Jamming delimiting method and device

Abstract

The invention discloses a jamming delimiting method and device, and relates to the technical field of networks. The method comprises: obtaining first key feature information of a user datagram protocol (UDP) data stream, the first key feature information comprising at least one of a message quantity feature, a retransmission quantity feature and a transmission control protocol (TCP) message feature, the message quantity feature being used for indicating quantity information of uplink and downlink messages in the UDP data stream, the retransmission quantity characteristic is used for indicating quantity information of retransmission messages in the UDP data stream, and the TCP message characteristic is used for indicating quantity information of messages in a TCP data stream associated with the UDP data stream; and based on the first key feature information of the UDP data stream, determining a jamming position of the UDP data stream, the jamming position comprising at least one of a network side and a user side. Based on the scheme, on one hand, manual package capturing is not needed for jamming judgment, time and labor are saved, the scheme is high in accuracy, and the delimiting accuracy can be guaranteed.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a method and apparatus for determining lag. Background Technology

[0002] User Datagram Protocol (UDP) is a simple network transport protocol. Unlike Transmission Control Protocol (TCP), UDP does not provide reliability guarantees and is more sensitive to changes in network conditions. UDP applications may experience stuttering when there is network congestion, packet loss, delay, or jitter.

[0003] In related technologies, the main approach to UDP stuttering issues relies on on-site packet capture by telecom operators to pinpoint the stuttering based on the captured data. However, this method is time-consuming and labor-intensive, and the accuracy of stuttering identification based on packet capture results cannot be guaranteed. Summary of the Invention

[0004] This application provides a method and apparatus for determining stuttering, which can improve the accuracy of stuttering determination.

[0005] Firstly, this application provides a method for determining stuttering. This stuttering determination method can be executed by a network operation and maintenance system in the network, such as a network cloud engine (NCE) device. The method includes: obtaining first key feature information of a UDP data stream; and determining the stuttering location of the UDP data stream based on this first key feature information. The first key feature information includes at least one of packet quantity features, retransmission quantity features, and TCP packet features. The packet quantity features indicate the number of uplink and downlink packets in the UDP data stream; the retransmission quantity features indicate the number of retransmitted packets in the UDP data stream; and the TCP packet features indicate the number of packets in the TCP data stream associated with the UDP data stream. The stuttering location includes at least one from the network side and the user side.

[0006] In the implementation of this application, the network operation and maintenance system determines the location of UDP data stream stuttering by using packet quantity characteristics, retransmission quantity characteristics, and TCP packet characteristics. The above three characteristics respectively indicate the uplink and downlink packet quantity information of the UDP data stream, the retransmission packet quantity information of the UDP data stream, and the packet quantity information of the TCP data stream associated with the UDP data stream. Any one of the above three characteristics can reflect the location of UDP data stream stuttering well. Therefore, based on the above scheme, on the one hand, there is no need for manual packet capture to determine stuttering, which saves time and effort, and on the other hand, the scheme has high accuracy and can ensure accurate delineation.

[0007] Among them, quantity information refers to information related to quantity. For example, the quantity information of uplink and downlink messages refers to information related to the quantity of context messages.

[0008] Since some UDP applications include both UDP and TCP data streams (e.g., TCP handshakes are performed via TCP data streams), a TCP data stream associated with a UDP data stream refers to a TCP data stream belonging to the same application as the UDP data stream. Related UDP and TCP data streams can have mutually associated identifiers.

[0009] For example, in the case of a UDP application that includes a TCP data stream, the first key characteristic information includes message quantity characteristics, retransmission quantity characteristics, and TCP message characteristics.

[0010] For example, in the case of a UDP application that does not include TCP data streams, the first key characteristic information includes the number of packets and the number of retransmissions.

[0011] In some implementations of this application, the message quantity characteristics include uplink message quantity and downlink message quantity information.

[0012] For example, the message quantity characteristics include changes in the number of uplink messages and downlink messages, or changes in the ratio of the number of uplink messages to the number of downlink messages.

[0013] For example, when a network failure causes a slowdown, uplink packets are sent normally. However, because the network failure reduces the number of downlink packets, the user will retransmit uplink packets, which increases the ratio of uplink packets to downlink packets.

[0014] Optionally, when a network-side failure occurs, the ratio of the number of uplink packets to the number of downlink packets increases by a proportion greater than a ratio threshold, which can be obtained based on data from the network-side failure.

[0015] For example, when a user-side fault causes a slowdown, uplink packets are lost. At this time, the number of downlink packets will also decrease, and the user will retransmit uplink packets, resulting in the ratio of uplink packets to downlink packets remaining unchanged or decreasing.

[0016] In the implementation of this application, increasing or decreasing refers to comparing data from two units of time, or comparing the current unit of time with the average value, etc. The length of the unit of time can be set as needed.

[0017] It can be seen that the message quantity characteristics can reflect the location of the fault causing the lag, and thus can be used for fault localization.

[0018] In some implementations of this application, the retransmission quantity characteristics include packet loss rate and retransmission message quantity information.

[0019] In the implementation of this application, the network operation and maintenance system can acquire UDP packets collected by network nodes and analyze key feature information based on the UDP packets collected by the network nodes. The aforementioned network nodes can be Fiber To The Room (FTTR) devices or other network devices. The following explanation uses FTTR as an example:

[0020] For example, when network-side failures cause buffering, packets sent by user-side devices can reach the FTTR normally, but some cannot be forwarded to network-side devices via the FTTR, resulting in a large number of uplink packet retransmissions. Therefore, analysis of UDP packets collected by the FTTR shows that the packet loss rate is normal, but the number of retransmitted packets exceeds the retransmission threshold.

[0021] For example, when a user-side fault causes a pause, some packets sent by the user-side device may not reach the FTTR normally. However, packets that do reach the FTTR can be forwarded to the network-side device via the FTTR, resulting in only a small number of uplink packet retransmissions. Therefore, analysis of the UDP packets collected by the FTTR shows an increased packet loss rate, but the number of retransmitted packets does not exceed the retransmission threshold.

[0022] The retransmission threshold can be obtained based on data from network-side and user-side failures.

[0023] It can be seen that the retransmission count can reflect the location of the fault causing the stuttering, and thus can be used for fault localization.

[0024] In some implementations of this application, TCP message characteristics include information on the number of times acknowledgment messages and sequence number messages are sent in a TCP session.

[0025] Under normal, fault-free conditions, during a TCP session between the user-side device and the network-side device, acknowledgment (ACK) packets sent by the network-side device arrive at the user-side device in sequence, and the user-side device replies with a corresponding sequence number (SEQ) packet for each acknowledgment packet. That is, the acknowledgment packet and sequence number packet are sent once and once respectively in a TCP session; this refers to a single acknowledgment packet and its corresponding sequence number packet. However, when a network fault occurs, the number of times the acknowledgment packet and sequence number packet are sent changes:

[0026] For example, when network-side failures cause delays, both the acknowledgment packets sent by the network-side device and the sequence number packets sent by the user-side device may be lost during FTTR forwarding, thus triggering retransmission. Therefore, analysis of the TCP packets collected by FTTR shows that the acknowledgment packets and sequence number packets were sent multiple times.

[0027] For example, when a user-side fault causes a pause, the acknowledgment message sent by the network-side device arrives at the FTTR normally. However, the message arriving at the FTTR cannot be forwarded to the user-side device, so the user-side device cannot respond with a sequence number message. Alternatively, the user-side device may receive the acknowledgment message, but the sequence number message it sent did not reach the FTTR, let alone the network-side device. Because the network-side device did not receive the sequence number message, it will retransmit the acknowledgment message. Therefore, analyzing the TCP packets collected at the FTTR, the number of times the acknowledgment message and the sequence number message were sent is multiple times and once, respectively.

[0028] It can be seen that TCP packet characteristics can reflect the location of the fault causing the lag, and thus can be used for fault localization.

[0029] In summary, one or more of the following characteristics can be used to accurately delimit the buffering failure: message quantity characteristics, retransmission quantity characteristics, and TCP message characteristics.

[0030] In the implementation of this application, the first key feature information of the UDP data stream is obtained, including:

[0031] Filter UDP data streams and associated TCP data streams based on application information;

[0032] Parse the UDP data stream to obtain the message quantity and retransmission quantity characteristics from the first key feature information;

[0033] Parse the TCP data stream associated with the UDP data stream to obtain the TCP packet characteristics in the first key feature information.

[0034] In this implementation, the network operation and maintenance system filters data streams based on applications and then parses these data streams to obtain key features. This approach not only ensures the automation of key feature extraction but also makes the identification of lag more targeted because it analyzes data streams at the application level.

[0035] For example, a network operations and maintenance system can receive data streams collected and uploaded by FTTR, and then filter UDP and TCP data streams based on the five-tuple of the UDP application that needs to be fault-delimited. The five-tuple refers to the source Internet protocol (IP) address, destination IP address, source port number, destination port number, and type.

[0036] Optionally, before filtering the data stream, the network operations and maintenance system receives buffering information from user-side devices, such as video application buffering reported by the user-side device. In this case, the network operations and maintenance system sends a command to instruct FTTR to collect and upload the data stream. The network operations and maintenance system then filters the data stream for that video application.

[0037] In the implementation of this application, the UDP data stream is parsed to obtain the message quantity characteristic and retransmission quantity characteristic in the first key characteristic information, including:

[0038] The message quantity and retransmission quantity characteristics are determined based on the IP length and IP identifier of the messages in the UDP data stream.

[0039] In this implementation, since the IP length and IP identification fields in a UDP packet are continuous features that change over time, the number of uplink and downlink packets can be determined based on the IP length and IP identification. Then, the ratio of uplink to downlink packets can be determined based on the total number of packets. Similarly, the packet loss rate and the number of retransmissions can be determined based on the IP length and IP identification, thus yielding the total number of packets.

[0040] In the implementation of this application, the TCP message characteristics only need to be analyzed by analyzing the number of times the same acknowledgment message and sequence number message are sent in the TCP message.

[0041] In the implementation of this application, the network operation and maintenance system can use a model to determine the extent of lag.

[0042] For example, determining the location of a UDP data stream stutter based on the first key feature information of the UDP data stream includes:

[0043] The first key feature information of the UDP data stream is input into the stuttering location definition model, which is used to define the stuttering location based on the first key feature information of the UDP data stream.

[0044] Obtain the stutter location to define the stutter location in the model output.

[0045] In this implementation, using the model for stuttering delimitation ensures high accuracy and efficiency in delimitation.

[0046] Before using the model, the method provided in this application may also include training the model.

[0047] For example, the method may also include:

[0048] Acquire training data, which includes sample data with the stuttering position as the user side label and sample data with the stuttering position as the network side label;

[0049] The model for determining the location of lag was trained using training data.

[0050] In this implementation, labeled sample data is used for model training, enabling the trained model to better distinguish whether the lag is on the user side or the network side.

[0051] Based on the preceding discussion of the differences between network-side and user-side faults causing lag, sample data labeled with the lag location on the user side possesses at least one of the following characteristics:

[0052] The ratio of uplink messages to downlink messages remains unchanged or decreases;

[0053] The packet loss rate increased, but the number of retransmitted packets did not exceed the retransmission threshold.

[0054] In a TCP session, acknowledgment messages and sequence number messages are sent multiple times and once, respectively.

[0055] Sample data that uses the stuttering location as the network side label has at least one of the following characteristics:

[0056] The ratio of uplink messages to downlink messages increased;

[0057] The packet loss rate is normal, but the number of retransmitted packets exceeds the retransmission threshold.

[0058] In a TCP session, acknowledgment messages and sequence number messages are sent multiple times.

[0059] In the implementation of this application, when the network operation and maintenance system reports a lag on the user-side device, it can first determine whether a lag exists. Only when a lag exists will the lag be delineated, thus avoiding the waste of network resources caused by delineating lag when there is no lag. Moreover, this method can make the lag delineation more accurate.

[0060] For example, the method may also include:

[0061] Parse the UDP data stream to obtain the second key feature information of the UDP data stream. The second key feature information includes at least one of the following: latency, number of packets, packet loss rate, packet sending density, and average packet duration.

[0062] The presence of stuttering in the UDP data stream is determined based on the second key feature information of the UDP data stream.

[0063] In this implementation, the second key feature information mentioned above can be used to accurately and quickly determine whether there is a UDP data stream stuttering, thus avoiding unnecessary stuttering delimitation.

[0064] In the implementation of this application, the UDP data stream is parsed to obtain the basic characteristic information of the UDP data stream, including:

[0065] Determine the delay based on request and response messages in the UDP data stream, or determine the delay based on heartbeat messages in the UDP data stream;

[0066] Alternatively, the number of packets and packet loss rate can be determined based on the IP length and IP identifier of the packets in the UDP data stream;

[0067] Alternatively, the message sending density can be determined based on the sending time of messages in the UDP data stream;

[0068] Alternatively, the average message duration per unit time can be determined based on the length of the messages in the UDP data stream.

[0069] It should be noted that there are some identical contents in the first and second key feature information, such as the number of packets and the packet loss rate. Therefore, they can be obtained at once to avoid duplication.

[0070] In this implementation, key features are determined by the attributes of the message itself, making it convenient to implement.

[0071] In the implementation of this application, the network operation and maintenance system can use a model to determine lag.

[0072] For example, determining whether there is a stutter in the UDP data stream based on the second key feature information of the UDP data stream includes:

[0073] The second key feature information of the UDP data stream is input into the stuttering judgment model, which is used to determine whether stuttering exists based on the second key feature information of the UDP data stream.

[0074] Obtain the judgment result output by the stuttering judgment model.

[0075] In this implementation, using a model to determine lag results in high accuracy and efficiency.

[0076] In the implementation of this application, the stuttering location definition model and the stuttering judgment model are two separate models. The training methods for the two models can be similar, both of which are trained using labeled sample data.

[0077] Secondly, this application provides a stuttering delimitation device, which includes:

[0078] The acquisition unit is used to acquire the first key feature information of the User Datagram Protocol (UDP) data stream. The first key feature information includes at least one of the following: message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature. The message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream. The retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream. The TCP message feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream.

[0079] The determining unit is used to determine the location of the UDP data stream stutter based on the first key feature information of the UDP data stream. The stutter location includes at least one of the network side and the user side.

[0080] For example, the acquisition unit is used to filter UDP data streams and TCP data streams associated with UDP data streams based on application information;

[0081] Parse the UDP data stream to obtain the message quantity and retransmission quantity characteristics from the first key feature information;

[0082] Parse the TCP data stream associated with the UDP data stream to obtain the TCP packet characteristics in the first key feature information.

[0083] For example, the message quantity characteristics include information on the number of uplink messages and the number of downlink messages;

[0084] The retransmission quantity characteristics include packet loss rate and the number of retransmitted packets;

[0085] TCP message characteristics include the number of times acknowledgment messages and sequence number messages are sent in a TCP session.

[0086] For example, the acquisition unit is used to determine the message quantity characteristics and retransmission quantity characteristics based on the Internet Protocol IP length and IP identifier of the messages in the UDP data stream.

[0087] For example, the determining unit is used to input the first key feature information of the UDP data stream into the stuttering location definition model, and the stuttering location definition model is used to define the stuttering location based on the first key feature information of the UDP data stream.

[0088] Obtain the stutter location to define the stutter location in the model output.

[0089] Optionally, the device further includes:

[0090] The training unit is used to acquire training data, which includes sample data with the stuttering position as the user side label and sample data with the stuttering position as the network side label.

[0091] The model for determining the location of lag was trained using training data.

[0092] For example, sample data that uses the lag location as the user-side label has at least one of the following characteristics:

[0093] The ratio of uplink messages to downlink messages remains unchanged or decreases;

[0094] The packet loss rate increased, but the number of retransmitted packets did not exceed the retransmission threshold.

[0095] In a TCP session, acknowledgment messages and sequence number messages are sent multiple times and once, respectively.

[0096] Sample data that uses the stuttering location as the network side label has at least one of the following characteristics:

[0097] The ratio of uplink messages to downlink messages increased;

[0098] The packet loss rate is normal, but the number of retransmitted packets exceeds the retransmission threshold.

[0099] In a TCP session, acknowledgment messages and sequence number messages are sent multiple times.

[0100] Optionally, the acquisition unit is also used to parse the UDP data stream to obtain the second key feature information of the UDP data stream. The second key feature information includes at least one of latency, number of packets, packet loss rate, packet transmission density and average packet duration.

[0101] The device also includes:

[0102] The determination unit is used to determine whether there is a stutter in the UDP data stream based on the second key feature information of the UDP data stream.

[0103] For example, the acquisition unit is used to determine the delay based on request and response messages in the UDP data stream, or to determine the delay based on heartbeat messages in the UDP data stream;

[0104] Alternatively, the number of packets and packet loss rate can be determined based on the IP length and IP identifier of the packets in the UDP data stream;

[0105] Alternatively, the message sending density can be determined based on the sending time of messages in the UDP data stream;

[0106] Alternatively, the average message duration per unit time can be determined based on the length of the messages in the UDP data stream.

[0107] For example, the determination unit is used to input the second key feature information of the UDP data stream into the stuttering determination model, and the stuttering determination model is used to determine whether stuttering exists based on the second key feature information of the UDP data stream.

[0108] Obtain the judgment result output by the stuttering judgment model.

[0109] Thirdly, a network operation and maintenance system, such as an NCE device, is provided. The network operation and maintenance system includes a processor and a memory. The memory is used to store software programs and modules. The processor implements the methods described in the first aspect or any possible implementation thereof by running or executing the software programs and / or modules stored in the memory.

[0110] Optionally, the processor may be one or more, and the memory may be one or more.

[0111] Optionally, the memory may be integrated with the processor, or the memory may be separated from the processor.

[0112] In the specific implementation process, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. This application does not limit the type of memory or the way the memory and processor are set.

[0113] Fourthly, a computer program product is provided. The computer program product includes computer program code that, when executed by a device, causes the device to perform the methods described in the first aspect or any possible implementation thereof.

[0114] Fifthly, this application provides a computer-readable storage medium for storing program code executed by a processor, the program code including methods for implementing any of the possible embodiments of the first aspect described above.

[0115] In a sixth aspect, a chip is provided, including a processor, which is configured to retrieve and execute instructions stored in a memory, causing a network operation and maintenance system equipped with the chip to perform the method in any of the possible implementations of the first aspect described above.

[0116] In a seventh aspect, another chip is provided. The other chip includes an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected via internal interconnection paths. The processor is used to execute code in the memory, and when the code is executed, the processor is used to perform the method in any of the possible embodiments of the first aspect described above.

[0117] Eighthly, a transmission system is provided, which includes means as described in the second aspect or any possible implementation thereof. Attached Figure Description

[0118] Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0119] Figure 2 This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0120] Figure 3 This is a flowchart of a stuttering delimitation method provided in an embodiment of this application;

[0121] Figure 4 This is a flowchart of a stuttering delimitation method provided in an embodiment of this application;

[0122] Figure 5 This is a schematic diagram illustrating the changes in the number of uplink and downlink packets during a network-side failure, provided in an embodiment of this application.

[0123] Figure 6 This is a schematic diagram illustrating the changes in the number of uplink and downlink packets during a user-side failure, provided in an embodiment of this application.

[0124] Figure 7 This is a schematic diagram illustrating the changes in uplink packet loss and retransmission during network-side failures provided in this application embodiment;

[0125] Figure 8 This is a schematic diagram illustrating the changes in uplink packet loss and retransmission during user-side failures, as provided in an embodiment of this application.

[0126] Figure 9 This is a flowchart illustrating the interaction between request and response messages provided in an embodiment of this application.

[0127] Figure 10 This is a flowchart of the heartbeat message interaction provided in the embodiments of this application;

[0128] Figure 11 This is a schematic diagram of uplink and downlink message transmission provided in an embodiment of this application;

[0129] Figure 12 This is a schematic diagram illustrating the downlink message length during user-side lag, as provided in an embodiment of this application.

[0130] Figure 13 This is a schematic diagram illustrating the downlink packet length during network-side lag, as provided in an embodiment of this application.

[0131] Figure 14 This is a schematic diagram of a normal TCP session provided in an embodiment of this application when no fault occurs;

[0132] Figure 15 This is a schematic diagram of a TCP session during a network-side failure, provided in an embodiment of this application.

[0133] Figure 16 This is a schematic diagram of a TCP session in the event of a user-side failure, provided in an embodiment of this application.

[0134] Figure 17 This is a block diagram of a stuttering delimitation device provided in an embodiment of this application;

[0135] Figure 18 This is a schematic diagram of the structure of a network operation and maintenance system provided in an embodiment of this application. Detailed Implementation

[0136] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0137] To facilitate understanding of the technical solutions provided in the embodiments of this application, the system structure of this application will be introduced first.

[0138] Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. See also... Figure 1 The system architecture includes user-side device 10, network-side device 20, network device 30 connecting user-side device 10 and network-side device 20, and network operation and maintenance system 40 connected to network device 30.

[0139] In this context, user-side device 10 is the user's internet access terminal, also known as user equipment, such as a personal computer or mobile terminal. Network-side device 20 is the server providing services to the user, such as an application server.

[0140] For example, the user-side device 10 can install UDP applications such as video, online office, and games, while the network-side device 20 can be a server that provides the corresponding services, such as a video server, an online office server, or a game server.

[0141] There can be multiple network devices 30, including access devices (such as routers, switches, FTTRs, etc.) and upper-layer network devices (such as optical line terminals (OLTs)). The network operation and maintenance system 40 can include two parts: servers and storage, such as NCE devices.

[0142] Figure 2 This is a more detailed system architecture diagram provided in an embodiment of this application. See also... Figure 2User-side device 10 connects to FTTR via a wireless network. FTTR connects to network-side device 20 via OLT and broadband remote access server (BRAS). Both FTTR and OLT are connected to NCE device of network operation and maintenance system 40.

[0143] The FTTR is responsible for collecting and uploading data streams to the NCE device. Data transmission between the FTTR and the NCE is carried out through the Message Queuing Telemetry Transport (MQTT) protocol.

[0144] like Figure 2 As shown, the NCE device includes multiple modules, such as data stream filtering, key feature extraction, stuttering detection, and stuttering delimitation. These modules enable stuttering identification and delimitation in user internet browsing scenarios when the user's application uses the UDP protocol, determining whether the stuttering originates before or after the network device. "Before the network device" refers to the connection between the network device and the user-side device, while "after the network device" refers to the connection between the network device and other network-side devices.

[0145] The NCE device can connect to network equipment via the southbound interface, and maintenance personnel can obtain the stuttering identification results output by the NCE device through the maintenance application. Similarly, the NCE device can also directly report the stuttering identification results to the operator, or provide them to program objects (such as ADO objects) via the northbound interface.

[0146] Of course, the above system architecture is only an example and does not constitute a limitation on the solution provided in this application.

[0147] Figure 3 This is a flowchart illustrating a method for lag localization provided in an embodiment of this application. This method can be executed by a network operations and maintenance system, such as an NCE device. Figure 3 As shown, the method includes the following steps.

[0148] S101: Obtain the first key characteristic information of the User Datagram Protocol (UDP) data stream.

[0149] The first key feature information includes at least one of the following: message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature.

[0150] For example, the message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream, the retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream, and the TCP message quantity feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream.

[0151] Among them, quantity information refers to information related to quantity. For example, the quantity information of uplink and downlink messages refers to information related to the quantity of context messages.

[0152] Since some UDP applications include both UDP and TCP data streams (e.g., TCP handshakes are performed via TCP data streams), a TCP data stream associated with a UDP data stream refers to a TCP data stream belonging to the same application as the UDP data stream. Related UDP and TCP data streams can have mutually associated identifiers.

[0153] For example, in the case of a UDP application that includes a TCP data stream, the first key characteristic information includes message quantity characteristics, retransmission quantity characteristics, and TCP message characteristics.

[0154] For example, in the case of a UDP application that does not include TCP data streams, the first key characteristic information includes the number of packets and the number of retransmissions.

[0155] S102: Determine the location of the UDP data stream stutter based on the first key feature information of the UDP data stream.

[0156] The location of the lag includes at least one on the network side and the user side.

[0157] For example, a user-side fault refers to a fault between the user side and the FTTR, while a network-side fault refers to a fault between the network side and the FTTR.

[0158] In the implementation of this application, the network operation and maintenance system determines the location of UDP data stream stuttering by using packet quantity characteristics, retransmission quantity characteristics, and TCP packet characteristics. The above three characteristics respectively indicate the uplink and downlink packet quantity information of the UDP data stream, the retransmission packet quantity information of the UDP data stream, and the packet quantity information of the TCP data stream associated with the UDP data stream. Any one of the above three characteristics can reflect the location of UDP data stream stuttering well. Therefore, based on the above scheme, on the one hand, there is no need for manual packet capture to determine stuttering, which saves time and effort, and on the other hand, the scheme has high accuracy and can ensure accurate delineation.

[0159] Figure 4 This is a flowchart illustrating a method for lag localization provided in an embodiment of this application. This method can be executed by a network operations and maintenance system, such as an NCE device. Figure 4 As shown, the method includes the following steps.

[0160] S201: Receive data stream uploaded by network device.

[0161] For example, a network operations and maintenance system can receive and upload data streams collected by FTTR.

[0162] Before filtering the data stream, the network operation and maintenance system receives the lag information reported by the user-side device. At this time, the network operation and maintenance system sends an instruction to FTTR to collect the data stream and upload it.

[0163] For example, if the NCE receives a report from the user-side device about video application buffering, the NCE notifies the FTTR, triggering the FTTR packet capture function. After the FTTR captures the packet-by-packet messages from the user-side device, it reports the messages to the NCE.

[0164] In addition, the network operation and maintenance system can also proactively determine and delineate the lag status of all applications even without receiving feedback on lag from user-side devices.

[0165] S202: Filter UDP data streams and TCP data streams associated with UDP data streams based on application information.

[0166] The original packets reported by FTTR are binary byte streams. The network operations and maintenance system parses the original packets into readable tabular data, and then filters the data based on this data. The network operations and maintenance system can process the data stream packet by packet.

[0167] Table 1 below shows an example of a raw message reported by FTTR:

[0168] Table 1

[0169]

[0170] For example, the network operation and maintenance system filters UDP data streams and TCP data streams based on the five-tuple of UDP applications that require fault delimitation.

[0171] The network operation and maintenance system identifies the application type corresponding to the reported data stream, classifies and stores it according to the five-tuple, and then obtains key feature information, or key performance indicators (KPIs), through subsequent steps.

[0172] S203: Parse the UDP data stream to obtain the message quantity feature and retransmission quantity feature from the first key feature information, as well as the second key feature information.

[0173] The first key feature information includes at least one of the following: message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature.

[0174] For example, the message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream, the retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream, and the TCP message quantity feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream.

[0175] In some implementations of this application, the message quantity characteristics include uplink message quantity and downlink message quantity information.

[0176] For example, the message quantity characteristics include changes in the number of uplink messages and downlink messages, or changes in the ratio of the number of uplink messages to the number of downlink messages.

[0177] Figure 5 This is a schematic diagram illustrating the changes in the number of uplink and downlink packets during a network-side failure, as provided in an embodiment of this application. See also... Figure 5 The horizontal axis represents time, which can be in milliseconds, and the vertical axis represents the ratio of uplink packets to downlink packets. The boxes represent the areas of lag. It can be seen that when lag occurs due to a network-side fault, the number of downlink packets decreases, causing the user to retransmit uplink packets, thus increasing the ratio of uplink to downlink packets (compared to the area outside the boxes).

[0178] Optionally, when a network-side failure occurs, the ratio of the number of uplink packets to the number of downlink packets increases by a proportion greater than a ratio threshold, which can be obtained based on data from the network-side failure.

[0179] Figure 6 This is a schematic diagram illustrating the changes in the number of uplink and downlink packets during a user-side failure, as provided in an embodiment of this application. See also... Figure 6 The horizontal axis represents time, which can be in milliseconds, and the vertical axis represents the ratio of uplink packets to downlink packets. The boxes represent the areas experiencing lag. It can be seen that when a user-side fault causes lag, uplink packets are lost. At this time, the number of downlink packets also decreases, and the user end will retransmit uplink packets, resulting in the ratio of uplink packets to downlink packets remaining unchanged or decreasing.

[0180] In the implementation of this application, increasing or decreasing refers to comparing data from two units of time, or comparing the current unit of time with the average value, etc. The length of the unit of time can be set as needed.

[0181] It can be seen that the message quantity characteristics can reflect the location of the fault causing the lag, and thus can be used for fault localization.

[0182] In some implementations of this application, the retransmission quantity characteristics include packet loss rate and retransmission message quantity information.

[0183] In the implementation of this application, the network operation and maintenance system can acquire UDP packets collected by network nodes and analyze key feature information based on the UDP packets collected by the network nodes. The aforementioned network nodes can be FTTR devices or other network devices. The following explanation uses FTTR as an example:

[0184] Figure 7 This is a schematic diagram illustrating the changes in uplink packet loss and retransmission during network-side failures, as provided in an embodiment of this application. See also... Figure 7 The x-axis represents time, and the y-axis represents packet loss rate and retransmission rate, with the dashed line representing the threshold. When network-side failures cause congestion, packets sent by user-side devices can reach the FTTR normally, but some cannot be forwarded to network-side devices via the FTTR, resulting in a large number of uplink packet retransmissions. Therefore, analysis of UDP packets collected by the FTTR shows a normal packet loss rate, but the number of retransmitted packets exceeds the retransmission threshold.

[0185] Figure 8 This is a schematic diagram illustrating the changes in uplink packet loss and retransmission during user-side failures, as provided in an embodiment of this application. See also... Figure 8 The x-axis represents time, and the y-axis represents packet loss rate and retransmission rate. The dashed line represents the threshold. When a user-side fault causes a pause, some packets sent by the user-side device cannot reach the FTTR normally. However, packets that do reach the FTTR can be forwarded to the network-side device through the FTTR, resulting in only a small number of uplink packet retransmissions. Therefore, analysis of UDP packets collected by the FTTR shows an increased packet loss rate, but the number of retransmitted packets does not exceed the retransmission threshold.

[0186] The retransmission threshold can be obtained based on data from network-side and user-side failures.

[0187] It can be seen that the retransmission count can reflect the location of the fault causing the stuttering, and thus can be used for fault localization.

[0188] In summary, one or more of the following characteristics can be used to accurately delimit the buffering failure: message quantity characteristics, retransmission quantity characteristics, and TCP message characteristics.

[0189] The second key feature information includes at least one of the following: latency, number of messages, packet loss rate, message transmission density, and average message duration.

[0190] In the implementation of this application, the UDP data stream is parsed to obtain the message quantity characteristic and retransmission quantity characteristic in the first key characteristic information, including:

[0191] The message quantity and retransmission quantity characteristics are determined based on the IP length and IP identifier of the messages in the UDP data stream.

[0192] In this implementation, since the IP length and IP identification fields in the UDP packet are continuous features that change over time, the number of uplink and downlink packets can be determined based on the IP length and IP identification. Then, the change in the ratio of uplink to downlink packets can be determined based on the number. Similarly, the packet loss rate and the number of retransmissions can be determined based on the IP length and IP identification, thus obtaining the packet quantity characteristics and retransmission quantity characteristics.

[0193] In the implementation of this application, the UDP data stream is parsed to obtain the basic characteristic information of the UDP data stream, including:

[0194] Determine the delay based on request and response messages in the UDP data stream, or determine the delay based on heartbeat messages in the UDP data stream.

[0195] Figure 9 This is a flowchart illustrating the interaction between request and response messages provided in an embodiment of this application. See also... Figure 9 When a user-side device sends a request message and a network-side device sends a response message, the time interval between the two is the network-side round-trip time; when a network-side device sends a request message and a user-side device sends a response message, the time interval between the two is the user-side round-trip time.

[0196] Network operation and maintenance systems divide packet flows into uplink and downlink packet flows according to direction. For UDP applications, there is information in the packets that can clearly represent the association between request and response packets, such as the Info information in the packet header. Round-trip latency is then calculated based on the occurrence time of the associated packets. During periods of lag, the round-trip latency increases.

[0197] Table 2 below shows an example of request and response messages. Referring to Table 2, if two messages have the same 5-tuple, their Info information includes "Request" and their Info information includes "Response," indicating a correspondence. In this case, the corresponding request and response messages are confirmed, and the latency can be determined based on the message generation time. STUN is a message type that encapsulates UDP messages.

[0198] Table 2

[0199] time Source IP address Destination IP address type length Info 4:36:07:01 157.*.*.54 192.168.100.20 STUN 178 Binding Request user: EDGERA 4:36:07:31 192.168.100.20 157.*.*.54 STUN 110 Binding Success Response

[0200] Figure 10 This is a flowchart illustrating the heartbeat message interaction process provided in an embodiment of this application. See also... Figure 10 The user-side device sends a heartbeat request, and the network-side device sends a heartbeat response. The time interval between the two is the round-trip delay.

[0201] The network operation and maintenance system divides the packet flow into uplink and downlink packet flows according to the direction, identifies the heartbeat packets in the uplink and downlink packets, and calculates the round-trip delay.

[0202] Table 3 below shows an example of a heartbeat message. Referring to Table 3, a message is sent from one end to the other, and two response messages are returned from the other end. The length and interaction period exhibit a regularity, which can be considered a heartbeat message exchange. In this case, the delay can be determined based on the message generation time. The round-trip delay can be calculated by measuring the time interval between the uplink heartbeat message and the second downlink heartbeat message.

[0203] Table 3

[0204] Source IP address Destination IP address type length Source port number Destination port number 192.168.100.20 109.*.*.54 UDP 572 55372 8019 109.*.*.54 192.168.100.20 UDP 102 8019 55372 109.*.*.54 192.168.100.20 UDP 505 8019 55372 192.168.100.20 109.*.*.54 UDP 572 55372 8019 109.*.*.54 192.168.100.20 UDP 102 8019 55372 109.*.*.54 192.168.100.20 UDP 505 8019 55372

[0205] In the implementation of this application, the UDP data stream is parsed to obtain the basic characteristic information of the UDP data stream, including:

[0206] The number of packets and packet loss rate are determined based on the IP length and IP identifier of packets in the UDP data stream.

[0207] Figure 11 This is a schematic diagram of uplink and downlink message transmission provided in an embodiment of this application. See also... Figure 11 The number in the sequence number is a simplified IP identifier; the actual sequence number occupies more bytes. User-side devices send uplink packets, and network-side devices send downlink packets. Packet loss (indicated by dashed lines) and retransmissions (with the same sequence number) are possible for both uplink and downlink packets. During periods of lag, the packet loss rate and the number of retransmissions increase.

[0208] The following example uses IP identifiers to illustrate how to determine packet loss rate and retransmission count. The method for determining based on IP length is similar and will not be elaborated here.

[0209] Table 4 below shows an example of uplink and downlink packets. Referring to Table 4, IP identifiers are continuous. The packet loss rate can be determined by identifying the lost IP identifiers, and the number of retransmissions can be determined based on the repeated IP identifiers.

[0210]

[0211] Source port number Destination port number IP Identifier 8015 53079 0xc9c4(51652) 8015 53079 0xc9c5(51653) 8015 53079 0xc9c7(51655) 8015 53079 0xc9c8(51656) 8015 53079 0xc9c8(51656)

[0212] In the implementation of this application, the UDP data stream is parsed to obtain the basic characteristic information of the UDP data stream, including:

[0213] The message sending density is determined based on the message sending time in the UDP data stream.

[0214] Table 5 below provides an example of uplink and downlink messages. Referring to Table 5, the message time difference between the previous and current messages can be calculated based on the message occurrence time. Furthermore, the data block time interval (e.g., the difference in the occurrence time of the last message of two consecutive data blocks) can be calculated based on the data blocks described in different messages. The time interval is determined based on either the message dimension or the data block dimension, and the overall time interval (e.g., average) per unit time is used to indicate the message transmission density. In Table 5, the occurrence times of each message are the same in hours, minutes, and seconds, differing only in milliseconds; therefore, the times in the table below only show milliseconds.

[0215] Table 5

[0216]

[0217]

[0218] In the implementation of this application, the UDP data stream is parsed to obtain the basic characteristic information of the UDP data stream, including:

[0219] The average message duration per unit time is determined based on the length of the messages in the UDP data stream.

[0220] The average message duration per unit time here can be the average downlink message duration per unit time in seconds.

[0221] During periods of lag, packet loss occurs in both uplink and downlink messages. Downlink messages carry retransmission information, leading to increased message length. The average downlink message duration per second is also the average length of a downlink message per second.

[0222] Figure 12 This is a schematic diagram of the downlink message length during user-side lag provided in an embodiment of this application. Figure 13 This is a schematic diagram illustrating the downlink packet length during network-side lag, as provided in an embodiment of this application. See also... Figure 12 and Figure 13 The horizontal axis represents time, which can be in milliseconds, and the vertical axis represents length, which can be in bits. The boxes represent the stuttering areas, showing that regardless of the type of stuttering, it will increase the average length of the downlink packets.

[0223] It should be noted that there are some identical contents in the first and second key feature information, such as the number of packets and the packet loss rate. Therefore, they can be obtained at once to avoid duplication.

[0224] S204: Parse the TCP data stream associated with the UDP data stream to obtain the TCP packet characteristics in the first key feature information.

[0225] In the implementation of this application, the TCP message characteristics only need to be analyzed by analyzing the number of times the same acknowledgment message and sequence number message are sent in the TCP message.

[0226] In some implementations of this application, TCP message characteristics include information on the number of times acknowledgment messages and sequence number messages are sent in a TCP session.

[0227] Figure 14 This is a schematic diagram of a normal TCP session provided in an embodiment of this application, assuming no faults occur. For example... Figure 14 As shown, under normal, fault-free conditions, during a TCP session between the user-side device and the network-side device, the acknowledgment (ACK) packets sent by the network-side device arrive at the user-side device in sequence, such as ACK1 and ACK2 in the diagram. The user-side device also replies with a corresponding sequence number (SEQ) packet for each acknowledgment packet, such as SEQ1 and SEQ2 in the diagram. That is, the acknowledgment packet and the sequence number packet are sent once and once respectively in a TCP session; this refers to a single acknowledgment packet and its corresponding sequence number packet. However, when a network fault occurs, the number of times the acknowledgment packet and the sequence number packet are sent will change:

[0228] Figure 15 This is a schematic diagram of a TCP session during a network-side failure, as provided in an embodiment of this application. When a network-side failure causes a pause, both the acknowledgment packets sent by the network-side device and the sequence number packets sent by the user-side device may be lost during FTTR forwarding, thus triggering retransmission. Figure 15 As shown, SEQ1 was lost between FTTR and the network-side device. Therefore, FTTR detected that ACK1 was retransmitted multiple times. At the same time, SEQ1 was also sent multiple times. So, by analyzing the TCP packets collected by FTTR, the number of times the acknowledgment packet and the sequence number packet were sent were multiple times and multiple times, respectively.

[0229] Figure 16 This is a schematic diagram of a TCP session during a user-side failure, as provided in an embodiment of this application. When a user-side failure causes a pause, the acknowledgment packet sent by the network-side device arrives normally at the FTTR, but the packet arriving at the FTTR cannot be forwarded to the user-side device. Therefore, the user-side device cannot respond with a sequence number packet. Alternatively, the user-side device receives the acknowledgment packet, but the sequence number packet it sent did not reach the FTTR, let alone the network-side device. Since the network-side device did not receive the sequence number packet, it will retransmit the acknowledgment packet. Figure 16 As shown, both ACK1 and SEQ1 were lost between FTTR and the user-side device. Therefore, FTTR detected that ACK1 was retransmitted multiple times, while SEQ1 was only transmitted once. Thus, analysis of the TCP packets collected by FTTR showed that the acknowledgment packet and the sequence number packet were sent multiple times and once, respectively.

[0230] It can be seen that TCP packet characteristics can reflect the location of the fault causing the lag, and thus can be used for fault localization.

[0231] S205: Determine whether there is a stutter in the UDP data stream based on the second key feature information of the UDP data stream.

[0232] In the implementation of this application, the network operation and maintenance system can use a model to determine lag.

[0233] For example, determining whether there is a stutter in the UDP data stream based on the second key feature information of the UDP data stream includes:

[0234] The second key feature information of the UDP data stream is input into the stuttering judgment model, which is used to determine whether stuttering exists based on the second key feature information of the UDP data stream.

[0235] Obtain the judgment result output by the stuttering judgment model.

[0236] In this implementation, using a model to determine lag results in high accuracy and efficiency.

[0237] Before using the model, the method provided in this application may also include training the model.

[0238] For example, the method may also include:

[0239] Acquire training data, which includes sample data labeled with stuttering and sample data labeled with no stuttering;

[0240] The training data was used to train the stuttering detection model.

[0241] Here, sample data refers to the second key feature information, that is, the second key feature information when there is lag and the second key feature information when there is no lag are used as training data for model training.

[0242] In this implementation, labeled sample data is used for model training, enabling the trained model to better distinguish whether the lag is on the user side or the network side.

[0243] S206: Determine the location of the UDP data stream stutter based on the first key feature information of the UDP data stream.

[0244] The location of the lag includes at least one on the network side and the user side.

[0245] In the implementation of this application, the network operation and maintenance system can use a model to determine the extent of lag.

[0246] For example, determining the location of a UDP data stream stutter based on the first key feature information of the UDP data stream includes:

[0247] The first key feature information of the UDP data stream is input into the stuttering location definition model, which is used to define the stuttering location based on the first key feature information of the UDP data stream.

[0248] Obtain the stutter location to define the stutter location in the model output.

[0249] In this implementation, using the model for stuttering delimitation ensures high accuracy and efficiency in delimitation.

[0250] Before using the model, the method provided in this application may also include training the model.

[0251] For example, the method may also include:

[0252] Acquire training data, which includes sample data with the stuttering position as the user side label and sample data with the stuttering position as the network side label;

[0253] The model for determining the location of lag was trained using training data.

[0254] Among them, sample data refers to the first key feature information, that is, the first key feature information with the stuttering position on the user side and the first key feature information with the stuttering position on the network side are used as training data for model training.

[0255] In this implementation, labeled sample data is used for model training, enabling the trained model to better distinguish whether the lag is on the user side or the network side.

[0256] In the implementation of this application, the stuttering location definition model and the stuttering judgment model are two separate models. The training methods for the two models can be similar, both of which are trained using labeled sample data.

[0257] In this embodiment, both the stuttering location definition model and the stuttering judgment model can be classifier models, such as the XGBoost algorithm. XGBoost is a type of gradient boosting tree algorithm. Gradient boosting is a guided learning algorithm that attempts to combine the estimates of a set of simpler, weaker models to accurately predict the target variable. When gradient boosting is used for regression, the weak learners are regression trees, each mapping input data points to a leaf containing continuous scores.

[0258] In addition, the classification and recognition algorithms of the classifier can also be Bayesian network-based classification methods, random forest-based classification methods, support vector machine (SVM)-based classification methods, etc.

[0259] Optionally, after the lag is delimited, the method may also include analyzing the cause of the lag, such as using existing methods to determine the cause of the lag and outputting the results to the operations and maintenance personnel. This will not be elaborated further.

[0260] The solution provided in this application addresses the problems of difficulty in collecting key features of UDP applications, limited available information, and difficulty in identifying lag. It extracts key features and other data from the original packets to construct a UDP application lag judgment and delimitation scheme, reducing the complexity of manual delimitation and achieving rapid lag delimitation.

[0261] Figure 17 This is a block diagram of a stuttering identification device provided in an embodiment of this application. The stuttering identification device can be implemented as all or part of a network operation and maintenance system through software, hardware, or a combination of both. The stuttering identification device may include: an acquisition unit 301 and a determination unit 302.

[0262] The acquisition unit 301 is used to acquire the first key feature information of the User Datagram Protocol (UDP) data stream. The first key feature information includes at least one of the following: message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature. The message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream. The retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream. The TCP message feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream.

[0263] The determining unit 302 is used to determine the stuttering location of the UDP data stream based on the first key feature information of the UDP data stream. The stuttering location includes at least one of the network side and the user side.

[0264] For example, the acquisition unit 301 is used to filter UDP data streams and TCP data streams associated with UDP data streams based on application information;

[0265] Parse the UDP data stream to obtain the message quantity and retransmission quantity characteristics from the first key feature information;

[0266] Parse the TCP data stream associated with the UDP data stream to obtain the TCP packet characteristics in the first key feature information.

[0267] For example, the message quantity characteristics include information on the number of uplink messages and the number of downlink messages;

[0268] The retransmission quantity characteristics include packet loss rate and the number of retransmitted packets;

[0269] TCP message characteristics include the number of times acknowledgment messages and sequence number messages are sent in a TCP session.

[0270] For example, the acquisition unit 301 is used to determine the message quantity characteristics and retransmission quantity characteristics based on the Internet Protocol IP length and IP identifier of the messages in the UDP data stream.

[0271] For example, the determining unit 302 is used to input the first key feature information of the UDP data stream into the stuttering location definition model, and the stuttering location definition model is used to define the stuttering location based on the first key feature information of the UDP data stream.

[0272] Obtain the stutter location to define the stutter location in the model output.

[0273] Optionally, the device further includes:

[0274] Training unit 303 is used to acquire training data, which includes sample data with the stutter position as the user side label and sample data with the stutter position as the network side label.

[0275] The model for determining the location of lag was trained using training data.

[0276] For example, sample data that uses the lag location as the user-side label has at least one of the following characteristics:

[0277] The ratio of uplink messages to downlink messages remains unchanged or decreases;

[0278] The packet loss rate increased, but the number of retransmitted packets did not exceed the retransmission threshold.

[0279] In a TCP session, acknowledgment messages and sequence number messages are sent multiple times and once, respectively.

[0280] Sample data that uses the stuttering location as the network side label has at least one of the following characteristics:

[0281] The ratio of uplink messages to downlink messages increased;

[0282] The packet loss rate is normal, but the number of retransmitted packets exceeds the retransmission threshold.

[0283] In a TCP session, acknowledgment messages and sequence number messages are sent multiple times.

[0284] Optionally, the acquisition unit 301 is also used to parse the UDP data stream to obtain the second key feature information of the UDP data stream. The second key feature information includes at least one of latency, number of packets, packet loss rate, packet transmission density and average packet duration.

[0285] The device also includes:

[0286] The determination unit 304 is used to determine whether there is a lag in the UDP data stream based on the second key feature information of the UDP data stream.

[0287] For example, the acquisition unit 304 is used to determine the delay based on the request and response messages in the UDP data stream, or to determine the delay based on the heartbeat messages in the UDP data stream;

[0288] Alternatively, the number of packets and packet loss rate can be determined based on the IP length and IP identifier of the packets in the UDP data stream;

[0289] Alternatively, the message sending density can be determined based on the sending time of messages in the UDP data stream;

[0290] Alternatively, the average message duration per unit time can be determined based on the length of the messages in the UDP data stream.

[0291] For example, the determination unit 304 is used to input the second key feature information of the UDP data stream into the stuttering judgment model, and the stuttering judgment model is used to determine whether stuttering exists based on the second key feature information of the UDP data stream.

[0292] Obtain the judgment result output by the stuttering judgment model.

[0293] It should be noted that the lag delimitation device provided in the above embodiments is only illustrated by the division of the above functional units when performing lag delimitation. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the device can be divided into different functional units to complete all or part of the functions described above. In addition, the lag delimitation device and the lag delimitation method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0294] This application also provides a transmission system. The transmission system includes, for example: Figure 17 The lag localization device shown can be implemented as a whole or part of a network operation and maintenance system through software, hardware, or a combination of both.

[0295] Figure 18 A schematic diagram of the structure of the network operation and maintenance system 150 provided in an embodiment of this application is shown. Figure 18 The network operation and maintenance system 150 shown is used to perform the above. Figure 3 or Figure 4 The illustrated stuttering delimitation method involves the following operations. The network operations and maintenance system 150 can be an NCE device. The network operations and maintenance system 150 can be implemented using a general bus architecture.

[0296] like Figure 18 As shown, the network operation and maintenance system 150 includes at least one processor 151, a memory 153, and at least one communication interface 154.

[0297] Processor 151 may be, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the embodiments of this application. For example, processor 151 may include an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A PLD may be, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof. It can implement or execute the various logic blocks, modules, and circuits described in connection with the embodiments of this application. A processor may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0298] Optionally, the network operation and maintenance system 150 also includes a bus. The bus is used to transmit information between the various components of the network operation and maintenance system 150. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 18 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0299] Memory 153 may be, for example, read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 153 may exist independently and be connected to processor 151 via a bus. Memory 153 may also be integrated with processor 151.

[0300] Communication interface 154 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), or Wireless Local Area Network (WLAN). Communication interface 154 can include wired and wireless communication interfaces. Specifically, communication interface 154 can be an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a WLAN interface, a cellular network communication interface, or a combination thereof. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. In this embodiment, communication interface 154 can be used by the network operation and maintenance system 150 to communicate with other devices.

[0301] In a specific implementation, as one example, processor 151 may include one or more CPUs, such as Figure 18 The CPU0 and CPU1 shown are examples of processors. Each of these processors can be a single-core processor or a multi-core processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0302] In a specific implementation, as one example, the network operation and maintenance system 150 may include multiple processors, such as... Figure 18 The processors 151 and 155 shown are illustrated. Each of these processors can be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0303] In a specific implementation, as one example, the network operation and maintenance system 150 may further include output devices and input devices. The output devices communicate with the processor 151 and can display information in various ways. For example, the output devices may be liquid crystal displays (LCDs), light-emitting diode (LED) displays, cathode ray tube (CRT) displays, or projectors. The input devices communicate with the processor 151 and can receive user input in various ways. For example, the input devices may be mice, keyboards, touchscreen devices, or sensing devices.

[0304] In some embodiments, memory 153 is used to store program code 1510 for executing the solution of this application, and processor 151 can execute the program code 1510 stored in memory 153. That is, network operation and maintenance system 150 can implement the stuttering delimitation method provided in the method embodiment by executing program code 1510 in memory 153 through processor 151. Program code 1510 may include one or more software modules. Optionally, processor 151 itself may also store program code or instructions for executing the solution of this application.

[0305] In a specific embodiment, the network operation and maintenance system 150 of this application embodiment can correspond to the controller in the above-described method embodiments. The processor 151 in the network operation and maintenance system 150 reads the instructions in the memory 153, causing... Figure 18 The network operation and maintenance system 150 shown can perform all or part of the operations performed by the controller.

[0306] Specifically, processor 151 is used to acquire first key feature information of the User Datagram Protocol (UDP) data stream. The first key feature information includes at least one of message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature. The message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream. The retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream. The TCP message feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream. Based on the first key feature information of the UDP data stream, the processor 151 determines the UDP data stream stuttering location. The stuttering location includes at least one of the network side and the user side.

[0307] Other alternative implementation methods will not be described in detail here for the sake of brevity.

[0308] in, Figure 3 or Figure 4 Each step of the stuttering delimitation method shown is completed through integrated logic circuits in the hardware or instructions in the software form of the processor of the network operation and maintenance system 150. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by the hardware processor, or as a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. Since this storage medium is located in memory, the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method; to avoid repetition, these will not be described in detail here.

[0309] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected via internal interconnection paths. The processor is used to execute code in the memory, and when the code is executed, the processor is used to execute any of the above-described stuttering delimitation methods.

[0310] It should be understood that the aforementioned processor can be a CPU, or it can be other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the ARM architecture.

[0311] Further, in an optional embodiment, the processor and the memory may be one or more. Optionally, the memory may be integrated with the processor, or the memory may be separately configured from the processor. The memory may include read-only memory and random access memory, and provide instructions and data to the processor. The memory may also include non-volatile random access memory. For example, the memory may also store reference blocks and target blocks.

[0312] The memory can be volatile or non-volatile, or may include both. Non-volatile memory can be ROM, PROM, EPROM, EEPROM, or flash memory. Volatile memory can be RAM, used as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM, and DR RAM.

[0313] In this embodiment of the application, a computer-readable storage medium is also provided, which stores computer instructions. When the computer instructions stored in the computer-readable storage medium are executed by the network operation and maintenance system, the network operation and maintenance system executes the above-mentioned lag delimitation method.

[0314] In this embodiment of the application, a computer program product containing instructions is also provided, which, when run on a network operation and maintenance system, causes the network operation and maintenance system to execute the aforementioned lag delimitation method.

[0315] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0316] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0317] The above description is merely an optional embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0318] Unless otherwise defined, the technical or scientific terms used herein shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains. The terms “first,” “second,” “third,” and similar terms used in this patent application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an” or “a” and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms “comprising” or “including” and similar terms mean that the elements or objects preceding “comprising” or “including” encompass the elements or objects listed following “comprising” or “including” and their equivalents, and do not exclude other elements or objects.

[0319] The above is merely one embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining stuttering limits, characterized in that, The stuttering delimitation method includes: Obtain first key feature information of the User Datagram Protocol (UDP) data stream. The first key feature information includes at least one of message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature. The message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream. The retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream. The TCP message feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream. Based on the first key feature information of the UDP data stream, the location of the UDP data stream lag is determined, and the lag location includes at least one of the network side and the user side.

2. The method according to claim 1, characterized in that, The acquisition of the first key feature information of the UDP data stream includes: The UDP data stream and the TCP data stream associated with the UDP data stream are filtered based on application information; Parse the UDP data stream to obtain the message quantity feature and retransmission quantity feature from the first key feature information; Parse the TCP data stream associated with the UDP data stream to obtain the TCP packet features in the first key feature information.

3. The method according to claim 2, characterized in that, The message quantity characteristics include information on the number of uplink messages and the number of downlink messages; The retransmission quantity characteristics include packet loss rate and retransmission message quantity information; The TCP message characteristics include information on the number of times acknowledgment messages and sequence number messages are sent in a TCP session.

4. The method according to claim 3, characterized in that, The process of parsing the UDP data stream to obtain the message quantity feature and retransmission quantity feature from the first key feature information includes: The message quantity characteristics and the retransmission quantity characteristics are determined based on the Internet Protocol IP length and IP identifier of the messages in the UDP data stream.

5. The method according to any one of claims 1 to 4, characterized in that, The determination of the UDP data stream's stuttering location based on the first key feature information of the UDP data stream includes: The first key feature information of the UDP data stream is input into the stuttering location definition model, which is used to define the stuttering location based on the first key feature information of the UDP data stream. Obtain the stuttering location output by the stuttering location definition model.

6. The method according to claim 5, characterized in that, The method further includes: Acquire training data, which includes sample data with the stuttering position as the user side label and sample data with the stuttering position as the network side label; The training data is used to train the stuttering location definition model.

7. The method according to claim 6, characterized in that, The sample data that uses the lag location as the user-side label has at least one of the following characteristics: The ratio of uplink messages to downlink messages remains unchanged or decreases; The packet loss rate increased, but the number of retransmitted packets did not exceed the retransmission threshold. In a TCP session, acknowledgment messages and sequence number messages are sent multiple times and once, respectively. The sample data that uses the stuttering position as the network side label has at least one of the following characteristics: The ratio of uplink messages to downlink messages increased; The packet loss rate is normal, but the number of retransmitted packets exceeds the retransmission threshold. In a TCP session, acknowledgment messages and sequence number messages are sent multiple times.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Parse the UDP data stream to obtain the second key feature information of the UDP data stream. The second key feature information includes at least one of latency, number of packets, packet loss rate, packet transmission density, and average packet duration. The presence of a stutter in the UDP data stream is determined based on the second key feature information of the UDP data stream.

9. The method according to claim 8, characterized in that, The process of parsing the UDP data stream to obtain its basic characteristic information includes: The delay is determined based on the request and response messages in the UDP data stream, or based on the heartbeat messages in the UDP data stream; Alternatively, the number of packets and the packet loss rate can be determined based on the IP length and IP identifier of the packets in the UDP data stream; Alternatively, the packet transmission density can be determined based on the transmission time of the packets in the UDP data stream; Alternatively, the average message duration per unit time can be determined based on the length of the messages in the UDP data stream.

10. The method according to claim 9, characterized in that, The determination of whether there is a stutter in the UDP data stream based on the second key feature information of the UDP data stream includes: The second key feature information of the UDP data stream is input into the stuttering judgment model, which is used to determine whether stuttering exists based on the second key feature information of the UDP data stream. Obtain the judgment result output by the stuttering judgment model.

11. A stuttering delimitation device, characterized in that, The device includes: The acquisition unit is used to acquire first key feature information of the User Datagram Protocol (UDP) data stream. The first key feature information includes at least one of message quantity feature, retransmission quantity feature, and Transmission Control Protocol (TCP) message feature. The message quantity feature is used to indicate the number of uplink and downlink messages in the UDP data stream. The retransmission quantity feature is used to indicate the number of retransmitted messages in the UDP data stream. The TCP message feature is used to indicate the number of messages in the TCP data stream associated with the UDP data stream. The determining unit is used to determine the stuttering location of the UDP data stream based on the first key feature information of the UDP data stream, wherein the stuttering location includes at least one of the network side and the user side.

12. A network operation and maintenance system, characterized in that, The system includes a memory and one or more processors, the memory being used to store a computer program; the one or more processors being used to execute the computer program in the memory, causing the network operation and maintenance system to perform the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code executed by a processor, the program code including instructions for implementing the method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, Includes program code that, when the device runs the computer program product, causes the device to perform the method as described in any one of claims 1 to 10.

Images