CN102223675A

CN102223675A - Method, system and equipment for alarming and processing congestion

Info

Publication number: CN102223675A
Application number: CN2011101517257A
Authority: CN
Inventors: 刘满朝; 张晓奎; 杨勇; 张卫国
Original assignee: Datang Mobile Communications Equipment Co Ltd
Current assignee: Datang Mobile Communications Equipment Co Ltd
Priority date: 2011-06-08
Filing date: 2011-06-08
Publication date: 2011-10-19
Anticipated expiration: 2031-06-08
Also published as: CN102223675B

Abstract

The embodiment of the invention discloses a method, a system and equipment for alarming and processing congestion, and relates to the technical field of wireless communication. The method, the system and the equipment are used for relieving the congestion state at a data receiving terminal. In the invention, the data receiving terminal in a data congestion state transmits an alarming message that the data receiving terminal is in the congestion state to a data transmitting terminal; and the data transmitting terminal adjusts lost packet control parameters of a sent message buffer queue in the data transmitting terminal according to the alarming message, so that the lost packet probability of the selected queue is increased, and the selected queue is subjected to lost packet control according to the adjusted lost packet control parameters. In the invention, the lost packet control parameters of the sent message buffer queue are adjusted at the data transmitting terminal to ensure that the lost packet probability of the data transmitting terminal is increased, so that the data packets transmitted to the data transmitting terminal are reduced; therefore, the congestion state at the data receiving terminal is effectively relieved.

Description

Congestion warning and processing method, system and equipment

Technical Field

The present invention relates to the field of wireless communications, and in particular, to a method, a system, and a device for congestion warning and processing.

Background

With the rapid development of wireless communication technology, services provided by wireless network communication gradually evolve from traditional voice services to diversified data services and multimedia services, the scale application of 3G wireless access networks is expanded to be about to be used in 4G Long Term Evolution (LTE) core networks, the bandwidth demand on transmission networks is also multiplied, and mobile access and bearer networks need to face the transition from a transmission mode based on circuit switching to an IP bearer network characterized by packet switching and evolve towards an all-IP bearer network to improve the utilization efficiency of transmission resources and meet higher and higher bandwidth requirements. Due to the packet statistical multiplexing characteristics of the IP bearer network, the diversity of the Service types of the mobile bearer network, and the complexity of mobile communication, it is necessary to improve the Quality of Service (QOS) congestion management technique to ensure the Quality of Service of various services. QOS is aimed at providing different quality of service to various services for their different requirements, such as: the method provides special bandwidth, reduces message loss rate, message transmission delay, delay jitter and the like, and simultaneously provides a congestion control and congestion avoidance mechanism to maintain the performance requirements of high throughput and low delay of the network. The architecture of IP QoS has an integrated service model (IntServ) and a differentiated service model (DiffServ). The DiffServ model has good expandability and simple implementation, conforms to the connectionless characteristic of an IP network, and is the mainstream IP QOS solution at present. The congestion management of QOS is one of the core mechanisms for ensuring the realization of DiffServ, and is an effective means for solving the problem of resource competition and sharing of a plurality of services.

The congestion management techniques mainly applied at present include the following two:

first, IEEE802.3X-based data link layer hardware flow control;

the network node monitors the receiving or sending buffer area of the local terminal, and when the buffer area overflows or exceeds the set threshold value, a pause (pause) frame is sent to the information source to indicate the information source to pause the sending of the data until the congestion of the local terminal is relieved, and the information source stops sending all the grouped data.

Second, QOS congestion management based on the DifferServ model.

The congestion management generally adopts a queue technology, which uses a classification algorithm to classify and enqueue traffic, then uses a queue priority algorithm to classify all received packets, buffers the packets into different queues, and then takes out the packets from the queues according to a certain scheduling strategy and sends the packets out from an interface. The congestion control and management are carried out by using a queue technology, and the basic idea is as follows: the method comprises the steps of classifying the arrived messages according to a certain rule, entering different queues, when congestion occurs, formulating a resource scheduling strategy, determining the forwarding sequence of the messages, and discarding some messages through a congestion avoidance mechanism so as to avoid the occurrence of congestion and the continuous deterioration of network performance. Typical Queuing techniques include first-in first-out Queuing (FIFO), strict Priority Queuing (PQ), Custom Queuing (CQ), Weighted Fair Queuing (WFQ), Real-Time Protocol (RTP) Priority Queuing (Priority Queuing), and the like; congestion avoidance mechanisms currently include: tail drop (drop tail), random early detection (Red) and weighted random early detection (Wred).

The four queuing techniques mentioned above are described separately below:

first, a priority queue;

the PQ mechanism is as follows:

the design is aimed at critical traffic applications, namely critical traffic is required to be preferentially served when congestion occurs so as to reduce response delay. The PQ mechanism can flexibly specify the priority according to the network protocol (such as ip, ipx), the data ingress interface, the length of the packet, the source/destination address, etc. The PQ mechanism divides queues into 4 classes, high priority (top), medium priority (middle), normal priority (normal), and low priority (bottom) queues, which are lower in priority. By default, the default data flow enters the normal queue.

Secondly, customizing the queue;

the CQ mechanism is as follows:

classifying according to conditions of priority/DSCP, quintuple and the like of the IP message, and dividing the queues into at most 17 types, wherein the number of the queues is 0-16, and the queue 0 is a system queue and is not allowed to be configured by a user; queues # 1 through 16 are user queues. The user can configure the rule of flow classification, and specify the proportional relation of the interface bandwidth occupied by the 16 user queues. When the queues are scheduled, the packets in the system queues are sent preferentially. And until the system queue is empty, sequentially taking out a certain number of packets from the number 1 to 16 user queues according to a preset bandwidth proportion in a polling mode and sending the packets. Therefore, different bandwidths can be obtained for the packets of different services, so that more bandwidths can be obtained for the critical services, and the bandwidths cannot be obtained for the non-critical services. By default, the default data flow enters queue number 1.

A weighted fair queue;

the WFQ mechanism increases the consideration of priority when calculating the scheduling order of the messages, the weight value depends on the IP priority carried in the IP message header, and the WFQ mechanism ensures that the scheduling opportunity of the messages with high priority is more than that of the messages with low priority. The scheduling of different queues can be balanced during congestion sending, the fair scheduling of short messages and long messages is considered, and the delay and delay jitter of each flow are balanced on the whole. The WFQ mechanism is capable of automatically classifying flows according to session information of the flows (including protocol type, source Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) port number, destination TCP/UDP port number, source IP address, destination IP address, priority bits in the tos domain, etc.), and provides queues as many as possible to evenly place each flow in different queues, thereby equalizing delay of the respective flows as a whole. At dequeue time, the WFQ mechanism allocates the bandwidth that each flow should occupy the egress in terms of the priority (precedence) of the flow. The larger the value of the priority, the more bandwidth is obtained.

For example: there are currently 5 streams in the interface, and their priorities are 0, 1, 2, 3, and 4, respectively, then the method for calculating the total bandwidth quota is as follows: and respectively calculating the value of the priority +1 of each stream, and taking the sum of the calculated values as the total bandwidth quota. Namely, it is

The total bandwidth quota is 1+2+3+4+5 is 15;

the bandwidth proportion occupied by each stream is as follows: (priority +1 of the current flow)/total quota of bandwidth. I.e. the available bandwidth per stream is: 1/15,2/15,3/15,4/15,5/15.

Fourthly, RTP is in priority to queue;

the RTP priority queue mechanism is as follows:

the RTP priority queue mechanism is a queue technology aiming at real-time service delay and jitter, and is characterized in that RTP messages carrying voice or video are sent into a high-priority queue to be sent preferentially. The RTP packet is a UDP packet with an even number of port numbers in a certain range, and the range of the port numbers can be configured. The RTP priority queue mechanism may be used in conjunction with any queue (including FIFO, PQ, CQ, WFQ) mechanism, where the RTP queue has the highest priority.

The above-mentioned congestion avoidance techniques are introduced below:

drop tail is based on fifo (first in first out) and is the most basic congestion avoidance mechanism, and when the system monitors that the queue length exceeds a set threshold, all subsequently received packets are discarded, which is the default congestion avoidance mechanism.

Red and Wred are called active queue management schemes, and as a congestion avoidance technique, data packets in a queue are discarded in a random manner before a queue buffer overflows, whether the average queue length (avgQ) exceeds a set minimum threshold (MinTh) is calculated in this manner, if the average queue length (avgQ) exceeds the set minimum threshold, a packet loss probability is calculated, and packet loss is performed according to the packet loss probability, a packet loss range is a data packet received after the actual queue length reaches the minimum threshold, and if the avgQ exceeds a set maximum threshold (MaxTh), all the received data packets are discarded after the actual queue length reaches the maximum threshold.

The above formula for calculating the packet loss probability is:

Pb＝maxp×(avgQ-MinTh)/(MaxTh-MinTh)；

P＝Pb/(1-count×Pb)；

the average queue length calculation formula is:

avgQ＝(1-w)×avgQ+q×w；

avgQ: average queue length;

w: a weight;

q: the actual queue length of the sample;

p: probability of packet loss;

pb: actual discard probability of the current queue;

and (5) Maxp: a maximum drop probability;

count: the number of packets received by the queue after the last discard.

In the process of implementing the invention, the inventor finds that the following technical problems exist in the prior art:

the QOS technology of the DifferServ model, various queue management and congestion technologies can complete flow control and congestion control under certain specific scenes aiming at different application scenes, and the difference lies in that all the queue technologies, the congestion avoidance technology and the parameter configuration are based on isolated single-system performance characteristics, the queue types are designed in advance, the QOS parameters are configured in a static mode, and the local linear characteristics are completely based on. Due to different node performances on the network and the complexity of the wireless access bearer network, in the process of changing burst and various services, improper static parameter configuration can damage the service quality of the services, increase the burst data packet loss rate and cause link rate oscillation. Therefore, the prior art cannot solve the problem of data congestion well.

Disclosure of Invention

The embodiment of the invention provides a congestion warning and processing method, a system and equipment, which are used for relieving the congestion state of a data receiving end.

A method of congestion warning, the method comprising:

the data receiving end determines whether the data receiving end is in a data congestion state according to the data fullness of the receiving buffer area;

and after the data receiving end is determined to be in the data congestion state, sending an alarm message of the data receiving end in the data congestion state to the data sending end.

A method of congestion handling, the method comprising:

a data sending end receives an alarm message of a data receiving end in a data congestion state;

the data sending end selects a sending queue needing parameter adjustment from a sending message cache queue of the local end according to the alarm message;

the data sending end adjusts packet loss control parameters set for the selected queue so as to increase the packet loss probability of the selected queue; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

A congestion warning device, the device comprising:

a congestion state determining unit, configured to determine whether the receiving buffer is in a data congestion state according to the data fullness of the receiving buffer;

and the congestion alarm sending unit is used for sending the alarm message of the local end in the data congestion state to the data sending end after the congestion alarm sending unit is in the data congestion state.

A congestion handling device, the device comprising:

a congestion alarm receiving unit, configured to receive an alarm message that a data receiving end is in a data congestion state;

a queue selecting unit, configured to select a sending queue requiring parameter adjustment from a sending message buffer queue at the home terminal according to the alarm message;

the congestion control unit is used for adjusting the packet loss control parameters set for the selected queue so as to increase the packet loss probability of the selected queue; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

A congestion handling system, the system comprising:

the data receiving end is used for determining whether the receiving buffer is in a data congestion state or not according to the data fullness of the receiving buffer; after determining that the data is in a data congestion state, sending an alarm message of the data congestion state to a data sending end;

the data sending end is used for receiving the alarm message of the data receiving end in the data congestion state; selecting a sending queue needing parameter adjustment from a sending message cache queue of the local terminal according to the alarm message; adjusting packet loss control parameters set for the selected queues to increase packet loss probability of the selected queues; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

In the invention, when the data receiving end is in the data congestion state, the data receiving end sends the alarm message of the data congestion state to the data sending end, and the data sending end adjusts the packet loss control parameter of the message buffer queue sent in the data receiving end according to the alarm message, so that the packet loss probability of the selected queue is increased, and the packet loss control is carried out on the selected queue according to the adjusted packet loss control parameter. Therefore, the data sending end increases the packet loss probability of the data sending end by adjusting the packet loss control parameter of the message sending cache queue, and further reduces the data packets sent to the data sending end, so that the congestion state of the data receiving end can be effectively relieved.

Drawings

FIG. 1 is a schematic flow chart of a method provided by an embodiment of the present invention;

FIG. 2 is a schematic flow chart of another method provided by the embodiment of the present invention;

fig. 3A is a schematic diagram of an OAM PDU in an embodiment of the present invention;

FIG. 3B is a schematic diagram illustrating a processing flow of a data receiving end according to an embodiment of the present invention;

fig. 3C is a schematic diagram illustrating a queue selection process at a data transmitting end according to an embodiment of the present invention;

fig. 3D is a schematic diagram of a parameter adjustment process of the data sending end in the embodiment of the present invention;

fig. 3E is a schematic diagram illustrating another parameter adjustment process of the data sending end in the embodiment of the present invention;

FIG. 4 is a schematic diagram of a system according to an embodiment of the present invention;

FIG. 5 is a schematic structural diagram of an apparatus according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of another apparatus according to an embodiment of the present invention.

Detailed Description

In order to alleviate the congestion state of a data receiving end, an embodiment of the present invention provides a congestion warning and congestion processing method, in which a data receiving end sends a warning message that the data receiving end is in a data congestion state to a data sending end when the data receiving end is in the data congestion state, and the data sending end adjusts a packet loss control parameter of a sending message buffer queue according to the warning message, so that the packet loss probability of a selected queue is increased.

Referring to fig. 1, the congestion warning method provided in the embodiment of the present invention includes the following steps:

step 10: the data receiving end determines whether the data receiving end is in a data congestion state according to the data fullness of the receiving buffer area;

step 11: and after the data receiving end is determined to be in the data congestion state, sending an alarm message of the data receiving end in the data congestion state to the data sending end.

In step 10, the data receiving end determines whether the data receiving end is in a data congestion state according to the data fullness of the receiving buffer, and the specific implementation thereof may be as follows:

the data receiving end scans the data fullness of the current receiving buffer area and determines whether the data fullness is larger than a preset congestion threshold value; and if so, determining that the data is in the data congestion state, otherwise, determining that the data is not in the data congestion state.

In step 11, the data receiving end sends a notification message that the local end is in a data congestion state to the data sending end, and the specific implementation may be as follows:

the data receiving end determines that the reason of causing the data congestion state is that the bandwidth rises smoothly or a large number of burst data packets are received according to the data fullness of the current receiving buffer area and the data fullness of the receiving buffer area obtained by last scanning; and sending an alarm message of the data congestion state of the local terminal to the data sending terminal, wherein the alarm message carries reason information causing the data congestion state.

Specifically, the data receiving end may determine whether a difference between the data fullness of the current receiving buffer and the data fullness of the receiving buffer obtained by the last scanning is greater than a preset burst congestion threshold; if so, determining that the reason causing the data congestion state is that a large number of burst data packets are received, otherwise, determining that the reason causing the data congestion state is that the bandwidth is gradually increased.

Preferably, the alarm message may carry a message attribute parameter of a received message buffer queue with the largest real-time bandwidth in the data receiving end and/or a message attribute parameter of a received message buffer queue with the most serious congestion degree.

The message attribute parameters include at least one of the following information: source IP address, destination IP address, source port, destination port, Differentiated Services Code (DSCP), protocol type.

Referring to fig. 2, an embodiment of the present invention provides a congestion handling method, including the following steps:

step 20: a data sending end receives an alarm message of a data receiving end in a data congestion state;

step 21: the data sending end selects a sending queue needing parameter adjustment from a sending message cache queue of the local end according to the alarm message;

step 22: the data sending end adjusts packet loss control parameters set for the selected queue so as to increase the packet loss probability of the selected queue; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

In step 21, the data sending end selects a queue that needs parameter adjustment from the sending message buffer queue of the local end according to the alarm message, and the specific implementation can be as follows:

the data sending end obtains the message attribute parameter of the received message cache queue with the largest real-time bandwidth and/or the message attribute parameter of the received message cache queue with the most serious congestion degree in the data receiving end from the alarm message;

and the data sending end selects two queues needing parameter adjustment from the message sending cache queues of the local end according to the acquired message attribute parameters.

Specifically, the data sending end selects two queues that need parameter adjustment from the sending message cache queues of the local end according to the obtained message attribute parameters, and the specific implementation can be as follows:

the data sending end matches the message attribute parameters of the receiving message cache queue with the maximum real-time bandwidth with the message attribute parameters of all the sending message cache queues in the local end so as to determine the sending message cache queue corresponding to the receiving message cache queue with the maximum real-time bandwidth in the local end; if the matching is successful, selecting a successfully matched sending message buffer queue (namely the sending message buffer queue corresponding to the local end of the receiving message buffer queue with the largest real-time bandwidth) as a queue needing parameter adjustment; otherwise, selecting the sending message buffer queue with the lowest priority of the local end as a queue needing parameter adjustment;

the data sending end matches the message attribute parameters of the received message cache queue with the most serious congestion degree with the message attribute parameters of all the sent message cache queues in the local end so as to determine the sent message cache queue corresponding to the received message cache queue with the most serious congestion degree in the local end; if the matching is successful and the successfully matched sending message buffer queue is not the same queue as the selected queue needing parameter adjustment, selecting the successfully matched sending message buffer queue (namely the sending message buffer queue corresponding to the local end of the receiving message buffer queue with the most serious congestion degree) as the other queue needing parameter adjustment; otherwise, selecting the sending message buffer queue with the next lower priority of the local terminal as another queue needing parameter adjustment.

Preferably, after the data sending end matches and matches the message attribute parameters of the received message cache queue with the largest real-time bandwidth with the message attribute parameters of all the sent message cache queues in the local end successfully, and before selecting the successfully matched sent message cache queue as a queue needing parameter adjustment, the data sending end may first determine whether the successfully matched sent message cache queue is a system queue in CQ; if so, reporting alarm information, and ending the process; otherwise, selecting the successfully matched sending message buffer queue as a queue needing parameter adjustment.

In step 22, the data sending end adjusts the packet loss control parameter set for the selected queue, so as to increase the packet loss probability of the selected queue, and the specific implementation thereof may be as follows:

if the Red congestion avoidance mechanism is adopted by the data sending end, at least one of the following operations is executed: reducing the queue length lowest threshold (namely MinTh of the background technology part) for calculating the packet loss probability; for example, the queue length minimum threshold is adjusted to be one N of the original value;

reducing the maximum threshold value of the queue length for calculating the packet loss probability (namely MaxTh of the background technology part); for example, adjusting the maximum threshold value of the queue length to be one N of the original value;

the weight for calculating the packet loss probability is adjusted to be large (namely w of the background technology part); for example, the weight is adjusted to a set maximum weight value.

If the data sending end does not adopt a Red congestion avoidance mechanism, reducing a queue length threshold value for judging whether packet loss occurs or not; for example, the queue length threshold is adjusted to one-N of the original value. In the prior art, if the actual length of the queue is greater than the queue length threshold, all subsequently received data packets are discarded.

Further, if the reason causing the data congestion state carried in the alarm message is that a large number of burst data packets are received, after the data sending end adjusts the packet loss control parameter set for the selected queue in step 22, the data sending end may start the fast response holding timer, and adjust the packet loss control parameter again after the fast response holding timer is overtime, so as to reduce the packet loss probability of the selected queue, and perform packet loss control on the selected queue according to the adjusted packet loss control parameter, so as to adjust the packet loss control parameter again after the congestion is recovered, thereby achieving the purpose of better adapting to the opposite end of the system.

Preferably, after the fast response holding timer is overtime and before the packet loss control parameter is adjusted again, the data sending end may first determine whether the value of the current packet loss control parameter exceeds a preset adjustment threshold; if so, reporting the event message and recording a log; otherwise, adjusting the packet loss control parameter again.

The packet loss control parameter is adjusted again, and the specific implementation may be as follows:

if the Red congestion avoidance mechanism is adopted by the data sending end, at least one of the following operations is executed:

the minimum threshold value of the queue length for calculating the packet loss probability is increased; for example, the queue length minimum threshold after readjustment is one step smaller than the queue length minimum threshold when the data sending end receives the alarm information; the step size can be configured in advance;

increasing the maximum threshold value of the queue length for calculating the packet loss probability; for example, the adjusted maximum threshold value of the queue length is smaller by one step than the maximum threshold value of the queue length when the data sending end receives the alarm information; the step size can be configured in advance;

reducing the weight for calculating the packet loss probability; for example, the weight after readjustment is one step larger than the weight when the data sending end receives the alarm information; the step size may be preconfigured at all.

If the data sending end does not adopt the Red congestion avoidance mechanism, the queue length threshold value for judging whether packet loss occurs is increased; for example, the queue length threshold after readjustment is one step smaller than the queue length threshold when the data sending end receives the alarm information; the step size may be preconfigured at all.

Further, if the cause of the data congestion state carried in the alarm message is a gradual rise in bandwidth, after the data sending end adjusts the packet loss control parameter set for the selected queue, the following steps are executed:

A. the data sending end starts a slow reply timer, and adjusts the packet loss control parameter again after the slow reply timer is overtime so as to reduce the packet loss probability of the selected queue; performing packet loss control on the selected queue according to the adjusted packet loss control parameter;

B. and B, the data sending end judges whether the value of the current packet loss control parameter exceeds a recovery target value, if so, the process is ended, and if not, the process returns to the step A.

Specifically, the recovery target value is equal to a value of a corresponding packet loss control parameter when the data sending end receives the alarm message, or is smaller than the value by one step.

the minimum threshold value of the queue length for calculating the packet loss probability is increased; for example, the queue length minimum threshold is adjusted up by a step size on the basis of the current value, and the step size can be configured in advance;

increasing the maximum threshold value of the queue length for calculating the packet loss probability; for example, the maximum threshold value of the queue length is adjusted up by a step size on the basis of the current value, and the step size can be configured in advance;

reducing the weight for calculating the packet loss probability; for example, the weight is adjusted downward by one step size based on the current value, which step size can be preconfigured at all.

If the data sending end does not adopt the Red congestion avoidance mechanism, the queue length threshold value for judging whether packet loss occurs is increased; for example, the queue length threshold is adjusted up by a step size based on the current value, and the step size can be configured in advance.

The invention is illustrated below in specific examples:

the invention realizes a congestion control method and strategy based on a feedback mechanism based on the IP QOS technology of the Ethernet. And the data receiving end monitoring system feeds back a message to the data sending end after finding that the local end is congested, the data sending end adjusts the local end parameters, and the two ends simultaneously carry out system congestion control operation to complete a congestion management mechanism under closed-loop control. Two network nodes A and B which are directly connected adopt the packet classification, queue management and congestion avoidance technology of a DiffServ model, an A, B node simultaneously starts an Ethernet operation and maintenance (OAM) (IEEE802.3ah) protocol, and the protocol uniformly defines two kinds of alarm messages of Critical Event and dangerous emergency (Dying Gasp) and represents the congestion state alarm indication message of a sending source. An 802.3ah Event Notification operation and maintenance protocol data unit (Event Notification OAM PDU) is defined in a unified way, wherein the Event Notification OAM PDU carries congestion state information of an alarm sending end, after the alarm receiving end receives the congestion state information, the congestion control parameters of a local end system are dynamically adjusted according to specific information content, and meanwhile, the data receiving end and the data sending end carry out congestion processing to quickly recover network performance, so that the adaptation of link performance QOS and the like between A, B nodes is realized, and the link performance and the QOS of systems at two ends tend to be reasonable. The invention can improve the service quality problems of high packet loss, large time delay and the like caused by burst, flow change and the like in the mobile communication bearing network.

The network node for providing service starts the packet classification and congestion management technology of a DifferServ model based on an IP bearing network of Ethernet, and supports the 802.3ah protocol of the Ethernet.

The new 802.3ah alarm message definition and Event Notification OAM PDU format are as follows:

a Critical Event which represents the congestion caused by the gradual rise of the bandwidth of the receiving end;

a Dying Gasp, which represents congestion caused by the burst of a large number of packets received by a receiving end;

as shown in fig. 3A, the OAM PDU message structure is defined as follows:

link Event TLV #2 Congestion information 1(Link Event TLV #2 Congestion Info1), which carries the message attribute parameter of the received message cache queue with the maximum real-time bandwidth of the receiving end;

link Event TLV #3 Congestion information 2(Link Event TLV #3 Congestion Info2), which carries the message attribute parameter of the received message buffer queue with the most serious receiving end queue Congestion;

flags is 0x04, which indicates that a Critical Event alarm is sent, and Flags is a flag bit;

flag is 0x02, indicating that a Dying Gasp alarm is sent;

the classification and queue parameters of the packet are as follows:

the classification of services applied to a Radio Network Controller (RNC) of an access stratum device of a mobile bearer network and an Evolved Packet Core (EPC) of an LTE core network device is defined as follows:

signaling: DSCP 56;

real-time service: DSCP 46;

streaming media service: DSCP 34;

interactive services: DSCP 18;

background class service: DSCP is 0.

Setting a queue;

the calculation formula of the cache sizes of different services is as follows:

MaxBu＝AlnkR×MaxTl/PktL

wherein, the AlnkR is the service available bandwidth;

MaxTl is the maximum buffer length with reasonable service; MinTl is the minimum buffer length with reasonable service;

PktL is the packet length common to traffic.

The initial queue length threshold is defined in terms of MinTh 1/2MaxTh, MaxTh 1/2 MaxBu:

the first embodiment is as follows:

the data receiving end monitors the congestion state of the system, judges that the system is congested, constructs an OAMPDU message and informs the data sending end of processing. As shown in fig. 3B, the alarm sending process at the data receiving end is as follows:

p1: the equipment is electrified and initialized, QOS parameters such as queues and DSCP are configured according to static parameters, 802.3ah alarm messages are configured according to the static parameters, and a congestion threshold value, a burst congestion threshold value and timers T1, T2 and T3 are configured according to the static parameters.

P2: the scan timer T1 is started, the receive buffer fullness is periodically scanned, and the results of the last two scans are buffered. And comparing the latest scanning result with the congestion threshold, if the scanning result is not greater than the congestion threshold, continuing to perform periodic scanning, and if the scanning result is greater than the set congestion threshold, entering the next process.

P3: comparing the difference between the last two scanning results, comparing the difference with a set burst congestion threshold result, and performing different processes:

p31: if the difference is not larger than the set burst congestion threshold, judging that the congestion is caused by the gradual rise of the bandwidth of the receiving end, constructing an OAMPDU message, wherein Flags is 0x04 and represents a Critical Event type, sending out from a physical port, starting an inactivity timer T2, and restarting the periodic scanning after the congestion processing of the opposite end is completed.

P32: if the difference is larger than the set burst congestion threshold, judging that the receiving end receives the congestion caused by the burst of a large number of packets, constructing an OAMPDU message, wherein Flags is 0x02 and represents a Dying Gasp message, sending the OAMPDU message out from a physical port, starting an inactivity timer T3, and restarting the periodic scanning after the opposite end congestion processing is finished.

Example two:

the data sending end receives OAMPDU message sent by the opposite end, analyzes the message structure, and selects a plurality of queues from the local end queue for parameter adjustment. As shown in fig. 3C, the data sender queue selection process is as follows:

p1: the equipment is electrified and initialized, QOS parameters such as queues and DSCP are configured according to the static parameters, and 802.3ah alarm messages are configured according to the static parameters.

P2: the queue selection module receives the Event Notification OAMPDU warning message, analyzes the contents of Link Event TLV #2 Congestion Info1 and Link Event TLV #3 Congestion Info2 of the OAMPDU message, and acquires the opposite end information: the most congested queue RSqs and the real-time bandwidth maximum queue RSqt determine the type of the alarm message according to Flag bits: critical Event or Dying Gasp.

P3: matching the RSqt queue parameters with all queue parameters of the local terminal, and performing different processing according to the matching result:

p31: and if the matching fails, selecting the queue with the lowest priority of the DSCP at the local end as a queue to be adjusted sq1, and switching to P4.

P32: if the matching is successful, judging whether the hit queue is a CQ system queue, and performing different processing according to the matching result:

p321: and if the queue is a CQ system queue, reporting an alarm message, and ending the process.

P322: if not, the queue is selected as the queue to be adjusted sq1, and the P4 is switched to.

P4: matching the RSqs queue parameters with all queue parameters of the home terminal, and performing different processing according to matching results:

p41: if the matching fails or the matching is successful but the hit queue is the same as the queue to be adjusted selected before, the queue with the lower priority of the DSCP at the local end is selected as the queue to be adjusted sq2, and the P5 is switched.

P42: and if the matching is successful and the hit queue is not the same queue as the previously selected queue to be adjusted, taking the hit queue as the queue to be adjusted sq2 and turning to P5.

P5: sending a request to adjust queue parameter message to a congestion dynamic processing module, wherein the message carries information of queues to be adjusted sq1 and sq2, and carries a congestion type: critical Event (congestion caused by gradual rise of bandwidth at the receiving end) or Dying Gasp (congestion caused by burst of a large number of packets received by the receiving end).

Example three:

the congestion type in the alarm message received by the data sending end is Dying Gasp, a large amount of bursts cause that the link is in a critical congestion state, the congestion recovery is quickly completed through a quick response mechanism of the data sending end system, and the parameters of the local end are adjusted after the congestion recovery, so that the local end system is better adapted to the opposite end system. As shown in fig. 3D, the process flow is as follows:

p1: and a congestion dynamic processing module of the data sending end receives the request for adjusting the queue parameter message, judges that the congestion type belongs to Dying Gasp (congestion caused by the fact that a receiving end receives a lot of bursts of packets), acquires the information of the queue to be adjusted, and enters a quick congestion recovery processing flow.

P2: judging whether the queue to be adjusted starts an RED mechanism, and performing different treatments according to the judgment result:

p21: if the queue does not start RED, the queue length threshold is adjusted to 1/N (N value suggestion: 3-5) of the current value, and a duration is waited, namely the duration of the fast response holding timer Tf.

P211: judging whether the current value of the queue length exceeds an adjustment threshold, and carrying out different treatments according to the judgment result:

p2111: if the adjustment threshold is exceeded, reporting the event message, recording the log, and turning to P3.

P2112: if the adjustment threshold is not exceeded, the queue length threshold is adjusted downward by one step based on the adjustment threshold of step P21, and P3 is turned.

P22: if the queue starts RED, the queue length threshold is adjusted to be 1/N (N value suggestion: 3-5) configured currently, the discarding weight is adjusted to be the maximum discarding weight value MaxW, and a duration is waited, namely the duration of the fast response holding timer Tf.

P221: judging whether the current value of the queue length exceeds an adjustment threshold, and carrying out different treatments according to the judgment result:

p2211: if the adjustment threshold is exceeded, reporting the event message, recording the log, and turning to P3.

P2212: if the adjustment threshold is not exceeded, the queue length threshold is adjusted down by one step based on the adjustment threshold in step P22, the discarding weight is adjusted up by one step, and the process goes to P3.

P3: the flow ends.

Example four:

the congestion type in the alarm message received by the data sending end is Critical Event, the slow rate increase makes the link possibly generate congestion, and the congestion recovery is quickly completed through a response mechanism of the data sending end system; through a slow recovery mechanism, the sending rate of a data sending end is slowly reduced, and the link rate jitter is reduced; and after the recovery is finished, the parameters of the local terminal are adjusted, and the local terminal is better adapted to the system of the opposite terminal. As shown in fig. 3E, the process flow is as follows:

p1: and a congestion dynamic processing module of the data sending end receives the request for adjusting the queue parameter message, judges that the congestion type belongs to a Critical Event (congestion caused by the gradual rise of the bandwidth of the receiving end), acquires the information of the queue to be adjusted, and enters a slow congestion recovery processing flow.

P2: judging whether the queue length threshold of the queue to be adjusted exceeds an adjustable range, and performing different processing according to the judgment result:

p21: if the adjustment range is exceeded, reporting the event message, recording the log, taking the current queue length threshold (queue length, discarding weight and the like) of the queue as a queue parameter recovery target value, and switching to P3.

P22: if the adjustment range is not exceeded, the current queue length threshold is adjusted downwards by one step to serve as a queue parameter recovery target value, and the P3 is switched.

P3: judging whether the queue to be adjusted starts an RED mechanism, and performing different treatments according to the judgment result:

p31: if the queue does not start RED, adjusting the queue length threshold value to 1/M (M value suggestion: 2-4) of the current value;

p311: waiting for a duration, i.e. the duration of the slow recovery timer Tl.

P312: and on the basis of the current queue length threshold value, the queue length threshold value is adjusted up by one step.

P313: judging whether the adjusted queue length threshold value exceeds a queue parameter recovery target value or not, and performing different processing according to a judgment result:

p3131: if so, log is recorded, go to P4.

P3132: if not, go to P311.

P32: if the queue starts RED, the queue length threshold is adjusted to 1/M (M value suggestion: 2-4) of the current value, and the discarding weight is adjusted to MaxW.

P321: waiting for a duration, i.e. the duration of the slow recovery timer Tl.

P322: on the basis of the queue modification threshold, the queue length threshold is adjusted up by one step, and the discarding weight is adjusted down by one step.

P323: judging whether the adjusted queue length threshold value exceeds a queue parameter recovery target value or not, and performing different processing according to a judgment result:

p3231: if so, log is recorded, go to P4.

P3232: if not, go to P321.

P4: the flow ends.

The above-described embodiments have the following advantages over the prior art:

defining an Event information PDU of an 802.3ah protocol, expanding in a TLV field, carrying congestion state information of a local terminal, and expanding the function of the 802.3ah protocol; dynamically adjusting QOS parameters according to OMAPDU information fed back by an opposite end node to achieve the best QOS parameter adaptation between adjacent network nodes, and realizing reasonable balance among time delay, packet loss and jitter for voice stream (Voip stream), interactive (interactive) and background (background) type services; the data receiving end and the data sending end simultaneously carry out the operation of a congestion control system, so that a link can be recovered to be normal from a congestion or critical congestion state more quickly, the performance of adjacent network nodes and the optimal adaptation of QOS are realized by dynamically adjusting parameters, and the IP bearer network dynamically and reasonably balances the time delay, packet loss and jitter indexes of all types of services such as VoIpstream, interactive and background; providing operation and operation logs, analyzing various message compositions and burst rules by network maintenance personnel, and manually adjusting bandwidth configuration QOS (quality of service) configuration to ensure that the link rate tends to be reasonable and is close to or approximately equal to the capacity of a link; the method is completely independent of a network layer, a transmission layer is independently finished, and end-to-end congestion control algorithms such as TCP slow start and the like are not required to be matched for use; the realization is simple, a new protocol message interaction mechanism is not involved, and only a data link layer-transmission bearing layer message interface is added in the realization; the expandability is strong, and the congestion information is interacted between two adjacent network nodes, so that the end-to-end transmission layer congestion management is realized.

Referring to fig. 4, an embodiment of the present invention provides a congestion processing system, including:

a data receiving end 40, configured to determine whether the receiving buffer is in a data congestion state according to the data fullness of the receiving buffer; after determining that the data is in a data congestion state, sending an alarm message of the data congestion state to a data sending end;

a data sending end 41, configured to receive an alarm message that a data receiving end is in a data congestion state; selecting a sending queue needing parameter adjustment from a sending message cache queue of the local terminal according to the alarm message; adjusting packet loss control parameters set for the selected queues to increase packet loss probability of the selected queues; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

Referring to fig. 5, an embodiment of the present invention provides a congestion warning apparatus, where the apparatus includes:

a congestion status determining unit 501, configured to determine whether the receiving buffer is in a data congestion status according to the data fullness of the receiving buffer;

a congestion alarm sending unit 502, configured to send an alarm message that the local end is in the data congestion state to the data sending end after determining that the local end is in the data congestion state.

The congestion status determining unit 501 is configured to:

scanning the data fullness of the current receiving buffer area, and determining whether the data fullness is greater than a preset congestion threshold value; and if so, determining that the data is in the data congestion state, otherwise, determining that the data is not in the data congestion state.

The congestion alarm sending unit 502 is configured to:

determining the reason causing the data congestion state to be that the bandwidth is gradually increased or a large number of burst data packets are received according to the data fullness of the current receiving buffer area and the data fullness of the receiving buffer area obtained by last scanning; and sending an alarm message of the data congestion state of the local terminal to the data sending terminal, wherein the alarm message carries reason information causing the data congestion state.

The congestion alarm sending unit 502 is configured to:

judging whether the difference value of the data fullness of the current receiving buffer area and the data fullness of the receiving buffer area obtained by last scanning is larger than a preset burst congestion threshold value or not; if so, determining that the reason causing the data congestion state is that a large number of burst data packets are received, otherwise, determining that the reason causing the data congestion state is that the bandwidth is gradually increased.

The alarm message carries the message attribute parameter of the received message cache queue with the largest real-time bandwidth in the data receiving end and/or the message attribute parameter of the received message cache queue with the most serious congestion degree.

The message attribute parameters include at least one of the following information:

source IP address, destination IP address, source port, destination port, diffserv code DSCP, protocol type.

Referring to fig. 6, an embodiment of the present invention provides a congestion handling apparatus, including:

a congestion alarm receiving unit 601, configured to receive an alarm message that a data receiving end is in a data congestion state;

a queue selecting unit 602, configured to select, according to the alarm message, a sending queue that needs to be parameter-adjusted from a sending message buffer queue at the home terminal;

a congestion control unit 603, configured to adjust a packet loss control parameter set for the selected queue, so as to increase a packet loss probability of the selected queue; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

The queue selecting unit 602 is configured to:

acquiring the message attribute parameter of a received message cache queue with the largest real-time bandwidth and/or the message attribute parameter of the received message cache queue with the most serious congestion degree in a data receiving end from the alarm message;

and selecting two queues needing parameter adjustment from the message sending cache queues of the local terminal according to the acquired message attribute parameters.

The queue selecting unit 602 is configured to: matching the message attribute parameters of the receiving message cache queue with the maximum real-time bandwidth with the message attribute parameters of all the sending message cache queues in the home terminal, and if the matching is successful, selecting the successfully matched sending message cache queue as one queue needing parameter adjustment; otherwise, selecting the sending message buffer queue with the lowest priority of the local end as a queue needing parameter adjustment;

matching the message attribute parameters of the received message cache queue with the most serious congestion degree with the message attribute parameters of all message sending cache queues in the local terminal, and if the matching is successful and the successfully matched message sending cache queue is not the same queue as the selected queue needing parameter adjustment, selecting the successfully matched message sending cache queue as the other queue needing parameter adjustment; otherwise, selecting the sending message buffer queue with the next lower priority of the local terminal as another queue needing parameter adjustment.

The queue selecting unit 602 is further configured to:

after matching the message attribute parameters of the receiving message cache queue with the largest real-time bandwidth with the message attribute parameters of all sending message cache queues in the local terminal and before selecting the sending message cache queue which is successfully matched as a queue which needs parameter adjustment, judging whether the sending message cache queue which is successfully matched is a system queue in a customized queue CQ;

and when judging that the successfully matched sending message cache queue is not the system queue in the CQ, selecting the successfully matched sending message cache queue as a queue needing parameter adjustment.

The congestion control unit 603 is configured to:

if the Red congestion avoidance mechanism is employed, performing at least one of the following operations: reducing the lowest threshold value of the queue length for calculating the packet loss probability, reducing the highest threshold value of the queue length for calculating the packet loss probability, and increasing the weight for calculating the packet loss probability; or,

if the Red congestion avoidance mechanism is not adopted, the queue length threshold value for judging whether packet loss occurs is reduced.

The congestion control unit 603 is further configured to:

if the reason causing the data congestion state carried in the alarm message is that a large number of burst data packets are received, after the packet loss control parameter set for the selected queue is adjusted, starting a fast response holding timer, and after the fast response holding timer is overtime, adjusting the packet loss control parameter again so as to reduce the packet loss probability of the selected queue; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

The congestion control unit 603 is configured to: after the fast response holding timer is overtime and before the packet loss control parameter is adjusted again, judging whether the value of the current packet loss control parameter exceeds a preset adjustment threshold or not;

and when the current value of the packet loss control parameter is judged not to exceed the preset adjustment threshold, adjusting the packet loss control parameter again.

The congestion control unit 603 is further configured to:

if the cause of the data congestion state carried in the alarm message is that the bandwidth is gradually increased, after adjusting packet loss control parameters set for the selected queue:

A. starting a slow reply timer, and adjusting the packet loss control parameter again after the slow reply timer is overtime so as to reduce the packet loss probability of the selected queue; performing packet loss control on the selected queue according to the adjusted packet loss control parameter;

B. and C, judging whether the current value of the packet loss control parameter exceeds a recovery target value, if so, ending the process, otherwise, returning to the step A.

The recovery target value is equal to the value of the packet loss control parameter when the data sending end receives the alarm message, or is smaller than the value by one step length.

The congestion control unit 603 is configured to:

if the Red congestion avoidance mechanism is employed, performing at least one of the following operations: the method comprises the steps of increasing a queue length lowest threshold used for calculating packet loss probability, increasing a queue length highest threshold used for calculating packet loss probability, and decreasing the weight used for calculating packet loss probability; or,

if the Red congestion avoidance mechanism is not adopted, the queue length threshold value for judging whether packet loss occurs is increased.

In conclusion, the beneficial effects of the invention include:

in the scheme provided by the embodiment of the invention, the data receiving end sends the alarm message of the data congestion state of the data receiving end to the data sending end when the data receiving end is in the data congestion state, the data sending end adjusts the packet loss control parameter of the message cache queue sent in the data receiving end according to the alarm message so as to increase the packet loss probability of the selected queue, and performs packet loss control on the selected queue according to the adjusted packet loss control parameter. Therefore, the data sending end increases the packet loss probability of the data sending end by adjusting the packet loss control parameter of the message sending cache queue, and further reduces the data packets sent to the data sending end, so that the congestion state of the data receiving end can be effectively relieved.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method of congestion warning, the method comprising:

and after the data receiving end is determined to be in the data congestion state, sending an alarm message that the data receiving end is in the data congestion state to the data sending end.

2. The method of claim 1, wherein the data receiving end determining whether it is in a data congestion state according to the data fullness of the receiving buffer comprises:

3. The method of claim 2, wherein the sending the notification message that the local end is in the data congestion state to the data sending end comprises:

the data receiving end determines that the reason of causing the data congestion state is that the bandwidth rises smoothly or a large number of burst data packets are received according to the data fullness of the current receiving buffer area and the data fullness of the receiving buffer area obtained by last scanning; and sending an alarm message of the data receiving end in a data congestion state to the data sending end, wherein the alarm message carries reason information causing the data congestion state.

4. The method as claimed in claim 3, wherein the determining, by the data receiving end, that the data congestion state is caused by a gradual increase in bandwidth or the receipt of a large number of burst packets according to the data fullness of the current receiving buffer and the data fullness of the receiving buffer obtained by the last scanning comprises:

the data receiving end judges whether the difference value of the data fullness of the current receiving buffer area and the data fullness of the receiving buffer area obtained by last scanning is larger than a preset burst congestion threshold value or not; if so, determining that the reason causing the data congestion state is that a large number of burst data packets are received, otherwise, determining that the reason causing the data congestion state is that the bandwidth is gradually increased.

5. The method according to any of claims 1-4, wherein the alarm message carries the message attribute parameter of the received message buffer queue with the largest real-time bandwidth and/or the message attribute parameter of the received message buffer queue with the most serious congestion degree at the data receiving end.

6. The method of claim 5, wherein the packet attribute parameters include at least one of:

7. A method of congestion handling, the method comprising:

the data sending end selects a queue needing parameter adjustment from a message sending buffer queue of the local end according to the alarm message;

8. The method of claim 7, wherein the selecting, by the data sending end, a queue requiring parameter adjustment from a message sending buffer queue of the local end according to the alarm message comprises:

the data sending end obtains the message attribute parameter of the received message cache queue with the largest real-time bandwidth and the message attribute parameter of the received message cache queue with the most serious congestion degree in the data receiving end from the alarm message;

9. The method of claim 8, wherein the data sending end selecting two queues needing parameter adjustment from the sending message buffer queues of the local end according to the obtained message attribute parameters comprises:

the data sending end matches the message attribute parameters of the receiving message cache queue with the maximum real-time bandwidth with the message attribute parameters of all the sending message cache queues in the local end, and if the matching is successful, the sending message cache queue which is successfully matched is selected as one queue which needs to be subjected to parameter adjustment; otherwise, selecting the sending message buffer queue with the lowest priority of the local end as a queue needing parameter adjustment;

the data sending end matches the message attribute parameters of the received message cache queue with the most serious congestion degree with the message attribute parameters of all the sent message cache queues in the data sending end, and if the matching is successful and the successfully matched sent message cache queue is not the same queue as the selected queue needing parameter adjustment, the successfully matched sent message cache queue is selected as the other queue needing parameter adjustment; otherwise, selecting the sending message buffer queue with the next lower priority of the local terminal as another queue needing parameter adjustment.

10. The method according to claim 9, wherein after the data sending end matches and succeeds in matching the message attribute parameters of the received message buffer queue with the largest real-time bandwidth with the message attribute parameters of all the message buffer queues in the local end, and before selecting the successfully matched message buffer queue as one queue needing parameter adjustment, the method further comprises:

the data sending end judges whether the successfully matched sending message buffer queue is a system queue in the customized queue CQ;

the selecting the successfully matched sending message buffer queue as one queue needing parameter adjustment comprises the following steps:

and when the data sending end judges that the successfully matched sending message cache queue is not the system queue in the CQ, selecting the successfully matched sending message cache queue as a queue needing parameter adjustment.

11. The method of claim 7, wherein the adjusting, by the data sending end, the packet loss control parameter set for the selected queue so as to increase the packet loss probability of the selected queue comprises:

if the Red congestion avoidance mechanism is adopted by the data sending end, at least one of the following operations is executed: reducing the lowest threshold value of the queue length for calculating the packet loss probability, reducing the highest threshold value of the queue length for calculating the packet loss probability, and increasing the weight for calculating the packet loss probability; or,

if the data sending end does not adopt the Red congestion avoidance mechanism, the queue length threshold value for judging whether packet loss occurs is reduced.

12. The method of claim 7, wherein if the cause of the data congestion state carried in the alarm message is that a large number of bursty data packets are received, after the data sending end adjusts the packet loss control parameter set for the selected queue, the method further comprises:

the data sending end starts a fast response holding timer, and adjusts the packet loss control parameter again after the fast response holding timer is overtime so as to reduce the packet loss probability of the selected queue; and performing packet loss control on the selected queue according to the adjusted packet loss control parameter.

13. The method of claim 12, wherein after the fast response hold timer expires and before the packet loss control parameter is adjusted again, the method further comprises:

judging whether the value of the current packet loss control parameter exceeds a preset adjustment threshold or not;

the readjusting the packet loss control parameter includes:

14. The method according to claim 7, wherein if the cause of the data congestion state carried in the alarm message is a gradual bandwidth increase, after the data sending end adjusts the packet loss control parameter set for the selected queue, the method further comprises:

15. The method of claim 14, wherein the recovery target value is equal to or smaller than the value of the packet loss control parameter when the data sending end receives the alarm message by one step.

16. The method according to claim 12 or 14, wherein said readjusting said packet loss control parameter comprises:

if the Red congestion avoidance mechanism is adopted by the data sending end, at least one of the following operations is executed: the method comprises the steps of increasing a queue length lowest threshold used for calculating packet loss probability, increasing a queue length highest threshold used for calculating packet loss probability, and decreasing the weight used for calculating packet loss probability; or,

if the data sending end does not adopt the Red congestion avoidance mechanism, the queue length threshold value for judging whether packet loss occurs is increased.

17. A congestion warning device, characterized in that the device comprises:

18. The apparatus of claim 17, wherein the congestion state determination unit is to:

19. The apparatus of claim 18, wherein the congestion alert sending unit is to:

20. The apparatus of claim 19, wherein the congestion alert sending unit is to:

21. The apparatus according to any of claims 17 to 20, wherein the alarm message carries a message attribute parameter of a received message buffer queue with a largest real-time bandwidth and/or a message attribute parameter of a received message buffer queue with a most serious congestion degree in a data receiving end.

22. The apparatus of claim 21, wherein the packet attribute parameters comprise at least one of:

23. A congestion handling apparatus, characterized in that the apparatus comprises:

a queue selecting unit, configured to select a queue that needs parameter adjustment from a message sending buffer queue of the home terminal according to the alarm message;

24. The apparatus of claim 23, wherein the queue selection unit is to:

25. The apparatus of claim 24, wherein the queue selection unit is to:

matching the message attribute parameters of the receiving message cache queue with the maximum real-time bandwidth with the message attribute parameters of all the sending message cache queues in the home terminal, and if the matching is successful, selecting the successfully matched sending message cache queue as one queue needing parameter adjustment; otherwise, selecting the sending message buffer queue with the lowest priority of the local end as a queue needing parameter adjustment;

26. The apparatus of claim 25, wherein the queue selection unit is further configured to:

27. The apparatus of claim 23, wherein the congestion control unit is to:

28. The apparatus of claim 23, wherein the congestion control unit is further to:

29. The apparatus of claim 28, wherein the congestion control unit is to:

after the fast response holding timer is overtime and before the packet loss control parameter is adjusted again, judging whether the value of the current packet loss control parameter exceeds a preset adjustment threshold or not;

30. The apparatus of claim 23, wherein the congestion control unit is further to:

31. The apparatus of claim 30, wherein the recovery target value is equal to or smaller than a value of the packet loss control parameter when the data sending end receives the alarm message by one step.

32. The apparatus of claim 28 or 30, wherein the congestion control unit is to:

33. A congestion handling system, comprising: