Method and device for constructing call record configuration, electronic device and storage medium

Abstract

This invention discloses a method, apparatus, electronic device, and readable storage medium for constructing call detail record (CDR) configurations, relating to the field of computer data processing technology. It includes: parsing a custom CDR configuration file; constructing a CDR configuration cache in the form of a linked list of attribute nodes organized in output order and a vendor attribute mapping hash table; receiving billing service messages and determining the vendor identifier based on the access device type information they carry; sequentially retrieving values ​​according to the output order of the attribute nodes; reprocessing the attribute values ​​according to the attribute type to obtain field values; and concatenating the field values ​​into a CDR string using a delimiter. This invention decouples the CDR generation logic from the service scenario and access device message format, allowing adaptation to new access devices or new CDR rules without modifying the core code and redeploying. Furthermore, it unifies the management of multi-vendor private attributes through composite key hash mapping, improving the compatibility and adaptation flexibility of heterogeneous message parsing.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for constructing call detail record (CDR) configurations, an electronic device, and a storage medium. Background Technology

[0002] In the field of billing support for communication networks, call detail records (CDRs) are structured data records formed by collecting, parsing, and integrating billing service data generated by access devices. They are widely used in network management and service operation support. Authentication, authorization, and billing servers need to generate CDR strings based on the billing service messages reported by access devices for use in subsequent data processing stages.

[0003] In related technologies, call detail record (CDR) output is mostly implemented through custom development, with the CDR generation logic deeply bound to specific business scenarios and the message formats of specific access devices. When business requirements change or new access devices need to be adapted, the program code often needs to be modified and redeployed, resulting in long development cycles, high maintenance difficulty, and limitations on the system's response speed and scalability to diverse business needs.

[0004] Some related technologies attempt to store call detail record (CDR) generation rules through configuration files or databases, but most remain at the level of simple parameter adjustments, lacking unified control over the entire CDR generation process. Meanwhile, access devices from different vendors often use different proprietary attribute names for semantically identical attributes, making it difficult to uniformly parse heterogeneous packets across vendors and networks using fixed templates. With the convergence of fixed-line and mobile services and the increasing diversification of access methods, the original billing service packets generated by access devices such as broadband remote access servers have complex and significantly different formats, exacerbating the aforementioned problems.

[0005] It is evident that the relevant technologies suffer from technical problems such as high coupling between the call detail record (CDR) generation logic and business scenarios and access device message formats, difficulty in adapting to heterogeneous messages from multiple vendors, and the need to modify and redeploy code to adapt to new requirements. Therefore, it is necessary to propose a technical solution that can decouple the CDR generation logic, support dynamic configuration of CDR generation rules, and have high scalability. Summary of the Invention

[0006] The present invention aims to provide a method, apparatus, electronic device and storage medium for constructing call detail record (CDR) configurations to overcome the shortcomings of the prior art. The technical problem to be solved by the present invention is achieved through the following technical solutions.

[0007] According to a first aspect of this application, a method for constructing call detail record (CDR) configurations is provided, comprising the following steps: S1: Parse the custom call detail record (CDR) configuration file and construct a CDR configuration cache and a vendor attribute mapping hash table; wherein, the CDR configuration cache is an attribute node linked list, and the vendor attribute mapping hash table stores the mapping relationship between vendor identifier, attribute name and vendor private attribute name; S2: Receive the billing service message and determine the target vendor identifier based on the access device type information carried in the billing service message; S3: Traverse each attribute node in the call detail record configuration cache. If the current attribute node is a standard attribute, extract the corresponding attribute value directly from the billing service message. If the current attribute node is a vendor attribute, search based on the target vendor identifier and the attribute name of the attribute node, match the corresponding vendor private attribute name in the vendor attribute mapping hash table, and extract the attribute value from the billing service message based on the vendor private attribute name. S4: Based on the attribute type of the current attribute node, perform data type conversion or segmentation on the extracted attribute values ​​to obtain the corresponding field values; S5: According to the separator specified in the custom call detail record configuration file, concatenate the values ​​of each field into a call detail record string in the organizational order of the attribute node linked list.

[0008] Preferably, the custom call detail record (CDR) configuration file is an Extensible Markup Language (XML) structure, which includes delimiters, an attribute list, and a list of vendor attribute mapping relationships. Each attribute definition in the attribute list includes output sequence number, attribute name, attribute sequence number, manufacturer sequence number, value type, value separator, separator value sequence number, and value prefix; Each vendor attribute mapping relationship in the vendor attribute mapping relationship list is represented by a string consisting of a vendor identifier, an attribute name, and a vendor-private attribute name.

[0009] Preferably, the attribute node linked list is a singly linked list organized in the output order; The attribute node includes an attribute name field, a value prefix field, an attribute number field, a value type field, a manufacturer identifier field, a separator field, a value retrieval number field, and a linked list pointer field. Multiple attribute nodes are linked together through the linked list pointer field. The delimiter field uses only the first character, and the attribute name field, the value prefix field, and the manufacturer identifier field all end with a string terminator.

[0010] Preferably, multiple composite keys consisting of different manufacturer identifiers and the same attribute name are all mapped to the output field corresponding to the same attribute name in the manufacturer attribute mapping hash table, so that the manufacturer private attribute name and the attribute name form a many-to-one mapping relationship.

[0011] Preferably, the value type corresponding to the attribute type of the attribute node includes at least one of string, integer, Internet Protocol version 4 address, date, binary, byte, Internet Protocol version 6 interface identifier, Internet Protocol version 6 address, and Internet Protocol version 6 prefix.

[0012] Preferably, in step S4, the extracted attribute values ​​are converted or segmented according to the attribute type of the current attribute node to obtain the corresponding field values, including: When the value type is a string, the attribute value is prefixed according to the value prefix of the attribute node, or the attribute value is segmented according to the delimiter of the attribute node and the Nth field is extracted as the field value, or the attribute value is directly used as the field value, where N is the value sequence number of the delimiter of the attribute node; When the value type is an integer, the attribute value is stored as the field value in a numeric structure; When the value type is an Internet Protocol address, the address conversion interface is called to convert the attribute value into the field value in string form.

[0013] According to a second aspect of this application, an apparatus for flexible call detail record (CDR) configuration construction using the above-described CDR configuration construction method is provided, comprising: The configuration parsing module is used to parse the custom call detail record (CDR) configuration file and build a CDR configuration cache and a vendor attribute mapping hash table. The CDR configuration cache is an attribute node linked list, and the vendor attribute mapping hash table stores the mapping relationship between vendor identifier, attribute name and vendor private attribute name. The vendor identification module is used to receive billing service messages and determine the target vendor identifier based on the access device type information carried in the billing service messages. The attribute value extraction module is used to traverse each attribute node in the call detail record (CDR) configuration cache. If the current attribute node is a standard attribute, the corresponding attribute value is directly extracted from the billing service message. If the current attribute node is a vendor attribute, the module searches based on the target vendor identifier and the attribute name of the attribute node, matches the corresponding vendor private attribute name in the vendor attribute mapping hash table, and extracts the attribute value from the billing service message based on the vendor private attribute name. The field value processing module is used to perform data type conversion or segmentation processing on the extracted attribute values ​​according to the attribute type of the current attribute node to obtain the corresponding field values; The call detail record (CDR) splicing module is used to splice the values ​​of each field into a CDR string according to the organization order of the attribute node linked list, based on the delimiters specified in the custom CDR configuration file.

[0014] Preferably, the attribute node linked list is a singly linked list organized in the output order; The configuration parsing module is specifically used to construct a singly linked list containing multiple concatenated attribute nodes, wherein each attribute node includes an attribute name field, a value prefix field, an attribute number field, a value type field, a manufacturer identifier field, a separator field, a value retrieval number field, and a linked list pointer field, and multiple attribute nodes are concatenated through the linked list pointer field; The delimiter field uses only the first character, and the attribute name field, the value prefix field, and the manufacturer identifier field all end with a string terminator.

[0015] According to a third aspect of this application, an electronic device is provided, the device comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the above-described method for constructing call detail record (CDR) configurations.

[0016] According to a fourth aspect of this application, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described method for constructing call detail record (CDR) configurations.

[0017] The embodiments of the present invention have the following advantages: This achieves decoupling of call detail record (CDR) generation logic from business scenarios and access device message formats. The field sorting, value retrieval criteria, delimiters, and data types of CDRs are all defined by a custom CDR configuration file. When the CDR generation rules are adjusted or new access devices are added, only the configuration file needs to be updated without modifying the core code of the CDR processing device and redeploying it, thereby shortening the processing flow for adapting to new requirements.

[0018] By using a vendor attribute mapping hash table with a composite key consisting of vendor identifier and attribute name, unified mapping and dynamic retrieval of private attributes from multiple vendors are achieved. This solves the problem of heterogeneous packet adaptation caused by different vendor access devices using different private attribute names for semantically identical attributes, and improves the compatibility and adaptation flexibility of call detail record (CDR) parsing.

[0019] The call detail record (CDR) configuration cache uses a singly linked list of attribute nodes organized in the output order. Combined with prefix recognition, delimiter segmentation, digital structured storage, and Internet Protocol address format conversion of attribute values ​​according to attribute type, it enables message attributes from different sources and with different formats to be uniformly parsed and concatenated into a CDR string with a consistent format, thereby improving the consistency and reliability of CDR data processing. Attached Figure Description

[0020] Figure 1 This is a flowchart of a method for constructing call detail record (CDR) configuration according to the present invention; Figure 2 This is a structural block diagram of a device for flexible configuration and construction of call detail records according to the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device according to the present invention; Figure 4 This is a schematic diagram of the structure of a computer storage medium according to the present invention. Detailed Implementation

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] It should be noted that the above detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0023] The example environment in which the call detail record (CDR) configuration construction method of this invention is applied includes an access device, a CDR processing device, configuration and dictionary files, and a CDR output file. The access device can be a broadband remote access server, a network access server, or a base station device, etc., which generates billing service messages and reports them to the CDR processing device during the process of providing access services to terminals. The configuration and dictionary files include a custom CDR configuration file and a dictionary file, wherein the custom CDR configuration file is used to define the CDR generation rules, and the dictionary file is used to store the correspondence between attribute numbers and attribute names. The CDR processing device can be deployed in an authentication, authorization, and billing server, which parses the billing service messages reported by the access device according to the configuration and dictionary files, generates CDR strings, and writes them to the CDR output file.

[0024] like Figure 1 As shown, the flow of the call detail record (CDR) configuration construction method provided in this embodiment of the invention includes the following steps: Step S1: Parse the custom call detail record (CDR) configuration file and construct a CDR configuration cache and a vendor attribute mapping hash table. Specifically, the CDR processing device reads the custom CDR configuration file upon startup. This custom CDR configuration file adopts an Extensible Markup Language (Extreme Markup Language) structure, and its root node includes a delimiter, an attribute list, and a vendor attribute mapping relationship list. Based on the output sequence number of each attribute defined in the attribute list, the CDR processing device constructs a linked list of attribute nodes organized in output order as a CDR configuration cache. Each attribute node in the linked list corresponds to a CDR field to be output. Simultaneously, based on the vendor attribute mapping relationship list, the CDR processing device constructs a vendor attribute mapping hash table that maps a composite key consisting of a vendor identifier and an attribute name to a vendor-specific attribute name.

[0025] Each attribute node includes an attribute name field, a value prefix field, an attribute sequence number field, a value type field, a vendor identifier field, a separator field, a value retrieval sequence number field, and a linked list pointer field. In some embodiments, the attribute name field, value prefix field, and vendor identifier field are fixed-length character arrays terminated by a string terminator; for example, the lengths of the attribute name field, value prefix field, and vendor identifier field can all be set to 256 bytes. The separator field is a fixed-length character array, and only its first character is used; for example, the length of the separator field can be set to 10 bytes, and the call detail record (CDR) processing device only reads its first character. The attribute sequence number field, value type field, and value retrieval sequence number field are integers. The linked list pointer field points to the next attribute node, and multiple attribute nodes are linked together via the linked list pointer field to form a singly linked list of the CDR configuration cache. In one implementation, the structure of the attribute node can be given an alias so that it can be referenced during the processing of the CDR processing device.

[0026] For attributes with the same semantics but different private attribute names in access devices from different vendors, the call detail record (CDR) processing device uses a composite key consisting of the vendor identifier and the attribute name as the key of the hash table, and the vendor's corresponding private attribute name as the value of the hash table. For example, for the same attribute to be output, the access device of the first vendor uses the private attribute name A-Attr1, and the access device of the second vendor uses the private attribute name B-Attr2. Then, a mapping relationship is established in the vendor attribute mapping hash table, from the composite key "first vendor - attribute name" to A-Attr1, and from the composite key "second vendor - attribute name" to B-Attr2, so that the private attribute names of different vendors form a many-to-one mapping relationship with the same attribute name.

[0027] For example, the structure of a custom call detail record (CDR) XML configuration file is shown in the table below:

[0028] Step S2: Receive the billing service message and determine the vendor identifier based on the access device type information carried in the billing service message. Specifically, the message receiving module receives the billing service message reported by the access device and directly confirms the vendor by checking the vendor code (VENDOR) of the sub-attribute of RADIUS attribute 26 carried in the billing service message; or, by checking the source IP address of the service message, the module retrieves the corresponding configuration from the locally configured BRAS information configuration. This configuration contains vendor information, thereby identifying the vendor to which the access device reporting the message belongs and obtaining the vendor identifier. This vendor identifier is used for subsequent composite key retrieval of vendor attributes.

[0029] Step S3: Read the attribute nodes sequentially according to the output order of the attribute nodes in the call detail record (CDR) configuration cache, and extract the attribute values. The process of generating the CDR string by processing attribute nodes includes the following steps: Read an unprocessed attribute node from the call detail record (CDR) configuration cache in the order of output.

[0030] The configured attribute name is retrieved from the dictionary file based on the attribute number of the attribute node.

[0031] The manufacturer identifier field of the attribute node determines whether the attribute corresponding to the attribute node is a standard attribute or a manufacturer attribute.

[0032] For standard attributes, the call detail record (CDR) processing device directly extracts the attribute value corresponding to the attribute from the billing service message. For vendor attributes, the call detail record (CDR) processing device generates a composite key based on the vendor identifier determined in step S2 and the attribute name of the attribute node, and uses the composite key to search in the vendor attribute mapping hash table to obtain the vendor private attribute name corresponding to the vendor. Then, it extracts the attribute value from the billing service message based on the vendor private attribute name.

[0033] Step S4: Reprocess the extracted attribute values ​​according to the attribute type of the attribute node to obtain field values. In some embodiments, the value types corresponding to the attribute types of the attribute nodes include strings, integers, Internet Protocol version 4 (IP4) addresses, dates, binary, bytes, Internet Protocol version 6 (IP6) interface identifiers, IPC addresses, and IPC prefixes. The call detail record (CDR) processing device reprocesses the extracted attribute values ​​according to the value type of the attribute node as follows: when the value type is a string, the CDR processing device performs prefix identification on the attribute value according to the value prefix of the attribute node, or segments the attribute value according to the delimiter of the attribute node and takes the Nth field after segmentation, or directly uses the attribute value as the field value, where N is the delimiter value sequence number of the attribute node; when the value type is an integer, the CDR processing device stores the attribute value as a field value in a numerical structure; when the value type is an Internet Protocol address, the CDR processing device calls the address conversion interface to convert the attribute value from binary form to string form as a field value.

[0034] Determine if all attribute nodes in the call detail record (CDR) configuration cache have been processed. If some attribute nodes are still unprocessed, return to read the next attribute node; if all attribute nodes have been processed, proceed to the next step.

[0035] Step S5: Concatenate the values ​​of each field into a call detail record (CDR) string according to the output order and the separator in the call detail record configuration.

[0036] Specifically, the call detail record (CDR) splicing module concatenates the field values ​​corresponding to each attribute node in the output order according to the delimiter defined in the custom CDR configuration file, obtaining a complete CDR string. It retains null values ​​or placeholders for attributes not found in the vendor attribute mapping hash table to ensure that the positional correspondence of fields in the CDR string does not shift. In some embodiments, the default delimiter in the CDR configuration is a comma. The generated CDR string is written to the CDR output file.

[0037] Example 1 is illustrated using an exemplary application scenario. A billing support platform simultaneously connects to access devices from a first vendor and a second vendor, requiring the generation of call detail records (CDRs) in a standardized format for attributes such as access duration, traffic, and access point type. Technical personnel write a custom CDR configuration file based on the requirements, defining the output sequence number, attribute name, and value type for each field in the attribute list, and configuring the access point type field as a vendor attribute; in the vendor attribute mapping relationship list, they configure mapping relationships where the composite key "first vendor - access point type" maps to the vendor's private attribute name, and the composite key "second vendor - access point type" maps to the vendor's private attribute name. After receiving the billing service message reported by the first vendor's access device, the call detail record (CDR) processing device first parses the configuration file to build a CDR configuration cache and vendor attribute mapping hash table, and determines the vendor identifier as the first vendor based on the access device type information carried in the message. Then, it processes the access point type field in the output order. Since this field is a vendor attribute, it retrieves the vendor's private attribute name from the hash table using the composite key "first vendor - access point type", and then extracts the attribute value from the message based on this private attribute name. If the attribute value is a string and has a configured delimiter and delimiter value sequence number, it is split and the corresponding field is taken as the field value. After all fields are processed, the complete CDR string is concatenated according to the configured delimiter and output.

[0038] In another embodiment of this application, the vendor type of the access device changes. Based on the above embodiments, when the billing support platform adds an access device from a third vendor, since the third vendor's access device uses a vendor-private attribute name for the access point type attribute that is different from both the first and second vendors, the call detail record (CDR) processing device does not need to modify its core code and redeploy. Technical personnel only need to add the mapping relationship from the composite key "third vendor - access point type" to the third vendor's private attribute name to the vendor attribute mapping relationship list in the custom CDR configuration file. When the CDR processing device parses the custom CDR configuration file again, it will construct this newly added mapping relationship into the vendor attribute mapping hash table, enabling compatible parsing of billing service messages reported by the third vendor's access device and generating CDR strings. Therefore, this embodiment has good adaptability, flexibility, and scalability in a multi-vendor environment.

[0039] In another embodiment of this application, the value type processing method for attributes differs. The attribute list defined in the custom call detail record (CDR) configuration file includes traffic attributes with integer values ​​and access address attributes with Internet Protocol version 4 (IP4) addresses. For traffic attributes with integer values, the CDR processing device stores the attribute value extracted from the packet as a field value in a numerical structure in step S4. For access address attributes with IPM address values, the CDR processing device calls the address conversion interface in step S4 to convert the address attribute value stored in binary form into a dotted decimal string value. This embodiment can be applied to different deployment scenarios such as broadband access services and mobile data services, and performs unified format conversion and splicing of packet attributes from different sources and with different formats.

[0040] like Figure 2 As shown, this embodiment of the invention provides a device for flexible configuration and construction of call detail records (CDRs), which can be implemented as follows: Figure 1 The call detail record (CDR) processing method, the device includes: The configuration parsing module is used to parse the custom call detail record (CDR) configuration file and build a CDR configuration cache and a vendor attribute mapping hash table. The CDR configuration cache is an attribute node linked list, and the vendor attribute mapping hash table stores the mapping relationship between vendor identifier, attribute name and vendor private attribute name. The vendor identification module is used to receive billing service messages and determine the target vendor identifier based on the access device type information carried in the billing service messages. The attribute value extraction module is used to traverse each attribute node in the call detail record (CDR) configuration cache. If the current attribute node is a standard attribute, the corresponding attribute value is directly extracted from the billing service message. If the current attribute node is a vendor attribute, the module searches based on the target vendor identifier and the attribute name of the attribute node, matches the corresponding vendor private attribute name in the vendor attribute mapping hash table, and extracts the attribute value from the billing service message based on the vendor private attribute name. The field value processing module is used to perform data type conversion or segmentation processing on the extracted attribute values ​​according to the attribute type of the current attribute node to obtain the corresponding field values; The call detail record (CDR) splicing module is used to splice the values ​​of each field into a CDR string according to the organization order of the attribute node linked list, based on the delimiters specified in the custom CDR configuration file.

[0041] Each of the above modules can be used to execute the corresponding steps in the method, and the corresponding beneficial effects will not be elaborated here.

[0042] Figure 3A block diagram of a computing device that can be used to implement embodiments of the present invention is shown. The computing device includes a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) or loaded from a memory unit into a random access memory (RAM). The RAM may also store various programs and data required for the operation of the computing device. The CPU, ROM, and RAM are interconnected via a bus. Input / output interfaces are also connected to the bus.

[0043] Multiple components in a computing device are connected to input / output interfaces, including: input units such as a keyboard and mouse; output units such as various types of displays and speakers; storage units such as hard disks and optical disks; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication units allow the computing device to exchange information or data with other devices through computer networks such as the Internet and / or various telecommunications networks. The various steps of the call detail record (CDR) configuration construction method described above can be executed by the central processing unit of the computing device.

[0044] like Figure 4 As shown, in some embodiments, the method for constructing the call detail record (CDR) configuration can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as a storage unit.

[0045] Part or all of the computer program may be loaded and / or installed onto a computing device via read-only memory and / or a communication unit. When the computer program is loaded into random access memory and executed by the central processing unit, one or more steps of the call detail record (CDR) configuration construction method described above may be performed. Alternatively, in other embodiments, the central processing unit may be configured in any other suitable manner to perform the CDR configuration construction method.

[0046] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0047] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein.

[0048] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0049] For ease of description, spatial relative terms such as "above," "on top of," "on the upper surface of," "above," etc., are used herein to describe the spatial positional relationship of a device or feature as shown in the figures to other devices or features. It should be understood that spatial relative terms are intended to encompass different orientations in use or operation beyond the orientation of the device as described in the figures. For example, if the device in the figures were inverted, a device described as "above" or "on top of" other devices or structures would subsequently be positioned as "below" or "under" other devices or structures. Thus, the exemplary term "above" can include both "above" and "below." The device may also be positioned in other different ways, such as rotated 90 degrees or in other orientations, and the spatial relative descriptions used herein will be interpreted accordingly.

[0050] In the detailed description above, reference has been made to the accompanying drawings, which form part of this document. In the drawings, similar symbols typically identify similar parts unless the context otherwise indicates otherwise. The illustrated embodiments described in the detailed specification, drawings, and claims are not intended to be limiting. Other embodiments may be used and other changes may be made without departing from the spirit or scope of the subject matter presented herein.

[0051] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method of call detail record configuration building, characterized by, Includes the following steps: S1: Parse the custom call detail record (CDR) configuration file and construct a CDR configuration cache and a vendor attribute mapping hash table; wherein, the CDR configuration cache is an attribute node linked list, and the vendor attribute mapping hash table stores the mapping relationship between vendor identifier, attribute name and vendor private attribute name; S2: Receive the billing service message and determine the target vendor identifier based on the access device type information carried in the billing service message; S3: Traverse each attribute node in the call detail record configuration cache. If the current attribute node is a standard attribute, extract the corresponding attribute value directly from the billing service message. If the current attribute node is a vendor attribute, search based on the target vendor identifier and the attribute name of the attribute node, match the corresponding vendor private attribute name in the vendor attribute mapping hash table, and extract the attribute value from the billing service message based on the vendor private attribute name. S4: Based on the attribute type of the current attribute node, perform data type conversion or segmentation on the extracted attribute values ​​to obtain the corresponding field values; S5: According to the separator specified in the custom call detail record configuration file, concatenate the values ​​of each field into a call detail record string in the organizational order of the attribute node linked list.

2. The method of slip configuration building according to claim 1, characterized in that, The custom call detail record (CDR) configuration file is an Extensible Markup Language (XML) structure, which includes delimiters, an attribute list, and a list of vendor attribute mapping relationships. Each attribute definition in the attribute list includes output sequence number, attribute name, attribute sequence number, manufacturer sequence number, value type, value separator, separator value sequence number, and value prefix; Each vendor attribute mapping relationship in the vendor attribute mapping relationship list is represented by a string consisting of a vendor identifier, an attribute name, and a vendor-private attribute name.

3. The method for constructing call detail record (CDR) configurations according to claim 1, characterized in that, The attribute node linked list is a singly linked list organized in the output order; The attribute node includes an attribute name field, a value prefix field, an attribute number field, a value type field, a manufacturer identifier field, a separator field, a value retrieval number field, and a linked list pointer field. Multiple attribute nodes are linked together through the linked list pointer field. The delimiter field uses only the first character, and the attribute name field, the value prefix field, and the manufacturer identifier field all end with a string terminator.

4. The method for constructing call detail record (CDR) configurations according to claim 1, characterized in that, Multiple composite keys consisting of different vendor identifiers and the same attribute name are all mapped to the output field corresponding to the same attribute name in the vendor attribute mapping hash table, so that the vendor private attribute name and the attribute name form a many-to-one mapping relationship.

5. The method for constructing call detail record (CDR) configurations according to claim 1, characterized in that, The value type corresponding to the attribute type of the attribute node includes at least one of the following: string, integer, Internet Protocol version 4 address, date, binary, byte, Internet Protocol version 6 interface identifier, Internet Protocol version 6 address, and Internet Protocol version 6 prefix.

6. The method for constructing call detail record (CDR) configurations according to claim 5, characterized in that, In step S4, the extracted attribute values ​​are converted or segmented according to the attribute type of the current attribute node to obtain the corresponding field values, including: When the value type is a string, the attribute value is prefixed according to the value prefix of the attribute node, or the attribute value is segmented according to the delimiter of the attribute node and the Nth field is extracted as the field value, or the attribute value is directly used as the field value, where N is the value sequence number of the delimiter of the attribute node; When the value type is an integer, the attribute value is stored as the field value in a numeric structure; When the value type is an Internet Protocol address, the address conversion interface is called to convert the attribute value into the field value in string form.

7. A flexible call detail record (CDR) configuration construction apparatus employing the CDR configuration construction method according to any one of claims 1 to 6, characterized in that, include: The configuration parsing module is used to parse the custom call detail record (CDR) configuration file and build a CDR configuration cache and a vendor attribute mapping hash table. The CDR configuration cache is an attribute node linked list, and the vendor attribute mapping hash table stores the mapping relationship between vendor identifier, attribute name and vendor private attribute name. The vendor identification module is used to receive billing service messages and determine the target vendor identifier based on the access device type information carried in the billing service messages. The attribute value extraction module is used to traverse each attribute node in the call detail record (CDR) configuration cache. If the current attribute node is a standard attribute, the corresponding attribute value is directly extracted from the billing service message. If the current attribute node is a vendor attribute, the module searches based on the target vendor identifier and the attribute name of the attribute node, matches the corresponding vendor private attribute name in the vendor attribute mapping hash table, and extracts the attribute value from the billing service message based on the vendor private attribute name. The field value processing module is used to perform data type conversion or segmentation processing on the extracted attribute values ​​according to the attribute type of the current attribute node to obtain the corresponding field values; The call detail record (CDR) splicing module is used to splice the values ​​of each field into a CDR string according to the organization order of the attribute node linked list, based on the delimiters specified in the custom CDR configuration file.

8. The call detail record (CDR) flexible configuration construction device according to claim 7, characterized in that, The attribute node linked list is a singly linked list organized in the output order; The configuration parsing module is specifically used to construct a singly linked list containing multiple concatenated attribute nodes, wherein each attribute node includes an attribute name field, a value prefix field, an attribute number field, a value type field, a manufacturer identifier field, a separator field, a value retrieval number field, and a linked list pointer field, and multiple attribute nodes are concatenated through the linked list pointer field; The delimiter field uses only the first character, and the attribute name field, the value prefix field, and the manufacturer identifier field all end with a string terminator.

9. An electronic device, characterized in that, The device includes: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the method for constructing call detail record (CDR) configurations according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for constructing call detail record (CDR) configurations according to any one of claims 1 to 6.

Images