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网络寻呼容量评估1 概述..................................................................................1.1 TAC介绍........................................................................1.2 TAC区约束条件.................................................................2 TAC寻呼能力分析.....................................................................2.1 核心侧MM分析..................................................................2.2 无线侧空口分析.................................................................3 现网分析..............................................................................4 TAC调整建议..........................................................................1概述1.1 TAC介绍LTE网络现行寻呼策略为：精准寻呼+普通的寻呼，即UE上次驻留的eNodeB发起寻呼-＞精准寻呼2S响应超时寻呼下级，最近TAC-＞精准寻呼2S响应超时寻呼下级，TAL-＞精准寻呼2S响应超时重新寻呼，TAL -＞寻呼6S超时后重新寻呼，TAL -＞寻呼6S超时后寻呼失败。

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

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

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

寻呼优化参数验证报告一、概述目前，在现网中发现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 聚合对寻呼解码测试结果影响不多，而码率降低和寻呼干扰随机化优化可以减少寻呼需要重发才收到的比例。

LTE系统主要信令流程引言LTE〔Long Term Evolution〕是第四代移动通信技术，其特点是高速率、低延迟和更高的系统容量。

在LTE系统中，主要的通信过程需要依赖一系列的信令流程来实现。

本文将介绍LTE系统中主要的信令流程，包括系统接入过程、呼叫建立过程以及呼叫释放过程。

一、系统接入过程系统接入是指UE〔User Equipment，用户设备〕首次进入LTE网络时，与网络进行连接的过程。

主要的信令流程如下：1.小区搜寻过程：UE通过接收播送信道上的系统信息，实现对可用小区的搜寻。

系统信息包括小区标识、频率等信息。

2.小区选择过程：UE根据接收到的系统信息，选择适合自身的小区。

这个过程主要考虑小区的信号质量、信号强度等因素。

3.小区注册过程：UE选择了目标小区后，需要向目标小区进行注册。

UE通过随机访问信道发送带有身份信息的接入请求，目标小区收到请求后进行验证和鉴权。

4.分配临时标识过程：目标小区验证通过后，为UE分配临时的标识，用于后续的通信过程中的身份认证。

同时，UE也会得到小区的系统信息。

5.RRC连接过程：UE和目标小区建立RRC〔Radio Resource Control，无线资源控制〕连接。

在RRC连接建立后，UE可以与网络进行通信。

呼叫建立过程是指在LTE网络中，UE发起呼叫并与目标终端进行连接的过程。

主要的信令流程如下：1.呼叫请求过程：UE向网络发起呼叫请求。

呼叫请求中包含被叫号码、呼叫类型等信息。

2.寻呼过程：网络收到呼叫请求后，根据被叫号码进行寻呼。

寻呼过程可以通过播送信道或者专用的寻呼信道进行。

3.寻呼回应过程：被叫终端收到寻呼信息后，发送回应给网络。

回应中包含被叫终端的临时标识等信息。

4.呼叫建立过程：网络收到寻呼回应后，根据被叫终端的临时标识，与被叫终端建立起连接。

连接建立后，就可以进行语音或数据传输。

呼叫释放过程是指在LTE网络中，呼叫结束后双方终止连接的过程。

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的动态分配使得⽹络负荷得到了平衡。

像其他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。

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的个数来计算得出。