Handling model ID in AI / ML operation in network

The method for managing AI/ML model and functionality identities in 3GPP 5G NR networks addresses the unclear allocation and management of model IDs by providing a framework for unique and efficient handling of model IDs, improving model life cycle management and transfer processes.

GB2634596APending Publication Date: 2025-04-16SAMSUNG ELECTRONICS CO LTD

Patent Information

Application Number
GB2024004540
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-05-12
Filing Date
2024-03-28
Publication Date
2025-04-16

AI Technical Summary

Technical Problem

The handling of model IDs in AI/ML operations within communication networks, particularly in 3GPP 5G NR networks, is unclear, leading to challenges in allocating, exchanging, and managing model IDs between user equipment (UE) and the network, which affects model life cycle management (LCM) and transfer/delivery processes.

Method used

A method for managing AI/ML model and functionality identities (MFIDs) is introduced, involving the transmission of information by the network to UEs for unique assignment of MFIDs, with coordination between the network and UE to ensure harmonized allocation and management of model IDs, including lists of allocated and available IDs, and support for different types such as global, dynamic, and local IDs.

Benefits of technology

This approach clarifies the allocation and management of model IDs, ensuring unique and efficient handling of AI/ML models across different network conditions and mobility scenarios, enhancing model life cycle management and transfer processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

There is disclosed a method for managing, in a network, one or more artificial intelligence and / or machine learning (AI / ML) model and / or functionality identities (MFIDs) for identifying one or more co
Need to check novelty before this filing date? Find Prior Art

Description

BACKGROUND Field Certain examples of the present disclosure provide one or more techniques for handling model Identification (ID) in Artificial Intelligence (Al) / Machine Learning (ML) operation in a communication network, for example a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) network. Description of the Related Art Herein, the following documents are referenced and the contents thereof are incorporated into the present disclosure: [1] 3GPP RP-213599 [2] 3GPP TS 38.331 [3] 3GPP TS 36.331 [4] 3GPPTS 38.413 [5] RAN2#121 Chairman notes [6] RAN2#121bis Chairman notes Various acronyms, abbreviations and definitions used in the present disclosure are defined at the end of this description. AI / ML is being used in a range of application domains across industry sectors. In mobile communications systems, conventional algorithms (e.g. speech recognition, image recognition, video processing) in mobile devices (e.g. smartphones, automotive, robots) are being increasingly replaced with AI / ML models to enable various applications. 3GPP Radio Access Network (RAN) working groups are studying AI / ML for NR Air interface and its use in a 3GPP system, for example to enhance mobility, User Equipment (UE) location, amongst other use cases [1], The 5G system can support various types of AI / ML operations, including the following three defined in 3GPPTS 22.261: • AI / ML operation splitting between AI / ML endpoints The AI / ML operation / model may be split into multiple parts, for example according to the current task and environment. The intention is to offload the computation-intensive, energy-intensive parts to network endpoints, and to leave the privacy-sensitive and delay-sensitive parts at the end device. The device executes the operation / model up to a specific part / layer and then sends the intermediate data to the network endpoint. The network endpoint executes the remaining parts / layers and feeds the inference results back to the device. • AI / ML model / data distribution and sharing over 5G system Multi-functional mobile terminals may need to switch an AI / ML model, for example in response to task and environment variations. An assumption of adaptive model selection is that the models to be selected are available for the mobile device. However, since AI / ML models are becoming increasingly diverse, and with the limited storage resource in a UE, not all candidate AI / ML models may be pre-loaded on-board. Online model distribution (i.e. new model downloading) may be needed, in which an AI / ML model can be distributed from a Network (NW) endpoint to the devices when they need it to adapt to the changed AI / ML tasks and environments. For this purpose, the model performance at the UE may need to be monitored constantly. • Distributed / Federated Learning over 5G system A cloud server may train a global model by aggregating local models partially-trained by each of a number of end devices (e.g. UEs). Within each training iteration, a UE performs the training based on a model downloaded from the Al server using local training data. Then the UE reports the interim training results to the cloud server, for example via 5G UL channels. The server aggregates the interim training results from the UEs and updates the global model. The updated global model is then distributed back to the UEs and the UEs can perform the training for the next iteration. An AI / ML model may be identified by a Model ID. The following are agreements on model ID in RAN2: RAN2#121 meeting: => RAN2 assumes that Model ID is unique “globally”, e.g. in order to manage test certification each retrained version need to be identified. RAN2#121bis-e meeting: => Model ID can be used to identify model or models for the following LCM purposes: model selection / activation / deactivation / switching (or identification, if that will be supported as a separate step). (e.g. for so called “model ID based LCM") => If model transfer / delivery is supported, model ID can be used for model transfer / delivery LCM purpose. => How to achieve globality of the Model ID is FFS. Initial discussion in RAN2: the following global unique model ID definition directions can be considered as a starting point: Direction 1: Pre-defined / hard-coded global unigue model ID Directions: Assigned global unique model ID via specific ID management node. Note: Other global unigue model ID definition is not precluded. Model ID structure, if any, is FFS The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present invention. SUMMARY It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein. The present invention is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the description and / or figures falling outside the scope of the claims are to be understood as examples useful for understanding the present invention. Other aspects, advantages and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates an exemplary method for managing, in a network, one or more AIML model and / or functionality identities (MFIDs) for identifying one or more corresponding AIML models and / or AIML functionalities; Figure 2 is a first signal flow diagram illustrating various exemplary operations relating to managing one or more MFIDs; Figure 3 is a second signal flow diagram illustrating further exemplary operations relating to managing one or more MFIDs; Figure 4 is a third signal flow diagram illustrating a yet further exemplary operation relating to managing one or more MFIDs; and Figure 5 is a block diagram of an exemplary network entity that may be used in certain examples of the present disclosure. DETAILED DESCRIPTION The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, as defined by the claims. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention. The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings. Detailed descriptions of techniques, structures, functions, operations or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present invention. The terms and words used herein are not limited to the bibliographical or standard meanings, but, are merely used to enable a clear and consistent understanding of the invention. Throughout the description and claims of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof. Throughout the description and claims of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects. Throughout the description and claims of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y. Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim described herein unless incompatible therewith. Certain examples of the present disclosure provide one or more techniques for handling model ID in AI / ML operation in a communication network, for example a 3GPP 5G NR network. However, the skilled person will appreciate that the present invention is not limited to this example, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards, including any existing or future releases of the same standards specification, for example 3GPP 5G and / or 6G. The functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in the same or any other suitable communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function or purpose within the network. For example, the functionality of a base station or the like (e.g. eNB, gNB, NB, RAN node, NG-RAN, access point, wireless point, transmission / reception point, central unit, distributed unit, radio unit, remote radio head, etc.) in the examples below may be applied to any other suitable type of entity performing RAN functions, and the functionality of a UE or the like (e.g. electronic device, user device, mobile station, subscriber station, customer premises equipment, terminal, remote terminal, wireless terminal, vehicle terminal, etc.) in the examples below may be applied to any other suitable type of device. A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements or entities may be added to the examples disclosed herein. • One or more non-essential elements or entities may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed and / or the order in which messages are transmitted may be modified, if possible, in alternative examples. • The techniques described herein may be applied in any suitable order or combination. Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Certain examples of the present disclosure may be provided in the form of a system (e.g. network or wireless communication system) comprising one or more such apparatuses / devices / network entities, and / or a method therefor. In the techniques of the related art, for example those referred to above, there occur the following problem(s). The behaviour of the UE and network in relation to AI / ML model ID allocation and handling of model ID is not clear. The following problems require solutions. 1) How to allocate model ID for UE-side model(s), UE-part of two-sided model(s), network-side model(s), and / or network-part of two-sided model(s)? 2) How to handle model IDs exchange, modification, release, and / or other actions related to model LCM and model transfer / delivery. 3) Other open points. Certain examples of the present disclosure provide one or more solutions to address the above problems. Certain examples of the present disclosure provide a method for managing, in a network, one or more artificial intelligence and / or machine learning (AIML) model and / or functionality identities (MFIDs) for identifying one or more corresponding AIML models and / or AIML functionalities, the method comprising: transmitting, by the network, to one or more user equipment (UEs), information for allowing the UE and / or the network to assign one or more MFIDs to one or more corresponding models and / or functionalities in a unique manner, wherein the information comprises one or more MFIDs. In certain examples, one or more of the models may comprise one or more of: a network-side model; a network-part of a two-sided model; a UE-side model; and a UE-part of a two-sided model. In certain examples, the information may comprise one or more of: a list of allocated MFIDs (e.g. for network-side, network-part, UE-side and / or UE-part models); and a list of not allocated (e.g. available) MFIDs. In certain examples, the method may further comprise allocating, by the network and / or the UE, one or more MFIDs to one or more corresponding models and / or functionalities in a unique manner based on the information. In certain examples, allocating the MFIDs in a unique manner may comprise uniquely assigning one or more MFIDs to one or more models and / or functionalities: globally; within a certain validity area (e.g. cell, tracking area, slice and / or country); and / or within an Access and Mobility Management Function (AMF). In certain examples, at least one MFID may be allocated to one or more of: a network-side model and / or functionality; a network-part of a two-sided model and / or functionality; a UE-side model and / or functionality; and a UE-part of a two-sided model and / or functionality. In certain examples, the allocating may be performed at least partly by an Access and Mobility Management Function (AMF) entity (e.g. based on an indication from a Radio Access Network (RAN) entity). In certain examples, the method may further comprise: selecting, by the UE, one or more MFIDs based on the information; and allocating the selected MFIDs to one or more models and / or functionalities. In certain examples, the method may further comprise transmitting, by the UE, to the network, an indication of the MFIDs allocated by the UE and / or MFID not allocated by the UE. In certain examples, the allocating may comprise allocating certain MFIDs (e.g. one or more set MFIDs and / or one or more set MFID ranges) only to one or more of: a predetermined service; a predetermined functionality; a predetermined use case; a predetermined configuration; a predetermined scenario; and a predetermined site. In certain examples, the method may further comprise rejecting, by one of the network and the UE, the allocation of an MFID to a model and / or functionality by the other of the network and the UE. In certain examples, the information and / or related information may be provided via one or more of: RRC signalling / messages; NAS signalling / messages; and one or more Information Elements (lEs). In certain examples, the information may further comprise information relating to the MFIDs. In certain examples, the related information may comprise one or more of: an MFID type (e.g. global, dynamic, temporary and / or local); and an MFID side (e.g. UE-side, UE part, networkside and / or network part). In certain examples, the method may further comprise transmitting, by the network to a UE and / or by a UE to the network, information indicating support or lack of support for MFID type. In certain examples, the method may further comprise storing the information and / or related information. In certain examples, the information may be stored in one or more of: a RAN entity; a UE context; and an AMF entity. In certain examples, the method may further comprise transmitting, by a first RAN, to a second RAN, the information and / or related information (e.g. during handover of a UE). In certain examples, the information may comprise one or more ranges of MFIDs. In certain examples, the method may further comprise transmitting, by the network, to the one or more UEs, updated information for allowing the UE and / or the network to assign one or more MFIDs to one or more corresponding models and / or functionalities in a unique manner, and the updated information may comprise one or more MFIDs. In certain examples, the method may further comprise updating, by a UE and / or the network, the allocation of one or more MFIDs to one or more corresponding models and / or functionalities based on the updated information. In certain examples, transmitting the information may comprise transmitting an MFID to a group of two or more UEs, and the MFID may be based on a combination of a group ID component and a group MFID component. In certain examples, the group ID may be associated with the group of UEs and is unique, and the group MFID may be unique within the group of UEs. In certain examples, the information may be transmitted as part of one or more of: a model transfer and / or delivery procedure; and a model life cycle management procedure. In certain examples, one or more of the MFIDs may be associated with a priority level. In certain examples, the method may further comprise performing, by the UE and / or the network, an AIML function using a model based on the priority level of the corresponding MFID. In certain examples, the UE and / or the network may assign an MFID to a model and / or functionality based on the priority level of the MFID. In certain examples, the method may further comprise requesting, by the network and / or a UE, release of one or more MFIDs at the UE and / or the network. In certain examples, the method may further comprise releasing at least one MFID in response to the request (e.g. as part of the deactivation procedure of the model). In certain examples, the method may further comprise determining not to release a requested MFID in response to the request. In certain examples, the method may further comprise transmitting, by the UE and / or the network, a message comprising information on the status (e.g. released, not released) of the one or more MFIDs requested to be released. In certain examples the one or more AIML functionalities may comprise one or more functionalities and / or part of functionality associated with one or more AIML models and / or part of an AIML model. In certain examples, the one or more AIML functionalities may comprise one or more functionalities and / or part of functionality associated with AIML LCM. In certain examples: one or more of the models may be each associated with one or more functionalities and / or part of functionality, one or more of the functionalities and / or part of functionality my be each associated with one or more models, one or more of the models may not be associated with any of the functionalities and / or part of functionality, and / or one or more of the functionalities and / or part of functionality may not be associated with any of the models. Certain examples of the present disclosure provide a network entity (e.g. AMF or RAN) configured to perform a method according to any example, aspect, embodiment and / or claim disclosed herein. Certain examples of the present disclosure provide a network (or wireless communication system) comprising one or more network entities (e.g. UE, RAN, AMF) according to any examples, aspects, embodiments and / or claims disclosed herein. Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, aspect, embodiment and / or claim disclosed herein. Certain examples of the present disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to any example, aspect, embodiment and / or claim disclosed herein. Various specific examples will now be described in more detail. Although the solutions described herein are described in relation to handling Model ID, the skilled person will appreciate that the same or similar solutions can be used for handling identification of a model using functionality / functionalities or functionality ID, etc. That is, the same or similar solutions can be used for handling AI / ML functionality / functionalities ID(s) of related AI / ML model(s) and / or handling functionality / functionalities AI / ML LCM purposes. Additionally, the same or similar solutions can be used for handling functionality and functionality identification in AI / ML operations and / or LCM purposes. The skilled person will appreciate that a model, or multiple models, may be related to, or part of, one functionality, or multiple functionalities. The techniques disclosed herein may be applied to any suitable relationship between models and functionalities. The skilled person will also appreciate that the techniques disclosed herein may be applied to network-side models and / or network-part of two-sided models, or UE-side models and / or UE-part of two-sided models. The skilled person will also appreciate that the techniques disclosed herein may be applied to a single UE or a group of UEs. The skilled person will appreciate that the proposals disclosed herein may be applied using any suitable type of messages, for example Radio Resource Control (RRC) message, Non Access Stratum (NAS) message, or any combination of RRC and NAS messages. Allocation of Model ID In certain examples of the present disclosure, coordination of model IDs between the network and the UE (or a group of UEs) is provided to ensure unique (or harmonised) allocation of models IDs for the UE (or a group of UEs). In certain examples, for network-side and / or network-part of two-sided models, the network may assign a model ID (or models IDs) forthose models. The network may update model IDs allocated to different UEs upon any change in the network, for example changes in network conditions and / or allocated models (model side, or model LCM purposes, etc.). For example, changes may include: a model(s) is no longer active at a given UE (or group of UEs) in a given time period or location / area; or the network decides to stop using a model or the priority of the model changes (e.g. becomes low priority). The network may need to release this ID(s), for example as part of model(s) deactivation. In certain examples, the network may assign a model (or models) an ID (or IDs) that is (are) valid (or active) for / in a given cell, tracking area, slice, country, any other area. In a related example, the model ID assigned for a given cell, tracking area, slice, country, any other area, should be uniquely assigned for the validity area. For example, for a model ID for which the validity area is a tracking area, the assigned model ID should be uniquely assigned over all cells of the tracking area. That is, upon the UE mobility, within the same tracking area, the model ID remains unique over all cells in this tracking area. Upon UE mobility to a cell in a new tracking area (i.e. different to an old tracking area, in which the model ID is unique), this UE will not be allowed to keep the same model ID (assigned in the old tracking area) for use over cells in the new tracking area. Hence, the model ID should be released (not active any more) upon the UE movement to a cell in the new tracking area. Additionally, a new unique (on the level of tracking area) model ID should be allocated to the model for use in the new tracking area. In certain examples, the model ID should be unique within a global cell ID and / or a new target cell. In certain examples, for network-side and / or network-part of two-sided models, the network may provide a list of model IDs to the UE (or group of UEs). In some examples, the list may indicate the list of assigned model IDs and / or list of available (not-assigned) model IDs for the UE (or group of UEs). In other examples, the network may also provide the list of model IDs allocated to network-side model(s) and / or network-part of two-sided model(s). In an embodiment, the network provides (or indicates) to the UE (or group of UEs) information related to the model ID(s), e.g. the model ID type (global, local, dynamic, temporary, and / or any mix of the previous, etc.), and / or model side (UE-side, UE-part, network side, network part). Optionally, this information may be include in the list of model IDs, e.g. may be in the form of a new Information Element (IE), and / or RRC and / or NAS message / signalling, or sent in a separate IE (and / or RRC and / or NAS message / signalling). For example, the indication may be a new defined Model ID Type IE, where this IE may have a new defined value that can be set to “Global”, “Dynamic”, “temporary or local”, etc. The network may configure the Model ID Type, as global, dynamic, temporary, local, etc., depending on the AI / ML LCM purposes, model meta data, use case, model functionality, and / or other assistance information from the network and / or the UE. The UE and / or the network (e.g. NG-RAN, gNB) may configure the model ID, for a model (or models) or any model side (e.g. UE-side, network-side, UE-part, and / or Network-part) to be a locally unique model ID. For example, the rule / range of locality maybe defined in a given area (or location), such as cell-level, slice-level, tracking area-level, country-level, and / or other area types. The network and UE may exchange indications of their support of allocating / assigning different type of model IDs for different model-side models. For example, allocating model types such as global, dynamic, temporary, local, etc. In certain examples, the network may indicate its support of (allocation of) different types of IDs, at least to network-side and / or network-part models, using RRC and / or NAS signalling / messages, and / or via system information broadcast (e.g. periodically and / or on demand). The UE may indicate its support of allocation of different type of IDs, at least to UE-side and / or UE-part model(s), using capability reporting. In certain examples, the network indication of support of different type of IDs may act as an implicit indication to the UE to report it is capability to handle (or assign) different types of IDs, at least to UE-side and / or UE-part of two-sided models. In certain examples, the list of model IDs associated / allocated to a given UE models (e.g. to be assigned to UE-side model(s) and / or UE-part of two-sided model(s)), may be stored in the UE context. For example, as part of the UE context management procedures (and / or any other procedure). In certain examples, the list of model IDs may contain IDs assigned to models, e.g. available at the UE and / or the network, and IDs not yet assigned to any model (s). In certain examples, the list of model IDs may include model IDs already assigned to networkside model(s) and / or network-part of two-sided model(s). In certain examples, the list of model IDs may include a range of model IDs available to a given UE to use in assigning IDs to AI / ML models (e.g. models deployed at the UE and / or network). The UE (or group of UEs) may store the list of model IDs. In certain examples, the UE (or group of UEs) may update (e.g. overwrite) the list of model IDs, stored in the UE, or the UE context, with the newer (or latest, or updated, or modified) list of model IDs. In certain examples, the updated list of model IDs may be received from an internal network entity (and / or function) or an external entity (and / or function), a server, an Operations Administration and Maintenance (OAM), Application, a network operator, based on a country policies and rules, a third party, or another UE (or a group of other UEs), etc. In certain examples, the network stores the list of model IDs. In certain examples, the network may update (e.g. overwrite) the list of model IDs, stored in the network with the newer (or latest, or updated, or modified) list of model IDs. In certain example, the updated list of mode IDs may be received from an internal network entity (and / or function) or an external entity (and / or function), a server, an Operations Administration and Maintenance (OAM), an Application, a network operator, based on a country policies and rules, a third party, or the UE (or a group of UEs), etc. For UE-side models and / or UE-part of two-sided models, the network may provide a list of model IDs (available) to the UE (or group of UEs). In certain examples, the UE (or group of UEs) may use the list of model IDs, received from the network, to assign IDs to a UE-side and / or UE-part of two-sided models. In certain examples, for UE-side models and / or UE-part of two-sided models, the UE may provide a list of model IDs to the network. In some examples, the list of model IDs may indicate assigned model IDs and / or not-assigned (available) model IDs. In other examples, both the UE and the network may allocate a model ID for two-sided models. In some examples, the UE may assign the model ID (or part of model ID) for the UE-part of the two-sided model, and the network may assign the model ID (or part of the model ID) for the network-part of two-sided mode. Both the UE and the Network may indicate the allocated model ID (or part of model ID) to each other. In certain examples, the network is responsible for allocating the model IDs for all models, that is, including UE-side, network side and two-sided models. In a related example, the network may indicate to the UE the list of network assigned or not-assigned (available) models IDs. In other examples, the UE (or group of UEs) is (are) responsible for allocating the model IDs for all models, that is, including UE-side, network side and two-sided models. In a related example, the network may indicate to the UE the list of network assigned or not-assigned (available) models IDs. In certain examples, the model ID for group of UEs may have a group ID component and a group-model ID component. The group-model ID component may be unique within a group ID component and the group ID may also be unique. In certain examples, the network allocation of the model ID (or models IDs) to UE-side and / or UE-part models is part of the model transfer / delivery procedure to the UE. In certain examples, the network allocation of the model ID (or models IDs) to UE-side and / or UE-part models is part of the model LCM procedure. In some examples, the allocation of the model ID (or models IDs) may be part of the activation of the model (or models). The network and / or the UE may assign specific ID(s) (or a range of ID(s)) for a given set of services, functionality / functionalities, use cases, configurations, scenarios, sites, etc., for example, assign a specific model ID(s) for public safety. In certain examples, at least one model ID may be reserved for special services, for example network operations, public safety, or other special applications that may be defined, or for a group of UEs. As such, the network and / or UE should ensure that any ID from this reserved set should only be associated with the application or service for which it is reserved. Otherwise the model ID should not be allocated or used. As such, the UE or the network should attempt to enforce this and optionally reject any model ID which is not in accordance to this rule or policy. The network may configure the UE behaviour to handle the model ID(s) for its models, for example, select model ID(s), assign, modify, release or discard, or indicate model ID(s). etc. A model ID may explicitly or implicitly be associated with a priority level. In this case, the allocation and / or use of a model ID may lead to prioritization of the AI / ML function that is associated with the model ID. The UE or network may then perform prioritized AI / ML functions based on the priority level of the model ID. The priority level may be explicitly signalled or exchanged between the network and the UE, or may be pre-defined for specific model IDs (e.g. reserved IDs) or for specific AI / ML applications. In one example, the list of model IDs (or range of model IDs) is pre-configured by the network, external entity, server, Operations Administration and Maintenance (OAM), Application, network operator, based on a country policies and rules, third party, etc. In certain examples, in the case of large number of models or number of models is larger than the range of model IDs, available for UE-side, network-side and / or two-sided models, the network and / or the UE (or group of UEs) may select a model ID, for example, randomly from the range of available model IDs. Both the UE and the network would then indicate to the other side the selected model ID(s). In certain examples, if selecting a model ID randomly and both the UE and network selects the same ID, the priority of keeping the ID is given for the network. In other examples, the priority of keeping the ID is given for the network at least for the allocation of the ID for the network-side and / or network-part of two-sided model(s). In another example, the priority of keeping the ID is given for the UE at least for the allocation of the ID for the UE-side and / or UE-part of two sided model(s). In certain examples, the model ID is considered to be unique within an Access and Mobility Management (AMF), where the AMF may be identified by any of the following identities (for example as defined in 3GPP TS 23.003): AMF identifier, AMF Region ID, AMF Set ID, AMF Pointer. The AMF (where the AMF may be identified for example by any of the identities listed above) may assign a model ID based on an indication from the RAN entity. For example, as part of any existing (or newly defined) NG (N2) signalling and / or messages, and / or IEs, the RAN (e.g. gNB or NG-RAN) may request the assignment of at least one model ID, or in another example, a list of model IDs. For example, the RAN request of the model ID (or list of model IDs) may be as part of any existing (or newly defined) NG signalling / messages and / or lEs. The AMF may assign at least one model ID based on an explicit request from the RAN entity (e.g. NG-RAN, gNB), or in another example, a list of model IDs. Alternatively, the AMF may assign at least one model ID based on subscription information for a UE or a group of UEs. The indication from the RAN may also be associated with an indication for an assignment which is for a single UE or a group of UEs, where alternatively the AMF may have this information e.g. based on local policies or configurations or subscription information. Alternatively, the AMF may not assign a model ID (or list of model IDs), based on assistance information from another network entity (and / or function). For example, assistance information may include analytics or predictions, statistics (e.g. from Network Data Analytics Function (NWDAF)), and / or history of previously assigned model ID (or list of model IDs). The AMF may store any model ID that is being used by the RAN. For example, the AMF may do so during the release of the UE’s NAS and / or RRC connection. For example, during the UE context release request (e.g. when the RAN sends the UE CONTEXT RELEASE REQUEST message) the RAN may indicate the list of model IDs that the UE is using and may request the AMF to store the model ID(s). The AMF may store the model ID(s) every time the UE’s connection is released or when the RAN explicitly requests the AMF to do so, or based on other local policies. This technique may also be applied when the UE’s context is being suspended, for example when the RAN sends the UE CONTEXT SUSPEND REQUEST message to the AMF. The RAN may fetch a stored UE context, where the context may be for AI / ML which includes at least a model ID. The term “model ID” may be used to refer to model IE and / or other AI / ML related parameters that may also be used with or associated with a model ID. This may also include a priority level which may be associated with the model ID. The RAN may get the model ID from the AMF when a UE enters RRC-CONNECTED state from any state, or when the UE establishes an RRC connection optionally which requires sending a NAS message to the AMF. In some examples, the RAN may explicitly request the model ID that is / are stored at the AMF. In other examples, the AMF may provide the model ID of the UE to the RAN. The AMF may do so when the UE establishes a NAS signalling connection and the AMF then sends the model ID to the RAN using any NG Application Protocol (NGAP) message or any N2 protocol message. For example, the AMF may send any stored model ID - for a UE in question - to the RAN using the Initial UE Context Setup Request message (or any other message, for example the UE CONTEXT MODIFICATION REQUEST message, or UE CONTEXT SUSPEND RESPONSE message). The AMF may do so if the AMF has policies to send this information or if the subscription information requires so or if the AMF has previously stored model ID(s) for the UE or if the AMF receives an explicit request from the RAN to get the model ID(s) for the UE. A model ID may be sent from the source RAN entity (e.g. NG-RAN, gNB) to another target RAN entity (e.g. NG-RAN, gNB) during handover of the UE. This may be done directly via the signalling between the RAN entities or via the AMF. In the case of the handover being done using Xn signalling (and messages and lEs) between the RAN entities, when the target RAN entity informs the AMF about handover completion, the AMF may decide to modify (allocate, release, update) a model ID and provide it to the target RAN entity. During handover, the source RAN entity may provide the model ID to the target RAN entity. The skilled person will appreciate that the names of the proposed new lEs (and / or messages) described herein are merely non-limiting examples, and any other suitable names may be used instead. Handling of model IDs between the UE and the network In certain examples, the network may send the list of model IDs to a give UE (or group of UEs) using an existing and / or newly defined message (e.g. RRC and / or NAS signalling / messages). For example, Model ID List IE (Range = 1..<maxnoofModel>), included in a request message. In a related example, the UE (or group of UEs) may allocate (or assign) a model ID (or models IDs) from the list of model IDs, received from the network, and include those model IDs in a Acknowledge or Confirm message (and / or existing or newly defined lEs) back to the network. For example, using an existing and / or newly defined message (e.g. RRC signalling / messages, NAS signalling / messages). In certain examples, the UE (or group of UEs) may reject (or not use) all IDs (or part of the IDs) included in the list of model IDs, received form the network, for assigning IDs to UE-side and / or UE-part models. In a related example, the UE may indicate to the network, for example in a failure message, the IDs, as rejected IDs, allocated IDs, assigned IDs, not-assigned (or available) IDs, etc. The rejection (or failure) message may be sent in an existing and / or newly defined message (e.g. via RRC and / or NAS signalling, messages) and / or lEs. In certain examples, the UE (or group of UEs) may indicate to the network the reject (or failure) reason using an existing cause value or a newly defined cause value. For example, “NotSuitableModellD”, “NotSupportedModellD”, “NotAllowedModellD”, or any other naming. In certain examples, the model IDs may be released (e.g. un-assigned or not-assigned or deallocated) by the network and / or the UE (or group of UEs), for example upon deactivation of a model (or models) and / or switching of the model (or models), for example to a different model (or models). In certain examples, the network may release (e.g. un-assigned or not-assigned or deallocated) a model ID (or models IDs) of UE-side and / or UE-part models. In one example, the release of the model ID (or models IDs) may be part of the deactivation procedure of the model (or models). In certain examples, the network may request the UE (or group of UEs) to release a model ID (or models IDs) of UE-side and / or UE-part models. This request may be sent in an existing and / or newly defined message (e.g. via RRC signalling / messages and / or NAS signalling / messages) and / or lEs. Ina related example, the UE may acknowledge (or confirm) to the network the release of the desired model ID (or model IDs). In other examples, the UE may send to the network a list of model IDs, or example including released, failed to release (or reject release), currently allocated, and / or available (not-allocated) model IDs at the UE (or group of UEs) side. In certain examples, the UE (or group of UEs) may reject the release of model ID (or models IDs) of UE-side and / or UE-part models, indicated in network request (message). In a related example, this rejection (or failure) message may be sent in an existing and / or newly defined message (e.g. via RRC signalling / messages and / or NAS signalling / messages). In certain examples, the UE (or group of UEs) may indicate to the network the reject (or failure) reason for releasing the model ID (or models IDs) using an existing cause value or a newly defined cause value for example “NoReleaseOfModellDAIIowed”, “ReleaseOfModellDNotSupported”, or any other naming. In certain examples, the network may modify (or update) the list of model IDs, previously shared with the UE (or group of UEs). In a related example, the network may share the list with the UE (or group of the UEs) involved in AI / ML operations. In certain examples, the network may send the modified list of model IDs, for example in a newly defined IE, for example Modified Model ID List IE (or any other suitable naming). In certain examples, the UE may overwrite the content of previously received list of model IDs (e.g. Model ID List IE) with the modified list of model IDs (e.g. Modified Model ID List IE). In certain examples, the UE (or group of UEs) may reject the model ID (or models IDs) allocated by the network for UE-side and / or UE-part of two-sided models. In certain examples, the UE may provide a cause value for the rejection (or failure) of the model ID (or models IDs), for example “AllocatedModellDNotSupported”, “NotSupportedModellD”, or any other suitable naming. The skilled person will appreciate that the names of the proposed new lEs (and / or messages) described herein are merely non-limiting examples, and any other suitable names may be used instead. Examples of changes to 3GPP Specifications RRC specifications: The model information (e.g. parameters, meta data, other model related information) may be provided using existing System Information Blocks (SIBs), and / or a new SIB. For example, the IE SystemlnformationBlockTypeXX contains model assistance information that is used to signal information related to the model between the network and the UE. SystemlnformationBlockTypeXX information element — AAH1RTART HlAtAiiIrifuviAtir.-Al: ; AypTHh-i'Hh ::= HERTEH-TE { un-i-rllnfc-Liii-.A- ltj'?=LZr.:A Li; t-cEE OPT 101 AA, lat~lAriCriti2ilE:=^i£ion -::000 ETFIHG Heed OR OPTIO1IAL, H--A-lTul --1,1 A -I "i :::: HEO1 1E| 1--0, (00:1--1 A . ..:. - H-1 - i.....1 . iA’IA’.--A:,A-- 1 AcAllrAc-Ai: ::= GEoUEHOE ( modeiid-iHA: ihteger (i?. a:a:,, m->delInf=-A00 PEQUE1ICE uodelPar?: oeeoo-AA I Iodol Aoa-oo' = -ATE OPTIO1IAL, — lAe? OR ||||||||ii||||||||||||||||||||||^ Other m-RI olo-o iiarAiietere... Other 3GPP Spec Option 1: Model ID list include UE-side and / or UE-part IDs Model ID List The network may send to the UE (or group of UEs), the IE below that contains a list of allocated and / or available model IDs for UE-side models and UE-part of two-sided models. lE / Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality Model ID List 1..<maxno ofModels> - >Allocated Model ID List M x.x.x.x Contains information of the allocated model IDs for UE-side and / or UE-part of two-sided models. >Available Model ID List M x.x.x.x Contains information of the available model IDs for UE-side and / or UE-part of two-sided models. >Other Information related to Model ID O x.x.x.x. YES ignore Range bound Explanation maxnoofModels Maximum no. of Models allowed for a UE. Value is xx. Option 2: Model ID list include all model IDs Model ID List The network may send to the UE (or group of UEs), the IE below that contains a list of allocated and / or available model IDs for UE-side models, UE-part of two-sided models, network side 5 models, and / or network side or two-sided models. lE / Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality Model ID List 1..<maxno ofModels> - >Allocated Model ID List M x.x.x.x Contains information of the allocated model IDs. - » Allocated Model ID List for UE-side and / or UE-part models Model IDs allocated to UE-side and / or UE-part of two-sided models. » Allocated Model ID List for networkside and / or network-part models M x.x.x.x Model IDs allocated to network-side and / or network-part of two-sided models. >Not Allocated Model ID List Contains information of the not allocated (available) model IDs. > Other Information related to Model ID List O x.x.x.x. YES ignore Range bound Explanation maxnoofModels Maximum no. of models allowed in the network. Value is xx. maxnoofModelforUE Maximum no. of models allowed fora given UE including UE-side and / or UE-part of two-sided models. Value is xx. maxnoofModelforNetwork Maximum no. of models allowed for the network including network-side and / or network-part of two-sided models. Value isxx. Example Methods / Signal Flows Figure 1 illustrates an exemplary method for managing, in a network, one or more AIML model and / or functionality identities (MFIDs) for identifying one or more corresponding AIML models and / or AIML functionalities. Referring to Figure 1, operation 100 comprises transmitting, by a network, to one or more UEs, information for allowing the UE(s) and / or the network to assign one or more MFIDs to one or more corresponding models and / or functionalities in a unique manner. The information comprises one or more MFIDs for identifying one or more corresponding AIML models and / or AIML functionalities. Figure 2 is a first signal flow diagram illustrating various exemplary operations relating to managing one or more MFIDs. Referring to Figure 2, in a first operation 201, the network (e.g. AMF, RAN and / or other network entity) and one or more UEs exchange messages with each other. The messages include indications of support for MFID related information (e.g. MFID type). In a second operation 202, the network transmits a message to the UE(s). The message includes information for allowing the UE(s) and / or the network to assign one or more MFIDs in a unique manner. The information includes one or more MFIDs and / or MFID ranges (e.g. allocated MFID(s) and / or not allocated MFID(s)), and optionally related information (e.g. MFID type and / or MFID side information). In a third operation 203a, the UE(s) allocate(s) one or more MFIDs to one or more models and / or functionalities in unique manner based on the information. Similarly, in operation 203b, the network allocates one or more MFIDs to one or more models and / or functionalities in a unique manner based on the information. In a fourth operation 204a, the UE(s) transmit(s) a message to the network. The message includes an indication of one or more MFIDs allocated and / or not allocated by the UE(s). Similarly, in operation 204b, the network transmits a message to the UE(s). The message includes an indication of one or more MFIDs allocated and / or not allocated by the network. In some cases, one or more allocations of MFIDs by the UEs and / or the network may be rejected. In this case, in a fifth operation 205a, the UE(s) transmit(s) a message to the network. The message includes a rejection of the allocation of one or more MFIDs by the network. Similarly, in operation 205b, the network transmits a message to the UE(s). The message includes a rejection of the allocation of one or more MFIDs by the UE(s). Figure 3 is a second signal flow diagram illustrating further exemplary operations relating to managing one or more MFIDs. In a first operation 301, the network (e.g. AMF, RAN and / or other network entity) transmits a message to one or more UEs. The message includes updated information allowing the UE(s) and / or the network to assign one or more MFIDs in a unique manner, and optionally updated related information (e.g. MFID type and / or MFID side information). In a second operation 302a, the UE(s) update(s) the allocation of one or more MFIDs to one or more models and / or functionalities in a unique manner based on the updated information. Similarly, in operation 302b, the network updates the allocation of one or more MFIDs to one or more models and / or functionalities in a unique manner based on the updated information. In a third operation 303a, the UE(s) transmit a message to the network. The message includes a request to release one or more MFIDs at the network. In a fourth operation 304a, the network determines whether or not to release the requested MFIDs. The network may release some MFIDs and not release other MFIDs. In a fifth operation 305a, the network transmits a message to the UE(s). The message includes information indicating a status (e.g. released, not released) of one or more MFIDs requested to be released. Similarly, in operation 303a, the network transmits a message to the UE(s). The message includes a request to release one or more MFIDs at the UE(s). In operation 304b, the UE(s) determine(s) whether or not to release the requested MFIDs. The UE(s) may release some MFIDs and not release other MFIDs. In operation 305b, the UE(s) transmit(s) a message to the network. The message includes information indicating a status (e.g. released, not released) of one or more MFIDs requested to be released. Figure 4 is a third signal flow diagram illustrating a yet further exemplary operation relating to managing one or more MFIDs. In a first operation 401, a UE handover procedure is carried out between a first RAN (e.g. a source RAN) and a second RAN (e.g. a target RAN). In a second operation 402, the source RAN transmits a message to the target RAN. The message includes information for allowing one or more UEs and / or a network to assign one or more MFIDs in a unique manner. The information includes one or more MFIDs (e.g. allocated MFID(s) and / or not allocated MFID(s)), and optionally related information (e.g. MFID type and / or MFID side information). In various examples, operation 402 may be considered as part of the handover procedure 401, or as separate from the handover procedure 401. The skilled person will appreciate that the operations shown in Figures 2-4 are merely examples that may be used in any suitable combination. In alternative examples, one or more of the operations shown in each of Figures 2-4 may be omitted and / or one or more further operations may be added. Also, the operations of Figures 2-4 may be used individually or may be combined with each other. The examples of Figures 2-4 may incorporate, or be combined with, any of the other examples disclosed herein. Example Apparatus Figure 5 is a block diagram of an exemplary network entity that may be used in examples of the present disclosure. For example, a UE and / or network entity in the examples of Figures 1-4 may be provided in the form of the network entity of Figure 5. The skilled person will appreciate that a network entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The entity 500 comprises a processor (or controller) 501, a transmitter 503 and a receiver 505. The receiver 505 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 503 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 501 is configured for performing one or more operations, for example according to the operations as described above. The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment, example or claim disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software. It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising 5 instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment, aspect and / or claim disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication 10 signal carried over a wired or wireless connection. While the invention has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention, as defined by the appended claims. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions are used. 3GPP 5G 3rd Generation Partnership Project 5th Generation 5 6G 6th Generation Al Artificial Intelligence AIML Al and / or ML AMF Access and Mobility Management Function eNB Base Station 10 FFS For Further Study gNB 5G Base Station ID Identity / ldentifier IE Information Element LCM Life Cycle Management 15 MFID AIML Model and / or Functionality ID ML Machine Learning N2 Interface between NG-RAN and AMF NAS Non Access Stratum NB Base Station 20 NG Next Generation NGAP NG Application Protocol NR New Radio NWDAF Network Data Analytics Function OAM Operations, Administration and Maintenance 25 RAN Radio Access Network RRC Radio Resource Control SIB System Information Block TS Technical Specification UE User Equipment 30 Xn Interface between NG-RAN nodes

Claims

1. A method for managing, in a network, one or more artificial intelligence and / or machine learning (AlML) model and / or functionality identities (MFIDs) for identifying one or more corresponding AIML models and / or AIML functionalities, the method comprising:transmitting, by the network, to one or more user equipment (UEs), information for allowing the UE and / or the network to assign one or more MFIDstooneormore corresponding models and / or functionalities in a unique manner,wherein the information comprises one or more MFI Ds.

2. A method according to claim 1, wherein one or more of the models comprises one or more of:a network-side model;a network-part of a two-sided model;a UE-side model; anda UE-part of a two-sided model.3 A method according to claim 1 or 2, wherein the information comprises one or more of:a list of allocated MFIDs (e.g. for network-side, network-part, UE-side and / or UE-part models); anda list of not allocated (e.g. available) MFIDs.

4. A method according to claim 1, 2 or 3, further comprising allocating, by the network and / or the UE, one or more MFIDs to one or more corresponding models and / or functionalities in a unique manner based on the information.

5. A method according to claim 4, wherein allocating the MFIDs in a unique manner comprises uniquely assigning one or more MFIDs to one or more models and / or functionalities:globally;within a certain validity area (e.g. cell, tracking area, slice and / or country); and / or within an Access and Mobility Management Function (AMF).

6. A method according to claim 4 or 5, wherein at least one MFID is allocated to one or more of:a network-side model and / or functionality;a network-part of a two-sided model and / or functionality;a UE-side model and / or functionality; anda UE-part of a two-sided model and / or functionality.

7. A method according to claim 4, 5 or 6, wherein the allocating is performed at least partly by an Access and Mobility Management Function (AMF) entity (e.g. based on an indication from a Radio Access Network (RAN) entity).

8. A method according to any of claims 4 to 7, further comprising: selecting, by the UE, one or more MFIDs based on the information; and allocating the selected MFIDs to one or more models and / or functionalities.

9. A method according to claim 8, further comprising transmitting, by the UE, to the network, an indication of the MFIDs allocated by the UE and / or MFID not allocated by the UE.

10. A method according to any of claims 4 to 9, wherein the allocating comprises allocating certain MFIDs (e.g. one or more set MFIDs and / or one or more set MFID ranges) only to one or more of:a predetermined service;a predetermined functionality;a predetermined use case;a predetermined configuration;a predetermined scenario; and a predetermined site.

11. A method according to any of claims 4 to 10, further comprising rejecting, by one of the network and the UE, the allocation of an MFID to a model and / or functionality by the other of the network and the UE.

12. A method according to any preceding claim, wherein the information and / or related information is provided via one or more of:RRC signalling / messages;NAS signalling / messages; andone or more Information Elements (lEs).

13. A method according to any preceding claim, wherein the information further comprises information relating to the MFI Ds.

14. A method according to claim 13, wherein the related information comprises one or more of:an MFID type (e.g. global, dynamic, temporary and / or local); andan MFID side (e.g. UE-side, UE part, network-side and / or network part).

15. A method according to claim 14, further comprising transmitting, by the network to a UE and / or by a UE to the network, information indicating support or lack of support for MFID type.

16. A method according to any preceding claim, further comprising storing the information and / or related information.

17. A method according to claim 16, wherein the information is stored in one or more of:a RAN entity;a UE context; and an AMF entity.

18. A method according to any preceding claim, further comprising transmitting, by a first RAN, to a second RAN, the information and / or related information (e.g. during handover of a UE).

19. A method according to any preceding claim, wherein the information comprises one or more ranges of MFI Ds.

20. A method according to any preceding claim further comprising transmitting, by the network, to the one or more UEs, updated information for allowing the UE and / or the network to assign one or more MFI Ds to one or more corresponding models and / or functionalities in a unique manner, wherein the updated information comprises one or more MFI Ds.

21. A method according to claim 20, further comprising updating, by a UE and / or the network, the allocation of one or more MFIDs to one or more corresponding models and / or functionalities based on the updated information.

22. A method according to any preceding claim, wherein transmitting the information comprises transmitting an MFID to a group of two or more UEs, and wherein the MFID is based on a combination of a group ID component and a group MFID component.

23. A method according to claim 22, wherein the group ID is associated with the group of UEs and is unique, and wherein the group MFID is unique within the group of UEs.

24. A method according to any preceding claim, wherein the information is transmitted as part of one or more of:a model transfer and / or delivery procedure; and a model life cycle management procedure.

25. A method according to any preceding claim, wherein one or more of the MFIDs are associated with a priority level.

26. A method according to claim 25, further comprising performing, by the UE and / or the network, an AIML function using a model based on the priority level of the corresponding MFID.

27. A method according to claim 25 or 26, wherein the UE and / or the network assign an MFID to a model and / or functionality based on the priority level of the MFID.

28. A method according to any preceding claim, further comprising requesting, by the network and / or a UE, release of one or more MFIDs at the UE and / or the network.

29. A method according to claim 28, further comprising releasing at least one MFID in response to the request (e.g. as part of the deactivation procedure of the model).

30. A method according to claim 28 or 29, further comprising determining not to release a requested MFID in response to the request.

31. A method according to claim 28, 29 or 30, further comprising transmitting, by the UE and / or the network, a message comprising information on the status (e.g. released, not released) of the one or more MFIDs requested to be released.

32. A method according to any preceding claim, wherein the one or more AIML functionalities comprise one or more functionalities and / or part of functionality associated with one or more AIML models and / or part of an AIML model.

33. A method according to any preceding claim, wherein the one or more AIML functionalities comprise one or more functionalities and / or part of functionality associated with AIML LCM.

34. A method according to any preceding claim, wherein:one or more of the models are each associated with one or more functionalities and / or part of functionality,one or more of the functionalities and / or part of functionality are each associated with one or more models,one or more of the models are not associated with any of the functionalities and / or part of functionality, and / orone or more of the functionalities and / or part of functionality are not associated with any of the models.

35. A network entity (e.g. AMF or RAN) configured to perform a method according to any preceding claim.

36. A computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of claims 1 to 34.

37. A computer or processor-readable data carrier having stored thereon a computer program according to claim 36.31

Citation Information

Patent Citations

  • Model discovery and selection for cooperative machine learning in cellular networks

    US20220182263A1

Cited By

  • A user equipment and a network node

    GB2701219A

  • A user equipment and a network node

    GB2701224A