Call record processing method, device and equipment and storage medium

Abstract

The disclosure provides a call processing method, device, equipment and storage medium, and relates to the technical field of communication. The method comprises the following steps: obtaining an original call from a relay node, wherein the original call is generated based on a target session identifier, an identifier of an upstream node, an identifier of the relay node and original charging data, the target session identifier is used for identifying and distinguishing original data forwarded by the relay node, and the upstream node is a previous node of the relay node; and based on the original call, target charging data of the relay node is calculated.

Description

Technical Field

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

[0002] With the rapid development of mobile communication technology, people's demand for wireless communication anytime and anywhere has also increased, thus giving rise to various new communication technologies.

[0003] Near-field communication systems, such as D2D (Device-to-Device), allow users to directly transmit data by reusing cellular resources. This reduces user-end transmit power while increasing the spectral efficiency of hybrid cellular and D2D networks, effectively alleviating the problem of scarce spectrum resources. In near-field communication systems, remote terminals access the cellular network via single-hop or multi-hop connections. In this coverage extension scenario, the near-field communication system is controlled by the cellular network; node updates and selection can be entirely triggered by the network side, and remote terminals do not necessarily need to know the information of all relay nodes providing relay forwarding services.

[0004] Therefore, the existing call detail record (CDR) processing methods are no longer applicable in the aforementioned multi-hop trunk scenarios, and a new CDR processing solution is urgently needed.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] This disclosure provides a call detail record (CDR) processing method, apparatus, device, and storage medium, which at least partially solves the problem that CDR processing methods in related technologies are not applicable to the aforementioned multi-hop trunk scenarios.

[0007] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0008] According to one aspect of this disclosure, a call detail record (CDR) processing method is provided, applied to a CDR processing node, the method comprising:

[0009] The original call detail records (CDRs) are obtained from the relay node. The original CDRs are generated based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the relay node. The upstream node is the node preceding the relay node.

[0010] Based on the original call detail records (CDRs), calculate the target billing data for the trunk nodes.

[0011] In one embodiment of this disclosure, the original billing data is at least one of the following:

[0012] The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

[0013] In one embodiment of this disclosure, the target billing data for a trunk node is calculated based on the original call detail records (CDRs), including:

[0014] A directed graph is constructed based on the target session identifier, upstream node identifier, relay node identifier, and original billing data in each original call detail record (CDR).

[0015] Based on the directed graph, the target billing data for each relay node is calculated.

[0016] In one embodiment of this disclosure, a directed graph is constructed based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data in each original call detail record (CDR), including:

[0017] The N original call detail records (CDRs) to be processed are aggregated to obtain M target CDRs.

[0018] Based on the target session identifier, the M target call detail records (CDRs) are clustered to obtain P CDR groups; target CDRs belonging to the same CDR group have the same target session identifier.

[0019] Construct a directed graph for each call detail record (CDR) group;

[0020] The aggregation process includes the following steps:

[0021] Determine whether the target session identifier, the upstream node identifier, and the trunk node identifier are the same for different original call detail records;

[0022] The original billing data of the original call detail records (CDRs) with the same target session identifier, the same upstream node identifier, and the same trunk node identifier are added together to obtain the aggregated original billing data of the target CDR.

[0023] In one embodiment of this disclosure, the target session identifier is generated based on the service request of the remote user to which the data forwarded by the relay node belongs, and is assigned by the network function that processes the service request.

[0024] In one embodiment of this disclosure, the target session identifier is the identifier of the PDU session to which the data forwarded by the relay node belongs.

[0025] In one embodiment of this disclosure, the target session identifier is generated based on the temporary identifier of the remote user to which the data forwarded by the relay node belongs; the temporary identifier of the remote user to which the data forwarded by the relay node belongs is assigned by the base station providing services to the remote user.

[0026] In one embodiment of this disclosure, obtaining the original call detail record (CDR) from a relay node includes:

[0027] Based on a preset period, the original call detail records (CDRs) are obtained from the relay nodes.

[0028] According to another aspect of this disclosure, a call detail record (CDR) processing method is provided, applied to a trunk node, the method comprising:

[0029] Based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data, the original call detail record (CDR) is generated. The target session identifier is used to identify and distinguish the original data forwarded by the relay node, and the upstream node is the node preceding the relay node.

[0030] The original call detail records (CDRs) are sent to the CDR processing node so that the CDR processing node can calculate the target billing data for the trunk node based on the original CDRs.

[0031] In one embodiment of this disclosure, the original billing data is at least one of the following:

[0032] The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

[0033] According to another aspect of this disclosure, a call detail record (CDR) processing apparatus is provided, applied to a CDR processing node, the apparatus comprising:

[0034] The call detail record (CDR) acquisition module is used to acquire raw CDRs from the trunk node. The raw CDRs are generated based on the target session identifier, the upstream node identifier, the trunk node identifier, and the raw billing data. The target session identifier is used to identify and distinguish the raw data forwarded by the trunk node, and the upstream node is the node preceding the trunk node.

[0035] The processing and calculation module is used to calculate the target billing data for trunk nodes based on the original call detail records (CDRs).

[0036] According to another aspect of this disclosure, a call detail record (CDR) processing apparatus is provided, applied to a trunk node, the apparatus comprising:

[0037] The call detail record (CDR) generation module is used to generate original CDRs based on the target session identifier, the upstream node identifier, the trunk node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the trunk node, and the upstream node is the node preceding the trunk node.

[0038] The call detail record (CDR) sending module is used to send the original CDRs to the CDR processing node, so that the CDR processing node can calculate the target billing data of the trunk node based on the original CDRs.

[0039] According to another aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the above-described call detail record (CDR) processing method by executing the executable instructions.

[0040] According to another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described call detail record (CDR) processing method.

[0041] The call detail record (CDR) processing method provided in this disclosure obtains the original CDR from the relay node and calculates the target billing data for the relay node. The original CDR is generated based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data. The upstream node is the node preceding the relay node. In this disclosure, the target billing data for the relay node is calculated only from the relay node's CDR. Since the service of the remote terminal is provided by the relay terminal, the target billing data of the relay node can be used to bill both the relay node and the remote terminal. This completes the CDR processing without requiring the remote terminal to generate its own CDR, and provides accurate billing data for subsequent billing work.

[0042] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0044] Figure 1 This disclosure includes a schematic diagram of a multi-hop relay scenario.

[0045] Figure 2 One of the schematic flowcharts of a call detail record (CDR) processing method in this disclosure;

[0046] Figure 3 A second schematic flowchart of a call detail record (CDR) processing method in this disclosure;

[0047] Figure 4 A schematic diagram of transmission (UL) from A to D direction in this embodiment of the present disclosure;

[0048] Figure 5 A schematic diagram of transmission (DL) from D to A in this embodiment of the present disclosure;

[0049] Figure 6 This disclosure provides a third schematic diagram of a call detail record (CDR) processing method.

[0050] Figure 7 A schematic diagram of a call detail record (CDR) processing device is provided in this embodiment.

[0051] Figure 8 Another schematic diagram of a call detail record (CDR) processing device in this disclosure embodiment; and

[0052] Figure 9 A structural block diagram of a computer device according to an embodiment of this disclosure. Detailed Implementation

[0053] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0054] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0055] As can be seen from the background section, the existing call detail record (CDR) processing methods are no longer applicable in multi-hop trunk scenarios, and a new CDR processing solution is urgently needed.

[0056] Specifically, in a near-field communication system, a node with relay functionality (U2N Relay) forwards data from a remote UE, enabling the remote UE and the cellular network to maintain communication. This method enhances cellular network coverage. The remote UE can access the cellular network via single or multiple hops, passing through any number of U2U Relays and one or more U2N Relays.

[0057] In this extended coverage scenario, the near-field communication system is controlled by the cellular network, and the updating and selection of nodes can be triggered entirely by the network side. The remote UE does not necessarily need to know the information of all U2U / U2N Relay nodes that provide relay forwarding services.

[0058] In near-field communication systems controlled by cellular networks, it is necessary to bill terminals and remote terminal devices that act as relay nodes. One of the bases for billing is the statistics of data usage.

[0059] Current data usage statistics are monitored in the core network through PDU sessions. However, this method of measuring data usage cannot be directly applied to multi-hop relay scenarios that include U2U Relay and U2N Relay forwarding, and therefore cannot be used to bill relay nodes and remote UEs in these scenarios.

[0060] In order to bill local area communication systems controlled by cellular networks, a basic requirement is to collect and measure the forwarding relationships and the amount of data forwarded by the local area communication nodes involved in forwarding.

[0061] Based on this, this disclosure provides a call detail record (CDR) processing method in which the remote UE does not need to and should not participate in the collection process of forwarding relationships and forwarding data volume, which can effectively reduce the requirements for the remote UE to use forwarding services, while ensuring that the CDR generation process is controlled by the network to the greatest extent.

[0062] Figure 1 This illustration shows a multi-hop relay system scenario according to an embodiment of the present disclosure;

[0063] The call detail record (CDR) processing method disclosed herein can be applied to, for example... Figure 1 The multi-hop relay system shown includes network device 102, first terminal 104, second terminal 106 and third terminal 108.

[0064] The term "terminal" as used above may include various user units with wireless communication capabilities, cellular phones, smartphones, wireless data cards, personal digital assistant computers, tablet computers, wireless modems, handheld devices, laptop computers, machine-type communication terminals, computing devices with wireless communication capabilities or other processing devices connected to a wireless modem, vehicle-mounted devices, wearable devices, smart home devices, drone devices, terminal devices in 5G networks, terminal devices in 6G networks, or terminal devices in future evolved Public Land Mobile Networks (PLMNs), etc. This disclosure does not limit the scope of the term. For ease of description, the devices mentioned above are collectively referred to as terminals.

[0065] Network device 102 may be a base station, which may be a device deployed in an access network to provide wireless communication functions for terminals.

[0066] Base stations can include various forms of macro base stations, micro base stations, relay stations, access points, etc. The name of the equipment with base station functionality may differ in systems employing different wireless access technologies; for example, in LTE systems, it is called eNodeB or eNB; in 5G NR-U systems, it is called gNodeB or gNB.

[0067] In some scenarios, a "base station" can also be called a "cell". As communication technologies evolve, the description of "base station" may change. In this embodiment of the disclosure, the devices described above that provide wireless communication functions for terminals are collectively referred to as network devices.

[0068] In this embodiment of the disclosure, the first terminal 104 and the network device 102 communicate with each other through some air interface technology, such as the Uu interface.

[0069] In some embodiments, the first terminal 104 and the second terminal 106 communicate with each other through a certain communication technology; the second terminal 106 and the third terminal 108 communicate with each other through a certain communication technology.

[0070] Optionally, the aforementioned terminals can communicate with each other via Bluetooth or WiFi technology.

[0071] Alternatively, the aforementioned terminals support D2D communication. The first terminal 104 and the second terminal 106, or the second terminal 106 and the third terminal 108, can communicate via a sidelink through the PC-5 interface. This sidelink communication uses source and destination identifiers at the MAC layer for addressing, meaning no connection needs to be established before communication.

[0072] In non-D2D communication schemes, when there is a service transmission requirement between the first terminal 104 and the second terminal 106 in a cellular system, the service data from the first terminal 104 to the second terminal 106 is first transmitted over the air interface to the base station (or eNB, or evolved eNB) of the cell where the first terminal 104 is located. This base station then transmits the user data to the base station of the cell where the second terminal 106 is located via its core network. This base station then transmits the aforementioned service data to the second terminal 106 over the air interface. The service data transmission from the second terminal 106 to the first terminal 104 follows a similar process.

[0073] When the first terminal 104 and the second terminal 106 are located in the same cell, although the two terminals are covered by the same base station cell, a single data transmission will still consume two sets of wireless spectrum resources.

[0074] In D2D communication, service data is transmitted directly from the source user equipment to the target user equipment via the air interface without being forwarded through a base station. This is also known as Proximity Service (ProSe). This communication mode differs from that of traditional cellular systems. For users communicating in short distances, D2D not only saves radio spectrum resources but also reduces the data transmission pressure on the core network.

[0075] In multi-hop relay communication schemes, such as Figure 1 As shown, the third terminal 108 is a remote terminal, and the second terminal 106 and the first terminal 104 are both relay nodes.

[0076] The second terminal 106 and the first terminal 104 provide relay services to relay control and data between the base station and the third terminal 108.

[0077] In this configuration, the first terminal 104 communicates with the base station via the Uu interface of the LTE cellular network, essentially acting as a wireless backhaul link. The second terminal 106 and the first terminal 104 can communicate in a D2D manner on the system's uplink resources, forming a sidelink. In this case, the first terminal 104 acts as a relay terminal, and the second terminal 106 acts as a remote terminal. Furthermore, for the second terminal 106 and the third terminal 108, the second terminal 106 also becomes a relay terminal. This means that the communication of the third terminal 108 passes through two relay nodes, the second terminal 106 and the first terminal 104, constituting multi-hop relay. This effectively extends the cellular network coverage and enables communication between the network side and users outside the coverage area.

[0078] It should be noted that the technical solutions of this disclosure can be applied to various communication systems, such as: Global System for Mobile communication (GSM), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), General Packet Radio Service (GPRS), Long Term Evolution (LTE), LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), Advanced Long Term Evolution (LTE-A), New Radio (NR), evolution systems of NR, LTE based access to Unlicensed spectrum (LTE-U), NR-U, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), and Wireless Local Area Networks (WLANs). Networks (WLAN), Wireless Fidelity (WiFi), next-generation communication systems, or other communication systems.

[0079] The following detailed description of this exemplary implementation method is provided in conjunction with the accompanying drawings and embodiments.

[0080] Figure 2 This diagram illustrates a call detail record (CDR) processing method according to an embodiment of the present disclosure, such as... Figure 2 As shown, the call detail record (CDR) processing method provided in this embodiment includes the following steps:

[0081] Step S202: The relay node generates the original call detail record (CDR) based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data.

[0082] Step S202: The relay node sends the original call detail records (CDRs) to the CDR processing node.

[0083] In step S204, the call detail record (CDR) processing node calculates the target billing data for the trunk node based on the original CDR.

[0084] The above steps are explained in detail below:

[0085] Currently, there are various billing methods for call detail records (CDRs), such as billing based on data volume, billing based on duration, or a combination of both. The "billing data" in the above steps may differ depending on the billing method used.

[0086] As an example, when using a data volume-based billing scheme, the original billing data in the above steps can be the amount of data to be forwarded, that is, the amount of data transmitted (forwarded) by the previous node, which is the amount of data forwarded by the upstream node to the relay node.

[0087] As another example, when using time-based billing, the original billing data in the above steps can be the communication duration between the upstream node and the relay node.

[0088] It should be noted that when using a hybrid billing method, the "billing data" in this embodiment may also include the data in the above example.

[0089] In the above steps, the target session identifier is used to identify and distinguish the raw data forwarded by the relay node, and is used to perform billing data statistics on different raw data separately.

[0090] As an example, the target session identifier can be generated based on the service request of the remote user to which the data forwarded by the relay node belongs, and is assigned by the network function that handles the service request. For example, it can be assigned by the network function that handles relay forwarding service requests. Accordingly, at this time... Figure 1 The scenario shown may also include a "network function for processing service requests", which may be located in the core network.

[0091] It should be noted that in some documents, the name of the "Target Session Identifier" can be changed and can be other names, such as "Accounting Identifier," which is not limited here. This "identifier" is used to identify and distinguish the raw data forwarded by the relay node for subsequent billing.

[0092] Specifically, when a remote user applies for a relay forwarding service, an identifier can be assigned by the network function instance (e.g., a network element in the core network) that controls the relay forwarding service. This identifier is used to distinguish this relay forwarding service from other relay forwarding services; furthermore, it can be used to distinguish the data of this relay forwarding service from the data of other relay forwarding services and to distinguish the billing data of different relay forwarding services.

[0093] As an example, the target session identifier can be the session identifier of the original data being forwarded. For instance, the target session identifier can be the identifier of the remote UE's PDU session (including information such as the IP 5-tuple).

[0094] As another example, in the case where the session only includes one hop, the target session identifier can be the Layer-2 ID of the Remote UE and the Layer-2 ID of the gNB.

[0095] The target session identifier can be generated as a temporary identifier of the remote user to which the data forwarded by the relay node belongs.

[0096] The temporary identifier of the remote user to which the data forwarded by the relay node belongs is assigned by the base station providing services to that remote user.

[0097] For simplicity, Layer-2 ID will be referred to as L2 ID in the following text.

[0098] Different target session identifier values ​​represent distinguishable and independent communication or session processes that require usage statistics. Based on the specific communication and session establishment mechanisms, different target session identifier values ​​may represent communication / session processes between the UE and a specific DN, a specific APP, or other UEs.

[0099] The identifier of the upstream node can be the identifier of the previous node of the current node (e.g., L2ID / IP address and port number).

[0100] The identifier of a relay node can be the identifier of the current (the node that generated the call detail record) node (e.g., L2 ID / IP address / port number).

[0101] In one example, the original call detail record (CDR) in the above embodiment can be ("A-to-D", A, B, 10), where the target session identifier is "A-to-D", the identifier of the upstream node is A, the identifier of the relay node is B, and the original billing data is 10.

[0102] Each relay node providing forwarding functionality generates a raw call detail record (CDR) containing the target session identifier, the upstream node identifier, the relay node identifier, and the raw billing data, based on the received forwarding request and by monitoring the data forwarding process, according to preset rules (such as a specific time granularity).

[0103] The call detail record (CDR) processing node can obtain raw CDRs through the application layer or through signaling. This disclosure does not limit how CDRs are collected.

[0104] Here, the call detail record (CDR) processing node can be a functional module within the billing server. The billing server can include functions such as CDR preprocessing, CDR analysis, billing approval, and billing management, while the CDR processing node can specifically be used for CDR preprocessing and CDR analysis.

[0105] Here, the billing server can be an application server or a web server. In specific deployments, this server can be a standalone server or a cluster server.

[0106] In some embodiments, calculating the target billing data for a trunk node based on the original call detail records may include:

[0107] A directed graph is constructed based on the target session identifier, upstream node identifier, relay node identifier, and original billing data in each original call detail record (CDR).

[0108] Based on the directed graph, the target billing data for each relay node is calculated.

[0109] The following details the process of constructing the directed graph and calculating the target billing data for each relay node based on the directed graph.

[0110] First, the N original call detail records (CDRs) to be processed are aggregated to obtain M target CDRs.

[0111] As an example, the original call detail record (CDR) could include ("A-to-D", E, C, 2) and ("A-to-D", E, C, 2).

[0112] When aggregating the two original call detail records (CDRs) mentioned above, it can be determined whether the target session identifier, the upstream node identifier, and the trunk node identifier are the same. The original billing data of the original CDRs with the same target session identifier, the same upstream node identifier, and the same trunk node identifier are added together to obtain the original billing data of the aggregated target CDR.

[0113] Therefore, in this example, "2" and "1" can be added together to get "3", which means that after aggregating the original call detail records, the target call detail record ("A-to-D", E, C, 3) can be obtained.

[0114] Then, based on the target session identifier, the M target call detail records (CDRs) are clustered to obtain P CDR groups. Target CDRs belonging to the same CDR group have the same target session identifier.

[0115] After aggregation, clustering is performed on the call detail records (CDRs), grouping CDRs with the same target session identifier into the same CDR group. This CDR group can be labeled as a BillSet. IE1＝p Mark the target session identifier in the i-th call detail record (CDR) group as IE1.Bill_i The upstream node is identified by IE2. Bill_i The relay node is identified by IE3. Bill_i The original billing data is marked as IE4. Bill_i .

[0116] Finally, a directed graph is constructed for each call detail record (CDR) group.

[0117] For BillSet IE1＝p If the IE2 of the i-th call detail record (CDR) bill is IE2... Bill_i Satisfies: For any call detail record (CDR) Bill_j, j = 1…N, j ≠ i, IE3 Bill_j None of them are equivalent to IE2 Bill_i Then IE2 Bill_i It is the starting point of a directed graph, and is added to a node set NodeSet. IE1＝p .

[0118] It should be noted that more than one call detail record (CDR) can be found here containing the starting point of the directed graph, but the IE2 values ​​of these CDRs are all the same, for example, they are all A.

[0119] Traversing the NodeSet IE1＝p For each node k in the set of nodes that have been processed, if it is not in the CompleteNodeSet, then... IE1＝p In the context of ), further traverse the call detail record (CDR) set NodeSet. IE1＝p Each call detail record (CDR) in the list is iterated over until the entire list is completed. During the iteration, if a CDR Bill_x satisfies IE2... Bill_i =k, then:

[0120] IE3 Bill_x =l is connected to the current node k by a directed edge, with the direction from k to l, and the edge value is IE4. Bill_x ;

[0121] IE3 Bill_x =l Add to NodeSet IE1＝p ;

[0122] Continue iterating through the call detail record (CDR) set.

[0123] After traversing the call detail records (CDRs), add node k to the CompleteNodeSet of processed nodes. IE1＝p ).

[0124] If CompleteNodeSet IE1＝p with NodeSet IE1＝pIf the number of elements is different, return to the above steps, continue traversing the node set, and start processing the next node.

[0125] If CompleteNodeSet IE1＝p with NodeSet IE1＝p If the number of internal elements is the same, the following steps can be continued.

[0126] From CompleteNodeSet IE1＝p with NodeSet IE1＝p In the middle, remove the starting node of the directed graph. At this point, CompleteNodeSet... IE1＝p All nodes in the network are relay nodes.

[0127] BillSet IE1＝p Iterate through CompleteNodeSet IE1＝p The nodes in the dataset. For node k, the amount of data forwarded by node k is calculated based on each edge pointing to node k and the edge value: the amount of data forwarded (DV, Data Volume) is calculated based on a weighted value for node k.

[0128]

[0129] Where M is BillSet IE1＝p Among all N records (Bill_i, i = 1…N), the condition IE3 is satisfied. Bill_i =k is the set of indices of call records.

[0130] BillSet IE1＝p Specifically, for the starting point *s* of a directed graph, the data volume (DV) that node *s* needs to forward can be calculated based on all edges emanating from *s* and their values: This is calculated using a weighted value for node *s*.

[0131]

[0132] Where Q is BillSet IE1＝p Among all N records (Bill_i, i = 1…N), the condition IE2 is satisfied. Bill_i =s is the set of indices of call detail records.

[0133] like Figure 4 The image shows an example of transmission (UL) from direction A to direction D.

[0134] UL direction trunk node call detail record information:

[0135]

[0136]

[0137] Usage information for UL direction:

[0138]

[0139] like Figure 5 The image shows an example of transmission (DL) from D to A. DL direction relay node call detail record (CDR) information:

[0140]

[0141]

[0142] DL direction usage information:

[0143]

[0144] Based on the same inventive concept, this disclosure also provides a call detail record (CDR) processing method, applied to a CDR processing node, such as... Figure 3 As shown, the call detail record (CDR) processing method includes:

[0145] Step S302: Obtain the original call detail records (CDRs) from the relay node. The original CDRs are generated based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the relay node. The upstream node is the node preceding the relay node.

[0146] Step S304: Calculate the target billing data for the trunk node based on the original call detail records.

[0147] The above steps are explained in detail below:

[0148] In some embodiments, the original billing data is at least one of the following:

[0149] The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

[0150] In some embodiments, the target billing data for the trunk node is calculated based on the original call detail records (CDRs), including:

[0151] A directed graph is constructed based on the target session identifier, upstream node identifier, relay node identifier, and original billing data in each original call detail record (CDR).

[0152] Based on the directed graph, the target billing data for each relay node is calculated.

[0153] In some embodiments, a directed graph is constructed based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data in each original call detail record (CDR), including:

[0154] The N original call detail records (CDRs) to be processed are aggregated to obtain M target CDRs.

[0155] Based on the target session identifier, the M target call detail records (CDRs) are clustered to obtain P CDR groups; target CDRs belonging to the same CDR group have the same target session identifier.

[0156] Construct a directed graph for each call detail record (CDR) group;

[0157] The aggregation process includes the following steps:

[0158] Determine whether the target session identifier, the upstream node identifier, and the trunk node identifier are the same for different original call detail records;

[0159] The original billing data of the original call detail records (CDRs) with the same target session identifier, the same upstream node identifier, and the same trunk node identifier are added together to obtain the aggregated original billing data of the target CDR.

[0160] In some embodiments, the target session identifier may be generated based on the service request of the remote user to which the data forwarded by the relay node belongs, and may be assigned by the network function that processes the service request.

[0161] In some embodiments, the target session identifier is the identifier of the relay node's PDU session.

[0162] In some embodiments, the target session identifier is generated based on the temporary identifier of the remote user to which the data forwarded by the relay node belongs; the temporary identifier of the remote user to which the data forwarded by the relay node belongs is assigned by the base station providing services to the remote user.

[0163] In some embodiments, obtaining the original call detail records (CDRs) from the relay node includes:

[0164] Based on a preset period, the original call detail records (CDRs) are obtained from the relay nodes.

[0165] The call detail record (CDR) processing method provided in this embodiment obtains the original CDR from the relay node and calculates the target billing data for the relay node. The original CDR is generated based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data. The target session identifier is the session identifier of the original data forwarded by the relay node, and the upstream node is the node preceding the relay node. In this embodiment, only the relay node's CDR needs to be obtained to calculate the target billing data for the relay node. Since the service of the remote terminal is provided by the relay terminal, the target billing data of the relay node can be used to bill not only the relay node but also the remote terminal. This completes the CDR processing without requiring the remote terminal to generate its own CDR, and provides accurate billing data for subsequent billing work.

[0166] Based on the same inventive concept, this disclosure also provides a call detail record (CDR) processing method, applied to a trunk node, such as... Figure 6 As shown, the call detail record (CDR) processing method includes:

[0167] Step S602: Generate the original call detail record (CDR) based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the relay node. The upstream node is the node preceding the relay node.

[0168] Step S604: Send the original call detail records (CDRs) to the CDR processing node so that the CDR processing node can calculate the target billing data of the trunk node based on the original CDRs.

[0169] In some embodiments, the original billing data is at least one of the following:

[0170] The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

[0171] Based on the same inventive concept, this disclosure also provides a call detail record (CDR) processing device, as described in the following embodiments. Since the principle by which this device solves the problem is similar to that of the method embodiments described above, the implementation of this device embodiment can refer to the implementation of the method embodiments described above, and repeated details will not be repeated.

[0172] Figure 7 This disclosure illustrates a call detail record (CDR) processing apparatus, which is applied to a CDR processing node, such as... Figure 7 As shown, the call detail record (CDR) processing device 700 includes:

[0173] The call detail record (CDR) acquisition module 702 is used to acquire raw CDRs from the trunk node. The raw CDRs are generated based on the target session identifier, the upstream node identifier, the trunk node identifier, and the raw billing data. The target session identifier is used to identify and distinguish the raw data forwarded by the trunk node, and the upstream node is the node preceding the trunk node.

[0174] The processing and calculation module 704 is used to calculate the target billing data of the trunk node based on the original call detail records.

[0175] In some embodiments, the original billing data is at least one of the following:

[0176] The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

[0177] In some embodiments, the target billing data for the trunk node is calculated based on the original call detail records (CDRs), including:

[0178] A directed graph is constructed based on the target session identifier, upstream node identifier, relay node identifier, and original billing data in each original call detail record (CDR).

[0179] Based on the directed graph, the target billing data for each relay node is calculated.

[0180] In some embodiments, a directed graph is constructed based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data in each original call detail record (CDR), including:

[0181] The N original call detail records (CDRs) to be processed are aggregated to obtain M target CDRs.

[0182] Based on the target session identifier, the M target call detail records (CDRs) are clustered to obtain P CDR groups; target CDRs belonging to the same CDR group have the same target session identifier.

[0183] Construct a directed graph for each call detail record (CDR) group;

[0184] The aggregation process includes the following steps:

[0185] Determine whether the target session identifier, the upstream node identifier, and the trunk node identifier are the same for different original call detail records;

[0186] The original billing data of the original call detail records (CDRs) with the same target session identifier, the same upstream node identifier, and the same trunk node identifier are added together to obtain the aggregated original billing data of the target CDR.

[0187] In some embodiments, the target session identifier may be generated based on the service request of the remote user to which the data forwarded by the relay node belongs, and may be assigned by the network function that controls the relay forwarding service.

[0188] In some embodiments, the target session identifier is the identifier of the relay node's PDU session.

[0189] In some embodiments, the target session identifier is generated based on the temporary identifier of the remote user to which the data forwarded by the relay node belongs; the temporary identifier of the remote user to which the data forwarded by the relay node belongs is assigned by the base station providing services to the remote user.

[0190] In some embodiments, obtaining the original call detail records (CDRs) from the relay node includes:

[0191] Based on a preset period, the original call detail records (CDRs) are obtained from the relay nodes.

[0192] The call detail record (CDR) processing device provided in this application embodiment can be used to execute the CDR processing methods provided in the above-described method embodiments. Its implementation principle and technical effect are similar, and for the sake of brevity, it will not be described in detail here.

[0193] Based on the same inventive concept, this disclosure also provides a call detail record (CDR) processing device, applied to a trunk node, such as... Figure 8 As shown, the call detail record (CDR) processing device 800 includes:

[0194] The call detail record (CDR) generation module 802 is used to generate original CDRs based on the target session identifier, the upstream node identifier, the trunk node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the trunk node, and the upstream node is the node preceding the trunk node.

[0195] The call detail record (CDR) sending module 804 is used to send the original CDR to the CDR processing node so that the CDR processing node can calculate the target billing data of the trunk node based on the original CDR.

[0196] In some embodiments, the original billing data is at least one of the following:

[0197] The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

[0198] In some embodiments, the target billing data for the trunk node is calculated based on the original call detail records (CDRs), including:

[0199] A directed graph is constructed based on the target session identifier, upstream node identifier, relay node identifier, and original billing data in each original call detail record (CDR).

[0200] Based on the directed graph, the target billing data for each relay node is calculated.

[0201] In some embodiments, a directed graph is constructed based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data in each original call detail record (CDR), including:

[0202] The N original call detail records (CDRs) to be processed are aggregated to obtain M target CDRs.

[0203] Based on the target session identifier, the M target call detail records (CDRs) are clustered to obtain P CDR groups; target CDRs belonging to the same CDR group have the same target session identifier.

[0204] Construct a directed graph for each call detail record (CDR) group;

[0205] The aggregation process includes the following steps:

[0206] Determine whether the target session identifier, the upstream node identifier, and the trunk node identifier are the same for different original call detail records;

[0207] The original billing data of the original call detail records (CDRs) with the same target session identifier, the same upstream node identifier, and the same trunk node identifier are added together to obtain the aggregated original billing data of the target CDR.

[0208] In some embodiments, the target session identifier is the identifier of the relay node's PDU session, or the identifier of the relay node and the identifier of the base station corresponding to the relay node.

[0209] In some embodiments, obtaining the original call detail records (CDRs) from the relay node includes:

[0210] Based on a preset period, the original call detail records (CDRs) are obtained from the relay nodes.

[0211] The call detail record (CDR) processing device provided in this application embodiment can be used to execute the CDR processing methods provided in the above-described method embodiments. Its implementation principle and technical effect are similar, and for the sake of brevity, it will not be described in detail here.

[0212] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0213] The following reference Figure 9 To describe an electronic device 900 according to such an embodiment of the present disclosure. Figure 9 The electronic device 900 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0214] like Figure 9As shown, the electronic device 900 is manifested in the form of a general-purpose computing device. The components of the electronic device 900 may include, but are not limited to: at least one processing unit 910, at least one storage unit 920, and a bus 930 connecting different system components (including the storage unit 920 and the processing unit 910).

[0215] The storage unit stores program code that can be executed by the processing unit 910, causing the processing unit 910 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 910 can perform the steps of the above-described method embodiments.

[0216] Storage unit 920 may include readable media in the form of volatile storage units, such as random access memory (RAM) 9201 and / or cache memory 9202, and may further include read-only memory (ROM) 9203.

[0217] Storage unit 920 may also include a program / utility 9204 having a set (at least one) program module 9205, such program module 9205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0218] Bus 930 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0219] Electronic device 900 can also communicate with one or more external devices 940 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 900, and / or with any device that enables electronic device 900 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 950. Furthermore, electronic device 900 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 960. As shown, network adapter 960 communicates with other modules of electronic device 900 via bus 930. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0220] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0221] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, which may be a readable signal medium or a readable storage medium. A program product capable of implementing the methods described above is stored thereon. In some possible implementations, various aspects of this disclosure may also be implemented as a program product including program code, which, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0222] More specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0223] In this disclosure, a computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device.

[0224] Optionally, the program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0225] In practical implementation, program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0226] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0227] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0228] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0229] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A call detail record (CDR) processing method, characterized in that, Applied to a near-field communication system, in which a remote terminal accesses a cellular network via one or more relay nodes, wherein the relay node is a user terminal, the method is executed by a call detail record (CDR) processing node, and the method includes: The original call detail records (CDRs) are obtained from the relay node. The original CDRs are generated based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the relay node. The upstream node is the node preceding the relay node. Based on the original call detail records (CDRs), the target billing data for the trunk node is calculated, including: The N original call detail records (CDRs) to be processed are aggregated to obtain M target CDRs. Based on the target session identifier, the M target call detail records are clustered to obtain P call detail record groups; wherein, the target session identifiers of target call detail records belonging to the same call detail record group are the same. For each of the call detail records (CDRs), a directed graph representing the data forwarding path is constructed based on the mapping relationship between the identifiers of upstream nodes and the identifiers of relay nodes in the CDRs within the group. The nodes of the directed graph represent communication nodes, and the weights of the directed edges between adjacent nodes are determined based on the corresponding original billing data. The remaining nodes in the directed graph, excluding the starting node, are identified as relay nodes to be billed. The starting node is a node that appears only in the identifier of the upstream node and does not appear in the identifier of any relay node in the same group of target call detail records. The target billing data for the relay node is calculated based on the sum of the weights of the directed edges pointing to the relay node.

2. The method according to claim 1, characterized in that, The original billing data is at least one of the following: The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

3. The method according to claim 1 or 2, characterized in that, The target session identifier is generated based on the service request of the remote user to which the data forwarded by the relay node belongs, and is allocated by the network function that processes the service request.

4. The method according to claim 1 or 2, characterized in that, The target session identifier is the identifier of the PDU session to which the data forwarded by the relay node belongs.

5. The method according to claim 1 or 2, characterized in that, The target session identifier is generated based on the temporary identifier of the remote user to which the data forwarded by the relay node belongs; the temporary identifier of the remote user to which the data forwarded by the relay node belongs is assigned by the base station providing services to the remote user.

6. The method according to claim 1 or 2, characterized in that, The step of obtaining the original call detail records from the relay node includes: Based on a preset period, the original call detail records (CDRs) are obtained from the relay nodes.

7. A call detail record (CDR) processing method, characterized in that, Applied to a near-field communication system, in which a remote terminal accesses a cellular network via one or more relay nodes, wherein the relay node is a user terminal, the method is executed by the relay node, and the method includes: Based on the target session identifier, the upstream node identifier, the relay node identifier, and the original billing data, an original call detail record (CDR) is generated. The target session identifier is used to identify and distinguish the original data forwarded by the relay node, and the upstream node is the node preceding the relay node. The original call detail records (CDRs) are sent to the CDR processing node, so that the CDR processing node can calculate the target billing data of the trunk node based on the original CDRs. Based on the original call detail records (CDRs), the target billing data for the relay nodes is calculated, including: aggregating the N original CDRs to be processed to obtain M target CDRs; clustering the M target CDRs based on the target session identifier to obtain P CDR groups; wherein the target session identifiers of target CDRs belonging to the same CDR group are the same; for each CDR group, constructing a directed graph representing the data forwarding path based on the mapping relationship between the identifiers of upstream nodes and the identifiers of relay nodes in the CDRs within the group, wherein the nodes of the directed graph represent communication nodes, and the weights of the directed edges between adjacent nodes are determined based on the corresponding original billing data; determining the remaining nodes in the directed graph except for the starting node as relay nodes to be billed, wherein the starting node is a node that only appears in the identifier of the upstream node and does not appear in the identifier of any relay node in the same target CDR group; and calculating the target billing data for the relay nodes based on the cumulative weights of the directed edges pointing to the relay nodes.

8. The method according to claim 7, characterized in that, The original billing data is at least one of the following: The amount of data forwarded from the upstream node to the relay node, and the communication duration between the upstream node and the relay node.

9. A call detail record (CDR) processing device, characterized in that, Applied to a near-field communication system, in which a remote terminal accesses a cellular network via one or more relay nodes, wherein the relay node is a user terminal, and the device is located at a call detail record (CDR) processing node, the device comprising: The call detail record (CDR) acquisition module is used to acquire raw CDRs from the trunk node. The raw CDRs are generated based on the target session identifier, the upstream node identifier, the trunk node identifier, and the raw billing data. The target session identifier is used to identify and distinguish the raw data forwarded by the trunk node. The upstream node is the node preceding the trunk node. The processing and calculation module is used to calculate the target billing data of the relay nodes based on the original call detail records (CDRs), including: aggregating the N original CDRs to be processed to obtain M target CDRs; clustering the M target CDRs based on the target session identifier to obtain P CDR groups; wherein the target session identifiers of target CDRs belonging to the same CDR group are the same; for each CDR group, constructing a directed graph representing the data forwarding path according to the mapping relationship between the identifiers of upstream nodes and the identifiers of relay nodes in the CDRs within the group, wherein the nodes of the directed graph represent communication nodes, and the weights of the directed edges between adjacent nodes are determined based on the corresponding original billing data; determining the remaining nodes in the directed graph except for the starting node as relay nodes to be billed, wherein the starting node is a node that only appears in the identifier of the upstream node and does not appear in the identifier of any relay node in the same target CDR group; and calculating the target billing data of the relay node according to the cumulative weight of each directed edge pointing to the relay node.

10. A call detail record (CDR) processing device, characterized in that, An application is made in a near-field communication system, wherein a remote terminal in the near-field communication system accesses a cellular network via one or more relay nodes, wherein the relay node is a user terminal, and the device is disposed at the relay node, the device comprising: The call detail record (CDR) generation module is used to generate original CDRs based on the target session identifier, the upstream node identifier, the trunk node identifier, and the original billing data. The target session identifier is used to identify and distinguish the original data forwarded by the trunk node, and the upstream node is the node preceding the trunk node. The call detail record (CDR) sending module is used to send the original CDR to the CDR processing node, so that the CDR processing node can calculate the target billing data of the trunk node based on the original CDR; Based on the original call detail records (CDRs), the target billing data for the relay nodes is calculated, including: aggregating the N original CDRs to be processed to obtain M target CDRs; clustering the M target CDRs based on the target session identifier to obtain P CDR groups; wherein the target session identifiers of target CDRs belonging to the same CDR group are the same; for each CDR group, constructing a directed graph representing the data forwarding path based on the mapping relationship between the identifiers of upstream nodes and the identifiers of relay nodes in the CDRs within the group, wherein the nodes of the directed graph represent communication nodes, and the weights of the directed edges between adjacent nodes are determined based on the corresponding original billing data; determining the remaining nodes in the directed graph except for the starting node as relay nodes to be billed, wherein the starting node is a node that only appears in the identifier of the upstream node and does not appear in the identifier of any relay node in the same target CDR group; and calculating the target billing data for the relay nodes based on the cumulative weights of the directed edges pointing to the relay nodes.

11. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the call detail record (CDR) processing method of any one of claims 1-8 by executing the executable instructions.

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

Images