您现在的位置:首页 >> 技术文章 >> 通信信号处理 >> 内容

matlab代做★highspeedlogic★SISO OFDM通信系统物理层协议设计之感悟

时间:2016-7-18 12:50:45 点击:

  核心提示:matlab代做,FPGA代做,淘宝,专业代做MATLAB、FPGA博士/硕士/本科毕业设计、项目仿真、Coursework、Assignment...

matlab代做FPGA代做淘宝专业代做MATLABFPGA博士/硕士/本科毕业设计项目仿真CourseworkAssignment

 开篇说明:我不懂MIMO,不懂SC-FDE,不懂上层协议,因此以下的讨论仅仅限于SISO-OFDM物理层。
1 子载波间隔的选择
    我们都知道OFDM对频偏敏感,所以子载波间隔不能过小,否则其抗频偏能力很弱,但又不能太大,否则频带过宽,浪费宝贵的频谱资源。LTE中普通模式下子载波间隔15kHz,特殊模式7.5kHz。而DVB-T2中子载波间隔最大8929Hz,最小的只有279Hz,比LTE中的小多了。究其原因,是因为它们所面对的信道环境不同造成的。LTE面对的环境可能会有高速移动的情况,因此多普勒频移很大,所以子载波间隔需要设置得大一点;而DVB-T2作为地面广播的数字电视标准,信道中的多普勒频移小得可怜,你见过谁背个电视在路上跑来跑去的,所以其子载波间隔可以设置得很小。
2 带宽的选择
    这就要看该系统承载的是什么业务了?语音?数据?多媒体?不同的业务对传输速率的要求差异很大,对误码率的要求也不尽相同。这里就要特别注意,到底该种业务需要的误码率是多少?速率要求又是多少?才能不降低用户体验?不可能用一个误码率只能达到1e-5的系统去承载数据业务,也不可能用带有ARQ的系统去传输视频,前者可能让用户读一段文字就一个乱码,而后者无异于杀鸡用牛刀。
    从误码率要求和速率要求,就可大致算出物理层的速率要求是多少了(当然,信道编码的开销大得惊人,必须把这部分算进去)。有了速率,有了子载波间隔,就可以算出该系统需要的带宽是多大了。
3 发射信号频谱的问题
    通信标准中对于Mask都有严格的定义,发射信号的频谱一定不能超过该Mask。虽然自己定制的协议可能会在这方面没下多少工夫,但并不意味着这部分的工作不重要。试想自己做了个超烂的发射机,频谱干扰到了邻频,那无委会可能就要找上门了。
    OFDM通过加窗以降低频谱的带外干扰,窗越平滑,所需的点也就越多,则所需的循环前缀和后缀(Cyclic Prefix & Suffix)就越长,有效地数据率就越低。所以,我们需要在有效数据率和带外干扰之间折衷,在这一点上需要特别注意,需要去看看无委会的频谱划分文档。其他参数的选择无非是影响接收端的性能,最多不能用。而这点可能直接把你送进监狱
4 信道编码的选择
    相信目前比较新版本的民用通信系统标准,除了Turbo就是LDPC,肯定2选1。LTE用的Turbo,Wi-Fi从802.11n开始使用LDPC,最近大热的802.11ac(也就是大家说的5G Wi-Fi)延续了LDPC的使用,而DVB、802.16、G.hn都是用的LDPC,连硬盘中都是用的LDPC
    Turbo和LDPC各有优缺点,其中LDPC的error floor更低,但要达到相同的误码率,LDPC需要更长的码长,一般都要上万。LTE中Turbo码长最长6144,而DVB-T2中LDPC码长最长64800,是前者的10倍还多。码长长度直接决定了系统的时延。比如LTE,语音业务仍然为其不可缺少的一部分,所以需要低延时;而DVB为电视广播业务,延迟大点也没关系。
如果再考虑到实现,Turbo编码简单,译码复杂,就算是新手也可以在2天时间内完成Turbo编码器的设计;LDPC编码复杂,译码简单。另外,由于Turbo译码算法的可并行性不高,所以其吞吐量一直做不上去;而LDPC译码器简简单单就可以上G。
    如果要在这2种中选一种,怎么选?撇开上述性能及复杂度的差异,下面只结合帧结构进行讨论。Turbo属于带反馈的卷积码,其码长灵活多变;而LDPC属于线性分组码,码长固定。LTE中帧长固定,采用固定码率为1/3的Turbo码,因此,为了达到RE(Resource Element)的充分利用,后续有速率匹配(Rate Matching)的过程。而LDPC一般都会对应不同的码率,但码长固定,这样就可以按照其码长来设计帧的长度,比如在星座映射阶数一定的情况下,就可以推出一个OFDM符号可以承载多少比特的数据,进而算出一个帧到底需要多少个OFDM符号才能承载整数个完整的码字。其实一帧可以不用承载整数个码字,比如一个码字的前半部分在上一帧,而后半部分在下一帧,这样接收端就需要更多的缓冲来存储数据,还需要额外的标识信号以便接收端在OFDM解调之后进行信道译码。甚至还有些标准故意把码字打乱到不同的帧,比如DVB-T2中的时间交织(Time Interleave)。这里先不讨论此种情况,我们的目标是制定一个最简单可靠的通信协议。
5 导频位置的选择
    这也要看当前应用场景所对应的信道模型,多径严重不?多普勒频移大不?大家都知道,如果多径严重而多普勒频移不大(比如城市中的蜂窝通信)可选择块状导频;如果多普勒频移大而多径不严重(比如军用的机载通信),可以选择梳状导频。不管是块状还是梳状,其导频所占的比例都太大(并且块状导频还会有PAPR过高的问题,下面会说到),所以目前很少看到有标准会纯粹地用这2种,一般都是蜂窝状导频,因为其所占比例小,可以由当前的信道质量决定到底时域隔几个插一个导频,频域又是隔几个插一个。
6 PAPR降低算法的选择
    PAPR降低的方法数不胜数,限幅、相位优化、编码……而不增加接收端复杂度又能保证误码率性能的,只有星座图扩展(Active Constellation Extension,ACE)和子载波预留(Tone Reservation,TR)。这2种方法都被DVB-T2标准采纳。
    说到PAPR的问题,就不得不提前上小节谈到的块状导频。一般导频都是由PN序列产生,所以其PAPR过高的问题不可避免。解决方法之一就是星座图扩展,不过扩展之后所对应的频域星座点已经发生改变,所以接收端必须存储这些扩展了之后的星座点。如果不用ACE,接收端完全可以本地放一个LFSR,只需要让其初始种子和发送端的相同就可以完全复制出导频序列了,而现在却必须用一堆ROM去存储导频序列。这在导频序列周期不长的情况下可以使用,但若导频序列过长,则ROM的容量也就需要得很多了。
    那么考虑另一种方法:TR。顾名思义,预留一部分子载波不用来传输数据,而专门用来降低PAPR,显然,这种方法的最大缺点就是损失了有效数据率。比如我们刚刚说的块状导频,那么我们是不是可以让条件松弛一点,在频域上每隔2个插一个导频,再预留一小部分导频用来降低PAPR。这也不失为一种可行的方法(这样损失的有效速率就有点大了)。
7 同步训练序列的选择
    这部分我们考虑2个方面,一个是序列值、另一个是序列位置的选择。
    先说第一个小问题:序列值。同步序列分好多种,用得比较多的为小m序列和ZC(Zadoff Chu)序列了。LFSR产生的比特流需要星座映射之后再IFFT调制,显然,这里PAPR过高的问题又出现了。而ZC序列由于其星座点发散在一个单位圆上,可以使PAPR很低
    另外,关于序列位置的选择。比如我们做频率同步,需要频偏估计,如果2个序列隔得越远,则其估计精度越高,但估计范围越小;相反,如果隔得越近,则估计精度越低,但估计范围也越大。所以,还是需要考虑应用场景,考虑系统可能产生的频偏到底有多大,再在这个基础上去选择同步序列的位置。同步序列的个数也要纳入考虑的范围,G.hn中针对电力线信道的帧头就包含5个完全相同的训练序列和2个相反值的训练序列,就看接收端怎么充分利用这么多训练序列,使得定时同步和频率同步的精度达到最高。
8 控制信道的选择
    控制信道需要低阶调制、低码率的信道编码,以便满足其苛刻的纠错需求。而且还不能用LDPC这类编码,因为LDPC码长动辄上万,折算到信息比特也至少上千。你见过哪个控制信号有几千比特的?所以,还是推荐卷积码、Turbo码这类非线性分组码或者码长比较短的线性分组码。
    另外,CRC是不能少的,否则怎么知道信息出错了,就靠这个来检错了。CRC和其它的信道编码是有区别的,因为它只能检错,不能纠错。下表是一组构造的最优CRC码字的检错性能。校验位长,只能提高它检错的准确率,即能够保证,在码字出错的情况下,能够检错成功;或者从另一个角度说,也就是减小明明出错了却没有检查出来的概率,即漏警概率。
[转载]SISO <wbr>OFDM通信系统物理层协议设计之感悟


    那么CRC校验位长度应该怎么设置呢?在协议设计初期,本人想把CRC校验位设置得很长。随之问题就来了,就算校验位再长,出错了就出错了,CRC对出错的码字毫无办法,只能告诉系统,说我这里有个码字错了,系统也没办法,只能把这个码字对应的帧丢掉或者请求重传。所以,控制信道的信道编码的设计是个技术活,既要纠错,也要检错,这两种编码校验位的长度应该怎么去配合,恩~高深。
9 自适应调制编码(AMC)
    这里先撇开具体的算法,我们讨论AMC颗粒度的粗细问题。颗粒度越粗,则控制信道的信息就越小,整个系统也越简洁,但明显没有发挥出OFDM自适应比特分配的优势;而如果颗粒度太细,则控制信息就需要得特别多,整个系统的复杂度也会增加。所以,关键还是折衷。
10 与上层接口的字段选择
    本人没接触过上层,所以这些方面一概不清楚,还请指教。
11 关于做项目和写论文的区别
    我们写论文,一般都是研究一个小点,其他关键技术都是假设理想的前提下,比如做信道估计,就会假设在理想的定时同步下完成;做信道译码,会假设在理想信道估计的前提下。
    但做项目不同,一个系统,所有的关键技术都不可能达到理想情况,所以每部分都会带来性能损失。因此,我们在论文中看到的某些算法可能在其他条件理想的情况下性能比较好,但是非理想情况下的性能就有待考证了。
12 总结:
    应用场景很重要,这直接决定了系统所面对的信道环境,包括多径、多普勒频移;
    系统需求也很重要,该系统是用来干嘛的?语音?数据?多媒体?需求直接决定了误码率、速率;
    折衷很重要,上面的每一点几乎都需要折衷,我们的目标就是在不降低系统性能(误码率、频谱带宽、带外干扰、速率……)的前提下降低系统实现的复杂度,这是门艺术。

    其实,设计协议需要有经验的学术研究者和工程师,协议的制定除了需要扎实的理论功底外,还要以大量的仿真进行验证。如果要让我们学生来设计的话,理论不扎实,也没多少仿真的经验,所以每遇到一个小问题都要从这两方面入手,这是相当痛苦的一件事,不仅项目进度特别慢,最怕的就是设计的协议不能用。革命尚未成功,同志仍需努力。

作者:网络 来源:网络
  • 您是如何找到本站的?
  • 百度搜索
  • Google搜索
  • 查阅资料过程中
  • 论坛发现
  • 百度贴吧发现
  • 朋友介绍
本站最新成功开发工程项目案例
相关评论
发表我的评论
  • 大名:
  • 内容:
  • matlab代做|matlab专业代做|matlab淘宝代做(www.hslogic.com) © 2018 版权所有 All Rights Reserved.
  • Email:highspeed_logic@163.com 站长QQ: 1224848052

    专业代做/代写/承接、MATLAB、SIMULINK、FPGA项目、博士/硕士/本科毕业设计、课题设计、论文,毕业论文,Coursework、Eassy、Assignment