Two sets of logic have been pulled up in WiFi's network billing system: authentication methods and costing strategies. Authentication determines how users access the Internet, and billing strategies determine how users are measured and deducted. Both things sound independent, but they are closely coupled within the actual system, which is poorly configured to raise a variety of problems. Some projects divide certification and billing between different people, and result in certification being over-connected with the calculation data or that the costing strategy works well, but user experience is extremely poor.
Portal certification and long-term time billing are natural matchings.
Portal certification is the most common authentication method in WiFi network billing system, where users connect to WiFi and eject the authentication page and enter an account password and access it.——The time-counting begins at the moment of authentication success, when users voluntarily or automatically stop counting when they break up with time. Note that Portal certification has a problem point: the user turns off browsers without downlines and if the system does not detect terminal delinks, the clock will continue. Configure the time-time calculation must be accompanied by an online terminal detection strategy, such as determining the downlink if there is no response to three consecutive heart beats, otherwise the user will find the last time-long running on the next login.
802.1X certification and more sophisticated matching of flow-based fees
802.1 X certifications are lower than Portal certifications, and authentications occur on the chain layers where users do not feel the existence of authentication pages. 802.1 X and flow-based matching statistics are more accurate because all traffic in authentication status is controlled by a billing system, unlike Portal certification, which may have problems with precertification flow leakages.——The terminal is configured with certificates or clients, AP and switchboards to support the transport of a complex dimension. If schools require high billing accuracy, user terminals are relatively fixed (e.g., the cable network in the teaching building), 802.1X is a better option.
MAC certification is not appropriate for billing, but it can be exempted.
MAC certification is often misused in WiFi web-based billing systems. Some schools use MAC authentication as a formal accreditation method, with the MAC address attached to each terminal and charged to its address. There are two problems: first, that MAC addresses can be forged, and students can use other people's amounts by changing their MAC addresses; second, that end MAC addresses change, such as iOS private address functions that allow the same cell to change MAC addresses daily, and billing data is all out of order.——Printers, Iot devices, for example, are not billed terminals that can be released directly through the MAC White List. Use the MAC certification where it is used, and don't use it as a basis for calculating costs.
Mixed authentication strategy to be designed by regional context
The WiFi use of different regions in schools varies widely, and it is often not feasible to manage all regions using a certification plus costing strategy. Teaching buildings are suitable for 802.1X certification + open-flow time statistics (mainly for audit purposes); dormitories are suitable for Portal certification + set-of-show flow billing (students have clear consumption expectations); public areas are suitable for Portal certification + free time-limited strategies (guarantee basic network usage). WiFi network accounting systems are required to support subregional strategies, authentication methods and costing strategies are configured on a regional basis.——Users move from the accommodation area to the teaching building, how certification is done, how billing strategies are changed and whether there is a break-in perception during the switch, which is better configured for user experience.
The logic of the billing process when authentication fails cannot be ignored
WiFi has a border situation that is easily overlooked: how to handle the traffic that has occurred when authentication fails. Users have entered the wrong password, authentication failed, but terminals have tried to connect to the network, and there may be a small flow. Do these flows need to be recorded in user accounts? Most systems defaulted out, but if not clearly configured, there may be cases where certification failure users still generate traffic and the billing system does not record it. The flow processing strategy for certification failure should be clear: either it is completely blocked (IP not assigned before authentication) or records are recorded without charge (logs retained for audit).
Authentication status interface for the package switch
The connection of authentication status is a technical detail when users switch their packages in the WiFi network billing system."Ten dollars, 5 G."Switch to"$20, 10G package.", is the switch process online, requires a user to re-validate it or does the system automatically refresh its strategy without disconnecting it? The first user has bad experience and the latter has complicated its technology. Different systems are handled differently, and configurations are based on actual scenarios——If the switching frequency is low, there is no major problem in requesting recertification; if the switch frequency is high (e.g. a sky-switching package), the insensitive switch must be supported, or if the user has to relive WiFi every time the switch is made, the number of complaints will be high.
Data consistency for authentication and billing is regularly verified
The authentication and billing systems are two sets of data, which are divided into different modules even on a platform. After some time online, there may be inconsistencies between the data on both sides.——The authentication records show users online, but the billing system shows users being downlined; or the billing system records traffic, but there are no corresponding sessions in the certification system. If not regularly verified, such inconsistencies accumulate as a source of fee disputes. WiFi network billing systems need to configure daily data consistency checks, cross-checking the certification logs and billing logs, and separate treatment of inconsistent records. This is not a complex task, but someone has to do it, and cannot wait until users complain before finding that data is not matched.