[go: up one dir, main page]

WO2024028370A1 - Déploiement et mise à jour de modèles d'apprentissage automatique dans un réseau d'accès radio - Google Patents

Déploiement et mise à jour de modèles d'apprentissage automatique dans un réseau d'accès radio Download PDF

Info

Publication number
WO2024028370A1
WO2024028370A1 PCT/EP2023/071365 EP2023071365W WO2024028370A1 WO 2024028370 A1 WO2024028370 A1 WO 2024028370A1 EP 2023071365 W EP2023071365 W EP 2023071365W WO 2024028370 A1 WO2024028370 A1 WO 2024028370A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
information
message
network node
opaque
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2023/071365
Other languages
English (en)
Inventor
Luca LUNARDI
Angelo Centonza
Germán BASSI
Pablo SOLDATI
Philipp BRUHN
Ioanna Pappa
Panagiotis Saltsidis
Vengatanathan KRISHNAMOORTHI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2024028370A1 publication Critical patent/WO2024028370A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0686—Additional information in the notification, e.g. enhancement of specific meta-data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition

Definitions

  • [001] Disclosed are embodiments related to the deployment and updating of machine learning (ML) models in a radio access network (RAN).
  • ML machine learning
  • RAN radio access network
  • FIG. 1 illustrates the current 5G RAN (a. k.a., the Next Generation RAN (NG-RAN)) architecture.
  • 5G RAN a. k.a., the Next Generation RAN (NG-RAN)
  • the NG-RAN architecture is described in 3GPP Technical Specification (TS) 38.401 v17.0.0.
  • the NG-RAN consists of a set of base stations (denoted "gNBs”) connected to a 5G core network (5GC) through an NG interface.
  • the gNBs can be interconnected through an Xn interface.
  • a gNB may consist of a gNB central unit (gNB-CU) and one or more gNB distributed units (gNB-DU(s)).
  • gNB-CU and a gNB-DU are connected via an F1 interface.
  • One gNB-DU is connected to only one gNB-CU.
  • the NG, Xn and F1 interfaces are logical interfaces.
  • a gNB-CU may comprise a gNB-CU control plane (CP) function (gNB-CU-CP) and a gNB-CU user plane (UP) function (gNB-CU-UP).
  • CP gNB-CU control plane
  • TR 37.817 The 3GPP Technical Report (TR) 37.817 V17.0.0 (“TR 37.817”) has been produced as outcome of the Study Item (SI) “Enhancement for Data Collection for NR and EN-DC” defined in 3GPP Technical Document (Tdoc) No. RP-201620.
  • SI Study Item
  • Tdoc 3GPP Technical Document
  • the study item aimed to study the functional framework for RAN intelligence enabled by further enhancement of data collection through use cases, examples, etc., and identify the potential standardization impacts on current NG-RAN nodes and interfaces.
  • TR 37.817 identifies the following high-level principles that should be applied for Al-enabled RAN intelligence:
  • the study focuses on AI/ML functionality and corresponding types of inputs/outputs.
  • the input/output and the location of the Model Training and Model Inference function should be studied case by case.
  • the study focuses on the analysis of data needed at the Model Training function from Data Collection, while the aspects of how the Model Training function uses inputs to train a model are out of RAN3 scope.
  • the study focuses on the analysis of data needed at the Model Inference function from Data Collection, while the aspects of how the Model Inference function uses inputs to derive outputs are out of RAN3 scope.
  • AI/ML functionality resides within the current RAN architecture, depends on deployment and on the specific use cases.
  • the Model Training and Model Inference functions should be able to request, if needed, specific information to be used to train or execute the AI/ML algorithm and to avoid reception of unnecessary information.
  • specific information to be used to train or execute the AI/ML algorithm and to avoid reception of unnecessary information.
  • the nature of such information depends on the use case and on the AI/ML algorithm.
  • the Model Inference function should signal the outputs of the model only to nodes that have explicitly requested them (e.g. via subscription), or nodes that take actions based on the output from Model Inference.
  • An AI/ML model used in a Model Inference function has to be initially trained, validated and tested by the Model Training function before deployment.
  • NG-RAN SA is prioritized; EN-DC and MR-DC are down-prioritized, but not precluded from Rel.18.
  • Radio Access Network Intelligence
  • FIG. 2 illustrates the Functional Framework for RAN Intelligence.
  • the framework includes the following functions: 1) a data collection function; 2) a model training function; 3) a model inference function; and 4) an actor function, or Actor.
  • the data collection function provides training data (e.g., a set of training data samples - i.e., one or more training data samples) to the model training function.
  • Training data is data that is used by the model training function to train a model (e.g., a neural network or other model).
  • a model e.g. a neural network
  • parameters e.g., neural network weights
  • the function approximated by the model is the Q-function, which assigns a value to a state-action pair.
  • the Q-function (hence the ML model) determine the behavior (or policy) of the RL agent.
  • the data collection function also provides inference data to the model inference function, which uses the inference data to produce an output (a.k.a., an inference)
  • ML model specific data preparation may also be carried out in the data collection function.
  • Examples of interference and training data may include measurements from user equipments (UEs) or different network entities, feedback from the Actor, and output from the model inference function.
  • the model training function performs the ML model training, validation, and testing which may generate model performance metrics as part of the model testing procedure.
  • the model training function is also responsible for data preparation (e.g. data pre-processing and cleaning, formatting, and transformation) based on training data delivered by a data collection function, if required.
  • the model training function deploys a trained, validated and tested model (e.g., a model that parameterizes or approximates at least one of a policy function, a value function and a Q-function in a deep reinforcement learning environment) to the model inference function or delivers an updated model to the model inference function.
  • the model inference function provides model inference output (e.g. predictions or decisions).
  • the model inference function may provide model performance feedback to the model training function when applicable.
  • the model inference function is also responsible for data preparation (e.g. data pre-processing and cleaning, formatting, and transformation) based on inference data delivered by a data collection function, if required.
  • the model inference function may provide model performance feedback information to the model training function, which uses this feedback information for monitoring the performance of the model.
  • the actor is a function that receives the output from the model inference function and triggers or performs corresponding actions.
  • the Actor may trigger actions directed to other entities or to itself.
  • the actions may generate feedback information, provided to the data collection function, that may be needed to derive training or inference data.
  • TR 37.817 states:
  • AI/ML Model Training is located in the 0AM and AI/ML Model Inference is located in the gNB [5G base station],
  • AI/ML Model Training and AI/ML Model Inference are both located in the gNB.
  • gNB is also allowed to continue model training based on model trained in the 0AM.
  • CU-DU split architecture the following solutions are possible:
  • AI/ML Model Training is located in the 0AM and AI/ML Model Inference is located in the gNB-CU.
  • AI/ML Model Training and Model Inference are both located in the gNB-CU.
  • TR 37.817 states:
  • the AI/ML Model Training function is deployed in 0AM, while the model inference function resides within the RAN node.
  • Both the AI/ML Model Training function and the AI/ML Model Inference function reside within the RAN node.
  • AI/ML Model Training is located in CU-CP or 0AM and AI/ML Model Inference function is located in CU-CP. Note: gNB is also allowed to continue model training based on model trained in the 0 AM.
  • TR 37.817 states:
  • AI/ML Model Training is located in the 0AM and AI/ML Model Inference is located in the gNB.
  • AI/ML Model Training and AI/ML Model Inference are both located in the gNB.
  • AI/ML Model Training is located in the 0AM and AI/ML Model Inference is located in the gNB-CU.
  • AI/ML Model Training and Model Inference are both located in the gNB-CU.
  • gNB is also allowed to continue model training based on model trained in the 0AM.
  • Tdoc R3-215244 proposes to introduce a model management function in the Functional Framework for RAN Intelligence, as shown in FIG. 3.
  • Tdoc R3-215244 states: Model deployment/update should be decided by model management instead of model training.
  • the model management may also host a model repository.
  • the model deployment/update should be performed by model management.
  • Model performance monitoring is a key function to assist and control model inference.
  • the model performance feedback from model inference should be first sent to model management. If the performance is not ideal, the model management may decide to fallback to traditional algorithm or change/update the model.
  • the model training should be also controlled by model management.
  • the model management function may be taken by either 0AM or CU or other network entities depending on the use cases. Clearly defining a model management function is useful for future signalling design and analysis.
  • Proposal 1 Introduce a model management function into AI/ML framework [as shown in FIG. 3],
  • Model management function supports following roles: I) Requesting model training and receiving the model training result; II) Model deployment/updates for inference, ill) Model performance monitoring, including receiving performance feedback from model inference and taking necessary action, e.g. keep the model, fallback to traditional algorithm, change or update the model, iv) Model storage.
  • the main objective of model training is to produce a model (e.g., neural network that parameterizes or approximates at least one of a policy function, a value function and a Q -function) that can generalize to conditions and situations not directly experienced in the training data (i.e., a model that performs well when used with inference data that differs from the training data used in the training process).
  • a model e.g., neural network that parameterizes or approximates at least one of a policy function, a value function and a Q -function
  • This process is also known as a training process.
  • the rollout worker uses the received model to interact with an external environment by selecting actions and applying the actions to the environment.
  • the rollout worker can collect experience samples that can be used for further training and improving the model.
  • an experience sample is a tuple that comprises: i) an observation (e.g., state vector) for time step t (denoted St), ii) an action (At) selected based on St, ill) an observation for time step t+1 (denoted St+1), and iv) a reward value Rt based on St and St+1 .
  • Some techniques provide a shared storage memory, also known as “replay buffer” or “experience buffer,” in which the rollout workers store the experience samples (e.g., at each time step, the rollout worker generates and stores an experience in the replay buffer).
  • the Model Trainer function can then filter experiences from the replay buffer to train/update the model (e.g., a new set of weights of a neural network), which is then provided to the distributed rollout workers.
  • Parallel and distributed experience sample collection allows the evaluation of multiple versions of a model in parallel and to quickly produce a new model. It also allows for improved diversity in the collected information, as different rollout workers can be tasked to test the model against different versions of the environment. This allows improved quality of the collected experiences, which in turns enables: producing a model that better generalizes against conditions (e.g., events) unseen during the training process, improving the speed of learning because updates of the model can be provided more frequently due to the high throughput of the training data generation, and improving learning efficiency (i.e., the improved data diversity provided by parallel and distributed rollout workers enables production of a better model for a given amount of experience samples compared to the case where a single rollout worker is used). Using these techniques in a RAN could achieve a performance that otherwise would not be possible to achieve.
  • This issue can be addressed in a proprietary way, e.g., by extending an open interface with private Information Elements (lEs) that can only be understood (encoded/decoded) by a network node which is aware of these proprietary extensions.
  • LEs Information Elements
  • a typical way to represent a piece of information as proprietary over open standardized interfaces is to encode the associated IE as an OCTET STRING.
  • OCTET STRING over 3GPP interfaces is seen as transparent payload (similar to an executable software package) and can be used for carrying ML models and associated information not to be revealed.
  • Another problem similar to the one described above is that, according to specifications, if a network node hosting an ML model inference function decides to update such model, there are no means to let other nodes understand that the ML model has changed. Namely, even in a simplified scenario where in a network a single ML model has been deployed, different nodes in the network would not understand that the performance impact of the model has changed due to the updating of the model. This, again, implies that it is not possible to derive a cause-effect rule by which the model outputs can be used with predictable performance impacts.
  • the ML model might be an obfuscated “black box” which is only accessible through an Application Program Interface (API).
  • API Application Program Interface
  • This is particularly desirable for developers of ML models, which might want to protect the added value of their products as well as prevent sensitive information leakage from the datasets used to train the ML models.
  • the API needs to be known by the network node in order to use the ML model, the network node's software needs to be updated each time a new ML model functionality that changes the API is developed.
  • a method for deploying and/or updating a model includes sending or receiving a message comprising one or more of the following: i) opaque information comprising a software package implementing the model to be deployed or updated or ii) non-opaque information comprising property information indicating one or more properties of the model.
  • a computer program comprising instructions which when executed by processing circuitry of a network node causes the network node to perform any of the methods disclosed herein
  • a carrier containing the computer program wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium
  • a network node that is configured to perform the methods disclosed herein.
  • the network node may include memory and processing circuitry coupled to the memory.
  • An advantage of the embodiments disclosed herein is that they avoid explicitly revealing properties of the ML model that should not be disclosed, while exposing details of the model that are needed to make the interaction amongst nodes participating in the procedures associated to the model (e.g., nodes that provide inputs or feedback information) work. For example, non-opaque information such as outputs generated by the model, allow the node hosting the model to know that such outputs might need to be signaled over open interfaces. Similarly, information about the inputs needed by the model allows the node hosting the model to request over open interfaces the input information needed to run the model. Furthermore, the embodiments allow the deployment and update of ML models as “black boxes” while providing the necessary information (e.g., API structure, inputs/outputs) to use them successfully.
  • FIG. 1 illustrates the current 5G RAN (a.k.a., the Next Generation RAN (NG-RAN)) architecture
  • FIG. 2 illustrates a Functional Framework for RAN Intelligence.
  • FIG. 3 illustrates the introduction of a model management function in the Functional Framework for RAN Intelligence.
  • FIG. 4 is a message flow diagram according to an embodiment
  • FIG. 5 is a message flow diagram according to an embodiment.
  • FIG. 6 is a message flow diagram according to an embodiment.
  • FIG. 7 is a message flow diagram according to an embodiment.
  • FIG. 8 is a message flow diagram according to an embodiment.
  • FIG. 9 is a flowchart illustrating a process according to an embodiment.
  • FIG. 10 is a block diagram of a network node according to an embodiment.
  • Transparent information is data of a data type whose data structure is defined in an interface.
  • Specified information is information that is visible, i.e. , it is specified, over the signaling interface through which the information travels, i.e., an information whose semantic meaning is known (or specified) for the interface carrying the information.
  • a node terminating the interface and receiving such information is able to decode it simply by means of implementing the interface standardized design.
  • Transparent information is synonymous with “specified information,” “visible information,'' “non-opaque information,” and “information in non-opaque format '''
  • Opaque information is data of an opaque data type (e.g., OCTET STRING), where an opaque data type is a data type whose data structure is not defined in the interface. That is, opaque information is information travelling across an interface whose meaning is not openly specified. This type of information may also be referred to as information not visible to the interface. Any node terminating the interface and receiving such type of information over the interface is able to decode the information only if it knows, by proprietary means, how such decoding should take place.
  • An example of implementation of opaque information in a 3GPP interface e.g., NGAP, or XnAP, or F1AP
  • IE Information Element
  • the IE may be used to convey content (e.g., an XML file, a serialized structured data (e.g., with Google Protocol Buffer), a string of bits) whose semantic meaning is not specified for the interface.
  • Opaque information may be obtained after one or more security techniques (such as data encryptions, data scrambling, signatures) are applied to an original (plain-text) information (e.g., the original ML model to be deployed).
  • Opaque information is synonymous with “unspecified information,” “information in opaque format,” “nonvisible information,” or “obscure information.”
  • a “network node” can be a node in a radio access network (RAN), an 0AM, a Core Network node, an 0AM, an SMO, a Network Management System (NMS), a Non-Real Time RAN Intelligent Controller (Non-RT RIC), a Real-Time RAN Intelligent Controller (RT-RIC), a gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, lAB-node, lAB-donor DU, lAB-donor-CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, O-eNB, a UE.
  • RAN radio access network
  • NMS Network Management System
  • NMS Non-Real Time RAN Intelligent Controller
  • a network node may be a physical node or a function or logical entity of any kind, e.g. a software entity implemented in a data center or a cloud, e.g. using one or more virtual machines, and two network nodes may well be implemented as logical software entities in the same data center or cloud.
  • a “RAN node” is a node or entity in a radio access network (RAN), such as a gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, lAB-node, lAB- donor DU, lAB-donor-CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, or O-eNB
  • RAN radio access network
  • a function, or entity of a RAN node is to be intended as one of the functional entities comprised in a RAN node.
  • a RAN node in split deployment comprises different functions or entities.
  • a gNB comprising a gNB-CU, one or more gNB-DU, one or more gNB-CU-CP.
  • model training, model optimizing, model optimization, model updating are herein used interchangeably with the same meaning unless explicitly specified otherwise.
  • model changing, modify or similar are herein used interchangeably with the same meaning unless explicitly specified otherwise.
  • they refer to the fact that the type, structure, parameters, connectivity of a model may have changed compared to a previous format/configuration of the model.
  • Al model ML model
  • AI/ML model AIML model
  • Data collection refers to a process of collecting data for the purpose of model training, data analytics, and/or inference.
  • AI/ML model types or learning problems/setting e.g. supervised learning, unsupervised learning, reinforcement learning, hybrid learning, centralized learning, federated learning, distributed learning, .
  • AI/ML algorithms may include supervised learning algorithms, deep learning algorithms, reinforcement learning type of algorithms (such as DQN, A2C, A3C, etc.), contextual multi-armed bandit algorithms, autoregression algorithms, etc., or combinations thereof.
  • Such algorithms may exploit functional approximation models, hereafter referred to as AI/ML models, such as neural networks (e.g. feedforward neural networks, deep neural networks, recurrent neural networks, convolutional neural networks, etc ).
  • reinforcement learning algorithms may include deep reinforcement learning (such as deep Q-network (DQN), proximal policy optimization (PPO), double Q- learning), actor-critic algorithms (such as Advantage actor-critic algorithms, e g. A2C or A3C, actor-critic with experience replay, etc), policy gradient algorithms, off-policy learning algorithms, etc.
  • DQN deep Q-network
  • PPO proximal policy optimization
  • double Q- learning double Q- learning
  • actor-critic algorithms such as Advantage actor-critic algorithms, e g. A2C or A3C, actor-critic with experience replay, etc
  • policy gradient algorithms e g. A2C or A3C, actor-critic with experience replay, etc.
  • the network nodes described herein can be directly connected (i.e., with a signaling connection between them) or indirectly connected (i.e., with a signaling connection traversing intermediate network nodes between them, relaying the signaling information exchanged between them).
  • transmitting a message to an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e , one or more other nodes are used to relay the message from the source node to the intended recipient).
  • receiving a message from a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node).
  • This disclosure describes solutions to deploy and/or update ML models in a RAN node (e.g., gNB, gNB-DU, gNB-CU-CP), enabling the possibility of differentiating operations concerning ML models signaled as opaque information (e.g., as OCTET STRING) or as transparent information.
  • a RAN node e.g., gNB, gNB-DU, gNB-CU-CP
  • the RAN node where the ML models are deployed or updated is mapped to the ML model inference function within the Functional Framework for RAN Intelligence defined in 3GPP TR 37.817.
  • the process includes sending to a network node (e.g. RAN node) a first message related to the deployment or updating of an ML model, wherein the first message includes opaque information for the ML model.
  • the opaque information may comprise a software package (i.e. , one or more software programs or applications) which includes the ML model.
  • the first message also includes transparent information for the ML model.
  • the transparent information may comprises parameters or characteristics of the ML model needed to use it properly.
  • the process includes sending a second message to the network node, wherein the second message comprises the transparent information, but not the opaque information.
  • a first network node e.g., an 0AM node or a CN node or a RAN node
  • a second network node sends to a second network node the ML model itself and additional information associated to the ML model.
  • the ML model is sent in an unspecified format (i.e., is sent as opaque information), where the whole of the model or at least parts of it are not specified. Namely, decoding of part or all of the model is only possible to an entity that is aware of how the model was encoded in the first place.
  • Additional information associated with the ML model can be: 1) sent as opaque information (e.g., OCTET STRING); 2) sent as transparent information; or 3) not sent at all (e.g., hardcoded, e.g. detailed in a technical specification, or hardcoded in a RAN node, or configured by other systems).
  • Such additional information associated with the ML model could be signaled either together with the model (e.g., as part of the same message or procedure) or separately (e.g., with a separate message or procedure).
  • the ML model and additional information associated to the ML model could both be signaled as specified information.
  • the additional information associated to the ML model concerns characteristics (or properties) of the ML model, examples of which are described herein.
  • Embodiments for network nodes In a communication network, the following operations are executed to deploy or update an ML model in a RAN node (e.g. , a gNB, a gNB-CU or a gNB-DU).
  • a RAN node e.g. , a gNB, a gNB-CU or a gNB-DU.
  • (Operation 1) Determining that an ML model is to be deployed or is to be updated for a first network node (e.g., a RAN node).
  • the decisions concerning the deployment and/or the update can be taken by the same network node or by different network nodes (e.g., a second network node determining that deployment is needed, and a third network node determining that update is needed).
  • (Operation 2) Determining/obtaining a mapping of a first set of one or more properties of the ML model to the ML model itself and/or to a second set of one or more properties of the ML model.
  • the mapping/obtaining can be determined by only one network node (e.g., a second network node, that can be an Element Manager, or a third network node, that can be a Network Manager, or a RAN node), or more than one network node. The determination can be performed for the case of new deployment as well as for the case of an update.
  • a mapping/determining is determined from a Model ID to the ML model to be deployed/updated, so that a specific Model ID value is used to indicate a specific ML model that is deployed/updated.
  • the Model ID may uniquely identify the model within an PLMN or, in general, within a configured or preconfigured area scope, such as a Tracking Area, or the cells served by a RAN node.
  • the Model ID is also updated, still maintaining uniqueness within the preconfigured area.
  • the Model ID is kept unchanged, still maintaining uniqueness within the preconfigured area.
  • a mapping is determined from a Model ID to a combination of "Model vendor” and “Model version”.
  • the overall identifier may reflect the same uniqueness properties described above.
  • a mapping is determined from the combination of a Model ID and a model version to the ML model to be deployed/updated, so that the combination of the specific Model ID and the model version is used to indicate a specific ML model that is deployed/updated.
  • the model version is changed every time the model is updated, while the Model ID might stay fixed.
  • multiple ML models may be deployed and updated at a given network node.
  • more than one may apply to the same use case, namely more than one model may work with input information within a common superset (e.g., use case specific), produce outputs within a common superset (e.g., use case specific) and need feedback information within a common superset (e.g., use case specific).
  • a common superset e.g., use case specific
  • each of such models will be identified by different Model IDs. This will allow the network node hosting the deployed/updated models to label procedures and information relative to any of such specific models with the appropriate Model ID, so to let neighboring nodes receiving the information to understand that the information has been produced by means of using the model with the associated Model ID.
  • (Operation 3) Sending to a RAN node one or more messages to deploy or to update the ML model, the message(s) comprising one or more of the following: i) unspecified information for an ML model to be deployed or updated (e.g., the code constituting the model) or II) specified information for the ML model to be deployed or updated.
  • (Operation 4) Sending to a RAN node one or more messages comprising specified information comprising a mapping of a first set of one or more properties of the ML model to: a) the ML model itself and/or b) a second set of one or more properties of the ML model.
  • the first sending and the second sending can occur in the same message or in distinct messages.
  • the first sending and the second sending can be executed by the same network node (e.g., second network node) or by different nodes (e.g., the second network node - for example an Element Manager - executing the first sending, and the third network node - for example a Network Manager - executing the second sending).
  • Unspecified information of an ML model can comprise: i) an ML model and/or an ML algorithm, ii) properties of an ML model not to be openly revealed over the signaling interface (e.g., a second set of one or more properties of the ML model), ill) additional support software packages and/or libraries required to execute the ML model of ML algorithm at the RAN node, iv) security certificates and/or other tools for validating/authenticating ML models.
  • Specified information of an ML model can comprise one or more or a combination of: i) one or more properties of an ML model; II) a first set of one or more properties of an ML model mapped to a second set of one or more properties of the ML model, wherein the second set of properties is not included (in one example, a Model ID is mapped to a certain Model Vendor and a certain use case, and neither the Model Vendor, nor the use case are explicitly part of the non-opaque information, but can be derived from the Model ID); ill) a first set of one or more properties of an ML model encoding a second set of one or more properties of the ML model, where the encoding can be partially masked (in one example, a Model ID is encoded in a way that contains the Model Vendor and the Model Version; the Model Vendor and the Model Version can be visible or at least in part visible over the signaling interface via the Model ID (e.g., the least "X”
  • the non-opaque information comprises a Model ID, mapped (associated) to the use case for which the ML model is to be used.
  • a RAN node receiving the opaque information (comprising the ML model), the non-opaque information comprising the Model ID, and capable to map the Model ID to the corresponding use case, can determine how to use the ML model.
  • a RAN node receiving the same information but not capable to map the Model ID to the corresponding use case, can derive that the ML model is not usable.
  • the non-opaque information can comprise the use case (or a list of use cases) associated to the ML model.
  • the receiver would be able to understand that, e.g., the ML model being deployed is for "Network Energy Saving” or for "Load Balancing Optimization”. This information may be already sufficient to determine the set of inputs, outputs, and feedback information relevant to the model, assuming that such information have been specified on a per use case basis.
  • the RAN node may use the non-opaque information for determining an action to discard the opaque information containing the ML model.
  • the non-opaque Model ID contains a part (e.g., a number of bits) indicating a specific vendor and if the receiving node belongs to a different vendor, the information can be used to discard the opaque information consisting of the ML model.
  • the RAN node may use the non-opaque information for determining an action to use I retrain I further modify the ML model comprised in the opaque information.
  • the non-opaque information used could be the same of the previous example, e.g., a vendor index within the Model ID.
  • Model ID a property realizes an encoding of other property(ies); or example, the Model ID is a bit string of (X+Y) bits, where the first part of X most significant bits is an ML Model vendor identifier, the subsequent part of Y bits is the ML Model type identifier;
  • the Model ID is a bit string of (X+Y) bits, where the first X most significant bits correspond to the ML Model vendor identifier and the subsequent Y bits correspond to the ML Model type, while the last Z bits of the Model Type are all “1”;
  • bitmap where bits in different positions are associated to different operations (e.g., Lifecycle management operation) of the ML model; for example, if the bit at position “X” has value “1” it indicates that the operation in question is an update of an ML model; if the bit at position “Y” has value “1” it indicates that the ML model can be re-trained at RAN (otherwise, re-training at RAN is not allowed); if the bit at position “Z” has value “1” it indicates that the RAN node can upload a re-trained ML model to 0AM; and/or
  • operations e.g., Lifecycle management operation
  • bitmap where bits at different positions are associated to different use cases supported by the ML model; for example, if the bit at position “X” has value “1” it indicates that the ML model is for “Network Energy Saving” use case, if the bit at position “Y” has value “1” it indicates that the ML model is for “Load Balancing Optimization” use case.
  • the content of the unspecified (opaque) information and the specified (non-opaque) information can vary between the case of ML Model deployment and the case of ML Model update. This is because, apart from the part concerning the ML model itself, which is expected to change between “deployment” and “update”, also some properties of the ML model can change, e.g., the Model Version or the Model type, or the mapping between nonopaque information and opaque information can change.
  • Model ID the means to provide the mapping
  • the value of the Model ID used for model deployment and the value of the Model ID used for model update are different, or the value of the Model ID used for model deployment and the value of the Model ID used for model update are the same, but the mapping is different.
  • the second network node (or the third network node) can send to the RAN node where the ML model was deployed, the new mapping, and the network node (second or third network node) can also send an indication to indicate that the (new) model replaces the previous one.
  • the Model ID may represent a model deployed by the node hosting the model training function, while the Model Version may represent the version of the model initially deployed, where version number is increased every time the model is updated.
  • the node that performs a model update (e.g. , model retraining) may generate a version number for the model identified by the Model ID.
  • the node responsible for the update may signal the model ID and new version number to other nodes involved in the procedures concerning the ML model (e.g., node hosting the Model Training Function, nodes receiving model outputs). This guarantees that all nodes involved in the ML processes are aware that the model has been updated and that new outputs and new performance impacts may be experienced.
  • the node hosting the model training function may deploy to the node hosting the model inference function a model with a new model ID.
  • the node hosting the model training function may include information stating that the new model is a replacement for an already deployed model with a different model ID. The receiving node would therefore deduce that the previously deployed model needs to be dismissed and replaced by the newly deployed model. Operations will resume using the newly deployed model with its associated model ID.
  • the property information for an ML model can be one or more or a combination of the following:
  • Identifiers of the ML Model such as a Model ID, a model index, an ML Model Reference that uniquely identifies an ML model and obtained combining a Model ID together with one or more other network identities, such as a PLMN ID, a Job ID, a Trace ID, a transport network address
  • a model identifier e.g. a Model ID can be realized in various ways, e.g., encoded as an INTEGER, an OCTET STRING, a BIT STRING, an ENUMERATED, a STRING, . .);
  • Type information indicating type of model e.g., linear regression, feedforward neural network, convolutional neural network, recurrent neural network, graph neural network, autoencoder, transformer, etc.;
  • Time stamps e.g., the production time of the ML model
  • Information indicating e.g., retrainability flags
  • the ML model is re-trainable by external systems, e.g., by other RAN nodes or another network node (e.g. implementing a Real-Time RIG), in case the training function resides at the RAN, or by the RAN in case the training function resides at the 0AM;
  • a RAN node is allowed to retrain, of 0AM is allowed to retrain, or a RAN node can trigger 0AM to retrain, or a RAN node can trigger another RAN node to retrain, or automatic/ re-training at the ML model inference host (e g., a RAN node) is supported, or re-training triggered or enabled by ML model inference host (e.g., a RAN node) is supported (the latter two cases are explained below);
  • t) Information indicating which Lifecycle Management operations e.g., validating, testing, monitoring, .... a network node/system, e.g., a RAN node (or the function in a RAN node) is allowed or not allowed or requested or configured to perform for the ML model;
  • use case can be: Network Energy Saving, Power Saving, Load Balancing Optimization, Mobility Optimization, Link Adaptation, QoS Optimization, QoE Optimization, Coverage and Capacity Optimization, MIMO Layer Optimization, CSI Prediction, Beam management, Positioning, Channel Coding, Reference Signal Enhancements, Interference Optimization,
  • w Information indicating an ML algorithm type (e.g., supervised learning, unsupervised learning, reinforcement learning);
  • x) Information indicating a type of ML training e.g. hybrid learning, centralized learning, federated learning, distributed learning
  • aa) Information indicating inputs of the ML model inference function in different variants, such as: a set of inputs the ML model needs, recommended inputs, minimum inputs for a workable ML model, minimum inputs required to achieve a certain level of performance, minimum set of inputs needed to produce a minimum set of outputs, mandatory inputs, optional inputs,;
  • the minimum set of inputs comprises inputs that are necessary to produce the minimum set of outputs (with a certain minimum performance, e.g., accuracy).
  • the performance is provided as part of the 0AM to RAN signaling, it may be specified per output for the case that only the minimum set of inputs is available/used and/or for the case that the superset of inputs is avail able/used.
  • the RAN node may need to run the ML model in "basic mode” using only the minimum set of inputs.
  • one or more computational requirements are provided as part of the 0AM to RAN signaling, they may be specified for the case that only the minimum set of inputs is avail able/used and/or for the case that the superset of inputs is available/used.
  • dd An indication/instruction of how to deal with missing inputs, i.e., whether to provide a substitute/replacement value for a missing input to the ML model inference function, e.g., the mean/median or another statistic of the missing input, or a marker/flag value, e.g., NULL, or -1 E308, or not provide any value for the missing input.
  • a substitute/replacement value for a missing input to the ML model inference function e.g., the mean/median or another statistic of the missing input, or a marker/flag value, e.g., NULL, or -1 E308, or not provide any value for the missing input.
  • the ML model inference host must not provide a substitute value to the ML model inference function
  • the ML model can be expected to replace missing inputs by itself or be able to cope with the missing input in another way;
  • ee Information indicating outputs generated by the ML model inference function, in different variants, such as: a set of output the ML model will generate, whether some outputs are mandatorily or optionally produced by the ML model (namely, out of the list of outputs specified to be produced by the model, an indication of the inputs that must or may be produced by the model), recommended outputs, minimum outputs, mandatory outputs, optional outputs, output generated when only a minimum set of input is provided, set of output available when the superset of input is available, recommended/suggested actions,;
  • the ML model is executed by a RAN node and updated or deployed by a second or a third network node, the required feedback information should be provided to the second or third network node, or to a network node hosting a data collection functionality for training data collection;
  • nn An indication of performance of the ML model provided to the first RAN node, such as accuracy and/or uncertainty/confidence (interval) with which model output predictions are generated. Possibly the accuracy and/or uncertainty/confidence interval may be provided per range of input values;
  • rr Information indicating the format with which one or more model output is produced, such as integer, floating-point number/value, Boolean, etc.
  • the output format may include the number of bytes or bits used to represent the output;
  • ss Information indicating the API protocol or architecture used to communicate with the ML model, e.g., representational state transfer (REST) architecture, remote procedural call (RPC) protocol, simple object access protocol (SOAP);
  • REST representational state transfer
  • RPC remote procedural call
  • SOAP simple object access protocol
  • tt Information indicating the API language used to communicate with the ML model, e g., JavaScript Object Notation (JSON), Extensible Markup Language (XML), HyperText Markup Language (HTML), plain text;
  • JSON JavaScript Object Notation
  • XML Extensible Markup Language
  • HTML HyperText Markup Language
  • uu Information indicating the way the data is structured in the API messages, e.g., the API schema;
  • An indication or a configuration of how training data should be collected for the AIML model may comprise one or more information related to. (the format to be used for training data samples, such as the type of information that should be aggregated to construct a training data sample. This may include the state (or input) used by the model inference function, the model inference output, an action determined using the model inference output (e.g., a change in one or more a network or user parameter value), one or more measurement associated to the model inference output (e.g., measurements of information predicted by the model inference, which could be carried out by one or more network node, one or mode UEs or combinations thereof));
  • the ML model is received as an unspecified payload (e.g., as a software package) comprising the ML model and that it is not specified how to decode the ML model or the unspecified payload as such
  • the node receiving the ML model may not be able to decode the ML model, but it can interact with the ML model (e.g., it could interact with the ML model via specific Application Program Interfaces (APIs) provided for this purpose, e.g., inference, re-training, etc ).
  • APIs Application Program Interfaces
  • the node also receives information about the one or more APIs to interact with the ML model.
  • the procedure to perform inference and re-training may be part of the procedures for such APIs.
  • the node will be instructed on how to carry out such procedures.
  • the signaling of information concerning the APIs may be part of the signaling used to deploy the ML model.
  • a node receiving the ML model may also receive an indication (in form of properties of the ML model) that the ML model is re-trained automatically by the ML software package. If this is the case, in one embodiment, the node receiving a trained ML model understands that the model re-training is triggered and carried out automatically by the ML software package. Moreover, the ML model execution/inference host cannot influence the re-training and it is unaware of the details. The re-training is fully controlled by the ML software package. The ML model is seen as a black box, which re-trains/updates itself.
  • Automatic re-training further implies that the inference data, which is assumed to be provided (by the inference host to the software package) as inputs via a specific API to receive outputs, comprises the training data.
  • the inference data comprises historical measurements of a metric (e.g., quantity) that is to be predicted by the ML model for a time in the future.
  • the inference data inherently comprises the ground truth of outputs (e.g., predictions) generated by the ML model at an earlier point.
  • the ML software package can use that data to re-train/update the ML model.
  • the inference host can understand that there has been an update of the ML model by means of a new Model ID (or version number). Note that if the inference data does not inherently comprise new training data, it may do so, e.g., based on instruction from the node providing (e.g., sending) the ML model or by definition in specifications.
  • inference data does not contain training data because training data includes information that is not needed to perform inference (e.g., ground truth, reward signals, etc).
  • the node receiving the ML model may receive an indication (again, in form of properties of the ML model) that the ML model re-training must be triggered or enabled by the ML model execution/i nference host by means of providing the required new training data through a separate re-training API, if needed.
  • the signaling must indicate what data is needed for the (re-)training (the same applies for inference).
  • the re-training is triggered or at least enabled by the execution/i nference host by providing (e.g., feeding) new training data, e.g., via the intended API, so the execution/inference host can decide if and when to retrain the ML model and can even influence the re-training (to a certain extent), because it can decide what training data to feed into the ML software package. In one example, it can decide to feed more training samples from input (or output) ranges where the ML model performance is worse or is of particular importance for the (overall) performance at or in the vicinity of the local node.
  • the inference host can trigger re-training based on instruction (e.g., configuration) from the node providing the ML model or even another node. It may trigger re-training, e.g., based on observed ML model performance degradation or system performance degradation when monitoring certain performance metrics, e.g., system KPI.
  • the ML software package Upon receiving new training data, e.g., via a specific API, the ML software package re- trains/updates the ML model internally, i.e., the details of the ML model remain hidden from the inference host. Similar to the above, the inference host can understand that the update of the ML model has been completed when receiving a new Model ID (or version).
  • the main difference between the automatic re-training case and this case is that, in this case, action from the inference host is needed to enable the re-training.
  • FIG. 4 illustrates a use case in which a RAN node 401 receives from a second network node 402 an optional configuration message m450 that comprises configuration information that maps a Model ID to particular model properties.
  • message m450 includes the Model ID and property information indicating the particular model properties.
  • the message may include an IE that comprises the Model ID and the property information and indicates that the property information is associated with the Model ID.
  • RAN node 401 stores in a storage unit the Model ID and the property information such that the Model ID is associated with (e.g., linked to) the property information so that the RAN node can later retrieve from the storage unit the property information using the Model ID as the search query.
  • RAN node 401 receives from a third network 403 node a deployment message m452 that comprises i) opaque information that comprises a software package (SP) implementing an ML model and ii) transparent information that comprises a Model ID (which in this example is the same Model ID as was included in configuration message m450).
  • the message may also include i) a use case indicator that provides indication of the use case for which the ML model is used (e g., “Network Energy Saving” or “Load Balancing Optimization”, or “Mobility Optimization”) and/or ii) additional property information (e.g., information indicating one or more inputs, one or more outputs, one or more feedbacks).
  • RAN node 401 uses the Model ID from deployment message m452 to retrieve from its storage unit the property information associated with the Model ID, if any. RAN node 401 then uses the retrieved property information (hereafter “model properties”), if any, and the model properties included in deployment message m452, if any, to execute the software package and/or provide feedback information pertaining to the ML model.
  • model properties the retrieved property information
  • deployment message m452 comprises the use case indicator
  • RAN node 401 uses the use case indicator to obtain model properties that are associated with the use case indicator, which model properties are for the ML model implemented by the software package.
  • the use case indicator is associated with (e.g., points to): a) the full list of inputs/outputs/feedback information the ML model needs; b) a standardized set of outputs that the ML model is expected to produce (the set of inputs may be left to implementation); c) a set of standardized inputs (the outputs may be left for implementation); and/or d) a set of standardized outputs conditionally present, i.e., expected only if a set of standardized input is provided.
  • a 3GPP standard can indicate a list of inputs, a list of outputs, and/or a list of feedbacks for a given use case indicator.
  • the inputs to the ML model include: a) UE location information (e.g., coordinates, serving cell ID, moving velocity) interpreted by gNB implementation when available; b) UE measurement report(s) (e.g., UE RSRP, RSRQ, SINR measurement, etc.), including cell level and beam level UE measurements; input from neighbouring RAN nodes (e.g., Current/Predicted energy efficiency, Current/Predicted resource status, and/or Current energy state (e g., active, high, low, inactive));
  • UE location information e.g., coordinates, serving cell ID, moving velocity
  • UE measurement report(s) e.g., UE RSRP, RSRQ, SINR measurement, etc.
  • input from neighbouring RAN nodes e.g., Current/Predicted energy efficiency, Current/Predicted resource status, and/or Current energy state (e g., active, high, low, inactive)
  • neighbouring RAN nodes e.
  • the feedback information for the ML model include: a) Resource status of neighbouring NG-RAN nodes; b) energy efficiency; c) UE performance affected by the energy saving action (e.g., handed-over UEs), including bitrate, packet loss, latency; and/or d) system KPIs (e.g., throughput, delay, RLF of current and neighbouring NG-RAN node).
  • the mapping can be expressed indicating that different sets of input I output I feedback can be used for one or more Use cases, e.g.: a first set of input maps to Use Case “A” and “B”; a second set of input maps to Use Case “C”; ...; an Nth set of input maps to Use Case “N”; a first set of output maps to Use Case “A” and “B”; a second set of input maps to Use Case “C”; a first set of feedback maps to Use Case ‘‘A” and “B”; and/or a second set of feedback maps to Use Case “C”.
  • RAN node 401 uses the model properties for the given use case plus the model properties from configuration message m450, if any, plus the model properties from deployment message m452, if any, to execute the software package and/or provide feedback.
  • the RAN node is able to determine a set of standardized inputs, outputs, and feedback information. Whether the ML model uses a reduced set of such inputs, outputs, and feedback (or additional input I output I feedback) is up to implementation. What is relevant for the example is that standardized inputs/outputs/feedback are known without signaling them explicitly.
  • FIG. 4 further shows that second network node 402 may send to RAN node 401 a second configuration message m454 that comprises configuration information that maps the Model ID to particular model properties.
  • RAN node 401 may either i) store in the storage unit the model properties from configuration message m454 so that these particular model properties and the particular property information included in configuration message m450 are both associated with the Model ID or ii) replace in the storage unit the particular property information from configuration message m450 with the particular property information from configuration message m454. In this way, second network node 402 can reconfigure RAN node 401.
  • third network node 403 may send a second deployment message m456 that comprises i) opaque information that comprises an updated software package implementing an updated version of the ML model and ii) transparent information that comprises a Model ID (which in this example is the same Model ID as was included in configuration messages m450 and m454).
  • RAN node 401 uses the Model ID from deployment message m456 to retrieve from its storage unit the particular property information that are associated with the Model ID and then uses the retrieved model properties (as well as model properties included in second deployment message m456, if any, and/or model properties derived from the use case indicator, if any, to execute the updated software package and/or provide feedback regarding the updated ML model.
  • FIG. 4 shows that second network node 402 is separate and distinct from third network node 403, in some embodiments they are the same network node.
  • FIG. 5 illustrates a use case in which a ML model is deployed as a software payload using a centralized resolving function (CRF) 506 (a.k.a., ML deployment resolver).
  • CRF centralized resolving function
  • third network node 403 transmits to RAN node 401 a deployment message m550 comprising opaque information comprising a software package that implements an ML model (deployment message m550 may be identical to deployment message m452 or m456).
  • the deployment message m550 includes a Model ID or includes sufficient information to enable RAN node 401 to derive a model ID (e.g. RAN node 401 may be able to obtain or derive the Model ID from the software package included in deployment message m550).
  • RAN node 401 After receiving deployment message m550, RAN node 401 extracts the software package included therein and associated information (e.g., Model ID), if any, that is transferred together with the software package. If the Model ID cannot be extracted from the message, then RAN Node derives a Model ID.
  • model properties e.g., a use case indicator
  • RAN node 401 uses the extracted/derived Model ID to obtain the necessary model properties by transmitting to CRF 506 a model property request message m552 that comprises the Model ID.
  • CRF 506 in response to receiving the model property request message m552 uses the Model ID included in the message to locate and retrieve a set of one or more model properties associated with the Model ID and transmits to RAN node 401 a response message m554 responsive to request message m552, where the response message m554 comprises the set of model properties (e.g., use case indicator, model input information, model output information, and/or model feedback information).
  • model properties e.g., use case indicator, model input information, model output information, and/or model feedback information.
  • FIG. 6 illustrates an example in which an ML model is requested by RAN node 401 (or other network node) after receiving a message comprising information pertaining to the ML model (e.g., the Model ID for the model).
  • RAN node receives message m650 and message m650 comprises information pertaining to the ML model (e.g., non-opaque information concerning the ML model).
  • non-opaque information can be: the ML model's Model ID, a combination of Model ID and Model version, a combination of Model ID and Model vendor, a Model vendor, an ML-based use case, an indication that use of ML in RAN is of interest, an indication that an ML model (without any specific indication of a model identifier) is available for the network node to be used.
  • RAN node 401 After receiving message m650, RAN node 401 determines to request a new or updated Model corresponding to the non-opaque information (e.g. the ML Model ID). Accordingly, RAN node 401 transmit a request message (a.k.a., query message) m652 to another network node 602 (e.g. the third network node or an ML deployment resolver) with at least part of the received non-opaque information (e.g. the ML Model ID).
  • a request message a.k.a., query message
  • another network node 602 e.g. the third network node or an ML deployment resolver
  • Network node 602 in response to receiving query message m652 uses information included in message m652 to obtain a software package that implements the ML model and then transmits to RAN node 401 a deployment message m654 that comprises opaque information comprising the software package.
  • Message m654 may further comprise ML model properties (in opaque format or non-opaque format).
  • FIG. 7 illustrates a successful ML model update example.
  • the node hosting the training function is an OAM 702
  • the node hosting the inference function which carries out the retraining, is RAN node 401 .
  • RAN node 401 sends to OAM 702 a model update message m750 to inform the OAM that the ML model signaled as an undefined payload (e.g., as an OCTET STRING) has been retrained.
  • Model update message m750 may also include one or more of the following:
  • Ranges of training data values used such as value ranges of predicted metrics and actual measurements for the same metrics at the time the prediction was assumed to be valid
  • Nodes/systems providing the training data used, e.g., training data collected from a selected number of cells or a selected group of UEs with specific characteristics.
  • a new Model ID identifying the model after re-training (if applicable) For example, if the RAN re-training changed the ML model and a new Model ID is/was required to be assigned to it.
  • the ML 1 software package may have updated the ML model internally, assigned a new Model ID and informed the execution/! nference host about the new Model ID.
  • the new ML model as an undefined payload (e.g., as an OCTET STRING).
  • message m750 includes the performance information mentioned above, then the 0AM assesses this information and responds to NG-RAN that it can use the re-trained model (i.e. , the 0AM 702 transmits to RAN node 401 a model update response message m752 comprising information indicating that RAN node 401 can use the re-trained model).
  • message m750 does not include the performance information mentioned above, then the OAM performs its own evaluation of the updated model, for example, by means of collecting system KPIs that may reveal how well the model in use is performing, and based on that responds to NG-RAN that it can use the retrained model.
  • the model performance can only be assessed for models that are active (e.g., in use in the network). If a model is inactive, the OAM may not receive any model performance indication/metric, however, the OAM may still be in charge of deciding whether the new model should be kept or discarded.
  • RAN node 401 After receiving model update response message m752, RAN node 401 provides model performance information to OAM after running the updated model by transmitting to the OAM model performance information message m754 comprising the model performance information.
  • FIG. 8 illustrates an unsuccessful ML model update example.
  • RAN node 401 sends to OAM 702 the model update message m750 as described above.
  • message m750 includes the performance information mentioned above, then the OAM assesses this information and responds to RAN node 401 that it rejects the retrained model with an appropriate cause (i.e., the OAM 702 transmits to RAN node 401 a model update reject message m852 comprising information indicating that the retrained model is rejected and, optionally, information indicating a reason why it was rejected).
  • the OAM 702 transmits to RAN node 401 a model update reject message m852 comprising information indicating that the retrained model is rejected and, optionally, information indicating a reason why it was rejected).
  • FIG. 9 is a flow chart illustrating a process 900, according to an embodiment, for deploying and/or updating a model.
  • Process 900 may begin in step s902.
  • Step s902 comprises sending or receiving a message comprising one or more of the following: opaque information comprising a software package implementing the model to be deployed or updated, or non-opaque information comprising property information indicating one or more properties of the model.
  • the message sent/received in steps s902 may be one of: message m450, message m452, message m454, message m456, message m550, message m552, message m554, message m650, message m652, message m654.
  • process 900 may be performed by network node 401 , network node 402, network node 403, network node 506 (a.k.a., CRF).
  • the message comprises both the opaque information and non-opaque information.
  • the message comprises the opaque information but not the non-opaque information.
  • the message comprises the non-opaque information but not the opaque information.
  • the property information comprises a model identifier (ID) for the model or information from which the network node can derive the model ID.
  • the property information further comprises additional property information
  • the process comprises receiving the message
  • the process further comprises storing the model ID and the additional property information such that the model ID can be used to locate and retrieve the additional property information.
  • the process further comprises, after storing the model ID and the additional property information, receiving a deployment message (e.g., message m452, m456, m550) comprising opaque information comprising a software package implementing the model to be deployed or updated; using the model ID to retrieve the additional property information; and using the addition property information to run the software package.
  • the method further comprises, before using the model ID to retrieve the additional property information, obtaining the model ID from the deployment message or deriving the model ID using information included in the deployment message.
  • the process comprises receiving the message containing the non-opaque information (e.g., the message is received by network node 401), and the process further includes transmitting to another network node (e.g., a CRF 506, network node 402, network node 403) a request message comprising the model ID; and receiving from the another network node a deployment message that is responsive to the request message and comprises the opaque information comprising a software package implementing the model to be deployed or updated.
  • another network node e.g., a CRF 506, network node 402, network node 403
  • the process comprises receiving the message containing the opaque information (e.g., the message is received by network node 401) and the process further includes obtaining a model ID from the message or deriving the model ID using information included in the message; and using the model ID to obtain property information for the model.
  • using the model ID to obtain property information for the model comprises: transmitting to another network node (e.g., network node 402, network node 403, CRF 506) a request message comprising the model ID; and receiving a response message transmitted by the another network node, the response message being responsive to the request message and comprising property information for the model.
  • FIG. 10 is a block diagram of network node 1000, according to some embodiments.
  • Network node 1000 can be used to implement any of the network node described herein, such as, for example, RAN node 401 , second network node 402, third network node 403, CRF 506.
  • network node 1000 may comprise: processing circuitry (PC) 1002, which may include one or more processors (P) 1055 (e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e.
  • processors e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like
  • ASIC application specific integrated circuit
  • FPGAs field
  • network node 1000 may be a distributed computing apparatus); at least one network interface 1048 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 1045 and a receiver (Rx) 1047 for enabling network node 1000 to transmit data to and receive data from other nodes connected to a network 110 (e.g., an Internet Protocol (IP) network) to which network interface 1048 is connected (physically or wirelessly) (e.g., network interface 1048 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 1000 to wirelessly transmit/receive data); and a storage unit (a.k.a., "data storage system”) 1008, which may include one or more non-volatile storage devices and/or one or more volatile storage devices.
  • IP Internet Protocol
  • a computer readable storage medium (CRSM) 1042 may be provided.
  • CRSM 1042 may store a computer program (CP) 1043 comprising computer readable instructions (CRI) 1044.
  • CP computer program
  • CRSM 1042 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like.
  • the CR1 1044 of computer program 1043 is configured such that when executed by PC 1002, the CRI causes network node 1000 to perform steps described herein (e.g., steps described herein with reference to the flow charts).
  • network node 1000 may be configured to perform steps described herein without the need for code. That is, for example, PC 1002 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.
  • transmitting a message to a device encompasses transmitting the message directly to the device or transmitting the message indirectly to the device (i.e., one or more nodes are used to relay the message from the source to the device).
  • receiving a message from a device encompasses receiving the message directly from the device or indirectly from the device (i.e., one or more nodes are used to relay the message from the device to the receiving node).
  • en-gNB A gNB acting as a secondary node in an EN-DC scenario i.e. in a DC scenario with an eNB as the master node and a gNB as the secondary node.
  • NG The interface between an NG-RAN and a 5GC.
  • RVQoE RAN Visible QoE S1 The interface between the RAN and the CN in LTE.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne également un procédé de déploiement et/ou de mise à jour d'un modèle. Le procédé consiste à envoyer ou recevoir un message comprenant un ou plusieurs des éléments suivants : des informations opaques comprenant un progiciel mettant en œuvre le modèle à déployer ou à mettre à jour, ou des informations non opaques comprenant des informations de propriétés indiquant une ou plusieurs propriétés du modèle.
PCT/EP2023/071365 2022-08-05 2023-08-02 Déploiement et mise à jour de modèles d'apprentissage automatique dans un réseau d'accès radio Ceased WO2024028370A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GR20220100649 2022-08-05
GR20220100649 2022-08-05

Publications (1)

Publication Number Publication Date
WO2024028370A1 true WO2024028370A1 (fr) 2024-02-08

Family

ID=87570073

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/071365 Ceased WO2024028370A1 (fr) 2022-08-05 2023-08-02 Déploiement et mise à jour de modèles d'apprentissage automatique dans un réseau d'accès radio

Country Status (1)

Country Link
WO (1) WO2024028370A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025208343A1 (fr) * 2024-04-02 2025-10-09 Nec Corporation Dispositifs et procédés de communication

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10803392B1 (en) * 2017-03-10 2020-10-13 Amazon Technologies, Inc Deploying machine learning-based models
WO2021136601A1 (fr) * 2020-01-03 2021-07-08 Huawei Technologies Co., Ltd. Entité de réseau pour déterminer un modèle pour analyser numériquement des données d'entrée
US20210337420A1 (en) * 2020-04-22 2021-10-28 Samsung Electronics Co., Ltd. Functional architecture and interface for non-real-time ran intelligent controller
WO2022013095A1 (fr) * 2020-07-13 2022-01-20 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'un dispositif sans fil permettant d'assurer une connexion à un réseau de communication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10803392B1 (en) * 2017-03-10 2020-10-13 Amazon Technologies, Inc Deploying machine learning-based models
WO2021136601A1 (fr) * 2020-01-03 2021-07-08 Huawei Technologies Co., Ltd. Entité de réseau pour déterminer un modèle pour analyser numériquement des données d'entrée
US20210337420A1 (en) * 2020-04-22 2021-10-28 Samsung Electronics Co., Ltd. Functional architecture and interface for non-real-time ran intelligent controller
WO2022013095A1 (fr) * 2020-07-13 2022-01-20 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'un dispositif sans fil permettant d'assurer une connexion à un réseau de communication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP TECHNICAL REPORT (TR) 37.817 V17.0.0 (''TR 37.817
3GPP TECHNICAL SPECIFICATION (TS) 38.401 V17.0.0
3GPP TR 37.817

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025208343A1 (fr) * 2024-04-02 2025-10-09 Nec Corporation Dispositifs et procédés de communication

Similar Documents

Publication Publication Date Title
US12388717B2 (en) Method and device for selecting service in wireless communication system
US20240205781A1 (en) User equipment trajectory-assisted handover
US11805022B2 (en) Method and device for providing network analytics information in wireless communication network
EP4160995A1 (fr) Procédé et dispositif de traitement de données
Lin Artificial intelligence in 3gpp 5g-advanced: A survey
CN118541956A (zh) 用于ai/ml通信的5g支持
CN109982391A (zh) 数据的处理方法及装置
WO2024097717A1 (fr) Analyse de données pour services de détection dans des réseaux cellulaires de prochaine génération
US20240414067A1 (en) Enhanced loading of machine learning models in wireless communications
AU2022381145B2 (en) Data collection method and communication apparatus
US20250055765A1 (en) Systems and methods to control aiml model re-training in communication networks
WO2024091862A1 (fr) Modèles d'intelligence artificielle/apprentissage automatique (ai/ml) pour déterminer la consommation d'énergie dans des instances de fonction de réseau virtuel
CN116368780A (zh) Mda报告请求、获取和上报
WO2024028370A1 (fr) Déploiement et mise à jour de modèles d'apprentissage automatique dans un réseau d'accès radio
US20250062967A1 (en) Network resource models and technologies for actions executed according to machine learning inference reports
US20240397362A1 (en) Enhanced performance measurements related to one-way uplink packet delay in wireless communications
WO2024220232A1 (fr) Intelligence et programmabilité de la fonction de gestion de la session et de la fonction du plan utilisateur
WO2024172911A9 (fr) Configuration pour entraînement d'apprentissage automatique
WO2025014819A1 (fr) Procédés et agencements pour un cadre d'applications de système
US20250071029A1 (en) Systems and methods for inter-node verification of aiml models
WO2024028368A1 (fr) Collecte efficace de données distribuées dans un ran
WO2024028182A1 (fr) Modèle d'apprentissage automatique dans un réseau d'accès radio
WO2024028183A1 (fr) Configuration de capacité d'apprentissage automatique dans un réseau d'accès radio
US20250293975A1 (en) Optimization of network routing for application performance
US20240154710A1 (en) Model update techniques in wireless communications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23753851

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23753851

Country of ref document: EP

Kind code of ref document: A1