對于5G尋呼，有以下選項：

• 選項1：Paging?DCI，然后尋呼消息，兩個動作可以不連續(xù)

• 選項2：Paging group indicator觸發(fā)UE反饋和Paging?DCI，然后是尋呼消息

• 選項3：Paging group indicator和Paging?DCI，然后是尋呼消息

• 選項4：Paging?DCI表示使用選項1或2。

對于這3個選項，至少支持選項1（尋呼調(diào)度DCI，后跟尋呼消息），從物理層角度來看，尋呼調(diào)度DCI和尋呼消息至少在同一個時隙中發(fā)送。

在多波束場景中，廣播傳輸（如用于發(fā)送尋呼消息）必須通過波束掃描進行。由于gNB側(cè)有大量波束，廣播效率非常低。多波束場景（例如使用高頻頻段）中的尋呼開銷取決于gNB必須掃描的波束方向數(shù)與gNB天線陣列數(shù)的比率。SS?burst set中SSB的數(shù)量可以視為該比率的等效項，因為gNB根據(jù)其必須掃描的方向數(shù)和天線陣列的數(shù)量來決定SSB的數(shù)量。因此，使用SSB的數(shù)量，而不是波束方向的數(shù)量和天線陣列的數(shù)量來分析下行尋呼開銷。表1顯示了在分析中使用的參數(shù)。

在LTE中，每個SS?burst set僅包含一個SSB。然而，在毫米波段（MMW）中，每個SS?burst set可以有多達64個SSB，即時在FR1中，也有8個SSB。

另一方面，LTE具有20 MHz帶寬，而毫米波的載波可以具有100 MHz帶寬。此外，LTE的小區(qū)邊緣頻譜效率為0.1bps/Hz。模擬結(jié)果表明，對于NR，能夠在小區(qū)邊緣實現(xiàn)0.225 bps/Hz?；谶@些數(shù)字，LTE和MMW的下行尋呼開銷如圖1所示

圖2比較了LTE和MMW對尋呼的容量需求。LTE以每秒6400個UE的最大尋呼速率消耗大約13%的下行容量。在毫米波網(wǎng)絡(luò)中，對于相同的尋呼速率，下行容量需求明顯更高，對于64個SSB，它可以達到下行容量的73%。這比LTE網(wǎng)絡(luò)中尋呼的相應(yīng)下行容量需求高5-6倍。

可以通過壓縮尋呼記錄來減小尋呼廣播的大小。這種壓縮可以基于應(yīng)用于UE ID的hash，例如，包含在尋呼記錄中的S-TMSI或IMSI。它還可以基于UE ID的截斷。它可以基于將UE ID替換為group ID，假設(shè)UE之前已經(jīng)與這樣的組相關(guān)聯(lián)。其他壓縮方法也是可能的。UE ID的壓縮形式稱為尋呼索引。尋呼廣播僅包含尋呼索引。

壓縮后，gNB廣播X位的尋呼索引，而不是（例如）40位長度的UE-ID，這將下行尋呼開銷減少了40/X。例如，如果X=14位，則廣播開銷減少了近3倍。

為了在廣播尋呼中獲得足夠大的資源增益，需要應(yīng)用有損壓縮。這種有損壓縮可能導(dǎo)致虛假尋呼警報，因為尋呼索引可能映射到多個UE id，其中只有一個或一個子集應(yīng)該被尋呼。在這里，由于尋呼索引的多對一映射，會出現(xiàn)錯誤警報。換句話說，通過假警報，我們關(guān)注UE從gNB正確接收尋呼索引位的場景；假設(shè)該索引是針對其自身的，因為映射函數(shù)將其UE ID映射到由gNB傳輸?shù)耐粚ず羲饕?；但尋呼索引用于另一個UE。

通過適當選擇索引大小，可以減少基于索引的尋呼機制引起的錯誤尋呼警報。例如，LTE在每個尋呼時刻最多發(fā)送16條尋呼消息，尋呼時刻每10ms發(fā)生四次。對于X位的索引大小，接收錯誤警報的概率約為16×2-X。假設(shè)X=14位，錯誤警報的概率小于10-3，這將在1000 X 320ms=5??min的時間內(nèi)轉(zhuǎn)化為一個錯誤警報。這是最壞的情況。在更現(xiàn)實的場景中，誤報率會低得多。

當UE收到基于索引的尋呼警報時，它嘗試建立到gNB的RRC連接，以檢索網(wǎng)絡(luò)上等待它的數(shù)據(jù)。

下面提供了2中解決尋呼警報的方法。

由于UE在RRC連接請求中包括其UE-ID，因此網(wǎng)絡(luò)可以驗證該UE-ID是否與尋呼記錄列表上的條目匹配。如果發(fā)現(xiàn)這種匹配，則網(wǎng)絡(luò)接受RRC連接請求。因此，不會為真正的警報引入額外的開銷。

在相反的情況下，如果沒有找到匹配項，則網(wǎng)絡(luò)會得出結(jié)論，認為發(fā)生了錯誤的尋呼警報，因此拒絕RRC連接請求。RRC連接拒絕消息可能包括拒絕的原因。與不成功的連接建立嘗試相關(guān)的開銷與錯誤尋呼警報概率一樣小。這可以通過應(yīng)用于尋呼消息的壓縮程度來設(shè)置，即如上所述的索引大小。

網(wǎng)絡(luò)應(yīng)僅對響應(yīng)尋呼廣播而發(fā)生的連接建立嘗試應(yīng)用匹配操作。為了區(qū)分基于尋呼的連接建立嘗試與其他性質(zhì)的嘗試，UE在請求建立連接時包括尋呼響應(yīng)指示。僅當包含該指示時，gNB才應(yīng)用匹配操作。

在該方法中，基于索引的尋呼警報可以通過尋呼消息的PDSCH傳輸，該消息之前是尋呼調(diào)度DCI。與當前LTE的尋呼機制相比，這仍將減少尋呼開銷，因為每個UE的尋呼信息將僅包含大小小于40位的尋呼索引。

在第二種機制中，基于索引的尋呼驗證嵌入到隨機接入過程中。接收警報的UE通過在隨機接入信道上發(fā)送前導(dǎo)來啟動隨機接入過程。它根據(jù)到導(dǎo)致尋呼警報的索引的映射來選擇前導(dǎo)碼。該映射可以由網(wǎng)絡(luò)預(yù)先配置。通過這種方式，gNB可以找到向UE發(fā)出警報的相關(guān)尋呼索引。

在尋呼廣播之后接收前導(dǎo)碼的gNB評估前導(dǎo)碼是否匹配到之前廣播的任何尋呼索引的映射。如果找到這樣的匹配，gNB在隨機訪問響應(yīng)（MSG 2）中包括與該索引相關(guān)的尋呼記錄。這允許UE驗證尋呼警報是真是假。在尋呼警報為假的情況下，UE將隨機接入終止指示包括在尋呼過程的MSG 3中。否則，它將以常規(guī)方式繼續(xù)尋呼過程和RRC連接建立，以檢索網(wǎng)絡(luò)上等待它的數(shù)據(jù)。

注意，通過Msg3的錯誤警報解決需要從尋呼索引映射到Msg1前導(dǎo)碼。gNB需要事先將這些前導(dǎo)傳輸給UE，以便UE可以將尋呼索引映射到適當?shù)腗sg1資源。