WiFi portal management method and device based on multi-service fusion

Abstract

The embodiment of the invention provides a WiFi portal management method and device based on multi-service fusion, and the method and device achieve the effective distribution of resources through the innovative design of an access scheduling system, load evaluation and feature extraction. An authentication processing mechanism is constructed, and a reliable security policy is established in combination with multi-level verification and anomaly detection. Response management is introduced, and access continuity is ensured through authority control and session recovery. According to the method, the defects of the traditional technology in the aspects of access scheduling, authentication processing, response management and the like are effectively overcome, and technical guarantee is provided for WiFi portal management.

Description

WiFi Portal Management Method and Device Based on Multi-Service Convergence Technical Field

[0001] This application relates to the field of data processing, specifically to a WiFi portal management method and apparatus based on multi-service convergence. Background Technology

[0002] Existing WiFi portal management methods have significant shortcomings. Traditional systems perform poorly in access scheduling and load balancing, failing to effectively allocate resources and impacting user experience.

[0003] Furthermore, existing technologies suffer from bottlenecks in authentication processing and security protection. Most systems lack robust multi-level authentication mechanisms and anomaly detection strategies, resulting in insufficient security reliability.

[0004] The existing system has technical shortcomings in response processing. It lacks in-depth analysis of authentication status, making efficient anomaly recovery through session management difficult and impacting system stability. Resolving these issues is crucial for improving WiFi portal management capabilities. Summary of the Invention

[0005] To address the problems in the existing technology, this application provides a WiFi portal management method and apparatus based on multi-service convergence, which can effectively solve the shortcomings of traditional technologies in access scheduling, authentication processing and response management, and provide technical support for WiFi portal management.

[0006] To address at least one of the aforementioned problems, this application provides the following technical solution: Firstly, this application provides a WiFi portal management method based on multi-service convergence, comprising: acquiring an access request data stream initiated by a user terminal; performing proximity access scheduling through a content delivery network edge node; constructing weight calculation rules based on the service node load status; calculating a load score by combining processing capacity indicators and connection number thresholds; distributing the access request data stream according to the load score; parsing the user agent identifier to obtain a terminal feature vector; generating multi-level authentication request data based on the terminal feature vector; constructing hierarchical verification rules based on the multi-level authentication request data; generating a user encryption factor based on a global key; and converting the encryption factor... An authentication feature matrix is ​​calculated using the user's password. An access permission identifier is generated based on the authentication feature matrix. An anomaly detection model is constructed to monitor the authentication process. Anomalies are identified and node switching is triggered based on the anomaly detection model. The access permission identifier is written into a distributed cache system and persistently stored. A user session data packet containing the authentication status is generated. A network response rule is constructed based on the user session data packet. Multi-level authentication verification is performed. A redirection policy is determined based on the authentication security level. The redirection policy is mapped to a gateway permission instruction. An anomaly is detected based on the anomaly detection model, and session recovery is performed. Response data containing the redirection address is generated. The response data is sent to the user terminal to complete the wireless network access authentication.

[0007] Furthermore, it also includes: parsing network requests initiated by user terminals, extracting request header identification information, establishing a terminal address mapping table, constructing a network topology distance matrix based on the physical location of the terminal, performing status detection on edge nodes of the content delivery network, constructing a node availability index set, generating scheduling basic data containing node load status and geographical distribution based on the availability index set; constructing proximity access rules based on the scheduling basic data, quantifying node processing capacity parameters according to preset standards, generating dynamic thresholds according to load balancing requirements, configuring priority coefficients according to network topology distance, substituting the priority coefficients into the calculation unit, allocating nodes to access requests based on the calculation results, and generating a scheduling dataset containing service node identifiers and load status.

[0008] Furthermore, it also includes: constructing load calculation rules based on processing capacity indicators, performing real-time statistics on the number of service node connections, establishing a load assessment model, generating performance parameters based on processing resource utilization, sampling and analyzing node response latency, constructing a performance curve matrix, and generating a load feature set containing resource utilization and connection data based on the performance curve matrix; constructing distribution control rules based on the load feature set, quantifying and assigning node performance indicators according to preset weights, generating dynamic thresholds based on the upper limit of the number of connections, configuring scheduling parameters according to load balancing requirements, substituting the scheduling parameters into the load matrix, distributing and allocating request data streams according to the calculation results, and generating an authentication dataset containing user agent identifiers and terminal characteristics.

[0009] Furthermore, it also includes: constructing a security parameter table based on multi-level authentication request data, obtaining global key parameters from the configuration center, establishing an encryption rule engine, generating random salt values ​​based on user identity identifiers, obfuscating key parameters, constructing a security calculation matrix, generating a security feature set containing user-specific encryption factors and verification markers based on the security calculation matrix; constructing authentication processing rules based on the security feature set, hashing user password data according to preset standards, generating verification parameters according to security level requirements, configuring feature mapping according to encryption rules, substituting the verification parameters into the calculation unit, classifying and marking user permissions according to the calculation results, and generating a permission dataset containing authentication features and access levels.

[0010] Furthermore, it also includes: constructing monitoring rules based on authentication process data, collecting service node status in real time, establishing an anomaly identification engine, generating baseline thresholds based on response latency parameters, performing frequency statistics on authentication failure events, constructing a status evaluation matrix, and generating a monitoring dataset containing node health and anomaly characteristics based on the status evaluation matrix; constructing fault handling rules based on the monitoring dataset, classifying and categorizing abnormal events according to preset standards, generating switching strategies according to system disaster recovery requirements, configuring backup parameters according to node status, substituting the backup parameters into the decision unit, migrating nodes for authentication requests based on the judgment results, and generating cached data packets containing fault recovery and session status.

[0011] Furthermore, it also includes: constructing response processing rules based on user session data packets, performing multi-dimensional verification of authentication status, establishing a security assessment engine, generating verification benchmarks based on session validity parameters, determining access permissions by level, constructing an authentication matrix, generating a response feature set containing security level and verification results based on the authentication matrix; constructing redirection rules based on the response feature set, mapping and converting access policies according to preset standards, generating allowance parameters according to gateway control requirements, configuring routing policies according to redirection types, substituting the routing policies into the conversion unit, authorizing access to user requests based on the calculation results, and generating an instruction dataset containing allowance instructions and routing identifiers.

[0012] Furthermore, it also includes: constructing access monitoring rules based on an anomaly detection model, collecting gateway response status in real time, establishing a session tracking engine, generating monitoring thresholds based on access delay parameters, extracting features from access interruption events, constructing a fault judgment matrix, and generating a monitoring dataset containing access status and anomaly type based on the fault judgment matrix; constructing recovery processing rules based on the monitoring dataset, verifying the integrity of session status according to preset standards, generating recovery strategies according to business continuity requirements, configuring reconstruction parameters according to session type, substituting the reconstruction parameters into the processing unit, restoring the user session status according to the execution result, and generating a response data packet containing redirection address and session identifier.

[0013] Secondly, this application provides a WiFi portal management device based on multi-service convergence, comprising: a load calculation module, used to acquire access request data streams initiated by user terminals, perform nearest access scheduling through content delivery network edge nodes, construct weight calculation rules based on service node load status, calculate a load score by combining processing capacity indicators and connection number thresholds, distribute the access request data streams according to the load score, parse user agent identifiers to obtain terminal feature vectors, and generate multi-level authentication request data based on the terminal feature vectors; and a request authentication module, used to construct hierarchical verification rules based on the multi-level authentication request data, generate user encryption factors based on a global key, and calculate a multi-level authentication request data by combining the encryption factors with the user password. The authentication feature matrix is ​​used to generate access permission identifiers. An anomaly detection model is constructed to monitor the authentication process. Anomalies are identified and node switching is triggered based on the anomaly detection model. The access permission identifiers are written to a distributed cache system and persistently stored. A user session data packet containing the authentication status is generated. The gateway access module is used to construct network response rules based on the user session data packet, perform multi-level authentication verification, determine a redirection policy based on the authentication security level, map the redirection policy to a gateway allow command, determine an allowance anomaly based on the anomaly detection model and perform session recovery, generate response data containing the redirection address, and send the response data to the user terminal to complete wireless network access authentication.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the WiFi portal management method based on multi-service convergence.

[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the WiFi portal management method based on multi-service convergence.

[0016] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the WiFi portal management method based on multi-service convergence.

[0017] As can be seen from the above technical solution, this application provides a WiFi portal management method and device based on multi-service convergence. Through an innovative access scheduling system design, it achieves effective resource allocation via load assessment and feature extraction. An authentication processing mechanism is constructed, combining multi-level verification and anomaly detection to establish a reliable security policy. Response management is introduced, ensuring access continuity through access control and session recovery. This method effectively addresses the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 is a flowchart illustrating the WiFi portal management method based on multi-service convergence in an embodiment of this application; Figure 2 is a structural diagram illustrating the WiFi portal management device based on multi-service convergence in an embodiment of this application; Figure 3 is a structural diagram illustrating the electronic device in an embodiment of this application.

[0020] Reference numerals: Electronic device 9600, Central processing unit 9100, Memory 9140, Communication module 9110, Input unit 9120, Audio processor 9130, Display 9160, Power supply 9170, Buffer memory 9141, Application / function storage unit 9142, Data storage unit 9143, Driver storage unit 9144, Antenna 9111, Speaker 9131, Microphone 9132. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0023] In view of the problems existing in the prior art, this application provides a WiFi portal management method and device based on multi-service convergence. Through an innovative access scheduling system design, it achieves effective resource allocation through load assessment and feature extraction. An authentication processing mechanism is constructed, combining multi-level verification and anomaly detection to establish a reliable security policy. Response management is introduced, ensuring access continuity through access control and session recovery. This method effectively solves the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management.

[0024] To effectively address the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, and to provide technical support for WiFi portal management, this application provides an embodiment of a WiFi portal management method based on multi-service convergence. Referring to Figure 1, the WiFi portal management method based on multi-service convergence specifically includes the following steps: Step S101: Obtain the access request data stream initiated by the user terminal; perform nearest-neighbor access scheduling through the content delivery network edge node; construct weight calculation rules based on the service node load status; calculate the load score by combining the processing capacity index and the connection number threshold; distribute the access request data stream according to the load score; parse the user agent identifier to obtain the terminal feature vector; and generate multi-level authentication request data based on the terminal feature vector. First, after accessing the access request data stream initiated by the user terminal, perform time alignment and deduplication processing, merging repeated probes from the same source address within a short period into a single valid request. Based on the input source of step S101, parse the request header identifier information and network 5-tuple of each request to generate an initial record containing the terminal address and geographical clues. Subsequently, the online status of the edge nodes of the content delivery network is read, and combined with the processing capacity indicators reported by the nodes and the current number of connections, a candidate set of nodes to be scheduled is formed, which serves as the set of objects for subsequent calculations.

[0025] Based on the candidate node set, a topology distance matrix for nearest access is established, mapping the network location of the user terminal to the set of nearest edge nodes. To avoid bias from a single distance factor, a priority coefficient is calculated by co-placing topology distance and node health, and this coefficient is registered in the scheduling context of each valid request. This scheduling context corresponds one-to-one with the aforementioned initial record and is subsequently used for distribution and inheritance of authentication parameters.

[0026] Based on the aforementioned scheduling context, the load score of the service node is calculated. The load score uses a combination rule that only includes addition, subtraction, and multiplication: Q = a1x1 + a2x2 + a3x3 + b1y1 + b2y2-c1z1-c2z2.

[0027] In the formula, Q represents the node load score; x1, x2, and x3 represent processing capacity-related indicators, such as the proportion of available computing power, the proportion of idle thread pool, and the proportion of bandwidth surplus; y1 and y2 represent connection and session usage items, such as the current connection percentage and the rate of newly established connections in the most recent window; z1 and z2 represent penalty items triggered by exceeding the threshold, such as the timeout rate and the error rate; a1, a2, a3, b1, b2, c1, and c2 are non-negative weights, set according to node type and business time period and limited to a bounded interval. This score is used to perform relative ranking among candidate nodes and is written into the scheduling context for downstream reference.

[0028] Once the load score is ready, a distribution process is performed on each valid request. Specifically, the priority coefficient of the request is combined with Q and sorted, and the node with the higher score is selected as the service node for the current request. At the same time, the order of the candidate nodes is recorded, forming a distribution result that includes the service node identifier and load status. The distribution result is mapped one-to-one with the original request and is used for node location and failover entry in subsequent authentication paths.

[0029] Based on the distribution results, the user agent identifier is parsed and a terminal feature vector is generated. The parsing process includes normalized encoding of the browser kernel, system version, device type, and network capability fields, resulting in a fixed-length vector description with the source node and timestamp appended. This terminal feature vector is associated with the aforementioned scheduling context, ensuring that the network capability bits in the vector are consistent with the capability tags of the service node, thus preventing parameter inconsistencies in subsequent authentication stages.

[0030] Based on the aforementioned terminal feature vectors, multi-level authentication request data is constructed. Specifically, according to the project-side authentication strategy, the basic identity verification level, session validity level, and risk supplement level are organized hierarchically. The parameters required for each level are extracted from the vectors according to the mapping table, and the policy bits issued by the configuration center are supplemented. The parameter blocks produced by each level are merged into a single multi-level authentication request data, with the internal labeling of the order and retry strategy maintained consistent with the node identifier of the distribution result, facilitating the routing of the authentication link.

[0031] After the multi-level authentication request data is generated, the necessary security context is populated. This context reads the global key digest from the key management module, generates a random factor tag related to the user's identity, does not calculate the encrypted value in this segment, but only marks a reference pointer for subsequent hierarchical verification calls. The security context is associated with the multi-level authentication request data through the same session identifier, ensuring that the request preimage can be reused for replay when anomaly detection is triggered.

[0032] At the session identifier dimension, consistency checks are performed on intermediate quantities in the distribution and authentication sub-processes. Specifically, this involves checking whether the service node identifier, timestamp sequence, and retry count are continuous and traceable. If any are missing, the corresponding request is rolled back to the next item in the candidate node sequence for redistribution, while keeping the terminal feature vector unchanged to avoid inconsistency risks caused by repeated parsing. The consistency check result is attached as a flag to the header of the multi-level authentication request data.

[0033] Finally, the aforementioned multi-level authentication request data is submitted to the hierarchical verification rules in subsequent step S102 via an internal message channel. The submitted content includes the scheduling context, load score, distribution result, terminal feature vector, and security context, indexed by the session identifier, so that the hierarchical verification rules can directly reference the output of this step when reading the encryption factor, generating the authentication feature matrix, and access permission identifier, thus completing the connection from access to authentication.

[0034] Step S102: Construct hierarchical verification rules based on the multi-level authentication request data, generate user encryption factors according to the global key, calculate the authentication feature matrix by combining the encryption factors with the user password, generate access permission identifiers according to the authentication feature matrix, construct an anomaly detection model to monitor the authentication process, identify anomalies according to the anomaly detection model and trigger node switching, write the access permission identifiers into the distributed cache system and perform persistent storage, and generate user session data packets containing authentication status. First, read the multi-level authentication request data and security context submitted in step S101, and complete alignment verification at the session identifier dimension. For each request, unpack the three parameter blocks of basic identity verification level, session validity level, and risk supplement level, and locate the subsequent verification path according to the service node identifier in the distribution result. To ensure key reference consistency, establish a one-to-one mapping relationship between the global key digest and the user identity identifier to generate the key reference pointer for this session, which serves as the input source for this segment's encryption calculation.

[0035] Based on the key reference pointer, a hierarchical verification rule is constructed. This rule is executed in the order of "basic identity first, session validity second, and risk supplement triggered as needed," defining the input fields, hashing method, and retry strategy respectively. For the basic identity verification level, the username and password digest fields are read to prepare salt value derivation; for the session validity level, the previously issued session timestamp and expiration window are read; for the risk supplement level, the device fingerprint and geolocation fragment are read and the triggering conditions are registered to ensure a one-to-one correspondence with the terminal feature vector field in step S101.

[0036] Based on the aforementioned rules, a user encryption factor is generated and combined with the cryptographic data to calculate the authentication feature matrix. In the specific implementation, the global key digest, session random factor, and user identifier are input into the secure computing unit in a fixed concatenation order to obtain the user encryption factor; then, the row and column meanings of the authentication feature matrix are constructed according to the levels, so that the rows correspond to the verification levels and the columns correspond to the field families and derived hashes.

[0037] To facilitate weighted judgment and anomaly constraints, a scoring expression containing only addition, subtraction, and multiplication is introduced: R = s1a + s2b + s3c-t1d-t2e.

[0038] In the formula, R is the row-level score output of the authentication feature matrix; a, b, and c represent the consistency score of basic identity comparison, the score of remaining session validity time, and the consistency score of risk supplementation, respectively; d and e represent the error count score and the geographical deviation score, respectively; s1, s2, s3, t1, and t2 are non-negative weights, derived from the policy version, and their specific value range is not limited. The R values ​​of each row of the matrix are written into the verification trajectory of the same session, which is used for subsequent permission generation and anomaly monitoring.

[0039] After the authentication feature matrix is ​​ready, hierarchical verification is performed. First, the R value of the basic identity row is compared with the threshold condition, and a pass / fail result and retry count are written back. If it passes, the session validity row is evaluated to determine whether the session is within the failure window. If necessary, a risk supplement row is enabled to verify the consistency between the device fingerprint and the location segment. The above determinations are summarized into a multi-dimensional verification result under the same session identifier and bound to the service node identifier in the scheduling context provided in step S101 to ensure that the node selection for subsequent open links is consistent with the authentication criteria.

[0040] Based on the multi-dimensional verification results, an access permission identifier is generated. The access permission identifier is coded by level, including the access scope, session duration category, and whether supplementary verification is required. During encoding, the combination relationship of each row of R is read to form an index in the permission mapping table, and then the index is converted into a permission identifier string. This permission identifier includes a policy version number and generation time, which are used as the basis for subsequent cache verification and fault recovery playback.

[0041] Based on the aforementioned verification trajectory and permission identifier, an anomaly detection model is constructed to monitor the authentication process. This model is named Session-Level Anomaly Identifier. It reads the distribution of the same session's R values ​​across different rows, the retry count growth trend, and the node response latency to generate anomaly type and severity labels. When authentication jitter or node response degradation is identified, node switching is triggered according to the candidate node order in the distribution results, and the switching reason and switching time are recorded to ensure consistency with the candidate nodes registered in step S101.

[0042] After the node switching operation is completed, the permission identifier and the consistency flag output by the session-level anomaly identifier are written to the distributed cache system, and persistent storage is triggered simultaneously. The cache key is represented by a tuple of the session identifier and the service node identifier, and the value field includes the permission identifier, verification trace summary, and anomaly label. The persistent storage side records the same structure and adds index fields to facilitate subsequent retrieval by project number and time window.

[0043] After the cache write is successful, a user session data packet is constructed. This data packet uses the session identifier as the primary key, encapsulates the authentication status, permission identifier, node identifier, and exception tag, and attaches a key reference pointer to the security context to ensure that subsequent steps can directly reference it during permissioning and redirection. To ensure end-to-end consistency, the terminal feature vector digest from step S101 is synchronously recorded within the data packet for verification and log alignment during the response phase.

[0044] Finally, the user session data packet is submitted to the network response rule reading interface in subsequent step S103. The submission includes the cache location and persistent record number, serving as input location information for the response phase. This allows for seamless reuse of the output from this step and maintains stable authentication methods when generating redirection policies, mapping gateway access instructions, and handling session recovery.

[0045] Step S103: Construct network response rules based on the user session data packets, perform multi-level authentication verification, determine redirection policies according to the authentication security level, map the redirection policies to gateway allow instructions, determine allowance anomalies based on the anomaly detection model and perform session recovery, generate response data containing the redirection address, and send the response data to the user terminal to complete wireless network access authentication.

[0046] First, the user session data packet output in step S102 is read, and verification is performed at the session identifier level to ensure that the permission identifier, verification trajectory summary, and anomaly label are complete and readable. Based on the service node identifier in the data packet, the current response path is located, and the scheduling context summary registered in step S101 is loaded for consistency comparison of routing and fallback. Subsequently, the execution environment of the network response rules is initialized within the same session scope. The values ​​of the fixed response timeout threshold and retry limit are derived from the policy version to avoid state drift caused by cross-version differences.

[0047] In the execution environment, convergence determination is performed on multi-level authentication verification. Specifically, the scoring records of the basic identity line, session validity line, and risk supplement line are read sequentially. The continuity of the pass marker and timestamp sequence of each line is checked to generate an authentication security level. This security level is mapped one-to-one with the permission identifier. If there is a discrepancy between the two, the latest record in the verification trajectory is taken as the standard, and the correction result is written back to the user session data packet. After the above verification is completed, the paired record of security level and permission identifier is output as the input of the redirection strategy.

[0048] Based on the pairing records, a redirection strategy is determined. The redirection strategy comprises three parts: target address category, parameter carrying range, and fallback order, all primarily driven by security level. To facilitate subsequent mapping and auditing, the strategy priority is numerically expressed using only addition, subtraction, and multiplication: P = k1g + k2h + k3j-m1n-m2r.

[0049] In the formula, P represents the policy priority; g represents the permission scope score, derived from the access scope field of the permission identifier; h represents the remaining session duration score, derived from the verification trajectory; j represents the risk supplement score, indicating whether supplementary verification has been completed; n represents the anomaly label score, marking the severity of session-level anomalies; r represents the target node load score, derived from the load score snapshot in step S101; k1, k2, k3, m1, and m2 are non-negative weights, given by the policy version and limited to a bounded interval. The calculated P is used to sort the candidate redirection targets and output a redirection policy table with ranking.

[0050] Based on the aforementioned redirection policy table, the policies are mapped to gateway permission commands. During mapping, the service node identifier and project number are read to generate a command entity containing permission parameters and a routing identifier. The permission identifier is encoded as a short string and attached to it, enabling the gateway to perform rapid verification in stateless scenarios. For scenarios requiring parameter carrying, session identifiers and timestamp digests are selectively attached as indicated in the policy table to prevent the cross-domain propagation of sensitive fields. After mapping is completed, the command entity is registered in the pending-send queue, and the target address category and priority of this mapping are recorded in the user session data packet for anomaly tracking.

[0051] In the queue to be sent, release monitoring is performed in conjunction with the session-level anomaly identifier from step S102. Specifically, the gateway response status and release latency are collected in real time, the release monitoring threshold trigger value is calculated, and cross-compared with the anomaly label and the target node load score. When a release failure or timeout is detected, the session recovery process is immediately executed. Session recovery replaces the target according to the order of the redirection policy table, while maintaining consistency in the permission identifier, policy version, and timestamp to ensure that the end-to-port path remains unchanged; the replacement action marks the failed instruction as processed and records the reason code.

[0052] After the session is restored, response data containing the redirect address is generated. The response data uses the session identifier as the primary key, encapsulates the target address, route identifier, permission identifier, and exception summary, and attaches the cache location and persistent record number, enabling the terminal and subsequent logging system to consistently locate the same session. For sessions that have been restored more than once, a lightweight retry suggestion bit is additionally included in the response data to remind the terminal to follow a fixed retry interval and avoid repeated triggering within a short period.

[0053] After the response data is ready, transmission and result writing are performed. The transmission action performs differentiated processing based on the terminal feature vector identified in step S101. For example, compatibility parameters are added for mobile terminals, and the complete redirection address is directly returned for fixed terminals. After transmission is completed, the gateway receipt summary and terminal confirmation status are written back to the user session data packet, and the latest clearance status in the cache is updated to form a closed-loop record for subsequent statistics and fault playback.

[0054] Finally, the execution result of this step is exposed to the subsequent session tracking and statistics module in the form of a response completion flag. This flag is associated with the session identifier, service node identifier, and policy version, and provides three directly readable fields: allowance status, redirection address, and recovery count, which are easily reused in the fault judgment matrix and weight calculation rules. At the same time, the order of the redirection policy table and the allowance command is preserved to support subsequent anomaly trend analysis and node switching decisions within the window.

[0055] As described above, the WiFi portal management method based on multi-service convergence provided in this application can achieve effective resource allocation through innovative access scheduling system design, load assessment, and feature extraction. It constructs an authentication processing mechanism, combining multi-level verification and anomaly detection to establish a reliable security policy. Furthermore, it introduces response management, ensuring access continuity through access control and session recovery. This method effectively addresses the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management.

[0056] In one embodiment of the WiFi portal management method based on multi-service convergence in this application, the method may further include the following steps: Step S201: Parse the network requests initiated by the user terminal, extract the request header identification information, establish a terminal address mapping table, construct a network topology distance matrix based on the physical location of the terminal, perform status detection on the edge nodes of the content delivery network, construct a node availability index set, and generate scheduling basic data containing node load status and geographical distribution based on the availability index set; Step S202: Construct proximity access rules based on the scheduling basic data, quantify the node processing capacity parameters according to preset standards, generate dynamic thresholds according to load balancing requirements, configure priority coefficients according to network topology distance, substitute the priority coefficients into the calculation unit, allocate nodes to access requests according to the calculation results, and generate a scheduling dataset containing service node identifiers and load status.

[0057] First, after receiving a network request initiated by a user terminal, packet parsing and time alignment are performed. Duplicate packets within a short period of the same session are merged, retaining key fields from the first and latest packets. Based on the source address, destination address, protocol family, and user agent identifier of the packet, request header identification information is extracted and normalized into a fixed key-value set. Simultaneously, the fingerprint of the original packet fields is stored in the database for subsequent traceability. After parsing, a terminal address mapping table is established at the session identifier level. The table entries record the terminal's LAN address, public IP address, near-end gateway identifier, and inferred access network type, serving as input for subsequent location estimation and routing decisions.

[0058] Based on the terminal address mapping table, and combined with the geocoding library provided by the operations and maintenance side, public network addresses are mapped to city numbers and registered with the geographical coordinates of access base stations or fiber optic nodes to construct a network topology distance matrix. This matrix, with the terminal and each content delivery network edge node as its two ends, records logical hop counts, link latency sampling values, and autonomous system traversal markers, ensuring that distance measurements for a single session are comparable across multiple measurements. Subsequently, status detection is performed on the content delivery network edge nodes, collecting online status, thread pool usage, number of active connections, and near-window failure event counts to form a node availability index set. Geographic distribution labels are attached to these indicators to ensure a one-to-one correspondence between indicators and locations.

[0059] Based on the aforementioned node availability metric set and topology distance matrix, basic scheduling data is generated. This data is indexed by session identifiers and includes a list of candidate edge nodes, load status segments of each node, and geographical distribution labels. It also includes sampling timestamps and version numbers for easy checking during subsequent rule reading. The basic scheduling data shares an indexing scheme with the scheduling context in step S101, eliminating the need for additional adaptation for cross-step read and write operations.

[0060] Based on the aforementioned scheduling baseline data, proximity access rules are constructed. The rules first read node processing capacity parameters and quantify them into bounded proportions according to preset standards, ensuring that capacity indicators from different sources can be summed and compared. Then, dynamic thresholds are generated based on load balancing requirements. These thresholds are bound to session-level historical allocation records to prevent a single node from being repeatedly selected within a short time window. To incorporate distance factors into the sorting process, priority coefficients are configured according to network topology distance, and these coefficients are registered back into the scheduling baseline data, forming an input column that can be directly read by the computation unit.

[0061] Based on the aforementioned input columns, node allocation is completed within the calculation unit. The calculation rule is: U = g1s + g2t + g3u - h1v - h2w. Where U is the ranking value of the candidate node for the current session; s represents the summative score of the processing capacity ratio set; t represents the inverse score of connection activity; u represents the positive score of the distance priority coefficient; v represents the normalized score of the recent failure event count; w represents the normalized score of thread pool usage; g1, g2, g3, h1, and h2 are non-negative weights, derived from the strategy version and limited to a bounded interval. For each session's candidate nodes, U is calculated one by one, and the node with the largest U is selected as the primary service node. Several nodes with the second highest U are recorded as candidate nodes.

[0062] After the allocation results are generated, a scheduling dataset is output. The scheduling dataset includes service node identifiers, node load status summaries, distance priority coefficients, and a list of candidate nodes, along with a calculation timestamp and version fingerprint. This dataset establishes a one-to-one mapping with the aforementioned terminal address mapping table, enabling subsequent steps to trace back to the original address and location estimation based on the session identifier. For access requests that arrive repeatedly within a short period, the latest scheduling dataset for the same session is read for idempotency assessment. If the calculated version remains unchanged and the primary service node is consistent, the existing allocation is directly reused to reduce unnecessary node switching.

[0063] During the process of writing the scheduling dataset, a weak consistency constraint is maintained with the node availability metric set. Specifically, if a refresh of the metric set is detected within the write window and affects the output candidate order, the order is partially rearranged and the order field in the dataset is updated without changing the selected primary service node, thus avoiding session jitter across windows. This constraint flag is also written back to the scheduling dataset for subsequent authentication and release phases, so that a switchover operation can be performed according to the order in case of an anomaly.

[0064] Finally, the scheduling dataset is exposed to the read interfaces of steps S101 and S103. Step S101 uses the service node identifier and load status as the basis for distribution processing; step S103 uses the distance priority coefficient and alternative order, using the same sorting criterion when calculating the redirection policy and resuming the session, to ensure the consistency of the link from nearest access to authentication and release.

[0065] In one embodiment of the WiFi portal management method based on multi-service convergence in this application, the method may further include the following steps: Step S301: Construct load calculation rules based on processing capacity indicators, perform real-time statistics on the number of service node connections, establish a load assessment model, generate performance parameters based on processing resource utilization, sample and analyze node response latency, construct a performance curve matrix, and generate a load feature set containing resource utilization and connection data based on the performance curve matrix; Step S302: Construct distribution control rules based on the load feature set, quantify and assign node performance indicators according to preset weights, generate dynamic thresholds based on the upper limit of the number of connections, configure scheduling parameters according to load balancing requirements, substitute the scheduling parameters into the load matrix, distribute and allocate request data streams according to the calculation results, and generate an authentication dataset containing user agent identifiers and terminal characteristics.

[0066] First, the scheduling dataset and node availability metric set generated in steps S201 and S202 are read and aligned along the service node identification dimension. For each candidate service node, the current and near-window connection count, thread pool usage, and bandwidth utilization ratio are continuously collected. A sliding window statistic is constructed for the connection count, outputting two types of fields: instantaneous value and smoothed value. Sudden jumps are tagged separately to prevent subsequent evaluation from being dominated by short-term anomalies. The above raw quantities are uniformly converted into a standard scale of processing capacity metrics for easy comparison within the same source.

[0067] Based on the aforementioned processing capacity metrics, a load assessment model is established. The model uses computing power margin, bandwidth margin, and session context usage as resource-side descriptions, and node response latency quantiles and jitter amplitude as latency-side descriptions. Significantly long-tailed samples are removed, and summary statistics are retained. All metrics are organized into a performance curve matrix by time slice, with rows corresponding to time slices and columns corresponding to metric families. Each cell includes a sampling timestamp and source tag, ensuring that changes in the same node across adjacent time slices are traceable.

[0068] Based on the aforementioned performance curve matrix, a load feature set is generated. The load feature set uses the service node identifier as the primary key, aggregating resource utilization, instantaneous and smoothed connection values, latency percentiles, and jitter amplitude, while retaining abnormal jump markers. This feature set includes a version fingerprint, serving as the control basis for subsequent readings on the distribution side. It also shares an index with the scheduling context of step S101, facilitating unambiguous cross-step referencing.

[0069] Based on the load feature set, distribution control rules are constructed. The rules first quantify and assign values ​​to node performance indicators according to preset weights. These weights are bound to the policy version and node type to avoid incomparability between different node groups. Then, based on the connection limit configured on the project side and combined with session history allocation records, a dynamic threshold is generated to filter overloaded nodes before allocation. To reflect the constraint of proximity access, the priority coefficient of network topology distance is read from step S202 and added as one of the scheduling parameters to the same computing link.

[0070] Based on the aforementioned scheduling parameters, a distribution ranking value relative to the current session is calculated for each node. The ranking value combines the available ratio of computing power and bandwidth, the congestion level represented by the connection smoothing value, the stability of latency and jitter, and the distance priority coefficient, while deducting from nodes marked with abnormal jumps. After calculation, dynamic threshold filtering is first performed, and then the primary service node is selected from the remaining candidates according to the ranking value. Several ranked nodes are recorded simultaneously to form the allocation result for the current session.

[0071] After the allocation results are generated, mapping is performed on the arriving request data streams. Mapping follows the arrival order within the session, binding requests to the primary service node; if a node state refresh triggers a threshold during binding, the process is reversed sequentially with the reason recorded. In parallel, the user agent identifier is extracted and parsed into four fields: browser kernel, terminal type, system version, and network capability. Fixed-length encoding is used to form a terminal feature vector, which, along with the service node identifier and timestamp from the allocation results, is written into the session context to ensure consistency between the parameter sources during the distribution and authentication phases.

[0072] Based on the aforementioned analysis results, an authentication dataset is generated. The authentication dataset uses the session identifier as the key and includes a normalized representation of the user agent identifier, terminal feature vector, service node identifier, and node load status summary. It also carries a dynamic threshold and a priority field to facilitate traceability during subsequent failover. This dataset is used in step S101 to ensure consistency verification of the distribution chain and in step S102 as the source of fields for hierarchical verification; both share the same index and version fingerprint.

[0073] When the authentication dataset is stored, a one-time verification flag and a policy version number are written. The one-time verification flag indicates whether the session has completed dynamic threshold filtering and priority confirmation; the policy version number indicates the source of the weight group. When the policy version or node family configuration is updated, this can be used to determine whether to perform lightweight recalculation on in-transit sessions to reduce disturbance to high-concurrency links. Finally, the authentication dataset address is registered in the cache index for direct location and reading during the response phase.

[0074] In one embodiment of the WiFi portal management method based on multi-service convergence in this application, the method may further include the following steps: Step S401: Construct a security parameter table based on multi-level authentication request data, obtain global key parameters from the configuration center, establish an encryption rule engine, generate random salt values ​​based on user identity identifiers, obfuscate the key parameters, construct a security calculation matrix, and generate a security feature set containing user-specific encryption factors and verification markers based on the security calculation matrix; Step S402: Construct authentication processing rules based on the security feature set, perform hash calculation on user password data according to preset standards, generate verification parameters according to security level requirements, configure feature mapping according to encryption rules, substitute the verification parameters into the calculation unit, classify and mark user permissions according to the calculation results, and generate a permission dataset containing authentication features and access levels.

[0075] First, the multi-level authentication request data and security context submitted in step S102 are read and aligned at the session identifier level. For each session, the parameter blocks of the basic identity verification level, session validity level, and risk supplement level are unpacked, the field integrity is verified, and the policy version number is recorded. Then, the global key parameters are loaded from the configuration center according to the policy version, and an index mapping is established between them and the project number to ensure that the source of keys referenced by different projects within the same running window is clear and traceable.

[0076] Based on the multi-level authentication request data, a security parameter table is constructed. This table registers the user's identity, session random factor, and policy version for each session, providing a unified entry point for subsequent encryption calculations. The encryption rule engine is initialized accordingly, loading the hash function family and key derivation process, and locking the required parameter order. For each session, a random salt value is generated based on the user's identity. The global key digest, session random factor, and this salt value are concatenated in a fixed order and input into the rule engine. This performs an obfuscation process on the key parameters, forming an irreversible intermediate fragment.

[0077] After the obfuscated fragments are ready, a secure computation matrix is ​​constructed. This matrix uses verification levels as rows and field families and derivation steps as columns, mapping the inputs of the three levels—basic identity, session validity, and risk supplementation—to a unified computation path. Matrix cells record the stage markers and source tags of the derived hashes for easy verification later. Within the same session, a secure feature set is generated from the matrix's derivation results. This security feature set includes user-specific encryption factors and verification markers, each corresponding one-to-one with the session identifier, and includes a timestamp and policy version, serving as the sole input source for subsequent authentication processing rules.

[0078] After the security feature set is prepared, authentication processing rules are constructed. The rules perform hash calculations on the user password data, ensuring the hash order matches the verification markers in the security feature set to avoid offsets caused by cross-level references. Based on security level requirements, corresponding parameter bits are extracted from the security feature set to generate verification parameters, distinguishing between mandatory basic identity verification, mandatory session validity verification, and on-demand risk supplementation execution paths. Subsequently, feature mapping is configured in the encryption rule engine, mapping the verification parameters column-by-column to the input ports of the computation unit, and registering retry counts and window information to form a replayable execution trajectory.

[0079] Based on the aforementioned configuration, the driving calculation unit completes step-by-step verification and aggregates the verification results at each level into authentication features at the session dimension. During aggregation, row-level pass markers and error counts are retained to form sparse records that can be referenced for subsequent anomaly detection. Based on the aggregation results, user permissions are hierarchically marked, encoding three types of fields: access scope, session duration category, and whether supplementary verification is required, generating access level identifiers. This access level and authentication features together constitute the permission dataset and share the session identifier with the session-level anomaly identifyer in step S102, facilitating consistency verification during subsequent granting and recovery processes.

[0080] After the permission dataset is generated, the access level identifier and authentication feature digest are backfilled into the cache and persistent storage. The cache key is a tuple of session identifier and service node identifier, and the value field includes access level, verification trace digest, and policy version number. The persistent storage side adds an item number and time window index, supporting historical retrieval by item and version. This backfilled record will serve as the direct read entry point when determining the redirection policy and mapping gateway release instruction in the subsequent step S103, ensuring that the authentication path and response path use the same verification criteria.

[0081] Finally, the execution result of this authentication process rule is written to a consistency flag. This flag records the version number of the security feature set, the hash function family identifier, and the execution window of the computation unit, used to determine whether a recalculation or downgrade verification needs to be triggered subsequently. When the policy version is updated or the key is rotated, reading this flag can locate the set of sessions that need to be migrated, thereby maintaining the stability of the authentication chain at a relatively low cost.

[0082] In one embodiment of the WiFi portal management method based on multi-service convergence in this application, the method may further include the following steps: Step S501: Construct monitoring rules based on authentication process data, collect service node status in real time, establish an anomaly identification engine, generate baseline thresholds based on response latency parameters, perform frequency statistics on authentication failure events, construct a status evaluation matrix, and generate a monitoring dataset containing node health and anomaly characteristics based on the status evaluation matrix; Step S502: Construct fault handling rules based on the monitoring dataset, classify and categorize abnormal events according to preset standards, generate switching strategies according to system disaster recovery requirements, configure backup parameters according to node status, substitute the backup parameters into the decision unit, perform node migration for authentication requests based on the judgment results, and generate cached data packets containing fault recovery and session status.

[0083] First, the permission dataset and verification trajectory summary generated in step S102 are read and aligned at the session identifier dimension. Based on the service node identifier and timestamp sequence of the same session, authentication process data is continuously collected, including gateway receipts, node response latency, timeout retry counts, and error code distribution, and the data is denoised and imputed. Then, the execution status of the service nodes is retrieved, and thread pool usage, number of active connections, near-window failure ratio, and queue depth are recorded as the raw data for the node status.

[0084] Based on the original data, monitoring rules are constructed. These rules generate baseline thresholds using multi-quantile values ​​of response latency and jitter amplitude, while also marking stable intervals within historical windows to avoid misjudgments caused by short-term fluctuations. Frequency statistics are established for authentication failure events, accumulating data by session, node, and error code indices, and marking sudden peaks. Indicators such as latency, failure frequency, thread pool usage, active connections, and queue depth are organized into a state evaluation matrix by time slices. Rows correspond to time slices, columns to indicator families, and cells include source and version fingerprints for review.

[0085] Based on the aforementioned state assessment matrix, a monitoring dataset is generated. The monitoring dataset calculates node health and anomaly characteristics for each service node. Health is derived from a combination of three indicators: latency stability, failure frequency, and resource usage. Anomalies are further categorized into three types: high timeouts, concentrated error codes, and queue congestion. The monitoring dataset uses node identifiers as the primary key, associating them with session sets and time windows to ensure that subsequent policy reads can pinpoint the specific session range.

[0086] Based on the monitoring dataset, fault handling rules are constructed. These rules first classify abnormal events according to preset standards into three levels: alert, downgrade, and switchover, and record the triggering conditions and cool-down periods. Then, a switchover strategy is generated according to system disaster recovery requirements. The strategy includes target node candidates, switchover priority, and rollback conditions, referencing the candidate priority and distance priority coefficients output in step S202 to ensure that the switchover path is consistent with the nearest access point.

[0087] Based on the aforementioned switching strategy, backup parameters are configured. These parameters include the allowed number of session replays, cache read locations, and inheritance flags for permission identifiers, which are mapped to node health to impose stricter replay and confirmation requirements on high-risk nodes. The backup parameters are then fed into the decision unit to determine the allowable links for the current session. When the anomaly level reaches the switching threshold or is repeatedly triggered during the cool-down period, node migration is executed, selecting the target node in order of priority and recording the reason code and switching time.

[0088] While the node migration operation is being performed, session consistency is maintained. Specifically, the original session's permission identifier, verification trajectory digest, and security context reference pointer are copied in their entirety to the target node's context to avoid inconsistencies caused by secondary authentication; in-transit requests are marked with a replay flag, and the target route is updated in the sending queue to ensure that end-side redirection can be completed in one go. If the migration fails, the node is restored to the previous available priority according to the fallback conditions, and a downgrade flag is added for subsequent statistics.

[0089] After the decision-making and migration are completed, a cached data packet is generated. This cached data packet encapsulates the fault recovery status, exception label, switchover order, and replay count using the session identifier and the new service node identifier as keys, and includes the original node identifier and cause code, forming a replayable record. This data packet is written to the distributed cache and synchronized to persistent storage. The persistent storage side includes an item number and window index for easy cross-window analysis later.

[0090] Finally, the address of the cached data packet is filled back into the read interface of step S103, so that the network response rules can directly read the latest session status and switching results when generating redirection addresses and gateway allow instructions. At the same time, the monitoring dataset and fault handling log of this round are pushed to the statistics module in summary form, which is used to update the baseline threshold and anomaly judgment boundary in subsequent windows, thereby maintaining the stability of the allow link without changing the permission criteria.

[0091] In one embodiment of the WiFi portal management method based on multi-service convergence in this application, the method may further include the following steps: Step S601: Construct response processing rules based on user session data packets, perform multi-dimensional verification of authentication status, establish a security assessment engine, generate verification benchmarks based on session validity parameters, determine access permissions by level, construct an authentication matrix, and generate a response feature set containing security level and verification results based on the authentication matrix; Step S602: Construct redirection rules based on the response feature set, map and convert access policies according to preset standards, generate allowance parameters according to gateway control requirements, configure routing policies according to redirection types, substitute the routing policies into the conversion unit, authorize user requests for access based on the calculation results, and generate an instruction dataset containing allowance instructions and routing identifiers.

[0092] First, the user session data packet generated in step S102 is read, and field verification is performed at the session identifier level to check whether the permission identifier, verification trajectory summary, and anomaly label are complete and readable. Based on the service node identifier and policy version in the same data packet, the execution environment of the response processing rules is initialized. The value of the fixed session validity period parameter is the consistent union of cached records and persistent records to avoid deviations caused by cross-source values. Then, the authentication status is expanded according to three dimensions: basic identity, session validity, and risk supplementation, forming a list to be verified and associated with a timestamp sequence.

[0093] Based on the list of sessions to be verified, a security assessment engine is established. The engine generates a verification baseline according to the session validity period parameter and performs a consistency comparison item by item, combining the access scope field in the permission identifier with the pass markers in the verification trajectory. For sessions with retry records, a time continuity check is added to prevent decision jitter at window boundaries. After completing the above verification, the three types of verification results are aligned into a unified structure, and an authentication matrix is ​​constructed within the same session scope. The rows of the matrix correspond to the verification dimensions, the columns correspond to the indicator families, and the cells record the pass markers and count information.

[0094] Based on the aforementioned authentication matrix, a response feature set is generated. The response feature set outputs paired records of security levels and verification results at the session dimension. The security level is mapped from the combination of three rows of results, and the verification result includes a pass flag, error count, and the time of the most recent judgment. The response feature set includes a policy version number and service node identifier, serving as the sole input source for the next redirection rule. A security level snapshot is also written back to the user session data packet for reference during fault recovery.

[0095] Once the response feature set is ready, redirection rules are constructed. The redirection rules read the pairing records of security level and permission identifiers, combine them with the project number and service node identifier, locate the access policy template from the policy library, and map it to the target address category and parameter range of the current session. To meet gateway control requirements, allowance parameters are generated according to the gateway's allowance interface format. These parameters include a session identifier digest, a short permission identifier string, and an expiration date indication. Specific fields distinguish whether a timestamp and routing label are required to prevent sensitive information leakage in cross-domain scenarios.

[0096] After the allowance parameters are prepared, a routing policy is configured according to the redirection type. The routing policy includes the destination address, routing identifier, and fallback order, referencing the distance priority coefficient and alternative order field output in step S202 to ensure consistency with the nearest access point. The allowance parameters and routing policy are then substituted into the conversion unit. The conversion unit determines the parameter encoding method and field arrangement order based on the policy version and generates an instruction structure that can be directly consumed by the gateway. The structure retains the target node identifier and policy timestamp for subsequent auditing.

[0097] Based on the aforementioned conversion results, access authorization is granted to user requests. The authorization process first performs a quick check of the session state to confirm that the session is still valid and the permission identifier has not been revoked, and then writes the instruction structure into the pending queue. For sessions in an abnormal observation state, the original redirection type is retained but the fallback threshold is lowered to improve the success rate when the network is unstable. After authorization is completed, the instruction number and target route identifier are recorded in the user session data packet to provide a location basis for subsequent receipts and recovery.

[0098] After the authorization action is executed, an instruction dataset is generated. The instruction dataset uses the session identifier as the primary key, encapsulates the allowance instruction and route identifier, and includes a security level snapshot, allowance parameter summary, and policy version number. This dataset is written to a distributed cache and a location index is synchronously persisted for further reading in step S103 to complete sending and writing back, while also providing a unified entry point for anomaly detection and session recovery. For subsequent requests within the same session, if the instruction dataset is still valid and the target route has not changed, it can be directly reused, reducing link disturbances caused by repeated calculations.

[0099] In one embodiment of the WiFi portal management method based on multi-service convergence in this application, the method may further include the following steps: Step S701: Constructing access monitoring rules based on an anomaly detection model, collecting gateway response status in real time, establishing a session tracking engine, generating monitoring thresholds based on access delay parameters, extracting features from access interruption events, constructing a fault judgment matrix, and generating a monitoring dataset containing access status and anomaly type based on the fault judgment matrix; Step S702: Constructing recovery processing rules based on the monitoring dataset, verifying the integrity of session status according to preset standards, generating recovery strategies according to service continuity requirements, configuring reconstruction parameters according to session type, substituting the reconstruction parameters into the processing unit, restoring the user session status based on the execution result, and generating a response data packet containing redirection address and session identifier.

[0100] First, the instruction dataset and user session data packets output in step S602 are read and aligned at the session identifier dimension. The target route identifier, allowance parameter digest, and security level snapshot are then obtained. The execution environment for the allowance monitoring rules is initialized based on the same index. The values ​​for the allowance delay parameter and receipt format are determined to be the union of the gateway interface definition and policy version, avoiding field drift between different versions. Subsequently, real-time collection of the gateway response status begins, including receipt code, first packet delay, redirection completion flag, and failure reason code.

[0101] Based on the real-time data acquisition, a session tracking engine is established. The session tracking engine maintains a state machine at the session level, recording the transition trajectories of five states: "Pending Send, Sent, Receipt Received, Redirected, and Anomaly Observation," and timestamps each transition. The engine reads the release latency parameter to generate monitoring thresholds, and combines this with security level snapshots to set threshold ranges for different levels, providing higher-level sessions with stricter latency boundaries. For access interruption events, four features are extracted: continuous timeouts, repeated receipts, unreachable destination, and redirection loops, forming standardized event description fragments.

[0102] Based on the aforementioned event fragments and state machine trajectories, a fault determination matrix is ​​constructed. The rows of the matrix correspond to session time slices, and the columns correspond to metrics such as latency, receipt codes, failure reasons, and state transition counts. The cells record whether the trigger threshold was triggered and the number of triggers. The matrix is ​​scanned row by row, outputting a combination of allowance status and exception type to form a monitoring dataset. The monitoring dataset uses the session identifier as the primary key, and the fields include allowance status label, exception type label, most recent trigger time, and target route identifier, along with a policy version number, which serves as input for subsequent recovery processing rules.

[0103] Once the monitoring dataset is ready, recovery processing rules are constructed. The recovery processing rules first perform an integrity check on the session state, including whether the permission identifier is still valid, whether the command number matches, whether the target route exists, and whether the cache pointer is readable. If any items are missing, they are filled in and the reason is recorded. Subsequently, a recovery strategy is generated based on business continuity requirements. The strategy includes three items: target replacement priority, retry interval category, and whether route degradation is required. It also references the alternative priority and distance priority coefficients output in step S202, maintaining consistency with the nearest access point.

[0104] Based on the aforementioned recovery strategy, reconstruction parameters are configured according to session type. For mobile terminal sessions, lightweight parameters are prioritized and cross-domain redirects are reduced; for fixed terminal sessions, full route identifiers are allowed to shorten the reconstruction path. Reconstruction parameters include the maximum number of session replays, cache read location, permission identifier inheritance flag, and timestamp retention flag, and a mapping relationship is established with the exception type, so that "target unreachable" triggers route replacement first, and "duplicate receipt" triggers instruction recoding first.

[0105] After the reconstruction parameters are configured, they are fed into the processing unit for recovery. The processing unit first selects a recovery branch based on the exception type, then performs target replacement or recoding according to the recovery strategy, generates a new redirection address and instruction number, and updates the session state machine to "reconstructed". If the current execution still triggers the monitoring threshold, it proceeds to the next step according to the rollback conditions in the recovery strategy, until the maximum number of replays is reached or a success receipt is received. Each attempt records the reason code and target node identifier, forming a replayable execution trajectory.

[0106] After the recovery process is complete, a response data packet is generated. The response data packet uses the session identifier as the primary key and encapsulates the latest redirect address, target route identifier, permission identifier digest, and exception handling digest. It also includes the cache location and persistent record number for subsequent statistics and diagnostics. For sessions that have undergone multiple recoveries, the recovery count and the last successful target node are additionally recorded for subsequent window update thresholds and priority adjustments.

[0107] Finally, the response data packet is submitted to the network response sending channel, and the final labels of the release status and exception type are written back to the user session data packet and command dataset. The write-back includes final status markers for both successful and failed paths, which are read by the sending receipt and statistics module in step S103. Simultaneously, the monitoring dataset and recovery log summary for this round are synchronized to the analysis module, providing a basis for the monitoring threshold, adaptive retry interval, and priority adjustment in the next window. Through this connection, release monitoring and session recovery operate in a closed loop under the same session index, maintaining parameter consistency with the preceding scheduling and authentication stages.

[0108] To effectively address the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, and to provide technical support for WiFi portal management, this application provides an embodiment of a WiFi portal management device based on multi-service convergence for implementing all or part of the aforementioned WiFi portal management method based on multi-service convergence. Referring to Figure 2, the WiFi portal management device based on multi-service convergence specifically includes the following components: a load calculation module 10, used to acquire access request data streams initiated by user terminals, perform nearest-neighbor access scheduling through content delivery network edge nodes, construct weight calculation rules based on service node load status, calculate a load score by combining processing capacity indicators and connection number thresholds, distribute the access request data streams according to the load score, parse user agent identifiers to obtain terminal feature vectors, and generate multi-level authentication request data based on the terminal feature vectors; request authentication. Module 20 is used to construct hierarchical verification rules based on the multi-level authentication request data, generate user encryption factors according to the global key, calculate the authentication feature matrix by combining the encryption factors with the user password, generate access permission identifiers according to the authentication feature matrix, construct an anomaly detection model to monitor the authentication process, identify anomalies according to the anomaly detection model and trigger node switching, write the access permission identifiers into the distributed cache system and perform persistent storage, and generate user session data packets containing authentication status. Gateway access module 30 is used to construct network response rules based on the user session data packets, perform multi-level authentication verification, determine redirection policies according to the authentication security level, map the redirection policies to gateway access instructions, determine access anomalies based on the anomaly detection model and perform session recovery, generate response data containing redirection addresses, and send the response data to the user terminal to complete wireless network access authentication.

[0109] As described above, the WiFi portal management device based on multi-service convergence provided in this application embodiment can achieve effective resource allocation through innovative access scheduling system design, load assessment, and feature extraction. It constructs an authentication processing mechanism, combining multi-level verification and anomaly detection to establish a reliable security policy. Furthermore, it introduces response management, ensuring access continuity through access control and session recovery. This method effectively addresses the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management.

[0110] From a hardware perspective, in order to effectively address the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, and to provide technical support for WiFi portal management, this application provides an embodiment of an electronic device for implementing all or part of the aforementioned WiFi portal management method based on multi-service convergence. The electronic device specifically includes the following components: a processor, memory, a communication interface, and a bus. The processor, memory, and communication interface communicate with each other via the bus. The communication interface is used to realize information transmission between the WiFi portal management device based on multi-service convergence and core business systems, user terminals, and related databases. The logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the WiFi portal management method based on multi-service convergence and the embodiments of the WiFi portal management device based on multi-service convergence described in the embodiments; their contents are incorporated herein, and repeated details are not repeated.

[0111] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0112] In practical applications, some parts of the WiFi portal management method based on multi-service convergence can be executed on the electronic device side as described above, or all operations can be completed in the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed in the client device, the client device may further include a processor.

[0113] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0114] Figure 3 is a schematic block diagram of the system configuration of an electronic device 9600 according to an embodiment of this application. As shown in Figure 3, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that Figure 3 is exemplary; other types of structures may also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0115] In one embodiment, the WiFi portal management method based on multi-service convergence can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following control: Step S101: Acquire the access request data stream initiated by the user terminal, perform nearest access scheduling through the content delivery network edge node, construct weight calculation rules based on the service node load status, calculate the load score by combining the processing capacity index and the connection number threshold, distribute the access request data stream according to the load score, parse the user agent identifier to obtain the terminal feature vector, and generate multi-level authentication request data based on the terminal feature vector; Step S102: Construct hierarchical verification rules based on the multi-level authentication request data, generate a user encryption factor based on the global key, and calculate the authentication feature by combining the encryption factor and the user password. The authentication feature matrix is ​​used to generate access permission identifiers. An anomaly detection model is constructed to monitor the authentication process. Anomalies are identified and node switching is triggered based on the anomaly detection model. The access permission identifiers are written into a distributed cache system and persistently stored. A user session data packet containing the authentication status is generated. Step S103: Based on the user session data packet, network response rules are constructed, multi-level authentication verification is performed, a redirection policy is determined according to the authentication security level, the redirection policy is mapped to a gateway allow command, an anomaly is judged based on the anomaly detection model and session recovery is performed, response data containing the redirection address is generated, and the response data is sent to the user terminal to complete the wireless network access authentication.

[0116] As described above, the electronic device provided in this application embodiment achieves effective resource allocation through an innovative access scheduling system design, load assessment, and feature extraction. It constructs an authentication processing mechanism, combining multi-level verification and anomaly detection to establish a reliable security policy. Furthermore, it introduces response management, ensuring access continuity through access control and session recovery. This method effectively addresses the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management.

[0117] In another embodiment, the WiFi portal management device based on multi-service convergence can be configured separately from the central processing unit 9100. For example, the WiFi portal management device based on multi-service convergence can be configured as a chip connected to the central processing unit 9100, and the WiFi portal management method function based on multi-service convergence can be implemented through the control of the central processing unit.

[0118] As shown in Figure 3, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily include all the components shown in Figure 3; furthermore, the electronic device 9600 may also include components not shown in Figure 3, as can be found in existing technologies.

[0119] As shown in Figure 3, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device. The central processing unit 9100 receives input and controls the operation of various components of the electronic device 9600.

[0120] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0121] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0122] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0123] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0124] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0125] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.

[0126] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the WiFi portal management method based on multi-service convergence, where the execution subject is a server or client, as described in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the WiFi portal management method based on multi-service convergence, where the execution subject is a server or client, as described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Step S101: Obtain the access request data stream initiated by the user terminal; perform nearest-access scheduling through the edge node of the content delivery network; construct weight calculation rules based on the service node load status; calculate the load score by combining the processing capacity index and the connection number threshold; distribute the access request data stream according to the load score; parse the user agent identifier to obtain the terminal feature vector; and based on the terminal feature vector... Step S102: Based on the multi-level authentication request data, construct hierarchical verification rules, generate user encryption factors according to the global key, calculate the authentication feature matrix by combining the encryption factors with the user password, generate access permission identifiers according to the authentication feature matrix, construct an anomaly detection model to monitor the authentication process, identify anomalies according to the anomaly detection model and trigger node switching, write the access permission identifiers into the distributed cache system and perform persistent storage, and generate user session data packets containing authentication status; Step S103: Based on the user session data packets, construct network response rules, perform multi-level authentication verification, determine the redirection policy according to the authentication security level, map the redirection policy to the gateway allow command, judge the allowance anomaly based on the anomaly detection model and perform session recovery, generate response data containing the redirection address, and send the response data to the user terminal to complete wireless network access authentication.

[0127] As described above, the computer-readable storage medium provided in this application embodiment achieves efficient resource allocation through an innovative access scheduling system design, load assessment, and feature extraction. It constructs an authentication processing mechanism, combining multi-level verification and anomaly detection to establish a reliable security policy. Furthermore, it introduces response management, ensuring access continuity through access control and session recovery. This method effectively addresses the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management.

[0128] This application also provides a computer program product capable of implementing all steps of the WiFi portal management method based on multi-service convergence, where the execution subject is a server or client, as described in the above embodiments. When executed by a processor, this computer program / instruction implements the steps of the WiFi portal management method based on multi-service convergence. For example, the computer program / instruction implements the following steps: Step S101: Obtain the access request data stream initiated by the user terminal, perform nearest access scheduling through the edge node of the content delivery network, construct weight calculation rules based on the load status of the service node, calculate the load score by combining the processing capacity index and the connection number threshold, distribute the access request data stream according to the load score, parse the user agent identifier to obtain the terminal feature vector, and generate multi-level authentication request data based on the terminal feature vector; Step S102: Based on the... The process involves: constructing hierarchical verification rules based on multi-level authentication request data; generating user encryption factors based on a global key; calculating an authentication feature matrix using the encryption factors and the user password; generating access permission identifiers based on the authentication feature matrix; constructing an anomaly detection model to monitor the authentication process; identifying anomalies and triggering node switching based on the anomaly detection model; writing the access permission identifiers into a distributed cache system and performing persistent storage; and generating user session data packets containing authentication status. Step S103: Constructing network response rules based on the user session data packets; performing multi-level authentication verification; determining a redirection strategy based on the authentication security level; mapping the redirection strategy to a gateway permission instruction; judging permission exceptions based on the anomaly detection model and performing session recovery; generating response data containing the redirection address; and sending the response data to the user terminal to complete wireless network access authentication.

[0129] As described above, the computer program product provided in this application, through an innovative access scheduling system design, achieves effective resource allocation through load assessment and feature extraction. It constructs an authentication processing mechanism, combining multi-level verification and anomaly detection to establish a reliable security policy. Furthermore, it introduces response management, ensuring access continuity through access control and session recovery. This method effectively addresses the shortcomings of traditional technologies in access scheduling, authentication processing, and response management, providing technical support for WiFi portal management.

[0130] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0131] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0132] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0133] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0134] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A WiFi portal management method based on multi-service convergence, characterized in that, The method includes: acquiring an access request data stream initiated by a user terminal; performing nearest access scheduling through edge nodes of a content delivery network; constructing weight calculation rules based on the load status of service nodes; calculating a load score by combining processing capacity indicators with connection number thresholds; distributing the access request data stream according to the load score; parsing the user agent identifier to obtain a terminal feature vector; generating multi-level authentication request data based on the terminal feature vector; constructing hierarchical verification rules based on the multi-level authentication request data; generating a user encryption factor based on a global key; calculating an authentication feature matrix by combining the encryption factor with the user password; generating an access permission identifier based on the authentication feature matrix; constructing an anomaly detection model to monitor the authentication process; identifying anomalies and triggering node switching based on the anomaly detection model; writing the access permission identifier into a distributed cache system and performing persistent storage; generating a user session data packet containing the authentication status; constructing network response rules based on the user session data packet; performing multi-level authentication verification; determining a redirection strategy based on the authentication security level; mapping the redirection strategy to a gateway allow command; judging an allowance anomaly based on the anomaly detection model and performing session recovery; generating response data containing the redirection address; and sending the response data to the user terminal to complete wireless network access authentication.

2. The WiFi portal management method based on multi-service convergence according to claim 1, characterized in that, The process of acquiring access request data streams initiated by user terminals, performing proximity access scheduling through edge nodes of the content delivery network, and constructing weight calculation rules based on service node load status includes: parsing network requests initiated by user terminals, extracting request header identification information, establishing a terminal address mapping table, constructing a network topology distance matrix based on the physical location of the terminal, performing status detection on edge nodes of the content delivery network, constructing a node availability index set, generating scheduling basic data containing node load status and geographical distribution based on the availability index set; constructing proximity access rules based on the scheduling basic data, quantifying node processing capacity parameters according to preset standards, generating dynamic thresholds according to load balancing requirements, configuring priority coefficients according to network topology distance, substituting the priority coefficients into the calculation unit, allocating nodes to access requests based on the calculation results, and generating a scheduling dataset containing service node identifiers and load status.

3. The WiFi portal management method based on multi-service convergence according to claim 1, characterized in that, The process of calculating a load score by combining processing capacity metrics and connection number thresholds, distributing the access request data stream based on the load score, parsing the user agent identifier to obtain a terminal feature vector, and generating multi-level authentication request data based on the terminal feature vector includes: constructing load calculation rules based on processing capacity metrics, performing real-time statistics on the number of service node connections, establishing a load assessment model, generating performance parameters based on processing resource utilization, sampling and analyzing node response latency, constructing a performance curve matrix, generating a load feature set containing resource utilization and connection data based on the performance curve matrix; constructing distribution control rules based on the load feature set, quantifying and assigning node performance metrics according to preset weights, generating a dynamic threshold based on the connection number upper limit, configuring scheduling parameters according to load balancing requirements, substituting the scheduling parameters into the load matrix, distributing and allocating the request data stream according to the calculation results, and generating an authentication dataset containing user agent identifiers and terminal features.

4. The WiFi portal management method based on multi-service convergence according to claim 1, characterized in that, The process of constructing hierarchical verification rules based on the multi-level authentication request data, generating user encryption factors based on the global key, calculating an authentication feature matrix using the encryption factors and user passwords, and generating access permission identifiers based on the authentication feature matrix includes: constructing a security parameter table based on the multi-level authentication request data, obtaining global key parameters from the configuration center, establishing an encryption rule engine, generating random salt values ​​based on user identity identifiers, obfuscating key parameters, constructing a security calculation matrix, generating a security feature set containing user-specific encryption factors and verification markers based on the security calculation matrix; constructing authentication processing rules based on the security feature set, hashing user password data according to preset standards, generating verification parameters according to security level requirements, configuring feature mappings according to encryption rules, substituting the verification parameters into the calculation unit, hierarchically marking user permissions based on the calculation results, and generating an access permission dataset containing authentication features and access levels.

5. The WiFi portal management method based on multi-service convergence according to claim 1, characterized in that, The anomaly detection model is constructed to monitor the authentication process. Anomalies are identified and node switching is triggered based on the anomaly detection model. The permission identifier is written to the distributed cache system and persistently stored. A user session data packet containing the authentication status is generated. This includes: constructing monitoring rules based on authentication process data; collecting service node status in real time; establishing an anomaly identification engine; generating a baseline threshold based on response latency parameters; statistically analyzing the frequency of authentication failure events; constructing a status evaluation matrix; generating a monitoring dataset containing node health and anomaly characteristics based on the status evaluation matrix; constructing fault handling rules based on the monitoring dataset; classifying and categorizing abnormal events according to preset standards; generating a switching strategy based on system disaster recovery requirements; configuring backup parameters according to node status; substituting the backup parameters into the decision unit; migrating the authentication request node based on the judgment result; and generating a cached data packet containing fault recovery and session status.

6. The WiFi portal management method based on multi-service convergence according to claim 1, characterized in that, The process of constructing network response rules based on the user session data packets, performing multi-level authentication verification, determining redirection policies according to authentication security levels, and mapping the redirection policies to gateway access instructions includes: constructing response processing rules based on user session data packets, performing multi-dimensional verification of authentication status, establishing a security assessment engine, generating verification benchmarks based on session validity parameters, determining access permission levels, constructing an authentication matrix, generating a response feature set containing security levels and verification results based on the authentication matrix; constructing redirection rules based on the response feature set, mapping and converting access policies according to preset standards, generating access parameters according to gateway control requirements, configuring routing policies according to redirection types, substituting the routing policies into the conversion unit, authorizing user requests for access based on the calculation results, and generating an instruction dataset containing access instructions and routing identifiers.

7. The WiFi portal management method based on multi-service convergence according to claim 1, characterized in that, The process of determining anomalies based on the anomaly detection model, performing session recovery, generating response data containing redirection addresses, and sending the response data to the user terminal to complete wireless network access authentication includes: constructing access monitoring rules based on the anomaly detection model, collecting gateway response status in real time, establishing a session tracking engine, generating monitoring thresholds based on access delay parameters, extracting features from access interruption events, constructing a fault determination matrix, and generating a monitoring dataset containing access status and anomaly type based on the fault determination matrix; constructing recovery processing rules based on the monitoring dataset, performing integrity verification on session status according to preset standards, generating recovery strategies according to business continuity requirements, configuring reconstruction parameters according to session type, substituting the reconstruction parameters into the processing unit, restoring the user session status based on the execution result, and generating a response data packet containing redirection addresses and session identifiers.

8. A WiFi portal management device based on multi-service convergence, characterized in that, The apparatus includes: a load calculation module, used to acquire access request data streams initiated by user terminals, perform nearest access scheduling through edge nodes of the content delivery network, construct weight calculation rules based on the load status of service nodes, calculate a load score by combining processing capacity indicators and connection number thresholds, distribute the access request data streams according to the load score, parse user agent identifiers to obtain terminal feature vectors, and generate multi-level authentication request data based on the terminal feature vectors; and a request authentication module, used to construct hierarchical verification rules based on the multi-level authentication request data, generate user encryption factors based on a global key, calculate an authentication feature matrix by combining the encryption factors and user passwords, and generate authentication feature matrix according to the authentication feature matrix. The authentication feature matrix generates an access permission identifier, an anomaly detection model is constructed to monitor the authentication process, anomalies are identified based on the anomaly detection model and node switching is triggered, the access permission identifier is written into a distributed cache system and persistently stored, and a user session data packet containing the authentication status is generated. The gateway access module is used to construct network response rules based on the user session data packet, perform multi-level authentication verification, determine a redirection policy based on the authentication security level, map the redirection policy to a gateway allow command, determine an allowance anomaly based on the anomaly detection model and perform session recovery, generate response data containing the redirection address, and send the response data to the user terminal to complete the wireless network access authentication.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the WiFi portal management method based on multi-service convergence as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the WiFi portal management method based on multi-service convergence as described in any one of claims 1 to 7.

Images