Understanding VoIP power consumption

This best practices guide from the Tolly Group defines and evaluates quantitative and qualitative characteristics of VoIP power consumption. It covers basic power consumption measurement tests, as well as total cost of ownership with respect to power and provides resources and sample calculations.

Table of contents:

• VoIP system power — level set
  • Power consumption
  • LAN/WAN communication infrastructure
  • LAN switch power consumption
  • Environmental life cycle
  • Upcoming challenges
  • Challenges to benchmarking VoIP system power consumption
  • Power measurement
  • VoIP system scope and components
  • Competitive equivalents
• Benchmarking VoIP system power consumption
  • Universal topics
  • Test challenges
  • Safety
  • Power source
  • System configuration
  • Published vs. actual power: Calibration factor
  • Test metrics & definitions
  • System states
  • Steady-state power draw
  • Impact of power supply
  • System measurements: Watts
  • Power factor
  • VoIP system power consumption
  • Premise
  • Test overview
  • Test coverage
  • Component summary: Bill of materials
  • Measurement and documentation
  • VoIP phone: Measurement and documentation
  • System components: Measurement and documentation
  • Interpretation of results
  • Test tools
  • Test setup
• Evaluating total cost of ownership
  • Users per server
  • High-availability (HA) configurations
  • Electricity rates
  • Power up — Cool down
  • Dissipation location
  • Life cycle and environmental impact
  • Power over ethernet
  • Sample cost calculations

VoIP System Power – Level Set

In a very short span of time, interest has surged (ahem) in measuring the power consumption of many IT infrastructure devices. Voice over IP systems, a part of every work environment infrastructure, are thus an area of particular interest.

VoIP Systems are typically “always on” devices so differences in power consumption across various vendor solutions are magnified as the devices run 24×7, year-round. The specific attributes of the telephony components deployed will impact power consumption. The presence or absence of specific model phones (having different displays) will impact consumption. Notably, the presence or absence of options such as audio response, emergency services and/or high-availability configurations will also have a significant impact on overall power consumption.

LAN/WAN COMMUNICATION INFRASTRUCTURE

Virtually all components of the VoIP system, wired and wireless will connect to a switched LAN infrastructure as their basic communication pathway. Thus, the power consumption of the underlying switched infrastructure will certainly impact over system consumption.

Most wired VoIP handsets are powered using the Power over Ethernet (PoE) that is provided by the LAN switch. While outside the direct scope of this document, it is important to note that the capabilities of the switch with respect to power delivery will have an impact on overall consumption.

ENVIRONMENTAL LIFE CYCLE

While it is not possible, for example, to “test” how a product is recycled, it is possible to outline environmental considerations which can then, at a minimum, be explored in discussions with prospective vendors. This report will eventually include such areas.

While measurement of power consumed is an important factor both with respect to cost and environmental impact, there are other attributes of a product, its manufacture and end-of-life plan that might weigh on your decision. Some companies will now provide recycling for their products when the products are taken out of service.

Upcoming challenges

As vendors focus on controlling power consumption, one would expect to see new products implementing a finer level of control of power. Switches will certainly offer options that can allow more granular control over power. Display systems on telephone handsets will provide more control over brightness and previously “always” on VoIP handsets will likely be able to be shut down dynamically to conserve power during likely long periods (nights, weekends and holidays) where the phone handset may go hours or even days without being used.

Handsets will likely take advantage of the Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) to be able to communicate over Ethernet to the switch ports that are providing power to manage power more precisely and automatically.

In the (relatively) near term, physical layer advancements will allow switches to adjust their output power levels based on the length of the cable rather than, by default, being configured to drive each port at maximum cable length. Thus, variables like cable length that were irrelevant (so long as the lengths were “legal”) when benchmarking switch performance will at some point become critical variables.

CHALLENGES TO BENCHMARKING VOIP SYSTEM POWER CONSUMPTION

Power measurement

The biggest challenge is that benchmarking power consumption in general is an entirely new endeavor to both equipment vendors and users alike. Where many benchmarking practices evolved over many years, power consumption tests, to date, have been ad hoc affairs. (This Common RFP is an attempt to remedy this situation.)

Tests to date have been similar but not identical and results might not be comparable. This is a significant challenge. The tester will likely encounter new terminology with which to become familiar. The industry encountered this situation when networking specialists began to become involved with voice technology. Now, users will need to understand new terms and acronyms related to power delivery.

Having a way to measure the various attributes of power consumption is, of course, a mandatory element of benchmarking. Fortunately, there is a wide range of measurement devices available.

In alphabetical order, the following is a list of power consumption test tools that have been used in Tolly Group projects:

• Chroma ATE – Chroma 66200 Series – http://www.chromaate.com/product/detail.aspx?gid=613&id=1593
• Extech Instruments – Extech 380801 Power Analyzer – http://www.extech.com/instruments/product.asp?catid=14&prodid=205
• Fluke 80 Series Digital Multimeter – http://us.fluke.com/usen/products/Fluke80SeriesV.htm
• P3 International – Kill A Watt – http://www.p3international.com/products/special/P4400/P4400-CE.html
• WattsUp – https://www.wattsupmeters.com/secure/products.php?pn=0&wai=278&more=4

While they all focus on measuring power consumption, they are far from identical with respect to functionality and, naturally, price. Some can be had for under $100 where others cost many thousands of dollars.

In our experience to date, all of the above solutions deliver measurements that are within 1 to 2% of each other. Given the number of variables involved in measuring and calculating power consumption it is likely that any variance in measurements as noted above will have relatively little impact on your final results. If your requirements need to absolutely precise, than you are well advised to spend time testing different measurement tools.

As a vendor-neutral organization, we will attempt to keep these tests test tool-neutral. That said, there will be cases where only specific test tools are able to either carry out a given test or provide control over particular variables. Thus, when required mention will be made of specific test tools.

In many cases, Tolly has observed that a major differentiator between less expensive and more expensive devices has been that the less expensive devices often provide a single “real time” reading where more expensive devices can store readings and provide a running average as well as provide automatic calculations of related values that must be done manually when using less expensive devices.

VoIP system scope and components

Once you have assured accurate measurements, the rest of your test will hinge on the configuration that you choose to measure. At the macro level, one needs to understand the general characteristics of the environment to be modeled and benchmarked. In general terms, this can be referred to as, say, HQ, regional office, or branch office. Unfortunately, there are no generally accepted definitions of what each of these sites should consist of.

While it is typically safe to assume that all sites will be provided with unified messaging (i.e. voice mail), other functions like E911 or high-availability deployments may not be a part of the configuration for a small branch office.

Certainly if any of these locations is used as a call center, there can be additional components that would need to be added to the configuration to support such services.

The type and number of handsets that are chosen for a given configuration will also impact your benchmarking results. More sophisticated handsets not only cost more but are typically outfitted with color displays that will consume more power. While an individual phone display might not consume much more power than a phone without a display, any difference can be magnified greatly when the phones number in the hundreds or the thousands and one considers the ongoing cost of power.

Competitive equivalents

Most challenging is building realistic and accurate models of competing vendors’ solutions. While it is not difficult to measure the solution, it is difficult to validate the appropriateness of any solution that is not designed by the equipment vendor itself.

Many such competing RFP responses likely exist as private documents shared only between large customers and bidding vendors. There is certainly a shortage of public documents that can serve as vendor-recommended configurations for use in tests that are “public” as opposed to being conducted for a specific user bid.

Fortunately, TEQConsult Group developed an RFP for a “large”, 1,500 user environment in the fall of 2007 in conjunction with the VoiceCon® Orlando 2008 conference.

This RFP specified user requirements for a headquarters location, one regional office and one satellite (branch) office. Multiple vendors responded to this RFP. As of this writing, the RFP is still available for free download at the VoiceCon website at: http://www.voicecon.com/orlando/about/real_world_rfp.php

Because it includes official responses from each of the vendors, it can be assumed to be the recommended solution for each. Please be aware, however, that as the RFP responses were compiled in late 2007-early 2008, a given vendor may have since introduced new equipment that might change their recommended configurations.

Also keep in mind that in this particular RFP most vendors assumed that 20% of the phones deployed would be traditional analog phones and thus submitted VoIP responses numbering only approximately 800 users

Benchmarking VoIP System Power Consumption: Quantitative tests of Voice over IP system solutions

UNIVERSAL TOPICS

These topics are applicable to more than one particular test and thus are grouped together for ease of reference. As these are sub-topics of the more specific tests, it is likely more useful to review them in conjunction with a specific test so as to understand the proper context.

Test challenges

Safety

Coming in contact with AC power can kill you. The various test tools and test procedures described herein require that you interface with the AC power source. Please follow all safety instructions provided with the devices under test as well as the safety instructions included with the test tools – and use common sense.

Power source

While a Gigabit ports is universal, the energy source that powers it is not. All tests will need to be conducted with specific power sources which are then referenced in the results.

The sources are likely relevant to a particular user based on geography and/or installation type. 120 V AC is the standard in North America, where 220 V AC is the standard power in many other parts of the world.

Additionally, devices that are built to run in data centers may be use NEMA L6-30 circuits which are 208 volts and 30 amperes. Traditional “plain old telephone service” (POTS) systems were typically powered by -48 V DC and can be found today in carrierclass and industrial Ethernet products.

System configuration

As noted elsewhere in this document, the system elements and detailed configuration will have a significant impact on results. It is necessary to be as specific as possible about all of the elements tested. Not only do specific model numbers need to be noted for handsets and system modules but where services run on “standard servers” it is important to note the key physical aspects of those servers (e.g., type and number of CPU cores) and, naturally, to measure those systems running the required software services.

While all VoIP systems will connect to a LAN switch infrastructure- wired phones and wired server components – that switch infrastructure may or may not be included in any particular benchmarking project.

While it is NOT common to find VoIP server functionality bundled into a LAN switch it IS common to find vendor organizations that can sell both to a customer under its own brand (e.g., Cisco, Nortel, Alcatel-Lucent). Such vendors would likely include the underlying LAN infrastructure especially if they have designed elements of that LAN switch, particularly Power over Ethernet, that interacts with the VoIP system and further optimizes the system.

Vendors that sell only VoIP solutions and thus are likely to be vendor neutral when it comes to LAN infrastructure, will typically NOT include the LAN infrastructure in the energy consumption measurements and subsequent calculations.

With remote office implementations, some vendors vendors integrate telephony functions into routers that are used to establish data connectivity with the outside world via WAN ports and sometimes contain integrated LAN switches that can be used to support VoIP phones or ordinary LAN connected workstations and/or servers. In such cases, it is often not possible to measure the power of only the telephony-related components.

Published vs actual power: Calibration factor

Virtually every system component data sheet will specify a figure for power consumption. To date, it has been our experience that these numbers represent values that are maximum values (whether or not that is stated) and, in an case, tend to be significantly higher than the power draw measured under normal operation. In many cases, Tolly has found “actual” power consumption to be only 25% to 30% of the figure found in product data sheets.

Given this difference, it is critical that actual power draw be used in the consumption and cost calculations. For system components that are unavailable for actual testing, it is recommended that some method be found for estimating a likely power draw. This can be done by testing a component similar to the “unavailable” component, determine its actual usage and calculate the relationship between that number and the power consumption figures on the product data sheet. Then, take that percentage and apply it to the stated power draw of the “unavailable” component. While one cannot be certain that this is accurate, experience shows that this is likely to give a more accurate assessment of the actual power than merely using the published power draw in consumption and cost calculations.

To be sure, the desired approach is to make actual measurements of every component but so long as good judgment is used in applying the calibration factor approach, results should be valid.

Test metrics & definitions

System states

The state or condition of the system is important to understand when evaluating power consumption. “Back End” components like call servers are assumed to be “always on”. Telephone handsets, however, are typically measured both when idle and when off-hook (i.e., someone is using the phone). Thus, it is important to note the state of the handset. Except with specialized applications like call centers, the “steady state” for most handsets is on hook. Certainly a handset dedicated to a single knowledge worker is likely to be on hook for those hours of each work day and weekend that the worker is not present in the office. Given that this “down time” represents roughly 75% of the hours in a week and that it is not likely that a user is one the phone constantly while in the office, it is reasonable to use the “idle” measurements in calculations. (According to VoIP system vendor Mitel in typical business environments a phone is idle as much as 96% of the time.) Experience to date has shown the power consumption of basic phones “off hook” to be about 10-15% more than the idle state.

Steady-state power draw

When we use this term in the context of performance testing, we mean for the system to be running in a state that it can maintain indefinitely. From a power consumption standpoint, this is not as clear cut.

With telephony systems, the primary variable for power consumption is related to whether a handset is being used in conversation or is “on hook”, idle and ready to receive or make calls. Furthermore, one needs to determine whether steady-state power draw is based on a device with active but idle ports or a device processing traffic.

Regardless of the definition used, it is important to note that energy cost calculations based solely on steady-state power draw will not likely be accurate as, over the course of time, the switch will not remain in a single state with respect to traffic load and other aspects of operation that can influence power consumption. Please see the section further below on cost calculation for additional information.

Impact of power supply

Testers note that for systems that provide multiple power supply options: power supplies typically operate at their most efficient state when the load on them is between 50% – and 90%. Therefore, power supply selection is important. For modular systems that are lightly loaded, selecting the highest power capacity supply for the system will result in inefficient operation of the power supply and higher power consumption than utilizing a lower capacity power supply operating closer to the mid range of its capabilities.

System measurements

A single test often provides multiple measurements – effectively different ways of looking at the same data.

Watts

When one measures power consumption, that measurement is made in watts. As the definition includes a unit of time (“… one joule of energy per second” see Wikipedia: https://en.wikipedia.org/wiki/Watt), the energy consumption is expressed simply as Watts. Network specialists are used to understanding performance “per second” but need to remember that to discuss “Watts per second” is fundamentally incorrect.

Power factor

Perhaps as important as the absolute measure of power consumed is quantifying the efficiency with which the power is being used by the DUT. Power factor is just that measurement. According to wikipedia it is “the ratio of the real power flowing to the load to the apparent power.”

Inefficient use of power means that the device consumes more energy than it is actually able to use and thus long-term power consumption costs are higher than they need to be.

Power factor (pf) is a number between zero and one – with “one” representing maximum or %100 efficiency. Test tools such as the “Watts Up” will calculate this value automatically.

This measurement occurs only when dealing with AC power source, and can be disregarded for DC systems.

The apparent power consumed by a system is the product of the RMS values of the voltage and current across the device, assuming the waveforms are in phase. This value is used by power suppliers to assess the total energy used. The problem is that, more often than not, the voltage and current waveforms will not be in phase due to the complex series of networks within the device. .

For additional details, please see the entry for Power Factor in wikipedia at: https://en.wikipedia.org/wiki/Power_factor.

Premise

As part of the corporate communication infrastructure, telephony systems are typically “always on” systems. Running 7×24 can make the power consumption of these devices a significant element of recurring cost in any total cost of ownership calculation.

Measuring the power consumption of VoIP systems is an essential element of making TCO calculations.

The test actually consists of multiple separate tests to measure key components. Results are then determined by calculating the individual components scaled up to the desired user level.

Test overview

This test will measure the power consumption of the various system components of the VoIP solution. For “back end” functions like unified messaging and the call server, those systems will simply be “running” without any particular load being placed on them.

All relevant IP phones should be tested as the power consumption likely to vary depending upon screen options and, where there is a screen, whether it is color or monochrome.

Many phones are also able to run at either Fast Ethernet (100 Mbps) or Gigabit Ethernet (1,o00 Mbps). While voice traffic can run without problem at the lower speed, many phones contain integrated switches to carry desktop traffic and FE might cause performance problems for certain desktop applications. Experience to date has shown that phones with ports running at Gigabit speeds will consume more power than those set to FE irrespective of whether any traffic flowing across the port. Thus, it is important to choose and test the LAN speed(s) appropriate to your intended deployment.

Test coverage

Given that a VoIP system evaluation can legitimately include or exclude a wide variety of elements, it is important to accompany the results of any benchmark with a grid outlining the components involved along with any special notes that will help orient the reader.

The following table can be adapted to your individual needs and illustrates identification of major system components. Tolly recommends not only noting which areas are included but also which are excluded. This provides a proper context for understanding the scope and relevance of the test.

VoIP System Test: Deployment Scenarios

(with sample data)

VoIP System Benchmark Coverage Areas

(with sample data)

Component summary: Bill of materials

Based on the scenario and scope, a bill of materials (BoM) will need to be constructed for each scenario. It is this BoM that will provide the quantities for each solution component that will ultimately be used to calculate the total power consumption and power costs for each scenario. This BoM must include specific model information along with quantity information.

Measurement and documentation

Because of the complex nature of configuring VoIP system solutions, it is critically important that key elements be documented clearly.

Tests should be run after the SUT has completed initial startup procedures but before heat begins to build up that would trigger any fans to activate in appliances or server components.

VoIP phone: Measurement and documentation

VoIP phones are powered by DC current usually using Power over Ethernet. Thus one must us a slightly more complicated approach to measurement than with the system components that simply plug in to standard AC power supplies.

If you are measuring across the PoE connection you will need a text fixture that is place “in line” that between the VoIP phone and the PoE switch which allows data to flow through to the switch but also allows the power to the phone to be measured.

Alternatively, one can use an external power source such as the PowerDsine 3100G PoE injector. This device connects to AC power and thus can be measured with a standard AC power meter. If this approach is used, one MUST first measure the power drawn by the injector alone (i.e., when not providing power to a phone). This amount is then subtracted from the readings made with the phone and injector together. (Past tests have shown that the aforementioned model of the PowerDsine, for example, draws 1.6 watts.)

The following table can be used to record results for VoIP Handsets

System components: Measurement and documentation

Most of the remaining components in the system will either be implemented as standalone appliances or software loaded on to industry-standard server platforms. The measurements can almost always be made using a standard power meter. The measurements should be an average over at least a one minute period.

The following table can be used as a guideline for the data that should be collected about each system component.

VoIP System Power Consumption Measurement

Interpretation of results

See section on Total Cost of Ownership (TCO). Results will typically be interpreted in a relative manner as no formal standard yet exists that defines “efficient” power utilization for VoIP solutions. When evaluating a single product or multiple products, power cost projections can be made. More information on this is in the TCO section of this document

Evaluating Total Cost of Ownership

Adding power into the equation adds another layer of complexity to calculating TCO and ROI. In one sense, the addition makes things easier. One can calculate direct device energy consumptions costs quite precisely (assuming one has an accurate base cost).

On the other hand, the power consumption over time is still only one element that must be considered when evaluatiing TCO for complex VoIP systems.

Users per server

Calculating energy TCO for VoIP systems is more challenging than, say, calculating energy costs for a LAN switch. There are several reasons for this. With switches, the energy consumption per port is typically the same or nearly the same irrespective of how busy the switch port is. In most cases there is a 1:1 or 2:1 ratio between switch ports and users. It is 1:1 when a single end-station is connected to the port. it is 2:1 when a device like a VoIP phone is directly connected to the switch port and that phone contains an integrated switch that allows the users desktop to connect to the main network via the phone’s integrated 3 port switch. (One port each for the phone and the desktop and one uplink port.) No other system components that reside external to the switch need to be figured into the calculation. Not so, with VoIP systems.

With VoIP systems, there is in almost every case, a “client-server” relationship between front-end components — the VoIP phone — and back-end components. The back end components will, at a minimum. consist of the call server that provides the “brains” to allow phones to set up phone calls to other users inside and outside the company.

In most cases, standard servers would include a voice mail/unified messaging server and emergency services. Others might include servers related to application-specific uses like call centers.

In every case, it is critically important to understand the ratio between users and servers especially when comparing alternative solutions. If, for example, when building a 1,000 user telephony environment, one vendor’s call server supports 100 users and an alternative vendor supports 500, the difference between needing to deploy ten call servers for the former and only two for the latter will likely have a significant impact on TCO. Not only will power consumption likely be higher but hardware costs, license costs, rack space and support costs will almost undoubtedly be higher. Thus, in any reckoning of system configuration it is critically important to establish a correct and and accurate ratio between system components.

Because of the nature of this exercise, you will almost certainly have to rely on vendor claims as it is unlikely that any given vendor will provide independent certification of, say, the fact that 10,000 VoIP phones can be supported effectively by a single call server. (Though, if such systems are deployed, the vendor should be able to provide independent certification or at least a customer reference.)

High-availability (HA) configurations

As telephony systems and related messaging services are essential elements of any corporate environment, customers will frequently want to deploy configurations where duplicate and/or redundant components are used to provide high-availability. These components will add not only to the power budget but likely to hardware, licensing, support and space requirements as well.

Furthermore, there is no single accepted definition for what “HA” means. Clearly, the more resistant your system is to failures, the more expensive it is likely to be as more redundant/backup components are added. Especially when comparing offerings of different vendors, be certain to make sure that the “HA” recommendations of each are truly comparable.

Electricity rates

Government agencies typically publish power costs by region. In the USA, the Energy Information Administration provides the official energy statistics from the U.S. Government. Note that the costs vary by sector with residential costs higher than commercial which is higher than industrial. The pointer below will bring you to a sample page (which may be out of date) and the figure shows the general layout and content of the site.

Official energy statistics by state

>

Power up – Cool down

The power that goes in to a switch is mostly dissipated in heat. That heat must then be drawn off through an air conditioning system. Thus a device that consumes more energy than another would also give off more heat and thereby require ones air conditioning system to expend even more energy in neutralizing that heat.

Thus, cost with respect to power can be viewed multiple ways. In its simplest form, the power consumption results will be used to calculate the electricity charges that will result from running a particular device.

Dissipation location

The costs to dissipate heat should be calculated as well. When a switch is delivering power over Ethernet, the calculations for dissipation becomes more calculated. Some of the heat is dissipated to the IP phone or other device being powered.

Life cycle and environmental impact

While beyond the scope of this document, users are advised that various vendors are now offering “life cycle” views of their equipment. This typically includes a plan for recycling equipment at the end of its useful life.

Such plans may also take into account manufacturing processes and/or other elements related to how the solution interacts with our earthly environment with respect to emission of so-called “greenhouse” gases.

Power over ethernet

When it comes to delivering energy over PoE, the calculations can get a bit more complicated when one considers, for example, metrics like “cost per port to deliver a full 15.4 watts per port.” The reader needs to decide which particular calculations are relevant.

Readers should also be advised that work is under way with switch vendors attempting to make the delivery of power over ethernet more intelligent and thus more cost effective.

It is likely that, in the near future, you might be able to reduce your overall VoIP power consumption leaving your VoIP handsets in place and upgrading wiring closet LAN switches. The discussion of Power over Ethernet is beyond the scope of this version of the Tolly Common RFP but is covered in Tolly Common RFP #1080 LAN Switch Power Consumption.

Sample cost calculations

The estimated annual electrical cost can be estimated based on the steady state power draw (SPD):

• (SPD(W) X .001) X 24 hr/day=KWH/day
• KWH/Day X KWH Billing Cost= Cost/Day
• Cost/Day X 365= Cost/Year
• Example: 150 W SPD 150 X .001=.15 KW X 24hr = 3.6 KWH/day X $.093/KWH Billing Rate = $.3348/day X 365 day/year = $122.20/year, in addition to the electrical cost of operation. The cost to cool network devices is also major factor in total cost of ownership. The annual cost for cooling a device can also be estimated. All electrical device produce heat paced on the total power they consume. This heat is measured in BTU (British Thermal Units). BTU can be calculated based on the steady state power draw using 3.41 as a conversion factor. The efficiency of the rooms cooling system (k factor) must be included in the calculation of the cost for cooling. Newer air conditioning units are more efficient and may require as little as .33 BTU to cool 1 BTU of heat.
• SPD(W) X 3.41= BTU/hr

NOTE TO READER: The cost calculations are “Preview”only and are in the process of review and enhancement.

• Example 150W X 3.41= 511.5 BTU/hr
• (BTU/3.41) X .001 = KWH for device
• KWH for device X k factor= KWH for cooling
• KWH for cooling X 24 hr/day = KWH/day for cooling
• KWH/day for cooling X KWH Billing Cost = Cost/Day
• Cost/day X 365 = Cooling Cost/Year
• Example: (511.5 BTU/hr/3.41) X .001 = .15KWH X .33 k factor =.0495 KWH for cooling X 24 hr/day =1.188 KWH/day for cooling X $.093 = $0.1105/ day for cooling X 365 =$40.33 Cooling cost/year
• Or if you already have calculated Electric cost of operation per year you can just multiply the k factor to determine the cooling cost per year Cost/Year X k factor = cooling cost/ year
• Example: $122.20/year X .33 = $40.33

About the author/document

DEFINITION

The Tolly Common RFP series presents a collection of detailed test plans that are designed to help validate feature/function and performance characteristics of Information Technology products and solutions. The Common RFP can assist Information Technology professionals as well as technology vendors in conducting detailed, consistent assessments of product features and performance.

PURPOSE & SCOPE

The RFP document does not present a product feature “checklist” nor does it specify levels of achievement required to “pass” a given test. Rather, the purpose of the Tolly Common RFP is to provide a wide range of specific evaluation points – more items and elements than are likely required by any single user. Users of this document can select those tests and evaluation points that they find relevant to their environments.

Ultimately, the purpose of the Common RFP series is to reduce the amount of time and effort expended by end-users in the RFP process. While users may have some unique requirements, it is likely that there are many requirements that are common across a great many users. This document aims to identify and document those common requirements and, most importantly, how to quantify how well a device or solution meets a given requirement.

This RFP document is a “living document” to which tests are added over time. Thus, any document should be considered a subset of all possible tests rather than a comprehensive collection. We welcome suggestions for additional areas to be covered either within this document or of other technologies.

This document draws upon expertise from The Tolly Group as well as invited input from leading technology vendors and end-users. Any vendor input is evaluated by Tolly engineers and analysts and included as deemed appropriate by the Tolly team. Vendors do not pay to provide that input and vendors do not sponsor this document. As with end users, some vendors may choose to license the document for their own internal use.

AUDIENCE

This document is written for a technical audience, specifically, people who are tasked with conducting “hands-on” evaluations of the subject technology to validate compliance with customer requirements. While it is our goal to provide appropriate context for the RFP tests described herein, basic knowledge of the subject technology and testing techniques is assumed.

LICENSING AND USAGE

This material is intellectual property of Tolly Common RFP, LLC and is offered only through a paid license agreement. You or your employer must have such a license in place to possess and use this document. Typically, the document is licensed on an annual basis.

If you are a VAR, consultant or reseller you are not licensed to distribute the document to your customers unless you have signed a distribution agreement with Tolly Common RFP, LLC.

Contact us at: Tolly Common RFP, LLC. Post Office Box 812333, Boca Raton, FL

33431. 561-391-5610. You may also contact the series editor, Kevin Tolly, directly at

Kevin.Tolly@tolly.com.

SUPPORT FOR THE RFP DOCUMENT

Depending on your license agreement you may have email, telephone or no support.

Please reference your subscription purchase invoice, license agreement, and/or company coordinator.

Tolly Common RFP 1082: VoIP System Power Unauthorized Reproduction Prohibited

DISCLAIMER AND TERMS OF USE

Tolly Common RFP, LLC presents this RFP as an informational, instructional tool and is not responsible for how the reader makes use of it. Users should not make purchases based solely upon the information that they gather based upon running the tests described herein. While reasonable efforts have been made to assure that the tests procedures produce accurate results, neither accuracy nor applicability are guaranteed.

Under no circumstances will buyer/user be entitled to any damages that exceed the licensing costs paid for use of this RFP.

Document Abstract – V1.0

This is the first version of the RFP and was released in March 2009.

This version covers basic power consumption measurement tests. It also addresses total cost of ownership with respect to power and provides resources and sample calculations.

Source: ComputerWeekly