LTE寻呼容量及参数设置

LTE基站寻呼拥塞率问题分析处理【摘要】实际现网由于用户量不多，基站负荷较小，4G网络在当前的业务需求以及寻呼策略下，一般的不太容易出现拥塞。

本例中描述的是一起单站信道板（BPL）故障导致寻呼拥塞，由面到点，再通过后台打印进程内容定位出故障位置。

给处理寻呼拥塞积累了一些分析思路。

【关键字】寻呼拥塞寻呼消息堆积【故障现象】在滁州日常KPI指标统计中，发现4月22日的网络的寻呼拥塞率从平时的0.00%突变到0.01%。

图1 滁州整网寻呼拥塞率【告警信息】检查告警信息，发现并没有大规模基站故障告警，只有部分零散的新开基站存在告警，但不会导致整网的寻呼拥塞率高。

【原因分析】寻呼拥塞率KPI分析：寻呼拥塞率=寻呼记录发送不成功次数/混户籍路应发送次数*100%主要是指eNB由于资源限制原因导致寻呼消息发送失败的情况。

由于目前现网是网络容量大于需求，正常情况下不会出现寻呼拥塞。

从核心网的同事了解到当前的寻呼策略是按照最近一次活动的TA寻呼和TA LIST寻呼相结合的。

第一次在最近一次活动的TA下寻呼一次，如果寻呼不到，则在相应的TA LIST 范围内进行寻呼。

表1 LTE网络寻呼的参数设置导致寻呼拥塞的原因可能有：无线测配置的寻呼参数配置失当或者网络的TA划分不合理：检查寻呼参数设置如下：表2 现网寻呼参数的设置其中nB和T属于协议参数，别的属于算法参数；广播的基站所用的寻呼周期（T），在UE使用时还有一个参数，叫做UE的专用寻呼周期，两者取小作为UE的实际使用的寻呼周期。

该UE的专用寻呼周期（取值范围与小区寻呼周期的相同）来自于UE 自己上报的NAS消息，在寻呼UE时，由核心网在寻呼消息中通知基站。

2、硬件配置问题：由面到点，查询全网的寻呼拥塞率指标，发现全部集中在滁州学院宿舍楼室分的8槽位BPL板的4/5/6三个小区，如下图：图2 滁州学院宿舍楼室分寻呼拥塞率综上，检查滁州学院宿舍楼的参数配置，可以排除寻呼信道不够用的情况；检查滁州学院宿舍楼室分的TAC规划，网管配置跟规划的一致，同个TAC下只有28个站点，排除TAC规划问题。

TD-LTE 基站寻呼容量计算方法1计算方法1.1输入参数计算1、业务模型参数根据业务模型计算忙时每用户呼叫次数，例如可假设为2.5次。

2、覆盖区的用户数根据目标区域特点设置用户密度，例如可设置为表1-1。

表1-1典型区域用户密度3、计算单小区寻呼用户数单小区寻呼用户数计算公式为单小区寻呼用户数=覆盖面积*用户密度*运营商渗透率*业务渗透率其中覆盖面积S ，R为小区覆盖半径，对应站间距为1.5R。

例如，如果站间距为400m，则单小区覆盖面积为0.13856平方公里，假设目标区域为商用区，则用户密度25,000个/平方公里，运营商渗透率设为0.8，业务渗透率设为1，则密集城区内单小区寻呼用户数=0.13856×25000×0.8×1=2772按照以上假设，单小区可能发生的寻呼次数为2772*2.5=6930次/小时，折算到秒为6930/3600=1.925次/s。

1.2根据配置获取每小区每秒支持的最大寻呼数根据3GPP 36.331，一个子帧中寻呼的UE最多为16个。

计算不同Nb配置下的寻呼个数，1s寻呼的UE个数/小区=1000/10×PO×16，各配置下每小区每秒支持的最大寻呼数见表1-2。

表1-2各配置下每小区每秒支持的最大寻呼数nB配置为T/2和T时，单小区每秒支持的最大寻呼UE数分别为800个和1600个。

1.3根据配置获取每小区每秒支持的最大寻呼数统计TA List内的小区数，获取TA List内每秒寻呼用户数，即每秒内TA List的首次寻呼次数=TA List内小区数×单小区寻呼用户数假设一个TA List内包含150个小区，则每秒内TA List的首次寻呼次数为1.925×150=288.75。

根据需要发起二次寻呼的用户比例，即可计算每秒TA List内需要发起的寻呼数，即TA List内需要发起的寻呼数=每秒内TA List的首次寻呼次数×(1+发起二次寻呼的用户比例)例如，如果发起二次寻呼的用户比例为5%，则为288.75×(1+5%)=303。

eNB上，寻呼相关的参数有两个，作为广播消息在SIB2中传递给UE：其中defaultPagingCycle即T，决定DRX周期即寻呼周期，单位为rf（无限帧，10ms），取值范围是32、64、128和256。

值越大，RRC_IDLE状态下UE的电力消耗越少，但是相应的，寻呼消息的平均延迟越大，接通的时延也越大。

nB表征寻呼密度，取值范围是4T、2T、T、T/2、T/4、T/8、T/16、T/32，图中oneT表示每个无线帧有1个子帧用于寻呼，如果设置为T/32则表示每32个无线帧有1个子帧用于寻呼，该值决定了LTE系统的寻呼容量。

nB的取值表征寻呼组的数量，如T取值128，nB取值T，则相当于将所有的用户分为128个寻呼组，如果T取值64，nB取值T/4，则分为16个寻呼组，寻呼组越多，每个组中用户数量越少。

LTE寻呼在物理信道PDSCH信道传输，每个寻呼信道最多可以寻呼16个用户，根据nB 的取值，可以计算出小区的寻呼容量：由于移动通信寻呼的突发性，一般要求网络的寻呼负荷不超过50%的寻呼容量，因此，在进行网络规划、参数规划的时候，需要考虑综合TAC、用户分布等因素，规划寻呼参数：一般情况下，LTE小区寻呼参数建议设置：–T=64或者128，nB=T此时，寻呼周期640/1280ms，寻呼容量：1600次/秒特殊场景（如大型活动、比赛现场），需要对某些小区的寻呼参数进行优化调整，可以采用的方案如下：–nB：增大nB，提高小区寻呼容量，减少寻呼拥塞，如nB→2T/4T–T：T值越大，寻呼时延越长，寻呼组增加，每个寻呼信道中的用户越少，反之寻呼时延缩短，每个寻呼信道用户增加，可能导致某个时刻一个寻呼组寻呼的用户超过16个，反而增加的寻呼时延，因此，可以根据实际用户的数量，调整T值。

LTE网络寻呼容量评估目录1概述1.1TAC介绍LTE网络现行寻呼策略为：精准寻呼+普通的寻呼，即UE上次驻留的eNodeB发起寻呼->精准寻呼2S响应超时寻呼下级，最近TAC ->精准寻呼2S响应超时寻呼下级，TAL->精准寻呼2S响应超时重新寻呼， TAL ->寻呼6S超时后重新寻呼，TAL ->寻呼6S超时后寻呼失败。

注：若UE在一个eNodeB下的驻留时间小于2分钟（eNodeB粘性时长），MME将跳过该UE对应的寻呼规则中“最近eNodeB”的寻呼范围，直接跳转到下一级范围（TAC或TA List）进行寻呼。

TAC区作为LTE网络寻呼过程中重要的一环，配置即不能过大也不能过小：过大：会导致核心侧、无线侧资源消耗过大，引起过载、挤占业务信道资源或需要的配置过高问题。

过小：会导致TAC级寻呼成功率偏低、从而触发过多不心要的TAC List级寻呼，并导致TAC编号资源紧张。

1.2TAC区约束条件TAC区最大寻呼能力需要考虑以下2方面的约束条件：1、核心侧MME现网配置条件下的寻呼能力。

2、无线侧寻呼对空口资源占用合理比例下的寻呼能力。

2TAC寻呼能力分析2.1核心侧MME分析核心网进行TAC合并的条件是，一个TAL下挂基站数量不超过150，否则在用户数突增情况下可能造成MME侧设备的负荷问题。

TAL下TAC数量减少对核心网设备负荷的影响在5%左右。

统计现网TAL下挂基站数目情况，150个基站以上的TAL数目达到53个，其中衡水最高达到一个TAL下面825个BBU（TAL:18929），部分过大的TAL需要进行分裂后再进行TAC合并。

按照现网TAL的基站容量对TAL进行了级别分类，建议分批次进行TAL裂分：2.2无线侧空口分析LTE寻呼信息主要由PDSCH（业务信道）承载，因此PDCCH容量无压力，重点分析PDSCH能力如下。

目前现网配置：1、寻呼周期为秒。

2、寻呼标识采用S-TMSI（每用户占用约42bit）。

移动LTE网络TAI、ENODEBID、CELLID编号原则1. TAILTE/EPC以TAI标识用户位置，类似2G/3G位置区LAI及路由区RAI，一个TA 可由一个或多个小区构成。

当LTE用户移动发生TAI改变时，终端需要向MME 发起TAU跟踪区更新，消息中包含用户的TAI。

TAI由MCC+MNC+TAC三部分组成。

其中：TAC：跟踪区码，2字节，用16进制表示为x1 x2 x3 x4，TAC的FQDN格式为：tac-lb<x3x4>.tac-hb<x1x2>.. mnc<MNC>.mcc<MCC>.。

由于TAC采用了LAC不同的FQDN格式，因此TAC与LAC 可重叠使用。

TAC码号的规划与LAC的规划分配统一，L1L2由集团统一分配，L3L4由省内分配，各分公司优先启用与本地GSM网LAC相同的TAC码号。

同一TA的无线覆盖范围，尽量不要位于不同MSC POOL的覆盖范围，以便于后续CSFB的部署。

2. ECGIECGI由PLMN+ECI两部分组成，ECI由eNodeB-ID+Cell-ID 两部分组成，eNodeB-ID基站标识，在PLMN下唯一，取值范围0~1048575（十进制）。

eNodeB-ID的定义参考RNC-Id定义。

即：eNodeB-ID表示为X1X2X3X4X5（X1、X2、X3、X4、X5均为4bit长），取值范围为0x00000 ～ 0xFFFFF，全部为0的编码不用。

X1和X2由集团统一分配（已分配80，81）； X3、X4、X5由省内分配。

分配方案见下：Cell-IDCell-ID是EUTRAN小区标识， CELLID由分公司自行分配，取值范围0~255（十进制）/0x00 -0xFF（十六进制），全部为0的编码不用。

TA及相关的基本概念TA：Tracking Area，跟踪区。

TA是LTE系统为UE的位置管理新设立的概念。

【摘要】文章介绍了LTE系统的寻呼机制，并把LTE的寻呼机制抽象成排队论中的nB个独立的M/D/1排队模型，其中nB是LTE系统广播消息中包含的寻呼消息的一个参数，同时采用M/D/1模型分析了LTE系统的寻呼时延和寻呼容量，对将来LTE网络寻呼的规划和优化有一定参考意义。

【关键词】LTE 寻呼 M/D/1收稿日期：2012-01-15赵建军 中国电信股份有限公司江苏分公司张光辉 中国电信股份有限公司北京研究院郭致毅 中国电信股份有限公司江苏分公司朱彩勤 中国电信股份有限公司北京研究院LTE系统的寻呼机制及1 引言LTE（Long Term Evolution）是3GPP推出的新一代无线通信系统，是3G的演进技术，一般被称为3.9G或准4G。

LTE目前共有R8、R9、R10三个版本，其中R8和R9版本已分别于2008年底和2009年底冻结，代表4G技术的R10版本也称为LTE-Advanced，其主要技术规范在2011年初完成。

LTE通过采用正交频分复用（OFDM，Orthogonal Frequency Division Multiplexing）和多入多出（MIMO，Multiple-Input Multiple-Output）作为其无线网络演进的主流标准，LTE R8可以在20MHz频谱带宽下提供下行100Mbit/s与上行50Mbit/s的峰值速率，同时提高了小区容量、降低了系统延迟，可以更好地满足用户对数据业务的需求。

伴随着LTE标准的成熟和完善，以及移动互联网时代全球移动数据业务的爆发式增长，LTE成为众多运营商选择的主流技术演进方案，这其中包括很多WiMAX运营商和原本属于3GPP2阵营的CDMA运营商。

2009年12月，北欧运营商Telia Sonera在Stockholm和Oslo两个城市开通全球第一个商用的LTE网络。

随后，美国Verizon Wireless、德国Vodafone、日本NTT DoCoMo等领先运营商在2010年相继跟进，LTE的商用进程开始加速。

寻呼优化参数验证报告一、概述目前，在现网中发现VOLTE时延测试较长的问题，通过定点测试发现，在RSRP低且SINR不高的情况下，易导致空口寻呼丢失概率增加，现象表现为UE无法正确解码PDSCH上paging消息。

通过降低寻呼信道码率，打开寻呼信道干扰随机化，提高PDCCH聚合度，使之寻呼信道对SINR的要求降低，达到提升空口寻呼成功概率。

各地分段对比，发现寻呼段是深圳时延短板：IMS侧分析时延不存在明显短板，总处理时延2s：3.2 s ~ 13.1s二、参数修改策略3．1参数解释：三、测试分析4.1 【寻呼信道干扰随机化+降寻呼码率+PDCCH聚合8】对比分析在参数修改前后，进行DT拉网测试对比，路线一致的情况下，得到如下对比指标：VOLTE时延修改前后对比：（1）寻呼优化参数前，寻呼这一段的时长收敛区间在2-3秒间，参数修改后，收敛区间在2s以下。

（2）全部样本平均，参数修改前寻呼时长3.49s，参数修改后3.11s，约400ms增益。

（3）统计不收敛的超长寻呼，（大于4s，寻呼间隔为3s，大于4s大致可说明第二次寻呼才收到）的次数占比，参数修改前是18.0%，参数修改后，为16.5%（4）统计不收敛的超长寻呼，（大于7s，寻呼间隔为3s，大于7s大致可说明第三次寻呼才收到）的次数占比，参数修改前是14.9% ，参数修改后，为8.2%修改前：修改后：PS吞吐率拉网修改前后对比：每RB频谱效率基本相同，说明PS调度基本不受影响:对比修改参数前后，PS拉网吞吐率，没见明显变化4.2 【寻呼信道干扰随机化+降寻呼码率】VOLTE时延修改前后对比：（1）总体平均增益也是维持在400ms左右（这几天核心网在做调整影响，测出来时延总体比之前的长。

修改前4.36，修改后3.97），与之前参数优化增益幅度相同（2）收敛区间不如之前一次参数优化这么明显，（3）统计不收敛的超长寻呼，（大于4s，寻呼间隔为3s，大于4s大致可说明第二次寻呼才收到）的次数占比，参数修改前是36.1%，参数修改后，为29.5%（4）统计不收敛的超长寻呼，（大于7s，寻呼间隔为3s，大于7s大致可说明第三次寻呼才收到）的次数占比，参数修改前是22.2% ，参数修改后，为21.6%修改前：修改后：PS吞吐率拉网修改前后对比：每RB频谱效率基本相同，说明PS调度基本不受影响:四、KPI指标分析数据来源：OMC数据采集时间：8月12日至8月15日参数修改时间为8月13号主要KPI 指标修改参数前后，网格KPI 平稳五、 基本结论1） PDCCH 上应该没有短板，修改与不修改PDCCH 聚合对寻呼解码测试结果影响不多，而码率降低和寻呼干扰随机化优化可以减少寻呼需要重发才收到的比例。