CN101378337A

CN101378337A - Method for measuring service quality, network appliance and network system

Info

Publication number: CN101378337A
Application number: CNA2007101484079A
Authority: CN
Inventors: 刘颖
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-08-28
Filing date: 2007-08-28
Publication date: 2009-03-04
Anticipated expiration: 2027-08-28
Also published as: CN101378337B

Abstract

The invention relates to a method for measuring service quality, and network equipment and a network system thereof, wherein, the method comprises the steps that: received sender reporting RTCP SR messages in a real-time control protocol is transmitted to a second measuring point by a first measuring point; receiver reporting extra RTCP RR messages in an extra real-time control protocol transmitted by the second measuring point is received; and the QoS parameters between the local site and the second measuring point are calculated by the first measuring point according to the extra RTCP RR messages. The network equipment comprises a message generating unit and a second message transmitting unit; the network system comprises the first network equipment comprising a first message transmitting unit, a message receiving unit and a network segment service quality calculating unit; and the second network equipment comprises a message generating unit and the second message transmitting unit. The invention can realize the service quality measurement based on the network segments under the situation that the network burden is not increased.

Description

Method for measuring service quality, network equipment and network system

Technical Field

The present invention relates to network technologies, and in particular, to a method, a network device, and a network system for measuring quality of service.

Background

With the increase of service demand and the development of Internet Protocol (IP) network technology, more and more real-time services are transmitted on an IP network. The addition of real-time services such as voice, video, multimedia, and telephone conference provides a new challenge to the IP network, and how to ensure the quality of the real-time services is a hot issue at present. Real-Time Protocol (RTP) is an end-to-end transmission Protocol for transmitting data of Real-Time services, and information such as a sequence number and a timestamp provided by the RTP provides a basis for a host-end reassembly packet of the packet. However, RTP does not provide Quality of Service (QoS) guarantee and Real-Time transmission guarantee for the data stream of the Real-Time Service, and needs to complete QoS parameter calculation along with a Real-Time Control Protocol (RTCP) to provide a basis for source-end transmission Control of the data stream. RTCP enables feedback of end-to-end network layer QoS parameters, such as network delay, delay jitter, packet loss rate, etc.

For quality of service, it is generally desirable to guarantee from two aspects. When the service quality is normal, checking the service quality routinely to prevent the service quality from happening; when the service quality is in problem, the problem is located as soon as possible, the reason causing the service quality change is grasped, and corresponding improvement measures are implemented. A common positioning method is to measure QoS performance variation in a service transmission process, and position a problem by using established performance indicators, such as network delay, delay jitter, packet loss rate, and threshold values of each indicator. The nature of RTP/RTCP dictates that it can be used to measure the QoS parameters of real-time traffic in the network. Besides reflecting the QoS condition of the service, the measurement result can also be provided for other entities to use, such as a resource admission management control entity and the like.

Currently, the commonly used method for measuring QoS based on RTP/RTCP mainly comprises active measurement and passive measurement.

In the active QoS measurement, it is assumed that a source user equipment (CPE) -a is a sender of a packet, a sink CPE-B is a receiver of the packet, 3 measurement points (monitors) are arranged between the source CPE-a and the sink CPE-B, the monitors are respectively a Monitor1, a Monitor2 and a Monitor3, the source CPE-a sends an RTP/RTCP SR data stream to the sink CPE-B, and 3 measurement points are arranged on a path through which the RTP/RTCP SR data stream flows. In turn, Monitor1, Monitor2, and Monitor 3. In the active measurement, when a measurement point monitors an end-to-end RTP data stream, it is further required to additionally generate a sender Report (RTCP SR, RTCP sender Report) message in an RTCP protocol and a receiver Report (RTCP RR, RTCP receiver Report) message in the RTCP protocol corresponding to the RTP data, and interact with other measurement points using the additional RTCP SR/RTCP RR messages to obtain QoS parameters between the measurement points and the other measurement points.

In the active measurement, although a measurement result based on a network segment can be provided, the measurement result has a direct relationship with measurement points arranged between network segments, and the more measurement points are arranged, the more valuable the measurement result is, but besides the RTP/RTCP SR message needs to be forwarded, the receiver report Extra RTCP SR/RR message in an Extra real-time control protocol needs to be generated between each measurement point for interaction, thereby increasing the burden of the network.

Please refer to fig. 1, which is a diagram illustrating a method for passive QoS measurement based on RTP/RTCP in the prior art. In passive measurement, a measurement point monitors RTP/RTCP data flow passing through the local, and respectively calculates QoS parameters of the RTP/RTCP data flow between a sender and the local of a message and between the local and a receiver of the message. Specifically, as shown in fig. 1, 2 measurement points, i.e., Monitor1 and Monitor2, are provided between the source CPE-a and the sink CPE-B, and an RTP/RTCP data stream sent by the source CPE-a to the sink CPE-B sequentially passes through Monitor1 and Monitor2, which specifically includes:

step 101, the source CPE-A sends out RTP/RTCP SR messages.

In step 102 and step 102', the Monitor1 and the Monitor2 successively record the information of the received RTP messages, wherein the information comprises the number of the RTP messages, the transmission delay and the like.

103, when the RTCP SR message reaches Monitor1, Monitor1 records the arrival time of the RTCP SR message, and extracts the information of the source CPE-A, wherein the information comprises the synchronous source identification SSRC of the sender and the maximum message number sent. Then, calculating QoS performance parameters such as RTP data packet loss rate, delay jitter and accumulated packet loss number in two RTCP SR message time periods before and after in the transmission process of the RTP data from the source end CPE-A to the local (i.e. Monitor 1).

Step 104, the Monitor1 continues to forward the RTCP SR messages to the next measurement point (i.e. Monitor 2).

Step 105, after receiving the RTCP SR message, the Monitor2 calculates QoS performance parameters such as RTP data packet loss rate, delay jitter, and cumulative packet loss in the transmission process of the RTP data stream between the source CPE-a and the local (i.e., Monitor2) in the two RTCP SR message time periods. QoS parameters in between;

step 106, continuously forwarding the RTCP SR message to the host CPE-B;

step 107, the host CPE-B calculates end-to-end QoS parameters including packet loss rate, delay jitter, accumulated packet loss number and time spent for generating the RTCP RR message according to the information of the RTP/RTCP SR message, and then generates the RTCP RR message;

and 108, returning the generated RTCP RR message to the source CPE-A.

Step 109, when the Monitor2 detects that the destination CPE-B returns the generated RTCP RR packet, it extracts the end-to-end QoS parameter, and compares it with the locally (i.e. Monitor2) calculated QoS parameter, so as to obtain the QoS performance parameter of RTP stream between the local and the destination CPE-B.

And step 110, continuing to forward and generate the RTCP RR message.

Step 111, when Monitor1 also monitors the generated RTCP RR message, calculating the QoS performance parameter of RTP stream between local (Monitor1) and host CPE-B according to the same calculation method as Monitor 2;

and step 112, the Monitor2 continues to forward the generated RTCP RR messages.

And 113, the source end CPE-A finally receives the RTCP RR message, obtains end-to-end QoS performance parameters, and calculates end-to-end RTT.

As can be seen from the implementation process, in the passive measurement, although a new RTCP packet is not introduced, in the passive measurement, the measurement point can only calculate the QoS parameter from both ends to the local, and cannot calculate the QoS parameter from the adjacent measurement point to the local, so the passive measurement cannot perform measurement based on the network segment.

After careful analysis and careful research, the inventor finds that the prior art has the defect that the QoS cannot be measured based on the network segment without increasing the network load.

Disclosure of Invention

Embodiments of the present invention provide a method, an apparatus, and a system for measuring quality of service, which are used to implement network segment-based quality of service measurement without increasing too much network load.

To solve the foregoing technical problem, an embodiment of the present invention provides a method for measuring quality of service, where the method includes:

the first measuring point calculates and stores a local QoS (quality of service) parameter of the RTP data stream according to an RTCP SR (real-time control protocol) report message of a sender in a real-time control protocol corresponding to the RTP data stream, and then forwards the RTCP SR message to the second measuring point;

when the second measurement point forwards the RTCP SR message, a receiver report extra RTCP RR message in an extra real-time control protocol is generated, and the extra RTCP RR message is sent in a service providing domain;

and the first measuring point calculates the QoS parameter between the local measuring point and the second measuring point according to the received extra RTCP RR message.

The embodiment of the invention also provides a method for measuring the service quality, which comprises the following steps:

the first measuring point sends a sender report RTCP SR message in a received real-time control protocol to the second measuring point;

receiving an extra RTCP RR message sent by a second measuring point and reported by a receiver in an extra real-time control protocol;

and the first measuring point calculates the QoS parameter between the local measuring point and the second measuring point according to the extra RTCP RR message.

the second measurement point generates an extra RTCP RR message when forwarding the received RTCP SR message; the extra RTCP RR message comprises a sender synchronous source identification, a locally calculated QoS parameter and a network time protocol timestamp when the sender generates the RTCP SR message;

and sending the extra RTCP RR messages in a service providing domain to be used for calculating the service quality between the measurement points.

In addition, an embodiment of the present invention further provides a network device, including:

the first message sending unit is used for sending the received RTCP SR message to the second measuring point;

a message receiving unit, configured to receive an extra RTCP RR message sent by the second measurement point;

and the network segment service quality calculating unit is used for calculating the QoS parameter between the local and the second measuring point according to the extra RTCP RR message.

An embodiment of the present invention further provides a network device, including:

the message generating unit is used for generating an extra RTCPR message when the received RTCP SR message is forwarded, wherein the extra RTCP RR message comprises a sender synchronous source identifier, a locally calculated QoS parameter and a network time protocol timestamp when the sender generates the RTCP SR message;

and a second message sending unit, configured to send the RTCP RR message in a service providing domain, so as to calculate the quality of service between the measurement points.

In addition, the embodiment of the invention also provides a network system, which comprises a first network device and a second network device, wherein,

the first network device includes:

a network segment service quality calculating unit, configured to calculate a QoS parameter between the local and the second measurement point according to the extra RTCP RR packet;

the second network device includes:

and the second message sending unit is used for sending the extra RTCP RR message to the message receiving unit in the service providing domain so as to calculate the service quality between the measurement points.

In the embodiment of the invention, the first measurement point calculates the QoS parameters between the measurement points according to the extra RTCP RR messages sent by the second measurement point. This simplifies the preparation before the measurement and also the control of the measurement points. That is to say, when the second measurement point stores and forwards the end-to-end RTP/RTCP packet, only one type of packet of the extra RTCP RR needs to be generated, which simplifies the requirement of the measurement point for processing the extra RTCP packet. And when the first measuring point receives the extra RTCP RR, calculating the QoS performance between the first measuring point and the second measuring point according to the information in the extra RTCP RR message. Therefore, under the condition of not increasing network burden, the measurement based on the service quality between the network segments is realized.

Drawings

FIG. 1 is a diagram illustrating a method for passive QoS measurement based on RTP/RTCP in the prior art;

FIG. 2 is a flowchart of a method for a first measurement point to measure QoS according to an embodiment of the present invention;

FIG. 3 is a flowchart of a method for measuring QoS at a second measurement point according to an embodiment of the present invention;

FIG. 4 is a diagram illustrating an exemplary scenario for measuring QoS between network segments according to an embodiment of the present invention;

FIG. 5 is a flowchart illustrating RTP/RTCP channel-associated measurement performed by a measurement point according to an embodiment of the present invention;

FIG. 6 is a diagram of another application scenario for measuring QoS between network segments according to an embodiment of the present invention;

FIG. 7 is another flow chart of the measurement point based on RTP/RTCP channel measurements according to the embodiment of the present invention;

FIG. 8 is a flowchart of a method for a measurement point to measure QoS according to an embodiment of the present invention;

FIG. 9 is a diagram illustrating a network device according to an embodiment of the present invention;

FIG. 10 is a schematic structural diagram of a network device according to another embodiment of the present invention;

fig. 11 is a schematic structural diagram of a network system according to an embodiment of the present invention.

Detailed Description

Embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

Referring to fig. 2 and fig. 3, a flowchart of a method for measuring qos at a first and a second measurement point according to an embodiment of the present invention is shown. The method as shown in fig. 2 comprises the following steps:

step 201, a first measuring point sends a sender report RTCP SR message in a received real-time control protocol to a second measuring point;

step 202, receiving an extra RTCPP RR message sent by a second measuring point and reported by a receiver in an extra real-time control protocol;

and 203, the first measuring point calculates the QoS parameter between the local measuring point and the second measuring point according to the extra RTCP RR message.

The method as shown in FIG. 3 comprises

301, when the second measurement point forwards the received RTCP SR message, generating an extra RTCPR message; the extra RTCP RR message comprises a sender synchronous source identification, a locally calculated QoS parameter and a network time protocol timestamp when the sender generates the RTCP SR message;

step 302, sending the extra RTCP RR packets in the service providing domain for calculating the service quality between the measurement points.

That is to say, in the embodiments of fig. 2 and fig. 3, it is assumed that there are two measurement points, and when a first measurement point receives an RTCP SR message corresponding to an RTP data stream, sender information in the RTCP SR message is extracted; after calculating and storing the QoS parameter of the RTP data stream reaching the local, the RTCP SR message is forwarded to a second stream measuring point;

when the second measuring point receives the RTCP SR message, the QoS parameter of the RTP data stream arriving at the local is calculated and stored, and the calculating process is the same as that of the first measuring point. When the second stream measuring point transmits the RTCP SR message, an extra RTCP RR message is generated, and the extra RTCP RR message is sent in a service providing domain, wherein the extra RTCP RR message comprises a sender synchronous source identifier, a locally calculated QoS parameter, a network time protocol timestamp LSR when the sender generates the RTCP SR message, and a time DLSR consumed for generating the extra RTCP RR message;

and when the sender information in the extra RTCP RR messages received by the first measuring point is matched with the locally stored sender information, calculating the QoS parameters between the local measuring point and a second measuring point which sends the extra RTCP RR messages.

The technical scheme of the embodiment of the invention is that the measurement point can measure the QoS parameters based on the network segments. In the implementation of the method, the measurement cost of other measurement points is reduced as much as possible besides the function of the measurement point is strengthened. For example, the measurement point can realize measurement based on the inter-network-segment QoS parameter without excessive additional work such as configuration preparation before measurement or statistical calculation of measurement results by other entities; the measurement result can reflect the performance condition of RTP data flow passing through the network segment more truly. Therefore, the embodiment of the invention makes full use of the characteristics of the RTCP message to improve the passive measurement, so that the measurement point can rapidly measure the QoS parameters between the network segments.

For a certain RTP flow, a measuring point (which can be a first measuring point or a second measuring point, or an upstream measuring point and a downstream measuring point; the two are relatively speaking) monitors the information that an RTP message reaches the local, when the corresponding RTCP SR message passes through the measuring point, the sender information in the RTCP SR message is recorded, and the sender information in the RTCP SR message is extracted, wherein the sender information comprises a sender synchronization source identifier (SSRC) and the number of sent messages; or the sender synchronizes the source identifier, the number of messages sent, and the network time protocol timestamp NTP timestamp, but not limited thereto; calculating QoS parameters when RTP flows pass through the local area, and synchronizing source identification by a sender of the RTP flows; or the synchronous source identification of the sender and the network time protocol timestamp are used as index storage; and then forwarding the RTCP SR message to a second measurement point.

After receiving the RTCP SR message, the second measurement point also extracts the sender information of the RTCP SR message, namely the sender information comprises the synchronous source identification of the sender and the number of the sent messages; or the sender synchronizes the source identification, the number of the sent messages and the network time protocol timestamp, and calculates the local QoS performance parameters of the RTP data stream; generating an extra RTCP RR message while forwarding the RTCP SR message, wherein the extra RTCP RR message comprises a sender synchronous source identifier, a locally calculated QoS parameter, a network time protocol timestamp LSR when the sender generates the RTCP SR message, a time DLSR spent on generating the extra RTCP RR message, and sending the extra RTCP RR message; and meanwhile, the end-to-end RTP/RTCPSR message is forwarded normally.

And after the first measuring point receives the extra RTCP RR message, extracting sender information in the extra RTCP RR message, matching the sender information with locally stored sender information, and if the sender information can be matched, calculating a QoS parameter between the local second measuring point and the second measuring point sending the extra RTCP RR message. That is, the sender synchronization source identifier in the RTCP RR message is extracted first; or the sender synchronizes the source identification and the network time protocol timestamp; then synchronizing the source identification with the sender; or the QoS parameter information stored before is searched by taking the synchronous source identification of the sender and the network time protocol timestamp as indexes, and the QoS performance condition of the RTP stream between the first measuring point and the second measuring point is obtained through comparison calculation, so that the QoS measurement between the network segments is realized.

In order to facilitate the understanding of those skilled in the art, the following description is given in conjunction with specific embodiments.

Please refer to fig. 4, which is an application scenario of measuring qos between network segments according to an embodiment of the present invention. In this embodiment, four measurement points are preset between network segments, and belong to the same service providing domain, and the embodiment takes the case where data flows pass through the measurement point (Monitor)1 and the Monitor3 as an example. As shown in FIG. 4, includes a source user equipment (Sender CPE-A)41, a measurement point (Monitor1)42, a measurement point (Monitor2)43, a measurement point (Monitor3)44, a measurement point (Monitor4)45, and a sink user equipment 46 (receiverCPE-B). The specific process comprises the following steps:

the source CPE-A41 sends RTP/RTCP SR packets to the sink CPE-B46. According to the protocol, the RTP message is continuously sent, the RTCP SR message is periodically sent, the sending period can be 5 seconds or 6 seconds, and the two messages are multiplexed and transmitted in a transmission layer. When the RTP/RTCP SR messages pass through two measurement points Monitor1 and Monitor3 of a service providing domain (SP), the measurement points at different positions execute different operations to realize network segment-based measurement. The detailed processing for the measurement points is shown in detail in fig. 5. In the measuring process, if two measuring points are set in the service providing domain, the mode of sending the RTCP RR message is multicast or unicast; if at least two measuring points are set in the service providing domain, the mode of sending the RTCP RR messages is unicast.

If the extra RTCP RR message is sent by adopting a multicast mode, a set multicast IP address and a set port number are informed in advance when a measuring point is configured; if the extra RTCP RR message is sent in a unicast mode, the IP address and the port number of the first measuring point are informed in advance when the second measuring point is configured.

Please refer to fig. 5, which is a flowchart illustrating the measurement point based on RTP/RTCP channel measurement according to an embodiment of the present invention. In this embodiment, measurement points belonging to the same SP need to join the same multicast group, and the RTCP protocol occupies the same port number in the SP domain, and the second measurement point feeds back an extra RTCP RR packet in a multicast and/or unicast manner in the SP domain. In this embodiment, a source CPE-a sends an RTP/RTCP SR data stream to a sink CPE-B, and the RTP/RTCP SR data stream passes through 2 measurement points Monitor1 and Monitor3 in an SP domain, where the two measurement points respectively correspond to an entry and an exit of an RTP service, and the specific process includes:

step 501, a source CPE-A sends out an RTP/RTCP SR message;

step 502 and step 503, recording the number of RTP messages and the like; when the Monitor1 and the Monitor3 receive the RTP message in sequence, the two measuring points operate the same and trigger the measuring points to carry out statistics and calculation; extracting a sequence number from the RTP message for calculating the packet loss rate; extracting the time stamp for calculating the transmission delay and the delay jitter;

step 504 (which can be performed in parallel with step 503) is that when the Monitor1 receives the RTCP SR message corresponding to the RTP data stream first, the arrival time A1 of the RTCP SR message is recorded, and the sender information in the header field of the RTCP SR message is extracted, wherein the sender information comprises sender synchronization source identification and the number of sent messages; or the synchronous source identification of the sending party, the network time protocol timestamp, the number of sent messages and the like. And according to the number of the sent messages, calculating the QoS parameter information of the RTP data stream between the two RTCP SR messages reaching the local, wherein the QoS parameter information comprises a packet loss rate Frac1, a cumulative packet loss number Cul _ num1 from the sending to the present and a delay jitter J1, and the calculation formulas are respectively as follows:

the packet loss Frac1 is the packet loss number lost _ interval/Expected received message number Expected _ interval within the interval;

the cumulative number of lost packets cui _ num1 is the Expected value Expected-actual value Received;

j1(i) ═ J1(i-1) + (| D (i-1, i) | -J1(i-1))/16, i represents the ith RTCP SR message received by the measurement point, and D represents the delay difference between the two previous and next messages reaching the measurement point;

then, the already calculated delay jitter J1 is combined to obtain the SSRC of CPE-a; or the SSRC of CPE-A and the network time protocol timestamp LSR, stores QoS information for the index.

And 505, the Monitor1 continuously forwards the end-to-end RTCP SR messages.

Step 506, when the Monitor3 receives the corresponding RTCP SR message, extracting the sender synchronization source identification of the RTCP SR message, and calculating the QoS parameter of the local arrival of the RTP data stream, wherein the calculation process is similar to that in step 504, namely, the arrival time A2 of the RTCP SR message is recorded, and the sender information in the header field of the RTCP SR message is extracted, and the sender information comprises the sender synchronization source identification and the number of the sent messages; or the synchronous source identification of the sending party, the network time protocol timestamp, the number of sent messages and the like. And according to the time of the number of the sent messages, calculating the QoS parameter information of the RTP data stream between the two RTCP SR messages reaching the local, wherein the QoS parameter information comprises the packet loss rate Frac2, the accumulated packet loss number Cul _ num2 from the sending to the present and the delay jitter J2. The formula of the calculation is detailed above, and is not described herein again. After the calculation of the QoS parameter information of the RTP data stream arriving at the local is completed, the RTP and RTCP SR messages are forwarded normally, and an extra RTCP RR message is generated or constructed at the same time, wherein the extra RTCP RR message comprises a sender synchronization source identifier, a locally calculated QoS parameter, a network time protocol timestamp LSR when the sender generates the RTCP SR message and time DLSR spent on constructing the extra message. That is, the sender synchronization source identification in the reception report of the extra RTCP RR message fills in the CPE-a SSRC, indicating that this is the QoS statistic for the RTP message sent by CPE-a. The LSR in the reception report fills the network time protocol timestamp in the RTCP SR message, indicating that the extra RTCP RR message is for this RTCP SR message.

And 507, sending the extra RTCP RR message in the SP domain in a multicast or direct unicast mode. For this embodiment, Monitor3 multicasts or directly unicasts the extra RTCP RR packet to Monitor 1. If a multicast mode is adopted, the multicast IP address and the port number are determined by the SP domain and are informed in advance when a measuring point is configured; if the unicast mode is adopted, the IP address and the listening port number of the first measurement point Monitor1 also need to be issued when the second measurement point Monitor3 is configured.

And step 508, the Monitor3 continuously forwards the end-to-end RTCP SR messages.

Step 509, when other measuring points in the SP domain receive the extra RTCP RR messages sent by the Monitor3, extracting a synchronous source identification CPE-A SSRC of a receiving report in the extra RTCP RR messages, matching the synchronous source identification CPE-A SSRC with a local record, if the synchronous source identification CPE-A SSRC is matched with the local record, processing the extra RTCP RR messages, and discarding other measuring points; and then extracting an LSR field in the message, and finding the corresponding QoS parameter by matching the stored network time protocol timestamp by the LSR. For this embodiment, only Monitor1 is matched with the synchronization source id in the extra RTCP RR message.

For this embodiment, when the Monitor1 receives the extra RTCP RR packet, the arrival time A3 of the extra RTCP RR packet is recorded, the QoS parameter in the extra RTCP RR packet is extracted, and compared with the QoS performance parameter calculated and stored before the measurement point, the network layer QoS transmission performance of the RTP packet between the Monitor1 and the Monitor3 is calculated, including the packet loss rate (Frac2-Frac1), the cumulative packet loss number (cui _ num 2-cui _ num1), the delay jitter (J2-J1), and the RTT (A3-a1-DLSR) during the RTCP sending period.

Step 510, after receiving the RTCP SR message forwarded by Monitor3, the host CPE-B calculates the end-to-end QoS parameter and generates an end-to-end RTCP RR message; wherein steps 509 and 510 are not chronologically ordered.

And 511, the host CPE-B feeds back the end-to-end RTCP RR message to the source CPE-A.

In addition, a plurality of measurement points may be provided between the source user equipment and the sink user equipment, and the second measurement point may send the extra RTCP RR packet in a unicast mode or in a multicast mode.

For easy understanding, please refer to fig. 6, which is a diagram illustrating another application scenario for measuring qos between network segments according to an embodiment of the present invention. Comprises a source end user device (Sender CPE-A)61, a measuring point (Monitor1)62, a measuring point (Monitor2)63, a measuring point (Monitor3) 64, a measuring point (Monitor4)65, a measuring point (Monitor 5)66, a sink end user device 67(Receiver CPE-B) and a centralized control unit 68. The specific process is similar to that of FIG. 4, except that the RTP data stream passes through three measurement points, namely Monitor1, Monitor2 and Monitor3, or more, in the same service providing domain; when the second measurement point (for example, Monitor3) forwards the RTCP SR message, an extra RTCP RR message is generated, and the extra RTCP RR message is sent to the first measurement point (for example, Monitor2), which may be a unicast mode or a multicast mode. That is to say. Before the second measurement point sends the extra RTCP RR message in a unicast manner, the second measurement point may know the location (IP address) of the first measurement point in advance by a method of configuring the measurement point by the centralized control unit. One general method is as follows:

after the measurement point is electrified, the measurement point is registered to the control plane, and the control plane stores the existing network topology information. When an RTP stream needs to be measured, the control plane matches the measuring points with the paths passed by the stream, and finds the measuring points passed by the stream and the sequence of the passing. Then configuring the measurement point to start the measurement of the flow and informing the second measurement point of the information of the first measurement point so that the second measurement point can feed back the extra RTCP RR message.

Please refer to fig. 7, which is a flowchart illustrating measurement points based on RTP/RTCP channel measurements according to another embodiment of the present invention. In this embodiment, taking three measurement points Monitor1, Monitor2 and Monitor3 set in the service providing domain (SP) where RTP/RTCP SR messages flow, when it is required to measure the QoS performance of one RTP stream in a certain network segment, the control entity sets the measurement points in the network segment in the SP domain in advance, and informs the IP address of the first measurement point when configuring the second measurement point. And two measuring points are arranged among the three measuring points and respectively correspond to the inlet and the outlet of the RTP service. The implementation process is similar to that of fig. 4, but the difference is that a unicast mode is adopted when the extra RTCP RR message is sent. The specific implementation steps comprise:

step 701, a source end CPE-A sends out an RTP/RTCP SR message;

step 702, step 703 and step 704, when Monitor1, Monitor2 and Monitor3 receive the RTP message in sequence, the three measurement points operate the same, and all trigger the measurement points to perform statistics and calculation.

Step 705 (which may be parallel to steps 703 and 704), when the Monitor1 receives the RTCP SR message corresponding to the RTP data stream first, recording an arrival time a1 of the RTCP SR message, and extracting sender information in a header field of the RTCP SR message, wherein the sender information includes a sender synchronization source identifier and a number of sent messages; or the sender synchronization source identifier, the network time protocol timestamp and the number of sent messages, and calculates the QoS parameter information of the RTP data stream arriving locally, including the packet loss rate Frac1, the cumulative packet loss number cui _ num1 from sending to the present, and the delay jitter J1, and the calculation formula is described in detail above and will not be described herein again. SSRC of CPE-A; or the SSRC of the CPE-A and the network time protocol timestamp are used as indexes to store QoS information;

step 706, Monitor node1 continues to forward the RTP/RTCP SR message from end to end;

step 707, similar to step 506, that is, when the Monitor node 2 receives the corresponding RTCP SR message, the arrival time a2 of the RTCP SR message is recorded, and the sender information in the RTCP SR message is extracted, wherein the sender information includes a sender synchronization source identifier and a number of sent messages; or the sender synchronizing source identifier, the number of sent messages and the network time protocol timestamp, and calculates the QoS parameters of the local arrival of the RTP data stream, where the QoS parameters include a packet loss rate Frac2, an accumulated packet loss number cui _ num2 and a delay jitter J2, and the calculation process is similar to that in step 506 and is not described herein again;

after the calculation of the QoS parameter information of the RTP data stream arriving at the local is completed, the RTP and RTCP SR messages are forwarded normally, and an extra RTCP RR message is generated or constructed at the same time, wherein the extra RTCP RR message comprises a sender synchronization source identifier, a calculated local QoS parameter, a network time protocol timestamp LSR when the sender generates the RTCP SR message, and time DLSR spent on constructing the extra message. That is, the sender synchronization source identifier in the reception report of the extra RTCP RR message fills in the CPE-ASSRC, indicating that this is the QoS statistic for the RTP message sent by CPE-a. The LSR in the reception report fills in the network time protocol timestamp indicating that the extra RTCP RR message is for this RTCP SR message.

Step 708, similar to step 507, the difference is that the manner of sending the extra RTCPRR message in the SP domain may be unicast. That is, Monitor2 directly unicasts the extra RTCP RR packet to Monitor1, and the unicast IP address and port number of Monitor2 already notify Monitor1 of the IP address and port number.

And 709, similar to the step 509, when the Monitor1 receives the extra RTCP RR message directly unicast by the Monitor2, extracting the synchronization source identifier CPE-A SSRC of the receiving report in the extra RTCP RR message and the network time protocol timestamp LSR when the CPE-A generates the RTCP SR message, matching the synchronization source identifier CPE-A SSRC with the local record, and processing the extra RTCP RR message if the synchronization source identifier CPE-A SSRC is matched with the local record. Namely:

recording the arrival time A3 of the extra RTCP RR message, extracting QoS parameters in the extra RTCP RR message, comparing the QoS parameters with QoS performance parameters calculated and stored before the measurement point, and calculating the network layer QoS transmission performance of the RTP message between Monitor1 and Monitor2, wherein the network layer QoS transmission performance comprises the packet loss rate (Frac2-Frac1), the accumulated packet loss number (Cul _ num2-Cul _ num1), the delay jitter (J2-J1), RTT (A3-A1-DLSR) and the like during the RTCP sending period;

step 710, the Monitor2 forwards the RTCP SR message;

step 711, similar to step 506, when the Monitor3 receives the corresponding RTCP SR message, recording the arrival time A4 of the RTCP SR message, and extracting the sender synchronization source identification and the number of the sent messages of the RTCP SR message; or the sender synchronization source identification, the number of sent messages and the network time protocol timestamp, and calculating the QoS parameters of the RTP data stream arriving at the local, wherein the QoS parameters comprise a packet loss rate Frac3, a cumulative packet loss number Cul _ num3 and a delay jitter J3, and the calculation process is similar to that in step 506 and is not described herein again;

after the calculation of the QoS parameter information of the RTP data stream arriving at the local is completed, the RTP and RTCP SR messages are forwarded normally, and an extra RTCP RR message is generated or constructed at the same time, wherein the extra RTCP RR message comprises a sender synchronization source identifier, a calculated local QoS parameter, a network time protocol timestamp LSR when the sender generates the RTCP SR message, and time DLSR spent on constructing the extra message. That is, the sender synchronization source identifier in the reception report of the extra RTCP RR message fills in the CPE-ASSRC, indicating that this is the QoS statistic for the RTP message sent by CPE-a. The LSR in the reception report fills in the network time protocol timestamp, indicating that the extra RTCP RR message is for this RTCP SR message.

It should be noted that steps 708 and 709 are not chronologically sequential to steps 710 and 711.

Step 712 is similar to step 507, except that the manner of sending the extra RTCPRR message in the SP domain is unicast. That is, Monitor3 directly unicasts the extra RTCP RR packet to Monitor2, and the unicast IP address and port number of Monitor3 are already informed of the IP address and port number of Monitor2 when configuring the second measurement point Monitor 3.

Step 713, similar to step 509, when the Monitor2 receives the extra RTCP RR packet directly unicast by the Monitor3, extracting a synchronization source identifier CPE-A SSRC of a receiving report in the extra RTCP RR packet; or the synchronization source identification CPE-ASSRC of the receiving report in the extra RTCP RR message and the network time protocol timestamp LSR when the sender generates the RTCP SR message, and the synchronization source identification CPE-A SSRC; or the synchronization source identifiers CPE-A SSRC and LSR are respectively matched with the local records, and if the synchronization source identifiers CPE-A SSRC and LSR are matched with the local records, the extra RTCP RR messages are processed. Namely:

recording the arrival time A5 of the extra RTCP RR message, extracting QoS parameters in the extra RTCP RR message, comparing the QoS parameters with QoS performance parameters calculated and stored before the measurement point, and calculating the network layer QoS transmission performance of the RTP message between Monitor2 and Monitor3, wherein the network layer QoS transmission performance comprises the packet loss rate (Frac3-Frac2), the accumulated packet loss number (Cul _ num3-Cul _ num2), the delay jitter (J3-J2), the RTT and the like (A5-A2-DLSR).

Step 714, Monitor3 forwards the RTCP SR message;

step 715, after receiving the extra RTCP SR message forwarded by Monitor3, the host CPE-B calculates the end-to-end QoS parameter and generates an end-to-end RTCP RR message;

it should be noted that steps 712 and 713 are not chronologically sequential to steps 714 and 715.

And 716, the host CPE-B feeds back the RTCPRR message to the source CPE-A.

As can be seen from the technical solutions disclosed in fig. 5 and fig. 7, the number of measurement points is different, and the manner of sending and generating the extraRTCP SR message is also different. In view of the optimization scheme, if two measurement points are set in the service providing domain, the extra RTCP SR messages may be sent in a unicast or multicast manner, and if three or more measurement points are set, the extra RTCP SR messages may be sent in a unicast manner.

In addition, an embodiment of the present invention further provides a method for measuring quality of service, where a flow chart of the method is shown in fig. 8, and the method includes the steps of:

step 801, a first measuring point calculates and stores a local QoS (quality of service) parameter of an RTP (real-time transport protocol) data stream according to an RTCP SR (real-time control protocol) report message of a sender in a real-time control protocol corresponding to the RTP data stream, and then forwards the RTCP SR message to a second measuring point;

step 802, when the second measurement point forwards the RTCP SR message, a receiver report extra RTCP RR message in an extra real-time control protocol is generated, and the extra RTCP RR message is sent in a service providing domain;

and 803, the first measurement point calculates the QoS parameter between the local and the second measurement point according to the received extra RTCP RR message.

When a first measuring point receives a sender report RTCP SR message in a real-time control protocol corresponding to an RTP data stream, extracting sender information in the corresponding RTCP SR message, wherein the sender information comprises a sender synchronization source identifier and a sender message number; or the synchronous source identification of the sender, the network time protocol timestamp and the number of the sent messages; calculating the QoS parameter of the RTP data stream arriving at the local, and identifying and sending message number by the synchronous source of the sender; or the synchronous source identification of the sending party, the network time protocol timestamp and the number of the sent messages are used as indexes to store the QoS parameters of the RTP data stream arriving at the local. Then forwarding the RTCP SR message to a second measurement point;

when a second measuring point receives the RTCP SR message, the QoS parameters of the RTP data stream arriving at the local are calculated and stored, wherein the QoS parameters comprise packet loss rate and accumulated packet loss number; then generating an extra RTCP RR message while forwarding the RTCP SR message, and sending the extra RTCP RR message in a service providing domain, wherein the extra RTCP RR message comprises a sender synchronous source identifier, a locally calculated QoS parameter, a network time protocol timestamp LSR when the sender generates the RTCP SR message, and a time DLSR consumed for generating the extra RTCP RR message;

the method for sending the extra RTCP RR messages in the service providing domain comprises multicast or unicast, if two measuring points are arranged, multicast or unicast can be adopted; if three or more measurement points are provided, unicast transmission is preferably used.

When a first measuring point receives the extra RTCP RR message, extracting sender information in the extra RTCP RR message, and judging whether the sender information in the extra RTCP RR message is matched with locally stored sender information; and if the two measurement points are matched, taking out a stored QoS parameter corresponding to the synchronous source identification of the sender, and comparing the QoS parameter with the QoS parameter in the extra RTCP RR message to obtain the QoS parameter between the two measurement points.

In addition, an embodiment of the present invention further provides a network device, and a schematic structural diagram of the network device is shown in fig. 9. The network device comprises a first message sending unit 91, a message receiving unit 92 and a network segment service quality calculating unit 93. The first message sending unit 91 is configured to send the received RTCP SR message to the second measurement point; the message receiving unit 92 is configured to receive an extra RTCP RR message sent by the second measurement point; and the segment QoS calculating unit 93 is configured to calculate a QoS parameter between a local node and the second measurement point according to the extra RTCP RR packet.

Preferably, the network device further comprises a first quality of service calculation unit and a first storage unit. The first quality of service calculation unit is configured to extract a sender synchronization source identifier and a number of sent messages in an RTCPSR message corresponding to a received RTP data stream; or the synchronous source identification of the sender, the network time protocol timestamp and the number of the sent messages; and calculating the QoS parameter of the RTP data stream arriving locally. That is, when a first service quality calculation unit receives an RTP/RTCP SR message, a sequence number, a timestamp and the arrival local time of the corresponding RTCP SR message in the RTP message are recorded, and sender information in a header field of the RTCP SR message is extracted, wherein the sender information comprises a sender synchronization source identifier and a sender message number; or the synchronous source identification of the sender, the network time protocol time stamp LSR and the number of the sent messages; and then, calculating the QoS parameter of the RTP data stream between the adjacent RTCP SR messages reaching the local according to the received RTP message serial number, the timestamp and the sender information in the RTCP SR messages.

A first storage unit, configured to synchronize a source identifier according to the sender; or the sender synchronization source identification and the network time protocol timestamp are used as indexes to store the QoS parameters of the RTP data stream arriving locally.

Preferably, the segment qos calculating unit 93 includes a determining sub-unit 931 and a comparing sub-unit 932. The determining subunit 931 is configured to determine a sender synchronization source identifier in the extra RTCP RR message; or whether the sender synchronization source identification and the network time protocol timestamp of the sender generating the RTCP SR message are matched with the local record or not; the comparing subunit 932 is configured to, when receiving the matching determination result sent by the determining subunit, compare the QoS parameter in the extra RTCP RR message with the local QoS parameter, to obtain the quality of service between the measurement points.

In addition, the implementation of the present invention further provides a network device, and a schematic structural diagram thereof is shown in fig. 10. The network device comprises a message generating unit 101 and a second message sending unit 102. The message generating unit 101 is configured to generate an extra RTCP RR message when forwarding the received RTCP SR message, where the extra RTCP RR message includes a sender synchronization source identifier, a locally calculated QoS parameter, and a network time protocol timestamp when the sender generates the RTCP SR message; the second packet sending unit 102 is configured to send the RTCP RR packet in a service providing domain, so as to calculate the quality of service between the measurement points.

Preferably, the network device further comprises a second quality of service calculation unit and a second storage unit. The second service quality calculating unit is used for extracting a sender synchronization source identifier and a sending message number of the RTCP SR message when receiving the RTCP SR message corresponding to the RTP data stream; or the sender synchronizing source identification, the network time protocol timestamp and the number of the sent messages, and forwards the RTCP SR messages after calculating and storing the QoS parameters of the RTP data stream reaching the local; the second storage unit is used for synchronizing the source identifier according to the sender; or the synchronous source identification of the sending party and the network time protocol timestamp are used as indexes to store the local QoS parameters.

Preferably, the second packet sending unit 102 includes at least one of a unicast sending subunit 1021 and a multicast sending subunit 1022. The unicast sending subunit 1021 is configured to send the extra RTCP RR packet when at least two measurement points are set in a service providing domain; the multicast sending subunit 1022 is configured to send the extra rtcp rr message when two measurement points are set in the service providing domain.

Preferably, the network device further comprises a centralized control unit, configured to control a manner of sending an extra RTCP RR packet, and when sending an extra RTCP RR packet in a multicast manner, pre-notify a set multicast IP address and port number when configuring a measurement point; or, when the extraRTCP RR message is sent in a unicast manner, the IP address and the port number of the first measurement point are notified in advance when the second measurement point is configured.

It should be noted that the network device is described in fig. 9 and fig. 10. When the network equipment comprises a first service quality calculating unit, a message receiving unit and a network segment service quality calculating unit, the network equipment provides a first measuring point on a path for an RTP flow in a domain for a service.

When the network equipment comprises a first service quality calculation unit, a message generation unit, a message sending unit, a message receiving unit and a network segment service quality calculation unit, the network equipment provides an intermediate measurement point on a path for an RTP flow in a domain for a service.

When the network equipment comprises a second service quality calculation unit, a message generation unit and a message sending unit, the network equipment provides the last measurement point on the RTP flow passing path in the domain for the service.

In addition, an embodiment of the present invention further provides a network system, and a schematic structural diagram of the network system is shown in fig. 11. The system comprises a first network device 111 and a second network device 112, wherein the first network device 111 comprises a first message sending unit 1111, a message receiving unit 1112 and a network segment service quality calculating unit 1113. The first packet sending unit 1111 is configured to send the received RTCP SR packet to a second measurement point; the message receiving unit 1112 is configured to receive an extraRTCP RR message sent by a second measurement point; the segment QoS calculating unit 1113 is configured to calculate a QoS parameter between the local node and the second measurement point according to the extra RTCPRR packet.

The second network device 112 includes a message generating unit 1121 and a second message sending unit 1122. The message generating unit 1121 is configured to generate an extra RTCP RR message when forwarding the received RTCP SR message, where the extra RTCP RR message includes a sender synchronization source identifier, a locally calculated QoS parameter, and a network time protocol timestamp when the sender generates the RTCP SR message; the second packet sending unit 1122 is configured to send the extra RTCP RR packet to a packet receiving unit in a service providing domain, so as to calculate a service quality between measurement points.

Preferably, the first network device comprises a first service quality calculation unit, a first storage unit; the second network device includes a second quality of service calculation unit and a second storage unit. The first or second service quality calculating unit is used for extracting a sender synchronization source identifier and a sending message number of an RTCP SR message when the RTCP SR message corresponding to the RTP data stream is received; or the sender synchronizing source identification, the network time protocol timestamp and the number of the sent messages, and forwards the RTCP SR messages after calculating and storing the QoS parameters of the RTP data stream reaching the local; the first or second storage unit is used for synchronizing the source identifier according to the sender; or the synchronous source identification of the sending party and the network time protocol timestamp are used as indexes to store the local QoS parameters.

For this embodiment, the specific implementation process is as follows:

for a certain determined RTP data stream, monitoring the information that the RTP data stream reaches the local, when an RTCP SR message corresponding to the RTP data stream reaches a first service quality calculating unit, the first service quality calculating unit extracts a sender synchronization source identifier and a sender message number of the RTCP SR message; or RTCP

The method comprises the steps that a sender synchronization source identification, a sender message number and a network time protocol timestamp of an SR message are calculated, and QoS parameters of the RTP data stream reaching the local are stored, wherein the QoS parameters comprise packet loss rate, accumulated packet loss rate, delay jitter and the like; and then the RTCP SR message is forwarded to a second service quality calculation unit through a first message sending unit. The second QoS calculating unit is similar to the QoS parameter calculating process of the first QoS calculating unit, namely, the second QoS calculating unit calculates the QoS parameter of the RTP data stream reaching the local according to the received RTCP SR message and forwards the RTCP SR message to the message generating unit; the message generating unit generates an extra RTCP RR message when forwarding the received RTCP SR message, wherein the extra RTCP RR message comprises a sender synchronous source identifier and a local QoS parameter, a network time protocol timestamp when the sender generates the RTCP SR message and the time spent on generating the extra RTCP RR message, and forwards the extra RTCP RR message to a second message sending unit; the second packet sending unit multicasts or unicasts the RTCP RR packet to a packet receiving unit, the packet receiving unit receives the extra RTCP RR packet and forwards the extra RTCP RR packet to a segment service quality calculating unit, and the segment service quality calculating unit 83 calculates a QoS parameter between the first measuring point and the second measuring point according to the extra RTCP RR packet. The specific implementation process is detailed in the specific implementation process of the method, and is not described herein again.

Therefore, the embodiment of the invention can multicast the extra RTCP RR messages generated by the feedback of the second measuring point in the SP range to calculate the QoS parameters between the measuring points. The information needed for the transport layer and network layer encapsulation is known. The measurement point does not need to know the IP address or the port information of the first measurement point through which the RTP/RTCP SR message flow passes, thereby simplifying the configuration preparation work before measurement and also simplifying the control of the measurement point.

When the RTT is calculated at the first measuring point, at least the unilateral path is the same as the RTP message, and the accuracy of the time delay is higher than that of the active measurement. When the measuring point stores and forwards the end-to-end RTP/RTCP message, only one type of message of extra RTCP RR needs to be generated, and multicast or unicast is directly carried out in the SP domain. Compared with active measurement, the requirement of processing additional RTCP messages by the measurement point is simplified.

The second measuring point feeds back QoS information to the first measuring point, and the first measuring point can calculate the QoS performance of the RTP message between the two measuring points according to the receiving report, so that the measuring points can measure based on network segments, and the calculation workload of the centralized control entity is reduced.

In addition, by using the technical solution of the embodiment of the present invention, the data stream of the RTP can be routinely checked, and if a measurement point at a certain position fails to send a fault, the scheme can be used to roughly position the data stream. When the end-to-end RTP traffic passes through a certain SP, the SP configures the measurement points for monitoring the RTP traffic to be distributed at the edge of the domain as much as possible, that is, the place where the RTP packet enters the domain and the place where the RTP packet leaves the domain. And the RTP service may not distribute or less distribute the measurement points on the path traveled by the domain. The embodiment of the invention sets measuring points at the entrance and the exit of an RTP service domain, and exchanges extra RTCP RR messages between the measuring points to firstly judge the quality condition of the RTP service in the SP range. If the quality is degraded, the problem can be located more accurately in conjunction with other methods.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be construed as the protection scope of the present invention.

Claims

1. A method of measuring quality of service, comprising the steps of:

the method comprises the steps that a first measuring point calculates and stores a local QoS (quality of service) parameter of an RTP (real-time protocol) data stream according to an RTCP SR (real-time control protocol) report message of a sender in a real-time control protocol corresponding to the RTP data stream, and then forwards the RTCP SR message to a second measuring point;

2. The method of claim 1, wherein the calculating and storing the QoS parameter of the RTP data stream locally is:

the first measuring point records the local arrival time of the corresponding RTCP SR message and extracts the information of a sender in the RTCP SR message corresponding to the received RTP data stream, wherein the information of the sender comprises a sender synchronous source identifier and the number of the sent messages; or the synchronous source identification of the sender, the network time protocol timestamp and the number of the sent messages;

calculating the QoS parameters of the RTP data stream arriving at the local, wherein the QoS parameters comprise delay jitter, packet loss rate and accumulated packet loss number;

synchronizing a source identification with the sender; or storing the QoS parameter of the RTP data stream arriving locally by using the synchronous source identification of the sender and the network time protocol timestamp as an index.

3. The method according to claim 2, wherein the manner for sending the extra RTCP RR packet in the service providing domain is as follows:

if two measuring points are set in the service providing domain, the extra RTCP RR message is sent to the first measuring point through multicast or unicast;

and if at least three measuring points are arranged in the service providing domain, the extra RTCP RR message is sent to the first measuring point through unicast.

4. A method of measuring quality of service, comprising the steps of:

the first measuring point sends the received RTCP SR message to the second measuring point;

receiving an extra RTCP RR message sent by a second measuring point;

5. The method of measuring quality of service as claimed in claim 1, further comprising:

the first measuring point extracts the information of a sender in an RTCP SR message corresponding to the received RTP data stream; and calculating and storing the QoS parameters of the RTP data stream reaching the local, wherein the QoS parameters comprise delay jitter, packet loss rate and accumulated packet loss number.

6. The method of claim 5, wherein the step of extracting the sender information in the RTCP SR message corresponding to the received RTP data stream comprises:

recording the local arrival time of the corresponding RTCP SR message, and extracting the synchronous source identification of the sender and the number of the sent messages in the message; or sender synchronization source identification, network time protocol timestamp and number of sent messages.

7. The method of claim 6, wherein the source identification is synchronized with the sender; or storing the QoS parameter of the RTP data stream arriving locally by using the synchronous source identification of the sender and the network time protocol timestamp as an index.

8. The method according to claim 4, wherein the step of the first measurement point calculating the QoS parameter between the local measurement point and the second measurement point according to the extra RTCP RR packet comprises:

extracting a sender synchronization source identifier in the extra RTCP RR message by the first measurement point; or the sender synchronization source identification and the network time protocol timestamp when the sender generates the RTCP SR message;

synchronizing a source identification with the sender; or the synchronous source identification of the sender and the network time protocol timestamp of the RTCPSR message generated by the sender are matched to the locally stored QoS parameter as indexes;

and comparing the QoS parameters in the extra RTCP RR messages with the locally stored QoS parameters to obtain the QoS parameters between the measurement points.

9. A method of measuring quality of service, comprising the steps of:

10. The method of claim 9, wherein the generating of the extra RTCP RR message comprises:

putting the locally calculated QoS parameters into corresponding positions of a receiving report block, wherein the QoS parameters comprise delay jitter, packet loss rate and accumulated packet loss number;

filling a sender synchronization source identification SSRC in a receiving report block as a sender synchronization source identification in the RTCP SR message; filling a network time protocol timestamp of a sender generating an RTCP RR message into the network time protocol timestamp in the RTCP SR message;

and the sender identifier in the header of the extra RTCP RR message is the identifier of the measuring point and receives the number of report blocks.

11. The method of claim 9, wherein the sending the extra RTCP RR packet in the service providing domain comprises:

12. The method of measuring service quality according to claim 11, wherein two measurement points are located at an entrance and an exit of a service providing domain; the three measurement points are located at the entrance and exit of a service providing domain, where at least two measurement points are located.

13. The method according to claim 11, wherein if the extra RTCP RR packet is sent in a multicast manner, the method informs a set multicast IP address and a port number for receiving the extra RTCP RR packet in advance when configuring the measurement point; if the extra RTCPRR message is sent in a unicast mode, the IP address of the first measuring point and the port number for receiving the extra RTCPRR message are informed in advance when the second stream measuring point is configured.

14. A network device, comprising:

15. The network device of claim 14, wherein the network device further comprises:

the first service quality calculation unit is used for extracting the synchronous source identification of a sender and the number of the sent messages in the RTCP SR messages corresponding to the received RTP data stream; or the synchronous source identification of the sender, the network time protocol timestamp and the number of the sent messages; calculating the QoS parameters of the RTP data stream arriving at the local, wherein the QoS parameters comprise delay jitter, packet loss rate and accumulated packet loss number;

16. The network device of claim 14, wherein the segment quality of service calculation unit comprises:

a judging subunit, configured to judge a sender synchronization source identifier in the extra RTCP RR message; or whether the sender synchronization source identification and the network time protocol timestamp of the sender generating the RTCP SR message are matched with those stored locally;

and the comparison subunit is used for comparing the QoS parameters in the extra RTCP RR messages with the local QoS parameters to obtain the service quality between the measurement points when receiving the matched judgment result sent by the judgment subunit.

17. A network device, comprising:

18. The network device of claim 17, wherein the network device further comprises:

the second service quality calculation unit is used for extracting the synchronous source identification of the sender and the number of the sent messages of the RTCP SR messages when receiving the RTCP SR messages corresponding to the RTP data streams; or the sender synchronizing source identification, the network time protocol timestamp and the number of the sent messages, and forwards the RTCP SR messages after calculating and storing the QoS parameters of the RTP data stream reaching the local;

the second storage unit is used for synchronizing the source identification according to the sender; or the synchronous source identification of the sending party and the network time protocol timestamp are used as indexes to store the local QoS parameters.

19. The network device according to claim 17 or 18, wherein the second messaging unit comprises at least one of:

a unicast sending subunit, configured to send the extra RTCP RR packet when at least two measurement points are set in the service providing domain;

and the multicast sending subunit is configured to send the extraRTCP RR packet when two measurement points are set in the service providing domain.

20. The network device of claim 17, wherein the network device further comprises:

the centralized control unit is used for controlling the mode of sending the extra RTCP RR messages, and when the extra RTCP RR messages are sent in a multicast mode, the set multicast IP address and the set port number are informed in advance when the measuring points are configured; or, when the extra RTCP RR message is sent in a unicast manner, the IP address and the port number of the first measurement point are notified in advance when the second measurement point is configured.

21. A network system includes a first network device and a second network device, wherein,

the first network device includes:

the second network device includes:

22. The network system according to claim 21, wherein the first network device further comprises a first QoS calculating unit and a first storage unit, and the second network device further comprises a second QoS calculating unit and a second storage unit; wherein,

the first or second service quality calculating unit is used for extracting the sender synchronization source identification and the number of the sent messages of the RTCP SR messages when receiving the RTCP SR messages corresponding to the RTP data streams; or the sender synchronizing source identification, the network time protocol timestamp and the number of the sent messages, and forwards the RTCP SR messages after calculating and storing the QoS parameters of the RTP data stream reaching the local;

the first or second storage unit is used for synchronizing the source identifier according to the sender; or the synchronous source identification of the sending party and the network time protocol timestamp are used as indexes to store the local QoS parameters.