LTE物理传输资源（1）-帧结构和OFDM符号

写完上一篇博文《LTE小区搜索-物理小区ID和同步信号PSS、SSS》之后，本想继续写系统信息相关内容的，但发现写的时候必不可少的要涉及PDCCH、PHICH等内容，而这些内容目前还没有系统的写。所以接下来的几篇博文，将写一些需要掌握的LTE背景知识。

本文描述的是LTE的帧结构相关内容。

关于帧结构，之前的博文里零散的提到过一些，比如博文《LTE-TDD随机接入过程（2）-前导码Preamble的格式与时频位置》，里面在讲解前导码格式的时候，提到了每个子帧的长度是30720Ts，以及不同的上下行子帧配置时，下行、特殊子帧、上行的配比。本文综合整理一下这些内容。

1.基本时间单位

在LTE里，无论是FDD还是TDD，它的时间基本单位都是采样周期Ts，值固定等于：

其中，15000表示子载波的间隔是15KHz，2048表示采样点个数，因此采样率等于30.72MHz（15000*2048=30.72MHz）。除了15KHz的子载波间隔之外，3GPP协议实际上还定义了一个7.5KHz的载波间隔。这种降低的子载波间隔是专门针对MBSFN（Multimedia Broadcast multicast service Single Frequency Network）的多播/广播传输的，且在R9协议中只是部分给出了实现，因此本博客除非特别说明，都将默认子载波间隔是15KHz。

2.FDD帧结构

协议上对LTE-FDD的帧结构模式，一般又称为Frame structure type 1，这里为了指代明确，还是称呼为FDD帧结构。

在FDD里，每个无线系统帧的长度Tf=307200*Ts=10ms，由20个时隙（slot）组成，每个时隙长度Tslot=15360*Ts=0.5ms，按照0到19进行周期循环编号。每个子帧由2个连续的时隙组成，按照0到9进行周期循环编号，因此1个无线系统帧由10个子帧组成，无线帧的周期是1024。

在FDD里，每个系统帧的10个子帧都可以传输下行，也都可以传输上行，上下行在不同的频域中分别进行。在半双工的FDD模式下，UE不能在同一个子帧里既发送数据又接收数据，而在全双工的FDD模式下，UE则没有这个限制，在同个子帧里可以同时发送和接收数据。

下面是FDD制式的帧结构示意图。

3.TDD帧结构

协议上对LTE-TDD的帧结构模式，一般又称为Frame structure type 2，这里为了指代明确，还是称呼为TDD帧结构。

在TDD里，每个无线系统帧的长度Tf=307200*Ts=10ms，由2个“半帧”组成，每个“半帧”的长度等于5ms，由5个连续的子帧组成，每个子帧长度等于1ms。除了特殊子帧，每个子帧由2个连续的时隙组成。特殊子帧固定在1、6号子帧，由DwPTS（下行导频时隙）、GP、UpPTS（上行导频时隙）组成。同样的，1个无线系统帧由10个子帧组成，无线帧的周期是1024。

下面是TDD制式的帧结构示意图。

相同的子帧在不同的上下行配置（Uplink-downlink configuration）时，可能会发送不同方向的数据。下图是各种上下行子帧配置下，所有子帧发送数据的方向。D表示该子帧只能发送下行数据，U表示该子帧只能发送上行数据，S表示特殊子帧，一般用作下行数据发送。UL/DL configuration参数来自于RRC层的SIB1消息（36331协议），具体参数路径是：SystemInformationBlockType1->tdd-Config->TDD-Config->subframeAssignment，详见博文《LTE-TDD随机接入过程（2）-前导码Preamble的格式与时频位置》。

下行-上行切换周期与10ms内特殊子帧的个数有关，计算方式参考下图。

本质上DwPTS可作为一个常规的下行子帧使用，只是调度的时候有效的RB仅为普通下行子帧的0.75倍，因此传输的数据量较小。一般在讲上下行子帧配比的时候，是将特殊子帧作为下行子帧考虑的。下图所示的就是TDD制式下，各种子帧上下行配比关系。而UpPTS由于时间太短，不用于数据传输，可用作随机接入PRACH（还记得随机接入的DCI格式4吗？请再看一遍文章《LTE-TDD随机接入过程（2）-前导码Preamble的格式与时频位置》）。

特殊子帧的时长与特殊子帧配置相关，如下图所示。关于特殊子帧配置（Special subframe configuration参数），参考博文《LTE-TDD随机接入过程（2）-前导码Preamble的格式与时频位置》。下文会结合OFDM符号长度再说这个表格。

4.OFDM符号

LTE的每个时隙由包括循环前缀（CP）在内的一定数量的OFDM符号组成。除了CP之外的OFDM符号时间称为有用的OFDM符号时间，时长为Tu=2048*Ts=66.7us。若系统是Normal CP类型（普通CP类型），则每个时隙包括7个OFDM符号，若是Extended CP类型（扩展CP类型），则每个时隙包括6个OFDM符号。对于Normal CP类型，每个时隙第一个OFDM符号前部的CP长度是160*Ts，其他的CP长度是144*Ts，第一个符号长度不同的原因仅仅在于为了填满0.5ms的时隙。对于Extended CP类型，每个CP的长度是512*Ts。如下图所示。

我在博文《LTE小区搜索-物理小区ID和同步信号PSS、SSS》的末尾给出了2张PSS和SSS的位置图，从图中可以看到，下行CP类型是Normal CP类型。从该博文中，也可以知道，检测到PSS/SSS同步信号之后，UE就获知了下行CP类型，而上行CP类型是RRC的ul-CyclicPrefixLength字段下发给UE的，如下图所示。

5.特殊子帧占用的OFDM符号个数

结合前文特殊子帧中DwPTS、UpPTS的长度以及每个OFDM符号的长度，可以得到特殊子帧中各部分占用的OFDM符号个数，如下图所示（只列出部分配置，其他配置类似可以画出）。

关于特殊子帧中UpPTS占用OFDM符号个数的计算：

对于上下行都是Normal CP来说，因为UpPTS肯定不在时隙的第一个符号，因此对于UpPTS来说，每个OFDM符号占用的时长是2192Ts（2048+144）。所以：对于时长是2192Ts的UpPTS，那么只需要1个OFDM符号即可传输；对于时长是4384Ts的UpPTS，那么需要2个OFDM符号即可传输。同样的，对于上下行都是Extended CP来说，对于时长是2560Ts的UpPTS，那么只需要1个OFDM符号即可传输；对于时长是5120Ts的UpPTS，那么需要2个OFDM符号即可传输。

6.PSS所处的OFDM符号位置

协议36213提到：如果特殊子帧配置是0、5，且下行CP类型是Normal，或者特殊子帧配置是0、4，且下行CP类型是Extended，那么不能在该特殊子帧中发送PDSCH数据。

For the special subframe configurations 0 and 5 with normal downlink CP or configurations 0 and 4 with extended downlink CP, there shall be no PDSCH transmission in  DwPTS of the special subframe.

下面分析一下为什么会有这个结论，原因是什么。

下图是同步信号PSS和SSS的一种位置示意图。从图中可以看到，这是个TDD制式，且下行CP类型是Normal CP类型。SSS位于子帧0、5的最后一个OFDM符号，无论是哪种上下行子帧配置，0、5子帧始终是下行子帧。PSS位于子帧1、6的第三个符号，而1、6子帧始终是特殊子帧，那么这里需要确保PSS不会落到GP甚至UpPTS中。

从前文的“特殊子帧时间长度”表格中可以看到，DwPTS的长度是由特殊子帧配置（Special subframe configuration）决定的，范围从6592Ts到26336Ts不等。而对于Normal CP时，每个时隙前三个OFDM符号的总长度（含循环前缀CP）=（160+2048+144+2048+144+2048）Ts=6592Ts。也就是说，无论是哪种特殊子帧配置，位于特殊子帧第三个符号上的PSS，总会落在DwPTS中，而不会落到GP甚至UpPTS中。

那么问题来了，如果特殊子帧配置是0或5，且下行是普通CP类型时，DwPTS的时长就是6592Ts，那么这个时候是没有办法在特殊子帧中发送下行数据的。所以，有时候更换了特殊子帧配置，也会影响下行的流量（还记得GAP配置会影响下行流量吗？参考《LTE-TDD资源调度（3）-测量GAP》）。

再来看看扩展CP的情况。当下行CP是扩展CP时，DwPTS的长度范围从7680Ts到25600Ts不等。每个时隙前三个OFDM符号的总长度（含循环前缀CP）=（512+2048）*3Ts=7680Ts。同样的，此时无论是哪种特殊子帧配置，位于特殊子帧第三个符号上的PSS，也总会落在DwPTS中，而不会落到GP甚至UpPTS中。同理，如果特殊子帧配置是0或4，且下行是扩展CP类型时，DwPTS的时长是7680Ts，这个时候是没有办法在特殊子帧中发送下行数据的。

参考文献：

（1）3GPP TS 36.211 V9.1.0 (2010-03) Physical Channels and Modulation

（2）《4G LTE/LTE-Advanced for Mobile Broadband》

（3）http://www.sharetechnote.com/

（4）3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures