RFC 7577
Definition of Managed Objects for Battery Monitoring
Pages: 40
Proposed Standard
Proposed Standard
Part 1 of 2 – Pages 1 to 11
Internet Engineering Task Force (IETF) J. Quittek Request for Comments: 7577 R. Winter Category: Standards Track T. Dietz ISSN: 2070-1721 NEC Europe, Ltd. July 2015 Definition of Managed Objects for Battery MonitoringAbstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7577. Copyright Notice Copyright (c) 2015 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . 5 3. Design of the Battery MIB Module . . . . . . . . . . . . . . 6 3.1. MIB Module Structure . . . . . . . . . . . . . . . . . . 6 3.2. Battery Technologies . . . . . . . . . . . . . . . . . . 8 3.2.1. Guidelines for Adding Battery Technologies . . . . . 9 3.3. Battery Identification . . . . . . . . . . . . . . . . . 9 3.4. Charging Cycles . . . . . . . . . . . . . . . . . . . . . 10 3.5. Charge Control . . . . . . . . . . . . . . . . . . . . . 10 3.6. Imported Definitions . . . . . . . . . . . . . . . . . . 11 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 6.1. SMI Object Identifier Registration . . . . . . . . . . . 36 6.2. Battery Technology Registration . . . . . . . . . . . . . 36 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1. Normative References . . . . . . . . . . . . . . . . . . 37 7.2. Informative References . . . . . . . . . . . . . . . . . 38 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 401. Introduction
Today, more and more managed devices contain batteries that supply them with power when disconnected from electrical power distribution grids. Common examples are nomadic and mobile devices, such as notebook computers, netbooks, and smartphones. The status of batteries in such a device, particularly the charging status, is typically controlled by automatic functions that act locally on the device and manually by users of the device. In addition to this, there is a need to monitor battery status of these devices by network management systems. This document defines a portion of the Management Information Base (MIB) that provides a means for monitoring batteries in or attached to managed devices. The Battery MIB module defined in Section 4 meets the requirements for monitoring the status of batteries specified in RFC 6988 [RFC6988]. The Battery MIB module provides for monitoring the battery status. According to the framework for energy management [RFC7326], it is an Energy Managed Object; thus, MIB modules such as the Power and Energy Monitoring MIB [RFC7460] could, in principle, be implemented for batteries. The Battery MIB extends the more generic aspects of energy management by adding battery-specific information. Amongst other things, the Battery MIB enables the monitoring of:
o the current charge of a battery,
o the age of a battery (charging cycles),
o the state of a battery (e.g., being recharged),
o last usage of a battery, and
o maximum energy provided by a battery (remaining and total
capacity).
Further, means are provided for battery-powered devices to send
notifications to inform the management system of needed replacement
when the current battery charge has dropped below a certain
threshold. The same applies to the age of a battery.
Many battery-driven devices have existing instrumentation for
monitoring the battery status because this is already needed for
local control of the battery by the device. This reduces the effort
for implementing the managed objects defined in this document. For
many devices, only additional software will be needed; no additional
hardware instrumentation for battery monitoring is necessary.
Since there are a lot of devices in use that contain more than one
battery, means for battery monitoring defined in this document
support addressing multiple batteries within a single device. Also,
batteries today often come in packages that can include
identification and might contain additional hardware and firmware.
The former allows tracing a battery and allows continuous monitoring
even if the battery is installed in another device. The firmware
version is useful information as the battery behavior might be
different for different firmware versions.
Not explicitly in the scope of definitions in this document are very
small backup batteries, for example, batteries used on a PC
motherboard to run the clock circuit and retain configuration memory
while the system is turned off. Other means may be required for
reporting on these batteries. However, the MIB module defined in
Section 3.1 can be used for this purpose.
A traditional type of managed device containing batteries is an
Uninterruptible Power Supply (UPS) system; these supply other devices
with electrical energy when the main power supply fails. There is
already a MIB module for managing UPS systems defined in RFC 1628
[RFC1628]. The UPS MIB module includes managed objects for
monitoring the batteries contained in a UPS system. However, the
information provided by the UPS MIB objects is limited and tailored
to the particular needs of UPS systems.
A huge variety of battery technologies are available, and they are evolving over time. For different applications, different battery technologies are preferable, for example, because of different weight, cost, robustness, charging time, etc. Some technologies, such as lead-acid batteries, are continuously in use for decades, while others, such as nickel-based battery technologies (nickel- cadmium and nickel-metal hydride), have, to a wide extent, been replaced by lithium-based battery technologies (lithium-ion and lithium polymer). The Battery MIB module uses a generic abstraction of batteries that is independent of particular battery technologies and expected to be applicable to future technologies as well. While identification of a particular battery technology is supported by an extensible list of battery technology identifiers (see Section 3.2), individual properties of the technologies are not modeled by the abstraction. In particular, methods for charging a battery, and the parameters of those methods, which vary greatly between different technologies are not individually modeled. Instead, the Battery MIB module uses a simple common charging model with batteries being in one of the following states: 'charging', 'maintaining charge', 'not charging', and 'discharging'. Control of the charging process is limited to requests for transitions between these states. For charging controllers that use charging state engines with more states, implementations of the Battery MIB module need to map those states to the four listed above. For energy management systems that require finer-grained control of the battery charging process, additional means need to be developed; for example, MIB modules that model richer sets of charging states and parameters for charging states. All use cases sketched above assume that the batteries are contained in a managed entity. In a typical case, this entity also hosts the SNMP applications (command responder and notification generator) and the charging controller for contained batteries. For definitions in this document, it is not strictly required that batteries be contained in the same managed entity, even though the Battery MIB module (defined further below) uses the containment tree of the Entity MIB module [RFC6933] for battery indexing. External batteries can be supported as long as the charging controller for these batteries is connected to the SNMP applications that implement the Battery MIB module. An example with an external battery is shown in the figure below. It illustrates that the Battery MIB module is designed as an interface between the management system and battery charging controller. Out of scope of this
document is the interface between the battery charging controller and controlled batteries. +-----------------------------------+ | management system | +-----------------+-----------------+ | | Battery MIB | +-----------------+-----------------+ | managed element | | | | | | +--------------+--------------+ | | | battery charging controller | | | +-----+--------------+--------+ | | | | | | +-----+-----+ | | | | internal | | | | | battery | | | | +-----------+ | | +-----------------------+-----------+ | +-----+-----+ | external | | battery | +-----------+ Figure 1: Battery MIB as Interface between Management System and Battery-Charging Controller Supporting External Batteries 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 RFC 2119 [RFC2119].2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580 [RFC2580].3. Design of the Battery MIB Module
3.1. MIB Module Structure
The Battery MIB module defined in this document defines objects for reporting information about batteries. All managed objects providing information on the status of a battery are contained in a single table called "batteryTable". The batteryTable contains one conceptual row per battery. Batteries are indexed by the entPhysicalIndex of the entPhysicalTable defined in the Entity MIB module [RFC6933]. An implementation of the Entity MIB module complying with the entity4CRCompliance MODULE-COMPLIANCE statement is required for compliant implementations of the Battery MIB module. If a battery is replaced, and the replacing battery uses the same physical connector as the replaced battery, then the replacing battery MUST be indexed with the same value of object entPhysicalIndex as the replaced battery. The kind of entity in the entPhysicalTable of the Entity MIB module is indicated by the value of enumeration object entPhysicalClass. All batteries SHOULD have the value of object entPhysicalClass set to battery(14) in their row of the entPhysicalTable. The batteryTable contains three groups of objects. The first group (OIDs ending with 1-9) provides information on static properties of the battery. The second group of objects (OIDs ending with 10-18) provides information on the current battery state, if it is charging or discharging, how much it is charged, its remaining capacity, the number of experienced charging cycles, etc.
batteryTable(1)
+--batteryEntry(1) [entPhysicalIndex]
+-- r-n SnmpAdminString batteryIdentifier(1)
+-- r-n SnmpAdminString batteryFirmwareVersion(2)
+-- r-n Enumeration batteryType(3)
+-- r-n Unsigned32 batteryTechnology(4)
+-- r-n Unsigned32 batteryDesignVoltage(5)
+-- r-n Unsigned32 batteryNumberOfCells(6)
+-- r-n Unsigned32 batteryDesignCapacity(7)
+-- r-n Unsigned32 batteryMaxChargingCurrent(8)
+-- r-n Unsigned32 batteryTrickleChargingCurrent(9)
+-- r-n Unsigned32 batteryActualCapacity(10)
+-- r-n Unsigned32 batteryChargingCycleCount(11)
+-- r-n DateAndTime batteryLastChargingCycleTime(12)
+-- r-n Enumeration batteryChargingOperState(13)
+-- rwn Enumeration batteryChargingAdminState(14)
+-- r-n Unsigned32 batteryActualCharge(15)
+-- r-n Unsigned32 batteryActualVoltage(16)
+-- r-n Integer32 batteryActualCurrent(17)
+-- r-n Integer32 batteryTemperature(18)
+-- rwn Unsigned32 batteryAlarmLowCharge(19)
+-- rwn Unsigned32 batteryAlarmLowVoltage(20)
+-- rwn Unsigned32 batteryAlarmLowCapacity(21)
+-- rwn Unsigned32 batteryAlarmHighCycleCount(22)
+-- rwn Integer32 batteryAlarmHighTemperature(23)
+-- rwn Integer32 batteryAlarmLowTemperature(24)
+-- r-n SnmpAdminString batteryCellIdentifier(25)
The third group of objects in this table (OIDs ending with 19-25) is
used for notifications. Threshold objects (OIDs ending with 19-24)
indicate thresholds that can be used to raise an alarm if a property
of the battery exceeds one of them. Raising an alarm may include
sending a notification.
The Battery MIB defines seven notifications for indicating:
1. a battery-charging state change that was not triggered by writing
to object batteryChargingAdminState,
2. a low-battery charging state,
3. a critical-battery state in which it cannot be used for power
supply,
4. an aged battery that may need to be replaced,
5. a battery that has exceeded a temperature threshold,
6. a battery that has been connected, and 7. disconnection of one or more batteries. Notifications 2-5 can use object batteryCellIdentifier to indicate a specific cell or a set of cells within the battery that have triggered the notification.3.2. Battery Technologies
Static information in the batteryTable includes battery type and technology. The battery type distinguishes primary (not rechargeable) batteries from rechargeable (secondary) batteries and capacitors. The battery technology describes the actual technology of a battery, which typically is a chemical technology. Since battery technologies are the subject of intensive research and widely used technologies are often replaced by successor technologies within a few years, the list of battery technologies was not chosen as a fixed list. Instead, IANA has created a registry for battery technologies at <http://www.iana.org/assignments/battery- technologies> where numbers are assigned to battery technologies. The table below shows battery technologies known today that are in commercial use with the numbers assigned to them by IANA. New entries can be added to the IANA registry if new technologies are developed or if missing technologies are identified. Note that there exists a huge number of battery types that are not listed in the IANA registry. Many of them are experimental or cannot be used in an economically useful way. New entries should be added to the IANA registry only if the respective technologies are in commercial use and relevant to standardized battery monitoring over the Internet.
+--------------------------------+---------------+
| Battery Technology | Value |
+--------------------------------+---------------+
| Reserved | 0 |
| Unknown | 1 |
| Other | 2 |
| Zinc-carbon | 3 |
| Zinc chloride | 4 |
| Nickel oxyhydroxide | 5 |
| Lithium-copper oxide | 6 |
| Lithium-iron disulfide | 7 |
| Lithium-manganese dioxide | 8 |
| Zinc-air | 9 |
| Silver oxide | 10 |
| Alkaline | 11 |
| Lead-acid | 12 |
| Valve-Regulated Lead-Acid, Gel | 13 |
| Valve-Regulated Lead-Acid, AGM | 14 |
| Nickel-cadmium | 15 |
| Nickel-metal hydride | 16 |
| Nickel-zinc | 17 |
| Lithium-ion | 18 |
| Lithium polymer | 19 |
| Double layer capacitor | 20 |
| Unassigned | 21-4294967295 |
+--------------------------------+---------------+
3.2.1. Guidelines for Adding Battery Technologies
New entries can be added to the IANA registry if new technologies are
developed or if missing technologies are identified. Note that there
exists a huge number of battery types that are not listed in the IANA
registry. Many of them are experimental or cannot be used in an
economically useful way. New entries should be added to the IANA
registry only if the respective technologies are in commercial use
and relevant to standardized battery monitoring over the Internet.
3.3. Battery Identification
There are two identifiers to be used: the entPhysicalUUID defined in
the Entity MIB [RFC6933] module and the batteryIdentifier defined in
this module. A battery is linked to an entPhysicalUUID through the
shared entPhysicalIndex.
The batteryIdentifier uniquely identifies the battery itself while
the entPhysicalUUID identifies the slot of the device in which the
battery is (currently) contained. For a non-replaceable battery,
both identifiers are always linked to the same physical battery. But
for batteries that can be replaced, the identifiers have different functions. The entPhysicalUUID is always the same for a certain battery slot of a containing device even if the contained battery is replaced by another. The batteryIdentifier is a representation of the battery identifier set by the battery manufacturer. It is tied to the battery and usually cannot be changed. Many manufacturers deliver not just plain batteries but battery packages including additional hardware and firmware. Typically, these modules include a battery identifier that can by retrieved by a device in which a battery has been installed. The value of the object batteryIdentifier is an exact representation of this identifier. The batteryIdentifier is useful when batteries are removed and reinstalled in the same device or in other devices. Then, the device or the network management system can trace batteries and achieve continuity of battery monitoring.3.4. Charging Cycles
The lifetime of a battery can be approximated using the measure of charging cycles. A commonly used definition of a charging cycle is the amount of discharge equal to the design (or nominal) capacity of the battery [SBS]. This means that a single charging cycle may include several steps of partial charging and discharging until the amount of discharging has reached the design capacity of the battery. After that, the next charging cycle immediately starts.3.5. Charge Control
Managed object batteryChargingOperState indicates the current operational charging state of a battery and is a read-only object. For controlling the charging state, object batteryChargingAdminState can be used. Writing to this object initiates a request to adapt the operational state according to the value that has been written. By default, the batteryChargingAdminState object is set to notSet(1). In this state, the charging controller is using its predefined policies to decide which operational state is suitable in the current situation. Setting the value of object batteryChargingAdminState may result in not changing the state of the battery to this value or even in setting the charging state to another value than the requested one. Due to operational conditions and limitations of the implementation of the Battery MIB module, changing the battery status according to a set value of object batteryChargingAdminState might not be possible.
For example, the charging controller might, at any time, decide to enter state discharging(5), if there is an operational need to use the battery for supplying power. The object batteryChargingAdminState will not automatically change when the object batteryChargingOperState changes. If the operational state is changed, e.g., to the state discharging(5) due to operational conditions, the admin state will remain in its current state. The charging controller SHOULD change the operational state to the state indicated by the object batteryChargingAdminState as soon as operational conditions allow this change. If a state change of the object batteryChargingAdminState is desired upon change of the operational state, the object batteryChargingOperState must be polled or the notification batteryChargingStateNotification must be used to get notified about the state change. This could be used, e.g., if maintaining charge is not desired after fully charging a battery even if the charging controller and battery support it. The object batteryChargingAdminState can then be set to doNotCharge(3) when the object batteryChargingOperState changes from charging(2) to maintainingCharge(3). Another use case would be when performing several charge and discharge cycles for battery maintenance.3.6. Imported Definitions
The BATTERY-MIB module defined in this document imports definitions from the following MIB modules: SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], and ENTITY-MIB [RFC6933].
(page 11 continued on part 2)