This approach is based on the volume of data transferred, such as kilowatt-hours per gigabyte (kWh/GB) or total kilowatt-hours (kWh), and allows for the allocation of emissions according to the amount of data consumed.

So if that cat meme we have been dying to send is 1MB and the network intensity is 5 Wh/GB, sending 1,000 memes would cost about 5 Wh. The factor can include just operational energy (e.g. routers, switches, towers) or also embodied infrastructure energy (depending on the scope), and can be converted to CO₂ using a grid emissions factor (global or region-specific).

Strengths:

• Clear attribution
  • e.g., within an organization: “Team A’s cat meme uploads used 500 GB last month = X kWh and Y kg CO₂”, helping teams see who’s using the most bandwidth and why
• Simple and Actionable
  Just data x factor. Once you know that more memes = more emissions, it becomes obvious where to cut waste (like oversized images or uncompressed videos).
• Enables teams to spot the “big offenders”
  By measuring impact per GB, it helps teams identify the real data hogs like an autoplaying cat video feed so they know where to optimise (e.g., compress, cache, or cut).
• Drives Efficiency Wins
  Sending less data reduces energy use directly (servers, devices) and indirectly (less pressure on network infrastructure). Cutting back during peak times can delay costly expansions like new routers or base stations, avoiding extra operational and embodied emissions.

Challenges:

• Network infrastructure energy use does not scale proportionally with data volume
  • e.g., this means that Internet hardware (routers, towers) stay powered on even when no cat memes are being sent. So sending one extra meme at midnight might use almost no extra energy, while sending it during peak hours could strain the network and trigger more energy use. The “per GB” model does not capture this non-linearity.
• Global average values ignore context
  • Physical distance between client and server
  • Geographic location (and local grid CO₂ intensity)
  • Transmission type (DSL, Wi-Fi, mobile, satellite, etc.)

Limitations:

• Misleading for Change
  If your app compresses memes, the model might claim “50% less energy!” But unless the underlying hardware powers down, the real savings are much smaller. It also assumes doubling meme traffic doubles emissions, which isn’t true when networks are under capacity.
• Accuracy Depends on Data
  Without knowing total network energy and traffic, the numbers are just rough guesses. If some parts of the system (like mobile towers) are left out, emissions are underestimated.

Summary:
The “energy per meme” model is easy to use and great for quick insights. It helps teams cut waste and track emissions by linking data volume to energy use.
But it oversimplifies reality, ignoring how networks actually consume energy.

Bottom line:
A useful starting point for action — not a precise measurement tool.

Even within the energy intensity approach, the assumed factor (Wh per GB) can vary wildly. Different tools and studies quote very different numbers for network energy per data, depending on scope and methodology. Let’s compare a few notable ones:

Tool Comparison

Why do Network Energy Estimates vary so much?

Estimates range from under 2 Wh/GB to over 70 Wh/GB — that’s a 40× difference! Why? It depends on what’s included in the calculation!
System boundaries vary. Some models only include core networks, while others factor in access networks, end-user devices, and even manufacturing.

Low estimates (e.g. GMT ~1.9 Wh/GB):

• Based on a bottom-up estimation.
• Extrapolated value for 2025 from Aslan et al. on fixed-line networks (i.e. does not include end-user networking equipment).
• Operational-only: does not include embodied emissions.

High estimates (e.g. CO2.js at 72 Wh/GB, Cardamon at 59 Wh/GB):

• Based on a top-down estimation.
• Include everything: core + access networks (including end-user networking equipment), and embodied carbon (e.g. emissions from manufacturing hardware).
• Designed to capture the full lifecycle impact.

Research-Based Estimates

Aslan et al. (2018):

• Found relative low energy use (0.06 kWh/GB for 2015) for moving data through the core Internet.
• Rule: the electricity intensity of network transfer decreases by half approximately every two years.
• Did not include mobile networks, home routers or Wi-Fi.
• Useful for best-case scenarios, but hugely underestimates total Internet energy use — by 5 to 25×.

Coroamă (2021):

• Broke down the Internet into:
  • WAN (core backbone): very efficient (0.02 kWh/GB for 2020)
  • FAN (home routers/local networks): medium use (0.07 kWh/GB)
  • RAN (mobile networks): most energy-hungry (0.2 kWh/GB)
• Sending 1 GB over mobile can use 30× more energy than over fiber.
• Predicted mobile data will remain most energy-intensive by 2025.

Guennebaud & Bugeau (2024):

• Warned against relying on “average energy per GB”.
• Argued we need more context — like when and how data is sent — for accuracy.

Mytton, Lundén & Malmodin (2024):

• Highlights that networks consume energy just to stay on, even when idle.
• Data reduction doesn’t always mean energy reduction — especially short-term.
• Recommends using the power model.

Seeliger et al. (2024):

• Wrote a guide on measuring emissions from video streaming.
• Provides a good overview of the topic and compares the different estimation models.

Which Network Segments Should Be Included?

When calculating network emissions for your software, define your system boundary. Here’s a breakdown:

• WAN (Wide Area Network): Core of the internet — long-distance links and routers. Low and decreasing energy per GB. Some tools only include WAN.
• FAN (Fixed Access Network): “Last mile” to users — local ISPs, fiber/cable, Wi-Fi routers.
• RAN (Radio Access Network): Mobile networks — most energy-hungry. Should be included for mobile-first apps.

Important Notes:

• CPE energy use can exceed WAN energy use. (CPE = customer premises networking equipment)
• RAN is 10–30× more energy-intensive per GB than WAN.

GMT Capabilities:

• Measures backend and frontend systems.
• For backend-only activity (e.g., data center to data center), including user networks overstates emissions.

Example Calculation (1 GB transfer, Coroamă, 2020):

• Only WAN: 0.02 kWh
• WAN + 50% FAN + 50% RAN: 0.155 kWh → 7.75× higher
• Mobile-only usage: 0.22 kWh → 11× higher

So What Segments Should You Include?

Include the segments that significantly contribute to your software’s operation.

• If mobile-first: include RAN + FAN
• If enterprise on wired networks: FAN only
• Always include WAN

The Green Software Foundation’s SCI standard says to include any infrastructure that meaningfully supports your software.

In GMT, we assume:

• 90% fixed (FAN), 10% mobile (RAN)
• Always include WAN

Reminder: Wi-Fi is part of FAN, not RAN (So even if users are on phones, they are often using fixed-line networks when on Wi-Fi).

But if you’re measuring backend-only activity—like server-to-server transfers in a data center—then including access networks (FAN/RAN) would overestimate emissions. Context matters. Define your boundary based on how your software is actually used.

GMT can calculate the SCI score for a given use case scenario.
Should estimated network impacts be included in the SCI score?

Pro (Include):

• Network is a major emissions source in some apps.
• Avoids blind spots and burden shifting.
• Aligns with SCI’s principles.

Con (Exclude or Treat Carefully):

• Simplistic methods distort outcomes.
• Might incentivize data savings that don’t cut real emissions.
• Unfair comparisons: Wi-Fi vs. mobile.
• Hard to verify: ISP data is opaque.

Verdict:

Don’t include network emissions (via kWh/GB) in the SCI score as it is too simplistic and can give a false sense of precision, mislead optimisation efforts, and make scores hard to compare. Use them as a separate diagnostic for awareness and improvement.