Support for scenarios when API cannot return a devices count is needed

[gregory1g]

Problem description There are at least two scenarios when the API cannot provide a number of devices in the requested area: 1) number of devices in the area is below privacy threshold. 2) the operator does not have coverage in the requested area (permanently or temporary)

Possible evolution The API must explicitly inform API invoker about these situation. We can discuss if it must be modelled as an error or via an additional flag in the response.,

[bigludo7]

@gregory1g and team.

Perhaps we can take a look and see if it make sense to align with PopulationDensityData API and in particular the status attribute in the response

status: Represents the state of the response for the input polygon defined in the request, the possible values are:

SUPPORTED_AREA: The whole request area is supported. Population density data for the entire requested area is returned.
PART_OF_AREA_NOT_SUPPORTED: Part of the requested area is outside the MNOs coverage area, the cells outside the coverage area are not returned.
AREA_NOT_SUPPORTED: The whole requested area is outside the MNOs coverage area. No data will be returned_

Perhaps we can add a fourth value DENSITY_BELOW_PRIVACY_THRESHOLD that be could used when the legal base is not Vital Interest and the number of connected device is below local regulation. WDYT?

[gregory1g]

@bigludo7 , I also think that it makes sense to align with PplDensity.

[chinaunicomyangfan]

@gregory1g @bigludo7 Thank you for your suggestion. I think it is reasonable to add an explanation in the response. Therefore, we may need to add an enumeration type parameter status in the return message to represent the status of regional statistics, including the following four values. SUBORTED-AREA: The whole request area is supported Population density data for the entire requested area is returned PART_OF_AREA_NOT_SUPPORTED:Part of the requested area is outside the MNOs coverage area, the cells outside the coverage area are not returned AREA-NOT-SUPPORTED: The whole requested area is outside the MNO coverage area No data will be returned DENSITY-BELOW-PRIVACY-THRESHOLD: The number of connected devices is below privacy threshold of local regulation I have a question. How to define a part in PART_OF_AREA_NOT_SUPPORTED? Is it through the threshold of coverage area? For example, if 50% of the area is not covered, the API will return this status.

[bigludo7]

Thanks @chinaunicomyangfan

How to define a part in PART_OF_AREA_NOT_SUPPORTED?

Yes this is a fair question. I guess we should crack this one with same algorithm than in PopulationDensityData API. @gregory1g as you were move involved in this latest you know if a policy has been discussed?

One way to consider it is to check on Device location - Verification API. We compute there a matchRate for partial area matching. For PART_OF_AREA_NOT_SUPPORTED we can provide this matchRate (so you have the information about the number of sim/device but also that x % of the area is checked)

[gregory1g]

Ppl density splits the area into a grid and returns data for every cell of the grid, if a single grid is not covered - the whole area is PART_OF_AREA_NOT_SUPPORTED. So, in ppl density the question is shifted to grid cell level.

However, for SimCount 50% sounds a bit high threshold for "PART_OF_AREA_NOT_SUPPORTED". Looking to the API from a user point of view I would say that 80% is PART_OF_AREA_NOT_SUPPORTED as well, and 90% also. Depending on my business 90% could be good enough or not - but this is user side decision. And as a user I could raise a question: ok 30% of the area is not supported, but which 30% is that, the middle of the area, or west part of the area, or something else?

[chinaunicomyangfan]

@bigludo7 @gregory1g According to the description information of PART_OF_AREA_NOT_SUPPORTED,I think following the PPL approach is correct. As long as there is a grid that is not covered, the whole area is PART_OF_AREA_NOT_SUPPORTED. If this definition is followed, further discussion can be conducted on whether to add a parameter to return the proportion of the area not coverd.

Additionally, this issue may be a common issue for users as this information can help them adjust the input parameter range. But this information is difficult to accurately describe. Can we return an Area parameter to describe the information of these uncovered areas. Does this seem a bit complicatedor may it involve some sensitive information that cannot be returned? Do you have any suggestions

And as a user I could raise a question: ok 30% of the area is not supported, but which 30% is that, the middle of the area, or west part of the area, or something else

[gregory1g]

suggestion: in this issue add a status attribute to the response and introduce different value. Discuss "PART_OF_AREA_NOT_SUPPORTED" definition (should it be MNO specific or defined on API level etc) separately.

[bigludo7]

Agree to add this status & value as proposed by @chinaunicomyangfan

@gregory1g I tend to think we can have a simple solution to start with: Telco coverage =100 % --> SUPPORTED-AREA 100>Telco Coverage >=50% --> PART_OF_AREA_NOT_SUPPORTED (We can keep for later a possibility to be more explicit on this) TelcoCoverage <50%: --> AREA_NOT_SUPPORTED SUPPORTED_AREA and PART_OF_AREA_NOT_SUPPORTED could be send back only if the number of devices in the area is > n (n is defined accordingly to local regulation). If the number of device is below n we send back DENSITY-BELOW-PRIVACY-THRESHOLD

[chinaunicomyangfan]

@bigludo7 Thank you for your suggestion. I think this is a simple and clear definition. If there are no other opinions, I will consider adding it to the response parameter. @gregory1g what do you think?

Telco coverage =100 % --> SUPPORTED-AREA 100>Telco Coverage >=50% --> PART_OF_AREA_NOT_SUPPORTED (We can keep for later a possibility to be more explicit on this) TelcoCoverage <50%: --> AREA_NOT_SUPPORTED SUPPORTED_AREA and PART_OF_AREA_NOT_SUPPORTED could be send back only if the number of devices in the area is > n (n is defined accordingly to local regulation). If the number of device is below n we send back DENSITY-BELOW-PRIVACY-THRESHOLD

[gregory1g]

If someone will ask me why 50%, I would not know what to answer. Anyway, I agree, that this is a not that bad starting point. But, please:

• SUPPORTED-AREA ->SUPPORTED_AREA
• DENSITY-BELOW-PRIVACY-THRESHOLD -> DENSITY_BELOW_PRIVACY_THRESHOLD or BELOW_PRIVACY_THRESHOLD, depending on how the threshold is defined (devices in the area or devices/km2 in the area).

[bigludo7]

Honestly I have no real explanation why use 50% as a threshold. This is a faire point.

We have probably to deep dive in UC .... I guess for a civil security UC like a wood fire in a national Park, we would like to know how many people could be in the "danger zone" and here 49%, or even 30% or 20% could be helpful.

Another way to manage it and send back in the response a covered area percentage: We have 149 device here and 76% of the zone covered. BTW It could be useful when the cells cover the area but also extra zone : you have 8961 device and the area is 108% covered (meaning that the telco is not able to circoncise precisely for the request area) The problem with that is the next question will be to provide the covered/not covered area and for that this more sensitive information.