WO2016062005A1 - 机器类通信请求重发的处理方法及装置 - Google Patents

机器类通信请求重发的处理方法及装置 Download PDF

Info

Publication number
WO2016062005A1
WO2016062005A1 PCT/CN2015/075155 CN2015075155W WO2016062005A1 WO 2016062005 A1 WO2016062005 A1 WO 2016062005A1 CN 2015075155 W CN2015075155 W CN 2015075155W WO 2016062005 A1 WO2016062005 A1 WO 2016062005A1
Authority
WO
WIPO (PCT)
Prior art keywords
mtc
request
factor
message
retransmission
Prior art date
Application number
PCT/CN2015/075155
Other languages
English (en)
French (fr)
Inventor
史莉荣
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2016062005A1 publication Critical patent/WO2016062005A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery

Definitions

  • the present invention relates to the field of communications, and in particular to a method and apparatus for processing a device type communication request retransmission.
  • M2M Machine to Machine
  • MTC Machine-Type Communications
  • M2M enables machines, devices, and application processes to share information with back-end information systems and share information with operators. It provides a means for transmitting data in real time by establishing a wireless connection between systems, between remote devices, or between individuals.
  • M2M technology integrates data acquisition, Global Positioning System (GPS), remote monitoring, telecommunications, and information technology. It is an ecosystem of computers, networks, devices, sensors, humans, etc., which can automate business processes and integrate companies. Real-time status of IT systems and non-IT devices and creating value-added services. This platform can be operated and provides a wide range of applications and solutions in environments such as safety monitoring, automatic meter reading, mechanical service and repair services, vending machines, public transportation systems, fleet management, industrial process automation, electromechanical, and urban information. Program.
  • the M2M system is mainly composed of the following three parts:
  • Wireless terminal In addition to commonly used mobile phones and notebook computers, it also includes various types of industrial application terminals;
  • Transmission channel a data transmission channel from a wireless terminal to an industrial application center
  • M2M technology is of great significance. It has a broad market and application, and promotes a new round of social production and lifestyle changes.
  • 3GPP 3rd Generation Partnership Project
  • M2M communication interface and standardized transmission content 3rd Generation Partnership Project
  • the processing of signaling congestion in the related art rejecting the MTC service and ensuring access to Human to Human (H2H) communication. Because the current number of MTC services is not large, and the H2H service that a cell can support is also very limited, the related technology can ensure the access of the H2H service, and the MTC service delays the access by resending the request.
  • H2H Human to Human
  • the embodiment of the invention provides a processing method and a device for requesting retransmission of a machine type communication, so as to solve the problem that signaling congestion occurs when a large number of MTC devices re-initiate an MTC service request in the related art.
  • a method for processing a final machine type communication request retransmission including: the network side sends a message to a machine type communication MTC device, where the message carries an MTC request retransmission factor,
  • the MTC request retransmission factor is a basis for the MTC device to determine to initiate an MTC service request again.
  • the method before the network side sends the message to the MTC device, the method further includes: determining, by the network side, the MTC request retransmission factor according to a load.
  • the load includes at least one of the following: the network side device processing load, and the wireless transmission load.
  • the method further includes: the network side updating the MTC request retransmission factor according to the change of the load; the network The side sends the updated MTC request retransmission factor to the MTC device.
  • the method before the network side sends the message to the MTC device, the method further includes: the network side sending the indication information to the MTC device, where the indication information is used to indicate the network Whether the side supports the MTC service.
  • the message includes at least one of the following: a system message, a connection reject message.
  • the MTC requests a retransmission factor to be a number.
  • a method for processing retransmission of a machine type communication request including: a machine type communication MTC device receives a message sent by a network side, where the message carries an MTC request retransmission a factor; the MTC device determines, according to the MTC request retransmission factor, whether to initiate the MTC service request again after the MTC service request is rejected.
  • the MTC requests a retransmission factor to be a number.
  • the MTC device determines, according to the MTC request retransmission factor, whether to initiate the MTC service request after the MTC service request is rejected, the MTC device generates a random number, and according to the random number The relationship with the MTC request retransmission factor determines whether to initiate the MTC service request again.
  • determining, according to the relationship between the random number and the MTC request retransmission factor, whether to initiate the MTC service request includes at least one of: the random number is greater than the MTC request retransmission factor Initiating the MTC service request again; and initiating the MTC service request again if the random number is greater than or equal to the MTC request retransmission factor; and the random number is equal to the MTC request retransmission factor In the case of the MTC service request being initiated again; the MTC service request is re-initiated if the random number is less than or equal to the MTC request retransmission factor; and the random number is smaller than the MTC request retransmission factor In the case, the MTC service request is initiated again.
  • the method further includes: when the MTC device initiates the MTC service request for more than a predetermined number of times, the MTC device identifies the target cell of the MTC service request, and performs cell weight Alternatively, if the reselected cell includes the target cell, the target cell is culled.
  • the message includes at least one of the following: a system message, a connection reject message.
  • a processing device for requesting retransmission of a machine type communication comprising: a sending module, configured to send a message to a machine type communication MTC device, wherein the message carries an MTC request A retransmission factor, where the MTC request retransmission factor is a basis for the MTC device to determine to initiate an MTC service request again.
  • the apparatus before transmitting the message to the MTC device, the apparatus further includes: a determining module, configured to determine the MTC request retransmission factor according to the load.
  • the load includes at least one of the following: the network side device processing load, and the wireless transmission load.
  • the determining module is further configured to update the MTC request retransmission factor according to the change of the load; the sending module is further configured to The updated MTC request retransmission factor is sent to the MTC device.
  • the sending module before the sending the message to the MTC device, the sending module is further configured to send the indication information to the MTC device, where the indication information is used to indicate whether the network side supports the MTC service.
  • the message includes at least one of the following: a system message, a connection reject message.
  • the MTC requests a retransmission factor to be a number.
  • a processing device for requesting retransmission of a machine type communication comprising: a receiving module, configured to receive a message sent by a network side, wherein the message carries an MTC request for retransmission a factor; a retransmission module, configured to determine whether to initiate the MTC service request again after the MTC service request is rejected according to the MTC request retransmission factor.
  • the MTC requests a retransmission factor to be a number.
  • the retransmission module includes: a determining module, configured to generate a random number, and determine, according to the relationship between the random number and the MTC request retransmission factor, whether to initiate the MTC service request again.
  • the determining module includes at least one of the following: a first determining unit, configured to re-initiate the MTC service request if the random number is greater than the MTC request retransmission factor; a unit, configured to initiate the MTC service request again if the random number is greater than or equal to the MTC request retransmission factor; and the third determining unit is configured to: when the random number is equal to the MTC request retransmission factor The MTC service request is initiated again; the fourth determining unit is configured to initiate the MTC service request again if the random number is less than or equal to the MTC request retransmission factor; the fifth determining unit, setting The MTC service request is initiated again if the random number is less than the MTC request retransmission factor.
  • the apparatus further includes: a reselection module, configured to: when the MTC device initiates the MTC service request for more than a predetermined number of times, identify the target cell of the MTC service request, and perform Cell reselection, if the reselected cell includes the target cell, the target cell is rejected.
  • a reselection module configured to: when the MTC device initiates the MTC service request for more than a predetermined number of times, identify the target cell of the MTC service request, and perform Cell reselection, if the reselected cell includes the target cell, the target cell is rejected.
  • the message includes at least one of the following: a system message, a connection reject message.
  • the network side device type communication MTC device is used to send a message, where the message carries the MTC request retransmission factor, and the MTC request retransmission factor is that the MTC device determines to initiate the MTC again.
  • the method of the service request is to solve the problem that the MTC device re-initiates the MTC service request in the related art, causing the signaling congestion, smoothing the time for the MTC device to resend the MTC service request, and effectively alleviating the signaling congestion.
  • FIG. 1 is a flowchart of a processing method of machine type communication request retransmission according to an embodiment of the present invention
  • FIG. 2 is a block diagram showing the structure of a processing device for requesting retransmission of a machine type communication according to an embodiment of the present invention
  • FIG. 3 is a flow chart 1 of a processing method for machine type communication request retransmission according to an alternative embodiment of the present invention
  • FIG. 4 is a structural block diagram 1 of a processing apparatus for requesting retransmission of a machine type communication request according to an alternative embodiment of the present invention
  • FIG. 5 is a second flowchart of a processing method for machine type communication request retransmission according to an alternative embodiment of the present invention.
  • FIG. 6 is a third flowchart of a processing method for machine type communication request retransmission according to an alternative embodiment of the present invention.
  • FIG. 7 is a flowchart 4 of a processing method of machine type communication request retransmission according to an alternative embodiment of the present invention.
  • FIG. 9 is a structural block diagram 2 of a processing apparatus for machine type communication request retransmission according to an alternative embodiment of the present invention.
  • FIG. 10 is a block diagram 3 of a processing apparatus for a machine type communication request retransmission according to an alternative embodiment of the present invention.
  • FIG. 1 is a flowchart of a processing method for retransmission of a machine type communication request according to an embodiment of the present invention. As shown in FIG. 1, the flow includes the following steps. :
  • Step S102 The network side sends a message to the machine type communication MTC device, where the message carries the MTC request retransmission factor, and the MTC request retransmission factor is the basis for the MTC device to determine to initiate the MTC service request again.
  • the network side device type communication MTC device is used to send a message, where the message carries the MTC request retransmission factor, and the MTC request retransmission factor is a method for the MTC device to determine the basis for reinitiating the MTC service request.
  • the network side can determine to some extent, the MTC device can resend the MTC service request, which can solve the problem that a large number of MTC devices in the related art re-initiate the MTC service request, causing signaling congestion, and smoothing The time when the MTC device resends the MTC service request effectively mitigates signaling congestion.
  • the MTC requests the retransmission factor as a basis for the MTC device to determine to initiate the MTC service request again.
  • the MTC request retransmission factor may have multiple determination manners.
  • the network side may determine the MTC request retransmission factor according to the load.
  • the network side determines different MTC request retransmission factors according to different loads, and sends a different MTC request retransmission factor to the MTC device.
  • the MTC device initiates the MTC request service again after a long delay.
  • the MTC device immediately initiates the MTC request service again.
  • the load may include many aspects.
  • the load may include at least one of the following: a network-side device processing load, and a wireless transmission load.
  • the load of the wireless transmission may include at least one of the following: downlink transmit power, uplink interference
  • the device processing load on the network side may include at least one of the following: a board CPU consumption, a message buffer.
  • the downlink transmit power according to the downlink transmit power, The uplink interference, the CPU consumption of the board, and one or more of the message buffers determine the MTC request retransmission factor, so that the MTC request retransmission factor corresponding to the current load status can be obtained, which reduces the system load and reduces the system overhead. .
  • the load is not static, and the load is changed according to the request quantity, the response amount, and the like of various services.
  • the process further includes: the network side updates the MTC request retransmission factor according to the change of the load; and the network side sends the updated MTC request retransmission factor to the MTC device.
  • the MTC request retransmission factor is dynamically adjusted according to the change of the load, so that the MTC device is re-established.
  • the timing of initiating the MTC service request is also dynamically adjusted to optimize the allocation and utilization of resources on the network side.
  • the MTC device Before the network side sends a message to the MTC device, the MTC device may not know whether the network side supports the MTC service. If the network side does not support the MTC service, it will waste system resources and increase the load. In an optional implementation manner of this embodiment, before the network side sends the message to the MTC device, the network side sends the indication information to the MTC device, where the indication information is used to indicate whether the network side supports the MTC service.
  • the MTC retransmission request factor is carried in the message and sent by the network side to the MTC device.
  • the message may include at least one of the following: a system message, a connection reject message, or other messages.
  • the MTC request retransmission factor may be in various forms.
  • the MTC request retransmission factor may be a time value indicating the interval of the MTC service request retransmitted by the MTC device.
  • the MTC request retransmission factor is a number, and the number may be provided to the MTC device, so that the MTC performs retransmission according to the number, for example, the MTC device may generate a number and is heavy with the MTC request.
  • the factors are compared and the results are compared to determine whether to resend. This will be described below by way of an alternative embodiment.
  • the module or unit in the device may be code stored in a memory and operable by the processor, and the memory and the processor may be located in the terminal, but the device is not limited thereto, and the device may be implemented in other manners. Let's take another example.
  • the present invention further provides a processing device for requesting retransmission of a machine type communication
  • FIG. 2 is a structural block diagram of a processing device for requesting retransmission of a machine type communication according to an embodiment of the present invention.
  • the apparatus includes a transmitting module 22 configured to send a message to a machine type communication MTC device, wherein the message is The MTC request retransmission factor is carried, and the MTC request retransmission factor is the basis for the MTC device to determine to initiate the MTC service request again.
  • the sending module 22 sends a message to the machine type communication MTC device, where the message carries the MTC request retransmission factor, and the MTC request retransmission factor is a method for the MTC device to determine the basis for reinitiating the MTC service request.
  • the network side can determine the retransmission of the MTC service request by the MTC device to a certain extent, so that the problem that the MTC device re-initiates the MTC service request in the related art and causes the signaling congestion is solved, and the problem is smoothed.
  • the time when the MTC device resends the MTC service request effectively mitigates signaling congestion.
  • the MTC requests the retransmission factor as the basis for the MTC device to determine to initiate the MTC service request again.
  • the apparatus further includes a determining module, configured to determine the MTC request retransmission factor according to the load.
  • the determining module determines different MTC request retransmission factors according to different loads, and sends a different MTC request retransmission factor to the MTC device.
  • the MTC device initiates the MTC request service again after a long delay.
  • the MTC device immediately initiates the MTC request service again.
  • the load includes many aspects.
  • the load may include at least one of the following: a network side device processing load, and a wireless transmission load.
  • the load of the wireless transmission may include at least one of the following: downlink transmit power, uplink interference
  • the device processing load on the network side may include at least one of the following: a board CPU consumption, a message buffer.
  • the determining module may determine, according to one or more of downlink transmit power, uplink interference, board CPU consumption, and message buffer, an MTC request retransmission factor, so that a current load status may be obtained. MTC requests a retransmission factor, which reduces the system burden and reduces system overhead.
  • the load is not static, and the load may change according to the request amount, the response amount, and the like of various services.
  • the determining module is further configured to update the MTC request retransmission factor according to the change of the load; the sending module 22 is further configured to send the updated MTC request retransmission factor to the MTC device.
  • the sending module 22 sends the updated MTC request retransmission factor to the MTC device by using the determining module to update the MTC request retransmission factor according to the change of the load, so that the MTC request retransmission factor is dynamically adjusted according to the change of the load, so that the MTC device is re-
  • the timing of initiating the MTC service request is also dynamically adjusted to optimize the allocation and utilization of resources on the network side.
  • the MTC device Before the sending module 22 sends a message to the MTC device, the MTC device may not know whether the network side supports the MTC service. If the network side does not support the MTC service, it will waste system resources and increase the load.
  • the sending module 22 before the sending module 22 sends a message to the MTC device, the sending module 22 is further configured to send the indication information to the MTC device, where the indication information is used to indicate whether the network side supports the MTC service.
  • the MTC retransmission request factor is carried in the message and sent by the sending module 22 to the MTC device.
  • the message may include at least one of the following: a system message, a connection reject message, or another message, so that multiplexing of the system message or the connection reject message may be implemented, thereby saving the system. Resources, to a certain extent, reduce the load.
  • the MTC request retransmission factor may be in various forms.
  • the MTC request retransmission factor may be a time value indicating the interval of the MTC service request retransmitted by the MTC device.
  • the MTC request retransmission factor is a number, and the number may be provided to the MTC device, so that the MTC performs retransmission according to the number, for example, the MTC device may generate a number and is heavy with the MTC request.
  • the factors are compared and the results are compared to determine whether to resend. This will be described below by way of an alternative embodiment.
  • FIG. 3 is a flowchart 1 of a rescue processing method according to an alternative embodiment of the present invention, which is illustrated from the perspective of an MTC device, and the process includes:
  • Step S302 the machine type communication MTC device receives the message sent by the network side, where the message carries the MTC request retransmission factor;
  • Step S304 The MTC device determines, according to the MTC request retransmission factor, whether to initiate the MTC service request again after the MTC service request is rejected.
  • the machine-type communication MTC device is used to receive the message sent by the network side, where the message carries the MTC request retransmission factor; and the MTC device determines, according to the MTC request retransmission factor, whether to initiate the MTC again after the MTC service request is rejected.
  • the method of business request Through the above steps, the MTC device can determine the retransmission of the MTC service request according to the network side to a certain extent, so that the problem that the MTC device re-initiates the MTC service request in the related art and causes the signaling congestion is solved. The time when the MTC device resends the MTC service request effectively mitigates signaling congestion.
  • the MTC request retransmission factor may be in various forms.
  • the MTC request retransmission factor may be a time value indicating the interval of the MTC service request retransmitted by the MTC device.
  • the MTC requests the retransmission factor to be a number, and after the MTC device obtains the number, according to the number, Line retransmission, for example, the MTC device can generate a number and compare it with the MTC request retransmission factor, and determine whether to retransmit based on the comparison result. This will be described below by way of an alternative embodiment.
  • the MTC device determines, according to the MTC request retransmission factor, whether to initiate the MTC service request again after the MTC service request is rejected, including: the MTC device. A random number is generated, and whether the MTC service request is initiated again is determined according to the relationship between the random number and the MTC request retransmission factor.
  • the timing of re-initiating the MTC service request by a large number of MTC devices may be dispersed, and the signaling congestion is slowed down. To some extent, the probability that the MTC device requests the MTC service to succeed is improved.
  • the MTC device determines, according to the relationship between the random number and the MTC request retransmission factor, whether to initiate the MTC service request again, the following may include at least the following: one:
  • the MTC service request is initiated again if the random number is less than the MTC request retransmission factor.
  • the MTC request retransmission factor value is 0.6
  • the MTC device randomly generates a value in the (0, 1) interval, which is 0.5.
  • the preset relationship is that the random number is greater than the retransmission factor for retransmission, and 0.5 ⁇ 0.6, The MTC device does not resend the MTC service request.
  • the MTC device re-initiates the MTC service request, but the MTC device does not receive the connection setup message.
  • the MTC device initiates the MTC service request exceeding the predetermined schedule. In the case of the number of times, the MTC device identifies the target cell of the MTC service request and performs cell reselection. If the reselected cell includes the target cell, the target cell is rejected.
  • the MTC device is prevented from transmitting the MTC service request to the heavily loaded cell, and the opportunity for the MTC device to request the MTC service is increased, and the system load is reduced to a certain extent, and the resource is effectively utilized.
  • the MTC retransmission request factor is carried in the message sent by the network side.
  • the message may be at least one of the following: a system message, a connection reject message, or other messages.
  • the present invention further provides a processing device for requesting retransmission of a machine type communication
  • FIG. 4 is a structural block diagram of a processing device for requesting retransmission of a machine type communication according to an alternative embodiment of the present invention. As shown in FIG. 4, the device includes:
  • the receiving module 42 is configured to receive a message sent by the network side, where the message carries an MTC request retransmission factor;
  • the retransmission module 44 is configured to determine whether to initiate the MTC service request again after the MTC service request is rejected according to the MTC request retransmission factor.
  • the receiving module 42 receives the message sent by the network side, where the message carries the MTC request retransmission factor; the retransmission module 44 determines, according to the MTC request retransmission factor, whether to initiate again after the MTC service request is rejected.
  • MTC business request MTC business request.
  • the MTC device can determine the retransmission of the MTC service request according to the network side to some extent, so that the problem that the MTC device re-initiates the MTC service request caused by the MTC device in the related art causes signaling congestion can be solved.
  • the time for the MTC device to resend the MTC service request is smoothed, which effectively alleviates the signaling congestion.
  • the MTC request retransmission factor may be in various forms.
  • the MTC request retransmission factor may be a time value indicating the interval of the MTC service request retransmitted by the MTC device.
  • the MTC requests the retransmission factor to be a number, and the MTC device obtains the number through the receiving module 42, and the retransmission module 44 performs retransmission according to the number, for example, the MTC device can generate a number, and Compare with the MTC request retransmission factor and determine whether to resend based on the comparison result. This will be described below by way of an alternative embodiment.
  • the retransmission module 44 includes a judging module configured to generate a random number and request a retransmission factor according to the random number and the MTC. The relationship determines whether to initiate an MTC service request again.
  • the judging module By using the judging module to generate a random number, and determining whether to initiate the MTC service request again according to the relationship between the random number and the MTC request retransmission factor, the timing of re-initiating the MTC service request by a large number of MTC devices may be dispersed, and the signaling congestion is slowed down. To some extent, the probability that the MTC device requests the MTC service to succeed is improved.
  • the determining module may include at least one of the following:
  • a first determining unit configured to initiate an MTC service request again if the random number is greater than the MTC request retransmission factor
  • a second determining unit configured to initiate an MTC service request again if the random number is greater than or equal to the MTC request retransmission factor
  • a third determining unit configured to initiate an MTC service request again if the random number is equal to the MTC request retransmission factor
  • a fourth determining unit configured to initiate an MTC service request again if the random number is less than or equal to the MTC request retransmission factor
  • the fifth determining unit is configured to initiate the MTC service request again if the random number is less than the MTC request retransmission factor.
  • the MTC request retransmission factor value is 0.6
  • the judging module randomly generates a value in the interval of (0, 1), which is 0.5, and the preset relationship selects the first judging unit, and 0.5 ⁇ 0.6, therefore, the MTC device is not heavy.
  • the MTC request retransmission factor value is 10
  • the retransmission module 44 re-initiates the MTC service request several times, but the receiving module 42 does not receive the connection establishment message.
  • the retransmission module When the MTC service request is initiated more than the predetermined number of times, the reselection module is configured to identify the target cell of the MTC service request and perform cell reselection, and if the reselected cell includes the target cell, the target cell is rejected.
  • the retransmission module 44 is prevented from transmitting the MTC service request to the heavily loaded cell, and the opportunity for the MTC device to request the MTC service is increased, and the system load is reduced to a certain extent, and the resource is realized. use efficiently.
  • the MTC retransmission requesting factor is carried in the message sent by the network side.
  • the message may be at least one of the following: a system message, a connection reject message, or another message, so that The reuse of system messages or connection rejection messages saves system resources and reduces the load to a certain extent.
  • the optional embodiment includes: a radio network controller (RNC), an evolved base station (eNodeB), and a cell all belong to the network side, and the user equipment UE belongs to the MTC device; the RNC or the eNodeB sends a message to the UE, where the message carries The MTC requests a retransmission factor, and the MTC request retransmission factor is a basis for the UE to determine to initiate an MTC service request again.
  • the UE receives the message sent by the RNC or the eNodeB, and determines whether to initiate the MTC service request again after the MTC service request is rejected according to the MTC request retransmission factor.
  • the timing of smoothing the retransmission of the MTC service request of the UE is effectively achieved, which effectively alleviates the signaling congestion.
  • the optional embodiment can be used in a 3G, 4G or 5G system, the 3G system corresponds to the RNC, and the LTE system corresponds to the eNodeB.
  • the following is an example of the 3G system;
  • FIG. 5 is a machine class according to an alternative embodiment of the present invention.
  • Step S502 The RNC sends a system message to the UE, where the system message includes an MTC request retransmission factor.
  • the identifier of the MTC request retransmission factor is specifically as shown in Table 1 or Table 2.
  • the MTC request retransmission factor is an integer and the maximum value is 100.
  • the value of the MTC request retransmission factor can be dynamically adjusted according to the load.
  • the maximum value of the MTC request retransmission factor in Table 1 or Table 2 can also be changed according to the specific implementation.
  • Step S504 The UE reads the MTC request retransmission factor, learns that the cell supports the MTC, and initiates an MTC service request, such as an RRC connection request, where the message indicates that the MTC service is requested, and the UE sets a timer and waits for a connection establishment message.
  • MTC service request such as an RRC connection request
  • Step S506 when the timer expires, the UE does not receive the connection establishment message, and generates a random number. If the random number and the MTC request retransmission factor satisfy the preset condition, the MTC service request is initiated again, and the retransmission request counter is incremented by one. . Otherwise, reset the timer for a retransmission interval.
  • the preset condition that the random number and the MTC request retransmission factor satisfy may include: the random number is greater than the retransmission factor, or the random number is greater than or equal to the retransmission factor, or the random number is equal to the retransmission factor, or the random number is less than the retransmission factor, or random The number is less than or equal to the retransmission factor.
  • the MTC requests the retransmission factor value to be 0.6, and the UE randomly generates a value in the interval of (0, 1), which is 0.5.
  • the preset condition is that the random number is greater than the retransmission factor for retransmission, and therefore, the UE does not retransmit the MTC. Business request.
  • the MTC request retransmission factor value is 10, and the UE randomly generates a value in the (1, 10) interval, which is 10, and the preset condition is that the random number is equal to the retransmission factor for retransmission, and the UE retransmits the MTC. Business request.
  • Step S508 when the number of times the retransmission request counter is accumulated reaches the maximum value of the retransmission, the MTC device no longer continues to send the MTC service request to the cell.
  • the method further includes: when the timer expires, the retransmission request counter is incremented by 1, and when the number of times the retransmission request counter is accumulated reaches the maximum value of retransmission, if the MTC device does not perform retransmission at one time, the last attempt is sent in the cell. MTC business request.
  • the time for the UE to resend the MTC service request can be randomized, and the timing of resending the MTC service request is determined according to the network load, and the time for the MTC device to resend the MTC service request is smoothed, thereby effectively alleviating the signaling congestion. .
  • FIG. 6 is a machine type communication request retransmission according to an alternative embodiment of the present invention.
  • Processing method Flowchart 3 the flow in FIG. 6 can also be used in a 3G system, a 4G system, or a 5G system, where the 3G system corresponds to the RNC, the LTE system corresponds to the eNodeB, and the LTE system is taken as an example, as shown in FIG. include:
  • Step S602 The eNodeB sends a system message to the UE, where the system message includes an indication of whether to support the MTC service.
  • Information Element/Group name is information element/group name; Need is required; Multi is multiple; Type and reference are type and reference value; MTC capability is MTC capability; Enumerated (TRMTC device) is enumerated type (Can send and receive MTC device messages).
  • Information Element/Group name is information element/group name; Need is required; Multi is multiple; Type and reference are type and reference value; Enumerated (True, False) is enumeration type (true, false) , which really means supporting the MTC service, and false means not supporting the MTC service.
  • the indication may be other than Table 3 and Table 4, and details are not described herein.
  • Step S604 The UE reads the system message, obtains an indication to support the MTC service, and learns that the cell supports the MTC service, and initiates an MTC service request, such as an RRC connection request, where the message indicates that the MTC service is requested.
  • an MTC service request such as an RRC connection request
  • Step S606 the UE receives the connection reject message sent by the eNodeB, where the message includes the MTC request retransmission factor.
  • the identifier of the MTC request retransmission factor is as shown in Table 5 or Table 6:
  • the value of the MTC request retransmission factor can be dynamically adjusted according to the load.
  • the maximum value of the MTC request retransmission factor in Table 5 or Table 6 can also be changed according to the specific implementation.
  • Step S608 the UE generates a random number. If the random number and the MTC request retransmission factor satisfy the preset condition, the UE initiates the MTC service request again, and the retransmission request counter is incremented by one. Otherwise, the UE resets the timer for a retransmission interval.
  • the preset conditions that the random number and the MTC request retransmission factor satisfy include: the random number is greater than the retransmission factor, or the random number is greater than or equal to the retransmission factor, or the random number is equal to the retransmission factor, or the random number is less than the retransmission factor, or the random number Less than or equal to the retransmission factor.
  • the MTC requests the retransmission factor value to be 0.6, and the UE randomly generates a value in the interval of (0, 1), which is 0.5.
  • the preset condition is that the random number is greater than the retransmission factor for retransmission, and therefore, the UE does not retransmit the MTC. Business request.
  • the MTC request retransmission factor value is 10, and the UE randomly generates a value in the (1, 10) interval, which is 10, and the preset condition is that the random number is equal to the retransmission factor for retransmission, and the UE retransmits the MTC. Business request.
  • Step S610 when the number of times the retransmission request counter is accumulated reaches the maximum value of the retransmission, the UE does not continue to send the MTC service request to the cell.
  • the method further includes: when the timer expires, the retransmission request counter is incremented by 1, and when the number of times the retransmission request counter is accumulated reaches the maximum value of retransmission, if the UE does not perform retransmission at one time, the last attempt is made in the cell, and the MTC is sent. Business request.
  • the UE can only send the MTC service request to the cell supporting the MTC service, which saves system resources, and at the same time, when the MTC service fails to be established, the time for re-issuing the MTC service request by the UE is randomized according to the network load. To determine the timing of resending MTC service requests, reducing network load.
  • FIG. 7 is an alternative embodiment of the present invention.
  • Flowchart 4 of the processing method of requesting retransmission of the machine type communication the flowchart may also be used in a 3G system, a 4G system, or a 5G system, where the 3G system corresponds to the RNC, the LTE system corresponds to the eNodeB, and the LTE system is taken as an example.
  • the process includes:
  • Step S702 after the UE requests the target cell to fail the MTC service, setting a penalty timer.
  • the duration of the timer may be indicated by the eNodeB to the UE by using a message, or may be set by the UE.
  • Step S704 the UE performs cell reselection. If the reselected cell list includes the target cell, if the timer does not time out, the target cell is rejected.
  • Step S706 in the reselected cell list, the UE initiates an MTC service request to the cell supporting the MTC service.
  • the UE can establish the MTC service as soon as possible, and allocate the network side resources reasonably, which reduces the system load to some extent.
  • FIG. 8 is an MTC request in the processing method of the machine type communication request retransmission according to an alternative embodiment of the present invention.
  • a flowchart of the retransmission factor determination which may be applied to a 3G system, a 4G system, or a 5G system, where the 3G system corresponds to the RNC, the LTE system corresponds to the eNodeB, and the LTE system is taken as an example, as shown in FIG.
  • the process includes:
  • Step S802 the cell determines the MTC request retransmission factor according to the load.
  • a corresponding list of the load level and the MTC request retransmission factor is set in the background, and the load level is different, and the MTC request retransmission factor is also different.
  • the load of the cell includes a wireless load or a device processing load, which is defined as a relative percentage with respect to the maximum value
  • the wireless load includes downlink transmit power or uplink interference
  • the device processing load includes a board CPU consumption or a message buffer.
  • the file classification of the wireless load is independent of the device processing load classification.
  • the file is divided into three levels: high, medium, and low, and the relative thresholds are 80%, 55%, and 25%, respectively.
  • the specific values of the MTC request retransmission factor are shown in Table 7 below.
  • the MTC request factor is 10, indicating that when the MTC device needs to retransmit the MTC service request, a random number is randomly generated between 1 and 10.
  • the MTC device is heavy. Send MTC business request.
  • the MTC request factor is 1, indicating that when the MTC device needs to retransmit the MTC service request, a random number is randomly generated between 1 and 1, when the MTC requests the retransmission factor to be equal to 1 At the time, the MTC device resends the MTC service request. Because there is only one value between 1 and 1, the MTC device must resend the MTC service request, which is equivalent to the shutdown of the retransmission factor limit.
  • Step S804 when the load changes, select a new value in the list according to the new load value, request the retransmission factor by the message update MTC, and send the signal to the UE.
  • the MTC request factor can be determined according to the load, and dynamically adjusted according to the change of the load, so that the network side resources can be reasonably utilized, and the load is reduced to some extent.
  • FIG. 9 is a structural block diagram 2 of a processing apparatus for requesting retransmission of a machine type communication according to an alternative embodiment of the present invention.
  • the structural block diagram can be applied to a 3G system, a 4G system, or a 5G system, as shown in FIG. :
  • the first messaging module 92 is configured to receive and send a message, including sending a message to the MTC device, where the message carries an MTC request retransmission factor.
  • Parameter setting module 94 Set to the setting of the message parameter, including setting the MTC request retransmission factor based on the load.
  • the parameter setting module 94 can be configured to set the MTC request retransmission factor based on the compliance, and the first message transceiving module 92 sends a message to the MTC device, where the message carries the MTC request retransmission factor, thereby implementing the current load status.
  • FIG. 9 is a processing device for describing a machine type communication request retransmission from the network side
  • FIG. 10 is a machine type communication request according to an alternative embodiment of the present invention.
  • the structural block diagram of the retransmission processing device is three.
  • the structural block diagram can be applied to a 3G system, a 4G system or a 5G system. As shown in FIG. 10, the device includes:
  • the second messaging module 102 is responsible for receiving, transmitting, and parsing the message, including sending an MTC service request to the network side, receiving a system message or a connection rejection message or other message sent by the network side, parsing the message content, and obtaining the MTC request. Retransmission factor.
  • the determining module 104 includes a determination of whether to resend the MTC request.
  • the second messaging module 102 can send the MTC service request to the network side by using the foregoing modules, and receive the message sent by the network side to obtain the MTC request retransmission factor, and the determining module 104, if the MTC service request is unsuccessful.
  • the timing of resending the MTC request is determined according to the MTC request retransmission factor. Therefore, according to the current load status, the timing of resending the MTC request is determined, the system resources are reasonably utilized, and the time for the MTC device to resend the MTC service request is smoothed, thereby effectively alleviating signaling congestion.
  • a network side device type communication MTC device is used to send a message, where the message carries the MTC request retransmission factor, and the MTC request retransmission factor is the MTC.
  • the device determines the basis for initiating the MTC service request again, and solves the problem that the MTC device re-initiates the MTC service request in the related art, causing the signaling congestion, smoothing the time for the MTC device to resend the MTC service request, and effectively alleviating the letter. Congestion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明提供了一种机器类通信请求重发的处理方法及装置，该方法包括：网络侧向机器类通信MTC设备发送消息，其中，该消息中携带有MTC请求重发因子，MTC请求重发因子是MTC设备判断再次发起MTC业务请求的依据。通过本发明解决了相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。

Description

机器类通信请求重发的处理方法及装置 技术领域
本发明涉及通信领域，具体而言，涉及一种机器类通信请求重发的处理方法及装置。
背景技术
通信网络技术的出现和发展，给社会生活面貌带来了极大的变化，人与人之间可以更加快捷地沟通，信息的交流也更顺畅。然而，目前仅仅是计算机和其他一些互联网技术(Internet Technology，简称IT)类设备具备这种通信和网络能力，而大量的普通机器设备几乎不具备联网和通信能力，这些不具备联网和通信能力的普通机器设备包括：家电、车辆、自动售货机、工厂的机器设备等。
作为机器对机器(Machine to Machine，简称M2M)物联网系统的一项关键技术，机器类通信(Machine-Type Communications，简称MTC)已成为当前一个重要的研究课题。M2M主要是指通过无线网络传递信息给后端的服务器网络来实现机器对机器的实时数据交换，也即机器互联、互通。M2M是所有增强机器设备通信和网络能力的技术总称，M2M技术的目标是使所有机器设备都具备联网和通信能力。
M2M使得机器、设备、应用处理过程与后台信息系统共享信息，并与操作者共享信息。它提供了设备实时地在系统之间、远程设备之间或与个人之间建立无线连接，从而提供传输数据的手段。M2M技术综合了数据采集、全球定位系统(Global Positioning System，简称GPS)、远程监控、电信、信息技术，是计算机、网络、设备、传感器、人类等的生态系统，能够使业务流程自动化，集成公司IT系统和非IT设备的实时状态，并创造增值服务。这一平台可在安全监测、自动抄表、机械服务和维修业务、自动售货机、公共交通系统、车队管理、工业流程自动化、电动机械、城市信息化等环境中运行并提供广泛的应用和解决方案。
M2M系统主要由以下三部分构成：
无线终端：除常用的手机和笔记本电脑外，还包括各类型的行业应用终端；
传输通道：从无线终端到行业应用中心之间的数据传输通道；
行业应用中心：是无线终端上传数据的会聚点，对分散的无线终端进行监控。
M2M技术具有非常重要的意义，有着广阔的市场和应用，推动着社会生产和生活方式新一轮的变革，第三代合作伙伴计划(3rd GenerationPartnership Project，简称3GPP)正致力于建立一个统一规范的M2M通信接口和标准化的传输内容。
预测显示,到2020年MTC的连接数将会达到50亿。如果大量MTC设备同时请求，很容易发生信令拥塞，并且由于设备要集中处理大量的消息，系统的处理能力也会是一个瓶颈。相关技术中对于信令拥塞的处理：拒绝MTC业务，保证人对人(Human to Human，简称H2H)通信的接入。因为目前的MTC业务数量并不多，而一个蜂窝小区所能支持的H2H业务也是很有限的，采取相关技术可以保证H2H业务的接入，而MTC业务通过重发请求延迟接入。但是由于未来的MTC设备的量非常大，有些设备如电表会在晚上集中上报数字，采用相关技术会使大量的MTC设备再次发起重传。因为重传的时机一致，大量的MTC设备发起重传仍然会发生信令拥塞，同时系统还需要同时处理这些消息，很容易造成系统崩溃。
针对相有技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种机器类通信请求重发的处理方法及装置，以解决相有技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题。
根据本发明的一个实施例，提供了一种终机器类通信请求重发的处理方法，包括：网络侧向机器类通信MTC设备发送消息，其中，所述消息中携带有MTC请求重发因子，所述MTC请求重发因子是所述MTC设备判断再次发起MTC业务请求的依据。
在本实施例中，在所述网络侧向所述MTC设备发送所述消息之前，所述方法还包括：所述网络侧根据负荷确定所述MTC请求重发因子。
在本实施例中，所述负荷包括以下至少之一：所述网络侧的设备处理负荷、无线传输的负荷。
在本实施例中，在所述网络侧向所述MTC设备发送所述消息之后，所述方法还包括：所述网络侧根据所述负荷的变化更新所述MTC请求重发因子；所述网络侧将更新后的所述MTC请求重发因子发送给所述MTC设备。
在本实施例中，所述网络侧向所述MTC设备发送消息之前，所述方法还包括：所述网络侧向所述MTC设备发送指示信息，其中，所述指示信息用于指示所述网络侧是否支持MTC业务。
在本实施例中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
在本实施例中，所述MTC请求重发因子为数字。
根据本发明的另一个实施例，还提供了一种机器类通信请求重发的处理方法，包括：机器类通信MTC设备接收网络侧发送的消息，其中，所述消息中携带有MTC请求重发因子；所述MTC设备根据所述MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起所述MTC业务请求。
在本实施例中，所述MTC请求重发因子为数字。
在本实施例中，所述MTC设备根据所述MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起所述MTC业务请求包括：所述MTC设备产生随机数字，并根据所述随机数字与所述MTC请求重发因子的关系确定是否再次发起所述MTC业务请求。
在本实施例中，根据所述随机数字与所述MTC请求重发因子的关系确定是否再次发起所述MTC业务请求包括以下至少之一：在所述随机数字大于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；在所述随机数字大于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；在所述随机数字等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；在所述随机数字小于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；在所述随机数字小于所述MTC请求重发因子的情况下再次发起所述MTC业务请求。
在本实施例中，所述方法还包括：在所述MTC设备发起所述MTC业务请求超过预定次数的情况下，所述MTC设备将所述MTC业务请求的目标小区进行标识，并进行小区重选，如果重选的小区包括所述目标小区，则将所述目标小区剔除。
在本实施例中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
根据本发明的另一个实施例，还提供了一种机器类通信请求重发的处理装置，包括：发送模块，设置为向机器类通信MTC设备发送消息，其中，所述消息中携带有MTC请求重发因子，所述MTC请求重发因子是所述MTC设备判断再次发起MTC业务请求的依据。
在本实施例中，在向所述MTC设备发送所述消息之前，所述装置还包括：确定模块，设置为根据负荷确定所述MTC请求重发因子。
在本实施例中，所述负荷包括以下至少之一：所述网络侧的设备处理负荷、无线传输的负荷。
在本实施例中，在向所述MTC设备发送所述消息之后，所述确定模块，还设置为根据所述负荷的变化更新所述MTC请求重发因子；所述发送模块，还设置为将更新后的所述MTC请求重发因子发送给所述MTC设备。
在本实施例中，向所述MTC设备发送消息之前，所述发送模块，还设置为向所述MTC设备发送指示信息，其中，所述指示信息用于指示所述网络侧是否支持MTC业务。
在本实施例中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
在本实施例中，所述MTC请求重发因子为数字。
根据本发明的另一个实施例，还提供了一种机器类通信请求重发的处理装置，包括：接收模块，设置为接收网络侧发送的消息，其中，所述消息中携带有MTC请求重发因子；重发模块，设置为根据所述MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起所述MTC业务请求。
在本实施例中，所述MTC请求重发因子为数字。
在本实施例中，所述重发模块包括：判断模块，设置为产生随机数字，并根据所述随机数字与所述MTC请求重发因子的关系确定是否再次发起所述MTC业务请求。
在本实施例中，所述判断模块包括以下至少之一：第一判断单元，设置为在所述随机数字大于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；第二判断单元，设置为在所述随机数字大于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；第三判断单元，设置为在所述随机数字等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；第四判断单元，设置为在所述随机数字小于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；第五判断单元，设置为在所述随机数字小于所述MTC请求重发因子的情况下再次发起所述MTC业务请求。
在本实施例中，所述装置还包括：重选模块，设置为在所述MTC设备发起所述MTC业务请求超过预定次数的情况下，将所述MTC业务请求的目标小区进行标识，并进行小区重选，如果重选的小区包括所述目标小区，则将所述目标小区剔除。
在本实施例中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
通过本发明实施例，采用网络侧向机器类通信MTC设备发送消息，其中，所述消息中携带有所述MTC请求重发因子，所述MTC请求重发因子是所述MTC设备判断再次发起MTC业务请求的依据的方式，解决了相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的机器类通信请求重发的处理方法的流程图；
图2是根据本发明实施例的机器类通信请求重发的处理装置的结构框图；
图3是根据本发明可选实施例的机器类通信请求重发的处理方法的流程图一；
图4是根据本发明可选实施例的机器类通信请求重发的处理装置的结构框图一；
图5是根据本发明可选实施例的机器类通信请求重发的处理方法的流程图二；
图6是根据本发明可选实施例的机器类通信请求重发的处理方法的流程图三；
图7是根据本发明可选实施例的机器类通信请求重发的处理方法的流程图四；
图8是根据本发明可选实施例的机器类通信请求重发的处理方法中MTC请求重发因子确定的流程图；
图9是根据本发明可选实施例的机器类通信请求重发的处理装置的结构框图二；
图10是根据本发明可选实施例的机器类通信请求重发的处理装置的结构框图三。
具体实施方式
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本实施例提供了一种机器类通信请求重发的处理方法，图1是根据本发明实施例的机器类通信请求重发的处理方法的流程图，如图1所示，该流程包括如下步骤：
步骤S102，网络侧向机器类通信MTC设备发送消息，其中，该消息中携带有MTC请求重发因子，MTC请求重发因子是MTC设备判断再次发起MTC业务请求的依据。
通过上述步骤，采用网络侧向机器类通信MTC设备发送消息，其中，该消息中携带有MTC请求重发因子，MTC请求重发因子是MTC设备判断再次发起MTC业务请求的依据的方法。通过该步骤，网络侧可以在一定程度上决定MTC设备可以在什么情况下重发该MTC业务请求，从而可以解决相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。
MTC请求重发因子作为MTC设备判断再次发起MTC业务请求的依据，该MTC请求重发因子可以有多种确定方式。在本实施例的一个可选实施方式中，网络侧可以根据负荷确定MTC请求重发因子。
网络侧根据负荷的不同，确定不同的MTC请求重发因子，通过向MTC设备发送不同的MTC请求重发因子，在负荷较重时，使MTC设备在较长延时后再次发起MTC请求业务，或者，在负荷较轻时，使MTC设备立刻再次发起MTC请求业务。通过采取网络侧根据负荷确定MTC请求重发因子的方法，有效减缓了系统负担，降低了系统开销。
负荷可以包括很多方面，在本实施例的一个可选实施方式中，负荷可以包括以下至少之一：网络侧的设备处理负荷、无线传输的负荷。例如，无线传输的负荷可以包括以下至少之一：下行发射功率、上行干扰，网络侧的设备处理负荷可以包括以下至少之一：单板CPU消耗、消息缓存区。在具体的实施过程中，可以根据下行发射功率、 上行干扰、单板CPU消耗、消息缓存区中的一项或者多项来确定MTC请求重发因子，从而可以得到对应于当前负荷状态的MTC请求重发因子，减缓了系统负担，降低了系统开销。
负荷不是一成不变的，根据各种业务的请求量、响应量等，负荷是会发生变化的，在本实施例的一个可选实施方式中，在网络侧向MTC设备发送MTC请求重发因子之后，该流程还包括，网络侧根据负荷的变化更新MTC请求重发因子；网络侧将更新后的MTC请求重发因子发送给MTC设备。通过采取网络侧根据负荷的变化更新MTC请求重发因子，并将更新后的MTC请求重发因子发送给MTC设备的方法，实现了MTC请求重发因子根据负荷的变化动态调整，使得MTC设备重新发起MTC业务请求的时机也动态调整，优化了网络侧资源的分配和利用。
网络侧向MTC设备发送消息之前，MTC设备可以不知道网络侧是否支持MTC业务。如果网络侧不支持MTC业务，会造成系统资源的浪费，加大负荷。在本实施例的一个可选实施方式中，网络侧向MTC设备发送消息之前，网络侧向MTC设备发送指示信息，其中，该指示信息用于指示网络侧是否支持MTC业务。通过采取上述方法，可以在一定程度上节省系统资源。
MTC重发请求因子是携带在消息中，由网络侧向MTC设备发送的。在本实施例的一个可选实施方式中，该消息可以包括以下至少之一：系统消息、连接拒绝消息，也可以是其他消息。通过采取上述方法，可以实现系统消息或连接拒绝消息的复用，节省了系统资源，在一定程度上减轻负荷。
MTC请求重发因子可以是多种形式，例如，该MTC请求重发因子可以是一个时间值，该时间可以指示MTC设备重发的MTC业务请求的间隔。在本实施的一个可选实施方式中，MTC请求重发因子为数字，该数字可以提供给MTC设备，使MTC根据该数字来进行重发，例如，MTC设备可以产生数字，并与MTC请求重发因子做比较，根据比较结果来确定是否重发。在下文中将以一个可选实施例为例对此进行说明。
在实施例中还提供了一种装置，该装置与上述实施例中的方法相对应，已经进行过说明的在此不再赘述。该装置中的模块或单元可以是存储在存储器中并可以被处理器运行的代码，该存储器和处理器可以位于终端中，但并不限于此，该装置也可以用其他方式实现，在此不再一一举例。
在一个可选的实施例中，本发明还提供了一种机器类通信请求重发的处理装置，图2是根据本发明实施例的机器类通信请求重发的处理装置的结构框图，如图2所示，该装置包括发送模块22，设置为向机器类通信MTC设备发送消息，其中，该消息中 携带有MTC请求重发因子，MTC请求重发因子是MTC设备判断再次发起MTC业务请求的依据。
通过利用上述装置，采用发送模块22向机器类通信MTC设备发送消息，其中，该消息中携带有MTC请求重发因子，MTC请求重发因子是MTC设备判断再次发起MTC业务请求的依据的方法。通过该模块，网络侧可以在一定程度上决定MTC设备可以在什么情况下重发该MTC业务请求，从而可以解决相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。
MTC请求重发因子作为MTC设备判断再次发起MTC业务请求的依据，在本实施例的一个可选实施方式中，该装置还包括确定模块，设置为根据负荷确定MTC请求重发因子。
确定模块根据负荷的不同，确定不同的MTC请求重发因子，通过向MTC设备发送不同的MTC请求重发因子，在负荷较重时，使MTC设备在较长延时后再次发起MTC请求业务，或者，在负荷较轻时，使MTC设备立刻再次发起MTC请求业务。通过采取确定模块根据负荷确定MTC请求重发因子的方法，有效减缓了系统负担，降低了系统开销。
负荷包括很多方面，在本实施例的一个可选实施方式中，负荷可以包括以下至少之一：网络侧的设备处理负荷、无线传输的负荷。例如，无线传输的负荷可以包括以下至少之一：下行发射功率、上行干扰，网络侧的设备处理负荷可以包括以下至少之一：单板CPU消耗、消息缓存区。在具体的实施过程中，确定模块可以根据下行发射功率、上行干扰、单板CPU消耗、消息缓存区中的一项或者多项来确定MTC请求重发因子，从而可以得到对应于当前负荷状态的MTC请求重发因子，减缓了系统负担，降低了系统开销。
负荷不是一成不变的，根据各种业务的请求量、响应量等，负荷是会发生变化的，在本实施例的一个可选实施方式中，在发送模块22向MTC设备发送MTC请求重发因子之后，确定模块还设置为根据负荷的变化更新MTC请求重发因子；发送模块22还设置为将更新后的MTC请求重发因子发送给MTC设备。通过利用确定模块根据负荷的变化更新MTC请求重发因子，发送模块22将更新后的MTC请求重发因子发送给MTC设备，实现了MTC请求重发因子根据负荷的变化动态调整，使得MTC设备重新发起MTC业务请求的时机也动态调整，优化了网络侧资源的分配和利用。
发送模块22向MTC设备发送消息之前，MTC设备可以不知道网络侧是否支持MTC业务。如果网络侧不支持MTC业务，会造成系统资源的浪费，加大负荷。在本实施例的一个可选实施方式中，发送模块22向MTC设备发送消息之前，发送模块22还设置为向MTC设备发送指示信息，其中，该指示信息用于指示网络侧是否支持MTC业务。通过采取上述方法，可以在一定程度上节省系统资源。
MTC重发请求因子是携带在消息中，由发送模块22向MTC设备发送的。在本实施例的一个可选实施方式中，该消息可以包括以下至少之一：系统消息、连接拒绝消息，也可以是其他消息，从而可以实现系统消息或连接拒绝消息的复用，节省了系统资源，在一定程度上减轻负荷。
MTC请求重发因子可以是多种形式，例如，该MTC请求重发因子可以是一个时间值，该时间可以指示MTC设备重发的MTC业务请求的间隔。在本实施的一个可选实施方式中，MTC请求重发因子为数字，该数字可以提供给MTC设备，使MTC根据该数字来进行重发，例如，MTC设备可以产生数字，并与MTC请求重发因子做比较，根据比较结果来确定是否重发。在下文中将以一个可选实施例为例对此进行说明。
上述实施例及可选的实施方式是从网络侧的角度来进行说明的，该网络侧一般是小区，但并不限于此。下面从MTC设备端来进行说明，图3是根据本发明可选实施例的救援处理方法的流程图一，是从MTC设备的角度来进行说明的，该流程包括：
步骤S302，机器类通信MTC设备接收网络侧发送的消息，其中，该消息中携带有MTC请求重发因子；
步骤S304，MTC设备根据MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起MTC业务请求。
上述各个步骤，采用机器类通信MTC设备接收网络侧发送的消息，其中，该消息中携带有MTC请求重发因子；MTC设备根据MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起MTC业务请求的方法。通过上述步骤，MTC设备可以在一定程度上根据网络侧来决定在什么情况下重发该MTC业务请求，从而可以解决相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。
MTC请求重发因子可以是多种形式，例如，该MTC请求重发因子可以是一个时间值，该时间可以指示MTC设备重发的MTC业务请求的间隔。在本实施的一个可选实施方式中，MTC请求重发因子为数字，MTC设备获得该数字后，根据该数字来进 行重发，例如，MTC设备可以产生数字，并与MTC请求重发因子做比较，根据比较结果来确定是否重发。在下文中将以一个可选实施例为例对此进行说明。
在MTC请求重发因子为数字的情况下，在本实施例的一个可选实施方式中，MTC设备根据MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起MTC业务请求包括：MTC设备产生随机数字，并根据该随机数字与MTC请求重发因子的关系确定是否再次发起MTC业务请求。
通过采取产生随机数字，并根据该随机数字与MTC请求重发因子的关系确定是否再次发起所述MTC业务请求的方法，可以使大量MTC设备重新发起MTC业务请求的时机分散，减缓了信令拥塞，在一定程度上使得MTC设备请求MTC业务成功的机率提高。
随机数字与MTC请求重发因子的关系有多种，在本实施的一个可选实施方式中，MTC设备根据随机数字与MTC请求重发因子的关系去确定是否再次发起MTC业务请求可以包括以下至少之一：
在随机数字大于MTC请求重发因子的情况下再次发起MTC业务请求；
在随机数字大于或等于MTC请求重发因子的情况下再次发起MTC业务请求；
在随机数字等于MTC请求重发因子的情况下再次发起MTC业务请求；
在随机数字小于或等于MTC请求重发因子的情况下再次发起MTC业务请求；
在随机数字小于MTC请求重发因子的情况下再次发起MTC业务请求。
例如，MTC请求重发因子值是0.6，MTC设备在(0,1)区间内随机产生一个值，为0.5，预设的关系为随机数大于重发因子进行重发，而0.5＜0.6，因此，MTC设备不重发MTC业务请求。
又例如，MTC请求重发因子值是10，MTC设备在(1,10)区间内随机产生一个值，为10，预设的关系为随机数等于重发因子进行重发，在这里，10＝10，因此，MTC设备重发MTC业务请求。
有时，网络侧小区的负荷很大，MTC设备若干次重新发起MTC业务请求，但是都没有收到连接建立消息，在本实施例的一个可选实施方式中，在MTC设备发起MTC业务请求超过预定次数的情况下，MTC设备将MTC业务请求的目标小区进行标识，并进行小区重选，如果重选的小区包括目标小区，则将目标小区剔除。
通过采取上述方法，避免了MTC设备无限制向负荷较重的小区发送MTC业务请求，增加了MTC设备请求MTC业务成功的机会，并在一定程度上减轻了系统负荷，实现了资源的有效利用。
MTC重发请求因子携带在网络侧发送的消息中，在本实施例的一个可选的实施方式中，消息可以为以下至少之一：系统消息、连接拒绝消息，也可以其他消息。通过采取上述方法，可以实现系统消息或连接拒绝消息的复用，节省了系统资源，在一定程度上减轻负荷。
在一个可选的实施例中，本发明还提供了一种机器类通信请求重发的处理装置，图4是根据本发明可选实施例的机器类通信请求重发的处理装置的结构框图一，如图4所示，该装置包括：
接收模块42，设置为接收网络侧发送的消息，其中，该消息中携带有MTC请求重发因子；
重发模块44，设置为根据MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起MTC业务请求。
通过上述各个模块，利用接收模块42接收网络侧发送的消息，其中，该消息中携带有MTC请求重发因子；重发模块44根据MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起MTC业务请求。通过上述各个模块，MTC设备可以在一定程度上根据网络侧来决定在什么情况下重发该MTC业务请求，从而可以解决相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。
MTC请求重发因子可以是多种形式，例如，该MTC请求重发因子可以是一个时间值，该时间可以指示MTC设备重发的MTC业务请求的间隔。在本实施的一个可选实施方式中，MTC请求重发因子为数字，MTC设备通过接收模块42获取该数字，重发模块44根据该数字来进行重发，例如，MTC设备可以产生数字，并与MTC请求重发因子做比较，根据比较结果来确定是否重发。在下文中将以一个可选实施例为例对此进行说明。
在MTC请求重发因子为数字的情况下，在本实施例的一个可选实施方式中，重发模块44包括判断模块，设置为产生随机数字，并根据该随机数字与MTC请求重发因子的关系确定是否再次发起MTC业务请求。
通过利用判断模块产生随机数字，并根据该随机数字与MTC请求重发因子的关系确定是否再次发起所述MTC业务请求，可以使大量MTC设备重新发起MTC业务请求的时机分散，减缓了信令拥塞，在一定程度上使得MTC设备请求MTC业务成功的机率提高。
随机数字与MTC请求重发因子的关系有多种，对应着有多种实现单元，在本实施的一个可选实施方式中，判断模块可以包括以下至少之一：
第一判断单元，设置为在随机数字大于MTC请求重发因子的情况下再次发起MTC业务请求；
第二判断单元，设置为在随机数字大于或等于MTC请求重发因子的情况下再次发起MTC业务请求；
第三判断单元，设置为在随机数字等于MTC请求重发因子的情况下再次发起MTC业务请求；
第四判断单元，设置为在随机数字小于或等于MTC请求重发因子的情况下再次发起MTC业务请求；
第五判断单元，设置为在随机数字小于MTC请求重发因子的情况下再次发起MTC业务请求。
例如，MTC请求重发因子值是0.6，判断模块在(0,1)区间内随机产生一个值，为0.5，预设的关系选择第一判断单元，而0.5＜0.6，因此，MTC设备不重发MTC业务请求。
又例如，MTC请求重发因子值是10，判断模块在(1,10)区间内随机产生一个值，为10，预设的关系选择第三判断单元，在这里，10＝10，因此，MTC设备重发MTC业务请求。
有时，网络侧小区的负荷很大，重发模块44若干次重新发起MTC业务请求，但是接收模块42都没有收到连接建立消息，在本实施例的一个可选实施方式中，在重发模块44发起MTC业务请求超过预定次数的情况下，重选模块，设置为将MTC业务请求的目标小区进行标识，并进行小区重选，如果重选的小区包括目标小区，则将目标小区剔除。
通过利用重选模块，避免了重发模块44无限制向负荷较重的小区发送MTC业务请求，增加了MTC设备请求MTC业务成功的机会，并在一定程度上减轻了系统负荷，实现了资源的有效利用。
MTC重发请求因子携带在网络侧发送的消息中，在本实施例的一个可选的实施方式中，消息可以为以下至少之一：系统消息、连接拒绝消息，也可以其他消息，从而可以实现系统消息或连接拒绝消息的复用，节省了系统资源，在一定程度上减轻负荷。
下面的可选实施例结合了实际的网络结构，下面对该可选实施例进行说明。
本可选实施例包括：无线网络控制器(RNC)、演进型基站(eNodeB)和小区都属于网络侧，用户设备UE属于MTC设备；RNC或eNodeB向UE发送消息，其中，该消息中携带有MTC请求重发因子，MTC请求重发因子是UE判断再次发起MTC业务请求的依据。UE接收RNC或eNodeB发送的消息，根据MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起MTC业务请求。最后实现平滑UE的重发MTC业务请求的时机，有效缓解了信令拥塞。
本可选实施例可以用于3G、4G或5G系统中，3G系统对应于RNC，LTE系统对应于eNodeB，下面以3G系统为例进行说明；图5是根据本发明可选实施例的机器类通信请求重发的处理方法的流程图二，如图5所示，本发明可选实施例的流程包括：
步骤S502，RNC向UE发送系统消息，系统消息中包含MTC请求重发因子。
其中，MTC请求重发因子的标识具体如表1或表2所示。
Figure PCTCN2015075155-appb-000001
表1
在表1中，Information Element/Group name为信息元素/组名；Need为需要；Multi为多项；Type and reference为类型和参考值；MTC retry factor为MTC请求重发因子。由表1可知，MTC请求重发因子为0到1区间的一个数。
Figure PCTCN2015075155-appb-000002
表2
在表2中，Information Element/Group name为信息元素/组名；Need为需要；Multi为多项；Type and reference为类型和参考值；MTC retry factor为MTC请求重发因子。由表2可知，MTC请求重发因子为整数，最大值为100。
MTC请求重发因子的值可以根据负荷的不同动态调整，表1或表2中MTC请求重发因子的最大值也可以根据具体实施情况作出改变。
步骤S504，UE读取到MTC请求重发因子，获知该小区支持MTC，发起MTC业务请求，如RRC连接请求，消息中指明请求MTC业务，UE设置定时器，等待连接建立消息。
步骤S506，当定时器超时，UE没有收到连接建立消息，则产生一个随机数，如果这个随机数和MTC请求重发因子满足预设条件，则再次发起MTC业务请求，重发请求计数器加1。否则，重新设置定时器，时长为重发间隔。
随机数和MTC请求重发因子满足的预设条件可以包括：随机数大于重发因子，或者随机数大于等于重发因子，或者随机数等于重发因子，或者随机数小于重发因子，或者随机数小于等于重发因子。
例如，MTC请求重发因子值是0.6，UE在(0,1)区间内随机产生一个值，为0.5，预设的条件为随机数大于重发因子进行重发，因此，UE不重发MTC业务请求。
又例如，MTC请求重发因子值是10，UE在(1,10)区间内随机产生一个值，为10，预设的条件为随机数等于重发因子进行重发，因子，UE重发MTC业务请求。
步骤S508，当重发请求计数器累加的次数达到了重发的最大值，MTC设备不再向该小区继续发送MTC业务请求。
还包括：当定时器超时，重发请求计数器加1，当重发请求计数器累加的次数达到了重发的最大值，如果MTC设备一次都没有进行重发，则在该小区尝试最后一次，发送MTC业务请求。
通过采取上述步骤，可以使得UE重发MTC业务请求的时间随机化，根据网络负荷来确定重新发送MTC业务请求的时机，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。
除了采取图5所示的流程，本发明还提供了另一种机器类通信请求重发的处理方法的可选流程图，图6是根据本发明可选实施例的机器类通信请求重发的处理方法的 流程图三，图6中的流程也可以用于3G系统、4G系统或5G系统中，3G系统对应于RNC，LTE系统对应于eNodeB，以LTE系统为例，如图6所示，该流程图包括：
步骤S602，eNodeB向UE发送系统消息，该系统消息中包含是否支持MTC业务的指示。
其中，该指示具体如表3或表4所示：
Figure PCTCN2015075155-appb-000003
表3
在表3中，Information Element/Group name为信息元素/组名；Need为需要；Multi为多项；Type and reference为类型和参考值；MTC capability为MTC能力；Enumerated(TRMTC设备)为枚举类型(可收发MTC设备消息)。
Figure PCTCN2015075155-appb-000004
表4
在表4中，Information Element/Group name为信息元素/组名；Need为需要；Multi为多项；Type and reference为类型和参考值；Enumerated(True，False)为枚举类型(真，假)，其中真表示支持MTC业务，假表示不支持MTC业务。
在具体实施过程中，该指示可以为除了表3和表4之外的其他形式，在此不一一赘述。
步骤S604，UE读取系统消息，获取到支持MTC业务的指示，获知该小区支持MTC业务，发起MTC业务请求，如RRC连接请求，消息中指明请求MTC业务。
步骤S606，UE收到eNodeB发送的连接拒绝消息，消息中包含了MTC请求重发因子。
MTC请求重发因子的标识具体如表5或表6所示：
Figure PCTCN2015075155-appb-000005
表5
在表5中，Information Element/Group name为信息元素/组名；Need为需要；Multi为多项；Type and reference为类型和参考值；MTC retry factor为MTC请求重发因子。由表5可知，MTC请求重发因子为0到1区间的一个数。
Figure PCTCN2015075155-appb-000006
表6
在表6中，Information Element/Group name为信息元素/组名；Need为需要；Multi为多项；Type and reference为类型和参考值；MTC retry factor为MTC请求重发因子。由表6可知，MTC请求重发因子为整数，最大值为100或者其他值。
MTC请求重发因子的值可以根据负荷的不同动态调整，表5或表6中MTC请求重发因子的最大值也可以根据具体实施情况作出改变。
步骤S608，UE产生一个随机数，如果该随机数和MTC请求重发因子满足预设条件，则UE再次发起MTC业务请求，重发请求计数器加1。否则，UE重新设置定时器，时长为重发间隔。
随机数和MTC请求重发因子满足的预设条件包括：随机数大于重发因子，或者随机数大于等于重发因子，或者随机数等于重发因子，或者随机数小于重发因子，或者随机数小于等于重发因子。
例如，MTC请求重发因子值是0.6，UE在(0,1)区间内随机产生一个值，为0.5，预设的条件为随机数大于重发因子进行重发，因此，UE不重发MTC业务请求。
又例如，MTC请求重发因子值是10，UE在(1,10)区间内随机产生一个值，为10，预设的条件为随机数等于重发因子进行重发，因子，UE重发MTC业务请求。
步骤S610，当重发请求计数器累加的次数达到了重发的最大值，UE不再向该小区继续发送MTC业务请求。
还包括：当定时器超时，重发请求计数器加1，当重发请求计数器累加的次数达到了重发的最大值，如果UE一次都没有进行重发，则在该小区尝试最后一次，发送MTC业务请求。
通过采取上述步骤，可以使得UE仅向支持MTC业务的小区发送MTC业务请求，节省了系统资源，同时在MTC业务建立失败的情况下，使UE重发MTC业务请求的时间随机化，根据网络负荷来确定重新发送MTC业务请求的时机，减轻了网络负荷。
如图5、图6所示，为了使UE尽快与小区建立MTC业务，UE不能在重发次数达到最大值后，继续向该小区发送MTC业务请求，图7是根据本发明可选实施例的机器类通信请求重发的处理方法的流程图四，该流程图也可以用于3G系统、4G系统或5G系统中，其中3G系统对应于RNC，LTE系统对应于eNodeB，以LTE系统为例，如图7所示，该流程包括：
步骤S702，UE向目标小区请求MTC业务失败后，设置一个惩罚定时器；
其中，定时器的时长可以由eNodeB通过消息指示给UE，也可以由UE自行进行设置。
步骤S704，UE执行小区重选，如果重选的小区列表中包含目标小区，如果定时器没有超时，则将目标小区剔除。
步骤S706，在重选的小区列表中，UE向支持MTC业务的小区发起MTC业务请求。
通过采取以上步骤，可以使UE尽快建立MTC业务，同时合理分配了网络侧资源，一定程度上减轻了系统负荷。
在UE请求MTC业务失败后，重新发起MTC业务请求的时机在一定程度上取决于MTC重发请求因子，图8是根据本发明可选实施例的机器类通信请求重发的处理方法中MTC请求重发因子确定的流程图，该流程图可以应用于3G系统、4G系统或5G系统中，其中3G系统对应于RNC，LTE系统对应于eNodeB，以LTE系统为例，如图8所示，该流程包括：
步骤S802，小区依据负荷来确定MTC请求重发因子。
具体地，后台设置了负荷档级与MTC请求重发因子的对应列表，负荷档级不同，MTC请求重发因子也不同。
例如：小区的负荷包括无线负荷或设备处理负荷，定义为相对于最大值的一个相对百分比，无线负荷包括下行发射功率或者上行干扰，设备处理负荷包括单板CPU消耗或消息缓存区。
无线负荷的档级分类与设备处理负荷分类独立，在本实施例中可选的实施方式中，都分成三个档级：高、中、低，相对门限分别为80％，55％，25％，MTC请求重发因子具体取值如下表7所示。
Figure PCTCN2015075155-appb-000007
表7
当无线负荷和设备处理负荷都处于高档时，MTC请求因子为10，表示当MTC设备需要重传MTC业务请求时，在1到10之间随机产生一个随机数，当等于10时，MTC设备重发MTC业务请求。
当无线负荷和设备处理负荷都处于低档时，MTC请求因子为1，表示当MTC设备需要重传MTC业务请求时，在1到1之间随机产生一个随机数，当MTC请求重发因子等于1时，MTC设备重发MTC业务请求。因为1到1之间只有1这个取值，所以MTC设备一定会重发MTC业务请求，相当于对于重传因子限制的关闭。
步骤S804，当负荷发生变化时，根据新的负荷值，在列表中选择新的值，通过消息更新MTC请求重发因子，发送给UE。
通过以上步骤，可以实现MTC请求因子根据负荷确定，并随着负荷的变化动态调整，从而使网络侧资源实现合理利用，一定程度上缓减了负荷。
上述可选实施例为对于机器类通信请求重发的处理方法的描述，下面对本发明的机器类通信请求重发的处理装置进行描述。图9是根据本发明可选实施例的机器类通信请求重发的处理装置的结构框图二，该结构框图可以应用于3G系统、4G系统或5G系统中，如图9所示，该装置包括：
第一消息收发模块92，设置为消息的接收、发送，包括向MTC设备发送消息，消息中携带MTC请求重发因子。
参数设置模块94：设置为消息参数的设置，包括基于负荷来设置MTC请求重发因子。
利用上述各个模块，可以实现参数设置模块94基于符合来设置MTC请求重发因子，第一消息收发模块92向MTC设备发送消息，其中该消息中携带MTC请求重发因子，从而实现根据当前负荷状态，合理分配系统资源，平滑MTC设备重新发送MTC业务请求的时间，有效的缓解信令拥塞。
图9是从网络侧来描述机器类通信请求重发的处理装置的，下面从MTC设备侧描述机器类通信请求重发的处理装置，图10是根据本发明可选实施例的机器类通信请求重发的处理装置的结构框图三，该结构框图可以应用于3G系统、4G系统或5G系统中，如图10所示，该装置包括：
第二消息收发模块102：负责消息的接收、发送，与消息解析，包括向网络侧发送MTC业务请求，接收网络侧发送的系统消息或者连接拒绝消息或者其他消息，解析消息内容，获取到MTC请求的重发因子。
判断模块104，包括是否重发MTC请求的判断。
利用上述各个模块，可以实现第二消息收发模块102向网络侧发送MTC业务请求，并在MTC业务请求不成功的情况下，接收网络侧发送的消息，获取到MTC请求重发因子，判断模块104根据MTC请求重发因子判断再次发送MTC请求的时机。从而实现根据当前负荷状态，确定重新发送MTC请求的时机，合理利用系统资源，平滑MTC设备重新发送MTC业务请求的时间，有效的缓解信令拥塞。
以上仅为本发明的可选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
工业实用性
基于本发明实施例提供的上述技术方案，采用网络侧向机器类通信MTC设备发送消息，其中，所述消息中携带有所述MTC请求重发因子，所述MTC请求重发因子是所述MTC设备判断再次发起MTC业务请求的依据的方式，解决了相关技术中大量的MTC设备重新发起MTC业务请求导致信令拥塞的问题，平滑了MTC设备重新发送MTC业务请求的时间，有效的缓解了信令拥塞。

Claims (26)

  1. 一种机器类通信请求重发的处理方法，包括：
    网络侧向机器类通信MTC设备发送消息，其中，所述消息中携带有MTC请求重发因子，所述MTC请求重发因子是所述MTC设备判断再次发起MTC业务请求的依据。
  2. 根据权利要求1所述的方法，其中，在所述网络侧向所述MTC设备发送所述消息之前，所述方法还包括：
    所述网络侧根据负荷确定所述MTC请求重发因子。
  3. 根据权利要求2所述的方法，其中，所述负荷包括以下至少之一：所述网络侧的设备处理负荷、无线传输的负荷。
  4. 根据权利要求2所述的方法，其中，在所述网络侧向所述MTC设备发送所述消息之后，所述方法还包括：
    所述网络侧根据所述负荷的变化更新所述MTC请求重发因子；
    所述网络侧将更新后的所述MTC请求重发因子发送给所述MTC设备。
  5. 根据权利要求1至4中任一项所述的方法，其中，所述网络侧向所述MTC设备发送消息之前，所述方法还包括：
    所述网络侧向所述MTC设备发送指示信息，其中，所述指示信息用于指示所述网络侧是否支持MTC业务。
  6. 根据权利要求1至4中任一项所述的方法，其中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
  7. 根据权利要求1至4中任一项所述的方法，其中，所述MTC请求重发因子为数字。
  8. 一种机器类通信请求重发的处理方法，包括：
    机器类通信MTC设备接收网络侧发送的消息，其中，所述消息中携带有MTC请求重发因子；
    所述MTC设备根据所述MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起所述MTC业务请求。
  9. 根据权利要求8所述的方法，其中，所述MTC请求重发因子为数字。
  10. 根据权利要求9所述的方法，其中，所述MTC设备根据所述MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起所述MTC业务请求包括：
    所述MTC设备产生随机数字，并根据所述随机数字与所述MTC请求重发因子的关系确定是否再次发起所述MTC业务请求。
  11. 根据权利要求10所述的方法，其中，根据所述随机数字与所述MTC请求重发因子的关系确定是否再次发起所述MTC业务请求包括以下至少之一：
    在所述随机数字大于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    在所述随机数字大于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    在所述随机数字等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    在所述随机数字小于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    在所述随机数字小于所述MTC请求重发因子的情况下再次发起所述MTC业务请求。
  12. 根据权利要求8至11中任一项所述的方法，其中，所述方法还包括：
    在所述MTC设备发起所述MTC业务请求超过预定次数的情况下，所述MTC设备将所述MTC业务请求的目标小区进行标识，并进行小区重选，如果重选的小区包括所述目标小区，则将所述目标小区剔除。
  13. 根据权利要求8至11中任一项所述的方法，其中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
  14. 一种机器类通信请求重发的处理装置，包括：
    发送模块，设置为向机器类通信MTC设备发送消息，其中，所述消息中携带有MTC请求重发因子，所述MTC请求重发因子是所述MTC设备判断再次发起MTC业务请求的依据。
  15. 根据权利要求14所述的装置，其中，在向所述MTC设备发送所述消息之前，所述装置还包括：
    确定模块，设置为根据负荷确定所述MTC请求重发因子。
  16. 根据权利要求15所述的装置，其中，所述负荷包括以下至少之一：网络侧的设备处理负荷、无线传输的负荷。
  17. 根据权利要求15所述的装置，其中，在向所述MTC设备发送所述消息之后，
    所述确定模块，还设置为根据所述负荷的变化更新所述MTC请求重发因子；
    所述发送模块，还设置为将更新后的所述MTC请求重发因子发送给所述MTC设备。
  18. 根据权利要求14至17中任一项所述的装置，其中，向所述MTC设备发送消息之前，
    所述发送模块，还设置为向所述MTC设备发送指示信息，其中，所述指示信息用于指示所述网络侧是否支持MTC业务。
  19. 根据权利要求14至17中任一项所述的装置，其中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
  20. 根据权利要求14至17中任一项所述的装置，其中，所述MTC请求重发因子为数字。
  21. 一种机器类通信请求重发的处理装置，包括：
    接收模块，设置为接收网络侧发送的消息，其中，所述消息中携带有MTC请求重发因子；
    重发模块，设置为根据所述MTC请求重发因子确定在MTC业务请求被拒绝后是否再次发起所述MTC业务请求。
  22. 根据权利要求21所述的装置，其中，所述MTC请求重发因子为数字。
  23. 根据权利要求22所述的装置，其中，所述重发模块包括：
    判断模块，设置为产生随机数字，并根据所述随机数字与所述MTC请求重发因子的关系确定是否再次发起所述MTC业务请求。
  24. 根据权利要求23所述的装置，其中，所述判断模块包括以下至少之一：
    第一判断单元，设置为在所述随机数字大于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    第二判断单元，设置为在所述随机数字大于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    第三判断单元，设置为在所述随机数字等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    第四判断单元，设置为在所述随机数字小于或等于所述MTC请求重发因子的情况下再次发起所述MTC业务请求；
    第五判断单元，设置为在所述随机数字小于所述MTC请求重发因子的情况下再次发起所述MTC业务请求。
  25. 根据权利要求21至24中任一项所述的装置，其中，所述装置还包括：
    重选模块，设置为在发起所述MTC业务请求超过预定次数的情况下，将所述MTC业务请求的目标小区进行标识，并进行小区重选，如果重选的小区包括所述目标小区，则将所述目标小区剔除。
  26. 根据权利要求21至24中任一项所述的装置，其中，所述消息包括以下至少之一：系统消息、连接拒绝消息。
PCT/CN2015/075155 2014-10-22 2015-03-26 机器类通信请求重发的处理方法及装置 WO2016062005A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410568375.8A CN105592398A (zh) 2014-10-22 2014-10-22 机器类通信请求重发的处理方法及装置
CN201410568375.8 2014-10-22

Publications (1)

Publication Number Publication Date
WO2016062005A1 true WO2016062005A1 (zh) 2016-04-28

Family

ID=55760170

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/075155 WO2016062005A1 (zh) 2014-10-22 2015-03-26 机器类通信请求重发的处理方法及装置

Country Status (2)

Country Link
CN (1) CN105592398A (zh)
WO (1) WO2016062005A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106792931A (zh) * 2015-11-24 2017-05-31 展讯通信（上海）有限公司 Mtc终端小区重选控制方法及装置
CN106792988A (zh) * 2015-11-24 2017-05-31 展讯通信（上海）有限公司 Mtc终端网络接入控制方法及装置
CN110012521A (zh) * 2018-01-05 2019-07-12 中国移动通信有限公司研究院 一种调度请求传输方法、装置和计算机可读存储介质
TWI705729B (zh) * 2019-05-21 2020-09-21 中華電信股份有限公司 應用於行動物聯網終端之分散接入、資料傳收及重傳處理方法及系統

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118833A (zh) * 2011-03-04 2011-07-06 电信科学技术研究院 一种小区接入指示方法、小区选择方法和设备
CN102469555A (zh) * 2010-11-05 2012-05-23 中兴通讯股份有限公司 终端接入网络的方法及系统
CN102469514A (zh) * 2010-11-05 2012-05-23 中兴通讯股份有限公司 终端及其接入网络的方法
US20120178436A1 (en) * 2011-01-07 2012-07-12 Renesas Mobile Corporation Wait Timer for Delay Tolerant Terminal
WO2012111993A2 (en) * 2011-02-16 2012-08-23 Pantech Co., Ltd. Method and apparatus for rrc connection establishment in mtc
CN104067535A (zh) * 2012-01-18 2014-09-24 Lg电子株式会社 在无线通信系统中基于多个优先级的控制方法和设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102448117B (zh) * 2010-09-30 2016-04-13 电信科学技术研究院 一种负荷控制的方法和设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102469555A (zh) * 2010-11-05 2012-05-23 中兴通讯股份有限公司 终端接入网络的方法及系统
CN102469514A (zh) * 2010-11-05 2012-05-23 中兴通讯股份有限公司 终端及其接入网络的方法
US20120178436A1 (en) * 2011-01-07 2012-07-12 Renesas Mobile Corporation Wait Timer for Delay Tolerant Terminal
WO2012111993A2 (en) * 2011-02-16 2012-08-23 Pantech Co., Ltd. Method and apparatus for rrc connection establishment in mtc
CN102118833A (zh) * 2011-03-04 2011-07-06 电信科学技术研究院 一种小区接入指示方法、小区选择方法和设备
CN104067535A (zh) * 2012-01-18 2014-09-24 Lg电子株式会社 在无线通信系统中基于多个优先级的控制方法和设备

Also Published As

Publication number Publication date
CN105592398A (zh) 2016-05-18

Similar Documents

Publication Publication Date Title
CN112203336B (zh) 无线接入控制方法、装置及系统
EP3981190B1 (en) Method and apparatus for enforcement of maximum number of protocol data unit sessions per network slice in a communication system
US10028293B2 (en) Method and apparatus for controlling data transmission on radio communication network
US11140737B2 (en) Session processing method in wireless communications and terminal device
US10362549B2 (en) Method and apparatus for setting up interface between access points
CN110535808B (zh) 一种设备监控、去注册方法及装置
WO2016062005A1 (zh) 机器类通信请求重发的处理方法及装置
US20180084565A1 (en) Bearer setup method and apparatus
EP3698497A1 (en) Improved assisted retransmission technique for cellular communications
KR20180047172A (ko) 서비스 별 네트워크 혼잡을 제어하는 방법 및 장치
KR20180016525A (ko) 자원 할당 방법, ue, 및 기지국
KR20110072478A (ko) 머신형 통신 서비스를 제공하는 방법 및 장치
CN112449425B (zh) 一种通信方法和装置
US11190974B2 (en) Device and method for controlling network congestion with RRC inactive
CN107306412B (zh) 用以实现消息可靠传输的方法、用户设备和基站
CN112602365B (zh) 一种数据传输方法、控制信息发送方法及设备
CN106900059A (zh) 下行信息的发送方法及装置
CN114079881B (zh) 一种通信方法及装置
CN105191460B (zh) 一种信息传输方法、设备及系统
RU2656248C2 (ru) Способ и устройство передачи сообщения, и устройство шлюза
WO2021233375A1 (en) Ip address allocation in a wireless communication network
EP4156843A1 (en) Communication method and device in wireless communication system supporting network slicing
WO2020125592A1 (zh) 通信方法、装置及系统
CN107682874A (zh) 一种进行业务传输的方法和设备
CN107231663B (zh) 一种资源配置的方法及设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15852469

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15852469

Country of ref document: EP

Kind code of ref document: A1