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

上传人:夺命阿水 文档编号:928615 上传时间:2024-01-18 格式:DOCX 页数:4 大小:69.90KB
返回 下载 相关 举报
990-基于寻呼方法的资源索引.docx_第1页
第1页 / 共4页
990-基于寻呼方法的资源索引.docx_第2页
第2页 / 共4页
990-基于寻呼方法的资源索引.docx_第3页
第3页 / 共4页
990-基于寻呼方法的资源索引.docx_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《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资源。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 在线阅读 > 生活休闲


备案号:宁ICP备20000045号-1

经营许可证:宁B2-20210002

宁公网安备 64010402000986号