荆州MOTO大容量BSC使用问题总结

1、荆州 MOTO 大容量 BSC 使用问题总结一、安装调测中遇到的问题1. ABIS 光接口板无法支持热倒换。大BSC下的GOIUB板倒换到备用侧后，相应传输设备没有同时做倒换。同样 传输设备倒换后，GOIUB也不跟随倒换。且传输设备使用备用侧时，强制 GOIUB 倒换后很快会倒回主用侧，无法驻留在备用侧上。现原因不明。答复：目前，原因已查明：为SDH设备参数设置为单端口倒换模式，而 BSC 设置为双端口倒换模式。在这种情况下，任何一方开始倒换时，对端都不响应。现在，我们在新调测的BSC6上进行实验，华为SDH也设置为双端口倒换模 式，双方都能同步正常倒换。二、运行中出现的问题1.基站打开ITS

2、后(支持EDGE，DCTU2勺A面如配置成EGPR信道，贝U 相应的B面时隙不可用。通常 TCH Full Rate 时隙，默认可转变成 EGPRS Normal Channe，l 这样就 可能导致基站中大量时隙不可用。所以，在打开 ITS 后，如不是指定配置 EGPRS 的TRX需要对其TCHFull Rate时隙对应可变 GPRS寸隙修改为GPRSChannel。建议：在大容量BSC下，最好还是将每个小区内开 EGPRS勺载频替换成CTU2D配置为CCTU2避免开ITS。答复：该问题已通过参数修改解决。基站开启ITS功能EDGEB，可将CTU2的对面B面的TCHFull Rate时隙对 应

3、可变GPRS寸隙修改为GPRS)hannel。将要承载EDG的载频替换成CTU2D 配置为 CCTU，2 就不会出现 B 面时隙不可用。目前通过该参数修改，没有小区出现 DCTU2勺B面时隙不可用的情况2. 修改小区数据后，如重启基站，可能导致基站软件丢失。为增加PCH和AGCH勺带宽，我们将所有小区的参数进行如下修改： 增加 ccch 到 2 个 timeslot ，同时将 bs_ag_blks_res 设置为 2，并将 BS-PA-MFRAM减小为2,加快寻呼的发送来加速系统寻呼排队状况恢复。步骤如下：deactived cell，从 LMT上选中小区，右键 set cell active

4、 state, 置成 not actived.（ 一个站下的所有小区不能同时置成 not actived） ，选中这个小区右键set cell attributes,首先修改BCCHS频的信道参数，第三个时隙的信道类型定义为 BCH然后修改小区的set idle parameters 中 BS_AG_BLKS_RES=2,BS_PA_MFRAMS存2, 从 LMT上选中小区，右键 set cell active state, 置成 actived. 完成一个小区的修改。修改参数，小区的所有载波重启。该BSC下共18个基站中，17个都正常起来，一个基站（东区）无法恢复， 查看告警发现基站的软件丢

5、失，人工从 OMC-S上下载软件后基站恢复（耗时45 分钟）。目前原因不明。答复：SR2346887已在10月29日开出，正在调查中。目前怀疑可能与基站上的PCMCIA老化有关，如果再次出现，我们保留相 关故障硬件供研发部门调查。对于该问题， 由于可能碰到的概率极小， 我们的方案是： 在后续修改如果可 能导致小区重启的参数时，将在晚上进行，并保证基站传输OML正常，并现场保 障软件能立即下载到基站（3045分钟），问题碰到后立即开SR,寻求根本原因。 保留相关故障硬件供研发部门深入调查。三、较严重的问题1.临安BSC6割接后寻呼成功率下降9月17号临安BSC6在割接后出现了电路域寻呼成功率严重

6、下降的现象，最差的情况寻呼成功率低至30%由于MOBIS与ABIS接口在寻呼接通上的机制不同，以前 GSR勺参数配置， 无法适应当前BSC6的性能，对BSC6的影响主要集中在寻呼成功率在忙时会有很 大的下降。GSF与 RSR勺系统最大变化是增加了规范规定的 Abis接口，而去掉了原来 的Mobis系统。而此项改变使得部分原来在 BTS上的功能转移到BSC上，而主导 CCC分配功能的Call Processing Module 也随之转移到BSC侧，具体流程也发 生了明显变化：GSR系统寻呼处理框图（话音寻呼）：RSR系统寻呼处理框图（话音寻呼）:如以上两幅流程图所示，RSR信道资源的分配与激活

7、的步骤在时间上相比GSR系统将有所增加，这也就意味着相同数量的空口资源，被占用的时间将会增 加，据研发人员的测试，正常情况下会有1秒到2秒的增加，且随着负载的增大， 所需时间也会随之增长。也就是空口资源使用效率下降。在RSF系统中，完成相 同的CCCF负载，相比GSRS统则需要更多的资源。资源不够的情况一旦出现，将出现AGCH和/或PCM拥塞，从而导致PagingRequest消息和/或Immediate Assignment 消息的丢弃或超时。考虑到以上情况，建议扩大PCH的带宽以提高对瞬时峰值的容忍度以及加速 对恶化后果的恢复。同时，考虑到在杭州出现的AGC!拥塞导致Paging_Resp

8、onse 降低的问题，建议扩大 AGCH勺带宽。综上，对于 paging 相关参数修改建议为： 增力卩ccch至U 2个timeslot ，同 时将bs ag blks res 设置为2,并将BS-PA-MFRAM减小为2,加快寻呼的发送 来加速系统寻呼排队状况恢复。答复：针对该问题，公司研发部门已经制定了修改方案，计划在下一版本（11 月中旬）通过BTS软件升级解决；目前版本下可采用 2CCCH配置作为临 时解决方案。对于浙江，在忙时启动了第二 CCCH的小区，工作正常，未出现寻呼抛弃，且话音立即指配成功率明显高于未开启第二CCCH勺小区。2. PS域统计值A031代码错误目前版本的BSC存

9、在代码统计缺陷，导致 A031值统计过大。错误的A031 统计值是A331的14倍，且这个指标的统计错误不会带来业务的影响 （纯话务统 计计数器值的增加只影响话务统计指标，不影响业务）。答复：该问题原因已查明，将在后续版本（ 6000.20t7 ）中解决。暂时可以 用小区的 PS 寻呼统计值来代替。四、基站割接时存在的问题：1. 故障现象：割接后玉桥开发区基站载频显示正常， 但所有时隙 （BCCH/SD/TCH/PD不可用故障分析：该站共两条传输，传输正好接反。这种情况在 BSC23上基站是不 会入服的，但在BSC600C上可以。在大BSC下，可能只要OMI所在的第一条传输 物理链路通，如在B

10、SC上对应的端口错误，数据仍能正常下载到 BTS但相应的 所有信道不活。答复：对于大BSC如基站传输接反，为保障基站快速恢复，基站仍会将软 件和数据下载到基站（减少退服时间），但所有信道仍起不来，避免了用户单通 或串话引起的投诉。 因此通过载波状态， 仍能判断出传输接反， 而一旦传输恢复， 基站就会快速完全恢复，不需再下载数据。减少退服时间。为在割接中避免该问题，割接时传输侧作好充分准备，保障同一个基站的几 条传输不要接错。割接完后需观察载波是否完全起来。2.故障现象：交征大楼基站割接到BSC6000后 oml 直显示failure ，所有传输状态正常故障分析：该站割接前输入 chg_elem

11、ent _site_data,5 2 siteid 后（倒换 CSFP启动双boot程序），还没有来得及lock rsl，很快基站就在原BSC上开 始 loading 。怀疑下载到CSFP勺双启动code并没有将支持Abis功能正常打开。该站备用 BTP无PCMCIA卡，且BTP未拔出，可能与此有关（但同样情况的其他基站并没 有影响起站）。所以，还是要求所有割接基站的BTP必须有卡，或将无卡 BTP拔出。也可能与BTP或 PCMCIA卡硬件有关，或可能code下载有问题。答复：对于此类问题，可通过充分作好割接准备来完全避免，要求所有割接基站的BTP必须有卡，或将无卡BTP拔出。割接当晚，多准备

12、 已包含新数据的BTP碰到上述问题可直接插入基站，这样基站可在 15分钟内 恢复。3. 故障现象：省电二处基站割到 BSC600C后无法起站，传输状态不稳定，3 条传输每隔几分钟就会同时中断。故障分析：该站无主侧的BTF，而我们通过migration_tool 转出来的数据库 只有主侧BTP数据，备用侧BTP数据需自行添加。此次割接添加备用BTP这一步 缺失。基站可能已正常下载了 COD和数据，但初始化后由于备用侧BTP无数据， 而主用侧无板子，导致无法起站。答复：该问题已通过完善数据库转换工具解决，而非BSCS备问题。该问题是割接的数据库转换工具有缺陷，备用侧BTP数据需自行人工添加，在割接时保证基站的主备用槽位都有 BTP可解决避免该问题。同时最新版本的数 据库转换工具Migration Tool已经解决该问题，不再需要手动添加备用 BTP数 据。4. 故障现象：热电厂基站割接后状态同上。故障分析：但该站的硬件条件与上面一个基站不同。该站割接前备用侧 BTP 为B-U，主用侧为E-U,割接到大BSC后也基站一直用备用侧BTP起站，一直没 有使用主用侧。CNRC寸以上两个问题在实验室测试，认为只有备用侧 BTP也是可以起站的， 因此问题3应该是没有备用侧BTP数据导致。但关于问题4,实验室测试时可以 倒换到主用侧起站， 怀疑可能与主用侧硬件问题有关， 或与 code 下载