前言

       UE在搜索小区过程之后, 已经与小区取得下行同步,得到小区的 PCI(Physical-layer-Cell Identity) 以及检测到系统帧的 timing(即 10ms timing)。 接着,UE 需要获取到小区的系统信息(System Information),这样才能知道该小区是如何配置的,以便接入该小区并在该小区内正确地工作。
        系统信息是小区级别的信息,即对接入该小区的所有 UE 生效。 系统信息可分为MIB ( MasterInformationBlock)和多个 SIB (SystemInformationBlock),每个系统信息包含了与某个功能相关的一系列参数集合。系统信息类型如下:

        并不是所有的SIB都必须存在,对运营商部署的基站而言,就不需要SIB9;小区会不断的广播这些系统信息,有三种类型的RRC消息用于传输系统信息:MIB消息,SIB1消息,一个或者多个SI消息。                                                          

        小区是通过逻辑信道BCCH向该小区内的所有UE发送系统信息的。

        从下图可以看出:逻辑信道BCCH会映射到传输信道BCH和DL-SCH,其中BCH只用于传输MIB信息,并映射到物理信道PBCH;DL-SCH用于传输各种SIB信息,并映射到物理信道PDSCH。

 

MIB

MIB消息中承载的是最基本的信息,这些信息涉及到PDSCH信道的解码,UE只有先解码到MIB,才能利用MIB中的参数去继续解码PDSCH中的数据,包括解码SIB信息。MIB消息包含的参数如图2所示。


(图2 MIB消息携带的参数)

(1)dl-Bandwidth:下行带宽参数,指示当前下行链路的带宽大小。取值范围是n6(对应1.4MHz)、n15(对应3MHz)、n25(对应5MHz)、n50(对应10MHz)、n75(对应15MHz)、n100(对应20MHz),分别表示当前带宽占用的RB个数,如n6表示带宽占用6个RB。因为下行带宽大小影响了PDSCH的解码,因此必须要将下行带宽dl-Bandwidth参数放到MIB中。本字段只需要3个bit就可以完成编码。

(2)phich-Config:PHICH配置参数,包括phich-Duration和phich-Resource这两个参数。phich-Config用于计算PHICH信道的位置(请参考《LTE下行物理层传输机制(3)-PHICH信道》),而PHICH信道的位置会影响PDCCH和PDSCH的解码,因此PHICH的配置参数需要在MIB中传输。本字段只需要3个bit就可以完成编码。


(图3)

(3)systemFrameNumber:系统帧号,用于UE和网侧的帧同步。之前在《LTE小区搜索-物理小区ID和同步信号PSS、SSS》里提到的是子帧的同步,UE只有成功解码了MIB,才能完成系统帧号的同步。需要注意的是,因为帧号的范围是0~1023,需要10个bit才能完整的编码1024个数据,但本字段并不能使用10个bit,而只能传输系统帧号的高8位(MSB)。至于为什么系统帧号的低2位不能在本字段中发送,后文在讲到MIB周期发送的时候会解释。

这里说明一下MIB占用的bit位个数以及原因:上述三个字段的有效信息只需要14bits(=3+3+8)就可以完成编码,考虑ASN1编码实现的时候需要字节对齐,所以MIB最低可以使用16bits的空间。但如果MIB占16bits,那么此时预留的bit位(图2中的spare字段)个数只有2个(=16-14),以后扩展的时候会很受限,所以这里协议为MIB分配了24bits的空间,预留的bit位是10bits(=24-14)。

MIB的解析

UE通过检测PBCH,能够得到一下信息:

(1)通过接收到MIB可以知道小区的下行系统带宽、PHICH配置,系统帧号(SFN,System Frame Number,更确切地说是获得SFN的高8位,最低两位需要在PBCH盲检的时候得到)。

(2)小区特点的天线端口(cell-specific antenna port)的数目:1或2或4.

(3)用于L1/L2 控制信令(包括 PCFICH、PHICH、PDCCH)的传输分集模式(transmit-diversity scheme):PBCH和L1/L2l控制信令都只能使用单天线传输或传输分集,如果使用传输分集,PBCH和L1/L2 控制信令会使用相同的多天线传输分集模式。

通过下图可知,PBCH时域上位于每个系统帧的子帧0的第2个slot的前4个OFDM符号上,并且在频域上占据72个中心子载波(不含DC)。

       把BCH传输限制在72个中心的子载波,而不考虑小区的下行系统带宽的原因在于:UE在接受BCH时并不知道小区的下行系统带宽。因此UE第一次接收BCH时,可以假定小区的下行系统带宽等于可能的最小下行系统带宽(6个RB,对应于72个子载波)。在解码了MIB之后,UE就能从MIB中得到实际的下行系统带宽。

      MIB在40ms的周期内重复了4次,每一次发送的PBCH都携带相同的coded bit ,也就是说,每一次都是可以单独解码的。因此,在信道质量(SIR)足够好的情况下,UE可能只接受这40ms内其中一个,就能成功的解码出PBCH的内容;如果不行,就在与下一个10ms发送的PBCH的内容进行软合并,在进行解码,直到成功解码出PBCH。

      40ms内每次发送的PBCH会使用不同的scrambling and bit position(即共有4个不同的 phase of the PBCH scrambing code),并且每40ms会重置一次。UE可以通过使用4个可能的phase of the PBCH scrambling code 中的每一次去尝试解码 PBCH,如果解码成功,也就知道小区是在40ms内的第几个系统帧发送MIB,即知道了SFN的最低两位。

  PBCH的多天线传输只能使用传输分集,而且在2天线端口传输时,只能使用SFBC;4天线端口传输时,只能使用combined SFBC/FSTD。UE使用3种不同的CRC mask来盲检PBCH,可以得到天线端口数目与传输分集模式--对应(1天线端口端口对应单天线端口传输;2天线端口对应SFBC;4天线端口对应combined SFBC/FSTD),因此当UE成功解码PBCH时,就知道小区特定的天线端口数以及用于L1/L2控制信令的传输分集模式。

 PBCH有三种天线端口组合(1/2/4)和4种不同扰码(phase)组合,所以盲检PBCH具有12中可能组合。

MIB在物理层的编码处理和流程映射如下图:

 

 

SIB

 

       LTE的SIB类型有很多种,对于R9版本的协议来说,SIB具体包括SIB1、SIB2、SIB3、SIB4、SIB5、SIB6、SIB7、SIB8、SIB9、SIB10、SIB11、SIB12、SIB13这13类。早期的SIB1也被称作SU-1,全称是Scheduling Unit-1,其他的SIB块被称为SU-n,MIB也被叫做SI-M,现在已经不这么叫了,如果有在其他资料中看到这种提法,也不要惊讶。不同的SIB携带不同的参数,具备不同的目的,具体如下:

SIB1:主要携带小区接入和小区选择相关信息,以及LTE-TDD子帧配置、其他SIB块的调度和窗口信息等。

SIB2:主要携带公共的无线资源配置相关信息,包括接入BAR信息、PRACH配置信息、上行频点信息、MBSFN配置等。

SIB3:携带同频、异频、跨制式小区重选相关的公共信息。

SIB4:携带用于同频小区重选的邻区信息。

SIB5:携带用于异频小区重选的邻区信息。

SIB6:携带用于跨制式(UTRA)小区重选的邻区信息。

SIB7:携带用于跨制式(GERAN)小区重选的邻区信息。

SIB8:携带用于跨制式(CDMA2000)小区重选的邻区信息。

SIB9:携带HOME eNB(HNB)的相关信息。

SIB10/11:携带ETWS(Earthquake and Tsunami Warning System)的相关信息。当UE从寻呼消息中解码发现有ETWS消息存在时,就需要从SIB10/11中获取具体的ETWS内容。这些告警信息是在paging中通知。

SIB12:携带CMAS(Commercial Mobile Alerting System)的相关信息。当UE从寻呼消息中解码发现有CMAS消息存在时,就需要从SIB12中获取具体的CMAS内容。

SIB13:携带MBMS(Multimedia Broadcast Multicast Service)的相关信息。

所有SIB中最重要的当属SIB1,因为SIB1除携带了UE接入小区等所需的参数之外,还携带了其他SIB类型的调度信息

     

UE能不能驻留这个小区,取决于红框中的3个参数:

  • PLMN:小区的PLMN
  • Cell barred:小区是否bar掉
  •  RxlevMin:UE能够驻留到此cell最小RSRP.

如果UE解码不到SIB1,也就无法解码其他类型的SIB。基于此,协议规定eNB通过两种不同的方式广播SIB:第一种是通过SystemInformationBlockType1消息周期广播SIB1,第二种是通过多个SI(SystemInformation)消息周期广播除SIB1之外的其它SIB,如图所示。

 

 

需要说明的是,除了SIB1之外的其他SIB块,如SIB2、SIB3等等,同一个SIB块只能放在同一条SI消息中传输,不能分割映射到两条不同的SI消息中。多个SIB块也可以封装到同一条SI消息中一起发送,但前提是这几个SIB块的周期必须相同。这个地方要注意,以后SI特指除SIB1之外的SIB消息。

不同于MIB在PBCH中的发送,所有SIB均需要使用SI-RNTI加扰,在CCE公共空间中通过PDSCH信道传输。

2、SIB的周期发送

SystemInformationBlockType1消息(下文简称SIB1消息)的周期固定等于80ms,且只在5号子帧中传输。之所以选择5号子帧,是因为无论哪种LTE-TDD配置,5号子帧都是下行子帧,不需要区分上下行子帧配置。

类似于MIB的发送机制,SIB1消息在80ms内也是重复发送4次。若系统帧号SFN满足条件(SFN mod 8 = 0),则认为该系统帧的5号子帧是第一次发送本周期的SIB1块,然后在同个周期内其它系统帧号满足条件(SFN mod 2 = 0)的5号子帧上重复发送SIB1块,如图2所示。

(图2 SIB周期)

 

不同SI消息的周期既可以相同也可以不同,图3所示的就是一种可能的情况。在这个图中,SIB2在SI-2消息中发送,周期是160ms;SIB3和SIB4的周期都是320ms,被封装在SI-3消息中一起下发。

(图3 不同SI的周期示例)

 

每个SI消息的发送时机都被限制在一个独立的窗口之内,这个窗口也被叫做SI窗口,如图4所示。每个SI消息对应着一个SI窗口,这些不同的SI窗口并不会重叠,在某个SI窗口内,只有这个SI窗口对应的SI消息才会被传输,其他的SI消息不会发送。所有SI消息的窗口长度都是相等的,值可以在SIB1中配置。在一个SI窗口内,该窗口对应的SI消息可以发送多次,且可以在任意子帧中发送,当然这些子帧不包括MBSFN子帧、TDD上行子帧和被SIB1占用的发送子帧。

从图4中可以看到,相邻两个SI窗口之间的距离就是该SI的周期长度,每个SI的周期长度也是在SIB1中配置的。在一个SI窗口内,SI消息可以在多个子帧中连续发送,也可以跳过某个子帧不发送。

(图4 SI窗口示意)

从上面可以看出,每个SI的窗口长度,周期都是在SIB1中定义的,且各个窗口都是相等,不能重叠,若是周期一样,可以放在一起传输。然后在窗口内就可以发送该SI,只要不与其他一些冲突就可以。

 

3.SIB1中的SI调度和窗口参数

SIB1携带了所有SI消息的调度和窗口参数,通过这些参数可以计算出每条SI消息的周期和发送时刻,如图5中的黄色区域所示。

(图5 SIB1中关于SI周期和窗口的参数)

图5中的相关参数说明如下:

SchedulingInfoList:指示结构体SchedulingInfo数组的长度。SI消息序列中必须至少包含SIB2,且SIB2需要放在数组SchedulingInfo中的第一个位置,所以SchedulingInfoList参数的取值范围是1到maxSI-message。虽然目前SI消息的总个数只有13个,考虑到后续的扩展,maxSI-message仍然被固定设置为32。

SchedulingInfo:指示每个SI消息的调度信息,包括周期si-Periodicity和承载的SIB类型SIB-Type。si-Periodicity的单位是无线帧号,比如rf8表示该SI的周期是8个系统帧即80ms。SIB-Type并不需要显式的包含SIB2类型,因为SIB2默认放在SchedulingInfo数组的第一个位置。如下面的图6所示,数组SchedulingInfo的第一个元素只填写了周期rf16,而没有填写sibType,因为此时默认是传输SIB2块。

si-WindowLength:所有SI消息的窗口长度,单位是ms,ms20表示SI的窗口长度是20ms。

图6是一种可能的SIB1配置。在这个配置中,eNB将会发送两个SI,分别是:第一个SI只携带SIB2,周期是160ms,窗口长度是20ms;第二个SI只携带SIB3,周期是320ms,窗口长度同样是20ms。

(图6)

 

 

Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐