CAMARA Population Density Data API - Follow-up meeting #13 - 2024-08-28

August 28th, 2024

Attendees

Population Density Data API minutes: https://lf-camaraproject.atlassian.net/wiki/display/CAM/Population+Density+Data+API+Minutes

Agenda

• Approval of previous meeting minutes #9 and meeting agenda

• Open issues and PRs
  
  

  • Issues: #12 #35 #37 #38 #39 #40

  • PR #25 #44 #45

• Initial algorithm proposal review

• Timeline and next steps

• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #12

→ Approved

API proposal review (2)

Issue#35

Include the checklist for meta-release Fall24, including documentation, ATPs and alignment with commonalities (0.4.0)

Item splitted into the following issues to track each item. To include proper scope for meta-relase.

AP: define properly the exact scope referencing the different issues.

Status: PR#36 merged, table will be updated with new status

Issue#37

Include basic ATP for the population-density-data API, including base test-plan and related documentation

AP: Telefonica to provide first proposal

Status: ATP proposal in PR#44 to be reviewed

Issue#38

• Confirm API definition → Current version confirmed

• Design guidelines from Commonalities applied → 

• Guidelines from ICM applied → 

AP: Rafal to validate the compliance of current code with the commonalities and I&CM v0.4.0.

Status: RC1 aligned with commonalities (TBC by Rafal). 

Issue#39

• API versioning convention applied → done

• API documentation → validate current documentation and (optionally) finalize the review of the algorithm description

AP: Gregory to review and validate current documentation.

Status: Agreed during the meeting on the final proposal considering the two topics pending to have feedback. Changes will be applied by Telefónica in the API Proposal to be finally approved by next meeting.

Issue#40

Issue opened in commonalities for the alignment on how to define the area types along all the APIs in CAMARA.

AP: provide direct feedback on the commonalities issue Issue #242. Groups is ok to create a homogeneous definition of the area types, as long as each API can later select granularly which types apply (and not getting obligation to support all the types, or getting involved in a complex data model).

Status: Delayed until september, following commonalities track.

PR#44

Including the API Test Plan proposal, updated also in wiki tracker

AP: Companies to review ATP proposal.

Status: Pending on the review of the ATP. No one had reviewed the ATP, but it has been asked to do so to meet the M4 deadline.

It has been mentioned by Ludovic during the meeting the documentation is not being well-structured in the PR: Readme and Checklist supposingly are not part of this PR.

PR#45

PR for meta M4, including public release. REQUIRES FIRST MERGING #PR44

AP: Reviewing the ATP.

Initial algorithm proposal (3)

Issue#12

K-anonimization to be clarified (in which step it is implemented)

New wording agreed for step 5:

5.    Distribution and aggregation: Taking into account the coverage area of the cell, users are going to be distributed, homogeneously among the grids (currently 150m x 150m or larger) associated with the cell, and the process is repeated for all cells. As we are assuming that the distribution of users in the coverage area of each cell is uniform, we are introducing an error/noise in the distribution of users by time interval, which will be transferred to population density predictions that contribute to reducing the risk of user reidentification. Each grid on the map can typically be served by several cells of different technologies and frequency bands. To obtain the number of users per grid and time interval, an aggregation is performed.
Output 5 → Number of Users per grid, based on distribution in the cells covering that area.

When and how the prediction of persons/users is done, based on the input (devices)

New wording agreed for step 2 & 3:

2. Attribution: A cell is associated with each user in each time interval.

1.  

   1. For mobile lines with persistent records, the last cell in which each user has been connected in each interval (considering intervals of 15 minutes) will be associated.

   2. It is common to have intervals for which a user does not show activity, for them it will be assumed that the user remains in the same cell in which he was last seen active.

Output 2 → Valid Users per cell in each time interval

3.    Counting and Aggregation: A count of users is performed per cell and interval. On this count, a statistical analysis is performed with the elimination of outliers. Records associated with cells with less than K users in each time interval (k – anonymity) per km2 are discarded (to be evaluated according to local regulations).
Output 3 → Total number of Users connected per cell in each time interval, considering privacy.

Telefonica to provide feedback on these two topics to move on.

Status: Review in Issue/PR

AoB (4)

Next steps:

• Meta release publication, PR of the RC1.1 created (draft) pending to fix any possible typo and merge ATP, to follow meta-release process.

Discussion Summary

Next steps

1. Feedback on algorithm proposal → Follow-up meeting #14

2. Align Meta-release items → #14

• Next call will be 11th September