991-5G寻呼大小对时域资源的要求.docx

《991-5G寻呼大小对时域资源的要求.docx》由会员分享，可在线阅读，更多相关《991-5G寻呼大小对时域资源的要求.docx（4页珍藏版）》请在优知文库上搜索。

1、5G寻呼大小对时域资源的要求一个寻呼消息需要几个OFDM符号来承载呢？表1提供了6GHz以上情况的示例，表1描述了当使用约35MHz的系统带宽和120kHz的SCS时，编码速率为1/6和1/12的QPSK调制的特定大小的寻呼消息在时域中所需的符号数。表1:每寻呼消息所需OFDM符号数Pagingmessagebits/CR“1/6”“1/12”8bits(SIchange/PWSindication)1symbol1symbol160bits/4UEs2symbols4symbols400bits/-10UEs4symbols8symbols从表1中可以看出，寻呼消息所需的时域符号数随寻呼消息

2、大小和使用的编码率而变化。因此，能够灵活地调整寻呼消息的时域长度就很有必要。事实上，这对于多波束系统是有益的,因为相同的寻呼内容需要扫描每个方向。对于并非所有波束方向都可以同时服务的多波束小区，需要对PCH（寻呼信道）应用波束扫描。考虑到上述定义的单个寻呼消息对寻呼信道比特率和可能有效负载大小的要求，能够适应寻呼消息大小是有益的。然而，使用正常的时隙长度扫描小区中的所有波束将花费不必要的时间资源，因此在多波束系统中并不可取。对于NRPDSCH上携带的PCH扫描，可以利用sub-slot概念来适应相对小的寻呼消息大小。如果消息大小很小，则使用基于时隙的调度可能会浪费时域中的系统资源（例如要求始终

3、为每个空间方向应用一个完整的时隙）。然而，所需的PDSeH分配（符号数）的大小将取决于要调度的UE数量。从图1可以看出，P（）#2的寻呼消息扫描比P（）#0的长，因为可能有更多与P0#2匹配的UEID需要寻呼。然而，寻呼调度扫描具有相同的大小，因此从UE的角度来看具有确定性。应该注意的是，寻呼消息中可能没有任何内容要携带，在这种情况下，应该允许带宽调度正常的上下行时隙分配，以替换控制信道扫描和PCH扫描。PO #1PO #0PCH sweep block #0Paging cycle 人图1:在一个Po内有多个Po sweepburst的多波束小区中进行寻呼。如上所述，寻呼消息的有效负载可能会

4、发生变化，减少扫描开销的一种可能性是使用非基于时隙的调度概念进行寻呼传输。如图2所示。因此，如果寻呼消息大小有限，CORESET空间将共享，PDCCH将使用非基于时隙的调度，从而实现更高效的资源使用。这在两种情况下都适用，即单波束部署和少波束部署。K0=9, Duration=4图2:基于Non-sIot的PCH调度NR-PDCCHNR-PDSCH在部署更多波束的场景中，减少寻呼扫描持续时间将是一件有意义的事情。如图3所示，根 据假设的PDSCH大小，可以确定CORESET在调度的KO=O的时隙中出现两到三次。另一种选 择是确定出现在时隙和Ko开头的CoRESET Wo表示计划的NR PDSC

5、H,如图4所示。Figure 1.分布式NR-PDCCH扫描，用于基于Non-sIot的寻呼调度，使用(a)4符号PDSCH和(b)2符 号 PDSCH图2. NR-PDCCH扫描在NOn-SlOt寻呼调度的开始，使用(a)4符号PDSCH和(b) 2符号PDSCH通常，对于多波束系统，PCH调度信息的时间位置供应应至少基于检测到的SSB具有一定的确定性，以便UE可以确定要监控的相应资源，从而减少所需的活动时间。因此，扫描中的每个调度块可以与小区中的SSB有固定的关联，因此UE可以确定要监视的CORESET的精确定时。另一方面，在考虑混合和模拟波束架构时，固定的定时对调度器提出了严格的要求。在

6、考虑寻呼时机可能与对延迟更敏感且具有更高优先级的服务发生冲突时，如果为寻呼监控定义了严格固定和受限的时间时机，那么调度器的唯一选择将是将寻呼延迟到下一个时机。这将导致寻呼延迟增加的风险，另一方面，这可能会对用户体验产生负面影响。然而，原则上可以确定寻呼监视时机具有一定的时间容限，以便网络可以有一定的寻呼调度自由度。例如，与用于LTE的SlB调度一样，可以确定窗口，以便CORESET的多个场合将出现在监视窗口内。如TR38.300描述，寻呼场合可以覆盖多个时隙，并且时隙长度应由系统配置。以图4(a)和(b)中所示的方法为起点，可以确定UE在时隙集开始的三个CORESET场合监测PDCCH,然后例

7、如根据寻呼消息的大小，网络可以选择使用4符号PDSCH或2符号PDSCH甚至全时隙来调度寻呼消息。当然，IJE需要提供时隙内监测场合的符号级位图，寻呼场合也应考虑不同的PDSCH分配（即可以在时隙中扫描的波束数量可能不同）。对于寻呼CORESET的确定，有两种主要方法，要么给出特定的寻呼配置，例如在RMSI中，要么使用PBCH中定义的C0RESETo由于RMSI和寻呼都是广播信号，因此定义方面是确保覆盖，并且PDCCH监测周期可以单独配置，因此使用与RMSI相同的CORESET参数化似乎是可行的，至少当两者使用相同的调度方法时，时隙或非时隙。如果SIB/RMSI使用基于Nonslot和通过基于

8、时隙的寻呼进行调度（反之亦然），则可能需要提供额外的参数。由于PDCCH监测周期和时隙级别的窗口大小将由寻呼时机配置决定，因此似乎只有通过提供搜索空间集，才能单独确定寻呼PDCCH监测的监测周期。如果基于Non-Slot的调度用于寻呼PDCCH,则需要提供“Montoring-periodicity-PDCCH-within-slot”,指示时隙中的位置。可以假设在寻呼窗口的每个时隙中监视寻呼，而不需要提供基于时隙的周期性，即Montoring-Periodicity-PDCCHsIotffo潜在的寻呼帧可以限制为所有帧的子集。这将有助于减少在连续帧中进行波束扫描（在混合/模拟波束的情况下）的

9、需要。然后，根据预期的寻呼负载，UE可以基于UEID分布在不同的位置。同样考虑到这种子集方法，有效帧可以集中在SSB的附近，即UE跟踪。此外，不同的寻呼帧可以偏移以定位在不同的SSburstSet上。/SSburstXirodJ图5:寻呼帧分布示意图扫描控制信道以FDM方式与SSB多路复用，以节省额外开销。然而，对于使用窄载波带宽运行的系统来说，主要需要降低开销，但很可能不可能使用具有SSB的FD多路复用。使用这种方案，位置的数量将受到SSburstSet周期性的限制，该周期性可能并不总是足以满足小区中的寻呼负载量。因此，为简单起见，应首先考虑用于扫描控制信道的单独扫描，然后再考虑通过与SSB

10、多路复用进行可能的优化，以用于具有足够宽载波带宽的系统。在任何情况下，带宽都应具有将扫描控制信道配置为单独扫描或SS扫描（甚至两者）的方法。需要支持不同的机制，以便在多波束部署中支持基于下行寻呼。通过来自UE的上行链路驱动响应（响应驱动寻呼），为了帮助网络识别用户所在的波束或波束组，可以减少寻呼消息的下行开销。在这种情况下，寻呼消息仅在用户可能所在的波束上发送。在响应驱动的寻呼指示符机制中，不是发送包含UEID（例如S-TMSD的寻呼消息，而是将UE分配给组，即寻呼组（PG）,UE在PO中对其进行监视。为了寻呼UE,网络发送寻呼指示符，作为响应，所有监视同一寻呼指示符的UE将执行上行访问。有两

11、种方法用于将RACH前导序列分配给用于响应寻呼指示符的RACH消息：方法1：专用PRACH前导序列：UE基于用户所属的寻呼组选择专用RAeH前导。同一组中的所有用户，选择相同的RACH前导，这些用户可以处于不同的波束中。网络无法区分同一组中的用户，因此需要在接收到给定RACH前导码的波束上发送寻呼消息。方法2：从PRACH随机序列池中随机选择前导：UE随机选择前导。UE将其ID作为RACHMsg3的一部分或可能作为RACHMSgl的数据部分发送到网络。这允许网络识别UE的波束位置，并因此在该波束上发送寻呼消息。Paginggroupindicator对于在下行中传输寻呼指示器，基本上有两种选择

12、。由于网络需要能够在单个PO中寻呼多个PG,因此最直接的做法似乎是以位图的形式携带所述指示，其中每个位对应于单个PGo每个PO所需的PG数量决定了所需的位数。最好的方法是增加每个PO可以支持的Pg的数量，减少了可以预期基于下行指示执行上行接入的Ue的数量。当然，为了增加可支持的PG数量，PG指示需要更大的空间，从而产生更多的下行开销。例如将16到32位长位图用于PG指示。这种大小的基于位图的指示（小于NbPBCH考虑的有效载荷）可以在NR-PDSCH上进行。另一种选择是使用NR-PDCCH（相关格式）交付位图。另一种选择是，每个PG都有一个标识，与正常寻呼的标识没有太大区别。此外，为了在这种情况下寻呼多个组，需要使用NR-PDSCH来携带多个（单独）PG标识符，将所需的有效载荷适合NR-PDCCH似乎不可行。如上所述，如果PG的数量大约为25=32（即单个PG为5位），则所需的有效负载大小将开始接近正常寻呼中的相同水平，从而减少可获得的下行资源开销节省。