服務質量的更新處理方法及裝置制造方法

服務質量的更新處理方法及裝置制造方法
【專利摘要】本發明提供了一種服務質量的更新處理方法及裝置，其中，上述方法包括：UE獲取應用提供商和運營商的協作關系；UE根據獲取的協作關系請求服務質量QoS更新。采用本發明提供的上述技術方案，解決了相關技術中，對用戶的多徑信息進行管理耗費較多硬件內部緩存空間在第三方應用提供商和運營商不存在業務協作時，尚無使UE正確識別應用提供商和運營商的協作關系等技術問題，從而使得UE根據獲取的應用提供商和運營商的協作關系對QOS進行正確處理（更新）。
【專利說明】服務質量的更新處理方法及裝置
【技術領域】
[0001]本發明涉及通信領域,具體而言,涉及一種服務質量(Quality of Service,簡稱為QoS)的更新處理方法及裝置。
【背景技術】
[0002]圖1 為第三代合作伙伴計劃(3rd Generation Partnership Project,簡稱為3GPP)演進分組系統結構示意圖，如圖1所示，3GPP演進分組系統(Evolved PacketSystem,簡稱為EPS)由演進的通用移動通信系統陸地無線接入網(Evolved UniversalTerrestrial Radio Access Network,簡稱為 E-UTRAN)、移動管理單兀(MobilityManagement Entity,簡稱為MME)、服務網關(Serving Gateway,簡稱為S-GW)、分組數據網絡網關(Packet Data Network Gateway,簡稱為 F1DN GW 或 P-GW)、歸屬用戶服務器(HomeSubscriber Server,簡稱為 HSS)、3GPP 的認證授權計費(Authentication、Authorizationand Accounting,簡稱為AAA)服務器、策略和計費規則功能實體(Policy and ChargingRules Function，簡稱為PCRF)及其它支撐節點組成。
[0003]其中，MME用于移動性管理、非接入層信令的處理和用戶移動管理上下文的管理等控制面相關工作；S_GW是與E-UTRAN相連的接入網關設備，在E-UTRAN與P-GW之間轉發數據，并且用于對尋呼等待數據進行緩存；P_GW則是EPS與PDN的邊界網關，用于PDN的接入及在EPS與TON間轉發數據等功能。
[0004]EPS支持與非3GPP系統的互通。與非3GPP系統的互通通過S2a、S2b、S2c接口實現，P-GW作為3GPP系統與非3GPP系統之間的錨點。其中，非3GPP系統被分為可信任非3GPP接入系統和不可信任非3GPP接入系統。可信任非3GPP接入系統可以直接通過S2a接口與P-GW連接；不可信任非3GPP接入系統需經過演進的分組數據網關(Evolved PacketData Gateway，簡稱為ePDG)與P-GW相連，ePDG與P-GW之間為S2b接口。S2c接口提供了用戶設備(User Equipment，簡稱為UE)與P-GW之間用戶面相關的控制和移動性支持，支持的移動性管理協議為支持雙棧的移動IPv6(Moblie IPv6 support for dual stack Hostsand Routers,簡稱為 DSMIPv6)。
[0005]EPS系統引入策略計費控制(Policy and Charging Control,簡稱為PCC)功能框架對用戶的業務訪問進行動態的策略計費控制。圖2為Rel-1l中非漫游場景下的PCC結構示意圖，如圖2所示,應用功能實體(Application Function,簡稱為AF)用于提供業務應用的接入點，這些業務應用所使用的網絡資源需要進行動態的策略控制。在業務面進行參數協商時，AF將相關業務信息傳遞給PCRF。如果這些業務信息與PCRF的策略相一致，則PCRF接受該協商；否則，PCRF拒絕該協商，并在反饋時給出PCRF可接受的業務參數。隨后，AF可將這些參數返回給用戶設備(User Equipment，簡稱為UE)。其中，AF和PCRF之間的接口是Rx接口。
[0006]PCRF是PCC的核心，負責策略決策和計費規則的制定。PCRF提供了基于業務數據流的網絡控制規則，這些網絡控制包括業務數據流的檢測、門控(Gating Control), QoS控制以及基于數據流的計費規則等。PCRF將其制定的策略和計費規則發送給策略和計費執行功能實體(Policy and Control Enforcement Function,簡稱為 PCEF)執行；同時，PCRF還需要保證這些規則和用戶的簽約信息一致。PCRF制定策略和計費規則的依據包括:從AF獲取與業務相關的信息、從用戶簽約數據庫(Subscription Profile Repository,簡稱為SPR)獲取與用戶策略計費控制相關的簽約信息、通過Gx接口從PCEF獲取的與承載相關網絡的信息。
[0007]PCEF通常位于網關(Gate-Way，簡稱為GW)內，在承載面執行PCRF所制定的策略和計費規則。PCEF按照PCRF所發送的規則中的業務數據流過濾器對業務數據流進行檢測，進而對這些業務數據流執行PCRF所制定的策略和計費規則。在承載建立時，PCEF按照PCRF發送的規則進行QoS授權，并根據AF的執行進行門控控制。同時，PCEF根據PCRF訂閱的事件觸發上報承載網絡上發生的事件。根據PCRF發送的計費規則，PCEF執行相應的業務數據流計費操作，計費既可以是在線計費，也可以是離線計費。如果是在線計費，則PCEF需要和在線計費系統(Online Charging System,簡稱為0CS)—起進行信用管理。離線計費時，PCEF和離線計費系統(Offline Charging System，簡稱為0FCS)之間交換相關的計費信息。PCEF與PCRF之間的接口是Gx接口，與OCS之間的接口是Gy接口，與OFCS之間的接口是Gz接口。PCEF —般都位于網絡的網關上，如EPS的分組數據網絡網關(PDN-Gff ),通用無線分組業務(General Packet Radio Service,簡稱為GPRS)中的網關通用分組無線業務支持節點(Gateway General Packet Radio Service Supporting Node,簡稱為 GGSN)以及互聯無線網局域網(Interworking WLAN,簡稱為1-WLAN)中的分組數據網關(Packet DataGateway,簡稱為 F1DGX
[0008]承載綁定和事件報告功能實體(Bearer Binding and Event ReportingFunction,簡稱為BBERF)通常位于接入網網關(Access Network Gateway,簡稱為ANG)內。如當用戶設備通過E-UTRAN接入EPS、服務網關S-GW與P-GW之間采用代理移動互聯網協議版本 6 (Proxy Mobile Internet Protocol version 6,簡稱為 PMIPv6)協議時，S-GW 中就存在BBERF。當用戶設備通過可信任非3GPP接入網接入時，可信任非3GPP接入網關中也存在 BBERF。
[0009]SPR存儲了與策略控制和計費相關的用戶策略計費控制簽約信息。SPR和PCRF之間的接口是Sp接口。
[0010]在線計費系統(Online Charging System,簡稱為0CS)和PCEF—起進行在線計費方式下用戶信用的控制和管理。
[0011]離線計費系統(Offline Charging System,簡稱為0FCS)與PCEF —起完成離線計費方式下的計費操作。
[0012]OCS和PCRF之間的接口是Sy接口，該接口上的計費策略會話用于傳送計費相關信息。PCRF從OCS獲取計費相關信息，作為制定PCC/QoS規則的依據信息之一。OCS檢測到授權配額(例如用量閾值)到達后，可向PCRF發起計費策略報告，觸發PCRF發起會話修改流程，更新相關規則。
[0013]以上PCC架構通過各功能實體實現了對UE為訪問一個分組數據網絡(PacketData Network,簡稱為 PDN)所建立的 IP連接接入網(IP Connectivity Access Network,簡稱為IP-CAN)會話的策略計費控制。一個IP-CAN會話的策略計費控制信息只由一個PCRF決定。
[0014]移動運營商使用EPS系統和第三方數據應用提供商的交互(Interworkingbetween Mobile Operators using the Evolved Packet System and Data ApplicationProviders,簡稱MOSAP)的功能框架引入了基于通用引導架構(Generic BootstrappingArchitecture，簡稱為GBA^POpen ID的安全機制，除了圖2中的PCC架構，引入了 GBA作為移動運營商對第三方應用提供商的鑒權和認證，來為UE提供相關應用業務。圖3為R12中非漫游場景下的第三方擁有數據應用提供商的結構示意圖。如圖3所示，Non-1MS AS為第三方應用服務器，類似于AF，可和PCRF交互提供相應的業務QoS信息，和HSS交互獲取相關的用戶簽約信息。GBA(包括 Bootstrapping Server Function-BSF,Network ApplicationFunction-NAF和SLF)旨在描述在移動的上下文環境中使用基于3GPP的AKA機制為客戶端(UE)和應用服務器(non-MSAS)提供共享密鑰，隨后該共享秘密能用于認證客戶(UE)和應用程序服務器(non-MSAS)之間的通信。這里GBA用于支持UE和RP之間的安全通信。引導服務功能(Bootstrapping Server Function,簡稱為BSF)為運用商的網內的功能實體，GBA所有的用戶安全設置(⑶SS)都存儲在HSS中，BSF通過與HSS之間的接口(Zh)獲得用戶安全信息和認證信息。UE和BSF之間通過認證機制在BSF和UE之間產生一個會話密鑰(Ks),網絡應用功能(Net Application Function,簡稱為NAF)負責業務控制，能從BSF獲得該會話密鑰，通過這種方式，NAF和UE就能擁有一個共享密鑰，該共享密鑰能為隨后的應用提供安全保護，特別是在應用會話開始時認證UE和NAF。因此運營商可以完成相關鑒權和認證，為簽約用戶提供第三方應用業務。
[0015]Open ID是實現全網統一 認證的解決方案:當終端用戶UE登錄一個支持Open ID的網站，即依賴方(Relying Party，簡稱為RP)時，與在該網站進行用戶登錄方式不同(該終端用戶也許沒有在該網站注冊過)，該用戶選擇了以Open ID的方式登錄該網站。Open ID是該用戶在另一個網站，即帳號提供方(OpenID Provider，簡稱為0P)，注冊的一個統一資源定位符(Uniform Resource Locator,簡稱為URL)。RP就會根據用戶提供的Open ID去發現0P，然后請求該OP對該用戶身份進行鑒權。OP收到RP請求后，會要求用戶登錄OP認證頁面進行鑒權，鑒權后，OP會提醒該用戶是否容許外部網站對其鑒權。用戶同意后，OP將鑒權結果返回給依賴方RP ;這里的OP鑒權采用了 GBA的引導模式，OP等效于GBA架構中的NAF。
[0016]現有技術中，UE建立到某個I3DN的IP-CAN會話后，網絡按相應授權的QoS為其業務提供數據傳輸需要的網絡資源，業務過程中可根據需要更改其QoS。對于MS類業務，則AF將提供新的QoS信息給PCRF，PCRF發起IP-CAN會話的修改流程。PCRF結合AF新請求的QoS以及SPR/UDC相應簽約數據，底層網絡承載資源信息等重新授權并下發新的PCC/QoS規則給PCEF/BBERF，PCEF/BBERF更新相應規則并修改承載資源，為該業務提供新的QoS。對于非MS類業務(例如圖3中的non-MS AS提供的業務)，運營商可以根據自身需求來部署網絡，自定義非MS類業務平臺和數據中心，通過自定義接口來觸發其PCRF發起IP-CANsession修改流程來更改QoS。若該類業務不是運營商自有的業務平臺提供，則運營商可以和該類業務提供商簽訂私有協議，來通過自定義接口觸發其PCRF發起IP-CANsession修改流程來更改QoS。
[0017]目前網絡第三方應用提供商的數量和種類越來越多，運營商自有業務已經遠遠不能滿足用戶的業務需求，運營商和部分應用業務提供商之間建立合作關系(該場景下non-1MS AS和PCRF之間存在Rx接口)，為用戶的應用業務提供良好的服務質量和應用體驗，從中收取其應有的提供網絡傳輸資源的應得利潤。但運營商不可能做到和所有應用提供商具備商業協作關系(該場景下non-MS AS和PCRF之間沒有Rx接口)。對于和運營商不具有協作關系的第三方應用提供商的業務(non-MS AS和PCRF之間沒有Rx接口)，運營商提供默認的QoS，但用戶可發起請求通過支付額外的費用來獲取該業務的高QoS。
[0018]這種和運營商不具有協作關系的第三方應用提供商分為兩類,第一類和運營商沒有任何商業關系也沒有任何業務協作，第二類和運營商有商業關系但沒有任何業務協作。針對第一類第三方應用提供商，用戶只能向運營商發起提升該業務的QoS請求，由運營商觸發修改該業務的相關承載資源以滿足用戶的需求，并承擔該高QoS的額外計費。針對第二類的第三方應用提供商，用戶可向第三方應用提供商發起提升該業務的QoS請求，由第三方應用提供商觸發運營商修改該業務的相關承載資源以滿足用戶的需求，并由第三方應用提供商提供該高QoS額外計費的話單，也可以像第一類一樣直接和運營商發起提升請求。
[0019]相關技術中，對于第一類和運營商沒有任何商業關系也沒有任何業務協作的場景，當UE需要提升QoS時，UE可以通過承載資源修改流程通知GW，觸發PCRF發起IP-CAN會話修改，對該業務的QoS重授權；也可以由UE直接通知運營商的AF相關的業務和QoS提升請求，觸發PCRF發起上述流程。對于第二類和運營商有商業關系但沒有任何業務協作的場景，UE可以通知DAP提升請求，由DAP和運營商的PCRF交互，觸發上述流程；也可以由UE直接和運營商觸發提升QoS，包括上述的承載資源修改流程觸發或AF觸發。但實際運營網絡中會同時存在以上兩類場景，UE需要根據不同場景作出相應的處理。
[0020]因此，UE如何正確區分這兩類場景并根據需求作出正確的選擇，成為必須解決的關鍵問題。
[0021]歸納以上問題可以看出，針對網絡中存在第三方應用提供商提供的業務，且第三方應用提供商和運營商不存在業務協作時，如何使UE能夠根據運營商或UE對于相關業務的QoS處理的需求做出正確處理，是需要解決的問題。
[0022]針對相關技術中的上述問題，目前尚未提出有效的解決方案。

【發明內容】

[0023]針對相關技術中，在第三方應用提供商和運營商不存在業務協作時，尚無使UE正確識別應用提供商和運營商的協作關系等技術問題，本發明提供了一種服務質量的更新處理方法及裝置，以至少解決上述問題。
[0024]根據本發明的一個方面，提供了一種服務質量的更新處理方法，包括:用戶設備(UE)獲取應用提供商和運營商的協作關系;UE根據獲取的協作關系請求服務質量QoS更新。
[0025]上述協作關系，包括以下之一:應用提供商和運營商存在業務協作；應用提供商和運營商不存在業務協作和商業關系；應用提供商和運營商僅存在商業關系但無業務協作。
[0026]UE根據獲取的協作關系請求QoS更新，包括:在應用提供商和運營商不存在業務協作和商業關系時，UE直接向運營商發起請求,請求運營商對QoS進行更新處理。
[0027]UE根據獲取的協作關系請求QoS更新，包括:在應用提供商和運營商僅存在商業關系但無業務協作時，UE根據協作關系采用以下方式之一發起對QoS的更新流程-M直接向運營商發起請求，觸發運營商進行對QoS進行更新處理；UE經由應用提供商發起請求觸發運營商對QoS進行更新處理。
[0028]UE獲取應用提供商和運營商的協作關系，包括:UE接收來自于應用提供商發送的協作關系；或者UE接收來自于運營商發送的協作關系。
[0029]UE接收來自于運營商發送的協作關系，包括:UE從運營商的應用功能AF實體發送的應用層信令或協議中獲取協作關系；或者UE從運營商的承載層信令中獲取協作關系。
[0030]根據本發明的另一個方面，提供了一種服務質量的更新處理裝置，位于UE中，該裝置包括:獲取模塊，用于獲取應用提供商和運營商的協作關系；請求模塊，用于根據獲取的協作關系請求服務質量QoS更新。
[0031]上述獲取模塊用于獲取以下之一協作關系:應用提供商和運營商存在業務協作；應用提供商和運營商不存在業務協作和商業關系；應用提供商和運營商僅存在商業關系但無業務協作。
[0032]上述請求模塊，用于在應用提供商和運營商不存在業務協作和商業關系時，直接向運營商發起請求，請求運營商進行對QoS進行更新處理。
[0033]上述請求模塊，用于在應用提供商和運營商僅存在商業關系但無業務協作時，根據協作關系采用以下方式之一發起對QoS的更新流程:直接向運營商發起請求，觸發運營商對QoS進行更新處理；經由應用提供商發起請求觸發運營商對QoS進行更新處理。
[0034]上述獲取模塊，用于接收來自于應用提供商發送的協作關系；或者接收來自于運營商發送的協作關系。
[0035]通過本發明，采用UE獲取應用提供商和運營商的協作關系的技術手段，解決了相關技術中，對用戶的多徑信息進行管理耗費較多硬件內部緩存空間在第三方應用提供商和運營商不存在業務協作時，尚無使UE正確識別應用提供商和運營商的協作關系等技術問題，從而使得UE根據獲取的應用提供商和運營商的協作關系對QOS進行正確處理(更新)。
【專利附圖】

【附圖說明】
[0036]此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，本發明的示意性實施例及其說明用于解釋本發明，并不構成對本發明的不當限定。在附圖中:
[0037]圖1為根據相關技術的3GPP演進分組系統結構示意圖；
[0038]圖2為根據相關技術的Rel-1l非漫游場景下的PCC結構示意圖；
[0039]圖3為根據相關技術的Rel-12非漫游場景下的MOSAP結構示意圖；
[0040]圖4為根據本發明實施例1的服務質量的更新處理方法的流程圖；
[0041]圖5為根據本發明實施例1的服務質量的更新處理裝置的結構框圖；
[0042]圖6為根據本發明實施例2的服務質量的更新方法的第一流程圖；
[0043]圖7為本發明實施例2的服務質量的更新方法的第二流程圖；
[0044]圖8為本發明實施例2服務質量的更新方法的第三流程圖；
[0045]圖9為根據本發明實施例3的服務質量的更新方法的第一流程圖；[0046]圖10為本發明實施例3的服務質量的更新方法的第二流程圖；
[0047]圖11為本發明實施例3服務質量的更新方法的第三流程圖。
【具體實施方式】
[0048]下文中將參考附圖并結合實施例來詳細說明本發明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。
[0049]考慮到相關技術中，應用提供商和運營商在不具有協作關系的兩種場景(即第一類和運營商沒有任何商業關系也沒有任何業務協作,第二類和運營商有商業關系但沒有任何業務協作)下，尚無使UE如何正確區分這兩類場景并根據需求作出正確的選擇等問題。以下結合實施例提供了相關的解決方案，現詳細說明。
[0050]實施例1
[0051]圖4為根據本發明實施例1的服務質量的更新處理方法的流程圖。如圖4所示，該方法包括:
[0052]步驟S402，UE獲取應用提供商和運營商的協作關系；
[0053]步驟S404，UE根據獲取的協作關系請求QoS更新。
[0054]無論對于運營商和應用提供商是否存在業務協作，均可以通過上述處理步驟使UE感知運營商和應用提供商的協作關系，尤其是在運營商和應用提供商不存在業務協作的情況下，可以使UE對兩者的具體協作情況進行感知，從而UE如何正確區分這兩類場景并根據需求作出正確的選擇，例如，對于相關技術中的第一類場景只能由運營商觸發QoS提升，對于相關技術中的第二類場景可以根據運營商策略或用戶的傾向，作出相應的觸發選擇。
[0055]在步驟S404，對QoS進行更新處理的實現過程由于可以在相關技術中查詢得知，此處不再贅述。
[0056]上述協作關系可以包括以下情況之一:應用提供商和運營商存在業務協作；應用提供商和運營商不存在業務協作和商業關系；應用提供商和運營商僅存在商業關系但無業務協作。
[0057]針對上述協作關系的幾種情況，步驟S404更新處理過程也略有不同:在應用提供商和運營商不存在業務協作和商業關系時，UE直接向運營商發起請求,請求運營商進行對QoS進行更新處理。在應用提供商和運營商僅存在商業關系但無業務協作時，UE根據協作關系按照采用以下方式之一發起對QoS的更新流程:第一種方式，UE直接向運營商發起請求，觸發運營商進行對QoS進行更新處理；第二種方式，UE經由應用提供商發起請求觸發運營商對QoS進行更新處理。
[0058]其中，對于應用提供商和運營商存在業務協作的情況，則可以采用第一種方式或第二種方式對QoS更新處理。
[0059]可以根據預定策略選擇采用哪種處理方式:運營商默認第一種方式或第二種方式；設置第一種方式和第二種方式的優先級；響應于用戶的選擇操作，從預先配置的所述第一種方式和所述第二種方式中選擇一種方式；根據QoS的資費歸屬方不同確定選擇所述第一種方式或所述第二種方式，例如可結合該業務的計費策略來決定，例如特殊QoS的資費歸屬應用提供商話單則選擇第二種方式，特殊QOS的資費歸屬運營商話單則選擇第一種方式。[0060]UE獲取應用提供商和運營商的協作關系的方式有多種，例如:可以通過UE接收來自于應用提供商發送的協作關系；或者通過UE接收來自于運營商發送的協作關系獲取。
[0061]對于UE通過接收來自于運營商發送的協作關系的獲取方式，可以采用以下處理過程實現:UE從運營商的應用功能AF實體發送的應用層信令或協議中獲取協作關系；或者UE從運營商的承載層信令中獲取協作關系。上述處理過程的具體實現方式可以參見實施例2和實施例3的描述，此處不再贅述。
[0062]在本實施例中還提供了一種服務質量的更新處理裝置，該裝置位于UE中，用于實現上述實施例及優選實施方式，已經進行過說明的不再贅述，下面對該裝置中涉及到的模塊進行說明。如以下所使用的，術語“模塊”可以實現預定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現，但是硬件，或者軟件和硬件的組合的實現也是可能并被構想的。圖5為根據本發明實施例1的服務質量的更新處理裝置的結構框圖。如圖5所示，該裝置包括:
[0063]獲取模塊50，連接至請求模塊52，用于獲取應用提供商和運營商的協作關系；
[0064]請求模塊52，根據獲取的協作關系請求QoS更新。
[0065]通過上述處理模塊所實現的功能，同樣可以使UE感知運營商和應用提供商的協作關系，尤其是在運營商和應用提供商不存在業務協作的情況下，可以使UE對兩者的具體協作情況進行感知，從而UE如何正確區分這兩類場景并根據需求作出正確的選擇，例如，對于相關技術中的第一類場景只能由運營商觸發QoS提升，對于相關技術中的第二類場景可以根據運營商策略或用戶的傾向，作出相應的觸發選擇。
[0066]優選地，上述獲取模塊50用于獲取以下之一協作關系:應用提供商和運營商存在業務協作；應用提供商和運營商不存在業務協作和商業關系；應用提供商和運營商僅存在商業關系但無業務協作。
[0067]上述請求模塊52，用于在應用提供商和運營商不存在業務協作和商業關系時，直接向運營商發起請求，觸發運營商進行對QoS進行更新處理。
[0068]在本實施例中，請求模塊52，還用于在應用提供商和運營商僅存在商業關系但無業務協作時，根據協作關系采用以下方式之一發起對QoS的更新流程:直接向運營商發起請求，請求運營商進行對QoS進行更新處理；經由應用提供商發起請求觸發運營商對QoS進行更新處理。
[0069]在本實施例中，獲取模塊50，用于接收來自于應用提供商發送的協作關系；或者接收來自于運營商發送的協作關系。
[0070]為了更好地理解實施例1，以下結合實施例2和實施例3詳細說明，以下所述實施例涉及EPS中UE感知協作關系更新QoS的方案，目的在于，UE對于運營商和第三方業務提供商的協作關系的感知和判斷，以及根據需求正確觸發業務QoS提升，以下實施例的主要設計思想在于，UE感知應用提供商和運營商的協作關系，并根據運營商策略或用戶的選擇來觸發優先流處理(即QoS提升)。其中，UE可以通過第三方數據應用提供商(Dataapplication provider,簡稱為DAP)感知應用提供商和運營商的協作關系,還可以通過移動運營商感知應用提供商和運營商的協作關系。對于后一種情況，即UE通過移動運營商感知包括:通過運營商應用功能的應用層信令應用提供商和運營商的協作關系；通過運營商的承載層信令感知提供商和運營商的協作關系。所述運營商策略或用戶的選擇包括:1)UE向移動運營商發起請求，運營商進行優先流處理；2)UE向第三方應用提供商發起請求,第三方應用提供商請求運營商進行優先流處理。
[0071]實施例2
[0072]本實施例基于圖3的MOSAP架構基礎上提供一種UE通過第三方應用提供商DAP感知應用提供商和運營商的協作關系，并根據運營商策略或用戶的選擇來觸發QoS提升的方法和系統，來實現用戶根據其需求觸發的優先流處理。
[0073]本實施例描述的UE使用和運營商不具有協作關系的第三方應用提供商的業務，該第三方應用提供商和運營商沒有任何商業關系也沒有任何業務協作。運營商負責為UE的第三方應用提供傳輸資源，UE向運營商發起優先流處理請求，由運營商處理相關QoS的更新。
[0074]IP-CAN會話創建后，第三方應用提供商根據其協作運營商的簽約信息、UE ID和PLMNID等信息判斷其與UE歸屬運營商的協作關系，并將其告知UE相應的API。UE接收并存儲該第三方應用提供商發送的其與運營商的該協作關系。當用戶不滿意當前業務的QoS，發起優先流處理請求時，UE根據當前的DAP與移動運營商(Mobile Operators,簡稱為MO)的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為當DAP和MO既無商業關系也無業務協作時直接由UE請求MO發起優先流處理請求。根據運營商網絡部署,UE可通過承載資源修改流程發起該QoS更新，也可以通過運營商自有的AF觸發PCRF發起該QoS更新。
[0075](一)
[0076]在圖6所示流程中，網絡部署中運營商自有AF功能(可以為新增邏輯功能，可以獨立部署，或集成在其它網元中。可以為運營商自有應用平臺，也可以是和NAF或OP結合的具備AF功能的proxy網元，也可以集成在現有網元中，例如PCRF中)，支持UE和AF的接口(可以采用http協議或者其它應用層信令)，若AF在PCRF之外，則支持AF和PCRF的接口(這里為Rx接口，可采用Diameter協議通信)。如圖6所示,該流程包括:
[0077]步驟S601:UE附著到歸屬地網絡，建立無線承載和創建IP-CAN session ；
[0078]步驟S602:UE登陸并成功訪問Non-MS AS,這里UE和Non-MS AS使用application level signaling 或 HTTP 協議，non-1MS AS 為 UE 提供應用業務；Non-1MS AS一并向運 UE 提供 Service ID/application ID,以及 flow information 相關信息；
[0079]步驟S603:完成該業務所需承載的創建；PCRF根據AS，SPR/UDC，PGff等client端發送的相關信息制定PCC/QoS規則，并下發到PCEF/BBERF;PCEF/BBERF安裝并執行相關規則，完成承載綁定，若沒有匹配承載則下發承載建立請求，創建承載；PCRF下發規則的同時，還可能攜帶相關event trigger,以及用量監控閾值,監控關鍵字等其它信息；PCEF收到信息后設置和執行相關事件報告及用量監控功能；
[0080]步驟S604:該業務承載創建完成，網絡按授權QoS為UE提供該業務數據的下行傳輸;
[0081]步驟S605:non-1MS AS根據其協作運營商的簽約信息，UE ID和PLMN ID等信息，判斷斷其與UE歸屬運營商或的協作關系，并將該協作關系通知給UE。UE接收并存儲該non-MSAS發送的其與運營商的該協作關系。該交互信令可以為應用層信令或http等應用協議。該協作指示告知UE該應用提供商的該項業務與運營商的協作關系，例如協作、非協作(包括具備商業關系但無業務協作，既無商業關系也無業務協作這兩種場景)關系。本發明旨在告知UE其雙反的協作關系，其告知形式不限于以上所述方式。該協作關系通知可以為單獨的信令或消息，也可以包含在UE和AS的其它信令或消息中傳送，例如步驟S601。該協作關系的指示，可在non-1MS AS獲取后的任何時候通知,不限于步驟S604之后；
[0082]步驟S606:業務過程中，UE發現服務質量QoS或用戶體驗不滿意(例如，由于移動性或網絡狀況導致數據流傳輸不穩定或帶寬太低等)，UE發起優先流處理請求。UE根據當前的應用提供商與運營商的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為:當兩者既無商業關系業務協作時，直接由UE請求運營商發起優先流處理請求。根據運營商網絡部署，UE可通過承載資源修改流程發起該QoS更新，也可以通過運營商自有的AF觸發PCRF發起該QoS更新。這里UE通過運營商自有的AF觸發。
[0083]UE發送請求消息給AF (部署中可以為類似NAF或non-MS AS或RP等應用平臺或集成在現有網元中)；UE的該請求消息中攜帶UEIP/ID,優先流處理指示/QoS,及flowinformation,以及如果有可能還會攜帶Service ID/Application ID;(這里UE和AF的通信協議不作限定，http或應用層信令均可實現)；
[0084]具體實現中，除了以上顯式地通知UE外，還可存在例如當兩者不存在商業關系也不存在業務協作時不會發送任何指示給UE，而UE默認無通知為非協作關系等實現方式。本發明旨在UE能正確判斷網絡或應用提供商兩者的協作關系，對于感知方式的具體實現不做限定，下同。
[0085]步驟S607:AF收到UE的請求消息后，關聯UE Id/IP和所需提升QoS的service/application,發送CCR請求消息給PCRF,請求發起會話修改update QoS ;這里AF作為PCRF的diameter client端,可獨立或集成于其它網元實體中部署。請求消息中攜帶UE ID/IP,優先流處理指不/QoS,及 flow information,以及可能還有 service ID/application ID;
[0086]步驟S608 =PCRF收到該AF的請求消息后，查詢SPR/UDC該用戶/業務/應用是否簽約了高優先流處理，若簽約允許則根據請求發起會話修改流程；制定下發更新后的PCC規則給 PCEF/BBERF，orADC 規則給 TDF。PCEF/BBERF/TDF 更新 PCC/QoS/ADC 規則，修改或新建承載，執行update后的QoS和相關承載的綁定。并發送響應消息給PCRF，反饋規則執行結果;
[0087]PCRF返回提升QoS修改響應消息CCA給該AF，告知修改是否被接受，如果被拒絕，攜帶相關cause ；
[0088]步驟S609:若update QoS授權成功，則AF給UE發送更新QoS確認請求消息，要求用戶確認是否滿意更新后的QoS，如果滿意則在預覽時間段內返回肯定的確認消息(確認接受更新后的QoS后，用戶需要為此優先流處理提供額外資費)；如果不滿意或不同意支付額外的優先流處理費用，則返回否定的確認或不進行確認(若用戶不進行確認，則終端設備可能會構建否定確認返回給網絡，便于技術實現中區分用戶沒有發送確認和確認消息丟失的異常情形，AF上也可設置timer某人拒絕或接受流程的除服。但具體處理根據運營商網絡實現處理);該處理流程，AF可在發送請求St印S607中設置QoS提升定時器Timerl，在收到PCRF的CCA確認消息且Timerl Time out之后(Timerl有效期應能保證正常的PCRF發起的IP-CANsession modification更新QoS處理完畢且已經按新的QoS為UE提供應用業務)，AF則向UE發送確認請求消息。發送該請求消息后AF可開啟用戶確認定時器Timer2。[0089]步驟S610:UE收到該AF的確認消息后，若對更新(例如提升)后的業務數據流滿意且愿意支付優先流處理的費用，則對該消息進行確認，UE將會發送給確認消息給該AF。該AF收到UE的確認響應后,可選地返回確認response消息給PCRF,運營商將對該業務繼續提供update之后的QoS (例如，繼續進行優先流處理，提供高優先級或高帶寬資源)。PCRF將發起IP-CAN會話修改流程(同StepS608),下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費)。
[0090]若UE對提升后的業務數據流的服務質量或用戶體驗不滿意和或不愿意支付額外的優先處理費用，則用戶不對該確認請求進行確認(不返回響應消息)或返回否定確認消息給此AF (即如果用戶不同意執行新的服務質量提供該業務但未作否定確認，則終端設備根據運營商需求可選地構建否定確認消息發送給AF),執行stepS610a_c ；
[0091]步驟S610a:若AF在規定時間內(例如timer2 timeout)沒有收到用戶的確認接收消息，或收到了用戶的確認拒絕消息，則AF將發送更新QoS請求(例如，downgrade QoS)給 PCRF ；
[0092]步驟S610b:PCRF收到AF的downgrade QoS請求消息后，結合簽約信息及本地策略(例如用戶確認接收UpdateQoS的Preview timer超時則需要回復原先QoS),發起IP-CAN/Gffcontrol/TDF會話修改流程，更新相關PCC/QoS/ADC規則，恢復該業務的原先QoS ；
[0093]步驟S610c:在QoS恢復處理完成后或提升QoS確認時間超時后，網絡對該業務數據流的處理將恢復到UE請求提升之前的QoS (QoS回退機制不在本發明的限定范圍內，可采用例如網元間的timer機制處理會話修改的回退時間，可本地存儲update之前的QoS,或者Trigger node發送downgrade QoS請求消息時攜帶此前的QoS信息,或者請求消息中攜帶使用默認QoS指示等)。
[0094]以上流程中除了策略控制，還存在計費相關處理流程，例如更新QoS后，新的PCC規則中可能下發新的計費關鍵字(對應新的計費費率)，可能存在PCRF、PCEF/BBERF/TDF等網元與計費網元0CS/0FCS以及其它計費系統的交互；該部分處理由于可以在相關技術中查詢得知，在此不再贅述。
[0095]經過圖6所示流程，可實現當運營商和應用提供商既無商業關系也無業務協作時，UE通過運營商感知其協作關系,直接請求運營商發起優先流處理請求,通過運營商自有的AF觸發PCRF發起該QoS更新，提升或降低服務質量/用戶體驗，變更運營商為該業務傳送的資源所對應的業務資費費率的處理流程。
[0096]( 二 )
[0097]對于該場景UE請求QoS更新，根據運營商網絡部署，UE還可以通過重用承載資源修改流程完成該QoS的更新。圖6所示流程中，UE通過第三方應用提供商感知協作關系，第三方應用提供商與移動運營商不具有商業關系也沒有業務協作，并且UE通過移動網絡運營商(Mobile network operator,簡稱為MNO)來發起QoS更新(QoSupdate)流程,通過承載資源修改流程，觸發” PCEF發起的會話修改流程”，更新Q0S。
[0098]如圖7所示，該流程包括:
[0099]步驟S701:如圖5中的步驟S501-S504，UE附著到網絡建立相關承載和會話，向Non-1MSAS請求了該業務，并創建完成相關的業務承載，網絡按授權QoS為UE提供該業務數據的下行傳輸；
[0100]步驟S702:non-1MS AS根據其協作運營商的簽約信息，UE ID和PLMN ID等信息，判斷斷其與UE歸屬運營商或的協作關系，并將該協作關系通知給UE。UE接收并存儲該non-MSAS發送的其與運營商的該協作關系。該交互信令可以為應用層信令或http等應用協議。該協作指示告知UE該應用提供商的該項業務與運營商的協作關系，例如協作、非協作(包括具備商業關系但無業務協作，既無商業關系也無業務協作這兩種場景)關系。本發明旨在告知UE其雙反的協作關系，其告知形式不限于以上所述方式。該協作關系通知可以為單獨的信令或消息，也可以包含在UE和AS的其它信令或消息中傳送。該協作關系的指示，可在non-MSAS獲取后的任何時候通知，不限于步驟S701結束之后；
[0101]步驟S703:業務過程中，UE發現服務質量QoS或用戶體驗不滿意(例如，由于移動性或網絡狀況導致數據流傳輸不穩定或帶寬太低等)，UE發起優先流處理請求。UE根據當前的應用提供商與運營商的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為:當兩者既無商業關系業務協作時，直接由UE請求運營商發起優先流處理請求。根據運營商網絡部署，UE可通過承載資源修改流程發起該QoS更新，也可以通過運營商自有的AF觸發PCRF發起該QoS更新。這里UE通過承載資源修改流程發起該QoS更新。
[0102]UE發送Request消息給MME,請求消息中攜帶請求的類型(更新QoS), UEIP/ID,承載ID (LBI)，flow information (例如流描述(TAD)，數據包過濾器ID (PTI)等)，QoS。若該業務/應用此前為GBR承載,則請求中可能攜帶packet filter identifier (s);以及如果有可能還會攜帶 Service ID/Application ID;
[0103]步驟S704:MME前轉發送request消息給SGW，消息中包括S703中的相關參數；
[0104]步驟S705 =SGff收到該消息后前轉該request消息給PGW，消息攜帶收到的具體參數；
[0105]步驟S706:PCEF根據收到的request消息參數,判斷需要更新QoS (例如根據攜帶了優先流處理或承載指示，或QoS更新指示,或該業務請求的QoS高于先的QoS等)，發起IP-CANsession modification流程處理,發送會話修改請求給PCRF觸發會話修改,如步驟309。消息中攜帶 UE IP/ID,請求的 QoS, flow information (例如 TAD,以及 SDF fileterID)等參數。
[0106]PCRF查詢SPR/UDC簽約信息(例如該用戶/業務/應用是否簽約了高優先流處理；若簽約允許則根據請求提升QoS)，更新PCC策略決策，下發更新后的PCC規則給PCEF/BBERF, or ADC規則給TDF/PCEF (如果存在應用流檢測功能)。這里若PCRF本地沒有簽約信息，則PCRF還需要向SPR/UDC/HSS等數據庫獲取相關簽約信息。PCEF/BBERF更新PCC/QoS規則，修改或新建承載滿足提升后的QoS。并反饋規則執行響應消息給PCRF，完成會話修改流程。
[0107]PGW執行QoS策略，完成承載修改和綁定，下發Update Bearer Request給SGW,SGff前傳到MME ；MME構建承載修改請求消息下發給eNodeB,帶上Bear ID, QoS; eNodeB映射EPS承載QoS到無線承載QoS下發RRL CR消息給UE’ UE更新存儲相關QoS ;逐級返回相關response消息直至給PGW，完成承載修改流程。這里具體涉及每個網元的消息及其參數等內容的詳細流程可參照3GPP TS 23.S701中的UE發起的承載資源修改描述。
[0108]步驟S707:若update QoS成功，貝U需要發送更新QoS確認請求消息給UE,要求用戶確認是否滿意更新后的QoS，如果滿意則UE返回肯定的確認消息(確認接受更新后的QoS需要為此優先流處理提供額外資費)；如果不滿意或不同意支付額外的優先流處理費用，則UE給網絡返回否定的確認或不進行確認(若用戶不進行確認，則終端設備可能會構建否定確認返回給網絡，便于技術實現中區分用戶沒有發送確認和確認消息丟失的異常情形，但具體處理根據運營商網絡實現處理)；
[0109]或者可以不由UE本身觸發感知，而由網絡側下發通知。在完成IP-CAN sessionmodification流程后，按更新后的QoS為該業務提供業務數據流；PGW/PCEF下發一個通知消息給UE，要求UE對更新后的QoS進行確認，該通知消息中攜帶確認指示，表示用戶請求的QoS更新完成，請求確認；SGW收到該通知消息后，下發該通知給MME，帶上UEID/IP，必要的業務流信息，以及該確認指示；MME將該消息下發給UE，UE收到該通知消息后將提供一個通知指示給上層(例如應用層)，觸發用戶感知；
[0110]步驟S708:用戶收到UE應用層的確認消息后，若對更新(例如提升)后的業務數據流滿意且愿意支付優先流處理的費用，則對在預覽時間段內對該消息進行確認，UE將會發送給肯定的確認消息給該網絡(在請求或通知相應中攜帶肯定的確認信息)，運營商將根據該確認對該業務繼續提供update之后的QoS (例如，繼續進行優先流處理，提供高優先級或高帶寬資源)。PCRF將發起IP-CAN會話修改流程(同St印309)，下發新的Charigng key(對該QoS下的業務執行相應的優先流特殊計費)。
[0111]若UE對提升后的業務數據流的服務質量或用戶體驗不滿意和或不愿意支付額外的優先處理費用，則用戶不對該確認請求進行確認(不返回確認響應消息)或返回否定確認消息給網絡(即如果用戶不同意執行新的服務質量提供該業務但未作否定確認，則終端設備根據運營商需求可選地構建否定確認消息發送給網絡，若User不確認則應用層則需要在等待確認的timer timeout之后觸發承載層構建否定確認消息發送給網絡，網絡將會在一定preview時間之后將QoS恢復到請求提升之前的水平；
[0112]步驟S709 =MME收到UE的請求或通知相應消息，給SGW前轉該消息，攜帶原消息中的參數，例如UE IP/ID，QoS,肯定或否定的確認信息/指示等；
[0113]步驟S710 =SGff前傳該消息到PGW，攜帶QoS和確認信息/指示等參數；
[0114]步驟S711:PGW根據確認信息/指示判斷用戶業務所需的QoS，若為肯定確認，則執行步驟S712。
[0115]若為否定確認則發送IP-CANsession modification請求給PCRF發起會話修改流程，downgrade QoS ；PCRF收到downgrade QoS請求消息后，結合簽約信息及本地策略(例如用戶確認接收UpdateQoS的Preview timer超時則需要回復原先QoS),發起IP-CAN/Gffcontrol/TDF會話修改流程，更新相關PCC/QoS/ADC規則，恢復該業務的原先QoS ;該IP-CAN session修改流程修改承載和會話，為該業務提供的QoS將恢復到用戶提升請求之前的水平，按原有的QoS繼續執行StepS7115提供下行業務數據流；(QoS回退機制不在本發明的限定范圍內，可采用例如網元間的timer機制處理會話修改的回退時間，可本地存儲update之前的QoS,或者UE發送downgrade QoS請求消息時攜帶此前的QoS信息,或者請求消息中攜帶使用默認QoS指示等)。
[0116]步驟S712-S714:如步驟S708 PCRF發起的IP-CAN會話修改流程下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費),提升或恢復QoS流程處理完畢。PGW確認UE用于發送確認通知發起的資源修改流程不需要執行(即QoS不需要變更)，則發送承載資源修改失敗指示來指示SGW，高QoS將繼續應用于該業務，不需要重新發起QoS修改流程，執行步驟S712-S714反饋該承載資源修改失敗指示。
[0117]步驟S715:若為步驟S711則在downgrade QoS完成后，按最初的QoS傳送下行數據；若為update QoS成功確認步驟S714，則按提升后的QoS傳送下行數據。S卩，網絡按授權的QoS為該業務繼續提供業務數據流。
[0118]經過上述流程，可實現當運營商和應用提供商既無商業關系也無業務協作時，UE直接請求運營商發起優先流處理請求，通過承載資源修改流程觸發PCRF發起IP-CAN會話修改，更新該業務的QoS，提升或降低服務質量/用戶體驗，變更運營商為該業務傳送的資源所對應的業務資費費率的處理流程。
[0119](三)
[0120]本實施例基于圖3的MOSAP架構基礎上提供一種UE通過第三方應用提供商DAP感知應用提供商和運營商的協作關系，并根據運營商策略或用戶的選擇來觸發QoS提升的方法和系統，來實現用戶根據其需求觸發的優先流處理。
[0121]本實施例描述的UE使用和運營商不具有協作關系的第三方應用提供商的業務，該第三方應用提供商和運營商具有商業關系但沒有任何業務協作。運營商負責為UE的第三方應用提供傳輸資源，UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求,觸發運營商修改會話更新Q0S。
[0122]IP-CAN會話創建后，第三方應用提供商根據其協作運營商的簽約信息、UE ID和PLMNID等信息判斷其與UE歸屬運營商的協作關系，并將其告知UE相應的API。UE接收并存儲該第三方應用提供商發送的其與運營商的該協作關系。當用戶不滿意當前業務的QoS，發起優先流處理請求時，UE根據當前的DAP與MO的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為當DAP和MO存在商業關系但無業務協作時，由UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求,觸發運營商修改會話更新QOS。
[0123]在圖8所示流程中，UE通過第三方應用提供商感知協作關系，第三方應用提供商和移動運營商之間具有商業關系但沒有業務協作，并且，UE通過運營商MNO來發起QoS更新(QoSupdate)，non-MS AS通知PCRF，觸發”PCEF發起的會話修改流程”，更新Q0S。該網絡部署中運營商和第三方業務提供商具有Rx接口，可傳送相關業務信息。但運營商不會替第三方業務提供商向用戶進行第三方業務的資費統計和計算。如圖8所示，該流程包括:
[0124]步驟S801:UE附著到歸屬地網絡，建立無線承載和創建IP-CAN session ；
[0125]步驟S802:UE登陸并成功訪問Non-MS AS,這里UE和Non-MS AS使用application level signaling 或 HTTP 協議，non-1MS AS 為 UE 提供應用業務；
[0126]步驟S803:Non_IMS AS 向運營商的PCRF提供UE ID/IP, Service ID/applicationID,以及flow information相關信息，發起Rx會話建立請求。PCRF向SPR/UDC獲取UE簽約信息和簽約AS信息，制定并下發PCC rule給PCEF，建立相關數據承載。由于該AS與運營商只有商業關系沒有業務合作，授權QoS為default bearer QoS ；
[0127]步驟S804:完成該業務所需承載的創建；PCRF根據AS，SPR/UDC，PGff等client端發送的相關信息制定PCC/QoS規則，并下發到PCEF/BBERF;PCEF/BBERF安裝并執行相關規則，完成承載綁定，若沒有匹配承載則下發承載建立請求，創建承載；PCRF下發規則的同時，還可能攜帶相關event trigger,以及用量監控閾值,監控關鍵字等其它信息；PCEF收到信息后設置和執行相關事件報告及用量監控功能；
[0128]步驟S805:該業務承載創建完成，網絡按授權QoS為UE提供該業務數據的下行傳輸;
[0129]步驟S806:non-1MS AS根據其協作運營商的簽約信息，UE ID和PLMN ID等信息，判斷斷其與UE歸屬運營商或的協作關系，并將該協作關系通知給UE。UE接收并存儲該non-MSAS發送的其與運營商的該協作關系。該交互信令可以為應用層信令或http等應用協議。該協作指示告知UE該應用提供商的該項業務與運營商的協作關系，例如協作、非協作(包括具備商業關系但無業務協作，既無商業關系也無業務協作這兩種場景)關系。本發明旨在告知UE其雙反的協作關系，其告知形式不限于以上所述方式。該協作關系通知可以為單獨的信令或消息，也可以包含在UE和AS的其它信令或消息中傳送，例如步驟S801。該協作關系的指示，可在non-1MS AS獲取后的任何時候通知，不限于步驟S805之后；
[0130]步驟S807:業務過程中，UE發現服務質量QoS或用戶體驗不滿意(例如，由于移動性或網絡狀況導致數據流傳輸不穩定或帶寬太低等)，UE發起優先流處理請求。UE根據當前的應用提供商與運營商的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為:當兩者具有商業關系但無業務協作時，由UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求,觸發運營商修改會話更新Q0S。
[0131]UE發送請求消息給non-MS AS，UE的該請求消息中攜帶UEIP/ID，優先流處理指不/QoS,及 flow information,以及如果有可能還會攜帶 Service ID/Application ID;
[0132]步驟S808:non-MS AS收到UE的請求消息后，關聯UE Id/IP和所需提升QoS的service/application,發送請求消息給PCRF,請求發起會話修改update QoS ;這里non-1MS AS作為PCRF的diameter client端，請求消息中攜帶UE ID/IP,優先流處理指示/QoS,及 flow information,以及可倉泛還有 service ID/application ID;
[0133]步驟S809 =PCRF收到該non_MS AS的請求消息后，查詢SPR/UDC該用戶/業務/應用是否簽約了高優先流處理(若本地沒有相關簽約信息則查詢SPR/UDC)，若簽約允許則根據請求發起會話修改流程；制定下發更新后的PCC規則給PCEF/BBERF，orADC規則給TDF0 PCEF/BBERF/TDF更新PCC/QoS/ADC規則，修改或新建承載，執行update后的QoS和相關承載的綁定。并發送響應消息給PCRF，反饋規則執行結果；
[0134]步驟S810:PCRF返回提升QoS修改響應消息給non-MS AS，告知修改是否被接受，如果被拒絕，攜帶相關cause ;該步驟需要AF在發送QoS更新請求時一并訂閱資源分配狀態等事件報告；
[0135]步驟S811:若update QoS更新成功，則non-1MS給UE發送更新QoS確認請求消息，要求用戶確認是否滿意更新后的QoS，如果滿意則在預覽時間段內返回肯定的確認消息(確認接受更新后的QoS后，用戶需要為此優先流處理提供額外資費);如果不滿意或不同意支付額外的優先流處理費用，則返回否定的確認或不進行確認(若用戶不進行確認，則終端設備可能會構建否定確認返回給網絡，便于技術實現中區分用戶沒有發送確認和確認消息丟失的異常情形，non-MS AS上也可設置timer作為拒絕或接受流程的時間窗口。但具體處理根據產品實現處理)。該步驟也可以由UE檢測到QoS更新成功即資源修改成功后，并且本地設置的預覽定時器超時，觸發API發送確認消息給用戶感知；
[0136]步驟S812:用戶收到non-MSAS的確認請求消息或底層UE觸發的確認請求消息后，若對更新(例如提升)后的業務數據流滿意且愿意支付優先流處理的費用，則對該消息進行確認，UE將會發送給確認響應消息給non-MS AS。
[0137]步驟S813:該non-1MS AS收到UE的確認響應后，可選地發送確認response消息給PCRF。若為接收更新后的高QoS確認，則運營商將對該業務繼續提供update之后的QoS (例如，繼續進行優先流處理，提供高優先級或高帶寬資源)。PCRF將發起IP-CAN會話修改流程，下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費)。
[0138]步驟S813a_c:若UE對提升后的業務數據流的服務質量或用戶體驗不滿意和或不愿意支付額外的優先處理費用，則用戶不對該確認請求進行確認(不返回響應消息)或返回否定確認消息給non-1MS AS(即如果用戶不同意執行新的服務質量提供該業務但未作否定確認，則終端設備根據運營商需求可選地構建否定確認消息發送給non-MS AS)，執行步驟 S813a-c ；
[0139]步驟S813a:若non-1MS AS在規定時間內(例如timer2 timeout)沒有收到用戶的確認接收消息，或收到了用戶的確認拒絕消息，則將發送更新QoS請求(例如，downgradeQoS)給 PCRF ；
[0140]步驟S813b:PCRF收到non-1MS AS的downgrade QoS請求消息后，結合簽約信息及本地策略(例如用戶確認接收UpdateQoS的Preview timer超時則需要回復原先QoS),發起IP-CAN/GWcontrol/TDF會話修改流程，更新相關PCC/QoS/ADC規則，恢復該業務的原先QoS ；
[0141]步驟S813c:在QoS恢復處理完成后或提升QoS確認時間超時后，網絡對該業務數據流的處理將恢復到UE請求提升之前的QoS (QoS回退機制不在本發明的限定范圍內，可采用例如網元間的timer機制處理會話修改的回退時間，可本地存儲update之前的QoS,或者AS發送downgrade QoS請求消息時攜帶此前的QoS信息,或者請求消息中攜帶使用默認QoS指不等)。
[0142]以上流程中除了策略控制，還存在計費相關處理流程，例如更新QoS后，新的PCC規則中可能下發新的計費關鍵字(對應新的計費費率)，可能存在PCRF、PCEF/BBERF/TDF等網元與計費網元0CS/0FCS以及其它計費系統的交互；該部分處理不在本發明的保護范圍之內，因此沒有本發明在此不作詳述；
[0143]以上流程中，當DAP和MO存在商業關系但無業務協作時，默認UE向DAP請求進而由DAP觸發MO發起優先流處理請求，但現網部署中也可支持直接由UE請求MO發起優先流處理請求，可由UE提供兩種處理機制選項供用戶選擇并根據其選擇發起流處理請求，或根據運營商策略默認其中一種處理機制，或默認兩種機制的優先級處理。具體根據現網部署需求和運營商策略決定。
[0144]針對本實施例的該流程，若運營商有自有AF功能或網元(例如應用平臺或集成在其它網元中的AF功能)，non-MS AS與PCRF的交互消息可能會發送給該運營商自有AF，前傳給PCRF處理，相關相應消息也可能經由AF轉發給第三方的non-MS AS。
[0145]經過上述流程，可實現當運營商和應用提供商存在商業關系但無業務協作時，UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求，觸發運營商修改會話更新QOS，提升或降低服務質量/用戶體驗，變更運營商為該業務傳送的資源所對應的業務資費費率的處理流程。
[0146]實施例3
[0147]本實施例基于圖3的MOSAP架構基礎上提供一種UE通過運營商感知應用提供商和運營商的協作關系，并根據運營商策略或用戶的選擇來觸發QoS提升的方法和系統，來實現用戶根據其需求觸發的優先流處理。
[0148]本實施例描述的UE使用和運營商不具有協作關系的第三方應用提供商的業務(該第三方應用提供商和運營商沒有任何商業關系也沒有任何業務協作，或具有商業關系但沒有業務協作)。運營商負責為UE的第三方應用提供傳輸資源，UE向運營商或第三方應用提供商發起優先流處理請求，由運營商處理相關QoS的更新。
[0149]IP-CAN會話創建后，運營商根據其簽約信息中的協作運營商的簽約list、第三方應用提供商的ID，業務/應用ID等信息判斷其與該第三方應用提供商的協作關系，并將其告知UE相應的API。UE接收并存儲運營商發送的其與應用提供商的該協作關系。當用戶不滿意當前業務的QoS，發起優先流處理請求時，UE根據當前的DAP與MO的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為當DAP和MO既無商業關系業務協作時直接由UE請求MO發起優先流處理請求。根據運營商網絡部署,UE可通過承載資源修改流程發起該QoS更新，也可以通過運營商自有的AF觸發PCRF發起該QoS更新。
[0150](一)
[0151]在圖9所示流程中，UE通過運營商感知協作關系，并且UE通過MNO來發起QoSupdate，通過運營商自有AF和PCRF交互，觸發會話修改更新Q0S。圖9所示流程中，UE使用和運營商不具有協作關系的第三方應用提供商的業務(該第三方應用提供商和運營商沒有任何商業關系也沒有任何業務協作)。運營商負責為UE的第三方應用提供傳輸資源，UE向運營商發起優先流處理請求，由運營商處理相關QoS的更新。
[0152]該網絡部署中運營商自有AF功能(可以為新增邏輯功能，可以獨立部署，或集成在其它網元中。可以為運營商自有應用平臺，也可以是和NAF或OP結合的具備AF功能的proxy網元，也可以集成在現有網元中，例如PCRF中)，支持UE和AF的接口(可以采用http協議或者其它應用層信令)，若AF在PCRF之外，則支持AF和PCRF的接口(這里為Rx接口，可采用Diameter協議通信)。采用自有AF功能，不但可以解決UE和PCRF沒有直接接口的問題，還可以解決IMS認為的UE提供的QoS和application信息不完全可信的問題，其可以被看作non-1MS AS和運營商網絡的proxy。如圖9所示,該流程包括:
[0153]步驟S901:UE附著到歸屬地網絡，建立無線承載和創建IP-CAN session ；
[0154]步驟S902:UE登陸并成功訪問Non-MS AS,這里UE和Non-MS AS使用application level signaling 或 HTTP 協議，non-1MS AS 為 UE 提供應用業務；Non-1MS AS一并向運 UE 提供 Service ID/application ID,以及 flow information 相關信息；
[0155]步驟S903:完成該業務所需承載的創建；PCRF根據AS，SPR/UDC，PGff等client端發送的相關信息制定PCC/QoS規則，并下發到PCEF/BBERF;PCEF/BBERF安裝并執行相關規則，完成承載綁定，若沒有匹配承載則下發承載建立請求，創建承載；PCRF下發規則的同時，還可能攜帶相關event trigger,以及用量監控閾值,監控關鍵字等其它信息；PCEF收到信息后設置和執行相關事件報告及用量監控功能；[0156]步驟S904:該業務承載創建完成，網絡按授權QoS為UE提供該業務數據的下行傳輸;
[0157]步驟S905:運營商根據其簽約信息中的協作運營商的簽約list、第三方應用提供商的ID，業務/應用ID等信息判斷其與該第三方應用提供商的協作關系，并將其告知UE相應的API。UE接收并存儲運營商發送的其與應用提供商的該協作關系。該交互信令可以為應用層信令或http等應用協議，該協作指示告知UE該應用提供商的該項業務與運營商的協作關系，例如協作、非協作(包括具備商業關系但無業務協作，既無商業關系也無業務協作這兩種場景)關系。本發明旨在告知UE其雙方的協作關系，其告知形式不限于以上所述方式。該協作關系通知可以為單獨的信令或消息，也可以包含在UE和運營商的其它信令或消息中傳送，例如步驟S901或S903中。該協作關系的指示，可在運營商獲取后的任何時候通知，不限于步驟S904之后；
[0158]步驟S906:業務過程中，UE發現服務質量QoS或用戶體驗不滿意(例如，由于移動性或網絡狀況導致數據流傳輸不穩定或帶寬太低等)，UE發起優先流處理請求。UE根據當前的應用提供商與運營商的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為:當兩者既無商業關系業務協作時，直接由UE請求運營商發起優先流處理請求。根據運營商網絡部署，UE可通過承載資源修改流程發起該QoS更新，也可以通過運營商自有的AF觸發PCRF發起該QoS更新。這里UE通過運營商自有的AF觸發。
[0159]UE發送請求消息給AF (部署中可以為類似NAF或non-MS AS或RP等應用平臺或集成在現有網元中)；UE的該請求消息中攜帶UEIP/ID,優先流處理指示/QoS,及flowinformation,以及如果有可能還會攜帶Service ID/Application ID;(這里UE和AF的通信協議不作限定，http或應用層信令均可實現)；
[0160]步驟S907:AF收到UE的請求消息后，關聯UE Id/IP和所需提升QoS的service/application,發送CCR請求消息給PCRF,請求發起會話修改update QoS ;這里AF作為PCRF的diameter client端,可獨立或集成于其它網元實體中部署。請求消息中攜帶UE ID/IP,優先流處理指不/QoS,及 flow information,以及可能還有 service ID/application ID;
[0161]步驟S908 =PCRF收到該AF的請求消息后，查詢SPR/UDC該用戶/業務/應用是否簽約了高優先流處理，若簽約允許則根據請求發起會話修改流程；制定下發更新后的PCC規則給 PCEF/BBERF，orADC 規則給 TDF。PCEF/BBERF/TDF 更新 PCC/QoS/ADC 規則，修改或新建承載，執行update后的QoS和相關承載的綁定。并發送響應消息給PCRF，反饋規則執行結果;
[0162]PCRF返回提升QoS修改響應消息CCA給該AF，告知修改是否被接受，如果被拒絕，攜帶相關cause ；
[0163]步驟S909:若update QoS授權成功，則AF給UE發送更新QoS確認請求消息，要求用戶確認是否滿意更新后的QoS，如果滿意則在預覽時間段內返回肯定的確認消息(確認接受更新后的QoS后，用戶需要為此優先流處理提供額外資費)；如果不滿意或不同意支付額外的優先流處理費用，則返回否定的確認或不進行確認(若用戶不進行確認，則終端設備可能會構建否定確認返回給網絡，便于技術實現中區分用戶沒有發送確認和確認消息丟失的異常情形，AF上也可設置timer某人拒絕或接受流程的除服。但具體處理根據運營商網絡實現處理);該處理流程，AF可在發送請求St印S907中設置QoS提升定時器Timerl，在收到PCRF的CCA確認消息且Timerl Time out之后(Timerl有效期應能保證正常的PCRF發起的IP-CANsession modification更新QoS處理完畢且已經按新的QoS為UE提供應用業務)，AF則向UE發送確認請求消息。發送該請求消息后AF可開啟用戶確認定時器Timer2。
[0164]步驟S910:UE收到該AF的確認消息后，若對更新(例如提升)后的業務數據流滿意且愿意支付優先流處理的費用，則對該消息進行確認，UE將會發送給確認消息給該AF。該AF收到UE的確認響應后,可選地返回確認response消息給PCRF,運營商將對該業務繼續提供update之后的QoS (例如，繼續進行優先流處理，提供高優先級或高帶寬資源)。PCRF將發起IP-CAN會話修改流程(同StepS908),下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費)。
[0165]若UE對提升后的業務數據流的服務質量或用戶體驗不滿意和或不愿意支付額外的優先處理費用，則用戶不對該確認請求進行確認(不返回響應消息)或返回否定確認消息給此AF (即如果用戶不同意執行新的服務質量提供該業務但未作否定確認，則終端設備根據運營商需求可選地構建否定確認消息發送給AF),執行stepS910a_c ；
[0166]步驟S910a:若AF在規定時間內(例如timer2 timeout)沒有收到用戶的確認接收消息，或收到了用戶的確認拒絕消息，則AF將發送更新QoS請求(例如，downgrade QoS)給 PCRF ；
[0167]步驟S910b:PCRF收到AF的downgrade QoS請求消息后，結合簽約信息及本地策略(例如用戶確認接收UpdateQoS的Preview timer超時則需要回復原先QoS),發起IP-CAN/Gffcontrol/TDF會話修改流程，更新相關PCC/QoS/ADC規則，恢復該業務的原先QoS ；
[0168]步驟S910c:在QoS恢復處理完成后或提升QoS確認時間超時后，網絡對該業務數據流的處理將恢復到UE請求提升之前的QoS (QoS回退機制不在本發明的限定范圍內，可采用例如網元間的timer機制處理會話修改的回退時間，可本地存儲update之前的QoS,或者Trigger node發送downgrade QoS請求消息時攜帶此前的QoS信息,或者請求消息中攜帶使用默認QoS指示等)。
[0169]以上流程中除了策略控制，還存在計費相關處理流程，例如更新QoS后，新的PCC規則中可能下發新的計費關鍵字(對應新的計費費率)，可能存在PCRF、PCEF/BBERF/TDF等網元與計費網元0CS/0FCS以及其它計費系統的交互。
[0170]經過上述流程，可實現當運營商和應用提供商既無商業關系也無業務協作時，UE通過運營商感知其協作關系，直接請求運營商發起優先流處理請求，通過運營商自有的AF觸發PCRF發起該QoS更新，提升或降低服務質量/用戶體驗，變更運營商為該業務傳送的資源所對應的業務資費費率的處理流程。
[0171](二)
[0172]對于該場景UE請求QoS更新，根據運營商網絡部署，UE還可以通過重用承載資源修改流程完成該QoS的更新。在圖10所示流程中，UE通過運營商感知協作關系，運營商和第三方應用提供商不具有商業關系也沒有業務協作，并且，UE通過運營商MNO來發起QoSupdate，通過承載資源修改流程，觸發” PCEF發起的會話修改流程”，更新Q0S。如圖10所示，該流程包括:
[0173]步驟SlOOl:如上步驟S901_S905，UE附著到網絡建立相關承載和會話，向Non-MSAS請求了該業務，并創建完成相關的業務承載，網絡按授權QoS為UE提供該業務數據的下行傳輸；
[0174]步驟S1002:運營商根據其簽約信息中的協作運營商的簽約list、第三方應用提供商的ID，業務/應用ID等信息判斷其與該第三方應用提供商的協作關系，并將其告知UE相應的API。UE接收并存儲運營商發送的其與應用提供商的該協作關系。該交互信令可以為應用層信令或http等應用協議。該協作指示告知UE該應用提供商的該項業務與運營商的協作關系，例如協作、非協作(包括具備商業關系但無業務協作，既無商業關系也無業務協作這兩種場景)關系。本發明旨在告知UE其雙方的協作關系，其告知形式不限于以上所述方式。該協作關系通知可以為單獨的信令或消息，也可以包含在UE和運營商的其它信令或消息中傳送。該協作關系的指示，可在運營商獲取后的任何時候通知，不限于步驟SlOOl結束之后；
[0175]步驟S1003:業務過程中，UE發現服務質量QoS或用戶體驗不滿意(例如，由于移動性或網絡狀況導致數據流傳輸不穩定或帶寬太低等)，UE發起優先流處理請求。UE根據當前的應用提供商與運營商的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為:當兩者既無商業關系業務協作時，直接由UE請求運營商發起優先流處理請求。根據運營商網絡部署，UE可通過承載資源修改流程發起該QoS更新，也可以通過運營商自有的AF觸發PCRF發起該QoS更新。這里UE通過承載資源修改流程發起該QoS更新。
[0176]UE發送Request消息給MME,請求消息中攜帶請求的類型(更新QoS), UEIP/ID,承載ID (LBI)，flow information (例如流描述(TAD)，數據包過濾器ID (PTI)等)，QoS。若該業務/應用此前為GBR承載,則請求中可能攜帶packet filter identifier (s);以及如果有可能還會攜帶 Service ID/Application ID;
[0177]步驟S1004:MME前轉發送request消息給SGW，消息中包括圖7中步驟S703中的相關參數；
[0178]步驟S1005:SGff收到該消息后前轉該request消息給PGW,消息攜帶收到的具體
參數；
[0179]步驟S1006:PCEF根據收到的request消息參數,判斷需要更新QoS (例如根據攜帶了優先流處理或承載指示，或QoS更新指示,或該業務請求的QoS高于先的QoS等),發起IP-CANsession modification流程處理,發送會話修改請求給PCRF觸發會話修改,如圖9中步驟S909。消息中攜帶UE IP/ID,請求的QoS, flow information (例如TAD,以及SDFfileter ID)等參數。
[0180]PCRF查詢SPR/UDC簽約信息(例如該用戶/業務/應用是否簽約了高優先流處理；若簽約允許則根據請求提升QoS)，更新PCC策略決策，下發更新后的PCC規則給PCEF/BBERF, or ADC規則給TDF/PCEF (如果存在應用流檢測功能)。這里若PCRF本地沒有簽約信息，則PCRF還需要向SPR/UDC/HSS等數據庫獲取相關簽約信息。PCEF/BBERF更新PCC/QoS規則，修改或新建承載滿足提升后的QoS。并反饋規則執行響應消息給PCRF，完成會話修改流程。
[0181]PGW執行QoS策略，完成承載修改和綁定，下發Update Bearer Request給SGW,SGff前傳到MME ；MME構建承載修改請求消息下發給eNodeB,帶上Bear ID, QoS; eNodeB映射EPS承載QoS到無線承載QoS下發RRL CR消息給UE’ UE更新存儲相關QoS ;逐級返回相關response消息直至給PGW，完成承載修改流程。這里具體涉及每個網元的消息及其參數等內容的詳細流程可參照3GPP TS 23.401中的UE發起的承載資源修改描述。
[0182]步驟S1007:若update QoS成功，則需要發送更新QoS確認請求消息給UE,要求用戶確認是否滿意更新后的QoS，如果滿意則UE返回肯定的確認消息(確認接受更新后的QoS需要為此優先流處理提供額外資費)；如果不滿意或不同意支付額外的優先流處理費用，則UE給網絡返回否定的確認或不進行確認(若用戶不進行確認，則終端設備可能會構建否定確認返回給網絡，便于技術實現中區分用戶沒有發送確認和確認消息丟失的異常情形，但具體處理根據運營商網絡實現處理)；
[0183]或者可以不由UE本身觸發感知，而由網絡側下發通知。在完成IP-CAN sessionmodification流程后，按更新后的QoS為該業務提供業務數據流；PGW/PCEF下發一個通知消息給UE，要求UE對更新后的QoS進行確認，該通知消息中攜帶確認指示，表示用戶請求的QoS更新完成，請求確認；SGW收到該通知消息后，下發該通知給MME，帶上UEID/IP，必要的業務流信息，以及該確認指示；MME將該消息下發給UE，UE收到該通知消息后將提供一個通知指示給上層(例如應用層)，觸發用戶感知；
[0184]步驟S1008:用戶收到UE應用層的確認消息后，若對更新(例如提升)后的業務數據流滿意且愿意支付優先流處理的費用，則對在預覽時間段內對該消息進行確認，UE將會發送給肯定的確認消息給該網絡(在請求或通知相應中攜帶肯定的確認信息)，運營商將根據該確認對該業務繼續提供update之后的QoS (例如，繼續進行優先流處理，提供高優先級或高帶寬資源)。PCRF將發起IP-CAN會話修改流程(同圖9中的步驟S909)，下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費)。
[0185]若UE對提升后的業務數據流的服務質量或用戶體驗不滿意和或不愿意支付額外的優先處理費用，則用戶不對該確認請求進行確認(不返回確認響應消息)或返回否定確認消息給網絡(即如果用戶不同意執行新的服務質量提供該業務但未作否定確認，則終端設備根據運營商需求可選地構建否定確認消息發送給網絡，若User不確認則應用層則需要在等待確認的timer timeout之后觸發承載層構建否定確認消息發送給網絡，網絡將會在一定preview時間之后將QoS恢復到請求提升之前的水平；
[0186]步驟S1009 =MME收到UE的請求或通知相應消息，給SGW前轉該消息，攜帶原消息中的參數，例如UE IP/ID，QoS，肯定或否定的確認信息/指示等；
[0187]步驟SlOlO =SGff前傳該消息到PGW，攜帶QoS和確認信息/指示等參數；
[0188]步驟SlOll:PGW根據確認信息/指示判斷用戶業務所需的QoS，若為肯定確認，則執行步驟S1012 ；
[0189]若為否定確認則發送IP-CANsession modification請求給PCRF發起會話修改流程，downgrade QoS ；PCRF收到downgrade QoS請求消息后，結合簽約信息及本地策略(例如用戶確認接收UpdateQoS的Preview timer超時則需要回復原先QoS),發起IP-CAN/Gffcontrol/TDF會話修改流程，更新相關PCC/QoS/ADC規則，恢復該業務的原先QoS ;該IP-CAN session修改流程修改承載和會話，為該業務提供的QoS將恢復到用戶提升請求之前的水平，按原有的QoS繼續執行StepS1015提供下行業務數據流；(QoS回退機制不在本發明的限定范圍內，可采用例如網元間的timer機制處理會話修改的回退時間，可本地存儲update之前的QoS,或者UE發送downgrade QoS請求消息時攜帶此前的QoS信息,或者請求消息中攜帶使用默認QoS指示等)。
[0190]步驟S1012-S1014:如步驟S1008 PCRF發起的IP-CAN會話修改流程下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費),提升或恢復QoS流程處理完畢。PGW確認UE用于發送確認通知發起的資源修改流程不需要執行(即QoS不需要變更)，則發送承載資源修改失敗指示來指示SGW，高QoS將繼續應用于該業務，不需要重新發起QoS修改流程，執行步驟S1012-S1014反饋該承載資源修改失敗指示。
[0191]步驟S1015:若為步驟SlOll則在downgrade QoS完成后，按最初的QoS傳送下行數據；若為update QoS成功確認St印S1014，則按提升后的QoS傳送下行數據。S卩，網絡按授權的QoS為該業務繼續提供業務數據流。
[0192]經過上述流程，可實現當運營商和應用提供商既無商業關系也無業務協作時，UE通過運營商感知其合作關系，直接請求運營商發起優先流處理請求，通過承載資源修改流程觸發PCRF發起IP-CAN會話修改，更新該業務的QoS，提升或降低服務質量/用戶體驗，變更運營商為該業務傳送的資源所對應的業務資費費率的處理流程。
[0193](三)
[0194]本實施例基于圖3的MOSAP架構基礎上提供一種UE通過運營商感知應用提供商和運營商的協作關系，并根據運營商策略或用戶的選擇來觸發QoS提升的方法和系統，來實現用戶根據其需求觸發的優先流處理。
[0195]本實施例描述的UE使用和運營商不具有協作關系的第三方應用提供商的業務，該第三方應用提供商和運營商具有商業關系但沒有任何業務協作。運營商負責為UE的第三方應用提供傳輸資源，UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求,觸發運營商修改會話更新Q0S。
[0196]IP-CAN會話創建后，運營商根據其簽約信息中的協作運營商的簽約list、第三方應用提供商的ID，業務/應用ID等信息判斷其與該第三方應用提供商的協作關系，并將其告知UE相應的API。UE接收并存儲運營商發送的其與應用提供商的該協作關系。當用戶不滿意當前業務的QoS，發起優先流處理請求時，UE根據當前的DAP與MO的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為當DAP和MO存在商業關系但無業務協作時，由UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求，觸發運營商修改會話更新Q0S。
[0197]在圖11所示流程中，UE通過運營商MO感知協作關系，第三方應用提供商和運營商具有商業關系但沒有業務協作，并且UE通過MNO來發起QoSupdate，non-MS AS通知PCRF，觸發” PCEF發起的會話修改流程”，更新Q0S。該該網絡部署中運營商和第三方業務提供商具有Rx接口，可傳送相關業務信息。但運營商不會替第三方業務提供商向用戶進行第三方業務的資費統計和計算。如圖11所示，該流程包括:
[0198]步驟SllOl:UE附著到歸屬地網絡，建立無線承載和創建IP-CAN session ；
[0199]步驟SI 102:UE登陸并成功訪問Non-MS AS,這里UE和Non-MS AS使用application level signaling 或 HTTP 協議，non-1MS AS 為 UE 提供應用業務；
[0200]步驟SI 103 =Non-1MS AS 向運營商的 PCRF 提供 UE ID/IP, Service ID/application ID,以及flow information相關信息，發起Rx會話建立請求。PCRF向SPR/UDC獲取UE簽約信息和簽約AS信息，制定并下發PCC rule給PCEF，建立相關數據承載。由于該AS與運營商只有商業關系沒有業務合作,授權QoS為default bearer QoS ；[0201]步驟S1104:完成該業務所需承載的創建；PCRF根據AS，SPR/UDC，PGff等client端發送的相關信息制定PCC/QoS規則，并下發到PCEF/BBERF;PCEF/BBERF安裝并執行相關規則，完成承載綁定，若沒有匹配承載則下發承載建立請求，創建承載；PCRF下發規則的同時，還可能攜帶相關event trigger,以及用量監控閾值,監控關鍵字等其它信息；PCEF收到信息后設置和執行相關事件報告及用量監控功能；
[0202]步驟S1105:該業務承載創建完成，網絡按授權QoS為UE提供該業務數據的下行傳輸；
[0203]步驟S1106:運營商根據其簽約信息中的協作運營商的簽約list、第三方應用提供商的ID，業務/應用ID等信息判斷其與該第三方應用提供商的協作關系，并將其告知UE相應的API。UE接收并存儲運營商發送的其與應用提供商的該協作關系。該協作指示告知UE該應用提供商的該項業務與運營商的協作關系，例如協作、非協作(包括具備商業關系但無業務協作，既無商業關系也無業務協作這兩種場景)關系。本發明旨在告知UE其雙方的協作關系，其告知形式不限于具體信令方式。該協作關系通知可以為單獨的信令或消息，也可以包含在UE和運營商的其它信令或消息中傳送,例如步驟SllOl和S1104的消息。該協作關系的指示，可在運營商獲取后的任何時候通知，不限于步驟S1105之后；
[0204]步驟SI 107:業務過程中，UE發現服務質量QoS或用戶體驗不滿意(例如，由于移動性或網絡狀況導致數據流傳輸不穩定或帶寬太低等)，UE發起優先流處理請求。UE根據當前的應用提供商與運營商的協作關系和運營商策略做出正確的選擇。例如，運營商默認策略為:當兩者具有商業關系但無業務協作時，由UE向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求,觸發運營商修改會話更新Q0S。
[0205]UE發送請求消息給non-MS AS，UE的該請求消息中攜帶UEIP/ID，優先流處理指不/QoS,及 flow information,以及如果有可能還會攜帶 Service ID/Application ID;
[0206]步驟SI 108:non-1MS AS收到UE的請求消息后，關聯UE Id/IP和所需提升QoS的service/application,發送請求消息給PCRF,請求發起會話修改update QoS ;這里non-1MS AS作為PCRF的diameter client端，請求消息中攜帶UE ID/IP,優先流處理指示/QoS,,? f1winformation,以及可倉泛還有 service ID/application ID;
[0207]步驟S1109 =PCRF收到該non_MS AS的請求消息后，查詢SPR/UDC該用戶/業務/應用是否簽約了高優先流處理(若本地沒有相關簽約信息則查詢SPR/UDC)，若簽約允許則根據請求發起會話修改流程；制定下發更新后的PCC規則給PCEF/BBERF，orADC規則給TDF0 PCEF/BBERF/TDF更新PCC/QoS/ADC規則，修改或新建承載，執行update后的QoS和相關承載的綁定。并發送響應消息給PCRF，反饋規則執行結果；
[0208]步驟SlllO =PCRF返回提升QoS修改響應消息給non_MS AS，告知修改是否被接受，如果被拒絕，攜帶相關cause ;該步驟需要AF在發送QoS更新請求時一并訂閱資源分配狀態等事件報告；
[0209]步驟Sllll:若update QoS更新成功，則non-1MS給UE發送更新QoS確認請求消息，要求用戶確認是否滿意更新后的QoS，如果滿意則在預覽時間段內返回肯定的確認消息(確認接受更新后的QoS后，用戶需要為此優先流處理提供額外資費);如果不滿意或不同意支付額外的優先流處理費用，則返回否定的確認或不進行確認(若用戶不進行確認，則終端設備可能會構建否定確認返回給網絡，便于技術實現中區分用戶沒有發送確認和確認消息丟失的異常情形，non-MS AS上也可設置timer作為拒絕或接受流程的時間窗口。但具體處理根據產品實現處理)。該步驟也可以由UE檢測到QoS更新成功即資源修改成功后，并且本地設置的預覽定時器超時，觸發API發送確認消息給用戶感知；
[0210]步驟S1112:用戶收到non-MS AS的確認請求消息或底層UE觸發的確認請求消息后，若對更新(例如提升)后的業務數據流滿意且愿意支付優先流處理的費用，則對該消息進行確認，UE將會發送給確認響應消息給non-MS AS。
[0211]步驟S1113:該non-1MS AS收到UE的確認響應后,可選地發送確認response消息給PCRF。若為接收更新后的高QoS確認，則運營商將對該業務繼續提供update之后的QoS (例如，繼續進行優先流處理，提供高優先級或高帶寬資源)。PCRF將發起IP-CAN會話修改流程，下發新的Charigng key (對該QoS下的業務執行相應的優先流特殊計費)。
[0212]步驟S1113a_c:若UE對提升后的業務數據流的服務質量或用戶體驗不滿意和或不愿意支付額外的優先處理費用，則用戶不對該確認請求進行確認(不返回響應消息)或返回否定確認消息給non-1MS AS(即如果用戶不同意執行新的服務質量提供該業務但未作否定確認，則終端設備根據運營商需求可選地構建否定確認消息發送給non-MS AS)，執行步驟 513a-c ；
[0213]步驟SI 113a:若non-1MS AS在規定時間內(例如timer2 timeout)沒有收到用戶的確認接收消息，或收到了用戶的確認拒絕消息，則將發送更新QoS請求(例如，downgradeQoS)給 PCRF ；
[0214]步驟SI 113b:PCRF收到non-1MS AS的downgrade QoS請求消息后，結合簽約信息及本地策略(例如用戶確認接收UpdateQoS的Preview timer超時則需要回復原先QoS),發起IP-CAN/GWcontrol/TDF會話修改流程，更新相關PCC/QoS/ADC規則，恢復該業務的原先QoS ；
[0215]步驟SI 113c:在QoS恢復處理完成后或提升QoS確認時間超時后，網絡對該業務數據流的處理將恢復到UE請求提升之前的QoS (QoS回退機制不在本發明的限定范圍內，可采用例如網元間的timer機制處理會話修改的回退時間，可本地存儲update之前的QoS,或者AS發送downgrade QoS請求消息時攜帶此前的QoS信息,或者請求消息中攜帶使用默認QoS指示等)。
[0216]以上流程中除了策略控制，還存在計費相關處理流程，例如更新QoS后，新的PCC規則中可能下發新的計費關鍵字(對應新的計費費率)，可能存在PCRF、PCEF/BBERF/TDF等網元與計費網元0CS/0FCS以及其它計費系統的交互。
[0217]以上流程中，當DAP和MO存在商業關系但無業務協作時，默認UE向DAP請求進而由DAP觸發MO發起優先流處理請求，但現網部署中也可支持直接由UE請求MO發起優先流處理請求，可由UE提供兩種處理機制選項供用戶選擇并根據其選擇發起流處理請求，或根據運營商策略默認其中一種處理機制，或默認兩種機制的優先級處理。具體根據現網部署需求和運營商策略決定。
[0218]針對本實施例的該流程，若運營商有自有AF功能或網元(例如應用平臺或集成在其它網元中的AF功能)，non-MS AS與PCRF的交互消息可能會發送給該運營商自有AF，前傳給PCRF處理，相關相應消息也可能經由AF轉發給第三方的non-MS AS。[0219]經過上述流程，可實現當運營商和應用提供商存在商業關系但無業務協作時，UE通過運營商感知其合作關系，向第三方業務提供商發起優先流處理請求，由DAP進而向運營商發起相關QoS的更新處理請求，觸發運營商修改會話更新Q0S，提升或降低服務質量/用戶體驗，變更運營商為該業務傳送的資源所對應的業務資費費率的處理流程。
[0220]上述實施例2和實施例3可以結合使用，主要根據具體網絡部署和網元功能支持。
[0221]以上實施例描述是在運營商和第三方應用提供商非協作關系場景下的IE感知和區分，以上實施例同樣適用于UE運營商自有業務和運營商與第三方存在協作關系(collaborated)場景的的感知和區分，以及運營商自有業務，與第三方存在協作，與第三方不存在協作沒有商業關系，以及與第三方不存在協作但有商業關系的這幾類場景在現網部署和應用中的感知和區分
[0222]在另外一個實施例中，還提供了一種軟件，該軟件用于執行上述實施例及優選實施方式中描述的技術方案。
[0223]在另外一個實施例中，還提供了一種存儲介質，該存儲介質中存儲有上述軟件，該存儲介質包括但不限于:光盤、軟盤、硬盤、可擦寫存儲器等。
[0224]顯然，本領域的技術人員應該明白，上述的本發明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，并且在某些情況下，可以以不同于此處的順序執行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現。這樣，本發明不限制于任何特定的硬件和軟件結合。
[0225]以上僅為本發明的優選實施例而已，并不用于限制本發明，對于本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。
【權利要求】
1.一種服務質量的更新處理方法，其特征在于，包括: 用戶設備UE獲取應用提供商和運營商的協作關系； 所述UE根據獲取的所述協作關系請求服務質量QoS更新。
2.根據權利要求1所述的方法，其特征在于，所述協作關系，包括以下之一: 所述應用提供商和所述運營商存在業務協作；所述應用提供商和所述運營商不存在業務協作和商業關系；所述應用提供商和所述運營商僅存在商業關系但無業務協作。
3.根據權利要求2所述的方法，其特征在于，所述UE根據獲取的所述協作關系請求QoS更新，包括: 在所述應用提供商和所述運營商不存在業務協作和商業關系時，所述UE直接向所述運營商發起請求，請求所述運營商對QoS進行更新處理。
4.根據權利要求2所述的方法，其特征在于，所述UE根據獲取的所述協作關系請求QoS更新，包括: 在所述應用提供商和所述運營商僅存在商業關系但無業務協作時，所述UE根據所述協作關系采用以下方式之一發起對QoS的更新流程:所述UE直接向所述運營商發起請求，觸發所述運營商進行對QoS進行更新處理；所述UE經由所述應用提供商發起請求觸發所述運營商對QoS進行更新處理。
5.根據權利要求1至4任一項所述的方法，其特征在于，所述UE獲取應用提供商和運營商的協作關系，包括: 所述UE接收來自于所述應用提供商發送的所述協作關系；或者 所述UE接收來自于所述運營商發送的所述協作關系。
6.根據權利要求5所述的方法，其特征在于，所述UE接收來自于所述運營商發送的所述協作關系，包括: 所述UE從所述運營商的應用功能AF實體發送的應用層信令或協議中獲取所述協作關系；或者 所述UE從所述運營商的承載層信令中獲取所述協作關系。
7.一種服務質量的更新處理裝置，位于用戶設備UE中，其特征在于，包括: 獲取模塊，用于獲取應用提供商和運營商的協作關系； 請求模塊，用于根據獲取的所述協作關系請求服務質量QoS更新。
8.根據權利要求7所述的裝置，其特征在于，所述獲取模塊用于獲取以下之一協作關系: 所述應用提供商和所述運營商存在業務協作；所述應用提供商和所述運營商不存在業務協作和商業關系；所述應用提供商和所述運營商僅存在商業關系但無業務協作。
9.根據權利要求8所述的裝置，其特征在于，所述請求模塊，用于在所述應用提供商和所述運營商不存在業務協作和商業關系時，直接向所述運營商發起請求，請求所述運營商進行對QoS進行更新處理。
10.根據權利要求8所述的裝置，其特征在于，所述請求模塊，用于在所述應用提供商和所述運營商僅存在商業關系但無業務協作時，根據所述協作關系采用以下方式之一發起對QoS的更新流程:直接向所述運營商發起請求，觸發所述運營商對QoS進行更新處理；經由所述應用提供商發起請求觸發所述運營商對QoS進行更新處理。
11.根據權利要求7至10任一項所述的裝置，其特征在于，所述獲取模塊，用于接收來自于所述應用提供商發送的所述協作關系；或者接收來自于所述運營商發送的所述協作關系ο
【文檔編號】H04W28/24GK103582030SQ201210271325
【公開日】2014年2月12日 申請日期:2012年8月1日 優先權日:2012年8月1日
【發明者】吳錦花, 周曉云 申請人:中興通訊股份有限公司