Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
1
Written by
10 November 2017
Overview of EGNSS downstream standardisation and
assessment of gaps and future needs to facilitate the integration
of Galileo and EGNOS into user applications
Final report
2
LEGAL NOTICE
This document has been prepared for the European Commission however it reflects the views only of the authors,
and the Commission cannot be held responsible for any use which may be made of the information contained
therein.
More information on the European Union is available on the Internet (http://www.europa.eu).
© European Union, 2017
Reproduction is authorised provided the source is acknowledged.
3
CONTENTS
1 INTRODUCTION ................................................................................................................ 5
1.1 Document structure ....................................................................................................5
1.2 Methodology ...............................................................................................................5
2 EXECUTIVE SUMMARY .................................................................................................... 8
3 KEY FINDINGS BY GNSS MARKET SEGMENT .............................................................. 17
3.1 Aviation .................................................................................................................... 17
3.2 UAVs ........................................................................................................................ 27
3.3 Maritime ................................................................................................................... 36
3.4 LBS .......................................................................................................................... 48
3.5 Road......................................................................................................................... 60
3.6 Rail ........................................................................................................................... 78
3.7 Multimodal transport and logistics ............................................................................. 82
3.8 Agriculture ................................................................................................................ 83
3.9 Timing and Synchronization of critical infrastructures ............................................... 86
3.10 Overarching recommendations ................................................................................. 94
4
TABLES
Table 1: UAVs devices from 2015 to 2025 .............................................................................. 27
FIGURES
Figure 1: Project Logic ..............................................................................................................5
Figure 2: Task 1 Logic ..............................................................................................................6
Figure 3: Task 2 Logic ..............................................................................................................7
Figure 4: Task 3 Logic ..............................................................................................................7
Figure 5. Roadmap and standardisation actions in aviation surveillance ................................ 19
Figure 6: Roadmap and standardisation actions in aviation SAR ............................................ 24
Figure 7: Roadmap and standardisation actions in UAVs ....................................................... 31
Figure 8. Roadmap and standardisation actions in maritime navigation .................................. 37
Figure 9. Recommended non-standardisation action in maritime navigation ........................... 40
Figure 10. Roadmap and standardisation actions in maritime E-navigation ............................ 42
Figure 11. Roadmap and standardisation actions in maritime autonomous navigation ........... 45
Figure 12. Roadmap and standardisation actions in LBS 5G .................................................. 49
Figure 13. Roadmap and standardisation actions in LBS IoT .................................................. 55
Figure 14. Roadmap and standardisation actions in Tracking of Hazardous Materials ............ 61
Figure 15. Roadmap and standardisation actions in ADAS ..................................................... 64
Figure 16. Roadmap and standardisation actions in Autonomous Driving ............................... 69
Figure 17. Roadmap and standardisation actions in Cooperative ITS (overlaps with ADAS/AD)
........................................................................................................................................ 72
Figure 18. Roadmap and standardisation actions in Rail ........................................................ 80
Figure 19: Recommended non-standardisation action in multimodal transport and logistics ... 83
Figure 20: Roadmap and recommended actions in agriculture ............................................... 85
Figure 21: Roadmap and recommended standardisation actions in T&S ................................ 89
Figure 22. Recommended non-standardisation actions in maritime SAR ................................ 95
5
1 INTRODUCTION
1.1 Document structure
This report covers the key findings of an analysis performed by GMV, LS and VVA under DG
GROW´s Framework Contract ENTR/396/PP/2014/FC on the overview of EGNSS
downstream standardisation and assessment of gaps and future needs to facilitate the
integration of Galileo and EGNOS into user applications.
The document contains the following sections:
Chapter 1: Introduction;
Chapter 2: Executive Summary
Chapter 3: Key findings by GNSS market segment
1.2 Methodology
Three tasks were covered in the analysis:
Task 1: Analysis of available standards and ongoing standardisation activities in
the main EGNSS application areas;
Task 2: Gap analysis of standards, aimed at identifying where existing standards
need to be updated, replaced or augmented, with alternatives to facilitate and promote
the use of EGNSS;
Task 3: Standardisation roadmap, focusing on the development of a long-term
strategy for standardisation activities for facilitating EGNSS adoption in important user
applications.
The project logic is shown in the following figure:
Figure 1: Project Logic
The objective of the first task was to develop a complete compilation of available standards
and ongoing standardisation activities for potential EGNSS application areas. To reach the
objective of this task, five activities were performed:
Activity 1.1: Development of the taxonomy of application areas (including analysis
whether it is advisable to include EGNSS in the future);
Activity 1.2: Generic description of standard types;
Activity 1.3: Elaboration of catalogue of standards and organizations;
6
Activity 1.4: Elaboration of catalogue of on-going standardisation activities;
Activity 1.5: Cross information from the individual analyses and generation of
synthetic summaries.
The logic of Task 1 is depicted in the following figure:
Figure 2: Task 1 Logic
It is important to remark that the project focuses on the standardisation of the use of GNSS
for different application areas, not on the standardisation of the applications themselves.
The objective of Task 2 was to analyse where existing standards (based on conventional
technology or GPS) would need to be updated, replaced or augmented, with alternatives to
facilitate and promote the use of EGNSS, and where there are gaps, i.e. where future
standardisation activities are needed to support EGNSS market penetration. To pursue this
objective, four activities were envisaged:
Activity 2.1: Desk research on gaps in standards
Activity 2.2: Interviews with stakeholders on gaps in standards
Activity 2.3: Analysis on actions to be taken in standardisation.
Activity 2.4: Validation of the results with stakeholders
The logic is depicted in the following figure:
7
Figure 3: Task 2 Logic
The objective of Task 3 was to propose a comprehensive long-term strategy for
standardisation activities with the objective to facilitate the integration of EGNOS and Galileo
into the different market segments and user applications. The roadmaps provide a coherent
action and implementation plan covering standardisation to be undertaken both at European
level as well as at international level.
Task 3 was split into the following activities:
Activity 3.1: Analysis on the strategic prioritization of actions on standardisation
Activity 3.2: Legal aspects analysis
Activity 3.3: Development of roadmap for standardisation activities
Activity 3.4: Overall project conclusions and recommendations
Task 3 logic is depicted in the following figure.
Figure 4: Task 3 Logic
8
2 EXECUTIVE SUMMARY
This report covers the key findings of the analysis performed by GMV, VVA and LexJus
Sinacta under Specific Contract Nº2 of DG GROW’s Framework Contract
ENTR/396/PP/2014/FC – Overview of EGNSS downstream standardisation and assessment
of gaps and future needs to facilitate the integration of Galileo and EGNOS into user
applications.
Galileo, the future European GNSS (Global Navigation Satellite System) system currently
under finalization, and EGNOS (European Geostationary Navigation Overlay Service), the
European Space Based Augmentation System (SBAS), will provide services for many different
user communities and applications over a wide geographical area: Galileo world-wide and
EGNOS over at least the ECAC (European Civil Aviation Conference) region. In this frame,
GNSS standardisation plays a key role to support the uptake of Galileo and EGNOS for two
reasons:
Concerning regulatory use of standards, the standards are a powerful tool to support
the safety of life services offered by the European GNSS (EGNSS), e.g. those of
transport, maritime and aviation segments.
Focusing on market driven standards, standards can help ensure operability, market
uptake and market penetration of Galileo and EGNOS products and services.
In this document, for each market segment and application:
The role of GNSS/EGNSS is summarised;
The gaps in standardisation found during the project are described;
The recommended actions are outlined.
This Executive Summary focuses on this last element. It covers the top priority actions to be
taken based on the analysis performed. These actions, ordered by priority, are outlined below.
1. UAVs: Perform a feasibility analysis to support GNSS Requirements definition for
UAVs.
The UAVs market segment is growing very quickly and it is very promising for EGNSS uptake.
At the same time, UAVs standardisation and in particular the standardisation of GNSS usage
in an UAVs context is at an early stage, which creates an adequate window of opportunity for
action. In this frame, GNSS requirements for UAVs need to be defined for each UAV category1
and for the different functions, as a necessary step before standardisation.
1 EASA established three Unmanned Aircraft categories with different safety requirements:
- “Open” (low risk) is a UA operation category that, considering the risks involved, does not require a prior authorisation by the competent authority before the operation takes place
- “Specific” (medium risk) is a UA operation category that, considering the risks involved, requires an authorisation by the competent authority before the operation takes place and takes into account the mitigation measures identified in an operational risk assessment, except for certain standard scenarios where a declaration by the operator is sufficient;
- “Certified” (high risk) is a UA operation category that, considering the risks involved, requires the certification of the UAS, a licensed remote pilot and an operator approved by the competent authority, in order to ensure an appropriate level of safety
9
A feasibility analysis on the performance achievable through EGNSS should be conducted as
soon as possible. The analysis aims at supporting the definition of the functions that require
GNSS data (navigation, electronic identification and geofencing) identified in the regulation2
and the U-Space3. Establishing navigation requirements that EGNSS technology could help
meeting would make the case for the introduction of EGNSS itself, encouraging industry and
users to adopt European systems in this market segment. This action (feasibility analysis) is
considered a key input for the standardization of the use of EGNSS in UAVs and should
clearly identify which is the potential added value of E-GNSS in this market.
This feasibility analysis needs to be launched by the European Commission (EC), together
with the GSA (GSA) and in close cooperation with the European Aviation Safety Agency
(EASA) / Single European Sky ATM Research (SESAR).
This action should be immediate and leverage on existing work. As soon as possible (i.e. end
2017 - beginning 2018 at the very latest), the European Commission and the GSA should
inject the outcomes of the proposed feasibility analysis in the GNSS requirements definition´s
process led by EASA4.
2. UAVs: Foster the Standardization Process at ICAO/EUROCAE level
After the definition of GNSS requirements, it is recommended that the European Commission
promotes an aviation-like standardization process (i.e. including receiver Minimum Operational
Performance Standards, ICAO Standards and Recommended Practices, Technical Standard
Orders etc.) for the use of E-GNSS in UAVs, at least for the “certified” category.
For the “specific category”, it is not clear whether the optimal action is a process similar to the
one in aviation or rather a lighter process (e.g. a light certification scheme). This depends on
the future definition of the safety positioning requirements for this category.
Focusing on the UAVs within the “open” category, product harmonisation (e.g. CE Marking)
should be used to ensure that EGNSS is being used properly in UAVs GNSS receivers, in
particular considering the geo-fencing and electronic identification functions. The process and
requirements should not be as stringent as the ones for the specific and certified categories, in
order not to hinder the market growth of open category UAVs.
The standardization process proposed above, to be started by 2018, should be coordinated
and aligned with the regulatory process that is currently on-going for UAVs.
3. LBS: Update 3GPP/ETSI standards to change the selection of the priority for GNSS
constellations
Existing standards such as 3rd Generation Partnership Project (3GPP) TS 45.005 and TS
36.171 give priority to the Global Positioning System (GPS) constellation for the selection of
satellites to calculate the position, even in the case of other constellations being available with
better signals. It is worth stressing that the current specifications have been drafted so to
2 NPA 2017-05 is the ‘Prototype’ Commission Regulation on Unmanned Aircraft Operations issued by EASA
3 The U-Space concept arises from the idea that a traffic management system is needed for controlling drones. U-
Space will be a set of services. SESAR is developing this concept and a blueprint has been released in June 2017. 4 It would be optimal to inject preliminary results of the feasibility analysis as soon as possible to leverage in these
results for the requirements definition process since both tasks will run in parallel
10
prioritise GPS because of the reliability that the system has shown over more than 20 years,
which makes it a “safe” choice for chipset manufacturers to rely on.
To solve this issue, the European Commission and the GSA should request as soon as
possible (target: 2017) 3GPP, and more specifically Working Group 4 under the Radio Access
Network (RAN) Technical Specifications Group (TSG), to update the technical specifications of
these standards, along with the ones that will be drafted for 5G, to the current GNSS
landscape, so that no specific system is given preference. The main argument should be that
whereas in the past the definition of GPS as primary constellation in the standards could be
reasonable, given the limited availability and low maturity of other GNSS, nowadays with more
fully operational systems available for the public, the distinction is only hampering the adoption
of the non-GPS systems and limiting the effectiveness of the overall satellite positioning
solutions, since satellites of a different constellation than GPS may provide better operating
conditions. This action is important on the one hand for enhancing the Galileo market
penetration and on the other hand for building a performance-driven positioning solution.
In parallel with the standardisation action outlined above, the continuation of ongoing activities
to facilitate the Galileo implementation in mass-market devices is a necessary complement to
the proposed standardisation action.
4. Road: Definition of the integrity concept and algorithms.
Road is the second largest market segment in terms of installed base and the most relevant in
terms of revenues, and EGNSS has good uptake perspectives, with Galileo and EGNOS being
adopted to support different applications considered in the analysis (Advanced driver-
assistance systems, Autonomous Driving, Cooperative-ITS). However, standardisation
could support a more pervasive use of EGNSS as compared to the state of the art, thanks to
the exploitation of some of their additional capabilities (e.g. use of EGNOS to determine
protection levels) and/or differentiators such as authentication.
In this frame, there is room for a more extensive use of EGNOS for protection levels
estimation. The approach used to apportion the risk in the aviation sector is far from optimal
in the perspective of non-aviation applications. The “specific risk assessment” built in Satellite-
Based Augmentation Systems (SBAS) to meet civil aviation specific needs penalises non-
aviation users in term of size of the resulting protection levels (and so, in terms of availability).
Although it is partially covered by the standard EN 16803-1, the work on the definition of an
integrity approach suitable for road applications should be further analysed. The road
environment is very different than the aviation one, therefore a characterization of the residual
error budgets (multipath, noise etc.) and a definition of performance levels in terms of
accuracy, availability and integrity aspects would be needed.
A common action to different applications is thus the proper definition of protection levels for
road. The GSA should contact CEN/CENELEC TC5 WG1 to contribute to the definition of the
integrity approach for road applications and security performance levels specific for the road
domain in the 2017-2018 period. Adequate integrity and protection level definitions should be
provided both at user-service level (the needs of the user service for the location system) and
operation level (integrity risk, continuity risk, alarm limit, protection levels). In this frame, a
11
potential support for the definition of performance levels from technical activities to be
developed by the industry could be envisaged. The exact definition of integrity-like parameters
varies based on the different applications. 1D integrity (i.e. linear, along-track) might be
enough for platooning/cruise control, whereas minimum 2D integrity (i.e. focusing on the
horizontal plane) is required for collision avoidance or automated lane change.
5. Road: Update relevant information exchange standards to include integrity and
authentication support for the road domain
Complementary to the action above, to leverage the additional capabilities of EGNSS (beyond
additional satellites in view), it is necessary to include support for integrity (provided by
EGNOS) and authentication (provided by Galileo) of the position information in the location
elements of the:
a) information exchange protocols between the different components of the vehicle;
b) vehicle-to-everything (V2X) data exchange protocols.
This action is important for EGNSS market uptake because integrity and authentication are the
differentiator features of EGNSS (versus other GNSS) for this market segment that are
currently not in use.
To cover objective a), starting from 2017 the European Commission and the GSA should
address CEN/CENELEC, with the final objective of getting in touch with ISO Technical
Committee 204 on Intelligent Transport Systems, so to review the current in-vehicle
communication protocols and expand the message format to add the minimum set of
information required to support signal authentication and integrity. To this end, the revision
cycle and development of relevant ISO TC 204 standards should be followed with respect to
the following standards:
ISO 15075:2003 Transport information and control systems -- In-vehicle navigation
systems -- Communications message set requirements;
ISO 15623:2013 Intelligent transport systems -- Forward vehicle collision warning
systems -- Performance requirements and test procedures;
ISO 18682:2016 Intelligent transport systems -- External hazard detection and
notification systems;
ISO 11067:2015 Intelligent transport systems -- Curve speed warning systems (CSWS)
-- Performance requirements and test procedures;
ISO/DIS 15622 Intelligent transport systems -- Adaptive cruise control systems --
Performance requirements and test procedures;
ISO/TS 19321:2015 Intelligent transport systems -- Cooperative ITS -- Dictionary of in-
vehicle information (IVI) data structures.
To cover objective b), the European Commission and the GSA should address standardisation
organisations, starting from ETSI (European Telecommunications Standards Institute) TC ITS,
again to include the support for integrity information and signal authentication (spoofing
detection) in the information exchange protocols, covering the following standards:
ETSI TS 103 324: Cooperative Observation Service;
12
ETSI-TS 102 894/SAE J2735/ITS Connect TD-001 - Applications and facilities layer
common data dictionary
ETSI EN 302 637-2 ITS: Vehicular Communications; Specifications of Context
Awareness Messages
ETSI EN 302 637-3 ITS: Vehicular Communications; Specifications of the
Decentralized Environmental Notification Messages
In parallel, within the future releases of the Rolling Plan on ICT (Information and
Communication Technologies) standardisation emphasis should be made to add support for
integrity and spoofing robustness.
6. Timing & Synchronisation: perform technical activities to solve open points and
provide inputs for standardisation process
Even if GPS is already used for Timing and Synchronisation (T&S) for different types of
applications, including critical infrastructures, there are no standards in place on GNSS-based
T&S (although several standards refer to the use of GNSS for timing). T&S applications,
associated to critical infrastructures, are strategic and critical for Europe, and for this reason it
is very important to ensure a minimum level of robustness and reliability for the use of GNSS,
which can be obtained thanks to standardization. Additionally, the standardization process can
serve as an effective mechanism to foster the use of EGNSS (Galileo and EGNOS) within this
important market.
However, as a preliminary step, standardisation actions need to be fed with technical analyses
to solve open points on the usage of GNSS for T&S applications. In our experience, the
performance of timing applications highly depends on how GNSS data is used (different
applications on the market show different behaviour in terms of robustness and resilience).
Therefore, is it very important to define a robust approach to GNSS processing. Additionally,
there are other technical aspects that need to be consolidated to maximise the benefits that E-
GNSS can bring to these applications thanks to its differentiators. To this end, is
recommended that the European Commission and the GSA launch technical studies to be
developed in 2018. The areas that require further investigation include:
Jamming and spoofing mitigation: to protect critical infrastructures from potential
attacks, it is important to identify the best solution to mitigate this GNSS vulnerabilities,
as well as to assess whether standardisation is needed;
T-RAIM (Timing Receiver Autonomous Integrity Monitoring) algorithms: it is
recommended to work on integrity timing algorithms and to define which is the best
option for a robust and reliable timing solution, analysing the potential use of EGNOS
and Galileo timing service;
Multi-GNSS timing solutions: The solution for combining multi-GNSS for timing
applications is not harmonized, to the point that in a faulty case of GPS, receivers have
been showing very different levels of resiliency. It is important to work on this specific
aspect to ensure a proper implementation of multiple constellations in timing
applications, so to ensure a minimum level of resilience over the EU territory
Use of Galileo Ionospheric NeQuick model: In our experience, the use of the Galileo
NeQuick model presents an advantage over the use of the GPS ionospheric model
(Klobuchar), in terms of obtaining a stable timing solution for monofrequency users. It
13
is recommended to study and demonstrate the advantages of using this model and the
benefits that this can provide to T&S applications.
Feasibility analysis covering EGNSS compliance with T&S requirements in critical
infrastructures: Defining which timing requirements, and to what extent, the EGNSS
technology could fulfil, would help make the case for the introduction of EGNSS itself,
encouraging industry and users to adopt European systems in this market segment.
The activities above are to a certain extent already handled in the recently completed
DEMETRA project5, as well as in the ongoing project focusing on EGNSS Robust Timing that
is funded under the H2020 Programme. When this project will be finished at the end of 2017, a
gap analysis should be performed to ensure that the remaining issues are covered, by
launching additional projects in the 2018 timeframe.
7. Timing & Synchronisation: Development of EGNSS T&S Receiver Standards and of
conformity assessment scheme
Leveraging on the outcomes of the previous action, to ensure the development of a EGNSS
T&S receiver standard, we recommend that in 2019-2020 the European Commission and the
GSA contact, through CEN/CENELEC, relevant bodies such as ISO/IEC at a global level and
ITU-T/ESMA at the level of applications, to raise awareness on the need of the development of
such standards. Once started, the standardisation process should be monitored by the
European Commission and the GSA to ensure that relevant EGNSS features are covered to
enhance EGNSS market penetration.
Standardisation of T&S will be relevant at least for critical infrastructures. Thus, the resilience
of the T&S solution should be guaranteed to protect strategic assets from potential attacks.
In parallel with receiver standardisation, the European Commission could decide whether to
mandate the use of EGNSS for T&S in critical infrastructures over EU territory. If this decision
is taken, it would be very important for the European Commission to develop a conformity
assessment scheme that would help ensuring that critical EU infrastructures are implementing
EGNSS for T&S following the standards developed. It is of critical importance for such scheme
to cover the reliability and resilience of the timing solution for critical infrastructures, by setting
minimum requirements that EGNSS would contribute to meet.
8. Maritime: perform technical studies to define autonomous vessels GNSS
requirements in maritime to be used in future development of autonomous vessels
standards
The autonomous vessels application, although very promising, is still in a very initial stage.
There is no legal framework dealing with the regulatory aspects of operating autonomous
vessels, the operational costs are still unknown and the technical standards for operating
autonomous vessels are not yet established. However, the trends towards unmanned vehicles
are evident and the question is not if there will be a market for autonomous vessels, but rather
when.
5 See http://rime.inrim.it/H2020-Demetra/project-overview/
14
In terms of regulatory bodies, the International Maritime Organisation (IMO) is starting to work
on autonomous vessels. The Maritime Safety Committee (MSC) in its 98th session, held in
June 2017, included the issue of marine autonomous surface ships on its agenda. It was
agreed to initiate a Scoping Paper6 on autonomous vessels at the next MSC session, planned
for 2018. This will be in the form of a scoping exercise to determine how safe, secure and
environmentally sound operations may be introduced in IMO instruments. It is anticipated that
the work will take place over four MSC sessions, meaning that it will be developed until mid-
20207. It is also expected that draft standards and regulations will be developed in the
upcoming years.
EGNSS (EGNOS and GALILEO) could play an important role and it is important that they are
considered on equal terms with GPS since the early beginning of the process. The definition of
positioning requirements, of key importance for GNSS, is a first step prior to a potential
standardisation process, since it will enable to determine whether and to what extent
autonomous vessels should be considered in a different way than manned navigation
application within the standards. Such activity is also important to analyse whether EGNSS
can comply with these requirements, a key element to assess the EGNSS adoption
perspective in this application.
Considering safety aspects, the definition of autonomous vessel requirements should be
accompanied by the definition of a safely manner to operate autonomous vessels and how to
be integrated with manned vessels, in other words, to develop an autonomous vessel
operational concept (define procedures, certified paths, etc.).
It is proposed that the European Commission and GSA launch technical studies in 2018 to
analyse and define positioning requirements of autonomous vessels. Special attention should
be dedicated to safety-related requirements.
Such activity would be complementary to a feasibility analysis aimed at assessing the
performance achievable with EGNSS, aimed at clearly identifying how EGNSS could help to
ensure safety of unmanned navigation.
The positioning requirements definition for autonomous vessels will be used to decide whether
it is necessary to launch a specific standardisation process for autonomous vessels. If as
expected, the autonomous vessels positioning requirements are found to be more stringent
than the ones for general maritime navigation, then either:
autonomous vessels will need to be considered as a specific category within existing
maritime standards;
or new standards for autonomous vessels would need to be developed.
At this stage, a standardisation roadmap for EGNSS within autonomous vessels would need to
be developed. Such roadmap would be instrumental to ensuring that the application obtains
the maximum benefits from EGNSS features and differentiators (e.g. integrity, robustness,
authentication, etc.).
6 A Scoping Paper is the formal identification of topics of interest to IMO and the process of making such a paper
usually takes 2-3 years. The processes in IMO are complex because of the need for harmonization between many member states. 7 http://www.imo.org/en/MediaCentre/MeetingSummaries/MSC/Pages/MSC-98th-session.aspx
15
To this end, it is suggested that, once the requirements definition will be consolidated, the
European Commission and the GSA contact the International Maritime Organisation (IMO), to
trigger then work by the Radio Technical Commission for Maritime Services (RTCM) and the
International Electrotechnical Commission (IEC).
9. Rail: Develop technical studies on GNSS use in Safety of Life applications
While GNSS is perceived as a very promising technology in rail (e.g. for virtualization of
balises and signalling of secondary routes) its usage in Safety of Life (SoL) applications such
as the European Rail Traffic Management System (ERTMS) is still in the research phase and
the added value of EGNSS is still under investigation. In this frame, EGNSS is expected to
provide an important added value thanks to improved availability and accuracy enabled by
Galileo in a multi-constellation context, as well as thanks to Galileo authentication and EGNOS
integrity; however, technical and cost-benefit assessments still need to be finalised.
Before activating a standardisation process, it is proposed that the European Commission and
the GSA, in coordination with other stakeholders such as the European Space Agency (ESA),
the European Union Agency for Railways (EUAR), UNISIG8 and the ERTMS Users Group
(EUG) continue launching and monitoring technical activities on GNSS for rail in the 2018-
2020 period, to solve different open point that need to be addressed to determine if EGNSS
capabilities are found suitable for ERTMS. A roadmap has been already agreed between the
stakeholders mentioned above. On-going projects on the use of GNSS in rail should be
monitored and technical studies should be developed for the points that could remain open in
the light of their outcomes. In addition to the activities foreseen in the roadmap, the following
actions are suggested:
Quantification of benefits once the technical solution is clear: Even if cost-benefit
analyses (CBAs) have been performed, a final and comprehensive CBA for the
introduction of EGNSS in ERTMS is required when the final architecture will be
selected. This CBA would need to focus specifically on the selection and quantification
of key parameters through an impartial approach;
Positioning requirements for rail applications (e.g. for signalling applications) are quite
stringent and GNSS augmentation will probably be required. In this sense, it is
recommended to perform analyses to select the most suitable GNSS technology for
ERTMS, choosing between Space Based Augmentation System (SBAS), Ground
Based Augmentation System (GBAS), Advanced RAIM (ARAIM) etc.
10. IoT: Promote the inclusion of signal authentication and position integrity support in
the IoT reference architectures
The fast growth of Internet of Things (IoT) has led to the development and deployment of
relevant technologies before relevant standards were put in place, which makes the definition
of industry-wide standards challenging. GNSS is already considered in IoT solutions, but only
at a basic level, i.e. as a sensor. Currently there is little room in current standards to leverage
8 UNISIG is an industrial consortium created to develop the ERTMS/ETCS technical specifications. As an
Associated Member of UNIFE, UNISIG actively contributes to the activities of the European Railway Agency in the field of ERTMS/ETCS technical specifications.
16
on the differentiators of EGNSS such as integrity (provided by EGNOS) and authentication
(provided by Galileo).
We recommend considering the active promotion of the expanded functionalities of EGNSS
and including their support in the reference architectures designed for IoT
applications. Given that the scope of IoT applications is very broad (there are many
standardisation streams in IoT), this option was prioritised versus the analysis of the
performance requirements, use cases and application scenarios since it is a more focused
task and can provide more relevant results to foster the adoption of EGNSS.
As currently IoT reference architectures support positioning information, but on a very basic
level (they cover coordinates only, some radius of confidence at the most), they should be
updated to optionally support additional positioning specifications, such as integrity and signal
authentication, which could then be leveraged by demanding applications (e.g. liability critical
ones).
The main recommendation is for the European Commission and the GSA, during the 2018-
2020 period, to contact ETSI and the Alliance for the Internet of Things Innovation (AIOTI) to
promote the support of signal authentication and position integrity (differentiators of EGNSS) in
the positioning elements of OneM2M, and to establish, through ETSI, similar contacts with
ISO/IEC JTC WG10, which is also developing a reference architecture for IoT. The Open
Mobile Alliance and Open Geospatial Consortium are also relevant organizations that could be
contacted regarding their IoT standards.
17
3 KEY FINDINGS BY GNSS MARKET SEGMENT This section outlines the key findings of the analysis for the market segments covered in the
analysis, followed by the outcomes of the gap analysis and presentation of the resulting
recommendations.
3.1 Aviation
Within the aviation market segment, Surveillance and Search and Rescue (SAR) have been
selected as the applications to be covered in the analysis, since they show a potential for
EGNSS and potential need for standardisation, whereas for other applications such as
navigation, the standardisation process is well under control and monitored by the EC.
3.1.1 Surveillance
3.1.1.1 The role of GNSS and EGNSS
GNSS is increasingly adopted in surveillance. The installed base of GNSS devices for aviation
surveillance worldwide will be multiplied by a factor of four between 2015 (24,000 devices) to
95,000 devices in 2020 and will be further increased to 139,000 devices in 20259.
As for aviation navigation applications, Automatic Dependent Surveillance – Broadcast (ADS-
B) is standardised worldwide by the International Civil Aviation Organisation (ICAO), while the
European Organisation for Civil Aviation Equipment (EUROCAE) and the Radio Technical
Commission for Aeronautics (RTCA) oversee developing Minimum Operational Performance
Standards.
Nowadays, the use of ADS-B for surveillance is accepted worldwide and EGNSS could
potentially play a key role. Standardisation is only a pre-requisite for GNSS adoption in
surveillance, which is mainly driven by the market itself and by regulators. Currently, standards
in a single-constellation and single-frequency context are already developed, including both
Standards and Recommended Practices (SARPs) and Minimum Operational Performance
Standards (MOPS). Focusing on EGNSS, EGNOS V2 is ready to be used in ADS-B from a
standardisation point of view.
In this frame, the constellation of Galileo provides an opportunity to increase the use of
EGNSS for surveillance either in a multi-constellation context or standalone.
The enhanced performance of EGNOS V3 (i.e. enhanced performances and resilience) is not
necessary based on the current ADS-B requirements in Europe, but it might become relevant
in the future (e.g. 2030 – 2040) if more stringent requirements from potentially new
applications, such ADS-C (Automatic Dependent Surveillance - Contract) or ADS-B in
runways, would come into place.
There are several aspects while analysing the future use of EGNSS (Galileo and EGNOS)
within ADS-B that can be considered as a prerequisite for the ADS-B standardization: the
9 Source: GNSS Market Report Issue 5, 2017
https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
18
Galileo constellation needs to be fully deployed and EGNOS V3 and Galileo systems need to
be fully operational and completely standardized (including SARPS, MOPS and Technical
Standard Orders (TSO) for navigation applications.
It is expected that a consolidated version of the GPS/Galileo SBAS L5 MOPS will be issued by
EUROCAE/RTCA in 2020-2021, including the Appendix F related with velocity data that is
needed in ADS-B (ADS-B equipment must set the velocity based on the real-time velocity
information provided by the position source). Once Galileo will be fully operational, it is likely
that multi-constellation GNSS solutions will become widespread within and outside Europe.
3.1.1.2 Gaps in standardisation
The use of ADS-B for surveillance is accepted worldwide and SBAS (EGNOS) provides
acceptable means of compliance. Standards on ADS-B are already developed and EGNOS
V2 could be used in the short term. For the long term, the inclusion of Galileo and EGNOS V3
would require the development of new standards (linked with aviation navigation applications).
The working group RMT.0679, coordinated by EASA, is currently considering the revision of
surveillance performance and interoperability and according to the stakeholders consulted, the
surveillance solutions will consider not only ADS-B but also radar infrastructure. Europe, as
opposed to the US, has not specified if there is a need for the position accuracy and the
capability of augmented GNSS or multi-constellation satellites. There is an agreement in the
rule-making (RMT.0679) to have an SBAS as a requirement for forward fit from 2025 onwards.
The evolution of the regulation will need to be monitored, to verify if new regulation will include
specifications related to the position accuracy and the capability of augmented GNSS or multi-
constellation satellites.
The use of GNSS for airport surface movement guidance is also currently in the research
phase. GNSS could play a role in this application, in the future as a combination of different
technologies as a backup in case of failures of e.g. radar or ADS-B.
3.1.1.3 Recommended standardisation actions
Considering the framework outlined in the sections above, it is too early to recommend a
complete list of standards to be developed for the usage of Galileo and EGNOS V3 in ADS-B.
However, once EGNOS V3 and Galileo will be deployed and standardised for navigation
applications, a proper standardisation process would be needed to support the uptake of
Galileo and EGNOS V3, since this application is SoL critical. Considering this framework, a
series of high priority actions suggested for aviation surveillance are proposed in the roadmap
below.
19
Figure 5. Roadmap and standardisation actions in aviation surveillance
Identification of optimal approach to support EGNSS uptake in ADS-B
Justification / Expected impact on EGNSS uptake: The fact that standards for ADS-B in a
single-constellation and single-frequency context already exist is a necessary but insufficient
condition to support EGNOS V2 uptake in ADS-B. In general, to support adoption of EGNSS,
the demonstration of a positive business case and/or a legislative mandate for the use of
EGNOS both represent possible actions to stimulate adoption. This action is important as
regulation on ADS-B is now being modified.
Priority: High, the action is important to improve the level of EGNSS usage for this
application, since standardisation alone is only a pre-requisite for market adoption.
Owner: European Commission.
Timeframe: From end of 2017 to end of 2018.
Recommendation: Identify and select the optimal approach to support EGNSS uptake in
aviation surveillance applications. The demonstration of a business case should be given
priority, as it also represents a facilitator for legislative actions. To this end, we suggest
updating the cost-benefit analysis (CBA) performed by GSA according to the new SPI IR
(Regulation (EU) No 1207/2011, laying down requirements for the performance and the
interoperability of surveillance for the Single European Sky. The CBA should focus on EGNOS
added value in ADS-B10 to investigate and show the presence of a positive business case. The
following actions are then suggested based on the results of the CBA:
If the CBA shows the presence of positive net benefits for all involved stakeholders, it
could be used as a tool to support adoption by promoting the results (and ADS-B
advantages) to key decision makers.
If the CBA shows overall positive results, but a negative impact on a specific
stakeholder, it might be possible that the market alone would not autonomously
introduce EGNSS. If this is the case, actions such an EU mandate for using EGNSS in
10
Going more into details than already existing CBAs, which already cover ADS-B in the wider frame of EGNOS benefits for aviation
20
Europe or incentives to the stakeholders negatively impacted in terms of net benefits
(e.g. the airlines) could be envisaged.
The same approach is also applicable in a multi-constellation context for Galileo and EGNOS
V3 adoption in ADS-B, after the required standardisation process will have been completed. In
the CBA, it is recommended to include scenarios covering the adoption of EGNOS V3
augmenting GPS and Galileo under the hypothesis of potentially more stringent requirements
than the current ones, which would justify the introduction of such systems.
EC/GSA to contact EUROCAE for developing Appendix F in GPS/Galileo SBAS L5
MOPS for supporting ADS-B
Justification / Expected impact on EGNSS uptake: To prepare Galileo and EGNOS V3
market uptake for ADS-B, a pre-requisite is to consider velocity data aspects in a multi-
constellation and multi-frequency context in support of ADS-B, within the navigation standards
being developed by EUROCAE WG-62. Raising awareness of this need would be important so
the stakeholders could clearly perceive the need of including EGNOS V3 (and Galileo) in ADS-
B. This appendix describes the additional data processing that manufacturers may consider
supporting ADS-B. The Dual-Frequency and Multi-Constellation (DFMC) SBAS MOPS for
navigation is dedicated to ensuring a position, time and integrity solution using SBAS and
GNSS core constellations. To support ADS-B, the velocity solution is required as well. This
appendix completes the velocity computation part of the PVT solution in support of ADS-B.
Priority: High, the action needs to be performed due to mainly two reasons:
- to prepare the usage of Galileo in ADS-B in navigation standards, before the
standardisation process of multi-GNSS and multi-frequency ADS-B that would include
the development of new standards.
- to develop the theory for velocity computation in multi-GNSS and multi-frequency
context since ADS-B requires velocity computation. This would then represent a first
step for standardisation of EGNSS for ADS-B.
Owner: European Commission and GSA.
Timeframe: 2017 and development in 2018-2020 period.
Recommendation: To foster the use of EGNSS within ADS-B application, it is recommended
to participate in EUROCAE WG-62 for developing Appendix F in GPS/Galileo SBAS L5
MOPS. In particular, EC/GSA should support the EUROCAE for the development of the
Appendix F “Velocity Data in Support to ADS-B” in the GPS/Galileo SBAS L5 MOPS under
development at EUROCAE level for navigation. The appendix is foreseen in the table of
contents but with a secondary priority.
This will be a first step before standardising the use of Galileo and EGNOS V3 for ADS-B.
To ensure the success of this action, it is highly recommended to support the action by raising
awareness of the need of including ADS-B in GPS/Galileo SBAS L5 MOPS, for example by
showcasing the benefits of Galileo (as multi-constellation capability) and EGNOS V3 (dual-
21
frequency and dual-constellation) within ADS-B requirements. Raising awareness on the need
of developing such appendix could contribute to a faster development of the Appendix F.
Since this action could be considered as a milestone to initiate a specific and complete
standardisation process for aviation surveillance11, it is recommended that the EC also
monitors the process after it will be initiated.
This action would have a minimum cost and effort since the correspondent MOPS is already
being developed for the sections related to navigation and this work is being closely monitored
by EC/GSA and supported by EC/GSA projects.
Decision making on EGNOS V3 introduction for ADS-B
Justification / Expected impact on EGNSS uptake: Considering that EGNOS V2 already
complies with ADS-B requirements in CS-ACNS for ADS-B (NIC6) and could comply with even
more stringent requirements (NIC7), after the development of navigation standards for Galileo
and EGNOS V3 (DFMC - Dual-Frequency Multi-Constellation), a decision should be taken by
the EC/GSA on whether it is strategic for EU to introduce EGNOS V3 in ADS-B. If this is the
case, standardisation would represent an essential step.
Priority: High, the action needs to be performed to decide whether it is strategic for the EU to
introduce EGNOS V3 and Galileo for ADS-B or whether the use of EGNOS V2 is sufficient.
Owner: EC/GSA
Timeframe: In 2020
Recommendation: Evaluate whether more stringent requirements for surveillance have to be
defined, which would make a case for EGNOS V3 and Galileo introduction in ADS-B. As
mentioned above, the update of existing studies and cost-benefit analysis could be envisaged
to obtain the necessary information for decision-making.
Only after taking the decision, a standardisation roadmap for EGNOS V3 and Galileo
introduction in ADS-B could be envisaged and executed. It is worth noticing here that there is
a group for Galileo SoL that is currently working in Dual-Frequency and Multi-Constellation
GNSS for ADS-B. The work of this group could be used as an input for a potential
standardisation process of DFMC GNSS for ADS-B.
3.1.2 Search and Rescue
3.1.2.1 The role of GNSS and EGNSS
GNSS is increasingly adopted within aviation Search and Rescue in Emergency Location
Transmitters (ELTs), which are the key focus of this analysis. The installed base of GNSS
11
Nevertheless, considering that EGNOS V3 and Galileo are not fully deployed nor standardised for navigation, it is too early to define a roadmap for including Galileo and EGNOS V3 in ADS-B standards and for this reason we propose a final monitoring action of Galileo and EGNOS V3 standardisation for navigation before proposing a roadmap for Galileo and EGNOS V3 standardisation for ADS-B.
22
devices for aviation SAR worldwide will increase from 63,500 devices in 2015 to 97,000
devices in 2020 and will further grow to 136,500 devices in 202512.
In Search and Rescue, the use of GNSS for positioning is currently not required by SAR
regulations. COSPAS-SARSAT requirements are based on performance parameters and can
be fulfilled by different systems. Standards for the validation of the performance of Low Earth
Orbit (LEO), Geostationary Orbit (GEO) and Medium Earth Orbit (MEO) satellites already
exist. The uptake of GNSS in ELTs has been growing significantly in the past decade.
Whereas in 2004 only 16% of newly manufactured ELTs included GNSS, in 2015 the share of
GNSS-enabled (i.e. Location Protocol beacons) on total manufactured ELTs had doubled to
33%13.
The Galileo SAR service is comprised of two components:
A Forward Link service (FLS) going from the beacons to the satellites defined in
COSPAS-SARSAT documentation for Galileo, as well as for the other constellations.
A Return Link service (RLS) going from the satellites to the beacons and defined in
Galileo SIS ICD and in COSPAS-SARSAT documentation.
The main added value of EGNSS compared to other systems, is indeed the RLS – a unique
feature that is available thanks to Galileo. The RLS provides acknowledgment messages to
distress beacons equipped with a Galileo receiver, through the Galileo L1 signal.
Moving explicitly to the aviation domain, MOPS documents containing minimum operational
performance specifications and associated test cases for 406 MHz ELTs have been developed
by RTCA and EUROCAE, covering the Galileo SAR FLS.
3.1.2.2 Gaps in standardisation
The Galileo Forward Link is considered in COSPAS-SARSAT documentation:
COSPAS-SARSAT Mission Control Centres Standard Interface Description C/S A.002
Issue 6 – Revision 1
COSPAS-SARSAT Specification for COSPAS-SARSAT 406 MHz distress beacons
C/S T.001 Issue 4
COSPAS-SARSAT Specification for Second-generation COSPAS-SARSAT 406-MHz
distress beacons C/S T.018 Issue 1
The Galileo Return Link messages are standardised in the Galileo SIS ICD.
Moving explicitly to the aviation domain, MOPS documents have been developed covering the
minimum technical requirements for the ELT: RTCA “DO-204 "Minimum Operational
Performance Standards for 406 MHz Emergency Locator Transmitters (ELT)” as well as in
12
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf 13
Source: COSPAS SARSAT, Beacons Manufacturers Survey, 2016
23
EUROCAE ED 62 “Minimum Operational Performance Specification for aircraft emergency
locator transmitters 406 MHz and 121.5 MHz (Optional 243 MHz). These standards are only
focused on performance levels, but they do not cover implementation details, which need to be
addressed in other documents (see above).
For the development of the Galileo SAR capabilities within the aviation domain, there are
different documents issued by different organizations that need to be developed (or updated in
case they exist) to fully cover the operational and implementation aspects:
CONOPS (Concept of Operations) and SARPS (Standards and Recommended
Practices) from ICAO;
MASPS (Minimum Aviation System Performance Standards) and MOPS (Minimum
Operational Performance Standards) from EUROCAE/RTCA:
o MASPS describe the system (subsystems / functions) and provide the
necessary information needed to understand the rationale for system
characteristics, operational goals, requirements and typical applications;
o MOPS cover how the system will be used at user level;
TSO/ETSO from EASA (European Technical Standard Order), which are linked to the
regulation;
ETSI (European Telecommunications Standards Institute) documents that define
technical characteristics and methods of measurement for the Galileo SAR.
Different gaps have been identified at standardisation level focusing strictly on aviation
standards:
MOPS standards describe the minimum operational performance and associated test
cases.
o The Galileo Forward Link Service can be considered as covered in RTCA
MOPS DO-204. Nevertheless, Galileo FLS implementation details should be
standardised. This is not covered in RTCA MOPS DO-204.
o On the other hand, MOPS standards for the Galileo Return Link Service should
be developed.
ICAO SARPs covering the Galileo Return Link Service should be developed.
ICAO CONOPS (Concept of Operations) describe the capabilities of the GNSS core
constellations. The next generation of ICAO CONOPS currently under development
should describe the Galileo RLS capability.
A future important feature of Galileo SAR is expected to be the remote beacon activation, i.e.
the ability to trigger the distress messaging autonomously when the aircraft (or boat in
maritime domain) is reported missing, or when the pilot enters in suicidal behaviour.
Standardisation aspects should be evaluated in the future, after further progress.
3.1.2.3 Recommended standardisation actions
Considering this framework, several standardisation activities are suggested for SAR
applications, as shown in the roadmap below.
24
Figure 6: Roadmap and standardisation actions in aviation SAR
EC/GSA contact and monitor EASA for development of TSO/ETSO for ELT-DT
(including RLS)
Justification / Expected impact on EGNSS uptake: If this action is not undertaken, the
Galileo RLS differentiator feature would not be implemented since TSO/ETSO for Emergency
Location Transmitter – Distress Tracking (ELT-DT), including RLS, are needed from a
regulatory perspective.
Priority: High, needed for usage of RLS from a regulatory perspective.
Owner: EC/GSA to trigger work by EASA.
Timeframe: From 2018 to 2019.
Recommendation: To ensure that Galileo SAR RLS is included in the regulatory frame for
aviation, it is necessary that EASA develops a TSO/ETSO for ELT-DT, where the RLS is
included. In this sense, it is recommended that EC/GSA contacts EASA, first to raise
awareness on this need, for example by showing which will be the benefits of Galileo SAR
RLS in aviation as a differentiator feature, and then to support EASA in the development and
monitoring of such TSO/ETSO. More specifically, the following actions are identified:
Defining the interfaces between the different components of the Galileo SAR system.
In particular:
o Defining the approach to convey the message in distress. The message is
currently supposed to be sent from COSPAS SARSAT MCC (Mission Control
Centres) to Galileo through the Galileo ground stations operations centre, but
this is not clearly stated in any standardisation document to date;
o Also, it is important to describe the Return Link Message, which needs to come
from an airline operation centre to Galileo ground stations and then to the
Galileo constellation, so to be received by the Galileo receiver inside the ELT
DT.
25
EC/GSA contact and monitor EUROCAE for consideration of SAR FLS implementation
details in MOPS-like documents
Justification / Expected impact on EGNSS uptake: Ensuring that SAR implementation
details for the Forward Link Service (FLS) are considered in MOPS-like documents is
important, since current MOPS (RTCA DO-204 and EUROCAE ED 62) are only focused on
performance levels. They don’t cover implementation details, which need to be addressed in
these documents.
Priority: High, for the adoption of Galileo SAR in aviation. Being an application related with
SoL, implementation details of SAR need to be considered in aviation standards as a pre-
requisite for EGNSS market uptake.
Owner: EC/GSA
Timeframe: From 2018 to 2020.
Recommendation: To standardise the use of SAR FLS within aviation, it is needed to define
the implementation details in a MOPS-like document. In this sense, it is recommended that the
EC/GSA contact EUROCAE/RTCA to raise awareness of the need of including SAR
implementation details in MOPS-like documents and monitor the standardisation process. The
EC/GSA should contact directly the secretary of the EUROCAE/RTCA, so to accelerate the
process.
It is recommended that this MOPS-like document includes as minimum the following
information:
Implementation details associated to the SAR standardised functionalities;
New test procedures related with implementation details.
As a suggested approach, it is recommended to update RTCA DO-204 and EUROCAE ED 62,
rather than developing new MOPS documents.
Development of new MASPS document: Consolidate concept of operations to activate
the beacon (ELT) remotely in case of distress situation
Justification / Expected impact on EGNSS uptake: Galileo Return Link Service (RLS) is a
differentiator feature with respect to other systems (COSPAS-SARSAT or other GNSS).
Therefore, it is very important that Europe takes the lead in terms of driving standardisation
efforts to ensure that the RLS will be used in aviation. To this end, it is of key importance to
describe the system and to provide the necessary information to describe the rationale for its
characteristics, operational goals, requirements and typical applications.
Priority: High - being SAR a SoL application, this Galileo capability needs to be considered in
the aviation standards as a pre-requisite for Galileo uptake.
Owner: EC/GSA
26
Timeframe: To start in 2018, potentially finishing it in 2020.
Recommendation: We recommend as supporting action that EC/GSA contact EUROCAE to
raise awareness on the need to implement this action. Based on the action above, EUROCAE
would standardise the concept of operations to activate the beacon remotely in a new MASPS
(Minimum Aviation System Performance Standards) document. The GSA has already
contacted major manufacturers to promote this action.
EC/GSA contact and monitor ICAO and EUROCAE for consideration of RLS in SARPSs
and MOPS
Justification / Expected impact on EGNSS uptake: The requirements and implementation
details of the Galileo RLS unique feature should be properly standardised in aviation
standards as a pre-requisite for market uptake, since this application is related with SoL. In
particular, the RLS capability needs to be considered in the multi-constellation and multi-
frequency SARPS (Standards and Recommended Practices) under development by ICAO
NSP (Navigation System Panel) and in a EUROCAE MOPS. Current standards (EUROCAE
ED 62 and RTCA DO-204) do not include operational and implementation aspects for aviation,
which need to be covered in SARPS and MOPS-like documents.
Priority: High, being a SoL application the Galileo RLS needs to be considered in the aviation
standards as a pre-requisite for Galileo uptake.
Owner: EC/GSA
Timeframe: 2018-2021 period could be targeted.
Recommendation: To ensure RLS introduction in SARPSs and MOPS by ICAO and
EUROCAE/RTCA respectively, we recommend that EC/GSA contact ICAO and
EUROCAE/RTCA to raise awareness of this need and monitor the standardisation process.
More specifically, ICAO Navigation System Panel and EUROCAE WG-62 are the key
committees to be contacted. Requirements for RLS will need to be defined at ICAO (SARPs)
and at EUROCAE level (MOPS). Coordination between ICAO NSP and EUROCAE will be
necessary to ensure alignment between both SARPs and MOPS.
To contact these groups, it is recommended that EC/GSA contacts directly the secretary of
each group to accelerate the process.
Inclusion of Galileo in ETSI standards
Justification / Expected impact on EGNSS uptake: EC/GSA needs to contact the European
Telecommunications Standards Institute (ETSI) to include Galileo in SAR standards, since
technical characteristics and methods of measurement are described in those standards and
the Galileo SAR service should be considered.
27
Priority: High, being a SoL application the Galileo RLS needs to be considered in the ETSI
standards as a pre-requisite for Galileo uptake.
Owner: EC/GSA
Timeframe: The 2018-2021 timeframe could be targeted.
Recommendation: It is recommended to promote the update of the following ETSI standards
so to include Galileo and the RLS:
ETSI EN 300 066 V1.3.1 “Electromagnetic Compatibility and Radio Spectrum Matters
(ERM); Float-free maritime satellite Emergency Position Indicating Radio Beacons
(EPIRBs) operating in the 406,0 MHz to 406,1 MHz frequency band; Technical
characteristics and methods of measurement;
ETSI EN 302 152-1 V1.1.1 “Electromagnetic compatibility and Radio Spectrum Matters
(ERM); Satellite Personal Locators Beacons (PLBs) operating in the 406,0 MHz to
406,1 MHz frequency band; Part 1: Technical characteristics and methods of
measurements.
3.2 UAVs
3.2.1.1 The role of GNSS and EGNSS
GNSS is a promising technology for the UAVs market segment. The market is growing fast
and it is expected to dramatically increase in the following years, as shown in the table
below14.
Table 1: UAVs devices from 2015 to 2025
UAV/Year 2015 2020 2025 Commercial 200.000 3.000.000 7.200.000
Prosumer 1.700.000 10.000.000 19.300.000
Consumer 370.000 15.000.000 43.000.000
GPS is already present in most high-end Open Category drones, as well as in many small
drones. Competing with GPS is difficult, since it is a mature and consolidated technology in
different markets; however, considering that the main concerns related to drone operations are
related to security, Galileo could bring an important added-value with its authentication and
better performance (accuracy, availability) in a multi-constellation context. Nevertheless, it
might be too early for a complete identification of EGNSS added value, since the GNSS
requirements for UAVs are not defined. Currently, drones’ manufacturers use the
performances provided by GNSS services to design their systems.
14
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
28
3.2.1.2 Gaps in standardisation
Standardisation in UAVs is in a preliminary stage, even if many different activities are currently
ongoing. A potential approach to introduce EGNSS in UAVs would include the following steps:
First, the need for positioning and associated requirements should be identified:
o System/infrastructure: from a system point of view, considering the needs for
regulation, U-Space, etc.
o Applications/services: from an application point of view, considering specific
needs that the application itself could have.
Understand how EGNSS can fulfil the requirements;
The last step would be standardisation.
At the time of writing, the first step is being covered.
In Europe, an ecosystem for drones is being built with two pillars:
EASA basic regulation: Current efforts of the European Aviation Safety Agency
(EASA) are aimed at the development of a regulatory framework for all unmanned
aircraft regardless of their maximum take-off mass (MTOM), overcoming the 150 kg
present hurdle that leads to a fragmented regulatory framework, which hampers the
development of a unified unmanned aircraft vehicle (UAV) market in the European
Union (EU). This regulatory framework conceived the establishment of three different
categories for the operation of drones: ‘open’, ‘specific’ and ‘certified’. The EU is
already competent (in terms of regulation) for drones above 150 kg. The revision of
EASA basic regulation 216/2008 includes a transfer of competence from Member
States to the EU for drones below 150 kg. It also includes a set of essential
requirements for UAVs and empowers the European Commission to adopt
implementing rules.
UAS Space: The U-Space concept15 arises from the idea that a traffic management
system is needed for controlling drones. U-Space will be a set of services. The Single
European Sky ATM Research (SESAR) is developing this concept and a blueprint has
been released in June 2017.
Different phases are foreseen for developing these services. Concerning the first
phase the following functions are being defined:
o Electronic identification
o Geofencing: Both electronic identification and geofencing will be mandated
for drones of the Open category.
o Security: Security dimensions might define other functions or other level of
requirements for the identified functions.
15
U-Space is a set of new services and specific procedures designed to support safe, efficient and secure access to airspace for large numbers of UAVs (e.g. registration, electronic identification, geofencing, flight approval, tracking, etc.). A draft blueprint of the U-space concept has been presented by the Directorate General (DG) Move of the European Commission at a workshop held on 20 April 2017 in The Hague. The blueprint will be incorporated into an addendum relative to the integration of UAS into the European Air Traffic Management (ATM) Master Plan that should be adopted by the end of 2017. There is also a first draft addendum to the ATM Master Plan.
29
A key aspect in the U-Space concept is that it is important to differentiate between the
safety of the drone itself and the safety of airspace users due to drone operations.
Commission implementing rules: Following the publication of an Advance-NPA
2015-10 in July 2015, a Technical Opinion in December 2015, a ‘Prototype’ for the
‘open’ and ‘specific’ categories in August 2016, EASA issued last in May 2017 a draft
Commission Regulation (NPA 2017-05) focusing on the open and specific categories,
demanding two functions (i.e. electronic identification and geofencing) to support
enforcement for open category UAVs16. The specific category will be ruled under the
Specific Operations Risk Assessment (SORA) concept17. The case for EGNSS will
depend on the requirements set in the EU regulations and on market needs. The
definition of requirements is at a preliminary stage. It is expected that the requirements
will be adapted to the different UAVs operations and categories of UAVs.
A key aspect for UAVs will be the certification need, which will depend on many
aspects (safety, security, market, UAV category, etc).
For the open category, the European Commission is proposing product harmonisation
under the New Legislative Framework (e.g. CE Marking), rather than following the civil
aviation certification process. For the certified category, a regulation for the use of
EGNSS in EU could be potentially issued.
The requirements for drones are being defined in both Regulations and U-Space.
Standardisation will come after requirement definition. A potential EU mandate (linked with
standardization and regulation) might be issued to guarantee security and safety in drones’
navigation.
The key characteristics and the challenge for this market is that the UAVs market is evolving
more quickly than the standardisation process itself. Therefore, it is of paramount importance
that the EC proactively and efficiently answers this market need while guaranteeing, at the
same time, security and safety in the EU territory.
It is important to note that the introduction of too many functions (safety, security, geofencing,
etc) and of too stringent requirements (in line with manned airplane safety procedures) would
hinder market uptake. A compromise between standardisation/certification and market
development is needed under the umbrella of the regulation and U-space.
EASA regulation already foresees different type of users:
Open category that already includes different types of sub-categories based on
technical and operational considerations;
Specific category. For UAVs operations in the specific category, an operational risk
assessment shall be performed and associated mitigation measures shall be identified.
For the Open Category, the standardisation/certification scheme is planned to rely on aviation
legislation and product harmonisation under the New Legislative Framework (e.g. CE
16
France and Italy already demanded these two functions). 17
The SORA provides a holistic model that should guide both the operator and the responsible approving authority in establishing whether an operation can be conducted in a safe manner
30
Marking). This could potentially imply some risks in terms of safety/security, as CE Marking
could be not comprehensive enough to cover an aviation standardization/certification process,
but on the other hand, typical civil aviation procedures/certification could be to too costly and
complex. A solution to mitigate this risk, could be the development of a conformity scheme for
including at least geofencing, electronic identification and safety PVT positioning and
navigation.
For the specific and certified categories, aeronautical authorisation and certification is in
principle expected to follow typical civil aviation procedures and certification schemes.
The regulatory actions that are currently under discussion in the EU context are an essential
step creating awareness of the existing challenges and for setting the UAVs framework in the
aviation sector. Challenges are related to:
a) implementing a concept of security (e.g. encryptions, confidentiality) across the
industry and national administrations and
b) acceptance, i.e. building the confidence that UAVs use would not create security risks
for other aircraft operations.
Another challenge is to align different stakeholders’ views on how to fill the UAVs-related gaps
related to security and trust issues.
3.2.1.3 Recommended standardisation actions
Considering this framework, a range of standardisation actions are suggested for UAVs
applications and can be shown in the roadmap below. It is proposed that the regulators define
positioning requirements in close cooperation with the industry, ensuring that they are
achievable with the EGNSS technology. Then, technical analyses should be launched to solve
different open points before initiating a multi-step standardisation process. For drones of the
Open category it is proposed to consider product harmonisation based on the New Legislative
Framework (e.g. CE Marking) for ensuring geo-fencing and electronic identification functions in
regulations and U-Space while for drones of the Specific and Certified categories aviation-like
standardisation processes will be needed: UAVs inclusion in ICAO CONOPS, ICAO SARPs,
EUROCAE/RTCA MOPS and EASA Technical Standard Orders.
31
Figure 7: Roadmap and standardisation actions in UAVs
EGNSS promotion for UAVs and promotion of cooperation between regulators and
industry
Justification / Expected impact on EGNSS uptake: Regulators defining UAVs requirements
might not be aware of the performance that EGNSS could provide for this market segment, in
particular the performances achievable with GPS + Galileo in a multi-constellation context. In
the definition of UAVs requirements, it is important to define feasible requirements and for that,
EGNSS added value and expected performance need to be considered, as well as the views
and constraints by the industry. This action would mitigate the risk of the definition of UAVs
requirements not achievable with EGNSS, as well as to set requirements that are difficult to
comply with by the industry. It is key to ensure EGNSS adoption in this market segment.
Priority: High. The purpose of this action is to ensure the feasibility of the requirements in
terms of GNSS performances to be defined by regulators.
Owner: EC/GSA/ESA.
Timeframe: 2017.
Recommendation: Promote the added value that EGNSS can provide for drones and the
expected navigation performances to the UAVs community, in particular for regulators being
aware of EGNSS performance for requirements definition. It is also recommended that
32
EC/GSA promote the cooperation between regulators (EASA with SESAR references and
support, member states regulators) and the industry to consider EGNSS capabilities, so to
define feasible and realistic requirements in terms of GNSS performances in the regulations.
With this respect, a relevant starting point is EASA NPA on drones recently published.
Feasibility analysis on fulfilment of EGNSS UAVs requirements
Justification / Expected impact on EGNSS uptake: It is important to complete a feasibility
analysis to identify the impact that EGNSS can bring on the requirements to be defined by the
regulators for the different functions (navigation, geofencing, electronic identification). Showing
that EGNSS can meet the UAVs requirements is key for EGNSS market uptake.
First, the concept of electronic identification must be refined in view of U-Space or NPA to
define associated positioning requirements and to ensure they are achievable with EGNSS.
Priority: High. A technical study needs to be performed to demonstrate the performance that
can be obtained with EGNSS technology to enable the setting of adequate requirements.
Owner: EC/GSA/ESA.
Timeframe: Start in 2017, with follow-ons linked to the definition of requirements up to the end
of 2017.
Recommendation: EC/GSA should launch a feasibility analysis to understand how EGNSS
can help meeting the requirements to be defined in the regulations. Simulations with a EGNSS
demonstrator could be executed for demonstrating that EGNSS performance. Obtained
performances could be used as arguments to support EGNSS promotion (see action above).
This action could be iterative to the actions on requirements definition. Consolidated
requirements will further feed the feasibility analysis that will produce recommendations for
further consolidation of the requirements.
EC/GSA contact and monitor EASA/SESAR for GNSS requirements definition
Justification / Expected impact on EGNSS uptake: We recommend that the EC/GSA
contact EASA/SESAR to monitor the GNSS requirements definition for UAVs. GNSS
requirements for UAVs need to be defined for each drone category and for the different
functions, as a necessary step before standardisation. Monitoring these activities would help to
ensure that requirements are in line with the performance that can be obtained thanks to
EGNSS.
Priority: High. GNSS requirements must be defined for the selection of the GNSS technology
and standardisation.
Owner: EC/GSA to trigger EASA/SESAR activities.
Timeframe: In 2017.
33
Recommendation: EC/GSA monitor the definition of positioning requirements (integrity,
availability, accuracy, continuity etc.) for navigation and for the different functions defined both
in EASA regulation activities and in SESAR U-Space: electronic identification and geofencing
(as defined in EASA NPA for UAS requirements and in U-Space for UAS services) for each of
the drone categories proposed by EASA. The main goal is the definition of requirements in line
with the ones achievable with EGNSS.
Technical analyses to solve open points and feed standardisation
Justification / Expected impact on EGNSS uptake: Launching technical activities to solve
several open points is a necessary step to feed the standardisation process of EGNSS for
UAVs.
Priority: High. Different topics need to be addressed before a standardisation process for
UAV.
Owner: EC/GSA/ESA.
Timeframe: In 2017.
Recommendation: Launch technical activities to solve open points and aspects that need to
be addressed to feed the standardisation processes. The follow-up of on-going and future
technical activities will allow to define the exact scope and priorities of the technical studies
needed.
Examples:
GNSS signal vulnerabilities to interferences: One of the barriers for GNSS in the UAV
market is GNSS signal vulnerability to interferences. Galileo authentication stands out
as a promising solution to face this vulnerability;
Geofencing analyses: Geo-fencing is a critical topic since it is a function required in the
regulation and an effort should be put in this topic;
Identification of most suitable GNSS technology for UAVs (e.g. SBAS), considering
UAV design, technical and market perspectives;
Safety navigation concept adaptation from manned aviation navigation, after assessing
if the underlying GNSS integrity concept is still valid.
European Commission request for standardisation
Justification / Expected impact on EGNSS uptake: Standardisation is considered crucial for
the safe operation of UAVs, and in particular to ensure safety. A request for GNSS
standardisation at least for UAVs of Specific and Certified Category following an aviation-like
standardisation process would be needed to start the standardisation process. The regulatory
work from EASA and the SESAR work on U-Space performed recently has provided clues on
the fact that aviation-like standardisation process will be required for drones of Specific and
Certified categories.
34
Priority: High. UAVs of Certified Category will need to be standardised following aviation-like
standardisation processes to ensure safety.
Owner: European Commission to contact CEN/CENELEC, EASA, EUROCAE and ICAO.
Timeframe: 2018-2019.
Recommendation: EU request for standardisation of aviation-like process (EUROCAE
MOPS, EASA Technical Standard Orders) or push for standardisation in documents
developed by non-EU organisations (SARPs, CONOPS, Technical Standard Orders etc.) of
GNSS usage for UAVs.
Product Harmonisation for Open Category
Justification / Expected impact on EGNSS uptake: for drones of the Open Category,
product harmonisation under the New Legislative Framework (e.g. CE Marking) would be
needed for ensuring product safety, geo-fencing and electronic identification functions in
regulations and U-Space.
Priority: High.
Owner: European Commission to contact CEN/CENELEC TC5 WG7.
Timeframe: In 2019.
Recommendation: It is recommended to start the product harmonisation process (including
CE Marking as an option) for drones of the Open Category as foreseen in NPA 2017. A
certification process as the one of aviation will not be required for drones of the Open
Category in order not to add strong constraints on the market development.
EC/GSA contact and monitor ICAO for inclusion of UAVs in SARPS for drones of the
Specific and Certified categories
Justification / Expected impact on EGNSS uptake: For the drones of the certified and
probably of the specific18 categories a similar standardisation process as in aviation will be
needed since the safety and security requirements for the different functions will be more
stringent than for drones of the open category. Standardisation will be a pre-requisite for
EGNSS market uptake and as in aviation navigation the ICAO SARPs will need to be modified
for including UAVs.
Priority: High. ICAO SARPs should include UAVs for specific and certified categories.
18
For the specific category, this point is controversial and requirements definition could help to decide which standardisation strategy is the most adequate
35
Owner: EC/GSA to trigger ICAO activities.
Timeframe: In 2019.
Recommendation: The ICAO Panel devoted to drones should include in the SARPs the
standardisation for drones of the specific and certified categories, since a similar
standardisation process as for aviation navigation will be needed. EC/GSA monitoring of the
standardisation process would help for providing EGNSS inputs and ensure EGNSS
capabilities are properly considered. The concept of operations has already been developed
by the JARUS (Joint Authorities for Rulemaking on Unmanned Systems) group of experts.
ICAO will be in charge of the drones of the certified category, while it should be analysed how
to consider drones of the specific category.
EC/GSA contact and monitor EUROCAE WG 105 for the development of MOPS
standards for EGNSS UAVs for drones of specific and certified categories
Justification / Expected impact on EGNSS uptake: For the drones of the certified and
probably of the specific19 categories a similar standardisation process as in aviation will be
needed since the safety and security requirements for the different functions will be more
stringent than for drones of the open category. Standardisation will be a pre-requisite for
EGNSS market uptake and MOPS documents as in aviation navigation will need to be
developed considering specific UAVs aspects.
Priority: High. MOPS standards on the use of EGNSS for UAV will be needed at least for the
Specific and Certified categories as for aviation navigation.
Owner: EC/GSA to trigger EUROCAE WG 105 and CEN/CENELEC TC5 activities.
Timeframe: 2018-2019.
Recommendation: EC/GSA monitor the development of standards describing the equipment
for EGNSS UAV for drones of the Specific and Certified categories. New MOPS standards
describing GNSS equipment for UAVs might need to be developed from scratch or UAVs
could be included in aviation standards such as in the GPS/Galileo SBAS MOPS currently
under development by EUROCAE WG-62.
EC/GSA contact and monitor EASA for the development of European-Technical
Standard Orders
Justification / Expected impact on EGNSS uptake: Drones of the certified category will
need to follow aviation-like standardisation processes. The last step in this process are the
19
As mentioned above, for the specific category this point is controversial and requirements definition could help to decide which standardisation strategy is the most adequate
36
Acceptable Means of Compliance, Certification Specifications and Technical Standard Orders
issued by EASA.
Priority: High. For drones of the certified category a similar standardisation process as for
aviation navigation will be needed. As a last step, EASA should issue Technical Standard
Orders for the drones of the certified category.
For drones of the specific category, probably an aviation-like standardisation process would
also be needed, but this decision would depend on previous activities such as requirements
definition.
Owner: EC/GSA to trigger action by EASA.
Timeframe: In 2020.
Recommendation: EC/GSA monitor the development of EASA Technical Standard Orders for
drones of the Specific and Certified categories. E-TSO usually reference to EUROCAE MOPS
so that GNSS receivers can be certified for EGNSS usage.
3.3 Maritime
3.3.1 Navigation
3.3.1.1 The role of GNSS and EGNSS
GNSS is already widely used by the maritime industry. The installed base of GNSS devices
worldwide will increase by nearly 60% between 2015 and 2025 (from 250.000 devices to
396.000 devices)20. SOLAS (Safety Of Life At Sea) vessels and in general large vessels will
be equipped with more than one device for redundancy reasons, as well as to serve multiple
applications.
EGNSS could provide the following added value for the maritime domain:
Enhanced accuracy and availability from Galileo in a multi-constellation context;
Security coming from Galileo authentication;
Integrity provided by EGNOS.
3.3.1.2 Gaps in standardisation
The widespread uptake of GNSS for commercial shipping has raised the need for common
standards for performance, reliability and resilience across and within constellations.
Standardisation of use of GNSS is on-going. No gap has been identified for the integrity at
user level definition in maritime applications, since the technical activities are already ongoing
(The ongoing SEASOLAS project is developing an EGNOS Maritime Safety Service based on
new shipborne receivers that utilise EGNOS Dual Frequency GPS/Galileo capability) and the
20
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
37
EC and the GSA are already involved in the process. The user level integrity concept is being
investigated (even if integrity monitoring is an issue to be further investigated) and the relevant
bodies are aware of the need of test specifications that will be developed by IEC (International
Electrotechnical Commission). Standardisation actions might be necessary following the
technical analyses currently on-going.
DGNSS (Differential GNSS) is a key GNSS augmentation technology currently in use in the
maritime domain and the inclusion of Galileo in the RTCM DGNSS standard is required to
support Galileo market uptake. Being SOLAS navigation a SoL application, Galileo usage in
maritime needs to be properly standardised as a pre-requisite for its adoption.
Another trend that could foster EGNSS adoption is the development of new operational
procedures concept, which are expected to be linked to stringent requirements, where a multi-
constellation scenario could be relevant in scenarios such as restricted waters, traffic
separation scheme, port approach or for autonomous vessels.
With respect to SBAS adoption in maritime, work has been performed in the past years and
important advances were achieved, thanks to the definition of an EC/GSA Roadmap for the
adoption of EGNOS, endorsed by the EMRF (European Maritime Radionavigation Forum).
IALA has offered to provide Guidelines of GNSS augmentation systems. Moreover, IEC is
supporting the standardization of SBAS.
3.3.1.3 Recommended standardisation actions
Considering this framework, two high priority actions and a secondary one are suggested for
maritime navigation and are proposed in the roadmap below.
Figure 8. Roadmap and standardisation actions in maritime navigation
EC/GSA contact RTCM for the proper inclusion of Galileo in RTCM DGNSS standards
and monitor standardisation process
Justification / Expected impact on EGNSS uptake: DGNSS is widely used in the maritime
domain and users could need the enhanced performances that a multi-constellation system
38
could provide: enhanced availability, accuracy and resilience. These standards are focused on
GPS. Therefore, Galileo should be considered in the DGNSS standards to make available
Galileo in a DGNSS multi-constellation context and to support Galileo market uptake. It is true
that the latest RTCM standard (RTCM 10403.3) includes Galileo but it should be monitored if it
is properly implemented for its current use.
Priority: High, being a SoL application, Galileo inclusion in DGNSS standard is a pre-requisite
for EGNSS market uptake in DGNSS context.
Owner: European Commission and GSA to trigger action by the Radio Technical Commission
for Maritime Services (RTCM).
Timeframe: Starting from 2017.
Recommendation: To ensure that Galileo is included in RTCM DGNSS standards, it is
recommended as supporting action that EC/GSA contact RTCM to push for the need of
monitoring the standardisation process since this would be a key action for Galileo uptake in
DGNSS context.
The standard RTCM 10403 is being updated approximately every three years. The last
updated version, RTCM 10403.3 including Galileo was issued in 2016 and then it could be
foreseen a new updated version by 2019. It is recommended to monitor whether the Galileo
inclusion in this standard is being properly done and to identify additional topics on Galileo that
this standard should cover. An example of additional topics that could be included is the
update of the protocol RSIM (Reference Stations and Integrity Monitors).
EC/GSA contact IALA for the inclusion of Galileo in IALA DGNSS Recommendations
and monitor standardisation process
Justification / Expected impact on EGNSS uptake: Similarly to the previous action, after
including Galileo in RTCM DGNSS standards, IALA (International Association of Lighthouse
Authorities) standards would need to be updated, because they only cover GPS and
GLONASS augmentation, although BeiDou and Galileo have already been recognized by IMO
as components of its WWRNS (World Wide Radio Navigation System). RTCM standards
cover the DGNSS message definition, whereas IALA develops guidelines and
recommendations on the provision of DGNSS augmentation.
Priority: High, being SOLAS navigation a SoL application, Galileo inclusion in DGNSS
standards and guidelines is a pre-requisite for EGNSS market uptake. In particular, IALA
DGNSS Guidelines would need to be updated so to include Galileo.
Owner: European Commission and GSA to trigger action by the International Association of
Lighthouse Authorities (IALA).
Timeframe: During the year 2019, after the RTCM standardisation activity, given that IALA
DGNSS service provision is based on RTCM message standards.
39
Recommendation: To ensure that Galileo is included in the IALA DGNSS Guidelines, it is
recommended that EC/GSA contact IALA to raise awareness of the need of including Galileo
in the document and then monitor the standardisation process.
More in detail, it is recommended to update the IALA Guidelines 111221, issued in 2015, after
the inclusion of Galileo in RTCM DGNSS Standard. IALA plans the future work in slots of four
years, identifying the documents to be issued/updated. The next four-year slot will be for the
period 2018-2022. On top of updating IALA Guidelines 1112, it is also recommended to update
IALA recommendation R-135 “Future of DGNSS” so to include Galileo.
.
EC/GSA coordinate with IALA for the development of integrity within new operational
procedures
Justification / Expected impact on EGNSS uptake: The development of new operational
procedures (certified paths) enabling operations with higher capacity in the context of e.g.
restricted waters, port approach or autonomous vessels could increase the stringency of user
requirements for the GNSS performance. This is expected to reinforce the case for EGNSS
adoption in a multi-constellation context and considering safety aspects.
Priority: Secondary. Developing new operational procedures (certified path) implying the
increase of the stringency of GNSS requirements (in e.g. restricted waters, port approach or
autonomous vessels) could build a stronger business case for EGNSS in maritime navigation.
Nevertheless, we don’t find this action as critical for EGNSS market uptake since EGNSS
perspectives for maritime domain are already promising.
Owner: EC/GSA to stimulate activity at IALA and subsequently at International Maritime
Organization (IMO) level.
Timeframe: Starting from 2018.
Recommendation: To provide the user with the capability of enabling operations with higher
capacity, new harbour manoeuvres, navigation through narrow straits and difficult areas, new
operational procedures (certified path) could be proposed. It is recommended that EC/GSA
contact IALA and subsequently IMO for the development of new operational procedures and
afterwards monitor the process. It is important to understand how integrity can be integrated
within the operational concept and it is recommended to be proactive and to coordinate with
IALA, so to be able to inject integrity within activities performed at IMO level as soon as
applications become mature enough.
In this line, ESA has recently launched a project “TT AO8802- using GNSS and big data
techniques to improve safety in critical maritime operations” where the concept of certified path
will be explored. The role of EGNOS, Galileo and in general, GNSS for critical maritime
operations will be clarified. Once feasibility is proven, an objective of this activity is to provide a
21
These include recommendation R-121, which should be modified to cover Galileo
40
way forward as a roadmap. This will include a new set of mission requirements for future
European Satellite Navigation and Communications systems. These paths could be an
important advantage for pilots and an enabler for future autonomous vessels traffic operations.
It is recommended to coordinate this activity with ESA. It is therefore suggested that the EC
monitors on-going related projects.
3.3.1.4 Other recommended actions
Standardisation will certainly push for EGNSS adoption in the maritime domain. Nevertheless,
promotion of the added value of EGNOS and Galileo for the maritime domain would also help
EGNSS market penetration. Recently, in an important IMO meeting held in June 2017 it was
clarified that IMO does not need to recognise any augmentations of GNSS. IMO will only focus
on the recognition of GNSS core systems (GPS, Galileo, Glonass, BeiDou). This means that
pursuing IMO recognition for EGNOS specifically or SBAS in general is not needed.
Considering this framework, one secondary non-standardisation action is suggested to support
EGNOS for maritime navigation and is proposed in the roadmap below.
Figure 9. Recommended non-standardisation action in maritime navigation
Monitor the adoption of SBAS country by country
Justification / Expected impact on EGNSS uptake: Given the fact that IMO will not require
recognition of augmentation systems at an international level as a condition for their adoption,
it is recommended to monitor the adoption of SBAS (EGNOS) on a country by country level.
Priority: Secondary, monitoring the use of SBAS (EGNOS) country by country will ensure a
proper adoption of EGNOS for the maritime domain given the fact that IMO will not recognize
augmentation systems at an international level. It is important to point out that first,
discussions at IALA are necessary as a first step that could provide recommendations on a
country by country basis. However, these recommendations should not be imposed.
Owner: European Commission and GSA.
Timeframe: It could start after IALA and EMRF discussions.
Recommendation: Discussion at IALA and EMRF (European Maritime Radionavigation
Forum) level on this topic are on-going. It is recommended to start the monitoring of SBAS
country initiatives after these IALA/EMRF discussions. It is recommended to promote EGNOS
capabilities for the maritime domain under the umbrella of SBAS (at worldwide level), insisting
41
on the interoperability among SBAS services deployed worldwide. This promotion shall be
performed on a country by country basis, given that the AtoNs (marine aids to navigation)
providers will be the ones that may facilitate the EGNOS introduction. The nature of this
interaction (bilateral meetings, demonstrations, events…) shall be defined case by case.
3.3.2 E-Navigation
3.3.2.1 The role of GNSS and EGNSS
The e-navigation concept promoted by the IMO is a strategy to achieve increased safety of
navigation in commercial shipping through a better organisation of data exchange and
communication on ships and on shore. E-navigation includes as an option, among others, an
on board resilient multisystem PNT (Positioning, Navigation and Timing) receiver. This
receiver requires three complementary components: a core GNSS receiver, an augmentation
system and an adequate backup for GNSS system failure.
The integrity and resilience concepts are not completely defined (at user level) in current IMO
regulations/guidelines, and it is to be mentioned the need of identifying/recommending the
integrity mechanism to be implemented in the resilient multi-system receiver. As for the
maritime navigation application, on-going activities are addressing this topic. More specifically,
the IMO NCSR subcommittee (Sub-Committee on Navigation, Communications, Search &
Rescue) has developed guidelines associated to the multi-system shipborne radionavigation
receiver proposed in MSC 401(95), in line with the e-Navigation concept. These guidelines
have been finalised and approved by IMO MSC 98. From a technical point of view, there are
some aspects related to integrity/safety that are not rigorously defined and that could imply a
risk of interpretation with respect to the use of GNSS and in particular to the integrity
capabilities (EGNSS benefits). In this frame, some of the identified aspects are:
Integrity Risk definition based on RAMS (Reliability, Availability, Maintainability, and
Safety) analysis for the GNSS technology;
Relationship between accuracy and integrity;
Gaussian hypothesis of the errors distribution;
Maritime environment characterisation: multipath due to the sea, shape of boats etc.
Feared events definition in maritime domain for the GNSS systems.
3.3.2.2 Gaps in standardisation
The main identified gap for this application is the definition of a user integrity concept, given
the need to provide a resilient PNT solution. While positioning and navigation are the main
objectives of the use of GNSS in maritime navigation, some applications such as the future
multi-system, multi-sensor receiver (IMO NCSR) are defining the guidelines for the provision of
a reliable solution at user level. These guidelines already include the use of EGNOS and
Galileo, but the concept of integrity and the description of how it can be used and integrated
with data from other sensors are not mature enough.
Additionally, based also in this concept, there is a need for the definition of a timing integrity
concept. The NCSR guidelines already identify the need of a reliable and harmonised
42
synchronization between different sensors and systems, and EGNSS could be potentially used
for this purpose within the future multi-system, multi-sensor receiver.
In addition, we also propose to analyse the possibility of developing a light certification scheme
(for certifying receiver capabilities without significantly increasing their cost, in order not to add
strong constraints to the market) to harmonise the product design by maritime manufacturers
and help the interoperability among systems and in particular to ensure a minimum
understanding and implementation of GNSS in terms of integrity.
3.3.2.3 Recommended standardisation actions
Considering this framework, one high priority action and two secondary priority actions are
suggested for maritime e-navigation, as proposed in the roadmap below.
Figure 10. Roadmap and standardisation actions in maritime E-navigation
Critical Review of NCSR guidelines
Justification / Expected impact on EGNSS uptake: Perform a critical review of NCSR
guidelines, focusing on exploring the capabilities that EGNSS could potentially provide to the
maritime users.
Priority: High. This action would support EGNSS market uptake for this application.
Owner: European Commission /GSA
Timeframe: 2017-2019.
Recommendation: It is recommended to perform a critical review of NCSR guidelines,
focusing on exploring the capabilities that EGNSS could potentially benefit maritime users.
These include:
Safety analysis: refinement of the integrity concept for SoL applications.
Analysis of other EGNSS added value features (authentication, integrity):
authentication is not currently considered in NCSR guidelines
High-accuracy solution (Galileo) in a multi-constellation context
43
Timing solution for synchronization purposes: in the guidelines, it is mentioned that a
common time reference is needed, implying the need for synchronisation from the
different sensors.
NCSR guidelines are defined from a high-level point of view and the elements identified above
are the open points that need to be addressed to ensure EGNOS and Galileo uptake, with a
specific focus on the safety aspects of EGNOS for maritime22.
Once this analysis is performed, it is recommended that to foster the EGNSS adoption,
EC/GSA is involved in the maritime fora to support the standards development and to ensure a
proper use of EGNOS and Galileo.
Launch timing integrity concept analysis to feed maritime standardisation processes
Justification / Expected impact on EGNSS uptake: Timing has been highlighted as a
relevant topic by stakeholders (The automatic identification system (AIS) uses timing from
GNSS and synchronisation is needed in cooperative operations, need of robust and reliable
timing capability for the Multi-system multi-sensor PNT equipment NCSR guidelines) and a
technical study would be necessary to feed a potential standardisation process. This action
could be beneficial to support the adoption of the potential Galileo Timing service.
Priority: Secondary, timing is important in the maritime domain since AIS uses timing from
GNSS and synchronisation is needed in cooperative operations. Nevertheless, we do not
consider this action as a top-level priority since currently the main topic to be solved with on-
going activities is the definition of integrity concept of positioning – as opposed to timing - at
user level. This action is linked with T&S market segment actions since the need of a robust
T&S solution can be related to the definition of a timing integrity concept.
Owner: European Commission, GSA and European Space Agency.
Timeframe: It could start in 2018 or 2019.
Recommendation: Launch a feasibility analysis for the definition of a reliable timing concept
(integrity) to have a robust synchronized PNT solution. It is recommended to analyse the
timing need considering requirements of IMO NCSR guidelines, since in the guidelines it is
mentioned that a common time reference is needed implying synchronisation from the
different sensors. Galileo and EGNOS could play a key role in this frame.
Analyse potential certification schemes
Justification / Expected impact on EGNSS uptake: In the maritime domain, in general only
guidelines are issued and receiver manufacturers have considerable freedom for developing
their products. It seems that there could be a lack of coordination in the maritime domain, for
example IALA beacons are not recognized by IMO. This flexibility on the one hand is positive
22
These guidelines have now been completed by NCSR and passed to MSC for approval. They were expected to be approved in June 2017 meeting and published as an IMO Circular: outcomes of this meeting still not public.
44
since there are no hard constraints for market expansion but on the other hand a light
certification could help to harmonise the manufacturers design and help the interoperability.
This is especially relevant when talking about integrity and safety of the positioning as it is the
case in the e-navigation concept. The EU needs to ensure a minimum concept of safety that
ensures the proper implementation and use of SBAS solutions in maritime.
Priority: Secondary, a light certification would be helpful for EGNSS market penetration
without putting strong standardisation constraints to the market development and still giving
freedom to receiver manufacturers.
Owner: European Commission and GSA.
Timeframe: 2018-2020
Recommendation: It is recommended to study the possibility of developing a light certification
scheme (EGNOS labelling and Galileo labelling), which could be helpful for EGNSS market
penetration. In a context where manufacturers can develop and deploy widely used
technologies, even if they are not recognized by IMO, a light certification scheme may provide
device manufacturers with an opportunity to achieve technological distinction for their
products, and at the same time help EGNSS penetration, while maintaining a minimum level of
safety.
It is also recommended to focus this scheme on safety/integrity related aspects. Current
EGNOS labelling is only focused on non-integrity applications and in consequence an EGNOS
labelling concept should be extended to maritime users for which safety is relevant.
A first step would be to define exactly the scope and objectives of this light certification
scheme. To this end, it is recommended to analyse this possibility from different perspectives:
market, regulation, standardization, safety, etc.
As a second step it is proposed, based on the identified objectives, to define which is the best
option for the certification scheme.
It is important that all these actions are accompanied with promotion actions to ensure that the
concept is well-understood and to guarantee the success of the initiative.
3.3.3 Autonomous Vessels
3.3.3.1 The role of GNSS and EGNSS
Autonomous vessels are an application still under development, but considering the increase
and the development of other autonomous transport solutions (aviation, cars, etc.) it is
foreseen that it will significantly grow in the coming years. In a similar fashion to manned
vessels, GNSS is expected to cover a key role for positioning and navigation.
Additionally, the stringent needs of unmanned vessels in terms of guarantee of the positioning
(integrity) is a key enabler of the market. This is a clear opportunity for EGNSS. More into
detail, EGNSS could provide a clear added value to this application in terms of:
Authenticated services of EGNSS (Galileo and potentially EGNOS). The
implementation of authentication solutions has been identified by users as a key added
45
value for this application, to mitigate the vulnerability against interference and other
threats to meet the requirements linked to this application;
A resilient solution thanks to integrity (EGNOS), needed as in any safety-of-life
application;
Timing solution (EGNOS and Galileo) to synchronise within the different sensors of
the on-board equipment;
Geofencing to ensure secure and safe navigation for autonomous and manned
vessels.
3.3.3.2 Gaps in standardisation
No standardisation process is currently ongoing for autonomous vessels, in relation with
EGNSS. At this point in time, the main challenge is the performance of technical analyses
aimed at consolidating the autonomous vessels operation concept. In this frame, GNSS
performance requirements for this application should be defined. If requirements are proven to
be more stringent than the ones for general navigation, standardisation would be necessary. If
not, general maritime standards could be directly applied to autonomous vessels.
3.3.3.3 Recommended standardisation actions
Considering the framework above, two high priority actions are suggested for maritime
autonomous navigation, as proposed in the roadmap below.
Figure 11. Roadmap and standardisation actions in maritime autonomous navigation
Note: The second action will be only recommended, if the first action demonstrates that GNSS
requirements are more stringent for autonomous vessels that for manned vessels.
Technical analysis for autonomous vessels operational concept and requirements
definition
Justification / Expected impact on EGNSS uptake: Launching a technical activity for
defining the GNSS requirements for autonomous vessels is a first step prior to a
standardisation process. This step would be needed as a pre-requisite for EGNSS adoption
since this application is safety of life critical. This will serve to “locate” GNSS in the overall
autonomous vessels’ infrastructure and operations.
46
This action will ensure that EGNSS is well positioned as a key technology for the robust
positioning of autonomous vessels. It is important to note that European institutions need to be
proactive to guarantee that this EGNSS opportunity is well managed from the very beginning.
Priority: High, requirements definition is needed to feed GNSS Standardisation process for
this application. In the process of analysing the potential GNSS requirements for autonomous
vessels, it is proposed to launch simulations on the expected EGNSS performances, so to
define feasible requirements. Once the requirements are defined, a feasibility analysis should
be performed.
Owner: European Commission, GSA and European Space Agency
Timeframe: 2017-2019 (depending on general standardisation activity on autonomous
vessels).
Recommendation: It is highly recommended to address requirements’ definition, without
simply assuming manned navigation requirements to be applicable to autonomous vessels.
It is recommended to analyse the GNSS component within the Autonomous Vessels
application. Once the requirements are clear, it is also recommended to analyse how EGNSS
could be used and in case there is a gap, to propose potential evolutions of the EGNSS
systems, so to cover such important and emerging market. More specifically, it is
recommended to focus on the following technical aspects:
GNSS Authentication (Galileo and potentially EGNOS)
Improvement of accuracy (Galileo and EGNOS)
Provision of integrity at user level (EGNOS)
Safety analysis in line with the safety operational concept
Geofencing
It is recommended to analyse the technical feasibility and to define a powerful solution to
obtain the maximum benefit from EGNSS and from the evolution of EGNOS and Galileo. It is
important to differentiate between different versions of the systems (EGNOS V2/V3 for
example), to ensure that the timeline of the actions is coordinated with the roadmap of the
systems.
Involvement of maritime stakeholders, manufacturers and EGNSS experts is recommended.
It is recommended to launch studies (R&D) to cover previous identified recommendations.
It is highly recommended to support these actions through promotion activities.
Finally, it is also recommended to implement prototypes and trials to a) analyse the technical
feasibility of the concept proposed and b) promote/show how EGNSS could fulfil autonomous
vessels requirements.
EC/GSA to monitor the standardisation process of autonomous vessels
Justification / Expected impact on EGNSS uptake: Being a SoL application, standardisation
will be a pre-requisite for EGNSS market uptake if requirements for autonomous vessels are
47
found to be more stringent than maritime navigation requirements (if not, general maritime
navigation standards could apply).
Priority: High/medium in case autonomous vessels requirements are found to be more
stringent than general maritime navigation ones. Being autonomous vessels a SoL application,
it is necessary to standardise the use of GNSS, either by developing specific standards or by
addressing autonomous vessels in more general standards.
Owner: EC/GSA
Timeframe: It could start in 2019, after (or in parallel) to the finalization of the action on
requirements definition. It is important to remark that the start time of this action will depend on
the maturity of the standardisation activities of autonomous vessels.
Recommendation: As a minimum, it is anticipated that modifications would be needed in IMO
(International Maritime Organization), RTCM (Radio Technical Commission for Maritime
Services), IEC (International Electrotechnical Commission) and MED (Marine Equipment
Directive) standards.
It is highly recommended to include autonomous vessels within the IMO NCSR, as part of the
multi-system and multi-sensor receiver. In this respect, the IMO Guidelines recently approved
by NCSR 423 provide a first step for the aforementioned operational concept consolidation,
including specific levels of performance for automated control applications, which could be
considered as minimum requirements of the ocean and coastal applications of autonomous
vessels. It is important to note that NCSR 4 provide a very good rationale for the
definition/identification of application grades (4 Grades defined depending on the type of PNT
data needed), level of performances (accuracy and integrity) and maritime tasks/applications
and their interdependencies. We highly recommend using this work as starting point and to
provide specific inputs to NCSR working group to elaborate the autonomous vessel case.
As mentioned above, modifications needed in other standards are to be analysed. A
preliminary list of the standards to be potentially modified is included below:
ISO 22090-3 (“Use of GNSS to implement a Transmitting Heading Device”), which
specifies general requirements, construction, performance, and testing of transmitting
heading device using GNSS principle as required by chapter V, SOLAS. ISO is the
organization in charge of this standard.
IMCA M 103 (“Guidelines for the design and operation of dynamically positioned
vessels”), which complements and completes the definition of dynamic positioning
implementation. IMCA (International Marine Contractors Association) is the
organization in charge of this standard.
23
Guidelines Associated with Multi-system shipborne Radionavigation Receivers dealing with the harmonized provision of PNT data and Integrity Information
48
128MSF (“International guidelines for the safe operation of dynamically offshore supply
vessels”), which complements the IMCA M 103 with guidelines for dynamic positioning
operation. IMCA is the organization in charge of this standard.
IALA’s “World Wide Radio Navigation Plan - Edition 2”.
IALA’s NAVGUIDE Aids to Navigation Manual – 2014 – Seventh Edition.
3.4 LBS
3.4.1 5G Networks
3.4.1.1 The role of GNSS and EGNSS
The fifth generation (5G) wireless is the next evolution of mobile phone communications
primarily designed to enable a superior data communication rate. The ITU (International
Telecommunication Union) Telecommunication Standardisation Sector (ITU-T) is responsible
for 5G standardisation, although it is the 3GPP that coordinates most of the 5G specific work.
Although 5G is a communication technology, the pervasive availability of high speed and low
latency communications pose technical challenges which could benefit from widely available
accurate and reliable positioning (e.g. to allocate network resources close to the target
location), timing and synchronization, and opens the possibility of advanced LBS (Location
Based Service) which could also rely on EGNSS for positioning information, particularly in
mobility/roaming applications.
5G also poses another competitor positioning technology for EGNSS, since it will require the
deployment of a very dense network of base stations, which will allow positioning the mobile
devices with very little power expenditure and a high accuracy and availability. Nonetheless,
although the draft specifications already consider these positioning capabilities, they also
acknowledge GNSS (and EGNSS) as alternatives for several scenarios (e.g. timing for
roaming devices or positioning outside ultra-dense networks).
3.4.1.2 Gaps in standardisation
The 5G technology is right in the middle of the standardisation and definition process. As per
the schedule of the ITU-T IMT2020 process, the initial evaluation criteria and requirements
definition phases of the 5G standardization are concluded. The phase of the standardisation
process envisaging the initial submission of proposals began in October 2017 and will result in
the closing of IMT-2020 specifications in October 2020. This timeline provides a clear deadline
for all EGNSS promotion and supporting actions24 . Therefore, it would be relevant to focus on
providing early input to the emerging standards, rather than having to modify them once the
definition is closed or approved.
24
http://www.3gpp.org/news-events/3gpp-news/1674-timeline_5g
49
It should be noted that, from the perspective of 5G specification, GNSS is just one of many
enablers. The core of the 5G specification work is focused on the requirements, architecture
and communication aspects. In this frame, the EC/GSA should raise awareness of and
promote the support for EGNSS capabilities.
3.4.1.3 Recommended standardisation actions
Considering this framework, five initial actions (four high priority actions and one of secondary
priority) have been identified for 5G EGNSS standardisation, as described in the roadmap
below.
Figure 12. Roadmap and standardisation actions in LBS 5G
Promote the inclusion of signal authentication and position integrity support in the 5G
reference architecture
Justification / Expected impact on EGNSS uptake: GNSS is already considered for diverse
uses in location based services in current wireless communication networks and is already
mentioned in the draft standards (e.g. TS 23.501). Also, modern chipsets already include
Galileo support. However, to truly foster the adoption of EGNSS, the 5G networks must
support services leveraging on the differentiator features of EGNOS and Galileo, which are
positioning integrity and increased spoofing robustness. Raising awareness of these features,
50
which could be included as optional functionalities in the 5G reference architecture would be
greatly beneficial.
Priority: High. For 5G to support any of the key differentiator features of EGNSS, the core
architecture should be prepared for it.
Owner: EC/GSA. 3GPP should be addressed (ETSI is a good vector of approach, since they
are part of the core of 3GPP) and representatives from the GSA or EC should participate in
3GPP fora to promote the support of EGNSS.
Timeframe: 2017-2020. It is relevant to start this process as soon as possible, and the 5G
specification is forecasted to be completed by 2020.
Recommendation: Establish contact with 3GPP to ensure that the core differentiator features
of EGNSS are supported in the 5G architecture (particularly concerning Location Based
Services). Both integrity and signal authentication/spoofing detection should be considered in
the architecture definition. Several different levels of service could be identified:
Multi constellation GNSS
Network-based only
Network + GNSS hybrid
Moreover, the different features of the systems shall be included in both the reference
architecture specified in TS 23.501 and in the location based services requirements
specification (TS 22.071). Although positioning in the context of 5G standards is frequently
provided by the network, GNSS is also considered for certain scenarios. By adding support for
integrity and signal authentication in the architecture and location services definition, location
based services can leverage on said functions. This would foster the adoption of EGNSS.
It is also relevant to survey TS 38.455, NG-RAN; NR Positioning Protocol A, although at the
present stage it is an unreleased draft. The technical study aims to define the network
resource positioning protocol. In this frame, EGNSS support for “edge” scenarios or scenarios
outside of network coverage (relying on device-based rather than network-based positioning)
or ad-hoc network scenarios could integrate support for integrity and signal authentication.
This action could be an extension of the action 2 on 5G of the current Rolling Plan for ICT
Standardisation, with a specific focus on the area of GNSS.
Analysis of the suitability of EGNSS for synchronization of 5G network elements
Justification / Expected impact on EGNSS uptake: GNSS is already under consideration to
synchronise 5G elements outside the edges of the 5G network, in roaming mode or when
starting operation. The EC should emphasize the added value of EGNOS/Galileo:
Interoperable with GPS;
Improves resilience by using multiple constellations;
Increased robustness to spoofing (which may have a relevant impact in security critical
applications, infrastructure management and financial applications).
51
It is important to share with the 5G community the added value of EGNSS for this application.
Priority: High. Timing and synchronization is an application area on top of location, where
EGNSS can contribute within 5G.
Owner: EC/GSA, should monitor the 5G standards development to ensure that EGNSS is
considered as a timing reference for 5G communications, particularly for devices outside of the
network coverage or in roaming mode. If this is not the case, ETSI should be addressed to
promote their consideration.
Timeframe: 2017-2020
Recommendation: To ensure that EGNSS is considered as one of the timing information
sources (particularly for elements not connected directly to the communication network) and to
generate verifiable timestamps, the EC should contact 3GPP, to promote:
The adoption of GNSS as timing source; and
The use of EGNSS, due to the improvements in the clock when compared to other
solutions.
Although the timing and synchronization topic will likely be covered in many specifications, it
should be considered at the very least for:
TS 23.501 specifying the reference architecture;
TS 33.501 providing the security architecture and procedures for 5G.
In the context of TS 23.501, timing and synchronization of network elements will be very
relevant, particularly for elements roaming outside the core network and for ad-hoc
connections between mobile devices (which are also considered within the scope of 5G). In
the frame of TS 33.501, synchronization is relevant to validate timestamps, certificates and
token expiration times. Therefore, GNSS synchronization could play a relevant role in both
standards.
Update 3GPP/ETSI standards to change the selection of the priority for GNSS
constellations in LBS
Justification / Expected impact on EGNSS uptake: Existing standards such as 3GPP TS
45.005 and TS 36.171 give priority to the GPS constellation for the selection of satellites to
calculate the position, even in the case of other constellations being available with better
signals. Thus, Galileo satellites are rarely used for the calculation of the position within
smartphones, even though chipsets compatible with Galileo are available. It is worth stressing
that the current specifications have been drafted so to prioritise GPS because of the reliability
that the system has shown over more than 20 years, which makes it a “safe” choice for chipset
manufacturers to rely on.
Priority: High. Together with implementation choices by chipset manufacturers, standards are
limiting the actual use of Galileo in mobile devices.
52
Owner: the European Commission and the GSA, in cooperation with ESA, should address (if
needed through ETSI/CEN CENELEC) 3GPP, and more specifically Working Group 4 under
the Radio Access Network (RAN) Technical Specifications Group (TSG).
EC/GSA should promote the adoption of an approach aimed at considering all GNSS equally,
and base usage on operational criteria (such as signal-noise ratio, number of satellites in view,
etc.).
Timeframe: 2017-2019 The action should start as soon as possible, with updates that could
take place alongside the standard 5G definition process which is currently ongoing and is
planned to last until the end of year 2020 (as mentioned in Section 3.4.1.2).
Recommendation: To update the technical specifications of these standards, along with the
ones that will be drafted for 5G, to the current GNSS landscape, so that no specific system is
given preference.
The main argument should be that whereas in the past the definition of GPS as primary
constellation in the standards could be reasonable, given the limited availability and low
maturity of other GNSS, nowadays with more fully operational systems available for the public,
the distinction is only hampering the adoption of the non-GPS systems and limiting the
effectiveness of the overall satellite positioning solutions, since priority is being given to GPS
satellites by default when those of a different constellation may provide better operating
conditions.
In parallel with the standardisation action outlined above, the continuation of ongoing activities
to facilitate Galileo implementation in mass-market devices is a necessary complement to the
standardisation action.
Contribute to the definition of Network Functions Virtualisation (NFV) security
Justification / Expected impact on EGNSS uptake: One of the most relevant aspects of the
upcoming proposed 5G architecture is that many functions of the network will not be managed
directly by dedicated hardware, but rather virtualized in general purpose, powerful hardware.
This opens many issues that were not of concern in prior specifications, and among them one
is how to ensure that a network function is provided in a specific area and time, as defined in
the terms of service. For example, sensitive data might not be allowed to leave a specific
region, or the servers caching should be hosted close to the destination location to minimize
latency. To enforce such contracts, a location stamping scheme is required (much like
timestamps are currently used to certify transactions). To solve this issue, the work item (i.e.
standardisation task) ETSI GR NFV-SEC016 aims to determine how the location of sensitive
Virtual Network Functions (VNFs) can be attested.
In this area, the enhanced security and signal authentication features of Galileo are not only a
differentiator, but a real enabler, providing a direct solution to the problem, which does not
require alternative or complex physical location binding schemes. A Galileo receiver paired to
53
the virtualization hardware can be used to certificate the location of the executing resources,
and the signal authentication functionality could be used afterwards to verify the location
claims.
Priority: High. This is an area where Galileo offers a clear differentiator, and the techniques
explored in ETSI GR NFV-SEC016 can be extrapolated to other location based services than
just NFV (such as critical infrastructure operation).
Owner: GSA, should follow and support ETSI progress.
Timeframe: 2017. The work item schedule details that work started on February 2017 and is
scheduled to finish on December 2017.
Recommendation: The GSA should contact the supporting organizations, provide relevant
documentation, follow and support the development of ETSI GR NFV-SEC016, highlighting
the key differentiating features of Galileo against other solutions and using the results to
promote the timing and location stamping of Galileo in other areas.
Define a voluntary certification scheme for positioning performance
Justification / Expected impact on EGNSS uptake: Although most modern smartphone
chipsets support Galileo (all Qualcomm mid and high-range chips since 2016, mid and high-
range Mediatek chipsets since 2017), it is necessary to also include the appropriate software
and leverage on the chipset capabilities to provide actual EGNSS support in devices.
At the time of writing despite the large hardware base supporting Galileo, the lack of
appropriate firmware exploiting such capabilities has led to an irregular situation where only a
high-end models do support Galileo (currently iPhone 8, BQ Aquaris V and X range, Google
Pixel 2, Huawei Mate 9 and 10 and P10, LG V30, Mediatek MeizuPro 7, Nokia 8, Oneplus 5,
Samsung Galaxy S8, Sony Xperia XZ Premium, Vernee Apollo 2, also pro or + variants of the
models25) with several large manufacturers missing (LG, Motorola, HTC)..
In the current scenario, the definition of different levels of performance that could determine
the type of LBS supported could be beneficial to promote the adoption of EGNSS and highlight
the added value of the European systems, as compared to the other positioning solutions.
Given the level of saturation of the market, support for Galileo could be a differentiating factor,
particularly for high-end devices. The EC has already begun work on positioning certification
with EGNOS, through a project called EGNOSLAB26. The work should be extended so to also
cover Galileo.
25
Source: www.usegalileo.eu, November 2017 26
EGNOS Enabled Labelling and SDK Validation, funded by the European Commission
54
Priority: Secondary
Owner: EC/GSA. CEN would be the most relevant target SDO (Standardisation Organisation),
given that it was already involved in the EGNOSLAB project, which was referenced to
generate CWA 16874:2015.
Timeframe: 2017-2019. Given that some work on EGNOS certification has already been
performed, and that certification is not specific to just 5G devices, the Galileo certification
scheme could be defined without waiting for 5G specifications. If a specific requirement is
determined during 5G definition, it can be integrated in the certification scheme in a second
phase.
Recommendation: Develop a standardised technical verification procedure to assess the
positioning capabilities of mobile devices if using optimally the Galileo signals.
In such procedure, define also a voluntary certification scheme to obtain different performance
levels in terms of key user requirements (accuracy as key requirement, but also availability,
continuity, integrity information support and spoofing detection) to be achieved based on the
verification results, meaning that different scoring could be provided to award the achievement
of different levels of performance.
In this process, ensure that the voluntary certification scheme complies with the accreditation
rules governing the authorization of testing laboratories by accreditation bodies across the EU
(e.g. compatibility with ISO/IEC 17065 and compliance with EA-1/22) and that the system
performance tests for the selected architecture options and associated operational conditions
(covering an “end to end” performance rather than just the navigation component itself)
adhere to the CWA 16874:2015 specification by CEN and future similar specifications for
Galileo, once developed.
3.4.2 IoT
3.4.2.1 The role of GNSS and EGNSS
The Internet of Things covers a huge range of industries and use cases that scale from a
single constrained device up to massive cross-platform deployments of embedded
technologies and cloud systems connecting in real-time. As defined in the ITU-T Y.2060, IoT is
a global infrastructure for the information society, enabling advanced services by
interconnecting (physical and virtual) things based on existing and evolving interoperable
information and communication technologies.
Given that the industry has led the development of IoT technologies before relevant standards
were put in place, there are plenty of IoT solutions already in the market different approaches
(from the reference architecture to the communication protocols) and specific user base. This
makes the definition of industry-wide standards difficult.
Within the scope of IoT, GNSS is a type of sensor that provides a time and location reference.
However, within the range of sensors that can be integrated in the IoT, GNSS is particularly
55
relevant, because it allows defining a context, as well as to observe relationships among the
readings of other sensors which share a common location.
3.4.2.2 Gaps in standardisation
At the time of writing, most IoT standards only use the location information, and do not provide
any additional information regarding the reliability of the position, nor do they support the
possibility to handle the information (integrity/authentication), providing some level of accuracy
information at best. This applies to all considered information exchange and sensor description
standards (OGC SensorThings API, OMA-TS-LightweightM2M, Semantic Sensor Net
Ontology, etc.).
3.4.2.3 Recommended standardisation actions
Considering this framework, two high priority actions and three secondary priority ones are
suggested for IoT, as proposed in the roadmap below.
Figure 13. Roadmap and standardisation actions in LBS IoT
Analysis of the minimum performance requirements, use cases and application
scenarios
Justification / Expected impact on EGNSS uptake: Whereas GNSS is already considered
in the sector, in the available standardisation documentation it is merely seen as one of
several multiple available positioning information sources. A study surveying the different IoT
application areas, and providing a set of use cases with minimum performance requirements
would contribute to identify areas where the enhanced features of European GNSS can
provide clear advantages, so to foster its adoption in the industry.
56
Priority: High. This analysis can set the basis for defining how and in which cases the
additional features of EGNSS can become differentiating factors.
Owner: GSA and European Space Agency.
Timeframe: 2017-2018. This should be one of the initial tasks before further GNSS
standardisation can take place, so it needs to be performed quickly.
Recommendation: Launch technical activities to solve the open points mentioned below:
Minimum positioning performance requirements applicable to IoT applications;
Definition of liability critical and safety of life scenarios;
Timing and synchronization requirements of IoT applications;
Generation of time and location stamps associated to other sensor records.
A study covering positioning and timing requirements could be funded within the scope of
H2020 or be supported by the GSA. Such study would be required to set the basis for the rest
of the actions.
Promote the inclusion of signal authentication and position integrity support in the IoT
reference architectures
Justification / Expected impact on EGNSS uptake: As mentioned before, GNSS is already
considered in IoT solutions, but only at a basic level, as a sensor. There is little room in current
standards to leverage the expanded functionalities of EGNSS compared to other systems.
To fully exploit the added features of EGNSS in IoT applications it is necessary to review the
reference architectures defined by the different Standardisation Organisation (SDOs) and to
support them, by providing technical insight on how to model integrity information and support
its usage end-to-end (from receiver to application) when supported, even if the functionalities
are not mandatory.
Priority: Secondary. For IoT to support any of the key differentiator features of EGNSS, the
core architecture should allow managing integrity and signal authentication at all levels of the
architecture (i.e. from receiver level to the application level), and on the information exchange
protocols between IoT devices (if the capabilities of the device allow for it).
Owner: EC/GSA. Given the wide range of IoT initiatives, there are several SDOs to be
addressed, as listed below. Given that ETSI and AIOTI, are both European organizations with
participation in OneM2M, which is one of the most relevant IoT architecture definition
standards, both organizations should be approached to include optional support for integrity
and signal authentication status in the definition of the architecture, logical elements and
information exchange protocols.
Timeframe: 2018-2020. Work on this area should begin after the initial studies are complete.
57
Recommendation: Establish contact with the different groups (IETF (Internet Engineering
Task Force), IIC (Industrial Internet Consortium), OMA (Open Mobile Alliance), OGC (Open
Geospatial Consortium), AIOTI (Alliance for Internet of Things Innovation), OneM2M) and
standardisation organizations (IETF, ETSI, ISO) to ensure that the core differentiator features
of EGNSS are supported in the definition of their IoT architecture. Both integrity and signal
authentication/spoofing detection should be considered in the architecture definition. Some of
these reference architectures include:
OneM2M TS-0001-V2.10.0 (of which ETSI is one of the founding partners). This
specification is already well defined, and includes detailed information on how to
manage location. However, it only mentions GPS (among the multiple GNSS) as
positioning information source, and the current iteration does not support location
integrity information in the data structures defined in the reference architecture, so it is
a relevant gap that needs to be addressed.
ISO/IEC 30141 reference architecture, by the ISO/IEC JTC 1 WG10. The standard is
still under development, so it provides a good opportunity to address ISO and allow for
support of EGNSS features.
AIOTI WG03 High Level Architecture is very generic, and thus places no constraints in
the positioning aspect of IoT, however, future changes to the specification should be
monitored to ensure integrity and signal authentication are still supported.
Promote the use of EGNSS for synchronisation in IoT applications
Justification / Expected impact on EGNSS uptake: Although only a fraction of IoT devices
will be fitted with a GNSS receiver, those that will, could benefit from the enhanced timing
capabilities of EGNSS. Additionally, these devices could act as a time reference and
disseminate timing information through the IoT communication networks. This promotion
action is important to support EGNSS market penetration.
Priority: Secondary. Although not every IoT device will be fitted with a GNSS receiver,
EGNOS and Galileo enhancements as a time reference make them desirable for those more
expensive devices in charge of providing a time reference.
Owner: European Commission, GSA.
Timeframe: 2018-2020. Work on this area should begin after the initial studies are complete.
Recommendation: Mechanisms to synchronize IoT systems need to be designed, and GNSS
is particularly suited to support this task, due to availability and accuracy. The EC and GSA
should contact the main SDOs in charge of the definition of the core IoT architectures and
promote the use of EGNSS for providing time-reference for devices fitted with a suitable
receiver and the relay of EGNSS timing information to devices without GNSS capabilities.
Relevant standards and organizations have been identified above, but are included here for
the sake of completeness:
ISO/IEC 30141 reference architecture, by the ISO/IEC JTC 1 WG10;
AIOTI WG03 High Level Architecture;
OneM2M TS-0001-V2.10.0 (of which ETSI is one of the founding partners).
58
Promote support of Integrity and signal authentication in M2M communications
Justification / Expected impact on EGNSS uptake: A large part of the standardisation work
in IoT involves enabling M2M communications and solving interoperability issues between
different technologies and even physical channels. To be able to understand and apply the
integrity and signal authentication information in IoT applications, it is first necessary that
standards allow different devices to exchange the information with each other so that it can be
understood and processed by both ends of the communications.
This action should be covered in future versions of the Rolling Plan for ICT Standardisation, as
an extension of the current Action 3 for IoT, but in this case focusing on adding support for
EGNSS features on standards for semantics for data interoperability.
Priority: High/Medium. This action is mandatory to leverage the Integrity and signal
authentication capabilities of EGNSS in IoT applications. If the information cannot be
transmitted among devices or understood in both ends of the communication (even if only one
of the devices has location capabilities) then the provided context information cannot be used.
Owner: European Commission, GSA.
Timeframe: 2018-2021. Once the analyses of the minimum performance requirements, use
cases and application scenarios proposed for the first action are complete, work on adding
support for these features within information exchange standards should begin.
Recommendation: The GSA should address SDOs and IoT organizations to raise awareness
of the added-value capabilities of EGNSS, so that the functionalities can be supported in IoT
applications.
Although most IoT M2M standards do support a position information element, the information
structures do not support any field for integrity information or signal authentication status.
Given that most of them are designed to be future-proof and support custom fields, it should
be relatively easy to expand the ontologies so that devices and systems with capability to
process them can use the additional information.
Identified SDOs and relevant standards include:
OneM2M by ETSI. OneM2M not only defines a reference IoT architecture, but also the
information exchange format and protocol. However, at the time of writing it only
considers GPS among all available GNSS and thus does not support neither integrity
nor signal authentication.
SensorThings API by OGC. SensorThings is an open standard providing semantics
for interoperability among IoT devices. It does not, however, support yet signal
authentication or integrity information, so it would need to be expanded to define
adequate data types for M2M information exchange.
OMA LightweightM2M by the Open Mobile Alliance is a communication protocol for
the interaction between a LWM2M Server and a LWM2M Client, located in a IoT
59
device. The protocol supports plain text/JSON/TLV fields, which could theoretically
host integrity and signal authentication information. However, said fields are open and
left to the implementation of each manufacturer, which is less than ideal to support
interoperability. To be able to automatically process the EGNSS information if it was
available/present and leverage on said information to provide any kind of service, it
would be required that the resource observation fields support the
integrity/authentication information in the defined messages and fields, even if it is only
optional and may not be included in every implementation.
It would be beneficial to approach the organizations with an already defined proposal, which is
coherent with the current formats of the protocol and includes all the information deemed
relevant, as identified in the preliminary studies.
Definition of time and location stamps for liability critical or safety critical applications
Justification / Expected impact on EGNSS uptake: In the same fashion of 5G applications,
for several application fields it might be relevant to provide a verifiable time and location
stamp, which provides context to other information (e.g. readings of a set of sensors
monitoring critical infrastructure or sensible goods). Galileo allows the provision of such
verifiable location and time reference27.
Priority: Secondary. It is likely that this capability will come from other areas, such as 5G, and
will be then applicable to IoT. Nonetheless, there are applications where it may have
relevance, such as insurance or liability critical applications.
Owner: European Commission, GSA
Timeframe: 2019-2021. It is not a high-priority task, efforts should be devoted first to the other
identified actions. The application of the Network Function Virtualization (NFV) standard to IoT
can be performed after the initial study is finished.
Recommendation: The EC/GSA should address ETSI and follow the development of the
ETSI GR NFV-SEC016 report, highlighting the key differentiating features of Galileo against
other solutions and using the results to promote the timing and location stamping of Galileo in
different application areas.
27 Please, do note that we are not considering EGNSS as a time reference for synchronization and operation of
infrastructures. Such use is covered in more detail in Section 3.9. The usage proposed for IoT is simply restricted to
the signature of pieces of information with a verifiable location/time stamp, so to ensure that the information is
relevant to a given place/time.
60
3.5 Road
Road is the second largest market segment in terms of installed base and the most relevant in
terms of revenues, and EGNSS has good uptake perspectives, closely related to the eCall
regulation (which has been covered in other studies) and will require the mandatory integration
of an EGNSS receiver in the vehicles. Additionally, applications in the road sector have a large
amount of overlap, meaning that standardization actions in one specific application area can
also be applied to others, multiplying their impact.
In particular, in the case of ADAS (Advanced Driver Assistance System), autonomous driving
and Cooperative ITS (Intelligent Transport Systems) there are significant synergies and
technology overlaps, which should be exploited for the common actions defined in all three
sectors:
Definition of integrity model for the road domain, which would be common for all three
applications (although different levels of performance might be required for different
applications)
Definition of a voluntary positioning performance certification scheme, which would be
limited to the in-vehicle system for ADAS and some Autonomous Driving (AD)
implementations and consider the transmission of the information for C-ITS and
collaborative implementations of AD (Autonomous Driving).
3.5.1 Tracking of Hazardous materials
3.5.1.1 The role of GNSS and EGNSS
Tracking and tracing of hazardous materials and goods is a regulated application. As such, the
introduction of GNSS and other technologies is subject to the inclusion in the relevant
legislation. Dangerous Goods Transport for Road is regulated by the European Agreement
concerning the International Carriage of Dangerous Goods by Road (ADR). The rules are
defined by UNECE (United Nations Economic Commission for Europe).
At the present state, no requirements for the use of GNSS or the transmission of positioning
information are included in the ADR; however, GNSS-related aspects are currently being
discussed by the Informal Working Group on Telematics within the Working Party 15 (WP.15)
on the Transport of Dangerous Goods, in the frame of the activities to support further
digitalisation of transport documentation and electronic exchange of information through
telematics.
The work of the Informal Working Group has not resulted yet in the update of the ADR, despite
having been started more than five years ago, due to the need to reach consensus between
the Contracting Parties.
3.5.1.2 Gaps in standardisation
While legislation is not in place, standardisation involving also EGNSS is already well
developed.
A data exchange protocol, based on DATEX, has been defined and is being further refined in
the frame of the UNECE Informal Working Group on Telematics. Among the extensions
61
proposed for the protocol, based on the outcomes of CEN Workshop Agreement 16390, a
non-mandatory field on the location was introduced including GNSS positioning, as well as the
Horizontal and Vertical protection levels, as means to introduce EGNOS (albeit current HPL
and VPL provided by EGNOS are not particularly well suited for the road environment). The
inclusion of multi-constellation and Galileo (as well as GLONASS) is also being discussed
within the same data exchange protocol.
A relevant standard in the frame of the application is ISO/TS 15638-1828, developed and
updated by ISO/TC 204 Intelligent Transport Systems. Since the Technical Committee is
cooperating with UNECE Working Party 15, the Committee doesn’t need to be addressed
directly. GNSS is not specified as the positioning technology, but it is mentioned in the
examples and use cases, as it is the most likely positioning method.
Also relevant is the ISO 17687:2007 Transport Information and Control Systems (TICS) –
General fleet management and commercial freight operations – Data dictionary and message
sets for electronic identification and monitoring of hazardous materials/dangerous goods
transportation. It supports the application of identification and monitoring of dangerous goods,
although it does not specify any positioning technology.
3.5.1.3 Recommended standardisation actions
Based on the framework above, one secondary priority action is suggested for the application,
as shown in the roadmap below.
Figure 14. Roadmap and standardisation actions in Tracking of Hazardous Materials
Contribute to the ongoing process on introduction of telematics at UNECE level
Justification / Expected impact on EGNSS uptake: The finalisation of the activities and
process at UNECE level would create the legal basis for the introduction of telematics, support
the use of GNSS and introduce the standards involving EGNSS.
Priority: Secondary – the contribution by the European Commission would be desirable in the
frame of an already ongoing process.
28
Intelligent transport systems -- Framework for cooperative telematics applications for regulated commercial freight vehicles (TARV) -- Part 18: ADR (Dangerous Goods)
62
Owner: European Commission - DG MOVE is the main actor due to the activity falling in the
field of transport and ITS.
Timeframe: Starting from second half of 2017 to the finalisation of the process.
Recommendation: Contribute to the ongoing process at UNECE level, promoting the added
values of EGNSS and facilitating the inclusion of multi-constellation and in particular Galileo in
the data exchange protocol standards.
Due to the very different positions of the UNECE Contracting Parties, it is suggested that
pushing for mandatory introduction of both tracking and EGNSS could prevent from achieving
a final consensus. Hence, promoting a softer approach envisaging a non-mandatory
introduction in the context of the overall process of introduction of telematics is deemed more
suitable.
The final goal would be to have the results of the work carried out by the Informal Working
Group on Telematics accepted for inclusion in the biennial update cycle of the ADR.
3.5.2 ADAS
3.5.2.1 The role of GNSS and EGNSS
Advanced driver assistance systems (ADAS) are systems developed to improve safety and
road travel by automating functions of the vehicle and enhancing vehicle systems. As there
are overlaps between ADAS, Autonomous Driving and Cooperative ITS (C-ITS) technologies,
the following distinction is adopted in the frame of this analysis:
ADAS encompass all systems up to the level 2 of automation (i.e. driver assistance
and partial automation), as defined in SAE (Society of Automotive Engineers)
International standard J301629;
Autonomous Driving covers systems from level 3 to level 5 of automation under the
same classification, i.e. from conditional to full automation;
C-ITS include, following ETSI approach, communications-related applications intended
to increase travel safety, minimise environmental impact, improve traffic management,
also by supporting ADAS or Autonomous Driving technologies.
Based on the above, the standardisation analysis and recommendations cover up to level 2 of
automation in the ADAS section, automation from level 3 to 5 in the Autonomous Driving
section and the communication part in the Cooperative ITS Section.
Within ADAS, GNSS plays an important role for Navigation systems, V2V (Vehicle-to-vehicle)
or V2I (Vehicle-to-infrastructure) integration, Emergency Driver Assistance, Collision
Avoidance Systems, Collision Warning, etc. The installed base of GNSS devices for ADAS is
29
See https://www.sae.org/misc/pdfs/automated_driving.pdf
63
expected to grow from 14 million units in 2015 to almost 70 million in 2020 and 85 million in
202530.
EGNSS is expected to be widely used to support ADAS, due to the added value in terms of
availability in a multi-constellation context (Galileo) for difficult environments such as urban
canyons, etc. Receivers are EGNOS ready, and new automotive receivers manufactured by
industry leaders such as Qualcomm, u-Blox, ST Microelectonics, Mediatek and Furuno already
support Galileo31. Galileo authentication is also expected to be important for this application.
The main decision makers in this application are automotive manufacturers, Tier 1 suppliers
and receiver manufacturers.
3.5.2.2 Gaps in standardisation
Although there are plenty of solutions in the market without completely defined standards
(apart from pre-existing safety regulations), there are some standards applicable to the field of
ADAS where EGNSS could play a role. The standards in general do consider location
information to some degree, while none include definitions for the management of
signal/position integrity or spoofing resilience. In this respect, the only referral to the level of
confidence in the position found is included for eCall in Draft Standard ISO/FDIS 15638-10,
being voted between March and May 2017.
For ADAS purposes, it should be underlined that GNSS is accurate enough when
augmentation techniques are used, particularly if the position is used to calculate the relative
position among elements (other moving vehicles, reference stations in the infrastructure, etc.)
but the whole integrity concept (the protection level approach, the integrity algorithm, the PVT
(Position Velocity and Time) error modelling in challenging scenarios, performance levels… )
as defined for aviation needs to be revised, since it is not directly applicable to the road
scenario. EN 16803-1 published in October 2016 provides an initial approach to performance
for ITS systems based on GNSS, and is currently being revised as part of the GP-START
project to improve some of definitions (how the PVT error is modelled, longitudinal and cross-
track components of position error, specify the integrity risk computation procedure…) and
include additional required metrics, such as continuity or protection level availability.
Also, suitable performance level categories for ITS applications need to be defined according
to the performance of the positioning equipment, combining accuracy, availability, the integrity
algorithm, the protection level and protection level availability performances to determine
whether the equipment is fit for the intended application. As such, the fact that this area is not
covered in ADAS standards (it is only covered in eCall) represents a standardisation gap. In
this context, the definition of the integrity concept for road applications should be further
analysed.
30
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf 31
Source: www.usegalileo.eu
64
Another outcome of the gap analysis is that a standard covering GNSS resilience against
jamming and/or spoofing for road applications is missing.
3.5.2.3 Recommended standardisation actions
Based on the above considerations, the following roadmap is suggested for ADAS.
Figure 15. Roadmap and standardisation actions in ADAS
Definition of the integrity concept for Road
Justification / Expected impact on EGNSS uptake: Although it is partially covered by EN
16803-1, the work on the definition of an integrity approach suitable for road applications
should be further analysed. The aviation approach used to apportionate the risk is far from
optimal in the perspective of non-aviation applications. The “specific risk assessment” built in
SBAS to meet civil aviation specific needs penalizes non-aviation users in term of size of the
resulting protection levels (and so, in terms of availability). This action is important for the
different road applications since being safety of life (SoL) critical, the integrity concept must be
carefully defined.
Priority: High, this action is necessary to maximise the added value of EGNOS for ADAS (and
Autonomous Driving). This action is also applicable to other areas of the road domain,
autonomous driving and cooperative ITS in particular, so particular effort should be made to
coordinate efforts between application areas.
Owner: EC should work with CEN/CENELEC and continue the efforts of the GP-START
project to provide a more complete definition for integrity management on road applications,
improve PVT error modelling in challenging scenarios, and defining the performance levels on
the accuracy, availability and integrity aspects. Given that there is no road equivalent of ICAO
or IALA, CEN/CENELEC TC5/WG1 (which is in liaison with CEN TC 278) and ISO TC20 SC14
WG1 (which is in liaison with ISO TC 204) are the two most suitable groups to address this.
65
Timeframe: 2017-2018. It is urgent to close this definition as soon as possible, since the
inclusion of the integrity concept for road applications in other standards would depend on this
one.
Recommendation: Adequate integrity and protection level definitions should be provided both
at user-service level (the needs of the user service for the location system) and operation level
(integrity risk, continuity risk, alarm limit, protection levels) for ADAS applications (1d/2d,
horizontal or along/cross-track, vertical error, etc.).
The exact definition varies based on the different applications. 1D along-track might be
enough for platooning/cruise control, whereas 2D minimum is required for collision avoidance
or automated lane change.
The GSA 2015 report on the performance and level of integrity for safety and liability critical
multi applications could be a good starting point32, since it provides categories of applications
with their operational requirements. A future task for the Rolling plan on ICT Standardisation
would be classifying ADAS in these categories to set their operational requirements and
validate the suggested protection levels for each application.
Update ISO standards on the exchange of information between vehicle components
Justification / Expected impact on EGNSS uptake: To leverage the additional capabilities of
EGNSS rather than only the additional availability coming from more satellites in view, it is
necessary to include support for the integrity of the position information and the signal
authentication/spoofing detection status in the location element of the information exchange
protocols between the different components of the vehicle.
ADAS applications rely on a combination of on-board sensors and GNSS to provide several
assistance services to drivers. Being able to detect spoofing on the vehicle positioning system
or that positioning information is unreliable and an estimation of the time to alarm would
greatly enhance the reliability of the systems and contribute to demand human interaction or
takeover if required.
Exact details on the operation when the positioning information cannot be trusted depend on
the specific application. E.g. a speed warning system may not be as critical as an obstacle
detection system or an adaptive cruise control, and the need for takeover would also depend
on the availability and reliability of additional sensors.
Priority: High, this action is important for making room to EGNSS differentiating features.
Owner: The European Commission and the GSA should address CEN/CENELEC, with the
final objective of getting in touch with ISO Technical Committee 204 on Intelligent Transport
32
https://www.gsa.europa.eu/sites/default/files/calls_for_proposals/Annex%202.pdf
66
Systems, so to review the current in-vehicle communication protocols and expand the
message format to add the minimum set of information required to support signal
authentication and integrity.
Timeframe: 2017 to 2021. The ISO review cycle for standards is of 5 years. Although
sometimes corrigenda are published in-between, it is not often. Given that ISO 15075:2003
was recently reviewed on 2016, and other related ADAS standards are currently under
revision or being replaced by new iterations, the whole range of standards should be revisited
by then.
Also, the beginning of the action should leverage on the protection level definitions for the road
sector, but we could potentially miss standards that are undergoing definition now (such as
ISO/DIS 15622, to replace ISO 15622:2010).
Recommendation: Define the minimum set of information required to support signal
authentication and integrity information in ADAS applications. Review the current in-vehicle
communication protocols and expand the message format to add the identified information.
Also review the existing standards at receiver level. The coordination between the actions
taken at application level (ISO TC 204) and those at receiver level (NMEA) will be key to
support the adoption of EGNSS for road applications.
Follow the revision cycle and development of relevant ISO TC 204 standards to include
support for signal authentication and integrity information in the different ADAS applications.
Relevant standards identified are:
ISO 15075:2003 Transport information and control systems -- In-vehicle navigation
systems -- Communications message set requirements, last reviewed and confirmed in
2016, next revision slot scheduled for 2021.
ISO 15623:2013 Intelligent transport systems -- Forward vehicle collision warning
systems -- Performance requirements and test procedures, published in 2013, revision
should begin 2018.
ISO 18682:2016 Intelligent transport systems -- External hazard detection and
notification systems -- Basic requirements, published in 2016, revision scheduled for
2021.
ISO 11067:2015 Intelligent transport systems -- Curve speed warning systems (CSWS)
-- Performance requirements and test procedures, published in 2015, to be reviewed in
2020.
ISO/DIS 15622 Intelligent transport systems -- Adaptive cruise control systems --
Performance requirements and test procedures, currently under development, replaces
ISO 15622:2010.
Although the current Rolling Plan for ICT standardisation does include actions regarding
interoperability (both in-vehicle and among vehicles and infrastructure), emphasis should be
put in future releases in adding support for EGNSS features, such as integrity and spoofing
robustness. These actions would contribute to achieve the goal of providing more effective and
advanced safety applications (by enriching and improving location information).
67
Define a voluntary certification scheme for positioning performance
Justification / Expected impact on EGNSS uptake: ADAS is not expected to be one of the
main drivers for the inclusion of EGNSS in vehicles. The implementation of eCall Regulation
and the development of new features, such as in-car navigators and autonomous driving (also
as an enabler for C-ITS applications) will have a greater impact on EGNSS market uptake.
Nonetheless, since the GNSS will be there in the vehicle, and the ADAS can benefit from the
positioning information to improve their operation, it could be beneficial to promote the
adoption of EGNSS in a multi-constellation environment, to define different levels of
performance that could highlight the added value of the European systems compared and in
addition to the other solutions of the market.
In a similar way to Euro NCAP (European New Car Assessment Programme), which is a
voluntary vehicle safety rating system (backed by the EC), the definition of a certification
scheme evaluating the performance of the integrated ADAS systems and in particular the
positioning performance components could foster the inclusion of EGNSS in the vehicles,
particularly in the high-end segment, which would benefit from the additional reliability as a
differentiator against other lower-end solutions.
Priority: Secondary. This action is also applicable to other areas of the road domain, namely
autonomous driving and cooperative ITS, so effort should be made to coordinate efforts
between these application areas.
Owner: EC. ETSI would probably be the reference standardisation organization, since they
have already defined the ETSI TS 103 246-5 standard on performance test specifications for
GNSS based location systems, which could be used as a basis for the certification scheme.
Timeframe: 2019-2021 – Once the rest of specifications have been updated to accommodate
the additional features of EGNSS, an adequate certification scheme validating the additional
functionalities could be defined.
Recommendation: Develop a standardised technical verification procedure to assess which
improved performance an EGNSS receiver would provide for ADAS applications if using
optimally the EGNOS and Galileo signals.
Define also a voluntary certification scheme, embedding such procedure, to obtain different
performance levels in terms of key user requirements (accuracy as key requirement, but also
availability, continuity, integrity information support and spoofing detection) to be achieved
based on the verification results – in a similar fashion to Euro NCAP logic, meaning that
different scoring could be provided to award the achievement of different levels of
performance.
In this process, ensure that the voluntary certification scheme complies with the accreditation
rules governing the authorization of testing laboratories by accreditation bodies across the EU
(e.g. compatibility with ISO/IEC 17065 and compliance with EA-1/22) and that the system
68
performance tests for the selected architecture options and associated operational conditions
(covering an “end to end” performance rather than just the navigation component itself)
adhere to the ETSI 103 246-5 specification.
This activity overlaps with the same activity proposed for C-ITS, and both actions should be
coordinated. The C-ITS scenario is analogous, but it needs to consider all the cases included
in the ADAS case plus the information exchange, information coding/decoding and integration
of information from external sources.
3.5.3 Autonomous driving
3.5.3.1 The role of GNSS and EGNSS
Autonomous Driving (AD) covers systems from level 3 to level 5 of automation under the
classification of SAE International standard J301633. These include:
Level 3: Conditional Automation. The driving mode-specific performance by an
automated driving system of all aspects of the dynamic driving task with the
expectation that the human driver will respond appropriately to a request to intervene;
Level 4: High Automation. The driving mode-specific performance by an automated
driving system of all aspects of the dynamic driving task, even if a human driver does
not respond appropriately to a request to intervene;
Level 5: Full Automation. The full-time performance by an automated driving system
of all aspects of the dynamic driving task under all roadway and environmental
conditions that can be managed by a human driver34 .
The application is in the R&D phase, with all major car groups worldwide and tech giants
working on AD technology. Technology uptake forecasts differ widely, with conservative
estimates foreseeing only a share (30-35%) of new vehicles reaching Level 3 in the 2040s,
whereas a more disruptive scenario sees 90% of new sales being represented by fully
autonomous (level 5) vehicles35. A positioning system using sensor data fusion is a key
enabler for AD. A GNSS engine will be an essential element of this positioning system.
Absolute positioning provided by GNSS is the only way to reference the vehicle within a high-
resolution digital map, which also mandatory for AD as a support for perception-based
navigation techniques based on cameras, LiDARs/Radars, and inertial sensors. In this context,
EGNSS can provide an added value under several perspectives:
Both integrity (provided by EGNOS) and signal authentication (provided by Galileo) are
of the highest importance for AD, where safety is critical
Multiple-frequency and high bandwidth Galileo signals for mitigating multipath effect
Better availability and accuracy in difficult environments in a multi-constellation context
Due to these benefits, EGNSS is expected to be included in the GNSS engine for AD, in line
with the approach adopted for ADAS (see Section above). Key decision makers are the same
33
https://www.sae.org/misc/pdfs/automated_driving.pdf 34
https://www.sae.org/misc/pdfs/automated_driving.pdf 35
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
69
considered for ADAS, with the possible addition of technology and IT giants based on the
evolution of competition.
3.5.3.2 Gaps in standardisation
No relevant gaps (other than the ones outlined for ADAS or C-ITS) have been detected at the
time of writing, mainly due to the general lack of standards concerning AD. This is in turn
because manufacturers are working on their own solution, and standardisation will come into
play with higher technological maturity. As this happens, potential gaps might arise depending
on how EGNSS will be considered in the future standards.
Like the case of C-ITS, the EGNSS standardization process for autonomous driving should
cover not only the positioning information of the vehicle itself, but also how information is
managed/hybridized with the observations of the sensors in the vehicle and information
coming from either the infrastructure or other vehicles (and how positioning information is
exchanged) to generate Dynamic Maps to model the car environment.
3.5.3.3 Recommended standardisation actions
Considering the framework above, one additional secondary priority action focused on
monitoring and participating in upcoming standardisation activities is proposed, on top of the
relevant actions for ADAS.
Figure 16. Roadmap and standardisation actions in Autonomous Driving
Definition of the integrity concept for Road applications
The same definition of the integrity concept specific for the road domain would be applicable
for autonomous driving applications (see section 3.5.2.3). Therefore, a joint standardization
process could be carried out.
Define a voluntary certification scheme for positioning performance
As mentioned at the beginning of the section, the certification scheme for GNSS positioning
performance would be applicable for ADAS, AD and C-ITS. This action is the same as
70
described in the other applications (see section 3.5.2.3), although a higher performance level
may be required for full vehicle automation.
Participate in standardisation activities to verify whether requirements related to
EGNSS features are being adequately covered
Justification / Expected impact on EGNSS uptake: While there are multiple initiatives by
car manufacturers, which are independent and use different technologies, there is public
interest in providing a minimum set of standards to enable interoperability to ensure safety (as
per EU directive 2010/40/EU). Moreover, even though EGNSS is expected to be included in
the GNSS engine for AD, standardisation could help ensure that EGNSS features and
differentiators are fully adopted.
Priority: Secondary. This is a long-term action which would ensure better use of EGNSS, as
opposed to its adoption in general.
Owner: European Commission and GSA. Possible standardisation activities arising from the
monitoring should be covered by CEN/CENELEC TC5 WG1.
Timeframe: From second half of 2017 to 2021 at least, depending on the pace of technical
progress.
Recommendation: Participating in standardisation activities to verify whether requirements
related to EGNSS features are being adequately covered, which could be the case because
the application is extremely demanding in terms of PNT performance. Identified standards and
standardisation activities to be monitored include:
ISO standards for C-ITS (ISO/DIS 18750 being drafted at the time of writing for local
dynamic maps, ISO/CD 15622 for Adaptive cruise control systems, ISO/NP TS19091
for V2I and I2V communications for intersections)
SAE standards for autonomous driving (at the moment SAE J3016 Taxonomy and
definitions for Terms related to On-Road Motor Vehicle Automated Driving Systems
and J2945/6 Performance requirements for Cooperative Adaptive Cruise Control and
Platooning)
ETSI standards for C-ITS (including the evolution of ETSI TR 103 298 for platooning
and TR 103 299 for cooperative Adaptive Cruise Control)
Technical reports now under development such as ISO/PRF TR 20545 for
standardisation for vehicle automated driving systems (RoVAS)/Beyond driver
assistance systems.
Activities and progress of industry initiatives and standardisation platforms with wide
participation, such as the Open AutoDrive Forum36
Possible additional standardisation actions arising from this monitoring activities should be
then covered by CEN/CENELEC TC5 WG1.
36
A cross-domain platform working on standardisation in autonomous driving, see http://www.openautodrive.org/
71
3.5.4 Cooperative ITS
3.5.4.1 The role of GNSS and EGNSS
Cooperative intelligent transport systems (C-ITS) are aimed at providing road users with better
road safety, traffic efficiency, comfort, improved mobility and sustainability. The technology is
in an initial adoption phase, but there is the intention and interest by the industry, supported by
the European Commission, to start full scale deployment of C-ITS enabled vehicles in 201937.
GNSS represents a relevant technology for C-ITS as it is one of the sources of positioning,
which in turn is relevant information in the data exchange between vehicles and
infrastructures.
In this frame, Galileo will provide enhanced performance for future C-ITS requirements in a
multi-constellation context, in particular in difficult environments such as urban canyons. No
issues are expected regarding the use of EGNSS in the frame of the application, as the in-
vehicle GNSS engine feeding C-ITS will be the same one supporting ADAS and Autonomous
Driving.
Moreover, Galileo authentication and EGNOS integrity could be also valuable for this
application. As such, relevant standardisation activities at receiver level and focusing on the
data exchange between vehicle components is a necessary condition. Further to that,
standardisation should also cover the data exchange of information between vehicles (V2V)
and from vehicles to the infrastructure (V2I), which is covered in this section.
3.5.4.2 Gaps in standardisation
Standardisation in C-ITS in Europe is very active, and the EC created an action plan for the
deployment of ITS in Europe, followed by a mandate (Mandate M/453) to foster the
cooperation among European SDOs. Additionally, there are joint agreements between CEN-
CENELEC- ETSI-EASC and CEN-ISO to ensure the interoperability of the developed
standards, and even joint development of standards regarding C-ITS.
This continued ITS standardisation effort is supported by the EC Rolling Plan for ICT
Standardisation. At the time of writing, existing ITS standards are not addressing in depth the
quality of the position information. Only very simple accuracy requirements are mentioned, and
in the best cases, some degree of confidence, but no real information about integrity or
authentication. Likewise, standards dealing with the exchange of information between in V2X
communications do not accommodate fields to model neither the integrity of the position nor
the detection of possible spoofing attempts.
37
See Car-2-Car Communication Consortium Press release of 30 October 2015 - European vehicle manufacturers work towards bringing Vehicle-to-X Communication onto European roads, and European Commission Communication COM (2016) 766 final.
72
Given the relevance of the resilience aspect when positioning systems are used for
manoeuvring purposes, additional mechanisms are to detect whether the signals from GNSS
are reliable, which would require the revision of these standards. Additionally, any actions
taken at application level should be coordinated with the standardisation developments at
receiver level, to provide interoperability and to ensure that the receivers provide information
suited to the needs at application level.
It is also important to remark that envisaged actions would need to be promoted by the EU,
with the support of cities and industry. In this frame, it was underlined that there are massive
challenges because all the parties have their own interest. A collaborative approach is needed
to ensure that the implementation is successful.
3.5.4.3 Recommended standardisation actions
Considering the framework above, the following roadmap is proposed for C-ITS.
Figure 17. Roadmap and standardisation actions in Cooperative ITS (overlaps with ADAS/AD)
Definition of the integrity concept for Road applications
Given that many C-ITS applications are an expansion of ADAS including information exchange
between vehicles and the infrastructure, the same definition of the integrity concept specific for
the road domain would be necessary for C-ITS applications (see section 3.5.2.3).
73
Review of the basic set of application requirements and base architecture to support
EGNSS capabilities
Justification / Expected impact on EGNSS uptake: Defining the reference applications in a
way that the integrity/signal authentication capabilities of EGNSS are supported, as well as
incorporating different levels of service depending on the capabilities of the positioning
component, would greatly simplify the adoption of EGNSS in the C-ITS application standard
definitions, since it could be taken as a reference.
Although the uptake of EGNSS will probably be led by the market adoption of the receivers for
other functions (navigation, e-Call), adding support for EGNSS capabilities would be an
additional enabler for EGNSS uptake.
Priority: High. The reference architecture should be ready to support EGNSS capabilities,
since it is the base of C-ITS application implementations
Owner: EC/GSA, addressing CEN/ETSI/ISO. Given that all main SDOs are working together
in the field of C-ITS, suggestions pushed to one organization should spread to others.
Timeframe: 2017-2018. Reference specification work should be performed early to establish
the base for other C-ITS application. Also, the ISO/DIS 17427-1 is currently under
development, so any actions towards this specification should be performed in a short period.
Recommendation: Address standardisation organizations to ensure that the basic set of
application requirements and C-ITS reference architecture consider support for EGNSS
features, as the basis for C-ITS application specifications. The approach should be modular,
allowing the definition of different levels of service with different capabilities.
Relevant standards to address are:
ISO/DIS 17427 (11 parts) covering Cooperative ITS in general (from architecture to
compliance and enforcement aspects).
ETSI EN 102 637-1 Intelligent Transport Systems (ITS); Vehicular Communications;
Basic Set of Applications.
Given that Galileo will be supported in vehicles from April 2018 due to eCall regulations, future
versions of the Rolling Plan for ICT Standardisation should consider among the actions
concerning the ITS architecture the integration of the already available receiver and the
support of its added value features in C-ITS applications.
Review data exchange protocols in-vehicle and V2X to support integrity and signal
authentication
Justification / Expected impact on EGNSS uptake: The exchange of information between
vehicles and infrastructure, in order to provide cooperative services, is the core of C-ITS. One
of the key information pieces exchanged is the position information of both static and mobile
elements (vehicular and non-vehicles, like cyclists or pedestrians using their mobile devices
for interaction).
74
Adding support for EGNSS added value features (mainly integrity and signal authentication
status) would allow C-ITS to leverage on the information to assess the reliability of the position
information.
Priority: Primary. It is a key aspect to integrate EGNSS in C-ITS in any way.
Owner: EC/GSA, addressing CEN/ETSI/ISO. Given that all main SDOs are working together
in the field of C-ITS, suggestions pushed to one organization should spread to others. Since it
is a mostly related with communications, ETSI TC ITS should be the initial SDO contacted on
the topic.
Timeframe: 2017-2018. The information exchange protocol definition should be performed
early to establish the base for other C-ITS application.
Recommendation: Address SDOs to review the support for integrity information and signal
authentication (spoofing detection) in the information exchange protocols, both in-vehicle and
V2X. Identified standards include:
ISO/TS 19321:2015, to be reviewed in 2020, concerning the in-vehicle communications
among different components
ETSI TS 103 324: Cooperative Observation Service, currently under development
ETSI-TS 102 894/SAE J2735/ITS Connect TD-001 - Applications and facilities layer
common data dictionary
ETSI EN 302 637-2 ITS: Vehicular Communications; Specifications of Context
Awareness Messages
ETSI EN 302 637-3 ITS: Vehicular Communications; Specifications of the
Decentralized Environmental Notification Messages
As mentioned above, it is key to coordinate actions at application level, with actions at receiver
level, to ensure that the requirements of the application level are correctly fulfilled. The Rolling
Plan for ICT standardisation already includes several actions regarding interoperability and
communication protocols, both in-vehicle and V2X. Given that the installed receiver will have
integrity and spoofing detection capabilities, actions in the rolling plan should accommodate for
extending information exchange protocols to accommodate fields to support the features.
Include integrity support and spoofing detection in C-ITS application standards
Justification / Expected impact on EGNSS uptake: Once the bases to enable usage of
EGNSS features in C-ITS applications have been set (in the architecture and communication
protocols), the application themselves should integrate the spoofing detection and integrity
support in the operation requirements definition (to complete the end to end EGNSS support).
Priority: Primary. It is required to include EGNSS in C-ITS applications and in particular, the
differentiating feature.
75
Owner: EC/GSA, addressing CEN/ETSI/ISO. Given that all main SDOs are working together
in the field of C-ITS, suggestions pushed to one organization should spread to others.
Timeframe: 2018-2021. The other steps are required prior to introducing EGNSS in the C-ITS
applications.
Recommendation: Address SDOs to consider different levels of service integrating spoofing
detection and integrity capabilities if available, and performing actions in the case of
positioning degradation, such as informing the surrounding vehicles and infrastructure of
spoofing attacks, informing the driver of the requirement for manual control or discarding the
position reference of an element if the integrity information associated to the position reference
is considered compromised. Identified C-ITS to consider include:
ETSI-TR 103 298 Intelligent Transport Systems (ITS); Platooning; Pre-standardisation
study - and the upcoming specification for cooperative platooning
ETSI TR 103 299 Intelligent Transport System (ITS); Cooperative Adaptive Cruise
Control (C-ACC); Pre-standardisation study and its future specification.
ISO standard ISO DIS 18750 Intelligent transport systems -- Co-operative ITS -- Local
dynamic map, which is currently under development and other standardisation
initiatives concerning the local dynamic map building process.
ISO/NP TS 19091 Intelligent transport systems -- Cooperative ITS -- Using V2I and I2V
communications for applications related to signalized intersections, currently under
development.
ISO/TS 17426 Intelligent transport systems -- Cooperative systems -- Contextual
speeds, which will be revised on 2021.
ETSI TS 101 539-3 Intelligent Transport Systems (ITS); V2X Applications; Part 3:
Longitudinal Collision Risk Warning (LCRW).
Also, non-vehicular solutions based on smartphones or other end-user devices would need to
be considered, such as:
ETSI TR 103 300 Intelligent Transport System (ITS); Cooperative Vulnerable Road
Users (VRU); Study of use cases and standardisation perspectives
ISO 13184-2:2016 Intelligent Transport Systems (ITS) -- Guidance protocol via
personal ITS station for advisory safety systems, also defined in 2016 and therefore
will be revised in 2021.
There is significant work ongoing for the definition of local dynamic maps and the exchange of
navigation data, as this will set the base for many C-ITS applications. Upcoming releases of
the Rolling Plan for ICT standardisation should consider emphasizing the added value of
modelling integrity information and considering the protection levels of other vehicles location
when modelling the dynamic map of the near area.
Define a voluntary certification scheme for positioning performance
Justification / Expected impact on EGNSS uptake: See above. Like in the ADAS sector,
GNSS adoption in the transport sector will be driven by a combination of factors, such as
76
autonomous driving e-call, or the C-ITS applications. Although certification does not seem the
key aspect for the EGNSS uptake, it could be beneficial to promote the adoption of EGNSS, to
define different levels of performance that could highlight the added value of the European
systems compared to the other solutions of the market.
The certification scheme in C-ITS could be an expansion of the scheme proposed for ADAS,
but including cooperative versions of the application implementations and some more
advanced features concerning how the positioning information is managed during and after
exchange and not just at local level. Like in the ADAS case, it could foster the inclusion of
EGNSS in the vehicles, particularly in the high-end sector, which would benefit from the added
reliability as a differentiator against other lower end solutions.
Priority: Secondary
Owner: EC. ETSI/ISO/CEN could all be target SDOs, although ETSI has already defined the
ETSI TS 103 246-5 standard on performance Test specification for GNSS based location
systems which could be used as a basis for the certification scheme.
Timeframe: 2019-2021 – Once the rest of specifications have been updated to accommodate
the additional features of EGNSS, an adequate certification scheme validating the additional
functionalities could be defined.
Recommendation: develop a standardised technical verification procedure to assess which
improved performance an EGNSS receiver would provide for C-ITS applications if using
optimally the EGNOS and Galileo signals.
In such procedure, define also a voluntary certification scheme to obtain different performance
levels in terms of key user requirements (accuracy as key requirement, but also availability,
continuity, integrity information support and spoofing detection) to be achieved based on the
verification results – in a similar fashion to Euro NCAP logic, meaning that different scoring
could be provided to award the achievement of different levels of performance. This process
could be merged with the same initiative for other Road applications to provide a compound
value in a single certification process.
Ensure that the voluntary certification scheme complies with the accreditation rules governing
the authorization of testing laboratories by accreditation bodies across the EU (e.g.
compatibility with ISO/IEC 17065 and compliance with EA-1/22) and that the system
performance tests for the selected architecture options and associated operational conditions
(covering an “end to end” performance rather than just the navigation component itself)
adhere to the ETSI 103 246-5 specification.
This activity overlaps with the same activity proposed for ADAS, and both actions should be
coordinated. Nonetheless, the C-ITS scenario needs to consider all the same cases included
in the ADAS case plus the information exchange, information coding/decoding and integration
of information from external sources.
77
3.5.5 Insurance telematics
3.5.5.1 The role of GNSS and EGNSS
There is a clear trend within insurance companies to use telematic devices, although only a
small percentage of the drivers currently adopts these solutions.
Insurance companies are currently using GNSS in insurance telematics devices (installed
base worldwide was 14 million units in 2015, set to grow to almost 70 million units by 202038),
mostly for the recording of the number of km driven and the day of the week and time when
the vehicle is used, plus georeferenced accidents or shocks detected by the accelerometer
included in the device.
Galileo authentication is considered an important feature for insurance telematics. Although
not mainstreamed at the time of writing, cyber-attacks might become more prominent in the
future and the need for authentication will increase even more.
Although liability applications are more critical than for road navigation, they are less critical
than for safety-related applications and currently integrity is not crucial. However, if the
application of insurance telematics becomes more sophisticated, e.g. identifying which type of
roads are being driven on (highway or parallel road), assessing more in depth driving
behaviour, etc. the need for positioning integrity will considerably increase.
As per other road applications, EGNOS integrity performance in the road environment would
not be sufficient to comply with the needs of the insurance telematics applications and the
integrity would need to be complemented with local RAIM to provide in-vehicle redundancy
and integrity information when EGNOS is not available. There are few standards addressing
Insurance Telematics specifically, although there is one organisation ACORD (Association for
Cooperative Operations Research and Development) which is focused on the Insurance
Telematics standardisation. ACORD standards so far include a Reference Architecture and
several data exchange standards.
There are also generic standards for road applications, including terrestrial GNSS applications
that cover Insurance Telematics but only as a part of the application domain, such as:
ETSI TR 101 593: Satellite Earth Stations and Systems (SES). Global Navigation
Satellite System (GNSS) based location systems. Minimum performance and features,
which considers PAYD insurance
ETSI TR 103 183 Satellite Earth Stations and Systems (SES). Global Navigation
Satellite Systems (GNSS) based applications and standardisation needs, which
describes pay per use insurance in the inventory of transport applications in the road
domain.
38
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf5
78
3.5.5.2 Gaps in standardisation
No specific gaps have been identified, although the gaps discussed for the other applications
might also apply to insurance telematics.
Although Integrity or signal authentication information (e.g. to detect information forgery) could
be applied in the area of Insurance Telematics, they do not constitute key features to drive the
adoption of EGNSS.
Furthermore, it is likely that the information of GNSS receivers integrated in the vehicles to
provide other functions can be leveraged for Insurance Telematics, so efforts should be
prioritised in the other areas, and then advancements in positioning modelling can be adopted
by the Insurance Telematics community.
3.5.6 Smart mobility
3.5.6.1 The role of GNSS and EGNSS
Smart Mobility refers to mobile IT solutions that allow for increased multi-modal mobility and a
more efficient use of the mobility infrastructure.
Positioning information is a key enabler of this market, but the market (particularly with the
market penetration of smartphones) will regulate itself, it would be more relevant for EGNSS to
promote the benefits in terms of availability, particularly in urban environments.
3.5.6.2 Gaps in standardisation
No specific gaps for this application have been identified, since there is a large overlap of this
application with other applications addressed in this document.
3.6 Rail
3.6.1 SoL applications including ERTMS
3.6.1.1 The role of GNSS and EGNSS
GNSS role in rail is expected to dramatically increase in the next decade. The installed base of
GNSS devices worldwide will increase by a factor of 11 between 2015 (8,000 devices) and
88,000 devices in 2025. The most rapid increase is expected in the period between 2020 and
2025, when more than 54.000 new devices will be increasing the installed base. GNSS is
already widely used in non-safety relevant rail applications (without specific GNSS standards),
while several safety-relevant applications are emerging in which GNSS can potentially cover
an important position.
In the context of the European Rail Traffic Management System (ERTMS) the demand is
growing fast, especially outside Europe. While GNSS is perceived as a very promising
technology in rail and it could improve the business case of ERTMS (e.g., subject to the
evolution of ERTMS, through the virtualization of balises for cost saving and signalling of
79
secondary routes), its usage in Safety of Life (SoL) applications is still in the research phase
and the added value of EGNSS is still under investigation.
EGNSS is expected to provide an important added value for Rail SoL applications thanks to
improved availability and accuracy in a multi-constellation context, Galileo authentication and
EGNOS integrity. Being a SoL application, standardisation is required, also with regards to the
use of GNSS and EGNSS features. The key decision makers for the introduction of EGNSS in
Rail are EUAR (European Union Agency for Railways) and UNISIG (Europe’s rail and
signalling industries) who will be in charge of introducing EGNSS in ERTMS Specifications
(i.e. Technical Specifications for Interoperability, Control Command and Signalling - TSI CCS).
3.6.1.2 Gaps in standardisation
The current GNSS capabilities for rail have not been fully demonstrated yet. Also, a clear
identification of the benefits of using EGNSS within ERTMS (enhanced accuracy,
availability/continuity, integrity, security, etc.) is missing. Nevertheless, different projects are
ongoing or have recently been completed (STARS, RHINOS, Railsafe, NGTC, ERSAT EAV
etc.) and it is expected that these topics will be covered.
In particular, the following aspects need to be further investigated (assuming that other topics
will be fully addressed in ongoing projects):
Security of EGNSS solution for ERTMS: in Rail SoL applications security is a must.
Secure communications are needed and in the case of the on-board GNSS equipment
resilience to spoofing would be required. Galileo authentication would provide
resilience, but these issues need to be addressed in detail;
Complementary Positioning System/engineering rules (for both virtual and physical
balises) to ensure high accuracy and availability, notably to cope with GNSS Denied
Areas (e.g. combination of inertial navigation, 5G, RTLS (Real Time Location System),
etc.);
It is still not clear which of the GNSS technologies (i.e. SBAS, GBAS, ARAIM) could
have a role in providing SoL services in rail. The use of EGNOS SBAS is still
questioned by stakeholders because some of the railway sections are not covered by
the system. This is an issue of the system architecture, since with SBAS distributed
over GSM-R along the section with SoL receiver integrated in a RBC (Radio Block
Centre), the problem of availability is not severe. Note: The Railsafe project is expected
to provide a recommendation on suitable GNSS technologies for balises virtualization
in the ERTMS context.
After the technical analyses, the development of specific GNSS standards for rail SoL
applications will be needed, if GNSS is proven to be a suitable technology.
3.6.1.3 Recommended standardisation actions
Considering the framework above, to prepare the path for EGNSS adoption in rail, technical
activities will need to be performed to solve open points on the usage of GNSS for rail and to
demonstrate EGNSS capabilities. In the meantime, promotion of EGNSS added value could
80
help ensuring engagement of decision makers. After that, a standardisation process for
including GNSS in ERTMS Specifications (Technical Specifications for Interoperability. Control
Command and Signalling) would be required.
Figure 18. Roadmap and standardisation actions in Rail
Develop technical studies on GNSS
Justification / Expected impact on EGNSS uptake: different technical topics need to be
solved to determine if EGNSS capabilities are suitable for ERTMS, before activating a
standardisation process.
Priority: High (already ongoing), several technical topics should be addressed within ongoing
and planned studies and activities. These will represent inputs to the standardisation process,
if EGNSS is found to be suitable for SoL rail applications.
Owner: European Commission, GSA, European Space Agency, Shift2Rail.
Timeframe: 2018-2020.
Recommendation: Monitor the on-going projects on the use of GNSS in rail and continue
developing technical studies to address the points that could remain open in light of the
outcomes of on-going projects. Potential specific activities include:
Quantification of benefits once the technical solution is clear: Even if cost-benefit
analyses (CBAs) have been performed, a final and comprehensive CBA for the
introduction of EGNSS in ERTMS is required when the final architecture will be
selected. This CBA would need to focus specifically on the selection and quantification
of key parameters through an impartial approach;
Positioning requirements for rail applications (e.g. for signalling applications) are quite
stringent and GNSS augmentation will probably be required. In this sense, it is
recommended to perform analyses to select the most suitable GNSS technology for
ERTMS, choosing between Space Based Augmentation System (SBAS), Ground
Based Augmentation System (GBAS), Advanced RAIM (ARAIM) etc.
81
EC/GSA contact EUAR and UNISIG for monitoring the standardisation process on the
inclusion of EGNSS on the ERTMS/ETCS standards evolution
Justification / Expected impact on EGNSS uptake: being a SoL application, a
standardisation process in needed as a pre-requisite for EGNSS market uptake. This process
should follow ERTMS/ETCS procedures39.
Priority: High.
Owner: European Commission, and GSA to trigger activities by EUAR, UNISIG and EUG
(ERTMS Users Group).
Timeframe: From the year 2020.
Recommendation: It is recommended that the EC/GSA contact EUAR, UNISIG and EUG to
monitor the standardisation process, working on the inclusion of EGNSS on the evolution of
ERTMS specifications/ETCS standards.
In this context, the need to develop a specific standard for GNSS receiver for Rail should be
evaluated. Experience from GNSS implementation in aviation can be used as a starting point.
3.6.2 Non-SoL applications
3.6.2.1 The role of GNSS and EGNSS
GNSS is widely used in non-safety related applications such as passenger information system
and rolling stock fleet management.
EGNSS (EGNOS and Galileo) could provide an added value for this market segment:
The usage of Galileo in a multi-constellation context would improve the availability and
accuracy of the PVT solution;
Reliability due to the integrity provided by EGNOS;
EGNSS Authentication might be relevant for some use cases.
3.6.2.2 Gaps in standardisation
For non-SoL applications in Rail, no standardisation actions are recommended, as both desk
research and the consultation with stakeholders didn’t detect any significant standardisation
gap.
39
The ERTMS specifications (TSI) are managed according to the Agency Change Control Management (CCM). The ERTMS Unit within EUAR is responsible for the organisation and the process of the Change Control Management for the ERTMS specifications and documents. For this aim, the CCM procedure, describing the whole process for the ERTMS Change Control is adopted. Any modification to the ERTMS specification is analysed via a Change Request. A Change Request shall only be submitted by one of the recognised organisations in the list drawn up by the RISC Committee.
82
3.7 Multimodal transport and logistics
3.7.1.1 The role of GNSS and EGNSS
Multimodal logistics refers to the transport of goods by at least two different modes of transport
in the framework of a single multimodal transport contract. Logistics service providers draw on
GNSS for efficiency, security and safety. In a multimodal perspective, GNSS can contribute,
mainly through container tracking, to the monitoring of cargo along the entire supply chain.
Despite the benefits provided by GNSS monitoring to multimodal logistics players, adoption is
still limited40. Key reasons include operational costs, power consumption when monitoring
unpowered assets, durability issues of the devices and signal availability when containers are
stored in lower decks of vessels or in warehouses.
In this frame EGNSS could provide the added value in terms of:
Enhanced availability and accuracy provided by Galileo in a multi-constellation context;
OS Authentication in some use cases, based on the perceived risk of the shipment, the
value of the cargo, etc.;
Reliability due to the integrity provided by EGNOS, limited to the cases when liability is
important and powered assets are monitored.
3.7.1.2 Gaps in standardisation
The analysis performed shows that the constraint for the uptake of EGNOS and Galileo in
multimodal logistics is not standardisation, but rather the overall adoption of satellite navigation
solutions and, further to that, EGNSS implementation in chipsets. No standardisation action is
therefore suggested, while awareness activities to promote the uptake of GNSS and EGNSS
could be envisaged.
3.7.1.3 Recommended actions
The following roadmap, including one awareness (rather than standardisation) measure, is
proposed for multimodal transport and logistics.
40
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
83
Figure 19: Recommended non-standardisation action in multimodal transport and logistics
Promotion of GNSS and EGNSS added value for container tracking
Justification / Expected impact on EGNSS uptake: Promoting the uptake of GNSS could
have an incremental impact on its market adoption. Promoting the adoption of EGNSS added
value is expected to increase the uptake of Galileo, in particular within GNSS-enabled
solutions for container tracking.
Priority: Secondary, the impact of this action is constrained by the limited penetration of
GNSS as a technology in multimodal logistics.
Owner: GSA, with support of the European Commission
Timeframe: From second half 2017 to second half of 2019.
Recommendation: The GSA could leverage the results of already concluded or ongoing
projects involving the use of EGNSS for container/asset tracking and management
(GALAPAGOS, UKRAINE, CORE) to promote both the use of GNSS and the adoption of
EGNSS within GNSS-enabled solutions. Shipping industry and EGNSS events could
represent suitable contact points for this action.
The first part of the action would mainly target logistics operators and the shipping industry
and would need to focus on the positive return on investment of adopting GNSS solutions for
container tracking and management.
The second part of the action would address device manufacturers, and would need to focus
on showing a positive trade off when adding one additional constellation (Galileo) in terms of
positioning performance (and thus added value for users) versus the impact on battery
consumption and additional costs.
3.8 Agriculture
3.8.1.1 The role of GNSS and EGNSS
GNSS is increasingly adopted in agriculture. The installed base of GNSS devices for precision
agriculture41 worldwide will double between 2015 (1.2 million devices) to 2.5 million in 202042.
The same will happen from 2020 to 2025, when more than 5 million devices will be in use.
EU28 currently accounts for more than 10% of the installed base, whereas almost half of the
devices worldwide are in use in North America. The adoption level of EGNSS is quite
promising. EGNOS represents a well-recognised entry level solution for precision agriculture
and Galileo ready receivers are already available on the market from major manufacturers
41
Including GNSS devices for tractor guidance, automated steering and variable rate tracking 42
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
84
(Trimble, Deere&Co (Navcom), Topcon, Novatel, Leica Geosystems, Javad and Septentrio
produce at least one Galileo-ready device43.)
Device and tractor manufacturers are key decision makers in terms of choices on GNSS
solutions, since the end users are not experts in GNSS and evaluate products based on the
actual performance (e.g. in terms of actual accuracy, availability, user friendliness etc.).
3.8.1.2 Gaps in standardisation
The use of GNSS in agriculture market segment is not fully standardised. In particular, we
have identified only one standard related to GNSS in agriculture: ISO 12188. This standard
intends to provide a procedure for evaluating and reporting the accuracy of GNSS navigation
systems such as GPS or Galileo (assuming NMEA (National Marine Electronics Association)
standard), without covering augmentation systems such as SBAS or RTK (Real Time
Kinematic).
This is not an issue, since the adoption of satellite constellations and augmentation systems
(including Galileo and EGNOS) is not driven by standardisation, but rather by the added value
provided to the end users. Moreover, due to oligopolistic competition, as well as to the role of
accuracy as a main factor of products’ selling propositions, the market tends to “regulate itself”
and main players develop their proprietary solutions and approaches. The main gap detected
for the application covered in the analysis, i.e. GNSS in precision agriculture, is the lack of
standardisation on testing the GNSS receiver performances.
Beyond the scope of the analysis, other gaps that are not directly related with GNSS
downstream standardisation within precision agriculture, but that could be further investigated
include:
The lack of unification of the different inputs and data formats in Farm Management
applications;
At service provision level, EDAS (EGNOS Data Access Service) could be upgraded to
deliver Virtual Reference Station (VRS) (EGNOS based DGNSS) corrections via EDAS
Ntrip service, so that the EGNOS Open Service performance could be delivered in a
format which is compatible with receiver fleet, regardless of the visibility conditions of
the geostationary satellites. In particular if this decision is taken44, it should be verified
whether it is necessary to upgrade EDAS Ntrip protocol to support HTTP based
communication. As precision agriculture exhibits strong synergies between GNSS
(including EGNOS and Galileo) and Earth Observation (including Copernicus),
standardisation initiatives related to EO (e.g. coordinating ongoing initiatives to
harmonise LPIS formats) would indirectly benefit also the adoption of GNSS, by
supporting the diffusion of Farm Management Solutions;
43
Based on data available on http://www.usegalileo.eu 44
This aspect is being investigated in the EGNOS EDAS Service Analysis, coordinated by the European Commission and the GSA and ongoing at the time of writing.
85
Standardisation aspects within the evolution of boundary definition and checks within
the evolution of the Common Agricultural Policy after 2020 could be further
investigated;
On top of the above, the evolution of UAV regulations and standards is set to play an
important role in agriculture, which represents a key segment of application. Gaps and
actions related to UAV are presented in Section 3.2.
3.8.1.3 Recommended standardisation actions
Considering the framework above, no high priority actions are suggested for agriculture,
whereas two secondary priority actions (related to voluntary certification rather than
standardisation) are proposed in the roadmap below.
Figure 20: Roadmap and recommended actions in agriculture
Develop a light and voluntary certification scheme for testing receiver performance in
agriculture
Justification / Expected impact on EGNSS uptake: In the market, the performance
declarations by different manufacturers for their products are not directly comparable, so it is
difficult for users to compare the performance that manufacturers claim to offer in their GNSS-
based solutions.
Defining a voluntary certification process based on performance could help to address this
issue. Although EGNOS and Galileo are already well accepted in agriculture and no significant
standardisation gap exists, this action could incrementally improve the use of GNSS systems
and data, along with the adoption of EGNOS and Galileo insofar they can contribute to
improved performance.
Priority: Secondary, as the impact on EGNSS market uptake is expected to be only
incremental.
Owner: European Commission – DG GROW
Timeframe: From end of 2017 to mid-2019.
86
Recommendation: develop a standardised technical verification procedure – based on
performance requirements – to assess which improved performance a precision agriculture
receiver would provide if using optimally the EGNOS and Galileo signals.
In such procedure, define also a voluntary certification scheme to obtain two labels, 'EGNOS
Enabled' and ‘Galileo Enabled’, for the receivers, with different performance levels in terms of
key user requirements (accuracy as key requirement, but also availability and continuity) to be
achieved based on the verification results – in a similar fashion to Euro NCAP logic, meaning
that different scoring could be provided to award the achievement of different levels of
performance. In this process, ensure that the voluntary certification scheme complies with the
accreditation rules governing the authorization of testing laboratories by accreditation bodies
across the EU (e.g. compatibility with ISO/IEC 17065 and compliance with EA-1/22).
Promote the adoption of the scheme
Justification / Expected impact on EGNSS uptake: Since the scheme will be voluntary,
awareness and interest by receiver manufacturers is key to ensure its adoption.
Owner: GSA, in coordination with DG GROW
Timeframe: From mid-2019 to mid-2020.
Recommendation: The objectives of this action are twofold based on two different targets,
end users (farmers’ community) and receiver / device manufacturers.
Raising device and receiver manufacturers’ awareness on the scheme and increasing
their interest in undergoing the procedure.
Promoting to farmers the added value of the scheme as means to objectively compare
solutions by different manufacturers and take an educated decision when purchasing
(E)GNSS equipment, along with highlighting the role of EGNOS and Galileo to ensure
high operational performance for precision agriculture operations;
These two objectives are interrelated, as meeting one of them facilitates the achievement of
the other one. To this end, the recommended action is to promote the scheme within the
several market development and communication channels already adopted by the GSA,
including:
Participation to Industry Events such as Agritechnica or organisation of dedicated
sessions within GNSS Events such as European Space Solutions;
Promotion of the scheme in websites (GSA, EGNOS Portal, useGalileo), Reports (User
Technology and Market Reports), communication material, etc.;
Bilateral discussions with manufacturers and farmers’ associations.
3.9 Timing and Synchronization of critical infrastructures
3.9.1.1 The role of GNSS and EGNSS
GNSS is already used for Timing and Synchronisation (T&S) in the frame of different types of
applications, including critical infrastructures; however, there are no standards in place on
87
GNSS-based T&S (although several standards refer to the use of GNSS for timing). The role
of GNSS is expected to become more prominent, because of many factors: in telecom, due to
more stringent requirements (in terms of timing accuracy); in finance, due to new regulations
and in power grids, because there is increasingly demand for new power and more efficient
distribution. T&S applications, associated to critical infrastructures, are strategic and critical for
Europe. Therefore, it is very important to ensure a minimum level of robustness and reliability
for the use of GNSS, which can be obtained thanks to standardisation. Additionally, the
standardisation process can serve as an effective mechanism to foster the use of EGNSS
(Galileo and EGNOS) within this important market.
Overall, GNSS devices for T&S worldwide will grow from 1.3 million devices in 2015 to 2.4
million in 2020. A further increase in the number of devices is expected from 2020 to 2025,
when 3.5 million of devices will be in use45. Telecommunications is by far the largest market,
followed by financial applications as a distant second market. The installed base of GNSS in
energy networks is low in numbers but has high importance, due to the critical need of
maintaining the synchronisation of critical infrastructures.
The differentiators of EGNSS (as e.g. authentication, improved accuracy and availability,
robustness) represent a good opportunity to push EGNSS market penetration. In addition,
being Galileo a system for civilian purposes, it is expected to be an appealing solution for
critical infrastructures (within or outside the EU), as opposed to the option of exclusively
relying on military-owned systems such as GPS.
The key decision makers for this application are the European Commission, which could
consider legislative actions for EGNSS T&S adoption in critical infrastructures, and other
organisations such as CEN/ETSI/ESMA. National timing laboratories are also expected to play
a relevant role in possible standardisation activities.
3.9.1.2 Gaps in standardisation
There are no standards on GNSS-based T&S, whereas several standards refer to the use of
GNSS for timing; however, none of them so far refers to Galileo. Some of the standards refer
to GPS, whereas others mention GNSS in general. A selection of identified ITU performance
and interface standards, identified within a project coordinated by the European Commission
on EGNSS Robust Timing, is provided below.
Performance standards include:
ITU-T G.811 Timing characteristics of primary reference clocks;
ITU-T G.812 Timing requirements of slave clocks suitable for use as node clocks in
synchronization networks;
ITU-T G.813 Timing characteristics of SDH equipment slave clocks (SEC);
ITU-T G.8262 Timing characteristics of a synchronous Ethernet equipment slave clock;
ITU-T G.8263 Timing characteristics of packet-based equipment clocks;
45
Source: GNSS Market Report Issue 5, 2017 https://www.gsa.europa.eu/system/files/reports/gnss_mr_2017.pdf
88
ITU-T G.8272 Timing characteristics of primary reference time clocks;
ITU-T G.8273.2 Timing characteristics of telecom boundary clocks and telecom time
slave clocks.
Interface standards include:
ITU-T G.8265.1 PTP telecom profile for frequency synchronization
ITU-T G.8275.1 PTP telecom profile for phase/time synchronization with full timing
support from the network
ITU-T G.8275.2 PTP telecom profile for phase/time synchronization with partial support
from the network
Therefore, on top of the absence of a standard on GNSS-based T&S, a key gap is the lack of
consideration for Galileo and EGNOS in existing standards.
In this frame, several technical topics would need to be addressed to feed standardisation
activities related to EGNSS. These include areas such as the development of a multi-GNSS
timing solution, jamming and spoofing mitigation etc. Based on the analysis performed,
Standardisation of GNSS in T&S would indeed support EGNSS market penetration.
Special attention should be paid to the aspects that could influence and deteriorate the
robustness and reliability of the EGNSS solution, to ensure that the processing of EGNSS is
correctly performed and minimum performances are obtained for critical applications.
The level of requirements (in the order of 9-10 nanoseconds for some applications) implies
that EGNSS could play an important role, but also that the solution leveraging on EGNSS
needs to be robust and reliable enough to fulfil the expected requirements, so to be
considered within this market. To ensure the uptake of EGNSS, it is important to work on the
standardisation as this is a market is not familiar with EGNSS systems and their added value.
Additionally, a gap has been detected with regards to the definition of the technical solution
using EGNSS depending on the application. There are currently EU projects (DEMETRA and
EGNSS Robust Timing) working these technical. Their outcomes are expected to be relevant
to support the standardisation of the timing applications in relation with the gaps identified.
3.9.1.3 Recommended standardisation actions
Considering this framework, the following high priority standardisation actions are suggested
for T&S applications and can be shown in the roadmap below:
Launch of technical activities to solve technical open points (these include jamming
and spoofing mitigation, T-RAIM algorithms, multi-GNSS timing solutions etc.) of a
robust T&S EGNSS service. These activities will provide inputs for the development of
a EGNSS T&S Receiver standard.
Focusing on T&S of critical infrastructures, a feasibility analysis is proposed to show
that EGNSS performance could achieve T&S requirements of critical infrastructures;
Based also on the above, evaluate the case for a European Commission initiative for
mandating EGNSS usage for T&S of critical infrastructures in the EU;
Development of a multi-GNSS SIS (Signal in Space) Timing accuracy standard;
89
EC/GSA to get in contact with the relevant standardisation bodies for the development
of an EGNSS T&S Receiver Test Cases Standard;
Development of a conformity assessment scheme.
Figure 21: Roadmap and recommended standardisation actions in T&S
Technical activities to feed standardisation process
Justification / Expected impact on EGNSS uptake: As a preliminary step, standardisation
actions need to be fed with technical analyses to solve open points on the usage of GNSS for
T&S applications. In our experience, the performance of timing applications highly depends on
how GNSS data is used (different applications on the market show different behaviour in terms
of robustness and resilience). Therefore, it is very important to define a robust approach to
GNSS processing. Additionally, there are other technical aspects that need to be consolidated
to maximise the benefits that EGNSS can bring to these applications thanks to its
differentiators. These technical activities would support EGNSS market penetration, since they
are needed as an input to standardisation
Priority: High, standardisation of EGNSS T&S will need to be fed with technical inputs.
Owner: European Commission, GSA.
Timeframe: this action could start in 2017.
Recommendation: European Commission and GSA to solve the issues preventing a robust
and reliable EGNSS timing solution, through technical activities. The areas that require further
investigation include:
Jamming and spoofing mitigation: to protect critical infrastructures from potential
attacks, it is important to identify the best solution to mitigate these GNSS
vulnerabilities, as well as to assess whether standardisation is needed;
90
T-RAIM (Timing Receiver Autonomous Integrity Monitoring) algorithms: it is
recommended to work on integrity timing algorithms and to define the best option for a
robust and reliable timing solution, analysing the potential use of EGNOS and Galileo
within a timing service;
Multi-GNSS timing solutions: The solution for combining multi-GNSS for timing
applications is not harmonized, to the point that in a faulty case of GPS, receivers have
been showing very different levels of resiliency. It is important to work on this specific
aspect to ensure a proper implementation of multiple constellations in timing
applications and a minimum level of resilience over the EU territory;
Use of Galileo Ionospheric NeQuick model: In our experience, the use of Galileo
NeQuick model presents an advantage over the use of GPS ionospheric model
(Klobuchar), in terms of obtaining a stable timing solution for monofrequency users. It
is recommended to study and demonstrate the advantages of using this model and the
benefits that this can provide to T&S applications.
Feasibility analysis covering EGNSS compliance with T&S requirements in critical
infrastructures: Defining which timing requirements, and to what extent, the EGNSS
technology could fulfil, would help make the case the introduction of EGNSS itself,
encouraging industry and users to adopt European systems in this market segment.
The activities above are to a certain extent already covered in the recently completed
DEMETRA project46, as well as in the ongoing project focusing on EGNSS Robust Timing that
is funded under the H2020 Programme. As soon as this project is finished (the end of 2017), a
gap analysis should be performed to ensure that the remaining issues are covered, by
launching additional projects in the 2018 timeframe.
Another project to consider is FANTASTIC (Field Aware Navigation and Timing Authentication
Sensor for Timing Infrastructure and Centimetre level positioning), which aims at developing
an enhanced positioning and timing engine to be used as a critical component in professional
applications. Three specific use cases will be tested and demonstrated within this project:
Commercial Service based precise positioning; Machine control for construction, agriculture;
and, most importantly, Timing.
Feasibility analysis of EGNSS compliance with T&S user requirements
Justification / Expected impact on EGNSS uptake: in parallel to the recommended
technical studies, and before entering in the standardisation process, it is important to analyse
whether a GNSS T&S receiver using EGNSS can comply with the T&S performance
requirements of critical infrastructures in terms of accuracy, integrity or resilience. Showing
that EGNSS T&S performance meets the requirements would support EGNSS market uptake.
If, for a given application, it is shown that EGNSS cannot meet the T&S requirements, other
complementary technologies would be needed.
46
See http://rime.inrim.it/H2020-Demetra/project-overview/
91
Priority: High, showing that the achievable performances of a T&S receiver meet the
requirements is a pre-requisite for standardisation and EGNSS market adoption.
Owner: European Commission, GSA and ESA.
Timeframe: This action could start in 2017.
Recommendation: EC/GSA to launch a feasibility analysis to investigate whether EGNSS
can provide the robustness, security, integrity and timing accuracy needed for the different
critical infrastructure applications. Different applications would benefit from a reliable timing
and synchronization provided by GNSS such as 5G, IoT, maritime applications, autonomous
transport, banking or power distribution applications, each of them having different needs in
terms of GNSS T&S performance. To define for which applications an EGNSS T&S service
could be suitable, a feasibility analysis is needed.
Considering that existing requirements could not be mature enough for the different
applications, it is recommended to revise them in terms of timing accuracy, security or
integrity.
It should also be considered that different options for such a service could be envisaged
(EGNOS, Galileo OS (Open Service), Galileo CS (Commercial Service), Galileo PRS (Public
Regulated Service) etc.).
We thus consider that this action is important on one side to work on technical aspects to
guarantee minimum performances levels for key applications, and on the other side to
guarantee the applicability of EGNSS T&S concepts and value propositions to the different
markets. Promotion and awareness of EGNSS for T&S is also relevant.
EC may consider an initiative for EGNSS T&S usage in critical infrastructures in the EU
Justification / Expected impact on EGNSS uptake: Standardisation of EGNSS T&S would
support EGNSS market penetration and would protect EU critical infrastructure. Nevertheless,
standardisation will not ensure EGNSS market uptake by itself. The only way to ensure
EGNSS adoption would be that the EC supports the usage of EGNSS for T&S in critical
infrastructures over the EU.
Priority: High. This initiative would foster EGNSS usage in T&S for critical infrastructures in a
multi-constellation context. For EU critical infrastructures, it would be strategic not to rely
exclusively on a foreign GNSS system as GPS in power, financial or telecommunication
applications.
Owner: European Commission.
Timeframe: 2018
Recommendation: Based also on the results of the feasibility analysis mentioned above, the
European Commission may consider mandating the use of EGNSS for critical infrastructure in
92
a multi-constellation context, adding Galileo on top of GPS. Even where Galileo could be not
considered the primary means to provide T&S, the possibility of having a complementary
mode could be explored, based primarily on Galileo only, for the EU not to rely on foreign
GNSS systems.
EC to consider support to the development of a Multi-GNSS SIS Timing standard
Justification / Expected impact on EGNSS uptake: Stakeholders consider the signal-in-
space interface control document and signal-in-space accuracy as of high importance to test
timing receivers based on a unified/standardised approach. Timing solution performance is,
among other factors, dependent on the correct installation and operation of the GNSS
receiver. Manufacturers base their performance specifications on historical data and laboratory
tests with GNSS constellation simulators. However, scenario files of GNSS constellation
simulators are not validated against GNSS service performance standards. For the end users,
the manufacturers’ product specifications are the only accessible relevant information.
Purchase decisions are made based on the product specifications. If poorly specified, a
product is not considered. Taking this into account, it is very important to harmonize robust
and reliable timing processing for a Multi-system (GNSS) case, through a standardisation
process.
Priority: High, this action is perceived as of high importance for EGNSS market penetration.
Owner: European Commission
Timeframe: 2019 (after developing the technical activities to feed the standardisation
process).
Recommendation: It is recommended that EC/GSA support the development of a Multi-
GNSS SIS Timing standard. This standard should consider as a minimum the following
technical aspects:
Mapping of final performances to Signal-in-space accuracy, including traceability
between GNSS services and receiver performances;
Definition of Figures-of-Merit from a GNSS service performance standard, to obtain a
clear comparison between GNSS services and product performances;
For the multi-constellation case, definition of GNSS processing so to ensure a
minimum performance, including robustness and reliability. Note: It is recommended,
that implementation details at receiver level are not strictly detailed or standardised,
since allowing receiver manufacturers to be flexible is advisable; however, a minimum
set of processing specifications needs to be defined, to ensure robustness and
reliability of the use of EGNSS.
Definition of test cases, including constellations scenarios setup.
Definition of test procedures and of the mechanism of validation for critical
infrastructures.
93
EC/GSA to contact CEN/CENELEC for consideration of the development of EGNSS T&S
Receiver Test Cases Standard and to monitor the standardisation process
Justification / Expected impact on EGNSS uptake: As commented above, a standardisation
process for EGNSS T&S for critical infrastructure is highly recommended. Once the technical
open points are solved (including feasibility analysis, see previous action), the next step
should be to develop a new EGNSS T&S Receiver Standard.
This will have a great impact on EGNSS uptake, and will be relevant at least for critical
infrastructures, where the resilience of the T&S solution should be guaranteed to protect upon
potential attacks to strategic infrastructure.
Priority: High, the development of EGNSS T&S Receiver Standard will be relevant for critical
infrastructures and would push EGNSS market penetration.
Owner: EC/GSA to support and monitor activities by CEN/CENELEC.
Timeframe: 2019 (after developing the technical activities to feed the standardisation process
and showing the feasibility of EGNSS T&S receiver).
Recommendation: To ensure the development of a EGNSS T&S Receiver Standard, we
recommend that the EC/GSA contact relevant bodies such as CEN/CENELEC. The
development of a standard covering an EGNSS T&S receiver could consider a global level
involving ISO/IEC but also the applications level, for which ITU-T (telecommunications) or
ESMA - European Securities and Markets Authority (finance) would need to be involved.
More specifically, it is recommended to develop a specific standard (EGNSS T&S Receiver
Standard) based on performance aspects, which could be used as the basis for the
standardisation of the use of EGNSS within the different applications and markets associated
to the T&S market. It is recommended to work mainly on the definition of how GNSS in
general and EGNSS specifically will be used for timing applications. The type of features to be
standardised will be clearly linked to the critical technical aspects to be identified within the
technical activities proposed above.
Standardisation is a living process and when developing standards, new open technical issues
might appear or could be reopened. It is recommended that the EC monitors the
standardisation process, so to launch and support additional technical activities if new open
technical topics appear when developing the standard.
Development of a conformity assessment scheme
Justification / Expected impact on EGNSS uptake: A conformity scheme would help
ensuring that critical EU infrastructures are implementing EGNSS T&S following the standard
developed in the previous step. This is particularly relevant to guarantee the robustness and
reliability of the timing solution for critical infrastructures. In this frame, it is strategic for the EU
to ensure a minimum level of resilience for the timing solution that on the one hand protects
94
the infrastructures from threats, on the other hand ensures a proper implementation of EGNSS
T&S solution.
Priority: High. The conformity assessment scheme will be relevant to ensure that UE
infrastructure is implementing EGNSS T&S properly. Also, resilience to potential attacks such
as spoofing could become more important in EU in the future.
Owner: European Cooperation for Accreditation (EA).
Timeframe: 2020 (after developing the new EGNSS T&S Receiver standard).
Recommendation: After developing the new EGNSS T&S Receiver Standard, it is
recommended to develop a conformity assessment scheme based on accredited authorities.
The scheme could be voluntary when not applied to critical infrastructures.
It is recommended that the EC evaluates whether this conformity assessment scheme would
be voluntary or mandatory (based also on the decision of an EC Mandate for EGNSS T&S
usage for critical infrastructures over the EU) and the exact scope and methodology.
It is recommended that the proposed conformity assessment scheme, as a minimum,
considers the following aspects:
Performance levels in terms of timing accuracy, integrity, etc. – i.e. the relevant
requirements for T&S;
Performance benchmarked against the Multi-GNSS SIS Timing standard;
Test cases and procedure definition, to ensure that the receiver implementation is
pe3rformed according to the standards;
Specific test cases for the processing of multi-constellation and EGNSS (EGNOS and
Galileo);
Validation methodology and environment definition (scenarios), for each application;
Timing labelling, in case this is needed to cover the different applications.
3.10 Overarching recommendations
Stakeholders interviewed during the project underlined that a key gap for the adoption of
EGNSS in applications such as Search & Rescue is of legal nature: non-authorised GNSS
systems are not allowed for use in the US without a user licence. Users in America are
therefore potentially prevented from using Galileo.
In this respect, the European Commission has requested a waiver to permit Galileo
positioning, navigation, and timing services in the United States. The waiver was initially
presented to the National Telecommunications and Information Administration (NTIA). The
NTIA responded by informing the FCC they believe that granting the waiver is in the public
interest in the sense that authorizing the use of Galileo in the US would advance national
goals. Furthermore, the grant of the waiver is consistent with US international trade, and the
system complies with United Nations Space Debris Mitigation guidelines.
95
This issue is expected to be resolved by the beginning of 2019, but stakeholders have
confirmed that it represents an immediate issue for the industry. Considering this framework,
one non-standardisation action is suggested in the roadmap below.
Figure 22. Recommended non-standardisation actions in maritime SAR
EC to perform activities to overcome US licence requirements
Justification / Expected impact on EGNSS uptake: Currently non-authorised GNSS
systems are not allowed for use in the US without a user licence. Users in America are
therefore potentially prevented from using Galileo. Therefore, it is necessary to push for
modification of legislation in US and other regions with the same potential problem and
coordinate European and American organizations to solve this issue.
Priority: High, to use EGNSS in US or other countries it is required to overcome this issue
since this currently prevents EGNSS uptake in non-EU territories.
Owner: European Commission
Timeframe: 2017-2019
Recommendation: To overcome the issue of the user licence requirements for non-
authorised GNSS systems in the United States (that prevents US users the use of Galileo
SAR), the European Commission should prompt all the necessary steps (in terms of
investment of human and financial resources) to overcome such obstacles and speed up the
consultation process, emphasizing the benefits of the Galileo signal, and the necessity of the
industries to achieve a quick definition of the procedure.