专利名称：带有标题压缩的无线通信设备的制作方法
技术领域：
本发明涉及无线通信设备并且涉及操作该无线通信设备的方法，特别涉及基于分组的无线通信设备以及操作该基于分组的无线通信设备的方法，其中使用标题压缩。本发明还涉及在这样的设备中使用的通信单元和软件产品。
基于无线电单元和用于将它们至少临时地组成共享资源网的连接的无线通信系统是已知的。这种一般类型的目前的一个实现是采用短射程、跳频网络的形式并且在本领域中被称为蓝牙TM通信。这种设备由蓝牙TM标准控制并且与蓝牙TM通信符合的完整规范和目前的蓝牙TM标准以及相关信息可以通过蓝牙TM特殊兴趣组(SIG)找到，其网站可在“www.bluetooth.com”找到。
蓝牙TM通信的有用论述可以在由Jennifer Bray和CharlesF.Sturman写的“BluetoothTM，Connect Without Wires(蓝牙TM，无线连接)”的文本书格式中找到，其由Prentice Hall PTR出版，ISBN 0-13-089840-6。
更多的现有技术可以在，例如WO 01/20940，US5940431以及在美国公开的申请2001/0005368A1和2001/0033601A1中找到，其中这个领域的目前技术发展水平的某些方面也被论述。
对于通用蓝牙TM背景信息以及例如，对于这里用到并且没有明确定义的技术术语的说明，读者可参考上述来源。
蓝牙TM网络中的每个接入点与一个或多个移动终端，例如移动电信手机组成一个蓝牙TM微微网。这个蓝牙TMPAN可以传送VoIP流以及其他类型的IP业务量。因为许多手机(或者其他终端)可被连接到相同的接入点，所以可以看到在有限的可用带宽(每个微微网1Mbps总容量)的使用方面使效率最大化很重要。
蓝牙TM的一个新出现的应用是互联网协议上的语音(VoIP)的传递，其被部署在互联网上以及企业通信网/内联网中。在后一种情况下，VoIP的主要优点是其被典型地用于数据的已有的网络基础设施的语音业务量使用。但是，当VoIP业务量需要在具有有限带宽的无线链路上被传送时，因为VoIP流是延迟敏感的并且显示出相当大的标题额外开销，所以最小化带宽浪费很重要。
图1中描述的基础结构显示一种可能的情景，其中一组移动终端MT1-n中的一个MT1包括蓝牙TM使能的第三代(3G)移动电话，其有一个嵌入的IP栈并且能够通过在如内联网的企业通信网中建立VoIP连接来象无绳电话手机一样操作。移动手机MT1使用内联网中的一组接入点AP1...n通过到电话网的专用网关(PABX/VoIP GW)或者在内联网里，建立与一个或者更多其他手机MTn的IP上语音(VoIP)连接。
根据VoIP范例，语音采样被压缩成分组，其长度依赖于使用的语音编码器。这样的有效负荷长度必须被限制以避免在会话中引入长延迟。为了GSM质量，5.3kb/s的G；723.1编码器可被使用，其生成20字节的语音分组。利用实时协议(RTP)为这个有效负荷打上时间戳，其引入12字节的标题并且所得到的段在UDP数据报中被传送，其增加了自己的另外8个字节的标题。虽然RTP提供用于时间同步的功能，但是UDP允许几个流被一起多路复用成无连接的逻辑信道。然后这个RTP/UDP分组被封装成IP数据报，其增加一个20字节的IP标题。如果使用IP版本6(IPv6)，则因为IP标题从20字节增加到40字节，给出只有20个字节有效负荷的60个字节的可能的整体标题，所以情况会更坏。当VoIP分组在有线LAN上被传送时带宽利用的这一低效率可能不是主要问题，但是当无线LAN被替代使用时会导致严重的限制。
在蓝牙TM通信的特殊情况下，个人区域网(PAN)工作组标准化了蓝牙TM上的IP并且，为这个目的，已经开发了称作“蓝牙TM网络封装协议”(BNEP)的新协议。这个协议为用于在蓝牙TM介质上传输通用联网协议的蓝牙TM网络封装定义了分组格式。BNEP为蓝牙TM提供以太网仿真，利用它把IP数据报封装成以太网帧并且发送到下面的L2CAP层。通过引入以太网仿真层，可能例如在网络接入点或者在蓝牙TM特设网中实现广播、组播以及层2桥接功能。BNEP的完整细节可通过蓝牙TMSIG和上面提到的其网站获得。
虽然非常灵活，但是，尽管有其自己的标题压缩机制，BNEP还是引入了很大的额外开销。当将BNEP合计到更高层协议的额外开销中时，对于有些应用会导致相当大的带宽浪费。例如，在上述VoIP应用的情况下，利用BNEP封装RTP/UDP/IP分组将向已经很长的标题中增加3到15个更多字节，因此对于20字节的有效负荷导致至少(12+8+20+3＝43)直到可能的(12+8+40+15＝75)字节的整体标题。类似的考虑应用于其他类型的IP业务量，例如如音频和/或视频信号的介质。在后面这些情况中，由音频/视觉应用生成的分组可能比VoIP分组更大，但是最小化标题额外开销仍然很重要。事实上，当使用蓝牙系统时，通常由音频/视觉编码器生成可被一对一地映射到L2CAP帧的分组。这使得无论何时有用的分组使用期限到期时能够进行更好的重传控制以及减轻缓存刷新。如果标题的尺寸被最小化，给定基带分组的有用有效负荷，则更多的带宽被预留用于实际的音频/视觉有效负荷。
本发明的一个目的是提供改良的无线通信设备以及操作该设备的改良的方法。本发明的另一个目的是提供一种改良的基于分组的无线通信设备，以及操作该无线通信设备设备的改良的方法，其中使用标题压缩。本发明的另一个目的是提供与这些改良的通信设备和方法相关联使用的改良的通信单元以及软件产品。照这样，本发明的一个特殊目的是提供减少的归因于在蓝牙TM个人区域网中对于如VoIP、音频和/或视频的互联网协议(IP)比特流的RTP/UDP/IP/BNEP标题的额外开销。
因此，本发明提供用于第一个单元和第二个单元之间无线传输的方法，该方法包括一个所述单元a)将实时比特流转换成预定的最大长度的一个或多个有效负荷；b)将一个或多个预定义标题应用于所述或每个所述有效负荷以便生成适合于根据预定的通信协议在所述单元之间传输的分组；c)将所述或每个所述分组封装在适合于跨越所述单元之间的无线连接传送所述或每个所述分组的封装协议帧中；以及d)将预定义标题压缩技术应用于所述或每个所述封装的分组。
该方法包括从包括如互联网上语音(VoIP)、音频或视觉流的互联网协议(IP)业务量的所述实时比特流生成所述或每个所述有效负荷。
该方法包括在所述第一个和第二个单元之间执行业务发现过程以及在所述业务发现过程期间通告所述标题压缩技术。
该方法包括配置一个或多个分段，重新组装以及多路复用所述预定义信协议的业务以便运送压缩的比特流。
该方法包括通过向适合于应用所述标题压缩技术的压缩器和解压缩器的上下文中增加封装协议信息来应用所述标题压缩，所述信息包括例如所述封装协议的静态标题域。
所述单元包括诸如蓝牙TM网的无线电通信网的一部分并且所述方法包括利用包括蓝牙TM网封装协议(BNEP)的封装协议来封装所述或每个所述分组。
该方法包括优选地通过将所述预定标题和BNEP标题的组合缩短到例如3字节的预定长度来利用所述标题压缩技术将所述或每个所述封装的分组压缩成单一时隙蓝牙TM基带分组。
该方法包括以诸如由互联网工程任务组(IETF)通过的ROHC的健壮标题压缩(ROHC)框架的形式应用所述标题压缩技术。
该方法包括下述的一个或多个a)对于所述分组使用实时协议(RTP)概况(profile)；b)使用IETF ROHC双向最有利方法(o模式)；c)使用小ROHC上下文识别符(R-CID)，空R-CID是缺省值；d)不传输通用数据报协议(UDP)校验和，可选地在解压缩器处对其重新计算；e)在任何一个分组流期间将整个封装协议标题考虑成静态上下文的一部分；f)仅传输实时协议(RTP)序列号和/或互联网协议身份；g)定义压缩器中“初始化和刷新”(IR)、“第一级”(FO)和“第二级”(SO)状态之间的转移以及解压缩器中“没有上下文”(NC)、“静态上下文”(SC)以及“全上下文”(FC)状态之间的转移。
该方法包括将封装帧分类因此只有预定的所述帧被利用所述标题压缩技术进行压缩。
该方法包括根据实时协议(RTP)、通用数据报协议(UDP)以及互联网协议中的一个或多个来将标题应用于所述有效负荷。
该方法包括所述单元配置多个逻辑信道用于这些单元之间的通信，至少一个所述信道专用于所述压缩的封装分组的传送。
该方法包括将所述标题压缩技术基于窗口-最低有效位编码(W-LSB)。
该方法包括通过提供适合于错误恢复请求以及优选地，适合于上下文更新确认的所述单元之间的反馈信道来管理压缩器和解压缩器状态之间的转换。
该方法包括所述单元接收被分段成基带分组的一连串所述压缩的封装帧，在下一个所述分组被传输之前肯定地确认每个所述分组以及，如果在最近的所述分组或者确认消息中出现传输错误，则所述最近的分组被重传。
该方法包括如果下列情况的至少一种发生，则重传所述分组a)基带分组存取码没有被接收到；b)在基带分组标题中出现无法纠正的错误；或者c)在所述分组的所述有效负荷中存在无法纠正的错误。
该方法包括例如，通过设置所述帧的成功传递的超时，限制对于所述压缩的封装帧的多个重传。
本发明还提供用于在第一个通信单元和第二个通信单元之间执行基于分组的无线通信的软件产品，所述产品包括用于执行下列操作的代码a)将实时比特流转换成预定最大长度的一个或多个有效负荷；b)将一个或多个预定义标题应用于所述或每个所述有效负荷以便生成适合于根据预定义的通信协议在所述单元之间传输的分组；c)将所述或每个所述分组封装在适合于跨越所述单元之间的无线连接传送所述或每个所述分组的封装协议的帧中；以及d)将预定义标题压缩技术应用于所述或每个所述封装的分组。
所述软件产品可与组成所述通信单元的一部分的蓝牙TM网接口软件驱动器关联运行。
本发明还提供包括适合于基本实时地向第二个单元发送信息的第一个单元的基于分组的无线通信设备，所述第一个单元适合于a)将实时比特流转换成一个或多个预定最大长度的有效负荷；b)将一个或多个预定义标题应用于所述或每个所述有效负荷以便生成适合于根据预定义的通信协议在所述单元之间传输的分组；c)将所述或每个所述分组封装在适合于跨越所述单元之间的无线连接传送所述或每个所述分组的封装协议的帧中；以及d)将预定义的标题压缩技术应用于所述或每个所述封装分组。
所述第一个单元根据蓝牙TM协议操作，所述封装协议优选地包括蓝牙网封装协议(BNEP)并且所述标题压缩技术优选地与互联网工程任务组(IETF)健壮标题压缩(ROHC)技术兼容。
本发明还提供适合于依照根据本发明的一种方法来操作的通信单元，所述单元优选地包括蓝牙网的主单元或者从单元，如接入点或者移动终端。封装的分组的标题压缩和/或解压缩可以以在与所述通信单元相关的蓝牙TM网接口软件驱动器中运行的软件产品的形式来实现。这个软件产品包括蓝牙网封装协议(BNEP)和逻辑链路控制和适配协议(L2CAP)层、帧分类器、健壮标题压缩(ROHC)编解码器以及用于协调的管理实体(ME)。管理实体可通过主控制器接口(HCI)与蓝牙TM基带通信以及利用操作系统特定的机制与上面的协议层通信。每次例如具体化为移动终端MT1-n的从通信单元连接到例如具体化为接入点AP1-n的主单元时，管理实体都登记其介质访问地址(MAC)并且为所述从单元配置逻辑信道。
图1是通信系统的示意图；图2是用于根据本发明的实施方案的通信单元的协议栈并且其适合于用于根据图1的系统；图3是用于图2的通信单元的网络配置的流程图；图4a是用于实现本发明的标题压缩器的流程图；图4b是用于实现本发明的标题解压缩器的流程图；图5是本发明的实施方案的功能图；图6a是标题压缩和解压缩链的示意图；图6b是压缩器状态的框图；图6c是解压缩器的框图；并且图7是图4a的标题压缩器的状态机。
现在将参考特定实施方案并且参考上述附图描述本发明。这些描述仅作为例子并且本发明不限于此。特别地将参考分组以及基于分组的通信系统。本领域的技术人员应该理解，本发明不限于分组交换系统而是可被用于将分组用作传输数据的手段的任何系统，也就是与它是分组交换、电路交换或另一种系统无关。对于“无线”的参考应该被理解成其最广泛的含义。例如，它可包括其某些传输不依赖于有线网络的任何系统，例如它包括如漫射红外的光传输方法。但是，应该注意，本发明的所有实施方案可与蓝牙TM协议一起被使用。这样的系统的特性包括下列的一个或多个-作为扩频技术的慢跳频；
-主单元和从单元，由此主单元可以设置跳频序列；-每个设备有其自己的时钟和其自己的地址；-主单元的跳频序列可从其地址被确定；-与一个主单元通信的一组从单元都有(主单元的)相同的跳频并组成一个微微网；-微微网可通过公共从单元被链接以便组成分散网；-从单元和主单元之间的时分复用传输(TDMA)；-从单元和主单元之间的时分双工(TDD)传输；-从单元和主单元之间的传输可以同步或者异步；-主单元确定何时从单元可以传输；-从单元仅当被主单元寻址时才应答；-时钟自由运行；-不对等的网络，特别是在2.4GHz无拍照ISM频段运行的那些网络；-使得应用能够找到该区域中其它蓝牙TM设备的软件堆栈；-其它设备通过发现/查询过程被找到；以及-硬或软的切换。
关于跳频，“慢跳频”指比调制速率慢的跳频，“快跳频”指跳频速率比调制速率快。本发明不限于慢或者快跳频。
下面将参考的用户终端是移动终端，但是本发明不限于此而是还包括诸如计算机的固定用户终端。
这里将参考标题压缩技术，并且特别是健壮标题压缩(ROHC)。提供这些技术的某些方面的概述被认为很有用，但是为了更详细地理解，读者可参考2001年7月的文章C.Borman等人的“Robust Header Compression(ROHC)Framework and four profilesRTP，UDP，BSP anduncompressed(健壮标题压缩(ROHC)框架和四个概况RTP，UDP，BSP以及未压缩的”)，这篇文章可以通过“互联网工程任务组”(IETF)网站在参考“RFC3095”下找到并且通过以下URL可以访问http://www.ietf.org/rfc/rfc3095.txt通常，标题压缩机制利用因为静态标题域在会话期间不改变，所以无需在每个分组中发送静态标题域的事实而减少了标题额外开销，这样的静态标题域包括例如IP地址和UDP端口。而且，有效地处理在会话期间变化的域(例如RTP时间戳、RTP序号以及IP标识)是可能的，因此标题额外开销可以被减少得更多。在某些情况下，这些所谓的“变化的域”可以利用简单的线性外推法从以前的分组中预测。其它标题域(例如IP标题长度和UDP长度)可以从数据链路级推断出来并且没必要发送他们，这些域被称为“推断域”。
标题压缩方案由S.Casner和V.Jacobson在其1999年2月的文章“Compressing IP/UDP/RTP Headers for Low-Speed Serial Links(对于低速串行链路压缩IP/UDP/RTP标题)”中被建议(互联网RFC2508)。这个方案压缩RTP/UDp/IP标题，但是没有被设计来处理在典型的无线链路上遇到的错误率以及往返行程延迟。
使标题压缩适用于无线环境的技术被建议，例如“ACE”(适应性标题压缩)以及“ROCCO”(健壮的基于校验和的标题压缩)。“ACE”介绍了使用可变的滑动窗口(VSW)中包含的多个参考值的域编码方案“变化域”(“基于窗口的最低有效位”W-LSB)，这些值被发送给解压缩器。ROCCO使用CRC来验证解压缩器中正确的重建以及避免错误传播。
IETF ROHC工作组目前正在研究在具有高错误率和长往返行程时间的链路上很好工作的新的压缩方案。所述方案对于使用如WCDMA、EDGE以及CDMA-2000技术建立的蜂窝链路必须能够很好执行。但是，所述方案还应该适用于具有高损耗和长往返行程时间的其它未来的链路技术，使得压缩可以在单向链路上被获得。IETF ROHC使用并且组合了ACE和ROCCO研究的所有技术并且细节可以通过以下的IETF ROHC工作组URL找到http://www.ietf.org/html.charters/rohc-charter.htmlROHC提供对于适用于无线信道上RTP/UDP/IP流的健壮标题压缩的可扩展框架。对TCP/IP标题和其它类型协议(例如移动Ipv6)的压缩的支持也被加入并且到此为止四个概况被ROHC RFC定义0 未压缩的IP分组1 RTP/UDP/IP2 UDP/IP3 ESP/IP本发明集中在概况1上。
ROHC压缩器和解压缩器需要维护上下文信息，以便实时流的动态域被正确地处理并且标题因此被重建，而静态标题域，也就是在给定上下文中保持不变的那些根本不被传输。压缩和解压缩链的图可以特别参考图6a看到。
对于RTP/UDP/IP流，动态域如下列出
-IP标识(16比特) IP-ID-UDP校验和(16比特)-RTP标记(1比特) M-bit-RTP序号(16比特)SN-RTP时间戳(32比特) TS所有其它标题域或者是静态的或者被推断。
最初，压缩器在“初始化和刷新”(IR)状态，其中标题未压缩的被发送以便解压缩器可以为IP流创建上下文。在“第一级”(FO)状态，压缩器仅向解压缩器发送静态域的更新来补偿可能破坏上下文的流中的不规则。因此，在这种状态下，压缩器仅发送上下文更新。在“第二级”(SO)状态下，因为可以肯定解压缩器已经接收到合法的上下文，因此压缩器发送压缩标题。请特别地参见图6b。
解压缩器以“没有上下文(NC)”状态开始。一成功地对标题解压缩，其就转到“完整上下文”(FC)状态，这是正常的运行状态。只有重复地解压缩标题之后其才转入“静止上下文”(SC)状态，其中其等待由在FO状态的压缩器发送的上下文更新分组。如果合法的上下文不能被恢复，则解压缩器返回NC状态。请特别地参见图6c。
状态之间的转移由运行模式来管理，其中ROHC定义了三种模式“单向”(U-模式)，“双向最有利”(O-模式)以及“双向可靠”(R-模式)。在U模式中，从解压缩器到压缩器的反馈信道不存在(或者不能被使用)因此压缩器状态之间的转移仅基于输入分组标题的周期性超时和不规则。在这种情况下，需要上下文的周期性刷新。在O模式中，反馈信道被用于错误恢复请求以及(可选地)上下文更新的确认。这种运行模式背后的合理性是最小化反馈信道的使用。最后，R模式密集地使用反馈信道以便最大化健壮性防止损耗传播和损坏传播。
W-LSB编码给定标题域值来压缩“v”，如果合适的参考值(v_ref)在压缩器和解压缩器都被保持，则W-LSB算法仅发送其最低有效位。为了避免“v_ref”值之间的不匹配，合适的健壮算法被定义，其在可变滑动窗口VSW中选择“v_ref”。发送要被压缩的值“v”的最低有效位的数量“k”按如下说明的被选择。
令f(v_ref，k)＝[v_ref-p，v_ref+(2k-1)-p] (1)是其中v预期会变化的间隔。偏移参数p可根据要压缩的特定域的行为来被选择。
现在，在压缩器中值k可以按如下的方式被选择k＝g(v_ref，v)＝min kv∈f(v_ref，k)(2)所以k可以是最小值因此v落在间隔f(v_ref，k)中。
但是，因为压缩器不知道解压缩器正在使用相同的参考值(因传输错误其可能实际上不相同)，所以这个方案可能对预防错误不够健壮。替代地，可变滑动窗口被引入VSW＝{vi-w，vi}(3)其包含被发送的最近的w值。无论何时新值进入压缩器，其就被附加到VSW。当压缩器充分确信VSW中某些较旧的值已经被正确地接收时，那些值从VSW中被删除。
我们定义vmin＝min(VSW)，vmax＝max(VSW) (4)作为VSW中的最小和最大值。
在W-LSB编码方案中，根据下列公式进行k的选择k＝max(g(v，vmin)，g(v，vmax)) (5)其中g()在(2)中已经被定义。
这样，归因于解压缩器具有用于解码传输的m比特的好的参考间隔的不确定性，更多数量的比特被用于对该域编码。事实上，解压缩器处的解码技术基于下列算法。
给定最近被正确解压缩的值v_ref_d和接收的比特数m，令Id＝f(v_ref_d，m) (6)被定义为解释间隔。通过在上述解释间隔中选取其m个最低有效位与接收的m个比特匹配的值，被解压缩的域被简单地获得。
可变滑动窗口的大小w依赖于压缩器对解压缩器状态的信任，其进而又依赖于选择的ROHC模式。对于U和O模式，w是与实现相关的。ROHC压缩分组的语法(后面定义)设置允许的w尺寸。事实上，因为每个分组类型有确定的数量的比特预留用于被编码的标题域，因此这自动地定义了窗口的尺寸。例如，RTP-SN是UO-0分组中被预留的4比特，其意味着窗口长度被设置为16(也就是多达15个分组可以被丢失。)在R模式中，来自解压缩器的明确的反馈可被用于最小化滑动窗口尺寸并且因此最大化压缩率。
W-LSB算法还可以通过简单的例子被进一步解释。我们假设压缩器已经发送了值151、152、153、154以及155并且因为无线链路上的传输错误，最近的三个值没有被接收。因此，在压缩器中
VSW＝[151，152，153，154，155]，vmin＝151并且vmax＝155。
现在值156进入压缩器。要传输的最低有效位的数量k由(5)给出，其生成k＝max(3，1)＝3。因此值156＝‘10011100’的最近三个LSB被传输(‘100’)。
在解压缩器中，因为值153、154和155已经被丢失，因此最近的好的参考值是152。根据(6)，解压缩器有解释间隔Id＝[152，159]，其被如下说明。
应该注意，在这个间隔中其三个LSB与样式‘100’匹配的唯一值是156。为了避免未检测到的传输错误导致错误的解压缩值，其进而可能在后面被用做参考值，导致损坏传播，解压缩的正确性可以通过将小的CRC应用于原始标题(例如依据模式的3-8个比特)被检查。CRC检测被损坏值的失败还可以在ROHC框架中被补偿。
其它编码方案W-LSB编码算法不是可被用于ROHC框架中的唯一算法。利用例如通常随时间按规则的步幅增加(TS_STRIDE值的倍数)的RTP时间戳之类的某些标题域的特定特征的其它方案也存在。这个特征由“成比例的RTP时间戳”编码使用。
还可利用以固定速率被生成的业务量的时刻、固定采样频率以及何时分组生成被锁定到采样频率的线性函数来近似RTP时间戳。在这种情况下应用“RTP时间戳的基于定时器的压缩”。
IP标识域(IP-ID)通过仅考虑IP-ID和RTP序号之间的偏移(后者对于每个新分组增加1)并且将W-LSB编码应用于这样的偏移而被编码。
ROHC RTP概况要被压缩的RTP/UDP/IP流的固定标题域可以被构建为有序列表。ROHC框架提供方法以这样的方式来处理这些列表，即解压缩器中的列表项(组成上下文)可以被压缩器灵活地插入、删除或者变更。
RTP标题的动态域根据表1被编码。
表1-RTP标题动态域编码。
因为当序号和时间戳增加相同的增量乘以一个固定值时，IP-ID通常增加该相同的增量，所以RTP TS和IP-ID域经常可以来自RTPSN。因此，当这些条件应用时，只有RTP SN被包括在压缩标题中并且推断其它域的函数被包括在上下文中。
ROHC分组具有下列格式
可选的，变长0或者多个反馈元素可变，具有CID信息表2-ROHC分组除了有效负荷之外，表2中的每个分组元素都从唯一的位模式开始。
标题运送上下文ID(CID)信息其对于1到15之间的小CID包括1字节‘add-CID’八位字节(以模式‘1110’开始)或者当CID空间很大时运送嵌入的CID信息(多达2字节)。ROHC上下文标识符被称为R-CID。如果CID＝0没有被发送，则该分组以分组类型开始，其是不同于‘1110’的唯一的位模式并且空CID被暗示。
反馈信息可被捎带确认到任何ROHC分组并且运送对于上下文更新和标题解压缩的否定和肯定确认。反馈分组还可被解压缩器用于请求模式之间的转移(例如从U模式到O模式)。
分组类型几种分组类型由ROHC根据其功能、使用的模式以及哪些域被运送而被定义。ROHC分组的表示是<模式>-<类型>-<可选域>
例如，UOR-2分组可在U模式、O模式或者R模式被使用并且是类型2。
在RTP概况中，三种分组类型被用于识别压缩标题并且两种用于初始化和刷新，如下所示0.(R-0，R-0-CRC，UO-0)这是最小分组类型，其中只有W-LSB编码的RTP-SN被发送，这是因为用于获得其他域的所有函数在解压缩器处都已知。
1.(R-1，R-1-ID，R-1-TS，UO-1，UO-1-ID，UO-1-TS)当对RTP-SN编码所需的比特数超过分组类型0中可用的那些时或者当用于从RTPSN获得RTP TS和IP-ID的函数变化时，这个分组被使用。
2.(UOR-2，UOR-2-ID，UOR-2-TS)被用于修改任何的SN函数的参数。
3.IR这个分组被用于发送上下文的静态部分，也就是不变的SN函数4.IR-DYN这一分组类型被用于发送上下文的动态部分，也就是不固定的SN函数。
为每种分组类型组成唯一前缀的位模式在表3中显示。
表3-分组前缀。
一接收到分组，解压缩器就解析第一个字节并且因此驱动其状态机。
IR分组初始化和刷新(IR)分组允许解压缩器为RTP/UDP/IP流创建上下文。其结构在下面表4中显示。
0 7
110-2大CID11可变可变如果D＝1，则出现表4-IR分组格式。
Add-CID八位字节能够将上下文标识符与在分组的剩余部分中运送的静态标题信息关联。D比特是概况特定的，在RTP概况的情况下，其指示正好在静态链之后的动态子标题信息的存在。只有需要使用大上下文标识符时，CID信息域才出现。概况域是ROHC概况的标识符。8位CRC跟随着，为这个目的读者可参考C.Borman等人的“RobustHeader Compression(ROHC)Framework and four profilesRTP，UDP，ESP and uncompressed(健壮标题压缩(ROHC)框架和四个概况RTP，UDP，ESP和未压缩的)”，其可通过“互联网工程任务组”(IETF)网站在参考“RFC3095”下找到。对于所述值在其域上被计算的生成多项式参见5.9.1节。
静态链包含静态标题域的有序列表。例如，IPv4标题应该用包括版本、协议、源地址和目的地地址的静态部分初始化。IPv4标题的动态部分包括业务类型、生存时间、标识、DF、RND、NBO、扩展标题列表。
IR-DYN分组这种分组类型被用于更新上下文的动态部分并且其格式在下面的表5中显示。在这种情况下只有动态链被发送。
0 7
111可变表5-IR-DYN分组格式。
通用分组格式表6中显示压缩的分组格式。应该注意其结构依赖于许多条件(Cx)，因此其处理可能不明显。
0 7
1字节，类型指示1可变，C02字节，C1可变2字节，C22字节，C3可变2字节，C42字节，C5表6-通用压缩的分组格式。
条件依赖于以前解码的标记域的值。标题扩展可选地出现来运送额外的ROHC信息(四个不同的扩展类型被定义)。如果上下文指示这个域随机变化，则IP-ID域可以出现。
AH数据涉及认证标题，其包含安全相关的值。GRE校验和涉及GRE隧道(RFC2784，RFC2890)。UDP校验和仅当在上下文中被明确地指示时才出现。
对蓝牙TM的健壮标题压缩
本发明集中在两个主要问题上a)将健壮标题压缩(ROHC)应用于蓝牙TM协通信系统；以及b)将ROHC扩展到BNEP。
本发明提供一种能够压缩VoIP帧、视频/音频流或者等价物的新协议，因此其适合单一时隙蓝牙TM基带分组，这个协议在这里为方便被称为“ROHC-BNEP”。
本发明不仅限于语音应用，还可应用于其他IP业务量，如涉及蓝牙TM微微网中实时IP业务的传送的音频/视频流式应用。根据本发明，BNEP信息被加入到ROHC压缩器和解压缩器的上下文中。这样，不仅IP分组被压缩，而且层2帧也被压缩。
根据本发明的实施方案的对于移动手机MT1-n的协议栈可以特别参考图2来看。对于语音编码器生成的每个分组，12字节的RTP标题被加入以便允许时间同步。8字节UDP标题被加入，其允许应用流被多路复用在一起并且增加标题校验和。UDP数据报被封装在IP分组中，其依赖是使用IP版本4还是版本6有20字节或40字节的标题。用于将IP分组封装到蓝牙TM帧中的BNEP标题的范围从3字节到15字节。可以看到健壮标题压缩(ROHC)被应用于运送RTP/UDP/IP流的BNEP帧。
为了在单一时隙DH1基带分组中运送压缩帧，其具有27字节的有效负荷并且考虑4字节L2CAP标题额外开销，RTP/UDP/IP/BNEP标题需要被ROHC压缩器缩短到3字节。如果BT系统和ROHC压缩器如下面说明的被正确地配置，则这个目标可以达到。
建议的解决方案包括几步-利用标准的蓝牙TM业务发现协议来通告ROHC压缩能力；-配置L2CAP信道来运送被压缩的比特流；-将BNEP静态标题域添加到ROHC上下文中(在单一VoIP会话中所有的BNEP标题域是静态的)；-使ROHC框架适合蓝牙TM基带重传方案；以及-将BNEP帧分类，使得只有那些运送VoIP分组的帧利用建议的ROHC-BNEP算法被压缩。
通用的ROHC框架在上面被提到。在下一节中，其对于蓝牙TM情况的应用将被详细描述，包括使用的分组类型，如何选择分组类型以及压缩器状态之间的转移如何被管理。ROHC-BNEP使用下列工具-RTP概况被使用；-ROHC双向最有利模式是被使用的方法；在不成功解压缩的情况下只有NACKS被反馈并且每当可能的时候，我们都设法最小化其使用。
-只有小的R-CID，不需要大的CID空间，空的R-CID作为缺省被使用，这是因为其不需要被传输。
-没有UDP校验和被传输(只有当有效负荷没有被加密时，其可选地可在解压缩器处被重新计算)。
-因为对于相同的VoIP流整个BNEP标题从不改变，所以其必须被考虑成静态上下文的一部分。
-只有RTP序号和/或IP-ID被传输，这是因为用于获得RTP TS的函数是已知的(基于定时器的编码被应用来补偿寂静抑制)。
-反馈信道利用被最小化以便仅将上下文更新请求从解压缩器运送到压缩器。
-在压缩器中的“初始化和刷新”(IR)、“第一级”(FO)和“第二级”(SO)状态之间的转移以及在解压缩器中的“没有上下文”(NC)、“静态上下文”(SC)以及“全上下文”(FC)状态之间的转移被定义。
蓝牙TM上的ROHC利用图7的状态机进一步被规定。对于每种压缩器状态，表明哪些信息被传输(顶)，哪些分组被使用(底)以及对于标题信息多少字节被发送(括号之间)。状态之间的转移也被表明并且下面给出其解释。
最初，压缩器在IR状态并且上下文的所有静态和动态部分在解压缩器处被传输。只有在观察时间t 1p(t)里丢失的分组数小于在观察时间t-1 1p(t-1)里丢失的分组数时，才进行从IR到FO的转移。这些观察时间是压缩器记录在可设置的时间阈值内不能成功地被传送到解压缩器的VoIP帧的数量的固定时间点。对于在间隔(t-1，t)期间在蓝牙TM堆栈中L2CAP层接收的每个L2CAP超时事件，1p(t)被增加1。仅当压缩器记录输入的VoIP流没有显示不规则(例如，语音编码器中的寂静抑制)时，从FO到SO的转移才发生。一旦在SO状态，如果IP流显示不规则，压缩器就返回FO。当在FO状态时，如果指示静态上下文已经被破坏的NAK分组通过反馈信道被接收，则压缩器返回到IR状态。
在蓝牙TM上映射ROHC RTP在下一节中描述的ROHC-BNEP算法属于ROHC双向最有利算法，其在上面提到的C.Borman等人的“Robust Header Compression(ROHC)Framework and four profilesRTP，UDP，BSP anduncompressed(健壮标题压缩(ROHC)框架和四个概况RTP，UDP，BSP以及未压缩的”)中被明确描述。
反馈信道利用被最小化以便仅将上下文更新请求从解压缩器运送到压缩器。在ROHC RTP概况中使用的分组类型可在C.Borman等人的文章的5.2.7节中找到。解压缩器在单向模式开始并且将指示其在获得上下文信息后想要转换到最有利模式的反馈分组发送回压缩器。压缩器一接收到这样的请求，其就停止发送周期性的IR更新并且进入O模式，因此节省了带宽。
为了评估蓝牙TM系统中ROHC-BNEP RTP/UDP/IP标题压缩算法的效果，需要进行某些考虑。首先，蓝牙TM逻辑链路控制和适配层(L2CAP)将被考虑，然后基带错误处理机制将被再访问。
链路层成帧L2CAP层为蓝牙TM堆栈提供逻辑信道和分段以及重新组装(SAR)功能。逻辑信道由信道ID(CID)识别并且由对等实体之间的专用L2CAP信令消息利用已有的基带连接来建立。相同的基带连接上的两个BT设备之间的几个逻辑信道可以被建立。对于每个逻辑信道，链路层最大传输单元(MTU)被定义，其限制了L2CAP最大帧的尺寸。L2CAP SAR功能使得L2CAP帧被分段成多个基带分组，这些基带分组被顺次传输。
因为基带层不允许我们在L2CAP连接之间区分，因此属于不同L2CAP帧的基带分组不能被交织。换句话说，一旦L2CAP帧的第一个分组已经被传输，则相同逻辑连接的所有剩余分组必须跟随。
这个特征暗示如果两个应用正在使用相同的逻辑信道(或者即使它们使用两个不同的逻辑信道)，则具有低优先级的较长的帧可以延迟具有较高优先级的较短的帧的传输。
因此建议正确地使用L2CAP MTU参数来避免这些阻塞效果。作为例子我们考虑具有VoIP应用的BT客户端以及一个或多个TCP/IP连接。所述两个应用有不同的特征，这是因为第一个是延迟敏感的并且具有短分组而第二个没有延迟约束但是分组可以多达1500字节长。为了避免延迟实时业务量，小的MTU也必须被用于TCP/IP连接，即使这在IP层引入大的分段存储额外开销。
上面的两种应用有不同的可靠性要求对于实时业务量，因超过某个阈值的传输错误而被延迟的分组不再有用并且可以被丢弃，而对于TCP/IP数据连接则不是这样。
利用一个可设置的值可以把自动的刷新超时应用于每个L2CAP逻辑信道。在我们的仿真中，12.5毫秒的超时被用于丢弃VoIP帧。
在如我们上面的例子中TCP/IP和RTP/UDP/IP在相同的BT链路上同时出现的情况中，需要评估是否也允许丢弃TCP/IP帧以便改良VoIP应用的质量。这个选择依赖于许多因素并且在实时和数据业务量上都有暗示(在后一种情况中，必须考虑TCP/IP重传)。
当在蓝牙TM系统中应用ROHC-BT算法时，延迟敏感的逻辑信道的L2CAP超时的数量对于增加标题压缩机制的错误健壮性扮演重要的角色。事实上，L2CAP超时事件指示帧被丢失，因此标题压缩器可以例如通过选择合适的ROHC分组类型，利用这个信息来增大窗口。
错误处理蓝牙TM基带中的ARQ机制使得接收机必须在下一个分组被传输之前肯定地确认每个基带分组。如果在数据分组或者在确认消息中出现传输错误，则该分组必须被重传。导致分组重传的错误条件包括-基带分组存取码没有被接收；-基带分组标题中不可纠正的错误；-分组有效负荷中不可纠正的错误(只要这样的错误条件在确认分组中出现，就不触发重传，这是因为ACK域在分组标题中被运送)。
在接收机处组装的帧被传递到上层之前，作为相同的L2CAP帧的一部分的所有的基带分组必须被正确地接收。在发送机中，L2CAP帧被分段成的所有的基带分组在可设置的时间里必须被肯定地确认以避免L2CAP超时事件。
当出现L2CAP超时事件时，发送机利用HCI_Flush命令(参见蓝牙TMSIG，“Core Specifications，vl.1(核心规范vl.1)”，H1部分，4.7.4节)刷新L2CAP层和主控制器中的所有剩余的基带分组。这个命令对于特定的连接处理来重置所有等待状态的重传。只有当被标记为新的一帧的开始的新的HCI数据分组被接收时，正常的操作才被恢复。
利用L2CAP信道配置中的Flush_Timeout选项来通知L2CAP连接的接受者关于发送机的L2CAP超时(参见蓝牙TMSIG，“CoreSpecifications，vl.1(核心规范vl.1)”，D部分，6.2节)。
点到多点当VoIP发送机在蓝牙TM从单元上运行并且主单元具有连接到其上的其他从单元时，对于轮询访问方案应该给予某些考虑。
首先，从单元应该以与VoIP分组的生成相匹配的速率来请求要被轮询的主单元(例如每30毫秒)。这通过用命令HCI_QoS_setup协商合适的Tpol1来实现，其被翻译为LMP_quality_of_service_request。
但是，在点到多点配置的情况下，蓝牙TM基带的未编号的ARQ方案指示下次主单元轮询从单元时由从节点向主节点发送的分组可被确认(参见蓝牙TMSIG，“Core Specifications，vl.1(核心规范vl.1)”，B部分，5.3.1节)。这意味着在从单元中可以依赖于主单元的调度策略来触发L2CAP超时。
配置初始配置过程如图3所示，其中流在个人区域网用户(PANU)和网络接入点NAP(AP1-n)之间。一旦首先连接到接入点AP1-n，手机MT就执行SDP查询来获得关于接入点AP1-n支持的业务的信息。接入点AP1-n必须分别为标准的BNEP协议(PSM值被分配)以及在本文档中规定的新的ROHC-BNEP协议(为此必须使用动态PSM)来通告PAN和ROHC-BNEP能力。
首先通过请求BNEP特定的PSM来创建L2CAP可靠连接。然后利用在SDP记录中被通告的对于ROHC-BNEP的动态PSM值来创建第二个L2CAP连接。将利用L2CAP业务质量(QoS)建立消息把这第二个连接配置为不可靠的。这使得对于VoIP分组的重传数量被限制事实上，如果分组在某个时间量内没有被成功地传送，则其对于接收机将变得无用并且可以被丢弃，由此节省了带宽。为此目的，L2CAP超时需要与基带刷新命令相耦合，其暂停分组重传并且释放BT链路管理器中所有涉及的缓存。概括地说，移动手机需要配置两个逻辑信道，一个用于运送标准的IP业务量并且另一个用于运送压缩的VoIP流。一旦L2CAP逻辑信道被建立，移动终端和接入点就必须始终如一地使用它们，如下面的小节所述。
如果只有一个L2CAP信道在接入点AP和移动终端MT之间可以被建立，则“不可靠的”信道还应该被用于数据连接以便保护VoIP流。在不可靠逻辑信道上数据分组的丢失可通过更高层的协议(例如TCP/IP)来处理。
发送机和接收机逻辑在发送机中，每当BNEP帧需要被递送到L2CAP时，就可以使用图4a中描述的算法。
首先，BNEP帧必须被分类以便理解其是否必须被压缩。事实上，只有运送RTP/UDP/IP分组的BNEP帧必须用建议的ROHC-BNEP算法来处理。
下面的BNEP标题域被检查-BNEP目的地地址(对端必须有ROHC功能)
-BNEP协议类型(必须是“IP”或“IPv6”，对于以太网帧标记，IEEE802.1p和IEEE802.1q也必须被解释，这是因为它们也被用于具有QoS支持的LAN中)-IP协议类型(必须是UDP)-UDP端口(必须对应于H.323)如果BNEP帧必须被压缩，则其ROHC上下文被检索并且所得到的压缩帧需要利用对应于不可靠信道的L2CAP CID(L-CID)被发送到L2CAP层。如果该帧不是必须被压缩，则替代地使用可靠信道的L-CID。
在接收机中，如图4b所描述，如果帧从对应于ROHC-BNEP L-CID的不可靠信道到达，则假设ROHC-BNEP解压缩必须被应用。在成功重建之后，该帧被递送到BNEP层。
在压缩帧不能被正确地重建的情况下，其在解压缩器中被丢弃。在N2个连续压缩分组不能被重建之后，利用不可靠信道和ROHC反馈分组类型，否定ACK被发送回对端ROHC压缩器(对于ROHC算法的描述参见后面章节)。N2被设置为例如15。
对于ROHC-over-BNEP方案的框图如图5所描述。ROHC编解码器和所有相关的逻辑可以用软件产品的形式被实现，该软件产品与蓝牙TM网接口软件驱动器关联运行。这个软件产品包括BNEP和L2CAP层、帧分类器、ROHC编解码器以及管理实体(ME)，其协调各种块。ME可以通过标准的HCI接口(当存在时)与BT基带通信以及利用操作系统特定机制与上层通信。
每次移动终端MT1-n连接到AP1-n，ME就登记其MAC地址并且为其配置逻辑信道。在蓝牙TM中，逻辑信道以两个称作L2CAP信道ID(L-CID)的信道端点为特征。一旦信道建立，每个对等端就指定其自己的本地L-CID并且将其发送到远程设备。因此，为了ROHC，下表可以被建立。
表9-AP的ROHC-BNEP示例配置在表9的例子中，AP1连接有两个移动终端MT1，2。MT1配置了两个逻辑信道，一个用于正常IP业务量并且一个用于VoIP。这第二个信道将使用空的ROHC上下文ID。当MT2连接到接入点AP1时，其为VoIP配置信道在这种情况下空R-CID也可被使用。但是，当MT1为第二个RTP/UDP/IP/BNEP流配置另一个信道时(第4行)，因为现在MT1有两个必须被单独处理的实时流(例如一个语音信道以及一个视频信道)，所以不同的ROHC上下文必须被使用。
通过在移动终端和接入点之间应用这里公开的建议的健壮标题压缩技术，可能节省带宽，从而处理相同微微网中更多数量的连接。
虽然本发明关于优选实施方案被特别显示和描述，但是本领域的技术人员应该理解在不背离本发明的范围和精神的情况下可以有形式和细节的改变。
词汇表
权利要求
1.一种用于在第一个单元和第二个单元之间的基于分组的无线传输的方法，所述方法包括一个所述单元a) 将实时比特流转换成预定最大长度的一个或多个有效负荷；b) 将一个或多个预定义标题应用于所述或每个所述有效负荷以便生成适合于根据预定义通信协议在所述单元之间传输的分组；c) 将所述或每个所述分组封装在适合于跨越所述单元之间的无线连接传送所述或每个所述分组的封装协议的帧里；以及d) 将预定义的标题压缩技术应用于所述或每个所述封装的分组中。
2.根据权利要求1所述的方法，包括从包含诸如互联网协议上的语音(VoIP)、音频或视觉流之类的互联网协议(IP)业务量的一个所述实时比特流中生成所述或每个所述有效负荷。
3.根据权利要求1或者权利要求2所述的方法，包括执行所述第一和第二个单元之间的业务发现过程以及在所述业务发现过程期间通告所述标题压缩技术。
4.根据前面任何一个权利要求所述的方法，包括配置一个或多个分段，重新组装以及多路复用所述预定义通信协议的业务以便运送压缩的比特流。
5.根据前面任何一个权利要求所述的方法，包括通过向适合于应用所述标题压缩技术的压缩器和解压缩器的上下文中添加封装协议信息来应用所述标题压缩，所述信息包括例如所述封装协议的静态标题域。
6.根据前面任何一个权利要求所述的方法，所述单元包括蓝牙TM网的一部分并且所述方法包括利用包括蓝牙TM网封装协议(BNEP)的封装协议来封装所述或每个所述分组。
7.根据权利要求6所述的方法，包括优选地通过将所述预定的标题和BNEP标题的组合缩短到例如3字节的预定长度，来用所述标题压缩技术将所述或每个所述封装的分组压缩到单一时隙蓝牙TM基带分组中。
8.根据前面任何一个权利要求所述的方法，包括以诸如由互联网工程任务组(IETF)通过的ROHC之类的健壮标题压缩(ROHC)框架的形式来应用所述标题压缩技术。
9.根据权利要求8所述的方法，包括下列的一个或多个a) 为所述分组使用实时协议(RTP)概况；b) 使用IETF ROHC双向最有利方法(o模式)；c) 使用小ROHC上下文标识符(R-CID)，空R-CID是缺省值；d) 不发送通用数据报协议(UDP)校验和，可选地在解压缩器中对其重新计算；e) 在任何一个分组流期间将整个封装协议标题考虑作为静态上下文的一部分；f) 仅发送实时协议(RTP)序号和/或互联网协议身份；g) 定义压缩器中的“初始化和刷新”(IR)、“第一级”(FO)和“第二级”(SO)状态之间以及解压缩器中的“没有上下文”(NC)、“静态上下文”(SC)以及“全上下文”(FC)状态之间的转移。
10.根据前面任何一个权利要求所述的方法，包括将封装帧分类使得只有预定的所述帧利用所述标题压缩技术被压缩。
11.根据前面任何一个权利要求所述的方法，包括根据实时协议(RTP)、通用数据报协议(UDP)以及互联网协议中的一个或多个将标题应用于所述有效负荷。
12.根据前面任何一个权利要求所述的方法，包括所述单元配置多个逻辑信道用于这些单元之间的通信，至少一个所述信道专用于所述压缩的封装的分组的传送。
13.根据前面任何一个权利要求所述的方法，包括将所述标题压缩技术基于窗口一最低有效位编码(W-LSB)。
14.根据前面任何一个权利要求所述的方法，包括通过提供适合于错误恢复请求以及可选地地适合于上下文更新确认的所述单元之间的反馈信道来管理压缩器和解压缩器状态之间的转换。
15.根据前面任何一个权利要求所述的方法，包括一个所述单元接收被分段成基带分组的一连串所述压缩的封装的帧，在下一个所述分组被传输之前肯定确认每个所述分组，以及如果在最近的所述分组或者确认消息中出现传输错误，则所述最近的分组被重传。
16.根据权利要求15所述的方法，包括如果下列情况的至少一种发生，则重传所述分组a)基带分组存取码没有被接收；b)在基带分组标题中出现无法纠正的错误；或者c)在所述分组的所述有效负荷中存在无法纠正的错误。
17.根据前面任何一个权利要求所述的方法，包括例如通过设置所述帧的成功递送的超时来限制对于一个所述压缩的封装的帧的多个重传。
18.一种用于执行第一个单元和第二个单元之间的基于分组的无线传输的软件产品，所述产品包括执行以下操作的代码a)将实时比特流转换成预定的最大长度的一个或多个有效负荷；b)将一个或多个预定义标题应用于所述或每个所述有效负荷以便生成适合于根据预定义的通信协议在所述单元之间传输的分组；c)将所述或每个所述分组封装在适合于跨越所述单元之间的无线连接传送所述或每个所述分组的封装协议的帧中；以及d)将预定义标题压缩技术应用于所述或每个所述封装的分组。
19.一种基于分组的无线通信设备，包括适合于基本上实时地向第二个单元发送信息的第一个单元，所述第一个单元适合于a)将实时比特流转换成一个或多个预定最大长度的有效负荷；b)将一个或多个预定义标题应用于所述或者每个所述有效负荷以便生成适合于根据预定义的通信协议在所述单元之间传输的分组；c)将所述或每个所述分组封装在适合于跨越所述单元之间的无线连接传送所述或每个所述分组的封装协议的帧中；以及d)将预定义标题压缩技术应用于所述或每个所述封装的分组。
20.根据权利要求20所述的无线通信设备，所述第一个单元根据蓝牙TM协议操作，所述封装协议优选地包括蓝牙网封装协议(BNEP)并且所述标题压缩技术优选地与互联网工程任务组(IETF)健壮标题压缩(ROHC)技术兼容。
21.一种适合于根据权利要求1到19的任何一个所述的方法来操作并且优选地至少临时地被配置为蓝牙TM通信网的主单元和从单元中的至少一个的无线通信单元。
全文摘要
一种用于第一个单元AP和第二个单元MT之间的无线传输的方法被公开。所述方法包括所述单元AP、MT将实时比特流(例如VoIP、音频和视频)转换成预定最大长度的一个或多个有效负荷。一个或多个预定义标题(RTP/UDP/IP)被应用于所述或每个所述有效负荷以便生成适合于根据预定义的通信协议在所述单元AP、MT之间传输的分组。然后所述或者每个分组被封装在适合于跨越在所述单元MT、AP之间的无线连接发送所述或每个分组的封装协议(BNEP)的帧里。然后预定义的标题压缩技术(IETF ROHC)被应用于所述或者每个封装的分组。
文档编号H04L12/56GK1636374SQ02822036
公开日2005年7月6日 申请日期2002年10月24日 优先权日2001年11月6日
发明者D·梅皮纳诺 申请人:皇家飞利浦电子股份有限公司