NB-IoT尋呼時延分析與探討

夏 穎

（上海電子信息職業技術學院 通信與信息工程學院，上海 201411）

1 NB-IoT業務概述

NB-IoT業務廣泛應用在工業、農業、智能家居、智慧城市、環境監測等眾多領域[1]，NB-IoT業務平臺下發指令通過核心網尋呼（Paging）空閑態的NB-IoT終端，如圖1所示。UE收到Paging消息后，建鏈并附著，與核心網及業務平臺完成信息交互。

2 NB-IoT尋呼參數

NB-IoT的尋呼是指通知空閑態的終端有系統消息的變更以及有下行數據到達。當核心網需要向終端發送數據時，將通過MME經S1接口向基站發送尋呼消息，基站收到該尋呼消息后，在收到的TAI列表中的小區內進行尋呼[2]。

NB-IoT終端在空閑態的被叫尋呼分為不連續接收（Discontinuous Reception，DRX）尋呼和擴展間斷接收（Extended Discontinuous Reception，eDRX）尋呼[3]，當處于空閑態的終端只要定義好固定的周期，就可以對PDCCH進行不連續的監聽，這樣可以節省終端發射功率。由于NB-IoT對低功耗方面要求更高，新增了eDRX擴展的非連續接收功能，進一步延長終端在空閑模式下的睡眠周期，減少接收單元不必要的啟動。eDRX適用于低速率、低頻次的業務模型。

2.1 DRX相關參數

（1）DRX尋呼周期TDRX。

（2）尋呼幀（Paging Frame，PF）。PF是一個無線幀，長度10 ms，PF上可以有一個或多個PO。

（3）尋呼時刻（Paging Occasion，PO）。PO為一個子幀，長度為1 ms。在PO上，基站通過NPDCCH信道發送尋呼消息給終端，終端在一個DRX周期內只監聽一個PO。

例如某個UE的DRX尋呼圖1所示，TDRX=512，PF=404，PO=9。

2.2 eDRX相關參數

（1）eDRX尋呼周期TeDRX。

（2）尋呼超幀（PH，Paging Hyperframe）。1個PH為1 024個無線幀。

（3）尋呼時間窗口（Paging Time Window，PTW）。PTW指終端在一個超幀內監聽尋呼NPDCCH的窗口。PTW為PH中的一段，單位為幀。當TeDRX≥1 PH，終端在PTW中監聽PO。

例如某個UE的eDRX尋呼圖2所示，TeDRX=8，PTWstart=256，PTWend=767，PF=404，PO=9。

3 問題分析

NB-IoT業務平臺下發指令后，完成整個過程的正常時延要求在15 s以內，如果超過15 s，則是時延過長[4]。業務平臺同時給多個UE下發指令，容易出現尋呼時延過長的問題，下面分析一下原因，主要分析eNodeB側的log。

（1）eNodeB在16:21:22:660收到從MME發過來的Paging消息。

圖1 空閑態的UE尋呼

圖2 DRX尋呼

圖3 eDRX尋呼

16-16:21:22:660 14388720 Module:RNLU_DMAC_BPCH Pri:FLW --------Dmac Rcv CN Pcch Msg Info--------

16-16:21:22:660 14388721 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchMsgRcv],CellId=81,Gid= 32772,CurTime=Ox3599,MsgLen=7

16-16:21:22:660 14388722 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchMsgRcv], UeId=2648,DrxLength=256,NB=8,T=256

16-16:21:22:660 14388723 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchMsgRcv],PFOfffSet=0,PO=9

16-16:21:22:660 14388724 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchMsgRcv], CsfbPaging=0,FreePagingNodeNum=22993

16-16:21:22:660 14388725 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchMsgRcv],ucIsTeDrx=0,wTeDrx=2,wPTW=256

16-16:21:22:660 14388726 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchMsgRcv], wFPH=0,wS tartPTW=0,wUeIdentityIdxVal=0

（2）eNodeB在16:21:24:320進行處理，該UE的尋呼時刻是HSFN=96, SFN=0, PO=9。

16-16:21:24:320 14390004 Module:RNLU_DMAC_BPCH Pri:FLW --------[Dmac Rcv Bcch Sch Result Info] ------

16-16:21:24:320 14390005 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], CellId=81,Flow No=1,TBSize=85,CurTime=Ox3ff9

16-16:21:24:320 14390006 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], Trantime=Ox00 02,SchCtrlInfoLen=24

16-16:21:24:320 14390007 Module:RNLU_DM AC_BPCH P r i:F LW [D m a cBc ch P ro c],CellIdInBoard=0,ValidNum=255

16-16:21:24:320 14390008 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], Gid=32773,Flo wNo=1,TransTime=Ox2,CurTime=Ox3ff9

16-16:21:24:320 14390009 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], Gid=32773,Cma cSendTime=Ox3ff9,TbSize=85

16-16:21:24:320 14390010 Module:RNLU_DMAC_BPCH Pri:FLW [DmacJudgePcchOccatsion], wCur Sfn=0,wSmallTValue=256,wFPF=0,SFNOffset=0

16-16:21:24:320 14390011 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchBsr], CellId=81,Merge PagingNum=1,Paging=187,PP:PagingNo

16-16:21:24:320 14390012 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchSendBsr], Paging Time==＞HSFN=96,SFN=0,PO=9

（3）eNodeB在16:21:24:320分配PDCCH和PDSCH資源，但分配失敗。

16-16:21:24:320 1097982 Module:MAINFLOWLOG Pri:FLW [SCHE][CellIdx:0]|Schd PCH,HFN:75872,(PF,PO)[Ox0,9],fail to alloc pdcch

（4）MME沒有及時收到UE的確認消息，每隔12 s重發1次Paging消息給eNodeB，eNodeB收到了3次重發的Paging消息。

16-16:21:34:620 14394469 Module:RNLU_DMAC_BPCH Pri:FLW --------Dmac Rcv CN Pcch Msg Info----------

16-16:21:46:760 14399825 Module:RNLU_DMAC_BPCH Pri:FLW --------Dmac Rcv CN Pcch Msg Info-----------

16-16:21:58:750 14404846 Module:RNLU_DMAC_BPCH Pri:FLW --------Dmac Rcv CN Pcch Msg Info-----------

（5）eNodeB在16:22:25:760對重發的Paging消息進行了處理，尋呼時刻是HSFN=102, SFN=0, PO=9。

16-16:22:25:760 14416346 Module:RNLU_DMAC_BPCH Pri:FLW ---------[Dmac Rcv Bcch Sch Result Info]-----

16-16:22:25:760 14416347 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], CellId=81,FlowNo=1,TB Size=85,CurTime=Ox3ff9

16-16:22:25:760 14416348 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], Trantime=Ox0002,SchCt rlInfoLen=24

16-16:22:25:760 14416349 Module:RNLU_DM AC_BP C H P r i:F LW [D m a cB c c h P r o c],CellIdInBoard=0,ValidNum=255

16-16:22:25:760 14416350 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], Gid=32773,FlowNo=1,Tr ansTime=Ox2,CurTime=Ox3ff9

16-16:22:25:760 14416351 Module:RNLU_DMAC_BPCH Pri:FLW [DmacBcchProc], Gid=32773,CmacSendTi me=Ox3ff9,TbSize=85

16-16:22:25:760 14416352 Module:RNLU_DMAC_BPCH Pri:FLW [DmacJudgePcchOccatsion], wCurSfn=0,w SmallTValue=256,wFPF=0,SFNOffset=0

16-16:22:25:760 14416353 Module:RNLU_DMAC_BPCH Pri:FLW [DmacJudgePcchOccatsion], wCurSfn=0,w SmallTValue=256,wFPF=0,SFNOffset=0

16-16:22:25:760 14416354 Module:RNLU_DMAC_BPCH Pri:FLW [DmacJudgePcchOccatsion], wCurSfn=0,w SmallTValue=256,wFPF=0,SFNOffset=0

16-16:22:25:760 14416355 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchBsr], CellId=81,MergePagingNu m=3,Paging=188, PP:PagingNo

16-16:22:25:760 14416356 Module:RNLU_DMAC_BPCH Pri:FLW [DmacPcchSendBsr], Paging Time==＞HSFN=102,SFN=0, PO=9

（6）eNodeB在16:22:26:210成功分配了PDCCH和PDSCH資源，把Paging消息發給了UE。

16-16:22:26:210 1101824 Module:MAINFLOWLOG Pri:FLW [SCHE][CellIdx:0]|Schd PCH,HFN:102,(PF,PO)[Ox0,9],PDCCH[Ox13,Ox34], PDSCH[Ox39,Oxe1].

從上面LOG可以看到，eNodeB在16:21:22:660第一次收到了MME發過來的Paging消息，在16:22:26:210將Paging消息成功發給了UE，共花了64 s，原因是eNodeB第一次收到Paging消息后資源分配失敗，導致MME重發，處理時間過長。

eNodeB資源分配處理失敗，原因是eNodeB在同一時間要處理8個UE的Paging消息，如下log所示，NB-IoT系統空口資源有限，會存在一定概率的資源分配沖突，導致資源分配失敗。

Line 223837：16-16:21:22:300 14388487 Module:RNLU_DMAC_BPCH Pri:FLW ---Dmac Rcv CN Pcch Msg Info--

Line 223893：16-16:21:22:390 14388542 Module:RNLU_DMAC_BPCH Pri:FLW ---Dmac Rcv CN Pcch Msg Info--

Line 223929：16-16:21:22:390 14388577 Module:RNLU_DMAC_BPCH Pri:FLW --Dmac Rcv CN Pcch Msg Info---

Line 223964：16-16:21:22:530 14388611 Module:RNLU_DMAC_BPCH Pri:FLW --Dmac Rcv CN Pcch Msg Info---

Line 223992：16-16:21:22:530 14388638 Module:RNLU_DMAC_BPCH Pri:FLW --Dmac Rcv CN Pcch Msg Info---

Line 224055：16-16:21:22:660 14388700 Module:RNLU_DMAC_BPCH Pri:FLW --Dmac Rcv CN Pcch Msg Info---

Line 224076：16-16:21:22:660 14388720 Module:RNLU_DMAC_BPCH Pri:FLW --Dmac Rcv CN Pcch Msg Info---

Line 224363：16-16:21:23:030 14389006 Module:RNLU_DMAC_BPCH Pri:FLW --Dmac Rcv CN Pcch Msg Info---

4 解決方案和探討

（1）建議業務平臺最好能串行下發指令，相鄰UE間隔一定時間，如0.5 s。

（2）eNodeB修改尋呼參數、隨機接入信道參數可減少資源沖突的概率。

（3）TAC尋呼策略會導致eNodeB收到的尋呼消息數較大，建議打開eNodeB和核心網尋呼優化功能，尋呼優化功能是UE釋放時，發送當前小區信息給核心網作為尋呼UE時發送消息的推薦小區，這樣核心網在下次尋呼中可以攜帶尋呼發送的小區列表，那么尋呼消息僅會在這些小區發送，而不是在這個跟蹤區（TAC）發送。

（4）尋呼策略改為基站級尋呼。