Linux 网络电话会议:改进无线网络
第三代蜂窝标准机构 (3G) 的一个既定目标是使无线网络能够作为互联网和其他基于 IP 的分组网络服务的无缝扩展来运行。我们仍在等待的开创性工作的大部分负担已从公司转移到标准机构,再到互联网工程任务组 (IETF)。IP 透明性将大量服务扩展到已经拥有互联网有线连接的用户的移动设备,并简化和方便添加专门为增强无线体验而设计的新颖和更具创意的服务。一个显而易见的结果是 3G 运营商成员的客户对无线通话时长的需求增加。
用于宽带数据传输的可用带宽既有限又昂贵。在英国,支持 3G 服务所需的频谱许可证已拍卖给网络运营商,价格为 360 亿美元。最近,美国联邦通信委员会 (FCC) 在类似的拍卖中为美国运营商筹集了 170 亿美元的净收入。这促使运营商提高频谱利用效率。将 IP 用作语音传输机制(例如,VoIP)要求无线网络承载实时多媒体,即使它还在努力处理非实时多媒体。例如,GSM 类型网络使用的全速率语音编码器(如 G721.1)生成 30 毫秒(毫秒)的有效负载,并与 40 字节的组合 IP、UDP 和实时协议 (RTP) 标头交织在一起,如 H.323 国际电信联盟 (ITU) 协议中为多媒体交付所规定的那样。30 毫秒的语音有效负载通常转换为 20 字节,因此我们的效率仅为 33%。

图 1. H.323 数据包的频谱效率
向 IETF 提出的标头压缩算法将标头在稳定状态下减少到一个字节,但复杂性程度各不相同。标头压缩算法需要向移动设备呈现位精确的有效负载和封装的 IP 协议标头。这被称为无损压缩。
事实证明,标头压缩带来的好处是提高多媒体通信频谱效率的必要措施,特别是因为思科在 1990 年代后期提出的 CRTP 被 IETF 相关指导委员会以及第三代合作伙伴计划 (3GPP) 认为是不够的,或者不够稳健。
IETF 将选择哪种标头压缩算法的细节尚未完全确定。尽管如此,需求已经敲定,并在表 1 中进行了总结。事实上,当前的提案满足了许多需求,但充斥着知识产权——这与 IETF 的目标背道而驰。第二轮提案正在审议中,以便可以征集不同的方法。当前的算法利用了 IP/UDP/RTP 流的性质。表 3、4 和 5 分别对每个协议 IP、UDP 和 RTP 的标头字段性质进行分类。表 2 定义了分类。
这些算法的本质是源于这些分类的策略。它们是“永不发送”、“至少通信一次”、“至少通信一次或更新”、“频繁通信更新和/或刷新”、“保证持续稳健性”、“在所有数据包中按原样通信并建立”以及“准备更新增量”。
已经采用这种方法来压缩数据包标头的电信公司包括诺基亚、松下和思科,最值得注意的是爱立信,因为他们付出了巨大的努力。他们提出的算法的完整细节已以 IETF 草案形式提交,可以在 http://www.dmn.tzi.org.org/ietf/rohc/ 找到。
可以使用少量硬件和软件(即 Linux Box、一对 H.323 生成器和一些免费提供的库)对无线信道的影响和压缩算法的响应进行建模。模拟所有这一切所需的相当简单的设置只需三台计算机、一对扬声器和麦克风、几块额外的以太网卡和两条交叉电缆即可完成。软件也同样简洁,当与图 2 所示的设置结合使用时,我们获得了一个特别容易重现的系统。
开放 H.323 项目是生成符合标准的数据包所需的软件组件的绝佳来源。在网站 (http://www.openh323.org/) 上为 Linux 和 Windows 平台提供了两种替代方案。对于那些已经拥有 Windows 的用户,通常与操作系统捆绑在一起的 NetMeeting 提供了另一个版本的 H.323 兼容多媒体引擎。
重要的场景需要考虑在模拟信道的实现中,包括
启动——建立会话需要很高的稳健性,以便压缩器/解压缩器对可以按照前面提到的策略进入上下文。
切换——切换是移动设备移动速度的函数,丢包的数量服从参数为 9 的泊松分布。这种行为被认为是优雅的,因为第三代网络允许会话在会话切换中幸存下来,而无需重新启动。
深度衰落——这些是无线通信的敌人,是由无线电波发射比特的恶劣性质引起的。深度衰落通常归因于无线电信号的瞬时阴影以及来自拥挤区域的干扰的有害影响。这些是目前学术界关注的所有第三代蜂窝网络运行的主要限制因素。
在网络的中间安装了 Linux 机器后,我们深入研究 TPC/IP 堆栈,以便我们可以以模块化、非阻塞、输入/输出、实时、客户端/服务器的方式创建适配功能。实际上,我们通过在 IP 链中设置规则并使用 libpcap 接口将停止的数据包带到用户空间进行分析,并最终进行压缩/解压缩来停止数据包流。在物理上再现图 2 的架构后,建立一个不间断的网络电话会议会话就变得轻而易举,该会话的数据包被强制通过您的 Linux 机器。必须启用 IP 转发才能使其正常运行,特别是因为我们将使用 IP 链来停止数据包流。要验证 IP 转发是否确实已启用,请键入
echo /proc/sys/net/ipv4/ip_forwarding如果我们准备好转发数据包,则结果等于 1。下一步是验证我们是否可以在不终止会话的情况下停止和重新启动流。这意味着 TCP 数据包必须是不间断的。此时,我们只需要关注 IP/UDP/RTP 数据包。以下命令将停止和重新启动流
ipchains -P forward -DENY ipchains -P forward -ACCEPT-P 选项不区分协议;它将停止 ICMP、ARP、TCP 和 UDP 数据包。
现在我们可以处理数据流了,我们可以有选择地传输哪些数据流以及如何传输它们。
链路层 (LL) 是我们希望拾取数据包的位置,以便保留所有 IP 字段。数据包由网络堆栈接收并排队在一个名为 sk_buff 的链表结构中,在该结构中,它们由内核的顶半软件中断在 ip_input.c、ip_forward.c 和 ip_forward.c 中自动处理。有关套接字缓冲区如何在内存中管理的更深入处理,请参阅 Alan Cox 的“网络缓冲区和内存管理”(Linux Journal,1996 年 10 月)。大多数用户空间程序通过 Berkeley Packet Filter (BPF) 或 INET 套接字与网络堆栈接口。出于安全目的,这些套接字接口并非旨在深入到以太网或设备/物理层 (PL)。通过打开一个原始套接字来达成折衷方案,该套接字通过直接与堆栈的 IP 层交互来保留 IP 字段。虽然 Libpcap 支持以原始形式读取数据包,但只有通过修改 Libpcap 本身才能实现传输它们的能力。关于 TCP/IP 网络堆栈的权威文本可以在 W. Richard Stevens 的 UNIX 网络编程 第 1 卷中找到。对于更具体于 Linux 的主题处理,感兴趣的读者可以参考 David A. Rusling 在 Linux 内核 中的“第 10 章,网络”,可以在 www.linuxhq.com/guides/TLK/net/net.html 找到。
一种简洁地规避内核或 libpcap 的必要更改以完整地弹出原始数据包进出以太网设备的方法,是以 Perl5 CPAN 包的形式找到的,即 RawIP (http://quake.skif.net/RawIP/)。图 3 是一个示意图,它映射了 Linux TCP/IP 堆栈和内核 (2.2.x) 中负责处理要压缩的数据包流的代码。
列表 1 [在 LJ 的 ftp 站点] 是使用 Perl5 拾取停止的数据包、输出 IP id 字段内容并依次将它们传递到最终目的地的基本方法。源地址和目标地址的 IP 地址是唯一需要的参数。该脚本区分协议,因此我们现在可以专注于语音数据包,甚至结果证明是视频数据包。
该脚本创建一个文本文件 id_dump.txt,该文件在任何给定会话期间提供 IP id 的句柄。通过在脚本中引用其他字段来扩展这一点,是在创建实现提交给 IETF 工作组的任何提案的状态机中所需的第一步。列表 2 使用 Math::Random Perl5 CPAN 包来引入平均数据包或帧错误率,在 VoIP 的情况下,根据 20% 的均匀分布。当与列表 1 的网关结合使用时,其效果立即可区分,列表 1 的网关现在将开始采用高级无线信道模拟器的形式。认为这是腐败数据流的充分手段的理由是双重的。一个非常精确的 3G 宽带码分多址调制信道模型,具有多个 Raleigh 衰落路径,可以从 w3.antd.nist.gov/wctg/3G/3G.html 免费下载。它的使用虽然强烈推荐,但在没有 Beowulf 集群的情况下,可能会对会话的实时性产生巨大影响。此外,延迟将降低工程师在感知语音传输质量时经常依赖的系统性能的主观性质。
现在您已经拥有了所有适用的框架,下一步是将工作应用于视频数据包的分析及其对我们恶劣信道的弹性,或者将其打包到嵌入式系统中以创建低成本的网络电话会议工具。
