WO2013082789A1

WO2013082789A1 - Congestion control method and device

Info

Publication number: WO2013082789A1
Application number: PCT/CN2011/083712
Authority: WO
Inventors: 王磊; 李岩; 魏凯
Original assignee: 华为技术有限公司
Priority date: 2011-12-08
Filing date: 2011-12-08
Publication date: 2013-06-13
Also published as: CN103548381A; CN103548381B

Abstract

Disclosed are a congestion control method and device. The congestion control method comprises: detecting a congestion identifier carried by a traffic flow; according to a detection result and the user priority of a user equipment (UE) that receives the traffic flow, determining a corresponding congestion level; according to the congestion level and the user priority, obtaining a corresponding congestion control policy to perform congestion control on the traffic flow. In the congestion control method and device according to the embodiments of the present invention, the current congestion degree is measured according to the congestion level and the user priority to perform corresponding traffic flow control, so as to ensure the user priority according to the network congestion situation.

Description

Congestion control method and device

Technical field

The embodiments of the present invention relate to the field of communications technologies, and in particular, to a congestion control method and apparatus. Background technique

Under the PCC (Policy and Charging Control) architecture, the PCRF (Policy and Charging Rules Function) entity determines the QCI (QoS Class Identifier) of the service flow.

When the QoS class identifier, QoS (Quality of Service), it needs to be determined according to the carrier's policy and service type.

Users have certain identity characteristics when signing up, such as gold, silver and copper users. Gold users have higher fees and have higher priority when enjoying business. When the gold, silver, and copper users use the same service, the PCRF can assign the same QCI to the three types of users. If the eNodeB (Evolved Node B) is congested, the services of the high-priority users cannot be guaranteed. Summary of the invention

An object of the embodiments of the present invention is to provide a congestion control method and apparatus, and to ensure user priority according to network congestion. The purpose of the embodiment of the present invention is achieved by the following technical solutions:

In one aspect, an embodiment of the present invention provides a congestion control method, including:

Detecting a congestion identifier carried by the service flow;

Determining a corresponding congestion level according to the detection result and the user priority of the user equipment UE that receives the service flow; obtaining a corresponding congestion control policy according to the congestion level and the user priority, and performing congestion control on the service flow. In another aspect, an embodiment of the present invention provides a congestion control apparatus, including:

a detecting unit, configured to detect a congestion identifier carried by the service flow;

a determining unit, configured to determine a corresponding congestion level according to the detection result and a user priority of the user equipment UE that receives the service flow, and obtain a corresponding congestion control policy according to the congestion level and the user priority;

And a control unit, configured to perform congestion control on the service flow according to the obtained congestion control policy.

It can be seen from the technical solution provided by the foregoing embodiments of the present invention that the current traffic congestion is measured by the congestion level and the user priority to perform corresponding service flow control, thereby ensuring the user priority according to the network congestion. DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention, Those skilled in the art can also obtain other drawings based on these drawings without any creative work.

1 is a schematic flowchart of a congestion control method according to an embodiment of the present invention;

2 is a schematic structural diagram of a congestion control apparatus according to an embodiment of the present invention;

3 is a schematic flowchart 1 of an application flow of a congestion control method according to an embodiment of the present invention; 4 is a second schematic diagram of an application flow of a congestion control method according to an embodiment of the present invention;

FIG. 5 is a second schematic diagram of an application flow of a congestion control method according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram 4 of an application flow of a congestion control method according to an embodiment of the present invention. detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

As shown in FIG. 1, an embodiment of the present invention provides a congestion control method, including:

11. Detect the congestion identifier carried in the service flow.

12. Determine a corresponding congestion level according to the detection result and the user priority of the user equipment that receives the service flow.

13. Acquire a corresponding congestion control policy according to the congestion level and the user priority, and perform congestion control on the service flow.

The execution entity of the congestion control method in the embodiment of the present invention may be a PGW (Packet Data Network Gateway), and specifically, may be a PCEF (Policy and Charging Execution Function) entity, or a TDF. (Traffic Detection Function) An entity, etc., where the TDF entity includes two types: a built-in TDF and an external TDF.

It can be seen from the technical solution provided by the foregoing embodiments of the present invention that the current traffic congestion is measured by the congestion level and the user priority to perform corresponding service flow control, thereby ensuring the user priority according to the network congestion.

Optionally, the method for detecting the congestion identifier carried by the service flow in the foregoing step 11 may include:

During the detection period, the number of data packets carrying the congestion identifier in the service flow is detected.

Or, during the detection period, detecting the number of data packets carrying the congestion identifier in the service flow, and obtaining the congestion ratio of the number of data packets carrying the congestion identifier and the number of all data packets in the detection period.

The congestion identifier may include a ConEx (Congestion Exposure) identifier. The ConEx logo can be understood by reference to the prior art and will not be described here.

The data packet may include an uplink data packet or a downlink data packet.

For example, the following data packet is used as an example. The specific implementation manner of detecting the data packet carrying the congestion identifier may be: when the first ConEx marked downlink packet is detected, the recording is started, and the statistics are detected within a certain period of time. The number of downstream packets of the ConEx tag.

Optionally, the foregoing step 11 is configured to detect a congestion identifier carried by the service flow, and the method may include:

For each UE (User Equipment), the congestion identifier carried by all service flows of the UE is detected.

Or, for each service flow, detecting a congestion identifier carried by the service flow.

It can be seen that the congestion control method in the embodiment of the present invention can detect the service flow granularity or the user granularity.

Optionally, the foregoing step 12 determines a corresponding congestion level according to the detection result and the user priority of the UE that receives the data packet. Can include:

If the congestion threshold is composed of the number of data packets, the corresponding congestion level is determined according to the number of data packets of the detection result and the user priority;

If the congestion threshold is composed of a congestion ratio, the corresponding congestion level is determined based on the congestion ratio of the detection result and the user priority.

In each congestion level, different user priorities correspond to different congestion thresholds. Under the same congestion level, the congestion threshold corresponding to the high user priority is greater than the congestion threshold corresponding to the lower user priority, and the same user takes precedence. Level F, the congestion threshold of the high congestion level is greater than the congestion threshold of the low congestion level.

It can be seen that for different user priorities, the congestion level has different metrics, reflecting the two dimensions of user priority and congestion level.

The metric of the congestion level may be configured on the PCEF entity or the TDF entity, or may be sent by the PCRF entity to the PCEF entity or the TDF entity.

The PCEF entity or the TDF entity may determine the identity characteristics of the user to which the service flow belongs according to the IP-CAN (IP-Connectivity Access Network) session information, such as IMSI (International Mobile Subscriber Identification Number, International Mobile User). The identification code) or MSISDN (Mobile Station Integrated Services Digital Number), etc., and then use the IMSI or MSISDN as the index to query the subscription information database, and the user priority can be obtained.

Optionally, the congestion control policy in step 13 above may include:

Under the same congestion level, the traffic congestion control degree for high user priority is lower than the traffic flow congestion control degree for low user priority;

And/or, under the same user priority, the traffic congestion control degree for the low congestion level is lower than the traffic flow congestion control level for the high congestion level.

It can be seen that a congestion control strategy metric is comprehensively considered from the two dimensions of user priority and congestion level. Moreover, multiple combinations can be implemented by user priority and congestion level, so that the traffic of high priority users or low congestion users can be guaranteed. Optionally, the congestion control policy can be formulated according to the operator policy.

The congestion control policy may be configured on the PCEF entity or the TDF entity, or may be sent by the PCRF entity to the PCEF entity or the TDF entity, or may be sent to the PCEF entity or the TDF entity by the PCRF entity. When the congestion control policy delivered by the PCRF entity affects the bearer parameters, such as QoS (Quality of Service), the PCRF entity can send the congestion control policy to the PCEF entity through the Gx reference point, or through the Gxx reference. The point is sent to the BBERF (Bearing Binding and Event Report Function) entity for execution.

When the congestion control policy is applied to the PCRF entity, the PCC (Policy and Charging Control) rule is used for the PCEF function, or the QoS rule is used to deliver the QoS-BBERF function, or the ADC (Application Detection and Control) is delivered. Application Detection and Control) Rules are used for TDF functions.

Specifically, when the PCRF entity requests to send a congestion control policy to the PCEF entity or the TDF entity, the foregoing step 13 is based on The congestion level and the priority of the household acquire the corresponding congestion control policies, which may include:

The congestion level is sent to the PCRF entity, so that the PCRF entity determines the corresponding congestion control policy according to the user priority and the congestion level; and receives the congestion control policy sent by the PCRF entity.

Alternatively, the congestion level is sent to the PCRF entity; and the congestion control policy corresponding to the user priority of each congestion level sent by the PCRF entity is received.

The PCRF entity may determine the identity characteristics of the user to which the service flow belongs according to the IP-CAN session information, such as IMSI or MSISDN, and then use IMSI or MSISDN as an index to query the subscription information database, and the user priority may be obtained.

It can be seen that the PCRF entity can deliver a set of congestion control policies or a specific congestion control policy according to the report.

Specifically, the PCRF entity is actively sent to the PCEF entity or the TDF entity or the BBERF entity, and the corresponding congestion control policy is obtained according to the congestion level and the user priority in the foregoing step 13, which may include:

Receiving a congestion control policy corresponding to the user priority under each congestion level transmitted by the PCRF entity; and obtaining a matching congestion control policy according to the congestion level.

Alternatively, the congestion control policy corresponding to the user priority sent by the PCRF entity is received, and the congestion control policy corresponding to the user priority is the same under each congestion level; and the matched congestion control policy is obtained according to the congestion level.

It can be seen that the PCRF entity can actively deliver a set of congestion control policies or a specific congestion control policy. Specifically, the congestion control policy may be configured on the PCEF entity or the TDF entity, and the corresponding congestion control policy may be obtained according to the congestion level and the user priority in the foregoing step 13, which may include:

The congestion control policy corresponding to the priority of each user in each congestion level is pre-configured, and the corresponding congestion control policy is obtained according to the congestion level and the user priority.

Optionally, the congestion control mode in the foregoing step 13 may include:

Loss of data packets in the service flow, or block data packets in the service flow, or switch service flows, or modify QoS parameters of data packets in the service flow.

The congestion control performed by the PCEF entity or the TDF entity may include performing packet loss processing on the data packet in the service flow, or blocking the data packet in the service flow, or switching the service flow, or modifying the QoS of the data packet in the service flow. parameter.

The congestion control performed by the BBERF entity includes modifying the QoS parameters of the data packets in the traffic flow.

The congestion control policy for performing packet loss processing on the data packet may include:

Under the same congestion level, the packet loss rate corresponding to the service flow of the high user priority is smaller than the packet loss rate corresponding to the service flow of the low user priority; and/or,

Under the same user priority, the packet loss rate corresponding to the service flow of the low congestion level is smaller than the packet loss rate corresponding to the traffic flow of the high congestion level. It can be seen that under the same congestion level, the traffic congestion control degree for high user priority is lower than the traffic flow congestion control degree for low user priority, and the traffic congestion control for low congestion level under the same user priority level. The degree is lower than the traffic congestion control level for high congestion levels. As shown in FIG. 2, corresponding to the congestion control method of the foregoing embodiment, an embodiment of the present invention provides a congestion control apparatus, including: The detecting unit 21 is configured to detect a congestion identifier carried by the service flow.

The determining unit 22 determines a corresponding congestion level according to the detection result and the W-home priority of the user equipment UE that receives the service flow, and acquires a corresponding congestion control policy according to the congestion level and the user priority.

The control unit 23 is configured to perform congestion control on the service flow according to the acquired congestion control policy.

The executor of the congestion control method in the embodiment of the present invention may be a PGW, and specifically, may be a PCEF entity, or a TDF entity, etc., where the TDF entity includes two types: a built-in TDF and an external TDF.

It can be seen from the technical solution provided by the foregoing embodiments of the present invention that the current traffic congestion is measured by the congestion level and the user priority to perform corresponding service flow control, thereby ensuring the W household priority according to the network congestion.

Specifically, the detecting unit 21 is specifically configured to:

Detecting the number of data packets carrying the congestion identifier in the service flow during the detection period;

The congestion identifier may include a ConEx identifier.

Optionally, the detecting unit 21 is further configured to:

For each UE, a congestion identifier carried by all service flows of the UE is detected.

Specifically, the determining unit 22 is specifically configured to:

In each congestion level, different user priorities correspond to different congestion thresholds. Under the same congestion level, the congestion threshold corresponding to the high user priority is greater than the congestion threshold corresponding to the lower user priority, and the same user takes precedence. Under the level, the congestion threshold of the high congestion level is greater than the congestion threshold of the low congestion level.

Specifically, the congestion control strategy may include:

Specifically, the control unit 23 may be specifically configured to:

Loss of data packets in the service flow, or block data packets in the service flow, or switch service flows, or modify the quality of service QoS parameters of data packets in the service flow.

Under the same congestion level, the packet loss rate corresponding to the service flow of the high user priority is smaller than the packet loss rate corresponding to the service flow of the low user priority; and/or, Under the same Sichuan household priority, the packet loss rate corresponding to the traffic flow with low congestion level is small, and the packet loss rate corresponding to the traffic flow with high congestion level. Optionally, the determining unit 22, the body can be used D:-:

Transmitting the congestion level to the PCRF entity, so that the PCRF entity receives the congestion control policy sent by the PCRF entity according to the congestion priority policy of the Sichuan household priority and the congestion level decision; or The congestion level is sent to the PCRF entity, and receives a congestion control policy corresponding to the user priority under each congestion level sent by the PCRF entity.

Optionally, the determining unit 22 is specifically configured to:

Receiving a congestion control policy corresponding to the user priority in each congestion level of the PCRF entity, and obtaining a matching congestion control policy according to the congestion level; or receiving a congestion control policy corresponding to the user priority sent by the PCRF entity, The congestion control policy corresponding to the user priority is the same under each congestion level, and a matching congestion control policy is obtained according to the congestion level.

Optionally, the determining unit 22 is specifically configured to:

A congestion control policy corresponding to each user priority in each congestion level is pre-configured, and a corresponding congestion control policy is obtained according to the congestion level and the user priority.

The congestion control apparatus and its configuration of the embodiment of the present invention can be understood in accordance with the execution action of the execution subject of the congestion control method of the above embodiment. Embodiment 1

The application scenario of the congestion control method in this embodiment is: the PCEF entity performs the service flow granularity level detection, and reports the congestion level to the PCRF entity; the PCRF entity performs the congestion control policy decision and sends it to the PCEF entity for execution, and the PCEF entity receives the congestion control. After the policy, flow control is performed at the granularity of the service flow.

Specifically, the PCEF entity detects the ConEx identifier information carried in the data packet sent by the sending end, such as an application function (such as an application function), and the identifier may reflect a network bottleneck in the packet forwarding path, such as an eNodeB (Evolved Node B, Current congestion of evolved Node B). In this way, the PCEF can obtain the degree of congestion of the eNodeB indirectly without interacting with the eNodeB, which can reduce the interaction process.

The PCEF entity performs the service flow granularity level detection, including: when the PCEF entity detects the first packet carrying the ConEx identification information, the recording starts, and the number of the packets carrying the ConEx identification information is detected in a certain period of time, and the ConEx identifier is carried. The greater the number of messages, the higher the congestion.

At the same time, for different user priorities, the corresponding congestion level has different metrics. The metric can be configured on the PCEF entity or the PCRF entity. For example, the congestion level of the eNodeB is defined as four levels of ABCD, A to D, and the congestion level is lowered in turn. The user has certain identity characteristics when signing the contract, such as gold, silver, and copper users, and the user priority is lowered from gold to copper. . The metrics can be divided into two types. The first one is the same user. The larger the number of packets carrying ConEx identification information, the higher the congestion level. For the traffic flow of gold users, the congestion levels A and B are detected respectively. 80 and 60 ConEx tagged messages. The second type is that at the same congestion level, the number of low-priority users can be less than that of high-priority users. For a congestion level A, 80 ConEx messages are detected in the gold service flow for a period of time, and the silver medal is The user's service flow detected 70 ConEx messages.

By considering the two dimensions of user priority and congestion level, a congestion control criterion is comprehensively considered. The congestion control standard can It can be configured on the PCEF entity to be configured in the subscription data. The congestion control standard is set according to the operator's policy. Different combinations of W-priority and congestion levels can be used to achieve multiple combinations. For example, even if the low-priority W-type packet congestion is low, it is considered that congestion control is required. High-priority users do not perform congestion control even if the packet congestion is high.

In summary, Table 1 below can be used to reflect the congestion level. The known in Table 1 is the user level such as gold, silver and copper and the number of packets M (only the threshold values of different congestion levels are indicated). Get an unknown ABCD rating.

Table 1: Congestion levels

For example, when it is detected that the gold medal user has 60 ConEx-marked messages within a certain period of time, it indicates that the current congestion level has reached the B level.

For example, the congestion level D can be used for recovery after congestion control. If the PCEF entity detects that a service flow does not have a ConEx marked packet, the congestion level D can cancel the congestion control of the service flow.

Alternatively, another solution for measuring the congestion level is that the PCEF detects the ratio of the number of ConEx tokens in the traffic flow message to the number of packets of the service flow. This requires the PCEF entity to record the number of ConEx-tagged packets and the number of unmarked packets in the traffic stream when detecting the ConEx-tagged packets, calculate the proportion of the ConEx-tagged packets, and measure the congestion level based on the ratio.

Similarly, the criteria for detection similar to Table 1 can be defined and will not be described here.

After the PCEF entity obtains the congestion level, the PCEF entity reports the congestion level to the PCRF entity, and the PCRF entity receives the congestion level and makes a congestion control policy decision. The PCEF entity reports the congestion level by using the existing PCEF to request the PCC rule flow, for example, by setting a new reporting cause value and embodying the congestion level in the cause value. When the congestion level reaches a certain level, the PCEF entity reports the cause value and carries a specific congestion level. The PCRF entity obtains the cause value and the congestion level information therein to make a policy decision. That is, the PCRF entity delivers a targeted policy for the current congestion level.

The PCEF entity executes the policy after receiving the congestion control policy. The specific actions may include the following: Performing different levels of packet loss, blocking the service flow, performing service flow switching, and modifying the service flow according to the user category and the congestion level. QoS parameters, etc.

Optionally, the congestion control policy is used as an example to perform different levels of packet loss in the service flow granularity.

The PCRF entity formulates a packet loss decision based on the user priority and congestion level, and distinguishes different policies by the proportion of the number of lost packets, as shown in Table 2. In order to ensure the priority of the gold medal user, the packet loss rate of the service flow message of the gold card user should be lower than that of the silver card user at the same level of congestion. In addition, for users with the same priority, such as two silver users, the traffic rate corresponding to the user with the lower congestion level is lower. Packet loss rate for different congestion levels and ffl household priorities Different from Table 1,

Packet loss rate.

For example, if the PCEF entity reports that the user's congestion level is B, and the PCRF entity queries the subscription information database to obtain the identity of the user as a silver card user, then the traffic flow of the congestion level B is generated for the silver card user, and 30% of the traffic is executed. package.

For the recovery after congestion control, there may be multiple schemes. For example, when the PCEF entity detects that all the traffic of the service flow does not have the ConEx identifier, the congestion level of the current network eNodeB is D. The PCEF entity reports the congestion level to the PCRF entity, and the PCRF entity modification policy returns to the control mode when there is no congestion.

Optionally, the congestion control policy is used as an example to block the service flow.

Illustratively, the file transfer protocol (FTP) of the Bronze user is congested, and the PCEF entity or the TDF entity corresponds to the corresponding congestion information on the application ID reported by the service flow. Based on the congestion information, the UE sends a policy to the UE, and the UE performs the received policy, and the FTP is generated from the 3GPP (3rd) that generates congestion. Generation Partnership Project) Network (such as UMTS (Universal Mobile Telecommunications System) network or LTE (Long Term Evolution)) network side switch to non-3GPP (non-3GPP access network), such as WLAN (Wireless) Local Area Networks, WLAN side.

For example, the corresponding MBR (Maximum Bit Rate) is lowered, or the gate corresponding to the modified service flow is turned off.

Optionally, the congestion control policy is used as an example to modify the QoS parameters of the service flow, and the description is as follows:

For example, after the PCEF entity detects the congestion information, the Diameter CCR (Credit Control Request) message is reported, and the PCRF entity decides to modify the QoS parameter according to the congestion information, and passes the Diameter CCA (Credit Control Answer). The message is sent by the policy. The PCEF entity executes the policy and modifies QoS parameters, such as reducing the MBR or APN-AMBR (Access Point Name-Aggregate Maximum Bit Rate).

Optionally, the PCRF entity may carry a time parameter when indicating the congestion control policy, and is used to indicate the effective time of the congestion control policy. During this period of time, the congestion control policy is valid, and the PCEF entity performs the corresponding action; after the time arrives, the congestion control policy is deactivated, and the PCEF entity no longer performs the corresponding action. After this point in time, the PCEF entity can perform a new congestion level detection.

The following describes the congestion control method in this embodiment in detail, as shown in FIG. 3, including:

31. After the IP-CAN session is established, the UE performs the service, and the downlink data packet is sent to the eNodeB. eNodeB performs packet forwarding Yes, it detects whether the current queue is congested as a congestion warning. When the congestion congestion warning occurs, the ECT (ECN-capable transport, ECM, Explicit Congestion Notification) indicator is marked in the forwarded downlink data packet.

32. The eNodeB sends the data packet to the UE by using the air interface resource, where the data packet carries the ECT identifier.

33. The UE receives the downlink data packet, and detects the ECT flag in the downlink data packet. The UE simultaneously detects packet loss during the forwarding process of the downlink data packet.

34. The UE feeds back the ECT identification information of the eNodeB to the AF.

35. AF marks Re-echo-ECN in the data packet according to the ECT identification information, and marks Re-echo-Loss according to the retransmission information of the message, and estimates that the appropriate Credit AF uses these two types of information as the ConEx identifier. Information, marked in the downstream data message. The line data packet is sent to the UE through the intermediate routing device.

The PCEF entity performs the service flow level detection on the downlink data packet. When the first ConEx marked packet is detected, the number of the ConEx identifier information is counted to measure the current congestion level. As shown in Table 1, the PCEF detects that there is 50 ConEx-labeled packets in a certain service flow for a period of time, indicating that the congestion level is B.

37. The PCEF entity reports the congestion level information to the PCRF entity. If the PCEF entity reuses the existing CCR/CCA process, the congestion level is reported as B.

38. The PCRF entity receives the congestion information reported by the PCEF entity, and the PCRF entity determines the identity feature of the user to which the service flow belongs according to the IP-CAN session information. The PCRF entity formulates a congestion control policy based on the identity characteristics and congestion information. For example, the PCRF entity determines that the service flow belongs to a silver card user according to the session information in the CCR. According to Table 2, a congestion of 30% is performed by the congestion level B and the identity characteristics of the silver card user.

39. The PCRF entity sends the congestion control policy to the PCEF entity.

310. The PCEF entity performs a congestion control policy. For example, according to Table 2, the PCEF entity performs 30% packet loss on the service flow. Steps 31 to 35 describe the existing processes of ECN (Explicit Congestion Notification) and ConEx in the prior art, and therefore no description is made.

Steps 39 to 310 can refer to the corresponding processes of the prior art.

In Figure 3, the V-PCRF is a functional entity in a roaming scenario, and is not described here. Embodiment 2

The difference between the embodiment and the first embodiment is that: when performing the congestion level detection, the PCEF entity detects the user granularity, that is, detects the service flow corresponding to all the rules in the IP-CAN session, and the PCEF entity counts the multiple users. Congestion caused by traffic flow over a period of time, measuring the level of congestion at that user level. The PCEF entity then reports the congestion level to the PCRF entity, and the PCRF entity makes user-level policy decisions. Embodiment 3

The application scenario of the congestion control method in this embodiment is: the PCRF entity performs policy decision according to the operator policy and the pre-configured congestion level, and actively sends a congestion control policy; the PCEF entity performs service flow granularity congestion detection, and matches the corresponding policy. carried out The corresponding action.

The following describes the congestion control method in this embodiment in detail, as shown in FIG. 4, including:

41. After the IP-CAN session is established, the UE performs the service, and the downlink data packet is sent to the eNodeB. The eNodeB performs packet forwarding to detect whether the current queue is congested as a congestion warning. When a congestion congestion warning occurs, the ECT is marked in the forwarded downlink data message.

42. The eNodeB sends the data packet to the UE by using the air interface resource, where the data packet carries the ECT identifier.

43. The UE receives the downlink data packet, and detects the ECT flag in the downlink data packet. The UE simultaneously detects packet loss during the forwarding process of the downlink data packet.

44. The UE feeds back the ECT identification information of the eNodeB to the AF.

45. The AF marks the Re-echo-ECN in the downlink data packet according to the ECT identification information, and marks the packet according to the retransmission information of the packet.

Re-echo-Loss, and estimate the appropriate Credit. AF uses these three types of information as ConEx identification information and marks it in the data packet. The downlink data packet is sent to the UE through the intermediate routing device.

46. The PCRF entity actively performs policy decision according to the operator policy and the user identity and a predefined set of congestion levels, and obtains a set of congestion control policies corresponding to a congestion level of a certain service flow. For example, for a certain service flow, when the PCC rule is delivered, the PCRF entity simultaneously delivers a congestion control policy for the service flow. As shown in Table 3, for the service flow of the gold card user, the PCRF entity sets a corresponding packet loss rate for each of the four congestion levels of the ABCD.

Table 3: Congestion Control Strategies

The metric of the congestion level can be statically configured on the PCEF entity, or can be actively sent by the PCRF entity while the policy is being sent. The metrics for different levels of congestion can also be used as a set of information, as shown in Table 4, which only shows the threshold values for different congestion levels.

Table 4: Congestion levels

47. The PCRF entity sends a congestion control policy to the PCEF entity. The PCRF entity can reuse the RAR (Re-Authorization-Request) procedure to send the congestion control policy to the PCEF entity. 48. The PCEF entity sends a RAA (Re- Authorization-Answer) response message to the PCRF entity.

49. The PCEF entity performs the service flow level detection on the data packet. When the first ConEx marked packet is detected, the number of the ConEx identifier information is counted to measure the current congestion level. Assume that at this time, the PCEF detects that there is 50 ConEx-tagged packets in a certain service flow for a period of time, and the inquiry table 4 can obtain the congestion level at the C level.

410. The PCEF entity obtains the congestion level C according to the calculation, performs policy matching in Table 3, and performs policy control according to the matched result, that is, discards 10% of the current service flow.

Steps 41~45 describe the existing processes of ECN and ConEx in the current technology.

Steps 47 to 48 describe the existing flow of the active delivery strategy of the PCRF entity in the prior art.

The V-PCRF in Figure 4 is a functional entity in a roaming scenario, and is not described here. Embodiment 4

The difference between the embodiment and the foregoing embodiment is that the PCEF entity performs the detection of the user granularity when performing the congestion level detection, calculates the congestion degree of all the packets in the user granularity, reports the congestion level, and executes the corresponding policy. Embodiment 5

The application scenario of the congestion control method in this embodiment is as follows: The external TDF entity performs the service flow granularity level detection, and reports the congestion level to the PCRF entity. The PCRF entity performs policy decision and sends it to the external TDF entity for execution. After receiving the congestion control policy, the external TDF entity performs flow control at the service flow granularity.

When the congestion control policy (such as modifying QoS) delivered by the PCRF entity affects the bearer parameters, the PCRF entity sends the congestion control policy F to the PCEF entity through the Gx reference point (GTP-based S5/S8) or through the Gxx reference. The point congestion control policy is implemented for the BBERF (Bearing Binding and Event Report Function) entity (PM IP-based S5/S8).

As shown in FIG. 5, the congestion control method in this embodiment is described in detail, including:

51. After the IP-CAN session is established, the UE performs the service, and the downlink data packet is sent to the eNodeB. The eNodeB performs packet forwarding to detect whether the current queue is congested or congestion. When a congestion or congestion warning occurs, the ECT is marked in the forwarded downlink data packet.

The eNodeB sends the downlink data packet to the UE by using the air interface resource, where the downlink data packet carries the ECT identifier.

53. The UE receives the downlink data packet, and detects the ECT flag in the downlink data packet. The UE simultaneously detects packet loss during the forwarding process of the downlink data packet.

54. The UE feeds back the ECT identification information of the eNodeB to the AF.

55. The AF marks the Re-echo-ECN in the downlink data packet according to the ECT identification information, and marks the Re-echo-Loss according to the retransmission information of the packet, and estimates that the appropriate Credit AF uses the three types of information as the ConEx identification information. Mark in the downlink data message. The downlink data packet is sent to the UE through the intermediate routing device.

56. The external TDF entity performs the service flow level detection on the line data packet. When the first ConEx marked packet is detected, the number of the ConEx identifier information is counted to measure the current congestion level. Such as external TDF entities according to Table 1, A packet of 50 ConEx marks is detected in a certain service flow for a period of time, indicating that the congestion level is B.

57. The external TDF entity reports congestion level information to the PCRF entity. If the ffiTDF entity reuses the existing CCR/CCA process, it reports the congestion level B. A similar reporting method can be used to detect the traffic level of the current service flow/user and report it to the policy control network element.

The PCRF entity receives the congestion information reported by the external TDF, and the PCRF entity determines the identity feature of the user to which the service flow belongs according to the session information. The PCRF entity formulates a congestion control policy based on the identity characteristics and congestion information. For example, the PCRF entity determines that the service flow belongs to the silver card user according to the session information in the CCR, and according to Table 2, through the congestion level B and the identity characteristics of the silver card user, a 30% packet loss action is determined.

59. The PCRF entity sends the congestion control policy to the external TDF entity.

510. The external TDF entity performs a congestion control policy, that is, the external TDF entity performs 30% packet loss on the service flow.

When the congestion control policy formulated by the PCRF entity affects the bearer operation, such as reducing the MBR/APN-AMBR, the PCRF formulates the corresponding PCC policy or QoS policy according to the level, and the PCRF entity sends the rule to the PCEF entity through the RAR message. Or BBERF (not shown) entity execution. For example, the PCRF entity decides to reduce the bandwidth parameter of the service flow, and the PCRF entity sends the congestion control policy to the PCEF entity through the Gx session or to the BBERF entity through the Gxx session.

512. The PCEF entity or the BBERF entity replies with a corresponding message, indicating that the congestion control policy is executed.

513. The PCEF entity receives the updated PCC rule, and modifies the bearer according to the congestion control policy. When the downlink data packet is forwarded, the maximum bandwidth of the packet is reduced by controlling the bearer.

Alternatively, the BBERF entity receives an updated QoS rule (RAR QoS rule), and modifies the bearer according to the congestion control policy.

Steps 51 to 55 can refer to the corresponding processes of the prior art.

Steps 59 to 513 can refer to the corresponding processes of the prior art.

The V-PCRF in Figure 5 is a functional entity in a roaming scenario, and is not described here. Embodiment 6

The difference between the embodiment and the foregoing embodiment 5 is that the external TDF entity performs the congestion level detection of the user granularity, collects the packet congestion degree of all service flow granularities in the user granularity, and reports the congestion level to the PCRF entity. Example 7

The scenario described in this embodiment is: The PCRF performs policy decision according to the definition of the operator policy and the congestion level, and actively sends a congestion control policy; the external TDF entity performs traffic flow granularity congestion detection, matches the corresponding congestion control policy, and executes The corresponding action.

When the congestion control policy delivered by the PCRF affects the bearer parameters, such as modifying the QoS, the PCRF entity sends the congestion control policy to the PCEF entity through the Gx reference point (GTP-based S5/S8) or through the Gxx reference point. The congestion control policy is enforced for the BBERF entity (PM IP-based S5/S8).

As shown in FIG. 6, the congestion control method in this embodiment is described in detail, including: 61. After the IP-CAN session is established, the UE performs the service, and the downlink data packet is sent to the eNodeB. The eNodeB performs packet forwarding to detect whether the current queue is congested as a congestion warning. When a congestion congestion warning occurs, the ECT is marked in the forwarded line data message.

62. The eNodeB sends the data packet to the UE by using the air interface resource, where the data packet carries the ECT identifier.

63. The UE receives the downlink data packet, and detects the ECT flag in the downlink data packet. The UE simultaneously detects packet loss during the forwarding process of the downlink data packet.

64. The UE feeds back the ECT identification information of the eNodeB to the AF.

65. The AF marks the Re-echo-ECN in the downlink data packet according to the ECT identification information, and marks the Re-echo-Loss according to the retransmission information of the packet, and estimates that the appropriate Credit AF is used as the ConEx identification information. , marked in the downlink data message. The downlink data packet is sent to the UE through the intermediate routing device.

66. The PCRF entity actively performs policy decision according to the operator policy and the user identity and a predefined set of congestion levels, and obtains a set of congestion control policies corresponding to a congestion level of a certain service flow. For example, for a certain service flow, when the ADC rule is sent, the PCRF entity simultaneously delivers a congestion control policy for the service flow. For the business flow of the Ding-the gold card user, the PCRF entity separately sets the corresponding packet loss rate for the four congestion levels of the ABCD. See Table 3.

The metric of the congestion level can be statically configured on the external TDF, or can be actively sent by the PCRF while the policy is being issued. Metrics for different levels of congestion can also be used as a set of information, as shown in Table 4.

67. The PCRF entity sends out a congestion control policy to the TDF entity. The PCRF entity can use the TSR (TDF-Session-Request) message or the RAR message to actively send the congestion control policy to the external TDF entity, which is a set of policies with different congestion levels.

68. The external TDF entity sends a response message to the PCRF.

69. The external TDF entity performs the service flow level detection on the line data packet. When the first ConEx marked message is detected, the number of the ConEx identifier information is counted to measure the current congestion level. Assume that at this time, the external TDF entity detects that there is 50 ConEx-tagged packets in a certain service flow for a period of time, and the query table 4 can obtain the congestion level of C at this time.

610. The external TDF entity performs policy matching according to the calculated congestion level C, and performs policy control according to the matched result, that is, discards 10% of the current service flow.

61 1. When the congestion control policy formulated by the PCRF entity affects the bearer operation, such as reducing the MBR/APN-AMBR, the PCRF requires the TDF to report the congestion level.

612. The PCRF formulates a corresponding PCC policy or a QoS policy according to the level. The PCRF entity delivers the rule to the PCEF entity or the BBERF (not shown) entity through the RAR message. For example, the PCRF entity decides to reduce the bandwidth parameter of the service flow, and the PCRF entity sends the policy to the PCEF entity through the Gx session or to the BBERF entity through the Gxx session.

613. The PCEF entity or the BBERF entity replies with a corresponding message, indicating that the policy execution is completed.

614. The PCEF entity receives the updated PCC rule, and the BBERF entity receives the updated QoS rule, and modifies the bearer according to the policy. When the downlink data packet is forwarded, the maximum bandwidth of the packet is reduced by controlling the bearer.

Steps 61 to 65 can refer to the corresponding processes of the prior art.

Steps 67 to 68, and steps 61 to 614, refer to the corresponding processes of the prior art. The V-PCRF in Figure 6 is a functional entity in a roaming scenario, and is not described here. Example eight

The difference between this embodiment and the foregoing embodiment 7 is that the PCRF performs policy decision according to the definition of the operator policy and the congestion level, and actively issues the policy; the external TDF entity performs the user level congestion level detection, and matches Corresponding strategies and perform the corresponding actions. It can be seen from the technical solution provided by the foregoing embodiments of the present invention that the current traffic congestion is measured by the congestion level and the user priority to perform corresponding service flow control, and the user priority can be ensured according to the network congestion. A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium, the program In execution, the flow of an embodiment of the methods as described above may be included. The storage medium may be a magnetic disk, an optical disk, or a read-only storage memory.

(Read-Only Memory, ROM) or Random Access Memory (RAM).

The above is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or within the technical scope of the present disclosure. Alternatives are intended to be covered by the scope of the present invention. Therefore, the scope of the invention should be determined by the scope of the claims.

Claims

1. A congestion control method, characterized by D, including:

Detecting a congestion identifier carried by the service flow;

Determining a corresponding congestion level according to the detection result and the user priority of the W-device UE receiving the service flow; acquiring the corresponding congestion control policy according to the congestion level and the W-home priority, and congesting the service flow control.

The method according to claim 1, wherein the detecting the congestion identifier carried by the service flow comprises: detecting, during the detection period, the number of data packets carrying the congestion identifier in the service flow;

In the detection period, the number of data packets carrying the congestion identifier in the service flow is detected, and the congestion ratio of the number of data packets carrying the congestion identifier and the number of all data packets in the detection period is obtained. .

3. The method according to claim 1 or 2, wherein the congestion identifier comprises a congestion-aware ConEx identifier.

The method according to claim 2, wherein the determining the corresponding congestion level according to the detection result and the user priority of the UE receiving the service flow includes:

If the congestion threshold is composed of the number of data packets carrying the congestion identifier, determining a corresponding congestion level according to the detected number of data packets carrying the congestion identifier and the user priority of the UE receiving the service flow;

If the congestion threshold is composed of a congestion ratio, the corresponding congestion level is determined according to the detected congestion ratio and the user priority of the UE receiving the service flow.

5. The method according to claim 4, characterized in that, under each congestion level, different user priorities correspond to different congestion thresholds, and under the same congestion level, congestion thresholds corresponding to high user priorities The congestion threshold is greater than the low user priority. Under the same user priority, the congestion threshold of the high congestion level is greater than the congestion threshold of the low congestion level.

The method according to claim 1 or 2, wherein the congestion control policy comprises:

The method according to claim 1 or 2, wherein the performing congestion control on the service flow comprises: performing packet loss processing on a data packet in the service flow, or blocking data packet in the service flow , or switch the service flow, or modify the quality of service QoS parameters of the data packet in the service flow.

The method according to claim 7, wherein the congestion control policy for performing packet loss processing on the data packet in the service flow specifically includes:

Under the same congestion level, the packet loss rate corresponding to the traffic flow of the high user priority is small - the packet loss rate corresponding to the traffic flow of the low user priority; and / or,

Under the same user priority, the packet loss rate corresponding to the traffic flow with low congestion level is small. The packet loss rate corresponding to the traffic flow with high congestion level.

The method according to claim 1 or 2, wherein the obtaining a corresponding congestion control policy according to the congestion level and the user priority comprises:

Sending the congestion level to a policy charging rule function PCRF entity, so that the PCRF entity preferentially according to the user The congestion control policy corresponding to the congestion level decision is received by the PCRF entity, and the congestion control policy sent by the PCRF entity is sent to the PCRF entity, and the congestion level sent by the PCRF entity is received. The congestion control policy corresponding to the user priority.

The method according to claim 2, wherein the method for obtaining a corresponding congestion control policy according to the congestion level and the user priority includes:

Receiving a congestion control policy corresponding to the user priority under each congestion level sent by the PCRF entity, and obtaining a matching congestion control policy according to the congestion level;

Alternatively, the congestion control policy corresponding to the user priority sent by the PCRF entity is received, and the congestion control policy corresponding to the user priority is the same under each congestion level, and the matched congestion control policy is obtained according to the congestion level.

The method according to claim 1 or 2, wherein the obtaining a corresponding congestion control policy according to the congestion level and the user priority includes:

The method according to claim 1 or 2, wherein the detecting the congestion identifier carried by the service flow comprises: detecting, for each UE, a congestion identifier carried by all service flows of the UE.

13. A congestion control device, comprising:

The device according to claim 13, wherein the detecting unit is specifically configured to:

The apparatus according to claim 13 or 14, wherein the congestion identifier comprises a congestion-aware ConEx identifier.

16. The apparatus according to claim 14, wherein the determining unit, the A body is configured to:

The device according to claim 16, wherein, under each congestion level, different user priorities correspond to different congestion thresholds, and under the same congestion level, the congestion threshold corresponding to the high user priority is greater than The congestion threshold corresponding to the user priority. Under the same user priority, the congestion threshold of the high congestion level is greater than the congestion threshold of the low congestion level.

The device according to claim 13 or 14, wherein the congestion control policy comprises: Under the same congestion level, the degree of traffic congestion control for the Takagawa priority is lower than that of the low-kawa household priority;

And /, the same W household priority level ', low traffic congestion control level for low congestion level 拥 congestion control level for high congestion level traffic.

The device according to claim 13 or 14, wherein the control unit is specifically configured to:

The device according to claim 19, wherein the congestion control policy for performing packet loss processing on the data packet in the service flow specifically includes:

Under the same congestion level, the packet loss rate corresponding to the traffic flow of the high user priority is small, and the packet loss rate corresponding to the traffic flow of the low user priority; and/or,

Under the same user priority, the packet loss rate corresponding to the service flow of the low congestion level is smaller than the packet loss rate corresponding to the traffic flow of the high congestion level.

The device according to claim 13 or 14, wherein the determining unit is specifically configured to:

Sending the congestion level to the policy and charging rule function PCRF entity, so that the PCRF entity receives the congestion control policy sent by the PCRF entity according to the user priority and the congestion control policy corresponding to the congestion level decision; Or sending the congestion level to the PCRF entity, and receiving a congestion control policy corresponding to the user priority under each congestion level sent by the PCRF entity.

Receiving a congestion control policy corresponding to the user priority under each congestion level of the PCRF entity, determining a matching congestion control policy according to the congestion level; or receiving a congestion control policy corresponding to the user priority sent by the PCRF entity, The congestion control policy corresponding to the user priority is the same under each congestion level, and the matched congestion control policy is determined according to the congestion level.

The apparatus according to claim 13 or 14, wherein the determining unit is specifically configured to:

The device according to claim 13 or 14, wherein the detecting unit is specifically configured to:

For each UE, detecting a congestion identifier carried by all service flows of the UE.

The apparatus according to claim 13 or 14, wherein the apparatus comprises a policy and charging execution function PCEF entity, or a flow detection function TDF entity.