W网规高培寻呼问题分析

,WCDMARNO寻呼问题分析,前言,寻呼是网络联系UE的重要途径，和其它流程相比较，寻呼流程在无线网络中表现出频率高、流量大、突发性强等特点，寻呼性能关系到整个无线网络的性能。所以研究寻呼问题对无线网络性能具有很强的现实意义。,课程目标,寻呼问题的分析流程寻呼问题的典型案例,学习完本课程，您将能够熟悉：,概述,如果网络侧需要主动联系处于空闲模式、CELL_PCH或者URA_PCH状态的UE，就要发起寻呼流程，寻呼是网络联系UE的重要途径。和其它流程相比较，寻呼流程在无线网络中表现出频率高、流量大、突发性强等特点，寻呼性能关系到整个无线网络的性能，所以研究寻呼问题对无线网络性能具有很强的现实意义。从UE接收寻呼消息的角度来看，寻呼消息分为PAGINGTYPE1和PAGINGTYPE2，由UTRAN决定发送给UE的寻呼类型。PAGINGTYPE1是通过PCCH逻辑信道来寻呼处在IDLE，CELL_PCH，URA_PCH状态的UE。PAGINGTYPE2是通过DCCH来寻呼处在CELL_FACH，CELL_DCH状态的UE。,概述,网络侧会在以下情况下发起寻呼：UE被叫；小区系统消息更新；UE状态迁移；一个典型的由寻呼引起的被叫流程如下图所示。寻呼过程中可能会存在种种问题导致目标UE不能正确收到寻呼消息，如在网络群发短消息和全文寻呼时，不合理的寻呼策略会使得寻呼信道拥塞从而造成寻呼消息大量丢失，严重情形下还会造成系统长期过载，寻呼信道功率配比过低造成寻呼成功率低。本文将对这些导致寻呼异常的问题进行深入分析，并给出其解决方法。,概述,UE被叫流程图：,课程内容,T,第一章寻呼问题的分析流程第二章寻呼问题的典型案例,第一章寻呼问题的分析流程,第一节分析流程第二节信息收集第三节问题定位第四节优化验证,分析流程,分析流程,寻呼问题分析流程如图所示，大体分为以下几个步骤：网络信息收集：收集网络与寻呼相关话统、告警、用户投诉、网络规划和优化记录、网络参数配置等信息；确定优化目标：确定寻呼问题优化的KPI指标；寻呼问题定位：定位导致寻呼问题的原因；寻呼问题优化：根据定位结果采用相应的优化调整措施；优化验证：验证优化后的KPI指标是否达到要求以及其它寻呼相关信息是否正常。,第一章寻呼问题的分析流程,第一节分析流程第二节信息收集第三节问题定位第四节优化验证,信息收集,网络信息收集是寻呼问题分析的第一步，优化人员要获取待优化网络中与寻呼相关的话统、用户投诉、告警、网络规划优化历史记录、无线参数配置等等信息，为后续进一步的深入分析做准备。需要收集的信息主要包括以下几个方面：话统告警用户投诉优化历史记录参数配置,信息收集,话统寻呼相关的话统指标可以根据不同的寻呼区域分别在RNC、UMSC、SGSN话统台上观测；RNC话统对应一个RNC区域，UMSC话统对应一个位置区，SGSN话统对应一个路由区。在实际话统分析过程中需要把RNC和CN的话统数据结合起来分析。RNC的话统中，需要关注“CN_PAGE_IDLE_UE_SUCC_RATE”和“UTRAN_PAGE1_SUCC_RATE”，这两个指标基本表征了RNC对应寻呼区域的寻呼成功率；前者从CN的角度考察了寻呼的成功率，后者除了包含CN寻呼情况外，还包含UTRAN系统消息更新和UE状态迁移两种情况。这两个指标可以用来分析一个RNC区域的寻呼性能，一个RNC区域一般包括多个位置区。,信息收集,话统UMSC寻呼相关话统指标都是基于一个位置区的。一般情况下，位置区不会跨RNC、BSC配置，可以统计一个位置区的寻呼成功率、第一次寻呼成功率、非第一次寻呼成功率。位置区的寻呼成功率关注一个位置区的寻呼状况，并不关心寻呼重发次数，而第一次寻呼成功率、非第一次寻呼成功率关注寻呼重发次数对寻呼成功率的影响。SGSN寻呼相关话统指标都是基于一个路由区的，可以得到某路由区的寻呼成功率。在话统分析过程中，要重点关注“位置区寻呼成功率”和“路由区寻呼成功率”，这是衡量寻呼性能的注意KPI指标。,信息收集,告警按照目前我司的实现，CN和寻呼相关的告警只有“RNC过载”，当CN接收到RNC的过载消息引发此告警。RNC为保证系统运行的稳定性，避免突发的消息风暴对系统的冲击，对包括寻呼在内的某些处理频率很高的消息进行了流控。当RNC收到CN的寻呼消息后，判断系统如果处于寻呼流控状态，就会丢弃寻呼消息，并记录下寻呼消息丢失的个数。如果寻呼丢失比例达到一定的门限，RNC就会向CN发Overload消息，CN就会控制消息发送流量按照一定的步长减少。如果在一定的时间内没有收到Overload消息，IU的消息流量会逐步增长直至恢复正常。RNC目前寻呼相关的告警是“流量控制告警”，当RNC处于寻呼流控状态下寻呼消息会无条件丢失。当系统从流控状态恢复时，会产生流量“控制恢复告警”。,信息收集,用户投诉如果寻呼消息丢失导致手机不能做被叫，主叫用户会听到系统提示音“用户不在服务区”。可以客户处了解用户投诉情况或直接联系投诉人了解不在服务区发生情况，要重点关注手机被叫失败的情况。整理投诉信息，寻找规律，观察是否存在下属情况：是否忙时和闲时都发生；如果寻呼失败在话务高峰，重点分析寻呼拥塞的情形，如果不是在话务高峰，要分析其它因素；是否被叫手机类型相同，可能存在手机自身问题；是否投诉地点集中，可能是因为信号覆盖问题；找到投诉的规律能加快问题解决的速度。,信息收集,优化历史记录获取网络规划报告，重点关注寻呼区域（位置区、路由区）的划分。规划报告应包括网络所经历各次扩容的规划报告。对于开通后网络，可能在本次优化之前已经经历了优化过程，在本次优化开始之前应获得各次优化历史记录，了解各次网络调整过程及遗留问题。应重点关注是否存在覆盖空洞、系统过载、寻呼丢失、寻呼信道功率配比低等方面的优化记录。,信息收集,参数配置和寻呼相关的参数如下，优化前要注意收集：CN寻呼重发次数、寻呼时间间隔；UTRAN寻呼重发次数、寻呼时间间隔；DRX寻呼周期系数k（DRX寻呼周期=2k）；一个PICH帧包含的寻呼指示数目NP；PICH、PCH信道功率配比；CN是否使用全局寻呼；CN寻呼使用的UEID（是IMSI还是TMSI、PTMSI）；,确定优化目标,确定优化KPI目标：位置区寻呼成功率路由区寻呼成功率“位置区寻呼成功率”和“路由区寻呼成功率”这两个KPI指标要达到优化要求，如寻呼成功率达到86%以上。,第一章寻呼问题的分析流程,第一节分析流程第二节信息收集第三节问题定位第四节优化验证,问题定位,确定定位方向寻呼问题优化目的是保证寻呼的KPI指标，UE能否成功回寻呼响应直接关系到寻呼的KPI指标。从这个角度上看，寻呼问题可以分为以下三个方向：寻呼消息根本没有在空口下发；最大的可能是寻呼丢失，也是寻呼过程中最常见的问题。具体分析见随后两节。寻呼消息下发，UE没有收到或者是收到错误的寻呼消息；按照用户投诉的情况具体区分，如果只是UE作被叫有问题，可能是PICH和PCH的功率配比过低或手机性能有问题；如果UE主叫被叫都有问题，可能该区域存在信号覆盖盲区。UE收到寻呼后回寻呼响应失败；属于接入失败的问题，解决方法参考“接入过程问题分析”。,问题定位,确定定位方向在寻呼问题定位过程中，可以通过分析寻呼话统、告警和用户投诉来确定。寻呼丢失一般发生在话务量高的时间段，查看CN的话统“位置区寻呼成功率”和“路由区寻呼成功率”，如果这两个指标总是在话务量高的时间段表现得比较低，用户投诉也是集中在这一时间段，则说明寻呼丢失较严重，需要重点分析寻呼丢失的原因。同时查看CN是否有RNC过载告警、RNC是否有流控告警，如果有这些告警存在说明寻呼丢失的可能性很大。如果这两个指标低的事件在时间上近似均匀分布，用户投诉具有地域性，就要检查除“寻呼丢失”外的原因了，如寻呼信道配比、信号覆盖、手机性能等。进一步分析寻呼问题需要到现场进行拨测分析，时间选择在话务量高的时间段，地点选择用户投诉集中的区域，拨测过程中可以在CN和RNC的维护台上跟踪寻呼消息的下发和UE回寻呼响应的过程。,问题定位,寻呼丢失原因寻呼在以下情况下会丢失：RNC系统处于寻呼流控状态。当RNC检查到CPU占有率或者消息队列占有率达到预先设置的门限时，就会触发寻呼流控，在寻呼流控状态下寻呼消息无条件丢弃。PCH容量限制。以PCH目前的编码方式，一个TTI只能传输240bits，如果使用IMSI寻呼，同一寻呼时刻只能寻呼3个UE；如果使用TMSI和PTMSI寻呼，同一寻呼时刻只能寻呼5个UE；如果在同一寻呼时刻寻呼UE的个数超过系统的处理能力，就会造成寻呼丢失。其它原因，如IUB口传输故障和设备故障等，这类故障发生几率小，会有相应告警伴随。,问题定位,丢失原因分析导致寻呼丢失的直接原因是系统过载、寻呼信道过载等，进一步地深入分析其原因可能是CN和RNC使用了不适当的寻呼策略，主要表现在以下几个方面：寻呼区域规划过大CN寻呼重发次数和时间间隔设置不合理UTRAN寻呼重发次数和时间间隔设置不合理CN使用了全网寻呼DRX寻呼周期系统设置不合理NP值设置不合理CN使用的UE标识不合理详细的分析参见后面的案例。,问题定位,其它原因分析可能存在的其它方面的原因有：寻呼类信道功率配比过低存在覆盖盲区手机性能问题详细的分析参见后面的案例。,第一章寻呼问题的分析流程,第一节分析流程第二节信息收集第三节问题定位第四节优化验证,问题优化,针对各个专题的寻呼问题优化方法详见第二章节的描述。,优化验证,在对网络实施了优化调整后，需要验证优化的结果：话统：查看“位置区寻呼成功率”和“路由区寻呼成功率”是否达到预定的优化目标；告警：查看CN是否有“RNC过载”告警，RNC是否有流控告警；用户投诉：在一段时间内是否有用户被叫投诉；拨测：选择话务高峰期和用户投诉地测试手机被叫成功率，拨测不需要接通，电话只需要听回铃音或提示音即可。,课程内容,T,第一章寻呼问题的分析流程第二章寻呼问题的典型案例,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,寻呼区域规划过大,现象与分析CN通常在一个寻呼区域（位置区或者路由区）对目标UE进行寻呼，这种寻呼又称作本局寻呼。对CS域业务来说，CN使用位置区来识别和寻呼UE，位置区被定义为移动终端在不更新VLR的情况下可以自由移动的区域，一个位置区可以涵盖一个或几个小区。对PS域业务来说，CN使用routingarea来识别和寻呼UE，RA定义为在特定操作模式下，移动终端不需要更新SGSN的情况下可以自由移动的区域，一个RA可以包含一个或几个小区。路由区和位置区的关系采用了GSM中定义的关系，即：路由区可以和位置区的大小相等，或者只是某个位置区的子集。,寻呼区域规划过大,现象与分析如果寻呼区域规划过大，网络寻呼移动台的同一寻呼消息会在许多小区中发送，会导致寻呼信道负荷过重，同时增加Iub接口上的信令流量。如果小区的寻呼信道在一段时间内负荷过重，会导致寻呼该小区UE的寻呼消息被丢掉，造成在服务区内的开机用户不能被寻呼到（用户不在服务区）问题。反之，如果寻呼区域规划过小，那么会造成用户在移动过程进行频繁的位置更新，从而增加系统的信令流量，频繁的位置更新会影响手机的待机时间。对于建网初期，PS业务寻呼需求不大，此时RA不需要刻意划分的过小，可按照n1来规划。随着网络的不断演进，PS业务的需求不断增多，这时候可适当减小RA的大小。优化措施对网络容量或寻呼量大于一定门限的位置区进行位置区分裂，可以有效降低寻呼消息流量。,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,CN寻呼参数设置不合理,现象与分析CN为保证寻呼成功率，会在IU接口重发寻呼消息，CN寻呼重发次数和时间间隔是可以配置的。寻呼重发造成寻呼量成倍增加，浪费下行信道资源。CN的寻呼重发配置应该和UTRAN协调起来。CN的寻呼重发是为防止第一次寻呼手机未正常响应而再次发起寻呼，提高寻呼成功率和接通率。但是GSM网上数据表明，重发寻呼的成功率比较低，特别是二次及二次以上重发，对寻呼成功率和接通率的贡献很小。经验数据表明：一般第一次寻呼成功率接近86%，重复寻呼成功率1.8%，其中重发寻呼成功大部分为二次寻呼成功，三次寻呼成功的次数按递减的规律计算，其寻呼成功率估计在0.2%以下。WCDMA的寻呼机制和GSM基本类似，从网上统计数据可以看出，CN寻呼次数太多对寻呼成功率的贡献很小，相反增加了系统负荷。,CN寻呼参数设置不合理,现象与分析CN的寻呼时间间隔不宜过短。CN通过IU接口发寻呼消息给RNC，RNC根据寻呼消息带的IMSI计算出寻呼时刻，并安排在最近一个寻呼周期对应的寻呼时刻下发。目前我司的RNC也采用了寻呼重发机制，缺省是重发1次，重发时间间隔是一个寻呼周期。从上述分析来看，RNC从收到CN的寻呼到下发到空口的最大时间间隔是一个寻呼周期，在RNC重发1次的情况下，CN的寻呼时间间隔要大于两个寻呼周期为宜。目前我司实现的寻呼周期是2.56s，如果CN的寻呼时间间隔大于2.56s小于5.12，在CN重发寻呼到来时，RNC还没有完成寻呼的重发，RNC处理的结果是在紧接着的下一个寻呼周期安排寻呼，这样实际上只发了3个寻呼消息，没有达到预计的4个寻呼消息，造成了寻呼消息在无形中丢失。,CN寻呼参数设置不合理,优化措施CN的寻呼重发配置应该和UTRAN互相配合。在UTRAN寻呼重发1次的情况下，建议CN配置重发1次（总共发2次），重发时间间隔大于两个寻呼周期。减少寻呼重发次数同时增大寻呼时间间隔，整体寻呼无响应的时间基本保持不变，不会影响MSC寻呼无响应时上报语音提示的时间间隔。CN寻呼时间间隔和重发次数可以通过软参进行配置。,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,UTRAN寻呼参数设置不合理,现象与分析为了减少Iu口寻呼消息流量，增加UE接收到寻呼消息的可能性，UTRAN可以重复发送寻呼消息，UTRAN寻呼重发配置要与CN寻呼重发相配合。由于寻呼总是在固定的寻呼时刻（一个寻呼周期内）下发，UTRAN寻呼时间间隔为一个寻呼周期的整数倍，一般为一个寻呼周期，所以可以通过调整DRC寻呼周期系数k，来调整UTRAN的寻呼重发时间间隔。UTRAN寻呼重发次数不宜过大，否则加上Iu口寻呼重发，Uu口寻呼信道负荷会剧增。另外，目前UTRAN在MACC层实现，MACC不识别具体的RRC消息，即使UE回了寻呼响应消息，MACC还会继续重发寻呼。优化措施寻呼重发次数保持目前的缺省配置比较合理。,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,CN使用了全网寻呼,现象与分析出于提高来话接通率的考虑，CN侧一般可配置全网寻呼。这种寻呼方式的最大特点是寻呼跨越位置区的概念，针对全CN下挂的所有的UTRAN发起。这种情况下的寻呼流量更大，特别是当CN下挂多个位置区的时候，容易导致容量较小的位置区出现过载，并且长时间无法恢复。优化措施CN应该避免采用全局寻呼。根据GSM网上应用经验，CN的全网寻呼是造成容量较小的位置区出现过载的重要原因。CN的全局寻呼仅在VLR记录UE位置区错误的情况有用，而这种情况极少发生，而且一旦发生，则表示系统出现重大故障。,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,DRX寻呼参数设置不合理,现象与分析当UE处在IDLE和PCH状态时，为了减少功率的消耗UE会利用不连续接收技术DiscontinuousReception（DRX）。根据协议TS25.304，寻呼周期长度（DRXcyclelength）=MAX（2k，PBP）。其中：K为”DRXcyclelengthcoefficient”，PBP为寻呼块周期”PagingBlockPeriodicity”，对于FDD，PBP=1，所以DRXcyclelength=2K。UE的DRX寻呼有三个来源：系统消息、CN的寻呼消息、UTRAN的UU口信令，并且CS、PS的处理方式也不一样。对于PS域，DRX寻呼周期系数由UE和SGSN通过NAS层消息（attach过程）协商，不管UE处于IDLE或者是connect都以协商数据为准，如果协商失败则使用CS域的寻呼系数。对于CS域，如果UE在IDLE状态下，DRX寻呼周期系数使用系统消息、CN的寻呼消息中的最小值，如果UE在连接状态，DRX寻呼周期系数使用系统消息、CN的寻呼消息、UTRAN的UU口信令中的最小值。,DRX寻呼参数设置不合理,现象与分析DRX寻呼周期系数K的设置，主要考虑以下因素：DRX寻呼周期系数K决定了DRX周期长度，K值越大，DRX周期就越长，UE功耗会降低，但是也带来了UE寻呼周期变长。如果K值过小，寻呼周期变小，UE处理寻呼开销和功耗都会增加。协议给出取值范围为212，目前建议取值8，寻呼周期为2.56秒。以PCH目前的编码方式，一个TTI只能传输240bits，如果使用IMSI寻呼，同一寻呼时刻只能寻呼3个UE；如果使用TMSI寻呼，同一寻呼时刻只能寻呼5个UE。如果在同一寻呼时刻寻呼UE的个数超过系统的处理能力，就会造成寻呼丢失的情况。如果K值设置过小，寻呼周期变短，计算出来UE的寻呼时刻相同的概率增大，寻呼丢失的概率也相应增大。由于UTRAN寻呼重发时间间隔是一个寻呼周期，所以DRX寻呼周期系数K的设置也要考虑到UTRAN寻呼重发时间间隔，要和CN寻呼重发情况配合设置。,DRX寻呼参数设置不合理,优化措施K值下限的设置要考虑到节省UE功耗和减小UE寻呼时刻相同的概率，K值上限的设置要考虑到UTRAN寻呼重发时间间隔。在实际设置过程中，K值一般设置位于212中间的值，如5、6、7、8，寻呼周期分别对应320ms、640ms、1280ms、2560ms。假设CN寻呼重发次数为1（总共发送两次寻呼），间隔为2s，那么UTRAN重发次数和间隔的设置应该遵从如下规律：1、如果UTRAN重发次数为0次（UTRAN不重发），UTRAN的DRX周期应小于CN重发间隔（2s），即此时的K值应该设置为7或8（1.28s,2.56s）比较合适，设置为8主要是考虑Iu/IuB寻呼流控时寻呼的丢失；2、如果UTRAN重发次数为1，UTRAN的DRX周期应小于CN重发间隔的一半（1s），即此时的K值应该设置为6或7（0.64,1.28s）比较合适，设置为7主要是考虑Iu/IuB寻呼流控时寻呼的丢失；,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,NP值设置不合理,现象与分析Np是寻呼指示信道PICH在一帧中下发的PI寻呼指示数，该参数在系统消息5中通过NumberofPIperframe指示。UE会在确定的寻呼时机接收PICH帧，然后找到对应的PI指示位（第q个PI指示），只有相应的PI指示位有效，UE才会去解调对应的S-CCPCH帧。Np在实际网络中的意义：该参数将所有的IMSI分成了Np组，每一个组中所有的IMSI使用同一个PI。Np设置过小，则每组中对应的UE数目较多，对每个IMSI而言，PI指示出现的概率增大，被唤醒的次数越多，对节省UE功耗不利；Np设置过大，则每组中对应的IMSI数目较少，对每个IMSI而言，PI指示出现的概率也较小，被唤醒的次数也较少，但Np越大，每个PI对应的bit数目减少，对UE的PICH解调性能要求越高。优化措施Np取值范围在（18，36，72，144），要根据当前网络的用户数的多少确定，一般用户多Np取值大一些，用户少Np取值小一些，实际网络中可以取中间值36或72。,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,CN寻呼使用的UE标识,现象与分析网络可以使用寻呼类型1消息同时在空口寻呼多个UE，由于PCH容量的限制，UE的个数和寻呼消息中使用的UE标识密切相关，也就是说UE标识影响了寻呼信道的容量。相对于CN发起寻呼的情况，UTRAN发起寻呼的概率要小得多，这里只考虑CN发起寻呼的情况：UE处于IDLE状态，CN使用IMSI进行寻呼，只能同时寻呼3个UE；UE处于IDLE状态，CN使用TMSI或者PTMSI进行寻呼，只能同时寻呼5个UE；UE处于CELL_PCH或URA_PCH状态，不管CN使用什么寻呼标识，UTRAN使用U-RNTI进行寻呼，只能同时寻呼5个UE。从上述分析可以看出，CN使用UE临时标识TMSI和PTMSI可以增加PCH的容量。优化措施CN优化使用UE临时标识TMSI和PTMSI进行寻呼，可以通过软参进行调整。,第二章寻呼问题的典型案例,寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH/DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题,IMSIATTACH/DETACH功能,现象与分析当UE开机注册成功后，MSC/VLR置用户状态为ATTACH，IMSIDETACH即移动用户关机，MS发起DETACH的流程，MSC/VLR置用户状态为IMSI分离，该流程一般不通知HLR。UE通过接收系统消息1确定能否使用IMSIATTACH和DETACH过程。GsmMAPIE有两个octer组成，第一个octer是T3212，第二个octer的bit1是ATT标识，“0”表示网络不允许UE使用IMSIATTACH和DETACH过程，“1”表示允许。下图配置的“0a01”表示T3212是60分钟，允许UE使用IMSIATTACH和DETACH过程。,IMSIATTACH/DETACH功能,现象与分析优