LTE寻呼

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 次/秒特殊场景（如大型活动、比赛现场），需要对某些小区的寻呼参数进行优化调整，可以采用的方案如下：–n B：增大nB ，提高小区寻呼容量，减少寻呼拥塞，如nB→2T/4T–T：T 值越大，寻呼时延越长，寻呼组增加，每个寻呼信道中的用户越少，反之寻呼时延缩短，每个寻呼信道用户增加，可能导致某个时刻一个寻呼组寻呼的用户超过16 个，反而增加的寻呼时延，因此，可以根据实际用户的数量，调整T 值。

LTE外场寻呼事情事件处理经验与手段摘要本文库文档旨在分享关于LT E外场寻呼事情事件处理的经验与手段。

通过探讨寻呼事情事件的背景和重要性，介绍处理此类事件的步骤和技巧，并提供实用的解决方案。

导言随着LT E技术的发展，寻呼事情事件在L TE外场网络中变得越来越普遍。

了解并有效处理这些事件对于维护网络性能和提供优质服务至关重要。

本文将探讨如何识别和处理L TE外场寻呼事情事件，并分享解决问题的经验与技巧。

1.寻呼事情事件背景L T E外场网络中的寻呼事情事件指的是发生在网络中的寻呼消息传输不成功或有延迟的情况。

这种事件可能导致通信中断、呼叫失败、网络容量低下以及用户不满等问题。

因此，及时准确地处理寻呼事情事件对于网络运营商至关重要。

2.寻呼事情事件处理步骤针对LT E外场寻呼事情事件，以下是一些处理步骤的建议：2.1事件识别首先，需要通过网络监控系统或分析工具来识别寻呼事情事件。

通过监测数据和指标，可以确定是否存在寻呼消息传输不成功或有延迟的情况。

2.2问题定位一旦识别出寻呼事情事件，需要进一步确定问题的具体位置和原因。

这可能需要对网络设备、信号传输和配置进行详细的分析和排查。

2.3数据分析在问题定位的基础上，进行深入的数据分析，以了解寻呼消息在何处丢失或延迟。

通过对相关数据的仔细检查，可以确定潜在的故障点并找出解决方案。

2.4故障排除一旦确定了故障点，需要采取相应的措施来解决问题。

可能的解决方案包括调整网络配置、更新软件版本、优化信号传输或设备更换等。

2.5维护和监控处理寻呼事情事件后，应定期进行维护和监控，以确保问题的持续解决和网络的健康运行。

及时跟踪和处理事件可以有效减少用户投诉和提高网络性能。

3.寻呼事情事件处理技巧为了更高效地处理LT E外场寻呼事情事件，以下是一些实用的技巧：3.1建立应急响应流程创建一套完善的应急响应流程，包括事件识别、问题定位、数据分析和故障排除等环节。

在实际操作中，运营商可以通过培训和模拟演练来提高团队的应急响应能力。

The UE may use Discontinuous Reception (DRX) in idle mode in order to reduce power consumption. One Paging Occasion (PO) is a subframe where there may beP-RNTI transmitted on PDCCH addressing the paging message. One Paging Frame (PF) is one Radio Frame, which may contain one or multiple Paging Occasion(s). When DRX is used the UE needs only to monitor one PO per DRX cycle.PF and PO is determined by following formulae using the DRX parameters provided in System Information:PF is given by following equation:SFN mod T= (T div N)*(UE_ID mod N)Index i_s pointing to PO from subframe pattern defined in 7.2 will be derived from followingcalculation:i_s = floor(UE_ID/N) mod NsSystem Information DRX parameters stored in the UE shall be updated locally in the UE whenever the DRX parameter values are changed in SI. If the UE has no IMSI, for instance when making an emergency call without USIM, the UE shall use as default identity UE_ID = 0 in the PF and i_s formulas above.The following Parameters are used for the calculation of the PF and i_s: - T: DRX cycle of the UE. T is determined by the shortest of the UE specific DRX value, if allocated by upper layers, and a default DRX value broadcast in system information. If UEspecific DRX is not configured by upper layers, the default value is applied.- nB: 4T, 2T, T, T/2, T/4, T/8, T/16, T/32.- N: min(T,nB)- Ns: max(1,nB/T)- UE_ID: IMSI mod 1024.IMSI is given as sequence of digits of type Integer (0..9), IMSI shall in the formulae above be interpreted as a decimal integer number, where the first digit given in the sequence represents the highest order digit.For example:IMSI = 12 (digit1=1, digit2=2)In the calculations, this shall be interpreted as the decimal integer "12", not "1x16+2 = 18".PCCH-Config ::= SEQUENCE {defaultPagingCycle ENUMERATED {rf32, rf64, rf128, rf256}, nB ENUMERATED {fourT, twoT, oneT, halfT, quarterT, oneEighthT,oneSixteenthT, oneThirtySecondT}。

L T E网络寻呼容量评估 Revised by Petrel at 2021LTE网络寻呼容量评估目录1概述....................................................................................................................................................TAC介绍.....................................................................................................................................TAC区约束条件 ......................................................................................................................... 2TAC寻呼能力分析 ..............................................................................................................................核心侧MME分析 .........................................................................................................................无线侧空口分析 ....................................................................................................................... 3现网分析............................................................................................................................................ 4TAC调整建议......................................................................................................................................1概述1.1TAC介绍LTE网络现行寻呼策略为：精准寻呼+普通的寻呼，即UE上次驻留的eNodeB发起寻呼->精准寻呼2S响应超时寻呼下级，最近TAC ->精准寻呼2S响应超时寻呼下级，TAL->精准寻呼2S响应超时重新寻呼， TAL ->寻呼6S超时后重新寻呼，TAL ->寻呼6S超时后寻呼失败。

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。

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）。

VOLTE寻呼拥塞分析优化案例一、案例背景VOLTE（Voice over LTE）是指通过LTE网络进行语音通信的技术，它提供了高质量的语音通话和丰富的通话功能。

然而，在实际网络运营中，由于网络拥塞等原因，VOLTE寻呼过程中可能浮现延迟或者失败的情况，影响用户的通话体验。

因此，我们需要进行VOLTE寻呼拥塞分析优化，以提高寻呼成功率和通话质量。

二、问题分析1. 寻呼拥塞原因分析：我们需要对VOLTE寻呼拥塞问题进行深入分析，找出导致寻呼失败或者延迟的具体原因。

可能的原因包括网络拥塞、信号覆盖不足、信道干扰等。

2. 寻呼成功率分析：对于寻呼成功的情况，我们需要分析成功率，并根据不同地区、时间段等因素进行对照分析，找出成功率较低的地区或者时间段，并进一步分析原因。

3. 通话质量分析：除了寻呼成功率外，我们还需要分析VOLTE通话质量，包括音质、时延、丢包率等指标。

通过对通话质量的分析，我们可以找出影响通话质量的因素，并进行优化。

三、数据采集与分析1. 数据采集：我们需要采集VOLTE寻呼过程中的相关数据，包括寻呼请求次数、寻呼成功次数、寻呼失败次数、寻呼延迟时间、通话质量指标等。

这些数据可以通过网络监测设备、基站设备、用户设备等进行采集。

2. 数据分析：采集到的数据需要进行详细的分析，包括寻呼成功率的计算、寻呼延迟时间的统计、通话质量指标的计算等。

通过对数据的分析，我们可以找出问题所在，并制定相应的优化方案。

四、优化方案1. 网络优化：针对网络拥塞问题，我们可以通过增加基站、优化网络参数、调整信道分配等手段来提高网络容量和覆盖范围，从而减少寻呼拥塞情况的发生。

2. 信号优化：对于信号覆盖不足的问题，我们可以通过增加基站或者调整天线方向来改善信号覆盖情况，提高寻呼成功率。

3. 干扰处理：针对信道干扰问题，我们可以通过频谱分析、干扰源定位等手段来找出干扰源，并采取相应的干扰消除措施，提高寻呼成功率和通话质量。

7.6 LTE寻呼7.6.1寻呼概述网络可以向空闲状态发送寻呼，也可以向连接状态的UE发送寻呼。

寻呼过程可以由核心网触发，也可以由eNodeB触发。

在LTE网络中，发送寻呼主要有如下几种场景（1）发送寻呼信息给RRC_IDLE状态的UE。

这种情况下寻呼过程是由核心网触发，用于通知某个UE接收寻呼请求（2）通知RRC_IDLE/RRC_CONNECTED状态下的UE系统信息改变。

这种情况下寻呼过程是由eNodeB触发，用于通知系统信息更新。

（3）通知UE关于ETWS（地震、海啸预警系统）信息。

寻呼还可以发送地震、海啸预警系统信息、商业移动告警服务。

（4）通知UE关于CMAS（商业移动告警服务）通知信息。

7.6.2寻呼过程处于Idle模式下的终端，根据网络广播的相关参数使用非连续接收（DRX）的方式周期性地去监听寻呼消息。

终端在一个DRX的周期内，可以只在相应的寻呼无线帧上的寻呼时刻先去监听PDCCH上是否携带有P—RNTI，进而去判断相应的PDSCH上是否有承载寻呼消息。

如果在PDCCH上携带有P—RNTI，就按照PDCCH 上指示的PDSCH的参数去接收PDSCH物理信道上的数据；而如果终端在PDCCH上未解析出P—RNTI，则无需再去接收PDSCH物理信道，就可以依照DRX周期进入休眠。

寻呼DRX是指处在RRC空闲状态的UE不连续地监测寻呼信道（PCH）。

它的主要优点就是实现手机较低功耗、较低的延迟和较低的网络负荷。

在连接（Connected）模式下，终端需要根据网络配置的相关参数（如Short DRX Cycle和Long DRX Cycle等）周期性地去监听PDCCH信道。

7.6.3寻呼帧和寻呼时机RRC_IDLE状态下的UE在特定的子帧（1ms）监听PDCCH，这些特定的子帧称为寻呼时机（PO，Pag-ing Occasion），这些子帧所在的无线帧（10ms）称为寻呼帧（PF，Paging Frame）。

竭诚为您提供优质文档/双击可除lte,寻呼协议篇一：td-lte系统的寻呼机制与容量td-lte系统的寻呼机制与容量寻呼是移动通信的关键过程，对于空闲状态（RRc-idle）的终端，系统使用寻呼类型1消息（pagingtype1）通过公共信道寻呼ue；对于连接状态下（RRc-connected）的终端，系统使用寻呼类型2消息（pagingtype2）直接在业务信道上通知ue。

一、寻呼消息lte系统中的寻呼消息中可以携带三类参数：寻呼的终端id列表、系统消息改变指示标识及地震海啸预警指示标识（etws）。

pagingmessagepaging::=sequence{ pagingRecordlistpagingRecordlistoptional,--needonsysteminfomodificationenumeRated{true}optional,--ne edonetws-indicationenumeRated{true}optional,--needon noncriticalextensionpaging-v890-iesoptional}paging-v890-ies::=sequence{latenoncriticalextensionoctetstRingoptional,--needo pnoncriticalextensionpaging-v920-iesoptional}paging-v920-ies::=sequence{cmas-indication-r9enumeRated{true}optional,--needon noncriticalextensionsequence{}optional--needop }pagingRecordlist::=sequence(size(1..maxpageRec))oFp agingRecordpagingRecord::=sequence{ue-identitypagingue-identity,cn-domainenumeRated{ps,cs},...}pagingue-identity::=choice{s-tmsis-tmsi,imsiimsi,...}1.寻呼的终端id列表根据lte规范，寻呼消息最多可以携带16个ue_id。

LTE寻呼和TAU篇3-TAC与TA List问题3、LTE⽹络中引⼊的TAC来替代2/3G时代的LAC，但同时⼜引⼊了TA List作为寻呼和位置更新的位置范围，那么，为什么要引⼊TA List？LTE中的TAC跟2/3G中的LAC的概念基本相同，在不考虑TA List的情况下，TAC就是位置区更新（TAU）和寻呼的基本区域。

但LTE中同时⼜引⼊了TA List （或者叫TAC List）的概念，是TAC的⼀个组合，每⼀个TA List包含1个或多个TAC，LTE ⽹络中的UE的基于位置变化的位置更新就基于TA List⽽触发的，寻呼也是针对于UE所在的TA List⽽进⾏的。

但从上⾯的概念来看，TA List⽆⾮就是扩⼤了的TAC，有什么价值呢？实际上，TA List和以前的LAC区是两个不同的概念。

虽然在进⾏⽹络规划的时候，也是需要对⽹络进⾏TAC的规划，也需要对TA List进⾏规划，但TA List的概念却是在⽤户业务或移动当中动态变化的，并且是由MME来进⾏动态的分配的。

每个⼩区指定属于某个TAC，但是某个TAC可以属于不同的TA List，当UE处于某个TAC的时候，它可能被分配在TA List1中，也可能被分配到TA List2中等等。

那么MME会根据什么来对⼀个UE分配不同的TA List呢？最典型的就是通过动态的TA List的分配对⽤户的TAU的群体的⾏为进⾏控制。

⽐如说，当某个⾼铁⼏百个⽤户同时进⼊到⼀个新的TAC，那么这些UE可能会在很短的时间内同时发起TAU，所在⼩区的⽹络负荷会很⼤。

那么MME检测到这种变化，当这些UE从TAC1全部进⼊到TAC2的时候，其中⼀部分⽤户之前被分配了包含TAC1和TAC2的TA List1中，这部分⽤户不需要进⾏TAU，⽽另⼀部分⽤户，被分配了只包含TAC1的TA List2中，这样这⼀部分⽤户进⼊到TAC2的时候就需要进⾏TAU。

所以，通过TA List的动态分配使得⽹络负荷得到了平衡。

LTEERAN信令流程之寻呼流程1.1 寻呼知识概述在以下三种场景下，eNB需要在空口发起寻呼。

上层在收到寻呼信息后，有可能会触发RRC连接建立过程，用于作为被叫接入。

（1）网络侧要发送数据给处于RRC_IDLE状态UE；（2）用于通知处于RRC_IDLE和RRC_CONNECTED状态的UE 系统消息改变时；（3）网络侧通知UE当前有ETWS主通知或从通知时；寻呼消息根据使用场景既可以由MME触发也可以由eNodeB触发。

MME发送寻呼消息时，eNodeB根据寻呼消息中携带的UE的TAL信息，通过逻辑信道PCCH向其下属于TAL的所有小区发送寻呼消息寻呼UE。

寻呼消息中包含指示寻呼来源的域，以及UE标识，UE 标识可以是S-TMSI或者IMSI。

系统消息变更时，eNodeB将通过寻呼消息通知小区内的所有EMM注册态的UE，并在紧随下一个系统消息修改周期中发送更新的系统消息。

eNodeB要保证小区内的所有EMM注册态UE能收到系统消息，也就是eNodeB要在DRX周期下所有可能时机发送寻呼消息。

两者触发源虽然不一样，但在空口的寻呼机制是一样的。

1. 空口寻呼机制空闲状态下，UE以DRX（Discontinuous Reception）方式接收寻呼信息以节省耗电量。

寻呼信息出现在空口的位置是固定的，以寻呼帧PF (Paging Frame)和寻呼时刻PO（Paging Occasion)来表示。

如0所示，一个寻呼帧PF是一个无线帧，可以包含一个或多个PO。

寻呼时刻PO是寻呼帧中的一个子帧，其中包含P-RNTI（Paging Radio Network Temporary Identity）的信息，在PDCCH上传输。

P-RNTI在协议中被定义为固定值。

UE将根据P-RNTI从PDSCH上读取寻呼消息。

寻呼机制示意图如下：PF的帧号和PO的子帧号可通过UE的IMSI、DRX周期以及DRX 周期内PO的个数来计算得出。

像其他GSM、WCDMA系统一样，LTE系统在空闲态UE使用DRX（不连续接收-睡眠、唤醒机制）功能减少功率消耗，增加电池寿命。

为了达到这一目的，UE从SIB2中获取DRX 相关信息，然后根据DRX周期UE监测PDCCH信道，查看是否有寻呼消息，如果PDCCH 信道指示有寻呼消息，那么UE解调PCH信道去看寻呼消息是否属于自己。

在这个过程，UE如何根据DRX周期确认在哪一无线帧、哪一子帧去监测PDCCH信道？寻呼时刻（PO)如何获取呢？通常为了计算PO分为两步。

第一步、寻呼帧位置确认。

根据下面公式求得：寻呼帧位置PF = SFN mod T= (T div N)*(UE_ID mod N)其中 SFN：系统帧号，当前UE所在帧号T：T=min（Tc，Tue），其中Tc，Tue 分别表示核心网和无线侧设置的寻呼周期，一般情况无线侧的寻呼周期小于核心网周期，默认等于无线侧寻呼周期DefaultPagingCycle，该参数从SIB2中读取。

而Tc从S1的寻呼消息中获取。

N：N=min(T,nB)，nB从SIB2中读取。

UE_ID:包含在S1的寻呼消息中，通过IMSI模1024计算得到。

第二步、寻呼时刻的确认寻呼时刻：即寻呼帧所在位置对应的子帧号，该时刻不是通过计算得到，而是通过NS与I_s对应关系获取。

对应关系如下表1、2.其中表1为FDD模式，表2为TDD模式。

其中：Ns：Ns =max(1,nB/T)，其中nB，T都是通过SIB2获得。

i_s ：i_s = floor(UE_ID/N) mod Ns。

UE_ID从S1消息中获取，N通过SIB2中信息计算得到。

下面举例说明寻呼帧与寻呼时刻的计算。

例如：如下表，现网中DefaultPagingCycle设置为128，则T=128;nB设置为T，即128，那么N=128；Ns=1.第一步，算寻呼帧位置：假设用户的IMSI= 448835805669362，则根据公式求得。

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值。

TD-LTE系统的寻呼机制与容量寻呼是移动通信的关键过程，对于空闲状态（RRC-IDLE）的终端，系统使用寻呼类型1消息（PAGING TYPE1）通过公共信道寻呼UE；对于连接状态下（RRC-CONNECTED）的终端，系统使用寻呼类型2消息（PAGING TYPE2）直接在业务信道上通知UE。

一、寻呼消息LTE系统中的寻呼消息中可以携带三类参数：寻呼的终端ID列表、系统消息改变指示标识及地震海啸预警指示标识（ETWS）。

Paging messagePaging ::= SEQUENCE {pagingRecordList PagingRecordList OPTIONAL, -- Need ONsystemInfoModification ENUMERATED {true} OPTIONAL, -- Need ONetws-Indication ENUMERATED {true} OPTIONAL, -- Need ONnonCriticalExtension Paging-v890-IEs OPTIONAL}Paging-v890-IEs ::= SEQUENCE {lateNonCriticalExtension OCTET STRING OPTIONAL, -- Need OPnonCriticalExtension Paging-v920-IEs OPTIONAL}Paging-v920-IEs ::= SEQUENCE {cmas-Indication-r9 ENUMERATED {true} OPTIONAL, -- Need ONnonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP}PagingRecordList ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecordPagingRecord ::= SEQUENCE {ue-Identity PagingUE-Identity,cn-Domain ENUMERATED {ps, cs},...}PagingUE-Identity ::= CHOICE {s-TMSI S-TMSI,imsi IMSI,...}1. 寻呼的终端ID列表根据LTE规范，寻呼消息最多可以携带16个UE_ID。