SIST EN 4709-002:2023

SLOVENSKI STANDARD
01-december-2023
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: EN 4709-002:2023
ICS:
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 4709-002
EUROPEAN STANDARD
NORME EUROPÉENNE
October 2023
EUROPÄISCHE NORM
ICS 03.220.50; 35.240.60; 49.020
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 European Standard was approved by CEN on 28 August 2023.

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. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists 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, Türkiye and
United Kingdom.
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
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 4709-002:2023 E
worldwide for CEN national Members.

Contents
European foreword . 4
Introduction . 5
1 Scope . 6
1.1 General. 6
1.2 Security . 6
1.3 DRI display software . 6
2 Normative references . 7
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 List of abbreviated terms . 8
4 General design requirements . 9
4.1 Conceptual overview . 9
4.2 Mandatory information . 10
4.3 Security of the DRI system . 10
4.4 Upload of UAS operator registration number . 11
4.5 Performance requirements . 15
4.6 Working time . 16
4.7 Add-on specific requirements . 16
5 Requirements for direct remote identification function. 16
5.1 Data dictionary . 16
5.2 DRI messages . 23
5.2.1 Message header . 23
5.2.2 Block message . 23
5.2.3 Basic ID message . 24

5.2.4 Location/vector message . 25
5.2.5 Self-ID message . 29
5.2.6 System message . 29
5.2.7 Operator ID message . 31
5.2.8 Message pack . 32
5.3 Broadcast transport protocols . 33
5.3.1 General. 33
5.3.2 Bluetooth legacy advertising transport mechanism (4.x compatible) . 33
5.3.3 Bluetooth long range advertising mechanism (5.x compatible) . 35
5.3.4 Wi-Fi NAN transport method . 42
5.3.5 Wi-Fi beacon transport method . 46
5.4 Output power . 47
5.5 Emission directivity . 48
5.6 Update and transmission rates . 48
6 Verification requirements and test methods . 49
6.1 Scope . 49
6.2 DRI generic test procedure . 49
6.2.1 General. 49
6.2.2 Upload UAS operator registration number test procedure . 49
6.2.3 UAS DRI data field transmission testing procedure . 49
6.3 Update and transmission rates test procedure . 52
6.3.1 General test setup . 52
6.3.2 Measurement procedure . 53
6.4 Remote ID compatibility with mobile device . 54
6.4.1 General test setup . 54
6.4.2 Measurement procedure . 55
Annex A (informative) Conformity methods and technical specifications references . 56
A.1 Requirement verification stage . 56
A.2 Wi-Fi, Bluetooth channels, bandwidth and frequencies . 56
Annex B (informative) Additional test procedures for verification of optional features of
the add-on DRI devices: UAS category of operation, UAS class . 57
B.1 Test setup . 57
B.2 UA category of operation configuration test procedure (for add-on only) . 57
B.3 UA class configuration test procedure (for add-on only) . 57
B.4 UA Category of operation transmission testing procedure (for add-on only) . 58
Annex C (informative) Guidelines for mobile device selection . 60
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. 61
Bibliography . 63

European foreword
This document (EN 4709-002:2023) has been prepared by the Aerospace and Defence Industries
Association of Europe — Standardization (ASD STAN) and is now under the responsibility of CEN/TC
471 ‘Unmanned aircraft systems.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by April 2024, and conflicting national standards shall be
withdrawn at the latest by April 2024.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
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.
A list of all parts in the 4709 series can be found on the CEN website: https://www.cencenelec.eu/.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: 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, Türkiye and the
United Kingdom.
Introduction
The European Commission adopted on the 12th of March 2019 the Delegated Regulation (EU)
2019/945 on unmanned aircraft systems and on third-country operators of unmanned aircraft systems.
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 Regulation 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 °C-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).
DRI display software
The following information is provided to clarify the assumptions made on the capability of compatible
mobile receiver devices to get DRI data interpretation and display capability.
As described in 4.1 the interested third party uses a receiver mobile device (such as a smartphone) with
specific RID Display Software to receive and display the information contained in Remote ID
broadcasted by an UA.
To be easily accessible, the display software is expected to be largely available to all interested third
parties.
The software is expected to display all mandatory information described in 4.2. A way to display remote
ID could be a map view showing the position of the UA(s) together with the position of the smartphone.
All transport methods for remote ID described in Clause 5 is expected to be processed and displayed by
the software to be used as a testing tool. As the transport methods have different hardware
requirements, a specific mobile receiver device may not be able to receive all transport methods.
The software is expected to show the user which transport methods are supported by the present
mobile receiver device.
1 Scope
1.1 General
This document provides means of compliance with the “Direct Remote Identification” requirements set
in Regulation (EU) 2019/945 on Unmanned Aircraft Systems.
“Direct remote identification” means a system that ensures the local broadcast of information about a
UA in operation.
More specifically, this document addresses drone’s 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) contributes to address security threats
and to support drones’ operators’ obligations with respect to citizens’ fundamental rights to privacy
and protection of personal data. It can be used by law enforcement people, critical infrastructure
managers, and public to get an instantaneous information on the drone flying around, providing various
information such as UA serial number, UA navigation data and operational status, UAS Operator
registration number and position as defined in the Delegated Regulation (EU) 2019/945.
Since Regulation (EU) 2019/945 requires DRI information to be broadcasted using an “open and
documented protocol”, this document does not define technological measures to protect the
confidentiality and integrity of the data broadcasted.
1.2 Security
This document is limited to ensure conformity of the UAS with the requirements set in Parts 2, 3, 4 and
6 of Regulation (EU) 2019/945. Therefore:
— 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 the DRI radio-transmitter interface;
— this document does not include the capability to protect against user and/or malicious software
and hardware modification of the geographical position, the timestamp, the height, the take-off
position, the speed, or the route course of the UA/add-on;
— this document does not include the capability to ensure DRI data integrity verification, or 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;
— 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, or 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.
1.3 DRI display software
Direct remote identification display software is not in the scope of this document. However, it is
assumed that compatible mobile receiver devices will support DRI data interpretation and display
capability.
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 300-328, V2.2.2:2019-07, Wideband transmission systems; Data transmission equipment
operating in the 2,4 GHz band; Harmonised Standard for access to radio spectrum
ETSI EN 300-440, V2.2.1:2018-07, Short Range Devices (SRD); Radio equipment to be used in the 1 GHz to
40 GHz frequency range; Harmonised Standard for access to radio spectrum
ETSI EN 301-893, V2.1.1:2017-05, 5 GHz RLAN; Harmonised Standard covering the essential
requirements of article 3.2 of Directive 2014/53/EU
EN ISO 3166-1:2020, Codes for the representation of names of countries and their subdivisions - Part 1:
Country code (ISO 3166-1:2020)
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 https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
add-on
standalone direct remote ID broadcast device integrating a GNSS function and a communication
function, being able to provide position, height, speed over ground, track clockwise with true north, of
the UA, and the remote pilot position or it’s take-off position
3.1.2
direct remote identification
DRI
system that ensures the local broadcast of information about a UA in operation so that this information
can be obtained without physical access to the UA
3.1.3
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 or UAS
operator registration ID.
3.2 List of abbreviated terms
AGL Above Ground Level
ASD-STAN Aerospace and Defence Industries Association of Europe - Standardization
C0, C1, C2, C3, Class 0 to Class 4 eligible for operations in the “Open” Category of UAS operations
C4
C2 link Command and Control link between UA and the GCS
C5, C6 Class 5 and Class 6 eligible for operations in the “Specific” Category under Standard
Scenarios
CAA Civil Aviation Authority
DRI Direct Remote ID/Identification
EASA European Union Aviation Safety Agency
EC European Commission
EDPS European Data Protection Supervisor
EMC Electro-Magnetic Compatibility
EMI Electro-Magnetic Interference
GCS Ground Control Station (EU regulation uses the equivalent term CU – Command
Unit)
GNSS Global Navigation Satellite System
GTRF Galileo Terrestrial Reference Frame
ICAO International Civil Aviation Organization
ID Identification
IEC International Electrotechnical Commission
ISO International Organization for Standardization
LE Little Endian
LSB Least Significant Byte
MS Member State
MSB Most Significant Byte
NAN (Wi-Fi) Neighbour Awareness Networking
NM Nautical Miles
OEM Original Equipment Manufacturer
RID Remote ID Display
RPAS Remotely Piloted Aircraft System
SDF Service Discovery Frame
GTRF is the reference ellipsoid for Galileo European satellite navigation system. GPS uses the WGS84 reference
ellipsoid. The maximum difference between WGS 84 and GTRF has been calculated to be less than 4 cm (around
3,6 cm 2 sigma) – see [16]. This is considered negligible with respect to the typical GNSS accuracy requirements
for aviation, which are in the order of several metres.
TU Time Unit (1 TU = 1024 microsecond)
UA Unmanned Aircraft
UAS Unmanned Aircraft System
UTC Coordinated Universal Time
UTM UAS Traffic Management
UUID Universally Unique Identifier based on IETF RFC4122
4 General design requirements
4.1 Conceptual overview
Figure 1 — DRI conceptual overview diagram
One or more UA are operating and broadcasting direct remote ID data. An interested third party or the
authority wants to identify the UA.
The UA continuously broadcasts remote ID data using one of the methods described in Clause 5.
The interested third party accesses a remote ID Display software (RID software) on a receiver mobile
device. This display software shows UA location and remote pilot position or take-off position if not
available, and a trail of position reports on a map, and associated identification information when a
particular UA is selected.
When the interested third party opens the remote ID software on a receiver mobile device (such as a
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 trail representing where the UA most recently flew,
beginning from the position that was received first;
2. the interested third party selects the Broadcast UA and views the corresponding ID information.
4.2 Mandatory information
The direct remote ID system shall broadcast locally the mandatory information listed below:
— identification information:
— the UAS operator registration number,
— the unique serial number of the UA (or exclusively the add-on);
— geolocation information:
— 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;
— UA status information:
— the UAS emergency status for Class C1, C2, C3. Not required for add-on.
The conformity to this requirement shall be proven by testing as specified in 6.2, “DRI generic test
procedure”.
4.3 Security of the DRI system
General security requirement:
— the direct remote identification system shall reduce the ability of tampering with the functionality
of the direct remote identification system.
NOTE 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 security requirements:
— the UA and the add-on come with a unique serial number; this number is 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;
— the design of the DRI shall not allow the user to modify the Geolocation information part of the DRI
message, as defined in 4.2 above.
The conformity to those requirements shall be proven per the OEM’s design documentation.
4.4 Upload of UAS operator registration number
UAS class C1, C2, C3 and the DRI Add-on shall have functionality that allows the upload of the UAS
operator registration number. The number is exclusively provided following the process for
registration based on Art. 14 of Regulation 2019/947. The detailed procedure to load the number in the
DRI system shall be defined by the manufacturer and covered by the instructions delivered to the
customer.
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
(MS) shall consist of 16 alphanumeric characters in total organized as the following:
1) three first alphanumeric characters corresponding to the EN ISO 3166-1:2020 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 shall randomly generate additional three alphanumeric characters (lower cases only). They are
separated from the sixteen characters defined in (a) by a hyphen “-” (ASCII code DEC 45).
c) MS shall 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).
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:
Table 1
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
EXAMPLE An example of the UAS operator registration number is: “FIN87astrdge12k8” where:
• ‘FIN’ is the EN ISO 3166-1:2020 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 EN ISO 3166-1:2020 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 system. The intention is that both parts are entered into the DRI System when uploading
the operator registration number. The DRI System uses both parts to recalculate a checksum on its side
and check the match.
However, the DRI System only broadcasts 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
Table 2
Character Code-point Double Reduce Sum of digits
8 8 16 (base 10)/g 16 16
(base 36)
7 7  7 7
a 10 20 (base 10)/k 20 20
(base 36)
s 28  28 28
t 29 58 (base 10)/1 1+22 23
m (base 36)
r 27  27 27
d 13 26 (base 10)/q 26 26
(base 36)
g 16  16 16
e 14 28 (base 10)/s 28 28
(base 36)
1 1  1 1
2 2 4 (base 10)/4 4 4
(base 36)
k 20  20 20
x 33 66 (base 10)/1 1+30 31
u (base 36)
y 34  34 34
z 35 70 (base 10)/ 1+34 35
1 y (base 36)
Sum of digits = 16 + 7 + 20 + 28 + 23 + 27 + 26 + 16 + 28 + 1 + 4 + 20 + 31 + 34 + 35 = 316.
Thus, 8 shall be added to 316 to get the number 324 so that 324 mod 36 = 0.
Result: checksum = 8
Another example of application of the Luhn mod-36 algorithm to the following 15 alphanumeric
characters “13azertyuiopabc”:
Sum of digit = 2 + 3 + 20 + 35 + 28 + 27 + 23 + 34 + 25 + 18 + 13 + 25 + 20 + 11 + 24 = 308
Result: checksum = g
A dedicated human interface is necessary to allow the user to enter the following data into the system:
the UAS operator registration number and the secure characters delivered by the member state at the
registration phase.
For any DRI implementation, a method shall be provided to allow users to enter the UAS operator ID,
check the consistency of the number, and store it in the device.
Based on the example above, the diagram hereafter describes the procedure to be implemented by the
UAS direct remote ID function or the add-on:
Figure 4 — UAS operator registration management flow
When an authority wishes to verify the broadcasted UAS operator registration number, the authority
has special access to the registration system for obtaining the private part. By recalculating the
checksum over the public and the private part and comparing against the checksum that was broadcast
from the UA, it is possible to determine whether the broadcasted registration number is valid or not.
The conformity to this requirement shall be proven by testing as specified in 6.2.
4.5 Performance requirements
This document defines several performance requirements:
— radio transmission performance: as radio-transmitting equipment, a DRI system shall comply with
relevant standards on radio-transmitting equipment: ETSI EN 301 893 for Wi-Fi 5GHz and
ETSI EN 300 328 V2.1.1 for Bluetooth and Wi-Fi 2,4 GHz (see Clause 2). These standards define
only maximum transmit power values. To guarantee minimum performance of a DRI system, the
DRI equipment shall comply with the minimum output power values defined in 5.4 and emission
directivity requirements defined in 5.5;
— data transmission and update rates: to allow proper identification and tracking of UA by observers,
the remote identification information shall be broadcasted periodically as defined in 5.6;
— direct remote identification information shall be received by existing mobile receiver devices (such
as a smartphone, tablet, laptop, or any kind of mobile device).
4.6 Working time
The information broadcasted by the DRI system shall be transmitted during the whole duration of the
flight (i.e. when the drone is airborne).
The broadcasted information can optionally also be transmitted when the drone is on the ground
(i.e. from switch-on to switch-off).
4.7 Add-on specific requirements
The DRI add-on device manufacturer shall provide:
— a user’s manual with the instructions to install the add-on on the UA: recommended location and
orientation regarding the antennas;
— a tool to configure the operator registration number, the class of the UA (and optionally the
category of operation, if this feature is implemented);
— instructions on how to upload the class of the UA, the category of operation and the operator
registration ID are also needed.
5 Requirements for direct remote identification function
5.1 Data dictionary
The block messages which are transmitted by broadcast DRI service, rely on a semantic model which is
defined as in Table 3; it includes the list of the required data fields for direct remote ID functionality,
including the minimum characteristics that shall be supported by broadcast implementations. Since
direct remote ID uses size-limited messages, some data fields require to use encoding methods that
adjust the resolution or aggregate ranges of values.
To ensure compatibility of data fields and protocols between delegated regulation requirements and
other specification requirements in the world, all the tables of Clause 5 below identify recommended
coded ‘R’, mandatory coded ‘M’ and optional coded ‘O’ values in the four rightmost columns named C1,
C2, C3, add-on.
‘M’ = Mandatory, means the data field answer to an explicit requirement from the delegated regulation,
consequently this data field shall be present in the global data set and its value correctly set.
‘O’ = Optional, means the data field doesn’t answer to an explicit requirement from the delegated
regulation, consequently this data field shall be present in the global data set and its value could be set
with the real value or set to null (i.e. null-characters if string or ‘0’ in numeric) or the value defined in
the table to be used when the value is unknown).
‘R’ = Recommended, means the data field doesn’t answer to an explicit requirement from the delegated
regulation, but ASD-STAN members representative of the industry, elaborating this standard
specification, recommend the presence of this data field in the global data set and its value correctly set.
In case a recommended field is not used, it shall be set to NULL.
Table 3 — Data dictionary
Data field Description/rationale C1 C2 C3 Add-on
UAS ID Four possible values (to ensure compatibility with

ASTM F3411-19):
1. Serial number → See ref. September 2019 edition of
M M M M
ANSI/CTA-2063-A serial number format.
2. UA registration ID → Likely given by the national CAA or an
O O O O
authorized representative.
3. UTM (UUID) → An ID given by an UTM entity and acting as
O O O O
“session ID” to avoid sensitive information leakage.
4. Specific Session ID → A unique 20-byte ID intended to identify
a specific flight (session) while providing a greater level of
privacy to the operator. The first byte is the universally unique
Specific Session ID Type maintained by an external registration
entity, and the remaining 19 bytes is the Session ID per the
Specific Session ID Type specification.
O O O O
Initial scheme registry entries should optionally include (to
ensure compatibility with ASTM F3411-19):
0 – reserved
1 – Internet Engineering Task Force (IETF) Drone Remote
Identification Protocol (DRIP) entity ID
2 – IEEE 1609.2–2016™ HashedID8
UAS ID Type Four possible values (to ensure compatibility with
ASTM F3411-19):
M M M M
1. serial number;
O O O O
2. registration ID; or
O O O O
3. UTM UUID;
O O O O
4. specific session ID.
UA Type Refer to Table 4 for values. O O O O
Classification Specifies the type of data in the UA Category and UA Class fields
R R R R
Type
UA Category The category of UAS operation as defined in Implementing
R R R R
Regulation (EU) 2019/947
UA Class The class of the UA as defined in the Delegated Regulation (EU)
R R R R
2019/945
Data field Description/rationale C1 C2 C3 Add-on
Timestamp The UTC time relevant to the acquisition of the position M M M M
information with a minimum resolution of one tenth of a second.
Special values: invalid, no value, or unknown are coded with
0xFFFF
ths
Timestamp Definition of the timestamp accuracy is 1/10 of seconds. It’s the O O O O
accuracy largest difference between timestamp and true time of
acquisition of the following parameters: latitude, longitude,
geodetic altitude, pressure altitude and height.
Operational Gives operational status of the UA, including UAS emergency M M M N/A
status status. Not applicable to add-on. Refer to Table 4 for values.
Operator ID Refer to 4.4 “Upload of UAS operator registration number”. M M M M
Latitude Limits from −90° to + 90°. Current latitude (within horizontal M M M M
accuracy limits) of the UA. The minimum resolution is at 7
decimal digits (~ 11 mm). Special values as invalid, no Value, or
Unknown are coded with 0 deg simultaneously for both latitude
and longitude.
Longitude Limits from −180° (excluded); +180° (included). Current M M M M
longitude (within horizontal accuracy limits) of the UA. This is
necessary to display UA location. Minimum resolution: 7 decimal
digits (~ 11 mm). Special values as invalid, no value, or unknown
are coded with 0 deg simultaneously for both latitude and
longitude.
Geodetic The aircraft distance above or below the ellipsoid as measured O O O O
altitude along a line that passes through the aircraft and is normal to the
surface of the WGS-84 ellipsoid. This value is given in meters
having a minimum resolution of 1 meter.
Special values as invalid, no value, or unknown are coded with
−1 000 m.
Pressure It is the elevation above a standard datum air-pressure plane O O O O
altitude (typically, 101,325 kPa). This value is given in meters having a
minimum resolution of 1 meter. Special values as invalid, no
value, or unknown are coded with −1 000 m.
Height Vertical distance of a UA position above take-off location or M M M M
height above the surface (AGL). This value is given in meters
having a minimum resolution of 1 meter.
Special values as invalid, no value, or unknown are coded with
−1 000 m.
Height type Height above take-off location or height above the surface (AGL). M M M M
Data field Description/rationale C1 C2 C3 Add-on
Geodetic Refer to Table 4 for values. This field indicates O O O O
vertical quality/containment on geodetic altitude. It derives from ADS-B
accuracy geodetic vertical accuracy (GVA).
Horizontal Refer to Table 4 for values. This field indicates O O O O
accuracy quality/containment on horizontal position. It derives from ADS-
B NACp.
Speed Refer to Table 4 for values. This field indicates O O O O
accuracy quality/containment on horizontal ground speed.
Track The direction of flight taken by the UA with reference to “True M M M M
direction North-based” ground track angle. It is measured in clockwise
degrees and has a minimum resolution of 1 degree. If the aircraft
is not moving horizontally, use the “Unknown” value. Special
values as invalid, no value, or unknown are coded with 361 deg.
Speed Ground speed of flight. This value is provided in meters per M M M M
second with a minimum resolution of 0,25 m/s. Special values as
invalid, no value, or unknown are coded with 255 m/s. In case the
speed is greater or equal than 254,25 m/s, the code value is
254,25 m/s.
Vertical Vertical speed upward in reference to the GTRF value; it is O O O O
speed measured in meters per second. Special values as invalid, no
value, or unknown are coded with 63 m/s.
In case the speed is greater or equal to 62 m/s, the code value is
62 m/s.
In case the speed is less than or equal to −62 m/s, the code value
is −62 m/s.
Remote pilot It informs about the remote pilot latitude position, or if not M M M M
latitude available, the take-off latitude position. Special values as invalid,
no value, or unknown are coded with 0 deg simultaneously for
both latitude and longitude.
Remote pilot It informs about the remote pilot longitude position, or if not M M M M
longitude available, the take-off longitude position. Special values as
invalid, no value, or unknown are coded with 0 deg
simu
...