GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7577

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

Abstract

 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.

Quittek, et al. Standards Track [Page 1] RFC 7577 Battery MIB July 2015

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
 [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:

Quittek, et al. Standards Track [Page 2] RFC 7577 Battery MIB July 2015

 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.

Quittek, et al. Standards Track [Page 3] RFC 7577 Battery MIB July 2015

 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

Quittek, et al. Standards Track [Page 4] RFC 7577 Battery MIB July 2015

 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

Quittek, et al. Standards Track [Page 5] RFC 7577 Battery MIB July 2015

 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.

Quittek, et al. Standards Track [Page 6] RFC 7577 Battery MIB July 2015

    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,

Quittek, et al. Standards Track [Page 7] RFC 7577 Battery MIB July 2015

 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.

Quittek, et al. Standards Track [Page 8] RFC 7577 Battery MIB July 2015

    +--------------------------------+---------------+
    | 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

Quittek, et al. Standards Track [Page 9] RFC 7577 Battery MIB July 2015

 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.

Quittek, et al. Standards Track [Page 10] RFC 7577 Battery MIB July 2015

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

4. Definitions

BATTERY-MIB DEFINITIONS ::= BEGIN
IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
    mib-2, Integer32, Unsigned32
        FROM SNMPv2-SMI                                -- RFC 2578
    DateAndTime
        FROM SNMPv2-TC                                 -- RFC 2579
    MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
        FROM SNMPv2-CONF                               -- RFC 2580
    SnmpAdminString
        FROM SNMP-FRAMEWORK-MIB                        -- RFC 3411
    entPhysicalIndex
        FROM ENTITY-MIB;                               -- RFC 6933

Quittek, et al. Standards Track [Page 11] RFC 7577 Battery MIB July 2015

batteryMIB MODULE-IDENTITY
    LAST-UPDATED "201506150000Z"         -- 15 June 2015
    ORGANIZATION "IETF EMAN Working Group"
    CONTACT-INFO
        "General Discussion: eman@ietf.org
        To Subscribe: <http://www.ietf.org/mailman/listinfo/eman>
        Archive: <http://www.ietf.org/mail-archive/web/eman>
        Editor:
          Juergen Quittek
          NEC Europe, Ltd.
          NEC Laboratories Europe
          Kurfuersten-Anlage 36
          69115 Heidelberg
          Germany
          Tel: +49 6221 4342-115
          Email: quittek@neclab.eu"
    DESCRIPTION
        "This MIB module defines a set of objects for monitoring
        batteries of networked devices and of their components.
        Copyright (c) 2015 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.
        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).
        This version of this MIB module is part of RFC 7577; see
        the RFC itself for full legal notices."
--  Revision history
    REVISION "201506150000Z"         -- 15 June 2015
    DESCRIPTION
        "Initial version published as RFC 7577."
    ::= { mib-2 233 }

Quittek, et al. Standards Track [Page 12] RFC 7577 Battery MIB July 2015

  1. - – Top-Level Structure of the MIB Module –
batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 }
batteryObjects       OBJECT IDENTIFIER ::= { batteryMIB 1 }
batteryConformance   OBJECT IDENTIFIER ::= { batteryMIB 2 }
  1. -==================================================================
  2. - 1. Object Definitions
  3. -==================================================================
  1. ——————————————————————-
  2. - 1.1. Battery Table
  3. ——————————————————————-

batteryTable OBJECT-TYPE

    SYNTAX      SEQUENCE OF BatteryEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "This table provides information on batteries.  It contains
        one conceptual row per battery in a managed entity.
        Batteries are indexed by the entPhysicalIndex of the
        entPhysicalTable defined in the ENTITY-MIB (RFC 6933).
        For implementations of the BATTERY-MIB, an implementation of
        the ENTITY-MIB complying with the entity4CRCompliance
        MODULE-COMPLIANCE statement of the ENTITY-MIB is required.
        If batteries are replaced, and the replacing battery uses
        the same physical connector as the replaced battery, then
        the replacing battery SHOULD be indexed with the same value
        of object entPhysicalIndex as the replaced battery."
    ::= { batteryObjects 1 }
batteryEntry OBJECT-TYPE
    SYNTAX      BatteryEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "An entry providing information on a battery."
    INDEX  { entPhysicalIndex }
    ::= { batteryTable 1 }

Quittek, et al. Standards Track [Page 13] RFC 7577 Battery MIB July 2015

BatteryEntry ::=
    SEQUENCE {
       batteryIdentifier               SnmpAdminString,
       batteryFirmwareVersion          SnmpAdminString,
       batteryType                     INTEGER,
       batteryTechnology               Unsigned32,
       batteryDesignVoltage            Unsigned32,
       batteryNumberOfCells            Unsigned32,
       batteryDesignCapacity           Unsigned32,
       batteryMaxChargingCurrent       Unsigned32,
       batteryTrickleChargingCurrent   Unsigned32,
       batteryActualCapacity           Unsigned32,
       batteryChargingCycleCount       Unsigned32,
       batteryLastChargingCycleTime    DateAndTime,
       batteryChargingOperState        INTEGER,
       batteryChargingAdminState       INTEGER,
       batteryActualCharge             Unsigned32,
       batteryActualVoltage            Unsigned32,
       batteryActualCurrent            Integer32,
       batteryTemperature              Integer32,
       batteryAlarmLowCharge           Unsigned32,
       batteryAlarmLowVoltage          Unsigned32,
       batteryAlarmLowCapacity         Unsigned32,
       batteryAlarmHighCycleCount      Unsigned32,
       batteryAlarmHighTemperature     Integer32,
       batteryAlarmLowTemperature      Integer32,
       batteryCellIdentifier           SnmpAdminString
    }
batteryIdentifier OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object contains an identifier for the battery.
        Many manufacturers deliver not only simple batteries but
        battery packages including additional hardware and firmware.
        Typically, these modules include an identifier that can be
        retrieved by a device in which a battery has been installed.
        The identifier is useful when batteries are removed and
        reinstalled in the same or other devices.  Then, the device
        or the network management system can trace batteries and
        achieve continuity of battery monitoring.
        If the battery is identified by more than one value,
        for example, by a model number and a serial number,
        then the value of this object is a concatenation of these

Quittek, et al. Standards Track [Page 14] RFC 7577 Battery MIB July 2015

        values, separated by the colon symbol ':'.  The values
        should be ordered so that a more significant value comes
        before a less significant one.  In the example above, the
        (more significant) model number would be first, and the serial
        number would follow: '<model number>:<serial number>'.
        If the battery identifier cannot be represented using the
        ISO/IEC IS 10646-1 character set, then a hexadecimal
        encoding of a binary representation of the entire battery
        identifier must be used.
        The value of this object must be an empty string if there
        is no battery identifier or if the battery identifier is
        unknown."
    ::= { batteryEntry 1 }
batteryFirmwareVersion OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates the version number of the firmware
        that is included in a battery module.
        Many manufacturers deliver not pure batteries but battery
        packages including additional hardware and firmware.
        Since the behavior of the battery may change with the
        firmware, it may be useful to retrieve the firmware version
        number.
        The value of this object must be an empty string if there
        is no firmware or if the version number of the firmware is
        unknown."
    ::= { batteryEntry 2 }
batteryType OBJECT-TYPE
    SYNTAX      INTEGER {
                    unknown(1),
                    other(2),
                    primary(3),
                    rechargeable(4),
                    capacitor(5)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates the type of battery.

Quittek, et al. Standards Track [Page 15] RFC 7577 Battery MIB July 2015

        It distinguishes between primary (not rechargeable)
        batteries, rechargeable (secondary) batteries, and
        capacitors.  Capacitors are not really batteries but
        are often used in the same way as a battery.
        The value other(2) can be used if the battery type is known
        but is none of the ones above.  Value unknown(1) is to be used
        if the type of battery cannot be determined."
    ::= { batteryEntry 3 }
batteryTechnology OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates the technology used by the battery.
        Numbers identifying battery technologies are registered at
        IANA.  A current list of assignments can be found at
        <http://www.iana.org/assignments/battery-technologies>.
        Value unknown(1) MUST be used if the technology of the
        battery cannot be determined.
        Value other(2) can be used if the battery technology is known
        but is not one of the types already registered at IANA."
    ::= { batteryEntry 4 }
batteryDesignVoltage OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "millivolt"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object provides the design (or nominal) voltage of the
        battery in units of millivolt (mV).
        Note that the design voltage is a constant value and
        typically different from the actual voltage of the battery.
        A value of 0 indicates that the design voltage is unknown."
    ::= { batteryEntry 5 }
batteryNumberOfCells OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current

Quittek, et al. Standards Track [Page 16] RFC 7577 Battery MIB July 2015

    DESCRIPTION
        "This object indicates the number of cells contained in the
        battery.
        A value of 0 indicates that the number of cells is unknown."
    ::= { batteryEntry 6 }
batteryDesignCapacity OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere hours"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object provides the design (or nominal) capacity of
        the battery in units of milliampere hours (mAh).
        Note that the design capacity is a constant value and
        typically different from the actual capacity of the battery.
        Usually, this is a value provided by the manufacturer of the
        battery.
        A value of 0 indicates that the design capacity is
        unknown."
    ::= { batteryEntry 7 }
batteryMaxChargingCurrent OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object provides the maximum current to be used for
        charging the battery in units of milliampere (mA).
        Note that the maximum charging current may not lead to
        optimal charge of the battery and that some batteries can
        only be charged with the maximum current for a limited
        amount of time.
        A value of 0 indicates that the maximum charging current is
        unknown."
    ::= { batteryEntry 8 }
batteryTrickleChargingCurrent OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere"
    MAX-ACCESS  read-only
    STATUS      current

Quittek, et al. Standards Track [Page 17] RFC 7577 Battery MIB July 2015

    DESCRIPTION
        "This object provides the recommended average current
        to be used for trickle charging the battery in units of
        mA.
        Typically, this is a value recommended by the manufacturer
        of the battery or by the manufacturer of the charging
        circuit.
        A value of 0 indicates that the recommended trickle charging
        current is unknown."
    ::= { batteryEntry 9 }
batteryActualCapacity OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere hours"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object provides the actual capacity of the
        battery in units of mAh.
        Typically, the actual capacity of a battery decreases
        with time and with usage of the battery.  It is usually
        lower than the design capacity.
        Note that the actual capacity needs to be measured and is
        typically an estimate based on observed discharging and
        charging cycles of the battery.
        A value of 'ffffffff'H indicates that the actual capacity
        cannot be determined."
    ::= { batteryEntry 10 }
batteryChargingCycleCount OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates the number of completed charging
        cycles that the battery underwent.  In line with the
        Smart Battery Data Specification Revision 1.1, a charging
        cycle is defined as the process of discharging the battery
        by a total amount equal to the battery design capacity as
        given by object batteryDesignCapacity.  A charging cycle
        may include several steps of charging and discharging the
        battery until the discharging amount given by
        batteryDesignCapacity has been reached.  As soon as a

Quittek, et al. Standards Track [Page 18] RFC 7577 Battery MIB July 2015

        charging cycle has been completed, the next one starts
        immediately, independent of the battery's current charge at
        the end of the cycle.
        For batteries of type primary(3), the value of this object is
        always 0.
        A value of 'ffffffff'H indicates that the number of charging
        cycles cannot be determined."
    ::= { batteryEntry 11 }
batteryLastChargingCycleTime OBJECT-TYPE
    SYNTAX      DateAndTime
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The date and time of the last charging cycle.  The value
        '0000000000000000'H is returned if the battery has not been
        charged yet or if the last charging time cannot be
        determined.
        For batteries of type primary(1), the value of this object is
        always '0000000000000000'H."
    ::= { batteryEntry 12 }
batteryChargingOperState OBJECT-TYPE
    SYNTAX      INTEGER {
                    unknown(1),
                    charging(2),
                    maintainingCharge(3),
                    noCharging(4),
                    discharging(5)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object indicates the current charging state of the
        battery.
        Value unknown(1) indicates that the charging state of the
        battery cannot be determined.
        Value charging(2) indicates that the battery is being
        charged in a way such that the charge of the battery
        increases.
        Value maintainingCharge(3) indicates that the battery is
        being charged with a low-average current that compensates

Quittek, et al. Standards Track [Page 19] RFC 7577 Battery MIB July 2015

        self-discharging.  This includes trickle charging, float
        charging, and other methods for maintaining the current
        charge of a battery.  In typical implementations of charging
        controllers, state maintainingCharge(3) is only applied
        if the battery is fully charged or almost fully charged.
        Value noCharging(4) indicates that the battery is not being
        charged or discharged by electric current between the
        battery and electric circuits external to the battery.
        Note that the battery may still be subject to
        self-discharging.
        Value discharging(5) indicates that the battery is either
        used as the power source for electric circuits external to
        the battery or discharged intentionally by the
        charging controller, e.g., for the purpose of battery
        maintenance.  In any case, the charge of the battery
        decreases."
    ::= { batteryEntry 13 }
batteryChargingAdminState OBJECT-TYPE
    SYNTAX      INTEGER {
                    notSet(1),
                    charge(2),
                    doNotCharge(3),
                    discharge(4)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "The value of this object indicates the desired
        charging state of the battery.  The real state is
        indicated by object batteryChargingOperState.  See the
        definition of object batteryChargingOperState for a
        description of the values.
        When this object is initialized by an implementation of the
        BATTERY-MIB module, its value is set to notSet(1).  In this
        case, the charging controller is free to choose which
        operational state is suitable.
        When the batteryChargingAdminState object is set, then the
        BATTERY-MIB implementation must try to set the battery
        to the indicated state.  The result will be indicated by
        object batteryChargingOperState.
        Setting object batteryChargingAdminState to value notSet(1)
        is a request to the charging controller to operate

Quittek, et al. Standards Track [Page 20] RFC 7577 Battery MIB July 2015

        autonomously and choose the operational state that is
        suitable.
        Setting object batteryChargingAdminState to value charge(2)
        is a request to enter the operational state charging(2) until
        the battery is fully charged.  When the battery is fully
        charged, or if the battery was already fully charged or
        almost fully charged at the time of the request, the
        operational state will change to maintainingCharge(3) if the
        charging controller and the battery support the functionality
        of maintaining the charge, or it will change to noCharging(4)
        otherwise.
        Setting object batteryChargingAdminState to value
        doNotCharge(3) is a request for entering operational
        state noCharging(4).
        Setting object batteryChargingAdminState to value
        discharge(4) is a request for entering operational
        state discharging(5).  Discharging can be accomplished
        by ordinary use, applying a dedicated load, or any other
        means.  An example for applying this state is battery
        maintenance.  If the battery is empty or almost empty, the
        operational state will change to noCharging(4).
        The charging controller will decide which charge condition
        will be considered empty dependent on the battery
        technology used.  This is done to avoid damage on the
        battery due to deep discharge.
        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 may not be possible.
        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.  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."
    ::= { batteryEntry 14 }
batteryActualCharge OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere hours"
    MAX-ACCESS  read-only
    STATUS      current

Quittek, et al. Standards Track [Page 21] RFC 7577 Battery MIB July 2015

    DESCRIPTION
        "This object provides the actual charge of the battery
        in units of mAh.
        Note that the actual charge needs to be measured and is
        typically an estimate based on observed discharging and
        charging cycles of the battery.
        A value of 'ffffffff'H indicates that the actual charge
        cannot be determined."
    ::= { batteryEntry 15 }
batteryActualVoltage OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "millivolt"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object provides the actual voltage of the battery
        in units of mV.
        A value of 'ffffffff'H indicates that the actual voltage
        cannot be determined."
    ::= { batteryEntry 16 }
batteryActualCurrent OBJECT-TYPE
    SYNTAX      Integer32
    UNITS       "milliampere"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object provides the actual charging or discharging
        current of the battery in units of mA.
        The charging current is represented by positive values,
        and the discharging current is represented by negative values.
        A value of '7fffffff'H indicates that the actual current
        cannot be determined."
    ::= { batteryEntry 17 }
batteryTemperature OBJECT-TYPE
    SYNTAX      Integer32
    UNITS       "deci-degrees Celsius"
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The ambient temperature at or within close proximity
        of the battery.

Quittek, et al. Standards Track [Page 22] RFC 7577 Battery MIB July 2015

        A value of '7fffffff'H indicates that the temperature
        cannot be determined."
    ::= { batteryEntry 18 }
batteryAlarmLowCharge OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere hours"
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "This object provides the lower-threshold value for object
        batteryActualCharge.  If the value of object
        batteryActualCharge falls below this threshold,
        a low-battery alarm will be raised.  The alarm procedure may
        include generating a batteryLowNotification.
        This object should be set to a value such that when the
        batteryLowNotification is generated, the battery is still
        sufficiently charged to keep the device(s) that it powers
        operational for a time long enough to take actions before
        the powered device(s) enters a 'sleep' or 'off' state.
        A value of 0 indicates that no alarm will be raised for any
        value of object batteryActualVoltage."
    ::= { batteryEntry 19 }
  batteryAlarmLowVoltage OBJECT-TYPE
      SYNTAX      Unsigned32
      UNITS       "millivolt"
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "This object provides the lower-threshold value for object
          batteryActualVoltage.  If the value of object
          batteryActualVoltage falls below this threshold,
          a low-battery alarm will be raised.  The alarm procedure may
          include generating a batteryLowNotification.
          This object should be set to a value such that when the
          batteryLowNotification is generated, the battery is still
          sufficiently charged to keep the device(s) that it powers
          operational for a time long enough to take actions before
          the powered device(s) enters a 'sleep' or 'off' state.
          A value of 0 indicates that no alarm will be raised for any
          value of object batteryActualVoltage."
      ::= { batteryEntry 20 }

Quittek, et al. Standards Track [Page 23] RFC 7577 Battery MIB July 2015

batteryAlarmLowCapacity OBJECT-TYPE
    SYNTAX      Unsigned32
    UNITS       "milliampere hours"
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "This object provides the lower-threshold value for object
        batteryActualCapacity.  If the value of object
        batteryActualCapacity falls below this threshold,
        a battery aging alarm will be raised.  The alarm procedure
        may include generating a batteryAgingNotification.
        A value of 0 indicates that no alarm will be raised for any
        value of object batteryActualCapacity."
    ::= { batteryEntry 21 }
batteryAlarmHighCycleCount OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "This object provides the upper-threshold value for object
        batteryChargingCycleCount.  If the value of object
        batteryChargingCycleCount rises above this threshold,
        a battery aging alarm will be raised.  The alarm procedure
        may include generating a batteryAgingNotification.
        A value of 0 indicates that no alarm will be raised for any
        value of object batteryChargingCycleCount."
    ::= { batteryEntry 22 }
batteryAlarmHighTemperature OBJECT-TYPE
    SYNTAX      Integer32
    UNITS       "deci-degrees Celsius"
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "This object provides the upper-threshold value for object
        batteryTemperature.  If the value of object
        batteryTemperature rises above this threshold, a battery
        high temperature alarm will be raised.  The alarm procedure
        may include generating a batteryTemperatureNotification.
        A value of '7fffffff'H indicates that no alarm will be
        raised for any value of object batteryTemperature."
    ::= { batteryEntry 23 }

Quittek, et al. Standards Track [Page 24] RFC 7577 Battery MIB July 2015

batteryAlarmLowTemperature OBJECT-TYPE
    SYNTAX      Integer32
    UNITS       "deci-degrees Celsius"
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "This object provides the lower-threshold value for object
        batteryTemperature.  If the value of object
        batteryTemperature falls below this threshold, a battery
        low temperature alarm will be raised.  The alarm procedure
        may include generating a batteryTemperatureNotification.
        A value of '7fffffff'H indicates that no alarm will be
        raised for any value of object batteryTemperature."
    ::= { batteryEntry 24 }
batteryCellIdentifier OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The value of this object identifies one or more cells of a
        battery.  The format of the cell identifier may vary between
        different implementations.  It should uniquely identify one
        or more cells of the indexed battery.
        This object can be used for batteries, such as lithium
        polymer batteries for which battery controllers monitor
        cells individually.
        This object is used by notifications of types
        batteryLowNotification, batteryTemperatureNotification,
        batteryCriticalNotification, and batteryAgingNotification.
        These notifications can use the value of this object to
        indicate the event that triggered the generation of the
        notification in more detail by specifying a single cell
        or a set of cells within the battery that is specifically
        addressed by the notification.
        An example use case for this object is a single cell in a
        battery that exceeds the temperature indicated by object
        batteryAlarmHighTemperature.  In such a case, a
        batteryTemperatureNotification can be generated that not
        only indicates the battery for which the temperature limit
        has been exceeded but also the particular cell.
        The initial value of this object is the empty string.  The
        value of this object is set each time a

Quittek, et al. Standards Track [Page 25] RFC 7577 Battery MIB July 2015

        batteryLowNotification, batteryTemperatureNotification,
        batteryCriticalNotification, or batteryAgingNotification
        is generated.
        When a notification is generated that does not indicate a
        specific cell or set of cells, the value of this object is
        set to the empty string."
    ::= { batteryEntry 25 }
  1. -==================================================================
  2. - 2. Notifications
  3. -==================================================================
batteryChargingStateNotification NOTIFICATION-TYPE
    OBJECTS     {
        batteryChargingOperState
    }
    STATUS      current
    DESCRIPTION
        "This notification can be generated when a charging state
        of the battery (indicated by the value of object
        batteryChargingOperState) is triggered by an event other
        than a write action to object batteryChargingAdminState.
        Such an event may, for example, be triggered by a local
        battery controller."
    ::= { batteryNotifications 1 }
batteryLowNotification NOTIFICATION-TYPE
    OBJECTS     {
        batteryActualCharge,
        batteryActualVoltage,
        batteryCellIdentifier
    }
    STATUS      current
    DESCRIPTION
        "This notification can be generated when the current charge
        (batteryActualCharge) or the current voltage
        (batteryActualVoltage) of the battery falls below a
        threshold defined by object batteryAlarmLowCharge or object
        batteryAlarmLowVoltage, respectively.
        Note that, typically, this notification is generated in a
        state where the battery is still sufficiently charged to keep
        the device(s) that it powers operational for some time.
        If the charging state of the battery has become critical,
        i.e., the device(s) powered by the battery must go to a
        'sleep' or 'off' state, then the batteryCriticalNotification
        should be used instead.

Quittek, et al. Standards Track [Page 26] RFC 7577 Battery MIB July 2015

        If the low charge or voltage has been detected for a single
        cell or a set of cells of the battery and not for the entire
        battery, then object batteryCellIdentifier should be set to
        a value that identifies the cell or set of cells.
        Otherwise, the value of object batteryCellIdentifier should
        be set to the empty string when this notification is
        generated.
        The notification should not be sent again for the same
        battery or cell before either (a) the current voltage or
        the current charge, respectively, has become higher than the
        corresponding threshold through charging or (b) an indication
        of a maintenance action has been detected, such as a battery
        disconnection event or a reinitialization of the battery
        monitoring system.
        This notification should not be sent when the battery is in
        a charging mode, i.e., the value of object
        batteryChargingOperState is charging(2)."
    ::= { batteryNotifications 2 }
batteryCriticalNotification NOTIFICATION-TYPE
    OBJECTS     {
        batteryActualCharge,
        batteryActualVoltage,
        batteryCellIdentifier
    }
    STATUS      current
    DESCRIPTION
        "This notification can be generated when the current charge
        of the battery falls so low that it cannot provide a
        sufficient power supply function for regular operation
        of the powered device(s).  The battery needs to be charged
        before it can be used for regular power supply again.  The
        battery may still provide sufficient power for a 'sleep'
        mode of a powered device(s) or for a transition into an 'off'
        mode.
        If the critical state is caused by a single cell or a set of
        cells of the battery, then object batteryCellIdentifier
        should be set to a value that identifies the cell or set of
        cells.  Otherwise, the value of object batteryCellIdentifier
        should be set to the empty string when this notification is
        generated.
        The notification should not be sent again for the same
        battery before either the battery charge has increased
        through charging to a non-critical value or an indication

Quittek, et al. Standards Track [Page 27] RFC 7577 Battery MIB July 2015

        of a maintenance action has been detected, such as a battery
        disconnection event or a reinitialization of the battery
        monitoring system.
        This notification should not be sent when the battery is in
        a charging mode, i.e., the value of object
        batteryChargingOperState is charging(2)."
    ::= { batteryNotifications 3 }
batteryTemperatureNotification NOTIFICATION-TYPE
    OBJECTS     {
        batteryTemperature,
        batteryCellIdentifier
    }
    STATUS      current
    DESCRIPTION
        "This notification can be generated when the measured
        temperature (batteryTemperature) rises above the threshold
        defined by object batteryAlarmHighTemperature or falls
        below the threshold defined by object
        batteryAlarmLowTemperature.
        If the low or high temperature has been detected for a
        single cell or a set of cells of the battery and not for the
        entire battery, then object batteryCellIdentifier should be
        set to a value that identifies the cell or set of cells.
        Otherwise, the value of object batteryCellIdentifier should
        be set to the empty string when this notification is
        generated.
        It may occur that the temperature alternates between values
        slightly below and slightly above a threshold.  For limiting
        the notification rate in such a case, this notification
        should not be sent again for the same battery or cell,
        respectively, within a time interval of 10 minutes.
        An exception to the rate limitations occurs immediately
        after the reinitialization of the battery monitoring system.
        At this point in time, if the battery temperature is above
        the threshold defined by object batteryAlarmHighTemperature
        or below the threshold defined by object
        batteryAlarmLowTemperature, respectively, then this
        notification should be sent, independent of the time at
        which previous notifications for the same battery or cell,
        respectively, had been sent."
    ::= { batteryNotifications 4 }

Quittek, et al. Standards Track [Page 28] RFC 7577 Battery MIB July 2015

batteryAgingNotification NOTIFICATION-TYPE
    OBJECTS     {
        batteryActualCapacity,
        batteryChargingCycleCount,
        batteryCellIdentifier
    }
    STATUS      current
    DESCRIPTION
        "This notification can be generated when the actual
        capacity (batteryActualCapacity) falls below a threshold
        defined by object batteryAlarmLowCapacity
        or when the charging cycle count of the battery
        (batteryChargingCycleCount) exceeds the threshold defined
        by object batteryAlarmHighCycleCount.
        If the aging has been detected for a single cell or a set
        of cells of the battery and not for the entire battery, then
        object batteryCellIdentifier should be set to a value that
        identifies the cell or set of cells.  Otherwise, the value
        of object batteryCellIdentifier should be set to the empty
        string when this notification is generated.
        This notification should not be sent again for the same
        battery or cell, respectively, before an indication of a
        maintenance action has been detected, such as a battery
        disconnection event or a reinitialization of the battery
        monitoring system."
    ::= { batteryNotifications 5 }
batteryConnectedNotification NOTIFICATION-TYPE
    OBJECTS     {
        batteryIdentifier
    }
    STATUS      current
    DESCRIPTION
        "This notification can be generated when it has been
        detected that a battery has been connected.  The battery
        can be identified by the value of object batteryIdentifier
        as well as by the value of index entPhysicalIndex that is
        contained in the OID of object batteryIdentifier."
    ::= { batteryNotifications 6 }
batteryDisconnectedNotification NOTIFICATION-TYPE
    STATUS      current
    DESCRIPTION
        "This notification can be generated when it has been
        detected that one or more batteries have been disconnected."
    ::= { batteryNotifications 7 }

Quittek, et al. Standards Track [Page 29] RFC 7577 Battery MIB July 2015

  1. -==================================================================
  2. - 3. Conformance Information
  3. -==================================================================
batteryCompliances OBJECT IDENTIFIER ::= { batteryConformance 1 }
batteryGroups      OBJECT IDENTIFIER ::= { batteryConformance 2 }
  1. ——————————————————————-
  2. - 3.1. Compliance Statements
  3. ——————————————————————-
batteryCompliance MODULE-COMPLIANCE
    STATUS      current
    DESCRIPTION
        "The compliance statement for implementations of the
        BATTERY-MIB module.
        A compliant implementation MUST implement the objects
        defined in the mandatory groups batteryDescriptionGroup
        and batteryStatusGroup.
        Note that this compliance statement requires
        compliance with the entity4CRCompliance
        MODULE-COMPLIANCE statement of the
        ENTITY-MIB (RFC 6933)."
    MODULE  -- this module
        MANDATORY-GROUPS {
            batteryDescriptionGroup,
            batteryStatusGroup
        }
        GROUP   batteryAlarmThresholdsGroup
        DESCRIPTION
           "A compliant implementation does not have to implement
            the batteryAlarmThresholdsGroup."
        GROUP   batteryNotificationsGroup
        DESCRIPTION
           "A compliant implementation does not have to implement
            the batteryNotificationsGroup."
        GROUP   batteryPerCellNotificationsGroup
        DESCRIPTION
           "A compliant implementation does not have to implement
            the batteryPerCellNotificationsGroup."
        GROUP   batteryAdminGroup
        DESCRIPTION

Quittek, et al. Standards Track [Page 30] RFC 7577 Battery MIB July 2015

           "A compliant implementation does not have to implement
            the batteryAdminGroup."
        OBJECT batteryAlarmLowCharge
        MIN-ACCESS  read-only
        DESCRIPTION
            "A compliant implementation is not required
            to support set operations on this object."
        OBJECT batteryAlarmLowVoltage
        MIN-ACCESS  read-only
        DESCRIPTION
            "A compliant implementation is not required
            to support set operations on this object."
        OBJECT batteryAlarmLowCapacity
        MIN-ACCESS  read-only
        DESCRIPTION
            "A compliant implementation is not required
            to support set operations on this object."
        OBJECT batteryAlarmHighCycleCount
        MIN-ACCESS  read-only
        DESCRIPTION
            "A compliant implementation is not required
            to support set operations on this object."
        OBJECT batteryAlarmHighTemperature
        MIN-ACCESS  read-only
        DESCRIPTION
            "A compliant implementation is not required
            to support set operations on this object."
        OBJECT batteryAlarmLowTemperature
        MIN-ACCESS  read-only
        DESCRIPTION
            "A compliant implementation is not required
            to support set operations on this object."
    ::= { batteryCompliances 1 }
  1. ——————————————————————-
  2. - 3.2. MIB Grouping
  3. ——————————————————————-
batteryDescriptionGroup OBJECT-GROUP
    OBJECTS {
       batteryIdentifier,

Quittek, et al. Standards Track [Page 31] RFC 7577 Battery MIB July 2015

       batteryFirmwareVersion,
       batteryType,
       batteryTechnology,
       batteryDesignVoltage,
       batteryNumberOfCells,
       batteryDesignCapacity,
       batteryMaxChargingCurrent,
       batteryTrickleChargingCurrent
    }
    STATUS      current
    DESCRIPTION
       "A compliant implementation MUST implement the objects
       contained in this group."
    ::= { batteryGroups 1 }
batteryStatusGroup OBJECT-GROUP
    OBJECTS {
       batteryActualCapacity,
       batteryChargingCycleCount,
       batteryLastChargingCycleTime,
       batteryChargingOperState,
       batteryActualCharge,
       batteryActualVoltage,
       batteryActualCurrent,
       batteryTemperature
    }
    STATUS      current
    DESCRIPTION
       "A compliant implementation MUST implement the objects
       contained in this group."
    ::= { batteryGroups 2 }
batteryAdminGroup OBJECT-GROUP
    OBJECTS {
       batteryChargingAdminState
    }
    STATUS      current
    DESCRIPTION
       "A compliant implementation does not have to implement the
       object contained in this group."
    ::= { batteryGroups 3 }
batteryAlarmThresholdsGroup OBJECT-GROUP
    OBJECTS {
       batteryAlarmLowCharge,
       batteryAlarmLowVoltage,
       batteryAlarmLowCapacity,
       batteryAlarmHighCycleCount,

Quittek, et al. Standards Track [Page 32] RFC 7577 Battery MIB July 2015

       batteryAlarmHighTemperature,
       batteryAlarmLowTemperature
    }
    STATUS      current
    DESCRIPTION
       "A compliant implementation does not have to implement the
       objects contained in this group."
    ::= { batteryGroups 4 }
batteryNotificationsGroup NOTIFICATION-GROUP
    NOTIFICATIONS {
       batteryChargingStateNotification,
       batteryLowNotification,
       batteryCriticalNotification,
       batteryAgingNotification,
       batteryTemperatureNotification,
       batteryConnectedNotification,
       batteryDisconnectedNotification
    }
    STATUS      current
    DESCRIPTION
        "A compliant implementation does not have to implement the
        notifications contained in this group."
    ::= { batteryGroups 5 }
batteryPerCellNotificationsGroup OBJECT-GROUP
    OBJECTS {
       batteryCellIdentifier
    }
    STATUS      current
    DESCRIPTION
        "A compliant implementation does not have to implement the
        object contained in this group."
    ::= { batteryGroups 6 }
END

5. Security Considerations

 There are a number of management objects defined in this MIB module
 with a MAX-ACCESS clause of read-write.  Such objects may be
 considered sensitive or vulnerable in some network environments.  The
 support for SET operations in a non-secure environment without proper
 protection opens devices to attack.  These are the tables and objects
 and their sensitivity/vulnerability:
 o  batteryChargingAdminState:
    Setting the battery charging state can be beneficial for an
    operator for various reasons such as charging batteries when the

Quittek, et al. Standards Track [Page 33] RFC 7577 Battery MIB July 2015

    price of electricity is low.  However, setting the charging state
    can be used by an attacker to discharge batteries of devices and
    thereby switching these devices off if they are powered solely by
    batteries.  In particular, if the batteryAlarmLowCharge and
    batteryAlarmLowVoltage can also be set, this attack will go
    unnoticed (i.e., no notifications are sent).
 o  batteryAlarmLowCharge and batteryAlarmLowVoltage:
    These objects set the threshold for an alarm to be raised when the
    battery charge or voltage falls below the corresponding one of
    them.  An attacker setting one of these alarm values can switch
    off the alarm by setting it to the 'off' value 0, or it can modify
    the alarm behavior by setting it to any other value.  The result
    may be loss of data if the battery runs empty without warning to a
    recipient expecting such a notification.
 o  batteryAlarmLowCapacity and batteryAlarmHighCycleCount:
    These objects set the threshold for an alarm to be raised when the
    battery becomes older and less performant than required for stable
    operation.  An attacker setting this alarm value can switch off
    the alarm by setting it to the 'off' value 0 or modify the alarm
    behavior by setting it to any other value.  This may lead to
    either a costly replacement of a working battery or use of
    batteries that are too old or too weak.  The consequence of the
    latter could be that, e.g., a battery cannot provide power long
    enough between two scheduled charging actions causing the powered
    device to shut down and potentially lose data.
 o  batteryAlarmHighTemperature and batteryAlarmLowTemperature:
    These objects set thresholds for an alarm to be raised when the
    battery rises above / falls below them.  An attacker setting one
    of these alarm values can switch off these alarms by setting them
    to the 'off' value '7fffffff'H, or it can modify the alarm
    behavior by setting them to any other value.  The result may be,
    e.g., an unnecessary shutdown of a device if
    batteryAlarmHighTemperature is set too low, there is damage to the
    device by temperatures that are too high if switched off or set to
    values that are too high, or there is damage to the battery when,
    e.g., it is being charged.  Batteries can also be damaged, e.g.,
    in an attempt to charge them at temperatures that are too low.
 Some of the readable objects in this MIB module (i.e., objects with a
 MAX-ACCESS other than not-accessible) may be considered sensitive or
 vulnerable in some network environments.  It is thus important to
 control even GET and/or NOTIFY access to these objects and possibly
 to even encrypt the values of these objects when sending them over
 the network via SNMP.  These are the tables and objects and their
 sensitivity/vulnerability:

Quittek, et al. Standards Track [Page 34] RFC 7577 Battery MIB July 2015

 All potentially sensible or vulnerable objects of this MIB module are
 in the batteryTable.  In general, there are no serious operational
 vulnerabilities foreseen in case of an unauthorized read access to
 this table.  However, corporate confidentiality issues need to be
 considered.  The following information or parts of it might be a
 trade secret:
 o  the number of batteries installed in a managed node (batteryIndex)
 o  properties of these batteries (batteryActualCapacity and
    batteryChargingCycleCount)
 o  the time at which the next replacement cycle for batteries can be
    expected (batteryAlarmLowCapacity and batteryAlarmHighCycleCount)
 o  the types of batteries in use and their firmware versions
    (batteryIdentifier, batteryFirmwareVersion, batteryType, and
    batteryTechnology)
 For any battery-powered device whose use can be correlated to an
 individual or a small group of individuals, the following objects
 have the potential to reveal information about those individuals'
 activities or habits (e.g., if they are near a power outlet, if they
 have been using their devices heavily, etc.):
 o  batteryChargingCycleCount
 o  batteryLastChargingCycleTime
 o  batteryChargingOperState
 o  batteryActualCharge
 o  batteryActualVoltage
 o  batteryActualCurrent
 o  batteryTemperature
 o  batteryAlarmLowCharge
 o  batteryAlarmLowVoltage
 o  batteryAlarmLowCapacity
 o  batteryAlarmHighCycleCount
 o  batteryAlarmHighTemperature

Quittek, et al. Standards Track [Page 35] RFC 7577 Battery MIB July 2015

 o  batteryAlarmLowTemperature
 Implementers of this specification should use appropriate privacy
 protections as discussed in Section 9 of "Requirements for Energy
 Management" [RFC6988].  Battery monitoring of devices used by
 individuals or in homes should only occur with proper authorization.
 SNMP versions prior to SNMPv3 did not include adequate security.
 Even if the network itself is secure (for example by using IPsec),
 there is no control as to who on the secure network is allowed to
 access and GET/SET (read/change/create/delete) the objects in this
 MIB module.
 Implementations SHOULD provide the security features described by the
 SNMPv3 framework (see [RFC3410]), and implementations claiming
 compliance to the SNMPv3 standard MUST include full support for
 authentication and privacy via the User-based Security Model (USM)
 [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
 MAY also provide support for the Transport Security Model (TSM)
 [RFC5591] in combination with a secure transport such as SSH
 [RFC5592] or TLS/DTLS [RFC6353].
 Further, deployment of SNMP versions prior to SNMPv3 is NOT
 RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
 enable cryptographic security.  It is then a customer/operator
 responsibility to ensure that the SNMP entity giving access to an
 instance of this MIB module is properly configured to give access to
 the objects only to those principals (users) that have legitimate
 rights to indeed GET or SET (change/create/delete) them.

6. IANA Considerations

6.1. SMI Object Identifier Registration

 The Battery MIB module defined in this document uses the following
 IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers
 registry:
           Descriptor        OBJECT IDENTIFIER value
           ----------        -----------------------
           batteryMIB        { mib-2 233 }

6.2. Battery Technology Registration

 Object batteryTechnology defined in Section 4 reports battery
 technologies.  Eighteen values for battery technologies have
 initially been defined.  They are listed in a table in Section 3.2.

Quittek, et al. Standards Track [Page 36] RFC 7577 Battery MIB July 2015

 For ensuring extensibility of this list, IANA has created a registry
 for battery technologies at <http://www.iana.org/assignments/battery-
 technologies> and filled it with the initial list given in
 Section 3.2.
 New assignments of numbers for battery technologies will be
 administered by IANA through Expert Review [RFC5226].  Experts must
 check for sufficient relevance of a battery technology to be added
 according to the guidelines in Section 3.2.1.

7. References

7.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
            Schoenwaelder, Ed., "Structure of Management Information
            Version 2 (SMIv2)", STD 58, RFC 2578,
            DOI 10.17487/RFC2578, April 1999,
            <http://www.rfc-editor.org/info/rfc2578>.
 [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
            Schoenwaelder, Ed., "Textual Conventions for SMIv2",
            STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
            <http://www.rfc-editor.org/info/rfc2579>.
 [RFC2580]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
            Schoenwaelder, Ed., "Conformance Statements for SMIv2",
            STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
            <http://www.rfc-editor.org/info/rfc2580>.
 [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
            Architecture for Describing Simple Network Management
            Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
            DOI 10.17487/RFC3411, December 2002,
            <http://www.rfc-editor.org/info/rfc3411>.
 [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", STD 62, RFC 3414,
            DOI 10.17487/RFC3414, December 2002,
            <http://www.rfc-editor.org/info/rfc3414>.

Quittek, et al. Standards Track [Page 37] RFC 7577 Battery MIB July 2015

 [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
            Advanced Encryption Standard (AES) Cipher Algorithm in the
            SNMP User-based Security Model", RFC 3826,
            DOI 10.17487/RFC3826, June 2004,
            <http://www.rfc-editor.org/info/rfc3826>.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            DOI 10.17487/RFC5226, May 2008,
            <http://www.rfc-editor.org/info/rfc5226>.
 [RFC5591]  Harrington, D. and W. Hardaker, "Transport Security Model
            for the Simple Network Management Protocol (SNMP)",
            STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
            <http://www.rfc-editor.org/info/rfc5591>.
 [RFC5592]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
            Shell Transport Model for the Simple Network Management
            Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June
            2009, <http://www.rfc-editor.org/info/rfc5592>.
 [RFC6353]  Hardaker, W., "Transport Layer Security (TLS) Transport
            Model for the Simple Network Management Protocol (SNMP)",
            STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
            <http://www.rfc-editor.org/info/rfc6353>.
 [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
            Chandramouli, "Entity MIB (Version 4)", RFC 6933,
            DOI 10.17487/RFC6933, May 2013,
            <http://www.rfc-editor.org/info/rfc6933>.

7.2. Informative References

 [RFC1628]  Case, J., Ed., "UPS Management Information Base",
            RFC 1628, DOI 10.17487/RFC1628, May 1994,
            <http://www.rfc-editor.org/info/rfc1628>.
 [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
            "Introduction and Applicability Statements for Internet-
            Standard Management Framework", RFC 3410,
            DOI 10.17487/RFC3410, December 2002,
            <http://www.rfc-editor.org/info/rfc3410>.
 [RFC6988]  Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T.,
            and B. Claise, "Requirements for Energy Management",
            RFC 6988, DOI 10.17487/RFC6988, September 2013,
            <http://www.rfc-editor.org/info/rfc6988>.

Quittek, et al. Standards Track [Page 38] RFC 7577 Battery MIB July 2015

 [RFC7326]  Parello, J., Claise, B., Schoening, B., and J. Quittek,
            "Energy Management Framework", RFC 7326,
            DOI 10.17487/RFC7326, September 2014,
            <http://www.rfc-editor.org/info/rfc7326>.
 [RFC7460]  Chandramouli, M., Claise, B., Schoening, B., Quittek, J.,
            and T. Dietz, "Monitoring and Control MIB for Power and
            Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015,
            <http://www.rfc-editor.org/info/rfc7460>.
 [SBS]      "Smart Battery Data Specification", Revision 1.1, December
            1998.

Quittek, et al. Standards Track [Page 39] RFC 7577 Battery MIB July 2015

Acknowledgements

 We would like to thank Steven Chew, Bill Mielke, and Alan Luchuk for
 their valuable input.

Authors' Addresses

 Juergen Quittek
 NEC Europe, Ltd.
 NEC Laboratories Europe
 Network Research Division
 Kurfuersten-Anlage 36
 Heidelberg  69115
 Germany
 Phone: +49 6221 4342-115
 Email: quittek@neclab.eu
 Rolf Winter
 NEC Europe, Ltd.
 NEC Laboratories Europe
 Network Research Division
 Kurfuersten-Anlage 36
 Heidelberg  69115
 Germany
 Phone: +49 6221 4342-121
 Email: Rolf.Winter@neclab.eu
 Thomas Dietz
 NEC Europe, Ltd.
 NEC Laboratories Europe
 Network Research Division
 Kurfuersten-Anlage 36
 Heidelberg  69115
 Germany
 Phone: +49 6221 4342-128
 Email: Thomas.Dietz@neclab.eu

Quittek, et al. Standards Track [Page 40]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7577.txt · Last modified: 2015/07/23 12:57 (external edit)