LTE中小区搜索过程

《LTE中小区搜索过程》由会员分享，可在线阅读，更多相关《LTE中小区搜索过程（9页珍藏版）》请在装配图网上搜索。

1、LTE中社区搜索过程图解我们懂得在LTE系统中，UE使用社区搜索过程来辨认社区，并获得下行同步，进而UE可以读取社区广播信息并驻留、使用网络提供的多种服务。此过程在初始接入和切换中都会用到。社区搜索的目的总结如下：1） 检测社区的物理层社区ID（Physical Cell-ID）通过PSS和SSS检测获取社区ID2）完毕时间/频率同步时间同步：获取10ms无线帧同步、40msPBCH TTI同步频率同步：与eNodeB载波频率同步3） 下行CP模式检测：normal模式 或者extended模式4）检测eNodeB所用的发射天线端口数5）读取PBCH（即MIB）获取SFN、下行系统带宽、PHI

2、CH配备信息6） 根据不同场景，支持最强社区、多种社区和存储社区列表（Stored-InformationCell Search）等多种模式的社区搜索。同步信号总是占用可用频谱的中间62个子载波（不考虑DC子载波）。不管小辨别配了多大带宽，UE只需解决这62个子载波。同步信号具体来说，是由一种PSS信号和一种SSS信号构成。同步信号每个无线帧发送两次。规范定义了3个PSS，使用长度为62的频域Zadoff-Chu（ZC）序列。每个PSS信号与物理层社区标记组内的一种物理层社区标记相应。SSS信号有168种，与168个物理层社区标记组相应。故UE在获得了PSS和SSS信号后即可拟定目前社区标记（

3、cell id）。下行参照信号用于更精确的时间同步和频率同步。（注意，此步是辅助性的。CRS的目的重要还是测量和信道估计）。完毕社区搜索后UE可获得时间/频率同步，社区ID辨认，CP长度检测、FDD or TDD等。1. UE上电之后，在也许存在LTE社区的中心频点上检测主同步信号PSS。UE以接受信号强度(具体取决与终端芯片的实现)来判断这个频点周边与否也许存在社区。如果UE保存了上次关机时的频点和运营商信息，则开机后会先在上次驻留的社区上尝试搜索PSS；如果没有，UE就要结合自己的频段支持能力，在划分给LTE系统的band上做全频段扫描，若发现信号较强的频点、就觉得也许存在LTE社区、并去

4、尝试匹配PSS；2. 在这个中心频点周边收PSS（主同步信号）并进行码域的匹配，由于PSS占用了中心频带的6RB（126=72子载波），因此这种设计可以兼容所有的系统带宽。PSS信号以5ms为周期反复，在子帧#0发送，并且是ZC序列，具有良好的有关性。因此，UE将第1步中接受到的6RB上的总能量，用ZC序列进行码域的匹配，据此可以得到社区组里的社区ID，同步拟定5ms的时隙边界。此外，在背面检测出来SSS之后，还通过检测这个信号就可以懂得循环前缀的长度以及采用的是FDD还是TDD。由于TDD的PSS是放在特殊子帧里面的，位置有所不同，由此可推断出是FDD还是TDD。但是，由于PSS是5ms反复

5、的，5MS里的PSS完全相似，因此，在第2步中，还无法获得无线帧同步（10ms)，只能获得5MS定期；1.2.3. 5ms时隙同步后，在PSS基本上搜索SSS，SSS由两个m序列级联而成，前后半帧的映射顺序正好相反，因此只要接受到两个SSS就可以拟定10ms的边界，达到了帧同步的目的。由于SSS信号携带了社区组ID，结合前面的PSS，就可以获得物理社区ID（CELL ID）。cell id: 323=107*3+24. 在获得下行同步后来，就可以读取PBCH了，通过上面两步还可以获得下行参照信号的构造(位置)，通过解调参照信号、可以进一步的精确的时隙与频率同步，同步CRS还可觉得解调PBCH做

6、信道估计。PBCH在子帧#0的slot #1上发送，通过解调PBCH，可以得到系统帧号和带宽信息，以及PHICH的配备、天线数配备等。此外，系统帧号SFN以及天线个数的设计，比较精致: SFN位长为10bit，取值为01023。在PBCH的MIB中，只广播了SFN的前8位，而剩余的SFN的后2位，是根据该帧在PBCH 40ms周期窗口的位置拟定：第一种10ms帧为00，第二帧为01，第三帧为10，第四帧为11。而PBCH的40ms窗口、手机可以通过盲检拟定的。天线个数，是隐含在PBCH的CRC里面的。由于PBCH的位置固定，承载MIB内容，因而MIB不需要动态调度，因此PBCH的CRC16个比

7、特，还可以再做点文章并加以运用的。基站是通过天线个数相应16比特的特性串（36.211里定义），对PBCH的CRC部分进行加扰；反过来，UE又可以通过CRC部分的校验，推断出基站的天线端口的配备。5. 至此，UE实现了和eNB的定期及同步；6. 要完毕社区搜索，仅仅接受PBCH是不够的，由于PBCH只是携带了非常有限的系统信息，更多更具体的系统信息是由SIBs携带的，因此背面UE还需要接受SIBs，即UE需要接受承载在PDSCH上的BCCH信息。为此UE需进行如下的动作：a) 接受PCFICH。此时该信道的频域RBG资源可以根据物理社区ID推算出来(TS36.211 6.7.4)，通过接受解码

8、PCFICH得到PDCCH的symbol数目（CFI）；b) 在PDCCH信道域的公共搜索空间里查找发送到SI-RNTI的候选PDCCH，如果找到一种并通过了有关的CRC校验，那就意味着有相应的SIB消息，于是接受PDSCH，解调PDSCH里相应的SIB内容，解码后将SIB上报给高层合同栈；c) 不断接受SIB，上层（RRC）会判断接受的系统消息与否足够，如果足够则停止接受SIB。至此，社区搜索过程才完全结束；d) 此外，SIBs的调度除了SIB1外均是以SI为单位调度的。调度机制及系统消息的更新机制及映射到同一种SI的约束关系，此处不作具体探讨。注意上图的两个system informati

9、on（SI）中，第一种SI给UE调度了SIB2/SIB3，第二个SI给UE调度了SIB5/SIB6/SIB7。 即SIB2/SIB3映射到了一种SI，而SIB5/SIB6/SIB7又映射到了此外一种SI。UE依托PDCCH上的SI-RNTI来拟定与否有被调度接受的SI。MIB只有有限的3个参数：下行系统带宽、PHICH的配备、系统帧号SFN，为什么还要单独设计，甚至单独给一种PBCH信道，并且其时频资源均已知（有固定的时间和频率位置）？MIB不参与调度，而其她的SIB消息，最后映射到PDSCH，是要参与调度的。即，针对社区内所有顾客的SIBs，是需要和顾客的专用数据、CCCH及寻呼等这些一起复用PDSCH信道、并最后由MAC层统一调度的。既然调度，UE需要检测PDCCH；而盲检PDCCH能成功，必须一方面要懂得下行系统带宽，PHICH的配备，以及SFN这三个参数了那结论就很明显了这三个参数必须一方面要让UE能读取出来，否则背面的SIBs主线没法读取，甚至连社区搜索都完毕不了。RRC_IDLE： MIB、SIB1、SIB2SIB8（视UE支持能力及网络参数配备而定）RRC_CONNECTED： MIB、SIB1、SIB2（SIB3一般不读。读不读取决于终端实现及RRC层合同栈的需要，目前从测试状况来看连接态下是不需要读SIB3的）