asd199086的博客

同样，NPN id会在SIB1中广播，SIB1中的NPN id(NID以及CAG ID)图示如上，它是通过SIB1->cellAccessRelatedInfo->npn-IdentityInfoList-r16->NPN-IdentityInfo-r16->NPN-Identity-r16带给UE，NPN-Identity中有可以分为pni-npn和snpn，pni-npn对应的就是PLMN ID + CAG ID，而snpn对应的就是PLMN ID + NID。CAG ID固定长度为 32 bits。

如上图UE可以通过Msg3 PUSCH 报告是否支持Msg4 HARQ-ACK PUCCH repetiton的能力，如果UE支持Msg4 HARQ-ACK PUCCH repetition的能力，就可以通过mac subheader中的LX=1，进而使用上表中带颜色的LCID分别表示Redcap UE/eRedcap UE以及non-(e)Redcap UE ，进而告知网络侧支持Msg4 HARQ-ACK PUCCH repetition的能力。这篇就简单看下这个机制是怎么运行的，内容不多，仅供参考。

这篇是有关MBS RRC相关的一些基本内容，内容不多，但是感觉很关键，主要包括SI，MBS网络侧相关的内容，L2 协议架构，cell reselection prioritity以及MBS接收的一些内容，希望有帮助。

对上面的inter band CA场景，band A只能作为band B的 reference band，band C只能作为band D的 reference band，那band combination能力上报时，band A supportOfMultipleGroups=referenceBand1，band B中配置supportOfMultipleGroups=scellWithoutSSB1；指示为"both"的band可配置为参考band或SSB-less band。

这篇是与Scell激活相关的内容,，可以看作是Scell activation方式的一个总结。

UE在接收到CHO配置之后保持与source gNB的连接，并开始评估候选小区的CHO执行条件，如果至少一个CHO候选小区满足相应的CHO执行条件，则UE从source gNB分离，对所选候选小区应用存储的相应配置，同步到该候选小区，并通过target gNB发送RRCReconfigurationComplete消息来完成RRC切换过程，在成功完成RRC切换后，UE释放存储的CHO配置。那根据RRC层的参数配置和38.212中的有关描述，DCI format 2_9的结构及用法图示如上。

通常还需要在 VR 中对用户进行某种形式的头部和运动跟踪，以允许更新模拟的视听组件，从而确保从用户的角度来看，VR场景及声源是与用户的运动保持一致，尽可能的保持真实。用户对当前环境的观察可能是直接的，没有中间的感知、处理和渲染，也可能是间接的，用户对环境的感知通过传感器传递，并可能得到增强或处理。从工作、娱乐、沟通到重温回忆，都有不可思议的新方式。MR可以把真实世界和虚拟世界合成在一起，产生一个新的环境，在真实世界中，通过虚拟世界进一步形象化，从而产生物理和数字对象共存，实时的交互，这就是所谓的混合现实。

这篇是Broadcast的overview，正文开始。值得注意的是，对于5MBS broadcast，UE处于RRC idle/RRC connected/Inactive时，网络侧都可以通过MRB将MBS 广播数据传输到 UE。对于Broadcast涉及的RNTI有G-RNTI以及MCCH-RNTI。

如果在小区中接收处于RRC_INACTIVE状态的MBS multicast session数据的UE被通知停止对所有加入的multicast session 继续监听由 G-RNTI 寻址的 PDCCH，则 UE 就不会监听由multicast MCCH-RNTI 寻址的 PDCCH，直到收到新的group notification。要接收多播 MBS session数据，加入多播 MBS session的UE应处于CM-CONNECTED 状态以接收多播 MBS session的数据。

5G NR广播多播业务(Multicast/Broadcast Services，MBS)的发展使得多媒体内容(例如共安全和关键任务服务、V2X 应用、IPTV、直播视频、无线软件交付和 IoT 应用等)能够通过广播的传输方式传送到UE，因而用户能够随时随地观看广播电视节目或接收数据推送服务。通常传输数据是以单播形式进行，当用户人数过多时网络就会出现拥塞。这样一个cell小区有多个用户同时观看视频内容，DL速率就难以保证，如果在cell内进行广播就可以保证流畅观看体验，这算是MBS的提出背景。

在TR 21.918中可以看到cell DTX/DRX是Network energy savings(NES) for NR 的一部分，其中还包括 SSB-less SCell operation for inter-band CA等等其他内容，其相关描述如下网络节能是 5G/NR 成功的关键，由此可以减少对环境的影响（温室气体排放）并节省运营成本。RAN WG 进行了一项初步研究，其中基于基站网络能耗模型研究了时间、频率、空间和功率域中的各种技术。

下面就开始看下UE空口流程相关的内容。下面内容来自TS38.300。常规的cell switch过程要通过RRC信令进行，而LTM过程是通过L1/L2信令完成，相对于常规的方式，省去了L3的处理，因而会一定程度上较少时延。具体的说，LTM是gNB先将一些候选小区信息通过RRC信令下发给UE，UE基于这些候选小区进行L1级别的测量并将L1 MR上报给gNB，基于这些报告，gNB经由MAC CE发送给UE，进而更改UE serving cell的过程。这个过程中，网络侧。

RAN3确定了此过程的优化，其中在RRCRelease消息中包含一个新的指示符，以使UE在移至RRC INACTIVE状态后自动发起新的 RRCResumeRequest/RRCResumeRequest1，而无需paging。如果RRCRelease消息中包含suspend indication，则UE将进入RRC_INACTIVE状态，或者如果RRCRelease消息中包含resumen indication，则UE可以发起RRC resume流程以转换到RRC_CONNECTED状态。

这篇主要看下为支持XR，L2都有哪些增强。主要分3个部分：(1)additionalBS-TableAllowed和Delay Status Report(DSR) (2)UE assistance info for UL traffic information (3) PDU set discard。

这篇是R18 XR enhancement的第二篇，主要看下从NAS->L3->L2->L1针对XR都做了哪些增强。

但是，对于发送大量数据的场景，从无线容量的角度来看，包括 SDT UL/DL 传输在内的 RRC inactive状态并未得到优化，因为UE和gNB之间不会进行RRC connected mode的CQI、beam、SRS等report过程。但是，目前，当前的 3GPP R17 SDT 或其他 3GPP 指定的功能不允许在 gNB 中启动SDT过程后，在有大量待处理的 UL/DL 数据时，将UE 切换到RRC connected mode的功能。为此就有了一下3种solution。

对于驻留在NTN小区上的UE，如果UE支持 skip TN测量，并且UE已经获得自己的位置信息，如果SIB25中的coverageAreaInfoList和TN AreaIdList，当UE不在经由TN Area\idList提freq的覆盖范围内时，UE可以不执行TN freq的测量(这时候不需要考虑freq priority信息)。:指示与每个freq相关联的TN area ID的list，以帮助处于RRC_IDLE和RRC_INACTIVE状态的NTN UE的跳过TN测量。这里并没有提供点的高度。

T430 的工作机制在NTN(二) TA有讲到，serving卫星相对于地球上UE的会发生移动，因而serving 卫星辅助信息(satellite ephemeris and common TA parameters)会涉及一个有效性的问题，所以38.331中有增加一个T430用于保证UE可以持续获得有效的serving卫星的辅助信息，简单的说是通过T430控制UE获得SIB19得到有效的serving卫星辅助信息，以便保证UE获得的NTN辅助信息始终处于有效期。如果您对看过的文章有疑问；

在看R18 38.300时，发现NTN场景 增加了如下黄色字体的内容，R18 NTN支持了RACH-less HO，索性就简单看了看。NTN RACH less HO相关的描述主要在38.331,38.213和38.321中。

无论FR1 的baseband bandwidth 是否有降低，eRedCap UE的峰值数据速率被进一步降低。(1)FR1的最大带宽为 20 MHz。eRedCap UE 不支持 FR1 中带宽大于20 MHz 的场景。值得注意的是eRedCap UE不支持FR2和FR1 SCS=60kHz 的场景。(2)eRedCap UE不支持CA、MR-DC、DAPS、CPAC 和 IAB（即 eRedCap UE 不充当 IAB 节点）等相关功能。

在overview中有提到，UE可以与网络侧协商是否对能力进行临时限制，38.300中的描述如下。当MUSIM UE需要在 NW B中进行传输或接收时，NW A中处于RRC_CONNECTED状态的MUSIM UE可以将 temp UE capability restriction 或移除某个restriction的perference 告知NW A。NW A 是 NR，NW B 可以是E-UTRA 或 NR。

前几篇主要是MUSIM feature NAS 部分内容的总结，这篇开始看RRC部分相关的内容，由于RRC部分内容过长，也分成了2篇。这篇就着重看下musim gap以及RRC触发UE离开RRC Connected mode相关的内容，直入正题， 上面的内容在overview中有提到，对应的是如下38.300中的描述。处于网络 A RRC_CONNECTED 状态的 MUSIM UE可能必须要从网络 A 切换到网络 B，假如网络A是NR，网络B则可以是E-UTRA 或 NR。

网络在指示支持paging restriction时，会绑定N1 NAS signalling connection release或reject paging request的支持情况，就是在支持N1 NAS signalling connection release或reject paging request时，才能下发支持paging restriction。AMF 应存储 UE 的paging restriction，并在寻呼过程中强制执行这些限制；

更多精彩内容，请阅知识星球合集链接。该链接收录了目前知识星球所有内容，涵盖了5G相关领域的绝大多数知识点；主要以协议原文截图后进行解释讲解外加实网log对照为主，辅以星友问答等等精华内容。合集链接如下(不用登录飞书即可查看)：Docs如果您对3GPP spec阅读有困扰； 如果您对3GPP spec阅读缺乏动力； 如果您对看过的文章有疑问； 如果您有UE侧IMS，NAS ，L3，L2，L1等协议上的问题； ...... 您都可以加入星球，我们一起慢慢进步！星球简介链接：“modem帮”知识星球介绍-CSDN

如果MUSIM UE需要与另一个USIM进行通信时，则当前USIM关联系统正在进行的业务可能会中断。从网络侧角度考虑，与当前USIM关联系统主动通信时，MUSIM UE确定需要在另一个USIM关联的系统中进行paging response或MRU过程的场景，之前spec规定中，UE可以在不通知网络的情况下，自主release当前USIM系统的RRC connection，这样对于网络侧来说就可能出现一些异常，比较明显的就是无法收到当前系统下行数据或者paging，对于网络侧的资源也会造成浪费。