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