本文已参加「新人创造礼」活动，一同开启创造之路。
群里看到一个疑问，LTE SIB24是否只在衔接态下下发？
LTE终端在IDLE态下装备的NR邻区信息在SIB24中装备，现在遇到的现象是SIB24都是终端在衔接态下读取到的，而导致以为SIB24是仅在衔接态下基站才下发。根据个人的经历来看，或许大致进程是下面这样的，因为LTE是在读取到SIB2后确认该小区能够驻留，后续就建议随机接入进程，随机接入成功，进入衔接态，而SIB24的周期或许装备较大，UE在进入衔接态之后才遇到SIB24的下发时间点。
当然有下面的疑问，假如Log进程中有5G小区重选到4G小区的场景的话，这个时分是每次都需求进行方位区更新吗？例如在同一个模式内的小区重选，假如方位区没有发生变化，则不需求建议方位区更新进程，不需求进入衔接态。
别的，对于实现来说，对于SIB1中装备的其他体系音讯，例如邻区装备，也仅应用在UE处于IDLE态，假如进入衔接态之后的邻区装备是经过RRCReconfiguration装备的，是否会有进入衔接态后就停止读取SIB1中指示的其他体系音讯，即便当该体系音讯UE还未读取获得。
群里看到一个问题，“uciOnPusch支撑的基础上，SR和HARQ都是放到PUSCH上，这个情况下SR会这么上报上来？”
首先，这里的SR肯定是指Positive SR，对于Positive SR和Negative SR两个概念，经常会有同事不理解这两个概念，其实在文章NR – Scheduling Request中有描述过。
“协议描述中有Positive SR和Negative SR的概念，UE并不是一直有发送SR恳求的需求，对于Positive SR即UE有SR恳求发送，需求物理层发送SR/PUCCH，而对于无SR发送恳求的UE，在SR资源的时间点，则该SR为Negative SR。”
其次，SR的目的是向网络恳求上行调度资源。恳求上行调度的别的一种方法是MAC上报BSR恳求。在sharetechnote（www.sharetechnote.com/html/Handbo…
BSR is a kind ofMAC CEfrom UE to Network carrying the information on how much data is in UE buffer to be sent out. Putting it another way, it is a kind of MAC layer message from UE to Network (eNodeB)saying “I have something to transmit, would you give me a Grant to send this data ?” Then Network would allocate the bare minimum amount of UL Grant (Resources for PUSCH) if the resource is available. With this mechanism, network can optimize UL resources based on following logics.
- Allocate UL resources (UL Grant) only when UE has something to transmit
- Avoid allocating too much UL resources (more than what UE needs) which lead to waste of resources.
SR只能简单地向网络请求上行调度，而BSR除了向网络请求调度外，还能够告知网络需求多大的UL Grant。
所以Positive SR和PUSCH信道在同一个Slot上发送时分的处理规则如下。
- 假如PUSCH不包括UL-SCH，即调度PUSCH的DCI仅用于发送非周期CSI，不包括层二的数据（BSR是层二组的MAC CE），则此时SR的优先级更高，不发送PUSCH。
- 假如PUSCH包括UL-SCH，则丢掉SR，不需求在经过SR来恳求上行调度，经过BSR也能够请求上行调度。
