荊州MOTO大容量BSC使用問題總結

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

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

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

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

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

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

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

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

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

10、SC上對應的端口錯誤，數據仍能正常下載到 BTS但相應的 所有信道不活。答復：對于大BSC如基站傳輸接反，為保障基站快速恢復，基站仍會將軟 件和數據下載到基站（減少退服時間），但所有信道仍起不來，避免了用戶單通 或串話引起的投訴。 因此通過載波狀態(tài)， 仍能判斷出傳輸接反， 而一旦傳輸恢復， 基站就會快速完全恢復，不需再下載數據。減少退服時間。為在割接中避免該問題，割接時傳輸側作好充分準備，保障同一個基站的幾 條傳輸不要接錯。割接完后需觀察載波是否完全起來。2.故障現象：交征大樓基站割接到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未拔出，可能與此有關（但同樣情況的其他基站并沒 有影響起站）。所以，還是要求所有割接基站的BTP必須有卡，或將無卡 BTP拔出。也可能與BTP或 PCMCIA卡硬件有關，或可能code下載有問題。答復：對于此類問題，可通過充分作好割接準備來完全避免，要求所有割接基站的BTP必須有卡，或將無卡BTP拔出。割接當晚，多準備

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