專利名稱：數(shù)據(jù)傳輸方法、網(wǎng)元設備及通信系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及無線通信技木，尤其涉及ー種數(shù)據(jù)傳輸方法、網(wǎng)元設備及通信系統(tǒng)。
背景技術：
IPv6 (Internet Protocol Version 6,第六版互聯(lián)網(wǎng)協(xié)議)技術已日漸成熟，應用也越來越多。同時，由于可分配的IPv4 (Internet Protocol Version 4,第四版互聯(lián)網(wǎng)協(xié)議)地址日益緊張，移動寬帶網(wǎng)絡支持向IPv6的演進勢在必行。當移動寬帶網(wǎng)絡的PS(Packet Switch,分組交換)域核心網(wǎng)演進到IPv6之后，例如SGSN (Serving GPRS Support Node,業(yè)務通用分組無線服務技術支持節(jié)點)與S-Gff (Serving Gateway,服務網(wǎng)關)之間的數(shù)據(jù)傳輸接 ロ、MME(Mobility ManagementEntity,移動性管理實體)與SGSN之間的數(shù)據(jù)傳輸接ロ、S-GW與RNC (Radio NetworkController,無線網(wǎng)絡控制器)之間的數(shù)據(jù)傳輸接ロ、S-GW與eNodeB (Evolved Node B,演 進型基站)之間的數(shù)據(jù)傳輸接ロ等都支持IPv6傳輸之后，GTP(GPRSTunneling Protocol,通用分組無線服務技術隧道協(xié)議)就要承載在IPv6的UDP(User Datagram Protocol,用戶數(shù)據(jù)報協(xié)議)之上，所有的控制面和用戶面上的GTP報文都必須計算校驗和。而UDP的校驗和計算包括M)P頭的校驗和計算和UDP負荷的校驗和計算。UDP的校驗和由發(fā)送端計算，然后由接收端驗證，如果接收端檢測到校驗和有差錯，GTP報文就要被丟棄。在某些情況下，丟掉這個包的代價是非常大的，尤其是那些包比較大的語音或視頻等業(yè)務。而對于語音或視頻等對錯包容忍度比較好的業(yè)務進行上述UDP的校驗和計算，會顯著降低數(shù)據(jù)傳輸?shù)男省?br>
發(fā)明內(nèi)容
本發(fā)明的多個方面提供ー種數(shù)據(jù)傳輸方法，用以提高數(shù)據(jù)傳輸?shù)男?。本發(fā)明的第一個方面，提供ー種數(shù)據(jù)傳輸方法，包括接收發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)量參數(shù)；根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述發(fā)送端返回攜帯有判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。如上所述的數(shù)據(jù)傳輸方法，所述根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，包括獲取第一閾值和第二閾值；判斷所述PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。
本發(fā)明的第二個方面，提供ー種數(shù)據(jù)傳輸方法，包括向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)
量參數(shù)；接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷PDP上下文對應的承載的用戶面隧道是否能通過 UDP-Lite協(xié)議進行封裝的結果；若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。如上所述的數(shù)據(jù)傳輸方法，所述通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝，具體為通過UDP-Lite協(xié)議將所述PDP上下文對應的承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本發(fā)明的第三個方面，提供ー種數(shù)據(jù)傳輸方法，包括接收發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯所述承載的服務質(zhì)量參數(shù)；根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述發(fā)送端返回攜帯有判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的數(shù)據(jù)傳輸方法，所述根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，包括獲取第一閾值和第二閾值；判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于第一閾值且丟包容忍度是否大于第二閾值，若均是，所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。本發(fā)明的第四個方面，提供ー種數(shù)據(jù)傳輸方法，包括向接收端發(fā)送承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述承載的服務質(zhì)量參數(shù)；接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果；若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的數(shù)據(jù)傳輸方法，所述通過UDP-Lite協(xié)議對所述承載進行封裝，具體為通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本發(fā)明的第五個方面，提供ー種數(shù)據(jù)傳輸方法，包括
創(chuàng)建或更新承載，井根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝；向所述接收端發(fā)送攜帯有判斷結果信息的指令消息，以使所述接收端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的數(shù)據(jù)傳輸方法，所述根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，包括獲取第一閾值和第二閾值；判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于第一閾值且丟包容忍度是否大于第二閾值，若均是，所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。 本發(fā)明的第六個方面，提供ー種數(shù)據(jù)傳輸方法，包括接收發(fā)送端發(fā)送的指令信息，所述指令信息攜帯有判斷結果信息，所述判斷結果信息為所述發(fā)送端根據(jù)創(chuàng)建或更新的承載的服務質(zhì)量參數(shù)，判斷出所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果；若所述指令信息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的數(shù)據(jù)傳輸方法，所述通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝，具體為通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本發(fā)明的第七個方面，提供ー種網(wǎng)元設備，包括接收單元，用于接收發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)量參數(shù)；判斷単元，用于根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果；發(fā)送單元，用于向所述發(fā)送端返回攜帯有所述判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。如上所述的網(wǎng)元設備，所述判斷単元，具體用于獲取第一閾值和第二閾值，并判斷所述PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述PDP上下文對應的承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。本發(fā)明的第八個方面，提供ー種網(wǎng)元設備，包括發(fā)送單元，用于向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)量參數(shù)；接收單元，用于接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果；封裝単元，用于在所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，則通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。如上所述的網(wǎng)元設備,所述封裝單元,具體用于通過UDP-Lite協(xié)議將所述PDP上下文對應的承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本發(fā)明的第九個方面，提供ー種網(wǎng)元設備，包括接收單元，用于接收發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯所述承載的服務質(zhì)量參數(shù)；判斷単元，用于根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果；發(fā)送單元，用于向所述發(fā)送端返回攜帯有所述判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述響應消息攜帯的所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的網(wǎng)元設備，所述判斷単元，具體用于獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。本發(fā)明的第十個方面，提供ー種網(wǎng)元設備，包括發(fā)送單元，用于向接收端發(fā)送承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述承載的服務質(zhì)量參數(shù)；接收單元，用于接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果；封裝単元，用于在所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的網(wǎng)元設備，所述封裝単元，具體用于在所述響應消息攜帯有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本發(fā)明的第十一個方面，提供ー種網(wǎng)元設備，包括創(chuàng)建或更新単元，用于創(chuàng)建或更新承載；
判斷単元，用于根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果；發(fā)送單元，用于向所述接收端發(fā)送攜帯有判斷結果信息的指令消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的網(wǎng)元設備，所述判斷単元，具體用于獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。本發(fā)明的第十二個方面，提供ー種網(wǎng)元設備，包括接收單元，用于接收發(fā)送端發(fā)送的指令信息，所述指令信息攜帯有判斷結果信息，所述判斷結果信息為所述發(fā)送端根據(jù)創(chuàng)建或更新的承載的服務質(zhì)量參數(shù)，判斷出所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果；封裝単元，用于在所述指令信息攜帯有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。如上所述的網(wǎng)元設備，所述封裝単元，具體用于通過UDP-Lite協(xié)議將所述承載的
用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本發(fā)明的第十三個方面，提供ー種通信系統(tǒng)，包括至少ー組用于數(shù)據(jù)傳輸?shù)木W(wǎng)元設備，所述網(wǎng)元設備采用上述的網(wǎng)元設備。由上述技術方案可知，本發(fā)明通過對承載的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述承載通過UDP-Lite進行封裝。對于那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本發(fā)明提供的技術方案可實現(xiàn)UDP-Lite封裝，較現(xiàn)有技術將所有PDP上下文激活或承載均通過UDP協(xié)議封裝，減少了對報文的載荷的校驗，顯著地提高了數(shù)據(jù)傳輸?shù)男省?br>

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作ー簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖I為本發(fā)明提供的數(shù)據(jù)傳輸方法實施例一的流程示意圖；圖2為本發(fā)明提供的數(shù)據(jù)傳輸方法實施例ニ的流程示意圖；圖3為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)2G或3G用戶側(cè)發(fā)起PDP上下文二次激活的創(chuàng)建或更新時的數(shù)據(jù)傳輸示意圖；圖4為本發(fā)明提供的數(shù)據(jù)傳輸方法實施例三的流程示意圖；圖5為本發(fā)明提供的數(shù)據(jù)傳輸方法實施例四的流程示意圖；圖6為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)S4SGSN組網(wǎng)用戶側(cè)發(fā)起專有承載的創(chuàng)建時的數(shù)據(jù)傳輸示意圖；圖7為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)S4SGSN組網(wǎng)用戶側(cè)發(fā)起專有承載的更新時的數(shù)據(jù)傳輸示意圖；圖8為本發(fā)明提供的數(shù)據(jù)傳輸方法實施例五的流程示意圖；圖9為本發(fā)明提供的數(shù)據(jù)傳輸方法實施例六的流程示意圖；圖10為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)S4SGSN組網(wǎng)網(wǎng)絡側(cè)發(fā)起專有承載的創(chuàng)建時的數(shù)據(jù)傳輸示意圖；圖11為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)S4SGSN組網(wǎng)網(wǎng)絡側(cè)發(fā)起專有承載的更新時的數(shù)據(jù)傳輸示意圖；圖12為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)EPC用戶側(cè)發(fā)起專有承載創(chuàng)建時的數(shù)據(jù)傳輸示意圖；圖13為應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)EPC用戶側(cè)發(fā)起專有承載更新時的數(shù)據(jù)傳輸示意圖；
圖14為本發(fā)明提供的網(wǎng)元設備實施例一的結構示意圖；圖15為本發(fā)明提供的網(wǎng)元設備實施例ニ的結構示意圖；圖16為本發(fā)明提供的網(wǎng)元設備實施例三的結構示意圖；圖17為本發(fā)明提供的網(wǎng)元設備實施例四的結構示意圖；圖18為本發(fā)明提供的網(wǎng)元設備實施例五的結構示意圖；圖19為本發(fā)明提供的網(wǎng)元設備實施例六的結構示意圖。
具體實施例方式
首先，對本發(fā)明實施例涉及的幾個概念進行解釋。UDP User Datagram Protocol,用戶數(shù)據(jù)報協(xié)議。UDP是ー種傳輸層協(xié)議,一般應用于分組網(wǎng)絡，用戶的數(shù)據(jù)基于單個UDP分組傳輸。UDP-Lite User Datagram Protocol Lite,輕量級用戶數(shù)據(jù)報協(xié)議。UDP-Lite 協(xié)議的校驗和字段的校驗范圍是可以變化的，其適用于語音或視頻類對誤碼率大于閾值的業(yè)務。GTP GPRS Tunnelling Protocol GPRS隧道協(xié)議，為GSN之間的用戶數(shù)據(jù)和信令信息的傳輸提供隧道。GTP協(xié)議是為GPRS網(wǎng)絡的Gn和Gp接ロ而定義的，是GPRS隧道協(xié)議。包括GTP控制平面(簡稱GTP-C)和數(shù)據(jù)傳輸(簡稱GTP-U)協(xié)議，允許多種協(xié)議的數(shù)據(jù)報在UMTS或GPRS骨干網(wǎng)上的SGSN之間，SGSN和網(wǎng)關GPRS支持節(jié)點(Gateway GPRS SupportNode,以下簡稱GGSN)之間傳輸。GTPU :通用無線分組業(yè)務(General Packet Radio Service, GPRS)隧道協(xié)議用戶面部分(User plane of GPRS Tunneling Protocol,GTPU),可以完成用戶數(shù)據(jù)加封裝或解封裝。為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。如圖I所示，本發(fā)明提供的數(shù)據(jù)傳輸方法實施例一的流程示意圖。如圖中所示，本實施例一所述數(shù)據(jù)傳輸方法，包括步驟101、接收發(fā)送端發(fā)送的F1DP (Packet Data Protocol,分組數(shù)據(jù)協(xié)議)上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶有所述PDP上下文激活的服務質(zhì)量(Qualityof Service,以下簡稱QoS)參數(shù)。其中，接收端接收發(fā)送端發(fā)送的PDP下文的創(chuàng)建或更新消息。所述接收端可以是能夠依據(jù)接收到的PDP上下文的創(chuàng)建或更新消息返回響應消息以建立GTP隧道的網(wǎng)元設備，如GGSN。所述發(fā)送端為可發(fā)送PDP上下文的創(chuàng)建或更新消息以建立GTP隧道的網(wǎng)元設備，如SGSN。所述PDP上下文創(chuàng)建包括PDP上下文的一次創(chuàng)建和PDP上下文的二次創(chuàng)建。
步驟102、根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述發(fā)送端返回攜帯有判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。具體地，接收端根據(jù)所述QoS參數(shù)，判斷所述PDP上下文是否為錯包容忍度高的業(yè)務，若是，則所述PDP上下文能通過UDP-Lite協(xié)議進行封裝。其中，判斷所述PDP上下文是否為錯包容忍度高的業(yè)務，可具體通過首先，獲取第一閾值和第二閾值；然后判斷所述PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，則所述PDP上下文為錯包容忍度高的業(yè)務，所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝，否則，所述PDP上下文不是錯包容忍度高的業(yè)務，所述PDP上下文對應的承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝，可仍然使用現(xiàn)有技術中的UDP協(xié)議進行封裝。其中，所述第一閾值和所述第二閾值可人為設定。所述第一閾值與所述第二閾值的獲取可采用人工控制的方式進行輸入來獲取，也可預存在存儲區(qū)中從所述存儲區(qū)中獲取。接收端向所述發(fā)送端返回所述響應消息的目的是為了 告知接收端是否接受所述發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新請求，若接受，則所述發(fā)送端和接收端之間就建立了 GTP隧道。所述發(fā)送端與所述接收端可通過該GTP隧道進行信息的傳輸。所述響應消息中攜帯的所述判斷結果信息是為了告知所述發(fā)送端所述PDP上下文對應的GTP隧道的用戶面隧道是否可通過UDP-Lite協(xié)議進行封裝，以使發(fā)送端根據(jù)告知的結果作出相應的響應，即對錯包容忍度高的業(yè)務的用戶面隧道進行UDP-Lite協(xié)議封裝。本實施例是基于現(xiàn)有2G (第二代手機通信技術)或3G (第三代手機通信技術)網(wǎng)絡提出的數(shù)據(jù)傳輸方法。本實施例通過對PDP上下文的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述PDP上下文對應的承載的用戶面隧道通過UDP-Lite進行封裝。對于那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本發(fā)明實施例可實現(xiàn)UDP-Lite封裝,較現(xiàn)有技術將所有PDP上下文激活均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。如圖2所示，本發(fā)明提供的數(shù)據(jù)傳輸方法實施例ニ的流程示意圖。如圖中所示，本實施例ニ所述數(shù)據(jù)傳輸方法，包括步驟201、向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)量參數(shù)。其中，發(fā)送端向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息。所述發(fā)送端為以是SGSN0所述接收端可以是GGSN，如圖3所示的實例。步驟202、接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果。步驟203、若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。具體地，若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則發(fā)送端通過UDP-Lite協(xié)議將所述PDP上下文對應的承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文(以下簡稱GTPU報文)，并將所述GTPU報文的報文頭中的校驗和覆蓋域(以下Checksum Coverage)字段設置為預設值。這里需要說明是在UDP-Lite協(xié)議中，一個數(shù)據(jù)報文到底需不需要對其進行校驗，或者是校驗多少位可由用戶控制。并且UDP-Lite協(xié)議就是用UDP協(xié)議的Length字段來表示其Checksum Coverage的,所以當UDP-Lite協(xié)議的Checksum Coverage字段等于整個UDP數(shù)據(jù)報(包括UDP頭和載荷)的長度時，UDP-Lite產(chǎn)生的包也就和傳統(tǒng)的UDP包一模一樣。若Checksum Coverage為0,表示對整個通過UDP-Lite協(xié)議進行封裝的數(shù)據(jù)報進行校驗。若Checksum Coverage >= 8,表示對通過UDP-Lite協(xié)議進行封裝的數(shù)據(jù)報的前Checksum Coverage個字節(jié)進行校驗。ChecksumCoverage取除上述的值之外的值是非法的。本實施例中，所述預設值可以是設定為8，即所述ChecksumCoverage取值為8,在校驗和計算時只對數(shù)據(jù)報的前8個字節(jié)進行校驗，即只對通過UDP-Lite協(xié)議封裝的GTPU報文的報文頭進行校驗，不對GTPU報文的載荷進行校驗，避免了現(xiàn)有技術中通過UDP協(xié)議封裝的數(shù)據(jù)報需要對數(shù)據(jù)報的報頭和載荷同時校驗的問題，提高了數(shù)據(jù)的傳輸效率。如圖3所示，應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)2G或3G用戶側(cè)發(fā)起PDP上下文二次創(chuàng)建或更新時的數(shù)據(jù)傳輸?shù)氖疽鈭D。本應用實例為用戶側(cè)發(fā)起的PDP上下文二 次創(chuàng)建或更新，由GGSN根據(jù)QoS參數(shù)判斷是否通過UDP-Lite來封裝該二次創(chuàng)建的PDP上下文對應的承載的用戶面隧道，并通過Create PDP Context Response或Update PDP ContextResponse消息告知SGSN設備。具體實現(xiàn)過程如下述內(nèi)容。，包括下述步驟。對于用戶側(cè)發(fā)起的PDP上下文的二次創(chuàng)建，包括步驟111、SGSN 向所述 GGSN 發(fā)送 Create PDP Context Request 消息創(chuàng)建 PDP 上下文。步驟112、所述GGSN根據(jù)所述Create PDP Context Request消息攜帶的QoS參數(shù)，判斷待創(chuàng)建的所述二次創(chuàng)建的PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述SGSN返回攜帶有判斷結果的Create PDP Context Response消息。其中，若所述GGSN根據(jù)所述Create PDP Context Response消息中攜帶的QoS參數(shù)，判斷出待創(chuàng)建的所述二次創(chuàng)建的PDP上下文為錯包容忍度高的業(yè)務，即所述二次創(chuàng)建的PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度大于第一閾值且丟包容忍度大于第二閾值，則所述二次創(chuàng)建的PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。當所述SGSN接收到所述GGSN返回的Create PDP Context Response消息后，所述SGSN和所述GGSN之間就建立起了 GTP隧道。所述SGSN和所述GGSN之間交互的信息均可承載在該GTP隧道內(nèi)進行傳輸。步驟113、若所述Create PDP Context Response消息中攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則所述SGSN通過UDP-Lite協(xié)議對所述PDP上下文二次激活的用戶面隧道進行封裝。具體地，SGSN通過UDP-Lite協(xié)議將二次創(chuàng)建的PDP上下文對應的用戶面隧道封裝為GTPU報文，并將所述GTPU報文的報文頭中的校驗和覆蓋域字段設置為8。發(fā)送端SGSN在向GGSN發(fā)送所述GTPU報文時，只對GTPU報文的報文頭進行校驗和計算。GGSN在接收所述GTPU報文后也只對報文頭的校驗和進行驗證，免去了現(xiàn)有技術中還需要對GTPU報文負荷(即Checksum Coverage,校驗和覆蓋域)字段進行校驗。對于用戶側(cè)發(fā)起的PDP上下文的更新，包括
步驟121、SGSN 向所述 GGSN 發(fā)送 Update PDP Context Request 消息更新 PDP 上下文。步驟122、所述GGSN根據(jù)所述Update PDP Context Request消息更新PDP上下文，然后根據(jù)所述Update PDP Context Request消息攜帶的QoS參數(shù),判斷待更新的所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述SGSN反饋攜帶有判斷結果的Update PDP Context Response消息。同樣地,若所述GGSN根據(jù)所述Create PDP Context Response消息中攜帶的QoS參數(shù)，判斷出待更新的所述PDP上下文二次激活為錯包容忍度高的業(yè)務，則所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。其中，錯包容忍度高的業(yè)務的判斷可采用上述的判斷過程來實現(xiàn)。當所述SGSN接收到所述GGSN返回的Update PDPContext Response消息后，所述SGSN和所述GGSN之間就建立起了 GTP隧道。所述SGSN和所述GGSN之間交互的信息均可承載在該GTP隧道內(nèi)進行傳輸。步驟123、若所述Update PDP Context Response消息中攜帶的判斷結果為能通過 UDP-Lite封裝，則SGSN通過UDP-Lite協(xié)議對所述PDP上下文二次激活的用戶面隧道進行封裝，以使得被封裝的所述PDP上下文二次激活承載在已建立的GTP隧道內(nèi)進行傳輸。其中，SGSN通過UDP-Lite協(xié)議封裝所述PDP上下文對應的承載的用戶面隧道的過程同上，此處不再贅述。如圖4所示，本發(fā)明提供的數(shù)據(jù)傳輸方法實施例三的流程示意圖。如圖中所示，本實施例三所述數(shù)據(jù)傳輸方法，包括步驟301、接收發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯所述承載的服務質(zhì)量參數(shù)。其中，本實施例是基于4G(第四代手機通信技術)網(wǎng)絡，例如SGSN通過S4接ロ接入到EPC網(wǎng)絡的組網(wǎng)方式的組網(wǎng)(以下簡稱S4SGSN組網(wǎng))或EPC網(wǎng)絡，實現(xiàn)的數(shù)據(jù)傳輸方法。具體地，接收端接收所述發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息。所述接收端可以是可發(fā)送承載創(chuàng)建或更新消息以建立GTP隧道的網(wǎng)元設備，如SGSN ;或者是轉(zhuǎn)發(fā)接收到的承載創(chuàng)建或更新消息的網(wǎng)元設備，如S-GW。所述接收端具體可以是F1DN(Public Data Network,公用數(shù)據(jù)網(wǎng))網(wǎng)關(以下簡寫P-GW)。其中所述承載包括專有承載和缺省承載。步驟302、根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述發(fā)送端返回攜帯有判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。具體地，接收端根據(jù)所述QoS參數(shù)，判斷所述承載是否為錯包容忍度高的業(yè)務，若是，則所述承載能通過UDP-Lite協(xié)議進行封裝。其中，判斷所述承載是否為錯包容忍度高的業(yè)務，可具體通過獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于第一閾值且丟包容忍度是否大于第二閾值，若均是，則所述承載為錯包容忍度高的業(yè)務，所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝，否則，所述承載不是錯包容忍度高的業(yè)務，所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝，可仍然使用現(xiàn)有技術中的UDP協(xié)議進行封裝。所述第一閾值和所述第二閾值可人為設定。接收端向所述發(fā)送端返回的所述響應消息的目的是為了告知接收端是否接受所述發(fā)送端發(fā)送的承載的創(chuàng)建或更新請求，若接受，則所述發(fā)送端和接收端之間就建立了 GTP隧道。所述發(fā)送端與所述接收端可通過該GTP隧道進行信息的傳輸。所述響應消息中攜帯的所述判斷結果信息是為了告知所述發(fā)送端所述承載的用戶面隧道是否可通過UDP-Lite協(xié)議進行封裝，以使發(fā)送端根據(jù)告知的結果作出相應的響應，即對錯包容忍度高的業(yè)務的用戶面隧道進行UDP-Lite協(xié)議封裝。如圖5所示，本發(fā)明提供的數(shù)據(jù)傳輸方法實施例四的流程示意圖。如圖中所示，本實施例四所述數(shù)據(jù)傳輸方法，包括步驟401、向接收端發(fā)送承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述承載的服務質(zhì)量參數(shù)。其中，發(fā)送端向接收端發(fā)送承載的創(chuàng)建或更新消息。所述承載包括專有承載和缺省承載。所述接收端可以是可發(fā)送承載創(chuàng)建或更新消息以建立GTP隧道的網(wǎng)元設備，如SGSN ;或者是轉(zhuǎn)發(fā)接收到的承載創(chuàng)建或更新消息的網(wǎng)元設備，如S-GW。所述接收端具體可以是P-GW?！げ襟E402、接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果。步驟403、若所述響應消息攜帯有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。具體地，若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則發(fā)送端通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為GTPU報文，并將所述GTPU報文的報文頭中的校驗和覆蓋域(Checksum Coverage)字段設置為預設值。其中預設值的選定可參照上述實施例中所涉及的相關內(nèi)容，此處不再贅述。上述實施例三和實施例四是基于現(xiàn)有的4G網(wǎng)絡中用戶側(cè)發(fā)起承載的創(chuàng)建或更新消息以建立GTP隧道所提出的數(shù)據(jù)傳輸方法。上述實施例通過對承載的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述承載通過UDP-Lite進行封裝。對于ー些可以通過UDP-Lite進行封裝的承載，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本發(fā)明提供的技術方案可實現(xiàn)UDP-Lite封裝，較現(xiàn)有技術將所有承載均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。如圖6和7所示，應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)S4SGSN組網(wǎng)下用戶側(cè)發(fā)起承載的創(chuàng)建或更新時的數(shù)據(jù)傳輸示意圖。如圖所示，對于S4SGSN組網(wǎng)下用戶側(cè)發(fā)起的專有承載的創(chuàng)建或更新，由P-GW根據(jù)QoS參數(shù)判斷是否通過UDP-Lite封裝專有承載，并通過Create Bearer Request 或 Update Bearer Request 消息告知 S-GW 和 SGSN 設備。具體實現(xiàn)過程如下述內(nèi)容。如圖6所示,S4SGSN組網(wǎng)用戶側(cè)發(fā)起專有承載的創(chuàng)建時的數(shù)據(jù)傳輸示意圖。包括步驟311、SGSN發(fā)起B(yǎng)earer Resource Command消息請求創(chuàng)建專有承載。步驟312、S_GW將接收自所述SGSN發(fā)起的Bearer Resource Command消息請求轉(zhuǎn)發(fā)至P-GW。步驟313、P_GW根據(jù)Bearer Resource Command消息攜帶的QoS參數(shù),判斷待創(chuàng)建的專有承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，井向S-GW返回攜帯有判斷結果的 Create Bearer Request 消息。步驟314、S-GW根據(jù)Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載進行封裝，并同時將接收到的所述Create Bearer Request消息轉(zhuǎn)發(fā)至所述SGSN。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則S-GW通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟315、SGSN根據(jù)接收的所述Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載的用戶面隧道進行封裝，井向所述S-GW返回應答專有承載建立消息。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則SGSN通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。這里需要注意的是若是DT(direct tunnel,直接隧道)模式,SGSN還需要將所述 Create Bearer Request消息轉(zhuǎn)發(fā)至無線網(wǎng)絡控制器(以下簡稱RNC) oRNC根據(jù)接收的所述Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載的用戶面隧道進行封裝。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則RNC通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟316、S-GW在接收到所述SGSN返回的應答專有承載建立消息后，同樣向P-GW返回應答專有承載建立消息。如圖7所示，S4SGSN組網(wǎng)用戶側(cè)發(fā)起專有承載的更新時的數(shù)據(jù)傳輸示意圖。對于S4SGSN組網(wǎng)下用戶側(cè)發(fā)起的專有承載更新，包括步驟321、SGSN發(fā)起Modify Bearer Command消息請求專有承載修改。步驟322、S-GW將接收自所述SGSN發(fā)起Modify Bearer Command消息轉(zhuǎn)發(fā)至P-GW。步驟323、P-Gff根據(jù)接收的所述Modify Bearer Command消息攜帶的QoS參數(shù)，判斷待更新的專有承載是否能通過UDP-Lite協(xié)議封裝，井向S-GW返回攜帯有判斷結果的Update Bearer Request 消息。步驟324、S-GW根據(jù)所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載進行封裝,并同時將接收到的所述Update Bearer Request消息轉(zhuǎn)發(fā)至所述SGSN。若Update BearerRequest消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則S-GW通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟325、SGSN根據(jù)接收的所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載的用戶面隧道進行封裝。若Update Bearer Request消息攜帯的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則SGSN通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。這里需要注意的是若是DT模式，SGSN還需要將所述Update Bearer Request消息轉(zhuǎn)發(fā)至RNC。RNC根據(jù)接收的所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載進行封裝。若Update Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則RNC通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟326、S_GW在接收到所述SGSN返回的應答專有承載建立消息后，同樣向P_GW返回應答專有承載建立消息。
如圖8所示，本發(fā)明提供的數(shù)據(jù)傳輸方法實施例五的流程示意圖。如圖中所示，本實施例五所述數(shù)據(jù)傳輸方法也是基于現(xiàn)有4G網(wǎng)絡，例如S4SGSN組網(wǎng)或EPC組網(wǎng)，實現(xiàn)的數(shù)據(jù)傳輸方法，包括步驟501、創(chuàng)建或更新承載，并根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝。具體地，發(fā)送端發(fā)起承載的創(chuàng)建或更新。所述發(fā)送端具體可以P-GW。所述承載包括專有承載和缺省承載。P-GW判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于第一閾值且丟包容忍度是否大于第二閾值，若均是，所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝，可仍然使用現(xiàn)有技術中的UDP協(xié)議進行封裝。其中所述第一閾值與所述第二閾值可人為設定。步驟502、向所述接收端發(fā)送攜帯有判斷結果信息的指令消息，以使所述接收端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述 承載的用戶面隧道進行封裝。具體地，發(fā)送端向所述接收端發(fā)送攜帯有判斷結果信息的指令消息。其中，在S4SGSN組網(wǎng)中，所述接收端可以是S-GW或SGSN。在EPC組網(wǎng)中，所述接收端可以是S-GW或 eNodeB。如圖9所示，本發(fā)明提供的數(shù)據(jù)傳輸方法實施例六的流程示意圖。如圖中所示，本實施例六所述數(shù)據(jù)傳輸方法，包括步驟601、接收發(fā)送端發(fā)送的指令信息，所述指令信息攜帯有判斷結果信息，所述判斷結果信息為所述發(fā)送端根據(jù)創(chuàng)建或更新的承載的服務質(zhì)量參數(shù)，判斷出所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果。具體地，接收端接收發(fā)送端發(fā)送的指令信息。所述步驟602、若所述指令信息攜帯有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。具體地，所述接收端通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。上述實施例五和實施例六是基于現(xiàn)有的4G網(wǎng)絡中網(wǎng)絡側(cè)發(fā)起承載的創(chuàng)建或更新以建立GTP隧道所提出的數(shù)據(jù)傳輸方法。上述實施例通過對承載的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述承載通過UDP-Lite進行封裝。對于ー些可以通過UDP-Lite進行封裝的承載，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本發(fā)明提供的技術方案可實現(xiàn)UDP-Lite封裝，較現(xiàn)有技術將所有承載均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。如圖10和11所示，應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)S4SGSN組網(wǎng)下網(wǎng)絡側(cè)發(fā)起承載的創(chuàng)建或更新時的數(shù)據(jù)傳輸示意圖。如圖所示，對于S4SGSN組網(wǎng)，網(wǎng)絡側(cè)發(fā)起的專有承載的創(chuàng)建或更新，由P-GW根據(jù)專有承載的QoS參數(shù)判斷是否通過UDP-Lite協(xié)議封裝專有承載，并通過 Create Bearer Request 或 Update Bearer Request 消息告知 S-GW和SGSN設備。具體實現(xiàn)過程如下述內(nèi)容。如圖10所示，S4SGSN組網(wǎng)網(wǎng)絡側(cè)發(fā)起專有承載的創(chuàng)建時的數(shù)據(jù)傳輸示意圖。包括步驟511、P-Gff創(chuàng)建專有承載時，根據(jù)所述專有承載的QoS參數(shù)判斷所述專有承載的用戶面隧道是否能通過UDP-Lite協(xié)議封裝，井向S-GW返回攜帯有判斷結果的CreateBearer Request 消息。步驟512、S-GW根據(jù)所述Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議封裝所述專有承載的用戶面隧道，并同時將接收到的所述CreateBearer Request消息轉(zhuǎn)發(fā)至所述SGSN。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則S-GW通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟513、SGSN根據(jù)接收的所述Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載的用戶面隧道進行封裝，井向所述S-GW返回應答專有承載建立消息。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則SGSN通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。這里需要注意的是若是DT模式，SGSN還需要將所述Create Bearer Request消 息轉(zhuǎn)發(fā)至RNC。RNC根據(jù)接收的所述Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載進行封裝。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則RNC通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟514、S_GW在接收到所述SGSN返回的應答專有承載建立消息后，同樣向P_GW返回應答專有承載建立消息。如圖11所示，S4SGSN組網(wǎng)網(wǎng)絡側(cè)發(fā)起專有承載的更新時的數(shù)據(jù)傳輸示意圖。包括步驟521、P-GW更新專有承載時，根據(jù)所述專有承載的QoS參數(shù)判斷所述專有承載的用戶面隧道是否能通過UDP-Lite協(xié)議封裝，井向S-GW返回攜帯有判斷結果的UpdateBearer Request 消息。步驟522、S-GW根據(jù)所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議封裝所述專有承載的用戶面隧道，并同時將接收到的所述UpdateBearer Request消息轉(zhuǎn)發(fā)至所述SGSN。若Update Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則S-GW通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟523、SGSN根據(jù)接收的所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載的用戶面隧道進行封裝，井向所述S-GW返回應答專有承載建立消息。若Update Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則SGSN通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。這里需要注意的是若是DT模式，SGSN還需要將所述Update Bearer Request消息轉(zhuǎn)發(fā)至RNC。RNC根據(jù)接收的所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議對專有承載的用戶面隧道進行封裝。若Update Bearer Request消息攜帯的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則RNC通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟524、S_GW在接收到所述SGSN返回的應答專有承載更新消息后，同樣向P_GW返回應答專有承載更新消息。
如圖如圖12和13所示，應用本發(fā)明提供的數(shù)據(jù)傳輸方法實現(xiàn)EPC組網(wǎng)下網(wǎng)絡側(cè)發(fā)起承載的創(chuàng)建或更新時的數(shù)據(jù)傳輸示意圖。如圖所示，對于EPC組網(wǎng)，網(wǎng)絡側(cè)發(fā)起的專有承載創(chuàng)建或更新，由P-GW根據(jù)專有承載的QoS參數(shù)判斷是否通過UDP-Lite來封裝GTPU報文，并通過 Create Bearer Request 或 Update Bearer Request 消息告知 S-GW、MME 和eNodeBo具體實現(xiàn)過程如下述內(nèi)容。如圖12所示，EPC用戶側(cè)發(fā)起專有承載創(chuàng)建時的數(shù)據(jù)傳輸示意圖。對于網(wǎng)絡側(cè)發(fā)起的專有承載創(chuàng)建，所述數(shù)據(jù)傳輸方法包括步驟531、P_GW創(chuàng)建專有承載時，根據(jù)所述專有承載的QoS參數(shù)判斷所述專有承載是否能通過UDP-Lite協(xié)議封裝,并向S-GW返回攜帶有判斷結果的Create Bearer Request消息。步驟532、S_GW處理專有承載建立,并根據(jù)所述Create Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議封裝所述專有承載，同時將接收到的所述CreateBearer Request消息轉(zhuǎn)發(fā)至所述MME。若CreateBearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則S-GW通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟533、MME處理專有承載建立，同時將接收到的所述Create BearerRequest消息轉(zhuǎn)發(fā)至所述eNodeB。步驟534、eNodeB處理專有承載建立，并根據(jù)所述Create Bearer Request消息攜帯的判斷結果決定是否通過UDP-Lite協(xié)議封裝所述專有承載的用戶面隧道，井向MME返回應答專有承載建立消息。若Create Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則eNodeB通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟535、MME在接收到所述eNodeB返回的應答專有承載建立消息后，同樣向S-GW返回應答專有承載建立消息。步驟536、S-Gff在接收到所述MME返回的應答專有承載建立消息后，同樣向P_GW返回應答專有承載建立消息。如圖13所示，EPC用戶側(cè)發(fā)起專有承載更新情況下的數(shù)據(jù)傳輸示意圖。對于網(wǎng)絡側(cè)發(fā)起的專有承載更新，所述數(shù)據(jù)傳輸方法，包括步驟541、P_GW更新專有承載時，根據(jù)所述專有承載的QoS參數(shù)判斷所述專有承載是否能通過UDP-Lite協(xié)議封裝,并向S-GW返回攜帶有判斷結果的Update Bearer Request消息。步驟542、S_GW處理專有承載建立,并根據(jù)所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議封裝所述專有承載，同時將接收到的所述UpdateBearer Request消息轉(zhuǎn)發(fā)至所述MME。若Update Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則S-GW通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟543、MME處理專有承載更新，同時將接收到的所述Update Bearer Request消息轉(zhuǎn)發(fā)至所述eNodeB。步驟544、eNodeB處理專有承載更新，并根據(jù)所述Update Bearer Request消息攜帶的判斷結果決定是否通過UDP-Lite協(xié)議封裝所述專有承載，并向MME返回應答專有承載建立消息。若Update Bearer Request消息攜帶的判斷結果為能通過UDP-Lite協(xié)議進行封裝，則eNodeB通過UDP-Lite協(xié)議對所述專有承載的用戶面隧道進行封裝。步驟545、MME在接收到所述eNodeB返回的應答專有承載建立消息后，同樣向S-GW返回應答專有承載建立消息。步驟546、S-Gff在接收到所述MME返回的應答專有承載建立消息后，同樣向P_GW返回應答專有承載建立消息。如圖14所示，本發(fā)明提供的網(wǎng)元設備實施例一的結構示意圖。如圖中所述，所述網(wǎng)元設備包括接收單元I、判斷單元2和發(fā)送單元3。其中，所述接收單元I用于接收發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶有服務質(zhì)量參數(shù)。判斷單元2用于根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果。所述發(fā)送單元3用于向所述發(fā)送端返回攜帶有所述判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過 UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。本實施例所述網(wǎng)元設備可以是GGSN。進一步地，上述實施例中所述判斷單元具體用于獲取第一閾值和第二閾值，并判斷所述PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述PDP上下文對應的承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。本實施例是基于現(xiàn)有2G或3G網(wǎng)絡提出的網(wǎng)元設備。本實施例所述網(wǎng)元設備通過對PDP上下文的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite進行封裝。對于一些可以通過UDP-Lite進行封裝的PDP上下文，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，本實施例可以輸出PDP上下文激活的是否能通過UDP-Lite進行封裝的判斷結果，以使接收端網(wǎng)元設備根據(jù)所述判斷結果作出相應地響應，較現(xiàn)有技術將所有PDP上下文均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。如圖15所示，本發(fā)明提供的網(wǎng)元設備實施例二的結構示意圖。如圖中所述，所述網(wǎng)元設備包括發(fā)送單元6、接收單元4和封裝單元5。其中，所述發(fā)送單元6用于向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶有所述PDP上下文的服務質(zhì)量參數(shù)。所述接收單元4用于接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帶有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果。所述封裝單元5用于在所述響應消息攜帶有判斷結果信息為能通過MF-Lite協(xié)議進行封裝時，則通過UDP-Lite協(xié)議對所述I3DP上下文對應的承載的用戶面隧道進行封裝。本實施例二中所述的網(wǎng)元設備可具體是SGSN。本實施例所述封裝單元可具體用于通過UDP-Lite協(xié)議將所述PDP上下文對應的承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
本實施例二是基于現(xiàn)有2G或3G網(wǎng)絡提出的網(wǎng)元設備。本實施例二所述網(wǎng)元設備通過接收到的響應信息攜帶的判斷結果，來確定是否將所述PDP上下文對應的承載的用戶面隧道通過UDP-Lite進行封裝。對于一些可以通過UDP-Lite進行封裝的PDP上下文激活，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本實施例二所述網(wǎng)元設備可實現(xiàn)UDP-Lite協(xié)議的封裝，較現(xiàn)有技術將所有PDP上下文激活均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。如圖16所示,本發(fā)明提供的網(wǎng)元設備的實施例三的結構示意圖。如圖中所示,所述網(wǎng)元設備包括接收單元12、判斷單元13和發(fā)送單元14。其中，所述接收單元12用于接收發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶所述承載的服務質(zhì)量參數(shù)。所述判斷單元13用于根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過 TOP-Lite協(xié)議進行封裝，得出判斷結果。所述發(fā)送單元14用于向所述發(fā)送端返回攜帶有所述判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述響應消息攜帶的所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。本實施例中所述網(wǎng)元設備可以是P-GW。進一步地，上述實施例中所述判斷單元具體用于獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。本實施例三是基于現(xiàn)有4G網(wǎng)絡，例如S4SGSN組網(wǎng)或EPC組網(wǎng)，提出的網(wǎng)元設備。本實施例所述網(wǎng)元設備通過對承載的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述承載的用戶面隧道是否能通過UDP-Lite進行封裝。對于一些可以通過UDP-Lite進行封裝的承載，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，本實施例可以輸出所述承載的是否能通過UDP-Lite進行封裝的判斷結果，以使接收端網(wǎng)元設備根據(jù)所述判斷結果作出相應地響應，較現(xiàn)有技術將所有承載均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男省Ｈ鐖D17中所示，本發(fā)明提供的網(wǎng)元設備實施例四的結構示意圖。所述網(wǎng)元設備包括發(fā)送單元15、接收單元16和封裝單元17。其中，所述發(fā)送單元15用于向接收端發(fā)送承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶有所述承載的服務質(zhì)量參數(shù)。所述接收單元16用于接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帶有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果。所述封裝單元17用于在所述響應消息攜帶有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。進一步地，所述封裝單元具體用于在所述響應消息攜帶有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。本實施例四是基于現(xiàn)有4G網(wǎng)絡，例如S4SGSN組網(wǎng)或EPC組網(wǎng)，提出的網(wǎng)元設備。本實施例四所述網(wǎng)元設備通過接收到的響應信息攜帶的判斷結果，來確定是否將所述承載的用戶面隧道通過UDP-Lite進行封裝。對于一些可以通過UDP-Lite進行封裝的承載，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本實施例四所述網(wǎng)元設備可實現(xiàn)UDP-Lite協(xié)議的封裝，較現(xiàn)有技術將所有承載均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。如圖18中所示，本發(fā)明提供的網(wǎng)元設備實施例五的結構示意圖。如圖中所示，所述網(wǎng)元設備包括創(chuàng)建或更新單元18、判斷單元19或發(fā)送單元20。所述創(chuàng)建或更新單元18用于創(chuàng)建或更新承載。所述判斷單元19用于根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果。所述發(fā)送單元20用于向所述接收端發(fā)送攜帶有判斷結果信息的指令消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。進一步地，上述實施例中所述的判斷單元具體用于獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于第一閾值且丟包容忍度是否大于第二閾值，若均是，得出判斷結果為所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。
本實施例五是基于現(xiàn)有4G網(wǎng)絡，例如S4SGSN組網(wǎng)或EPC組網(wǎng)，提出的網(wǎng)元設備。本實施例所述網(wǎng)元設備通過在創(chuàng)建或更新承載時，同時對承載的服務質(zhì)量參數(shù)進行判斷，來確定是否將所述承載的用戶面隧道是否能通過UDP-Lite進行封裝。對于一些可以通過UDP-Lite進行封裝的承載，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，本實施例可以輸出所述承載的是否能通過UDP-Lite進行封裝的判斷結果，以使接收端網(wǎng)元設備根據(jù)所述判斷結果作出相應地響應，較現(xiàn)有技術將所有承載均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男省Ｈ鐖D19所示，本發(fā)明提供的網(wǎng)元設備的實施例六的結構示意圖。如圖中所示，所述網(wǎng)元設備包括接收單元21和封裝單元22。其中，所述接收單元21用于接收發(fā)送端發(fā)送的指令信息，所述指令信息攜帶有判斷結果信息，所述判斷結果信息為所述發(fā)送端根據(jù)創(chuàng)建或更新的承載的服務質(zhì)量參數(shù)，判斷出所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果。所述封裝單元22用于在所述指令信息攜帶有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。進一步地，上述實施例中所述封裝單元具體用于通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。該預設值的選取可參照上述數(shù)據(jù)傳輸實施例中所涉及到的相關內(nèi)容，此處不再贅述。本實施例六是基于現(xiàn)有4G網(wǎng)絡，例如S4SGSN組網(wǎng)或EPC組網(wǎng)，提出的網(wǎng)元設備。本實施例六所述網(wǎng)元設備通過接收到的指令消息攜帶的判斷結果，來確定是否將所述承載的用戶面隧道通過UDP-Lite進行封裝。對于一些可以通過UDP-Lite進行封裝的承載，尤其是那些語音和視頻等對錯包容忍度比較高的業(yè)務，通過本實施例六所述網(wǎng)元設備可實現(xiàn)UDP-Lite協(xié)議的封裝，較現(xiàn)有技術將所有承載均通過UDP協(xié)議封裝，能顯著地提高數(shù)據(jù)傳輸?shù)男?。本發(fā)明提供一種通信系統(tǒng)實施例。所述通信系統(tǒng)包括至少一組用于數(shù)據(jù)傳輸?shù)木W(wǎng)元設備。所述的一組網(wǎng)元設備包括至少兩個所述網(wǎng)元設備。其中，所述一組網(wǎng)元設備可以是上述實施例一和實施例二所述的網(wǎng)元設備，具體如圖3所示的實例。所述的一組網(wǎng)元設備還可以是上述實施例三和實施例四所述的網(wǎng)元設備，具體如圖6和7所示的實例。所述的一組網(wǎng)元設備還可以是上述實施例五和實施例六所述的網(wǎng)元設備，具體如圖10、11、12和13所示的實例。本領域普通技術人員可以理解附圖只是一個實施例的示意圖，附圖中的模塊或流程并不一定是實施本發(fā)明所必須的。本領域普通技術人員可以理解實施例中的裝置中的模塊可以按照實施例描述分布于實施例的裝置中，也可以進行相應變化位于不同于本實施例的一個或多個裝置中。上述實施例的模塊可以合并為一個模塊，也可以進一步拆分成多個子模塊。上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。本領域普通技術人員可以理解實現(xiàn)上述各方法實施例的全部或部分步驟可以通過程序指令相關的硬件來完成。前述的程序可以存儲于一計算機可讀取存儲介質(zhì)中。該程序在執(zhí)行時，執(zhí)行包括上述各方法實施例的步驟；而前述的存儲介質(zhì)包括R0M、RAM、磁碟·或者光盤等各種可以存儲程序代碼的介質(zhì)。最后應說明的是以上各實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡管參照前述各實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分或者全部技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質(zhì)脫離本發(fā)明各實施例技術方案的范圍。
權利要求
1.ー種數(shù)據(jù)傳輸方法，其特征在于，包括 接收發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)量參數(shù)； 根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述發(fā)送端返回攜帯有判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。
2.根據(jù)權利要求I所述的數(shù)據(jù)傳輸方法，其特征在于，所述根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，包括 獲取第一閾值和第二閾值； 判斷所述PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。
3.ー種數(shù)據(jù)傳輸方法，其特征在于，包括 向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述PDP上下文的服務質(zhì)量參數(shù)； 接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果； 若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。
4.根據(jù)權利要求3所述的數(shù)據(jù)傳輸方法，其特征在于，所述通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝，具體為 通過UDP-Lite協(xié)議將所述PDP上下文對應的承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
5.ー種數(shù)據(jù)傳輸方法，其特征在于，包括 接收發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有服務質(zhì)量參數(shù)； 根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向所述發(fā)送端返回攜帯有判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
6.根據(jù)權利要求5所述的數(shù)據(jù)傳輸方法，其特征在于，所述根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，包括 獲取第一閾值和第二閾值； 判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。
7.ー種數(shù)據(jù)傳輸方法，其特征在于，包括向接收端發(fā)送承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述承載的服務質(zhì)量參數(shù)； 接收所述接收端返回的創(chuàng)建或 更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果; 若所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
8.根據(jù)權利要求7所述的數(shù)據(jù)傳輸方法，其特征在于，所述通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝，具體為 通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
9.ー種數(shù)據(jù)傳輸方法，其特征在于，包括 創(chuàng)建或更新承載，井根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝； 向所述接收端發(fā)送攜帯有判斷結果信息的指令消息，以使所述接收端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
10.根據(jù)權利要求9所述的數(shù)據(jù)傳輸方法，其特征在于，所述根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，包括 獲取第一閾值和第二閾值； 判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。
11.ー種數(shù)據(jù)傳輸方法，其特征在于，包括 接收發(fā)送端發(fā)送的指令信息，所述指令信息攜帯有判斷結果信息，所述判斷結果信息為所述發(fā)送端根據(jù)創(chuàng)建或更新的承載的服務質(zhì)量參數(shù)，判斷出所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果； 若所述指令信息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝，則通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
12.根據(jù)權利要求11所述的數(shù)據(jù)傳輸方法，其特征在于，所述通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝，具體為 通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
13.ー種網(wǎng)元設備，其特征在于，包括 接收單元，用于接收發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述PDP上下文的服務質(zhì)量參數(shù)； 判斷単元，用于根據(jù)所述服務質(zhì)量參數(shù)，判斷所述PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果； 發(fā)送單元，用于向所述發(fā)送端返回攜帯有所述判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。
14.根據(jù)權利要求13所述的網(wǎng)元設備，其特征在干， 所述判斷単元，具體用于獲取第一閾值和第二閾值，并判斷所述PDP上下文的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述PDP上下文對應的承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝。
15.ー種網(wǎng)元設備，其特征在于，包括 發(fā)送單元，用于向接收端發(fā)送PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶有所述PDP上下文的服務質(zhì)量參數(shù)； 接收單元，用于接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果； 封裝単元，用于在所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述PDP上下文對應的承載的用戶面隧道進行封裝。
16.根據(jù)權利要求15所述的網(wǎng)元設備，其特征在干， 所述封裝単元，具體用于在所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議將所述PDP上下文對應的承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
17.ー種網(wǎng)元設備，其特征在于，包括 接收單元，用于接收發(fā)送端發(fā)送的承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯所述承載的服務質(zhì)量參數(shù)； 判斷単元，用于根據(jù)所述服務質(zhì)量參數(shù)，判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果； 發(fā)送單元，用于向所述發(fā)送端返回攜帯有所述判斷結果信息的響應消息，以使所述發(fā)送端在接收到所述響應消息攜帯的所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
18.根據(jù)權利要求17所述的網(wǎng)元設備，其特征在干， 所述判斷単元，具體用于獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。
19.ー種網(wǎng)元設備，其特征在于，包括 發(fā)送單元，用于向接收端發(fā)送承載的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帯有所述承載的服務質(zhì)量參數(shù)；接收單元，用于接收所述接收端返回的創(chuàng)建或更新響應消息，所述響應消息為所述接收端根據(jù)所述創(chuàng)建或更新消息返回的，所述響應消息攜帯有判斷結果信息，所述判斷結果信息為所述接收端根據(jù)所述服務質(zhì)量參數(shù)，判斷承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果； 封裝単元，用于在所述響應消息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
20.根據(jù)權利要求19所述的網(wǎng)元設備，其特征在干， 所述封裝単元，具體用于在所述響應消息攜帯有判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
21.ー種網(wǎng)元設備，其特征在于，包括 創(chuàng)建或更新単元，用于創(chuàng)建或更新承載； 判斷単元，用于根據(jù)所述承載的服務質(zhì)量參數(shù)判斷所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，得出判斷結果； 發(fā)送單元，用于向所述接收端發(fā)送攜帯有判斷結果信息的指令消息，以使所述發(fā)送端在接收到所述判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
22.根據(jù)權利要求21所述的網(wǎng)元設備，其特征在干， 所述判斷単元，具體用于獲取第一閾值和第二閾值，并判斷所述承載的服務質(zhì)量參數(shù)中的誤碼容忍度是否大于所述第一閾值且丟包容忍度是否大于所述第二閾值，若均是，得出判斷結果為所述承載的用戶面隧道能通過UDP-Lite協(xié)議進行封裝；否則，得出判斷結果為所述承載的用戶面隧道不能通過UDP-Lite協(xié)議進行封裝。
23.ー種網(wǎng)元設備，其特征在于，包括 接收單元，用于接收發(fā)送端發(fā)送的指令信息，所述指令信息攜帯有判斷結果信息，所述判斷結果信息為所述發(fā)送端根據(jù)創(chuàng)建或更新的承載的服務質(zhì)量參數(shù)，判斷出所述承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝的結果； 封裝単元，用于在所述指令信息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝吋，通過UDP-Lite協(xié)議對所述承載的用戶面隧道進行封裝。
24.根據(jù)權利要求23所述的網(wǎng)元設備，其特征在干， 所述封裝単元，具體用于在所述指令信息攜帯的判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議將所述承載的用戶面隧道封裝為數(shù)據(jù)傳輸協(xié)議報文，并將所述數(shù)據(jù)傳輸協(xié)議報文的報文頭中的校驗和覆蓋域字段設置為預設值。
25.—種通信系統(tǒng)，其特征在于，包括包括至少ー組用于數(shù)據(jù)傳輸?shù)木W(wǎng)元設備；所述的一組網(wǎng)元設備為上述權利要求13或14所述的網(wǎng)元設備和上述權利要求15或16所述的網(wǎng)元設備；或者，所述的ー組網(wǎng)元設備為上述權利要求17或18所述的網(wǎng)元設備和上述權利要求19或20所述的網(wǎng)元設備；或者，所述的ー組網(wǎng)元設備為上述權利要求21或22所述的第三網(wǎng)元設備和上述權利要求23或24所述的第四網(wǎng)元設備。
全文摘要
本發(fā)明實施例提供一種數(shù)據(jù)傳輸方法、網(wǎng)元設備及通信系統(tǒng)。所述方法包括接收發(fā)送端發(fā)送的PDP上下文的創(chuàng)建或更新消息，所述創(chuàng)建或更新消息攜帶有PDP上下文的服務質(zhì)量參數(shù)；根據(jù)服務質(zhì)量參數(shù)判斷PDP上下文對應的承載的用戶面隧道是否能通過UDP-Lite協(xié)議進行封裝，并向發(fā)送端返回攜帶有判斷結果信息的響應消息，以使發(fā)送端在接收到判斷結果信息為能通過UDP-Lite協(xié)議進行封裝時，通過UDP-Lite協(xié)議對PDP上下文對應的承載的用戶面隧道進行封裝。本發(fā)明實施例提供的技術方案可將一些錯包容忍度高的業(yè)務封裝為UDP-Lite協(xié)議的報文，較現(xiàn)有技術，減少了對報文的載荷的校驗，顯著地提高數(shù)據(jù)傳輸?shù)男省?br> 文檔編號H04W80/06GK102870490SQ201280000908
公開日2013年1月9日 申請日期2012年6月30日 優(yōu)先權日2012年6月30日
發(fā)明者周軍平 申請人:華為技術有限公司