專利名稱：消息傳輸方法及裝置的制作方法
技術(shù)領域：
本發(fā)明涉及通信領域，具體而言，涉及一種消息傳輸方法及裝置。
背景技術(shù)：
移動全球互操作性微波接入(WiMAX,Worldwide Interoperability forMicrowave Access)網(wǎng)絡的體系結(jié)構(gòu)至少包括移動用戶終端(MSS, Mobile ServiceSubscribe)、BS (BS, Base Station)、接入網(wǎng)關(guān)(ASN-GW, ASN Access Gateway)、核心網(wǎng)(CSN, Connection Service Network)和應用服務提供商(ASP, Application ServiceProvider)網(wǎng)絡。其中，MSS為移動用戶設備，用戶使用該設備接入WiMAX網(wǎng)絡。BS處理空口(Rl接口)和與ASN-GW之間的R6接口數(shù)據(jù)。AGW處理與BS之間的R6接口數(shù)據(jù)和與CSN之間的數(shù)據(jù)。BS和ASN-GW都是ASN的組成部分，CSN由路由器、認證、授權(quán)、計費(AAA，Authentication、Authorization、Accounting)服務器、動態(tài)主機分配協(xié)議(DHCP, DynamicHost Configuration Protocol)服務器、用戶數(shù)據(jù)庫、因特網(wǎng)網(wǎng)關(guān)設備等組成，為WiMAX用 戶提供IP連接，并通過以太網(wǎng)連接到ASP上。ASP包含各種應用服務器，為WiMAX用戶提供上層應用服務，如文件傳輸協(xié)議(FTP, File Transfer Protocol)服務、超級文本傳輸協(xié)議(HTTP, Hyper Text Transfer Protocol)月艮務和 Email (電子郵件)服務等。根據(jù)WiMAX論壇技術(shù)工作組(TWG, Technical Work Group)頒布的最新空口802. 16e標準和網(wǎng)絡工作組(NWG，Network Work Group)頒布的最新網(wǎng)絡架構(gòu)標準，MSS要完成整個網(wǎng)絡接入流程(Initial Network Entry)流程,在完成與BS的物理鏈路同步、獲得上下行信道參數(shù)、Initial Ranging(初始測距)基本能力協(xié)商之后，需要進行鑒權(quán)過程，驗證正在嘗試接入的是否為合法用戶。現(xiàn)有的鑒權(quán)實現(xiàn)流程包含以下步驟步驟一、AGW發(fā)送鑒權(quán)消息AR_EAP_Transfer消息給基站發(fā)起鑒權(quán)流程；步驟二、基站將AR_EAP_Transfer消息中的鑒權(quán)請求作為載荷通過鑒權(quán)消息PKMv2-RSP/EAP-Transfer消息傳送給移動終端；步驟三、終端將網(wǎng)絡接入標識符(NAI, Network Access Identifier)信息通過PKMv2-REQ/EAP-Transfer 消息發(fā)送給基站；步驟四、基站將MSS發(fā)送的消息內(nèi)容通過AR_EAP_Transf er消息傳遞給AGW ；步驟五、AGW將基站發(fā)送過來的EAP消息內(nèi)容作為載荷通過Radius消息透傳給AAA服務器；步驟六、接下來在MSS與AAA之間進行一系列的信息交互，主要是挑戰(zhàn)、應答消息的交互；步驟七、鑒權(quán)結(jié)束之后，鑒權(quán)結(jié)果由AAA服務器通過AGW、BS傳送給MSS?，F(xiàn)在實現(xiàn)的R6 口與R3之間鑒權(quán)消息的發(fā)送，均使用用戶數(shù)據(jù)報協(xié)議(UDP，UserDatagram Protocol)連接進行的,但是UDP是非面向連接的協(xié)議,在網(wǎng)絡狀況不佳的情況下，難以保證發(fā)送消息的準確性。也正因此，目前現(xiàn)有實現(xiàn)的鑒權(quán)消息發(fā)送方法或流程有以下問題如果鑒權(quán)過程中BS與AGW之間接口即R6 口的消息長度大于網(wǎng)絡的最大傳輸單元(MTU,Maximum Transmission Unit)值，或者AGW與AAA服務器之間接口即R3 口的某個消息的長度大于網(wǎng)絡的MTU，消息通過R6、R3時，均使用UDP進行傳輸，此時UDP包傳送到IP層時，IP協(xié)議會對該長度大于MTU的數(shù)據(jù)包進行分片，這樣一來，增加了丟包的可能性，并且UDP不具備自動重傳的功能，會導致鑒權(quán)成功率低。鑒權(quán)過程中，如果與AGW交互的AAA服務器僅僅是作為代理Proxy服務器，那么MSS反饋的消息還需要通過該Proxy AAA服務器使用Radius協(xié)議傳輸?shù)秸嬲腁AA服務器，AAA服務器發(fā)送的消息也需要通過該路徑發(fā)送給MS，Radius協(xié)議在傳輸消息的時候使用的是UDP協(xié)議，也是不可靠傳輸，在消息長度較大，網(wǎng)絡跳數(shù)較大的情況下，鑒權(quán)成功率較低。針對相關(guān)技術(shù)中采用UDP連接鑒權(quán)流程會導致鑒權(quán)成功率較低的問題，目前尚未 提出有效的解決方案。

發(fā)明內(nèi)容
鑒于相關(guān)技術(shù)存在的采用UDP連接鑒權(quán)流程會導致鑒權(quán)成功率較低的問題，本發(fā)明提供一種消息傳輸方法及裝置。根據(jù)本發(fā)明的一個方面，提供了一種消息傳輸方法，包括判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP Message MTU ;若是，采用傳輸控制協(xié)議TCP傳輸方式傳輸所述待傳輸?shù)南?。?yōu)選的，判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP Message MTU之后，還包括若否，則采用用戶數(shù)據(jù)報協(xié)議UDP傳輸方式傳輸所述待傳輸?shù)南ⅰ?yōu)選的，當所述待傳輸?shù)南榛綛S發(fā)送至接入網(wǎng)關(guān)AGW的傳輸消息AR_EAP_Transfer消息時，所述EAP Message MTU設置在所述BS中；當所述待傳輸?shù)南樗鯝GW發(fā)送的請求消息Access-Request消息或者所述AGW發(fā)送至所述BS的AR_EAP_Transfer消息時，所述EAP Message MTU設置在所述AGW中；當所述待傳輸?shù)南檎J證、授權(quán)、計費AAA服務器發(fā)送的搶占消息Access-Challenge消息或者接受消息Access-Accept消息時，所述EAP Message MTU設置在所述AAA中。優(yōu)選的，所述EAP Message MTU 為 1500。優(yōu)選的，所述方法應用于移動用戶終端MSS接入網(wǎng)絡的鑒權(quán)流程。優(yōu)選的，所述米用TCP傳輸方式傳輸所述待傳輸?shù)南?包括確定所述待傳輸?shù)南⒌陌l(fā)送方與接收方之間是否存在TCP連接；若否，則建立所述TCP連接，采用所述TCP傳輸方式傳輸所述待傳輸?shù)南?；若是，則米用所述TCP傳輸方式傳輸所述待傳輸?shù)南ⅰ?yōu)選的，建立所述TCP連接之后，還包括在鑒權(quán)成功結(jié)束或者失敗之后，所述TCP連接繼續(xù)保留預設時長。優(yōu)選的，建立所述TCP連接之后，還包括若所述預設時長內(nèi)，不存在通過所述TCP連接發(fā)送的消息，則刪除所述TCP連接。優(yōu)選的，所述預設時長為5秒。根據(jù)本發(fā)明的另一方面，提供了一種消息傳輸裝置，包括判斷模塊，用于判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP Message MTU ;第一傳輸模塊，用于在所述判斷模塊判斷結(jié)果為是時，采用傳輸控制協(xié)議TCP傳輸方式傳輸所述待傳輸?shù)南?。?yōu)選的，消息傳輸裝置還包括第二傳輸模塊，用于在所述判斷模塊判斷結(jié)果為否時，米用用戶數(shù)據(jù)報協(xié)議UDP傳輸方式傳輸所述待傳輸?shù)南?。在本發(fā)明實施例中，判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAPMessage MTU,若是,米用傳輸控制協(xié)議TCP傳輸方式傳輸待傳輸?shù)南?。即，在本發(fā)明實施例中添加了一個參數(shù)EAP Message MTU，作為鑒權(quán)消息是否使用TCP連接進行傳輸?shù)慕缦拗?。對于長度大于MTU的待傳輸消息，在被傳送到IP層時，IP協(xié)議不需要對該數(shù)據(jù)包進行分片，降低了丟包的可能性，提高鑒權(quán)成功率；并且，鑒權(quán)過程中，如果與AGW交互的AAA服務器僅僅是作為代理Proxy服務器，那么MSS反饋的消息還需要通過該Proxy AAA服務器使用Radius協(xié)議傳輸?shù)秸嬲腁AA服務器，AAA服務器發(fā)送的消息也需要通過該路徑發(fā)送給MSS，Radius協(xié)議在傳輸消息的時候使用的是TCP協(xié)議，是可靠傳輸，在消息長度較大，網(wǎng)絡跳數(shù)較大的情況下，相對于Μ)Ρ連接能夠提高鑒權(quán)成功率。


此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當限定。在附圖中圖I是根據(jù)本發(fā)明實施例的消息傳輸方法的處理流程圖；圖2是根據(jù)本發(fā)明實施例的在BS側(cè)增加EAP Message MTU的處理流程圖；圖3是根據(jù)本發(fā)明實施例的在AGW側(cè)增加EAP Message MTU的處理流程圖；圖4是根據(jù)本發(fā)明實施例的在AAA服務器端增加EAP Message MTU的處理流程圖；圖5是根據(jù)本發(fā)明實施例的三個新增模塊的連接關(guān)系示意圖；圖6是根據(jù)本發(fā)明實施例的消息傳輸裝置的第一種結(jié)構(gòu)示意圖；圖7是根據(jù)本發(fā)明實施例的消息傳輸裝置的第二種結(jié)構(gòu)示意圖。
具體實施例方式下文中將參考附圖并結(jié)合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合?，F(xiàn)在實現(xiàn)的R6 口與R3之間鑒權(quán)消息的發(fā)送，均使用UDP連接進行的，但是UDP是非面向連接的協(xié)議，在網(wǎng)絡狀況不佳的情況下，難以保證發(fā)送消息的準確性，鑒權(quán)成功率較低。雖然在AGW、AAA服務器中，針對UDP的弱點，為該UDP傳輸添加丟包判斷、超時重發(fā)的功能，BS、AGW、AAA服務器均自身具有消息的超時重發(fā)功能，但是，在消息體長度較大時，這種機制無法從根本上解決丟包率高的問題。為解決上述技術(shù)問題，本發(fā)明實施例提供了一種消息傳輸方法，其處理流程如圖I所示，包括步驟S102、判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP MessageMTU ；
步驟S104、若是,米用傳輸控制協(xié)議TCP傳輸方式傳輸待傳輸?shù)南?。在本發(fā)明實施例中，判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAPMessage MTU,若是,米用傳輸控制協(xié)議TCP傳輸方式傳輸待傳輸?shù)南?。即，在本發(fā)明實施例中添加了一個參數(shù)EAP Message MTU，作為鑒權(quán)消息是否使用TCP連接進行傳輸?shù)慕缦拗?。對于長度大于MTU的待傳輸消息，在被傳送到IP層時，IP協(xié)議不需要對該數(shù)據(jù)包進行分片，降低了丟包的可能性，提高鑒權(quán)成功率；并且，鑒權(quán)過程中，如果與AGW交互的AAA服務器僅僅是作為代理Proxy服務器，那么MSS反饋的消息還需要通過該Proxy AAA服務器使用Radius協(xié)議傳輸?shù)秸嬲腁AA服務器，AAA服務器發(fā)送的消息也需要通過該路徑發(fā)送給MSS，Radius協(xié)議在傳輸消息的時候使用的是TCP協(xié)議，是可靠傳輸，在消息長度較大，網(wǎng)絡跳數(shù)較大的情況下，相對于Μ)Ρ連接能夠提高鑒權(quán)成功率。當然,若判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP Message MTU之后，判斷結(jié)果為否，則仍然采用用戶數(shù)據(jù)報協(xié)議UDP傳輸方式傳輸待傳輸?shù)南ⅰ?
根據(jù)待傳輸消息的類型及傳輸方向不同，EAP Message MTU可以相應存儲在不同的服務器或設備中，例如，當待傳輸?shù)南榛綛S發(fā)送至接入網(wǎng)關(guān)AGW的傳輸消息AR_EAP_Transfer 消息時，EAP Message MTU 設置在 BS 中；當待傳輸?shù)南锳GW發(fā)送的請求消息Access-Request消息或者AGW發(fā)送至BS的 AR_EAP_Transfer 消息時，EAP Message MTU 設置在 AGW 中；當待傳輸?shù)南檎J證、授權(quán)、計費AAA服務器發(fā)送的搶占消息Access-Challenge 消息或者接受消息 Access-Accept 消息時，EAP Message MTU 設置在 AAA中。EAP Message MTU設置在何種實體中，取決于發(fā)送消息的實體，S卩，在發(fā)送消息的實體中設置EAP Message MTU，并進行相關(guān)判斷。EAP Message MTU 為 1500。本發(fā)明實施例提供的消息傳輸方法可以應用于移動用戶終端MSS接入網(wǎng)絡的鑒權(quán)流程，提高鑒權(quán)流程的準確性。當將本發(fā)明實施例提供的消息傳輸方法應用于鑒權(quán)流程中時，采用TCP傳輸方式傳輸待傳輸?shù)南?，包括如下流程步驟一、確定待傳輸?shù)南⒌陌l(fā)送方與接收方之間是否存在TCP連接；步驟二、若否，則建立TCP連接，采用TCP傳輸方式傳輸待傳輸?shù)南?；步驟三、若是，則米用TCP傳輸方式傳輸待傳輸?shù)南ⅰ卩，若當前不存在TCP連接的情況下，需要先建立TCP連接，若已存在TCP連接，則只需要利用已有的TCP連接傳輸待傳輸?shù)南?。建立TCP連接之后，優(yōu)選的，在鑒權(quán)成功結(jié)束或者失敗之后，TCP連接繼續(xù)保留預設時長。建立TCP連接之后，優(yōu)選的，若預設時長內(nèi)，不存在通過TCP連接發(fā)送的消息，則刪除TCP連接。通常，預設時長可以根據(jù)實際情況設定，優(yōu)選的，可以將預設時長設置為5秒?，F(xiàn)以具體實施例對本發(fā)明實施例提供的消息傳輸方法進行說明。實施例一
本發(fā)明實施例提供了一種鑒權(quán)過程中BS、AGW、AAA服務器之間交互消息體較長情況下的鑒權(quán)消息發(fā)送方法，既不能影響較短消息的傳送又能保證較長消息的可靠傳送，包括以下方面R6 口消息AR_EAP_Transfer，比如方向是BS- > AGff,則在BS中需要確認封裝后的消息是否較長，來判斷是否使用TCP連接來傳送該消息，是否較長的判斷是根據(jù)MTU來確定的，該值需要能在后臺設置，比如該值設為1000，如果AR_EAP_Transfer消息的載荷長度+UDP頭長度+IP頭長度之和超過該值，則需要采用TCP傳輸。并在BS與AGW之間建立一條TCP通道，將該消息通過該連接傳輸。對于Access-Challenge、Access-Request 消息，計算消息載荷封裝為 Radius 消息后的長度，如果該值大于MTU值，則在AGW與AAA服務器或者AAA Proxy之間建立Tcp連接，將該消息通過TCP進行傳輸。R6 口或R3 口的TCP連接一旦建立，在鑒權(quán)過程中該連接將一直存在，在需要的時候傳遞相應消息，直到鑒權(quán)成功結(jié)束或者失敗之后，該連接繼續(xù)保留5秒鐘的時間，如果5 秒之內(nèi)，沒有通過該連接發(fā)送的消息，則依次刪除R3 口、R6 口的TCP連接，這樣有助于減少AGW, AAA需要維護的TCP連接數(shù)量，并能保證這樣的連接不需要過于頻繁的建立。這種方式還有如下特點，目前多數(shù)網(wǎng)絡設備的MTU值為1500，當給基站或者AGW、AAA 服務器設置的米用 TCP 傳送 AR_EAP_Transfer、Access_Challenge、Access-Request 消息的長度門限大于1500時，倘若這三個消息封裝后的長度沒有超過該值，則他們的傳送仍然使用現(xiàn)有的方式，即使用UDP傳送。若某個或某幾個消息超過了該值，則該消息使用Tcp連接進行傳輸。綜合來看，保證了傳送的準確性。實施例二基站、AGW、AAA服務器的后臺網(wǎng)管部分，添加一個參數(shù)EAP Message MTU，作為鑒權(quán)消息是否使用TCP連接進行傳輸?shù)慕缦拗?。在基站前臺軟件添加一個鑒權(quán)的消息比較、分類以及通道建立的模塊，它的主要作用如圖2所示步驟S202、對 BS 與 AGW 之間交互的 AR_EAP_Transfer 消息與 EAP Message MTU 進行比較，確定是否大于EAP Message MTU，若是，執(zhí)行步驟S204，若否，執(zhí)行步驟S210 ;步驟S204、如果消息的長度值更大，該模塊檢查是否已經(jīng)存在到AGW之間的TCP連接，若是，執(zhí)行步驟S208，若否，執(zhí)行步驟S206及S208 ；步驟S206、如果沒有，則BS通過該模塊主動發(fā)起到AGW的TCP連接，即BS作為客戶端，AGff作為服務端；步驟S208、利用TCP連接發(fā)送消息；步驟S210、如果消息的長度較EAP Message MTU的值小，則該模塊將鑒權(quán)消息發(fā)送到原來的消息傳送通道進行傳輸，即使用UDP通道進行傳輸。在AGW中增加一個負責鑒權(quán)相關(guān)消息的比較、分類以及通道建立的模塊，它的主要功能如圖3所示,包括步驟S302、對需要發(fā)送到BS的AR_EAP_Transfer消息、發(fā)送到AAA的Access-Request消息的長度與EAP Message MTU進行比較,確定是否大于EAP MessageMTU,如果是，則執(zhí)行步驟S04，如果否，則執(zhí)行步驟S310 ；
步驟S304、如果消息長度較該值大，則AGW檢查是否存在BS、AAA服務器的TCP連接，如果是，則執(zhí)行步驟S308，如果否，則執(zhí)行步驟S306及S308 ；步驟S306、如果不存在則建立；步驟S308、將該消息通過該TCP通道進行傳輸；步驟S310、如果消息的長度較 EAP Message MTU 值小，則 AR_EAP_Transfer、Access-Request消息使用原來的即UDP方式進行傳輸。同樣的，在AAA服務器端，需要增加負責Access-Challenge、Access-Accept消息的比較、分類、建立傳輸通道的模塊，它的主要功能如圖4所示，包括步驟S402、對 Access_Challenge、Access_Accept 消息的長度與 EAP Message MTU進行比較，確定是否大于EAP Message MTU，如果是，則執(zhí)行步驟S404，如果否，則執(zhí)行步驟S410 ； 步驟S404、如果消息體的長度較EAP Message MTU大，則該模塊檢查AAA服務器與AGW之間是否已經(jīng)存在傳輸鑒權(quán)消息的TCP連接，如果是，則執(zhí)行步驟S408，如果否，則執(zhí)行步驟S406及S408 ；步驟S406、如果不存在則建立一條；步驟S408、通過該連接傳送Access消息；步驟S410、反之,則通過UDP方式傳送該消息。此外，如果AAA服務器僅作為Proxy，那么，AAA服務器還需要判斷將要進行轉(zhuǎn)發(fā)的Access-Request消息長度是否較EAP Message MTU大,如果是,則檢查是否存在到實際AAA服務器間的TCP連接,不存在則建立一條，并使用該連接轉(zhuǎn)發(fā)Access-Request消息。需要注意的是，在BS、AGW、AAA服務器中添加的負責比較、分類、通道建立的模塊，均可以接受、發(fā)起連接，這樣可以避免不能同時收發(fā)的問題，三個模塊之間的連接關(guān)系如圖5所示。在多個MSS同時發(fā)起初始接入的情況下，后面MSS的鑒權(quán)消息可以使用前面建立的TCP連接來傳送長度較EAP Message MTU大的消息?；谕话l(fā)明構(gòu)思，本發(fā)明實施例還提供了一種消息傳輸裝置，其結(jié)構(gòu)示意圖如圖6所示,包括判斷模塊601，用于判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAPMessage MTU ；第一傳輸模塊602，與判斷模塊601相連，用于在判斷模塊601判斷結(jié)果為是時，采用傳輸控制協(xié)議TCP傳輸方式傳輸待傳輸?shù)南?。在一個實施例中，優(yōu)選的，如圖7所不,消息傳輸裝置還可以包括第二傳輸模塊701，與判斷模塊601相連，用于在判斷模塊601判斷結(jié)果為否時，采用用戶數(shù)據(jù)報協(xié)議UDP傳輸方式傳輸待傳輸?shù)南?。從以上的描述中，可以看出，本發(fā)明實現(xiàn)了如下技術(shù)效果在本發(fā)明實施例中，判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAPMessage MTU,若是,米用傳輸控制協(xié)議TCP傳輸方式傳輸待傳輸?shù)南?。即，在本發(fā)明實施例中添加了一個參數(shù)EAP Message MTU，作為鑒權(quán)消息是否使用TCP連接進行傳輸?shù)慕缦拗?。對于長度大于MTU的待傳輸消息，在被傳送到IP層時，IP協(xié)議不需要對該數(shù)據(jù)包進行分片，降低了丟包的可能性，提高鑒權(quán)成功率；并且，鑒權(quán)過程中，如果與AGW交互的AAA服務器僅僅是作為代理Proxy服務器，那么MSS反饋的消息還需要通過該Proxy AAA服務器使用Radius協(xié)議傳輸?shù)秸嬲腁AA服務器，AAA服務器發(fā)送的消息也需要通過該路徑發(fā)送給MSS，Radius協(xié)議在傳輸消息的時候使用的是TCP協(xié)議，是可靠傳輸，在消息長度較大，網(wǎng)絡跳數(shù)較大的情況下，相對于Μ)Ρ連接能夠提高鑒權(quán)成功率。顯然，本領域的技術(shù)人員應該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。
以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1.一種消息傳輸方法,其特征在于,包括 判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP Message MTU； 若是，采用傳輸控制協(xié)議TCP傳輸方式傳輸所述待傳輸?shù)南ⅰ?br> 2.根據(jù)權(quán)利要求I所述的方法，其特征在于，判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP Message MTU之后，還包括若否，則采用用戶數(shù)據(jù)報協(xié)議UDP傳輸方式傳輸所述待傳輸?shù)南ⅰ?br> 3.根據(jù)權(quán)利要求I所述的方法，其特征在于，當所述待傳輸?shù)南榛綛S發(fā)送至接入網(wǎng)關(guān)AGW的傳輸消息AR_EAP_Transfer消息時，所述EAP Message MTU設置在所述BS中； 當所述待傳輸?shù)南樗鯝GW發(fā)送的請求消息Access-Request消息或者所述AGW發(fā)送至所述BS的AR_EAP_Transfer消息時，所述EAP Message MTU設置在所述AGW中；當所述待傳輸?shù)南檎J證、授權(quán)、計費AAA服務器發(fā)送的搶占消息Access-Challenge消息或者接受消息Access-Accept消息時,所述EAP Message MTU設置在所述AAA中。
4.根據(jù)權(quán)利要求1-3任一項所述的方法，其特征在于，所述EAPMessage MTU為1500。
5.根據(jù)權(quán)利要求1-3任一項所述的方法，其特征在于，所述方法應用于移動用戶終端MSS接入網(wǎng)絡的鑒權(quán)流程。
6.根據(jù)權(quán)利要求5所述的方法,其特征在于,所述米用TCP傳輸方式傳輸所述待傳輸?shù)南ⅲ? 確定所述待傳輸?shù)南⒌陌l(fā)送方與接收方之間是否存在TCP連接； 若否，則建立所述TCP連接，采用所述TCP傳輸方式傳輸所述待傳輸?shù)南ⅲ? 若是，則采用所述TCP傳輸方式傳輸所述待傳輸?shù)南ⅰ?br> 7.根據(jù)權(quán)利要求6所述的方法，其特征在于，建立所述TCP連接之后，還包括 在鑒權(quán)成功結(jié)束或者失敗之后，所述TCP連接繼續(xù)保留預設時長。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于，建立所述TCP連接之后，還包括 若所述預設時長內(nèi)，不存在通過所述TCP連接發(fā)送的消息，則刪除所述TCP連接。
9.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述預設時長為5秒。
10.一種消息傳輸裝置，其特征在于，包括 判斷模塊，用于判斷待傳輸?shù)南⒌拈L度是否大于預設的傳輸界限值EAP MessageMTU ； 第一傳輸模塊，用于在所述判斷模塊判斷結(jié)果為是時，采用傳輸控制協(xié)議TCP傳輸方式傳輸所述待傳輸?shù)南ⅰ?br> 11.根據(jù)權(quán)利要求10所述的裝置，其特征在于，還包括第二傳輸模塊，用于在所述判斷模塊判斷結(jié)果為否時，采用用戶數(shù)據(jù)報協(xié)議UDP傳輸方式傳輸所述待傳輸?shù)南ⅰ?br> 全文摘要
本發(fā)明公開了一種消息傳輸方法及裝置，該方法包括判斷待傳輸?shù)南⒌拈L度是否大于預設的EAP Message MTU；若是，采用TCP傳輸方式傳輸待傳輸?shù)南?。采用本發(fā)明能夠解決相關(guān)技術(shù)存在的采用UDP連接鑒權(quán)流程會導致鑒權(quán)成功率較低的問題。
文檔編號H04W12/06GK102833750SQ20111016263
公開日2012年12月19日 申請日期2011年6月16日 優(yōu)先權(quán)日2011年6月16日
發(fā)明者張廷全 申請人:中興通訊股份有限公司