Hybrid Energy Saving Mechanism for Transport Network

This document presents transport network energy saving management framework that harmonizes device-level autonomy with network-wide coordination. The framework is grounded in 's reference model and addresses the specific requirements identified in through practical mechanisms for multi-layer energy optimization. The framework is organized into two functionally distinct yet complementary layers that work in concert to achieve coordinated energy optimization:

Device-Centric Energy Saving: The device-centric management encompasses individual network elements that execute real-time, localized energy adjustments based on local data collection and policies received from the network controller. Device-centric management enables fast response to transient traffic conditions and maintains autonomous operation.

Controller-Centric Energy Saving: The controller-level energy management provides centralized visibility, cross-layer analysis, and strategic policy formulation across the entire network domain. Controller-centric management performs long-term traffic prediction, assesses network-level risks, and provides a northbound interface to users for intuitive evaluation of energy-saving effects.

Transport networks requires comprehensive, real-time, and granular measurements spanning physical, logical, and environmental domains to enable cross-layer correlation and coordinated optimization.

Power Monitoring: Power monitoring is the foundation for understanding energy consumption patterns and identifying optimization opportunities. Power monitoring encompasses measurements at multiple hierarchical levels within network elements, from component-level including boards, fans, and PSU to device-level chassis power.

Traffic Monitoring: Traffic monitoring extends the framework to address transport network-specific requirements. Understanding traffic characteristics across multiple layers is essential for correlating energy consumption with network utilization and for identifying temporal patterns that enable predictive optimization. This enables both real-time response to transient traffic changes and long-term trend analysis for strategic planning.

Topology Monitoring: Topology monitoring provides the cross-layer visibility necessary for coordinated energy optimization. Transport networks span multiple protocol layers with complex interdependencies; understanding these relationships is critical for making energy-saving decisions that respect service requirements and network constraints. Topology monitoring across both transport and IP layers should be used to capture relevant logical relationships, such as protection relationships, resource aggregation, and service-to-infrastructure mappings that support the formulation of energy optimization strategies.

Section 6.1 of discuss the implementation focus and where intelligence resides. The transport network uses the hybrid approach which need device capabilities and controller coordination. Transport network device must independently manage its energy saving no matter DCN is available for local real-time process. It needs local algorithms, minimal controller dependency, autonomous operation. Secondly, the device-centric performs traffic prediction, quickly responds to short-term traffic changes, formulates strategies, and executes actions. On the other side, the controller-centric energy saving performs long-term traffic prediction based on network topology resources, assesses network-level risks, provides a northbound interface to users, and enables visualized and intuitive evaluation of energy-saving effects. Depending on the scenario, inference time, accuracy, and other factors, different intelligent algorithms are deployed on the controller and device to intelligently predict long and short cycles and burst traffic. This allows the controller to accurately predict long-term changes in services and devices to accurately predict short-term burst traffic, thereby adjusting the equipment operating status in advance and avoiding service disruption.

This allows devices to make local decisions on resource scheduling based on real-time, node-local data/information collection, enabling faster reaction to transient traffic conditions though on-device analysis.

Data collection

Sensors continuously gather real-time power and energy-related metrics, including chip, port, board, fan, and chassis power consumption, as well as device zone temperature and instantaneous traffic load.

Analysis

An embedded processing unit applies lightweight algorithms to model the relationship between local load and power consumption. It performs short-term traffic trend prediction, evaluates energy-saving strategies through simulation, and supports cross-layer command coordination. Conditions are continuously assessed against configured energy-saving policies.

Simulation and Verification

The simulation model describes the relationships between parameters of device and relationships between devices themseleves. It use the data from scenario and energy-saving scheme to simulate and verfify the consumption information after executing energy-saving scheme. Based on the power consumption information, the feasibility of energy-saving scheme is tested and determined.

Control and Execution

Devices dynamically switch the power state of the components (e.g., ports, line cards, switch cards, chassis) based on local traffic load, in accordance with policies received from the device controller. For instance, when predicted traffic falls below a predefined threshold, the system sequentially initiates energy-saving actions, such as placing boards into sleep mode and intelligently adjusting fan speeds.

Supported power states include deep sleep, light sleep, normal operation, and power-off. Deep sleep maintains only essential core links, substantially reducing energy consumption during idle periods. Light sleep can satisfy hitless wake-up from sleep modes to ensure zero service impact, particularly for high-priority services.

This network-level energy management operates from a network controller platform, providing a holistic view and strategic control. Unlike device-local management, its role is primarily one of coordination, optimization, and assurance across the multi-layer network.

Data collection The controller ingests and correlates telemetry from all managed devices, building a holistic network model that spans real time power consumption, topology, and traffic state.

Transport Layer Topology: Logical link information and resource status from both the optical layer (L0) and electrical layer (L1/L2).

IP Layer Topology: Logical links, protection relations and routing adjacencies from the IP layer (L3). For instance, protection paths may carry extra traffic under normal conditions but must be reserved for failover scenarios. This integrated view allows the network controller to assess risks, such as extended wake‑up delays from deep sleep modes, that could impact service performance during protection switching or other reactive scenarios.

Analysis

Leveraging AI/ML and analytical engines, the controller performs predictive traffic and load forecasting. It identifies optimization opportunities through cross layer correlation. It also can simulates the potential impact of different energy management strategies before deployment.

Control and Execution The central controller acts as the brain for network-level energy optimization. Its key functions include: The controller analyzes historical and real-time traffic data to predict future load patterns. Based on these predictions and service SLAs, it generates holistic energy-saving strategies,

Computing paths for traffic migration to consolidate services onto fewer network elements.

Instructing idle or underutilized devices to enter low-power states (e.g., deep sleep for best-effort services, light sleep for premium services). These policies are then dispatched to devices.

Cross-layer Coordination: The controller translates high-level strategies into specific, synchronized actions for both transport and IP layers to ensure service continuity. For example, before putting a transport node to sleep, it coordinates with the IP layer to reroute traffic away from that node.

This section describes the collaborative information exchanges between device-centric and controller-centric energy saving functions. The hybrid approach leverages the strengths of both layers: devices provide fast, localized responses to transient conditions, while the controller provides global optimization and strategic guidance. The coordination between devices and the controller relies on a set of well-defined information exchange interfaces. The key information flows are summarized below. Device-to-Controller Information Flows:

Capability Advertisement:Upon boot-up or when its capabilities change, a device advertises to the controller the set of supported power states (e.g., deep sleep, light sleep), transition delays for each state, the granularity at which energy-saving operations can be applied (port-level, board-level, or chassis-level), and any operational constraints.

Telemetry Data:Devices periodically (e.g., every 1 min) or event-triggeredly report component-level measurements including power consumption, temperature, and traffic load to the controller, enabling the controller to maintain a real-time view of network-wide energy status.

State Change Notification: When a device undergoes a power state transition, or when an energy-saving action succeeds or fails, the device actively notifies the controller of the event, including the target component, previous and current states, timestamp, execution result, and failure reason if applicable.

Policy Feedback: Upon receiving a policy from the controller, the device responds with an acceptance or rejection. If accepted, the device may subsequently report the execution status of the policy.

Controller-to-Device Information Flows:

Policy Distribution:When an energy saving policy is generated or updated, the controller pushes it to the relevant devices. Each policy specifies the target components, the desired power state, trigger conditions (time windows or traffic thresholds), rollback conditions, maximum allowed wake-up delay, and priority level.

Query Request: The controller may on-demand query a device for its current energy-saving state or historical energy data.

Device-to-Device Information Flows:

Peer Coordination: Devices within the same protection group synchronize their energy-saving states with each other. This ensures that when one device enters a sleep state, its protection peer is aware of the status, preventing any adverse impact on failover capabilities.

All interfaces are designed to be asynchronous. Devices do not wait for controller confirmation before executing local decisions based on pre-provisioned policies, which ensures fast response to transient conditions. However, devices are expected to report state changes to the controller to maintain global view consistency.

The implementation of the hybrid device-centric and controller-centric energy optimization requires standardized data models for representing energy-related information, policies, and control mechanisms. This section discusses the YANG data model considerations for this implementation. The framework defines information flows between devices and controllers:

Transport Network Energy Saving Framework | Transport Network Element | | | | | +----------------------------+ +----------------------------+ ]]> Devices report operational data including power measurements, traffic characteristics, device status, and multi-granularity aggregated data to the controller. Controllers distribute energy-saving policies, SLA constraints, cross-layer control commands, and configuration updates to devices. To address this hybrid coordination, the following YANG considerations should be evaluated:

Controller and Users: YANG models for northbound interfaces enabling users to configure energy-saving objectives, view optimization results, and monitor energy consumption.

Controller and Devices: YANG models for southbound interfaces enabling the controller to distribute policies, receive telemetry, and issue control commands to devices.

Device and Device: Peer-to-peer interactions between devices to support cross-layer coordination and local optimization. This may involve protocol or signaling extensions, such as capability advertisement, energy-saving status synchronization, or the notifications of energy-saving policies, which can guide other devices to perform operations or provide information to the other devices.

Transport networks differ from other network domains in that energy-saving operations are subject to a set of operational constraints that are specific to the transport domain. Devices MUST advertise these constraints to the controller so that the controller can formulate energy-saving strategies that do not compromise network reliability. The following constraints are defined: In transport networks, network elements are typically organized into protection groups (e.g., 1+1, 1:N) to ensure service survivability per ITU-T G.808.1. A component that belongs to an active protection group MUST NOT be placed into a power-saving state unless the protection function can be guaranteed by other means. For each protection group, the device advertises: protection-group-id: unique identifier of the protection group role: working or protection protection-type: 1+1, 1:N, or shared-mesh energy-saving-permitted: true or false permitted-states: list of power states allowed (e.g., only light-sleep, not deep-sleep) For example, in a 1+1 protection configuration, the working line card may be permitted to enter light sleep during low-traffic periods if the protection line card remains fully operational. The protection line card itself MUST NOT be placed into any sleep state as it must be ready for immediate failover. In contrast, in a 1:N protection configuration where one protection card backs up N working cards, all N working cards may be candidates for energy saving, but the protection card must remain in normal state at all times. Transport networks carry services with different priority levels. Devices advertise the maximum service priority level that can be affected by energy-saving operations. Components carrying services above this priority level MUST NOT be placed into energy-saving states. The device advertises: max-affected-service-priority: integer value (0-7, where 0 is highest) Each component advertises current-service-priority: the highest priority of all services currently traversing it A typical configuration in a transport network may set max-affected-service-priority = 3, meaning that services with priority 0, 1, 2 (e.g., 5G backhaul, financial trading, emergency services) are never impacted. Only services with priority 3-7 may be subject to energy-saving actions. This ensures that critical services maintain their SLA commitments defined in the service-level agreement. Transport networks often have predictable traffic patterns with distinct peak and off-peak periods for network operations. Devices advertise time windows during which energy-saving operations are permitted or prohibited. For each time window, the device advertises: window-id: unique identifier window-type: permitted or prohibited recurrence: daily, weekly, once start-time: e.g., T00:00:00+08:00 (local time) end-time: e.g., T06:00:00+08:00 day-of-week: list of days if weekly recurrence A typical transport network configuration permits light sleep on weekdays from 00:00 to 06:00 and throughout weekends, but prohibits any deep sleep during business hours (08:00-20:00) to maintain service availability. For example, an OTN device may be configured with the following time windows: permitted: daily 00:00-06:00, all day Saturday and Sunday prohibited: daily 08:00-20:00 (business hours) cautious: daily 06:00-08:00 and 20:00-00:00 (transition windows where only light sleep is permitted, not deep sleep)

A general principle is that the more significant the energy savings, the slower the module response time and the longer the wake-up delay, which may impact service performance. To address this, the following items should be considered:

Power state configuration aligned with service tolerance: During low-traffic periods (e.g., nighttime), idle line cards/standby main control units can enter deep sleep mode for maximum energy savings. During peak hours (e.g., daytime), a light sleep mode should be adopted to enable faster wake-up and minimize service disruption.

Resource reservation for reliable energy efficiency: In the transport network, the total bandwidth utilization of a network network element is primarily determined by the aggregate traffic across its ports. However, in practice, the available capacity cannot be entirely assigned to user traffic, as a portion of the bandwidth must be reserved for protection switching, rerouting operations and control plane overhead. It ensures the network reliability during network anomalies or congestion events.

So redundant resources should be reserved to accommodate scenarios like protection switching at failure cases. This guarantees service reliability while maintaining energy-saving benefits.