Add Sync26 new changes (Geohashlist+Commonalities & ICM)

[albertoramosmonagas]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

This change extends Predictive Connectivity Data with optional GEOHASHLIST area support, following the same model introduced in Population Density Data to keep both sister APIs aligned and consistent in their area modelling.

It adds reusable GeohashList and Geohash schemas with geohash validation, restricts the precision field to POLYGON requests only, and clarifies that using precision together with GEOHASHLIST returns 400 INVALID_ARGUMENT. It also introduces new 422 errors for valid but unsupported request values:

• PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_AREA_TYPE
• PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_SERVICE_LEVEL

Additionally, CellConnectivityData.geohash is refactored to reuse the common Geohash schema, and the API description is updated to clarify GEOHASHLIST behaviour, including mixed precision levels, non-contiguous geohashes, partial out-of-coverage results using NO_DATA, and full out-of-coverage responses using AREA_NOT_SUPPORTED.

Precision handling is clarified: values outside the schema range 1–12 return 400 INVALID_ARGUMENT, while values within the valid schema range but unsupported by the MNO return 422 PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_PRECISION.

Alignment with CAMARA Commonalities

This PR also aligns the API definition with the updated CAMARA Commonalities requirements.

Commonalities version update (Comm-Spring26-005)

• Updated x-camara-commonalities from 0.6 to the full semantic version 0.8.0.

Notification credentials (Comm-Spring26-004)

The sinkCredential model has been aligned with the updated CAMARA notification credential model:

• Removed the deprecated PLAIN and REFRESHTOKEN credential types.
• Added the PRIVATE_KEY_JWT credential type, which supports token renewal through an authorization server.
• The supported credential types are now:
  • ACCESSTOKEN
  • PRIVATE_KEY_JWT

Implementation note: the Nexo platform does not currently support PRIVATE_KEY_JWT. It has been included in the API specification for forward compatibility. For the current one-time callback use case, the credential type used in practice remains ACCESSTOKEN.

Reinforced input validation (Comm-Spring26-006)

Validation constraints have been added to string, array and integer fields in accordance with the CAMARA OWASP-oriented validation guidelines. These constraints do not invalidate any value that was already valid under the previous API definition.

For Predictive Connectivity Data, the following limits have been added:

Field type	Fields and constraints
Strings	Geohash: maxLength: 12; sink: maxLength: 2048; request and interval startTime / endTime: maxLength: 64; OperationId: maxLength: 256; statusInfo: maxLength: 512
Arrays	geohashes: maxItems: 1000; timedConnectivityData: maxItems: 168; CellConnectivityDataArray: maxItems: 10000; LayerConnectivities: maxItems: 100; LayerSignalStrengths: maxItems: 100
Integers	precision: format: int32; height: format: int32; requestedHeight: format: int32, minimum: 0, maximum: 250

Error model and traceability

The standard CAMARA validation constraints have also been applied to the shared error and tracing fields:

• ErrorInfo includes the standard description and constraints:
  • status: format: int32, with values restricted to the range 100–599;
  • code and message: standard maxLength constraints.
• x-correlator includes the standard CAMARA description and maxLength constraint.

Backwards compatibility

All Commonalities-related changes are backwards compatible, except for the removal of the deprecated PLAIN and REFRESHTOKEN notification credential types. No practical impact is expected, as the previous API specification already required the use of ACCESSTOKEN.

Which issue(s) this PR fixes:

Fixes #38, #39

Special notes for reviewers:

This change intentionally mirrors the GEOHASHLIST modelling introduced in Population Density Data (camaraproject/PopulationDensityData#110) to preserve consistency between both APIs.

Changelog input

 release-note
Added optional `GEOHASHLIST` area support with reusable geohash schemas, clarified precision and service-level error handling, and introduced `PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_AREA_TYPE` and `PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_SERVICE_LEVEL` for valid but unsupported request values.

Additional documentation

This section can be blank.

docs

[camara-validation]

CAMARA Validation — PASS

0 errors, 11 warnings, 4 hints | Profile: standard

View full results

[albertoramosmonagas]

Some comments for reviews

[albertoramosmonagas]

The next “rx.y” we'll be looking at

[albertoramosmonagas]

New marketing description based on the guidelines and review from Marketing WG: #54