summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7577.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7577.txt')
-rw-r--r--doc/rfc/rfc7577.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc7577.txt b/doc/rfc/rfc7577.txt
new file mode 100644
index 0000000..2886d43
--- /dev/null
+++ b/doc/rfc/rfc7577.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+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
+
+
+ --******************************************************************
+ -- Top-Level Structure of the MIB Module
+ --******************************************************************
+
+ batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 }
+ batteryObjects OBJECT IDENTIFIER ::= { batteryMIB 1 }
+ batteryConformance OBJECT IDENTIFIER ::= { batteryMIB 2 }
+
+ --==================================================================
+ -- 1. Object Definitions
+ --==================================================================
+
+ --------------------------------------------------------------------
+ -- 1.1. Battery Table
+ --------------------------------------------------------------------
+ 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 }
+
+ --==================================================================
+ -- 2. Notifications
+ --==================================================================
+
+ 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
+
+
+ --==================================================================
+ -- 3. Conformance Information
+ --==================================================================
+
+ batteryCompliances OBJECT IDENTIFIER ::= { batteryConformance 1 }
+ batteryGroups OBJECT IDENTIFIER ::= { batteryConformance 2 }
+
+ --------------------------------------------------------------------
+ -- 3.1. Compliance Statements
+ --------------------------------------------------------------------
+
+ 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 }
+
+ --------------------------------------------------------------------
+ -- 3.2. MIB Grouping
+ --------------------------------------------------------------------
+
+ 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]
+