A method and device for realizing traffic bill charging
By generating user traffic ledgers and performing real-time authentication, and collecting and parsing traffic call details, the accuracy and flexibility issues of targeted traffic billing in existing technologies are resolved. This enables accurate billing and control of targeted traffic and supports traffic sharing and rate limiting for combined products.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HUNAN CREATOR INFORMATION TECH CO LTD
- Filing Date
- 2022-12-29
- Publication Date
- 2026-07-31
AI Technical Summary
The existing data traffic package billing scheme cannot accurately distinguish between different business products, cannot support data sharing and rate limiting for combined products, cannot shut down excessive data traffic in a timely manner, and cannot flexibly adapt to rate limiting for single/combined products and monthly/periodic products.
By generating user traffic ledgers, authenticating user traffic usage in real time, collecting user traffic call details at set intervals, parsing and calculating traffic reserves, supporting traffic sharing and rate limiting for combined products, and achieving accurate billing and control of targeted traffic.
It enables precise billing for targeted traffic, supports flexible sharing and rate limiting of traffic for bundled products, timely shutdown of traffic exceeding limits, adapts to rate limiting for single/bundled products and monthly/periodic products, and provides tiered user rate limiting alerts and partner alerts.
Smart Images
Figure CN116390045B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of information processing technology, and in particular, to a method and apparatus for implementing traffic call detail record (CDR) billing. Background Technology
[0002] Targeted data usage refers to the data used by a user to access specific mobile applications and content through a mobile device. For purchased targeted data packages, the data used while using these applications and content will not be deducted from the user's general data plan or other data packages, provided it does not exceed the threshold of the subscribed targeted data package. Targeted data can be either unlimited (unrestricted) or limited (with specific data limits). This patent describes a method for billing based on data usage records (DDRs). By collecting user DDR data, it calculates and deducts user data usage, thereby ensuring overall service security and data limit control, and achieving accurate billing for targeted data usage.
[0003] The current targeted data plan billing is mainly accomplished through the collaboration of GGSN and cBSS. GGSN needs to configure the IP / URL and corresponding SID for the targeted data plan service, while cBSS configures the SID and data limit threshold. When a user accesses an application or content, GGSN collects the traffic used by that application based on the mapping between IP / URL and SID, generates a data plan carrying the corresponding SID, and synchronizes the data plan to the cBSS system. cBSS matches the corresponding targeted data plan product based on the SID and calculates the consumed data for that product. If the consumed data exceeds the threshold, the excess data is billed using the general data plan included in the package.
[0004] The advantage of this solution is that it uses China Unicom's cBSS billing system to implement traffic-specific call detail record (CDR) billing for targeted traffic. However, this solution also has some drawbacks and cannot meet operational requirements:
[0005] 1. Different business products under the same SID cannot be accurately distinguished, and billing cannot be applied to the corresponding product according to the business type;
[0006] 2. Bundled products cannot share traffic in a fixed manner, and it is not possible to set traffic thresholds for individual products within a bundled product;
[0007] 3. Does not support traffic stacking or validity extension for recurring products;
[0008] 4. When the user's data usage has exceeded the product's threshold, it cannot be shut down in a timely manner;
[0009] 5. It is not possible to specify the order of traffic deduction for individual products in a bundled product. Summary of the Invention
[0010] To address the aforementioned technical issues, this application provides a method for implementing traffic-based call detail record (CDR) billing.
[0011] The technical solution adopted in this application is as follows:
[0012] A method for implementing data traffic call detail record (CDR) billing includes the following steps:
[0013] S1. After a user successfully purchases a product, a user traffic ledger is generated through periodic calculations. The user traffic ledger includes traffic volume, validity period, and product code.
[0014] S2. When a user uses the data-free service, the system will authenticate the user's data usage in real time, check the user's remaining data information, and if the data usage exceeds the threshold, the system will promptly implement data control and restriction, and the user will no longer be allowed to enjoy the data-free service.
[0015] S3. Collect user traffic call detail records (CDRs) including service-related parameters from the China Unicom CDN platform or partner platform at a set period for subsequent user traffic calculation and deduction. The service-related parameters include user ID and service ID.
[0016] S4. After collecting and parsing the user traffic call details, compare the traffic balance of the corresponding user ID and service ID in the user traffic ledger based on the parsing results of the user traffic call details, and calculate and update the traffic balance of different service IDs of the user.
[0017] S5. Query the database for users who need to receive traffic surplus notifications, and notify both the partners and the users respectively.
[0018] Further, step S1 specifically includes the following steps:
[0019] S101. After a user successfully purchases a product on the China Unicom billing platform, the user's billing details are generated through the user billing platform.
[0020] S102. Synchronize the user's billing bills from the user billing platform through the batch processing service of the traffic billing platform, and generate the user traffic ledger for the current month based on the relevant data carried in the billing bills. The user traffic ledger includes traffic volume, validity period, and product code.
[0021] S103. Push the user's traffic records to the cached data service through the batch processing service of the traffic call detail record (CDR) billing platform, and notify the partner platform of the user's traffic status.
[0022] Further, step S1 specifically includes the following steps:
[0023] S111. Periodically query the billing details of the current month that have not been canceled through the batch processing service of the traffic billing platform, generate the user traffic ledger for the next period, and update it to the cached data service.
[0024] S112. Periodically query the billing details of unsubscribed services in the current month through the batch processing service of the traffic billing platform, and query the user traffic account book from the data cache service.
[0025] S113. If a user traffic ledger already exists, update the validity period of the user traffic ledger to expire.
[0026] Furthermore, step S2 specifically includes the following steps:
[0027] S21. When a user plays a video on the partner platform client, the partner platform client queries the server for the user's remaining bandwidth. If there is remaining bandwidth, the video playback request is sent to the DES platform for bandwidth proxy acceleration.
[0028] S22. After receiving the traffic proxy request through the DES platform, parse the relevant data in the request link, including mobile phone number, partner code, and product code information;
[0029] S23. Obtain the user's remaining data information by requesting the traffic authentication interface of the traffic call detail record billing platform capability interface service through the DES platform.
[0030] S24. Parse the relevant parameters transmitted through the traffic call detail record billing platform capability interface service, query the user's traffic account book from the cached data service according to the mobile phone number and product code, and feed back the user's remaining traffic to the DES platform;
[0031] S25. If the traffic billing platform capability interface service determines that the current user traffic ledger has no traffic ledger, then the user's information will be pushed to the data bus service.
[0032] S26. Obtain relevant user information from the data bus service through batch processing service, query the user's billing bill in the database, and if a valid billing bill is found, regenerate the user traffic ledger and update it in the cached data service.
[0033] When the S27 and DES platforms receive a user's remaining data balance that is not 0, they will use the free data proxy channel to allow the user to enjoy free video playback. If the remaining data balance is 0, a specific encoded error will be returned, and the partner platform client will prompt the user that they cannot enjoy the free data service.
[0034] Furthermore, step S3 specifically includes the following steps:
[0035] S31. Collect user traffic usage information through the DES platform, generate and synchronize user traffic call detail records (CDRs) to the file storage server of the traffic CDR billing platform, including user identifier, partner code, traffic consumption value, and usage time.
[0036] S32. The user traffic call detail record (CDR) file is retrieved from the file storage server at a predetermined frequency through the batch processing service of the traffic call detail record (CDR) billing platform, and the data in the user traffic CDR file is parsed. The parsed user traffic CDR is then pushed to the data bus service of the traffic call detail record (CDR) billing platform.
[0037] S33. The partner platform uses API interface to push user traffic call details in real time. The traffic call details billing platform capability interface service receives user traffic call details and sends them to the traffic call details billing platform data bus service.
[0038] Furthermore, step S4 specifically includes the following steps:
[0039] S41. Obtain undeducted user traffic records from the data bus service through the batch processing service of the traffic record billing platform, and calculate the traffic value in the user traffic records.
[0040] S42. Obtain the user traffic ledger from the cached data service of the traffic call detail record billing platform through batch processing service, and deduct the remaining traffic in the user traffic ledger.
[0041] S43. The deducted traffic balance is corrected to the user's traffic ledger through batch processing service and updated to the cache data service of the traffic call detail record billing platform.
[0042] S44. Query the trigger threshold of user traffic notification through batch processing service, determine whether the user's current traffic balance triggers the traffic notification condition, and if it has been triggered, save the user information that needs to be notified of the remaining traffic balance to the database, and save the deducted traffic call details to the data bus service.
[0043] S45. Obtain the deducted traffic call details from the data bus service through the batch processing service and save them to the database for easy customer service inquiry later.
[0044] Further, step S5 specifically includes the following steps:
[0045] S51. Query the database for users who need to be notified through the batch processing service of the traffic call detail record billing platform;
[0046] S52. Call the API interface of the partner platform to notify the partner platform of the remaining traffic.
[0047] S53. Notify users of remaining data allowance via SMS.
[0048] This application also provides an apparatus for implementing traffic-based call detail record (CDR) billing, comprising:
[0049] The user traffic ledger generation module is used to generate a user traffic ledger through periodic calculations after a user successfully purchases a product. The user traffic ledger includes traffic volume, validity period, and product code.
[0050] The data usage limit control and authentication module is used to authenticate users' data usage in real time when they use data-free services. If the user's remaining data exceeds the threshold, data usage will be restricted and the user will no longer be allowed to enjoy the data-free service.
[0051] The user traffic call detail record (CDR) collection module is used to collect user traffic CDRs, including service-related parameters, from the China Unicom CDN platform or partner platform at a set period for subsequent user traffic calculation and deduction. The service-related parameters include user ID and service ID.
[0052] The traffic deduction module is used to collect and parse user traffic call records, compare the traffic balance of the corresponding user ID and service ID in the user traffic ledger based on the parsing results of the user traffic call records, and calculate and update the traffic balance of different service IDs of the user.
[0053] The traffic notification module is used to query the database for users who need to be notified of remaining traffic, and then notify both partners and users respectively.
[0054] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method for implementing traffic call detail record (CDR) billing.
[0055] This application also provides a storage medium including a stored program that, when the program is executed, controls the device where the storage medium is located to perform the steps of the method for implementing traffic call detail record (CDR) billing.
[0056] Compared with the prior art, this application has the following advantages:
[0057] This application provides a method and apparatus for implementing data traffic billing. The method includes the following steps: S1. After a user successfully purchases a product, a user data traffic ledger is generated periodically. The user data traffic ledger includes data traffic volume, validity period, and product code. S2. When a user uses data-free services, the user's data traffic usage is authenticated in real time. If the user's remaining data traffic exceeds a threshold, data traffic control and restriction are implemented, and the user is no longer allowed to enjoy data-free services. S3. User data traffic bills, including service-related parameters, are collected from the China Unicom CDN platform or a partner platform at set intervals for subsequent user data traffic calculation and deduction. The service-related parameters include user ID and service ID. S4. After collecting and parsing the user data traffic bills, the remaining data traffic for the corresponding user ID and service ID in the user data traffic ledger is compared based on the parsing results of the user data traffic bills, and the remaining data traffic for different service IDs of the user is calculated and updated. S5. Users who need to be notified of their remaining data traffic are queried from the database, and the partners and users are notified respectively.
[0058] This application supports traffic limit restrictions for targeted data traffic. It achieves targeted data traffic billing by generating user traffic ledgers and collecting user traffic call detail records (CDRs) at set intervals for real-time analysis and calculation. This includes periodic calculation, traffic limit authentication, user traffic detail record collection, traffic deduction, and traffic notification. It can update the remaining targeted data traffic information of users in real time, supports flexible sharing and traffic limiting of bundled products, and can flexibly adapt to traffic limiting of single / bundled products and monthly / periodic products. It supports tiered user traffic limiting warnings and partner warnings, thereby helping operators achieve accurate billing and control of targeted data traffic.
[0059] In addition to the purposes, features, and advantages described above, this application has other purposes, features, and advantages. The application will now be described in further detail with reference to the accompanying drawings. Attached Figure Description
[0060] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:
[0061] Figure 1 This is a schematic flowchart illustrating a preferred embodiment of the method for implementing traffic-based call detail record (CDR) billing.
[0062] Figure 2 This is a timing diagram of the sub-steps of step S1 in a preferred embodiment of this application.
[0063] Figure 3 This is a timing diagram of another sub-step of step S1 in a preferred embodiment of this application.
[0064] Figure 4This is a timing diagram of the sub-steps of step S2 in a preferred embodiment of this application.
[0065] Figure 5 This is a timing diagram of the sub-steps of step S3 in a preferred embodiment of this application.
[0066] Figure 6 This is a timing diagram of the sub-steps of step S4 in a preferred embodiment of this application.
[0067] Figure 7 This is a timing diagram of the sub-steps of step S5 in a preferred embodiment of this application.
[0068] Figure 8 This is a schematic diagram of a module of a device for implementing traffic call detail record (CDR) billing according to a preferred embodiment of this application.
[0069] Figure 9 This is a schematic block diagram of an electronic device according to a preferred embodiment of this application.
[0070] Figure 10 This is an internal structural diagram of a computer device according to a preferred embodiment of this application. Detailed Implementation
[0071] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0072] Reference Figure 1 In one embodiment of the present invention, a method for implementing traffic call detail record (CDR) billing is provided, comprising the steps of:
[0073] S1. After a user successfully purchases a product, a user traffic ledger is generated through periodic calculations. The user traffic ledger includes traffic volume, validity period, and product code.
[0074] S2. When a user uses the data-free service, the system will authenticate the user's data usage in real time, check the user's remaining data information, and if the data usage exceeds the threshold, the system will promptly implement data control and restriction, and the user will no longer be allowed to enjoy the data-free service.
[0075] S3. Collect user traffic call detail records (CDRs) including service-related parameters from the China Unicom CDN platform or partner platform at a set period for subsequent user traffic calculation and deduction. The service-related parameters include user ID and service ID.
[0076] S4. After collecting and parsing the user traffic call details, compare the traffic balance of the corresponding user ID and service ID in the user traffic ledger based on the parsing results of the user traffic call details, and calculate and update the traffic balance of different service IDs of the user.
[0077] S5. Query the database for users who need to receive traffic surplus notifications, and notify both the partners and the users respectively.
[0078] This embodiment provides a method for implementing traffic-based call detail record (CDR) billing. This method collects user traffic CDR data to calculate and deduct user traffic, thereby ensuring the overall security and limit control of the service and achieving accurate billing for targeted traffic. The method supports traffic limit restrictions for targeted traffic. It achieves targeted traffic CDR billing by generating a user traffic ledger and collecting user traffic CDRs at set intervals for real-time analysis and calculation. This includes periodic calculation, traffic limit authentication, detailed user traffic record collection, traffic deduction, and traffic notification. It can update the remaining targeted traffic information in real time, supports flexible sharing and limiting of traffic for combined products, and can flexibly adapt to limiting traffic for single / combined products and monthly / periodic packages. It supports tiered user traffic limiting warnings and partner warnings, thereby helping operators achieve accurate billing and management of targeted traffic.
[0079] Specifically, the periodic calculation includes monthly periodic calculation. After a user successfully purchases a product, the data traffic billing platform generates a data traffic ledger based on the product's data usage, validity period, etc. Subsequent data traffic deductions are all based on this ledger. Therefore, if... Figure 2 As shown, when performing the monthly cycle calculation, step S1 specifically includes the following steps:
[0080] S101. After a user successfully purchases a product on the China Unicom billing platform, the user's billing details are generated through the user billing platform.
[0081] S102. Synchronize the user's billing bills from the user billing platform through the batch processing service of the traffic billing platform, and generate the user traffic ledger for the current month based on the relevant data carried in the billing bills. The user traffic ledger includes traffic volume, validity period, and product code.
[0082] S103. Push the user's traffic records to the cached data service through the batch processing service of the traffic call detail record (CDR) billing platform, and notify the partner platform of the user's traffic status.
[0083] Specifically, if a user subscribes to a monthly data plan and does not cancel within the current month, the system will calculate the user's data usage data for the following month (including product number, data allowance, validity period, etc.). Due to the large number of existing users each month and the resulting large amount of data to be calculated for the next month's data usage data, the system calculates the data usage data for the next month (periodic unit) in batches and at different times each day to distribute the system load. Each batch of data is retrieved and the calculation is completed within 10 seconds. Therefore, if... Figure 3 As shown, step S1 specifically includes the following steps:
[0084] S111. Periodically query the billing details of the current month that have not been canceled through the batch processing service of the traffic billing platform, generate the user traffic ledger for the next period, and update it to the cached data service.
[0085] S112. Periodically query the billing details of unsubscribed services in the current month through the batch processing service of the traffic billing platform, and query the user traffic account book from the data cache service.
[0086] S113. If a user traffic ledger already exists, update the validity period of the user traffic ledger to expire.
[0087] Specifically, when a user uses the data-free service, their data usage needs to be authenticated in real time. If the usage exceeds a threshold, data control and restrictions will be implemented, disallowing the user from enjoying the data-free service. Authentication interface example:
[0088] http: / / host:port / orderFlow / flowQuery? userid=xxxx&cpid=xxx&channel=xxx×tamp=xxx&signature=xxxxxxxx
[0089] Where signature = Md5(userid + cpid + channel + timestamp + pwd)
[0090] The host:port is the address of the scheduling interface. The interface parameters are shown in Table 1.
[0091] Table 1
[0092]
[0093]
[0094] Response: Returned in JSON format. A normal message includes the parameters listed in Table 2.
[0095] Table 2
[0096]
[0097] Therefore, as Figure 4 As shown, step S2 specifically includes the following steps:
[0098] S21. When a user plays a video on the partner platform client, the partner platform client queries the server for the user's remaining bandwidth. If there is remaining bandwidth, the video playback request is sent to the DES platform for bandwidth proxy acceleration.
[0099] S22. After receiving the traffic proxy request through the DES platform, parse the relevant data in the request link, including mobile phone number, partner code, and product code information;
[0100] S23. Obtain the user's remaining data information by requesting the traffic authentication interface of the traffic call detail record billing platform capability interface service through the DES platform.
[0101] S24. Parse the relevant parameters transmitted through the traffic call detail record billing platform capability interface service, query the user's traffic account book from the cached data service according to the mobile phone number and product code, and feed back the user's remaining traffic to the DES platform;
[0102] S25. If the traffic billing platform capability interface service determines that the current user traffic ledger has no traffic ledger, then the user's information will be pushed to the data bus service.
[0103] S26. Obtain relevant user information from the data bus service through batch processing service, query the user's billing bill in the database, and if a valid billing bill is found, regenerate the user traffic ledger and update it in the cached data service.
[0104] When the S27 and DES platforms receive a user's remaining data balance that is not 0, they will use the free data proxy channel to allow the user to enjoy free video playback. If the remaining data balance is 0, a specific encoded error will be returned, and the partner platform client will prompt the user that they cannot enjoy the free data service.
[0105] Specifically, detailed user traffic records are collected from the China Unicom CDN platform or partner platforms, supporting both API and text interfaces. The detailed data is pushed to a message queue for subsequent user traffic calculation and deduction. Example of detailed data collection interface:
[0106] http: / / host:port / orderFlow / flowCons? userid=xxxx&cpid=xxxx&channel=xxxx×tamp=xxx&consflow=xxxx&constime=xxxx&signature=1ebd669e65fcc1dc4c902b2121b9adc7
[0107] in:
[0108] signature=Md5(userid+cpid+channel+timestamp+consflow+consti me+pwd)
[0109] `host:port` is the address of the scheduling interface. The interface parameters are shown in Table 3.
[0110] Table 3
[0111]
[0112]
[0113] Response: Returned in JSON format. A normal message contains the parameters shown in Table 4.
[0114] Table 4
[0115]
[0116] Therefore, as Figure 5 As shown, step S3 specifically includes the following steps:
[0117] S31. Collect user traffic usage information through the DES platform, generate and synchronize user traffic call detail records (CDRs) to the file storage server of the traffic CDR billing platform, including user identifier, partner code, traffic consumption value, and usage time.
[0118] S32. The user traffic call detail record (CDR) file is retrieved from the file storage server at a predetermined frequency (e.g., every minute) through the batch processing service of the traffic call detail record (CDR) billing platform. The data in the user traffic call detail record file is parsed and the parsed user traffic call detail record is pushed to the data bus service of the traffic call detail record (CDR) billing platform.
[0119] S33. The partner platform uses API interface to push user traffic call details in real time. The traffic call details billing platform capability interface service receives user traffic call details and sends them to the traffic call details billing platform data bus service.
[0120] Specifically, after collecting and parsing the user's detailed data usage records, it is necessary to compare them with the remaining data in the user's data usage ledger and calculate and update the user's remaining data usage. Therefore, as follows: Figure 6 As shown, step S4 specifically includes the following steps:
[0121] S41. Obtain undeducted user traffic records from the data bus service through the batch processing service of the traffic record billing platform, and calculate the traffic value in the user traffic records.
[0122] S42. Obtain the user traffic ledger from the cached data service of the traffic call detail record billing platform through batch processing service, and deduct the remaining traffic in the user traffic ledger.
[0123] S43. The deducted traffic balance is corrected to the user's traffic ledger through batch processing service and updated to the cache data service of the traffic call detail record billing platform.
[0124] S44. Query the trigger threshold of user traffic notification through batch processing service, determine whether the user's current traffic balance triggers the traffic notification condition, and if it has been triggered, save the user information that needs to be notified of the remaining traffic balance to the database, and save the deducted traffic call details to the data bus service.
[0125] S45. Obtain the deducted traffic call details from the data bus service through the batch processing service and save them to the database for easy customer service inquiry later.
[0126] Specifically, the system queries the database for users who need to receive notifications about remaining data allowances, notifies partners via API, and notifies users via SMS. Therefore, as... Figure 7 As shown, step S5 specifically includes the following steps:
[0127] S51. Query the database for users who need to be notified through the batch processing service of the traffic call detail record billing platform;
[0128] S52. Call the API interface of the partner platform to notify the partner platform of the remaining traffic.
[0129] S53. Notify users of remaining data allowance via SMS.
[0130] In summary, the method for implementing traffic-based call detail record (CDR) billing provided in the above embodiments has the following technical features compared to the prior art:
[0131] 1. Precise billing based on data usage
[0132] Existing technologies configure SIDs and traffic quota thresholds in BSS (including OCS) to achieve targeted traffic quota control, but cannot accurately distinguish different service products under the same SID, and cannot bill traffic to the corresponding product according to service type.
[0133] This application adds business-related parameters such as user ID and service ID to the user's data traffic record, parses the data traffic record, calculates the data traffic, queries the corresponding data traffic ledger, and deducts the remaining data traffic.
[0134] 2. Fixed traffic sharing for bundled products
[0135] Existing BSS (including OCS) technologies only support flexible sharing for combined products. Individual products under a combined product share the same flow threshold. If a single product consumes all the flow of the combined product, other products cannot be used.
[0136] This application sets traffic thresholds for individual products under the combined product, finds the remaining traffic of individual products under the combined product traffic ledger based on the business ID, and deducts the traffic.
[0137] 3. Overlapping traffic from cyclical products
[0138] Existing BSS (including OCS) technologies only support one traffic billing and control per month for products within the same cycle, and do not allow multiple traffic accumulations or validity extensions within the same month.
[0139] This application supports multiple purchases of cyclical products within the same month, and allows for the stacking of traffic for the same product and the extension of its validity period.
[0140] 4. Stop the data flow in a timely manner
[0141] When collecting user traffic call details, existing GGSN technologies query the SID corresponding to the IP / URL accessed by the user, add the SID field to the traffic call details, and pass the traffic details to BSS (including OCS) for traffic calculation and deduction. If the user's targeted traffic has been exhausted, then general traffic will be deducted.
[0142] This application provides an authentication interface for traffic limits to China Unicom's CDN platform. When performing free traffic proxy, the CDN platform queries the user's remaining traffic information in real time through the authentication interface and chooses to continue free traffic proxy or shut down the proxy based on the remaining traffic information.
[0143] like Figure 8 As shown, another preferred embodiment of this application also provides an apparatus for implementing data traffic call detail record (CDR) billing, comprising:
[0144] The user traffic ledger generation module is used to generate a user traffic ledger through periodic calculations after a user successfully purchases a product. The user traffic ledger includes traffic volume, validity period, and product code.
[0145] The data usage limit control and authentication module is used to authenticate users' data usage in real time when they use data-free services. If the user's remaining data exceeds the threshold, data usage will be restricted and the user will no longer be allowed to enjoy the data-free service.
[0146] The user traffic call detail record (CDR) collection module is used to collect user traffic CDRs, including service-related parameters, from the China Unicom CDN platform or partner platform at a set period for subsequent user traffic calculation and deduction. The service-related parameters include user ID and service ID.
[0147] The traffic deduction module is used to collect and parse user traffic call records, compare the traffic balance of the corresponding user ID and service ID in the user traffic ledger based on the parsing results of the user traffic call records, and calculate and update the traffic balance of different service IDs of the user.
[0148] The traffic notification module is used to query the database for users who need to be notified of remaining traffic, and then notify both partners and users respectively.
[0149] like Figure 9 As shown, a preferred embodiment of this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the method for implementing traffic call detail record (CDR) billing in the above embodiments.
[0150] like Figure 10 As shown, a preferred embodiment of this application also provides a computer device, which may be a terminal or a liveness detection server, and its internal structure diagram may be as follows. Figure 10 As shown. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with other external computer devices via a network connection. When the computer program is executed by the processor, it implements the steps of the above-described method for implementing traffic-based call detail record (DDR) billing.
[0151] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0152] A preferred embodiment of this application also provides a storage medium, the storage medium including a stored program, which, when running, controls the device where the storage medium is located to execute the steps of the method for implementing traffic call detail record (CDR) billing in the above embodiments.
[0153] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.
[0154] If the functions described in this embodiment are implemented as software functional units and sold or used as independent products, they can be stored in one or more computing device-readable storage media. Based on this understanding, the parts of this application's embodiments that contribute to the prior art or the technical solutions can be embodied in the form of software products. These software products are stored in a storage medium and include several instructions to cause a computing device (which may be a personal computer, server, mobile computing device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage media include: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.
[0155] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application can be implemented in various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.
[0156] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0157] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0158] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0159] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.
[0160] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A method for implementing data traffic call detail record (CDR) billing, characterized in that, Including the following steps: S1. After a user successfully purchases a product, a user traffic ledger is generated periodically. The user traffic ledger includes traffic volume, validity period, and product code. Specific steps include: S101. After a user successfully purchases a product on the China Unicom billing platform, the user's billing details are generated through the user billing platform. S102. Synchronize the user's billing bills from the user billing platform through the batch processing service of the traffic billing platform, and generate the user traffic ledger for the current month based on the relevant data carried in the billing bills. The user traffic ledger includes traffic volume, validity period, and product code. S103. Push the user's traffic billing records to the cached data service through the batch processing service of the traffic billing platform, and notify the partner platform of the user's traffic status; S2. When a user uses the data-free service, the system will authenticate the user's data usage in real time, check the user's remaining data information, and if the data usage exceeds the threshold, the system will promptly implement data control and restriction, and the user will no longer be allowed to enjoy the data-free service. S3. Collect user traffic call detail records (CDRs) including service-related parameters from the China Unicom CDN platform or partner platform at a set period for subsequent user traffic calculation and deduction. The service-related parameters include user ID and service ID. The specific steps include: S31. Collect user traffic usage information through the DES platform, generate and synchronize user traffic call detail records (CDRs) to the file storage server of the traffic CDR billing platform, including user identifier, partner code, traffic consumption value, and usage time. S32. The user traffic call detail record (CDR) file is retrieved from the file storage server at a predetermined frequency through the batch processing service of the traffic call detail record (CDR) billing platform, and the data in the user traffic CDR file is parsed. The parsed user traffic CDR is then pushed to the data bus service of the traffic call detail record (CDR) billing platform. S33. The partner platform uses API interface to push user traffic call details in real time. The traffic call details billing platform capability interface service receives user traffic call details and sends them to the traffic call details billing platform data bus service. S4. After collecting and parsing the user traffic call details, compare the traffic balance of the corresponding user ID and service ID in the user traffic ledger based on the parsing results of the user traffic call details, and calculate and update the traffic balance of different service IDs of the user. S5. Query the database for users who need to receive traffic surplus notifications, and notify both the partners and the users respectively.
2. The method for implementing traffic-based call detail record (CDR) billing according to claim 1, characterized in that, Step S1 further includes the following steps: S111. Periodically query the billing details of the current month that have not been canceled through the batch processing service of the traffic billing platform, generate the user traffic ledger for the next period, and update it to the cached data service. S112. Periodically query the billing details of unsubscribed services in the current month through the batch processing service of the traffic billing platform, and query the user traffic account book from the data cache service. S113. If a user traffic ledger already exists, update the validity period of the user traffic ledger to expire.
3. The method for implementing traffic-based call detail record (CDR) billing according to claim 1, characterized in that, Step S2 specifically includes the following steps: S21. When a user plays a video on the partner platform client, the partner platform client queries the server for the user's remaining bandwidth. If there is remaining bandwidth, the video playback request is sent to the DES platform for bandwidth proxy acceleration. S22. After receiving the traffic proxy request through the DES platform, parse the relevant data in the request link, including mobile phone number, partner code, and product code information; S23. Obtain the user's remaining data information by requesting the traffic authentication interface of the traffic call detail record billing platform capability interface service through the DES platform. S24. Parse the relevant parameters transmitted through the traffic call detail record billing platform capability interface service, query the user's traffic account book from the cached data service according to the mobile phone number and product code, and feed back the user's remaining traffic to the DES platform; S25. If the traffic billing platform capability interface service determines that the current user traffic ledger has no traffic ledger, then the user's information will be pushed to the data bus service. S26. Obtain relevant user information from the data bus service through batch processing service, query the user's billing bill in the database, and if a valid billing bill is found, regenerate the user traffic ledger and update it in the cached data service. When the S27 and DES platforms receive a user's remaining data balance that is not 0, they will use the free data proxy channel to allow the user to enjoy free video playback. If the remaining data balance is 0, a specific encoded error will be returned, and the partner platform client will prompt the user that they cannot enjoy the free data service.
4. The method for implementing traffic-based call detail record (CDR) billing according to claim 1, characterized in that, Step S4 specifically includes the following steps: S41. Obtain undeducted user traffic records from the data bus service through the batch processing service of the traffic record billing platform, and calculate the traffic value in the user traffic records. S42. Obtain the user traffic ledger from the cached data service of the traffic call detail record billing platform through batch processing service, and deduct the remaining traffic in the user traffic ledger. S43. The deducted traffic balance is corrected to the user's traffic ledger through batch processing service and updated to the cache data service of the traffic call detail record billing platform. S44. Query the trigger threshold of user traffic notification through batch processing service, determine whether the user's current traffic balance triggers the traffic notification condition, and if it has been triggered, save the user information that needs to be notified of the remaining traffic balance to the database, and save the deducted traffic call details to the data bus service. S45. Obtain the deducted traffic call details from the data bus service through the batch processing service and save them to the database for easy customer service inquiry later.
5. The method for implementing traffic-based call detail record (CDR) billing according to claim 1, characterized in that, Step S5 specifically includes the following steps: S51. Query the database for users who need to be notified through the batch processing service of the traffic call detail record billing platform; S52. Call the API interface of the partner platform to notify the partner platform of the remaining traffic. S53. Notify users of remaining data allowance via SMS.
6. An apparatus for implementing data traffic call detail record (CDR) billing, for implementing the method as described in any one of claims 1-5, characterized in that, include: The user traffic ledger generation module is used to generate a user traffic ledger through periodic calculations after a user successfully purchases a product. The user traffic ledger includes traffic volume, validity period, and product code. The data usage limit control and authentication module is used to authenticate users' data usage in real time when they use data-free services. If the user's remaining data exceeds the threshold, data usage will be restricted and the user will no longer be allowed to enjoy the data-free service. The user traffic call detail record (CDR) collection module is used to collect user traffic CDRs, including service-related parameters, from the China Unicom CDN platform or partner platform at a set period for subsequent user traffic calculation and deduction. The service-related parameters include user ID and service ID. The traffic deduction module is used to collect and parse user traffic call records, compare the traffic balance of the corresponding user ID and service ID in the user traffic ledger based on the parsing results of the user traffic call records, and calculate and update the traffic balance of different service IDs of the user. The traffic notification module is used to query the database for users who need to be notified of remaining traffic, and then notify both partners and users respectively.
7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method for implementing traffic call detail record (CDR) billing as described in any one of claims 1 to 5.
8. A storage medium comprising a stored program, characterized in that, When the program is running, it controls the device where the storage medium is located to perform the steps of the method for implementing traffic call detail record (CDR) billing as described in any one of claims 1 to 5.