搜索
查看: 1952|回复: 8

【加菲戏说LTE】之三:协议篇,时频资源分析

[复制链接]

22

主题

336

帖子

1000

积分

金牌会员

Rank: 6Rank: 6

积分
1000
发表于 2014-5-7 07:58:57 | 显示全部楼层 |阅读模式
2.协议篇:时频资源部分

以下资料均来源于3GPP 36系列协议。
36.211
1.jpg


2.jpg

9.上行资源格

加菲乱谈:LTE系统协议叫工程师难以理解的地方就是:有太多的符号和公式。和以前的系统不同的是,LTE系统具有太多的灵活性。为了表示这种灵活性,数学公式显然比不同配置的图表更加简洁。但是,这样也带来了一个副作用:如果不仔细带入数据演算,很难深刻的了解这些公式的物理含义。
个人看法,公式是好的,但是对于下行PRB个数这个问题,一堆公式还不如下面一个小小的表来得明白。系统带宽包括信号与保护带(用于邻道滤波器滚降),所以大于信号带宽。
            
系统带宽(MHz

            
            
1.5

            
            
3

            
            
5

            
            
10

            
            
15

            
            
20

            
            
#PRB

            
            
6

            
            
15

            
            
25

            
            
50

            
            
75

            
            
100

            
            
信号带宽(MHz

            
            
1.08

            
            
2.7

            
            
4.5

            
            
9

            
            
13.5

            
            
18

            
下来再聊聊神奇数值712的由来。7是一个时隙的符号数目,12PRB的子载波数目。这又是常数,按照上一讲的介绍,突然而来的常数都是有故事的人啊。(叫我想起了《东京爱情故事》的主题歌:《突然道来的爱情》,真的太经典了。)
先说说OFDM符号长度的问题,这个指标有几个约束:1)有效信号长度必需是所有子载波周期的整数倍(这是FFT算法的一个局限,非整数倍对于傅立叶分析是比日本地震+海啸+核污染还大的灾难。这也触发了后来的时频分析大出现,说远了);2CP必需可以抵抗多径时延;3)在满足以上两点要求的前提下,长度越短信息传递的越多,越长则误码越低。在综合考虑之后,3GPP选择了7(七仙女?)。
子载波的最小单元则取决于:1)硬件的FFT资源的大小问题(在硬件结构上不同质数为基的FFT的结构是不同的,所以12 的基是23,结合协议规定的调度基是235,这样就只要3FFT了,资源比较节约);2)最小的包的要求(系统允许的最小业务,应该定义在一个RB内完成,并且插入的无意义的padding不能太多)。
加菲判曰:技术上很多常数,看似随意,实际上没有多少是怕脑袋的。
3.jpg

4.jpg

10.下行资源格

加菲乱谈:下行的情况与上行类似,书不重表。
需要注意的是,无论怎么样,下行的调制和解调都只需要全部带宽对应子载波数目的FFT。例如,对应20 MHz带宽系统是 1200个,加上保护带宽就是2048点,正好是2的幂。
小区专用参考信号应在支持PDSCH传输的小区中的所有下行子帧中传输。
小区专用参考信号在天线端口0~3中的一个或多个端口上传输。
小区专用参考信号仅适用于子载波间隔 15 KHz的情况。
……
5.jpg
在一个时隙中,任何天线端口上用于传输参考信号的资源单元   不能在相同时隙中其他天线端口上进行任何传输,并被设置为0
在一个MBSFN子帧中,小区专用参考信号只在非MBSFN域传输。
1112 给出了按上述定义的用于参考信号传输的资源单元示意图。其中   表示在天线端口   上用于传输参考符号的资源单元。
F11.jpg

11.下行参考信号映射(常规CP)



f12.jpg

12.下行参考信号映射(扩展CP)

加菲乱谈:参考信号(RS)是OFDM解调的参考,除了一些固定码的信道,如:PRACHPSSSSS等。无线通讯系统进化到了现在,一般都采用带有学习序列的相干解调技术。理论上,相干解调的可靠性更高,可以更好地抵抗信号早空口传播时候,信道衰落的影响。
参考信号的设计是“加一分太长,减一分太少”的精细活。太多的参考信号,会降低系统有效数据的传输。太少的RS又会降低系统性能。
最后,下行RS的位置是和PCI以及系统逻辑天线数目有关的。对于双天线端口系统,RS的位置可能有3种,这就是所谓“模三干扰”的来源。如果还有资料说这个干扰是PSS带来的,把它丢了吧!要是有人还坚持这个说法,我的建议是面试不通过。
最后,唠一唠这个“模三干扰”。老衲说:这就是一个伪命题。在邻区都空闲的时候,的确邻区的RS不干扰本小区的RS,在SINR看来是有好处的。但是,邻区的RS不和本小区的参考信号重合,就必然和本小区的数据重合。就是说不干扰RS就干扰数据,到底哪个好,不好说了。再来看看,真实系统更加可能共址的状态:系统接近满负荷。这个时候,“非模三干扰”邻区的数据部分也会干扰本小区的RS。无论如何,此时同频干扰是不可避免的。降低“模三干扰”,无论你高兴不高兴,本质上说,就是花功夫应付局方开始空负载下的拉网检查。我的话,就是“猫盖屎”。

与非网加菲原创,谢绝转载。

更多内容详见:大V在线,加菲戏说LTE


回复

使用道具 举报

3

主题

133

帖子

1616

积分

版主

Rank: 7Rank: 7Rank: 7

积分
1616
发表于 2014-5-7 08:45:10 | 显示全部楼层

RE:【加菲戏说LTE】之三:尤益醒来两眼黑,概述地理定经纬(之三)

沙发是我的,过来学习学习!
回复 支持 反对

使用道具 举报

0

主题

1

帖子

1

积分

新手上路

Rank: 1

积分
1
发表于 2014-5-7 16:11:07 | 显示全部楼层

RE:【加菲戏说LTE】之三:尤益醒来两眼黑,概述地理定经纬(之三)

请教,上行SRS能否代替DMRS进行解调?这样可以节省RE资源
回复 支持 反对

使用道具 举报

0

主题

23

帖子

4

积分

新手上路

Rank: 1

积分
4
发表于 2014-5-7 16:53:26 | 显示全部楼层

回复:【加菲戏说LTE】之三:尤益醒来两眼黑,概述地理定经纬(之三)

正在弄LTE的东西,很及时的资料
回复 支持 反对

使用道具 举报

22

主题

336

帖子

1000

积分

金牌会员

Rank: 6Rank: 6

积分
1000
 楼主| 发表于 2014-5-7 19:02:00 | 显示全部楼层

回复:【加菲戏说LTE】之三:尤益醒来两眼黑,概述地理定经纬(之三)

不能,因为
1)SRS和数据并不能保证同一个子帧发射,窄带SRS也不能保证和data在相同PRB上
2)SRS在子帧最后面,很难标记前面符号的信道
3)SRS只一个符号,一个RE/PRB上能量太低,性能不好
回复第 3 楼 于2014-05-07 16:11:07发表:
请教,上行SRS能否代替DMRS进行解调?这样可以节省RE资源
回复 支持 反对

使用道具 举报

27

主题

73

帖子

504

积分

高级会员

Rank: 4

积分
504
发表于 2014-5-8 10:45:10 | 显示全部楼层

RE:【加菲戏说LTE】之三:尤益醒来两眼黑,概述地理定经纬(之三)

来支持有才的加菲。
回复 支持 反对

使用道具 举报

10

主题

97

帖子

303

积分

中级会员

Rank: 3Rank: 3

积分
303
发表于 2014-5-12 09:32:30 | 显示全部楼层

RE:【加菲戏说LTE】之三:尤益醒来两眼黑,概述地理定经纬(之三)

还好没有来晚
回复 支持 反对

使用道具 举报

0

主题

188

帖子

431

积分

中级会员

Rank: 3Rank: 3

积分
431
发表于 2014-5-26 18:34:02 | 显示全部楼层

RE:【加菲戏说LTE】之三:协议篇,时频资源分析

谢谢分享
回复 支持 反对

使用道具 举报

0

主题

8

帖子

52

积分

注册会员

Rank: 2

积分
52
发表于 2014-7-15 16:32:52 | 显示全部楼层
对我来说还是有点深奥,不太好懂
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Archiver|RF技术社区

GMT+8, 2018-7-19 05:33 , Processed in 0.147871 second(s), 11 queries , MemCache On.

Powered by Discuz! X3.4

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表