搜索
PRACH格式随机接入信号是由CP（长度为TCP）、前导序列（长度为TSEQ）和GT(长度为)三个部分组成，前导序列与PRACH时隙长度的差为GT，用于对抗多径干扰的保护，以抵消传播时延。一般来说较长的序列，能获得较好的覆盖范围，但较好的覆盖范围需要较长的CP和GT来抵消相应的往返时延，即小区覆盖范围越大，传输时延越长，需要的GT越大，为适应不同的覆盖要求，36.211协议规定了五种格式的PRACH循环前缀长度、序列长度、以及GT长度如下表3。Preamble格式和小区覆盖范围的关系约束原则为：小区内边缘用户的传输时延需要在GT内部，才能保证PRACH能正常接收，且不干扰其他的子帧。即需要满足的关系为，其中，TTCP为循环前缀CP的长度；TGT为保护间隔；TRTT为最大往返时间。根据以上关系，可以得到各种格式下所支持小区的最大半径如表3：表3前导格式CP长度(Ts/)GT长度()最大半径03168/103.132976/96.886.2514.53121024/684.3815840/515.6316.6777.3426240/203.136048/196.886.2529.53321024/684.3821984/715.6316.67100.164448/14.583288/9.37551.406具体可以叙述为：Preamble格式0：持续1ms，序列长度800us，适用于小、中型的小区，最大小区半径14.53km，此格式看满足网络覆盖的多数场景。Preamble格式1：持续2ms，序列长度800us，适用于大型的小区，最大小区半径为77.34km。Preamble格式2：持续2ms，序列长度1600us，适用于中型小区，最大小区半径为29.53km。Preamble格式3：持续3ms，序列长度1600us，适用于超大型小区，最大小区半径为100.16km；一般用于海面、孤岛等需要超长距离覆盖的场景。Preamble格式4：TDD模式专用的格式，持续时间157.292μs（2个OFDM符号的突发），适用于小型小区，小区半径≤1.4km，一般应用于短距离覆盖，特别是密集市区、室内覆盖或热点补充覆盖等场景。它是对半径较小的小区的一种优化，可以在不占用正常时隙资源的情况下，利用很小的资源承载PRACH信道，有助于提高系统上行吞吐量，某种程度上也可以认为有助于提高上行业务信道的覆盖性能。PUCCH格式PhysicalUplinkControlCHannel，物理上行链路控制信道，主要携带ACK/NACk,CQI,PMI和RI。LTE中主要有如下的格式：一、Format1：用于终端上行发送调度请求，基站侧仅需检测是否存在这样的发送Format1a/1b：用于终端上行发送ACK/NAK（1比特或2比特）Format1在系统L3信令配置给ScheduleRequest的资源上传输；format1a/1b在与下行PDCCHCCE相对应的PUCCHACK/NAK资源上传输；当SR和上行ACK/NAK需要同时传输时，在L3信令配置给SR的资源上传输上行ACK/NAK。PUCCH上传输上行ACK占用的资源由RBID，frequencydomainCDMcode(ZCcyclicshift)和timedomainCDMcode(orthogonalcover).确定二、Format2：用于发送上行CQI反馈（编码后20比特），数据经过UEspecific的加扰之后，进行QPSK调制Format2a：用于发送上行CQI反馈（编码后20比特）+1比特的ACK/NAK信息，进行BPSK调制Format2b：用于发送上行CQI反馈（编码后20比特）+2比特的ACK/NAK信息，采用QPSK调制PUCCH资源映射：PUCCH位于系统带宽的两边，一个子帧的两个时隙采取跳频方式获得频率分集增益PDCCH格式(DCI和支持CCE的4种传输格式)PDCCH上传输的内容就叫DCI，PDCCH中承载的是DCI（DownlinkControlInformation），包含一个或多个UE上的资源分配和其他的控制信息；LTE中PDCCH在一个子帧内（注意，不是时系）占用的符号个数，是由PCFICH中定义的CFI所确定的PDCCH的传输带宽内可以同时包含多个PDCCH，为了更有效地配置PDCCH和其他下行控制信道的时频资源，LTE定义了两个专用的控制信道资源单位：RE组(REGroup，REG)和控制信道单元(ControlChannelElement，CCE)。1个REG由位于同一OFDM符号上的4个或6个相邻的RE组成，但其中可用的RE数目只有4个，6个RE组成的REG中包含了两个参考信号，而参考信号RS所占用的RE是不能被控制信道的REG使用的。协议中（36.211）还特别规定，对于只有一个小区专用参考信号的情况，从REG中RE映射的角度，要假定存在两个天线端口，所以存在一个REG中包含4个或6个RE两种情况。一个CCE由9个REG构成。定义REG这样的资源单位，主要是为了有效地支持PCFICH、PHICH等数据率很小的控制信道的资源分配，也就是说，PCFICH，PHICH的资源分配是以REG为单位的；而定义相对较大的CCE，是为了用于数据量相对较大的PDCCH的资源分配，PHICH的分布由PBCH确定。PDCCH在一个或多个连续的CCE上传输，LTE中支持4中不同类型的PDCCH，如下图所示：PDCCHformatNumberofCCEsNumberofresource-elementgroupsNumberofPDCCHbits01972121814424362883872576PDCCH的0123分别包含1、2、4、8个CCE，选用哪种格式的PDCCH，不仅取决于要传的数据个数，还取决于信道质量等因素，比如对小区边缘的UE，就应该用多的CCE以保证可靠性。0123基本是按大类分，比如0上行，1下行，2是MIMO等，然后在大类里又分abcd几个小类对的。0上行，1下行，2MIMO，3传TPC信息。1,2,4,8对应的是CCE个数，也就是aggregationlevel，也就对应某个UE在当前TTI的PDCCHchannel，或者公共PDCCHchannel，选择多少个CCE一般是有UE的CQI决定的，如果信道质量比较好，则可以选择小的CCE个数，毕竟PDCCH是非常珍贵的资源。DCI是指当前TTI的不同PDCCHchannel采用的格式，一般由传输模式决定，比如说0用于上行，1C一般用于SI,RAR,PAGING等，1A用于SFBC，2/2A用于SM。PCFICH格式用来指明PDCCH在子帧内所占用的符号个数。CFI就是指示了前面究竟有几个Symbol用于发送控制消息（1、2、3、4）PHICH物理混合重传指示信道（PhysicalHybrid-ARQIndicatorChannel）PHICH用于对PUSCH传输的数据回应HARQACK/NACK。每个TTI中的每个上行TB对应一个PHICH，也就是说，当UE在某小区配置了上行空分复用时，需要2个PHICH。小区是通过MIB的phich-Config字段来配置PHICH的，下行ThePhysicalHybrid-ARQIndicatorChannel(PHICH)承载上行数据传输的HybridARQ确认信息，位于每个子帧的第一个OFDM符号上（注：FDD为基础，在正常的PHICH周期）。PHICH在多个REG上传输（resourceElementGroup），多个PHICH可以分享一组REG，由正交数组区分。同一个资源上的PHICH称为一个PHICH组，一个单独的PHICH由两个参数决定：PHICH组号，组内的正交序列号。一个PHICH需要多少REG？计算方式简单明了。ACK是111，NACK是000，都是3比特，PHICH使用BPSK调制，每个ACK/NACK需要3个调制符号。然后这3个调制符号用正交码复用，选用扩频因子为4的常规循环前缀，得到12个符号。每个REG包含4个RE（resourceelement），每个RE承载一个调制符号，所以一个单独的PHICH需要3个REG。下图显示了PHICH是如何映射到物理资源上的，用到三个PHICH组。3个REG用于支持PHICH组，他们均匀的分布在系统带宽上，以备频率分集。（图中第一个符号也包含PCFICH（PhysicalControlFormatIndicatorChannel）信息，无论系统带宽多少PCFICH总是占用4个REG，均匀的分布在系统带宽中。）每个PHICH组可以包含几个PHICH？(3GPPTS36.211Table6.9.1-2)定义了8个正交序列，所以每组可以最多携带8个PHICH。系统能支持多少PHICH？结果跟具体的帧结构相关。PHICH的数量由下行系统带宽和参数Ng决定，这两个参数都在MIB消息中广播（MasterInformationBlock）。计算公式是在3GPPTS36.211章节6.9中定义的。假设下行带宽是10HMz，Ng=1则可供使用的PHICH组有7个，PHICH的总数是7个PHICH组x每组8个PHICH共计56个PHICH。需要的RE（resourceelements）数是7PHICH组x每组需要3个REGx4个RE每REG，共计84个RE。上行数据传输的HARQACK/NACK装在每个PHICH中，用户怎么知道查哪个PHICH找自己的ACK/NACK信息呢？在时域，上行数据传输发生在子帧#n，相应的PHICH就会出现在子帧#n+4。频域上，它由上行资源分配的DCIformat0指示，PHICH（组号和组内的正交序列号）是由上行传输第一个时隙上最低的PRBindex和DMRS循环前缀决定的，具体算法参见3GPPTS36.213章节9.1.2.。为什么MIB中要有Ng?为什么不把它放在SIB系统消息里？这就是鸡生蛋/蛋生鸡的问题，UE在系统消息获取阶段就要知道PHICH配置。一方面，UE解码PDCCH以获取SIB在PDSCH上的位置；另一方面，PDCCH、PHICH、PCFICH共享子帧中控制单元的资源，可用的PDCCH资源数取决于PHICH的配置（PCFICH资源已知且固定）。