Method, device and system for analyzing quality of experience data of multiple wireless transmitting and receiving units

Abstract

Disclosed herein are methods, apparatuses, systems, and the like for analyzing quality of experience (QoE) data for multiple wireless transmit and receive units (WTRUs) in a 5G network. In an embodiment, a method may include receiving a request message requesting a quality of service (QoS) configuration associated with at least one WTRU involved in an application, for obtaining a target QoE for the application. The first method may further include transmitting the QoS configuration obtained based on the target QoE. In an embodiment, a method may include: transmitting a first request signal for subscribing to service data from an application; and receiving a first response signal, the first response signal including at least one identifier of at least one WTRU involved in the application, the first response signal including at least one indication of at least one individual contribution of the at least one WTRU to the QoE of the application.

Description

Background Art

[0001] The present disclosure relates to network communications, including but not limited to methods, devices, systems, etc. for performing network data analysis in 5G networks.

[0002] The Network Data Analysis Function (NWDAF) can interact with different entities for different purposes. For example, the NWDAF can collect data from various data-providing entities (such as network functions (NFs)) and provide analysis to consumer entities based on demand. The NWDAF can be considered a general mechanism for providing access to analytical services. The analytical information can be either statistical information about past events or predictive information for future periods. Summary of the Invention

[0003] Disclosed herein are methods, apparatuses, systems, and the like for analyzing quality of experience (QoE) data for (e.g., multiple) wireless transmit and receive units (WTRUs) in a 5G network. In an embodiment, a first method may include receiving a request message requesting a quality of service (QoS) configuration associated with at least one WTRU involved in an application, for obtaining a target QoE for the application. The first method may further include transmitting the QoS configuration obtained based on the target QoE. In an embodiment, a second method may include receiving a request signal for subscribing to service data from an application; and transmitting a response signal, the response signal including at least one identifier of at least one WTRU involved in the application, the response signal further including at least one indication of an individual contribution of the at least one WTRU to the QoE of the application. In an embodiment, a third method may include transmitting a first request signal for subscribing to service data from an application; and receiving a first response signal including at least one identifier of at least one WTRU involved in the application, the first response signal including at least one indication of at least one individual contribution of the at least one WTRU to the QoE of the application. The third method may include transmitting a second request signal for subscribing to network data from a network function, the network data associated with the at least one WTRU and the application. A third method may include receiving a second response signal including the network data related to the at least one WTRU and the application. Data analysis of the application (such as, for example, a QoE value) may be obtained based on the received first response message and the second response message.

[0004] Although various embodiments are described and / or claimed herein in which devices, systems, equipment, etc. and / or any elements thereof are configured to perform an operation, process, algorithm, function, etc. and / or any portion thereof, it should be understood that any embodiment described and / or claimed herein assumes that any device, system, device, etc. and / or any element thereof performs any operation, process, algorithm, function, etc. and / or any portion thereof (and vice versa). BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding can be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings. As with the detailed description, the figures in such drawings are examples. Therefore, the drawings and detailed description should not be considered limiting, and other equally effective examples are possible and contemplated. In addition, like reference numerals in the drawings indicate similar elements.

[0006] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0007] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0008] Figure 1C It is shown that according to one embodiment, Figure 1A a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) for use within the illustrated communication system;

[0009] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0010] Figure 2 is a diagram showing an example of message exchange for analytics subscription and data collection;

[0011] Figure 3 is a system diagram illustrating an example of application functionality running on a device;

[0012] Figure 4 is a diagram showing an example of a message exchange for monitoring information of a set of WTRUs;

[0013] Figure 5 is a diagram showing another example of a message exchange for monitoring information of a set of WTRUs;

[0014] Figure 6is a diagram showing an example of a message exchange for estimating QoE based on a WTRU (e.g., QoS) configuration;

[0015] Figure 7 is a diagram showing an example of a message exchange for obtaining a QoS configuration for a target QoE;

[0016] Figure 8 is a diagram showing an example of a message exchange for collecting WTRU input data for service experience analysis;

[0017] Figure 9 is a diagram showing an example of a method for obtaining a QoE value;

[0018] Figure 10 is a diagram illustrating an example of a method for obtaining a QoS configuration;

[0019] Figure 11 is a diagram illustrating an example of a method for obtaining data analysis. DETAILED DESCRIPTION

[0020] The detailed description of exemplary embodiments will now be described with reference to various drawings. Although this specification provides a detailed example of possible specific implementation, it should be noted that the details are intended to be exemplary and in no way limit the scope of this application. In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples can be put into practice without some or all of the specific details set forth herein. In other cases, well-known methods, procedures, components and circuits are not described in detail to avoid blurring the following description. In addition, embodiments and examples not specifically described herein can be put into practice in place of the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein, or put into practice in combination with these embodiments and examples.

[0021] Exemplary Communication Network

[0022] Figure 1Ais a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 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), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0023] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, 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 (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0024] The communication system 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 CNs 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNodeB, a Home NodeB, a Home eNodeB, a gNB, an 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.

[0025] Base station 114a may be part of RAN 104 / 113, 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, etc. Base station 114a and / or 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 cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input, multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0026] 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).

[0027] More specifically, as noted above, the communication 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. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may utilize Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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 UL Packet Access (HSUPA).

[0028] In one embodiment, 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).

[0029] In one embodiment, 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 New Radio (NR).

[0030] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface utilized by the 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., eNBs and gNBs).

[0031] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology 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), GSM Enhanced Data rates for Evolution (EDGE), GSM EDGE (GERAN), etc.

[0032] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, 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). In one embodiment, 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). In yet another embodiment, 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 a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0033] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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. Data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in Figure 1AAlthough not shown in the figures, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0034] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0035] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0036] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0037] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0038] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive RF and light signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0039] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in FIG. 1 , 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.

[0040] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals 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 to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0041] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an 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. Furthermore, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or 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. In other embodiments, 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).

[0042] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, 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, etc.

[0043] 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. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0044] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (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, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0045] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0046] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, 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 CN 106.

[0047] 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. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0048] Each of the eNodeBs 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 UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0049] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0050] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, 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 also 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.

[0051] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0053] The CN 106 may facilitate communications with other networks. For example, 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. For example, the CN 106 may include, or may be in communication 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. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0054] Even though the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communications interface with a communications network.

[0055] In a representative embodiment, the other network 112 may be a WLAN.

[0056] 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 to and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA can reach the AP and be delivered to the STA. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the destination. Traffic between STAs within the BSS can be sent through the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between the source and destination STAs (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0057] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0058] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a primary 20 MHz channel combined with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0059] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 80 MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be individually processed using an inverse fast Fourier transform (IFFT) and time domain processing. These streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0060] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0061] WLAN systems that support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum 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 (that supports the minimum bandwidth operating mode) from among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only) 1 MHz mode, the primary channel may be 1 MHz wide, 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, because a STA (that only supports 1 MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even if most of the frequency band remains idle and potentially available.

[0062] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0063] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 according to one embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0064] The RAN 113 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, 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. In one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0065] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. 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 the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).

[0066] 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 a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the eNode-Bs 160a, 160b, 160c. For example, the 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. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0067] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0068] Figure 1DThe illustrated CN 115 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 data networks (DNs) 185a, 185b. While each of the aforementioned elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0069] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via the N2 interface in the RAN 113 and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. The AMFs 182 a and 182 b may provide a control plane function for switching between the RAN 113 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.

[0070] The SMFs 183a and 183b may connect to the AMFs 182a and 182b in the CN 115 via the N11 interface. The SMFs 183a and 183b may also connect to the UPFs 184a and 184b in the CN 115 via the N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure traffic routing through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, and so on.

[0071] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface. These gNBs 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 UPFs 184a, 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 downlink packets, providing mobility anchoring, and the like.

[0072] The CN 115 may facilitate communications with other networks. For example, the CN 115 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 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local data networks (DNs) 185a, 185b.

[0073] Given that Figures 1A to 1D as well as Figures 1A to 1D As described herein, one or more or all of the functionality described herein for one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any one or more other devices described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0074] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, the one or more simulation devices can perform 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 simulation devices can perform one or more functions or all functions while being temporarily implemented or deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or can use over-the-air wireless communication to perform testing.

[0075] The one or more simulation devices can perform one or more (including all) functions without being implemented or deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0076] Examples of application functionality

[0077] A network (e.g., home, WLAN, LAN) may include multiple devices (e.g., with different capabilities), wirelessly connected, for example, via different access technologies, that collaborate to provide applications and services to users and / or devices in the (e.g., home, WLAN, LAN) network. The (e.g., home, WLAN, LAN) network may include any number of gateway devices that provide a multi-radio access technology (RAT) convergence point, thereby enabling either in-home local networking or in-home edge computing. The multi-RAT gateway device may enable the (e.g., home) network to integrate with external networks, applications, and services. The (e.g., home) network may be part of a 3rd Generation Partnership Project (3GPP) dedicated virtual network (e.g., per application vertical) for a residential setting and may be controlled by a 3GPP core network. In this context, some network functions (NFs) of the 3GPP core network (such as NWDAF) may be located on the (e.g., home) gateway device.

[0078] For example, an application function (AF) running on a (e.g., home) device may involve multiple WTRUs. For example, a virtual reality (VR) gaming device may interact with multiple cameras (e.g., for user positioning), one VR device per user, provided the device has (e.g., sufficient) processing power. In another example, an interactive teleconferencing system may involve interaction between display equipment, any number of positioning cameras, and the like. In these examples, these individual WTRUs (e.g., each of which) may contribute to improving the overall quality of experience (QoE) of the application.

[0079] The embodiments described herein may allow any of a (eg, home) gateway device and a set of points of access (PoAs) to determine which resources to allocate to which WTRUs to improve overall (eg, network, application) performance.

[0080] According to an embodiment, the network data analysis function (NWDAF) may be based on data provided by any of the access and mobility function (AMF), session management function (SMF), policy control function (PCF), unified data management (UDM), application function (AF) (e.g., directly or via the network exposure function (NEF)), and operation and maintenance (OAM). The NWDAF may provide access to analysis services, which may be either historical statistical information or future forecast information. Any of the 5G system network functions and OAM may use these analysis services to improve network performance.

[0081] According to an embodiment, a WTRU (e.g., any one of a game console, a tablet, a PC, and a smartphone) may run (e.g., execute) an application, such as, for example, any one of an immersive game, a teleconferencing application, and a monitoring system. Such an application may be referred to herein as an application function (AF). While executing the application, the WTRU may receive and process data from other (e.g., user) devices (e.g., any one of a WTRU, a sensor, and a camera). For example, the output of processing performed on, for example, a game console may generate data (e.g., a rendered video stream), which may be sent (e.g., transmitted) to another device (e.g., any one of a WTRU, a VR headset, and a smartphone).

[0082] According to an embodiment, a WTRU (such as, for example, a (e.g., home) gateway or any other device configured to manage a (e.g., home) network infrastructure) may receive a message from another WTRU (e.g., running an application as described above) containing metrics and measurements related to the QoE of the application. For example, these metrics may include any of the resolution of the rendered video stream, the accuracy (e.g., and confidence) of the user's location (e.g., within the home), and the (e.g., latency) time for sending the video portion to the other WTRU. According to an embodiment, the (e.g., home) gateway may host (e.g., run, execute), for example, a NWDAF that is configured to collect the metrics and obtain (e.g., determine, calculate / compute) predictions regarding these metrics. Examples of metrics obtained by the NWDAF may include an estimated service experience / QoE, which may be any of, for example, a mean opinion score (MOS), average resolution, average latency, etc.

[0083] The mean opinion score (MOS) can be considered a measure of QoE, representing the overall quality of a service or system experienced by an end-user. MOS can be used to measure the quality of (e.g., a wide range of) services (including any of video, audio, audiovisual, web browsing, and gaming). For example, MOS can be based on a panel of end-users, who subjectively rate their quality of experience of a service or system. MOS can be represented by a single rational number, for example, in a range of 1 to 5, where 1 is the lowest perceived quality and 5 is the highest perceived quality. MOS can be represented by any other numerical value, such as, for example, between 1 and 100. Based on subjective ratings (e.g., obtained from a panel of end-users), a set of low-level metrics (such as latency, jitter, CPU load, page load time, network throughput, video resolution, video encoding rate, number of resolution changes, audio encoding rate, gaming latency, etc.) can be mapped to a mean opinion score according to a model. MOS can be estimated (e.g., automatically) based on low-level metrics that may have been collected (e.g., measured) according to a model.

[0084] According to an embodiment, a (e.g., home) gateway may receive messages (e.g., data, packets) from network devices (e.g., routers, extenders) that may be connected to a local (e.g., home) network. These messages may include (e.g., network) metrics, such as any one of wireless signal strength, latency, and throughput. The network devices (e.g., routers, extenders) may run (e.g., execute) functions that may be referred to herein as network functions (NFs).

[0085] According to an embodiment, a network device (such as a router or extender) may run a NF configured to transmit a message (e.g., data, packet) to a (e.g., home) gateway, the message including a subscription request for the (e.g., estimated) QoE / service experience of a (e.g., given) application. These NFs (e.g., configured to request subscription to QoE metrics) may be referred to herein as "consumer NFs." According to an embodiment, the (e.g., home) gateway may transmit a message containing the (e.g., estimated) service experience to a subscribed network device (e.g., a subscribed metric). The network device may (e.g., decide) to change its behavior based on the metric / estimated service experience received from the (e.g., home) gateway. For example, a router may prioritize (increase priority) or de-prioritize (e.g., decrease priority) a traffic flow based on the received (e.g., QoE) metric. In another example, a router may route traffic through a specific interface or radio access technology based on the received (e.g., QoE) metric. In yet another example, a gaming console may send a message to a (e.g., home) gateway indicating, for example, poor QoE (e.g., poor user positioning). The (e.g., home) gateway may transmit the message containing the QoE metric (or any derived metric, such as either a mean or a median) to subscribed network devices, which may decide to change the priority of the gaming console's traffic. However, despite the change in traffic priority, the resulting QoE may not improve, for example, because the root cause of the QoE degradation may be a poor (e.g., poor, degraded) connection to one of the sensors or cameras.

[0086] According to an embodiment, the NWDAF can provide analytics (e.g., observed, measured, monitored) about the service experience of applications (e.g., VR games, teleconferencing applications). The NWDAF can collect service data (e.g., QoE) from the AF and network data (e.g., QoS) from the NF. Table 1 depicts the service data that can be collected from the AF (e.g., transmitted by the AF).

[0087]

[0088]

[0089] Table 1: Service data related to (e.g., observed) service experience .

[0090] According to an embodiment, network data (such as, for example, QoS flow-level network data) may be collected from (e.g., transmitted by) the NF. The network data may be associated with a QoS profile that is associated with a (e.g., specific) service, such as identified by, for example, an application identifier or IP filter information. The QoS profile may be, for example, a QoS class identifier (QCI) that may represent a QoS class. The QoS class may have any of a priority, a packet delay budget, and a packet loss rate. The QoS profile may also be associated with a QoS class that assigns a priority to traffic. For example, an IP filter may be, for example, a set of IP addresses or an IP address range that identifies a traffic flow (e.g., a protocol data unit (PDU) session) used by a service. The network data is depicted in Table 2.

[0091]

[0092] Table 2: Network data associated with the QoS profile assigned to a service (e.g., QoS flow level) .

[0093] According to an embodiment, network data related to the WTRU may be collected via the OAM protocol. Table 3 depicts network data related to the QoS profile.

[0094]

[0095] Table 3: WTRU-level OAM network data related to QoS profiles .

[0096] Figure 2 is a diagram showing an example of message exchange for analysis subscription and data collection. According to an embodiment, the NF may subscribe to the NWDAF by sending an analysis request / subscription message 21 to the NWDAF, for example, by calling the (analysis ID service = service experience, analysis filter information = (application ID, time window, single network slice selection assistance information (S-NSSAI), data network name (DNN), area of interest)) service. For example, the NF may transmit a message 21 (e.g., a packet) containing a request for analysis. The request for analysis may be referred to as a subscription to analysis in this document. The request for analysis may include first information indicating the type of requested analysis (e.g., analysis ID) that may be set as "service experience". The request for analysis may include second information that allows filtering / selecting metrics. The second information may include any of an application identifier, a time window, a session, and a network identifier, such as any of single network slice selection assistance information (S-NSSAI), a data network name (DNN), and an area of interest. The area of interest may be, for example, a list of any of wireless cells, access points (access points / points of access). A subscribed NF (eg, a NF that has subscribed to analytics) may be referred to herein as a NF consumer.

[0097] According to an embodiment, the NWDAF may collect data (e.g., data for which analysis has been requested) by, for example, transmitting a subscription message 221a to the AF to collect service data, and another subscription message 221b to any number of NFs to collect network data. According to an embodiment, service data may be collected by receiving a notification message 222a from the AF, and network data may be collected by receiving notification messages 222b from any number of NFs. The NWDAF may train 22c a QoE model based on the collected network and service data. The NWDAF may provide any of the observed service experience (e.g., average MOS), spatial validity conditions (e.g., indicating the locations where the estimated service experience may apply), and temporal validity conditions (e.g., indicating the times when the estimated service experience may apply) to the (e.g., consumer) NF. For example, the NWDAF may transmit a message 23 (e.g., a packet) to a subscribed NF (NF consumer), the message including metrics received from the AF and any other NFs. The message 23 transmitted by the NWDAF may include, for example, any of average MOS, average resolution, average latency, etc. The message 23 may include an indication of the area (eg, a list of cells or access points) to which the sent metric may apply. The message may include an indication of the time interval (eg, t0 to t1) to which the sent metric may apply.

[0098] Depending on the embodiment, a "request, transfer message / packet request" may correspond to any one of a request for a single response and a request (e.g., subscription) for a set of (e.g., continuous) updates. For example, a message may be sent (e.g., a response, a notification) if an updated metric or prediction may become available.

[0099] The mechanism for collecting QoE and network metrics for an AF can be designed for an AF associated with a single WTRU and can be adapted to AFs associated with multiple (e.g., any number of) WTRUs. For example, a virtual reality (VR) gaming AF can interact with multiple WTRUs (e.g., cameras) for positioning, one VR rig per user, and processing power for rendering. In another example, an interactive teleconferencing AF can interact with a display device, any number of positioning cameras, and so on. In yet another example, a vehicle-to-vehicle communication AF can interact with any number of sensors within a car, relaying on the road to communicate with nearby cars...

[0100] The embodiments described herein may allow a NWDAF that has sent a query to an AF for data analysis to identify WTRUs that the AF and the devices targeted in the query may rely on (e.g., may interact with, may exchange data with). While a consumer NF may query (e.g., send a request, an analysis subscription request to) specific devices or areas, the AF running in those devices may depend on contributions from WTRUs (e.g., services, applications running on the WTRUs) that are not indicated in the consumer NF query (such as, for example, sensors collecting information about a player's behavior in another house, or a WTRU connected to an AP that is not part of the request, such as a 3G / 4G / 5G base station). A query for a specific area (such as a specific house) may include other WTRUs (e.g., not related to the AF), such as a 5G-enabled microwave oven or an unused VR headset or sensor). The embodiments described herein may allow a NWDAF to identify WTRUs involved in a service provided by the AF and ignore other WTRUs not involved in the service.

[0101] Several WTRUs in the same location may be running the same type of AF (e.g., VR gaming), but contributing to the QoE of two independent services. For example, two children may be playing a VR game independently of each other on the same (e.g., home) network. The embodiments described herein may allow for the analysis of the two services to be managed independently of each other.

[0102] The embodiments described herein can be used, for example, for online VR gaming. A VR game can be rendered on a game console, which can obtain data about other players from the cloud. The game console can render and stream the game to the player's VR headset. The QoS of both the game console and the VR headset can affect the QoE. For example, latency, which is known to affect the QoE of a game, can be affected by the QoS of either the link between the console and the cloud or the link between the console and the headset. The embodiments described herein can allow the NWDAF to determine which of the two links may be the cause of QoE degradation.

[0103] The embodiments described herein may allow for dynamic updating of the list of WTRUs associated with an AF.

[0104]

[0066] The embodiments described herein may allow for associating (eg, correlating) QoS improvements with QoE improvements for a particular WTRU.

[0105] The embodiments described herein may allow for improved QoE for an AF involving multiple WTRUs by allowing for quantification of the individual contribution of the WTRUs (eg, each of the WTRUs) to the QoE.

[0106] The embodiments described herein may allow a (eg, home) network (eg, a gateway, or a set of PoAs in a home) to identify WTRUs to which resources should be allocated in order to achieve a target QoE for the AF.

[0107] The embodiments described herein may allow identification of WTRUs that can support (e.g., contribute resources to) an application without having to run (execute) the application. Examples of such WTRUs may include sensors, cameras, ...

[0108] The embodiments described herein may allow querying the NWDAF to estimate the impact of changes in network parameters on QoE.

[0109] Depending on the embodiment, operational QoE information may be exchanged with the AF involving any number of WTRUs. Operational here means that the exchange of QoE information between different entities (NEF, NWDAF, AF, NF) may result in operations (e.g., QoS policy changes) in the network. A set (e.g., group, list) of WTRUs (e.g., identifiers) may be associated with the AF. The set of WTRUs (e.g., identifiers) may be transmitted by the AF to the NWDAF. For example, the AF may transmit information indicating which WTRUs may participate (e.g., contribute) to an application to the NWDAF. The AF may transmit the identifiers of those WTRUs. The NWDAF may collect QoS data related to these WTRUs (associated with the AF). The AF may transmit information indicating the (e.g., individual) contribution (e.g., such as any of scores, weights) of the WTRUs to the QoE to the NWDAF. The contribution (e.g., any of scores, weights) may be obtained (determined, calculated) by the AF and transmitted by the AF to the NWDAF.

[0110] According to an embodiment, the NWDAF may be queried for information indicating how to update QoS parameters for the WTRU (e.g., receiving a packet requesting such information). For example, the NWDAF may be able to provide (e.g., transmit) QoS modifications to the WTRU to achieve the AF's (e.g., target) QoE. For example, the NF may provide (e.g., transmit) the application's (e.g., target) QoE to the NWDAF, and the NWDAF may respond (e.g., transmit back) the WTRU's configuration to the NF. For example, the WTRU's configuration may be a set of (WTRU ID, QoS parameter) pairs, where a pair includes a WTRU identifier and QoS parameters that the NWDAF recommends (e.g., determines) for the WTRU. For example, the NWDAF may be able to provide an estimate of the AF's QoE that would result from the recommended QoS modifications. For example, the NF may provide (transmit) the QoS configuration of the WTRU and any one of a set of WTRUs to the NWDAF (e.g., a set of (WTRU ID, QoS parameter) pairs), and the NWDAF may respond to the NF with the application's QoE (e.g., estimated QoE) based on the QoS configuration.

[0111] Figure 3 is a system diagram illustrating an example of a VR gaming application function 310 running on a gaming console device 31. The VR gaming AF 310 may be a multiplayer VR game involving two VR headsets 32 and 33, each worn by two different users in two different rooms. The VR game may involve a set of cameras 341, 342, 343, 344, 345, and 346, located in different rooms and configured to locate the users (e.g., headsets) in the different rooms. The AF function 310 may run (e.g., execute) in the gaming console device 31. The NWD AF function 350 may run (e.g., execute) in either the (e.g., home) gateway 35 or the (e.g., 5G core) network gateway. The NF function 351 may run (e.g., execute) in the (e.g., home) gateway 35 and may be configured to allocate resources (e.g., more bandwidth, higher QoS / priority) to the WTRU, which may negatively impact the QoE of the VR gaming application. The NF 351 may also be configured to release resources used by the WTRUs that may not (e.g., currently) affect the QoE of any application. In other (not shown) examples, the AF may run (e.g., execute) on any of the cameras, VR headsets, and set-top boxes. For example, the AF may run (e.g., execute) on each of the WTRUs involved in a multi-WTRU application (e.g., camera, VR headset, set-top box, etc.). The arrows show the message exchanges between the NF and the NWDAF, and between the NWDAF and the AF, respectively, via the NEF. Figures 4 to 7According to the embodiment, Figures 4 to 7 The illustrated multi-WTRU AF may be run on (e.g., a single WTRU) or any WTRU (e.g., each WTRU). For example, the NWDAF may receive service data related to different WTRUs from different WTRUs, where, for example, each WTRU running the AF may send service data related to that WTRU. In another example, the NWDAF may receive service data related to different WTRUs from a single network element (e.g., a WTRU), which may retrieve service data related to different WTRUs from different WTRUs, for example, at the application level.

[0112] This paper describes the implementation scheme based on four categories of features: (1) monitoring information from the set of WTRUs involved in the AF; (2) collecting information about the individual contributions of the WTRUs to the QoE; (3) estimating the QoE based on the QoS configuration; and (4) obtaining the QoS configuration for the target QoE.

[0113] Monitor information from a set of WTRUs

[0114] According to an embodiment, the NWDAF may obtain a set of identifiers of WTRUs involved in the AF. For example, the NWDAF may transmit a request to the AF to subscribe to AF analysis. The AF may transmit a response to the NWDAF including a set of identifiers of WTRUs involved in the AF (e.g., affecting the QoE of the AF). In a variation, the set of WTRUs involved in the AF may change, and the AF may transmit an update to the set of identifiers of the involved WTRUs. According to an embodiment, the NWDAF may transmit a request for WTRUs involved in the AF to obtain network information.

[0115] Figure 4 FIG2 is a diagram illustrating an example of a message exchange for monitoring information for a set of WTRUs involved in AF. The set of WTRUs involved in AF may include any of a camera used to locate a player in a VR / AR game, a VR headset, and the like.

[0116] According to an embodiment, a consumer NF (e.g., a device running a consumer NF) may send (e.g., transmit) a first request message 41 to a NWDAF (e.g., a device running an NWDAF) for subscribing to analytics, for example, by calling any of the Nwdaf_AnalyticsSubscription_Subscribe and Nwdaf_AnalyticsInfo_Request services. The first request message 41 may include first information indicating the type of requested analytics (e.g., analytics ID), which may be set as "service experience." The request for analytics may include second information that allows filtering / selecting metrics. The second information may include any of an application identifier, a time window, a session, and a network identifier, such as any of single network slice selection assistance information (S-NSSAI), a data network name (DNN), and a region of interest.

[0117] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may subscribe to service data from the AF by calling the Naf_EventExposure_Subscribe service (event ID = service data, event filter information = application ID, subscription target = any WTRU). The NWDAF may send (e.g., transmit) a second request message 42a for requesting subscription to analysis in the AF involving a set of WTRUs (e.g., any number of WTRUs). The second request message 42a may include first information indicating the type of subscribed event (e.g., event ID) which may be set as "service data". The AF (e.g., a device running the AF) may transmit, for example, a second response message 42b for confirming the subscription, or for notifying or sending new metrics to the NWDAF. According to an embodiment, the second response message 42b may include a set (e.g., a list) of identifiers of the WTRUs involved in the AF that have subscribed to the analysis. The set of identifiers included in the response message 42b may be referred to herein as a dependent WTRU ID list, as described in Table 4.

[0118]

[0119] Table 4: Service data from AF related to observed QoE for multiple WTRUs .

[0120] According to an embodiment, for each of the WTRUs listed by the AF (e.g., each of them), the NWDAF (e.g., a device running the NWDAF) may subscribe to any network data described in Table 2 from the NF by, for example, invoking the Nnf_EventExposure_Subscribe service. The NWDAF may send (e.g., transmit) a third request message 43a requesting a subscription to network data related to the WTRUs listed by the AF. The NWDAF may send (e.g., transmit) the third request message 43a to any number of NFs. The third request message 43a may include first information indicating the type of event subscribed to (e.g., event ID), which may be set to "5Q1_Statistics." The NF (e.g., a device running the NF) may transmit, for example, a third response message 43b to confirm the subscription or to notify or send new metrics to the NWDAF. According to an embodiment, the third response message 43b may include any network (e.g., QoS, statistics) data related to any of the WTRUs listed by the AF.

[0121] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may train 44 (e.g., offline or online) a data analysis (e.g., QoE, QoS) model for a given application, which may be used to determine (e.g., estimate, predict) data analysis (e.g., any one of the QoE of the application and the QoS configuration of the WTRU). According to an embodiment, in step 44, the data analysis (e.g., QoE of the application, QoS configuration of the WTRU) may be obtained based on the (QoE, QoS) model that has been trained (e.g., previously, offline) and any (e.g., network-related, service-related) metrics received in either the second response message 42b or the third response message 43b.

[0122] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may provide data analytics (e.g., observed service experience) to the consumer NF by means of either Nwdaf_AnalyticsSubscription_Notify or Nwdaf_AnalyticsInfo_Response. For example, the NDWAF may transmit a fourth message 45 indicating whether (e.g., used) QoS parameters meet the service MoS (e.g., agreed upon between the mobile network operator (MNO) and the end user or between the MNO and an external application service provider (ASP)). According to an embodiment, the fourth message may include (e.g., observed) service experience (e.g., average MOS), spatial validity conditions (e.g., indicating a location where the estimated service experience may apply), and temporal validity conditions (e.g., indicating a time when the estimated service experience may apply).

[0123] Figure 5 is a diagram showing another example of a message exchange for monitoring information of a set of WTRUs involved in AF. Figure 5 In the example of Figure 2 The first request message 2a and the second request message 2b described in.

[0124] According to an embodiment, in response to the second request message 52a, the AF (e.g., a device running the AF) may transmit, for example, a second response message 52b to confirm the subscription or to notify or send new metrics to the NWDAF. The second response message 52b may not include a set (e.g., a list) of identifiers of WTRUs involved in the AF that may have subscribed to the analysis. The set of WTRUs involved in the AF may be communicated to the NWDAF via (e.g., a separate) message exchange.

[0125] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may subscribe to a list of WTRUs involved in the AF by calling the Naf_EventExposure_Subscribe service (event ID = used WTRU, event filter information = application ID, subscription target = any WTRU). The NWDAF may transmit a (e.g., specific) request message 53a for requesting a subscription to a set of WTRUs involved in the AF. The (e.g., specific) request message 53a may include first information indicating the type of subscribed event (e.g., event ID) that may be set as "used WTRU". For example, the AF (e.g., a device running the AF) may transmit a (e.g., specific) response message 53b for confirming the subscription, or for notifying or sending a new or updated set (e.g., list) of identifiers of WTRUs involved in the NWDAF. According to an embodiment, the (e.g., specific) response message 53b may include a set (e.g., list) of identifiers of WTRUs involved in the AF that may have subscribed to the analysis. The set of identifiers included in the response message 53b may be referred to herein as a dependent WTRU ID list, as described in Table 5. According to an embodiment, in case the set of WTRUs involved in the AF changes, a (eg, specific) response message 53b may be transmitted to indicate the update of the set of WTRUs involved in the AF.

[0126]

[0127] Table 5: Example of data sent by the AF related to the WTRU involved in the AF .

[0128] According to an embodiment, the third request message 54a, the third response message 54b, the data analysis (eg, QoE, QoS) model (eg, training) 55, and the fourth message 56 may be similar to Figure 4 The third request message 43a, the third response message 43b, the data analysis (eg, QoE, QoS) model (eg, training) 44, and the fourth message 45 described in FIG. Figure 4 As described in, the fourth message 56 may include data analysis obtained on the (e.g., trained) model,

[0129] According to an embodiment, a (eg, dedicated) NWDAF may be used to track the set of WTRUs involved in the AF.

[0130] Collect information about the WTRU's individual contribution to QoE

[0131] According to an embodiment, the individual contribution of a WTRU to the QoE of an AF involving multiple WTRUs may be quantified as an individual metric. For example, the AF may provide (e.g., transmit) an individual metric to the NWDAF, where the individual metric may quantify the contribution of a single WTRU to the QoE of the AF involving multiple WTRUs. For example, the individual metric value may be obtained (e.g., calculated) by the AF and transmitted to the NWDAF. In another example, an individual metric related to the WTRU may be obtained (e.g., calculated) by a network element based on network data (e.g., any kind of QoS metric related to the WTRU). The network element may be a WTRU or a different network element. According to an embodiment, the network element (e.g., which may be calculating the individual metric) may or may not be running the AF. According to an embodiment, the network element may or may not be running the NWDAF.

[0132] For example, the individual metric values obtained by the AF for a WTRU may be associated with a (e.g., minimum) set of values for a set of (e.g., QoS, low-level) parameters / metrics for the WTRU that achieves a (e.g., minimum) QoE level for the AF. As previously described, the QoE may be, for example, a model-based MOS that maps a set of low-level parameters / metrics (such as latency, jitter, CPU load, page load time, network throughput, video resolution, video encoding rate, number of resolution changes, audio encoding rate, gaming latency, etc.) to a MOS. The MOS model may include parameters / metrics from any number of WTRUs. The AF may use the MOS model to calculate the MOS based on the set of low-level parameters / metrics. The AF may also use the MOS model to determine a set of values and parameters for the WTRU (e.g., each WTRU therein) that enable a MOS (e.g., greater than or equal to a given score). For example, this set of values and parameters may be defined, for example, during the specific implementation phase of an application, or learned during deployment, for example, via a machine learning algorithm.

[0133] In a first example, the individual metric value may be a Boolean value that indicates whether the WTRU's (eg, QoS, low-level) parameters / metrics may enable the AF to achieve the target level of QoE.

[0134] In a second example, the WTRU's individual metric value may be a percentage value (e.g., between 0 and 100) that indicates how close the WTRU's (e.g., QoS, low-level) parameters / metrics are to a set of values that would enable the AF to achieve a target level of QoE.

[0135] In a third example, the WTRU's individual metric values may be as shown in the second example, where a value greater than 100 may indicate that the WTRU's current (e.g., QoS, low-level) parameters / metrics may be better than the values that would enable the AF to achieve the target level of QoE.

[0136] In a fourth example, the WTRU's separate metric value may be the QoE that the AF would achieve if the WTRU had unlimited QoS / resources. In other words, if the WTRU did not have communication limitations and / or unlimited resources, the separate metric value may be the difference between the AF's (e.g., current) QoE and the AF's QoE.

[0137] In a fifth example, a separate metric value for the WTRU may be the QoE degradation that may occur if the WTRU disappears or loses communication.Any combination of the above examples may be applicable to the embodiments described herein.

[0138] According to an illustrative example, in a VR game AF involving two WTRUs (e.g., as headsets), latency may degrade the game's QoE. The impact of latency L can be quantified by a parameter function of latency, where the parameters of the parameter function may depend on the type of game. An example of such a parameter function may be given by the following equation:

[0139] f(L)=a / (1+exp(b–cL))–d

[0140] Where a, b, c, and d may be constants depending on the type of game being played. In this example, if two WTRUs are communicating via device-to-device communication, the latency L for the communication between the two devices may be the sum of the individual latency (e.g., L=L1+L2). The individual metric value for one of the WTRUs (e.g., WTRU(i)) may be, for example, the QoE that the AF would achieve if the WTRU had unlimited QoS (e.g., f(L)-f(L-Li)). The individual metric value for one of the WTRUs (e.g., WTRU(i)) may be the difference between the effect of the latency L and the effect of the latency of (e.g., only) the other WTRU in the device-to-device communication.

[0141] In another example, the individual metric value for a WTRU may be the derivative of an influence function with respect to a single delay of that WTRU.

[0142] Any method for obtaining a WTRU's individual impact on the global QoE relative to a given QoS parameter for that WTRU may be applicable to the embodiments described herein.

[0143] According to an embodiment, the individual metric values may be included in the service data information of the message response sent by the AF to the NDWAF via the NEF. Figure 4 , the individual metric values may be included in the Naf_EventExposure_Notify message 42b. The individual metric values may be included in the service data information as described in Table 6. Table 6 is a modified version of Table 4.

[0144]

[0145]

[0146] Table 6: Service data from AF related to observed QoE of multiple WTRUs, including individual WTRU contributions .

[0147] According to the embodiment, and for example with reference to Figure 5 , the individual metric values may be included in the Naf_EventExposure_Notify message 53b. As described in Table 7, the individual metric values may be included in the used data information. Table 7 is a modified version of Table 5.

[0148]

[0149] Table 7: Data from AF related to usage of WTRUs involved in AF, including individual WTRU contributions .

[0150] Depending on the embodiment, the information indicating the individual contribution of the WTRU may be transmitted as either of a single list of (WTRU identifier and individual metric value for that WTRU) pairs, where the two lists include the WTRU identifier and the corresponding individual metric value. Any encapsulation technique that allows the transmission of the individual contribution of the WTRU to the QoE may be applicable to the embodiments described herein.

[0151] Depending on the embodiment, information indicating the WTRU's individual contribution may be forwarded (eg, transmitted) or provided (eg, transmitted upon request) to any NF (such as a PCF).

[0152] Service experience analysis based on WTRU data

[0153] According to an embodiment, a (e.g., enriched, observed) service experience prediction may be provided by a NWDAF (e.g., a device running the NWDAF) based on input data collected from WTRUs involved in a multi-WTRU application. The input data may be either service data or network data. The service data may be collected from the AF. The network data may be collected from either the NF or the OAM.

[0154] For example, input data may be collected from the WTRU and may include any of a QoS metric associated with the WTRU and an individual contribution (e.g., metric) of the WTRU to the overall application service experience (e.g., the QoE of an AF involving multiple WTRUs).

[0155] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may receive a request for service experience analysis from, for example, a consumer NF (e.g., any of the OAM and PCF). For example, according to any embodiment described herein, the NWDAF (e.g., a device running the NWDAF) may obtain a list of identifiers of WTRUs involved in an application. The list (e.g., set, group) of WTRU IDs may be associated with the AF, for example.

[0156] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may obtain input data from the WTRUs (e.g., each WTRU) involved in a multi-WTRU application, for example, via an OAM service. According to any embodiment described herein, the WTRU input data may include individual contributions to QoE, for example, associated with any QoS metric. Table 8 describes an example of WTRU input data collected by the NWDAF. For example, the NWDAF (e.g., a device running the NWDAF) may be configured to call (e.g., use) any OAM service to retrieve management data that may be relevant to analysis generation. The OAM service may include a 3GPP OAM service or any other type of OAM service. For example, the NWDAF (e.g., a device running the NWDAF) may be configured to use OAM to collect input data related to (e.g., a single) WTRU via information retrieval based on minimization of drive tests (MDT). MDT may be considered a method that enables a WTRU to perform and report measurement results (e.g., network coverage). For example, the amount of data may be measured separately (e.g., independently) for DL and UL, for example, based on QoS. In another example, throughput may be measured separately (e.g., independently) for DL and UL based on radio access bearer. In yet another example, any of reference signal received power and reference signal received quality may be measured. In yet another example, packet delay measurement may be performed separately (e.g., independently) for DL and UL, for example, based on a QoS class identifier, etc. According to an embodiment, any QoS metric described herein may be reported (e.g., transmitted) by the WTRU to the NWDAF (e.g., a device running the NWDAF) via MDT-based information retrieval independently of its measurement results (e.g., by the WTRU).

[0157]

[0158]

[0159] Table 8: Example of WTRU input data

[0160] Figure 8 is a diagram showing an example of message exchange for collecting WTRU input data for service experience analysis (eg, prediction).

[0161] According to an embodiment, a consumer NF (e.g., a device running the consumer NF) may send (e.g., transmit) a subscription message 81 to an NWDAF (e.g., a device running the NWDAF) to subscribe to service experience analytics, for example, by calling either the Nwdaf_AnalyticsSubscription_Subscribe and Nwdaf_AnalyticsInfo_Request services. The subscription message 81 may include first information indicating the type of requested analytics (e.g., analytics ID), which may be set to "service experience." The subscription message 81 may include second information that allows filtering / selecting metrics. The second information may include either an application identifier (ID) and a time window representing a target period for the analysis. For example, the time window may be set to a future time period to obtain analytics predictions. In another example, the time window may be set to a past time period to obtain analytics statistics.

[0162] According to an embodiment, in step 82, the NWDAF (eg, a device running the NWDAF) may collect input data from (eg, each) individual WTRU involved in the AF based on, for example, MDT-based information retrieval.

[0163] According to an embodiment, in step 83, the NWDAF (e.g., a device running the NWDAF) may process the collected input data, for example, based on any of the embodiments described herein. For example, the NWDAF (e.g., a device running the NWDAF) may obtain a service experience prediction for a future time period based on the collected input data and a (e.g., trained) QoE model.

[0164] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may provide data analytics (e.g., predicted service experience) to the consumer NF via either Nwdaf_AnalyticsSubscription_Notify or Nwdaf_AnalyticsInfo_Response. For example, the NDWAF may transmit a notification message 84 indicating the predicted service experience of the application. Table 9 describes an example of parameters included in the notification message 84.

[0165] information describe Application ID Identify the application that provided this information Service Experience Observed Service Experience Prediction

[0166] Table 8: Example of WTRU input data

[0167] Depending on the embodiment, the service experience may include the type of service experience (e.g., any of voice, video, etc.), the service experience within the analysis target period (e.g., any of the average, variance), a list of identifiers of WTRUs involved in the application service experience (e.g., subscription permanent identifier (SUPI)), an estimated percentage of WTRUs with similar service experience, spatial validity (e.g., the area to which the estimated service experience may be applicable), a validity period, and any of a probabilistic assertion (e.g., indicating the confidence of the prediction).

[0168] According to an embodiment, the NF consumer function (e.g., a device running the NF consumer function) may subscribe to receive continuous reports of service experience analysis (e.g., via a subscription message 81). The NWDAF (e.g., a device running the NWDAF) may further receive WTRU input data 85 from (e.g., each) individual WTRU involved in the AF based on, for example, MDT-based information retrieval. In step 86, the NWDAF (e.g., a device running the NWDAF) may generate further analysis and may provide these analyses to the NF consumer function (e.g., a device running the NF consumer function) via a further notification message 87 (e.g., similar to the notification message 84 with updated parameter values).

[0169] Estimating QoE based on QoS configuration

[0170] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may collect information that can be used to improve the QoE of the AF. This information may be provided to the consumer NF (e.g., PCF), which may update (e.g., make) decisions to improve the QoE.

[0171] The embodiments described herein may also be applicable to AF involving a single WTRU.

[0172] Figure 6 is a diagram showing an example of a message exchange for estimating QoE based on a WTRU (eg, QoS) configuration.

[0173] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may be queried by the NF (e.g., receive a request from the NF) regarding (e.g., potential) modifications to the QoS (or any other parameter or combination of parameters) of the WTRU involved in the AF. The NWDAF (e.g., a device running the NWDAF) may reply with (e.g., transmit) a QoE estimate resulting from the modification.

[0174] According to an embodiment, a consumer NF (e.g., a device running a consumer NF) may send (e.g., transmit) a first request message 61 to a NWDAF (e.g., a device running an NWDAF) for requesting the WTRUs (a set of WTRUs) involved in the AF by, for example, calling any of the Nwdaf_AnalyticsSubscription_Subscribe and Nwdaf_AnalyticsInfo_Request services. For example, the service may be called as follows: (Analysis ID = "WTRU used by AF", Analysis Filter Information = (Application ID, Time Window, S-NSSAI, DNN, Region of Interest)). The first request message 61 may include first information indicating the type of requested analysis (Analysis ID), which may be set to "WTRU used by AF". The request for the involved WTRUs may include second information that allows filtering / selection parameters. The second information may include any of an application identifier, a time window, a session, and a network identifier, such as any of Single Network Slice Selection Assistance Information (S-NSSAI), a Data Network Name (DNN), and a Region of Interest. In step 615, the NWDAF (eg, a device running the NWDAF) may retrieve a list of WTRUs involved in the AF according to any of the embodiments described herein.

[0175] According to an embodiment, in response to the first request message 61, the NWDAF (e.g., a device running the NWDAF) may transmit a first response message 62 including an identifier of the WTRU (e.g., a set of identifiers) by invoking either the Nwdaf_AnalyticsSubscription_Notify and Nwdaf_AnalyticsInfo_Response services. The identifier of the WTRU (e.g., a set of identifiers) included in the first response message 62 may correspond to a set of WTRUs involved (e.g., estimated to be involved) in the AF during the time window requested by the NF.

[0176] According to an embodiment, a consumer NF (e.g., a device running a consumer NF) may send (e.g., transmit) a second request message 63 to a NWDAF (e.g., a device running an NWDAF) to request data analytics, for example, by invoking any of the Nwdaf_AnalyticsSubscription_Subscribe and Nwdaf_AnalyticsInfo_Request services. For example, the service may be invoked as follows: (Analysis ID = "Service Experience from QoS Estimation", Analysis Filter Information = (Application ID, Time Window, S-NSSAI, DNN, Region of Interest), QoS Update = (WTRU ID, [Recommended] QoS Value) List). The second request message 63 may include first information indicating the type of requested analytics (e.g., Analysis ID), which may be set to "Service Experience from QoS Estimation". The request for analytics may include second information allowing for filtering / selection parameters. The second information may include any of an application identifier, a time window, a session, and a network identifier, such as any of Single Network Slice Selection Assistance Information (S-NSSAI), a Data Network Name (DNN), and a Region of Interest. The request for analysis may include third information that allows for indicating the QoS configuration of the WTRU (e.g., a set of WTRUs) for which the estimated QoE may be requested. The QoS configuration may be transmitted as a WTRU ID (e.g., a set of WTRU IDs), where a set of values (e.g., low-level, QoS parameters) may be associated with a WTRU ID (e.g., each of which may be a WTRU ID). For example, the QoS parameters associated with the WTRU ID may be QoS values that the PCF may consider assigning to the WTRU.

[0177] According to an embodiment, in step 635, the NWDAF (eg, a device running the NWDAF) may obtain (eg, calculate) an estimated QoE value that is achievable if the received QoS configuration is applicable.

[0178] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may transmit a second response message 64 by invoking either the Nwdaf_AnalyticsSubscription_Notify and Nwdaf_AnalyticsInfo_Response services, the second response message including a QoE value (e.g., a range of QoE values) obtained (e.g., estimated) based on the received WTRU's QoS configuration. The second response message 64 may include information indicating, for example, the extent to which the proposed QoS configuration may be estimated to meet the QoE (e.g., as agreed upon between the MNO and the end user or between the MNO and an external ASP). For example, the information may indicate any of an estimated service experience (e.g., an average MOS), a spatial validity condition (e.g., a location where the estimated MOS may be applicable), and a temporal validity condition (e.g., a time when the estimated MOS may be applicable).

[0179] Get the QoS configuration for (e.g., target) QoE

[0180] Figure 7 FIG2 is a diagram illustrating an example message exchange for obtaining a QoS configuration based on a target QoE. For example, the NF may query the NWDAF (e.g., a device running the NWDAF) regarding the QoE that the AF may be targeting (e.g., receiving a request including the QoE). The NWDAF (e.g., a device running the NWDAF) may reply with the QoS (e.g., the recommended QoS) (or any other parameter or combination of parameters) for each of the WTRUs that may be involved in the AF (e.g., each of the WTRUs). The embodiments described herein may also be applicable to an AF involving a single WTRU.

[0181] According to an embodiment, a consumer NF (e.g., a device running a consumer NF) may send (e.g., transmit) a request message 71 to an NWDAF (e.g., a device running an NWDAF) to request data analysis, for example, by calling any of the Nwdaf_AnalyticsSubscription_Subscribe and Nwdaf_AnalyticsInfo_Request services. For example, the service may be called as follows: (Analysis ID = "QoS estimation from QoE", Analysis filter information = (Application ID, Time window, S-NSSAI, DNN, Region of interest), QoE). The first request message 71 may include first information indicating the type of analysis requested (Analysis ID), which may be set to "QoS estimation from QoE". The request for analysis may include second information allowing for filtering / selection parameters. The second information may include any of an application identifier, a time window, a session, and a network identifier, such as any of Single Network Slice Selection Assistance Information (S-NSSAI), a Data Network Name (DNN), and a Region of Interest. The request for analysis may include third information allowing for an indication of the QoE for which the QoS configuration may be requested (eg, a target range of QoE).

[0182] Depending on the embodiment, in step 715, the QoS configuration may be obtained based on the requested QoE (e.g., the target range QoE). For example, the QoS configuration may be obtained by requesting (e.g., invoking) a function based only on the QoE (e.g., the target range QoE). In another example, the QoS configuration may be obtained by requesting (e.g., invoking) a function based on the QoE (e.g., the target range QoE) and network data related to the WTRUs (e.g., the set of WTRUs) involved in the application. The network data may be received according to any embodiment described herein and may include any QoS metric according to any embodiment described herein. In yet another example, the QoS configuration may be obtained by requesting (e.g., invoking) a function based on the QoE (e.g., the target range QoE) and any individual contribution metric of any WTRU in the WTRUs (e.g., the set of WTRUs) involved in the application. The individual contribution metric may be included in the service data, which may be received according to any embodiment described herein.

[0183] According to an embodiment, the NWDAF (e.g., a device running the NWDAF) may transmit a response message 72 that includes the requested data analysis, such as, for example, the QoS configuration of the WTRUs (e.g., a set of WTRUs) that may be involved in the AF. The QoS configuration may enable the AF to achieve the requested QoE (e.g., a target range of QoE). The response message 72 may be transmitted by invoking either the Nwdaf_AnalyticsSubscription_Notify and Nwdaf_AnalyticsInfo_Response services. The QoS configuration may be transmitted as a WTRU ID (e.g., a set of WTRU IDs), where a set of (e.g., low-level, QoS parameter) values may be associated with a WTRU ID (e.g., each WTRU ID).

[0184] Depending on the implementation, the QoS configuration may include, for example, a value (e.g., a specific value) for any of the following parameters for the service: data volume (e.g., for DL and UL separately or for the whole); throughput (e.g., for DL and UL separately or for the whole), for example, according to any of the radio access bearer and UL radio network controllers; minimum expected signal quality (such as, for example, minimum expected RSRP, RSRQ); packet delay (e.g., for DL and UL separately or for the whole); packet loss rate (e.g., for DL and UL separately or for the whole); priority, etc. The QoS configuration may also include a QoS class identifier (QCI), which may indicate a QoS category. For example, a QoS category may have any of priority, packet delay budget, and packet loss rate, etc.

[0185] According to an embodiment, the function that may be requested (e.g., invoked, used) based on at least one QoE (e.g., a target range of QoE) may be any of a lookup table, an optimization algorithm, and a machine learning model. To determine the QoS configuration, the function may use input data that may be associated with the application in addition to the requested QoE (e.g., a target range of QoE). For example, according to any embodiment described herein, the input data may include any network data related to any WTRU involved in the application. For example, according to any embodiment described herein, the input data may include any individual contribution metrics for any WTRU involved in the application. For example, the input data may include any filter values provided in the request for data analysis, such as any of a time window, session and network identifiers, single network slice selection assistance information (S-NSSAI), a data network name (DNN), and an area of interest. The input data may include information about the WTRU involved in the application, such as, for example, location, DNN, s-NSSAI, IP filter information, QFI, number of packet transmissions and / or retransmissions, WTRU ID, WTRU type, owner ID, etc. The input data may include information about the AF, such as, for example, any of location, timestamp, application ID, current QoE, application type, etc.

[0186] In a first variation, the functionality that can be requested based on at least one QoE (e.g., a target range of QoE) can be a lookup table that can map QoE values (e.g., a range of QoE values) to QoS configurations (e.g., for each AF). For example, the lookup table can store (e.g., previous) QoS configurations that may have been allowed to achieve the QoE value (e.g., a range of QoE values) for a certain type of AF. For example, in addition to the QoE value, the lookup table can also associate (e.g., a given QoS configuration) with any additional network parameters related to the WTRUs involved in the application and / or any individual contributions to QoE that have been allowed to achieve the QoE value (e.g., a range of QoE values). For example, the lookup table can map any input data and QoE value (e.g., a range of QoE values) to a QoS configuration by WTRU type. The lookup table can be searched for an entry that is closest to (e.g., the input data) and the target QoE, and the corresponding QoS configuration for the WTRUs involved in the AF (e.g., each WTRU therein) can be retrieved, for example, based on the WTRU type. In the same example, several entries may be searched in the lookup table and the QoS configurations associated with these entries (e.g., all QoS configurations) may be retrieved. For example, the QoS configurations (e.g., returned) may be calculated by any of the following methods: averaging the retrieved QoS configurations, using the median value, counting QoS configurations with the same value (or by counting the values of the fields of the QoS configuration) and using the value that has the highest possible count, using the QoS configuration that is least different from the current QoS configuration of the WTRU involved in the AF. Any other aggregation techniques may be applicable to the embodiments described herein.

[0187] In a second variation, the functionality that can be requested based on at least one QoE (e.g., a target range of QoE) can be coupled to an optimization algorithm (e.g., any of an analytical model, a machine learning model) for obtaining a QoS configuration based on the QoE (e.g., and any additional input data as described herein). For example, the model can be Figure 6The model used in step 635 of the method described in , wherein the QoE may be calculated based on, for example, any of a QoS metric and a QoS configuration. An optimization algorithm may be used to obtain the QoS configuration of the WTRU (set of WTRUs) involved in the AF based on the model. For example, the optimization algorithm may be used to obtain any of the best QoS configuration (e.g., allowing the highest QoE to be achieved), a QoS configuration that meets the requested QoE, and a QoS configuration that meets the requested QoE and is closest to the current QoS configuration (e.g., one of the QoS configurations). For example, (e.g., any of an analytical model, a machine learning model) may be differentiable and a gradient descent algorithm may be performed to obtain the QoS that can achieve the requested QoE value. In another example, any of a genetic algorithm, a sampling-based method, a simulated annealing method may be used as an optimization algorithm coupled with a model that allows the determination of the QoE based on the QoS configuration.

[0188] In a third variation, the function that can be requested based on at least one QoE (e.g., a target QoE range) can be a machine learning model that maps (e.g., any input data and) a target QoE to a QoS configuration. The model may have been preliminarily trained (e.g., offline). The machine learning model can be based on any of a decision tree, a random forest, a learning regression, a boosting method, a bagging algorithm, a deep neural network, a support vector machine, a nearest neighbor, and the like.

[0189] According to an embodiment, the individual contribution metrics to QoE may be used to obtain a QoS configuration. For example, a NWDAF (e.g., a device running NWDAF) may obtain new QoS configurations for (e.g., only) WTRUs whose individual contributions may indicate that they may not meet a target level of QoE. For example, the NWDAF (e.g., a device running NWDAF) may use these individual contributions to sort the WTRUs by their individual contribution (or lack thereof) and may sequentially go through the WTRUs, thereby calculating a new QoS configuration for the WTRUs (e.g., each WTRU) until the requested QoE can be achieved. Any technique for determining a QoS configuration taking into account individual contributions to QoE may be applicable to the embodiments described herein.

[0190] According to an embodiment, the examples of Nwdaf_AnalyticsSubscription_Subscribe and Nwdaf_AnalyticsSubscription_Notify messages have been used to describe how to request (e.g., subscribe) and receive (e.g., be notified) data analytics, such as Figures 4 to 8 As shown. Figures 4 to 8Not explicitly shown, but according to any of the embodiments described herein, Nwdaf_AnalyticsInfo_Request and Nwdaf_AnalyticsInfo_response messages may be used to request and receive data analytics, respectively.

[0191] Examples of application functionality in a home network

[0192] This article will refer to Figures 3 to 7 An example of an AF in a home network is described. A network device (e.g., a router, an extender) may run a NF configured to transmit messages 41, 51, 61 (e.g., data, packets) to a (e.g., home) gateway, the message including a subscription request for (e.g., estimated) QoE / service experience for (e.g., a given) application. The subscription request may include a request for a list of WTRUs used by the (e.g., given) application.

[0193] A home gateway (e.g., a home gateway executing NWDAF) may send a message 42a, 52a to a game console (e.g., a game console running an application), the message including a subscription request for metrics related to the application. For example, upon receiving a subscription message 41 from a network device, the home gateway may send the message 42a, 52a to the game console.

[0194] The game console may transmit a message 42b, 53b to the home gateway containing metrics and measurements related to the QoE of the application. For example, these metrics may include any of the resolution of the rendered video stream, the accuracy and confidence of the user's location within the home, and the time (e.g., latency) used to send the video portion to other (e.g., end devices) WTRUs. For example, upon receiving a subscription message 42a, 52a from the home gateway, and / or when (e.g., new) application data may become available (e.g., updated), the game console may transmit a message 42b. Depending on the embodiment, the message 42b, 53b may include identifiers (a list of identifiers, a set of identifiers) of WTRUs that the application may know about and that may contribute to the application (e.g., all WTRUs). For example, this list may include identifiers (such as any of a MAC address, a subscription permanent identifier (SUPI)) of any sensors and cameras that may be sending data to the game console. This list may also include an identifier of the WTRU that is rendering the video stream generated by the game console.

[0195] Depending on the embodiment, for each WTRU identified in the list, the message 42b, 53b may include a number indicating the impact of the WTRU on the QoE according to the application. For example, the number may be a Boolean value indicating whether the WTRU can (e.g., completely) meet the target set by the application, or a percentage between 0 and 100 indicating how close the WTRU is to (e.g., completely) meeting the target set by the application.

[0196] The home gateway may transmit a message 43a, 54a to a network device (e.g., a router, an extender) containing a subscription request for metrics related to the application. Depending on the embodiment, the message 43a, 54a may include identifiers (e.g., a list of identifiers, a set of identifiers) of WTRUs (e.g., all WTRUs). For example, this list may be the same as the list transmitted by the game console, or may be derived from the list (e.g., a subset or an intersection with another list). Depending on the embodiment, the network device may transmit a message containing metrics (e.g., any of signal strength, throughput, latency, etc.) of (e.g., a particular) WTRU to the home gateway, for example, upon receiving a subscription message 43a, 54a from the home gateway, and / or when new data / metrics related to the WTRUs in the list may become available.

[0197] The home gateway may obtain 44, 55 (determine, calculate) any of a service experience, a QoE score based on any of the messages and metrics received from the gaming console and the network device.

[0198] After sending the subscription request messages 41, 51, 62, the home gateway may transmit messages 45, 56, 61 to the network device. The transmitted messages 45, 56 may include the service experience obtained. Depending on the embodiment, these messages 42b, 43a, 43b, 45, 53b, 54a, 54b, 55, 56, 62 may include identifiers (a list of identifiers, a set of identifiers) of WTRUs that the application may know and that may contribute to the application (e.g., all WTRUs).

[0199] The network device may transmit a message 63 to the home gateway, the message including the QoS (e.g., recommended QoS) (e.g., any of traffic bandwidth allocation, flow priority, etc.) of the WTRU (e.g., one of the WTRUs) in the previously received WTRU list. If the QoS (e.g., recommended QoS) is used, the home gateway may respond with a message including the QoE that can be obtained for the application.

[0200] The network equipment may send a message 71 to the home gateway containing the (e.g., target) QoE. The home gateway may respond with a message 72 containing a QoS configuration (e.g., a list of (QoS recommendation parameters, WTRU identifiers)) that enables the AF to achieve the (e.g., target) QoE.

[0201] Figure 9 is a diagram illustrating an example of a method 900 for obtaining a QoE value. According to an embodiment, in step 910, a first request signal may be transmitted for subscribing to service data of an application (e.g., related to the application). In step 920, a first response signal may be received. The first response signal may include at least one identifier of at least one WTRU involved in the application. The first response signal may further include at least one indication of at least one individual contribution of at least one WTRU to the QoE of the application. According to an embodiment, in step 930, a second request signal may be transmitted for subscribing to network data from a network function. For example, the network data may be related to at least one WTRU and, for example, related to the application. According to an embodiment, in step 940, a QoE value for the application may be obtained based on the received first response message and the second response message.

[0202] According to an embodiment, a QoE model may be trained based on the received first response message and the second response message.

[0203] According to an embodiment, a third request signal may be received for estimating a QoE value for the application. For example, the third request signal may include a QoS configuration, and the QoE value estimation may be requested based on the QoS configuration. According to an embodiment, a third response signal may be transmitted. The third response signal may include a QoE value obtained based on the QoS configuration, the received first response message, and the received second response message.

[0204] According to an embodiment, a fourth request signal requesting a QoS configuration may be received. The fourth request signal may include a target QoE value, and the QoS configuration may be requested based on the target QoE value. The requested QoS configuration may allow the target QoE to be achieved. According to an embodiment, the QoS configuration may be obtained based on the target QoE value, the received first response message, and the received second response message. A fourth response signal may be transmitted, the fourth response signal including the obtained QoS configuration.

[0205] Figure 10FIG1 is a diagram illustrating an example of a method 1000 for obtaining a QoS configuration. According to an embodiment, at step 1010, a request message may be received. The request message may request a QoS configuration associated with at least one WTRU involved in an application to obtain a target QoE for the application. According to an embodiment, at step 1020, the QoS configuration may be obtained based on the target QoE. For example, the QoS configuration may be transmitted in response to the request message.

[0206] Depending on the embodiment, multiple WTRUs may be involved in the application.The obtained QoS configuration may be associated with multiple WTRUs (eg, any one of the multiple WTRUs).

[0207] Depending on the implementation, a subscribe message may have been transmitted for subscribing to service data related to the application, eg before obtaining the QoS configuration.

[0208] According to an embodiment, a subscription response message may be received, for example, in response to a subscription message and before obtaining a QoS configuration, for example, the subscription response message including a plurality of identifiers corresponding to a plurality of WTRUs involved in the application.

[0209] According to an embodiment, network data associated with a plurality of WTRUs may be received. For example, a QoS configuration may be further obtained (eg, calculated) based on the received network data.

[0210] According to an embodiment, service data related to an application may be received, for example, before obtaining a QoS configuration. The service data may include a WTRU's individual contribution metric to the QoE of the application. The WTRU's individual contribution metric may quantify the WTRU's individual contribution to the QoE. For example, the QoS configuration may be further obtained based on the WTRU's individual contribution metric.

[0211] According to an embodiment, a separate contribution metric for the WTRU may be received from a network element different from the WTRU.The network element may be executing an application function associated with the application.

[0212] According to an embodiment, an individual contribution metric of the WTRU may be received from the WTRU.

[0213] Depending on the embodiment, the network data related to the WTRU may include any QoS metrics related to the WTRU, which may be received from the WTRU, for example.

[0214] Figure 11is a diagram illustrating an example of a method 1100 for obtaining data analytics. According to an embodiment, in step 1110, a (e.g., subscribe, request) message may be transmitted for subscribing to service data associated with an application. According to an embodiment, in step 1120, a (e.g., subscribe) response message may be received, the response message identifying a plurality of WTRUs involved in the application. According to an embodiment, in step 1130, network data associated with the WTRU may be received. According to an embodiment, in step 1140, service data associated with the application may be received. The service data may include an individual contribution metric of the WTRU to the QoE of the application, wherein the individual contribution metric of the WTRU may quantify the individual contribution of the WTRU to the QoE. According to an embodiment, in step 1150, data analytics associated with the application may be transmitted. The data analytics may be obtained based on, for example, the network data associated with the WTRU and the individual contribution metric of the WTRU.

[0215] According to an embodiment, a separate contribution metric for a WTRU may be received from a network element other than the WTRU. For example, the network element may be executing an application function associated with the application.

[0216] According to an embodiment, an individual contribution metric for a WTRU may be received from the WTRU.

[0217] Depending on the embodiment, the network data related to the WTRU may include any QoS metrics related to the WTRU, which may be received from the WTRU, for example.

[0218] According to an embodiment, any of the WTRU-related QoS metrics and the WTRU's individual contribution metrics may be received from the WTRU via minimization of drive tests (MDT) based information retrieval.

[0219] Depending on the embodiment, the QoE model may be applied to either the network data and the individual contribution metrics to obtain data analysis.

[0220] According to an embodiment, the data analysis may include a QoE value for an application. According to an embodiment, the data analysis may include a WTRU's QoS configuration, which indicates how the WTRU is configured to achieve a target QoE value for the application. For example, the QoS configuration may be obtained based on the target QoE value.

[0221] According to an embodiment, the target QoE value may be received from a requesting network element.

[0222] in conclusion

[0223] Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0224] Although not explicitly described, embodiments of the present invention may be employed in any combination or subcombination. For example, the present principles are not limited to the variations described, and any arrangement of variations and embodiments may be used. Furthermore, the present principles are not limited to the channel access methods described, and any other type of channel access method is compatible with the present principles.

[0225] Furthermore, any features, variations, or embodiments described with respect to the method are compatible with an apparatus comprising an apparatus for processing the disclosed method, with an apparatus comprising a processor configured to process the disclosed method, with a computer program product comprising program code instructions, and with a non-transitory computer-readable storage medium storing program instructions.

[0226] Although features and elements are described above in particular combinations, it will be understood by one of ordinary skill in the art that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0227] In addition, in the above-mentioned embodiments, processing platforms, computing systems, controllers and other devices containing processors are pointed out. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be considered to be "performed," "computer-executed," or "CPU-executed."

[0228] Those skilled in the art will appreciate that the actions and symbolic representations of operations or instructions comprise manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation or reduction of the electrical signal and the retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and performing other signal processing. The memory location that retains the data bits is a physical location having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the representative embodiments are not limited to the aforementioned platforms or CPUs, and that other platforms and CPUs may also support the provided methods.

[0229] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage systems readable by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside solely on the processing system or distributed across multiple interconnected processing systems that may be local or remote relative to the processing system. It should be understood that the representative embodiments are not limited to the aforementioned memories, and that other platforms and memories may also support the described methods.

[0230] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0231] There is little distinction between hardware implementations and software implementations of various aspects of the system. The use of hardware or software is typically (e.g., but not always, because in certain contexts, the choice between hardware and software may become important) a design choice that represents a trade-off between cost and efficiency. There may be various media (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary with the context of the deployment process and / or system and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may select a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may select an implementation that is primarily software. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0232] The foregoing detailed description has set forth various embodiments of devices and / or processes through the use of block diagrams, flow charts, and / or examples. Where such block diagrams, flow charts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts, or examples may be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC), and / or state machines.

[0233] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended to be illustrations of various aspects. Many modifications and variations can be made without departing from the spirit and scope of the present invention, as they will be obvious to those skilled in the art. Unless explicitly provided as such, any element, action or description used in this application specification should not be understood as being essential or necessary to the present invention. Based on the foregoing description, functionally equivalent methods and devices within the scope of the present disclosure, in addition to those listed herein, will be obvious to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full range of equivalents to such entitled claims. It should be understood that the present disclosure is not limited to a specific method or system.

[0234] It should also be understood that the terminology used herein is for the purpose of describing specific embodiments only and is not intended to be limiting. As used herein, the term "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE", when referred to herein, may mean: (i) a wireless transmit and / or receive unit (WTRU), such as described below; (ii) any of several embodiments of a WTRU, such as described below; (iii) a device with wireless functionality and / or with wired functionality (e.g., tetherable) configured with (in particular) some or all of the structure and functionality of a WTRU, such as described below; (iii) a device with wireless functionality and / or with wired functionality configured with less than all of the structure and functionality of a WTRU, such as described below; or (iv), etc. The following relative to Figures 1A to 1D Details are provided for an exemplary WTRU that may represent any of the UEs described herein.

[0235] In certain representative embodiments, several portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in whole or in part in an integrated circuit as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuits and / or writing code for the software and / or firmware will be well within the skill of those skilled in the art in light of the present disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as program products in a variety of forms, and that the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0236] The subject matter described herein sometimes shows different components contained within or connected to different other components. It should be understood that the architectures depicted in this type are merely examples, and in fact many other architectures that achieve the same function can be implemented. In a conceptual sense, any arrangement of components that achieve the same function is effectively "associated" so that the desired function can be achieved. Therefore, any two components combined herein to achieve a specific function can be considered to be "associated" with each other so that the desired function is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired function, and any two components that can be so associated can also be considered to be "operably couplable" to each other to achieve the desired function. Specific examples of operably couplable include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or wirelessly interact and / or components that can logically interact and / or components that can logically interact.

[0237] With respect to substantially any plural and / or singular terms used herein, those skilled in the art may convert from the plural to the singular and / or from the singular to the plural, as appropriate, depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0238] It will be understood by those skilled in the art that, in general, terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), are generally intended to be “open-ended” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “comprising” should be interpreted as “including but not limited to,” etc.). It will also be understood by those skilled in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitations, no such intent is present. For example, where only one item is intended, the term “single” or similar language may be used. To aid understanding, the following appended claims and / or the description herein may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that any particular claim containing such introduced claim recitation is limited to embodiments containing only one such recitation by the indefinite article “a” or “an” to introduce the claim recitation. This is true even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations).

[0239] In addition, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such constructions are intended to be understood by those skilled in the art (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having A alone, B alone, C alone, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such constructions are intended to be understood by those skilled in the art (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having A alone, B alone, C alone, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). Those skilled in the art will also understand that, in fact, any discrete words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one, either, or both of the terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" followed by a listing of a plurality of items and / or a plurality of categories of items is intended to include "any of," "any combination," "any multiples," and / or "any combination of multiples" of the items and / or categories of items, alone or in combination with other items and / or other categories of items. Additionally, as used herein, the terms "group" or "grouping" are intended to include any number of items, including zero. Additionally, as used herein, the term "quantity" is intended to include any quantity, including zero.

[0240] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also described in terms of any individual member or subgroup of members of the Markush group.

[0241] As will be understood by those skilled in the art, for any and all purposes (such as for providing a written description), all ranges disclosed herein also encompass any and all possible subranges and combinations of their subranges. Any listed range can be readily identified as fully describing and enabling the same range to be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all language such as "up to," "at least," "greater than," "less than," etc. includes the referenced numerals and refers to ranges that can subsequently be divided into subranges as described above. Finally, as will be understood by those skilled in the art, ranges include each individual numeral. Thus, for example, a group having 1 to 3 units refers to groups having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to groups having 1, 2, 3, 4, or 5 units, etc.

[0242] Furthermore, the claims should not be read as limited to the order or elements presented unless otherwise stated. Additionally, the use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, 6 or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

[0243] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or any host. The WTRU may be used in conjunction with a module and may be implemented in hardware and / or software including: a software defined radio (SDR) and other components such as a camera, a video camera module, a video phone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0244] Although the present invention has been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0245] Furthermore, while the invention has been shown and described herein with reference to specific embodiments, it is not intended that the invention be limited to the details shown. Rather, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention.

Claims

1. A method implemented in a first network element, the method comprising: A transmission request message for subscribing to receive service experience data related to an application, wherein the application involves multiple wireless transmit and receive units (WTRUs); receiving the service experience data associated with the application, the service experience data comprising first information indicating individual contribution metrics of a plurality of WTRUs to a global quality of experience (QoE) of the application, wherein the individual contribution metrics of the plurality of WTRUs comprise service experience contribution weights of the plurality of WTRUs to the global QoE of the application; determining, based on the first information, data analytics associated with the application; as well as The data analytics associated with the application are transmitted.

2. The method of claim 1 , wherein the WTRU's individual contribution metric represents the WTRU's individual contribution to the global QoE. 3 . The method of claim 1 , wherein the global QoE of the application comprises a mean opinion score of the application.

4. The method of claim 2, wherein the first information comprises an information element indicating the individual contribution metric of the WTRU, and wherein the information element is received from the WTRU or from a second network element different from the WTRU.

5. The method of claim 1, wherein the first information indicates the plurality of WTRUs involved in the application.

6. The method according to claim 1, further comprising: A first request message is received from a consumer network function prior to transmitting the request message, wherein the first request message indicates a type of requested analysis set as a service experience.

7. The method of claim 6, wherein the first request message indicates any one of an application identifier and single network slice selection assistance information (S-NSSAI).

8. The method of claim 1 , wherein transmitting the request message comprises: The request message is transmitted to the application function directly or via the network exposure function.

9. The method according to claim 1, wherein receiving the service experience data comprises: The service experience data is received from the application function directly or via a network exposure function.

10. The method of claim 1, wherein the data analysis includes a QoE value of the application.

11. A device comprising a circuit, the device comprising any one of a transmitter, a receiver, a processor, and a memory, configured to: A transmission request message for subscribing to receive service experience data related to an application, wherein the application involves multiple wireless transmit and receive units (WTRUs); receiving the service experience data associated with the application, the service experience data comprising first information indicating individual contribution metrics of a plurality of WTRUs to a global quality of experience (QoE) of the application, wherein the individual contribution metrics of the plurality of WTRUs comprise service experience contribution weights of the plurality of WTRUs to the global QoE of the application; determining, based on the first information, data analytics associated with the application; as well as Transmitting analytical data associated with said application.

12. The apparatus of claim 11, wherein the individual contribution metric of a WTRU represents the individual contribution of the WTRU to the global QoE.

13. The apparatus of claim 11, wherein the global QoE of the application comprises a mean opinion score of the application.

14. The apparatus of claim 12, wherein the first information comprises an information element indicating the individual contribution metric of the WTRU, and wherein the apparatus is configured to receive the information element from the WTRU or from a second network element different from the WTRU.

15. The apparatus of claim 11, wherein the first information indicates the plurality of WTRUs involved in the application. 16 . The apparatus of claim 11 , further configured to receive a first request message from a consumer network function before transmitting the request message, wherein the first request message indicates a type of requested analysis set as a service experience.

17. The apparatus of claim 16, wherein the first request message indicates any one of an application identifier and single network slice selection assistance information (S-NSSAI).

18. The apparatus according to claim 11, wherein being configured to transmit service experience data related to an application for subscription reception comprises: The system is configured to transmit the request message to the application function directly or via the network exposure function.

19. The apparatus according to claim 11, wherein being configured to receive the service experience data comprises: The system is configured to receive the service experience data from the application function directly or via the network exposure function.

20. The apparatus of claim 11, wherein the data analysis comprises a QoE value of the application.

Images