[go: up one dir, main page]

WO2025096934A1 - Procédés et appareil pour améliorer une structure d'apprentissage automatique d'intelligence artificielle (aiml) pour prendre en charge une collecte de données d'unité de transmission-réception sans fil (wtru) - Google Patents

Procédés et appareil pour améliorer une structure d'apprentissage automatique d'intelligence artificielle (aiml) pour prendre en charge une collecte de données d'unité de transmission-réception sans fil (wtru) Download PDF

Info

Publication number
WO2025096934A1
WO2025096934A1 PCT/US2024/054109 US2024054109W WO2025096934A1 WO 2025096934 A1 WO2025096934 A1 WO 2025096934A1 US 2024054109 W US2024054109 W US 2024054109W WO 2025096934 A1 WO2025096934 A1 WO 2025096934A1
Authority
WO
WIPO (PCT)
Prior art keywords
wtru
data collection
application
network
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/054109
Other languages
English (en)
Inventor
Ulises Olvera-Hernandez
Oumer Teyeb
Tejaswinee LUTCHOOMUN
Michael Starsinic
Michel Roy
Yugeswar Deenoo NARAYANAN THANGARAJ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of WO2025096934A1 publication Critical patent/WO2025096934A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports

Definitions

  • An event consumer is a subscriber to event data produced by, e.g., a network function (NF).
  • the event data is produced and then exposed by the NF to the event consumer.
  • the event consumer may be another NF orAF.
  • a mobile network operator (MNO)-managed event consumer is an event consumer instance that is managed by the MNO, e.g., managed by network function (NF) within the MNO network.
  • the event consumer may be a trusted or an untrusted event consumer.
  • the event data exposure may be executed via a network exposure function (NEF), e.g., for non-trusted event consumer, or without an NEF, e.g., for a trusted event consumer
  • NEF network exposure function
  • Procedures for data collection and reporting for artificial intelligence/machine learning (AI/ML) applications which may run in a wireless transmit and receive unit (WTRU), are described.
  • the procedures may specify mechanisms performed by a network function in a core network, such as a network data analytics function (NWDAF), to collect data from the WTRU via an intermediary entity of function, such as an application function (AF).
  • NWDAAF network data analytics function
  • AF application function
  • Some functionalities supported by a 5G system (5GS) may be leveraged to facilitate such mechanisms.
  • Such functionalities may enable client configuration for WTRU data collection and data reporting, WTRU procedures to report collected data, and subsequent exposure of reported WTRU collected data to an AF.
  • a data collection application function may be implemented in a 5G core (5GC) network.
  • a WTRU direct data collection client may be implemented in a WTRU.
  • An AI/ML application may be running in the WTRU.
  • the application data may be collected by the WTRU AI/ML application and be internally reported to the WTRU direct data collection client for further processing and filtering.
  • the direct data collection client may submit a data report to the DCAF. Reception of a data report by the DCAF may result in an event being exposed to interested event consumers, which may have previously subscribed to this event, such as an NWDAF.
  • BRIEF DESCRIPTION OF THE DRAWINGS BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented
  • FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;
  • WTRU wireless transmit/receive unit
  • FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;
  • RAN radio access network
  • CN core network
  • FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment
  • FIG. 2 depicts a diagram of a reference architecture for WTRU data collection
  • FIG. 3 illustrates examples of reporting mechanisms
  • FIG. 4 illustrates a call flow of an example of WTRU configuration procedure for data collection and data reporting
  • FIG. 5 illustrates a call flow of an example of WTRU data reporting
  • FIG. 6 depicts a diagram of an instantiation of a Direct Data Collection Client as part of a WTRU application
  • FIG. 7 illustrates an example of deployment of an Al application and its associated DCAF collocated with a gNB
  • FIG. 8 illustrates an example of deployment of an Al application collocated with a gNB and a DCAF deployed outside the access network
  • FIG. 9 illustrates an example of deployment of an Al application and a DCAF deployed outside access network
  • FIG. 11 illustrates an example of an architecture for alignment of MDT and Al data reporting via the
  • MDT reporting entity using the architecture in FIG. 10, via control plane;
  • FIG. 12 illustrates an example of an architecture for alignment of MDT and Al data reporting via the Direct Data Collection Client, using the architecture in FIG 10, via user plane;
  • FIG. 13 illustrates an example of a variation of the architecture in FIG. 11 for the case when UPF and DCAF are collocated with the RAN;
  • FIG. 14 illustrates an example of a variation of the architecture in FIG. 12 for the case when UPF and DCAF are collocated with the RAN;
  • FIG. 15 depicts an example of policy based authorization of WTRU data collection
  • FIG. 16 depicts a call flow of an example of policy based user consent
  • FIG. 17 depicts a call flow of an example of application-triggered WTRU data collection
  • FIG. 18 depicts a call flow of an example of RAN configuration during application-triggered WTRU data collection
  • FIG. 19 is an example of a call flow for a diagram of WTRU data collection reporting when the reporting type is PMF;
  • FIG. 20 is an example of a call flow for a diagram of WTRU data collection reporting when the reporting type is OTT;
  • FIG. 21 is an example of a call flow for a diagram of WTRU data collection reporting when the reporting type is MDT;
  • FIG. 22 illustrates a high level diagram of an example of WTRU data collection configuration and reporting
  • FIG. 23 illustrates an example of a diagram of WTRU data collection for user plane adaptation via PMF, according to an embodiment
  • FIG. 24 illustrates an example of a diagram of instantiation of a Direct Data Collection Client in a PMF application, according to an embodiment
  • FIG. 25 illustrates an example of a MDT activation mechanism to enable routing of MDT measurements over a Direct Data Collection Client, according to an embodiment
  • FIG. 26 illustrates an example call flow of MNO-based user consent verification
  • FIG. 27 illustrates an example call flow of MNO-based configuration of WTRU data collection.
  • UE User Equipment UE and WTRU may be used interchangeably herein
  • WTRU Wireless T ransmitting-Receiving Unit WTRU and UE may be used interchangeably herein
  • FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA singlecarrier FDMA
  • ZT-UW-DFT-S- OFDM zero-tail unique-word discrete Fourier transform Spread OFDM
  • UW-OFDM unique word OFDM
  • FBMC filter bank multicarrier
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs wireless transmit/receive units
  • RAN radio access network
  • ON core network
  • PSTN public switched telephone network
  • Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and
  • UE user equipment
  • PDA personal digital assistant
  • HMD head-
  • the communications systems 100 may also include a base station 114a and/or a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or the other networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum
  • a cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • beamforming may be used to transmit and/or receive signals in desired spatial directions.
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • LTE-A Pro LTE-Advanced Pro
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface 116 using NR.
  • a radio technology such as NR Radio Access
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g , an eNB and a gNB).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e , Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.11 i.e , Wireless Fidelity (WiFi)
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 1X, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for
  • the base station 114b in FIG 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the CN 106.
  • the RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like.
  • QoS quality of service
  • the CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT.
  • the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
  • FIG. 1 B is a system diagram illustrating an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others.
  • GPS global positioning system
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit)
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li- ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like.
  • FM frequency modulated
  • the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and/or simultaneous.
  • the full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118).
  • the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e g., for transmission) or the DL (e g., for reception)).
  • a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e g., for transmission) or the DL (e g., for reception)).
  • FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the ON 106.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • MME mobility management entity
  • SGW serving gateway
  • PGW packet data network gateway
  • PGW packet data network gateway
  • the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an 81 interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA
  • the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface.
  • the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • packet-switched networks such as the Internet 110
  • the CN 106 may facilitate communications with other networks
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
  • the other network 112 may be a WLAN.
  • a WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP.
  • the AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS.
  • Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs.
  • Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations.
  • DS Distribution System
  • Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA
  • the traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic.
  • the peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS).
  • the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems.
  • the STAs e.g., every STA, including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off.
  • One STA (e.g., only one station) may transmit at any given time in a given BSS.
  • High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels
  • the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels.
  • a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
  • the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
  • IFFT Inverse Fast Fourier Transform
  • time domain processing may be done on each stream separately
  • the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA.
  • the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
  • MAC Medium Access Control
  • Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah.
  • the channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac.
  • 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum
  • 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum.
  • 802.11 ah may support Meter Type Control/Machine- Type Communications (MTC), such as MTC devices in a macro coverage area.
  • MTC Meter Type Control/Machine- Type Communications
  • MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g , only support for) certain and/or limited bandwidths
  • the MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
  • WLAN systems which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS.
  • the bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes.
  • Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.
  • STAs e.g., MTC type devices
  • NAV Network Allocation Vector
  • the available frequency bands which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.
  • FIG. 1 D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the CN 106.
  • the RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment.
  • the gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the gNBs 180a, 180b, 180c may implement MIMO technology.
  • gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c.
  • the gNB 180a may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • the gNBs 180a, 180b, 180c may implement carrier aggregation technology.
  • the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum.
  • the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology.
  • WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).
  • CoMP Coordinated Multi-Point
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).
  • TTIs subframe or transmission time intervals
  • the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
  • RANs e.g., such as eNode-Bs 160a, 160b, 160c.
  • WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band.
  • WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c
  • WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
  • eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.
  • Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • the CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator. [0084]
  • the AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node.
  • the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like.
  • Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
  • the AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface.
  • the SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface.
  • the SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
  • the SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like.
  • a PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.
  • the CN 106 may facilitate communications with other networks
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IP gateway e.g., an IP multimedia subsystem (IMS) server
  • IMS IP multimedia subsystem
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers
  • the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
  • one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).
  • the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
  • the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
  • the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment.
  • the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.
  • RF circuitry e g., which may include one or more antennas
  • Procedures for WTRU data collection and reporting for AIML applications may specify the mechanisms executed by a network data analytics function (NWDAF) to collect data from a WTRU via an intermediary entity of function, e.g., an application function (AF).
  • NWDAAF network data analytics function
  • the functionalities supported by a 5G system (5GS) may include client configuration for WTRU data collection and data reporting, WTRU procedures to report collected data, and subsequent exposure of reported WTRU collected data to an AF
  • FIG. 2 depicts a diagram of a reference architecture for WTRU data collection.
  • WTRU data is collected by a WTRU application 201, such as an artificial intelligence machine learning (AIML) application, and reported to a WTRU Direct Data Collection Client 202, for further processing and filtering.
  • the Direct Data Collection Client 202 may submit the data report to the Data Collection Application Function (DCAF) 203 in the network. Reception of a data report by the DCAF 203, may result in an event being exposed to interested event consumers, e.g., Network Data Analytics Function (NWDAF) 204, that may have previously subscribed to this event.
  • DCAF Data Collection Application Function
  • An event consumer is a subscriber to event data at the DCAF.
  • the term event consumer is used synonymously with the term NF consumer or NF service consumer in the 3GPP standards.
  • a mobile network operator (MNO)-managed event consumer is an event consumer instance that is managed by the MNO, e.g., a network entity such as a network function (NF) or an AF, or may be an event consumer.
  • Event data is data exposed by the DCAF to event consumers.
  • the term event data is used synonymously with the term event reporting information in the 3GPP standards. The exposure may be implemented via a network exposure function (NEF), e.g., for non-trusted event consumer, or without an NEF, e g., for a trusted event consumer.
  • a Direct Data Collection Client is a functional entity in a WTRU that collects data and reports it to the DCAF. Three data reporting reference points are supported: Direct Data Collection Client, Indirect Data Collection Client, and Application Server (AS).
  • FIG. 3 illustrates examples of reporting mechanisms.
  • a data report may be sent from the Direct Data Collection Client 301 to the DCAF 302, over the R2 interface 303.
  • a data report may be sent from the WTRU application 304 to the DCAF 302 via an indirect data collection function 305 of an application service provider (ASP) 306.
  • ASP application service provider
  • the data report may be sent from the WTRU application 304 to the indirect data collection function 305 in the ASP 306 via the user plane, i.e., R8 interface 307.
  • the indirect data collection function 305 may then send the data report to the DCAF 302, via the R3 interface 308.
  • the data may then be exposed to the NWDAF 309 via the R5 interface 310.
  • a DCAF may register to the 5GC (e.g., the NRF, over Nnrf service-based reference point) to indicate its event reporting capabilities by indicating the event IDs that it supports.
  • an event ID may refer to consumption reporting of WTRU data.
  • An ASP that is interested in exposing application specific events from WTRU applications, e.g., Quality of Experience (QoE), may use the R1 interface to configure WTRU data collection and data reporting in the one or more DCAFs that are assigned to the one or more WTRUs running the application of interest.
  • QoE Quality of Experience
  • the Direct Data Collection Client in the WTRU may use the R2 interface to acquire data collection and reporting configuration.
  • the Direct Data Collection Client in the WTRU may receive context information from a WTRU application over the R7 interface, which may trigger the Direct Data Collection Client to acquire the required configuration from the DCAF.
  • the WTRU may submit the data report over the same interface (i.e., R2)
  • FIG. 4 illustrates a call flow of an example of WTRU configuration procedure for data collection and data reporting.
  • An ASP may configure an application in the WTRU over the user plane 401
  • the configuration may include information such as authentication information, user consent, or the address of the relevant DCAF (e.g., IP address of DCAF).
  • An ASP provisioning function may provision the configuration of data reporting and WTRU data collection in the DCAF 402, for a specific application identified by the App ID, and for one or more specific events
  • the DCAF may authorize or reject the provisioning request, based on operator policies.
  • the WTRU application may be triggered by the ASP application to establish a context with the Direct Data Collection Client 403, e g., by providing authentication credentials, user consent, and Fully Qualified Domain Name (FQDN) of the relevant DCAF.
  • the Direct Data Collection Client triggered by the WTRU application that established the context, may retrieve the client configuration from the DCAF 404, for the relevant application identified by an App ID, and addressed by the FQDN provided by the WTRU application.
  • the Direct Data Collection Client may configure the WTRU application 405 for WTRU data collection and reporting, based on the configuration obtained from the DCAF.
  • FIG. 5 illustrates a call flow of an example of WTRU data reporting.
  • the WTRU application may report the relevant data. This may be done either directly 501 or indirectly 503.
  • the DCAF may receive the data report, either directly 502 or indirectly 504.
  • the DCAF may process the report 506 and determine whether an event needs to be reported. If so, it determines when it needs to be reported (e.g., immediately, a later time, or based on some condition), and the event consumer, e.g., NWDAF.
  • the DCAF may expose the event 506 to the event consumer that has previously subscribed to this event.
  • the DCAF may provide the WTRU ID, event ID, and event specific parameters, e.g., quality of experience information.
  • a Direct Data Collection Client function may be instantiated inside other WTRU functions to satisfy the domain-specific data collection and reporting requirements corresponding to specific features of the 5G System.
  • reporting domain-specific data collection client instances operating simultaneously on a given WTRU, each one performing a different role.
  • One valid deployment option may be to combine these instances in a common middleware component.
  • Another option may be to provide the Direct Data Collection Client as an integral part of each relevant WTRU application.
  • FIG. 6 depicts a diagram of an instantiation of a Direct Data Collection Client as part of a WTRU application.
  • a WTRU 601 comprises a WTRU application 602 and a Direct Data Collection Client 603 is instantiated as part of the application.
  • the Direct Data Collection Client 603 communicates with the DCAF 604 via the R2 interface 605.
  • the WTRU application 602 communicates with the ASP 606 via the R8 interface 607.
  • the WTRU will report the data collected to the network, and therefore a route improvement for WTRU data reporting may be implemented, with a possible deployment of the application and/or the associated DCAF close to the radio access network (RAN), e g., close/co-located to/with a gNB.
  • RAN radio access network
  • This may optimize the data path between the Direct Data Collection Client and the DCAF, which may be co-located with the gNB, and the application, which may be residing in the gNB.
  • FIG. 7 illustrates an example of deployment of an Al application and its associated DCAF collocated with a gNB.
  • the Al application 701 may be deployed in the RAN node 702.
  • the DCAF 703 may also implemented in the RAN node 702.
  • the DCAF 703 may be implemented as part of the Al application 701, as it is shown in this example in FIG. 7.
  • FIG. 8 illustrates an example of deployment of an Al application collocated with a gNB and a DCAF deployed outside the access network
  • the Al application 801 is collocated with a gNB 802.
  • the DCAF 803 is located outside the access network, e.g., outside the gNB.
  • the DCAF 803 may be part of the CN or may be outside the CN.
  • the Al application 801 may provision the DCAF 803 over the R1 interface 804.
  • a new interface may be defined from the gNB to the DCAF.
  • FIG. 9 illustrates an example of deployment of an Al application and a DCAF deployed outside access network.
  • the gNB 901 may provide Al specific parameters to the Al application 902, according to the specific use case or feature the gNB wants the Al application to execute. These parameters may be provided from the gNB directly to the Al application 902, via a new interface 903, or though the CN, e.g , using enhanced N2 procedures (e.g., through the AMF/SMF). Then the application-specific provisioning may be executed via the R1 interface 904.
  • An MNO may be enabled to control and manage configuration of WTRU data collection, WTRU data reporting, and WTRU data exposure This may include specific operator policies governing an authorization mechanism in the DCAF or operator polices directly updated to the WTRU Direct Data Collection Client. Among other considerations, end-user security, RAN configuration requirements for model training, and impact to the 5G system may be considered.
  • a 5GS may support WTRU data collection over the control plane, such as through Minimization of Drive Test (MDT).
  • MDT Minimization of Drive Test
  • the application specific WTRU data reporting and the MDT data reporting may co-exist and benefit from one another. Mechanisms may be used to determine when one is used over the other or when they are used in conjunction.
  • WTRU data may be reported independently from the existing MDT data reporting mechanism or in conjunction with it.
  • the CN may use policies to configure the WTRU to enable joint or independent data reporting.
  • FIG. 10 illustrates an example of an MNO-integrated architecture for data collection.
  • WTRU data may be sent to the DCAF 1001 over the control plane, e.g., using RRC or NAS signaling.
  • WTRU data may be sent to the DCAF over the user plane, e.g., using a PDU session.
  • WTRU data may be reported to the DCAF 1001 using a direct connection 1002 from the gNB to DCAF.
  • WTRU data may be reported through the control plane 1003, for instance using RCC signalling and/or NAS signalling.
  • WTRU data may be reported through the data plane, using a PDU session 1004 toward the DCAF.
  • the RRC may send data to the UPF 1005, possibly with the usage of a gateway function in between the RRC and UPF. Examples implementing some of these different options using the architecture from FIG. 10 are illustrated in FIGs. 11-14. [0126]
  • FIG. 11 illustrates an example of an architecture for alignment of MDT and Al data reporting via the MDT reporting entity, using the architecture in FIG. 10, via control plane.
  • the WTRU may combine the Al data collected and the MDT data collected and report via the control plane.
  • the Direct Data Collection Client 1101 is shown as a separate entity of the Al application client 9002.
  • the Direct Data Collection Client 1101 may be instantiated as part of the Al application client 1102.
  • the combination/aggregation of the two types of data e.g., Al data collected and MDT data collected, may be performed by the Direct Data Collection Client 1101 in the WTRU, or by the MDT entity in the WTRU 1103.
  • the information may be sent by the WTRU to the network in a NAS message encapsulated in an RRC message 1104.
  • the NAS message 1105 may be forwarded to the AMF/SMF 1106 in the CN.
  • the AMF/SMF 1106 may interface with the DCAF 1107, either directly or via NEF 1108.
  • FIG. 12 illustrates an example of an architecture for alignment of MDT and Al data reporting via the Direct Data Collection Client, using the architecture in FIG 10, via user plane.
  • the WTRU may combine the Al data collected and the MDT data collected and report via the user plane.
  • the Direct Data Collection Client 1201 is shown as a separate entity of the Al application client 1202.
  • the Direct Data Collection Client 1201 may be instantiated as part of the Al application client 1202.
  • the combination/aggregation of the two types of data e.g., Al data collected and MDT data collected, may be performed by the Direct Data Collection Client 1201 in the WTRU, or by the MDT entity in the WTRU 1203.
  • the combined information may be sent by the WTRU to the DCAF 1204 via the user plane using a PDU session 1204 towards the DCAF.
  • FIG. 13 illustrates an example of a variation of the architecture in FIG. 11 for the case when UPF and DCAF are collocated with the RAN.
  • the combined reporting is sent via the control plane to the RRC entity 1301 in an RRC message 1302.
  • the RRC 1301 may process the information and send it to a gateway function/local switch 1303, which forwards to the UPF 1304. From the UPF 1304, the data may be reported to the DCAF 1305.
  • the UPF 1304 and the Al application server/DCAF 1305 may be co-located with the gNB at the RAN location 1306 to minimize end-to-end the latency.
  • FIG. 14 illustrates an example of a variation of the architecture in FIG. 12 for the case when UPF and DCAF are collocated with the RAN 1401 .
  • Embodiments are disclosed herein to address M NO-driven WTRU data collection and reporting.
  • MNO-based WTRU data collection and MNO controlled AF authorization to configure an Al application operates entirely on top of 5GS. Therefore, new procedures may be required to enable the MNO to authorize, configure, and filter WTRU measurements using the existing policy framework. It may be beneficial to leverage the current user consent information stored in the subscriber record to assist with the determination of which WTRU data/measurements should be allowed.
  • FIG. 15 depicts an example of policy based authorization of WTRU data collection
  • a policy-based mechanism enables an MNO to control WTRU data collection.
  • the ASP may request authorization from the CN to configure Al application parameters to enable WTRU data collection, e.g., for model training and/or inference 1501.
  • the AF may provide the DNN, S-NSSAI, AF service ID and intended configuration data for collection of Al application data, e g., configuration measurements to obtain data for model training.
  • the NEF may obtain user consent and authorization of the intended WTRU data collection configuration, possibly filtering on user consentfor specific measurements or data, through a user consent map 1502.
  • operator policies may allow a specific ASP (as defined by the AF service ID) to execute a direct WTRU data collection configuration procedure, entirely over the user plane.
  • User consent map may comprise a filter or association of user consent to a specific measurement or data being collected.
  • the NEF may provide the user consent map and a token or secure reference that the ASP may use to authenticate the user consent, when a direct ASP/WTRU application configuration is executed 1503
  • FIG. 16 depicts a call flow of an example of policy based user consent.
  • the WTRU may register to the network and it may provide its WTRU data collection 5GMM CN capability, indicating its ability to collect application specific measurements, e.g., Al applications measurements for model training.
  • the capability may be sent in a NAS message, for instance, it may be sent in the NAS Registration Request message 1601 .
  • the presence of this information may trigger the AMF to obtain the user consent and the associated WTRU data collection allowance from the subscriber record.
  • the data collection allowance may be based on the user consent.
  • Data collection allowance is the allowed data collection type, e.g., Performance Management Function (PMF), Minimization of Drive Tests (MDT), Over the Top (OTT) or Hybrid (a combination of these types or mechanisms).
  • PMF Performance Management Function
  • MDT Minimization of Drive Tests
  • OTT Over the Top
  • Hybrid a combination of these types or mechanisms.
  • the AMF may request WTRU data collection subscription information from the UDM. 1602
  • the presence of this WTRU data collection 5GMM CN capability provided by the WTRU in the Registration Request message signals the AMF to obtain the user consent and the associated WTRU data collection allowance from the subscriber record, based on the user consent.
  • the AMF may provide, to the WTRU, the user consent map, associated S-NSSAI, and DNN where the WTRU data collection is authorized and the user consent token 1604.
  • the use consent token may provide user consent integrity and DCAF authentication credentials. This may be sent, for instance, in the NAS Registration Accept message.
  • the 5G NAS layer in the WTRU may deliver, to the Direct Data Collection Client, per App ID, the user consent purpose, and user consent token so that the user consent is not tampered with at the application layer 1605.
  • User consent purpose is the user consent associated to a specific application ID, e.g., the user may be able to consent to data collection on per application-basis, and a token may also be associated to the user consent purpose.
  • FIG. 17 depicts a call flow of an example of application-triggered WTRU data collection.
  • An Al AF that has been granted authorization to configure a WTRU Al application client may request notification from the 5GS when a WTRU Al application requests a data connection leading to the establishment of a PDU session or the modification of a PDU session with the purpose of contacting a DCAF.
  • the notification request/response may be enabled by the NEF. This is illustrated 1700a and 1700b.
  • the WTRU Al application may trigger a request for WTRU data collection configuration. This may trigger, in the WTRU Direct Data Collection Client, a request from the NAS layer for data connectivity for a specific DNN and S-NSSAI.
  • the WTRU Al application may request WTRU data collection configuration from the Direct Data Collection Client 1701 and it provides the App ID and user consent token that was received from the Al AF
  • a WTRU Al application may request a modification to the data connection, if e g., perceived Quality of Experience is suboptimal.
  • the Direct Data Collection Client may verify the user consent. To verify consent, the Direct Data Collection Client may compare the token received from the AF with the token received from the network/UDM. User consent is confirmed/authorized when the two tokens match. If authorized, the Direct Data Collection Client requests data connectivity from the NAS layer 1702, providing the App Id, OSid, DNN and S-NSSAI. If a WTRU Al application requests modifications to the data connection supporting the application, then the Direct Data Collection Client may request modifications to the PDU session, causing the NAS layer to trigger a PDU Session Modification request, e.g., using an Attention (AT) Command.
  • AT Attention
  • the NAS layer in the WTRU may send, to the AMF, a PDU Session Establishment Request message 1703, indicating the chosen WTRU data collection type (e.g., PMF, MDT, Hybrid) and it also indicates a new PDU session request type to signal the use of the PDU session for WTRU data collection.
  • the WTRU, or the network e.g., the SMF, may request updates to existing PDU session parameters by using a PDU session modification procedure.
  • the WTRU may request new QoS values, or the SMF, prompted by a modification to the session management policy association from the PCF, may request policy modifications, such as a new WTRU data collection mechanism.
  • the SMF may request SM policy association from the PCF 1704, and it provides the request type to indicate PDU session establishment for the purpose of WTRU data collection.
  • the PCF may provide WTRU data collection policies 1705, including guidance as to when WTRU data collection may be applied under system conditions including slice load, specific WTRU data collection mechanisms, e.g., Performance Measurement Function (PMF), Minimization of Drive Tests (MDT), Over the Top (OTT), or a combination thereof, as well as geographical and validity conditions.
  • PMF Performance Measurement Function
  • MDT Minimization of Drive Tests
  • OTT Over the Top
  • FIG. 18 depicts a call flow of an example of RAN configuration during application-triggered WTRU data collection.
  • the AMF may send a response 1801 to the subscription request (which was illustrated in FIG. 17, 1700b) and it may include the address of the DCAF that the Al AF can use to configure the WTRU Al application client.
  • the SMF may configure the gNB with RAN WTRU data collection policies, including slide load allowance and QoS thresholds.
  • the gNB may configure the WTRU RRC layer, per App ID, with relevant Al model measurements and allowed WTRU data collection mechanisms.
  • the SMF in response to the PDU Session Establishment Request message 1703, using a PDU Session Establishment Accept message 1804, may deliver new WTRU data collection policies to the WTRU NAS layer 1406, including WTRU data collection assistance information, allowed data collection mechanisms (i.e., PMF, OTT, MDT or a combination thereof), QoS parameters per QoS flow associated to specific WTRU application layer measurements and the associated DCAF address.
  • WTRU data collection assistance information i.e., PMF, OTT, MDT or a combination thereof
  • QoS parameters per QoS flow associated to specific WTRU application layer measurements and the associated DCAF address.
  • the NAS layer may pass, to upper layer, WTRU data collection assistance information, allowed data collection mechanisms (i.e., PMF, OTT, MDT or a combination thereof), and the associated DCAF address 1805.
  • WTRU data collection assistance information i.e., PMF, OTT, MDT or a combination thereof
  • allowed data collection mechanisms i.e., PMF, OTT, MDT or a combination thereof
  • the Direct Data Collection Client may configure, per App ID, the WTRU Al application 1408 using the WTRU data collection assistance information received from the NAS layer 1806.
  • the WTRU may report WTRU data collection results using a data collection type (i.e., PMF, MDT, OTT) or a combination thereof.
  • a data collection type i.e., PMF, MDT, OTT
  • FIG. 19 is an example of a call flow for a diagram of WTRU data collection reporting when the reporting type is PMF.
  • the PMF may be instantiated as a Direct Data Collection Client
  • the WTRU Al application may request application layer measurements from the WTRU Direct Data Collection Client 1901.
  • the WTRU Al application provides the GPSI, App ID and DCAF address.
  • an instantiation of the PMF application may request relevant application layer measurements from the RRC layer 1902, and provides the relevant application layer measurement configuration, provided by the WTRU Al application.
  • the RRC layer in the WTRU may request from the gNB application layer measurement control 1903 to provide, e.g. , guarantee that the measurements are performed using applicable QoS and are done according to the configuration provided in the RAN WTRU data collection rule, and the specifics of the application layer measurement, e.g , whether these measurements are intended for positioning, beam forming channel state indication (CSI) model training, e.g., by using the model ID provided by the WTRU Al application.
  • the gNB may, at any time, modify the application layer measurement reporting mechanism, e.g., based on cell load, slice load, geographical or time-based conditions.
  • the RRC layer may provide applicable Al application layer measurements 1904
  • the PMF client may forward the Al application WTRU data collected for the specific WTRU Al application 1905, and it provides App ID, PDU session ID, and QFI(s).
  • the PMF instantiation in the DCAF uses the App ID, PDU session ID, and QFI(s), to identify the specific instances of the WTRU Al application for which the data has been collected.
  • FIG. 20 is an example of a call flow for a diagram of WTRU data collection reporting when the reporting type is OTT.
  • the WTRU Al application may request application layer measurements from the Direct Data Collection Client 2001 .
  • the WTRU Al application provides the GPSI, App ID, and DCAF address.
  • the Direct Data Collection Client may request relevant application layer measurements from the RRC layer 2002, and may provide the relevant application layer measurement configuration, provided by the WTRU Al application directly to the DCAF address by the DCAF address information provided by the WTRU data collection rule or provided by the WTRU Al application.
  • the WTRU data collection rule information has presence over the DCAF address provided by the WTRU Al application
  • the RRC layer in the WTRU may request from the gNB application layer measurement control 2003 to guarantee, that the measurements are performed using applicable QoS and are done according to the configuration provided in the RAN WTRU data collection rule, and the specifics of the application layer measurement, e.g., whether these measurement are intended for positioning, beam forming or CSI model training, e.g., by using the model ID provided by the WTRU Al application.
  • the gNB may, at any time, modify the application layer measurement reporting mechanism, e.g., based on cell load, slice load, geographical or time-based conditions.
  • the RRC layer may provide applicable Al application layer measurements 2004
  • the Direct Data Collection Client forwards, to the DCAF, the Al application WTRU data collected for the specific WTRU Al application 2005. It may provide App ID, PDU session ID, and QFI(s). The DCAF may use the App ID, PDU session ID, and QFI(s), to identify the specific instances of the WTRU Al application for which the data has been collected.
  • FIG. 21 is an example of a call flow for a diagram of WTRU data collection reporting when the reporting type is MDT.
  • the WTRU Al application may request application layer measurements from the Direct Data Collection Client 2101 .
  • the WTRU Al application provides the GPSI, App ID, and DCAF address.
  • the Direct Data Collection Client requests relevant application layer measurements from the RRC layer 2102, and provides the relevant application layer measurement configuration, provided by the WTRU Al application, including the DCAF address, PDU session ID, and QFI(s).
  • the RRC layer in the WTRU requests from the gNB application layer measurement control 2103 to provide, e.g., to guarantee, that the measurements are performed using applicable QoS and are done according to the configuration provided in the RAN WTRU Data Collection rule, and the specifics of the application layer measurement, e.g., whether these measurement are intended for positioning, beam forming or CSI model training, e.g., by using the model ID provided by the WTRU Al application.
  • the gNB may, at any time, modify the application layer measurement reporting mechanism, e g, based on cell load, slice load, geographical or time-based conditions.
  • the RRC layer may forward, through the gNB, using RCC signaling, the applicable Al application layer measurements, and it provides GPSI, PDU session ID, and QFI9s 2104.
  • the gNB may forward, to the AMF, using NGAP signaling, the applicable Al application layer measurements 2105, and it provides GPSI, PDU session ID, and QFI(s)
  • the AMF may forward, to the DACF (possibly through NEF), the applicable Al application layer measurements 2106, and it provides GPSI, PDU Session ID, and QFI(s), e.g, within an Naf_Event_Notification message).
  • the DCAF may provide event notification services to service consumers, e.g, NWDAF.
  • FIG. 22 illustrates a high level diagram of an example of WTRU data collection configuration and reporting.
  • the NAS layer 2201 may provide 2202 to the Direct Data Collection Client 2203 a WTRU data collection rule or set of rules indicating the reporting mechanism the Direct Data Collection Client 2203 may use to submit application layer-specific WTRU data measurements.
  • the rule may indicate that for certain geographical locations (e.g, cell IDs or zones) or certain period of times (e.g, during a midnight maintenance period), the WTRU may be allowed to collect data for specific applications on a specific network slice, possibly using the slice load as a criteria for reporting.
  • the rules may also include the mechanism for reporting, such as PMF, MDT or OTT.
  • the data measurements to be collected may be configured at the RRC layer 2204.
  • the RRC layer 2204 may report measurements 2205 to the Direct Data Collection Client 2203.
  • the Direct Data Collection Client 2203, or the PMF 2206, in case the reporting mechanism is PMF, may report the measurements to the DCAF 2207.
  • the reporting may be implemented over the user plane 2208 / R8 interface 2209, or over the control plane 2209, via RRC 2206 in an RRC application layer measurement container.
  • the WTRU data reporting rule may also indicate RAN reporting control, e.g., using an extension of the existing RAN visible QoE (or QoS) measurements, and defining a new set of measurements, e.g., based on the model that needs to be trained, e.g., measurements for training a positioning model.
  • RAN reporting control e.g., using an extension of the existing RAN visible QoE (or QoS) measurements, and defining a new set of measurements, e.g., based on the model that needs to be trained, e.g., measurements for training a positioning model.
  • the Direct Data Collection Client may be instantiated as an extension of the PMF protocol.
  • DCAF may be housed in the PSA.
  • the Al AF could be separate or co-located in the PSA.
  • FIG. 23 illustrates an example of a diagram of WTRU data collection for user plane adaptation via PMF, according to an embodiment.
  • the configuration of MDT data measurements may be implemented by inserting an adaptation layer 2301 that maps or translates configuration commands from the Al App extension 2302 (via the adaptation layer) to MDT configuration information.
  • the MDT configuration information may be injected directly 2303 onto the RRC layer 2304, as depicted by the arrow 2303 that points from the adaptation layer to the RRC layer.
  • FIG. 24 illustrates an example of a diagram of instantiation of a Direct Data Collection Client in a PMF application, according to an embodiment.
  • an Al application function may be able to configure MDT functionality by contacting a Direct Data Collection Client that has an adaptation layer 2401 , similarly to FIG. 23, 2301. Also here, the arrow pointing downwards 2402 illustrates the configuration of MDT measurements in the RCC layer, as directed by the Al Application Function
  • the RCC layer may send MDT measurements via the Direct Data Collection Client, which is illustrated by the arrow going upwards from the RCC layer to the WTRU Al Application 2501.
  • the WTRU Al Application may then send the data to the Al Application Function (similar to the example in FIG. 24).
  • the access network e.g., gNB
  • the access network e.g., gNB
  • FIG. 26 illustrates an example call flow of MNO-based user consent verification.
  • the AF provides a user consent token to the WTRU, 2600a, 2600b.
  • the AF obtains the user consent token from the core network.
  • the WTRU NAS layer may provide may register with the network 2601 and indicate its data collection capability.
  • the network e.g., AMF
  • the network may provide a user consent token, user consent map, associated S-NSSAI, and DNN where the WTRU data collection is authorized 2602.
  • the use consent token may provide user consent integrity and DCAF authentication credentials.
  • the WTRU NAS layer may deliver, to the Direct Data Collection Client, per App ID, the user consent token and the user consent purpose 2603.
  • the WTRU Al application may trigger a request for WTRU data collection configuration 2604. This may trigger, in the WTRU Direct Data Collection Client, a request from the NAS layer for data connectivity for a specific DNN and S-NSSAI.
  • the WTRU Al application may provide the App ID and user consent token that was received from the Al AF.
  • the WTRU may verify the user consent 2605 by comparing the one received initially from the AF 2600b with the one received from the AMF 2603.
  • FIG. 27 illustrates an example call flow of MNO-based configuration of WTRU data collection.
  • the Direct Data Collection Client may request to the NAS layer a PDU session establishment 2701.
  • the NAS layer may send the request to the CN (e.g., AMF) 2702, indicating the PDU session is to be used to transport WTRU data collection, and it may indicate the preferred WTRU data collection type (e.g., PMF, MDT, OTT, Hybrid).
  • the SMF may obtain the data collection policies from the PCF 2703.
  • the network may include WTRU data collection assistance information, allowed data collection mechanisms (e.g., PMF, OTT, MDT or a combination thereof), and an associated DCAF address.
  • the Direct Data Collection Client in the WTRU may configure the WTRU Al application using the WTRU data collection assistance information received from the NAS layer 2705. If there are more than one applications, this may be done for each application, based on the App ID.
  • the Direct Data Collection Client in the WTRU may obtain the measurements from the RRC layer and send the measurements to the network.
  • the reporting may be done using a PMF over PMFP, or a DCAF over user plane, or MDT over RRC signaling.
  • the OTT server may directly request the RAN/CN data to be collected for some Al ML related operation such as training, and the RAN/CN may control the whole data collection process on behalf of the OTT server (e.g., choose the WTRUs from which to collect the data, initiate the data collection procedure, collect the data from the different WTRUs, etc.,) and may provide the collected data to the OTT server.
  • the OTT server may directly request the RAN/CN data to be collected for some Al ML related operation such as training, and the RAN/CN may control the whole data collection process on behalf of the OTT server (e.g., choose the WTRUs from which to collect the data, initiate the data collection procedure, collect the data from the different WTRUs, etc.,) and may provide the collected data to the OTT server.
  • the RAN or ON may have proactively collected data from a multitude of WTRUs, and can provide a subset of the collected data to an OTT server on request.
  • an OTT server may pre-register to be informed when a certain type of collected data becomes available at the RAN/CN (e g., data collected in certain locations, time of day, containing certain information elements, from certain types of users, and/or serving cell frequencies).
  • a certain type of collected data becomes available at the RAN/CN (e g., data collected in certain locations, time of day, containing certain information elements, from certain types of users, and/or serving cell frequencies).
  • the RAN/CN may modify the collected data before sending it to the OTT server. For example, the RAN/CN may remove/obfuscate/randomize some information elements such as WTRU identities, locations, etc., to ensure that user privacy/anonymity is preserved and/or confidential network information such as configuration/deployment information is not revealed to the external OTT entity.
  • some information elements such as WTRU identities, locations, etc.
  • the WTRU is aware/informed about the purpose of the data collection. This could be part of the initial registration/user consent provisioning process, or it could be done separately For example, a user may give a consent for the data to be used for certain purposes but not for other purposes, and the RAN/CN can prevent such information from being provided to the external OTT server (or at least can cause such information to be transformed in such a way that the user/WTRU information is not detectable from the collected data).
  • the WTRU may have full or partial autonomy in performing the data collection and the sending of the collected data.
  • the OTT/RAN/CN may request the initiation of the data collection procedure and the WTRUs may refuse to do the data collection (e g., send a response with a rejection message indicating the rejection reason, e.g., limitations in resources such as battery, memory, etc.).
  • This rejection could be temporary or final (e.g , the WTRU may indicate the data collection can be done later or when certain conditions are fulfilled.)
  • the WTRU/user proactively volunteers for data collection and informs the RAN/CN/OTT (e.g , indicating the type of data that the WTRU/user is willing to collect and to report and/or the amount/size of data to report).
  • the RAN/CN/OTT e.g , indicating the type of data that the WTRU/user is willing to collect and to report and/or the amount/size of data to report.
  • a WTRU that has already established a PDU session and/or a RRC connection may request the RAN/CN for a PDU session modification and/or a RRC connection reconfiguration to
  • the WTRUs may request modification or setup of the radio bearer(s) to be used for the transmission of the data, may request the network to provide additional information such as measurement configurations of neighbor cells, interfrequency cells, etc., and/or request the network to start sending additional reference signals, etc.
  • a WTRU may terminate or pause an ongoing data collection (e.g., if the size of the collected data becomes bigger than a certain amount, if the WTRU battery level falls below a certain level, if the WTRU experiences overheating, etc.), and may inform the RAN/CN/OTT server.
  • an ongoing data collection e.g., if the size of the collected data becomes bigger than a certain amount, if the WTRU battery level falls below a certain level, if the WTRU experiences overheating, etc.
  • a WTRU may terminate or pause an ongoing transmission of collected data (e.g., for reasons like the termination/pausing of the data collection).
  • a WTRU may resume/restart a paused/terminated data collection procedure and may inform the network/OTT server.
  • the WTRUs may inform the network/OTT server that the data collection can be resumed/restarted, and then will resume the data collection.
  • WTRUs may decide to resume/restart a paused/terminated transmission of collected data and may send an indication/request to the network/OTT server.
  • Devices and systems that can be constructed, configured, or that can operate according to subject matter disclosed herein include smart phones, tablets, wearables, head-mounted displays, connected vehicles, drones, CPE gateways, access points, base stations, core networks, and servers.
  • an AF performs the following actions: the AF provides the DNN, S-NSSAI, AF service identification or identifier (ID) and intended configuration data for collection of Artificial Intelligence (Al) application data, e g., configuration measurements to obtain data for Model Training.
  • MNO Mobile Network Operator
  • ID AF service identification or identifier
  • Al intended configuration data for collection of Artificial Intelligence (Al) application data, e g., configuration measurements to obtain data for Model Training.
  • a Network Exposure Function performs the following actions: the NEF obtains, from the Unified Data Management (UDM), user consent and authorization of the intended WTRU data collection configuration, possibly filtering on user consent for specific measurements or data, through a user consent map
  • operator policies may allow a specific ASP (as defined by the AF Service ID), to execute a direct WTRU data collection configuration procedure, entirely over the User Plane; and the NEF provides the user consent map and a token or secure reference that the ASP uses to authenticate the user consent, when a direct ASP/WTRU application configuration is executed.
  • a WTRU performs the following actions: the WTRU registers to the network and it provides its WTRU data collection 5GMM Core Network Capability indicating its ability to collect application specific measurements, e.g., Al applications measurements for Model Training; the presence of this information element signals the Access and Mobility Management Function (AMF) to obtain the user consent and the associated WTRU data collection allowance from the subscriber record, based on the user consent; and at the WTRU, the 5G NAS layer delivers, per an App ID, the user consent purpose, and user consent token obtained from the AMF, to provide that the user consent is not tampered with at the application layer.
  • AMF Access and Mobility Management Function
  • An AMF performs the following actions: the AMF obtains the user consent and the associated WTRU data collection allowance from the subscriber record, relevant for this user consent; and the AMF also provides the user consent map, associated S-NSSAI, and DNN where the WTRU data collection is authorized and the user consent token provides user consent integrity, and the user consent token also might provide DCAF authentication credentials.
  • a WTRU performs the following actions: the Direct Data Collection Client in a WTRU verifies the user consent provided by a WTRU application, and if the request is authorized, the Direct Data Collection Client requests data connectivity from the NAS layer, providing the App Id, Operating System Identification/ldentifier (OSid), DNN, and S-NSSAI; the WTRU (NAS layer) issues a PDU Session Establishment Request, indicating the chosen WTRU data collection type (e.g., Performance Management Function (PMF), Minimization of Drive Test (MDT), Hybrid) and it also indicates a new PDU Session Request Type to signal the use of the PDU session as WTRU data collection; the NAS layer in the WTRU passes, to the upper layer, WTRU data collection assistance information, allowed data collection mechanisms (i e., PMF, Over the Top (OTT), MDT or a combination thereof), and the associated DCAF address; and the Direct
  • An SMF performs the following actions: the SMF requests SM policy association from the PCF, and it provides the Requested Type to indicated PDU session establishment for the purpose of WTRU data collection; the SMF, using a PDU Session Establishment Accept message, delivers new WTRU data collection policies to the WTRU NAS layer, including WTRU data collection assistance information, allowed data collection mechanisms (i.e., PMF, OTT, MDT or a combination thereof), QoS parameters per QoS flow associated to specific WTRU application layer measurements and the associated DCAF address; and the SMF, e.g., using an Initial Context Setup message, configures the gNB with RAN WTRU data collection policies, including slide load allowance and QoS thresholds.
  • PDU Session Establishment Accept message delivers new WTRU data collection policies to the WTRU NAS layer, including WTRU data collection assistance information, allowed data collection mechanisms (i.e., PMF, OTT, MDT or a combination thereof), QoS parameters per QoS
  • a PCF performs the following actions: the PCF provides WTRU data collection policies, including guidance as to when WTRU data collection can be applied under system conditions including slice load, specific WTRU data collection mechanisms, e.g., PMF, MDT, OTT or a combination thereof, as well as geographical and validity conditions.
  • WTRU data collection policies including guidance as to when WTRU data collection can be applied under system conditions including slice load, specific WTRU data collection mechanisms, e.g., PMF, MDT, OTT or a combination thereof, as well as geographical and validity conditions.
  • a RAN node e.g., a gNB performs the following actions: the gNB, e g., using RRC signaling, configures the WTRU RRC layer, per an App ID, with relevant Al model measurements and allowed WTRU data collection mechanisms
  • a WTRU performs the following actions: [0227] The WTRU Al application requests application layer measurements from the WTRU Direct Data Collection Client. The WTRU Al application provides the GPSI, App ID and DCAF address; [0228] If the Direct Data Collection Client in the WTRU is configured to request WTRU Al measurements using PMF functionality, an instantiation of the PMF application requests relevant application layer measurements from the RRC layer, and provides the relevant application layer measurement configuration, provided by the WTRU Al application;
  • the Direct Data Collection Client If the Direct Data Collection Client is configured to request WTRU Al measurements using an over the top data connection mechanism, the Direct Data Collection Client requests relevant application layer measurements from the RRC layer, and provides the relevant application layer measurement configuration, provided by the WTRU Al application directly to the DCAF address by the DCAF address information provided by the WTRU data collection rule or provided by the WTRU Al application;
  • the RRC layer forwards, through the gNB, using RCC signaling, the applicable Al application layer measurements, and it provides GPSI, PDU Session ID, and QFI9s.
  • the RRC layer in the WTRU provides applicable Al application layer measurements, as received from the gNB;
  • the reporting mechanism is PMF to DCAF
  • the PMF client in the WTRU forwards to the DCAF, the Al application WTRU data collected for the specific WTRU Al application, and it provides an App ID, PDU Session ID, and QFI(s);
  • the Direct Data Collection Client requests the RRC layer to forward application layer measurements to the AMF, via gNB, and it provides GPSI, PDU Session ID, and QFI(s).
  • a RAN node e.g., a gNB performs the following actions: the gNB may at any time modify the application layer measurement reporting mechanism, e.g., based on cell load, slice load, geographical, or time-based conditions; and for MDT based WTRU data collection, the gNB forwards to the AMF, using NGAP signaling, the applicable Al application layer measurements, and it provides GPSI, PDU Session ID, and QFI(s)
  • a Data Collection Application Function performs the following actions: the PMF instantiation in the DCAF, or the DCAF itself, uses the App ID, PDU session ID, and QFI(s) to identify the specific instances of the WTRU Al application for which the data has been collected.
  • the DCAF may provide event notification services to service consumers, e.g., NWDAF.
  • an AMF performs the following actions: the AMF forwards, to the DACF (possibly through NEF), the applicable Al application layer measurements, and it provides GPSI, PDU session ID and QFIs, e.g., within an Naf_Event_Notification message.
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Une unité de transmission-réception sans fil (WTRU) peut recevoir, d'un réseau, un jeton de consentement d'utilisateur. L'unité WTRU peut déterminer, sur la base du jeton de consentement d'utilisateur, que le consentement d'utilisateur est autorisé. L'unité WTRU peut envoyer, au réseau, une demande d'établissement d'une session d'unité de données de protocole (PDU). La demande peut comprendre un type de demande indiquant une session de données pour une collecte de données de mesure spécifique à une application. L'unité WTRU peut recevoir, du réseau, une indication de l'acceptation de la session PDU. L'indication peut comprendre des informations d'assistance à la collecte de données d'unité WTRU qui sont spécifiques à une application. L'unité WTRU peut utiliser les informations d'assistance à la collecte de données spécifiques à l'application pour déterminer une configuration de collecte et de rapport de données associée à l'application. L'unité WTRU peut envoyer, au réseau, à l'aide de la session PDU établie et sur la base de la configuration de collecte et de rapport de données, un rapport de mesure spécifique à une application.
PCT/US2024/054109 2023-11-02 2024-11-01 Procédés et appareil pour améliorer une structure d'apprentissage automatique d'intelligence artificielle (aiml) pour prendre en charge une collecte de données d'unité de transmission-réception sans fil (wtru) Pending WO2025096934A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363595524P 2023-11-02 2023-11-02
US63/595,524 2023-11-02

Publications (1)

Publication Number Publication Date
WO2025096934A1 true WO2025096934A1 (fr) 2025-05-08

Family

ID=93590621

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/054109 Pending WO2025096934A1 (fr) 2023-11-02 2024-11-01 Procédés et appareil pour améliorer une structure d'apprentissage automatique d'intelligence artificielle (aiml) pour prendre en charge une collecte de données d'unité de transmission-réception sans fil (wtru)

Country Status (1)

Country Link
WO (1) WO2025096934A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120254320A1 (en) * 2011-04-04 2012-10-04 Microsoft Corporation Distributing collected information to data consumers based on global user consent information
WO2022026482A1 (fr) * 2020-07-30 2022-02-03 Convida Wireless, Llc Optimisations de plan utilisateur au moyen d'une analyse de données de réseau
WO2023147032A1 (fr) * 2022-01-27 2023-08-03 Interdigital Patent Holdings, Inc. Surveillance et rapport de performance pour prendre en charge une opération aiml

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120254320A1 (en) * 2011-04-04 2012-10-04 Microsoft Corporation Distributing collected information to data consumers based on global user consent information
WO2022026482A1 (fr) * 2020-07-30 2022-02-03 Convida Wireless, Llc Optimisations de plan utilisateur au moyen d'une analyse de données de réseau
WO2023147032A1 (fr) * 2022-01-27 2023-08-03 Interdigital Patent Holdings, Inc. Surveillance et rapport de performance pour prendre en charge une opération aiml

Similar Documents

Publication Publication Date Title
CN111684824B (zh) 增强的nef功能、mec和5g集成
WO2018034924A1 (fr) Resélection de tranche de réseau
WO2018236830A1 (fr) Relocalisation de plan d'utilisateur
EP4470176A1 (fr) Surveillance et rapport de performance pour prendre en charge une opération aiml
US20250184857A1 (en) Route selection in a wireless communication system
WO2023147049A1 (fr) Connectivité d'un réseau personnel d'internet des objets
WO2023192303A1 (fr) Système et procédés pour prendre en charge un flux et un profil de qos auto-adaptatifs
WO2025096934A1 (fr) Procédés et appareil pour améliorer une structure d'apprentissage automatique d'intelligence artificielle (aiml) pour prendre en charge une collecte de données d'unité de transmission-réception sans fil (wtru)
US12301674B2 (en) Edge-cloud application context migration
WO2025175196A1 (fr) Procédé et appareil pour permettre un apprentissage fédéré vertical sur la base d'une interaction réseau avec une fonction d'application
WO2024233918A1 (fr) Support pour pcc dynamique avec sa prose
WO2024211765A1 (fr) Désenregistrement d'une wtru inactive d'une tranche de réseau ai/ml
WO2025208008A1 (fr) Association d'un utilisateur humain à un abonnement
WO2025213060A1 (fr) Gestion d'enregistrement pour dispositifs aiot derrière un nœud intermédiaire wtru
WO2025213073A1 (fr) Procédés d'activation et d'authentification d'identifiant d'utilisateur
WO2025160416A1 (fr) Procédés et appareil pour permettre un calcul d'aiml divisé dans des systèmes sans fil sur la base d'un chaînage de fonctions de service
WO2024177963A1 (fr) Procédés d'aide à la sélection d'un élément de wtru sur la base d'un consentement d'utilisateur par application
WO2024177919A1 (fr) Procédés d'autorisation ue/ac/eec dans des services de groupe fournis par eas commun à l'aide d'un serveur de groupe
WO2025075956A1 (fr) Procédés et appareil pour gérer une communication indirecte par l'intermédiaire de passerelles dans des réseaux personnels de l'internet des objets (ido)
WO2025175210A1 (fr) Association d'un utilisateur humain à un abonnement
WO2025240798A1 (fr) Mécanismes de gestion de transitions d'état d'utilisateur
WO2024177961A1 (fr) Procédés d'aide à la sélection d'un membre wtru sur la base d'un état de sécurité de plan utilisateur
WO2024211787A1 (fr) Autorisation de transfert de contexte de client activateur de peripherie (eec)
EP4548690A1 (fr) Retrait initié par wtru à partir d'une opération d'apprentissage fédéré
WO2024233906A1 (fr) Authentification secondaire de services de proximité à l'aide d'informations de dnn configurées localement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24809479

Country of ref document: EP

Kind code of ref document: A1