Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 26.942  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   5…   6…   7…   7.3…   7.4…   7.5…   7.6…   7.7…   7.8…   7.9…   7.10…   8…   9…

 

7.7  Solution #6: QMC-based monitoring and measurementp. 56

7.7.1  Key Issue mappingp. 56

This Candidate Solution addresses Key Issue #1 and Key Issue #2 using the QoE Measurement Collection (QMC) functionality summarised in clause 4.2.2.5.

7.7.2  Functional descriptionp. 56

7.7.2.1  Introductionp. 56

There is currently no solution enabling to monitor energy-saving actions at the application layer and in the RAN access stratum based on information provided by the application layer on the UE. To this end, an energy consumption-aware mechanism for media handling and delivery (in both uplink and downlink directions) based on QoE metrics collection, configuration and reporting is proposed here for different types of media services. The mechanism for media handling and delivery includes UE-side and network-side operations according to the reported energy consumption information.
This Candidate Solution focuses on the energy consumption monitoring. As a result of collecting and evaluating energy-related measurements on the UE, energy consumption in the network may be reduced, thus triggering network energy savings. A typical use case is for the network (potentially acting on behalf of an application) to initiate a campaign of UE energy measurements in order to evaluate the impacts of a specific action taken (e.g. updating some parameters of a media delivery session). In particular, in the context of QoE measurement, the network, or an application, can appreciate the relationship between QoE and energy consumption on the UE, that is to look for an optimum configuration that would save most energy on the UE whilst preserving the target QoE (trade-off).
In this context, this Candidate Solution proposes a method leveraging energy consumption information to monitor and measure the way the media content is handled and delivered to the users, and to provide better Quality of Experience (QoE) for users. Specifically, this Candidate Solution focuses on extending the UE QoE reporting mechanism with energy-related information.
Up

7.7.2.2  MTSI Quality of Experience (QoE) metricsp. 56

MTSI Quality of Experience (QoE) metrics is a relevant background for this Candidate Solution. As defined in TS 26.114, the metrics are valid for speech, video and text media, and are calculated for each measurement resolution interval "Measure-Resolution". They are reported to the OAM or QoE server via the gNodeB according to the measurement reporting interval "Sending-Rate", and also after the end of the session. The metrics defined in TS 26.114 include:
  • Corruption duration metric.
  • Successive loss of RTP packets
  • Frame rate
  • Jitter.
  • Sync loss duration.
  • Average codec bit rate
  • Codec information.
  • Call setup time.
However, the specified metrics don't include energy consumption related information.
Furthermore, the QoE configuration and reporting can optionally be specified by the QoE Measurement Collection (QMC) functionality. In this case, the QoE configuration is received via specific RRC messages for UMTS, RRC messages for LTE, and RRC messages for NR over the control plane, and the QoE reporting is also sent back via RRC messages over the control plane. An example signalling diagram for NR is reproduced in Figure 7.7.2.2-1 below.
Copy of original 3GPP image for 3GPP TS 26.942, Fig. 7.7.2.2-1: Example signalling diagram for NR
Figure 7.7.2.2-1: Example signalling diagram for NR
(⇒ copy of original 3GPP image)
Up
[Source: TS 28.405]

7.7.2.3  DASH Quality of Experience (QoE) metricsp. 57

TS 26.247 defines QoE metrics and procedures for progressive download and DASH media streaming. Configuration and reporting can be based on the same mechanisms (QMC) as for MTSI, or via MPD or OMA-DM.

7.7.3  Proceduresp. 58

This Candidate Solution proposes a new metric; procedures for reporting this metric from the UE to an external entity are described in solution #4 in clause 7.5.

7.7.3.1  Network-triggered QoE configurationp. 58

7.7.3.1.1  Introductionp. 58
QoE Measurement Collection (QMC) functionality can be reused according to one of the two following procedures.
7.7.3.1.2  Option 1: Adding Energy Consumption as a new flag in MTSI QoE reporting, relating to a specific media delivery sessionp. 58
The following signalling diagram is based on TS 26.114 for MTSI use cases.
Copy of original 3GPP image for 3GPP TS 26.942, Fig. 7.7.3.1.2-1: Example signalling diagram for Option 1
Up
The steps are as follows:
Step 0.
When UE starts/registers, the QMC handler of the UE indicates qoe-MeasReportcapability via UE Access Stratum when supported.
Step 1a.
The OAM sends QoE configuration requests with EC flag (energy consumption) inside MTSI QoE reporting request, which is associated with media session ID, time stamp, etc.
Step 1b.
The gNodeB triggers the QMC handler with for QoE reporting to collect QoE metrics.
Step 1c.
The QMC Handler within the UE triggers the MTSI Client to collect MTSI QoE metrics;
Step 2.
The MTSI Client in the UE collects Energy-related QoE metrics related to the media session. This may be done e.g. based on new AT commands between the UE Application Layer and the UE Access Stratum.
The UE may rely on the Energy Information Collector defined in Solution #5, including via the QMC handler entity.
Step 3.
A new QoE report is created and sent to OAM via QMC Handler, including the requested EC information in the MTSI QoE container.
Step 3c.
After the OAM has received UE energy consumption status report, the OAM may forward this information to an MnS Consumer (e.g. AF), the AF can accordingly propose an optimized network configuration (e.g. different QoS) or slice to the UE via the 5GC to fit the UE energy consumption status.
Up
7.7.3.1.3  Option 2: Dedicated QoE configuration for energy reporting onlyp. 59
Copy of original 3GPP image for 3GPP TS 26.942, Fig. 7.7.3.1.3-1: Example signalling diagram for option 2
Up
The steps are as follows:
Step 0.
The UE indicates to the gNodeB that it supports energy consumption measurement via capability = qoe-EC-MeasReport.
Step 1a.
The OAM requests energy consumption reporting via a dedicated QoE configuration request qoe-EC-MeasReport.
Step 1c.
The Energy Information Collector in the UE forwards this request to the client.
Step 2.
The client in the UE collects QoE metrics including the requested EC information and creates the new QoE report.
Step 3.
The UE sends the QoE report (periodically) to the OAM via UE (Energy Information Collector) with the requested EC information.
Step 3c.
After the OAM has received a UE QoE status report, the OAM may forward this information to an MnS Consumer (e.g. AF), the AF can accordingly propose an optimized network configuration (e.g. different QoS) or slice to the UE via the 5GC to fit the UE energy consumption status.
The same mechanisms apply to DASH and XR use cases using QMC: similarly to MTSI, the Energy Consumption information mentioned above can be incorporated into the qoe-Streaming-MeasReport QoE configuration request and reported using QMC.
Up

7.7.4  Summaryp. 59

This candidate solution introduces:
  1. New QoE metrics related to UE Energy Consumption by the UE, along with processing at the application level, which can be associated with a dedicated media session.
  2. UE-side configuration to optimize user experience based on the collected energy and media session QoE-related metrics, including requesting the network or AF to optimise the session or split-rendering support.
  3. Network-triggered mechanisms for configuration and reporting of UE energy metrics, either inside or outside the scope of QoE metrics collection for a particular media delivery session, as well as RAN-visible QoE reporting of UE energy consumption information.
The proposed solution involves coordinating with RAN and OAM since the solution involves sending information from the UE application to the OAM via gNodeB.
Up

Up   Top   ToC