ETSI GS E4P 006 V1.1.1 (2021-05)

Europe for Privacy-Preserving Pandemic Protection (E4P); Device-Based Mechanisms for pandemic contact tracing systems

DGS/E4P-006

General Information

• Status: Not Published
• Technical Committee: E4P - Europe for Privacy-Preserving Pandemic Protection
• Current Stage: 12 - Completion
• Due Date: 25-May-2021
• Completion Date: 25-May-2021

Standards Content (Sample)

GROUP SPECIFICATION
Europe for Privacy-Preserving Pandemic Protection (E4P);
Device-Based Mechanisms
for pandemic contact tracing systems
Disclaimer
The present document has been produced and approved by the Europe for Privacy-Preserving Pandemic Protection ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS E4P 006 V1.1.1 (2021-05)

Reference
DGS/E4P-006
Keywords
covid, eHealth, emergency services, identity,
mobility, pandemic, privacy, security, smartphone

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2021.
All rights reserved.
ETSI
3 ETSI GS E4P 006 V1.1.1 (2021-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 10
3.3 Abbreviations . 10
4 General description. 11
4.1 Reference device architecture . 11
5 Device-based mechanisms for pandemic contact tracing systems . 12
5.1 Contact proximity detection . 12
5.1.1 Contact proximity detection technical options . 12 ®
5.1.2 Bluetooth LE usage . 13 ®
5.1.2.1 Bluetooth LE usage requirements . 13 ®
5.1.2.2 Bluetooth LE API usage . 13 ®
5.1.3 Bluetooth LE advertisement mode . 13 ®
5.1.4 Bluetooth LE RSSI measurement suitability for proximity detection. 14 ®
5.1.5 Bluetooth LE calibration . 17
5.1.6 Decentralized approach . 18
5.1.6.1 Calibration in Google Apple Exposure Notification (GAEN) . 18
5.1.7 Centralized approach . 18
5.1.7.1 Calibration in the French TousAntiCovid/ROBERT digital exposure notification tool . 18
5.1.7.2 Calibration in DESIRE protocol . 18
5.2 Anonymous contact identification . 19
5.2.1 Contact identification protocols . 19
5.2.2 Decentralized approach . 19
5.2.2.1 Anonymous contact identification in GAEN . 19
5.2.2.1.1 The GAEN protocol . 19 ®
5.2.2.1.2 Bluetooth message structure in GAEN . 20
5.2.2.2 Decentralized Privacy-Preserving Proximity Tracing (DP-3T) . 20
5.2.3 Centralized approach . 21
5.2.3.1 ROBERT . 21
5.2.3.1.1 ROBERT protocol . 21 ®
5.2.3.1.2 Bluetooth message structure in ROBERT . 21
5.2.3.1.3 Underlying assumptions for ROBERT: adversarial model . 22
5.2.3.2 DESIRE . 22
5.2.3.2.1 DESIRE protocol . 22 ®
5.2.3.2.2 Bluetooth message structure in DESIRE . 23
5.3 Contact data storage . 24
5.3.1 General considerations . 24
5.3.2 Decentralized approach . 24
5.3.3 Centralized approach . 25
5.3.3.1 Robert . 25
5.3.3.2 ROBERT protocol . 25
5.3.3.3 DESIRE protocol . 25
5.4 User experience and usability . 26
6 Requirements mapping to device functions and interfaces . 27
ETSI
4 ETSI GS E4P 006 V1.1.1 (2021-05)
Annex A (informative): Matching with ETSI GS E4P 003 'Requirements for Pandemic
Contact Tracing Systems using mobile devices' . 28
History . 29

ETSI
5 ETSI GS E4P 006 V1.1.1 (2021-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association. ®
BLUETOOTH is a trademark registered and owned by Bluetooth SIG, Inc.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Europe for
Privacy-Preserving Pandemic Protection (E4P).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The COVID-19 pandemic has generated significant challenges for many countries and their citizens and showed that
digital technologies could play an important role in addressing this pandemic and future pandemics. Various
applications, services and systems for contact tracing (identification and notification of those who come in contact with
a carrier) have been developed in different regions.
Despite the similar goal of automated detection of COVID-19 exposure as a complementary solution to manual tracing
(interviews with people diagnosed with COVID-19 to track down their recent contacts), their functionality, technology,
scale, required data and limitations are different and may not interoperate.
ETSI
6 ETSI GS E4P 006 V1.1.1 (2021-05)
These systems are currently being deployed in different countries and many more are expected in the near future. In
particular, mobile devices with their contact tracing applications can support public health authorities in controlling and
containing the pandemic. In that purpose, E4P has been created to provide a technical answer to pandemic crisis not
limited to COVID-19 by specifying interoperable contact tracing systems.
ETSI
7 ETSI GS E4P 006 V1.1.1 (2021-05)
1 Scope
The present document sets out device based features which pandemic contact tracing systems should meet to ensure
their performance and compliance with the ETSI E4P system requirements and interoperability framework defined in ®
ETSI GS E4P 003 [1] and ETSI GS E4P 007 [i.21]. Systems based on a smartphone with cellular and Bluetooth
connectivity will be studied as the first priority and other solutions could be considered later.
In the context of tracing persons potentially infected with a transmittable virus such as SARS-CoV-2, the ISG E4P
develops a framework and consistent set of specifications for proximity tracing systems, to enable the development of
applications and platforms, and to facilitate international interoperability as defined in ISG E4P
Terms of Reference [i.1]. The present document describes device based mechanisms for the Pandemic Tracing
Systems.
In particular, the present document specifies various Proximity Detection Methods for Pandemic contact tracing
systems, including:
• Proximity detection of contacts
• Anonymous identification of contacts
• Storage requirements for proximity data of contacts
• User experience and usability
Solutions are specified in technical detail so that means of interoperability between different systems and methods can
also be readily defined in ETSI GS E4P 007 [i.21] "Pandemic proximity tracing systems: Interoperability framework".
Each method is characterized (e.g. in a table) by its degree of compatibility with the ETSI GS E4P 003 [1].
The present document relates to ETSI GR E4P 002 [i.20] "Comparison of existing pandemic contact tracing systems"
ETSI GS E4P 003 [1] "Requirements for Pandemic Contact Tracing Systems using mobile devices" and ETSI
GS E4P 008 [2] "Back-End mechanisms for pandemic contact tracing systems". In addition, it will be used as an input
to ETSI GS E4P 007 [i.21] "Pandemic proximity tracing systems: Interoperability framework".
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS E4P 003 (V1.1.1): "Europe for Privacy-Preserving Pandemic Protection (E4P); High
level requirements for pandemic contact tracing systems using mobile devices".
[2] ETSI GS E4P 008 (V1.1.1): "Europe for Privacy-Preserving Pandemic Protection (E4P);
Back-End mechanisms for pandemic contact tracing systems". ®
[3] Bluetooth Core Specification V5.2.
[4] ETSI EN 301 549: "Accessibility requirements for ICT products and services".
ETSI
8 ETSI GS E4P 006 V1.1.1 (2021-05)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI ISG E4P Terms of Reference (ToR) for "Europe for Privacy-Preserving Pandemic Protection
(E4P)", Version 1.1, 8 May 2020.
[i.2] Google API for Exposure Notification - Exposure Notification BLE attenuations.
NOTE: Available at https://developers.google.com/android/exposure-notifications/ble-attenuation-overview.
[i.3] "The Strength of Friendship Ties in Proximity Sensor Data", Vedran Sekara, Sune Lehmann,
Published: July 7, 2014.
NOTE: Available at https://doi.org/10.1371/journal.pone.0100915. ®
[i.4] "Exposure Notification Bluetooth Specification", v1.2 April 2020, Google Apple.
NOTE: Available at https://blog.google/documents/70/Exposure_Notification_-
_Bluetooth_Specification_v1.2.2.pdf.
[i.5] "Exposure Notification Cryptography Specification", v1.2 April 2020, Google Apple.
NOTE: Available at https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-
tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf?1.
[i.6] Decentralized Privacy-Preserving Proximity Tracing GitHub repository.
NOTE: Available at https://github.com/DP-3T/bt-measurements/tree/master/figures.
[i.7] CTIA Test Plan for Wireless Device Over-the-Air Performance, Method of Measurement for
Radiated RF Power and Receiver Performance, Version 3.8.1, October 2018.
NOTE: Available at https://api.ctia.org/wp-content/uploads/2019/04/CTIA_OTA_Test_Plan_3_8_2.pdf.
[i.8] Google API for Exposure Notification - Exposure Notifications BLE RSSI calibration procedure.
NOTE: Available at https://developers.google.com/android/exposure-notifications/ble-attenuation-procedure. ®
[i.9] Android™ API Reference Bluetooth Low Energy.
NOTE 1: Available at https://developer.android.com/reference/android/bluetooth/le/package-summary.
NOTE 2: Android is a trademark of Google LLC. ®
[i.10] Apple Developer Documentation Core Bluetooth Framework.
NOTE: Available at https://developer.apple.com/documentation/corebluetooth. ®
[i.11] Apple Documentation Archive - Core Bluetooth Background Processing for iOS Apps.
NOTE 1: Available at
https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBlue
tooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInT
heBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW1.
NOTE 2: IOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used by Apple
under license.
ETSI
9 ETSI GS E4P 006 V1.1.1 (2021-05)
[i.12] PRIVATICS team, Inria, France, Fraunhofer AISEC, Germany, "ROBERT: ROBust and privacy-
presERving proximity Tracing, version 1.1", May 31st, 2020.
NOTE: Available at https://github.com/ROBERT-proximity-tracing/documents, https://hal.inria.fr/hal-
02611265/en/.
[i.13] C. Castelluccia, N. Bielova, A. Boutet, M. Cunche, C. Lauradoux, D. Le Metayer, V. Roca,
"DESIRE: A Third Way for a European Exposure Notification System Leveraging the best of
centralized and decentralized systems, version 1.0", May 2020.
NOTE: Available at https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE,
https://hal.inria.fr/hal-02570382/en/.
[i.14] J-M. Gorce, M. Egan, R. Gribonval, "An efficient algorithm to estimate Covid-19 infectiousness
risk from BLE-RSSI measurements".
NOTE: Available at https://hal.inria.fr/hal-02641630/en/.
[i.15] G. Kessibi, M. Cunche, A. Boutet, C. Castelluccia, C. Lauradoux, D. Le Metayer, V. Roca,
"Analysis of Diagnosis Key distribution mechanism in contact tracing applications based on
Google-Apple Exposure Notification (GAEN) framework (version 1.2)", September 2020.
NOTE 1: Available at https://hal.inria.fr/hal-02899412/en/.
NOTE 2: https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE. ®
[i.16] M. Cunche, A. Boutet, C. Castelluccia, C. Lauradoux, V. Roca, "On using Bluetooth -Low-
Energy for contact tracing (version 1.3)", September 2020.
NOTE: Available at https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE and
https://hal.inria.fr/hal-02878346/en/.
[i.17] Swiss Confederation, "Replay Attacks", June 14th, 2020, section "Unmasking users by
eavesdropping EphIDs".
[i.18] Tijmen Schep, "Corona Detective".
NOTE: Available at https://www.coronadetective.eu/.
[i.19] O. Seiskari, "BLE contact tracing sniffer PoC".
NOTE: Available at https://github.com/oseiskar/corona-sniffer.
[i.20] ETSI GR E4P 002: "Europe for Privacy-Preserving Pandemic Protection (E4P); Comparison of
existing pandemic contact tracing systems".
[i.21] ETSI GS E4P 007 (V1.1.1): "Europe for Privacy-Preserving Pandemic Protection (E4P);
Pandemic proximity tracing systems: Interoperability Framework".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
diagnosis key: secret code from which ephemeral identifiers for a given period of time can be derived with the help of a
cryptographic function
ephemeral identifier: unique device identifier exchanged with another device during a proximity event
proximity event: event recorded by the software on a mobile device corresponding to proximity to other device with an
active interoperable application, and which meets the predefined criteria for an event to be recorded (e.g. duration)
ETSI
10 ETSI GS E4P 006 V1.1.1 (2021-05)
3.2 Symbols
For the purposes of the present document, the following symbols apply:
dB decibel
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADV_IND Advertisement Indication
AES Advanced Encryption Standard
API Application Programming Interface ®
Bluetooth LE Bluetooth Low Energy
CID Content IDentifier
CT Clearance Time
DB Device - Backend
DD Device - Device
DP-3T Decentralized Privacy-Preserving Proximity Tracing
DPA Data Protection Authority
DUT Device Under Test
E4P Europe for Privacy-Preserving Pandemic Protection
EBID Ephemeral Bluetooth IDentifier
ECC Encrypted Country Code
FSPL Free Space Path Loss
GAEN Google Apple Exposure Notification
GDPR General Data Protection Regulation
GR Group Report
GRX receiving Bluetooth device antenna gain [dB]
GS Group Specification
GTX transmitting Bluetooth device antenna gain [dB]
HKDF Hashed Key Derivation Function
iOS iOS Operating System
ISG Industry Specification Group
ISM Industrial Scientific Medical band
LE Low Energy
MAC Medium Access Control
NTP Network Time Protocol
PDU Protocol Data Unit
PET Private Encounter Token
PRF PseudoRandom Function
PRG PseudoRandom Generator
QR Quick Response (code)
RF Radio Frequency
ROBERT ROBust and privacy-presERving proximity Tracing
RPI Rolling Proximity Identifier
RSSI Received Signal Strength Indicator
SID EBID Slice IDentifier
SIG Special Interest Group
TEK Temporary Exposure Key
TRP Total Radiated Power
TRP Total Radiated Power
TX Transmit
UD User - Device
UUID Universal Unique IDentifier
XOR eXclusive OR
ETSI
11 ETSI GS E4P 006 V1.1.1 (2021-05)
4 General description
4.1 Reference device architecture
The generic reference E4P device architecture is depicted in Figure 1. It describes a user device and its interactions with
other components of the system such as its users, Back-End system (described in ETSI GS E4P 003 [1] as part of the
Infrastructure) and other devices. It also introduces three corresponding external reference points and interfaces as
follows:
a) Reference point UD (User - Device) - User interface.
b) Reference point DB (Device - Back-End System) - Back-End interface.
c) Reference point DD (Device - Device) - Contact proximity detection interface.
The contact tracing protocols are based on decentralized or centralized design approach as defined in ETSI
GS E4P 003 [1]). Based on the model of digital contact tracing system defined in ETSI GS E4P 003 [1], main internal
device functions implementing pandemic contact tracing Mobile Application as defined in ETSI GS E4P 003 [1] are
described in the following clauses of the present document and are also shown in Figure 1.
NOTE: Optional architecture elements and functions are shown in dotted lines.
These include:
a) User interface - describes requirements related to interaction between the user and the device (as defined in
ETSI GS E4P 003 [1]).
b) Contact proximity detection - describes proximity detection method requirements as defined in ETSI
GS E4P 003 [1].
c) Anonymous contact identification - describes anonymous contacts identification requirements. This function
shall be present in the Device for decentralized approach only as it shall be implemented in Back-End for the
centralized approach.
d) Contact data storage - describes requirements for data storage and contact tracing protocol between the
device and the Back-End. This function may also include Ephemeral IDs generation sub function if it is not
implemented in the Back-End.
Detailed architecture of the Back-End system is out of scope of the present document and is described in ETSI
GS E4P 008 [2]. High level requirements related to unique device identifiers exchanged on DD interface (Ephemeral
IDs) are defined in ETSI GS E4P 003 [1].
ETSI
12 ETSI GS E4P 006 V1.1.1 (2021-05)
Reference point DU Reference point DB
(User interface) (Back-End interface)
User (U)
Reference point DD
(Contact proximity detection interface)

Figure 1: Reference E4P device architecture
5 Device-based mechanisms for pandemic contact
tracing systems
5.1 Contact proximity detection
5.1.1 Contact proximity detection technical options
Almost all mobile device-based proximity tracing protocols, both centralized and decentralized, proposed so far suggest ®
using radiated transmit power of advertisement packets or signal attenuation of Bluetooth Low Energy (LE) signals as
a substitute for spatial proximity. This information combined with the duration of exposure for the past few days is used
for infection risk score calculation and subsequent notification based on exceeding a threshold.
The Bluetooth LE Received Signal Strength Indicator (RSSI) measurements can be affected by a number of factors such
as antenna sensitivity, device orientation and environmental conditions which makes it challenging to use it for distance
estimation. The signal attenuation is defined as the difference between the transmission power at the sending device and
RSSI. The difficulty in measuring the distance based on the attenuation arises due to signals being noisy. The multipath
and shadowing effects due to walls, objects and people also affect signal propagation, however the authors of
Decentralized Privacy-Preserving Proximity Tracing (DP-3T) [i.3] have conducted experiments to show that rarely do
these hurdles decrease the attenuation and use this fact to propose a mechanism for distance estimation between two
devices.
ETSI
13 ETSI GS E4P 006 V1.1.1 (2021-05)
The authors show that below 50 dB of attenuation there is a good chance that devices are within 2 meters of each other,
which is a suggested minimum distance to avoid contacting infection. Further calibration is applied at both the sending
and receiving device to account for the variance in transmission power and RSSI measurements across device models.
The key goal of the approach presented by the authors is not to accurately measure the distance between devices but to
estimate the breach of the 2-meter threshold, accurate distance measurement is rather challenging considering the
diversity of operation environments and low Bluetooth LE beaconing frequency.
ISG E4P also propose using the Google Apple Exposure Notification (GAEN) approach, which exchanges
advertisements with neighbouring devices every 2,5 to 5 minutes, to estimate the proximity using a probabilistic
measure of distance by observing the received beacon attenuation level. Thus, allowing a receiver to estimate the
overall duration of time it was exposed at an attenuation level using a set of beacons and corresponding attenuations
received. ®
5.1.2 Bluetooth LE usage ®
5.1.2.1 Bluetooth LE usage requirements
[DCP-01]: Bluetooth LE is a subset of Bluetooth. Its full description can be found in the clause 4.5 of the Bluetooth
specification [3]. The contact proximity detection function in a mobile device of a contact tracing system can use
Bluetooth LE to do a contact proximity detection. For this purpose, the Bluetooth component of the mobile device shall
comply with clause 4.5 of Bluetooth specification [3].
[DCP-02]: The contact proximity detection function in a mobile application shall be able to use the Bluetooth LE
capabilities via the Bluetooth LE API of the mobile device. All Bluetooth LE functions and parameters shall be
accessible via the Bluetooth LE API of a mobile device.
NOTE 1: The instructions how to use the Bluetooth LE API by a mobile application are described in [i.9] for
Android mobile devices and in [i.10] for IOS mobile devices.
NOTE 2: Bluetooth LE is also used in a dedicated API called GAEN [i.4] that can be used in the contact proximity
detection function of the decentralised contact tracing system application to do all the contact proximity
detection functions. The Bluetooth LE setup is defined in the GAEN API and cannot be modified. ®
5.1.2.2 Bluetooth LE API usage
Bluetooth LE API shall be used in any centralized approach as the GAEN API is not applicable However, the Bluetooth
LE API can also be used in a decentralized approach without relying on GAEN API.
The use of the Bluetooth LE API can lead to some restriction to the Bluetooth LE functions on Apple mobile devices
when the application is running in background mode or in suspended mode [i.11]. These restrictions are not inherent to
Bluetooth LE, but the result of choices made in iOS to prevent malicious applications that leverage on Bluetooth LE.
These restrictions most likely could be modified in iOS at any time. In the meantime, workarounds are required to
bypass up to a certain point these restrictions. One working workaround is the presence of a Bluetooth LE beacon or
Android device broadcasting which leads to wakening up of the app running on iOS. With the French
StopCovid/TousAntiCovid application, the presence of Android versions of the application is required to wakeup iOS
versions of the application. These workarounds are very specific and are not further described in the present document. ®
5.1.3 Bluetooth LE advertisement mode
[DCP-04]: Bluetooth LE can be used in the contact proximity detection function to make continuous advertisement of a
given contact tracing service and, in the same time, to share a specific payload used to assess proximity with a user that
shall be anonymised.
This clause describes the advertisement modes and recommended advertisement payload for contact proximity
detection.
[DCP-05]: Two Bluetooth LE advertisement modes are available for the contact proximity detection function and the
mobile application can use either or both modes. They are defined as follows:
a) Bluetooth LE Broadcast mode - consists of broadcasting advertisement together with payload required to
make the proximity detection. The broadcast mode shall use PDU type ADV_NONCONN_IND as described
in Bluetooth Sig Vol.6 Part B, clauses 2.3 and 2.3.1.3 of [3].
ETSI
14 ETSI GS E4P 006 V1.1.1 (2021-05)
b) Bluetooth LE Connected mode - consists of broadcasting in the first step only the advertisement of the
service and in the second step, connecting with another device to share contact data required to make the
proximity detection. The broadcast mode shall use PDU type ADV_ IND as described in Bluetooth Sig Vol.6
Part B, clauses 2.3 and 2.3.1.2 of [3].
[DCP-06]: Both Bluetooth LE advertisement modes in the contact proximity detection function shall use the physical
layer LE1 as described in Bluetooth Sig Vol.1 Part A, clause 1.2 of [3]. Advertising physical channel Protocol Data
Unit (PDU) is described in Bluetooth Sig Vol.6 Part B, clause 2.3 of [3].
[DCP-07]: A Universally Unique Identifier (UUID) shall be used by the contact proximity detection function to allow
service discovery of the contact tracing service. The UUID shall be registered to Bluetooth SIG. ®
5.1.4 Bluetooth LE RSSI measurement suitability for proximity detection
The reported Bluetooth LE RSSI to estimate the distance between the two Bluetooth devices is based on a number of
parameters, which are described in the following Free Space Path Loss (FSPL) equation 1:
��������=20������+20������−27,55��−���−��� (1)
where:
• d- distance between the two Bluetooth LE devices [m];
• f - communication frequency [MHz];
• GTX - transmitting Bluetooth device antenna gain [dB];
• GRX - receiving Bluetooth device antenna gain [dB].
The frequency f is known as it is based on the Industrial, Scientific and Medical (ISM) bands used in Europe in the
frequency range 2,4 - 2,5 GHz. GTX and GRX are not known a priori even if they are based on the technical
specifications of the device (brand and model). In addition, the Bluetooth LE device may introduce another correction
factor in the conversion between the received power and the RSSI provided to the application layer. The GTX, GRX
and the correction factor are all unknowns which can negatively impact the proper evaluation of the distance from the
reported RSSI.
The position of the Bluetooth LE devices (e.g. mobile phones) determine different values of GTX and GRX on the basis
of the radiation patterns of the receiver and transmitter Bluetooth device. Such radiation patterns are also different for
each polarization used in the wireless communication Bluetooth standard.
If the coordinated system is used as described in Figure 2, the radiation pattern of various models of phones were
measured in a calibrated shielded anechoic chamber at the Joint Research Centre facilities of the European Commission
in Ispra, Italy. An example of such radiation pattern is reported in Figure 3.
®
Figure 2: Position of the Bluetooth LE device (smartphone) in the coordinate system
ETSI
15 ETSI GS E4P 006 V1.1.1 (2021-05)

Figure 3: An example of a reported radiation pattern for two different polarizations
for a smart phone model
It can be seen from Figure 3 that the radiation patterns vary significantly with the value of the angles. As a result, the
power received by a mobile phone for the proximity detection from another phone will vary significantly for different
positions and orientations of the phone. This observation is confirmed with the result of experiments conducted on
different phone models, which are reported in Table 1 below:
Table 1: Peak and average gain for different polarizations for different phone models
Mobile Phone Model Peak Gain Peak Gain Median Gain Median Gain
Theta Polarization Phi Polarization Theta Polarization Phi Polarization
(dBi) (dBi) (dBi) (dBi)
Model 1 -3,8 -6,2 -10,8 -16,7
Model 2 -10,6 -10,9 -18,4 -20,8
Model 3 -1,0 -0,7 -8,2 -12,3
Model 4 -7,4 -7,4 -16,5 -18,1
Model 5 -10,7 -11,0 -19,9 -18,5
Model 6 -12,0 -5,8 -24,5 -20,0
Model 7 +4,5 +0,9 -2,9 -10,2
Model 8 +4,0 +3,3 -3,9 -7,4
Model 9 -7,0 -7,8 -14,6 -21,0
Model 10 -4,4 -4,9 -17,0 -17,2

ETSI
16 ETSI GS E4P 006 V1.1.1 (2021-05)
As it can be seen from Table 1, different models have significant differences even in the peak and average gain, which
means that even in ideal positions of the Bluetooth LE devices, the calculated distance for the proximity detection may
not be easily derived from the reported RSSI and a correction factor shall be introduced, which depends on the
orientation of the Bluetooth device. Finally, even the total radiated power of a Bluetooth LE device can have variations
among different models.
The Total Radiated Power (TRP) is calculated from equation 2 [i.7].
�
��� ���
��� ≅ ∑∑ ����� ��,��+���� ��,��������� (2)
��� ��� � � � � � � �
���
where:
• TRP - Total Radiated Power calculated for a complete sphere;
• N - number of theta intervals with even angular spacing;
• M - number of phi intervals with even angular spacing;
• EiRP - Effective Isotropic Radiated Power [dBi].
Using the same experimental data set used for the previous results, the total radiated power was calculated for the same
models of Bluetooth LE devices (i.e. mobile phones) listed before. The results are shown in Table 2.
Table 2: Total radiated power for different models
Mobile Phone Model Tx Power (dBm) TRP (dBm) Efficiency (dB)
Model 1 -2 -9,4 -7,4
Model 2 +1 -12,5 -13,5
Model 3 -1 -4,7 -3,7
Model 4 -1 -12,3 -11,3
Model 5 +1 -12,5 -13,5
Model 6 +1 -11,3 -12,3
Model 7 -1 -0,15 +0,85
Model 8 0 +0,74 +0,74
Model 9 +12 +1,25 -10,8
Model 10 +12 +1,8 -10,2
Table 2 indicates two different observations. The first is that the total radiated power can still vary significantly across
models. This can create problems in the calculation of the distance from the RSSI as each Bluetooth LE device will
generate the Bluetooth signals with different levels of power. Then, a correction factor is needed for each phone model.
The second observation is that the efficiency is relatively low for mass market mobile phones. Then, presence of
obstacles, which can create higher levels of attenuation, can impact the correctness of the calculation of the distance for
the proximity detection even more.
ETSI
17 ETSI GS E4P 006 V1.1.1 (2021-05)
Limitations of Bluetooth LE signals as a ranging technology are shown in Figure 4 which shows the limited correlation
between the measured Bluetooth signal attenuation and the actual distance [i.6]. Especially for the shorter distance
range below 4 meters typically used for the contact proximity detection, the corresponding attenuation range is
significant which may impact the distance evaluation accuracy and cause proximity detection errors.
®
Figure 4: Measured correlation between Bluetooth LE signal attenuation and distance [i.6] ®
5.1.5 Bluetooth LE calibration
Bluetooth LE signal attenuation is not the best indicator of proximity due to being noisy but can offer some benefit if
used carefully. Each user device using contact proximity detection interface (reference point DD in the reference
architecture) based on Bluetooth will have a unique Bluetooth RF performance, based upon its Bluetooth chipset,
RF Front End and antenna design. This means that in order to utilise the reported Bluetooth RSSI to estimate the
distance between the two Bluetooth devices, there is a need to understand the difference in performance between each
device. Once the performance difference is understood it is possible to calculate a calibration factor to normalise the
reported RSSI with a known offset, typically measured on a 'reference' device. This will then allow the user device to
calculate approximated distance between devices from a lookup table of calibration values per device type. It is noted
rd
that 3 parties including Google have been working on solutions for calibration methods and publication of calibration
values and how to apply them within the device.
ETSI
18 ETSI GS E4P 006 V1.1.1 (2021-05)
5.1.6 Decentralized approach
5.1.6.1 Calibration in Google Apple Exposure Notification (GAEN)
At present (August 2020) for Android Bluetooth LE devices Google has made their work public, see [i.2]. The Google
Apple Exposure Notification (GAEN) approach proposes calibrating devices using a Bluetooth RSSI Calibration Tool
app and generating a per-device TX_power and RSSI_correction for increased accuracy. The procedure includes
collecting data with mobile devices in different orientations - portrait, landscape and facing skyward (12 device
orientations in total) and using it to predict calibration values. It is important to test various orientations as the readings
can vary by about 10 dB only based on the orientation.
The calibration software collects the uncalibrated RSSI that a stationary reference device (an Android phone) measures
when the Device Under Test (DUT) emits packets at ULTRA_LOW_POWER, LOW_POWER, MEDIUM_POWER
and HIGH_POWER to calculate TX_power.
The reference device is kept at a distance of
...