WO2024043819A1

WO2024043819A1 - Network nodes and methods for handling quality measurements for a group of user equipment in a wireless communication network

Info

Publication number: WO2024043819A1
Application number: PCT/SE2023/050843
Authority: WO
Inventors: Filip BARAC; Johan Rune; Luca LUNARDI; Ali PARICHEHREHTEROUJENI; Cecilia EKLÖF
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-08-22
Filing date: 2023-08-21
Publication date: 2024-02-29

Abstract

Network nodes (211, 212) and method therein for handling quality measurements for a group of UEs in a wireless communication network are provided. A first network node (211) determines (310) to execute quality measurements and/or to detect quality measurements related events for the group of UEs (231, 232), configures (340) the group of UEs (231, 232) based on obtained information on available quality measurements for the group of UEs (231, 232); and receives (350) reports on the quality measurements configured by the first network node (211) from the group of UEs (231, 232).

Description

NETWORK NODES AND METHODS FOR HANDLING QUALITY MEASUREMENTS FOR A GROUP OF USER EQUIPMENT IN A WIRELESS COMMUNICATION NETWORK

TECHNICAL FIELD

Embodiments herein relate to network nodes and methods therein. Furthermore, a computer program and a computer readable storage medium are also provided herein. In particular, embodiments herein relate to handling quality measurements for a group of UEs.

BACKGROUND

In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or user equipment (UE), communicate via a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a WiFi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a “NodeB” or “eNodeB” or “gNB”. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within a range of the radio network node.

A Universal Mobile Telecommunications System (UMTS) is a third generation (3G) telecommunication network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network or Long Term Evolution (LTE) have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (5G) New Radio (NR) network and upcoming releases.

Quality of Experience (QoE) measurements, also referred to as “application layer measurements”, have been specified for LTE and UMTS and are being specified for NR in 3GPP release 17. The purpose of the application layer measurements is to measure the end user experience when using certain applications. Currently QoE measurements for streaming services and for Mobility Telephony Service for Internet Protocol (IP) Multimedia Subsystem (IMS) (MTSI) services are supported. For NR, it is likely that at least virtual reality (VR) is added to the list of services for which QoE measurements are specified and supported.

The solutions in LTE and UMTS are similar with the overall principles as follows. Quality of Experience Measurement Collection (QMC) enables configuration of application layer measurements in the UE and transmission of QoE measurement result files, commonly referred to as QoE reports, to the network by means of radio resource control (RRC) signalling. An application layer measurement configuration, also called QoE measurement configuration or QoE configuration that the RAN receives from the Operation and Maintenance (OAM) system or the ON is encapsulated in a transparent container, which is forwarded to a UE in a downlink RRC message. An application layer measurement report, also called QoE report, that the UE Access Stratum (UE AS) or UE RRC layer receives from the UE's higher layer, i.e. application layer, is encapsulated in a transparent container and sent to the network in an uplink RRC message. The RAN then forwards the QoE report to a Measurement Collector Entity (MCE).

In 3GPP release 17 a new study item “Study on NR QoE management and optimizations for diverse services” for NR has been approved and concluded. The specification work for 3GPP release 17 is still ongoing. The purpose of the study item is to study solutions for QoE measurements in NR. QoE management in NR will not just collect the the quality of experience parameters of streaming services but also consider the typical performance requirements of diverse services, e.g. Augmented Reality/Virtual Reality (AR/VR) and Ultra Reliable Low-Latency Communications (URLLC), of which at least VR seems to be covered in 3GPP release 17. Based on requirements of services, the NR study will also include more adaptive QoE management schemes that enable network optimization to satisfy user experience for diverse services.

The configuration data related to QoE measurements, typically referred to as application layer measurements in standard specifications, consists of a service type indication, an indication of an area in which the measurements are to be performed, i.e. denoted area scope, an IP address of the entity the collected measurement results i.e. the QoE reports, should be sent to, e.g. Measurement Collector Entity or Measurement Collection Entity (MCE) , which may also be referred to as a Trace Collection Entity (TCE), and a set of instructions of which type of measurements that should be performed and details of how these measurements are to be performed. These instructions are intended for the application layer in the UE and are placed in a “container” which the network entities handling it, e.g. forwarding it to the UE, as well as the UE Access Stratum, cannot interpret and do not try to read. The currently specified service types are Multimedia Telephony Service for IMS (MTSI) and streaming service DASH, i.e. Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP), and in 3GPP release 17, at least service type VR will be added. An area scope is defined in terms of cells or network related areas. In UMTS, an area scope is defined as either a list of cells, a list of routing areas or a list of tracking areas. In LTE, an area scope is defined as either a list of cells or a list of tracking areas. In NR, an area scope will be defined as either a list of cells or a list of tracking areas.

QoE, and in particular QoE configuration, comes in two flavors: managementbased QoE configuration and signaling-based QoE configuration. In both cases the QoE configuration originates in the QAM system or some other administrational entity, e.g. dealing with customer satisfaction. All of these entities are in this document referred to as the QAM system, where the QAM system also contains further entities. With management-based QoE (m-based QoE), the QAM system is typically interested in general QoE statistics from a certain area, which is configured as an area scope. The m-based QoE configuration is sent directly from the QAM system to the RAN nodes controlling cells that are within the area scope. Each RAN node then selects UEs that are within the area scope, and also fulfills any other relevant condition such as supporting the concerned application or service type, and sends the m-based QoE configuration to these UEs.

With signaling-based QoE (s-based QoE), the QAM system is interested in collecting QoE measurement results from a specific UE, e.g. because the user of the UE has filed a complaint. The QAM system sends the s-based QoE configuration to the Home Subscriber Server (HSS) in EPS/LTE, or Unified Data Management (UDM) in 5GS/NR, which forwards the QoE configuration to the UE’s current core network node (CN), e.g. an Mobility Management Entity (MME) in EPS/LTE or an Access and Mobility Management Function (AMF) in 5G/NR. The CN then forwards the s-based QoE configuration to the RAN node that serves the concerned UE and the RAN node forwards it to the UE.

Forwarded to the UE are the service type indication and the container with the measurement instructions. The UE is not aware of whether a received QoE configuration is m-based or s-based. In legacy systems, the QoE framework is integrated with the Trace functionality and a Trace Identifier/ldentity (ID) is associated with each QoE configuration. In NR, the QoE functionality will be logically separated from the Trace functionality, but it will still partly reuse the Trace signaling mechanisms. In NR and LTE, a globally unique QoE reference, formed of Mobile Country Code (MCC)+ Mobile Network Code (MNC)+ QoE Measurement Collection (QMC) ID, where the QMC ID is a string of 24 bits, will be associated with each QoE configuration. The QoE reference is included in the container with measurement instructions and also sent to the RAN node, i.e. the gNB in NR. For the communication between the gNB and the UE, the QoE reference is replaced by a shorter identifier denoted as measConfigAppLayerld, which is locally unique within a UE, i.e. there is a one-to-one mapping between a measConfigAppLayerld and a QoE reference for each QoE configuration provided to a UE. The measConfigAppLayerld is stored in the UE Access Stratum and also forwarded in an Attention (AT) Command, which is the type of instructions used in the communication between the UE’s modem part and the UE’s application layer, together with the service type indication and the container with the measurement instructions.

Reports with collected QoE measurement results, i.e. QoE reports, are sent from the UE application layer to the UE Access Stratum, which forwards them to the RAN, which forwards them to the MCE. These QoE measurement results are placed in a “container”, which is uninterpretable for the UE Access Stratum and the RAN. QoE reporting can be configured to be periodic or only sent at the end of an application session. Furthermore, the RAN can instruct the UE to pause QoE reporting, e.g. in case the cell/gNB is in a state of overload.

The RAN is not aware of when an application session with an associated QoE measurement session is ongoing and the UE Access Stratum is also not automatically aware of this. To alleviate this session start/stop indications can be introduced, which will be sent from the application layer in the UE to the UE AS and from the UE AS to the RAN. A session stop indication may be implicit in the form of a QoE report sent when the application session and the associated QoE measurement session are concluded.

The RAN may decide to release a QoE configuration in a UE at any time, as an implementation-based decision. Typically, it is done when the UE has moved outside an area configured for the QoE measurements, commonly referred to as the area scope.

One opportunity provided by legacy solutions is also to be able to keep the QoE measurement for the whole session, even during a handover situation. It is also discussed to let the UE continue with the QoE measurements on an ongoing application session until the application session ends, even if the UE in the meantime moves out of the configured area scope.

RAN visible QoE (RVQoE) In NR, 3GPP Rel-17 introduced RAN visible QoE measurements, and a general description can be found in 3GPP TS 38.300 V17.0.0 clause 21.4.

RAN visible QoE measurements are configured by the NG-RAN node, where a subset of QoE metrics is reported from the UE as an explicit Information Element (IE) readable by the NG-RAN node. RAN visible QoE measurements, e.g., RAN visible QoE metrics, RAN visible QoE values, could be utilized by the NG-RAN node for network optimization. RAN visible QoE measurements are supported for the DASH streaming and VR services. The NG-RAN node configures the RAN visible QoE measurement to collect all or some of the available RAN visible QoE metrics, where the indication of metric availability is received from the QAM or CN. The set of available RAN visible QoE metrics is a subset of the metrics which are already configured as part of QoE measurement configuration encapsulated in the transparent container. The Protocol Data Unit (PDU) session ID(s) corresponding to the service that is subject to QoE measurements can also be reported by the UE along with the RAN visible QoE measurement results.

A request for collecting QoE measurements not visible to RAN, also called OAM- QoE in R3-223290, is started from OAM and identified by a QoE Reference. A definition for this identifier can be found e.g. in 3GPP TS 28.405 V17.1.0, clause 5.2:

The QoE reference parameter specifies the network request session. The QoE reference shall be globally unique therefore it is composed as follows: MCC+MNC+QMC ID, where the MCC and MNC are coming with the QMC activation request from the management system to identify one PLMN containing the management system, and QMC ID is a 3 byte Octet String.

The QMC ID is generated by the management system or the operator.

It is used to identify the QoE measurement collection job in the traffic nodes and in the measurement collection centre.

The UE AS layer can report to a gNB the RAN visible QoE measurements in RRC format and a UE Application Layer can be configured for performing more application layer measurements at the same time, in NR Rel-17 up to 16 and, e.g. in TS 38.331 , an application layer measurement is identified by the MeasConfigAppLayerld IE.

In a gNB, RAN visible QoE information can be transferred from gNB-CU to the gNB-DU in a procedure described in TS 38.473 v17.0.0. The procedure is UE- associated, i.e. it is specific for a UE. See sections 8.16.1 and 9.2.16.1 , 9.3.1.260.

In the contribution R3-223128 to 3GPP TSG-RAN WG3 Meeting #116-e, the association of RAN visible QoE report to a reference is discussed: In F1AP a list containing currently agreed RVQoE metric is transferred over Fl using UE- associated signalling. But the reports are not associated with e.g. any reference or other id. So the gNB-DU will not know how many different application sessions that provide reports, and the currently defined signalling will therefore not allow the gNB-DU to distinguish between QoE reports coming from the different application sessions. Also, the gNB-DU will not be able to group reports that it successively receives from a given application session and will therefore not be able to trace e.g. any tendencies in the reported data.

Candidate reference or other ID that could solve this issue would typically be the QoE reference or the short RRC id (measConfigAppLayerld) allocated by the UE. In the F1AP CR submitted to the present meeting in R3-223131, we propose to use the QoE reference, but the ultimate choice may be subject for further evaluation.

In the same contribution, the following proposal is made according to the reported discussion:

Proposal 3: RAN3 to discuss and agree on identifying RVQoE report information over Fl using QoE Reference or short RRC id (measConfigAppLayerld).

Signalling Radio Bearer (SRB)

Signalling Radio Bearers are configured in the UE for transmission of control plane message to and from the UE. In current specifications five different SRBs may be configured. SRBO is used for initial RRC setup, before any security is activated. SRB1 is used for most RRC messages and SRB2 for NAS messages.

If the UE is configured with dual connectivity (DC), SRB1 is used for communicating with the Master Node (MN). The UE may in DC also be configured with SRB3, which is used for direct communication between the UE and the Secondary Node (SN).

For the transmission of QoE and RVQoE reports, a dedicated SRB4 has been defined. SRB4 is in Rel-17 only being used for transmission of QoE and RVQoE reports in the RRC message MeasurementReportAppLayer, to a Master Node.

Multicast and Broadcast Service overview

Multicast and Broadcast Service (MBS) is a point-to-multipoint service in which services and data are transmitted from a single source entity to multiple recipients, either to all UEs in a Broadcast service area, or to users in a multicast group as defined in 3GPP TS 23.247. 5G NR system enables delivery of Multicast Broadcast Service (MBS) in a resource-efficient way. Via the MBS, the same service and the same specific content data from a single source can be provided simultaneously to all UEs in a geographical area in the broadcast communication service or to a dedicated set of UEs in the multicast communication service. That is, all UEs in a broadcast area can receive the data, while not all UEs are authorized to receive the data in a multicast area.

A UE can receive a broadcast MBS communication service independently of its RRC state, while a multicast MBS service can be received only by the UEs in the RRC_CONNECTED state. Multicast communication data can be delivered to a UE via Point-to-Point (PTP) and/or Point-To-Multipoint (PTM) mechanisms, and Hybrid automatic repeat request (HARQ) retransmission/feedback can be applied to both of these mechanisms, as specified in 3GPP TS 38.300.

For a multicast communication service, shared and individual delivery modes are specified in 3GPP TS 23.247. Between 5GC and NG-RAN, there are two possible delivery methods to transmit the MBS data:

- 5GC Individual MBS traffic delivery method: This method is only applied for multicast MBS sessions. 5GC receives a single copy of MBS data packets and delivers separate copies of those MBS data packets to individual UEs via per-UE PDU sessions, hence for each such UE one PDU session is required to be associated with a Multicast MBS session. The MBS data received by the MB-UPF is replicated towards the UPF(s) where individual delivery is performed via unicast transport over N19mb interface.

- 5GC Shared MBS traffic delivery method: This method is applied for both broadcast and multicast MBS sessions. 5GC receives a single copy of MBS data packets and delivers a single copy of those MBS packets to an NG-RAN node, which then delivers the packets to one or multiple UEs. These incoming MBS traffic packets are delivered from MB-UPF to NG-RAN node via the N3mb interface.

The 5GC Shared MBS traffic delivery method is required in all MBS deployments. The 5GC Individual MBS traffic delivery method is required to enable mobility when there is an NG-RAN deployment with non-homogeneous support of MBS.

Between the NG-RAN and the UE, two delivery methods are available for the transmission of MBS data packets over radio interface:

Point-to-Point (PTP) delivery method: NG-RAN delivers separate copies of MBS data packets over radio interface to individual UE(s). Point-to-Multipoint (PTM) delivery method: NG-RAN delivers a single copy of

MBS data packets over radio interface to multiple UEs.

NG-RAN may use a combination of PTP/PTM to deliver an MBS data packets to

UEs.

MBS Radio Bearer

An MBS Session Resource may be associated with one or more MBS QoS flows, and each of those flows is associated with a QoS profile. gNB provides one or more multicast MBS Radio Bearer (MRB) configurations to the UE via RRC signalling, as described in TS 38.300, clause 16.10.3. For a multicast session, gNB may change the MRB type using RRC signalling. For a broadcast session, gNB provides a broadcast MRB with one DL-only RLC-UM entity for PTM transmission, i.e. only one type of an MRB is specified at the moment for the broadcast communication transmission. Network and protocol architectures are described in detail in 3GPP TS 38.300 chapters 16.10.2 and 16.10.3.

Group scheduling and group paging

Group scheduling mechanisms for MBS delivery are described in 3GPP TS 38.300, clause 16.10.4. Radio Network Temporary identifier (RNTI) is used for the group transmission where a UE can receive different services using the same or different G- RNTI(s)/G-CS-RNTIs, as defined in 3GPP TS 38.300. NG-RAN performs certain functions to support MBS. They include management of MBS QoS flows, delivery of MBS data packets from 5GC to multiple UEs via PTP or PTM, configuration of UE for MBS QoS flow reception at AS layer, controlling switching between PTM and PTP delivery per UE, support for multicast session service continuity during Xn and NG handovers, and support for group paging at multicast session activation over radio toward UEs in CM-IDLE state and CM-CONNECTED with RRC INACTIVE state.

MBS Interest Indication

To ensure service continuity of MBS broadcast, the UE in RRC_CONNECTED state may send MBS Interest Indication to the gNB, consisting of the following information:

(1) List of MBS frequencies UE is interested in receiving, sorted in decreasing order of interest.

(2) Priority between the reception of all listed MBS frequencies and the reception of any unicast bearer.

(3) List of MBS broadcast services the UE is interested in receiving, in case SIB20 is scheduled by the UE's PCell.

(4) UE’s priority to MBS broadcast versus unicast reception. MBS Interest Indication information reporting can be implicitly enabled/disabled by the presence of SIB21 .

Mobility support during MBS session

Mobility support for service continuation when a UE is in an MBS session depends on whether the broadcast or multicast session is taking place, and on whether the source and target nodes support MBS. For the multicast MBS session, three cases can be distinguished: 1) handover from an NG-RAN node supporting MBS to a node not supporting MBS, 2) handover from an NG-RAN node not supporting MBS to a node supporting MBS, and 3) a handover from a node supporting MBS to another node supporting MBS.

In the Multicast MBS case:

When a handover takes place from a node that supports MBS to a node that does not support MBS, or vice versa, the 5GC Shared MBS Traffic Delivery and 5GC Individual Traffic delivery methods can co-exist temporarily upon handover.

. Mapping information about unicast QoS flows for multicast data transmission and the information of associated multicast QoS flows are provided to an NG-RAN node.

. The delivery method is switched from 5GC Shared MBS Traffic delivery to 5GC Individual MBS delivery via establishing the N3 tunnel of the PDU Session for Individual delivery. Session Management Function (SMF) realizes that the target node does not support MBS.

. GPRS Tunnelling Protocol (GTP) tunnel between the UPF and the MB-UPF for 5GC Individual MBS traffic delivery activated by SMF and MBS-SMF.

When a handover takes place from a RAN node that supports MBS to another node that also supports MBS, if the shared delivery for the MBS session has not been established towards the target NG-RAN node, it uses MB-SMF (Multicast Broadcast Session Management Function) and MB-UPF (Multicast Broadcast User Place Function) to establish the Shared delivery for the MBS session.

The PDU Sessions, including the one associated with the MBS Multicast session and used for the 5GC Individual MBS traffic delivery, are handed over to the target ND- RAN node.

. SMF triggers the mode switch from the Individual to the Shared delivery mode.

. Target node establishes the shared delivery for the MBS Session upon receiving the MBS Session Context.

. 5GC Individual MBS traffic delivery is terminated by 5GC and changed to the 5GC shared MBS traffic delivery. In the Broadcast MBS case:

. The UE may receive the same service in the target node (which supports MBS) if the same MBS session is established with the 5GC Shared MBS traffic delivery.

. Currently, a case of when a UE is handed over to a node not supporting the MBS within the broadcast area, is not specified.

RAN visible QoE (RVQoE)

An extension of the QoE framework, which has been studied for 3GPP release 17 and which is currently being specified in 3GPP is the concept of RAN visible QoE (RVQoE). The regular QoE reports are intended for the MCE, which is an entity outside the RAN, e.g., a part of the QAM system, and the RAN cannot read the QoE reports, at least not according to specification, although gNB/eNB implementations are not prevented from doing so. In contrast, reported RVQoE metrics are intended for the RAN and are delivered to the RAN in a format that the RAN understands. The RVQoE metrics are derived from the regular QoE metrics, collected and compiled in reports by the UE application layer and delivered to the RAN, so that the RAN may use the reports for various types of optimizations. As an example, when the RAN receives RVQoE reports during an ongoing application session, the RAN can perform adaptive actions to impact the QoE of the concerned application session while the application session is ongoing, such as change various parameters related to the scheduling of the UE and the data flows related to the application session.

RVQoE metrics at Application Layer:

As one option, or for some RVQoE metrics, the UE AS forwards RVQoE metrics received from the UE Application Layer to the RAN without modification or additions:

One or more (raw) QoE metrics are measured at UE Application Layer, and subsequently: i. The QoE metrics are sent from the Application Layer of the UE to the UE Access Stratum, in a format, e.g., RRC format, that the UE AS can easily include in, or convert into, a field in an RRC message. The information obtained from the raw QoE metrics and included in the RRC message constitutes the RAN Visible QoE metrics. ii. The RAN Visible QoE metrics are then sent from the UE RRC layer to RAN, without modification at UE Access Stratum. RVQoE metrics at Access Stratum Layer:

As another option, or for some RVQoE metrics, the UE AS modifies or adds to the RVQoE metrics received from the UE Application Layer before forwarding them to the RAN.

One or more (raw) QoE metrics are measured at UE Application Layer, and subsequently: i. The QoE metrics are sent from the Application Layer of the UE to the UE Access Stratum, in a format e.g., RRC format, that the UE AS can easily include in, or convert into, a field in an RRC message. The information obtained from the raw QoE metrics and, via the described steps, included in the RRC message constitutes the RAN Visible QoE metrics. ii. Before sending the RAN Visible QoE metric to the RAN, the RAN Visible QoE metrics as received from the Application Layer, are modified by the UE Access Stratum.

Hi. The obtained version of the RAN Visible QoE metrics is then sent from the UE RRC layer to RAN.

RVQoE values (or RVQoE scores) at Application Layer:

RAN-visible QoE values are a set of values derived from raw QoE metrics through a model or function.

One or more representations or mapping of the raw QoE metrics are measured at UE Application Layer, and subsequently: i. The representations are sent from the Application Layer of the UE to the UE Access Stratum, e.g., in RRC format e.g., in a format that the UE AS can easily include in, or convert into, a field in an RRC message. ii. The representations are then sent from the UE RRC layer to RAN without modification at UE Access Stratum.

RVQoE values (or RVQoE scores) at Access Stratum:

One or more representations or mapping of raw QoE metrics are measured at UE Application Layer, and subsequently: i. The representations are sent from the Application Layer of the UE to the UE Access Stratum in RRC format e.g., in a format that the UE AS can easily include in, or convert into, a field in an RRC message. ii. The representations are then modified by the UE Access Stratum.

Hi. The modified version of the representations is then sent from the UE RRC layer to RAN. QoE-related event

A QoE-related event happens in relation to QoE metrics, or RAN Visible QoE metrics, or RAN Visible QoE values, or a combination thereof. A QoE-related event is identified by a unique identifier, e.g., a value or a label used for an identity, such as a value for a QoE-Event-ID, and the definition of a QoE-related event may comprise:

- an identifier of the QoE-related event e.g. a QoE-Event-ID.

- one or more parameters, conditions, and indications, among which o parameters, conditions, and indications pertaining to QoE metrics, or part of QoE metrics, or combination thereof. o parameters, conditions, and indications pertaining to RVQoE metrics, or combination thereof. o parameters, conditions, and indications pertaining to RVQoE values, or combination thereof. o entering conditions for the event. o leaving conditions for the event o one of more thresholds e.g., threshold for entering/leaving the event. o one or more hysteresis e.g., hysteresis for entering/leaving the event. o duration of the event. o frequency of occurrence of the event, i.e. number of occurrences of the event in a given period of time. o time-to-trigger

3GPP Rel-18 QoE Work Item

For 3GPP Rel-18, the RP-221803 describes the Work Item “Enhancement on NR QoE management and optimizations for diverse services” and among others, it indicates, the following objectives:

• Support for new service type, such as AR, MR, MBS and other new service type defined or to be supported by SA4. Support RAN-visible parameters for the additional service types, and the existing service if needed, and the coordination with SA4 is needed [RAN3, RAN2].

- Specify the new service and the existing service defined or to be supported by SA4, combined with high mobility scenarios, e.g., High Speed Trains.

• Specify for QoE measurement configuration and collection in RRC_INACTIVE and RRCJDLE states for MBS, at least for broadcast service [RAN3, RAN2],

- Specify the mechanism to support the alignment of the existing radio related measurement and QoE reporting. • Left-over features from Rel-17, as well as the enhancements of existing features which are not included in Rel-17 normative phase, should be supported in Rel-18 if consensus on benefits are reached [RAN3, RAN2],

- Specify per-slice QoE measurement configuration enhancement.

- Specify RAN visible QoE enhancements for QoE value, RAN visible QoE trigger event, RAN visible QoE Report over F1.

- Specify QoE reporting handling enhancement for overload scenario.

SUMMARY

As part of developing embodiments herein problems were identified and will first be discussed.

In Rel-17, the concept of RAN visible QoE (RVQoE) measurements was specified, in addition to the signaling- and management-based QoE measurements. The RAN can configure RVQoE measurements for a UE only if the UE is, at the same time, configured with corresponding QoE measurements.

As opposed to QoE measurements, where the specifications differentiate between m- and s-based QoE, no such differentiation exists for RVQoE. However, from the fact that a prerequisite for configuring a UE for RVQoE measurements is that the QAM informs the RAN about the available RVQoE metrics at the UE, and the fact that this indication is sent together with the s-based QoE measurement configuration, it implicitly follows that, as of today, only s-based RVQoE framework is specified.

Nevertheless, in some scenarios, it would be beneficial to collect RVQoE measurements from a group of UEs that have something in common, e.g., use a common radio resource for the application session, so that the network can evaluate the QoE more accurately, e.g., based on more input. One prominent example is the scenario where a group of UEs receives data of an MBS session. An MBS session may be delivered to a group of UEs in a broadcast mode or in multicast mode. In either case, the same radio resource is used for delivering the data for the application session to all the UEs, except for the PTP delivery mode for multicast, as shown in Figure 1 .

As of today, for an application session, the RVQoE reports are collected from a single UE. There are currently no solutions where the RVQoE reports for an application session, e.g., an MBS session, are collected from all the UEs receiving the application session.

Another example would be a group of UEs travelling together, for example, onboard a high-speed train. Rel-18 will support scenarios where network nodes are mobile, e.g., mobile Integrated Access and Backhaul (IAB) or vehicle-mounted relays, where the same vehicle that carries the mobile node also carries a multitude of UEs served by this mobile network node.

Another case would be a group of UEs exposing a common characteristics or capability. Non limiting examples may be:

- UEs in the same mobility state or not in a certain mobility state.

- UEs subject to group mobility.

- UEs served by shared spectrum.

- All or part of the UEs placed in a factory and connected to the same private network.

- UEs that are Fixed Wireless Terminals served by the same RAN node where the RAN node in question may also serve other UEs.

- UEs providing radio connectivity to machines or devices that perform one or more tasks in a coordinated manner.

Hence, currently, there is no management-based counterpart of RVQoE measurements, i.e., there are no means to support the collection of RVQoE measurements for a group of UEs that, e.g., have something in common.

Therefore it is an object of embodiments herein to provide an improved method for handling RVQoE measurement, configurations and reporting for a group of UEs in a wireless communication network.

According to one aspect of embodiments herein, the object is achieved by a first network node and method therein for handling quality measurements for a group of UEs in a wireless communication network. The first network node determines to execute quality measurements and/or to detect quality measurements related events for the group of UEs. The first network node configures the group of UEs based on obtained information on available quality measurements for the group of UEs and receives reports on the quality measurements configured by the first network node from the group of UEs.

The quality measurements may be RVQoE measurements and/or RVQoE values, and the quality measurements related events may be RVQoE and/or QoE related events.

According to one aspect of embodiments herein, the object is achieved by a second network node and method therein for handling quality measurements for a group of UEs in a wireless communication network. The second network node 212 receives a message from the fist network node indicting an intention to configure quality measurements and/or to detect quality measurements related events for a group of UEs.

The second network node sends to the first network node a response comprising an indication indicating one or more of the following information:

• Available services and measurements for the group of UEs;

• RVQoE measurement metrics that each UE in the group is allowed to collect and including a management-based QoE measurement configuration that pertains to the UEs;

• RVQoE measurement metrics that each UE in the group is allowed to collect;

• RVQoE measurement metrics for which there are corresponding QoE measurement metrics included in the QoE configuration;

• Rejection of providing information for some of the UEs in the group.

According to embodiments herein, management based QoE framework is designed to collect QoE measurements for potentially a mass of UEs connected or camped in an area of network. Analyzing such reports by network entities such as QAM or RAN node, in case of RAN visible RVQoE, may require proper selection of the set of the UEs for the QoE measurements. In particular, the RVQoE collected for fine analysis at the network side, may be affected by the peculiarities at the real network. For example, UEs using different network slices or different radio resources with different priority for the network may have different end user experience and hence different RVQoE.

The proposed method enables the RAN node to select a group of the UEs based on specific metrics as proposed in this disclosure.

In addition, since the underlying configuration of the MBS is set by the Distributed Unit (DU), the Central Unit (CU) may not be able to select suitable set of the UEs to be configured with QoE configuration. Hence DU providing additional information to the CU, e.g., which UEs are in PTM mode and which UEs are in PTP mode as well, would assist the CU to select the correct set of the UEs based on the MBS configuration.

The proposed method enables RVQoE measurements and reporting from a group of UEs that have something in common, e.g.:

• A group of UEs that receive the data for an application session using the same radio resource e.g., the exact same resources, and/or radio resources with the same priority at the network.

• A group of UEs that receive data for the same application session, e.g., MBS, where the data can be delivered to the UEs using a common radio resource e.g. PTM delivery mode for MBS, or separate radio resources for each UE e.g. PTP delivery mode for MBS.

• A group of UEs that travel together.

• UEs configured with the same RAN-based Notification Area (RNA).

• UEs in the same mobility state or not in a certain mobility state.

• UEs subject to group mobility.

• UEs served by shared spectrum.

• All or part of the UEs placed in a factory and connected to the same private network such as standalone non-public network or public network integrated non-public network.

• UEs that are Fixed Wireless Terminals served by the same RAN node e.g. where the RAN node in question may also serve other UEs.

• UEs providing radio connectivity to machines or devices that perform one or more tasks in a coordinated manner.

• UEs with certain capabilities, e.g., a certain set of UE capabilities.

• UEs in the same multi-connectivity setup, e.g., NR-DC, EN-DC

• UEs that are in certain cell(s) or cell groups, which have the same Master Cell Group (MCG), the same Secondary Cell Group (SCG).

• UEs that have a certain cell category, a certain allowed cell list, e.g. previously white list, or a certain cell category.

• UEs under coverage of some specific Synchronization Signal Block (SSB) or Channel State Information Reference Signal (CRI-RS) beams.

• UEs served by an Integrated Access and Backhaul (IAB) node or mobile IAB node.

• UEs served by an IAB network, located a certain number of wireless hops from the IAB donor.

• UEs connected to the network using the network-controlled relay.

• UEs associated or served with/by certain set of network slices.

Therefore, embodiments herein provide an improved method for handling RVQoE measurement, configurations and reporting for a group of UEs in a wireless communication network.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to attached drawings in which: Figure 1 is a signaling diagram illustrating MBS delivery methods as shown in 3GPP TS 23.247;

Figure 2 is a schematic block diagram depicting embodiments of a communication network;

Figure 3 is a combined signalling schema and flowchart according to embodiments herein;

Figure 4 is a signaling diagram illustrating an example embodiment;

Figure 5 is a schematic block diagram illustrating one embodiment of a first network node;

Figure 6 is a schematic block diagram illustrating one embodiment of a second network node;

Figure 7 schematically illustrates a telecommunication network connected via an intermediate network to a host computer;

Figure 8 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and

Figures 9-12 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

DETAILED DESCRIPTION

Please note that the terms “UE”, “terminal equipment”, “wireless terminal” and “terminal” are used interchangeably.

• At least some parts of the solution herein are described on an example of MBS but are equally applicable to any other application layer service or communication service where the same radio resource is used to deliver the content to a group of UEs.

• The solution herein is also applicable for any scenario where a group of UEs are located in a very close proximity, e.g., onboard a high-speed train, onboard a vehicle carrying a mobile IAB node, at events such as concerts etc.

• “Using the same radio resource to deliver the content to a group of UEs” means that each transmitted packet by the network during the session is received by all the UEs subscribed to the session.

• The solution herein is also applicable for scenarios listed in the Summary and in the following sections. • “The UEs in the session” may refer to the UEs that receive the same content from the network at the same time. This may, e.g., be UEs receiving an MBS session in broadcast mode.

• The terms “application layer measurement configuration”, "application measurement configuration”, “QoE measurement configuration”, “QoE configuration”, “QoE measurement and reporting configuration” and “QMC configuration” are used interchangeably. But note that the “QMC configuration file” is not an equivalent term, but instead refers to the part of the QoE configuration consisting of an Extensible Markup Language (XML) file containing instructions of QoE metrics to be collected etc.

• All references to the application layer are with respect to the application layer of the UE since RAN nodes do not have an application layer.

• The term “service” is often used as a short notation for “service type”, therefore “service” and “service types” can be seen as interchangeably unless explicitly stated.

• The solution proposed in this disclosure applies to both signaling- and management-based QoE measurements, but may also optionally be restricted to apply to only one of them.

• The terms “QoE report” and “QoE measurement report” are used interchangeably. Similarly, the terms “RAN Visible QoE report”, “RAN Visible QoE measurement report”, “RVQoE report” and “RVQoE measurement report” are used interchangeably.

• The terms “access stratum” and “radio layer” are used interchangeably when referring to a UE.

• The term “session” may refer to either a QoE measurement session or an application session or an application session for which QoE measurement is applied.

• The solution proposed in this invention applies to UMTS, LTE and NR as well as future RATs such as 6G.

• The solution is described on the example of management based QoE measurements, i.e., their corresponding RVQoE measurements, but it is equally applicable to both management-based and signalling-based QoE measurements, as well as their corresponding RVQoE measurements.

• The term “UEs of interest”, “UE group” and “group of UEs” refer to the UEs that have something in common and for which a network node e.g., the RAN node is interested in configuring group RVQoE measurements. • A network node may be a RAN node, a Core Network node, an CAM node, an MCE, a TCE, an Service Management and Orchestration (SMO), a Network Management System (NMS), a Non-Real Time RAN Intelligent Controller (Non-RT RIC), a Real-Time RAN Intelligent Controller (RT-RIC), a gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-DU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, lAB-node, mobile IAB node, Vehicle Mounted Relay, lAB-donor DU, lAB-donor-CU, IAB-DU, IAB-MT, O-CU, O- CU-CP, O-CU-UP, O-DU, O-RU, O-eNB, a Cloud-based network function, a Cloud-based centralized training node.

Embodiments herein relate to a communication networks in general. Figure 2 is a schematic overview depicting a communication network 200. The communication network 200 may be a wireless communications network comprising one or more RANs, and one or more CNs. The communication network 200 may use a number of different technologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, NR, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein relate to recent technology trends that are of particular interest in a 5G context, however, embodiments are also applicable in further development of the existing wireless communication systems such as e.g. WCDMA and LTE.

In the wireless communication network 200, one or more wireless devices e.g. a first user equipment 231, a second user equipment 232, such as a mobile station, a non- access point (non-AP) STA, a STA, a user equipment and/or a wireless terminals, communicate via one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN). It should be understood by the skilled in the art that “wireless device” is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell. The terms user equipment 231/232, UE, UE 231/232 and wireless device 231/232 are used interchangeable herein.

Network nodes operate in the wireless communication network 200 such as a first network node 211 and a second network node 212. The RAN node may be any of gNB, eNB, en-gNB, ng-eNB, gNB Central Unit (gNB-CU), gNB-CU-Control Plane (gNB-CU- CP), gNB-CU-User Plane (gNB-CU-UP), eNB Central Unit (eNB-CU), eNB-CU-Control Plane (eNB-CU-CP), eNB-CU-User Plane (eNB-CU-UP), Integrated Access and Backhaul (lAB)-node, lAB-donor Distributed Unit (lAB-donor DU), lAB-donor-CU, IAB-DU, IAB Mobile Termination (IAB-MT), Open RAN Central Unit (O-CU), O-CU-CP, O-CU-UP, O- DU, O-RAN Radio Unit (O-RU), O-eNB. The first network node 211 provides radio coverage over a geographical area, a service area 11 , which may also be referred to as a beam or a beam group where the group of beams is covering the service area of a first radio access technology (RAT), such as 5G, LTE, Wi-Fi or similar. The second network node 212 may be a RAN node, an OAM node or a CN node in charge of configuring e.g. QoE measurements or configuring QoE-related events.

The first network node 211 may be a transmission and reception point e.g. a radio access network node such as a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, a gNB, an evolved Node B (eNB, eNode B), a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of communicating with a wireless device within the service area served by the first network node 211 depending e.g. on the radio access technology and terminology used. The first network node 211 may be referred to as a source or target radio network node, and may communicate with the wireless device 231/232 with Downlink (DL) transmissions to the wireless device 231/232 and Uplink (UL) transmissions from the wireless device 231/232.

Figures 3 and 4 each shows a schematic signalling scheme according to embodiments herein for illustrating an example solution for handling RAN visible QoE measurements and QoE-related events for a group of UEs 231 , 232 in the wireless communication network 200.

The method for handling RAN visible QoE measurements and QoE-related events for a group of UEs 231 , 232 comprises the following actions.

Action 310

A first network node 211 e.g., a RAN node, or a CU in split RAN architecture realizes that it wants to execute RVQoE measurements for a group of UEs and/or that it wants to detect QoE-related events for a group of UEs. The latter, for example in relation to RVQoE measurements or RVQoE values. There may be many ways, for example based on Minimization of Drive Tests (MDT) measurements or any other type of measurements performed by the UE or the node itself or another network node, based on an indication from another network node, based on customer complaint that then causes the operator to invoke the first network node 211 to configure measurements for the UE etc.

These UEs in the group may for example be: a) UEs receiving the same application layer session e.g., via MBS broadcast or multicast, b) UEs receiving the same service type or even the same session while travelling in the same vehicle.

For MBS, for example, a number of UEs can subscribe to, and start receiving, an MBS session, thus forming a group of UEs, where the first network node 211 uses the same radio resource to deliver the content to this group of UEs.

In other examples, the group of UEs may comprise: c) A group of UEs that travel together d) UEs configured with the same RAN-based Notification Area (RNA), e) UEs in the same mobility state or not in a certain mobility state, f) UEs subject to group mobility, g) UEs served by shared spectrum, h) All or part of the UEs placed in a factory and connected to the same private network, i) UEs that are Fixed Wireless Terminals served by the same RAN node where the RAN node in question may also serve other UEs, j) UEs providing radio connectivity to machines or devices that perform one or more tasks in a coordinated manner, k) UEs with certain capabilities, e.g., a certain set of UE capabilities, l) UEs in the same multi-connectivity setup, e.g., NR-DC, EN-DC, m) UEs that are in certain cell(s) or cell groups, which have the same MCG, the same SCG, n) UEs that have a certain cell category, a certain allowed cell list (previously white list) or a certain cell category, o) UEs under coverage of some specific SSB or CRI-RS beams, p) UEs served by an IAB node or mobile IAB node, q) UEs served by an IAB network, located a certain number of wireless hops from the IAB donor, r) UEs connected to the network using the network-controlled relay, s) UEs associated/served with/by certain set of network slices.

The first and second wireless devices 231 , 232 may be comprised in a group of UEs that have something in common, as listed above.

Action 311

The first network node 211 indicates its intention to configure RVQoE measurements for a group of UEs, indicates UE IDs and requests the information about which RVQoE metrics may be collected from the UEs constituting the groups.

Case A: According to a first embodiment herein, the first network node 211 may send a message to a second network node 212, where the second network node 212 is in charge of configuring the QoE measurements or configuring QoE-related events, e.g., the QAM node which created the QoE measurement configuration for which the first network node 211 is considering to configure corresponding RVQoE measurements, and note that this request may be sent via one or more other node(s), e.g. OAM node(s), e.g. a Domain Manager/Element Manager (DM/EM) indicating its intention to configure RVQoE measurements for a group of UEs 231 , 232 or that it wants to detect QoE-related events for a group of UEs 231 , 232.

In a first option, the message may also contain a request for the second network node 212 to provide to the first network node 211 an indication of which RVQoE metrics/values each UE is allowed to provide.

In a second option, the message may also contain a request for the second network node 212 to provide to the first network node 211 an indication of which RVQoE metrics/values the group of UEs 231 , 232 is allowed to provide. That is the available RVQoE metrics, i.e., the RVQoE metrics for which there are corresponding QoE metrics configured for measurement according to the corresponding QoE configuration. In this second option, the request indicates that it pertains to a group of UEs 231 , 232 e.g., the request contains a flag indicating that RVQoE configuration is for a group, or an indication indicating a reference or identity of the group of UEs, e.g., an MBS Session ID, and in that sense, the first option and the second options are different.

In addition, or as an alternative, the request may contain the QoE reference of the concerned QoE configuration. In another option, the first network node 211 may also suggest to the second network node 212 parameters for the second network node 212 to include in the m-based QoE configuration that it is about to assemble. The notion of RVQoE metrics/values a UE is “allowed” to provide refers to the fact that, as of today, a UE will provide an RVQoE metric/value only if it is configured to provide the same or corresponding metric as a part of QoE measurements.

Case B: According to a second embodiment herein, the first network node 211 has previously received, but not yet configured to the UEs, an m-based QoE configuration from the second network node 212, and the UE group satisfies the criteria for executing QoE measurements and/or reporting QoE-related events.

According to some embodiments herein, the first network node 211 has not yet configured the group of UEs with the m-based QoE configuration. According to some embodiments herein, the first network node 211 has already configured the group of UEs with the m-based QoE configuration, and now the first network node 211 considers, or plans, to complement this QoE configuration with a corresponding RVQoE configuration. For the UE group for which it intends to configure the RVQoE measurements, similar to the previous variant, the first network node 211 sends a message to the second network node 212 in charge of configuring the QoE measurements e.g., the QAM node which created the QoE measurement configuration for which the first network node 211 is considering to configure corresponding RVQoE measurements, and note that this request may be sent via one or more other node(s), e.g. QAM node(s), e.g. a DM/EM, indicating its intention to configure RVQoE measurements for a group of UEs. In a first option, the message may also contain a request for the second network node 212 to provide an indication of which RVQoE metrics/values and/or QoE-related event each UE is allowed to provide. Similarly, as for Case A, also for Case B, in a second option the message indicates that the request pertains to a group of UEs. In addition, or as an alternative, the request can contain the QoE reference of the concerned QoE configuration.

The notion of RVQoE metrics/values or QoE-related event a UE is “allowed” to provide refers to the fact that, as of today, UE will provide an RVQoE metric/value or QoE-related event only if it is configured to provide the same metric as a part of QoE measurements.

Case C: According to a third embodiments herein, the message that delivered the m-based QoE configuration from the second network node 212, where the second network node 212 may e.g. be an QAM node, and where the first network node 211 e.g. may have received this message from a DM/EM, contained indication(s) of the available RVQoE metric(s), e.g. the QoE metric(s) in the QoE configuration for which there is/are specified corresponding RVQoE metric(s). In this variant, the first network node 211 thus does not have to send any request to the second network node 212 before configuring the group of UEs with suitable RVQoE configurations.

Currently, in 3GPP release 17, the only specified RVQoE metrics are RAN visible versions of the same QoE metric, and measurement/collection of such a RVQoE metric can only be configured if the corresponding QoE configuration contains the same metric configured for QoE measurement/collection. However, it may be anticipated that in future 3GPP releases, there may be RVQoE metrics specified which do not have a corresponding QoE metric. In such a scenario, in a subvariant of this variant, the first network node 211 may select such RVQoE metrics, for which there are no specified corresponding QoE metrics, to include in the RVQoE configuration, e.g. based on known UE capabilities, where the network node has obtained information about a UE’s capabilities from the UE. These RVQoE metrics may be configured for measurement/collection in addition to RVQoE metrics for which there are corresponding QoE metrics in the QoE configuration. The selection and/or configuration of the additional RVQoE metrics may be performed per UE in the group of UEs or may be common for all the UEs in the group of UEs, e.g., based on a set of capabilities that all UEs in the group of UEs have in common.

According to some embodiments herein, it may be possible for the RAN node to configure RVQoE metrics for collection/measurement for which there are specified corresponding versions of QoE metrics, but where these QoE metrics are not included in the QoE configuration. These additional RVQoE metrics may be configured for measurement/collection in addition to RVQoE metrics for which there are corresponding QoE metrics in the QoE configuration. The selection and/or configuration of the additional RVQoE metrics may, e.g., be based on UE capabilities, which the network node may previously have obtained from the UE, and may be performed per UE in the group of UEs, or may be common for all the UEs in the group of UEs, e.g., based on a set of capabilities that all UEs in the group of UEs have in common.

According to some embodiments herein, a merger of the two alternatives above, i.e., it is possible for the RAN node to configure RVQoE metrics for collection/measurement for which there are no specified corresponding QoE metrics as well as RVQoE metrics for which there are specified corresponding versions of QoE metrics, but where these QoE metrics are not included in the QoE configuration. These additional RVQoE metrics may be configured for measurement/collection in addition to RVQoE metrics for which there are corresponding QoE metrics in the QoE configuration. The selection and/or configuration of the additional RVQoE metrics may, e.g., be based on UE capabilities, which the network node may previously have obtained from the UE, and may be performed per UE in the group of UEs, or may be common for all the UEs in the group of UEs, e.g., based on a set of capabilities that all UEs in the group of UEs have in common.

Case D: According to a fourth embodiment herein, given that the first network node 211 knows, based on UE capability indication, which RVQoE metrics/values or QoE-related events the UE is able to provide, the first network node 211 may configure the UE group with RVQoE measurements on its own, i.e., need not contact the second network node 212.

Case E: According to a fifth embodiment herein, the first network node 211 sends a signal to a third network node e.g., a Distributed Unit (DU), requesting for the information and configuration of the UEs involved in a specific service. In a non-limiting example, the Central Unit (CU) requests the DU to provide to the CU information concerning the UEs using specific service type e.g., the list of UEs that are using the MBS services.

To identify the UEs in the variants above, the first network node 211 may, for example, indicate individual UE IDs to the second network node 212 e.g., 5G Temporary Mobile Subscriber Identity (5G-TMSI), 5G-S-TMSI, S-TMSI, RAN UE ID, Subscription Permanent identifier (SUPI), International Mobile Subscriber Identity (IMSI), Subscription Concealed Identifier (SUCI), 5G Globally Unique Temporary Identifier (5G-GUTI), GUTI, AMF UE NGAP ID, RAN UE NGAP ID, MME UE S1AP ID, eNB UE S1AP ID, etc., or it may use a group identifier, such as MBS session identifier, a Temporary Mobile Group Identity (TMGI), a G-RNTI, identifier of the mobile IAB node serving the UEs etc.

• As one option, in a 5GS network, the first network node 211 identifies the UEs by indicating each UE’s respective 5G-GUTI, which contains the Globally Unique AMF Identifier (GUAMI) and the 5G-TMSI and the second network node 212 uses these identifiers to find the AMF(s) holding the UEs’ contexts and obtain each UE’s SUPI or IMSI from this/these AMF(s).

• As another option, in an EPS network, the first network node 211 identifies the UEs by indicating each UE’s respective GUTI, which contains the Globally Unique MME Identifier (GUMMEI) and the S-TMSI, and the second network node 212 uses these identifiers to find the MME(s) holding the UEs’ contexts and obtain each UE’s IMSI from this/these MME(s). • As another option, in a 5GS network, the first network node 211 identifies the UEs by indicating each UE’s respective GUAMI and AMF UE NGAP ID, and the second network node 212 uses these identifiers to find the AMF(s) holding the UEs’ contexts and obtain each UE’s SUPI or IMSI from this/these AMF(s).

• As another option, in an EPS network, the first network node 211 identifies the UEs by indicating each UE’s respective GUMMEI and MME UE S1AP ID, and the second network node 212 uses these identifiers to find the MME(s) holding the UEs’ contexts and obtain each UE’s IMSI from this/these MME(s).

Action 320

Optionally, the second network node 212 may send a response to the first network node 211. The second network node 212 replies and provides the information requested in step 311.

For Case A, the second network node 212 indicates the RVQoE metrics that each UE of interest is allowed to collect and includes an m-based QoE configuration that pertains to the UEs of interest. Alternatively, or in addition, the second network node 212 may indicate the RVQoE metrics for which there are corresponding QoE metrics included in the QoE configuration. The second network node 212 may also reject to provide the information for some of the UEs in the group.

For Case B, the second network node 212 indicates the RVQoE metrics that each UE of interest is allowed to collect. Alternatively, or in addition, the second network node 212 may indicate the RVQoE metrics for which there are corresponding QoE metrics included in the QoE configuration. The second network node 212 may also reject to provide the information for some of the UEs in the group.

For Case C and D, there is no request to and response from the second network node 212.

Action 330

Optionally, pertaining to Case E, the third network node e.g., the DU may send a response to the first network node 211 . Optionally upon request from the first network node 211 e.g. a CU, the third RAN node, i.e. the DU, may send additional assistance information including configuration of the UEs according to the request by the CU. In a non-limiting example pertaining to MBS service, the third network node e.g. the DU provides a list of the UEs configured with different MBS configuration such as UEs configured with PTM or PTP MBS configuration. Action 340

Configuring the UE group with RVQoE measurements and/or QoE-related events. The first network node 211 configures the UEs 231 , 232 of interest e.g. from a group of UEs, with RVQoE measurements and/or QoE-related events.

• In one variant, the UEs are configured by using individual RRC messages, i.e. dedicated RRC signaling towards each UE. The RRC message conveying the configuration may be an existing RRC message, an enhanced existing RRC message or a newly defined RRC message. In one option the UEs 231 , 232 may receive an indication that they belong to a group configuration, by e.g., a group identity or just an indication of a group configuration. In another option, only the first network node 211 has the knowledge of which UEs that belong to a certain group configuration.

• In one variant, an indication of QoE group configuration is broadcasted in system information. It may be indicated which UEs that shall join the session, e.g. by a QoE group identity or just an indication of group QoE configuration. Broadcast in system information may be combined with dedicated RRC signalling, so that e.g., UEs first are configured with a certain QoE group configuration and then the UE performs the measurements in the cells which have an indication in system information.

• In one variant, the first network node 211 may include in a first message e.g., a Paging message or alike, an indication e.g., a flag, indicating that an RVQoE configuration is being sent in a second message i.e. that the RVQoE configuration is available in a second message. This mechanism, applicable in the case of Paging to UEs in RRCJDLE or RRCJNACTIVE state, can be used regardless of the application layer service type the RVQoE configuration pertains to, regardless of the communication service type the RVQoE configuration pertains to, regardless of the service subtype or the subservice type the RVQoE configuration pertains to.

In one variant, the first message may announce the presence of a QoE configuration being sent/available for the UE.

In another variant, the first message may announce the presence of a RVQoE configuration being sent/available for the UE.

According to one option, the first network node 211 may request the UEs of the group of UEs that received the RVQoE configuration to notify the first network node 211 that the configuration has been applied. The first network node 211 may send, as part of the RVQoE/QoE configuration, an implicit or explicit indication, identifying that the RVQoE/QoE configuration is targeting a group of UEs without any further details indicating the exact group of UE, and/or an identifier identifying the group of UEs which are the target for the RVQoE/QoE configuration. The above indication and/or identifier may be used later for analysis and optimization purposes. Non-limiting examples of identifier may be: a QoE Reference Group ID, an MBS Session ID, or a TMGI, or a Session Area ID, or an MBS Service Area.

In one variant, the identifier identifying the group of UEs may be realized as a combination or concatenation of identities/indications. For example, a RVQoE/QoE configuration may comprise a QoE reference or QoE Reference ID, and an MBS Session ID, where the combination of the two identities identifies the group of UEs.

The first network node 211 may request the UEs in the group of UEs, which are the target for the RVQoE/QoE configuration, towards which the RVQoE/QoE configuration has been sent/is being sent, or the UEs that received and applied a RVQoE/QoE configuration, the RVQoE/QoE configuration targeting a group of UEs , to send an indication, together with or as part of the corresponding RVQoE/QoE reports, indicating that RVQoE/QoE measurements are part of RVQoE/QoE measurements configured for a group of UEs e.g., a QoE-Reference-Group-ID, an MBS Session ID, or a TMGI, or a Session Area ID, or an MBS Service Area.

• In one option the first network node 211 may request the UEs of a group of UEs based on a certain criterion or certain criteria, non-limiting examples such as:

. the UEs with certain capabilities may/shall join the session.

. the UEs that currently are connected to a certain cell or a certain (Master or Secondary) cell group may/shall join the session.

. the UEs of a certain RRC state, e.g., RRCJNACTIVE may/shall join the session.

. the UEs with a certain allowed cell list (previously white list) may/shall join the session.

. the UEs of a certain cell category may/shall join the session, e.g. only UEs which has a suitable cell.

. the UEs that are in Camped Normally state may/shall join the session.

. the UEs in the same multi-connectivity setup, e.g., NR-DC, EN-DC. The examples listed in Action 310 a)-s) also apply here. Action 350

Collecting the RVQoE/QoE reports and/or QoE-related events from the UE group. The UEs 231 , 232 from the UE group send to the first network node 211 the RVQoE/QoE reports as requested, instructed, or configured by the first network node 211 . The reporting may be event-triggered, periodic, performed at the end of each session or performed on explicit request from the first network node 211.

Action 360

The first network node 211 analyzes the RVQoE/QoE reports and/or the QoE- related events and optionally performs optimizing adaptations based on the analysis. Optimizing adaptations may include aspects such as adapting a scheduling policy e.g. providing more or less resources for the data flow(s) of the concerned session, change of BLER target for transmitted data pertaining to the data flow(s) of the concerned session, change of MCS for transmitting of data pertaining to the data flow(s) of the concerned session, and/or change of MBS delivery mode e.g. changes between PTM and PTP or vice versa. The first network node 211 may compare the received RVQoE reports and/or QoE-related events from different UEs and, based on this, e.g. change the MBS delivery mode e.g. between PTM and PTP or vice versa for one or more of the UEs 231 , 232.

In one embodiment, the first network node 211 may, by comparing the reports from different subgroups of UEs within a group e.g., the subgroup consisting of one or more UEs with good and the subgroup consisting of one or more UEs with bad performance or QoE, determine the causes of bad QoE for the “bad QoE” subgroup.

In one embodiment, the first network node 211 may determine group-level information concerning RVQoE metrics I RVQoE values I RVQoE-related events I QoE- related events.

In some non-limiting examples the first network node 211 may determine: an average of Application Level Buffer, an amount of UEs/number of occurrences for which certain QoE-related events were fulfilled e.g., the number of times a QoE-related event occurred whose definition indicates that the event is fulfilled if stop reason is “rebuffering” for a DASH streaming service.

The first network node 211 e.g., a first RAN node may use the received RVQoE reports to determine a distribution of the values for a certain RVQoE metric and correlate this with the distribution of radio related measurements received from the same group of UEs. In one embodiment, the first network node 211 may send to a fourth network node group-level information concerning RVQoE metrics I RVQoE values I RVQoE-related events I QoE-related events. The possible node types for the fourth network node would be a super-set of the possible node types for the second network node 212 or for the third network node.

In a split architecture deployment, various options are possible, wherein the first network node 211 and the second network node are different entities of the same RAN node:

In one example, the first network node 211 may be a gNB-CU-CP and the second network node 212 may be a gNB-DU or a gNB-CU-UP.

In one example, the first network node 211 may be a gNB and the second network node 212 may be a gNB.

In one example, the first network node 211 may be a gNB-CU and the second network node 212 may be a gNB-DU.

In one example, the first network node 211 may be a gNB-CU and the second network node 212 may be a gNB-CU.

In one example, the first network node 211 may be a gNB-CU-CP and the second network node 212 may be a gNB-CU-CP.

In one example, the first network node 211 may be an eNB-CU-CP and the second network node 212 may be an eNB-DU or an eNB-CU-UP.

In one example, the first network node 211 may be an eNB and the second network node 212 may be an eNB.

In one example, the first network node 211 may be an eNB-CU and the second network node 212 may be an eNB-DU.

In one example, the first network node 211 may be an eNB-CU and the second network node 212 may be an eNB-CU.

In one example, the first network node 211 may be an eNB-CU-CP and the second network node 212 may be an eNB-CU-CP.

To perform the method in the first network node 211 for handling quality measurements for a group of UEs 231 , 232, the first network node 211 comprises modules as shown in Figure 5. The network node 211 comprises a receiving module 1110, a transmitting module 1120, a determining module 1130, a processing module 1140, a memory 1150 etc. The first network node 211 is configured to determine to execute quality measurements and/or to detect quality measurements related events for the group of UEs 231 , 232.

The first network node 211 is further configured to configure the group of UEs 231 , 232 based on obtained information on available quality measurements for the group of UEs 231 , 232.

The first network node 211 is further configured to receive reports on the quality measurements configured by the first network node 211 from the group of UEs 231 , 232.

The method according to embodiments herein may be implemented through one or more processors, such as the processor 1160 in the first network node 211 together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of computer readable medium or a data carrier 1180 carrying computer program code 1170, as shown in Figure 5, for performing the embodiments herein when being loaded into the first network node 211 . One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server or a cloud and downloaded to the first network node 211 .

To perform the method in the second network node 212, the second network node 212 comprises modules as shown in Figure 6. The second network node 212 comprises a receiving module 1210, a transmitting module 1220, a determining module 1230, a processing module 1240, a memory 1250 etc.

The second network node 212 is configured to receive a message from the fist network node 211 indicting an intention to configure quality measurements and/or to detect quality measurements related events for a group of UEs 231 , 232.

The second network node 212 is configured to send a response comprising an indication indicating one or more of the following information:

• Available services and measurements for the group of UEs (231 , 232);

• RVQoE measurement metrics that each UE in the group is allowed to collect;

• Rejection of providing information for some of the UEs in the group. The method according to embodiments herein may be implemented through one or more processors, such as the processor 1260 in the second network node 212 together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of computer readable medium or a data carrier 1280 carrying computer program code 1270, as shown in Figure 6, for performing the embodiments herein when being loaded into the second network node 212. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server or a cloud and downloaded to the second network node 212.

With reference to Figure 7, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP- type cellular network, which comprises an access network 3211 , such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the radio network node 12 herein, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first user equipment (UE) 3291 , being an example of the UE 330, located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221 , 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Figure 7 as a whole enables connectivity between one of the connected UEs 3291 , 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291 , 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211 , the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Figure 8. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350. The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Figure14) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Figure 8) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331 , which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides. It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Figure 8 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Figure 7, respectively. This is to say, the inner workings of these entities may be as shown in Figure 8 and independently, the surrounding network topology may be that of Figure 13.

In Figure 8, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the user equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both.

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Figure 8 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Figure 7, respectively. This is to say, the inner workings of these entities may be as shown in Figure 8 and independently, the surrounding network topology may be that of Figure 7.

In Figure 8, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the user equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may achieve an efficient RACH process and thereby provide benefits such as improved battery time, and better responsiveness.

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may achieve an efficient QoE reporting and thereby provide benefits such as improved UE experience, and better responsiveness.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311 , 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signalling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311 , 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc. Figure 9 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figures 7 and 8. For simplicity of the present disclosure, only drawing references to Figure 9 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Figure 10 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figures 7 and 8. For simplicity of the present disclosure, only drawing references to Figure 10 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Figure 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figures 7 and 8. For simplicity of the present disclosure, only drawing references to Figure 11 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Figure 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figures 7 and 8. For simplicity of the present disclosure, only drawing references to Figure 12 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.

As used herein, the term “processing module” may refer to a processing circuit, a processing unit, a processor, an Application Specific integrated Circuit (ASIC), a Field- Programmable Gate Array (FPGA) or the like. As an example, a processor, an ASIC, an FPGA or the like may comprise one or more processor kernels. In some examples, the processing module may be embodied by a software module or hardware module. Any such module may be a determining means, estimating means, capturing means, associating means, comparing means, identification means, selecting means, receiving means, transmitting means or the like as disclosed herein. As an example, the expression “means” may be a module, such as a determining module, selecting module, etc.

As used herein, the expression “configured to” may mean that a processing circuit is configured to, or adapted to, by means of software configuration and/or hardware configuration, perform one or more of the actions described herein.

As used herein, the term “memory” may refer to a hard disk, a magnetic storage medium, a portable computer diskette or disc, flash memory, random access memory (RAM) or the like. Furthermore, the term “memory” may refer to an internal register memory of a processor or the like.

As used herein, the term “computer readable medium” may be a Universal Serial Bus (USB) memory, a DVD-disc, a Blu-ray disc, a software module that is received as a stream of data, a Flash memory, a hard drive, a memory card, such as a Memory Stick, a Multimedia Card (MMC), etc.

It will be appreciated that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and apparatus taught herein. As such, the apparatus and techniques taught herein are not limited by the foregoing description and accompanying drawings.

Claims

Claims A method performed in a first network node (211) for handling quality measurements for a group of user equipment, UEs (231 , 232), in a wireless communication network (200), the method comprising: determining (310) to execute quality measurements and/or to detect quality measurements related events for the group of UEs (231 , 232); configuring (340) the group of UEs (231 , 232) based on obtained information on available quality measurements for the group of UEs (231 , 232); and receiving (350) reports on the quality measurements configured by the first network node (211) from the group of UEs (231 , 232). The method according to claim 1 , wherein the quality measurements are Radio Access Network Visible Quality of Experience, RVQoE, measurements and/or RVQoE values, and quality measurements related events are RVQoE and/or QoE related events. The method according to any one of claims 1-2, wherein the group of UEs (231 , 232) comprises any one or more of the following groups: a) A group of UEs receiving the same application layer session via broadcast or multicast; b) A group of UEs receiving data for an application session using the same radio resource; c) A group of UEs receiving data for the same application session; d) A group of UEs receiving the same service type or the same session while travelling in the same vehicle; e) A group of UEs that travel together; f) A group of UEs configured with the same Radio Access Network based Notification Area, RNA; g) A group of UEs in the same mobility state or not in a certain mobility state; h) A group of UEs subject to group mobility; i) A group of UEs served by shared spectrum; j) A group of UEs or part of the group of UEs placed in a factory and connected to the same private network; k) A group of UEs that are Fixed Wireless Terminals served by the same Radio Access Network node; l) A group of UEs providing radio connectivity to machines or devices that perform one or more tasks in a coordinated manner; m) A group of UEs with certain capabilities; n) A group of UEs in the same multi-connectivity setup; o) A group of UEs that are in certain cell(s) or cell groups, which have the same Master Cell Group, MCG, the same Secondary Cell Group, SCG, p) A group of UEs that have a certain cell category, a certain allowed cell list or a certain cell category; q) A group of UEs under coverage of some specific Synchronization Signal Block, SSB or Channel State Information Reference Signal, CRI-RS, beams; r) A group of UEs served by an Integrated Access and Backhaul, IAB, node or mobile IAB node; s) A group of UEs served by an IAB network, located a certain number of wireless hops from the IAB donor; t) A group of UEs connected to a network node using a network-controlled relay; u) A group of UEs associated with certain set of network slices or served by certain set of network slices.

4. The method according to any one of claims 1-3, wherein determining (310) to execute quality measurements and/or to detect quality measurements related events for the group of UEs (231 , 232) is based on any one or a combination of the following: a) minimization of Drive Tests (MDT) measurements or any other type of measurements; b) an indication from another network node; c) customer complaint.

5. The method according to any one of claims 1-4, further comprising receiving a management-based QoE configuration from a second network node (212).

6. The method according to any one of claims 1-4, further comprising: transmitting (311) a message to a second network node (212) or a third network node to indicate its intention to configure quality measurements and/or to detect quality measurements related events for a group of UEs (231 , 232).

7. The method according to claim 6, wherein the message comprises any one or more of the following: a) An indication indicating identities of UEs in the group; b) An indication indicating a reference or identity for the group of UEs (231 , 232); c) An indication indicating that quality measurements configuration is for a group of UEs; d) An indication indicating that configuring RVQoE measurement is for a group of UEs; e) A request for the second network node (212) to provide an indication of which RVQoE metrics/values and/or QoE-related event each UE in the group is allowed to provide; f) A request for the second network node (212) to provide an indication of which measurements metrics the group of UEs (231 , 232) is allowed to provide; g) A request containing a QoE reference of the concerned services and/or measurement configuration; h) A request containing parameters for the second network node (212) to include in the quality measurement configuration; i) A request for information and configuration of the UEs involved in a specific service.

8. The method according to claim 7, wherein the identity of a UE comprises any one of a Temporary Mobile Subscriber Identity, TMSI, a Subscription Permanent Identifier, SUPI, an International Mobile Subscriber Identity, IMSI, a Subscription Concealed Identifier, SUCI, a Globally Unique Temporary Identifier, GUTI, Globally Unique Access and Mobility Management Function Identifier, GUAMI, Globally Unique Mobility Management Entity Identifier, GUMMEI.

9. The method according to claim 7, wherein the group identifier for the group of UEs (231 , 232) comprises any one of a Multicast Broadcast Service, MBS, session identifier, a Temporary Mobile Group Identity, TMGI, a Group Radio Network Temporary Identifier G-RNTI, an Identifier of a mobile Integrated Access and Backhaul, IAB, node serving the group of UEs.

10. The method according to any one of claims 6-9, further comprising: receiving (320) a response from the second network node (212) comprising an indication indicating one or more of the following information:

• available services and measurements for the group of UEs (231 , 232);

• RVQoE measurement metrics that each UE in the group is allowed to collect;

• Rejection of providing information for some of the UEs in the group.

11 . The method according to any one of claims 6-9, further comprising: receiving information on available quality measurements for the group of UEs (231 , 232) from the UEs.

12. The method according to claim 11 , wherein configuring (340) the group of UEs

(231 , 232) comprising configuring RVQoE metrics which have corresponding QoE metrics in the QoE configuration, for one or more UEs in the group of UEs or for all the UEs in the group of UEs based on capabilities of UEs in the group of UEs.

13. The method according to claim 11 , wherein configuring (340) the group of UEs

(231 , 232) comprising configuring additional RVQoE metrics which have no corresponding QoE metrics for one or more UEs in the group of UEs or for all the UEs in the group of UEs based on capabilities of UEs in the group of UEs.

14. The method according to claim 11 , wherein configuring (340) the group of UEs

(231 , 232) comprising configuring additional RVQoE metrics in addition to RVQoE metrics which have corresponding QoE metrics in the QoE configuration for one or more UEs in the group of UEs or for all the UEs in the group of UEs based on capabilities of UEs in the group of UEs.

15. The method according to claim 11 , wherein configuring (340) the group of UEs

(231 , 232) comprising configuring additional RVQoE metrics which have specified corresponding versions of QoE metrics but these QoE metrics are not included in the QoE configuration, in addition to RVQoE metrics which have corresponding QoE metrics in the QoE configuration, for one or more UEs in the group of UEs or for all the UEs in the group of UEs based on capabilities of UEs in the group of UEs.

16. The method according to any one of claims 6-9, further comprising: receiving (330) a response from the third network node comprising any one of the following information:

• additional assistance information including configuration of the UEs according to the request by the first network node (211);

• a list of the UEs configured with different MBS configurations.

17. The method according to any one of claims 1-16, wherein configuring (340) the group of UEs (231 , 232) is performed by any one of the following:

• using individual Radio Resource Control, RRC, messages towards each UE;

• broadcasted in system information;

• including in a first message an indication indicating that an RVQoE configuration is being sent in a second message.

18. The method according to claim 17, wherein the RRC message conveying the configuration is any one of an existing RRC message, an enhanced existing RRC message or a newly defined RRC message.

19. The method according to claim 17, wherein the first message indicates the presence of a QoE configuration being sent or available for the UEs, or the presence of a RVQoE configuration being sent or available for the UEs. The method according to any one of claims 1-19, wherein configuring (340) the group of UEs (231 , 232) comprises sending an implicit or explicit indication identifying that the quality measurement configuration is targeting a group of UEs without any further details indicating the group of UEs, and/or an identifier identifying the group of UEs which are the target for the quality measurement configuration. The method according to claim 20, wherein the implicit or explicit indication is anyone of a QoE refence, a QoE Reference ID, a QoE Reference Group ID, an MBS Session ID, or a TMGI, or a Session Area ID, or an MBS Service Area. The method according to claim 20, wherein the implicit or explicit indication is a combination or concatenation of identities/indications comprising two or more of a QoE reference, a QoE Reference identity, an MBS Session identity, an MBS Session ID, a TMGI, a Session Area ID, an MBS Service Area, where the combination of the two or more identities/indications identifies the group of UEs. The method according to any one of claims 1-22, wherein Receiving (350) reports on the quality measurements from the group of UEs (231 , 232) comprising receiving reports on RVQoE/QoE measurements and/or QoE-related events. The method according to any one of claims 1-23, further comprising requesting the UEs in the group to send an indication, together with or as part of the corresponding reports on the quality measurements, indicating that RVQoE/QoE measurements are part of RVQoE/QoE measurements configured for a group of UEs. The method according to claim 24, wherein the indication is any one of a QoE reference, a QoE reference ID, a QoE-Reference-Group-ID, an MBS Session ID, or a TMGI, or a Session Area ID, or an MBS Service Area. The method according to any one of claims 1 -25, further comprising sending a request to the UEs of the group of UEs that received the quality measurements configuration to notify the first network node (211) that the configuration has been applied by the UEs. The method according to any one of claims 1-26, further comprising requesting the UEs of a group of UEs to join a session based on a certain criterion or certain criteria. The method according to any one of claims 1-27, further comprising: analysing (360) the reports on RVQoE/QoE measurements and/or the QoE- related events. The method according to claim 28, further comprising performing optimizing adaptations based on the analysing. The method according to claim 29, wherein performing optimizing adaptations based on the analysing comprises any one or more of the following:

• adapting a scheduling policy;

• providing more or less resources for data flow(s) of a concerned session;

• changing of Block Error Rate, BLER, target for transmitted data pertaining to data flow(s) of a concerned session;

• changing of Modulation and Coding Scheme, MCS, for transmitting of data pertaining to data flow(s) of a concerned session;

• changing of Multicast Broadcast Service, MBS, delivery mode. The method according to any one of claims 28-30, further comprising sending to a fourth network node group-level information concerning RVQoE metrics or RVQoEZ QoE-related events. The method according to claim 31 , wherein the type of the fourth network node is a super-set of the possible node types for the second network node (212) or for the third network node. A first network node (211) configured to perform the method according to any one of claims 1-32. A method performed in a second network node (212) for handling quality measurements for a group of user equipment, UEs (231 , 232) in a wireless communication network (200), the method comprising: receiving (311) a message from a fist network node (211) indicating an intention to configure quality measurements and/or to detect quality measurements related events for a group of UEs (231 , 232); and sending (320) a response comprising an indication indicating one or more of the following information:

• Available services and measurements for the group of UEs (231 , 232);

• RVQoE measurement metrics that each UE in the group is allowed to collect;

• Rejection of providing information for some of the UEs in the group. A second network node (212) configured to perform the method according to claim 34. The first network node (211) and second network node (212) according to claims 33 and 35, wherein:

• the first network node (211) is a gNB-CU-CP and the second network node (212) is a gNB-DU or a gNB-CU-UP; or

• the first network node (211) is a gNB and the second network node (212) is a gNB; or

• the first network node (211) is a gNB-CU and the second network node (212) is a gNB-DU; or

• the first network node (211) is a gNB-CU and the second network node (212) is a gNB-CU; or

• the first network node (211) is a gNB-CU-CP and the second network node (212) is a gNB-CU-CP; or

• the first network node (211) is an eNB-CU-CP and the second network node (212) is an eNB-DU or an eNB-CU-UP; or • the first network node (211) is an eNB and the second network node (212) is an eNB; or

• the first network node (211) is an eNB-CU and the second network node (212) is an eNB-DU; or • the first network node (211) is an eNB-CU and the second network node

(212) is an eNB-CU; or

• the first network node (211) is an eNB-CU-CP and the second network node (212) is an eNB-CU-CP. 37. A computer program product (1180) comprising computer program code (1170) which, when the program code (1170) is executed by a computer, cause the computer to carry out the method of any one of claims 1-32.

38. A computer program product (1280) comprising computer program code (1270) which, when the program code (1270) is executed by a computer, cause the computer to carry out the method of claim 34.