数据传输方法与流程

文档序号:11139825阅读:1144来源:国知局
数据传输方法与制造工艺

本发明涉及通信技术领域,特别涉及一种数据传输方法。



背景技术:

上下行并发时,上行业务的上行方向TCP(传输控制协议)数据包发送会干扰下行业务触发的上行方向TCP ACK(确认)包的发送,导致TCP ACK包发送延时加大,则TCP RTT(往返传输时间)时延增大,相应下行速率下降;若TCP ACK包发送延时抖动,则TCP RTT时延抖动,相应下行速率抖动。其中,TCP数据包和TCP ACK包的传送过程如图1所示,101为TCP数据包,102为TCP ACK包。

UE(终端)的上行方向TCP ACK包和TCP数据包都缓存在发送队列中,需要得到网络侧的资源调度UL GRANT(上行授权)之后才能进行发送。在得到网络侧资源调度UL GRANT之前,对于缓存的TCP ACK包和TCP数据包有2种处理方式:

(1)不做预处理,等收到网络侧资源调度ULGRANT之后,再进行数据链路层的协议处理。

(2)做一部分预处理,这样,等收到网络侧资源调度UL GRANT之后,发送数据包时可以减少协议处理开销,有助于满足实时性要求。

方式(1)的缺陷在于对UE的处理能力要求高,通常无法满足在一次网络侧资源调度UL GRANT上处理与发送大量TCP ACK包的实时要求。

方式(2)的缺陷在于数据链路层的分组数据汇聚子层(PDCP)处理时 会给每个包(上行TCP数据包和TCP ACK包)按序编号与加密,网络侧对等层也必须按序递交,因此如果数据链路层已有经过分组数据汇聚子层(PDCP)预先处理的,并等待发送的包,则后续发往分组数据汇聚子层PDCP的TCP ACK包不能优先于这些包进行发送。

然而,已预处理包的发送有2个问题:(1)得到空口调度资源UL GRANT的调度时间是不确定的,如果L2(Layer 2,协议栈第二层)预处理数据过早,则晚于预处理时间点,但早于得到空口调度资源UL GRANT时间点的,新的TCP ACK包不能优先于已预处理的包在该UL GRANT上发送,而是要等到再下一次得到空口调度资源UL GRANT时才有可能发送。(2)网络分配的空口调度资源UL GRANT的大小是不确定的,很可能和已经预处理的包的累加总长不匹配,如果预处理的包累加总长过大,本次空口调度资源UL GRANT发不完,则导致新的TCP ACK包在下一次得到空口调度资源UL GRANT时,不能优先于本次UL GRANT发剩下的已预处理的包,可能需要延迟到再下一次得到空口调度资源UL GRANT时发送;而如果预处理的包总长过小,则本次UL GRANT会有部分资源被浪费。



技术实现要素:

本发明解决的问题在于提供一种数据传输方法,使得数据传输方法。

为解决上述技术问题,本发明的实施方式提供了一种数据传输方法,包含以下步骤:

终端侧在得到网络侧资源调度的上行授权UL GRANT之前,对上行包中的全部传输控制协议TCP确认ACK包与部分TCP数据包进行预处理,在得到所述UL GRANT之后,实时处理所述上行包中剩余的TCP数据包。

本发明实施方式相对于现有技术而言,是在上下行并发时,终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,先对上行包中的全部TCP ACK包与部分TCP数据包进行预处理,在得到UL GRANT之后,再实时处理上行包中剩余的TCP数据包。采用上述技术方案可以消除发送TCP数据包对发送TCP ACK包的干扰,使得上行业务不影响下行业务速率。

进一步地,在所述对上行包中的全部TCP ACK包与部分TCP数据包进行预处理的步骤中,包含以下子步骤:若所述上行包为TCP ACK包,则进行预处理;若所述上行包为TCP数据包,则存入缓存队列中;其中,所述缓存队列为先入先出FIFO缓存队列;根据预先设置的TCP数据包预处理门限、已预处理的包总长、上一次网络侧分配的UL GRANT的大小,计算待预处理的TCP数据包的长度N;判断所述N值的正负;若N为正值,则从所述缓存队列中取出长度为N的TCP数据包,并进行预处理。参考上一次网络侧分配的UL GRANT的大小,对TCP ACK包与部分TCP数据包进行预处理,这样,可以尽量避免本次网络侧分配的UL GRANT的大小与预处理的TCP ACK包与部分TCP数据包的总包长不匹配的问题,进而,既可以避免新的TCP ACK包延迟发送,又可以避免本次UL GRANT部分资源被浪费。

另外,在所述计算待预处理的TCP数据包的长度的步骤之前,包含以下步骤:根据终端的中央处理器CPU的处理能力设置TCP数据包预处理门限。根据终端的处理能力设置TCP数据包预处理门限,对部分TCP数据包进行预处理,这样,可以避免“处理能力较低的终端无法满足在一次网络侧资源调度UL GRANT上处理与发送大量TCP ACK包的实时要求”的问题。

附图说明

图1是现有技术中TCP数据包和TCP ACK包的传送过程示意图;

图2是本发明第一实施方式的数据传输方法具体流程图;

图3是本发明第一实施方式的数据传输方法中预处理流程示意图;

图4是本发明第一实施方式的数据传输方法中实时处理流程示意图;

图5是本发明第二实施方式的数据传输方法中预处理流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明的各实施方式进行详细的阐述。然而,本领域的普通技术人员可以理解,在本发明各实施方式中,为了使读者更好地理解本申请而提出了许多技术细节。但是,即使没有这些技术细节和基于以下各实施方式的种种变化和修改,也可以实现本申请各权利要求所要求保护的技术方案。

本发明的第一实施方式涉及一种数据传输方法,具体流程如图2、3、4所示;其中,图2是数据传输方法的具体流程图,图3是终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,对TCP ACK包与部分TCP数据包进行预处理的流程示意图,图4为在得到UL GRANT之后,实时处理上行包中剩余的TCP数据包的流程示意图。

在本实施方式中,数据传输方法包含以下步骤:

步骤201,在终端侧在得到网络侧资源调度的UL GRANT(上行授权)之前,将全部TCP ACK包进行预处理,将TCP数据包存入缓存队列。具体地说,在本步骤中,先检测是否接收到网络侧的UL GRANT,若未接收到网络侧的UL GRANT,则将全部TCP ACK包进行预处理,并将TCP数据包存入缓存队列,接着,进入步骤202,否则,执行步骤203。

步骤202,从缓存队列中取出一部分TCP数据包进行预处理。

步骤203,在收到UL GRANT之后,扣除已预处理包的总长度,按剩余长度从缓存队列中取出TCP数据包进行处理。在本步骤中,是从缓存队列中取出长度等于UL GRANT剩余长度的TCP数据包进行处理。

这样,在上下行并发时,终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,先对上行包中的全部TCP ACK包与部分TCP数据包进行预处理,在得到UL GRANT之后,再实时处理上行包中剩余的TCP数据包。这样,可以消除发送TCP数据包对发送TCP ACK包的干扰,使得上行业务不影响下行业务速率。

以上对本实施方式中的数据传输方法从整体上进行了介绍,下面分别对图3所示的预处理与图4所示的实时处理分别进行介绍。

首先,介绍终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,对TCP ACK包与部分TCP数据包进行的预处理过程,具体包含以下步骤:

步骤301,从TCP\IP模块接收上行包。其中,上行包包含TCP数据包与TCP ACK(确认)包。

步骤302,判断上行包是否配置了头压缩。若是,则执行步骤303,否则,执行步骤304。

步骤303,进行头压缩处理。其中,终端侧执行头压缩处理,而网络侧执行解压缩处理。

步骤304,检测上行包的类型。

步骤305,根据检测结果判断上行包是否为TCP ACK包。若是,则执行步骤310,否则,执行步骤306。

步骤306,存入FIFO(先入先出)缓存队列。先存入缓存队列中的数据也可以先被取出,这样,可以保证先存入缓存队列的数据也可以优先发送,保证了数据发送的有序性。

步骤307,计算待预处理的TCP数据包的长度(N)。在本步骤中,根据预先设置的TCP数据包预处理门限、已预处理的包总长、上一次网络侧分 配的UL GRANT的大小,计算待预处理的TCP数据包的长度;其中,TCP数据包预处理门限是终端在收到UL GRANT之后能够在规定时间内处理的TCP数据包的最大长度。具体而言,可以根据如下关系式计算待预处理的TCP数据包的长度:

待预处理的TCP数据包的长度=上一次网络侧分配的UL GRANT的大小-已预处理的包总长-TCP数据包预处理门限;

其中,已预处理的包总长是预处理的所有TCP ACK包的长度之和。参考上一次网络侧分配的UL GRANT的大小,作为对TCP ACK包与部分TCP数据包进行预处理的依据,这样,可以尽量避免本次网络侧分配的UL GRANT的大小与预处理的TCP ACK包与部分TCP数据包的总包长不匹配的问题,进而,既可以避免新的TCP ACK包延迟发送,又可以避免本次UL GRANT部分资源被浪费。

步骤308,判断待预处理的TCP数据包的长度(N)是否为正值。若是,则执行步骤309,否则,执行步骤301。具体而言,若N为零或者负值,则不对TCP数据包进行预处理,直接返回步骤301,继续从TCP\IP模块接收上行包,开始新一轮的循环。

步骤309,从FIFO缓存队列取TCP数据包。由于先缓存入FIFO缓存队列中的数据本应该优先发送,所以,从FIFO缓存队列取TCP数据包时遵循先进先出的原则,这样,可以保证数据发送的顺序有条不紊。

步骤310发给数据链路层进行预处理。在本步骤中,对接收的TCP ACK包、TCP数据包进行加密、加PDCP(分组数据会聚协议)包头等处理。终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,对TCP ACK包与部分TCP数据包进行加密、加PDCP(分组数据会聚协议)包头等处理,这样,在收到上行授权之后,到实际通过天线进行无线传输之间是一个非常短暂的时间片,在这个时间片上需要进行头压缩、数据包加密、PDCP协议 处理、RLC协议处理、MAC协议处理等一系列操作,如果这些操作未能在这个时间片上及时完成,则会浪费掉上行授权。而头压缩和加密等相关操作实际上并不依赖上行授权参数,可以提前处理,这样在时间片上的操作减小,超时后浪费上行授权的可能性下降。

以上介绍了终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,对TCP ACK包与部分TCP数据包进行的预处理过程,下面介绍终端侧在得到UL GRANT之后,实时处理上行包中剩余的TCP数据包的过程,具体包含以下步骤:

步骤401,终端侧接收网络侧资源调度的UL GRANT。

步骤402,取出预处理包。

步骤403,判断UL GRANT是否有剩余。若是,则执行步骤404,否则,执行步骤406。具体地说,在本步骤中,包含以下子步骤:

4031,将本次网络侧分配的UL GRANT的大小减去已预处理的包总长,得到,UL GRANT的剩余长度值(M)。其中,此处所述的已预处理的包总长是预处理的TCP ACK包与TCP数据包的包长之和。

4032,判断M值的正负。其中,若检测结果是M值为正,则判定UL GRANT有剩余;否则,判定UL GRANT无剩余,即若M为零或者负值,判定UL GRANT无剩余。

步骤404,从FIFO缓存队列取TCP数据包。同样,从FIFO缓存队列取TCP数据包时遵循先进先出的原则,这样,可以保证数据发送的顺序有条不紊。

步骤405,发给数据链路层进行实时处理。在本步骤中,对取出的TCP数据包进行加密、加PDCP(分组数据会聚协议)包头等处理。

步骤406,根据UL GRANT构造组包并发送。组包过程是现有技术,具 体参见36.321、36.322、36.323中第五章节相关的协议处理,在此不再赘述。

与现有技术相比,在是在上下行并发时,终端侧在得到网络侧资源调度的上行授权(UL GRANT)之前,先检测上行包的类型,然后按照上行包的类型分别进行处理:将全部TCP ACK包发送到数据链路层并直接进行预处理,而将全部TCP数据包存入缓存队列;接着,根据预设的参数,从缓存队列中将部分TCP数据包取出,进行预处理;终端侧在得到网络侧资源调度的上行授权(UL GRANT)之后,扣除已预处理的包的总长度,按剩余长度从缓存队列中取出剩余的TCP数据包进行实时处理。由于TCP ACK包比TCP数据包的容量小得多,对全部TCP ACK包优先进行处理,可以消除发送TCP数据包对发送TCP ACK包的干扰,使得上行业务不影响下行业务速率,又不影响TCP数据包的处理与发送。

下面举例说明,假定有1ms无线子帧的时隙序列{T0,T1,T2,…Tn},其中上行UL GRANT每5ms调度一次,调度序列为{T1,T6,T11,T16…Tn1,Tn6},每次UL GRANT的大小为1500Bytes;每个上行TCP数据包大小为1500Bytes;每个上行TCP ACK大小为50Bytes;为简单计算,若不计L2包头开销,则一个UL GRANT一次可以发送1个TCP数据包或者30个TCP ACK。假定在T2时隙收到3个TCP数据包,在T3时隙收到30个TCP ACK。

若按现有技术中的常规方式按时间序列处理,在T6,T11,T16上发送TCP数据包,在T21上发送TCP ACK,则TCP ACK被延迟了21-3=18ms;

若按本方案实施,假定TCP数据包预处理门限为1500Bytes,则T2上的TCP数据包被缓存,T3上的TCP ACK被预处理,并在T6上发送,则TCP ACK被延迟了6-3=3ms。即在本实施方式中,可以消除发送TCP数据包对发送TCP ACK包的干扰。

本发明的第二实施方式涉及一种数据传输方法。第二实施方式在第一实施方式的基础上作了进一步改进,主要改进之处在于:在本发明第二实施方式中,在计算待预处理的TCP数据包的长度之前,根据终端的CPU的处理能力设置TCP数据包预处理门限,这样,可以避免“处理能力较低的终端无法满足在一次网络侧资源调度UL GRANT上处理与发送大量TCP ACK包的实时要求“的问题。

具体地说,本实施方式中,在得到UL GRANT之后,实时处理上行包中剩余的TCP数据包的流程与第一实施方式中的相同,再次不再赘述;终端侧在得到UL GRANT之前,对TCP ACK包与部分TCP数据包进行预处理的流程如图5所示,其中,步骤502~511分别与第一实施方式中的步骤301~310分别相似,在此不再赘述。

步骤501,根据终端的中央处理器(CPU)的处理能力设置TCP数据包预处理门限。不同终端CPU的处理能力可能各不相同,在计算待预处理的TCP数据包的长度之前,先根据终端的CPU的处理能力设置TCP数据包预处理门限,再根据TCP数据包预处理门限计算待预处理的TCP数据包的长度,这样,可以针对不同的终端预处理不同长度的TCP数据包,这样,可以避免“处理能力较低的终端无法满足在一次网络侧资源调度UL GRANT上处理与发送大量TCP ACK包的实时要求“的问题。

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

本领域的普通技术人员可以理解,上述各实施方式是实现本发明的具体 实施例,而在实际应用中,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1