Service XDR acquisition method, device, and storage medium

Abstract

This application discloses a method, device and storage medium for acquiring a service XDR. The method for acquiring a service XDR, which is applied to a first device, includes the steps of: receiving a service XDR sent by a second device and generated based on service data collected from a user plane (401); searching for a target signaling XDR among signaling XDRs sent by the third device and generated based on information about a service in the signaling collected from a control plane based on the service XDR and a preset association between the service and the signaling (402); and updating the service XDR according to the target signaling XDR. This allows a complete and accurate service XDR (403) to be acquired even when the control plane and the user plane are separated.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority from a Chinese patent application filed on March 22, 2022, bearing application number 202210287606.2, the entire contents of which are incorporated herein by reference.

[0002] TECHNICAL FIELD The embodiments of the present application relate to the field of communication technology, and in particular to a method, apparatus and storage medium for obtaining a service XDR. [Background technology]

[0003] To better monitor and manage network elements in a network, a method of generating X (Application) Detail Records (XDRs) based on data from network elements is usually adopted. XDRs can be further classified into two types: signaling XDRs, which are used to record the signaling transmission process and signaling content between network elements, and service XDRs, which are used to record information about users. Taking a Session Border Controller (SBC) as an example, Session Initiation Protocol (SIP) signaling on the control plane and Real-Time Transport Protocol (RTP) Real-Time Transport Control Protocol (RTCP) data packets on the media plane are simultaneously collected and distributed to the same collection and analysis device. The collection and analysis device then extracts and fills in relevant fields from the SIP signaling and RTP / RTCP data packets to generate signaling XDRs and service XDRs.

[0004] However, the above process is only valid when the signaling and service data are processed by the same collection and analysis device, in the absence of control and user plane separation. For network elements where the concept of control and user plane separation is applied, the signaling and service data are no longer processed by the same collection and analysis device, and therefore the fields in the service XDR that can only be filled in depending on the control plane information are missing, making it impossible to obtain a complete and valid service XDR. Summary of the Invention [Problem to be solved by the invention]

[0005] The main purpose of the embodiments of the present application is to propose a method, device, and storage medium for acquiring a service XDR so that a complete and accurate service XDR can be acquired even when the control plane and the user plane are separated. [Means for solving the problem]

[0006] To achieve the above object, an embodiment of the present application provides a service XDR acquisition method applied to a first device, the method including: receiving a service XDR sent by a second device, the service XDR being generated based on service data collected from a user plane; searching for a target signaling XDR from signaling XDRs sent by the third device, the signaling XDR being generated based on information about the service in the signaling collected from the control plane, based on the service XDR and a preset association between the service and the signaling; and updating the service XDR according to the target signaling XDR.

[0007] To achieve the above object, an embodiment of the present application further provides a service XDR acquisition method applied to a second device, the method including: collecting service data from a user plane; filling in non-control-related fields based on the service data to generate a service XDR; and sending the service XDR to a first device.

[0008] To achieve the above object, an embodiment of the present application further provides a service XDR acquisition method applied to a third device, the method including: collecting signaling from a control plane; generating a signaling XDR based on information about the service in the signaling; and sending the signaling XDR to a first device.

[0009] To achieve the above object, an embodiment of the present application further proposes an apparatus, which includes: a receiving module used to receive a service XDR sent by a second apparatus, the service XDR being generated based on service data collected from a user plane; a search module used to search for a target signaling XDR from among signaling XDRs sent by the third apparatus, the signaling XDR being generated based on information about the service in the signaling collected from the control plane, based on the service XDR and a preset association between the service and the signaling; and an update module used to update the service XDR according to the target signaling XDR.

[0010] To achieve the above object, an embodiment of the present application further proposes an apparatus, which includes: a first collection module used to collect service data from a user plane; a first generation module used to fill in non-control-related fields based on the service data to generate a service XDR; and a first sending module used to send the service XDR to a first device.

[0011] To achieve the above object, an embodiment of the present application further proposes an apparatus, which comprises: a second collection module used to collect signaling from a control plane; a second generation module used to generate a signaling XDR based on information about a service in the signaling; and a second transmission module used to transmit the signaling XDR to a first device.

[0012] In order to achieve the above object, an embodiment of the present application further proposes an electronic device, the electronic device including at least one processor and a memory communicatively connected to the at least one processor, the memory storing instructions executable by the at least one processor, and the instructions being executed by the at least one processor, enabling the at least one processor to perform the method for obtaining a service XDR described in any one of the above claims.

[0013] To achieve the above object, an embodiment of the present application further proposes a computer-readable storage medium, which stores a computer program that, when executed by a processor, realizes the method for obtaining a service XDR described in any one of the above claims.

[0014] (beneficial effects) The method for obtaining a service XDR proposed in this application not only generates a signaling XDR that completely records the process of signaling interaction based on the conventional signaling, but also adds another type of signaling XDR that is generated based on information about services in the signaling collected from the control plane. This type of signaling XDR is generated based on information about services in the signaling collected from the control plane, so it records information about services in the signaling. In this way, after receiving the service XDR sent by the second device and the signaling XDR sent by the third device, the first device can search for the target signaling XDR from the signaling XDR sent by the third device based on the service XDR and the pre-configured association between the service and the signaling, and then update the service XDR according to the target signaling XDR, so that fields in the service XDR that can only be filled in depending on the control plane information can be filled in according to the target signaling XDR, thereby obtaining a complete service XDR even when the control plane and the user plane are separated.

[0015] One or more embodiments are illustrated by way of example in the accompanying drawings, corresponding images of which are not intended to constitute limitations on the embodiments. [Brief explanation of the drawings]

[0016] [Figure 1] 1 is a schematic diagram of an SBC network architecture in the related art of the present application when the control plane and the user plane are not separated. [Figure 2] 1 is a schematic diagram of the generation of service XDRs and signaling XDRs when the control plane and user plane are not separated in the related art of the present application. [Figure 3] FIG. 1 is a schematic diagram of an SBC network architecture when the control plane and the user plane are separated in the related art of the present application. [Figure 4] 1 is a flowchart of a method for obtaining a service XDR applied to a first device provided in an embodiment of the present application; [Figure 5] FIG. 2 is a schematic diagram of data collection when the control plane and the user plane are not separated, provided in one embodiment of the present application; [Figure 6] 10 is a flowchart of a method for obtaining a service XDR applied to a second device provided in another embodiment of the present application; [Figure 7] 10 is a flowchart of a method for obtaining a service XDR applied to a third device provided in another embodiment of the present application; [Figure 8] FIG. 10 is a schematic diagram of signaling interactions during a session provided in another embodiment of the present application; [Figure 9] FIG. 1 is a schematic diagram of a device provided in another embodiment of the present application. [Figure 10] FIG. 1 is a schematic diagram of a device provided in another embodiment of the present application. [Figure 11] FIG. 1 is a schematic diagram of a device provided in another embodiment of the present application. [Figure 12] FIG. 1 is a schematic diagram of an electronic device provided in another embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0017] As can be seen from the background art, the conventional method of generating service XDRs and signaling XDRs is only effective when the control plane and user plane of a network element are not separated, and there is a need for a method that can still obtain a complete service XDR even when the control plane and user plane of a network are separated.

[0018] Analysis revealed that the main cause of the above problem is when a Voice over Long-Term Evolution (VoLTE) / VoNR (VoNR) user accesses an SBC network element in an IP Multimedia Subsystem (IMS) network, which has the functionality to process SIP signaling flows on the control plane and RTP / RTCP data flows on the media plane. Without separation of the control plane and user plane, as shown in Figure 1, both SIP signaling on the control plane and RTP / RTCP data packets on the media plane enter the SBC from the User Plane Function (UPF) via the Gm interface for communication between the UPF and the SBC. In this case, the SIP signaling on the control plane and the RTP / RTCP data packets on the media plane are collected on the same fiber, and for the same call, the user equipment (UE) side IP address and the SBC side IP address are also the same for the two types of data. Therefore, in a scenario where a service XDR and a signaling XDR are generated, as shown in Figure 2, the SBC side simultaneously collects the SIP signaling on the control plane and the RTP / RTCP data packets on the media plane and distributes them to the same collection and analysis device. As a result, when processing the service XDR, the collection and analysis device can directly extract information from the SIP signaling on the control plane and fill in the fields in the service XDR that can only be filled in depending on the control plane information.On the other hand, when the control plane and user plane are separated, the original SBC network element is divided into two physical entities: a Session Border Controller-Control (SBC-C) that processes SIP signaling on the control plane and a Session Border Controller-User (SBC-U) that processes RTP / RTCP data on the media plane, as shown in Figure 3. Thus, the SIP signaling flow on the control plane is routed from the UPF based on the Gm interface to the SBC-C, which is a virtual network element deployed in a network functions virtualization (NFV) resource pool of a district (such as an administrative region in North China or East China, etc.), while the media plane RTP / RTCP data is routed from the UPF to the SBC-U, which is deployed in a province (such as an administrative region in Anhui or Hebei, etc., in China). In this case, control plane data and media plane data are collected within the region and province, respectively. For the same call, the UE side IP address for the two types of data is the same, but the SBC-C / SBC-U side IP addresses are different. Furthermore, the RTP / RTCP data corresponding to SIP signaling within one SBC-C may be distributed across multiple SBC-Us, and the SIP signaling corresponding to RTP / RTCP data within one SBC-U may also be distributed across multiple SBC-Cs. In other words, the SBC-C and SBC-U form a single mesh network, and it is not possible to guarantee that the two types of data for the same call will be distributed to the same collection and analysis device simply based on the IP address relationship between the SBC-C and SBC-U.Therefore, if a VoLTE / VoNR service needs to output an RTP / RTCP slice XDR on the media plane, i.e., a Service XDR, to evaluate voice quality in addition to outputting a SIP XDR for SIP signaling, some fields in the Service XDR will be missing or not completely accurate because the generation of some fields in the Service XDR depends on information extracted from the control plane or parameter calculations on the control plane. Here, the fields in the RTP / RTCP slice XDR that can only be filled in depending on information from the control plane are shown in Table 1. [Table 1]

[0019] In order to solve the above-mentioned problems, an embodiment of the present application provides a service XDR acquisition method applied to a first device, the method including: receiving a service XDR sent by a second device, the service XDR being generated based on service data collected from a user plane; searching for a target signaling XDR from signaling XDRs sent by the third device, the signaling XDR being generated based on information about the service in the signaling collected from the control plane, based on the service XDR and a preset association between the service and the signaling; and updating the service XDR according to the target signaling XDR.

[0020] The method for obtaining a service XDR proposed in this application not only generates a signaling XDR that completely records the process of signaling interaction based on the conventional signaling, but also adds another type of signaling XDR that is generated based on information about services in the signaling collected from the control plane. This type of signaling XDR is generated based on information about services in the signaling collected from the control plane, so it records information about services in the signaling. In this way, after receiving the service XDR sent by the second device and the signaling XDR sent by the third device, the first device can search for the target signaling XDR from the signaling XDR sent by the third device based on the service XDR and the pre-configured association between the service and the signaling, and then update the service XDR according to the target signaling XDR, so that fields in the service XDR that can only be filled in depending on the control plane information can be filled in according to the target signaling XDR, thereby obtaining a complete service XDR even when the control plane and the user plane are separated.

[0021] In order to clarify the objectives, technical solutions, and advantages of the embodiments of the present application, the following detailed description of each embodiment will be provided in conjunction with the accompanying drawings. However, those skilled in the art will understand that many technical details are provided in each embodiment of the present application to help readers better understand the present application. However, the technical solutions claimed for protection of the present application can be realized without these technical details and various changes and modifications based on the following embodiments. The division of the following embodiments is made for the convenience of explanation and should not be construed as imposing any limitations on the specific embodiments of the present application. The embodiments may be combined or referenced with each other as long as they are not inconsistent.

[0022] An aspect of the embodiment of the present application provides a method for obtaining a service XDR applied to a first device, the flow of which is shown in FIG. 4, and may include at least the following steps:

[0023] In step 401, a service XDR sent by a second device is received, the service XDR being generated based on service data collected from the user plane.

[0024] When the user plane and control plane of a network element are separated, the user plane data and the control plane data can no longer be collected by the same device, so the service data on the user plane and the signaling on the control plane need to be collected by two devices respectively, as shown in Figure 5.

[0025] In this embodiment, the second device is used to collect service data from the user plane after separation of the network element, and generate a service XDR based on the collected service data, where the network element may be any network element whose user plane and control plane are separated, such as a UPF, an SBC, etc.

[0026] In step 402, based on the service XDR and the pre-configured association between the service and the signaling, the target signaling XDR is searched for among the signaling XDRs sent by the third device, which are generated based on information about the service in the signaling collected from the control plane.

[0027] In this embodiment, the pre-configured association between a service and signaling is related to the type of service and the type of signaling. Taking VoLTE service as an example, the signaling transmitted on the control plane is SIP signaling, and the service data transmitted on the user plane is mainly RTP / RTCP data packets, so the pre-configured association between a service and signaling may be that the service and signaling are from the same session, etc.

[0028] It should be emphasized that the signaling XDR in this embodiment is not generated based on the signaling itself, but rather on a portion of the signaling, i.e., service-related information. This is because signaling includes various information, such as the signaling transmission and reception time, but not all of the information needs to be included in the signaling XDR. Since interest is focused on information that is useful for obtaining a service XDR, i.e., service-related information, a new signaling XDR can be added under the existing signaling XDR generation mode. This reduces the amount of data, eases implementation difficulty, and facilitates transmission. Because XDRs are typically implemented based on defined interfaces, adding a new signaling XDR is equivalent to adding an extra interface. However, because the size and number of SDP XDRs are extremely small, adding this interface has little impact on the performance of existing devices, and the receiver of the service XDR does not notice any changes due to the addition of the interface.

[0029] It should be understood that for some signaling, multiple signaling XDRs may be generated during the provision of one service. For example, during VoLTE service implementation, a signaling XDR may be defined as an SDP XDR that is acquired in addition to the existing SIP XDR, so that multiple SDP XDRs may be generated for one session due to multiple media negotiations. Furthermore, one service XDR may correspond to more than one SDP XDR. In this case, it is necessary to consider maintaining the signaling XDRs so that the first device can obtain accurate and sufficient signaling XDRs to update the service XDR when it receives it. Furthermore, because the service XDR and the signaling XDR are not necessarily generated or transmitted to the first device at the same time, it is also necessary to consider maintaining the signaling XDRs so that the first device can obtain accurate and sufficient signaling XDRs to update the service XDR when it receives it.

[0030] Based on this, in some examples, before the step of searching for the target signaling XDR from among the signaling XDRs sent by the third device based on the service XDR and the preset association between the service and the signaling, the method for obtaining the service XDR further includes the steps of receiving the signaling XDR sent by the third device and caching the received signaling XDR in a local cache. Therefore, searching for the target signaling XDR from among the signaling XDRs sent by the third device based on the service XDR and the preset association between the service and the signaling can be realized by searching for the target signaling XDR from the local cache based on the service XDR and the preset association between the service and the signaling.

[0031] In particular, in order to save space and to avoid interference of past information with the latest information, each time the latest signaling XDR is received, the service information determined based on the previously received signaling XDR may be modified, or the latest received signaling XDR may be saved, and this will not be described here.

[0032] In step 403, the service XDR is updated according to the target signaling XDR.

[0033] In addition, since the service XDR sent by the third device may have missing fields due to missing information in the control plane, it is necessary to fill in the missing fields using the signaling XDR sent by the second device. Also, since it is possible that related fields that cannot be clearly determined are predicted using the collected information and filled in based on the predicted information, it is necessary to verify whether the fields are correct using the signaling XDR and correct them.

[0034] Based on this, in some examples, updating the service XDR according to the target signaling XDR can be achieved by identifying missing fields in the service XDR, retrieving information about the missing fields from the target signaling XDR, generating filler fields based on the retrieved information, and filling the filler fields into the service XDR. Here, before identifying the missing fields in the service XDR, the service XDR may first be inspected to determine whether a missing field condition has occurred, and when the occurrence of the missing field condition is detected, the updating of the service XDR may be achieved by backfilling the fields in the service XDR according to the target signaling XDR.

[0035] In some other examples, updating the service XDR according to the target signaling XDR can also be achieved by modifying the corresponding related fields in the service XDR when a mismatch is detected between the target signaling XDR and the service XDR in related fields that describe the same object in the signaling XDR and the service XDR.

[0036] The above examples have been explained separately from the perspectives of missing fields and field errors, but in other examples, the two can be combined by detecting whether or not a field is missing and then detecting whether or not a field error is present, but this will not be explained here.

[0037]

[0033] As mentioned above, a service XDR may correspond to more than one signaling XDR, and when a signaling XDR expires, resources occupied by the signaling XDR may be reclaimed. Based on this, when the termination of a service corresponding to a service XDR is detected, updating the service XDR according to the target signaling XDR can be further achieved by updating the service XDR according to the target signaling XDR, adding information indicating the termination of the service to the updated service XDR, and releasing resources used to maintain the signaling XDR corresponding to the service XDR after updating the service XDR according to the target signaling XDR. For example, after a SIP session is terminated, the first device tags the updated last RTP / RTCP service XDR of the SIP session with a call end tag and releases resources occupied for storing the signaling XDR.

[0038] In particular, if the signaling XDR received by the first device contains an empty set of information useful for filling in the service XDR, some data may be predicted using some mathematical processing methods or algorithms to update the service XDR. For example, when processing a VoLTE / VoNR service XDR, if some fields related to jitter and coding rate (e.g., RTCP Jitter, Codec Rate, Frame Rate) that are strongly related to the specific type of audio / video cannot be identified based on the service XDR, the unknown service type (Table 1) may be first clarified, and other fields may be calculated or predicted based on the pre-determined service type. The audio / video-related evaluation algorithm performs a tentative evaluation based on information such as the payload length and timestamp of the RTP message. Furthermore, even in an example where the service XDR is modified to update, a similar method may be used to modify the relevant fields via the service type in the signaling XDR.

[0039] Another aspect of the embodiment of the present application further provides a method for obtaining a service XDR applied to a second device, the flow of which is shown in FIG. 6, and may include at least the following steps:

[0040] In step 601, service data is collected from the user plane.

[0041] In this embodiment, the service data may be a data packet, a message, etc. The collection of the service data may be realized by using a hardware collection method such as installing a probe.

[0042] In step 602, a service XDR is generated based on the service data, with non-control related fields filled in.

[0043] In this embodiment, non-control related fields are fields that can be determined from the service data without having to rely on control plane data.

[0044] In some examples, filling in non-control related fields to generate a service XDR based on service data can be achieved by identifying fields that do not need to be determined based on control plane information, extracting information from the service data based on the identified fields to generate corresponding fields, and deriving a service XDR based on the generated fields.

[0045] In some other examples, after filling in non-control related fields based on the service data to generate the service XDR, further calculations and predictions are made based on the service data regarding fields related to control plane information and filled in the service XDR to further complement the service XDR.

[0046] Furthermore, the service XDR allows for the absence of fields related to control plane information and allows for the existence of information imbalances in fields related to control plane information, and when it is sent by the second device to the first device, the first device can supplement and correct it by receiving the signaling XDR sent by the third device.

[0047] In particular, the service XDR may be divided into two parts, such as two XDRs or two sub-XDRs that record the uplink service and the downlink service, respectively, but this is again not described here.

[0048] In step 603, the service XDR is sent to the first device.

[0049] Another aspect of the embodiment of the present application further provides a method for obtaining a service XDR applied to a third device, the flow of which is shown in FIG. 7, and may include at least the following steps:

[0050] In step 701, signaling is collected from the control plane.

[0051] In this embodiment, signaling collection can be achieved using a hardware collection method such as installing a probe.

[0052] In step 702, a signaling XDR is generated based on information about the service in the signaling.

[0053] This embodiment does not limit the representation format of the information about the service in the signaling, nor does it limit the periodicity of the control information recorded by the signaling XDR or the stage of the service. For example, if the service is a streaming media service, it may be information about the media flow in the SDP message body. One signaling XDR may be a record of multiple SDP message bodies transmitted in multiple related media negotiation processes in one session, or may be a record of the SDP message body in one media negotiation process.

[0054] Taking VoNR as an example, there is currently a description of SIP XDRs for SBCs. In addition, in this embodiment, we newly add the output of SDP XDRs, i.e., detailed records of the SDP negotiation process generated based on collected control plane SIP signaling. Here, the timing of outputting SIP XDRs for call flows remains the same: upon receiving the final response to the initial Invite request and upon receiving the session termination response. This is the same as the previous mechanism and remains unchanged. Meanwhile, unlike SIP XDRs, which are output only twice, one SDP XDR must be output at the end of each SDP media negotiation to ensure that the synthesis server can obtain the media negotiation results in a timely manner. Because SIP call flows are usually complex, Figure 8 can roughly reflect the timing from the creation to output of SDP XDRs. The SDP Offer and SDP Answer in Figure 8 represent the SDP offer / answer model, and the SDP XDR represents the media flow information in the SDP message body that needs to be collected. As can be seen from Figure 8, there are multiple media negotiations during a single SIP session, and even after a session is established, session modifications, i.e., new media negotiations, can occur, and one SDP XDR can be generated for each SDP message body collected during the media negotiation process.

[0055] In step 703, a signaling XDR is sent to the first device.

[0056] In the above-mentioned method embodiments, the service XDR acquisition methods are respectively described from the perspectives of the first device, the second device, and the third device. This is for the purpose of facilitating the description of the implementation of different functions, and does not mean that they must be implemented by different physical devices. For example, the first device and the second device may be integrated into the same physical device, and therefore the related sending and receiving are actually communication processes within the device, and are not described here.

[0057] In order to make it easier for those skilled in the art to understand the method of obtaining the service XDR mentioned in the above-mentioned embodiment, the following will describe the case where the signaling XDR is an SDP XDR and the service XDR is an RTP / RTCP XDR. However, in order to make it easier to distinguish from the conventional processing flow, SIP XDR will be further introduced below.

[0058] First, the third device recognizes the call request message based on the method=INVITE in the Request-URI of the acquired SIP message, requests resources necessary for call flow processing, and decodes the signaling. The third device then extracts relevant information elements from the encoding and fills them into corresponding interface fields in the collection specification, thereby creating a SIP Invite transaction XDR for the SIP call, a SIP session XDR, and a first SDP XDR_1 for the SDP message carried in the SIP Invite message. This SDP XDR is then used to update the RTP / RTCP XDR. The information carried in the SDP XDR similarly includes required and optional fields. The required fields are keys associated with multiple XDRs and must include at least the SIP CallID, SessionID, User_Type, calling / callee numbers, and source and destination media stream IP addresses. Meanwhile, the optional fields are related information reflecting the quality of the media streams extracted from the SDP, including the source media IP address, destination IP address, number of media streams, and media negotiation result. In this case, the fields are filled in when the Invite request message is received, so all that is filled in is the media information of the calling party.In particular, the newly added SDP_XDR interface can refer to the interface definition specification in "China Mobile 5G Network Connection Log Storage System Technical Specification - Control Plane Collection and Analysis Device Interface Specification 2.0.docx" and is designed as follows: [Table 2] JPEG0007796227000003.jpg219170JPEG0007796227000004.jpg200170

[0059] Of course, you can refer to other methods or create your own service XDR, and the above table is just an explanation showing specific examples.

[0060] Next, the third device collects non-100, non-3XX-6XX non-failure response messages, such as SIP 183. In this case, it first extracts SIP-related information, fills in the callee information in the SIP transaction XDR, and fills in the callee information in the SIP session XDR. If the message also carries SDP, it parses the SDP information and fills in the information carried by the callee in SDP XDR_1, while filling in some SIP-related control plane information in the SDP XDR_1. After the processing is completed, it outputs the SIP transaction XDR and SDP XDR and sends them to the first device via the IF1 interface. During a SIP session, if media negotiation is unsuccessful, according to the SIP protocol, both parties continue media negotiation through subsequent messages in the dialogue until negotiation is successful. If the initial negotiation fails and an Update message initiated by the caller is received again, the third device creates a new SDP XDR_2, parses the SDP message, and fills in the caller's information in SDP XDR_2. Since a negotiation request always results in a response, upon receiving a negotiation response such as 200 OK (Update), the third device parses the SDP message and fills in the called party's information in SDP XDR_2. It then fills in the SIP signaling-related fields in SDP XDR_2 with relevant information about the SIP session, completes processing of the SDP XDR field, and immediately transmits it via IF1. In this way, if media negotiation is performed multiple times, an SDP XDR is output each time, as described above. In particular, a media update may be initiated between session establishment and session termination, for example, due to a network error that causes the audio / video communication to be adjusted to audio-only communication. In this case, the SDP XDR is also processed and output according to the method described above. When the third device receives the Bye message, the call is terminated, or an internal session keep alive timer expires, it populates fields such as the call time interval and call termination information in the SIP session XDR.

[0061] Note that the SIP-related fields in the SDP XDR may be filled in when the SDP XDR is created, rather than processing SDP first and then SIP as described above. Information included in the SDP XDR, such as the session ID, call ID, and caller / callee numbers, may be managed together with the SIP session XDR, or may be extracted when the SDP XDR is output.

[0062] Regarding the generation of RTP / RTCP XDR by the second device, the main principle is to fill in as many accurate and uncontroversial field information as possible, such as slice direction, slice start time, slice end time, number of packets received, number of packets lost, link information, etc., and to refrain from fields that are determined depending on related information carried by other control planes.

[0063] In particular, when the SBC adopts CU separate deployment and processes VoLTE / VoNR media XDR, the media sub-module that processes user plane media data can first perform a pre-determination of the audio / video type bServerType field to be filled in. The pre-determination rule is as follows: if the timestamps of two consecutive RTP messages are the same, the bServerType field is determined to indicate video; if the timestamps of two consecutive RTP messages are different and the payload length of both is less than 500 bytes, the bServerType field is determined to indicate audio; if the timestamps of two consecutive RTP messages are different and the payload length of both is greater than 500 bytes, the bServerType field is determined to indicate video; and if the bServiceType is not recognized, only the number of received packets, the number of lost packets, etc. are counted, and jitter-related parameters and encoding rate-related parameters are not calculated.

[0064] On the other hand, when the first device receives SDP_XDR_1 sent by the third device, it must cache all information therein in SDP Info. If it subsequently receives SDP_XDR_n in the same SIP session, there is a change in the media negotiation. When it receives the new SDP_XDR, it must delete the media stream information that is no longer used and add the newly added media stream information, that is, it must immediately update the cached information. When it receives the RTP / RTCP XDR sent by the second device, if there is a gap in the RTP / RTCP XDR, it searches for the cached media stream information using the related information. If not found, it first caches the slice call record for 5 seconds. A specific time can be set. After the timeout, it attempts to backfill again. If related media stream information is found, it starts backfilling. Specifically, static information such as Session_ID, calling / called party number, Stream 1 Service_Type, Resolution_Width, and Resolution_Height are backfilled. If a mismatch occurs between the RTP / RTCP XDR and the SDP XDR, the ServerType in the SDP_Info is updated to the slice XDR, and fields such as RTP delay and jitter in the slice XDR are calculated and filled in according to the new values. In particular, if the media protocol machine calculates related fields such as RTP delay and jitter according to the pre-determination results during pre-determination, it must correct the original calculation if a mismatch is found at that time. Here, determining whether a mismatch occurs between the RTP / RTCP XDR and the SDP XDR is performed by finding the related SDP_Info information, obtaining the value of the ServerType field, and comparing it to determine whether the ServerType in the SDP XDR matches the ServerType in the slice.

[0065] In particular, the modification of fields in the RTP / RTCP XDR when the C / U are separated is also suitable for scenarios where the CU is integrated, and the newly added SDP XDR also records intermediate negotiations, making the data output by the RTP / RTCP XDR more accurate when the CU is integrated.

[0066] It should be understood that the division of steps in the above various methods is merely for the purpose of clarity, and that the steps may be integrated into one step or some steps may be subdivided into multiple steps during implementation, and that as long as they contain the same logical relationship, they are all within the scope of protection of the present application; and that as long as the core design of the algorithm or process is not changed and an insignificant modification is made to the algorithm or process, or an insignificant design is introduced, they are all within the scope of protection of the present application.

[0067] Another aspect of the present embodiment further provides an apparatus, as shown in FIG. 9, comprising: a receiving module 901 used for receiving a service XDR sent by a second device, the service XDR being generated based on service data collected from a user plane; a search module 902, which is used to search for a target signaling XDR among signaling XDRs sent by a third device based on the service XDR and the pre-configured association between the service and the signaling, the signaling XDR being generated based on information about the service in the signaling collected from the control plane; an update module 903, which is used to update the service XDR according to the target signaling XDR.

[0068] Another aspect of the present embodiment further provides an apparatus, as shown in FIG. 10, comprising: a first collection module 1001 used to collect service data from a user plane; a first generating module 1002 used to generate a service XDR by filling in non-control related fields based on the service data; a first sending module 1003 used to send the service XDR to the first device.

[0069] Another aspect of the present embodiment further provides an apparatus, as shown in FIG. 11, comprising: a second collecting module 1101 used to collect signaling from the control plane; a second generating module 1102 used to generate a signaling XDR based on information about the service in the signaling; a second sending module 1103 used to send the signaling XDR to the first device.

[0070] It is easy to understand that the above-mentioned apparatus embodiments correspond to the method embodiments, and the above-mentioned apparatus embodiments can be implemented in combination with the method embodiments. Since the relevant technical details mentioned in the method embodiments are also valid for the above-mentioned apparatus embodiments, they will not be described here to reduce duplication. Therefore, the relevant technical details mentioned in the above-mentioned apparatus embodiments are also applicable to the method embodiments.

[0071] In addition, each module in this embodiment is a logical module, and in actual application, one logical unit may be one physical unit, may be part of one physical unit, or may be realized by a combination of multiple physical units. In addition, in order to highlight the creative aspects of this application, means that are not closely related to solving the technical problem raised in this application are not introduced in this embodiment, but this does not mean that other means are not present in this embodiment.

[0072] Another aspect of an embodiment of the present application further provides an electronic device, as shown in FIG. 12, comprising at least one processor 1201 and a memory 1202 communicatively connected to the at least one processor 1201, wherein the memory 1202 stores instructions executable by the at least one processor 1201, and the instructions, when executed by the at least one processor 1201, enable the at least one processor 1201 to perform the method for obtaining a service XDR described in any one of the method embodiments above.

[0073] Here, the memory 1202 and the processor 1201 are connected via a bus system, which may include any number of interconnected buses and bridges, connecting various circuits of one or more processors 1201 and memory 1202 together. The bus may also connect various other circuits, such as peripherals, voltage regulators, and power management circuits, which are well known in the art and will not be further described herein. A bus interface provides an interface between the bus and a transceiver. The transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, and provides a means for communicating with various other devices over a transmission medium. Data processed by the processor 1201 is transmitted over a wireless medium via an antenna, which also receives and transmits data to the processor 1201.

[0074] In addition to being responsible for bus management and general processing, processor 1201 may also provide a variety of other functions, including timing, peripheral interfacing, voltage regulation, power management, and other control functions, while memory 1202 may be used to store data used in performing operations by processor 1201.

[0075] Another aspect of the present invention further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for obtaining a service XDR as set forth in any one of the method embodiments above.

[0076] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by instructing related hardware through a program. The program is stored in a storage medium and includes several instructions for causing a device (which may be a one-chip computer, chip, etc.) or a processor to execute all or part of the steps of the methods described in each embodiment of the present application. Meanwhile, the storage medium includes various media capable of storing program code, such as a USB memory, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0077] Those skilled in the art will understand that the above embodiments are specific examples for implementing the present application, and that in actual applications, various changes can be made in form and details without departing from the spirit and scope of the present application.

Claims

1. A method for obtaining a service XDR, applied to a first device, comprising: receiving (401) a service XDR sent by a second device, said service XDR being generated based on service data collected from a user plane; searching (402) for a target signaling XDR from among signaling XDRs sent by a third device based on the service XDR and a pre-configured association between the service and the signaling, the signaling XDRs being generated based on information about the service in the signaling collected from the control plane; updating (403) the service XDR according to the target signaling XDR; When an end of a service corresponding to the service XDR is detected, the step of updating the service XDR according to the target signaling XDR comprises: updating the service XDR according to the target signaling XDR, and adding information indicating the end of a service to the updated service XDR; After the step of updating the service XDR according to the target signaling XDR, the method further comprises: releasing resources used to maintain said signaling XDR corresponding to said service XDR; A method for obtaining a service XDR including:

2. The step (403) of updating the service XDR according to the target signaling XDR comprises: Identifying missing fields in the service XDR; retrieving information about the missing fields from the target signaling XDR and generating filler fields based on the found information; filling said filler fields into said service XDR; The method for obtaining a service XDR according to claim 1 , comprising:

3. The step (403) of updating the service XDR according to the target signaling XDR comprises: modifying the corresponding relevant fields in the service XDR when a mismatch is detected between the target signaling XDR and the service XDR in the relevant fields, the relevant fields being fields that describe the same object in the signaling XDR and the service XDR. The method for obtaining a service XDR according to claim 1 , comprising:

4. Before the step (402) of searching for a target signaling XDR among signaling XDRs sent by the third device based on the service XDR and a pre-configured association between a service and a signaling, the method further comprises: receiving the signaling XDR sent by the third device; caching the received signaling XDR in a local cache; The step of searching for a target signaling XDR from among the signaling XDRs sent by the third device based on the service XDR and a pre-configured association between a service and a signaling XDR comprises: retrieving the target signaling XDR in a local cache based on the service XDR and a pre-configured association of the service with signaling; The method for obtaining a service XDR according to any one of claims 1 to 3, comprising:

5. A method for obtaining a service XDR, applied to a second device, comprising: Collecting service data from a user plane (601); generating a service XDR based on the service data by filling in non-control related fields (602); and sending (603) said service XDR to a first device; The step of generating a service XDR based on the service data by filling in non-control related fields (602) comprises: determining a field that is determined independently of control plane information, extracting information from the service data based on the determined field to generate the corresponding field, and obtaining the service XDR based on the generated field; The step of obtaining the Service XDR includes filling in the non-control related fields to generate the Service XDR based on the service data, and then calculating and predicting fields related to the control plane information based on the service data, filling in the Service XDR, and further completing the Service XDR. How to obtain Service XDR.

6. a receiving module (901) used to receive a service XDR sent by a second device, the service XDR being generated based on service data collected from a user plane; a search module (902) used to search for a target signaling XDR among signaling XDRs sent by a third device based on the service XDR and a pre-configured association between the service and the signaling, the signaling XDRs being generated based on information about the service in the signaling collected from the control plane; an update module (903) used to update the service XDR according to the target signaling XDR; When the termination of the service corresponding to the service XDR is detected, an update module (903) used for updating the service XDR according to the target signaling XDR updates the service XDR according to the target signaling XDR and adds information indicating the termination of the service to the updated service XDR; After the update module (903) updates the service XDR according to the target signaling XDR, it releases resources used to maintain the signaling XDR corresponding to the service XDR. Device.

7. a first collection module (1001) used to collect service data from a user plane; a first generating module (1002) used to generate a service XDR based on said service data by filling in non-control related fields; a first sending module (1003) used to send the service XDR to a first device; A first generating module (1002) is used to generate a service XDR based on the service data by filling in non-control related fields, determining a field that is determined independently of control plane information, extracting information from the service data based on the determined field to generate the corresponding field, and obtaining the service XDR based on the generated field; After filling in the non-control related fields to generate the Service XDR based on the service data, calculating and predicting fields related to the control plane information based on the service data and filling in the Service XDR to further complement the Service XDR; Device.

8. An electronic device comprising at least one processor (1201) and a memory (1202) communicatively connected to the at least one processor (1201), The memory (1202) stores instructions executable by the at least one processor (1201), and the instructions are executed by the at least one processor (1201), thereby enabling the at least one processor (1201) to execute the service XDR acquisition method according to any one of claims 1 to 4 or the service XDR acquisition method according to claim 5. electronic equipment.

9. A computer-readable storage medium storing a computer program, When the computer program is executed by a processor, the computer program executes the method for acquiring a service XDR according to any one of claims 1 to 4 or the method for acquiring a service XDR according to claim 5. A computer-readable storage medium.

Images