專利名稱：一種保證業(yè)務服務質(zhì)量的數(shù)據(jù)包傳輸方法
技術(shù)領(lǐng)域：
本發(fā)明涉及在通用移動通信系統(tǒng)(UMTS)中傳輸數(shù)據(jù)包的技術(shù)，特別涉及一種保證業(yè)務服務質(zhì)量(QoS)的數(shù)據(jù)包傳輸方法。
背景技術(shù)：
UMTS是采用寬帶碼分多址(WCDMA)系統(tǒng)空中接口技術(shù)的第三代移動通信系統(tǒng)(3G)，UMTS系統(tǒng)通常被稱為WCDMA系統(tǒng)。UMTS系統(tǒng)采用與第二代移動通信系統(tǒng)類似的結(jié)構(gòu)，包括無線接入網(wǎng)絡(luò)(Radio AccessNetwork，RAN)和核心網(wǎng)絡(luò)(Core Network，CN)。其中，RAN實現(xiàn)無線接入功能，CN實現(xiàn)UMTS系統(tǒng)內(nèi)所有的話音呼叫和數(shù)據(jù)連接，并實現(xiàn)與外部網(wǎng)絡(luò)的交換和路由功能。CN從邏輯上分為電路交換域(Circuit SwitchedDomain，CS)和分組交換域(Packet Switched Domain，PS)。對于WCDMA的R5及R5以后的版本，CN還可以包括IP多媒體子系統(tǒng)(IMS，IP MultimediaSubsystem)域。
UMTS核心網(wǎng)絡(luò)中的PS和IMS域，采用互聯(lián)網(wǎng)協(xié)議(IP)作為其承載協(xié)議。因為PS和IMS域采用IP技術(shù)，而IP技術(shù)卻存在沒有業(yè)務服務質(zhì)量(QoS)保證的缺點，從而導致PS和IMS域也存在無QoS保證的缺點。
但是UMTS提供的諸多業(yè)務，比如語音、可變速率數(shù)據(jù)和活動視頻會話等業(yè)務，特別是多媒體業(yè)務，對QoS提出了嚴格的要求。為了解決UMTS的PS和IMS域無QoS的問題，實現(xiàn)端到端的QoS保證，UMTS的端到端QoS框架已被提出(3GPP TS23.207)。
圖1是在現(xiàn)有技術(shù)中UMTS內(nèi)部QoS框架的示意圖。如圖1所示，在UMTS內(nèi)部，無線核心網(wǎng)(CN)側(cè)的QoS框架包括應用功能實體(AF)、策略決定功能實體(PDF)和網(wǎng)關(guān)GPRS支持節(jié)點(GGSN)，其中，AF提供需要控制IP承載需求的應用程序功能，并通過Gq接口與PDF交互動態(tài)QoS相關(guān)業(yè)務消息；PDF是邏輯策略決定單元，基于AF的資源請求和會話信息進行策略決定，并通過Go接口把策略決定結(jié)果下發(fā)到GGSN；GGSN提供數(shù)據(jù)包在UMTS內(nèi)部的CN與外部數(shù)據(jù)網(wǎng)之間的路由和封裝功能，并且安裝PDF下發(fā)的策略，根據(jù)策略進行數(shù)據(jù)包的轉(zhuǎn)發(fā)。
圖2是端到端QoS劃分區(qū)段示意圖。如圖2所示，端到端的QoS可劃分為3個區(qū)段，在UMTS內(nèi)部，從用戶設(shè)備(UE)到服務GPRS支持節(jié)點(SGSN)的QoS和從SGSN到GGSN的QoS，以及從UMTS內(nèi)部的GGSN到UMTS外部IP骨干網(wǎng)的QoS。
目前，保證UMTS內(nèi)部SGSN與GGSN之間的QoS措施，包括綜合業(yè)務(IntServ)模型和區(qū)分業(yè)務(DiffServ)模型。
綜合業(yè)務(IntServ)模型使用資源預留(RSVP)協(xié)議，RSVP協(xié)議是一種預留資源的信令協(xié)議。圖3是在現(xiàn)有技術(shù)中使用綜合業(yè)務模型保證SGSN到GGSN的QoS的流程圖。如圖3所示，在主叫方所處UMTS側(cè)，綜合業(yè)務模型保證從SGSN到GGSN的QoS的過程為步驟301、在主叫方所處UMTS側(cè)，主叫方的用戶設(shè)備(UE)發(fā)出業(yè)務會話請求后，在收發(fā)業(yè)務流數(shù)據(jù)包之前向SGSN發(fā)送路徑(PATH)消息，SGSN將PATH消息轉(zhuǎn)發(fā)到SGSN和GGSN之間的IP骨干網(wǎng)中的邊緣路由器上。
步驟302、SGSN和GGSN之間的IP骨干網(wǎng)中，包括邊緣路由器的各級路由器逐級向下發(fā)送PATH消息，直至GGSN。
步驟303、從GGSN逐級向上至SGSN，分別向其上游發(fā)送RESV消息，該RESV消息請求上游路由器預留出QoS參數(shù)指定的帶寬資源，并且，各級路由器在接收到RESV消息時，分別判斷其當前是否存在可用的承載資源，如果存在，則執(zhí)行步驟305，否則，執(zhí)行步驟304。
步驟304、不存在承載資源的路由器不向其上游路由器發(fā)送RESV消息，各級上游路由器及SGSN在設(shè)定時間內(nèi)未接收到RESV消息，則認為資源預留不成功，跳出本流程。
步驟305、各級路由器至SGSN均接收到RESV消息時，為本次業(yè)務預留帶寬，并且保存相關(guān)的狀態(tài)信息。
步驟306、SGSN通過IP骨干網(wǎng)中的各級路由器將業(yè)務流數(shù)據(jù)包轉(zhuǎn)發(fā)至GGSN。
在區(qū)分業(yè)務(DiffServ)模型中，客戶預先與網(wǎng)絡(luò)供應商簽訂服務級別合同(SLA)。SLA明確了該客戶的業(yè)務級別和在每個業(yè)務級別中所允許的通信量，即業(yè)務流數(shù)據(jù)包所需的傳輸帶寬。
在主叫方所處UMTS側(cè)，區(qū)分業(yè)務模型保證從SGSN到GGSN的QoS的過程為當接收到SGSN發(fā)來的業(yè)務流數(shù)據(jù)包時，區(qū)分業(yè)務模型中的邊緣路由器根據(jù)該用戶的級別為業(yè)務流數(shù)據(jù)包進行優(yōu)先級分類，并將其傳輸給網(wǎng)絡(luò)中的下一個中間路由器；各級路由器在接收到業(yè)務流數(shù)據(jù)包時，直接根據(jù)該業(yè)務流數(shù)據(jù)包的優(yōu)先級對其進行轉(zhuǎn)發(fā)，直至GGSN。
在現(xiàn)有技術(shù)中，UMTS外部的IP骨干網(wǎng)也使用綜合業(yè)務模型或區(qū)分業(yè)務模型保證傳輸業(yè)務流數(shù)據(jù)包的QoS，因此，從主叫方所處UMTS中的GGSN至UMTS外部IP骨干網(wǎng)保證QoS過程的原理與上述在主叫方所處UMTS中使用綜合業(yè)務模型或區(qū)分業(yè)務模型保證從SGSN到GGSN的QoS過程的原理相同。
而在被叫方所處UMTS側(cè)，GGSN與SGSN之間的IP骨干網(wǎng)使用綜合業(yè)務模型或區(qū)分業(yè)務模型，保證從GGSN到SGSN的QoS的過程與上述在主叫方所處UMTS側(cè)使用綜合業(yè)務模型或區(qū)分業(yè)務模型保證從SGSN到GGSN的QoS的具體過程的原理相同。
主叫方所處UMTS、UMTS外部IP骨干網(wǎng)和被叫方所處UMTS在使用綜合業(yè)務模型保證QoS時，綜合業(yè)務模型中的各級路由器定時更新其保存的狀態(tài)信息。
可見，現(xiàn)有技術(shù)存在以下缺點1、當進行跨UMTS域范圍的無線通信時，對于區(qū)分業(yè)務模型，UMTS本身的QoS保證與IP骨干網(wǎng)中(包括UMTS內(nèi)部SGSN和GGSN之間，以及GGSN和外部IP網(wǎng)絡(luò)之間)的QoS保證是兩個獨立的過程，UMTS域內(nèi)與域外分別根據(jù)其接收到的業(yè)務流進行QoS保證，所以即使業(yè)務流在UMTS內(nèi)部得到QoS保證，而當其到達IP骨干網(wǎng)時，很可能由于IP骨干網(wǎng)無充足的承載資源，使得業(yè)務流被拒絕或丟失，從而無法確保從主叫方所處UMTS中的SGSN和GGSN，到被叫方所處UMTS中的GGSN至SGSN的QoS，即無法確保SGSN與GGSN之間以及GGSN與外部骨干網(wǎng)，如IP骨干網(wǎng)之間的QoS。
2、主叫方所處UMTS內(nèi)部從SGSN到GGSN、UMTS外部的IP骨干網(wǎng)以及被叫方所處UMTS內(nèi)部從GGSN到SGSN，采用綜合業(yè)務模型保證QoS時，需要對綜合業(yè)務模型中的各個設(shè)備定時刷新其保存的PATH及RSVP狀態(tài)信息，而大量定時刷新PATH及RSVP狀態(tài)信息對網(wǎng)絡(luò)設(shè)備的處理器、緩沖器(Buffer)和內(nèi)存消耗很大，并影響UMTS網(wǎng)絡(luò)的穩(wěn)定性，不具備可擴展性，從而嚴重制約了綜合業(yè)務模型的實際應用。
3、主叫方所處UMTS內(nèi)部從SGSN到GGSN、UMTS外部的IP骨干網(wǎng)以及被叫方所處UMTS內(nèi)部從GGSN到SGSN，采用區(qū)分業(yè)務模型保證QoS時，因為各級路由器無法根據(jù)網(wǎng)絡(luò)拓撲和資源狀況判斷是否能夠為業(yè)務提供質(zhì)量保證，只是直接根據(jù)業(yè)務流數(shù)據(jù)包的優(yōu)先級進行轉(zhuǎn)發(fā)，從而無法在會話建立時提供QoS保證。
圖4是現(xiàn)有技術(shù)中IP骨干網(wǎng)采用獨立資源控制的QoS框架示意圖。如圖4所示，為了解決IP骨干網(wǎng)采用綜合業(yè)務模型或區(qū)分業(yè)務模型保證QoS的缺點，目前，提出了一種在UMTS外部的IP骨干網(wǎng)采用獨立資源控制的QoS模型，該QoS模型按照功能可以劃分為三層，分別為業(yè)務控制層、承載控制層和承載層。其中，業(yè)務控制層，由IP骨干網(wǎng)絡(luò)中的處理分組數(shù)據(jù)申請的各類業(yè)務服務器組成，向承載控制層申請業(yè)務流的承載路徑；承載控制層，由若干個資源管理器(RM)組成，負責管理承載層的網(wǎng)絡(luò)資源，包括帶寬、處理器和緩沖器(Buffer)等，對于每條有QoS要求的業(yè)務流的數(shù)據(jù)業(yè)務申請進行資源允許控制、資源分配和選路，滿足業(yè)務流的QoS要求；承載層分為基礎(chǔ)承載網(wǎng)絡(luò)層和邏輯承載網(wǎng)絡(luò)層，基礎(chǔ)承載網(wǎng)絡(luò)層是由邊緣路由器和核心路由器所組成的IP骨干網(wǎng)絡(luò)物理實體，承載各類IP業(yè)務包。邏輯承載網(wǎng)絡(luò)層是利用標簽交換路徑(LSP)技術(shù)在基礎(chǔ)承載網(wǎng)絡(luò)層上預先規(guī)劃和配置的各個邏輯承載網(wǎng)絡(luò)，每個邏輯承載網(wǎng)絡(luò)承載特定業(yè)務類型或特定QoS等級的IP業(yè)務包。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種保證Qos的數(shù)據(jù)包傳輸方法，該方法能確保跨IP骨干網(wǎng)的UMTS實現(xiàn)有Qos保證的數(shù)據(jù)包傳輸。
根據(jù)上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的一種保證業(yè)務服務質(zhì)量的數(shù)據(jù)包傳輸方法，該方法采用通用移動通信系統(tǒng)UMTS的業(yè)務服務質(zhì)量QoS框架并適于跨網(wǎng)際協(xié)議IP骨干網(wǎng)的UMTS，分別將業(yè)務服務器的功能設(shè)置在應用功能實體AF上和將資源管理器的功能設(shè)置在策略決定功能實體PDF上，PDF管理從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源，該方法還包括A、AF接收到本次業(yè)務會話消息后，向PDF發(fā)送本次業(yè)務流數(shù)據(jù)包的QoS承載資源請求；B、收到該承載資源請求的PDF根據(jù)其管理域內(nèi)的承載資源信息，進行承載選路，并作出包括承載路徑及其QoS資源的QoS策略下發(fā)給主叫方所屬的GGSN；C、該GGSN執(zhí)行該QoS策略，對本次業(yè)務流數(shù)據(jù)包進行傳輸。
在步驟C之后，該方法還包括
D、AF接收到終止本次業(yè)務會話的消息后，向PDF發(fā)送釋放本次業(yè)務流數(shù)據(jù)包的QoS承載資源請求；E、PDF釋放本次業(yè)務流數(shù)據(jù)包所占的承載資源，向GGSN發(fā)送停止本次業(yè)務流數(shù)據(jù)包的傳輸命令；F、GGSN停止傳輸本次業(yè)務流數(shù)據(jù)包。
該方法進一步包括承載資源狀態(tài)信息變化上報過程當GGSN檢測出承載資源狀態(tài)發(fā)生變化時，GGSN向PDF上報承載資源變化狀態(tài)信息，由PDF根據(jù)該承載資源變化狀態(tài)信息重新作出QoS策略下發(fā)給GGSN后，執(zhí)行步驟C。
將邊緣路由器的功能設(shè)置在網(wǎng)關(guān)GPRS支持節(jié)點GGSN上，步驟C所述的對本次業(yè)務流數(shù)據(jù)包進行傳輸為GGSN根據(jù)其接收到QoS策略中的承載路徑信息逐層將本次業(yè)務會話的業(yè)務流數(shù)據(jù)包打上從主叫方所屬的GGSN經(jīng)過IP骨干網(wǎng)到被叫方所屬的GGSN方向路徑的多級標簽棧，然后根據(jù)標簽所示的路徑將該業(yè)務流數(shù)據(jù)包進行傳輸，直到該業(yè)務流數(shù)據(jù)包傳輸?shù)奖唤蟹剿鶎俚腉GSN上。
步驟B所述下發(fā)給主叫方所屬的GGSN的QoS策略是通過Go接口下發(fā)的，Go接口應用的協(xié)議遵循通用開放策略業(yè)務COPS協(xié)議及其擴展。
步驟B所述的管理域內(nèi)的承載資源信息為靜態(tài)配置的，或者為GGSN通過Go接口上報的，Go接口應用的協(xié)議遵循COPS協(xié)議及其擴展。
所述的在GGSN設(shè)置的邊緣路由器的功能為接收QoS策略的功能和采用MPLS的多級標簽棧技術(shù)的功能。
所述的PDF管理從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源為將從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源由同一個PDF管理，該承載資源包括從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN中各個網(wǎng)絡(luò)節(jié)點的設(shè)備資源及網(wǎng)絡(luò)節(jié)點之間的拓撲結(jié)構(gòu)和帶寬資源。
所述的被叫方所屬的GGSN可以為多個被叫方所屬的不同GGSN，在一次業(yè)務會話中被叫方所屬的GGSN被主叫方所屬的PDF管理。
從上述方案可以看出，本發(fā)明將現(xiàn)有UMTS QoS框架中的AF、PDF和GGSN的功能增強AF具有IP骨干網(wǎng)中的業(yè)務服務器的功能，PDF具有IP骨干網(wǎng)中的資源管理器的功能和GGSN具有IP骨干網(wǎng)中的邊緣路由器的功能，使該現(xiàn)有的UMTS QoS框架可以采用獨立資源控制的IP骨干網(wǎng)QoS方法，管理從主叫方GGSN經(jīng)IP骨干網(wǎng)到被叫方GGSN的有QoS保證的承載資源和進行承載路徑選擇，不需要分別保證UMTS內(nèi)部和UMTS外部IP骨干網(wǎng)的QoS數(shù)據(jù)包的傳輸。因此，本發(fā)明提供的方法可以確?？鏘P骨干網(wǎng)的UMTS實現(xiàn)有QoS保證的數(shù)據(jù)包傳輸。


圖1是在現(xiàn)有技術(shù)中UMTS內(nèi)部QoS框架的示意圖。
圖2是端到端QoS劃分區(qū)段示意圖。
圖3是在現(xiàn)有技術(shù)中使用綜合業(yè)務模型保證SGSN到GGSN的QoS的流程圖。
圖4是現(xiàn)有技術(shù)中IP骨干網(wǎng)采用獨立資源控制的QoS框架示意圖。
圖5為本發(fā)明跨IP骨干網(wǎng)的QoS框架示意圖。
圖6為本發(fā)明跨IP骨干網(wǎng)的UMTS實現(xiàn)有Qos保證的數(shù)據(jù)包傳輸?shù)牧鞒虉D。
具體實施例方式
為了使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，以下舉實施例并參照附圖，對本發(fā)明進行進一步詳細說明。
圖5為本發(fā)明跨IP骨干網(wǎng)的QoS框架示意圖。如圖5所示，UMTS內(nèi)部包括AF、PDF、SGSN和GGSN，其中，AF具有IP骨干網(wǎng)中的業(yè)務服務器的功能，即具有申請業(yè)務流的承載路徑的功能；PDF具有IP骨干網(wǎng)中的資源管理器的功能，即具有負責管理網(wǎng)絡(luò)資源，包括帶寬、處理器和Buffer等，對于每條有QoS要求的業(yè)務流數(shù)據(jù)包申請進行資源允許控制、資源分配和選路，滿足業(yè)務流數(shù)據(jù)包的QoS要求的功能；GGSN具有IP骨干網(wǎng)中的邊緣路由器的功能。IP骨干網(wǎng)包括邊緣路由器和核心路由器。
本發(fā)明中IP骨干網(wǎng)的各個路由器，包括邊緣路由器和核心路由器都支持多協(xié)議標簽交換技術(shù)(MPLS)。
為了便于管理和網(wǎng)絡(luò)的穩(wěn)定性，一般可將PS和IMS劃分為多個管理域，管理域的劃分與路由域相同或不同。本發(fā)明中由主叫方所屬的PDF管理的管理域的范圍跨過了IP骨干網(wǎng)，并包括主叫方所屬的GGSN和被叫方所屬的GGSN。該管理域上的所有承載資源都由PDF來管理，所有的承載資源包括主叫方所屬的GGSN、IP骨干網(wǎng)中的各個路由器和被叫方所屬的GGSN等網(wǎng)絡(luò)節(jié)點的設(shè)備及節(jié)點之間的拓撲結(jié)構(gòu)和帶寬資源等。管理域內(nèi)的承載資源可以為靜態(tài)配置的，或者可以為GGSN通過Go接口上報的，Go接口應用的協(xié)議遵循并不局限于遵循通用開放策略業(yè)務(COPS)協(xié)議及相關(guān)的擴展。
由于PDF完成管理域中的所有承載選路功能，即PDF記錄和維護各個節(jié)點的拓撲結(jié)構(gòu)及資源數(shù)據(jù)，所以本發(fā)明提供的PDF能夠根據(jù)本次業(yè)務流數(shù)據(jù)包的QoS要求選擇在管理域中業(yè)務流數(shù)據(jù)包將要通過的節(jié)點路徑，并且此路徑上的Qos是能夠得到嚴格保證的。
本發(fā)明中的主叫方所屬的GGSN可以采用現(xiàn)有的MPLS的多級標簽棧技術(shù)，把對應于業(yè)務流的數(shù)據(jù)包打上對應路徑的多級標簽棧，并按照PDF所指定的承載路徑傳輸該數(shù)據(jù)包。
在GGSN和PDF之間的接口Go，除傳遞原Go接口的所有信息之外，還需要傳遞承載路徑信息和與其相關(guān)聯(lián)的QoS資源，PDF將承載路徑信息和與其相關(guān)聯(lián)的QoS資源通過Go下發(fā)給GGSN。Go接口應用的協(xié)議遵循并不局限于遵循COPS協(xié)議及相關(guān)的擴展。
以下具體說明跨IP骨干網(wǎng)的UMTS實現(xiàn)有Qos保證的數(shù)據(jù)包傳輸?shù)倪^程。如圖6所示，圖6為本發(fā)明跨IP骨干網(wǎng)的UMTS實現(xiàn)有Qos保證的數(shù)據(jù)包傳輸?shù)牧鞒虉D，其具體步驟為步驟600、AF接收到業(yè)務會話信令消息，即呼叫消息，如SIP等，向PDF發(fā)送申請本次業(yè)務流數(shù)據(jù)包的承載路徑請求；步驟601、收到該請求的PDF根據(jù)其管理域內(nèi)的資源信息，進行承載選路，作出QoS策略決定，該策略中包括本次業(yè)務流數(shù)據(jù)包的承載路徑信息和與承載路徑信息相關(guān)聯(lián)的QoS資源；步驟602、PDF將該QoS策略下發(fā)給主叫方所屬的GGSN；步驟603、GGSN接收該QoS策略，根據(jù)該QoS策略中的信息對本次業(yè)務流數(shù)據(jù)包進行轉(zhuǎn)發(fā)；步驟604、當AF要終止本此業(yè)務會話時，AF向PDF發(fā)送拆除本次業(yè)務流數(shù)據(jù)包的承載路徑請求；步驟605、PDF收到該請求后，釋放所占管理域內(nèi)的資源，并發(fā)送停止本次業(yè)務流數(shù)據(jù)包處理的命令給GGSN；步驟606、GGSN收到該命令后，停止對本次業(yè)務流數(shù)據(jù)包的轉(zhuǎn)發(fā)。
本發(fā)明所述的被叫方所屬的GGSN可以為多個被叫方所屬的不同GGSN，但是在一次會話呼叫中，分配的承載路徑只能經(jīng)過一個被叫方所屬的GGSN。
PDF和GGSN之間進行信息交互，當在轉(zhuǎn)發(fā)業(yè)務流時，承載資源狀態(tài)因承載層的設(shè)備，如路由器故障而發(fā)生變化時，GGSN可以向PDF上報承載資源變化狀態(tài)信息，由PDF根據(jù)該承載資源變化狀態(tài)信息重新作出QoS策略決定，下發(fā)給GGSN執(zhí)行。
在本發(fā)明中，GGSN收到要轉(zhuǎn)發(fā)的業(yè)務流數(shù)據(jù)包時，根據(jù)其接收到的承載路徑信息逐層將本次業(yè)務會話的業(yè)務流數(shù)據(jù)包打上從主叫方所屬的GGSN經(jīng)過IP骨干網(wǎng)到被叫方所屬的GGSN方向路徑的多級標簽棧，然后根據(jù)標簽所示的路徑將該業(yè)務流數(shù)據(jù)包進行轉(zhuǎn)發(fā)，直到該業(yè)務流數(shù)據(jù)包傳輸?shù)奖唤蟹剿鶎俚腉GSN上。
本發(fā)明通過結(jié)合現(xiàn)有UMTS QoS框架和獨立資源控制的IP骨干網(wǎng)QoS方法，很好地繼承了獨立資源控制地IP骨干網(wǎng)QoS方法的成果，從而獲得了跨IP骨干網(wǎng)的UMTS實現(xiàn)有Qos保證的數(shù)據(jù)包傳輸過程。
本發(fā)明沒有改變現(xiàn)有的UMTS QoS框架，通過在AF、PDF和GGSN上進行某些功能的增強實現(xiàn)QoS保證，對現(xiàn)有的UMTS QoS框架沖擊最小。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)所做的任何修改、等同替換和改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1.一種保證業(yè)務服務質(zhì)量的數(shù)據(jù)包傳輸方法，該方法采用通用移動通信系統(tǒng)UMTS的業(yè)務服務質(zhì)量QoS框架并適于跨網(wǎng)際協(xié)議IP骨干網(wǎng)的UMTS，其特征在于，分別將業(yè)務服務器的功能設(shè)置在應用功能實體AF上和將資源管理器的功能設(shè)置在策略決定功能實體PDF上，PDF管理從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源，該方法還包括A、AF接收到本次業(yè)務會話消息后，向PDF發(fā)送本次業(yè)務流數(shù)據(jù)包的QoS承載資源請求；B、收到該承載資源請求的PDF根據(jù)其管理域內(nèi)的承載資源信息，進行承載選路，并作出包括承載路徑及其QoS資源的QoS策略下發(fā)給主叫方所屬的GGSN；C、該GGSN執(zhí)行該QoS策略，對本次業(yè)務流數(shù)據(jù)包進行傳輸。
2.如權(quán)利要求1所述的方法，其特征在于，在步驟C之后，該方法還包括D、AF接收到終止本次業(yè)務會話的消息后，向PDF發(fā)送釋放本次業(yè)務流數(shù)據(jù)包的QoS承載資源請求；E、PDF釋放本次業(yè)務流數(shù)據(jù)包所占的承載資源，向GGSN發(fā)送停止本次業(yè)務流數(shù)據(jù)包的傳輸命令；F、GGSN停止傳輸本次業(yè)務流數(shù)據(jù)包。
3.如權(quán)利要求1所述的方法，其特征在于，該方法進一步包括承載資源狀態(tài)信息變化上報過程當GGSN檢測出承載資源狀態(tài)發(fā)生變化時，GGSN向PDF上報承載資源變化狀態(tài)信息，由PDF根據(jù)該承載資源變化狀態(tài)信息重新作出QoS策略下發(fā)給GGSN后，執(zhí)行步驟C。
4.如權(quán)利要求1所述的方法，其特征在于，將邊緣路由器的功能設(shè)置在網(wǎng)關(guān)GPRS支持節(jié)點GGSN上，步驟C所述的對本次業(yè)務流數(shù)據(jù)包進行傳輸為GGSN根據(jù)其接收到QoS策略中的承載路徑信息逐層將本次業(yè)務會話的業(yè)務流數(shù)據(jù)包打上從主叫方所屬的GGSN經(jīng)過IP骨干網(wǎng)到被叫方所屬的GGSN方向路徑的多級標簽棧，然后根據(jù)標簽所示的路徑將該業(yè)務流數(shù)據(jù)包進行傳輸，直到該業(yè)務流數(shù)據(jù)包傳輸?shù)奖唤蟹剿鶎俚腉GSN上。
5.如權(quán)利要求1所述的方法，其特征在于，步驟B所述下發(fā)給主叫方所屬的GGSN的QoS策略是通過Go接口下發(fā)的，Go接口應用的協(xié)議遵循通用開放策略業(yè)務COPS協(xié)議及其擴展。
6.如權(quán)利要求1所述的方法，其特征在于，步驟B所述的管理域內(nèi)的承載資源信息為靜態(tài)配置的，或者為GGSN通過Go接口上報的，Go接口應用的協(xié)議遵循COPS協(xié)議及其擴展。
7.如權(quán)利要求1所述的方法，其特征在于，所述的在GGSN設(shè)置的邊緣路由器的功能為接收QoS策略的功能和采用多協(xié)議標簽交換MPLS的多級標簽棧技術(shù)的功能。
8.如權(quán)利要求1所述的方法，其特征在于，所述的PDF管理從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源為將從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源由同一個PDF管理，該承載資源包括從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN中各個網(wǎng)絡(luò)節(jié)點的設(shè)備資源及網(wǎng)絡(luò)節(jié)點之間的拓撲結(jié)構(gòu)和帶寬資源。
9.如權(quán)利要求8所述的方法，其特征在于，所述的被叫方所屬的GGSN可以為多個被叫方所屬的不同GGSN，在一次業(yè)務會話中被叫方所屬的GGSN被主叫方所屬的PDF管理。
全文摘要
一種保證業(yè)務服務質(zhì)量的數(shù)據(jù)包傳輸方法，該方法分別將業(yè)務服務器的功能設(shè)置在應用功能實體AF上和將資源管理器的功能設(shè)置在策略決定功能實體PDF上，PDF管理從主叫方所屬的GGSN經(jīng)IP骨干網(wǎng)到被叫方所屬的GGSN的承載資源，該方法還包括A.AF接收到本次業(yè)務會話消息后，向PDF發(fā)送本次業(yè)務流數(shù)據(jù)包的QoS承載資源請求；B.收到該承載資源請求的PDF根據(jù)其管理域內(nèi)的承載資源信息，進行承載選路，并作出包括承載路徑及其QoS資源的QoS策略下發(fā)給主叫方所屬的GGSN；C.該GGSN執(zhí)行該QoS策略，對本次業(yè)務流數(shù)據(jù)包進行傳輸。
文檔編號H04L12/56GK1705296SQ200410042389
公開日2005年12月7日 申請日期2004年5月28日 優(yōu)先權(quán)日2004年5月28日
發(fā)明者陳悅鵬, 馬朝暉, 何蕓谷, 鄒婷 申請人:華為技術(shù)有限公司