專利名稱：基站日志上報(bào)系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別涉及全球移動(dòng)通信系統(tǒng)(Global System formobile Communication，簡(jiǎn)稱“GSM”)中的基站日志上報(bào)技術(shù)。
背景技術(shù)：
移動(dòng)通信從20世紀(jì)20年代開始就在軍事及某些特殊領(lǐng)域得到了應(yīng)用，20世紀(jì)40年代逐步從軍事向民用擴(kuò)展，并在20世紀(jì)70年代末，由美國(guó)貝爾實(shí)驗(yàn)室推出了蜂窩移動(dòng)通信技術(shù)。移動(dòng)通信經(jīng)歷了由模擬通信向數(shù)字化通信發(fā)展得過(guò)程，從20世紀(jì)80年代以來(lái)，以歐洲國(guó)家為主導(dǎo)的，采用時(shí)分多址(Time DivisionM ultiple Access，簡(jiǎn)稱“TDMA”)方式的數(shù)字移動(dòng)通信系統(tǒng)——GSM，得到了迅猛發(fā)展，并在今天成為實(shí)現(xiàn)個(gè)人移動(dòng)通信的主流技術(shù)。
在GSM技術(shù)體系中，基站系統(tǒng)(Base Station System，簡(jiǎn)稱“BSS”)是GSM系統(tǒng)實(shí)現(xiàn)無(wú)線通信的關(guān)鍵組成部分，BSS是由基站收發(fā)信機(jī)(BaseTransceiver Station，簡(jiǎn)稱“BTS”)和基站控制器(“Base Station Controller”，簡(jiǎn)稱“BSC”)以及碼率適配單元(Transcoding and Rate Adaptation Unit，簡(jiǎn)稱“TRAU”)組成，BTS屬于BSS的無(wú)線部分，通過(guò)其提供的無(wú)線覆蓋區(qū)使移動(dòng)用戶可直接通過(guò)無(wú)線射頻接口建立與BTS的無(wú)線連接與通信；BSC主要提供對(duì)BSS的控制作用。
從系統(tǒng)構(gòu)成上，一個(gè)BSC根據(jù)需要可以控制多個(gè)BTS，BSC與其所屬的各個(gè)BTS之間的網(wǎng)絡(luò)連接方式可采用星狀、級(jí)聯(lián)、環(huán)狀或混合連接方式。由此可以看出，BTS和BSC是GSM系統(tǒng)中分布最廣，使用最多的兩個(gè)部分，而且一般來(lái)說(shuō)，BTS都是無(wú)人值守的，如果出現(xiàn)問(wèn)題需要BTS能夠自動(dòng)上報(bào)問(wèn)題，以便于系統(tǒng)維護(hù)人員及時(shí)的根據(jù)上報(bào)信息定位問(wèn)題，響應(yīng)問(wèn)題。
操作維護(hù)中心(Operations & Maintenance Center，簡(jiǎn)稱“OMC”)是用于對(duì)GSM系統(tǒng)的集中操作與維護(hù)，允許遠(yuǎn)程集中操作維護(hù)管理，并能支持高層網(wǎng)絡(luò)管理中心的接口。OMC包括遠(yuǎn)端維護(hù)臺(tái)和近端維護(hù)臺(tái)。OMC通常是以UNIX為操作系統(tǒng)通過(guò)相關(guān)應(yīng)用程序?qū)崿F(xiàn)以下功能(1)事件/告警管理(2)故障管理(3)性能管理(4)安全管理(5)配置管理一般情況下，從BSC機(jī)房到基站近端去定位問(wèn)題很不方便，因此增加基站遠(yuǎn)端問(wèn)題定位的手段非常重要，也即是希望設(shè)置一個(gè)綜合的集中的基站遠(yuǎn)端維護(hù)臺(tái)，通過(guò)BSS系統(tǒng)本身的數(shù)據(jù)傳輸能力，把單一的分散的BTS處基站的維護(hù)信息收集起來(lái)，進(jìn)行遠(yuǎn)端問(wèn)題定位以利于系統(tǒng)維護(hù)。
BTS中的基站日志記錄了本基站運(yùn)行時(shí)的各種有用信息，是遠(yuǎn)端定位問(wèn)題的有效手段之一。BTS可以提供遠(yuǎn)端按條件提取日志功能，可以部分或者全部的提取本基站日志，但是在通常情況下，由于BTS中的日志記錄了很多基站運(yùn)行的信息數(shù)據(jù)，導(dǎo)致日志區(qū)數(shù)據(jù)存儲(chǔ)量很大，從基站遠(yuǎn)端維護(hù)臺(tái)提取BTS的日志過(guò)程需要持續(xù)很長(zhǎng)的時(shí)間，這必將影響問(wèn)題響應(yīng)和定位速度。
如果BTS的問(wèn)題不能及時(shí)定位找到問(wèn)題所在或者不能及時(shí)得到響應(yīng)，都有可能影響到BTS下面所連接的用戶群，使用戶出現(xiàn)一些使用問(wèn)題，嚴(yán)重時(shí)引起用戶投訴，給運(yùn)營(yíng)商的設(shè)備維護(hù)部門帶來(lái)很大的壓力。因此采用新技術(shù)以提高基站日志提取速度是非常有實(shí)用價(jià)值的。
在目前采用的日志提取技術(shù)中，論是基站近端維護(hù)臺(tái)還是遠(yuǎn)端維護(hù)臺(tái)提取日志都是將原始日志直接上報(bào)。
在實(shí)際應(yīng)用中，上述方案存在以下問(wèn)題由于每個(gè)BTS日志中記錄了大量的信息，而且BSC下面管理BTS數(shù)量很大，如果是因?yàn)檫h(yuǎn)端定位問(wèn)題而需要提取大量的日志信息，則可能有龐大的數(shù)據(jù)上傳，由此造成從基站遠(yuǎn)端維護(hù)臺(tái)提取BTS的日志過(guò)程需要持續(xù)很長(zhǎng)的時(shí)間，影響問(wèn)題響應(yīng)和定位速度。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種基站日志上報(bào)系統(tǒng)及方法，能夠縮短日志提取過(guò)程所需時(shí)間，從而較好地改善問(wèn)題響應(yīng)和定位速度。
為實(shí)現(xiàn)上述目的，本發(fā)明提供了一種基站日志上報(bào)系統(tǒng)，包含基站和操作維護(hù)中心，其中所述基站包含用于保存未壓縮日志的第一日志存儲(chǔ)區(qū)，所述基站還包含以下模塊第二日志存儲(chǔ)區(qū)，用于保存經(jīng)過(guò)壓縮后的日志；壓縮日志模塊，用于對(duì)所述第一日志存儲(chǔ)區(qū)中的日志進(jìn)行壓縮，并將壓縮后日志保存到所述第二日志存儲(chǔ)區(qū)；壓縮后日志透?jìng)魃蠄?bào)模塊，用于把所述第二日志存儲(chǔ)區(qū)中的壓縮后日志上報(bào)到所述操作維護(hù)中心；所述操作維護(hù)中心還包含以下模塊壓縮后日志透?jìng)鹘邮漳K，用于接收來(lái)自所述壓縮后日志透?jìng)魃蠄?bào)模塊的所述壓縮后日志。
其中，所述第二日志存儲(chǔ)區(qū)是在原先所述基站保存未壓縮日志的存儲(chǔ)區(qū)中分割出來(lái)的一塊存儲(chǔ)空間。
所述操作維護(hù)中心還包含壓縮后日志存儲(chǔ)區(qū)，用于保存所述壓縮后日志透?jìng)鹘邮漳K接收的壓縮后日志。
所述壓縮日志模塊采用以下壓縮算法中的任意一種對(duì)所述第一日志存儲(chǔ)區(qū)中的日志進(jìn)行壓縮ARJ、CAB、JAR、LHA、TAR、ZOO、ARC、LZH、Pak。
本發(fā)明還提供了一種基站日志上報(bào)方法，包含以下步驟A操作維護(hù)中心向基站發(fā)送用于啟動(dòng)日志壓縮的第一命令；B所述基站響應(yīng)所述第一命令，對(duì)未壓縮日志進(jìn)行壓縮；C所述操作維護(hù)中心向所述基站發(fā)送用于查詢壓縮后日志的第二命令；D所述基站響應(yīng)所述第二命令，將所述壓縮后日志發(fā)送到所述操作維護(hù)中心。
其中，所述方法還包含以下步驟所述操作維護(hù)中心通過(guò)輪詢方式查詢所述基站壓縮日志的進(jìn)度；當(dāng)所述基站完成日志壓縮后，向所述操作維護(hù)中心反饋包含壓縮后日志總幀數(shù)的應(yīng)答消息。
所述第二命令中還包含幀號(hào)，所述步驟D中，所述基站判斷所述幀號(hào)是否合法，如果是則向所述操作維護(hù)中心返回所述壓縮后日志中所述幀號(hào)對(duì)應(yīng)的幀。
所述步驟D中，當(dāng)所述操作維護(hù)中心在遠(yuǎn)端時(shí)，所述基站通過(guò)基站控制器的透?jìng)鲗⑺鰤嚎s后日志發(fā)送到所述操作維護(hù)中心。
所述方法還包含以下步驟E所述操作維護(hù)中心向所述基站發(fā)送用于停止壓縮的第三命令；F所述基站響應(yīng)所述第三命令，停止正在或?qū)⒁獔?zhí)行的日志壓縮任務(wù)，并向所述操作維護(hù)中心反饋應(yīng)答消息。
所述第一命令中還包含日志過(guò)濾條件，所述基站對(duì)符合條件的日志進(jìn)行壓縮。
通過(guò)比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的區(qū)別在于，本發(fā)明提出的基站日志上報(bào)方法采用了已有的壓縮算法，通過(guò)改進(jìn)的系統(tǒng)框架，將需要提取的基站日志壓縮后上報(bào)給OMC。此方法通過(guò)改進(jìn)后的基站日志上報(bào)系統(tǒng)實(shí)現(xiàn)，其中，在基站中設(shè)置了用于存儲(chǔ)未壓縮日志的原始日志存儲(chǔ)區(qū)以及用于存儲(chǔ)壓縮后日志的壓縮后日志存儲(chǔ)區(qū)，并增加了用于對(duì)原始日志存儲(chǔ)區(qū)中的日志進(jìn)行壓縮的壓縮日志模塊，以及用于把壓縮后日志存儲(chǔ)區(qū)的壓縮后日志上報(bào)到OMC的壓縮后日志透?jìng)魃蠄?bào)模塊。同時(shí)，在OMC中，增加了用于接收來(lái)自壓縮后日志透?jìng)魃蠄?bào)模塊的壓縮后日志的壓縮后日志透?jìng)鹘邮漳K，以及用于保存接收到的壓縮后日志的壓縮后日志存儲(chǔ)區(qū)。
這種技術(shù)方案上的區(qū)別，帶來(lái)了較為明顯的有益效果，即通過(guò)日志壓縮功能將基站大量的原始日志壓縮后存儲(chǔ)和上報(bào)，大大節(jié)省了操作人員遠(yuǎn)端提取基站工作日志的時(shí)間；同時(shí)，提取的日志直接保存在維護(hù)臺(tái)所在的機(jī)器上，加快了問(wèn)題的響應(yīng)和定位速度。而以前遠(yuǎn)端提取的日志保存在后管理模塊(Back Administration Module，簡(jiǎn)稱“BAM”)中，從圖1中就可以看出，基站近端維護(hù)臺(tái)11和基站遠(yuǎn)端維護(hù)臺(tái)12間在BSS中沒有直接相連的通路，需要相關(guān)人員將日志走其它網(wǎng)絡(luò)通過(guò)郵件發(fā)過(guò)來(lái)。另外，本發(fā)明通過(guò)在原日志上報(bào)系統(tǒng)中進(jìn)行很少的軟件升級(jí)配置就能夠達(dá)到很好的技術(shù)效果，是一種低風(fēng)險(xiǎn)的改進(jìn)升級(jí)方案。


圖1是根據(jù)本發(fā)明的一個(gè)實(shí)施例的基站日志上報(bào)系統(tǒng)的結(jié)構(gòu)式意圖；圖2是根據(jù)本發(fā)明的一個(gè)實(shí)施例的基站日志上報(bào)方法的流程示意圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步地詳細(xì)描述。
總的來(lái)說(shuō)，本發(fā)明的原理就是利用已有的標(biāo)準(zhǔn)GZIP壓縮算法，將BTS處的工作日志壓縮后存放在壓縮后日志存儲(chǔ)區(qū)，并可以通過(guò)在BTS處的壓縮后日志透?jìng)魃蠄?bào)模塊向OMC上傳壓縮后的日志，在基站近端維護(hù)臺(tái)或遠(yuǎn)端維護(hù)臺(tái)增加壓縮后日志透?jìng)鹘邮漳K接收上傳的日志，并存儲(chǔ)在二者各自的壓縮后日志存儲(chǔ)區(qū)。其中，中間的壓縮日志利用原BSC的透?jìng)髟既罩就ǖ纻鬟f信息。
下面結(jié)合圖1描述本發(fā)明的總體解決方案。如圖1所示，本發(fā)明總體上涉及到四個(gè)GSM系統(tǒng)模塊，它們是基站控制器(BSC)10、基站近端維護(hù)臺(tái)(OMC)11、基站遠(yuǎn)端維護(hù)臺(tái)(OMC)12以及基站(BTS)13。
更具體的說(shuō)，在基站控制器10中包含有透?jìng)髟O(shè)備101；在基站近端維護(hù)臺(tái)11中包含有壓縮后日志存儲(chǔ)區(qū)111和壓縮后日志透?jìng)鹘邮漳K112；在基站遠(yuǎn)端維護(hù)臺(tái)12中包含壓縮后日志透?jìng)鹘邮漳K121與壓縮后日志存儲(chǔ)區(qū)122；基站13中包含4個(gè)小模塊壓縮后日志透?jìng)魃蠄?bào)模塊131、壓縮后日志存儲(chǔ)區(qū)132、壓縮日志模塊133、原始日志存儲(chǔ)區(qū)134。需要說(shuō)明的是，基站遠(yuǎn)端維護(hù)臺(tái)12和基站近端維護(hù)臺(tái)11從邏輯上來(lái)說(shuō)屬于一個(gè)OMC。
根據(jù)本發(fā)明，基站13將實(shí)現(xiàn)日志壓縮相關(guān)消息的接收和相應(yīng)的處理。其中，原始日志存儲(chǔ)區(qū)134用于存儲(chǔ)原始日志信息；新增的壓縮日志模塊133用于將原始日志存儲(chǔ)區(qū)134的日志壓縮后發(fā)送給壓縮后日志存儲(chǔ)區(qū)132；壓縮后日志存儲(chǔ)區(qū)132用于存儲(chǔ)上述壓縮后日志；壓縮后日志透?jìng)魃蠄?bào)模塊131用于把壓縮后日志存儲(chǔ)區(qū)132中存儲(chǔ)的壓縮后日志上報(bào)到OMC。
基站控制器10中包含有透穿設(shè)備101，用于實(shí)現(xiàn)對(duì)日志壓縮相關(guān)消息的完全透?jìng)鳎沟迷摴δ艿男薷闹痪窒抻贠MC和基站13側(cè)。
基站遠(yuǎn)端維護(hù)臺(tái)12和基站近端維護(hù)臺(tái)11分別由各自的壓縮后日志透?jìng)鹘邮漳K實(shí)現(xiàn)日志壓縮相關(guān)消息的下發(fā)和接收，并在各自的壓縮后日志存儲(chǔ)區(qū)保存接收到的的壓縮后的日志。具體的說(shuō)，基站近端維護(hù)臺(tái)11包含壓縮后日志透?jìng)鹘邮漳K112和壓縮后日志存儲(chǔ)區(qū)111。其中，壓縮后日志透?jìng)鹘邮漳K112用于實(shí)現(xiàn)日志壓縮相關(guān)消息的下發(fā)和接收，壓縮后日志存儲(chǔ)區(qū)111用于保存上報(bào)的壓縮后的日志。而基站遠(yuǎn)端維護(hù)臺(tái)12包含壓縮后日志透?jìng)鹘邮漳K121以及壓縮后日志存儲(chǔ)區(qū)122。其中，壓縮后日志透?jìng)鹘邮漳K121同樣用于實(shí)現(xiàn)日志壓縮相關(guān)消息的下發(fā)和接收，壓縮后日志存儲(chǔ)區(qū)122同樣用于保存上報(bào)的壓縮后的日志。
需要說(shuō)明的是，BSS原先的日志系統(tǒng)也有透?jìng)魑磯嚎s的原始日志信息的功能，本發(fā)明透?jìng)鞴δ苣K利用了原先的傳輸功能模塊，同樣實(shí)現(xiàn)了數(shù)據(jù)的透?jìng)?，但是本發(fā)明在傳輸功能模塊中傳輸?shù)膬?nèi)容有所不同，是壓縮后的日志信息。
同時(shí)，本發(fā)明方案設(shè)計(jì)上同原有未壓縮日志的查詢機(jī)制實(shí)現(xiàn)了兼容，本發(fā)明沒有對(duì)原BSS進(jìn)行硬件上的改動(dòng)，只是進(jìn)行了軟件上的升級(jí)，采用了另外的一套指令集和存儲(chǔ)空間。
還需要說(shuō)明的是，在本發(fā)明中，為保證日志提取的可靠性，基站近端維護(hù)臺(tái)11和基站遠(yuǎn)端維護(hù)臺(tái)12與基站13間消息采用同時(shí)一對(duì)一的查詢機(jī)制，由基站近端維護(hù)臺(tái)11或者基站遠(yuǎn)端維護(hù)臺(tái)12下發(fā)一條查詢命令，基站13上報(bào)一幀壓縮后的日志，基站13在未接收到基站近端維護(hù)臺(tái)11或者基站遠(yuǎn)端維護(hù)臺(tái)12查詢命令時(shí)，不主動(dòng)發(fā)起同基站近端維護(hù)臺(tái)11或者基站遠(yuǎn)端維護(hù)臺(tái)12的通訊。同時(shí)還通過(guò)總幀數(shù)和幀號(hào)避免丟幀。
由于基站側(cè)采用的技術(shù)在本發(fā)明中是關(guān)鍵技術(shù)，下面將結(jié)合圖1和圖2再重點(diǎn)闡述基站13側(cè)的實(shí)現(xiàn)方案。
在基站13中，壓縮后日志存儲(chǔ)區(qū)132的確定是關(guān)鍵問(wèn)題?；?3工作日志最初保存在原始日志存儲(chǔ)區(qū)134中，以6M為其最大容量，根據(jù)對(duì)GZIP壓縮比的估算，本發(fā)明從6M中拿出1M空間作為壓縮后日志存儲(chǔ)區(qū)132來(lái)存放壓縮后的工作日志。即在物理上壓縮后日志存儲(chǔ)區(qū)132和原始日志存儲(chǔ)區(qū)134都在基站現(xiàn)有技術(shù)中的原始日志存儲(chǔ)器上，邏輯上二者分開，壓縮后日志存儲(chǔ)區(qū)132占用原始日志存儲(chǔ)器1M空間，原始日志存儲(chǔ)區(qū)134占用原始日志存儲(chǔ)器5M空間，本發(fā)明從原先不大的空間中再劃出一塊來(lái)而不是新增一塊存儲(chǔ)器以增加存儲(chǔ)空間，是考慮到盡量減少BSS硬件上的改動(dòng)。
另一方面，為實(shí)現(xiàn)壓縮后的日志上報(bào)，基站13與基站近端維護(hù)臺(tái)11/基站遠(yuǎn)端維護(hù)臺(tái)12分別新增三個(gè)消息接口啟動(dòng)日志壓縮，查詢壓縮日志和停止日志壓縮。也就是說(shuō)，基站近端維護(hù)臺(tái)11和基站遠(yuǎn)端維護(hù)臺(tái)12與基站13間消息傳遞時(shí)，需要在信令流中增加上述條信令。
下面參照?qǐng)D2，進(jìn)一步說(shuō)明根據(jù)本發(fā)明的一個(gè)實(shí)施例的基站日志上報(bào)方法的具體步驟。
首先需要說(shuō)明，圖2中的OMC 20就是指圖1中的基站遠(yuǎn)端維護(hù)臺(tái)12和基站近端維護(hù)臺(tái)11，如上所述，邏輯上來(lái)說(shuō)它們屬于一個(gè)OMC。
從圖2中的信令流可以看出，首先在步驟200，OMC 20向基站13發(fā)送啟動(dòng)壓縮后的日志上報(bào)命令，這個(gè)命令中含有標(biāo)志為0的信息，表示基站維護(hù)臺(tái)下發(fā)基站開始?jí)嚎s日志的命令，這個(gè)命令中還包含日志過(guò)濾條件，基站13對(duì)符合條件的日志進(jìn)行壓縮。
接著在步驟201，基站13對(duì)步驟200中發(fā)來(lái)的啟動(dòng)命令進(jìn)行響應(yīng)，正確處理啟動(dòng)壓縮后的日志上報(bào)命令；并正確創(chuàng)建并啟動(dòng)壓縮日志任務(wù)，對(duì)未壓縮日志進(jìn)行壓縮，同時(shí)向OMC 20發(fā)送啟動(dòng)壓縮后的日志上報(bào)確認(rèn)(ACK)，告訴它正在壓縮。
隨后在步驟202，OMC 20又開始對(duì)基站13發(fā)送啟動(dòng)壓縮后的日志上報(bào)命令，不同于步驟200中的命令之處在于，這個(gè)命令中含有標(biāo)志為1的信息，表示基站維護(hù)臺(tái)輪詢基站日志壓縮是否完成的命令。
由于基站13還在壓縮日志，于是在步驟203，基站13對(duì)步驟200中發(fā)來(lái)的啟動(dòng)命令進(jìn)行響應(yīng)，同時(shí)向OMC 20發(fā)送啟動(dòng)壓縮后的日志上報(bào)確認(rèn)(ACK)，告訴它正在壓縮。
在步驟204，OMC 20繼續(xù)對(duì)基站13發(fā)送啟動(dòng)壓縮后的日志上報(bào)命令，命令中含有標(biāo)志為1的信息。
由于此時(shí)基站13已經(jīng)完成日志的壓縮，于是在步驟205，不再向OMC 20發(fā)送和步驟203相同的上報(bào)命令，而是發(fā)送啟動(dòng)壓縮后的日志上報(bào)確認(rèn)(ACK)，壓縮完成的命令，告訴OMC 20日志已經(jīng)壓縮好，可以提取。這個(gè)命令還包含著壓縮完成后基站13壓縮日志的總幀數(shù)。
需要說(shuō)明的是，在步驟201和205間是個(gè)輪詢方式查找進(jìn)度，可能存在更多的相似信令流，圖2中用省略號(hào)表示，同時(shí)，在步驟200與步驟205期間，基站13一直在進(jìn)行日志壓縮的處理過(guò)程，這個(gè)過(guò)程大概有數(shù)秒的時(shí)間，這個(gè)時(shí)間幾乎等于輪詢方式查詢的時(shí)間。
接下來(lái)，即將對(duì)壓縮好的日志進(jìn)行傳遞。如圖所示，在步驟206，OMC20向基站13發(fā)出提取壓縮后的第1幀日志的命令。
基站13收到后，響應(yīng)此命令，在步驟207，經(jīng)過(guò)圖1中的基站控制器10的透?jìng)髟O(shè)備101，向OMC 20上報(bào)壓縮后的第1幀日志。
然后在步驟208，OMC 20向基站13繼續(xù)發(fā)出提取壓縮后的第n幀日志的命令。
基站13收到后，響應(yīng)此命令，同樣在步驟209，經(jīng)過(guò)圖1中的基站控制器10的透?jìng)髟O(shè)備101向OMC 20上報(bào)壓縮后的第n幀日志。
需要說(shuō)明的是，步驟206到步驟208，就是壓縮好的日志傳遞的過(guò)程，OMC 20向基站13發(fā)送的提起命令中包含幀號(hào)，逐幀提取壓縮后日志；同時(shí)，如果提取某幀壓縮日志失敗則重試，重試3次都失敗則終止整個(gè)過(guò)程。
如果209第n幀就是最后一幀壓縮日志的信息，那么完成后，在步驟210，OMC 20需要向基站13發(fā)送停止壓縮后日志上報(bào)命令，
最后，在步驟211，基站13響應(yīng)這條命令，停止正在或?qū)⒁獔?zhí)行的日志壓縮任務(wù)，并向基站維護(hù)臺(tái)反饋應(yīng)答消息，發(fā)送停止壓縮后日志上報(bào)確認(rèn)(ACK)。
需要指出的是，在本發(fā)明中，對(duì)日志的壓縮采用的是GZIP標(biāo)準(zhǔn)壓縮算法，該算法壓縮比率較大，經(jīng)驗(yàn)證5M的日志完全可以壓縮后存儲(chǔ)在1M的空間中。但是，熟悉本領(lǐng)域的技術(shù)人員可以理解，在本發(fā)明的其他實(shí)施例中，也可以采用與GZIP類似的其他算法，比如PKZIP、ARJ、CAB、JAR、LHA、TAR、ZOO、ARC、LZH、Pak等。
從上面的流程可以看出，基站13對(duì)OMC 20發(fā)來(lái)的每條命令的響應(yīng)各不相同，同時(shí)本發(fā)明還針對(duì)基站13日志壓縮過(guò)程中出現(xiàn)的異常情況制定了保護(hù)功能響應(yīng)，下面再進(jìn)一步針對(duì)啟動(dòng)命令的響應(yīng)、停止命令的響應(yīng)、以及查詢命令的響應(yīng)中的不同情況以及保護(hù)功能進(jìn)行說(shuō)明。
啟動(dòng)命令的響應(yīng)(1)正確處理啟動(dòng)壓縮后的日志上報(bào)命令；(2)正確創(chuàng)建并啟動(dòng)壓縮日志任務(wù)；(3)根據(jù)日志壓縮狀態(tài)正確應(yīng)答。如果日志壓縮失敗，向維護(hù)臺(tái)回NACK，原因值是壓縮失??；如果正在壓縮日日志，向維護(hù)臺(tái)回ACK，標(biāo)志為正在壓縮日志；如果壓縮日志已經(jīng)完成，向維護(hù)臺(tái)回ACK，標(biāo)志為壓縮完成，這里的標(biāo)志都是附帶在反饋的ACK和NACK命令中的，消息中還包括壓縮后的日志總幀數(shù)。
停止命令響應(yīng)(1)正確處理停止日志壓縮功能的命令；(2)如果應(yīng)答ACK，且壓縮日志任務(wù)在運(yùn)行，刪除壓縮日志任務(wù)；(3)如果應(yīng)答ACK，且日志壓縮功能已經(jīng)啟動(dòng)，則初始化日志壓縮功能使用的全局變量。
需要說(shuō)明的是，本響應(yīng)中的兩種情況，(2)中的壓縮日志任務(wù)在運(yùn)行指壓縮正在進(jìn)行，而(3)中的日志壓縮功能已經(jīng)啟動(dòng)卻是表示壓縮還沒有運(yùn)行。
查詢命令響應(yīng)(1)如果日志壓縮功能沒有啟動(dòng)，直接應(yīng)答NACK，原因值消息無(wú)法執(zhí)行，否則繼續(xù)；(2)如果消息中的工作臺(tái)號(hào)與啟動(dòng)日志壓縮功能的工作臺(tái)號(hào)不同，直接應(yīng)答NACK，原因值資源不可用，否則繼續(xù)；這個(gè)響應(yīng)的情況是考慮到不同工作臺(tái)需要壓縮和下載的日志段可能不同而制訂的；(3)如果正在壓縮日志，直接應(yīng)答NACK，原因值請(qǐng)等待，否則繼續(xù)；(4)如果幀號(hào)不合法，直接應(yīng)答NACK，原因值參數(shù)越界；(5)根據(jù)消息中的幀號(hào)上報(bào)對(duì)應(yīng)的壓縮日志。
保護(hù)功能(1)日志壓縮功能和普通日志提取功能不能同時(shí)執(zhí)行；這是考慮到同一個(gè)基站維護(hù)臺(tái)提取這兩部分時(shí)可能會(huì)出現(xiàn)一些進(jìn)程上的沖突，如果維護(hù)臺(tái)不同，則如有需要可以同時(shí)提?。?2)遠(yuǎn)端和近端日志壓縮功能不能同時(shí)執(zhí)行；(3)日志壓縮過(guò)程中，不允許繼續(xù)寫新增日志；(4)日志壓縮功能啟動(dòng)5分鐘過(guò)程中，一直未收到基站維護(hù)臺(tái)的壓縮消息，則5分鐘后自動(dòng)停止日志壓縮功能。
雖然通過(guò)參照本發(fā)明的某些優(yōu)選實(shí)施例，已經(jīng)對(duì)本發(fā)明進(jìn)行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細(xì)節(jié)上對(duì)其作各種各樣的改變，而不偏離所附權(quán)利要求書所限定的本發(fā)明的精神和范圍。
權(quán)利要求
1.一種基站日志上報(bào)系統(tǒng)，包含基站和操作維護(hù)中心，其中所述基站包含用于保存未壓縮日志的第一日志存儲(chǔ)區(qū)，其特征在于，所述基站還包含以下模塊第二日志存儲(chǔ)區(qū)，用于保存經(jīng)過(guò)壓縮后的日志；壓縮日志模塊，用于對(duì)所述第一日志存儲(chǔ)區(qū)中的日志進(jìn)行壓縮，并將壓縮后日志保存到所述第二日志存儲(chǔ)區(qū)；壓縮后日志透?jìng)魃蠄?bào)模塊，用于把所述第二日志存儲(chǔ)區(qū)中的壓縮后日志上報(bào)到所述操作維護(hù)中心；所述操作維護(hù)中心還包含以下模塊壓縮后日志透?jìng)鹘邮漳K，用于接收來(lái)自所述壓縮后日志透?jìng)魃蠄?bào)模塊的所述壓縮后日志。
2.根據(jù)權(quán)利要求1所述的基站日志上報(bào)系統(tǒng)，其特征在于，所述第二日志存儲(chǔ)區(qū)是在原先所述基站保存未壓縮日志的存儲(chǔ)區(qū)中分割出來(lái)的一塊存儲(chǔ)空間。
3.根據(jù)權(quán)利要求1所述的基站日志上報(bào)系統(tǒng)，其特征在于，所述操作維護(hù)中心還包含壓縮后日志存儲(chǔ)區(qū)，用于保存所述壓縮后日志透?jìng)鹘邮漳K接收的壓縮后日志。
4.根據(jù)權(quán)利要求1所述的基站日志上報(bào)系統(tǒng)，其特征在于，所述壓縮日志模塊采用以下壓縮算法中的任意一種對(duì)所述第一日志存儲(chǔ)區(qū)中的日志進(jìn)行壓縮ARJ、CAB、JAR、LHA、TAR、ZOO、ARC、LZH、Pak。
5.一種基站日志上報(bào)方法，其特征在于，包含以下步驟A操作維護(hù)中心向基站發(fā)送用于啟動(dòng)日志壓縮的第一命令；B所述基站響應(yīng)所述第一命令，對(duì)未壓縮日志進(jìn)行壓縮；C所述操作維護(hù)中心向所述基站發(fā)送用于查詢壓縮后日志的第二命令；D所述基站響應(yīng)所述第二命令，將所述壓縮后日志發(fā)送到所述操作維護(hù)中心。
6.根據(jù)權(quán)利要求5所述的基站日志上報(bào)方法，其特征在于，所述方法還包含以下步驟所述操作維護(hù)中心通過(guò)輪詢方式查詢所述基站壓縮日志的進(jìn)度；當(dāng)所述基站完成日志壓縮后，向所述操作維護(hù)中心反饋包含壓縮后日志總幀數(shù)的應(yīng)答消息。
7.根據(jù)權(quán)利要求5所述的基站日志上報(bào)方法，其特征在于，所述第二命令中還包含幀號(hào)，所述步驟D中，所述基站判斷所述幀號(hào)是否合法，如果是則向所述操作維護(hù)中心返回所述壓縮后日志中所述幀號(hào)對(duì)應(yīng)的幀。
8.根據(jù)權(quán)利要求5所述的基站日志上報(bào)方法，其特征在于，所述步驟D中，當(dāng)所述操作維護(hù)中心在遠(yuǎn)端時(shí)，所述基站通過(guò)基站控制器的透?jìng)鲗⑺鰤嚎s后日志發(fā)送到所述操作維護(hù)中心。
9.根據(jù)權(quán)利要求5所述的基站日志上報(bào)方法，其特征在于，所述方法還包含以下步驟E所述操作維護(hù)中心向所述基站發(fā)送用于停止壓縮的第三命令；F所述基站響應(yīng)所述第三命令，停止正在或?qū)⒁獔?zhí)行的日志壓縮任務(wù)，并向所述操作維護(hù)中心反饋應(yīng)答消息。
10.根據(jù)權(quán)利要求5所述的基站日志上報(bào)方法，其特征在于，所述第一命令中還包含日志過(guò)濾條件，所述基站對(duì)符合條件的日志進(jìn)行壓縮。
全文摘要
本發(fā)明涉及通信領(lǐng)域，公開了一種基站日志上報(bào)系統(tǒng)及方法，能夠縮短日志提取過(guò)程所需時(shí)間，從而較好地改善問(wèn)題響應(yīng)和定位速度。這種基站日志上報(bào)系統(tǒng)包含基站和操作維護(hù)中心，其中基站包含用于保存未壓縮日志的第一日志存儲(chǔ)區(qū)、用于保存經(jīng)過(guò)壓縮后的日志的第二日志存儲(chǔ)區(qū)、用于對(duì)第一日志存儲(chǔ)區(qū)中的日志進(jìn)行壓縮，并將壓縮后日志保存到第二日志存儲(chǔ)區(qū)的壓縮日志模塊、用于把第二日志存儲(chǔ)區(qū)中的壓縮后日志上報(bào)到操作維護(hù)中心的壓縮后日志透?jìng)魃蠄?bào)模塊；操作維護(hù)中心包含以下模塊用于接收來(lái)自壓縮后日志透?jìng)魃蠄?bào)模塊的壓縮后日志的壓縮后日志透?jìng)鹘邮漳K。
文檔編號(hào)H04W88/08GK1719918SQ20041007151
公開日2006年1月11日 申請(qǐng)日期2004年7月7日 優(yōu)先權(quán)日2004年7月7日
發(fā)明者魯智鋒, 文凱, 沈同林, 陳煜樵, 陳萍, 陳建 申請(qǐng)人:華為技術(shù)有限公司