1、下行物理信道
下行物理信道一般处理流程：
- 这个过程与TD-SCDMA是不同的。在物理层传输的信号都是OFDM符号，从传输信道映射到物理信道的数据，经过一系列的底层的处理，最后把数据送到天线端口上，进行空口的传输。
| #of TX antennas | PBCH CRC Mack |
|---|---|
| 1 | <0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0> |
| 2 | <1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1> |
| 4 | <0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1> |
PBCH映射到每1帧的第一个子帧的第二个时隙的前四个符号，根据CP长度不同，PBCH对应的编码之后的信息比特为1920或1728比特。
PBCH映射的时候都假设基站有4天线，其中，PBCH的发送周期为40ms。
MIB信息为24bit，经过CRC（包括CRCmask）之后为40bit，再经过1/3CC后为120bit，速率匹配后为1920bit/s（normal CP，extended CP为1728bit/s），这些比特加扰后通过4个无线帧发射出去。
关于一个无线帧的RE数目，在normalCP时为240RE，extendedCP时为216RE，两种情况下导频开销不同。
PBCH不会和PDCCH冲突，因为两者是时分的，永远不会冲突。
SFN的高8bit通过PBCH传输，低2bit通过盲检测PBCH40ms定时获得。
dl-bandwidth，3位，表示6，,1,25,50,75,100六种带宽。
PHICH-duration，1为，表示Normal或Extend。
PHICH-resource，2位，对应PHICH的参数Ng， 等于{1/6，1/2，1，2}。
对Normal CP而言，40ms的物理资源共4*（4*72-4*12）=960个子载波，每个子载波上传输一个QPSK符号，因此传输1920比特。
3、物理控制格式指示信道PCFICH
PCFICH用于指示在一个子帧中传输PDCCH所使用的OFDM个数：
CFI：2bit信息
1/16编码，QPSK调制
PCFICH映射到控制区域的第一个OFDM4个REG上
4个REG之间相差1/4带宽
REG的位置与小区ID有关
PCFICH放置在第1个OFDM符号中，PCFICH的2bit信息通过4个每个长16个QPSK符号的序列承载。CFICH承载的信息非常重要，实际上划分了每个子帧中控制信令区域和数据区域的边界，所以必须采用可以有效抑制干扰的传输方式。因此，一个PCFICH序列的16个符号被分散到整个系统带宽，不同小区放置在不同的子载波组上。另外，PCFICH也进行小区特定加扰(Cell-specificScrambling)。PCFICH采用和PDCCH相同的发射分集技术。
TD-LTE中子帧1,6中的PDCCH最多只能占用2个OFDM符号。
4、PHICH——ACK/NACK传输
PHICH信息含义：eNodeB是否成功解析PUSCH的反馈，ACK/NACK，1bit。
PHICH编码过程：重复3倍，编码输出为3bit。
PHICH调制映射过程：主要有几个参数：
PHICH_duration：这个可以是Normal or extended，在MIB中指示，用来表示PHICH持续多少个OFDM符号，取值可以是1,2,3。
PHICH_group：这个由CP模式，Ng和N_RB_DL决定，在MIB中指示。
mi：这是TDD特有的参数，由上下行配置模式决定在STB1中指示。
PHICH_seq：由于PHICH有扩频操作，NormalCP扩频码长度为4，支持8组复数扩频码，ExtendCP扩频码长度为2，支持4组复数扩频码。
具体调制映射过程是将编码输出的3bit进行BPSK调制，加扰和扩频，以NormalCP为例，经过调制加扰扩频后，输出为12个符号，然后进行分层和Precoding，其中4天线的Precoding在ExtendCP模式下和PBCH略有不同。接下来将不同PHICH_Seq的序列相加，并根据上述几个参数计算物理资源映射的具体位置，最后将相加的结果放入相应的物理资源中。
PHICH接收过程：这里主要存在一个鸡生蛋或蛋生鸡的问题的解决——因为解PHICH需要已知mi，而mi又在SIB1中，SIB1又在PDDSCH中，而解析PDSCH之前，需要先解析对应的PDCCH，在解PDCCH之前，又需要排除PHICH所占用的资源，这又需要知道mi。
解决方法是mi一共有0,1,2三种，因此在解析SIB1之前的第一次解PDCCH可以尝试解三种可能。
HARQ的确认消息也很重要，而且情况多种多样，所以要单独设置一条信道。
PHICH是复用的，给不同的UE的确认消息可以同时发，一个信道可以同时发8个确认消息。
给多个UE的确认消息PHICH是一个组，组内的确认消息的个数是可变的，有四种情况：上行多个PRB给一个HARQ时（2种情况）、上行一个PRB给一个HARQ时，上行MU-MIMO时一个PRB给多个HARQ时。
Multiple ACK/NACK：
由于TDD系统并非在希望反馈ACK/NACK时总能碰到合适的“时隙”，因此需要在将多个ACK/NACK一并发送。
两种方式：ACK/NACK multiplexing
ACK/NACK Bundling
一个PHICH里可能有多个UE的确认消息，也有可能有一个UE的多个HARQ的确认消息。
当用了MU-MIMO时一个PHICH时间会要同时发多个确认，如果一个HARQ要多个PRB承载，那PHICH里的确认消息可以较少。
PHICH占用的OFDM符号数可能采用两种配置：一是将PHICH固定在第一个OFDM符号，但这种方法可能影响PHICH的覆盖性能；
二是采用半静态可配的PHICH长度。经过研究决定采用两种长度半静态可配的方式：
对MBSFN（多播广播单频网）子帧，PHICH长度在1个和2个OFDM符号之间半静态选择；
对非MBSFN子帧，PHICH长度在1个和3个OFDM符号之间半静态选择。
PHICH包含3个REG，采用QPSK调制。对于2天线情况，一个ACK/NACK比特采用Walsh序列经过4倍扩频行程一个REG，然后重复3次，形成一个ACK/NACK信道。由于采用4倍正交码扩频，再加上QPSK的I、Q两路，共可以在一个PHICH内复用8个ACK/NACK信道。在4天线情况下，仍然采用4倍扩频，但要对相应的4天线发送分集方法做一些调整。
和PCFICH一样，PHICH也尽可能均匀分布在6个PRB所在的分别位于3个符号。如带宽内，两个相邻PHICH REG之间相隔6个REG，另外，在时域上，PHICH也尽可能分散到控制区域所在的所有符号，PHICH长度为3，因此3个PHICH REG有一个位于第一符号，有两个位于第二符号。
PHICH信令是和上一周期上行数据紧密联系的，因此PHICH需要占用的资源与一个周期内的上行数据信道资源有一定关联，这就为隐性地表示PHICH资源创造了可能。最后决定，将PHICH使用的资源位置和上行资源分配的第一个PRB之间建立联系。
由于采用了独立的PHICH和PCFICH信道，而且这两个信道使用的资源是相对固定的（PCFICH资源是静态的，PHICH资源是半静态的），因此系统会首先分配PHICH和PCFICH信道使用的RE，然后将剩下的RE分配给PDCCH，PDCCH将在这些剩下的RE内进行交织。
PCFICH占用的RE是静态的，不会对PDCCH的资源指示造成影响，但PHICH占用的RE是半静态变化的，占用哪些RE应该由系统信息指示。如果这个系统信息放在PDCCH中，就带来了“鸡生蛋，蛋生鸡”的问题：PDCCH需要获知PHICH占用的RE才能解调，而PHICH反过来需要PDCCH通知它使用了哪些RE。为解决这个问题，最终决定在PBCH中对PHICH格式进行指示，虽然PBCH的开销本来应该是严格控制的。在PBCH中使用1bit指示PHICH的长度，2bit指示PHICH使用的频域资源，即PHICH组的数量（每个组包含8个PHICH）。在频域上，PHICH采用等间距放置，即每隔固定数量的子载波放置一个PHICH的REG。为了抑制不同小区PHICH之间的干扰，还采用循环位移的方法使相邻小区在错开的频域资源上发送PHICH。某个小区的PHICH位移可以和它的小区ID对应，因此不需要 额外的信令传输。
PHICH占用的时域位置（符号位置），由胶片中的表来决定，或MIB来决定，目的是要在时域上尽可能地离散。
PHICH占用的频域位置（子载波位置），由胶片中的项目来决定，其中PHICH_group序号代表着和上行承载HARQ的RB的起始标号有关。
5、物理下行控制信道PDCCH
PDCCH用于承载资源分配信息，包括功率控制等；
逻辑映射：
一个PDCCH是一个或者几个连续CCE的集合；
根据PDCCH中包含CCE的个数，可以将PDCCH分为如下四种格式。
| PDCCH格式 | CCE个数 | REG个数 | PDCCH比特数目 |
| 0 | 1 | 9 | 72 |
| 1 | 2 | 18 | 144 |
| 2 | 4 | 36 | 288 |
| 3 | 8 | 72 | 576 |
经过研究，决定采用TDM方式复用下行信令。具体地说，物理下行控制信道（PDCCH）放置在一个子帧的前n个（n<=3）OFDM符号。数据最早可以在PDCCH的最后一个OFDM符号开始。
接下来的问题是如何指示PDCCH的内部结构。PDCCH中包含的下行信令是指导UE正确接收和发送数据的信息，但PDCCH本身包含给小区众多用户的下行控制信令，结构也较复杂，如何使每个UE都能够快速地找到并准确地解调自己的控制信令，同时保持PDCCH具有较低的开销，也是一个难题。因此，首先应该定义PDCCH内部的资源分配单位，然后再设计指示PDCCH内部结构的方法。
一条PDCCH只能携带一个用户的信息，用户是根据CRC上的RNTI（无线网络临时鉴定：在UE 和UTRAN 之间的信号信息内部作为UE 的标识）来识别的。
UE在盲检前，只知道CCE的个数，PDCCH的时间范围，或者说只知道PDCCH所拥有的时域和频域的范围，以及PDCCH的最大个数。UE不知道PDCCH的具体个数，更不知道哪个PDCCH是我的。
一个PDCCH对应一个UE标示（RNTI），UE标示长度为16比特，与上图中CRC的长度相同，采用与CRC异或的方式在PDCCH中传输。
根据不同的DCI format（下行控制信息格式），PDCCH的内容大小可能是26，43，46，56，72比特，系统不支持码率大于3/4的“PDCCh内容大小”和“占用的CCE个数”的组合。
UE specific的搜索空间的起点有“hashing 函数”给出，函数的输入包括：UE_ID、Aggregation Level、number of CCEs in this subframe，subframe number。
DCI下行控制信息的量是不确定的，就是同一种DCI编号，它的数据量也是不定的，受频宽和天线数目影响，3/3A是功控信息。
UE一般不知道当前的DCI传送石什么Format的信息，也不知道自己需要的信息在哪个位置，但是UE知道自己当前在期待什么信息，例如在Idle态UE期待的信息是paging，SI；发起RandomAccess后期待的是RACH Response；在有上行数据等待发送的时候期待UL Grant等。对于不同的期望信息UE用相应的X-RNTI去和CCE信息做CRC校验，如果CRC校验成功，那么UE就知道这个信息是自己需要的，也知道相应的DCI format，调制方式，从而进一步解出DCI内容，这就是所谓的“盲检”过程。
协议首先划分了CCE公共搜索空间（Common Search Space）和UE特定搜索空间（UE-specific Search Space），对于不同的信息在不同的空间里搜索。
另外对于某些format信息，一个CCE是不够承载的，可能需要多个CCE，因此协议规定了所谓的CCE Aggregation Level取值为1,2,4,8。例如对于位于公共空间里的信息Aggregation Level只有4,8两种取值，那么UE搜索的时候就先按4CCE为粒度搜索一遍，再按8CCE为粒度搜索一遍。
盲检的次数不是22二是44，是因为对于每种transmission mode，都有需要检测两种不同size的DCI format，比如对于transmission mode 1，UE需要检测DCI0/1A，和DCI1。0/1A是相同的size，而DCI1与DCI 0/1A的size是不一样的，所以UE这两种size都要检测一次，才能确定到底收到的是DCI0/1A，还是DCI1。而DCI0/1A可以用一个flag来区别，所以因为是两种size，22就需要乘以2。
为了减少format 1C带来的额外盲检测数目，对它在Common Space中的起始位置进行了限制：
对于PBCH的调度总是从CCE0开始（包括Aggregation Level等于4或8）；
对于RACH response的调度信息总是从CCE8开始（包括Aggregation Level等于4或8）。
在资源分配信令中，使用“5bits MCS指示”结合“分配的RB数目”，即可得到传输块大小（TBS）。
下行使用单独的表项是因为重传不改变码率，只是可能因为信道情况而使用不用的调制方式。
上行使用同步HARQ机制，重传与初传使用想用的调制方式。
胶片中不是22次而是44次的原因大概是：根据不同的资源分配方式，UE要收两遍。
4468
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
