|
X-RNTI （1）SI-RNTI：系统消息
（2）P-RNTI：寻呼
（3）RA-RNTI：标示用户发随机接入前导所使用的资源块
（4）C-RNTI：用户业务
（5）TPC-PUCCH—RNTI： PUCCH上行功控信息
（6）TPC-PUSCH—RNTI： PUSCH上行功控信息
（7）SPS C-RNTI的用法和C-RNTI是一样的，只是使用半静态调度的时候才用；
P-RNTI C-RNTI可以在一个子帧里存在，paging的P-RNTI是所有UE共用的 见36321的表格。P-RNTI是FFFE, SI-RNTI是FFFF, 对于所有UE是共用的。 因为手机需要X-RNTI对PDCCH进行盲检DCI,而对于手机来说,每个subframe只可能有一个DCI,所以在UE-Specified Space里面,手机只存在一个RNTI.但是在Common Search Space,手机可以用的公共的RNTI (例如P-RNTI) 不过，PDCCH本身是盲检测的，如果再加上需要在common search space搜索公共的RNTI，UE的开销会是很大的。 在随机接入的过程中，UE会选择一个前导码和时频资源发送前导码-Msg1，发送的子帧位于PRACH资源的位置可以推算出RA-RNTI；RA-RNTI= 1 + t_id+10*f_id；见MAC协议。 基站收到终端的前导后根据收到前导的PRACH时频资源位置推算RA-RNTI，并以该RA-RNTI加扰PDCCH，并发送随机接入响应-Msg2，该Msg2-RAR中包含了TC-RNTI，是基站为终端分配的临时调度ID（temporal C-RNTI/C-RNTI），用于终端和网络的进一步通信。 。。。。。。MSG3, MSG4省略，
当终端随机接入成功后就会将TC-RNTI升级为C-RNTI。基站要寻呼UE就通过P-RNTI加扰PDCCH，并指示DAI，UE会解码PDCCH，并根据DAI的信息找到寻呼的下行数据；基站与终端建立连接后（connected），通过C-RNTI或SPS-RNTI进行PDCCH的加扰解扰，进而获得调度信息，截获相应子帧的业务数据。 CQI定义
Channel Quality indicator（CQI），CQI只有0-15共16种，分别对应29种MCS，对应关系是通过码率来实现的，选择和16种CQI对应的码率最接近的MCS组合，作为对应的MCSlevel。因此，对应于不同的天线配置、不同的层数等会对应于不同可用的MCS组合。 CQI\PMI\RI反馈 CQI\PMI\RI的反馈通过PUSCH和PUCCH进行，其中，周期性的反馈是通过PUCCH进行的，PUCCH共有六种模式：1\1A\1B\2\2A\2B，非周期的反馈通过PUSCH进行，当对应的反馈信息在PUSCH上发送时，采用和PUCCH相同的格式。由于UE不能同时发送PUCCH和PUSCH，所以当周期性的反馈和非周期性的反馈冲突时，只发送非周期反馈（PUSCH）。 基站共有七种传输模式，每种传输模式对应于不同的CQI\PMI\RI反馈模式。 对于下行带宽小于等于7个RB的情况，不支撑PUSCH反馈（这里为什么是小于等于7个RB7下行系统带宽可以等于7么?） 当宽带CQI和子带CQI同时反馈时，在每两个宽带CQI反馈之间，每隔子带CQI都会被反馈多次，具体的次数由子带划分和宽带CQI反馈周期确定，另外，当子带CQI和宽带CQI同时反馈时或者两个码字同时反馈时，子带CQI或者第二个码字的CQI都将以相对值得形式进行反馈。 PUCCH & PUSCH pucch和pusch不能同时发送，SR/CQI/SRS不能在同一子帧中发送，优先级SR>CQI>SRS； PUCCH中的内容是不要CRC校验的，PUSCH需要CRC校验。 HARQ重传的问题 29种MCS分别对应不同的调制编码方式和TB-Size大小的组合，而29-31则对应于HARQ重传时的版本号，在进行HARQ重传时，TB-Size大小是不变的，但是调制编码方式的组合是可以改变的，带来的影响就是码率的改变。 MCS Determination PDCCH指示对应的PDSCH所用的调制编码方式，UE根据自己调度的带宽和PDCCH指示的MCS，则可以计算得出对应的传输块的大小。 需要注意的问题：对应与系统信息、随机接入信道的相应（RAR）以及寻呼信息，都采用QPSK调制编码方式。对于DwPTS，假设对应的的带宽为NPRB，则实际查表时使用的带宽为NPRB的3/4，当DwPTS对应的符号数小于等于三个的时候，不做PDSCH传输。 如果初传地码率大于0.93，UE则会直接跳过解码。 注意TBS表格和传输方式的对应关系，且TBS表格中的数值为添加CRC后信息比特的长度。 Resource Allocation LTE下行资源分配主要由三种类型，type0，type1和type2，其中，每一种类型都和一定的DCI格式对应，type0和type1对应直接与物理资源向对应，而type2的分配则与虚拟资源的分配对应，然后通过虚拟资源与物理资源的映射关系，获得最终的物理资源。 Type0和type1分别与DCI format1、2、2A对应，两者通过1比特的指示信息区别，type2与DCI format1A、1B、1C、1D对应。 Type0将连续的物理RB分配给调度的UE，首先根据系统下行带宽分为大小为P的RBG（P的大小和系统下行带宽有关系），然后通过DCI里面对应的bitmap映射对应的RBG，如果为'1'，则与之对应的RBG被分配给当前UE。 Type1也是直接指示物理资源与调度用户的关系的，但Type1与Type0不同，它分配的不是连续的RB，首先也是把整个下行带宽进行分为P组（P的大小也是由下行带宽决定的，与Type0中对应的P大小相同），在这个过程当中，从第p个RB开始，每隔P个RB所对应的物理RB被添加到RBG p，然后把对应的DCI中的用于资源指示的区域分为三部分，第一部分用来指示选择这P组中的哪一组，第二部分用来指示在当前被选择的资源集当中是否需要进行一个shift，第三部分则用来指示在当前选中资源集中那些物理RB被分配给了当前的调度用户。用于Type1和Type0通过相同的DCI模式指示，对应的资源映射区域的大小也相同，由于type1使用了一部分的信息比特用来指示集合编号，这样的话就使得剩下的信息不能不能和资源集中的每一个RB一一对应，因此，采用type2进行资源分配时会有部分物理RB不被指示，通过1比特的shift来指示。 Type2对应的是虚拟RB，虚拟RB的与物理RB的映射有两种方式，一种是Localized一种是Distributed。在DCI format1A、1B、1D格式中，通过1比特信息来指示对应映射方式的是Localized还是Distributed，对于DCI format1C来说，则只能用Distributed。 LTE相关编码与速率匹配（下行turbo码） 码块分割完毕后，对各个码块进行编码，以turbo码为例，首先进行1/3码率编码，编码之后根据所分配的资源上可用的RE数目、Rank数以及对应的调制方式，即可以确定速率匹配之后输出的比特数。对于PDCCH来说，首先基站会确定某个PDCCH占用的CCE的数目，然后根据CCE的数目则可以获知对应的PDCCH在速率匹配之后的比特数。 需要注意的问题，，，其中，Nsoft是与UE能力相对应的soft buffer的大小，与UE能力相关的几个参数是：空间复用支撑的最大layer数、在一个TTI内可以接收到的总的码字比特数、最大的码字比特数和Buffer的大小。对于NIR的公式分母最大为16，根据UE category等级的差别，UE的buffer大小和他所能支撑的最大码字的长度大小比值为16.4，而且Ncb如果小于编码后的序列长度，则多出部分再进行速率匹配的时候将被忽略掉。HARQ重传的版本号体现在速率匹配当中的起始位置上，对于每一个码块的速率匹配后的比特数，需要考虑到在码块分割时每个码块对应的长度。 LTE相关码块分割和CRC添加 一个码块最大的长度为6144，最小为40（与其相对应，Turbo码编码器交织器最小是40，最大是6144），如果不够40，则需要添加"NULL"比特，如果超过6144，则需要进行码块分割，需要注意的问题，整个码字被添加了一个CRC，然后每一个码块也会被添加一个CRC，再进行码块分割的时候，可能需要添加填充比特。 参考信号 UE Specific 参考信号 对应于单天线模式，与Cell Specific参考信号同时存在，不存在冲突。 待续 MBSFN 参考信号 子载波间隔分别为15kHz和7.5kHz 待续 Cell Specfic 参考信号 小区专用参考信号的生成是由时隙编号、符号编号、CP长度和小区ID共同决定的，小区参考序列S的长度是由系统下行带宽决定的随机序列，而对应于每一个下行带宽的小区参考信号序列S1则是从上面S序列的尾部向前读取相应的长度。 需要注意的问题： 小区专用参考信号只支撑15kHz的子载波间隔； 不支撑MBSFN传输，在PDSCH和PMCH同时存在的子帧上面，只出现在前两个符号； PHICH PHICH承载上行数据的ACK/NACK反馈，多个PHICH可以映射到同一份物理资源上，共同组成一个PHICH组，组内的PHICH通过正交码进行区分。对于TDD来说，每一个下行子帧上面对应的PHICH组数和UL/DL的配置相关。 PHICH有三比特信息，根据CP长度的不同，通过正交码进行加扰，分别扩展成12个符号和6个符号，然后在对扩展CP情况下，加扰过符号进一步划分为12个符号，然后进行映射和预编码，PHICH采用单天线或者发射分集模式，其中，四天线情况下采用的预编码矩阵为PHICH专用。 预编码结束后，进行物理映射，映射时以PHICH组为单位，对于常规CP，需要把同一PHICH组内的所有的PHICH相加，对于扩展CP，需要把相邻两个PHICH组当中的PHICH相加（在扩展的时候，添00的位置不同，所以在这一步不会对结果产生影响），映射的时候以symbol quadruplet为单位，同一个PHICH组对应于同一个PHICH映射单元，可能在同一个符号上也可以映射到不同的符号上。 频域上的位置通过公式计算可以得出，首先把对应符号上的除去PCFICH后的REG进行排序，然后再把symbol quadruplet映射到对应的物理资源上，基本上是均匀分步的。 注意PHICH Duration的含义是允许包含PHICH的符号数，它的大小受到PCFICH的限制，假设用于PDCCH的符号数是3个，则PHICH duration要小于3，具体是几根据帧结构进行判断。 PDCCH的资源映射 PDCCH承载调度分配和下行控制信息，PDCCH的传输是通过一个或者多个CCE(control channel elements)承载的，CCE是由9个REG组成，也就是36个Resource element，由于PDCCH是QPSK调制，因此也就是对应了72个信息比特，多个PDCCH可以在同一个子帧上传输。 如果一个PDCCH由n个CCE组成，那么这个PDCCH在映射时的起始位置应该为i%n=0。PDCCH在映射时需要把PCFICH、PHICH占用后剩余的REG都填满，如果所有PDCCH的信息比特加起来仍然不满足要求，则需要在PDCCH后面添加相应数量的NIL，因为PDCCH的aggregation级别是由MAC给定的，因此，PDCCH对应的REG的数目已知，从而可以确定PDCCH经过速率匹配之后的符号数满足36的整数倍，因此，添加NIL的REG是PCFICH、PHICH、PDCCH映射之后剩余的。 PDCCH采用单天线或者发射分集模式，采用和PBCH相同的天线配置，PDCCH在映射到物理资源之前，需要进行一个交织，交织是以symbol quadruplet为单位的，在映射时，首先把PCFICH和PHICH映射后剩余的REG进行排序，然后按照对应的顺序把交织后的symbol quadruplet进行映射。 PDCCH所占符号的映射顺序为：RS->PCFICH->PHICH->PDCCH->NIL。 另外：基站通过PCFICH规定了PDCCH的符号数，假设当前对应的有效PDCCH信息比特不能完全填满PDCCH占用的符号，NIL元素会被添加，直到完全填满PDCCH符号，这样的话，前三个PDCCH符号上面始终是处于填满状态的，从功率的角度来看，始终是有的。 关于PDCCH中NIL元素的理解
NIL的作用只是为了实现对应的PDCCH和相应的聚合级别的对齐，只是起到了一个占位的作用，最初的版本用的是Dummy，后来改成了NIL，根据36.141的规定，NIL对应的RE上面的发送功率为-Inf，也就是0，另外，36.302里面给出的Reception Type指得是所有可能出现的情况，UE需要按照这些组合去接收，但是不一定会接收到相应的信息。 总之，在一个下行子帧里面可能出现没有PDSCH也没有PDCCH的情况，此时基站仅发送RS和PCFICH（PHICH？），出现的条件是 没有PDSCH
没有PUSCH
并且没有承载广播信息的PDSCH（PDCCH通过SI-RNTI加扰，且按照基站规定周期性发送） PCFICH PCFICH用来指示用于PDCCH的符号数，最大为4个，PCFICH由32个信息比特组成，采用QPSK调制方式，调制后为16个符号，映射到4个REG上面，采用单天线或者发射分集方式，采用和PBCH相同的天线配置。 PCFICH映射到每一个子帧的第一个符号，在频域上是均匀分布的，分布的具体位置是和小区ID有关系的，因为PCFICH是Cell-Specfic的，并且在非MBSFN子帧上，至少有1个符号会被用作PDCCH。 待续~ PBCH PBCH上面发送的主要是广播信息（Master Information Block），PBCH采用QPSK调制，采用单天线或者发射分集方式发送，PBCH采用盲解。 PBCH映射到每1帧的第1个子帧的第2个时隙的前4个符号，根据CP长度的不同，PBCH对应的编码之后的信息比特程度为1920或者1728比特，PBCH映射的时候都假设基站有4天线。其中，PBCH的发送周期为40ms。 待续 PMCH PMCH对应的是单天线模式，没有发射分集，对应的天线端口为4。 需要注意的是，当某子帧，在某载波同时支撑PDSCH和PMCH传输，前2个符号是用作非PMCH传输的，同样，当基站有4个天线端口时，前两个符号也是用作非PMCH传输的，这两个非MBSFN符号的CP长度和0#子帧的长度相同，PMCH不在0号子帧和5号子帧上传输。 Precoding 空间复用： 每一个UE可用的预编码矩阵是由基站制定的，基站可以限定某一个UE只能使用预编码矩阵的子集。 开环预编码（CDD） 对于两天线来说，使用的是对应层数的第一个预编码矩阵。对于四天线来说，则是在不同的向量组上面循环使用对应层数的最后四个预编码矩阵，假设层数为v， 则每v个{x(0)(i) ~ x(v-1)(i)} 使用同一个预编码矩阵，下面v个向量组使用下一个预编码矩阵。 Layer Mapping spatial multiplexing，空间复用，需要注意的问题时，只有当天线数为4的时候，才会有一个码字映射到两个层的情况，但是根据211 中的Table 6.3.3.2-1，其中，有一个codeword对应两个曾的情况，应该是下行4根天线，每两根天线为一组服务一个UE，所以此时因该是双流模式？ transmit diversity，发射分集，只有一个码字，层数由天线数决定，其中，注意对应于四天线的情况，需要注意映射时，如果最终调制完的符号数不能被4整除，需要在后面添加两个NULL符号，在进行速率匹配的过程中，对于层数大于2的情况下，NL=2，所以进行速率匹配之后的信息比特经过调制之后的符号书都是2的倍数，但是不一定会被4整除，因此，这对于不能被4整除的情况需要添加2个符号。 在空间复用和发射分集的情况下，都有一种1个码字映射2个层上面的情况，这种情况下，两者的区别在于预编码上面。 Resoure-element Groups Resource-element Group简称REG，是LTE当中物理资源映射的基本单位，每一组包含四个可用的Resource-element。 需要注意的问题： REG的划分需要根据天线数的不同而不同，具体原因是天线数的不同影响到导频的分布，从而使对应的符号上可用的Resource-element的分步产生变化； REG的划分需要考虑到CP长度的影响，原因也是由于不同长度的CP对应不同的导频分布。 当只有一根小区天线时，需要按照两条天线的导频分布进行REG划分。 REG的编号，按照同一个REG内的最小的频率进行编号，先频率，后符号。 PDCCH、PHICH、PCFICH的分步都是以REG为单位进行。 基站触发的随机接入过程（非竞争接入）
UE根据基站的指示选择相应的随机接入前导序列和掩码发送PRACH（具体过程略），然后开始等待基站端的RAR（等待时间由RAR等待窗口大小确定），过程是通过自己对应的RA-RNTI（RA-RNTI根据UE发送PRACH的时间和频率资源确定）搜索对应的PDCCH； 基站接收到UE发送的PRACH之后，在PDSCH上面发送对应的RAR，与RAR所在的PDSCH对应的PDCCH通过RA-RNTI加扰； UE通过RA-RNTI搜索到对应的PDCCH之后，寻找对应的PDSCH，解码获得对应的RAR信息，如果对应的RAR信息中的前导序列编号和UE使用的前导序列的编号相同，则UE 认为随机接入过程完成··· 基站发起的随机接触过程中的前导序列编号和掩码编号由PDCCH order或者RRC指定，其中RRC制定的模式可能对应于切换时的操作，原因是高层信令的可靠性更高。
UE触发的随机接入过程（竞争接入）
UE发送PRACH（具体过程略），然后开始等待基站端的RAR（等待时间由RAR等待窗口大小确定），过程是通过自己对应的RA-RNTI（RA-RNTI根据UE发送PRACH的时间和频率资源确定）搜索对应的PDCCH； 基站接收到UE发送的PRACH之后，在PDSCH上面发送对应的RAR，与RAR所在的PDSCH对应的PDCCH通过RA-RNTI加扰； UE通过RA-RNTI搜索到对应的PDCCH之后，寻找对应的PDSCH，解码获得对应的RAR信息，然后UE根据RAR信息配置PUSCH发送相应的MSG3消息，如果此时UE不是出于RRC-Connected状态，则该UE没有C-RNTI，这样的话，UE把RAR当众包含的临时C-RNTI设置为自己的临时C-RNTI，如果UE处于RRC-Connected状态，则UE有一个唯一的C-RNTI； 基站解出第一个MSG3消息后，会通过PDSCH发送MSG4消息，MSG4的消息根据UE状态的不同而确定，如果是初始接入，MSG4中包含的消息则是UE发送的MSG3（里面包括UE用户冲突解决的ID），如果是出于RRC-Connected的状态，则可以发送其它一些调度信息在MSG4里面； ->如果UE是初始接入，UE会通过接收到的RAR当中的临时C-RNTI搜索对应的PDCCH，搜索到之后，对对应的PDSCH进行解码，通过对MSG4消息与自己发送的MSG3进行比较，如果相同，则根据对应的消息调整定时之类的，如果不同，则证明有冲突情况发生，当前RAR不属于自己，重新开始下一次PRACH； ->如果UE处于RRC-Connected状态，则通过自己的C-RNTI搜索对应的PDCCH，以此来解决冲突。 基站端在分配C-RNTI的时候，需要避免出现C-RNTI与RA-RNTI，临时RA-RNTI冲突的情况。
| 
发表于 2014-2-11 10:58:09