CN108810939B - 一种提升数据通路可靠性的方法及装置 - Google Patents

一种提升数据通路可靠性的方法及装置 Download PDF

Info

Publication number
CN108810939B
CN108810939B CN201710294200.6A CN201710294200A CN108810939B CN 108810939 B CN108810939 B CN 108810939B CN 201710294200 A CN201710294200 A CN 201710294200A CN 108810939 B CN108810939 B CN 108810939B
Authority
CN
China
Prior art keywords
data packet
tcp
data
packet
transmission condition
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN201710294200.6A
Other languages
English (en)
Other versions
CN108810939A (zh
Inventor
张迪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Priority to CN201710294200.6A priority Critical patent/CN108810939B/zh
Priority to PCT/CN2018/084349 priority patent/WO2018196767A1/zh
Publication of CN108810939A publication Critical patent/CN108810939A/zh
Application granted granted Critical
Publication of CN108810939B publication Critical patent/CN108810939B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本文公布了一种提升数据通路可靠性的方法及装置，包括：根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。本申请有效提升了数据通路的可靠性，能够确保车联网中UE的数据通路正常通畅。

Description

一种提升数据通路可靠性的方法及装置
技术领域
本发明涉及通信领域，具体涉及一种提升数据通路可靠性的方法及装置。
背景技术
随着车联网的发展，需要联网设备的性能和稳定性不断提升。在联网进行数据业务时，通常设备连网之后，如果遇到终端异常或者网络异常导致断网，数据业务就会断开，但此时网络连接状态为已连接，使得终端状态与数据业务的状态不一致，也就无法及时恢复网络。
相关技术中，通过检测传输控制协议(TCP，Transmission Control Protocol)数据包的传输情况来判断网络连接状态。当三次握手完成，TCP客户端和服务器端成功地建立连接，建立连接之后即可开始传输数据，当数据通路故障时通过快速重传和快速恢复等方式修复网络。上述方法能够检测到数据通路异常但不能判断数据通路哪块不通。例如，是PC没有发TCP数据包，还是PC发了网络侧没有回复确认字符(ACK，ACKnowledgment)，还是网络侧发了TCP数据包而PC没有回复ACK，针对这些情况上述方法是无法确定的。也就是说，上述方式只能尝试做一些重传动作恢复数据通路，不能解决因终端问题导致的数据通路障碍。
相关技术中，还可利用长期演进(LTE，Long Term Evolution)协议来判断数据传输情况。LTE中一个用户设备(UE，User Equipment)处在无线资源控制(RRC，RadioResource Control)连接态，信号稳定，并且没有切换，这时可以进行数据业务。其过程是，开机随机接入过程建立RRC，开始附着(Attach)流程：通过安全方面的信令(比如鉴权加密性保护等)建立默认承载。没有数据业务时会释放RRC，断开数据连接，当出现数据通路异常时网络会尝试进行恢复或者切换到其他制式或小区以恢复数据连接。上述方式无法对“用户没有数据需要传输”和“用户有数据需要传输，但是在LTE协议栈中无法进行数据传输”两种情况进行区分，而这两种情况下如果采用上述方式将会尝试通过重启终端来恢复，这时对用户来说则可能是没有进行数据传输时终端突然重启，将会影响用户体验。
针对相关技术中无法准确判断数据通路障碍的原因以及因终端导致数据通道障碍时无法及时进行恢复以至于影响数据业务正常进行的技术问题，目前尚未提出有效的解决方案。
发明内容
为了解决上述技术问题，本发明实施例提供了一种提升数据通路可靠性的方法及装置。
本申请提供了：
一种提升数据通路可靠性的方法，包括：
根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；
在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
其中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因之前，还包括：检测传输控制协议TCP数据包的传输情况以及长期演进LTE协议层的传输情况。
其中，所述检测TCP数据包的传输情况以及LTE协议层的传输情况，包括如下之一或其任意组合：
检测是否向网络侧发送了TCP数据包；
检测是否接收到来自网络侧的确认字符ACK数据包；
检测是否向基站eNB发送了空口数据；
检测是否接收到来自eNB的空口数据；
检测是否将来自网络侧的ACK数据包发送给PC；
检测是否接收到服务器重传的TCP数据包；
检测是否将服务器重传的TCP数据包发送给PC；
检测是否接收到来自PC的ACK数据包。
其中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，并且未能成功向eNB发送空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据但未接收到来自eNB的空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包且接收到了来自网络侧的ACK数据包，成功接收到了来自eNB的空口数据但未能成功将来自网络侧的ACK数据包发送给PC，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，未能成功向网络侧发送TCP数据包，确定为终端原因导致数据通路异常。
其中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，还包括：在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据且接收到了来自eNB的空口数据，确定为网络原因导致数据通路异常。
其中，所述确定数据通路异常的原因之后，还包括：在所述数据通路异常的原因为网络原因导致数据通路异常时，不执行恢复网络的动作。
其中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
接收到了服务器重传的TCP数据包，但未能将所述TCP数据包成功发送给PC，确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC且接收到了来自PC的ACK数据包，但未能成功向eNB发送空口数据，则确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC但未接收到来自PC的ACK数据包，确定为终端原因导致数据通路异常。
一种提升数据通路可靠性的装置，包括：
确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；
执行模块，用于在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
其中，还包括：检测模块，用于检测传输控制协议TCP数据包的传输情况以及长期演进LTE协议层的传输情况。
其中，所述检测模块用于检测TCP数据包的传输情况以及LTE协议层的传输情况，包括如下之一或其任意组合：
检测是否向网络侧发送了TCP数据包；
检测是否接收到来自网络侧的ACK数据包；
检测是否向eNB发送了空口数据；
检测是否接收到来自eNB的空口数据；
检测是否将来自网络侧的ACK数据包发送给PC；
检测是否接收到服务器重传的TCP数据包；
检测是否将服务器重传的TCP数据包发送给PC；
检测是否接收到来自PC的ACK数据包。
其中，所述确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，并且未能成功向eNB发送空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据但未接收到来自eNB的空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包且接收到了来自网络侧的ACK数据包，成功接收到了来自eNB的空口数据但未能成功将来自网络侧的ACK数据包发送给PC，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，未能成功向网络侧发送TCP数据包，确定为终端原因导致数据通路异常。
其中，所述确定模块，用于用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，还包括：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据且接收到了来自eNB的空口数据，确定为网络原因导致数据通路异常。
其中，所述确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
接收到了服务器重传的TCP数据包，但未能将所述TCP数据包成功发送给PC，确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC且接收到了来自PC的ACK数据包，但未能成功向eNB发送空口数据，则确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC但未接收到来自PC的ACK数据包，确定为终端原因导致数据通路异常。
一种提升数据通路可靠性的装置，至少包括：
存储有提升数据通路可靠性程序的存储器；
处理器，配置为执行所述提升数据通路可靠性程序以执行下述操作：根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
一种计算机可读存储介质，所述计算机可读存储介质上存储有提升数据通路可靠性程序，所述提升数据通路可靠性程序被处理器执行时实现上述提升数据通路可靠性方法的步骤。
本发明实施例中，结合UE侧的TCP层数据包传输情况及LTE协议栈中网络侧数据包的传输情况进行综合判断，从而准确判断UE当前的数据通路状况，在判断为终端原因导致的数据通路异常时，在UE侧执行恢复操作，从而解决了无法准确判断数据通路障碍的原因以及因终端导致数据通道障碍时无法及时进行恢复以至于影响数据业务正常进行的技术问题，有效提升了数据通路的可靠性，能够确保车联网中UE的数据通路正常通畅。
本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。
图1为本发明实施例一提升数据通路可靠性方法的流程示意图；
图2为车联网***的结构示例图；
图3为PC向服务器发送TCP数据后接收服务器返回的ACK数据包的场景下数据通路正常时的交互示意图；
图4为PC向服务器发送TCP数据后接收服务器返回的ACK数据包的场景下提升数据通路可靠性的流程示意图；
图5为服务器向PC发送TCP数据后接收PC返回的ACK数据包的场景下数据通路正常时的交互示意图；
图6为服务器向PC发送TCP数据后接收PC返回的ACK数据包的场景下提升数据通路可靠性的流程示意图；
图7为本发明实施例二提升数据可靠性装置的组成结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
相关技术中的技术方案，主要包括如下三种：
1)当网络断开后，终端尝试自动重连，每隔30秒或者1分钟连接一次，当超过一定次数后重连时间间隔加大以降低功耗。
2)在确定断网后，对断网后接收到的由客户端发往服务器的数据包进行第一次处理，并缓存断网后接收到的由客户端发往服务器的数据包；当网络恢复后，将缓存的所述数据包发送给服务器，根据服务器返回的响应包确定是否需要对数据包进行第二次处理，其中，所述第二次处理是对所述第一次处理的更正处理。
3)通过分析媒体接入控制(MAC，Medium Access Control)、IP层、TCP层获取的网络信息，将网络分类，若无线路径状态不是不可用，则以高优先级对第一个重复的确认通知所对应的传输层数据(TCP Data)分组进行本地重传。
相关技术存在如下缺陷：
方案1)仅解决了数据设备网络状态确定是断开情况下的重新连接、数据处理。不能解决网络侧是连接状态的数据问题，不能解决设备网络状态是已连接，但因为终端原因导致的数据业务已经不通以及什么时候设备的数据业务已经异常的问题。
方案2)是一种断网后通过缓存的方法处理数据的方法，未公开网络断开的细节。
方案3)是对无线网络不是不可用的情况下进行的TCP协议的数据包重传，解决的是网络侧阻塞问题。仅在TCP层判断数据不同从而进行数据重传，不能解决因终端原因导致的数据通路问题。
本申请提供一种提升数据通路可靠性的方法及装置，能够解决因终端原因导致的数据通路问题，以保证车载终端的数据通路正常通畅。
实施例一
一种提升数据通路可靠性的方法，如图1所示，可以包括：
步骤101，根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；
步骤102，在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
本实施例中，TCP数据包的传输情况是指在UE侧的TCP数据包传输情况，可以包括TCP层数据包重传的场景下UE是否发送了TCP数据包、是否接收到TCP数据包、是否在接收到TCP数据包之后发送了ACK数据包、以及是否在发送TCP数据包之后接收到了相应ACK数据包等。
本实施例中，LTE协议层的传输情况是指UE侧的LTE协议栈数据包传输情况，主要可以包括：UE侧的LTE协议栈中网络侧数据包的接收情况、以及UE侧的LTE协议栈中向网络侧发送数据包的情况。
本实施例中，结合UE侧的TCP层数据包传输情况及LTE协议栈中网络侧数据包的传输情况进行综合判断，从而准确判断UE当前的数据通路状况，在判断为终端原因导致的数据通路异常时，在UE侧执行恢复操作，从而解决了无法准确判断数据通路障碍的原因以及因终端导致数据通道障碍时无法及时进行恢复以至于影响数据业务正常进行的技术问题，有效提升了数据通路的可靠性，能够确保车联网中UE的数据通路正常通畅。
本实施例的方法可以适用于车联网***中。本实施例的方法可由车联网***中的UE执行，从而提升车联网***中数据通路的可靠性。
例如，本实施例的方法可适用于如图2所示的车联网***，如图2所示，该***主要包括四个部分：PC、UE、基站(eNB)、服务器。其中，PC是指使用数据业务的固定终端(如电脑)或车载终端(如车载电脑)；UE是无线数据终端，负责与基站、服务器连接，给PC提供无线数据业务；eNB为运营商基站，用于提供无线网络，该无线网络可分为PDCP、RLC、MAC层；服务器可以为数据服务器，用于为UE提供无线数据业务。本实施例的方法可由图2所示***结构中的UE来执行，通过将本实施例的方法应用于图2所示的***架构，可以提升该***结构中数据通路的可靠性。
其中，在步骤102之前还可以包括：步骤100，检测TCP数据包的传输情况以及LTE协议层的传输情况。
一种实现方式中，所述检测TCP数据包的传输情况以及LTE协议层的传输情况，可以包括如下之一或其任意组合：
检测是否向网络侧发送了TCP数据包；
检测是否接收到来自网络侧的ACK数据包；
检测是否向eNB发送了空口数据；
检测是否接收到来自eNB的空口数据；
检测是否将来自网络侧的ACK数据包发送给PC；
检测是否接收到服务器重传的TCP数据包；
检测是否将服务器重传的TCP数据包发送给PC；
检测是否接收到来自PC的ACK数据包。
实际应用中，本实施例主要体现在以下四个方面：
1)在PC向服务器发送TCP数据后接收服务器返回的ACK数据包的场景中，通过发现TCP层数据包多次重传，如果UE没有收到服务器回复的TCP ACK消息，这是数据通路出现问题导致的。问题可能出现在PC和网络的数据通路的某个地方。结合判断LTE协议层，UE如果没有给eNB发送空口数据，可以判断为终端原因导致数据通路异常。
2)在PC向服务器发送TCP数据后接收服务器返回的ACK数据包的场景中，通过发现TCP层数据包多次重传，如果UE没有收到服务器回复的TCP ACK消息，这是数据通路出现问题导致的。问题可能出现在PC和网络的数据通路的某个地方。再继续判断LTE协议层，UE如果向eNB发送了空口数据，但是UE没有接收到来自eNB的空口数据，可以判断为终端原因导致数据通路异常。
3)在PC向服务器发送TCP数据后接收服务器返回的ACK数据包的场景中，通过发现TCP层数据包多次重传，如果UE没有收到服务器回复的TCP ACK消息，这是数据通路出现问题导致的。问题可能出现在PC和网络的数据通路的某个地方。继续判断LTE协议层，UE如果向eNB发送了空口数据且接收到了来自eNB的空口数据，此时判断为网络原因导致数据通路异常。
4)在服务器向PC发送TCP数据后接收PC返回的ACK数据包的场景中，通过发现UE接收到了服务器重传的TCP数据包，UE发给了PC重传的TCP数据包，UE也从PC侧收到了ACK数据包，此时继续判断LTE协议层，UE没有发给eNB空口数据，可以判断为终端原因导致数据通路异常。
本实施例中，对于终端原因导致的数据通路异常UE侧执行恢复操作，对由于网络原因导致的数据通路异常UE侧不做处理。
一种实现方式中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少可以包括如下之一：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，并且未能成功向eNB发送空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据但未接收到来自eNB的空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包且接收到了来自网络侧的ACK数据包，成功接收到了来自eNB的空口数据但未能成功将来自网络侧的ACK数据包发送给PC，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，未能成功向网络侧发送TCP数据包，确定为终端原因导致数据通路异常。
一种实现方式中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，还可以包括：在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据且接收到了来自eNB的空口数据，确定为网络原因导致数据通路异常。
本实施例中，所述确定数据通路异常的原因之后，还可以包括：在所述数据通路异常的原因为网络原因导致数据通路异常时，不执行恢复网络的动作。
另一种实现方式中，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少可以包括如下之一：
接收到了服务器重传的TCP数据包，但未能将所述TCP数据包成功发送给PC，确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC且接收到了来自PC的ACK数据包，但未能成功向eNB发送空口数据，则确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC但未接收到来自PC的ACK数据包，确定为终端原因导致数据通路异常。
实际应用中，UE执行恢复操作时的恢复手段可以包括：重新连接、重新attach、modem侧低电/高电、modem侧重启、整机重启等。例如，当UE没有向eNB发送空口数据时，尝试重新detach attach，以恢复数据通路。再例如，当UE未能接收到来自eNB的空口数据时，通过modem侧低电/高电进行恢复。再例如，当UE未能向PC发送服务器重传的ACK数据包时，通过整机重启的方式恢复。再例如，UE从PC侧没有收到的ACK数据包时，重新连接。实际应用中，上述各个场景中还可以交叉使用不同的恢复方式。
实际应用中，本实施例所述的LTE协议层并不局限于LTE制式，也可适用于其他网络制式。
下面以针对两个不同场景以两个实例来详细说明本实施例方法的实现过程。
实例1
本实例的场景为：PC向服务器发送TCP数据后接收服务器返回的ACK数据包的场景。在该场景下，数据通路正常的状况下交互过程如图3所示，可以包括：
步骤301，UE从PC侧接收TCP数据包；
步骤302，UE向网络侧发送TCP数据包；
步骤303，UE接收来自网络侧的ACK数据包；
步骤304：UE向PC发送ACK数据包。
在该场景下，数据通路正常的状况下UE与eNB之间的交互过程如图3所示，可以包括：
步骤305，UE发送给eNB的空口数据(如schedule request)；
步骤306，UE从eNB接收的空口数据(如RLC PDU&CQI)。
如图4所示，本实例中，提升数据通路可靠性的流程可以包括：
步骤401，检测PC是否给UE重传了TCP数据包，如果是，则继续步骤步骤402，如果否则不作处理，结束当前流程。
步骤402，检测UE是否给网络侧发送了所述TCP数据包，如果是则继续步骤403，如果否则跳转至步骤406；
步骤403，检测UE是否从网络侧接收到了所述TCP数据包的ACK数据包，如果是则继续步骤404，如果否则跳转至步骤405；
步骤404，检测UE是否将所述ACK数据包发送给了PC，如果是则跳转至步骤408，如果否则跳转至步骤406；
步骤405，检测UE是否接收到了来自eNB的空口数据，如果是则跳转至步骤407，如果否则跳转至步骤406；
步骤406，判断为终端原因导致的数据通路异常，执行恢复网络的动作，尝试进行恢复。
步骤407，判断为可能是终端原因、也可能是网络原因导致的数据通路异常。由于实际应用中只有断定是终端原因的前提下执行恢复性动作才可能有效。因此，这种情况下，终端可以不进行任何恢复性操作。
步骤408，判断为非终端原因导致的数据通路异常，不做处理。
如图4所示流程可知，本实例主要涉及以下几种情况：
检测发生了TCP数据包重传，UE向网络侧发送TCP数据包，UE从网络侧没有接收到该TCP数据包的ACK数据包，此时结合UE没有给eNB发送空口数据，判断为终端原因导致数据通路异常。这里，只要UE没有给eNB发送空口数据，就足以判断为终端原因，可以不再判断接收。
检测发生了TCP数据包重传，UE向网络侧发送TCP数据包，UE从网络侧没有接收到该TCP数据包的ACK数据包，此时UE给eNB成功发送了空口数据，但UE没有接收到eNB的空口数据，则判断为终端原因导致数据通路异常。
检测发生了TCP数据包重传，UE向网络侧发送了TCP数据包，UE从网络侧接收到了重传的ACK数据包，此时可以判断UE已经接收到了来自eNB的空口数据，而如果UE没有把来自网络侧的ACK数据包发给PC，则判断为终端原因导致数据通路异常。
检测发生了TCP数据包重传，UE向网络侧发送了TCP数据包，UE没有接收到网络侧重传的ACK数据包，UE向eNB成功发送了空口数据，但UE也接收到了来自eNB的空口数据，此时则判断为网络原因导致数据通路异常。
检测发生了TCP数据包重传，UE没有向网络侧发送TCP数据包，则判断为终端原因导致数据通路异常。
本实例中，结合上述UE对各TCP数据包的检测情况以及UE对LTE空口数据传输的检测情况综合判断是否为终端原因导致的数据通路异常，在终端原因导致数据通路异常时在终端侧执行恢复网络的动作。
本实例中，检测是否发生TCP重传的方法可以是：UE保存最近5s之内UE从PC侧收到的TCP数据包的序列号及内容，UE将当前接收到的来自PC侧的TCP数据包的序列号及内容与所保存的最近5s之内UE从PC侧收到的TCP数据包的序列号及内容进行对比，如果UE检测到当前从PC侧收到的TCP数据包的序列号及内容与保存的最近5s之内UE从PC侧收到的TCP数据包中的某一个或多个TCP数据包的序列号及内容相同，则认定为发生了TCP数据包重传。如果UE检测到当前从PC侧收到的TCP数据包的序列号及内容与保存的最近5s之内UE从PC侧收到的TCP数据包中的任何一个TCP数据包的序列号及内容均不相同，则认定为没有发生TCP数据包重传。
本实例中，UE检测是否给网络侧发送了所述TCP数据包的方式可以是：UE保存最近5s之内UE发送给网络侧的TCP数据包的序列号及内容，UE将重传的TCP数据包的序列号及内容与所保存的最近5s之内UE发送给网络侧的TCP数据包的序列号及内容进行对比，如果UE检测到重传的TCP数据包的序列号及内容与保存的最近5s之内UE发送给网络的TCP数据包的某一个或多个TCP数据包的序列号及内容相同，则认定为UE将重传的TCP数据包发给了网络。如果UE检测到重传的TCP数据包的序列号及内容与保存的最近5s之内UE发送给网络的TCP数据包中的任何一个TCP数据包的序列号及内容均不相同，则认定为UE未发给网络侧重传的TCP数据包。
本实例中，UE检测是否从网络侧接收到了所述TCP数据包的ACK数据包的方法可以是：UE保存最近5s之内UE从网络侧收到的ACK数据包的序列号；UE将发生重传的TCP数据包的序列号与所保存的最近5s之内UE从网络侧收到的ACK数据包的序列号进行对比，如果UE检测到发生重传的TCP数据包的序列号与所保存的最近5s之内UE从网络侧收到的ACK数据包中的某一个或多个ACK数据包的序列号相同，则认定UE收到了重传TCP数据包的ACK数据包。如果UE检测到发生重传的TCP数据包的序列号与所保存的最近5s之内UE从网络侧收到的ACK数据包中的任何一个ACK数据包的序列号均不相同，则认定UE未收到该重传TCP数据包的ACK数据包。
本实例中，检测UE是否将ACK数据包发送给PC的方式可以是：UE保存最近5s之内UE发给PC的ACK数据包的序列号；UE将发生重传的TCP数据包的序列号与保存的最近5s之内UE发给PC的ACK数据包的序列号进行对比，如果UE检测到发生重传的TCP数据包的序列号与保存的最近5s之内UE发给PC的ACK数据包的序列号中的某一个或多个ACK数据包的序列号相同，则认定UE将重传TCP数据包的ACK数据包发送给了PC。如果UE检测到发生重传的TCP数据包的序列号与保存的最近5s之内UE发给PC的任何一个ACK数据包的序列号均不相同，则认定UE未将重传TCP数据包的ACK数据包发送给PC。
上述检测方式中UE保存最近5s之内的数据包是优选方案，可以将所保存数据包的时长设定为其他值，比如UE保存最近10s之内的数据包、UE保存最近30s之内的数据包，一般所保存数据包的时长设定为不超过1分钟的值，以避免UE处理数据的负荷太大而导致拥塞。
本实例中，检测UE是否接收到了来自eNB的空口数据的方法可以包括如下：
首先判断下行信道质量：eNB发送小区特定参考信号(cell specific referencesignal)给UE，UE估计信道质量指示(CQI，Channel Quality Indicator)并上报给eNB，CQI不仅告诉eNB信道的质量，还包含推荐的编码调制方式。eNB根据下行信道的质量好坏自适应地分配下行资源(针对UE选择不同的载波和时隙(slot))。下行链路中，演进的通用陆地无线接入网络(Evolved Universal Terrestrial Radio Access Network，E-UTRAN)在每个传输时间间隔(TTI，Transmission time interval)动态地给UE分配资源物理资源块(PRBs，Physical Resource Block)&多点通信业务(MCS，Multipoint CommunicationService)。eNB在下行信道传输数据，根据资源分配的结果在物理下行共享信道(PDSCH，Physical Downlink Shared Channel)上填充数据,并在PDCCH上传输相应的小区无线网络临时标识(C-RNTI，Cell Radio Network Temporary Identifier)。
再判断RLC链路，RLC是LTE中的无线链路控制层协议，确认模式(AM)：发送侧在高层数据上添加必要的控制协议开销后进行传送，并保证传递到对等实体。因为具有自动重传请求(ARQ，Automatic Repeat Request)能力，如果无线链路控制(RLC，Radio LinkControl)接收到错误的RLC PDU，就通知发送方的RLC重传这个协议数据单元(ProtocolData Unit，PDU)。由于RLC PDU中包含有顺序号信息，支持数据向高层的顺序/乱序递交。AM模式是分组数据传输的标准模式。
UE检测RLC层是否有PDU,如果有则判定UE从eNB接收到了空口数据，如果没有PDU则判定为UE未从eNB接收到空口数据。
实例2
本实例的场景为：服务器向PC发送TCP数据后接收PC返回的ACK数据包的场景。在该场景下，数据通路正常的状况下交互过程如图5所示，可以包括：
S501，UE从网络侧接收TCP数据包；
S502，UE向PC发送TCP数据包；
S503，UE接收来自PC的ACK数据包；
S504，UE向网络侧发送ACK数据包。
在该场景下，数据通路正常的状况下UE与eNB之间的交互过程如图5所示，其过程与实例1相同，不再赘述。
如图6所示，本实例中，提升数据通路可靠性的流程可以包括：
步骤601，检测UE是否接收到服务器重传的TCP数据包，如果是则继续步骤602，如果否则跳转至步骤606；
步骤602，检测UE是否将服务器重传的TCP数据包发给了PC，如果是则继续步骤603，如果否则跳转至步骤606；
步骤603，检测UE是否接收到来自PC的ACK数据包，如果是则继续步骤604，如果否则跳转至步骤606；
步骤604，检测UE是否向eNB发送了空口数据，如果是则继续步骤605，如果否则跳转至步骤606；
步骤605，判断为非终端原因导致的数据通路异常，不做处理。
步骤606，判断为终端原因导致的数据通路异常，执行恢复网络的动作，尝试进行恢复。
本实例中，结合UE对各种TCP数据包的检测情况以及UE对LTE空口数据传输的检测情况综合判断是否为终端原因导致的数据通路异常，在终端原因导致数据通路异常时在终端侧执行恢复网络的动作。
通过图6所示流程可知，本实例主要涉及以下几种情况：
检测UE接收到了服务器重传的TCP数据包，UE未发给PC所述重传的TCP数据包，则判断为终端原因导致数据通路异常。
检测UE接收到了服务器重传的TCP数据包，UE向PC发送了所述服务器重传的TCP数据包，UE接收到了来自PC侧的ACK数据包，UE没有发给eNB空口数据，则判断为终端原因导致数据通路异常。
检测UE接收到了服务器重传的TCP数据包，UE向PC发送了所述服务器重传的TCP数据包，UE没有收到来自PC侧的ACK数据包，则判断为终端原因导致数据通路异常。
本实例中，检测的方式与实例1相似，只是方向正好相反，这里不再赘述。
本实例中，检测UE是否向eNB发送了空口数据的方法可以包括如下：
UE向eNB请求上行资源：物理信道(Physical channel)，PUCCH(Physical UplinkControl Channel)Message(物理上行链路控制信道信息)，SR(schedule request)(时间表请求)。SR发送的周期以及在子帧中的位置由上层的配置决定。UE需要告诉eNB自己要传输的数据量，同时SR中UE必须告诉eNB自己的identity(C-RNTI)。eNB对SR的发送者的识别是通过UE和eNB事先约定好的伪随机序列来实现的。当UE有发送数据的需求时，就把相应得SR置1，没有资源请求时SR为空。SR只负责告诉eNB是否有资源需求，而具体需要多少资源则由上层的信令交互告诉eNB。
eNB给UE分配上行资源之前首先必须要知道上行信道的质量，如果UE的上行信道质量较好且有传输数据的需求，eNB才会给UE分配资源。eNB根据从UE接收到的声音参照信号(sounding reference signal)和自己已知的信号的对比就可以知道当前上行信道的质量了。
eNB分配资源并通知UE：分配完资源后eNB还必须把分配的结果告诉UE，即UE可以在哪个时间哪个载波上传输数据，以及采用的调制编码方案。E-UTRAN在每个TTI动态地给UE分配资源(PRBs&MCS)，并在PDCCH上传输相应的C-RNTI。
UE接收资源分配结果的通知并传输数据：UE首先接收eNB下发的资源分配通知，监视PDCCH以查找可能的上行传输资源分配，从通用搜索空间(common search space)中获取公共信息，从UE specific search space中搜索关于自己的调度信息。根据搜索到的结果后就可以在PUSCH对应的PRB上传输数据信息。
综上，UE通过与eNB的交互，在调度信息中分配给自己的物理资源块(PRB，Physical Resource Block)上进行了数据发送，将数据发送到eNB以后则判定UE的空口数据已经发送给了eNB。
实施例二
一种提升数据通路可靠性的装置，如图7所示，包括：
确定模块72，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；
执行模块73，用于在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
其中，所述提升数据通路可靠性的装置还可以包括：检测模块71，用于检测传输控制协议TCP数据包的传输情况以及长期演进LTE协议层的传输情况。一种实现方式中，所述检测模块71用于检测TCP数据包的传输情况以及LTE协议层的传输情况，可以包括如下之一或其任意组合：
检测是否向网络侧发送了TCP数据包；
检测是否接收到来自网络侧的ACK数据包；
检测是否向eNB发送了空口数据；
检测是否接收到来自eNB的空口数据；
检测是否将来自网络侧的ACK数据包发送给PC；
检测是否接收到服务器重传的TCP数据包；
检测是否将服务器重传的TCP数据包发送给PC；
检测是否接收到来自PC的ACK数据包。
一种实现方式中，所述确定模块72用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，并且未能成功向eNB发送空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据但未接收到来自eNB的空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包且接收到了来自网络侧的ACK数据包，成功接收到了来自eNB的空口数据但未能成功将来自网络侧的ACK数据包发送给PC，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，未能成功向网络侧发送TCP数据包，确定为终端原因导致数据通路异常。
一种实现方式中，所述确定模块72用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，还可以包括：在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据且接收到了来自eNB的空口数据，确定为网络原因导致数据通路异常。
在另一种实现方式中，所述确定模块72用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
接收到了服务器重传的TCP数据包，但未能将所述TCP数据包成功发送给PC，确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC且接收到了来自PC的ACK数据包，但未能成功向eNB发送空口数据，则确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC但未接收到来自PC的ACK数据包，确定为终端原因导致数据通路异常。
本实施例中提升数据通路可靠性的装置可以实现实施例一所述方法的所有细节，可参照相应方法的相关说明。实际应用中，本实施例中的提升数据通路可靠性的装置可以通过设置于车联网设备(如UE)上来实现上述功能以及实施例一的方法，或者本实施例中的提升数据通路可靠性的装置可以直接通过车联网设备(如UE)实现。
实际应用中，检测模块71、确定模块72、执行模块73分别可以通过软件、硬件或两者结合的方式实现。例如，检测模块71、确定模块72、执行模块73可以通过车联网设备(如UE)的处理器通过执行相应程序来实现。对此本文不作限制。
实施例三
一种提升数据通路可靠性的装置，至少包括：
存储有提升数据通路可靠性程序的存储器；
处理器，配置为执行所述提升数据通路可靠性程序以执行下述操作：检测传输控制协议TCP数据包的传输情况以及长期演进LTE协议层的传输情况；根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因；在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
本实施例中提升数据通路可靠性的装置可以实现实施例一所述方法的所有细节，可参照相应方法的相关说明。实际应用中，本实施例中的提升数据通路可靠性的装置可以通过设置于车联网设备(如UE)上来实现上述功能以及实施例一的方法，或者本实施例中的提升数据通路可靠性的装置可以直接通过车联网设备(如UE)实现。
此外，本申请实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令被执行时实现上述提升数据通路可靠性的方法。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例的方法步骤。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件(例如处理器)完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，例如通过集成电路来实现其相应功能，也可以采用软件功能模块的形式实现，例如通过处理器执行存储于存储器中的程序/指令来实现其相应功能。本申请不限制于任何特定形式的硬件和软件的结合。
以上显示和描述了本申请的基本原理和主要特征和本申请的优点。本申请不受上述实施例的限制，上述实施例和说明书中描述的只是说明本申请的原理，在不脱离本申请精神和范围的前提下，本申请还会有各种变化和改进，这些变化和改进都落入要求保护的本申请范围内。

Claims (15)

1.一种提升数据通路可靠性的方法，其特征在于，包括：
根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，所述TCP数据包的传输情况是指在用户设备UE侧的TCP数据包传输情况，包括TCP层数据包重传的场景下UE是否发送了TCP数据包、是否接收到TCP数据包、是否在接收到TCP数据包之后发送了ACK数据包、以及是否在发送TCP数据包之后接收到了相应ACK数据包，所述LTE协议层的传输情况是指UE侧的LTE协议栈数据包传输情况，包括UE侧的LTE协议栈中网络侧数据包的接收情况、以及UE侧的LTE协议栈中向网络侧发送数据包的情况；
在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
2.根据权利要求1所述的方法，其特征在于，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因之前，还包括：
检测传输控制协议TCP数据包的传输情况以及长期演进LTE协议层的传输情况。
3.根据权利要求2所述的方法，其特征在于，所述检测TCP数据包的传输情况以及LTE协议层的传输情况，包括如下之一或其任意组合：
检测是否向网络侧发送了TCP数据包；
检测是否接收到来自网络侧的确认字符ACK数据包；
检测是否向基站eNB发送了空口数据；
检测是否接收到来自eNB的空口数据；
检测是否将来自网络侧的ACK数据包发送给PC；
检测是否接收到服务器重传的TCP数据包；
检测是否将服务器重传的TCP数据包发送给PC；
检测是否接收到来自PC的ACK数据包。
4.根据权利要求1所述的方法，其特征在于，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，并且未能成功向eNB发送空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据但未接收到来自eNB的空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包且接收到了来自网络侧的ACK数据包，成功接收到了来自eNB的空口数据但未能成功将来自网络侧的ACK数据包发送给PC，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，未能成功向网络侧发送TCP数据包，确定为终端原因导致数据通路异常。
5.根据权利要求1所述的方法，其特征在于，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，还包括：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据且接收到了来自eNB的空口数据，确定为网络原因导致数据通路异常。
6.根据权利要求1或5所述的方法，其特征在于，所述确定数据通路异常的原因之后，还包括：在所述数据通路异常的原因为网络原因导致数据通路异常时，不执行恢复网络的动作。
7.根据权利要求1所述的方法，其特征在于，所述根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
接收到了服务器重传的TCP数据包，但未能将所述TCP数据包成功发送给PC，确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC且接收到了来自PC的ACK数据包，但未能成功向eNB发送空口数据，则确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC但未接收到来自PC的ACK数据包，确定为终端原因导致数据通路异常。
8.一种提升数据通路可靠性的装置，其特征在于，包括：
确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，所述TCP数据包的传输情况是指在用户设备UE侧的TCP数据包传输情况，包括TCP层数据包重传的场景下UE是否发送了TCP数据包、是否接收到TCP数据包、是否在接收到TCP数据包之后发送了ACK数据包、以及是否在发送TCP数据包之后接收到了相应ACK数据包，所述LTE协议层的传输情况是指UE侧的LTE协议栈数据包传输情况，包括UE侧的LTE协议栈中网络侧数据包的接收情况、以及UE侧的LTE协议栈中向网络侧发送数据包的情况；
执行模块，用于在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
9.根据权利要求8所述的装置，其特征在于，还包括：检测模块，用于检测传输控制协议TCP数据包的传输情况以及长期演进LTE协议层的传输情况。
10.根据权利要求9所述的装置，其特征在于，所述检测模块用于检测TCP数据包的传输情况以及LTE协议层的传输情况，包括如下之一或其任意组合：
检测是否向网络侧发送了TCP数据包；
检测是否接收到来自网络侧的ACK数据包；
检测是否向eNB发送了空口数据；
检测是否接收到来自eNB的空口数据；
检测是否将来自网络侧的ACK数据包发送给PC；
检测是否接收到服务器重传的TCP数据包；
检测是否将服务器重传的TCP数据包发送给PC；
检测是否接收到来自PC的ACK数据包。
11.根据权利要求8所述的装置，其特征在于，所述确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，并且未能成功向eNB发送空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据但未接收到来自eNB的空口数据，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，向网络侧发送了TCP数据包且接收到了来自网络侧的ACK数据包，成功接收到了来自eNB的空口数据但未能成功将来自网络侧的ACK数据包发送给PC，确定为终端原因导致数据通路异常；
在发生TCP数据重传时，未能成功向网络侧发送TCP数据包，确定为终端原因导致数据通路异常。
12.根据权利要求8所述的装置，其特征在于，所述确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，还包括：在发生TCP数据重传时，向网络侧发送了TCP数据包但未接收到来自网络侧的ACK数据包，成功向eNB发送了空口数据且接收到了来自eNB的空口数据，确定为网络原因导致数据通路异常。
13.根据权利要求8所述的装置，其特征在于，所述确定模块，用于根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，至少包括如下之一：
接收到了服务器重传的TCP数据包，但未能将所述TCP数据包成功发送给PC，确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC且接收到了来自PC的ACK数据包，但未能成功向eNB发送空口数据，则确定为终端原因导致数据通路异常；
接收到了服务器重传的TCP数据包，将所述TCP数据包成功发送给PC但未接收到来自PC的ACK数据包，确定为终端原因导致数据通路异常。
14.一种提升数据通路可靠性的装置，其特征在于，至少包括：
存储有提升数据通路可靠性程序的存储器；
处理器，配置为执行所述提升数据通路可靠性程序以执行下述操作：根据TCP数据包的传输情况以及LTE协议层的传输情况，确定数据通路异常的原因，所述TCP数据包的传输情况是指在用户设备UE侧的TCP数据包传输情况，包括TCP层数据包重传的场景下UE是否发送了TCP数据包、是否接收到TCP数据包、是否在接收到TCP数据包之后发送了ACK数据包、以及是否在发送TCP数据包之后接收到了相应ACK数据包，所述LTE协议层的传输情况是指UE侧的LTE协议栈数据包传输情况，包括UE侧的LTE协议栈中网络侧数据包的接收情况、以及UE侧的LTE协议栈中向网络侧发送数据包的情况；在所述数据通路异常的原因为终端原因导致数据通路异常时，执行恢复网络的动作。
15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有提升数据通路可靠性程序，所述提升数据通路可靠性程序被处理器执行时实现如权利要求1至7中任一项所述提升数据通路可靠性方法的步骤。
CN201710294200.6A 2017-04-28 2017-04-28 一种提升数据通路可靠性的方法及装置 Active CN108810939B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201710294200.6A CN108810939B (zh) 2017-04-28 2017-04-28 一种提升数据通路可靠性的方法及装置
PCT/CN2018/084349 WO2018196767A1 (zh) 2017-04-28 2018-04-25 一种提升数据通路可靠性的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710294200.6A CN108810939B (zh) 2017-04-28 2017-04-28 一种提升数据通路可靠性的方法及装置

Publications (2)

Publication Number Publication Date
CN108810939A CN108810939A (zh) 2018-11-13
CN108810939B true CN108810939B (zh) 2021-04-30

Family

ID=63918841

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710294200.6A Active CN108810939B (zh) 2017-04-28 2017-04-28 一种提升数据通路可靠性的方法及装置

Country Status (2)

Country Link
CN (1) CN108810939B (zh)
WO (1) WO2018196767A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022061698A1 (en) * 2020-09-25 2022-03-31 Qualcomm Incorporated Recover from downlink data transfer failure

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100372306C (zh) * 2005-05-10 2008-02-27 华为技术有限公司 一种异步传输模式承载ip数据通道故障定位方法
CN101437029B (zh) * 2008-12-23 2012-08-29 华为技术有限公司 数据传输方法、本地维护终端、代理设备及***
CN102833783B (zh) * 2012-07-02 2015-04-08 北京邮电大学 一种优化无线环境下tcp协议的方法
CN103648058B (zh) * 2013-10-28 2017-01-11 南京邮电大学 基于信道测量的3g媒体流跨层速率控制方法
KR20150089853A (ko) * 2014-01-28 2015-08-05 삼성전자주식회사 이종 무선망에서 트래픽 분산 제어방법 및 장치

Also Published As

Publication number Publication date
CN108810939A (zh) 2018-11-13
WO2018196767A1 (zh) 2018-11-01

Similar Documents

Publication Publication Date Title
US11889577B2 (en) Methods for handling periodic radio access network notification area (RNA) update configuration upon reject
US9629192B2 (en) Method, terminal, and system for realizing device to device communication
KR101532789B1 (ko) 재전송 데이터를 처리하는 ｈａｒｑ 동작 방법
US8971288B2 (en) Method of supporting handover in a wireless communication system
KR101375936B1 (ko) 시간동기 타이머의 만료 시 하향링크 ｈａｒｑ의 동작 방법
EP2154927B1 (en) Data transmission method and user equipment for the same
TWI471024B (zh) 在基地台與行動台之間交換資料的方法與裝置
EP2094054A2 (en) Method of performing random access procedure in wireless communication system
US20220116819A1 (en) Method and apparatus for reporting rlc layer status, storage medium and user equipment
US10757605B2 (en) Radio communication device and radio communication method
CN108322936B (zh) 数据重传的方法及装置
WO2017215749A1 (en) Reallocation of control channel resources for retransmission of data in wireless networks based on communications mode
US11246185B2 (en) Radio terminal and base station
EP2209248A2 (en) Method for processing NDI in random access procedure and a method for transmitting and receiving a signal using the same
JP6736045B2 (ja) 無線通信装置
US20240080725A1 (en) Methods, systems and devices that provide fast mobility
US20230397297A1 (en) Methods and apparatuses for a scg deactivation mechanism and a scg activation mechanism in a mr-dc scenario
CN108810939B (zh) 一种提升数据通路可靠性的方法及装置
US10009884B2 (en) Method of error recovery in transmitting and receiving voice service in packet based mobile communication systems
KR101313517B1 (ko) 패킷 데이터 네트워크 통신 디바이스 및 방법
US11683134B2 (en) Data transmission method, network device, and terminal device
KR20100008232A (ko) 무선연결 설정방법
CN112615760A (zh) 数据传输方法、装置、基站和存储介质
US20180192453A1 (en) Communication system, communication method, and recording medium in which communication program is recorded
US20240080083A1 (en) Methods, systems and devices that provide fast mobility

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant