Apparatus and method

Abstract

A method of managing AI / ML data within a telecommunication system, comprising a network and a User Equipment, UE, wherein said AI / ML data is explicitly identified as such by means of the provision of

Description

Field The present invention relates to AI / ML data transport mechanisms. Background to the invention AI / ML Operations Machine Learning Operations (MLOps) is a system of processes for the end-to-end AI / ML lifecycle management (LCM) at scale. These processes ensure that the AI / ML model can be scaled for a large user base and achieve accurate performance. The MLOps processes can be split into three categories [1]. • Data Preparation: This category involves data collection, data reporting, data analysis, data validation, feature engineering and data splitting. Using data collection to collect data from a variety of sources, data analysis to analyzing data to identify patterns and relationships, data validation is the process of verifying that the data is accurate and consistent. Through feature engineering, new features can be developed from existing data and this can enhance the model's accuracy. Using data splitting to separate the data into train, test, and validation sets to ensure the model is correctly trained. • Model Development: This category involves model configuration, model training and model validation. The data scientist implements different algorithms with the prepared data to train various ML models. In addition, you subject the implemented algorithms to hyper-parameter tuning to obtain the best performing ML model. The output of this step is a trained model. Next step to validate model to be deployed in the production environment. • Rollout: This category involves model deploying, model serving, model monitoring and model re-training. The validated model is deployed to a production environment to serve predictions. The model deployment can be REST API micro service to serve online predictions or an embedded model to an edge or mobile device. The model predictive performance is monitored to potentially invoke a new iteration in the ML process. Figure 1 schematically depicts an example of different stages of data preparation for AI / ML model. Data is the backbone of AI / ML algorithms. Therefore, high-quality data is needed for any AI / ML project, a low-quality dataset never produces a high-quality Al model. Quality Data is described as the filtered, cleansed and contextualized form of massive dataset. Modern AI / ML models have become data-hungry and computationally expensive. Such models keep performing better as the size of the training data increases. However, training on large datasets has significantly increased end-to-end training times, computational power and energy consumption. Many Al projects struggle with the data collection because of several common issues. For example: • Incomplete data • Unstructured data • Duplicated data • Biased data • Imbalanced data • Noisy data • High-dimensional data 3GPP Background Information The following provides a selection of 3GPP agreements on AI / ML work in working groups RAN1, RAN2 and RAN3, that is related to this invention. RAN1 agreements on Study Item on AI / ML for NR Air Interface [RP-213599]: Refer to Appendix I; RAN2 agreements on Study Item on AI / ML for NR Air Interface [RP-213599]: Refer to Appendix II; and RAN3 agreement on AI / ML for NG-RAN work item: Refer to Appendix III. Summary of the Invention Problem Statement 3GPP has started studying the benefits of integration of AI / ML solutions to communications networks, in order to improve network operations. 3GPP working groups RAN1 and RAN2 are studying data collection requirements, for different AI / ML model Life Cycle Management (LCM) purposes per use case, for aspects such as data content, data size, and data latency. For example, data for model training may have less latency constraint on data collection compared with model inference or model monitoring. For any AI / ML operation, data needs to be collected and in many cases transferred from one entity to another. The data may be training data, validation data and / or data for inference -hereafter referred to as data. A common transport mechanism is the user plane where, for example, an IP connection is used to transport data. Such mechanisms assume a communication between a device and an application server (AS) somewhere in the Internet. However, AI / ML data for RAN related operation may need data from within the network. How such data should be transferred, e.g. between a UE and the NG-RAN has not been described, at least not adequately and not for all scenarios. One such missing scenario is the case of certain UEs which do not support user plane i.e. they only support the control plane. These devices therefore cannot use the common user plane approach for data transport. An aim of an embodiment of the present invention is to provide solutions related to the following issues: • Data transport mechanisms over the user plane (for UEs that support user plane) where such solutions have not been described yet; and • Data transport mechanisms over the control plane - for UEs which don’t support the user plane. Detailed Description of the Invention According to the present invention there is provided a method, as set forth in the appended claims. Also provided is a network. Other features of the invention will be apparent from the dependent claims, and the description that follows. According to a first aspect of the present invention, there is provided a method of managing AI / ML data within a telecommunication system, comprising a network and a User Equipment, UE, wherein said AI / ML data is explicitly identified as such by means of the provision of one or more of explicit signalling and the provision of assistance information, allowing a particular system entity to recognise the AI / ML data and to process it accordingly. In an embodiment, the explicit signalling comprises NAS or RRC signalling from the network to the UE. In an embodiment, the assistance information comprises one or more of timestamp, location, data session ID, data purpose, reason for data update, data version number and last update. According to a second aspect of the present invention, there is provided a method of using a User Plane, UP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network, wherein the AI / ML data is carried by means of at least one of: • A Local Area Data Network, LADN; and • Service Data Adaptation Protocol, SDAP. In an embodiment, if the AI / ML data is carried by means of SDAP, there is an SDAP entity configured for each LADN PDU session for AI / ML data According to a third aspect of the present invention, there is provided a method of using a Control Plane, CP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network, wherein either: • a dedicated Network Function, NF, is provided to host the AI / ML data and a specific NAS message is provided for this purpose; or • AI / ML data is exchanged via the Session Management Function, SMF, via the use of a UL / DL NAS TRANSPORT message. In an embodiment, the UE and network exchange capability information regarding one or more supported techniques for exchanging AI / ML data. According to a fourth aspect of the present invention, there is provided apparatus arranged to perform the method of any preceding aspect. Solutions The following are the proposed solutions in this invention which can be used in any order or combination and are not just limited to a particular system such as 5G but can also be used in other systems such as 4G, 6G, etc. User plane (UP) solution options The following provides solutions for data transport based on UP mechanisms. Use of local area data network to get data for RAN related AI / ML operations This section provides that the AI / ML data should be local to the UE’s location. The AI / ML data may by exchanged with at least one NG-RAN node that is in (or associated with) the UE’s location and the at least one NG-RAN node is involved in either sending and / or receiving data from the UE for an AI / ML application and / or use case. Hereafter, the UE’s location may refer to a location in at least one cell, at least one Tracking Area (TA), RAN Notification Area (RNA), Registration Area (RA), and / or a country, PLMN, etc. The UE may be configured with an LADN DNN (or LADN DNN and S-NSSAI) information for AI / ML data for any RAN related use case and / or application. Hereafter, LADN information may refer to LADN DNN, or LADN DNN and S-NSSAI information. When the UE is in the location, e.g. in the tracking area (TA) which matches the tracking area identity (TAI) that is associated with the LADN DNN (or LADN DNN and S-NSSAI), then the UE may establish a PDU session for LADN where the UE then gets or sends data for RAN AI / ML operations. In this case, it is proposed that a local AS should be used by the network to contain the AI / ML data and as such the UE would see or consider this AS like any other AS on the Internet but the difference is that it is quite known to the UE that the PDU session for LADN is to be used for AI / ML data. This information, or this awareness, about the LADN PDU session being for AI / ML data for RAN applications may be configured in the UE. Alternatively, the RAN (i.e. NG-RAN(s) / gNB(s)) may broadcast via system information (e.g. periodically and / or on-demand) at least any of the following indications: • An indication that there is support for a local PDU session for AI / ML for RAN. For example, the NG-RAN provides a flag ‘1 / 0’ indicating whether a given cell (or more than one cell) supports / does not support a local PDU session for AI / ML. In another example, the indication may be provided using existing and / or newly defined SIBs. • The LADN information that can be used by the UE to get AI / ML data for RAN. For example, the NG-RAN provides a flag ‘1 / 0’ indicating whether a given cell (or more than one cell) provides / does not provide LADN information, or an indication whether LADN PDU session can be used for AI / ML data. In another example, the indication (and / or the LADN information) may be provided using existing and / or newly defined SIBs. In another example, the LADN information, or an indication whether LADN PDU session can be used for AI / ML data, may be provided to the UE via on-demand broadcast of the information following the UE request of the information. In another example, the LADN information, or an indication whether LADN PDU session can be used for AI / ML data, may be multicast to a group of UEs that are expecting to get AI / ML data from RAN. Alternatively, the UE may receive an indication from the network e.g. using existing (and / or newly defined) dedicated signaling / messages (NAS and / or RRC signaling) that the AI / ML data can be sent and / or received using a local PDU session. The messages may also contain the actual LADN information. Upon receipt of an indication that AI / ML data is available for the UE, or can be uploaded and / or downloaded by the UE, using a local PDU session, the UE may take any of the following actions: • The UE may request the specific LADN information from the network, using any NAS or RRC message, where the message may be a new or existing message • The UE may indicate that the reason for the request is for AI / ML data • The UE may establish a PDU session for LADN using an LADN information that the UE has received (via broadcast method, dedicated NAS / RRC message method, and / or based on pre-configured information in the UE) • As part of the PDU session establishment, the UE indicates e.g. with a new IE or field, that the PDU session is for AI / ML data (optionally for RAN application). The network should also indicate that the session is for AI / ML, where for example the indication may be introduced in the 5GSM NAS message e.g. in the PDU Session Establishment Accept message. The UE should store an indication that the particular PDU session is for AI / ML either based on knowledge of the LADN information being for RAN AI / ML or based on an indication that is received e.g. from the network in any NAS or RRC message • When a PDU session for LADN (for AI / ML data) has been established, the UE may then connect with the local AS to get or send data • Upon reception of any AI / ML data in the UE, the UE need not send the data to the upper layers. The data that is received should be provided to the lower layers e.g. to the RRC layer or an AI / ML entity in the UE, where this entity is not an application client like a normal application client which resides in the upper layers of the UE Note that this solution re-uses the existing functionalities as much as possible. The network operator should deploy a local AS that can be accessed by a local PDU session (e.g. a PDU session for LADN) which the UE can use to get or exchange data based on the concept of a PDU session that may be of type IP, Ethernet, non-IP, etc. The UE may be informed, based on broadcast and / or dedicated signaling (at NAS and / or RRC) about the scope of the LADN PDU session e.g. which cells, TAI and / or NG-RAN nodes (or any other location) provide access to the session. As such, when the UE determines that it has moved out of the area that enables access to the LADN PDU session (for AI / ML), the UE may take any of the actions previously listed e.g. to establish a new session in the new area which does not provide access to the previous session and / or AS for AI / ML data. Alternatively, the UE may use a Fully qualified domain name (FQDN) to get the address of an AI / ML data application server that can be connected with to exchange AI / ML data with. The UE may use DNS to discover an AS for exchange of AI / ML data. In this solution, how the network populates the local AS with RAN AI / ML data is out of scope, or it may be implementation specific or may be based on operation and management procedures. Similarly, how the NG-RAN node becomes aware of data from a UE being sent or transferred to the local AS is based on implementation specific aspects or based on operation and management procedures. Alternatively, when the UE sends data to the local AS, the UE may inform the NG-RAN that it has uploaded data to the AS. The UE may provide an indication and / or identification of the data content that it has uploaded, optionally with other parameters such as timestamp, location, data session ID, data purpose (e.g. training, monitoring, other life-cycle-management (LCM) purpose), etc. In one example, the UE provides to the NG-RAN information related to the model (and / or model functionality) identification in relation to the data. In another example, In another example, the information related to the model (and / or model functionality) may identify the data explicitly or implicitly. The NG-RAN may use this information to fetch data from individual UEs or group of UEs (for which group ID and / or other identification may be used) accordingly. In another example the NG-RAN may use this information to fetch data from the AS. The UE may use new and / or existing RRC messages to inform the NG-RAN that data has been updated to the local AS and provides any form of identification in relation to the data that has been uploaded. In one example, the model (and / or model functionality) identification in relation to the data. Optionally, the UE may provide other (additional) parameters related to the data, such as timestamp, location, data session ID, data purpose (e.g. training, monitoring, other life-cycle-management (LCM) purpose), and / or reason for the data update, data version number, last update, etc. The NG-RAN may then use any received identification information to fetch the data, noting that the identification information may be any identification such as a UE identity (NAS level or RRC level), AI / ML session identity, use case identity, model identification, and / or model functionality (or functionality) identification, etc. Similarly, when the NG-RAN updates AI / ML data which is relevant for the UEs, or at least one UE, the NG-RAN may indicate to (or informs) the UE(s) about the update. In a related example, the indication may be sent together with (or separately) information related to the changes (or updates) in the AI / ML data which is relevant to the UEs. Optionally, the NG-RAN may provide other (additional) parameters related to the data, such as timestamp, location, data session ID, data purpose (e.g. training, monitoring, other life-cycle-management (LCM) purpose), and / or reason for the data update, data version number, last update, etc. The indication may be done with dedicated (existing and / or newly defined RRC signaling / messages) and / or broadcast signaling (e.g. periodically and / or on-demand, using existing and / or new SIBs) and / or MAC CE. The NG-RAN may also provide an identification which is related to the updated data. In one example, the NG-RAN provides to the UE information on the model (and / or model functionality) identification in relation to the data. In another example, the information related to the model (and / or model functionality) may identify the data explicitly or implicitly. The UE may receive, e.g. via broadcast or dedicated signaling, an indication that AI / ML data has been updated and may also receive related identification information. Based on this, the UE may then attempt to fetch the updated data and may use the identification information to request the particular updated data. There is also provided an interface between the AS and the NG-RAN. The NG-RAN may use this interface to upload data for a UE, or to fetch data that that was uploaded by any UE where the NG-RAN may use the identification information to fetch such a data and provide this information on the interface (or protocol) connecting the NG-RAN with the AS for identifying the data of relevance. Note that the term NG-RAN may also refer to the network which in turn may refer to either RAN nodes and / or core network nodes or any other new nodes. Note that the UE and the network (e.g. NG-RAN, AMF, SMF, UPF, UDM, etc.) may exchange capability information to indicate support of AI / ML data transport using a PDU session for LADN. The UE and / or the network may behave as described herein when both entities support the capability. In one option, if the capability is negotiated with the core network, then the core network (e.g. AMF) may provide this capability to the NG-RAN where the core network may indicate that the UE supports this feature and hence the NG-RAN may operate as described herein, in relation to the UE in question, based on this indication. In another example, the UE provides this capability directly to the NG-RAN based on request from the NG-RAN. In another example, the UE provides the capability to the NG-RAN. Hereafter, the UE and / or network capability to support AI / ML data transport using PDU session for LADN, is exchanged using any suitable existing (and / or newly defined) RRC and / or NAS signaling / messages. In one example, the network may only offer the service of AI / ML data transport using a PDU session to the UE (or groups of UEs), that report the capability to support this service. In another example, the network may configure the UE (or groups of UEs) that support this capability to behave as described in previous examples and participate in transport of AI / ML data using PDU session for LADN. Use of Service Data Adaptation Protocol (SDAP) to exchange AI / ML data The following describes the use of the SDAP protocol as a means to exchange AI / ML data. SDAP entity configuration, establishment and release: There is an SDAP entity configured for each LADN PDU session for AI / ML data. Note that although LADN PDU session for AI / ML may be used, the AI / ML data may be sent directly in the SDAP protocol as described next. The network may request the UE to establish a SDAP entity for LADN PDU session for AI / ML data. In one example, the RRC requests establishment of an SDAP entity for LADN PDU session for AI / ML data. The UE may establish a SDAP entity for LADN PDU session for AI / ML data. The network may request the UE to release a SDAP entity for LADN PDU session for AI / ML data. In one example, the RRC requests release of an SDAP entity for LADN PDU session for AI / ML data. The UE may release a SDAP entity for LADN PDU session for AI / ML data. DL SDAP LADN PDU For AI / ML Data with SDAP header Figure 2 shows an example format of SDAP LADN PDU session of DL for AI / ML data with SDAP header being configured. UL SDAP LADN PDU For AI / ML Data with SDAP header Figure 3 shows an example format of SDAP LADN PDU session of UL for AI / ML data with SDAP header being configured. In one example, the UL SDAP and DL SDAP PDU for AI / ML data may use (or contain) an existing Quality of Service (QoS) Flow ID (QFI) header for the identification of the QoS flow related to related to (or associated with) the AI / ML data. Optionally, the DL SDAP PDU may also use other headers (but not limited to those headers) such as Reflective QoS indication (RQI), Reflective QoS flow to DRB Identifier (RDI). In alternative example, the UL SDAP and DL SDAP PDU for AI / ML data may use (or contain) a newly defined header, namely LQDI (LDAN QFI, and / or any other suitable naming), for the identification of the QoS flow related to (or associated with) the AI / ML data. LQFI (LADN QFI) Length: example, 6 bits The LQFI field indicates the ID of the LADN QoS flow to which the SDAP PDU belongs (i.e. LADN PDU session). Note for the definition of SDAP parameters and headers, such as DATA, D / C, QFI, R, refer to Annex IV, or 3GPP TS 37.324 [5], Control plane (CP) solution options Use of a new Network Function and a new NAS message for data transport This solution proposes to use the NAS as a transport mechanism for AI / ML data. A new data collection network function (or entity) can be defined such that the entity can host the AI / ML data. However, the transport of this data should be done using a NAS protocol. To do so, a new NAS message may be defined and used for this purpose. For example, a new (UPLINK / DOWNLINK) AIML DATA TRANSPORT message may be defined for this purpose. It should be noted that the name does not matter but any other name may be used, and that this name is to be considered as an example. Note that the existing UL / DL NAS TRANSPORT message may also be used for this purpose. However, a new payload type can be defined for the Payload type container IE (see [5]) such that it indicates that the contents of the Payload container IE (see [5]) is AI / ML data. The UE or the AMF, when needing to send AI / ML data, should therefore set the Payload container type IE to a value which indicates AI / ML data, e.g. a new “AI / ML data content” value may be defined for this purpose. The UE or the AMF should then include the AI / ML data content in the Payload container IE, and optionally include any other parameter as new fields or within the Payload container IE. The UE or the AMF should then send the NAS message accordingly. The NAS message may also contain any of the following information: • Identification information which can be used to identify any combination of the following • The UE, or group of UEs • An AI / ML session or use case • A particular AI / ML data set, optionally whether the data is for training, validation, testing, inference, etc • Any other information that can be defined and used for specific contexts such as timestamp, location, application of the data, use of the data, purpose, etc • Sequence number that can be used to define or track the sequence of data that is being used / sent / exchanged, where the sequence may be updated at every transmission • An indication if the data is to be provided to the upper layers, or the lower layers in the UE Note that when sending the data, the UE or the network may populate the necessarily fields of a NAS message such that the information listed above may be provided to the recipient, where the sender may be either a UE or the network (e.g. AMF). Upon reception of the NAS message with AI / ML data, the recipient (UE or AMF) may verify the parameters which are included to determine which UE or application or context is the data for. Note that the UE and the network (e.g. the AMF) should exchange capability information about the support of this feature i.e. the feature of sending AI / ML data over NAS. The UE may be expected to support this by default, e.g. any UE which does not support UP may be expected to support this by default. Alternatively, the UE may indicate that it supports AI / ML data transport over NAS by means of a new capability indication that can be defined as part of the 5GMM capability IE which the UE may include in a NAS message such as the Registration Request message. Similarly, the network may indicate it supports this feature by defining and using a new indication in any IE which can be sent in any NAS message. For example, the 5GS network feature support IE can be used for this purpose where a new bit may be defined to indicate if the feature is supported. The IE can be sent in the Registration Accept message or any other NAS message. The UE may be configured to use the NAS protocol for transporting or exchanging of AI / ML data, or the UE may do so if the UE supports this feature and optionally the network also supports this feature and optionally has allowed it for the UE. The lower layers in the UE may collect AI / ML data that needs to be sent to the network. The lower layers in the UE should provide the AI / ML data to the NAS and indicate that this is for AI / ML data. The NAS can then include the AI / ML data in the appropriate NAS message, and optionally include other information and then send the data. The AMF may receive a NAS message which contains AI / ML data. The AMF may verify the contents to determine other parameters that are associated with the AI / ML data such as any combination of those that have been listed above. The AMF may forward the data and the other parameters (or information e.g. UE identity, AI / ML identity, session identity, timestamp, NG-RAN identity such as cell identity, etc) to the new proposed NF. The AMF may inform the NG-RAN that new data has been sent by any UE, or the UE may inform the NG-RAN about this as has been proposed herein. The NG-RAN, either based on the indication from the AMF, or the UE, may them attempt to get and / or use the data. The UE or AMF may provide - to the NG-RAN - any other information to identify the data which has been provided and the NG-RAN in turn may use this information to fetch or use the particular data in question. The NG-RAN may be configured with information to connect with the new NF and to optionally fetch or upload data. Alternatively, the AMF may provide the AI / ML data to the NG-RAN when such data is sent by a UE. When the UE receives a NAS message which contains AI / ML data, e.g. the new NAS message which has been set out, the UE may determine that the AI / ML data is for the lower layers based on any indication in the NAS message, or based on a default behaviour. The UE (e.g. the NAS entity) may then provide the data and / or other information to the lower layers. Use of existing messages and data is exchanged via the SMF In this alternative, the new NF for AI / ML data may be connected to an SMF. The NG-RAN may be configured to connect to this new NF using any protocol and the NG-RAN may use this information or protocol to get or upload data to the new NF. The AMF or SMF or UE may notify the NG-RAN when data is sent by a UE, optionally with any additional parameters such as those previously listed. For this solution, the UE may be preconfigured with a well-known DNN and / or S-NSSAI to be used for sending AI / ML data, or a well-known (or predefined) PDU session ID such that it is known that this PDU session ID is associated with a PDU session for sending (or exchanging) AI / ML data. The use of the specific PDU session ID means that the data contents are for AI / ML. The UE and the network may also exchange capability information for this solution option as has been described earlier. To send actual AI / ML data, the UE or the network may use the existing NAS message e.g. UL / DL NAS TRANSPORT message and include the data as if it is data for CloT communication. However, the particular PDU session ID would mean that the data is for AI / ML. In another alternative, a new payload type can be defined for the Payload type container IE (see [5]) such that it indicates that the contents of the Payload container IE (see [5]) is AI / ML data. The UE or the AMF, when needing to send AI / ML data, should therefore set the Payload container type IE to a value which indicates AI / ML data, e.g. a new “AI / ML data content” value may be defined for this purpose. The UE or the AMF should then include the AI / ML data content in the Payload container IE, and optionally include any other parameter as new fields or within the Payload container IE. The UE or the AMF should then send the NAS message accordingly. Note that to send data in the downlink, the SMF receives data from the new NF and then forwards the data to the AMF and includes the PDU session ID. The AMF then forwards the data to the UE using the DL NAS TRANSPORT. In the uplink, the UE sends the data and optionally the PDU session ID as has been described earlier. The AMF forwards the data to the SMF which in turn forwards the data to the new NF. The UE or the network may also send other information or parameters in the NAS message. References [1] https: / / cloud.google.com / architecture / mlops-continuous-delivery-and-automation-pipelines-in-machine-learning [2] RP-213599, Study on Artificial Intelligence (Al) / Machine Learning (ML) for NR Air Interface. [3] 3GPP TS 38.413, Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP) [4] 3GPP TS 38.423, NG-RAN; Xn Application Protocol (XnAP). [5] 3GPP TS 37.324 V17.0.0 (2022-03), Service Data Adaptation Protocol (SDAP) specification. [6] 3GPPTS 24.501 V18.3.0 Definitions The optional features set out herein may be used either individually or in combination with each other where appropriate and particularly in the combinations as set out in the accompanying claims. The optional features for each aspect or exemplary embodiment of the invention, as set out herein are also applicable to all other aspects or exemplary embodiments of the invention, where appropriate. In other words, the skilled person reading this specification should consider the optional features for each aspect or exemplary embodiment of the invention as interchangeable and combinable between different aspects and exemplary embodiments. Brief description of the drawings For a better understanding of the invention, and to show how exemplary embodiments of the same may be brought into effect, reference will be made, by way of example only, to the accompanying diagrammatic Figures, in which: Figure 1 schematically depicts an example of different stages of data preparation for AI / ML model; Figure 2 schematically depicts an example on DL SDAP for AI / ML Data PDU of DL LADN session for AI / ML data with SDAP header; and Figure 3 schematically depicts an on UL SDAP for AI / ML Data PDU of UL LADN session for AI / ML data with SDAP header. Notes Although a preferred embodiment has been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims and as described above. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. Appendix I (RAN1 Study Item on AI / ML for NR Air Interface) RAN1#109-e Agreements and working assumptions: Table: Working list of terminologies Terminology Description Data collection A process of collecting data by the network nodes, management entity, or UE for the purpose of AI / ML model training, data analytics and inference AI / ML Model A data driven algorithm that applies AI / ML techniques to generate a set of outputs based on a set of inputs. AI / ML model training A process to train an AI / ML Model [by learning the input / output relationship] in a data driven manner and obtain the trained AI / ML Model for inference AI / ML model Inference A process of using a trained AI / ML model to produce a set of outputs based on a set of inputs AI / ML model validation A subprocess of training, to evaluate the quality of an AI / ML model using a dataset different from one used for model training, that helps selecting model parameters that generalize beyond the dataset used for model training. AI / ML model testing A subprocess of training, to evaluate the performance of a final AI / ML model using a dataset different from one used for model training and validation. Differently from AI / ML model validation, testing does not assume subsequent tuning of the model. UE-side (AI / ML) model An AI / ML Model whose inference is performed entirely at the UE Network-side (AI / ML) model An AI / ML Model whose inference is performed entirely at the network One-sided (AI / ML) model A UE-side (AI / ML) model or a Network-side (AI / ML) model Two-sided (AI / ML) model A paired AI / ML Model(s) over which joint inference is performed, where joint inference comprises AI / ML Inference whose inference is performed jointly across the UE and the network, i.e, the first part of inference is firstly performed by UE and then the remaining part is performed by gNB, or vice versa. AI / ML model transfer Delivery of an AI / ML model over the air interface, either parameters of a model structure known at the receiving end or a new model with parameters. Delivery may contain a full model or a partial model. Model monitoring A procedure that monitors the inference performance of the AI / ML model RAN1#110bis-e Agreements Study AI / ML model monitoring for at least the following purposes: model activation, deactivation, selection, switching, fallback, and update (including re-training). Study at least the following metrics / methods for AI / ML model monitoring in lifecycle management per use case: Monitoring based on inference accuracy, including metrics related to intermediate KPIs i. Monitoring based on system performance, including metrics related to system performance KPIs ii. Other monitoring solutions, at least following 2 options. • Monitoring based on data distribution a) Input-based: e.g., Monitoring the validity of the AI / ML input, e.g., out-of-distribution detection, drift detection of input data, or something simple like checking SNR, delay spread, etc. b) Output-based: e.g., drift detection of output data • Monitoring based on applicable condition Note: Model monitoring metric calculation may be done at NW or UE RAN1#113 Agreements: Consider at least the following aspects and if applicable, the corresponding potential specification impact related to data collection: Measurement configuration and reporting Contents, type and format of data including: o Data related to model input o Data related to ground truth o Quality of the data o Other information Signaling of assistance information for categorizing the data o Note: The study should consider the feasibility of disclosure of proprietary information Signaling for data collection procedure Note 1: Use-case specific details can be studied in respective agenda items Note 2: Signaling mechanism details can be studied by appropriate working groups. 2.1.2 Remaining Open issues • Complete AI / ML model, terminology and description to identify common and specific characteristics for framework investigations: । o Characterize lifecycle management of AI / ML model: e.g., model training, model deployment, model inference, model monitoring, model updating o Dataset(s) for training, validation, testing, and inference o Identify common notation and terminology for AI / ML related functions, procedures 5 and interfaces • Evaluate performance benefits of AI / ML based algorithms for the agreed use cases in the final representative set • Assess potential specification impact, specifically for the agreed use cases in the final representative set and for a common framework: 10 o PHY layer aspects, e.g., (RAN1) • Consider aspects related to, e.g., the potential specification of the Al Model lifecycle management, and dataset construction for training, validation and test for the selected use cases • Use case and collaboration level specific specification impact, such as new 15 signalling, means for training and validation data assistance, assistance information, measurement, and feedback Appendix II (RAN2 Study Item on AI / ML for NR Air Interface) RAN2#121 agreement: => Agreed: Aim to at least analyze the feasibility and benefits of model / transfer solutions based on the following: Solution 1a: gNB can transfer / deliver AI / ML model(s) to UE via RRC signalling. Solution 2a: CN (except LMF) can transfer / deliver AI / ML model(s) to UE via NAS signalling. Solution 3a: LMF can transfer / deliver AI / ML model(s)to UE via LPP signalling. Solution 1b: gNB can transfer / deliver AI / ML model(s) to UE via UP data. Solution 2b: CN (except LMF) can transfer / deliver AI / ML model(s) to UE via UP data. Solution 3b: LMF can transfer / deliver AI / ML model(s)to UE via UP data. Solution 4: Server (e.g. OAM, OTT) can transfer / delivery AI / ML model(s) to UE (e.g. transparent to 3GPP). RAN2#122 agreements: Related to data collection, the following was agreed: • RAN 2 assumes that for the data collection in some scenarios (e.g., internal data up to implementation or the existing data are enough), possibly no RAN2 specification effort is needed in some scenarios, e.g. (not exhaustive): o For model inference of UE-sided model, input data for model inference is available inside the UE. o For UE-side (real time) monitoring of UE-sided model, performance metrics are available inside the UE. UE can independently monitor a model's performance without any data input from NW. • For the latency requirement of data collection, RAN2 assumes: o for all types of offline model training (i.e., UE- / NW- / two-sided model training), there is no latency requirement for data collection o for model inference, when required data comes from other entities, there is a latency requirement for data collection o for model monitoring, when required monitoring data (e.g., performance metric) comes from the other entities, there is a latency requirement for data collection. • RAN2 assumes that the analysis / selection of the data collection frameworks should focus on the RRC_CONNECTED state (for both data generation and reporting). Analysis and potential enhancement on the non-connected state can be revisited when needed. • For the data generation entity and termination entity deployed at different entities, RAN2 assumes: o For CSI enhancement and beam management use cases: ■ For model training, training data can be generated by UE / gNB and terminated at gNB / OAM / OTT server ■ For NW-sided model inference, input data can be generated by UE and terminated at gNB. ■ For UE-side model inference, input data / assistance information can be generated by gNB and terminated at UE. ■ For model monitoring at NW side, performance metrics can be generated by UE and terminated at gNB. o For positioning enhancement use case: ■ For model training, training data can be generated by UE / gNB and terminated at LMF / OTT server ■ For NW-sided model inference, input data can be generated by UE / gNB and terminated at LMF and / or gNB ■ For UE-side model inference, input data / assistance information can be generated by LMF / gNB and terminated at the UE ■ For model monitoring at NW side, performance metrics can be generated by UE / gNB and terminated at LMF. Related to data collection, RAN2 has also agreed to send an LS to RAN1 in R2-2306906, asking RAN1 to express concerns (if any) on the above assumption, and to provide additional information (if any) on the above discussed topics. Additionally, RAN2 asks RAN1 to provide inputs on the following: • The required data content per use case and per LCM purpose, when available, and to what extent said data would I should be specified (in detail). • The reporting type (e.g., periodic, event triggered, other) of the identified data content • The typical size (value or value range) of the identified data content. • The typical latency requirement (value or value range) to transfer the identified data content. Related to architectural discussion, the following was agreed: • RAN2 will cover functional architecture in general, e.g. covering both be model based and / or functionality based LCM • Figure 2 is R2-2305327 capturing architectural aspects is agreed with the following assumptions: o “Model Storage” in the figure is only intended as a reference point (if any) for protocol terminations etc for model transfer / delivery etc. It is not intended to limit where models are actually stored. Add a note for this. o Remove “Model” in Model Managemt and Model Inference and for the actions / the arrow form Management to Inference (to reduce the risk for misunderstanding). o Management may be model based management, or functionality based management. RAN2#121bis agreements: • Study the applicability (and limitations) of each identified data collection framework for each of the identified LCM purposes, i.e., inference, monitoring and (offline) training. FFS how we do the formatting / presentation of the results. • With more progress on architectural discussion, consider the suitability of each identified data collection framework for the termination points and mapping with the location of LCM purposes / functions (inference, monitoring, (offline) training) considering: - Model sidedness (UE side, NW side, two sided) FFS - Use case mapping FFS Remaining Open issues Based on what was discussed during RAN2#122 the following are the open issues: • Architecture; functionality-to-entity mapping, • Life Cycle Management implications from a RAN2 point of view, • Progress with data collection, including suitability analysis of identified collection frameworks, taking into account model sidedness (i.e. UE-sided, NW-sided), the LCM function, and the consumer of the data collection (e.g. UE, gNB, CAM, OTT server). Reflect such analysis in the previously endorsed table. • Continue discussion on model ID handling, and model transfer / delivery Appendix III (RAN3 Work Item on AI / ML for NG-RAN) RAN3#117bis-e agreements: Procedures used for AI / ML support in the NG-RAN shall be use case agnostic. Legacy information that are used to support AI / ML are transferred via existing legacy procedures (no need to signal them via other procedures) RAN3 will focus on non-split architecture use cases and procedures first and discuss split architecture use cases and procedures when completion for the nonsplit architecture use cases and procedures is achieved. Signalling describing the capability to support specific information predictions used for AI / ML is not pursued in this release Signalling describing the capability to supports specific AI / ML use cases is not pursued in this release AI / ML capability exchange in NG-RAN can be achieved by means of procedures for AI / ML information request, AI / ML information response and AI / ML Information Request Failure WA: Solutions for AI / ML information exchange over the NG interface are not considered as part of Rel18. Xn interface: Introduce a new Class 1 procedure for initiating the reporting of AI / ML Related Information and a Class 2 procedure for Data Reporting of AI / ML Related Information. Reporting options for the new procedure used for AI / ML Related Information to be evaluated on a case-by-case basis. Possible reporting options are one-time and periodic reporting. The new procedure is non-UE associated procedure. If needed, the procedure can be used to capture UE-associated information. The response message of the new procedure for AI / ML Related Information indicates if the requested information can be provided. Support the following UE performance information to be sent for feedback purposes: Average Packet Delay, Average UE Throughput DL, Average UE Throughput UL, Average Packet Error Rate. How to indicate validity time (e.g., implicitly with a new prediction when the previous prediction becomes invalid, explicitly with every prediction in the AI / ML output or by the request to the prediction) shall be discussed on a case by case basis. RAN3#118 agreements WA: Procedures used for AI / ML support in the NG-RAN shall be “data type agnostic”. Xn interface: The request in the new Class 1 procedure for initiating the reporting of AI / ML Related Information can include an ID assigned by the requesting NG-RAN node to request for reporting, which includes the reporting parameters 5 - list of cells to report reporting periodicity The response in the new Class 1 procedure for initiating the reporting of AI / ML Related Information can include an ID assigned by the responding NG-RAN node which includes the confirmation on the reporting parameters requested. 10 The message in the Class 2 procedure for Data Reporting of AI / ML Related Information can include the corresponding IDs assigned by the NG-RAN nodes, reports result. The "Energy Efficiency" metric should be measurable, produced and interpretable by the RAN. Start with per node granularity EE and Per cell granularity EE could be considered if it is 15 feasible. WA: Take the EE defined in SA5 as the baseline for the energy efficiency of a gNB. What to be transfered between NG-RAN nodes is FFS. UE Trajectory Prediction is transferred to the target gNB via the Handover Request. Appendix IV (reference to SDAP parameters in TS 37.324 [5]) 6.3 Parameters 6.3.1 General If not otherwise mentioned in the definition of each field, then the bits in the parameters shall be interpreted as follows: the left most bit is the first and most significant bit and the right most bit is the last and least significant bit. Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases the bits appear ordered from MSB to LSB when read in the PDU. 6.3.2 Data Length: Variable This field includes the SDAP SDU. 6.3.3 D / C Length: 1 bit, The D / C bit indicates whether the SDAP PDU is an SDAP Data PDU or an SDAP Control PDU. Table 6.3.3-1: D / C field Bit Description 0 Control PDU 1 Data PDU 6.3.4 QFI Length: 6 bits The QFI field indicates the ID of the QoS flow (TS 23.501 [4]) to which the SDAP PDU belongs. 6.3.5 R Length: 1 bit Reserved. In this version of the specification reserved bits shall be set to 0. Reserved bits shall be ignored by the receiver. 6.3.6 RQI Length: 1 bit, The RQI bit indicates whether NAS should be informed of the updated of SDF to QoS flow mapping rules (TS 23.501 [4]). Table 6.3.6-1: RQI field Bit Description 0 No action 1 To inform NAS that RQI bit is set to 1.

Claims

1. A method of managing AI / ML data within a telecommunication system, comprising a network and a User Equipment, UE, wherein said AI / ML data is explicitly identified as such by means of the provision of one or more of explicit signalling and the provision of assistance information, allowing a particular system entity to recognise the AI / ML data and to process it accordingly.

2. The method of claim 1 wherein the explicit signalling comprises NAS or RRC signalling from the network to the UE.

3. The method of claim 1 or 2 wherein the assistance information comprises one or more of timestamp, location, data session ID, data purpose, reason for data update, data version number and last update.

4. A method of using a User Plane, UP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network, wherein the AI / ML data is carried by means of at least one of:• A Local Area Data Network, LADN; and• Service Data Adaptation Protocol, SDAP.

5. The method of claim 4 wherein if the AI / ML data is carried by means of SDAP, there is an SDAP entity configured for each LADN PDU session for AI / ML data6. A method of using a Control Plane, CP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network, wherein either:• a dedicated Network Function, NF, is provided to host the AI / ML data and a specific NAS message is provided for this purpose; or• AI / ML data is exchanged via the Session Management Function, SMF, via the use of a UL / DL NAS TRANSPORT message.

7. The method of any preceding claim wherein the UE and network exchange capabilityinformation regarding one or more supported techniques for exchanging AI / ML data.

8. Apparatus arranged to perform the method of any preceding claim.

Images