【資料名稱】：Gemini Typical case sharing

【資料作者】：nsnnsn

【資料日期】：2010

【資料語(yǔ)言】：中文

【資料格式】：DOC

【資料目錄和簡(jiǎn)介】：

Gemini Typical case sharing
2010.Feb.
一． FlexiBSC part

1. Case NA04626625_High Call Drop Rate（Liu qiuying）
問(wèn)題描述
GeminiBTS基站小區(qū)掉話率高
原因分析
經(jīng)過(guò)分析測(cè)量數(shù)據(jù)，發(fā)現(xiàn)主要是切換掉話
通過(guò)Abis信令跟蹤，發(fā)現(xiàn)目的BSC收到handover Dection后，BTS就發(fā)了CONNECTION
Failure的消息，caus為“Handove Access failue”


******* DCS = 677************** 2009-12-10 16:04:00.65 ****
From BTS-0760 TRX-01 to BSC
Dedicated Channel ManagementNON_Transparent
HANDOVER DETECTION (27H)
Channel Number
- Lm + ACCHssub-channel : 0
- Timeslot : 2
Access Delay
- value : 14 (0Eh)

******* DCS = 677************** 2009-12-10 16:04:00.80 ****
From BTS-0760 TRX-01 to BSC
Dedicated Channel ManagementNON_Transparent
CONNECTION FAILURE (24H)
Channel Number
- Lm + ACCHssub-channel : 0
- Timeslot : 2
Cause
-Normal Event
-Handover access failure
解決方案:
基于信令分析，切換掉話的原因是NY1*T3105超時(shí)
針對(duì)GEMINIBTS建議更改以下參數(shù)：
NY1=35，缺省為5（命令為EQM)
MIU=10s，缺省為3s （命令為EHG）
GEMINI 站上，Alarm2 設(shè)置為 3. 命令：
Set COBA:NAME=RACK:0/COBA:0,ALRMT2=3;
Set COBA:NAME=RACK:0/COBA:1,ALRMT2=3;


2. Case NA04635141_About change the port Q1 (Li deji)
問(wèn)題描述：
網(wǎng)管工程師反映對(duì)于FLEXI BSC上建立的FLEXI BTS和GEMINI BTS，從網(wǎng)管側(cè)可以連接到FLEXI BTS上而不能連接到GEMINI BTS。
原因分析：
FlexiBSC的Q1 address為4080，GEMINI BTS的Q1address 為4001
當(dāng)在BSC創(chuàng)建BCF后，缺省的Q1 address為4080
解決方案：
1)用ZQWL;命令檢查所有BCF的Q1 ADDRESS；
2)對(duì)于前諾的基站類型，Q1 ADDRESS是默認(rèn)的4080不需要修改。對(duì)于GEMINI基站Q1 ADDRESS則需要將4080改為4001:
ZQWG:BCF=<bcf_id>:TRE=1:4001;
ZQWG:BCF=<bcf_id>:TRE=2:;
3)用ZQWL;命令檢查所有BCF的Q1 ADDRESS: FLEXI BTS---->4080; GEMINI BTS---->4001;
4)網(wǎng)管側(cè)UPLOAD BSC網(wǎng)元配置數(shù)據(jù)則OK.

3. Case NA04635271 3G MS will drop call during cell reselection (Shi man)
問(wèn)題描述:
當(dāng)3G手機(jī)在2G到3G重選的過(guò)程中，3G手機(jī)無(wú)法做被叫。主叫方呼叫時(shí)，產(chǎn)生一次回鈴音，然后掉話。被叫方可以看到對(duì)方來(lái)電，并出現(xiàn)未接來(lái)電。
原因分析:
problem 3G MS will drop call during cell reselection, after hardworking for analysis K15 log, I found many Handover reject message from MSS cause handover from 2g to 3g.(It is not allow by operator)
3G手機(jī)在進(jìn)行小區(qū)重選時(shí)會(huì)產(chǎn)生掉話。在分析信令LOG時(shí)發(fā)現(xiàn)有許多由交換側(cè)引起的2G到3G切換拒絕消息（這種切換現(xiàn)網(wǎng)運(yùn)營(yíng)商是不支持的）

所以要特別注意以下參數(shù)：
THRESHOLD FOR MULTI-RAT MS ..................... never
MIN TRAFFIC LOAD FOR SPEECH CALL ............... 80 %
NUMBER OF MEASURED FDD CELLS ................... 02===> please change it to 0.
ISHO is disabled in dedicated mode only if the parameter number of measured FDD cells (FDMR) is set to value 0.

解決方案:
將參數(shù)FDMR（ NUMBER OF MEASURED FDD CELLS ）的值設(shè)為0


4. Case NA04631020 paging delete (Liu qiuying)
問(wèn)題描述：
call difficult under cell BTS-8 in AnHuiMCC,from raw measurement counter,found many paging delete command from this site
原因分析:
For example duration 17:00 -18:00:
1,From raw measurement file ME0252 and ME0253:
BTS8:
03000 : PAGING_MSG_SENT_TO_BTS : 0000129112
03001 : IMM_ASS_MSG_SENT_TO_BTS: 0000010110
03004 : CH_REQ_MSG_RES_FROM_BTS: 0000010110
03057 : PS_PAGING_MSG_SENT: 0000043121
072084 : PACKET_IMMED_ASS_MSG: 0000073180

03038 : DEL_PAGING_CMND: 0000044310

03048 : AVE_PAGING_GB_BUF: 0000009222
03049 : RES_ACC_DENOMINATOR_7: 0000000121 ==> 76.2%
03050 : MAX_PAGING_GB_BUF: 0000000100 ==> 100%
03051 : AVE_PAGING_LOAD_AIR : 0000006565
03052 : RES_ACC_DENOMINATOR_8: 0000000121 ==>54.26%

072082 : PACKET_CH_REQ: 0000059645

such 03000 + 03001 + 03057 + 072084 = 255523 ==> 44310 paging delation

BTS9:
03000 : PAGING_MSG_SENT_TO_BTS : 0000130447
03001 : IMM_ASS_MSG_SENT_TO_BTS: 0000007829
03004 : CH_REQ_MSG_RES_FROM_BTS: 0000007829
03057 : PS_PAGING_MSG_SENT: 0000043281
072084 : PACKET_IMMED_ASS_MSG: 0000007620

03038 : DEL_PAGING_CMND: 0000000000

03048 : AVE_PAGING_GB_BUF: 0000002608
03049 : RES_ACC_DENOMINATOR_7: 0000000121==>21.55%
03050 : MAX_PAGING_GB_BUF: 0000000053==>53%
03051 : AVE_PAGING_LOAD_AIR : 0000003027
03052 : RES_ACC_DENOMINATOR_8: 0000000121==>25.02%

072082 : PACKET_CH_REQ: 0000004900

such 03000 + 03001 + 03057 + 072084 = 189177 ==> no paging delation


14:00 - 15:00
BTS8:
03000 : PAGING_MSG_SENT_TO_BTS : 0000092745
03001 : IMM_ASS_MSG_SENT_TO_BTS: 0000005953
03004 : CH_REQ_MSG_RES_FROM_BTS: 0000005953
03057 : PS_PAGING_MSG_SENT: 0000043146
072084 : PACKET_IMMED_ASS_MSG: 0000082918

03038 : DEL_PAGING_CMND: 0000002151

03048 : AVE_PAGING_GB_BUF: 0000006872
03049 : RES_ACC_DENOMINATOR_7: 0000000127==>54.11%
03050 : MAX_PAGING_GB_BUF: 0000000100==>100%
03051 : AVE_PAGING_LOAD_AIR : 0000012730
03052 : RES_ACC_DENOMINATOR_8: 0000000127==>100%

072082 : PACKET_CH_REQ: 0000073584

such 03000 + 03001 + 03057 + 072084 = 224762 ==> 2151 paging delation

BTS9:
03000 : PAGING_MSG_SENT_TO_BTS : 0000092745
03001 : IMM_ASS_MSG_SENT_TO_BTS: 0000008062
03004 : CH_REQ_MSG_RES_FROM_BTS: 0000008065
03057 : PS_PAGING_MSG_SENT: 0000043075
072084 : PACKET_IMMED_ASS_MSG: 0000028873

03038 : DEL_PAGING_CMND: 0000000000

03048 : AVE_PAGING_GB_BUF: 0000002928
03049 : RES_ACC_DENOMINATOR_7: 0000000128==>22.88%
03050 : MAX_PAGING_GB_BUF: 0000000080==>80%
03051 : AVE_PAGING_LOAD_AIR : 0000012259
03052 : RES_ACC_DENOMINATOR_8: 0000000128==>95.77%

072082 : PACKET_CH_REQ: 0000018625
such 03000 + 03001 + 03057 + 072084 = 172755 ==> no paging delation

2, I checked Abis log, the situation is samilar as measurement files.

分析結(jié)果：
1, BTS8 have huge PACKET_CH_REQ coming, then leads to huge PACKET_IMMED_ASS_MSG;
2, Since PACKET_IMMED_ASS_MSG have higher proirity than PAGING_MSG in BTSPlus, so extra PAGING_MSG will be deleted;
3, CCCH is not enough for cell/BTS 8, every time paging delation happen with MAX_PAGING_GB_BUF is 100%.
解決方案:
Then please follow the suggestion below:
1,Waiting for S14 EP3.2 and BTSPlus new version to support extend CCCH feature, and increase CCCH for this cell.
The following workaround can be tried, but not sure.
2,To adjust antenna angle of this BCF, so that BTS9 and BTS10 can take over some PS service of BTS8.(Because BTS9 and BTS10 have no paging delation happened.
3,To split CELL 8.
4,According to Abis log trace, Uplink TBF creatation procedure of one same subscriber can repeated several times with short interval, so I suggested to active 'extended uplink TBF mode' feature and with proper parameter.
5, Try to active ISP feature, maybe can help.
最終方案：
need more CCCh capacity, S14 EP3.2 and BTSPlus new version(0935) to support extend CCCH feature. EP3.2 release plan is 07/01/10 and 0935 BTS load release schedule is 29/01/10


5. Case NA04637433 Call services statistics abnormal (Zhang zhiyong)

CASE 描述：
在FLEXI BSC下掛了兩個(gè)BTS：
BTS666（NCC=2,BCC=0,FREQ=646,LAC=1870,CI=1040）
BTS900（NCC=2,BCC=0,FREQ=640,LAC=1870,CI=1041）
其中BTS666為關(guān)電狀態(tài)。BTS900為正常工作狀態(tài)。
聯(lián)通大樓基站（現(xiàn)網(wǎng)）創(chuàng)建AdjAC=1870,CI=1040,NCC=2,BCC=0,FREQ=640.（錯(cuò)誤鄰區(qū)數(shù)據(jù)）
在話務(wù)統(tǒng)計(jì)中發(fā)現(xiàn)

2G NetworkTimetch_rej_req_due_lack_fr (Traffic)tch_request (Traffic)
BS8201-12-10 11:007272數(shù)據(jù)恢復(fù)到之前錯(cuò)誤統(tǒng)計(jì)狀態(tài)即鄰區(qū)數(shù)據(jù)錯(cuò)誤時(shí)間段
BS8201-12-10 12:003232
BS8201-12-10 13:0000
BS8201-12-10 14:0000鄰區(qū)數(shù)據(jù)修改正確時(shí)間段
BS8201-12-10 15:0000

注：BTS82即為未開(kāi)電的BTS666。BTS666有tch_request(traffic)和tch_rej_req_due_lack_fr(traffic)計(jì)數(shù)器有更新的計(jì)錄。


CASE 原因：

通過(guò)上述表格測(cè)試表明是由于錯(cuò)誤的鄰區(qū)定義導(dǎo)致計(jì)數(shù)器的更新。


CASE 分析：

首先，聯(lián)通大樓基站（現(xiàn)網(wǎng)）創(chuàng)建AdjAC=1870,CI=1040,NCC=2,BCC=0,FREQ=640.（錯(cuò)誤鄰區(qū)數(shù)據(jù)）
此鄰區(qū)數(shù)據(jù)會(huì)通過(guò)系統(tǒng)消息5 廣播出去，手機(jī)會(huì)根據(jù)此消息去測(cè)量NCC=2，BCC=0，F(xiàn)REQ=640的信號(hào)，而正好此信號(hào)的BTS是開(kāi)著的。所以手機(jī)可以測(cè)量到此信號(hào)，并上報(bào)給現(xiàn)網(wǎng)的BSC，現(xiàn)網(wǎng)的BSC會(huì)根據(jù)上報(bào)的測(cè)量報(bào)告去查找鄰區(qū)列表，找到的小區(qū)是LAC=1870,CI=1040，而此小區(qū)是是關(guān)電的。現(xiàn)網(wǎng)的BSC就會(huì)發(fā)切換請(qǐng)求給MSC，MSC會(huì)發(fā)切換要求給FLEXI BSC，F(xiàn)LEXI BSC 會(huì)根據(jù)LAC=1870,CI=1040去請(qǐng)求資源，相關(guān)的計(jì)數(shù)器會(huì)更新，詳細(xì)流程見(jiàn)下圖：







結(jié)論：現(xiàn)網(wǎng)在聯(lián)通大樓BTS下的手機(jī)嘗試切換導(dǎo)致了上述情形。


6. Case NA04641950 (Flexi BSC) There is a lot of 7741 alarm. (Sun Tao)
問(wèn)題描述：
在安徽合肥FBSC7下，出現(xiàn)大量7741告警。話務(wù)量持續(xù)增長(zhǎng)。經(jīng)Lock/Unlock載頻時(shí)隙，部分7741告警無(wú)法消失。

硬件信息: Flexi-BSC
軟件信息: S14 CD:3.0

告警信息如下：

FBSC7BCF-0027BTS-0029 QUAL2010-01-1600:49:54.82
**ALARMTRX -010BAOSHENGZC3
RTSL-007
(32037) 7741 MEAN HOLDING TIME ABOVE DEFINED THRESHOLD
01 471d 1d 0d

FBSC7BCF-0027BTS-0029 QUAL2010-01-1604:49:54.85
**ALARMTRX -010BAOSHENGZC3
RTSL-002
(32320) 7741 MEAN HOLDING TIME ABOVE DEFINED THRESHOLD
F0 242d 2d 0d

FBSC7BCF-0027BTS-0029 QUAL2010-01-1604:49:54.85
**ALARMTRX -010BAOSHENGZC3
RTSL-003
(32321) 7741 MEAN HOLDING TIME ABOVE DEFINED THRESHOLD
00 439d 1d 0d

原因分析：
1．通過(guò)7741告警的描述得知：

子信道為如下：
00-01：TCH/H subchannel
F0：TCH/F subchannel
占用時(shí)間：
471 min
242 min
439 min
分析：為TCH無(wú)法正常釋放，長(zhǎng)時(shí)間占用。從而表現(xiàn)為話務(wù)量持續(xù)增長(zhǎng)的假象。

2．通過(guò)RADIO RESOURCE MONITORING（E00_BXSX），我們可以看到如下信息：
00-MAN> Z8T:1D,A
2010-01-16 17:09:52.24
DX 200 BSC RADIO CHANNEL INFORMATION FOR BTS NUMBER 001D
TRX 0AN-TRXREGULARPCM 1B10ARFCN 0008LINK ID 0067BITRATE 0040
TSL _CONFIG ____ STATE __ STATUS _______ IF-LVL ___ CALL TIME TIME ___ USAGE
FR,HR0HR1 F0 H0 H1FR,HR0HR1
-00SDCCH8WORKINGCSW
-01DUAL RATEWORKINGIDLEIDLE 00 00 000000000000000000 CSW
-02DUAL RATEWORKINGIDLEIDLE 00 00 000000000000000000 CSW
-03DUAL RATEWORKINGOCCU00 00002C5B CSW
-04DUAL RATEWORKINGIDLEIDLE 00 00 000000000000000000 CSW
-05DUAL RATEWORKINGIDLEIDLE 00 00 000000000000000000 CSW
-06DUAL RATEWORKINGIDLEIDLE 00 00 000000000000000000 CSW
-07DUAL RATEWORKINGIDLEIDLE 00 00 000000000000000000 CSW
SCH 00: FC FC FC FC 0C FC FC FC
-------------------------------------------------------------------------
FTCHS: 07 HTCHS: 0ESCHS: 08BL-TSLS: 00
BUSY FTCHS: 01BUSY HTCHS: 00 BUSY SCHS: 01 HSCSDS: 00
-------------------------------------------------------------------------


分析：系統(tǒng)真正未釋放的時(shí)隙為3時(shí)隙，其它7741告警為系統(tǒng)未作更新。

解決方案：
該Case為系統(tǒng)Pronto，將在S14 MP4.0中解決。發(fā)布時(shí)間為2010-02-12。


二．Ex-N BTS part:

1. Case NA04599306 alarm 8275 (Ma qingwen)
問(wèn)題描述：
基站有8275 告警
<HIST> SYBSC10BCF-0068 COMM2009-10-2514:41:14.85
*ALARM
TRE -0001ENABLED
(49156) 8275 LICENCE FOR FLEXIEDGE TRS ABIS GROOMING IS NOT AVAILABLE
Flexi EDGE BTS Flexi EDGE TRS AlarmDatabase

原因分析：
Flexi EDGE Abis over IP/Ethernet, Flexi EDGE Additional 2 E1/T1, Flexi EDGE TRS Abis Grooming, and Flexi EDGE TRS Loop Protection introduce new base control function (BCF) parameters:
•Flexi EDGE Abis over IP/Ethernet usage
•Flexi EDGE Additional 2 E1/T1 usage
•Flexi EDGE TRS Abis Grooming usage
•Flexi EDGE TRS Loop Protection usage
The modification of the parameters is possible when the state of the feature is ON or CONF. You can enable transmission features by setting values of the parameters with the MML commands EFC and EFM if there is capacity left in the licences. You can print out the parameters with the EFO command.
The following values are possible:
SoftwareParameterValue
Flexi EDGE Abis over IP/EthernetFlexi EDGE Abis over IP/Ethernet usage0-1
•0= not in use
•1= in use
Flexi EDGE Additional 2 E1/T1Flexi EDGE Additional 2 E1/T1 usage0-3
•0= enable two free E1/T1 interfaces
•1= enable additional 2 E1/T1 interface
•2= enable two additional 2 E1/T1 interfaces
•3= enable three additional 2 E1/T1 interfaces
Flexi EDGE TRS Abis GroomingFlexi EDGE TRS Abis Grooming usage0-1
•0= not in use
•1= in use
Flexi EDGE TRS Loop ProtectionFlexi EDGE TRS Loop Protection usage0-1
•0= not in use
•1= in use
If Flexi EDGE Abis over IP/Ethernet, Flexi EDGE TRS Abis Grooming, or Flexi EDGE TRS Loop Protection are activated in one BCF, one capacity item is used. If Flexi EDGE Additional 2 E1/T1 is activated in one BCF, one to three capacity items are used according to user configuration usage value. Two E1/T1 interfaces are licence free. One capacity item allows one Flexi EDGE Additional 2 E1/T1 usage.
When the BCF is in the UNLOCKED state and the state of the licence is ON, you can set the parameters online. Flexi EDGE Abis over IP/Ethernet, Flexi EDGE Additional 2 E1/T1, Flexi EDGE TRS Abis Grooming, and Flexi EDGE TRS Loop Protection do not use capacity if the BCF is in the LOCKED state.
Note that Flexi EDGE Abis over IP/Ethernet, Flexi EDGE Additional 2 E1/T1, Flexi EDGE TRS Abis Grooming, and Flexi EDGE TRS Loop Protection must first be configured in the BSC before they can be used in the BTS site.
Flexi EDGE Abis over IP/Ethernet, Flexi EDGE Additional 2 E1/T1, Flexi EDGE TRS Abis Grooming, and Flexi EDGE TRS Loop Protection also introduce new alarms:
•8273 LICENCE FOR FLEXI EDGE ABIS OVER IP/ETHERNET IS NOT AVAILABLE
•8274 LICENCE FOR FLEXI EDGE ADDITIONAL 2 E1/T1 IS NOT AVAILABLE
•8275 LICENCE FOR FLEXI EDGE TRS ABIS GROOMING IS NOT AVAILABLE
•8276 LICENCE FOR FLEXI EDGE TRS LOOP PROTECTION IS NOT AVAILABLE
These alarms are raised by the BTS if any of the licensed transmission features have been configured without a valid licence. This means that they have been configured in the BTS but not in the BSC. The BTS raises a separate alarm for each missing licence.
解決方案：
Check the status of the ‘Flexi EDGE TRS Abis Grooming’ licence at the BSC, and if needed, install and/or activate it.
Configure the ‘Flexi EDGE TRS Abis Grooming’ feature in the BSC.
Alternatively, you can disable all the cross-connections which are controlled by 'Flexi EDGE TRS Abis Grooming'.


三．Ex-S BTS part

1.Case NA04632624 (Liuwenzheng)
問(wèn)題描述：
The ticket is related to high call drop rate and TBF low establishment successfully rate when the BTSplus with GCU/FCU mixed configuration; GCUs with sub-seg and FCUs with sub-seg; RF-HOPPING enabled together;
原因分析：
SW Bug.
when BTS CONF DATA is received for the 2nd sector, where RF hopping is already enabled, the ARFN list has not been taken into account by the TRXs. Software improvements have been carried out in order to avoid such situations. So, if the 2nd sector is locked when BTS CONF DATA is received at first sector the hopping mode to 2nd sector is not allowed until it is unlocked from BSC.
解決方案：
BTS Load 0947 was delivered on 25,Jan. to solve this problem and verified on AHMCC.

2.External Alarm on BTS+ (Liuwenzheng)
Create the External Alarm on BTS+：


Do nothing on FlexiBSC for the External Alarm of BTS+。


Monitor the alarm message on BSC and NetAct：
*** ALARM
(14787) 7407 EXTERNAL AL 7
smoke Not_ID: 372
BSC40BCF-0900BTS-0900 QUAL2010-01-1321:52:04.01
*ALARM
(14763) 7408 EXTERNAL AL 8
ABNORMAL Not_ID: 257
BSC40BCF-0900 ENVIR2010-01-1217:07:39.67
**ALARM
(14765) 7409 EXTERNAL AL 9
DC Not_ID: 267



3.Case NA04630856 CU module high failure rate(Liuwenzheng)
問(wèn)題描述：
After BTS+ is migrated to FlexiBSC, some FCU seem work well from LMT view, but the TRX do not work from fBSC view.
From Abis Traces we can see that BTS does not send 7208 alarm cancellation. At BTS side this could be due to some configuration of HMO state and SW is not properly handling it.
原因分析：
SW Bug.
A misalignment between the status showed by LMT and the one reported at FlexiBSC caused by an uncleared 7208 LOCAL BLOCK alarm.
BTS Load 0946 and all later on will correct this problem.
解決方案：
BTS Load 0946 was delivered on 21,Jan. to solve this problem and all BTS Load later on will include this correction.