Over the years, building network projects have seen too many cases of late rollovers due to poor billing system selection. Some buy cheap goods, six months of online counting logic is not back, and operators are not getting their own accounts; others choose a large and full platform, so the operator simply doesn’t understand it, and the monthly checkout is done overtime.
Let's find out who the network is for.
That sounds like bullshit, but when we actually do the project, many of the firms that have not even figured out how to do it start recommending a programme.
Pure writing buildings, tenants are the main users, network needs are business-oriented and flow models are relatively stable——The day peaks, night valleys, and weekends are almost non-flowing."By bandwidth + traffic pack"Combination of the billing, which is aligned to the property rental cycle.
There may be software development companies (large traffic, high bandwidth), a team of live-broad operators (high upflows, sensitivity to delays), and ordinary office businesses. Mixed tenants mean that the billing strategy must be flexible, with flow charges at all costs depleting high value customers.
The hotel building is another completely different scene. The guest is a temporary user, and the certification + billing + time control needs to be integrated, and supports PMS docking (the house charge includes network costs). If you take the writing building's scheme for hotels, the authentication process and the calculation logic are not matched.
The first step in the selection is not to look at a list of product functions, but to figure out how the building is painted and traffic models. This is wrong, and all the configurations are patched on the wrong basis.
The flexibility of the costing strategy is more important than the number of functions
Some of the product lists are written in a very small way: support is provided on time, by flow, bandwidth, month, year, step, blend.……The list of functions draws two pages. But when you really do it, you find that these billing patterns cannot be freely combined or that the configuration interface is so complicated that it takes a week to get started.
I've had this in a project. A side bought a name."Global coverage"The first check was made with the carrier, who checked the data for two full days and found that three floors were misdefined as parameters and all monthly bills were re-repeated.
A really good network traffic system. The billing strategy should be configured to:"Select role+strategy template+reciprocal parameters"The bottom logic is that the system has pre-sets a costing model for common scenes (writing buildings, industrial parks, hotels, apartments), you choose a template and then you adjust several key parameters to the reality. There is no need to build a log from scratch.
You need to get a clear check on the coupling with the authentication system.
The relationship between the billing system and the certification system, each manufacturer's treatment is different. Some of them are a tight coupling.——The billing module is embedded in the certification system and upgrades to authenticate solids are needed to update the costing strategy; some of them are loose coupling——The billing is run as an independent service and interacts with NATSHEL_AUTH_GATEWAY through API.
The advantage of a tight coupling is that it is simple to deploy, one equipment handles authentication plus billing, and the carrier does not have to handle two systems. The bad side is also clear: the logical change in the calculation involves a significant risk for certification equipment; and the problem in the certification is also connected with the failure of the crediting system.
NATSHEL_AUTH_GATEWAY is responsible for user access and identification, and the billing system independently handles strategies and bills. Communications are conducted through standard protocols (Radius Billing, REST API). The benefits are individual upgrades, without disruption; the negative side is higher in transport capability, which requires an understanding of the logic of the two systems.
When you select a model, ask: What does this system have to do with Authentication Gateway? Is it plug-in or stand-alone? Does the billing data lose when NATSHEL_AUTH_GATEWAY fails? Do you need to reboot authentication services for updating the billing strategy? These questions are not clear in advance, and we have problems on line before checking them.
The ability to account and reconcile is a test for the system.
A billing system is useful. Do not look at Demo, see the account function.
The billing of the network usually requires several conditions: a natural monthly check-out, support for midway changes (upgraded bandwidth in the tenant month), support prorating, support for prepaid and later payment mixes, bill details (Excel/CSV) and support to interface with financial systems.
I saw a system of billing in an industrial park project, and it was normal when the functionality was demonstrated, but by the time the actual account check came up with problems: a tenant changed his suite that month, and the system was only charged for a new set of meals for a full month, not converted daily. The result was an upgrade from 100 to 500 m per month, with a charge of 500M for a whole month, the tenants were not paying their bills, and the property was covered between the two.
The network’s export bandwidth is usually contracted with the operator, and the property needs to know how much each tenant spends, whether it's correct or not, and if there are any unusual traffic users."Operator bill comparison"Functions——Automatedly match flow/long-duration data from system statistics to operator clearing data——This would significantly reduce the workload of the transporter.
Don't ignore deployment and the wiring threshold.
Many buildings have limited power booths, no standard cabinets, or even a steady supply of electricity. If your billing system requires a dedicated server plus database+UPS, deployment costs and maintenance costs will go up.
There are programmes that support soft routers or virtual machine deployments, and billing systems run on generic hardware as a service. This is more friendly for small and medium buildings.——No additional hardware is required and the existing servers or NASs can be carried.
The IT team of property companies is not always the same. If a billing system is managed on backstage with professional training, later maintenance is a problem. A good billing system should allow a network-based operator to perform day-to-day operations independently after half-day training: view online users, check bills, adjust policies, and export reports.
A simple requirement can be made when the model is selected: that manufacturers be able to use their systems on site to configure a complete set of billing rules.——The user group, strategy binding, checkout setting to the report is timed throughout the period. If the configuration process exceeds half an hour, this indicates that the system has a problem with utility.
Finally, a point that is easy to ignore: expansion.
The tenants are dynamic. Today the whole floor is leased to a company, and tomorrow it may be divided into four working spaces for different teams. The billing system needs to adapt quickly to this change.——New users, grouping and changing strategies should not require re-engineering of services or reprogramming the entire configuration.
Also, if the building is to upgrade its network in the future (e.g. from gigabytes to megabytes or with an increase in Wi-Fi 6/7 coverage), can the billing system be smooth? Can bandwidth units be flexible? Can the metering be more fine? These are all things that need to be considered in advance of the selection, otherwise the cost of re-engineering the system later on would be much higher than the first one.