A radius server authorization method, device and medium

Abstract

The application relates to the field of communication, in particular to a RADIUS server authorization method and device and medium. The method comprises the following steps: calculating a pre-off-line time of a user based on an authentication time of the user and a first authorization time length; judging whether the pre-off-line time is in a busy period in at least one preset period; the first authorization time length is an authorization time length of the system pre-configured for the user, and the preset period comprises the busy period and an idle period; if the pre-off-line time is not in the busy period in any preset period, the first authorization time length is authorized to the user; if the pre-off-line time is in the busy period in a first preset period, a second authorization time length is calculated based on the idle period included in the first preset period, and the second authorization time length is authorized to the user after being combined with the first authorization time length; and the first preset period is included in the at least one preset period. The method can balance the load of the RADIUS server.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication, and in particular to a RADIUS server authorization method, device and medium. BACKGROUND

[0002] Currently, the authentication methods used by telecom operators and network service providers for users mainly include local authentication, RADIUS authentication and no authentication. In actual application, the RADIUS authentication method is most widely used. This authentication method obtains user information through a network attached storage (NAS), and a RADIUS server authenticates the user and issues an authorization duration to the user who has passed the authentication. In the prior art, the authorization duration issued by the RADIUS server to the user is mostly a fixed value. After the authorization duration is consumed, the user needs to re-authenticate and re-authorize through the RADIUS server. However, with the increase in the number of users, the authorization method in the prior art will cause uneven work pressure of the RADIUS server. SUMMARY

[0003] The present application provides a RADIUS server authorization method, device and medium, which can balance the work pressure of the RADIUS server and solve the problem of uneven work pressure of the RADIUS server in the prior art.

[0004] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0005] In a first aspect, the present application provides a RADIUS server authorization method, which comprises: calculating a pre-off-line time of a user based on an authentication time of the user and a first authorization duration;

[0006] determining whether the pre-off-line time is in a busy period in at least one preset period; the first authorization duration is an authorization duration pre-configured by a system for the user, and the preset period includes a busy period and an idle period;

[0007] if the pre-off-line time is not in the busy period in any preset period, the first authorization duration is authorized to the user;

[0008] if the pre-off-line time is in the busy period in a first preset period, a second authorization duration is calculated based on an idle period included in the first preset period, and the second authorization duration is combined with the first authorization duration and then authorized to the user; the first preset period is included in the at least one preset period.

[0009] As a possible implementation manner of the first aspect of the present application, the second authorization duration is calculated based on the idle period included in the first preset period, which comprises:

[0010] The time point is randomly selected from the idle period, and a second authorization duration is determined based on the time point and the pre-off-line time.

[0011] As a possible implementation of the first aspect of the application, the second authorization duration is determined based on the time point and the pre-off-line time, including:

[0012] A first calculation duration is obtained by calculating a duration from the time point to a first preset time point;

[0013] A second calculation duration is obtained by calculating a duration from the pre-off-line time to the first preset time point;

[0014] A third calculation duration is obtained by calculating a duration from the pre-off-line time to a second preset time point; and it is determined whether the time point is later than an end time of the busy period at the pre-off-line time;

[0015] If the time point is later than the end time of the busy period at the pre-off-line time, the second authorization duration is equal to the first calculation duration minus the second calculation duration;

[0016] If the time point is not later than the end time of the busy period at the pre-off-line time, the second authorization duration is equal to the third calculation duration plus the first calculation duration.

[0017] As a possible implementation of the first aspect of the application, the method further includes:

[0018] At least one preset period is obtained according to at least one of historical service conditions and historical load conditions of the RADIUS server; a duration of a busy period in the preset period is less than a duration of an idle period in the preset period.

[0019] In a second aspect, the application provides a RADIUS server authorization device, which includes:

[0020] A processing unit is configured to calculate a pre-off-line time of a user based on an authentication time of the user and a first authorization duration;

[0021] The processing unit is further configured to determine whether the pre-off-line time is in a busy period in at least one preset period; the first authorization duration is an authorization duration of the system pre-configured for the user; and the preset period includes the busy period and an idle period.

[0022] A communication unit is configured to authorize the user with the first authorization duration if the pre-off-line time is not in the busy period in any preset period;

[0023] The communication unit is further configured to calculate a second authorization duration based on an idle period included in a first preset period if the pre-off-line time is in the busy period in the first preset period; and to authorize the user with the second authorization duration combined with the first authorization duration; the first preset period is included in the at least one preset period.

[0024] As a possible implementation manner of the second aspect of the present application, the second authorization duration is calculated based on the idle time period included in the first preset time period, including:

[0025] a time point is randomly selected from the idle time period, and the second authorization duration is determined based on the time point and the pre-off-line time.

[0026] As a possible implementation manner of the second aspect of the present application, the second authorization duration is determined based on the time point and the pre-off-line time, including:

[0027] a first calculation duration is calculated, which is a duration from the time point to the first preset time point;

[0028] a second calculation duration is calculated, which is a duration from the pre-off-line time to the first preset time point;

[0029] a third calculation duration is calculated, which is a duration from the pre-off-line time to the second preset time point; and it is determined whether the time point is later than the end time of the busy time period at the pre-off-line time;

[0030] if the time point is later than the end time of the busy time period at the pre-off-line time, the second authorization duration is equal to the first calculation duration minus the second calculation duration;

[0031] if the time point is not later than the end time of the busy time period at the pre-off-line time, the second authorization duration is equal to the third calculation duration plus the first calculation duration.

[0032] As a possible implementation manner of the second aspect of the present application, the processing unit is further configured to obtain at least one preset time period according to at least one of historical service conditions and historical load conditions of the RADIUS server; a duration of the busy time period in the preset time period is less than a duration of the idle time period in the preset time period.

[0033] In a third aspect, the present application provides a RADIUS server authorization device, which comprises a processor and a communication interface; the communication interface is coupled with the processor, and the processor is configured to run computer programs or instructions to implement the RADIUS server authorization method as described in the first aspect and any possible implementation manner of the first aspect.

[0034] In a fourth aspect, the present application provides a computer readable storage medium, which stores instructions, when the instructions are run on a terminal, the terminal executes the RADIUS server authorization method as described in the first aspect and any possible implementation manner of the first aspect.

[0035] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a RADIUS server authorization device, cause the RADIUS server authorization device to perform the RADIUS server authorization method as described in the first aspect and any possible implementation thereof.

[0036] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run computer programs or instructions to implement the RADIUS server authorization method as described in the first aspect and any possible implementation thereof.

[0037] Specifically, the chip provided in this application embodiment also includes a memory for storing computer programs or instructions.

[0038] The technical solution provided in this application brings at least the following beneficial effects: This application adjusts the authorized duration of the RADIUS server based on a preset time period, which can adjust the offline time of some users to the off-peak time when the RADIUS server is under less processing pressure, thereby balancing the workload of the RADIUS server and rationally distributing the load of the RADIUS server. Attached Figure Description

[0039] Figure 1 A schematic diagram of an AAA system architecture provided for an embodiment of this application;

[0040] Figure 2 A flowchart illustrating a RADIUS server authorization method provided in an embodiment of this application;

[0041] Figure 3 Historical service distribution diagram of the RADIUS server provided in this application embodiment;

[0042] Figure 4 A schematic diagram of a RADIUS server authorization method provided in an embodiment of this application;

[0043] Figure 5 A schematic diagram of a RADIUS server authorization device provided in an embodiment of this application;

[0044] Figure 6 A schematic diagram of another RADIUS server authorization device provided in this application embodiment;

[0045] Figure 7 This is a schematic diagram of a chip structure provided in an embodiment of this application. Detailed Implementation

[0046] The RADIUS server authorization method and apparatus provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0047] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0048] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0049] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0050] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0051] The following explains some of the related terms and technologies involved in the embodiments of this application.

[0052] 1) AAA and AAA system

[0053] AAA stands for Authentication, Authorization, and Accounting. It is a security management mechanism for access control in network security, providing three security services: authentication, authorization, and accounting.

[0054] Specifically, the three security services provided by AAA are:

[0055] Authentication: This involves verifying a user's identity to determine whether they are a legitimate user.

[0056] Authorization: This refers to granting authorized users the right to use certain services.

[0057] Billing: This involves recording the resources a user uses to access network services; this information serves as the basis for billing.

[0058] First, the authentication section provides user authentication. The entire authentication process typically involves the user entering a username and password for permission verification. The principle behind authentication is that each user has a unique permission acquisition standard. The AAA server compares the user's standard with the standard for each user in the database. If they match, the user is authenticated. If they do not match, network connection is denied.

[0059] Secondly, users need authorization to gain permission to perform corresponding tasks. For example, after logging into the system, a user might execute commands to perform actions. At this point, the authorization process checks whether the user has the permission to execute these commands. Simply put, the authorization process is a combination of a series of enforcement policies, including: determining the type or quality of activity, resources, or services the user is allowed to access. The authorization process occurs within the authentication context; once a user is authenticated, they are granted the corresponding permissions.

[0060] Finally, the billing process calculates the amount of resources consumed by the user during the connection. These resources include connection time or the user's data transmission and reception during the connection. The billing process can be performed based on connection statistics logs, user information, authorization controls, billing, trend analysis, resource utilization, and capacity planning activities.

[0061] An AAA system is a system that implements AAA functions. The main protocols for implementing authentication, authorization, and accounting applications on an AAA system include RADIUS and TACACS+, while the Diameter protocol, as a new standard, is gradually being adopted. For details on the RADIUS protocol, see standards RFC 2865 and RFC 2866. TACACS+ enhances the functionality of the TACACS protocol (RFC 1492). For details on the Diameter protocol, see RFC 3588 and RFC 4006.

[0062] 2) RADIUS and RADIUS server

[0063] RADIUS (Remote Authentication Dial-In User Server) is a distributed, client / server architecture information exchange protocol defined by standards RFC2865 and RFC2866. It can protect the network from interference by unauthorized access and is often used in various network environments that require high security but also allow remote user access.

[0064] A RADIUS server is a protocol server that transmits authentication, authorization, and configuration information between Network Attached Storage (NAS) and shared authentication servers. RADIUS uses UDP as its transport protocol. Additionally, RADIUS is responsible for transmitting billing information between network access servers and shared accounting servers. The RADIUS server stores a large amount of information, which the NAS does not need to store; instead, it accesses this information through the RADIUS protocol. This centralized storage of information makes management more convenient and secure. The RADIUS server can act as a proxy, communicating with other RADIUS servers or other types of authentication servers as a client. User roaming is typically achieved through a RADIUS proxy.

[0065] Figure 1 An exemplary AAA system architecture diagram is disclosed, which adopts a typical client / server structure; it includes: multiple users 100 (only one is shown in the diagram), multiple NAS 101 (only one is shown in the diagram), and multiple RADIUS servers 102 (only one is shown in the diagram). The AAA program running on the NAS 101 is the server side from the user's perspective and the client side from the RADIUS server 102. The NAS 101 is responsible for transmitting user information to the designated RADIUS server 102, and then processing it accordingly based on the information returned by the RADIUS server 102. The RADIUS server 102 stores a large amount of information, including user information, NAS information, authorization attribute information, etc. It should be noted that... Figure 1 This is merely a schematic diagram illustrating a scenario in which this application may be used, and does not constitute a limitation on the applicable scenarios of the technical solutions provided in this application.

[0066] An exemplary AAA system operates as follows: When user 100 wants to log in to the network, NAS 101 provides a user login interface that requires user 100 to provide user information (username and password), and user 100 waits for the authentication result.

[0067] After receiving the user information, NAS101 sends an access request packet to RADIUS server 102. The packet contains some RADIUS related attributes: username, user password, access server ID, and access port ID.

[0068] After receiving an access request packet from the NAS, RADIUS server 102 first verifies whether the shared key of NAS101 matches the one set by the RADIUS server to determine if NAS101 is the RADIUS client it belongs to. After verifying that the access request packet sent by NAS101 is correct, RADIUS server 102 queries the user database to see if the user exists. If the user information is incorrect, RADIUS server 102 sends an access rejection packet to NAS101. Upon receiving the packet, NAS101 rejects and terminates the service request from user 100 and forcibly logs user 100 out of the system.

[0069] If the queried user information is correct, RADIUS server 102 will send an access-challenge packet to NAS101 to further verify user 100's login request. This verification includes: username, password, IP address of the server accessed by user 100, and physical port number of user 100's login. After receiving the access-request packet, NAS101 will notify user 100 to provide more user information and request further confirmation of the login request. After user 100 confirms, RADIUS server 102 will compare the two request information and then decide how to respond to the request (send access-accept, access-reject, or send access-challenge again). When all verification conditions and handshakes are passed, RADIUS server 102 will put the user's configuration information from the database in an access-accept packet and return it to NAS101. NAS101 will then limit user 100's network access capabilities based on the configuration information in the packet.

[0070] Once authentication and authorization are complete, user 100 can access the network through the switch. When user 100 accesses the network, NAS 101 sends an accounting start request packet to RADIUS server 102 to notify RADIUS server 102 to start accounting. When the user logs off the network, NAS 101 sends an accounting stop packet to RADIUS server 102. RADIUS server 102 will calculate the relevant costs for user 100's network usage based on the information in the accounting packet.

[0071] RADIUS server 102 compares the user's authentication credentials reported by NAS 101 with the user credentials stored in the database. If the credentials match, user authentication is successful, and the user is granted network access. If the credentials do not match, authentication fails, and network access is denied. If authentication is successful, RADIUS server 102 issues corresponding authorizations to the user via the RADIUS protocol, such as domain name, bandwidth rate, and duration. The NAS then executes the corresponding authorization. The authorization duration issued by the RADIUS server is a crucial parameter when authorizing users, affecting user internet access perception, NAS resource allocation, and RADIUS server processing load. Users need to re-authenticate, re-authorize, and reconnect after the authorization duration expires.

[0072] Currently, RADIUS server authorization durations in existing technologies are typically either fixed values ​​or specified ranges. Fixed values ​​mean the RADIUS server allocates a fixed duration to the user based on pre-configuration; specified ranges mean the RADIUS server randomly generates a duration from the user's specified maximum and minimum internet access time based on user information. Currently, fixed-value authorization durations are widely used in RADIUS servers.

[0073] It is evident that neither a fixed authorization duration nor a specified range of authorization duration is adjustable for the RADIUS server; that is, the RADIUS server cannot determine when a user should log off. With the rapid development of network services, both of these timing methods suffer from the following drawbacks:

[0074] 1. Poor user experience: For users, both of the above authorization methods result in users being logged off due to the expiration of authorization time during peak business hours, requiring re-authentication, re-authorization, and re-login. For users with high real-time requirements (such as those engaged in live streaming or online education), re-authentication, re-authorization, and re-login severely impact their user experience and overall experience.

[0075] 2. Uneven load on the RADIUS server: The load on the RADIUS server depends mainly on the user's internet browsing habits. Statistics show that the processing pressure on the RADIUS server during peak hours is about 40% higher than that during off-peak hours. Excessive processing pressure during peak hours will affect the efficiency, performance, and lifespan of the RADIUS server.

[0076] To address the aforementioned issues, this application first provides a RADIUS server authorization method that can improve user experience and balance the RADIUS server load.

[0077] refer toFigure 2 This application provides a RADIUS server authorization method, the method comprising:

[0078] S100. Calculate the user's pre-offline time based on the user's authentication time and first authorization duration;

[0079] It is understandable that the authentication time mentioned above can be either the start time of authentication or the end time (successful authentication). For example, in Figure 1 In the AAA architecture described above, the authentication time can be: the authentication start time, i.e., the time when user 100 sends user information to NAS101; or the authentication end time, i.e., the time when RADIUS server 102 returns the access reception packet to NAS101.

[0080] The first authorization duration is the authorization duration pre-configured by the system for the user. This first authorization duration can be freely set by the telecom operator and network service provider according to actual needs; it can be a fixed value or a specified range. For example, as a specified range, the first authorization duration can be a random number between 40 and 60 hours; as a fixed value, the first authorization duration can be 40 hours, 50 hours, or 60 hours, etc., and can be adjusted by the telecom operator and network service provider according to actual usage requirements.

[0081] S200. Determine whether the pre-offline time falls within a busy period of at least one preset time period;

[0082] The aforementioned preset time periods include busy periods and idle periods. There can be multiple preset time periods or only one preset time period.

[0083] In one possible implementation, this application can obtain the at least one preset time period based on at least one of the historical service data and historical load data of the RADIUS server; wherein the duration of the busy period in the preset time period is shorter than the duration of the idle period in the preset time period. See details below. Figure 3 , Figure 3This application provides an exemplary historical service distribution diagram of a RADIUS server. The horizontal axis represents time periods, totaling 24 time periods, covering 0:00:00 to 23:59:59. It can be understood that time period 00 in the diagram corresponds to 0:00:00 to 0:59:59. The vertical axis represents service volume. As shown in the diagram, historical service scenarios can include: user-requested offline services, timeout offline services, and other services. Other services include: Lost-Carrier (sudden line anomalies causing offline) and Idle-Timeout (some devices may have idle time thresholds for users, requiring a certain period of inactivity before offline). User-requested offline services involve users actively requesting offline; timeout offline services involve the RADIUS server disconnecting users whose authorized time has expired, requiring the user to re-authenticate, authorize, and reconnect.

[0084] Understandably, the business performance of a RADIUS server in actual applications is determined by users' network usage habits. Since the number of RADIUS server users is relatively large and the users are relatively fixed, from a macro perspective, the habits of RADIUS server users are also relatively fixed. The replacement of a small number of users will not change the user habits of the RADIUS server at the macro level.

[0085] from Figure 3 As can be seen, peak traffic is concentrated in the 8:00 and 9:00 hours, while historically, traffic in the 1:00 and 2:00 hours is relatively low. From... Figure 3 As can be seen from the data, during the periods when the aforementioned business peaks are concentrated, user requests to shut down services are quite heavy. Therefore, this application can... Figure 3 The historical business data shown indicates a first preset time period; wherein, the first preset time period includes the 08 time period and the 01 time period; wherein, the busy time period in the first preset time period includes the 08 time period; and the idle time period includes the 01 time period.

[0086] Meanwhile, as can be seen from the graph, the timeout and shutdown of services in the historical business of the RADIUS server are distributed relatively evenly and almost consistently. This indicates that among the users managed by the RADIUS server, there are a certain number of users whose usage habits are: after consuming the authorized time provided by the RADIUS server, the RADIUS server will shut them down, and they will not actively request to shut down services.

[0087] S300. If the scheduled offline time does not fall within any of the busy periods in the preset time slots, then the first authorized duration will be granted to the user;

[0088] S400. If the scheduled offline time falls within a busy period of the first preset time period, the second authorized duration is calculated based on the idle period included in the first preset time period, and the second authorized duration is combined with the first authorized duration and then authorized to the user; the first preset time period is included in at least one preset time period.

[0089] This application adjusts the authorization duration of the RADIUS server based on preset time periods, which can adjust the offline time of users who have timed out to during off-peak hours when the RADIUS server is under less processing pressure, thus balancing the RADIUS server load. For users with high real-time requirements, the technical solution provided in this application can reduce the timeouts caused by the exhaustion of authorization time during busy periods, thereby improving the user experience and perception.

[0090] In one possible implementation, the calculation of the second authorized duration based on the idle time period included in the first preset time period includes:

[0091] Randomly select a time point from the off-peak period, and determine the second authorized duration based on the time point and the pre-offline time.

[0092] In one possible implementation, determining the second authorized duration based on a time point and a pre-offline time includes:

[0093] The duration from the calculated time point to the first preset time point is obtained to obtain the first calculation duration;

[0094] Calculate the time from the pre-offline time to the first preset time point to obtain the second calculation time;

[0095] The time from the pre-offline time to the second preset time point is calculated as the third calculation time; and it is determined whether the time point is later than the end time of the busy period when the pre-offline time is expected.

[0096] The first preset time point can be 0:00:00, and the second preset time point can be 23:59:59.

[0097] If the second authorized duration is later than the scheduled offline time and falls within the end time of the busy period, then the second authorized duration is equal to the first calculated duration minus the second calculated duration.

[0098] If it is not later than the end of the busy period before the scheduled offline time, then the second authorized duration is equal to the third calculated duration plus the first calculated duration.

[0099] In one possible implementation, the method further includes:

[0100] Based on at least one of the historical business and load data of the RADIUS server, at least one preset time period is obtained; the duration of the busy period in the preset time period is shorter than the duration of the idle period in the preset time period.

[0101] The preset time period obtained based on the historical load data of the RADIUS server in a certain region is shown in Table 1:

[0102] Table 1 Preset Time Period Table

[0103]

[0104] See Figure 4 , Figure 4 This diagram illustrates the RADIUS server authorization method provided in this application. As shown, if user A successfully authenticates, the authentication time is obtained. The RADIUS server obtains user A's first authorization duration based on its configuration. For example, if the authentication time plus the first authorization duration equals 08:05:00, this time is determined to fall within the busy period of preset time period 1 in the table, which is shown as busy period 1 in the diagram. The idle period corresponding to busy period 1 is idle period 1, such as 10:00:00~12:00:00. Therefore, the second authorization duration needs to be calculated based on idle period 1.

[0105] In one possible implementation, this application obtains the start time of the idle period 1 as 10:00:00; and determines that the start time of the idle period is greater than the end time of the busy period as 09:00:00. A time point is randomly selected from the idle period 10:00:00 to 12:00:00, such as 11:30:00, and this time is then converted into duration (in seconds), i.e., 11*3600 + 30*60 + 0 = 41400 seconds. The user's pre-logout time is 08:05:00, and the duration (in seconds) until midnight is 8*3600 + 5*60 + 0 = 29100 seconds. The second authorized duration is 41400 - 29100 = 12300 seconds.

[0106] In another possible implementation, this application randomly selects a time point in the idle period 1, such as 11:30:00, and calculates the duration from that time point to 00:00:00 as 11*60*60+30*60=41400 seconds, thus obtaining the first calculation duration;

[0107] The duration from 08:05:00 to 00:00:00 is calculated as 8*3600+5*60+0=29100 seconds, yielding the second calculation duration. The duration from 08:05:00 to 23:59:59 is calculated as 15*60*60+55*60=57300 seconds, yielding the third calculation duration. In 24-hour time format without considering the date, the random time point is earlier than the end time of busy period 2, therefore the second authorized duration is equal to 41400-29100=12300 seconds.

[0108] If user B successfully authenticates, the authentication time is obtained. The RADIUS server obtains the first authorized duration of user B according to the configuration. If the authentication time plus the first authorized duration is 21:00:00, it is determined that the pre-offline time falls into the busy period of the preset time period 2 in Table 1. The figure shows the busy period period 2. The idle period corresponding to the busy period period 2 in the preset time period 2 is the idle period period 2. Then, this application can calculate the second authorized duration based on the idle period period 2.

[0109] In one possible implementation, the start time of the idle period 2 obtained by this application is 00:30:00, which, without considering the date, is earlier than the end time of the busy period, 20:00:00. The duration from the pre-offline time 21:00:00 to the current time 23:59:59 is calculated as 23:59:59 minus 21:00:00, which is 3 * 3600 = 10800 seconds. A random time point is selected from 00:30:00 to 04:30:00, for example, 00:41:55, and this time is converted to duration (in seconds), which is 41 * 60 + 55 = 2515 seconds. Therefore, the second authorized duration is: 10800 + 2515 = 13315 seconds.

[0110] In another possible implementation, this application randomly selects a time point in the idle period 2, such as 00:41:55, and calculates the duration from this time point to 00:00:00 as 41*60+55=2515 seconds, obtaining the first calculation duration; calculates the duration from 21:00:00 to 00:00:00 as 21*60*60=75600 seconds, obtaining the second calculation duration; calculates the duration from 21:00:00 to 23:59:59 as 3*3600=10800 seconds, obtaining the third calculation duration; in 24-hour time without considering the date, the above-mentioned random time point is earlier than the end time of the busy period 2, therefore the second authorized duration is equal to 10800+2515=13315 seconds.

[0111] This application analyzes users' pre-disconnection time and modifies the user's authorized duration based on the pre-disconnection time; it can adjust users who originally had to disconnect during busy hours to disconnect during off-peak hours. Based on the above analysis, it can be seen that the RADIUS server handles timeout disconnection requests relatively evenly, with a fairly uniform distribution of the workload between peak and off-peak hours. However, the RADIUS server is heavily burdened with handling user-initiated disconnections and other services during peak hours. Therefore, this application adjusts the authorization time of the RADIUS server, allowing users who would otherwise be handling timeout disconnections during peak hours to instead handle them during off-peak hours. This shifts the processing capacity of the RADIUS server from handling timeout disconnections during peak hours to handling user-initiated disconnections and other services. Based on this, this application can reduce the workload of the RADIUS server handling timeout disconnections during peak hours and transfer this workload to off-peak hours when the RADIUS server is under less pressure. This allows the RADIUS server to primarily handle user-initiated disconnections during peak hours, thereby balancing the load on the RADIUS server.

[0112] Meanwhile, by adjusting the authorization time, this application can reduce the likelihood of users with high real-time needs being disconnected by the RADIUS server due to their authorization time expiring during peak hours. Furthermore, during peak hours, these users with high real-time needs are mostly using the network, and disconnection negatively impacts their user experience and perception. Therefore, this application can adjust the timeout disconnection time for these users with high real-time needs to be shifted to off-peak hours, thereby improving their user experience and perception.

[0113] This application embodiment can divide the RADIUS server authorization device into functional modules or functional units according to the above method example. For example, each function can be divided into a separate functional module or functional unit, or two or more functions can be integrated into one processing unit. The integrated module can be implemented in hardware or in software functional modules or functional units. The module or unit division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0114] like Figure 5 As shown, this application provides a RADIUS server authorization device, which includes:

[0115] Processing unit 201 is used to calculate the user's pre-offline time based on the user's authentication time and first authorization duration;

[0116] Processing unit 201 is also used to determine whether the pre-offline time falls within a busy period of at least one preset time period; the first authorized duration is the authorized duration pre-configured by the system for the user, and the preset time period includes busy periods and idle periods;

[0117] The communication unit 202 is used to authorize the user with the first authorized duration if the pre-offline time does not fall within any busy period in the preset time period;

[0118] The communication unit 202 is further configured to calculate a second authorized duration based on the idle periods included in the first preset time period if the pre-offline time falls within a busy period in the first preset time period, and then authorize the user by merging the second authorized duration with the first authorized duration; the first preset time period is included in at least one preset time period.

[0119] As one possible implementation, the second authorized duration is calculated based on the idle time periods included in the first preset time period, including:

[0120] Randomly select a time point from the off-peak period, and determine the second authorized duration based on the time point and the pre-offline time.

[0121] As one possible implementation, the second authorization duration is determined based on a time point and a pre-offline time, including:

[0122] The duration from the calculated time point to the first preset time point is obtained to obtain the first calculation duration;

[0123] Calculate the time from the pre-offline time to the first preset time point to obtain the second calculation time;

[0124] The time from the pre-offline time to the second preset time point is calculated as the third calculation time; and it is determined whether the time point is later than the end time of the busy period when the pre-offline time is expected.

[0125] If the second authorized duration is later than the scheduled offline time and falls within the end time of the busy period, then the second authorized duration is equal to the first calculated duration minus the second calculated duration.

[0126] If it is not later than the end of the busy period before the scheduled offline time, then the second authorized duration is equal to the third calculated duration plus the first calculated duration.

[0127] As one possible implementation, the processing unit 201 is further configured to obtain at least one preset time period based on at least one of the historical business conditions and historical load conditions of the RADIUS server; the duration of the busy period in the preset time period is less than the duration of the idle period in the preset time period.

[0128] When implemented in hardware, the communication unit 202 in this embodiment can be integrated onto the communication interface, and the processing unit 201 can be integrated onto the processor. Specific implementation methods are as follows: Figure 6 As shown.

[0129] Figure 6 A schematic diagram of another possible structure of the RADIUS server authorization device involved in the above embodiments is shown. The RADIUS server authorization device includes a processor 302 and a communication interface 303. The processor 302 is used to control and manage the operation of the RADIUS server authorization device, for example, executing the steps performed by the processing unit 201, and / or performing other processes of the technology described herein. The communication interface 303 is used to support communication between the RADIUS server authorization device and other network entities, for example, executing the steps performed by the communication unit 202. The RADIUS server authorization device may also include a memory 301 and a bus 304. The memory 301 is used to store the program code and data of the RADIUS server authorization device.

[0130] The memory 301 may be a memory in a RADIUS server licensing device, and the memory may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk or solid-state drive; the memory may also include a combination of the above types of memory.

[0131] The processor 302 described above can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0132] Bus 304 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 304 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0133] Figure 7 This is a schematic diagram of the structure of chip 170 provided in an embodiment of this application. Chip 170 includes one or more (including two) processors 1710 and communication interfaces 1730.

[0134] Optionally, the chip 170 also includes a memory 1740, which may include read-only memory and random access memory, and provides operation instructions and data to the processor 1710. A portion of the memory 1740 may also include non-volatile random access memory (NVRAM).

[0135] In some implementations, memory 1740 stores elements such as execution modules or data structures, or subsets thereof, or extended sets thereof.

[0136] In this embodiment of the application, the corresponding operation is executed by calling the operation instructions stored in the memory 1740 (the operation instructions can be stored in the operating system).

[0137] The processor 1710 described above can implement or execute various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. The processor can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0138] The memory 1740 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk or solid-state drive; the memory may also include combinations of the above types of memory.

[0139] The Bus 1720 can be an Extended Industry Standard Architecture (EISA) bus, etc. The Bus 1720 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0140] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0141] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the RADIUS server authorization method in the above method embodiments.

[0142] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the RADIUS server authorization method in the method flow shown in the above method embodiments.

[0143] The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires; portable computer disks; hard disks; random access memory (RAM); read-only memory (ROM); erasable programmable read-only memory (EPROM); registers; hard disks; optical fibers; portable compact disc read-only memory (CD-ROM); optical storage devices; magnetic storage devices; or any suitable combination thereof; or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may reside in an application-specific integrated circuit (ASIC). In the embodiments of this application, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0144] Embodiments of the present invention provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform actions such as... Figure 2 , Figure 4 The RADIUS server authorization method described in [the document].

[0145] Since the RADIUS server authorization device, computer-readable storage medium, and computer program product in the embodiments of the present invention can be applied to the above method, the technical effects obtained can also be referred to the above method embodiments, and the embodiments of the present invention will not be repeated here.

[0146] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0147] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0148] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0149] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A RADIUS server authorization method, characterized in that, include: Based on at least one of the historical business and load data of the RADIUS server, at least one preset time period is obtained; The duration of the busy period in the preset time period is shorter than the duration of the idle period in the preset time period; The user's pre-offline time is calculated based on the user's authentication time and the first authorization duration; Determine whether the pre-offline time falls within a busy period of the at least one preset time period; The first authorized duration is the authorized duration pre-configured by the system for the user, and the preset time period includes busy time periods and idle time periods; If the pre-offline time does not fall within any busy period in the preset time period, then the first authorized duration will be authorized to the user; If the pre-offline time falls within a busy period of the first preset time period, a time point is randomly selected from the idle periods included in the first preset time period, and a second authorization duration is determined based on the time point and the pre-offline time; the second authorization duration is combined with the first authorization duration and then authorized to the user. The first preset time period is included in the at least one preset time period; The determination of the second authorized duration based on the time point and the pre-offline time includes: Calculate the duration from the given time point to the first preset time point to obtain the first calculation duration; Calculate the duration from the pre-offline time to the first preset time point to obtain the second calculation duration; The duration from the pre-offline time to the second preset time point is calculated as the third calculation duration; and it is determined whether the time point is later than the end time of the busy period when the pre-offline time is located. If it is later than the end time of the busy period in which the pre-offline time is located, then the second authorized duration is equal to the first calculated duration minus the second calculated duration; If it is not later than the end time of the busy period in which the pre-offline time is located, then the second authorized duration is equal to the third calculated duration plus the first calculated duration.

2. A RADIUS server authorization device, characterized in that, The device includes: The processing unit is configured to obtain at least one preset time period based on at least one of the historical business and historical load data of the RADIUS server; the duration of the busy period in the preset time period is shorter than the duration of the idle period in the preset time period. The processing unit is also used to calculate the user's pre-offline time based on the user's authentication time and the first authorization duration; The processing unit is further configured to determine whether the pre-offline time falls within a busy period of the at least one preset time period; the first authorized duration is the authorized duration pre-configured by the system for the user, and the preset time period includes busy periods and idle periods; The communication unit is configured to grant the first authorized duration to the user if the pre-offline time does not fall within a busy period of any preset time period; The communication unit is further configured to, if the pre-offline time falls within a busy period of a first preset time period, randomly select a time point from the idle periods included in the first preset time period, determine a second authorized duration based on the time point and the pre-offline time, and authorize the user by merging the second authorized duration with the first authorized duration; the first preset time period is included in the at least one preset time period; The determination of the second authorized duration based on the time point and the pre-offline time includes: Calculate the duration from the given time point to the first preset time point to obtain the first calculation duration; Calculate the duration from the pre-offline time to the first preset time point to obtain the second calculation duration; The duration from the pre-offline time to the second preset time point is calculated as the third calculation duration; and it is determined whether the time point is later than the end time of the busy period when the pre-offline time is located. If it is later than the end time of the busy period in which the pre-offline time is located, then the second authorized duration is equal to the first calculated duration minus the second calculated duration; If it is not later than the end time of the busy period in which the pre-offline time is located, then the second authorized duration is equal to the third calculated duration plus the first calculated duration.

3. A RADIUS server authorization device, characterized in that, include: A processor and a communication interface; the communication interface is coupled to the processor, the processor being configured to run computer programs or instructions to implement the method as described in claim 1.

4. A computer-readable storage medium storing instructions, characterized in that, When the computer executes the instruction, the computer performs the method described in claim 1.

Images