idnits 2.17.1 draft-ietf-eman-battery-mib-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2015) is 3290 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Quittek 3 Internet-Draft R. Winter 4 Intended status: Standards Track T. Dietz 5 Expires: October 19, 2015 NEC Europe Ltd. 6 April 17, 2015 8 Definition of Managed Objects for Battery Monitoring 9 draft-ietf-eman-battery-mib-20 11 Abstract 13 This memo defines a portion of the Management Information Base (MIB) 14 for use with network management protocols in the Internet community. 15 In particular, it defines managed objects that provide information on 16 the status of batteries in managed devices. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 19, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. The Internet-Standard Management Framework . . . . . . . . . 5 54 3. Design of the Battery MIB Module . . . . . . . . . . . . . . 6 55 3.1. MIB Module Structure . . . . . . . . . . . . . . . . . . 6 56 3.2. Battery Technologies . . . . . . . . . . . . . . . . . . 8 57 3.2.1. Guidelines for Adding Battery Technologies . . . . . 9 58 3.3. Battery Identification . . . . . . . . . . . . . . . . . 9 59 3.4. Charging Cycles . . . . . . . . . . . . . . . . . . . . . 10 60 3.5. Charge Control . . . . . . . . . . . . . . . . . . . . . 10 61 3.6. Imported Definitions . . . . . . . . . . . . . . . . . . 11 62 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 65 6.1. SMI Object Identifier Registration . . . . . . . . . . . 36 66 6.2. Battery Technology Registration . . . . . . . . . . . . . 36 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 70 8.2. Informative References . . . . . . . . . . . . . . . . . 38 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 73 1. Introduction 75 Today, more and more managed devices contain batteries that supply 76 them with power when disconnected from electrical power distribution 77 grids. Common examples are nomadic and mobile devices, such as 78 notebook computers, netbooks, and smart phones. The status of 79 batteries in such a device, particularly the charging status is 80 typically controlled by automatic functions that act locally on the 81 device and manually by users of the device. 83 In addition to this, there is a need to monitor battery status of 84 these devices by network management systems. This document defines a 85 portion of the Management Information Base (MIB) that provides a 86 means for monitoring batteries in or attached to managed devices. 87 The Battery MIB module defined in Section 4 meets the requirements 88 for monitoring the status of batteries specified in RFC 6988 89 [RFC6988]. 91 The Battery MIB module provides for monitoring the battery status. 92 According to the framework for energy management [RFC7326] it is an 93 Energy Managed Object, and thus, MIB modules such as the Power and 94 Energy Monitoring MIB [RFC7460] could in principle be implemented for 95 batteries. The Battery MIB extends the more generic aspects of 96 energy management by adding battery-specific information. Amongst 97 other things, the Battery MIB enables the monitoring of: 99 o the current charge of a battery, 101 o the age of a battery (charging cycles), 103 o the state of a battery (e.g. being re-charged), 105 o last usage of a battery, 107 o maximum energy provided by a battery (remaining and total 108 capacity). 110 Further, means are provided for battery-powered devices to send 111 notifications when the current battery charge has dropped below a 112 certain threshold to inform the management system of needed 113 replacement. The same applies to the age of a battery. 115 Many battery-driven devices have existing instrumentation for 116 monitoring the battery status because this is already needed for 117 local control of the battery by the device. This reduces the effort 118 for implementing the managed objects defined in this document. For 119 many devices only additional software will be needed but no 120 additional hardware instrumentation for battery monitoring. 122 Since there are a lot of devices in use that contain more than one 123 battery, means for battery monitoring defined in this document 124 support addressing multiple batteries within a single device. Also, 125 batteries today often come in packages that can include 126 identification and might contain additional hardware and firmware. 127 The former allows tracing a battery and allows continuous monitoring 128 even if the battery is installed in another device. The firmware 129 version is useful information as the battery behavior might be 130 different for different firmware versions. 132 Not explicitly in scope of definitions in this document are very 133 small backup batteries, such as for example, batteries used on PC 134 motherboard to run the clock circuit and retain configuration memory 135 while the system is turned off. Other means may be required for 136 reporting on these batteries. However, the MIB module defined in 137 Section 3.1 can be used for this purpose. 139 A traditional type of managed device containing batteries is an 140 Uninterruptible Power Supply (UPS) system; these supply other devices 141 with electrical energy when the main power supply fails. There is 142 already a MIB module for managing UPS systems defined in RFC 1628 143 [RFC1628]. The UPS MIB module includes managed objects for 144 monitoring the batteries contained in an UPS system. However, the 145 information provided by the UPS MIB objects is limited and tailored 146 the particular needs of UPS systems. 148 There is a huge variety of battery technologies and it is evolving in 149 time. For different applications, different battery technologies are 150 preferable, for example, because of different weight, cost, 151 robustness, charging time, etc. Some technologies, such as lead acid 152 batteries are constantly in use for decades, while others, such as 153 nickel based battery technologies (nickel-cadmium, nickel-metal 154 hydride) have to a wide extend been replaced by lithium based battery 155 technologies (lithium-ion, lithium polymer). 157 The Battery MIB module uses a generic abstraction of batteries that 158 is independent of particular battery technologies and expected to be 159 applicable to future technologies as well. While identification of a 160 particular battery technology is supported by an extensible list of 161 battery technology identifiers (see Section 3.2), individual 162 properties of the technologies are not modelled by the abstraction. 163 In particular, methods for charging a battery and their parameters, 164 that vary a lot between different technologies, are not individually 165 modelled. 167 Instead, the Battery MIB module uses a simple common charging model 168 with batteries being in one of the states 'charging', 'maintaining 169 charge', 'not charging', and 'discharging'. Control of the charging 170 process is limited to requests for transitions between these states. 171 For charging controllers that use charging state engines with more 172 states, implementations of the Battery MIB module need to map those 173 states to the four listed ones. 175 For energy management systems that require finer grained control of 176 the battery charging process, additional means need to be developed, 177 such as, for example, MIB modules that model richer sets of charging 178 states and parameters for charging states. 180 All use cases sketched above assume that the batteries are contained 181 in a managed entity. In a typical case, this entity also hosts the 182 SNMP applications (command responder, notification generator) and the 183 charging controller for contained batteries. For definitions in this 184 document it is not strictly required that batteries are contained in 185 the same managed entity, even though the BATTERY-MIB module, that is 186 defined further below, uses the containment tree of the ENTITY-MIB 187 module [RFC6933] for battery indexing. 189 External batteries can be supported as long as the charging 190 controller for these batteries is connected to the SNMP applications 191 that implement the BATTERY-MIB module. An example with an external 192 battery is shown in the figure below. It illustrates that the 193 BATTERY-MIB module is designed as interface between management system 194 and battery charging controller. Out of scope of this document is 195 the interface between the battery charging controller and controlled 196 batteries. 198 +-----------------------------------+ 199 | management system | 200 +-----------------+-----------------+ 201 | 202 | BATTERY-MIB 203 | 204 +-----------------+-----------------+ 205 | managed element | | 206 | | | 207 | +--------------+--------------+ | 208 | | battery charging controller | | 209 | +-----+--------------+--------+ | 210 | | | | 211 | +-----+-----+ | | 212 | | internal | | | 213 | | battery | | | 214 | +-----------+ | | 215 +-----------------------+-----------+ 216 | 217 +-----+-----+ 218 | external | 219 | battery | 220 +-----------+ 222 Figure 1: The BATTERY-MIB as interface between management system and 223 battery charging controller supporting external batteries. 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 227 "OPTIONAL" in this document are to be interpreted as described in RFC 228 2119 [RFC2119]. 230 2. The Internet-Standard Management Framework 232 For a detailed overview of the documents that describe the current 233 Internet-Standard Management Framework, please refer to section 7 of 234 RFC 3410 [RFC3410]. 236 Managed objects are accessed via a virtual information store, termed 237 the Management Information Base or MIB. MIB objects are generally 238 accessed through the Simple Network Management Protocol (SNMP). 239 Objects in the MIB are defined using the mechanisms defined in the 240 Structure of Management Information (SMI). This memo specifies MIB 241 modules that are compliant to the SMIv2, which is described in STD 242 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 243 2580 [RFC2580]. 245 3. Design of the Battery MIB Module 247 3.1. MIB Module Structure 249 The Battery MIB module defined in this document defines objects for 250 reporting information about batteries. All managed objects providing 251 information of the status of a battery are contained in a single 252 table called batteryTable. The batteryTable contains one conceptual 253 row per battery. 255 Batteries are indexed by the entPhysicalIndex of the 256 entPhysicalTable defined in the ENTITY-MIB module [RFC6933]. An 257 implementation of the ENTITY-MIB module complying with the 258 entity4CRCompliance MODULE-COMPLIANCE statement is required for 259 compliant implementations of the BATTERY-MIB module. 261 If a battery is replaced, and the replacing battery uses the same 262 physical connector as the replaced battery, then the replacing 263 battery MUST be indexed with the same value of object 264 entPhysicalIndex as the replaced battery. 266 The kind of entity in the entPhysicalTable of the Entity MIB module 267 is indicated by the value of enumeration object entPhysicalClass. 268 All batteries SHOULD have the value of object entPhysicalClass set to 269 battery(14) in their row of the entPhysicalTable. 271 The batteryTable contains three groups of objects. The first group 272 (OIDs ending with 1-9) provides information on static properties of 273 the battery. The second group of objects (OIDs ending with 10-18) 274 provides information on the current battery state, if it is charging 275 or discharging, how much it is charged, its remaining capacity, the 276 number of experienced charging cycles, etc. 278 batteryTable(1) 279 +--batteryEntry(1) [entPhysicalIndex] 280 +-- r-n SnmpAdminString batteryIdentifier(1) 281 +-- r-n SnmpAdminString batteryFirmwareVersion(2) 282 +-- r-n Enumeration batteryType(3) 283 +-- r-n Unsigned32 batteryTechnology(4) 284 +-- r-n Unsigned32 batteryDesignVoltage(5) 285 +-- r-n Unsigned32 batteryNumberOfCells(6) 286 +-- r-n Unsigned32 batteryDesignCapacity(7) 287 +-- r-n Unsigned32 batteryMaxChargingCurrent(8) 288 +-- r-n Unsigned32 batteryTrickleChargingCurrent(9) 289 +-- r-n Unsigned32 batteryActualCapacity(10) 290 +-- r-n Unsigned32 batteryChargingCycleCount(11) 291 +-- r-n DateAndTime batteryLastChargingCycleTime(12) 292 +-- r-n Enumeration batteryChargingOperState(13) 293 +-- rwn Enumeration batteryChargingAdminState(14) 294 +-- r-n Unsigned32 batteryActualCharge(15) 295 +-- r-n Unsigned32 batteryActualVoltage(16) 296 +-- r-n Integer32 batteryActualCurrent(17) 297 +-- r-n Integer32 batteryTemperature(18) 298 +-- rwn Unsigned32 batteryAlarmLowCharge(19) 299 +-- rwn Unsigned32 batteryAlarmLowVoltage(20) 300 +-- rwn Unsigned32 batteryAlarmLowCapacity(21) 301 +-- rwn Unsigned32 batteryAlarmHighCycleCount(22) 302 +-- rwn Integer32 batteryAlarmHighTemperature(23) 303 +-- rwn Integer32 batteryAlarmLowTemperature(24) 304 +-- r-n SnmpAdminString batteryCellIdentifier(25) 306 The third group of objects in this table (OIDs ending with 19-25) is 307 used for notifications. Threshold objects (OIDs ending with 19-24) 308 indicate thresholds which can be used to raise an alarm if a property 309 of the battery exceeds one of them. Raising an alarm may include 310 sending a notification. 312 The Battery MIB defines seven notifications for indicating 314 1. a battery charging state change that was not triggered by writing 315 to object batteryChargingAdminState, 317 2. a low battery charging state, 319 3. a critical battery state in which it cannot be used for power 320 supply, 322 4. an aged battery that may need to be replaced, 324 5. a battery exceed a temperature threshold, 325 6. a battery that has been connected, 327 7. disconnection of one or more batteries. 329 Notifications 2.-5. can use object batteryCellIdentifier to indicate 330 a specific cell or a set of cells within the battery that have 331 triggered the notification. 333 3.2. Battery Technologies 335 Static information in the batteryTable includes battery type and 336 technology. The battery type distinguishes primary (not 337 rechargeable) batteries from rechargeable (secondary) batteries and 338 capacitors. The battery technology describes the actual technology 339 of a battery, which typically is a chemical technology. 341 Since battery technologies are subject of intensive research and 342 widely used technologies are often replaced by successor technologies 343 within an few years, the list of battery technologies was not chosen 344 as a fixed list. Instead, IANA has created a registry for battery 345 technologies at http://www.iana.org/assignments/battery-technologies 346 where numbers are assigned to battery technologies (TBD). 348 [NOTE for IANA: Please modify the URL above if you choose a different 349 one, see section on IANA Considerations below.] 351 The table below shows battery technologies known today that are in 352 commercial use with the numbers assigned to them by IANA. New 353 entries can be added to the IANA registry if new technologies are 354 developed or if missing technologies are identified. Note that there 355 exists a huge number of battery types that are not listed in the IANA 356 registry. Many of them are experimental or cannot be used in an 357 economically useful way. New entries should be added to the IANA 358 registry only if the respective technologies are in commercial use 359 and relevant to standardized battery monitoring over the Internet. 361 +--------------------------------+----------+ 362 | battery technology | assigned | 363 | | number | 364 +--------------------------------+----------+ 365 | Unknown | 1 | 366 | Other | 2 | 367 | Zinc-carbon | 3 | 368 | Zinc chloride | 4 | 369 | Nickel oxyhydroxide | 5 | 370 | Lithium-copper oxide | 6 | 371 | Lithium-iron disulfide | 7 | 372 | Lithium-manganese dioxide | 8 | 373 | Zinc-air | 9 | 374 | Silver oxide | 10 | 375 | Alkaline | 11 | 376 | Lead acid | 12 | 377 | Valve-Regulated Lead Acid, Gel | 13 | 378 | Valve-Regulated Lead Acid, AGM | 14 | 379 | Nickel-cadmium | 15 | 380 | Nickel-metal hydride | 16 | 381 | Nickel-zinc | 17 | 382 | Lithium-ion | 18 | 383 | Lithium polymer | 19 | 384 | Double layer capacitor | 20 | 385 +--------------------------------+----------+ 387 3.2.1. Guidelines for Adding Battery Technologies 389 New entries can be added to the IANA registry if new technologies are 390 developed or if missing technologies are identified. Note that there 391 exists a huge number of battery types that are not listed in the IANA 392 registry. Many of them are experimental or cannot be used in an 393 economically useful way. New entries should be added to the IANA 394 registry only if the respective technologies are in commercial use 395 and relevant to standardized battery monitoring over the Internet. 397 3.3. Battery Identification 399 There are two identifiers to be used: The entPhysicalUUID defined in 400 the ENTITY-MIB [RFC6933] module and the batteryIdentifier defined in 401 this module. A battery is linked to an entPhysicalUUID through the 402 shared entPhysicalIndex. 404 The batteryIdentifier uniquely identifies the battery itself while 405 the entPhysicalUUID identifies the slot of the device in which the 406 battery is (currently) contained. For a non-replaceable battery both 407 identifiers are always linked to the same physical battery. But for 408 batteries that can be replaced, the identifiers have different 409 functions. 411 The entPhysicalUUID is always the same for a certain battery slot of 412 a containing device even if the contained battery is replaced by 413 another one. The batteryIdentifier is a representation of the 414 battery identifier set by the battery manufacturer. It is tied to 415 the battery and usually cannot be changed. 417 Many manufacturers deliver not just plain batteries but battery 418 packages including additional hardware and firmware. Typically, 419 these modules include an battery identifier that can by retrieved by 420 a device in which a battery has been installed. The value of the 421 object batteryIdentifier is an exact representation of this 422 identifier. The batteryIdentifier is useful when batteries are 423 removed and re-installed in the same device or in other devices. 424 Then the device or the network management system can trace batteries 425 and achieve continuity of battery monitoring. 427 3.4. Charging Cycles 429 The lifetime of a battery can be approximated using the measure of 430 charging cycles. A commonly used definition of a charging cycle is 431 the amount of discharge equal to the design (or nominal) capacity of 432 the battery [SBS]. This means that a single charging cycle may 433 include several steps of partial charging and discharging until the 434 amount of discharging has reached the design capacity of the battery. 435 After that the next charging cycle immediately starts. 437 3.5. Charge Control 439 Managed object batteryChargingOperState indicates the current 440 operational charging state of a battery and is a read-only object. 441 For controlling the charging state object batteryChargingAdminState 442 can be used. Writing to this object initiates a request to adapt the 443 operational state according to the value that has been written. 445 By default the batteryChargingAdminState object is set to notSet(1). 446 In this state the charging controller is using its predefined 447 policies to decide which operational state is suitable in the current 448 situation. 450 Setting the value of object batteryChargingAdminState may result in 451 not changing the state of the battery to this value or even in 452 setting the charging state to another value than the requested one. 453 Due to operational conditions and limitations of the implementation 454 of the BATTERY-MIB module, changing the battery status according to a 455 set value of object batteryChargingAdminState might not be possible. 457 For example, the charging controller might at any time decide to 458 enter state discharging(5), if there is an operational need to use 459 the battery for supplying power. 461 The object batteryChargingAdminState will not automatically change 462 when the object batteryChargingOperState changes. If the operational 463 state is changed, e.g. to the state discharging(5) due to operational 464 conditions, the admin state will remain in its current state. The 465 charging controller SHOULD change the operational state to the state 466 indicated by the object batteryChargingAdminState as soon as 467 operational conditions allow this change. 469 If a state change of the object batteryChargingAdminState is desired 470 upon change of the operational state, the object 471 batteryChargingOperState must be polled or the notification 472 batteryChargingStateNotification must be used to get notified about 473 the state change. This could be used, e.g. if maintaining charge is 474 not desired after fully charging a battery even if charging 475 controller and battery support it. The object 476 batteryChargingAdminState can then be set to doNotCharge(3) when the 477 object batteryChargingOperState changes from charging(2) to 478 maintainingCharge(3). Another use case would be when performing 479 several charge and discharge cycles for battery maintenance. 481 3.6. Imported Definitions 483 The Battery MIB module defined in this document imports definitions 484 from the following MIB modules: SNMPv2-SMI [RFC2578], SNMPv2-TC 485 [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], 486 ENTITY-MIB [RFC6933]. 488 4. Definitions 490 BATTERY-MIB DEFINITIONS ::= BEGIN 492 IMPORTS 493 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 494 mib-2, Integer32, Unsigned32 495 FROM SNMPv2-SMI -- RFC2578 496 SnmpAdminString 497 FROM SNMP-FRAMEWORK-MIB -- RFC3411 498 DateAndTime 499 FROM SNMPv2-TC -- RFC2579 500 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 501 FROM SNMPv2-CONF -- RFC2580 502 entPhysicalIndex 503 FROM ENTITY-MIB; -- RFC6933 505 batteryMIB MODULE-IDENTITY 506 LAST-UPDATED "201504171200Z" -- 17 April 2015 507 ORGANIZATION "IETF EMAN Working Group" 508 CONTACT-INFO 509 "General Discussion: eman@ietf.org 510 To Subscribe: http://www.ietf.org/mailman/listinfo/eman 511 Archive: http://www.ietf.org/mail-archive/web/eman 513 Editor: 514 Juergen Quittek 515 NEC Europe Ltd. 516 NEC Laboratories Europe 517 Kurfuersten-Anlage 36 518 69115 Heidelberg 519 Germany 520 Tel: +49 6221 4342-115 521 Email: quittek@neclab.eu" 523 DESCRIPTION 524 "This MIB module defines a set of objects for monitoring 525 batteries of networked devices and of their components. 527 Copyright (c) 2014 IETF Trust and the persons identified as 528 authors of the code. All rights reserved. 530 Redistribution and use in source and binary forms, with or 531 without modification, is permitted pursuant to, and subject 532 to the license terms contained in, the Simplified BSD 533 License set forth in Section 4.c of the IETF Trust's Legal 534 Provisions Relating to IETF Documents 535 (http://trustee.ietf.org/license-info). 537 This version of this MIB module is part of RFC yyyy; see 538 the RFC itself for full legal notices." 539 -- replace yyyy with actual RFC number & remove this notice 541 -- Revision history 543 REVISION "201504171200Z" -- 17 April 2015 544 DESCRIPTION 545 "Initial version, published as RFC yyyy." 546 -- replace yyyy with actual RFC number & remove this notice 548 ::= { mib-2 zzz } 549 -- zzz to be assigned by IANA. 551 --****************************************************************** 552 -- Top Level Structure of the MIB module 553 --****************************************************************** 555 batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 } 556 batteryObjects OBJECT IDENTIFIER ::= { batteryMIB 1 } 557 batteryConformance OBJECT IDENTIFIER ::= { batteryMIB 2 } 559 --================================================================== 560 -- 1. Object Definitions 561 --================================================================== 563 -------------------------------------------------------------------- 564 -- 1.1. Battery Table 565 -------------------------------------------------------------------- 566 batteryTable OBJECT-TYPE 567 SYNTAX SEQUENCE OF BatteryEntry 568 MAX-ACCESS not-accessible 569 STATUS current 570 DESCRIPTION 571 "This table provides information on batteries. It contains 572 one conceptual row per battery in a managed entity. 574 Batteries are indexed by the entPhysicalIndex of the 575 entPhysicalTable defined in the ENTITY-MIB (RFC6933). 577 For implementations of the BATTERY-MIB an implementation of 578 the ENTITY-MIB complying with the entity4CRCompliance 579 MODULE-COMPLIANCE statement of the ENTITY-MIB is required. 581 If batteries are replaced, and the replacing battery uses 582 the same physical connector as the replaced battery, then 583 the replacing battery SHOULD be indexed with the same value 584 of object entPhysicalIndex as the replaced battery." 585 ::= { batteryObjects 1 } 587 batteryEntry OBJECT-TYPE 588 SYNTAX BatteryEntry 589 MAX-ACCESS not-accessible 590 STATUS current 591 DESCRIPTION 592 "An entry providing information on a battery." 593 INDEX { entPhysicalIndex } 594 ::= { batteryTable 1 } 596 BatteryEntry ::= 597 SEQUENCE { 598 batteryIdentifier SnmpAdminString, 599 batteryFirmwareVersion SnmpAdminString, 600 batteryType INTEGER, 601 batteryTechnology Unsigned32, 602 batteryDesignVoltage Unsigned32, 603 batteryNumberOfCells Unsigned32, 604 batteryDesignCapacity Unsigned32, 605 batteryMaxChargingCurrent Unsigned32, 606 batteryTrickleChargingCurrent Unsigned32, 607 batteryActualCapacity Unsigned32, 608 batteryChargingCycleCount Unsigned32, 609 batteryLastChargingCycleTime DateAndTime, 610 batteryChargingOperState INTEGER, 611 batteryChargingAdminState INTEGER, 612 batteryActualCharge Unsigned32, 613 batteryActualVoltage Unsigned32, 614 batteryActualCurrent Integer32, 615 batteryTemperature Integer32, 616 batteryAlarmLowCharge Unsigned32, 617 batteryAlarmLowVoltage Unsigned32, 618 batteryAlarmLowCapacity Unsigned32, 619 batteryAlarmHighCycleCount Unsigned32, 620 batteryAlarmHighTemperature Integer32, 621 batteryAlarmLowTemperature Integer32, 622 batteryCellIdentifier SnmpAdminString 623 } 625 batteryIdentifier OBJECT-TYPE 626 SYNTAX SnmpAdminString 627 MAX-ACCESS read-only 628 STATUS current 629 DESCRIPTION 630 "This object contains an identifier for the battery. 632 Many manufacturers deliver not only simple batteries but 633 battery packages including additional hardware and firmware. 634 Typically, these modules include an identifier that can be 635 retrieved by a device in which a battery has been installed. 636 The identifier is useful when batteries are removed and 637 re-installed in the same or other devices. Then the device 638 or the network management system can trace batteries and 639 achieve continuity of battery monitoring. 641 If the battery is identified by more than one value, 642 for example, by a model number and a serial number, 643 then the value of this object is a concatenation of these 644 values, separated by the colon symbol ':'. The values 645 should be ordered that a more significant value comes 646 before a less significant one. In the example above, the 647 (more significant) model number would be first, the serial 648 number would follow: ':'. 650 If the battery identifier cannot be represented using the 651 ISO/IEC IS 10646-1 character set, then a hexadecimal 652 encoding of a binary representation of the entire battery 653 identifier must be used. 655 The value of this object must be an empty string if there 656 is no battery identifier or if the battery identifier is 657 unknown." 658 ::= { batteryEntry 1 } 660 batteryFirmwareVersion OBJECT-TYPE 661 SYNTAX SnmpAdminString 662 MAX-ACCESS read-only 663 STATUS current 664 DESCRIPTION 665 "This object indicates the version number of the firmware 666 that is included in a battery module. 668 Many manufacturers deliver not pure batteries but battery 669 packages including additional hardware and firmware. 671 Since the behavior of the battery may change with the 672 firmware, it may be useful to retrieve the firmware version 673 number. 675 The value of this object must be an empty string if there 676 is no firmware or if the version number of the firmware is 677 unknown." 678 ::= { batteryEntry 2 } 680 batteryType OBJECT-TYPE 681 SYNTAX INTEGER { 682 unknown(1), 683 other(2), 684 primary(3), 685 rechargeable(4), 686 capacitor(5) 687 } 688 MAX-ACCESS read-only 689 STATUS current 690 DESCRIPTION 691 "This object indicates the type of battery. 692 It distinguishes between primary (not rechargeable) 693 batteries, rechargeable (secondary) batteries, and 694 capacitors. Capacitors are not really batteries but 695 often used in the same way as a battery. 697 The value other(2) can be used if the battery type is known 698 but none of the ones above. Value unknown(1) is to be used 699 if the type of battery cannot be determined." 700 ::= { batteryEntry 3 } 702 batteryTechnology OBJECT-TYPE 703 SYNTAX Unsigned32 704 MAX-ACCESS read-only 705 STATUS current 706 DESCRIPTION 707 "This object indicates the technology used by the battery. 708 Numbers identifying battery types are registered at IANA. 709 A current list of assignments can be found at 710 . 712 Value 1 (unknown) MUST be used if the type of battery 713 cannot be determined. 715 Value 2 (other) can be used if the battery type is known 716 but not one of the types already registered at IANA." 717 ::= { batteryEntry 4 } 719 batteryDesignVoltage OBJECT-TYPE 720 SYNTAX Unsigned32 721 UNITS "millivolt" 722 MAX-ACCESS read-only 723 STATUS current 724 DESCRIPTION 725 "This object provides the design (or nominal) voltage of the 726 battery in units of millivolt (mV). 728 Note that the design voltage is a constant value and 729 typically different from the actual voltage of the battery. 731 A value of 0 indicates that the design voltage is unknown." 732 ::= { batteryEntry 5 } 734 batteryNumberOfCells OBJECT-TYPE 735 SYNTAX Unsigned32 736 MAX-ACCESS read-only 737 STATUS current 738 DESCRIPTION 739 "This object indicates the number of cells contained in the 740 battery. 742 A value of 0 indicates that the number of cells is unknown." 743 ::= { batteryEntry 6 } 745 batteryDesignCapacity OBJECT-TYPE 746 SYNTAX Unsigned32 747 UNITS "milliampere hours" 748 MAX-ACCESS read-only 749 STATUS current 750 DESCRIPTION 751 "This object provides the design (or nominal) capacity of 752 the battery in units of milliampere hours (mAh). 754 Note that the design capacity is a constant value and 755 typically different from the actual capacity of the battery. 756 Usually, this is a value provided by the manufacturer of the 757 battery. 759 A value of 0 indicates that the design capacity is 760 unknown." 761 ::= { batteryEntry 7 } 763 batteryMaxChargingCurrent OBJECT-TYPE 764 SYNTAX Unsigned32 765 UNITS "milliampere" 766 MAX-ACCESS read-only 767 STATUS current 768 DESCRIPTION 769 "This object provides the maximal current to be used for 770 charging the battery in units of milliampere (mA). 772 Note that the maximal charging current may not lead to 773 optimal charge of the battery and that some batteries can 774 only be charged with the maximal current for a limited 775 amount of time. 777 A value of 0 indicates that the maximal charging current is 778 unknown." 779 ::= { batteryEntry 8 } 781 batteryTrickleChargingCurrent OBJECT-TYPE 782 SYNTAX Unsigned32 783 UNITS "milliampere" 784 MAX-ACCESS read-only 785 STATUS current 786 DESCRIPTION 787 "This object provides the recommended average current 788 to be used for trickle charging the battery in units of 789 milliampere (mA). 791 Typically, this is a value recommended by the manufacturer 792 of the battery or by the manufacturer of the charging 793 circuit. 795 A value of 0 indicates that the recommended trickle charging 796 current is unknown." 797 ::= { batteryEntry 9 } 799 batteryActualCapacity OBJECT-TYPE 800 SYNTAX Unsigned32 801 UNITS "milliampere hours" 802 MAX-ACCESS read-only 803 STATUS current 804 DESCRIPTION 805 "This object provides the actual capacity of the 806 battery in units of milliampere hours (mAh). 808 Typically, the actual capacity of a battery decreases 809 with time and with usage of the battery. It is usually 810 lower than the design capacity 812 Note that the actual capacity needs to be measured and is 813 typically an estimate based on observed discharging and 814 charging cycles of the battery. 816 A value of 'ffffffff'H indicates that the actual capacity 817 cannot be determined." 818 ::= { batteryEntry 10 } 820 batteryChargingCycleCount OBJECT-TYPE 821 SYNTAX Unsigned32 822 MAX-ACCESS read-only 823 STATUS current 824 DESCRIPTION 825 "This object indicates the number of completed charging 826 cycles that the battery underwent. In line with the 827 Smart Battery Data Specification Revision 1.1, a charging 828 cycle is defined as the process of discharging the battery 829 by a total amount equal to the battery design capacity as 830 given by object batteryDesignCapacity. A charging cycle 831 may include several steps of charging and discharging the 832 battery until the discharging amount given by 833 batteryDesignCapacity has been reached. As soon as a 834 charging cycle has been completed the next one starts 835 immediately independent of the battery's current charge at 836 the end of the cycle. 838 For batteries of type primary(3) the value of this object is 839 always 0. 841 A value of 'ffffffff'H indicates that the number of charging 842 cycles cannot be determined." 844 ::= { batteryEntry 11 } 846 batteryLastChargingCycleTime OBJECT-TYPE 847 SYNTAX DateAndTime 848 MAX-ACCESS read-only 849 STATUS current 850 DESCRIPTION 851 "The date and time of the last charging cycle. The value 852 '0000000000000000'H is returned if the battery has not been 853 charged yet or if the last charging time cannot be 854 determined. 856 For batteries of type primary(1) the value of this object is 857 always '0000000000000000'H." 858 ::= { batteryEntry 12 } 860 batteryChargingOperState OBJECT-TYPE 861 SYNTAX INTEGER { 862 unknown(1), 863 charging(2), 864 maintainingCharge(3), 865 noCharging(4), 866 discharging(5) 867 } 868 MAX-ACCESS read-only 869 STATUS current 870 DESCRIPTION 871 "This object indicates the current charging state of the 872 battery. 874 Value unknown(1) indicates that the charging state of the 875 battery cannot be determined. 877 Value charging(2) indicates that the battery is being 878 charged in a way that the charge of the battery increases. 880 Value maintainingCharge(3) indicates that the battery is 881 being charged with a low average current that compensates 882 self-discharging. This includes trickle charging, float 883 charging and other methods for maintaining the current 884 charge of a battery. In typical implementations of charging 885 controllers, state maintainingCharge(3) is only applied 886 if the battery is fully charged or almost fully charged. 888 Value noCharging(4) indicates that the battery is not being 889 charged or discharged by electric current between the 890 battery and electric circuits external to the battery. 891 Note that the battery may still be subject to 892 self-discharging. 894 Value discharging(5) indicates that the battery is either 895 used as the power source for electric circuits external to 896 the battery or being discharged intentionally by the 897 charging controller, e.g., for the purpose of battery 898 maintenace. In any case, the charge of the battery 899 decreases." 900 ::= { batteryEntry 13 } 902 batteryChargingAdminState OBJECT-TYPE 903 SYNTAX INTEGER { 904 notSet(1), 905 charge(2), 906 doNotCharge(3), 907 discharge(4) 908 } 909 MAX-ACCESS read-write 910 STATUS current 911 DESCRIPTION 912 "The value of this object indicates the desired 913 charging state of the battery. The real state is 914 indicated by object batteryChargingOperState. See the 915 definition of object batteryChargingOperState for a 916 description of the values. 918 When this object is initialized by an implementation of the 919 BATTERY-MIB module, its value is set to notSet(1). In this 920 case the charging controller is free to choose which 921 operational state is suitable. 923 When the batteryChargingAdminState object is set, then the 924 BATTERY-MIB implementation must try to set the battery 925 to the indicated state. The result will be indicated by 926 object batteryChargingOperState. 928 Setting object batteryChargingAdminState to value notSet(1) 929 is a request to the charging controller to operate 930 autonomously and choose the operational state that is 931 suitable. 933 Setting object batteryChargingAdminState to value charge(2) 934 is a request to enter the operational state charging(2) until 935 the battery is fully charged. When the battery is fully 936 charged, or if the battery was already fully charged or 937 almost fully charged at the time of the request, the 938 operational state will change to maintainingCharge(3) if the 939 charging controller and the battery support the functionality 940 of maintaining the charge, or will change to noCharging(4) 941 otherwise. 943 Setting object batteryChargingAdminState to value 944 doNotCharge(3) is a request for entering operational 945 state noCharging(4). 947 Setting object batteryChargingAdminState to value 948 discharge(4) is a request for entering operational 949 state discharging(5). Discharging can be accomplished 950 by ordinary use, applying a dedicated load, or any other 951 mean. An example for applying this state is battery 952 maintenance. If the battery is empty or almost empty the 953 operational state will change to noCharging(4). 954 The charging controller will decide which charge condition 955 will be considered empty dependent on the battery 956 technology used. This is done to avoid damage on the 957 battery due to deep discharge. 959 Due to operational conditions and limitations of the 960 implementation of the BATTERY-MIB module, changing the 961 battery status according to a set value of object 962 batteryChargingAdminState may not be possible. 963 Setting the value of object batteryChargingAdminState 964 may result in not changing the state of the battery 965 to this value or even in setting the charging state 966 to another value than the requested one. For example, 967 the charging controller might at any time decide to 968 enter state using(6), if there is an operational need 969 to use the battery for supplying power." 970 ::= { batteryEntry 14 } 972 batteryActualCharge OBJECT-TYPE 973 SYNTAX Unsigned32 974 UNITS "milliampere hours" 975 MAX-ACCESS read-only 976 STATUS current 977 DESCRIPTION 978 "This object provides the actual charge of the battery 979 in units of milliampere hours (mAh). 981 Note that the actual charge needs to be measured and is 982 typically an estimate based on observed discharging and 983 charging cycles of the battery. 985 A value of 'ffffffff'H indicates that the actual charge 986 cannot be determined." 987 ::= { batteryEntry 15 } 989 batteryActualVoltage OBJECT-TYPE 990 SYNTAX Unsigned32 991 UNITS "millivolt" 992 MAX-ACCESS read-only 993 STATUS current 994 DESCRIPTION 995 "This object provides the actual voltage of the battery 996 in units of millivolt (mV). 998 A value of 'ffffffff'H indicates that the actual voltage 999 cannot be determined." 1000 ::= { batteryEntry 16 } 1002 batteryActualCurrent OBJECT-TYPE 1003 SYNTAX Integer32 1004 UNITS "milliampere" 1005 MAX-ACCESS read-only 1006 STATUS current 1007 DESCRIPTION 1008 "This object provides the actual charging or discharging 1009 current of the battery in units of milliampere (mA). 1010 Charging current is represented by positive values, 1011 discharging current is represented by negative values. 1013 A value of '7fffffff'H indicates that the actual current 1014 cannot be determined." 1015 ::= { batteryEntry 17 } 1017 batteryTemperature OBJECT-TYPE 1018 SYNTAX Integer32 1019 UNITS "deci-degrees Celsius" 1020 MAX-ACCESS read-only 1021 STATUS current 1022 DESCRIPTION 1023 "The ambient temperature at or within close proximity 1024 of the battery. 1026 A value of '7fffffff'H indicates that the temperature 1027 cannot be determined." 1028 ::= { batteryEntry 18 } 1030 batteryAlarmLowCharge OBJECT-TYPE 1031 SYNTAX Unsigned32 1032 UNITS "milliampere hours" 1033 MAX-ACCESS read-write 1034 STATUS current 1035 DESCRIPTION 1036 "This object provides the lower threshold value for object 1037 batteryActualCharge. If the value of object 1038 batteryActualCharge falls below this threshold, 1039 a low battery alarm will be raised. The alarm procedure may 1040 include generating a batteryLowNotification. 1042 This object should be set to a value such that when the 1043 batteryLowNotification is generated, the battery is still 1044 sufficiently charged to keep the device(s) that it powers 1045 operational for a time long enough to take actions before 1046 the powered device(s) enter a 'sleep' or 'off' state. 1048 A value of 0 indicates that no alarm will be raised for any 1049 value of object batteryActualCharge." 1050 ::= { batteryEntry 19 } 1052 batteryAlarmLowVoltage OBJECT-TYPE 1053 SYNTAX Unsigned32 1054 UNITS "millivolt" 1055 MAX-ACCESS read-write 1056 STATUS current 1057 DESCRIPTION 1058 "This object provides the lower threshold value for object 1059 batteryActualVoltage. If the value of object 1060 batteryActualVoltage falls below this threshold, 1061 a low battery alarm will be raised. The alarm procedure may 1062 include generating a batteryLowNotification. 1064 This object should be set to a value such that when the 1065 batteryLowNotification is generated, the battery is still 1066 sufficiently charged to keep the device(s) that it powers 1067 operational for a time long enough to take actions before 1068 the powered device(s) enter a 'sleep' or 'off' state. 1070 A value of 0 indicates that no alarm will be raised for any 1071 value of object batteryActualVoltage." 1072 ::= { batteryEntry 20 } 1074 batteryAlarmLowCapacity OBJECT-TYPE 1075 SYNTAX Unsigned32 1076 UNITS "milliampere hours" 1077 MAX-ACCESS read-write 1078 STATUS current 1079 DESCRIPTION 1080 "This object provides the lower threshold value for object 1081 batteryActualCapacity. If the value of object 1082 batteryActualCapacity falls below this threshold, 1083 a battery aging alarm will be raised. The alarm procedure 1084 may include generating a batteryAgingNotification. 1086 A value of 0 indicates that no alarm will be raised for any 1087 value of object batteryActualCapacity." 1088 ::= { batteryEntry 21 } 1090 batteryAlarmHighCycleCount OBJECT-TYPE 1091 SYNTAX Unsigned32 1092 MAX-ACCESS read-write 1093 STATUS current 1094 DESCRIPTION 1095 "This object provides the upper threshold value for object 1096 batteryChargingCycleCount. If the value of object 1097 batteryChargingCycleCount rises above this threshold, 1098 a battery aging alarm will be raised. The alarm procedure 1099 may include generating a batteryAgingNotification. 1101 A value of 0 indicates that no alarm will be raised for any 1102 value of object batteryChargingCycleCount." 1103 ::= { batteryEntry 22 } 1105 batteryAlarmHighTemperature OBJECT-TYPE 1106 SYNTAX Integer32 1107 UNITS "deci-degrees Celsius" 1108 MAX-ACCESS read-write 1109 STATUS current 1110 DESCRIPTION 1111 "This object provides the upper threshold value for object 1112 batteryTemperature. If the value of object 1113 batteryTemperature rises above this threshold, a battery 1114 high temperature alarm will be raised. The alarm procedure 1115 may include generating a batteryTemperatureNotification. 1117 A value of '7fffffff'H indicates that no alarm will be 1118 raised for any value of object batteryTemperature." 1119 ::= { batteryEntry 23 } 1121 batteryAlarmLowTemperature OBJECT-TYPE 1122 SYNTAX Integer32 1123 UNITS "deci-degrees Celsius" 1124 MAX-ACCESS read-write 1125 STATUS current 1126 DESCRIPTION 1127 "This object provides the lower threshold value for object 1128 batteryTemperature. If the value of object 1129 batteryTemperature falls below this threshold, a battery 1130 low temperature alarm will be raised. The alarm procedure 1131 may include generating a batteryTemperatureNotification. 1133 A value of '7fffffff'H indicates that no alarm will be 1134 raised for any value of object batteryTemperature." 1135 ::= { batteryEntry 24 } 1137 batteryCellIdentifier OBJECT-TYPE 1138 SYNTAX SnmpAdminString 1139 MAX-ACCESS read-only 1140 STATUS current 1141 DESCRIPTION 1142 "The value of this object identifies one or more cells of a 1143 battery. The format of the cell identifier may vary between 1144 different implementations. It should uniquely identify one 1145 or more cells of the indexed battery. 1147 This object can be used for batteries, such as, for example, 1148 lithium polymer batteries for which battery controllers 1149 monitor cells individually. 1151 This object is used by notifications of type 1152 batteryLowNotification, batteryTemperatureNotification, 1153 batteryCriticalNotification, and batteryAgingNotification. 1154 These notifications can use the value of this object to 1155 indicate the event that triggered the generation of the 1156 notification in more details by specifying a single cell 1157 or a set of cells within the battery which are specifically 1158 addressed by the notification. 1160 An example use case for this object is a single cell in a 1161 battery that exceeds the temperature indicated by object 1162 batteryAlarmHighTemperature. In such a case, a 1163 batteryTemperatureNotification can be generated that not 1164 just indicates the battery for which the temperature is 1165 exceeded but also the particular cell. 1167 The initial value of this object is the empty string. The 1168 value of this object is set at each time a 1169 batteryLowNotification, a batteryTemperatureNotification, 1170 a batteryCriticalNotification, or a batteryAgingNotification 1171 is generated. 1173 When a notification is generated that does not indicate a 1174 specific cell or set of cells, the value of this object is 1175 set to the empty string." 1176 ::= { batteryEntry 25 } 1178 --================================================================== 1179 -- 2. Notifications 1180 --================================================================== 1182 batteryChargingStateNotification NOTIFICATION-TYPE 1183 OBJECTS { 1184 batteryChargingOperState 1185 } 1186 STATUS current 1187 DESCRIPTION 1188 "This notification can be generated when a charging state 1189 of the battery (indicated by the value of object 1190 batteryChargingOperState) is triggered by an event other 1191 than a write action to object batteryChargingAdminState. 1192 Such an event may, for example, be triggered by a local 1193 battery controller." 1194 ::= { batteryNotifications 1 } 1196 batteryLowNotification NOTIFICATION-TYPE 1197 OBJECTS { 1198 batteryActualCharge, 1199 batteryActualVoltage, 1200 batteryCellIdentifier 1201 } 1202 STATUS current 1203 DESCRIPTION 1204 "This notification can be generated when the current charge 1205 (batteryActualCharge) or the current voltage 1206 (batteryActualVoltage) of the battery falls below a 1207 threshold defined by object batteryAlarmLowCharge or object 1208 batteryAlarmLowVoltage, respectively. 1210 Note that typically, this notification is generated in a 1211 state where the battery is still sufficiently charged to keep 1212 the device(s) that it powers operational for some time. 1213 If the charging state of the battery has become critical, 1214 i.e., the device(s) powered by the battery must go to a 1215 'sleep' or 'off' state, then the batteryCriticalNotification 1216 should be used instead. 1218 If the low charge or voltage has been detected for a single 1219 cell or a set of cells of the battery and not for the entire 1220 battery, then object batteryCellIdentifier should be set to 1221 a value that identifies the cell or set of cells. 1222 Otherwise, the value of object batteryCellIdentifier should 1223 be set to the empty string when this notification is 1224 generated. 1226 The notification should not be sent again for the same 1227 battery or cell before either (a) the current voltage or 1228 the current charge, respectively, has become higher than the 1229 corresponding threshold through charging or (b) an indication 1230 of a maintenance action has been detected, such as battery 1231 disconnection event, or a reinitialization of the battery 1232 monitoring system. 1234 This notification should not be sent when the battery is in 1235 a charging mode, i.e., the value of object 1236 batteryChargingOperState is charging(2) or fastCharging(3)." 1237 ::= { batteryNotifications 2 } 1239 batteryCriticalNotification NOTIFICATION-TYPE 1240 OBJECTS { 1241 batteryActualCharge, 1242 batteryActualVoltage, 1243 batteryCellIdentifier 1244 } 1245 STATUS current 1246 DESCRIPTION 1247 "This notification can be generated when the current charge 1248 of the battery falls so low that it cannot provide a 1249 sufficient power supply function for regular operation 1250 of the powered device(s). The battery needs to be charged 1251 before it can be used for regular power supply again. The 1252 battery may still provide sufficient power for a 'sleep' 1253 mode of powered device(s) or for a transition into an 'off' 1254 mode. 1256 If the critical state is caused a single cell or a set of 1257 cells of the battery, then object batteryCellIdentifier 1258 should be set to a value that identifies the cell or set of 1259 cells. Otherwise, the value of object batteryCellIdentifier 1260 should be set to the empty string when this notification is 1261 generated. 1263 The notification should not be sent again for the same 1264 battery before either the battery charge has increased 1265 through charging to a non-critical value or an indication 1266 of a maintenance action has been detected, such a battery 1267 disconnection event, or a reinitialization of the battery 1268 monitoring system. 1270 This notification should not be sent when the battery is in 1271 a charging mode, i.e., the value of object 1272 batteryChargingOperState is charging(2) or fastCharging(3)." 1273 ::= { batteryNotifications 3 } 1275 batteryTemperatureNotification NOTIFICATION-TYPE 1276 OBJECTS { 1277 batteryTemperature, 1278 batteryCellIdentifier 1279 } 1280 STATUS current 1281 DESCRIPTION 1282 "This notification can be generated when the measured 1283 temperature (batteryTemperature) rises above the threshold 1284 defined by object batteryAlarmHighTemperature or falls 1285 below the threshold defined by object 1286 batteryAlarmLowTemperature. 1288 If the low or high temperature has been detected for a 1289 single cell or a set of cells of the battery and not for the 1290 entire battery, then object batteryCellIdentifier should be 1291 set to a value that identifies the cell or set of cells. 1292 Otherwise, the value of object batteryCellIdentifier should 1293 be set to the empty string when this notification is 1294 generated. 1296 It may occur that the temperature alternates between values 1297 slightly below and slightly above a threshold. For limiting 1298 the notification rate in such a case, this notification 1299 should not be sent again for the same battery or cell, 1300 respectively, with in a time interval of 10 minutes. 1302 An exception to the rate limitations occurs immediately 1303 after the reinitialization of the battery monitoring system. 1304 If at this point in time the battery temperature is above 1305 the threshold defined by object batteryAlarmHighTemperature 1306 or below the threshold defined by object 1307 batteryAlarmLowTemperature, respectively, then this 1308 notification should be sent, independent of the time at 1309 which previous notifications for the same battery or cell, 1310 respectively, had been sent." 1311 ::= { batteryNotifications 4 } 1313 batteryAgingNotification NOTIFICATION-TYPE 1314 OBJECTS { 1315 batteryActualCapacity, 1316 batteryChargingCycleCount, 1317 batteryCellIdentifier 1318 } 1319 STATUS current 1320 DESCRIPTION 1321 "This notification can be generated when the actual 1322 capacity (batteryActualCapacity) falls below a threshold 1323 defined by object batteryAlarmLowCapacity 1324 or when the charging cycle count of the battery 1325 (batteryChargingCycleCount) exceeds the threshold defined 1326 by object batteryAlarmHighCycleCount. 1328 If the aging has been detected for a single cell or a set of 1329 cells of the battery and not for the entire battery, then 1330 object batteryCellIdentifier should be set to a value that 1331 identifies the cell or set of cells. Otherwise, the value 1332 of object batteryCellIdentifier should be set to the empty 1333 string when this notification is generated. 1335 This notification should not be sent again for the same 1336 battery or cell, respectively, before an indication of a 1337 maintenance action has been detected, such as a battery 1338 disconnection event, or a reinitialization of the battery 1339 monitoring system." 1340 ::= { batteryNotifications 5 } 1342 batteryConnectedNotification NOTIFICATION-TYPE 1343 OBJECTS { 1344 batteryIdentifier 1345 } 1346 STATUS current 1347 DESCRIPTION 1348 "This notification can be generated when it has been 1349 detected that a battery has been connected. The battery 1350 can be identified by the value of object batteryIdentifier 1351 as well as by the value of index entPhysicalIndex that is 1352 contained in the OID of object batteryIdentifier." 1353 ::= { batteryNotifications 6 } 1355 batteryDisconnectedNotification NOTIFICATION-TYPE 1356 STATUS current 1357 DESCRIPTION 1358 "This notification can be generated when it has been 1359 detected that one or more batteries have been disconnected." 1360 ::= { batteryNotifications 7 } 1362 --================================================================== 1363 -- 3. Conformance Information 1364 --================================================================== 1366 batteryCompliances OBJECT IDENTIFIER ::= { batteryConformance 1 } 1367 batteryGroups OBJECT IDENTIFIER ::= { batteryConformance 2 } 1369 -------------------------------------------------------------------- 1370 -- 3.1. Compliance Statements 1371 -------------------------------------------------------------------- 1373 batteryCompliance MODULE-COMPLIANCE 1374 STATUS current 1375 DESCRIPTION 1376 "The compliance statement for implementations of the 1377 BATTERY-MIB module. 1379 A compliant implementation MUST implement the objects 1380 defined in the mandatory groups batteryDescriptionGroup 1381 and batteryStatusGroup. 1383 Note that compliance with this compliance 1384 statement requires compliance with the 1385 entity4CRCompliance MODULE-COMPLIANCE statement of the 1386 ENTITY-MIB (RFC6933)." 1387 MODULE -- this module 1388 MANDATORY-GROUPS { 1389 batteryDescriptionGroup, 1390 batteryStatusGroup 1391 } 1393 GROUP batteryAlarmThresholdsGroup 1394 DESCRIPTION 1395 "A compliant implementation does not have to implement 1396 the batteryAlarmThresholdsGroup." 1398 GROUP batteryNotificationsGroup 1399 DESCRIPTION 1400 "A compliant implementation does not have to implement 1401 the batteryNotificationsGroup." 1403 GROUP batteryPerCellNotificationsGroup 1404 DESCRIPTION 1405 "A compliant implementation does not have to implement 1406 the batteryPerCellNotificationsGroup." 1408 GROUP batteryAdminGroup 1409 DESCRIPTION 1410 "A compliant implementation does not have to implement 1411 the batteryAdminGroup." 1413 OBJECT batteryAlarmLowCharge 1414 MIN-ACCESS read-only 1415 DESCRIPTION 1416 "A compliant implementation is not required 1417 to support set operations to this object." 1419 OBJECT batteryAlarmLowVoltage 1420 MIN-ACCESS read-only 1421 DESCRIPTION 1422 "A compliant implementation is not required 1423 to support set operations to this object." 1425 OBJECT batteryAlarmLowCapacity 1426 MIN-ACCESS read-only 1427 DESCRIPTION 1428 "A compliant implementation is not required 1429 to support set operations to this object." 1431 OBJECT batteryAlarmHighCycleCount 1432 MIN-ACCESS read-only 1433 DESCRIPTION 1434 "A compliant implementation is not required 1435 to support set operations to this object." 1437 OBJECT batteryAlarmHighTemperature 1438 MIN-ACCESS read-only 1439 DESCRIPTION 1440 "A compliant implementation is not required 1441 to support set operations to this object." 1443 OBJECT batteryAlarmLowTemperature 1444 MIN-ACCESS read-only 1445 DESCRIPTION 1446 "A compliant implementation is not required 1447 to support set operations to this object." 1449 ::= { batteryCompliances 1 } 1451 -------------------------------------------------------------------- 1452 -- 3.2. MIB Grouping 1453 -------------------------------------------------------------------- 1455 batteryDescriptionGroup OBJECT-GROUP 1456 OBJECTS { 1457 batteryIdentifier, 1458 batteryFirmwareVersion, 1459 batteryType, 1460 batteryTechnology, 1461 batteryDesignVoltage, 1462 batteryNumberOfCells, 1463 batteryDesignCapacity, 1464 batteryMaxChargingCurrent, 1465 batteryTrickleChargingCurrent 1466 } 1467 STATUS current 1468 DESCRIPTION 1469 "A compliant implementation MUST implement the objects 1470 contained in this group." 1471 ::= { batteryGroups 1 } 1473 batteryStatusGroup OBJECT-GROUP 1474 OBJECTS { 1475 batteryActualCapacity, 1476 batteryChargingCycleCount, 1477 batteryLastChargingCycleTime, 1478 batteryChargingOperState, 1479 batteryActualCharge, 1480 batteryActualVoltage, 1481 batteryActualCurrent, 1482 batteryTemperature 1483 } 1484 STATUS current 1485 DESCRIPTION 1486 "A compliant implementation MUST implement the objects 1487 contained in this group." 1488 ::= { batteryGroups 2 } 1490 batteryAdminGroup OBJECT-GROUP 1491 OBJECTS { 1492 batteryChargingAdminState 1493 } 1494 STATUS current 1495 DESCRIPTION 1496 "A compliant implementation does not have to implement the 1497 object contained in this group." 1498 ::= { batteryGroups 3 } 1500 batteryAlarmThresholdsGroup OBJECT-GROUP 1501 OBJECTS { 1502 batteryAlarmLowCharge, 1503 batteryAlarmLowVoltage, 1504 batteryAlarmLowCapacity, 1505 batteryAlarmHighCycleCount, 1506 batteryAlarmHighTemperature, 1507 batteryAlarmLowTemperature 1508 } 1509 STATUS current 1510 DESCRIPTION 1511 "A compliant implementation does not have to implement the 1512 objects contained in this group." 1513 ::= { batteryGroups 4 } 1515 batteryNotificationsGroup NOTIFICATION-GROUP 1516 NOTIFICATIONS { 1517 batteryChargingStateNotification, 1518 batteryLowNotification, 1519 batteryCriticalNotification, 1520 batteryAgingNotification, 1521 batteryTemperatureNotification, 1522 batteryConnectedNotification, 1523 batteryDisconnectedNotification 1524 } 1525 STATUS current 1526 DESCRIPTION 1527 "A compliant implementation does not have to implement the 1528 notifications contained in this group." 1529 ::= { batteryGroups 5 } 1531 batteryPerCellNotificationsGroup OBJECT-GROUP 1532 OBJECTS { 1533 batteryCellIdentifier 1534 } 1535 STATUS current 1536 DESCRIPTION 1537 "A compliant implementation does not have to implement the 1538 object contained in this group." 1539 ::= { batteryGroups 6 } 1540 END 1542 5. Security Considerations 1544 There are a number of management objects defined in this MIB module 1545 with a MAX-ACCESS clause of read-write. Such objects may be 1546 considered sensitive or vulnerable in some network environments. The 1547 support for SET operations in a non-secure environment without proper 1548 protection opens devices to attack. These are the tables and objects 1549 and their sensitivity/vulnerability: 1551 o batteryChargingAdminState 1552 Setting the battery charging state can be beneficial for an 1553 operator for various reasons such as charging batteries when the 1554 price of electricity is low. However, setting the charging state 1555 can be used by an attacker to discharge batteries of devices and 1556 thereby switching these devices off if they are powered solely by 1557 batteries. In particular, if the batteryAlarmLowCharge and 1558 batteryAlarmLowVoltage can also be set, this attack will go 1559 unnoticed (i.e. no notifications are sent). 1561 o batteryAlarmLowCharge and batteryAlarmLowVoltage 1562 These objects set the threshold for an alarm to be raised when the 1563 battery charge or voltage falls below the corresponding one of 1564 them. An attacker setting one of these alarm values can switch 1565 off the alarm by setting it to the 'off' value 0 or modify the 1566 alarm behavior by setting it to any other value. The result may 1567 be loss of data if the battery runs empty without warning to a 1568 recipient expecting such a notification. 1570 o batteryAlarmLowCapacity and batteryAlarmHighCycleCount 1571 These objects set the threshold for an alarm to be raised when the 1572 battery becomes older and less performant than required for stable 1573 operation. An attacker setting this alarm value can switch off 1574 the alarm by setting it to the 'off' value 0 or modify the alarm 1575 behavior by setting it to any other value. This may either lead 1576 to a costly replacement of a working battery or too old or too 1577 weak batteries being used. The consequence of the latter could 1578 e.g. be that a battery cannot provide power long enough between 1579 two scheduled charging actions causing the powered device to shut 1580 down and potentially lose data. 1582 o batteryAlarmHighTemperature and batteryAlarmLowTemperature 1583 These objects set thresholds for an alarm to be raised when the 1584 battery rises above/falls below them. An attacker setting one of 1585 these alarm values can switch off these alarms by setting them to 1586 the 'off' value '7fffffff'H or modify the alarm behavior by 1587 setting them to any other value. The result may e.g. be an 1588 unnecessary shutdown of a device if batteryAlarmHighTemperature is 1589 set to too low or damage to the device by too high temperatures if 1590 switched off or set to too high values or by damage to the battery 1591 when it e.g. is being charged. Batteries can also be damaged e.g. 1592 in an attempt to charge them at too low temperatures. 1594 Some of the readable objects in this MIB module (i.e., objects with a 1595 MAX-ACCESS other than not-accessible) may be considered sensitive or 1596 vulnerable in some network environments. It is thus important to 1597 control even GET and/or NOTIFY access to these objects and possibly 1598 to even encrypt the values of these objects when sending them over 1599 the network via SNMP. These are the tables and objects and their 1600 sensitivity/vulnerability: 1602 All potentially sensible or vulnerable objects of this MIB module are 1603 in the batteryTable. In general, there are no serious operational 1604 vulnerabilities foreseen in case of an unauthorized read access to 1605 this table. However, corporate confidentiality issues need to be 1606 considered. It may be a trade secret of the operator 1608 o how many batteries are installed in a managed node (batteryIndex) 1609 o how old these batteries are (batteryActualCapacity and 1610 batteryChargingCycleCount) 1612 o when the next replacement cycle for batteries can be expected 1613 (batteryAlarmLowCapacity and batteryAlarmHighCycleCount) 1615 o what battery type and make are used with which firmware version 1616 (batteryIdentifier, batteryFirmwareVersion, batteryType, and 1617 batteryTechnology) 1619 For any battery-powered device whose use can be correlated to an 1620 individual or a small group of individuals, the following objects 1621 have the potential to reveal information about those individuals' 1622 activities or habits (e.g., if they are near a power outlet, if they 1623 have been using their devices heavily, etc.): 1625 o batteryChargingCycleCount 1627 o batteryLastChargingCycleTime 1629 o batteryChargingOperState 1631 o batteryActualCharge 1633 o batteryActualVoltage 1635 o batteryActualCurrent 1637 o batteryTemperature 1639 o batteryAlarmLowCharge 1641 o batteryAlarmLowVoltage 1643 o batteryAlarmLowCapacity 1645 o batteryAlarmHighCycleCount 1647 o batteryAlarmHighTemperature 1649 o batteryAlarmLowTemperature 1651 Implementers of this specification should use appropriate privacy 1652 protections as discussed in Section 9 of the Requirements for Energy 1653 Management [RFC6988]. Battery monitoring of devices used by 1654 individuals or in homes should only occur with proper authorization. 1656 SNMP versions prior to SNMPv3 did not include adequate security. 1657 Even if the network itself is secure (for example by using IPsec), 1658 there is no control as to who on the secure network is allowed to 1659 access and GET/SET (read/change/create/delete) the objects in this 1660 MIB module. 1662 Implementations SHOULD provide the security features described by the 1663 SNMPv3 framework (see [RFC3410]), and implementations claiming 1664 compliance to the SNMPv3 standard MUST include full support for 1665 authentication and privacy via the User-based Security Model (USM) 1666 [RFC3414] with the AES cipher algorithm [RFC3826]]. Implementations 1667 MAY also provide support for the Transport Security Model (TSM) 1668 [RFC5591] in combination with a secure transport such as SSH 1669 [RFC5592] or TLS/DTLS [RFC6353]. 1671 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1672 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1673 enable cryptographic security. It is then a customer/operator 1674 responsibility to ensure that the SNMP entity giving access to an 1675 instance of this MIB module is properly configured to give access to 1676 the objects only to those principals (users) that have legitimate 1677 rights to indeed GET or SET (change/create/delete) them. 1679 6. IANA Considerations 1681 6.1. SMI Object Identifier Registration 1683 The Battery MIB module defined in this document uses the following 1684 IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers 1685 registry: 1687 Descriptor OBJECT IDENTIFIER value 1688 ---------- ----------------------- 1689 batteryMIB { mib-2 xxx } 1691 [NOTE for IANA: Please allocate an object identifier at 1692 http://www.iana.org/assignments/smi-numbers for object batteryMIB.] 1694 6.2. Battery Technology Registration 1696 Object batteryTechnology defined in Section 4 reports battery 1697 technologies. Eighteen values for battery technologies have 1698 initially been defined. They are listed in a table in Section 3.2. 1700 For ensuring extensibility of this list, IANA has created a registry 1701 for battery technologies at http://www.iana.org/assignments/battery- 1702 technologies and filled it with the initial list given in 1703 Section 3.2. 1705 New assignments of numbers for battery technologies will be 1706 administered by IANA through Expert Review ([RFC5226]). Experts must 1707 check for sufficient relevance of a battery technology to be added 1708 according to the guidelines in section Section 3.2.1. 1710 [NOTE for IANA: Please create a new registry under 1711 http://www.iana.org/assignments/battery-technologies for battery 1712 types. Please fill the registry with values from the table in 1713 Section 3.2] 1715 7. Acknowledgements 1717 We would like to thank Steven Chew, Bill Mielke, and Alan Luchuk for 1718 their valuable input. 1720 8. References 1722 8.1. Normative References 1724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1725 Requirement Levels", BCP 14, RFC 2119, March 1997. 1727 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1728 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1729 May 2008. 1731 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1732 Schoenwaelder, Ed., "Structure of Management Information 1733 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1735 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1736 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 1737 58, RFC 2579, April 1999. 1739 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1740 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1741 April 1999. 1743 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1744 Architecture for Describing Simple Network Management 1745 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1746 December 2002. 1748 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1749 (USM) for version 3 of the Simple Network Management 1750 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1752 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 1753 Advanced Encryption Standard (AES) Cipher Algorithm in the 1754 SNMP User-based Security Model", RFC 3826, June 2004. 1756 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model 1757 for the Simple Network Management Protocol (SNMP)", STD 1758 78, RFC 5591, June 2009. 1760 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 1761 Shell Transport Model for the Simple Network Management 1762 Protocol (SNMP)", RFC 5592, June 2009. 1764 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 1765 Model for the Simple Network Management Protocol (SNMP)", 1766 STD 78, RFC 6353, July 2011. 1768 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1769 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 1770 2013. 1772 8.2. Informative References 1774 [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and 1775 B. Claise, "Requirements for Energy Management", RFC 6988, 1776 September 2013. 1778 [RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek, 1779 "Energy Management Framework", RFC 7326, September 2014. 1781 [RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J., 1782 and T. Dietz, "Monitoring and Control MIB for Power and 1783 Energy", RFC 7460, March 2015. 1785 [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, May 1786 1994. 1788 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1789 "Introduction and Applicability Statements for Internet- 1790 Standard Management Framework", RFC 3410, December 2002. 1792 [SBS] "Smart Battery Data Specification", Revision 1.1, December 1793 1998. 1795 Authors' Addresses 1796 Juergen Quittek 1797 NEC Europe Ltd. 1798 NEC Laboratories Europe 1799 Network Research Division 1800 Kurfuersten-Anlage 36 1801 Heidelberg 69115 1802 DE 1804 Phone: +49 6221 4342-115 1805 Email: quittek@neclab.eu 1807 Rolf Winter 1808 NEC Europe Ltd. 1809 NEC Laboratories Europe 1810 Network Research Division 1811 Kurfuersten-Anlage 36 1812 Heidelberg 69115 1813 DE 1815 Phone: +49 6221 4342-121 1816 Email: Rolf.Winter@neclab.eu 1818 Thomas Dietz 1819 NEC Europe Ltd. 1820 NEC Laboratories Europe 1821 Network Research Division 1822 Kurfuersten-Anlage 36 1823 Heidelberg 69115 1824 DE 1826 Phone: +49 6221 4342-128 1827 Email: Thomas.Dietz@neclab.eu