WO2018107635A1 - 网络故障处理方法及设备 - Google Patents

网络故障处理方法及设备 Download PDF

Info

Publication number
WO2018107635A1
WO2018107635A1 PCT/CN2017/081395 CN2017081395W WO2018107635A1 WO 2018107635 A1 WO2018107635 A1 WO 2018107635A1 CN 2017081395 W CN2017081395 W CN 2017081395W WO 2018107635 A1 WO2018107635 A1 WO 2018107635A1
Authority
WO
WIPO (PCT)
Prior art keywords
connection
data
terminal device
determining
downlink
Prior art date
Application number
PCT/CN2017/081395
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 华为技术有限公司
Priority to US16/469,322 priority Critical patent/US10986685B2/en
Priority to EP17881082.6A priority patent/EP3544366A1/en
Priority to CN201780009365.2A priority patent/CN108605257B/zh
Publication of WO2018107635A1 publication Critical patent/WO2018107635A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0681—Configuration of triggering conditions
    • 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
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition

Definitions

  • the embodiments of the present invention relate to the field of communications technologies, and in particular, to a network fault processing method and device.
  • the terminal device In the process of acquiring data services from the core network (for example, a mobile phone, a computer, etc.), the terminal device needs to communicate with the base station, and acquires data services from the core network through the base station.
  • the core network for example, a mobile phone, a computer, etc.
  • the terminal device can usually send uplink data, but the terminal device cannot receive the core network side.
  • the downlink data is sent, and the user cannot obtain normal data services through the terminal device.
  • the user usually needs to reopen the data switch of the terminal device according to personal experience, or turn on and off the flight mode of the terminal device, so that the terminal device can normally acquire the data service.
  • the user can obviously perceive the Internet access failure, and needs to rely on the user's personal experience to solve the network failure, resulting in poor user experience.
  • the present invention provides a network fault processing method and device, which can automatically detect and repair downlink data link faults, thereby improving user experience.
  • the present application provides a network fault processing method, where a network fault processing apparatus can obtain a first data amount of uplink data sent by a terminal device within a preset time period in real time or periodically, and the terminal device is within a preset time period.
  • the second data quantity of the received downlink packet data is analyzed, and the first data quantity and the second data quantity are analyzed.
  • the downlink of the terminal device may be determined. If the link fails, the RRC connection can be re-established and/or the Internet Protocol IP connection resources can be re-acquired to implement automatic repair of the downlink fault.
  • the downlink data link fault can be automatically detected, and when the downlink data link fault is detected, the downlink data link fault can be automatically repaired, so that the user does not perceive the network fault again. Improve the user experience without the need for manual repairs by users.
  • the data types of the uplink data include: a transmission control protocol TCP type, a domain name system DNS type, and a user datagram protocol UDP type.
  • the signal receiving quality of the terminal device may be determined to be greater than a preset quality threshold.
  • the reconstruction RRC can be implemented by using at least two feasible implementation manners as follows. Connect and/or regain IP connection resources:
  • the IP connection resource is re-acquired.
  • the RRC connection is re-established, and it is determined whether the downlink data link failure is repaired. If it is determined that the downlink data link failure is not repaired, the IP connection resource is re-acquired.
  • reestablishing the RRC connection includes:
  • re-acquiring IP connection resources including:
  • the terminal device can re-acquire the IP connection resource, and thus can determine that the terminal device and the core network can communicate normally.
  • the reconstructing the first PDN connection comprises:
  • the present application provides a network fault processing apparatus including a processor, a memory for storing program instructions, and a communication bus for implementing a connection between components, the processor being used for Read the program instructions in the memory and perform the following operations:
  • the data type of the uplink data includes: a transmission control protocol TCP type, a domain name system DNS type, and a user datagram protocol UDP type.
  • the processor before the processor reestablishes the RRC connection and/or reacquires the IP connection resource, the processor is further configured to:
  • the processor is specifically configured to:
  • the IP connection resource is re-acquired.
  • the processor is specifically configured to:
  • the RRC connection is re-established, and it is determined whether the downlink data link failure is repaired. If it is determined that the downlink data link failure is not repaired, the IP connection resource is re-acquired.
  • the processor is specifically configured to:
  • the processor is specifically configured to:
  • the processor is specifically configured to:
  • the application provides a network fault processing apparatus, including an acquiring module and a fault processing module, where
  • the acquiring module is configured to acquire a first data amount of uplink data that is sent by the terminal device within a preset duration
  • the acquiring module is further configured to: acquire a second data amount of downlink packet data that is received by the terminal device in the preset duration;
  • the fault processing module is configured to reestablish the radio resource control RRC connection and/or re-acquire the Internet Protocol IP connection resource when determining that the first data amount is greater than the first threshold and the second data amount is equal to zero.
  • the data type of the uplink data includes: a transmission control protocol TCP type, a domain name system DNS type, and a user datagram protocol UDP type.
  • the apparatus further includes a determining module, where
  • the determining module is configured to determine that the signal receiving quality of the terminal device is greater than a preset quality threshold before the fault processing module reestablishes the RRC connection and/or reacquires the IP connection resource.
  • the fault processing module is specifically configured to:
  • the IP connection resource is re-acquired.
  • the fault processing module is specifically configured to: determine whether the number of data units in the uplink buffer queue in the data link layer is less than a second threshold, and downlink buffering in the data link layer In the queue Whether the data unit is greater than a third threshold;
  • the RRC connection is re-established, and it is determined whether the downlink data link failure is repaired. If it is determined that the downlink data link failure is not repaired, the IP connection resource is re-acquired.
  • the fault processing module is specifically configured to: determine a base station to which the terminal device is currently connected;
  • the fault processing module is specifically configured to: determine a first PDN connection used when sending the uplink data;
  • the fault processing module is specifically configured to:
  • the network fault processing method and device provided by the present application obtain the first data amount of the uplink data sent by the terminal device in the preset duration, and acquire the second downlink data received by the terminal device within the preset duration
  • the amount of data when it is determined that the first data amount is greater than the first threshold, and the second data amount is equal to zero, may determine that a downlink data link failure occurs, and then reestablish the RRC connection and/or re-acquire the IP connection resource, and downlink
  • the data link fault is repaired.
  • the link between the terminal device and the base station can be ensured by reestablishing the IP connection resource by reestablishing the RRC connection. Therefore, the link between the terminal device and the core network can be ensured.
  • the downlink data link failure can be effectively repaired.
  • the downlink data link fault can be automatically detected, and when the downlink data link fault is detected, the downlink data link fault can be automatically repaired, so that the user does not perceive the network fault again. Improve the user experience without the need for manual repairs by users.
  • FIG. 1 is a schematic diagram of an application scenario of a network fault processing method provided by the present application
  • FIG. 2 is a schematic flowchart 1 of a network fault processing method provided by the present application.
  • FIG. 3 is a schematic flowchart of a method for reacquiring an IP connection resource provided by the present application
  • FIG. 4 is a schematic flowchart 2 of a network fault processing method provided by the present application.
  • FIG. 5 is a schematic structural diagram of a network fault processing device provided by the present application.
  • FIG. 6 is a schematic structural diagram 1 of a network fault processing apparatus provided by the present application.
  • FIG. 7 is a schematic structural diagram 2 of a network fault processing apparatus provided by the present application.
  • FIG. 1 is a schematic diagram of an application scenario of a network fault processing method provided by the present application. Please refer to Figure 1, including terminal settings.
  • the base station 102 and the core network 103, the terminal device 101 can normally send uplink data to the base station 102, and the terminal device 101 cannot receive the downlink packet data sent by the core network 103.
  • the terminal device may be a wireless terminal or a wired terminal, and the wireless terminal may be a device that provides voice and/or other service data connectivity to the user, a handheld device with wireless connectivity, or other processing device connected to the wireless modem.
  • the wireless terminal can communicate with one or more core networks via a Radio Access Network (RAN), which can be a mobile terminal, such as a mobile phone (or "cellular" phone) and a computer with a mobile terminal.
  • RAN Radio Access Network
  • it may be a portable, pocket, handheld, computer built-in or in-vehicle mobile device that exchanges language and/or data with a wireless access network.
  • the wireless terminal may also be referred to as a system, a subscriber unit, a subscriber station, a mobile station, a mobile station, a remote station, a remote terminal, and a remote terminal.
  • the access terminal, the user terminal (User Terminal), the user agent (User Agent), and the user device (User Device or User Equipment) are not limited herein.
  • the base station may be a Global System of Mobile communication (GSM) or a Base Transceiver Station (BTS) in Code Division Multiple Access (CDMA), or may be a Wideband Code Division Multiple Access (Wideband Code).
  • GSM Global System of Mobile communication
  • BTS Base Transceiver Station
  • CDMA Code Division Multiple Access
  • Wideband Code Wideband Code Division Multiple Access
  • the base station (NodeB, NB) in the Division Multiple Access (WCDMA) may be an evolved base station (Evolutional Node B, eNB or eNodeB) in the Long Term Evolution (LTE), and is not limited thereto.
  • LTE Long Term Evolution
  • FIG. 2 is a schematic flowchart 1 of a network fault processing method provided by the present application. Referring to FIG. 2, the method may include:
  • the executor of the technical solution provided by the present application may be a network fault processing device, and the network fault processing device is disposed in the terminal.
  • the network fault processing device may be implemented by software and/or hardware.
  • the preset duration may be a plurality of consecutive sampling periods.
  • the duration of one sampling period may be 4 seconds
  • the preset duration may be 4 consecutive sampling periods, that is, the preset duration may be 16 seconds.
  • the preset duration may be set according to actual needs, which is not specifically limited in this application.
  • the uplink data in this application is usually data related to the data service of the user, and the uplink data usually indicates the core network feedback response message.
  • the type of the uplink data may include a Transmission Control Protocol (TCP) type, a Domain Name System (DNS) type, and a User Datagram Protocol (UDP) type.
  • the uplink data may be ipv4 data or ipv6 data.
  • the first data volume may be the number of data packets that the terminal device sends uplink data within a preset duration.
  • the uplink data of the terminal device can be monitored and counted by the baseband processor modem of the terminal device.
  • the downlink packet data refers to downlink data sent by the core network to the terminal device.
  • the second amount of data may be the number of data packets of the downlink data that is received by the terminal device within a preset duration.
  • the downlink data link After determining the first data amount and the second data amount, determining whether the first data amount is greater than the first threshold and the second data amount is zero, and if yes, determining that the downlink data link is faulty. It should be noted that, when it is determined that the first data quantity is greater than the first threshold, and the second data quantity is less than the preset threshold, the downlink data link may be determined to be faulty. In actual application, the preset threshold value is generally compared. The first threshold and the preset threshold may be set according to actual needs, which is not specifically limited in this application.
  • the signal receiving quality of the terminal device may also be acquired, and whether the signal receiving quality is greater than a preset quality threshold, and if not, the possible The terminal device cannot receive the downlink packet data because the signal receiving quality of the terminal device is too poor. At this time, it cannot be determined that the downlink data link is faulty.
  • the terminal device may send a Connection Reestablishment Request (CRC) message to the base station to request to reestablish an RRC connection with the base station.
  • CRC Connection Reestablishment Request
  • the terminal device can determine whether the downlink data link failure is repaired. If yes, the process ends. If not, the IP connection resource is re-acquired.
  • it can be determined whether the downlink packet data can be received. If yes, the downlink data link is repaired; otherwise, the downlink data link is not repaired.
  • the IP connection resource may be re-acquired by re-establishing a PDN connection between the terminal device and the core network, or triggering a Tracking Area Update (TAU) TAU process.
  • TAU Tracking Area Update
  • IP connection resources for re-acquiring IP connection resources, refer to 3GPP TS 24.301 V14.3.0 (2017-03) section 6.1.1 "the request for resources (IP connectivity to a PDN or dedicated bearer resources) by the UE.”
  • the process of re-acquiring the IP connection resource may be implemented by one or more of the methods of establishing a PDN connection, disconnecting the PDN connection, allocating the bearer resource, and modifying the bearer resource, where the PDN connection is established, the PDN connection is disconnected,
  • allocating bearer resources and modifying bearer resources refer to 3GPP TS 24.301 V14.3.0 (2017-03), which is not described here.
  • the base station By reestablishing the RRC connection between the terminal device and the base station, the base station can re-allocate the resource to the terminal device, and the data that the base station cannot deliver the core network due to the abnormality of the resource allocated by the base station to the terminal device (for example, insufficient) can be solved. Issues sent to the terminal device.
  • the core network By reacquiring the IP connection resources, the core network can re-allocate resources to the terminal device, thereby solving the problem that the core network cannot send data to the terminal device through the base station due to the abnormal resource allocated by the core network for the terminal device.
  • the technical solution shown in this application may also be executed during the process in which the user is using the terminal device, for example, the mobile phone is in a bright screen state.
  • the network fault processing method provided by the application obtains the uplink data sent by the terminal device within a preset duration Obtaining, by a data quantity, a second data quantity of the downlink packet data received by the terminal device within the preset duration, when determining that the first data amount is greater than a first threshold, and the second data amount is equal to zero, It can be determined that a downlink data link failure occurs, and the downlink data link failure is repaired by reestablishing the RRC connection and/or re-acquiring the IP connection resource, wherein the link between the terminal device and the base station can be ensured by reestablishing the RRC connection. Normally, by reacquiring the IP connection resources, the link between the terminal device and the core network can be ensured.
  • the downlink data link failure can be effectively repaired by the above method.
  • the downlink data link fault can be automatically detected, and when the downlink data link fault is detected, the downlink data link fault can be automatically repaired, so that the user does not perceive the network fault again. Improve the user experience without the need for manual repairs by users.
  • the IP connection resource may be re-acquired through the following possible implementation manners. For details, refer to the embodiment shown in FIG. 3.
  • FIG. 3 is a schematic flowchart of a method for reacquiring IP connection resources provided by the present application. Referring to FIG. 3, the method may include:
  • the PDN connection used by the core network to send downlink data is the same as the PDN connection used for the uplink data corresponding to the downlink data. For example, if the core network receives the uplink data sent by the terminal device through the PDN1, when the core network needs to send the downlink data corresponding to the uplink data to the terminal device, the core network sends the downlink data to the terminal device through the PDN1.
  • the PDN connection currently exists in the terminal device is configured in the terminal device, and the number of PDN connections currently existing in the terminal device may be one or multiple.
  • the first PDN may be directly reconnected.
  • the first PDN connection may be directly disconnected and reconstructed.
  • the process of establishing a PDN connection may refer to section 6.5.1 of 3GPP 24301.
  • the process of disconnecting the PDN connection may refer to section 6.5.2 of 3GPP 24301, and details are not described herein again.
  • the operator corresponding to the terminal device refers to an operator that currently provides a network server for the terminal device.
  • S305 Determine a core network corresponding to the uplink data, and establish an alternate PDN connection with the core network.
  • the terminal device may obtain a parameter corresponding to the standby PDN connection (such as an Access Point Name (APN) parameter) from the operator, and establish a backup with the core network according to the parameter corresponding to the standby PDN connection.
  • PDN connection such as an Access Point Name (APN) parameter
  • the terminal device may send a TAU Request message to the core network, so that the core network updates the terminal device.
  • Tracking Area (TA) parameters may be used to determine the location of the terminal device.
  • the PDN between the terminal device and the core network is reconnected or the TAU process is triggered according to the PDN connection situation of the terminal device, so as to re-acquire the IP connection resource.
  • FIG. 4 is a schematic flowchart 2 of a network fault processing method provided by the present application. Referring to FIG. 4, the method may include:
  • the sampling period can be 4 seconds.
  • the sampling period can be set according to actual needs.
  • the terminal device When it is determined whether the signal receiving quality of the terminal device is less than or equal to the preset quality threshold, it may be that the terminal device cannot receive the downlink packet data because the signal receiving quality of the terminal device is too poor, and therefore, the downlink data link failure cannot be determined. Then the process ends.
  • the base station may send the feedback information to the terminal device normally.
  • the terminal device may be timely.
  • the uplink data to be sent is sent to the base station by using the data link layer. Therefore, when it is determined that the number of the RLC DRB uplink buffer queue AM PDU is less than the second threshold, and the number of the downlink AM ACK PDUs of the RLC DRB is greater than the third threshold, It is determined that the RRC link between the terminal device and the base station is normal, otherwise, the RRC link failure between the terminal device and the base station is indicated.
  • S406. Determine a base station to which the terminal device is currently connected, and reestablish an RRC connection with the base station.
  • the network fault processing device can automatically detect the downlink data link failure, and when the downlink data link fault is detected, the downlink data link fault can be automatically repaired, so that the user does not The network will be perceived to be faulty and the user will not need to manually repair it to improve the user experience.
  • FIG. 5 is a schematic structural diagram of a network fault processing device provided by the present application.
  • the network fault processing device may be disposed in the terminal device.
  • the device may include a processor 11, a memory 12, and a communication bus 13 for storing program instructions, the communication bus. 13 is used to implement the connection between the components, the processor 11 is used to read the program instructions in the memory, and perform the following operations:
  • the network fault processing device provided by the present application may perform the technical solutions shown in the foregoing method embodiments, and the implementation principles and beneficial effects thereof are similar, and details are not described herein.
  • the data type of the uplink data includes: a transmission control protocol TCP type, a domain name system DNS type, and a user datagram protocol UDP type.
  • the processor 11 before the processor 11 reestablishes the RRC connection and/or reacquires the IP connection resource, the processor 11 is further configured to:
  • the processor 11 is specifically configured to:
  • the IP connection resource is re-acquired.
  • the processor 11 is specifically configured to:
  • the RRC connection is re-established, and it is determined whether the downlink data link failure is repaired. If it is determined that the downlink data link failure is not repaired, the IP connection resource is re-acquired.
  • the processor 11 is specifically configured to:
  • the processor 11 is specifically configured to:
  • the processor 11 is specifically configured to:
  • the network fault processing device provided by the present application may perform the technical solutions shown in the foregoing method embodiments, and the implementation principles and beneficial effects thereof are similar, and details are not described herein.
  • FIG. 6 is a schematic structural diagram 1 of a network fault processing apparatus provided by the present application.
  • the network fault processing device may be disposed in the terminal device.
  • the device may include an obtaining module 21 and a fault processing module 22, where
  • the acquiring module 21 is configured to acquire a first data amount of uplink data that is sent by the terminal device within a preset duration
  • the acquiring module 21 is further configured to: acquire a second data amount of the downlink packet data that is received by the terminal device in the preset duration;
  • the fault processing module 22 is configured to reestablish the radio resource control RRC connection and/or re-acquire the Internet Protocol IP connection resource when determining that the first data amount is greater than the first threshold and the second data amount is equal to zero.
  • the network fault processing apparatus provided by the present application may perform the technical solutions shown in the foregoing method embodiments, and the implementation principles and beneficial effects thereof are similar, and details are not described herein.
  • the data type of the uplink data includes: a transmission control protocol TCP type, a domain name system DNS type, and a user datagram protocol UDP type.
  • FIG. 7 is a schematic structural diagram 2 of a network fault processing apparatus provided by the present application.
  • the device On the basis of the embodiment shown in FIG. 6, referring to FIG. 7, the device further includes a determining module 23, wherein
  • the determining module 23 is configured to determine that the signal receiving quality of the terminal device is greater than a preset quality threshold before the fault processing module 22 reestablishes the RRC connection and/or reacquires the IP connection resource.
  • the fault processing module 22 is specifically configured to:
  • the IP connection resource is re-acquired.
  • the fault processing module 22 is specifically configured to: determine whether the number of data units in the uplink buffer queue in the data link layer is less than a second threshold, and downlink in the data link layer Whether the data unit in the buffer queue is greater than a third threshold;
  • the RRC connection is re-established, and it is determined whether the downlink data link failure is repaired. If it is determined that the downlink data link failure is not repaired, the IP connection resource is re-acquired.
  • the fault processing module 22 is specifically configured to: determine a base station to which the terminal device is currently connected;
  • the fault processing module 22 is specifically configured to:
  • the fault processing module 22 is specifically configured to:
  • the network fault processing apparatus provided by the present application may perform the technical solutions shown in the foregoing method embodiments, and the implementation principles and beneficial effects thereof are similar, and details are not described herein.
  • the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed.
  • the foregoing steps include the steps of the foregoing method embodiments; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

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

Abstract

本申请提供一种网络故障处理方法及设备，该方法包括：获取终端设备在预设时长内发送的上行数据的第一数据量；获取终端设备在预设时长内接收到的下行分组数据的第二数据量；确定第一数据量大于第一阈值、第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。实现了自动对下行数据链路故障进行检测及修复，进而提高用户使用体验。

Description

网络故障处理方法及设备
本申请要求于2016年12月14日提交中国专利局、申请号为201611155224.5、发明名称为“一种LTE分组数据故障诊断修复的方法和设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明实施例涉及通信技术领域，尤其涉及一种网络故障处理方法及设备。
背景技术
终端设备(例如，手机、电脑等)从核心网获取数据业务的过程中，终端设备需要与基站进行通信，并通过基站从核心网中获取数据服务。
在实际应用过程中，当出现下行数据链路故障时，例如，核心网出现下行路由故障、计费鉴权系统故障等时，终端设备通常可以发送上行数据，但终端设备无法接收到核心网侧发送的下行数据，导致用户无法通过终端设备获取正常的数据业务。该种情况下，用户通常需要根据个人经验重开终端设备的数据开关、或者开启并关闭终端设备的飞行模式等，以实现终端设备可以正常获取数据业务。
然而，在上述过程中，用户可以明显感知到上网故障，并需要依赖用户的个人经验解决网络故障，导致用户体验差。
发明内容
本申请提供一种网络故障处理方法及设备，可以实现自动对下行数据链路故障进行检测及修复，进而提高用户使用体验。
第一方面，本申请提供一种网络故障处理方法，网络故障处理装置可以实时或周期性的获取终端设备在预设时长内发送的上行数据的第一数据量、及终端设备在预设时长内接收到的下行分组数据的第二数据量，并对第一数据量和第二数据量进行分析，当判断第一数据量大于第一阈值、第二数据量等于零时，可以确定终端设备的下行链路出现故障，则可以重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源，以实现修复自动修复下行链路故障。
在上述过程中，可以自动对下行数据链路故障进行检测，且在检测到下行数据链路故障时，可以自动对下行数据链路故障进行修复，使得用户不会再感知到网络出现故障，也无需用户手动进行修复，进而提高用户体验。
可选的，上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
在一种可能的实施方式中，在重建RRC连接和/或重新获取IP连接资源之前，还可以先确定终端设备的信号接收质量大于预设质量门限。
在另一种可能的实施方式中，可以通过至少如下两种可行的实现方式实现重建RRC 连接和/或重新获取IP连接资源：
一种可行的实现方式：
重建RRC连接，并判断下行数据链路故障是否被修复；
若判断下行数据链路故障未被修复，则重新获取IP连接资源。
另一种可行的实现方式：
判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且数据链路层中下行缓冲队列中的数据单元是否大于第三阈值；
若是，则重新获取IP连接资源；
若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，重建RRC连接，包括：
确定终端设备当前连接的基站；
重建与基站之间的RRC连接。
通过重建终端设备和基站之间的RRC连接，可以确定终端设备和基站之间可以正常通信。
在另一种可能的实施方式中，重新获取IP连接资源，包括：
确定发送上行数据时使用的第一PDN连接；
判断终端设备当前存在的公共数据网络PDN连接数量是否大于1；
若是，断开、重建第一PDN连接；
若否，则判断终端设备对应的运营商是否支持多PDN连接，若是，则重建第一PDN连接，若否，则触发跟踪区更新TAU流程。
通过重连第一PDN连接或者触发TAU流程可以使得终端设备重新获取IP连接资源，进而可以确定终端设备和核心网之间可以正常通信。
在另一种可能的实施方式中，重建第一PDN连接，包括：
确定上行数据对应的核心网，并建立与核心网之间的备用PDN连接；
断开、重建第一PDN连接；
断开备用PDN连接。
第二方面，本申请提供网络故障处理设备，包括处理器、存储器及通信总线，所述存储器用于存储程序指令，所述通信总线用于实现各元器件之间的连接，所述处理器用于读取所述存储器中的程序指令，并执行如下操作：
获取终端设备在预设时长内发送的上行数据的第一数据量；
获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量；
确定所述第一数据量大于第一阈值、所述第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。
在一种可能的实施方式中，所述上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
在另一种可能的实施方式中，在所述处理器重建RRC连接和/或重新获取IP连接资源前，所述处理器还用于：
确定所述终端设备的信号接收质量大于预设质量门限。
在另一种可能的实施方式中，所述处理器具体用于：
重建RRC连接，并判断下行数据链路故障是否被修复；
若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述处理器具体用于：
判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且所述数据链路层中下行缓冲队列中的数据单元是否大于第三阈值；
若是，则重新获取IP连接资源；
若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述处理器具体用于：
确定所述终端设备当前连接的基站；
重建与所述基站之间的RRC连接。
在另一种可能的实施方式中，所述处理器具体用于：
确定发送所述上行数据时使用的第一PDN连接；
判断所述终端设备当前存在的公共数据网络PDN连接数量是否大于1；
若是，断开、重建所述第一PDN连接；
若否，则判断所述终端设备对应的运营商是否支持多PDN连接，若是，则重建所述第一PDN连接，若否，则触发跟踪区更新TAU流程。
在另一种可能的实施方式中，所述处理器具体用于：
确定所述上行数据对应的核心网，并建立与所述核心网之间的备用PDN连接；
断开、重建所述第一PDN连接；
断开所述备用PDN连接。
第三方面，本申请提供一种网络故障处理装置，包括获取模块和故障处理模块，其中，
所述获取模块用于，获取终端设备在预设时长内发送的上行数据的第一数据量；
所述获取模块还用于，获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量；
所述故障处理模块用于，在确定所述第一数据量大于第一阈值、所述第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。
在一种可能的实施方式中，所述上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
在另一种可能的实施方式中，所述装置还包括确定模块，其中，
所述确定模块用于，在所述故障处理模块重建RRC连接和/或重新获取IP连接资源前，确定所述终端设备的信号接收质量大于预设质量门限。
在另一种可能的实施方式中，所述故障处理模块具体用于：
重建RRC连接，并判断下行数据链路故障是否被修复；
若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述故障处理模块具体用于：判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且所述数据链路层中下行缓冲队列中 的数据单元是否大于第三阈值；
若是，则重新获取IP连接资源；
若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述故障处理模块具体用于：确定所述终端设备当前连接的基站；
重建与所述基站之间的RRC连接。
在另一种可能的实施方式中，所述故障处理模块具体用于：确定发送所述上行数据时使用的第一PDN连接；
判断所述终端设备当前存在的公共数据网络PDN连接数量是否大于1；
若是，断开、重建所述第一PDN连接；
若否，则判断所述终端设备对应的运营商是否支持多PDN连接，若是，则重建所述第一PDN连接，若否，则触发跟踪区更新TAU流程。
在另一种可能的实施方式中，所述故障处理模块具体用于：
确定所述上行数据对应的核心网，并建立与所述核心网之间的备用PDN连接；
断开、重建所述第一PDN连接；
断开所述备用PDN连接。
本申请提供的网络故障处理方法及设备，获取终端设备在预设时长内发送的上行数据的第一数据量，获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量，在确定所述第一数据量大于第一阈值、所述第二数据量等于零时，可以确定出现下行数据链路故障，则通过重建RRC连接和/或重新获取IP连接资源，对下行数据链路故障进行修复，其中，通过重建RRC连接，可以确保终端设备与基站之间的链路正常，通过重新获取IP连接资源，可以确保终端设备与核心网之间的链路正常，因此，通过上述方式可以有效的修复下行数据链路故障。在上述过程中，可以自动对下行数据链路故障进行检测，且在检测到下行数据链路故障时，可以自动对下行数据链路故障进行修复，使得用户不会再感知到网络出现故障，也无需用户手动进行修复，进而提高用户体验。
附图说明
图1为本申请提供的网络故障处理方法的应用场景示意图；
图2为本申请提供的网络故障处理方法的流程示意图一；
图3为本申请提供的重新获取IP连接资源方法的流程示意图；
图4为本申请提供的网络故障处理方法的流程示意图二；
图5为本申请提供的网络故障处理设备的结构示意图；
图6为本申请提供的网络故障处理装置的结构示意图一；
图7为本申请提供的网络故障处理装置的结构示意图二。
具体实施方式
图1为本申请提供的网络故障处理方法的应用场景示意图。请参见图1，包括终端设 备101、基站102和核心网103，终端设备101可以正常向基站102发送上行数据，终端设备101无法接收到核心网103发送的下行分组数据。
终端设备可以是无线终端也可以是有线终端，无线终端可以是指向用户提供语音和/或其他业务数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。无线终端可以经无线接入网(Radio Access Network，RAN)与一个或多个核心网进行通信，无线终端可以是移动终端，如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。例如，个人通信业务(Personal Communication Service，PCS)电话、无绳电话、会话发起协议(Session Initiation Protocol，SIP)话机、无线本地环路(Wireless Local Loop，WLL)站、个人数字助理(Personal Digital Assistant，PDA)等设备。无线终端也可以称为系统、订户单元(Subscriber Unit)、订户站(Subscriber Station)，移动站(Mobile Station)、移动台(Mobile)、远程站(Remote Station)、远程终端(Remote Terminal)、接入终端(Access Terminal)、用户终端(User Terminal)、用户代理(User Agent)、用户设备(User Device or User Equipment)，在此不作限定。
基站可以是全球移动通讯(Global System of Mobile communication，GSM)或码分多址(Code Division Multiple Access，CDMA)中的基站(Base Transceiver Station，BTS)，也可以是宽带码分多址(Wideband Code Division Multiple Access，WCDMA)中的基站(NodeB，NB)，还可以是长期演进(Long Term Evolution，LTE)中的演进型基站(Evolutional Node B，eNB或eNodeB)等，在此并不限定。
下面，通过具体实施例，对本申请所示的技术方案进行详细说明。需要说明的是，下面几个具体实施例可以相互结合，对于相同或相似的内容，在不同的实施例中不再进行重复说明。
图2为本申请提供的网络故障处理方法的流程示意图一。请参见图2，该方法可以包括：
S201、获取终端设备在预设时长内发送的上行数据的第一数据量。
本申请提供的技术方案的执行主体可以为网络故障处理装置，该网络故障处理装置设置在终端中，可选的，该网络故障处理装置可以通过软件和/或硬件实现。
可选的，预设时长可以为连续的多个采样周期，例如，一个采样周期的时长可以为4秒，预设时长可以为4个连续的采样周期，即，预设时长可以为16秒。当然，在实际应用过程中，可以根据实际需要设置该预设时长，本申请对此不作具体限定。
本申请中的上行数据通常为与用户的数据业务相关的数据、且上行数据通常会指示核心网反馈响应消息。可选的，上行数据的类型可以包括传输控制协议(Transmission Control Protocol，TCP)类型、域名系统(Domain Name System，DNS)类型和用户数据报协议(User Datagram Protocol，UDP)类型。可选的，上行数据可以为ipv4数据，也可以为ipv6数据。
可选的，第一数据量可以为终端设备在预设时长内发送上行数据的数据包个数。
可选的，可以通过终端设备的基带处理器modem监测、并统计终端设备的上行数据。
S202、获取终端设备在预设时长内接收到的下行分组数据的第二数据量。
在本申请中，下行分组数据是指由核心网发送给终端设备的下行数据。
可选的，第二数据量可以为终端设备在预设时长内接收到的下行数据的数据包个数。
S203、确定第一数据量大于第一阈值、第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取IP连接资源。
在确定得到第一数据量和第二数据量之后，判断第一数据量是否大于第一阈值、且第二数据量是否为零，若是，则可以确定下行数据链路出现故障。需要说明的是，在确定第一数据量大于第一阈值、第二数据量小于预设阈值时，也可以确定下行数据链路出现故障，在实际应用过程中，预设阈值的取值通常较小，可以根据实际需要设置该第一阈值和预设阈值，本申请对此不作具体限定。
可选的，在确定第一数据量大于第一阈值、第二数据量等于零之后，还可以获取终端设备的信号接收质量，并判断信号接收质量是否大于预设质量门限，若否，则说明可能是由于终端设备的信号接收质量太差而导致终端设备无法接收到下行分组数据，此时，则无法确定是下行数据链路出现故障。
在确定下行数据链路出现故障之后，可选的，终端设备可以向基站发送(Connection Reestablishment Request，CRC)消息，以请求重建与基站之间的RRC连接。在终端设备与基站之间的RRC连接重建之后，终端设备可以判断下行数据链路故障是否被修复，若是，则流程结束，若否，则重新获取IP连接资源。可选的，可以判断是否能接收到下行分组数据，若能，则说明下行数据链路被修复，否则，则说明下行数据链路未被修复。可选的，可以通过重建终端设备与核心网之间的PDN连接、或者触发跟踪区更新(Tracking Area Update，TAU)TAU流程实现重新获取IP连接资源，具体的，在图3所示的实施例中对重新获取IP连接资源进行详细说明，此处在进行说明。
可选的，重新获取IP连接资源可以参考3GPP TS 24.301 V14.3.0(2017-03)6.1.1节"the request for resources(IP connectivity to a PDN or dedicated bearer resources)by the UE."，可选的，重新获取IP连接资源的过程可以通过建立PDN连接、断开PDN连接、分配承载资源、修改承载资源等方式中的一种或多种方式实现，其中，建立PDN连接、断开PDN连接、分配承载资源、修改承载资源的实现过程可以参考3GPP TS 24.301 V14.3.0(2017-03)，本申请此处不再进行赘述。
重建RRC连接可以参考3GPP TS 36.331 version 9.2.0 Release 9的章节5.3.7 RRC connection re-establishment，此处不再进行赘述。
通过重建终端设备和基站之间的RRC连接，可以使得基站重新向终端设备分配资源，进而可以解决由于基站为终端设备分配的资源异常(例如不足等)而导致基站无法将核心网下发的数据发送至终端设备的问题。通过重新获取IP连接资源，可以使得核心网重新向终端设备分配资源，进而解决由于核心网为终端设备分配的资源异常而导致核心网无法将数据通过基站发送至终端设备的问题。
需要说明的是，在实际应用过程中，还可以在用户正在使用终端设备的过程中(例如手机为亮屏状态)，执行本申请所示的技术方案。
本申请提供的网络故障处理方法，获取终端设备在预设时长内发送的上行数据的第 一数据量，获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量，在确定所述第一数据量大于第一阈值、所述第二数据量等于零时，可以确定出现下行数据链路故障，则通过重建RRC连接和/或重新获取IP连接资源，对下行数据链路故障进行修复，其中，通过重建RRC连接，可以确保终端设备与基站之间的链路正常，通过重新获取IP连接资源，可以确保终端设备与核心网之间的链路正常，因此，通过上述方式可以有效的修复下行数据链路故障。在上述过程中，可以自动对下行数据链路故障进行检测，且在检测到下行数据链路故障时，可以自动对下行数据链路故障进行修复，使得用户不会再感知到网络出现故障，也无需用户手动进行修复，进而提高用户体验。
在图2所示实施例的基础上，可选的，可以通过如下可行的实现方式重新获取IP连接资源，具体的，请参见图3所示的实施例。
图3为本申请提供的重新获取IP连接资源方法的流程示意图。请参见图3，该方法可以包括：
S301、确定发送上行数据时使用的第一PDN连接。
在实际应用过程中，核心网发送下行数据所使用的PDN连接，与该下行数据对应的上行数据所使用的PDN连接相同。例如，若核心网通过PDN1接收到终端设备发送的上行数据，当核心网需要向终端设备发送上行数据对应的下行数据时，核心网通过PDN1向终端设备发送下行数据。
S302、判断终端设备当前存在的PDN连接数量是否大于1。
若是，则执行S303。
若否，则执行S304-S306。
在实际应用过程中，终端设备中配置有该终端设备当前存在的PDN连接，终端设备当前存在的PDN连接数量可以为1个，也可以为多个。
S303、断开、重建第一PDN连接。
若终端设备当前存在的PDN数量大于1，则可以直接对第一PDN进行重连，可选的，可以直接断开、重建第一PDN连接。
可选的，建立PDN连接的过程可以参考3GPP 24301 6.5.1章节，断开PDN连接的过程可以参考3GPP 24301 6.5.2章节，此处不再进行赘述。
S304、判断终端设备对应的运营商是否支持多PDN连接。
若是，则执行S305-S307。
若否，则执行S308。
可选的，终端设备对应的运营商是指当前为终端设备提供网络服务器的运营商。
S305、确定上行数据对应的核心网，并建立与核心网之间的备用PDN连接；
可选的，终端设备可以从运营商处获取备用PDN连接对应的参数(例如接入点(Access Point Name，APN)参数)，并根据备用PDN连接对应的参数，建立与核心网之间的备用PDN连接。
S306、断开、重建第一PDN连接；
S307、断开备用PDN连接。
S308、触发TAU流程。
可选的，终端设备可以向核心网发送TAU Request消息，以使核心网更新终端设备 的跟踪区(Treaking Area，TA)参数。
在上述过程中，根据终端设备的PDN连接情况，对终端设备和核心网之间的PDN进行重连或者触发TAU流程，以实现重新获取IP连接资源。
在上述任意一个实施例的基础上，下面，结合图4，通过具体示例，对上述方法实施例所示的技术方案进行详细说明。
图4为本申请提供的网络故障处理方法的流程示意图二。请参见图4，该方法可以包括：
S401、通过终端设备的modem，获取终端设备在连续4个采样周期发送的TCP/DNS/UDP数据的第一数据包个数。
例如，采样周期可以为4秒，当然，可以根据实际需要设置该采样周期。
S402、通过终端设备的modem，获取终端设备在该连续4个采样周期接收到的下行分组数据的第二数据包个数。
S403、判断第一数据包个数是否大于第一阈值、且第二数据包个数为零。
若是，则执行S404。
若否，则执行S416。
在确定第一数据包个数下于第一阈值、或者第二数据包个数大于零时，则无法确定存在下行数据链路故障，则流程结束。
S404、判断终端设备的信号接收质量是否大于预设质量门限。
若是，则执行S405。
若否，则执行S416。
在确定终端设备的信号接收质量是否小于或等于预设质量门限时，说明可能由于终端设备的信号接收质量太差导致终端设备无法接收到下行分组数据，因此，无法确定存在下行数据链路故障，则流程结束。
S405、判断无线链路控制(Radio Link Control，RLC)数据无线承载(Data Radio Bearer，DRB)上行缓冲队列中确认模式协议数据单元(Acknowledgement Mode Protocol Data Unit，AM PDU)的数量是否小于第二阈值、且RLC DRB的下行确认模式应答协议数据单元(Acknowledgement Mode Acknowledgement Protocol Data Unit，AM ACK PDU)的数量大于第三阈值。
若是，则执行S408。
若否，则执行S406。
在确定RLC DRB的下行AM ACK PDU的数量大于第三阈值时，说明基站可以正常向终端设备发送反馈信息，在确定RLC DRB上行缓冲队列AM PDU的数量小于第二阈值时，说明终端设备可以及时通过数据链路层将需要发送的上行数据发送至基站，因此，当确定RLC DRB上行缓冲队列AM PDU的数量小于第二阈值、且RLC DRB的下行AM ACK PDU的数量大于第三阈值时，可以确定终端设备和基站之间RRC链路正常，否则，说明终端设备和基站之间的RRC链路故障。
S406、确定终端设备当前连接的基站，并重建与该基站之间的RRC连接。
S407、判断下行数据链路故障是否被修复。
若是，则执行S416。
若否，则执行S408。
S408、确定发送上行数据时使用的第一PDN连接。
需要说明的是，S408的执行过程可以参见S302，此处不再进行赘述。
S409、判断终端设备当前存在的PDN连接数量是否大于1。
若是，则执行S410。
若否，则执行S411。
S410、断开、重建第一PDN连接。
需要说明的是，S410的执行过程可以参见S303，此处不再进行赘述。
S411、判断终端设备对应的运营商是否支持多PDN连接。
若是，则执行S412-S414。
若否，则执行S415。
S412、确定上行数据对应的核心网，并建立与核心网之间的备用PDN连接。
S413、断开、重建第一PDN连接；
S414、断开备用PDN连接。
需要说明的是，S412-S414的执行过程可以参见S305-S307，此处不再进行赘述。
S415、触发TAU流程。
需要说明的是，S415的执行过程可以参见S308，此处不再进行赘述。
S416、流程结束。
在图4所示的实施例中，网络故障处理装置可以自动对下行数据链路故障进行检测，且在检测到下行数据链路故障时，可以自动对下行数据链路故障进行修复，使得用户不会再感知到网络出现故障，也无需用户手动进行修复，进而提高用户体验。
图5为本申请提供的网络故障处理设备的结构示意图。可选的，该网络故障处理设备可以设置在终端设备中，请参见图5，该设备可以包括处理器11、存储器12及通信总线13，所述存储器12用于存储程序指令，所述通信总线13用于实现各元器件之间的连接，所述处理器11用于读取所述存储器中的程序指令，并执行如下操作：
获取终端设备在预设时长内发送的上行数据的第一数据量；
获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量；
确定所述第一数据量大于第一阈值、所述第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。
本申请提供的网络故障处理设备可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
在一种可能的实施方式中，所述上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
在另一种可能的实施方式中，在所述处理器11重建RRC连接和/或重新获取IP连接资源前，所述处理器11还用于：
确定所述终端设备的信号接收质量大于预设质量门限。
在另一种可能的实施方式中，所述处理器11具体用于：
重建RRC连接，并判断下行数据链路故障是否被修复；
若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述处理器11具体用于：
判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且所述数据链路层中下行缓冲队列中的数据单元是否大于第三阈值；
若是，则重新获取IP连接资源；
若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述处理器11具体用于：
确定所述终端设备当前连接的基站；
重建与所述基站之间的RRC连接。
在另一种可能的实施方式中，所述处理器11具体用于：
确定发送所述上行数据时使用的第一PDN连接；
判断所述终端设备当前存在的公共数据网络PDN连接数量是否大于1；
若是，断开、重建所述第一PDN连接；
若否，则判断所述终端设备对应的运营商是否支持多PDN连接，若是，则重建所述第一PDN连接，若否，则触发跟踪区更新TAU流程。
在另一种可能的实施方式中，所述处理器11具体用于：
确定所述上行数据对应的核心网，并建立与所述核心网之间的备用PDN连接；
断开、重建所述第一PDN连接；
断开所述备用PDN连接。
本申请提供的网络故障处理设备可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
图6为本申请提供的网络故障处理装置的结构示意图一。可选的，该网络故障处理装置可以设置在终端设备中，请参见图6，该装置可以包括获取模块21和故障处理模块22，其中，
所述获取模块21用于，获取终端设备在预设时长内发送的上行数据的第一数据量；
所述获取模块21还用于，获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量；
所述故障处理模块22用于，在确定所述第一数据量大于第一阈值、所述第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。
本申请提供的网络故障处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
在另一种可能的实施方式中，所述上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
图7为本申请提供的网络故障处理装置的结构示意图二。在图6所示实施例的基础上，请参见图7，所述装置还包括确定模块23，其中，
所述确定模块23用于，在所述故障处理模块22重建RRC连接和/或重新获取IP连接资源前，确定所述终端设备的信号接收质量大于预设质量门限。
在另一种可能的实施方式中，所述故障处理模块22具体用于：
重建RRC连接，并判断下行数据链路故障是否被修复；
若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述故障处理模块22具体用于：判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且所述数据链路层中下行缓冲队列中的数据单元是否大于第三阈值；
若是，则重新获取IP连接资源；
若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
在另一种可能的实施方式中，所述故障处理模块22具体用于：确定所述终端设备当前连接的基站；
重建与所述基站之间的RRC连接。
在另一种可能的实施方式中，所述故障处理模块22具体用于：
确定发送所述上行数据时使用的第一PDN连接；
判断所述终端设备当前存在的公共数据网络PDN连接数量是否大于1；
若是，断开、重建所述第一PDN连接；
若否，则判断所述终端设备对应的运营商是否支持多PDN连接，若是，则重建所述第一PDN连接，若否，则触发跟踪区更新TAU流程。
在另一种可能的实施方式中，所述故障处理模块22具体用于：
确定所述上行数据对应的核心网，并建立与所述核心网之间的备用PDN连接；
断开、重建所述第一PDN连接；
断开所述备用PDN连接。
本申请提供的网络故障处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (16)

  1. 一种网络故障处理方法，其特征在于，包括：
    获取终端设备在预设时长内发送的上行数据的第一数据量；
    获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量；
    确定所述第一数据量大于第一阈值、所述第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。
  2. 根据权利要求1所述的方法，其特征在于，所述上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
  3. 根据权利要求1或2所述的方法，其特征在于，重建RRC连接和/或重新获取IP连接资源前，还包括：
    确定所述终端设备的信号接收质量大于预设质量门限。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，重建RRC连接和/或重新获取IP连接资源，包括：
    重建RRC连接，并判断下行数据链路故障是否被修复；
    若判断下行数据链路故障未被修复，则重新获取IP连接资源。
  5. 根据权利要求1-3任一项所述的方法，其特征在于，重建RRC连接和/或重新获取IP连接资源，包括：
    判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且所述数据链路层中下行缓冲队列中的数据单元是否大于第三阈值；
    若是，则重新获取IP连接资源；
    若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，重建RRC连接，包括：
    确定所述终端设备当前连接的基站；
    重建与所述基站之间的RRC连接。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，重新获取IP连接资源，包括：
    确定发送所述上行数据时使用的第一PDN连接；
    判断所述终端设备当前存在的公共数据网络PDN连接数量是否大于1；
    若是，断开、重建所述第一PDN连接；
    若否，则判断所述终端设备对应的运营商是否支持多PDN连接，若是，则重建所述第一PDN连接，若否，则触发跟踪区更新TAU流程。
  8. 根据权利要求7所述的方法，其特征在于，重建所述第一PDN连接，包括：
    确定所述上行数据对应的核心网，并建立与所述核心网之间的备用PDN连接；
    断开、重建所述第一PDN连接；
    断开所述备用PDN连接。
  9. 一种网络故障处理设备，其特征在于，包括处理器、存储器及通信总线，所述存储器用于存储程序指令，所述通信总线用于实现各元器件之间的连接，所述处理器用于 读取所述存储器中的程序指令，并执行如下操作：
    获取终端设备在预设时长内发送的上行数据的第一数据量；
    获取所述终端设备在所述预设时长内接收到的下行分组数据的第二数据量；
    确定所述第一数据量大于第一阈值、所述第二数据量等于零时，重建无线资源控制RRC连接和/或重新获取互联网协议IP连接资源。
  10. 根据权利要求9所述的设备，其特征在于，所述上行数据的数据类型包括：传输控制协议TCP类型、域名系统DNS类型和用户数据报协议UDP类型。
  11. 根据权利要求9或10所述的设备，其特征在于，在所述处理器重建RRC连接和/或重新获取IP连接资源前，所述处理器还用于：
    确定所述终端设备的信号接收质量大于预设质量门限。
  12. 根据权利要求9-11任一项所述的设备，其特征在于，所述处理器具体用于：
    重建RRC连接，并判断下行数据链路故障是否被修复；
    若判断下行数据链路故障未被修复，则重新获取IP连接资源。
  13. 根据权利要求9-11任一项所述的设备，其特征在于，所述处理器具体用于：
    判断数据链路层中上行缓冲队列中的数据单元的数量是否小于第二阈值、且所述数据链路层中下行缓冲队列中的数据单元是否大于第三阈值；
    若是，则重新获取IP连接资源；
    若否，重建RRC连接，并判断下行数据链路故障是否被修复，若判断下行数据链路故障未被修复，则重新获取IP连接资源。
  14. 根据权利要求9-13任一项所述的设备，其特征在于，所述处理器具体用于：
    确定所述终端设备当前连接的基站；
    重建与所述基站之间的RRC连接。
  15. 根据权利要求9-14任一项所述的设备，其特征在于，所述处理器具体用于：
    确定发送所述上行数据时使用的第一PDN连接；
    判断所述终端设备当前存在的公共数据网络PDN连接数量是否大于1；
    若是，断开、重建所述第一PDN连接；
    若否，则判断所述终端设备对应的运营商是否支持多PDN连接，若是，则重建所述第一PDN连接，若否，则触发跟踪区更新TAU流程。
  16. 根据权利要求15所述的设备，其特征在于，所述处理器具体用于：
    确定所述上行数据对应的核心网，并建立与所述核心网之间的备用PDN连接；
    断开、重建所述第一PDN连接；
    断开所述备用PDN连接。
PCT/CN2017/081395 2016-12-14 2017-04-21 网络故障处理方法及设备 WO2018107635A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/469,322 US10986685B2 (en) 2016-12-14 2017-04-21 System and method for handling network fault identified according to amounts of uplink data sent and downlink data received
EP17881082.6A EP3544366A1 (en) 2016-12-14 2017-04-21 Network failure processing method and device
CN201780009365.2A CN108605257B (zh) 2016-12-14 2017-04-21 网络故障处理方法及设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611155224.5 2016-12-14
CN201611155224 2016-12-14

Publications (1)

Publication Number Publication Date
WO2018107635A1 true WO2018107635A1 (zh) 2018-06-21

Family

ID=62557945

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/081395 WO2018107635A1 (zh) 2016-12-14 2017-04-21 网络故障处理方法及设备

Country Status (4)

Country Link
US (1) US10986685B2 (zh)
EP (1) EP3544366A1 (zh)
CN (1) CN108605257B (zh)
WO (1) WO2018107635A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111800840A (zh) * 2020-06-29 2020-10-20 RealMe重庆移动通信有限公司 小区连接控制方法、装置、移动终端及存储介质
CN113992731A (zh) * 2021-11-02 2022-01-28 四川安迪科技实业有限公司 基于stomp协议的异常控制方法及装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11368861B2 (en) * 2019-03-29 2022-06-21 Lg Electronics Inc. Method and apparatus for transmitting stuck indication by user equipment in wireless communication system
WO2021243535A1 (en) * 2020-06-02 2021-12-09 Qualcomm Incorporated Radio link control layer feedback reporting for rateless codes
US20220094722A1 (en) * 2020-09-24 2022-03-24 Avaya Management L.P. Methods and systems for maintaining conditional communication sessions using terminable authentication signals
US11968674B2 (en) * 2021-02-04 2024-04-23 Qualcomm Incorporated Controlling modem memory used by uplink data

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101998469A (zh) * 2009-08-17 2011-03-30 中兴通讯股份有限公司 基于载波聚合的无线链路故障处理方法及用户设备
CN102293029A (zh) * 2011-04-26 2011-12-21 华为技术有限公司 一种用户面缓冲器内存的恢复方法及装置
WO2012139798A1 (en) * 2011-04-15 2012-10-18 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for radio link monitoring
CN103765954A (zh) * 2011-07-01 2014-04-30 高通股份有限公司 预先约定的无线链路故障恢复信道序列

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050172894A1 (en) * 2004-02-10 2005-08-11 Farnworth Warren M. Selective deposition system and method for initiating deposition at a defined starting surface
CN101815314A (zh) * 2009-02-20 2010-08-25 华为技术有限公司 发现无线网络问题的方法、装置及系统
CN101789880B (zh) 2010-01-22 2012-09-05 中国电信股份有限公司 基于IP接入网实现上行QoS的方法和多业务接入网关
EP2945453B1 (en) * 2010-08-13 2016-11-02 Interdigital Patent Holdings, Inc. In-device interference mitigation
GB2484117A (en) * 2010-09-30 2012-04-04 Fujitsu Ltd Automated network coverage hole detection by systematically modifying a connection reestablishment timer (T311) in a number of UEs
JP4927213B1 (ja) * 2010-12-03 2012-05-09 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法、ゲートウェイ装置、移動管理ノード及び呼セッション制御サーバ装置
EP2749064B1 (en) * 2011-09-30 2019-12-04 Nokia Solutions and Networks Oy Radio link failure report filtering
BR112014017289A8 (pt) * 2012-01-20 2017-07-04 Fujitsu Ltd método para analisar uma causa de falha de enlace, método e aparelho de otimização de rede
CN106454926B (zh) * 2012-05-04 2020-06-02 华为技术有限公司 链路覆盖问题确定方法、装置与系统
EP3039799B1 (en) * 2013-08-27 2021-06-16 Samsung Electronics Co., Ltd. Method and apparatus for random access procedure and radio link failure in inter-enb carrier aggregation
CN104813701A (zh) * 2013-09-24 2015-07-29 华为技术有限公司 一种终端、基站及其发送失败信息的方法
EP2854449B1 (en) * 2013-09-26 2018-01-31 Alcatel Lucent Wireless telecommunications network nodes and methods
US10306696B2 (en) * 2014-05-16 2019-05-28 Lg Electronics Inc. Method and apparatus for handling RAN assistance information for radio link failure in wireless communication system
US10524152B2 (en) 2015-01-22 2019-12-31 Nokia Solutions And Networks Oy Coverage hole analysis
JP2018093249A (ja) * 2015-04-03 2018-06-14 シャープ株式会社 無線通信システム、端末装置、基地局装置、無線通信方法および集積回路
US10548000B2 (en) * 2015-06-11 2020-01-28 Intel IP Corporation Cellular IoT network architecture
US10097462B2 (en) * 2016-04-02 2018-10-09 Niciria, Inc. Throughput resilience during link failover
CN106028470B (zh) * 2016-07-29 2019-07-09 武汉虹信通信技术有限责任公司 一种实现无线资源控制连接重建的方法及小基站簇控制器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101998469A (zh) * 2009-08-17 2011-03-30 中兴通讯股份有限公司 基于载波聚合的无线链路故障处理方法及用户设备
WO2012139798A1 (en) * 2011-04-15 2012-10-18 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for radio link monitoring
CN102293029A (zh) * 2011-04-26 2011-12-21 华为技术有限公司 一种用户面缓冲器内存的恢复方法及装置
CN103765954A (zh) * 2011-07-01 2014-04-30 高通股份有限公司 预先约定的无线链路故障恢复信道序列

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3544366A4

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111800840A (zh) * 2020-06-29 2020-10-20 RealMe重庆移动通信有限公司 小区连接控制方法、装置、移动终端及存储介质
CN111800840B (zh) * 2020-06-29 2022-10-28 RealMe重庆移动通信有限公司 小区连接控制方法、装置、移动终端及存储介质
CN113992731A (zh) * 2021-11-02 2022-01-28 四川安迪科技实业有限公司 基于stomp协议的异常控制方法及装置
CN113992731B (zh) * 2021-11-02 2024-04-30 四川安迪科技实业有限公司 基于stomp协议的异常控制方法及装置

Also Published As

Publication number Publication date
EP3544366A4 (en) 2019-09-25
EP3544366A1 (en) 2019-09-25
CN108605257A (zh) 2018-09-28
US20200077462A1 (en) 2020-03-05
CN108605257B (zh) 2020-12-04
US10986685B2 (en) 2021-04-20

Similar Documents

Publication Publication Date Title
WO2018107635A1 (zh) 网络故障处理方法及设备
US9313094B2 (en) Node and method for signalling in a proxy mobile internet protocol based network
US8620328B2 (en) Handover procedures in a wireless communications system
US20160198457A1 (en) Data Transmission Method and User Equipment
US10616812B2 (en) Voice service handover method and device
RU2504128C2 (ru) Способ, устройство и компьютерный программный продукт для обеспечения восстановления после ошибки шифрования для радиоканала в режиме передачи без подтверждения
EP3641480A1 (en) Method and device for improving quality of call service in mobile communication system
US20110310868A1 (en) P-gw/ggsn issued paging requests
WO2014206489A1 (en) Master base station-controlled response to detected failure of radio link between secondary base station and mobile station in dual connectivity wireless networks
EP3579613A1 (en) User equipment maximum bandwidth control method and device, computer storage medium
JP7357153B2 (ja) セッション管理のための方法および装置
US20130142120A1 (en) Mobile communication method and call session control server device
JP2017515375A (ja) 向上したタイマ取扱い機構
KR20220081990A (ko) 보조 노드 변경을 통한 빠른 mcg 실패 복구
US10530693B2 (en) Congestion control method and apparatus, and related device
US10616119B2 (en) Policy determining method and apparatus
US20160080992A1 (en) Method of Inter-RAT Bearer Change for 3GPP System
US9854487B2 (en) Simplified call continuity
WO2015184704A1 (zh) 网络切换处理方法及装置
US10542467B2 (en) Method and device for establishing a bearer
KR20230005277A (ko) 핸드오버 실패 시나리오에서 네트워크 최적화 관리
US20150011205A1 (en) Communication system, mobility management entity, base station, and communication method
US20130083646A1 (en) Methods and Apparatus for Managing Resource Access Attempts
US9237484B2 (en) Method, system and device for configuring radio access bearers in mobile networks with multi-RAB capability
US11012931B2 (en) Methods, systems, and computer readable media for enhanced signaling gateway (SGW) status detection and selection for emergency calls

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: 17881082

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017881082

Country of ref document: EP

Effective date: 20190619