The WiFi compliance certification is usually treated as a technical project: selection, deployment, on-line, and closing. But the hotel that actually does this will find that it is longer-term challenges to deliver the security. Technical programmes can be completed within a month or two, and long-term work. Good hotels, with no problem running for two or three years; poor ones, have been able to start with logs missing, certification failures, customer complaints in six months.
What's the malfunction pattern?
The most frequent failure patterns in the WiFi certification system of hotels that I maintained were probably these:
The first category is the authentication page that cannot be opened. Guests can access WiFi, but the browser does not project Portal or the page can never be rounded up. The reason is usually: NATSHEL_AUTH_GATEWAY load is too high (while online equipment exceeds capacity), DNS resolution failure (Porttal domain decomposition failed), HTTPS recalibration problems (the browser defaults HTTPS and Portal is HTTP)."The net doesn't work."The high rate of complaints does not necessarily represent a failure of the certification system itself.
The second category is log writing interruptions. The system is functioning normally on the surface, but logs are not properly written. This may be because there is a full storage space, log database connections fail, networks that are pushed to cloud ends are interrupted and local temporary storage is fully occupied.
The third category is the inconsistent authentication data. The certification system shows that a user has been online, but in fact the user has checked out or, conversely, the user has certified but no corresponding log record. Such problems usually arise from PMS synchronous delays, inappropriate meeting status when network disconnects are reconnected, or bugs of the authentication system itself.
How's the surveillance system going?
In order to address the above-mentioned malfunction patterns, the monitoring system should cover the following levels:
The system is accessible: every few minutes you can detect whether Portal pages are accessible and authenticated API responding. If a continuous failure exceeds the threshold, you will be warned. This monitoring is very low, but it quickly identifies problems that affect the client most.
Logs write integrity monitoring: check log writing every hour, compared to the expected value. If a time writing is zero or significantly low, trigger alarms. This control requires historical baselines——Count normal writings for weeks and set reasonable warning thresholds.
Storage capacity monitoring: The remaining space stored in real-time surveillance logs is pre-empted when below a threshold (e.g. 20%) and sufficient time is reserved for processing. Many of the problems that are written into the records after they have been fully stored are caused by lack of timely expansion, which can be prevented well in advance.
Clock synchronization: The time difference between the system and the standard time of each Authentication Gateway is regularly checked. Warnings are issued for deviations exceeding one minute, and alerts are raised for more than five minutes. This surveillance is simple but very easy to miss.
Design of a transport-based response mechanism
With surveillance, there's a need for an accompanying response mechanism. Many hotel IT carriers are"Passive"The problem with this model is a delay in responding to the delay.——Guests complained that IT personnel were in place, and one or two hours may have passed between them, and the missing window of time for the log has been formed.
It is recommended that a hierarchical response mechanism be established: failures affecting the Internet access of clients (a certification system not available, Portal unwieldy), defined as P0, requiring 15 minutes to respond and recovery within 1 hour; log writings for anomalies, storage alerts defined as P1, requiring one hour to respond and four hours to process; and problems with reduced performance without compromising usability defined as P2, processing within 24 hours.
For small and medium hotels without dedicated IT personnel, the corresponding SLA could be contracted in a supplier contract with the vendor assuming responsibility for the transportation of the carrier. It should be noted, however, that the contract must contain an explicit agreement that the response time begins with the notification from the hotel and not with the identification of the issue by the supplier; the recovery time is defined as"Guests can access the Internet and logs are properly written."No, it's not."Vendor completes an operation"。
Daily inspection lists
In addition to monitoring and warning, regular manual inspections are also necessary. It is recommended that a basic inspection be conducted once a week, including: confirmation of log storage for the past seven days; random sampling of 3-5 authentication records to confirm field integrity; checking of remaining space stored; checking whether there are warnings pending; and verification of a complete certification process (a Portal validation with test devices).
Conduct of a monthly in-depth inspection: random check of the log entry and log matching of one day against PMS data; checking of clock synchronization for all equipment; checking of consistency between vendor cloud platform data and local data; review of alarm records over the past month to identify recurring problems.
This inspection mechanism takes a lot of time, and experienced IT personnel can do it in 30 minutes each.
Note for Version Update
The version update of the authentication system software is a high-risk point of time that can be easily problematic. I have seen several times, and suppliers send updates to the system, and hotel IT staff install them directly without looking closely at the update instructions. It turns out that the update has changed the log field format, that the old format logs are mixed with the new format logs, and that there was a data resolution error during the query.
It is recommended that, before updating the version, suppliers be asked to provide an update note focusing on whether the log field structure has been changed; whether the authentication process has been modified; and whether reconfiguration of parameters is necessary. Once updated, a complete validation is performed: go through the certification process to confirm that the log fields are fully written and formatted in a manner consistent with the update. This verification step takes little time but avoids many problems.