Method and apparatus for support of data transfer via user plane connection in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. According to an example, there is provided a method of a first network function (NF) in a wireless communications network, the method comprising: based on determining whether to request user equipment (UE)-side data for artificial intelligence (AI) / machine learning (ML) model training, transmitting a request for collecting AI / ML data to a UE; receiving, via a secured user plane (UP) connection, data for AI / ML model training transferred from the UE; and notifying at least a portion of the data for AI / ML model training to an AI / ML server.

Description

METHOD AND APPARATUS FOR SUPPORT OF DATA TRANSFER VIA USER PLANE CONNECTION IN A WIRELESS COMMUNICATION SYSTEM

[0001] Certain examples of the present disclosure relate to methods, apparatus and / or systems for AI / ML related data collection and / or transfer from UE to AI / ML server via user plane (UP). In various examples, the data collection and / or transfer is with network controllability and / or visibility. Various examples relate to options or configurations for data flow path of UE-side AI / ML data transfer via UP. Various examples describe AI / ML data routing by UPF, e.g. for AI / ML data from a UE. Various examples describe functionality of a termination entity inside CN, which may perform various functions in support of AI / ML data collection and / or transfer operations.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] Embodiments of the present disclosure is to provide an apparatus and method for effectively providing a service in a wireless communication system.

[0009] 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.

[0010] In an embodiment, a method performed by a user equipment (UE) in a wireless communication system is provided. The method includes: receiving, from a data collection function (DCF), a data collection request; performing data collection for artificial intelligence and machine learning (AIML) model training based on the data collection request; initiating a user plane connection establishment for a data transfer via a user plane; and transferring, to the DCF, AIML data associated with the data collection for the AIML model training via the user plane.

[0011] In an embodiment, a method performed by a data collection function (DCF) in a wireless communication system is provided. The method includes: transmitting, to a user equipment (UE), a data collection request; receiving, from the UE, artificial intelligence and machine learning (AIML) data collected based on the data collection request for AIML model training; and transmitting, to an AIML server, the AIML data for the AIML model training, wherein the AIML data are received via a user plane that is established based on a user plane connection establishment initiated by the UE.

[0012] In an embodiment, a user equipment (UE) in a wireless communication system is provided. The UE includes at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the UE to receive, from a data collection function (DCF), a data collection request, perform data collection for artificial intelligence and machine learning (AIML) model training based on the data collection request, initiate a user plane connection establishment for a data transfer via a user plane, and transfer, to the DCF, AIML data associated with the data collection for the AIML model training via the user plane.

[0013] In an embodiment, a data collection function (DCF) in a wireless communication system is provided. The DCF includes at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the DCF to transmit, to a user equipment (UE), a data collection request, receive, from the UE, artificial intelligence and machine learning (AIML) data collected based on the data collection request for AIML model training, and transmit, to an AIML server, the AIML data for the AIML model training, wherein the AIML data are received via a user plane that is established based on a user plane connection establishment initiated by the UE.

[0014] According to a first aspect of the disclosure, there is provided a method of a first network function (NF) in a wireless communications network, the method comprising: based on determining whether to request user equipment (UE)-side data for artificial intelligence (AI) / machine learning (ML) model training, transmitting a request for collecting AI / ML data to a UE; receiving, via a secured user plane (UP) connection, data for AI / ML model training transferred from the UE; and notifying at least a portion of the data for AI / ML model training to an AI / ML server.

[0015] According to an example, the method further comprises: receiving, from the AI / ML server, a request for the UE-side data for AI / ML model training; wherein the first NF determines whether to request the UE-side data based on the request from the AI / ML server.

[0016] According to an example, the request for the UE-side data is a subscription request from the AI / ML server.

[0017] According to an example, the request for the UE-side data comprises one or more of: a purpose of data collection, AI / ML operation type, use case or scenario, type of data to be collected and / or transferred, requirements on data collection, potential size or volume of data transfer, or required timing information for the data collection or transfer.

[0018] According to an example, the method further comprises: if the secured UP connection is not established, establishing the secured UP connection with the UE.

[0019] According to an example, establishing the secured UP connection comprises: transmitting, to the UE via a second NF, UP information; and receiving, from the UE via the second NF, an indication that the secured UP connection is successfully established.

[0020] According to an example, the UP information comprises one or more of: a UP address of the first NF, a first identifier for associating the secured UP connection with a second identifier for identifying the UE, or the second identifier.

[0021] According to an example, the first identifier is a AI / ML data collection binding / correlation ID, and / or the second identifier is a Subscription Permanent Identifier (SUPI) and / or a Generic Public Subscription Identifier (GPSI) of the UE.

[0022] According to an example, the data for AI / ML model training is received via the secured UP connection with the first identifier.

[0023] According to an example, the method further comprises: triggering the establishing of the secured UP connection.

[0024] According to an example, the method further comprises: filtering the received data for AI / ML model training based on user consent and / or operator's policies to obtain the portion of the data for AI / ML model training.

[0025] According to an example, the method further comprises: determining to terminate the AI / ML data collecting or the data transferring, or terminating the AI / ML data collecting or the data transferring based on an indication from the UE or the AI / ML server.

[0026] According to an example, determining to terminate the AI / ML data collecting or the data transferring is based on: controllability requirements, privacy consideration, network / UE load, network congestion, network performance degradation, lack of resources, or network configuration relating to first NF.

[0027] According to a second aspect of the disclosure, there is provided a method of a user equipment (UE) in a wireless communications network, the method comprising: receiving, from a first network function (NF), a request for collecting artificial intelligence (AI) / machine learning (ML) data; based on the request, collecting data for AI / ML model training; and transferring, via a secured user plane (UP) connection, the data for AI / ML mode training to the first NF.

[0028] According to an example, the method further comprises: determining to terminate the AI / ML data collecting or the data transferring, or terminating the AI / ML data collecting or the data transferring based on an indication from the first NF.

[0029] According to an example, determining to terminate the AI / ML data collecting or the data transferring is based on: a battery level of the UE, the UE being out of an area of interest of the data collection, the UE being overloaded, the UE determining to leave an AI / ML procedure relating to the data collection, or the UE not being interested in a service corresponding to the data collection.

[0030] According to an example, the method further comprises: if the secured UP connection is not established, establishing the secured UP connection with the first NF.

[0031] According to an example, the method further comprises: if the secured UP connection is not established, triggering establishing of the secured UP connection.

[0032] According to an example, establishing the secured UP connection comprises: transmitting, to a second NF, a UP establishment request with an indication of AI / ML data transfer; and receiving, from the first NF via the second NF, UP information.

[0033] According to an example, establishing the secured UP connection comprises: transmitting, to the first NF via the second NF, an indication of success of establishing the secured UP connection; and / or if there is no established applicable protocol data unit (PDU) session for transferring the data via UP, establish a PDU session for transferring the data via UP based on a UE route selection policy (URSP) including UP AI / ML data transfer related PDU session parameters; and / or if the request for collecting AI / ML data includes an address or identifier of the first NF, transmitting an indication of the address or identifier of the first NF to the second NF.

[0034] According to a third aspect of the disclosure, there is provided a method of an artificial intelligence (AI) / machine learning (ML) server in a wireless communications network, the method comprising: determining to request UE-side data for AI / ML model training; transmitting, to a first network function (NF), a request for UE side data for AI / ML model training; and receiving, from the first NF, UE-side data for AI / ML model training.

[0035] According to an example, the request for the UE-side data is a subscription request sent to the first NF.

[0036] According to an example, the request for UE side data for AI / ML model training comprises one or more of: a purpose of data collection, AI / ML operation type, use case or scenario, type of data to be collected and / or transferred, requirements on data collection, potential size or volume of data transfer, or required timing information for the data collection or transfer.

[0037] According to a fourth aspect of the disclosure, there is provided one or more network entity configured to perform the method of the first aspect or according to any one of the examples relating to the first aspect.

[0038] According to a fifth aspect of the disclosure, there is provided a UE configured to perform the method of the second aspect or according to any one of the examples relating to the second aspect.

[0039] According to a sixth aspect of the disclosure, there is provided a server configured to perform the method of the third aspect or according to any one of the examples relating to the third aspect.

[0040] According to a seventh aspect of the disclosure, there is provided a computer-readable storage medium storing instructions which, when executed by at least one processor of at least one electronic device, cause the at least one electronic device to perform a method according to any one of the first aspect, the examples related to the first aspect, the second aspect, the examples related to the second aspect, the third aspect or the examples related to the third aspect.

[0041] According to an eighth aspect of the disclosure, there is provided a network comprising one or more network entity according to the fourth aspect, a UE according to the fifth aspect and a server according to the sixth aspect.

[0042] Various examples of the present disclosure provide computer-readable storage medium configured to store instructions which, when executed by at least one processor or a computer, cause the at least one processor or the computer to perform (or assist in performing) a method according to one or more of the examples, aspects, embodiments etc. described herein.

[0043] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.

[0044] Embodiments of the present disclosure provides an apparatus and method for effectively providing a service in a wireless communication system.

[0045] Embodiments / examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which:

[0046] Figure 1 is a schematic illustration of QoS architecture, corresponding to figure 12-1 of TS 38.300.

[0047] Figure 2 is a schematic illustration of an AI / ML-specific data transfer option according to various examples.

[0048] Figure 3 is a schematic illustration of an AI / ML-specific data transfer option according to various examples.

[0049] Figure 4 is a schematic illustration of a configuration for AI / ML data transfer via UP according to various examples of the present disclosure.

[0050] Figure 5 is a schematic illustration of a configuration for AI / ML data transfer via UP according to various examples of the present disclosure.

[0051] Figure 6 is a schematic illustration of a configuration for AI / ML data transfer via UP according to various examples of the present disclosure.

[0052] Figure 7 is a call flow diagram illustrated a method according to various examples of the present disclosure.

[0053] Figure 8 is a call flow diagram illustrating a method according to various examples of the present disclosure.

[0054] Figure 9 is a call flow diagram illustrating a method according to various examples of the present disclosure.

[0055] Figure 10 is a block diagram illustrating an example structure of an entity in accordance with certain examples of the present disclosure.

[0056] Figure 11 is a flow diagram illustrating a method according to an example of the disclosure.

[0057] Figure 12 is a flow diagram illustrating a method according to an example of the disclosure.

[0058] Figure 13 is a flow diagram illustrating a method according to an example of the disclosure.

[0059] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. 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 or disclosure.

[0060] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0061] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

[0062] 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 disclosure.

[0063] Throughout the description 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.

[0064] Throughout the description 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.

[0065] Throughout the description, the expression "at least one of A, B and / or C" (or the like), the expression "and / or", and the expression "one or more of A, B and / or C" (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C.

[0066] Throughout the description 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.

[0067] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment or example are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith.

[0068] Certain examples of the present disclosure relate to methods, apparatus and / or systems for AI / ML related data collection and / or transfer from UE to AI / ML server via user plane (UP). In various examples, the data collection and / or transfer is with network controllability and / or visibility, e.g. via decoding or decrypting the transferred data. Various examples relate to options or configurations for data flow path of UE-side AI / ML data transfer via UP. Various examples describe AI / ML data routing by UPF, e.g. for AI / ML data from a UE. Various examples describe functionality of a termination entity inside CN, which may perform various functions in support of AI / ML data collection and / or transfer operations.

[0069] The following examples are applicable to, and use terminology associated with, 3GPP 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, 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. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G NR or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other 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, operation or purpose within the network. In particular, the following disclosure should be considered at least in relation to 6G also, which is expected to use at least part of the 5G architecture, or equivalent, and to which the present disclosure also relates.

[0070] 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.

[0071] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example:

[0072] * The techniques disclosed herein are not limited to 3GPP 5G, B5G or 6G.

[0073] * 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.

[0074] * 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.

[0075] * One or more further elements, entities and / or messages may be added to the examples disclosed herein.

[0076] * One or more non-essential elements, entities and / or messages may be omitted in certain examples.

[0077] * 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.

[0078] * 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.

[0079] * Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.

[0080] * Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.

[0081] * The order in which operations are performed may be modified, if possible, in alternative examples.

[0082] * The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.

[0083] 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. Such an apparatus / device / network entity 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). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0084] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[0085] A network according to one or more of the examples disclosed herein may include one or more of a Network Data Analytics Function (NWDAF) entity, an Access and Mobility Management Function (AMF) entity, a Session Management Function (SMF) entity, a Network Slice Selection Function (NSSF) entity, a Network Repository Function (NRF) entity, Application Function (AF) entity, and an Operation and Maintenance (OAM) entity. The network may include one or more Service Consumers (including one or more of the entities mentioned above and / or one or more other entities) that receive analytics from NWDAF. The skilled person will appreciate that a network may omit one or more of the entities mentioned above and / or may comprise one or more additional entities

[0086] As described above, the existing 5G NR User Plane (UP) mechanism cannot support the fully / partial data visibility at CN or OAM; only the OTT server is able to decrypt the data transferred over UP from UE(s). Fully / partial data controllability also cannot be supported without enhancement. Therefore, enhancement to 5GS is required to support UE data transfer over UP with network controllability and visibility.

[0087] To this end, various examples of the present disclosure include procedures (i.e. methods) and apparatus, entities etc. to provide such enhancement(s). That is, various embodiments of the present disclosure provide methods for supporting UE data transfer over UP with network visibility and / or controllability. An example of such an apparatus is a 1sttermination NF / entity as described in various examples herein.

[0088] The content of the following documents is referred to below and / or their content provides background information that the following disclosure should be considered in the context of:

[0089] [1] 3GPP TS 23.501 - 5G; System architecture for the 5G System (5GS), Release 18 (e.g. v18.8.0).

[0090] [2] 3GPP TS 38.300 - 5G; NR; NR and NG-RAN Overall description; Stage-2, Release 18 (e.g. v18.4.0).

[0091] [3] 3GPP RP-221348, Revised SID: Study on Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface.

[0092] [4] 3GPP TR 22.850 - Study on 3GPP AI / ML Consistency Alignment.

[0093] [5] 3GPP RP-234039, New WID on Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface.

[0094] [6] 3GPP RP-243245, New SID: Study on Artificial Intelligence (AI) / Machine Learning (ML) for NR air interface Phase 2.

[0095] [7] 3GPP RP-243244, Revised WID: Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface

[0096] [8] 3GPP TR 38.843 - Study on Artificial Intelligence (AI) / Machine Learning (ML) for NR air interface.

[0097] [9] 3GPP S2-2409600, LS on AIML data collection.

[0098]

[0010] 3GPP RP-242389, LS on AIML data collection.

[0099]

[0011] 3GPP S2-2411191, LS RP-242389 (S2-2409600) LS on AIML data collection.

[0100]

[0012] 3GPP SP-241441, LS RP-242389 (S2-2409600) LS on AIML data collection.

[0101]

[0013] 3GPP SP-241575, Reply LS on AIML data collection.

[0102]

[0014] 3GPP S2-2412726, LS RP-242389 (S2-2411455) LS on AIML data collection.

[0103]

[0015] 3GPP S2-2411455, LS on AIML data collection.

[0104]

[0016] 3GPP S2-2500025, Reply LS to SA2 on AIML data collection.

[0105]

[0017] 3GPP S2-2412621, Reply LS to SA2 on AIML data collection.

[0106]

[0018] 3GPP R2-2411152, Reply LS to SA2 on AIML data collection.

[0107]

[0019] 3GPP S2-2501372, LS on AI / ML UE sided data collection.

[0108]

[0020] 3GPP S2-2500055, LS on AI / ML UE sided data collection.

[0109]

[0021] 3GPP RP-243316, LS on AI / ML UE sided data collection.

[0110]

[0022] 3GPP SP-250068, New SID on Core Network Enhanced Support for Artificial Intelligence (AI) / Machine Learning (ML) Phase 2.

[0111]

[0023] 3GPP S2-2502788, New SID on Core Network Enhanced Support for Artificial Intelligence (AI) / Machine Learning (ML)_Ph2.

[0112] Note: indicated version numbers are provided for illustrative purposes, other (including future) versions of these documents are considered also.

[0113] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3rdGeneration Partnership Project (3GPP) design, specify and standardise technologies for mobile wireless communication networks. Fourth Generation (4G) and Fifth Generation (5G) systems (5GS) are now widely deployed, while beyond 5G (B5G) and 6G systems are being considered.

[0114] 3GPP standards for 4G systems include an Evolved Packet Core (EPC) and an Enhanced-UTRAN (E-UTRAN: an Enhanced Universal Terrestrial Radio Access Network). The E-UTRAN uses Long Term Evolution (LTE) radio technology. LTE is commonly used to refer to the whole system including both the EPC and the E-UTRAN, and LTE is used in this sense in the remainder of this document. LTE should also be taken to include LTE enhancements such as LTE Advanced and LTE Pro, which offer enhanced data rates compared to LTE.

[0115] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies B5G systems, such as 6G, are currently being considered and developed, and are expected to at least partly build on 5G systems.

[0116] New frameworks and architectures are being developed as part of 5G network (and beyond, such as 6G networks) in order to increase the range of functionality and use cases available through 5G networks. One such new framework is the use of artificial intelligence / machine learning (AI / ML, or AIML), which may be used for the optimisation of the operation of 5G networks.

[0117] In AI / ML operation, AI / ML models and / or data might be transferred across the AI / ML applications (e.g., application functions (AFs)), 5GC (5G core), UEs (user equipments) etc.). Without limitation, the AI / ML works could be divided into two main phases: model training and inference. During model training and inference, multiple rounds of interaction may be required.

[0118] In Section 6.40 ('AI / ML model transfer in 5GS') in TS 22.261 [1], three types of AI / ML operations to be supported in (at least) Release 18 and / or Release 19 are described as follows:

[0119] A) AI / ML operation splitting between AI / ML endpoints

[0120] The AI / ML operation / model is split into multiple parts according to the current task and environment. The intention is to offload the computation-intensive, energy-intensive parts to network endpoints, whereas 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.

[0121] B) AI / ML model / data distribution and sharing over 5G system

[0122] Multi-functional mobile terminals might need to switch the AI / ML model in response to task and environment variations. The condition of adaptive model selection is that the models to be selected are available for the mobile device. However, given the fact that the AI / ML models are becoming increasingly diverse, and with the limited storage resource in a UE, it can be determined to not pre-load all candidate AI / ML models on-board. Online model distribution (i.e. new model downloading) is needed, in which an AI / ML model can be distributed from a 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 needs to be monitored constantly.

[0123] C) Distributed / Federated Learning over 5G system

[0124] The cloud server trains a global model by aggregating local models partially-trained by each end devices. Within each training iteration, a UE performs the training based on the model downloaded from the AI server using the local training data. Then the UE reports the interim training results to the cloud server 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.

[0125] 1.1 NR user plane (UP)

[0126] As documented in TS 23.501 [1]:

[0127] * The 5GC supports a PDU Connectivity Service i.e. a service that provides exchange of PDUs between a UE and a data network identified by a DNN. The PDU Connectivity Service is supported via PDU Sessions that are established upon request from the UE.

[0128] * The expectation is that the URSP in the UE is always up to date using the procedure defined in clause 4.16.12.2 of TS 23.502 and therefore the UE requested DNN will be up to date.

[0129] * Each PDU Session supports a single PDU Session type i.e. supports the exchange of a single type of PDU requested by the UE at the establishment of the PDU Session. The following PDU Session types are defined: IPv4, IPv6, IPv4v6, Ethernet, Unstructured.

[0130] * PDU Sessions are established (upon UE request), modified (upon UE and 5GC request) and released (upon UE and 5GC request) using NAS SM signalling exchanged over N1 between the UE and the SMF. Upon request from an Application Server, the 5GC is able to trigger a specific application in the UE. When receiving that trigger message, the UE shall pass it to the identified application in the UE. The identified application in the UE may establish a PDU Session to a specific DNN.

[0131] * Within the 5GS, a QoS Flow is controlled by the SMF and may be preconfigured, or established via the PDU Session Establishment procedure (see clause 4.3.2 of TS 23.502), or the PDU Session Modification procedure (see clause 4.3.3 of TS 23.502). The QoS architecture is shown in Figure 1 (corresponding to Figure 12-1 of TS 38.300 [2]).

[0132] * The 5G QoS model is based on QoS Flows. The 5G QoS model supports both QoS Flows that require guaranteed flow bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (Non-GBR QoS Flows).

[0133] 1.2 AI / ML related items in 3GPP RAN working groups

[0134] 3GPP RAN working groups started to work on Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface since Release 18. The objectives for the SI were documented in RP-221348 [3] and listed below. The outcome of the study item was documented in TR 38.843 [4].

[0135] Study the 3GPP framework for AI / ML for air-interface corresponding to each target use case regarding aspects such as performance, complexity, and potential specification impact.

[0136] Use cases to focus on:

[0137] * Initial set of use cases includes:

[0138] ** CSI feedback enhancement, e.g., overhead reduction, improved accuracy, prediction [RAN1]

[0139] ** Beam management, e.g., beam prediction in time, and / or spatial domain for overhead and latency reduction, beam selection accuracy improvement [RAN1]

[0140] ** Positioning accuracy enhancements for different scenarios including, e.g., those with heavy NLOS conditions [RAN1]

[0141] * Finalize representative sub use cases for each use case for characterization and baseline performance evaluations by RAN#98

[0142] ** The AI / ML approaches for the selected sub use cases need to be diverse enough to support various requirements on the gNB-UE collaboration levels

[0143] Note: the selection of use cases for this study solely targets the formulation of a framework to apply AI / ML to the air-interface for these and other use cases. The selection itself does not intend to provide any indication of the prospects of any future normative project.

[0144] AI / ML model, terminology and description to identify common and specific characteristics for framework investigations:

[0145] * Characterize the defining stages of AI / ML related algorithms and associated complexity:

[0146] ** Model generation, e.g., model training (including input / output, pre- / post-process, online / offline as applicable), model validation, model testing, as applicable

[0147] ** Inference operation, e.g., input / output, pre- / post-process, as applicable

[0148] * Identify various levels of collaboration between UE and gNB pertinent to the selected use cases, e.g.,

[0149] ** No collaboration: implementation-based only AI / ML algorithms without information exchange [for comparison purposes]

[0150] ** Various levels of UE / gNB collaboration targeting at separate or joint ML operation.

[0151] * Characterize lifecycle management of AI / ML model: e.g., model training, model deployment, model inference, model monitoring, model updating

[0152] * Dataset(s) for training, validation, testing, and inference

[0153] * Identify common notation and terminology for AI / ML related functions, procedures and interfaces

[0154] * Note: Consider the work done for FS_NR_ENDC_data_collect when appropriate

[0155] For the use cases under consideration:

[0156] 1) Evaluate performance benefits of AI / ML based algorithms for the agreed use cases in the final representative set:

[0157] ** Methodology based on statistical models (from TR 38.901 and TR 38.857 [positioning]), for link and system level simulations.

[0158] *** Extensions of 3GPP evaluation methodology for better suitability to AI / ML based techniques should be considered as needed.

[0159] *** Whether field data are optionally needed to further assess the performance and robustness in real-world environments should be discussed as part of the study.

[0160] *** Need for common assumptions in dataset construction for training, validation and test for the selected use cases.

[0161] *** Consider adequate model training strategy, collaboration levels and associated implications

[0162] *** Consider agreed-upon base AI model(s) for calibration

[0163] *** AI model description and training methodology used for evaluation should be reported for information and cross-checking purposes

[0164] ** KPIs: Determine the common KPIs and corresponding requirements for the AI / ML operations. Determine the use-case specific KPIs and benchmarks of the selected use-cases.

[0165] *** Performance, inference latency and computational complexity of AI / ML based algorithms should be compared to that of a state-of-the-art baseline

[0166] *** Overhead, power consumption (including computational), memory storage, and hardware requirements (including for given processing delays) associated with enabling respective AI / ML scheme, as well as generalization capability should be considered.

[0167] 2) Assess potential specification impact, specifically for the agreed use cases in the final representative set and for a common framework:

[0168] ** PHY layer aspects, e.g., (RAN1)

[0169] *** Consider aspects related to, e.g., the potential specification of the AI Model lifecycle management, and dataset construction for training, validation and test for the selected use cases

[0170] *** Use case and collaboration level specific specification impact, such as new signalling, means for training and validation data assistance, assistance information, measurement, and feedback

[0171] ** Protocol aspects, e.g., (RAN2) - RAN2 only starts the work after there is sufficient progress on the use case study in RAN1

[0172] *** Consider aspects related to, e.g., capability indication, configuration and control procedures (training / inference), and management of data and AI / ML model, per RAN1 input

[0173] *** Collaboration level specific specification impact per use case

[0174] ** Interoperability and testability aspects, e.g., (RAN4) - RAN4 only starts the work after there is sufficient progress on use case study in RAN1 and RAN2

[0175] *** Requirements and testing frameworks to validate AI / ML based performance enhancements and ensuring that UE and gNB with AI / ML meet or exceed the existing minimum requirements if applicable

[0176] *** Consider the need and implications for AI / ML processing capabilities definition

[0177] Note 1: specific AI / ML models are not expected to be specified and are left to implementation. User data privacy needs to be preserved.

[0178] Note 2: The study on AI / ML for air interface is based on the current RAN architecture and new interfaces shall not be introduced.

[0179] RAN WGs started the normative work on Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface in Release 19. The WID was agreed as RP-234039 [5] with the following objectives:

[0180] * AI / ML general framework for one-sided AI / ML models within the realm of what has been studied in the FS_NR_AIML_Air project [RAN2]:

[0181] ** Signalling and protocol aspects of Life Cycle Management (LCM) enabling functionality and model (if justified) selection, activation, deactivation, switching, fallback

[0182] *** Identification related signalling is part of the above objective

[0183] ** Necessary signalling / mechanism(s) for LCM to facilitate model training, inference, performance monitoring, data collection (except for the purpose of CN / OAM / OTT collection of UE-sided model training data) for both UE-sided and NW-sided models

[0184] ** Signalling mechanism of applicable functionalities / models

[0185] * Beam management - DL Tx beam prediction for both UE-sided model and NW-sided model, encompassing [RAN1 / RAN2]:

[0186] ** Spatial-domain DL Tx beam prediction for Set A of beams based on measurement results of Set B of beams ("BM-Case1")

[0187] ** Temporal DL Tx beam prediction for Set A of beams based on the historic measurement results of Set B of beams ("BM-Case2")

[0188] ** Specify necessary signalling / mechanism(s) to facilitate LCM operations specific to the Beam Management use cases, if any

[0189] ** Enabling method(s) to ensure consistency between training and inference regarding NW-side additional conditions (if identified) for inference at UE

[0190] NOTE: Strive for common framework design to support both BM-Case1 and BM-Case2

[0191] * Positioning accuracy enhancements, encompassing [RAN1 / RAN2 / RAN3]:

[0192] ** Direct AI / ML positioning:

[0193] *** (1st priority) Case 1: UE-based positioning with UE-side model, direct AI / ML positioning

[0194] *** (2nd priority) Case 2b: UE-assisted / LMF-based positioning with LMF-side model, direct AI / ML positioning

[0195] *** (1st priority) Case 3b: NG-RAN node assisted positioning with LMF-side model, direct AI / ML positioning

[0196] ** AI / ML assisted positioning

[0197] *** (2nd priority) Case 2a: UE-assisted / LMF-based positioning with UE-side model, AI / ML assisted positioning

[0198] *** (1st priority) Case 3a: NG-RAN node assisted positioning with gNB-side model, AI / ML assisted positioning

[0199] ** Specify necessary measurements, signalling / mechanism(s) to facilitate LCM operations specific to the Positioning accuracy enhancements use cases, if any

[0200] ** Investigate and specify the necessary signalling of necessary measurement enhancements (if any)

[0201] ** Enabling method(s) to ensure consistency between training and inference regarding NW-side additional conditions (if identified) for inference at UE for relevant positioning sub use cases

[0202] * Core requirements for the above two use cases for AI / ML LCM procedures and UE features [RAN4]:

[0203] ** Specify necessary RAN4 core requirements for the above two use cases.

[0204] ** Specify necessary RAN4 core requirements for LCM procedures including performance monitoring.

[0205] Study objectives with corresponding checkpoints in RAN#105 (Sept '24):

[0206] * CSI feedback enhancement [RAN1]:

[0207] ** For CSI compression (two-sided model), further study ways to:

[0208] *** Improve trade-off between performance and complexity / overhead

[0209] **** e.g., considering extending the spatial / frequency compression to spatial / temporal / frequency compression, cell / site specific models, CSI compression plus prediction (compared to Rel-18 non-AI / ML based approach), etc.

[0210] *** Alleviate / resolve issues related to inter-vendor training collaboration.

[0211] while addressing other aspects requiring further study / conclusion as captured in the conclusions section of the TR 38.843.

[0212] ** For CSI prediction (one-sided model), further study performance gain over Rel-18 non-AI / ML based approach and associated complexity, while addressing other aspects requiring further study / conclusion as captured in the conclusions section of the TR 38.843 (e.g., cell / site specific model could be considered to improve performance gain).

[0213] * Necessity and details of model Identification concept and procedure in the context of LCM [RAN2 / RAN1]

[0214] * CN / OAM / OTT collection of UE-sided model training data [RAN2 / RAN1]:

[0215] ** For the FS_NR_AIML_Air study use cases, identify the corresponding contents of UE data collection

[0216] ** Analyse the UE data collection mechanisms identified during the FS_NR_AIML_Air (TR 38.843 section 7.2.1.3.2) study along with the implications and limitations of each of the methods

[0217] * Model transfer / delivery [RAN2 / RAN1]:

[0218] ** Determine whether there is a need to consider standardised solutions for transferring / delivering AI / ML model(s) considering at least the solutions identified during the FS_NR_AIML_Air study

[0219] * Testability and interoperability [RAN4]:

[0220] ** Finalize the testing framework and procedure for one-sided models and further analyse the various testing options for two-sided models, in collaboration with RAN1, and including at least:

[0221] *** Relation to legacy requirements

[0222] *** Performance monitoring and LCM aspects considering use-case specifics

[0223] *** Generalization aspects

[0224] *** Static / non-static scenarios / conditions and propagation conditions for testing (e.g., CDL, field data, etc.)

[0225] *** UE processing capability and limitations

[0226] *** Post-deployment validation due to model change / drift

[0227] ** RAN5 aspects related to testability and interoperability to be addressed on a request basis

[0228] NOTE: offline training is assumed for the purpose of this project.

[0229] NOTE: the outcome of the study objectives should be captured in TR 38.843 for future reference.

[0230] NOTE: Coordination with SA / SA WGs of the ongoing study / work as it may relate to their required work.

[0231] In December 2024, the Study objectives agreed in RP-234039 [5] were removed the agreed WID / SID and agreed as a new SID in RP-243245 [6] - Study on Artificial Intelligence (AI) / Machine Learning (ML) for NR air interface Phase 2. The remaining work items in RP-234039 [5] were agreed as an updated WID in RP-243244 [7] Revised WID: Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface.

[0232] 1.3 Analysis on RAN led topic - AI / ML for NR air interface

[0233] Use cases:

[0234] There are 3 major AI / ML use cases identified by RAN. The detailed scenarios / types of the 3 major uses were also discussed.

[0235] 1. CSI feedback enhancement,

[0236] A. CSI compression, e.g. Spatial-frequency domain CSI compression using two-sided AI model.

[0237] B. CSI prediction, e.g. Time domain CSI prediction using UE-side model.

[0238] 2. Beam management.

[0239] 3. Positioning accuracy enhancements for different scenarios.

[0240] Collaboration levels:

[0241] RAN also defined different collaboration levels between the UE and network for the use cases, as documented in 4.3 of TR 38.843, including:

[0242] * No collaboration: implementation-based only AI / ML algorithms without information exchange for comparison purposes.

[0243] * Various levels of UE / Network collaboration targeting at separate or joint ML operation.

[0244] The following Network-UE collaboration levels are considered as one aspect for defining collaboration levels:

[0245] 1. Level x: No collaboration.

[0246] 2. Level y: Signalling-based collaboration without model transfer. Note: this level includes cases without model delivery.

[0247] 3. Level z: Signalling-based collaboration with model transfer.

[0248] Level x / y boundary is understood such as Level x is implementation-based AI / ML operation without any dedicated AI / ML-specific enhancement (e.g., LCM related signalling, RS) collaboration between network and UE. (Note: The AI / ML operation may rely on future specification not related to AI / ML collaboration. The AI / ML approaches can be used as baseline for performance evaluation for future releases.)

[0249] Level y / z boundary is defined based on whether model delivery over the air interface is done in a non-transparent manner to 3GPP signalling. Note: procedures other than model transfer / delivery are decoupled with collaboration Level y-z.

[0250] [Table 1], corresponding to Table 4.3-1 of TR 38.843 [8] (see below), introduces different options for model delivery / transfer to UE, training location, and model delivery / transfer format combinations for UE-side models and UE-part of two-sided models.

[0251] Z2, Z3 and Z5 have been down prioritized in RAN1 Release 19.

[0252] The Model delivery / transfer cases can be found in [Table 1] below, corresponding to Table 4.3-1 of TR　38.843 [8].

[0253]

[0254] When a model of a known structure at UE (e.g., Case z4) is transferred from the Network, the new model being identified (e.g., via Type B2) has the same structure as a previously identified model at the Network and UE.

[0255] For model delivery / transfer to UE (for UE-side models and UE-part of two-sided models):

[0256] * Model delivery / transfer to UE, if feasible, may be beneficial to handle scenario / configuration specific (including site-specific configuration / channel conditions) models (i.e., when a single model cannot generalize well to multiple scenarios / configurations / sites), to reduce the device storage requirement.

[0257] * Model delivery / transfer to UE after offline compiling and / or testing may be friendlier from UE's implementation point of view compared to the case without offline compiling and / or testing. On the other hand, the case without offline compiling and / or testing (that can update parameter with known model structure), may have benefit at least in terms of shorter model parameter update timescale.

[0258] * Model transfer / delivery of an unknown structure at UE has more challenges related to feasibility (e.g. UE implementation feasibility) compared to delivery / transfer of a known structure at UE.

[0259] * For model trained at network side, Case y (w / NW-side training) and Case z2 may incur the burden of offline cross-vendor collaboration such as sending a model to the UE-side and / or compiling a model.

[0260] * For model trained at UE side / neutral site, Case z1 and Case z3 may incur the burden of offline cross-vendor collaboration to send the trained model from the UE-side to the network, compared to Case y (w / UE-side training) which does not have such burden.

[0261] * Model storage at the 3GPP network, compared to storing the model outside the 3GPP network, may come with 3GPP network side burden on model maintenance / storage.

[0262] * Proprietary design disclosure concern may arise from model training and / or model storage at the network side compared to other cases (such as case y with UE side training) which does not have such issue.

[0263] 1.3.1 CSI feedback enhancement

[0264] For CSI compression

[0265] The Spatial-frequency domain CSI compression requires two-sided AI model, the UE-part model is used for CSI generation and called encoder; meanwhile the NW-part model is used for CSI reconstruction and called decoder.

[0266] * UE-part of a two-sided CSI compression model = CSI generation part = encoder

[0267] * NW-part of a two-sided CSI compression model = CSI reconstruction part = decoder

[0268] For two-sided models, the inference will be performed at both UE and NW sides. As identified by RAN, there are different modes to perform model training of the two-sided model:

[0269] A. Type 1: Joint training of the two-sided model at a single side / entity, e.g., UE-sided or Network-sided.

[0270] B. Type 2: Joint training of the two-sided model at network side and UE side, respectively.

[0271] C. Type 3: Separate training at network side and UE side, where the UE-side CSI generation part and the NW-side CSI reconstruction part are trained by UE side and network side, respectively.

[0272] For CSI prediction

[0273] For the domain CSI prediction, normally the UE-side model is used. Therefore, in this case the inference will be performed at UE.

[0274] As documented in TR 38.843 [8], for CSI prediction use cases:

[0275] * For model training, training data can be generated by UE.

[0276] * For UE-side model inference, input data is internally available at UE.

[0277] * For performance monitoring at the NW side, calculated performance metrics (if needed) or data needed for performance metric calculation (if needed) can be generated by UE and terminated at gNB.

[0278] As documented in clause 7.1.2 of TR 38.843, in CSI prediction using UE-sided model use case:

[0279] Data collection:

[0280] In CSI prediction using UE sided model use case, at least the following aspects have been proposed by companies on data collection, including:

[0281] * Signalling and procedures for the data collection

[0282] * Data collection indicated by NW

[0283] * Requested from UE for data collection

[0284] * CSI-RS configuration

[0285] * Assistance information for categorizing the data, if needed

[0286] * The provision of assistance information needs to consider feasibility of disclosing proprietary information to the other side.

[0287] 1.3.2 Beam management

[0288] As documented in TR 38.843 [8], the following are selected as representative sub-use cases:

[0289] * BM-Case1: Spatial-domain Downlink beam prediction for Set A of beams based on measurement results of Set B of beams

[0290] * BM-Case2: Temporal Downlink beam prediction for Set A of beams based on the historic measurement results of Set B of beams

[0291] For both sub-use cases, the following alternatives are studied for the predicted beams:

[0292] * Alt.1: DL Tx beam prediction

[0293] * Alt.2: DL Rx beam prediction (deprioritized)

[0294] * Alt.3: Beam pair prediction (a beam pair consists of a DL Tx beam and a corresponding DL Rx beam)

[0295] For BM-Case1 and BM-Case2 with a UE-side AI / ML model, the necessity and potential BM-specific conditions / additional conditions for functionality(ies) and / or model(s) are considered at least from the following aspects:

[0296] * information regarding model inference

[0297] * Set A / Set B configuration

[0298] * performance monitoring

[0299] * data collection

[0300] * assistance information

[0301] For beam management use cases:

[0302] * For model training, training data can be generated by UE / gNB.

[0303] * For NW-side model inference, input data can be generated by UE and terminated at gNB.

[0304] * For UE-side model inference, input data is internally available at UE.

[0305] * For performance monitoring at the NW side, calculated performance metrics (if needed) or data needed for performance metric calculation (if needed) can be generated by UE and terminated at gNB.

[0306] As documented in clause 7.1.3 of TR 38.843, Data collection At UE side for UE-side AI / ML model:

[0307] * UE reporting to NW supported / preferred configurations of DL RS transmission.

[0308] * Trigger / initiating data collection considering:

[0309] ** Option 1: data collection initiated / triggered by configuration from NW.

[0310] ** Option 2: request from UE for data collection.

[0311] * Signalling / configuration / measurement / report for data collection, e.g., signalling aspects related to assistance information (if supported), Reference signals, content / type of the collected data, configuration related to Set A and / or Set B, information on association / mapping of Set A and Set B

[0312] * Assistance information from Network to UE for UE data collection for categorizing the data for the purpose of differentiating characteristics of the data (if supported). The assistance information should preserve privacy / proprietary information.

[0313] 1.3.3 Positioning accuracy enhancements

[0314] The following are selected as representative sub-use cases:

[0315] * Direct AI / ML positioning: AI / ML model output: UE location

[0316] * AI / ML assisted positioning: AI / ML model output: new measurement and / or enhancement of existing measurement

[0317] More specifically, the following Cases are considered for the study:

[0318] * Case 1: UE-based positioning with UE-side model, direct AI / ML or AI / ML assisted positioning

[0319] * Case 2a: UE-assisted / LMF-based positioning with UE-side model, AI / ML assisted positioning

[0320] * Case 2b: UE-assisted / LMF-based positioning with LMF-side model, direct AI / ML positioning

[0321] * Case 3a: NG-RAN node assisted positioning with gNB-side model, AI / ML assisted positioning

[0322] * Case 3b: NG-RAN node assisted positioning with LMF-side model, direct AI / ML positioning

[0323] For positioning enhancement use case:

[0324] * For model training, training data can be generated by UE / PRU / gNB / LMF.

[0325] * For LMF-side model inference (Case 2b, Case 3b), input data can be generated by UE / gNB and terminated at LMF.

[0326] * For gNB-side model inference (Case 3a), input data is internally available at gNB.

[0327] * For UE-side model inference (Case 1, Case 2a), input data is internally available at UE.

[0328] * For performance monitoring at the LMF side, calculated performance metrics (if needed) or data needed for performance metric calculation (if needed) can be generated by UE / gNB and terminated at LMF.

[0329] * For performance monitoring at the gNB side, calculated performance metrics (if needed) or data needed for performance metric calculation (if needed) can be generated by at least gNB.

[0330] Case 2b and Case 3b have been studies and specified by 3GPP WG SA2 during Release 19.

[0331] 1.3.4 Data collection

[0332] As documented in CR R2-2407807, for Data collection for UE-side model training:

[0333] The following options were discussed in RAN2:

[0334] 1a. UE collects and directly transfers training data to the data collection entity outside the MNO (e.g. Over-The-Top (OTT) server) for UE-side model training. No 3GPP specification impact is expected.

[0335] 1b. UE collects training data and transfers it to the server for data collection for UE-side model training (inside the MNO (Mobile Network Operator)) and then optionally from the server for data collection for UE-side model training to the OTT server (outside the MNO)

[0336] 2. UE collects training data and transfers it to Core Network. Core Network transfers the training data to the server for data collection for UE-side model training / OTT server.

[0337] 3. UE collects training data and transfers it to OAM. OAM transfers the training data to the server for data collection for UE-side model training / OTT server.

[0338] The options listed above were analysed to understand potential specification impact. The analysis included aspects such as termination entities, data transfer path, whether control plane (CP) or user plane (UP) should be used to transfer the data, protocol layers involved, MNO controllability and visibility over the collected data, etc. The result of this analysis can be found in [Table 2] below, corresponding to Table 7.2.1.3.2-1 of TR 38.843. ([Table 2] - Analysis of different data collection options for UE-side model training (Table 7.2.1.3.2-1 of TR　38.843))

[0339] It is worth noting that different options for the data content visibility were discussed. The different levels of data content visibility are captured in the Note 3 in Table 7.2.1.3.2-1 of TR 38.843.

[0340] OptionAspectOption 1a)Option 1b)Option 2Option 3First termination entityTraining entity (e.g., Over-The-Top (OTT) server)Server for data collection for UE-side model trainingInside the CNInside OAM domainAI / ML-specific Data Transfer PathUE to OTT server via either 3GPP or non-3GPP networkUE ->Server for data collection for UE-side model training / OTT server(Note 4)UE-> CN -> Server for data collection for UE-side model training / OTT server(Note 4)UE-> gNB->OAM -> Server for data collection for UE-side model training / OTT server(Note 4)UP / CP tunnelUP tunnel (for the case of data transfer from UE to OTT server via 3GPP network)UP tunnelCP tunnel (provided that the data volume remains within the NAS signalling capacity)FFS: UP tunnel(Note 7)CP tunnel (provided that the data volume remains within the RRC signalling capacity)FFS: UP tunnel(Note 7)Protocol layer for data transferApplication layerApplication layerNAS layer for CP tunnelFFS: the protocol layer for UP tunnelRRC layer for CP tunnelFFS: the protocol layer for UP tunnelControllability of MNO on data transferNo AI / ML specific controllabilityFFS: level of controllability(Note 5)(Note 1)Full controllability(Note 1)Full controllability(Note 1)Solution for network controllabilityN / A (the OTT server can directly request data from the UE)Example: per PDU sessionsVia NAS procedure, FFS other proceduresVia RRC procedurePossible Options for data content visibility in MNO(Note 2, Note 3)No standardized visibilityFFS on level of visibility(Note 5)Opt A) Full visibility for standardized data contents.Opt B) Partial visibility for partially standardized data contents.(Note 6)Opt C) No standardized visibility.(Note 6)Opt A) Full visibility for standardized data contents.Opt B) Partial visibility for partially standardized data contents.(Note 6)Opt C) No standardized visibility.(Note 6)Impacted WGsN / ASA2, SA3, RAN2, RAN3, CT1SA2, SA3, RAN3, RAN2, CT1 and CT3RAN2, RAN3, SA3, SA5, SA2- Note 1: Full controllability: The MNO can manage data transfer to the server for UE-side data collection, without the need of SLA. This includes initiating, terminating, and fully managing data transfer.- Note 2: Visibility of data content signifies that the MNO can, at least, be aware of, access, and comprehend the data without the need of SLA.- Note 3: The following options are identified to realize the different levels of data content visibility to the MNO:- Full visibility for standardized data content.- Partial visibility for partially standardized data content (e.g. UE proprietary information can be included transparently together with the standardized data message).- No standardized visibility (e.g. UE proprietary information can only be included transparently).- Note 4: The potential involvement of NF or other higher layers entities / functionalities should be discussed in other WGs. Impact on the OTT server is not in the scope of RAN2 discussion.- Note 5: RAN2 cannot reach consensus on the level of possible MNO controllability and visibility via Option 1b without input from SA groups.- Note 6: RAN2 has not concluded on the need for partial and no visibility options.- Note 7: RAN2 cannot reach consensus on the feasibility of UP tunnel in Options 2 and 3

[0341] Related to privacy, it has been stressed in RAN2 the importance that any potential mechanism to collect UE side data for model training purposes (including the options 1a, 1b, 2, 3 listed above) must comply with privacy protection regulations, requirements, laws and / or policies.

[0342] 1.4 Requirements on supporting data transfer over UP (user plane)

[0343] TSG RAN sent LS (liaison statement) to SA2 and other WGs (working groups) in S2-2409600 [9] / RP-242389

[0010] during RAN#105, Sept 2024, to initiate the work and at least for SA WG2 to provide inputs on solutions / data collection options 1b, 2, and 3 by RAN#106. In the LS RAN include the RAN#105 forward and requirements for standardized solutions for data collection (if standardized).

[0344] The solutions / data collection options 1b, 2, and 3 are listed in [Table 3] below, above in section 1.3.4 (Data collection)).

[0345] RAN has agreed to the following requirements for data collection for UE sided model training for standardized solution (if standardized) (i.e. Option 1b, 2, 3). Option 1a is not precluded.* The data collected is secured and data integrity and confidentiality for that data is ensured.* User data privacy, anonymity and user consent is respected.* The MNO has full control of the standardized data collection transfer process and can manage data transfer to the server for UE-side data collection, without the need of SLA for this purpose. This includes initiating, terminating, and fully managing data transfer.* MNO has full visibility for standardized data.* The design is futureproof and extendable.FFS / study if and how to handle non-standardized data (i.e. partial visibility).FFS controllability on data collectionStandardized Solutions should follow the principle of aiming to minimize air interface overhead and impact to NW operation

[0346] SA2 replied to the above LS in S2-2411191

[0011] / SP-241441

[0012] during SA2#165, Oct 2024, to ask for clarifications on some terms in the RAN LS.

[0347] Then SA2 sent another follow-up LS reply in SP-241575

[0013] / S2-2412726

[0014] during SA2#166, Nov 2024, to inform RAN that SA2 did not reach consensus on the feasibility, for any of the options outlined above, to meet RAN requirements specified in RP-242389

[0010] (S2-2411455).

[0348] RAN2 replied to S2-2411191

[0011] in S2-2500025

[0016] / S2-2412621

[0017] / R2-2411152

[0018] to answer the questions raised by SA2. SA2 received the RAN2 LS reply during SA2#166 meeting and noted the LS in SA2#166 AHE meeting. The SA2 questions and RAN2 answers include:

[0349] SA2's question 1:

[0350] Are there any aspects of the UE-data collection controllability, that required NG-RAN involvement? If so, what is the involvement of NG-RAN in UE-data collection controllability, e.g., what aspects of MNO controllability would require NG-RAN involvement and what would such involvement be?

[0351] As an example of the kind of feedback that is requested, some companies in SA2 understand that initiating (e.g., triggering), terminating collection of UE-side data and controlling data transfer may require NG-RAN involvement, and it is currently not clear what this involvement may be.

[0352] RAN2's answer:

[0353] RAN2 wants to clarify the following for the discussion of the UE side data collection for UE side model training:

[0354] * Data collection refers to the UE collecting data that involves the UE performing measurements (e.g., radio measurements).

[0355] * Data transfer refers to the sending / transfer of the collected data from the UE to Server for data collection for UE-side model training / OTT server (as capture in Table 7.2.1.3.2-1) in TR38.843.

[0356] SA2 can assume that the NG-RAN is involved in providing radio measurement configuration (if needed) for the UE side data collection at least for the beam management use case, as captured in the following agreement in RAN2-127bis:

[0357] * Data collection initiation and configuration for data collection is under network control. FFS how the NW determines whether data collection should be initiated (e.g., via UE requests (UE directly or UE server))

[0358] Data transfer can happen at any point in time under network control if there is collected data available in the UE. Furthermore, for data transfer, RAN2 hasn't studied / concluded on the level of NG-RAN involvement.

[0359] RAN2 will continue the discussion on data collection configuration and RAN2 will appreciate SA2 / SA5 input on the data transfer process.

[0360] SA2's question 2:

[0361] Furthermore, with regards to "initiating, terminating and fully managing data transfer" some companies in SA2 believe that further clarification is required, on a per use case basis, on where (which entities) and under what conditions, should controllability be performed, e.g., in NG-RAN, a NF, OAM, an MNO controlled AF, a 3rd party AF, a UE)?

[0362] RAN2's answer:

[0363] SA2 can assume that the gNB is involved in providing radio measurement configuration (if needed) for beam management use case and LMF is involved in providing PRS measurement configuration (if needed). However, RAN2 has not agreed that the gNB / LMF is in charge of "initiating, terminating and fully managing data transfer".

[0364] SA2's question 3:

[0365] Furthermore, some companies in SA2 wondered whether full controllability would have any impact on UE normal operation. If so, what impact is expected from RAN2 perspective to enable UE-side Data Collection?

[0366] RAN2's answer:

[0367] RAN2 has not evaluated / analyzed the impact on UE's normal operation due to the full controllability of the data collection process.

[0368] SA2's question 4:

[0369] Some companies in SA2 understands that standardized data content refers only to data reflecting results of measurements performed by the UE according to network measurement configuration. SA2 would kindly asks RAN2 to confirm this understanding.

[0370] RAN2's answer:

[0371] Standardized data refers to data whose format / content is explicitly defined in 3GPP specifications, allowing the network to understand its content and meaning.

[0372] SA2's question 5:

[0373] Does RAN2 expect data to be collected from UEs that are roaming?

[0374] RAN2's answer:

[0375] Roaming considerations are outside the scope of RAN2.

[0376] SA2's question 6:

[0377] SA2 would like confirmation from RAN2, whether it is sufficient that the data content be standardized and MNO knowing which data type is collected, and the MNO knowing the actual data content to be considered as the MNO having full visibility of such data or should further conditions be required in order to declare that the MNO has full visibility of such data, e.g. whether MNO need to verify the match between the data transferred and the data collected ?

[0378] RAN2's answer:

[0379] As stated in the LS sent from RAN, visibility of data content signifies that the MNO will be able to be aware of, access, and comprehend the content of the collected / reported data without the need of SLA. Thus, full visibility allows the MNO to verify / match the data specified / configured to be collected and the data that is being reported.

[0380] 1.5 SA2 approved 5GA R20 study item

[0381] TSG RAN sent LS to TSG SA, WG SA2 and SA5 in S2-2501372

[0019] / S2-2500055

[0020] / RP-243316

[0021] during RAN#106, Dec 2025, to require the relevant WGs to start studying the transfer of data over UP for solution 2 in WG SA2 and transfer of data over UP for solution 3 in WG SA5 and provide feedback to TSG RAN and WG RAN2.

[0382] SA2 approved the study item on 5GA Rel-20 Core Network Enhanced Support for Artificial Intelligence (AI) / Machine Learning (ML) Phase 2 during SA2#167 meeting, Feb 2025. As documented in SP-250068

[0022] / S2-2502788

[0023] , the SA2 objective related to UP data transfer include:

[0383] * WT#1: Study whether and how to support the standardized transfer of standardized data over UP for UE data collection to meet requirements for AI / ML for NR air interface operation with UE-side model training.

[0384] Note 1: The WT#1 scope is based on UP Data Collection for Option2 documented in RAN LSs RP-243316 and RP-242389.

[0385] Note 2: The requirements are elaborated in LSs RP-242389 and R2-2411152 which will be considered during the study phase.

[0386] Note 3: WT#1 impact on user consent and privacy will be addressed in cooperation with SA3.

[0387] SA2 will start to work on the above the objective in SA2#168 meeting, April 2025.

[0388] Based on the approved SA2 R20 5GA SID on Core Network Enhanced Support for Artificial Intelligence (AI) / Machine Learning (ML) Phase 2, SA2 will study transfer of data over UP for solution 2 and possibly also part of solution 3. As detailed in [Table 2] above,

[0389] * The data transfer path of Option 2: UE-> CN -> Server for data collection for UE-side model training / OTT server;

[0390] * The data transfer path of Option 3: UE-> gNB->OAM -> Server for data collection for UE-side model training / OTT server.

[0391] However, the existing 5G NR User Plane (UP) mechanism cannot support the fully / partial data visibility at CN or OAM; only the OTT server is able to decrypt the data transferred over UP from UE(s). The fully / partial data controllability cannot be supported without enhancement either.

[0392] Therefore, enhancement to 5GS is required to support UE data transfer over UP with network controllability and visibility.

[0393] The following is a list of AI / ML related terms and their definitions which may be used herein:

[0394] * Network-side (AI / ML) model / NW-side model: An AI / ML Model whose inference is performed entirely at the network.

[0395] * UE-side (AI / ML) model: An AI / ML Model whose inference is performed entirely at the UE.

[0396] * 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.

[0397] * AI / ML Model: A data driven algorithm that applies AI / ML techniques to generate a set of outputs based on a set of inputs.

[0398] * AI / ML model delivery: A generic term referring to delivery of an AI / ML model from one entity to another entity in any manner. Note: An entity could mean a network node / function (e.g., gNB, LMF, etc.), UE, proprietary server, etc.

[0399] * 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.

[0400] * 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.

[0401] * AI / ML model transfer: Delivery of an AI / ML model over the air interface in a manner that is not transparent to 3GPP signalling, 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.

[0402] * 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. Furthermore, in this invention, the data collection also refers to (documented in S2-2500025

[0016] / S2-2412621

[0017] / R2-2411152

[0018] ) to the UE collecting data that involves the UE performing measurements (e.g., radio measurements).

[0403] * Data transfer: Data transfer refers to the sending / transfer of the collected data from the UE to Server for data collection for UE-side model training / OTT server (as in Table 7.2.1.3.2-1 in TR 38.843 [8], i.e. [Table 2] above).

[0404] * Life Cycle Management (LCM): the life cycle management (LCM) of AI / ML model (e.g., model training, model deployment, model inference, model monitoring, model updating) and AI / ML functionality, including the following procedures Data collection, Model training, Functionality / model identification, Model delivery / transfer, Model inference operation, Functionality / model selection, activation, deactivation, switching, and fallback operation, Functionality / model monitoring, Model update, UE capability, etc.

[0405] * ML model lifecycle management: The management capabilities allowing a consumer to manage different phases of the ML model lifecycle as defined in clause 6.2.1.7 of TR 22.850 [4].

[0406] * AI / ML operation / process: in this invention it refers to one or more of the following AI / ML procedures: Data collection, Model training, Functionality / model identification, Model delivery / transfer, Model inference operation, Functionality / model selection, activation, deactivation, switching, and fallback operation, Functionality / model monitoring, Model update, UE capability, etc.

[0407] * AI / ML(-related) data: refers to any type of data that is related to or collected / used / consumed for any AI / ML procedures during LCM.

[0408] Various embodiments of the present disclosure provide solution(s) on AI / ML related data collection and / or transfer from the UE to the AI / ML server via UP with network controllability and visibility. Herein, where a step / operation or method is described, it will be appreciated that such a step / operation or method may be performed, in various examples, by an entity such as a 1sttermination entity / NF (e.g. in CN or OAM) or by a plurality of entities (e.g. two or more of UE, 1st termination entity / NF, UPF, SMF, server).

[0409] Different from a conventional UP data transfer, in the present disclosure, a 1sttermination NF / entity (i.e. network function, network entity, or entity) has the capability (e.g. is configured, arranged or adapted) to control AI / ML related data collection at UE and / or control transfer (i.e. of AI / ML related data) from the UE to the AI / ML server. In various examples, the 1sttermination NF / entity may also have different level(s) of visibility of the data by comprehending (e.g. determining, identifying, considering etc.) the different level of the AI / ML data.. In various examples, a level of AI / ML data is based on the same or similar principles to the principles of standardised data content (as discussed elsewhere herein). For example, a level of AI / ML data may be determined by or associated with a data content, a data type, a format of the data and / or how the AI / ML data is or may be decoded. For example, based on identifying a level of the AI / ML data, the 1sttermination NF / entity has or configures, or is configured with, a level of visibility of the data, wherein different levels of visibility are associated with different levels of the AI / ML data. In various examples, the 1sttermination NF / entity may more generally be referred to as a first NF or first entity.

[0410] Various examples of the present disclosure provide methods (and / or associated apparatus / entity / entities) relating to the following:

[0411] * Data transfer from UE to UPF via UP, then the UPF transfers the data to the 1st termination entity via UP or even exposure service, the UPF also transfers the data to the AIML / OTT server / DN via UP.

[0412] * Data transfer from UE to UPF via UP, the UPF forwards the data to SMF (e.g. via data forwarding mechanism). Then the SMF sends the data to the 1st termination entity via exposure. Then,

[0413] ** The 1st termination entity may send all or part of the AIML data to the OTT / AIML server (e.g. via 5GC exposure);

[0414] ** or UPF sends the data to the AIML / OTT server via UP.

[0415] * The entire data transfer is vis UP: data transfer from UE to UPF, then to the 1st termination entity, then (all / part of) AIML data is transferred to the AIML / OTT server via UP.

[0416] * Data transfer from UE to UPF then to the 1st termination entity via UP; then the 1st termination entity sends the data to AIML / OTT server via 5GC (internal / external) exposure service.

[0417] Various examples of the present disclosure provide or relate to the end-to-end procedures of supporting AI / ML (UE side) data transfer via UP.

[0418] 2.1 Support of Data transfer over UP with network controllability and / or visibility

[0419] Various examples relating to of Data transfer over UP with network controllability and / or visibility will now be provided / discussed.

[0420] In the present disclosure, the given examples, embodiments, solutions, aspects etc. are applicable to at least one or more of the use cases that have been identified by 3GPP for AI / ML over air interface (e.g. CSI feedback enhancement, beam management, positioning accuracy enhancements), but not limited to those use cases.

[0421] In the present disclosure, the given examples, embodiments, solutions, aspects etc are applicable to transmission of any types of data. In various examples, the AI / ML data types herein may be related to and / or used during AI / ML operation(s) / AI / ML procedure(s) which may include (but are not limited to): AI / ML data for model (re-)training, for inference, for performance monitoring, (trained / part of / entire) AI / ML model, AI / ML assistance data, AI / ML metadata, AI / ML (intermediate) results of training and / or inference, AI / ML inference results, etc. In various examples of the present disclosure, the UE side AI / ML data for model training is used an example to explain the proposed method(s) / solution(s) on AI / ML data transfer via UP. Accordingly, the present disclosure should not be seen as limited to the case of UE side AI / ML data for model training. AI / ML data transfer via UP may be interpreted as the data is transferred from the UE to UPF via UP, from UE to the 1st termination entity via UP, from UE to the AIML server (e.g. via 1st termination entity) over UP.

[0422] In general, AI / ML operation may be data driven. Data may be needed for AI / ML model (re-)training, AI / ML inference, AI / ML performance monitoring, etc. For different AIML operations, the different procedures may be performed by different entities / users; e.g. model training might be preformed by the network (gNB, OAM, core network (CN), etc.), but AI / ML inference may be (but is not required to be) performed by one or more entities different from the model training entities (e.g. UE, the network entities different from the training entities). Therefore, AI / ML-related data and / or model may be transferred between / from / to different entities in different use cases and scenarios.

[0423] In various examples, data collected from and / or by the UE may be needed for model training; e.g. for UE-side model, NW-side model, or UE-side or NW-side two-side model. In various examples, data for model training may be collected and / or transferred to the entity for model training. For example, referring to [Table 1] (Model delivery / transfer cases) above, the model training may be performed at UE-side, NW-side, or neutral (or other) site (e.g. AI / ML server). Therefore, the UE side data might be required to be transferred to the NW or neutral site for model training.

[0424] Various examples of the present disclosure provide methods, entities, apparatus etc. to support UE side data collection and data transfer to network and / or OTT server via user plane with network controllability and visibility. Various examples herein are based on the baseline UP paths of data transfer for Option 2 and Option 3, which have been agreed by RAN, as illustrated in [Table 2] above,

[0425] * For Option 2: the AI / ML-specific Data Transfer Path is UE-> CN -> Server for data collection for UE-side model training / OTT server, as shown in Figure 2 which illustrates an example relating to AI / ML-specific Data transfer Option 2;

[0426] * For Option 3: the AI / ML-specific Data Transfer Path is UE-> gNB->OAM -> Server for data collection for UE-side model training / OTT server, as shown in Figure 3 which illustrates an example relating to AI / ML-specific Data transfer Option 3

[0427] In the above options, as it has been agreed in RAN2: it can be assumed that for data collection the gNB is involved in providing radio measurement configuration (if needed) for beam management use case and LMF is involved in providing radio PRS measurement configuration (if needed). However, RAN2 has not agreed that the gNB / LMF is in charge of "initiating, terminating and fully managing data transfer"

[0428] According to various embodiments of the present disclosure, it is assumed that the gNB or LMF (location management function), the 1sttermination entity / NF and / or the OTT server and / or the entities who own the model proprietary is / are in charge of initiating, terminating and fully / partial managing data collection and / or data transfer. In various examples, if / in the case that the 1sttermination entity / NF is in charge, the 1st termination entity / NF may be requested by the UE, AI / ML server, OAM etc. for the initiating and / or terminating the AIML data collection and / or data transfer

[0429] As shown in Figure 2 and Figure 3, the 1sttermination entity of UE side AI / ML data transfer are inside the CN and inside OAM domain, respectively. For data transfer via UP, RAN has requirements on the AI / ML UE side data visibility and controllability at CN 230 and OAM 330 for option 2 and option 3, respectively. For data transfer via UP, RAN requires full controllability for both Option 2 and Option 3, but the requirements on level of visibility is still FFS (for further study).

[0430] As documented in RAN2 chair notes, the controllability requirement is referring to the controlling of the data collection / transfer process without an SLA. There might be also different level of controllability. But, based on the RAN agreement, for option 2 and option 3 (referring to [Table 2] above) Full controllability is required.

[0431] * Full controllability: means The MNO has the capability to manage data transfer to the server for UE-side data collection without the need of SLA. This includes at least initiating, terminating, and fully managing data transfer.

[0432] As documented in RAN2 chair notes, there are 3 levels of visibility. Which level(s) of visibility will be supported for Option 2 and option 3 (referring to [Table 2] above) are still FFS. Visibility of data content signifies that the MNO can at least, be aware of, access, and comprehend the data without the need of SLA. There are 3 levels of visibility, including:

[0433] * Full visibility for standardized data content.

[0434] * Partial visibility for partially standardized data content.

[0435] * No standardized visibility

[0436] In the present disclosure, all 3 levels of visibility are considered, particularly on full visibility and partial visibility. Various examples of the present disclosure consider one or two of the levels of visibility (i.e. a subset of the 3 levels); i.e. the embodiments described herein may not be limited to cases where all 3 visibility levels are considered or to cases where all 3 visibility levels are defined.

[0437] For the 'standardized data content', currently RAN has not reached there is no final consensus or agreement on this. In general herein, it assumed that the principles of 'standardized data content' may include one or more of the following:

[0438] * The data content is specified, e.g. the metadata of the UE side AI / ML and / or the measurement data collected by UE (e.g. data related to beam management or CSI feedback and / or RSRP, etc.) etc.

[0439] * The data type of the UE measurement data is specified, e.g. the data type for UE side AIML-related data collection. For example, the data type may be one or more of the type of measurement data at UE side, beam management data, CSI feedback related data, RSRP, etc.

[0440] * The format of the data is specified. The data may be collected at UE side, e.g. new type of data protocol. The data may be transferred to network and / or OTT server from the UE. The format of the data may be a new type 3GPP format. The entities allowed to comprehend the data may understand the format of the data for data decoding and interpretation, e.g. based on pre-configuration or (dynamic) configuration before or during the AI / ML data collection at UE and / or data transmission from UE.

[0441] * The data packet may be decoded / decrypted / encrypted by the 3GPP entities and / or based on the specific protocols, e.g. the NW NF or OAM, the RAN node and / or the UE configured or allowed to read / comprehend the data or own the data proprietary. This may be based on the protocol type / configuration.

[0442] The level of visibility that may be achieved by the network or the 1sttermination NF may depend on the level of 'standardized data content' to be supported by RAN. For various of the examples herein, it is assume that any combination of the above principals of 'standardized data content' are supported.

[0443] The (5GC NF) type of the 1sttermination NF / entity may be one or more different existing or new 5GC network function(s), e.g. in different use cases (i.e. from case to case) the 1sttermination NF / entity may be different. The 1sttermination NF / entity may be determined based on the functionality of the 1sttermination entity, e.g. as detailed in section 2.4 (Functionality of the 1sttermination entity inside CN) below.

[0444] 2.2 Data flow path of UE side AI / ML data transfer via UP

[0445] Various examples relating to data flow path of UE side AIML data transfer via UP will now be provided.

[0446] According to various embodiments, it is assumed that the AIML / OTT server is a final data termination point (or final data termination entity). If the AI / ML server and the 1sttermination NF / entity are collocated, the 1sttermination NF / entity may be a final data termination point. If the AIML data is transferred to AIML server and 1sttermination NF / entity via different paths, the 1sttermination NF / entity may also be considered as the data termination point. Examples of the present disclosure are applicable to at least one or more of the following scenarios / cases (even though in some examples the OTT server may be outside the 3GPP system):

[0447] * the AIML / OTT server is outside 3GPP domain, e.g. the OTT server cannot be (entirely) controlled by 3GPP / operators / MNOs.

[0448] * the AIML / OTT server is inside the 3GPP domain, e.g. within the core network and / or OAM. One or more of the following may work in conjunction:

[0449] ** the OTT server can be controlled by 3GPP / operators / MNOs, e.g. the network can control and determine the AI / ML operation;

[0450] ** the OTT server cannot entirely controlled by 3GPP / operators / MNOs, e.g. the OTT server can make independent decisions on AI / ML operation, and coordinate with 5GC / 5GS / 3GPP system.

[0451] ** AI / ML server and the 1st termination NF is collocated.

[0452] Figure 4 shows AI / ML data transfer via UP by routing AIML data to two paths, according to an example of the present disclosure. In Figure 4, UE 410 sends AI / ML data to UPF 431 in CN 430 (e.g. via base station or NG-RAN node 420), and UPF 431 performs AI / ML data transfer over a second path 450 to OTT server 440 (or DN 440, or application server 440, or OTT AIML server 440). UPF 431 may perform AI / ML data transfer over a first path 435 to 1sttermination NF / entity 433 in CN 430.

[0453] As shown in Figure 4, in an example relating to supporting Option 2 (in [Table 2] above), one option is to reuse an existing UP tunnel between the UE 410 and UPF 431, or between the UE 410 and DN / OTT AIML server / application server 440, between the UPF 431 and the DN / OTT server / application server 440. In addition, the UPF 431 may transfer the AI / ML data to the 1sttermination NF / entity 433 inside the CN 430, e.g. if the 1sttermination NF / entity 433 inside the CN 430 is not UPF but is instead another network function(s), or if the 1sttermination NF / entity 433 is a UPF but it is different from UPF 431 that receives the AI / ML data transferred from UE 410. In various examples, if the 1sttermination NF / entity 433 inside CN 430 is the UPF 431 that receives AI / ML data from the UE 410 (i.e. if 433 and 431 are the same entity), the AI / ML data transfer over the first path 435 in Figure 4 may be omitted.

[0454] In Figure 4, AI / ML data transfer over the first path 435 and AI / ML data transfer over the second path 450 may be performed in parallel, or one after the other - i.e. there is no required sequence to how / when these operations are performed.

[0455] In various examples, the first path 435 may be supported by user plane connection, and / or NF event exposure service, and / or data forwarding mechanism.

[0456] * For supporting the first path 435 by UP connection, UP connection between 1sttermination entity / NF 433 and / or UPF 431 and / or the UE 410 may be established. The first path 435 and the second path 450 may be associated, as they may be related to the same AI / ML data collection and / or transfer. For example, when establishing or modifying the user connection for the UE 410 for AI / ML data collection and / or transfer, both first and second paths 435, 450 are or will be established. During data transfer, UPF may send the data via both the first path 435 and the second path 450.

[0457] * For supporting the first path 435 by NF (e.g. UPF) event exposure, the 1sttermination NF / entity 433 may subscribe to UPF / SMF, e.g. for the event to transfer AI / ML data from UPF 431 to 1sttermination NF / entity 433. If the subscription is via SMF, the existing N4 procedure between UPF and SMF may be applied to forward the subscription. Once UPF 431 receives AI / ML data or the subscribed event related to AI / ML is triggered, UPF 431 may or will expose the data to the 1sttermination NF / entity 433.

[0458] In various examples (e.g. building on those relating to Figure 4, such that any feature or consideration made above in relation to Figure 4 may be applied to Figure 5), UPF forwards the AI / ML data to SMF (not shown) via data forwarding mechanism, then SMF forwards the AI / ML data to 1sttermination NF / entity inside CN. As example of this is shown in Figure 5.

[0459] Figure 5 shows an example relating to AI / ML data transfer via UP by routing AIML data to two paths with SMF involvement. In Figure 5, UE 510 sends AI / ML data to UPF 531 in CN 530 (e.g. via base station or NG-RAN node 520), and UPF 531 performs AI / ML data transfer over a third path 550 to OTT server 540 (or DN 540, or application server 540, or OTT AIML server 540). UPF 531 may perform AI / ML data transfer over a first path 537 to SMF 533, and SMF 533 may perform AI / ML data transfer over a second path 539 to 1sttermination NF / entity 535 in CN 530.

[0460] Data forwarding between SMF 533 and UPF 531 is supported by the existing NR design but may need enhancement to support the method(s) of Figure 5 (or similar) e.g. as detailed in section 2.3 (AI / ML data routing by UPF within 5GC) below. But the second path 539, relating to the data transfer / forwarding between SMF 533 and the 1sttermination NF / entity 535 is not supported yet.

[0461] In various examples, the AI / ML data transfer between / from SMF 533 and / to the 1sttermination entity 535, SMF 533 event exposure or other service operation that can support transfer data may be invoked (e.g. may be configured between or for one or more of these entities). The 1sttermination entity 535 may subscribe to SMF 533 for the AI / ML data.

[0462] In various examples, SMF 533 may be the 1sttermination NF / entity 435 (e.g. the two entities are combined, co-located or provided in a single entity). In this case, the second path 539 in Figure 5 is omitted.

[0463] Figure 6 shows an example relating to AI / ML data transfer via UP with enhancing an existing UP path, to support Option 2 (in [Table 2] above). In Figure 6, UE 610 sends AI / ML data to UPF 631 in CN 630 (e.g. via base station or NG-RAN node 620), and UPF 631 performs AI / ML data transfer over a first path 635 to 1st termination NF / entity 633 in CN 630. The 1sttermination NF / entity performs AI / ML data transfer over a second path 650 to OTT server 640 (or DN 640, or application server 640, or OTT AIML server 640). Figure 6 may be considered to build on examples relating to Figure 4, such that any feature or consideration made above in relation to Figure 4 may be applied to Figure 6.

[0464] Figure 6 illustrates that it may be possible to enhance or modify the existing UP design. In some examples, data may be transferred:

[0465] from UE 610 to the UPF 631, via UP connection / PDU session,

[0466] the UPF 631 transfers the data to the 1sttermination point 633 inside CN 630, e.g. via user plane connection / UP tunnel (e.g. corresponding to first path 635).

[0467] the 1st termination point 633 inside CN 630 transfers the data to the OTT server 640, e.g. via user plane connection / UP tunnel or network information exposure (e.g. corresponding to second path 650).

[0468] A benefit of sending AI / ML data by the 1st termination NF / entity 633 is that the 1sttermination NF / entity 633 or the operator / MNO may have control of the AI / ML data to be transferred to the OTT server 640; this may be particularly useful or practical if the OTT server 640 is outside 3GPP / MNO domain and / or the OTT server 640 is not untrusted by the network. The 1sttermination NF / entity 633 may determine, configure or control one or more of the following:

[0469] * whether or not to transfer the (received) AI / ML data to AIML / OTT server 640;

[0470] * which type of AI / ML data / data content will be transfer to the OTT server 640, e.g. sensitive data or data related to user or network privacy may not be transferred to the OTT server 640.

[0471] In various examples, an existing UP / data connection between UPF 631 and OTT / application server 640 may be extended, e.g. by adding the 1sttermination NF / entity 633 between the UPF 631 and DN / OTT / application server 640 compared to the conventional UP data transfer; here, the entire UP connection will be: UE 610 - UPF 631 - 1sttermination NF / entity 633 - DN / AIML or OTT server 640 for the AI / ML data transfer. In Figure 6, the data path from the UE 610 to the UPF 631 in addition to the first path 635 and the second path 650 are all over UP connection.

[0472] In various examples, in Figure 6 the data path from the UE 610 to the UPF 631 and the first path 636 are over UP connection, and the second path 650 is via network / NF / 5G exposure. The network / NF / 5G exposure may be:

[0473] * within the core network if the server is inside MNO / network domain, and / or

[0474] * to the outside of core network if the sever is outside MNO / network domain (e.g. via NEF if untrusted server).

[0475] The OTT / AIML server 640 may subscribe / request the 1sttermination entity 633 for AI / ML data exposure. This subscription / request may be the same as, together with or different to the AI / ML data collection and / or transfer request (e.g., the same as, sent together with or different to a request / subscription for AI / ML data collection and / or transfer).

[0476] The OTT / AIML server 640 may indicate the data type, metadata information and / or requirements etc. of the data for AI / ML operation (e.g. AI / ML model training) to the UE 610 or 5GC or 1sttermination point 633. Then the 5GC or 1sttermination point 633 may negotiate (e.g. communicate) with the AI / ML server, e.g. if or in case that the request from the AI / ML server cannot be performed or the requirements cannot be met by the network. Then the 5GC or 1sttermination point 633 may indicate the requirement(s) it can meet (or its capabilities) in (or of) the AI / ML server requirement(s) and / or may indicate additional information / data it can provide to AI / ML server. The AI / ML server may determine to accept or not accept the negotiation. If the AI / ML server and 5GC or 1sttermination point 633 cannot make agreement (e.g. do not agree) on AI / ML data collection and / or transfer, the procedure might not be triggered by or in the network / 5GC / 1sttermination point 633 or the UE 610.

[0477] 2.3 AI / ML data routing by UPF within 5GC

[0478] Various examples relating to AI / ML data routing by UPF within 5GC will now be provided.

[0479] To support Option 2 (in [Table 2] above), UPF may need to transfer the AI / ML data to a 1sttermination entity inside 5GC; different from the existing UP data transfer, in which the UPF may transfer data (e.g. the AI / ML data) to the DN / application.

[0480] To route the A / IML data to the 1sttermination entity, the UPF may need to understand (e.g. determine or be configured to identify) one or more of the following data information:

[0481] * Whether or not the data should be routed to the 1sttermination NF / entity.

[0482] * The information that may be needed to identify, discover, or establish UP connection to the 1sttermination NF / entity, e.g. (NF / NF instance) ID, IP addresses, and / or any type of information that may identify and discover the 1sttermination NF.

[0483] * Whether or not the received data from UE is AI / ML data, if the AI / ML data will be routed to the 1sttermination NF.

[0484] * Which / what type of AI / ML data it is, e.g. AI / ML data for model training, for inference, for performance monitoring, AI / ML model, AIML assistance data, AIML metadata, AIML (intermediate) results and / or AIML inference results etc. In some examples, not all the AI / ML related data (e.g. not all types of AI / ML data) will be routed to the 1sttermination point, subject to (e.g. based on) operators policies and network configuration / implementation and / or user consent / privacy; e.g. the data related UE side data for AI / ML model training, inference or other AI / ML procedures may be routed, while other data may not be routed.

[0485] In various examples, the UPF may need to determine the above data information in data packet / PDU level, QoS flow level, PDU session level, service flow level, IP flow level, etc.

[0486] In various examples, the UPF may recognize, distinguish, determine or differentiate the data information based on rules and / or configuration instructed by SMF for AI / ML data.

[0487] Currently (e.g. according to current 3GPP specifications), the UPF is not aware of any of the above information. In the existing UP design, the UPF can perform traffic detection based on the Packet Detection Rule (PDR) configured by SMF to identify the packets belonging to a session (e.g. for DownLink (DL) data), or a service data flow (e.g. for UpLink (UL) data). For the UE side AI / ML data transfer, it mainly involves the data from UE to OTT server.

[0488] The UPF may route the AI / ML data to (data / service flow belongs to) the 1st termination entity or SMF based on the information in PDR, in various examples of the present disclosure.

[0489] If the UPF forwards the data to the SMF over N4 interface, then the SMF sends the data to the 1st termination point, a new scenario might be added to 3GPP specification, e.g., the following [Table 4] entry could be added to in Table 5.8.2.5.2-1 of TS 23.501 [1] ( Scenarios for data forwarding between the SMF and UPF).

[0490] Scenario descriptionData forwarding directionnForwarding of AIML data , e.g. UE side AIML data for model training or inference or performance monitoring, AIML models, AIML intermediate results, AIML inference results, etc.UPF to SMFSMF to UPF

[0491] The UPF may determine to route the data to the 1sttermination NF / entity, or SMF or AIML server based on the information carried by the data packet, e.g. the designation of the data packet which can be represented by information IP addresses or FQDN (Fully Qualified Domain Name). Based on this, the UPF may route the data to the required destination, e.g. the 1sttermination NF / entity and / or the OTT server. In various examples, UPF may additionally or alternatively determine the data routing based on UPF internal logic (e.g. the internal AI model of UPF, which may be based on, e.g. generated by or deriving from, learning by the UPF) to recognize the AI / ML data or AI / ML data type, e.g. the characteristics of the data go through UPF can be used for data detection / differentiation. E.g. the UPF may learn the characteristics of AI / ML traffic over time, and based on this learning may identify where to route the AI / ML data. The characteristics of the data may include one or more of data set types (e.g. if the AI / ML data is standardized) for training / inference / performance monitoring, specific (AI / ML) model(-related) parameters, etc.

[0492] 2.4 Functionality of the 1sttermination entity inside CN

[0493] Various examples relating to functionality of the 1sttermination NF / entity inside CN will now be provided.

[0494] The 1sttermination NF / entity inside CN (e.g. in Option 2) may be NWDAF, NEF, UPF, SMF, or new type of network function (e.g. data network function).

[0495] According to various examples of the present disclosure, it is assumed that the 1sttermination NF / entity inside CN is able to perform one or more of the following:

[0496] * Triggering, initiating and / or terminating the AI / ML UE side data collection and / or transfer,

[0497] ** E.g. based on the internal logic of the 1sttermination NF / entity, or request / subscription from UE, AIML server, OAM or any other entities.

[0498] * Configuring or establishing the corresponding essential information or resources (e.g. UP connection, trigger PDU session establishment and / or QoS flow establishment, etc.) for AI / ML UE side data collection and / or transfer.

[0499] * Checking, identifying or determining user consent and / or user privacy (e.g. at NRF, UDM, UDR, or its stored / preconfigured information etc.) for AI / ML data UE side collection and / or transfer, e.g. before triggering, initiating or terminating the AI / ML UE side data collection and / or transfer. The procedure may be triggered only if the data collection and / or transfer is allowed by user consent and / or there are no user privacy concerns; otherwise, data collection and / or transfer may not be allowed.

[0500] * Coordinating, communicating and / or negotiating with AI / ML server (if it is a different NF / entity) to exchange information for AI / ML data UE side collection and / or transfer, e.g. one or more of QoS requirement, type of data collection, time window of potential data collection and / or transfer, data volume, data pattern, etc.

[0501] * The 1sttermination NF / entity may be involved in one or more procedures of the AI / ML operation, e.g. model training, model inference, model performance monitoring, etc.

[0502] ** If the 1sttermination NF / entity performs AI / ML model training, it may directly use the received AI / ML data to train the corresponding AI / ML model or part of the model if the model is split;

[0503] * Storing the AI / ML data for the corresponding AI / ML operation / procedure / model or forwarding the data to other entities to store (e.g. ADRF (Analytics Data Repository Function), NRF (Network Repository Function), UDR (Unified Data Repository), UDM (Unified Data Manager), etc. or OAM for data storage, etc.), e.g. based on the model ID (e.g. defined by 3GPP RAN working groups) or AI / ML operation / correlation ID or the AIML binding / correlation ID (in section 2.5 (Procedures of AI / ML data transfer via UP) below), etc.

[0504] ** Based on RAN definition: the Model ID may be used to identify model or models for the following LCM (lifecycle management) 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".

[0505] * Filtering the data to be transmitted to the OTT server, e.g. the 1sttermination NF / entity inside CN may decide one or more of the following:

[0506] ** whether or not to transfer the data to the OTT server;

[0507] ** which data packets, type of data will be transferred to the OTT server;

[0508] ** the decision might be made based on user privacy, user consent, network operation policy, etc.

[0509] * Using the data to make a determination related to the corresponding AI / ML operation, e.g. terminating, suspending, pausing, resuming, starting an AI / ML operation, e.g. AI / ML model training etc.

[0510] * Using the data to make a determination related to the network operation, e.g. operation optimization. This may be based on coordination with other 5GC NF, OAM, or RAN node.

[0511] 2.5 Procedures of AI / ML data transfer via UP

[0512] Various examples relating to procedures of AI / ML data transfer via UP will now be provided.

[0513] Figure 7 illustrates a method or procedure for AI / ML data transfer via UP according to various embodiments of the present disclosure.

[0514] Figure 7 illustrates a number of entities, including: UE 710, RAN node 720, AMF 730, UPF 740, SMF 750, 1sttermination entity / NF 760 (also referred to as 1sttermination NF 760 and / or 1sttermination entity 760), AIML / OTT server 770 (or AI / ML server 770, or AIML server 770) and AI / ML data storage 780.

[0515] According to various examples, the AI / ML server 770 may send information or (subscription) request to the 5GC NFs via NEF, if the AIML server 770 is untrusted AF and the 1st termination entity / NF 760 is not NEF.

[0516] The UP connection and / or PDU session establishment for AI / ML data transfer may be triggered by the UE 710, the 1sttermination entity / NF 760 or the AI / ML server 770. In various examples, the 1st termination entity / NF is used as an example to explain the data collection and transfer procedure.

[0517] The procedure shown in Figure 7 will now be described.

[0518] In operation 0, the UE 710, 1sttermination entity / NF 760 or the AI / ML 770 server determines that AI / ML data collection and / or data transfer is required, e.g. for model training or another AI / ML procedure(s).

[0519] In various examples, if the AI / ML data collection and / or data transfer is initially triggered by AI / ML server 770, the AIML server 770 may send request on data collection / transfer to the 1sttermination entity / NF 760. Then, the 1sttermination entity / NF 760 may trigger the following procedure (i.e. the procedure shown in Figure 7) within 3GPP / MNO domain.

[0520] In various examples, the AIML server 770 may inform the 1sttermination entity / NF 760 or UE 710 of the information related to data collection / transfer, e.g. the purpose of data collection / transfer (e.g. for AI / ML model training, inference, etc.), AI / ML operation type / use case / scenarios (e.g. AI / ML for beam management, CSI prediction, application layer use case, etc.), type of (UE / measurement) data to be collected and / or transferred, requirements on data collection (e.g. accuracy / confidence level of data, (parameters related to) QoS, delay requirements, data transfer protocols, data format, etc.), potential size / volume of data transfer, and / or required the timing information / time window of the data collection / transfer, etc. Said information may be used by UE 710 or 1sttermination entity / NF 760 to determine whether to transfer the data via UP and / or CP.

[0521] Operation 1 relates to decision making on utilising AI / ML data transfer via UP connection and / or CP connection between UE 710 and 1st termination entity / NF 760 and / or AIML server / OTT server / application / AF / AS 770.

[0522] In various examples, the decision may be made by or based on one or more of the following (e.g. by negotiation or coordination):

[0523] * UE 710, where this may be the UE 710 that data is collected from and / or data is transferred from. If the UE 710 decides or determines to use UP connection and / or CP connection to transfer the AI / ML data, UE 710 may inform the decision to the 1st termination entity / NF 760 and / or AIML server 770, then the 1st termination entity / NF 760 and / or AIML server 770 will take this information into account or follow UE's 710 decision for AI / ML data transfer via UP. Alternatively, the UE 710 may decide to trigger data transfer via user plane and / or control plane after making the decision.

[0524] * 1sttermination entity / NF 760 inside 5GC, e.g. if it is NWDAF, NEF, ADRF etc. or a new 5GC NF.

[0525] * The AIML / OTT server 770 of the AI / ML operation or AI / ML data collection / transfer.

[0526] In various examples, the decision on AI / ML data transfer via UP may be based on one or more of the following:

[0527] * the (potential) data volume, data transfer frequency, the duration of the data collection and / or data transfer, the latency requirement and / or the QoS requirement of the data to be transferred .

[0528] * the schedule information or time window of the AI / ML data transmission, e.g. the timing information determined based on the negotiation of PDTQ or BDT in the existing specifications.

[0529] * the type of AI / ML data and / or type of AI / ML service (e.g. the data is for beam management, positioning, CSI feedback etc.).

[0530] * UE and / or UPF user plane data transfer capability.

[0531] * control plane and / or user plane congestion status and / or prediction information (e.g. AMF, SMF, UPF load status).

[0532] * The network requirement of data transfer, e.g. whether the network requires controllability and / or full / partial visibility of the data. In one example, if the AI / ML data transfer via UP cannot support full visibility of AI / ML data, but the network requires full visibility; the AIML data transfer might be determined via CP (e.g. determined to be transferred via CP).

[0533] The 1sttermination entity / NF 760 and / or the AIML server 770 may determine to use user plane for AI / ML data transfer, if there is available user plane connection between UE 710, the 1st termination entity / NF 760 and / or the AIML server 770.

[0534] In various examples, operations 2-9 are skipped if there is already a user plane connection context of the target UE in 1st termination entity / NF 760 and the 1st termination entity / NF 760 or AIML server 770 determines to utilize the user plane connection for AI / ML data transfer.

[0535] In operation 2, which may be performed / occur conditionally as noted above, the AI / ML server 770 may subscribe to or send a request to the 1sttermination entity / NF 760, e.g. for AI / ML UE side data collection and / or transfer for model training (exposure). In various examples, this may happen during, e.g. at the same time as, operation 0.

[0536] In various examples, if the 1sttermination entity / NF 760 and AI / ML server 770 are not the same NF / entities, they may exchange their user plane information with each other, e.g. the IP addresses or FQDN. The information exchange might be via event exposure service operations of the 1st termination NF or AF.

[0537] In various examples, the user plane information of 1sttermination entity / NF 760 and AI / ML server 770 may be associated, e.g. for the corresponding AI / ML data collection and / or transfer, and, optionally, in addition other AI / ML related procedures associated to the AI / ML operation that the AI / ML data collection and transfer belongs to. In other words, for the same AI / ML operation (ID), both the 1st termination entity / NF 760 and the AI / ML server 770 are involved

[0538] This operation may happen (e.g. be performed) before or after operation 1 or in parallel with operation 1.

[0539] This operation may happen after the AI / ML server 770 checks the user consent and / or user privacy of UE side AI / ML data collection and / or data transfer, and / or operators' / network requirements on the AI / ML data collection with core network, before the data collection and / or data transfer was triggered.

[0540] The operators' / network requirements may include one or more of:

[0541] * Whether or not network visibility and / or controllability is required;

[0542] * The required level of visibility and / or controllability, etc.

[0543] In various examples, the AI / ML server 770 (either inside or outside MNO mobile network operator domain) may discover / contact the 1st termination entity / NF 760 based on the requirements on the AIML data.

[0544] Benefits of exchanging UP information between the AIML server 770 and 1st termination NF 760 may include: either of them can inform the UP information of both to AMF 730 then to the UE 710, e.g. via one message. In particular, if the UP data flow may go to the AI / ML server 770 and 1st termination NF 760 separately, as shown in Figure 4 and Figure 5, as a result the UP connection towards the AI / ML server 770 and 1st termination NF 760 may be established together and the UPF 740 may route the data packets with the address of either AI / ML server 770 or 1st termination NF 760 to both UP connections.

[0545] In various examples, the information exchanged between the AIML server 770 and 1st termination NF 760 may also include the scheduling information of the data collection or transfer (e.g. the data should be collected or transferred before a time point), the latency requirement and / or QoS of the data, etc. Therefore the 1st termination entity 760 may determine when to trigger the data collection and / or transfer to meet the server requirements and meanwhile maintain 5GS good performance.

[0546] In operation 3, which may be performed / occur conditionally as noted above, if AIML server 770 and / or the 1st termination NF 760 decides to utilize user plane for AI / ML data transfer but there is no established secure user plane connection between the UE 710, AIML server 770 and the 1st termination NF 760, AIML server 770 and / or the 1st termination NF 760 invokes a service operation, e.g. Namf_communication_N1N2MessageTransfer service operation, to send the user plane information to AMF 730 in a suitable message, e.g. a NAS container, to indicate UE 710 to utilize user plane for AI / ML data transfer.

[0547] In various examples, the user plane information may include the user plane AI / ML data transfer address of the AI / ML server 770 and / or the 1st termination NF 760.

[0548] In various examples, the 1st termination NF 760 may allocate a AI / ML binding / correlation ID to associate the user plane connection to be established with the target UE 710 and / or the AIML server 770. The 1st termination NF 760 may include this binding / correlation ID in the user plane information. The 1st termination NF 760 associates the target UE identity (SUPI and / or GPSI) with binding / correlation ID.

[0549] In various examples, the target UE ID may be indicated by the AIML server 770 to the 1st termination NF 760, e.g. via operation 2 of Figure 7. The target UE 710 is the UE 710 to perform data collection and / or transfer its AI / ML data to the network.

[0550] In operation 4, which may be performed / occur conditionally as noted above, when AMF 730 receives the user plane information, AMF 730 may send it to UE 710, e.g. via a DL NAS TRANSPORT message.

[0551] In operation 5, which may be performed / occur conditionally as noted above, if there is no established applicable PDU session for the user plane AI / ML data transfer, the UE 710 uses the URSP (e.g. as defined in TS 23.503) which includes user plane AI / ML data transfer related PDU session parameters, e.g. a dedicated DNN, time window, S-NSSAI, location, etc., to establish the PDU session for user plane AI / ML data transfer.

[0552] UE 710 may establish a secured user plane connection with the 1st termination NF 760.

[0553] In various examples, if the 1st termination NF 760 sends its FQDN to the UE 710, a DNS server / resolver may be used to resolve the IP address (e.g. EASDF or local DNS for local 1st termination NF address resolution).

[0554] In various examples, after the secured user plane connection been established successfully, the UE 710 sends the binding ID received in operation 3 to AMF 730 via the secured user plane connection to enable the 1st termination NF / entity 760. to perform the correlation of the UE 710 with the secured user plane connection. The binding ID will be released once the correlation is complete.

[0555] In operation 6, which may be performed / occur conditionally as noted above, the UE 710 may send an acknowledgement to the 1st termination NF / entity 760 through AMF 730 to indicate a success of user plane connection establishment for AI / ML data transfer via UP or a failure to utilize the user plane connection

[0556] In operation 7, which may be performed / occur conditionally as noted above, AMF 730 may send or forward the acknowledgement received in operation 5 to the 1st termination NF / entity 760, e.g. via Namf_N1messageNotify service.

[0557] In operation 8, which may be performed / occur conditionally as noted above, the 1st termination NF 760 may indicate to the AMF 730 that user plane connection between the UE 710 and 1st termination NF 760 and AIML server 770 has been established.

[0558] In various examples, the 1st termination NF / entity 760 may invoke a type of service operation, e.g. Nnf_DataTransfer_UP, and the NF in the name of the service operation will be replaced by the specified name of the 1st termination NF / entity 760, e.g. NEF, NWDAF or any new 5GC NF.

[0559] In operation 9, which may be performed / occur conditionally as noted above, the AMF 730 may store the AI / ML UP connection context as part of UE context.

[0560] In operation 10, AI / ML data transfer via the established UP connection is performed (i.e. occurs).

[0561] As detailed in section 2.1 (Support of Data transfer over UP with network controllability and / or visibility) above, different data flow path(s) via UP are possible. For example:

[0562] A. Data transfer from UE 710 to UPF 740 via UP, the UPF 740 forward the AI / ML data to the 1st termination NF 760 and AIML server 770 via UP. The UPF 740 may forward the same data to the 1st termination NF 760 and AIML server 770 or may filter the data based on configured rules, if any (e.g. different data or parts of the AI / ML data may be sent to each pf the 1sttermination NF 760 and the AIML server 770). This scenario may relate to examples according to Figure 4.

[0563] B. Data transfer from UE 710 to UPF 740 via UP, the UPF 740 forward the AI / ML data to SMF 750, e.g. by using data forwarding mechanism. Then the SMF 750 forwards data to the 1st termination NF 760, e.g. by invoking SMF 750 exposure service operation or any new service operation. Then the 1st termination NF 760 sends the AI / ML data to the AIML server 770, e.g. by invoking the corresponding event exposure service for (AI / ML) data exposure. The 1st termination NF 760 may filter the AI / ML data to be sent to AI / ML server based on rules, e.g. to protect 5GC or user privacy. Alternatively, the UPF 740 may forward the AI / ML data to the AIML server 770 via UP connection.

[0564] C. Data transfer from UE 710 to UPF 740 via UP, then UPF 740 forward the AI / ML data to the 1st termination NF 760. Then the 1st termination NF 760 sends the (optionally filtered) AI / ML data to the AIML server 770, e.g. via UP or via exposure service operation. The 1st termination NF 760 may filter the AI / ML data to be sent to AIML server 770 based on rules, e.g. to protect 5GC or user privacy.

[0565] In operation 11, in any stage during or following data transfer, after the 1st termination NF 760 receives the AI / ML data, the 1sttermination NF 760 may forward the data to another NF or OAM to storage (e.g. to AIML data storage 780). The NF 780 to store AI / ML data might be ADRF, NEF, UDM, UDR, NRF, new NF for (AI / ML) data storage, or OAM etc

[0566] In operation 12, data collection and / or transfer termination is performed (i.e. occurs), e.g. the termination may be triggered by AIML server 770, UE 710 or the 1st termination NF 760. There are now provided various examples of this:

[0567] * Data collection and / or transfer termination by AIML server 770: this may be based on internal logic, e.g. the AIML server 770 may determine the AI / ML training is done or suspended / terminated and there is no need to continue data collection and / or transfer, the UE 710 associated to the data collection and / or transfer is dropped (e.g. due to one or more of UE data cannot meet requirements on delay, data accuracy, no enough data for training, UE is out of the required / interested areas (AOI area of interests), etc.), etc.

[0568] In various examples, the AIML server 770 may inform the UE 710 (e.g. via the 1st termination NF 760) and / or 1st termination NF 760 of the termination decision. Then the UE 710 and / or 1st termination NF 760 will terminate the data collection and / or transfer upon receiving the notification.

[0569] * Data collection and / or transfer termination by UE 710: this may be based on internal logic, e.g. one or more of battery level is low, UE 710 is out of the area of interest of the data collection and / or transfer, UE 710 is overloaded, UE 710 determines to leave the AI / ML procedure / operation, UE is not interested in the corresponding service associated to the data collection / transfer, etc.

[0570] In various examples, the UE 710 may inform the AIML server 770 (e.g. via the 1st termination NF 760) and / or 1st termination NF 760 of the termination decision, e.g. via NAS, information carried by the data packet (e.g. in the data packet header), etc. Then the AIML server 770 and / or 1st termination NF 760 will terminate the data collection and / or transfer upon receiving the notification, release the corresponding UP connection and corresponding resources, e.g. the PDU session, QoS flow, RRC connection, etc.

[0571] * Data collection and / or transfer termination by the 1st termination NF 760, e.g. due to one or more of controllability requirements, user and network privacy consideration to not expose AI / ML data to server and / or being informed by the AIML server 770 to terminate the procedure, network / UE load (e.g. load is too high), network congestion (CP and / or UP), network performance degradation, lack of resources, 1st termination NF will be out of service (e.g. due to network configuration), etc.

[0572] In various examples, the 1st termination NF 760 may inform the AIML server 770 and / or the UE 710 of the termination decision, e.g. via AMF 730 and NAS or NF service operation (e.g. data collection termination, unsubscribe, notify, etc.), Then the AIML server 770 and / or UE 710 terminate the data collection and / or transfer upon receiving the notification.

[0573] In various examples, the AIML server 770 may negotiate with the 1st termination NF 760 if it still needs data for AI / ML operation, or the AI / ML server 770 may discover other 5GC NF that can support and provide data collection and transfer service, or directly collect data from UE 710 via application layer, etc.

[0574] During any stage or operation in the method of Figure 7, the data collection and / or transfer procedure or request can be rejected. For example:

[0575] * The 1st termination NF 760 may reject the data collection data collection and / or transfer request from the AIML server 770, e.g. before any other related procedures have been triggered or initiated in the method of Figure 7 or in or following operation 0, 1, or 2.

[0576] * The UE 710 may reject the collection data collection and / transfer request, from the 1st termination NF760 or AIML server 770, e.g. in or following operation 0, 1 or 4. The UE 710 may reject the UP connection establishment or modification request, e.g. as received from the 1st termination NF 760 (e.g. via AMF 730), e.g. in operation 4.

[0577] ** The rejection maybe due to e.g. UE location, capability, device memory, battery status, the entity of the 1st termination NF or AIML server, etc.

[0578] In various embodiments, if the request / subscription for AI / ML data collection and / or transfer is rejected, the entity / UE which determines the rejection may send the decision and / or the cause value of the rejection to the subscriber or the entity sending the request. Then the operations after (i.e. occurring after the time when) the rejection is made in the method of Figure 7 may be skipped.

[0579] According to various embodiments of the present application, there is provided a first entity (e.g. 1sttermination entity or 1sttermination NF, such as described in any of the examples herein) configured to: receive AI / ML related data or traffic from a second entity (e.g. user plane function (UPF) or session management function (SMF)), the AI / ML related data or traffic being provided by a user equipment (UE).

[0580] In various embodiments, the first entity is included in core network or Operations, Administration and Maintenance (OAM).

[0581] In various embodiments, the AI / ML related data or traffic is AI / ML data. For example, the AI / ML data is for one or more of AI / ML model (re-)training, AI / ML inference or AI / ML performance monitoring. For example, the AI / ML related data or traffic is for model training (e.g. UE-side model, network-side model or two-side model).

[0582] In various embodiments, the second entity is a SMF and the AI / ML related data or traffic is received from a UPF via the SMF. E.g. the UPF sends the AI / ML related data or traffic to the SMF, and the SMF sends (e.g. via exposure) the AI / ML related data or traffic to the first entity.

[0583] In various embodiments, the second entity is a UPF.

[0584] In various embodiments, the AI / ML related data or traffic is received from the UPF via user plane (UP).

[0585] In various embodiments, the first entity is configured to transmit the AI / ML related data or traffic to a server (e.g. OTT server, AI / ML server, application server), e.g. over UP or over 5GC (internal or external) exposure service.

[0586] In various embodiments, the first entity is configured to filter the AI / ML related data or traffic, and transmit the filtered AI / ML related data or traffic to the server (e.g. OTT server, AI / ML server, application server), e.g. over UP or over 5GC (internal or external) exposure service.

[0587] In various embodiments, the filtering is based on one or more rules, e.g. the one or more rules relating to user privacy or protection of 5GC (e.g. the CN).

[0588] In various embodiments, the UP is an existing UP connection relating to the UE in the first entity.

[0589] In various embodiments, the first entity is configured to determine to utilize the existing UP connection for AI / ML data transfer (e.g. controlling transmission and / or reception of the AI / ML related data or traffic). In an example, this may be instead of determining to establishing a (e.g. new) UP connection. In various examples, this determination is made by the server.

[0590] In various embodiments, the first entity is configured to establish a UP connection relating to the UE (e.g. by performing a method according to that of operations 2-9 of Figure 7).

[0591] For example, the first entity is configured to transmit UP information to an Access & Mobility Management Function (AMF), or transmit a message to indicate the UE is to use UP for AI / ML data transfer. The UP information or message may be transmitted in a NAS container. The UP information may include user plane AI / ML data transfer address of the server and / or the first entity.

[0592] For example, the first entity is configured to receive, from the AMF, an acknowledgement or message from the UE, the acknowledgement or message indicating a success of the UP connection establishment or a failure to utilize the UP connection.

[0593] For example, the first entity is configured to transmit, to the AMF, an indication that UP connection between the UE, the first entity and the server is established. In various examples, the AMF stores the UP connection context (i.e. for the established UP connection) as part of UE context.

[0594] In various embodiments, the first entity is configured to receive an indication of the UE from the server. E.g. the UE is a target UE to perform data (e.g. AI / ML data) collection and / or to transfer AI / ML data to the network.

[0595] In various embodiments, the first entity is configured to forward the AI / ML related data or traffic to be stored in at least one other entity. The at least one other entity may include at least one of ADRF, NEF, OAM, UDM, UDR or NRF.

[0596] In various embodiments, the first entity is configured to determine to terminate collection of AI / ML related data or traffic in the UE and / or determine to terminate transfer of the AI / ML related data or traffic from the UE and / or to the server. In various examples, said determination(s) is / are based on one or more of controllability requirements, user privacy considerations (e.g. not to expose the AI / ML related traffic or data to the server), network privacy considerations (e.g. not to expose the AI / ML related traffic or data to the server), or an instruction from the server to terminate a corresponding procedure or operation.

[0597] For example, the first entity is configured to inform the server and / or the UE of the termination decision (i.e. the result of the determination to terminate the collection and / or terminate the transfer). The first entity may inform the UE of the termination decision via AMF, e.g. by NF service operation.

[0598] In various embodiments, the AI / ML related data or traffic corresponds to a stream of data or traffic, e.g. data or traffic being received over time. E.g. the UE is, e.g. over time, collecting data to generate or provide the AI / ML related data or traffic and transferring the AI / ML related data or traffic to the first entity (e.g. via UPF).

[0599] In various embodiments, the first entity is configured to control the collection or generation of the AI / ML related data or traffic at the UE and / or the transfer of the AI / ML related data or traffic from the UE to the server. E.g. the first entity is configured to control the transfer of the AI / ML data or traffic to the server by at least initiating, terminating and managing the transfer.

[0600] In various embodiments, the first entity is configured to have: full visibility of standardized data content or partial visibility for partially standardised data content. For example, the first entity is configured to decode or decrypt (e.g. fully or partially) the AI / ML related data or traffic. This may be based on a level of the AI / ML related data or traffic. In various examples, based on decoding or decrypting the AI / ML related data or traffic, the first entity is configured to control the collection or generation of the AI / ML related data or traffic at the UE and / or the transfer of the AI / ML related data or traffic from the UE to the server.

[0601] In various embodiments, the first entity is co-located with the server or the server is outside 3GPP domain.

[0602] According to various embodiments of the present disclosure, there is provided a second entity (e.g. UPF), the second entity configured to: receive, from a UE, AI / ML related data or traffic over UP; and transmit the AI / ML related data or traffic to a first entity (e.g. first termination entity or first termination NF, e.g. as described above).

[0603] In various embodiments, the AI / ML related data or traffic is transmitted to the first entity via SMF.

[0604] In various embodiments, the second entity is configured to transmit the AI / ML related data or traffic to a server (e.g. OTT server, AI / ML server, application server), e.g. over UP. In an example, if the second entity transmits the AI / ML related data or traffic to the server, the first entity is not configured to transmit the AI / ML related data or traffic to the server.

[0605] In various embodiments, the second entity is configured to transmit the AI / ML related data or traffic to the first entity over UP.

[0606] In various embodiments, the second entity is included in core network.

[0607] In various embodiments, the first entity is included in the core network.

[0608] In various embodiments, the AI / ML related data or traffic is AI / ML data. For example, the AI / ML data is for one or more of AI / ML model (re-)training, AI / ML inference or AI / ML performance monitoring. For example, the AI / ML related data or traffic is for model training (e.g. UE-side model, network-side model or two-side model).

[0609] In various embodiments, the second entity is configured to route the AI / ML related data or traffic to the first entity or to the SMF (for forwarding on the first entity) based on information in a packet detection rule (PDR) configured by the SMF.

[0610] In various embodiments, the second entity is configured to determine to route the AI / ML related data or traffic to the first entity, the SMF and / or the server based on information carried by a data packet of the AI / ML related data or traffic. In various examples, the second entity is configured to additionally or alternatively determine to route the AI / ML related data or traffic based on UPF internal logic. e.g. based on identifying or recognising data characteristics (e.g. type of data, data set types, specific model parameters, a data use, or the data itself) of the AI / ML related data or traffic.

[0611] Various embodiments of the present disclosure related to methods, apparatus, systems etc. for supporting, or relating to supporting, standardised transfer of standardised data over UP, e.g. for UE data collection to meet the requirements for AI / ML for NR air interface operation with UE-side model training.

[0612] As requested by RAN, SA2 is expected to study the transfer of data over UP for Option 2. The data transfer path of Option 2: UE-> CN -> Server for data collection for UE-side model training / OTT server (as shown in [Table 2] above). In general, the UP data may be transferred from the UE to the target DN or application via UPF. To support Option 2, various examples of the present disclosure include transferring AI / ML data from UE to the 5GC NF that hosts the AIML data collection management functionality (e.g. DCF, Data Collection Function) via UP connection; then the DCF notifies / transfers the data to the AIML server for model training. Such examples can provide AIML data visibility and controllability as required by RAN.

[0613] An example of such a procedure is illustrated in Figure 8, which illustrates operations of DCF initiated UP connection for UE side data transfer for AI / ML model training. Figure 8 shows interactions between one or more of UE 810, NG-RAN 820, AMF 830, UPF 840, DCF (data collection function) 850 and AIML (training) server 860 (which may also be termed AI / ML server 860).

[0614] In various examples, DCF 850 may trigger the user plane connection establishment for UE side AI / ML data transfer, e.g. after receiving AI / ML data collection request from AIML (training) server or based internal logic of DCF 850, if target the UE 810 does not have user plane connection with the corresponding DCF 850. The DCF 850 may subscribe to the AMF 830 for the status of the user plane connection for the target UE 810.

[0615] In operation 0, being optional, the AIML (training) server 860 may determine to request UE side data for AI / ML model training by sending request to or subscribe to DCF 850. E.g. the AIML (training) server 860 transmits the request to or subscribes to DCF 850. The DCF 850 may check the user consent to determine whether the data collection request can be complied or not.

[0616] In operation 1, DCF 850 determines to request the UE side data for AI / ML model training purpose. This operation might be triggered by the request from AI / ML server 860 and / or by DCF 850 internal logic. In various examples, this operation is omitted and operation 2 is performed instead, i.e. instead of determining to request the UE side data, the DCF 850 transmits a data collection request to the target UE.

[0617] In various examples, the DCF 850 may also decide whether to transfer the AI / ML data via UP or CP. In this case, operation 4 (Described below) may be skipped / omitted.

[0618] In operation 2, DCF 850 sends a data collection request (or a request for data) to the target UE 810, e.g. via AMF 830 or NG-RAN 820.

[0619] In operation 3, UE 810 performs data collection for AI / ML model training based on the request from network (e.g. from DCF 850, or from DCF 850 via AMF 830 and / or NG-RAN 820).

[0620] In operation 4, which is conditional as noted above (e.g. depending on whether operation 1 includes the DCF 850 determining whether to transfer the AI / ML data via UP or CP), DCF 850 makes a determination on AI / ML UE side transfer via UP.

[0621] In various examples, DCF 850 may determine the AI / ML data transfer via UP based on one or more of the AI / ML data volume, the duration of the data collection and / or data transfer, UE user plane AI / ML data transfer capability, or control plane and / or user plane congestion status, etc.

[0622] In operation 5, if DCF 850 decides to utilize user plane connection for AI / ML data transfer but there is no established secure user plane connection between the UE 810 and DCF 850, the DCF 850 sends user plane information to AMF 830 or UE 810 to indicate UE to utilize UP for AI / ML data transfer. For example, the DCF 850 invokes Namf_communication_N1N2MessageTransfer service operation to send its user plane information to AMF in a NAS container to indicate UE to utilize user plane for AIML data transfer. Operation 5 may be conditional based on there being no established UP connection between DCF 850 and UE 810, e.g. operation 5 is not performed if there is such a UP connection.

[0623] The user plane information may include the user plane address of DCF (e.g. IP address or FQDN).

[0624] In various embodiments, DCF 850 may also may allocate an AI / ML data collection binding / correlation ID to associate the user plane connection to be established with the target UE identify (SUPI and / or GPSI). The DCF 850 may include this ID in the user plane information.

[0625] In various examples, the target UE 810 identity (SUPI and / or GPSI) may be indicated to the AMF 830 by DCF 850 in operation 2.

[0626] In operation 6, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 850 and UE 810)), AMF 830 receives the user plane information, AMF 830 may send it to the target UE 810, e.g. via a DL NAS TRANSPORT message, by including the information in operation 5.

[0627] In operation 7, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 850 and UE 810)), if there is no established applicable PDU session for the user plane AI / ML data transfer, the UE 810 uses USRP, e.g. the URSP as defined in TS 23.503, which includes user plane AI / ML data transfer related PDU session parameters - e.g. a dedicated DNN, time window, S-NSSAI and / or location, etc. - to establish the PDU session for user plane AI / ML data transfer.

[0628] In operations 8 and 9, which are conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 850 and UE 810)), UE 810 may send an acknowledgement to the DCF 850, e.g. through AMF 830, to indicate a success of user plane connection establishment for AI / ML data transfer via UP or a failure to utilize the user plane connection.

[0629] In operation 10, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 850 and UE 810)), the AMF 830 may store the context of the UP connection for user plane AIML data transfer as part of UE context. In various example, operation 10 is omitted.

[0630] In operation 11, there is AI / ML UE side data transfer for AI / ML model training from UE 810 to DCF 850 via the established UP connection with the assigned AI / ML data collection binding / correlation ID. That is, such AI / ML data transfer is performed in operation 11, with UE 810 sending the data and DCF 850 receiving the data. It will be appreciated that, in various examples, where decides to utilize user plane connection for AI / ML data transfer and there is an established user plane connection between the UE 810 and DCF 850, said established UP connection will be used for the AI / ML UE side data transfer (here, operations 5-10 are omitted).

[0631] In operation 12, DCF 850 may notify the AI / ML UE side data for AIML model training to the AIML (training) server 860.

[0632] In various examples, DCF 850 may filter the data to be transferred to the AI / ML server 860 based on user consent and / or subject to operators' policies.

[0633] In operation 13, data collection and / or transfer termination occurs. The termination might be decided (e.g. controlled, initiated or determined etc.) by the AI / ML server 860, the target UE 810 or DCF 850.

[0634] Figure 9 shows an example which illustrates operations of UE initiated UP connection for data transfer. In various examples, a UE may trigger the user plane connection establishment for UE side AI / ML data transfer, if the UE 910 does not have user plane connection with DCF. Figure 9 shows interactions between one or more of UE 910, NG-RAN 920, AMF 930, UPF 940, DCF (data collection function) 950 and AIML (training) server 960 (which may also be termed AI / ML server 960).In operation 0, which is optional (i.e. may be omitted), the AIML (training) server 960 may determine to request UE side data for AI / ML model training by sending request to or subscribe to DCF. E.g. the AIML (training) server 960 transmits the request to or subscribes to DCF 950. The DCF 950 may check the user consent to determine whether the data collection request can be complied or not.

[0635] In operation 1, DCF 950 determines to request the UE side data for AIML model training purpose. This operation might be triggered by the request from AIML server 960 or DCF 950 internal logic. In various examples, this operation is omitted and operation 2 is performed instead, i.e. instead of first determining to request the UE side data, the DCF 950 just transmits a data collection request to the target UE.

[0636] In operation 2, DCF 950 sends data collection request to the target UE 910, e.g. via AMF 930 or NG-RAN 920. The DCF 950 may optionally indicate its user plane information or NF ID to the UE.

[0637] In operation 3, UE 910 performs data collection for AI / ML model training based on the request from network (e.g. from DCF 950, or from DCF 950 via AMF 930 and / or NG-RAN 920).

[0638] In operation 4, UE 910 makes a determination on AI / ML UE side transfer via UP, e.g. based on one or more of AI / ML data volume, UE user plane AIML data transfer capability or other UE 910 internal logic. For example, the UE 910 determines whether to transfer the collected data via UP or CP.

[0639] In operation 5, UE 910 sends a user plane connection establishment request to AMF 930, e.g. via NAS Message, with the indication of AIML data transfer via UP, if there is no established secure user plane connection between the UE 910 and DCF 950. E.g. operation 5 may be performed conditionally based on whether or not there is an established UP connection between UE 910 and DCF 950.

[0640] In operation 6, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 950 and UE 910)), if the UE 910 is authorized, e.g. based on UE Subscription, to use the user plane AI / ML data transfer, AMF 930 establishes a user plane session for the UE 910.

[0641] In various examples, if the DCF 950 indicate its address or ID in step 2, the UE 910 may indicate the DCF address to AMF 930 in operation 6. Therefore the AMF 930 will directly establish the UP connection with corresponding DCF 950. Otherwise, the AMF may either query a / the NRF (not shown) or, based on local configuration, discover and select a proper DCF (e.g. DCF 950).

[0642] In operation 7, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 950 and UE 910)), the AMF 930 sends request to DCF950 to request set up of UP connection for AI / ML data transfer, e.g. by invoking Ndcf_DataTrans_UPConfig request or other service operation.

[0643] In operation 8, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 950 and UE 910)), if DCF 950 accepts to utilize user plane for AI / ML data transfer and there is no established secure user plane connection between the UE 910 and DCF 950, DCF 950 sends a user plane information to AMF 930 to indicate the UE 910 request is accepted.

[0644] The user plane information may include the user plane address of DCF (e.g. IP address or FQDN).

[0645] In various examples, DCF 950 may also allocate an AI / ML data collection binding / correlation ID to associate the user plane connection to be established with the UE 910 identify (SUPI and / or GPSI). The DCF 950 may include this ID in the user plane information.

[0646] In operation 9, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 950 and UE 910)), when AMF 930 receives the user plane information (e.g. from DCF 950), AMF 930 forwards it to UE 910, e.g. via a DL NAS TRANSPORT message, by including the information from operation 8 in a message.

[0647] In operation 10, which is conditional (e.g. depending on operation 5 being performed (i.e. there being no established UP connection between DCF 950 and UE 910)), if there is no established applicable PDU session for the user plane AI / ML data transfer, the UE uses USRP, e.g. the URSP as defined in TS 23.503, which includes user plane AIML data transfer related PDU session parameters - e.g. a dedicated DNN, time window, S-NSSAI and / or location, etc. - to establish the PDU session for user plane AI / ML data transfer.

[0648] In operations 11 and 12, UE 910 may send an acknowledgement to the DCF 950, e.g. through AMF 930, to indicate a success of user plane connection establishment for AI / ML data transfer via UP or a failure to utilize the user plane connection.

[0649] In operation 13, DCF 950 responds to AMF 930 that user plane connection between the UE 910 and DCF 950 has been established.

[0650] Operations 14 - 17 are the same as operations 10 -13 in Figure 8.

[0651] Relating to various examples according to Figures 8 and 9, various embodiments of the present disclosure provide an entity, e.g. DCF, configured to support UE side data collection for AI / ML model training, e.g. by one or more of initiating and / or termination the data collection and transfer, establishing and configuring the UP connection, and notifying the AI / ML data to AI / ML server. Relating to various examples according to Figures 8 and 9, various embodiments of the present disclosure provide an entity, e.g. AMF, configured to establish UP connection between UE and DCF for AIML data transfer. Relating to various examples according to Figures 8 and 9, various embodiments of the present disclosure provide an entity, e.g. UPF, configured to route UE side AIML data for model training to DCF.

[0652] It will be appreciated that, in each example / embodiment / aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate. Additionally, one or more features or operations from any example / embodiment may be combined with features or operations from any other example / embodiment. In particular, regardless of whether or not a pointer towards a combination of features / examples is found herein, the present disclosure should be considered to include all combinations of two or more of the embodiments, examples etc. disclosed herein, and all combinations of two or more of the features disclosed herein.

[0653] Figure 10 is a block diagram of an exemplary apparatus, or network entity, that may be used in examples of the present disclosure. The skilled person will appreciate said 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.

[0654] The entity 1000 comprises a processor (or controller) 1001, a transmitter 1003 and a receiver 1005. The receiver 1005 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 1003 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 1001 is configured for performing one or more operations, for example according to the operations as described above.

[0655] Figure 11 illustrates a method of a network function (e.g. a first network function, such as a DCF, which may be implemented by one or more entity (e.g. device) in a network) according to an example of the disclosure.

[0656] In S1110, based on determining whether to UE-side data for AI / ML model training, the network function transmits a request for collecting AI / ML data to a UE.

[0657] In S1120, the network function receives via a secured UP connection, data for AI / ML model training transferred from the UE.

[0658] In S1130, the network function notifies at least a portion of the data for AI / ML model training to an AI / ML server. For example, some of the data received from the UE may be filtered, such that all the received data is not sent to the AI / ML server.

[0659] Figure 12 illustrates a method of a UE according to an example of the disclosure.

[0660] In S1210, the UE receives, from a network function (e.g. a first NF, e.g. DCF), a request for collecting AI / ML data.

[0661] In S1220, based on the request, the UE collects data for AI / ML model training.

[0662] In S1230, the UE transfers, via a secured UP connection, the data for AI / ML mode training to the network function.

[0663] Figure 13 illustrates a method of a server (e.g. AI / ML server) according to an example of the disclosure.

[0664] In S1310, the server determines to request UE-side data for AI / ML model training.

[0665] In S1320, the server transmits, to a network function (e.g. first NF, e.g. DCF) a request for UE side data for AI / ML model training.

[0666] In S1330, the server receives, from the network function, UE-side data for AI / ML model training.

[0667] Acronyms and Definitions (as may be used herein)

[0668] 3GPP: 3rd Generation Partnership Project

[0669] 5G: 5th Generation

[0670] 5GA: 5G Advanced

[0671] 5GC: 5G Core

[0672] 5QI: 5G QoS Identifier

[0673] 5GS: 5G System

[0674] 5GSM: 5G System Session Management

[0675] 5GMM: 5G System Mobility Management

[0676] AF: Application Function

[0677] AI: Artificial Intelligence

[0678] AIML: Artificial Intelligence / Machine Learning

[0679] AM: Acknowledged Mode

[0680] AMF: Access and Mobility Management Function

[0681] AS: Application Server

[0682] ASP: Application Service Provider

[0683] ATSSS: Access Traffic Steering Switching & Splitting

[0684] AUSF: Authentication Server Function

[0685] CDRX: Connected Mode Discontinuous Reception

[0686] CSI: Channel Status Information

[0687] DCAF: Data Collection Application Function

[0688] DNAI: Data Network Access Identifier

[0689] DNN: Data Network Name

[0690] DNS: Domain Name Server

[0691] DRB: Data Radio Bearer

[0692] eNB: Evolved Node B

[0693] EPS: Evolved Packet System

[0694] FQDN: Fully Qualified Domain Name

[0695] GBR: Guaranteed Bit Rate

[0696] GMLC: Gateway Mobile Location Centre

[0697] gNB: Next generation Node B

[0698] GPSI: Generic Public Subscription Identifier

[0699] IAB: Integrated Access and Backhaul

[0700] ID: Identity / Identifier

[0701] IIoT: Industrial Internet of Things

[0702] IMEI: International Mobile Equipment Identities

[0703] IP: Internet Protocol

[0704] LCM: Lifecycle Management

[0705] LMF: Location Management Function

[0706] MA-PDU: Multiple Access PDU

[0707] ML: Machine Learning

[0708] MME: Mobility Management Entity

[0709] MN: Master Node

[0710] MNO: Mobile Network Operator

[0711] MPTCP: MultiPath TCP

[0712] MT: Mobile Termination

[0713] NAS: Non-Access Stratum

[0714] NEF: Network Exposure Function

[0715] NRF: Network Repository Function

[0716] NG-RAN: Next Generation Radio Access Network

[0717] NG-eNB: Next Generation eNB

[0718] NSA: Non-Standalone

[0719] NSSF: Network Slice Selection Function

[0720] NW: Network

[0721] NWDAF: Network Data Analytics Function

[0722] OAM: Operations and Management

[0723] OS: Operating System

[0724] OTT: Over the Top

[0725] PCF: Policy Control Function

[0726] PCC: Policy and Charging Control

[0727] PCO: Protocol Configuration Options

[0728] PDR: Packet Detection Rule

[0729] PDU: Protocol Data Unit

[0730] PMF: Performance Measurement Function

[0731] PRS: Positioning Reference Signal

[0732] PRU: Positioning Reference Unit

[0733] PSA: PDU session anchor

[0734] QFI: QoS Flow Identifier (ID)

[0735] QoE: Quality of Experience

[0736] QoS: Quality of Service

[0737] RACH: Random Access Channel

[0738] RAN: Radio Access Network

[0739] RAT: Radio Access Technology

[0740] RLC-AM: Radio Link Control Acknowledge Mode

[0741] RLC-UM: Radio Link Control Unacknowledge Mode

[0742] RSD: Route Selection Descriptor

[0743] SA: Standalone

[0744] SBA: Service-Based Architecture

[0745] SBI: Service-Based Interface

[0746] SCEF: Service Capability Exposure Function

[0747] SCP: Service-Based Communication Proxy

[0748] SCTP: Stream Control Transmission Protocol

[0749] SDAP: Service Data Adaptation Protocol

[0750] SDU: Service Data Unit

[0751] SIM: Subscriber Identity Module

[0752] SLA: Service Level Agreement

[0753] SM: Session Management

[0754] SMF: Session Management Function

[0755] SN: Secondary Node

[0756] S-NSSAI: Single Network Slice Selection Assistance Information

[0757] SRS: Sounding Reference Signal

[0758] SSC: Session and Service Continuity

[0759] SUPI: Subscription Permanent Identifier

[0760] TAI: Tracking Area Identity

[0761] TE: Terminal Equipment

[0762] TM: Transparent Mode

[0763] TS: Technical Specification

[0764] UDM: Unified Data Manager

[0765] UDR: Unified Data Repository

[0766] UE: User Equipment

[0767] UL: Uplink

[0768] UM: Unacknowledged Mode

[0769] UP: User Plane

[0770] UPF: User Plane Function

[0771] URLLC: Ultra-Reliable and Low-Latency Communication

[0772] URSP: UE Route Selection Policy

[0773] XRM: Extended Reality and Media

[0774] 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 or example 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.

[0775] 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.

[0776] 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 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 and / or aspect 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 signal carried over a wired or wireless connection.

[0777] While the present disclosure has been shown, illustrated 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 disclosure.

[0778] The reader's 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.

[0779] Various features and examples of the present disclosure are described in the following Annex.

Claims

1.A method performed by a user equipment (UE) in a wireless communication system, the method comprising:receiving, from a data collection function (DCF), a data collection request;performing data collection for artificial intelligence and machine learning (AIML) model training based on the data collection request;initiating a user plane connection establishment for a data transfer via a user plane; andtransferring, to the DCF, AIML data associated with the data collection for the AIML model training via the user plane.2.The method of claim 1,wherein the data collection request includes information indicating the user plane.3.The method of claim 1,wherein the AIML data are filtered based on a user consent and subject to an operator policy.4.The method of claim 1, further comprising:deciding to terminate the data collection or the transferring of the AIML data.5.A method performed by a data collection function (DCF) in a wireless communication system, the method comprising:transmitting, to a user equipment (UE), a data collection request;receiving, from the UE, artificial intelligence and machine learning (AIML) data collected based on the data collection request for AIML model training; andtransmitting, to an AIML server, the AIML data for the AIML model training,wherein the AIML data are received via a user plane that is established based on a user plane connection establishment initiated by the UE.6.The method of claim 5,wherein the data collection request includes information indicating the user plane.7.The method of claim 5,wherein the AIML data are filtered based on a user consent and subject to an operator policy.8.The method of claim 5, further comprising:deciding to terminate a data collection based on the data collection request or the transferring of the AIML data.9.A user equipment (UE) in a wireless communication system, the UE comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the UE to:receive, from a data collection function (DCF), a data collection request,perform data collection for artificial intelligence and machine learning (AIML) model training based on the data collection request,initiate a user plane connection establishment for a data transfer via a user plane, andtransfer, to the DCF, AIML data associated with the data collection for the AIML model training via the user plane.10.The UE of claim 9,wherein the data collection request includes information indicating the user plane.11.The UE of claim 9,wherein the AIML data are filtered based on a user consent and subject to an operator policy.12.The UE of claim 9, wherein the instructions executable by the at least one processor individually or in any combination further cause the UE to:decide to terminate the data collection or the transferring of the AIML data.13.A data collection function (DCF) in a wireless communication system, the DCF comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the DCF to:transmit, to a user equipment (UE), a data collection request,receive, from the UE, artificial intelligence and machine learning (AIML) data collected based on the data collection request for AIML model training, andtransmit, to an AIML server, the AIML data for the AIML model training,wherein the AIML data are received via a user plane that is established based on a user plane connection establishment initiated by the UE.14.The DCF of claim 13,wherein the data collection request includes information indicating the user plane, andwherein the AIML data are filtered based on a user consent and subject to an operator policy.15.The DCF of claim 13, wherein the instructions executable by the at least one processor individually or in any combination further cause the DCF to:decide to terminate a data collection based on the data collection request or the transferring of the AIML data.

Images