7.3.4.5.6 一个SRS资源配置和使用的实例分析
本节课程视频前面几节已经分别介绍了SRS的基本概念、ResourceSet与Resource的层级关系、SRS在UL MIMO中的作用以及antenna switching与下行MIMO互易性之间的关系。本节不再停留在抽象概念而是结合一个实际UE在RRC连接建立过程中连续出现的三次SRS配置完整分析这些字段如何演进以及为什么最终能够形成2-layer UL SU-MIMO所需要的SRS基础。分析这类配置时最重要的方法不是逐字段孤立地解释而是先建立“RRC消息时间线”再区分ResourceSet级参数和Resource级参数最后把SRS配置与后续PUSCH MIMO调度联系起来。图7.3.4.5.6-1 三次RRC消息中的SRS配置演进一、先建立三个关键判断原则ResourceSet是SRS资源的集合并在ResourceSet级别定义usage、resourceType等用途和触发属性。Resource是集合中的具体SRS资源nrofSRS-Ports、transmissionComb、resourceMapping、freqDomainPosition、periodicityAndOffset等主要属于Resource级配置。后续RRC消息再次出现同一个SRS Resource ID通常首先应考虑这是对已有Resource的Add/Modify而不是自动理解成一个全新的Resource。因此分析RRCReconfiguration时必须同时追踪ResourceSet ID、Resource ID以及本次消息究竟出现了哪一个Add/Mod List。图7.3.4.5.6-2 SRS-Config、ResourceSet与Resource之间的层级关系二、第一次配置RRC Setup中的初始SRS Resource #1第一次配置出现在UE初始接入阶段的RRC Setup相关消息中。这里建立了ResourceSet #1并通过srs-ResourceIdList引用Resource #1。ResourceSet #1的usage明确为codebookResource #1则只有一个SRS port。这意味着此时已经建立了一个用于Codebook-based UL传输相关流程的基本SRS资源但它本身只有单个SRS端口。仅凭这一配置不能支持2-layer UL SU-MIMO实际PUSCH层数仍然需要结合PUSCH配置、UE能力、SRS测量以及后续DCI调度信息共同判断。第一次配置中最值得关注的字段是srs-Config setup :{srs-ResourceSetToAddModList {{srs-ResourceSetId 1,srs-ResourceIdList { 1 },resourceType aperiodic {aperiodicSRS-ResourceTrigger 1},usage codebook,p0 -110}},srs-ResourceToAddModList {{srs-ResourceId 1,nrofSRS-Ports port1,transmissionComb n2 {combOffset-n2 0,cyclicShift-n2 0},resourceMapping {startPosition 0,nrofSymbols n1,repetitionFactor n1},freqDomainPosition 4,freqDomainShift 0,freqHopping {c-SRS 0, b-SRS 0, b-hop 0},groupOrSequenceHopping neither,resourceType aperiodic { },sequenceId 0}}}其中ResourceSet #1的usagecodebook与Resource #1的nrofSRS-Portsport1分别回答两个不同的问题前者说明“这组SRS用于什么传输机制”后者说明“这个具体SRS资源有多少SRS端口”。不能把二者混为一谈。resourceTypeaperiodic以及aperiodicSRS-ResourceTrigger1还说明该ResourceSet采用非周期触发方式而不是像periodic SRS那样配置固定的periodicityAndOffset。具体触发时机由后续L1 DCI等机制决定。三、为什么第一次配置只有1个SRS端口初始接入阶段的SRS配置首先解决的是建立一个基本可用的上行sounding框架而不是一开始就把所有高阶MIMO能力全部打开。对于当前实例Resource #1只有port1因此它能够提供单端口的上行信道观测但不能仅靠这个资源形成2个同时可用的SRS空间维度。因此当后续业务阶段需要2-layer UL SU-MIMO时仅保留这个1-port Resource #1是不够的需要对SRS配置进行扩展或修改。四、第二次配置新增ResourceSet #2与Antenna Switching第二次RRC Reconfiguration出现在UE完成初始Attach/Registration之后不久。此时新增了ResourceSet #2并把usage设置为antennaSwitching。与第一次只有一个Resource不同这个ResourceSet包含两个ResourceResource #2和Resource #3。srs-Config setup :{srs-ResourceSetToAddModList {{srs-ResourceSetId 2,srs-ResourceIdList { 2, 3 },resourceType periodic { },usage antennaSwitching,p0 -110}},srs-ResourceToAddModList {{srs-ResourceId 2,nrofSRS-Ports ports2,transmissionComb n4 {combOffset-n4 0,cyclicShift-n4 0},resourceMapping {startPosition 1,nrofSymbols n1,repetitionFactor n1},freqDomainPosition 0,freqDomainShift 0,freqHopping {c-SRS 61, b-SRS 0, b-hop 0},groupOrSequenceHopping neither,resourceType periodic { periodicityAndOffset-p sl40 : 23 },sequenceId 507},{srs-ResourceId 3,nrofSRS-Ports ports2,transmissionComb n4 {combOffset-n4 0,cyclicShift-n4 0},resourceMapping {startPosition 1,nrofSymbols n1,repetitionFactor n1},freqDomainPosition 0,freqDomainShift 0,freqHopping {c-SRS 61, b-SRS 0, b-hop 0},groupOrSequenceHopping neither,resourceType periodic { periodicityAndOffset-p sl40 : 33 },sequenceId 507}}}这里最重要的观察结果有三个。第一ResourceSet #2的usage从codebook变成了antennaSwitching——注意这不是把ResourceSet #1改成antennaSwitching而是新增了一个不同用途的ResourceSet。第二Resource #2和Resource #3各自配置了ports2。第三它们的periodicityAndOffset分别为sl40:23和sl40:33因此属于两个不同的周期性SRS发送occasion。这两个Resource不能简单理解成“4个SRS端口同时工作”。更准确的理解是每个Resource在自己的发送occasion中使用2个SRS端口通过多个occasion以及UE侧的天线切换机制帮助gNB获得更多物理发射链路的空间观测。这一配置的主要价值与前一节所讲的SRS antenna switching一致在TDD等满足空间信道互易利用条件的场景中gNB可以利用这些SRS观测辅助下行Advanced/SRS-based MIMO的空间信道获取。图7.3.4.5.6-4 实际网络中的SRS配置演进与后续MIMO使用关系五、第三次配置为什么这是对Resource #1的Modify第三次RRC Reconfiguration是本实例最值得学习的地方。它没有重新出现srs-ResourceSetToAddModList也没有重新声明usage它只出现在srs-ResourceToAddModList中而且再次使用srs-ResourceId 1。因此分析时首先应该问这个ID是不是已经存在答案是Resource #1在第一次RRC Setup中已经存在。于是第三次消息的合理解释是对已有Resource #1进行资源级修改。ResourceSet #1原来的usagecodebook并没有被这条消息重新声明或替换。srs-Config setup :{srs-ResourceToAddModList {{srs-ResourceId 1,nrofSRS-Ports ports2,transmissionComb n2 {combOffset-n2 0,cyclicShift-n2 0},resourceMapping {startPosition 0,nrofSymbols n1,repetitionFactor n1},freqDomainPosition 4,freqDomainShift 0,freqHopping {c-SRS 0, b-SRS 0, b-hop 0},groupOrSequenceHopping neither,resourceType aperiodic { },sequenceId 0}}}最关键的变化就是nrofSRS-Ports从port1更新为ports2而其它主要结构参数继续保持与原Resource #1相同。也就是说这不是创建一个新的ResourceSet而是在原有Codebook SRS资源的基础上把具体SRS资源从1-port升级为2-port。图7.3.4.5.6-3 Resource #1从1-port修改为2-port的关键意义六、为什么ports2是2-layer UL SU-MIMO的重要基础对于Codebook-based UL transmissionSRS资源与PUSCH的空间传输配置存在直接关联。将Resource #1从1-port修改为2-port使UE能够使用两个SRS端口进行相应的上行空间信道 sounding从而为后续2-layer PUSCH传输提供必要的空间信道观测基础。但是需要特别强调不能把“nrofSRS-Portsports2”直接等同于“PUSCH一定发送2层”。真正一次PUSCH是否使用2层还需要结合UE能力、PUSCH的txConfig、maxRank、SRS测量结果以及DCI中的层数/预编码相关调度信息共同确定。因此更严谨的因果关系是RRC把SRS Resource #1从1-port升级到2-portgNB由SRS获得更丰富的上行空间信道观测调度器根据当前信道和UE能力决定合适的Rank/预编码DCI向UE下发本次PUSCH调度所需的空间传输信息UE最终按照本次调度发送相应层数的PUSCH。因此第三次RRC配置是“让2-layer UL SU-MIMO成为可配置、可调度状态”的重要一步而不是单独一个字段就完成了整个MIMO过程。七、三次配置放在一起看整个演进过程阶段ResourceSetusageResource核心变化RRC SetupSet #1codebook#1: port1建立初始Codebook SRSRRC Reconfig #1Set #2antennaSwitching#2/#3: ports2新增天线切换/空间sounding资源RRC Reconfig #2Set #1继承原usage#1: port1→ports2修改已有Codebook Resource #1表7.3.4.5.6-1 三次RRC消息中SRS ResourceSet/Resource的演进八、从配置到实际PUSCH还差哪些步骤实际网络中RRC配置只是建立“可以怎么发”的框架。真正某一次PUSCH采用2层SU-MIMO还需要进入动态调度阶段。一个典型的分析路径是① RRC配置SRS ResourceSet/Resource以及PUSCH的MIMO相关参数。② UE按照SRS配置发送SRSgNB进行上行空间信道测量。③ gNB调度器根据SRS测量、UE能力、当前资源和干扰情况决定Rank/预编码。④ PDCCH中的UL DCI携带本次PUSCH所需的调度与空间传输指示。⑤ UE根据DCI、RRC配置和标准规定的码本/端口映射确定实际PUSCH发送方式。⑥ gNB利用PUSCH DMRS对本次实际传输进行信道估计、均衡和解调。因此QXDM或协议日志分析时不能只看到RRC里的ports2就宣布“已经2-layer SU-MIMO”。更可靠的方法是把RRC配置、SRS实际发送、UL DCI和最终PUSCH Schedule Report放到同一条时间线上。九、这个实例中最容易产生的四个误解误解1Resource #2和Resource #3各有2个port所以就是4-layer MIMO。错误。它们属于antenna switching相关的不同SRS资源/occasion不能把端口数简单相加。误解2第三次RRC没有usage所以Resource #1的usage消失了。错误。第三次消息是在修改已有Resource #1ResourceSet #1原有的codebook用途仍然是理解该配置的重要依据。误解3nrofSRS-Portsports2就意味着PUSCH一定是2层。错误。它只是为2层空间传输提供了相应的SRS端口基础实际Rank还要经过能力、测量和调度。误解4SRS本身就是PUSCH。错误。SRS是参考信号用于gNB获得上行空间/频域信道信息PUSCH才承载实际UL数据。十、结合QXDM/协议日志的推荐分析方法当在实际抓包或QXDM日志中遇到类似配置时可以按照下面的顺序定位第一步找到SRS-Config记录所有ResourceSet ID及其usage。第二步对每个ResourceSet展开srs-ResourceIdList再去对应的srs-ResourceToAddModList查具体Resource。第三步记录每个Resource的nrofSRS-Ports、resourceType、periodicity/offset、transmissionComb以及频域位置。第四步比较后续RRCReconfiguration中是否再次出现相同Resource ID若出现判断它是Add/Modify还是Release。第五步把修改后的SRS配置与实际SRS发送日志对齐。第六步再向后追踪UL DCI以及PUSCH实际层数/预编码信息。第七步最终用PUSCH DMRS和物理层Schedule Report验证实际发送结果。这种分析方法比单独盯着某一个SRS字段可靠得多因为SRS配置描述的是“可用资源和用途”而实际MIMO传输是RRC配置、信道测量、调度和物理层执行共同形成的结果。十一、本实例的核心结论这个实例非常典型地展示了5G NR中SRS配置不是一次性固定完成的而是可以随着UE所处业务阶段和MIMO需求逐步演进。第一次RRC Setup建立ResourceSet #1 / Resource #1usagecodebookResource #1为1-port形成基本UL sounding能力。第二次RRC Reconfiguration新增ResourceSet #2usageantennaSwitching并配置Resource #2/#3各为2-port用于天线切换/空间sounding相关过程。第三次RRC Reconfiguration再次修改Resource #1把nrofSRS-Ports从port1提升到ports2而ResourceSet #1的codebook用途继续有效。最终Resource #1的2-port配置为后续2-layer UL SU-MIMO提供了必要的SRS空间观测基础真正的PUSCH 2-layer发送还需要动态调度过程共同完成。