WiFi Network Billing System deployment options logic at different scales

Last month a friend from WiFi, who operated the park, approached me and they just took up a new project, about 2,000 terminals, which was a long-term solution. They used open source to build them, dozens of APs and hundreds of users barely worked, but the scale was all over the place.——The certification of overtime, the billing, the reconciliations were wrong and the carrier was being pushed by clients every day. He asked me what to do with WiFi's network billing system. I talked to him and thought it was a typical question, not just that he had encountered.

Many people have a misunderstanding that WiFi’s network billing system must be commercial. But, in fact, if you only had one or two points, and together there were less than 200 terminals, you could run with the Coova Chili+FreeRADIUS+ MySQL package. That's how many university laboratories do it, and there are no big problems for a year or two.

But what's the problem?"That's enough."The opening condition is that you have someone to defend.——RADIUS configuration, database optimization, log rotation, and secure patches are easy to do, but they take time. Many small operators or small campus teams, IT alone, run the network and servers and connect customers, have no effort to maintain this package. I asked a few clients who abandoned their open source options for commercial products after more than six months, for almost the same reason: it was not good enough to open up, but it was too little effort to serve itself.

So the core of the selection for small-scale scenarios is not."Can you do it?"But..."Can the team keep up?". If the team were one or two, it would be more cost-effective to go directly to commercial WiFi network billing systems and spend a little more money on the front and less on the back.

By the level of 500 to 23,000 terminals, the selection criteria for WiFi’s network billing system are completely different from those for small scale. At this stage you must consider several open source options that are naturally missing: precise flow billing, multiple set management, user self-service portals and minimum reconciliation functions.

I have seen a case of WiFi operating in the mall, using a national-based WiFi network billing system that initially selected the standard version. Three months after it was online, one problem is: traffic statistics are not matched by more than 10 users per day, with dozens or dozens less. Individual users vary little, but accumulate errors of hundreds of dollars a month. It was later discovered that some sessions caused by CoA ' s response timeout were not properly terminated and the billing module did not receive final flow data.

These problems are not even discovered in small-scale settings.——The user base is too small to have a minimal impact. But on a large scale, any tiny calculation error will be magnified. So when you choose medium-sized models, you can't just look at them."Do you have a billing function?"The accuracy of the billing, the abnormality mechanism and the ability to fully interface with the RADINAS report on Accounting are determined.

More than 3,000 terminals, or multiple branch sites, the WiFi network billing system is not selected to look at a functional list; architecture design is the real decision-making factor. Distributional or centralized? How do data synchronize when deployed more often? How do business management authorities divide?

A technical director of a chain hotel group told me something that I thought was quite there:"What we want is not a fully functional billing system, but a system that quickly locates node failure in the event of a problem."He actually said that to the heart of a big scene.——A single failure point. If WiFi network billing system puts all its capabilities on a server or data centre, any problem will result in the entire web being out of use.

So the selection of this size should focus on: RADIUS load balance capabilities, data consistency for distributed billing nodes, network delay tolerance when deployed in multiple locations and whether there is a well-developed hierarchy of managerial competencies.

Whatever the size, the WiFi network billing system option must take into account an iron truth: it has to match existing AP and AC equipment. There is no single program on the market that can be fully aligned with all brands and models. I have encountered a project that was not taken into account at all by previous options, and after signing contracts and paying advances, it became clear that there were problems in the standard RADIUS compliance of AP manufacturers with the system.——CoA messages are not formatted in an identical way, which results in some users being offline and unable to re-authenticate.

This is entirely avoidable. There are at least three things to do before the selection: first, to list all brand models that are using AP and AC; second, to have the option manufacturer provide a compatibility test report; third, to run at least one round of NATSHEL_AUTH_BILLING in the testing environment. These three things take little time but they prevent millions of projects from turning over.

And finally, there's a dimension that almost everyone ignores when selecting WiFi network billing systems.——Long-term transportation costs. The cost of transport here is not just annual insurance and upgrades, but also human costs that are required to operate daily.

For example, does your billing system have automated reconciliations? If not, it takes at least half a day to check manually every month. Do you have a batch interface? If not, the operator changes the new set of meals by one user each time. These seem small, but multiplying them by 12 months and then three or five years, and the cumulative cost is quite significant.

So I've been suggesting that when we get the offer, we don't just have to look at the system's interactive design.——The operational complexity of the operator, automated reporting, and unusual warning coverage. These are the things that determine your experience in three or five years of transport, much more important than one function less than one.