WO2012062193A1

WO2012062193A1 - Method, device, and system for congestion control in mtc handover

Info

Publication number: WO2012062193A1
Application number: PCT/CN2011/081872
Authority: WO
Inventors: 谢宝国; 李志军; 支春霞
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-11-08
Filing date: 2011-11-07
Publication date: 2012-05-18
Also published as: CN102469503A

Abstract

Disclosed is a method for congestion control in MTC handover, the method comprising: in an MTC handover process, a target eNodeB or a target MME determining whether the target eNodeB or the target MME is in a network congestion state according to acquired MTC information of an MTC terminal and a current network load status; if yes, refusing the current handover; otherwise, continuing the current handover. Also disclosed are a device and a system for congestion control in MTC handover. The effects of the MTC handover on the current network are decreased to the lowest degree, so that a routine service of a common UE is not affected by frequent handover when a large number of MTC terminals move, thereby effectively preventing network congestion, and effectively using network resources to the greatest degree through network optimization.

Description

Congestion control method, device and system in MTC handover

The present invention relates to a handover technique in the field of machine to machine (M2M), and more particularly to a congestion control method, apparatus, and system in MTC handover. Background technique

In recent years, M2M communication services have gradually begun to be applied, such as logistics systems, remote meter reading, smart homes and so on. The M2M service provider uses the existing wireless network, such as the General Packet Radio Service (GPRS) network, and the Evolved Packet System (EPS) network to carry out M2M services. Because of the obvious difference between the M2M service and the human to human (H2H) communication service, it is necessary to optimize the existing network to obtain the best network management and network communication quality.

With the development of wireless broadband technology, the performance requirements of the service layer for the bandwidth and delay of the transport layer are getting higher and higher. In order to improve its network performance and reduce network construction and operation costs, 3GPP is committed to the study of System Architecture Evolution (SAE), which aims to enable EPC (Evolved Packet Core) to provide higher transmission rates. , shorter transmission delay, optimized packet, and Evolved Universal Terrestrial Radio Access Network (E-UTRAN), UMTS Terrestrial Radio Access Network (UTRAN), Mobility management between wireless local area networks (WLANs) and other access networks other than 3GPP (Third Generation Partnership Projects).

The architecture of the existing SAE is as shown in FIG. 1. The network element included in the evolved radio access network (E-RAN, Evolved Radio Access Network) is an evolved Node B (eNodeB, Evolved NodeB), which is used for the user. Access to provide wireless resources; packet data network (PDN, Packet Data Network is a network that provides services to users; EPC provides lower latency and allows more wireless access systems to access, including the following network elements:

The Mobility Management Entity (MME) is a control plane function entity that temporarily stores user data. It is responsible for managing and storing the context of user equipment (UE, User Equipment), such as user identification, mobility management status, and user security. The parameter, etc., allocates a temporary identifier to the user, and when the UE is camped on the tracking area or the network, it is responsible for authenticating the user.

The Serving Gateway (S-GW) is a user plane entity that is responsible for user plane data routing processing and terminates downlink data of UEs in idle (ECM_IDLE) state. Manage and store the SAE bearer context of the UE, such as IP bearer service parameters and network internal routing information. The S-GW is the anchor point of the internal user plane of the 3GPP system. A user can only have one S-GW at a time.

The packet data network gateway (PGW, PDN Gateway) is the gateway responsible for the UE accessing the PDN, and assigns the user IP address. It is also the mobility anchor of the 3GPP and non-3GPP access systems. The PGW functions include policy implementation and charging support. . Users can access multiple PGWs at the same time. The Policy and Charging Enforcement Function (PCEF) is also located in the PGW.

The Policy and Charging Rules Function (PCRF) is responsible for providing policy control and charging rules to the PCEF. User Subscription Database (SPR, Subscription Profile Repository) is used to manage contracted policies and PCC rules.

The Home Subscriber Server (HSS) is responsible for permanently storing user subscription data. The content stored in the HSS includes the UE's International Mobile Subscriber Identification (IMSI) and the IP address of the PGW.

Physically, the SGW and the PGW may be unified. The EPC system user plane network element includes the SGW and the PGW. MTC Server (Machine Type Communication Server) is mainly responsible for information collection and data storage/processing of MTC equipment, and necessary management of MTC equipment.

The Machine Type Communication User Equipment (MTC), similar to the UE, is usually responsible for collecting information of several collectors and accessing the core network through the RAN node and interacting with the MTC Server. M2M service is a networked application and service based on intelligent interaction of machine terminals. It uses intelligent machine terminals to transmit information through wireless networks, and provides information solutions for customers to meet customer monitoring, command and dispatch. Information needs for data collection and measurement.

In the prior art, when the source eNodeB moves from the source eNodeB to the target eNodeB, the source eNodeB needs to initiate the handover, and the source eNodeB can initiate the handover from the X2 interface and the S1 interface. When the target eNodeB or the target MME is in the network congestion state, This switch request can be rejected.

FIG. 2 is a process of describing an X2 handover performed by a radio side to a target eNodeB when the UE is moved to the target eNodeB by the UE, specifically including:

S201: The UE accesses the EPS network, and performs data interaction with the remote end by using the established EPS bearer.

S202, the source eNodeB initiates a measurement control command to the UE, and configures the location restriction information and the measurement rule of the UE.

5203, the UE, according to the measurement rule or system information, the location information is included in the measurement report and sent to the source eNodeB;

S204: The source eNodeB selects the target eNodeB according to the location information provided in the measurement report, and determines to initiate the handover.

5205. The source eNodeB initiates a handover (HO, handover) request to the target eNodeB, and carries a radio bearer setup context (RRC context), a target cell identifier (Target Cell ID), a signaling context (Signling context), and a radio resource assignment context (E- RAB context ) Waiting for the HO parameter to the target eNodeB;

S206. If the target eNodeB allows handover, allocate radio resources according to the QoS (Quality of Service) parameter in the E-RAB. When the eNodeB is in a congested state and there is no available radio resource, the target eNodeB rejects the handover request initiated by the source eNodeB;

S207. The target eNodeB is congested, and sends a handover reject message (HO failure) to the source eNodeB, rejecting the request of the source eNodeB.

S208: After receiving the handover reject message, the source eNodeB selects another available target eNodeB according to the cell ID of the UE, and attempts to initiate the handover.

5209. When the target eNodeB accepts the handover request of the source eNodeB, the source eNodeB needs to send an RRC reconfiguration message to the UE, and switch the wireless connection of the UE to the target eNodeB.

FIG. 3 is a process of the S1 handover performed by the core network side when the UE is moved to the target eNodeB by the source eNodeB in the prior art, and specifically includes:

S301. The UE accesses the EPS network, and performs data interaction with the remote end by using the established EPS bearer.

S302, the source eNodeB determines to initiate a handover to the target eNode through the S1 interface (HO is initiated);

S303. The source eNodeB initiates a handover request (HO request;) to the source MME, and carries the transparent data of the source eNodeB to the target eNodeB, the target tracking area identifier (targer TAI), and the ID of the target eNodeB.

S304, the source MME selects the target MME according to the Target TAI information, and sends a forward redirect request to the target MME, where the MME UE context, the target tracking area identifier Target TAI, and the source eNodeB to the target eNodeB transparent data are carried. Information such as the ID of the target eNodeB, and the MME UE context includes information such as an IMSI, a terminal capability, an S-GW address, a P-GW address, and an APN.

S305. The target MME determines, according to the Target TAI, whether a new S-GW needs to be selected. Selecting a new S-GW, the target MME needs to re-establish the EPS bearer between the target S-GW and the P-GW;

5306, the target MME sends a handover request message (for example, a redirection request) to the target eNodeB, and carries the S-GW entry address, the EPS Bear QoS parameter, the source eNodeB to the target eNodeB transparent data, and requests to perform handover;

5307. The target eNodeB is in network congestion, and if there is no radio resource allocation, the handover request is rejected.

S308. The target eNodeB sends a handover failure message (for example, a redirection request rejection) to the target MME, rejects the handover request, and the target MME releases the network resource reserved for the terminal.

S309. Optionally, the target MME deletes the established session by sending a delete session request message.

EPS bearer resources;

The target MME sends a forward redirect redirection message to the source MME, rejecting the current handover;

5311. After receiving the redirect reject message, the source MME returns a handover failure message (HO failure) to the source eNodeB.

The number of MTC terminals may be more than 10 times the number of mobile terminals. Each MTC terminal has access to the 3GPP network for data communication as long as it has a 3GPP communication module. If a large-scale deployment of MTC terminals accesses concurrent data at the same time, it will inevitably bring congestion to all levels of the wireless network, signaling network, and data transmission, causing M2M devices to access and transmit data barriers, which may seriously cause network defects. .

The prior art only proposes a handover method initiated by the source eNodeB for a common terminal such as a mobile phone. However, for the MTC terminal, there is no corresponding method yet. If the handover of the MTC terminal is performed according to the method of the ordinary terminal, the MTC will be used because of the MTC. The number of terminals is far greater than that of ordinary terminals, which has a lot of impact on the services of the existing network, such as congestion on the existing network, which affects the normal use and user experience of the existing network services. Therefore, it is necessary to propose a corresponding congestion control scheme when switching to the MTC terminal, so as to distinguish the switching between the MTC terminal and the ordinary terminal, and find a more optimized and capable It is applicable to the handover method for the MTC terminal. The handover caused by the movement of the MTC terminal does not affect the normal service of the ordinary terminal, so as to prevent network congestion, and optimize the network resources to the maximum extent through network optimization. Summary of the invention

In view of the above, the main object of the present invention is to provide a congestion control method, apparatus, and system for MTC handover, which are to solve the problem that the handover caused by MTC terminal mobility affects the normal service of the ordinary terminal and causes network congestion.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

The present invention provides a congestion control method in an MTC handover, where the method includes: in a process of performing an MTC handover, the target eNodeB or the target MME determines according to the acquired MTC information of the MTC terminal and the current network load state. Whether it is in a network congestion state, if yes, refuses to perform the current handover; otherwise, continues the current handover.

In the above solution, the target eNodeB determines whether the network is in a network congestion state according to the obtained MTC information of the MTC terminal and the current network load status, and is: according to the received handover request initiated by the source eNodeB. The MTC information of the MTC terminal, and the current network load status, the target eNodeB determines whether it is in a network congestion state; if yes, rejects the handover request of the source eNodeB, and sends a handover failure message to the source eNodeB; otherwise, accepts the Switch the request and continue the subsequent operations of the current switch.

In the above solution, before the target eNodeB receives the handover request initiated by the source eNodeB, the method further includes: acquiring, by the source eNodeB, the MTC information of the MTC terminal from the MTC terminal or the source MME, and The target eNodeB initiates a handover request carrying the MTC information.

In the above solution, the target MME determines whether it is in a network congestion state according to the obtained MTC information of the MTC terminal and the current network load status, and is: according to the forward forwarding redirection request sent by the source MME. MTC information of the MTC terminal carried, And the current network load status, the target MME determines whether it is in a network congestion state; if yes, rejects the forward redirect request, and sends a forward redirect request rejection message to the source MME; otherwise, accepts the source MME Forwards the redirect request and sends a redirect request to the currently switched target eNodeB.

In the above solution, before the target MME receives the forward redirection request that carries the MTC information, the method further includes: the source MME acquiring the MTC information of the MTC terminal, and sending the MTC information to the target MME Send a forward redirect request carrying the MTC information.

In the above solution, the source MME acquires the MTC information, when the MTC terminal is attached to the network where the source MME is located, the MTC terminal carries its own MTC information to the source MME by using an attach request; Or, when the MTC terminal is attached to the network where the source MME is located, the source MME obtains the MTC information of the MTC terminal from the quality of service (QoS) parameter of the MTC terminal.

In the foregoing solution, the target MME sends a redirection request to the currently-switched target eNodeB, where: the target MME sends a redirection request carrying the MTC information of the MTC terminal to the currently-switched target eNodeB; The method further includes: the target eNodeB receiving the redirect request, determining, according to the MTC information of the MTC terminal carried in the redirect request, and the current network load status, whether the network is currently in a network congestion state, and if yes, rejecting the Redirecting a request, sending a redirect request rejection message to the target MME; otherwise, continuing the subsequent operation of the current handover.

In the above solution, after the target eNodeB sends a redirect request rejection message to the target MME, the method further includes: after receiving the redirect request rejection message, the target MME sends the source MME to the current handover. Returning a forward redirect request rejection message, rejecting the current forward redirect request of the source MME; afterwards, the source MME reselects the target MME, and sends a forward carrying the MTC information to the selected target MME Redirecting the request; or, the source MME returns a handover failure message to the source eNodeB of the current handover, notifying the source The eNodeB currently fails to switch.

In the foregoing solution, the handover failure message, and the forward redirection request rejection message include a cause value and/or a waiting time, where the cause value is an indication that the target eNodeB or the target MME is currently in a network congestion state; The waiting time is used to indicate the time elapsed by the source eNodeB or the source MME from the current rejection to the selection of the target eNodeB or the target MME again.

In the above solution, the MTC information includes any one or more of the following three types of information: an MTC indication (MTC Indication), a 氐 priority indication (Low Priority), and an MTC ARP.

The present invention also provides a congestion control apparatus in an MTC handover, where the apparatus includes: an obtaining unit, a determining unit, a rejecting unit, and an accepting unit, wherein the acquiring unit is configured to acquire the MTC during the MTC switching process. a determining unit, configured to determine, according to the MTC information of the MTC terminal acquired by the acquiring unit, and the current network load status, whether the target eNodeB or the target MME is in a network congestion state, and if yes, starting the rejecting unit, Otherwise, the accepting unit is activated; the rejecting unit is used to reject the current switching; and the accepting unit is used to continue the current switching.

The present invention also provides a congestion control system in an MTC handover, where the system includes: a source eNodeB and a target eNodeB, where the source eNodeB is configured to acquire MTC information of the MTC terminal from an MTC terminal or a source MME, and The target eNodeB initiates a handover request that carries the MTC information. The target eNodeB includes: a first acquiring unit, a first determining unit, a first rejecting unit, and a first accepting unit, where the first acquiring unit is configured to receive the Determining the MTC information of the MTC terminal carried in the handover request initiated by the source eNodeB; the first determining unit, configured to: according to the MTC information of the MTC terminal carried in the handover request received by the first obtaining unit, and the current network load status, Determining whether the target eNodeB itself is in a network congestion state, if yes, starting the first rejecting unit, otherwise starting the first accepting unit; the first rejecting unit, for rejecting the switching request of the source eNodeB, The source eNodeB sends a handover failure message; a first accepting unit, configured to accept a handover request of the source eNodeB, and continue a subsequent operation of the current handover.

The present invention also provides a congestion control system in an MTC handover, the system includes: a source MME and a target MME, where the source MME is configured to acquire MTC information of the MTC terminal, and send the carried to the target MME The forwarding request of the MTC information; the target MME includes: a second acquiring unit, a second determining unit, a second rejecting unit, and a second receiving unit, where the second acquiring unit is configured to receive the carried by the target MME a request for redirection of the MTC information of the MTC terminal; the first determining unit, configured to determine, according to the MTC information of the MTC terminal carried in the redirection request received by the second obtaining unit, and the current network load status, the target MME itself Whether the network is in a network congestion state, if yes, the second rejection unit is started, otherwise, the second accepting unit is started; the first rejecting unit is configured to reject the forward redirect request, and send a forward redirect redirect to the source MME. Requesting a reject message; a first accepting unit, configured to accept a forward redirect request of the source MME, to the currently switched target eNodeB Send redirection request.

In the foregoing solution, the second receiving unit of the target MME is configured to send, to the currently switched target eNodeB, a redirection request that carries the MTC information; the system further includes: the target eNodeB, where the target eNodeB includes a third obtaining unit, a third determining unit, a third rejecting unit, and a third accepting unit, wherein the third obtaining unit is configured to receive the redirect request sent by the second accepting unit of the target MME; a determining unit, configured to determine, according to the MTC information of the MTC terminal carried in the redirection request received by the third acquiring unit, and the current network load status, whether the target eNodeB is currently in a network congestion state, and if so, the startup The third rejecting unit; otherwise, the third accepting unit is activated; the third rejecting unit is configured to reject the redirect request, and send a redirect request rejection message to the target MME; and a third accepting unit, configured to accept The redirect request continues the subsequent operations of the current handover.

In the above solution, the source MME is further configured to: receive a forward redirect request rejection message sent by the target MME; after that, reselect the target MME and send the selected target MME to the selected target MME. Sending a forward redirect request carrying the MTC information, or returning a handover failure message to the source eNodeB that initiates the current handover, notifying the source eNodeB that the current handover fails; the target MME further includes a receiving feedback unit, the receiving The feedback unit is configured to receive a redirect request rejection message returned by the target eNodeB, and send a forward redirect rejection message to the source MME.

The present invention proposes a congestion control scheme for a handover of an MTC terminal, and the target eNodeB or the target MME determines whether it is in a network congestion state according to the obtained MTC information of the MTC terminal; and rejects or allows the current handover according to the judgment result, in the MTC. When the terminal moves from the source network to the target network and performs handover, the congestion control of the target network for the MTC terminal is implemented, and the impact of the MTC handover on the live network is minimized, so that the normal service of the ordinary UE is not subject to a large number of MTC terminals. The effect of frequent switching when moving, thus effectively preventing network congestion, and maximizing the effective use of network resources through network optimization. DRAWINGS

1 is a schematic diagram of an architecture of an EPS network system in the prior art;

2 is a flowchart of performing X2 handover when a normal UE moves from a source eNodeB to a target eNodeB in the prior art;

FIG. 3 is a flowchart of performing S1 handover when a normal UE moves from a source eNodeB to a target eNodeB in the prior art;

4 is a flowchart of implementing a congestion control method in an MTC handover according to the present invention;

FIG. 5 is a schematic flowchart of an implementation process of performing congestion control in an X2 handover process when an MTC UE moves from a source eNodeB to a target eNodeB according to the present invention;

FIG. 6 is a schematic flowchart of an implementation process of performing congestion control in an S1 handover process when an MTC UE moves from a source eNodeB to a target eNodeB according to the present invention;

FIG. 7 is a schematic diagram of another implementation flow of congestion control in an X2 handover process when an MTC UE moves from a source eNodeB to a target eNodeB according to the present invention;

FIG. 8 is a flowchart of the present invention when an MTC UE moves from a source eNodeB to a target eNodeB, Another implementation flow diagram of congestion control during SI handover. detailed description

The basic idea of the present invention is: when the MTC terminal moves from the wireless area of the source eNodeB to the wireless area of the target eNodeB, during the handover process, the congestion control for the MTC terminal is performed, thereby preventing the handover caused by the movement of the MTC terminal from affecting the ordinary terminal. Normal business.

A congestion control method in MTC handover according to the present invention, as shown in FIG. 4, mainly includes the following steps:

Step 401: The target eNodeB or the target MME obtains the MTC information of the MTC terminal during the MTC handover.

Step 402: The target eNodeB or the target MME determines whether the network is in a network congestion state according to the obtained MTC information of the MTC terminal and the current network load status. If yes, the current handover is refused; otherwise, the current handover is continued.

Here, the MTC information may include any one or more of the following three types of information: an MTC indication (MTC Indication), a low priority indication (Low Priority), and an MTC allocation and retention priority (ARP).

The MTC Indication is used to indicate the MTC UE itself, and the Low Priority is used to indicate that the MTC UE is a low priority MTC terminal.

In the EPS system, the bearer-level QoS parameters include QCI, ARP, GBR guaranteed bit rate, MBR maximum bit rate, and AMBR aggregation maximum bit rate. ARP and QCI are used in GBR and Non-GBR bearers. The main purpose of ARP is In the case of resource restrictions, it is decided to accept or reject the establishment or modification request of the bearer. At the same time, ARP is used for special resource restrictions, such as switching, to decide which bearer to drop. Once the bearer is successfully established, ARP does not affect the transmission of the packet.

In the EPS bearer-level QoS parameters, ARP defines 1 to 15 levels for bearer allocation and handover control of common terminals. For the MTC ARP of the MTC terminal, it is used for the load distribution and handover control of the MTC terminal, which can be defined by the specific value of the MTC ARP to be compared with the common terminal. ARP is distinguished. For example, you can define 20 to 30 levels for MTC ARP. Each network element in the network can determine whether the current bearer is established, modified, or switched based on the ARP.

MTC Terminal Services.

In practical applications, there are generally two switching modes. One mode is that there is an X2 interface between the source eNodeB and the target eNodeB, and the source eNodeB directly initiates the handover to the target eNodeB through the X2 interface. The other way is between the source eNodeB and the target eNodeB. Without the X2 interface, the source eNodeB initiates a handover directly to the target eNodeB through the S1 interface.

For the handover using the X2 interface, the specific implementation process of the present invention is as follows: The source eNodeB in the current MTC handover acquires the MTC information of the MTC terminal from the MTC terminal or the source MME, and initiates carrying the MTC to the target eNodeB. Information switching request;

The target eNodeB receives the handover request initiated by the source eNodeB, and determines whether it is in a network congestion state according to the MTC information of the MTC terminal carried in the handover request and the current network load status; if yes, rejects the handover of the source eNodeB. Requesting, sending a handover failure message to the source eNodeB; otherwise, accepting the handover request, continuing the subsequent operation of the current handover.

The handover failure message includes a cause value and/or a waiting time, where the cause value is specifically an indication that the target eNodeB is currently in a network congestion state; the waiting time is used to indicate that the source eNodeB is from the current rejection to the current selection again. The time elapsed by the target eNodeB.

For the handover using the S1 interface, the specific implementation process of the present invention is as follows:

When the MTC terminal is attached to the network where the source MME is located, the MTC terminal carries its own MTC information to the source MME of the current handover by using an attach request; or, the MTC terminal is attached to the network where the source MME is located. The source MME obtains the MTC information of the MTC terminal from the quality of service (QoS) parameter of the MTC terminal. Sending, by the source MME, a forward redirect request carrying the acquired MTC information to the target MME;

The target MME of the current handover receives the forward redirection request sent by the source MME, and determines whether it is in a network congestion state according to the MTC information of the MTC terminal carried in the MTC terminal and the current network load status; if yes, rejecting the forward transfer weight Orienting the request, sending a forward redirect request rejection message to the source MME; otherwise, accepting the forward redirect request of the source MME, and sending a redirect request to the currently switched target eNodeB.

The redirection request sent by the target MME to the currently switched target eNodeB is specifically a redirection request that carries the MTC information of the MTC terminal.

The method may further include: the target eNodeB receiving the redirect request sent by the target MME, and determining whether the network is currently in the network according to the MTC information of the MTC terminal carried in the redirect request and the current network load status. The congestion state, if yes, rejecting the redirect request, sending a redirect request rejection message to the target MME; otherwise, continuing the subsequent operation of the current handover.

After the target eNodeB sends a redirect request rejection message to the target MME, the method further includes: after receiving the redirect request rejection message, the target MME returns a forward redirect request to the source MME that is currently handed over. Rejecting the message, rejecting the current forward redirect request of the source MME; then, the source MME reselects the target MME, and sends a forward redirect request carrying the MTC information to the selected target MME, or The source MME returns a handover failure message to the source eNodeB that is currently handed over, and notifies the source eNodeB that the current handover fails.

The handover failure message and the forward redirect request rejection message include a cause value and/or a waiting time, where the cause value is specifically an indication that the target MME is currently in a network congestion state; the waiting time is used to Indicates the time elapsed by the source MME from the current rejection to the selection of the target MME again. In order to implement the foregoing method, the present invention further provides a congestion control apparatus in an MTC handover, where the apparatus mainly includes: an obtaining unit, a determining unit, a rejecting unit, and an accepting unit, where the acquiring unit is configured to perform the MTC switching process. Obtaining MTC information to the MTC terminal; the determining unit, configured to determine, according to the MTC information of the MTC terminal acquired by the acquiring unit, and the current network load status, whether the target eNodeB or the target MME is in a network congestion state, and if yes, start Reject the unit, otherwise, start the accepting unit; reject the unit, to reject the current switch; accept the unit, to continue the current switch.

Here, the congestion control apparatus in the above MTC handover may be specifically provided on the target eNodeB or the target MME capable of MTC handover, or may be independently provided, but connected to the target eNodeB or the target MME.

In addition, the present invention also provides a congestion control system in two types of MTC handovers: a congestion control system in a first type of MTC handover, which is applicable to handover using an X2 interface, where the system includes: a source eNodeB and a target eNodeB, where ,

a source eNodeB, configured to acquire MTC information of the MTC terminal from an MTC terminal or a source MME, and initiate a handover request that carries the MTC information to the target eNodeB;

The target eNodeB includes: a first acquiring unit, a first determining unit, a first rejecting unit, and a first accepting unit, where the first acquiring unit is configured to receive MTC information of the MTC terminal carried in the handover request initiated by the source eNodeB a first determining unit, configured to determine, according to the MTC information of the MTC terminal carried in the handover request received by the first acquiring unit, and the current network load status, whether the target eNodeB itself is in a network congestion state, and if yes, start Determining, by the first rejecting unit, the first accepting unit, the first rejecting unit, configured to reject a handover request of the source eNodeB, and send a handover failure message to the source eNodeB; Accepting the handover request of the source eNodeB, continuing the subsequent operation of the current handover.

The congestion control system in the second MTC handover is applicable to the S1 interface. The system includes: a source MME and a target MME, where

The source MME is configured to obtain MTC information of the MTC terminal, and send a forward redirect request that carries the MTC information to the target MME.

The target MME includes: a second obtaining unit, a second determining unit, a second rejecting unit, and a second receiving unit, where the second acquiring unit is configured to receive, by the target MME, a redirection of the MTC information that carries the MTC terminal a first determining unit, configured to determine, according to the MTC information of the MTC terminal carried in the redirection request received by the second acquiring unit, and the current network load status, whether the target MME itself is in a network congestion state, and if yes, Then, the second rejecting unit is started, otherwise, the second accepting unit is started; the first rejecting unit is configured to reject the forward redirecting redirect request, and send a forward redirect request rejection message to the source MME; the first accepting unit, A forward redirect request for accepting the source MME, and sending a redirect request to the currently switched target eNodeB.

The second receiving unit of the target MME is specifically configured to send, to the currently switched target eNodeB, a redirection request that carries the MTC information.

The system further includes: the target eNodeB, the target eNodeB specifically includes: a third obtaining unit, a third determining unit, a third rejecting unit, and a third accepting unit, wherein the third obtaining unit is configured to receive the target And the third determining unit is configured to: according to the MTC information of the MTC terminal carried in the redirection request received by the third acquiring unit, and the current network load status, Determining whether the target eNodeB is currently in a network congestion state, if yes, starting the third reject unit; otherwise, starting the third accepting unit; and third rejecting unit, for rejecting the redirect request, to the target The MME sends a redirect request rejection message, and the third accepting unit is configured to accept the redirect request and continue the subsequent operation of the current handover.

Here, the source MME is further configured to: receive a forward redirect request rejection message sent by the target MME; after that, reselect the target MME, and send the carried to the selected target MME. Forwarding redirection request with the MTC information, or returning a handover failure message to the source eNodeB that initiates the current handover, notifying the source eNodeB that the current handover fails; the target MME further includes a receiving feedback unit, and the receiving feedback The unit is configured to receive a redirect request rejection message returned by the target eNodeB, and send a forward redirect rejection message to the source MME.

Embodiment 1

In this embodiment, a congestion control method is performed in the X2 switching process when the MTC UE moves from the source eNodeB to the target eNodeB. In this embodiment, the MTC UE accesses the EPS network and performs data communication with the MTC Server. The MTC UE moves from the source eNodeB radio area to the target eNodeB radio area, and the source eNodeB initiates a handover request to the target eNodeB, carries the MTC indication (MTC Indication) of the MTC UE, and/or a low priority indication (Low Priority), indicating the target eNodeB performs MTC switching. The target eNodeB performs MTC handover according to the handover request: determining whether it is in a network congestion state set in the MTC setting or other congestion control, and if yes, rejecting the handover request to avoid affecting the existing network; otherwise, Continue the subsequent switching operations.

As shown in FIG. 5, the specific process of this embodiment is as follows:

5501. The MTC UE is connected to the EPS network, and performs data exchange with the remote MTC Server (not shown in FIG. 5) through the established EPS bearer to perform data transmission.

When the MTC UE is connected to the EPS network, the source eNodeB acquires the MTC Indication of the MTC UE, and/or the MTC information such as the Low Priority from the MTC UE, and establishes a context in its own radio bearer after the RRC is successfully established. The MTC information is saved in (RRC Context).

S502: The source eNodeB initiates a measurement control command to the MTC UE, and configures location restriction information and measurement rules of the MTC UE.

S503, the MTC UE according to the measurement rule, including its own location information in the measurement report and sent to the source eNodeB; S504: The source eNodeB selects a target eNodeB for the MTC UE according to the location information provided in the measurement report sent by the MTC UE, and determines to initiate a handover (ie, HO initiation).

The source eNodeB sends an HO request to the target eNodeB, and carries an HO parameter such as an RRC context, a Target Cell ID, a Signalling context, and an E-RAB context to the target eNodeB. The RRC context includes the MTC Indication of the MTC UE, and/or Low

Priority

5506. The target eNodeB performs MTC congestion control, and detects that the current network load has reached a pre-configured network congestion threshold, and determines that the network is in a network congestion state.

Here, after receiving the handover request, the target eNodeB searches for the MTC information in the RRC Context included therein, and determines whether the network congestion state is based on the found MTC information and the pre-configured network congestion threshold, and according to the judgment result, Decide whether to switch.

Specifically, after receiving the handover request including the MTC Indication, and/or Low Priority of the MTC UE, the target eNodeB detects the current network load, for example, can detect the current CPU load average value, and considers the overload if it reaches the 80% level; Or, the statistics of the interface traffic are used for judging. For example, the target eNodeB can only process 100G traffic. If the traffic has reached 80M, the network is considered overloaded. After that, the target eNodeB determines according to the MTC Indication, and/or Low Priority of the MTC UE. Whether the current network load reaches the pre-configured network congestion threshold. If yes, it determines that it is in the network congestion state and decides to reject the handover request. Otherwise, it determines that it is in the normal network state and allows MTC handover.

Here, before the MTC congestion control is performed, the network congestion threshold for the MTC handover needs to be configured in advance on the target eNodeB according to the operator policy.

For example, the network congestion threshold for MTC handover can be configured as follows:

Manner 1: When the handover request includes MTC Indication and Low Priority, or only includes Low Priority, the network load reaches 40% for congestion control, that is, setting corresponding The first network congestion threshold is 40%; when the handover request includes only the MTC Indication, the network load reaches 50% for congestion control, that is, the corresponding second network congestion threshold is set to 50%;

Manner 2: When the handover request includes the MTC Indication and the Low Priority, or only the Low Priority, the network load reaches 40% to perform congestion control, that is, the corresponding first network congestion threshold is set to 40%; When the request includes only the MTC Indication, the corresponding second network congestion threshold is set, which is consistent with the normal UE.

5507. The target eNodeB sends a handover failure message (HO failure) to the source eNodeB, and rejects the handover request of the source eNodeB.

Here, the target eNodeB may carry a cause value (cause) and/or a first waiting time in the handover failure message, and notify the source eNodeB that the current network is congested.

The cause is the indication that the target eNodeB is currently in the network congestion state, and is used to notify the source eNodeB that the current handover request fails because the target eNodeB is currently in a network congestion state.

The first waiting time is used to indicate the time elapsed by the source eNodeB from the current rejection to the current target eNodeB, that is, the source eNodeB does not select the target eNodeB to attempt to switch before the waiting time overflows. Here, the first waiting time may be pre-configured in the target eNodeB, and is generally determined according to the statistical result of the network state of the target eNodeB, which is an empirical value. During the busy period of the target eNodeB, a longer first waiting time can be configured, and during the idle period of the target eNodeB, a shorter first waiting time can be configured.

After receiving the handover failure message, the source eNodeB selects another available target eNodeB for the MTC UE according to the location information of the MTC UE provided in the measurement report, and attempts to initiate a handover request; or before the first waiting time overflows, The source eNodeB then attempts to initiate a handover request to the current target eNodeB.

5509, after performing the above congestion control, as long as the target eNodeB accepts the source The handover request of the eNodeB, the source eNodeB sends an RRC reconfiguration message to the MTC UE, and switches the wireless connection of the MTC UE to the target eNodeB that accepts the handover request.

Here, whether the other available target eNodeB accepts the handover request of the source eNodeB, or the current target eNodeB accepts the handover request of the source eNodeB after the first waiting time elapses, the source eNodeB sends an RRC reconfiguration message to the MTC UE, and the MTC UE The wireless connection is switched to the target eNodeB that accepts the handover request, and the handover of the MTC UE from the source eNodeB to the target eNodeB is completed.

Embodiment 2

The present embodiment is a congestion control method in the process of performing an S1 handover when the MTC UE moves from the source eNodeB to the target eNodeB. In this embodiment, the MTC terminal (MTC UE) accesses the EPS network and performs data communication with the MTC server. . The MTC UE moves from the source eNodeB radio area to the target eNodeB radio area, and the source eNodeB initiates a handover request to the source MME through the S1 interface, and the source MME initiates a forward redirection request to the target MME, and carries the MTC Indication, and/or Low of the MTC UE. Priority, indicating that the target MME performs MTC handover; after receiving the forward redirect request, the target MME performs MTC handover: determining whether it is in a network congestion state set by the MTC, and if yes, rejecting the forward redirect request No, it performs a subsequent handover operation, the target MME initiates a redirection request to the target eNodeB, carries the MTC Indication of the MTC UE, and/or Low Priority, and then the target eNodeB performs an MTC handover operation according to the redirection request. That is, it is judged whether it is in the network congestion state set by the MTC, and if so, the redirection request is rejected to avoid affecting the existing network; otherwise, the subsequent switching operation is performed.

As shown in FIG. 6, the specific process of this embodiment is as follows:

S601: The MTC UE has accessed the EPS network, and performs data exchange with the remote MTC Server (not shown in FIG. 6) through the established EPS bearer to perform data transmission;

When the MTC UE attaches to the EPS network, it carries its own MTC in the attach request. After the attachment is successful, the source MME stores the identifier information of the MTC UE and the MTC information such as the MTC Indication and/or the Low Priority in the currently carried MM context.

5602. The source eNodeB determines to initiate a handover to the target eNode through the S1 interface (HO is initiated);

S603, the source eNodeB initiates a handover request (HO request;) to the source MME, and carries the HO parameters such as the transparent data of the source eNodeB to the target eNodeB, the Targer TAI, the ID of the target eNodeB, and the identifier information of the MTC UE, such as the IMSI of the MTC UE. .

S604: The source MME selects a target MME according to the Target TAI in the handover request, and sends a forward redirect request to the target MME, and carries the forwarding MME in the forward redirect request.

MME UE context, Target TAI, transparent data from the source eNodeB to the target eNodeB, and the ID of the target eNodeB.

The MME UE context includes the IMSI, the terminal capability, the S-GW address, the P-GW address, the access point name (APN, Access Point Name), and the currently hosted MM context of the MTC UE. Here, the MM context includes MTC information such as MTC Indication and/or Low Priority of the MTC UE.

5605. The target MME performs MTC congestion control, and detects that the current network load has reached a pre-configured network congestion threshold, and determines that the network is in a network congestion state.

Here, after receiving the forward redirect request, the target MME searches for the MTC information in the MME UE context of the forward redirect request, and determines whether the network is in the network according to the found MTC information and the pre-configured network congestion threshold. Congestion status, and based on the judgment result, decide whether to switch.

Specifically, after receiving the forward redirection request including the MTC Indication, and/or the Low Priority, the target MME detects the current network load, and the detection method of the specific detection target eNodeB is similar, and is not described in detail; Whether the network load reaches the pre-configured The network congestion threshold, if yes, determines that it is in a network congestion state, and decides to reject the forward redirect request; otherwise, it determines that it is in a normal network state, and allows subsequent MTC handover operations.

Here, before the MTC congestion control is performed, the network congestion threshold for the MTC handover needs to be configured in advance in the target MME according to the operator policy. For example, the configuration may be performed in the first mode or the second mode in the step S506. The specific value of the configured network congestion threshold may be different from that in the step S506, and determined according to the network operation status of the target MME.

S606, the target MME sends a forward redirect redirection message to the source MME, and rejects the forward redirect request of the source MME.

Here, the forward redirect redirection message may carry the cause and the second waiting time, notify the source MME that the network is congested, and the source MME does not select the target MME to attempt to perform handover before the waiting time overflows.

The cause is specifically an indication that the target MME is currently in a network congestion state, and the reason for the failure of the source MME to notify the current handover request is that the target MME is currently in a network congestion state.

The second waiting time is used to indicate the time that the source MME has to go from being currently rejected to selecting the current target MME again. Here, the second waiting time may be pre-configured in the target MME, and is generally determined according to the statistical result of the target MME network status, which is an empirical value. During the busy period of the target MME, a longer second waiting time can be configured, and during the idle period of the target MME, a shorter second waiting time can be configured.

After receiving the forward redirect redirection message, the source MME selects another available target MME and attempts to initiate a forward redirect request, or after the second waiting time overflows, the source MME selects the current target MME to try again. Forward the redirect request.

5608, when all MMEs reject the current forward redirect request of the source MME, the source MME returns a handover failure message (HO failure) to the source eNodeB, and notifies the source eNodeB that the handover fails. Here, the handover failure message may also include a cause, and the cause may be an indication that all available target MMEs are currently in a network congestion state, and the reason for notifying the source eNodeB that the current handover request fails is that all available target MMEs are currently in the Network congestion status.

5609. If the target MME can accept the current forwarding request of the source MME, the target MME that accepts the current forwarding request of the source MME sends a redirect request message to the target eNodeB, and carries the S-GW entry address and the EPS Bear. – requesting to perform handover by using QoS parameters, source eNodeB to target eNodeB transparent data, and MTC Indication and/or Low Priority information of the MTC UE;

5610, which is basically the same as step 506, except that the target eNodeB finds the MTC Indication and/or Low of the MTC UE from the redirect request message sent by the target MME.

Priority MTC information, and when it is judged that the network is in a network congestion state, it decides to reject the redirect request, and determines that it is in the normal state of the network, and allows subsequent MTC handover.

In the actual application, after the target eNodeB receives the redirect request message, if the target eNodeB is in the normal state of the network, the handover is allowed, the EPS Bear-QoS is implicitly transmitted to the E-RAB QoS, and the radio resource is allocated to the MTC UE according to the QoS parameter; If the target eNodeB is in a network congestion state, it decides to reject the redirect request initiated by the target MME, and then sends a redirect reject message to the target MME.

5611. The target eNodeB sends a redirect reject message to the target MME, rejects the redirect request message of the target MME, and the target MME releases the network resource reserved for the MTC UE.

Here, the redirection reject message may further carry a cause, and the cause is specifically an indication that the target eNodeB is currently in a network congestion state, and is used to notify the target MME that the current redirection request is rejected because the target eNodeB is currently in a network congestion state.

The target MME sends a forward redirect redirection message to the source MME, and rejects the current forward redirection request of the source MME.

Here, the forward redirect redirection message may also carry a cause, the cause and the step The reason in S61 1 is that the source eMME is notified that the current forwarding redirection request is rejected because the target eNodeB is currently in a network congestion state.

S613. After receiving the forwarding redirection rejection message, the source MME returns a handover failure message to the source eNodeB, and notifies the source eNodeB that the current handover fails.

Here, the handover failure message may also carry a cause, which is the same as that in step S611, and is used to notify the source eNodeB that the current handover request is rejected because the target eNodeB is currently in a network congestion state.

Embodiment 3

This embodiment is another congestion control method in the process of performing the X2 handover when the MTC UE moves from the source eNodeB to the target eNodeB. In this embodiment, the MTC terminal (MTC UE) accesses the EPS network and performs data with the MTC server. Communication. The MTC UE moves from the source eNodeB radio area to the target eNodeB radio area, and the source eNodeB initiates a handover to the target eNodeB, carrying the MTC ARP of the MTC UE, instructing the target eNodeB to perform MTC handover; and after receiving the handover request, the target eNodeB performs MTC handover: Determine whether it is in the network congestion state set by the MTC. If yes, reject the handover request to avoid affecting the existing network; if not, continue to perform subsequent handover operations.

As shown in Figure 7, the specific process of this embodiment is as follows:

5701. The MTC UE allocates an MTC ARP to the bearer during the establishment of the bearer. When attaching to the EPS network, the MTC UE first establishes an RRC connection and initiates an attach request to the source MME. The source MME establishes an EPS bearer for the MTC UE, and returns an EPS Bearer context to the source eNodeB, carrying the QoS parameter, where the QoS parameter includes the MTC ARP of the MTC UE. The source eNodeB maps the QoS parameters to E-RAB QoS parameters, and establishes a radio EPS bearer, and saves the E-RAB QoS parameters of the MTC ARP including the MTC UE in the E-RAB Context.

5702, the MTC UE has access to the EPS network, and the established EPS bearer and remote end MTC Server (not shown in Figure 7) performs data interaction;

S703-S705, which is completely the same as steps S502~S504;

5706, which is basically the same as step S505. The difference is that the MTC Indication of the MTC UE is not included in the RRC context, and/or the Low Priority, but the MTC ARP of the MTC UE is included in the E-RAB context to indicate The destination eNodeB performs MTC handover;

5707, substantially the same as step S506, the difference is: the target eNodeB does not determine whether the current network load reaches the pre-configured network congestion threshold according to the MTC Indication, and/or the Low Priority, but detects the current network according to the MTC ARP of the MTC UE. Whether the load reaches the preset network congestion threshold and determines whether it is in a network congestion state.

Correspondingly, the network congestion threshold for configuring MTC handover in the target eNodeB is different in implementation. For example, the corresponding congestion control threshold may be preset in the target eNodeB according to the network running status of the target eNodeB for different levels of the MTC ARP.

Specifically, after receiving the handover request carrying the MTC ARP, the target eNodeB verifies whether the current network load reaches its corresponding network congestion threshold according to the level of the MTC ARP, and if yes, determines that the network is in a network congestion state, and determines The handover request is rejected; otherwise, it is determined that it is in the normal state of the network, and subsequent MTC handover is allowed.

S708-S710, which is exactly the same as step S507-509.

Embodiment 4

This embodiment is another congestion control method in the process of performing the S1 handover when the MTC UE moves from the source eNodeB to the target eNodeB. In this embodiment, the MTC terminal accesses the EPS network and performs data communication with the MTC Server. The MTC UE moves from the source eNodeB radio area to the target eNodeB radio area, and the source eNodeB initiates a handover request to the source MME through the S1 interface, and the source MME initiates a forward redirection request to the target MME, and carries the MTC ARP. The target MME identifies that it is an MTC handover, determines whether it is in a network congestion state set by the MTC, and if so, rejects the forward redirect request; otherwise, performs a subsequent handover operation, and the target MME continues. Initiating a redirection request to the target eNodeB, the target eNodeB identifies the MTC handover, and determines whether it is in the network congestion state set by the MTC. If yes, the redirection request is rejected to avoid affecting the existing network. Otherwise, the subsequent execution is performed. Switch operations. As shown in FIG. 8, the specific process of this embodiment is as follows:

5801. During the establishment of the bearer process, the MTC UE allocates MTC ARP to the bearer.

When the MTC UE attaches and establishes the EPS bearer, the network signs the HSS or SPR.

The MTC ARP of the MTC UE, and the MTC ARP is included in the QoS parameters allocated for the EPS bearer, and is stored in the EPS Bearer Context currently carried in the source MME.

5802, which is identical to step S702;

S803~S804, which are completely the same as steps S602~603;

5805, which is basically the same as the S604. The difference is that the MME UE context carried by the forward redirect request includes: an IMSI of the MTC UE, a terminal capability, an S-GW address, a P-GW address, an APN, and the EPS. Information such as QoS parameters in the Bearer Context. The QoS parameter includes the MTC ARP of the MTC UE.

5806, which is basically the same as step S605. The difference is that when the target MME receives the forward redirect request, it searches for the MTC ARP in the MME UE Context, and determines whether it is in accordance with the MTC ARP and the pre-configured network congestion threshold. Network congestion status.

Here, the process of configuring the network congestion threshold of the MTC handover in the target MME is the same as that in step S707. The difference is that the specific value of the congestion control threshold can be set according to the network operating status of the target MME.

Specifically, after receiving the forward redirection request carrying the MTC ARP, the target MME verifies whether the current network load reaches its corresponding network congestion threshold according to the level of the MTC ARP, and if yes, determines that it is in network congestion. The state determines to reject the forward redirect request; otherwise, it determines that it is in the normal state of the network, allowing subsequent MTC handover.

S807-S809, which are completely the same as steps S606~S608; S810, which is substantially the same as step S609, except that the redirect request message sent by the target MME to the target eNodeB carries information such as an ingress address of the S-GW, an EPS Bear QoS parameter, and a transparent data of the source eNodeB to the target eNodeB, and the request is performed. Switch. The MTC ARP of the MTC UE is included in the EPS Bearer QoS parameter.

S811, which is substantially the same as step S610. The difference is that the target eNodeB finds the MTC ARP of the MTC UE from the redirect request message sent by the target MME, and determines whether the network is in the network according to the MTC ARP of the found MTC UE. The congestion state, the specific process of judgment, and the process of setting the network congestion threshold in advance are the same as step S707. According to the judgment result, the subsequent operation is different from step S707.

Specifically, the target eNodeB receives the redirect request and will redirect the requested EPS.

Bear—Locates MTC ARP in QoS, based on the MTC ARP found. When it is determined that the network is in the normal state of the network, the target eNodeB allows the handover, implicitly transmits the EPS Bear QoS to the E-RAB QoS, and allocates the radio resource according to the QoS parameter, and decides to reject the redirection request when determining that it is in the network congestion state. .

S812-S814 is completely the same as steps S611 to S613.

The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included. Within the scope of protection of the present invention.

Claims

Claim

A congestion control method in an MTC handover, the method includes: in a process of performing an MTC handover, a target eNodeB or a target MME according to the acquired

The MTC information of the MTC terminal and the current network load status determine whether the network is in a network congestion state. If yes, the current handover is refused; otherwise, the current handover is continued.

The congestion control method in the MTC handover according to claim 1, wherein the target eNodeB determines whether the network is in a network congestion state according to the acquired MTC information of the MTC terminal and the current network load status. For:

The target eNodeB determines whether it is in a network congestion state according to the received MTC information of the MTC terminal carried in the handover request initiated by the source eNodeB, and the current network load status; if yes, rejects the handover request of the source eNodeB, The source eNodeB sends a handover failure message; otherwise, accepts the handover request and continues the subsequent operation of the current handover.

The congestion control method in the MTC handover according to claim 2, wherein before the target eNodeB receives the handover request initiated by the source eNodeB, the method further includes: the source eNodeB from the MTC The terminal or the source MME acquires the MTC information of the MTC terminal, and initiates a handover request carrying the MTC information to the target eNodeB.

The congestion control method in the MTC handover according to claim 1, wherein the target MME determines whether the network is in a network congestion state according to the acquired MTC information of the MTC terminal and the current network load status. The target MME determines whether it is in a network congestion state according to the MTC information of the MTC terminal carried in the forward redirection request sent by the source MME, and the current network load status; if yes, rejects the forward redirection And sending a forward redirect request rejection message to the source MME; otherwise, accepting the forward redirect request of the source MME, and sending a redirect request to the currently switched target eNodeB.

The congestion control method in the MTC handover according to claim 4, wherein before the target MME receives the forward redirect request carrying the MTC information, the The method further includes: the source MME acquiring the MTC information of the MTC terminal, and sending a forward redirect request carrying the MTC information to the target MME.

The congestion control method in the MTC handover process according to claim 5, wherein the source MME acquires the MTC information as:

When the MTC terminal is attached to the network where the source MME is located, the MTC terminal carries its own MTC information to the source MME by using an attach request;

Or, when the MTC terminal is attached to the network where the source MME is located, the source MME obtains the MTC information of the MTC terminal from the quality of service (QoS) parameter of the MTC terminal. .

The congestion control method in the MTC handover according to claim 4, wherein the target MME sends a redirection request to the currently switched target eNodeB, where: the target MME sends the bearer to the currently switched target eNodeB. a redirection request for MTC information of the MTC terminal;

After the method, the method further includes: the target eNodeB receiving the redirection request, and determining, according to the MTC information of the MTC terminal carried in the redirection request, and the current network load status, whether the network is currently in a network congestion state, if Yes, rejecting the redirect request, sending a redirect request rejection message to the target MME; otherwise, continuing the subsequent operation of the current handover.

The congestion control method in the MTC handover according to claim 7, wherein after the target eNodeB sends a redirect request rejection message to the target MME, the method further includes:

After receiving the redirect request rejection message, the target MME returns a forward redirect request rejection message to the source MME of the current handover, and rejects the current forward redirect request of the source MME;

Then, the source MME reselects the target MME, and sends a forward redirect request carrying the MTC information to the selected target MME; or, the source MME cuts the current MME The changed source eNodeB returns a handover failure message, notifying the source eNodeB that the current handover fails.

The congestion control method in MTC handover according to any one of claims 2 to 8, wherein the handover failure message and the forward redirect request rejection message contain a cause value and/or a waiting time. The cause value is an indication that the target eNodeB or the target MME is currently in a network congestion state; the waiting time is used to indicate a time that the source eNodeB or the source MME has to go from being currently rejected to selecting the target eNodeB or the target MME again. .

The congestion control method in the MTC handover according to any one of claims 1 to 8, wherein the MTC information includes any one or more of the following three types of information: MTC indication (MTC Indication), 氐 priority Level Priority (Low Priority), MTC ARP.

A congestion control device in an MTC switch, the device includes: an obtaining unit, a determining unit, a rejecting unit, and an accepting unit, where

An obtaining unit, configured to obtain MTC information of the MTC terminal during the MTC handover;

a determining unit, configured to determine, according to the MTC information of the MTC terminal acquired by the acquiring unit, and the current network load status, whether the target eNodeB or the target MME is in a network congestion state, and if yes, starting the rejecting unit, otherwise, starting the accepting unit ;

a reject unit for rejecting the current switch;

Accept unit to continue the current switch.

12. A congestion control system in an MTC handover, where the system includes: a source eNodeB and a target eNodeB, where

The target eNodeB includes: a first obtaining unit, a first determining unit, a first rejecting unit, and a first accepting unit, where

a first acquiring unit, configured to receive an MTC carried in a handover request initiated by the source eNodeB MTC information of the terminal;

a first determining unit, configured to determine, according to the MTC information of the MTC terminal that is carried in the handover request that is received by the first acquiring unit, and the current network load status, whether the target eNodeB is in a network congestion state, and if yes, start the location Determining the first reject unit, otherwise, starting the first accepting unit;

a first rejecting unit, configured to reject a handover request of the source eNodeB, and send a handover failure message to the source eNodeB;

The first accepting unit is configured to accept the handover request of the source eNodeB, and continue the subsequent operation of the current handover.

A congestion control system in an MTC handover, where the system includes: a source MME and a target MME, where

The source MME is configured to obtain MTC information of the MTC terminal, and send a forward redirect request carrying the MTC information to the target MME.

The target MME includes: a second obtaining unit, a second determining unit, a second rejecting unit, and a second accepting unit, where

a second acquiring unit, configured to receive a redirection request that is sent by the target MME and carries the MTC information of the MTC terminal;

a first determining unit, configured to determine, according to the MTC information of the MTC terminal that is carried in the redirection request received by the second obtaining unit, and the current network load status, whether the target MME is in a network congestion state, and if yes, start a second reject unit, otherwise, a second accepting unit is activated;

a first rejecting unit, configured to reject the forward redirect request, and send a forward redirect request rejection message to the source MME;

The first accepting unit is configured to accept a forward redirect request of the source MME, and send a redirect request to the currently switched target eNodeB.

The congestion control system in the MTC handover according to claim 13, wherein the second accepting unit of the target MME is configured to send, to the currently switched target eNodeB, a redirect request carrying the MTC information. ;

The system further includes: the target eNodeB, where the target eNodeB includes: a third obtaining unit, a third determining unit, a third rejecting unit, and a third receiving unit, where the third obtaining unit is configured to receive the target MME The second receiving unit sends the redirection request; the third determining unit is configured to determine, according to the MTC information of the MTC terminal carried in the redirection request received by the third obtaining unit, and the current network load status, Whether the target eNodeB is currently in a network congestion state, if yes, starting the third reject unit; otherwise, starting the third accepting unit; and third rejecting unit, for rejecting the redirect request, to the target MME Sending a redirect request rejection message; the third accepting unit is configured to accept the redirect request and continue the subsequent operation of the current handover.

The congestion control system in the MTC handover according to claim 14, wherein the source MME is further configured to: receive a forward redirect request rejection message sent by the target MME; and then reselect the target MME. And sending a forward redirection request carrying the MTC information to the selected target MME, or returning a handover failure message to the source eNodeB that initiates the current handover, to notify the source eNodeB that the current handover fails;

The target MME further includes a receiving feedback unit, configured to receive a redirect request reject message returned by the target eNodeB, and send a forward redirect redirection reject message to the source MME.