新版本升级步骤

新版本升级步骤 版本升级步骤如下,,默认条件为基站所有本地小区都已建立成功， 1) 获取版本,通过管理站,OMC-R/LMT-B，下载软件压缩包 TDB36AS.dtz,远程下载大概30分钟可以完成,本地下载5分钟可 以完成， )通过管理站,OMC-R/LMT-B，下载固件压缩包TDB36AF.dtz,远程2 下载大概10分钟可以完成,本地下载2分钟可以完成， 3) 通过管理站,OMC-R/LMT-B，在对象树->被管对象->固件->固件管 理->激活固件包中选择运行目录,选择手动激活， 4) 通过管理站,OMC-R/LMT-B在对象树->被管对象->软件->软件管理 ->即时激活软件包中选择备份目录，激活软件包,选择自动激活，命 令下发后,基站会在20分钟内复位并启动成功， 5) 为了解决天线系数继承问题,此次升级需要对软件包做连续两次升 级操作。请再次下载软件压缩包,然后通过管理站发起自动激活操作， 即重复步骤1,4。 6) 更新LMT-B、Hummer等软件。 大家仔细阅读，每种问题都有建议处理意见。 对大家排障应该很有帮助～ 发件人: yangwangjun [mailto:yangwangjun@datangmobile.cn] 发送时间: 2009年4月11日 0:40 收件人: guohongjian@datangmobile.cn 基站问题主题: 1、 下行功率为负值的情况 问题描述:各地上报了下行功率为负值，下行功率跳变，UE侧看到信号不稳等显现。涉及室内小区，室外小区。室内小区主要体现在功率不稳;室外小区体现在功率不稳和下行功率为负值，AC校准告警等。 结论:最近通过调换BBU槽位，有升级27版本可以彻底解决。个别顽固站点BBU调到3、4槽位仍然有功率问题，更换到1、4槽位后可以彻底解决。在各地通过调换槽位并升级27版本可以彻底解决该问题。最近正在验证不需要调换槽位的版本，本周完成验证情况。 建议外场处理: 1) 使用轮询工具，可以很快轮询出功率异常的站点。 2) 对于功率为负值的站点先调换BBU板卡位置，避开2槽位，如果调到3、4 槽位仍然有问题，可以调到1、4槽位，可以彻底解决。 3) 尽快升级27版本。 2、IPOA闪断问题: 问题描述:基站出现IPOA闪断，有的16s闪断一次，有的时间上没有规律。 结论:IPOA问题有多种原因导致，如果是闪断，多和保活机制相关。如果彻底不通，需要上站定位。有下面原因: 1)NEA的保活消息丢失，导致基站IPOA闪断; 2)OMCR发起版本下载，由于带宽问题使IPOA保活消息不能下发，导致IPOA闪断，IPOA申请成功后，会自动上传一致性文条件，又加大了带宽压力，又导致了基站IPOA故障。版本批量下载时触发。 3)RNC上将两个NodeB的ID配置重复，导致基站IPOA闪断。 4)个别站点的传输线缆做错，比如RNC的4路E1中有一路没有连到基站上，导致了RNC给基站的数据包丢失，出现了IPOA闪断。在上海的菊园营业厅出现过。 建议: 1)IPOA不通，先看IMA是否激活，如果IMA也没有激活，需要上站排障。 2)如果IMA激活，收到基站请求消息，需要看参数配置。 3)如果是有规律闪断，需要看NEA。 4)如果可以通，但是闪断，且误码高，需要查传混线的情况。 3、BBU ping不通导致小区建立失败，小区反复删建 问题描述:小区反复删建，无法分配载波。Hammer上无法ping通BBU。 结论:aCCU上以太phy异常所致，升级27版本解决。升级后零星发现了2个站点还有该问题，最后定位是升级前的问题，因为升级后该板卡程序没有同步成功导致了基站没有复位所致。 建议: 1) 可以先通过轮询工具轮询到现网中这类问题。 2) 发现了该问题要整站复位。 4、基带板与基带接口板不同步问题 问题描述:有告警“基带板与基带接口板不同步”，BBU在位不可用。 结论:这类问题较少，当前版本没有解决。 建议:一个站发生了该问题，上站插拔板卡，换槽位尝试解决，有的板卡到了其他基站可以使用。 5、问题描述 :18AE出现7槽位问题: 告警: 2009-04-07 22:33:08 基站产生编号为59999故障类告警:板启动;(产生模块:特殊告警;告警值:无效;附加信息:) 2009-04-07 22:36:23 CCU(0,0)[SFW]-> LocalCell(0) O_AOMBCPSOM_GTPTXPATH_SET_REQ send OK! 变更通知(删除): 2009-04-07 22:37:56 被管对象boardRowStatus实例0.7值变为:行无效 变更通知(单节点): 2009-04-07 22:37:57 被管对象boardUpTime实例0.7值变为:2000-01-01 00:00:00 2009-04-07 22:40:19 CCU(0,0)[HDW]-> UnKnown Board(0,7) is not exist 告警提示: 2009-04-07 22:37:57 基站产生编号为20185故障类告警:未知类型板卡不在位;(产生模块: AOMTD;告警值:无效;附加信息:FrameNo = 0, SlotNo = 7.) SI日志中: 2009-04-07 22:35:23 CCU(0,0)[HDW]-> UnKnown Board(0,7) is exist 2009-04-07 22:36:23 CCU(0,0)[SFW]-> LocalCell(0) O_AOMBCPSOM_GTPTXPATH_SET_REQ send OK! 2009-04-07 22:40:19 CCU(0,0)[HDW]-> UnKnown Board(0,7) is not exist 2009-04-07 22:41:44 CCU(0,0)[SFW]-> Lmtb Read File Info Success 2009-04-07 22:41:46 CCU(0,0)[SFW]-> Lmtb Read Software Macro Version Success 2009-04-07 22:42:11 CCU(0,0)[HDW]-> UnKnown Board(0,7) is exist是18AE吧。 1 结论:18AE中，0机框7槽位对于驱动来说是GEU，此板卡没有处理器，原本是 不处理此板卡的在位等信息的，但是后来应外场和测试线要求，把它的在位信息 也提供了。 下面几种情况大部分可通过复位RRU解决 6、 FPGA同步，si日志: NB REJECT!!! 该RRU存在反复接入的现象，接入原因为: NB REJECT!!! 一直存在如下打印: * ^ † 'W ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 @2009-03-30 06:15:13 # J Í 7 Z _tIfpTdm —& * ^ † 'W ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 @2009-03-30 06:15:24 # J Í 7 Z _tIfpTdm —& * ^ † 'W ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 @2009-03-30 06:15:35 # J Í 7 Z _tIfpTdm —& * ^ † 'W ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 7、 级联RRU无法接入 本调时，所有RRU均可正常接入。当联调复位18AE后，第1光口第2级RRU 无法正常接入，刷板卡信息可以看到该RRU，但一直处于初始化状态，光纤、 光模块正常。将该RRU直连18AE后可正常接入，将其倒换为第1级RRU后也 可正常接入，其下联的原来第1级RRU也可正常接入，顺序复原后，故障依旧。 RRU61号日志中一直有如下打印: # J Í 7 Z _tIfpTdm èÊ~~TÅ ?HW FPGA EX ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 @2009-03-31 15:28:12 # J Í 7 Z _tIfpTdm èÊ~~TÅ ?HW FPGA EX ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 @2009-03-31 15:28:23 # J Í 7 Z _tIfpTdm èÊ~~TÅ ?HW FPGA EX ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 @2009-03-31 15:28:34 # J Í 7 Z _tIfpTdm èÊ~~TÅ ?HW FPGA EX ?SFU:0x9050032, FILE:dd_ifu_dd_arch.c LINE:4671, AlarmNo:101, AlarmValue:28, AlarmClearFlag:1 ErrMsg>tdd_ifu_tdm_task:GET MASTER TDRI HYPERFRAME NUMBER FAIL,ret = 0 8、 反复接入，si日志显示BBU Lost 反复接入原因为BBU LOST，怀疑RRU0下级光口存在问题，建议现场做更换 级联顺序操作尝试 9、RRU无法接入问题 问题描述:RRU不明原因不在位。 结论:目前27版本对此有一些改善，但是没有彻底消除。27版本中增加了RRU 在时延测量间断的自复位，可以大大降低RRU的不在位情况。 建议: 1) 先看光功率，如果光功率位0或,350左右，可以判定该RRU没有连接， 或没有上电。 2) 光功率良好，fpga不明原因失步，上站前先复位EIU尝试一下，据上海反 馈70,可以解决。 3) 如果Fpga同步，RRU无法接入，可以通过下列方法解决: 处理:(不方便直接连接RRU时可以添加下面的路由来复位RRU) a) A)hammer 登入CCU，通过在CCU添加路由的命令: b) routeAdd “10.1.xx.192”，“10.0.5.192”目的是让CCU可以访问未接入的RRU， 前提是EIU可以ping 通RRU，翟奎做过测试。 在本地做时可以不管下面的步骤C c) 在CCU的控制台上telnet到RRU telnet "10.1.xx.192" user:nodeb password:nodeb.1234 d) 这样可以登录到RRU上。在telnet到RRU上后，调用RRU的复位命令复位RRU， 注意不能用reboot，因为reboot会导致基站复位。命令:RRS_RESETRRS e) RRU复位后，自动接入基站，可以从基站侧提取该RRU的全部日志。 4)上述方法无法解决，可以试着下电复位RRU。 5)最后可以尝试升级RRU