利用蜂窝网络中的尾巴时间进行数据传输的方法

摘要

本发明涉及利用蜂窝网络中的尾巴时间进行数据传输的方法，属于计算机网络通讯技术领域，该方法包括不断地接收移动终端的数据传输请求，并将这些请求按照类型分别放入到实时请求队列和可延迟请求队列中；根据无线资源控制协议状态机的状态和吞吐量，判断能够进行尾巴时间传输的时间，根据请求的类型从实时请求队列或者可延迟请求队列中，取出一个请求进行处理，并发送到网络；所述数据传输请求分为实时请求和可延迟请求两类；还包括通过修改移动终端的数据传输请求提交接口实现请求的分类；该修改移动终端的数据传输请求提交接口为在原接口的基础上增加两个参数：请求传输数据的类型和可延迟时间。

说明书

技术领域

本发明属于计算机网络通讯技术领域，特别涉及一种利用蜂窝网络中的尾巴时间来进 行数据传输，延长手机等移动终端电池续航时间的方法。

背景技术

随着社会和技术的不断发展进步，手机等移动终端变的越来越普遍。据统计全球大约 有68亿的手机用户。在众多的手机中，基于Android和iOS等操作系统的智能手机变得越 来越受欢迎。它们为人们提供功能丰富的各式各样的应用程序，使得人们的生活和工作更 加方便快捷。但是智能手机等移动终端的一个很大的问题是有限的电池续航能力。这不仅 大大影响了用户体验，还延缓了更多功能丰富的应用程序的出现。

在蜂窝网络中，无线资源已经被证明是移动终端电能的最大消耗者。然而在这些被消 耗的电能中，有超过60%是来自不活动计时器的超时时间。这些不活动计时器被用来控制 无线资源的释放。对应着不活动计时器的超时时间被称为尾巴时间。尾巴时间的设计是为 了在无线资源、用户体验、能量消耗和网络开销之间寻求平衡。但是，尾巴时间却带来无 线资源以及移动终端电能的浪费。以3G网络通用移动通信系统（UMTS，Universal Mobile  Telecommunications System）为例来说。为了更有效地使用无线资源，通用移动通信系统 引入无线资源控制（RRC，Radio Resource Control）协议。无线资源控制协议为手机和无 线网络控制器（RNC，Radio Network Controller）维护一个共同的状态机。在状态机的不 同状态，手机消耗不同等级的电池能量。在数据被传输之前，状态机的状态被提升到高能 量状态。需要注意的是状态提升不仅需要消耗一定的能量，还会给用户带来一定的延迟。 当数据传输结束之后，状态机的状态并没有被立即降低到低能量状态。状态机根据网络控 制的不活动计时器等待一定的时间（尾巴时间，约15秒）。在这段时间内并没有数据传输， 但是移动终端一直处在高能量状态，因此会带来移动终端电能的浪费。

图1给出了通用移动通信系统网络中无线资源控制协议状态机的示意图。无线资源控 制协议状态机拥有三种不同的状态：专用信道（DCH，Dedicated Channel）状态、前向接 入信道(FACH，Forward Access Channel)状态和空闲（IDLE）状态。其中专用信道状态和 前向接入信道状态是处于连接状态，在这两种状态下移动终端可以进行数据传输；而在空 闲状态不能进行数据传输。此外，三种不同的状态对应着不同的能量消耗，专用信道状态 消耗最多的能量。当移动终端有数据需要发送或者接收时，无线资源控制协议状态机从空 闲状态上调到专用信道状态；因为这个上调过程需要向无线网络控制器申请资源，因此需 要消耗一定的时间（状态上调时间，约2秒）。当数据传输完毕后，无线网络控制器启动 一个不活动计时器α（对应着时间T₁）。当计时器α超时时，状态机从专用信道状态下调到 前向接入信道状态。在前向接入信道状态，无论是上行链路，还是下行链路方向中任何一 个方向的缓冲区消耗超过无线网络控制器设定的界限值，无线资源控制协议状态机的状态 都会被从前向接入信道状态上调到专用信道状态。如果在前向接入信道状态下仍然没有数 据传输，无线网络控制器启动另外一个不活动计时器β（对应着时间T₂）。当计时器β超时 时，无线资源控制协议状态机的状态被下调到空闲状态。此外，从专用信道状态，可以通 过快速休眠的方式下调到空闲状态。

为了解决因蜂窝网络中尾巴时间引起移动终端电能浪费的问题，研究人员提出了很多 优化方法。根据这些方法处理尾巴时间方式的不同，可以把它们分为两类：流量聚合法和 尾巴时间调整法。流量聚合方法根据流量的模式把小的传输聚合成大的连续传输，从而减 少尾巴时间发生的次数和传输数据所消耗的电能，例如TailEnder（参见Naianjan  Balasubramanian等，于2009年发表在Internet Measurement Conference的文章：Energy  Consumption in Mobile Phones：A Measurement Study and Implications for Network  Applications）等。对于可延迟应用（例如，邮件，RSS等）和可预取应用（例如，新闻和 视频等），可以通过延迟或者预取的方式实现流量聚合。但是，如果可预取应用的预取准 确率很低时，流量聚合方法不仅不能减少电能消耗，反而有可能增加电能消耗。例如，当 预取的数据只有很小一部分是应用程序真正需要时，流量聚合只减少了很小一部分的尾巴 时间，但是却在预取操作本身上消耗了很高的电能。另外一类方法，尾巴时间调整法希望 在浪费在尾巴时间中的能量与能量状态上调带来的延迟之间寻找一个平衡点。这类方法中 一大部分方法都希望找到一个合适长度的尾巴时间，但是即便设置了一个合理长度的尾巴 时间，尾巴时间依然存在并且依然带来相当可观的电能浪费。最新的一种尾巴时间调整方 法，TOP（参见Feng Qian等，于2010年发表于IEEE International Conference on Network  Protocols的文章：TOP：Tail Optimization Protocol for Cellular Radio Resource Allocation）， 它利用了一种快速休眠（fast dormancy）机制动态地终止尾巴时间。当TOP预测到在未来 的一段时间内没有数据需要传输时，它把状态机的状态快速下调到低能量状态。但是，TOP 的有效性依赖于预测未来流量模式的准确率。很低的预取准确率会带来额外的状态上调， 从而带来更多的能量浪费。

总结来说，在蜂窝网络中尾巴时间消耗了很大一部分的移动终端电能，通过优化尾巴 时间机制可以带来移动终端电池续航能力的提升。但是，已有的尾巴时间优化方法在一些 情况下不仅不能够节省移动终端的电能，反而有可能增加电能消耗。

发明内容

本发明的目的是为克服已有方法的不足之处，提出一种利用蜂窝网络中的尾巴时间进 行数据传输的方法。通过有效地利用尾巴时间，不仅能够实现更好的节能效果，有效地延 长移动终端的电池续航时间，还克服了已有方法存在的可能增加电能消耗的不足。

本方法主要基于以下原理：在蜂窝网络中，尾巴时间带来了移动终端很大一部分的电 能浪费。如果能够把这部分空闲的尾巴时间利用起来，移动终端的电池续航时间将能够得 到有效的延长。本发明把调整数据传输请求被传输的时间和先后顺序称为请求调度；请求 调度接收数据传输请求，然后经过处理之后再把数据传输请求传输出去。在移动终端设备 上，有很大一部分数据传输请求是可延迟的（例如，邮件发送请求等）或者是可预取的（例 如，新闻条目等）。通过延迟和预取操作，这部分数据传输请求可以被调度到空闲的尾巴 时间中，从而使得尾巴时间被利用起来。

本发明利用蜂窝网络中空闲的尾巴时间传输可延迟的或者可预取的数据，来节省移动 终端（例如，手机等）在数据通讯过程中所消耗的电能，从而有效地延长移动终端的电池 续航时间。这种利用尾巴时间的方法可以节省移动终端的电能主要是因为：（1）原本空闲 的尾巴时间被有效地利用起来了；（2）延迟操作和预取操作可以缩短数据传输的总体时间， 以及减少状态上调产生的次数。因为是利用原本空闲的尾巴时间，所以即使在预取操作的 准确率很低时，和原始的方法相比，这种方法也不会带来能量消耗的增加，从而有效地克 服了增加电能消耗的风险。

本发明提出的利用蜂窝网络中的尾巴时间进行数据传输的方法，完成在尾巴时间中进 行数据传输；该方法不断地接收移动终端的数据传输请求，并将这些请求按照类型分别放 入到实时请求队列和可延迟请求队列中；然后，根据无线资源控制协议状态机的状态和吞 吐量，判断能够进行尾巴时间传输的时间，并且根据请求的类型从实时请求队列或者可延 迟请求队列中，取出一个请求进行处理，并发送到网络。

本方法将移动终端上的数据传输请求分为两类：实时请求和可延迟请求。其中，可延 迟请求包括可延迟应用的可延迟请求和可预取应用的预取请求（因为预取操作可以根据需 要被推迟，所以预取请求的预取时刻是可延迟，因此把可预取应用的预取请求也归类为可 延迟请求）。

本方法通过修改移动终端的数据传输请求提交接口实现请求的分类。在原接口的基础 上增加两个参数：请求传输数据的类型和可延迟时间。

本方法设置三个计时器θ、γ和δ；每个计时器均拥有三种状态：未启动，已启动未超 时和已启动并超时。其中，计时器θ是为了保证可延迟请求在它的最终期限之前被传输； 计时器γ和δ分别对应着无线资源控制协议状态机的专用信道状态和前向接入信道状态， 它们被用来判断能否在尾巴时间中进行数据传输。

本发明提出的利用蜂窝网络中的尾巴时间进行数据传输的方法，包括以下步骤：

步骤（1）：间隔发送两个数据包，测量需要的参数；这些参数包括：触发专用信道状 态到前向接入信道状态下调的吞吐量界限值、上行和下行链路缓冲区的界限值，以及上行 和下行链路缓冲区的消耗时间；

步骤（2）：不断地接收移动终端的数据传输请求，并且根据数据传输请求的类型，将 数据传输请求分别放入到实时请求队列和可延迟请求队列，同时根据接收的可延迟请求维 护计时器θ；

步骤（3）：根据移动终端的功率和吞吐量，持续不断地维护计时器γ和δ；根据这两个 计时器的状态，确定尾巴时间，从而执行在尾巴时间中进行数据传输；

步骤（4）：根据计时器θ、γ和δ的状态，不断地从实时请求队列或者可延迟请求队列 中取出请求进行处理，并发送到网络。

上述步骤（2）中，不断地接收移动终端的数据传输请求的具体步骤如下：

步骤（2.1）：接收一个数据传输请求，该数据传输请求包括请求传输的数据、请求传 输数据的类型和可延迟时间；

步骤（2.2）：判断接收的请求是否为实时请求，如果是实时请求，则执行步骤（2.3）， 否则执行步骤（2.4）；

步骤（2.3）：将接收的请求插入到实时请求队列的队尾；跳转至步骤（2.1）；

步骤（2.4）：判断计时器θ是否启动，如果已启动，则执行步骤（2.5），否则执行步骤 （2.6）；

步骤（2.5）：停止计时器θ；

步骤（2.6）：根据接收请求的可延迟时间和当前时间，计算出该请求的最终期限；按 照最终期限的远近从小到大的顺序将该请求插入到可延迟请求队列中；

步骤（2.7）：获取可延迟请求队列队首请求的最终期限，并根据该期限启动计时器θ； 跳转至步骤（2.1）；

上述步骤（3）中，根据移动终端的功率和吞吐量，持续不断地维护计时器γ和δ的具 体步骤如下：

步骤（3.1）：利用移动终端当前的功率推断当前无线资源控制协议状态机所处的状态；

步骤（3.2）：判断当前状态是否为专用信道状态，如果是，则执行步骤（3.3），否则执 行步骤（3.8）；

步骤（3.3）：判断当前的吞吐量是否小于触发从专用信道状态到前向接入信道状态的 界限值（该值在步骤（1）中测得），如果是，则执行步骤（3.4），否则跳转至步骤（3.6）；

步骤（3.4）：判断计时器γ是否启动，如果未启动，执行步骤（3.5），否则跳转至步骤 （3.14）；

步骤（3.5）：启动计时器γ，跳转至步骤（3.14）；

步骤（3.6）：判断计时器γ是否启动，如果已启动，执行步骤（3.7），否则跳转至步骤 （3.14）；

步骤（3.7）：停止计时器γ，跳转至步骤（3.14）；

步骤（3.8）：判断当前状态是否为前向接入信道状态，如果是，则执行步骤（3.9），否 则跳转至步骤（3.14）；

步骤（3.9）：判断当前的吞吐量是否等于0，如果是，则执行步骤（3.10），否则跳转 至步骤（3.12）；

步骤（3.10）：判断计时器δ是否启动，如果未启动，则执行步骤（3.11），否则跳转至 步骤（3.14）；

步骤（3.11）：启动计时器δ，跳转至步骤（3.14）；

步骤（3.12）：判断计时器δ是否启动，如果已启动，则执行步骤（3.13），否则跳转至 步骤（3.14）；

步骤（3.13）：停止计时器δ，跳转至步骤（3.14）；

步骤（3.14）：延迟一段时间（0秒～1秒），然后跳转至步骤（3.1）。

上述步骤（4）中，根据计时器θ、γ和δ的状态，不断地从实时请求队列或者可延迟 请求队列中取出请求进行处理，并发送到网络的具体步骤如下：

步骤（4.1）：判断计时器θ是否启动，如果已启动，则执行步骤（4.2），否则执行步骤 （4.3）；

步骤（4.2）：判断计时器θ是否超时，如果未超时，则执行步骤（4.3），否则执行步骤 （4.7）；

步骤（4.3）：判断实时请求队列中是否有请求，如果有，则执行步骤（4.4），否则执行 步骤（4.5）；

步骤（4.4）：取出实时请求队列队首的请求，传输该请求到网络；跳转至步骤（4.1）；

步骤（4.5）：判断能否进行尾巴时间传输，如果能，则执行步骤（4.6），否则跳转至步 骤（4.1）；

上述步骤（4.5）中判断能否进行尾巴时间传输的具体步骤如下：

步骤（4.5.1）：利用移动终端当前的功率推断当前无线资源控制协议状态机所处的状态；

步骤（4.5.2）：判断状态机的状态是否为专用信道状态，如果是，则执行步骤（4.5.3）， 否则执行步骤（4.5.4）；

步骤（4.5.3）：判断计时器γ是否被启动，如果已启动，则执行步骤（4.5.5），否则跳 转至步骤（4.1）；

步骤（4.5.4）：判断计时器δ是否被启动，如果已启动，则执行步骤（4.5.5），否则跳 转至步骤（4.1）；

步骤（4.5.5）：判断当前吞吐量是否等于0，如果是，则执行步骤（4.6），否则跳转至 步骤（4.1）；

步骤（4.6）：调度可延迟请求队列中的请求到尾巴时间中；

上述步骤（4.6）调度可延迟请求队列中的请求到尾巴时间的具体步骤如下：

步骤（4.6.1）：判断可延迟请求队列中是否有请求，如果没有，则执行步骤（4.6.2）， 否则执行步骤（4.6.3）；

步骤（4.6.2）：延迟T₃长度的一段时间。T₃可以设置为一个固定值或者动态地变化； 固定值可以通过统计网络中超过90%的请求与下一个请求之间的时间间隔获得；动态变化 的数值需要统计在最近的一段时间内，对应用户的数据传输请求特征；根据请求之间的时 间间隔动态地变化。在延迟结束后，跳转至步骤（4.6.11）；

步骤（4.6.3）：停止计时器θ；

步骤（4.6.4）：利用移动终端当前的功率推断当前状态机所处的状态；

步骤（4.6.5）：判断当前状态是否为专用信道状态，如果是，则执行步骤（4.6.6），否 则执行步骤（4.6.7）；

步骤（4.6.6）：执行在专用信道状态下的尾巴时间调度；

上述步骤（4.6.6）中，在专用信道状态下的尾巴时间调度步骤如下：

步骤（4.6.6.1）：判断计时器γ是否超时，如果未超时，则执行步骤（4.6.6.2），否则跳 转至步骤（4.6.10）；

步骤（4.6.6.2）：取出可延迟请求队列队首的请求，传输该请求到网络；然后跳转至步 骤（4.6.9）；

步骤（4.6.7）：判断当前状态是否为前向接入信道状态，如果是，则执行步骤（4.6.8）， 否则跳转至步骤（4.1）；

步骤（4.6.8）：执行在前向接入信道状态下的尾巴时间调度；

上述步骤（4.6.8）中，在前向接入信道状态下的尾巴时间调度的具体步骤如下：

步骤（4.6.8.1）：判断计时器δ是否超时，如果未超时，则执行步骤（4.6.8.2），否则跳 转至步骤（4.6.10）；

步骤（4.6.8.2）：取出可延迟请求队列队首的请求，传输该请求到网络，在传输请求数 据的时候，保证不触发从前向接入信道状态到专用信道状态的状态上调；然后执行步骤 （4.6.9）；

步骤（4.6.9）：根据可延迟请求队列队首请求的最终期限重启计时器θ；然后跳转到步 骤（4.6.1）；

步骤（4.6.10）：等待无线链路控制协议缓冲区被清空；根据步骤（1）中测得的上行和 下行链路缓冲区的大小，以及上行和下行链路缓冲区的消耗时间确定需要等待的时间；

步骤（4.6.11）：调用快速休眠机制下调状态；然后跳转至步骤（4.1）；

步骤（4.7）：直接处理可延迟请求队列队首的请求；如果可延迟请求队列中的请求在 到达最后可延迟期限之前仍然没有被调度，则不论当前状态机处于什么状态，该请求被直 接处理。

上述步骤（4.7）直接处理可延迟请求队列队首的请求的具体步骤如下：

步骤（4.7.1）：取出可延迟请求队列队首的请求；

步骤（4.7.2）：判断该请求是否为预取请求，如果是，则执行步骤（4.7.3），否则执行 步骤（4.7.4）；

步骤（4.7.3）：丢弃该请求；因为预取请求的预取操作可能失败，所以该请求在到达最 后期限时被直接丢弃；然后跳转至步骤（4.7.5）；

步骤（4.7.4）：传输该请求到网络；然后执行步骤（4.7.5）；

步骤（4.7.5）：根据可延迟请求队列队首请求的最终期限重启计时器θ；然后跳转到步 骤（4.1）；

本发明的特点及有益效果：

本发明把移动终端中的可延迟请求和预取请求调度到蜂窝通讯过程中的尾巴时间中， 实现了把空闲的尾巴时间利用起来效果，从而达到了节省移动终端电能的目的。

相比于已有的方法，本发明提出的利用尾巴时间节省移动终端电能的方法能够获取更 好的节能效果。另外，由于本发明是利用原本空闲的尾巴时间调度应用请求，所以即便在 预取操作的准确率很低时，该方法也不会带来能量消耗的增加，从而有效地克服了增加电 能消耗的风险。

附图说明

图1是通用移动通信系统网络中无线资源控制协议状态机的示意图；

图2是本实施例的总体流程图；

图3是本实施例中不断地接收数据传输请求（步骤2）的流程图；

图4是本实施例中持续不断地维护计时器γ和δ（步骤3）的流程图；

图5是本实施例中调度数据传输请求（步骤4）的流程图；

图6是本实施例中调度数据传输请求的过程中判断能否进行尾巴时间传输（步骤4.5） 的流程图；

图7是本实施例中调度数据传输请求中调度可延迟队列中的请求到尾巴时间中（步骤 4.6）的流程图；

具体实施方式

本发明提出了一种利用蜂窝网络中的尾巴时间进行数据传输的方法，结合附图和实施 例详细说明如下。

在手机等移动终端上应用包括邮件、新闻、视频、云盘、实时通讯、社交网络等。在 这些应用中，像邮件、云盘等应用的数据是可以被延迟的；如果能够有效地节省手机的电 能，用户是非常乐意将自己的邮件延迟发送一段时间的。像新闻、视频和社交网络等应用 可以根据用户的习惯提前预取一些用户可能需要的内容；本方法以一台Android手机作为 移动终端的实施例，以邮件作为可延迟应用，以新闻作为可预取应用，来说明如何在手机 上利用尾巴时间进行数据传输。

本实施例的手机配置如下：

硬件配置：型号：三星Galaxy SIII；CPU：三星Exynos4412；RAM：1GB；ROM： 16GB；3G网络类型：WCDMA。

软件配置：Android4.04。

本方法将移动终端上的数据传输请求分为两类：实时请求和可延迟请求。其中，可延 迟请求包括可延迟应用的可延迟请求和可预取应用的预取请求。在本实施例中可延迟应用 为邮件，可预取应用为新闻，因此可延迟请求包括邮件数据传输请求和新闻数据传输请求； 实时请求是除了可延迟请求之外的其他数据传输请求。在本实施例中，邮件数据传输请求 的可延迟时间设置为30分钟（可以根据用户自身的需求设置，不同的可延迟长度能够获 取不同的节能效果）；新闻数据被定期预取，在本实施例中设置三个预取时间段：分别是 早上7点、中午12点和下午6点（可以根据用户看新闻的时间设置），每个预取请求的预 取最终期限为60分钟。

本方法通过修改移动终端的数据传输请求提交接口实现请求的分类。本实施例以 Android手机系统为例，在手机中的原有接口的基础上增加了两个参数：请求传输数据的 类型r_type和可延迟时间r_delay。其中r_type和r_delay的初始值都为0。对于可延迟应 用的可延迟请求，r_type设置为1，r_delay设置为可延迟的时间；对于可预取应用的预取 请求，r_type应设置为-1，r_delay设置为预取的时间期限。

本实施例设置三个计时器θ、γ和δ；每个计时器均拥有三种状态：未启动，已启动未 超时和已启动并超时。其中，计时器θ是为了保证可延迟请求在它的最终期限之前被传输； 计时器γ和δ分别对应着无线资源控制协议状态机的专用信道状态和前向接入信道状态， 它们被用来判断能否在尾巴时间中进行数据传输。

本方法实施例的整体流程如图2所示，包括以下步骤：

步骤（1）：间隔发送两个数据包，测量需要的参数（参见Feng Qian等，于2011年发 表在The International Conference on Mobile Systems,Applications,and Services的文章： Profiling Resource Usage for Mobile Applications：A Cross-layer Approach）；这些参数包括： 触发专用信道状态到前向接入信道状态下调的吞吐量界限值、上行和下行链路缓冲区的界 限值，以及上行和下行链路缓冲区的消耗时间；表1中列出了本实施例测量获得的参数。

表1测得的参数

项目 数值（其中d为数据的大小） 触发专用信道状态到前向接入信 8kbps

道状态下调的吞吐量界限值   上行链路缓冲区界限值 540字节 下行链路缓冲区界限值 475字节 上行链路缓冲区消耗时间 0.0015d²+1.5d+20毫秒 下行链路缓冲区消耗时间 0.1d+10毫秒

步骤（2）：不断地接收移动终端的数据传输请求，并且根据数据传输请求的类型，将 数据传输请求分别放入到实时请求队列和可延迟请求队列，同时根据接收的可延迟请求维 护计时器θ；

步骤（3）：根据移动终端的功率和吞吐量，持续不断地维护计时器γ和δ；根据这两个 计时器的状态，确定尾巴时间，从而执行在尾巴时间中进行数据传输；

步骤（4）：根据计时器θ、γ和δ的状态，不断地从实时请求队列或者可延迟请求队列 中取出请求进行处理，并发送到网络。

上述步骤（2）中，不断地接收移动终端的数据传输请求的流程如图3所示，具体包括 以下步骤：

步骤（2.1）：接收一个数据传输请求，该数据传输请求包括请求传输的数据、请求传 输数据的类型r_type和可延迟时间r_delay；表2列出了本实施例中三种不同类型的请求， 以及这些请求对应的参数设置。

表2本实施例中的不同类型的请求

请求类型 数据类型 r_type r_delay(秒) 可延迟 邮件数据 1 1800 预取 新闻数据 -1 3600 实时 其他 0 0

步骤（2.2）：判断接收的请求的r_type是否为0，如果为0，则执行步骤（2.3），否则 执行步骤（2.4）；

步骤（2.3）：将接收的请求插入到实时请求队列的队尾；跳转至步骤（2.1）；

步骤（2.4）：判断计时器θ是否启动，如果已启动，则执行步骤（2.5），否则执行步骤 （2.6）；

步骤（2.5）：停止计时器θ；

步骤（2.6）：根据接收请求的可延迟时间（本实施例中该值为1800秒或3600秒）和 当前时间，计算出该请求的最终期限；按照最终期限的远近从小到大的顺序将该请求插入 到可延迟请求队列中；

步骤（2.7）：获取可延迟请求队列队首请求的最终期限，并根据该期限启动计时器θ； 跳转至步骤（2.1）；

上述步骤（3）中，根据移动终端的功率和吞吐量，持续不断地维护计时器γ和δ的流 程如图4所示，具体包括以下步骤：

步骤（3.1）：利用移动终端当前的功率推断当前无线资源控制协议状态机所处的状态；

步骤（3.2）：判断当前状态是否为专用信道状态，如果是，则执行步骤（3.3），否则执 行步骤（3.8）；

步骤（3.3）：判断当前的吞吐量是否小于触发从专用信道状态到前向接入信道状态的 界限值（该值在步骤（1）中测得，如表1所示为8kbps），如果是，则执行步骤（3.4），否 则跳转至步骤（3.6）；

步骤（3.4）：判断计时器γ是否启动，如果未启动，执行步骤（3.5），否则跳转至步骤 （3.14）；

步骤（3.5）：启动计时器γ，跳转至步骤（3.14）；

步骤（3.6）：判断计时器γ是否启动，如果已启动，执行步骤（3.7），否则跳转至步骤 （3.14）；

步骤（3.7）：停止计时器γ，跳转至步骤（3.14）；

步骤（3.8）：判断当前状态是否为前向接入信道状态，如果是，则执行步骤（3.9），否 则跳转至步骤（3.14）；

步骤（3.9）：判断当前的吞吐量是否等于0，如果是，则执行步骤（3.10），否则跳转 至步骤（3.12）；

步骤（3.10）：判断计时器δ是否启动，如果未启动，则执行步骤（3.11），否则跳转至 步骤（3.14）；

步骤（3.11）：启动计时器δ，跳转至步骤（3.14）；

步骤（3.12）：判断计时器δ是否启动，如果已启动，则执行步骤（3.13），否则跳转至 步骤（3.14）；

步骤（3.13）：停止计时器δ，跳转至步骤（3.14）；

步骤（3.14）：延迟一段时间（本实施例中该时间为0.5秒），然后跳转至步骤（3.1）。

上述步骤（4）中，根据计时器θ、γ和δ的状态，不断地从实时请求队列或者可延迟 请求队列中取出请求进行处理，并发送到网络的流程如图5所示，具体包括以下步骤：

步骤（4.1）：判断计时器θ是否启动，如果已启动，则执行步骤（4.2），否则执行步骤 （4.3）；

步骤（4.2）：判断计时器θ是否超时，如果未超时，则执行步骤（4.3），否则执行步骤 （4.7）；

步骤（4.3）：判断实时请求队列中是否有请求，如果有，则执行步骤（4.4），否则执行 步骤（4.5）；

步骤（4.4）：取出实时请求队列队首的请求，传输该请求到网络；跳转至步骤（4.1）；

步骤（4.5）：判断能否进行尾巴时间传输，如果能，则执行步骤（4.6），否则跳转至步 骤（4.1）；

上述步骤（4.5）判断能否进行尾巴时间传输的流程如图6所示，具体步骤如下：

步骤（4.5.1）：利用移动终端当前的功率推断当前无线资源控制协议状态机所处的状态；

步骤（4.5.2）：判断状态机的状态是否为专用信道状态，如果是，则执行步骤（4.5.3）， 否则执行步骤（4.5.4）；

步骤（4.5.3）：判断计时器γ是否被启动，如果已启动，则执行步骤（4.5.5），否则跳 转至步骤（4.1）；

步骤（4.5.4）：判断计时器δ是否被启动，如果已启动，则执行步骤（4.5.5），否则跳 转至步骤（4.1）；

步骤（4.5.5）：判断当前吞吐量是否等于0，如果是，则执行步骤（4.6），否则跳转至 步骤（4.1）；

步骤（4.6）：调度可延迟请求队列中的请求到尾巴时间中；

上述步骤（4.6）调度可延迟请求队列中的请求到尾巴时间的流程如图7所示，具体包 括以下步骤：

步骤（4.6.1）：判断可延迟请求队列中是否有请求，如果没有，则执行步骤（4.6.2）， 否则执行步骤（4.6.3）；

步骤（4.6.2）：延迟T₃长度的一段时间。在本实施例中T₃设置为固定值1.5秒。该值 通过分析手机上网络流量的特征获得。在延迟结束后，跳转至步骤（4.6.11）；

步骤（4.6.3）：停止计时器θ；

步骤（4.6.4）：利用移动终端当前的功率推断当前状态机所处的状态；

步骤（4.6.5）：判断当前状态是否为专用信道状态，如果是，则执行步骤（4.6.6），否 则执行步骤（4.6.7）；

步骤（4.6.6）：执行在专用信道状态下的尾巴时间调度；

上述步骤（4.6.6）中，在专用信道状态下的尾巴时间调度步骤如下：

步骤（4.6.6.1）：判断计时器γ是否超时，如果未超时，则执行步骤（4.6.6.2），否则跳 转至步骤（4.6.10）；

步骤（4.6.6.2）：取出可延迟请求队列队首的请求，传输该请求到网络；然后跳转至步 骤（4.6.9）；

步骤（4.6.7）：判断当前状态是否为前向接入信道状态，如果是，则执行步骤（4.6.8）， 否则跳转至步骤（4.1）；

步骤（4.6.8）：执行在前向接入信道状态下的尾巴时间调度；

上述步骤（4.6.8）中，在前向接入信道状态下的尾巴时间调度步骤如下：

步骤（4.6.8.1）：判断计时器δ是否超时，如果未超时，则执行步骤（4.6.8.2），否则跳 转至步骤（4.6.10）；

步骤（4.6.8.2）：取出可延迟请求队列队首的请求，传输该请求到网络。在前向接入信 道状态下调度可延迟请求队列中的请求时，保证无线链路控制缓冲区中数据不超过步骤 （1）中测得的无线链路控制协议缓冲区的界限值（表（1）分别列出了上下行链路缓冲区 的界限值）；然后执行步骤（4.6.9）；

步骤（4.6.9）：根据可延迟请求队列队首请求的最终期限重启计时器θ；然后跳转到步 骤（4.6.1）；

步骤（4.6.10）：等待无线链路控制协议缓冲区被清空；本实施例中通过延迟无线链路 控制缓冲区消耗的最大时间来实现（通过表1列出的参数求得该时间为1.2674秒）。

步骤（4.6.11）：调用快速休眠机制下调状态；然后跳转至步骤（4.1）；

步骤（4.7）：直接处理可延迟请求队列队首的请求；如果可延迟请求队列中的请求在 到达最后可延迟期限之前仍然没有被调度，则不论当前状态机处于什么状态，该请求被直 接处理；

上述步骤（4.7）直接处理可延迟请求队列队首的请求的具体步骤如下

步骤（4.7.1）：取出可延迟请求队列队首的请求；

步骤（4.7.2）：判断该请求的r_type是否为-1，如果是，则执行步骤（4.7.3），否则执 行步骤（4.7.4）；

步骤（4.7.3）：丢弃该请求；然后跳转至步骤（4.7.5）；

步骤（4.7.4）：传输该请求到网络；然后执行步骤（4.7.5）；

步骤（4.7.5）：根据可延迟请求队列队首请求的最终期限重启计时器θ；然后跳转到步 骤（4.1）。