專利名稱:一種數(shù)據(jù)冗余發(fā)送方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域:
本發(fā)明涉及一種數(shù)據(jù)冗余發(fā)送方法及系統(tǒng),特別涉及一種將無線電路域數(shù)據(jù)業(yè)務(wù)在核心網(wǎng)中冗余發(fā)送的方法及系統(tǒng)。
背景技術(shù):
IWF(Interworking Function;互通功能)是無線網(wǎng)絡(luò)和異種網(wǎng)絡(luò)之間電路域數(shù)據(jù)業(yè)務(wù)互通時的協(xié)議轉(zhuǎn)換時,隱蔽物理鏈路和網(wǎng)絡(luò)技術(shù)上差異的設(shè)備,是GSM/WCDMA(Global System for Mobile Communications/Wide-band CodeDivision Multiple Access;全球移動通信系統(tǒng)/寬帶碼分多址接入系統(tǒng))和PSTN(public Switched telphone network;公共交換電話網(wǎng))、ISDN(Integrated ServicesDigital Network;綜合業(yè)務(wù)數(shù)字網(wǎng))、PSPDN(Packet Switched Public DataNetwork;分組交換公共數(shù)據(jù)網(wǎng))電路域數(shù)據(jù)業(yè)務(wù)互通時的一個轉(zhuǎn)換功能設(shè)備。IWF在電路域中的業(yè)務(wù)分為3.1khz、UDI(unresctricted digital information;非受限數(shù)字信息)兩種承載能力,其中3.1khz對應(yīng)著IWF中使用Modem/Fax。IWF分為3.1khz、UDI,3.1khz承載能力可以支持Modem/Fax業(yè)務(wù)。
在GSM里面,由于沒有定義分組域,數(shù)據(jù)業(yè)務(wù)只能通過IWF進(jìn)行,如果一個用戶想通過手機(jī)上網(wǎng)的話,只能通過IWF撥入到PSTN/ISDN的接入服務(wù)器上,再通過接入服務(wù)器上網(wǎng)。而在GPRS(General Packet Radio Service;通用分組無線業(yè)務(wù))出現(xiàn)后,通過手機(jī)上網(wǎng)方式就有兩種了。其中通過手機(jī)給PSTN、ISDN的傳真機(jī)發(fā)送傳真,是IWF的一個重要功能,目前還沒有其他功能可以很好的替代。
在3G時代,IWF的功能逐步弱化為一些點(diǎn)到點(diǎn)業(yè)務(wù)如傳真、遠(yuǎn)程監(jiān)控、遠(yuǎn)程維護(hù)等。但是IWF是網(wǎng)關(guān)設(shè)備入網(wǎng)必須具備的功能,否則網(wǎng)關(guān)設(shè)備就無法入網(wǎng)和繼承原有業(yè)務(wù),另外也是一些如俄羅斯這樣地廣人稀的國家很需要的功能。
在無線核心網(wǎng)中,電路域數(shù)據(jù)業(yè)務(wù)經(jīng)過IWF之后,Modem/Fax/UDI業(yè)務(wù)目前采用的是作為64Kbps碼流處理,其中64Kbps碼流使用G711編碼方案的5ms打包,且使用R4標(biāo)準(zhǔn)中需要對用戶面的數(shù)據(jù)進(jìn)行幀處理的Nbup(Nbinterface User Plane,Nb接口上的用戶平面)支持模式作為用戶層協(xié)議。因?yàn)锳TM(Asynchronous Transfer Mode;異步傳輸模式)網(wǎng)絡(luò)質(zhì)量可靠,所以這種方案在ATM網(wǎng)絡(luò)里面沒有問題,但是在IP(internet protocol;互聯(lián)網(wǎng)協(xié)議)網(wǎng)絡(luò)里面,由于IP網(wǎng)絡(luò)質(zhì)量不可靠,會出現(xiàn)丟包、亂序等問題。亂序問題可以通過一定深度的JB(Jitter Buffer;抖動緩存器)解決,而對于丟包問題,雖然在語音上不存在嚴(yán)重問題,但是對于Modem/fax/UDI業(yè)務(wù),則會存在嚴(yán)重業(yè)務(wù)的影響,因?yàn)镸odem/Fax/UDI對丟包很敏感,因此3GPP(3rd GenerationPartnership Project;第三代移動通信標(biāo)準(zhǔn)化組織)目前定義的IWF核心網(wǎng)的實(shí)現(xiàn)方式在ATM核心網(wǎng)中雖然是可行的,但是在IP網(wǎng)絡(luò)中卻是不可行的。
在現(xiàn)有3GPP R4/5/6版本中,在3GPP協(xié)議29.007、23.910等規(guī)范里面定義如下29007的11.5.2節(jié),經(jīng)過IWF之后的傳輸,Modem信號對PCM(pulsecode modulation;脈沖編碼調(diào)制)方式進(jìn)行G711編碼、64Kbit/s碼流帶寬傳輸。協(xié)議單元為40字節(jié)大小,5ms發(fā)送時間間隔,并且用戶面使用支持模式的UP(User Plane;用戶平面)協(xié)議。該方案類似于固網(wǎng)里面的G711 5ms打包方式傳送Modem/Fax業(yè)務(wù),但是加了UP協(xié)議頭。在23.910里面也有類似定義。
但是經(jīng)過理論分析與實(shí)踐證明,當(dāng)5ms G711在IP網(wǎng)絡(luò)上傳送Modem/Fax業(yè)務(wù)時,只能在IP網(wǎng)絡(luò)質(zhì)量很好的情況下才能保證業(yè)務(wù)質(zhì)量。對于1%,抖動40ms的IP網(wǎng)絡(luò),Modem/fax/UDI業(yè)務(wù)質(zhì)量已經(jīng)無法得到保證,Modem、Fax雖然很容易重新協(xié)商,但最后常常因?yàn)閰f(xié)商次數(shù)過多而失敗。而對于UDI業(yè)務(wù)來說,只有靠鏈路層的重傳才能保證業(yè)務(wù)質(zhì)量,對于非重傳業(yè)務(wù),一樣難以保證業(yè)務(wù)質(zhì)量。
現(xiàn)有在使用RTP(realtime transport protocol;實(shí)時傳輸協(xié)議)時對冗余音頻數(shù)據(jù)進(jìn)行編碼的負(fù)載格式RFC2198規(guī)范規(guī)定的方案中,規(guī)范定義了在固網(wǎng)中的音頻數(shù)據(jù)業(yè)務(wù)的冗余方式,通過增加冗余的RTP載荷來提高抗丟包能力。當(dāng)發(fā)生丟包時,后續(xù)的報(bào)文將攜帶前面一個報(bào)文,接收方補(bǔ)上丟失的報(bào)文,這樣就保證數(shù)據(jù)流的連續(xù)完整性了。冗余報(bào)文的個數(shù)可以通過信令面H.248協(xié)議控制。RFC2198是根據(jù)RTP的PT(payload type;凈荷類型)來定義冗余的。
冗余數(shù)據(jù)報(bào)文的個數(shù)一般根據(jù)網(wǎng)絡(luò)質(zhì)量定,如果網(wǎng)絡(luò)質(zhì)量比較好,則使用1個即可,如果網(wǎng)絡(luò)質(zhì)量比較差,則使用2個。這個過程在IETF RFC2198中有文檔說明,可被恢復(fù)的報(bào)文最大數(shù)目是3個。信令面通過相應(yīng)的QoS(Qualityof Service;業(yè)務(wù)質(zhì)量)指標(biāo)確定指示幾個冗余。冗余數(shù)據(jù)發(fā)送技術(shù)雖然能夠很好的防止丟包發(fā)生,提高數(shù)據(jù)傳輸?shù)目煽啃耘c業(yè)務(wù)質(zhì)量,但是該技術(shù)并不能直接在無線環(huán)境中使用。
綜上所述,目前還沒有能夠利用RFC2198協(xié)議的冗余數(shù)據(jù)發(fā)送技術(shù)的優(yōu)勢,來滿足以無線協(xié)議里面定義的無線電路域數(shù)據(jù)業(yè)務(wù)在核心網(wǎng)中傳輸?shù)娜毕荩沟脽o線業(yè)務(wù)能在IP網(wǎng)絡(luò)中正常運(yùn)行。
發(fā)明內(nèi)容
本發(fā)明提供了一種數(shù)據(jù)冗余發(fā)送方法,用以解決不能利用RFC2198協(xié)議的冗余數(shù)據(jù)發(fā)送技術(shù)的優(yōu)勢,來滿足以無線協(xié)議里面定義的無線電路域數(shù)據(jù)業(yè)務(wù)在核心網(wǎng)中傳輸?shù)娜毕荩沟脽o線業(yè)務(wù)能在IP網(wǎng)絡(luò)中正常運(yùn)行的問題。
本發(fā)明方法包括一種數(shù)據(jù)冗余發(fā)送方法,包括如下步驟A、媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)協(xié)商連接報(bào)文凈荷類型;B、媒體網(wǎng)關(guān)向媒體網(wǎng)關(guān)控制器發(fā)送攜帶所需凈荷類型的報(bào)文;C、媒體網(wǎng)關(guān)控制器按媒體網(wǎng)關(guān)所需凈荷類型,將UP用戶平面協(xié)議頭冗余編碼所需凈荷類型發(fā)送至媒體網(wǎng)關(guān)。
其中步驟A中所述媒體網(wǎng)關(guān)控制器實(shí)時與媒體網(wǎng)關(guān)協(xié)商連接報(bào)文凈荷類型。
其中步驟A中所述報(bào)文為ITU G711編碼方案的報(bào)文。
其中步驟B中所述媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)是通過IP承載控制協(xié)議協(xié)商的。
其中步驟B中所述媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)是通過控制面協(xié)商的。
其中步驟C中所述冗余編碼是在實(shí)時傳輸協(xié)議層上進(jìn)行的。
其中步驟C中所述UP用戶平面協(xié)議頭冗余個數(shù),由信令面通過相應(yīng)的網(wǎng)絡(luò)服務(wù)質(zhì)量指標(biāo)確定。
其中所述冗余個數(shù)為2個或3個。
本發(fā)明還提供了一種數(shù)據(jù)冗余發(fā)送系統(tǒng),包括媒體網(wǎng)關(guān)控制器、媒體網(wǎng)關(guān),還包括數(shù)據(jù)冗余編碼模塊,用于在媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)協(xié)商確定基于ITU G711協(xié)議的連接報(bào)文凈荷類型后,將UP用戶平面協(xié)議頭冗余編碼進(jìn)所需凈荷類型,由媒體網(wǎng)關(guān)控制器發(fā)送至媒體網(wǎng)關(guān)。
本發(fā)明將RFC 2198協(xié)議中的冗余發(fā)送方法,通過UP頭作為G711編碼方案中的一種動態(tài)編碼來對待,從而解決了無線網(wǎng)絡(luò)中的電路域數(shù)據(jù)業(yè)務(wù)在IP網(wǎng)絡(luò)上的數(shù)據(jù)可靠性問題,從而提高了數(shù)據(jù)傳輸?shù)臉I(yè)務(wù)成功率和業(yè)務(wù)質(zhì)量。
圖1為實(shí)施例IP核心網(wǎng)上所述協(xié)議棧的結(jié)構(gòu)示意圖;圖2為本發(fā)明冗余報(bào)文發(fā)送的實(shí)施流程示意圖;圖3為實(shí)施例中所述參照RTP視聽框架[3]所定義的數(shù)據(jù)包示意圖。
具體實(shí)施例方式
下面結(jié)合
本發(fā)明的具體實(shí)施方式
。
對于在IP網(wǎng)絡(luò)上傳送數(shù)據(jù)業(yè)務(wù)所出現(xiàn)質(zhì)量難以保證的情況,我們需要專門為IP網(wǎng)絡(luò)考慮一種改進(jìn)方式。本發(fā)明所考慮的是使用數(shù)據(jù)包冗余的方式來解決。由于在電路域方面,3GPP的分組化包括IP和ATM兩種方式,而3GPP2的分組化僅有一種全I(xiàn)P的方式。3GPP2的IP核心網(wǎng)中沒有UP協(xié)議,所以實(shí)際上兩個體系電路域的IP方式基本一致,因此解決在3GPP里面IP核心網(wǎng)上傳送Modem/Fax/UDI業(yè)務(wù)的方案也可以在3GPP2里面IP核心網(wǎng)里面使用。
在現(xiàn)有3GPP R4/5/6版本中,經(jīng)過IWF的傳輸,Modem信號以PCM方式編碼(G711)、64Kbit/s碼流帶寬傳輸,用戶面使用支持模式的UP協(xié)議,與固網(wǎng)里面的G711 5ms打包方式傳送Modem/Fax業(yè)務(wù)不同在于加了UP協(xié)議頭,因此我們可以通過擴(kuò)展RFC 2198協(xié)議,冗余帶UP協(xié)議頭的G711來保證業(yè)務(wù)在IP網(wǎng)絡(luò)中的正常運(yùn)行,也就是將G711帶UP協(xié)議頭作為一種動態(tài)編碼內(nèi)容來看待以達(dá)到傳輸目的。
在無線網(wǎng)絡(luò)中,電路域數(shù)據(jù)業(yè)務(wù)經(jīng)過IWF之后,以Modem/Fax或者UDI的64kbps PCM方式在IP網(wǎng)絡(luò)上傳送。對于Modem/Fax的64Kbps的PCM信號,其實(shí)際上是G711 a率或者u率編碼。對于UDI的64Kbps的PCM碼流,實(shí)際上是字節(jié)流,沒有a率、u率之分。圖1為IP核心網(wǎng)上協(xié)議棧的結(jié)構(gòu)示意圖,IP核心網(wǎng)上協(xié)議棧的結(jié)構(gòu)如圖所示,包括有G711 40字節(jié)的凈荷、UP協(xié)議頭的4字節(jié)、RTP協(xié)議頭、UDP協(xié)議頭、IP協(xié)議頭、以太網(wǎng)協(xié)議頭。
對于任何報(bào)文丟失,將會引起Modem/fax/UDI信號缺失,導(dǎo)致Modem/Fax/UDI重新協(xié)商或者降速,如果次數(shù)太多,將導(dǎo)致呼叫拆除,業(yè)務(wù)成功率降低。
在使用冗余機(jī)制后,在RTP層次使用RTP凈荷的冗余。因此將RTP協(xié)議層之上的內(nèi)容進(jìn)行冗余重復(fù)。報(bào)文格式如下RTP頭+2198頭(9B)+UP頭1+G711 40Bytes+UP頭2+G711 40bbytes+UP頭3+G711 40Bytes。
其中,UP協(xié)議頭指UP協(xié)議部分。
按UP協(xié)議規(guī)定方法使用UP頭1/2/3表示有3個報(bào)文的UP頭;在RTP頭里面攜帶冗余信息,冗余的個數(shù)由(MediaGateway Controller;媒體網(wǎng)關(guān)控制器)控制,在RTP頭里面指示,并且在載荷里面體現(xiàn)出來;UP頭1/2/3表示與之相應(yīng)的冗余包。
對于G711來說,有兩種凈荷類型a率、u率。但是在無線環(huán)境中,因?yàn)樵黾恿薝P協(xié)議層,所以G711帶UP協(xié)議頭時,就不能再使用G711的凈荷類型,而必須統(tǒng)一使用動態(tài)協(xié)商的凈荷類型。當(dāng)需要擴(kuò)展使用時,應(yīng)是控制面指定RTP凈荷類型,而無線環(huán)境中有兩種方式協(xié)商RTP凈荷類型,它可以使用IPBCP(IP Bearer Control Protocol;IP承載控制協(xié)議)協(xié)商和控制面指定。
對于冗余報(bào)文個數(shù)的控制可以采用很多方案進(jìn)行控制,一般分為MGC控制和MGW(Media Gateway;媒體網(wǎng)關(guān))自己控制或者配置。
對于控制冗余報(bào)文的方式,我們還可以使用全網(wǎng)配置的方法即認(rèn)為全網(wǎng)都是某個廠商的MGW,這樣發(fā)送報(bào)文格式雙方都可以識別處理。還可以使用身份探測方法即通過私有的方法識別對方是否是自己廠商的MGW,然后決定是否發(fā)送這種冗余報(bào)文。
下面描述使用MGC通過MGW與MGC之間的控制接口對冗余報(bào)文控制的具體實(shí)施方式
。
圖2為本發(fā)明冗余報(bào)文發(fā)送的實(shí)施流程示意圖,如圖所示,包括步驟201、MGC媒體網(wǎng)關(guān)控制器與MGW媒體網(wǎng)關(guān)協(xié)商連接報(bào)文凈荷類型;步驟202、MGW媒體網(wǎng)關(guān)向MGC媒體網(wǎng)關(guān)控制器發(fā)送攜帶所需凈荷類型的報(bào)文;步驟203、MGC媒體網(wǎng)關(guān)控制器按MGW媒體網(wǎng)關(guān)所需凈荷類型,將UP用戶平面協(xié)議頭冗余編碼進(jìn)所需凈荷類型發(fā)送至MGW媒體網(wǎng)關(guān)。
根據(jù)同樣原理,本發(fā)明還提供了數(shù)據(jù)冗余發(fā)送系統(tǒng)的實(shí)施方式,本系統(tǒng)在3GPP網(wǎng)絡(luò)中包括媒體網(wǎng)關(guān)控制器、媒體網(wǎng)關(guān),還包括數(shù)據(jù)冗余編碼模塊,用于在MGC媒體網(wǎng)關(guān)控制器與MGW媒體網(wǎng)關(guān)協(xié)商確定基于RFC G711協(xié)議的連接報(bào)文凈荷類型后,將UP用戶平面協(xié)議頭冗余編碼進(jìn)所需凈荷類型,由MGC媒體網(wǎng)關(guān)控制器發(fā)送至MGW媒體網(wǎng)關(guān)。
本實(shí)施例中,以IPBCP方式來確定的凈荷類型進(jìn)行描述。
對于使用IPBCP的方式下,以下實(shí)施例使用SDP協(xié)議描述為例以說明具體的實(shí)施。
m=audio $RTP/AVP$a=rtpmap$VND.3GPP.IUFP/16000/1a=Ptime5其含義為媒體通告=媒體格式(音頻)端口號(由媒體網(wǎng)改選擇端口)傳輸協(xié)議(RTP/AVP)媒體格式(由媒體網(wǎng)關(guān)選擇);RTP/AVP-IETF的使用音頻/視頻描述的在UDP上承載的實(shí)時傳輸協(xié)議媒體格式-是在RTP/AVP里面定義的凈荷類型(payload type);屬性=RTP映射屬性凈荷類型(由網(wǎng)關(guān)選擇)編碼類型/時鐘頻率/編碼參數(shù);rtpmap-rtp的映射屬性 VND.3GPP.IUFP是3GPP里面使用的一種編碼類型。1600是時鐘頻率,且是單聲道的。
屬性=打包時間時長其中“m=”字段中定義的附加負(fù)載格式本身也可能是動態(tài)負(fù)載類型,而一旦如此,就需要一些附加屬性“a=”來描述這些動態(tài)負(fù)載類型。
要發(fā)送一個冗余流,發(fā)送方得知道建議使用的主編碼和第二編碼。該信息對于冗余格式是明確的,并通過使用附加屬性“fmtp”來指定,該屬性傳達(dá)了格式特定的信息。一個會話目錄并不解析fmtp屬性的值,而僅僅是將它轉(zhuǎn)交。為了冗余性,我們定義了RTP負(fù)載格式的格式參數(shù)列表,通過斜線“/”分隔開。
這該RTP數(shù)據(jù)包,參照RTP視聽框架[3]所定義,則可如圖3所示。圖3為參照RTP視聽框架[3]所定義的數(shù)據(jù)包圖。
當(dāng)發(fā)送后,則MGW回應(yīng)為m=audio 5432 RTP/AVP 100a=rtpmap100 VND.3GPP.IUFP/16000/1a=Ptime5MGW選擇好UDP端口號,以及RTP映射屬性里面的凈荷類型返回給MGC。
MGC在后續(xù)下發(fā)給MGW的消息中以MGW選擇好的內(nèi)容下發(fā),同時攜帶上相應(yīng)的冗余編解碼類型。
m=audio 5432 RTP/AVP 100 121a=rtpmap100 VND.3GPP.IUFP/16000/1a=Ptime5a=rtpmap121 red/16000/1(冗余編解碼類型的描述)a=fmtp121 100/100/100(冗余方式的描述)其中,“rtpmap”屬性用于將負(fù)載類型121綁定到編解碼器“red”,表示該編解碼器是一個冗余幀,采樣率16KHz,且是單聲道的。當(dāng)與SDP一同使用時,術(shù)語“red”表示本文中所討論的冗余格式。
對于不使用IPBCP方式的實(shí)施則為m=audio $RTP/AVP 121 100a=rtpmap100 VND.3 GPP.IUFP/16000/1a=Ptime5a=rtpmap121 red/16000/1a=fmtp121 100/100/100這時MGC直接通知MGW使用冗余編解碼方式,并下發(fā)冗余編解碼的凈荷類型和冗余方式信息即可。
顯然,本領(lǐng)域的技術(shù)人員可以對本發(fā)明進(jìn)行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣,倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi),則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
權(quán)利要求
1.一種數(shù)據(jù)冗余發(fā)送方法,其特征在于,包括如下步驟A、媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)協(xié)商連接報(bào)文凈荷類型;B、媒體網(wǎng)關(guān)向媒體網(wǎng)關(guān)控制器發(fā)送攜帶所需凈荷類型的報(bào)文;C、媒體網(wǎng)關(guān)控制器按媒體網(wǎng)關(guān)所需凈荷類型,將UP用戶平面協(xié)議頭冗余編碼所需凈荷類型發(fā)送至媒體網(wǎng)關(guān)。
2.如權(quán)利要求1所述的方法,其特征在于,步驟A中所述媒體網(wǎng)關(guān)控制器實(shí)時與媒體網(wǎng)關(guān)協(xié)商連接報(bào)文凈荷類型。
3.如權(quán)利要求1所述的方法,其特征在于,步驟A中所述報(bào)文為ITU G711編碼方案的報(bào)文。
4.如權(quán)利要求1所述的方法,其特征在于,步驟B中所述媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)是通過IP承載控制協(xié)議協(xié)商的。
5.如權(quán)利要求1所述的方法,其特征在于,步驟B中所述媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)是通過控制面協(xié)商的。
6.如權(quán)利要求1所述的方法,其特征在于,步驟C中所述冗余編碼是在實(shí)時傳輸協(xié)議層上進(jìn)行的。
7.如權(quán)利要求1所述的方法,其特征在于,步驟C中所述UP用戶平面協(xié)議頭冗余個數(shù),由信令面通過相應(yīng)的網(wǎng)絡(luò)服務(wù)質(zhì)量指標(biāo)確定。
8.如權(quán)利要求7所述的方法,其特征在于,所述冗余個數(shù)為2個或3個。
9.一種數(shù)據(jù)冗余發(fā)送系統(tǒng),包括媒體網(wǎng)關(guān)控制器、媒體網(wǎng)關(guān),其特征在于,還包括數(shù)據(jù)冗余編碼模塊,用于在媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)協(xié)商確定基于ITUG711協(xié)議的連接報(bào)文凈荷類型后,將UP用戶平面協(xié)議頭冗余編碼進(jìn)所需凈荷類型,由媒體網(wǎng)關(guān)控制器發(fā)送至媒體網(wǎng)關(guān)。
10.如權(quán)利要求9所述的系統(tǒng),其特征在于,所述數(shù)據(jù)冗余編碼模塊,位于媒體網(wǎng)關(guān)控制器。
全文摘要
本發(fā)明公開了一種3GPP網(wǎng)絡(luò)中數(shù)據(jù)冗余發(fā)送方法及系統(tǒng),是在媒體網(wǎng)關(guān)控制器與媒體網(wǎng)關(guān)協(xié)商確定基于ITU G711協(xié)議的連接報(bào)文凈荷類型后,將UP用戶平面協(xié)議頭冗余編碼進(jìn)所需凈荷類型,由媒體網(wǎng)關(guān)控制器發(fā)送至媒體網(wǎng)關(guān)。使用本發(fā)明解決了無線網(wǎng)絡(luò)中的電路域數(shù)據(jù)業(yè)務(wù)在IP網(wǎng)絡(luò)上的數(shù)據(jù)可靠性問題,從而提高了數(shù)據(jù)傳輸?shù)臉I(yè)務(wù)成功率和業(yè)務(wù)質(zhì)量。
文檔編號H04L12/56GK101047604SQ200610078380
公開日2007年10月3日 申請日期2006年5月17日 優(yōu)先權(quán)日2006年5月17日
發(fā)明者李琥 申請人:華為技術(shù)有限公司