Method and apparatus for artificial intelligence related data transmission in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a terminal in a wireless communication system includes receiving, from a base station, a message for a data collection associated with a model, performing the data collection corresponding to at least one identifier (ID), and transmitting, to the base station, information on at least one model corresponding to the at least one ID, wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.

Description

METHOD AND APPARATUS FOR ARTIFICIAL INTELLIGENCE RELATED DATA TRANSMISSION IN A WIRELESS COMMUNICATION SYSTEM

[0001] The present invention relates to AI / ML data transport mechanisms.

[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] 5th generation (5G) or new radio (NR) mobile communications is recently gathering increased momentum with all the worldwide technical activities on the various candidate technologies from industry and academia. The candidate enablers for the 5G / NR mobile communications include massive antenna technologies, from legacy cellular frequency bands up to high frequencies, to provide beamforming gain and support increased capacity, new waveform (e.g., a new radio access technology (RAT)) to flexibly accommodate various services / applications with different requirements, new multiple access schemes to support massive connections, and so on.

[0009] In line with development of the communication systems, there is a need for artificial intelligence or machine learning related data transmission.

[0010] The technical subjects pursued in the disclosure may not be limited to the above mentioned technical subjects, and other technical subjects which are not mentioned may be clearly understood, through the following descriptions, by those skilled in the art to which the disclosure pertains.

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

[0012] According to embodiments of the present disclosure, a method of managing AI / ML data within a telecommunication system is provided. The method comprises a network and a User Equipment, UE, wherein said AI / ML data is explicitly identified as such by means of the provision of one or more of explicit signalling and the provision of assistance information, allowing a particular system entity to recognise the AI / ML data and to process it accordingly.

[0013] According to embodiments of the present disclosure, wherein the explicit signalling comprises NAS or RRC signalling from the network to the UE.

[0014] According to embodiments of the present disclosure, wherein the assistance information comprises one or more of timestamp, location, data session ID, data purpose, reason for data update, data version number and last update.

[0015] According to embodiments of the present disclosure, a method of using a User Plane, UP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network is provided, wherein the AI / ML data is carried by means of at least one of:

[0016] · A Local Area Data Network, LADN; and Service Data Adaptation Protocol, SDAP.

[0017] According to embodiments of the present disclosure, wherein if the AI / ML data is carried by means of SDAP, there is an SDAP entity configured for each LADN PDU session for AI / ML data.

[0018] According to embodiments of the present disclosure, a method of using a Control Plane, CP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network is provided, wherein either:

[0019] · a dedicated Network Function, NF, is provided to host the AI / ML data and a specific NAS message is provided for this purpose; or

[0020] · AI / ML data is exchanged via the Session Management Function, SMF, via the use of a UL / DL NAS TRANSPORT message.

[0021] According to embodiments of the present disclosure, wherein the UE and network exchange capability information regarding one or more supported techniques for exchanging AI / ML data.

[0022] According to embodiments of the present disclosure, a method performed by a terminal in a wireless communication system is provided, the method comprises:

[0023] receiving, from a base station, a message for a data collection associated with a model;

[0024] performing the data collection corresponding to at least one identifier (ID); and

[0025] transmitting, to the base station, information on at least one model corresponding to the at least one ID,

[0026] wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.

[0027] According to embodiments of the present disclosure, the method further comprising transmitting, to the base station, information on a model functionality.

[0028] According to embodiments of the present disclosure, wherein the model is an artificial intelligence (AI) model or a machine learning (ML) model.

[0029] According to embodiments of the present disclosure, wherein at least one of a collected data, the information on the configuration associated with the data collection, or the information on the at least one ID is transmitted via a user plane (UP).

[0030] According to embodiments of the present disclosure, a method performed by a base station in a wireless communication system is provided, the method comprises:

[0031] transmitting, to a terminal, a message for a data collection associated with a model; and

[0032] receiving, from the terminal, information on at least one model corresponding to at least one identifier (ID),

[0033] wherein the data collection is performed corresponding to the at least one ID, and

[0034] wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.

[0035] According to embodiments of the present disclosure, a terminal in a wireless communication system is provided, the terminal comprises: a transceiver; and at least one processor coupled with the transceiver and configured to:

[0036] receive, from a base station, a message for a data collection associated with a model, perform the data collection corresponding to at least one identifier (ID), and transmit, to the base station, information on at least one model corresponding to the at least one ID, wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.

[0037] According to embodiments of the present disclosure, a base station in a wireless communication system is provided, the base station comprises:

[0038] a transceiver; and at least one processor coupled with the transceiver and configured to: transmit, to a terminal, a message for a data collection associated with a model, and receive, from the terminal, information on at least one model corresponding to at least one identifier (ID), wherein the data collection is performed corresponding to the at least one ID, and wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.

[0039] AI / ML Operations

[0040] Machine Learning Operations (MLOps) is a system of processes for the end-to-end AI / ML lifecycle management (LCM) at scale. These processes ensure that the AI / ML model can be scaled for a large user base and achieve accurate performance. The MLOps processes can be split into three categories [1].

[0041] ·Data Preparation:

[0042] This category involvesdata collection, data reporting, data analysis, data validation, feature engineering and data splitting. Using data collection to collect data from a variety of sources, data analysis to analyzing data to identify patterns and relationships, data validation is the process of verifying that the data is accurate and consistent. Through feature engineering, new features can be developed from existing data and this can enhance the model's accuracy. Using data splitting to separate the data into train, test, and validation sets to ensure the model is correctly trained.

[0043] ·Model Development:

[0044] This category involvesmodel configuration, model training and model validation. The data scientist implements different algorithms with the prepared data to train various ML models. In addition, you subject the implemented algorithms to hyper-parameter tuning to obtain the best performing ML model. The output of this step is a trained model. Next step to validate model to be deployed in the production environment.

[0045] ·Rollout:

[0046] This category involvesmodel deploying, model serving, model monitoring and model re-training. The validated model is deployed to a production environment to serve predictions. The model deployment can be REST API micro service to serve online predictions or an embedded model to an edge or mobile device. The model predictive performance is monitored to potentially invoke a new iteration in the ML process.

[0047] Figure 1 schematically depicts an example of different stages of data preparation for AI / ML model.

[0048] Data is the backbone of AI / ML algorithms. Therefore, high-quality data is needed for any AI / ML project, a low-quality dataset never produces a high-quality AI model. Quality Data is described as the filtered, cleansed and contextualized form of massive dataset. Modern AI / ML models have become data-hungry and computationally expensive. Such models keep performing better as the size of the training data increases. However, training on large datasets has significantly increased end-to-end training times, computational power and energy consumption.

[0049] Many AI projects struggle with the data collection because of several common issues. For example:

[0050] -Incomplete data

[0051] -Unstructured data

[0052] -Duplicated data

[0053] -Biased data

[0054] -Imbalanced data

[0055] -Noisy data

[0056] -High-dimensional data

[0057] 3GPP Background Information

[0058] The following provides a selection of 3GPP agreements on AI / ML work in working groups RAN1, RAN2 and RAN3, that is related to this invention.

[0059] RAN1 agreements on Study Item on AI / ML for NR Air Interface [RP-213599]: Refer to Appendix I;

[0060] RAN2 agreements on Study Item on AI / ML for NR Air Interface [RP-213599]: Refer to Appendix II; and

[0061] RAN3 agreement on AI / ML for NG-RAN work item: Refer to Appendix III.

[0062] Problem Statement

[0063] 3GPP has started studying the benefits of integration of AI / ML solutions to communications networks, in order to improve network operations.

[0064] 3GPP working groups RAN1 and RAN2 are studying data collection requirements, for different AI / ML model Life Cycle Management (LCM) purposes per use case, for aspects such as data content, data size, and data latency. For example, data for model training may have less latency constraint on data collection compared with model inference or model monitoring.

[0065] For any AI / ML operation, data needs to be collected and in many cases transferred from one entity to another. The data may be training data, validation data and / or data for inference - hereafter referred to as data.

[0066] A common transport mechanism is the user plane where, for example, an IP connection is used to transport data. Such mechanisms assume a communication between a device and an application server (AS) somewhere in the Internet. However, AI / ML data for RAN related operation may need data from within the network. How such data should be transferred, e.g. between a UE and the NG-RAN has not been described, at least not adequately and not for all scenarios. One such missing scenario is the case of certain UEs which do not support user plane i.e. they only support the control plane. These devices therefore cannot use the common user plane approach for data transport.

[0067] An aim of an embodiment of the present invention is to provide solutions related to the following issues:

[0068] ·Data transport mechanisms over the user plane (for UEs that support user plane) where such solutions have not been described yet; and

[0069] ·Data transport mechanisms over the control plane - for UEs which don't support the user plane.

[0070] The present disclosure provides an effective and efficient method for transmitting AI / ML related data. Advantageous effects obtainable from the disclosure may not be limited to the above mentioned effects, and other effects which are not mentioned may be clearly understood, through the following descriptions, by those skilled in the art to which the disclosure pertains.

[0071] For a better understanding of the invention, and to show how exemplary embodiments of the same may be brought into effect, reference will be made, by way of example only, to the accompanying diagrammatic Figures, in which:

[0072] Figure 1 schematically depicts an example of different stages of data preparation for AI / ML model;

[0073] Figure 2 schematically depicts an example on DL SDAP for AI / ML Data PDU of DL LADN session for AI / ML data with SDAP header; and

[0074] Figure 3 schematically depicts an on UL SDAP for AI / ML Data PDU of UL LADN session for AI / ML data with SDAP header.

[0075] Figure 4 illustrates a structure of a terminal in a wireless communication system according to an embodiment of the disclosure; and

[0076] Figure 5 illustrates a structure of a base station in a wireless communication system according to an embodiment of the disclosure.

[0077] According to the present invention there is provided a method, as set forth in the appended claims. Also provided is a network. Other features of the invention will be apparent from the dependent claims, and the description that follows.

[0078] According to a first aspect of the present invention, there is provided a method of managing AI / ML data within a telecommunication system, comprising a network and a User Equipment, UE, wherein said AI / ML data is explicitly identified as such by means of the provision of one or more of explicit signalling and the provision of assistance information, allowing a particular system entity to recognise the AI / ML data and to process it accordingly.

[0079] In an embodiment, the explicit signalling comprises NAS or RRC signalling from the network to the UE.

[0080] In an embodiment, the assistance information comprises one or more of timestamp, location, data session ID, data purpose, reason for data update, data version number and last update.

[0081] According to a second aspect of the present invention, there is provided a method of using a User Plane, UP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network, wherein the AI / ML data is carried by means of at least one of:

[0082] · A Local Area Data Network, LADN; and

[0083] · Service Data Adaptation Protocol, SDAP.

[0084] In an embodiment, if the AI / ML data is carried by means of SDAP, there is an SDAP entity configured for each LADN PDU session for AI / ML data

[0085] According to a third aspect of the present invention, there is provided a method of using a Control Plane, CP, in a telecommunication system to transfer AI / ML data in either direction between a UE and a network, wherein either:

[0086] · a dedicated Network Function, NF, is provided to host the AI / ML data and a specific NAS message is provided for this purpose; or

[0087] · AI / ML data is exchanged via the Session Management Function, SMF, via the use of a UL / DL NAS TRANSPORT message.

[0088] In an embodiment, the UE and network exchange capability information regarding one or more supported techniques for exchanging AI / ML data.

[0089] According to a fourth aspect of the present invention, there is provided apparatus arranged to perform the method of any preceding aspect.

[0090] Solutions

[0091] The following are the proposed solutions in this invention which can be used in any order or combination and are not just limited to a particular system such as 5G but can also be used in other systems such as 4G, 6G, etc.

[0092] User plane (UP) solution options

[0093] The following provides solutions for data transport based on UP mechanisms.

[0094] Use of local area data network to get data for RAN related AI / ML operations

[0095] This section provides that the AI / ML data should be local to the UE's location. The AI / ML data may by exchanged with at least one NG-RAN node that is in (or associated with) the UE's location and the at least one NG-RAN node is involved in either sending and / or receiving data from the UE for an AI / ML application and / or use case. Hereafter, the UE's location may refer to a location in at least one cell, at least one Tracking Area (TA), RAN Notification Area (RNA), Registration Area (RA), and / or a country, PLMN, etc.

[0096] The UE may be configured with an LADN DNN (or LADN DNN and S-NSSAI) information for AI / ML data for any RAN related use case and / or application. Hereafter, LADN information may refer to LADN DNN, or LADN DNN and S-NSSAI information.

[0097] When the UE is in the location, e.g. in the tracking area (TA) which matches the tracking area identity (TAI) that is associated with the LADN DNN (or LADN DNN and S-NSSAI), then the UE may establish a PDU session for LADN where the UE then gets or sends data for RAN AI / ML operations. In this case, it is proposed that a local AS should be used by the network to contain the AI / ML data and as such the UE would see or consider this AS like any other AS on the Internet but the difference is that it is quite known to the UE that the PDU session for LADN is to be used for AI / ML data. This information, or this awareness, about the LADN PDU session being for AI / ML data for RAN applications may be configured in the UE.

[0098] Alternatively, the RAN (i.e. NG-RAN(s) / gNB(s)) may broadcast via system information (e.g. periodically and / or on-demand) at least any of the following indications:

[0099] ·An indication that there is support for a local PDU session for AI / ML for RAN. For example, the NG-RAN provides a flag '1 / 0' indicating whether a given cell (or more than one cell) supports / does not support a local PDU session for AI / ML. In another example, the indication may be provided using existing and / or newly defined SIBs.

[0100] ·The LADN information that can be used by the UE to get AI / ML data for RAN. For example, the NG-RAN provides a flag '1 / 0' indicating whether a given cell (or more than one cell) provides / does not provide LADN information, or an indication whether LADN PDU session can be used for AI / ML data. In another example, the indication (and / or the LADN information) may be provided using existing and / or newly defined SIBs. In another example, the LADN information, or an indication whether LADN PDU session can be used for AI / ML data, may be provided to the UE via on-demand broadcast of the information following the UE request of the information. In another example, the LADN information, or an indication whether LADN PDU session can be used for AI / ML data, may be multicast to a group of UEs that are expecting to get AI / ML data from RAN.

[0101] Alternatively, the UE may receive an indication from the network e.g. using existing (and / or newly defined) dedicated signaling / messages (NAS and / or RRC signaling) that the AI / ML data can be sent and / or received using a local PDU session. The messages may also contain the actual LADN information.

[0102] Upon receipt of an indication that AI / ML data is available for the UE, or can be uploaded and / or downloaded by the UE, using a local PDU session, the UE may take any of the following actions:

[0103] - The UE may request the specific LADN information from the network, using any NAS or RRC message, where the message may be a new or existing message

[0104] - The UE may indicate that the reason for the request is for AI / ML data

[0105] ·The UE may establish a PDU session for LADN using an LADN information that the UE has received (via broadcast method, dedicated NAS / RRC message method, and / or based on pre-configured information in the UE)

[0106] ·As part of the PDU session establishment, the UE indicates e.g. with a new IE or field, that the PDU session is for AI / ML data (optionally for RAN application). The network should also indicate that the session is for AI / ML, where for example the indication may be introduced in the 5GSM NAS message e.g. in the PDU Session Establishment Accept message. The UE should store an indication that the particular PDU session is for AI / ML either based on knowledge of the LADN information being for RAN AI / ML or based on an indication that is received e.g. from the network in any NAS or RRC message

[0107] ·When a PDU session for LADN (for AI / ML data) has been established, the UE may then connect with the local AS to get or send data

[0108] ·Upon reception of any AI / ML data in the UE, the UE need not send the data to the upper layers. The data that is received should be provided to the lower layers e.g. to the RRC layer or an AI / ML entity in the UE, where this entity is not an application client like a normal application client which resides in the upper layers of the UE

[0109] Note that this solution re-uses the existing functionalities as much as possible. The network operator should deploy a local AS that can be accessed by a local PDU session (e.g. a PDU session for LADN) which the UE can use to get or exchange data based on the concept of a PDU session that may be of type IP, Ethernet, non-IP, etc.

[0110] The UE may be informed, based on broadcast and / or dedicated signaling (at NAS and / or RRC) about the scope of the LADN PDU session e.g. which cells, TAI and / or NG-RAN nodes (or any other location) provide access to the session. As such, when the UE determines that it has moved out of the area that enables access to the LADN PDU session (for AI / ML), the UE may take any of the actions previously listed e.g. to establish a new session in the new area which does not provide access to the previous session and / or AS for AI / ML data.

[0111] Alternatively, the UE may use a Fully qualified domain name (FQDN) to get the address of an AI / ML data application server that can be connected with to exchange AI / ML data with. The UE may use DNS to discover an AS for exchange of AI / ML data.

[0112] In this solution, how the network populates the local AS with RAN AI / ML data is out of scope, or it may be implementation specific or may be based on operation and management procedures. Similarly, how the NG-RAN node becomes aware of data from a UE being sent or transferred to the local AS is based on implementation specific aspects or based on operation and management procedures. Alternatively, when the UE sends data to the local AS, the UE may inform the NG-RAN that it has uploaded data to the AS. The UE may provide an indication and / or identification of the data content that it has uploaded, optionally with other parameters such as timestamp, location, data session ID, data purpose (e.g. training, monitoring, other life-cycle-management (LCM) purpose), etc. In one example, the UE provides to the NG-RAN information related to the model (and / or model functionality) identification in relation to the data. In another example, In another example, the information related to the model (and / or model functionality) may identify the data explicitly or implicitly. The NG-RAN may use this information to fetch data from individual UEs or group of UEs (for which group ID and / or other identification may be used) accordingly. In another example the NG-RAN may use this information to fetch data from the AS.

[0113] The UE may use new and / or existing RRC messages to inform the NG-RAN that data has been updated to the local AS and provides any form of identification in relation to the data that has been uploaded. In one example, the model (and / or model functionality) identification in relation to the data. Optionally, the UE may provide other (additional) parameters related to the data, such as timestamp, location, data session ID, data purpose (e.g. training, monitoring, other life-cycle-management (LCM) purpose), and / or reason for the data update, data version number, last update, etc. The NG-RAN may then use any received identification information to fetch the data, noting that the identification information may be any identification such as a UE identity (NAS level or RRC level), AI / ML session identity, use case identity, model identification, and / or model functionality (or functionality) identification, etc.

[0114] Similarly, when the NG-RAN updates AI / ML data which is relevant for the UEs, or at least one UE, the NG-RAN may indicate to (or informs) the UE(s) about the update. In a related example, the indication may be sent together with (or separately) information related to the changes (or updates) in the AI / ML data which is relevant to the UEs. Optionally, the NG-RAN may provide other (additional) parameters related to the data, such as timestamp, location, data session ID, data purpose (e.g. training, monitoring, other life-cycle-management (LCM) purpose), and / or reason for the data update, data version number, last update, etc. The indication may be done with dedicated (existing and / or newly defined RRC signaling / messages) and / or broadcast signaling (e.g. periodically and / or on-demand, using existing and / or new SIBs) and / or MAC CE. The NG-RAN may also provide an identification which is related to the updated data. In one example, the NG-RAN provides to the UE information on the model (and / or model functionality) identification in relation to the data. In another example, the information related to the model (and / or model functionality) may identify the data explicitly or implicitly. The UE may receive, e.g. via broadcast or dedicated signaling, an indication that AI / ML data has been updated and may also receive related identification information. Based on this, the UE may then attempt to fetch the updated data and may use the identification information to request the particular updated data.

[0115] There is also provided an interface between the AS and the NG-RAN. The NG-RAN may use this interface to upload data for a UE, or to fetch data that that was uploaded by any UE where the NG-RAN may use the identification information to fetch such a data and provide this information on the interface (or protocol) connecting the NG-RAN with the AS for identifying the data of relevance.

[0116] Note that the term NG-RAN may also refer to the network which in turn may refer to either RAN nodes and / or core network nodes or any other new nodes.

[0117] Note that the UE and the network (e.g. NG-RAN, AMF, SMF, UPF, UDM, etc.) may exchange capability information to indicate support of AI / ML data transport using a PDU session for LADN. The UE and / or the network may behave as described herein when both entities support the capability. In one option, if the capability is negotiated with the core network, then the core network (e.g. AMF) may provide this capability to the NG-RAN where the core network may indicate that the UE supports this feature and hence the NG-RAN may operate as described herein, in relation to the UE in question, based on this indication. In another example, the UE provides this capability directly to the NG-RAN based on request from the NG-RAN. In another example, the UE provides the capability to the NG-RAN.

[0118] Hereafter, the UE and / or network capability to support AI / ML data transport using PDU session for LADN, is exchanged using any suitable existing (and / or newly defined) RRC and / or NAS signaling / messages.

[0119] In one example, the network may only offer the service of AI / ML data transport using a PDU session to the UE (or groups of UEs), that report the capability to support this service. In another example, the network may configure the UE (or groups of UEs) that support this capability to behave as described in previous examples and participate in transport of AI / ML data using PDU session for LADN.

[0120] Use of Service Data Adaptation Protocol (SDAP) to exchange AI / ML data

[0121] The following describes the use of the SDAP protocol as a means to exchange AI / ML data.

[0122] SDAP entity configuration, establishment and release:

[0123] There is an SDAP entity configured for each LADN PDU session for AI / ML data. Note that although LADN PDU session for AI / ML may be used, the AI / ML data may be sent directly in the SDAP protocol as described next.

[0124] The network may request the UE to establish a SDAP entity for LADN PDU session for AI / ML data. In one example, the RRC requests establishment of an SDAP entity for LADN PDU session for AI / ML data.

[0125] The UE may establish a SDAP entity for LADN PDU session for AI / ML data.

[0126] The network may request the UE to release a SDAP entity for LADN PDU session for AI / ML data. In one example, the RRC requests release of an SDAP entity for LADN PDU session for AI / ML data.

[0127] The UE may release a SDAP entity for LADN PDU session for AI / ML data.

[0128] DL SDAP LADN PDU For AI / ML Data with SDAP header

[0129] Figure 2 shows an example format of SDAP LADN PDU session of DL for AI / ML data with SDAP header being configured.

[0130] UL SDAP LADN PDU For AI / ML Data with SDAP header

[0131] Figure 3 shows an example format of SDAP LADN PDU session of UL for AI / ML data with SDAP header being configured.

[0132] In one example, the UL SDAP and DL SDAP PDU for AI / ML data may use (or contain) an existing Quality of Service (QoS) Flow ID (QFI) header for the identification of the QoS flow related to related to (or associated with) the AI / ML data. Optionally, the DL SDAP PDU may also use other headers (but not limited to those headers) such as Reflective QoS indication (RQI), Reflective QoS flow to DRB Identifier (RDI).

[0133] In alternative example, the UL SDAP and DL SDAP PDU for AI / ML data may use (or contain) a newly defined header, namely LQDI (LDAN QFI, and / or any other suitable naming), for the identification of the QoS flow related to (or associated with) the AI / ML data. LQFI (LADN QFI)

[0134] Length: example, 6 bits

[0135] The LQFI field indicates the ID of the LADN QoS flow to which the SDAP PDU belongs (i.e. LADN PDU session).

[0136] Note for the definition of SDAP parameters and headers, such as DATA, D / C, QFI, R, refer to Annex IV, or 3GPP TS 37.324 [5].

[0137] Control plane (CP) solution options

[0138] Use of a new Network Function and a new NAS message for data transport

[0139] This solution proposes to use the NAS as a transport mechanism for AI / ML data.

[0140] A new data collection network function (or entity) can be defined such that the entity can host the AI / ML data. However, the transport of this data should be done using a NAS protocol. To do so, a new NAS message may be defined and used for this purpose. For example, a new (UPLINK / DOWNLINK) AIML DATA TRANSPORT message may be defined for this purpose. It should be noted that the name does not matter but any other name may be used, and that this name is to be considered as an example.

[0141] Note that the existing UL / DL NAS TRANSPORT message may also be used for this purpose. However, a new payload type can be defined for the Payload type container IE (see [5]) such that it indicates that the contents of the Payload container IE (see [5]) is AI / ML data. The UE or the AMF, when needing to send AI / ML data, should therefore set the Payload container type IE to a value which indicates AI / ML data, e.g. a new "AI / ML data content" value may be defined for this purpose. The UE or the AMF should then include the AI / ML data content in the Payload container IE, and optionally include any other parameter as new fields or within the Payload container IE. The UE or the AMF should then send the NAS message accordingly.

[0142] The NAS message may also contain any of the following information:

[0143] ·Identification information which can be used to identify any combination of the following

[0144] - The UE, or group of UEs

[0145] - An AI / ML session or use case

[0146] - A particular AI / ML data set, optionally whether the data is for training, validation, testing, inference, etc

[0147] · Any other information that can be defined and used for specific contexts such as timestamp, location, application of the data, use of the data, purpose, etc

[0148] ·Sequence number that can be used to define or track the sequence of data that is being used / sent / exchanged, where the sequence may be updated at every transmission

[0149] ·An indication if the data is to be provided to the upper layers, or the lower layers in the UE

[0150] Note that when sending the data, the UE or the network may populate the necessarily fields of a NAS message such that the information listed above may be provided to the recipient, where the sender may be either a UE or the network (e.g. AMF).

[0151] Upon reception of the NAS message with AI / ML data, the recipient (UE or AMF) may verify the parameters which are included to determine which UE or application or context is the data for.

[0152] Note that the UE and the network (e.g. the AMF) should exchange capability information about the support of this feature i.e. the feature of sending AI / ML data over NAS. The UE may be expected to support this by default, e.g. any UE which does not support UP may be expected to support this by default. Alternatively, the UE may indicate that it supports AI / ML data transport over NAS by means of a new capability indication that can be defined as part of the 5GMM capability IE which the UE may include in a NAS message such as the Registration Request message.

[0153] Similarly, the network may indicate it supports this feature by defining and using a new indication in any IE which can be sent in any NAS message. For example, the 5GS network feature support IE can be used for this purpose where a new bit may be defined to indicate if the feature is supported. The IE can be sent in the Registration Accept message or any other NAS message.

[0154] The UE may be configured to use the NAS protocol for transporting or exchanging of AI / ML data, or the UE may do so if the UE supports this feature and optionally the network also supports this feature and optionally has allowed it for the UE.

[0155] The lower layers in the UE may collect AI / ML data that needs to be sent to the network. The lower layers in the UE should provide the AI / ML data to the NAS and indicate that this is for AI / ML data. The NAS can then include the AI / ML data in the appropriate NAS message, and optionally include other information and then send the data.

[0156] The AMF may receive a NAS message which contains AI / ML data. The AMF may verify the contents to determine other parameters that are associated with the AI / ML data such as any combination of those that have been listed above. The AMF may forward the data and the other parameters (or information e.g. UE identity, AI / ML identity, session identity, timestamp, NG-RAN identity such as cell identity, etc) to the new proposed NF. The AMF may inform the NG-RAN that new data has been sent by any UE, or the UE may inform the NG-RAN about this as has been proposed herein. The NG-RAN, either based on the indication from the AMF, or the UE, may them attempt to get and / or use the data. The UE or AMF may provide - to the NG-RAN - any other information to identify the data which has been provided and the NG-RAN in turn may use this information to fetch or use the particular data in question.

[0157] The NG-RAN may be configured with information to connect with the new NF and to optionally fetch or upload data. Alternatively, the AMF may provide the AI / ML data to the NG-RAN when such data is sent by a UE.

[0158] When the UE receives a NAS message which contains AI / ML data, e.g. the new NAS message which has been set out, the UE may determine that the AI / ML data is for the lower layers based on any indication in the NAS message, or based on a default behaviour. The UE (e.g. the NAS entity) may then provide the data and / or other information to the lower layers.

[0159] Use of existing messages and data is exchanged via the SMF

[0160] In this alternative, the new NF for AI / ML data may be connected to an SMF. The NG-RAN may be configured to connect to this new NF using any protocol and the NG-RAN may use this information or protocol to get or upload data to the new NF. The AMF or SMF or UE may notify the NG-RAN when data is sent by a UE, optionally with any additional parameters such as those previously listed.

[0161] For this solution, the UE may be preconfigured with a well-known DNN and / or S-NSSAI to be used for sending AI / ML data, or a well-known (or predefined) PDU session ID such that it is known that this PDU session ID is associated with a PDU session for sending (or exchanging) AI / ML data. The use of the specific PDU session ID means that the data contents are for AI / ML. The UE and the network may also exchange capability information for this solution option as has been described earlier.

[0162] To send actual AI / ML data, the UE or the network may use the existing NAS message e.g. UL / DL NAS TRANSPORT message and include the data as if it is data for CIoT communication. However, the particular PDU session ID would mean that the data is for AI / ML.

[0163] In another alternative, a new payload type can be defined for the Payload type container IE (see [5]) such that it indicates that the contents of the Payload container IE (see [5]) is AI / ML data. The UE or the AMF, when needing to send AI / ML data, should therefore set the Payload container type IE to a value which indicates AI / ML data, e.g. a new "AI / ML data content" value may be defined for this purpose. The UE or the AMF should then include the AI / ML data content in the Payload container IE, and optionally include any other parameter as new fields or within the Payload container IE. The UE or the AMF should then send the NAS message accordingly. Note that to send data in the downlink, the SMF receives data from the new NF and then forwards the data to the AMF and includes the PDU session ID. The AMF then forwards the data to the UE using the DL NAS TRANSPORT.

[0164] In the uplink, the UE sends the data and optionally the PDU session ID as has been described earlier. The AMF forwards the data to the SMF which in turn forwards the data to the new NF. The UE or the network may also send other information or parameters in the NAS message.

[0165] References

[0166] [1] https: / cloud.google.com / architecture / mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

[0167] [2] RP-213599, Study on Artificial Intelligence (AI) / Machine Learning (ML) for NR Air Interface.

[0168] [3] 3GPP TS 38.413, Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP)

[0169] [4] 3GPP TS 38.423, NG-RAN; Xn Application Protocol (XnAP).

[0170] [5] 3GPP TS 37.324 V17.0.0 (2022-03), Service Data Adaptation Protocol (SDAP) specification.

[0171] [6] 3GPP TS 24.501 V18.3.0

[0172] Definitions

[0173] The optional features set out herein may be used either individually or in combination with each other where appropriate and particularly in the combinations as set out in the accompanying claims. The optional features for each aspect or exemplary embodiment of the invention, as set out herein are also applicable to all other aspects or exemplary embodiments of the invention, where appropriate. In other words, the skilled person reading this specification should consider the optional features for each aspect or exemplary embodiment of the invention as interchangeable and combinable between different aspects and exemplary embodiments.

[0174] Notes

[0175] Although a preferred embodiment has been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims and as described above.

[0176] At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as 'component', 'module' or 'unit' used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term "comprising" or "comprises" means including the component(s) specified but not to the exclusion of the presence of others.

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

[0178] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive.

[0179] Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0180] The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

[0181] Appendix I (RAN1 Study Item on AI / ML for NR Air Interface)

[0182] RAN1#109-e Agreements and working assumptions:

[0183]

[0184]

[0185] RAN1#110bis-e Agreements

[0186] Study AI / ML model monitoring for at least the following purposes: model activation, deactivation, selection, switching, fallback, and update (including re-training).

[0187] Study at least the following metrics / methods for AI / ML model monitoring in lifecycle management per use case:

[0188] · Monitoring based on inference accuracy, including metrics related to intermediate KPIs

[0189] i. Monitoring based on system performance, including metrics related to system performance KPIs

[0190] ii. Other monitoring solutions, at least following 2 options.

[0191] ● Monitoring based on data distribution

[0192] a) Input-based: e.g., Monitoring the validity of the AI / ML input, e.g., out-of-distribution detection, drift detection of input data, or something simple like checking SNR, delay spread, etc.

[0193] b) Output-based: e.g., drift detection of output data

[0194] ● Monitoring based on applicable condition

[0195] Note: Model monitoring metric calculation may be done at NW or UE

[0196] RAN1#113 Agreements:

[0197] Consider at least the following aspects and if applicable, the corresponding potential specification impact related to data collection:

[0198] - Measurement configuration and reporting

[0199] - Contents, type and format of data including:

[0200] ○ Data related to model input

[0201] ○ Data related to ground truth

[0202] ○ Quality of the data

[0203] ○ Other information

[0204] - Signaling of assistance information for categorizing the data

[0205] ○ Note: The study should consider the feasibility of disclosure of proprietary information

[0206] - Signaling for data collection procedure

[0207] - Note 1: Use-case specific details can be studied in respective agenda items

[0208] - Note 2: Signaling mechanism details can be studied by appropriate working groups.

[0209] 2.1.2Remaining Open issues

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

[0211] ○ ...

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

[0213] ○ Dataset(s) for training, validation, testing, and inference

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

[0215] ● Evaluate performance benefits of AI / ML based algorithms for the agreed use cases in the final representative set

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

[0217] ○ PHY layer aspects, e.g., (RAN1)

[0218] · 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

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

[0220] Appendix II (RAN2 Study Item on AI / ML for NR Air Interface)

[0221] RAN2#121 agreement:

[0222] → Agreed:

[0223] Aim to at least analyze the feasibility and benefits of model / transfer solutions based on the following:

[0224] Solution 1a: gNB can transfer / deliver AI / ML model(s) to UE via RRC signalling.

[0225] Solution 2a: CN (except LMF) can transfer / deliver AI / ML model(s) to UE via NAS signalling.

[0226] Solution 3a: LMF can transfer / deliver AI / ML model(s) to UE via LPP signalling.

[0227] Solution 1b: gNB can transfer / deliver AI / ML model(s) to UE via UP data.

[0228] Solution 2b: CN (except LMF) can transfer / deliver AI / ML model(s) to UE via UP data.

[0229] Solution 3b: LMF can transfer / deliver AI / ML model(s) to UE via UP data.

[0230] Solution 4: Server (e.g. OAM, OTT) can transfer / delivery AI / ML model(s) to UE (e.g. transparent to 3GPP).

[0231] RAN2#122 agreements:

[0232] Related to data collection, the following was agreed:

[0233] ● RAN 2 assumes that for the data collection in some scenarios (e.g., internal data up to implementation or the existing data are enough), possibly no RAN2 specification effort is needed in some scenarios, e.g. (not exhaustive):

[0234] ○ For model inference of UE-sided model, input data for model inference is available inside the UE.

[0235] ○ For UE-side (real time) monitoring of UE-sided model, performance metrics are available inside the UE. UE can independently monitor a model's performance without any data input from NW.

[0236] ● For the latency requirement of data collection, RAN2 assumes:

[0237] ○ for all types of offline model training (i.e., UE- / NW- / two-sided model training), there is no latency requirement for data collection

[0238] ○ for model inference, when required data comes from other entities, there is a latency requirement for data collection

[0239] ○ for model monitoring, when required monitoring data (e.g., performance metric) comes from the other entities, there is a latency requirement for data collection.

[0240] ● RAN2 assumes that the analysis / selection of the data collection frameworks should focus on the RRC_CONNECTED state (for both data generation and reporting). Analysis and potential enhancement on the non-connected state can be revisited when needed.

[0241] ● For the data generation entity and termination entity deployed at different entities, RAN2 assumes:

[0242] ○ For CSI enhancement and beam management use cases:

[0243] ■ For model training, training data can be generated by UE / gNB and terminated at gNB / OAM / OTT server

[0244] ■ For NW-sided model inference, input data can be generated by UE and terminated at gNB.

[0245] ■ For UE-side model inference, input data / assistance information can be generated by gNB and terminated at UE.

[0246] ■ For model monitoring at NW side, performance metrics can be generated by UE and terminated at gNB.

[0247] ○ For positioning enhancement use case:

[0248] ■ For model training, training data can be generated by UE / gNB and terminated at LMF / OTT server

[0249] ■ For NW-sided model inference, input data can be generated by UE / gNB and terminated at LMF and / or gNB

[0250] ■ For UE-side model inference, input data / assistance information can be generated by LMF / gNB and terminated at the UE

[0251] ■ For model monitoring at NW side, performance metrics can be generated by UE / gNB and terminated at LMF.

[0252] Related to data collection, RAN2 has also agreed to send an LS to RAN1 in R2-2306906, asking RAN1 to express concerns (if any) on the above assumption, and to provide additional information (if any) on the above discussed topics. Additionally, RAN2 asks RAN1 to provide inputs on the following:

[0253] ● The required data content per use case and per LCM purpose, when available, and to what extent said data would / should be specified (in detail).

[0254] ● The reporting type (e.g., periodic, event triggered, other) of the identified data content

[0255] ● The typical size (value or value range) of the identified data content.

[0256] ● The typical latency requirement (value or value range) to transfer the identified data content.

[0257] Related to architectural discussion, the following was agreed:

[0258] ● RAN2 will cover functional architecture in general, e.g. covering both be model based and / or functionality based LCM

[0259] ● Figure 2 is R2-2305327 capturing architectural aspects is agreed with the following assumptions:

[0260] ○ "Model Storage" in the figure is only intended as a reference point (if any) for protocol terminations etc for model transfer / delivery etc. It is not intended to limit where models are actually stored. Add a note for this.

[0261] ○ Remove "Model" in Model Managemt and Model Inference and for the actions / the arrow form Management to Inference (to reduce the risk for misunderstanding).

[0262] ○ Management may be model based management, or functionality based management.

[0263] RAN2#121bis agreements:

[0264] ● Study the applicability (and limitations) of each identified data collection framework for each of the identified LCM purposes, i.e., inference, monitoring and (offline) training. FFS how we do the formatting / presentation of the results.

[0265] ●With more progress on architectural discussion, consider the suitability of each identified data collection framework for the termination points and mapping with the location of LCM purposes / functions (inference, monitoring, (offline) training) considering:

[0266] - Model sidedness (UE side, NW side, two sided) FFS

[0267] - Use case mapping FFS

[0268] Remaining Open issues

[0269] Based on what was discussed during RAN2#122 the following are the open issues:

[0270] ● Architecture; functionality-to-entity mapping,

[0271] ● Life Cycle Management implications from a RAN2 point of view,

[0272] ● Progress with data collection, including suitability analysis of identified collection frameworks, taking into account model sidedness (i.e. UE-sided, NW-sided), the LCM function, and the consumer of the data collection (e.g. UE, gNB, OAM, OTT server). Reflect such analysis in the previously endorsed table.

[0273] ● Continue discussion on model ID handling, and model transfer / delivery

[0274] Appendix III (RAN3 Work Item on AI / ML for NG-RAN)

[0275] RAN3#117bis-e agreements:

[0276] - Procedures used for AI / ML support in the NG-RAN shall be use case agnostic.

[0277] - Legacy information that are used to support AI / ML are transferred via existing legacy procedures (no need to signal them via other procedures)

[0278] - RAN3 will focus on non-split architecture use cases and procedures first and discuss split architecture use cases and procedures when completion for the non-split architecture use cases and procedures is achieved.

[0279] - Signalling describing the capability to support specific information predictions used for AI / ML is not pursued in this release

[0280] - Signalling describing the capability to supports specific AI / ML use cases is not pursued in this release

[0281] - AI / ML capability exchange in NG-RAN can be achieved by means of procedures for AI / ML information request, AI / ML information response and AI / ML Information Request Failure

[0282] - WA: Solutions for AI / ML information exchange over the NG interface are not considered as part of Rel18.

[0283] Xn interface:

[0284] - Introduce a new Class 1 procedure for initiating the reporting of AI / ML Related Information and a Class 2 procedure for Data Reporting of AI / ML Related Information.

[0285] - Reporting options for the new procedure used for AI / ML Related Information to be evaluated on a case-by-case basis. Possible reporting options are one-time and periodic reporting.

[0286] - The new procedure is non-UE associated procedure. If needed, the procedure can be used to capture UE-associated information.

[0287] - The response message of the new procedure for AI / ML Related Information indicates if the requested information can be provided.

[0288] - Support the following UE performance information to be sent for feedback purposes: Average Packet Delay, Average UE Throughput DL, Average UE Throughput UL, Average Packet Error Rate.

[0289] - How to indicate validity time (e.g., implicitly with a new prediction when the previous prediction becomes invalid, explicitly with every prediction in the AI / ML output or by the request to the prediction) shall be discussed on a case by case basis.

[0290] RAN3#118 agreements

[0291] WA: Procedures used for AI / ML support in the NG-RAN shall be "data type agnostic".

[0292] Xn interface:

[0293] The request in the new Class 1 procedure for initiating the reporting of AI / ML Related Information can include an ID assigned by the requesting NG-RAN node to request for reporting, which includes

[0294] - the reporting parameters

[0295] - list of cells to report

[0296] - reporting periodicity

[0297] The response in the new Class 1 procedure for initiating the reporting of AI / ML Related Information can include an ID assigned by the responding NG-RAN node which includes the confirmation on the reporting parameters requested.

[0298] The message in the Class 2 procedure for Data Reporting of AI / ML Related Information can include the corresponding IDs assigned by the NG-RAN nodes, reports result.

[0299] The "Energy Efficiency" metric should be measurable, produced and interpretable by the RAN.

[0300] Start with per node granularity EE and Per cell granularity EE could be considered if it is feasible.

[0301] WA: Take the EE defined in SA5 as the baseline for the energy efficiency of a gNB.What to be transfered between NG-RAN nodes is FFS.

[0302] UE Trajectory Prediction is transferred to the target gNB via the Handover Request.

[0303] Appendix IV (reference to SDAP parameters in TS 37.324 [5])

[0304] 6.3Parameters

[0305] 6.3.1General

[0306] If not otherwise mentioned in the definition of each field, then the bits in the parameters shall be interpreted as follows: the left most bit is the first and most significant bit and the right most bit is the last and least significant bit.

[0307] Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases the bits appear ordered from MSB to LSB when read in the PDU.

[0308] 6.3.2Data

[0309] Length: Variable

[0310] This field includes the SDAP SDU.

[0311] 6.3.3D / C

[0312] Length: 1 bit,

[0313] The D / C bit indicates whether the SDAP PDU is an SDAP Data PDU or an SDAP Control PDU.

[0314] Table 6.3.3-1: D / C field

[0315]

[0316] 6.3.4QFI

[0317] Length: 6 bits

[0318] The QFI field indicates the ID of the QoS flow (TS 23.501 [4]) to which the SDAP PDU belongs.

[0319] 6.3.5R

[0320] Length: 1 bit

[0321] Reserved. In this version of the specification reserved bits shall be set to 0. Reserved bits shall be ignored by the receiver.

[0322] 6.3.6RQI

[0323] Length: 1 bit,

[0324] The RQI bit indicates whether NAS should be informed of the updated of SDF to QoS flow mapping rules (TS 23.501 [4]).

[0325] Table 6.3.6-1: RQI field

[0326]

[0327] FIG. 4 illustrates an example of the structure of a terminal according to an embodiment of the disclosure.

[0328] Referring to FIG. 4, a terminal 400 according to an embodiment of the disclosure may include a controller 401, a transceiver 402, and a memory 403. In the disclosure, the controller 401 of the terminal 400 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0329] The controller 401 may control overall operations of the terminal 400 according to an embodiment provided in this disclosure. For example, the controller 401 may control a signal flow between respective blocks to perform operations according to the drawings (or sequential diagrams or flowcharts) described above.

[0330] The transceiver 402 may transmit and receive signals. For example, the transceiver 402 may transmit a signal to a node or base station and receive a signal from the node or base station according to an embodiment of the disclosure.

[0331] The memory 403 may store at least one of information transmitted and received through the transceiver 402 and information generated through the controller 401. Additionally, the memory 403 may be defined as a storage.

[0332] FIG. 5 illustrates the structure of a base station to which the disclosure may be applied.

[0333] Referring to FIG. 5, a base station 500 according to an embodiment of the disclosure may include a controller 501, a transceiver 502, and a memory 503. In the disclosure, the controller 501 of the base station 500 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0334] The controller 501 may control overall operations according to an embodiment provided in this disclosure. For example, the controller 501 may control a signal flow between respective blocks to perform operations according to the drawings (or sequential diagrams or flowcharts) described above.

[0335] The transceiver 502 may transmit and receive signals. For example, the transceiver 502 may transmit a signal to a terminal or node and receive a signal from the terminal or node according to an embodiment of the disclosure.

[0336] The memory 503 may store at least one of information transmitted and received through the transceiver 502 and information generated through the controller 501. Additionally, the memory 503 may be defined as a storage.

[0337] Methods disclosed in the claims and / or methods according to the embodiments described in the specification of the disclosure may be implemented by hardware, software, or a combination of hardware and software.

[0338] When the methods are implemented by software, a computer-readable storage medium for storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium may be configured for execution by one or more processors within the electronic device. The at least one program may include instructions that cause the electronic device to perform the methods according to various embodiments of the disclosure as defined by the appended claims and / or disclosed herein.

[0339] These programs (software modules or software) may be stored in non-volatile memories including a random access memory and a flash memory, a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a magnetic disc storage device, a compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other type optical storage devices, or a magnetic cassette. Alternatively, any combination of some or all of them may form a memory in which the program is stored. In addition, a plurality of such memories may be included in the electronic device.

[0340] Moreover, the programs may be stored in an attachable storage device which may access the electronic device through communication networks such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), and Storage Area Network (SAN) or a combination thereof. Such a storage device may access the electronic device via an external port.

[0341] Furthermore, a separate storage device on the communication network may access a portable electronic device.

[0342] In the above-described detailed embodiments of the disclosure, an element included in the disclosure is expressed in the singular or the plural according to presented detailed embodiments. However, the singular form or plural form is selected appropriately to the presented situation for the convenience of description, and the disclosure is not limited by elements expressed in the singular or the plural. Therefore, either an element expressed in the plural may also include a single element or an element expressed in the singular may also include multiple elements.

[0343] The embodiments of the disclosure described and shown in the specification and the drawings are merely specific examples that have been presented to easily explain the technical contents of embodiments of the disclosure and help understanding of embodiments of the disclosure, and are not intended to limit the scope of embodiments of the disclosure. That is, it will be apparent to those skilled in the art that other variants based on the technical idea of the disclosure may be implemented.

[0344] Furthermore, the above respective embodiments may be employed in combination, as necessary.

[0345] In the drawings in which methods of the disclosure are described, the order of the description does not always correspond to the order in which steps of each method are performed, and the order relationship between the steps may be changed or the steps may be performed in parallel.

[0346] In the drawings in which methods of the disclosure are described, the order of the description does not always correspond to the order in which steps of each method are performed, and the order relationship between the steps may be changed or the steps may be performed in parallel.

[0347] Furthermore, in methods of the disclosure, some or all of the contents of each embodiment may be combined without departing from the essential spirit and scope of the disclosure.

[0348] The embodiments of the disclosure described and shown in the specification and the drawings are merely specific examples that have been presented to easily explain the technical contents of embodiments of the disclosure and help understanding of embodiments of the disclosure, and are not intended to limit the scope of embodiments of the disclosure. That is, it will be apparent to those skilled in the art that other variants based on the technical idea of the disclosure may be implemented. Furthermore, the above respective embodiments may be employed in combination, as necessary. For example, all embodiments of the disclosure may be partially combined to operate a base station and a terminal.

[0349] Although the present disclosure has been described with various embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.

Claims

1.A method performed by a terminal in a wireless communication system, the method comprising:receiving, from a base station, a message for a data collection associated with a model;performing the data collection corresponding to at least one identifier (ID); andtransmitting, to the base station, information on at least one model corresponding to the at least one ID,wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.2.The method of claim 1, further comprising:transmitting, to the base station, information on a model functionality.3.The method of claim 1,wherein the model is an artificial intelligence (AI) model or a machine learning (ML) model.4.The method of claim 1,wherein at least one of a collected data, the information on the configuration associated with the data collection, or the information on the at least one ID is transmitted via a user plane (UP).5.A method performed by a base station in a wireless communication system, the method comprising:transmitting, to a terminal, a message for a data collection associated with a model; andreceiving, from the terminal, information on at least one model corresponding to at least one identifier (ID),wherein the data collection is performed corresponding to the at least one ID, andwherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.6.The method of claim 5, further comprising:receiving, from the terminal, information on a model functionality.7.The method of claim 5,wherein the model is an artificial intelligence (AI) model or a machine learning (ML) model,wherein at least one of a collected data, the information on the configuration associated with the data collection, or the information on the at least one ID is transmitted via a user plane (UP).8.A terminal in a wireless communication system, the terminal comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:receive, from a base station, a message for a data collection associated with a model,perform the data collection corresponding to at least one identifier (ID), andtransmit, to the base station, information on at least one model corresponding to the at least one ID,wherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.9.The terminal of claim 8, wherein the at least one processor is further configured to:transmit, to the base station, information on a model functionality.10.The terminal of claim 8,wherein the model is an artificial intelligence (AI) model or a machine learning (ML) model.11.The terminal of claim 8,wherein at least one of a collected data, the information on the configuration associated with the data collection, or the information on the at least one ID is transmitted via a user plane (UP).12.A base station in a wireless communication system, the base station comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:transmit, to a terminal, a message for a data collection associated with a model, andreceive, from the terminal, information on at least one model corresponding to at least one identifier (ID),wherein the data collection is performed corresponding to the at least one ID, andwherein the message comprises at least one of information on a configuration associated with the data collection, or information on the at least one ID.13.The base station of claim 12, wherein the at least one processor is further configured to:receive, from the terminal, information on a model functionality.14.The base station of claim 12,wherein the model is an artificial intelligence (AI) model or a machine learning (ML) model.15.The base station of claim 12,wherein at least one of a collected data, the information on the configuration associated with the data collection, or the information on the at least one ID is transmitted via a user plane (UP).

Images