overview of egnss downstream standardisation and

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 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


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.


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

https://www.easa.europa.eu/system/files/dfu/NPA%202017-05%20%28A%29_0.pdf

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


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.


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.


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


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


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

https://www.easa.europa.eu/system/files/dfu/NPA%202017-05%20%28A%29_0.pdf

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.


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.


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


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.


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



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.


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.


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


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.


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.


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


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.


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


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.


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.


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


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).


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

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.


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.


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

http://www.usegalileo.eu/

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


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.


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.).


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.


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


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.


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.


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


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

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.


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


http://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.


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

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


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



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


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





69

considered for ADAS, with the possible addition of technology and IT giants based on the

evolution of competition.


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.


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.


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/

http://www.openautodrive.org/

71

3.5.4 Cooperative ITS


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.


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.


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.


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


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.


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



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


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


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


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.


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


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).


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.


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.


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


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.


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


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.


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



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


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



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.).


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.


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


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.


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



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.


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.


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


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.

overview of egnss downstream standardisation and

Documents