Network element step value adjustment method and device, equipment, and storage medium

Abstract

Embodiments of the present application provide a network element step value adjustment method and device, equipment and storage medium, the method comprises: obtaining the charging data request of a target user sent by a network element side; if it is determined that the charging data request is not the first charging data request of the target user, dynamically adjusting the current step of the target user based on the historical call record of the target user to obtain a first target step, and feeding back the first target step to the network element side, so that the network element side sends the charging data request of the target user based on the first target step. The behavior habit of the target user is obtained by analyzing the historical call record of the target user, and the current step of the target user on the network element side is dynamically adjusted according to the behavior habit of the target user, thereby avoiding the above problems caused by using a fixed step, and relieving the performance pressure of the charging system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, and in particular to a network element step value adjustment method and device, equipment and storage medium. BACKGROUND

[0002] The intelligent dynamic step technology can effectively reduce the great pressure on the business system caused by the continuous and rapid growth of user bill quantity after the operator upgrades from 4G to 5G. In the traditional 4G and 5G billing scenarios, the core network generates bills regularly and quantitatively, such as generating 1 bill every 100M of traffic used or every 1 hour. With the rapid growth of user traffic usage after the upgrade from 4G to 5G, this mode is likely to cause the business system to need to continuously invest in capacity expansion.

[0003] In the related art, the step given by the system to the network element generally adopts a fixed step. The main problem of the fixed step is that if the step is too small, the message quantity sent by the network element to the billing system will increase sharply, thereby causing the performance pressure of the billing system to increase. Therefore, only simple step setting cannot well balance the problem of bill quantity. SUMMARY

[0004] The network element step value adjustment method provided by the embodiments of the present application can analyze the behavior habits of a target user through the historical bills of the target user, and dynamically adjust the current step of the target user on the network element side according to the behavior habits of the target user, thereby avoiding the above-mentioned problems caused by the fixed step and relieving the performance pressure of the billing system.

[0005] In a first aspect, the embodiments of the present application provide a network element step value adjustment method, which comprises: acquiring a charging data request of a target user sent by a network element side; if it is determined that the charging data request is not the first charging data request of the target user, dynamically adjusting a current step of the target user based on historical bills of the target user to obtain a first target step, and feeding back the first target step to the network element side, so that the network element side sends the charging data request of the target user based on the first target step.

[0006] Further, the dynamically adjusting the current step of the target user based on the historical bills of the target user to obtain the first target step comprises: if it is determined that the sending time of the charging data request of the target user sent by the network element side falls within a target time period in the historical bills, determining a new step based on the end time of the target time period as the first target step, wherein the target time period includes a communication peak period, and the communication includes traffic usage or call; and the network element side sending the charging data request of the target user based on the first target step comprises: the network element side sending the charging data request of the target user at the end time of the target time period.

[0007] Further, the dynamically adjusting the current step length of the target user based on the historical call record of the target user to obtain a first target step length comprises: if it is determined that the sending time of the charging data request of the target user sent by the network element side falls within a target time period in the historical call record, determining a new step length based on the usage amount of the target time period traffic or the usage amount of the target time period call as the first target step length, wherein the target time period comprises a communication peak period, and the communication comprises traffic usage or call; and the sending, by the network element side, of the charging data request of the target user based on the first target step length comprises: sending, by the network element side, the charging data request of the target user after the target user uses the usage amount of the target time period traffic or the usage amount of the target time period call.

[0008] Further, after the obtaining of the charging data request of the target user sent by the network element side, the method further comprises: if it is determined that the charging data request is the first charging data request of the target user, obtaining an initial step length of the target user based on the amount base contained in the package of the target user, and feeding back the initial step length to the network element side, so that the network element side sends the charging data request of the target user based on the initial step length.

[0009] Further, the method further comprises: adjusting a current step length of the target user based on real-time amount base usage information of a package of the target user to obtain a second target step length, and feeding back the second target step length to the network element side, so that the network element side sends the charging data request of the target user based on the second target step length.

[0010] Further, the adjusting the current step length of the target user based on the real-time amount base usage information of the package of the target user to obtain the second target step length comprises: in response to the remaining traffic in the package of the target user being less than a first traffic threshold or the remaining call time being less than a first call threshold, determining a first time required by the target user to use a set unit of traffic or a second time required by the target user to use a set call time based on big data prediction, and taking the first time or the second time as the second target step length.

[0011] Further, the method further comprises: in response to the real-time amount base of the package of the target user reaching a second threshold, sending reminder information of the real-time amount base of the package to the network element side.

[0012] In a second aspect, an embodiment of the present application further provides a network element step length value adjustment apparatus, the apparatus comprising: a processor and a memory, the memory being used to store at least one instruction, the instruction being loaded and executed by the processor to implement the network element step length value adjustment method provided in the first aspect.

[0013] In one embodiment, the network element step size adjustment device provided in the second aspect can be a component of the device, such as a chip.

[0014] Thirdly, embodiments of this application also provide an apparatus that may include the network element step size adjustment device provided in the second aspect.

[0015] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the network element step size adjustment method provided in the first aspect.

[0016] By employing the above technical solution, if it is determined that the billing data request is not the target user's first billing data request, the target user's current step size is dynamically adjusted based on the target user's historical call detail records (CDRs) to obtain a first target step size. This first target step size is then fed back to the network element, enabling the network element to send the target user's billing data request based on the first target step size. This allows for the analysis of the target user's historical CDRs to determine the target user's behavioral habits, and the dynamic adjustment of the network element's current step size based on these habits. This avoids the aforementioned problems associated with using a fixed step size and alleviates the performance pressure on the billing system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of a step size adjustment system architecture provided in one embodiment of this application;

[0019] Figure 2 A flowchart illustrating a method for adjusting the network element step size value according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of a user data prediction interaction process provided in another embodiment of this application;

[0021] Figure 4 This is a schematic diagram of the structure of a network element step size adjustment device provided in another embodiment of this application. Detailed Implementation

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

[0023] With the rollout of 5G services and the increasing richness of mobile internet applications, more importantly, the development of services such as speed upgrades and price reductions, data traffic management, and the Internet of Things (IoT) has led to a geometric increase in call detail records (CDRs). This surge in CDRs poses a severe challenge to the support of operator systems. In traditional 4G and 5G billing scenarios, the core network generates CDRs on a timed and quantitative basis, for example, one CDR is generated for every 100MB of data used or every hour. With the rapid increase in user data usage after the upgrade from 4G to 5G, this model easily leads to the need for continuous cost-intensive expansion of business systems.

[0024] The step size refers to the traffic and duration values ​​generated by the billing system to control the frequency of call detail records generated by the network element. For example, if the step size is 100M / 30 minutes, the network element will send a request message to the billing side for authorization control every 30 minutes or when the traffic reaches 100M, which is used for tariff calculation.

[0025] The current 4G system uses a fixed step size mode. Fixed step size means that the network element controls the frequency of call detail record (CDR) generation according to a fixed duration and traffic configured on the network element side. Fixed step size uniformly controls all services for all users, and it remains unchanged throughout a user's service plan. In this mode, there is no dynamic interaction logic between the network element and the billing domain. When an adjustment to the step size is needed, it must be negotiated manually, and the step size configuration must be manually changed on the network element side.

[0026] In related technologies, the step size sent by the system to the network element is generally fixed. The main problem with fixed step sizes is that if the step size is too large, the time and traffic generated by each message will be large, making it difficult to control overdue payments and reminders; if the step size is too small, the number of messages sent by the network element to the billing system will surge, increasing the performance pressure on the billing system. Therefore, simply setting a step size cannot effectively balance the issues of call detail record volume, reminder timeliness, and overdue payment risk.

[0027] To overcome the above-mentioned technical problems, this application provides a method for adjusting the step size of a network element. This method can analyze the historical call detail records of the target user to obtain the target user's behavioral habits and dynamically adjust the current step size of the target user on the network element side according to the target user's behavioral habits. This avoids the problems caused by using a fixed step size and alleviates the performance pressure on the billing system.

[0028] To implement the above-mentioned method for adjusting the step size of network elements, this application provides a step size adjustment system architecture. Figure 1 This is a schematic diagram of the step size adjustment system architecture provided in one embodiment of this application, as shown below. Figure 1 As shown, the architecture may include a Session Management function (SMF, network element SMF), a Charging Function (CHF), and a Mobile Billing Financial Domain (hereinafter referred to as the Billing Domain).

[0029] SMF is responsible for tunnel maintenance, IP address allocation and management, UP function selection, policy implementation and QoS control, billing data collection, roaming, etc.

[0030] CHF is responsible for generating 5G call detail records.

[0031] Billing Domain is responsible for functions such as accounting processing and accounting management.

[0032] Figure 2 A flowchart of a network element step size adjustment method provided in one embodiment of this application is shown below. Figure 2 As shown, the method for adjusting the step size of a network element may include the following steps:

[0033] Step 201: CHF obtains the billing data request for the target user sent by the network element side (SMF).

[0034] Step 202: CHF determines whether the billing data request is the first billing data request for the target user. If it is the first billing data request, proceed to step 203; otherwise, proceed to step 204.

[0035] Step 203: CHF calculates the initial step size of the target user based on the data included in the target user's package and feeds back the initial step size to the network element side, so that the network element side sends the billing data request of the target user based on the initial step size.

[0036] Step 204: Send the billing data request of the target user to the billing domain.

[0037] Step 205: The billing domain calculates the corresponding tariff based on the billing data request of the target user, feeds back the calculated tariff to CHF, and includes the corresponding tariff in the target user's historical call detail records.

[0038] Step 206: The billing domain performs behavioral analysis on the target user based on the target user's historical call detail records and predicts the target user's future communication data usage, and sends the predicted target user's future communication data usage to CHF.

[0039] Step 207: CHF sends the target user's current step size value to CHF based on the target user's future communication data usage to obtain the first target step size, and feeds back the first target step size and the corresponding tariff provided by the billing domain to the network element user.

[0040] In the specific implementation of step 201, both SMF and CHF are functional modules defined in the 5G specification. The network element sends a charging data request to the CHF, and the CHF can return a charging data response to the network element based on the charging data request. The CHF is a charging interface added according to the 5G specification, and it interacts with the network element (SMF) through charging data request and charging data response messages.

[0041] In the specific implementation of step 202, the CHF can determine whether the charging data request is the target user's first charging data request. Specifically, when the CHF returns a charging data response message, it dynamically calculates the step size returned to the network element. Different control strategies are adopted for the first charging data request initiated by a user, also known as the initial message, and for subsequent charging data requests, also known as update messages. Specifically, if it is the first charging data request, step 203 is executed; otherwise, step 204 is executed.

[0042] In the specific implementation of step 203, since the target user sending the initial message does not yet have historical call detail records, usage prediction cannot be made based on historical data. In one implementation, the initial step size can be calculated based on the data allowance included in the user's subscribed package.

[0043] For example, if a user's subscription includes 20GB of data, this patent returns a step size control result of 200MB or 1 hour. That is, the network element user can initiate a billing data request to the CHF after consuming 200MB of data or after 1 hour. If a user's subscription includes 40GB of data, this patent returns a step size calculation result of 400MB or 1 hour. That is, the network element user can initiate a billing data request to the CHF after consuming 400MB of data or after 1 hour.

[0044] In the specific implementation of step 204, after receiving the billing data request sent by the network element, the CHF will generate a billing data response message. The response message contains the control parameters of user traffic and duration calculated by the CHF using dynamic step size. At the same time, the CHF will send the message to the billing domain for tariff calculation.

[0045] In the specific implementation of step 205, the billing domain can calculate the corresponding tariff based on the target user's billing data request, feed back the calculated tariff to CHF, and include the tariff in the target user's historical call detail records (CDRs). In some implementations, after completing the tariff calculation for the CDRs, the billing domain maintains the user's real-time data usage record based on the data usage in the CDRs. The user's real-time data usage record information includes the total data allowance and the amount already used.

[0046] In the specific implementation of step 206, the billing domain can perform behavioral analysis on the target user based on the target user's historical call detail records (CDRs) and predict the target user's future communication data usage, and then send the predicted future communication data usage to the CHF (CHF). Specifically, after completing the CDR tariff calculation, the billing domain performs intelligent analysis and prediction of the user's traffic usage information. The user's traffic usage information includes: user number, billing group, traffic usage amount, usage duration, start time, and end time. Through the above intelligent analysis and prediction, if it is predicted that the user will be in a peak traffic usage period in the future, the intelligent dynamic step size system will allow the user to use a larger step size, allowing the network element to relax the traffic usage restrictions reported by the CDR. If it is determined that the sending time of the target user's billing data request sent by the network element falls within the target time period in the historical CDRs, then a new step size is determined based on the end time of the target time period as the first target step size, wherein the target time period includes peak communication periods, and the communication includes traffic usage or calls. Alternatively, if it is determined that the sending time of the billing data request of the target user sent by the network element falls within the target time period in the historical call detail record, then a new step size determined based on the traffic usage or call usage during the target time period is used as the first target step size, wherein the target time period includes peak communication periods, and the communication includes traffic usage or calls.

[0047] In the specific implementation of step 207, CHF can dynamically adjust the current step size value of the target user based on the future communication data usage of the target user to obtain the first target step size, and feed back the first target step size and the corresponding tariff provided by the billing domain to the network element user.

[0048] For example, if a user subscribes to a 40GB data plan, and the intelligent analysis indicates that the user watches online videos between 7:00 PM and 9:00 PM daily, consuming 1GB to 1.5GB of data, and if the network element reports the user's usage information (via a billing data request) at 7:05 PM that day, the CHF (Cybersecurity Information Center) can use its intelligent dynamic step size system to determine that the user may consume 1.2GB of data within the next two hours. The CHF will then notify the network element to either continue consuming 1.2GB of data or to submit the billing data request again after two hours.

[0049] In some implementations, for users configured with a reminder policy, the CHF can check the progress of the user's reminder policy. In response to the target user's remaining data allowance being less than a first data allowance threshold or remaining call time being less than a first call time threshold, it determines, based on big data prediction, either a first time required for the target user to use a set unit of data or a second time required for the target user to use a set call time, using the first time or the second time as a second target step size. That is, when approaching the reminder threshold, the step size result is calculated based on the remaining amount of the reminder threshold. For example, a user subscribes to a 40GB data plan and also subscribes to a service that triggers an SMS reminder when data usage reaches 80%, meaning an SMS reminder should be triggered when the user's cumulative data usage reaches 32GB. The user has currently used 31.5GB of data, and big data predicts that the user will use 2GB of data in the next hour. At this time, the intelligent dynamic step size system will return a step size result of 0.5GB or 1 hour. Thus, when the user continues to use 0.5GB, the network element will report a billing data request, and the reminder will be triggered exactly when the user's cumulative data usage reaches 32GB.

[0050] In some implementations, the CHF can also check the user's real-time data usage information. When a user's data allowance is nearly exhausted, the intelligent dynamic step size system will reduce the step size to avoid triggering billing only after using too much data outside the plan, thus reducing the risk and amount of unpaid charges. Specifically, in response to the target user's real-time data usage reaching a second threshold, a reminder message about the real-time data usage of the plan is sent to the network element. For example, a user has subscribed to a 40GB data plan, and has currently used 39.9GB of data. The intelligent dynamic step size system calculates the step size as 0.1GB or 1 hour. When the user continues to use 0.1GB, the network element will report a billing data request, and a data usage alert will be triggered promptly after 40GB of data usage. Furthermore, if the user continues to use data outside the plan, the intelligent dynamic step size system will continue to return a smaller step size to the network element, triggering timely signal control reminders when the user's out-of-plan usage is low, thus preventing the user from incurring high out-of-plan charges.

[0051] With the network element step size adjustment method provided in this application embodiment, each time CHF processes a billing data request initiated by a network element, it will calculate the step size to be returned to the network element in real time through the intelligent dynamic step size system.

[0052] By providing user-level step size control, this solution avoids the one-size-fits-all approach of fixed step sizes used in related technologies, which fail to consider differences in user plans and usage habits. Instead, this solution utilizes user-level information for big data prediction, alert strategies, and real-time data volume analysis. This allows the intelligent dynamic step size system to calculate step sizes tailored to each user, resulting in the most suitable step size for that user.

[0053] Furthermore, user-level step size control can alleviate the performance pressure on the billing system. Specifically, by analyzing user habits through big data and adopting intelligent quotas, message interaction can be dynamically controlled in real time. Without increasing the risk of user arrears, the number of interactions between billing and network elements can be effectively reduced, thus alleviating the system performance pressure brought by the massive amount of 5G call detail records.

[0054] Furthermore, the accuracy of traffic threshold alerts can be improved. Specifically, by using smart quotas to reference traffic thresholds, when a user's traffic reaches the threshold, the user will be granted a quota using a baseline step size (smaller step size). When a traffic threshold alert is triggered, the actual amount of traffic used by the user will be closer to the traffic threshold configured by the user.

[0055] Furthermore, it can improve the real-time nature of information interaction. Specifically, it can control call detail record (CDR) volume without affecting the timeliness of overdue payment reminders and service suspension. Before user usage reaches the traffic reminder threshold, CDR volume is reduced based on user prediction data; after user usage reaches the traffic reminder threshold, a small-step approach is used to prioritize controlling overdue payments and ensuring timely reminders.

[0056] Furthermore, it can reduce the investment requirements for billing hardware. Specifically, due to the reduction in 5G billing call details, the processing capacity requirements of each stage of the 5G billing process will also be reduced. Correspondingly, the hardware requirements for 5G billing applications, MDB, databases, message middleware, file systems, and other related hosts, networks, and storage will also be significantly reduced.

[0057] In some implementations, the detailed process for dynamically adjusting the network element step size is as follows:

[0058] In this application embodiment, the introduction of Artificial Intelligence for ITOperations (AIOps) and the use of big data and data mining technologies can be used to build user data prediction that supports 5G intelligent dynamic step size, thereby empowering the billing system and enabling front-line operation and maintenance personnel to no longer rely on manual experience to configure coarse-grained fixed step size rules, thus achieving refined support for user-level dynamic step size.

[0059] Specifically, the key aspects of AIOps intelligent applications supporting 5G intelligent dynamic step size include:

[0060] 1. List Collection

[0061] The big data platform requires billing domain inventory data for analysis. It is recommended that this inventory data be transferred via a file interface. While the real-time requirements are relatively low, the throughput is high, and file transfer facilitates batch processing. The existing big data platform already has this capability and can directly use the collected data.

[0062] 2. Data Processing

[0063] By leveraging the computing power of big data platforms and collected user behavior data, tag data, list data, sales product data, etc., user profiles and historical trend behavior are formed, and wide table data is output for user data prediction models.

[0064] 3. Model Building

[0065] By using wide tables and big data mining techniques, we can predict a user's data usage over a future period of time, specifically within different time slots. For example, we can predict how much data (uplink and downlink) a user will use in each hour of the next day.

[0066] 4. Results synchronization

[0067] The system synchronizes the predicted user traffic usage for a future period with the updated data for each period.

[0068] 5. Evaluation and Optimization

[0069] The system automatically generates an evaluation report based on the comparison between the predicted and actual results; on-site maintenance personnel can optimize and rerun the model in stages according to actual needs.

[0070] Figure 3 This is a schematic diagram of a user data prediction interaction process provided in another embodiment of this application, such as... Figure 3 As shown, the 5G intelligent dynamic step-size user data prediction interaction process includes the following steps:

[0071] Step 1: The billing system synchronizes the billing data to the big data platform.

[0072] Step 2: AIOps utilizes the data mining computing power of big data platforms to train models.

[0073] Step 3: Configure and deploy AI scenarios for 5G intelligent dynamic step size user data prediction using AIOps.

[0074] Step 4: AIOps utilizes the batch data computing capabilities of the big data platform to perform wide table calculations for the model.

[0075] Step 5: AIOps utilizes the data mining computing power of big data platforms for model inference.

[0076] Step 6: AIOps synchronizes the user prediction data calculated on the big data platform to the billing system.

[0077] Step 7: AIOps utilizes the batch data computing capabilities of the big data platform to calculate the evaluation results.

[0078] Step 8: AIOps synchronizes the evaluation results of the big data platform back to its own system and provides an interface for querying and displaying them.

[0079] Step 9: AIOps iteratively optimizes the model based on the evaluation results and actual needs.

[0080] exist Figure 3 In the user data prediction interaction process provided in the illustrated embodiment, the data processing data sources include: quantity list data, user basic information, user order information, sales product information, user tag information, etc. All data sources originate from existing data tables on the big data platform. The calculation targets are the input wide table for the user traffic prediction model and the input wide table for the user duration prediction model.

[0081] The intelligent user traffic / duration prediction model is designed as follows:

[0082] Different user groups exhibit different behavioral characteristics. For example, ordinary office workers use their phones significantly more frequently on holidays than on weekdays, while sales personnel use their phones more frequently on weekdays. Some groups use their data primarily for social media, while others concentrate their data consumption on video apps. To reflect the behavioral habits of different user groups, separate prediction models are built for each group. The following descriptions will use a specific user group's data usage prediction scenario as an example. The same principle applies to other user groups and data usage duration prediction scenarios; the modeling fields remain the same, only the data preparation method needs adjustment (extracting sample data from the target user group as modeling data).

[0083] Using hours as the granularity, the day is divided into 24 time periods. Based on user basic information, user consumption habits, data consumption patterns, data usage habits, historical data usage details for each time segment, and holiday attributes, a regression model is constructed to predict the user's data usage on a future day and during a specific time segment. For more detailed data usage, such as data usage between 00:10 and 00:20, the average value can be calculated for the corresponding time segment between 00:00 and 01:00.

[0084] The following is an explanation of the attributes in each dimension:

[0085] Data preparation:

[0086] The modeling data should cover as many dimensions of user information as possible to comprehensively reflect the user profile. The dimensions are explained below:

[0087] User Basic Information

[0088] This primarily includes basic indicators such as age, gender, customer star rating, urban / rural location, and customer segmentation. These indicators provide fundamental criteria for predicting user traffic usage. For example, users aged 15-40 generally use more data than other age groups; male users consume significantly more data in gaming apps than female users; and urban users generally use more data than rural users.

[0089] User consumption habits

[0090] This primarily includes the price of the main data plan, the average number of data product subscriptions over the past few months, and the average subscription price of data products over the past few months. This dimension reflects users' consumption patterns on main data plans and data products, and is one of the core dimensions for predicting user data usage. For example, higher-priced main data plans often offer more data allowances, and users with higher-priced main data plans generally use more data than those with lower-priced main data plans; if a user group frequently subscribes to premium data plans or high-priced data products, their data usage will be significantly higher than that of other users.

[0091] Data consumption

[0092] This mainly includes the total amount, usage, and remaining data for the main data plan and data products. This dimension reflects the user's data consumption and indirectly affects the user's subsequent restraint in data usage. For example, compared to a situation with ample remaining data, if most of the data in the plan has been used up and there is very little left, then subsequent data usage will tend to decrease.

[0093] Data usage habits

[0094] This primarily includes the average daily data usage over the past month, covering both holidays and weekdays, as well as the average daily data usage of video, music, game, and social media apps. This dimension describes user data usage habits and is one of the core dimensions for predicting user data usage. For example, ordinary office workers use significantly more data on holidays than on weekdays; some users spend more data on social media, while others concentrate their data consumption on video apps.

[0095] Data usage details for each time period over the past eight days

[0096] This primarily includes detailed data on user data usage across 24 time segments over the past eight days. This dimension is a key indicator in the user data usage prediction model. The model will predict the user's data usage for the eighth day based on basic user information, consumption habits, data consumption patterns, usage patterns, holiday attributes, and detailed data usage for each time segment over the past seven days. The reason for using an eight-day time span is that it's necessary to predict the eighth day's data based on the historical seven-day data. The rationale for using historical seven-day data is that while time spans can typically be three days, seven days, fifteen days, or one month, to ensure full utilization of historical information and considering storage and computing resources, a seven-day time span is tentatively recommended. The specific timeframe will be determined after considering model performance and discussions with the business team.

[0097] Holiday attributes of the past eight days

[0098] This primarily reflects the historical data for eight days of holidays. Holiday characteristics play a decisive role in user traffic usage. For example, if the predicted date falls on a holiday, the traffic volume of ordinary employees will significantly increase during the holiday.

[0099] Data cleaning:

[0100] To ensure that the data is accurate and usable, it needs to be cleaned. The main steps of data cleaning include missing value imputation and outlier handling.

[0101] Missing value imputation

[0102] Common methods for imputing missing values ​​include mean imputation, median imputation, and mode imputation. If a variable has a high percentage of missing values, such as more than 90%, then deleting that variable may be considered. Examples are as follows:

[0103] If there are missing values ​​for continuous indicators, such as the price of the main package, the mean or median of the main package prices in the sample data can be used to fill the gaps.

[0104] If discrete indicators are missing, such as user gender, the mode of gender in the sample data can be used to fill in the gaps.

[0105] For continuous business metrics such as current call balance, total data allowance for main plan, data usage for main plan, and remaining data allowance for main plan, it is recommended to use the mean or median of the corresponding metrics to fill in the gaps.

[0106] For attribute-based business metrics such as customer identification and customer segmentation, it is recommended to use the mode of the corresponding metric to fill in the gaps.

[0107] Outlier handling

[0108] A common method for handling outliers is to remove long-tail data. An example is as follows:

[0109] Remove sample records from the sample data where the price of the main package is less than the 5th percentile or greater than the 95th percentile of the main package price distribution;

[0110] For business metrics such as total traffic volume of traffic products, total traffic usage of traffic products, and total remaining traffic volume of traffic products, it is recommended to use the above method to remove outlier sample data.

[0111] Feature engineering:

[0112] The significance of feature engineering lies in extracting features from raw data to the maximum extent possible for use by algorithms and models, involving both feature derivation and feature selection.

[0113] Feature Derivation

[0114] Feature derivation involves transforming, synthesizing, and expanding existing features, including methods such as discretization, encoding, normalization, standardization, regularization, and feature combination. Examples are as follows:

[0115] Discretize continuous data to improve model processing efficiency. For example, design a series of threshold intervals [0M, 200M), [200M, 500M), [500M, 1G), [1G, Infinity), and map and replace the total traffic volume of the main package with the corresponding interval (e.g., if the total traffic volume of the main package is 800M, then the indicator value is replaced with [500M, 1G)). The threshold interval can be set based on business experience or based on the IV value after grouping (which reflects the importance of the indicator), and the grouping method with the highest IV value can be selected.

[0116] The enumerated values ​​of attribute variables cannot be used directly and need to be encoded. For example, the two values ​​of gender, 1-female and 2-male, are expanded into two indicators, gender1 and gender2. If gender1=1 and gender2=0, then it is considered female; if gender1=0 and gender2=1, then it is considered male.

[0117] Continuous metrics such as the average daily data usage on weekdays / holidays over the past month, and the average daily data usage of video / music / game / social apps over the past month, all need to be discretized.

[0118] Attribute-based business metrics such as customer identification and customer segmentation must be coded.

[0119] Feature Filtering

[0120] Feature filtering refers to filtering a newly generated indicator system based on certain criteria, retaining only the feature data that is meaningful and contributes to the model, such as F-test, chi-square test, and correlation analysis. Examples are as follows:

[0121] Perform a correlation test on the explanatory variable, the current phone bill balance, and the data usage of the user on a certain time segment of the eighth day. If the correlation between the explanatory variable and the explained variable is low, it is recommended to remove the explanatory variable; otherwise, retain it.

[0122] All explanatory variables must be tested for correlation with the explained variable. Explanatory variables with low correlation (the specific threshold needs to be determined based on the actual data) are recommended to be removed.

[0123] Model building

[0124] The appropriate model algorithm should be selected based on the business scenario to depict the true distribution and trend of data. This business scenario—"user traffic and usage prediction"—falls under the category of regression prediction; therefore, linear regression or decision tree regression models are recommended. Modeling method:

[0125] 1. Training set / test set split: Generally, the training set and test set are split in a ratio of 7:3. The training set is used for model training, and the test set is used for model performance evaluation.

[0126] 2. Parameter tuning: Enumerate the non-parameter values ​​of the model algorithm or provide a range of values, and use grid search, random search or genetic algorithm to find the optimal non-parameter values. At this time, the model performs best.

[0127] 3. Model selection: Compare different model algorithms and select the model with excellent performance and stability.

[0128] The model is trained based on the data after feature engineering, and the nonparametric parameters of the model are adjusted. The relevant parameter coefficients are continuously calculated, optimized and improved based on the optimization objective, so as to fit the real data as closely as possible and describe the mapping relationship between the explanatory variables and the explained variables.

[0129] Inference and Prediction

[0130] Model-based inference prediction refers to using model training to generate and solidify model files or model parameter coefficients to predict target variables for new sample data. For example, by inputting basic user information, user consumption habits, data consumption, data usage habits, historical data usage details from 00:00 to 01:00 for the past seven days, and holiday attributes for the eighth day, the total data usage of the user in the time segment from 00:00 to 01:00 on the eighth day can be predicted.

[0131] The prediction results from the traffic usage model and the traffic usage duration model are summarized to generate the following wide table:

[0132]

[0133] Figure 4 This is a schematic diagram of the structure of a network element step size adjustment device provided in another embodiment of this application, as shown below. Figure 4As shown, the device includes a processor 401 and a memory 402. The memory 402 is used to store at least one instruction, which is loaded and executed by the processor 401 to implement the network element step size adjustment method provided in any embodiment of this application.

[0134] In one implementation, Figure 4 The network element step size adjustment device provided in the illustrated embodiment can be a component of the device, such as a chip.

[0135] This application also provides a device, which may include... Figure 4 The network element step size adjustment device provided in the embodiment shown.

[0136] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the network element step size adjustment method provided in any embodiment of this application.

[0137] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0138] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus 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 coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0139] 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.

[0140] Furthermore, the functional units in the various embodiments of the present invention 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. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0141] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for adjusting the step size value of a network element, characterized in that, include: Obtain the billing data request for the target user sent by the network element side; If it is determined that the billing data request is not the first billing data request of the target user, the current step size of the target user is dynamically adjusted based on the target user's historical call detail records to obtain a first target step size, and the first target step size is fed back to the network element side so that the network element side sends the target user's billing data request based on the first target step size; If it is determined that the billing data request is the first billing data request of the target user, then the initial step size of the target user is calculated based on the data usage included in the target user's package, and the initial step size is fed back to the network element side so that the network element side can send the billing data request of the target user based on the initial step size.

2. The method according to claim 1, characterized in that, The step of dynamically adjusting the current step size of the target user based on the target user's historical call detail records to obtain the first target step size includes: If it is determined that the sending time of the billing data request of the target user sent by the network element falls within the target time period in the historical call detail record, then a new step size is determined as the first target step size based on the end time of the target time period. The network element side sends the billing data request for the target user based on the first target step size, including: The network element sends a billing data request to the target user at the end of the target time period.

3. The method according to claim 1, characterized in that, The step of dynamically adjusting the current step size of the target user based on the target user's historical call detail records to obtain the first target step size includes: If it is determined that the sending time of the billing data request of the target user sent by the network element falls within the target time period in the historical call detail record, then the new step size determined based on the traffic usage or call usage of the target time period is used as the first target step size. The network element side sends the billing data request for the target user based on the first target step size, including: After the target user has used the traffic or made calls during the target time period, the network element sends a billing data request to the target user.

4. The method according to claim 1, characterized in that, The method further includes: Based on the real-time usage information of the target user's package, the current step size of the target user is adjusted to obtain a second target step size, and the second target step size is fed back to the network element side so that the network element side can send the billing data request of the target user based on the second target step size.

5. The method according to claim 4, characterized in that, The step of adjusting the current step size of the target user based on the real-time data usage information of the target user's package to obtain the second target step size includes: In response to the target user's remaining data allowance being less than a first data allowance threshold or remaining call time being less than a first call time threshold, a first time required for the target user to use a set unit of data allowance or a second time required for the target user to use a set call time is determined based on big data prediction, with the first time or the second time being used as the second target step size.

6. The method according to claim 1, characterized in that, The method further includes: In response to the target user's real-time data usage reaching the second threshold, a reminder message regarding the real-time data usage of the package is sent to the network element.

7. A network element step size adjustment device, characterized in that, The device includes: A processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the network element step size adjustment method as described in any one of claims 1-6.

8. A device, characterized in that, The device includes the network element step size adjustment device as described in claim 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the network element step size adjustment method as described in any one of claims 1-6.

Images