A method for QOE / rvqoe event triggered reporting and individual rvqoe configuration

Abstract

This disclosure generally relates to Quality of Experience (QoE) reporting configuration. For example, a Radio Access Network Visible QoE (RVQoE) mechanism that can be independently configured is provided such that Radio Access Network (RAN) terminated QoE reporting can be provisioned without having to reply on other QoE configurations. Such an RVQoE mechanism may be referred to as individual RVQoE (iRVQoE). An event-triggered mechanism for QoE / RVQoE / iRVQoE reporting is further discloses which reduces unnecessary reporting and save reporting resource cost. The corresponding QoE / RVQoE / iRVQoE oE configuration may be transmitted between the various network nodes in various manners during connection and / or mobility of the UE.

Description

A METHOD FOR QOE / RVQOE EVENT TRIGGERED REPORTING AND INDIVIDUAL RVQOE CONFIGURATIONTECHNICAL FIELD

[0001] This disclosure generally relates to quality of experience (QoE) reporting configuration and is particularly directed to (1) RAN Visible QoE (RVQoE) that may be independently configurable from any other QoE, referred to as individual RVQoE) and (2) event triggered QoE / RVQoE / iRVQoE reporting.BACKGROUND

[0002] In a wireless network, QoE may be reported from one or more User Equipment (UE) to the core network or the access network nodes for various purposes. The timing and content of such reporting may be configured by the network. It is desirable to configure the UE to report QoE with flexibility and in an efficient manner.SUMMARY

[0003] This disclosure generally relates to QoE reporting configuration. For example, an RVQoE mechanism that can be independently configured is provided such that Radio Access Network (RAN) terminated QoE reporting can be provisioned without having to reply on other QoE configurations. Such an RVQoE mechanism may be referred to as individual RVQoE. An event-triggered mechanism for QoE or individual RVQoE reporting (individual or otherwise) is further discloses which reduces unnecessary reporting and save reporting resource cost. The corresponding QoE / RVQoE / iRVQoE configuration may be transmitted between the various network nodes in various manners during connection and / or mobility of the UE.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

[0005] FIG. 2 illustrates an example wireless access network including a plurality of mobile stations / terminals or User Equipments (UEs) and a wireless access network node in communication with one another via an over-the-air radio communication interface.

[0006] FIG. 3 shows an example radio access network (RAN) architecture.

[0007] FIG. 4 shows an example communication protocol stack in a wireless access network node or wireless terminal device including various network layers.

[0008] FIG. 5 illustrates an example messaging flow for transmitting QoE and / or individual RVQoE configuration information from a core network to a UE via a RAN.

[0009] FIG. 6 illustrates an example messaging flow for transmitting QoE and / or individual RVQoE configuration information from a central unit (CU) to a distributed unit (DU) of a RAN node.

[0010] FIG. 7 illustrates an example messaging flow for QoE and / or individual RVQoE reporting.

[0011] FIG. 8 illustrates an example messaging flow for transmitting QoE and / or individual RVQoE configuration during UE mobility.

[0012] FIG. 9 illustrates another example messaging flow for transmitting QoE and / or individual RVQoE configuration during UE mobility.

[0013] FIG. 10 illustrates an example messaging flow for transmitting QoE and / or RVQoE configuration during an NG based handover.DETAILED DESCRIPTION

[0014] The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments. The present disclosure may, however, be embodied in a variety of different forms and, therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the embodiments to be set forth below.

[0015] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” or “in other embodiments” as used herein does not necessarily refer to a different embodiment. The phrase “in one implementation” or “in some implementations” as used herein does not necessarily refer to the same implementation and the phrase “in another implementation” or “in other implementations” as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

[0016] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” or “at least one” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a” , “an” , or “the” , again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” or “determined by” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0017] Wireless Network Overview

[0018] An example wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier  network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as Radio Access Network (RAN) . The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

[0019] In the example wireless communication network of 100 of FIG. 1, the UEs may communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

[0020] FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and / or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM / USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be  implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

[0021] Similarly, the WANN 120 may include a wireless base station or other wireless network access point capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, or a 5G distributed-unit base station. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

[0022] Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and / or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are  also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

[0023] The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

[0024] Returning to wireless radio access network (RAN) , FIG. 3 illustrates an example RAN 340 in communication with a core network 310 and wireless terminals UE1 to UE7. The RAN 340 may include one or more various types of wireless base station or WANNs 320 and 321 which may include but are not limited to gNB, eNodeB, NodeB, or other type of base stations. The RAN 340 may be backhauled to the core network 310. The WANNs 320, for example, may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. The CU 322 is connected with DU1 324 and DU2 326 via various interfaces, for example, an F1 interface. The F1 interface, for example, may further include an F1-C interface and an F1-U interface, which may be used to carry control plane information and user plane data, respectively. In some embodiments, the CU may be a gNB Central Unit (gNB-CU) , and the DU may be a gNB Distributed Unit (gNB-DU) . While the various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of radio access networks including but not limited to other generations of cellular network, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0025] The UEs may be connected to the network via the WANNs 320 over an air interface. The UEs may be served by at least one cell. Each cell is associated with a coverage area.  These cells may be alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell while may be potentially connected or connectable to more than one cell. In some example implementations, a DU of FIG. 3 may support one or multiple cells and one cell is supported by only one DU. In the example of FIG. 3, UE1, UE2, and UE3 may be served by cell1 330 of the DU1, whereas UE4 and UE5 may be served by cell2 332 of the DU1, and UE6 and UE7 may be served by cell3 associated with DU2. In some implementations, a UE may be served simultaneously by two or more cells. Each of the UE may be mobile and the signal strength and quality from the various cells at the UE may depend on the UE location and mobility.

[0026] FIG. 4 further illustrates a simplified view of the various network layers involved in transmitting user-plane PDUs from a transmitting device 402 to a receiving device 404 in the example wireless access network of FIGs. 1-3. FIG. 4 is not intended to be inclusive of all essential device components or network layers for handling the transmission of the PDUs. FIG. 4 illustrates that the data packaged by upper network layers 420 at the transmitting device 402 may be transmitted to corresponding upper layer 430 (such as radio resource control or RRC layer) at the receiving device 304 via Packet Data Convergence Protocol layer (PDCP layer, not shown in FIG. 4) and radio link control (RLC) layer 422 and of the transmitting device, the physical (PHY) layers of the transmitting and receiving devices and the radio interface, as shown as 406, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device. Various network entities in each of these layers may be configured to handle the transmission and retransmission of the PDUs.

[0027] In FIG. 4, the upper layers 420 may be referred as layer-3 or L3, whereas the intermediate layers such as the RLC layer and / or the MAC layer and / or the PDCP layer (not shown in FIG. 4) may be collectively referred to as layer-2, or L2, and the term layer-1 is used to refer to layers such as the physical layer and the radio interface-associated layers. In some instances, the term “low layer” may be used to refer to a collection of L1 and L2, whereas the term “high layer” may be used to refer to layer-3. In some situations, the term “lower layer” may be used to refer to a layer among L1, L2, and L3 that are lower than a current reference layer. Control signaling may be initiated and triggered at each of L1 through L3 and within the various network layers therein. These signaling messages may be encapsulated and cascaded  into lower layer packages and transmitted via allocated control or data over-the-air radio resources and interfaces. The term “layer” generally includes various corresponding entities thereof. For example, a MAC layer encompasses corresponding MAC entities that may be created. The layer-1 (L1) , for example, encompasses PHY entities. The layer-2 (L2) , for another example encompasses MAC layers / entities, RLC layers / entities, service data adaptation protocol (SDAP) layers and / or PDCP layers / entities.

[0028] In some example CU / DU splitting implementations shown in FIG. 3, the CU 322 may be defined as a logical node hosting higher layer RRC, SDAP and PDCP protocols of the example gNB or RRC and PDCP protocols or protocol entities of the example en-gNB that controls the operation of the one or more example DUs 324 and 326. The example DUs 324 and 326 may each be defined as a logical node hosting lower layer RLC, MAC and PHY protocol or protocol entities of the gNB or en-gNB, with its operation partly controlled by CU 322.

[0029] In some example implementations, the cells shown in FIG. 3 may be alternatively referred to as serving cells. The serving cells may be grouped into serving cell groups (CGs) . A serving cell group may be either a Master CG (MCG) or Secondary CG (SCG) . Within each type of cell groups, there may be one primary cell and one or more secondary cells. A primary cell in a MSG, for example, may be referred to as a PCell, whereas a primary cell in a SCG may be referred to as PSCell. Secondary cells in either an MCG or an SCG may be all referred to as SCell. The primary cells including PCell and PSCell may be collectively referred to as spCell (special Cell) . All these cells may be referred to as serving cells or cells. The term “cell” and “serving cell” may be used interchangeably in a general manner unless specifically differentiated. The term “serving cell” may refer to a cell that is serving, will serve, or may serve the UE. In other words, a “serving cell” may not be currently serving the UE. While the various embodiment described below may at times be referred to one of the types of serving cells above, the underlying principles apply to all types of serving cells in both types of serving cell groups.

[0030] Quality of Experience (QoE) and RAN Visible QoE (RVQoE)

[0031] Service quality of the wireless network above may be characterized in various manners and using various metrics. One of such metrices may be referred to as Quality of Experience (QoE) , which may be reported from a UE to the network and may be used by the network to collect quality of experience from single a UE or multiple UEs.

[0032] QoE reporting may be requested and may be configured by the core network. Such QoE reporting may be generated by the UE as configured and transmitted to the core network via the RAN. The RAN simply pass the QoE report packaged in a message to the core network.

[0033] In some other implementations, QoE reports may be configured by the core network as RAN visible. In such situations, the so configured QoE reports may be extractable on the network side at the RAN even though it may still terminate at the core network. The RAN may use the reported QoE to improve services (such as adjustment of allocation of wireless resources and the like) . This may be referred to as a RAN Visible QoE (RVQoE) reporting mechanism. In some example implementations, the RVQoE may be enabled based a basis QoE configuration by the core network. For example, when an RVQoE is enabled, the QoE configured by the core network may be used to generate a QoE report terminated at the core network but visible at the RAN.

[0034] In some other example implantations as described in further detail below, a mechanism is provided for configuring QoE reporting to the RAN that may not have to rely on or linked to a QoE configuration. Such a QoE reporting would necessarily be RAN visible. Such a QoE may be configured to the UE directly by the RAN without involvement of the core network. In some other situations, however, such QoE may still be configured to the UE by the core network for the RAN. Such an RVQoE mechanism may be referred to as individual RVQoE, or iRVQoE. While iRVQoE may not need to rely on any core network configured QoE, a configuration for iRVQoE by the RAN or the core network may still have an option to refer to another core network configured QoE in order to reuse measurements and contents of QoE reporting to the core network in the individual RVQoE to the RAN. For example, QoE and / or an RVQoE may be configured by the network and an iRVQoE may be configured by the RAN or by the core network at the same time. Any one or more of the QoE / RVQoE / iRVQoE reporting to the RAN or the core network may be performed at the same time or different times. Any of the QoE / RVQoE / iRVQoE reporting to the RAN or the core network may be performed  at the same time or at different times. However, the individual RVQoE may have a flexible / configurable option to refer to the core network configured QoE so as to impute the QoE configuration as part of the individual RVQoE configuration. Further details of such a mechanism and various implementations are provided below.

[0035] In some further example implementations, the timing of the QoE, RVQoE, or iRVQoE reporting may be configured separately or collectively. For example, event-triggered QoE, RVQoE, or iRVQoE reporting may be employed. Configuration related to such event-triggered reporting of the QoE, RVQoE, or individual RVQoE may be provided from the network to the UE in order to control the timing of the QoE reporting. The QoE reporting can thus be made adaptive and may be generated and transmitted by the UE as needed according to the configured triggering events, rather than being constantly or periodically transmitted.

[0036] Event Triggered QoE / RVQoE

[0037] In some example implementations, a QoE and / or RVQoE and / or individual RVQoE (QoE / RVQoE / iRVQoE) report from the UE to the network (either the core network or the RAN) may only be event-triggered in one of two non-limiting example ways (1) a transmission of the QoE / RVQoE / iRVQoE report may be triggered when a configured event occurs, or (2) a stoppage of a QoE or RVQoE or individual RVQoE transmission may be triggered when a configured event occurs.

[0038] In some example implementations, an information element may be defined for specifying the QoE / RVQoE / iRVQoE reporting functions, including how the QoE / RVQoE / iRVQoE reporting is triggered by various events. Such an IE may be carried in any type of messages, including but not limited RRC messages, MAC IE, and the like, as persistent, semi-persistent, or dynamic configurations. Such an IE may originate from the core network or the RAN. Such an information element may form a portion of a specific message for configuring the event triggered QoE / RVQoE / iRVQoE reporting. Alternatively, such an information element may be included in a message that also contains one or more other IEs of the QoS configuration.

[0039] As such, a mechanism of event triggered QoE / RVQoE / iRVQoE reporting may be introduced and configured, and may be followed by the UE in performing  QoE / RVQoE / iRVQoE functions. For example, the QoE / RVQoE / iRVQoE reporting may not be started until a configured event occurs. Before the occurrence of a triggering event, the UE may either store the QoE / RVQoE / iRVQoE measurement report locally or simply release the QoE / RVQoE / iRVQoE measurement report.

[0040] Additionally, or alternatively, the event triggered QoE / RVQoE / iRVQoE reporting mechanism may also be used to cease an ongoing reporting. For example, the QoE / RVQoE / iRVQoE reporting may be performed normally before the configured event (s) occurs and upon an occurrence of the configured event (s) , the QoE / RVQoE / iRVQoE reporting may stop.

[0041] This configuration IE for such event triggered QoE / RVQoE / iRVQoE reporting may include at least one of the following information items:

[0042] ● Event information: This indicates to the UE of the trigger events or type of triggering events. When the configured event occurs, UE shall start transmitting the QoE / RVQoE / iRVQoE report accordingly. At least one of the following events or event types may be used for such triggering QoE and may be contained in this field:

[0043] ○ Handover: When UE preforms a handover, QoE / RVQoE / iRVQoE reporting shall be started or stopped.

[0044] ○ Command for Pause / resume QoE reporting: When UE receives a command or control message for pausing / resuming QoE / RVQoE / iRVQoE reporting information, the QoE / RVQoE / iRVQoE reporting shall be started or stopped.

[0045] ○ Dual Connect (DC) status change: When UE DC status changes (e.g., the UE connectivity status changes between standalone and DC) , QoE / RVQoE / iRVQoE reporting shall be started or stopped.

[0046] ○ Network change: When UE switch its NW types, e.g., from Non-Terrestrial Network (NTN) to Terrestrial (TN) or from TN to NTN, QoE / RVQoE / iRVQoE reporting shall be started or stopped.

[0047] ○ UE workload level or level change: when the UE workload is lower than a threshold or higher than a threshold, QoE / RVQoE / iRVQoE reporting shall be started or stopped, respectively. the thresholds may be either a specific value which may be configured explicitly by the network or a common or predefined value which need not be defined or configured by the network

[0048] ○ UE battery state change or UE battery level: when the UE battery status is lower than a threshold or higher than a threshold, QoE / RVQoE / iRVQoE reporting shall be started or stopped, respectively. the thresholds above may be either a specific value which may be configured explicitly by the network or a common or predefined value which need not be defined or configured by the network.

[0049] (The triggering of the QoE / RVQoE / iRVQoE reporting may be at an onset of or at a completion or other time point of the above events, which may be further configured) .

[0050] ● Event controlled reporting: This indicates or specifies whether QoE / RVQoE / iRVQoE reporting shall be controlled based on the event information above. This may, for example, be implemented as a binary flag or indicator.

[0051] Stop reporting or start reporting info: This information may be used to specify or indicate how to use the configured event (s) . For example, whether the configured events information above is for triggering reporting or for stopping reporting of the QoE / RVQoE / iRVQoE. This may, for example, be implemented as a binary flag or indicator.

[0052] Individual RVQoE (iRVQoE) Configuration and Reporting

[0053] As described above, a mechanism for iRVQoE configuration and reporting may be provided in addition to QoE and regular RVQoE configuration and reporting. Such iRVQoE reporting may not need to involve the core network while it can be configured by the core network and / or be linked to regular QoE configuration. In other words, while iRVQoE may not need to rely on any core network configured QoE, a configuration for individual RVQoE by the RAN may still be flexibly configured to refer to another core network configured QoE in order to reuse measurements and contents of QoE reporting to the core network in the individual RVQoE to the RAN. For example, a QoE and / or an RVQoE may be configured by the  network and an iRVQoE may be configured by the RAN or by the core network at the same time. Any one or more of the QoE / RVQoE / iRVQoE reporting to the RAN or the core network may be performed at the same time or different times. The iRVQoE may have a configurable option to refer the core network configured QoE so as to impute the QoE configuration as part of the iRVQoE configuration. Further details of such a mechanism and implementations are provided below. When a UE receives such individual RVQoE configuration, the UE may keep the configuration and start measuring / reporting RVQoE data when the UE fulfills the measurement requirement.

[0054] As such, iRVQoE may be flexibly configured to depend on or may be independent of the core network QoE configuration. iRVQoE may be directly configured by the RAN and can also be configured from the core network. An iRVQoE that does not involve the core network and core network configured QoE may be referred to as independent iRVQoE. The configuration of iRVQoE is nevertheless considered as independent from QoE configuration in that it does not need the QoE configuration to function (even though it may or may not link to a QoE configuration) .

[0055] In some example implementations, at least one of the following information or information items may be included in the iRVQoE configuration:

[0056] ● RVQoE ID: This may be used to identify the iRVQoE configuration.

[0057] ● QoE ID: This is optional and may be used to identify an QoE configuration. If RVQoE is linked to the QoE configuration, the identified QoE configuration may be referred to in order to avoid any duplicated measurement. The NW may configure the QoE ID associated with this iRVQoE configuration.

[0058] ● RVQoE metric configuration: This may be used to specify or indicate which QoE metric shall be measured and reported for the iRVQoE. Such RVQoE metric configuration may indicated at least one of the following metrics to measure: corruption duration metric; successive loss of RTP packets, frame rate, jitter duration, sync loss duration, round-trip time, average codec bitrate, codec information, call setup time, representation switch events, average throughput, initial playout delay, buffer level, play list, Media Presentation Descriptor (MPD) information, playout delay for media start-up, device information, comparable  quality viewport switching latency, rendered viewports, Virtual Reality (VR) device information.

[0059] ● Area scope information item: This may be used to indicate the area scope information for this iRVQoE. UE may measure and / or report the iRVQoE data only when UE is inside this area scope. The area scope information item may indicate one or more of the following:

[0060] ○ Cell ID info: This may contain one or multiple cell ID.

[0061] ○ Tracking Area (TA) info: This may contain one or multiple TA.

[0062] ○ TA ID (TAI) info: This may contain one or multiple TAIs.

[0063] ○ Public Land Mobile Network (PLMN) information: This may contain one or multiple PLMNs.

[0064] ● Slicing information item: This may be used to configure the network slicing information for the iRVQoE. The iRVQoE measurement and / or reporting may be started or enabled if the UE receives data via configured NW slice.

[0065] ● RVQoE measurement status: This may be used to indicate the RVQoE measurement status. At least one of the following information items may be included:

[0066] ○ Ongoing: this indicates that the RVQoE measurement is starting.

[0067] ○ Paused measurement: this indicates that the RVQoE measurement is paused.

[0068] ○ Paused reporting: this indicates that the RVQoE reporting is paused.

[0069] ○ Out of area scope: This indicates that this UE is outside the area scope.

[0070] ● Service type information item: This indicates the service type information corresponding to this iRVQoE. RVQoE measurement and / or reporting may be started or enabled if the UE is receiving such type of user data. At least one of the following service types may be indicated:

[0071] ○ Dynamic Adaptive Streaming over HTML (DASH) , (Multimedia Telephony Service for IMS (MTSI) , Virtual Reality (VR) , sidelink, Aircraft to Anything (A2X) , Vehicle to anything (V2X) , eXtended Reality (XR) , Augmented Reality (AR) , Mixed Reality (MR) , and the like.

[0072] ● UE types information item: this indicates the UE types for this iRVQoE. The RVQoE measurement and / or reporting may be started or enabled if the UE is of the  indicated UE type. The UE types may include at least one of: IoT, IIoT, aerial UE, Redcap, aerial-liked UE, common UE, and the like.

[0073] ● Communication service type information item: This indicates the communication service type requirement for this iRVQoE. This iRVQoE may be enabled or allowed if the required service type data is transmitted via this specific communication service type. At least one of the following service types may be indicated: Multicast, broadcast, sidelink, A2X, V2X, NTN, Non-Public Network (NPN) , etc.

[0074] ● Minimization of Drive Tests (MDT) alignment information item: this is used to indicate which MDT is aligned with this iRVQoE. For example, one or multiple trace ID may be indicated.

[0075] ● Priority information item: This indicates the priority information for this iRVQoE configuration.

[0076] ● RVQoE reporting path: This indicates which path the UE shall use for this iRVQoE reporting. At least one of the following paths may be indicated: SRB4 or SRB5 (SRB stands for Signaling Radio Bearer)

[0077] ● Service area for NPN:

[0078] ○ Equivalent Standard NPN (SNPN) information item: a list of equivalent SNPNs may be configured within the iRVQoE configuration. The iRVQoE may be triggered or triggerable by a UE if UE is using the service announced in the RVQoE configuration by using one of the equivalent SNPNs shown in this information.

[0079] ○ Allowed Public Network Integrated NPN (PNI-NPN) information: a list of PNI-NPNs may be configured within the iRVQoE configuration. The iRVQoE may be triggered or triggerable by a UE if UE is using the service announced in the iRVQoE configuration by using one of the PNI-NPN indicated in this information item.

[0080] ● Service area for NTN: NW may configure additional service area configuration for iRVQoE in NTN. The iRVQoE may be triggered if UE is inside the configured service area. When UE moves out of the configured service area, UE may keep the ongoing iRVQoE and stop triggering RVQoE measurement. It is also possible for  UE to stop all the RVQoE measurements when this UE moves out of the configured service area. Information items that may be indicated for Service area NTN are separated described below.

[0081] ● Further NTN Radio Access Technology (RAT) restriction information item:

[0082] Further detailed information on NTN may be configured to iRVQoE. A UE with such iRVQoE configuration may trigger the RVQoE measurement if the NTN used by this UE fulfills the requirement in this configuration information item. At least one of the following RAT information may be indicated in this information items: E-UTRA, NR, NR-unlicensed, Very Low Earth Orbit (VLEO) , Low Earth Orbit (LEO) , Medium Earch Orbit (MEO) , GEosynchronous Orbit (GE) O, GeoStationary Orbit (GSO) , Non-GeoStationary Orbit (NGSO) , Other satellite, or Other orbits. NW may use at least one of the following IEs to configure this information item:

[0083] ○ Bitmap / BitString with multiple bits: each bit in the bitmap represents one RAT information shown above. The bit map indicates which RATs are configured.

[0084] ○ Enumerated IE with multiple codepoints where each codepoints represents one of the RATs above.

[0085] ○ For each different RATs above, NW may use several IEs for this configuration.

[0086] Each different IEs represents one specific RAT.

[0087] iRVQoE Service Area for NTN

[0088] In some example implementation, for the above IE for service area for NTN in the iRVQoE configuration, at least one of the following service area related information fields may be included:

[0089] ● Positioning defined area information list,

[0090] ● Positioning based area information list,

[0091] ● Cell based area information list,

[0092] ● TAI based area information list,

[0093] ● Area Counting information,

[0094] ● Mapped cell ID information,

[0095] ● Mapping information,

[0096] ● Administrative region information.

[0097] These lists and information related to service area are explained in further detail below.

[0098] The Positioning defined area information list, for example, includes at least one positioning defined area.

[0099] The Positioning based area information list may include at least one positioning based area information item. Each positioning based area information item, may include a Positioning Defined Area and at least one of: cell information List containing least one Cell ID, and a TAI information List containing at least one TAI.

[0100] The Cell based area information list may include at least one cell based area information item. Each cell based area information item may include a cell ID and a positioning defined area information list.

[0101] The TAI based area information list may include at least one TAI based area information item. Each TAI based area information item, may include a TAI and a positioning defined area information list.

[0102] The Area Counting information, in some example implementations, may include both cell information and positioning defined area information, and if so, at least one of the following rules may be applied to account for service area:

[0103] ● Final service area is obtained as the intersection of the cell information and positioning defined area information.

[0104] ● Final service area is obtained as the union set of the cell information and positioning defined area information.

[0105] ● Final service area is obtained as the cell area minus positioning defined area information.

[0106] ● Final service is obtained as the positioning defined area information minus cell area.

[0107] The Area Counting information, in some other example implementations, may include both TAI information and positioning defined area information, and if so, at least one of the following rules may be applied for account for service area:

[0108] ● Final service area is obtained as the intersection of the TAI information and  positioning defined area information.

[0109] ● Final service area is obtained as the union set of the TAI information and positioning defined area information.

[0110] ● Final service area is obtained as the TAI area minus positioning defined area information.

[0111] ● Final service is the positioning defined area information minus TAI area.

[0112] The Area Counting information, in some other example implementation may include both cell information, TAI information and positioning defined area information, and if so, at least one of the following rules may be applied:

[0113] ● Final service area is obtained as the intersection of all these three aspects.

[0114] ● Final service area is obtained as the intersection of positioning defined area information and either of TAI or cell info.

[0115] ● Final service area is obtained as the union set of the TAI information and cell information and positioning defined area information.

[0116] ● Final service area is obtained as the TAI area minus positioning defined area information.

[0117] ● Final service is obtained as the positioning defined area information minus TAI area.

[0118] This information or information item (the Area Counting information) may be either explicitly transmitted as an IE in the messages with the area information, or may only have stage 2 description without detail IE transmission, or just based on implementation in the system.

[0119] The Mapped cell ID information may include at least one of the mapped cell ID. The mapped cell ID may be defined in NR NTN field or information item.

[0120] The Mapping information may indicate mapping relationship between the mapped cell ID and the specific area information. The format of the specific area information may be either cell information or TAI information or positioning defined area information. For example, this information item or field may be provided from CN to UE via gNB, or CN to gNB as an explicit IE. In some examples, this information may also be provided from OAM to gNB and / or UE.

[0121] The Administrative region information informs administrative region related information. Different granularity may be applied for this information (e.g., National based area, province based area, city based area, village based area, street based area, building based area, etc. ) . Administrative region IDs may be used to distinguish different administrative areas. At least one of the following alternatives may be included in this information: (1) the Administrative region IDs list containing at least one administrative region ID, (2) cell based administrative region information list including at least one Cell based administrative region information item. Each Cell based administrative region information item may include a cell ID and an administrative region ID list.

[0122] The TAI based administrative region information list may include at least one TAI based administrative region information item. Each TAI based administrative region information item may include a TAI and an administrative region ID list.

[0123] QoE / RVQoE / iRVQoE Configuration Procedures

[0124] An example messaging procedure for transmitting the QoE / RVQoE / iRVQoE configuration above is shown in FIG. 5 and is described in further detail below. In this example procedure, the QoE / RVQoE / iRVQoE configuration may originate from the core network (CN) and may be transmitted to the UE via a RAN node.

[0125] As shown in FIG. 5, in Step 1, for signaling based QoE / RVQoE / iRVQoE, the CN transmits, for example, a Next-Generation Application Protocol (NGAP) message 1 to the RAN node for QoE / RVQoE / iRVQoE configuration. This message may be either a new defined NGAP message or existing ones and may include one or more QoE / RVQoE / iRVQoE configurations. Each of the QoE / RVQoE / iRVQoE configurations may include at least one of a QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE configuration (e.g., the event triggering configuration) .

[0126] In Step 2 of FIG. 5, for signaling based QoE / RVQoE / iRVQoE, the RAN node receives the NGAP message 1 and stores the QoE / RVQoE / iRVQoE configuration. The RAN node may respond with NGAP message 2 to the CN. This message may be either a newly defined NGAP message or an existing one. Alternatively, for management based  QoE / RVQoE / iRVQoE, the OAM may transmit an OAM message to the RAN node with the QoE / RVQoE / iRVQoE configuration. The NGAP message 2 or the OAM message may include the one or more QoE and / or individual RVQoE QoE / RVQoE / iRVQoE configurations. Each of the QoE / RVQoE / iRVQoE configurations may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE configuration (e.g., the event triggering configuration) .

[0127] In Step 3, the RAN node may select proper UEs based on the received the various information items described above for the QoE / RVQoE / iRVQoE configuration (e.g., the event triggering configuration) .

[0128] In Step 4, the RAN node may transmit the QoE / RVQoE / iRVQoE configurations to the identified UEs via, for example, RRC message 1. This message may be based on either a newly defined RRC message or an existing one. This message may include an QoE and / or individual RVQoE QoE / RVQoE / iRVQoE configuration for a UE, which may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE configuration (e.g., the event triggering configuration) .

[0129] Another example messaging procedure for transmitting the QoE / RVQoE / iRVQoE configuration above is shown in FIG. 6 and is described in further detail below. In this example procedure, the QoE / RVQoE / iRVQoE configuration may be transmitted from CU to a DU of a base station.

[0130] As shown in FIG. 6, in Step 1, the CU may transmit the QoE / RVQoE / iRVQoE configuration to the DU via F1AP message A. This message may be based on either a newly defined F1AP message or an existing one. This message may include the QoE / RVQoE / iRVQoE E configuration, which may include at least one of at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE configuration (e.g., the event triggering configuration) .

[0131] In Step 2, the DU receives the F1AP message A and keeps the received information  from the message. The DU may respond to the CU with F1AP message B. This message may be based on either a newly defined F1AP message or an existing one.

[0132] Another example messaging procedure for QoE / RVQoE / iRVQoE reporting is shown in FIG. 7 and is described in further detail below. In this example procedure, the QoE / RVQoE / iRVQoE reporting may be transmitted from the UE to the RAN node and then to an Measurement Collector Entity (MCE) .

[0133] As shown in FIG. 7, in Step 1, the UE may start QoE / RVQoE / iRVQoE reporting according to the corresponding configuration and transmits RRC message 1 to the RAN node. This message may be based on either a newly defined RRC message or an existing one. This message may include one or more QoE / RVQoE / iRVQoE reports. Each of the reports may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE reporting.

[0134] In Step 2, the RAN node receives the QoE / RVQoE / iRVQoE reports and transmits non-standardized message with the reports to the MCE. This message may include the QoE / RVQoE / iRVQoE reports. Each of the reports may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE E reporting.

[0135] QoE / RVQoE / iRVQoE Configuration / Reporting Procedures During Mobility

[0136] An example messaging procedure for transmitting the QoE / RVQoE / iRVQoE information during a handover process is shown in FIG. 8 and is described in further detail below. In this example procedure, the QoE / RVQoE / iRVQoE information may transmitted from a source RAN node to a target RAN node upon request from the target node during handover.

[0137] As shown in FIG. 8, in Step 1, the target node may send an XnAP message 1 to the source node.

[0138] In Step 2, the source node may respond to the target node with XnAP message 2. The XnAP message 2 may be either new defined message or an existing one (such as S-Node Addition Request Acknowledgement message, S-Node Modification Request  Acknowledgement message, S-Node Modification Confirm message, Retrieve UE Context Response message, and the like) . This message may include QoE / RVQoE / iRVQoE information such as QoE / RVQoE / iRVQoE configurations. Each QoE / RVQoE / iRVQoE configuration may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for QoE / RVQoE / iRVQoE (e.g., the event triggering configuration) .

[0139] Another example messaging procedure for transmitting the QoE / RVQoE / iRVQoE information during a handover process is shown in FIG. 9 and is described in further detail below. In this example procedure, the QoE / RVQoE / iRVQoE information may be sent from from a source RAN node to a target RAN node directly during handover.

[0140] As shown in FIG. 9, in Step 1, the source ode may send an XnAP message 1 to the target node. The XnAP message 1 may be either newly defined message or an existing one (such as Handover request message, S-Node Addition request message, S-Node Modification Request message, S-Node Modification Required message, and the like) . This message may include QoE / RVQoE / iRVQoE information such as QoE / RVQoE / iRVQoE configurations. Each of the QoE / RVQoE / iRVQoE configurations may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE / RVQoE / iRVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoEv (e.g., the event triggering configuration) .

[0141] In Step 2, the target node receives the XnAP message 1 and stores the received QoE / RVQoE / iRVQoE information into UE context. The target node may further respond to the source node with XnAP message 2.

[0142] Another example messaging procedure for transmitting the QoE / RVQoE / iRVQoE information during an NG based handover process is shown in FIG. 10 and is described in further detail below. In this example procedure, the QoE / RVQoE / iRVQoE information may be sent from a source NG RAN node to a target NG RAN node via the core network during a NG based handover.

[0143] In some example implementations, the messaging procedure of FIG. 10 may be applied to handover procedure of various types, including but not limited to intra-system  intra-RAT handover between gNBs, intra-system intra-RAT handover between ng-eNBs, intra-system inter-RAT handover from source gNB to target ng-eNB, and intra-system inter-RAT handover from source ng-eNB to target gNB.

[0144] Specifically, as shown in Step 1 of FIG. 10, the source node may trigger the NG based handover by sending an NGAP message 1 (e.g., a Handover required message) to the core network. In Step 2, the core network may send an NGAP message 2 (e.g., a Handover Request message) to the target node. These messages may include QoE / RVQoE / iRVQoE configurations. Each of the QoE / RVQoE / iRVQoE configurations may include at least one of the QoE / RVQoE / iRVQoE ID for identifying the QoE and / or individual RVQoE configuration, and the various information items described above for the QoE / RVQoE / iRVQoE (e.g., the event triggering configuration) . In Step 3, after target node receives the QoE / RVQoE / iRVQoE information, it may response with an NGAP message 3 (e.g., a Handover Request ACK message) to the core network. In Step 4, the core network may respond with an NGAP message 4 (e.g., a Handover Command) .

[0145] The disclosure above thus provides at least the following example implementations.

[0146] In some example implementations, a method performed by a user equipment (UE) in a wireless network is disclosed. The method may include receiving configuration information from the wireless network, the configuration information being associated with Quality of Experience (QoE) reporting and specifying an event-triggering mechanism for the UE to transmit QoE reports; generating a QoE report; and transmitting the QoE report according to the event-triggering mechanism.

[0147] In the example implementations above, the configuration information comprises at least one of: event information to specify triggering events or event types for the QoE reporting; a flag for indicating whether the event-triggering mechanism is applied; a triggering mode specifying whether the QoE report is started or stopped by the triggering events or event types.

[0148] In any one of the example implementations above, the event information specifies that the triggering events or event types comprise at least one of: a handover of the UE; a reception of a command of the UE for pausing / resuming the QoE reporting; dual connectivity status change of the UE; network type switch by the UE; workload level of the UE being in or  out of a predefined or configured workload range; UE battery state change; and UE battery level being in or out of a predefined or configured battery level range.

[0149] In any one of the example implementations above, the QoE reporting may be configured as one of: a core network terminated and Radio Access Network (RAN) invisible QoE reporting configured by a core network of the wireless network; a core network terminated but RAN visible QoE (RVQoE) reporting configured by the core network or a RAN relying on and being linked to a sperate QoE reporting configuration; and a RAN terminated individual RVQoE (iRVQoE) reporting configured by the RAN.

[0150] In any one of the example implementations above, the configuration information is received from a RAN node via an RRC message after being received by the RAN node from a core network via an NGAP message. network via an RNA node an RRC message.

[0151] In any one of the example implementations above, the configuration information is received from distributed unit (DU) of a RAN after being received by the DU from central unit (CU) of the RAN via an F1AP message.

[0152] In any one of the example implementations above, the QoE report is transmitted to a RAN node via an RRC message followed by the QoE report being transmitted by the RAN node to a Measurement Collector Entity (MCE) .

[0153] In any one of the example implementations above, the configuration information is received from a source RAN node after being transmitted from a target RAN node to the source RAN node via an XnAP message in a handover process.

[0154] In any one of the example implementations above, the configuration information is transmitted from the target RAN node to the source RAN node after the target RAN node receives an QoE configuration request from the source RAN node via another XnAP message in a handover process.

[0155] In any one of the example implementations above, the configuration information is received from a source RAN node after being received by the source RAN node from a target RAN node via a core network in an NG based handover process.

[0156] In some other example implementations, another method performed by a user  equipment (UE) in a wireless network is disclosed. The method may include receiving an individual RAN Visible Quality of Experience (iRVQoE) configuration information from the wireless network, the iRVQoE configuration information being provided from the network to configure an RVQoE reporting from the UE to a RAN regardless of existence of any other Quality of Experience (QoE) configurations; generating an iRVQoE report according to the iRVQoE configuration information; and transmitting the iRVQoE report to the RAN.

[0157] In the example implementations above, the iRVQoE configuration information comprises one or more of: an ID to identify the iRVQoE configuration information; a QoE ID to identify another QoE configuration to link the iRVQoE configuration information to; an iRVQoE metric configuration to specify QoE metrics to be measured for the iRVQoE report; an area scope information item for the iRVQoE report; a slicing information item to indicate a scope of network slices for the iRVQoE report; iRVQoE measurement status; a service type information item for indicating service types governed by the iRVQoE configuration information; a UE type information item for indicating UE types governed by the iRVQoE configuration information; a communication service type information item for indicating service types governed by the iRVQoE configuration information; a minimization of drive tests (MDT) alignment information item; a priority information item; an iRVQoE reporting path; an indication of service area for Non-Public Network (NPN) ; an indication of service area for Non-Terrestrial Network (NTN) ; and NTN Radio Access Technology (RAT) restriction.

[0158] In any one of the example implementations above, the iRVQoE metric configuration comprises at least one of a corruption duration metric, successive loss of RTP packets, frame rate, jitter duration, sync loss duration, round-trip time, average codec bitrate, codec information, call setup time, representation switch events, average throughput, initial playout delay, buffer level, play list, Media Presentation Descriptor (MPD) information, playout delay for media start-up, device information, comparable quality viewport switching latency, rendered viewports, or Virtual Reality (VR) device information.

[0159] In any one of the example implementations above, the area scope information indicates areas where the iRVQoE report is transmitted.

[0160] In any one of the example implementations above, the iRVQoE measurement status  comprises at least one of: ongoing, indicating that the iRVQoE report is starting; paused measurement, indicating that that iRVQoE measurement is paused; paused reporting, indicating that that the iRVQoE reporting is paused; or out of areas scope, indicating that the UE is out of the area scope.

[0161] In any one of the example implementations above, the service type information item indicates at least one of: Dynamic Adaptive Streaming over HTML (DASH) , Multimedia Telephony Service for IMS (MTSI) , Virtual Reality (VR) , sidelink, Aircraft to Anything (A2X) , Vehicle to anything (V2X) , eXtended Reality (XR) , Augmented Reality (AR) , or Mixed Reality (MR) .

[0162] In any one of the example implementations above, the UE type information indicates at least one of: IoT, IIoT, aerial UE, Redcap, aerial-liked UE, or common UE.

[0163] In any one of the example implementations above, the communication service type information item indicates at least one of: Multicast, broadcast, sidelink, Airborne to anything (A2X) , vehicle to anything (V2X) , Non-terrestrial Network (NTN) service, or Non-Public Network (NPN) service.

[0164] In any one of the example implementations above, the iRVQoE reporting path indicate at least one of: Signaling Radio Barrier 4 (SRB4) or SRB5.

[0165] In any one of the example implementations above, the indication of service area for NPN indicates an equivalent Standard Non-Public-Network (SNPN) information and allowed Public Network Integrated NPN (PNI-NPN) information.

[0166] In any one of the example implementations above, the indication of service area of NTN indicates at least one of: positioning defined area information list; positioning based area information list; cell based area information list; TAI based area information list; area counting information; mapped cell ID information; mapping information; or administrative region information.

[0167] In any one of the example implementations above, the area counting information comprises a cell area and a positioning defined area, and a final service area is obtained as: an intersection of the cell area and the positioning defined area; a union of the cell area and the  positioning defined area; the cell area minus the positioning defined area; or the positioning defined area minus the cell area.

[0168] In any one of the example implementations above, the area counting information comprises a TAI area and a positioning defined area, and a final service area is obtained as: an intersection of the TAI area and the positioning defined area; a union of the TAI area and the positioning defined area; the TAI area minus the positioning defined area; or the positioning defined area minus the TAI area.

[0169] In any one of the example implementations above, the area counting information comprises a cell area, a TAI area and a positioning defined area, and a final service area is obtained as: an intersection of the cell area, the TAI area and the positioning defined area; an intersection of the positioning defined area with either of the cell area or the TAI area; a union of the cell area, the TAI area and the positioning defined area; the TAI area minus the positioning defined area; or the positioning defined area minus the TAI area.

[0170] In any one of the example implementations above, the iRVQoE configuration information is received from a RAN node via an RRC message after being received by the RAN node from a core network via an NGAP message. network via an RNA node an RRC message.

[0171] In any one of the example implementations above, the iRVQoE configuration information is received from distributed unit (DU) of a RAN after being received by the DU from central unit (CU) of the RAN via an F1AP message.

[0172] In any one of the example implementations above, the iRVQoE report is transmitted to a RAN node via an RRC message followed by the iRVQoE report being transmitted by the RAN node to a Measurement Collector Entity (MCE) .

[0173] In any one of the example implementations above, the iRVQoE configuration information is received from a source RAN node after being transmitted from a target RAN node to the source RAN node via an XnAP message in a handover process.

[0174] In any one of the example implementations above, wherein the iRVQoE configuration information is transmitted from the target RAN node to the source RAN node after the target RAN node receives an iRVQoE configuration request from the source RAN  node via another XnAP message in a handover process.

[0175] In any one of the example implementations above, the iRVQoE configuration information is received from a source RAN node after being received by the source RAN node from a target RAN node via a core network in an NG based handover process.

[0176] In some other example implementations, a method performed by a wireless network node (e.g., a radio access network node or a core network node) is disclosed. The method may include one or more counterpart steps performed in the UE in any one of the example implementations above.

[0177] Specifically, in some example implementations, a method performed by a network node in a wireless network is disclosed. The method may include transmitting configuration information to a User Equipment (UE) , the configuration information being associated with Quality of Experience (QoE) reporting and specifying an event-triggering mechanism for the UE to transmit QoE reports; and receiving a QoE report transmitted by the UE, the QoE report being generated and transmitted by the UE according to the event-triggering mechanism.

[0178] In the example implementations above, the configuration information comprises at least one of: event information to specify triggering events or event types for the QoE reporting; a flag for indicating whether the event-triggering mechanism is applied; a triggering mode specifying whether the QoE report is started or stopped by the triggering events or event types.

[0179] In any one of the example implementations above, the event information specifies that the triggering events or event types comprise at least one of: a handover of the UE; a reception of a command of the UE for pausing / resuming the QoE reporting; dual connectivity status change of the UE; network type switch by the UE; workload level of the UE being in or out of a predefined or configured workload range; UE battery state change; and UE battery level being in or out of a predefined or configured battery level range.

[0180] In any one of the example implementations above, the QoE report may be configured as one of: a core network terminated and Radio Access Network (RAN) invisible QoE reporting configured by a core network of the wireless network; a core network terminated but RAN visible QoE (RVQoE) reporting configured by the core network or a RAN relying on  and being linked to a sperate QoE reporting configuration; and a RAN terminated individual RVQoE (iRVQoE) reporting configured by the RAN.

[0181] In any one of the example implementations above, the network node comprises a RAN node and the configuration information is transmitted to the UE via an RRC message after being received by the RAN node from a core network via an NGAP message. network via an RNA node an RRC message.

[0182] In any one of the example implementations above, the configuration information is transmitted by a distributed unit (DU) of a RAN to the UE after being received by the DU from central unit (CU) of the RAN via an F1AP message.

[0183] In any one of the example implementations above, the network node comprises a RAN node and the QoE report is transmitted from the UE to the RAN node via an RRC message followed by the QoE report being transmitted by the RAN node to a Measurement Collector Entity (MCE) .

[0184] In any one of the example implementations above, the network node comprises a source RAN node and the configuration information is transmitted from the source RAN node to the UE after being transmitted from a target RAN node to the source RAN node via an XnAP message in a handover process of the UE.

[0185] In any one of the example implementations above, the configuration information is transmitted from the target RAN node to the source RAN node after the target RAN node receives an QoE configuration request from the source RAN node via another XnAP message in a handover process of the UE.

[0186] In any one of the example implementations above, the network node comprises a source RAN node and the configuration information is received from the source RAN node after being received by the source RAN node from a target RAN node via a core network in an NG based handover process of the UE.

[0187] In some other example implementations, a method performed by a network node in a wireless network is disclosed. The method may include transmitting an individual RAN Visible Quality of Experience (iRVQoE) configuration information to a User Equipment (UE) , the  iRVQoE configuration information being provided from the wireless network to configure an RVQoE reporting from the UE to a RAN regardless of existence of any other Quality of Experience (QoE) configurations; and receiving an iRVQoE report from the UE, the iRVQoE report being generated and transmitted by the UE according to the iRVQoE configuration information.

[0188] In the example implementations above, the iRVQoE configuration information comprises one or more of: an ID to identify the iRVQoE configuration information; a QoE ID to identify another QoE configuration to link the iRVQoE configuration information to; an iRVQoE metric configuration to specify QoE metrics to be measured for the iRVQoE report; an area scope information item for the iRVQoE report; a slicing information item to indicate a scope of network slices for the iRVQoE report; iRVQoE measurement status; a service type information item for indicating service types governed by the iRVQoE configuration information; a UE type information item for indicating UE types governed by the iRVQoE configuration information; a communication service type information item for indicating service types governed by the iRVQoE configuration information; a minimization of drive tests (MDT) alignment information item; a priority information item; an iRVQoE reporting path; an indication of service area for Non-Public Network (NPN) ; an indication of service area for Non-Terrestrial Network (NTN) ; and NTN Radio Access Technology (RAT) restriction.

[0189] In any one of the example implementations above, the iRVQoE metric configuration comprises at least one of a corruption duration metric, successive loss of RTP packets, frame rate, jitter duration, sync loss duration, round-trip time, average codec bitrate, codec information, call setup time, representation switch events, average throughput, initial playout delay, buffer level, play list, Media Presentation Descriptor (MPD) information, playout delay for media start-up, device information, comparable quality viewport switching latency, rendered viewports, or Virtual Reality (VR) device information.

[0190] In any one of the example implementations above, the area scope information indicates areas where the iRVQoE report is transmitted.

[0191] In any one of the example implementations above, the iRVQoE measurement status comprises at least one of: ongoing, indicating that the iRVQoE report is starting; paused  measurement, indicating that that iRVQoE measurement is paused; paused reporting, indicating that that the iRVQoE reporting is paused; or out of areas scope, indicating that the UE is out of the area scope.

[0192] In any one of the example implementations above, the service type information item indicates at least one of: Dynamic Adaptive Streaming over HTML (DASH) , Multimedia Telephony Service for IMS (MTSI) , Virtual Reality (VR) , sidelink, Aircraft to Anything (A2X) , Vehicle to anything (V2X) , eXtended Reality (XR) , Augmented Reality (AR) , or Mixed Reality (MR) .

[0193] In any one of the example implementations above, the UE type information indicates at least one of: IoT, IIoT, aerial UE, Redcap, aerial-liked UE, or common UE.

[0194] In any one of the example implementations above, the communication service type information item indicates at least one of: Multicast, broadcast, sidelink, Airborne to anything (A2X) , vehicle to anything (V2X) , Non-terrestrial Network (NTN) service, or Non-Public Network (NPN) service.

[0195] In any one of the example implementations above, the iRVQoE reporting path indicate at least one of: Signaling Radio Barrier 4 (SRB4) or SRB5.

[0196] In any one of the example implementations above, the indication of service area for NPN indicates an equivalent Standard Non-Public-Network (SNPN) information and allowed Public Network Integrated NPN (PNI-NPN) information.

[0197] In any one of the example implementations above, the indication of service area of NTN indicates at least one of: positioning defined area information list; positioning based area information list; cell based area information list; TAI based area information list; area counting information; mapped cell ID information; mapping information; or administrative region information.

[0198] In any one of the example implementations above, the area counting information comprises a cell area and a positioning defined area, and a final service area is obtained as: an intersection of the cell area and the positioning defined area; a union of the cell area and the positioning defined area; the cell area minus the positioning defined area; or the positioning  defined area minus the cell area.

[0199] In any one of the example implementations above, the area counting information comprises a TAI area and a positioning defined area, and a final service area is obtained as: an intersection of the TAI area and the positioning defined area; a union of the TAI area and the positioning defined area; the TAI area minus the positioning defined area; or the positioning defined area minus the TAI area.

[0200] In any one of the example implementations above, the area counting information comprises a cell area, a TAI area and a positioning defined area, and a final service area is obtained as: an intersection of the cell area, the TAI area and the positioning defined area; an intersection of the positioning defined area with either of the cell area or the TAI area; a union o the cell area, the TAI area and the positioning defined area; the TAI area minus the positioning defined area; or the positioning defined area minus the TAI area.

[0201] In any one of the example implementations above, the network node comprises a RAN node and the iRVQoE configuration information transmitted to the UE by the RAN node via an RRC message after being received by the RAN node from a core network via an NGAP message.

[0202] 56. The method of claim 41, wherein the iRVQoE configuration information is transmitted from a distributed unit (DU) of a RAN to the UE after being received by the DU from central unit (CU) of the RAN via an F1AP message.

[0203] In any one of the example implementations above, the network node comprises a RAN node the iRVQoE report is received by the RAN node from the UE via an RRC message followed by the iRVQoE report being transmitted by the RAN node to a Measurement Collector Entity (MCE) .

[0204] In any one of the example implementations above, the network node comprises a source RAN node and the iRVQoE configuration information is transmitted by the source RAN node to the UE after being transmitted from a target RAN node to the source RAN node via an XnAP message in a handover process of the UE.

[0205] In any one of the example implementations above, the iRVQoE configuration  information is transmitted from the target RAN node to the source RAN node after the target RAN node receives an iRVQoE configuration request from the source RAN node via another XnAP message in a handover process of the UE.

[0206] In any one of the example implementations above, the network node comprises a source RAN node and the iRVQoE configuration information is transmitted by the source RAN node to the UE after being received by the source RAN node from a target RAN node via a core network in an NG based handover process of the UE.

[0207] In some other implementations, the UE or the network node above is disclosed. The UE or the network node may include at least one processor and a memory, wherein the at least one processor is configured to read code from the memory and implement any one of the methods above.

[0208] In yet some other implementations, a non-transitory computer readable medium is disclosed. The non-transitory computer readable medium may include computer instructions, when executed by at least one processor of the UE or the network node above, may cause the UE or the network node to implement any one of the methods above.

[0209] The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0210] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment / implementation” as used herein does not necessarily refer to the same  embodiment and the phrase “in another embodiment / implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

[0211] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0212] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

[0213] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be  recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1.A method performed by a user equipment (UE) in a wireless network comprising:receiving configuration information from the wireless network, the configuration information being associated with Quality of Experience (QoE) reporting and specifying an event-triggering mechanism for the UE to transmit QoE reports;generating a QoE report; andtransmitting the QoE report according to the event-triggering mechanism.2.The method of claim 1, wherein the configuration information comprises at least one of:event information to specify triggering events or event types for the QoE reporting;a flag for indicating whether the event-triggering mechanism is applied;a triggering mode specifying whether the QoE report is started or stopped by the triggering events or event types.3.The method of claim 2, wherein the event information specifies that the triggering events or event types comprise at least one of:a handover of the UE;a reception of a command of the UE for pausing / resuming the QoE reporting;dual connectivity status change of the UE;network type switch by the UE;workload level of the UE being in or out of a predefined or configured workload range;UE battery state change; andUE battery level being in or out of a predefined or configured battery level range.4.The method of claim 1, wherein the QoE reporting may be configured as one of:a core network terminated and Radio Access Network (RAN) invisible QoE reporting configured by a core network of the wireless network;a core network terminated but RAN visible QoE (RVQoE) reporting configured by the core network or a RAN relying on and being linked to a sperate QoE reporting configuration; anda RAN terminated individual RVQoE (iRVQoE) reporting configured by the RAN.5.The method of claim 1, wherein the configuration information is received from a RAN node via an RRC message after being received by the RAN node from a core network via an NGAP message.6.The method of claim 1, wherein the configuration information is received from distributed unit (DU) of a RAN after being received by the DU from central unit (CU) of the RAN via an F1AP message.7.The method of claim 1, wherein the QoE report is transmitted to a RAN node via an RRC message followed by the QoE report being transmitted by the RAN node to a Measurement Collector Entity (MCE) .8.The method of claim 1, wherein the configuration information is received from a source RAN node after being transmitted from a target RAN node to the source RAN node via an XnAP message in a handover process.9.The method of claim 8, wherein the configuration information is transmitted from the target RAN node to the source RAN node after the target RAN node receives an QoE configuration request from the source RAN node via another XnAP message in a handover process.10.The method of claim 1, wherein the configuration information is received from a source RAN node after being received by the source RAN node from a target RAN node via a core network in an NG based handover process.11.A method performed by a user equipment (UE) in a wireless network comprising:receiving an individual RAN Visible Quality of Experience (iRVQoE) configuration information from the wireless network, the iRVQoE configuration information being provided from the wireless network to configure an RVQoE reporting from the UE to a RAN regardless of existence of any other Quality of Experience (QoE) configurations;generating an iRVQoE report according to the iRVQoE configuration information; andtransmitting the iRVQoE report to the RAN.12.The method of claim 11, wherein the iRVQoE configuration information comprises one or more of:an ID to identify the iRVQoE configuration information;a QoE ID to identify another QoE configuration to link the iRVQoE configuration information to;an iRVQoE metric configuration to specify QoE metrics to be measured for the iRVQoE report;an area scope information item for the iRVQoE report;a slicing information item to indicate a scope of network slices for the iRVQoE report;iRVQoE measurement status;a service type information item for indicating service types governed by the iRVQoE configuration information;a UE type information item for indicating UE types governed by the iRVQoE configuration information;a communication service type information item for indicating service types governed by the iRVQoE configuration information;a minimization of drive tests (MDT) alignment information item;a priority information item;an iRVQoE reporting path;an indication of service area for Non-Public Network (NPN) ;an indication of service area for Non-Terrestrial Network (NTN) ; andNTN Radio Access Technology (RAT) restriction.13.The method of claim 12, wherein the iRVQoE metric configuration comprises at least one of a corruption duration metric, successive loss of RTP packets, frame rate, jitter duration, sync loss duration, round-trip time, average codec bitrate, codec information, call setup time, representation switch events, average throughput, initial playout delay, buffer level, play list, Media Presentation Descriptor (MPD) information, playout delay for media start-up, device information, comparable quality viewport switching latency, rendered viewports, or Virtual Reality (VR) device information.14.The method of claim 12, wherein the area scope information indicates areas where the iRVQoE report is transmitted.15.The method of claim 12, wherein the iRVQoE measurement status comprises at least one of:ongoing, indicating that the iRVQoE report is starting;paused measurement, indicating that that iRVQoE measurement is paused;paused reporting, indicating that that the iRVQoE reporting is paused; orout of areas scope, indicating that the UE is out of the area scope.16.The method of claim 12, wherein the service type information item indicates at least one of: Dynamic Adaptive Streaming over HTML (DASH) , Multimedia Telephony Service for IMS (MTSI) , Virtual Reality (VR) , sidelink, Aircraft to Anything (A2X) , Vehicle to anything (V2X) , eXtended Reality (XR) , Augmented Reality (AR) , or Mixed Reality (MR) .17.The method of claim 12, wherein the UE type information indicates at least one of: IoT, IIoT, aerial UE, Redcap, aerial-liked UE, or common UE.18.The method of claim 12, wherein the communication service type information item indicates at least one of: Multicast, broadcast, sidelink, Airborne to anything (A2X) , vehicle to anything (V2X) , Non-terrestrial Network (NTN) service, or Non-Public Network (NPN) service.19.The method of claim 12, wherein the iRVQoE reporting path indicate at least one of: Signaling Radio Barrier 4 (SRB4) or SRB5.20.The method of claim 12, wherein the indication of service area for NPN indicates an equivalent Standard Non-Public-Network (SNPN) information and allowed Public Network Integrated NPN (PNI-NPN) information.21.The method of claim 12, wherein the indication of service area of NTN indicates at least one of:positioning defined area information list;positioning based area information list;cell based area information list;TAI based area information list;area counting information;mapped cell ID information;mapping information; oradministrative region information.22.The method of claim 21, wherein the area counting information comprises a cell area and a positioning defined area, and a final service area is obtained as:an intersection of the cell area and the positioning defined area;a union of the cell area and the positioning defined area;the cell area minus the positioning defined area; orthe positioning defined area minus the cell area.23.The method of claim 21, wherein the area counting information comprises a TAI area and a positioning defined area, and a final service area is obtained as:an intersection of the TAI area and the positioning defined area;a union of the TAI area and the positioning defined area;the TAI area minus the positioning defined area; orthe positioning defined area minus the TAI area.24.The method of claim 21, wherein the area counting information comprises a cell area, a TAI area and a positioning defined area, and a final service area is obtained as:an intersection of the cell area, the TAI area and the positioning defined area;an intersection of the positioning defined area with either of the cell area or the TAI area;a union of the cell area, the TAI area and the positioning defined area;the TAI area minus the positioning defined area; orthe positioning defined area minus the TAI area.25.The method of claim 11, wherein the iRVQoE configuration information is received from a RAN node via an RRC message after being received by the RAN node from a core network via an NGAP message. network via an RNA node an RRC message.26.The method of claim 11, wherein the iRVQoE configuration information is received from distributed unit (DU) of a RAN after being received by the DU from central unit (CU) of the RAN via an F1AP message.27.The method of claim 11, wherein the iRVQoE report is transmitted to a RAN node via an RRC message followed by the iRVQoE report being transmitted by the RAN node to a Measurement Collector Entity (MCE) .28.The method of claim 11, wherein the iRVQoE configuration information is received from a source RAN node after being transmitted from a target RAN node to the source RAN node via an XnAP message in a handover process.29.The method of claim 28, wherein the iRVQoE configuration information is transmitted from the target RAN node to the source RAN node after the target RAN node receives an iRVQoE configuration request from the source RAN node via another XnAP message in a handover process.30.The method of claim 11, wherein the iRVQoE configuration information is received from a source RAN node after being received by the source RAN node from a target RAN node via a core network in an NG based handover process.31.The UE of any one of claims 1-30, comprising a memory for storing instructions and at least one processor configured to execute the instructions to cause the UE or the network node to perform steps of any one of the claims 1-30.32.A non-transitory computer readable storage medium for storing instructions, the instructions, when executed by at least one processor, are configured to perform steps of any one of claims 1-30.

Images