注意,我们讲上行多址接入时提到,上行所有用户的数据信号到达接收基站的时间需要同步,用户间才能保证正交,才不会有用户之间的相互干扰,这就是上行同步需要达到的效果。那么,怎么达到上行同步呢?比较直观的方法如下:如果用户终端知道基站侧的上行信号接收参考线(上行无线帧)里每个OFDM符号的起始位置,并且知道自己到基站的传播时延 т 就简单了。比如,用户终端相对于基站OFDM符号的起始时刻提前 т 时间发送,那么这个信号经过传播时延 т 到达基站刚好和基站一个OFDM符号重叠,就达到同步效果了,如图18-5所示。
图18-5 上行无线帧同步
但是,用户怎么知道传播时延呢?如果比较容易知道传播时延,那我们下行同步本来也可以采用这种方法了。所以,相对来说,用户终端自己获得传播时延还是比较困难的。但是毫无疑问,要达到上行同步,用户终端必须提前 т 发送,不然你能想到第二种方法吗?就像赶火车一样,火车是到点就要开的,不会等你的。要想赶上火车,就得知道你住的地方到火车站需要多少时间,然后提前那么多时间从住的地方出发,到达火车站就可以刚好赶上火车。既然用户终端自己无法通过测量等获取传播时延,只能别人告诉它了。“别人”还能有谁呢?这个“别人”的合适候选人就是基站了。
那么思路就是基站测量后,再发送消息告诉用户终端传播时延。而基站测量要基于某个东西,才谈得上测量,并且这个东西必然要和要测量的用户终端相关,因为各个终端的传播时延都不一样。至于基于的东西,通信里能有什么,当然还是信号啦!于是思路又变成:用户终端先发一个信号,然后基站根据这个信号测量用户终端到基站的传播时延,最后基站再通过下行把传播时延消息通知给用户终端。
注意,这里用户终端还没有完成上行同步,基站根本就不知道该用户的存在,也就是说基站并没有为用户分配时频资源,用户终端不能随便乱发信号,否则就干扰到正在通信的那些用户了。也就是说用户用来发送信号的时频资源一定是没人用的(没有分配给某个用户),是系统预留的;另一方面,基站不知道哪个用户终端会在哪个时候发起上行同步,从而不能专门为某个用户预留,因此系统预留的时频资源是公共的,即任何用户想要上行同步都可以在该系统预留的时频资源上发送信号。这个系统预留的时频资源在LTE里就是物理随机接入信道(Physical Random Access Channel,PRACH)。下面我们介绍一下如何设计PRACH信号,并完成上行同步。
PRACH信道是基站在上行无线帧里的某些上行子帧上预留的一部分时频资源,这个PRACH信道是周期的,比如周期是10 ms,那么每个无线帧里对应位置的子帧上都有PRACH信道;周期是5 ms,那么每个无线半帧里对应位置的上行子帧上都有PRACH信道。具体周期是多少,PRACH对应的时频资源在哪儿,是基站通过网络实际情况配置的,配置后基站把配置信息广播出来。用户终端在完成下行同步后可以去接收处理广播信道,从而获得这些配置信息。
用户下行同步后,通过接收广播信道,还可以知道每个下行无线帧的编号,编号为0~1023,采用循环记数。请注意,PRACH信道是基站预留在上行无线帧的上行子帧上,并通知给用户终端的。而用户终端目前仅下行同步上了,即仅知道下行时间相关的东西。那么,假设基站广播说PRACH信道在每个上行无线帧的子帧2的PRB 6~11上。终端目前并不知道上行无线帧以及其中每个子帧的起止时刻,当然并不能准确知道上行子帧2是哪个,终端目前唯一的时间参考线就是下行时间线。因此,终端在发PRACH信号的时间参考,只能是它同步到的下行时间线,也就是以下行子帧2的起止时刻为准,在系统上行带宽PRB 6~11上发送信号。对于TDD系统来说可以拿上下行两根时间轴来分析,下行子帧2在下行时间轴里可能是空白子帧,不过是否空白在这里都没有关系,仅作为一个参考对象而已。
要注意终端发的信号不能造成干扰,即要求终端按照下行时间参考发送的信号仍然能落在上行子帧为PRACH信道预留的资源里,一般来说要求基站的下行无线帧和上行无线帧同步对齐,即时间起止重合。不过,仅有这个要求还远远不够,有没有干扰还和终端发的信号持续时间有关。仍然接着上面的例子继续分析,假设基站侧从时间上来看只预留了1 ms的空白时间段,用来容纳PRACH信号,显然终端发的PRACH信号最长就是和这个预留的空白时间段一样长,即1 ms。但实际情况要比1 ms短,具体时间短多少和系统里各基站小区覆盖的区域大小有关。比如,覆盖半径为10 km的小区里,有些终端离基站近,比如就在基站底下,这样的终端发的信号到达基站传播时延几乎为0,那么理论上来说,这样的终端即使发的PRACH信号时长为1 ms也不会有干扰问题,发射的信号能刚好落入PRACH信道,并填满PRACH信道;同时,有些终端可能在小区边缘,离基站距离为10 km,这样的终端发的PRACH信号传播到达基站需要的时长为
通过图18-6可以看到,若这些离基站远的终端发的信号时长也是1 ms,显然由于没有上行同步,传播时延会使得这些终端发的信号落入下一个子帧内,这样会对下一个上行子帧对应PRB上的信号造成干扰。
图18-6 上行PRACH信道设计
同时可以看到,这些处于小区边缘的用户的PRACH信号最长为
1 ms-2×33.3 μs≈933.3 μs
当然,基站不能预测什么时候小区的哪个位置会有终端,终端也不知道自己在小区的哪个位置,和小区的距离有多远,PRACH信号只能是一个统一的长度,即要求短于预留的PRACH信道长度减去小区覆盖的最大传播时延。
说到这儿,按照以上的分析来设计,LTE支持的几种PRACH信道长度为连续1 ms、连续2 ms和3 ms,支持的几种PRACH信号长度大概约为966 μs、1.5 ms和2.3 ms,可以支持的最大小区覆盖半径为100 km。具体应用时,基站根据情况来配置PRACH信道长度、PRACH信号的长度,以及前面已经提到过的PRACH信道所在的时频资源位置,通过广播信道广播给所有打算或已经接入基站的用户终端,终端根据这些配置来进行上行同步。最后,值得一提的是,我们在分析说明问题的时候是假设基站侧下行无线帧和上行无线帧在时间上是准确对齐的,但某些PRACH信道和PRACH信号长度的组合,可以使得即使有些偏差,系统仍然是可以正常工作的,有兴趣的读者可自己去分析。
到目前为止,我们只是把设计框架确定下来了,接下来再介绍一下具体PRACH信号是什么。实际上,PRACH信道对应的PRB里每个子载波会细分成12个子载波,即子载波间隔只有15/12=1.25 kHz,6个PRB共有12×12×6=864个子载波,其中两边预留一些子载波作为保护间隔,实际只有839个子载波用来承载数据,这839个子载波承载的数据是长度为839的ZC序列或其循环移位。不过,并不是同一个序列的所有循环移位都用来做PRACH信号,而是有一定的间隔,比如可用的为循环移位为0、17、34等的序列,原因稍后简单说明。(www.daowen.com)
基站接收PRACH信道所在的上行子帧时,因为PRACH信道和该子帧上其他子载波间隔大小不一样,并且和其他子载波上时间也不同步,一般需要拿单独的滤波器把PRACH信道所在频率的信号过滤出来单独处理,过滤后,所在子帧的其他剩余部分可以用同一个DFT/FFT处理。
接下来,简单讲讲基站如何通过PRACH信号估计出终端到基站的传播时延的方法。基站把PRACH信号过滤出来后,从该子帧的起始位置开始,不停地采样,比如每个符号就采839个点(不包括PRACH信号的CP)。把这839个采样点和所有可用的ZC序列时域形式做相关,若发现某个相关值超过检测门限就认为有终端发PRACH信号,并且是用超过检测门限最大的那个ZC序列(或离该ZC序列移位间隔最近的那个可用序列)来发射,那么该终端到达基站的传播时延近似为0。若没发现超过检测门限的相关值,延迟一个采样点,再取839个点继续和所有可能情况做相关。直到延迟M个采样点后,出现一个相关值,则基站认为有用户终端在发PRACH信号,并且同理也能知道发的哪个可用ZC序列,同时可以知道基站到发这个PRACH信号的终端的传播延迟为M/2个采样点间隔。继续延迟采样点,把所有可以检测出来的PRACH信号都检测出来。若在整个PRACH信道都没有检测到超过检测门限的相关值,则基站认为当前上行子帧上没有用户终端通过PRACH发起上行同步。
终端发起上行同步是没有任何控制和协作的,有可能有多个终端同时在上行同步,都在某个上行子帧的PRACH信道里发PRACH信号,那么如何解决这个冲突呢?分两种情况:
●若用户之间发送的PRACH信号采用的是不同的ZC序列。
●若用户之间发送的PRACH信号采用的是相同的ZC序列。
对于第一种情况,如果基站在同一个子帧的同一个PRACH信道检测出了多个不同的PRACH信号(ZC序列),那么基站会在随机接入响应里,把所有检测到PRACH信号用到的ZC序列索引号,以及对应的传播延迟分别发送下来。所有发了PRACH信号的终端会去接收随机接入响应,看是否有自己发的ZC序列索引号,若有就记下对应的传播延迟,继续后面的步骤;若没有,就等下次发PRACH信号。显然,若终端发的ZC序列不同,是没有什么冲突的,大家都可以区分开。接下来只剩下一种特殊情况,有多个终端发了相同的ZC序列,那么终端在随机接入响应里发现了对应的索引号,会都认为基站收到了自己的PRACH信号。接下来,这些终端会按照对应的传播延迟来提前上行发送数据,上行数据里会携带终端各自的标识。注意,一般情况下这些发相同ZC序列的终端的传播延迟是不一样的,那么基站检测到的所对应的传播延迟一般只会对其中一个真正匹配的终端有效,其他终端按照那个不准的传播延迟提前发送仍然达不到和基站上行同步,从而一般情况下基站只会正确接收真正匹配的终端的上行数据发送。下一步,基站下行反馈正确接收到的数据里携带的标识,所有上一步都发上行数据的终端都去接收,看是否是自己发的那个标识,显然只有基站反馈的标识和自己上一步携带的标识相同的终端才算上行同步上了。到目前位置,上行同步的设计原理基本上讲解完毕,这个设计原理对FDD和TDD系统都适用。仅简单提一下FDD和TDD的区别:
●FDD里上行子帧多,每个上行子帧只有一个PRACH信道;而TDD里一个上行子帧可能有多个PRACH信道,相互之间频分,即处于不同的PRB上。
●FDD里上行子帧是连续的,PRACH信道的周期和每个PRACH信道时长是可以灵活配置的,理论上没有任何限制;而TDD里各不同上下行配比上行子帧分布不一样,能配置的周期和PRACH信道时长都有限制,并且限制都不一样;比如,有些配比,如配比1,PRACH信道的周期最小可以是5 ms;有些配比,如配比4,最小周期只能是10 ms,并且有些配比里永远找不到连续3个上行子帧,因此不可能配置时长为3 ms的PRACH信道。
●除了1 ms、2 ms、3 ms时长的PRACH信道外,TDD系统里还有一个很短的PRACH信道
和对应的PRACH信号,这个PRACH信道位于特殊子帧的上行部分UpPTS里,只能用于覆盖非常小的TDD小区。
●TDD系统里特殊子帧的保护间隔配置会制约PRACH信道/信号的配置。
还有一些更细节的考虑,比如考虑到多径,哪些ZC序列的循环移位不能拿来做PRACH信号等,就不在本书里讨论了。上行的同步维护由基站负责完成,基站通过检测UE上发的DMRS或者Sounding信道来确定UE的上行同步是否相对准确。如果不准确,基站计算出新的提前量,再用时间提前(Timing Advance,TA)命令通知给UE,UE根据新的提前量来发送上行数据。和下行一样,基站如何通过DMRS或者Sounding来完成上行同步维护,由厂商产品实现算法确定,这里不具体介绍。
讲完上下行同步,最后讨论一下LTE TDD无线帧里特殊子帧的保护间隔长度问题。在LTE TDD里特殊子帧分为三个部分,分别为下行部分(DwPTS)、保护间隔(GP)和上行部分(UpPTS)。并且这三部分各占多少个OFDM符号有多种配置,在实际布网时,网络侧会为每个小区选取一种合适的配置。实际上,这个配置问题最终可以归结为保护间隔长度的配置问题。为什么LTE TDD系统里要有这个保护间隔呢?一方面,由于TDD里一般上下行共享一套射频链路,通过收发开关转换来分别服务于下行接收和上行发送。而这个上下行的开关转换一般需要一点时间完成,因此需要一个保护时间,这个保护时间隐含在特殊子帧的保护间隔里;另一方面,是为了避免上下行冲突问题和干扰问题。
上下行冲突问题主要是针对同一个终端来说的。因为同一个终端在接收完DwPTS之前(包括DwPTS)的下行部分后,接下来可能需要上行发送。而我们知道终端的下行接收相对于基站的下行发送来说是延迟的,而终端的上行发送又是要提前的。那么提前发送的时刻必须保证在终端下行接收完之后(包括收发开关转换时间),才不会有接收和发射的冲突。这就取决于基站侧下行部分和上行部分之间的时间间隔以及基站和终端之间的传播时延了。如图18-7所示,对于给定的一个特殊子帧配置,终端1与基站的传播时延小,从而下行接收的截止时刻和上行发送要求的起始时刻之间还有一段时间间隔,不会出现冲突;但对于传播时延较大的终端2来说,上行发送要求的起始时刻在下行接收截止之前就有冲突了。要么下行不接收完保证上行,要么保证下行接收完而影响上行。可以看到,一个小区的保护间隔长度配置取决于离基站最远的终端与基站之间的传播延迟,即取决于小区的覆盖半径。覆盖半径越大,理论上需要的保护间隔越长。当然,本来小区覆盖半径很小,也不限制配置一个很长的保护间隔,只是会造成资源浪费。图18-7中还有一个细节,基站侧区分了“理想无线帧”和“实际无线帧”。“理想无线帧”是按每个子帧都是1 ms来画的。而实际上,基站侧从下行发送转向上行接收也需要开关转换时间,即下行子帧和紧接的上行子帧之间需要一个间隔,这个间隔通过基站把上行接收(U)都提前完成,即如“实际无线帧”所示。
上下行干扰问题主要是针对相邻基站间来说的。就是说,有可能一个基站的下行发射信号传播到达相邻基站时,可能相邻基站正处于上行接收时间,从而造成干扰。并且,由于基站一般放置位置较高,其信号到达相邻基站很少受建筑物遮挡,信号损耗较小,致使信号到达相邻基站功率还很高,干扰较强。要避免这样的干扰,一般要求基站间无线帧绝对同步,同一时刻要么都是下行发送,要么都是上行接收。注意这仅仅是从各自基站来看的动作时间,并不能保证信号出来后的行为。因此,还要求特殊子帧的保护间隔要配置合适,避免一个基站的下行发射信号传播到达相邻基站时,落在上行接收时间。最后,也是要求相邻基站距离越远,即各基站覆盖半径越大,在无线帧同步的情况下,要求保护间隔越长。
图18-7 TDD特殊子帧保护间隔与小区覆盖半径
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。