2025-06-24 PredictiveConnectivityData Minutes
Community Attendees:
@Alberto Ramos Monaga @Violeta González @Nick Petropouleas @Eric Murray
Community Attendees:
LF Staff:
Agenda
The project's Antitrust Policy is linked from the LF and project websites. The policy is important when multiple companies, including potential industry competitors, are participating in meetings. Please review it, and if you have any questions, please contact your company’s legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.
Approval of previous meeting minutes and meeting agenda.
Open issues and PRs
Discussion Summary
Agenda 1: Review and close scope of WIP version of PCD API
AoB
Approval of previous meeting minutes
2025-06-10 PredictiveConnectivityData Minutes: OK
Open Issues & PRs
# | Summary | Action |
|---|---|---|
Define first WIP version of Predictive Connectivity Data API | Review comments and merge this first PR with the initial WIP version to have a basis to work on for the release candidate. | |
| Close scope of the fall25 and close issues |
Discussion Summary
Agenda: Review of the comments of the PR with the WIP version:
Height parameter
Eric’s proposal: Add an optional height parameter so clients can request data for a specific vertical layer.
TEF: Fully supports including an optional height — if specified, return only the relevant layer.
Technical team: Agree — this matches what we want. For example, if 12 m is requested, return only the layer that covers 0–30 m.
Decision: OK with maximum of 250 meters and as optional parameter.
Precision parameter
Eric’s proposal: Include optional precision like in Population Density API, with 422 UNSUPPORTED_PRECISION if not supported.
TEF: Agrees; as long as each MNO can define supported levels and return 422 when unsupported.
Technical team: Fully support this. It aligns with existing practice in the Population API.
Decision: Let’s include this optional precision parameter and align with the Population Density API behavior.
New service level and Signal Strength
Eric’s proposal: Add a new service level (SIGNAL_STRENGTH).
TEF: Cautious — agrees only if optional; doesn’t support making signal strength mandatory.
Technical team: Clarify that this wouldn’t be a new service level, as service levels produce GC/MC/NC/ND. What’s requested is a value rather than a level. Suggest further discussion.
Decision for Signal Strength comments: If the API consumer says, I want signal strength we can respond, no, that feature's not supported or we can have another endpoint for service level and one for signal strength.
AoB
N/A
Action Points
➜ If included, agree on the new response schema (e.g. layerValues containing both connectivityLevel and signalStrength).
➜ Confirm that connectivityLevel (GC/MC/NC/ND) will always be present, and signalStrength will only appear if requested and supported.