專利名稱：一種通用分組無線服務(wù)隧道用戶面路徑保活方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種在LTE(Long Term Evolution,長(zhǎng)期演進(jìn))系統(tǒng)中eNB (evolved Node B，演進(jìn)的節(jié)點(diǎn)B)之間，或者eNB與EPC (Evolved PacketCore,演進(jìn)的分組數(shù)據(jù)的核 心網(wǎng))之間GPRS (General Packet RadioService，通用分組無線服務(wù))隧道用戶面(簡(jiǎn)稱 GTPU， GPRS TunnelProtocol User-plane)路徑保活的處理技術(shù)。
背景技術(shù)：
在LTE移動(dòng)通訊系統(tǒng)里面，eNB網(wǎng)元提供了各式各樣的UE (UserEquipment，用戶設(shè) 備)接入EPC(Evolved Packet Core,演進(jìn)的分組數(shù)據(jù)的核心網(wǎng))的通道。LTE系統(tǒng)采用扁 平化網(wǎng)絡(luò)結(jié)構(gòu)，對(duì)eNB來說，地面?zhèn)鬏斨饕婕皟蓚€(gè)接口 S1接口 (Sl接口為EPC和eNB間 接口 )和X2接口 (X2接口為eNB間接口 )。接口示意圖如附圖1所示。Sl、 X2接口采用 IP (Internet Protocol,網(wǎng)際協(xié)議)傳輸，SI接口斷鏈會(huì)導(dǎo)致業(yè)務(wù)不可行，X2接口斷鏈會(huì)導(dǎo) 致跨eNB切換不可行。接口上用戶面數(shù)據(jù)采用GTPU協(xié)議進(jìn)行傳輸。 在實(shí)際組網(wǎng)中，一個(gè)eNB可能和多個(gè)eNB連接，Sl和X2 口也不是僅直接連接著eNB 或者EPC，也就是說有可能中間經(jīng)過了多級(jí)交換和路由設(shè)備甚至多種物理承載，而這些路由 和交換設(shè)備甚至傳輸承載的可靠性并不能百分之百的保證。 GTPU協(xié)議是基于UDP(User Datagram Protocol,用戶數(shù)據(jù)報(bào)文協(xié)議)協(xié)議的，UDP
協(xié)議是一個(gè)無連接無確認(rèn)的協(xié)議，也就是說，如果底層斷鏈，UDP協(xié)議以及下層協(xié)議缺乏一
個(gè)有效的發(fā)現(xiàn)機(jī)制，所以GTPU協(xié)議規(guī)定了一個(gè)路徑保活的機(jī)制，但是這個(gè)路徑?；顧C(jī)制需
要較長(zhǎng)的時(shí)間才能確認(rèn)底層鏈路斷鏈，GTPU路徑?；钪饕幸韵聨讉€(gè)步驟 1) eNB或EPC任何一端都可以作為?；顧C(jī)制的發(fā)起端，而另一端作為響應(yīng)端，發(fā)起
端主動(dòng)定時(shí)向響應(yīng)端發(fā)送?；钕ⅲ憫?yīng)端響應(yīng)消息，發(fā)起端在定時(shí)器超時(shí)的時(shí)間間隔里
面收到響應(yīng)，則認(rèn)為鏈路正常； 2)如果定時(shí)器超時(shí)而發(fā)起端未收到響應(yīng)報(bào)文，發(fā)起端不能馬上判定路徑異常，而 需要再次發(fā)送路徑?；钕ⅲ?3)只有在發(fā)送消息超時(shí)多次未收到任何響應(yīng)，發(fā)起端才會(huì)認(rèn)為底層鏈路異常，從 而釋放對(duì)應(yīng)鏈路上的所有相關(guān)資源。 在上述?；盍鞒汤锩妫瑓f(xié)議沒有限定超時(shí)定時(shí)器的時(shí)長(zhǎng)和重發(fā)次數(shù)，但是限定了 正常情況下發(fā)送路徑保活消息的間隔必須不小于60秒。而考慮網(wǎng)絡(luò)繁忙情況下正常丟包， 重發(fā)次數(shù)可能需要10次左右才算合理。也就是說，按照協(xié)議流程，GTPU以及上層需要10分 鐘才能識(shí)別底層鏈路斷鏈。 需要特別說明的是，在GTPU的傳輸路徑上面，時(shí)刻都有可能有業(yè)務(wù)數(shù)據(jù)在傳輸， 而不僅僅是路徑保活消息在傳輸。而對(duì)應(yīng)這些業(yè)務(wù)數(shù)據(jù)是會(huì)占用其它資源的，例如，eNB通 過S1接口發(fā)往EPC的報(bào)文，最初的來源是UE， UE產(chǎn)生業(yè)務(wù)數(shù)據(jù)，通過UE的接入層處理，在 空口上被發(fā)送到eNB，然后通過eNB的用戶面處理，才以GTPU協(xié)議報(bào)文的方式通過SI接口 發(fā)往EPC。也就是說，如果SI接口斷鏈，但是UE不能即時(shí)檢測(cè)到，則UE會(huì)按照正常流程發(fā)送業(yè)務(wù)報(bào)文，這些業(yè)務(wù)報(bào)文會(huì)占用UE、 eNB的處理資源，會(huì)占用空中接口的帶寬，但是報(bào)文 實(shí)際上是送不到預(yù)期的對(duì)端的。 如果按照標(biāo)準(zhǔn)的協(xié)議流程，則在這10分鐘里面，斷鏈的路徑上面對(duì)應(yīng)的業(yè)務(wù)實(shí)際 上是不通的，對(duì)應(yīng)業(yè)務(wù)的UE處理資源、eNB處理資源、空中無線資源是浪費(fèi)的；又因?yàn)橄到y(tǒng) 側(cè)不能及時(shí)識(shí)別異常并通知到用戶，例如用戶正在通話中Sl/X2通道斷鏈，用戶認(rèn)為系統(tǒng) 正常但是實(shí)際已經(jīng)無法通話了，用戶對(duì)系統(tǒng)的滿意度會(huì)下降。 之所以GTPU協(xié)議定義一個(gè)這樣的?；顓f(xié)議，是因?yàn)镚TPU協(xié)議最初是適配2G和3G 組網(wǎng)的，在2/3G時(shí)代，系統(tǒng)組網(wǎng)尚未扁平化，eNB被拆分成基站和基站控制器，GTPU協(xié)議在 基站控制器和核心網(wǎng)之間發(fā)生作用，而基站控制器和核心網(wǎng)之間的組網(wǎng)往往非常簡(jiǎn)單(甚 至可能基站控制器和核心網(wǎng)的接入設(shè)備就在統(tǒng)一機(jī)房)，同時(shí)，早期的組網(wǎng)多采用異步傳輸 模式組網(wǎng)，網(wǎng)絡(luò)的連通性可以通過其它方式檢測(cè)。而LTE系統(tǒng)組網(wǎng)采用IP傳輸，檢測(cè)斷鏈 的方便性大大減少，同時(shí)，eNB和核心網(wǎng)之間的距離拉大，導(dǎo)致底層傳輸鏈路斷鏈的可能性 大大加大。但是LTE系統(tǒng)沿用GTPU協(xié)議，協(xié)議本身并未做任何改進(jìn)。因此，LTE系統(tǒng)里面 有較大可能會(huì)出現(xiàn)因?yàn)镚TPU鏈路異常導(dǎo)致相關(guān)資源浪費(fèi)，用戶滿意度降低的情況。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提出一種路徑?；畹姆椒ê拖到y(tǒng)，使包含GTPU協(xié)議 層的各網(wǎng)元能更快地檢測(cè)到之間的傳輸鏈路異常，從而減少相關(guān)資源的浪費(fèi)，提升用戶滿意度。 本發(fā)明的技術(shù)方案是 —種GTPU路徑保活方法，包括以下處理步驟 1)正常狀態(tài)下，各網(wǎng)元的GTPU協(xié)議層按照協(xié)議規(guī)定發(fā)送業(yè)務(wù)報(bào)文，并定時(shí)發(fā)送路 徑?；钕ⅲ?2)網(wǎng)元同時(shí)通過非GTPU路徑?；罘绞絺蓽y(cè)GTPU傳輸路徑的連接情況； 3)當(dāng)網(wǎng)元通過底層監(jiān)測(cè)到所述鏈路斷鏈，而GTPU協(xié)議層尚未檢測(cè)到時(shí)，監(jiān)測(cè)端網(wǎng)
元中的GTPU協(xié)議層作為?；畎l(fā)起端，加大向保活響應(yīng)端發(fā)送路徑?；钕⒌念l率，并等待
?；铐憫?yīng)端的路徑保護(hù)響應(yīng)，?；畎l(fā)起端根據(jù)?；钕⒌捻憫?yīng)消息判斷鏈路的狀態(tài)； 4)如果鏈路正常，返回步驟1);如果鏈路異常，通知網(wǎng)元GTPU協(xié)議層的上層釋放
鏈路相關(guān)業(yè)務(wù)。 進(jìn)一步地，所述步驟2)中具體為通過網(wǎng)元之間的發(fā)送GTPU報(bào)文，并偵測(cè)中間設(shè) 備反饋的ICMP報(bào)文的方式監(jiān)測(cè)傳輸通道鏈路連接情況。
優(yōu)選的，所述步驟3)進(jìn)一步包括以下處理步驟
31)?；畎l(fā)起端接收到傳輸通道鏈路斷鏈的通知； 32)?；畎l(fā)起端加大路徑?；钕⒌陌l(fā)送頻率，并對(duì)消息設(shè)定響應(yīng)接收定時(shí)器； 該步驟中設(shè)定的響應(yīng)接收定時(shí)器的時(shí)長(zhǎng)應(yīng)大于傳輸鏈路的正常時(shí)延；一般略大即可，為了 提升效率，不用設(shè)置的特別大。 33)?；畎l(fā)起端統(tǒng)計(jì)在各定時(shí)器定時(shí)范圍內(nèi)接收的響應(yīng)情況，判斷鏈路的狀態(tài)。
所述步驟33)進(jìn)一步包括以下處理步驟
331)設(shè)定響應(yīng)次數(shù)門限；
332)如果在響應(yīng)次數(shù)門限內(nèi)?；畎l(fā)起端收到?；钕㈨憫?yīng)，則判斷為鏈路正常；
333)否則，判斷為鏈路異常。 所述的?；畎l(fā)起端和保活響應(yīng)端之間的傳輸接口為SI接口或者X2接口 。所述的 ?；畎l(fā)起端為eNB時(shí)，所述的保護(hù)響應(yīng)端為與發(fā)起端連接的其他eNB或者EPC ;所述的保護(hù) 發(fā)起端為EPC時(shí)，所述的保護(hù)響應(yīng)端為與發(fā)起端連接的eNB。
—種通用分組無線服務(wù)隧道用戶面路徑?；钕到y(tǒng)，包括 ?；畎l(fā)起端，用于在正常狀態(tài)下，向?；铐憫?yīng)端發(fā)送業(yè)務(wù)報(bào)文和定時(shí)發(fā)送路徑保 活消息；還用于在傳輸通道斷鏈時(shí)，加大向?；铐憫?yīng)端發(fā)起路徑?；钕⒌念l率，等待保活 響應(yīng)端的路徑保護(hù)響應(yīng)，并根據(jù)?；钕⒌捻憫?yīng)消息判斷鏈路的狀態(tài)；以及在判斷傳輸通 道斷鏈后，通知網(wǎng)元GTPU協(xié)議層的上層釋放鏈路業(yè)務(wù)；
?；铐憫?yīng)端，用于響應(yīng)?；畎l(fā)起端的路徑保活消息。 進(jìn)一步地，所述?；畎l(fā)起端還用于向保活響應(yīng)端發(fā)送GTPU報(bào)文，以及根據(jù)接收到 的中間設(shè)備反饋的ICMP報(bào)文判斷傳輸通道斷鏈情況。 本發(fā)明通過GTPU協(xié)議層的底層主動(dòng)通知GTPU協(xié)議層傳輸通道可能斷鏈，從而觸 發(fā)GTPU協(xié)議層加快頻率的路徑保活消息發(fā)送的處理方式，加快了 GTPU協(xié)議層對(duì)底層鏈路 異常的發(fā)現(xiàn)過程，從而減少了 Sl/X2接口的丟包，同時(shí)減少了相關(guān)資源的浪費(fèi)，提升了業(yè)務(wù) 質(zhì)量。其中提升業(yè)務(wù)質(zhì)量，減少相關(guān)資源浪費(fèi)的程度取決于更快發(fā)送頻率的設(shè)定。例如正常 的協(xié)議流程是每分鐘發(fā)送一個(gè)路徑保活消息，10次超時(shí)判定路徑異常；而異常路徑?；羁?以是每秒發(fā)送一個(gè)路徑?；钕?，10次超時(shí)判定路徑異常，10秒對(duì)比10分鐘是一個(gè)很大的 改善。本發(fā)明基于LTE系統(tǒng)提出，在LTE系統(tǒng)有較大的應(yīng)用價(jià)值，在使用GTPU協(xié)議的2/3G 系統(tǒng)里面也有應(yīng)用價(jià)值。


圖1為eNodeB和EPC的組網(wǎng)結(jié)構(gòu)原理圖； 圖2為GTPU與IP協(xié)議棧以及傳輸鏈路之間的關(guān)系圖； 圖3為本發(fā)明優(yōu)選實(shí)施例的LTE系統(tǒng)路徑?；罘椒鞒虉D； 圖4為本發(fā)明與現(xiàn)有技術(shù)對(duì)比的優(yōu)選實(shí)施例路徑?；罘椒ㄔ韴D。
具體實(shí)施例方式
下面結(jié)合附圖并通過具體實(shí)施例對(duì)本發(fā)明的技術(shù)方案進(jìn)行詳細(xì)說明。 如圖l所示的組網(wǎng)結(jié)構(gòu)。eNodeB可以與多個(gè)eNodeB通過X2接口相連，也可以與
多個(gè)EPC通過S1接口相連。S1接口和X2接口采用IP傳輸。eNodeB之間以及eNodeB與
EPC之間可能還有一些中間設(shè)備，例如多級(jí)交換和路由設(shè)備等，這些設(shè)備之間還可能有多種
物理承載，這些承載的可靠性無法得到保證。本發(fā)明的路徑?；罘椒ň褪菫榱烁焖俚陌l(fā)
現(xiàn)鏈路異常，釋放業(yè)務(wù)。 如圖2所示的GTPU協(xié)議層和傳輸鏈路的關(guān)系GTPU承載業(yè)務(wù)層的報(bào)文，GTPU的協(xié) 議數(shù)據(jù)和業(yè)務(wù)層的數(shù)據(jù)通過GTPU的封裝，被打包成IP/UDP報(bào)文，IP/UDP報(bào)文可以承載在以 太網(wǎng)等傳輸路徑上面，為了完成IP協(xié)議的數(shù)據(jù)傳輸，有一套相關(guān)的協(xié)議配合，一般將IP協(xié) 議以及相關(guān)協(xié)議統(tǒng)稱為IP協(xié)議棧。為了描述方便，對(duì)于兩個(gè)網(wǎng)關(guān)之間監(jiān)測(cè)傳輸鏈路時(shí)，設(shè)定一個(gè)網(wǎng)元為?；畎l(fā)起端，另一個(gè)網(wǎng)元為保活響應(yīng)端。本發(fā)明系統(tǒng)的基本思路是在正常狀 態(tài)下，?；畎l(fā)起端向?；铐憫?yīng)端發(fā)送業(yè)務(wù)報(bào)文和定時(shí)發(fā)送路徑?；钕?；在傳輸通道斷鏈 時(shí)，?；畎l(fā)起端加大向保活響應(yīng)端發(fā)起路徑?；钕⒌念l率，等待?；铐憫?yīng)端的路徑保護(hù) 響應(yīng)，并根據(jù)?；钕⒌捻憫?yīng)消息判斷鏈路的狀態(tài)；以及在判斷傳輸通道斷鏈后，?；畎l(fā)起 端通知該網(wǎng)元GTPU協(xié)議層的上層釋放鏈路業(yè)務(wù)。而?；铐憫?yīng)端，僅用于響應(yīng)保活發(fā)起端的 路徑?；钕ⅰＦ渲信袛鄠鬏斖ǖ赖逆溌愤B接情況可以采用?；畎l(fā)起端向?；铐憫?yīng)端發(fā) 送GTPU報(bào)文，保活發(fā)起端根據(jù)接收到的中間設(shè)備反饋的ICMP報(bào)文判斷傳輸通道斷鏈情況。 即圖示網(wǎng)元中傳輸?shù)陌I(yè)務(wù)數(shù)據(jù)流、IP協(xié)議棧交互數(shù)據(jù)(ICMP、路由等協(xié)議報(bào)文)和路 徑?；钕ⅰＨ鐖D1中網(wǎng)元eNodeB與EPC都可以作為?；畎l(fā)起端和保活響應(yīng)端，之間的傳 輸接口可以為S1接口或者X2接口。 如圖3所示的?；钐幚砹鞒?，Sl/X2接口兩端設(shè)備按照協(xié)議規(guī)定正常處理路徑保 活流程，同時(shí)正常做業(yè)務(wù)數(shù)據(jù)的收發(fā)。將一端定義為?；畎l(fā)起端，另一端定義為?；铐憫?yīng) 端。正常的路徑?；盍鞒淌潜；畎l(fā)起端定時(shí)向保活響應(yīng)端發(fā)送路徑保活消息，本發(fā)明采用 的是如果中間設(shè)備存在斷鏈，則這種斷鏈可能被GTPU協(xié)議下層的IP協(xié)議棧檢測(cè)到，IP協(xié) 議層主動(dòng)通知GTPU協(xié)議層啟動(dòng)特定路徑?；盍鞒?，例如中間設(shè)備會(huì)向發(fā)起端發(fā)送一個(gè)目 的不可達(dá)的ICMP (Internet Control Message Protocol,網(wǎng)絡(luò)控制消息協(xié)議)報(bào)文。發(fā)起 端在收到這個(gè)ICMP報(bào)文的時(shí)候，會(huì)由發(fā)起端的IP協(xié)議棧偵測(cè)到并進(jìn)行IP協(xié)議層的處理， IP協(xié)議棧同時(shí)通知GTPU協(xié)議層啟動(dòng)特定路徑?；盍鞒?。特定?；钋闆r下，?；畎l(fā)起端以更 快的頻率向?；铐憫?yīng)端發(fā)送路徑保活消息，并啟動(dòng)定時(shí)器，對(duì)發(fā)送消息進(jìn)行響應(yīng)計(jì)數(shù)。如在 路徑?；钕?duì)應(yīng)的定時(shí)器超時(shí)范圍內(nèi)有收到響應(yīng)，則認(rèn)為底層誤報(bào)、鏈路正常、斷鏈?zhǔn)菚?態(tài)行為，恢復(fù)正常的路徑?；钕l(fā)送頻率，S1/X2接口按照GTPU協(xié)議正常處理。如果保 活消息在對(duì)應(yīng)定時(shí)器超時(shí)范圍內(nèi)都沒有收到響應(yīng)，并且其次數(shù)達(dá)到設(shè)定的計(jì)數(shù)閾值，則認(rèn) 為鏈路異常，通知高層釋放鏈路相關(guān)業(yè)務(wù)。 以下再通過一個(gè)具體實(shí)施例，對(duì)比現(xiàn)有計(jì)數(shù)的處理方法和本發(fā)明處理方法的區(qū) 別。 如圖4所示，步驟1為鏈路正常情況下的路徑?；钚帕盍鞒蹋襟E2為當(dāng)中間設(shè)備 和?；铐憫?yīng)端之間發(fā)生鏈路斷鏈的情況下，現(xiàn)有技術(shù)提出的路徑?；钕⑿帕盍鞒?；步驟 3為當(dāng)中間設(shè)備和?；铐憫?yīng)端之間發(fā)生鏈路斷鏈的情況下，本發(fā)明提出的路徑?；钕⑿?令流程。
步驟1 : a)發(fā)起端向響應(yīng)端周期發(fā)送路徑?；钕ⅲl(fā)送周期可以取值為60s，例如箭頭 a、箭頭c所示，發(fā)起端在發(fā)送消息的同時(shí)啟動(dòng)定時(shí)器，定時(shí)器時(shí)長(zhǎng)設(shè)置應(yīng)該比傳輸鏈路的 正常時(shí)延稍長(zhǎng)，例如可以是ls。 b)鏈路正常的情況下，響應(yīng)端收到?；钕?，向發(fā)起端回應(yīng)響應(yīng)，響應(yīng)在發(fā)起端定 時(shí)器超時(shí)前到達(dá)，則認(rèn)為鏈路正常，例如箭頭b、箭頭d，收到響應(yīng)，發(fā)起端取消定時(shí)器。
步驟2 : a)發(fā)起端依舊周期向響應(yīng)端發(fā)送路徑?；钕?，并啟動(dòng)定時(shí)器，如箭頭e，箭頭f 所示； b)此時(shí)中間設(shè)備和響應(yīng)端中間鏈路存在異常，圖示中為X，這個(gè)?；钕?shí)際上到達(dá)不了響應(yīng)端，響應(yīng)端也無從回應(yīng)發(fā)起端； c)則發(fā)起端發(fā)送?；钕r(shí)設(shè)置的定時(shí)器會(huì)超時(shí)； d)多次( 一般設(shè)定10次)周期發(fā)送?；钕?即箭頭g的消息)以及等待回應(yīng) 的定時(shí)器超時(shí)后，發(fā)起端判定傳輸路徑異常，則發(fā)起端通知GTPU協(xié)議上層釋放業(yè)務(wù)，方框h 所示。 現(xiàn)有的處理流程至少需要10分鐘以上的時(shí)間才能夠判定路徑異常。
步驟3 : a)發(fā)起端和響應(yīng)端之間一般存在多級(jí)傳輸設(shè)備和傳輸鏈路，如果中間鏈路斷鏈，
則靠斷鏈位置最近的傳輸設(shè)備應(yīng)該能馬上檢測(cè)到并體現(xiàn)在其路由信息里面。 b)在正常頻率發(fā)送路徑?；钕⒌臅r(shí)候，發(fā)起端還會(huì)發(fā)送非?；钕⒌腉TPU報(bào)
文，也就是正常的業(yè)務(wù)報(bào)文，例如箭頭i，這個(gè)報(bào)文到達(dá)斷鏈位置附近的中間設(shè)備，中間設(shè)備
會(huì)因?yàn)檎也坏巾憫?yīng)端的路由信息而將這個(gè)報(bào)文丟棄，同時(shí)向報(bào)文的源地址發(fā)送ICMP報(bào)文，
例如箭頭j 。通過ICMP協(xié)議中的目的不可達(dá)類型的報(bào)文觸發(fā)GTPU進(jìn)入特定路徑?；盍鞒?br> 是本發(fā)明實(shí)施的一種典型方式，但是不應(yīng)局限于這種方式，例如IP協(xié)議棧路由協(xié)議的某些
流程也可以達(dá)到同樣效果。當(dāng)?shù)讓佑胮pp鏈路的時(shí)候，PPP協(xié)議會(huì)通過PPP協(xié)議的控制流
程檢測(cè)鏈路是否正常；在動(dòng)態(tài)路由過程中，通過路由學(xué)習(xí)，底層也可以檢測(cè)到鏈路異常。 c)發(fā)起端收到這個(gè)ICMP報(bào)文，馬上啟動(dòng)加快頻率的路徑保活處理流程； i.發(fā)起端向響應(yīng)端加快頻率發(fā)送路徑?；钕?，圖中的箭頭k、箭頭l，箭頭m，同
時(shí)啟動(dòng)定時(shí)器和計(jì)數(shù)，定時(shí)器時(shí)長(zhǎng)與正常?；盍鞒痰亩〞r(shí)器設(shè)定相同。 ii.如果在定時(shí)器超時(shí)時(shí)限內(nèi)收到路徑?；铐憫?yīng)，則認(rèn)為鏈路正常，ICMP誤報(bào)，結(jié) 束特殊?；盍鞒?。 iii.如果超時(shí)未收到響應(yīng)，則判斷計(jì)數(shù)是否大于設(shè)定的門限(IO次)，如果未超出 門限，則轉(zhuǎn)流程i。 iv.如果計(jì)數(shù)大于設(shè)定門限，則認(rèn)為路徑異常，結(jié)束加快頻率的?；盍鞒?。 d)參見方框n，如果通過加快頻率的?；盍鞒膛卸ㄦ溌樊惓?，則發(fā)起端通知GTPU
協(xié)議上層釋放業(yè)務(wù)。 按照上述實(shí)施方式，本發(fā)明的處理流程只需要100秒左右，就可以夠判定路徑異 常。因此本發(fā)明相對(duì)于現(xiàn)有技術(shù)，加快了鏈路異常的發(fā)現(xiàn)過程，減少了系統(tǒng)資源的浪費(fèi)，提 升了業(yè)務(wù)質(zhì)量。
權(quán)利要求
一種通用分組無線服務(wù)隧道用戶面路徑保活方法，其特征在于，包括以下處理步驟1)正常狀態(tài)下，各網(wǎng)元的GTPU協(xié)議層按照協(xié)議規(guī)定發(fā)送業(yè)務(wù)報(bào)文，并定時(shí)發(fā)送路徑?；钕?；2)網(wǎng)元同時(shí)通過非GTPU路徑?；罘绞絺蓽y(cè)GTPU傳輸路徑的連接情況；3)當(dāng)網(wǎng)元通過底層監(jiān)測(cè)到所述鏈路斷鏈，而GTPU協(xié)議層尚未檢測(cè)到時(shí)，監(jiān)測(cè)端網(wǎng)元中的GTPU協(xié)議層作為?；畎l(fā)起端，加大向?；铐憫?yīng)端發(fā)送路徑保活消息的頻率，并等待?；铐憫?yīng)端的路徑保護(hù)響應(yīng)，?；畎l(fā)起端根據(jù)?；钕⒌捻憫?yīng)消息判斷鏈路的狀態(tài)；4)如果鏈路正常，返回步驟1)；如果鏈路異常，通知網(wǎng)元GTPU協(xié)議層的上層釋放鏈路相關(guān)業(yè)務(wù)。
2. 根據(jù)權(quán)利要求1所述的通用分組無線服務(wù)隧道用戶面路徑?；罘椒ǎ涮卣髟谟?， 所述步驟2)中具體為通過網(wǎng)元之間的發(fā)送GTPU報(bào)文，并偵測(cè)中間設(shè)備反饋的ICMP報(bào)文 的方式監(jiān)測(cè)傳輸通道鏈路連接情況。
3. 根據(jù)權(quán)利要求1或2所述的通用分組無線服務(wù)隧道用戶面路徑保活方法，其特征在 于，所述步驟3)進(jìn)一步包括以下處理步驟31) ?；畎l(fā)起端接收到傳輸通道鏈路斷鏈的通知；32) 保活發(fā)起端加大路徑保活消息的發(fā)送頻率，并對(duì)消息設(shè)定響應(yīng)接收定時(shí)器；33) ?；畎l(fā)起端統(tǒng)計(jì)在各定時(shí)器定時(shí)范圍內(nèi)接收的響應(yīng)情況，判斷鏈路的狀態(tài)。
4. 根據(jù)權(quán)利要求3所述的通用分組無線服務(wù)隧道用戶面路徑?；罘椒?，其特征在于， 所述步驟33)進(jìn)一步包括以下處理步驟331) 設(shè)定響應(yīng)次數(shù)門限；332) 如果在響應(yīng)次數(shù)門限內(nèi)?；畎l(fā)起端收到?；钕㈨憫?yīng)，則判斷為鏈路正常；333) 否則，判斷為鏈路異常。
5. 根據(jù)權(quán)利要求3所述的通用分組無線服務(wù)隧道用戶面路徑?；罘椒?，其特征在于， 所述步驟32)中設(shè)定的響應(yīng)接收定時(shí)器的時(shí)長(zhǎng)大于傳輸鏈路的正常時(shí)延。
6. 根據(jù)權(quán)利要求3所述的通用分組無線服務(wù)隧道用戶面路徑?；罘椒?，其特征在于， 所述的?；畎l(fā)起端和保活響應(yīng)端之間的傳輸接口為SI接口或者X2接口。
7. 根據(jù)權(quán)利要求6所述的通用分組無線服務(wù)隧道用戶面路徑?；罘椒?，其特征在于， 所述的?；畎l(fā)起端為演進(jìn)的節(jié)點(diǎn)B時(shí)，所述的保護(hù)響應(yīng)端為與發(fā)起端連接的其他演進(jìn)的節(jié) 點(diǎn)B或者演進(jìn)的分組數(shù)據(jù)的核心網(wǎng)；所述的保護(hù)發(fā)起端為演進(jìn)的分組數(shù)據(jù)的核心網(wǎng)時(shí)，所 述的保護(hù)響應(yīng)端為與發(fā)起端連接的演進(jìn)的節(jié)點(diǎn)B。
8. —種通用分組無線服務(wù)隧道用戶面路徑?；钕到y(tǒng)，其特征在于，所述系統(tǒng)包括 ?；畎l(fā)起端，用于在正常狀態(tài)下，向?；铐憫?yīng)端發(fā)送業(yè)務(wù)報(bào)文和定時(shí)發(fā)送路徑?；钕?；還用于在傳輸通道斷鏈時(shí)，加大向?；铐憫?yīng)端發(fā)起路徑?；钕⒌念l率，等待?；铐憫?yīng) 端的路徑保護(hù)響應(yīng)，并根據(jù)?；钕⒌捻憫?yīng)消息判斷鏈路的狀態(tài)；以及在判斷傳輸通道斷 鏈后，通知網(wǎng)元GTPU協(xié)議層的上層釋放鏈路業(yè)務(wù)；?；铐憫?yīng)端，用于響應(yīng)保活發(fā)起端的路徑?；钕ⅰ?br> 9. 根據(jù)權(quán)利要求8所述的通用分組無線服務(wù)隧道用戶面路徑?；钕到y(tǒng)，其特征在于， 所述?；畎l(fā)起端還用于向?；铐憫?yīng)端發(fā)送GTPU報(bào)文，以及根據(jù)接收到的中間設(shè)備反饋的ICMP報(bào)文判斷傳輸通道斷鏈情況。
10.根據(jù)權(quán)利要求8或9所述的通用分組無線服務(wù)隧道用戶面路徑保活系統(tǒng)，其特征在 于，所述的保活發(fā)起端和?；铐憫?yīng)端之間的傳輸接口為SI接口或者X2接口。
全文摘要
本發(fā)明公開了一種通用分組無線服務(wù)隧道用戶面路徑?；罘椒ê拖到y(tǒng)，方法包括處理步驟1)正常狀態(tài)下，各網(wǎng)元的GTPU協(xié)議層照常發(fā)送業(yè)務(wù)報(bào)文，并定時(shí)發(fā)送路徑?；钕ⅲ?)同時(shí)通過非GTPU路徑?；罘绞絺蓽y(cè)GTPU傳輸路徑的連接情況；3)當(dāng)所述鏈路斷鏈，而GTPU協(xié)議層尚未檢測(cè)到時(shí)，保活發(fā)起端加大向?；铐憫?yīng)端發(fā)送路徑保活消息的頻率，并等待?；铐憫?yīng)端的路徑保護(hù)響應(yīng)，?；畎l(fā)起端根據(jù)保活響應(yīng)消息判斷鏈路的狀態(tài)；4)如果鏈路正常，返回步驟1)；如果鏈路異常，通知網(wǎng)元GTPU協(xié)議層的上層釋放鏈路相關(guān)業(yè)務(wù)。采用本發(fā)明，加快了鏈路異常的發(fā)現(xiàn)過程，減少了系統(tǒng)資源的浪費(fèi)，提升了業(yè)務(wù)質(zhì)量。
文檔編號(hào)H04W92/14GK101772194SQ20081024170
公開日2010年7月7日 申請(qǐng)日期2008年12月26日 優(yōu)先權(quán)日2008年12月26日
發(fā)明者湯德龍 申請(qǐng)人:中興通訊股份有限公司