In-band control of user-plane data collection in a cellular communication system
Patent Information
- Application Number
- PCT/US2026/021603
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-05-09
- Filing Date
- 2026-03-30
- Publication Date
- 2026-10-01
Smart Images

Figure US2026021603_01102026_PF_FP_ABST
Abstract
Description
PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00IN-BAND CONTROL OF USER-PLANE DATA COLLECTION IN A CELLULAR COMMUNICATION SYSTEM CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 780,158 entitled “In-Band Control of User-Plane Data Collection in a Cellular Communication System,” filed March 28, 2025, and provisional U.S. Patent Application No. 63 / 803,514 entitled “In-Band Control of User-Plane Data Collection in a Cellular Communication System,” filed May 9, 2025. The entire content of the provisional applications is hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE
[0002] This disclosure relates generally to methods, devices, and articles in wireless communication systems, such as 3GPP communication systems, and in particular to determining and communicating user consent information related to data collection.BACKGROUND
[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
[0004] The 3rd Generation Partnership Project (3GPP) contemplates convergence between communication system functions and Artificial Intelligence (Al) technology, to improve the intelligence at the fifth-generation core (5GC) and the air interface and support network automation. More particularly, 3 GPP has begun to address such topics as data collection (DC), machine learning (ML) model training, analytics inference, etc. These technical areas require collaborative AI / ML mechanisms for coordinating functionality across such domains as user equipment (UE), radio access network (RAN), 5GC, operations and maintenance (0AM), and application functions (AF).PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0005] To support collection of training data for a UE-side model that generates complete inferences at the UE, based on the specifications related to AI / ML for New Radio (NR) air interface documented in 3 GPP TR 38.843, 3 GPP has agreed to study the potential support of UE data collection to meet the requirements for RAN Al support for air interface operation. Today, the remaining issues include enhancement of UE data collection and policy control in a 5G system.
[0006] 3GPP has identified several options for data collection for UE-side model training: (i) a UE collecting and directly transferring training data to an Over-the-Top (OTT) server, in a transparent or non-transparent manner; (ii) the UE collecting training data and transferring the training data to the core network, which then transfers the training data to the OTT server; or (iii) the UE collecting training data and transferring the training data to an 0 AM, which then transfers the relevant data to the OTT server.
[0007] According to TS 23.288, a network data analytics function (NWDAF) can support data collection for network automation based on the UE application data collection framework described in TS 26.531. The NWDAF can interact with a data collection application function (DCAF) in the trusted domain of the operator network, to collect data from a UE application as an input for analytics generation and ML model training. This framework can apply to the UE collecting and directly transferring training data to an OTT server as discussed above, where the DCAF operates as a data collection network function (DCNF) (or simply data collection function (DCF)) that connects to the User-Plane Function (UPF) via an N6 interface.
[0008] To comply with local regulations and operator policy, and before collecting AI / ML model training data, the network should obtain, from the UE, user consent for the corresponding AI / ML-enabled features for various purposes, e.g., AI / ML training for a UE-sided model, a RAN-sided model, or a CN-side model. However, according to TS 23.501 and TS 23.288, the user consent for data collection currently is based on the subscription information stored in a Unified Data Management function (UDM). The subscription information indicates whether the user authorizes data collection and usage of the UE data for a particular purpose, where the purpose for data collection is analytics or model training.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0009] The existing mechanisms are designed for collecting UE data managed and stored in the core network, and the NWDAF generates an AI / ML model or analytics requested by consumers (e.g., an AF, a Policy Control Function (PCF), a Session Management Function (SMF), an Access & Mobility Management Function (AMF), or an 0AM) for network-side inferencing. In addition to collecting training data for AI / ML related to the NR air interface, various other 3GPP features can require training data collection. These 3GPP features can correspond to various use cases and can span various domains such as the RAN, the core network, and cloud applications. These AI / ML-enabled features are expected to enhance resource management for the radio interface, radio resource management, RAN mobility, and core network automation.
[0010] However, currently there are no mechanisms for controlling collection of training data, sensing data, and other types of auxiliary data. For example, there is no mechanism a UE can use to establish a user-plane (UP) data connection, release a UP data connection, suspend a UP data connection, resume a UP data collection, etc., when using a network-provided AI / ML model training service. Further, it is unclear how a network and a UE can interact to control the UE operation for collecting and / or transferring training data for each AI / ML-enabled feature, when the UE enables one or more AI / ML-enabled features or when there are different entities collecting and transferring data to the network for the same AI / ML-enabled feature.SUMMARY
[0011] The techniques discussed below address the challenges outlined above and support controlling UP data collection for AI / ML features, sensing, and other services, using in-band UP messaging.
[0012] An example embodiment of these techniques is a method for facilitating user-plane (UP) data collection in a cellular communication network, the method implemented in a user equipment (UE). The method comprises establishing, with a core network, a user-plane (UP) connection for UP data collection, including establishing a User Datagram Protocol (UDP) tunnel; and communicating, with the CN and over the UDP tunnel, an in-band UP data collection control message (UPDC-CM) related to managing the UP data collection, the control messagePATENT APPLICATION Attorney Docket No.: 31730 / 309152-00including a feature identifier (ID) identifying an artificial intelligence / machine learning (AIZML)-enabled feature to which the UP data collection pertains.
[0013] Another example embodiment of these techniques is a method for facilitating UPDC in a cellular communication network, the method implemented in a UE. The method comprises establishing, with a core network, a UP connection for UP data collection, including establishing a protocol data unit (PDU) session; and communicating, with the CN and in the PDU session, an in-band UP data collection control message (UPDC-CM) related to managing the UP data collection.
[0014] Another example embodiment of these techniques is a method for facilitating UPDC in a cellular communication network, the method implemented in a CN node. The method comprises establishing, with a UE, a UP connection for UP data collection, including establishing a PDU tunnel; and communicating, with the CN and over the UDP tunnel, an in-band UP data collection control message (UPDC-CM) related to managing the UP data collection.
[0015] Another example embodiment of these techniques is a method for facilitating UPDC in a cellular communication network, the method implemented in a CN node. The method comprises establishing, with a UE, a UP connection for UP data collection, including establishing a PDU session; and communicating, with the UE and in the PDU session, an in-band UP data collection control message (UPDC-CM) related to managing the UP data collection.
[0016] Another example embodiment of these techniques is a method for facilitating UPDC in a cellular communication network, the method implemented in a first network endpoint and comprising: establishing, with a second network endpoint, a UP connection for UP data collection; and communicating, with the second network endpoint and over the UP connection, a control message related to managing the UP data collection.
[0017] Still another example embodiment of these techniques is an apparatus comprising processing hardware and configured to implement any of the methods above.BRIEF DESCRIPTION OF THE DRAWINGSPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0018] Fig. l is a block diagram of an example wireless communication system that can implement one or more of the techniques of this disclosure for auxiliary data collection to support sensing functions, artificial intelligence (AI) / machine learning (ML) functions, and other user-plane (UP) data functions;
[0019] Fig. 2 is a block diagram of an example protocol stack according to which the UE of Fig. 1 can communicate with the RAN of Fig. 1;
[0020] Fig. 3A is a service-based representation of the CN architecture, which the system of Fig. 1 can implement, and in which multiple network functions (NFs) implement respective instances of a data collection network function (DCNF) to support the corresponding data collection functions;
[0021] Fig. 3B illustrates another example service-based representation of the CN architecture, in which a DCNF operates as a separate, dedicated NF, from which support other NFs can request data collection services;
[0022] Fig. 3C illustrates another example service-based representation of the CN architecture, in which a Network Data Analytics Function (NWDAF) implements a DCNF, so that other NFs in the core network can request data collection services from the DCNF-enhanced NWDAF;
[0023] Fig. 4 is a reference-point based representation of the CN architecture of Fig. 3B, which the system of Fig. 1 can implement;
[0024] Fig. 5 is a messaging diagram of a high-level procedure according to which a UE manages UP data collection with the network;
[0025] Fig. 6A is a messaging diagram of an enhanced UE Parameters Update procedure that uses a UDM control plane;
[0026] Fig. 6B is a messaging diagram of an enhanced UE Parameters Update procedure that uses a DCNF control plane;
[0027] Fig. 7 illustrates a QUIC packet structure carrying a user-plane data collection control management (UPDC-CM) message over a UDP tunnel;PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0028] Fig. 8 illustrates an example scenario in which a UE establishes a UDP tunnel with the DCNF and sends, via the UDP tunnel, a QUIC DATAGRAM including a UPDC-CM message;
[0029] Fig. 9 illustrates an example scenario in which a UE indicates support of UPDC and UPDC-CM during a registration procedure;
[0030] Fig. 10 illustrates an example scenario in which a UE indicates support of UPDC-CM during when establishing or modifying a PDU session;
[0031] Fig. 11 is a flow diagram of an example method for in-band UPDC-CM transmission or reception, which can be implemented in the UE of Fig. 1;
[0032] Fig. 12 is a flow diagram of an example method for in-band UPDC-CM transmission or reception, which can be implemented in a core network node of Fig. 1;
[0033] Fig. 13 A is a messaging diagram illustrating several example UPDC-CMs which network endpoints can exchange to manage UP data collection; and
[0034] Fig. 13B illustrates a messaging scheme generally similar to that of Fig. 13 A, but with a generic UPDC-CM including an indication of a respective control function.DETAILED DESCRIPTION OF THE DRAWINGSOverview
[0035] Generally speaking, a UE and one or more network functions (NFs) operating in core network (CN) support a framework for managing data collection for auxiliary data such as AI / ML training (or simply “training data”), sensing data, interference data, etc. In the examples below, the network devices communicate the auxiliary data over a user plane (UP), and the auxiliary data is referred below to as “user-plane (UP) data. More generally, network devices can exchange auxiliary data over another plane, e.g., a plane dedicated to transporting auxiliary data. The UE and network nodes discussed below communicate user-plane data collection control messages (UPDC-CM) messages using in-band transmission techniques.
[0036] The network endpoints that communicate UP data can reside in a UE, in a RAN node, or one or more CN nodes.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0037] The training data the UE transmits to a DCNF can apply for various 3 GPP system features and can correspond to various use cases related to RAN, CN, and / or cloud functionality. These AI / ML-enabled features can enhance resource management for the radio interface, radio resource management, RAN mobility, core network automation, etc.
[0038] Some of the specific examples of such features include AI / ML based channel state information (CSI) compression, AI / ML based CSI reference signal (CSI-RS) overhead reduction, AI / ML-based CSI prediction, AI / ML based beam management with downlink beam prediction, direct AI / ML positioning, and AI / ML-assisted positioning for positioning accuracy enhancement, supporting AI / ML based network slicing, AI / ML based coverage and capability optimization, AI / ML based Network Energy Saving (NES) for finer granularities, AI / ML-enabled radio resource management (RRM) measurement prediction, measurement event prediction, AI / ML-enabled quality of service (QoS) sustainability analytics enhancement, QoS and Policy Assistance Analytics enhancement, Packet Data Unit (PDU) session traffic analytics enhancement, movement behavior analytics enhancement, location accuracy analytics enhancement, etc.
[0039] For example, an AI / ML-enabled feature can enhance 3GPP -based sensing services or non-3GPP based sensing services, including sensing for communication and communication for sensing. In this case, the network can collect the sensing data from the UE or a RAN node, for AI / ML-enabled training services the network provides.
[0040] In at least some of the implementations, the AI / ML-enabled features have respective feature identifiers (IDs). A UE in general supports one or more AI / ML-enabled features and uses a feature ID to associate particular training data with a particular AI / ML-enabled feature. More generally, a UE and / or the network (e.g., the CN) can use feature IDs when handling UP data collection and policies that control UP data connections for UP data collection (UPDC). In some cases, for a specific AI / ML-enabled feature, one or more AI / ML models may apply. When only one AI / ML model applies to an ALM- enabled feature, the Feature ID can identify an AI / ML model as a Model ID (and, conversely, the Model ID can identify the feature in this case).PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0041] The approaches discussed below can apply to a UE, a DCNF (which can be implemented in a legacy NF or can operate as a special-purpose, dedicated NF), or both.
[0042] In some implementations, the DCNF operates within an existing (legacy) NF such as for example a Location Management Function (LMF), a PCF, an AMF, or an SMF. The entity in which the DCNF operates can support service operations for UP data collection directly. For example, an AI / ML-enabled feature can be related to positioning accuracy enhancement, and the LMF can operate as the DCNF to provide the UP data collection service for that feature.
[0043] In other implementations, the DCNF is a dedicated NF configured to support operations related to UP data collection for, or on behalf of, the existing (legacy) NFs such as an LFM, a PCF, an AMF, or an SMF for example. According to this approach, NFs can request a UP data collection service from the dedicated DCNF.
[0044] In yet other implementations, a DCNF operates in an NWDAF with coordination functionality, i.e., with a Data Collection Coordination Function (DCCF). According to this approach, NFs operate as consumers and request a data collection service from the NWDAF with the DCCF. Accordingly, the NWDAF with DCCF can enhance operations ofNnwdaj ' DataManagement services, to collect training data from a UE.
[0045] While this disclosure uses 5G networks as an example, one will appreciate that the principles of this disclosure generally apply to 3G networks, 4G networks, 6G networks, and future generations of networks.Example system architecture
[0046] Referring first to Fig. 1, an example wireless communication system 100 can implement one or more of the techniques of this disclosure for managing user consent for UP data collection. The example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110, such as a fifth generation (5G) core (5GC). The base stations 104 and 106 can operate in a RAN 105 connected to the CN 110. The CN 110 can also be implemented as a sixth generation (6G) core or another suitable core network.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0047] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 124 is an ng-eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 126 is an ng-eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5GNR (or simply, “NR”) air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.
[0048] Several network functions (NFs) that make up the CN 110 are discussed below with reference to Figs. 3A-C. The CN 110 includes a DCNF 150, which in different implementations can operate as a separate NF within the CN 110 or as a component of another NF such as an LMF for example. In some implementations, a data collection application function (DCAF) 152 can operate in the trusted domain of the CN 110. The CN 110 can communicate with an application server (AS) 146, which also can operate in a trusted domain. Further, in some scenarios or implementations, one or more NFs of the CN 110 operate on a CN-side Al / ML model 147.
[0049] While not shown in Fig. 1 to avoid clutter, the CN 110 may include processing hardware, which may include one or more general -purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware can include specialpurpose processing units.
[0050] The base station 104 can be equipped with processing hardware that can include one or more general -purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute (not shown).PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00Additionally or alternatively, the processing hardware can include special-purpose processing units.
[0051] The UE 102 is equipped with processing hardware 130 that can include one or more general -purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The UE 102 also includes a transceiver 132 to communicate with the RAN 105 over a radio interface. Further, the UE 102 includes a memory 134 storing a data collection controller 136 configured to implement one or more of the techniques for managing UP data collection discussed in this disclosure. The memory 134 in some cases further stores a UE-side ML model (not shown).
[0052] The base station 106 is equipped with processing hardware 140 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general -purpose processors, and / or special-purpose processing units. The base station 106 also includes a transceiver 142 to communicate with the UE 102 over a radio interface. The base station 106 further includes a memory 134 storing a data collection controller 146 configured to implement one or more of the techniques for managing UP data collection. The base station 104 may be configured in a similar manner as the base station 106.
[0053] The collection controller 136, the data collection controller 146, and the DCNF 150 define network endpoints for UP data collection in the UE 102, the RAN 105, and the CN 110, respectively. The DCNF 150 can collect UP data from the UE 102 or the RAN 105 to train corresponding models, for example.
[0054] Fig. 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB 230 or a gNB 232 (e.g., one or more of the base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MACPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.
[0055] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”
[0056] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.
[0057] Fig. 3A is a service-based representation 300A of an example CN architecture, which the system of Fig. 1 can implement as the CN 110. In the representation 300A, the overall nonroaming reference architecture of the policy and charging control (PCC) framework for the 5GS includes components illustrated using solid lines, and the other components are illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. The components that are outside the PCC framework include a Network Slicing Selection Function (NSSF) 302, a Network Repository Function (NRF) 306, a Unified Data Management (UDM) 308, an Edge Application Server Discovery Function (EASDF) 310, a Network Slice Specific Authentication and Authorization FunctionPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00(NSSAAF) 312, an Authentication Server Function (AUSF) 314, a Service Communication Proxy (SCP) 316, and a Network Slice Admission Control Function (NSACF) 318. The non-PCC architecture further includes the UE 102 and the (R)AN 105.
[0058] The PCC framework in the architecture 300 A includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a network data analytics function (NWDAF) 356, an Application Function (AF) 358, a Policy Control Function (PCF) 360, a Charging Function (CHF) 362, an Access & Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370. The UPF 370 can access a data network (DN) 330, in which an application server (AS) 311 can operate.
[0059] The AMF 364 is generally configured to manage registration, connection, and mobility of a UE (such as the UE 102) and provide transport for session management (SM) messages between the UE 102A and the SMF 366. The SMF 366 is generally configured to manage sessions, allocate IP addresses for UEs, and provides downlink (DL) notifications. In some implementations, the SMF 366 also includes following functionalities for PIN service: providing per-QoS flow non-3GPP QoS assistance information to the UE (e.g., PEGC), and supporting IP address allocation to UE and Packet Detection Rule (PDR) configuration with packet filter set for PIN to UPF for framed routing based on PIN group information from the UDM 308.
[0060] The UDM 308 is generally configured to handle user identification, access authorization based on subscription data, and subscription management. In some implementations, the UDM 308 supports the functionality of PIN group management handling.
[0061] The UDR 352 is generally configured to store subscription-related information, such as subscription data, policy data, structured data for exposure, and application data. The UPF 370 is generally configured to handle packet routing and forwarding. The NEF 354 is generally configured to expose a network’s capabilities and services to authorized third-party applications.
[0062] The AF 358 in some deployment operates in a trusted domain 311 or outside the trusted domain 311, i.e., in a non-trusted domain. The trusted domain 311 is generally internal to the CN 110 and includes such components as the UDM 308, the UDR 352, the PCF 360, the AMF 364, the SMF 366, and the UPF 370. Generally speaking, an AF operating outside the trusted domain 311 (such as operated by an authorized third-party entity) can access the networkPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00functions of the CN 110 only via the NEF 354, whereas an AF operating within the trusted domain 311 can access at least some of the network functions of the CN 110 directly, or may access these functions via the NEF 354 in some deployments.
[0063] According to the architecture 300 A, several NFs implement respective instances of a DCNF. For example, the LMF 245 implements an LMF DCNF 350A, the PCF 360 implements a PCF DCNF 350B, an SMF 366 implements an SMF DCNF 350C, the AMF 364 implements an AMF DCNF 350D, and the UPF 370 implements a UPF DCNF 350E. Each of the DCNF instances 350A-E can support the corresponding NF directly. As a more specific example, the LMF DCNF 35OA provides UP data collection service for an AI / ML-enabled feature for positioning accuracy enhancement.
[0064] Referring to Fig. 3B, a DCNF 35OG according to an architecture 300B operates as a separate, dedicated data collection NF to support service operations for UP data collection on behalf of the legacy NFs (the LMF 345, the PCF 360, the AMF 364, etc.) and special -purpose NFs such as a sensing service network function (SSF) (not shown). In this case, the NFs can request UP data collection service from the dedicated DCNF 350G. For example, the DCNF 350G can provide a UP data collection service for the NWDAF 356 operating as a service consumer, for an AI / ML-enabled feature configured to enhance NWDAF analytics. As another example, the DCNF 350G can operate as a UP data collection service producer to provide UP data collection service for the LMF 345 operating as a service consumer, for an AI / ML-enabled feature configured to enhance positioning accuracy.
[0065] Referring now to Fig. 3C, a DCNF 350G, the NWDAF 356 can implement a DCNF 350H. Here, the other NFs operate as consumers and can request data collection services from the NWDAF 356 equipped with the DCNF 350G. For example, the NWDAF 356 can enhance Nnwdaf Datamanagement services operations to collect training data from the UE 102.
[0066] Fig. 4 is a reference-point based representation 400 of the example 5GS architecture discussed with reference to Fig. 3B. In Fig. 4, the non-roaming reference architecture of the PCC framework for the 5GS is illustrated as blocks and connections with solid lines, and components and connections outside the PCC framework are illustrated using dashed lines. ThePATENT APPLICATION Attorney Docket No.: 31730 / 309152-00interfaces are labeled with the corresponding protocols, e.g., N3 between the RAN 105 and the UPF 370, N1 between the AMF 364 and the UE 102, etc.
[0067] The DCNF 350G can support respective interfaces with the SMF 366, the PCF 360, the NWDAF 356, and other NFs that may require UP data collection services.
[0068] The communication system shown Figs. 1-4 in may include additional, fewer, and / or alternative devices or functionalities, and may be configured to perform additional, fewer, or alternate actions, including functionalities / actions described herein.Example techniques for in-band UP data collection management
[0069] The example below describe a framework for UP Data collection management for a cellular communication system such as a 5G system or a 6G system. As indicated above, training data collection can apply to various AI / ML-enabled features of the system of Fig. 1, in various scenarios, and across different domains such as the RAN 105, the CN 110, the UE 102, and cloud applications operating outside the CN 110. These AI / ML-enabled features operate to enhance resource management across the radio air interface, radio resource management, RAN mobility, and core network automation, etc.
[0070] In a scenario 500 of Fig. 5, the network provides an AI / ML training service, and the network requires and initiates UP data collection. The UP data collection can for example correspond to an AI / ML data collection for UE-side model, AI / ML data collection for a RAN-side model, an AI / ML data collection for network-side model, etc. More specifically, Figure 5 illustrates a high-level procedure according to which the UE 102 interacts with the wireless cellular system for data collection management through the exchange of information between the UE and the network to control UP data collection.
[0071] The UE 102 performs 502 a registration procedure to negotiate support of UP data collection support with the network. In an example implementation, this procedure can be implemented similar to the procedure described in 3GPP TS 23.502, clause 4.2.2.2. The AMF 364 selects 502A an instance of the PCF 360, for the UE 102, and associates the instance with the UE 102.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0072] The UDM 308, the UDR 352, and the DCNF 350 provision 512, to the UE 102, UPDC UE parameters during a UE parameters update procedure. The UE parameters for UP data collection can include some or all of the following information: (i) DCNF address information, (ii) an AI / ML feature ID, (iii) an activation indication to indicate whether the AI / ML feature is active or inactive. Example provisioning procedures are discussed in more detail below with reference to Figs. 6A and 6D.
[0073] If the CN 110 supports UE policy handling, and if the triggering condition is met, the PCF 370 or the DCNF 350 perform 522 a UE configuration update procedure to provision UE policies for the UE. The DCNF 350 can perform the UE configuration update procedure directly or via the PCF 360 using a Namf_Communication_NlN2MessageTransfer message to provision session management UE policies to the UE 102 via the AMF 364. This procedure can include at least some of the steps described in TS 23.502 clause 4.2.4.3, when the PCF 360 and / or the DCNF 350 determines to update the UE policy based on triggering conditions.
[0074] These triggering conditions at the PCF 360 and / or the DCNF 350 can include at least some of the following: (i) the DCNF 350 determines to enable UP data collection from the UE 102 for a specific AI / ML-enabled feature using AI / ML model training service at the network, (ii) the DCNF 350 receives a request for an AF or another NF, or (iii) the DCNF 350 determines to update UE policy related to UP data collection.
[0075] Based on the triggering condition of the UE policy evaluation, the UE 102 performs 524 the following: (i) evaluate UE policies enhanced for UP data collection, (ii) determine to enforce a matched UE policy, and (iii) determine whether to perform a PDU Session Establishment / Modifi cation request procedure for UP data collection for one or more AI / ML-enabled features e.g., for AI / ML model training service at the network.
[0076] At the UE 102, the triggering condition for UE policy evaluation can include one or more of the following: (i) the UE 102 receiving a request from an upper layer (e.g., the application layer) or a lower layer (e.g., RRC, MAC, or SDAP) for establishing / releasing UP data collection; (ii) the UE 102 receiving a request from an upper layer or a lower layer to request / or update information of UP data collection of one or more AI / ML-enabled features.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0077] Based on the enforced UE policy enhanced for UP data collection, the UE 102 performs 534 a PDU Session Establishment / Modification request procedure, which can be similar to the procedure described in TS 23.502 clause 4.3.2. The SMF 366 can select 534A an instance of the PCF 360 and / or the DCNF 350 and create a PCF 360 / DCNF 350 association for the PDU Session, to retrieve and / or update UE policies of the PDU Session. The PCF for the UE 102 and the PCF for the PDU Session may be the same (e g., the PCF 360) or different.
[0078] As a part of the PDU Session Establishment / Modification request procedure, the PCF 360 and the SMF 366 can perform one or more of the following: i) the PCF 360 can request subscription information at the PDU Session establishment or PDU Session modification during the UE Policy Association Establishment procedure. The UDR 352 can provide policy control subscription profile information during the UE Policy Association Establishment procedure using a Nudr service for Data Set = "Policy Data" and Data Subset = "UE context policy control data.”; (ii) the SMF 366 can obtain PCC rules from the PCF 360, and the PCC rules can contain the UP Data collection configuration information. The SMF 366 accordingly can configure the UPF 370 using N4 rules; (iii) the SMF 366 can configure N4 rules that include UP data connection information, which can guide the PSA UPF 370 to route the traffic with related AI / ML data toward the corresponding DCNF address and port information or the fully qualified domain name (FQDN) information for a specific AI / ML-enabled feature. The UE 102 then receives, from the network, a PDU Session Establishment Accept message or a PDU Session Modification Command message, which confirms the use of the UP data collection for the PDU Session.
[0079] Based on the UE policy and address information of DCNF for each AI / M-enabled feature, the UE 102 requests 542 one or more secure user-plane connections with the DCNF 350, e g. using TLS over TCP or Quick UDP Internet Connections (QUIC), for UP data collection of one or more AI / ML-enabled features. Thes techniques are discussed in more detail below with reference to Figs. 7 and 8.
[0080] After establishing 542 a UDP tunnel between the UE 102 and the DCNF 350, the UE 102 can begin to exchange 552 UPDC-CM messages with the DCNF 350 as well as transfer dataPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00to the DCNF 350. These techniques also are discussed in more detail below with reference to Figs. 7 and 8.
[0081] According to one (“first”) approach, and referring to procedure 532, the CN 110 uses policy control subscription profile information that enhances or augments the information in TS 23.502 Tables 6.2.1.3-1 and 6.2.1.3-2. The UDM 308 an / the UDR 352 provides the enhanced policy control subscription profile information at the establishment of a PDU Session using a Nudm or Nudr service for Data Set "Policy Data.” The enhancements can include the following: (i) for Data Subset " UE context policy control data" (based, for example, on Table 6.2.1.3-1 in TS 23.503), add a new (dedicated, special-purpose) indication of UE capability of UP data collection, which is used to indicate the UE support for transferring UP data collection to the network; (ii) for Data Subset "PDU Session policy control data" (based, for example, on Table 6.2.1.3-2 in TS 23.503), add a new (dedicated, special-purpose) IE of Allowed AI / ML-enabled features for UP data collection.
[0082] According to another (“second”) approach, and still referring to procedure 532, the CN 110 uses PCC rule information that enhances or augments the PCC rule information described in TS23.503 Table 6.3.1. The enhanced PCC rules information in the CN 110 can include a UP Data collection configuration information which indicates or includes a list of DCNF addresses and port numbers with associated AEML-enabled features (which can be identified using the corresponding feature IDs) for UP data collection, and which also can include the corresponding Protocol ID of secure transport layer mechanism, e.g. TLS over TCP or QUIC.
[0083] Using this information, the SMF 366 can determine how to handle the PDU Session Establishment / Modifi cation Request procedure from the UE 102, or whether to initiate a PDU Session Modification procedure with the RAN 102 and the UPF 370 to invoke or revoke UP data collection for the AI / ML-enabled feature.
[0084] According to yet another (“third”) approach, and still referring to procedure 532, the CN 110 uses N4 rules that enhance or augment the N4 rules described in TS 23.501 Table 5.8.5.6-1. Based on the UP data collection configuration information in the PCC rules, the SMF 366 configures N4 rules at the PSA UPF 370, so that when the traffic is detected based on the PDR, the UPF 370 enforces the Forwarding Action Rule (FAR) accordingly. The PDR includes aPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00DCAF address and a port number or an FQDN of a specific AI / ML-enabled feature, which is used to detect the traffic containing training data to be collected and transferred from the UE 102. The FAR, according to one option, enhances or augments the existing FAR attributes with new settings such as (i) a destination interface set as at core-side, and (ii) a forwarding policy which indicates to steer traffic toward the target DCNF address and the port number in the CN or the FQDN address for the corresponding AI / ML-enabled feature. According to another option, the FAR includes a new (dedicated, special-purpose) attribute that indicates in-network forwarding information for the target DCNF address and the port number in the CN 110.
[0085] According to still another (“fourth”) approach, and still referring to procedure 532, the CN 110 uses User Equipment Route Selection Policy (URSP) rules of the UE policy that include enhanced traffic descriptor (TD) information. One option is for the enhanced TD information to include existing IP descriptors indicating a destination DCNF address, a port number, and a protocol ID for a secure UP connection.
[0086] Another option is for the enhanced TD information to include a Connection Capabilities component, where the Connection Capabilities indicates a new standardized component value as “UP data collection” for example. When the UE 102 receives an UP-connection request for UP data collection from an upper layer such an application, or a lower layer such as RRC, MAC, or SDAP layer, the UE 102 triggers a URSP rules evaluation to establish a secure UP connection, and the UE 102 enforces the URSP rule that includes Connection Capabilities with a component value that matches “UP data collection request.”
[0087] Yet another option is for the enhanced TD information to include a new component of AI / ML-enabled feature ID(s) for AI / ML model training at the network, where the component value indicates or includes a list of AI / ML-enabled feature ID(s) to identify one or more feature ID to be used in the PDU session for UP data collection. The feature ID in this case can be a standardized value defined in 3 GPP or an operator-defined value. When the UE receives an UP-connection request for UP data collection for a specific AI / ML-enabled feature ID from an upper layer or a lower layer, in order to establish a secure UP connection, the UE triggers URSP rules evaluation and enforces the URSP rule that includes the AI / ML-enabled feature ID(s) componentPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00with a component value that matches the feature ID indicated in the UP data collection request from the upper or lower layer.
[0088] The fourth approach also can include enhancements to a route selection descriptor (RSD). When the UE 102 selects a matched TD of the URSP rule, the UE enforces the RSD, which provides information related to a PDU Session for UP data collection. Accordingly, the UE 102 enforces the URSP rule by indicating 532, during the PDU Session Establishment / Modification request procedure, information for session management of UP data collection, or SM-UPDC information. One option is for the enhanced RSD to indicate the following information using the existing RSD components of PDU Session related information, e.g., UPDC-DNN, UPDC-S-NSSAI, configured for UP data collection in the network. Another option is for the enhanced RSD to include a UP data connection indication. When the RSD includes the UP data connection indication, the UE 102 and the CN 110 use, for UP Data collection, the PDU session specified in the route selection components. Yet another option is for the enhanced RSD to include, as one of the route selection components, a new (dedicated, special -purpose) component of UP data connection indication. When the RSD includes the new UP data connection indication component, the UE 102 and the CN 110 use the PDU Session for UP Data collection.
[0089] Next, example implementations of the the UE parameters update procedure 512 of Fig.5 are discussed below with reference to Figs. 6A and 6B.
[0090] Generally speaking, rge procedures to allow the Home Public Land Mobile Network (HPLMN) to update the UE 102 with a specific set of parameters for UP Data Collection, which the UDM 308 generates and stores. The UE parameters associated with UP Data Collection (UPDC-UE parameters) can include one or more of the following: (i) AEML-enabled feature ID, (ii) an activation indication to indicate whether the AI / ML-enabled feature ID is active or inactive, and (iii) DCNF information, which can include a include DCNF address as an end point of user-plane connection in the network for collecting data of the AI / ML-enabled feature (identified by the feature ID). For example, DCNF information can include an FQDN address (to achieve flexibility in managing DNS changes with a separate port numbers configuration), a URL address (to explicitly specifying the protocol, the host, the port, and the resource path), orPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00an IP address and a port number of the DCNF (to eliminate dependency on the DNS, at the expense of flexibility of the IP address changes).
[0091] Two approaches are discussed below: the approach of Fig. 6A enhances the UE Parameters Update procedure via a UDM Control Plane Procedure, and the approach of Fig. 6B uses a new (dedicated, special-purpose) UE Parameters Update procedure via a DCNF controlplane procedure. The UDM 308 and / or the DCNF 350 initiates the procedure to provision UE parameters of UPDC to the AMF 364, and the AMF 364 encapsulates the UE parameters of UPDC in a payload container of a DL NAS Transport message. The nodes of the CN 110 and the can UE 102 can identify the payload container using an existing payload container type, a “UE-parameters update transparent container,” or using a new (dedicated, special-purpose) payload container type, a “UPDC-UE parameters update transparent container.”
[0092] Referring first to a scenario 612A of Fig. 6A, the AMF 364 subscribes 613 for a UDM service, in particular for the Nudm_SDM_Notifi cation service operation when there are changes to the UPDC-UE parameters in the subscription data.
[0093] The PCF 360 discovers 614A the DCNF 350 that supports the allowed AVML-enabled feature(s) based on subscription information obtained from the UDM / UDR 308 / 352. The DCNF 350 determines to update the UPDC-UE parameters at the UDM / UDR 308 / 352 directly or via the PCF 360. Alternatively, the PCF 360 determines to update the UPDC-UE parameters at the UDM / UDR 308 / 352 directly (based on information obtained from the DCNF 350) or via the DCNF 350. The PCF / DCNF 360 / 350 sends 614A-1, to the UDM / UDR 308 / 352, aNudm ParameterProvision Create / Update / Delete request including the UPDC-UE parameters to, and receives 614A-2, in response, a Nudm_ParameterProvision_Create / Update / Delete response message that confirms reception of the update.
[0094] The DCNF 350 may subscribe 615 to the Nudm_SDM_Notification service, for notifications, from the UE 102, regarding the result of the update of the UPDC-UE parameters. The UDM 308 can determine 616 to perform a UE parameter update procedure for the UPDC-UE parameters. The UDM 308 sends 616-1 a Nudm_SDM_Notification message including a UDM Update data to notify the affected AMF 364 of the changes to the information related to the UE 102. The UDM Update data can include (i) the updated UPDC-UE parameters for UPPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00data collection, (ii) an indication of whether the UE 102 needs to send an acknowledgement to the UDM 308, and (iii) an indication of whether the UE 102 needs to re-register after updating the data.
[0100] The AMF sends 616-2, to the UE 102, a DL NAS TRANSPORT message including a transparent container with the UPDC-UE parameters received from the UDM 308. If the AMF 364 determines that the UE 102 is not reachable, the AMF 364 can invoke the Nudm SDM Info service operation, so as to indicate, to the UDM 308, that the transmission of the UE Parameters Update data was not successful. The UDM 308 can consider the UE Parameters Update procedure pending, and the subsequent steps are omitted.
[0095] If the UDM 308 has requested the UE 102 to send an acknowledgement to the UDM 308, the UE 102 sends 618A, to the serving AMF 364, a UL NAS TRANSPORT message with a transparent container including the UE acknowledgement. If the AMF 364 receives 618A, from the UE 102, a UL NAS TRANSPORT message with a transparent container carrying a UE acknowledgement, the AMF 164 sends 618A-1, to the UDM 308, a Nudm_SDM_Info request message including the transparent payload container. If the DCNF 350 previously subscribed 615 to the notification service for UE parameters provisioning updates from the UDM 308, the UDM 308 sends 618A-2, to the DCNF 350, a Nudm_SDM_Notification Notify message including the acknowledgement information.
[0096] At the end of the scenario 612A, if the UDM 308 has requested the UE 102 to reregister after the UPDC-UE parameters update 616-1, the UE 102 can wait until transitioning back to RRC IDLE and then initiate a Registration Request procedure (not shown to avoid clutter).
[0097] Now referring to Fig. 6B, a UE Parameters Update procedure 612B can use a DCNF control plane. The PCF 360 discovers 614B the DCNF 350 supporting the allowed AI / ML-enabled feature(s) based on subscription information of the UE 102, obtained from the UDM / UDR 308 / 352. According to approach discussed with reference to Fig. 9, the PCF 360 discovers the DCNF 350 supporting the required AI / ML-enabled feature(s) and In-Band management of User Plane Data Collection (IBM-UPDC) for the UE 102. According to approach discussed with reference to Fig. 10, the PCF 360 discovers the DCNF 350 supportingPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00the required AI / ML-enabled feature(s) for the UE 102. The DCNF 350 determines to update the UE 102, via the AMF 364, with the UPDC-UE parameters, e.g. based on the information of the registered area of the UE 102 or subscription data of the UPDC changes received from the UDM 308. Alternatively, the PCF 360 determines to update the UE 102, via the AMF 364, with the UPDC-UE parameters based on the information obtained from the DCNF 350.
[0098] The DCNF 350 sends 614B-1, to the AMF 364, an Namf_Communication_NlN2MessageTransfer message including UPDC-UE parameters. If the UE 102 is in CM-IDLE state, the AMF 364 triggers 614B-2 a service request procedure. If the UE 102 is reachable, the AMF sends 614B-3, to the serve UE 102, a DL NAS TRANSPORT message including a transparent payload container with the UPDC-UE parameters received from the DCNF 350.
[0099] If the DCNF 350 has requested that the UE 102 send an acknowledgement to the DCNF, the UE 102 sends 618B, to the serving AMF 364, a UL NAS TRANSPORT message with a transparent payload container including the UE acknowledgement for the results of the delivery of UPDC-UE parameters. If the AMF 364 receives 618B-1 a UL NAS TRANSPORT message with a transparent container carrying a UE acknowledgement for the results of the delivery of UPDC-UE parameters, the AMF 364 sends 618B-2, to the DCNF 350, a Namf_Communication_NlMessageNotify message including the UE acknowledgement for the results of the delivery of UPDC-UE parameters.
[0100] Next, in-band UP data collection management using a UDP tunnel for exchanging UPDC control messages is discussed with reference to Figs. 7 and 8. These techniques can be used during the procedures 542 and 552 discussed with reference to Fig. 5, and can be based on the principles outlined below.
[0101] Both the UE 102 and the network (the CN 110) support in-band UP data collection management via capability negotiation during the Registration Request procedure (see Fig. 9) or the PDU Session Establishment / Modifi cation Request procedure (see Fig. 10).
[0102] Further, the CN 110 supports the following functionality: the PSA UPF 360 can operate as an HTTP proxy supporting connect-udp (MASQUE) and can bridge the UE 102 and the DCNF 350 by processing HTTP -based requests to establish a UDP tunnel to the DCNF 350,PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00the intended destination for the traffic from the UE 102, based on the connect-udp request. This allows a UDP packet encapsulating a QUIC packet with data or a QUIC datagram with a UPDC-CM message to transfer over a UDP tunnel via the PSF UPF 360, between the UE 102 and the DCNF 350.
[0103] Still further, when the UE 102 supports in-band UPDC-CM, the UE 102 is configured with a specific Context ID for the new capsule type to deliver a UPDC-CM message. Fig. 7 illustrates a scheme 700 in which a QUIC packet 781 carries a UPDC-CM message 785 over a UDP tunnel 780, between the UE 102 and the CN 110. The UPDC-CM message 785 corresponds, in the HTTP datagram 782, to a specific context ID 784 indicating the use of the capsule protocol for communicating UPDC-CM information. The UDP datagram 780 thus encapsulates the HTTP / 3 datagram for carrying the UPDC-CM message 780, in HTTP / 3 datagram payload of a QUIC datagram frame 782. Using the UDP tunnel, the UE 102 can send a capsule with the UPDC-CM message within a QUIC DATAGRAM frame and data in a QUIC stream frame.
[0104] Fig. 8 illustrates an example scenario 800 in which the UE 102 requests the establishment of a UDP tunnel with the DCNF 350 via the PSA UPF 360 and sends a QUIC DATAGRAM frame with a capsule type for a UPDC-CM message. Here, the UE 102 acting as an HTTP client initiates 861 a QUIC Connection Request using a HTTP CONNECT-UDP request method (based on RFC 9298 for HTTP / 3 and MASQUE), indicating the DCNF address and the port to the PSA UPF acting as a http proxy.
[0105] The PSA UPF 360 receiving 862 the HTTP CONNECT-UDP request message establishes a UDP tunnel to the DCNF 350. This tunnel enables communications between the UE 102 and the DCNF 350 via the PSA UPF 360 as an HTTP proxy. The PSA UPF 360 responds 863, to the UE 102, with an HTTP success status (e.g., 200 OK) indicating that the UDP tunnel has been successfully established. The PSA UPF 360 acting as a proxy for the UDP traffic can then start transparently forwarding UDP packets between the UE 102 and DCNF 350.
[0106] With the UDP tunnel established, the UE 102 initiates 864 a QUIC handshake with the DCNF 350, via the UPF 360. The DCNF 350 responds 864 to the QUIC handshake, completing the connection setup. Once established, a direct QUIC connection exists between UE 102 andPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00DCNF 350, with the UPF 360 transparently relaying UDP packets between these two communication endpoints.
[0107] The UE 102 and the DCNF 360 negotiate support for the Capsule Protocol by exchanging HTTP / 3 SETTINGS frames with SETTINGS ENABLE CAPSULE = 1 at the start of the connection. This negotiation enables the use of capsules within QUIC streams or datagrams. Using the established UDP tunnel, and for a UE-initiated UPDC, the UE 102 constructs 866A a capsule containing a UPDC-CM message to initiate data collection with the DCNF 350. The UE 102 sends 866A this capsule in a QUIC DATAGRAM frame, to the DCNF 350. The DCNF responds 866B to the data collection initiation by sending, to the UE 102, a capsule containing a UPDC-CM message. Using the established UDP tunnel, and for a network-initiated UPDC, the DCNF 350 constructs 866C a capsule containing a UPDC-CM message to initiate data collection with the UE 102. The DCNF 350 sends this capsule in a QUIC DATAGRAM frame, to the UE 102. The UE 102 responds to the data collection initiation by sending, to the DCNF 350, a capsule containing a UPDC-CM message. The UE 102 and the DCNF 350 perform 866 these steps whenever the UE 102 or the DCNF 250 needs to send a UPDC-CM message.
[0108] The UE 102 begins 867 transferring data encapsulated in QUIC packets over the established UDP tunnel to the DCNF 250 via the PSA UPF 360. The PSA UPF 360 continues to relay the QUIC packets transparently between the UE 102 and DCNF 350.
[0109] Next, an example in-band UP data collection management techniques is discussed with reference to Fig. 9. According to the approach of Fig. 9, the CN 110 enhances URSP rules of the UE policy by (i) indicating, in the TD, Connection Capabilities for UP data collection, and (ii) indicating, in the RSD, a PDU Session for UP Data collection. Further, according to this approach, the UE 102 and the CN 110 negotiate UE capability and the network support for in-band UP data collection management during a registration request procedure. The UE 102 indicates UE capability for UDPC and in-band management of UPDC (IBM-UPDC) in a Registration Request message.
[0110] The UE capability can indicate one or more (i) support of USRP rules enhancement for UPC, (ii) support of UDPC (e.g., the UE 102 acting as an HTTP client can request an HTTPPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00connect-udp toward the DCNF 350 and transfer training data associated with a specific AI / ML-enabled feature per a QUIC connection over a UDP tunnel, between the UE 102 and the DCNF 350, (iii) support of an in-band UPDC-CM message exchange with the DCNF 350, (iv) capability to construct a capsule type of a specific context ID for a UPDC-CM in an HTTP diagram, and (v) capability to decapsulate a UPDC-CM from an HTTP datagram in a UDP packet. The CN 110 in turn can indicate support of UPDC and of in-band UPDC management capability in a Registration Accept message, and network capability can indicate one or more of (i) the PCF 360 supporting PCC rules enhancement for data collection, (ii) the PCF 360 discovering an instance of the DCNF 350 capable of in-band UPDC management, based on a UE capability indication for in-band UPDC management, (iii) the SMF 366 and the UPF 360 supporting required functionalities for UP data collection at the DCNF 350, or (iv) the DCNF 350 supporting UP data collection and in-band UPDC management.[oni] Further, according to this approach, the PDU Session Establishment / Modification Request procedure includes certain enhancements to support UPDC. In particular, the UE requests a PDU Session establishment / modifi cation for UPDC indicating session management related UPDC (SM-UPDC) information according to one of the following options: (i) using a new (dedicated, special-purpose) PDU Session type set to “UP data collection,” (ii) using a new (dedicated, special-purpose) IE with a UPDC indication, (iii) using a new (dedicated, specialpurpose) IE with an AI / ML-enabled feature ID, or (iv) using a specific pair of a DNN and an S-NSSAI configured by the operator for specifically for UDPC, which can be indicated as a {DC-DNN, DC-SNSSAI} tuple, and which cannot be used for other purpose such as accessing the Internet. The SMF 366 can perform the following: (i) discover and selects a DCNF with the in-band UPDC management capability, based on the UE subscription of UPDC information from the UDM / UDR 308 / 352, and (ii) discovers a PSA UPF with UPDC capabilities. These UPDC capabilities can include (i) capability to act as an HTTP proxy, (ii) capability to establish a QUIC connection with a DCNF when receiving an HTTP request , (iii) for the uplink, capability to forward UDP packets to the destined DCNF address and port, and (iv) for the downlink, capability to forward UDP packets to the destination UE address and port.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0112] The UE 102 can determine to request UDCP management from the DCNF 350, and the DCNF 350 can similarly request UDCP management from the UE 102. For example, the DCNF 350 can send, to the UE 102, a UPDC-CM over a UDP tunnel between the DCNF 350 and the UE 102. The UPDC-CM is encapsulated in an HTTP datagram using a capsule protocol and indicating, to the UE 102, a Context ID for UPDC-CM. The UE 102 then can handle the PDU session, UP data connection, and send a UPDC-CM message to the DCNF 350, in response to the first UPDC-CM received in the HTTP datagram.
[0113] Fig. 9 illustrates an example scenario 900 that includes an exchange of UPDC-CM messages between the UE 102 and the DCNF 250 for UDPC management, using UPDC-CM messages according to the first or second approach discussed with reference to procedure 532. The scenario 900 illustrates a PDU Session Establishment Request procedure as an example, but a PDU Session Modification Request procedure can use similar techniques.
[0114] The UE 102 sends 902, to the AMF 364, a Registration Request message including, as a part of 5GMM capability, the following information: (i) UE capability with respect to UPDC and (ii) UE capability with respect to IBM-UPDC. The AMF 364 stores the UE capabilities in AMF UE context. More specifically, the AMF 364 can request 902A, from the UDM 308, retrieval of the UE subscription with Session Management Subscription data that includes UPDC information (which in turn indicates whether a PDU session for UPDC is allowed). In addition, the AMF 364 can request an update of UE subscription at the UDM 352, to store the UE capability with respect to IBM-UPDC.
[0115] If the UE capability indicates UPDC support, and the UE subscription allows the UE 102 to establish a PDU Session for UPDC, the AMF 364 selects a PCF 460 and creates 904A a PCF association for the UE 102 to handle and control UE policies. In particular, the AMF 364 sends 904 A, to the associated PCF 360, a Npcf UEPolicyControl Create Request message including the SUPI of the UE and the indication of UPDC. The PCF 360 includes 904B, in an Npcf_UEPolicyControl Create Response message responsive to receiving 904A the request, an indication a support of UPDC IE, to indicate network support of UPDC.
[0116] If the AMF 364 determines that the network supports UPDC for purpose of AI / ML model training at the network, the AMF 364 sends 906, to the UE 102, a Registration AcceptPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00message that includes an indication of UPDC Support. This indication can be a part of an 5GS Network Feature Support IE for an AVML model training service provided by the network (e.g. AI / ML data collection for UE-side model, AI / ML data collection for RAN-side model, AI / ML data collection for network-side model, etc.). Otherwise, the AMF 364 does not include an indication of network support for UP data collection, and may include a cause field with a value that indicates lack of support for UP data collection.
[0117] With continued reference to Fig. 9, a procedure 912 can be similar to the procedure 512 discussed above, with URSP rules enhancement, procedure 922 can be similar to the procedure 522 discussed above, and procedure 924 can be similar to the procedure 524 discussed above. The approaches of Figs. 6A and 6B can also apply to provision UE parameters.
[0118] Based on RSD (routing selection descriptor) in a matched UE policy in Step 924, the UE sends 932A PDU Session Establishment Request message including SM-UPDC information, e g. AI / ML-enabled feature ID, PDU Session type set as UP data collection, and a pair of DNN, S-NSSAI, to SMF via AMF using Nsmf_PDUSession_CreateSMContext Request including SM-PDC information in Step 932A. With SM-UPDC information, the SMF retrieves / updates 932B subscription information, e.g. the UPDC of the AEML-enabled feature(s) and UE capability of IBM-UPDC, from UDM / UDR for the UE. The SMF sends 4032CNsmf PDUSession CreateSMContext Response message to the AMF in re-sponding to Step 4032a.
[0119] The SMF performs 934 an SM Policy Session establishment with the PCF 360 for the PDU Session by sending, to the PCF 360, an Npcf_UE_PolicyAssociation message including SM-UPDC info and IBM-UPDC, and obtains a PCC rule including the QoS parameters and the UP Data collection configuration information (including the DCNF address information), from the PCF 360. The SMF 366 discovers 936 PSA UPF with UPDC capability.
[0120] The SMF performs 938 the following: (i) QoS flow binding for UPDC based on the PCC rule and (ii) configuration of N4 rules with the UPDC configuration information to the PSA UPF 360, to route the data traffic of a specific AEML-enabled feature toward the DCNF 350.
[0121] If the DCNF address information is not provided 912, or if the DCNF address information requires an update, the SMF 366 sends 940 a PDU Session Establishment AcceptPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00message including the DCNF address information, e.g. in a new IE or in ePCO IE. The AMF 364 then sends a PDU Session Establishment Accept to UE. Finally, procedure 942 can be similar to the procedure 542 discussed above, and procedure 952 can be similar to the procedure 552 discussed above.
[0122] Next, another approach to in-band UPDC management is discussed with reference to Fig. 10. This approach also involves enhancing URSP rules of the UE policy, with a TD indicating a Connection Capabilities for UDPC and an RSF indicating a PDU Session for UPDC. The UE and the network negotiate UE capability as well as network support for UDPC during a Registration Request procedure. In particular, the UE indicates UE capability for UPDC, and the UE capability can indicate one or more (i) support of USRP rules enhancement for UPC and (ii) support of UDPC (e.g., the UE 102 acting as an HTTP client can request an HTTP connect-udp toward the DCNF 350 and transfer training data associated with a specific AI / ML-enabled feature per a QUIC connection over a UDP tunnel, between the UE 102 and the DCNF 350. The CN 110 in turn can indicate (i) support of the PCC rules enhancement for Data Collection at the UPF, (ii) ii) the PCF being able to discover an instance of the DCNF capable of in-band UPDC management, based on a UE capability indication for in-band UPDC management, (iii) support for UPDC and UPDC-CM at the DCNF, and (iv) support of UPDC capabilities at the PSA UPF.
[0123] According to the approach of Fig. 10, the PDU Session Establishment / Modification Request procedure includes certain enhancements for UDPC. In particular, the UE requests a PDU Session for UPDC with one of the following options: (i) a new (dedicated, special-purpose) PDU Session type set to “UP data collection,” (ii) a new (dedicated, special-purpose) IE with a UPDC indication, (iii) a new (dedicated, special-purpose) IE with an AI / ML-enabled feature ID, (iv) a specific pair of a DNN and an S-NSSAI configured by the operator for specifically for UDPC, which can be indicated as a {DC-DNN, DC-SNSSAI} tuple, and which cannot be used for other purpose such as accessing the Internet. The UE also indicates its capability with respect to IBM-UPDC indication. This capability indication can indicate one or more of (i) support of in-band UPDC-CM message exchange with the DCNF, (ii) capability to construct a capsule type of a specific Context ID for UPDC-CM in an HTTP datagram, or (iii) a capability to decapsulate a UPDC-CM from an HTTP datagram of a UDP packet .PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0124] The PCF may reselect a DCNF with an in-band UPDC management capability based on the UE capability indication for in-band UPDC-CM. The SMF then discovers a PSA UPF with the following UPDC capabilities: (i) capability to act as an HTTP proxy, (ii) capability to establish a QUIC connection with a DCNF when receiving an HTTP request , (iii) for the uplink, capability to forward UDP packets to the destined DCNF address and port, and (iv) for the downlink, capability to forward UDP packets to the destination UE address and port.
[0125] Similar to the approach of Fig. 9, the UE 102 can determine to request UDCP management from the DCNF, and the DCNF 350 can similarly request UDCP management from the UE 102. For example, the DCNF 350 can send, to the UE 102, a UPDC-CM over a UDP tunnel between the DCNF 350 and the UE 102. The UPDC-CM is encapsulated in an HTTP datagram using a capsule protocol and indicating, to the UE 102, a Context ID for UPDC-CM. The UE 102 then can handle the PDU session, UP data connection, and send a UPDC-CM message to the DCNF 350, in response to the first UPDC-CM received in the HTTP datagram.
[0126] Fig. 10 illustrates an example exchange of UPDC-CM messages between a UE 102 and the DCNF 350 for UPDC-CM using UPDC-CM messages as discussed with reference to Fig. 13 A and Fig. 13B. Figure 10 refers to a PDU Session Establishment Request procedure as an example, but similar techniques can apply to the PDU Session Modification request procedure.
[0127] The UE sends 1002, to the AMF 364, a registration Request message including, as a part of 5GMM capability to the AMF, an indication of UE capability with respect to UPDC. It is noted that in the scenario 900 of Fig. 9, the UE 102 also indicates its capability with respect to IBC-UPDC, but here the UE indicates this capability at a later stage.
[0128] The AMF 364 stores the UE capabilities in the AMF UE context. In particular, the AMF 364 requests 1002A, from the UDM 308, retrieval of subscription information. This information can be stored with a Session Management Subscription data that includes the UPDC information, which in turn indicates whether the PDU session for UP data collection is allowed.
[0129] Procedures 1004, 1006, and 1012-024 are similar to the procedures 904, 906, and 912-924 discussed above with reference to Fig. 9. Based on the RSD in a matched UE policy determined 1024 earlier, the UE 102 sends 1032, to the SMF 366 via the AMF 364, a PDU Session Establishment Request message including an indication of UE capability with respect toPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00IBM-UPDC as well as SM-UPDC information (e.g., an AI / ML-enabled feature ID, a PDU Session type set to “UP data collection,” a {DNN, S-NSSAI} tuple, etc.). To this end, the UE 102 can send 1032A an Nsmf_PDUSession_CreateSMContext Request including a UE capability with respect to IBM-UPDC and the SM-PDC information.
[0130] Using the SM-UPDC information, the SMF retrieves 1032B subscription information, e.g. the UPDC of the AI / ML-enabled feature(s), from the UDM / UDR 308 / 352, for the UE 102. The SMF 366 sends 1032C, to the AMF 364 and response to receiving 1032 the request, an Nsmf_PDUSession_CreateSMContext Response message.
[0131] The SMF 366 performs 5034 an SM Policy Session establishment with the PCF 360 for the PDU Session by sending, to the PCF 360, an Npcf_UE_Policy Association message including the SM-UPDC info and the IBM-UPDC, and obtains the PCC rule including QoS parameters and UDPC configuration information (including DCNF address information), from the PCF 360. The PCF 360 also may reselect a DCNF (e.g., the DCNF 350) capable of IBM-UPDC. In the scenario of Fig. 10, the PCF 360 provides an updated DCNF address information to the SMF 366, and the SMF 366 sends 1040, to the UE 102, a PDU Session Establishment Accept message including the DCNF address information, e.g. in a new (dedicated, specialpurpose) IE or in ePCO IE. The remaining messages or procedures in the scenario 1000 are similar to those in the scenario 900 of Fig. 9.
[0132] Fig. 11 is a flow diagram of an example method 1100 for in-band UPDC-CM transmission, which can be implemented in the UE of Fig. 1. At block 1142, the UE establishes a UP connection with a core network (e.g., with a DCNF via a UPF). The UP connection can be a UDP tunnel. As discussed above, the UE can setup a UDP tunnel upon establishing a modifying a PDU session. At block 1152, the UE encapsulates an UPDC-CM in a datagram. As discussed above with reference to Fig. 7 for example, the UE can encapsulate the UPDC-CM in a UDP datagram. If desired, the UPDC-CM can be included in a QUIC packet, which in turn is encapsulated in an HTTP datagram. The UE transmits the UPDC-CM to the core network over the UDP tunnel. Thus, the UE performs an in-band transmission of the UPDC-CM rather than using control-plane signaling, NAS signaling, etc.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00
[0133] Fig. 12 is a flow diagram of an example method 1220 for in-band UPDC-CM transmission, which can be implemented in a CN node of Fig. 1 such as the DCNF for example. At block 1242, the CN node establishes a UP connection with a UE. The UP connection can be a UDP tunnel associated with a PDU session. At block 1252, the CN node encapsulates an UPDC-CM in a datagram (see Fig. 7). The CN node transmits the UPDC-CM to the UE over the UDP tunnel. Thus, the CN performs an in-band transmission of the UPDC-CM rather than using control-plane signaling, NAS signaling, etc.
[0134] Fig. 13A is a messaging diagram 1320A illustrating several example UPDC-CMs which network endpoints can exchange to manage UP data collection. The techniques of Figs.13A and 13B are compatible with one or more of the techniques of Figs. 11 A, 1 IB, and 12 discussed above.
[0135] To implement UP data collection management, the UPDC endpoint 1 can transmit 1328A a UP Data Collection Connection Establishment request, which is used to request for establishment of a new UP connection for UP Data Collection between the UE and the DCNF. The UPDC endpoint 2 can respond 1329A with a UP Data Collection Connection Establishment Complete, which is used to acknowledge for the establishment completion of a new UP connection for UP Data Collection between the UE 102 and the DCNF 350.
[0136] The UPDC endpoint 1 can transmit 1328B a UP Data Collection Suspend request, which is used to request for suspending UP Data Collection for the existing UP connection between the UE 102 and the DCNF 350. The UPDC endpoint 2 can respond 1329B with a UP Data Collection Suspend Confirm, which is used to acknowledge for the confirmation of suspending the UP connection for UP Data Collection between the UE 102 and the DCNF 350.
[0137] The UPDC endpoint 1 can transmit 1328C a UP Data Collection Resume request, which is used to request for resuming UP Data Collection for the existing UP connection between the UE and the DCNF. The UPDC endpoint 2 can respond 1329C with a UP Data Collection Resume Confirm, which is used to acknowledge for the confirmation of resuming UP Data Collection for the existing UP connection between the UE 102 and the DCNF 350.
[0138] The UPDC endpoint 1 can transmit 1328D a UP Data Collection Connection Update request, which is used to request for updating UP connection for UP Data Collection between thePATENT APPLICATION Attorney Docket No.: 31730 / 309152-00UE and the DCNF. The UPDC endpoint 1 can respond 1329D with a UP Data Collection Connection Update Confirm, which is used to acknowledge for confirming the update of UP connection for UP Data Collection between the UE 102 and the DCNF 350.
[0139] The UPDC endpoint 1 can transmit 1328D a UP Data Collection Connection Release request, which is used to request for releasing UP Data Collection for the existing UP connection between the UE and the DCNF. The UPDC endpoint 2 can respond 1329D a UP Data Collection Connection Release Confirm, which is used to acknowledge for confirming the release of UP Data Collection for the existing UP connection between the UE 102 and the DCNF 350.
[0140] The UPDC endpoint 1 can transmit 1328F a UP Data Collection Status Update indication, which is used to request status update for the UP Data Collection for the existing UP connection between the UE 102 and the DCNF 350. The UPDC CM can additionally indicate what the status information is requested for the update, e g. data volume of data collected, transferred, time window of the collected data to be transferred, earliest timestamp of the collected data to be transferred, last timestamp of the collected data to be transferred, last timestamp of the data being transferred, etc. for UP data collection of AIML enabled features.
[0141] The UPDC endpoint 2 can respond 1329F with UP Data Collection Status Update response indication, which is used to respond status update for the UP Data Collection for the existing UP connection between the UE and the DCNF. The UPDC CM can include the status information requested for the update, e.g. data volume of data collected, transferred, time window of the collected data to be transferred, earliest timestamp of the collected data to be transferred, last timestamp of the collected data to be transferred, last timestamp of the data being transferred, etc. for UP data collection of AIML enabled features.
[0142] Each of the messages of Fig. 13A can include one or more of the fields or IES discussed above.
[0143] Fig. 13B illustrates a messaging scheme generally similar to that of Fig. 13 A, but with a generic UPDC-CM including an indication of the respective control function. In a scenario 1320B, the UPDC endpoint 1 can transmit 1330A, 1330B, 133OC, 1330D, 1330E, or 1330F a generic UPDC-CM with an indication that identifies a message similar to that in transmission 1328A, 1328B, 1328C, 1328D, 1328E, or 1328F, respectively. The UPDC endpoint 2 canPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00transmit 1331 A, 133 IB, 1331C, 133 ID, 133 IE, or 133 IF a generic UPDC-CM with an indication that identifies a message similar to that in transmission 1329A, 1329B, 1329C, 1329D, 1329E, or 1329F, respectively. Similar to Fig. 13A, each of the messages in a scenario 1320B of Fig. 13B can include one or more of the fields or IES discussed above with reference to Fig. 12.
[0144] Each of the UPDC-CM messages can include one or more of (i) a UE ID, e.g. SUPI, (ii) an AUML-enabled feature ID, (iii) a Correlation ID (which the DCNF 350 can generate to enable the correlation between the UPDC CM and the corresponding data to be collected from the UE 102), (iv) a validity time period, or (v) validity area(s).
[0145] Finally, several examples are considered next with reference to UE-initiated UPDC-CM and network-initiated UPDC-CM. As one example, a UE (e.g., the UE 102) sends an i-band UPDC CM to request activation UPDC for a secure UP connection (e.g. a QUIC connection over UDP) with a DCNF (e.g., the DCNF 350) via a UPF (e.g., the UPF 36) for UP data collection in connection with AI / ME enabled features, where the UPDC_CM includes a UP Data Collection Connection Establishment request (see events 1328A, 1330A). In response, the DCNF sends an in-band UPDC CM corresponding to a UP Data Collection Activation Complete indication (see events 1328B, 1330B) to confirm the request from the UE.
[0146] As another example, the UE sends an in-band UPDC CM to request the deactivation or release of UPDC for a secure UP connection (e.g. QUIC connection over UDP), with the DCNF via UPF for UP data collection of an AEME enabled feature. The UPDC CM includes a UP Data Collection Connection Release or an UP Data Collection Deactivation indication, for a secure UP connection (e.g. QUIC connection over UDP) with the DCNF via UPF for UP data collection of AIML enabled features. In response, the DCNF sends an in-band UPDC CM corresponding to a UP Data Collection Release Confirm or a UP Data Collection Deactivation indication, to confirm the request from the UE.
[0147] As another example, the UE sends an in-band UPDC CM to request suspending UPDC for a secure UP connection (e.g. QUIC connection over UDP) with the DCNF via UPF for UP data collection of an AIML enabled features, and the UPDC CM includesa UP Data Collection Suspend indication (see Fig. 13B) or a UP Data Collection Suspend (se Fig. 13 A), for a secure UP connection (e.g. QUIC connection over UDP) with the DCNF via UPF for UP dataPATENT APPLICATION Attorney Docket No.: 31730 / 309152-00collection of AI / ML-enabled features. In response, the DCNF sends an in-band UPDC CM including a UP Data Collection Suspend Complete indication (see Fig. 13B) or a UP Data Collection Suspend Complete message (see Fig. 13 A), to confirm the request from the UE.
[0148] As another example, the UE sends an in-band UPDC CM to request resumption of UPDC for a secure UP connection (e.g. QUIC connection over UDP) with the DCNF via UPF for UP data collection of an AI / ML-enabled feature. The UPDC CM includes an UP Data Collection Resume indication (see Fig. 13B) or a UP Data Collection Resume message (see Fig.13 A) for a secure UP connection (e.g. QUIC connection over UDP) with the DCNF via a UPF for UP data collection of a AIML enabled features. In response, the DCNF sends an in-band UPDC CM including a UP Data Collection Resume Complete indication (see Fig. 13B) or a UP Data Collection Resume Complete message (see Fig. 13 A), to confirm the request from the UE.
[0149] Similarly, a UE can send an in-band UPDC CM to request an update of UPDC for a secure UP connection, and the UPDC CM includes a UP Data Collection Update indication or a UP Data Collection Update message, and the DCNF sends a corresponding confirmation in response. As a final example, a UE can send an in-band UPDC CM to request to update the status of UPDC for a secure UP connection, and the DCNF can send an appropriate response in the form of an in-band UPDC CM.Additional considerations
[0150] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purposePATENT APPLICATION Attorney Docket No.: 31730 / 309152-00processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.
[0151] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general -purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
[0152] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.
Claims
PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00The claims:
1. A method for facilitating user-plane (UP) data collection in a cellular communication network, the method implemented in a user equipment (UE) and comprising: establishing, with a core network, a user-plane (UP) connection for UP data collection, including establishing a User Datagram Protocol (UDP) tunnel; andcommunicating, with the CN and over the UDP tunnel, an in-band UP data collection control message (UPDC-CM) related to managing the UP data collection, the control message including a feature identifier (ID) identifying an artificial intelligence / machine learning (AIZML)-enabled feature to which the UP data collection pertains.
2. The method of claim 1, wherein the control message operates to request one of: (i) establishing of a new connection for UP data collection between the UE and the CN, (ii) suspending an existing connection for UP data collection between the UE and the CN, (iii) resuming an existing suspended connection for UP data collection between the UE and the CN,(iv) updating an existing connection for UP data collection between the UE and the CN, (v) releasing an existing connection for UP data collection between the UE and the CN; or(vi) updating a status of a connection for UP data collection between the UE and the CN.
3. The method of claim 1 or 2, wherein the establishing of the UDP tunnel is associated with establishing or modifying a packet data unit (PDU) session.
4. The method of claim 3, wherein the establishing of the PDU session includes: transmitting a PDU Session Establishment message or a Modification Request message indicating a data network name (DNN) and Single Network Slice Selection Assistance Information (S-NSSAI) allocated specifically for the UP data collection.
5. The method of claim 1, further comprising:PATENT APPLICATION Attorney Docket No.: 31730 / 309152-00encapsulating the UPDC-CM in a Hypertext Transfer Protocol (HTTP) datagram; wherein the communicating of the UPDC-CM includes transmitting, over the UP tunnel, the HTTP diagram.
6. The method of claim 5, further comprising:including the UPDC-CM in a Quick UDP Internet Connections (QUIC) packet, wherein the QUIC packet is included in the HTTP datagram.
7. The method of any of the preceding claims, further comprising: transmitting, to the CN, a registration request message including an indication of a capability of the UE with respect to communicating in-band UPDC-CM messages.
8. The method of claim 7, further comprising:including, in the registration request message, an indication of a capability of the UE with respect to the UPDC.
9. The method of claim 1 or 2, further comprising:transmitting, to the CN, a request to establish a PDU session, the request including an indication of a capability of the UE with respect to communicating in-band UPDC-CM messages.
10. A method for facilitating user-plane (UP) data collection in a cellular communication network, the method implemented in a core network (CN) node and comprising:establishing, with a user equipment (UE), a user-plane (UP) connection for UP data collection, including establishing a User Datagram Protocol (UDP) tunnel; and communicating, with the UE and over the UDP tunnel, an in-band UP data collection control message (UPDC-CM) related to managing the UP data collection, the control message including a feature identifier (ID) identifying an artificial intelligence / machine learning (AEML)-enabled feature to which the UP data collection pertains.PATENT APPLICATION Attorney Docket No.: 31730 / 309152-0011. The method of claim 10 implemented in a data collection network function (DCNF), the method further comprising:communicating with the UE via a user plane function (UPF) operating as an Hypertext Transfer Protocol (HTTP) proxy.
12. The method of claim 10, further comprising:transmitting, to the UE, a DCNF address.
13. The method of any of claims 10-12, further comprising:receiving, from the UE, a registration request message including an indication of a capability of the UE with respect to communicating in-band UPDC-CM messages.
14. The method of any of claims 10-12, further comprising:receiving, from the UE, a request to establish a PDU session, the request including an indication of a capability of the UE with respect to communicating in-band UPDC-CM messages.
15. A device comprising processing hardware and configured to implement a method of any of the preceding claims.