The billing system is not accurate, and it has a direct impact on the tenants’ willingness to pay their fees on time, as well as on whether there are disputes between property and operators about the settlement.——Many projects were not followed up when they were online and the first payment was made before all kinds of mismatches were discovered.
The traffic is a single caliber.
The most basic bill accuracy problem, often arises"What about the traffic?"This looks like a simple definition.
Operators usually use the traffic statistics caliber."Billing bytes"Counts the costs of the IP head, TCP top-level agreements."Net Load"Yes, there is."Total bytes"And, you know, there's only one way to measure the flow (for example, just down and not up. If your billing system doesn't have a caliber that goes with the operator, your bill for the tenant is not matched by the account bill that the operator gives you.
For example, a tenant downloads 1000 GB content in the month, which is 1,000 GB by net load; but if it is measured by a costing bytes (with an approximate 5-8% TCP/IP head charge), it should actually be about 1070 GB. This 7% difference is not evident at 100 GB level, and to TB level is dozens of GB differences, with hundreds or thousands of dollars in commercial bandwidth prices.
When selecting a model, you should confirm: What is the traffic caliber of the billing system? Can you configure the statistical direction (one/two-way)? Can you configure whether the agreement is included? If upstream operators change the statistics, can the system be quickly adjusted?
Cost particle size affects bill accuracy
The normal particle size is a given second, minute, minute, hour.
The more particles are fine, the more accurate the bill is, but the larger the amount of data. A medium building for 1,000 users, with a single day's flow record, may be millions if it is in particle size per second; and less than 300,000 if it is in particulate mass every five minutes.
For a traffic-based scenario, the particle size is too thick to lead to bill deviations. One example is that a user has an unexpected large flow (e.g. downloading a big file) over a five-minute window period, and if sampling during this window captures only average traffic, the actual peak flow will be smoothed out, resulting in lower costing. Conversely, when samples are caught at their peak, they may result in higher billing costs.
The practical suggestions were that the particle size could be a bit thick (5-15 minutes) for time-consuming scenarios, since long-term statistics would require less precision; and that the particle size in flow-based scenarios should preferably be within one minute to ensure that sudden traffic was accurately recorded.
NET and the attribution of flows in proxy environments
One of the most common problems in the building network is that there may be only a few IPs for a writing building, and hundreds of users are connected to it. If traffic billing systems look at traffic data at the IP level of the net only, they cannot distinguish which user/roperator uses how much.
The solution is usually to do traffic statistics at the NATSHEL_AUTH_GATEWAY level——When the user is certified online, the gateway records the traffic of each online user so that regardless of how NAT converts it can be attributed to a specific account number.
But there is a question of detail: if an enterprise has built its own internal agent or VPN, the staff flow first to the enterprise's internal server and then to the corporate server for a unified public access. At this point, the billing system sees the export traffic from the company's internal servers rather than the individual flows from each employee. If the business tenants also control the internal traffic, without which the billing data on the property side can only be calculated by the enterprise as a whole and cannot be broken down into individuals.
This is not a fee-based system bug, but it is a data boundary problem caused by the network structure."Flow statistics for intra-enterprise networks are export-based"The rules are clear and avoid later disputes.
Common causes and responses to bill disputes
I have summarized several high-frequency controversial scenarios:
Category I:"I don't use that much.". This is usually a situation where people within the tenant download or run automatic updates, but the tenant manager does not know.——The billing system is best supported."Use your warning."function, automatically issue a notice when an account/renter ' s usage is abnormally increased, rather than waiting to be accounted for.
Category II:"We don't use the traffic at midnight.". The tenants in the writing building should not theoretically have a large flow after work, but sometimes office computers are open, automatically updated to run on the backstage or someone has remote access to VPN, which causes traffic at night."Time-bound traffic report", show the tenant the distribution of usage over each time period.
Category III:"Your statistics are not right for us."Some tenants (especially IT enterprises) also do flow statistics internally, comparing their data with the billings of the property. If the statistical calculator is not consistent (e.g., it counts both sides and down, but not the agreed costs).
Operator clearing reconciliation cannot be ignored
Property rents export bandwidth from the operator, usually at a fixed monthly fee or 95 (at 95th percent peak per month). The property receives a flow/band bandwidth rating for tenants. These two sets of fees are independent in logic, but the industry needs to know: is the overall usage within the operator’s contract? Is there any additional costs arising from proximity to or beyond the bandwidth?
A good network traffic system should be able to do it."Operator bill simulation"——If the simulation value is more than 5% different from the actual bill, it indicates either a missing count or a problem with the operator and needs to be checked in time.
This is a feature that is unattractive, but can be achieved by exporting raw data to Excel or by docking third-party analysis tools.
The level of automation of the check-out directly affects transportation costs
Finally, a pain in the actual dimension: degree of automation of the check-out process.
The most basic requirements are that the system automatically generates bills for all tenants on a monthly specified date, and supports mail or system alerts.
I've seen a project where the billing system itself is not working, but it's all manual.——The carrier manually exports data, uses Excel for calculations and sends mail by hand at the beginning of each month. It spends a lot of time repeating work and is prone to errors.
The automation of the check-out is not complicated, but many items are online without any configuration. It is recommended that the check-out process be completed as soon as the system is deployed and not wait until the first check-out is done.