Support for scope 3 energy/GHG reporting

[erik-reinhard]

Introduction

The regulatory environment in many countries and regions is pushing toward net zero, following various global and local initiatives. At the global level this includes the Kyoto Protocol and the Paris Agreement. Regional activities include the European Green Deal, which is now written into law (the European Climate Law), prescribing a legally binding commitment to climate neutrality by 2050, and a reduction of greenhouse gas emissions (GHG) of 55% by 2030.

Associated with these actions is a need to assess progress towards climate neutrality, therefore requiring monitoring, reporting and evaluation. The Greenhouse Gas Protocol, for example, offers worldwide standards for greenhouse gas emissions reporting for companies. These reporting standards define three scopes:

• Scope 1: direct emissions from owned or controlled resources,
• Scope 2: indirect emissions from the generation of purchased energy,
• Scope 3: all indirect emissions that occur in the value chain of the reporting company

This standard is currently enforced in Europe under the Corporate Sustainability Reporting Directive (CSRD), with 2024 being its first reporting year for the largest companies affected. Smaller companies may be begin reporting until January 2028 at the latest. The reporting applies to EU companies that exceed two of the following criteria: 1) more than 250 employees, 2) net revenue exceeding 40M euros, 3) total assets exceeding 20M euros. It also applies to non-EU parent companies with a cumulative turnover in the EU greater than 150M euros.

In the United States, the Securities Exchange Commission has issued official climate rules, mandating publicly listed companies (generating more than 700M USD) to report their climate impact, notably Scope 1 and Scope 2 emissions, while encouraging the reporting of Scope 3 emissions. Larger suppliers to the United States Federal Government are likely to become subject to Scope 1 and 2 reporting requirements through the US Federal Supplier Climate Risks and Resilience Rule. The Sustainability Accounting Standards Board provides non-mandatory standards for ESG (Environmental, Social, Governance) reporting which are increasingly adopted by US companies to meet investor demands for ESG data.

Finally, the State of California has enacted the Climate Corporate Data Accountability Act (SB 253), which requires companies with revenues exceeding $1B to report Scopes 1, 2 and 3 greenhouse gas emissions.

Standards in Telecommunications

In the realm of broadcasting and streaming, all the main standards setting organizations are currently considering or implementing standards that help reduce the energy requirements of the sector, and/or facilitate the reporting of climate impact. These include ITU-R, ITU-T, MPEG, 3GPP, DVB, ATSC and SMPTE.

CTA, currently defining v2 of the CMCD standard, can and should play an important role in supporting energy reduction and the facilitation of climate impact reporting. This is especially the case because it enables the flow of information from end user devices to relevant stakeholders. To this end, we request the support of Scope 3 reporting through a dedicated keyword, as described below.

Request for Keywords Supporting Scope 3 Reporting

For broadcasters and streaming platforms, the Scope 3 impact can be significant, especially when a program is watched by a large audience. In such cases, it can be much larger than the Scope 1 and 2 impacts. It is therefore extremely desirable to assess the Scope 3 impact through measurement where possible, rather than through estimation. This type of reporting involves the entire value chain of a reporting company. For a broadcaster or streaming platform, this includes for example the origin server, data centers, CDNs, access networks, and end user devices, insofar not self-owned. Studies have shown that the impact of televisions on the total energy consumption involved in transmitting and viewing content is non-negligible.

Scope 3 reporting of the climate impact of an end user device can be managed through CMCD, even if this presents some challenges on the side of the player running on the end-user device. To be consistent with the Greenhouse Gas Protocol, as made a reporting requirement in Europe and in California, the greenhouse gas emissions would have to be reported. Currently this would be difficult to achieve, but various options are open that would make the problem more tractable.

To fulfill Scope 3 reporting requirements, an end user device should ideally report the greenhouse gas emissions caused by its operation. The following information would allow compliance with the Greenhouse Gas Protocol:

• Energy (or average power) consumed,
• Start and end time stamps
• Carbon intensity
• Recipient (already available in CMCD v2 spec)

The reporting of energy or power usage should be straightforward the moment that end user devices have built-in power meters (as advocated by Greening of Streaming). Power use in mobile devices can be inferred by querying the battery state. In the absence of a measurement facility, the energy and power use could be inferred programmatically.

The reporting period may be indicated with start and end time stamps. It would be advantageous if the timing information would allow the Scope 3 message to be linked to a specific segment of the content being shown. For example, the time stamps could be specified in number of minutes/seconds since the start of the content.

The recipient of the energy report should be indicated. This could either be a fixed report collection service, or in a future scenario it could be derived from the (metadata associated with) the content being delivered to the end user device. In essence, the entities subject to reporting requirements should receive the information.

To be compatible with the Greenhouse Gas Protocol, it would be desirable to obtain a local estimate of the carbon intensity. The carbon intensity is measured in grammes CO2-equivalent per kWh. Such an estimate relates to the source of the electricity powering the end user device, and it can be obtained from a number of sources. In its simplest form, the display device lets the user set the energy intensity directly, or if the user is given the option to name the source of the device's energy. Either solution would be useful in the case the end user device is connected to a locally owned power source (such as a solar panel or a diesel generator). If the device is connected to a wall socket, then the energy intensity could be derived through a combination of location services or localization based on IP-address, and local energy forecasts provided by APIs provided by a variety of online services (such as Grid Status, Electricity Maps or WattTime). Fall-back solutions would be using national grid averages.

The timing of Scope 3 reports would be governed by events detectable by the media player. In particular, certain events may trigger the sending of a report, such as changing to a different channel, switching off a device, or the start/end of an interstitial (as this would potentially involve a different stakeholder). In any case, the aim is to reduce the number of reports sent to ensure that the reporting activity itself does not consume undue energy. Thus, the Event Mode (reporting mode #3) is appropriate for this kind of report.

As the values transmitted may be different in each message, the header field CMCD-Request should be used, except for the carbon intensity key, as it will not vary over the course of a session (but may vary between sessions). While the requested values could be defined as separate keys, a flexible approach would be to define a single key containing a string, as follows:

Description Energy-Related Information Report
Key Name erir
Header Name CMCD-Request
Type & Unit String
Value Definition A string describing energy use, start and end times and carbon intensity.
Allowed with Reporting Mode 3 Yes

The formatting of the string would follow this C-like syntax
"ec=%f, est=%" PRIu64 ", eet=%" PRIu64 ",ci=%f"

In this string, the values are specified in floating point and 64-bit unsigned integers, and are interpreted as follows:

• ec: energy consumed, a floating point value specifying the amount of energy consumed in mWh.
• est: energy start time, an integer specifying the number of milliseconds since UNIX epoch. It indicates the start time over which the energy measurement/estimate is performed. This should be specified as a 64-bit unsigned integer to avoid the year 2038 buffer-overflow problem.
• eet: energy end time, an integer specifying the number of milliseconds since UNIX epoch. This is the end time over which the energy measurement/estimate is performed. It should be specified as a 64-bit unsigned integer.
• ci: carbon intensity, a float specifying the estimated carbon intensity of the energy source, in milligram CO2-e / Watt-hour

Note that the units of measurement are in SI units to guarantee interoperability.

[nicolaslevy]

Thanks @erik-reinhard, can you guide us to understand how to get this information in the main platforms (Browsers, iOS, Android)?

[erik-reinhard]

Apologies for the delay in responding to you, and many thanks for your question. I believe that the information requested here can be made available to applications running in different environments. This discussion also comes up in other standards bodies, notably 3GPP. Gleaning information from there, I can say the following:

• On Android devices, it seems to be possible to get battery information, from which power measures can be derived. The example I've seen comes from AccuBattery (https://play.google.com/store/apps/details?id=com.digibites.accubattery&pli=1).

• Likewise on iOS devices: https://apps.apple.com/us/app/digital-power-meter/id1509657723
• 3GPP report TR 26.942 mentions a conversion from current to energy: joules = currentInAmps × timeDifference × voltage. Likewise, a conversion from current to power can be performed: watts = currentInAmps x voltage.
• For computers there is an API that can be consulted to obtain power/energy measurements at various granularities: https://powerapi.org/

For carbon intensity, it would be possible to use location-based services (either through IP address, or based on a mobile device's in-built location services). With an approximate location available, it is possible to consult any one of a number of API's that make localised carbon intensity information available. Example APIs are:

• https://carbonintensity.org.uk/
• https://www.electricitymaps.com/
• https://developers.thegreenwebfoundation.org/api/ip-to-co2/overview/
• https://docs.watttime.org/

I hope that this goes towards answering your question.

[slhck]

Interesting suggestion! The main issue with desktop/browser-based tools and the power API you mentioned is that the solution is a) highly specific to certain processor architectures and b) limited to operating-system processes.

For instance, if you look at the documentation here, it says:

This technology is only available on Intel Sandy Bridge architecture or newer. However, Intel Core Tiger Lake, Alder Lake and Raptor Lake families for desktop and mobile are not supported. The sensor is also available on AMD Zen (1,2,34). Power/ARM/RISCV are not supported architectures.

A browser process cannot query this data because the web context has no APIs. Any information about the host that is relevant for the web context would have to be exposed (e.g., like through the WebGPU API). There is a related proposal by the W3C to expose CPU usage but it does not include power consumption. So unless there is a browser API to get resource consumption for the current web context, this will be impossible.

(There are Chrome extension APIs to get CPU information and process information, but these would be unavailable for a streaming provider anyway.)

[erik-reinhard]

On the technical side, it seems that there is some browser support for energy measurement, as per the following article:

         https://www.devsustainability.com/p/measuring-website-energy-consumption

However, getting at the required information is surely fragmented today. Different systems require different approaches, which is certainly not ideal. On the other hand, it remains very important to make some headway with reporting. To not get caught in a situation where everybody is waiting for everybody else, I would propose that my request is included in the v2 spec as an optional field.

For an organisation such as a streaming company or a broadcaster wishing to perform Scope 3 reporting, currently only coarse estimates could be employed. If the requested field were available as an option, methods could be developed whereby these estimates are bit-by-bit replaced with measurements where available --- thereby increasing the accuracy of reporting.

Given that such reporting is written into regulatory frameworks (Europe’s CSRD, for example), it would be really helpful if infrastructure could be put in place that facilitates responding to such requirements. And given that we have to start somewhere, CMCD v2 would be an excellent low-cost / low-effort way to break the deadlock.