用服部工程经验汇总

GU用服部ZXG10-BSS工程经验汇总（2023年07月）中兴通讯股份有限公司移动产品支持中心GU用服部目录TOC\o"3-3"\h\z\t"标题1,1,标题2,2"第1章业务类 1-11.1V3业务类 1-11.1.1某一个社区的切换失败率忽然提高了很多 1-11.1.2DSP监听工具进行单通定位 1-11.1.3ZDB损坏引起OMP重起 1-11.1.4iBSC告警箱调试时无法与后台建链 1-21.1.5iBSC下的卫星开通问题的解决 1-21.1.6传输正常基站不能运营 1-31.1.7UIMC板出现“单板输入时钟丢失”告警 1-41.1.8OMP单板反复出现“OMC的网关掩码与数据库配置不一致”的告警 1-41.1.9手机不能正常注册入网 1-61.1.10某BTS所有载频总是出现过温告警并不定期重启的故障解决 1-61.1.11传输高误码导致iBSC下站点Abis资源闭塞，导致TCH指配失败 1-61.1.12SBCX开局FTP故障一例 1-71.1.13基站环境监控无法上报的解决 1-71.1.14新开M8202基站开站正常一个多月后就不发功率了 1-81.1.15新开站点无法开通的因素排查一例 1-81.1.16Abis口时隙根据实际情况合理配置避免话路拥塞 1-91.1.17CDU类型错误导致TCH指配异常 1-91.1.18A口PCM链路部分时隙双向无声故障解决 1-121.2V2业务类 1-121.2.1PUC告警问题解决 1-121.2.2许可证更新问题 1-131.2.3比较特殊的BSC的基站数据不能下发的问题 1-131.2.4静态HR改动态HR开通 1-141.2.5BSC扩容外围模块出现P0-Pn通讯断问题解决 1-141.2.6BSC外围模块基站掉站故障一例 1-151.2.77号信令瞬断问题的解决 1-15第2章网管类 2-12.1V3网管类 2-12.1.1MINOS400系列版本中表空间创建的注意点 2-12.1.2数据库实例的字符集设立错误引起ISMG安装失败 2-12.1.3iBSC性能数据提取相关设立 2-42.1.4Sqlserver公司管理器中查询不到性能数据问题解决 2-52.1.5在调试iBSC的时候无法上报社区性能 2-52.1.6iOMCR与前台OMP断链故障查询 2-52.1.7“应用服务器的硬盘可用空间超过”告警 2-62.1.8严重驻波比告警 2-72.1.9MINOS提取不到性能数据 2-72.1.10如何安装MINOSV3.10.400f并与上级网管对接 2-82.1.11通过MINOS日记拟定和上级网管间的告警SOCKET是否正常工作 2-82.1.12NFS自启动和守护进程启动方法 2-92.1.13在iOMCR的客户端不能登录系统管理 2-102.1.14后台构造OMP时需要选择对的的OMP类型 2-122.1.15在WINDOWS系统中安装iOMCR时，不能创建成功数据表空间 2-132.1.16前台软件版本错误导致NFS故障 2-132.1.17ISMG软件版本升级故障解决一例 2-152.2V2网管类 2-152.2.1性能管理任务不能删掉 2-152.2.2V2网管下提高MMI下发速度的方法 2-162.2.3客户端告警内容乱码解决 2-172.2.4软件入库错误 2-172.2.5用脚本下发数据失败案例 2-182.2.6某DB2局服务器异常掉电后无法正常启动OMCR 2-192.2.7OMCRV2进程异常一例 2-20第3章设备类 3-13.1V3设备类 3-13.1.1单块CMB板出现“CMM/CMB备板工作是否正常” 3-13.1.2iBSC系统中如何配置GPRS链路数据 3-13.1.3跨BIPB单板站点Abis资源调整方法 3-53.1.4iBSCV3设备基站数据规划、数据添加过程中注意事项 3-53.1.5在OMP上直接修改MAC地址的方法 3-73.1.6SBCX外接显示器黑屏 3-73.1.7OMP网关和掩码异常变化的问题 3-83.1.8用telnet命令初始配置S8001的IP 3-83.1.9支持不同网段的IPBB端口配置注意事项 3-103.1.10iBSC上的接续 3-143.1.11iBSC开局调测时两个机框不能加载启动正常 3-143.1.12SBCX开局时不规范操作导致NFS故障解决一例 3-163.1.13基站故障排查一例 3-173.2V2设备类 3-173.2.1MP拨码错误导致MP工作异常一例 3-17第4章工程类 4-14.1.1工程问题导致的GPRS故障 4-1业务类V3业务类某一个社区的切换失败率忽然提高了很多【作者姓名】ShahidParvez【问题描述】某一个社区的切换失败率忽然提高了很多，看其他指标都没有问题。【解决方案】查看硬件和其他指标也正常，怀疑是时钟出了问题。集成管理上把基站的时钟类型由内同步更改为网同步，切换指标正常。因素在于站点以前采用内同步，但是CMM板的时钟超过范围，导致切换成功率差。解决方法有两个：一是校准CMM板的时钟基准，二是在传输质量好的情况下，更改为网同步。DSP监听工具进行单通定位【作者姓名】刘光华【问题描述】使用DSP监听工具进行单通问题定位及排查。【解决方案】ZDB损坏引起OMP重起【作者姓名】斯勤勇【问题描述】在开局过程中OMP不断重起。【解决方案】重传ZDB，详见附件：iBSC告警箱调试时无法与后台建链【作者姓名】周军【问题描述】现场在iBSC系统下配置告警箱。现场系统配置为MINOS+SBCX+OMP。后台采用MINOS客户端登陆并对告警箱进行配置，同时告警箱IP网段配置和ISMG地址同一网段，但配置完后，告警箱始终和iOMCR无法建链。【解决方案】1．通过告警箱液晶屏操作并设立告警箱IP地址/服务器IP地址/端标语；注：这里告警箱IP需设立为MINOS服务器的IP同一个网段（这里以MINOS客户端设立告警箱为例）2． 登陆MINOS客户端设立告警箱IP以及端标语（端标语可默认6800）；3． 至此假如以在MINOS服务器上可以ping通告警箱为前提，那么此时告警箱是可以正常上报告警的。iBSC下的卫星开通问题的解决【作者姓名】吴健文【问题描述】某局现场开通卫星站的时候，BTS始终无法正常开通，CMB不断复位重启。检查了基站拨码和传输误码没有发现问题。【解决方案】通过查看信令和LAPD板打印，发现软件激活已经成功，但是LAPD配置下发时，基站侧始终无响应。查看udpwatch工具录下的LAPD板打印。出现以下打印：->BTS(Tick:NS:0NR:1):10800008035A54459E00FFFFFF58C3E0发0号帧[SM]:MulFrameEst_T200Expiry->BTS(Tick:NS:0NR:1):10800008035A54459E00FFFFFF58C3E0700ms超时重发0号帧BTS->(Tick:NS:1NR:1):808000920A00FFFFFF16000041008742730ms后才收到BTS的确认看到的双向延迟在730-750ms左右，超过了iBSC所能承受的延迟时间700ms。该问题已经在iBSCV6.00.013D版本中解决。传输正常基站不能运营【作者姓名】张帆【问题描述】某站点为方舱V2站点，属于900M和1800M共站站点。故障现象为1800M基站可以正常运营，900M【解决方案】1． 对基站传输环回测试，显示正常。2． 查看拨码开关的拨码，设立对的。3． 与上级站点进行传输互换，传输互换后2个站点都没有起来。（上级站点也是V2的且900M和1800M共站）4． 初步定位为故障传输也许有问题。将上级站点传输通过微波的第二条传输环回后，上级站点站点恢复正常运营。怀疑从上级站点到BSC侧传输或者数据也许有问题。5． 从上级站点带了一块备用CMB到故障站点，将故障站点传输连接到上级站点。将上级站点所有CMB取出，把那块从故障站点取来的CMB插上后站点正常起来。6． 查看CMB的版本信息，发现CMB版本太老，不能在V3iBSC下运营，更换成新版本后仍然没有解决。7． 在iBSCDDF侧将上级站点和故障基站的物理端口进行更换，上级站点还是不能起来，而故障站点还是可以正常运营。8． 在iBSC侧，查看该基站所在DTB板闪灯正常，查看传输打线也正常。由于之前已经更换过iBSC上端口，既也排除了iBSC端口以及单板问题。所以考虑到也许上级站点所占LAPD时隙有问题，在更换控制时隙16，31，30都不行的情况下，尝试了不删除原数据，只是新做一个同样配置的站点数据后，将上级站点挂在新做基站数据下，基站正常运营。【故障总结】该站点的故障是由2个因素导致的，1． CMB版本问题，V2BSC下的基站割接到V3基站下需要一个过渡版本。2． iBSC所随机分派的LAPD时隙，或者相应的LAPD板有问题，所以才导致了这个基站不能正常运营的主线因素。注：当基站配置时，LAPD时隙是自动分派到基站。但是一旦分派了以后，这个LAPD时隙就固定这个基站（数据）上了，除非删除重新做基站数据，否则不能改变这个基站的LAPD时隙。UIMC板出现“单板输入时钟丢失”告警【作者姓名】陈辉【问题描述】某局开局过程中互换框UIMC板子出现“单板输入时钟丢失(1286)”告警，导致整个互换框所有单板时钟异常。【解决方案】经仔细检查发现CLKG后插板输出至RIM板时钟线是用来接UIMU后插板RIM2、RIM23板的。把CLKG后插板输出至RIM板时钟线序及时更正后问题彻底解决。【故障总结】CLKG后插板时钟输出线是1拖8的，至RIM和RIM2/3板时钟线序不同，接线时需要特别注意分清楚。OMP单板反复出现“OMC的网关掩码与数据库配置不一致”的告警【作者姓名】陈辉【问题描述】某局开局过程中，OMP单板反复出现“omc的网关掩码与数据库配置不一致(5393)”的问题。【解决方案】1． 使用PC机通过串口连接到OMP查询到前台OMP网关掩码是。2． 再检查iBSC后台设立的OMC的网关掩码为，如下图所示3． 检查iBSC后台单板服务器网卡的网关掩码，如下图所示4． 修改iOMCR中配置的OMC的掩码。5． 修改和ISMG单板服务器网卡的网关掩码进行更改与前台OMP网关掩码，然后在后台动态管理对OMP进行手工复位后告警消失。【故障总结】更改后台OMC和ISMG单板服务器网卡的网关掩码要对OMP进行复位重读网关掩码，也可以在后台重启ISMG单板服务器进行更新网关掩码，两者方法选择其一就可以。手机不能正常注册入网【作者姓名】吴雷【问题描述】手机不能注册入网，能看到基站很强的信号，但是被拒绝登入。【解决方案】1． BSC全局复位，OMP复位，基站复位。2． 查看基站CMB板闪灯，发现clock灯慢闪。3． 经查是由于传输线路接头松动导致。把传输从新做线后，CMB的闪灯常亮绿灯，载频正常工作，问题解决。某BTS所有载频总是出现过温告警并不定期重启的故障解决【作者姓名】门辉【问题描述】基站所有载频总是出现过温告警，并随着有CMB的“HDLC链路断”告警，“AEM不在位告警”。【解决方案】机房温度并不高，设备温度也正常，将所有载频功率减少2dB，告警消除。传输高误码导致iBSC下站点Abis资源闭塞，导致TCH指配失败【作者姓名】段永刚【问题描述】1． 拨打电话提醒网络忙，或者接通后立即“嘟嘟”响。2． 用户所在基站无异常告警，基站信道状态正常，但SDCCH有占用，TCH无占用。3． 基站的Abis状态：所有abis资源闭塞。4． CS信令显示有非常多指配失败，因素：无可用无线资源。【解决方案】1． 通过3G平台工具的性能记录里的记录功能，发现该基站传输误码率非常高，达成万分之8000左右。2． 基站相应的PCM有很多次TIS告警。3． 更换传输后，故障解决。说明：iBSC管理的abis资源不再固定分派给某个基站、某个载频，与基站松散耦合的Abis资源有问题，也会导致在该基站下呼喊异常。因此建议碰到类似故障，对于iBSC管理的abis资源与基站硬件都要仔细排查。SBCX开局FTP故障一例【作者姓名】黄孝国【问题描述】1． 前后台建链正常，并可以进行整表同步；2． 可以从OMP前台将版本软件拖回服务器;3． OMPftp和服务器的ftp功能都正常；但是从iOMCR客户端向OMP添加版本软件到网元失败，提醒FTP故障。【解决方案】经查，发现在/home/iomcr/ums-svr/deploy/perties中ftp服务器的IP地址设立错误:

#FTPConfiguration

#

userdefined-zxgsmomcr-ftpUser=uep#userdefined-zxgsmomcr-ftpPassword=uepuserdefined-zxgsmomcr-ftpIP=将userdefined-zxgsmomcr-ftpIP的值修改为iomcr服务器的IP地址，故障解决。注：不用重新启动iomcr服务器和ftp服务器。基站环境监控无法上报的解决【作者姓名】刘瑜【问题描述】开通站点的EASS时，无法监控到该站点的环境情况。复位主用CMB有2秒左右可以收到环境监控信息，两秒之后环境监控信息消失，更换MISU故障依旧。【解决方案】检查BTS（B8112）的SITEID拨码，发现关于下级站点级联的拨码不对的，改正后环境监控信息上报正常。新开M8202基站开站正常一个多月后就不发功率了【作者姓名】房广芝【问题描述】新开M8202基站开站正常一个多月后就不发功率了，该基站是S1/1/1配置，故障时有“SYNCLK时钟异常”告警，主柜正常、辅机柜起不来。【解决方案】1． 检查机箱主辅柜内外部的60ms时钟线缆，正常。2． 检查CMB板，没有问题。3． 经检测发现市电交流电压过低，调整市电后设备正常。新开站点无法开通的因素排查一例【作者姓名】卞福涛【问题描述】新基站所有载频都起不来。【解决方案】1． 检查数据配置无误。2． 传输正常，可以看到基站起站，但载频不断重启。3． 将此新基站（站A）与此外一个模块上正常运营的站（站B）互换PCM端口，站B的载频起不来，站A正常。4． 将另一基站挂接到站A故障时的PCM端口，基站正常，否认Abis口问题。5． 记录本模块所有基站的载频和PS静态辅时隙，发现总信道数目超过了HW：118×8＝944信道的限制。6． 记录所有模块的载频数和辅时隙，做模块间平横调整，问题解决。Abis口时隙根据实际情况合理配置避免话路拥塞【作者姓名】温腊勇【问题描述】某局iBSC下的一站点拥塞。【解决方案】检查数据发现该站点总共6个社区10个载频，CMB上的Abis时隙仅仅配置了3个64K时隙，最多容纳12人同时使用该站。为该站多配置一些abis口时隙即可。CDU类型错误导致TCH指配异常【作者姓名】何维来【问题描述】某基站第二社区的指配失败率非常高，切入成功率非常低，该社区下拨打电话非常困难，很难占到BCCH载频的TCH信道上。拨测发现被叫铃声有如下几种情况：1． 被叫手机可以一直响铃。2． 被叫手机没有响铃。3． 被叫手机有响铃，但瞬间停止。【解决方案】1． 该站点第二社区只有两块载频，对每个载频单独进行测试。2． 测试BCCH载频上的话音信道。3． 闭塞掉TCH载频，只保存BCCH载频上的话音信道，拨打正常。4． 测试TCH载频上的话音信道。闭塞BCCH载频上的所有话音信道，解闭TCH载频上的话音信道，无法打通电话，CS信令显示“TCH指派失败”，如下图所示：1． 将两块载频互换，重新按上述环节测试，测试结果与第一次一致，可以断定两块载频都没有问题。2． 将BCCH信道更改到本来的TCH载频上，发现该社区无信号。检查相应的CDU连线，发现CDU类型错误，1800频段的BTS使用了900频段的CDU，更换对的类型的CDU后，问题解决，对每块载频单独测试，都可以正常打通电话。同时解释一下故障现象中提到的三种被叫铃声的情况：1． 假如在该社区下拨打电话时指派在BCCH载频的话音信道上，被叫一直在响铃，属于正常状态。2． MGW下主叫在Callprocessing后，即开始寻呼。被叫先发指派TCH指派请求，然后是主叫发TCH指派请求。然下来有也许先指派主叫TCH，也有也许先指派被叫TCH，假如先指派主叫TCH，由于指派失败，立即就拆链，此时被叫不会响铃。3． 假如被叫TCH先指派完毕，被叫开始响铃，然后主叫TCH开始指派，由于指派失败，立即拆链，被叫手机有响铃，但瞬间停止。此外，通过拨打被叫号码发现（主叫号码），在被叫TCH指派请求后，再进行主叫TCH指派请求，然后接下来有如下几种情况：1． 被叫指派完毕，被叫响铃，主叫指派完毕，主叫放回铃音。2． 被叫指派完毕，主叫指派完毕，被叫响铃，主叫放回铃音。3． 主叫指派完毕，被叫指派完毕，被叫响铃，主叫放回铃音。A口PCM链路部分时隙双向无声故障解决【作者姓名】方淼清【问题描述】某局iBSC和华为软互换对接时出现双向无声。检查iBSC和基站状态都正常，没有异常告警和告知。【解决方案】1． 拨测发现有三条A口PCM电路的大部分时隙存在双向无声的问题。2． 更换另一条PCM的端口，拨测故障仍然存在。3． 将其中一条PCM物理电路（该电路不走信令）自环，拨测，MSC侧可以听到回音，iBSC侧听不到任何声音。4． 这三条PCM都由同一块DRTB解决语音，有也许是DRTB的问题。凌晨把DRTB和后面槽位还没有占用的DRTB进行互换，再进行指定中继拨打测试，正常。V2业务类PUC告警问题解决【作者姓名】朱杰【问题描述】某局BSC，GPRS模块四个SPCU单元的主用PUC单板陆续出现“PUC单板之间UDP以太网通讯断”告警，并且均是RACKNO3_SHEELFNO4_SLOTNO16主用PUC单板（复合单元号26PUC单元号0）与此外三个SPCU单元主用PUC单板之间的通讯断告警，而其他三个SPCU单元的主用PUC单板之间没有通讯断断告警，同时该PUC与各GDPP单板出现和PUC之间的UDP以太网通信断告警，但没有影响业务。【解决方案】对该PUC单板进行复位操作，主用倒换到原备用PUC所有告警消除，由此判断告警是PUC单板导致。许可证更新问题【作者姓名】胡晓岚【问题描述】某局，升级后，更新许可证时，licchk正常，但在运营licupd时，无反映，既不提醒更新成功也不提醒更新失败。【解决方案】1． 查许可证文献，没有问题。2． 查OMCPS进程，LMD进行运营正常。3． 经实验室验证发现，在OMCR重启时，由于在进行TOP树构建，因此系统没有输出结果，事实上已更新成功。规定在OMCR进程正常运营后，再进行许可证的更新。比较特殊的BSC的基站数据不能下发的问题【作者姓名】朱晓程【问题描述】海外某局，忽然发现基站数据不能下发，但是ICC解析正常。【解决方案】1． 多个客户端均由此现象。2． omcps检查服务器的进程，没有异常。3．df–k，服务器有足够剩余空间。4． 数据库剩余表空间较多。5． 同一个服务器管理的其他BSC，没有此问题。6． ZDB数据前后台一致。7． 同步数据不成功。查询单板状态：超时失败。8． 重启OMCR服务器端进程，该BSC的MP和PP等单板均变成slave状态。9． 话务量低时，重启MP，问题解决。结论：MP某些功能模块不能工作，重新启动之后，重新初始化恢复正常。静态HR改动态HR开通【作者姓名】朱明【问题描述】OMCR和BSC版本升级到297版本后，将本来开通的静态HR改成动态HR的方法。【解决方案】1． 删除本来的静态HR2． 入库BIPP板的FPGA版本，并设立一类软件版本3． 更换新的BIPP板，设立拨码开关4． 在客户端的命令窗口执行命令：EBCM：BSCID：NEWBIPP：T；执行上述命令，一方面需要编辑client\dat\cm.crf下的ebcm[SpType:INT(1，3)]/*信令点类型*//*[NewBIPp:BOOL]是否使用新BIPP*/改为:[SpType:INT(1，3)]，/*信令点类型*/[NewBIPp:BOOL]/*是否使用新BIPP*/5． 集成配置中，配置支持动态HR相关操作（根据升级文档中进行配置）BSC扩容外围模块出现P0-Pn通讯断问题解决【作者姓名】魏东东【问题描述】BSC扩容外围模块后，各板件没有告警。外围模块新开基站可以开通，但是不能正常打电话。从动态管理观测，站点信道有P0-Pn通讯断告警。【解决方案】经查该问题是由于外围模块BIPP与BNET后背板的连线接触不好导致。BSC外围模块基站掉站故障一例【作者姓名】冯浩然【问题描述】备用MP升级完毕，倒换MP，主备mp都同时不断复位。该模块所挂基站都无法建链，处在退服状态。【解决方案】将备用的右边mp关电，只留一块左边的mp。唯一的mp可正常启动，但是一插入mpmp板就不断复位，更换mpmp板，故障依旧。将MPMP插紧，故障消除。7号信令瞬断问题的解决【作者姓名】杨勇【问题描述】某局几个BSC的7号信令链路经常瞬断，连续时间非常短，且现象不同，有些BSC是其中的某几条瞬断，有个BSC是所有的信令同时瞬断，尚有个BSC是有一半的信令同时瞬断。【解决方案】针对这几种情况，现场分别有不同的解决方法。1． 部分信令瞬断：检查相应的PCM是否瞬断，若没有，则检查相应的TIC，把TIC（ETIC）和别的TIC进行对调。2． 所有信令都有瞬断：检查SYCK板，若主用SYCK的状态不是正常的TRACING状态，而是CATCH状态。而备用的SYCK状态正常，若倒换SYCK倒换后，信令瞬断告警消失，说明本来主用的SYCK板存在问题，需要更换。3． 有一半的信令出现瞬断：检查发现这一半的信令都是由一块MTP板解决的，因素也许在于这个MTP板有异常，通过更换这块MTO板，恢复正常。网管类V3网管类MINOS400系列版本中表空间创建的注意点【作者姓名】舒宏【问题描述】MINOS的最新版本为400f，在创建表空间时选择中模式，需要200g左右的磁盘空间，脚本文献执行完毕后，发现只有30多g的空间被划提成表空间，与实际不符。【解决方案】这个情况是MINOS在400系列版本中的改善，以前300系列的MINOS版本中，假如选择中模式创建表空间，则会预先划分200g左右的空间，而在现在400系列的版本中则先创建大约30g左右的表空间，实际空间会随着以后数据容量的增大自动变大。数据库实例的字符集设立错误引起ISMG安装失败【作者姓名】陈琦【问题描述】安装ISMG过程中碰到如下打印：[2023-06-2020:02:42，510]WARN-Thexmlfileof'setup/solaris/conf/common-i18n.xml'containsnolabelwhosekeyis'insertinitialdatainsertintoPM_QOSTYPEDEF_TABLE(NETYPEID，QOSTYPEID，QOSTYPENAME，QOSTYPEDES，QOSTYPEHTMLDES)*ERRORatline1:ORA-00001:uniqueconstraint(UEPPM.UID_PM_QOSTYPEDEF$NETYPE$NAME)violated'[2023-06-2020:02:43，448]INFO-结束，安装失败。【解决方案】故障因素为数据库实例的字符集设立错误，字符集无法修改只能删除并重新创建数据库实例。1． oracle用户登录SBCX，登录时注意语言选择中文（简体）2． sqlplussys/oracle@gomcrassysdbaSQL>select*fromnls_database_parameters;查看结果中的字符集，假如不是ZHS16GBK，说明字符集错误NLS_CHARACTERSETZHS16GBK3． 假如确认字符集错误，运营dbca4． 选择删除数据库，下一步5． 点击完毕，删除数据库实例6． 再次运营dbca7． 选择创建数据库实例8． 创建实例的环节可以参见6.00的安装文档9． 指定字符集的时候按下图选择10． 数据库实例创建完以后再重新安装iOMCR。iBSC性能数据提取相关设立【作者姓名】张彦栋【问题描述】现在ISMG要能正常提取性能数据必须手动设立，所以在新开一个iBSC以后，需要修改相关设立，性能数据才干正常提取。【解决方案】见附件文档。Sqlserver公司管理器中查询不到性能数据问题解决【作者姓名】方淼清【问题描述】1． 开局时，检查预先安装好的SVR服务器，在任务管理器进程中可以看到Front.exe及nfsSvrDetect.exe在运营；串口登陆到OMP下MPX86_2->提醒符下，键入NfsShowState（回车）显示正常。2． Serv-Uftp服务器已经启动且域在线，在iOMCR上观测告警，不存在OMP与前置机通信断告警。3． 从iOMCR可以ping通SVR板的IP，但是在Sqlserver公司管理器中查询不到性能数据。【解决方案】查看SVR板FTPRoot\nfsDev\iBSC\OMS\log目录日记中有“[Microsoft][ODBC驱动程序管理器]未发现数据源名称并且未指定默认驱动程序”错误，检查后发现预先安装时，数据源(ODBC)]中配置系统DSN数据源错配成用户DSN数据源，重新配置后恢复正常。在调试iBSC的时候无法上报社区性能【作者姓名】田勇军【问题描述】在平台进行性能分析中，无法读取到社区性能数据。【解决方案】检查各项参数设立以及环境设立、目录权限，在/nfsDev/iBSC10/OMSZIP/PM下可以找到zip文献并且时间最新，需要有基站运营才会有性能数据上报。iOMCR与前台OMP断链故障查询【作者姓名】李伟【问题描述】iOMCR和OMP断链，如图中的标记，该位置显示的是断开状态。【解决方案】由于OMCR服务器和OMP在不同的网段且通过防火墙连接。OMCR服务器的两个网卡各有一个IP地址分别为：79和78.OMP的IP地址为6。开放78至6的所有端口后仍然断链，OMP和OMCR服务器无法通信。但当开放79至6的所有端口后可以OMP和OMCR可以正常通信。因素：oracle的监听是在79上启动的，但是iOMCR服务器的相关配置文献都是配置为78.这样配置后，oracle可以正常启动，iOMCR也可以正常启动。但是假如仅仅开放78的所有端口是无法和OMP建链。需要同时开放79的端口。解决方法：把oracle监听的IP地址改成78后就仅仅需要开放78的所有端口即可和OMP建链。“应用服务器的硬盘可用空间超过”告警【作者姓名】何超瑜【问题描述】ISMG客户端告警管理界面出现“应用服务器的硬盘可用空间超过”告警，具体信息为：应用服务器HD/dev/sdb1可用空间太少(门限是1000MB，现在是178.22MB)【解决方案】在系统管理-〉应用服务器管理-〉性能监控配置里面，有个剩余空间小于1000m报告警，默认是1000m，/boot目录只有200m，低于门限值，所以报了这个磁盘空间不够的告警，事实上200m的空间只使用了11m，把这个1000改成150即可。严重驻波比告警【作者姓名】濮广奇【问题描述】严重驻波比告警，事实上通过驻波比测试仪检查，驻波比并不高。【解决方案】1． 某社区只有两块载频，发射都接在左边的CDU上，但右边的CDU上有严重驻波比告警，测试后，驻波比并不高；2． 更换CDU后故障依旧；3． 在避雷器处互换该社区的两根天馈，在右边CDU位置，仍然有严重驻波比告警；4． 判断故障应当跟设备有关；5． 打开后门，重新拔插了载频背板上的告警线缆，CDU上驻波比告警消失。MINOS提取不到性能数据【作者姓名】舒宏【问题描述】MINOS提取不到性能数据【解决方案】MINOS上提取不到性能数据，一方面要检查iOMCR上能否取到性能数据，否则检查MINOS。本例是由于SBCX上的系统时间不对导致。由于SBCX上的系统时间不对，与实际时间不一致，导致MINOS上取不到性能数据，修改SBCX上的时间后，MINOS上性能数据就提取正常了。如何安装MINOSV3.10.400f并与上级网管对接【作者姓名】李衡【问题描述】某iBSC开局过程中，需要安装MINOS并与亿阳上级网管对接【解决方案】MINOS版本：MINOSV3.10.400f+P001+P002+P003+P005安装环节和配置文献的修改过程，有附件。通过MINOS日记拟定和上级网管间的告警SOCKET是否正常工作【作者姓名】杨文【问题描述】如何通过MINOS服务器日记拟定当前告警SOCKET是否正常工作？如下提供两种方法，供参考。【解决方案】方法一：MINOS启动好15~30分钟后，打开../ums-svr/log中的文献名类似server-20230716-0433-49931.log的最新的日记文献，搜索如下关键字：1． sendalarmtonaf5（这里的IP需要换成现场使用上级网管IP，并且naf和IP之间没有空格）——假如在启动后的日记中可以搜索到，同时搜索不到下面的3个关键字，则意味着socket告警告知正常运营。2． errorwhenconnecttonaf——假如有上面的关键字，且无下面的2个关键字，则是上级网管问题，请上级网管重启，即可解决此问题。3． [com.zte.ums.MINOS.naf.rtalarm.fmnaf.RtAlarmDBService]errorwhengetDBconnection4． loseconnectiontonaf5whensendalarmtonaf:（这里的IP需要换成现场使用上级网管IP，并且naf和IP有空格）。假如有3）或4）中的关键字，则说明需要替换..\ums-svr\MINOS\MINOS-naf-rtalarm.par\下面的MINOS-naf-rtalarm.jar（附件提供），重启MINOS即可。方法二：查看perties文献中nafx.port值（x=1，2，3。。。），假定为3010，则输入$netstat-a|grep3010，假如显示naf1的端口为LISTEN状态，则说明告警SOCKET正常工作。NFS自启动和守护进程启动方法【作者姓名】张健【问题描述】NFS自启动和守护进程启动方法【解决方案】1． 随SBCX板上的linux自启动：（1） 把ismg文献放入/etc/init.d/目录（2） 以root用户执行#chownrootismg#chgrprootismg#chmod755ismg#ln-s/etc/init.d/ismg/etc/rc0.d/K10ismg#ln-s/etc/init.d/ismg/etc/rc5.d/S99ismg注意：ismg文献要相应现场环境修改，修改一下两个变量：ISMG_HOME=/home/iomcr/ums-svr ISMG_OWNER=iomcrISMG_HOME是服务器端的目录ISMG_OWNER是启动服务器的用户名2． 设立cron方式启动nfsdetect，这样使系统定期自动检查nfsdetect进程的存在，若不存在则自动启动版本说明中的内容Nfs守护进程启动：使用系统的CRON功能定期调用nfsDtctCron脚本Solaris(linux)版本：（1） 使用iomcr用户登录。（2） 使用exportEDITOR=vi修改EDITOR环境变量，可以用vi来编辑crontab文献。（3） 使用crontab–e编辑crontab文献，在crontab文献中增长下列几行：OMCHOME=/home/iomcr/ums-svr13****$OMCHOME/tools/nfsdetect/nfsDtctCron28****$OMCHOME/tools/nfsdetect/nfsDtctCron43****$OMCHOME/tools/nfsdetect/nfsDtctCron58****$OMCHOME/tools/nfsdetect/nfsDtctCron需要注意：1． 不要破坏原有的系统定期执行的内容，同时修改时不能有空行。2． OMCHOME变量的途径需要根据实际情况进行设立。注意：$OMCHOME/tools/nfsdetect/nfsDtctCron当前用户需要有该文献的执行权限。在iOMCR的客户端不能登录系统管理【作者姓名】成小文【问题描述】iOMCR客户端的系统管理里以system用户登录iOMCR1数据库，密码输oracle不能登录，也许设立了这个用户的权限或改变了这个用户的密码。或者数据库不正常。iOMCR1登录时客户端提醒如下【解决方案】telnet到iOMCR1上，sys用户进入sql正常，监听正常，说明数据库正常，用system用户登录sql，提醒为system用户帐户被锁和权限不够。-bash-3.00$sqlplus/nologSQL*Plus:Release.0-ProductiononWedJul1617:29:072023Copyright(c)1982，2023，Oracle.Allrightsreserved.SQL>connectsystem/oracle@gomcassysdba;ERROR:ORA-01031:insufficientprivilegesSQL>exit-bash-3.00$sqlplus/nologSQL*Plus:Release.0-ProductiononWedJul1617:33:212023Copyright(c)1982，2023，Oracle.Allrightsreserved.SQL>connectsystem/oracle@gomc;ERROR:ORA-28000:theaccountislocked故障解决：telnet到服务器上，执行sqlplussys/oracle@gomcrassysdbaSQL>alterusersystemaccountunlock;在客户端试可以正常登陆数据库.问题解决，因素为保证系统安全，oracle的系统用户被锁。后台构造OMP时需要选择对的的OMP类型【作者姓名】陈亮【问题描述】OMP构造完毕后，OMP可以下载ompcfg.ini文献和单板运营的版本文献，但是OMP单板不断的反复重启。【解决方案】1． 检查OMP的前台构造配置，各项参数对的。2． telnet登录到OMP后观测OMP状态是下载完版本文献后几秒钟就开始重启。3． 重新构造OMP后故障恢复。解决方法：后台重新选择对的的OMP类型并构造生成对的的OMPcfg.ini文献后，OMP重启后下载对的的构造文献即可。【故障总结】目前OMP反复重启的因素有三种：1． OMP缺少ZDB文献，由于没有配置文献，OMP不清楚单板配置类型间隔约10分钟后重启；2． 假如是4框标准机架。而在后台配置OMP时选择单框配置，由于所需要的功率负载不同，单框配置OMP无法带动四框配置，所以OMP反复重启；3． 在选择OMP类型时选择了MP+CMP+SMP的类型，与实际类型不符合，OMP版本下载后对配置环境检查有误，进行重启。在WINDOWS系统中安装iOMCR时，不能创建成功数据表空间【作者姓名】刘兆礼【问题描述】在WINDOWS系统中安装iOMCR时，不能创建成功数据表空间【解决方案】重新安装，在显示［数据库部署配置］界面后，在［表空间途径］下拉框中按需要输入统一途径，此表空间途径必须是已存在的目录，否则不能创建成功数据库表空间。前台软件版本错误导致NFS故障【作者姓名】黄孝国【问题描述】1． OMP经常重新启动，平均1-2小时就发生一次；2． NFS性能数据采集粒度中间时常有丢失；如下图所示：12：15到13：00没有性能数据。3． iBSC与OMP之间有时有断链【解决方案】1． 重传ZDB文献到OMP，然后重启OMP还是不能建链。2． 重启服务器，建链成功，但找不到nfsDev。3． Exc_OMP.txt文献只有下面两种犯错信息************************BeginofLastException************************Rack:1，Shelf:2，Board:11，Cpu:13GPlatdate:2023-05-1418:43:04WatchdogOverflowininterrupt1task"IDLE"sysexcmsg:_************************EndofExceptionInfo************************经分析，发现：前台iBSC的版本在安装时错误的上传为iBSCV6.10.001d，事实上我们应当使用iBSCV6.10.003d【故障总结】MP重新启动的问题，就是由于前后台软件版本不一致导致的。而nfs性能数据的故障的因素，正是由于OMP的重新启动，导致采集粒度丢失。在现场实际环境中，发现nfs故障和如下因素相关：1． 前台版本、OMP版本错误，导致单板故障；2． ISMG中的配置文献perties中的设立；3． NFS写权限问题及进程；4． ISMG中的管理网元ID配置错误；5． LinuxOS中环境变量设立:/iomcr/jdk-linux/bin用以压缩性能文献ISMG软件版本升级故障解决一例【作者姓名】黄孝国【问题描述】在S8001实验局进行iOMCR版本升级（iOMCRV6.10.000d升级到iOMCRV6.10.010b）中，发现在原版本iOMCRV6.10.000d下的配置数据，导入iOMCRV6.10.010b后，配置子树是空的。发现使用新版本的数据库+老版本的应用系统，配置文献可以正常显示；但是使用新版本的数据库+新版本的应用，原配置文献无法显示。【故障分析】新版本比老版本在全局管理页面中增长了一个数据表iBSC_HBARANG，该表导致iomcrclinet界面无法显示。【解决方案】新版本的Client中增长一个备用配置集，查询数据表iBSC_HBARANG中的记录；导入升级前的备份的配置数据，根据备用配置集（升级前的数据）ID，管理网元ID号等信息，增长iBSC_HBARANG中的记录即可。V2网管类性能管理任务不能删掉【作者姓名】ShahidParvez【问题描述】服务器跟MP链路正常，登陆的用户为root，但性能管理的任务一直不能删除。【解决方案】性能管理上BSC同步以后问题解决了。同步环节，打开性能管理--〉BSC上按右键--〉选synchronize.V2网管下提高MMI下发速度的方法【作者姓名】佘小宇【问题描述】大量修改数据时MMI下发速度影响工作效率，分析服务器负荷及IMF日记发现磁盘读写影响MMI下发速度。【解决方案】修改syscfg.ini文献中trace为0，不写进程log，修改imfcfg.ini文献中MTRANSRATE=6即每秒送6条MMI命令，并且在[LOGEXCLUDE]小节中增长MMIHEAD3=R即将RBTM命令不记入操作日记（oplog），重启IMF进程后对比MMI下发速度有很大改善。客户端告警内容乱码解决【作者姓名】胡晓岚【问题描述】在升级/安装过程中，假如没有对的设立define.sql文献中的语言，或者是在英文环境中，执行了中文环境的脚本，将导致告警内容乱码。涉及的表有：falarmcode、FINFORMCODE、pIndexFormula、FALARMREASON相关执行文献：在$OMCHOME\sql\libdata\english目录下【解决方案】1． 退出OMCR进程。2． 以omc用户进入sqlplus。3． 确认以下哪张表是中文sql>select*fromfalarmcode;sql>select*FROMFINFORMCODE;sql>select*frompIndexFormulasql>select*fromFALARMREASON4． 若有中文，请重新执行相应的脚本sql>@code.sqlsql>@informc.sqlsql>@pmindex.sqlsql>@reasonc.sql。5． 重启服务器。软件入库错误【作者姓名】范文欣【问题描述】BSC3共有4个外围模块，软件装载BTSV5.96.301A版本入库时候，2号模块的cmm_log入库提醒错误：此版本存在不能修改文献长度和校验。试图在软件装载界面中先删除掉入库的cmm_log软件，再重新入库，可删除入库软件也提醒错误：入库软件版本的相关MO实例号性属列表不为空。【因素分析】此时检查前后台版本数据发现情况：1． 前台MP的VERSION目录中有cmm_log文献名05000701.bin，文献大小1305342． 后台OMCR服务器的VERSION目录中存在两个cmm_log文献，一个是05000701.bin，文献大小130534，此外一个是05000203.bin，文献大小224233． 客户端软件装载中的入库软件2号模块cmm_log显示05000701.bin，文献大小224234． 前台2号模块的ZDB表r_swlib.ZDB表中记录的BTSV2_clg的文献名05000701.bin，文献大小22423【解决方案】因上述情况所以不能对2号模块所带基站复位进行版本升级，做了如下操作：1． 备份后台OMCR服务器的VERSION目录中cmm_log文献05000203.bin（文献大小22423），将其删除，将05000701.bin改名。2． 将前台2号模块的VERSION目录中cmm_log文献名05000701.bin改名。3． 再在软件装载中重新入库，依旧提醒相同错误。解决办法：1． 删除所有物理装载的V2版本，删除2号模块的cmm_log一类软件2． 在软件装载中删除入库2号模块的cmm_log软件，成功3． 重新给2号模块入库对的的cmm_log软件，成功。用脚本下发数据失败案例【作者姓名】李智超【问题描述】在升级完某海外现场的OMCR版本后，根据升级文档上的规定，升级新版本为2.97.003f后，需要拷贝脚本03fbts.pl到服务器，执行转换成MMI命令，通过client来进行下发．在client里，打开命令窗口，执行trans:c:/03fbts.MMI后，当进度到26%时，提醒失败。【解决方案】执行命令后，进度条正常显示，怀疑该脚本修改数据量比较大，在修改某些忙社区数据时，由于社区有话务在占用，导致执行超时，因而提醒失败；可以根据现场BSCID来进行依次下发，通过修改文献后缀MMI为txt，用写字板打开，根据BSCID，依次提取数据，重新保存后缀名为MMI的文献，依次下发，问题得到解决，下发成功。【故障总结】在以后用脚本进行数据修改时，不要一口气修改所有的数据，应当合理化来进行修改，避免下发失败。对于涉及到多个BSC的脚本时，需要按照BSC把脚本提成几个文献，依次执行，而不能一次执行。某DB2局服务器异常掉电后无法正常启动OMCR【作者姓名】钟振锋【问题描述】某DB2局服务器异常掉电，重新启动服务器后，在启动OMCR进程出现以下错误：$omcstartdb2Copythedb2processesRunOMCRwithdb2bindthepackagesfordb2Thedatabasealiasnameordatabasename"OMC"couldnotbefound.SQLSTATE=42705【解决方案】1． 由于是服务器异常掉电，怀疑系统文献有问题，使用fsck-y进行系统文献的检查修复，重启后还是有故障。2． 尝试连接数据库，出现以下错误：$db2connecttoomcSQL1013NThedatabasealiasnameordatabasename"OMC"couldnotbefound.SQLSTATE=427053． 检查数据库实例，数据库目录已空。$db2listdbdirectoryshowdetailSQL1057WThesystemdatabasedirectoryisempty.SQLSTATE=01606经研发初步分析，也许是服务器掉电时导致数据库编目录丢失，重新创建数据库编目录后，数据库连接正常，过程见下：检查$HOME/omc目录是否存在$ls$HOME/omcNODE0000$ls$HOME/omc/NODE0000SQL00001sqldbdir假如存在的话，执行$db2db2=>catalogdatabaseomcasomcon/export/home/omcdb2=>quit$db2terminate然后再连一下看看$db2connecttoomc数据库连接正常，重新启动OMCR进程，进程正常启动，故障解决。OMCRV2进程异常一例【作者姓名】刘宇宏【问题描述】某现场有V2OMCR服务器（双机＋磁阵）发生故障，客户端无法登陆，或者登陆后无法显示拓扑树。对OMCR服务重启后，用omcps命令查看进程，Daemon为true的只有5，6个进程，而正常2.97.000g应当有18个。重启SUN服务器，也是同样问题。查看nohup.out文献，发现下面异常：[omc@sunfirev490-1]$tail-fnohup.outException--OpenTraceFile:fatalerror，openfile/export/home/omclog/imf.20230717.logfailException--Opentracefileerror!!进入log日记目录，ls-limf*，发现从7月16日开始，天天生成的imf文献超过2G。其中很多都是与上级网管对接产生的信息，而的确是在16日凌晨对接NMS时，为了调试方便，将log日记等级从100（Error）改为5（Base_debug），产生了大量的打印信息，导致imf超大，从而OMCR进行无法正常打开imf日记文献，导致OMCR服务出问题。【解决方案】将超大的imf文献移除，并在conf/syscfg.ini里将TraceLev等级改回100，重启OMCR服务，一切恢复正常。设备类V3设备类单块CMB板出现“CMM/CMB备板工作是否正常”【作者姓名】濮广奇【问题描述】现场解决故障更换CMB板后，发现在主用CMB单板上出现“CMM/CMB备板工作是否正常”告警。【解决方案】1． 由于事实上只插了一块CMB单板，并且数据上也只配置了一块CMB板，所以怀疑这个告警不对的；2． 运用“AAAA”同步后告警仍然存在；3． 删除告警后，“AAAA”同步后告警又自动出现；4． 复位CMB单板，告警仍然存在；5． 在集成配置上添加备用的CMB单板后，发现告警转移到新添加的CMB单板上（事实上槽位没有单板）；6． 再将新添加的CMB单板数据删除，告警消除。iBSC系统中如何配置GPRS链路数据【作者姓名】李衡【问题描述】现场开通GPRS电路时，需要局方提供以下数据：NSEI，NSVCI，DLCI，RAC和接入速率；若开通两条电路，除了RAC和接入速率相同外，其他的NSEI和NSVCI及DLCI分别做在两条电路上，用来辨认电路；【解决方案】开通两条GPRS电路制作环节如下：1． 分别创建NSE，输入NSEI标记；如下图所示2． 分别创建两条承载信道，输入通道号，MCC时隙号（第一条从1开始，第二条从33开始），选择PCM号，输入接入速率（若局方给的接入时隙从1－31，起始时隙就是1，接入速率就是31）；如下图所示3． 分别创建NSVCI，输入NSVCI标记，选择NSEI，输入数据链路承载标记DLCI，最后选择链路号，与前面的信道相应；如下图所示4． 在物理2M对通的情况下，同步数据后，发现有链路故障告警，提醒NSEI，NSVCI不对，在核算一下数据配置，有无做错；5． 后台这边已经无告警，但SGSN那边出现物理链路未通，传输有问题的告警；检查GIPB板上的两条链路指示灯的频率，若出现快闪一段时间后，出现停顿，再次快闪情况，是配置GIPB板时，PCM选择的帧格式与SGSN那边不相应，需要重新删除数据，将PCM改为与SGSN相应的格式；iBSC默认为双帧格式，但江西移动这边使用的是多帧格式；帧格式不同，导致的iBSC后台未出现告警，但SGSN为链路断告警，同时GIPB板的指示灯为快闪一段时间后，出现停顿状态；指示灯快闪无停顿才算正常；6． 重新制作数据后，同步正常，GIPB板2M指示灯快闪，正常；有时候还是提醒链路故障告警，这个情况是iOMCR有BUG，无法删除原先的告警，只有删除GIPB板后，重新同步数据，再增长GIPB板，重新制作链路，同步数据才干告警消失；7． 路由码RAC在社区配置GPRS的时候才用到；版本信息：iBSC版本：iBSCv6.10.002k，iOMCR版本：iOMCRv6.10.100d跨BIPB单板站点Abis资源调整方法【作者姓名】孙海滨【问题描述】见附件。【解决方案】附件iBSCV3设备基站数据规划、数据添加过程中注意事项【作者姓名】贾耀鹏【问题描述】iBSC设备开局中，假如采用双机柜配置，要注意机柜资源的平衡，在平常的数据配置及维护中也要注意相关的事项。【解决方案】iBSC设备与V2平台的BSC设备在技术上有很大的不同，设备安装和数据配置之前，规划iBSC各部分资源。使得iBSC各部分CPU的占用率平衡，系统安全运营。需要规划的资源涉及：1． iBSC双机架设备，使用两个RCBU（基本配置单元），设计单个iBSC的载频容量为2048个，可管理社区为1024个，需要将单个iBSC的管理社区做规划，使得两个机架的资源管理平衡。2． iBSC设备对于信令的解决和各种控制面的解决重要是通过CMP进行，一个RCBU配置两块CMP单板（主备）：包含两个主用CPU，数据配置时，需要将单个基站归属到某个模块（即CMP的CPU），A口的信令链路的管理也是要归属到CPU模块，GB口的解决单板UPPB的DSP管理也要归属到CMP单板的CPU模块，这一块也需要具体的规划，尽量使得各CPU的负荷平衡。3． V3设备对于ABIS口传输资源的管理使用了动态Abis资源池的概念。对于LAPD采用了LAPD通道簇的概念，不再有直接到载频的LAPD通道，这点在做基站数据规划时要做的比较具体，现在一条E1传输可以承载业务的载频最大数量为15，通常情况一个站点最大的LAPD信道数为4。4． 由于LAPD通道簇的技术，基站配置的LAPD时隙越多，基站下载版本的速度越快，但由于一个RCBU可以解决的LAPD时隙数有限，所以不能每个站点都配置最大LAPD时隙，通常根据以下规则：6载频以下配置1条LAPD7～16载频配置2条LAPD17～26载频配置3条LAPD27以上载频配置4条LAPD对于基站的Abis资源池，也不是配置的越大越好，虽然有些站点传输资源充足，但资源池里E1时隙的数量应当按照需要配置，这个是由于受到BIPB单板的解决能力限制。BIPB单板有14块DSP，每块DSP可以解决60条话路，这样算来一个BIPB单板最多解决840条话路(即：ABIS资源池里840个时隙)，假如每个站点都配置所有的传输时隙：28条，那么一个RCBU配置3块BIPB单板，最多可以解决3×840÷28＝90个站点，假如这个时候你再配置第91个站点，就会出现BIPB资源局限性。基站的Abis资源池大小按照以下规则配置：Min（基站的E1传输×31－LAPD时隙数，基站载频数×2.5）5． 假如SPB单板配置了1条信令，那么该单板的最后一条E1时隙将不能再配置7号PCM强调一点：在iOMCR上做命令批解决时，确认没有其别人在iOMCR上做数据同步操作，否则会导致iBSC前台数据的混乱。在做晚批解决后，尽量做数据增量同步，不要做数据全局同步，假如之前做过数据全局同步，要保证在5分钟后再做同步操作，对于有多个终端的iOMCR服务器，各终端在做数据同步之前，告知各个终端，保证不会出现多个终端同时同步的现象。在OMP上直接修改MAC地址的方法【作者姓名】杨文【问题描述】一般情况下，修改OMP的MAC地址需要重启OMP后重新构造。此方法未免复杂。特提供在telnet上直接运营的命令，即可修改OMP的MAC地址。【解决方案】使用OSS_DbgSetOmcMac可简便的修改OMP的MAC。例如，OSS_DbgSetOmcMac0x0a，0x0a，0x0a，0x0a，0x0a，0x01表达将MAC地址修改为0.10.1，随后重启OMP即可使得修改后的MAC地址生效。SBCX外接显示器黑屏【作者姓名】李春宇【问题描述】SBCX板（已经预装的Linux系统）在上电后，有时会给出两个选项F1和F2，选择F1是进行BIOS设立，F2是载入缺省的BIOS设立，此时一定不要选择F2，选择F2将会出现黑屏的现象。【解决方案】暂时没有好的解决办法（重装系统是可以的）。该问题是可以避免的，提醒大家注意。OMP网关和掩码异常变化的问题【作者姓名】李伟【问题描述】通过串口线设立的OMP的网关和掩码产生变化。【解决方案】在串口配置好OMP的网关和掩码后重启查看信息对的，已经配置成功。但是在后台iOMCR同步过一次后发现OMP的网关和掩码发生变化，经检查是由于在iOMCR的某两个配置的地方配置了错误的信息。如图：中的两个选项omcsubnetmask(info4)和omcgateway(info5)应当设立为OMP的掩码和网关，而不是OMCR服务器的掩码和网关。用telnet命令初始配置S8001的IP【作者姓名】孙海彪【问题描述】一个新的S8001假如没有装载软件版本是无法与Lmtlink软件建链的。此时，我们只能通过telnet方式来配置其IP。【解决方案】以下图IP为例：telnet->SetIPCfgMode1//closeDHCP.setIPmodesuccessvalue=20=0x14->SetLocalIPAddr0xc0a81005//setIPto,usingHEX.setlocalIPAddresssuccessvalue=29=0x1d->SetSubnetMask0xFFFFFF00//setnewmask.setSubnetMasksuccess->SetGatewayAddr0xc0a81001//setgatewayip.setgatewaysuccess->SetAccBscIPAddr0xc0a81001//setipoftheaccessiBSC.setaccessBSCIPaddresssuccess下列内容为端口设立：->SetLocalPort14168//setlocalport,mustbe14168.setlocalPortsuccess->SetAccBscPort14168//setiBSCport,mustbe14168.setaccessBSCportsuccess->SetRudpPortxxxx//setRUDPport,range1501--65534->SetCSRtpPortxxxx //设立CSRTP端口，范围：1502—65528,需为偶数->SetPSRtpPortxxxx//设立PSRTP端口，范围：1502—65528,需为偶数->ShowAllConfig重启BTS。->ping“1”,3//ping13次进行检查注意引号支持不同网段的IPBB端口配置注意事项【作者姓名】唐永华【问题描述】现场有多个不同网段的网段需要同时接入iBSC，在配置时后台iBSC需要涉及到IPBB端标语配置、子网掩码、广播地址、静态路由网络前缀、静态路由网络掩码，下一跳IP及路由器上的路由地址等，每个环节在配置上出现问题都有也许引起网络配不通，甚至会引起当前配置网络中断，现场结合一个实际案例对不同网段的S8