CN102546531A - 数据流量的控制方法及用户终端 - Google Patents

Abstract

本发明涉及通信领域，公开了一种数据流量的控制方法及用户终端。本发明中，在UE侧检测协议栈内部拥塞情况，在处于拥塞状态时指示PC侧不再发数据。由于UE通过对协议栈内部拥塞情况进行监控，当处于拥塞状态时(即出现TCP包不能及时通过空口发送的情况)，随时指示PC侧不再发数据，因此在拥塞状态时PC侧就不会再产生多余的TCP重传包，从而有效利用了无线资源。其中，可以通过将从网络侧收到的TCP包中的通告窗口字段修改为0，实现拥塞状态下向PC侧指示暂停TCP包的发送，实现简单，不需要更改PC侧应用就可达到终端和PC之间流量控制的效果，具有极强的适应性。

Description

数据流量的控制方法及用户终端

技术领域

本发明涉及通信领域，特别涉及通信领域中数据的流控技术。

背景技术

在无线通信***中，用户终端(UE)和网络设备作为底层的承载，可以为应用程序提供传输链路，完成数据的传输。对于使用传输控制协议TCP/网间互联协议IP协议的应用程序，UE和无线设备之间传递的数据就是IP包，如图1所示，UE协议栈包括高层(非接入层和接入层)和物理层。TCP/IP协议层及其应用层则相对地属于应用程序的范畴，通常位于PC(个人计算机)侧。PC侧应用和UE通过USB接口进行通信。

PC侧和网络侧数据交互有如下过程：

(1)PC侧的TCP包通过USB口传递给UE，UE通过无线接口发送给网络。

(2)UE接收到来自网络的下行数据重组成TCP包，并通过USB口发送给PC侧。

TCP包的发送速率，一般是通过滑动窗口机制来控制的。其发送参数则是根据TCP包在网络中往返时间(RTT，即从发送数据到接收到数据确认的总时间)的变化来调整的。而UE的发送速率则依赖于空口资源状况。若网络侧分配的资源少，空口的传输速率就相对较慢。因此，需要考虑TCP包的发送速率与空口速率的适应问题。

目前，PC和UE的交互过程通常如图2所示。PC侧的应用程序在发送窗口之内，不断的发送TCP包给UE侧。UE侧将此TCP包按照空口格式，进行分段、编码、调制等操作，然后通过空口发送给网络。

UE接收到空口数据时，经过解调、译码和组包的操作，得到相应的TCP包。UE将其通过USB口发送给PC侧，PC侧应用程序则对这些TCP包进行相应的处理。

在上述方案中，若TCP包的发送速率和空口速率较为匹配，则不存在问题。比如说，以拥塞窗口和通告窗口都是32个报文段的大小为例：拥塞窗口＝32768字节，通告窗口＝32768字节，报文段长度(LEN)＝1024字节。

如图3所示，不考虑TCP慢启动。在空口速率较快的情况下，UE收到的来自PC侧的数据包都迅速发送了出去，也及时收到了网络的TCP确认。因此，空口速率对TCP包的发送不构成明显影响。

但若空口质量不理想，则应用程序所在的PC侧发送给UE的TCP包堆积在UE协议栈内，无法及时发送。而对于TCP层来说，数据堆积在UE的时间是计入重传时长的。一旦重传定时器超时，未收到确认的数据就会被重传，造成空口资源浪费。虽然TCP/IP本身具备通过调整窗口适应速率的功能，但调整的速度无法适应空口资源变化。若TCP包的发送速率和空口速率不能匹配，则出现UE侧上行数据的拥塞，使得TCP包缓存在UE得不到及时发送，引起TCP层不必要的重传。

具体地说，如图4所示，在现有方案中，UE接收到TCP包之后，因空口速率较慢，堆积在终端的数据越来越多。T1时刻发出的seq＝5120的TCP包，在T2时刻因为还没有得到确认，于是在T2时刻超时重新发送。seq＝6144、seq＝7168的数据块也是一样，分别在T3和T4时刻超时重传。

由此可见，空口上会堆积大量重发的数据包。虽然一段时间之后，TCP/IP协议会因为测量到RTT变长而调整重传数据的间隔。但重传的数据还是会增加空口的负担。承载数据的无线信道随环境易于变化，现有方案就不可避免地出现TCP发送速率无法与之匹配的问题，从而影响整个***的效率。

另外，若在PC和UE之间增加一个流控机制，UE通过消息来通知PC侧暂停发送或者恢复发送TCP数据，这需要更改PC侧应用程序的实现。在一般应用程序非透明的情况下，这一点无法办到。

发明内容

本发明的目的在于提供一种数据流量的控制方法及用户终端，使得TCP应用能适应无线***资源的快速变化，从而有效地利用了无线资源。

为解决上述技术问题，本发明的实施方式提供了一种数据流量的控制方法，包含以下步骤：

用户终端UE检测本UE内待发送的传输控制协议TCP包的堆积情况，并根据所述TCP包的堆积情况，判断所述UE是否处于拥塞状态；

如果所述UE判定处于拥塞状态，则所述UE指示个人计算机PC侧暂停TCP包的发送。

本发明的实施方式还提供了一种用户终端，包含：

检测模块，用于检测待发送的传输控制协议TCP包的堆积情况；

状态判断模块，用于根据所述检测模块检测到的TCP包的堆积情况，判断所述用户终端UE是否处于拥塞状态；

流量控制模块，用于在所述状态判断模块判定处于拥塞状态时，指示个人计算机PC侧暂停TCP包的发送。

本发明实施方式相对于现有技术而言，在UE侧检测协议栈内部拥塞情况，在处于拥塞状态时指示PC侧不再发数据。由于UE通过对协议栈内部拥塞情况进行监控，当处于拥塞状态时(即出现TCP包不能及时通过空口发送的情况)，随时指示PC侧不再发数据，因此在拥塞状态时PC侧就不会再产生多余的TCP重传包，保证了TCP包的发送速率与空口速率能较好地匹配，使得TCP应用能适应无线***资源的快速变化，从而有效利用了无线资源。

另外，UE通过将从网络侧收到的TCP包中的通告窗口字段修改为0后，再将该TCP包传递给PC侧，实现拥塞状态下向PC侧指示暂停TCP包的发送。实现简单，不需要更改PC侧应用就可达到终端和PC之间流量控制的效果，具有极强的适应性。

另外，当UE根据TCP包的堆积情况，判定UE不处于拥塞状态时，将从网络侧收到的TCP包直接透传给所述PC侧，进一步保证了TCP应用能适应了线***资源的快速变化，使得空口资源得到合理使用。

另外，如果在UE中存在至少两个TCP连接，则UE根据各TCP连接的不同优先级，为各TCP连接设置不同的拥塞门限值，其中，为优先级越低的TCP连接，设置越低的拥塞门限值。将不同优先级的TCP连接采用不同策略的流控机制，既保证了终端的发送缓存不会溢出，又能够使高优先级的应用数据有更大的概率发送出去。

附图说明

图1是根据现有技术中的通过UE进行数据传输的协议结构示意图；

图2是根据现有技术中的PC和UE的交互过程示意图；

图3是根据现有技术中的TCP发送速率和空口速率相对匹配时的TCP序列示意图；

图4是根据现有技术中的空口速率较慢时的TCP序列示意图；

图5是根据本发明第一实施方式的数据流量的控制方法示意图；

图6是根据本发明第一实施方式的数据流量的控制方法流程图；

图7是根据本发明第一实施方式中的TCP header的结构示意图；

图8是根据本发明第一实施方式中的IP header的结构示意图；

图9是根据本发明第一实施方式中的空口速率较慢时的TCP序列示意图；

图10是根据本发明第三实施方式的用户终端的结构示意图。

具体实施方式

本发明的第一实施方式涉及一种数据流量的控制方法。在本实施方式中，在UE侧的高层中需要判断当前是否处于拥塞状态，比如说，可在UE协议栈高层中增加一个模块P，由该模块P判断本UE是否处于拥塞状态，并在处于拥塞状态时，指示PC侧暂停TCP包的发送，如图5所示。

具体地说，UE根据本UE内堆积的TCP包的情况，判断是否满足拥塞条件，一旦满足拥塞条件，则说明当前处于拥塞状态。此时，一旦收到来自网络侧的携带win字段的TCP包，则将TCP包中的通告窗口(win)字段置为0，其他参数都不改，递交给PC侧。由于PC侧TCP协议栈检测到接收端的通告窗口为0，则不会再发TCP包给UE侧。这样，就达到了PC侧和UE之间流控的效果。同时也不会影响PC侧TCP协议栈的正常处理。若UE检测到拥塞条件不再满足，则将来自网络侧的TCP包透传给PC侧应用。UE通过将从网络侧收到的TCP包中的通告窗口字段修改为0后，再将该TCP包传递给PC侧，实现拥塞状态下向PC侧指示暂停TCP包的发送。实现简单，不需要更改PC侧应用就可达到终端和PC之间流量控制的效果，具有极强的适应性。

具体流程如图6所示，在步骤601中，UE接收下行TCP包，也就是说，UE接收来自网络侧的TCP包。

接着，在步骤602中，UE判断当前是否处于拥塞状态。具体地说，可以在UE中预先设置一个拥塞门限值，并通过检测本UE内待发送的传输控制协议TCP包的堆积情况，判断当前堆积的TCP包是否达到了预设的拥塞门限值，如果达到了该拥塞门限值，则判定当前处于拥塞状态；如果未达到该拥塞门限值，则判定当前不处于拥塞状态。比如说，设定拥塞门限值为3，则如果当前堆积的TCP包大于或等于3，则判定当前处于拥塞状态。

如果在步骤602中，UE判定当前处于拥塞状态，则进入步骤603，如果在步骤602中，判定当前不处于拥塞状态，则进入步骤607，在步骤607中，UE将从网络侧收到的TCP包透传给PC侧。

在步骤603中，UE判断从网络侧收到的TCP包中是否携带通告窗口(win)字段。如果携带win字段，则进入步骤604；如果不携带win字段，则进入步骤607。

接着，在步骤604中，UE判断该win字段的值是否为0。如果该win字段的值不为0，则进入步骤605；如果该win字段的值为0，则进入步骤607。

在步骤605中，UE将该TCP包中win字段的值，修改为0。

接着，在步骤606中，UE将通告窗口字段修改后的TCP包传递给PC侧。

在本实施方式中，UE可根据TCP/IP包结构获取通告窗口win。本领域技术人员可以理解，TCP包由header(包头)和数据构成，TCP header由不少于20个字节构成，如图7所示。图7中的头长度表示以32比特为单位的TCP header的长度，A是一个比特，为“1”表示该TCP包包含一个ACK报文。第4行高16位的窗口(win)就是指通告窗口的大小，最小是0，最大可以取值为65535。IP包也由header部分和数据内容部分两部分构成。其中数据部分包括TCP包。IP header由至少20个字节构成，如图8所示。图8中的总长表示以字节为单位的IP包的总长度，头标长表示以32比特为单位的IP header的长度。因此，UE可通过以下方式，获取所述TCP包中的通告窗口字段：通过对从网络侧收到的IP包的包头解析，判断该包是否为TCP包。如果判定为TCP包，则通过对该TCP包的包头解析，获取通告窗口字段。UE在获取到win字段后，即可将win字段修改为0。

以预定的拥塞门限值为3(即堆积在UE的TCP包在达到3个时就判定处于拥塞状态)为例，本实施方式中在空口速率较慢时的TCP序列如图9所示：当UE从网络侧收到(Seq＝0，ACK＝1024，win＝32768)的TCP包后，因为当时UE已从PC侧收到过5个TCP包，只发送出去2个。于是模块P判断达到了拥塞条件，将从网络侧收到的这个TCP包(Seq＝0，ACK＝1024，win＝32768)中的win改为0，其他参数不变，然后发给PC侧。PC侧的TCP/IP协议在收到win＝0的TCP包之后，按照协议将立即停止发送TCP包。UE继续分段发送堆积在协议栈内部的TCP包，在堆积的TCP包小于3个时，判定不满足拥塞条件。UE收到(Seq＝0，ACK＝2048，win＝32768)的TCP包，又因此时拥塞条件不再满足，于是UE透传此TCP包给PC侧。PC侧收到这条win不为0的消息之后，得到接收窗口不为0，则重新开始发送新的TCP包。之后的过程类似。

不难发现，在本实施方式中，由于UE通过对协议栈内部拥塞情况进行监控，当处于拥塞状态时(即出现TCP包不能及时通过空口发送的情况)，随时指示PC侧不再发数据，因此在拥塞状态时PC侧就不会再产生多余的TCP重传包，保证了TCP包的发送速率与空口速率能较好地匹配，使得TCP应用能适应无线***资源的快速变化，从而有效利用了无线资源。

而且，UE在收到TCP包后，如果根据TCP包的堆积情况，判定处于拥塞状态，则将TCP header窗口部分的16个比特置0；如果根据TCP包的堆积情况，判定不处于拥塞状态，则就透传数据不做处理。进一步保证了TCP应用能适应了线***资源的快速变化，使得空口资源得到合理使用。

本发明的第二实施方式涉及一种数据流量的控制方法。第二实施方式与第一实施方式大致相同，主要区别之处在于：在第一实施方式中，UE中只存在一个TCP连接(即从PC侧收到的TCP包具有相同的socket对)。而在本发明第二实施方式中，UE中存在多个TCP连接。因此，在本实施方式中，可根据socket优先级的不同，来决定是否需要进入流控以及需要把哪些应用(socket)的通告窗口置为0。

比如说，UE中存在2个TCP连接，分别对应socket1和socket2。socket1用来进行上行FTP传输，实时性要求低，优先级低一些；socket2用来进行web浏览，实时性要求高，优先级高一些。如果在业务进行过程中，UE的发送队列设定两个拥塞门限值T1和T2。其中T1是针对socket1设置的拥塞门限值，T2是针对socket2设置的拥塞门限值，T1要小于T2，因为socket1的优先级小于优先级小于socket2。

当发送缓存的容量开始达到T1的时候，这时需要进行流控，就是先对优先级低的，即对socket1进行流控，UE就应该产生针对socket1的通告窗口为0的控制包。当PC侧收到这个通告窗口为0的控制包后，socket1的上行传输会暂停，而socket2的上行传输继续。当发送缓存的容量开始达到T2的时候，终端再产生针对socket2的通告窗口为0的控制包，当PC侧收到这个通告窗口为0的控制包后，socket2的上行传输会暂停。

也就是说，如果在UE中存在至少两个TCP连接，则UE根据各TCP连接的不同优先级，为各TCP连接设置不同的拥塞门限值，其中，为优先级越低的TCP连接，设置越低的拥塞门限值。通过将不同优先级的TCP连接采用不同策略的流控机制，既保证了终端的发送缓存不会溢出，又能够使高优先级的应用数据有更大的概率发送出去。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包含相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第三实施方式涉及一种用户终端，如图10所示，包含：

检测模块，用于检测待发送的TCP包的堆积情况；

门限设定模块，用于预先设定拥塞门限值；

状态判断模块，用于根据该检测模块检测到的TCP包的堆积情况，判断用户终端UE是否处于拥塞状态。该状态判断模块在根据TCP包的堆积情况，判断UE是否处于拥塞状态时，将堆积的TCP包与门限设定模块设定的拥塞门限值(如3个TCP包)进行比较，在堆积的TCP包达到设定的拥塞门限值时，判定处于拥塞状态；

流量控制模块，用于在该状态判断模块判定处于拥塞状态时，指示PC侧暂停TCP包的发送。

其中，流量控制模块包含以下子模块：通告窗口修改子模块，用于将从网络侧收到的TCP包中的通告窗口字段修改为0；传递子模块，用于将通告窗口字段修改后的TCP包传递给PC侧；透传子模块，用于在该状态判断模块判定不处于拥塞状态时，将从网络侧收到的TCP包直接透传给PC侧；通告窗口字段判断子模块，用于在该状态判断模块判定处于拥塞状态时，判断从网络侧收到的TCP包中是否携带通告窗口字段，在判定为携带通告窗口字段时，指示通告窗口修改子模块将从网络侧收到的TCP包中的通告窗口字段修改为0，在判定为不携带通告窗口字段时，指示透传子模块将从网络侧收到的TCP包直接透传给PC侧。

通告窗口修改子模块通过包含以下子模块，获取TCP包中的通告窗口字段：TCP包确定子模块，用于通过对从网络侧收到的IP包的包头解析，判断该包是否为TCP包；TCP包头解析子模块，用于对判定为TCP包的包头进行解析，获取通告窗口字段。

不难发现，本实施方式为与第一实施方式相对应的***实施例，本实施方式可与第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明第四实施方式涉及一种用户终端。第四实施方式与第三实施方式大致相同，主要区别之处在于：在第三实施方式中，UE中只存在一个TCP连接(即从PC侧收到的TCP包具有相同的socket对)。而在本发明第四实施方式中，UE中存在多个TCP连接。因此，在本实施方式中，可根据socket优先级的不同，来决定是否需要进入流控以及需要把哪些应用(socket)的通告窗口置为0。

也就是说，门限设定模块在UE中存在至少两个TCP连接时，根据各TCP连接的不同优先级，为各TCP连接设置不同的拥塞门限值；其中，为优先级越低的TCP连接，设置越低的拥塞门限值。

不难发现，本实施方式为与第二实施方式相对应的***实施例，本实施方式可与第二实施方式互相配合实施。第二实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第二实施方式中。

上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (16)

1.一种数据流量的控制方法，其特征在于，包含以下步骤：

用户终端UE检测本UE内待发送的传输控制协议TCP包的堆积情况，并根据所述TCP包的堆积情况，判断所述UE是否处于拥塞状态；

如果所述UE判定处于拥塞状态，则所述UE指示个人计算机PC侧暂停TCP包的发送。

2.根据权利要求1所述的数据流量的控制方法，其特征在于，所述UE指示PC侧暂停TCP包的发送的步骤中，包含以下子步骤：

所述UE将从网络侧收到的TCP包中的通告窗口字段修改为0；

所述UE将所述通告窗口字段修改后的TCP包传递给所述PC侧。

3.根据权利要求2所述的数据流量的控制方法，其特征在于，还包含以下步骤：

当所述UE根据TCP包的堆积情况，判定所述UE不处于拥塞状态时，将从网络侧收到的TCP包直接透传给所述PC侧。

4.根据权利要求2所述的数据流量的控制方法，其特征在于，所述UE通过以下方式，获取所述TCP包中的通告窗口字段：

通过对从网络侧收到的IP包的包头解析，判断该包是否为TCP包；

如果判定为TCP包，则通过对该TCP包的包头解析，获取所述通告窗口字段。

5.根据权利要求2所述的数据流量的控制方法，其特征在于，在所述UE判定处于拥塞状态的步骤之后，指示PC侧暂停TCP包的发送的步骤之前，还包含以下步骤：

所述UE判断从网络侧收到的TCP包中是否携带通告窗口字段；

如果所述UE判定携带通告窗口字段，则再进入所述指示PC侧暂停TCP包的发送的步骤；如果所述UE判定不携带通告窗口字段，则将从网络侧收到的TCP包直接透传给所述PC侧。

6.根据权利要求1至5中任一项所述的数据流量的控制方法，其特征在于，所述根据TCP包的堆积情况，判断所述UE是否处于拥塞状态的步骤中，包含以下子步骤：

如果堆积的TCP包达到预定的拥塞门限值，则判定处于拥塞状态。

7.根据权利要求6所述的数据流量的控制方法，其特征在于，所述拥塞门限值为3。

8.根据权利要求6所述的数据流量的控制方法，其特征在于，如果在所述UE中存在至少两个TCP连接，则所述UE根据各TCP连接的不同优先级，为各TCP连接设置不同的拥塞门限值；

其中，为优先级越低的TCP连接，设置越低的拥塞门限值。

9.一种用户终端，其特征在于，包含：

检测模块，用于检测待发送的传输控制协议TCP包的堆积情况；

状态判断模块，用于根据所述检测模块检测到的TCP包的堆积情况，判断所述用户终端UE是否处于拥塞状态；

流量控制模块，用于在所述状态判断模块判定处于拥塞状态时，指示个人计算机PC侧暂停TCP包的发送。

10.根据权利要求9所述的用户终端，其特征在于，所述流量控制模块包含以下子模块：

通告窗口修改子模块，用于将从网络侧收到的TCP包中的通告窗口字段修改为0；

传递子模块，用于将所述通告窗口字段修改后的TCP包传递给所述PC侧。

11.根据权利要求10所述的用户终端，其特征在于，所述流量控制模块还包含透传子模块，用于在所述状态判断模块判定不处于拥塞状态时，将从网络侧收到的TCP包直接透传给所述PC侧。

12.根据权利要求10所述的用户终端，其特征在于，所述通告窗口修改子模块通过包含以下子模块，获取所述TCP包中的通告窗口字段：

TCP包确定子模块，用于通过对从网络侧收到的IP包的包头解析，判断该包是否为TCP包；

TCP包头解析子模块，用于对判定为TCP包的包头进行解析，获取所述通告窗口字段。

13.根据权利要求10所述的用户终端，其特征在于，所述流量控制模块还包含以下子模块：

通告窗口字段判断子模块，用于在所述状态判断模块判定处于拥塞状态时，判断从网络侧收到的TCP包中是否携带通告窗口字段；

所述通告窗口字段判断子模块在判定为携带通告窗口字段时，指示所述通告窗口修改子模块将从网络侧收到的TCP包中的通告窗口字段修改为0；在判定为不携带通告窗口字段时，指示所述透传子模块将从网络侧收到的TCP包直接透传给所述PC侧。

14.根据权利要求9至13中任一项所述的用户终端，其特征在于，所述用户终端还包含门限设定模块，用于预先设定拥塞门限值；

所述状态判断模块在根据TCP包的堆积情况，判断UE是否处于拥塞状态时，将堆积的TCP包与所述门限设定模块设定的拥塞门限值进行比较，在堆积的TCP包达到所述拥塞门限值时，判定处于拥塞状态。

15.根据权利要求14所述的用户终端，其特征在于，所述拥塞门限值为3。

16.根据权利要求14所述的用户终端，其特征在于，所述门限设定模块在所述UE中存在至少两个TCP连接时，根据各TCP连接的不同优先级，为各TCP连接设置不同的拥塞门限值；

其中，为优先级越低的TCP连接，设置越低的拥塞门限值。

Images