上海用服部 ZXG10BSS 份工程经验汇总.docx
- 文档编号:30673936
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:42
- 大小:54.73KB
上海用服部 ZXG10BSS 份工程经验汇总.docx
《上海用服部 ZXG10BSS 份工程经验汇总.docx》由会员分享,可在线阅读,更多相关《上海用服部 ZXG10BSS 份工程经验汇总.docx(42页珍藏版)》请在冰豆网上搜索。
上海用服部ZXG10BSS份工程经验汇总
移动事业部用服部GSM产品10月份工程经验汇总
中兴通讯移动事业部用服部
1GSM产品工程经验汇总
1.1GSM工程支持一科
1.1.1GSM工程支持一科10月经验汇总
1.1.1.1保定移动涞源支家庄基站通话质量差问题的定位和处理
【作者姓名】:
钟俊标
【现象描述】:
保定移动涞源支家庄基站上挂我司四个ZXG10-BSCV2的BSC2,并且为ZXG10-BTS(V1)基站,配置为S626站型,每个小区对应一个V1机柜。
开通后,运行一直很好。
但是,最近接到用户投诉,反映该基站3小区下通话质量很差。
其他小区和基站暂未接到类似投诉。
现象为:
在该小区下发起呼叫,主叫在通话时,可以清晰听到方说的声音,对方有时却听不清。
问题现象实际上就是我司来源支家庄基站3小区存在上行通话噪音。
【解决方案】:
处理过程(方案):
1) 首先和办事处技术人员和局方相关技术人员了解情况,已经进行的前期处理如下:
保定移动公司技术人员曾多次赴现场进行实地拨测,没有发现用户反映问题。
但是用户仍然投诉,并且投诉升级。
我司办事处工程师赴现场驻地进行实地拨测400多次左右,发现问题确实存在,机率大概在4—5%左右。
由于其他小区用户没投诉,于是对该小区对应的机柜进行硬件排查,单元电路板全部换过,现象依旧。
同时对相应的数据报表和信令进行统计、分析没有发现明显问题。
2) 根据1的处理情况,现分析初步制定两个方案定位故障:
一是排查BSC、二是继续排查2小区机柜的背板和天馈系统。
3) 根据现场人员和设备工具情况,首先决定采用方案一进行排查和定位。
先是对配置数据和有关定时器和小区参数检查,均没发现问题。
然后在软件装载菜单,对软件检查时发现BSC2的EDRT有两块板的第一个DSP用的是2.52.03.04其余均是2.52.03.06晚上对运行的EDRT检查发现,第一个DSP用的是2.52.03.04其余均是2.52.03.06的板子刚好为EDRT852板,其他EDRT均不是EDRT852,由于根据相关的用服技术通知要求2.52.03.06版本EDRT852在信号处理上存在问题,所以在征得同意后将两块EDRT852的DSP版本统一为2.52.03.04,由于对A口进行了大面积操作,所以操作结束后,根据要求,由移动公司对该BSC2进行了CQT呼叫测试,没有发现问题。
4) 根据3的处理情况,随后我司人员在投诉现场,以电信座机号码为被叫进行大话务CQT拨打测试,发现上行通话噪音消失,出现新问题是上行通话单通,就是电信用户听不到移动用户声音,出现机率1—2%,随后对我司BSC2的其他基站小区BTSV2、BTS21、BTSV1拨测均有同等概率的现象,后用北电的基站拨测也出现了同样问题。
初步定位新问题可能是BSC上级网络出现问题一是定位BSC直接相连的北电MSC、二是电信座机所在交换网络。
5) 根据4的处理,改用网通座机做被叫进行了均达400次以上CQT测试,我司基站均未出现问题,通话清晰,无掉话、杂音、单通等任何故障,北电设备也未发现单通问题。
也就是说4中定位电信网络存在问题是正确的。
移动公司拜访了投诉用户,用户反映处理以来通话良好。
处理结论或建议
根据这次故障处理得到如下启示就是:
一、 处理问题要把问题现象首先要搞清楚,思维要灵活,全面。
也就是说一个小区用户投诉,不见得其他没投诉的小区就没问题,也要看看整个BSC有没同样的问题。
二、 建议对于入库版本、一类软件和运行软件一定要用正确。
工作要细心认真,检查再检查,核对再核对,今后一定不要出现如上同一块EDRT板DSP运行程序不一致的情况。
1.1.1.2 时钟处于自由振荡不能正常跟踪
【作者姓名】:
钟俊标
【现象描述】:
调测开通A口时,TIC板开通了4块,由于工程2M线安装原因,只能从最后四块连续配置TIC数据,但是总发现有A口异常和EDRT的DSP单元故障现象,数据重做和排查硬件现象依旧,检查时钟处于自由振荡工作状态不能正常跟踪
【解决方案】:
处理过程(方案):
1) 电话咨询张总工告知,我司BSCV2的同步时钟从第一块TIC板上提取
2) 通知办事处协调工作,并配合现场工程师按技术要求将工程2M线安装进行调整,改为从前四块开始,并保证第一块TIC板的2M线和上级局MSC的2M相连
3) 配置数据相应修改为前4块开始配置后,故障消失,观察系统时钟处于跟踪工作状态
处理结论或建议:
在现场安装调测时,在第一块TIC上务必要配置A口,就是由于设计原因头块板位是系统使用2M口同步下外标用的;否则会造成时钟没有同步的外标而自由振荡。
出现一些莫名其妙的问题。
1.1.1.3如何减少和杜绝升级中疲劳操作产生的错误
【作者姓名】:
钟俊标
【现象描述】:
升级时由于一般都是午夜疲劳作业,加之人多手杂,稍有疏忽就容易犯错误,所以需要提高工作效率减少甚至杜绝错误发生,鉴于此,这次升级采取了如下改进
【解决方案】:
处理过程(方案):
1) 升级思路要清晰,分工要到位。
尤其是由于工作现场情况紧迫,需要紧急升级,更要严格按照升级流程操作,工作更要细化。
2) MP的配置文件要做好备份;写逻辑时可以用同类板子的空槽位烧录,可以减少对设备的影响。
3) 换背板时HW线和DSNI和时钟板要提前做好标记,NET背板要提前按照要换取的背板的HW位置插好固定小插片,这样插HW和换单元板时方便易记,不容易搞混。
4) 升级前要准备充分,包括电烙铁,长点的逻辑线,最好建议用并口延长线,能备用一些接线排更好;
5) OMCR升级前的准备工作中可以事先将升级过程中用到的命令保存在txt文件中放于服务器上,特别是一些较长的命令如修改数据库参数时的一些SQL语句都可以事先保存到txt文件中,在升级的时候用到的命令可以直接粘贴使用即可,一是保证了输入命令的正确性、二是加快了升级的速度。
6) 一些常用的配置文件可以提前编辑好,但要注意好文件格式是DOS或者UNIX格式,检查确认无误。
处理结论或建议
以上方案过程可以有效地减少错误,提高工作效率,行之有效,值得借鉴
1.1.1.4海西移动BSCV2.0设备中860EDRT单板无法升级故障的处理
【作者姓名】:
焦强
【现象描述】:
升级海西移动BSCV2.0设备中EDRT单板的DSP芯片时,发现该设备中所有860EDRT单板的版本还是02E的版本,其它852EDRT和386DRT单板的版本均正常。
而DSP芯片已经成功升级到04A下的版本。
【解决方案】:
检查该设备中的860EDRT单板版本为单板指定版本,指定版本为03E版本,查看R_PPSPEC表,发现其中指定的版本也是03E。
复位860EDRT,待运行正常后,查看单板当前运行版本,发现还是02E下版本。
删除该单板指定版本,改用一类软件中的03E版本,再次复位860EDRT,运行正常后,查看单板当前运行版本,仍是02E下版本。
拔出单板,发现860EDRT单板BOOT芯片上版本标签没改动过,怀疑BOOT芯片升级时未烧录。
替换上烧录过的芯片后,插上单板,待运行正常后,查看当前运行版本,为03E版本。
升级成功。
1.1.1.5BTSV2.0(80W)设备机架内所以载频无法正常上电故障的处理
【作者姓名】:
焦强
【现象描述】:
格尔木移动新开霍布逊BTSV2.0(80W)基站设备时,发现机架内CMM板上电正常,所有载频板上电均不正常,表现为载频电源指示灯红灯闪烁。
基站无法正常工作。
【解决方案】:
检查机房内电源设备,工作正常,同机房内使用相同电源设备供电的微波设备运行正常。
检查基站设备电源接线,连接正确,机架的PDM模块及连线也没发现问题。
在检查塔放电源时,发现塔放的电源指示灯不亮。
检查功放安装,发现塔放安装错误。
正常安装为机架-避雷器-塔放-天馈;而现场的安装为机架-塔放-避雷器-天馈。
塔放设备的电源是由载频通过CDU间接提供的,结果,塔放T型头位置安装错误导致载频供电不正常,最后无法正常启动。
重新按照正常安装顺序安装后,载频上电正常。
基站正常启动,工作。
1.1.1.6四川阿坝移动茂县中学基站割接问题分析报告
【作者姓名】:
焦强
【现象描述】:
基站由V1.6设备割接到V2.0设备后,Abis口传输一直不正常
【解决方案】:
基站由V1.6设备割接到V2.0设备后,Abis口传输一直不正常,出现闪断,导致该基站无法正常启动工作。
采取在基站侧向BSC侧环回传输的办法,致使该站的微波传输设备复位、重置,使Abis口传输正常后,该站正常启动工作。
1.1.1.7服务器根目录满的处理
【作者姓名】:
李录俊
【现象描述】:
服务器正常关机重起后oracle无法正常启动,提示:
写文件失败。
【解决方案】:
分析处理:
df–k结果如下:
文件系统千字节用了可用容量挂接在
/dev/md/dsk/d1152345514625260100%/
/dev/md/dsk/d43096423916032211846331%/usr
/proc0000%/proc
fd0000%/dev/fd
mnttab0000%/etc/mnttab
/dev/md/dsk/d31016122380769170794%/var
swap114507928114507841%/var/run
/dev/md/dsk/d73450428430284055387518789%/oracleapp
/dev/md/dsk/d53096423213530323601%/opt
/dev/md/dsk/d61766347646174867961%/tmp
/dev/md/dsk/d83450428459091122825013018%/export/home
查看根目录下无*.log、core、*.error等文件,与陈琦、研发周自朴联系,根据现场情况,经其分析确认为是由于数据库安装路径问题所致。
Oracle主目录应安装在/oracleapp/u01目录下,而现场服务器是安装在跟目录下,从而导致根目录满。
经周自朴远程支持进行如下操作:
1、把oracle软件移动到/oracleapp/u01下面
#su-oracle
#mv/oracle/app/oracleapp/u01
2、停止所有oracle进程
3、修改/etc/profile文件
以root用户修改下列字段
ORACLE_BASE=/oracleapp/u01/app/oracle
ORACLE_HOME=$ORACLE_BASE/product/8.1.7
CLASSPATH=$CLASSPATH:
$ORACLE_HOME/JRE/lib:
$ORACLE_HOME/jlib:
$ORACLE_HOME/product/jlib
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:
$ORACLE_HOME/lib:
$ORACLE_HOME/jdbc/lib:
/usr/openwin/lib
4、修改dbora和oratab文件
将dbora文件的ORA_HOME路径改为:
$ORACLE_BASE/product/8.1.7
将/var/opt/oracle/oratab文件,的路径改成/oracleapp/u01/app/oracle/product/8.1.7
5、退出nettern重新登陆
6、$cd$ORACLE_HOME/dbs
$unlinkinitomc.ora
$ln-s$ORACLE_BASE/admin/omc/pfile/initomc.orainitomc.ora
6、以oracle用户修改initomc.ora
background_dump_dest=/oracleapp/u01/app/oracle/admin/omc/bdump
core_dump_dest=/oracleapp/u01/app/oracle/admin/omc/cdump
user_dump_dest=/oracleapp/u01/app/oracle/admin/omc/udump
7、修改listener.ora文件
将ORACLE_HOME改成$ORACLE_BASE/product/8.1.7
8、重新启动listener和oracle
以oracle用户登陆执行$sqlplusomc/omc可以,但以omc用户登陆执行$sqlplusomc/omc连不上数据库;ls-l|greporacle无输出。
9、修改$ORACLE_HOME/rdbms/lib/nmliblist文件:
将oracle/app/oracle/product/8.l.7/rdbms/lib/skgxns.o改成
/oracleapp/u01/app/oracle/product/8.l.7/rdbms/lib/skgxns.o
10、执行$ORACLE_HOME/bin/relinkall后,重起oracle和omcr正常。
正常后重新启动服务器也正常
1.1.1.8常用性能指标定义
【作者姓名】:
李文龙
【现象描述】:
工程现场经常需要对网络的性能指标进行分析和对比,因而需要了解一些主要性能指标的定义。
【解决方案】:
性能指标分析中,常用的性能指标有:
忙时话务量,忙时话务掉话比,忙时话音信道掉话率,忙时切换成功率,无线接通率,忙时话音信道拥塞率和最坏小区。
这些性能指标的定义如下:
1)忙时话务掉话比:
=忙时话务量×60/忙时掉话总次数,反映在忙时平均两次掉话之间的间隔(分钟)。
一般要求忙时话务掉话比应不低于85,但对于一些边际网,话务量较低,会导致这一指标偏低。
2)忙时话音信道掉话率(含切换):
=忙时话音信道掉话总次数/忙时话音信道占用总次数(含切换)*100%。
这一指标应小于1%,当达到0.8%时,性能指标优良。
一些偏远地区由于覆盖不连续,会导致掉话率指标增高。
3)忙时切换成功率:
=忙时切换成功总次数/忙时切换请求总次数*100%。
当切换成功率大于97%时,性能指标优良。
4)无线接通率:
=(1-忙时SDCCH溢出总次数/忙时SDCCH试呼总次数)*(1-忙时话音信道溢出总次数/(忙时话音信道试呼总次数(含切换)))*100%,即为手机成功占用信令信道和话音信道的百分比。
5)忙时话音信道拥塞率:
=忙时话音信道溢出总次数(含切换)/忙时话音信道试呼总次数(含切换)*100%。
拥塞较大的站点需要及时进行扩容。
6)最坏小区:
其定义满足以下两个条件:
i)话音信道掉话率(含切换)大于3%且每信道话务量大于0.1爱尔兰且小于0.6爱尔兰的小区;
ii)话音信道拥塞率(不含切换)大于5%的小区。
1.1.1.9核对网络码的重要性
【作者姓名】:
许波
【现象描述】:
北京中国移动研发中心配合做2G、3GA口兼容性测试。
由于现场版本太低,首先记下原始数据(未仔细注意网络码),然后对服务器和OMCR升级,开通机房测试环境的V2基站,出现基站无信号输出,在检查A口无问题后,跟踪信令、检查基站配置(此时还未发现网络码错误的问题,我原以为在移动公司做测试,网络码肯定是0),MSC侧显示无法识别的位置区码。
导致白白浪费公司测试部同事半天工作时间。
【解决方案】:
后查明,MSC侧对网络码的设置是9,因为是测试环境,未与现网对接。
将网络码设置成9后,故障消除。
1.1.1.10新开局,与爱立信核对A口数据。
【作者姓名】:
许波
【现象描述】:
与爱立信MSC对A口时发现:
A口时隙只有1和2正常,其他的时隙占用时双向无声。
【解决方案】:
检查MSC的A口配置数据,发现A口CIC从33开始,33、34、36、37、38……没有35(一般是不会出现这种低级错误,但也要仔细检查),重新配置A口数据后,A口时隙占用正常。
核对数据首先检查CIC,选择PCMNO=0,CIC即从1开始,PCMNO=1,即CIC从33开始。
SLC是否一致!
然后看CIC是否有误!
1.1.1.11在新开局前开通测试站做通话测试,发现通话4分钟后自动中断。
【作者姓名】:
许波
【现象描述】:
在新开局前开通测试站做通话测试,发现通话4分钟后自动中断。
【解决方案】:
登录客户端在“字符窗口”中用人机命令执行下面的命令:
NSTM:
EBSCID=?
:
TMIAR=10000; (其中?
号为BSC的编号)
1.1.1.12 BNET背板造成MPMP、MPPP内部备份链路通信断
【作者姓名】:
蔡晓丹
【现象描述】:
BSC上电后台配置完BSC数据后,中心模块第一块MPMP和MPPP始终告警内部备份链路通信断。
用后台测试管理中内部链路测试管理功能进行测试,通信正常。
【解决方案】:
进行排查硬件故障原因,倒换相关主备单板及槽位、倒换背板HW线、倒换中心模块与外围模块的背板,都无法消除故障点,最后找到一块从其他地方更换下来的老的BNET背板更换上去后,告警消失,据此判断,是BNET背板故障导致内部备份通信断。
1.1.1.13后台监测小区切换方法
【作者姓名】:
张运刚
【现象描述】:
在站点运行后需要验证站点各小区的切换是否正常,通常需要到站点测试,但是借助后台监控配合会更方便一些。
【解决方案】:
在客户端性能管理-性能管理-观测任务-创建然后选择观测类型,创建完成后再在观测任务中选择事件观测过几分钟出现小区切换了就可以看到切换的详细内容了
1.1.1.14解决数据探针看不到内容的故障
【作者姓名】:
王映
【现象描述】:
安装数据探针,testip设为10.157.153.20,与客户端在同一网段内,复位MP后,可正常连接winnttcp,但探针内看不到任何内容,无错误提示。
【解决方案】:
将testip最后一位改为80(大于65即可),复位MP后,探针应用正常。
1.1.1.15 解决V2基站小站型配置时分路器不匹配故障
【作者姓名】:
王映
【现象描述】:
新开某V2S111基站,由于现场没有人员,后台按以往经验配置合路器、分路器均为CDU,TRX在每框最左侧,上电后右侧CDU报“AEM类型告警”,所有载频闭塞。
【解决方案】:
将右侧CDU由10M改为8M,故障依旧,将右侧CDU改为RDU后,告警消失,基站运行正常。
经验:
V2小站型,若每小区载频数小于3个,为节约成本,分路器可用RDU代替CDU。
1.1.1.16移动三期亿阳网管取个别性能数据与omcr客户端有区别的解决
【作者姓名】:
吴健文
【现象描述】:
亿阳网管采集性能数据时,出的报表中的两项参数:
切换请求总次数切换成功总次数与我们omcr客户端提取的性能报表对应项的值不一致。
【解决方案】:
移动三期网管接口文档定义不一致是产生问题的原因,和亿阳方面沟通,需要将以上两个性能统计对应数据库字段改为:
忙时切换请求总次数=C11617+C11668-C11675
忙时切换成功总次数=C11618+C11669-C11675
问题解决。
1.1.1.17基站在BSC告警中显示异常
【作者姓名】:
王龙
【现象描述】:
基站开通时,设备运行正常,可以打电话,在BSC动态数据管理中显示占用正常,但是在告警管理中显示断站
【解决方案】:
检查告警,发现在基站已经无LAPD告警,但是在BSC侧还有LAPD断链告警.删除BSC的LAPD告警,故障消除.询问办事处人员,得知该站曾重做数据,但站号没有改.分析,应为重新配置数据后原来的LAPD告警没有消除造成.
1.1.1.18 绵阳移动新开局通话4分钟左右开始断话的处理
【作者姓名】:
黄平
【现象描述】:
在新开BSC下挂站测试时,出现通话4分钟就自动掉话的问题
【解决方案】:
1、现象分析属于A口配合问题,原因出在No.7的定时器参数设置
2、处理办法是在客户端的系统工具的字符窗口里进行对相关定时器修改.
3.登录客户端在“字符窗口”中用人机命令执行下面的命令:
NSTM:
EBSCID=8:
TMIAR=6000;(8为BSC的ID号)
1.1.1.19 通过查看t_biecom.zdb,确认载频LAPD在PCM中占用的时隙
【作者姓名】:
田辉
【现象描述】:
我们在用OCEAN仪表对Abis口进行信令跟踪的时候需要知道某一站点甚至载频的LAPD信令链路在整个PCM中占用的是哪个时隙。
在OMCR客户端上是没办法查看的。
我么可以通过查看ZDB表-t_biecom.zdb来得到答案。
【解决方案】:
查看ZDB表-t_biecom.zdb(该表为每个外围模块下面都有一个该表),可以查出来某个站点的某个载频的LAPD信令在PCM传输链路中占用的时隙。
该表中的第5个字段的“biets”就是某载频对应的LAPD时隙字段。
第1个字段No-序号
第2个字段PhySiteNo-站点编号
第3个字段RackNo-站点机架号
第4个字段BiePCM-站点PCM传输的序号,有些站点1条传输,有些站点为2条传输(超过13个载频的时候就要求2条传输了)
第5个字段BieTs-载频或站点的LAPD时隙
第6个字段BieSubTs-HW子时隙
第7个字段Kind-PCM时隙的种类(1为话路时隙,2为站点LAPD时隙,3为载频LAPD时隙)
第8个字段DestPhySiteNo-站点编号
第9个字段DestRackNo-站点的机架号
第10个字段ShelfNo-机架的机框号
第11个字段PanelNo-机框的槽位号
1.1.1.20创建新的测量任务时报错,提示“BAF和MP断链”
【作者姓名】:
田辉
【现象描述】:
在OMCR客户端中的“性能管理”-“性能管理”-“测量任务”中创建新的测量任务的时候,老是失败,提示错误码为30002,“BAF和MP断链”。
无论创建任何测量任务都是这样不能成功。
【解决方案】:
经查发现BSC只有2个模块(1个中心模块,1个外围模块),而在OMCR配置文件bsccfg.ini中的两个字段的值为:
“ModuleNum=4,LocalModuleNum=4”,将其这两个字段的值改为2后重启BAF进程,再进行创建测量任务的工作,成功了,问题解决了。
1.1.1.21BSCV2中GPP板异常的解决方案
【作者姓名】:
曹红元
【现象描述】:
在集成管理配置,软件装载完成后,所有的PP单板和EDRT板不能正常启动。
版本问题排除在外,接下来就是背板连线,在仔细检查后,我们确认无误;由于是实验环境,我们只有一块MPPP板,插在16槽位,后台并没有告警,该框15槽位本来就没有插板子。
【解决方案】:
MPPP差在15槽位后正常。
1.1.1.22TRMG本振PLL失锁问题的思考
【作者姓名】:
曹红元
【现象描述】:
青海海西州天棚基站二小区副机架的TRMG板出现发射射频本振PLL失锁、TRX与BSC的通讯链路断的告警,在机房对二小区进行远程复位后告警消除,第二天又出现了同样的问题,远程复位无效,到达基站发现二小区副机架的CMM板状态正常,TRMG板的指示灯STA为红灯常亮、MOD为红灯慢闪。
【解决方案】
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 上海用服部 ZXG10BSS 份工程经验汇总 上海 用服部 工程 经验 汇总
![提示](https://static.bdocx.com/images/bang_tan.gif)