荊州MOTO大容量BSC使用問題總結(jié)

1、荊州 MOTO 大容量 BSC 使用問題總結(jié)一、安裝調(diào)測中遇到的問題1. ABIS 光接口板無法支持熱倒換。大BSC下的GOIUB板倒換到備用側(cè)后，相應(yīng)傳輸設(shè)備沒有同時做倒換。同樣 傳輸設(shè)備倒換后，GOIUB也不跟隨倒換。且傳輸設(shè)備使用備用側(cè)時，強制 GOIUB 倒換后很快會倒回主用側(cè)，無法駐留在備用側(cè)上?，F(xiàn)原因不明。答復(fù)：目前，原因已查明：為SDH設(shè)備參數(shù)設(shè)置為單端口倒換模式，而 BSC 設(shè)置為雙端口倒換模式。在這種情況下，任何一方開始倒換時，對端都不響應(yīng)?，F(xiàn)在，我們在新調(diào)測的BSC6上進行實驗，華為SDH也設(shè)置為雙端口倒換模 式，雙方都能同步正常倒換。二、運行中出現(xiàn)的問題1.基站打開ITS

2、后(支持EDGE，DCTU2勺A面如配置成EGPR信道，貝U 相應(yīng)的B面時隙不可用。通常 TCH Full Rate 時隙，默認(rèn)可轉(zhuǎn)變成 EGPRS Normal Channe，l 這樣就 可能導(dǎo)致基站中大量時隙不可用。所以，在打開 ITS 后，如不是指定配置 EGPRS 的TRX需要對其TCHFull Rate時隙對應(yīng)可變 GPRS寸隙修改為GPRSChannel。建議：在大容量BSC下，最好還是將每個小區(qū)內(nèi)開 EGPRS勺載頻替換成CTU2D配置為CCTU2避免開ITS。答復(fù)：該問題已通過參數(shù)修改解決?；鹃_啟ITS功能EDGEB，可將CTU2的對面B面的TCHFull Rate時隙對 應(yīng)

3、可變GPRS寸隙修改為GPRS)hannel。將要承載EDG的載頻替換成CTU2D 配置為 CCTU，2 就不會出現(xiàn) B 面時隙不可用。目前通過該參數(shù)修改，沒有小區(qū)出現(xiàn) DCTU2勺B面時隙不可用的情況2. 修改小區(qū)數(shù)據(jù)后，如重啟基站，可能導(dǎo)致基站軟件丟失。為增加PCH和AGCH勺帶寬，我們將所有小區(qū)的參數(shù)進行如下修改： 增加 ccch 到 2 個 timeslot ，同時將 bs_ag_blks_res 設(shè)置為 2，并將 BS-PA-MFRAM減小為2,加快尋呼的發(fā)送來加速系統(tǒng)尋呼排隊狀況恢復(fù)。步驟如下：deactived cell，從 LMT上選中小區(qū)，右鍵 set cell active

4、 state, 置成 not actived.（ 一個站下的所有小區(qū)不能同時置成 not actived） ，選中這個小區(qū)右鍵set cell attributes,首先修改BCCHS頻的信道參數(shù)，第三個時隙的信道類型定義為 BCH然后修改小區(qū)的set idle parameters 中 BS_AG_BLKS_RES=2,BS_PA_MFRAMS存2, 從 LMT上選中小區(qū)，右鍵 set cell active state, 置成 actived. 完成一個小區(qū)的修改。修改參數(shù)，小區(qū)的所有載波重啟。該BSC下共18個基站中，17個都正常起來，一個基站（東區(qū)）無法恢復(fù)， 查看告警發(fā)現(xiàn)基站的軟件丟

5、失，人工從 OMC-S上下載軟件后基站恢復(fù)（耗時45 分鐘）。目前原因不明。答復(fù)：SR2346887已在10月29日開出，正在調(diào)查中。目前懷疑可能與基站上的PCMCIA老化有關(guān)，如果再次出現(xiàn)，我們保留相 關(guān)故障硬件供研發(fā)部門調(diào)查。對于該問題， 由于可能碰到的概率極小， 我們的方案是： 在后續(xù)修改如果可 能導(dǎo)致小區(qū)重啟的參數(shù)時，將在晚上進行，并保證基站傳輸OML正常，并現(xiàn)場保 障軟件能立即下載到基站（3045分鐘），問題碰到后立即開SR,尋求根本原因。 保留相關(guān)故障硬件供研發(fā)部門深入調(diào)查。三、較嚴(yán)重的問題1.臨安BSC6割接后尋呼成功率下降9月17號臨安BSC6在割接后出現(xiàn)了電路域?qū)ず舫晒β蕠?yán)重

6、下降的現(xiàn)象，最差的情況尋呼成功率低至30%由于MOBIS與ABIS接口在尋呼接通上的機制不同，以前 GSR勺參數(shù)配置， 無法適應(yīng)當(dāng)前BSC6的性能，對BSC6的影響主要集中在尋呼成功率在忙時會有很 大的下降。GSF與 RSR勺系統(tǒng)最大變化是增加了規(guī)范規(guī)定的 Abis接口，而去掉了原來 的Mobis系統(tǒng)。而此項改變使得部分原來在 BTS上的功能轉(zhuǎn)移到BSC上，而主導(dǎo) CCC分配功能的Call Processing Module 也隨之轉(zhuǎn)移到BSC側(cè)，具體流程也發(fā) 生了明顯變化：GSR系統(tǒng)尋呼處理框圖（話音尋呼）：RSR系統(tǒng)尋呼處理框圖（話音尋呼）:如以上兩幅流程圖所示，RSR信道資源的分配與激活

7、的步驟在時間上相比GSR系統(tǒng)將有所增加，這也就意味著相同數(shù)量的空口資源，被占用的時間將會增 加，據(jù)研發(fā)人員的測試，正常情況下會有1秒到2秒的增加，且隨著負(fù)載的增大， 所需時間也會隨之增長。也就是空口資源使用效率下降。在RSF系統(tǒng)中，完成相 同的CCCF負(fù)載，相比GSRS統(tǒng)則需要更多的資源。資源不夠的情況一旦出現(xiàn)，將出現(xiàn)AGCH和/或PCM擁塞，從而導(dǎo)致PagingRequest消息和/或Immediate Assignment 消息的丟棄或超時?？紤]到以上情況，建議擴大PCH的帶寬以提高對瞬時峰值的容忍度以及加速 對惡化后果的恢復(fù)。同時，考慮到在杭州出現(xiàn)的AGC!擁塞導(dǎo)致Paging_Resp

8、onse 降低的問題，建議擴大 AGCH勺帶寬。綜上，對于 paging 相關(guān)參數(shù)修改建議為： 增力卩ccch至U 2個timeslot ，同 時將bs ag blks res 設(shè)置為2,并將BS-PA-MFRAM減小為2,加快尋呼的發(fā)送 來加速系統(tǒng)尋呼排隊狀況恢復(fù)。答復(fù)：針對該問題，公司研發(fā)部門已經(jīng)制定了修改方案，計劃在下一版本（11 月中旬）通過BTS軟件升級解決；目前版本下可采用 2CCCH配置作為臨 時解決方案。對于浙江，在忙時啟動了第二 CCCH的小區(qū)，工作正常，未出現(xiàn)尋呼拋棄，且話音立即指配成功率明顯高于未開啟第二CCCH勺小區(qū)。2. PS域統(tǒng)計值A(chǔ)031代碼錯誤目前版本的BSC存

9、在代碼統(tǒng)計缺陷，導(dǎo)致 A031值統(tǒng)計過大。錯誤的A031 統(tǒng)計值是A331的14倍，且這個指標(biāo)的統(tǒng)計錯誤不會帶來業(yè)務(wù)的影響 （純話務(wù)統(tǒng) 計計數(shù)器值的增加只影響話務(wù)統(tǒng)計指標(biāo)，不影響業(yè)務(wù)）。答復(fù)：該問題原因已查明，將在后續(xù)版本（ 6000.20t7 ）中解決。暫時可以 用小區(qū)的 PS 尋呼統(tǒng)計值來代替。四、基站割接時存在的問題：1. 故障現(xiàn)象：割接后玉橋開發(fā)區(qū)基站載頻顯示正常， 但所有時隙 （BCCH/SD/TCH/PD不可用故障分析：該站共兩條傳輸，傳輸正好接反。這種情況在 BSC23上基站是不 會入服的，但在BSC600C上可以。在大BSC下，可能只要OMI所在的第一條傳輸 物理鏈路通，如在B

10、SC上對應(yīng)的端口錯誤，數(shù)據(jù)仍能正常下載到 BTS但相應(yīng)的 所有信道不活。答復(fù)：對于大BSC如基站傳輸接反，為保障基站快速恢復(fù)，基站仍會將軟 件和數(shù)據(jù)下載到基站（減少退服時間），但所有信道仍起不來，避免了用戶單通 或串話引起的投訴。 因此通過載波狀態(tài)， 仍能判斷出傳輸接反， 而一旦傳輸恢復(fù)， 基站就會快速完全恢復(fù)，不需再下載數(shù)據(jù)。減少退服時間。為在割接中避免該問題，割接時傳輸側(cè)作好充分準(zhǔn)備，保障同一個基站的幾 條傳輸不要接錯。割接完后需觀察載波是否完全起來。2.故障現(xiàn)象：交征大樓基站割接到BSC6000后 oml 直顯示failure ，所有傳輸狀態(tài)正常故障分析：該站割接前輸入 chg_elem

11、ent _site_data,5 2 siteid 后（倒換 CSFP啟動雙boot程序），還沒有來得及l(fā)ock rsl，很快基站就在原BSC上開 始 loading 。懷疑下載到CSFP勺雙啟動code并沒有將支持Abis功能正常打開。該站備用 BTP無PCMCIA卡，且BTP未拔出，可能與此有關(guān)（但同樣情況的其他基站并沒 有影響起站）。所以，還是要求所有割接基站的BTP必須有卡，或?qū)o卡 BTP拔出。也可能與BTP或 PCMCIA卡硬件有關(guān)，或可能code下載有問題。答復(fù)：對于此類問題，可通過充分作好割接準(zhǔn)備來完全避免，要求所有割接基站的BTP必須有卡，或?qū)o卡BTP拔出。割接當(dāng)晚，多準(zhǔn)備

12、 已包含新數(shù)據(jù)的BTP碰到上述問題可直接插入基站，這樣基站可在 15分鐘內(nèi) 恢復(fù)。3. 故障現(xiàn)象：省電二處基站割到 BSC600C后無法起站，傳輸狀態(tài)不穩(wěn)定，3 條傳輸每隔幾分鐘就會同時中斷。故障分析：該站無主側(cè)的BTF，而我們通過migration_tool 轉(zhuǎn)出來的數(shù)據(jù)庫 只有主側(cè)BTP數(shù)據(jù)，備用側(cè)BTP數(shù)據(jù)需自行添加。此次割接添加備用BTP這一步 缺失?；究赡芤颜Ｏ螺d了 COD和數(shù)據(jù)，但初始化后由于備用側(cè)BTP無數(shù)據(jù)， 而主用側(cè)無板子，導(dǎo)致無法起站。答復(fù)：該問題已通過完善數(shù)據(jù)庫轉(zhuǎn)換工具解決，而非BSCS備問題。該問題是割接的數(shù)據(jù)庫轉(zhuǎn)換工具有缺陷，備用側(cè)BTP數(shù)據(jù)需自行人工添加，在割接時保證基站的主備用槽位都有 BTP可解決避免該問題。同時最新版本的數(shù) 據(jù)庫轉(zhuǎn)換工具Migration Tool已經(jīng)解決該問題，不再需要手動添加備用 BTP數(shù) 據(jù)。4. 故障現(xiàn)象：熱電廠基站割接后狀態(tài)同上。故障分析：但該站的硬件條件與上面一個基站不同。該站割接前備用側(cè) BTP 為B-U，主用側(cè)為E-U,割接到大BSC后也基站一直用備用側(cè)BTP起站，一直沒 有使用主用側(cè)。CNRC寸以上兩個問題在實驗室測試，認(rèn)為只有備用側(cè) BTP也是可以起站的， 因此問題3應(yīng)該是沒有備用側(cè)BTP數(shù)據(jù)導(dǎo)致。但關(guān)于問題4,實驗室測試時可以 倒換到主用側(cè)起站， 懷疑可能與主用側(cè)硬件問題有關(guān)， 或與 code 下載