Definition of Managed Objects for Battery Monitoring
Extracted elements (24)
Battery technologies are subject to rapid evolution and replacement, so a fixed enumeration would quickly become obsolete. An extensible IANA registry was chosen instead, allowing new technologies to be added without revising the MIB module. New entries are restricted to technologies in commercial use and relevant to Internet-based battery monitoring.
batteryIdentifier (tied to the physical battery) and entPhysicalUUID (tied to the battery slot) serve distinct purposes. This separation allows the management system to trace a battery across devices and maintain monitoring continuity when a replaceable battery is moved, while entPhysicalUUID remains stable for the slot.
The MIB uses a simple four-state charging model (charging, maintainingCharge, noCharging, discharging) as a technology-independent abstraction. Charging controllers with richer internal state engines must map to these four states; finer-grained control is explicitly deferred to future MIB extensions.
RFC 1628 (UPS MIB) already defines battery monitoring objects for Uninterruptible Power Supply systems, but those objects are limited and UPS-specific. The Battery MIB is designed to supplement — not replace — the UPS MIB, providing broader and more detailed battery status applicable to general networked devices.
A compliant implementation of the Battery MIB MUST implement the objects in the mandatory groups batteryDescriptionGroup (static properties) and batteryStatusGroup (current status). The Entity MIB entity4CRCompliance MODULE-COMPLIANCE statement is also required.
All batteries SHOULD have the entPhysicalClass object in the Entity MIB entPhysicalTable set to battery(14) in their row.
If a battery is replaced and the replacing battery uses the same physical connector, the replacing battery MUST be indexed with the same entPhysicalIndex value as the replaced battery to maintain monitoring continuity.
Implementations claiming compliance to SNMPv3 MUST include full support for authentication and privacy via the User-based Security Model (USM) with the AES cipher algorithm (RFC 3826). Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.
The batteryTemperatureNotification SHOULD NOT be re-sent for the same battery or cell within a 10-minute interval to limit notification rate when temperature alternates near a threshold. An exception applies immediately after reinitialization of the battery monitoring system.
The charging controller SHOULD change the operational charging state (batteryChargingOperState) to the state requested via batteryChargingAdminState as soon as operational conditions allow. However, it may override at any time — for example, entering discharging(5) if battery power is urgently needed.
The value unknown(1) MUST be used for object batteryTechnology if the technology of the battery cannot be determined. Value other(2) may be used if the technology is known but not yet registered with IANA.
For battery-powered devices correlated to individuals, objects such as batteryChargingCycleCount, batteryLastChargingCycleTime, batteryChargingOperState, batteryActualCharge, and related alarm thresholds can reveal information about users' activities and habits (e.g., proximity to power outlets, device usage intensity). Battery monitoring of individually owned devices SHOULD occur only with proper authorization.
batteryCellIdentifier (SnmpAdminString, read-only) optionally identifies the specific cell or set of cells within a battery that triggered a notification. Its value is set each time a low, critical, temperature, or aging notification is generated; an empty string indicates the entire battery is addressed.
batteryChargingAdminState (read-write) allows a management system to request a charging state: notSet(1) lets the controller operate autonomously, charge(2) requests charging to full, doNotCharge(3) requests noCharging(4), and discharge(4) requests discharging(5). The operational result is reflected in the read-only batteryChargingOperState; the controller may override the request if operational conditions require it.
batteryChargingCycleCount tracks completed charging cycles, defined per the Smart Battery Data Specification Rev 1.1 as total discharge equal to the design capacity (batteryDesignCapacity). Partial charge/discharge steps accumulate; the next cycle begins immediately after the prior one completes. Value 0xFFFFFFFF indicates the count is undetermined.
batteryIdentifier (SnmpAdminString, read-only) holds the manufacturer-assigned battery identifier tied to the physical battery. When multiple sub-identifiers exist (e.g., model number and serial number), they are concatenated with ':' as a separator, more significant value first.
Seven notifications are defined: batteryChargingStateNotification (autonomous state change), batteryLowNotification (charge or voltage below threshold), batteryCriticalNotification (battery cannot supply normal power), batteryTemperatureNotification (temperature threshold crossed), batteryAgingNotification (capacity or cycle count threshold), batteryConnectedNotification, and batteryDisconnectedNotification.
The batteryTable is the single central table containing one conceptual row per battery in a managed entity, indexed by entPhysicalIndex from the Entity MIB (RFC 6933). It is divided into three groups: static properties (OIDs 1–9), current status (OIDs 10–18), and alarm thresholds and notification support (OIDs 19–25).
IANA assigned OID { mib-2 233 } to the batteryMIB MODULE-IDENTITY, recorded in the SMI Numbers registry under the descriptor 'batteryMIB'.
IANA created a Battery Technologies registry (http://www.iana.org/assignments/battery-technologies) seeded with 20 technologies (values 0–20, including lead-acid, lithium-ion, nickel-cadmium, etc.; values 21–4294967295 unassigned). New assignments require Expert Review; technologies must be in commercial use and relevant to standardized Internet battery monitoring.
Even read-only access to battery status objects may expose corporate trade secrets, including the number and types of installed batteries, their firmware versions, remaining capacity, and expected replacement schedules. SNMPv3 authentication and privacy (encryption) SHOULD be used to protect GET and NOTIFY access.
Write access to batteryChargingAdminState can be exploited to forcibly discharge batteries, effectively powering off battery-only devices. If an attacker also sets batteryAlarmLowCharge and batteryAlarmLowVoltage to 0, the discharge attack goes unnoticed because no low-battery notifications are generated.
Write access to the alarm threshold objects (batteryAlarmLowCharge, batteryAlarmLowVoltage, batteryAlarmLowCapacity, batteryAlarmHighCycleCount, batteryAlarmHighTemperature, batteryAlarmLowTemperature) allows an attacker to suppress critical alarms or set them to values that cause device shutdowns, data loss, or physical battery damage.
The batteryChargingOperState object defines five battery charging states: unknown(1), charging(2), maintainingCharge(3), noCharging(4), and discharging(5). Transitions are triggered either autonomously by the charging controller or by write operations to batteryChargingAdminState; the controller SHOULD honor the admin state as soon as operational conditions permit.