This Candidate Solution partially addresses Key Issue#3 (Evaluation Framework) described in clause 6.3.

The methodology described in the Arcom/Arcep [61] study (as summarised in clause 4.2.6) is used as a point of departure for designing a UE energy consumption evaluation framework in the context of the present document. However, it is observed that [61] does not include energy consumption during the usage phase of all three tiers of the digital value chain (user devices, networks and data centres). In particular, no metrics or APIs are available today for the network and data centre aspects. Their scopes would be too broad to be addressed. These parts are for further study outside the scope of the present document. This is not the case for the user device part, because the required metrics and APIs are already available, at least on major smartphones Operating Systems, and are already used by regulators for evaluating the impact of some specific parameters. The ARCOM/ARCEP study [61] demonstrated their usefulness in evaluating the environmental impact of video codecs, video resolutions and frame rates. But this could easily be extended to other parameters such as different access network types (i.e., Wi-Fi, 5G, LTE) or content delivery modes (i.e., unicast, MBS, 5G Broadcast). For example, the Battery Manager API is available on Android [63], allowing the status of the UE battery to be interrogated by an application without the need for any external network connection. Using this API, it is possible to query the battery status at various points/intervals and to collate results over time to be able to calculate the energy usage of a specific workload. Samples can be taken periodically (e.g. once per second) including the timestamp, instantaneous battery current in microamperes and current battery voltage. From the collection of these data points, the energy (measured in Joules) is calculated as follows: There are a few limitations to measuring energy usage by this method:

1. Other applications or system processes running at the same time may affect the results.
2. The data collection itself service consumes some energy when collecting energy values. This artefact can be negated or controlled for by ensuring certain device conditions.

Contrary to the Test and Characterization Framework for Video Codecs described in TS 26.955, reference software tools are not used in this candidate solution. Real-life implementation is used as the anchor against which specific features are evaluated. Exact results from testing a specific model of device will not be generalised for all devices, nor for all implementations on that device or others.

The following methodology is proposed to measure energy consumption in the UE:

1. A test scenario is defined, and test conditions described in terms of:
   1. Network (connection type, upload and download bandwidth, latency).
   2. User device (type, model, SoC, OS version, video player).
   3. Test conditions (test duration, number of iterations, factory setting applied, etc.).
   4. Anchor against which the specific features will be evaluated (i.e., 5GMS service delivering a 720p video at 2 Mbps in HEVC).
   5. Reference sequence(s) used.
2. The application under test which implements the reporting of energy-related information is started.
3. The test is done for the anchor and the implementation including the feature evaluated.
   • The measurement period and the number of iterations performed are required to ensure relevance and to limit artefacts relating to the measurement itself.
   Two measurement modes are possible, selection is made according to the influence of the caching on the test:
   1. Systematic content change between iterations. This has the advantage of avoiding user-side CDN caching strategies but has the disadvantage of introducing variability with different content. This measurement also provides stronger representativeness of user behaviour.
   2. Iterations are conducted on a continuously played video. This has the advantage of controlling for the content, but the disadvantage of potentially underestimating consumption due to caching technologies.
4. Store results for non-real-time analysis.
5. Characterization is documented in terms of expected energy savings, and may include additional comparison parameters such as impact on the end user's Quality of Experience, etc.

Collection per-media-application of energy-related information, allowing energy use by certain computational workloads (e.g., battery current and battery voltage) over a cellular network to be measured and analysed offline, is needed.