990-基于寻呼方法的资源索引.docx

《990-基于寻呼方法的资源索引.docx》由会员分享，可在线阅读，更多相关《990-基于寻呼方法的资源索引.docx（4页珍藏版）》请在优知文库上搜索。

1、5G高频如何降低寻呼开销对于5G寻呼，有以下选项： 选项1：PagingDCI,然后寻呼消息，两个动作可以不连续 选项2：Paginggroupindicator触发UE反馈和PagingDCl,然后是寻呼消息 选项3：PaginggroupindicatorflPagingDCL然后是寻呼消息 选项4：PagingDCI表示使用选项1或2。对于这3个选项，至少支持选项1（寻呼调度DCI,后跟寻呼消息），从物理层角度来看，寻呼调度DCl和寻呼消息至少在同一个时隙中发送。在多波束场景中，广播传输（如用于发送寻呼消息）必须通过波束扫描进行。由于gNB侧有大量波束，广播效率非常低。多波束场景（例如使

2、用高频频段）中的寻呼开销取决于gNB必须扫描的波束方向数与gNB天线阵列数的比率。SSburstSet中SSB的数量可以视为该比率的等效项，因为gNB根据其必须扫描的方向数和天线阵列的数量来决定SSB的数量。因此，使用SSB的数量，而不是波束方向的数量和天线阵列的数量来分析下行寻呼开销。表1显示了在分析中使用的参数。表1:各类参数参数解释每SSburstSet中SSB数SSB数表示gNB用于传输SYNC和寻呼信号的下行TX波束数与gNB天线阵列数的比率。UEIDSize(U)寻呼消息包括UEID。假设有40位。PagingRate(P)每秒寻呼的UE数量数Spectralefficiency(

3、E)以bps/Hz表示。在此分析中，重点关注小区边缘的频谱效率CarrierBandwidth(B)用HZ表示基于上述参数，下行寻呼开销可以计算如下:DL Paging Overhead =NumberofSSBlocksPagingRateUEIDSizeSpectralEfficiencyCarrierBandwidth在LTE中，每个SSburstSet仅包含一个SSB。然而，在毫米波段（MMW）中，每个SSburstSet可以有多达64个SSB,即时在FRI中，也有8个SSB。另一方面，LTE具有20MHZ带宽，而毫米波的载波可以具有100MHZ带宽。此外，LTE的小区边缘频谱效率为O

4、JbPS/Hz。模拟结果表明，对于NR,能够在小区边缘实现0.225bpsHzo基于这些数字，LTE和MMN的下行寻呼开销如图1所示图2：4G和5G毫米波网络之间寻呼开销对比图2比较了LTE和MMW对寻呼的容量需求。LTE以每秒6400个UE的最大寻呼速率消耗大约13%的下行容量。在毫米波网络中，对于相同的寻呼速率，下行容量需求明显更高，对于64个SSB,它可以达到下行容量的73%。这比LTE网络中寻呼的相应下行容量需求高5-6倍。可以通过压缩寻呼记录来减小寻呼广播的大小。这种压缩可以基于应用于UEID的hash,例如，包含在寻呼记录中的S-TMSI或IMSI。它还可以基于UEID的截断。它可

5、以基于将UEID替换为groupID,假设UE之前已经与这样的组相关联。其他压缩方法也是可能的。UEH）的压缩形式称为寻呼索引。寻呼广播仅包含寻呼索引。压缩后，gNB广播X位的寻呼索引，而不是（例如）40位长度的UETD,这将下行寻呼开销减少了40/X。例如，如果X=14位，则广播开销减少了近3倍。为了在广播寻呼中获得足够大的资源增益，需要应用有损压缩。这种有损压缩可能导致虚假寻呼警报，因为寻呼索引可能映射到多个UEid,其中只有一个或一个子集应该被寻呼。在这里，由于寻呼索引的多对一映射，会出现错误警报。换句话说，通过假警报，我们关注UE从gNB正确接收寻呼索引位的场景；假设该索引是针对其自身

6、的，因为映射函数将其UEID映射到由gNB传输的同一寻呼索引；但寻呼索引用于另一个UE。通过适当选择索引大小，可以减少基于索引的寻呼机制引起的错误寻呼警报。例如，LTE在每个寻呼时刻最多发送16条寻呼消息，寻呼时刻每IOmS发生四次。对于X位的索引大小，接收错误警报的概率约为16X2-X。假设X=14位，错误警报的概率小于103,这将在100OX320ms=5min的时间内转化为一个错误警报。这是最坏的情况。在更现实的场景中，误报率会低得多。UEIgNBDerivingpagingindexlistfrompaging、recordIiSt,Broadcastofpagingindexlist

7、(mayIndudecompressionindication)(mayindudeUE-IDtypeindication)卜PagingalertRACKProcedureM-RRCConnectionRequestIncludesPaglng-ResponseIndfcatlonandUE-IDIfPaging-ResponseIndication,compareUE-ID-、toPagingrecordIiStJRRCConnectIonSetup-RRCConnectjonCompIete-Match*-zRRCConnectIonReject(mayIncludereasonforr

8、ejection)HNomatCh一i图3:在RRC连接建立过程中，具有警报验证的基于索引的寻呼当UE收到基于索引的寻呼警报时，它尝试建立到gNB的RRC连接，以检索网络上等待它的数据。下面提供了2中解决寻呼警报的方法。由于UE在RRC连接请求中包括其UE-ID,因此网络可以验证该UE-TD是否与寻呼记录列表上的条目匹配。如果发现这种匹配，则网络接受RRC连接请求。因此，不会为真正的警报引入额外的开销。在相反的情况下，如果没有找到匹配项，则网络会得出结论，认为发生了错误的寻呼警报，因此拒绝RRC连接请求。RRC连接拒绝消息可能包括拒绝的原因。与不成功的连接建立尝试相关的开销与错误寻呼警报概率一

9、样小。这可以通过应用于寻呼消息的压缩程度来设置，即如上所述的索引大小。网络应仅对响应寻呼广播而发生的连接建立尝试应用匹配操作。为了区分基于寻呼的连接建立尝试与其他性质的尝试，UE在请求建立连接时包括寻呼响应指示。仅当包含该指示时，gNB才应用匹配操作。在该方法中，基于索引的寻呼警报可以通过寻呼消息的PDSCH传输，该消息之前是寻呼调度DCI。与当前LTE的寻呼机制相比，这仍将减少寻呼开销，因为每个UE的寻呼信息将仅包含大小小于40位的寻呼索引。图4：在随机接入过程中，具有警报验证的基于索引的寻呼机制在第二种机制中，基于索引的寻呼验证嵌入到随机接入过程中。接收警报的UE通过在随机接入信道上发送前

10、导来启动随机接入过程。它根据到导致寻呼警报的索引的映射来选择前导码。该映射可以由网络预先配置。通过这种方式，gNB可以找到向UE发出警报的相关寻呼索引。在寻呼广播之后接收前导码的gNB评估前导码是否匹配到之前广播的任何寻呼索引的映射。如果找到这样的匹配，gNB在随机访问响应（MSG2）中包括与该索引相关的寻呼记录。这允许UE验证寻呼警报是真是假。在寻呼警报为假的情况下，UE将随机接入终止指示包括在寻呼过程的MSG3中。否则，它将以常规方式继续寻呼过程和RRC连接建立，以检索网络上等待它的数据。注意，通过Msg3的错误警报解决需要从寻呼索引映射到MSgl前导码。gNB需要事先将这些前导传输给UE,以便UE可以将寻呼索引映射到适当的MSgl资源。