测试链路自适应策略的IP分析技术

链路自适应（也称为调度），首先是作为3GPP协议下HSDPA技术的一个特点推出的，它是手机无线网络分配射频资源的一种方法。采用这样方法，基站采用的射频协议在每个传输时间间隔（TTI）为下行链路传输提供数据及为上行链路传输分配资源（见图1）。

　　图1：每个TTI必须执行的处理功能。

　　由于TTI可短至1ms， 该调度技术提供了极大灵活性，以将流量路由和吞吐率与可用资源匹配起来。它是高通量、稳定和有效利用带宽的关键。然而，链路自适应实施中的一个根本问题一直困扰着手机设备的发展：常规的测试设置无法充分查明并定位链路自适应方法在工作中出现的错误和失败。本文提出了一种测试设置，它能以精准到具体TTI的水平检测并定位调度错误。

测试链路自适应的常规策略

　　传统上，功能和性能测试是协议和系统验证过程中两个截然不同的部分。调度通常包括在功能测试部分，而该功能同时也对性能（数据吞吐量）有根本性的影响。

　　传统的功能测试方法产生巨量的日志记录（log），因为每个TTI（也即每1ms）调度软件都接收输入并做出决策。这意味着，日志分析既繁琐又耗时，因此并不进行该工作。相反，链路自适应通常是采用简单但有限配置（与满足覆盖现实使用各可能情况的要求有相当差距）实施的功能测试。

　　链路自适应的性能测试是通过测量数据吞吐量实现的。因链路自适应功能测试的范围有限，所以必须等到性能测试开始，才可进行完整的功能验证。显而易见，这通常处在项目开发的后期。在很多时候，链路自适应存在的性能问题，与功能上的错误息息相关。如果这些功能问题是在性能测试过程中发现的，则必须对这些问题予以纠错，这可能意味着必须对设备的某些部分进行重新设计并重新进行部分验证。因此，精准的性能测试数据就成为一种宝贵资源，它使开发工程师能集中精力在确实较劲的地方调试差错并反复验证。

　　不幸的是，今天的常规性能测试设置提供的输出非常不精确。它们包括运行于PC或UNIX工作站上的服务器应用和拨号PC上运行的客户端应用。服务器和客户端应用实现数据通信协议（如FTP传输）、进行测量并提供结果。

　　问题是，Windows或Unix操作系统（OS）一般提供的计时精度约为500ms。真实情况是，Windows应用中数据包的实际传输通常使用NDIS技术，它具有优于Windows本身的计时精度，但对这些传输的测量受操作系统的影响。

　　更糟的是，即使这种数百毫秒水平粗放的计时精度，操作系统或计算机制造商也不能保证。因为LTE（以及HSPA和HSPA+的一些配置）的TTI为1ms，显然，基于Windows的应用可能提供的数据流通量不会超过OSI堆栈应用层面的总吞吐量水平。所以，精准到具体TTI的功能问题的详细定位信息就不可能提供。为找出有助于调试吞吐量问题的这类信息，研究一个简化的例子就很有帮助（见图2）。

　　图2：包重传造成的后果是降低了数据吞吐率。

　　例如通过基站传输的一个IP数据流。采用链路自适应，调度器采用最大和最小的可用块大小；每一块大小都传输相同的块数。如果我们分别采用256bit和7，480bit作为最小和最大传输块（TBS），这就将实现约1，948，000bps（也即约2Mbps）的总数据吞吐量。（为简单起见，计算中，这个例子没包括协议报头；并且选定的IP报头和数据大小都假定为128bit。）

　　想象一下，下一次实施相同测量的情况，射频协议的性能已经恶化（可能是由于协议软件性能的下降），导致每个第三大的数据包都传丢了。射频协议栈必须重发丢失的数据包，这将使数据吞吐量降低至约1，504，000bps（约1.5Mbps）。这就比第一次测量降低了25％。

　　使用常规性能测试设置，工程师不会了解吞吐量降低的原因或故障所在，他们看到的只是吞吐率。但若测量系统能提供精准计时，则只需测量数据包延迟便很容易找出问题。