How the network Wi Authentication & Billing interfaces with existing AC and AP is never really critical“Can you play the page?”But...Could authentication links, release logic, billing state and terminal control really run?. The page pops up only to show that the forward jump may be okay, but how the subsequent authentication results are returned, who controls user access, how the billing status is synchronized, how the user breaks after maturity and how the terminal state is maintained is the key to the ultimate stability of the project.
So we're gonna have to take a wrong spot out of the beginning:
The ability to play Portal pages does not amount to a successful docking of existing AC and AP systems on the Web Wi Authentication & Billing system.
The first thing to be sure before a real docking is whether or not the existing ACs are supporting it.External PortalThis is very important. Many equipment campaigns have written support for Portal, but the Portal in it sometimes has a simple page capability that this machine carries and does not necessarily mean that it can work smoothly with external Authentication & Billing platforms. Some equipment jumps over pages, but there is incomplete back-writing support for authentication results; others support basic certification, but are not suitable for more sophisticated fee and terminal control logic; others have different versions of equipment, which vary considerably. That means, the previous period cannot just ask questions about the quality of the certificate.“Supported Portal”And ask you more: do you have support?External Portal, Radius connection, authentication state synchronization, terminal release control。
The second is to look ahead to the existing network. Although both AC and AP are on the ground, it is not ambiguous how the flow of traffic goes, how the authentication flow goes, and who really controls exports. Some live wireless access looks standard, and the actual certification release logic is not closed. For example, users can be redirected to the authentication page when they access AP, but the real exit is not on the AC side, but on other gateways or export equipment. If this layer is not clear, there is a situation that can easily follow: the certification works, the pages show normal, the user cannot access the Internet, or the Internet does not match the backstage status.
So the network Wi Authentication & Billing system interfaces AC and AP, which must be complete from the beginning to the end. After user terminals are connected to AP, who will first pass the authentication page, who will send it, who will verify the information, who will issue the release strategy after verification, who will execute the break-up or recovery of the billing status, and if the access is not confirmed before this whole chain will fall into the back of the project.“It looks like it's almost over.”The pit.
There is also a particularly real problem, namely the compatibility of different brands. The number of wireless equipment brands common on site is many and there are various manufacturers, models, versions, and adaptation capabilities to external Authentication & Billing systems is different. Some brands are more open and external Portal and Radius connections are mature and relatively compatible; others have limited access to basics, but support for external systems becomes very difficult when they involve more sophisticated costing and terminal control.Specific model, current version, current network configuration。
Besides AC itself, access patterns are also seen when accessing APs. For example, if centralized or decentralized, if centralized, or locally administered; fat or thin; if different regions share the same authentication strategy. On the surface, APs are just access devices, as long as signals come from them, and in practice, as long as there are multiple buildings, areas, multiSSIDs exist, the distribution of strategies at the AP and AC levels will have a direct impact on the way NATSHEL_AUTH_BILLING systems land. In particular, such scenes as schools, apartments, parks and so on are often not just web-based, one SSID behind a rule, the other another strategy. If this level is not planned, it will only get messy.
A lot of clients will miss one thing, that's...Synchronization of billing and online statusThis is actually the most problematic and undervalued place in the connection. Because WiFi Authentication & Billing system does not only register, it also pays fees and ends. When users buy a package, the state is put into effect in time; equipment is limited in time when the package expires; the network is quickly restored after the user fee has been successfully renewed; and when the terminal limit is exceeded, the system is able to determine precisely which equipment is online and which one should be kicked offline. If these actions are not properly linked to the existing AC/AP system, they can lead to strange problems on the ground: when a package is bought but cannot be accessed online, it has expired and has not stopped, or when the system's backstage shows an online presence, users actually have been offline long ago.
There are also log and retrospective issues. Many scenes run the WiFi Authentication & Billing system, not just for fee but also for log retention, user behaviour check-up, authentication records retroactive.“Can you verify it?”The data is scattered when the authentication records, terminal information, and Internet access are matched to the log links that follow. Otherwise, the certifications are done before, and there is a real need for records, accounts, terminals, and the project remains incomplete.
So, really mature practices never come up and say“You can answer it directly.”Instead, we should identify each of these questions on the ground:
Whether existing AC supports external Portal
Whether or not to support Radius and associated mobility
What's the current brand, model, version?
Where are the tops and export controls?
Who will release the certification after it is successful?
Who will enforce the limits after the billing expires
How to synchronize terminal, online and log status
These conditions are clear before it can be judged whether direct docking is sufficient, or whether there is a need to add NATSHEL_AUTH_GATEWAY, or to adjust the current network. Many projects are not technically impossible to re-engineer at a later stage, but rather pre-opt.“Connect existing ACs and APs”This is a light thought, thinking that the page is finished. In fact, the page is just an entry and it's really hard to get this whole chain of control back there.
After all, the WiFi Natshell system and the interface of existing ACs, APs are not in essence.“Page face-to-face”But...“Links to the line.”. Only when the links go well, authentication, billing, terminal control and logs are all going to go together. If you look at the page, the project will leave behind its consequences; if you see the back-office logic, network structure and equipment capability, then the connection is real.