NR/5G - On demand SI

05/25 13:40
阅读数 199

 

NR中系统消息如MIB - 可用于无线帧同步等,SIB1 - 小区物理信道公共配置等,是驻留一个小区所必需获得的信息,这类系统信息小区是进行周期性广播。

 

在SI的配置中,系统消息分为BroadCasting和non-BroadCasting,BroadCasting类系统消息基站也是周期性进行广播的,而non-BroadCasting类系统消息则是通过一种on-demand的方式,即如果需要读取这类系统消息,那么UE需要先发送请求给基站,基站响应UE之后,再下发系统消息。

 

 

为什么引入这种on-demand的方式?

 

NR中引入了Beam的概念,为了支持小区的全覆盖,基站需要在不同的Slot对不同方向的Beam分别广播系统消息,在NR/5G - 广播数据SSB/SIB1/SI/Paging调度小总结文中可以看到这种Beam Sweep的下发方式。

                                                                                          Beam Sweep

 

在中低频段,Beam的个数为4/8,但是在高频时候,Beam的个数最大为64,那么可以看到,如果采用非广播的方式,可以节省基站的功耗。有预测,到2026年,5G或许会使网络能耗添加150%至170%,增幅最大的是宏基站和数据中心。

 

另外一方面,如果都采用广播方式,则还需要将PDCCH资源预留以保证系统消息的调度,这些资源不能用于其他PDSCH的调度。

 

UE是怎么请求读取non-BroadCasting系统消息?

 

有两种方式。

 

方式一是通过给系统消息(SI)分配指定的preamble index,UE通过发送PRACH来请求基站下发系统消息,这种基站通过下发MSG2来响应UE,只需要MSG2中的RAPID与UE发送的preamble index一致,则认为基站接收到了UE的请求。

 

 

  

使用方式一,使用的是非竞争性随机接入,不会存在RACH冲突,需要为on demand SI请求预留RACH资源。

 

方式二是不指定SI对应的preamble index,这种配置下,UE还是通过竞争性随机接入方式来请求,在RAR调度的MSG3中携带需要请求读取的系统消息类型,在随机接入竞争解决成功之后读取系统消息。

 

 

 

 

基站下发SI的方式可以是广播,在所有的beam方向下发,由于preamble信息中包含了UE期望下行接收的beam方向,基站应该也可以只在UE的beam方向上下发。通过38.311中的描述,UE还是按照SI的配置方式,协议中并未看到对于基站实现的明确描述,在周期性时间点上的SI-Window内读取系统消息。SI的时间位置计算可以参考NR SI Message

 

在参考文章1中还介绍了一种Listen Before Request(LBR)机制。UE尝试先在最近一个SI周期的SI-Window内进行读取non-Broadcasting SI,如果未读取到则再通过SI-Request请求基站下发non-Broadcasting SI。

 

参考文章

1. 《5G On-Demand SI Acquisition Framework and Performance Evaluation》

https://www.researchgate.net/publication/337177632_5G_On-Demand_SI_Acquisition_Framework_and_Performance_Evaluation

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部