【BSC】某局有一個小區(qū)單載頻配置，有一天手機用戶投訴說基站附近該小區(qū)信號不好，話音質(zhì)量差。工程師拿著測試手機到基站測試，發(fā)現(xiàn)手機能上網(wǎng)，但是即使鎖定該小區(qū)頻點撥打電話，也立即被指配到附近其它基站的載頻上，且話音質(zhì)量不好。
通過一些操作，得到以下信息：
1）該基站沒有任何告警。
2）查看話統(tǒng)，發(fā)現(xiàn)該小區(qū)TCH根本就沒有話務量，切換接入也沒有；SDCCH有占用請求，但是全部失敗。
3）跟蹤Abis口信令，立即指配命令所指配顯示載頻頻點號為7A，也就是122，對該小區(qū)強制發(fā)送系統(tǒng)消息，在SYSTEMIMFO1中表明載頻頻點也是7A即122。
4）打開基站遠端維護臺，獲取小區(qū)屬性表明頻點卻是118；發(fā)現(xiàn)基站工作頻點有疑問，查詢BSC數(shù)管臺，檢查該小區(qū)有關頻點信息的表格《小區(qū)分配表》、《載頻配置表》，數(shù)據(jù)配置一致，沒有錯誤，頻點為118。
5）對《小區(qū)分配表》、《載頻配置表》兩個表查看主機，發(fā)現(xiàn)主機中頻點為122。
6）詢問現(xiàn)場工程師，說該站以前在網(wǎng)優(yōu)中曾經(jīng)修改過頻點，原來工作頻點為122，后來改為118，采用動態(tài)設定設定到主機，成功更改后正常運行了一段時間，在出現(xiàn)用戶投訴前，該基站所在模塊又成功做過兩次MPU主備倒換操作。
根據(jù)這些信息，定位出了問題所在，在實驗室模擬，該問題得到重現(xiàn)，請回答以下問題：

【BSC】某局有一個小區(qū)單載頻配置，有一天手機用戶投訴說基站附近該小區(qū)信號不好，話音質(zhì)量差。工程師拿著測試手機到基站測試，發(fā)現(xiàn)手機能上網(wǎng)，但是即使鎖定該小區(qū)頻點撥打電話，也立即被指配到附近其它基站的載頻上，且話音質(zhì)量不好。
通過一些操作，得到以下信息：
1）該基站沒有任何告警。
2）查看話統(tǒng)，發(fā)現(xiàn)該小區(qū)TCH根本就沒有話務量，切換接入也沒有；SDCCH有占用請求，但是全部失敗。
3）跟蹤Abis口信令，立即指配命令所指配顯示載頻頻點號為7A，也就是122，對該小區(qū)強制發(fā)送系統(tǒng)消息，在SYSTEMIMFO1中表明載頻頻點也是7A即122。
4）打開基站遠端維護臺，獲取小區(qū)屬性表明頻點卻是118；發(fā)現(xiàn)基站工作頻點有疑問，查詢BSC數(shù)管臺，檢查該小區(qū)有關頻點信息的表格《小區(qū)分配表》、《載頻配置表》，數(shù)據(jù)配置一致，沒有錯誤，頻點為118。
5）對《小區(qū)分配表》、《載頻配置表》兩個表查看主機，發(fā)現(xiàn)主機中頻點為122。
6）詢問現(xiàn)場工程師，說該站以前在網(wǎng)優(yōu)中曾經(jīng)修改過頻點，原來工作頻點為122，后來改為118，采用動態(tài)設定設定到主機，成功更改后正常運行了一段時間，在出現(xiàn)用戶投訴前，該基站所在模塊又成功做過兩次MPU主備倒換操作。
根據(jù)這些信息，定位出了問題所在，在實驗室模擬，該問題得到重現(xiàn)，請回答以下問題：

【BSC】某局有一個小區(qū)單載頻配置，有一天手機用戶投訴說基站附近該小區(qū)信號不好，話音質(zhì)量差。工程師拿著測試手機到基站測試，發(fā)現(xiàn)手機能上網(wǎng)，但是即使鎖定該小區(qū)頻點撥打電話，也立即被指配到附近其它基站的載頻上，且話音質(zhì)量不好。
通過一些操作，得到以下信息：
1）該基站沒有任何告警。
2）查看話統(tǒng)，發(fā)現(xiàn)該小區(qū)TCH根本就沒有話務量，切換接入也沒有；SDCCH有占用請求，但是全部失敗。
3）跟蹤Abis口信令，立即指配命令所指配顯示載頻頻點號為7A，也就是122，對該小區(qū)強制發(fā)送系統(tǒng)消息，在SYSTEMIMFO1中表明載頻頻點也是7A即122。
4）打開基站遠端維護臺，獲取小區(qū)屬性表明頻點卻是118；發(fā)現(xiàn)基站工作頻點有疑問，查詢BSC數(shù)管臺，檢查該小區(qū)有關頻點信息的表格《小區(qū)分配表》、《載頻配置表》，數(shù)據(jù)配置一致，沒有錯誤，頻點為118。
5）對《小區(qū)分配表》、《載頻配置表》兩個表查看主機，發(fā)現(xiàn)主機中頻點為122。
6）詢問現(xiàn)場工程師，說該站以前在網(wǎng)優(yōu)中曾經(jīng)修改過頻點，原來工作頻點為122，后來改為118，采用動態(tài)設定設定到主機，成功更改后正常運行了一段時間，在出現(xiàn)用戶投訴前，該基站所在模塊又成功做過兩次MPU主備倒換操作。
根據(jù)這些信息，定位出了問題所在，在實驗室模擬，該問題得到重現(xiàn)，請回答以下問題：

【BTS3X】某局一個新開站為BTS312設備，S4/4/4配置，為了統(tǒng)一該局的基站版本，開通之前在近端把TMU和TRX都升級到G2BTS32.30000.07.0407A。傳輸接通后基站重新上電開始觀測正常，但是所有TRX正常運行7、8分鐘后復位，在運行7、8分鐘后又復位，如此反復，在正常運行的7、8分鐘內(nèi)，基站功能正常，可以打通電話，相關告警僅有單板通信告警。
1、TRX出現(xiàn)反復復位，在開局中最常見的原因是什么？
2、這個案例所描述的現(xiàn)象，會不會也是這個原因？為什么？
3、請解釋出現(xiàn)這種現(xiàn)象的直接原因。
4、出現(xiàn)這個故障時，如果注意觀察，還有一個顯著的現(xiàn)象，那就是TMU和TRX的CPU占有率升高，一般TMU和TRX正常運行時，CPU占有率是多少？
5、如何解決這個問題？