Internet data usage meters are complex systems, with many components that must function well together. Often meter systems include a mix of vendors with home-grown elements added in. A typical meter system includes six processing functions.
The customer’s device (e.g., cable modem, mobile phone, residential gateway, etc.) sends subscriber traffic to and receives subscriber traffic from the ISP’s network edge device (e.g., router, gateway, CMTS, switch), which counts the traffic, and puts that count into a count record. Count records are then aggregated from multiple collectors and the data is converted into uniform values (typically per hour) that are forwarded to the account mediation function. There the usage values are associated with subscriber accounts and any business rules associated with each account are applied. Account mediation then stores the usage information as formal meter records in a general database. In a final step, the data is made available to users via a customer portal.
Data usage meter accuracy fluctuates over time for a variety of reasons [see Why do good usage meters go bad?]. Data usage meters can and do experience issues, making vigilance and proactive measures essential to maintain meter accuracy.
The following report assesses data usage meter accuracy across the industry.
ISP Data Usage Meter Accuracy Industry Assessment
NetForecast has audited the accuracy of data usage meters at many broadband ISPs. Following is a summary of overall meter accuracy at month end (aka the month-end error, or MEE). MEE is the difference between the ISP’s usage counter value derived from within the ISP’s network, and the NetForecast UMap usage value determined by a UMap router operating in a volunteer’s home. MEE is based on the total usage observed by both systems over the same calendar month. MEE can have three basic outcomes:
We apply the standard NetForecast meter accuracy specification across all the ISPs. MEE is defined as being within the specification (within spec) for each subscriber home if the MEE is within +/-1%. Data usage meters are assessed by the percentage of subscriber homes NetForecast is tracking that fall into the following MEE categories:
The NetForecast monthly meter accuracy reports summarize the percentage of NetForecast-measured sites in each of the above categories.
Below are composite results from multiple ISPs that use NetForecast’s ongoing meter validation service. Inclusion in this composite required a sufficient number of NetForecast-instrumented homes at each ISP to provide a statistically sound meter accuracy assessment. The composite is a simple average of the percentage of sites in each category across the multiple ISPs. The monthly data is then combined to show general trends across calendar quarters.
Meter accuracy among ISPs working with NetForecast has been improving over the past 3 years as shown in the table below.
The year-over-year increases represent a 6% per year improvement of sites operating within the +/-1% specification.
A quarterly summary of the out-of-spec conditions is shown in the following chart.
Note that the majority of out-of-spec conditions cause underreporting (out-of-spec low) which slows the rate at which a subscriber reaches an ISP’s usage cap. Out-of-spec high instances (overreporting) have significantly decreased over time for ISPs using NetForecast’s auditing service.Back to top
A variety of factors conspire to cause data usage meters to overcount, to undercount, or to be erratic. Underreporting is more frequent than overreporting, although both problems are common and often occur together, causing different results across a service provider’s footprint. Meter errors stem from four main sources, usage counters, processing software, server problems, and human error. A long list of potential issues can cause meters to over or undercount, or to count erratically.
Overcounting is especially troubling to subscribers because it can lead to overbilling. NetForecast has discovered overcounting caused by: meter systems resending counter data; meter systems counting traffic that should not be counted; and vendor product behavior.
Undercounting occurs: when collectors or aggregators cannot keep up with raw traffic counter data volume; when large time gaps occur in counter data; and when meter systems take too long to show traffic events. Although undercounting benefits subscribers in billing situations and may not trouble them as much as overcounting, dramatic undercounting causes subscribers to doubt the veracity of the meter, adversely affecting a service provider’s credibility, reputation, and ultimately revenue.
Meter reporting can become erratic: when packet loss in an over-utilized part of the network causes errors; when a meter doesn’t display data in a timely way and catches up after the fact; when aggregation systems lose time synchronization; or during some denial-of-service (DOS) attacks. System upgrades or software changes also can adversely affect meter accuracy, and accuracy can be compromised when a service provider pushes the limits of its meter architecture. In addition, meters often have hidden design flaws that only emerge during accuracy testing.
Over the decade that NetForecast has been auditing data usage meter accuracy, we have seen that meter accuracy problems fall relatively evenly into the four categories: counter problems, software problems, server issues, or human error. Here is the approximate breakdown, and some examples of each of the categories.
Back to top
Based on our extensive experience auditing the accuracy of data usage meters, NetForecast has developed best practices for ISPs to define proper operation and assess whether their meter is operating as expected. You can read the report here.Back to top
You can gather your own usage information either from a computer or from the network on your premises. A computer can track what is downloaded to/uploaded from it, but it does not report network protocol overhead because such data is hidden within the PC operating system (you need special instrumentation software to see all the protocol traffic).
For example, if one looks at the size of a file on a PC, that value does not include any protocol overhead, which may lead one wrongly to conclude that the ISP meter is overcounting. If you measure traffic at the network layer, you will see the payload traffic plus overhead from protocols like TCP/IP and Ethernet, which generally add about 6% to 9% overhead to the payload traffic for large packets and a larger percentage for small packet traffic like VoIP. The meter system counts the traffic as seen on the wire, which includes the payload plus protocol overhead, so it should closely match the network view. Network layer counting is best done using an intelligent switch or router.
Be aware, though, that these devices often fail to count all protocols (e.g., Ethernet), so you may be undercounting. It is important that your network device counts ALL traffic passing into and out of the Internet, and that your device does not count local traffic (e.g., traffic to printers or local music servers). You must be certain to count all Wi-Fi traffic to/from the Internet. You must be careful to configure your measurement software to count only the relevant traffic.
Doing your own counting also requires careful data gathering. Switch and router counters typically default to zero when the device boots, and subsequently display cumulative usage counts. These counts continue to increment past ISP billing month boundaries. To track your ISP’s usage meter accurately, you must record counts periodically—especially at the billing date boundary. Keep in mind that the date boundary depends on the time zone your ISP uses.
Details that may seem minor can mess up your counts. For example, we recently discovered a home router that appeared to count properly, but it only counted usage for devices in the DHCP table at start up. Usage by devices added to the network after the router booted went uncounted. Rebooting the router brought the new devices into the counts from the reboot onward. The subscriber reasonably concluded that the ISP was over-counting, but in fact, months had passed since the last router reboot, and new devices were introduced into the home during that period. These new devices generated significant usage that the router did not count but the ISP did. Properly measuring home usage requires technical know-how, careful attention to process, and patience.Back to top