Drive test method, device, equipment and storage medium

Abstract

This application provides a drive test method, apparatus, device, and storage medium, relating to the field of communications technology. The method comprises: obtaining a measurement report (MR) dataset; the MR dataset comprising MR data of one or more user devices in an area to be evaluated; obtaining a mobile user detail record (XDR) call bill dataset generated by the core network when one or more user devices dial a Long Term Evolution (VoLTE) service; the XDR call bill dataset comprising XDR call bills of one or more user devices; and conducting a drive test in the area to be evaluated based on the MR dataset and the XDR call bill dataset to obtain a drive test result for the area to be evaluated. This method is applicable to a drive test in a single area and is used to address the issue of insufficiently reflecting network issues.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a drive testing method, apparatus, device, and storage medium. Background Art

[0002] Traditional testing methods such as drive tests (DT) and call quality tests (CQT) are time-consuming, labor-intensive, and costly. They can only test limited roads and test points and cannot accurately locate network problems, resulting in some network problems remaining undetected, thus affecting network quality.

[0003] To address the problems of traditional testing methods such as DT and CQT, a virtual drive test solution called Minimization Drive Test (MDT) has been proposed. This solution can detect network problems based on measurement report (MR) data from commercial terminals.

[0004] However, current MR data cannot accurately reflect network problems. Summary of the Invention

[0005] The present application provides a drive test method, apparatus, device, and storage medium, which can be used to perform drive tests in combination with an XDR call record dataset and an MR dataset when a user device dials a VoLTE service, and can comprehensively and accurately provide feedback on network problems in the area to be evaluated.

[0006] In a first aspect, the present application provides a road test method, the method comprising: obtaining a measurement report (MR) data set; the MR data set including MR data of one or more user devices in an area to be evaluated; obtaining a mobile user detail record (XDR) call bill data set generated by a core network when one or more user devices dial a long term evolution voice bearer (VoLTE) service; the XDR call bill data set including XDR call bills of one or more user devices; and performing a road test on the area to be evaluated based on the MR data set and the XDR call bill data set to obtain a road test result for the area to be evaluated.

[0007] Optionally, the drive test result of the area to be evaluated includes location information, and network performance information and VoLTE status information corresponding to the location information.

[0008] Optionally, based on the MR data set and the XDR call record data set, a road test is performed on the area to be evaluated to obtain a road test result of the area to be evaluated, including: rasterizing the map of the area to be evaluated to obtain a rasterized map of the area to be evaluated; the rasterized map includes multiple grids; based on the rasterized map of the area to be evaluated, the MR data set, and the XDR call record data set, a road test is performed on the area to be evaluated to obtain a road test result of the area to be evaluated.

[0009] Optionally, the road test results of the area to be evaluated include the road sections where abnormal events occur in the area to be evaluated, and the network performance information and VoLTE status information corresponding to the road sections where the abnormal events occur. Based on the rasterized map of the area to be evaluated, the MR data set, and the XDR call record data set, the road test is performed on the area to be evaluated to obtain the road test results of the area to be evaluated, including: determining the road attributes of each grid based on the vector information in the high-precision map of the area to be evaluated; the road attributes include road or non-road; based on the grid with the road attribute being road and the preset road section segmentation length, the road in the rasterized map of the area to be evaluated is divided into multiple rasterized sections; based on the multiple rasterized sections, the MR data set, and the XDR call record data set, the road test is performed on the area to be evaluated to determine the road sections where abnormal events occur, and the network performance information and VoLTE status information corresponding to the road sections where the abnormal events occur.

[0010] Optionally, based on multiple rasterized road sections, MR data sets, and XDR call record data sets, road tests are performed on the area to be evaluated to determine the road section where the abnormal event occurred, as well as the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred, including: determining the abnormal call record from the XDR call record data set based on preset non-connection rules and call drop rules; the abnormal call record is an XDR call record generated when an abnormal event occurs in the user equipment; the abnormal events include VoLTE non-connection and VoLTE call drop; based on the timestamp and mobile station international services digital network number MSISDN in the abnormal call record, determining the target MR data corresponding to the abnormal call record; based on multiple rasterized road sections and the location information in the target MR data, determining the road section where the abnormal event occurred; based on the abnormal call record and the target MR data, determining the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred.

[0011] Optionally, the XDR call record includes a VoLTE Session Initiation Protocol SIP interface call record and an Evolved Packet Core Network EPC_S1MME interface call record;

[0012] The no-connect rule includes the following conditions being met simultaneously:

[0013] The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface;

[0014] The process type indicated by the process field in the VoLTE SIP interface call record is the call type;

[0015] The process status field in the VoLTE SIP interface call record indicates a failed state;

[0016] The sum of the call answering duration and the call connection duration in the VoLTE SIP interface call log is 0.

[0017] The call drop rule includes the following conditions being met simultaneously:

[0018] The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface;

[0019] The process type indicated by the process field in the VoLTE SIP interface call record is the call type;

[0020] The process status field in the VoLTE SIP interface call record indicates a successful status;

[0021] The MSISDN in the VoLTE SIP interface call log is the same as the MSISDN in the EPC_S1MME interface call log.

[0022] The interface type field in the EPC_S1MME interface call record indicates the interface is the S1-MME interface;

[0023] The call record type field in the EPC_S1MME interface call record indicates the context release type;

[0024] The context release completion time in the EPC_S1MME interface call record is between the process start time and the process end time in the VoLTE SIP interface call record.

[0025] The context release reason field in the EPC_S1MME interface call record is a field other than the preset field.

[0026] Optionally, the abnormal call list includes an abnormal VoLTE SIP interface call list and an abnormal EPC_S1MME interface call list; for the VoLTE failure in the abnormal event, based on the timestamp and the mobile station international service digital network number MSISDN in the abnormal call list, determining the target MR data corresponding to the abnormal call list, including: determining one or more candidate MR data including the unconnected MSISDN from the MR data set; the unconnected MSISDN is the MSISDN in the abnormal VoLTE SIP interface call list; based on the abnormal VoLTE The process start time in the SIP interface call record is used as the target MR data, by determining the candidate MR data whose start time in the MR data is closest to the process start time from one or more candidate MR data; for the VoLTE call drop in the abnormal event, the target MR data corresponding to the abnormal call record is determined based on the timestamp and the mobile station international services digital network number MSISDN in the abnormal call record, including: determining one or more candidate MR data including the dropped call MSISDN from the MR data set; the dropped call MSISDN is the MSISDN in the abnormal EPC_S1MME interface call record; based on the context release completion time in the abnormal EPC_S1MME interface call record, determining the candidate MR data whose start time in the MR data is closest to the context release completion time from one or more candidate MR data as the target MR data.

[0027] The drive test method provided in this application can combine the MR dataset and the XDR call record dataset generated when the user equipment dials the VoLTE service to perform road testing on the area to be evaluated. Compared with the traditional MDT solution, this application combines the MR dataset and the XDR call record dataset, and the evaluation indicators are more comprehensive, which improves the reliability of virtual drive testing.

[0028] In addition, the road testing method provided in this application can divide the roads in the rasterized map of the area to be evaluated into multiple rasterized sections, and locate abnormal events in specific sections. It converts traditional single event problem points into sections where abnormal events occur to identify network problems, which can facilitate focusing on and processing sections with serious problems at the abnormal event level.

[0029] In a second aspect, the present application provides a drive test device, which may include: an acquisition module and a processing module.

[0030] An acquisition module is configured to acquire a measurement report (MR) data set for the area to be evaluated; the MR data set includes MR data of one or more user devices in the area to be evaluated; and an XDR call record data set generated by the core network when one or more user devices dial a Long Term Evolution (VoLTE) voice bearer service. The XDR call record data set includes XDR call records for one or more user devices.

[0031] The processing module is used to perform a drive test on the area to be evaluated based on the MR data set and the XDR call record data set to obtain a drive test result of the area to be evaluated.

[0032] Optionally, the drive test result of the area to be evaluated includes location information, and network performance information and VoLTE status information corresponding to the location information.

[0033] Optionally, the processing module is specifically used to rasterize the map of the area to be evaluated to obtain a rasterized map of the area to be evaluated; the rasterized map includes multiple grids; based on the rasterized map of the area to be evaluated, the MR data set, and the XDR call record data set, a road test is performed on the area to be evaluated to obtain a road test result of the area to be evaluated.

[0034] Optionally, the road test results of the area to be evaluated include the road sections where abnormal events occur in the area to be evaluated, and the network performance information and VoLTE status information corresponding to the road sections where abnormal events occur. The processing module is specifically used to determine the road attributes of each grid based on the vector information in the high-precision map of the area to be evaluated; the road attributes include road or non-road; based on the grid with the road attribute being road, and the preset road section segmentation length, the roads in the rasterized map of the area to be evaluated are divided into multiple rasterized road sections; based on the multiple rasterized road sections, the MR data set, and the XDR call record data set, a road test is performed on the area to be evaluated to determine the road sections where abnormal events occur, and the network performance information and VoLTE status information corresponding to the road sections where abnormal events occur.

[0035] Optionally, the processing module is specifically used to determine an abnormal call record from the XDR call record data set based on preset unconnected rules and dropped call rules; the abnormal call record is an XDR call record generated when an abnormal event occurs in the user equipment; the abnormal events include VoLTE unconnected and VoLTE dropped calls; based on the timestamp and mobile station international services digital network number MSISDN in the abnormal call record, the target MR data corresponding to the abnormal call record is determined; based on multiple rasterized road sections and the location information in the target MR data, the section where the abnormal event occurred is determined; based on the abnormal call record and the target MR data, the network performance information and VoLTE status information corresponding to the section where the abnormal event occurred are determined.

[0036] Optionally, the XDR call record includes a VoLTE Session Initiation Protocol SIP interface call record and an Evolved Packet Core Network EPC_S1MME interface call record;

[0037] The no-connect rule includes the following conditions being met simultaneously:

[0038] The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface;

[0039] The process type indicated by the process field in the VoLTE SIP interface call record is the call type;

[0040] The process status field in the VoLTE SIP interface call record indicates a failed state;

[0041] The sum of the call answering duration and the call connection duration in the VoLTE SIP interface call log is 0.

[0042] The call drop rule includes the following conditions being met simultaneously:

[0043] The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface;

[0044] The process type indicated by the process field in the VoLTE SIP interface call record is the call type;

[0045] The process status field in the VoLTE SIP interface call record indicates a successful status;

[0046] The MSISDN in the VoLTE SIP interface call log is the same as the MSISDN in the EPC_S1MME interface call log.

[0047] The interface type field in the EPC_S1MME interface call record indicates the interface is the S1-MME interface;

[0048] The call record type field in the EPC_S1MME interface call record indicates the context release type;

[0049] The context release completion time in the EPC_S1MME interface call record is between the process start time and the process end time in the VoLTE SIP interface call record.

[0050] The context release reason field in the EPC_S1MME interface call record is a field other than the preset field.

[0051] Optionally, the abnormal call record includes an abnormal VoLTE SIP interface call record and an abnormal EPC_S1MME interface call record; for VoLTE failure in an abnormal event, the processing module is specifically used to determine one or more candidate MR data including an unconnected MSISDN from the MR data set; the unconnected MSISDN is the MSISDN in the abnormal VoLTE SIP interface call record; based on the process start time in the abnormal VoLTE SIP interface call record, the candidate MR data whose starting time in the MR data is closest to the process start time is determined from one or more candidate MR data as the target MR data; for VoLTE call drop in the abnormal event, the processing module is specifically used to determine one or more candidate MR data including a dropped call MSISDN from the MR data set; the dropped call MSISDN is the MSISDN in the abnormal EPC_S1MME interface call record; based on the context release completion time in the abnormal EPC_S1MME interface call record, the candidate MR data whose starting time in the MR data is closest to the context release completion time is determined from one or more candidate MR data as the target MR data.

[0052] In a third aspect, the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the steps of the related method described in the first aspect to implement the method described in the first aspect.

[0053] In a fourth aspect, the present application provides an electronic device comprising a processor and a memory; the memory stores instructions executable by the processor; when the processor is configured to execute the instructions, the electronic device implements the method described in the first aspect above.

[0054] In a fifth aspect, the present application provides a readable storage medium, which includes: software instructions; when the software instructions are executed in an electronic device, the electronic device implements the method described in the first aspect above.

[0055] The beneficial effects of the second to fifth aspects mentioned above can be referred to those described in the first aspect and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0057] Figure 1A schematic diagram of the structure of a drive test system provided in an embodiment of the present application;

[0058] Figure 2 A schematic diagram of the composition of an electronic device provided in an embodiment of the present application;

[0059] Figure 3 A schematic diagram of a flow chart of a drive test method provided in an embodiment of the present application;

[0060] Figure 4 This is a diagram of the voice call signaling process for the VoLTE service;

[0061] Figure 5 A schematic diagram of the map rasterization process provided in an embodiment of the present application;

[0062] Figure 6 A schematic diagram of a gridded road section provided in an embodiment of the present application;

[0063] Figure 7 A schematic diagram of geographic grid presentation provided in an embodiment of the present application;

[0064] Figure 8 A schematic diagram of the structure of a drive test device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0066] It should be noted that in the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described in the embodiments of this application as "exemplarily" or "for example" should not be interpreted as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0067] In order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with basically the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order.

[0068] Traditional testing methods such as DT and CQT are time-consuming, labor-intensive, and costly. They can only test limited roads and test points and are unable to accurately locate network problems, causing some network problems to remain undetected, thus affecting network quality.

[0069] To address the problems of traditional testing methods such as DT and CQT, a virtual drive testing solution called MDT has been proposed. This solution can detect network problems based on MR data from commercial terminals.

[0070] However, current MR data cannot accurately reflect network problems.

[0071] On this basis, the embodiments of the present application provide a drive test method, apparatus, device, and storage medium, which can perform drive testing in combination with the XDR call record dataset and MR dataset when the user device dials a VoLTE service, and can comprehensively and accurately feedback network problems in the area to be evaluated.

[0072] The following is an introduction with reference to the accompanying drawings.

[0073] Figure 1 This is a schematic diagram of the composition of the drive test system provided in the embodiment of the present application. Figure 1 As shown, the system may include: user equipment (UE) 100, a base station 200, a mobile user detail record (XDR) server 300, and a first server 400. The user equipment 100 and the base station 200 may be connected via a wireless network, and the base station 200, the XDR server 300, and the first server 400 may be connected via a wired network or a wireless network.

[0074] The user device 100 may be a mobile phone, a tablet computer, a wearable device, an in-vehicle device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), or the like. Figure 1 (This is illustrated using a mobile phone as an example only.) This embodiment of the application does not limit the specific type of the user equipment 100.

[0075] The user equipment 100 may be configured to receive wireless signals transmitted by the base station 200 .

[0076] In some embodiments, the user equipment 100 may also measure the signal strength and signal quality of the wireless signal transmitted by the base station 200 and other network performance information and report it to the base station 200 on the service channel at a speed of milliseconds.

[0077] The base station 200 may be an evolved Node B (eNB), a next generation node B (gNB) with a measurement function, etc. The embodiment of the present application does not limit the specific type of the base station 200.

[0078] The XDR server 300 can be an electronic device with computing and processing capabilities, such as a computer or server. The server can be a single server or a server cluster consisting of multiple servers. In some implementations, the server cluster can also be a distributed cluster. The embodiments of this application do not limit the specific form of the XDR server 300.

[0079] The XDR server 300 may be used to collect XDR call record data generated by the core network when the user equipment 100 dials a voice over long term evolution (VoLTE) service.

[0080] The specific form of the first server 400 can refer to the description of the XDR server 300, which will not be repeated here.

[0081] The first server 400 may perform a drive test on the area to be evaluated according to the drive test method provided in the following method embodiment. The specific process may refer to that described in the following method embodiment and will not be repeated here.

[0082] It should be noted that Figure 1 In the example, the XDR server 300 and the first server 400 are independent devices. However, the first server 400 and the XDR server 300 may be combined into one server, that is, the XDR server 300 or the corresponding functions and the first server 400 or the corresponding functions may be integrated into the same device. This embodiment of the present application is not limited to this.

[0083] The execution entity of the drive testing method provided in the embodiments of the present application may be the aforementioned first server 400, the XDR server 300, or a device comprising the XDR server 300 and the first server 400. As described above, both the XDR server 300 and the first server 400 may be electronic devices with computing and processing capabilities, such as computers or servers. Optionally, the execution entity of the drive testing method provided in the embodiments of the present application may also be a processor in the aforementioned electronic device; or an application (APP) with drive testing capabilities installed in the aforementioned electronic device; or, alternatively, a functional module with drive testing capabilities in the aforementioned electronic device. This embodiment of the present application is not limited in this regard.

[0084] For simplicity of description, the drive test method provided in the embodiments of the present application is described below using the above-mentioned electronic device as an example of an execution subject.

[0085] Figure 2 This is a schematic diagram of the composition of the electronic device provided in the embodiment of the present application. Figure 2 As shown, the electronic device may include: a processor 10 , a memory 20 , a communication line 30 , a communication interface 40 , and an input / output interface 50 .

[0086] The processor 10 , the memory 20 , the communication interface 40 , and the input / output interface 50 may be connected via a communication line 30 .

[0087] The processor 10 is used to execute the instructions stored in the memory 20 to implement the road test method provided in the following embodiments of the present application. The processor 10 can be a central processing unit (CPU), a general-purpose processor network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller (MCU) / single chip microcomputer / single chip microcomputer, a programmable logic device (PLD) or any combination thereof. The processor 10 can also be any other device with processing functions, such as a circuit, a device or a software module, which is not limited in the embodiments of the present application. In one example, the processor 10 may include one or more CPUs, such as Figure 2 As an optional implementation, the electronic device may include multiple processors, for example, in addition to the processor 10, it may also include a processor 60 ( Figure 2 The dashed line is used as an example.

[0088] The memory 20 is used to store instructions. For example, the instruction may be a computer program. Optionally, the memory 20 may be a read-only memory (ROM) or other types of static storage devices that can store static information and / or instructions, or a random access memory (RAM) or other types of dynamic storage devices that can store information and / or instructions, or an electrically erasable programmable read-only memory (EEPROM), a CD-ROM or other optical disk storage, an optical disk storage (including a compact disc, a laser disc, an optical disc, a digital versatile disc, a Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, etc., and the embodiments of the present application are not limited thereto.

[0089] It should be noted that the memory 20 may exist independently of the processor 10 or may be integrated with the processor 10. The memory 20 may be located inside the electronic device or outside the electronic device, which is not limited in the embodiment of the present application.

[0090] The communication line 30 is used to transmit information between the components included in the electronic device.

[0091] Communication interface 40 is used to communicate with other devices (such as base station 200) or other communication networks. Such other communication networks may be Ethernet, radio access networks (RAN), wireless local area networks (WLAN), etc. Communication interface 40 may be a module, circuit, transceiver, or any other device capable of communication.

[0092] The input / output interface 50 is used to implement human-computer interaction between a user and the electronic device, such as action interaction, text interaction, or voice interaction.

[0093] For example, the input / output interface 50 may be a keyboard, a mouse, etc. Action interaction or text interaction between a user and the electronic device may be achieved through the keyboard, the mouse, etc.

[0094] It should be noted that Figure 2 The structure shown in the figure does not constitute a limitation on the electronic device, except Figure 2 In addition to the components shown, the electronic device may include more or fewer components than shown, or a combination of certain components, or a different arrangement of components.

[0095] The drive test method provided in the embodiments of the present application is introduced below with reference to the accompanying drawings.

[0096] Figure 3 Schematic diagram of the process flow of the drive test method provided in the embodiment of the present application. Figure 2 The electronic device of the hardware structure shown is executed as Figure 3 As shown, the method may include S101 to S103.

[0097] S101. An electronic device obtains a measurement report (MR) data set.

[0098] The MR data set may include MR data of one or more user equipment in the area to be evaluated.

[0099] Exemplarily, the MR data may specifically include the data shown in Table 1 below.

[0100] Table 1: MR data (MDT data) format

[0101]

[0102]

[0103]

[0104] The details in Table 1 can be referred to the related art and will not be repeated here.

[0105] S102: The electronic device obtains an XDR call record data set generated by the core network when one or more user equipments in the MR data set dial a VoLTE service.

[0106] The XDR call record data set may include XDR call records of the one or more user devices. The XDR call records may include VoLTE session initiation protocol (SIP) interface call records and evolved packet core (EPC)-S1MME interface call records.

[0107] VoLTE service is a voice call service based on the SIP protocol. All signaling interacting with the Internet Protocol Multimedia Subsystem (IMS) is SIP signaling. Therefore, in the XDR call record, the entire signaling process for VoLTE service is recorded in the VoLTE SIP interface call record.

[0108] Illustratively, the VoLTE SIP interface call record may be as shown in Table 2 below.

[0109] Table 2: VoLTE SIP interface call record data format

[0110]

[0111]

[0112]

[0113]

[0114]

[0115]

[0116]

[0117]

[0118] The specific content in Table 2 can be referred to in the related art and will not be repeated here.

[0119] For example, Figure 4 The following is a diagram of the voice call signaling process for VoLTE services. Figure 4 As shown, the voice call signaling mainly includes the following parts:

[0120] 1) From 1 to 6, the UE initiates a call. The UE's upper layer protocol layer needs to send an INVITE to the IMS, triggering processes such as radio resource control (RRC) connection and security mode. It also establishes an SRB2 signaling radio bearer and restores the QCI5 bearer through an RRC reconfiguration message, and configures measurement control. The IMS receives the caller's INVITE message and starts paging, and sends an INVITE 100 (TRYING) to the calling UE in response to the INVITE message. The INVITE message contains the call type, calling and called numbers, and the media types and codecs supported by the caller.

[0121] 2) From 7 to 15, the core network sends an INVITE message to the called party in the idle state. Since the called party is in the idle state, the core network side triggers a paging message to page the called user in the idle state. After the called UE receives the paging, it triggers the RRC connection, security mode and other processes. The called party establishes an SRB2 signaling radio bearer through the RRC reconfiguration message. The CN side sends an INVITE message to the called party through the RB with QCI=5. After receiving the message, the UE sends an INVITE 100 message in response. At the same time, the called party sends an INVITE 183 message to the CN to indicate that the session is being processed, starts the Precondition (resource reservation) process, notifies the caller of the media types and encodings it supports, and establishes a bearer with QCI=1.

[0122] 3) 16 to 17, after receiving the called party's INVITE 83, the IMS starts the Precondition (resource reservation) process for the calling party, notifies the calling party's SM layer through the EPC to establish a bearer with QCI=1, and then sends the INVITE 183 information to the UE.

[0123] 4) From 18 to 25, the calling party sends a PRACK message to the called party. The PRACK process is a pre-confirmation process, mainly to prevent session timeout and congestion. After receiving the PRACK200 from the called party, the calling party returns a PRACK200. After receiving the PRACK200 from the called party, the calling party sends an UPDATE message to negotiate the media format. The called party returns the negotiation result through UPDATE200.

[0124] 5) 26 to 31 is the ringing and answering process. The called party sends INVITE 180 to the calling party. After ringing and picking up the phone, it sends INVITE 200 to the calling party. The calling party returns ACK for confirmation. The call is completely established and enters the call process.

[0125] 6) 32 to 37 are the hang-up process. After the call is completed, the calling party sends a BYE request to end the current session. The IMS server sends a BYE to the called party, requesting the end of the current session. The called party hangs up and returns a BYE200 message. The core network IMS server sends a BYE200 to the calling party, indicating the end of the session. The calling party and the called party each deactivate the EPS dedicated bearer message and delete the data radio bearer with QCI = 1.

[0126] As can be seen from the VoLTE SIP interface call record shown in Table 2 above, the interface call record mainly includes the SIP interface type, SIP process type, and process status, which mainly involve the voice service connection process. The voice call process is recorded in the EPC_S1MME interface call record.

[0127] Exemplarily, the EPC_S1MME interface call record may be as shown in Table 3 below.

[0128] Table 3: EPC_S1MME interface call record data format

[0129]

[0130]

[0131]

[0132]

[0133]

[0134] The specific content of Table 3 can be referred to in the related art and will not be repeated here.

[0135] S103: The electronic device performs a drive test on the area to be evaluated based on the MR data set and the XDR call record data set to obtain a drive test result of the area to be evaluated.

[0136] In a possible implementation, the drive test result of the electronic device on the area to be evaluated may specifically include location information, and network performance information and VoLTE status information corresponding to the location information.

[0137] For example, location information can include latitude and longitude in MR data, or the position of a grid in a gridded road segment. The gridded road segment can be described in another possible implementation described below and will not be further described here. Network performance information can include information such as signal strength and / or signal quality in MR data. VoLTE status information can include normal call, unconnected, or dropped call status. For details, please refer to another possible implementation described below and will not be further described here.

[0138] Optionally, the electronic device may divide the area to be evaluated into a plurality of grids and perform drive testing according to the divided grids. In this case, the above S103 may specifically include the following two steps:

[0139] Step 1: The electronic device rasterizes the map of the area to be evaluated to obtain a rasterized map of the area to be evaluated.

[0140] The rasterized map includes multiple grids.

[0141] Optionally, Figure 5 This is a flow chart of map rasterization provided in the embodiment of the present application. Figure 5 As shown, the above step 1 may specifically include S201 to S209.

[0142] S201 : The electronic device cuts out a map of the area to be evaluated from the overall map using a side length set by the user.

[0143] The overall map may include multiple areas, and the multiple areas may include the area to be evaluated.

[0144] For example, the electronic device may receive a side length set by the user through the above-mentioned input and output interface.

[0145] S202 : The electronic device uses the point where the outermost side of the north side of the area to be evaluated is tangent to the latitude as the first tangent point.

[0146] S203 : The electronic device uses the point where the westernmost side of the area to be evaluated is tangent to the meridian as the second tangent point.

[0147] S204: The electronic device uses the point where the latitude line passing through the first tangent point intersects the longitude line passing through the second tangent point as the upper left corner vertex of the starting grid.

[0148] S205. The electronic device determines the longitude and latitude of the center point of the 5th grid of the starting grid based on the upper left corner vertex and the preset length of the starting grid, and determines the longitude and latitude of the center point of the Mth grid on the outermost diagonal line extending southward and eastward from the starting grid based on the size and the preset length of the map of the area to be evaluated.

[0149] S206 , the electronic device starts from the starting grid and expands southward along the longitude to determine whether the longitudes of the center points of the adjacent 1st, 2nd, ..., Nth grids satisfy Yn≤Ym.

[0150] If Yn≤Ym, execute S207.

[0151] The value range of N is (1, 2, ..., M-1). Ym is the latitude of the center point of the Mth outermost grid of the diagonal line extending southward and eastward from the starting grid in S205.

[0152] For example, the electronic device can start from the starting grid, first keep the latitude of the starting grid unchanged, expand the grid southward in the longitude direction with a preset length as the side length of the square, calculate the central longitude and latitude of the next grid based on the equally spaced expanded side lengths, compare the central longitude Yn of the next grid with the above Ym, and if Yn is less than or equal to Ym, execute S207.

[0153] S207 , the electronic device continues to expand outward to the next grid, and the center accuracy of the next grid is Yn1 =Yn+P.

[0154] Among them, P is the precision bias of the distance conversion between the longitude and latitude of two adjacent grid centers, which can be approximately regarded as the above-mentioned preset length, and the value range of n1 is (2, 3, ..., M).

[0155] For example, when Yn satisfies less than or equal to Ym, the electronic device can continue to expand to the next grid Yn1, and keep the latitude equal to the starting grid. If Yn≤Ym is always satisfied, the loop continues to step S206; if Yn is greater than Ym, execute S208.

[0156] S208 , the electronic device starts from the starting grid and expands eastward along the latitude line, and determines whether the latitude release of the midline points of the adjacent 1st, 2nd, ..., gth grids satisfies Xg≤Xm.

[0157] If Xg≤Xm, the execution continues to loop to S206; if Xg>Xm, the execution continues to S209.

[0158] The value range of g is (1, 2, ..., M-1). Xm is the longitude of the center point of the Mth outermost grid of the diagonal line extending southward and eastward from the starting grid in S205.

[0159] When the grid longitude Yn of the starting grid expanded southward along the longitude is greater than Ym, it is necessary to expand eastward along the latitude and calculate the center latitude of the next grid based on the length of the equally spaced expansion side. The center latitude Xg1 is equal to Xg+Q, where Q is the latitude offset of the distance conversion between the center longitudes and longitudes of adjacent grids.

[0160] S209: The electronic device assigns a unique identifier to the grid that has completed expansion in the area to be evaluated.

[0161] It should be noted that the above S201 to S209 are described in the order of first expanding southward along the longitude and then expanding eastward along the latitude. The electronic device can also first expand eastward along the latitude and then expand southward along the latitude, or perform rasterization in other expansion orders (for example, selecting different vertices of the map of the area to be evaluated as the starting grid to start expansion). The embodiments of the present application are not limited to this.

[0162] Step 2: The electronic device performs a drive test on the area to be evaluated based on the rasterized map of the area to be evaluated, the MR dataset, and the XDR call record dataset, and obtains a drive test result of the area to be evaluated.

[0163] In another possible implementation, the drive test results of the area to be evaluated may include the road section where the abnormal event occurred, as well as network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred. In this case, the above step 2 may specifically include the following steps:

[0164] Step 2.1: The electronic device determines the road attributes of each grid based on the vector information in the high-precision map of the area to be evaluated.

[0165] The road attribute includes road or non-road.

[0166] For example, the specific classification of the road attributes of the grid may be as shown in Table 4 below.

[0167] Table 4: Road attribute classification table

[0168]

[0169]

[0170] Optionally, the electronic device may generate a border through software, and based on the road attributes of the grid, use the generated border to mark each road to form a closed loop area.

[0171] Optionally, after marking each road to form a closed-loop area, the electronic device may further assign an ID to the border corresponding to each road.

[0172] Optionally, specific rules for assigning IDs are as follows:

[0173] ① First-level road border ID: Pro-City-level 1-000001~N (N is a maximum of 6 digits, 999999), Pro is the province, and City is the province to which the city belongs.

[0174] ② Secondary road border ID: Pro-City-level 2-000001~N (N is a maximum of 6 digits, 999999), Pro is the province, and City is the province to which the city belongs.

[0175] ③Third-level road border ID: Pro-City-level 3-000001~N (N is a maximum of 6 digits, 999999), Pro is the province, and City is the province to which the city belongs.

[0176] ④ Fourth-level road border ID: Pro-City-level 4-000001~N (N is a maximum of 6 digits, 999999), Pro is the province, and City is the province to which the city belongs.

[0177] ⑤Expressway border ID: Pro-City-Expressway-000001~N (N is a maximum of 4 digits, 9999), Pro is the province, and City is the province to which the city belongs.

[0178] For example, the road border ID may be as shown in Table 5 below.

[0179] Table 5: Road border ID table for some roads in Shanghai

[0180]

[0181]

[0182] As shown in Table 5, the table includes road number items, road attribute items, road name items, and matching attribute items. Road number items include Shanghai-Shanghai-Level 1-000001, Shanghai-Shanghai-Level 1-000002, Shanghai-Shanghai-Level 2-000001, Shanghai-Shanghai-Level 3-000001, and Shanghai-Shanghai-Expressway-0001; road attribute items include primary roads, secondary roads, tertiary roads, and expressways; road name items include Pudong Avenue, Hutai Road, Kaixuan Road, Hutai Branch Road, and Shenhai Expressway; and matching attribute items include roads. There is a correspondence between Shanghai-Shanghai-Level 1-000001, primary roads, Pudong Avenue, and roads. There is a correspondence between Shanghai-Shanghai-Level 1-000002, primary roads, Hutai Road, and roads. There is a correspondence between Shanghai-Shanghai-Level 2-000001, secondary roads, Kaixuan Road, and roads. There is a correspondence between Shanghai-Shanghai-Level 3-000001, third-level roads, Hutai Branch Road, and roads. There is a correspondence between Shanghai-Shanghai-Expressway-0001, expressways, Shenhai Expressway, and roads.

[0183] Step 2.2: The electronic device divides the road in the rasterized map of the area to be evaluated into a plurality of rasterized road segments based on the road attribute being a road grid and a preset road segment division length.

[0184] The segment length may be preset in the electronic device by a manager, or may be determined by the electronic device according to a scene selection rule preset by the manager. Each of the plurality of gridded road segments may include a plurality of grids.

[0185] For example, for each road, the electronic device may start from the starting point of the road and divide the road into multiple rasterized road segments according to the segment lengths.

[0186] For example, taking the total length of the road as 600 meters as an example, the scene selection rules can be specifically as follows:

[0187] 1) Dense urban areas (applicable to 50-meter standard length road section cutting)

[0188] The 600-meter road is divided into 12 grid sections of 50-meter standard length. Each section is assigned a unique number. The grid section numbering rules are as follows:

[0189] Road name - Standard length section mark (50 meters) - Grid section ID number (000001 to 999999)

[0190] 2) Dense urban areas or general urban areas (applicable to 100-meter standard length road section cutting)

[0191] The 600-meter road is divided into six grid sections with a standard length of 100 meters. Each section is assigned a unique number. The grid section numbering rules are as follows:

[0192] Road name - Standard length section identifier (100 meters) - Grid section ID number (000001 to 999999)

[0193] 3) General urban scenarios (applicable to 200-meter standard length road section cutting)

[0194] The 600-meter road is divided into three grid sections with a standard length of 200 meters. Each section is assigned a unique number. The grid section numbering rules are as follows:

[0195] Road name - Standard length section identifier (200 meters) - Grid section ID number (000001 to 999999)

[0196] 4) Suburban or rural scenes (applicable to 300-meter standard length road cutting)

[0197] The 600-meter road is divided into two grid sections with a standard length of 300 meters. Each section is assigned a unique number. The grid section numbering rules are as follows:

[0198] Road name - Standard length section identifier (300 meters) - Grid section ID number (000001 to 999999)

[0199] For example, see Figure 6 , Figure 6 This is a schematic diagram of a gridded road section provided in an embodiment of the present application. Figure 6 4 shows the segmentation of several different road segmentation lengths, taking Zhongshan Road as an example.

[0200] Step 2.3: The electronic device performs a road test on the evaluation area based on multiple rasterized road sections, the MR dataset, and the XDR call record dataset to determine the road section where the abnormal event occurred and the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred.

[0201] In a possible implementation, step 2.3 may specifically include the following steps:

[0202] Step 2.3.1: The electronic device determines abnormal call records from the XDR call record data set based on preset unconnected rules and call drop rules.

[0203] An abnormal call record is an XDR call record generated when an abnormal event occurs on a user device. Abnormal events include VoLTE call failure and VoLTE call drop.

[0204] From the above Figure 4 The voice call signaling process shown in the figure shows that the entire process includes the normal connection process and the normal call process. According to the VoLTE voice call signaling process, the corresponding fields of the VoLTE SIP interface call record and the EPC_S1MME interface call record in the XDR call record are correlated. By analyzing the meaning of the fields in the call record corresponding to the normal signaling process, the rules for missed connection and dropped calls are formulated.

[0205] First, let’s introduce the no-connection rules

[0206] Through the VoLTE service call process, we can see that it mainly includes the process from the caller initiating INVITE to triggering RRC connection, security mode, etc., and then to the core network side triggering a paging message, paging the called user in the idle state, and after the called UE receives the paging, it triggers RRC connection, security mode, etc., and finally to the ringing and answering process. The fields corresponding to the VoLTE SIP interface call record mainly include SIP interface type, SIP process type, and process status. Therefore, the VoLTE voice service call process can be associated with the SIP signaling process in the VoLTE SIP interface call record. The main association process is as follows:

[0207] 1) SIP interface type in VoLTE SIP protocol interface call records

[0208] XDR call records are generated by the core network. Therefore, the interfaces between multiple network elements in the IMS core network can be found through the "Interface" field in the VoLTE SIP protocol interface call record. When interface = 12, the SIP signaling process of the SI-U interface is obtained, which is consistent with the SIP signaling process of the VoLTE voice service call process:

[0209] Interface type:

[0210] 12.S1-U (S1 user interface, limited to SIP)

[0211] 13.Gm

[0212] 14.Mw

[0213] 15.Mg

[0214] 16.Mi

[0215] 17.Mj

[0216] 18.ISC

[0217] 19.Sv

[0218] 20.Cx

[0219] 21.Dx

[0220] 22.Sh

[0221] 23.Dh

[0222] 24.Zh

[0223] 25.Gx

[0224] 26.Rx

[0225] 27.I2

[0226] 28.Nc (Interface between MGCF and gateway office)

[0227] 29.ATCF-SCCAS

[0228] 2) SIP process type in VoLTE SIP interface call records

[0229] After confirming that the interface type in the XDR call record is the voice service SIP protocol (that is, the interface type field is set to 12, indicating the interface is the S1 user plane interface), the "procedure_type" process type field description in the VoLTE SIP protocol interface call record can be queried. When procedure_type = 5, that is, the "Calling" type, it indicates that the voice service process is in the voice call state, which is consistent with the SIP signaling process of the VoLTE voice service call process:

[0230] Process type code, the specific values ​​are as follows:

[0231] 1: Register;

[0232] 2: Deregister;

[0233] 3:3rd-Register;

[0234] 4:3rd-Deregister;

[0235] 5: Calling;

[0236] 6: INVITE from eMSC (this value also applies to INVITE for handover notification between ATCF and SCC AS interfaces);

[0237] 7: MESSAGE (SRVCC);

[0238] 8: Other--OPTION and other message processes

[0239] 9: Re-Register

[0240] 81: subscribe--SUBSCRIBE request and its response message

[0241] 82: notify--NOTIFY request and its response message

[0242] 83: options--OPTIONS request and its response message (optional)

[0243] 84: short-message--MESSAGE request and its response message not registered by esrvcc

[0244] 85: publish--PUBLISH request and its response message

[0245] 86: refer--REFER request and its response message

[0246] 3) SIP process status in VoLTE SIP protocol interface call records

[0247] After confirming in the second step that the VoLTE service process type is a voice call state (that is, the process type field is set to 5, indicating that the process type is the call type "Calling"), the "procedure_status" process status field description in the VoLTE SIP protocol interface call record can be queried. When procedure_status = 1, the call is in the "successful" state; when procedure_status = 2, the call is in the "failed" state; when procedure_status = 3, the call is in the "cancelled" state; when procedure_status = 4, the call is in the "timeout" state.

[0248] Process status:

[0249] 1: Success;

[0250] 2: Failure;

[0251] 3: Cancel;

[0252] 4: Timeout

[0253] 4) SIP Time Node Process in VoLTE SIP Protocol Interface Call Record

[0254] After the conditions of steps 1 to 3 are met, the four key time points in the VoLTE call process are confirmed, as shown in Table 6:

[0255] Table 6: Important event nodes in the VoLTE call process

[0256]

[0257]

[0258] As shown in Table 6, the four important time nodes in the VoLTE call process mainly include:

[0259] ①procedure_start_time: process start time

[0260] ②procedure_end_time: process end time

[0261] ③ alerting_time: duration of call connection (valid when procedure_type is 5 or 6. Duration of call connection. This field is relative time, with the received 180 response message without the P-Early-Media header field as the ALERTING message, relative to the initial INVITE)

[0262] ④answer_time: Call answering time (valid when procedure_type is 5 or 6. Call answering time. This field is relative time, with the 200 response message received to the initial INVITE as the ANSWER message, and the initial INVITE as the relative benchmark)

[0263] The normal call process of VoLTE voice service includes the voice service access process and the voice service call holding process. Based on the above four time nodes, the procedure_start_time to alerting_time / answer_time is defined as the call access process; the period from answer_time to procedure_end_time is defined as the call holding process. The details are shown in Table 7 below:

[0264] Table 7: VoLTE voice service process

[0265]

[0266] Based on the process shown in Table 7 above, the connection rule may specifically include the following items being satisfied simultaneously:

[0267] 1. The interface field in the VoLTE SIP interface call record indicates the S1 user plane interface.

[0268] 2. The process type indicated by the process field in the VoLTE SIP interface call record is the call type.

[0269] 3. The process status field in the VoLTE SIP interface call record indicates a successful state.

[0270] The connection rule may also be specifically expressed as follows according to the fields of the VoLTE SIP interface call record shown in Table 2 above: interface=12and procedure_type=5and procedure_status=1.

[0271] Similarly, the unconnected rule may specifically include the following items being met simultaneously:

[0272] 1. The interface field in the VoLTE SIP interface call record indicates the S1 user plane interface.

[0273] 2. The process type indicated by the process field in the VoLTE SIP interface call record is the call type.

[0274] 3. The process status field in the VoLTE SIP interface call record indicates a failed state.

[0275] 4. The sum of the call answering duration and the call connection duration in the VoLTE SIP interface call record is 0.

[0276] The unconnected rule can also be specifically expressed as follows according to the fields of the VoLTE SIP interface call record shown in Table 2 above: interface=12and procedure_type=5and procedure_status=2and (answer_time+alerting_time=0).

[0277] Then introduce the call drop rules

[0278] As shown in Table 3 above, in the EPC_S1MME interface call record, there are two fields: "interface" (interface type) and "sdrtype" (call record type) related to the voice call process:

[0279] 1) "interface" interface type

[0280] When interface = 32, it indicates that the CDR comes from the S1MME interface and contains the VoLTE voice service process.

[0281] 2) "sdrtype" call record type

[0282] When sdrtype=5, even if it is "context release", it means that the call record belongs to the context release type during the voice call process. It is necessary to further confirm the fields contained in this type. The data format is shown in Table 8 below:

[0283] Table 8: Context Release Call Record Data Format

[0284]

[0285]

[0286]

[0287]

[0288] Table 8 shows that the "Context Release" call record contains important fields such as the terminal release request time, release completion time, and release reason. When the release reason "RElEASE_CAUSE" has a value of 2, 20, or 23, it is considered a normal release based on the value content. All other values ​​indicate abnormal releases. Therefore, it is necessary to first filter out call records that meet the connection definition based on the VoLTE SIP interface call record. Then, by associating the mobile phone number in the call record with the call status of the same number in the EPC_S1MME interface call record, a call drop rule is generated. Specifically, the call drop rule includes the following conditions that are met simultaneously:

[0289] 1) The interface field in the VoLTE SIP interface call record indicates the S1 user plane interface.

[0290] 2) The process type indicated by the process field in the VoLTE SIP interface call record is the call type.

[0291] 3) The status indicated by the process status field in the VoLTE SIP interface call record is a successful status.

[0292] After filtering out the SIP incoming call records according to 1) to 3), filter out the S1MME dropped call details for the corresponding UE number, and meet the following conditions:

[0293] 4) The MSISDN in the VoLTE SIP interface call log is the same as the MSISDN in the EPC_S1MME interface call log.

[0294] 5) The interface type field in the EPC_S1MME interface call record indicates that the interface is the S1-MME interface.

[0295] 6) The call record type indicated by the call record type field in the EPC_S1MME interface call record is the context release type.

[0296] 7) The context release completion time in the EPC_S1MME interface call record is between the process start time in the VoLTE SIP interface call record and the process end time in the VoLTE SIP interface call record.

[0297] 8) The context release reason field in the EPC_S1MME interface call record is a field other than the preset field.

[0298] The call drop rule can also be specifically expressed as follows according to the fields of the VoLTE SIP interface call list shown in Table 2 and the fields of the EPC_S1MME interface call list shown in Table 3: interface = 12 and procedure_type = 5 and procedure_status = 1 and EPC_S1MME.MSISDN = volte_sip.MSISDN and volte_sip.Procedure_Start_Time <EPC_S1MME.COMP_TIME<volte_sip.Procedure_End_Time andEPC_S1MME.interface=31and EPC_S1MME.SDRtype=5and EPC_S1MME.release_causenot in[2,20,23]。

[0299] Step 2.3.2: The electronic device determines the target MR data corresponding to the abnormal call record based on the timestamp and the Mobile Station International Services Digital Network Number (MSISDN) in the abnormal call record.

[0300] Among them, abnormal call records may include abnormal VoLTE SIP interface call records and abnormal EPC_S1MME interface call records.

[0301] Optionally, for the VoLTE failure in an abnormal event, the above step 2.3.2 may specifically include the following steps:

[0302] Step 2.3.2.1: The electronic device determines one or more candidate MR data including an unconnected MSISDN from the MR data set.

[0303] The MSISDN that is not connected is the MSISDN in the abnormal VoLTE SIP interface call record.

[0304] For example, after the electronic device determines abnormal call records (including abnormal VoLTE SIP interface call records) according to the above-mentioned unconnected rules and dropped call rules, for each abnormal VoLTE SIP interface call record, it determines that the MSISDN in the abnormal VoLTE SIP interface call record is an unconnected MSISDN, and then uses the unconnected MSISDN as an index to traverse the MR data set and screen out one or more MR data including the unconnected MSISDN as candidate MR data.

[0305] Step 2.3.2.2: Based on the process start time in the abnormal VoLTE SIP interface call record, the electronic device determines, from one or more candidate MR data, the candidate MR data whose start time is closest to the process start time as the target MR data.

[0306] Specifically, when VoLTE is not connected, the electronic device may select target MR data from candidate MR data according to the following formula (1):

[0307] min{|Volte sip.procedure_starttime m -MDT.orig_time n |} Formula (1)

[0308] In formula (1), m represents the user whose UE meets the abnormal event of not being connected on the core network side, and n represents the period of MDT reporting by the corresponding user UE.

[0309] Since the UE reports MDT periodically according to the operator's specifications, it uses a fixed time period (usually the default value: collection period 10240ms) during the service process. The MDT data indicators collected and reported by the UE are shown in Table 9 below:

[0310] Table 9: MDT data indicators

[0311]

[0312]

[0313]

[0314]

[0315] The specific content in Table 9 can be referred to in the related art and will not be repeated here.

[0316] While the UE is collecting and reporting MDT data, the core network will generate VoLTE XDR data which will be collected by the background XDR server. The VoLTE SIP protocol interface call record data indicators in the XDR call record collected by the XDR server during the corresponding time period are shown in Table 10 below:

[0317] Table 10: VoLTE SIP interface call record data indicators

[0318]

[0319] Taking the data listed in Tables 9 and 10 above as an example, for abnormal events in which VoLTE connection is not established, the electronic device can specifically filter the target MR data according to Table 11 below:

[0320] Table 11: Target MR data screening table

[0321]

[0322]

[0323] The preceding table shows that after subtracting the "procedure start time" for the VoLTE SIP interface call record when a disconnection event occurs from the "time stamp of the MDT period reported by the corresponding UE number" one by one, the minimum absolute value is taken. When the procedure_starttime1 for the disconnection event is subtracted from all the timestamps of the MDT period reported by the corresponding UE number (i.e., MDT.orig_time1, MDT.orig_time2, MDT.orig_time3, MDT.orig_time4, MDT.orig_time5, MDT.orig_time6, MDT.orig_time7, and MDT.orig_time8), the minimum absolute value is 1.082s. The corresponding result is the subtraction of procedure_starttime1 from MDT.orig_time4. Therefore, the timestamps for aligning the voice service disconnection event and the corresponding UE-reported MDT data are procedure_starttime1 and MDT.orig_time4.

[0324] Optionally, for a VoLTE call drop in an abnormal event, step 2.3.2 may specifically include the following steps:

[0325] Step 2.3.2.3: The electronic device determines one or more candidate MR data including the dropped call MSISDN from the MR data set.

[0326] The dropped call MSISDN is the MSISDN in the abnormal EPC_S1MME interface call record.

[0327] Step 2.3.2.4: Based on the context release completion time in the abnormal EPC_S1MME interface call record, the electronic device determines, from one or more candidate MR data, the candidate MR data whose start time is closest to the context release completion time as the target MR data.

[0328] Specifically, for a VoLTE call drop, the electronic device may filter target MR data from candidate MR data according to the following formula (2):

[0329] min{|EPC_S1MME comp_time o -MDT.orig_time n |} Formula (2)

[0330] In formula (2), o represents the user whose UE meets the call drop exception event on the core network side.

[0331] Step 2.3.3: The electronic device determines the road section where the abnormal event occurs based on the multiple rasterized road sections and the position information in the target MR data.

[0332] For example, the electronic device can use the longitude and latitude information in the target MR data as location information, and determine the road section where the abnormal event occurred based on the location information and the high-precision map.

[0333] Step 2.3.4: The electronic device determines the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred based on the abnormal call record and the target MR data.

[0334] The VoLTE status information may include VoLTE not connected or VoLTE call dropped.

[0335] In the drive test method provided in the embodiment of the present application, the electronic device can combine the MR dataset and the XDR call record dataset generated when the user equipment dials the VoLTE service to perform a road test on the area to be evaluated. Compared with the traditional MDT solution, the present application combines the MR dataset and the XDR call record dataset, and the evaluation indicators are more comprehensive, thereby improving the reliability of the virtual drive test.

[0336] In addition, in the road testing method provided in the embodiment of the present application, the electronic device can divide the roads in the rasterized map of the area to be evaluated into multiple rasterized sections, and locate abnormal events in specific sections, converting traditional single event problem points into sections where abnormal events occur to identify network problems, which can facilitate focusing on and processing sections with serious problems at the abnormal event level.

[0337] In some possible embodiments, after obtaining the road test results of the area to be evaluated, the electronic device can also count the number of VoLTE failures and the number of VoLTE dropped calls on each road section, and divide the abnormal road sections into dropped call problem sections, non-connection problem sections, and abnormal event problem sections, etc. according to the number of VoLTE failures and the number of VoLTE dropped calls.

[0338] Optionally, specific division rules are as follows:

[0339] 1) Conditions for call drop problem sections: The number of call drops between 50m and 300m is greater than or equal to [5, 10, 20, 30] times (the number of call drops for sections of different lengths can be adjusted based on actual network conditions).

[0340] 2) Conditions for unconnected sections: The number of unconnected times between 50m and 300m is greater than or equal to [10, 20, 30, 40] times (the number of unconnected times for sections of different lengths can be adjusted based on the actual network conditions).

[0341] 3) Problem road section of abnormal events: one of the conditions of call drop or unconnected problem road section is met.

[0342] In some possible embodiments, in order to further improve the efficiency of analyzing and locating problems related to abnormal voice service events, the electronic device may automatically analyze and locate network problems based on a preset root cause algorithm.

[0343] Abnormal road voice service incidents are closely related to inadequate wireless network coverage and poor downlink SINR quality. Generally, these incidents in macro base station scenarios are categorized into five main types: weak coverage, overcoverage, overlapping coverage, MOD3 interference, and poor downlink quality. These incidents are located by correlating the latitude and longitude of the MDT with indicators such as the primary serving cell downlink SINR, primary serving cell TA, primary serving cell RSRP, PCI, neighboring cell RSRP, PCI overlap coverage ratio, and MOD3 interference rate.

[0344] 1. When an abnormal event occurs, the corresponding primary service cell converges

[0345] According to the target MR data, enb_id and eci are obtained, and the coverage RSRP, downlink SINR and other parameter values ​​of each sampling point of the primary serving cell mapped to enb_id and eci are obtained. As shown in the following Table 12:

[0346] Table 12: Cell aggregation index table

[0347]

[0348]

[0349]

[0350] From the above table, it can be seen that by associating the abnormal event with the MDT through the timestamp, the SINR and level coverage strength contained in each MDT sampling point in the primary serving cell where the abnormal event occurred can be associated.

[0351] 2. Road grid aggregation of TA indicators in the main service cell in MDT

[0352] TA represents the distance between the UE and the antenna port. This metric is defined as the time the UE uses to adjust its primary cell PUCCH / PUSCH / SRS uplink transmissions. The specific calculation method is as follows: During random access, the eNodeB determines the timing advance (TA) value by measuring the received pilot signal. The TA value range is (0, 1, 2, ..., 1282) × 16Ts. In the RRC connected state, the eNodeB determines the TA adjustment value for each UE based on measurements of the corresponding UE's uplink transmission. This adjustment value range is (0, 1, 2, ..., 63) × 16Ts. The latest TA is the sum of the previously recorded TA and the adjustment value measured by the eNodeB. The TA distance corresponding to 1Ts is equal to: (3 * 10^8 * 1 / (15000 * 2048)) / 2 = 4.89 meters. This means that distance = propagation speed (speed of light) * 1Ts / 2 (sum of uplink and downlink paths). The distance corresponding to the TA command value is calculated with reference to 1Ts.

[0353] 1) TA value range in the MDT specification:

[0354] The value range is shown in the following table. For example, from 0 to 192Ts, every 16Ts is an interval, corresponding to MR.Tadv.00 to MR.Tadv.11; from 192Ts to 1024Ts, every 32Ts is an interval, corresponding to MR.Tadv.12 to MR.Tadv.37; from 1024Ts to 2048Ts, every 256Ts is an interval, corresponding to MR.Tadv.38 to MR.Tadv.41; from 2048Ts to 4096Ts, every 1048Ts is an interval, corresponding to MR.Tadv.42 and MR.Tadv.43; greater than 4096Ts is an interval, corresponding to MR.Tadv.44.

[0355] For example, the TA value range and the converted coverage distance range in the MDT specification may be specifically shown in Table 13 below:

[0356] Table 13: MDT specification TA value range and conversion coverage distance table

[0357]

[0358]

[0359] 2) This measurement data can be used to determine the distance between the UE and the base station, perform cell coverage analysis, determine whether adjustments to the cell antenna are necessary, and examine whether the base station's coverage area is reasonable, including issues such as overcoverage and shadow areas. TA can also be used to assist in providing location services. Table 14 below shows the specific content of MDT including longitude and latitude, including TA data.

[0360] Table 14: Related indicators of latitude and longitude in MDT data

[0361]

[0362]

[0363]

[0364] Table 14 shows that each sampling point includes the TA and level coverage intensity, including the TA of each sampling point, which is contained in each grid and grid section along the longitude and latitude. The TA ratio of a single grid can be aggregated, and the conversion relationship between the measured data interval distribution and the converted coverage distance interval distribution can be used to calculate the ratio of different coverage ranges in the grid and grid section.

[0365] 3. Road grid convergence of the main service cell overlap coverage index in MDT

[0366] Definition of overlapping coverage sampling point: Based on the premise that the RSRP of the sampling point on the covered road is stronger than -100dBm, if the number of neighboring cells with a level difference of less than 6dB between the current primary serving cell and the neighboring cells of the MDT sampling point is greater than or equal to 3, then the sampling point is an overlapping coverage sampling point.

[0367] 1) If the number of neighboring cells where the level difference between the current primary serving cell and the neighboring cells at the MDT sampling point is less than 6 dB is 3, the overlap coverage of the MR sampling point is defined as 1.

[0368] 2) If the number of neighboring cells where the level difference between the current primary serving cell and the neighboring cells at the MDT sampling point is less than 6 dB is 4, the MR sampling point is defined as having overlapping coverage of 2.

[0369] 3) By analogy, if the number of neighboring cells with a level difference of less than 6dB between the current primary serving cell and the neighboring cells at the MDT sampling point = n, then the MR sampling point is defined as overlapping coverage = n (n is the maximum number of neighboring cells added to the primary serving cell).

[0370] The overlapping coverage of the sampling point is calculated by the power level strength of the primary serving cell and the power levels of multiple neighboring cells in the MDT table, as shown in Table 15 below:

[0371] Table 15: Overlap coverage index table in MDT data

[0372]

[0373]

[0374] Table 15 shows that lte_cd represents the overlap coverage calculated based on the level difference between the primary serving cell and the neighboring cell at the MDT sampling point. Once the overlap coverage is calculated for each sampling point and associated with its longitude and latitude, the overlap coverage ratio for each grid and road segment can be aggregated to calculate the overlap coverage ratio for each grid and road segment.

[0375] 4. Road grid aggregation of MOD3 interference rate index of primary service cell in MDT

[0376] Definition of a MOD3 interference sampling point: Based on the premise that the RSRP of the sampling point on the covered road is stronger than -100dBm, if the level difference between the current primary serving cell and the neighboring cell at the MDT sampling point is less than 6dB and the scrambling code PCI modulo 3 remainder results are the same, then the sampling point is a MOD3 interference sampling point.

[0377] 1) If the level difference between the current primary serving cell and the neighboring cells at the MDT sampling point is less than 6dB, and the number of neighboring cells is 3 and the scrambling code PCI modulo 3 remainder is the same, then the MR sampling point is defined as MOD3 interference level = 1.

[0378] 2) If the level difference between the current primary serving cell and the neighboring cells at the MDT sampling point is less than 6dB, the number of neighboring cells = 4 and the scrambling code PCI modulo 3 remainder is the same, then the MR sampling point is defined as MOD3 = 2.

[0379] 3) By analogy, if the level difference between the current primary serving cell and the neighboring cells at the MDT sampling point is less than 6dB, the number of neighboring cells = n and the scrambling code PCI modulo 3 remainder results are the same, then the MR sampling point is defined as MOD3 interference degree = n (n is the maximum number of neighboring cells added to the primary serving cell).

[0380] The MOD3 interference rate of the sampling point is calculated by the power level strength of the primary serving cell and the power levels of multiple neighboring cells in the MDT table, as shown in Table 16 below:

[0381] Table 16: MOD3 interference rate indicator table of MDT data summary

[0382]

[0383]

[0384] Based on the understanding of the above four parts 1-4, the preset root cause algorithm can be specifically shown in the following Table 17:

[0385] Table 17: Root cause algorithm table

[0386]

[0387]

[0388] In some possible embodiments, the electronic device can also define the abnormal road section in a closed loop, and automatically determine whether the historical problem grid road section has returned to normal through weekly comparison, thereby forming a problem point control table for the road grid road section.

[0389] It supports statistics by region, which can visually present the problem solving status, distribution of unresolved problems and the top n legacy issues, so as to keep abreast of the progress of solving road legacy issues.

[0390] Based on the unique identification number of each road grid section and the definition of problem sections for voice service legacy events, control is implemented for sections that meet the definition of voice service abnormal event problems. Based on weekly indicator statistics, the number of new problem sections, the number of closed-loop problem sections, and all problem sections throughout the entire cycle are automatically updated to form a comprehensive voice service abnormal event problem section control table. The specific implementation is as follows:

[0391] 1) Control of road sections with abnormal voice service incidents

[0392] ① Based on the road grid segment definition, the system automatically counts all problem segments for voice service anomaly events, including closed-loop problem segments and newly added problem segments. This system covers all problem segments throughout the entire cycle and forms a comprehensive management table for all problem segments for voice service anomaly events. This system supports zoning display based on focused, non-focused, prefecture-level cities, districts and counties, administrative regions, and units.

[0393] ② Based on the definition of road grid sections, the comparison of the sections with abnormal voice service events in the current cycle and the previous cycle is automatically counted. Based on the unique identification of the road grid sections, overlapping sections are identified as the same problem section. If there is a problem section in the current cycle but not in the previous cycle, it is a newly added abnormal event section; if there is a problem section in the current cycle but not in the previous cycle, it is a closed-loop abnormal event section. The closed-loop definition of voice service abnormal event problems is as follows:

[0394] A. Closed-loop conditions for call drop problem sections: The number of call drops between 50m and 300m is less than or equal to [0, 2, 4, 6] times (the number of call drops for sections of different lengths can be adjusted based on actual network conditions)

[0395] B. Closing condition for unconnected sections: The number of unconnected times between 50m and 300m is less than or equal to [1, 3, 5, 7] times (the number of unconnected times for sections of different lengths can be adjusted based on the actual network conditions)

[0396] C. Closing conditions for abnormal event problem sections: one of the closing conditions for call drops or unconnected problem sections is met

[0397] 2) Closing rate of problem sections with abnormal voice service events

[0398] According to the number of closed loops on problem sections related to voice service abnormal events / the number of various problem sections

[0399] For example, the full voice service abnormal event problem section control table may be specifically shown in the following Table 18:

[0400] Table 18: Statistics of abnormal events in voice services

[0401]

[0402] In some embodiments, the electronic device can also select different layers, different areas, different road section categories and road section lengths to present voice service dropped call events and unconnected events, thereby realizing a virtual road test for the geographical and rapid assessment of abnormal voice service event problems on the road, replacing the traditional time-consuming and labor-intensive manual analysis mode.

[0403] After completing the above steps, it is possible to achieve geographic grid presentation of key indicators of road disconnection events and call drop time based on different regions, different road sections, and road section lengths. The main implementation contents are as follows:

[0404] 1. Road indicator raster presentation - voice service abnormal event indicator

[0405] 1) Number of dropped calls

[0406] 2) Call drop rate

[0407] 3) Number of missed calls

[0408] 4) Unconnected rate

[0409] For example, see Figure 7 , Figure 7 This is a schematic diagram of geographic grid presentation provided in an embodiment of the present application. Figure 7 (a) and (b) in FIG. 5 show several situations of geographical presentation according to different road sections and different abnormal events.

[0410] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to realize the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. It should be easy to realize that the technical goals in this field are combined with the units and algorithm steps of each example described in the embodiments disclosed herein, and the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technical goals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0411] In an exemplary embodiment, the present application also provides a drive test device. Figure 8 A schematic diagram of the composition of the drive test device provided in the embodiment of the present application is shown as follows: Figure 8 As shown, the device may include: an acquisition module 801 and a processing module 802.

[0412] An acquisition module 801 is configured to acquire a measurement report (MR) dataset for an area to be evaluated; the MR dataset includes MR data of one or more user equipment in the area to be evaluated; and acquire a mobile user detail record (XDR) call bill dataset generated by a core network when one or more user equipment dials a Long Term Evolution (VoLTE) service; the XDR call bill dataset includes XDR call bills for one or more user equipment.

[0413] The processing module 802 is configured to perform a drive test on the area to be evaluated based on the MR data set and the XDR call record data set to obtain a drive test result of the area to be evaluated.

[0414] In some possible embodiments, the drive test results of the area to be evaluated include location information, and network performance information and VoLTE status information corresponding to the location information.

[0415] In other possible embodiments, the processing module 802 is specifically used to rasterize the map of the area to be evaluated to obtain a rasterized map of the area to be evaluated; the rasterized map includes multiple grids; based on the rasterized map of the area to be evaluated, the MR data set, and the XDR call record data set, a road test is performed on the area to be evaluated to obtain a road test result of the area to be evaluated.

[0416] In some other possible embodiments, the road test results of the area to be evaluated include the road sections where abnormal events occurred in the area to be evaluated, and the network performance information and VoLTE status information corresponding to the road sections where the abnormal events occurred. The processing module 802 is specifically used to determine the road attributes of each grid based on the vector information in the high-precision map of the area to be evaluated; the road attributes include road or non-road; based on the grid with the road attribute being road and the preset road section segmentation length, the road in the rasterized map of the area to be evaluated is divided into multiple rasterized road sections; based on the multiple rasterized road sections, the MR data set, and the XDR call record data set, a road test is performed on the area to be evaluated to determine the road sections where abnormal events occurred, and the network performance information and VoLTE status information corresponding to the road sections where the abnormal events occurred.

[0417] In some other possible embodiments, the processing module 802 is specifically used to determine an abnormal call record from the XDR call record data set based on preset non-connection rules and dropped call rules; the abnormal call record is an XDR call record generated when an abnormal event occurs in the user equipment; the abnormal events include VoLTE non-connection and VoLTE dropped calls; based on the timestamp and mobile station international services digital network number MSISDN in the abnormal call record, the target MR data corresponding to the abnormal call record is determined; based on multiple rasterized road sections and the location information in the target MR data, the road section where the abnormal event occurred is determined; based on the abnormal call record and the target MR data, the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred are determined.

[0418] In some further possible embodiments, the XDR call record includes a VoLTE Session Initiation Protocol SIP interface call record and an Evolved Packet Core Network EPC_S1MME interface call record;

[0419] The no-connect rule includes the following conditions being met simultaneously:

[0420] The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface;

[0421] The process type indicated by the process field in the VoLTE SIP interface call record is the call type;

[0422] The process status field in the VoLTE SIP interface call record indicates a failed state;

[0423] The sum of the call answering duration and the call connection duration in the VoLTE SIP interface call log is 0.

[0424] The call drop rule includes the following conditions being met simultaneously:

[0425] The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface;

[0426] The process type indicated by the process field in the VoLTE SIP interface call record is the call type;

[0427] The process status field in the VoLTE SIP interface call record indicates a successful status;

[0428] The MSISDN in the VoLTE SIP interface call log is the same as the MSISDN in the EPC_S1MME interface call log.

[0429] The interface type field in the EPC_S1MME interface call record indicates the interface is the S1-MME interface;

[0430] The call record type field in the EPC_S1MME interface call record indicates the context release type;

[0431] The context release completion time in the EPC_S1MME interface call record is between the process start time and the process end time in the VoLTE SIP interface call record.

[0432] The context release reason field in the EPC_S1MME interface call record is a field other than the preset field.

[0433] In some other possible embodiments, the abnormal call list includes an abnormal VoLTE SIP interface call list and an abnormal EPC_S1MME interface call list; for the VoLTE failure in the abnormal event, the processing module 802 is specifically configured to determine one or more candidate MR data including an unconnected MSISDN from the MR data set; the unconnected MSISDN is the MSISDN in the abnormal VoLTE SIP interface call list; based on the abnormal VoLTE The process start time in the SIP interface call record is used as the target MR data, and the candidate MR data whose start time is closest to the process start time is determined from one or more candidate MR data; for the VoLTE call drop in the abnormal event, the processing module 802 is specifically used to determine one or more candidate MR data including the dropped call MSISDN from the MR data set; the dropped call MSISDN is the MSISDN in the abnormal EPC_S1MME interface call record; based on the context release completion time in the abnormal EPC_S1MME interface call record, the candidate MR data whose start time is closest to the context release completion time is determined from one or more candidate MR data as the target MR data.

[0434] It should be noted that Figure 8The module division described in the preceding text is illustrative and represents only one logical functional division. In actual implementation, other divisions may be employed. For example, two or more functions may be integrated into a single processing module. This is not a limitation of the present application. The integrated modules described above may be implemented in either hardware or software functional modules.

[0435] In an exemplary embodiment, the present application also provides a readable storage medium, including: an execution instruction, which, when executed on an electronic device, enables the electronic device to execute any one of the methods provided in the above embodiments.

[0436] In an exemplary embodiment, the present application also provides a computer program product including computer-executable instructions, which, when executed on an electronic device, enables the electronic device to execute any one of the methods provided in the above embodiments.

[0437] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer-executable instructions. When the computer-executable instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer-executable instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer-executable instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0438] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude multiple components. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0439] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, the present application is intended to include such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

[0440] The above is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or replacements within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A drive test method, characterized in that: The method comprises: Acquire a measurement report MR data set; the MR data set includes MR data of one or more user equipment in the area to be evaluated; Obtaining a mobile user detail record XDR call bill data set generated by a core network when the one or more user devices dial a Long Term Evolution Voice Bearer VoLTE service; the XDR call bill data set includes the XDR call bills of the one or more user devices; Rasterizing the map of the area to be evaluated to obtain a rasterized map of the area to be evaluated; the rasterized map includes a plurality of grids; Determining the road attributes of each grid based on the vector information in the high-precision map of the area to be evaluated; the road attributes include road or non-road; Based on the road attribute being a road grid and a preset road segmentation length, dividing the road in the rasterized map of the area to be evaluated into a plurality of rasterized road segments; Based on preset unconnected rules and call drop rules, an abnormal call record is determined from the XDR call record data set; the abnormal call record is an XDR call record generated when the abnormal event occurs in the user equipment; the abnormal event includes VoLTE unconnected and VoLTE call drop; the abnormal call record includes abnormal VoLTE SIP interface call record and abnormal EPC_S1MME interface call record; For the VoLTE failure in the abnormal event, one or more candidate MR data including an unconnected MSISDN are determined from the MR data set; the unconnected MSISDN is the MSISDN in the abnormal VoLTE SIP interface call record; based on the process start time in the abnormal VoLTE SIP interface call record, the candidate MR data whose start time is closest to the process start time is determined from the one or more candidate MR data as the target MR data; For the VoLTE call drop in the abnormal event, one or more candidate MR data including the dropped call MSISDN are determined from the MR data set; the dropped call MSISDN is the MSISDN in the abnormal EPC_S1MME interface call record; based on the context release completion time in the abnormal EPC_S1MME interface call record, the candidate MR data whose start time is closest to the context release completion time is determined from the one or more candidate MR data as the target MR data; determining the road section where the abnormal event occurred based on the plurality of rasterized road sections and position information in the target MR data; Based on the abnormal call record and the target MR data, the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred are determined; the road test results of the area to be evaluated include the road section where the abnormal event occurred in the area to be evaluated, and the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred.

2. The method according to claim 1, characterized in that The drive test result of the area to be evaluated includes location information, and network performance information and VoLTE status information corresponding to the location information.

3. The method according to claim 1, characterized in that XDR call records include VoLTE Session Initiation Protocol (SIP) interface call records and Evolved Packet Core Network (EPC_S1MME) interface call records. The unconnected rule includes the following conditions being met simultaneously: The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface; The process type indicated by the process field in the VoLTE SIP interface call record is the call type; The state indicated by the process status field in the VoLTE SIP interface call record is a failure state; The sum of the call answering duration and the call connection duration in the VoLTE SIP interface call record is 0; The call drop rule includes the following conditions being met simultaneously: The interface indicated by the interface field in the VoLTE SIP interface call record is the S1 user plane interface; The process type indicated by the process field in the VoLTE SIP interface call record is the call type; The status indicated by the process status field in the VoLTE SIP interface call record is a success status; The MSISDN in the VoLTE SIP interface call record is the same as the MSISDN in the EPC_S1MME interface call record; The interface indicated by the interface type field in the EPC_S1MME interface call record is the S1-MME interface; The call record type indicated by the call record type field in the EPC_S1MME interface call record is the context release type; The context release completion time in the EPC_S1MME interface call record is between the process start time in the VoLTE SIP interface call record and the process end time in the VoLTE SIP interface call record; The context release reason field in the EPC_S1MME interface call record is a field other than the preset field.

4. A drive test device, characterized in that: The device comprises: an acquisition module and a processing module; The acquisition module is configured to acquire a measurement report (MR) data set for the area to be evaluated; the MR data set includes MR data of one or more user equipment in the area to be evaluated; and acquire a mobile user detail record (XDR) call bill data set generated by the core network when the one or more user equipment dials a Long Term Evolution (VoLTE) voice bearer (VoLTE) service; the XDR call bill data set includes the XDR call bills of the one or more user equipment. The processing module is configured to rasterize the map of the area to be evaluated to obtain a rasterized map of the area to be evaluated; the rasterized map includes a plurality of grids; based on the vector information in the high-precision map of the area to be evaluated, determine the road attribute of each grid; the road attribute includes road or non-road; based on the grid whose road attribute is road and the preset road segmentation length, divide the road in the rasterized map of the area to be evaluated into a plurality of rasterized road segments; based on the preset unconnected rule and call drop rule, determine an abnormal call record from the XDR call record data set; the abnormal call record is an XDR call record generated when the abnormal event occurs in the user equipment; the abnormal event includes VoLTE unconnected and VoLTE call drop; the abnormal call record includes abnormal VoLTE SIP interface call record and abnormal EPC_S1MME interface call record; for the VoLTE unconnected in the abnormal event, determine one or more candidate MR data including unconnected MSISDN from the MR data set; the unconnected MSISDN is the abnormal VoLTE MSISDN in the SIP interface call list; based on the abnormal VoLTE Based on the process start time in the SIP interface call record, one or more candidate MR data are determined, whose starting time is closest to the process start time, as the target MR data; for the VoLTE call drop in the abnormal event, one or more candidate MR data including the dropped call MSISDN are determined from the MR data set; the dropped call MSISDN is the MSISDN in the abnormal EPC_S1MME interface call record; based on the context release completion time in the abnormal EPC_S1MME interface call record, one or more candidate MR data are determined, whose starting time is closest to the context release completion time, as the target MR data; based on the multiple rasterized road sections and the location information in the target MR data, the road section where the abnormal event occurred is determined; based on the abnormal call record and the target MR data, the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred are determined; the road test results of the area to be evaluated include the road section where the abnormal event occurred in the area to be evaluated, and the network performance information and VoLTE status information corresponding to the road section where the abnormal event occurred.

5. An electronic device, characterized in that: The electronic device includes: a processor and a memory; The memory stores instructions executable in the process; When the processor is configured to execute the instructions stored in the memory, the electronic device implements the method according to any one of claims 1 to 3.

6. A readable storage medium, characterized in that: The readable storage medium includes: software instructions; When the software instructions are executed in an electronic device, the electronic device is enabled to implement the method according to any one of claims 1 to 3.

Images