A YANG Data Model for Reporting Utilization Scores in ISAC

Introduction Integrated Sensing and Communication (ISAC) introduces a paradigm where network nodes perform both communication and sensing tasks. Several use cases and their requirements for ISAC have been defined in 3GPP (e.g., TR 22.837) and ETSI (e.g., GR ISC001) and it is one of the use cases defined for GREEN WG preparations . ISAC involves collection of sensing data including RF (radar-like) sensing and non RF sensing. The collection of sensing data for different use cases can consume different amounts of system resources such as compute, memory, energy, storage, 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 an ISAC sensing task. This document defines an ISAC 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 ISAC-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.

Model Scope The model is intended for systems that support ISAC and want to participate in energy-aware operations. The model is telemetry-only, meaning all data nodes defined here are operational state. Standard YANG telemetry mechanisms (polling and/or subscriptions such as YANG Push) can be used to collect the data.

Integration with GREEN Power and Energy (Informative) The GREEN Working Group is defining a base YANG module for Power and Energy monitoring and control of Energy Objects . When ISAC sensing operations run on the same physical component(s) that are represented as Energy Objects, it is beneficial to be able to correlate:

energy and power telemetry; and
ISAC utilization telemetry (scores and breakdown)

for the same scope. This document describes two integration paths.

Path 1 is implemented in this revision via a companion augmentation module that binds ISAC utilization to an existing Energy Object.
Path 2 is described as a consideration for future revisions and may require extensions to the GREEN base model.

Path 1: Augment Energy Objects (This Revision) Path 1 introduces an augmentation module ietf-isac-utilization-power-and-energy. It augments the Energy Object list entry (energy-entry) defined in the GREEN Power and Energy YANG module with an isac-utilization container that reuses the subtree defined by ietf-isac-utilization. This path allows:

Minimal disruption: it does not change the GREEN base model.
Correlation by construction: the ISAC utilization score is attached to the same energy-entry instance that exposes power/energy metrics.
Compatibility with standalone deployments that do not use the GREEN base models.

Interpretation guidance:

Implementations SHOULD publish the ISAC Utilization Score (US) on a single Energy Object that best represents the ISAC execution scope (e.g., chassis/ device, baseband 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.

This guidance is operational in nature and does not impose schema-level constraints.

Considerations for Path 2: Software/Service Scopes In many deployments, sensing functions are implemented as software components running on shared hardware. Operators may therefore want to reason about utilization and energy at a software/service scope, not only at a hardware component scope. The current GREEN Power and Energy YANG module associates each energy-entry primarily with a physical component (e.g., via a hardware component reference). Path 1 works well when the ISAC execution scope maps cleanly to such a physical component. A future "Path 2" could be enabled if the GREEN base model (or a companion module) adds a way to represent software/service/workload scopes and link them to the underlying hardware scope(s). This draft does not require such support and does not define it.

YANG Trees The following tree diagrams summarize the YANG modules in this document.

ietf-isac-utilization

ietf-isac-utilization-power-and-energy

YANG Modules

ietf-isac-utilization Sebastian Robitzsch "; description "Reports normalized utilization *scores* for Integrated Sensing and Communication (ISAC) systems. 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: * ISAC 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 ISAC utilization telemetry without duplicating the subtree definition."; revision 2026-02-23 { description "Draft -03 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 ISAC 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 ISAC 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 an ISAC 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 isac-utilization-body { description "Reusable ISAC utilization reporting structure."; leaf overall-utilization-score { type score-0-100; mandatory true; description "Overall ISAC 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 isac-utilization { config false; description "ISAC utilization reporting at device/node scope."; uses isac-utilization-body; } } ]]>

ietf-isac-utilization-power-and-energy (Path 1) Sebastian Robitzsch "; description "Path 1 integration module between ISAC utilization reporting and the GREEN Power/Energy base model. This module augments the 'energy-entry' list (an Energy Object) defined in ietf-power-and-energy with an ISAC-specific utilization container. This enables correlation between: * power/energy telemetry from ietf-power-and-energy; and * ISAC utilization telemetry (overall score and optional breakdown) for the same physical scope. Interpretation guidance: * The ISAC 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 ISAC 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 'isac-utilization' container is optional per energy-entry and can be omitted for Energy Objects where ISAC utilization is not applicable."; revision 2026-02-23 { description "Draft -03 update (corrected): align with ietf-isac-utilization changes."; reference "draft-jadoon-green-isac-utilization"; } augment "/eo:energy-objects/eo:energy-entry" { description "Attach ISAC utilization reporting to a GREEN Energy Object."; container isac-utilization { config false; description "ISAC utilization reporting attributed to this energy-entry."; uses isac-util:isac-utilization-body; } } } ]]>

JSON Encoding Examples

Standalone reporting using ietf-isac-utilization

Reporting correlated to an Energy Object (Path 1) The following example illustrates a controller reading an energy-entry from ietf-power-and-energy where the energy-entry is augmented by this draft with isac-utilization:

Security Considerations The utilization score and its breakdown can reveal operational details about sensing activity, device capabilities, and workload patterns. Implementations MUST apply appropriate access control (e.g., via NACM) to prevent unauthorized access to operational telemetry.

IANA Considerations This document has no IANA actions.

Acknowledgements 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).