asd199086的博客

资源映射的目的就是将序列结合port的复用情况，映射到具体的RE上。• 增强型 DMRS configuration type 1：1 个 FL DMRS 符号最多 8 个，2 个 FL DMRS 符号最多 16 个。• DMRS configuration type 1：1 个前载 (FL) DMRS 符号最多 4 个，2 个 FL DMRS 符号最多 8 个。• DMRS configuration type 2：1 个 FL DMRS 符号最多 6 个，2 个 FL DMRS 符号最多 12 个。

这篇是R18 XR的最后一部分，主要是L1方面的增强。这部分增强大概的背景如下。一些 XR 应用（例如增强现实）不仅在 DL 方向需要高数据速率，在 UL 方向也需要高数据速率。如果应用需要在 UL 方向传输视频流量，则 UL 中支持的 XR 用户数量可能非常有限。因此，增加有限的时间以成功传输和接收数据非常重要。调度延迟的增加会导致在数据包延迟超时前的数据包成功传输的剩余时间减少，从而导致支持的UE数量减少。减少调度延迟的一个可能的解决方案是配置授权 (CG)。

根据3GPP的定义non-RedCap XR 可穿戴 UE 的默认值为4Rx(对于强制使用4Rx 的频段)，但是对于有些XR UE(例如XR眼镜)，由于体积小要戴在头上，使用时，仅由耳朵/后方和鼻梁支撑，导致外形尺寸受限，可用于 Rx 的体积有限，所以就有了2Rx XR UE。至于为什么有个前缀non-Redcap，应该也很好理解，XR UE需要大带宽和电量的支持，用Redcap的那套参数显然是不够的。 上图是XR眼镜的结构以及一种可能的天线位置。比如apple，三星和meta等公司可能就会退出这种形态的

RRC层完成判断后 ，在MAC层初始化定位SRS传输时，还是要满足一定条件才会进行的，比如要SRS的TA要首先是有效的，还要满足功控并进行SRS与PUSCH或PUCCH冲突的一些条件判断后，底层才会进行定位SRS的传输。除此之外，还有跳频和SRS带宽聚合的内容。这里就先看下RRC INACTIVE下SRS TA验证的规定。这里涉及的问题就是要先计算DL pathloss参考RSRP，这部分在38.331中有规定，如下。

NPN是为非公共用途部署的5GS。NPN 可以是：(1)独立非公共网络 (SNPN)，即由NPN运营商运营且不依赖PLMN提供的网络功能；(2)公共网络集成 NPN (PNI-NPN)，即在PLMN支持下部署的非公共网络。值得注意的是NPN 和 PLMN 可以共享 NG-RAN。上篇看了PNI-NPN，这篇就看下SNPN，这部分参考TS 38.331 38.300，38.304，23.501，23.502，24.501等等，这里先从基础架构看起。

这里我们开始看RRC inactive状态下的Positioning相关内容，SRS for positioning最早是在R16引入的，而positioning for RRC inactive则是在R17才引入的。由于positioning的相关过于庞大，下面只摘出了Positioning for RRC inactive的内容，后续有时间再展开其余部分。先看下各个Release都做了哪些方面的工作。下面内容摘自TR 21.917 和21.918。

Rel-17 指定MO-SDT允许针对UL方向的数据包进行小数据包传输。对于DL，MT-SDT(即DL触发的小数据)可带来类似的好处，即 通过不转换到 RRC_CONNECTED来减少信令开销和UE功耗，并通过允许快速传输(小而少见的)数据包(例如用于定位)来减少延迟。在R17中，NR_SmallData_INACTIVE的工作项允许在UE保持在RRC_INACTIVE状态时传输小信令或数据包。这些R17的增强功能仅支持MO SDT过程。R18 就引入了MT-SDT。

始评估候选小区的CHO执行条件，如果至少一个CHO候选小区满足相应的CHO执行条件，则UE从源gNB分离，对所选候选小区应用存储的相应配置，同步到该候选小区，并通过目标gNB发送RRCReconfigurationComplete消息来完成RRC切换过程，在成功完成RRC切换后，UE释放存储的CHO配置。对于ATG场景，essential SI除了MIB和SIB1外，还包括SIB22，只不过ATG UE无法获取SIB22时，UE的下一步操作取决于UE实现，比如可以重选到其他cell做喜爱一部接入尝试。

这里简单看下多播DRX的内容。对于MBS多播，RRC可配置 MAC entity使其具备per G-RNTI 或per G-CS-RNTI DRX 功能，从而控制 UE 对 MAC entity的G-RNTI和G-CS-RNTI 的 PDCCH 监听活动。当处于 RRC_CONNECTED 状态时，如果为 G-RNTI 或 G-CS-RNTI 配置了多播DRX，则允许 MAC entity使用多播 DRX 操作不连续地监听此G-RNTI 或 G-CS-RNTI 的 PDCCH；

当处于RRC_IDLE或RRC_INACTIVE或RRC_CONNECTED 状态时，如果为 G-RNTI 配置了broadcast DRX，则允许MAC entity使用broadcast DRX 操作不连续地监听此G-RNTI的PDCCH；此 G-RNTI 的 drx-onDurationTimerPTM 或 drx-InactivityTimerPTM 正在运行的时间,也就是。long DRX周期drx-LongCycle-PTM和drx-StartOffset-PTM定义DRX周期开始的子帧。

与上行符号不重叠的MCCH消息的PDCCH监控时机（根据tdd-UL-DL-ConfigurationCommon确定）在multicast MCCH传输窗口中从1开始依次编号，multicast MCCH传输窗口中第[x×N+K]个multicast MCCH消息的PDCCH监控时机对应第K个传输的SSB，其中x = 0，1，…根据测量的好的beam方向对应的SSB索引，找到对应的PDCCH时机来接收multicast MCCH的调度信息，进而接收multicast MCCH信令。其中x=0,1, …

这篇看下RACH-less LTM cell switch。相比于RACH-based LTM，RACH-less LTM在进行LTM cell switch之前就要先知道target cell的TA信息，进而才能进行RACH-less过程，这里一般可以通过UE自行测量或者通过RA过程获取，而这里的RA一般是通过PDCCH order过程触发。

下面是38.300中有关LTM cell switch的两张图。LTM的主要过程在上篇已经提到过，这里我们以上面2张图为例，看下每一步的具体规定。这篇先看下RACH-based LTM过程。1 LTM candidate configuration 网络会使用LTM-Config IE中给UE配置一个或多个LTM候选信息。在NR-DC中，UE可能会收到两个独立的ltm-Config：(1)与MCG关联的ltm-Config，包含在通过SRB1接收的RR

下面就开始看下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的过程。这个过程中，网络侧。

根据测量的好的beam方向对应的SSB索引，找到对应的PDCCH时机来接收MCCH的调度信息，进而接收MCCH信令。这里对应的就是DCI format 4_0的MCCH change notification field，MSB =1代表启用新的MBS services，LSB value设置为"1"时，表示MCCH信息的修改(也就是除开始 new MBS services情况外的其他情况)，例如修改正在进行的MBS session的配置、停止相应MBS session以及邻区cell 信息的修改。

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

这篇是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的提出背景。

这篇我们来看下PNI-NPN，之前都没有提到NPN引入的背景，这里就简单看下。NPN引入的背景如上，就不细说了，贴在这里，确实很简单的看了下。紧接着就来看下规范上的内容。相比于SNPN，PNI-NPN是PLMN提供的NPN，内容也要少很多，下面的内容参考38.300，38.331 ，38.304，23.501，38.413等等。先看一些综合性质的内容。PNI-NPN是通过PLMN提供的NPN，例如通过专用DNN或通过为NPN分配的一个(或多个)网络切片实例，也就是现有的网络切片功能完全适用。

在正式开始NPN内容之前，有必要看下R16-R18 对于NPN都有哪些方面的规定，以便后续查看。

同样，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的能力。这篇就简单看下这个机制是怎么运行的，内容不多，仅供参考。

对上面的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的结构及用法图示如上。

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

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都做了哪些增强。

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

但是，对于发送大量数据的场景，从无线容量的角度来看，包括 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