CTC 技术介绍概述——啃论文系列

文章目录

  • CTC 技术介绍概述——啃论文系列
    • 自我介绍
    • 摘要
    • 前言
      • 知识导图
    • 1. 定义
    • 2. 诞生背景
      • 2.1 频谱紧张
        • 例子,wifi的5GHz
      • 2.2 通信干扰——CTI
      • 2.3 管理困难
      • 2.4 异构通信
        • 传统实现——网关桥接
      • 2.5 CTC——异构直接通信
    • 3. 包级CTC
      • 3.1 基于RSSI
      • 3.2 基于CSI
        • ZigFi
    • 4. 物理级CTC
      • 4.1 接收透明
        • WEBee
      • 4.2 发送透明
        • XBee
      • 4.3 不透明
        • TwinBee
    • 5. 各种类型的CTC比较
      • 5.1 性能比较
      • 5.2 复杂度比较
    • 6. 未来展望
      • 6.1 研究现状
      • 6.2 未来展望
    • 7. 参考文献

自我介绍

大家好,我是物联黄同学,来自深圳技术大学。

我在OpenHarmony成长计划啃论文俱乐部,通过啃论文收获技术成长!

在我们俱乐部中不止有来自全国各大高校的优秀大学生,还有来自国内外一线企业、一线研发技术专家进行指导。

之前还发布过一篇啃论文技术文章,是关于代码编程提示框架相关的综述文献学习笔记,详见:自动化编程提示框架——啃论文笔记

摘要

本文主要是对CTC跨技术通信技术进行一个概述。在阅读参考文献得到的相关知识点基础上,结合自己的理解,主要内容有CTC的定义、诞生背景、包级以及物理级CTC、各种CTC技术对比,还有关于CTC的一些现状陈述和对其未来前景的展望。

比较重点的内容是两大类CTC的实现机制

本文从参考文献中筛选出了许多具有代表性的例子,结合所属的CTC技术可以更好理解。

前言

本人之所以接触到CTC这项技术是因为之前因为通信课的课堂展示,在查阅ACM文献时,无意间发现,初看综述文献被其技术亮点所惊艳。

到现在为了去更好的了解CTC技术,自己也查阅了许多文献,不只是这篇文章的参考文献,还有很多综述和非综述的学术文献,比较可惜的是虽然有许多技术文献可以查阅,但是到具体的实习时,这一块的开源案例比较少,这也是本人觉得比较可惜的地方。即使在后来找到了一些开源案例,发现在具体复现时难度也是比较大。我本人相对学术的研究,更喜欢从事学术的实践。

下图是我本人关于CTC技术介绍,也就是本文梳理的知识导图。

知识导图

1. 定义

  1. 全称 Cross Technology Communication,直译过来就是 跨技术通信。
  2. 旨在建立在遵循不同通信技术(诸如蓝牙,ZigBee,WIFI,移动通信)的异构设备之间的直接通信。
  3. 本质上做的是“翻译器”的工作。

2. 诞生背景

在看了关于CTC的不少论文,大致可以总结出这些背景原因:频谱紧张,通信干扰,管理困难,异构通信。

2.1 频谱紧张

很好理解,就是随着设备数量的不断增加,很容易出现在某个区域的某个时间节点上,某个频段的有大量的设备,无论是异构还是同构,只要在无线信道上传输信息,那就会使用到频谱资源,而多种通信技术共同使用,其实会使得频谱变得不够用,资源紧张。

例子,wifi的5GHz

一个很好的例子就是,我们都知道现在WIFI 已经支持了两个频段,2.4GHz和5GHz,但是在之前的802.11.n及之前的版本其实是不支持5GHz频段,当然802.11.ac 以及 最新的 802.11.ax 都是支持同时覆盖两大频段的。

而之所以从只支持2.4G到支持5G,个人认为主要原因是在原有的2.4G频段中,除了WIFI,还有系那个蓝牙,ZigBee等其他通信技术使用,这带来的问题就是这个频段信道拥挤,给WiFi的信道受限,传输质量,速率受到影响。

2.2 通信干扰——CTI

这里的干扰主要是来自异构设备,当然同构设备其实也会产生干扰。CTI就是跨技术干扰(Crooss Technology Interfere)。

干扰的原因,其实就是传输信息产生碰撞。对于同构设备,我们知道,可以采用CSMA做防碰撞处理,但是像异构设备其实就很难用CSMA去做碰撞检测。

为什么?因为,CSMA的原理其实就是双方发一个信号然后根据信号的回应情况来确定是否发生了碰撞。但是异构设备,就比如我们最熟悉的蓝牙和WIFI设备,很明显WIFI设备的功率要更强,可以覆盖的范围相对更广,这种范围的不对等,就造成在发生碰撞时,蓝牙设备可以感知到WIFI设备的传输信息,而WIFI却不行,因为蓝牙设备发送的数据还没到wifi设备,可能就衰退到无法被检测到的情况。

2.3 管理困难

这个也是当下物联网场景会遇到的问题,就是在一个环境下有很多包括同构,异构的设备同时通信,那么显然需要一个好的方式去管理调度这些信道的使用。

如果是同构设备,还是比较好管理的。像我们熟知的移动通信中的FDMA、CDMA、OFDMA等宽带,信道资源分配调度方式,可以实现多设备的通信。

但是对于异构设备,显然要实现还是比较麻烦的。

2.4 异构通信

个人认为这是CTC提出的最直接,最针对性解决的背景原因。

传统实现——网关桥接

传统实现异构通信,其实就是使用网关,包括现在的很多智能家居系统不同的异构设备其实都是采用这种类似的实现方式。通过类似网关的设备,进行一个无线技术的转换,也可以理解为协议的转换。

网关传输的过程如图所示(画的有点丑)

从图片可以看出来其实就是做了两次同构通信了。这其实带来了很多问题:

  1. 使用了多的硬件,或者软件,需要至少多一次的解码和编码,以及信号调制,带来通信开销较大。
  2. 差错检验,网关不一定具备检验传输差错的能力,那么很有可能会造成传输差错而无法被有效检验到。
  3. 部署相对要更加复杂。

2.5 CTC——异构直接通信

CTC的提出其实就很好解决了上述的问题。

  1. 频谱资源以及管理上,如果CTC能够实现,其实就可以在信道内的传输数据进行统一化管理,管理成本降低的同时,频谱资源也就不会过于紧张。
  2. 克服CTI,通过CTC建立侧信道等方式可以有效解决CTI问题。
  3. 直接通信,降低异构通信的成本,有效优化设备部署。

CTC可以分为两类,包级CTC和物理级CTC,前者是通过建立侧信道作为信息传输载体,后者是通过相对来说更加复杂的加解码实现传输。

3. 包级CTC

其实就是利用包传输,在CTC早期,很多研究是是在发送端进行特殊的编码,将数据包的一些特征(能量、大小等)进行特别化,而接收方就是通过所接收到信号强度指示RSSI(received signal strength indication),RSSI采样其实在很多现有的无线通信协议(诸如蓝牙、WIFI等)物理层即MAC层中在接收端都采用这种信息采样方式。

除了基于RSSI,包级CTC还有另外一种主流的实现方式,基于信道状态特征CSI(channel state information)。这一类方法适合用于WIFI作为接收端的场景,WIFI通过分析相应子载波CSI值,从而感知到像蓝牙,ZigBee等异构设备的传输。这些异构设备通过影响频段信道中正在WIFI传输的CSI值,构建侧信道实现异构设备对WIFI传输信息。在近年中关于包级CTC各项研究中,这种方式随WIFI设备在广泛应用而发展。

3.1 基于RSSI

在基于RSSI的包级CTC中,发送方和接收方都通过在信道中产生和感知某种RSSI序列通信。如下图所示,作为接收方可以识别到有两个包,还能计算出包的大小和间隔,同时我们可以注意到从这张采样图可以看到数据包的RSSI值和环境噪声间有一个明显的能量差Energy Gap,这个能量差就可以作为一个建立CTC通信侧信道的基础。

基于RSSI的包级CTC在对数据包的编码调制上有多种实现,比较有代表性的有:能量、大小、时间以及数据包的内容。

  1. 能量:其实就是发送的数据包的能量级别来进行传输数据信息。当然这里有一个前提,WIFI设备和ZigBee设备的信道必须重叠

    1. 下图就是WIFi发送UDP包,ZigBee进行RSSI采样,发现一些单位区间的强度明显增大,这里根据能量明显强于某个级别就解码为1,否则就是0。

    2. 只有0和1其实相当于二进制,但是我需要通信,WIFI就需要发送数据包,利用这种数据包发送来改变ZigBee采样到的RSSI能量只能单纯变为1或0,其实很浪费的,所以就提出了WiZig,这个好处就是把能量等级划分了多级,这样子就可以在一个分组数据包的采样RSSI中读取更多信息了。

  2. 大小,接收端可以根据采样到的数据包和正常通信时的数据包比较大小,通过这样来解码为对应信息。

  3. 时间:(讲道理,我也没读懂)大致上就在正常通信时存在一定的时间区间,这个区间大小相对来说比较固定,可以在这个区间内进行通信,如果给传输数据附上时间戳之类的信息,其实接收端就可以识别出是否是CTC信号。

  4. 内容:注意这里的内容并不是数据包传输信息的内容,而是载荷的信息,这部分载荷在传输前会有一定的调制,接收端会检测RSSI信息特征和预先存储的特征集中的匹配后,对CTC信号解码得到通信信息。

3.2 基于CSI

CSI值包括了子载波级信道变化引起的相位变化和能量的衰减。通常被WIFI设备用来测量报文从发送端到接收端的过程中的信道变化。而异构设备在传输频段和传输时间上是可以重叠的,即信道重叠,这样子,异构设备就可以通过发送数据包等方式来影响同频率的WIFI子载波的CSI,实现和WIFI的通信。

这种方式的能够实现的核心之处在于——蓝牙,ZigBee的数据包足够长,WIFI子载波的带宽要比蓝牙,ZigBee的信道窄很多,这样子异构设备既可以连续命中多个WIFI数据包。对于WIFI接收端,可以连续接收多个数据包,如下图所示wifi接收端在一段时间内的CSI矩阵,其中蓝色的部分就是和明显的和其他相邻的子载波在CSI值有着明显的区别。

ZigFi

这个是个人认为比较有意思的设计,前面提到的基于CSI的朴素方式,其实就是异构设备发送产生数据发送,从而影响wifi子载波的信道CSI值,利用这些CSI差异来进行和wifi的通信。但是这样的方式存在一定的问题——可能会影响到原来的wifi通信。显然,我们并不希望出现这个问题。而ZigFi就是避免出现这个问题的设计,其基本思想是将ZigBee数据包对接在WiFi数据包上,且不破坏正在进行的WiFi传输。需要满足以下几个条件:

  1. 选择的子信道需要使ZigBee和WiFi在频域重叠。
  2. ZigBee报文长度必须足够大,使报文在时域上和WiFi报文重叠。
  3. ZigBee的功率需要适当,这样可以使得CSI序列更加独特。

满足上诉条件时,WiFi接收端就可以在正常WiFi通信时检查CSI值,利用ZigBee报文的存在与否对CTC信号进行解码实现基于CSI构建侧信道达到CTC通信的目的。

4. 物理级CTC

前面提到的包级CTC,他们的工作原理基本上都对现有的信道发送一定的数据,对信道或者接收端接收信息产生一定的影响,但是接收端并非直接读取这些数据,本质上那些数据其实是无效的,包级CTC是利用这些数据产生的影响,接收端通过解读这些影响,比如RSSI的能量,数据包的大小,CSI值等通过这些数值的差异来解码出CTC的内容。

但是显然这些CTC工作的效率是非常有限的,因为本身这些通信的吞吐量就相当有限。

  1. 无线数据包本身的持续时间是很短的,基本上都在毫秒范围内,要在这么短的间隔使用CTC通信,嵌入影响符号,其实是很低效的。
  2. 不能够充分利用带宽。比如从WiFi到ZigBee的过程,ZigBee的带宽在2MHz,而WiFi的带宽则为20MHz,如果采用RSSI,那么对于WIFI而言,剩余带宽内的信号就被浪费。

正是基于上述问题,物理级的CTC由此出现了。

在此表达一下个人观点,并不是说这个CTC名字叫物理级CTC,就一定采用了物理硬件实现的方式,个人认为物理级CTC其实是用极少的硬件或者不用硬件实现的可以高效传输,充分利用带宽等资源的CTC。相比于包级CTC,个人认为物理级CTC更专注于传输数据本身。

物理级CTC根据在通信过程中对发送方、接收方是否透明划分为三类,即:接收方透明CTC、发送方透明CTC、不透明CTC。

这个透明与否,个人认为是对于机器是否需要进行额外的调制或者解调制步骤对数据信号进行操作。

4.1 接收透明

接收透明,其实就是对于接收方对于接收到的数据不用任何修改,就可以直接解调信号,解调的协议遵从接收机设备本身。

基本原理主要是通过对发送机的有效载荷操纵来模拟接收机的可接收信号。

而根据接收方的不同,这一类的CTC又可以分为基于时域波形和基于相移序列两类。前者的主要代表有WeBeePMC,后者的则有 WIDEBlueBee

以下只介绍WEBee,其他的如果感兴趣可以从=参考文献中了解。

WEBee

值得一提的是WEBee是最早出现在学术研究中的物理级CTC设计。

WEBee实现的是操控WiFi发射机模拟ZigBee的时域波形,从而达到从WiFi到ZigBee的高速率CTC。

下图就是WEBee的体系结构,WiFi设备选择WiFi帧来模拟ZigBee报文,对于ZigBee在接收到数据时,会将WiFi的头、尾两部分视为噪声忽略,有效部分即为ZigBee数据包,可以被ZigBee成功解码。

而整个仿真过程则如下图所示,主要包括三部分:

  1. 正交调幅仿真QAM,也就是我们常说的星座图仿真。
  2. 信道编码仿真。
  3. 后QAM仿真。

其中,QAM仿真是WEBee的核心。如下图所示,整个过程反向进行,将所需的ZigBee时域信号送入到FFT(快速傅里叶变换),选择QAM星座点。因为理想的ZigBee时域信号的频率分量可能与WiFi的QAM点不完全匹配,导致QAM量化误差。针对这些问题,WEBee采用了更加宽松地设置最大汉明距离来容忍QAM模拟错误。

4.2 发送透明

和接收透明CTC不同,发送透明CTC是利用充分利用接收机的能力,无序对发射机进行任何修改,即可实现从低端发射机到高端接收器的通信。

发送透明CTC这里提到了三种设计,分别为XBeeLEGO-FiXFi。前两种是接收机干茶发射机信号的模式,实现交叉解码,而第三种则是利用WiFi接收端强大的计算能力,对发射机信号重构。

这里主要介绍XBee和交叉解码。

XBee

XBee 是一个从ZigBee到BLE的物理级CTC,主要采用了交叉解码的方法,通过观察在蓝牙接收器的信号,位模式来解释ZigBee帧。

交叉解码有以下的两个点:

  1. ZigBee接收器和蓝牙接收器都利用相移来解码信号。
  2. 对蓝牙接收端的相移量化,所以只使用相移的信号。

由于蓝牙的采样率是ZigBee的采样率的一半,所以采样左偏还是右偏决定了最终的解码效果。

4.3 不透明

不透明CTC就是对发送端和接收端都修改,这一类的部分设计像 TwinBeeLongBee等是为了增强CTC的 鲁棒性,其他的如果 ChironPIC 等实现不同无线协议之间的并行通信。

TwinBee

这是一种增强CTC鲁棒性的非透明的CTC设计。它是为了恢复 WEBee 不完全信号仿真引起误差,设计了一种特殊的芯片组合编码方法来恢复易错芯片中的错误。

芯片组合编码的基本思想是利用ZigBee芯片序列的循环移位特性将易出错的芯片移走。如下图所示。

5. 各种类型的CTC比较

从下面的图表中,可以从吞吐量、可靠性、并发性、硬件修改和复杂性开销方面比较各种CTC技术。

5.1 性能比较

  1. 包级CTC传输速率远低于物理级CTC。
  2. 包级CTC相对物理级CTC要更可靠,具有更强的抗干扰和抗噪声能力。

5.2 复杂度比较

  1. 包级CTC的复杂度和成本相对较低。基于RSSI分类解调算法简单,一般为线性,即O(n)O(n)O(n),而CSI的则取决于分类算法,像SVM分类、CNN分类,是具有不同的复杂度和成本的。

  2. 物理级CTC的复杂度要高于包级,所以我们比较物理级之间的

    1. 接收透明,发射机需要操纵数据包负载,仿真过程是调制过程的逆向,其中FFT是最耗时的运算。
    2. 发射透明,接收机可能需要为了适应不同的发射信号来更新解调算法。
    3. 不透明,由于是双方都需要更改,且为了提高仿真报文的接收无线电,扩展通信距离,支持并发性更高的CTC链路,这种CTC采用更复杂的操作,比如带宽转换,网段拼接等操作。

6. 未来展望

6.1 研究现状

在谈未来之前,先写下目前CTC的研究现状。

  1. 学术研究近20年,相关的论文数个人了解到的有50+。
  2. 中文文献较少,像我参考阅读的文献绝大多数是在ACM、IEEE两个数据库阅读到的,像国内的CNKI关于这一块的文献还是很少的。
  3. 目前几乎都是学术研究,即论文,相关的开源实例,比如代码,仿真文件较少,个人认为学生对于这一块的理论学习尚可,但是如果要付诸实践难度较大。
  4. 目前在工业上还没有实现的案例,说明这种技术还只是处于理论研究阶段。

6.2 未来展望

  1. 个人认为CTC如果最终可以在工业中实现,很有可能引起在通信、网络等领域的技术变革。
  2. 用直接通信来代替网关,无论是成本还是管理难度上都要更小,更低。
  3. 未来可能会在跨介质传输中起到一定的影响。

7. 参考文献

Yuan He. Cross-Technology Communication for the Internet of Things: A Survey[EB/OL]. 2022[2022-11-8]

CTC 技术介绍概述——啃论文系列相关推荐

  1. WMI技术介绍和应用——查询硬件信息

    这个月实在太忙了,一直没有时间去继续写WMI的应用例子. 本来是希望将<WMI技术介绍和应用>系列博文写的像WMI百科全书般,但是貌似对这个技术感兴趣的同学并不多,所以我决定对部分知识点点 ...

  2. TIBCO Rendezvous — 技术介绍

      http://blog.csdn.net/tiercel2008/article/details/6799952 TIBCO Rendezvous - 技术介绍 1.1.1.      TIBCO ...

  3. 大数据技术介绍:01大数据概述

    大数据技术介绍:01大数据概述 大数据技术框架: Hadoop生态系统(1) Hadoop生态系统(2) Hadoop构成:Flume(非结构化数据收集): Cloudera开源的日志收集系统 用于非 ...

  4. 【ELT.ZIP】OpenHarmony啃论文俱乐部——点燃主缓存压缩技术火花

    本文出自ELT.ZIP团队,ELT<=>Elite(精英),.ZIP为压缩格式,ELT.ZIP即压缩精英. 成员: 上海工程技术大学大二在校生 合肥师范学院大二在校生 清华大学大二在校生 ...

  5. 软考高级系统架构设计师论文系列三:论改进Web服务器性能的有关技术

    软考高级系统架构设计师论文系列三:论改进Web服务器性能的有关技术 一.摘要 二.缓存服务器和均衡负载设备 三.Web服务器配置 四.三层C/S软件结构设计 一.摘要 某大型图书馆数字化信息系统的设计 ...

  6. Uptime ATD技术论文系列:连续制冷-翻译 孙长青

    摘要 本技术论文阐明了Uptime Institute的Tier Standard:Topology背景下的连续冷却要求. Tier IV是唯一需要连续冷却的等级. 但是,Uptime Institu ...

  7. 撰写毕设论文正文的摘要、绪论、相关技术介绍-“一楼正式开建”-03

    本文思维导图 目录 摘要 绪论 相关技术介绍 我们的建筑,地址选好了,地基也打稳了,今天正式开始建造一楼.那这一楼有什么呢?前门.大厅和后门,这三项必有,对吧.它们分别对应毕业设计中的摘要.绪论和相关 ...

  8. 容器技术介绍之docker核心技术概述

    容器简单来说是一种沙盒技术,将应用"装"进沙盒中,像集装箱一样,把应用封装起来,使得应用之间不会相互干扰,而放进沙盒中的应用也方便"搬家".本文基于docker ...

  9. 无线充电技术介绍系列之一(技术科普)【无线充电圈 技术分析】

    http://forum.eet-cn.com/BLOG_ARTICLE_19153.HTM?click_from=8800109278,9703943504,2014-01-22,EECOL,FOR ...

最新文章

  1. 如何配置IntelliJ IDEA发布JavaEE项目?
  2. Linux下使用Opencv打开笔记本摄像头
  3. Review: Maximum Energy Efficiency Tracking for Wireless Power Transfer Systems
  4. linux下echo /dev/ttys* 到字符设备文件,linux之tty pty pts
  5. Gradle of Android Example
  6. 新元素之section,article,aside
  7. 想买啥 VS 买了啥!理想与现实的差距咋就这么大咧?
  8. 【BZOJ 2119】 2119: 股市的预测 (后缀数组+分块+RMQ)
  9. 使用u-boot的USB下载功能烧写程序到Nand Flash ——韦东山嵌入式Linux学习笔记06
  10. activepython win32com_activepython下载
  11. SAP Cloud for Customer的产品主数据通过PI同步到CRM
  12. java组件是什么意思_年前面试京东3面凉经~ 面试过程与真题全分享+备战春招(java)...
  13. Centos系统查看CPU有关信息
  14. 情人节海报设计没有灵感?看过来
  15. hdu-1695 GCD(莫比乌斯反演)
  16. 苹果计算机格式化磁盘,苹果电脑怎么格式化
  17. 弧微分直角系最详细推导
  18. OPA2134UA IC AUDIO 2 CIRCUIT 8SOIC
  19. SpaceSniffer(磁盘大小扫描分析) 彻底解决C盘爆满问题 清理C盘必备软件
  20. Enhancement spot 的实现

热门文章

  1. 未明学院:学员来稿 | 2019年中国电影分析报告
  2. 语音芯片排行榜,为何唯创知音WT588F语音芯片如此受欢迎
  3. AirPods pro 连接Macbook pro左耳无声音
  4. MYSQL长时间保持连接
  5. Weakly Superised video anomaly detection弱监督视频异常检测
  6. js实现拼接一个以逗号隔开的字符串
  7. 反编译之脱去乐固加固的壳
  8. Mybatis错误Illegal overloaded gette
  9. 灰度图、黑白图,彩色图理解
  10. joda-time 使用详解