| Internet-Draft | ISAC-Utilization | November 2026 |
| Jadoon & Robitzsch | Expires 6 May 2027 | [Page] |
This document defines a YANG data model to report a Sensing Utilization Score (US) for sensing workloads. The US is an abstract, normalized score (0..100) that summarizes the relative resource cost of executing a sensing operation on a device.¶
The model supports a mandatory overall US and optional explanatory component impact scores (compute, memory, energy, storage, latency). The model also supports optional metadata (e.g., timestamp, aggregation window, and scoring method identification) describing how a reported score was derived.¶
The model includes a companion augmentation module that attaches sensing utilization telemetry to a GREEN Energy Object, as defined by the GREEN Power and Energy YANG Module, for correlation with power and energy telemetry.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Network nodes can perform sensing tasks alongside communication tasks. Sensing use cases and requirements have been studied in 3GPP (e.g., TR 22.837) and ETSI (e.g., GR ISC001), and sensing is included among the use cases considered by the GREEN Working Group [I-D.ietf-green-use-cases].¶
Sensing involves the collection of data using radio-frequency (RF), including radar-like techniques, and non-RF techniques. Different sensing use cases can consume different amounts of compute, memory, energy, and storage resources, and can also constrain latency.¶
To enable energy-aware orchestration, it is useful to report an abstract utilization score that summarizes the resource impact of executing a sensing task.¶
This document defines a Sensing Utilization Score (US): an implementation-defined, normalized value in the range 0..100 where higher means "more costly" in the given deployment.¶
The model allows sensing-enabled devices to report:¶
a mandatory overall US;¶
optional explanatory component impact scores (compute, memory, energy, storage, latency); and¶
optional metadata describing how the score was derived.¶
The sensing US provides a compact and implementation-defined score that can be used by controllers and orchestrators to compare sensing configurations and to support energy-aware sensing decisions.¶
When used together with the GREEN Power and Energy YANG Module [I-D.ietf-green-power-and-energy-yang], the sensing US can be reported as use-case telemetry associated with a GREEN Energy Object. This allows a controller to correlate sensing utilization with the power and energy telemetry of the component on which the sensing workload executes.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The model is intended for systems that support sensing and want to participate in energy-aware operations.¶
The model reports the resource impact of sensing workloads on network devices and their components. It applies to radio-frequency and non-radio-frequency sensing.¶
The model is telemetry-only, meaning all data nodes defined in this document are operational state. Standard YANG telemetry mechanisms (polling and/or subscriptions such as YANG Push) can be used to collect the data and will be defined in the GREEN Controller YANG Model [I-D.swepcarl-green-controller-yang].¶
This model defines the telemetry to be reported. Selection of data nodes, collection mechanisms, reporting policies, and delivery destinations are handled by the applicable collection or subscription models.¶
This document does not define power-state control. If a management system uses sensing utilization telemetry to drive energy-saving actions, such as changing a component power state or reducing operating capacity, the actual control operation is expected to be performed using the applicable control model, such as the energy-control subtree in the GREEN Power and Energy YANG Module.¶
The GREEN Working Group has defined a base YANG module for Power and Energy monitoring and control of Energy Objects [I-D.ietf-green-power-and-energy-yang]. That model provides the general power and energy telemetry framework. This document defines a sensing-specific use-case telemetry model that can be used together with that base model. When sensing operations run on the same physical component(s) that are represented as Energy Objects, it is beneficial to be able to correlate:¶
for the same scope. This document implements the Energy Object augmentation approach in this revision via a companion augmentation module that binds sensing utilization to an existing Energy Object. Section 3.2 documents a future consideration for software/service-scoped reporting, which may require future extensions to the GREEN base model or a related companion model.¶
This document introduces an augmentation module, ietf-sensing-utilization-power-and-energy. It augments the Energy Object list entry (energy-object) defined in the GREEN Power and Energy YANG module with a sensing-utilization container that reuses the subtree defined by ietf-sensing-utilization.¶
This path allows:¶
Minimal disruption: it does not change the GREEN base model.¶
Correlation by construction: the sensing utilization score is attached to the same energy-object instance that exposes power/energy metrics.¶
Compatibility with standalone deployments that do not use the GREEN base models.¶
Interpretation guidance:¶
Implementations SHOULD publish the Sensing Utilization Score (US) on a single Energy Object that best represents the sensing execution scope (e.g., chassis/device, baseband unit, radio unit, or dedicated accelerator).¶
If the sensing pipeline spans multiple Energy Objects, one Energy Object SHOULD be designated as the primary anchor for the consolidated US (typically where scheduling or admission-control decisions are made).¶
Additional scope-specific US values MAY be reported on other Energy Objects only when they represent materially different execution scopes.¶
Controllers should compare scores only where the scoring method, version, normalization basis, reporting scope, and observation period are compatible. Scores from different Energy Objects should not be summed or averaged unless the scoring method defines that operation. Association with an Energy Object identifies the reporting scope; its power and energy measurements may include other workloads sharing that scope.¶
This guidance is operational in nature and does not impose schema-level constraints.¶
In many deployments, sensing functionality is not a physical component by itself. It may be implemented as software, firmware, a containerized function, a virtualized network function, an edge application, or a service workload running on one or more physical components. Examples include a sensing coordination function, a sensing data generation function, a sensing processing/fusion function, or an AI/ML-based sensing analytics function [ETSI-GR-ISC003].¶
The GREEN Power and Energy base model provides Energy Objects for power and energy monitoring and control. In the current base model, an energy-object is primarily associated with a physical component, for example through the hardware component reference. This is sufficient for the integration approach used in this document, where sensing utilization is reported against the Energy Object that best represents the physical execution scope.¶
However, energy-aware control decisions often require more than knowing the total power or energy consumption of a hardware component. A controller may need to understand which services, functions, or workloads are active on the component, how they contribute to resource usage, and what service-level impact may result if the component is reconfigured. For example, a controller considering whether to move a component into a lower power state, switch off a port, disable a hardware accelerator, or reduce the operating capacity of a subsystem should understand whether a sensing function is using that component.¶
Without service-to-component visibility, a controller can observe that a hardware component consumes power, but it cannot reliably determine whether that consumption is associated with sensing, communication or another workload. As a result, control actions may either be too conservative, leaving energy-saving opportunities unused, or too aggressive, degrading an active service whose dependency on the component was not visible.¶
This is particularly relevant for sensing because sensing operations are multi-dimensional. A sensing task can consume or constrain radio, compute, memory, storage, latency, and energy resources. Furthermore, sensing service quality is often bounded by sensing KPIs such as accuracy, resolution, confidence level, refresh rate, and latency. Therefore, a controller that performs energy optimization should not only observe hardware-level power and energy values, but should also be able to attribute, estimate, or correlate those values with the sensing functions or sensing services that cause or depend on the corresponding resource usage.¶
Such visibility also helps avoid incorrect control decisions in shared or virtualized deployments. A single physical component may support multiple logical functions, and a single logical function may span multiple physical components. In such cases, a service-scoped view can help a controller determine whether to migrate a sensing function, alter a sensing configuration, reduce sensing data reporting, change the set of sensing entities, or keep a component active because it supports an ongoing sensing task.¶
This document does not define software-scoped or service-scoped Energy Objects, and it does not require such support from the GREEN base model. Instead, the current revision uses the Energy Object augmentation approach defined in Section 3.1. In this approach, sensing utilization is attached to the Energy Object that best represents the physical execution scope.¶
Future GREEN base model work could consider whether Energy Objects, or a related companion model, should support software, service, workload, or logical-function scopes. Such support could include one or more of the following capabilities:¶
an object class or object type indicating whether the Energy Object represents hardware, software, a service, or a workload;¶
a generic reference from an Energy Object to the managed object that it represents, for example a software function, process, container, virtualized function, or service instance;¶
relationships between software/service Energy Objects and the hardware Energy Objects on which they execute;¶
guidance for attribution and aggregation so that software-scoped utilization or energy estimates do not result in double counting against hardware-level power and energy measurements;¶
time-window alignment between software/service utilization telemetry and hardware-level power and energy telemetry;¶
guidance on how controllers can use service-scoped telemetry when deciding whether to change the power state or operating capacity of a hardware component.¶
If such software/service scoped Energy Objects are defined in a future version of the GREEN base model or in a companion module, the reusable sensing utilization subtree defined in this document can be applied at that scope. This would allow sensing utilization to be reported directly for a sensing function or sensing service, while still allowing correlation to the underlying hardware Energy Objects.¶
This consideration is included to document the sensing use case for future GREEN discussions. It is not required for implementations of this revision.¶
The following tree diagrams summarize the YANG modules in this document. The augmentation target follows the YANG module in revision -04 of [I-D.ietf-green-power-and-energy-yang].¶
module: ietf-sensing-utilization
+--ro sensing-utilization!
+--ro overall-utilization-score score-0-100
+--ro timestamp? yang:date-and-time
+--ro aggregation-window? duration-milliseconds
+--ro component-scores {component-breakdown}?
| +--ro compute-impact-score? score-0-100
| +--ro memory-impact-score? score-0-100
| +--ro energy-consumption-impact-score? score-0-100
| +--ro storage-impact-score? score-0-100
| +--ro latency-impact-score? score-0-100
+--ro metadata
+--ro score-method? identityref
+--ro score-method-version? string
+--ro score-provenance? enumeration
+--ro sample-count? uint32
+--ro confidence-level? score-0-100
¶
module: ietf-sensing-utilization-power-and-energy
augment /eo:energy-objects/eo:energy-object:
+--ro sensing-utilization!
(uses ietf-sensing-utilization:sensing-utilization-body)
¶
module ietf-sensing-utilization {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sensing-utilization";
prefix sensing-util;
import ietf-yang-types {
prefix yang;
reference "RFC 9911: Common YANG Data Types";
}
organization "InterDigital Europe";
contact
"Muhammad Awais Jadoon <muhammad.awaisjadoon@interdigital.com>
Sebastian Robitzsch <sebastian.robitzsch@interdigital.com>";
description
"Reports normalized utilization *scores* for sensing workloads.
This module intentionally reports *scores* (normalized 0..100) rather
than raw measurements (e.g., Watts, Joules, CPU cycles). The goal is to
provide a compact, implementation-defined indicator that higher-layer
controllers can compare across sensing configurations.
Terminology:
* Sensing Utilization Score (US): a normalized value in the range 0..100
where higher means 'more costly' to execute in the given deployment.
* Component impact scores (optional): normalized components that explain
which resource dimension(s) contribute to the US.
The model supports:
* a mandatory overall US;
* optional component impact scores (compute, memory, energy, storage,
latency); and
* optional metadata describing how the score was derived.
Notes:
* This model does not prescribe how scores are computed.
* Component impact scores are explanatory, and are not meant to replace
dedicated telemetry models for compute, memory, storage, etc.
This module also defines reusable groupings so that other modules can
augment existing YANG models (e.g., GREEN base models) with sensing
utilization telemetry without duplicating the subtree definition.";
revision 2026-11-02 {
description
"Use sensing terminology, make reporting containers optional, and clarify score interpretation.";
reference "draft-jadoon-green-isac-utilization";
}
revision 2026-02-23 {
description
"Draft -04 update (corrected):
* Align all score leaves to a single normalized score type (0..100).
* Add optional metadata to interpret the score.
* Remove per-measurement related objects to keep the model focused on
an overall utilization score.";
reference "draft-jadoon-green-isac-utilization";
}
revision 2025-10-17 {
description
"Initial revision (draft-jadoon-green-isac-utilization-02).";
reference "draft-jadoon-green-isac-utilization";
}
feature component-breakdown {
description
"Expose optional component impact scores (compute, memory, energy,
storage, latency) that contribute to the overall Sensing Utilization
Score (US).";
}
typedef score-0-100 {
type uint8 {
range "0..100";
}
description
"A normalized score in the range 0..100.";
}
typedef duration-milliseconds {
type uint64;
units "milliseconds";
description
"A time duration expressed in milliseconds.";
}
identity us-score-method {
description
"Base identity for Sensing Utilization Score (US) computation methods.
Derived identities can be defined by vendors, operators, or other
standards to identify the specific scoring method/profile used.";
}
identity us-score-method-implementation-specific {
base us-score-method;
description
"A generic derived identity indicating that the US computation
method is implementation-specific and not further identified.";
}
identity us-score-method-vendor-defined {
base us-score-method;
description
"A derived identity indicating that the US computation method
is vendor-defined.";
}
identity us-score-method-operator-policy {
base us-score-method;
description
"A derived identity indicating that the US computation method
follows an operator-defined policy/profile.";
}
grouping utilization-component-scores {
description
"Optional component impact scores contributing to a Sensing Utilization
Score (US).
Each leaf is a normalized (0..100) impact score for a resource
dimension. Implementations MAY omit this entire container by not
advertising the 'component-breakdown' feature.";
leaf compute-impact-score {
type score-0-100;
description
"Normalized compute impact component (0..100).";
}
leaf memory-impact-score {
type score-0-100;
description
"Normalized memory impact component (0..100).";
}
leaf energy-consumption-impact-score {
type score-0-100;
description
"Normalized energy impact component (0..100).
This is NOT energy consumption (e.g., Joules); it is an explanatory
score component.";
}
leaf storage-impact-score {
type score-0-100;
description
"Normalized storage impact component (0..100).";
}
leaf latency-impact-score {
type score-0-100;
description
"Normalized latency impact component (0..100).";
}
}
grouping utilization-metadata {
description
"Optional metadata describing how a score was derived and how to
interpret it.
The metadata is intended to support correlation and comparability
across implementations and deployments.";
leaf score-method {
type identityref {
base us-score-method;
}
description
"Identifier for the scoring method/profile used to compute the US.
If not reported, or if an unknown derived identity is reported, the
receiver SHOULD treat the score-method value as an opaque identifier.";
}
leaf score-method-version {
type string;
description
"Version of the scoring method/profile (e.g., semantic version).";
}
leaf score-provenance {
type enumeration {
enum measured {
description
"Score derived from directly observed resource usage (measured).";
}
enum estimated {
description
"Score derived from estimation or modeling (estimated).";
}
enum aggregated {
description
"Score derived from aggregation of other scores/telemetry.";
}
}
description
"Indicates the origin of the score computation.";
}
leaf sample-count {
type uint32;
description
"Number of samples/observations used to compute the score over the
aggregation window (if known).";
}
leaf confidence-level {
type score-0-100;
units "%";
description
"Confidence in the reported score (0..100).
A value of 100 indicates high confidence that the score reflects the
current sensing workload under the specified aggregation window.";
}
}
grouping sensing-utilization-body {
description
"Reusable sensing utilization reporting structure.";
leaf overall-utilization-score {
type score-0-100;
mandatory true;
description
"Overall Sensing Utilization Score (US) for the reporting scope (0..100).";
}
leaf timestamp {
type yang:date-and-time;
description
"End time of the aggregation.";
}
leaf aggregation-window {
type duration-milliseconds;
description
"Length of window ending at timestamp.
For example, 60000 represents 60 seconds.";
}
container component-scores {
if-feature component-breakdown;
description
"Optional component impact score breakdown.";
uses utilization-component-scores;
}
container metadata {
description
"Optional metadata describing how the score was derived.";
uses utilization-metadata;
}
}
container sensing-utilization {
presence
"Indicates that sensing utilization telemetry is available
for this reporting scope.";
config false;
description
"Sensing utilization reporting at device/node scope.";
uses sensing-utilization-body;
}
}
¶
module ietf-sensing-utilization-power-and-energy {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sensing-utilization-power-and-energy";
prefix sensing-pe;
import ietf-sensing-utilization {
prefix sensing-util;
reference "draft-jadoon-green-isac-utilization";
}
import ietf-power-and-energy {
prefix eo;
reference
"draft-ietf-green-power-and-energy-yang-04: Power and Energy YANG Module";
}
organization "InterDigital Europe";
contact
"Muhammad Awais Jadoon <muhammad.awaisjadoon@interdigital.com>";
description
"Path 1 integration module between sensing utilization reporting and the
GREEN Power/Energy base model.
This module augments the 'energy-object' list (an Energy Object) defined in
ietf-power-and-energy with a sensing-specific utilization container. This
enables correlation between:
* power/energy telemetry from ietf-power-and-energy; and
* sensing utilization telemetry (overall score and optional breakdown)
for the same physical scope.
Interpretation guidance:
* The sensing utilization values are normalized scores (0..100) and MAY
include non-energy explanatory components (compute, memory, storage,
latency) to explain why a sensing configuration consumes energy or
constrains energy-saving policies.
* To avoid double counting, implementations SHOULD report this container
on the Energy Object that represents the sensing execution scope (e.g., the
chassis/device, baseband unit, or a dedicated accelerator), rather than
repeating the same score verbatim on multiple Energy Objects.
The 'sensing-utilization' container is optional per energy-object and can be
omitted for Energy Objects where sensing utilization is not applicable.";
revision 2026-11-02 {
description
"Use sensing terminology, make reporting optional per Energy Object, and align the augmentation with the GREEN power-and-energy -04 module.";
reference "draft-jadoon-green-isac-utilization";
}
revision 2026-02-23 {
description
"Draft -04 update (corrected): align with ietf-sensing-utilization changes.";
reference "draft-jadoon-green-isac-utilization";
}
augment "/eo:energy-objects/eo:energy-object" {
description
"Attach sensing utilization reporting to a GREEN Energy Object.";
container sensing-utilization {
presence
"Indicates that sensing utilization telemetry is available
for this reporting scope.";
config false;
description
"Sensing utilization reporting attributed to this energy-object.";
uses sensing-util:sensing-utilization-body;
}
}
}
¶
{
"ietf-sensing-utilization:sensing-utilization": {
"overall-utilization-score": 53,
"timestamp": "2026-02-23T09:00:00Z",
"aggregation-window": "60000",
"component-scores": {
"compute-impact-score": 40,
"memory-impact-score": 10,
"energy-consumption-impact-score": 60,
"storage-impact-score": 5,
"latency-impact-score": 20
},
"metadata": {
"score-method": "ietf-sensing-utilization:us-score-method-implementation-specific",
"score-method-version": "1.0.0",
"score-provenance": "measured",
"sample-count": 120,
"confidence-level": 90
}
}
}
¶
TBD # IANA Considerations¶
TBD¶
This work has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union's Horizon Europe research and innovation programme under Grant Agreement No 101192521 (MultiX).¶