任 智,郭 黎,王 磊,苏 新
(重庆邮电大学通信与信息工程学院,重庆 400065)
在当今信息化时代,人们对高带宽和高速率的数据传输需求日益增加,而传统无线通信(2G~5G)的数据传输速率[1-2]低于10 Gb/s。毫米波通信是第5 代移动通信系统的替代方案之一[3],尽管毫米波频段的数据速率可以达到GB 级[4-5],但仍无法满足未来无线通信中不断增长的数据流量需求。因此,研究人员开始关注尚未完全发掘的太赫兹频段(0.1~10 THz)[6],并致力于太赫兹无线通信[7-9]的研究。
太赫兹无线通信满足5G 以上的超高速通信要求[10-12]。太赫兹波已成为第6 代通信技术(6G)的主要使用频段,即使在未来继续发展的第7 代通信技术中也需要太赫兹相关技术支持[13]。太赫兹相关技术的研究重点是太赫兹频段媒体接入控制协议[14],传统MAC 协议采用全向天线,但考虑到太赫兹传播损耗较大,所以研究者引入定向天线[15]以提高其传输性能。根据IEEE 802.15.3c 标准[16],网络中配备定向天线的设备在进行通信时需要进行波束赋形以获取节点位置。在波束赋形过程若按照标准所提供的方法执行,会产生n×n时间复杂度,带来不必要的开销,同时增大数据传输时延。经典的ENLBT-MAC协议[17]改进后是按照节点入网顺序进行波束赋形,其时间复杂度为O(n)~O(n2),但也会带来额外的控制开销。
随着频率增大,波束变得越窄[18],在60 GHz 的通信中,如此窄的波束用于波束赋形会产生浪费。针对此问题,文献[19]提出快速波束赋形方案,首先在低频段进行信道扫描及信令交互,通过在2.4 GHz频段确定方位角和发射角大致方位,然后在太赫兹频段进行定向数据传输,但该方案会增加设备成本。针对波束赋形产生的数据时延、Beacon 字段冗余等问题,文献[20]提出FED-MAC 协议,该协议只能对1/2 的区域进行优化,并没有考虑节点运动等情况。
本文提出太赫兹网络场景下节点移动感知的定向MAC 协议。通过引入微微网节点位置预估算法和动态场景节点位置感知机制,使协议在进行节点发现时只需要在目的节点所在范围内发送训练序列,从而减少不必要的控制开销。同时通过计算多个设备(DEV)的运动轨迹并预测其在下一时刻的位置,使源DEV 和目的DEV 能在目的DEV 发生移动后及时恢复已经断开的链路。
太赫兹网络应用在高速数据传输的场景,为了满足高速数据传输需求,需要制定相应的各层通信协议,其中MAC 协议作为太赫兹网络的核心协议,具有信道接入、信道资源分配等作用。太赫兹无线个域网的网络拓扑结构如图1 所示。
图1 网络拓扑结构Fig.1 Structure of network topology
整个网络由一个微微网协调器(Piconet Coordinator,PNC)和多个设备(DEV)组成。本文讨论的超帧结构如图2 所示。
图2 超帧结构Fig.2 Super-frame structure
该超帧结构与IEEE802.15.3c 标准协议的超帧结构一致,太赫兹无线个域网的网络运行时间由多个超帧组成,每个超帧由以下3 部分组成:1)信标时期(Beacon Period,BP)用于PNC 在每个波束方向上发送多个定向信标帧,该帧包含分配给DEV 的时隙信息、网络同步等信息;2)信道竞用时期(Contention Access Period,CAP)分为关联S-CAP(Sub-Contention Access Period,S-CAP)和常规S-CAP 两个子时段,关联S-CAP 中每个S-CAP 子时段用于节点向PNC 申请入网,常规S-CAP 子时段的每个S-CAP 子时段用于节点向PNC 申请时隙;3)信道时隙分配时期(Channel Time Allocation Period,CTAP)由信道时隙(Channel Time Allocation,CTA)组成,部分CTA 用于节点发现,部分用于节点间的数据交互。
在使用定向天线的条件下,太赫兹无线个域网按照15.3c 标准协议执行会出现以下2 个问题:
1)配备定向天线的节点与其他节点通信时,在空间进行循环往复扫描,以获取其他节点的位置信息。在3c/ad 标准中,根据划分的扇区,节点在每个扇区重复发送多个训练序列,以寻找目的节点,但目的节点只可能在源节点的某个范围内,对于其他方向的扫描和遍历,只会增加节点的发现时长。
2)在动态场景中,节点位置可能会发生变动。在标准和相关协议中,网络协调器PNC 需要全方位、周期性地发送完整信标消息,使得移动后的节点能准确接收到相应配置信息和时隙分配信息。但信标消息是整个网络中最大的控制消息。若盲目性、周期性发送这些消息使得整个网络性能变差,也会增加PNC 负载,进而影响数据传输时延和吞吐量。此外,节点发生移动后,源节点和该节点建立好的链路就会断开,需要重新进行节点发现,增大了数据传输时延。
针对上述存在的问题,本文提出太赫兹网络场景下的节点移动感知定向MAC(NMA-MAC)协议,该协议包含了微微网节点快速发现和动态场景节点位置感知2 种新机制。
在超帧CAP 时段,PNC 根据DEV 发送的时隙申请等消息,确定源DEV 以及目的DEV 所在位置,由此建立扇区-位置表,然后在物理层根据信号接收的强度指示(Received Signal Strength Indication,RSSI)机制计算出源DEV、目的DEV 的相对位置,最后将相对位置信息通过时隙申请回复帧告知给源DEV。此后,源DEV 与目的DEV 进行相互发现时,只需根据相对位置信息对目的DEV 进行相应握手,即源DEV 在知道目的DEV 的大致方位时,只需要在该方向发送波束赋形训练帧,目的DEV 旋转接收该训练帧。目的DEV 选择接收信噪比最强的扇区作为最佳扇区,并在该扇区向源DEV 发送训练帧。此时源DEV 旋转接收目的DEV 的训练帧,同样选择接收信噪比最强的扇区作为最佳扇区。这样就完成了一次握手过程,避免了源DEV 在每个扇区重复发送多个训练帧,从而减少节点发现时长,使源DEV 和目的DEV 更快速地找到彼此位置。相比原有协议,在新机制下源DEV 不需要全方位搜索目的DEV,根据PNC 提供的信息,可以更快地发现目的DEV,从而减少节点发现时间。
微微网节点快速发现流程如图3 所示,该机制在CAP 时段由PNC 执行。
图3 微微网节点快速发现流程Fig.3 Rapid discovery procedure of piconet node
步骤1PNC 在CAP 时段判断是否有节点申请时隙,若有,则执行下一步骤;若无,则结束本机制。
步骤2定向天线将无线空间以一定角度划分成多个扇区[21],每个设备扇区数量相同,PNC 根据每个扇区分布的DEV 数量,建立扇区-位置信息表。该表包含DEV 的编号ID、PNC 与DEV 的距离、DEV 所在扇区号、获知DEV 距离的时刻、目的DEV 的ID、相对位置信息。若有节点向PNC 发送时隙申请,则PNC 根据这些信息以及通过物理层RSSI 机制,将相关信息存入扇区-位置信息表。PNC 判断目的DEV与源DEV 是否进行过波束赋形,若没有,则转至步骤3;若有,则转至步骤5。
步骤3PNC 通过扇区-位置信息表计算出目的DEV 相对于源DEV 的位置,并将该位置信息填入扇区-位置表的相对位置信息中,转至步骤4。
首先以PNC 为原点建立坐标。1)若源DEV 与目的DEV 所在象限相对,则其相对位置为目的DEV所在的象限,如源DEV 在第一象限,目的DEV 在第三象限,则目的DEV 在以源DEV 为原点建立坐标的第三象限。2)若源DEV 与目的DEV 所在象限相邻,则其相对位置为源DEV 所在象限的相对象限与目的DEV 所在象限联合的象限区域。3)若源DEV 与目的DEV 所在象限相同,假设源DEV 距PNC 距离为x,目的DEV 距PNC 的距离为y,则进一步判断:
1)源DEV 与目的DEV 在同一扇区,若x
2)若不在同一个扇区,且源DEV 的扇区号为n,目的DEV 的扇区号为m,假设源DEV、目的DEV 所在象限为α(1≤α≤4),其中规定若Amod 4=0,则A=4(mod 求余)。若x 步骤4PNC 在回复DEV1 的时隙请求帧时,查看扇区-位置信息表,并将表中象限信息提取出来,在回复给DEV 的时隙请求时,将象限信息装入回复帧的帧头部MAC Header 的Index Stream 字段中,Index Stream 字段的前4 bit 分别对应1~4 象限,每位上的0 表示该象限不用做波束赋形,1 表示需要做波束赋形,通过该字段将象限信息给DEV1,转下一步。 步骤5在CTAP 时段,源DEV 根据PNC 回复消息,判断Fragmentation Control 中的保留字段是否为1,若是,则按新的节点发现机制进行;若不是,则按原有节点发现机制进行。 在默认情况下,当节点发生移动,为了使移动的节点能收到Beacon 消息,PNC 需要在每个方向循环发送该消息,从而使移动后的节点还能与网络进行同步,但这会造成很严重的时延以及控制开销。此外,源节点在没有目的节点位置信息情况下,需要重新对目的节点进行节点发现操作。新机制的主要思想是PNC 通过一种动态算法计算出移动后节点的位置,并且通过该位置信息针对性地发送Beacon 消息。另外,若该移动的DEV 在下个超帧的CTAP 时段没有参与数据收发,则PNC 向该DEV 所在位置发送Beacon 消息时,不需要在Beacon 消息中携带时隙分配信息。在下个CAP 时段,执行新机制1,把目的DEV 的位置告知给源DEV,使得源DEV 可以在具体位置对目的DEV 进行发现操作。 当节点发生移动时,首先,由PNC 建立扇区-DEV表,用于记录某个扇区经过移动可能出现的DEV;然后,通过CAP 时段收集DEV 的相关信息(ID、与PNC距离、获取时刻等),在CTAP 时段结束后,根据在CAP 时段收集到的信息,计算出该DEV 在本超帧结束时移动后的大致位置,根据该位置信息更新扇区-DEV 表;最后,在下一超帧的Beacon 时段根据表中信息自适应调整发送Beacon 帧的方向和Beacon 帧的内容。 1)在当前Beacon 时段,PNC 建立2 个扇区-DEV信息表,表1 记录当前超帧的各个扇区所对应的DEV,表2 记录当前超帧结束时,各个扇区可能出现的经过移动后的DEV。如表1 中扇区号为0,记录的ID 为1、3,表2 中扇区 为0,记 录ID 为1、5,表 示DEV3 和DEV5 都发生过移动。 2)在当前CAP 时段,PNC 判断是否有DEV 进行时隙申请,若无,则结束本机制;若有,则PNC 建立位置-信息表。通过物理层RSSI机制确定DEV 所在扇区、与PNC 距离、获取信息时刻,将这些信息填入表中,并在表中加入源DEV、目的DEV 的ID 信息,转下一步。 3)若某个节点发生移动,则在CTAP 的最后一个时隙开始,PNC 根据预先知道的节点最大运动速率vmax和每个扇区的角度α,以及上述步骤所得到的信息,计算出该节点可能运动到扇区的扇区号范围。然后将该DEV 填入扇区-DEV 表2 内所对应的扇区号所在栏,同时在表1 中删除该DEV。 扇区号范围计算方法是以PNC为中心建立坐标轴,网络覆盖范围半径为X的圆,设每个扇区角度为α,DEV的扇区号为ε(0 ≤ε≤360/(α-1)),DEV 与PNC 的距离为R,则DEV 位于该扇区半径为R的一段弧上,设获取该DEV 时刻为t1,CTAP 时段的最后一个时隙,假设PNC获取DEV 运动后的时刻为t2,已知DEV 最大运动速率为vmax,则DEV 在这段时间内运动的距离为L=vmax×(t2-t1)。微微网节点运动轨迹如图4 所示。 图4 微微网节点运动轨迹Fig.4 Motion trajectory of piconet node (1)若L≥R,说明在没超出网络范围的情况下,该DEV 可能运动到每个扇区,此时按照原有机制进行Beacon 帧的发送。 (2)若L 该DEV 下次可能出现的扇区号范围如式(1)、式(2)所示: 4)在下个Beacon 时 段,PNC 查找扇 区-DEV表2,若表为空,说明没有DEV 移动,则结束本机制;若表不为空,说明在前一个超帧结束时,DEV 发生移动,且PNC 已经计算如各个扇区DEV 的移动情况,继续执行下一步。 5)PNC 根据表1 和表2,推断DEV 的分布情况,然后向移动后的DEV 所在扇区发送Beacon 帧,对于那些经移动后空置的扇区不发Beacon 帧。此外判断该移动后的DEV 是否申请过时隙,若没有,则在Beacon 帧中删除时隙分配信息。 6)若移动的节点是某个DEV 的目的DEV,则在下个CAP 时段,继续执行新机制1,PNC 将移动后的节点位置告知给源DEV;否则结束本机制。 关于新协议性能,给出如下引理及相关证明。 引理1节点间在进行相互发现时,与IEEE80 2.15.3c 标准协议以及ENLBT-MAC 协议相比,NMA-MAC 协议节点发现过程中所产生的控制开销更小。 证明假设太赫兹无线个域网中有1 个PNC,每个PNC 的周围有m个DEV(m>1),DEV 产生的每个控制帧帧长为α,DEV 需要在Si(i=1,2,3)个扇区发送控制消息,每个扇区需要发送控制帧的总数为f。IEEE802.15.3c 协议中,节点发现过程所产生的控制开销为C1;ENLBT-MAC 协议中,节点发现过程所产生的控制开销为C2;NMA-MAC 协议中,节点发现过程所产生的控制开销为C3,如式(6)~式(8)所示: 由于协议所适用的网络模型相同,在新机制的操作下,NMA-MAC 协议节点发现过程中,不需要对全方位的扇区进行遍历,只需要对某个或某几个扇区进行遍历,所以S3 引理2与IEEE802.15.3c 标准协议以及ENLBTMAC 协议相比,NMA-MAC 协议在数据传输过程中的传输成功率将会更高。 证明传输成功率是指网络中目的节点接收到的数据量与源节点发送的数据量的比值。设IEEE802.15.3c 协议的 成功率 为P1,ENLBT-MAC 协议的成功率为P2,NMA-MAC 协议的成功率为P3,其中Nri(i=1,2,3)表示接收到帧的数量,Nsi(i=1,2,3)表示发送帧的数量,如式(9)~式(11)所示: 如果源节点持续向相同的方向发送数据帧,随着源节点的移动,可能会导致目的节点收到的数据帧会越来越少。而在新机制的作用下,PNC 可以预先知道移动节点的位置,然后将位置信息告知给源DEV,此时源DEV 可以根据该消息调整发送方向。由此可以得出Nr1≤Nr2≤Nr3,从而P1≤P2≤P3,得证。 引理3与IEEE802.15.3c 标准协议以及ENLBTMAC 协议相比,NMA-MAC 协议在数据传输过程中的吞吐量将会更高。 证明吞吐量是指单位时间内,目的节点收到的bit 数总和。超帧的长度一定,设网中节点数为N,CTAP 时段源DEV 向目的DEV 发送帧的总长为ldata,Pi为在太赫兹信道上发送数据帧的成功率,T为整个网络运行时间。设IEEE802.15.3c 协议的吞吐量为S1,ENLBT-MAC 协议的吞吐量为S2,NMA-MAC 协议的吞吐量为S3,如式(12)~(14)所示: 在网络拓扑和各节点参数相同的情况下,ldata和T都是相同的,由引理2 可知,P1≤P2≤P3,从而S1≤S2≤S3,得证。 本文利用OPNET 仿真工具模拟实际网络中业务,并主要研究随着节点数目的增加,对协议各性能指标的影响。仿真参数设置如表1 所示。 表1 仿真参数设置Table 1 Simulation parameters setting 不同协议的波束赋形控制开销对比如图5 所示。随着节点增加,各协议控制开销都有所上升,由于NMA-MAC 协议使用新的机制,使得运行网络所产生的的控制开销在网络饱和情况降低30.86%,仿真结果和引理1 分析一致。由于IEEE802.15.3c 标准协议需要在每个方向遍历,导致每个方向都会产生控制开销;而ENLBT-MAC 协议根据入网顺序进行遍历,产生的开销会相应减少,但仍然需要在每个方向进行遍历。NMA-MAC 协议使用新机制不需要在每个方向进行遍历,只在有节点的方向产生所需要的开销,所以总开销更小。 图5 不同协议的波束赋形控制开销对比Fig.5 Beamforming control cost comparison among different protocols 不同协议的消息传输成功率如图6 所示。当节点数从10 增加到13 时,网络中某些节点发生了移动。相比IEEE802.15.3c 标准协议,NMA-MAVC 协议的网络传输成功率增长了4.575%,仿真结果和引理2 分析一致。由于存在节点移动的情况,当节点发生移动后,IEEE 802.15.3c 协议或ENLBT-MAC 协议的源节点在原方向发送数据,此时目的节点收不到该消息,在下个超帧中,源DEV 与目的DEV 需要重新进行节点发现后,再进行数据传输,此时源节点重复发送了相同数据,而目的节点只接收到一次数据。而NMA-MAC 协议下源节点通过PNC 预先知道目的DEV 的位置,只需要向移动后的方向发送一次数据,从而提升数据消息传输成功率。 图6 不同协议的消息传输成功率对比Fig.6 Message transmission success rate comparison among different protocols 不同协议的吞吐量对比如图7 所示。相比IEEE802.15.3c 标准协议,NMA-MAC 协议的吞吐量增加了13.28%,仿真结果与引理3 分析一致。3 种协议在节点没有发生移动的情况下,吞吐量的走势是差不多的,若节点发生移动,使得IEEE802.15.3c 标准协议和ENLBT-MAC 协议的吞吐量发生短暂下降,而后节点需要重新进行波束赋形重新发现节点,吞吐量又逐渐开始上升。在节点移动后,NMA-MAC 协议通过计算获取移动节点位置,然后动态调整数据发送方向,其吞吐量不会呈下降的趋势。随着节点数的增加,各协议的吞吐量逐渐趋于平稳状态。 图7 不同协议MAC 层吞吐量对比Fig.7 MAC layer throughput comparison among different protocols 不同协议的数据传输时延如图8 所示。从图8 可以看出,在不同节点场景下3 种协议的数据传输时延的差别不是很大。随着节点个数增加,由于申请时隙的节点个数逐渐增多,而超帧的长度是不变的,每个节点被安排的时隙也会推后,因此时延逐渐增加。而NMAMAC 协议通过减少在部分扇区的扫描时间,从而调整常规S-CAP 的长度,PNC 有足够时间处理节点的时隙申请,可以缩短数据的传输时延。 图8 不同协议平均时延对比Fig.8 Average delay comparison among different protocols 本文提出一种太赫兹网络场景下的节点移动感知定向MAC 协议。在分析节点波束赋形的过程中,采用软件建模方式模拟微微网中节点的运动状态,引入微微网节点快速发现和动态场景节点位置感知机制,并使用归一化方法分析网络性能指标。仿真结果表明,相比IEEE802.15.3c 标准协议和ENLBT-MAC协议,NAM-MAC 协议能有效提高吞吐量和消息传输成功率,降低数据平均时延。后续将利用定向天线空分复用的特点,对太赫兹定向并行传输协议做进一步优化。2.2 动态场景下的节点位置感知机制
3 协议性能分析
4 仿真分析
4.1 控制开销
4.2 传输成功率
4.3 吞吐量
4.4 平均时延
5 结束语