[Discussion] Defining Boundaries for User Experience Insights API: Focusing on Multi-Dimensional Application Real-Use Experience

[XunliYang]

Hi team,

We have launched a new API proposal camaraproject/APIBacklog#314. There are some scope boundary questions we'd like to discuss with you.

To provide a brief overview, User Experience Insights API is designed to expose the internal network "vision" by providing user network access information, application-level network data, and application experience analysis data. It provides detailed data reporting, including basic application statistics (such as uplink statistics, downlink statistics, number of lost packets, valid uplink bandwidth, valid downlink bandwidth, average uplink bandwidth, and statistical summaries of periodic applications) and experience analysis data (such as application rating, maximum resolution, duration at maximum resolution, uplink bit rate, downlink bit rate, stalling duration, latency, and application creation latency).

The analysis data parameters example in below:

"UserExperienceInsightsRecords": [
    {
      "appSignalingAndStatisticsAnalysisRecords": [
        {
          "starttime": "2023-07-03T12:27:08.312Z",
          "endtime": "2023-07-03T12:27:08.312Z",
          "applicationType": "video/game/Live Video",
          "applicationId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
          "areaData": {
            "city": "string",
            "district": "string"
          },
          "appSignalingData": {
            "dnn": "string",
            "qciOr5qi": 0,
            "netType": "string"
          },
          "applicationIndicatorStatistics": {
            "subAppStartTime": "2023-07-03T12:27:08.312Z",
            "subAppEffDur": 0,
            "avgBwUl": "string",
            "avgBwDl": "string",
            "maxBwUl": "string",
            "maxBwDl": "string",
            "subAppVol": {
              "totalVolume": "string",
              "ulVolume": "string",
              "dlVolume": "string"
            },
            "maxDelayAn": 0,
            "maxDelayDn": 0
          },
          "applicationExperienceAnalysis": {
            "avgQoe": 0,
            "maxResolution": "string",
            "mostResolution": "string",
            "maxBitRateUl": "string",
            "avgBitRateUl": "string",
            "maxBitRateDl": "string",
            "avgBitRateDl": "string",
            "stallSec": 0,
            "stallNum": 0,
            "serviceDelay": 0,
            "initialDur": 0
          }
        }
      ]
    }
  ]

These data payloads are derived from real-time data within network elements. It provides developers with high-fidelity Quality of Experience (QoE) scores and predictive network trends to dynamically adjust their application strategies.

We want to have an API focus on the application real-use experience analysis across multiple dimensions. It evaluates the actual in-action business fluency (e.g., fusing dnn/5qi signaling dimensions with stallSec, initialDur, and maxResolution experience dimensions.

As the APIBacklog WG suggested in the 2026-05-14 API Backlog Minutes - CAMARA Project - CAMARA Project, we'd like to hear your suggestions on this proposal and explore how we can align the boundaries.

@camaraproject/predictive-connectivity-data_codeowners
@camaraproject/predictive-connectivity-data_maintainers
cc: @albertoramosmonagas @cmhkknight

[albertoramosmonagas]

Hi @XunliYang, thanks for opening this discussion.

Predictive Connectivity Data already covers the capability to retrieve an estimation of 4G/5G connectivity for a defined area or volume, future time window, service level, network type and, where applicable, height/vertical layer. Its output is intended to support planning decisions by exposing predicted connectivity levels over geographic cells.

The User Experience Insights proposal appears to have a different and potentially valid core scope when it is focused on actual application real-use experience: per-device / per-application QoE, application statistics, stalling, bitrate, resolution, latency, and network-side service experience observations for active or recent application usage.

However, the current wording also refers to “predictive network trends”, area-based identification of poor QoS, regional deployment optimization, network quality along user paths, and proactive application adaptation based on network-side intelligence. This creates overlap with Predictive Connectivity Data whenever the API is positioned as a source of predicted connectivity or network quality information for a given area, route, time window, or planning scenario.

My suggestion would be to explicitly define the boundary as follows:

• User Experience Insights should focus on observed or near-real-time user/application experience derived from actual application usage or active sessions.
• It should not expose future connectivity forecasts for a geographic area, route, volume, altitude, or planned time window, as this belongs to Predictive Connectivity Data.
• Any “trend” or “prediction” wording should be either removed or clearly limited to short-term degradation detection for an existing user/application context, not to connectivity forecast or planning.
• Area information, if retained, should be contextual metadata for the observed experience, not an area-based planning query model.
• Use cases such as drone/vehicle route planning, network availability prediction, regional connectivity planning, or future service-level availability should remain outside UEI and be handled through Predictive Connectivity Data.

With this clarification, I think UEI could still be positioned as a complementary API focused on real-use application QoE, while Predictive Connectivity Data remains the API for future connectivity estimation and planning over an area/volume.

WDYT @camaraproject/predictive-connectivity-data_codeowners?

[XunliYang]

Thanks @albertoramosmonagas for your points. You are absolutely right, and it is necessary for us to clarify and restrict these scope boundaries in our API proposal and description.

To clear up any ambiguity, we would like to clarify the intent behind our current wording:

• The mention of "trends" or "predictions" in our proposal is limited to short-term degradation detection for an active user/application session context (e.g., predicting that an active video stream is about to experience severe stuttering based on near-real-time NWDAF evaluation). It does not involve future connectivity forecasting for geographic areas, routes, or volumes.

• The area field included in our payload is just designed as part of user's experience portrait. It will not be utilized as an area-based planning query model or for coverage forecasting.

We will update the wording in UEI's proposal, limiting "predictions" to the short-term degradation detection for an existing user/application context. And also clarify that UEI’s positioning and API scope are dedicated to providing real-use application QoE insights.

cc: @cmhkknight

[albertoramosmonagas]

Hi @XunliYang,

From the Predictive Connectivity Data perspective, the key boundary is exactly the one you describe: UEI may include short-term degradation detection for an active user/application session, but should not provide future connectivity forecasting for geographic areas, routes, volumes, altitude layers, or planned time windows. I think the proposal would be clearer if the updated wording explicitly states that:

• UEI is focused on observed or near-real-time real-use application QoE for an existing user/application context.
• “Prediction” or “trend” references are limited to short-term degradation detection within an active/recent session.
• areaData, if included, is only contextual metadata for the observed experience and must not be used as an area-based planning query model.
• Coverage forecasting, route/area planning, future service-level availability, and volume/altitude-based connectivity estimation remain out of scope and are covered by Predictive Connectivity Data.

With those clarifications included in the API proposal and description, I think the boundary with Predictive Connectivity Data would be sufficiently clear.