Aerospace series - Unmanned Aircraft Systems - Part 002: Direct Remote identification

Luft- und Raumfahrt - Unbemannte Luftfahrzeugsysteme - Teil 002: Anforderungen an die direkte Fernidentifizierung

Série aérospatiale - Aéronefs télépilotés - Partie 002 : Exigences d'identification directe à distance

Aeronavtika - Letalski sistemi brez posadke - 002. del: Neposredna identifikacija na daljavo

General Information

Status
Not Published
Publication Date
29-Oct-2023
Withdrawal Date
30-Nov-2022
Current Stage
6055 - CEN Ratification completed (DOR) - Publishing
Start Date
28-Aug-2023
Completion Date
28-Aug-2023

Buy Standard

Draft
prEN 4709-002:2021 - BARVE
English language
56 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
oSIST prEN 4709-002:2021
01-februar-2021
Aeronavtika - Letalski sistemi brez posadke - 002. del: Neposredna identifikacija
na daljavo
Aerospace series - Unmanned Aircraft Systems - Part 002: Direct Remote identification
Luft- und Raumfahrt - Unbemannte Luftfahrzeugsysteme - Teil 002: Anforderungen an
die direkte Fernidentifizierung
Série aérospatiale - Aéronefs télépilotés - Partie 002 : Exigences d'identification directe à
distance
Ta slovenski standard je istoveten z: prEN 4709-002
ICS:
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
oSIST prEN 4709-002:2021 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 4709-002:2021

---------------------- Page: 2 ----------------------
oSIST prEN 4709-002:2021


DRAFT
EUROPEAN STANDARD
prEN 4709-002
NORME EUROPÉENNE

EUROPÄISCHE NORM

December 2020
ICS
English Version

Aerospace series - Unmanned Aircraft Systems - Part 002:
Direct Remote identification
Série aérospatiale - Aéronefs télépilotés - Partie 002 : Luft- und Raumfahrt - Unbemannte
Exigences d'identification directe à distance Luftfahrzeugsysteme - Teil 002: Anforderungen an die
direkte Fernidentifizierung
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee ASD-
STAN.

If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.


EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 4709-002:2020 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
Contents Page

European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 6
3.1 Terms and definitions . 6
3.2 List of abbreviated terms . 7
4 General design requirements . 8
4.1 Privacy and personal data of remote pilots and drone operators . 8
4.2 Conceptual overview . 8
4.3 Mandatory information . 9
4.4 Security of the DRI system . 9
4.5 Upload of UAS operator registration number . 10
4.6 Performance Requirements . 13
4.7 Working Time . 14
4.8 Add-on Specific requirements . 14
4.9 DRI Display Applications . 14
5 Requirements for Direct Remote Identification function . 14
5.1 Data Dictionary . 14
5.2 DRI messages . 20
5.2.1 Message header . 20
5.2.2 Block message . 20
5.2.3 Basic ID Message . 21
5.2.4 Location/Vector Message . 22
5.2.5 Self-ID Message . 26
5.2.6 System Message . 26
5.2.7 Operator ID Message . 29
5.2.8 Message Pack . 30
5.3 Broadcast Transport Protocols . 30
5.3.1 General . 30
5.3.2 Bluetooth Legacy Advertising Transport Mechanism (4.x compatible) . 31
5.3.3 Bluetooth Long Range Advertising Mechanism (5.x compatible) . 33
5.3.4 Wi-Fi Aware Transport Method . 38
5.3.5 Wi-Fi Aware Management Frames . 38
5.3.6 Neighbour Awareness Networking (NAN) . 39
5.3.7 NAN Service Discovery Frame and Synchronization Beacon Frame format . 39
5.3.8 Wi-fi Operating Channels . 43
5.3.9 Wi-Fi Beacon Transport Method . 43
5.4 Output Power . 45
5.5 Emission directivity . 45
5.6 Update and Transmission Rates . 45
6 Verification requirements and Test Methods . 46
2

---------------------- Page: 4 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
6.1 Scope . 46
6.2 DRI Generic Test Procedure . 46
6.2.1 General . 46
6.2.2 Upload UAS Operator Registration Number test procedure . 46
6.2.3 UA Category/UA Class configuration test procedure (for Add-on only) . 46
6.2.4 UAS DRI Data Field transmission testing procedure . 47
6.3 Update and Transmission Rates test procedure . 49
6.3.1 General Test setup . 49
6.3.2 Measurement procedure . 49
Annex A (informative) Conformity methods and technical specifications references . 51
A.1 Requirement verification stage . 51
A.2 WiFi, Bluetooth channels, bandwidth, and frequencies . 51
Annex ZA (informative) Relationship between this document and the essential
requirements of Delegated regulation (EU) 2019/945 of 12th March 2019 on
unmanned aircraft systems and on third-country operators of unmanned aircraft
systems aimed to be covered . 52
Bibliography . 55


3

---------------------- Page: 5 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
European foreword
This document (prEN 4709-002:2020) has been prepared by the Aerospace and Defence Industries
Association of Europe — Standardization (ASD-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this document has
received the approval of the National Associations and the Official Services of the member countries of
ASD-STAN, prior to its presentation to CEN.
This document is currently submitted to the ASD-STAN National Domain Ballot in parallel to the CEN
Enquiry.
This document was originally reviewed by the Domain Technical Coordinator of ASD-STAN's
Autonomous flying Domain.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association and supports essential requirements of EU Directive(s).
For relationship with EU Directive(s), see informative Annex ZA, which is an integral part of this
document.
4

---------------------- Page: 6 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
Introduction
EASA published the Commission Delegated Regulation (EU) 2019/945 of 12th March 2019 on unmanned
aircraft systems and on third-country operators of unmanned aircraft systems.
Many organizations are involved in developing a range of general technical standards for electrical safety,
EMC, environmental and a range of other standards to be applied to specific applications. For UAS the
picture is complex, but an acceptable means of compliance can be completed with existing technical
standards and the use of electrical components that are intended to be incorporated into equipment and
for which a risk assessment can be undertaken.
This document gives all economic operators (such as manufacturers, importers and distributors and their
trade associations as well as bodies involved in the conformity assessment procedures) a viable way to
prove compliance with the requirements laid out in the Delegated Act of 12th, March 2019 find
commonality in compliance methods.
It is the manufacturer’s responsibility to determine, based on his risk assessment, whether the risk is
acceptable. Regarding what is an acceptable level of risk for a product, this is determined by the
compliance with the safety objectives defined in the Delegated Act of 12th, March 2019.
The end user of this document assumes all responsibility for the safe application of these test methods.
All relevant safety/quality procedures should be considered. Special consideration should be considered
when operating the UAS for evaluations. All local, state, federal, and country laws should be considered
when operating UAS.
For repeatability, it is assumed that environmental conditions (temperature, wind, pressure, humidity)
are recorded during any tests and it is further assumed tests conducted unless otherwise noted within
the following conditions: Temperature – 18-28 °C, Pressure – Atmospheric from sea level up to 2 000 m,
Humidity – 10-60 %, Wind Speed – Calm (less than 0,3 m/s or zero on the Beaufort Scale).
5

---------------------- Page: 7 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
1 Scope
This document will provide means of compliance to cover the “Direct Remote Identification” system for
UA of the “open Category”. This document applies to Class 1 to Class 3 and Add-On.
The “direct remote identification” means a system that ensures the local broadcast of information about
a UA in operation.
More specifically, this document will address drone capability to be identified during the whole duration
of the flight, in real time and with no specific connectivity or ground infrastructure link, by existing mobile
devices when within the broadcasting range. Such functionality, based on an open and documented
transmission protocol (described in this document) and developed for security purposes and social
acceptance, can be used by law enforcement people, critical infrastructure managers, and general public
to get an instantaneous information on the drone flying around, providing various information such as
UA identifier, UA navigation data and operational status, UAS Operator identifier and position as defined
in the Delegated Regulation (EU) 2019/945.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ETSI EN 301489-1, ElectroMagnetic Compatibility (EMC) standard for radio equipment and services;
Part 1: Common technical requirements; Harmonised Standard for ElectroMagnetic Compatibility
ETSI EN 301489-17, ElectroMagnetic Compatibility (EMC) standard for radio equipment and services;
Part 17: Specific conditions for Broadband Data Transmission Systems; Harmonised Standard for
ElectroMagnetic Compatibility
ETSI EN 300328, Wideband transmission systems; Data transmission equipment operating in the 2,4 GHz
band; Harmonised Standard for access to radio spectrum
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at http://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/
3.1.1
Direct Remote Identification
DRI
system that ensures the local broadcast of information about a UA in operation, including the marking of
the UA, so that this information can be obtained without physical access to the UA
6

---------------------- Page: 8 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
3.1.2
UAS Operator Registration Number
identifier delivered by the National Aviation Authority, upon UAS operator eRegistration procedure
Note 1 to entry: In this document UAS Operator Registration Number is equivalent to UAS Operator ID, UAS
Operator Registration ID
3.2 List of abbreviated terms
Add-on A standalone Direct Remote ID broadcast device integrating a GNSS function, a
barometric function, a communication function, being able to provide position,
height, speed over ground, track clockwise with true north, of the UA, and the remote
pilote position or it’s take-off position.
AGL Above Ground Level
ASD-STAN Aerospace and Defence Industries Association of Europe - Standardization
DRI Direct Remote ID
EASA European Union Aviation Safety Agency
EC European Commission
EMC Electro-Magnetic Compliance
ft feet
GCS Ground Control Station
ID Identification
IEC International Electrotechnical Commission
ISO Internation Organization for Standardization
kts knots
NM Nautical Miles
MS Member State
RID Remote ID Display
SDF Service Discovery Frame
UA Unmanned Aircraft
UAS Unmanned Aircraft System
UTC Coordinated Universal Time
UTM UAS Traffic Management
UUID Universally Unique Identifier based on IETF RFC4122
C0, C1, C2, C3, Class 0 to Class 4 that the UA belongs to “Open” Category
C4
C5, C6 Class 5 to Class 6 that the UA belongs to ”Specific” Category
C2 link Command and Control link between UA and the GCS
DRI Direct Remote Identification
TU Time Unit (1 TU = 1024 microsecond)
7

---------------------- Page: 9 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
4 General design requirements
4.1 Privacy and personal data of remote pilots and drone operators
Following European Commission consultation to EDPS (European Data Protection Supervisor), EDPS
delivered an opinion about the Communication from the Commission to the European Parliament and
the Council on “A new era for aviation - Opening the aviation market to the civil use of remotely piloted
aircraft systems in a safe and sustainable manner”, the 26th of November 2014.
The EDPS recommends that the Commission encourages RPAS manufacturers to implement privacy by
design and by default and data controllers to carry out data protection impact assessments where
processing operations present specific risks to the rights and freedoms of data subjects (ie citizens) by
virtue of their nature, scope or purposes. And to encourage measures that would facilitate identification
of the controller of an RPAS. This last recommendation will be managed in the Delegated Regulation (EU)
2019/945, with the Direct Remote Identification feature requirement for UA and Add-on. The DRI data
messages shall be then transmitted in plain text without encryption, such as the UA unique serial number,
the UAS Operator Registration Number, the time-stamp, the position, the height, the speed, the direction,
the emergency status of the UA, and the position of the remote pilot. As a consequence, this document
does not cover the Remote Pilot/Operator privacy and data protection by design, and by default.
4.2 Conceptual overview

Figure 1 — DRI conceptual overview diagram
One or more UA are operating and broadcasting Direct Remote ID data. An interested observer wants to
identify the UA.
The UA continuously broadcasts Remote ID data using one of the methods described in Clause 5. The UA
is controlled locally by the Remote Pilot and has no interface with a U-Space service provider.
8

---------------------- Page: 10 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
The interested observer accesses a Remote ID Display Application (RID App). This display application
shows UA location and remote Pilot position or take-off position if not available, and a near-real-time trail
of position reports on a map, and associated identification information when a particular UA is selected.
When the interested observer opens the Remote ID software on a receiver mobile device (such as
smartphone), Remote ID data are acquired as follows:
1. The broadcast UA is transmitting its Remote ID advertisements continuously. The receiver mobile
device (such as smartphone) uses its internal radios to listen for the advertisements from the UA,
extract the Remote ID data, and show the location of the UA on the map and the position of the pilot,
or the take-off position according to requirement matrix. As new position updates are received, the
prior position reports become part of a near-real-time trail representing where the UA most recently
flew.
2. The interested observer selects the UA symbols for the Broadcast UA on the map and views the
corresponding ID information.
3. The interested observer closes the mobile application. After a period of time, the Remote ID software
discards the information.
4.3 Mandatory information
The Direct Remote ID system shall broadcast locally the mandatory information listed below:
— The UAS operator registration number.
— The unique serial number of the UA (or exclusively the Add-on) compliant with standard ANSI/CTA-
2063-A-2019.
— The time stamp, the geographical position of the UA and its height above the ground or its take-off
point.
— The route course measured clockwise from true north and ground speed of the UA.
— The geographical position of the remote pilot, or if not available, the geographical position of the
take-off point.
— The UAS emergency status for Class C1, C2, C3. Not required for Add-on.
The conformity to this requirement shall be proved per experiment method described in 6.2, “DRI Generic
Test Procedure”.
4.4 Security of the DRI system
The Direct Remote Identification system shall reduce the ability of tampering the functionality of the
direct remote identification system.
The Direct Remote Identification system is the on-board feature in the UA/Add-on that is formatting and
transmitting over the air the DRI information to a compatible receiver mobile device.
The scope of this document does not include the receiver mobile device; thus, this security requirement
does not apply to the receiver mobile device itself.
Specific considerations of this document regarding the security topic:
1. The UA and the Add-on come with a unique serial number; this number will be loaded at factory level
and shall not be modified anymore afterwards. The protection of the unique serial number of the
UA/Add-on shall be done by design. The serial number shall be stored in a secure memory area.
9

---------------------- Page: 11 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
2. This document does not include the capability to store securely the UAS operator registration
number.
3. This document does not include the capability to protect communication against user and/or
malicious modification of sensors output values involved in DRI information computation (like GNSS,
Barometer, Magnetometer, and Accelerometer…) and DRI radio-transmitter interface.
4. This document does not include the capability to protect against user and/or malicious software and
hardware modification, the geographical position, the timestamp, the height, the take-off position,
the speed, the route course, of the UA/Add-on.
5. This document does not include the capability to ensure DRI data integrity verification, the capability
to ensure detection that the UA/Add-on’s serial number is unique, when received by the Receiver
Mobile Device. However, to provide such capabilities, a Digital Signature may be added to the DRI
message.
6. This document does not include the capability to ensure DRI data received by the receiver mobile
device are genuine and come from a UA/Add-on belonging to a registered UAS Operator, the
capability to ensure detection of spoofing of the UAS Operator Registration Number. However, to
provide such capabilities, a Digital Signature may be added to the DRI message.
The conformity to requirement “1.” shall be proved per OEM’s design documentation.
4.5 Upload of UAS operator registration number
UAS class C1, C2, C3 and the DRI Add-on shall have a direct remote identification that allows the upload
of the UAS operator registration number and exclusively following the process provided by the
registration system.
The DRI system shall not accept to upload an invalid UAS operator registration number.
a) As shown in Figure 2, the unique UAS operator registration number issued by the Member States
should consist of 16 alphanumeric characters in total organized as the following:
1) three first alphanumeric characters corresponding to the ISO 3166 Alpha-3 code of the MS of
registration (upper case only); and
2) twelve following characters randomly generated consisting of alphanumeric characters (lower
cases only).
3) one character corresponding to checksum generated in line with point (c).
b) MS should randomly generate additional three alphanumeric characters (lower cases only). They will
be separated from the sixteen characters defined in (a) by a hyphen “-” (ASCII code DEC 45).
c) MS should generate a checksum by applying the Luhn mod-36 algorithm to the fifteen alphanumeric
characters resulting from the concatenation in the following order of:
1) the twelve last alphanumeric characters of the UAS operator registration number defined in (a)
(2); and
2) the three randomly “xyz” generated additional alphanumeric characters defined in (b)
10

---------------------- Page: 12 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)

Figure 2 — UAS Operator Registration Number format
For the Luhn mod-36 algorithm, the mapping characters to code-points starts with the digits, then the
lower-case letters as shown below:
Character 0 1 2 3 4 5 6 7 8 9 a b c d e f g h
Code-point 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Character i j k l m n o p q r s t u v w x y z
Code-point 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

An example of the UAS operator registration number is: “FIN87astrdge12k8” where:
• ‘FIN’ is the ISO 3166 Alpha-3 code of Finland,
• ‘87astrdge12k’ are an example of the twelve (12) alphanumeric characters, as specified in (a)(2)
in AMC1 Article 14(6) Registration of UAS operators and ‘certified’ UAS,
• ‘8’ is the checksum value, i.e. the result of the application of the Luhn mod-36 algorithm to the
15 alphanumeric characters resulting from the concatenation of the 12 last alphanumeric
characters of the UAS operator registration number defined in (a)(2) and the 3 randomly
generated additional alphanumeric characters defined in (b) (i.e. 87astrdge12kxyz). Please note
that the three alphanumeric characters corresponding to ISO 3166 Alpha-3 code, (in the example,
the string ”FIN”), are not used as a part of the checksum calculation, nor the hyphen character ”-
”.
An example of the full string point (e) of the AMC1 Article 14(6), to be provided by a Member State is
‘FIN87astrdge12k8-xyz’ where:
• ‘FIN87astrdge12k8’ is the UAS operator registration number
• ‘xyz’ are an example of 3 randomly generated alphanumeric characters.
‘8’ is the checksum provided value, to be verified during the UAS operator registration number upload
procedure;
The UAS operator registration number information consists of the UAS Operator Registration Number
(OPRN) the public part including a checksum character, and the three randomly generated Secure
Characters, the private part. Both parts are delivered to the operator from the Member State registration
11

---------------------- Page: 13 ----------------------
oSIST prEN 4709-002:2021
prEN 4709-002:2020 (E)
system. The intention is that both parts are entered into the DRI System when uploading the operator
registration number. The DRI System will use both parts to recalculate a checksum on its side and check
the match.
However, the DRI System will only broadcast the public part (including the checksum). The private part
is not stored in the UA and is not broadcast.

Figure 3 — UAS Operator Registration Number (OPRN) public and private parts
In the example used above, the public part is the string “FIN87astrdge12k8” and the private part is the
string “xyz”.
Example of application of the Luhn mod-36 algorithm to the following 15 alphanumeric characters
“87astrdge12kxyz”:
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.