Method, apparatus and system for quality of experience data analysis for multiple wireless transmit and receive units

Abstract

Methods, apparatuses, systems, etc. for quality of experience (QoE) data analysis for multiple wireless transmit and receive units (WTRUs) in a 5G network are disclosed herein. In an embodiment, a method may include receiving a request message requesting a Quality of Service (QoS) configuration related to 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 may include at least one indication of at least one individual contribution of the at least one WTRU to the QoE of the application.

Description

[0001] This application is a divisional application of patent application No. 202080075580.4, filed on September 25, 2020, entitled "Method, Apparatus and System for Analyzing Experience Quality Data for Multiple Wireless Transmitting and Receiving Units". Background Technology

[0002] This disclosure relates to network communications, including but not limited to methods, apparatus, and systems for performing network data analysis in 5G networks.

[0003] Network Data Analytics Functions (NWDAFs) can interact with different entities for various purposes. For example, an NWDAF can collect data from various data-providing entities (such as network functions (NFs)) and provide analytics to consumer entities as needed. An NWDAF can be viewed as a general mechanism for providing access to analytics services. The analytics information can be either statistical information about past events or predictive information for future periods. Summary of the Invention

[0004] This document discloses methods, apparatus, systems, etc., for Quality of Experience (QoE) data analysis of (e.g., multiple) Radio Transmit and Receive Units (WTRUs) in a 5G network. In one 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 another embodiment, a second method may include: receiving a request signal for subscribing to service data from an application; and transmitting a 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 a separate contribution of the at least one WTRU to the QoE of the application. In yet another 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 a separate 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 being associated with the at least one WTRU and the application. The third method may include receiving a second response signal, which includes 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 and second response messages.

[0005] While various embodiments are described and / or claimed herein, wherein apparatus, systems, devices, etc. and / or any element thereof are configured to perform operations, processes, algorithms, functions, etc. and / or any part thereof, it should be understood that any embodiment described herein and / or protected by the claims assumes that any apparatus, system, device, etc. and / or any element thereof performs any operation, process, algorithm, function, etc. and / or any part thereof (and vice versa). Attached Figure Description

[0006] A more detailed understanding can be obtained from the following description, taken in conjunction with the accompanying drawings, by way of example. As with the detailed description, the figures in these drawings are illustrative. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and contemplated. Furthermore, similar reference numerals in the drawings indicate similar elements.

[0007] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments;

[0008] Figure 1B This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0009] Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0010] Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0011] Figure 2 This is a diagram illustrating an example of message exchange used for analyzing subscriptions and data collection;

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

[0013] Figure 4 This is a diagram illustrating an example of message exchange used to monitor information from a set of WTRUs;

[0014] Figure 5 This is an illustration of another example of message exchange used to monitor information from a set of WTRUs;

[0015] Figure 6This is an illustration of an example of message switching for WTRU-based (e.g., QoS) configuration estimation of QoE;

[0016] Figure 7 This is a diagram illustrating an example of message exchange used to obtain the QoS configuration for a target QoE;

[0017] Figure 8 This is an illustration of an example of message exchange used to collect WTRU input data for service experience analysis;

[0018] Figure 9 This is an illustration showing an example of a method for obtaining QoE values;

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

[0020] Figure 11 This is a diagram illustrating an example of a method used to obtain data for analysis. Detailed Implementation

[0021] A detailed description of exemplary embodiments will now be described with reference to the various accompanying drawings. While this specification provides detailed examples of possible specific implementations, 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, numerous 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 may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively, “provided”) herein.

[0022] Exemplary communication network

[0023] Figure 1AThis is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, 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 Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0024] 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, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. As examples, WTRUs 102a, 102b, 102c, and 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), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0025] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node Bs, evolved Node Bs, home Node Bs, home evolved Node Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0026] 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 base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio 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 coverage of radio services to a specific geographic area, which may be relatively fixed or changeable 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, i.e., one transceiver 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 desired spatial directions.

[0027] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0028] 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, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 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).

[0029] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0030] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0031] In one implementation, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can 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).

[0032] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0033] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN106 / 115.

[0034] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0035] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0037] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving 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 peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the implementation.

[0038] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0040] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0041] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0042] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. 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. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0043] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0044] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0045] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0046] WTRU 102 may include a full-duplex radio for which the 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 through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a full-duplex radio for which the 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.

[0047] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0048] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0049] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0050] Figure 1C The CN 106 shown 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.

[0051] The MME 162 can connect to each of the evolved nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0052] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0053] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0054] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0055] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0056] In a representative implementation, the other network 112 may be a WLAN.

[0057] A WLAN in Basic Services 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 carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via 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 source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0058] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0059] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0060] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels, and data can be transmitted via 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 Media Access Control (MAC).

[0061] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0062] WLAN systems supporting multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

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

[0064] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one implementation scheme. As noted above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0065] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to 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 implementation, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0066] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0067] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as eNode-B160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0068] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0069] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing 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.

[0070] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c via the N2 interface in RAN 113 and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 182a and 182b can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies, such as WiFi.

[0071] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can 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 can be IP-based, non-IP-based, Ethernet-based, etc.

[0072] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184a and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0073] CN 115 may facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or may communicate with such an IP gateway. Additionally, CN 115 may provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local data networks (DNs) 185a and 185b.

[0074] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the following functions, which may be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any one or more other devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0076] The one or more simulation devices may 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 devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0077] Examples of application functions

[0078] A network (e.g., home, WLAN, LAN) may include multiple devices (e.g., with different capabilities) wirelessly connected, for example, via different access technologies, to cooperate in providing applications and services to users and / or devices within the network. A network (e.g., home, WLAN, LAN) may include any number of gateway devices providing multiple radio access technologies (RAT) convergence points, enabling either in-home local networking or in-home edge computing. Multiple RAT gateway devices enable the network (e.g., home) to integrate with external networks, applications, and services. The network (e.g., home) may be part of a 3GPP dedicated virtual network (e.g., per-application vertical) for residential settings and may be controlled by the 3GPP core network. In this context, some network functions (NFs) of the 3GPP core network (such as NWDAF) may reside on the gateway device (e.g., home).

[0079] For example, an application function (AF) running on a device (e.g., a home device) may involve multiple WTRUs. For instance, a virtual reality (VR) gaming device may interact with multiple cameras (e.g., for user positioning), with one VR headset per user, and 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, etc. In these examples, these individual WTRUs (e.g., each of these WTRUs) can contribute to improving the application's global quality of experience (QoE).

[0080] The implementation described herein allows either (e.g., home) gateway devices and a set of access points (PoA) to determine which resources to allocate to which WTRUs to improve overall (e.g., network, application) performance.

[0081] According to the implementation plan, the Network Data Analytics Function (NWDAF) can be based on data provided, for example, through any of the Access and Mobility Functions (AMF), Session Management Functions (SMF), Policy Control Functions (PCF), Unified Data Management (UDM), Application Functions (AF) (e.g., directly or via Network Exposure Functions (NEF)), and Operation and Maintenance (OAM). NWDAF can provide access to analytics services, which can be either past statistics or future forecasts. Any of the 5G system network functions and OAM can use these analytics services to improve network performance.

[0082] According to the implementation scheme, the WTRU (e.g., any of a game console, tablet, PC, and smartphone) can run (e.g., execute) applications, such as any of immersive games, teleconferencing applications, and monitoring systems. This application may be referred to herein as an application function (AF). While executing the application, the WTRU can receive and process data from other (e.g., user) devices (such as the WTRU, sensors, cameras, etc.). For example, the output of processing performed on, for example, a game console can generate data (such as, for example, a rendered video stream), which can be sent (e.g., transmitted) to another device (such as the WTRU, VR headset, or smartphone).

[0083] According to the implementation, a WTRU (such as, for example, a home gateway or any other device configured to manage, for example, a home network infrastructure) can receive messages containing metrics and measurement results related to the application's QoE from another WTRU (e.g., running an application as described above). These metrics may include, for example, the resolution of a rendered video stream, the accuracy (e.g., and confidence) of the user's location (e.g., at home), and the time (e.g., latency) used to send video portions to other WTRUs. According to the implementation, the home gateway may host (e.g., run, execute) an NWDAF, configured to collect metrics and obtain (e.g., determine, calculate / compute) predictions about these metrics. Examples of metrics obtained by the NWDAF may include estimated service experience / QoE, which may be, for example, mean opinion score (MOS), average resolution, average latency, etc.

[0084] Mean Opinion Score (MOS) can be considered a measure of QoE, representing the overall quality of a service or system experienced by the end user. MOS can be used to measure the quality of a wide range of services, including video, audio, audiovisual, web browsing, and gaming. For example, MOS can be based on end-user dashboards, subjectively rating their experience of a service or system. MOS can be represented by a single rational number in the range of, for example, 1 to 5, where 1 is the lowest perceived quality and 5 is the highest perceived quality. MOS can also be represented by any other numerical value, such as, for example, between 1 and 100. Based on subjective ratings (e.g., obtained from end-user dashboards), a set of low-level metrics (such as latency, jitter, CPU load, page load time, network throughput, video resolution, video bitrate, number of resolution changes, audio bitrate, game latency, etc.) can be mapped to the 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.

[0085] According to the implementation, a gateway (e.g., a home network) can receive messages (e.g., data, packets) from network devices (such as routers, extenders) that can connect to a local (e.g., home) network. These messages may include (e.g., network) metrics, such as any of wireless signal strength, latency, and throughput. The network devices (such as routers, extenders, etc.) can run (e.g., perform) functions that may be referred to herein as network functions (NFs).

[0086] According to the implementation, network devices (such as routers, extenders, etc.) may operate NFs configured to transmit messages (e.g., data, packets) to a (e.g., home) gateway, including subscription requests for (e.g., estimated) QoE / service experiences of (e.g., a given) application. These NFs (e.g., configured to request subscription to QoE metrics) may be referred to herein as “consumer NFs.” According to the implementation, the (e.g., home) gateway may transmit messages containing (e.g., estimated) service experiences to subscribed network devices (e.g., subscribed metrics). Network devices may (e.g., decide) to modify their behavior based on the metrics / estimated service experiences received from (e.g., home) gateways. For example, a router may prioritize (increase priority) or de-prioritize (e.g., decrease priority) traffic flows based on the received (e.g., QoE) metrics. In another example, a router may route traffic via a specific interface or radio access technology based on the received (e.g., QoE) metrics. In yet another example, the game console might send a message to a (e.g., home) gateway indicating, for example, poor QoE (e.g., poor user positioning). The (e.g., home) gateway might transmit a message containing a QoE metric (or any derived metric, such as either the mean or median) to subscribed network devices that can decide to adjust the priority of the game console's traffic. However, for example, despite the change in traffic priority, the resulting QoE might not improve because the root cause of the QoE degradation could be a poor (e.g., poor, degraded) connection to one of the sensors or cameras.

[0087] According to the implementation plan, NWDAF can provide analysis of service experiences (e.g., observed, measured, monitored) for applications (e.g., VR games, teleconferencing applications). NWDAF can collect service data (e.g., QoE) from AF and network data (e.g., QoS) from NF. Table 1 depicts the service data that can be collected from AF (e.g., transmitted by AF).

[0088]

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

[0090] According to the implementation scheme, network data (such as, for example, QoS flow level network data) can be collected from (e.g., transmitted by) the NF. The network data can be associated with a QoS profile, which is associated with a (e.g., specific) service identified, for example, by an application identifier or IP filter information. The QoS profile can be, for example, a QoS class identifier (QCI) that can represent a QoS category. A QoS category can have any of priority, packet delay budget, and packet loss rate. The QoS profile can also be associated with QoS categories that assign priorities to traffic. For example, an IP filter can be, for example, a set or range of IP addresses that identifies traffic flows (e.g., Protocol Data Unit (PDU) sessions) used by a service. The network data is depicted in Table 2.

[0091]

[0092] Table 2: Network data related to QoS profiles assigned to services (e.g., QoS flow levels) .

[0093] According to the implementation plan, network data related to WTRU can be collected via the OAM protocol. Table 3 depicts the network data related to QoS profiles.

[0094]

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

[0096] Figure 2 This is an illustration of an example of message exchange used for analytics subscription and data collection. According to an implementation, the NF can subscribe to the NWDAF, for example, by invoking a service (Analysis ID service = Service Experience, Analysis Filter Information = (Application ID, Time Window, Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), Region of Interest)) by sending an analytics request / subscription message 21 to the NWDAF. For example, the NF can transmit message 21 (e.g., a packet) containing a request for analytics. This request for analytics may be referred to herein as an analytics subscription. The analytics request may include first information indicating the type of analytics requested (e.g., Analytics ID), which can be set as a "Service Experience". The analytics request may include second information allowing filtering / selection of metrics. The second information may include any of the following: application identifier, time window, session, and network identifier, such as Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), and Region of Interest. The Region of Interest may be, for example, a list of any of the following: wireless cells, access points, or points of access. Subscribed NFs (e.g., NFs that have subscribed to analytics) may be referred to as NF consumers in this paper.

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

[0098] According to the implementation scheme, "request, message / packet request" can correspond to either a request for a single response or a request for a set of (e.g., consecutive) updates (e.g., subscription). For example, a message (e.g., response, notification) can be sent when an updated metric or prediction may become available.

[0099] Mechanisms for collecting QoE and network metrics from AFs can be designed for AFs associated with a single WTRU and can be adapted to AFs associated with multiple (e.g., any number) WTRUs. For example, a virtual reality (VR) gaming AF can interact with multiple WTRUs (e.g., cameras) for positioning, with one VR headset for each user and processing capabilities for rendering. In another example, an interactive teleconferencing AF can interact with a display device, any number of positioning cameras, etc. In yet another example, a vehicle-to-vehicle communication AF can interact with any number of sensors within a vehicle, relaying traffic on the road and communicating with nearby vehicles…

[0100] The implementation described herein allows an NWDAF that has sent a query to an AF for data analysis to identify the WTRUs that the AF and the target device in the query can rely on (e.g., those that can interact with WTRUs, those that can exchange data with WTRUs). While a consumer NF can query (e.g., send a request, an analytics subscription request) a specific device or area, the AF operating in those devices may depend on contributions from WTRUs not indicated in the consumer NF query (e.g., services, applications running on WTRUs) such as sensors collecting information about a player's behavior in another house, or WTRUs connected to APs that are not part of the request, such as 3G / 4G / 5G base stations. Queries targeting a specific area (such as a specific house) may include other WTRUs (e.g., unrelated to the AF), such as a 5G-enabled microwave oven or an unused VR headset or sensor. The implementation described herein allows the NWDAF to identify WTRUs involved in the services provided by the AF and ignore other WTRUs not involved in that service.

[0101] Several WTRUs in the same location can run the same type of AF (e.g., VR game) but contribute to the QoE of two independent services. For example, two children can play a VR game independently of each other on the same (e.g., home) network. The implementation described herein allows for the independent management of analytics for the two services.

[0102] The implementation described herein can be used, for example, in online VR games. VR games can be rendered on a game console that can obtain data from other players in the cloud. The game console can then render and stream the game to the player's VR headset. The QoS of both the game console and the VR headset can affect QoE. For example, latency known to affect game QoE 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 implementation described herein allows NWDAF to determine which of the two links is likely the cause of QoE degradation.

[0103] The implementation described herein allows for dynamic updating of the WTRU list associated with the AF.

[0104] The implementation described herein allows QoS improvements for a specific WTRU to be associated with (e.g., correlated) QoE improvements.

[0105] The implementation described herein allows for improvements in the QoE of an AF involving multiple WTRUs by allowing the quantification of the individual contribution of each WTRU to the QoE.

[0106] The implementation described herein allows (e.g., home) networks (e.g., gateways, or sets of PoA in a home) to identify the WTRUs that should be allocated resources in order to achieve the target QoE of the AF.

[0107] The implementation described herein allows for the identification of WTRUs that can support (e.g., contribute resources to) an application without running (executing) the application. Examples of such WTRUs may include sensors, cameras, ...

[0108] The implementation described in this paper allows querying the NWDAF to estimate the impact of changes in network parameters on QoE.

[0109] According to the implementation scheme, actionable QoE information can be exchanged with AFs involving any number of WTRUs. Actionable here means that exchanging QoE information between different entities (NEF, NWDAF, AF, NF) may result in actions (e.g., QoS policy changes) within the network. A set (e.g., group, list) of WTRUs (e.g., identifiers) can be associated with an AF. This set of WTRUs (e.g., identifiers) can be transmitted from the AF to the NWDAF. For example, the AF can transmit information indicating which WTRUs can participate (e.g., contribute) to an application to the NWDAF. The AF can transmit the identifiers of those WTRUs. The NWDAF can collect QoS data associated with these WTRUs (associated with the AF). The AF can transmit information indicating the (e.g., individual) contribution of a WTRU to QoE (e.g., such as a score, weight) to the NWDAF. The contribution (e.g., any of a score, weight) can be obtained (determined, calculated) by the AF and transmitted from the AF to the NWDAF.

[0110] According to the implementation scheme, the NWDAF can 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 (e.g., target) QoE of the AF. For example, the NF may provide (e.g., transmit) the (e.g., target) QoE of the application to the NWDAF, and the NWDAF may respond to the NF with (e.g., transmit back) the configuration of the WTRU. For example, the configuration of the WTRU may be a set of (WTRU ID, QoS parameter) pairs, where each pair includes a WTRU identifier and QoS parameters that the NWDAF recommends (e.g., determines) for that WTRU. For example, the NWDAF may be able to provide an estimate of the QoE of the AF, which will be caused by the recommended QoS modifications. For example, the NF may provide (transmit) the QoS configuration of the WTRU and any of the WTRU sets (e.g., a set of (WTRU ID, QoS parameter) pairs), and the NWDAF may respond to the NF based on the QoS configuration using the QoE of the application (e.g., the estimated QoE).

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

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

[0113] Monitoring information from the WTRU set

[0114] According to the implementation scheme, the NWDAF can obtain a set of identifiers for WTRUs involved in the AF. For example, the NWDAF can transmit a request to the AF to subscribe to AF analysis. The AF can transmit a response to the NWDAF including a set of identifiers for WTRUs involved in the AF (e.g., affecting the QoE of the AF). In a variant, the set of WTRUs involved in the AF can vary, and the AF can transmit updates to the set of identifiers for the involved WTRUs. According to the implementation scheme, the NWDAF can transmit requests for WTRUs involved in the AF to obtain network information.

[0115] Figure 4 This is an illustration of an example of message exchange used to monitor the set of WTRUs involved in AF. The set of WTRUs involved in AF may include any of the following: a camera used to locate a player in a VR / AR game, a VR headset, etc.

[0116] According to the implementation scheme, a consumer NF (e.g., a device running the consumer NF) can send (e.g., transmit) a first request message 41 to an NWDAF (e.g., a device running an NWDAF) for subscribing to analytics by, for example, invoking either the Nwdaf_AnalyticsSubscription_Subscribe or Nwdaf_AnalyticsInfo_Request services. The first request message 41 may include first information indicating the type of analytics requested (e.g., analytics ID), which can be configured as a "service experience". The request for analytics may include second information allowing filtering / selection of metrics. The second information may include any of the following: application identifier, time window, session, and network identifier, such as Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), and region of interest.

[0117] According to the implementation, the NWDAF (e.g., a device running the NWDAF) can subscribe to service data from the AF by invoking 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 to request a subscription to analytics 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 (e.g., event ID) of the subscribed event that can be set as "service data". The AF (e.g., a device running the AF) may transmit, for example, a second response message 42b, to confirm the subscription or to notify the NWDAF or send a new metric. According to the implementation, the second response message 42b may include a set (e.g., a list) of identifiers of WTRUs involved in the AF that have subscribed to analytics. The set of identifiers included in the response message 42b may be referred to herein as the dependent WTRU ID list, as described in Table 4.

[0118]

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

[0120] According to the implementation scheme, for each WTRU listed by the AF, the NWDAF (e.g., the device running the NWDAF) can 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 to request subscription to network data associated with 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 subscribed event (e.g., event ID) that can be set to "5Ql_Statistics". The NF (e.g., the 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 the implementation scheme, the third response message 43b may include any network (e.g., QoS, statistics) data associated with any WTRUs listed by the AF.

[0121] According to the implementation scheme, the NWDAF (e.g., a device running the NWDAF) can train 44 (e.g., offline or online) a data analytics (e.g., QoE, QoS) model for a given application, which can be used to determine (e.g., estimate, predict) data analytics (e.g., either the application's QoE or the QoS configuration of the WTRU). According to the implementation scheme, in step 44, data analytics (e.g., the application's QoE, QoS configuration) can 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 the implementation scheme, the NWDAF (e.g., a device running the NWDAF) can provide data analytics (e.g., observed service experience) to the consumer NF using either Nwdaf_AnalyticsSubscription_Notify or Nwdaf_AnalyticsInfo_Response. For example, the NWDAF can transmit a fourth message 45 indicating whether (e.g., the QoS parameters used) satisfy the Service MoS (e.g., agreed upon between the mobile network operator (MNO) and the end user, or between the MNO and the external application service provider (ASP). According to the implementation scheme, the fourth message may include (e.g., observed service experience, e.g., average MOS), spatial validity conditions (e.g., indicating the location where the estimated service experience may be applicable), and temporal validity conditions (e.g., indicating the time when the estimated service experience may be applicable).

[0123] Figure 5 This is an illustration of another example of message exchange used to monitor the set of WTRUs involved in an AF. Figure 5 In the example, the first request message 51 and the second request message 52a can be similar to Figure 2 The first request message 2a and the second request message 2b are described in the text.

[0124] According to the implementation scheme, in response to the second request message 52a, the AF (e.g., the device running the AF) may transmit, for example, a second response message 52b, for confirming the subscription or for notifying the NWDAF or sending a new metric. 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 analytics. The set of WTRUs involved in the AF may be transmitted to the NWDAF via (e.g., a separate) message exchange.

[0125] According to the implementation, an NWDAF (e.g., a device running the NWDAF) can subscribe to a list of WTRUs involved in an AF by invoking the Naf_EventExposure_Subscribe service (Event ID = WTRU used, Event Filter Information = Application ID, Subscription Target = Any WTRU). The NWDAF may transmit (e.g., a specific) request message 53a to request a subscription to the set of WTRUs involved in the AF. The (e.g., a specific) request message 53a may include first information indicating the type of subscribed event (e.g., Event ID) of the WTRU that can be set as "WTRU used". For example, the AF (e.g., a device running the AF) may transmit (e.g., a specific) response message 53b to confirm the subscription or to notify or send a new or updated set (e.g., a list) of identifiers of WTRUs involved in the NWDAF. According to the implementation, the (e.g., a specific) response message 53b may include (e.g., a list) of identifiers of WTRUs involved in an AF that may have been subscribed to for 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 the implementation scheme, in the event of a change in the set of WTRUs involved in the AF, a (e.g., specific) response message 53b may be transmitted to indicate an update to the set of WTRUs involved in the AF.

[0126]

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

[0128] According to the implementation scheme, the third request message 54a, the third response message 54b, the data analysis (e.g., QoE, QoS) model (e.g., training) 55, and the fourth message 56 can be respectively similar to Figure 4 The third request message 43a, the third response message 43b, the data analysis (e.g., QoE, QoS) model (e.g., training) 44, and the fourth message 45 described herein. Figure 4 As described above, the fourth message 56 may include data analysis obtained on (e.g., trained) models.

[0129] Depending on the implementation, a (e.g., dedicated) NWDAF can be used to track the set of WTRUs involved in the AF.

[0130] Collect information on WTRU's individual contributions to QoE.

[0131] According to the implementation scheme, the individual contribution of a WTRU to the QoE of an AF involving multiple WTRUs can be quantified into a separate metric. For example, the AF can provide (e.g., transmit) a separate metric to the NWDAF, where the separate metric quantifies the contribution of a single WTRU to the QoE of an AF involving multiple WTRUs. For example, the separate metric value can be obtained (e.g., calculated) by the AF and transmitted to the NWDAF. In another example, the separate metric associated with a WTRU can be obtained (e.g., calculated) by a network element based on network data (e.g., any kind of QoS metric associated with the WTRU). The network element can be a WTRU or a different network element. According to the implementation scheme, the network element (e.g., possibly calculating the separate metric) may or may not operate the AF. According to the implementation scheme, the network element may or may not operate the NWDAF.

[0132] For example, a single metric obtained by the AF for a WTRU can be associated with a (e.g., minimum) set of values ​​for a set of (e.g., QoS, low-level) parameters / metrics of the WTRU that enables the AF's (e.g., minimum) QoE level. As previously described, QoE can 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 bitrate, resolution change count, audio bitrate, game latency, etc.) to a MOS. The MOS model can include parameters / metrics from any number of WTRUs. The AF can use the MOS model to compute the MOS based on the set of low-level parameters / metrics. The AF can also use the MOS model to determine the values ​​and set of parameters for each WTRU (e.g., each of which) that enable the MOS (e.g., above or equal to a given score). For example, this set of values ​​and parameters can be defined, for example, at the specific implementation stage of the application, or learned during deployment via, for example, a machine learning algorithm.

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

[0134] In the second example, the individual metric of WTRU can 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 the set of values ​​that enable AF to achieve the target level of QoE.

[0135] In the third example, the individual metric of WTRU can be as shown in the second example, where a value greater than 100 indicates that the current (e.g., QoS, low level) parameter / metric of WTRU is better than the value that enables AF to achieve the target level of QoE.

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

[0137] In the fifth example, a separate metric for WTRU could be the QoE reduction that may occur when the WTRU disappears or loses communication. Any combination of the examples above is applicable to the implementation described herein.

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

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

[0140] Where a, b, c, and d can be constants, depending on the type of game being played. In this example, if two WTRUs communicate via device-to-device communication, the latency L between the two devices can be the sum of the individual latencyes (e.g., L = L1 + L2). A separate metric for one WTRU (e.g., WTRU(i)) can be, for example, the QoE that AF would obtain in the case of an infinite QoS for the WTRU (e.g., f(L) - f(L - Li)). A separate metric for one WTRU (e.g., WTRU(i)) can be the difference between the effect of latency L and the effect of the latency of the other WTRU in device-to-device communication (e.g., only).

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

[0142] Any method for obtaining the individual impact of a given QoS parameter of a WTRU on the global QoE is applicable to the implementation described herein.

[0143] According to the implementation scheme, individual metrics may be included in the service data information of a message response that the AF may send to the NDWAF via the NEF. For example, refer to Figure 4 Individual metrics may be included in Naf_EventExposure_Notify message 42b. Individual metrics may also be included in service data information as described in Table 6. Table 6 is a modified version of Table 4.

[0144]

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

[0146] According to the implementation plan, and for example, refer to Figure 5 Individual metrics can be included in Naf_EventExposure_Notify message 53b. As described in Table 7, individual metrics can be included in the data information used. Table 7 is a modified version of Table 5.

[0147]

[0148] Table 7: Data on WTRU-related usage from the AF, including individual WTRU contributions. .

[0149] According to the implementation scheme, information indicating the individual contribution of the WTRU can be transmitted as either one of a single list of (WTRU identifier and the individual metric of that WTRU) pairs, where each list includes the WTRU identifier and the corresponding individual metric. Any encapsulation technique that allows the individual contribution of the WTRU to be transmitted to QoE is applicable to the implementation scheme described herein.

[0150] According to the implementation scheme, information indicating the individual contribution of the WTRU may be forwarded (e.g., transmitted) or provided (e.g., transmitted upon request) to any NF (such as PCF).

[0151] Service experience analysis based on WTRU data

[0152] According to the implementation scheme, (e.g., rich, observed) service experience predictions can be provided by the NWDAF (e.g., the device running the NWDAF) based on input data collected from WTRUs involved in a multi-WTRU application. The input data can be either service data or network data. Service data can be collected from the AF. Network data can be collected from either the NF or OAM.

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

[0154] According to the implementation, the NWDAF (e.g., a device running the NWDAF) may receive requests for service experience analysis from, for example, a consumer NF (e.g., either OAM or PCF). For example, according to any implementation described herein, the NWDAF (e.g., a device running the NWDAF) may obtain a list of identifiers of WTRUs involved in the application. The list of WTRU IDs (e.g., sets, groups) may be associated with the AF, for example.

[0155] According to the implementation, the NWDAF (e.g., the device running the NWDAF) can obtain input data from the WTRUs involved in a multi-WTRU application (e.g., each WTRU), for example, via an OAM service. According to any implementation described herein, the WTRU input data may include a separate contribution to QoE, such as being associated with any QoS metric. Table 8 describes examples of WTRU input data collected by the NWDAF. For example, the NWDAF (e.g., the device running the NWDAF) can be configured to invoke (e.g., use) any OAM service to retrieve management data that may be relevant to analytics generation. The OAM service may include a 3GPP OAM service or any other type of OAM service. For example, the NWDAF (e.g., the device running the NWDAF) can be configured to use OAM to collect input data related to (e.g., a single) WTRU via information retrieval based on Minimum Drive Test (MDT). MDT can be considered as a method that enables the WTRU to perform and report (e.g., network coverage) measurement results. For example, the amount of data can be measured separately (e.g., independently) for DL ​​and UL, for example, according to QoS. In another example, throughput can be measured separately (e.g., independently) for both DL and UL, based on the radio access bearer. In yet another example, either reference signal received power or reference signal received quality can be measured. In yet another example, packet delay measurements can be performed separately (e.g., independently) for both DL and UL, for example, based on a QoS class identifier, etc. Depending on the implementation, any QoS metric described herein can be reported (e.g., transmitted) by the WTRU to the NWDAF (e.g., the device operating the NWDAF) independently of its measurement results (e.g., by the WTRU) via MDT-based information retrieval.

[0156]

[0157] Table 8: Examples of WTRU Input Data

[0158] Figure 8 This is an illustration of an example of message exchange used to collect WTRU input data for service experience analysis (e.g., prediction).

[0159] According to the implementation scheme, a consumer NF (e.g., a device running the consumer NF) can send (e.g., transmit) subscription message 81 to an NWDAF (e.g., a device running an NWDAF) for subscribing to service experience analytics by, for example, invoking either the Nwdaf_AnalyticsSubscription_Subscribe or Nwdaf_AnalyticsInfo_Request services. Subscription message 81 may include first information indicating the type of requested analytics (e.g., analytics ID) that can be set to "service experience". Subscription message 81 may include second information allowing filtering / selection of metrics. The second information may include an application identifier (ID) and either a time window representing the target period of the analytics. 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.

[0160] According to the implementation scheme, in step 82, the NWDAF (e.g., the device running the NWDAF) can collect input data from individual WTRUs involved in the AF (e.g., each) based on information retrieval based on, for example, MDT.

[0161] According to the implementation scheme, 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 implementation schemes described herein. For example, the NWDAF (e.g., a device running the NWDAF) may obtain a prediction of service experience for future time periods based on the collected input data and (e.g., a trained) QoE model.

[0162] According to the implementation scheme, the NWDAF (e.g., a device running the NWDAF) can 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 can transmit a notification message 84 indicating the predicted service experience of the application. Table 9 describes examples of parameters included in the notification message 84.

[0163] information describe Application ID Identify the application that provides this information. Service experience Observed service experience prediction

[0164] Table 8: Examples of WTRU Input Data

[0165] According to the implementation plan, the service experience may include the service experience type (e.g., any of voice, video, etc.), the service experience within the target time period (e.g., any of mean, variance), a list of identifiers of WTRUs involved in the application service experience (e.g., subscription perpetual identifier (SUPI)), an estimated percentage of WTRUs with similar service experiences, spatial validity (e.g., the area where the estimated service experience may be applicable), validity period, and probability assertions (e.g., indicating the confidence level of the prediction).

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

[0167] Based on QoS configuration estimation QoE

[0168] According to the implementation scheme, the NWDAF (e.g., the device operating the NWDAF) can collect information that can be used to improve the QoE of the AF. This information can be provided to the consumer NF (e.g., the PCF), which can update (e.g., make) decisions to improve the QoE.

[0169] The implementation scheme described herein can also be applied to AFs involving a single WTRU.

[0170] Figure 6 This is an illustration of an example of message exchange for WTRU-based (e.g., QoS) configuration estimation of QoE.

[0171] According to the implementation scheme, the NWDAF (e.g., a device running the NWDAF) can be queried by the NF (e.g., receiving a request from the NF) if there is a (e.g., potential) modification 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) can respond with a QoE estimate resulting from the modification (e.g., transmitting the QoE estimate).

[0172] According to the implementation scheme, a consumer NF (e.g., a device running the consumer NF) can send (e.g., transmit) a first request message 61 to an NWDAF (e.g., a device running the NWDAF) by, for example, invoking either the Nwdaf_AnalyticsSubscription_Subscribe or Nwdaf_AnalyticsInfo_Request services, to request a WTRU (WTRU set) involved in the AF. For example, the service can be invoked as follows: (Analysis ID = "WTRU used by the 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 analysis (Analysis ID) requested for a WTRU that can be set as "WTRU used by the AF". The request for the involved WTRU may include second information allowing filtering / selection parameters. The second information may include any of the application identifier, time window, session, and network identifier, such as Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), and Region of Interest. In step 615, the NWDAF (e.g., a device operating the NWDAF) may retrieve a list of WTRUs involved in the AF according to any of the embodiments described herein.

[0173] According to the implementation scheme, in response to the first request message 61, the NWDAF (e.g., a device running the NWDAF) can transmit a first response message 62 by invoking either the Nwdaf_AnalyticsSubscription_Notify or Nwdaf_AnalyticsInfo_Response services. This first response message includes identifiers of WTRUs (e.g., a set of identifiers). The identifiers of WTRUs included in the first response message 62 (e.g., the set of identifiers) may correspond to, for example, the set of WTRUs involved (e.g., estimated involved) in the AF during the time window requested by the NF.

[0174] According to the implementation scheme, a consumer NF (e.g., a device running the consumer NF) can send (e.g., transmit) a second request message 63 to an NWDAF (e.g., a device running an NWDAF) to request data analysis, for example, by invoking either the Nwdaf_AnalyticsSubscription_Subscribe or Nwdaf_AnalyticsInfo_Request services. For example, the service can 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, [Suggested] QoS Values) list). The second request message 63 may include first information indicating the type of analysis requested (e.g., Analysis ID) that can be set to "Service Experience from QoS Estimation". The request for analysis may include second information allowing filtering / selection parameters. The second information may include any of the following: application identifier, time window, session, and network identifier, such as Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), and Region of Interest. Requests for analysis may include third information that allows indication of the QoS configuration of WTRUs (e.g., a set of WTRUs) for which an estimated QoE can be requested. The QoS configuration may be transmitted as WTRU IDs (e.g., a set of WTRU IDs), where a set of values ​​(e.g., low-level, QoS parameters) may be associated with each WTRU ID. For example, the QoS parameter associated with a WTRU ID may be a QoS value that the PCF can consider assigning to the WTRU.

[0175] According to the implementation scheme, in step 635, the NWDAF (e.g., a device running the NWDAF) can obtain (e.g., calculate) an estimated QoE value that can be achieved with the applicable received QoS configuration.

[0176] According to the implementation scheme, the NWDAF (e.g., a device running the NWDAF) can transmit a second response message 64 by invoking either the Nwdaf_AnalyticsSubscription_Notify or Nwdaf_AnalyticsInfo_Response services. This second response message includes a QoE value (e.g., a range of QoE values) obtained (e.g., estimated) based on the QoS configuration of the received WTRU. The second response message 64 may include information indicating, for example, the extent to which the proposed QoS configuration might satisfy the QoE (e.g., as agreed upon between the MNO and the end user or between the MNO and an external ASP). For example, this information might indicate any of the following: estimated service experience (e.g., average MOS), spatial validity conditions (e.g., the location where the estimated MOS might apply), or temporal validity conditions (e.g., the time when the estimated MOS might apply).

[0177] Obtain (e.g., target) QoE QoS configuration

[0178] Figure 7 This is an illustration of an example of message exchange used to obtain QoS configuration based on a target QoE. An NWDAF (e.g., a device running an NWDAF) can be queried using, for example, an NF that might target an AF's QoE (e.g., receiving a request including a QoE). For each WTRU that might be involved in the AF, the NWDAF (e.g., the device running the NWDAF) can respond using QoS (e.g., a proposed QoS) (or any other parameter or combination of parameters). The implementation described herein can also be applied to AFs involving a single WTRU.

[0179] According to the implementation scheme, a consumer NF (e.g., a device running the consumer NF) can send (e.g., transmit) a request message 71 to an NWDAF (e.g., a device running the NWDAF) to request data analysis, for example, by invoking either the Nwdaf_AnalyticsSubscription_Subscribe or Nwdaf_AnalyticsInfo_Request services. For example, the service can be invoked 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 (Analysis ID) requested, which can be set to "QoS estimation from QoE". The request for analysis may include second information allowing filtering / selection parameters. The second information may include any of the following: application identifier, time window, session, and network identifier, such as Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), and Region of Interest. The request for analysis may include third information that allows indication of the QoE for which QoS configuration can be requested (e.g., the QoE for the target range).

[0180] According to the implementation scheme, in step 715, the QoS configuration can be obtained based on the requested QoE (e.g., the QoE of the target range). For example, the QoS configuration can be obtained by requesting (e.g., invoking) a function based solely on the QoE (e.g., the QoE of the target range). In another example, the QoS configuration can be obtained by requesting (e.g., invoking) a function based on the QoE (e.g., the QoE of the target range) and network data associated with WTRUs (e.g., a set of WTRUs) involved in the application. Network data can be received according to any implementation scheme described herein, and the network data can include any QoS metric according to any implementation scheme described herein. In yet another example, the QoS configuration can be obtained by requesting (e.g., invoking) a function based on any individual contribution metric of any WTRU in the WTRUs (e.g., a set of WTRUs) involved in the application, based on the QoE (e.g., the QoE of the target range) and any WTRU in the WTRUs (e.g., a set of WTRUs). Individual contribution metrics can be included in service data, which can be received according to any implementation scheme described herein.

[0181] According to the implementation scheme, the NWDAF (e.g., a device running the NWDAF) can transmit a response message 72, which includes requested data analytics, such as QoS configurations for WTRUs (e.g., a set of WTRUs) that may be involved in the AF. The QoS configuration enables the AF to achieve the requested QoE (e.g., a target range of QoE). The response message 72 can be transmitted by invoking either the Nwdaf_AnalyticsSubscription_Notify or Nwdaf_AnalyticsInfo_Response services. The QoS configuration can be transmitted as WTRU IDs (e.g., a set of WTRU IDs), where a set of values ​​(e.g., low-level, QoS parameters) can be associated with each WTRU ID.

[0182] According to the implementation scheme, the QoS configuration may include, for example, values ​​(e.g., specific values) for any of the following parameters of the service: data volume (e.g., for DL ​​and UL respectively or for the whole); throughput (e.g., for DL ​​and UL respectively or for the whole), for example, based on either the radio access bearer or the UL radio network controller; minimum expected signal quality (such as, for example, minimum expected RSRP, RSRQ); packet delay (e.g., for DL ​​and UL respectively or for the whole); packet loss rate (e.g., for DL ​​and UL respectively or for the whole); priority, etc. The QoS configuration may also include a QoS class identifier (QCI), which may represent a QoS class. For example, the QoS class may have any of priority, packet delay budget, and packet loss rate, etc.

[0183] According to the implementation scheme, the functionality that can be requested (e.g., invoked, used) based on at least one QoE (e.g., the QoE of the target range) can be any of a lookup table, optimization algorithm, and machine learning model. To determine the QoS configuration, in addition to the requested QoE (e.g., the QoE of the target range), the functionality may also use input data that may be associated with the application. For example, according to any implementation scheme described herein, the input data may include any network data related to any WTRU involved in the application. For example, according to any implementation scheme described herein, the input data may include any individual contribution metric of 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 time window, session and network identifier, single network slice selection aid information (S-NSSAI), data network name (DNN), and any of the regions of interest. The input data may include information about the WTRUs 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. Input data may include information about the Application AF, such as location, timestamp, application ID, current QoE, application type, etc.

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

[0185] In the second variation, the functionality that can be based on at least one QoE (e.g., target-range QoE) request can be coupled to (e.g., an analysis model, a machine learning model) an optimization algorithm for obtaining a QoE-based QoS configuration (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 herein can be used to compute QoE based on, for example, either a QoS metric or a QoS configuration. An optimization algorithm can be used to obtain the QoS configuration of the WTRUs (set of WTRUs) involved in the AF based on this model. For example, an optimization algorithm can be used to obtain any of the following: the optimal QoS configuration (e.g., allowing the highest QoE), a QoS configuration that satisfies the requested QoE, or a QoS configuration that satisfies 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) can be differentiable, and a gradient descent algorithm can be performed to obtain the QoS that achieves the requested QoE value. In another example, any of the following can be used as an optimization algorithm coupled to the model that allows QoE to be determined based on the QoS configuration: a genetic algorithm, a sampling-based method, or simulated annealing.

[0186] In the third variant, the functionality that can be requested based on at least one QoE (e.g., the QoE of the target range) can be a machine learning model that maps (e.g., any input data and) the target QoE to a QoS configuration. This model may have been pre-trained (e.g., offline). The machine learning model can be based on any of the following: decision trees, random forests, learned regression, boosting methods, bagging, deep neural networks, support vector machines, nearest neighbors, etc.

[0187] According to the implementation scheme, a separate contribution metric to QoE can be used to obtain the QoS configuration. For example, an NWDAF (e.g., a device running an NWDAF) may obtain (e.g., only) separate contributions that might indicate that WTRUs may not meet the target level of QoE, resulting in a new QoS configuration. For example, the NWDAF (e.g., a device running an NWDAF) can use these separate contributions to sort WTRUs by separate contribution (or missing contribution) and can sequentially process the WTRUs to calculate a new QoS configuration for each WTRU (e.g., each WTRU) until the requested QoE is achieved. Any technique that considers separate contributions to QoE to determine the QoS configuration is applicable to the implementation scheme described herein.

[0188] According to the implementation plan, examples of the 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. Although in Figures 4 to 8Although not explicitly shown in this document, the Nwdaf_AnalyticsInfo_Request and Nwdaf_AnalyticsInfo_response messages can be used to request and receive data analysis, respectively, according to any implementation described herein.

[0189] Examples of application functions in a home network

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

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

[0192] The game console may transmit messages 42b and 53b to the home gateway, which contain metrics and measurements related to the application's QoE. These metrics may include, for example, any of the following: the resolution of the rendered video stream, the accuracy and confidence of user location within the home, and the time (e.g., latency) for sending video portions to other (e.g., end devices) WTRUs. For example, the game console may transmit message 42b upon receiving subscription messages 42a and 52a from the home gateway, and / or when (e.g., new) application data may become available (e.g., updated). Depending on the implementation, messages 42b and 53b may include identifiers (a list of identifiers, a set of identifiers) of WTRUs (e.g., all WTRUs) that the application may know and that may contribute to the application. For example, this list may include identifiers (such as MAC addresses, subscription persistent identifiers (SUPIs)) of any sensors and cameras that may be sending data to the game console. This list may also include identifiers of the WTRUs that render the video stream generated by the game console.

[0193] According to the implementation scheme, for each of the WTRUs identified in the list, messages 42b and 53b may include a number indicating the impact of the WTRU on QoE, depending on the application. For example, this number may be a Boolean value indicating whether the WTRU can (e.g., fully) meet the target set by the application, or it may be a percentage between 0 and 100 indicating the extent to which the WTRU may be close to (e.g., fully) meeting the target set by the application.

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

[0195] The home gateway can obtain either a 44, 55 (deterministic, calculated) service experience or a QoE score based on either messages and metrics received from the game console and network devices.

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

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

[0198] The network equipment can send message 71 to the home gateway, which contains (e.g., the target) QoE. The home gateway can respond with message 72, which contains QoS configurations (e.g., a list of (QoS recommendation parameters, WTRU identifiers) that enable the AF to achieve (e.g., the target) QoE.

[0199] Figure 9 This is an illustration of 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., application-related). 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 at least one of the application's QoE. 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 associated with at least one WTRU and, for example, with an application. According to an embodiment, in step 940, the QoE value of the application may be obtained based on the received first and second response messages.

[0200] According to the implementation plan, the QoE model can be trained based on the received first response message and second response message.

[0201] According to the implementation scheme, a third request signal may be received for estimating the QoE value of the application. For example, the third request signal may include a QoS configuration, based on which a QoE value estimate may be requested. According to the implementation scheme, a third response signal may be transmitted. The third response signal may include a QoE value obtained based on the QoS configuration, a received first response message, and a received second response message.

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

[0203] Figure 10This is an illustration of an example of a method 1000 for obtaining a QoS configuration. According to an embodiment, in step 1010, a request message may be received. This request message may request a QoS configuration associated with at least one WTRU involved in the application, for obtaining the application's target QoE. According to an embodiment, in 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.

[0204] Depending on the implementation, the application may involve multiple WTRUs. The obtained QoS configuration may be associated with multiple WTRUs (e.g., any one of multiple WTRUs).

[0205] According to the implementation plan, subscription messages may have been transmitted, for example, before the QoS configuration is obtained, for subscribing to service data related to the application.

[0206] According to the implementation scheme, a subscription response message may be received, for example, in response to a subscription message and, for example, before obtaining QoS configuration, the subscription response message includes multiple identifiers corresponding to multiple WTRUs involved in the application.

[0207] According to the implementation scheme, network data associated with multiple WTRUs can be received. For example, QoS configuration can be further obtained (e.g., calculated) based on the received network data.

[0208] According to the implementation scheme, service data related to the application may be received, for example, before the QoS configuration is obtained. This service data may include a measure of the WTRU's individual contribution to the application's QoE. The WTRU's individual contribution measure quantifies the WTRU's individual contribution to QoE. For example, the QoS configuration may be further obtained based on the WTRU's individual contribution measure.

[0209] According to the implementation plan, separate contribution metrics for the WTRU can be received from network elements that are different from the WTRU. These network elements may be performing application functions associated with an application.

[0210] According to the implementation plan, a separate contribution metric for the WTRU can be received from the WTRU.

[0211] According to the implementation scheme, network data related to the WTRU may include any QoS metrics associated with the WTRU, which may be received, for example, from the WTRU.

[0212] Figure 11This is an illustration of an example of a method 1100 for obtaining data analytics. According to one embodiment, in step 1110, a message may be transmitted (e.g., subscription, request) for subscribing to service data related to the application. According to one embodiment, in step 1120, a response message may be received (e.g., subscription) identifying multiple WTRUs involved in the application. According to one embodiment, in step 1130, network data related to the WTRUs may be received. According to one embodiment, in step 1140, service data related to the application may be received. This service data may include a measure of the individual contribution of each WTRU to the application's QoE, wherein the measure of the individual contribution of each WTRU quantifies the individual contribution of each WTRU to the QoE. According to one embodiment, in step 1150, data analytics associated with the application may be transmitted. Data analytics may be obtained based on, for example, network data related to the WTRUs and the measure of the individual contribution of each WTRU.

[0213] According to the implementation plan, separate contribution metrics of the WTRU can be received from network elements that are different from the WTRU. For example, a network element may be performing application functions associated with an application.

[0214] According to the implementation plan, a separate contribution metric for the WTRU can be received from the WTRU.

[0215] According to the implementation scheme, network data related to the WTRU may include any QoS metrics associated with the WTRU, which may be received, for example, from the WTRU.

[0216] According to the implementation plan, either a QoS metric associated with the WTRU or a separate contribution metric of the WTRU can be received from the WTRU via information retrieval based on Minimum Drive Test (MDT).

[0217] According to the implementation plan, the QoE model can be applied to either network data or individual contribution metrics to obtain data analysis results.

[0218] According to the implementation scheme, data analytics may include the application's QoE value. According to the implementation scheme, data analytics may include the QoS configuration of the WTRU, which indicates how the WTRU configuration should be used to obtain the application's target QoE value. For example, the QoS configuration may be obtained based on the target QoE value.

[0219] According to the implementation plan, the target QoE value can be received from the requesting network element.

[0220] in conclusion

[0221] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) 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 internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

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

[0223] Furthermore, any features, variations, or embodiments described for the method are compatible with apparatus equipment including means for processing the disclosed method, with apparatus including a processor configured to process the disclosed method, with computer program products including program code instructions, and with non-transitory computer-readable storage media storing program instructions.

[0224] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in 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 optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0225] Furthermore, the above embodiments specify processing platforms, computing systems, controllers, and other devices including processors. 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 can be executed by various CPUs and memories. Such actions and operations or instructions can be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0226] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that representative embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may also support the provided methods.

[0227] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that representative embodiments are not limited to the memory described above, and other platforms and memories may also support the method described.

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

[0229] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software may become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of the deployment of the processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0230] The above detailed description has illustrated various embodiments of the apparatus and / or process using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can 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 array (FPGA) circuits, any other type of integrated circuit (IC) and / or state machine.

[0231] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described in this patent application, which are intended as examples of various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0232] It should also be understood that the terminology used herein is for the purpose of describing specific implementations only and is not intended to be limiting. As used herein, when referred to herein, the term “station” and its abbreviation “STA”, “user equipment” and its abbreviation “UE” may mean: (i) a wireless transmitting and / or receiving unit (WTRU), as described below; (ii) any of several implementations of a WTRU, as described below; (iii) equipment having wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU, as described below; (iii) equipment having wireless and / or wired capabilities configured with fewer than all the structure and functions of a WTRU, as described below; or (iv) etc. The following is relative to Figures 1A to 1D Details of an exemplary WTRU that can represent any UE described herein are provided.

[0233] In some representative embodiments, 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 integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein are, wholly or partially, equivalently implemented 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 circuitry and / or writing software and / or firmware code according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement that distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media (such as floppy disks, hard disks, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0234] The topics described herein sometimes illustrate different components contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same function is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to enable the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0235] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0236] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim objects, such intention will be explicitly stated in the claims, and if no such claim objects are present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the 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 objects. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim objects is limited to an embodiment containing only one such claim object by using the indefinite articles “a” or “an.” This is true even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce the subject matter of a claim. Furthermore, even when a specific number of the introduced subject matter of a claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matters" without other modifiers means at least two subject matters, or two or more subject matters).

[0237] Furthermore, in instances where the convention of "at least one of A, B, and C" is used, generally speaking, such a construction implies that a person skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C). In instances where the convention of "at least one of A, B, or C" is used, generally speaking, such a construction implies that a person skilled in the art will understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C). A person skilled in the art should also understand that, in fact, any separate 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 term, any one of the terms, or both of the terms. For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items alone or in combination with other items and / or other item categories, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Furthermore, as used herein, the term “group” or “cluster” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero.

[0238] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0239] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

[0240] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to invoke 35 U.S.SC §112. 6. The claim format is either device plus function, and any claim without the term "device for..." is not intended to be so.

[0241] The software-associated processor can be used to implement the radio frequency transceiver in a Transmitter-Receiver Unit (WTRU), User Equipment (UE), terminal, base station, Mobility Management Entity (MME), or Evolved Packet Core (EPC), or any host. The WTRU can be used in conjunction with modules and can be implemented in hardware and / or software including: Software-defined Radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keypads, etc. Modules, FM radio units, Near Field Communication (NFC) modules, Liquid Crystal Display (LCD) units, Organic Light Emitting Diode (OLED) units, Digital Music Players, Media Players, Video Game Players, Internet Browsers, and / or any Wireless Local Area Network (WLAN) or Ultra-Wideband (UWB) modules.

[0242] Although the invention has been described in relation to a communication system, it is conceivable that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, one or more functions of the various components can be implemented in software that controls the general-purpose computer.

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

Claims

1. A method implemented in a first network element, the method comprising: Receive a first request message, the first request message indicating a target quality of experience (QoE) for an application involving multiple wireless transmit and receive units (WTRUs); Transmit a second request message for subscribing to receive service experience data related to the application; Receive network data related to the plurality of WTRUs; Receive the service experience data related to the application; Based on the service experience data, the network data, and the target QoE, a Quality of Service (QoS) configuration is determined for the plurality of WTRUs, wherein the QoS configuration is used to obtain the target QoE for the application; as well as Transmit the QoS configuration for the plurality of WTRUs.

2. The method of claim 1, wherein the target QoE of the application includes the average opinion score of the application.

3. The method of claim 1, wherein the service experience data associated with the application indicates a measure of the individual contribution of the plurality of WTRUs to the global QoE of the application.

4. The method of claim 3, wherein the individual contribution metric of the WTRU includes the service experience contribution weights of the plurality of WTRUs to the global QoE of the application.

5. The method of claim 4, wherein the individual contribution metric of the WTRU represents the individual contribution of the WTRU to the global QoE of the application.

6. The method of claim 5, wherein the service experience data associated with the application includes an information element indicating the individual contribution metric of the WTRU, wherein the information element is received from the WTRU or from a second network element different from the WTRU.

7. The method of claim 1, wherein the service experience data associated with the application indicates the plurality of WTRUs involved in the application.

8. The method of claim 1, wherein the first request message further indicates any one of Single Network Slice Selection Auxiliary Information (S-NSSAI), Data Network Name (DNN), and Region of Interest.

9. The method of claim 1, wherein the target QoE includes a range of QoE values.

10. The method of claim 1, wherein transmitting the second request message includes sending the second request message directly or via a network exposure function to the application function.

11. An apparatus including circuitry, the apparatus comprising any one of a transmitter, a receiver, a processor, and a memory, configured to: Receive a first request message, the first request message indicating a target quality of experience (QoE) for an application involving multiple wireless transmit and receive units (WTRUs); Transmit a second request message for subscribing to receive service experience data related to the application; Receive network data related to the plurality of WTRUs; Receive the service experience data related to the application; Based on the service experience data, the network data, and the target QoE, a Quality of Service (QoS) configuration is determined for the plurality of WTRUs, wherein the QoS configuration is used to obtain the target QoE for the application; as well as Transmit the QoS configuration for the plurality of WTRUs.

12. The apparatus of claim 11, wherein the target QoE of the application includes the average opinion score of the application.

13. The apparatus of claim 11, wherein the service experience data associated with the application indicates a measure of the individual contribution of the plurality of WTRUs to the global QoE of the application.

14. The apparatus of claim 13, wherein the individual contribution metric of the WTRU includes the service experience contribution weights of the plurality of WTRUs to the global QoE of the application.

15. The apparatus of claim 14, wherein the individual contribution metric of the WTRU represents the individual contribution of the WTRU to the global QoE of the application.

16. The apparatus of claim 15, wherein the service experience data associated with the application includes an information element indicating the individual contribution metric of the WTRU, wherein the information element is received from the WTRU or from a second network element different from the WTRU.

17. The apparatus of claim 11, wherein the service experience data associated with the application indicates the plurality of WTRUs involved in the application.

18. The apparatus of claim 11, wherein the first request message further indicates any one of Single Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), and Region of Interest.

19. The apparatus of claim 11, wherein the target QoE includes a range of QoE values.

20. The apparatus of claim 11, wherein being configured to transmit the second request message includes being configured to send the second request message directly or via a network exposure function to an application function.

Images