Individual Submission X. Xie Internet-Draft S. Liu Intended status: Informational Tsinghua University Expires: 21 March 2027 G. Yi Huawei Y. Cui Tsinghua University 17 September 2026 QoSformer: A Framework for Learning-Based QoS Prediction and Policy Evaluation draft-xie-qosformer-qos-assurance-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 March 2027. Xie, et al. Expires 21 March 2027 [Page 1] Internet-Draft QoSformer Framework September 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and Status . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases and Design Objectives . . . . . . . . . . . . . . . 5 3.1. Uplink Live Streaming . . . . . . . . . . . . . . . . . . 5 3.2. Interactive Services and Variable Load . . . . . . . . . 6 3.3. Design Objectives . . . . . . . . . . . . . . . . . . . . 6 4. Functional Architecture . . . . . . . . . . . . . . . . . . . 7 5. Multiple Flow Snapshot Encoding . . . . . . . . . . . . . . . 8 5.1. Inputs and Temporal Alignment . . . . . . . . . . . . . . 8 5.2. Tensor Structure and Position Information . . . . . . . . 9 6. QoSformer Model Workflow . . . . . . . . . . . . . . . . . . 10 6.1. Self-Supervised Pre-Training . . . . . . . . . . . . . . 10 6.2. Task-Specific Prediction . . . . . . . . . . . . . . . . 11 6.3. Model Preparation and Release . . . . . . . . . . . . . . 11 7. Online Policy Evaluation and Feedback . . . . . . . . . . . . 12 7.1. Trigger and Baseline . . . . . . . . . . . . . . . . . . 13 7.2. Candidate Generation and Comparison . . . . . . . . . . . 13 7.3. Authorization, Application, and Feedback . . . . . . . . 14 7.4. Information Associated with a Decision . . . . . . . . . 15 8. Example Mapping to a 5G Core Network . . . . . . . . . . . . 15 9. Evaluation Methodology . . . . . . . . . . . . . . . . . . . 16 9.1. Data and Prediction Accuracy . . . . . . . . . . . . . . 16 9.2. Timing and Candidate Evaluation . . . . . . . . . . . . . 17 9.3. Data Efficiency, Robustness, and Deployment Effects . . . 17 10. Operational Considerations . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. Informative References . . . . . . . . . . . . . . . . . . . 19 Appendix A. Example Model Configuration . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Xie, et al. Expires 21 March 2027 [Page 2] Internet-Draft QoSformer Framework September 2026 1. 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 [RFC9232] 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. 1.1. 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. Xie, et al. Expires 21 March 2027 [Page 3] Internet-Draft QoSformer Framework September 2026 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 Section 8 is a deployment example, not a complete interface specification. Numeric model settings in Appendix A 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. 2. 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: Xie, et al. Expires 21 March 2027 [Page 4] Internet-Draft QoSformer Framework September 2026 +==============+=============================================+ | 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 | +--------------+---------------------------------------------+ Table 1: Abbreviations The term "masked autoencoder" is written out to distinguish it from MAE, the prediction-error metric. 3. Use Cases and Design Objectives 3.1. 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. Xie, et al. Expires 21 March 2027 [Page 5] Internet-Draft QoSformer Framework September 2026 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. 3.2. 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. 3.3. 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. Xie, et al. Expires 21 March 2027 [Page 6] Internet-Draft QoSformer Framework September 2026 4. Functional Architecture Figure 1 shows the logical functions. Arrows describe information dependencies, not newly specified interfaces. Functions can be colocated or connected by deployment-specific adapters. Measurements Flow configuration Resource context | | | +--------------------+------------------------+ | v +------------------------+ | Collection, alignment, | | and MFS encoding | +------------------------+ | v +------------------------+ +--------------+ | QoSformer prediction |<----| Approved | | Candidate evaluation | | model store | +------------------------+ +--------------+ | Recommendation | v +------------------------+ | Policy authority | | and constraint checks | +------------------------+ | Authorized change | v +------------------------+ | Existing enforcement | +------------------------+ | Post-change measurements | +----> Collection and feedback Figure 1: Logical QoS prediction and policy evaluation architecture Xie, et al. Expires 21 March 2027 [Page 7] Internet-Draft QoSformer Framework September 2026 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. 5. Multiple Flow Snapshot Encoding 5.1. 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. Xie, et al. Expires 21 March 2027 [Page 8] Internet-Draft QoSformer Framework September 2026 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. 5.2. 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. Xie, et al. Expires 21 March 2027 [Page 9] Internet-Draft QoSformer Framework September 2026 Per-flow time series ----> 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 Figure 2: MFS input preparation Figure 2 summarizes the encoding pipeline. The preprocessing configuration is versioned with the model, including units, normalization, categorical vocabularies, window sizes, and treatment of missing values. 6. QoSformer Model Workflow 6.1. 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. Xie, et al. Expires 21 March 2027 [Page 10] Internet-Draft QoSformer Framework September 2026 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 Appendix A illustrates the architecture and masking settings. 6.2. 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. 6.3. 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. Xie, et al. Expires 21 March 2027 [Page 11] Internet-Draft QoSformer Framework September 2026 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. Operator Preparation/training Model store Online | | | | |-- training task --->| | | | |-- prepare dataset -->| | | |<-- training data ----| | | | | | | pre-train, fine-tune, validate | | | | | |<-- validation ------| | | |-- approval -------->| | | | |-- approved bundle -->| | | | |<-- load ------| | | |-- bundle ---->| | | | warm-up |<----------------------- ready notification ----------------| Figure 3: Illustrative offline preparation and release sequence Figure 3 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. 7. Online Policy Evaluation and Feedback Xie, et al. Expires 21 March 2027 [Page 12] Internet-Draft QoSformer Framework September 2026 7.1. 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. 7.2. 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. Xie, et al. Expires 21 March 2027 [Page 13] Internet-Draft QoSformer Framework September 2026 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. 7.3. 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. Telemetry QoSE Policy authority Enforcement | | | | |-- state --->| | | | validate inputs | | | predict baseline | | | evaluate candidates | | | |-- recommendation ->| | | | check constraints | | | |-- approved change ->| | | |<-- apply status ----| | |<-- decision/status-| | | | | | |<---------------- post-change measurements -------------| |-- feedback->| | | | compare prediction | | | with observed result | | Figure 4: Online evaluation, authorization, and feedback Figure 4 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. Xie, et al. Expires 21 March 2027 [Page 14] Internet-Draft QoSformer Framework September 2026 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 Section 6.3; online feedback does not automatically authorize new model weights. 7.4. 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. 8. Example Mapping to a 5G Core Network The 5G system architecture is described in [TS23501], with procedures in [TS23502], network analytics in [TS23288], and policy control in [TS23503]. 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. Xie, et al. Expires 21 March 2027 [Page 15] Internet-Draft QoSformer Framework September 2026 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. 9. 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. 9.1. 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. Xie, et al. Expires 21 March 2027 [Page 16] Internet-Draft QoSformer Framework September 2026 9.2. 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. 9.3. 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. 10. 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. Xie, et al. Expires 21 March 2027 [Page 17] Internet-Draft QoSformer Framework September 2026 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. 11. 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 [RFC9846] 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. Xie, et al. Expires 21 March 2027 [Page 18] Internet-Draft QoSformer Framework September 2026 12. 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 [RFC6973] 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. 13. IANA Considerations This document has no IANA actions. 14. Informative References [RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [TS23501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP TS 23.501 V18.9.0, April 2025, . [TS23502] 3GPP, "Procedures for the 5G System (5GS)", 3GPP TS 23.502 V18.9.0, April 2025, . Xie, et al. Expires 21 March 2027 [Page 19] Internet-Draft QoSformer Framework September 2026 [TS23503] 3GPP, "Policy and charging control framework for the 5G System (5GS); Stage 2", 3GPP TS 23.503 V18.9.0, April 2025, . [TS23288] 3GPP, "Architecture enhancements for 5G System (5GS) to support network data analytics services", 3GPP TS 23.288 V18.9.0, April 2025, . Appendix A. 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. +=======================================+=========================+ | 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 | +---------------------------------------+-------------------------+ Table 2: Illustrative QoSformer model settings Xie, et al. Expires 21 March 2027 [Page 20] Internet-Draft QoSformer Framework September 2026 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. Authors' Addresses Xiaohui Xie Tsinghua University Email: xiexiaohui@tsinghua.edu.cn Shengnan Liu Tsinghua University Email: liusn25@mails.tsinghua.edu.cn Gang Yi Huawei Email: yigang8@huawei.com Yong Cui Tsinghua University Email: cuiyong@tsinghua.edu.cn Xie, et al. Expires 21 March 2027 [Page 21]