The most central output of the campus network billing system is bills. Inaccurate bills, students complain, and financial reconciliation errors affect cooperation between schools and operators.——The pre-tests did not cover the true high-sum scene.
Grounds for non-receipt: loss of billing reports
The bottom logic of the system is that: Authentication Gateway regularly sends a Radius Accounting message to the billing service (start of billing, update of billing, closure of billing). The charge-back services are based on time spent online and flow data in the report.
The problem is that the Radius Reporting report is based on UDP transmission and does not guarantee delivery."End of billing."The paper will keep the user's online session in the billing system."Hanging on.", ongoing billing.
A good billing system will do."Sessions to keep you alive."——Query regularly to Authentication Gateway"Is this user still online?". If the gateway returns"Offline"The billing system automatically closes the session and settles it.
The correct method for testing the accuracy of bills
When the factory shows, they usually run the process with a test account or two and tell you."The bill is correct.". This demonstration has no reference value.
The correct test is the number of co-directed users that simulate real scenes, allowing all users to go online and randomly downline for 24 hours, then compare the billing records in the counterbalancing system with the actual online logs in Authentication Gateway.
There is also a test method: whether the billing system can supplement the billing report by deliberately rebooting the billing service, looking at the users who are on line during the reboot.
Discrepancies with operator reconciliations
A lot of campus networks are."School for operator fees"Model: A student buys an Internet-based package, the money goes to a school account and the school settles with the operator. In this scenario, billing from the system is accurate not only for students but also against the operators’ broadband usage data.
In actual projects, the data on both sides are not normal. The reasons may be: inconsistent costing cycles between the system and operators (one by natural month and one by cycle); or different flow calculations (one by sum of top-down lines and one by bottom).
When you choose, ask yourself if the billing system can be exported."It's for the operator."billing format? Can you re-consolidate data according to the operator's required periodicity and dimensions? If these two functions are not available, later financial reconciliation will be very painful.
The scene where students complain most: the remaining flow of the package is not shown
The student's most sensitive is not."How much did you pay this month?"But..."I bought a 100-G package. It took me three days to use it."90% of these complaints are not miscalculated by the system, but are not taken into account by the logic of calculation of the remaining flow of the package."Flows + Current Session Real-Time Flow"。
Specifically: students download a 10G file and view the remaining traffic during download, if only the system shows"Used Flows"No, no."Real-time traffic that has been generated by the current session but not settled"When you download it, you get 10 Gs and the complaint comes.
A good billing system, which is available in real time to NATSHEL_AUTH_GATEWAY when students query the remaining traffic"Real-time traffic of current active session"And, you know, it's calculated in the flow. It looks small and actually important for reducing complaints. You can use this scenario to measure whether you can do real-time traffic queries.
And the integrity of bills must be considered at the database level.
The billing data of the billing system is stored in a database, and its own reliability affects the accuracy of the bill. Some products are stored on SQLite single files with the benefit of simple deployment, with the disadvantage of having a combined write-up performance and all bill data lost if the document is damaged. For campus networks with over 3,000 users, it is recommended that the product be supported by MySQL or PostgreSQL.
There is also a frequently overlooked problem: the backup strategy for billing data. Some products are defaulted to keep only the last three months of detail, which exceeds automatic clean-up. But the Board of Education audits usually require web logs and billing records to be kept for more than six months. If the product is retained for only three months, the school must take responsibility if it does not have data at the time of the audit."Detailed retention policy"Can we change it by default for how long?