Cwa-documentation: Risk calculation with ENFv2: Clarify action when signal attenuation is between 63 dB and 73 dB

[vaggelisdouros]

In the updated diagram for risk calculation with enf v2, it is unclear to me how the time where the signal attenuation is between 63 dB and 73 dB is taken into account. Unless there is a typo, It seems that this signal is considered harmless and does not take part in the calculation of the weighted exposure time (even with a 0.5 coefficient), therefore i do not really understand whether the threshold is set to 73 db or 63 dB https://github.com/corona-warn-app/cwa-documentation/blob/master/images/risk_calculation/risk_calculation_enf_v2_overview.pdf

---

Internal Tracking ID: EXPOSUREAPP-4445

[MikeMcC399]

I also have the question:

• why not drop encounters >= 63 dB immediately instead of first filtering using < 73 dB?

If I understood the diagram correctly, then encounters >= 63dB are disregarded for any risk calculation.

[vaggelisdouros]

@MikeMcC399 in other words, if we understand correctly, then whenever two phones have a distance of at least 3 meters (this is what the app considers as 63 dB), then, no matter how long their interaction will be, the app considers it as harmless

[heinezen]

Hey @vaggelisdouros ,

Thank you for the question. I have asked the development team to clarify this and created a internal Jirra ticket for this request (ticket ID: EXPOSUREAPP-4445). We will update the documentation and FAQ entries accordingly.

why not drop encounters >= 63 dB immediately instead of first filtering using < 73 dB?

As far as I understand it from the diagram, the encounter with signal attenuation 63 dB <= x < 73 are still shown as encounters in the app, while the ones > 73 dB are not. However, we will try to get an official answer fro the devs.

Best Regards,
CH

---

Corona-Warn-App Open Source Team

[tklingbeil]

Hi @vaggelisdouros:

The reason why there is this range between 63dB and 73dB is to allow shorter (i.e. <10 minutes), more critical encounters be counted (i.e. <63dB or even <55), as long as the overall encounter has been long enough.

I'll try to clarify this with an example.

Let's look at the following example Exposure Window:

There we've got two scan instances (assumed 3 minutes apart), one at ~59dB, one at ~52dB. However, they could also result from just a short encounter, e.g. at the supermarket.

Now there's this second example:

As you can see here, there's three additional scan instances (above 63dB). This indicates, that this was definitely was an encounter - and that it has lasted long enough to count. Even though, the times with the larger attenuation don't count in, they give us a hint that this should count in.

Now, the 6 minutes are weighted (30.5+31.0)=4.5 and multiplied with the factor of TRL VIII (1.6) = 7.2 minutes. Three of those encounters would be required on a single day to turn the status red.

[MikeMcC399]

@tklingbeil
That makes sense. Thank you!

The diagram risk_calculation_enf_v2_overview.pdf is not enough to understand exactly how the calculation takes place, also it doesn't explain any of the reasoning about why it is done this way.

Do you know if the document How does the Corona-Warn-App identify an increased risk? - cwa-risk-assessment.md regarding risk calculation using v2 of the GAEN framework will soon be updated and published?

[hoehleatsu]

The two diagrams are helpful, but I have a couple of questions regarding the two figures:

1) The exposure windows are all with the same diagnosis key, right?

2) What is the time axis in the two figures, i.e. what's time zero? If in the first figure the second scan instance would not have been there, then the entire encounter would not have counted, because it does not have a duration. Or am I mistaken here?

3)

There we've got two scan instances (assumed 3 minutes apart), one at ~59dB, one at ~52dB. However, they could also result from just a short encounter, e.g. at the supermarket.

The app will not be able to tell the difference, and I always thought some kind of average is computed for the attenuation value to score the entire encounter/exposure window. Or has this completely changed with the new version of the ENF?

Altogether, I agree with @MikeMcC399: With the current state of documentation, the risk scoring is not really transparent anymore. It's been out-of-date for a while (since September), but with the change to the new ENF, it is even less clear what's going on. That's a really dissapointing for an app, which builds on trust and public acceptance...
(see also slides 21-22 of https://staff.math.su.se/hoehle/talks/hoehle-riskscoring2020.pdf)

[daimpi]

I agree with @hoehleatsu and @MikeMcC399. Please update the risk-assessment doc or at least put a disclaimer on top of the doc for now, signifying that the page is out of date as suggested by @MikeMcC399 here.

Related issue: https://github.com/corona-warn-app/cwa-documentation/issues/426

[tklingbeil]

@hoehleatsu
1: Yes. Only one diagnosis key (i.e. one other device) per Exposure Window. If multiple encounters overlap, there are multiple windows. Those windows are not aligned with each other.

1. 0 is either a) the first time an RPI belonging to a new Diagnosis Key is detected b) the first scan within a new exposure window, if the one before has reached 30 minutes already. Note on the side: Multiple Exposure Windows belonging to the same DK cannot be related to each other - there's also no timestamp on those EWs, so if there are multiple windows for a day, it's not possible to tell, which came first.
2. This has completely changed. While the V1 only used an average, with V2 the app now gets the minimum and average attenuation for each scan instance. One scan instance might contain multiple scans of the same RPI/DK, as they are supposed to be broadcasted every 250ms.

[MikeMcC399]

@vaggelisdouros
I appreciate your time in posting this question, which I also didn't understand at the time. So I'm very glad that @tklingbeil was able to provide us with his insight and know-how.

If you think that your question has been answered, you could close the issue.

[Ein-Tim]

Your questions have been answered, or @vaggelisdouros?

If yes, please close this issue, thanks!

(@dsarkar FYI)