写完上一篇博文《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