FreeSWITCH技巧：如何向通话的另一方号码发送dtmf?
LTE Rel-12及其后续演进系统中的MIMO技术
& && &&&根据LTE系统标准化与网络部署的发展态势以及业界对MIMO技术的研究动向，从技术原理、发展现状以及标准化方向等角度对MIMO技术在LTE Rel-12及其后续版本中的潜在演进路线及应用方案进行了初步探讨：基于对LTE现有版本中MIMO技术的发展历程及Rel-11中MIMO技术的标准化进展情况的回顾，对Rel-12中已经确定的MIMO标准化方向—CSI反馈增强技术以及3D-MIMO/massive
MIMO技术进行了讨论；结合近年来MIMO技术的研究动态以及业界对LTE后续系统部署架构的演进路线的预想，对高频段局域覆盖场景中的MIMO增强技术进行了介绍。
& && &&&LTE、MIMO、3D-MIMO、3D-beamforming、massive MIMO、CSI反馈、3GPP
2.2.2&&3D-MIMO/ massive MIMO
& && &&&空间自由度是MIMO技术的安身立命之本。但是如前所述，在现有的被动式基站天线结构基础上，很难在UE级实现对信号垂直维分布的控制，也无法利用信道的垂直维自由度。Rel-10中引入的反馈增强机制已经比较超前地将天线端口数量扩展为8个，但是这些看似近乎极致的优化也仅仅限于水平维度内。信道的垂直维自由度对于MIMO技术而言，仍然是一片未经开垦的处女地。虽然3D-MIMO、3D-beamforming或vertical-beamforming等技术（文中统称为3D-MIMO）早已将目光汇聚于此，但是在AAS技术获得认可之前，一切都只是空中楼阁。最终，AAS技术的兴起为3D-MIMO技术注入了一剂强心针。有了AAS技术的支撑，垂直维自由度的大门已悄然向MIMO技术开启，MIMO技术中已积蓄多年的向着3D化发展的势头从此将一发而不可收。
& && &&&面对这样一个热门话题的出现，可以预见的是，3D-MIMO技术的标准化道路上免不了一场场恶斗。Rel-12正式启动之前，各友邦公司已经迫不及待地抛出一些初步方案与评估结果，一方面展示了其长期积累的技术实力，另一方面也像是一种食肉动物的护食行为，用餐前在呲牙咧嘴与低沉咆哮中宣示着自己的势力范围。
& && &&&由于MIMO技术在LTE系统中的基础性地位，MIMO技术的发展革新对LTE规范的影响往往是牵一发而动全身的。3D-MIMO的标准化过程中将会涉及的议题包括：
1）&&信道模型
& && &&&信道模型是MIMO技术性能评估与对比的基础，因此3D-MIMO SI的首要任务便是定义统
一的3D信道模型。WINNER II/+以及IEEE期刊中公开的3D信道建模方法[2-4]可能将成为3GPP确定3D信道模型的基准点。
2）&&传输与反馈
& && &&&传输与反馈机制向来是MIMO技术标准化的核心，因而也是争论的一大焦点。由于基于专
用导频的传输已经成为主流，因此下行传输过程基本已经属于实现问题。但是传输算法本身与反馈机制有着非常密切的关系，反馈机制的评估与筛选也必然以传输性能为依据，因此对传输机制的研究仍然是标准化推进中的重要环节。此外，而且传输算法的研究对于日后的产品实现也有着重要的参考价值。
& && && &在3D信道环境中，CSI反馈机制的讨论可能主要会集中在隐式反馈和基于互易性的反馈之上。由于需反馈的信息量进一步增加，因此3D-MIMO中可能不会有显式反馈的生存空间。可以预见基于码本的反馈方式仍将占据主导地位，但是由于隐式反馈是基于下行测量而进行的，而导频开销的增加终究是有限度的，这一限制将可能成为制约隐式反馈性能的一个不利因素。在3D信道中基于互易性的反馈的性能优势可能会更加明显，这种情况下基于互易性的反馈方式可能还会得到进一步的扩展。
& && && &3D-MIMO码本设计将是隐式反馈的核心问题，较为可行的方案包括：水平、垂直维度分别定义不同的码本或者针对2维AAS阵列定义统一的码本。对于前者而言，水平和垂直维仍然可以沿用现有的码本结构，而且这种结构与Rel-10的多颗粒度双级码本十分类似（当然，水平与垂直维本身可能就是双级），可以分别对不同的维度配置不同的反馈颗粒度与上报周期。但是这种方案中，需要对两个码本的组合方式以及数据流在水平维和垂直维的分布等问题进行定义。对于后一种方案而言，由于需要全新的码本设计，因此如何能够将多种方案收敛至相对统一的方向，同时又能以相近的复杂度与开销获得超越前者的性能，对其将会是一个挑战。
& && && &除了上述问题之外，规范中还需要定义CQI计算时对PDSCH传输方案的假设，对于垂直、水平维分别采用不同码本的情况，这里需要定义两个码本的组合方式。同时，可能还需要根据反馈机制的设计引入新的上报模式。
3）&&参考符号
& && & 由于3D-MIMO需要垂直维度的信道信息，单靠一个CSI-RS pattern所能提供的最多8个端
口就显得有些捉襟见肘了。针对这个问题，再额外增加CSI-RS端口似乎不太可行，但是可以沿用CoMP中定义的测量机制，例如为UE配置两个CSI-RS pattern（分别对应于CoMP中需要测量的两个传输点），分别用于垂直和水平维CSI的测量与反馈。
4）&&传输模式/传输方案及控制信令
& && &&&引入3D-MIMO之后，可能需要定义新的传输模式与传输方案，并定义相关的L1/L2控制信令与高层信令， 例如DCI设计与码本子集约束方案等。这类相对比较零碎的入门级议题上容易出专利而且门槛低，不需要太深厚的研究功底也可以侃侃而谈。因此这一议题必将继续成为MIMO技术标准化过程中最能体现参与意识的舞台。
& && &&&AAS技术不但为3D-MIMO的发展带来了福音，也让massive MIMO这样初出茅庐的新技术成了得志少年，转眼间就要从IEEE的论文上一步跨入LTE规范中。massive MIMO或称大规模MIMO是指采用大规模天线阵列的MIMO技术，其设计思路类似于扩频通信。在扩频通信技术中，发射机利用伪随机序列使信号趋于白化，使信号可以以极低的SINR隐没于噪声和干扰之中，而又能被接收机所检测出来。massive MIMO则利用大规模阵列使信号的空间分布趋于白化，随着基站天线数量的增加，各用户的信道系数向量之间逐渐趋于正交，高斯噪声以及互不相关的小区间干扰趋于可以忽略的水平，因此系统内可以容纳的用户数量剧增，而给每个用户分配的功率可以任意小。理论研究结果表明，若基站配置400根天线，在20MHz带宽的同频复用TDD系统中，每小区用MU-MIMO方式服务42个用户时，即使小区间无协作，且接受/发送只采用简单的MRC/MRT时，每个小区的平均容量也可高达1800Mbits/s[5]。
& && &&&Massive MIMO应用的基础是大规模阵列，若非采用二维AAS阵列，单纯基于传统的水平维线阵形式是无法支持这一技术的。因此从实现角度考虑，3D-MIMO和massive MIMO并不存在本质上的差别：massive MIMO必然使用二维AAS阵列，使用了二维AAS阵列之后，信道就成为三维的，而基于三维信道的传输自然也属于3D-MIMO的范畴。
& && &&&单纯从技术角度考虑，两者的研究与标准化似乎更应该是递进的关系，即先确定3D-MIMO的框架，再逐渐扩展其规模。3D-MIMO阶段有可能会利用类似CoMP中为UE配置多个CSI-RS pattern的方式增加等效端口数。但很明显的是，尽管不能排除在massive MIMO阶段继续增加导频端口的可能性，但是一味地通过增加导频开销来满足massive MIMO需求的方式，无论从性能增益还是标准化复杂度角度考虑，都将是不可行的。因此一种更为现实的方式是：3D-MIMO阶段引入一些新的机制，以实现垂直维信道测量，而massive
阶段在这一基础之上，可能会更偏重于通过上行信道来获取CSI（目前关于massive MIMO的理论研究主要是基于TDD假设的）。也就是说测量机制可能会成为3D-MIMO与massive MIMO技术在LTE标准化过程中一个隐性的分界点。
& && &&&随着天线阵列规模的增大，从控制阵列尺寸的角度考虑，似乎更适合在高频段使用3D-MIMO或massive MIMO这类技术。在高频段范围内，不太容易找到适于FDD系统的成对频带。因此除了下行导频开销因素之外，3D-MIMO与massive MIMO的引入，也可能会使LTE系统向着更有利于TDD技术的方向发展。可以预见到，随着单小区3D-MIMO/massive MIMO技术的标准化，这类技术可能会继续向多小区、协作化的方向发展，继而衍生出诸如3D-CoMP、massive
CoMP之类的应用方案。
& && &&&3D-MIMO与massive MIMO技术大规模应用后，每当那无比硕大的天线面板在风中摇曳之时，单薄的塔架之下必定有一群雷达界同僚心中窃喜。首先，AAS阵列、3D-MIMO这些目前被MIMO界奉若救世主的技术并非完全是通信工程师的创举，大规模的二维有源天线阵列早在数十年前就已用于相控阵雷达系统中。其次，在某些陆基相控阵雷达系统中，动辄就使用数以万计的天线阵子，因此所谓的3D-MIMO/beamforming与massive MIMO在他们看来可能也无非就是Q版的相控阵雷达技术。此外，AAS阵列在移动通信领域的大规模应用也为传统的雷达设计、开发单位带来了可观的市场空间。在云计算加AAS的发展趋势之中，眼看着基站的主要基带功能没入云端渐行渐远，而射频功能又高高地挂上了天线面板，传统的基站功能被一分为二。这种划分可能为众多往日的看客提供了分一杯羹的机会，但是在这一划分对于很多没有高瞻远瞩眼光的传统通信厂商，尤其是过分专注基站产品的厂商来讲更像是一个高难度的隔空大劈叉，若不是有深厚的功底怕是难以消受。
Copyright (C)2017
All rights reserved.FreeSWITCH技巧：如何向通话的另一方号码发送dtmf?
收藏者: bb
注：这里的文章都是本人的日常总结，请尊重下个人的劳动成果，转载的童鞋请注明出处，谢谢。如您转载的文章发生格式错乱等问题而影响阅读，可与本人联系，无偿提供本文的markdown源代码。联系邮箱：.
在实际的应用中，经常有这样的需求，比如一个号码拨打外线，需要送dtmf出去（如拨打10086，根据提示按1按2等），在这种情况下，如果处理呢？
其实该问题可以分解为下面两个子问题：& 1、如何根据一方号码，获取与之通话的另一方号码？ 比如66903 拨打 66904，那如何根据66903来获取到66904呢？& 解决方法：& 通过执行FreeSWITC的API命令，可以获取另一条信道的信息，如下：
show channels like 66903@ as xml
在该命令的返回值中抽取sent_callee_num，即为另一方的号码。& 下面是具体的实现方法：
2、如何向另一方号码发送dtmf？& 解决方法：& 该问题比较容易处理，只需要调用uuid_send_dtmf方法即可。前提条件是获取到那个信道的UUID。
下面是完整的脚本代码，仅供参考：}