Call bill processing method and device, equipment, storage medium and program product

Abstract

The invention discloses a call ticket processing method and device, equipment, a storage medium and a program product. The method comprises the following steps: acquiring an enhanced call ticket comprising basic call ticket feature data and value added service feature data; analyzing the enhanced call ticket according to a first service rule of the area to which the enhanced call ticket belongs, and generating to-be-processed data; the first service rule is a newly configured rule template for indicating a data processing mode of an area to which the currently monitored enhanced ticket belongs; performing data routing on the to-be-processed data according to a second service rule of the area to which the to-be-processed data belongs, wherein the second service rule is a newly configured rule template for indicating a data routing mode of the area to which the currently monitored enhanced ticket belongs; according to the invention, the value-added service feature data is expanded on the basis of the basic call ticket feature data, the multi-dimensional analysis requirement of the 5G new call service can be met, meanwhile, the processing of the enhanced call ticket can flexibly adapt to the differentiated processing requirements of different regions through the dynamic configuration of the service rule, and the data processing efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a call detail record (CDR) processing method, apparatus, device, storage medium, and program product. Background Technology

[0002] VoNR (Voice over New Radio) is a new 5G calling technology that supports high-definition voice and video calls, as well as various value-added services (such as fun calls and intelligent translation). Operators typically use a CDR (Call Detail Record) system to record basic call information.

[0003] Currently, the analysis of new 5G call services mainly adopts a fixed-rule service analysis method, which filters and statistically analyzes CDR records through predefined rules. However, traditional CDR records only contain basic information such as the calling and called numbers and call duration, and lack effective analysis tools for the usage characteristics of value-added services, which cannot meet the multi-dimensional analysis needs of new 5G call services. At the same time, the service analysis rules are pre-configured when the system goes online and cannot be dynamically adjusted according to the actual needs of different regions, resulting in an inability to adapt to differentiated regional processing requirements. Summary of the Invention

[0004] To address the problems existing in the prior art, embodiments of the present invention provide a call detail record (CDR) processing method, apparatus, device, storage medium, and program product, which can meet the multi-dimensional analysis needs of new 5G call services, and can flexibly adapt to the differentiated processing needs of different regions through dynamic rule configuration.

[0005] In a first aspect, embodiments of the present invention provide a call detail record (CDR) processing method, including: Obtain the enhanced call detail records (CDRs) to be processed; wherein, the enhanced CDRs include basic CDR feature data and value-added service feature data; The enhanced call detail records (CDRs) are parsed according to the first service rule of the region to which they belong, generating data to be processed; wherein, the first service rule is a rule template indicating the latest configured data processing method for the region to which the currently monitored enhanced CDRs belong. The data to be processed is routed according to the second service rule of the region to which it belongs. The second service rule is a rule template that indicates the latest configuration of the data routing method for the region to which the enhanced call detail record (CDR) belongs.

[0006] As an improvement to the above solution, the step of obtaining the enhanced call detail records to be processed includes: When a user initiates a new 5G call during a call, the system detects service operation events that trigger value-added services in real time and extracts the value-added service feature data of the detected service operation events. After the call ends, basic call detail record (CDR) feature data is obtained, and the enhanced CDR is generated based on the basic CDR feature data and the value-added service feature data.

[0007] As an improvement to the above solution, the real-time detection of service operation events that trigger value-added services and the extraction of value-added service feature data of the detected service operation events include: Real-time monitoring of the session initiation protocol message during a call; wherein the session initiation protocol message is extended with a setting header field; the setting header field is used to indicate the value-added services triggered during the call, including the service type field, function code field, and timestamp field of the value-added services; Regular expression matching is performed on the setting header field of the session initiation protocol message to detect business operation events in the session initiation protocol message in real time; Upon detecting a business operation event, value-added service feature data is extracted from the session initiation protocol message.

[0008] As an improvement to the above solution, the value-added service feature data includes: service subtype identifier, function usage identifier, call status identifier, and province identifier; The service subtype identifier is used to indicate the sub-function of the value-added service used by the user during the call; The function usage identifier is used to indicate the number of times the sub-function of the value-added service is triggered during the call; The call status indicator is used to indicate the end of the call; The province identifier is used to indicate the location of the user's number.

[0009] As an improvement to the above solution, the extraction of value-added service feature data from the session initiation protocol message includes: The service type field in the setting header field of the session initialization protocol message is matched using a pre-built thesaurus; wherein, the thesaurus includes keywords corresponding to each sub-function of the value-added service and feature codes corresponding to each sub-function of the value-added service; Based on the feature encoding of the matched keywords, the business subtype identifier is generated; The number of times the sub-functions of the value-added services corresponding to the matched keywords are triggered is encoded to generate the function usage identifier.

[0010] As an improvement to the above solution, the method further includes: The call status identifier is generated based on the network signaling status information indicating the end of the call in the session initiation protocol message.

[0011] The user's number is assigned a province code to generate the province identifier.

[0012] As an improvement to the above solution, the step of matching the business type field in the setting header field of the session initialization protocol message using a pre-built thesaurus includes: The keyword matching is performed on the business type field in the setting header field of the session initialization protocol message using the lexicon; If the keyword database contains keywords that match the business type field, retrieve the matched keywords; If no keyword matching the business type field exists in the thesaurus, fuzzy semantic matching is performed on the business type field to obtain the matched keyword.

[0013] As an improvement to the above solution, the step of performing fuzzy semantic matching on the business type field to obtain the matched keywords includes: The business type field is segmented into multiple subfields. Keyword matching is performed on multiple subfields using the aforementioned thesaurus; If the thesaurus contains keywords that match at least one of the subfields, retrieve at least one matched keyword; If no keyword matches any of the subfields in the thesaurus, the business type field is fuzzy matched using the thesaurus, and the keyword with the highest similarity to the business type field is obtained as the matched keyword.

[0014] As an improvement to the above solution, the step of parsing the enhanced call detail record (CDR) according to the first service rule of the region to generate data to be processed includes: Based on the provincial identifier of the value-added service feature data in the enhanced call detail record (CDR), a first service rule for the enhanced CDR is determined; wherein the first service rule includes at least one of the following: digital signature, data encryption, and data format conversion; The first service rule is executed on the enhanced call detail record (CDR) to generate data to be processed.

[0015] As an improvement to the above solution, the step of routing the data to be processed according to the second business rule of the region includes: The target node of the data to be processed is determined based on the corresponding provincial identifier of the data to be processed; Write the data to be processed into the push table; The data to be processed in the push table is pushed to the corresponding target node according to the second business rule of the region; wherein the data to be processed is written into the target storage table of the target node.

[0016] As an improvement to the above solution, the method further includes: Determine the common associated fields between the table to be pushed and the target storage table; Based on the associated fields and the target query value, construct a structured query statement; The structured query statement is executed to perform a related query, and the data to be processed that matches the target query value indicated by the related field in the table to be pushed and the target storage table is obtained. The value-added service usage details are extracted based on the matched data to be processed.

[0017] As an improvement to the above solution, the step of pushing the data to be processed in the push table to the corresponding target node according to the second business rule of the region includes: Rule matching is performed on each piece of data to be processed in the push table to determine a second business rule for each piece of data to be processed; wherein, the second business rule includes: data push mode and scheduling strategy; the data push mode includes real-time push mode and batch push mode; the scheduling strategy includes the time interval of the real-time push mode or the batch push mode and the number of retries for failure; A two-phase commit method is used to transmit each piece of data to be processed in the push table to the corresponding target node according to the corresponding second business rules.

[0018] Secondly, embodiments of the present invention provide a call detail record (CDR) processing apparatus, comprising: The call detail record (CDR) acquisition module is used to acquire enhanced CDRs to be processed; wherein, the enhanced CDRs include basic CDR feature data and value-added service feature data; The rule parsing module is used to parse the enhanced call detail record (CDR) according to the first service rule of the region to which it belongs, and generate data to be processed; wherein, the first service rule is the latest configured rule template of the region to which the enhanced CDR belongs, indicating the data processing method. The data routing module is used to route the data to be processed according to the second service rule of the region to which it belongs. The second service rule is a rule template that indicates the data routing method in the latest configuration of the region to which the enhanced call detail record belongs.

[0019] Thirdly, embodiments of the present invention provide a call detail record (CDR) processing device, comprising: a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the CDR processing method as described in any one of the first aspects.

[0020] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the call detail record (CDR) processing method as described in any one of the first aspects.

[0021] Fifthly, embodiments of the present invention provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the call detail record (CDR) processing method as described in any one of the first aspects.

[0022] Compared to existing technologies, this invention provides a call detail record (CDR) processing method, apparatus, device, storage medium, and program product. This involves acquiring enhanced CDRs of user calls, where the enhanced CDRs include basic CDR feature data and value-added service feature data. The enhanced CDRs are then parsed according to a first service rule for the region to which they belong, generating data to be processed. The first service rule is a rule template indicating the latest configured data processing method for the region to which the enhanced CDR belongs. The data to be processed is then routed according to a second service rule for the region, which is also a rule template indicating the latest configured data routing method for the region to which the enhanced CDR belongs. This invention expands upon the basic CDR feature data with value-added service feature data related to 5G new call services, meeting the multi-dimensional analysis needs of 5G new call services. Different regions can be dynamically configured with different service rules, enabling dynamic service rule configuration. The enhanced CDRs are processed using region-matched service rules, flexibly adapting to the differentiated processing needs of different regions and improving data processing efficiency. Attached Figure Description

[0023] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a call detail record (CDR) processing method provided in an embodiment of the present invention; Figure 2This is a schematic diagram of the call detail record (CDR) processing framework provided in an embodiment of the present invention; Figure 3 This is a structural block diagram of a call detail record (CDR) processing device provided in an embodiment of the present invention; Figure 4 This is a structural block diagram of a call detail record (CDR) processing device provided in an embodiment of the present invention. Detailed Implementation

[0025] 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, and 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.

[0026] It is understood that the various numerical designations used in the embodiments of this invention are merely for descriptive convenience and are not intended to limit the scope of this application. The order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

[0027] In embodiments of the invention, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element. The terms "a plurality or several" refer to two or more, and "at least one or more" refers to one or more.

[0028] Please see Figure 1 , Figure 1 This is a flowchart of a call detail record (CDR) processing method provided in an embodiment of the present invention. The CDR processing method specifically includes: S11: Obtain the enhanced call detail records (CDRs) to be processed; wherein, the enhanced CDRs include basic CDR feature data and value-added service feature data; The basic call detail record (CDR) feature data includes basic call information such as the caller's and called user's numbers and call duration; the value-added service feature data includes information related to value-added services for new 5G calls initiated by the user during the call, including: service subtype identifier, function usage identifier, call status identifier, and province identifier. The service sub-type identifier indicates the sub-function of the value-added service used by the user (i.e., the user initiating the new 5G call) during the call. Value-added services include fun calls, intelligent translation, etc., and different value-added services include different sub-functions. For example, the sub-functions of fun calls include emoji rain, gesture effects, virtual background replacement, etc.; the sub-functions of intelligent translation include Chinese to English, English to Chinese, Chinese to English to Japanese, etc. A two-level service classification system can be established to accurately distinguish various value-added services and their sub-functions.

[0029] The function usage identifier is used to indicate the number of times the sub-function of the value-added service is triggered (i.e., the number of times it is used) during the call. The call status indicator is used to indicate the end of the call; The provincial identifier is used to indicate the location of the user's (i.e., the user who initiated the new 5G call) number.

[0030] S12: The enhanced call detail record (CDR) is parsed according to the first service rule of the region to which it belongs, and data to be processed is generated; wherein, the first service rule is the latest configured rule template of the indication data processing method of the region to which the enhanced CDR currently belongs; S13: The data to be processed is routed according to the second service rule of the region to which it belongs, wherein the second service rule is the latest configured rule template indicating the data routing method of the region to which the enhanced call detail record belongs.

[0031] It should be noted that the call detail record (CDR) processing method described in this embodiment of the invention can be executed by a VoNR AS (Application Server). For example, a rule configuration platform, such as Nacos (Naming and Configuration Service), can be deployed. This platform enables the configuration and management (including adding, deleting, and modifying) of exclusive rule templates for each region (e.g., province). For instance, it allows for the configuration of exclusive first and second business rules for each province, thereby achieving dynamic configuration of business rules for different regions and improving rule flexibility. Specifically, the first business rule instructs that the enhanced CDRs for the corresponding region be processed according to a specified data processing method, and the second business rule instructs that the data to be processed generated after the enhanced CDR data processing for the corresponding region be routed according to a specified data routing method to push the data to be processed to the target node in the corresponding region.

[0032] This invention extends the basic call detail record (CDR) feature data to include value-added service feature data related to new 5G call services. This expands the dimensions of the original CDR records, meeting the multi-dimensional analysis needs of new 5G call services. Furthermore, by configuring different service rules for different regions, dynamic service rule configuration can be achieved. This enhances the processing of CDRs through dynamically configured service rules for different regions, allowing for flexible adaptation to the differentiated processing needs of different regions and improving data processing efficiency.

[0033] In one optional embodiment, obtaining the enhanced call detail record (CDR) to be processed includes: When a user initiates a new 5G call during a call, the system detects service operation events that trigger value-added services in real time and extracts the value-added service feature data of the detected service operation events. Specifically, the real-time detection of service operation events that trigger value-added services and the extraction of value-added service feature data from the detected service operation events include: Real-time monitoring of the session initiation protocol message during a call; wherein the session initiation protocol message is extended with a setting header field; the setting header field is used to indicate the value-added services triggered during the call, including the service type field, function code field, and timestamp field of the value-added services; Regular expression matching is performed on the setting header field of the session initiation protocol message to detect business operation events in the session initiation protocol message in real time; Upon detecting a business operation event, value-added service feature data is extracted from the session initiation protocol message.

[0034] After the call ends, obtain the basic call record feature data, and generate the enhanced call record according to the basic call record feature data and the value-added service feature data.

[0035] In the embodiment of the present invention, a service probe module is deployed in the application server, which is used to detect whether a service operation event of a value-added service of 5G new call is triggered in the Session Initiation Protocol (SIP) message flow during the call, and extract relevant value-added service feature data. The specific data extraction process of the service probe module is as follows: Expand a custom set header field in the SIP (Session Initiation Protocol) message, such as a Feature-ID custom header field, including a service type field, a function code field, and a timestamp field; the data format of this set header field is: Feature-ID: <service type field>; <function code field>; timestamp field. Among them, the service type field is used to indicate the sub-function of the service type of the triggered value-added service; the function code field is used to indicate the coding information of the sub-function of the service type of the triggered value-added service; the timestamp field is used to indicate the time when the value-added service is triggered.

[0036] For the SIP messages generated during the call, extract the fields (i.e., the content of the set header field) that conform to the rules indicated by the regular expression (such as Feature-ID: <service type field>; <function code field>; timestamp field) in the SIP message through a regular expression, and determine whether a value-added service is triggered according to the extracted set header field; for example, the data content in the set header field of a SIP message at a certain moment is: Feature-ID: <Fun Call>; <111>; 20231127163500000; indicating that the user initiated the fun call service of 5G new call at 16:35 on November 27, 2023, that is, a service operation event is detected; another example, the data content in the set header field of a SIP message at a certain moment is: Feature-ID: <Null (null value)>; <Null (null value)>; 20231127162000000; indicating that the user did not initiate the value-added service of 5G new call at 16:20 on November 27, 2023, that is, no service operation event is detected.

[0037] Upon detecting a business operation event, relevant business features are extracted. These features are the contents of designated header fields extracted using regular expressions, including business type, function code, and timestamp fields. Aggregating all business features during the call generates value-added business feature data. The enhanced call detail record (CDR) generation module combines the basic CDR feature data and value-added business feature data to generate enhanced CDRs with expanded record dimensions, meeting the multi-dimensional analysis needs of new 5G calls. Furthermore, business feature extraction does not require parsing the specific information content of SIP messages; it only requires matching the designated header fields of SIP messages using regular expressions. This reduces the complexity of feature extraction, improves data processing efficiency, reduces the risk of call content exposure, and enhances call security.

[0038] Specifically, the step of extracting value-added service feature data from the session initiation protocol message includes: The service type field in the setting header field of the session initialization protocol message is matched using a pre-built thesaurus; wherein, the thesaurus includes keywords corresponding to each sub-function of the value-added service and feature codes corresponding to each sub-function of the value-added service; Based on the feature encoding of the matched keywords, the business subtype identifier is generated; The feature codes corresponding to the sub-functions of value-added services can be generated using 3-bit BCD (Binary-Coded Decimal) codes. For example, "021" represents English-to-Chinese translation (sub-function, secondary category) of intelligent translation (value-added service, primary category).

[0039] This invention, through its embodiments, pre-constructs keywords corresponding to various sub-functions of different value-added services, as well as feature codes corresponding to each sub-function of the value-added services. For example, it constructs a predefined lexicon containing all possible keywords for the emoticon rain, namely the oms_funtel_gesture table. This table can be a relational database table containing two fields: keyword (keywords for emoticon rain) and code (standardized feature codes).

[0040] Then, the extracted content of the set header field is subjected to keyword matching based on the thesaurus to find the matching keywords, and the corresponding business subtype identifier (service_sub_type) is generated based on the matching keywords and the corresponding feature codes.

[0041] The number of times the sub-functions of the value-added services corresponding to the matched keywords are triggered is encoded to generate the function usage identifier.

[0042] The usage of value-added services in new 5G calls initiated by users during a call is recorded using TLV (Type-Length-Value) encoding, generating a feature usage identifier (feature_used). For example, a feature usage identifier (feature_used) of "T: 0xA1, L: 2, V: 0x0003" indicates that the "Emoji Rain - Spring Festival Special Effect" was triggered 3 times. 0xA1 indicates that the "Emoji Rain - Spring Festival Special Effect" (a sub-function of the fun call) was triggered 3 times, 0x0003 indicates that it was triggered 3 times, and 2 indicates the length of the V value (i.e., 0x0003). TLV encoding can support accurate recording of complex service scenarios. For example, the number of times the corresponding sub-function of the value-added service was triggered can be obtained by statistically analyzing the data recorded in the header field of the same service type and function encoding.

[0043] Furthermore, the call status identifier is generated based on the network signaling status information indicating the end of the call in the session initiation protocol message.

[0044] For example, a call status flag (end_flag) can be generated through a state machine model to indicate the integrity of the call, i.e., the end of the call. For instance, after the call ends, the state machine model sets the call status flag (end_flag) to "end" based on the network signaling status information, indicating that the call has ended and the call is complete, which can trigger subsequent processing procedures.

[0045] The user's number is assigned a province code to generate the province identifier.

[0046] For example, a standard province code is generated based on the location of the number segment in the user's number as a province identifier, which serves as the basis for data routing. For instance, if a calling user initiates a new 5G call, and the location of the number segment in the user's number is province Y, the province code (i.e., the province identifier) ​​is "YN530". The enhanced call detail records (CDRs) for this call can then be pushed to the target node corresponding to province Y.

[0047] This invention extends the CDR call detail record (CDR) structure, dynamically stores service features using BCD and TLV encoding, and achieves semantic standardization matching through a predefined lexicon (oms_funtel_gesture table). Combined with the end_flag state machine, it accurately determines the service completion status, ensuring data integrity. This expands the dimensions of CDR records, constructs a complete service profile, and solves the problem of insufficient dimensions in traditional CDR analysis. While maintaining compatibility with existing billing systems, it improves service analysis capabilities by 8 times, supporting refined operations from "whether it is used" to "how it is used," meeting the service analysis needs of new 5G calls.

[0048] Specifically, the matching of the business type field in the setting header field of the session initialization protocol message using a pre-built thesaurus includes: The keyword matching is performed on the business type field in the setting header field of the session initialization protocol message using the lexicon; If the keyword database contains keywords that match the business type field, retrieve the matched keywords; If no keyword matching the business type field exists in the thesaurus, fuzzy semantic matching is performed on the business type field to obtain the matched keyword.

[0049] The step of performing fuzzy semantic matching on the business type field to obtain the matched keywords includes: The business type field is segmented into multiple subfields. Keyword matching is performed on multiple subfields using the aforementioned thesaurus; If the thesaurus contains keywords that match at least one of the subfields, retrieve at least one matched keyword; If no keyword matches any of the subfields in the thesaurus, the business type field is fuzzy matched using the thesaurus, and the keyword with the highest similarity to the business type field is obtained as the matched keyword.

[0050] For example, when a user initiates a new 5G call for a value-added service (such as a fun call), the application server's service probe module captures the service operation event in real time and extracts the service type field from the setting header field of the SIP message that triggers the sub-function (such as an emoji rain) and performs keyword matching with a predefined thesaurus (oms_funtel_gesture table). The specific matching process is as follows: Semantic standardization and precise matching: When a user triggers an emoji rain event, the field that triggered the emoji rain (i.e., the business type field) is written to the configuration header field of the SIP message. After detecting the business operation event, the business probe module extracts the corresponding business type field and performs precise matching with keywords in the thesaurus (oms_funtel_gesture table). If a keyword matching the business type field is found (i.e., a keyword consistent with the business type field), the feature code of the corresponding keyword is directly obtained as the business subtype identifier. If no keyword matching the business type field is found, further processing is required, such as word segmentation and fuzzy matching.

[0051] Word segmentation matching: If the exact match above fails, the business type field that triggers the emoji rain will be segmented into multiple sub-fields. Then, each sub-field will be matched again with keywords in the thesaurus (oms_funtel_gesture table). If a keyword matching the business type field is found, its feature code will be used as part of the business sub-type identifier. All the feature codes corresponding to the found keywords will be concatenated according to the string order of the corresponding sub-fields to generate a complete business sub-type identifier. If no keyword matching the business type field is found, further processing, such as fuzzy matching, is required.

[0052] Fuzzy matching: If word segmentation also fails, the business type field that triggered the emoji rain will be fuzzily matched with keywords in the thesaurus (oms_funtel_gesture table). For example, the similarity between the business type field and each keyword in the thesaurus will be calculated based on algorithms such as edit distance and similarity. Then, the feature code corresponding to the keyword with the highest similarity will be selected as the business subtype identifier.

[0053] In this embodiment of the invention, after completing the matching process, a service sub-type identifier is generated based on the matching result. This identifier can be a standardized feature code, such as a predefined 32-bit feature code, or a combination of feature codes dynamically generated based on the matching result. By employing precise matching, word segmentation matching, and fuzzy matching, the accuracy of value-added service identification during a call can be improved. In one optional embodiment, parsing the enhanced call detail record (CDR) according to the first service rule of the region to generate data to be processed includes: Based on the provincial identifier of the value-added service feature data in the enhanced call detail record (CDR), a first service rule for the enhanced CDR is determined; wherein the first service rule includes at least one of the following: digital signature, data encryption, and data format conversion; The first service rule is executed on the enhanced call detail record (CDR) to generate data to be processed.

[0054] In this embodiment of the invention, the application server deploys a call detail record (CDR) parsing engine to read rule templates (such as the first business rule and the second business rule) for each region (such as a province) in the rule configuration platform. Different regions have different data processing requirements for enhanced call detail records. The required data processing methods are configured through the first business rule, such as digital signature, data encryption, and data format conversion.

[0055] For example, when end_flag=end and province is the corresponding province, the enhanced call detail record (CDR) is written to the push table (oms_single_funtel_user_usage_push table) to cache the data that needs to be pushed.

[0056] Based on the primary business rules for different regions, it can be determined that data to be processed that needs to be pushed to the corresponding region requires special processing. This special processing includes one or more of the following: Digital signature: Specific provinces require special digital signature processes to verify the signatures of data to be processed. Adding a specific digital signature to the data ensures its integrity and authenticity.

[0057] Data encryption: Special encryption logic is required for specific provinces. For example, it may be necessary to perform special encryption processing on the data to be processed in that region to ensure data security.

[0058] Data format conversion: Special data format conversion logic is required for specific provinces. For example, it may be necessary to convert the data to be processed into a specific data format in order to interact with other systems or services.

[0059] It should be noted that the digital signature method, encryption algorithm, and data format required by different regions can be configured in the first business rule, and are not specifically limited in this embodiment of the invention.

[0060] In one optional embodiment, the step of routing the data to be processed according to the second business rule of the region includes: The target node of the data to be processed is determined based on the corresponding provincial identifier of the data to be processed; Write the data to be processed into the push table; The data to be processed in the push table is pushed to the corresponding target node according to the second business rule of the region; wherein the data to be processed is written into the target storage table of the target node.

[0061] In this embodiment of the invention, the province identifier of the value-added service feature data in the data to be processed can be used to determine the region to which the data to be processed needs to be sent. This determines the target node of the data to be processed as the database of the region to which it needs to be sent, such as the provincial database. The processed data is then rewritten into the push table (oms_single_funtel_user_usage_push table), overwriting the corresponding enhanced call detail records (CDRs) in the push table (oms_single_funtel_user_usage_push table). Then, data routing is performed according to the second service rules of the respective regions in the push table (oms_single_funtel_user_usage_push table) to push each piece of data to be processed to its corresponding target node.

[0062] In this embodiment of the invention, the region to which the data belongs is first identified by the provincial identifier, and then the data is routed according to the second business rule of that region (such as data push mode, target storage table). This avoids routing deviations caused by applying uniform static rules to all regions and can adapt to the differentiated operation needs of operators by province.

[0063] Specifically, the step of pushing the data to be processed in the push table to the corresponding target node according to the second business rule of the region includes: Rule matching is performed on each piece of data to be processed in the push table to determine a second business rule for each piece of data to be processed; wherein, the second business rule includes: data push mode and scheduling strategy; the data push mode includes real-time push mode and batch push mode; the scheduling strategy includes the time interval of the real-time push mode or the batch push mode and the number of retries for failure; A two-phase commit method is used to transmit each piece of data to be processed in the push table to the corresponding target node according to the corresponding second business rules.

[0064] In this embodiment of the invention, a dynamic rule-based driving mechanism is used to implement service filtering and data processing of the 5G new call service analysis system. This is mainly achieved by defining a series of dynamic rules (such as a second service rule) to describe the filtering conditions and processing actions of the data to be processed, thereby enabling flexible configuration and dynamic adjustment of the service processing logic. It supports independent configuration of service filtering strategies for each province. The specific implementation method is as follows: Rule definition: A series of dynamic second business rules are defined using a specific rule definition language (such as XML, JSON, etc.), including the conditions and actions of the rules, as described above, and will not be repeated here.

[0065] Rule loading: The defined second business rules are loaded into the system through the rule hot loading engine. The hot loading and dynamic updating of rules can be achieved through the rule configuration platform.

[0066] Rule matching: When new data to be processed is received (for example, new data to be processed is written to the push table), the system will match the conditions of the second business rule to find all rules that meet the conditions.

[0067] Rule execution: For the matched second business rule, the action part of the rule is executed in a certain order (such as the priority of the second business rule) to process the data to be processed (such as data push, data aggregation, etc.).

[0068] Rule feedback: During the execution of the second business rule, feedback and adjustments can be made as needed, such as adjusting the priority of the second business rule, modifying the conditions or actions of the dynamic rule, etc.

[0069] The second business rules specific to each region include three main elements: 1. Triggering conditions: This is used to indicate the conditions that must be met for data in the push table (oms_single_funtel_user_usage_push table) to be pushed. For example, you can configure the service type, end flag (such as time window thresholds, e.g., service_sub_type='02' AND end_flag='end', which means that data will be routed for data with service type 02 (e.g., 02 represents Fun Call - Emoji Rain) and call status is end.

[0070] 2. Execution Actions: Configure the data push mode (i.e., data routing action) in the execution actions, such as real-time push mode and batch push mode. You can also configure the target storage table, field mapping relationship, aggregation strategy (such as counting the occurrence frequency of the keywords (rain_keywords_used) corresponding to the emoji rain), exception handling actions, etc.

[0071] Data routing: Data processing for a specific province may involve special data routing logic. For example, it may be necessary to route user data to specific addresses for subsequent processing or analysis.

[0072] Anomaly handling (also known as fault tolerance): Data processing for a specific province may involve special anomaly handling logic. For example, special handling may be required for abnormal situations, such as stopping data push and triggering an alarm if the number of retries for failed transmission exceeds the limit, in order to ensure the stability and reliability of the system.

[0073] 3. Scheduling strategy: Configure runtime parameters such as data scanning interval (e.g., 10 minutes) and number of retries on failure (e.g., maximum of 5 times).

[0074] Administrators in each region can modify the configuration of the first and second business rules according to actual needs. The application server listens to the configuration changes of the business rules in each region and loads the latest business rules in real time, so that the new rules take effect within 300 milliseconds, avoiding business interruption due to system restart.

[0075] An example application server deploys a province-specific database router to dynamically select physical storage nodes, i.e., target nodes, based on the province identifier. For example, data from province X is routed to the province X's database for independent storage, achieving data sovereignty isolation. The specific process is as follows: A scheduled task (Province Futel Push Job) is used to periodically scan the data to be processed in each provincial database of the push table and perform the following key operations: 1. Time window filtering: Filter by time window create_time < (current time) Using the condition of 10 minutes, filter out the data to be processed for province=YN530; 2. Business Feature Aggregation: Through the feature aggregation engine, multiple pending data entries with the same call_record_id (i.e., the identifier of the enhanced call detail record, a unique identifier for a single call session) are counted according to service_sub_type to count the number of times the corresponding keywords appear. For example, the number of times the keywords corresponding to the emoticon rain indicated by service_sub_type=02 are counted. 3. Encryption and signature processing: Sensitive fields such as user number (caller_user_phone) are encrypted through the user service core module and HMAC-SHA256 digital signature is added.

[0076] Furthermore, field-level encryption can be employed to encrypt 11 types of sensitive fields (such as user number and call duration), for example, using AES-256 encryption. By employing the AES encryption algorithm and encrypting sensitive fields, user privacy and data security can be protected.

[0077] 4. Provincial-level interface calls: Through secure transmission modules, such as the sidecar-open-service-core (affiliated open service core) component, the standardized data packets to be processed after the above processing are pushed to the corresponding provincial sub-databases.

[0078] This invention embodiment uses the sidecar-open-service-core component as an interface to ensure data transmission channel security at the sidecar layer, providing link security guarantees. Measures to ensure data transmission channel security include: Two-way authentication: Two-way authentication is implemented at the sidecar layer to ensure the legitimacy of the communicating parties. This is achieved by using digital certificates and key pairs to verify the identities of both parties and ensure the confidentiality and integrity of the data.

[0079] Encrypted transmission: Encrypted transmission is implemented at the sidecar layer to ensure data security during transmission. By using encryption algorithms to encrypt data, it is possible to prevent eavesdropping or tampering during transmission.

[0080] Access control: Implement access control at the sidecar layer to ensure that only authorized users or systems can access sensitive data. By using access control policies, access permissions to sensitive data can be restricted, and data security can be ensured.

[0081] Logging: Logging is implemented at the sidecar layer (i.e., the oms_single_funtel_user_usage_push_log table below) to ensure the traceability of data transmission. By recording key information during data transmission, the data transmission path and access records can be traced, thereby detecting abnormal behavior or security threats.

[0082] Security Audit: Implement security auditing at the sidecar layer to ensure compliance during data transmission. By regularly auditing data transmission logs and access control policies, potential security vulnerabilities or violations can be identified, and appropriate remedial measures can be taken promptly.

[0083] Audit traceability: The complete operation trajectory is recorded through the oms_single_funtel_user_usage_push_log table to meet compliance requirements.

[0084] By encrypting the aforementioned sensitive fields and implementing security measures for the data transmission channel, end-to-end secure data transmission can be achieved.

[0085] Furthermore, this embodiment of the invention can also implement provincial data governance. By allocating an independent database instance to each province and using the `province` field for automatic routing, physical data isolation is achieved. Specifically, a real-time push mode (10-minute interval) can be configured for some provinces, meaning data is pushed every 10 minutes. Other provinces can use a T+1 batch processing mode, where T is a timestamp representing a specific point in time. In the T+1 batch processing mode, T represents the current time, and T+1 represents the day after the current time, meaning data from the previous day is pushed in batches.

[0086] It also allows for data lifecycle management, setting the maximum retention period for data in the oms_single_funtel_user_usage_push table to 7 days, after which it will be automatically archived.

[0087] For example, the execution process of the push and exception handling phases is as follows: The push task controller scans the push list every 10 minutes and performs the following actions on the data that meets the conditions of the second business rule of each province: Parameter standardization assembly: Construct a JSON message containing orderNumber (caller number), peerNumber (called number), and funtelRecords (emoji rain statistics, obtained by aggregating and processing the above business features) for the data to be pushed, and push the data. Failure retry mechanism: The number of JSON message sending failures is recorded by the failure count (error_times) field. A progressive retry strategy of 1 / 5 / 15 / 15 / 15 minutes is adopted. If the number of retries reaches 5, it will be transferred to manual handling. Transaction consistency guarantee: A two-phase commit protocol is adopted to ensure the atomicity of data deletion in the push table (oms_single_funtel_user_usage_push table) and writing to the log table (oms_single_funtel_user_usage_push_log table). Details are as follows: Preparation Phase: After a piece of data in the `oms_single_funtel_user_usage_push` table has been sent, when it's necessary to delete that data from the `oms_single_funtel_user_usage_push` table, the deletion operation is first executed as part of a transaction. Specifically, before the deletion operation, a log record is written to the `oms_single_funtel_user_usage_push_log` table, recording relevant information about the deletion operation. Then, the deletion operation is executed, and based on the execution result, an ACK (indicating successful deletion) or NACK (indicating deletion failure) message is sent to the transaction coordinator.

[0088] Commit phase: If the deletion operation is successful and all participants (i.e., the execution units responsible for performing specific operations such as "log writing" and "data deletion") return ACK messages, the transaction coordinator sends a COMMIT message to all participants to commit the transaction.

[0089] After receiving the COMMIT message, the participant performs a local commit operation, which includes deleting data from the oms_single_funtel_user_usage_push table and the corresponding log record from the commit log table oms_single_funtel_user_usage_push_log.

[0090] If all participants return ACK messages, the transaction coordinator completes the transaction commit; if any participant returns NACK messages, the transaction coordinator sends a ROLLBACK (instruction to roll back) message to all participants, rolling back the transaction.

[0091] By employing a two-phase commit approach to perform data push, it is ensured that when data is deleted from the oms_single_funtel_user_usage_push table, a log record is simultaneously written to the oms_single_funtel_user_usage_push_log table. Furthermore, both operations either succeed or fail, thus guaranteeing data consistency.

[0092] Furthermore, the method also includes: Determine the common associated fields between the table to be pushed and the target storage table; Based on the associated fields and the target query value, construct a structured query statement; The structured query statement is executed to perform a related query, and the data to be processed that matches the target query value indicated by the related field in the table to be pushed and the target storage table is obtained. The value-added service usage details are extracted based on the matched data to be processed.

[0093] This invention establishes a provincial database association query mechanism to obtain business usage details. Taking `call_record_id` as the key field, and using the target storage table (oms_funtel_user_usage_record table) of the linked region as an example, the specific implementation process of the association query mechanism is as follows: Determine the associated field: In the oms_single_funtel_user_usage_push and oms_funtel_user_usage_record tables, determine a common field, call_record_id, as the associated field.

[0094] Construct an SQL (Structured Query Language) statement: Based on the defined related fields, construct an SQL statement to query the oms_single_funtel_user_usage_push and oms_funtel_user_usage_record tables.

[0095] Execute the constructed SQL statement to perform a join query; through this query, data matching the call_record_id field value can be obtained from the oms_single_funtel_user_usage_push and oms_funtel_user_usage_record tables.

[0096] Processing query results: Process the queried data to extract the required value-added service usage details, including but not limited to: user number, service type, service subtype, service usage time, and number of service usages (e.g., based on).

[0097] Compared with the prior art, the beneficial effects of the embodiments of the present invention are as follows: By deploying a service probe module on the VoNR application server, the Feature-ID header field in SIP messages is deeply parsed, and value-added service feature data is extracted in real time using regular expressions. Simultaneously, by expanding the CDR call detail record (CDR) fields, multiple new service feature dimensions are added to meet the multi-dimensional analysis needs of new 5G calls. The rule configuration platform enables dynamic loading of provincial-level XML rule templates (effective within 300ms), supporting real-time adjustment of differentiated analysis strategies for each province. This solves the problem of traditional fixed-rule systems being unable to adapt to the needs of multiple provinces, achieving minute-level effectiveness of differentiated analysis strategies for each province and avoiding system downtime for upgrades. It also improves the completeness of service feature collection from 65% to 99% and supports efficient processing of 100,000 CDRs per second.

[0098] A dynamic routing mechanism for provincial databases is implemented based on the `province` field, allocating an independent database instance to each province. This ensures data sovereignty and query efficiency, reduces database I / O pressure, and improves data processing efficiency and queryability. Combined with streaming computing frameworks, such as... Figure 2 As shown, operations such as time window filtering, business feature aggregation (e.g., TLV encoding parsing), and encrypted signature (AES-256+HMAC-SHA256) are performed in parallel. A two-phase commit protocol ensures transaction consistency, and two-way authentication and encrypted transmission are implemented at the Sidecar layer. This solves the efficiency and security risks caused by mixed data storage in traditional systems, reducing data processing latency to the 10-minute level and lowering the risk of user privacy leakage by 99.6%.

[0099] By extending the CDR (Call Detail Record) structure, BCD and TLV encoding are used to dynamically store service features, while semantic standardization matching is achieved through a predefined thesaurus. Combined with the end_flag state machine, the service completion status is accurately determined, ensuring data integrity. This solves the problem of insufficient dimensions in traditional call detail record analysis. While maintaining compatibility with existing billing systems, the service analysis capability is improved by 8 times, supporting refined operations from "whether it is used" to "how it is used".

[0100] See Figure 3 , Figure 3 This is a structural block diagram of a call detail record (CDR) processing device provided in an embodiment of the present invention. The CDR processing device includes: The call detail record (CDR) acquisition module 11 is used to acquire enhanced CDRs to be processed; wherein, the enhanced CDRs include basic CDR feature data and value-added service feature data; Rule parsing module 12 is used to parse the enhanced call detail record (CDR) according to the first service rule of the region to which it belongs, and generate data to be processed; wherein, the first service rule is the latest configured rule template of the region to which the enhanced CDR belongs, indicating the data processing method. The data routing module 13 is used to route the data to be processed according to the second service rule of the region to which it belongs, wherein the second service rule is the latest configured rule template indicating the data routing method of the region to which the enhanced call detail record belongs.

[0101] In one optional embodiment, the call detail record (CDR) acquisition module 11 includes: The service probe unit is used to detect service operation events that trigger value-added services in real time when a user initiates a new 5G call during a call, and to extract the value-added service feature data of the detected service operation events in real time. The call detail record (CDR) generation unit is used to obtain basic CDR feature data after the call ends, and generate the enhanced CDR based on the basic CDR feature data and the value-added service feature data.

[0102] In one optional embodiment, the service probe unit includes: The message listening subunit is used to listen to the session initialization protocol message during the call in real time; wherein, the session initialization protocol message is extended with a setting header field; the setting header field is used to indicate the value-added service triggered during the call, including the service type field, function code field, and timestamp field of the value-added service; The regular expression matching subunit is used to perform regular expression matching on the set header field of the session initialization protocol message in order to detect business operation events in the session initialization protocol message in real time. The business feature extraction subunit is used to extract value-added business feature data from the session initiation protocol message when a business operation event is detected.

[0103] In one optional embodiment, the value-added service feature data includes: service subtype identifier, function usage identifier, call status identifier, and province identifier; The service subtype identifier is used to indicate the sub-function of the value-added service used by the user during the call; The function usage identifier is used to indicate the number of times the sub-function of the value-added service is triggered during the call; The call status indicator is used to indicate the end of the call; The province identifier is used to indicate the location of the user's number.

[0104] In one optional embodiment, the business feature extraction subunit includes: The matching subunit is used to match the service type field in the setting header field of the session initialization protocol message using a pre-built lexicon; wherein, the lexicon includes keywords corresponding to each sub-function of the value-added service and feature codes corresponding to each sub-function of the value-added service; The sub-unit is used to generate the business sub-type identifier based on the feature encoding of the matched keywords; The encoding subunit is used to encode the number of times the sub-function of the value-added service corresponding to the matched keyword is triggered, and to generate the function usage identifier.

[0105] In an optional embodiment, the device further includes: The call status identifier generation module is used to generate the call status identifier based on the network signaling status information indicating the end of the call in the session initiation protocol message.

[0106] The provincial identifier generation module is used to encode the province of the user's number and generate the provincial identifier.

[0107] In one optional embodiment, the matching subunit includes: The first keyword matching subunit is used to perform keyword matching on the business type field in the setting header field of the session initialization protocol message using the thesaurus. The first keyword determination subunit is used to obtain the matched keyword when the keyword database contains a keyword that matches the business type field; The fuzzy semantic matching subunit is used to perform fuzzy semantic matching on the business type field and obtain the matched keywords when there are no keywords in the thesaurus that match the business type field.

[0108] In one optional embodiment, the fuzzy semantic matching subunit includes: The word segmentation subunit is used to segment the business type field into multiple subfields; The second keyword matching subunit is used to match keywords for multiple subfields using the thesaurus; The second keyword determination subunit is used to obtain at least one matched keyword when the vocabulary contains keywords that match at least one of the subfields. The fuzzy matching subunit is used to perform fuzzy matching on the business type field through the thesaurus when there are no keywords in the thesaurus that match all the subfields, and to obtain the keyword with the highest similarity to the business type field as the matched keyword.

[0109] In an optional embodiment, the rule parsing module 12 includes: The first rule determination unit is used to determine the first service rule of the enhanced call detail record (CDR) based on the provincial identifier of the value-added service feature data in the enhanced CDR; wherein the first service rule includes at least one of the following: digital signature, data encryption, and data format conversion; The first rule execution unit is used to execute the first service rule on the enhanced call detail record (CDR) and generate data to be processed.

[0110] In an optional embodiment, the data routing module 13 includes: The target node determination unit is used to determine the target node of the data to be processed based on the corresponding provincial identifier of the data to be processed. A data writing unit is used to write the data to be processed into a table to be pushed. The second rule execution unit is used to push the data to be processed in the push table to the corresponding target node according to the second business rule of the region; wherein the data to be processed is written into the target storage table of the target node.

[0111] In an optional embodiment, the device further includes: The associated field determination module is used to determine the associated fields common to the table to be pushed and the target storage table; The structured query statement construction module is used to construct a structured query statement based on the associated fields and the target query value; The structured query statement execution module is used to execute the structured query statement to perform a related query, obtain the data to be processed in the table to be pushed and the target storage table that matches the target query value indicated by the related field, and extract the value-added service usage details based on the matched data to be processed.

[0112] In one optional embodiment, the second rule execution unit includes: The rule matching subunit is used to perform rule matching on each of the data to be processed in the push table to determine the second business rule for each of the data to be processed; wherein, the second business rule includes: data push mode and scheduling strategy; the data push mode includes real-time push mode and batch push mode; the scheduling strategy includes the time interval of the real-time push mode or the batch push mode and the number of retries for failure; The data transmission subunit is used to transmit each piece of data to be processed in the push table to the corresponding target node in accordance with the corresponding second business rules using a two-phase commit method.

[0113] It should be noted that the working process of each module in the call detail record (CDR) processing device described in the embodiments of the present invention can refer to the working process of the CDR processing method described in the above embodiments, and the technical effect achieved is the same as that of the CDR processing method described in the above embodiments, so it will not be repeated here.

[0114] See Figure 4 , Figure 4 This is a structural block diagram of a call detail record (CDR) processing device provided in an embodiment of the present invention. The CDR processing device includes a processor 21, a memory 22, and a computer program stored in the memory 22 and executable on the processor 21. When the processor 21 executes the computer program, it implements the steps in the above-described CDR processing method embodiments, such as steps S11 to S13.

[0115] For example, the computer program can be divided into one or more modules / units, which are stored in the memory 22 and executed by the processor 21 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the call detail record (CDR) processing device.

[0116] The call detail record (CDR) processing device may include, but is not limited to, a processor 21 and a memory 22. Those skilled in the art will understand that the schematic diagram is merely an example of a CDR processing device and does not constitute a limitation on the device. It may include more or fewer components than illustrated, or combine certain components, or use different components. For example, the CDR processing device may also include input / output devices, network access devices, buses, etc.

[0117] The processor 21 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 21 is the control center of the call detail record (CDR) processing equipment, connecting all parts of the equipment via various interfaces and lines.

[0118] The memory 22 can be used to store the computer programs and / or modules. The processor 21 implements various functions of the call detail record (CDR) processing device by running or executing the computer programs and / or modules stored in the memory 22 and calling the data stored in the memory 22. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0119] If the modules / units integrated into the call detail record (CDR) processing equipment are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 21, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0120] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0121] The above description represents the preferred embodiments of the present invention. It should be noted that, for those skilled in the art, various improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A call detail record (CDR) processing method, characterized in that, include: Obtain the enhanced call detail records (CDRs) to be processed; wherein, the enhanced CDRs include basic CDR feature data and value-added service feature data; The enhanced call detail records (CDRs) are parsed according to the first service rule of the region to which they belong, generating data to be processed; wherein, the first service rule is a rule template indicating the latest configured data processing method for the region to which the currently monitored enhanced CDRs belong. The data to be processed is routed according to the second service rule of the region to which it belongs. The second service rule is a rule template that indicates the latest configuration of the data routing method for the region to which the enhanced call detail record (CDR) belongs.

2. The call detail record (CDR) processing method as described in claim 1, characterized in that, The process of obtaining the enhanced call detail records to be processed includes: When a user initiates a new 5G call during a call, the system detects service operation events that trigger value-added services in real time and extracts the value-added service feature data of the detected service operation events. After the call ends, basic call detail record (CDR) feature data is obtained, and the enhanced CDR is generated based on the basic CDR feature data and the value-added service feature data.

3. The call detail record (CDR) processing method as described in claim 2, characterized in that, The real-time detection of service operation events that trigger value-added services, and the extraction of value-added service feature data from the detected service operation events, include: Real-time monitoring of the session initiation protocol message during a call; wherein the session initiation protocol message is extended with a setting header field; the setting header field is used to indicate the value-added services triggered during the call, including the service type field, function code field, and timestamp field of the value-added services; Regular expression matching is performed on the setting header field of the session initiation protocol message to detect business operation events in the session initiation protocol message in real time; Upon detecting a business operation event, value-added service feature data is extracted from the session initiation protocol message.

4. The call detail record (CDR) processing method as described in claim 3, characterized in that, The value-added service feature data includes: service subtype identifier, function usage identifier, call status identifier, and province identifier; The service subtype identifier is used to indicate the sub-function of the value-added service used by the user during the call; The function usage identifier is used to indicate the number of times the sub-function of the value-added service is triggered during the call; The call status indicator is used to indicate the end of the call; The province identifier is used to indicate the location of the user's number.

5. The call detail record (CDR) processing method as described in claim 4, characterized in that, The step of extracting value-added service feature data from the session initiation protocol message includes: The service type field in the setting header field of the session initialization protocol message is matched using a pre-built thesaurus; wherein, the thesaurus includes keywords corresponding to each sub-function of the value-added service and feature codes corresponding to each sub-function of the value-added service; Based on the feature encoding of the matched keywords, the business subtype identifier is generated; The number of times the sub-functions of the value-added services corresponding to the matched keywords are triggered is encoded to generate the function usage identifier.

6. The call detail record (CDR) processing method as described in claim 4, characterized in that, The method further includes: The call status identifier is generated based on the network signaling status information indicating the end of the call in the session initiation protocol message; The user's number is assigned a province code to generate the province identifier.

7. The call detail record (CDR) processing method as described in claim 5, characterized in that, The matching of the business type field in the setting header field of the session initialization protocol message using a pre-built thesaurus includes: The keyword matching is performed on the business type field in the setting header field of the session initialization protocol message using the lexicon; If the keyword database contains keywords that match the business type field, retrieve the matched keywords; If no keyword matching the business type field exists in the thesaurus, fuzzy semantic matching is performed on the business type field to obtain the matched keyword.

8. The call detail record (CDR) processing method as described in claim 7, characterized in that, The step of performing fuzzy semantic matching on the business type field to obtain the matched keywords includes: The business type field is segmented into multiple subfields. Keyword matching is performed on multiple subfields using the aforementioned thesaurus; If the thesaurus contains keywords that match at least one of the subfields, retrieve at least one matched keyword; If no keyword matches any of the subfields in the thesaurus, the business type field is fuzzy matched using the thesaurus, and the keyword with the highest similarity to the business type field is obtained as the matched keyword.

9. The call detail record (CDR) processing method as described in claim 4, characterized in that, The step of parsing the enhanced call detail record (CDR) according to the first service rule of the region to generate data to be processed includes: Based on the provincial identifier of the value-added service feature data in the enhanced call detail record (CDR), a first service rule for the enhanced CDR is determined; wherein, the first service rule includes at least one of the following: digital signature, data encryption, and data format conversion; The first service rule is executed on the enhanced call detail record (CDR) to generate data to be processed.

10. The call detail record (CDR) processing method as described in claim 4, characterized in that, The step of routing the data to be processed according to the second business rule of the region includes: The target node of the data to be processed is determined based on the corresponding provincial identifier of the data to be processed; Write the data to be processed into the push table; The data to be processed in the push table is pushed to the corresponding target node according to the second business rule of the region; wherein the data to be processed is written into the target storage table of the target node.

11. The call detail record (CDR) processing method as described in claim 10, characterized in that, The method further includes: Determine the common associated fields between the table to be pushed and the target storage table; Based on the associated fields and the target query value, construct a structured query statement; The structured query statement is executed to perform a related query, and the data to be processed that matches the target query value indicated by the related field in the table to be pushed and the target storage table is obtained. The value-added service usage details are extracted based on the matched data to be processed.

12. The call detail record (CDR) processing method as described in claim 10, characterized in that, The step of pushing the data to be processed in the push table to the corresponding target node according to the second business rule of the region includes: Rule matching is performed on each piece of data to be processed in the push table to determine a second business rule for each piece of data to be processed; wherein, the second business rule includes: data push mode and scheduling strategy; the data push mode includes real-time push mode and batch push mode; the scheduling strategy includes the time interval of the real-time push mode or the batch push mode and the number of retries for failure; A two-phase commit method is used to transmit each piece of data to be processed in the push table to the corresponding target node according to the corresponding second business rules.

13. A call detail record (CDR) processing device, characterized in that, include: The call detail record (CDR) acquisition module is used to acquire enhanced CDRs to be processed; wherein, the enhanced CDRs include basic CDR feature data and value-added service feature data; The rule parsing module is used to parse the enhanced call detail record (CDR) according to the first service rule of the region to which it belongs, and generate data to be processed; wherein, the first service rule is the latest configured rule template of the region to which the enhanced CDR belongs, indicating the data processing method. The data routing module is used to route the data to be processed according to the second service rule of the region to which it belongs. The second service rule is a rule template that indicates the data routing method in the latest configuration of the region to which the enhanced call detail record belongs.

14. A call detail record (CDR) processing device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the call detail record (CDR) processing method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the call detail record (CDR) processing method as described in any one of claims 1 to 12.

16. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the call detail record (CDR) processing method according to any one of claims 1 to 12.

Images