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）寻呼策略改为基站级寻呼。