通信网络如何突破毫秒障碍

通信网络

633人已加入

描述

 

对于通信网络来说,带宽一直是王道。每一代光纤、蜂窝网络或Wi-Fi技术在吞吐量上的飞跃,都让我们的网络生活更丰富。20年前,我们只能在手机上进行短信交流,而现在已经对YouTube和网飞(Netflix)上的视频习以为常了。因此现在视频占据互联网带宽的60%也就不足为奇了。如果这一趋势持续下去,我们可能会看到全动态的全息影像发送至手机,这是自《星球大战》中出现全息影像(莱娅公主请求帮助时的场景)以来便存在的一个技术梦想。  不过,最近低延迟这一不同于高带宽的优点也开始受到关注。根据信号在网络中的传播距离、通过的路由器数量、使用有线还是无线连接等,延迟时间有很大不同。例如,4G网络的延迟通常为50毫秒。将延迟时间降低到10毫秒(正如5G和Wi-Fi目前所做的那样),能够为一系列单靠高带宽无法实现的应用打开大门。

比如,在虚拟现实耳机中,如果跟随头部运动渲染和显示图像时的延迟超过10毫秒,人会非常容易感知到,而且会产生一种迷失方向的感觉,有点类似于晕船。  多人游戏、自动驾驶汽车和工厂机器人也需要极低的延迟。尽管5G和Wi-Fi使10毫秒成为了新的延迟标准,但研究人员(比如我所在的纽约大学无线研究中心团队)已经在努力实现另一个数量级的延迟降低,致力于将10毫秒降低到1毫秒甚至更低。 将延迟降低到1毫秒需要重新设计通信过程的每一步。过去,工程师们忽略了造成微小延迟的源头,因为它们对整个延迟来说微不足道。现在,研究人员必须开发新的数据编码、传输和路由的方法,以消除哪怕是最小的延迟来源。不可改变的物理定律,特别是光速,将对延迟为1毫秒的网络做出严格限制。适用于各种极低延迟网络的万能技术并不存在。只有把针对所有这些延迟源的解决方案结合起来,才有可能建立丝毫不浪费时间的网络。  

 

直到20世纪80年代,延迟敏感技术使用的都是专用的端到端电路。例如,电话是在电路交换网络上进行的,会在通话者之间建立一个专用链路以保证最小延迟。即使在今天,打电话也需要端到端的延迟小于150毫秒,否则人们很难轻松地交谈。 与此同时,互联网使用了分组交换等技术来传输延迟容忍流量,如电子邮件。分组交换相当于互联网上的邮政服务,邮件通过邮局路由到达正确的邮箱。数据包(或者说40到1500字节之间的数据包)从A点发送到B点,在B点按正确的顺序重新组装。使用20世纪80年代的可用技术,延迟通常超过100毫秒,最严重的延迟甚至远超1秒。 最终,网络电话(VoIP)技术取代了电路交换网络,现在供应商正在淘汰最后一批电路交换机。

VoIP取得成功后,延迟进一步降低,我们也进入了几十毫秒延迟范围的时代。 低于1毫秒的延迟将为人们长期以来一直寻找的应用程序开辟新类别。触觉交流(或称传递触觉)便是其中之一。想象一下用指尖平衡铅笔。当你看到铅笔开始倾斜,然后移动手指保持它的平衡,这两者之间的反应时间以毫秒为单位。一个由人类控制、有触觉反馈的遥控机器人需要达到类似的延迟水平。

自动驾驶

非人类控制的机器人也将因1毫秒的延迟而受益。就像人一样,机器人只有在1毫秒内做出反应,才能避免摔倒或掉落东西,但处理实时反应的强大计算机和供它们运行的电池都很重。如果机器人的“大脑”能被存放在一个低延迟的无线网络上,机器人就可以变得更轻,操作时间更长。

在深入了解工程师们构建超低延迟网络使用的所有方法之前,先了解一下数据从一台设备传输到另一台设备的过程会很有帮助。当然,信号必须沿着设备之间的传输链路进行物理传输。信号的传输并非仅受光速的限制,沿途的交换机和路由器也会造成延迟。甚至在这之前,数据必须进行转换,并在设备上为传输做好准备。所有这些过程都需要重新设计,以统一达到亚毫秒级的延迟。

 

我的研究集中在管理互联网数据交换的多层协议中的传输层。这意味着,我关心的是控制传输速率并检查确保数据包以正确顺序到达目的地且没有出错的那部分通信网络。虽然设备本身确实存在一些小的延迟源,但我将重点讨论网络延迟。

第一个问题是帧持续时间。无线接入链路(将设备连接到更大的有线网络的链路)会在名为“帧”的周期性间隔内进行传输调度。4G链路的帧持续时间通常是1毫秒,所以如果只是等着轮到你进行传输的话,这1毫秒可能就浪费了,而5G缩小了帧持续时间,减少了它们对延迟的影响。

自动驾驶

Wi-Fi的运行活动则不同。Wi-Fi网络不使用帧而使用随机访问,设备会立即传输信号,如果在链路中与另一设备的传输发生冲突,则会重新安排传输。其中好的一面是,在没有拥塞的情况下,这种方法的延迟较短,但更多的设备竞争同一信道传输时,延迟就会迅速增加。最新版本的Wi-Fi Certified 6(基于IEEE P802.11ax标准草案)引入了计划传输(scheduled transmission)来解决拥塞问题,就像4G和5G网络一样。

数据包通过一系列连接其源点和目的地的网络链路时,也会受到拥塞延迟的影响。数据包常常不得不在链路上排队,因为通过链路传输的数据量和可用带宽的数量都会随着时间的推移而发生自然波动。例如,晚上更多数据量大的视频流会造成链路拥塞延迟。通过一系列无线链路发送数据包,就像用一根长度和直径持续变化的吸管喝水一样。由于延迟和带宽的变化,前一秒你可能会吸走一点点数据,而下一秒则可能会收到更多数据包,超过你的处理能力。

拥塞延迟是不可预测的,因此无法完全避免。传输控制协议(TCP)负责减轻拥塞延迟,它是一系列管理计算机相互通信方式的互联网协议的一部分。最常见的TCP实现方式(如TCP Cubic)是通过感知网络路由器的缓冲区何时达到满负荷来测量拥塞的。满负荷时,数据包会发生丢失,因为没有空间来存储它们了。可以把它想象成一个放在水龙头下、有孔洞的桶。如果水龙头注入桶里的水多于通过孔洞排出的水,那么它就会慢慢装满,直到水最终溢出。本例中的桶即是路由器缓冲区,如果它“溢出”,数据包就会丢失,需要再次发送,从而增加延迟。接下来,发送方会调整其传输速率,以避免再次淹没缓冲区。 问题是,即使缓冲区没有溢出,数据仍然会被卡住,因为要排队等待通过水桶的“孔洞”。我们要做的是让数据包在网络中流动起来,而不必在缓冲区中排队。YouTube的目标也是如此,它采用了谷歌开发的TCP变体——TCP BBR(瓶颈带宽和往返传播时间),其工作原理是调整传输速率,直到其匹配数据通过路由器的速率。回到水桶类比,便是不断调整水龙头流出的水流量,使其与水桶孔中流出的流量保持一致。

自动驾驶

为了进一步减少拥塞,工程师们必须处理以前忽略的微小延迟,比如,在轮流访问无线链路期间,每个特定数据包传输所花费的时间上的微小变化。另一个例子是不同软件协议在计算时间上的细微差别。这两者都会干扰TCP BBR的判断能力,即判断在不使容量闲置或造成通信阻塞的情况下,把数据包注入连接所需要的确切速率。

我研究的一个重点是重新设计TCP以实现低延迟,同时与网络上的其他连接公平地共享带宽。为此,我们团队正在研究现有的TCP版本,包括BBR和互联网工程任务组的L4S(低延迟低损耗可扩展吞吐量)等。我们发现,这些现有版本倾向于注重特定的应用程序或情况。例如,针对YouTube视频,BBR得到了优化,YouTube视频数据的到达速度通常比观看速度快。这意味着BBR忽略了带宽变化,因为过量数据缓冲区已经将数据送达最终用户。

另一方面,L4S允许路由器优先处理时间敏感数据,比如实时视频包。不过并不是所有路由器都能做到这一点,而在这些情况下L4S就没那么有用了。 我们团队正在研究如何利用这些TCP版本中最有效的部分,并将它们组合成一个用途更广的整体。到目前为止,我们最有希望的方法是让设备持续监控数据包延迟,并在延迟增加时降低传输速率。有了这些信息,网络上的每台设备都可以独立计算出自己能向网络注入多少数据。这有点像购物者在繁忙的杂货店观察结账队伍,看哪些队伍走得更快,或者队伍更短,然后选择加入哪些队伍,这样就不会出现太长的队。

具体来说,无线网络要可靠地实现低于1毫秒的延迟,还会受到连接切换的阻碍。当手机或其他设备从一个基站(通常称为蜂窝塔)的覆盖区域移动到相邻基站的覆盖区域时,必须切换其连接。网络检测到来自第一个基站的信号强度下降而第二个基站的信号强度相应上升时,就会启动切换。切换发生在信号强度变化的几秒钟或更长时间窗口内,因此很少会中断连接。

不过,现在5G正在探索频率超过20千兆赫兹的毫米波,这带来了前所未有的障碍。这些频段以前从未使用过,通常它们的传送距离不如低频率远,这一缺点直到最近才通过波束形成等技术得以解决。波束形成的工作原理是使用一组天线将狭窄的聚焦传输直接指向目标接收器。可惜,行人和车辆等障碍物会完全阻挡这些光束,导致频繁出现连接中断。 为避免此类中断,可选择建设多个覆盖区域有重叠的毫米波基站,这样一来,如果一个基站被阻挡,另一个基站可以接管。

不过,与常规的蜂窝塔切换不同,这些切换更频繁且不可预测,因为它们是由人和流量移动引起的。 我所在的纽约大学团队正在开发一种解决方案,将相邻的基站通过光纤环形网络连接起来。所有传输到这组基站的流量都将注入环路,然后在环路中循环。数据在环路上传输时,任何连接到手机或其他无线设备的基站都可以对其进行复制。如果一个基站被阻,下一个基站可以试着向设备发送数据。如果它也被阻,那么后面的基站可以试试。想象一下机场的行李传送带,旅客站在附近等待自己的行李。旅客可能会被传送带周围拥挤的人群“挡住”,所以可能不得不走到一个不那么拥挤的地方。同样,只要移动设备位于至少有一个未受阻的基站范围内的任何地方,光纤环路系统就允许接收。

自动驾驶

 

 

光速是最后一个不能再被忽视的不变的延迟源。光的传播速度非常快,所以过去有其他更大的延迟源时,我们可以忽略它,但现在不能再忽视它了。 以我们前面讨论过的机器人为例,它的计算“大脑”位于云端服务器中。服务器和大型数据中心通常距离终端设备数百公里。由于光以有限的速度传播,在这种情况下,机器人的大脑不能离得太远。无线通信信号以光速移动,每毫秒传输大约300公里。光纤中的信号更慢,大约为200公里/毫秒。

最后,考虑到机器人需要在不到1毫秒的时间内往返通信,因此机器人与大脑之间的最大可能距离约为100公里。这就忽略了所有其他可能的延迟来源。 对于这个问题,我们看到的唯一解决方案就是简单地从传统的云计算转向所谓的边缘计算。事实上,对亚毫秒延迟的追求也在推动边缘计算的发展。这种方法将实际计算放在了尽可能靠近设备的地方,而不是在几百公里以外的服务器农场。不过,要在用户附近找到放置这些服务器的大楼,对服务提供商来说成本高昂。 毫无疑问,随着研究人员和工程师朝着1毫秒延迟的方向努力,他们会发现更多我没有提到的延迟来源。每一微秒都很重要的时候,他们就不得不创造性地把最后几毫秒缩减到1毫秒。最终,人们期望实现的超低延迟的用途,将驱使我们实现相关新方法和新技术。

自动驾驶

在互联网的发展初期,没有人知道什么是杀手级应用程序。大学因远程访问计算能力或促进大文件传输而感到兴奋。美国国防部看到了互联网的分散性在通信基础设施遭到攻击时的价值。不过真正提高使用率的是电子邮件,它与普通人更加息息相关。同样,虽然工厂机器人和远程手术肯定会受益于亚毫秒级延迟,但很有可能两者都不是这些技术的杀手级应用。事实上,我们可能无法自信地预测究竟什么会驱使微小延迟消失。不过,我认为应该会是多人游戏。

作者:Shivendra Panwar

 

 

 

编辑:黄飞

 

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分