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)?