华为设备TBF建立成功率优化提升方案XXXX03

1、华为设备TBF建立成功率的提升方案目录1 网络接入性能分析优化1.1 接入性能指标1.2 无信道资源导致的下行TBF 建立失败优化1.2.1 无线拥塞类型1.2.2 对于无线拥塞的处理1.3 手机无响应导致下行 TBF 建立失败1.3.2空口质量1.3.3Abis 口传输1.3.4BSC6000 PCU 处理部分1.3.5GB 口传输1.3.6手机问题1.3.7手机行为1.4 CCCH 过载导致下行 TBF 建立成功率低101.4.1 问题描述分析111.4.2 解决方法131.4.3 优化前后效果比较141 网络接入性能分析优化1.1 接入性能指标下行TBF建立成功率计算公式如下:内置PCU

2、 TBF建立成功率定义:1）上行TBF建立成功率=（上行GPRS TBF建立成功次数+上行EGPRS TBF建立成功次数）/（上行GPRS TBF建立尝试次数+上行EGPRS TBF建立尝试次数）2）下行TBF建立成功率=（下行GPRS TBF建立成功次数+下行EGPRS TBF建立成功次数）/（下行GPRS TBF建立尝试次数+下行EGPRS TBF建立尝试次数）统计TBF建立失败的主要有以下2个指标:1）无信道资源导致下行TBF建立失败次数/无信道资源导致下行 TBF建立失败次数2） MS无响应导致下行TBF建立失败次数/ MS无响应导致下行TBF建立失败次数TBF性能优化中主要就无信道资

3、源导致下行TBF建立失败次数和MS无响应导致下行TBF建立失败次数这2个指标进行优化。1.2 无信道资源导致的下行TBF建立失败优化在EGPR网络建设初期，EGPR信道配置较少，随着 EGPR数据用户的增长，需要对基站的容量进行扩容和EGPR信道个数或信道控制参数进行调整。1.2.1无线拥塞类型对于无信道资源导致 TBF建立失败，按照问题的严重程度分为以下几个类型:1）硬拥塞，上行下行TBF建立无可用的信道资源该问题非常严重，由于 EGPRS&GPRS无法使用，给用户造成的主观感受很差。2) 话音抢占造成TBF释放，忙时回收有负载动态 PDCH次数比较严重，相当于 GSM中的掉话。3) TBF

4、信道复用比较明显，每用户平均占用信道个数比较少严重程度一般，EGPRS&GPRS可正常使用，但是给用户的感受是速度慢。以上是判断拥塞的一般性描述，具体的判断标准可根据具体情况进行合理定义。1.2.2对于无线拥塞的处理根据不同的拥塞现象，处理建议分别如下:1)有较多的硬拥塞或者话音造成的TBF释放,此种情况下无可用PDCH信道，由于语音的抢占导致配置的动态PDCH为TCH状态。此种情况必须通过增加静态 PDCH信道或者TRX扩容才能够解决。2) 有TBF复用明显现象以及少量语音造成TBF释放问题不特别明显建议增加 PDCH动态信道个数，并且如果该点为CQT点则一定要增加EGPRS静态信道。内置P

5、CU，增加小区级PDCH信道控制参数：“小区下最大 PDCH比率门限”。3) 有少量的TBF复用明显问题不明显，但如果为 CQT点则最好增加PDCH动态信道。内置PCU的BSC，增加小区级PDCH信道控制参数：“小区下最大 PDCH比率门限”。1.3 手机无响应导致下行TBF建立失败本测量指标统计一个测量周期内小区MSB响应导致下行GPRS TBFl立失败次数，MS无响应导致下行TBF建立失败包含以下两种情况:(1) MS无响应导致在CCCH上发起的下行TBF建立失败2020-1-22华为机密，未经许可不得扩散第28页，共19页在下行TBF的建立流程中，网络侧会发送POLLING消息给MS来获

6、取TA值，并且预留块资源让MS回应指配确认消息。如果网络侧在指配的信道的预留块资源上未收到该MS的PACKET CONTROL ACKNOWLEDGEMENT消息，网络侧会多次重发下行立即指配，直到超出最大尝试次数。图1是由于MS无响应导致建立下行TBF建立失败的过程。每当网络侧尝试次数超出最大值的时候，如图中的测量点A所示，统计值“手机无响应导致下行 TBF建立失败次数”加一。M3Network |IMMEDIATE ASSIGNMEITTPOLLING (頤 BP)*P0LUNG (RRBP)MS No Response.,.4图1 MS无响应导致在CCCHh发起的下行TBF建立失败MS无

7、响应导致在PACCH上发起的下行TBF建立失败网络侧可以通过下面两种方法来建立下行TBF :在当前的上行TBF传输过程中或下行TBF释放过程中发起新的下行 TBF建立请求；在当前的下行 TBF传输过程中为该TBF重新指配下行资源。网络侧发送PACKET DOWNLINK ASSIGNMENT 消息，并且预留块资源让 MS回应指配确认消息。如果网络侧在指配的信道的预留块资源上未收到该MS 的 PACKET CONTROLACKNOWLEDGEMENT 消息，网络侧会多次重发下行分组指配，直到超出最大尝试次数。图2是由于MS无响应导致下行TBF建立失败的过程，每当重发的次数超出最大的尝试次数时，如

8、图中的测量点 A所示，统计值手机无响应导致下行TBF建立失败次数加一。MS首先要检查的就是空口的传输是否存在故障(如图3),空口质量是否良好;垂质量很垂!T仙I亲SeSNPCUVCflfc N*twdirlUMSC/VLR/MTBTI3S7/zeroiseccDNSnPRS BarkboUPDNNetworkPACKET DOWN UNKASSIGNMErir(RRBP)PACKET DOWNLINKASSIGNMENT(RR0P)毛PACKET DOWNLINKASSIGNMENTCRR0P)MS No Response,.图2 MS无响应导致在PACCHt发起的下行TBF建立失败其次，我们

9、来分析手机无响应有哪些影响因素:1.3.2 空口质量，因此主要是无线环境的因素，手机无响应就是手机和网络之间传输和通信出现了问题图3 GSM/G PRS吉构图1.3.3 Abis 口传输在网络侧，首先就是BTS和BSC之间Abis 口的传输，如果传输有问题，比如端口故障，就会 有大量的误码（包括失步帧和校验错帧）,这会在一定程度上影响手机接入;1.3.4BSC6000 PCU 处理部分数据业务的中央中心就是 BSC6000中的内置PCU，因此排除几个传输接口的问题后,要的分析对象就是内置 PCU的下行TBF建立流程的处理了，主要从以下几点去分析:1、数据配置是否存在异常，与其它没有出现此问题的

10、PCU小区有何区另TBFCCCH2、手机无响应导致下行 TBF建立失败较多，从下行 TBF建立流程进行分析，下行建立流程主要包括 CCCH上的下行TBF建立流程和PACCH上的下行TBF建立流程;当PCU收到LLC PDU而没有下行TBF时，需要建立一个下行 TBF用以传送数据。上的下行TBF建立流程，如图4所示:MSBTSBSCPCUP亡LI tar IMtl ACS CUD7 tun机mac $忖总卄匚崗五mtroi恕II IFJC色t Pow&M 匚门讥 QkriiiHq SJ吐c请求建立下帚二帕TFb關c卜at 8粗训1 II盒III卽iinentJ、Starling Tme?| H

11、向Polli叫苗 FCL chq bb; ht f hi. $p-rOVII Illi 卜 A 小-凰(2图4 CCCH上建立下行TBF流程如图4,在下行TBF开始时，网络侧在下行TBF的PACCH下发以TFI标识的Packet PollingRequest消息。手机对此响应ACCESS BURST类型的分组控制确认消息。网络侧从AB(ACCESS BURST)中提取时间提前量，在 Packet Power Control/Timing Advanee 消息中通知手机，并发分组下行指配消息给手机分配多个信道。（此流程的作用：一是确认手机是否）。收到下行立即指配，下行 TBF是否建立成功；二是提

12、取时间提前量通知手机由于手机和网络的配合问题，可能会出现网络侧发了立即指配消息和P acket Polli ngRequest消息，手机没有收到的情况，因此适当增加立即指配消息或P acket Polli ng Request消息，因此一般选择提高P acket的重发次数，然而提高立即指配次数会导致指配成功率的降低Polling Request消息的重发次数，可以很大程度上减少手机无响应的概率，类似于语音中的寻呼次数。继续看图4,如果手机发的上行FAI已经发送，但此时上行TBF还处于传输状态，就不能 进行下行建立，需等待一段时间后再建立下行，如果这个时间超时就会导致手机无响应。PACCH上的下

13、行TBF建立流程，如图5所示:MSBTSBSCPCU；RLCdaWblo 曲A1iRLC1FJ block1111111；RLC dd11J Woo卓11 .Control 料百 n)ed peE ent(AB or 1崩匸三 亠1!RLC dala b(oi(!RLC dd1a Uockm1111图5 PACCH上建立下行TBF流程PCU在PACCH上发分组下行指配消息以后，如果没有收到手机响应的分组控制确认消息，则PACCH上的下行TBF建立失败。另外，加大上下行延迟释放时间，可以增大手机从PACCH建立下行的几率，因此可以提高手机接入时间，提高下行TBF建立成功率，一定程度上减少手机无响

14、应。1.3.5 GB 口传输对于GB 口，主要关注是否有 GB 口的链路故障，是否有拥塞情况。1.3.6手机问题对于个别手机可能存在手机兼容性问题，也有可能是手机本身的问题，对于这些问题需要手机侧进行处理定位。1.3.7手机行为下行由于手机可能已经进入其他小区，此时在原小区建立下行TBF时的POLLING消息和指配消息，手机无法响应；另外，即便手机还在原小区，由于可能该手机处于Sta ndBy 状态，对于PCU建立下行TBF时的指配消息和POLLING消息，该手机也不一定能接收到或及时响应。此外，手机即使收到了P Olli ng消息，由于兼容性问题，会导致不回AB消息。这些都可能导致下行TBF

15、因手机无响应而建立次数占下行 TBF尝试建立次数的比例较高。1.4 CCCH过载导致下行TBF建立成功率低CCCH信道在空口上主要传送寻呼信令（ PCH）和立即指配信令（AGCH ）。每条寻呼信令和立即指配信令均占一条51复帧，51复帧占用时长为0.2354秒。立即指配消息和寻呼消息共同在 CCCH信道下发，当小区的配置为“一个非组合CCCH信道时”，CCCH共分9个消息块，接入允许保留块数设置了保留多少个消息块供立即指配消息专用，一般该参数设置为 1或2。当同时下发立即指配消息较多时，会占用其它消息块, 删除指示消息上报次数）/（A330:寻呼下发次数（电路业务）+ A331:寻呼下发次数（

16、分组业此时，立即指配消息和寻呼消息同时排在寻呼队列中,会导致寻呼队列更拥塞，寻呼超时次数进一步增加。一条寻呼信令中能发多条寻呼消息。采用TMSI寻呼方式，一条寻呼信令最多可发送4条寻呼寻呼消息，采用IMSI寻呼方式，一条寻呼最多可发送 4条寻呼消息。张家口移动寻呼策略则是采用两次寻呼，第一次采用TMSI寻呼，第二次采用IMSI寻呼，现网各位置区一次寻呼成功率在91 %94%之间，采用比较统计的值为93%,这样通过典型寻呼合并效率计算,估算出平均每条寻呼信令中下发2.98条寻呼消息。CCCH负荷、CCCH溢出率为参考移动通信业界的思路自定制的分析公式，用如下公式估算:CCCH负荷=（A330:寻

17、呼下发次数（电路业务）A331:寻呼下发次数（分组业务）/2.98 X 0.2354+（A301H:立即指配命令次数（分组业务）CA301J:立即指配命令次数（电路业务）X 0.2354 /3600/（9X配置的CCCH时隙数）100%；其中配置的CCCH时隙数指的是BCCH信道数和扩展BCH信道（BCH信道）数之和，默认不开通扩展BCH场景下为1。（每51复帧中能够发送多条 PCH寻呼块，每个寻呼块最大能够发送2-4条寻呼消息；而每51复帧只发送一条立即指配命令消息）考虑以CCCH溢出率来估算CCCH信道过载程度:CCCH溢出率=（A337:PCH电路业务寻呼删除次数+ A338:PCH电路

18、业务寻呼超时次数+ A339:PCH分组业务寻呼删除次数+ A340:PCH分组业务寻呼超时次数+L3188A:Abis接口务）+A301H:立即指配命令次数（分组业务）+CA301J:立即指配命令次数（电路业务） ）X 100 %。指标指标描述A330:CELL PAGES CS寻呼下发次数（电路业务）A331:CELL P AGES PS寻呼下发次数（分组业务）A337: CELL CIRCUIT PCH DELPCHfe路业务寻呼删除次数A338: CELL CIRCUIT PCH EXPPCHfe路业务寻呼超时次数A339: CELL PACUIT PCH DELPCH组业务寻呼删除次

19、数A340: CELL PACUIT PCH EXPPCH组业务寻呼超时次数L3188A:CELL DEL INDAbis接口删除指示消息上报次数1.4.1问题描述分析对于PCU下面个别小区因业务量高导致话统指标“手机无响应导致下行 TBF建立失败次数”较高，导致下行TBF建立成功率较低，晚忙时特别明显。从CCCH上的下行TBF建立流程分析，对存在手机无响应导致下行TBF建立失败次数较高的小区（沽源ZJGDO1D、沽源ZJGDO1C、沽源ZJGDO1B等），分析流控测量相关的话统指标“呼叫相关测量（CALL ）-流控测量 小区- Abis接口分组CCCH负载指示消息上报次数（此话统指标需要在

20、M2000上先进行登记）”，发现重要信息:Abis接口分组CCCH起始时间GCELLL3188D:Abis 接口 CCCH负载指示（PCH消息上报次数（分组业务）02/16/2011 19:00:00ZJDH899A16602/16/2011 19:00:00ZJDHB38F15202/16/2011 19:00:00ZJDHB38G10102/16/2011 19:00:00ZJG801A10902/16/2011 19:00:00ZJG801B17802/16/2011 19:00:00ZJGB01A184负载指示消息上报次数非常多（见表1）02/16/2011 19:00:00ZJGB0

21、1B21102/16/2011 19:00:00ZJGB01C21602/16/2011 19:00:00ZJGB38A24002/16/2011 19:00:00ZJGB38D13102/16/2011 19:00:00ZJGD01B22602/16/2011 19:00:00ZJGD01C114表1 Abis接口分组CCCH负载指示消息上报次数当CCCH过载，BSC收到测量小区所属的 BTS报告的PACKET CCCH LOAD IND消息的次数，然后，BSC侧启动一个TN_CCCH_OVERLOAD_PROTECTION 定时器，BSC为了 降低CCCH拥塞程度，基于话音业务优先于分组业

22、务的原则，分组域不重发下行分组立即指 配，并且只发 1 个polling request，即只发 1 个 IMM ASS和 1 个Polling Request消息。在 TN_CCCH_OVERLOAD_ PROTECTION 定时器超时后，恢复正常。即正常情况下，如果手机对下行分组立即指配无响应的话，BSC会重发IMM ASS和Polling Request,直到手机有响应为止。而且每个IMM ASS后发5个Polling Request （所发个数在LMT中可以配置，默认值已为最大 值5）。IMM ASS的下发次数在LMT中也可以配置，现在默认为 2次。正常情况下，手机无响应导致下行TBF

23、建立失败的话，BSC侧会共发送2个IMM ASS和10个Polli ng Request。由于空口质量不稳定，一般网络侧会发几个P olli ng Request后，手机才有响应，如图6所示:11 Ji Ji di ii Ji Ji Ji 11 Ji Ji Ji Ji il IK Ji Ji Ji 14 Ji Ji Ji 1i II- 1 Ji Ji 11 Ji Ji di Ji ii II- 豈IE虧略虧器鸣陋陋陋虧貶虧昨粘虧鸣魁学岡虧照昨略昨虧帼陋鸣虑虧虧虧磐略陋帼 E Ja*Fane召 F*ckGt IfaliiA Ack/Eadt 令I Ftckel Fflllimg R电quei?

24、tt t込対 Packet PoUirig Request3叵1区）S lade Keportss叵区EGFKS Picket Downlink Ack/Hack EGPES Pickst Downlink Ack/Nack ECjPHS Packet Downllitk Ack/Madc Packet Uplink Aefc/tfackV EGFK5 racket Dcipi Ack/Naek t 萌ttt十IFadwt DwnliiA Ack/Sackf*ckei Uplink Kck/Sictt t/ PAcket Fow电r 匚ntrol/Ttming 丸d.EGFRS Packet

25、Downlink 取k/lUck Picket Uplink ftcR/FackEGFRS racket Downlink Ack/Haclc racket F41Ii.ne K4questEGPRS Picket Downlink Ack/HackPicket Uplink Ack/FackPacket Uplinfc Ack/KackEGPfiS Packet Dcwnlink Ack/Mack PTCCH DL MessageEGFRS Packet 口砂nlink Ack/llackEGPRS Fwlwt Downlink Ack/Hack Picket Downlink Assign

26、ment Picket Uplink Ack/HackPacket Uplink Act/HackEGPfiS Packet Downlink Ack/MackPacket Uplink Acfe/FackEGFRS Packet Downlink Ack/NaekPicket racket racketPicketUplinh AckZNack Follinf Rquest Uplink ck/Nack Uplink Ack/KickEGFES FMlMt Dowcliak AcVtckt EGPHS Packet Downliii Ack/HackEq.SISISISISI31SiSISI

27、SISISISISISISISISISISISISISISISI31SISISISI1SISISISI_I NwntTHFHFHPHPHPHPHTHFDCH Block FDCH BlockPDCH BlockPDCH Rlsck HeaderHtderHaderHeaderDL DL DL BLlEtportRtportEepartRep art.rBSC侧发了 3个Polling Reques诟手机才有回当CCCH负荷超过75%后，CCCH信道溢出严重，此时应及时采取路由区分裂、位置区分裂、增加BCH信道等优化措施；当 CCCH负荷在60%到75%之间，此时CCCH信道溢出率指标不超过6%

28、,此次应予关注，必要时采取减少寻呼次数、增加CCCH信道数目等相关措施;当CCCH负荷低过60%时，CCCH溢出次数比较少，只需针对个别问题小区进行优化处理。对于LAC区内的寻呼业务考虑。若A330 + A331寻呼容量典型值（每小时19万次），需考虑对该LAC区内所有小区扩展BCH。对目前张家口华为区域现网的 CCCH负荷分析来看，不存在整个LAC区下所有小区CCCH过载问题。对于个别小区 CCCH 过载评估，若(A337+A338+A339+A340+L3188A)/(A330+A331）10%，表示出现寻呼消息丢弃，建议配置扩展BCH，扩容CCCH信道:对应的一个BCCH复帧中CCCH消

29、息块数为：3、9、18、27、36。CCCH配置决定了 PCH、AGCH和RACH容量。接入允许保留块数、 CCCH配置参数会根据小区主 B载频0信道配置类型动态调整:若小区CCCH配置为非“ 1个组合CCCH ”，则接入允许保留块数缺省值修改为2,同时该参数的取值范围为17。若小区的CCCH配置为“ 1个组合CCCH ”时，则将该小区对应的系统消息表中的接入允许保留块数缺省值修改为1,同时该参数的取值范围为12;默认情况下，一个小区只配置一个主 BCCH ,这样有“ 1个非组合的CCCH ” ,那么CCCH 在一个BCCH复帧中的消息块数就为 9。如果多配置一个 BCH，那么就有“ 2个非组

30、合的CCCH ”，那么CCCH在一个BCCH复帧中的消息块数就为18,很大程度上提高了 CCCH的容量。143优化前后效果比较以下是实施优化方案前后的对比效果:优化方案实施后Abis接口分组CCCH负载指示消息上报次数明显减少（见表2），只有业务突发高峰造成的几次过载。起始时间GCELLL3188D:Abis 接口 CCCH负载指示(PCH消息上报次数（分组业务）（无）02/16/2011 19:00:00ZJDH899A16602/17/2011 19:00:00ZJDH899A1802/16/2011 19:00:00ZJDHB38F15202/17/2011 19:00:00ZJDHB3

31、8F002/16/2011 19:00:00ZJDHB38G10102/17/2011 19:00:00ZJDHB38G1 002/16/2011 19:00:00ZJG801A10902/17/2011 19:00:00ZJG801A1 002/16/2011 19:00:00ZJG801B17802/17/2011 19:00:00ZJG801B2902/16/2011 19:00:00ZJGB01A18402/17/2011 19:00:00ZJGB01A002/16/2011 19:00:00ZJGB01B21102/17/2011 19:00:00ZJGB01B002/16/2011

32、 19:00:00ZJGB01C21602/17/2011 19:00:00ZJGB01C002/16/2011 19:00:00ZJGB38A24002/17/2011 19:00:00ZJGB38A002/16/2011 19:00:00ZJGB38D13102/17/2011 19:00:00ZJGB38D202/16/2011 19:00:00ZJGD01B22602/17/2011 19:00:00ZJGD01B902/16/2011 19:00:00ZJGD01C11402/17/2011 19:00:00ZJGD01C0表2增加扩展BCCH信道前后的Abis接口分组CCC顷载指示

33、消息上报次数从KPI上看，扩容CCCH后，下行TBF建立成功率已经有了很大的提高。忙时的下行TBF建立成功率由原来的80%多上升到90%以上(见表3)，效果非常明显。起始时间网元名称GCELL下行EGPRSTBF建立尝试次数下行EGPRSTBF建立成功次数MS无响应 导致下行EGPRSTBF建立失败次数下行EGPRSTBF建立成功率(%)02/16/201119:00:00ZKBS17ZJDH899A109709605136587.56%02/16/201119:00:00ZKBS9ZJDHB38F7274629597986.54%02/16/201119:00:00ZKBS9ZJDHB38G

34、56694377129277.21%02/16/201119:00:00ZKBS17ZJG801A1138010097128388.73%02/16/201119:00:00ZKBS17ZJG801B119411094699591.67%02/16/201119:00:00ZKBS9ZJGB01A9352864670692.45%02/16/201119:00:00ZKBS9ZJGB01B102799273100690.21%02/16/201119:00:00ZKBS9ZJGB01C9269828798289.41%02/16/201119:00:00ZKBS9ZJGB38A13629119

35、09172087.38%02/16/201119:00:00ZKBS9ZJGB38D7968714981989.72%02/16/201119:00:00ZKBS9ZJGD01B123281135897092.13%02/16/201119:00:00ZKBS9ZJGD01C6738587286687.15%02/17/201119:00:00ZKBS17ZJDH899A127851227115095.90%02/17/201119:00:00ZKBS9ZJDHB38F506150016098.80%02/17/201119:00:00ZKBS9ZJDHB38G134791332715298.

36、87%02/17/201119:00:00ZKBS17ZJG801A992698556999.20%02/17/201119:00:00ZKBS17ZJG801B124641173034394.10%02/17/201119:00:00ZKBS9ZJGB01A395039262499.30%02/17/201119:00:00ZKBS9ZJGB01B539953574299.20%02/17/201119:00:00ZKBS9ZJGB01C621461734199.30%02/17/201119:00:00ZKBS9ZJGB38A533252745798.90%02/17/201119:00:

37、00ZKBS9ZJGB38D551354199398.20%02/17/201119:00:00ZKBS9ZJGD01B139971376121498.30%02/17/201119:00:00ZKBS9ZJGD01C548254453599.30%附录：相关话统含义说明1、PCH电路业务寻呼删除次数A337: CELL_CIRCUIT_ PCH_DEL含义:本指标统计了 PCH块上调度消息时存在竞争问题,记录电路域寻呼消息被删除的次数。BTS统计PCH电路业务寻呼删除次数并每分钟上报一次BTS_STATIS_REPORT 消息给 BSC。2、PCH电路业务寻呼超时次数A338: CELL C

38、IRCUIT PCH EXP含义:本指标统计了 PCH块上调度消息时存在竞争问题,记录电路域寻呼消息超时的次数。因为每个寻呼都有生存周期， 超过生存周期后，寻呼消息就会被删除。 这个生存周期默认值是5s,可以通过基站软参修改。BTS统计PCH电路业务寻呼超时次数并每分钟上报一次BTS_STATIS_REPORT 消息给 BSC。3、PCH分组业务寻呼删除次数A339: CELL PACUIT PCH DEL含义:本指标统计了 PCH块上调度消息时存在竞争问题,记录分组域寻呼消息被删除的次数。BTS统计PCH分组业务寻呼删除次数并每分钟上报一次BTS_STATIS_REPORT 消息给 BSC。4、PCH分组业务寻呼超时次数A340: CELL PACUIT PCH EXP含义:本指标统计了 PCH块上调度消息时存在竞争问题,记录分组域寻呼消息超时的次数。因为每个寻呼都有生存周期， 超过生存周期后，寻呼消息就会被删除。 这个生存周期默认值是5s，可以通过基站软参修改。BTS统计PCH分组业务寻呼超时次数并每分钟上报一次BTS_STATIS_REPORT消息给BSC。5、寻呼下发次数（电路业务）A330: CELL PAGES CS含义：当BSC下的MS作为电路业务的被叫时，BSC收到来自MSC或PCU的电路PAGING消息后，根据小区识别标志向相应小