WO2025080186A1 - Admission control of model-related traffic - Google Patents

Abstract

A User Equipment, UE (110) transmits a connection request for model-related traffic to a network node (120) The connection request comprises a request for the wireless communication network (100) to deliver a model to the UE (110) or for the UE (110) to deliver model training data collected by the UE to a model training node. The network node (120) receives the connection request and selects between approving or denying the connection request based on the model-related traffic.

Description

ADMISSION CONTROL OF MODEL-RELATED TRAFFIC

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 63/543212, filed 9 October 2023, the entire disclosure of each being hereby incorporated by reference herein.

TECHNICAL FIELD

The present disclosure generally relates to the technical field of wireless communication and, more particularly, to Lifecycle Management (LCM) of an Artificial Intelligence (Al) and/or Machine Learning (ML) model in which inferences are performed at a User Equipment (UE).

BACKGROUND

Al and ML have been investigated, both in academia and industry, as promising tools to optimize the design of the air-interface in wireless communication networks. Example use cases include using autoencoders for Channel State Information (CSI) compression to reduce the feedback overhead and improve channel prediction accuracy; using deep neural networks for classifying Line-of-Sight (LOS) and Non-LOS (NLOS) conditions to enhance the positioning accuracy; and using reinforcement learning for beam selection at the network side and/or the UE side to reduce the signaling overhead and beam alignment latency; and using deep reinforcement learning to learn an optimal precoding policy for complex Multiple Input Multiple Output (MIMO) precoding problems.

In 3rd Generation Partnership Project (3GPP) New Radio (NR) standardization work, a new release 18 study item on AI/ML for the NR air interface started in May 2022. This study item will explore the benefits of augmenting the air interface with features enabling improved support of AI/ML based algorithms for enhanced performance and/or reduced complexity/overhead. Through studying a few selected use cases (CSI feedback, beam management, and positioning), this study item aims at laying the foundation for future airinterface use cases leveraging AI/ML techniques.

SUMMARY

The present disclosure generally relates to admission control in a wireless communication network that differentiates model-related traffic from other traffic and/or between different types of model-related traffic. Particular embodiments support the transfer or delivery of models and/or training data by prioritizing or deprioritizing connections requested that will be used for said transfer or delivery.

Embodiments include a method implemented by a UE. The method comprises transmitting, to a network node of a wireless communication network, a connection request for model-related traffic. The connection request comprises a request for the wireless communication network to deliver a model to the UE or for the UE to deliver model training data collected by the UE to a model training node. In some embodiments, the method further comprises exchanging, with the network node, a priority identifier that is based on a random access resource and/or a 5G Quality of Service Identifier (5QI), and/or a Single Network Slice Selection Assistance Information (S- NSSAI). In some such embodiments, the priority identifier comprises an establishment cause indicating a reason for requesting the connection, the establishment cause being comprised in a MSG3 or MSGA random access message of a random access procedure.

In some embodiments, the connection request comprises an initial connection setup request or a connection resume request or a handover request or a Quality of Service (QoS) flow setup request.

In some embodiments, the request is for the network to deliver the model to the UE and transmitting the connection request is responsive to the UE leaving an area in which the model is valid.

In some embodiments, transmitting the connection request is responsive to the UE leaving an area in which the access request would not have been allowed.

In some embodiments, the request is for the network to deliver the model to the UE and transmitting the connection request is responsive to validity of the model expiring.

In some embodiments, the request is for the network to deliver the model to the UE and transmitting the connection request is responsive to more than a threshold amount of time elapsing since the UE received the model.

In some embodiments, the request is for the network to deliver the model to the UE and transmitting the connection request is responsive to a performance metric of the model being below a threshold.

In some embodiments, the request is for the network to deliver the model to the UE and transmitting the connection request is responsive to the model executing for more than a threshold amount of time.

In some embodiments, the request is for the UE to deliver the model training data to the model training node and transmitting the connection request is responsive to exhausting memory allocated in the UE for storing the model training data.

In some embodiments, the request is for the UE to deliver the model training data to the model training node and transmitting the connection request is responsive to more than a threshold amount of time elapsing since a previous training data collection occurred.

In some embodiments, the request is for the UE to deliver the model training data to the model training node and transmitting the connection request is responsive to the model training data having been stored at the UE for more than a threshold amount of time.

In some embodiments, the request is for the UE to deliver the model training data to the model training node and transmitting the connection request is responsive to receiving a request from the network node for the training data. Other embodiments include a UE configured to transmit, to a network node of a wireless communication network, a connection request for model-related traffic. The connection request comprises a request for the wireless communication network to deliver a model to the UE or for the UE to deliver model training data collected by the UE to a model training node.

In some embodiments, the UE is further configured to perform any one of the UE methods described above.

In some embodiments, the UE comprises interface circuitry and processing circuitry communicatively connected to the interface circuitry. The processing circuitry is configured to transmit, to the network node of the wireless communication network via the interface circuitry, the connection request for model-related traffic. The processing circuitry may be further configured to perform any one of the UE methods described above.

Other embodiments include a computer program comprising instructions which, when executed on processing circuitry of a UE, cause the processing circuitry to carry out any one of the UE methods described above.

Embodiments of the present disclosure also include a method implemented by a network node of a wireless communication network. The method comprises receiving, from a UE, a connection request for model-related traffic. The connection request comprises a request for the wireless communication network to deliver a model to the UE or for the UE to deliver model training data collected by the UE to a model training node. The method further comprises selecting between approving or denying the connection request based on the model-related traffic.

In some embodiments, the method further comprises exchanging, with the UE, a priority identifier that is based on a random access resource and/or a 5QI and/or an S-NSSAI. In some such embodiments, the priority identifier comprises an establishment cause indicating a reason for requesting the connection, the establishment cause being comprised in a MSG3 or MSGA random access message of a random access procedure.

In some embodiments, the connection request comprises an initial connection setup request or a connection resume request or a handover request or QoS flow setup request.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to the model-related traffic having a QoS requirement that is lower than a QoS threshold and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to the model-related traffic being of a size that is larger than a size threshold and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to the model-related traffic being associated with a low priority function and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to the model-related traffic being associated with a low priority model and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to the network load being below a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to the model-related traffic having a QoS requirement that is higher than a QoS threshold and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to the model-related traffic being of a size that is smaller than a size threshold and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to the model-related traffic being associated with a high priority function and the network load being above a load threshold.

In some embodiments, selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to the model-related traffic being associated with a high priority model and the network load being above a load threshold.

In some embodiments, the method further comprises preempting an already established connection to free resources for the requested connection.

Other embodiments include a network node configured to receive, from a UE, a connection request for model-related traffic. The connection request comprises a request for a wireless communication network to deliver a model to the UE or for the UE to deliver model training data collected by the UE to a model training node. The network node is further configured to select between approving or denying the connection request based on the model- related traffic. In some embodiments, the network node is further configured to perform any one of the network node methods described above.

In some embodiments, the network node comprises interface circuitry and processing circuitry communicatively coupled to the interface circuitry. The processing circuitry is configured to receive, from a UE via the interface circuitry, a connection request for model- related traffic. The connection request comprises a request for a wireless communication network to deliver a model to the UE or for the UE to deliver model training data collected by the UE to a model training node. The processing circuitry is further configured to select between approving or denying the connection request based on the model-related traffic.

In some embodiments, the processing circuitry is further configured to perform any one of the network node methods described above.

Other embodiments include a computer program comprising instructions which, when executed on processing circuitry of a network node cause the processing circuitry to carry out any one of the network node methods described above.

Yet other embodiments include a carrier containing UE computer program or the network node computer program described above. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying figures with like references indicating like elements.

FIG. 1 is a schematic block diagram illustrating an example of training and inference pipelines within a model LCM procedure, according to one or more embodiments of the present disclosure.

FIG. 2 is a schematic block diagram illustrating an example framework for studying aspects of an AI/ML model, according to one or more embodiments of the present disclosure.

FIG. 3 is a schematic block diagram illustrating example of CSI reporting using a two- sided model, according to one or more embodiments of the present disclosure.

FIG. 4 is a table illustrating example combinations of options for model-related traffic, according to one or more embodiments of the present disclosure.

FIG. 5 is a schematic block diagram illustrating an example wireless communication network, according to one or more embodiments of the present disclosure.

FIG. 6 is a flow diagram illustrating an example method implemented by a UE, according to one or more embodiments of the present disclosure.

FIG. 7 is a flow diagram illustrating an example method implemented by a network node, according to one or more embodiments of the present disclosure.

FIG. 8 is a schematic block diagram illustrating an example UE, according to one or more embodiments of the present disclosure. FIG. 9 is a schematic block diagram illustrating an example network node, according to one or more embodiments of the present disclosure.

DETAILED DESCRIPTION

As used herein, the term “model” refers to one or more data structures and/or algorithms used to generate a prediction from collected input data. The terms “model,” “ML model,” “Al model,” “AI/ML model,” and “Al and/or ML model” should be considered to have equivalent meanings to each other and therefore be interchangeable. As will be discussed in greater detail below, a model may be deployed, implemented, and/or configured in a Wireless Device (WD), in a network node, or both. As used herein, the terms UE and WD each refer to a device attached to a wireless communication network at a Radio Access Network (RAN) and should be considered interchangeable.

Building a model may include several development steps. The actual training of the model may be just one step in a training pipeline. An important part of model development is model LCM. FIG. 1 is an illustration of training and inference pipelines 10, 20 and their interactions within a model LCM procedure 30. The model LCM procedure 30 typically comprises a training pipeline 10 (which may or may not be used for retraining, either partly or wholly), a model deployment stage 16, an inference pipeline 20, and a drift detection stage 25.

The training pipeline 10 may include data ingestion 11 , data preprocessing 12, model training 13, model evaluation 14, and/or model registration 15.

Data ingestion 11 refers to gathering raw data (e.g., training data) from data storage. After data ingestion 11 , there may also be a step that controls the validity of the gathered data.

Data preprocessing 12 refers feature engineering that is applied to the gathered data. For example, data preprocessing 12 may include data normalization and/or data transformation required for the input data to the model.

Model training 13 refers to the actual model training steps.

Model evaluation 14 refers to benchmarking model performance to some model baseline. The iterative steps of model training 13 and model evaluation 14 may continue until an acceptable level of performance is achieved.

Model registration 15 refers to registering the model, including any corresponding metadata that provides information on how the model was developed, and possibly model evaluation performance outcomes.

The deployment stage 16 makes the trained (e.g., retrained) model part of the inference pipeline 20.

The inference pipeline 20 may include data ingestion 21 , data preprocessing 22, model operation 23, and data and/or model monitoring 24.

Data ingestion 21 refers to gathering raw data (e.g., inference data) from a data storage.

Data preprocessing 22 for the inference pipeline 20 is substantially similar to the corresponding data preprocessing 12 that occurs in the training pipeline 10. Model operation 23 refers to using the trained and deployed model in an operational mode.

Data and model monitoring 24 refers to validating that the inference data are from a distribution that aligns well with the training data, as well as monitoring model outputs for detecting any performance, or operational, drifts.

The drift detection stage 25 informs about any drifts in the model operations.

FIG. 2 illustrates a functional framework for studying model LCM aspects. The framework may, for example, be used for studying different network (NW)-UE collaboration levels for physical layer use cases.

The models being discussed in the Rel-18 study item on AI/ML for the NR air interface can be categorized into the following two types, namely a one-side AI/ML model and a two-side AI/ML model.

The one-side AI/ML model may be a UE-sided model whose inference is performed entirely at the UE or a NW-sided model whose inference is performed entirely at the NW.

The two-sided AI/ML model refers to paired models over which joint inference is performed across the UE and the NW. That is, the first part of the inference is firstly performed by a UE and the remaining part is performed by a network node (e.g., at a next generation Node B (gNB)), or vice versa.

FIG. 3 shows an example use case of autoencoder (AE)-based two-sided CSI compression, where an encoder 42 (i.e., the UE-part of the two-sided AE model) is operated at a UE to compress measured CSI 41 produced by estimating a wireless channel, and the output of the encoder (the compressed wireless channel information estimates 43) is reported from the UE to a gNB. The gNB uses a decoder 44 (i.e., the NW-part of the two-sided AE model) to reconstruct the estimated wireless channel information and produce the reconstructed CSI 45.

In functionality-based LCM, 3GPP signaling may be used by the network to indicate activation, deactivation, fallback, and/or switching of AI/ML functionality. Such 3GPP signaling may include, e.g., Radio Resource Control (RRC), Medium Access Control (MAC) Control Element (MAC-CE), and/or Downlink Control Information (DCI), among others. In many cases, models may not be identified at the network and the UE may perform model-level LCM. Whether (and how much) awareness the network should have about such model-level LCM currently requires further study within the industry. For functionality identification, there may be one or more functionalities defined within an AI/ML-enabled feature (i.e., a feature in which AI/ML may be used). Notably, a UE may have one AI/ML model for such functionality, or the UE may have multiple AI/ML models for the functionality, depending on the embodiment.

For AI/ML functionality identification and functionality-based LCM of UE-side models (and/or the UE-part of two-sided models), AI/ML functionality refers to an AI/ML-enabled feature or Feature Group (FG) enabled by one or more configurations, wherein the one or more configurations are supported based on conditions indicated by UE capability. Correspondingly, functionality-based LCM generally operates based on at least one configuration of AI/ML- enabled feature (or FG).

After functionality identification, mechanisms for the UE to report one or more identified functionalities may be performed. The identified functionalities may be a subset of all functionalities that are available or configured.

In model-ID-based LCM, models are identified at the network, and the network or the UE may activate, deactivate, select, and/or switch individual AI/ML models using the model ID.

For AI/ML model identification and model-ID-based LCM of UE-side models (and/or the UE-part of two-sided models), model-ID-based LCM operates based on identified models, where a model may be associated with specific configurations and/or conditions associated with UE capability of an AI/ML-enabled Feature/FG and additional conditions (e.g., scenarios, sites, and datasets) as determined/identified between UE-side and NW-side.

From the perspective of the physical layer of the RAN (RAN1), an AI/ML model identified by a model ID may be logical, and how it maps to one or more physical AI/ML models may be up to implementation. When distinction is necessary for discussion purposes, companies may use the term “logical AI/ML model” to refer to a model that is identified and assigned a model ID and the term “physical AI/ML model” to refer to an actual implementation of such a model.

Model identification may be categorized into multiple types. For purposes of this disclosure, a Type A model will refer to a model that is identified to the network (if applicable) and the UE (if applicable) without over-the-air signaling. The model may be assigned with a model ID during model identification, which may be referred to and used in over-the-air signaling after model identification.

A Type B model will refer to a model that is identified via over-the-air signaling. In particular, a Type B1 model will refer to a model in which model identification is initiated by the UE. The network may assist with one or more remaining steps of the model identification, if any. In contrast, a Type B2 model will refer to a model in which model identification is initiated by the network, and UE may, if applicable, respond for one or more remaining steps of the model identification, if any. Type B models may be assigned with a model ID during model identification, whether they are of Type B1 or B2.

Once models are identified, the UE can indicate one or more supported AI/ML model IDs for a given AI/ML-enabled feature (or FG) in a UE capability report. Such model identification using a capability report may be performed for any model type (i.e., Type A, Type B1 , Type B2) depending on the embodiment.

A Model ID may or may not be globally unique, and different types of model IDs may be created for a single model for various LCM purposes. For functionality/model-ID based LCM, once functionalities/models are identified, the same or similar procedures may be used for their activation, deactivation, switching, fallback, and monitoring. The UE and the network may collaborate a different levels, depending on the embodiment. For purposes of this disclosure, level x is considered a no collaboration scenario. When there is no collaboration, implementation is based only AI/ML algorithms without information exchange. Level y refers to signaling-based collaboration without model transfer. This level would also include embodiments without model delivery. Level z refers to signalingbased collaboration with model transfer.

Although embodiments herein may refer to the “delivery” or “transfer” of a model or data relating thereto, it should be appreciated that whenever either of these terms is used herein, the other may be equally appropriate according to various embodiments (unless otherwise specified). As used herein, the phrase “model-related traffic” refers to traffic that transfers or delivers a model and/or data collected for purposes of training a model.

The distinction between level x and level y may be readily appreciated. Level x, for purposes of this disclosure, is implementation-based AI/ML operation without any dedicated AI/ML-specific enhancement (e.g., LCM related signaling, Reference Signal (RS)) collaboration between network and UE. The distinction between level y and level z is based on whether model delivery over the air interface is done in a manner to that is non-transparent to 3GPP signaling.

FIG. 4 is a table illustrating examples of different uses cases, according to one or more embodiments of the present disclosure. Each use case includes a different combination of options for delivery of a model to a UE, training location, and model delivery format combinations, as it relates to UE-side models (or the UE-part of two-sided models).

Model delivery of an unknown structure at the UE has more challenges related to feasibility (e.g. UE implementation feasibility) compared to delivery of a known structure at UE. That said, according to one or more of the embodiments discussed herein, one or more AI/ML models are transferred or delivered to a UE:

1) by a gNB via RRC signaling;

2) by a gNB via user plane data;

3) by a core network via Non-Access Stratum (NAS) signaling;

4) by a core network via user plane data;

5) by a Location Management Function (LMF) via Long Term Evolution (LTE) Positioning Protocol (LPP) signaling;

6) by an LMF via UP data; and/or

7) by a server (e.g., an Operations and Maintenance (OAM) server, an Over-the-Top (OTT) server) using signaling that is transparent to 3GPP.

Most of the transfer scenarios above concern an AI/ML model being transferred from a 3GPP node towards a UE (e.g., a RAN node, a core network node). However, non-3GPP methods and nodes may be supported as well. For example, transfer option 7 listed may include an OTT server transferring the model to the UE. As shown in the framework illustrated in FIG. 2 and discussed above, this may include a scenario in which a model is trained, stored, and transferred towards the UE from the OTT server, or whether when the model is trained in another node (e.g., a 3GPP-node like a RAN or core network node) and then stored in the OTT server to be later transferred towards the UE.

Irrespective of whether the UE-side model training is performed by a node outside the RAN (e.g., in a core network node) or even outside the 3GPP network (e.g., in a UE-vendor specific server, like an OTT server), a certain amount of data may be collected by the UE in order to enable such a node to perform model training. Indeed, in many use cases (e.g., Al- based CSI compression, Al-based CSI prediction, Al-based beam management, Al-based positioning, Al-based mobility predictions, Al-based traffic predictions), the training node may need to receive input from the UE. Accordingly, a protocol in which the UE does training data collection (e.g., upon receiving a trigger from the training node) for a certain amount of time, and once the data collection is completed, the collected data is transferred to the training node.

FIG. 5 is a schematic diagram illustrating an example network 100 comprising a RAN node 120 (sometimes referred to as a Mobile Network Node (MNN)), a core network node 140, an Over-the-T op (OTT) node 150, and a UE 110. The RAN node 120 serves a cell 130 to the UE 110. The cell 130 supports a RAT (e.g., NR, 6G) that provides the UE 110 with access to a core network 160 that comprises the core network node 140. The core network 160 provides access to the OTT server 150, which may be external to the core network 160.

The UE 110 typically gains access to the core network 160 by participating in a random access procedure with the network node 120. The random access procedure may be contention-free or contention based, depending on the embodiment. 5G NR supports two types of Contention Based Random Access (CBRA): 4-step CBRA (introduced in NR Rel-15 and similar to the one adopted in LTE) and 2-step CBRA (introduced in NR Rel-16). Therefore, a 5G network may select the type of CBRA that best supports intended use cases and deployment scenarios.

For the 4-step CBRA, a UE 110 initiates an access attempt by transmitting a preamble (MSG1) on a Physical Random Access Channel (PRACH). After detecting the preamble, the gNB responds with a Random Access Response (RAR) message (MSG2) on a Physical Downlink Shared Channel (PDSCH). Upon successful reception of the RAR, the UE 110 transmits on a Physical Uplink Shared Channel (PUSCH) the MSG3 for UE identification and RRC connection request. Finally, the gNB sends the MSG4 for contention resolution.

For the 2-step CBRA, in the first step, a UE 110 transmits a MSGA, which is a combination of a preamble on PRACH and a payload on PUSCH. In the second step, the gNB responds by transmitting a MSGB, which contains the response for contention resolution.

If system resources are reaching maximum utilization, admission control may limit incoming traffic. This can be achieved by different actions, such as rejecting incoming connections requests, queuing incoming connection requests in response to a temporary load peak, and/or attempt to remove established connections to release resources needed by incoming connections. To further regulate the number of connections reaching a highly-loaded cell, admission control may additionally or alternatively include a waitTime element in RRC Reject and/or RRC Release messages sent to UEs that are not allowed to connect. Those UEs may then bar Access Classes (ACs) for the time interval indicated by the waitTime element. In some embodiments, ACs 0 and 2 may be excluded from such access barring.

Examples of connection procedures that can trigger admission control actions are initial connection setup, resume, handover, and Quality of Service (QoS) flow setup requests. Admission control, in fact, can act upon both connecting new users and establishing each of the multiple services, mapped to QoS flows, that a connected user might run. Different indicators may be used by admission control to provide accessibility differentiation in 5G networks, including:

• Establishment Cause in the MSG3 or MSGA PUSCH transmission during a random access procedure, which indicates the reason for its access request.

• Allocation and Retention Priority (ARP); i.e., a QoS parameter that presently defines three important prioritization aspects of a QoS flow. The ARP priority level indicates the relative importance of the service mapped to the QoS flow; the pre-emption capability indicates whether the QoS flow can trigger the release of another one; and the pre-emption vulnerability indicates whether the QoS flow can be pre-empted by another one.

• 5G QoS Identifier (5QI), which is a scalar associated with each QoS flow and used by the network as indication of the traffic forwarding treatment. Standardized or preconfigured QoS characteristics may be indicated through the 5QI value.

• Single Network Slice Selection Assistance Information (S-NSSAI), which identifies a network slice. S-NSSAI is a combination of a mandatory slice/service type (SST) field identifying the slice behavior in terms of features and services and an optional slice differentiator (SD) field that differentiates among slices with the same SST field.

In spite of the above, adoption of AI/ML model-enabled function faces many challenges. In future networks, there can be as many as thousands of UE-side models deployed at a network. For example, there may be many Al-capable UEs in the network. Further, one UE may support multiple Al models associated with one or more Al-based features. Furthermore, one UE may support multiple different Al-based features.

Further, different UE-sided models may have different model sizes. Some Al Physical Layer (PHY) models can be very large and delivering/transferring such models to UEs can cause problems for sensitive traffic or normal data traffic transmission in the network.

Different UE-sided models may have different QoS requirements on model delivery based on the features/use-cases that the models are applied for. For instance, some models need to be delivered/transferred with low latency and high reliability. If model delivery is done OTT and the 5G cellular network may be unaware of the model delivery. Accordingly, model delivery for these models may be treated as low priority traffic, which may be problematic. In this case, models may not be successfully or timely received at UEs.

On the other hand, some models may have relaxed QoS requirements. However, with large model sizes, even if model delivery for these models are treated as low priority traffic, in high load situations, delivering/transferring such models can impact the normal data traffic transmission or cause network congestion (especially if many UEs started model delivery OTT at the same time).

Further, when the network detects a UE-sided/UE-part model is not functioning well for many users in the network, or when the network received indicates of model malfunction from many users associated to the same model, continue delivering/transferring the malfunction model may be a waste of network resources.

Accordingly, solutions are needed to create network awareness of the model-related traffic that is ongoing in the network for delivering/transferring UE-side/UE-part models from network node to UE. In addition, solutions are needed to enable a network node to control/differentiate the transmission of the model delivery traffic in certain scenarios, e.g., when the network is in high load situations, and/or when there is a model that shall be transferred/delivered with high reliability low latency, and/or when there is malfunction detected for a model that is to be delivered/transferred.

A similar problem arises when transferring collected data from the UE to the node performing the training (e.g., an OTT node). Uploading this collected data may take time and impact the UE performance and the RAN system performance, e.g., in terms of uplink radio resources available to the UE and/or radio resources available to other UEs in the same cell and/or area. In particular, the delivery of the collected data may be delayed if the cell is congested. Delaying the delivery of the collected data may delay training or updates of an AI/ML model.

In view of the above, embodiments of the present disclosure create network awareness of model-related traffic. Particular embodiments enable a network node to control and/or differentiate model delivery traffic in certain scenarios, e.g., when network load is high, when a model will be transferred with high reliability or low latency, and/or when a malfunction is detected for a model to be transferred.

One or more of the embodiments proposed herein will, e.g., enable the network node 120 to maintain service quality for ongoing high priority services during high load situations while ensuring that incoming prioritized model transfer requests receive the desired access treatment. The network may additionally or alternatively reject model delivery when a malfunction with a model is detected.

One or more priority identifiers are designed for model-related traffic. A network node performs admission control that differentiates model-related traffic based on defined priority identifiers. This includes differentiated connection request priority handling between model- related traffic and other traffic and/or between different types of model-relative traffic.

The network node performing the admission control can be a RAN node (e.g. gNB, 6G RAN node, or a core network node, such as UPF, AMP). The node performing the training may transfer the model to the UE. Such a node may be outside the 3GPP network (e.g. , an OTT server) or it may be represented by a logical function within a 3GPP network node (e.g., an application layer function within a 3GPP network node).

As will be explained in greater detail below, in one example, all types of model-related traffic are considered as a new type of service and a single priority identifier or a single set of priority identifiers is designed for this new type of service. In another example, different types of model-related traffic that are associated with different QoS requirements, and/or different model sizes, and/or different model identifications are considered as different type of services. Different priority identifiers or different sets of priority identifiers are designed for these new types of service.

Embodiments include the UE determining when to initiate the connection request for receiving a model from the node performing the training, in response of any of the following:

• Exiting the area of validity one or more models currently used by the UE, the area being, e.g., a RAN node coverage area, a geographical area, a site covered by a network operator.

• Exiting an area in which the access request for the first purpose was not allowed, the area being, e.g., a RAN node coverage area, a geographical area, a site covered by a network operator.

• Expiration of the validity of one or more models currently used by the UE.

• Time elapsed since the last reception of one or more of the models currently used by the UE above of a certain threshold.

• Performance metrics, e.g. accuracy, of the one or more of the models currently used below a certain threshold.

• Time elapsed since the one or more of the models are being executed above of a certain threshold.

• Entering connected mode, upon receiving indication, e.g. from the higher layers of the UE, to request a new model from the node performing the training.

Embodiments also include the UE determining when to initiate the connection request for transferring collected data, in response of any of the following:

• Completing the data collection.

• Exhausting the memory allocated in the UE to store collected data.

• Exiting an area, e.g. gNb, site, geographical area, network operator, in which the access request for the second purpose was not allowed. • Time elapsed since the last transferring of collected data above of a certain threshold.

• Time for which the currently stored data have been stored by the UE above a certain threshold.

• Request received from the node performing the training to transfer collected data.

• Entering connected mode, while data collected are stored in the UE memory.

Particular embodiments obtain one or more of these benefits using one or more priority identifiers that are defined for model-related traffic. The priority identifier may be, for example, an establishment cause, a 5QI, a random access resource configuration, and/or a network slice ID. A network node 120 performs differentiated admission control operations between model delivery traffic and other traffic, or among different modes of delivery traffic based on the defined priority identifiers.

For example, one or more priority identifiers may be designed for model-related traffic (e.g., for model delivery and/or model data transfer). A network node 120 performs, based on the defined priority identifies, differentiated connection request priority handling:

• between model-related traffic and other traffic in the network;

• among different types of model-related traffic;

• between other traffic and UE-collected data being transferred from the UE to the training node;

• among different types of UE-collected data being transferred from the UE to the training node.

For example, a network node 120 may perform differentiated admission control operations between model-related traffic and other traffic, or among different modes of model- related traffic based on one or more priority identifiers. The one or more priority identifiers may be defined for different model-related traffic. For example, models associated with different AI/ML functionalities may be associated with different identifiers. Additionally or alternatively, different models may be associated with the same AI/ML functionality, yet may nonetheless be associated with different identifiers. In another embodiment, a network node 120 performs differentiated admission control operations between the transfer of UE-collected data and other traffic. Alternatively, the network node 120 may perform differentiated admission control operations among different transfers of UE-collected data based on one or more priority identifiers. The one or more priority identifiers may be defined for different traffic types associated with the transfer of collected data.

For example, the UE 110 may collect data at the same time for different AI/ML functionalities (e.g., CSI compression, CSI predictions, positioning, L3 mobility) or to enforce different models that the node performing the training (i.e., the training node) is handling. Hence, the UE 110 may have different collected data associated with different AI/ML functionalities and/or models available to transfer. In any of the embodiments discussed herein, the one or more priority identifiers may include a PRACH/MsgA resource configuration and/or an establishment cause and/or a standardized or pre-configured 5QI and/or a network slice identifier.

In some embodiments, a single identifier or set of identifiers may be designated for traffic of the same priority. In one example, all types of model-related traffic may have the same priority and a single priority identifier (or a single set of priority identifiers) is designed for such traffic. Additionally or alternatively, all types of data collection traffic may have the same priority and a single priority identifier or a single set of priority identifiers is designed for such traffic. Additionally or alternatively, all traffic types associated with model-related traffic (e.g., model delivery and/or model data transfer) have the same priority and a single priority identifier or a single set of priority identifiers is designated for such traffic.

The network node may be enabled to perform differentiated connection request priority handling between connection requests from UEs for model-related traffic and connection requests from UEs for other traffic (i.e., non-model-related traffic) using admission control mechanisms.

In some such embodiments, a set of PRACH/MsgA resources is configured for access requests associated with model-related traffic (e.g., model delivery and/or collected data transfer). The set of PRACH/MsgA resources may, for example, include one or more of any of the following:

• one or more random access preambles;

• one or more PRACH time/frequency resources;

• one or more MsgA PUSCH time/frequency resources;

• one or more MsgA PUSCH DMRS configurations.

During random access procedure, by receiving the Msg1/MsgA from a UE 110, a network node 120 may identify a model-related traffic request and decide whether to accept or reject the request based on certain conditions (e.g., traffic load in the network). In some embodiments, the same set of PRACH/MsgA resources is configured for the requests associated with the model delivery as for collected data transfer.

In some embodiments, a new establishment cause for model-related traffic is defined. During CBRA, by receiving the establishment cause on Msg3 from a UE 110, the network can identify the model-related traffic request and decide whether to accept it and send an RRC Setup message to the UE 110 or to reject it based on certain conditions and send an RRC Reject message instead (e.g., based on the traffic load in the network). In some embodiments, the establishment cause is the same for all model-related traffic connection requests. In other embodiments, different types of model-related traffic connection requests are associated with different establishment causes (e.g., different establishment causes for model delivery as compared to collected data transfer). In some embodiments, one or more new values (e.g., larger values) are added in the waitTime information in the RRC Reject message and/or RRC Release message. After identifying the access requests associated with a model-related traffic request is for transferring collected data, the network node 120 may includes waitTime information in the RRC Reject message and/or RRC Release message sent to the requesting UE(s) 110 to not allow them to connect for a certain duration.

In some embodiments, a standardized or pre-configured 5QI value is defined for model delivery requests and another standardized or pre-configured 5QI value is defined for collected data transfer requests. These 5QI value(s) may be treated with a lower priority than other traffic. The network node 120 identifies the connection request for model-related traffic based on the defined 5QI and decides whether to admit or reject the QoS flow based on certain conditions, e.g., based on traffic load in the network.

In some embodiments, a network slice identifier (e.g., an S-NSSAI indicator) is defined for model delivery traffic and another network slice identifier is defined for collected data transfer. The network slice identifier is mapped to the specific network slice of the Packet Data Unit (PDU) session hosting the model-related traffic or collected data transfer. During initial context setup, a request is made to setup one or more new QoS flows mapped to the PDU session for model-related traffic. The network node 120 is informed of the network slice for which the resources are being requested. The network node 120 makes admission control decisions on the QoS flow setup request for model-related traffic depending on resource availability for the slice.

In many of the above examples, model-related traffic is given the same priority. That said, according to other embodiments, different types of model-related traffic have different priorities. Different priorities identifiers may be defined for one or more such priorities and configured at the UE 110 and within the network 100.

The different types of model-related traffic may be differentiated based on one or more factors. In some embodiments, model-related traffic may be differentiated based on QoS requirements. Examples of a QoS requirement may include latency measured from when a UE 110 sends a request for delivery of a model until having successfully received said model. Another example of a QoS requirement may include a required reliability of the model-related traffic being requested.

In some embodiments, model-related traffic may be differentiated based on model structure. For example, whether the model is a Convolutional Neural Network, a Recurrent Neural Network, a transformer, or model having some other structure may be a basis for differentiating model-related traffic.

In some embodiments, model-related traffic may be differentiated based on model size. For example, model-related traffic may be prioritized based on which of a plurality of model size ranges a given model fits into. In some embodiments, model-related traffic may be differentiated based on feature and/or function identifications (or feature/function group identifications). For example, model- related traffic may be prioritized differently depending on whether a corresponding model implements a feature or function (or group thereof) relating to Al-based CSI compression, Al- based CSI prediction, Al-based beam prediction, and/or Al-based positioning.

In some embodiments, model-related traffic may be differentiated based on model identification. For example, a model identifier may indicate that a model corresponding to model-related traffic is a standardized model, a model that is offline aligned among the network and UE sides, or other model type. Model-related traffic may be prioritized differently depending on the model identifier.

In some embodiments, model-related traffic may be differentiated based on meta information that describes the applicable conditions for this model. Scenarios, cell identifiers, area identifiers, and network-configurations are examples of meta information that may be used as a basis for differentiating model-related traffic.

The differentiation discussed above may be applied to connection requests for delivering a model, transferring data collected for model training, or for other model-related traffic as discussed above, e.g., to differentiate based on QoS requirements, size, and so on.

Collected data transfer traffic may be differentiated based on when the collected data should be transferred to the node to perform model training. For example, if the collected data cannot be delivered by a certain time or within a given window, the UE 110 may need to restart data collection or clear from the UE memory the collected data.

A feature, functionality, feature group, or functionality group identifier as discussed above may, in some embodiments, be used to differentiate collected data traffic. Such an identifier may indicate which one or more models the transfer of collected data is meant to train.

Similarly, a model identifier as discussed above may indicate which one or more models the data is intended for (e.g., for a standardized model, for a model that is offline-aligned between the network and UE sides).

In some embodiments, collected data traffic may be differentiated based on which LCM stage the collected data relates to (e.g., model training, model performance monitoring, model inference, model deployment).

In some embodiments, collected data traffic may be differentiated based on the type of node performing the training (e.g., a RAN node, an QAM node, an OTT node). That is, collected data traffic may be differentiated based on the node to which the collected data is destined for.

By giving different types of model traffic different priorities, a network node 120 may perform differentiated connection request priority handling between different types of model- related traffic, as well as the ability to differentiate model-related traffic from other kinds of traffic. As previously noted, in some embodiments, a 5QI identifier is used to differentiate model-related traffic. In the following examples, different 5QI identifiers are used to differentiate different types of model-related traffic. As will be shown below, the defined 5QI values may be used to support differentiated admission control for model-related traffic.

For example, different 5QI values may be designated for model-related traffic having different QoS requirements (examples of which have been previously discussed). A network node 120 can prioritize the model-related traffic requests having high QoS requirements. For instance, a first 5QI value can be designated for model-related traffic with higher QoS requirements (e.g., for models to be delivered with low latency and high reliability) and a second 5QI value can be designated for model-related traffic with lower QoS requirements.

In some such embodiments, the first 5QI value can be given a higher priority than one or more other 5Qls associated with non-model-related traffic. The second 5QI value can given a lower priority than the one or more other 5Qls associated with the non-model-related traffic.

In some embodiments, the first 5QI value can be associated with a guaranteed bit rate (GBR) resource type or delay critical GBR resource type, whereas the second 5QI value can be associated with a non-GBR resource type.

In some embodiments, in certain conditions (e.g., high load situations), the network node 120 can deprioritize model-related traffic requests associated with lower QoS requirements from a UE 110 by rejecting QoS flow setup requests associated with the second 5QI value. Additionally or alternatively, the network node 120 may trigger preemption of existing connections associated with the second 5QI value to free up resources. Additionally or alternatively, the network node 120 may queue connection requests associated with the second 5QI value.

In some embodiments, the network node 120 may prioritize model-related traffic requests associated with higher QoS requirements received from a UE 110 by admitting the QoS flow setup requests associated with the first 5QI value. Additionally or alternatively, the network node 120 may trigger the preemption of existing connections with 5QI values associated with lower priority to free up resources.

Many of the embodiments described herein do not require the network node 120 to know or define the model identifiers of the models associated with the model-related traffic at least because the 5QI values are defined based on QoS requirements rather than the model identifier.

In some embodiments, different 5QI values are designed for model-related traffic that have different model sizes or are within particular model size ranges. In this regard, size may be considered based on bytes or number of model elements (e.g., number of model parameters). A network node 120 can prioritize model-related traffic requests based on model size. For instance, a first 5QI value can be associated with small model sizes (e.g., less than ten thousand parameters) and a second 5QI value can be associated with large model sizes (e.g., greater than one hundred thousand parameters). The first 5QI value may be given a higher priority than the 5QI values associated with non-model-related traffic. The second 5QI value may be given a lower priority than the 5QI values associated with non-model-related traffic. Then, similarly to other examples given above, under certain conditions (e.g., high load situations), the network node 120 can deprioritize model-related traffic requests associated with large model sizes. Additionally or alternatively, the network node 120 may prioritize model- related traffic requests associated with small model sizes.

In some embodiments, different 5QI values are associated with different Al-based features, functions, or groups thererof. Accordingly, a network node 120 can prioritize model- related traffic requests based thereon. For example, different Al-based features may be associated with different QoS requirements that should be prioritized differently. 5QI values may be associated with individual Al-based features/functions/groups or they may be associated with a set of Al-based features/functions/groups, depending on the embodiment.

Consider an example in which Al-based positioning features have higher QoS requirements and there is no legacy fallback scheme that can meet such high QoS requirements. In contrast, in this example, Al-based beam prediction features and Al-based CSI feedback features have lower QoS requirements (or there is a legacy fallback scheme available for such features). Accordingly, a first 5QI value can be associated with Al-based positioning and a second 5QI value can be associated with Al-based beam prediction features and Al-based CSI feedback features. The network can configure the first 5QI value to have a higher priority than the second 5QI value.

In some embodiments, the network node 120 may prioritize based on 5QI value when certain conditions are met (e.g., when network load is high). Under such circumstances, the network node 120 can deprioritize model-related traffic requests associated with the second 5QI value. The network node 120 may additionally or alternatively prioritize model-related traffic requests associated with the first 5QI value. Accordingly, admission-based traffic control for model-related traffic may be implemented.

As another example, when a given feature, function, or group thereof is not working (or other condition is met), the network node 120 may prevent a UE 110 from setting up a QoS flow associated with one or more models corresponding to the non-working function. The network node 120 may prevent setup of these QoS flows via admission control operations based on the associated 5QI value, e.g., until function is restored or for a given amount of time, in some situations.

In some embodiments, different 5QI values are associated with different model identifiers. Accordingly, a network node can prioritize and/or deprioritize model-related traffic requests for one or more models (or one or more sets of Al models) based on any of the criteria discussed above (e.g., QoS requirements of the model(s)). A 5QI value may be associated with one or more model identifiers. Each model identifier may be associated with one or more features, functions, or groups thereof. Consider an example in which one or more Al models are developed for an Al-based beam prediction feature and each Al model has a unique model identifier. A 5QI value may be associated with one or more of these models. The network node 120 can prioritize or deprioritize model-related traffic requests associated with these one or more models by configuring admission control operations. In some situations (e.g., when the network detects or is notified that an model is not working), the network node 120 can also prevent a UE 110 from setting up a QoS flow for the model for a certain amount of time by taking admission control operations based on the associated 5QI value.

Even though the above examples assume that a 5QI value is defined based on a certain property of the model to which traffic relates, it is possible that a 5QI value is defined based on any combination of properties of the model, e.g., the model size and the QoS requirements for delivering/transferring the model.

Additionally or alternatively, even though the above examples assume admission control operations are taken based on 5QI values, it is possible that the admission control operations are taken based on different priority identifiers at different stages, e.g., PRACH configuration or/and establishment cause based priority handling during random access control, 5QI based priority handling during QoS flow setup procedure, etc.

In an embodiment, the admission control operations associated to model-related traffic or for the transfer of collected data at the network node are taken based on different priority identifiers at different stages, e.g., PRACH configuration or/and establishment cause based priority handling during random access control, 5QI based priority handling during QoS flow setup procedure, etc.

In view of the above, FIG. 6 is a flow diagram illustrating an example method 200 implemented by a UE 110, according to one or more embodiments of the present disclosure. The method 200 comprises transmitting, to a network node 120 of a wireless communication network 100, a connection request for model-related traffic (block 220). The connection request comprising a request for the wireless communication network 100 to deliver a model to the UE 110 or for the UE 110 to deliver model training data collected by the UE 110 to a model training node. In some embodiments, the method further comprises collecting model training data (block 210).

Correspondingly, FIG. 7 is a flow diagram illustrating an example method 300 implemented by a network node 120 of a wireless communication network 100, according to one or more embodiments of the present disclosure. The method 300 comprises receiving, from a UE 110, a connection request comprising a priority identifier that identifies whether the requested connection is for model-related traffic (block 310). The method 300 further comprises selecting between approving or denying the connection request based on the priority identifier (block 320).

The UE 110 may, for example, be implemented as schematically illustrated in the example of FIG. 8. The UE 110 of FIG. 8 comprises processing circuitry 610, memory circuitry 620, and interface circuitry 630. The processing circuitry 610 is communicatively coupled to the memory circuitry 620 and the interface circuitry 630, e.g., via a bus 604. The processing circuitry 610 may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or a combination thereof. For example, the processing circuitry 610 may be programmable hardware capable of executing software instructions stored, e.g., as a machine-readable computer program 640 in the memory circuitry 620. The memory circuitry 620 of the various embodiments may comprise any non- transitory machine-readable media known in the art or that may be developed, whether volatile or non-volatile, including but not limited to solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid state drive, etc.), removable storage devices (e.g., Secure Digital (SD) card, miniSD card, microSD card, memory stick, thumb-drive, USB flash drive, ROM cartridge, Universal Media Disc), fixed drive (e.g., magnetic hard disk drive), or the like, wholly or in any combination.

The interface circuitry 630 may be a controller hub configured to control the input and output (I/O) data paths of the UE 110. Such I/O data paths may include data paths for exchanging signals over a network. The interface circuitry 630 may be implemented as a unitary physical component, or as a plurality of physical components that are contiguously or separately arranged, any of which may be communicatively coupled to any other or may communicate with any other via the processing circuitry 610. For example, the interface circuitry 630 may comprise a transmitter 632 configured to send wireless communication signals and a receiver 634 configured to receive wireless communication signals.

The UE 110 may be configured (e.g., by the processing circuitry 610) to perform the method 200 described above.

Still other embodiments include a control program 640 comprising instructions that, when executed on processing circuitry 610 of a UE 110, cause the UE 110 to carry out the method 200 described above.

Yet other embodiments include a carrier containing the control program 640. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Correspondingly, a network node 120 may be implemented as schematically illustrated in the example of FIG. 9. The network node 120 of FIG. 9 comprises processing circuitry 710, memory circuitry 720, and interface circuitry 730. The processing circuitry 710 is communicatively coupled to the memory circuitry 720 and the interface circuitry 730, e.g., via a bus 704. The processing circuitry 710 may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or a combination thereof. For example, the processing circuitry 710 may be programmable hardware capable of executing software instructions stored, e.g., as a machine- readable computer program 740 in the memory circuitry 720. The memory circuitry 720 of the various embodiments may comprise any non-transitory machine-readable media known in the art or that may be developed, whether volatile or non-volatile, including but not limited to solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid state drive, etc.), removable storage devices (e.g., Secure Digital (SD) card, miniSD card, microSD card, memory stick, thumb-drive, USB flash drive, ROM cartridge, Universal Media Disc), fixed drive (e.g., magnetic hard disk drive), or the like, wholly or in any combination.

The interface circuitry 730 may be a controller hub configured to control the input and output (I/O) data paths of the network node 120. Such I/O data paths may include data paths for exchanging signals over a network. The interface circuitry 730 may be implemented as a unitary physical component, or as a plurality of physical components that are contiguously or separately arranged, any of which may be communicatively coupled to any other or may communicate with any other via the processing circuitry 710. For example, the interface circuitry 730 may comprise a transmitter 732 configured to send wireless communication signals and a receiver 734 configured to receive wireless communication signals.

The network node 120 may be configured (e.g., by the processing circuitry 710) to perform the method 300 described above.

Still other embodiments include a control program 740 comprising instructions that, when executed on processing circuitry 710 of a network node 120, cause the network node 120 to carry out the method 300 described above.

Yet other embodiments include a carrier containing the control program 740. The carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Although the various communication devices described herein may include the illustrated combination of hardware components, other embodiments may comprise computing and/or communication hardware with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions, and methods disclosed herein. Further, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, the devices described herein may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware. In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless communication network generally.

Claims

CLAIMS What is claimed is:

1 . A method (200), implemented by a User Equipment, UE (110), the method comprising: transmitting (220), to a network node (120) of a wireless communication network (100), a connection request for model-related traffic, the connection request comprising a request: for the wireless communication network (100) to deliver a model to the UE (110); or for the UE (110) to deliver model training data collected by the UE (110) to a model training node.

2. The method of claim 1 , further comprising exchanging, with the network node (120), a priority identifier that is based on: a random access resource; and/or a 5G Quality of Service Identifier, 5QI; and/or a Single Network Slice Selection Assistance Information, S-NSSAI.

3. The method of claim 2, wherein the priority identifier comprises an establishment cause indicating a reason for requesting the connection, the establishment cause being comprised in a MSG3 or MSGA random access message of a random access procedure.

4. The method of any one of claims 1-3, wherein the connection request comprises: an initial connection setup request; or a connection resume request; or a handover request; or a Quality of Service, QoS, flow setup request.

5. The method of any one of claims 1-4, wherein: the request is for the network (100) to deliver the model to the UE (110); and transmitting the connection request is responsive to the UE leaving an area in which the model is valid.

6. The method of any one of claims 1-4, wherein transmitting the connection request is responsive to the UE leaving an area in which the access request would not have been allowed.

7. The method of any one of claims 1-4, wherein: the request is for the network (100) to deliver the model to the UE (110); and transmitting the connection request is responsive to validity of the model expiring.

8. The method of any one of claims 1-4, wherein: the request is for the network (100) to deliver the model to the UE (110); and transmitting the connection request is responsive to more than a threshold amount of time elapsing since the UE (110) received the model.

9. The method of any one of claims 1-4, wherein: the request is for the network (100) to deliver the model to the UE (110); and transmitting the connection request is responsive to a performance metric of the model being below a threshold.

10. The method of any one of claims 1-4, wherein: the request is for the network (100) to deliver the model to the UE (110); and transmitting the connection request is responsive to the model executing for more than a threshold amount of time.

11 . The method of any one of claims 1-4, wherein: the request is for the UE (100) to deliver the model training data to the model training node; and transmitting the connection request is responsive to exhausting memory allocated in the UE (110) for storing the model training data.

12. The method of any one of claims 1-4, wherein: the request is for the UE (100) to deliver the model training data to the model training node; and transmitting the connection request is responsive to more than a threshold amount of time elapsing since a previous training data collection occurred.

13. The method of any one of claims 1-4, wherein: the request is for the UE (100) to deliver the model training data to the model training node; and transmitting the connection request is responsive to the model training data having been stored at the UE (110) for more than a threshold amount of time.

14. The method of any one of claims 1-4, wherein: the request is for the UE (100) to deliver the model training data to the model training node; and transmitting the connection request is responsive to receiving a request from the network node (120) for the training data.

15. A User Equipment, UE (110), configured to: transmit, to a network node (120) of a wireless communication network (100), a connection request for model-related traffic, the connection request comprising a request: for the wireless communication network (100) to deliver a model to the UE (110); or for the UE (110) to deliver model training data collected by the UE (110) to a model training node.

16. The UE of the preceding claim, further configured to perform the method of any one of claims 2-14.

17. A User Equipment, UE (110), comprising: interface circuitry (630) and processing circuitry (610) communicatively connected to the interface circuitry (630), wherein the processing circuitry (610) is configured to: transmit, to a network node (120) of a wireless communication network (100) via the interface circuitry (630), a connection request for model-related traffic, the connection request comprising a request: for the wireless communication network (100) to deliver a model to the UE (110); or for the UE (110) to deliver model training data collected by the UE (110) to a model training node.

18. The UE of the preceding claim, wherein the processing circuitry (610) is further configured to perform the method of any one of claims 2-14.

19. A computer program, comprising instructions which, when executed on processing circuitry (610) of a User Equipment, UE (110), cause the processing circuitry (610) to carry out the method according to any one of claims 1-14.

20. A method (300), implemented by a network node (120) of a wireless communication network (100), the method comprising: receiving (310), from a User Equipment (110), a connection request for model-related traffic, the connection request comprising a request: for the wireless communication network (100) to deliver a model to the UE (110); or for the UE (110) to deliver model training data collected by the UE (110) to a model training node; and selecting (320) between approving or denying the connection request based on the model-related traffic.

21. The method of claim 20, further comprising exchanging, with the UE (110), a priority identifier that is based on: a random access resource; and/or a 5G Quality of Service Identifier, 5QI; and/or a Single Network Slice Selection Assistance Information, S-NSSAI.

22. The method of claim 21 , wherein the priority identifier comprises an establishment cause indicating a reason for requesting the connection, the establishment cause being comprised in a MSG3 or MSGA random access message of a random access procedure.

23. The method of any one of claims 20-22, wherein the connection request comprises: an initial connection setup request; or a connection resume request; or a handover request; or a Quality of Service, QoS, flow setup request.

24. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to the network load being above a load threshold.

25. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to: the model-related traffic having a QoS requirement that is lower than a QoS threshold; and the network load being above a load threshold.

26. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to: the model-related traffic being of a size that is larger than a size threshold; and the network load being above a load threshold.

27. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to: the model-related traffic being associated with a low priority function; and the network load being above a load threshold.

28. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises denying the connection request responsive to: the model-related traffic being associated with a low priority model; and the network load being above a load threshold.

29. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to the network load being below a load threshold.

30. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to: the model-related traffic having a QoS requirement that is higher than a QoS threshold; and the network load being above a load threshold.

31 . The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to: the model-related traffic being of a size that is smaller than a size threshold; and the network load being above a load threshold.

32. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to: the model-related traffic being associated with a high priority function; and the network load being above a load threshold.

33. The method of any one of claims 20-23, wherein selecting between approving or denying the connection request is further based on network load and comprises approving the connection request responsive to: the model-related traffic being associated with a high priority model; and the network load being above a load threshold.

34. The method of any one of claims 20-23 or 29-33, further comprising preempting an already established connection to free resources for the requested connection.

35. A network node (120) configured to: receive, from a User Equipment (110), a connection request for model-related traffic, the connection request comprising a request: for a wireless communication network (100) to deliver a model to the UE (110); or for the UE (110) to deliver model training data collected by the UE (110) to a model training node; and select between approving or denying the connection request based on the model-related traffic.

36. The network node of the preceding claim, further configured to perform the method of any one of claims 21-34.

37. A network node (120) comprising: interface circuitry (730) and processing circuitry (710) communicatively coupled to the interface circuitry (730), wherein the processing circuitry (710) is configured to: receive, from a User Equipment (110) via the interface circuitry (710), a connection request for model-related traffic, the connection request comprising a request: for a wireless communication network (100) to deliver a model to the UE (110); or for the UE (110) to deliver model training data collected by the UE (110) to a model training node; and select between approving or denying the connection request based on the model-related traffic.

38. The network node of the preceding claim, wherein the processing circuitry (710) is further configured to perform the method of any one of claims 21-34.

39. A computer program, comprising instructions which, when executed on processing circuitry (710) of a network node (120) cause the processing circuitry (710) to carry out the method according to any one of claims 20-34.

40. A carrier containing the computer program of claim 19 or 39, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.