Performance measurement in packet switched communication networks

Abstract

Methods and systems are disclosed for providing performance measurements in a packet-switched communication network, in which a performance measurement application run by a user communication device monitors performance of a packet flow exchanged by a user application run by the user communication device with the packet-switched communication network. Such monitoring includes providing values of performance parameters related to the packet flow. If a fault condition affecting the packet flow is detected based on the values of the performance parameters provided by the performance measurement application, further monitoring of the performance of the packet flow is activated by one or more measurement points located within the packet-switched communication network on a path of the packet flow. Such further monitoring includes providing values of further performance parameters related to the packet flow.

Description

Technical Field

[0001] This invention relates to the field of communication networks. In particular, this invention relates to methods and systems for performing performance measurements in packet-switched communication networks. Background Technology

[0002] In packet-switched communication networks, packet streams are transmitted from the source node to the destination node through possible intermediate nodes. Exemplary packet-switched networks are IP (Internet Protocol) networks, Ethernet, and MPLS (Multiprotocol Label Switching) networks. IP networks can support QUIC (Fast UDP Internet Connection), a transport layer (Layer 4) network protocol designed to support multiplexed connections between two endpoints (client and server) via User Datagram Protocol (UDP).

[0003] The performance of packet-switched communication networks is typically measured in terms of packet loss and / or delay and / or jitter. These measurements can be one-way or round-trip.

[0004] Measurement techniques are known to operate directly on packet streams carrying user data without transmitting any artificial packets (such as ping packets) specifically for measurement purposes. These techniques typically specify the packets of the packet stream to be measured and specify the deployment of one or more measurement points along the path of the marked packets. Each measurement point provides one or more performance parameters (typically counters and / or timestamps) associated with the marked packets, which are then used to determine the performance of that packet stream. Some of these techniques require a single measurement point along the path of the marked packets, capable of autonomously determining performance measurements (e.g., packet loss measurements or latency measurements) based on its own performance parameters(s) (i.e., without using performance parameters(s) provided by other measurement points).

[0005] B. Trammel et al., Internet draft “The addition of a Spin Bit to the QUICTransport Protocol draft-trammel-quic-spin-01”, December 13, 2017, describes the addition of a so-called “delay spin bit” (or simply “spin bit”) to the QUIC header, which enables the measurement of RTT (round-trip time) between the client and server of the QUIC connection via a measurement point located on the connection.

[0006] M. Cociglio et al.: Internet draft “New Spin bit enabled measurements with one or two bits draft-cfb-ippm-spinbit-new-measurements-01”, July 1, 2019, describes the addition of a so-called missing bit in the QUIC header, which enables round-trip packet loss measurements between the client and server of a QUIC connection via measurement points located on the connection.

[0007] A. Ferrieux et al., Internet draft “Packet Loss Signaling for Encrypted Protocols draft-ferrieuxhamchaoui-quic-lossbits-03”, January 16, 2020, describes an extension of the QUIC protocol that introduces two bits into the packet header: the Q bit (sQuared signal bit) and the L bit (loss event bit). These bits enable different types of unidirectional packet loss measurements (including end-to-end, upstream, and downstream measurements) to be performed via measurement points located on the connection. Summary of the Invention

[0008] The applicant has noted that providing performance measurements that indicate the actual overall performance of a packet-switched network and simultaneously provide results with the desired granularity (e.g., through any of the aforementioned known techniques) requires individual monitoring of the performance of all packet flows transmitted through the network, or at least a significant portion thereof. Since nodes in a communication network are typically traversed by several packet flows (typically from thousands of packet flows at DSLAMs and eNodeBs to millions of packet flows at backbone nodes, peer nodes, and WAN gateways), the measurement points implemented at network nodes must be configured to detect several packet flows and provide performance measurements associated with each packet. This would require a significant amount of computation at the measurement points.

[0009] In view of the above, the applicant has recognized the need to provide a method and system for performing performance measurements in packet-switched communication networks that overcomes or mitigates the aforementioned disadvantages.

[0010] In particular, the applicant has solved the problem of providing methods and systems for performing performance measurements in packet-switched communication networks, which allows for a reduction in the amount of computation required at one or more measurement points deployed within the network.

[0011] According to embodiments of the present invention, this problem is solved by providing a computer program product (also referred to as a "performance measurement application" in the following description) suitable for installation on user communication devices (such as smartphones, PCs, tablets, IoT devices, etc.). The user communication device has at least one user application (e.g., a browser, video conferencing app, social networking app, e-commerce app, e-banking app, etc.) configured to exchange at least one packet stream (typically a bidirectional packet stream) with a packet-switched communication network. When the performance measurement application is run by the user communication device, it monitors the performance of the bidirectional packet stream exchanged between the user application running on the user communication device and the communication network by providing a value of at least one performance parameter associated with it (e.g., packet loss value, latency value, etc.). If a fault condition affecting the packet stream is detected based on the performance parameter value provided by the performance measurement application, further monitoring of the packet stream is also activated at least one measurement point located along its path, such that at least one measurement point provides a value of at least one further performance parameter associated with the packet stream (e.g., packet loss value, latency value, etc.).

[0012] The system and method according to the invention then advantageously allow for a reduction in the amount of computation required to deploy one or more measurement points in a network.

[0013] In practice, under normal conditions (i.e., no fault conditions), only performance measurement applications monitor the performance of packet flows, thus acting as measurement points capable of monitoring the packet flows exchanged between user communication equipment and the packet-switched communication network and detecting any fault conditions that may affect the packet flows. Under normal conditions, the measurement points remain inactive and are only activated when a fault condition is detected.

[0014] Therefore, even if measurement points are deployed at network nodes traversed by hundreds or even millions of packet flows (e.g., gateways to a WAN), they are only used to monitor the performance of specific packet flows (i.e., those that have detected fault conditions based on performance parameter values ​​provided by performance measurement applications running on user communication devices connected to the network). This makes the computational resources required by the measurement points far less than continuously monitoring the performance of all packet flows traversing the measurement points.

[0015] Since the measurement point is located on the path of the grouped flow, the further performance parameter values ​​provided by the measurement point can provide an indication of, for example, the path length affected by fault conditions detected based on performance parameter values ​​provided by the performance measurement application.

[0016] For example, a performance measurement application can provide round-trip packet loss values ​​between itself and network nodes on the path that terminates the bidirectional packet flow at the other end, for example, according to the techniques disclosed in the aforementioned Internet draft by M. Cociglio et al. As long as no fault condition is detected (e.g., the round-trip packet loss value does not exceed a predefined maximum threshold), the packet flow will continue to be monitored solely by the performance measurement application.

[0017] If a fault condition is detected at a point based on round-trip packet loss values ​​provided by a performance measurement application (e.g., one or more consecutive round-trip packet loss values ​​exceed a predefined maximum threshold), a measurement point located on the path of the packet flow is activated to initiate further monitoring of the packet flow by providing, for example, round-trip packet loss values ​​between itself and a network node on the path terminating the bidirectional packet flow at the peer end of the user communication device. These further round-trip packet loss values ​​advantageously provide an indication of whether the fault condition detected by the performance measurement application occurs in the path length between the user communication device and the measurement point or in the path length between the measurement point and the network node terminating the bidirectional packet flow at the peer end.

[0018] According to a first aspect, the present invention provides a method for providing performance measurement of a packet-switched communication network, the method comprising:

[0019] a) Monitor the performance of at least one packet stream exchanged between a user application running on a user communication device and a packet switching network by a performance measurement application running on the user communication device, the monitoring including providing a value for at least one performance parameter associated with the at least one packet stream;

[0020] b) Based on the value of the at least one performance parameter provided by the performance measurement application, a fault condition affecting the at least one packet flow is detected; and

[0021] c) In response to the detection of a fault condition, further monitoring of the performance of the at least one packet flow is activated by at least one measurement point located within the packet-switched communication network along the path of the at least one packet flow, the further monitoring including providing values ​​for at least one further performance parameter associated with the at least one packet flow.

[0022] According to an embodiment, step b) includes comparing the value of the at least one performance parameter with a predefined threshold, and detecting a fault condition when one or more consecutive values ​​of the at least one performance parameter exceed the predefined threshold.

[0023] Preferably, step b) is performed by a performance measurement application.

[0024] Preferably, step b) includes notifying the measurement management server, which collaborates with the performance measurement application and the at least one measurement point, of the fault condition by sending an alarm message from the performance measurement application to the measurement management server.

[0025] Preferably, step c) includes sending an activation message from the measurement management server to the at least one measurement point.

[0026] Alternatively, the at least one measurement point is pre-configured to monitor packets including predefined private identifiers, and step c) includes sending an instruction from the measurement management server to the performance measurement application to insert the predefined private identifiers into the at least one packet stream.

[0027] Optionally, step a) further includes: sending a periodic acknowledgment message from the performance measurement application to the measurement management server as long as no fault condition is detected, the acknowledgment message notifying the measurement management server that monitoring is in progress and no fault condition has been detected.

[0028] Preferably, step a) further includes sending an update message from the performance measurement application to the measurement management server, the update message including periodic updates to the value of the at least one performance parameter.

[0029] Preferably, step c) further includes sending an update message from the at least one measurement point to the measurement management server, the update message including periodic updates to the value of at least one further performance parameter.

[0030] According to an embodiment, step a) includes:

[0031] - Activate the marking functionality for the at least one packet flow, the marking functionality including marking upstream packets of the at least one packet flow and causing network nodes in the packet-switched communication network that generate downstream packets of the at least one packet flow to mark downstream packets; and

[0032] - Detect upstream packets of a tag sent by the user communication device and / or downstream packets of a tag received by the user communication device, and provide a value for the at least one performance parameter based on the detection.

[0033] Preferably, marking the upstream packet of the at least one packet stream at step a) includes setting the value of at least one measurement-specific field in the upstream packet; and causing the network node of the packet-switched communication network that generates the downstream packet stream to mark the downstream packet includes causing the network node to set the value of at least one measurement-specific field in the downstream packet.

[0034] According to a second aspect, the present invention provides a system for providing performance measurements of a packet-switched communication network, the system comprising:

[0035] - A performance measurement application configured to monitor the performance of at least one packet stream exchanged between a user application running on a user communication device and a packet-switched communication network when the user communication device is in operation, the monitoring including providing a value for at least one performance parameter associated with the at least one packet stream; and

[0036] - At least one measurement point located within the packet-switched communication network along the path of the at least one packet flow, the at least one measurement point being configured to activate further monitoring of the performance of the at least one packet flow in response to the detection of a fault condition affecting the at least one packet flow based on a value of the at least one performance parameter provided by a performance measurement application, the further monitoring including providing a value of at least one further performance parameter associated with the at least one packet flow. Attached Figure Description

[0037] The invention will become clearer from the following detailed description, given by way of example and not limitation and read with reference to the accompanying drawings, in which:

[0038] Figure 1 The architecture of a performance measurement system according to an embodiment of the present invention is illustrated schematically;

[0039] Figure 2 The invention schematically illustrates an embodiment of the present invention. Figure 1 The structure of packets sent or received by user communication equipment; and

[0040] Figure 3 This is according to an embodiment of the present invention. Figure 1 A flowchart of the operation of the performance measurement system. Detailed Implementation

[0041] Figure 1 The architecture of a system 100 for providing performance measurement of a packet-switched communication network 200 according to an embodiment of the present invention is illustrated schematically.

[0042] System 100 includes a performance measurement application 10 suitable for installation on a user communication device 1, at least one measurement point 11, and a measurement management server 12.

[0043] The performance measurement application 10 can be downloaded and installed on the user communication device 1, or it can be part of the operating system of the user communication device 1. The user communication device 1 can be a PC, smartphone, tablet, IoT (Internet of Things) device, or any other device with the ability to connect to the packet-switched communication network 200. Connectivity can be wired or wireless (e.g., Wi-Fi or mobile). The user communication device 1 can be a personal device (typically, whose user is also its owner) or a commercial device (typically, whose owner is a natural or legal person other than its user).

[0044] User communication device 1 includes at least one user application A1, configured to provide communication services provided by a service provider to device 1, such as web browsing, video conferencing, multimedia streaming, e-commerce, and e-banking services. User communication device 1 may include several user applications providing different communication services. User application A1 (and other user applications of device 1, if any) supports the provision of corresponding communication services by exchanging streams of user packets with packet-switched communication network 200, particularly with network node 2 (typically a service provider's server). The packet stream is typically bidirectional; that is, it includes upstream packets Pk (i.e., packets transmitted from device 1 to network 200) and downstream packets Pk' (i.e., packets transmitted from network 200 to device 1). User application A1 generates upstream packets Pk to be transmitted to network node 2 and terminates downstream packets Pk' received from network node 2.

[0045] Measurement point 11 is preferably implemented at a node in the packet-switched communication network 200 along the path followed by upstream packet Pk and / or downstream packet Pk' between user communication equipment 1 and network node 2. Measurement point 11 is particularly preferably implemented at an intermediate node between user communication equipment 1 and network node 2.

[0046] The measurement management server 12 is preferably operatively connected to both the performance measurement application 10 and the measurement point 11. The measurement management server 12 can be implemented as a single machine, or as a cluster of machines, for example, via cloud computing technology within network 200. The measurement management server 12 can be implemented via network 200 itself or via... Figure 1 Another network, not depicted, is operatively connected to performance measurement application 10 and measurement point 11.

[0047] According to an embodiment of the present invention, performance measurement application 10 is configured to monitor the performance of bidirectional packet streams Pk and Pk' exchanged between user application A1 and node 2 of communication network 200 by providing values ​​of associated performance parameters (e.g., packet loss values, latency values, etc.) when it is running by user communication device 1. When a fault condition is detected based on the performance parameter values ​​provided by performance measurement application 10, measurement management server 12 preferably instructs measurement point 11 to also begin monitoring the performance of bidirectional packet streams Pk and Pk' by providing values ​​of further associated performance parameters (e.g., packet loss values, latency values, etc.).

[0048] Now refer to Figure 3 The flowchart describes the operation of system 100 and its components in more detail.

[0049] In the first step 301, the performance measurement application 10 preferably begins monitoring the performance of the bidirectional packet streams Pk, Pk' exchanged between the user application A1 and node 2 of the communication network 200 by providing at least one performance parameter associated with them (step 301). The performance parameter value PP(i) may be provided periodically. The performance parameter value PP(i) may be, for example, a packet loss value or a delay value.

[0050] Preferably, step 301 is triggered by the performance measurement application 10 receiving a performance measurement request from, for example, the owner or user of device 1 or measurement management server 12. Such a request may include the packet stream Pk to be measured, the identifier of Pk' (e.g., its destination address), and the type of performance measurement to be performed (packet loss, latency, etc.).

[0051] According to an embodiment of the invention, the requested performance measurement depends on the labeling of groups Pk, Pk'.

[0052] In particular, such as Figure 2 The diagram schematically depicts each packet Pk, Pk' exchanged by user application A1, comprising a payload PL and at least one header H, the payload PL containing user data. In the case of multiple headers, each header belongs to a different network layer. For example, each packet Pk, Pk' may include a network layer header (such as an IP header) and a transport layer header (such as a QUIC header or a TCP header). One of the headers H (typically a network layer header) includes message forwarding information, i.e., information allowing upstream messages Pk generated by user communication device 1 to reach network node 2 and downstream messages Pk' generated by network node 2 to reach user communication device 1.

[0053] Each packet Pk, Pk' also preferably includes at least one measurement-specific field MF (hereinafter also referred to as "marker field") that supports at least one type of performance measurement of packet streams Pk, Pk'. One or more marker fields MF may be included in the same header H as the packet forwarding information (e.g., ...). Figure 2 As shown in the diagram), in different headers (if any) or in the payload PL. For example, assuming packets Pk and Pk' include network layer headers (such as IP headers) and transport layer headers (such as QUIC headers), one or more tag fields MF can be included in the transport layer header.

[0054] The number of marker fields and their positions in packets Pk and Pk' depend on the protocol(s) upon which the packet formatting is based and the types of performance(s) supported(s). As a non-limiting example, if packets Pk and Pk' are formatted according to the QUIC protocol, then the marker field(s) MF may be in the QUIC header and may include (i) spin bits supporting RTT measurements, as disclosed in the aforementioned Internet draft by B. Trammel et al.; and / or (ii) loss bits supporting round-trip packet loss measurements, as disclosed in the aforementioned Internet draft by M. Cociglio et al.; and / or (iii) Q bits and L bits supporting different types of one-way packet loss measurements, as disclosed in the aforementioned Internet draft by A. Ferrieux et al.

[0055] At step 301, performance measurement application 10 preferably activates a marking functionality for packet flows Pk, Pk', which specifies marking the upstream packet Pk initiated by user application A1 and prompts network node 2 to also mark the downstream packet Pk' to support the requested performance measurement on packet flows Pk, Pk'. Marking includes appropriately setting the value of one or more marking fields MF in packets Pk, Pk' to support the requested performance measurement. For example, if a round-trip packet loss measurement disclosed in the aforementioned known Internet draft by M. Cociglio et al. has been requested, marking includes setting the value of the loss bit in packets Pk, Pk'. The marking of upstream packet Pk and downstream packet Pk' is consistent with each other because they support the same performance measurement on packets Pk, Pk'.

[0056] The tagging functionality can be embedded in user application A1, meaning that the values ​​of one or more tagging fields MF in upstream packet Pk can be exclusively set by user application A1. This is the case, for example, when one or more tagging fields MF of packets Pk and Pk' are included in the header of a client-server protocol (such as QUIC), whose client is embedded in user application A1 itself. In this case, at step 301, performance management application 10 instructs user application A1 to activate the tagging functionality.

[0057] Otherwise (for example, in the case where user application A1 uses TCP as the transport layer protocol), performance management application 10 can perform its own tagging functionality by appropriately setting the values ​​of one or more relevant tag fields MF.

[0058] To ensure that the network node 2 that initiated the downstream packet Pk' consistently marks them with the label of the upstream packet Pk, different mechanisms can be used.

[0059] For example, if one or more of the tag fields MF of packets Pk and Pk' are included in the header of a client-server protocol (such as QUIC), and the client is embedded in user application A1 and its server is in network node 2 that initiated the downstream packet Pk', the client in user application A1 can instruct the server in network node 2 to begin tagging the downstream packet Pk'. This instruction can include sending an explicit tagging command from the client to the server. Otherwise, the server at network node 2 can be configured to permanently implement a reflection mechanism, whereby it reflects the values ​​of one or more tag fields MF received from the upstream packet Pk into one or more tag fields MF of the corresponding downstream packet Pk' (e.g., the next packet in the downstream packet stream). In this case, when the client in user application A1 begins tagging the upstream packet Pk, the server in network node 2 receives them and automatically and consistently tags the downstream packet Pk' with the tag of the upstream packet Pk by simply continuing to implement its reflection mechanism.

[0060] According to other embodiments, performance management application 10 may send a marking instruction to network node 2, or negotiate a marking with it.

[0061] After the user application A1 activates the tag functionality, at step 301, the performance management application 10 preferably begins detecting upstream packets Pk of the tag sent by the user communication device 1 and / or downstream packets Pk' of the tag received by the user communication device 1 and provides a value PP(i) of the performance parameter indicating the requested performance measurement. The performance parameter value PP(i) may be provided periodically.

[0062] For example, if the round-trip packet loss measurement disclosed in the aforementioned known Internet draft by M. Cociglio et al. has been requested, the performance management application 10 can count the number of transmitted upstream packets Pk with a loss bit equal to 1 in each consecutive upstream packet Pk sequence, and provide a round-trip packet loss value PP(i) based on such count.

[0063] During step 301, performance measurement application 10 determines potential fault conditions that may affect packet flows Pk and Pk' (step 302). The determination of potential fault conditions is preferably based on the performance parameter value PP(i) provided at step 301.

[0064] According to an embodiment, in order to determine the possible fault conditions affecting packet flows Pk and Pk' at step 302, the performance measurement application 10 preferably compares the performance parameter value PP(i) provided at step 301 with a predefined threshold TH. If the performance parameter value PP(i) does not exceed the threshold TH, then at step 302, it is determined that there is no fault condition. Conversely, if one or more consecutive performance parameter values ​​PP(i) exceed the threshold TH, then a fault condition is determined. The threshold TH can be determined by the measurement management server 12 and transmitted to the performance measurement application 10 before the measurement begins. The threshold can be static or can be modified or dynamically changed by the measurement management server 12. For example, if a round-trip packet loss measurement as disclosed in the Internet draft of M. Cociglio et al., as known above, has been requested, then the threshold TH can be the maximum value of the round-trip packet loss.

[0065] As long as no fault condition affecting packet streams Pk and Pk' is detected at step 302, the performance measurement application 10 preferably continues to monitor packet streams Pk and Pk'. The performance measurement application 10 may also send periodic acknowledgment messages to the measurement management server 12 to notify the measurement management server 12 that monitoring is in progress and no fault condition has been detected.

[0066] Alternatively or additionally, the performance measurement application 10 may also send an update message (step 303) to the measurement management server 12, which includes periodic updates to the measurement results. The update message may specifically include the performance measurement value PP(i) calculated since the last update. Additionally or alternatively, the update message may include statistics on the performance measurement values ​​PP(i) calculated since the last update, such as their average, maximum, and minimum values. The update message may be transmitted to the measurement management server 12 at a longer period than the calculation of the performance parameter value PP(i) (e.g., weekly).

[0067] If a fault condition affecting packet flows Pk and Pk' is detected at a certain point, the performance measurement application 10 preferably notifies the measurement management server 12 of this event by sending an alarm message to the measurement management server 12 (step 304). The alarm message preferably includes identifiers of packet flows Pk and Pk' (e.g., their IP source address and / or their IP destination address), and optionally, also includes an indication of the fault type (e.g., packet loss fault, delay fault, etc.). The alarm message may also include one or more performance parameter values ​​PP(i) based on the fault condition(i) that have been detected (e.g., those values ​​that exceed a predefined threshold TH).

[0068] According to another variant, the measurement management server 12 itself can determine the occurrence of a fault condition, for example, based on the performance parameter value PP(i) included in the update message received from the performance measurement application 10 at step 303.

[0069] When the performance management application 10 notifies the measurement management server 12 of a fault condition (or, according to the above variant, the measurement management server 12 detects the fault condition itself), the measurement management server 12 preferably activates the measurement point 11 (step 305), for example by sending it an activation message.

[0070] This activation message preferably includes identifiers for packet flows Pk and Pk', which allow measurement point 11 to uniquely identify packets within the packet flow to be monitored. These identifiers may include, for example, the IP source address and IP destination address of upstream packet Pk and / or downstream packet Pk'. The activation message also preferably includes the type of performance measurement to be performed (packet loss, latency, etc.).

[0071] Alternatively, measurement point 11 can be pre-configured to monitor packet flows identified by one or more dedicated identifiers (e.g., a set of IP addresses) that are not typically used for packet flow transmission within network 200. When performance measurement application 10 detects a fault condition affecting packet flows Pk and Pk' at step 302, it preferably changes the IP address in upstream packet Pk and / or downstream packet Pk' to one of the dedicated addresses. More specifically, upon receiving an alarm message notifying measurement management server 12 of a fault condition affecting packet flows Pk and Pk', measurement management server 12 preferably instructs performance measurement application 10 to change the IP source address in upstream packet Pk or the IP destination address in downstream packet Pk' to one of the dedicated addresses by changing the IP address assigned to user communication device 1 to one of the dedicated addresses. This automatically triggers measurement point 11 to monitor the performance of packet flows Pk and Pk' without requiring any activation message to be sent to measurement point 11. This variant is advantageous, for example, when activating several measurement points 11 and / or when determining which (which) measurement points 11 should be activated, for example, due to a particularly complex network topology.

[0072] In response to receiving an activation message from the measurement management server 12, measurement point 11 begins monitoring the performance of the bidirectional packet streams Pk and Pk' by providing a value PP'(i) of at least one further performance parameter associated with the bidirectional packet streams Pk and Pk' (e.g., packet loss value, latency value, etc.) (step 306). Since the packets Pk and Pk' have been tagged (the tagging functionality has been activated by the performance measurement application 10 at step 301), the monitoring performed by measurement point 11 can also rely on this tagging.

[0073] When measurement point 11 provides further performance parameter values ​​PP'(i), it can send a periodic update message (step 307) to measurement management server 12, which includes periodic updates of the measurement results. The update message may specifically include further performance measurement values ​​PP'(i) calculated since the last update. Additionally or alternatively, the update message may include statistics on the further performance measurement values ​​PP'(i) calculated since the last update, such as their average, maximum, and minimum values. Update messages may be transmitted to measurement management server 12 at longer intervals than the calculation of the further performance parameter values ​​PP'(i).

[0074] Since measurement point 11 is located on the path of group flows Pk, Pk', the further performance parameter value PP'(i) provided by measurement point 11 can provide the measurement management server 12 with an indication of, for example, the path length or path segment affected by the fault condition detected at step 302, based on the performance parameter value PP'(i).

[0075] For example, at step 301, for example, according to the technology disclosed in the aforementioned Internet draft by M. Cociglio et al., the performance measurement application 10 can provide round-trip packet loss values ​​between the user communication device 1 and the network node 2 that terminates the path of the bidirectional packet streams Pk, Pk' at the other end.

[0076] As long as no fault condition is detected (e.g., the number of round-trip packet losses does not exceed the predefined maximum threshold TH), packet streams Pk and Pk' continue to be monitored solely by the performance measurement application 10.

[0077] If a fault condition is detected at a point based on the round-trip packet loss value PP(i) provided by the performance measurement application 10 (e.g., one or more consecutive round-trip packet loss values ​​exceed a predefined maximum threshold TH), the measurement management server 12 begins monitoring of the bidirectional packet stream Pk, Pk' by providing, for example, the round-trip packet loss value PP'(i) between the measurement point 11 itself and the network node 2 that terminates the path of the bidirectional packet stream Pk, Pk' at the peer of the user communication device 1 (step 306) (step 305). These further round-trip packet loss values ​​PP'(i) advantageously provide an indication of whether the fault condition detected by the performance measurement application 10 occurs on the path length between the user communication device 1 and the measurement point 11, or on the path length between the measurement point 11 and the network node 2.

[0078] If several measurement points 11 are distributed along the path of packets Pk, Pk' between user communication device 1 and network node 2, then the further performance parameter values ​​provided by each of them at steps 306 and 307 will allow measurement management server 12 to more accurately determine the location of the fault.

[0079] Then, the system 100 according to the invention advantageously allows for a reduction in the amount of computation required for one or more measurement points 11 deployed in the packet-switched communication network 200.

[0080] In practice, under normal conditions (i.e., when no fault condition is detected at step 302), only the performance measurement application 10 monitors the performance of packet streams Pk and Pk', thus acting as a measurement point capable of monitoring whether the user communication device 1 is exchanging packet streams Pk and Pk' with the packet-switched communication network 200 and detecting any fault conditions that may affect packet streams Pk and Pk'. Under normal conditions, measurement point (one or more) 11 remains inactive and is only activated by the measurement management server 12 when a fault condition is detected based on the performance parameter value PP(i) provided by the performance measurement application 10.

[0081] Therefore, even if measurement point 11 is deployed at a node of network 200 (e.g., to a gateway to the WAN) traversed by hundreds or even millions of packet flows, it is only used to monitor the performance of a specific packet flow (i.e., the packet flow for which a fault condition has been detected based on the performance parameter value PP(i) provided by one or more performance measurement applications 10). This requires far fewer computational resources from measurement point 11 than continuously monitoring the performance of all packet flows traversing the measurement point.

Claims

1. A method for providing performance measurements of a packet-switched communication network (200), the method comprising: a) A performance measurement application (10) running on the user communication device (1) monitors the performance of at least one packet stream (Pk, Pk') of user packets, and a user application (A1) running on the user communication device (1) exchanges the user packets with the packet switching communication network (200) to provide the user communication device (1) with communication services provided by the service provider, the monitoring including providing the value (PP(i)) of at least one performance parameter associated with the at least one packet stream (Pk, Pk'). b) The performance measurement application (10) detects a fault condition affecting the at least one packet flow (Pk, Pk') based on the value (PP(i)) of the at least one performance parameter provided by the performance measurement application (10); and c) In response to the detection of the fault condition, further monitoring of the performance of the at least one packet flow (Pk, Pk') is activated by at least one measurement point (11) located within the packet-switched communication network (200) on the path of the at least one packet flow (Pk, Pk'), the further monitoring including providing the value of at least one further performance parameter (PP'(i)) associated with the at least one packet flow (Pk, Pk').

2. The method of claim 1, wherein step b) comprises comparing the value (PP(i)) of the at least one performance parameter with a predefined threshold (TH), and detecting the fault condition when one or more consecutive values ​​(PP(i)) of the at least one performance parameter exceed the predefined threshold (TH).

3. The method of claim 1, wherein step b) comprises notifying the measurement management server (12) of the fault condition by sending an alarm message from the performance measurement application (10) to a measurement management server (12) that cooperates with the performance measurement application (10) and the at least one measurement point (11).

4. The method according to claim 3, wherein step c) includes sending an activation message from the measurement management server (12) to the at least one measurement point (11).

5. The method of claim 3, wherein the at least one measurement point (11) is preconfigured to monitor packets including a predefined private identifier, and wherein step c) includes sending an instruction from the measurement management server (12) to the performance measurement application (10) to insert the predefined private identifier into the at least one packet stream (Pk, Pk').

6. The method according to any one of claims 3 to 5, wherein step a) further comprises sending a periodic confirmation message from the performance measurement application (10) to the measurement management server (12) as long as no fault condition is detected, the confirmation message notifying the measurement management server (12) that the monitoring is in progress and no fault condition has been detected.

7. The method according to any one of claims 3 to 5, wherein step a) further comprises sending an update message from the performance measurement application (10) to the measurement management server (12), the update message comprising a periodic update of the value (PP(i)) of the at least one performance parameter.

8. The method according to any one of claims 3 to 5, wherein step c) further comprises sending an update message from the at least one measurement point (11) to the measurement management server (12), the update message comprising periodic updates to the value (PP'(i)) of the at least one further performance parameter.

9. The method according to any one of claims 1 to 5, wherein step a) comprises: - Activate the marking functionality for the at least one packet stream (Pk, Pk'), the marking functionality including marking the upstream packet (Pk) of the at least one packet stream and causing the network node (2) of the packet-switched communication network (200) that generates the downstream packet (Pk') of the at least one packet stream to mark the downstream packet (Pk'). as well as - Detect the tagged upstream packets (Pk) sent by the user communication device (1) and / or the tagged downstream packets (Pk') received by the user communication device (1), and provide the value (PP(i)) of the at least one performance parameter based on the detection.

10. The method of claim 9, wherein marking the upstream packet (Pk) of the at least one packet stream at step a) includes setting the value of at least one measurement-specific field (MF) in the upstream packet (Pk); and causing the network node (2) of the packet-switched communication network (200) that generates the downstream packet (Pk') of the packet stream to mark the downstream packet (Pk') includes causing the network node (2) to set the value of at least one measurement-specific field (MF) in the downstream packet (Pk').

11. A system (100) for providing performance measurements of a packet-switched communication network (200), the system (100) comprising: - A performance measurement application (10) is configured to monitor the performance of at least one packet stream (Pk, Pk') of user packets when running by a user communication device (1), wherein a user application (A1) running by the user communication device (1) exchanges the user packets with the packet-switched communication network (200) to provide the user communication device (1) with communication services provided by a service provider, the monitoring including providing a value (PP(i)) of at least one performance parameter associated with the at least one packet stream (Pk, Pk'); and - At least one measurement point (11) located within the packet-switched communication network (200) on the path of the at least one packet flow (Pk, Pk'), the at least one measurement point (11) being configured to perform further monitoring of the performance of the at least one packet flow (Pk, Pk') in response to detecting a fault condition affecting the at least one packet flow (Pk, Pk') based on the value (PP(i)) of the at least one performance parameter provided by the performance measurement application (10), the further monitoring including providing the value (PP'(i)) of at least one further performance parameter associated with the at least one packet flow (Pk, Pk').

Images