《992-如何降低5G寻呼开销？.docx》由会员分享，可在线阅读，更多相关《992-如何降低5G寻呼开销？.docx（4页珍藏版）》请在第壹文秘上搜索。
1、如何降低5G寻呼开销？对于5G寻呼，有以下选项：选项LPagingDCI,然后寻呼消息，两个动作可以不连续 选项2：Paginggroupindicator触发UE反馈和PagingDCI,然后是寻呼消息 选项3：Paginggroupindicator和PagingDCI,然后是寻呼消息 选项4：PagingDCI表示使用选项1或2。在上述NR寻呼机制的候选方案中，选项1是已经商定的基线解决方案，类似于LTE的基线解决方案。选项2、3和4是选项1之上的可能增强，在基线寻呼过程之前引入寻呼指示过程。paginggroupindicator可能是DCl信令，或一些其他现有或新的物理层信号。选项2
2、和4在发送groupindicator后还需要UE反馈，例如作为波束报告,以帮助gNB选择合适的波束进行寻呼，以减少寻呼的波束扫描开销。可以减少的开销在很大程度上取决于系统中使用的波束数量和要在波束之间寻呼的Ue的分布。如果仅部署一个或两个波束，例如在低于6GHz的系统中，则预期增益很小。如果寻呼UE均匀分布在波束之间，最终承载寻呼DCI和消息的波束数量将永远不会减少。此外，paginggroupindicator本身应该在所有波束之间扫描，这不可避免地增加了上述场景中的下行开销。因此，波束报告机制仅在使用了大量波束的一些特殊场景中可以减少波束扫描开销，但是由于某些原因，所有寻呼UE都聚集在这
3、些波束中的少数。这种情况似乎是不寻常的。另一种可能的场景是在一个小区中寻呼，该小区只有很少的UE。然而，在这种情况下，寻呼信号开销是否是一个重要问题值得怀疑，尤其是与下面要讨论的其他问题相比。另一个问题是，额外的波束报告机制需要来自空闲和非活动UE的上行传输，其中无法进行适当的时间对齐。重用PRACH似乎是一个简单的解决方案。然而，如果用于波束报告的PRACH资源与用于随机接入的PRACH资源多路复用，则gNB可能无法区分它们。如果分配的专用前导码类似于无竞争情况，则随机接入冲突可能不可避免地增加。如果为波束报告目的分配了专用PRAeH资源，则上行PRACH开销可能会显著增加，因为需要为不同的
4、接收波束保留多个PRACH资源。此外，beam报告可能不够可靠。例如，由于UE阻塞或开环功控不足，报告可能不幸失败。因此，gNB可能错误地假设在该特定波束下没有要寻呼的UE,从而导致更高的寻呼失败率。如果采用类似于功率斜坡的机制，则端到端延迟将显著增加，这是不可取的。另一方面，除了寻呼信令开销问题外，UE功耗也是应该考虑的一个重要方面。额外的波束报告以及潜在的功率斜坡程序显著增加了UE的功耗。一旦同一组UE接收到groupindicator,所有UE都必须发送波束报告信号，而在大多数情况下，只有少数UE或甚至没有UE最终被寻呼。不幸的是，从UE的角度来看，这只是浪费能源。另一方面，为了节能，可
5、以在寻呼Del之前引入groupwakeupindicator（即选项3）o当检测到特定的wakeupindicator时，UE只需要监视后续寻呼时机。这样的唤醒机制可以实现寻呼监测的提前终止，因此对于UE来说，消除寻呼监测中的大量不必要功耗是可取的。对于该Wakeupindicator,应考虑一些细节问题。首先,要设计好groupwakeupindicator的信道结构。一种选择是引入通用DCIo虽然该选项可能对规范的影响较小，但盲检和解码过程的复杂性可能高于可接受水平,并最终限制了可实现的节能增益。另一种选择是引入新的物理层信号，即指示序列。预计该信号的检测和解码的复杂度应尽可能低，同时努
6、力实现足够低的漏检率和误报率。其次，还应考虑长时间DRX睡眠后的时间和频率同步。希望利用SSB在空闲状态下实现时间/频率同步。然而，这也意味着UE需要在DRX周期中频繁唤醒以与SSB同步，这导致空闲状态下的大量功耗。此外，SSB以5msburstSet传输，产生了长的同步接收时间。因此，从UE节能的角度来看，在从DRX唤醒后，需要有额外的信号来辅助同步。始终领先于寻呼场合的groupwakeupindicator序列似乎是实现此目的的完美选择。除了基本的寻呼框架外，还有一些细节问题需要解决。首先，在LTE中，定义了指示可用于寻呼场合的子帧子集的固定子帧模式。它使UE能够在从DRX唤醒时仅监视预
7、定义位置中用于寻呼指示的子帧的子集，这有利于UE降低功耗。尽管这种机制有利于NR,但应注意，规范中预定义的子帧模式不向前兼容，甚至不可能用于TDD部署，因为时隙的传输方向可以半静态或动态地改变。因此，应研究向IJE通知可能发生寻呼的可用时域资源（例如时隙或符号）的机制。假设支持更高层信令来为NR进行上下行传输方向的半静态分配（例如位图模式），那么在更高层信令中将寻呼消息的模式分配放在一起似乎很自然。另一种解决方案可能是，与SFI类似，从组公共PDCCH发送的指示宣布可以将时隙用于寻呼。然而，它因此要求UE在DRX周期中监测寻呼之前定期获取组公共PDCCHo这种额外的功耗是不可取的。此外，在LT
8、E中，用于寻呼的子帧模式可以是一到四个子帧。考虑到NR支持灵活的numerology,在一个无线帧中最多四次寻呼可能并不总是满足各种部署下的要求。因此，寻呼次数也应该是可配置的。其次，应该定义调度寻呼的DCI。重用LTE行为是合理的，即特定的P-RNTI加扰表示寻呼指示的DCI的CRC,而实际寻呼消息在该DCI分配的PDSCH中传输。如果寻呼仅用于通知目的，则它只能是大约8位，甚至比调度DCl小得多。LTEeMTC中的直接指示信息表示，已经支持在LTE的DCI中携带该信息。NR中也可以合理支持这种特性，以消除寻呼的PDSCH开销，并避免寻呼的PDSCH的波束扫描。此外，处于RRJCoNNECT
9、ED状态的UE可以直接从寻呼DCI感知系统信息修改或ETWCM的通知，而无需解码寻呼消息的PDSCH0在多波束部署中，己经同意支持波束扫描进行寻呼传输。寻呼DCI的共享CORESET可能只是简单地共享相同的RMSI的CORESETo问题是，为RMSI配置的协复位可能没有足够的空间用于其他传输，特别是在小信道带宽下。考虑到必要的寻呼配置，如DRX周期、时域资源等。在RMSl中广播，那么用于寻呼的RMSl配置自然也是RMSl中寻呼配置的一部分。注意，通过这种方式，仍然可以配置UE以在RMSI的CORESET中监视寻呼DCI,这对于某些情况很有用，比如smallcell,其中信道质量足够好。在这种情
10、况下，不需要公共DCI的高聚合级别，因此为公共DCI（例如RMSK寻呼、RAR等）共享相同的CORESET。在一个宽载波内可以传输多个SSBo空闲和非活动模式ue可能只能集中在与SSB传输相关的频率子带上，并从系统的角度监视限制在该频率子带或所述BWP内的CORESETo然而，值得注意的是，网络并不知道UE所占用的实际BWP；因此，网络必须将寻呼消息广播到所有包含SSB传输的BWP,并进一步增加寻呼信令开销的成本。当然，这个机制也可以得到增强。假设UE只集中在一个BWP,到该UE的寻呼消息目标应该只在该特定BWP传输。这种增强代替在宽载波的每个BWP广播寻呼消息，可以与配置的BWP的数量成比例
11、减少寻呼信令开销。图1:将UE的PO分发到不同的BWP图1说明了一个例子，其中配置了两个PB（BWP#2和#5）。一些UE（UE1、UE2）在BWP#5上醒来以监视它们的寻呼消息，而其他UE（UE3、UE4）则停留在另一个BWP（即BWP#2）上以监视它们的寻呼消息。UE根据从其IMSl派生出的哈希函数来选择PB。因此，网络知道UE驻留上的潜在BWP,并能够将为这些UE专用的寻呼消息发送到驻留上的特定BWPo这种增强还可以增加使用现有的寻呼消息格式为每个运营商寻呼的总量。可以寻呼的UE总数与配置的PB数量成比例增加。为了避免寻呼传输的波束扫描，SFN传输可以降低寻呼的开销，并可能在小区边缘获得
12、更好的性能。然而，仍有几个问题需要考虑。时频跟踪长时间DRX睡眠后的时间和频率同步是不可避免的，SSB可以作为时间和频率参考。如果以SFN的方式传输寻呼，则时间和频率跟踪参考信号也应以这种方式传输。然而,SFN传输对于SSB是不可行的，其中PSS、SSS、PBCH和PBCH-DMRS以特定于小区的方式初始化或加扰，因此UE不能假定SSB和寻呼之间的QCL。在这种情况下，在寻呼接收前与NR-SS同步不能帮助唤醒UE,这可能会导致寻呼DCI和寻呼消息的性能损失。寻呼CORESET如果将SFN用于寻呼传输，则该SFN传输自然也用于寻呼DCI；否则，SFN增益将不可避免地受到限制.DMRS设计在LTE
13、中，PMCH以SFN的方式传输，除了小区特定的参考信号（CRS）外，还专门为PMCH设计了MBSFN参考信号（即Port4）。MBSFNRS与CRS的不同之处在于RS模式和RS序列初始化两个方面。同样，在NR中，这两个方面可能仍然需要考虑，具体讨论如下。首先，如果从多个传输点传输相同的信号，与单点传输信道相比，该SFN信道的延迟扩展会很大，从而降低频域的信道相关性。此外，频率偏移是独立的，这将降低时域上的信道相关性，似乎很难校准SFN区域内的频率偏移。因此，在频域和时域的SFN-RS应该足够密集，以方便更准确的信道估计。从RS密度的角度来看，TypeIPDSCHDMRS模式，其设计适用于1/2密度的广播和多播传输，似乎适用于SFN传输。然而，PDCCHDMRS的密度仅为1/4.其次，SFN-RS序列应该用N学而不是cellID进行初始化，以确保从不同的TP传输的相同的信号/RS。CP长度/pagingnumerologySFN信道会导致较大的延迟扩展，如果不能覆盖延迟扩展，正常的CP长度可能不够。与LTEPMeH类似，扩展的CP可能需要用于SFN传输。扩展CP仅定义为60kHzSCS。基于当前的协议，使用扩展的CP来传输寻呼似乎是不可行的。寻呼物理通道与DMRS序列设计中考虑的类似，寻呼DCI和寻呼消息不应该与cellID相关进行加扰，确保从多个TP传输的相同信号。
