5G高频如何降低寻呼开销
对于5G寻呼，有以下选项：
选项1：Paging DCI，然后寻呼消息，两个动作可以不连续
选项2：Paging group indicator触发UE反馈和Paging DCI，然后是寻呼消息
选项3：Paging group indicator和Paging DCI，然后是寻呼消息
选项4：Paging DCI表示使用选项1或2。
对于这3个选项，至少支持选项1（寻呼调度DCI，后跟寻呼消息），从物理层角度来看，寻呼调度DCI和寻呼消息至少在同一个时隙中发送。
在多波束场景中，广播传输（如用于发送寻呼消息）必须通过波束扫描进行。由于gNB侧有大量波束，广播效率非常低。多波束场景（例如使用高频频段）中的寻呼开销取决于gNB必须扫描的波束方向数与gNB天线阵列数的比率。SS burst set中SSB的数量可以视为该比率的等效项，因为gNB根据其必须扫描的方向数和天线阵列的数量来决定SSB的数量。因此，使用SSB的数量，而不是波束方向的数量和天线阵列的数量来分析下行寻呼开销。表1显示了在分析中使用的参数。
在LTE中，每个SS burst set仅包含一个SSB。然而，在毫米波段（MMW）中，每个SS burst set可以有多达64个SSB，即时在FR1中，也有8个SSB。
另一方面，LTE具有20 MHz带宽，而毫米波的载波可以具有100 MHz带宽。此外，LTE的小区边缘频谱效率为0.1bps/Hz。模拟结果表明，对于NR，能够在小区边缘实现0.225 bps/Hz。基于这些数字，LTE和MMW的下行寻呼开销如图1所示
图2比较了LTE和MMW对寻呼的容量需求。LTE以每秒6400个UE的最大寻呼速率消耗大约13%的下行容量。在毫米波网络中，对于相同的寻呼速率，下行容量需求明显更高，对于64个SSB，它可以达到下行容量的73%。这比LTE网络中寻呼的相应下行容量需求高5-6倍。
可以通过压缩寻呼记录来减小寻呼广播的大小。这种压缩可以基于应用于UE ID的hash，例如，包含在寻呼记录中的S-TMSI或IMSI。它还可以基于UE ID的截断。它可以基于将UE ID替换为group ID，假设UE之前已经与这样的组相关联。其他压缩方法也是可能的。UE ID的压缩形式称为寻呼索引。寻呼广播仅包含寻呼索引。
压缩后，gNB广播X位的寻呼索引，而不是（例如）40位长度的UE-ID，这将下行寻呼开销减少了40/X。例如，如果X=14位，则广播开销减少了近3倍。
为了在广播寻呼中获得足够大的资源增益，需要应用有损压缩。这种有损压缩可能导致虚假寻呼警报，因为寻呼索引可能映射到多个UE id，其中只有一个或一个子集应该被寻呼。在这里，由于寻呼索引的多对一映射，会出现错误警报。换句话说，通过假警报，我们关注UE从gNB正确接收寻呼索引位的场景；假设该索引是针对其自身的，因为映射函数将其UE ID映射到由gNB传输的同一寻呼索引；但寻呼索引用于另一个UE。
通过适当选择索引大小，可以减少基于索引的寻呼机制引起的错误寻呼警报。例如，LTE在每个寻呼时刻最多发送16条寻呼消息，寻呼时刻每10ms发生四次。对于X位的索引大小，接收错误警报的概率约为16×2-X。假设X=14位，错误警报的概率小于10-3，这将在1000 X 320ms=5½ min的时间内转化为一个错误警报。这是最坏的情况。在更现实的场景中，误报率会低得多。
当UE收到基于索引的寻呼警报时，它尝试建立到gNB的RRC连接，以检索网络上等待它的数据。
下面提供了2中解决寻呼警报的方法。
由于UE在RRC连接请求中包括其UE-ID，因此网络可以验证该UE-ID是否与寻呼记录列表上的条目匹配。如果发现这种匹配，则网络接受RRC连接请求。因此，不会为真正的警报引入额外的开销。
在相反的情况下，如果没有找到匹配项，则网络会得出结论，认为发生了错误的寻呼警报，因此拒绝RRC连接请求。RRC连接拒绝消息可能包括拒绝的原因。与不成功的连接建立尝试相关的开销与错误寻呼警报概率一样小。这可以通过应用于寻呼消息的压缩程度来设置，即如上所述的索引大小。
网络应仅对响应寻呼广播而发生的连接建立尝试应用匹配操作。为了区分基于寻呼的连接建立尝试与其他性质的尝试，UE在请求建立连接时包括寻呼响应指示。仅当包含该指示时，gNB才应用匹配操作。
在该方法中，基于索引的寻呼警报可以通过寻呼消息的PDSCH传输，该消息之前是寻呼调度DCI。与当前LTE的寻呼机制相比，这仍将减少寻呼开销，因为每个UE的寻呼信息将仅包含大小小于40位的寻呼索引。
在第二种机制中，基于索引的寻呼验证嵌入到随机接入过程中。接收警报的UE通过在随机接入信道上发送前导来启动随机接入过程。它根据到导致寻呼警报的索引的映射来选择前导码。该映射可以由网络预先配置。通过这种方式，gNB可以找到向UE发出警报的相关寻呼索引。
在寻呼广播之后接收前导码的gNB评估前导码是否匹配到之前广播的任何寻呼索引的映射。如果找到这样的匹配，gNB在随机访问响应（MSG 2）中包括与该索引相关的寻呼记录。这允许UE验证寻呼警报是真是假。在寻呼警报为假的情况下，UE将随机接入终止指示包括在寻呼过程的MSG 3中。否则，它将以常规方式继续寻呼过程和RRC连接建立，以检索网络上等待它的数据。
注意，通过Msg3的错误警报解决需要从寻呼索引映射到Msg1前导码。gNB需要事先将这些前导传输给UE，以便UE可以将寻呼索引映射到适当的Msg1资源。
