]> Tsinghua University

xiexiaohui@tsinghua.edu.cn

Tsinghua University

liusn25@mails.tsinghua.edu.cn

Huawei

yigang8@huawei.com

Tsinghua University

cuiyong@tsinghua.edu.cn

Operations and Management Individual Submission quality of service network telemetry machine learning policy evaluation QoSformer Network operators need to assess how changes to quality-of-service (QoS) policies may affect individual traffic flows and shared network resources. Measurements describe observed behavior, but policy evaluation also requires predictions under candidate configurations. This document describes a framework that combines heterogeneous network measurements and configuration data in a Multiple Flow Snapshot (MFS), learns representations through masked reconstruction, and uses a Transformer-based model called QoSformer to predict throughput, delay, and resource utilization. It describes offline model preparation, online candidate evaluation, and feedback after authorized policy changes. A 5G core network use case illustrates the mapping to analytics and policy-control functions. The framework is informational: it defines neither a new wire protocol nor extensions to existing 3GPP interfaces.

Introduction QoS management involves both service-specific objectives and competition for shared resources. Increasing the resource allocation of one flow can affect other flows, while a policy that worked under one traffic pattern may be unsuitable after load or radio conditions change. Monitoring alone does not indicate which of several permissible policy changes is likely to improve the current situation. The network telemetry framework in describes the collection and use of operational information. This document addresses a consumer of such information: a learning-based function that predicts QoS behavior and evaluates candidate policies before they are considered for deployment. Its inputs include time-varying measurements, current flow configuration, and shared-resource context. Its outputs are predictions and policy recommendations, not commands that bypass existing authorization. The proposed framework has three technical elements. First, MFS encoding preserves temporal and cross-flow relationships in a common representation. Second, masked reconstruction uses unlabeled observations to initialize the prediction models. Third, task-specific prediction models evaluate throughput, delay, and resource use for the current configuration and candidate configurations. A separate policy authority decides whether a recommendation can be applied. The motivating deployment is QoS experience assurance for uplink live streaming in a 5G core network. Interactive video and heavily loaded public event networks provide related use cases. The same separation of measurement, prediction, authorization, and feedback can be considered in other managed networks, but the radio-resource inputs and deployment mapping described here are specific to the 5G example.

Scope and Status This document describes a proposed architecture, information dependencies, model workflow, and evaluation methodology. QoSformer is the example model used to make that architecture concrete. The document does not prescribe a mandatory model implementation, define interoperable message encodings, allocate protocol identifiers, or modify 3GPP specifications. QoSE is the name used here for the proposed QoS assurance function. It is not a claim that a new 3GPP network function or service has been standardized. The 5G mapping in is a deployment example, not a complete interface specification. Numeric model settings in are an illustrative configuration, not measured performance results or conformance requirements. This is an individual contribution intended for discussion. It does not represent IETF working-group consensus. The document uses ordinary descriptive language and does not define a normative implementation conformance profile.

Terminology

Flow:

A traffic aggregate whose identity and measurement scope are defined by the deployment. In the 5G example, a flow is a QoS Flow, not necessarily a single transport connection. Session context is retained when a local flow identifier is not globally unique.

Multiple Flow Snapshot (MFS):

A representation of multiple flows over an observation window, indexed by time, flow, and feature. It is a model input, not an on-wire format.

QoSformer:

A Transformer-based prediction model family initialized through masked reconstruction of MFS inputs and adapted to individual prediction tasks.

QoSE:

The logical QoS assurance function containing input preparation, prediction, candidate evaluation, and feedback processing.

Candidate policy:

A proposed configuration change, together with its target flows, applicability conditions, and evaluation context. A candidate is not an authorized configuration update.

Policy authority:

The existing function responsible for checking and authorizing changes according to operator policy, resource limits, and service obligations.

Prediction horizon:

The future interval, or sequence of intervals, for which a prediction is produced. It is distinct from the observation-window duration.

The following abbreviations are used: Abbreviations

Abbreviation	Meaning
5QI	5G QoS Identifier
GFBR	Guaranteed Flow Bit Rate
MAE	Mean Absolute Error
MAPE	Mean Absolute Percentage Error
MFBR	Maximum Flow Bit Rate
NWDAF	Network Data Analytics Function
OAM	Operations, Administration, and Maintenance
PCC	Policy and Charging Control
PCF	Policy Control Function
PRB	Physical Resource Block
SLA	Service Level Agreement
SMF	Session Management Function
STFT	Short-Time Fourier Transform
UPF	User Plane Function

The term "masked autoencoder" is written out to distinguish it from MAE, the prediction-error metric.

Use Cases and Design Objectives

Uplink Live Streaming Uplink streaming can experience throughput shortfalls when several flows compete for radio resources. A QoSE function observes traffic demand, recent throughput and delay, applicable QoS settings, and cell context. It evaluates permissible changes to rate guarantees or limits and estimates both the affected flows' behavior and shared-resource use. The policy authority considers those estimates before deciding whether to change the configuration. This use case requires a distinction between network QoS and application experience. Throughput and delay are useful indicators, but predicting them does not by itself establish a reduction in video stalls or an improvement in perceived quality. Such claims require corresponding application measurements.

Interactive Services and Variable Load Interactive video and similar applications make delay, as well as throughput, relevant to policy selection. Public events introduce rapid changes in the number and demand of active flows. Jointly representing those flows helps the predictor consider competition for a common resource rather than evaluating each flow in isolation. For industrial or other tightly constrained services, predictions can support planning and admission decisions. They do not establish a deterministic delay bound or replace the mechanisms needed to enforce such a bound.

Design Objectives The framework is designed to:

• combine time-series measurements and categorical configuration without discarding their association with flows and observation times;
• reuse unlabeled data when task-specific labels are limited;
• predict flow-level throughput and delay together with cell-level resource utilization;
• compare several candidate configurations against an unchanged-policy baseline using the same observed state;
• leave policy authorization and enforcement with existing functions; and
• use post-change observations to assess prediction error and policy effects, while retaining a safe operational fallback.

Collection interval, inference budget, decision interval, and policy installation time are separate deployment parameters. A short inference time alone does not imply a short end-to-end reaction time.

Functional Architecture shows the logical functions. Arrows describe information dependencies, not newly specified interfaces. Functions can be colocated or connected by deployment-specific adapters.

Logical QoS prediction and policy evaluation architecture Collection and feedback ]]>

The input adapter identifies measurement scope, units, timestamps, configuration versions, and missing values. MFS encoding transforms that input into the representation expected by the active model. The prediction function calculates baseline and candidate results. The evaluation function filters candidates and ranks those that remain feasible. The model-management function is separate from the decision path. It maintains approved model artifacts, their preprocessing dependencies, validation records, and rollback versions. Online decisions use a known model version rather than implicitly accepting the most recently trained weights. The feedback function relates observations to the policy that was actually installed. A recommendation that was rejected, modified, or only partially applied is not recorded as though it had been fully executed.

Multiple Flow Snapshot Encoding

Inputs and Temporal Alignment The example input contains three groups of data:

1. Per-flow time series, such as offered traffic, measured throughput, delay, and available channel-quality measurements.
2. Per-flow configuration, such as service class and configured rate parameters.
3. Shared context, such as cell bandwidth, duplex mode, subcarrier spacing, antenna configuration, and observed resource utilization.

Each sample is associated with an observation interval and a stable flow mapping within that interval. When a flow starts or ends, its identity and presence are retained separately from its numeric features. An inactive flow, a padded tensor position, and an active flow with zero throughput have different meanings. The encoder aligns heterogeneous measurements to a configured time grid. Fast-changing variables can contribute window statistics and STFT-derived features. More slowly changing measurements can use suitable window aggregates. Categorical values use one-hot or learned embeddings. Global cell features are associated with all relevant flow positions. Only information available at the prediction time enters the input. Window construction and feature normalization avoid including future samples. Missing or stale measurements are accompanied by validity information; filling a field with zero is not evidence that zero was measured.

Tensor Structure and Position Information The MFS tensor has dimensions W x H x C:

• W is the number of observation intervals;
• H is the configured number of flow positions; and
• C is the feature-vector length at each time-flow position.

Zero padding provides a fixed shape when fewer than H flows are present. A presence mask prevents padded positions from being treated as traffic measurements or prediction targets. When more than H flows are present, the deployment records the grouping or selection policy. Omitting competing flows can change prediction quality and is therefore part of the evaluation context. Patch embedding converts the tensor into model tokens. Learned two-dimensional position embeddings and relative position information, such as rotary position embeddings, can represent time and flow coordinates. Flow-axis proximity denotes the chosen ordering, not necessarily physical proximity or a network-topology relationship. Training and inference use the same ordering and feature definitions.

MFS input preparation Window statistics / STFT -----+ | Per-flow configuration --> Categorical / numeric -------+ encoding | v Cell configuration ------> Shared-context encoding --> Fusion | v Align time and flow | v MFS tensor + masks [W x H x C] | v Patch and position encoding | v Model input tokens ]]>

summarizes the encoding pipeline. The preprocessing configuration is versioned with the model, including units, normalization, categorical vocabularies, window sizes, and treatment of missing values.

QoSformer Model Workflow

Self-Supervised Pre-Training Pre-training uses unlabeled MFS observations. Selected observed patches are hidden from the encoder, and a lightweight decoder reconstructs their features from the visible patches and position information. Random masking learns general dependencies; localized masks can represent correlated loss across adjacent time or flow positions. Such adjacency does not imply physical proximity between the flows. The reconstruction objective is the average squared feature error over the deliberately masked, originally observed patches. Naturally missing measurements and padding are not used as reconstruction ground truth. Feature scaling prevents large numeric ranges from dominating that objective. After pre-training, the encoder weights initialize downstream prediction models. The reconstruction decoder is a training component and is not required in the online prediction path. The configuration in illustrates the architecture and masking settings.

Task-Specific Prediction The example design uses three prediction tasks:

• Flow throughput: a sequence of future throughput values for each selected flow.
• Flow delay: a sequence of future delay values for each selected flow.
• Cell resource use: a scalar prediction of PRB utilization for a specified future interval.

Each task-specific encoder is initialized from the pre-trained encoder and fine-tuned with a lightweight task decoder. The tasks share a representation-learning stage, but need not share every trainable parameter during fine-tuning. Batched evaluation combines their outputs for policy assessment. For throughput and delay, an example decoder predicts tokens representing logarithmically spaced value ranges, trained with cross-entropy and label smoothing. The tokenizer defines a distinct treatment of zero, its supported range, and its mapping from a token to a numeric estimate. Values outside the supported range are flagged rather than silently interpreted as reliable predictions. PRB utilization uses a scalar regression output with a mean-squared-error objective in this example. Throughput units, delay scope, prediction horizon, and resource-aggregation interval accompany the model output. A delay observation made at one network element is not automatically an end-to-end delay measurement. PRB utilization is associated with a specified cell, link direction, and measurement interval.

Model Preparation and Release The offline procedure is:

1. An operator starts a training task and selects authorized data sources, measurement definitions, and a validation scope.
2. The preparation function cleans and aligns the observations, creates MFS examples, and records their provenance and feature definitions.
3. The training function pre-trains on unlabeled examples and fine-tunes task models on labeled examples.
4. Validation assesses accuracy, timing, missing-input behavior, and performance on the intended deployment conditions.
5. The operator approves a model bundle containing weights, preprocessing configuration, tokenizer information where applicable, and validation metadata.
6. The inference function loads and warms the approved bundle. It keeps the preceding approved version available for rollback.

Illustrative offline preparation and release sequence | | | | |-- prepare dataset -->| | | |<-- training data ----| | | | | | | pre-train, fine-tune, validate | | | | | |<-- validation ------| | | |-- approval -------->| | | | |-- approved bundle -->| | | | |<-- load ------| | | |-- bundle ---->| | | | warm-up |<----------------------- ready notification ----------------| ]]>

expresses logical actions rather than protocol messages. The repository is a deployment-managed data and model store; this document does not require that a particular 3GPP repository store arbitrary training data or model binaries.

Online Policy Evaluation and Feedback

Trigger and Baseline An evaluation starts either periodically or after an event, such as an observed throughput shortfall, an increased delay, or a load alarm. QoSE collects a consistent view of current observations and configuration, checks their freshness, and predicts the behavior of the unchanged configuration. The baseline is evaluated over the same horizon and with the same model version as the candidates. If required inputs are unavailable, excessively old, or outside the validated input domain, the function reports that evaluation is unavailable. Existing policy remains in effect, or the deployment uses its established non-ML control procedure.

Candidate Generation and Comparison Candidate generation is bounded by operator-defined permissions. It may propose changes to permitted service-class or rate parameters, and may consider reclaiming an excessive resource guarantee. Candidates include the unchanged configuration so that no change is a valid outcome. For each candidate, QoSE combines the same observed network state with the proposed configuration values and performs batched prediction. A candidate describes the configuration intended to apply over the prediction horizon. It does not rewrite the historical measurements or the configuration under which those measurements were collected. A candidate-aware model represents historical settings and proposed future settings distinctly, for example using separate conditioning tokens for the proposed settings. The specific representation is a model-design choice and is used consistently in training and inference. Candidate-conditioned prediction requires training examples or a validated evaluation environment that represents the relevant policy variations. Merely changing a configuration feature in a model trained only on an unchanged policy does not establish a causal effect. A deployment validates this use of the predictor separately from ordinary forecasting and restricts candidates to its validated domain. The evaluation function first excludes candidates that violate known service, resource, or authorization constraints. It then ranks feasible candidates using an operator-defined objective covering throughput, delay, and resource use. Metric normalization, objective weights, and tie-breaking behavior are explicit deployment choices. No universal utility formula or fixed set of weights is defined here. Candidate comparisons use compatible prediction and aggregation intervals. A multi-step flow prediction is not combined with a resource estimate for an unrelated interval. Predictions are estimates, not resource reservations. The policy authority rechecks constraints against current state before approving a change, including effects on flows that are not the original trigger.

Authorization, Application, and Feedback QoSE passes a recommendation and its evaluation context to the policy authority. The authority can accept, modify, or reject it. Only an authorized decision reaches enforcement. Changes made during review are either evaluated again or treated as distinct decisions, rather than being assigned the predictions of the original candidate.

Online evaluation, authorization, and feedback | | | | validate inputs | | | predict baseline | | | evaluate candidates | | | |-- recommendation ->| | | | check constraints | | | |-- approved change ->| | | |<-- apply status ----| | |<-- decision/status-| | | | | | |<---------------- post-change measurements -------------| |-- feedback->| | | | compare prediction | | | with observed result | | ]]>

separates a prediction from the act of changing the network. The feedback record identifies the installed policy version, installation status, observation times, and relevant traffic or resource changes. This permits evaluation of the actual decision rather than the proposed one. Policy stability controls include a minimum interval between changes, bounded change magnitude, and a criterion for reverting harmful changes. In multi-controller deployments, a designated authority resolves conflicting recommendations. Model adaptation uses reviewed feedback data and the release procedure in ; online feedback does not automatically authorize new model weights.

Information Associated with a Decision The following information supports traceability. It describes semantic content, not a standardized data model or message schema:

• Evaluation context: request identifier, target flow and resource scope, measurement interval, current configuration version, and data freshness.
• Candidate context: candidate identifier, intended parameter changes, applicability period, and the unchanged-policy baseline.
• Prediction context: model and preprocessing versions, output units, prediction horizon, predicted metrics, and validity indicators. A confidence measure is included only when the deployment has a defined and validated method for producing it.
• Decision context: authorization result, approved configuration, installation status, and observation or rollback outcome.

Example Mapping to a 5G Core Network The 5G system architecture is described in , with procedures in , network analytics in , and policy control in . These references provide context for the following proposed mapping; they do not establish a standardized QoSE service. QoSE can be implemented alongside an analytics function or as a separate operator-managed application with authorized adapters. In the example, NWDAF-related information supplies analytics context, session-management information supplies current flow configuration, and OAM-related sources supply resource context and model-management input. Available UPF measurements supplement these inputs where their scope is appropriate. The precise service operations, access permissions, and data availability depend on the chosen deployment and specification versions. The policy authority is mapped to PCF-related policy control. Accepted policy decisions follow the existing session-management and enforcement procedures rather than creating a direct QoSE control path to the UPF. The N4 reference point remains between SMF and UPF; this document does not define a QoSE-to-UPF N4 interface. In this mapping, candidate settings use 5G terminology, including 5QI and, where applicable, GFBR and MFBR. A QoS Flow is identified together with its session context. Radio scheduling remains an access-network responsibility: a predicted PRB utilization value does not reserve PRBs, and a core-network policy update is not itself a radio scheduling command. Storage and model distribution are logical deployment functions. Their mapping to available analytics, management, or repository services needs a separate integration design. This framework does not add arbitrary model-storage semantics to a 3GPP repository or assign a new service name.

Evaluation Methodology Evaluation distinguishes forecasting accuracy, usefulness for candidate ranking, and the operational effect of applied policies. These are different questions and are reported separately. This section describes test methods; it does not report completed measurements.

Data and Prediction Accuracy Training, validation, and test sets are separated by independent source sequences or deployment periods before overlapping windows are created. Normalization and tokenizer parameters are fitted using training data. Reports identify the collection or simulation conditions, task labels, traffic population, and any excluded samples. For throughput and delay, report MAE in the stated physical units and error by prediction horizon. MAPE can supplement MAE when targets are nonzero. For zero or near-zero targets, report an explicit inclusion rule or an alternative metric; the denominator is not silently changed. For resource utilization, state whether values are fractions or percentages and report absolute error on that scale. Results identify aggregation across flows, cells, and time. Reporting only an overall average can hide errors affecting low-rate flows or uncommon load conditions. Baselines use the same held-out data and measurement definitions.

Timing and Candidate Evaluation Measure preprocessing, model inference, and end-to-end decision-path latency separately. State CPU and accelerator configuration, runtime, batch size, observation-window dimensions, flow count, and candidate count. Report warm-up treatment, typical latency, and a tail percentile such as the 99th percentile. Candidate evaluation tests hold the initial network conditions comparable while varying the candidate policy in a simulator, testbed, or controlled deployment. They compare predicted ordering with observed outcomes, including constraint violations and effects on competing flows. A replay containing only the policy actually applied does not directly provide outcomes for all unexecuted alternatives.

Data Efficiency, Robustness, and Deployment Effects Data-efficiency tests fine-tune with several labeled-data fractions while holding the test set and unlabeled-data access policy constant. Report absolute task errors rather than an undefined percentage of "accuracy retained" for regression tasks. Robustness tests remove individual feature groups, introduce missing intervals and stale inputs, and vary load, mobility, and flow count. Evaluate input rejection and fallback as well as prediction error. Additional tests cover model rollback, rejected recommendations, partial application, and conflicting policy updates. Deployment evaluation records the measurement window and compares observed service objectives, resource use, policy-change frequency, and fallback events. Predicted improvements are kept separate from observed improvements. Claims about application experience require corresponding application-level observations.

Operational Considerations QoSE introduces dependence on feature definitions, clock alignment, and model versions. A model deployment therefore includes its preprocessing bundle, supported input domain, resource limits, and a record of its validation. Changing a tokenizer or feature order without updating the corresponding model is treated as an incompatible change. Flow population and traffic distribution can drift over time. Operators monitor input validity and prediction residuals, bound the number of evaluated candidates, and define when automatic recommendations are suspended. Failure of QoSE does not remove existing policies or disable the network's established control functions. Introducing a new task requires its labels, output semantics, decoder, and validation. Reusing a pre-trained encoder can reduce model-design work, but does not establish a fixed retraining time or eliminate the need to validate the new task.

Security Considerations A compromised measurement source can bias predictions and induce resource misallocation. Input adapters therefore authenticate sources, check message integrity and freshness, restrict collection scope, and reject invalid values. Cross-tenant data and recommendations are isolated according to the deployment's authorization model. Model artifacts and preprocessing bundles are also security-sensitive. Controlled release, integrity verification, restricted write access, and auditable version changes help prevent unauthorized model replacement. Training pipelines consider poisoning and feedback manipulation: an attacker may attempt to cause the system to learn from traffic that the attacker deliberately shaped. Communication carrying telemetry, model artifacts, or recommendations needs authenticated confidentiality and integrity protection. TLS 1.3 is one mechanism for suitable application transports. The selection follows the deployment's security architecture; this document does not redefine security requirements for existing 3GPP interfaces. Stored data and models require access control and protection appropriate to their sensitivity. The policy authority checks every recommendation, regardless of model confidence. Candidate counts, input sizes, and request rates are bounded to limit denial-of-service exposure. A recommendation cannot grant itself additional permissions. Rejection, timeout, and model unavailability lead to an established fallback rather than uncontrolled resource changes.

Privacy Considerations Flow measurements, timing, mobility context, and service configuration can reveal user behavior even when packet payloads are not collected. Removing direct identifiers does not necessarily prevent correlation or re-identification. The privacy considerations in are relevant to this collection and analysis. The deployment limits data fields, linkability, retention, and access to what is needed for the stated QoS-management purpose. Pseudonymous flow identifiers can preserve the association needed within an observation window without routinely exposing subscriber identities to training jobs. Training datasets, logs, model outputs, and exported models are included in the privacy assessment because they can retain or expose information about the underlying traffic.

IANA Considerations This document has no IANA actions.

Informative References 3GPP 3GPP 3GPP 3GPP

Example Model Configuration The following configuration makes the proposed model workflow concrete. It is illustrative and does not define a benchmark result, a guaranteed reaction time, or a mandatory deployment profile. Illustrative QoSformer model settings

Setting	Example value
Basic sampling interval	1 second
MFS feature dimension, C	64
Pre-training mask fraction	75% of eligible patches
Pre-training encoder	6 Transformer layers
Encoder hidden dimension	768
Encoder attention heads	12
Reconstruction decoder	2 Transformer layers
Task-specific decoder	2 Transformer layers
Throughput and delay horizon	10 prediction steps
Token vocabulary for sequence outputs	200 bins
Label-smoothing factor	0.1

Local block masking can supplement random masking. One example considers a neighborhood extending two time positions and five flow positions on either side of a selected location. Tensor boundaries and invalid positions limit the actual neighborhood. The observation length W, flow capacity H, patch dimensions, bin boundaries, and output aggregation intervals are chosen for the dataset and deployment. They are recorded with the model artifact. The basic sampling interval alone does not determine the effective prediction horizon when output intervals use a different resolution.