Most people who operate the network have this feeling: systems are bought, certified and the package is online, but there are a few links that are blocked like hair vessels, students complain, and they take fire out of the sky. The problem is often not core functions, but those in the whole chain."It looks okay, but it's a problem."# On the fine little nodes.
The campus Internet access billing system is not a server, but a complete link from the operator's line to the student phone screen. Each node may have breakpoints, and most breakpoints are not technically impossible to achieve, but are designed without treating them as problems.
The first break point that is most easily overlooked, in the operator access level. Many schools are buying a functional list of their billing systems: Portal certifications, flexible set-up and financial reconciliation. But interfaces on the operator side are often treated as if they were not yet available."We'll take care of it later."The reality is that if schools use proxy models to work with operators, the number synchronization between BRAS equipment and billing systems is the most vulnerable link in the entire chain. Is the account number synchronized by the operator time-twice or real-time push? Are there any downgrade mechanisms after synchronization failed? How long will the system be aware of a change of operator suite for students? These issues are rarely discussed at the procurement evaluation stage, and thousands of students are on line during the school season, before massive complaints about the failure of dialling become visible.
One practical case has been seen: a college dialling system using a batch of synchronized operators every morning, with very frequent school year-long students changing their suites, resulting in a group of students changing the set and running old school net, and the operator having stopped serving but the student's use of the school access to the Internet, which accumulated until the end of the month. The problem is essentially due to an unreasonable data synchronization frequency design, not bugs, but to a decision-making error at the programme design stage.
The second breakpoint is the delivery chain for Portal certification. The mainstream program is Portal ' s forced jump, and students automatically eject the authentication page after they have access to the WIFI browser. But this mechanism often acts unstablely on the mobile end. iOS and Android versions change the system ' s logic of handling mandatory jumping pages, some intercept pop windows, some put Portal pages backstage. Students go on the WIFI network, and the certification page does not come out, and he tries repeatedly, and eventually gets systematically judged as abnormal. The problem in this scenario is not with the system itself, but with whether the Portal push strategy is adapted to the mobile end and if there are fallback mechanisms.——For example, when pushing failed, a certified link was provided through text messages or micromails to enable students to manually complete the certification.
The third breakpoint is the delay in implementing the billing strategy."Immediately."The actual meaning of the system may be very far from the same. Some systems have a counter-recording strategy, with a few seconds to dozens of seconds of delay. At peak times, this delay is magnified and hundreds of people are charged at the same time, backlogs in queues, delays are extended to several minutes, students pay no more than they can get online, call the network centre, and the logs of the transport check find account balances to be accounted for, but the strategy has not yet been updated. The problem of such an experience’s impact on students’ charging delays is usually not detected during functional testing, as the test environment is well below the real school season. A simulation peak charge test should be scheduled at the receiving and inspection stage to observe the delay in worst-case scenarios.
The fourth breakpoint is a combination of wired and wireless authentication status. There are two access systems in the campus, which allow students to use desktop machines for their accommodations and cell phones for their cellular use. The question is: is the same account number released simultaneously after cable certification? If it does not synchronize, there will be confusion over the student's account status, with the same account number at both locations."Online"The logic of the billing may be wrong and bandwidth control may be bypassed.
The entire chain also has a deeper break point: asymmetrical logs and surveillance. Many school operators can see the number of Portal online in real time, but they do not see the distribution of specific causes for certification failure; they can see a summary of the amounts charged, but they cannot see the path to retesting students after the charges fail. Logs are scattered, surveillance is one-sided, and questions become complaints, so the drivers start to collate data from various systems to determine why.
Understanding these breakpoints is not about choosing a system that has no breakpoint.——There are no such systems. Instead, these breakpoints are managed as known risks during the selection and implementation phase: ask each link for technical realization, identify a downgrading strategy when an anomaly occurs, test the response time of a critical path.