Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 7577

Proposed STD
Pages: 40
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: EMAN

Definition of Managed Objects for Battery Monitoring

Part 1 of 2, p. 1 to 11
None     Next RFC Part


Top       ToC       Page 1 
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 Monitoring


   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

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
   ( 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.

Top       Page 2 
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  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  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

   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:

Top      ToC       Page 3 
   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

   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.

Top      ToC       Page 4 
   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

Top      ToC       Page 5 
   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",
   "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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
      +--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

   4.  an aged battery that may need to be replaced,

   5.  a battery that has exceeded a temperature threshold,

Top      ToC       Page 8 
   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 <
   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.

Top      ToC       Page 9 
      | 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

Top      ToC       Page 10 
   for batteries that can be replaced, the identifiers have different

   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

   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.

Top      ToC       Page 11 
   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)

Next RFC Part