Many units are using the Authentication & Billing system for their own purposes, and the real risk of being difficult to handle is not taken seriously. When the system is online, the problem comes up one by one.——Some have problems with equipment matching, others with data migration and some operators agree to lock down the process. These cases are judged at the project research stage, but most people do not ask in this direction.
The first risk that is easily overlooked is compatibility of existing network equipmentThe network Authentication & Billing system usually relies on Portal or 802.1X protocols to work with access equipment, which requires that standard RADIFUS configurations be supported by AC, BRAS or switchboards and the corresponding solidware version is not subject to any strange restrictions. In reality, these scenes are often used in different ages and in different manufacturers. Some old equipment has formatting limitations for Portal re-entry URLs, some two layers of switches have been incomplete for 802.1X, and some third party branding has had a private extension of equipment in Radius properties. If the current equipment model and solid version are not sorted out when the models are selected, then the back-to-back docking phase will recur."Why is the network not working after authentication?"Such issues are highly cost-effectively identified.
The second risk is the migration of historical user dataThe old system has been running for several years, with accounts, packages, balances, Internet records. When the new system is online, the migration options are not easily accessible to every manufacturer. Commonly: the new system has different user chart structures and old systems, password fields are encrypted differently and cannot be imported directly; the field definition of the package system is incompatible and requires manual maping; account balances are synchronized with third-party financial systems when they are tied to them. If there is no pre-record matching and migration testing, a large number of users will be unable to log in and have an abnormal setup on the day of the line switching.
The third risk is the operator's access cycle.In high schools, apartments, parks, etc., systems often require proxy or broadband account systems for the operator. Such interfaces are not technically autonomous and require operators to open interfaces, provide testing environments, and undergo approval processes. Interfacing clearance within operators is usually monthly, with year-end or season-end approval windows tightened, which may be delayed longer. If a system selection does not include an operator in the schedule planning, and when equipment is in place and the system installed, it will be discovered that the operator interface has not been approved and the entire time of access is delayed.
The fourth risk is co-inflicted authentication.. The bid parameters are written on"Support N-000 users"Usually refers to the number of registered users, not the number of authentications that are issued simultaneously. The real influence on the use of experience is the ability to process certification per second——Especially for the time period during which users can be certified centrally, such as working in the morning and students leaving school, requests for certification are intensely received on short notice. If the system’s Portal authentication process fails to keep pace with it, users encounter problems of certifying overtime and repeating the authentication page.
The fifth risk is the cost of follow-up to compliance auditsThe network Authentication & Billing system must retain user logs, which usually require more than 180 days of log retention, as requested by the Ministry of Public Security. This storage is not free. Many units do not add to the cost of storing audit logs at the time of procurement and only then find out that daily logs are produced far beyond expectations, disk capacity is insufficient, and expansion costs extra.
Each of these risks is clearly identified in advance of the start-up of the project: running compatibility confirmations by getting a list of existing equipment; field matching the old system ' s data sheet structure for exporting out; confirming the interface approval process schedule well in advance with the operator; clearly defining the indicators to be certified and issued per second within the solicitation parameters; adding capacity planning and costs to the total budget for log storage. An extra week of checking before implementation would normally be much more cost-effective than repeating problems after being online.
The selection phase is really worth the time, not just to compare functional lists, but to put these implementation risks on the desktop and give manufacturers a clear response. Manufacturers that can make clear these issues are usually actually doing similar projects.
There is also a risk of experience gained by the project implementation team.The Authentication & Billing system involves a longer technical chain: authentication protocols, network equipment configurations, billing logic, user management, payment docking, compliance auditing, each block with details. If the implementation team is not familiar with certain links, it takes a lot of time in these locations and even leaves risks to the system. In evaluating bids, it may be useful to ask manufacturers whether they can provide examples of how the same type of scene (the same size, brand of the same equipment, the same way of authentication) is implemented and to contact case units for information on the actual situation, which is one of the most direct ways to judge their ability to implement.
The government is not in a position to do so.Risk management at system-line time nodes is not to be ignored.The Authentication & Billing system is often lined up with the time nodes of school start, building occupancy, and park opening, which, if missed, has a significant operational impact. In actual projects, delays in the arrival of equipment, operator interface clearances, on-site construction coordination problems, etc., are not uncommon for them to be delayed. It is proposed that risk buffer times at key nodes be included at the start of the project, rather than scheduled for optimal conditions.