E2 4.docx
《E2 4.docx》由会员分享，可在线阅读，更多相关《E2 4.docx（39页珍藏版）》请在冰豆网上搜索。
E24
问题log号003740000810
分类类型（GSM）GSM常用技巧心得
紧急程度正常
问题难度小菜一碟
提交时间2006-8-2814:
41:
25
关闭时间2006-11-2210:
05:
34
主题SWAPCSFP中的问题
详细描述
想问一下在LOADMANAGEMENT里网元DOWNLOAD和COMPLETELOAD都打倒DISABLE状态的情况下，能否做SWAPCSFP操作，会否有所影响？
在做SWAPCSFP操作时，DOWNLOAD和COMPLETELOAD两个选项应该打到什么状态下比较合适？
因为我听说过在DOWNLOAD和COMPLETELOAD两个选项都ENABLE状态时SWAPCSFP会容易造成SWAP后CSFP里的数据丢失，并且我也试验过，确实存在丢失的情况。
另外我想问一下SWAPCSFP后的UPLOAD操作是否是必需的，也就是说如果我SWAPCSFP后，在不做UPLOAD的情况下，重启该网元，此时该网元去DOWNLOAD对比的数据应该为新数据还是老数据，谢谢！
！
附件swap_rejected.JPG
swap_002.JPG
002_LOG.TXT
download_002.JPG
问题状态已关闭
处理时间（天）86
备注
处理过程
日期
提交人采取措施备注
2006-8-2815:
46:
40赵克威开始处理问题
2006-8-2815:
47:
13赵克威问题被提交到专家组
2006-8-2923:
50:
02徐玉华1,如果download和completeload都关闭，是无法swapcsfp的。
2,如果需要swapcsfp，单独打开download即可，我一般是2个全打开。
关于swapcsfp后csfp数据丢失和completeload有没有关系就不知道。
有一种情况肯定是会csfp中没数据的，就是冻结数据库做002前就没有csfp，那割接后肯定没有csfp也没有数据了。
3,按照割接流程显示，upload是必需的。
如果swapcsfp后，在没有upload之前，你重起BSC，如果download是打开的，重会比对数据，重新下载你上次upload的老数据；如果download是关闭，则不会影响bsc的新数据。
2006-8-309:
30:
01吁旻川首先感谢徐工的回复！
！
：
）
1、我是因为有听说有同事在download和completeload都关闭的情况下成功swapcsfp的经验，所以才想问问，徐工有没有在download和completeload都关闭的情况做过swapcsfp操作？
？
会报什么错误？
？
2、我是指csfp的002中有定义csfp的情况下，download和completeload的状态与swapcsfp后csfp数据丢失是否存在关系，前面可能没说清楚，抱歉！
！
3、按照徐工的解释，在swapcsfp操作后，只影响bsc内部数据倒换。
omcr内部bssspecific目录下的002文件将不会发生变化，所以upload是必需的。
那么在需要割接导回，csfp数据又丢失的情况下，只要将该网元download打开，然后重启，是否就能达到数据导回的目的？
2006-9-122:
00:
03徐玉华1、download和completeload都关闭的时候是无法swap的，我试过，你割接的时候也可以试下。
2、completeload和csfp数据丢失，我不清楚了。
3、按我的理解，应该是如此。
2006-9-422:
14:
48潘嵘对于第三个问题我存在疑问，如果在CSFP数据丢失的情况下，倒回系统下载的是bssspecific目录下的002文件，那如果此002文件是长时间没有UPLOAD的数据那不就会存在问题？
2006-9-422:
16:
20潘嵘哪位能提供一个相对标准的流程，以指导日后升级工作
2006-9-523:
00:
20徐玉华潘嵘：
对于第3个问题，的确是会恢复以前的002。
如果要避免这样的情况，建议平时把这2个开关都关闭。
在江西的5个地市的MCC，这个开关就是关的。
还有建议给网元做一个的uploadschedule，我在做新BSC时，一般会给新BSC做upload、auditschedule，定在凌晨做。
2006-9-1121:
28:
56潘嵘徐工：
您的意思就是DOWNLOAD打开的情况下，只要重起（在没有指定数据库的情况下）BSC都会做数据库的DOWNLOAD？
2006-9-1122:
29:
51徐玉华swap的重起自然是应用csfp的数据库。
其它原因的重起，如果oml通，download打开，则会下载最近一次upload或load到activedirectory的数据库。
2006-9-129:
03:
41吁旻川download打开的状态，网元重启会拿原有BSP中的数据库文件和omcr上/usr/gsm/ne_data/dbroot/目录下相应网元目录中的数据库文件进行对比，如果相同则不进行相关数据DOWNLOAD的操作，直接用BSP中的数据库启动网元。
如果对比出现不同，则会重新从OMCR上DOWNLOAD网元数据到BSP中进行广播启动网元。
UPLOAD操作会将网元BSP中的数据库上传更新到omcr上/usr/gsm/ne_data/dbroot/目录下相应网元目录中，所以如果长期不做UPLOAD操作，一旦重启则有可能会造成数据的丢失。
我问的问题的意思是指，SWAPCSFP操作会不会对omcr上/usr/gsm/ne_data/dbroot/目录下相应网元目录中的数据库文件也进行倒换，如果会，则SWAPCSFP后的UPLOAD操作是不必要的，如果不会，则SWAPCSFP后的UPLOAD操作是必须的。
2006-9-1217:
28:
23徐玉华swap是针对bsc的命令，不会对/usr/gsm/ne_data/dbroot/产生影响。
/usr/gsm/ne_data/dbroot/下的文件只能由upload、loaddatabase、或是omcadmin/root直接修改。
2006-9-1218:
44:
44潘嵘对于是否会DOWNLOAD的问题，我和张鸿在上饶用新BSC进行了试验。
在DOWNLOAD都打开的情况下，重起BSC。
BSC没有重新DOWNlLOAD数据库。
且/usr/gsm/ne_data/dbroot/目录下相应网元目录中的数据库文件和重起前BSC的数据库不同。
2006-9-1218:
45:
50潘嵘是否由此可以判断两位的前面的说法有问题？
2006-9-131:
00:
10徐玉华不会有问题，有机会可以一起试下。
在TESTBSC记录下当前dblevel，然后做upload，再干掉一个RTF/DRI，记下dblevel，确认omle-u后，之后把download打开，之后reset_site，应该可以看到dblevel或RTF/DRI的恢复。
如果流程没错的话应该不会出现数据库不恢复的情况。
2006-9-138:
25:
40张鸿我与潘嵘是这样做的。
一开始，SHRBSC23是我们为了验证datagen没问题的SHRBSC15的数据（有很多基站数据），做过upload。
然后我们把SHRBSC23的数据通过ConventionalDownload下到BSC23上（现在只有一个微蜂窝的基站），这个002是在另一个目录。
我们再把BSC23的download功能全打开，resetBSC，但重启了2次BSC23都没有下OMC-R服务器上/usr/gsm/ne_data/dbroot/BSS/BSSspecific/SHRBSC23/目录下含BSC15的数据。
所以我们觉得BSC发现与OMC-R上的002不同，download都打开，BSC还是不会重下数据的。
2006-9-1310:
04:
47吁旻川ConventionalDownload应该会改变/usr/gsm/ne_data/dbroot/下相关网元的002文件，张鸿，有时间帮我做做CSFPSWAP的试验，看看会不会对/usr/gsm/ne_data/dbroot/下相关网元的002文件产生改变，谢了！
2006-9-140:
41:
11徐玉华现在很多没有入网的BSC，想试自己可以试下。
2006-9-150:
55:
32张鸿做conventionaldownload与swapcode都会更改usr/gsm/ne_data/dbroot/下相关网元的002文件.今天已测试.
2006-9-159:
03:
12吁旻川谢谢张鸿帮忙测试！
：
）
如果测试无误的话，从测试结果看，swapcsfp后的upload操作并不是必需的。
张鸿有没有做过download和completeload都关闭情况下的swapcsfp操作，是否和徐工遇到的情况一样，会报错而无法执行？
？
2006-9-1511:
30:
12徐玉华是不是确定conventionaldownload后，/usr/gsm/ne_data/dbroot/后文件变化时间在你reset_site时间后，因为我们loaddatabase到activediretory就会有一次时间变化。
swapcsfp的情况，如果swap的时候002就会变化，那么按割接流程走的话，当时002会备件两次，因为每次002变化都会备份。
按我看来swapcsfp是不会变化/usr/gsm/ne_data/dbroot/的，今年上饶GSR7升级用了宜春的TESTBSC测试DN2，应工swap了好多次，/usr/gsm/ne_data/dbroot/中002没有任何变化。
2006-9-1523:
11:
44徐玉华download和completeload都关闭情况下的swapcsfp操作会报错，出错信息如下：
SwapCodeLoadFailed:
error:
CSFPSwaprejected-DownloadsareDisabledforthisNE.
详细情况见附件截图，注意下面的报错信息。
swap_rejected.JPG
2006-9-1523:
20:
55徐玉华对BSC做swapcsfp是不会变化OMCR的上002文件的，因此割接后需要做手工UPLOAD操作：
我21：
04对XYC1S做了SWAP操作，在XYC1S起来之后，21：
19分进入OMC的相关目录，查看002文件（00.00.03.fd.02）状态，该文件的时间为20:
37也就是我上次upload的时间。
详细情况见图示，该图截出的时间为21：
27分。
swap_002.JPG
2006-9-1523:
28:
17徐玉华做conventionaldownload不会变化OMCR上的002文件：
我在21：
38对XYC1R进行了reset，并在9：
56分的时候进入OMCR的目录查看002的文件时间，显示该002文件（00.00.03.fd.02）时间为20：
42，也就是我上次loaddatabase到activedirectory的时间。
详细情况见图示，该图截出的时间为21：
56分。
download_002.JPG
2006-9-1523:
49:
36徐玉华TO张鸿：
BSC重起在OML通，DOWNLOAD打开的时候会比对数据库，不一致会重新下载，这个是写在书的IP流程中的，是不会错的。
"这个002是在另一个目录"我是没有明白你的意思，所谓BSC的002文件是在BSC的目录下的那个，在我的图中就是00.00.03.fd.02，而该目录的子目录下的文件为历史002备份，每当002更改一次（包含upload、loaddatabase产生的更改）OMCR就因备份一次。
对于你的流程，我没有看清楚，你按我的流程做一次，我想就会有答案。
关于文件时间的变化：
我想是这样，当SWAP的时候，但是当前OMCR目录下的002的不会变化，002目录下的各备份子目录的文件时间会发生变化，但里面文件不会变化，详细见附件的LOG，宜春BSC在GSR7升级的晚上OMCR上002备份子目录的时间发生了变化。
做conventionaldownload前，因为我们一般是在loaddatabase到activedirectory或是之前有upload过，如果这个时间就在reset_site时间前不久，可能会造成你的误判。
建议可以开个SR问问。
002_LOG.TXT
2006-11-2210:
05:
32系统管理员关闭问题
问题log号001810000808
分类类型（GSM）GSM统计分析
紧急程度正常
问题难度小菜一碟
提交时间2006-8-2411:
36:
22
关闭时间2006-10-2017:
45:
57
主题杭州一站的IOI统计一直在14左右
详细描述为M-CELL站，目前已处理以下步骤：
1、更换IADU，重调载频的接受和发射，问题仍然存在；
2、上站检查天溃，确认正常；
3、关闭附近直放站（神龙宾馆），观察东贸宾馆IOI统计依然偏高；
4、更换天线，问题仍存在；
5、曾关闭附近联通CDMA站，问题仍然存在。
现将联通CDMA站更换为新滤波器，问题仍然存在。
附件为东贸宾馆高IOI处理的进程报告，请大侠帮忙指点，非常感谢！
附件东贸宾馆二扇区高IOI处理进程报告.rar
cdma_01.jpg
问题状态已关闭
处理时间（天）57
备注
处理过程
日期
提交人采取措施备注
2006-8-2411:
48:
09张雷开始处理问题
2006-8-2510:
34:
48龚勋从附件报告中看，如果报告结论可靠，就可以参照信产部2002年65号文件，责令联通公司进行整改。
如附件cdma_01.jpg所示。
cdma_01.jpg
2006-8-2811:
44:
20王建勇可CDMA站已整改，更换了滤波器，曾停过站（客户反映），IOI高现象仍然存在。
2006-9-51:
14:
22张雷问题被提交到专家组
2006-9-1315:
03:
03张雷如果如报告中的描述，真的排除了CDMA的问题，那就没有什么其他建议了。
2006-9-2217:
50:
22张雷”联通CDMA基站天线应与GSM天线应有50米的保护距离，并要求联通CDMA基站发射产生的杂散辐射低于－67dBm“
距离50米：
很难做到啊，经常是共站情况、
杂散辐射低于－67dBm：
也不可能啊，怎么强的杂散辐射，而且是发射的信号，杂散信号到了egsm和gsm的接收频段后，手机的上行信号基本被干扰掉了。
2006-9-2810:
10:
29系统管理员我已和王建勇联系，他会尽快上来和大家继续探讨这个问题。
2006-10-911:
19:
03袁拉拉有没有换过避雷器啊，避雷器老化或故障，极有可能造成高IOI
2006-10-1310:
55:
55陈智炜如果是避雷器老化或故障，那在测馈线的驻波比时就有体现的啊。
而且如果时避雷器的问题，应该表现在PB值上的异常。
2006-10-1311:
27:
29王建勇和客户交流后，客户反馈由于东贸宾馆室内分布系统采用二扇区作信源，由于设备故障导致，整改后我统计IOI在2左右，应该是恢复正常了。
但现场扫频的确扫到干扰波，并在联通CDMA天线下扫频，但对离该站更近的一些基站干扰统计在5左右，很难解释CDMA对GSM的干扰。
象另一个站，离CDMA大约1000m，干扰在8左右，而我们与CDMA共站的基站干扰统计在5左右，有时没有。
但这个case可以close了，谢谢各位专家的支持，非常感谢！
2006-10-2017:
45:
53张雷关闭问题
问题log号002370000805
分类类型（GSM）GSM数据库配置
紧急程度正常
问题难度小菜一碟
提交时间2006-8-1711:
06:
57
关闭时间2006-11-2210:
03:
44
主题GDP2当GDP用，数据库配置方面要注意什么
详细描述版本为176021－T6，
cage为老的RXU2，
因此只能将GDP2当GDP用，
请问在数据库配置中
msitype应该选gdp还是gdp2
transcodingcapability应该选0还是2。
谢谢！
另，请问现在DSW2到底是支持1024个timeslots还是2048个。
附件
问题状态已关闭
处理时间（天）97
备注
处理过程
日期
提交人采取措施备注
2006-8-219:
37:
36系统管理员开始处理问题
2006-8-2311:
52:
40梁彦DSW2据CNRC说是支持2048个时隙.
定义的方法如下:
eq0msi
Enterthemsiidentifier:
24
Enterthecagenumber:
0
Entertheslotnumber:
24
Enterthemsitype:
20
Enterthemsiidtothemsc:
240
Enterthetranscodingcapability:
2
和原来配GDP数据的差别是
Enterthemsitype:
2020指MSI的类别,在GDP中选2,这里选20.
Enterthetranscodingcapability:
2这里2指支持两条E1.
2006-8-281:
36:
45陈智炜这个明白，
那么由于是GDP2的板子在老的CAGE里使用，所以如果
Enterthetranscodingcapability:
选0，是否正确？
另，在现场测试发DSW2还是只能支持1024个。
。
迷惘
2006-9-410:
25:
25潘巍transcodingcaability选0或者basic
2006-9-419:
24:
39陈智炜感觉选0和2都可以。
。
对否?
2006-9-59:
15:
39梁彦选2应该不行吧？
不过我没有试过，哪位专家这样用过吗？
2006-10-1110:
58:
27董志飞河南上期工程一直是将GDP2当GDP用，定义方法与定义GDP一模一样。
DSW2支持2048，但必须启用半速率才有效，CNRC这样解释的。
实际配置确实发现GPROC2还是只能配置16个时隙，不能是32个时隙，否则肯定有个别定义不上去。
2006-10-1210:
30:
03李中旗1、各地的2CAGEXCDR配置一般是扩展方式，如果更改为扩容方式应当所有的板卡可以定义上，不会有时隙不够的问题存在。
2、如果采取扩容的方式，就需要XCDR增加2块DSW2，2块DSWX。
它又和售前合同有关系，不知其它地方怎么解决。
2006-10-139:
57:
29陈智炜个人觉得DSW2还是只能支持1024，至少现场测试的结果是这样。
transcodingcaability选2，会有2条E1，GDP2当GDP用时，1端口都oos，也没有问题。
2006-11-2210:
03:
42系统管理员关闭问题
问题log号000270000817
分类类型（GSM）GSM路测分析
紧急程度正常
问题难度小菜一碟
提交时间2006-9-414:
14:
06
关闭时间2006-9-416:
29:
35
主题IMMEDIATEASSIGNMENTEXTENDED
详细描述在什么情况下，当MS发起呼叫CHANNELREQUEST接入时，BSS会下发IMMEDIATEASSIGNMENTEXTENDED消息？
附件
问题状态已关闭
处理时间（天）0
备注
处理过程
日期
提交人采取措施备注
2006-9-414:
34:
02李静崟开始处理问题
2006-9-415:
34:
33李静崟只不过是个凑巧，在某个MS发起ChannelRequest时系统（BSC或BTS）正好有两个ImmediateAssignment（针对两个MS）需要下发。
于是就合在一起发出来了，改名叫ImmediateAssignmentExtended。
2006-9-415:
40:
03潘巍是这两个MS都收到这条消息吗？
如果是怎么区分？
2006-9-415:
55:
52李静崟当然两个MS都会收到这条消息，消息中有ReferenceNumber可以区分是发给哪个MS的。
可以参考GSM04.08中对ImmediatedAssignmentExtended的描述，就清楚了。
2006-9-416:
09:
30潘巍查了消息结构，已经明白，可以关闭
2006-9-416:
29:
32李静崟关闭问题
问题log号003200000831
分类类型（GSM）GSM路测分析
紧急程度正常
问题难度小菜一碟
提交时间2006-9-723:
10:
08
关闭时间2006-11-2210:
09:
41
主题通话过程中，突然中断，然后听到网络忙的提示音！
详细描述通话过程中，突然中断，然后听到网络忙的提示音！
不知道产生这种问题可能的原因。
附件
问题状态已关闭
处理时间（天）76
备注
处理过程
日期
提交人采取措施备注
2006-9-89:
46:
58阮民开始处理问题
2006-9-89:
47:
26阮民问题被提交到专家组
2006-9-821:
20:
04徐玉华今天我打1860也出现过这样的情况。
2006-9-1213:
29:
40张雷呵呵，蹊跷！
在贵阳市，交换机在收到clearrequest的时候发送录音通知，内容为“该用户暂时无法接通”，给人的感觉很异样。
你们遇到的情况，去和交换机交流一下吧。
因为录音通知都是交换机提供的。
如果排除了交换机提供的录音情况，只能查找一下是否存在串话了。
这种串话与河南出现情况很像。
2006-9-1221:
50:
46范智祥能不能给一个比较具体的解决方案啊？
在此先谢谢了!
2006-9-1315:
05:
26张雷问题能否描述的清楚些？
听见的是“嘟嘟嘟”的忙音还是录音通知？
如果问题不能确定就不会有具体的解决方案。
2006-9-1415:
10:
56岳刚同意张雷的分析，先找交换机看看在什么情况下，也就是交换机收到了什么消息，或是说带什么causevalue的消息会放这样的录音通知。
在宜昌解决过这样的问题，是华为的交换机和西门子交换机的边界上如果发生跨交换机切换失败就会放类似的莫名其妙的录音通知，最后是交换机修改参数后解决。
2006-9-1816:
57:
04刘雷你拨打的号码有什么规律吧？
按照你的描述，感觉是交换机中继有拥塞？
2006-9-2
升级会员 