數(shù)據(jù)業(yè)務(wù)加速方法及裝置制造方法
【專利摘要】本發(fā)明公開了一種數(shù)據(jù)業(yè)務(wù)加速方法及裝置，涉及通信領(lǐng)域，用于解決現(xiàn)有技術(shù)中通信運營商在實現(xiàn)數(shù)據(jù)業(yè)務(wù)加速的過程中部署周期較長、運維成本較高的問題。本發(fā)明提供的裝置包括：第一API接口，第二標準接口和處理器；所述處理器用于通過所述第一API接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議；對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議；將所述第二請求消息通過所述第二標準接口發(fā)送至策略與計費規(guī)則功能體PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略。本發(fā)明適用于通信領(lǐng)域，用于實現(xiàn)數(shù)據(jù)業(yè)務(wù)加速。
【專利說明】數(shù)據(jù)業(yè)務(wù)加速方法及裝置
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及通信領(lǐng)域，尤其涉及一種數(shù)據(jù)業(yè)務(wù)加速方法及裝置。
【背景技術(shù)】
[0002]隨著網(wǎng)絡(luò)的普及，數(shù)據(jù)業(yè)務(wù)得到了快速發(fā)展，例如，用戶可以通過手機或平板電腦等用戶終端隨時隨地瀏覽網(wǎng)頁、在線觀看視頻等。但是，由于網(wǎng)絡(luò)堵塞或帶寬有限等因素，會使得數(shù)據(jù)業(yè)務(wù)的傳輸速度受到較大限制，導(dǎo)致網(wǎng)頁打開的時延較大、在線視頻播放發(fā)生卡頓等問題。為了提高數(shù)據(jù)業(yè)務(wù)的傳輸速度，業(yè)界提出了一種數(shù)據(jù)業(yè)務(wù)加速方法，所述數(shù)據(jù)業(yè)務(wù)加速方法包括用戶級加速方法和業(yè)務(wù)級加速方法，其中，所述用戶級加速方法用于為指定用戶的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級加速方法用于為指定業(yè)務(wù)進行加速。
[0003]現(xiàn)有技術(shù)中，數(shù)據(jù)業(yè)務(wù)加速方法是通過OCS (Online Charging System,在線計費裝置)和PCRF (Po I icy and Charging Rules Function,策略與計費規(guī)則功能體)共同實現(xiàn)的，其中，所述OCS用于重新配置計費策略，所述PCRF用于重新配置QoS(Quality ofService，服務(wù)質(zhì)量)策略。例如，在實現(xiàn)用戶級加速時，用戶終端向門戶服務(wù)器(PortalServer)發(fā)送用戶級加速請求，由所述門戶服務(wù)器將所述用戶級加速請求分發(fā)給OCS和PCRF,以使得所述OCS和PCRF根據(jù)所述加速請求為所述用戶終端進行業(yè)務(wù)加速。一般的，門戶服務(wù)器依據(jù)SOAP (Simple Object Access Protocol,簡單對象訪問協(xié)議)向OCS和PCRF發(fā)送加速請求。
[0004]在實現(xiàn)本發(fā)明的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)中至少存在如下問題:
[0005]由于SOAP是一種定制性較強的協(xié)議，OCS和PCRF在實現(xiàn)用戶級加速和業(yè)務(wù)級加速時均需要分別定制SOAP協(xié)議；另一方面，如果通信運營商采用的OCS和PCRF由不同生產(chǎn)廠商制造，則還需要分別定制SOAP協(xié)議，會導(dǎo)致通信運營商在實現(xiàn)數(shù)據(jù)業(yè)務(wù)加速的過程部署周期較長、運維成本較高。

【發(fā)明內(nèi)容】

[0006]本發(fā)明的實施例提供一種數(shù)據(jù)業(yè)務(wù)加速方法及裝置，能夠解決現(xiàn)有技術(shù)中通信運營商在實現(xiàn)數(shù)據(jù)業(yè)務(wù)加速的過程中部署周期較長、運維成本較高的問題。
[0007]為達到上述目的，本發(fā)明的實施例采用如下技術(shù)方案:
[0008]第一方面，本發(fā)明實施例提供了一種數(shù)據(jù)業(yè)務(wù)加速方法，所述方法包括:
[0009]通過第一API (Application Programming Interface)應(yīng)用程序編程接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；
[0010]對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議、且所述第二請求消息通過第二標準接口進行發(fā)送，所述第二請求消息用于請求為所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；
[0011]將所述第二請求消息通過所述第二標準接口發(fā)送至PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置QoS策略，并將所述QoS策略發(fā)送至PGff (Packet data network GateWay,分組數(shù)據(jù)網(wǎng)關(guān))，由所述PGW根據(jù)所述QoS策略為所述用戶終端重新配置業(yè)務(wù)承載，通過所述業(yè)務(wù)承載對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0012]在第一種可能的實現(xiàn)方式中，所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略之后,還包括:
[0013]所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置與所述QoS策略對應(yīng)的PCC策略，并將所述重新配置的PCC策略發(fā)送至PGW，由所述PGW將所述PCC策略發(fā)送至OCS,以使得所述OCS根據(jù)所述PCC策略對所述用戶終端進行計費。
[0014]結(jié)合第一方面，在第二種可能的實現(xiàn)方式中，所述第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0015]結(jié)合第一方面的第二種可能的實現(xiàn)方式，在第三種可能的實現(xiàn)方式中，當所述第一請求消息為用戶級請求消息時，所述通過第一 API接口獲取第一請求消息，包括:通過所述第一 API接口接收門戶服務(wù)器Portal Server發(fā)送的用戶級請求消息,所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY ；
[0016]則所述PCRF為所述用戶終端重新配置的QoS策略用于指示所述PGW為所述用戶終端的重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速。
[0017]結(jié)合第一方面的第二種可能的實現(xiàn)方式，在第四種可能的實現(xiàn)方式中，當所述第一請求消息為業(yè)務(wù)級請求消息時，所述通過第一 API接口獲取第一請求消息，包括:通過所述第一 API接口接收互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器OTT Server發(fā)送的業(yè)務(wù)級請求消息，所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)；
[0018]則所述PCRF為所述用戶終端重新配置的QoS策略用于指示所述PGW為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0019]結(jié)合第一方面的第二種可能的實現(xiàn)方式，在第五種可能的實現(xiàn)方式中，所述方法還包括:
[0020]檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話；
[0021]當檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器或OTT服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器或OTT激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0022]其中，所述檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話，包括:
[0023]通過PGW感知所述用戶終端是否建立所述IP-CAN會話；或者
[0024]通過PCRF感知所述用戶終端是否建立所述IP-CAN會話；或者
[0025]通過所述用戶終端的客戶端感知所述用戶終端是否建立所述IP-CAN會話。
[0026]第二方面，本發(fā)明實施例還提供了一種數(shù)據(jù)業(yè)務(wù)加速裝置，所述裝置包括第一應(yīng)用程序編程接口 API，第二標準接口和處理器；
[0027]所述第一 API接口用于與門戶服務(wù)器或OTT服務(wù)器進行交互；[0028]所述第二標準接口用于與PCRF進行交互；
[0029]所述處理器用于:
[0030]用于通過所述第一 API接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；
[0031]對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議；
[0032]將所述第二請求消息通過所述第二標準接口發(fā)送至策略與計費規(guī)則功能體PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略，并將所述QoS策略發(fā)送至分組數(shù)據(jù)網(wǎng)關(guān)PGW，由所述PGW根據(jù)所述QoS策略為所述用戶終端重新配置業(yè)務(wù)承載，通過所述業(yè)務(wù)承載對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0033]在第一種可能的實現(xiàn)方式中，所述處理器通過所述第一 API接口獲取的所述第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0034]結(jié)合第二方面的第一種可能的實現(xiàn)方式，在第二種可能的實現(xiàn)方式中，當所述第一請求消息為用戶級請求消息時，所述處理器用于通過所述第一 API接口接收門戶服務(wù)器Portal Server發(fā)送的用戶級請求消息，所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY，用于為所述用戶的所有數(shù)據(jù)業(yè)務(wù)進行加速。
[0035]結(jié)合第二方面的第一種可能的實現(xiàn)方式，在第三種可能的實現(xiàn)方式中，當所述第一請求消息為業(yè)務(wù)級請求消息時，所述處理器用于通過所述第一 API接口接收互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器OTT Server發(fā)送的業(yè)務(wù)級請求消息，所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)，用于為所述用戶的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0036]結(jié)合第二方面，在第四種可能的實現(xiàn)方式中，所述處理器還用于檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話；當所述處理器檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器或OTT服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器或OTT激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0037]結(jié)合第二方面的第四種可能的實現(xiàn)方式，在第五種可能的實現(xiàn)方式中，所述處理器具體用于通過PGW感知所述用戶終端是否建立所述IP-CAN會話；或者
[0038]所述處理器還用于通過PCRF感知所述用戶終端是否建立所述IP-CAN會話；或者
[0039]所述處理器還用于通過所述用戶終端的客戶端感知所述用戶終端是否建立所述IP-CAN 會話。
[0040]本發(fā)明實施例提供的數(shù)據(jù)業(yè)務(wù)加速方法及裝置，在實現(xiàn)業(yè)務(wù)級加速和用戶級加速的過程中，對外部應(yīng)用層(例如門戶服務(wù)器或OTT服務(wù)器)提供第一 API接口作為統(tǒng)一接口供終端或系統(tǒng)開發(fā)者調(diào)用，對內(nèi)部網(wǎng)元(例如PCRF)提供第二標準接口以支持業(yè)務(wù)流程。由于對外部應(yīng)用層和對內(nèi)部網(wǎng)元均提供了統(tǒng)一接口，使得OCS和PCRF無需專門定制協(xié)議，能夠降低通信運營商的部署周期，降低運維成本?！緦＠綀D】

【附圖說明】
[0041]為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0042]圖1為本發(fā)明實施例一提供的數(shù)據(jù)業(yè)務(wù)加速方法的流程示意圖；
[0043]圖2為本發(fā)明實施例二提供的數(shù)據(jù)業(yè)務(wù)加速方法的流程示意圖；
[0044]圖3為本發(fā)明實施例三提供的數(shù)據(jù)業(yè)務(wù)加速方法的流程示意圖；
[0045]圖4為本發(fā)明實施例三提供的用戶級加速業(yè)務(wù)和業(yè)務(wù)級加速的融合架構(gòu)圖；
[0046]圖5、圖6為本發(fā)明實施例四提供的數(shù)據(jù)業(yè)務(wù)加速裝置的結(jié)構(gòu)框圖；
[0047]圖7為本發(fā)明實施例四提供的數(shù)據(jù)業(yè)務(wù)加速裝置的結(jié)構(gòu)框圖。
【具體實施方式】
[0048]下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0049]實施例一
[0050]本發(fā)明實施例提供了一種數(shù)據(jù)業(yè)務(wù)加速方法，如圖1所示，包括:
[0051]101、通過第一 API接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0052]優(yōu)選的，為了便于管理，本實施例提供的方法可以通過在通信系統(tǒng)中增加新的網(wǎng)元設(shè)備進行實現(xiàn)，例如可以在通信系統(tǒng)中新增能力開放網(wǎng)關(guān)以實現(xiàn)本實施例提供的方法。接下來，本實施例以增加能力開放網(wǎng)關(guān)為例進行具體說明。
[0053]本實施例中，所述能力開放網(wǎng)關(guān)由運營商提供，用于通過開放靈活的方式向合作伙伴/OTT互聯(lián)網(wǎng)業(yè)務(wù)提供統(tǒng)一的能力調(diào)用API接口，以使得開發(fā)者通過這些能力調(diào)用API接口獲取運營商網(wǎng)絡(luò)內(nèi)的管道能力，例如網(wǎng)絡(luò)定義能力、QoS能力，用戶位置能力、用戶標識能力等，從而開發(fā)出各種方便、快捷的應(yīng)用。需要強調(diào)的是，本實施例中主要通過調(diào)用QoS能力實現(xiàn)業(yè)務(wù)加速。根據(jù)本實施例提供的方法，本領(lǐng)域技術(shù)人員在不付出創(chuàng)造性勞動的前提下，也可以想到通過調(diào)用其他能力來進行擴展，此處不多贅述。
[0054]值得說明的是，第一 API接口用于供所述能力開放網(wǎng)關(guān)與外部應(yīng)用層進行通信。例如，所述能力開放網(wǎng)關(guān)可以通過所述第一 API接口接收門戶服務(wù)器(Portal Server)發(fā)送的用戶級加速請求，或者，所述能力開放網(wǎng)關(guān)還可以通過所述第一 API接口接收OTTServer發(fā)送的業(yè)務(wù)級加速請求。
[0055]值得說明的是，所述OTT Server是Over The Top Server,即頂層服務(wù)器,也可以稱為互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器，此處不做限定。
[0056]102、所述能力開放網(wǎng)關(guān)對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議。
[0057]其中，所述第二請求消息能夠通過第二標準接口進行發(fā)送，且所述第二請求消息用于請求為所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0058]也就是說，本實施例中的能力開放網(wǎng)關(guān)能夠?qū)邮盏降恼埱笙⑦M行協(xié)議轉(zhuǎn)換，從而將符合第一協(xié)議的第一請求消息轉(zhuǎn)換為符合第二協(xié)議的第二請求消息。其中，優(yōu)選的，可以選擇一種通用的、無需定制的標準協(xié)議作為第二協(xié)議，所述第二標準接口是基于第二協(xié)議的標準接口，任意支持第二協(xié)議的設(shè)備均可以通過所述第二標準接口與所述能力開放網(wǎng)關(guān)進行通信。例如，在本實施例中，可以將第二協(xié)議設(shè)定為Rx協(xié)議，則所述第二標準接口為Rx接口，用于供能力開放網(wǎng)關(guān)和PCRF進行交互。
[0059]103、所述能力開放網(wǎng)關(guān)將所述第二請求消息通過所述第二標準接口發(fā)送至策略與計費規(guī)則功能體PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略，并將所述QoS策略發(fā)送至分組數(shù)據(jù)網(wǎng)關(guān)PGW，由所述PGW根據(jù)所述QoS策略為所述用戶終端重新配置業(yè)務(wù)承載，通過所述業(yè)務(wù)承載對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0060]本發(fā)明實施例提供的數(shù)據(jù)業(yè)務(wù)加速方法，在實現(xiàn)業(yè)務(wù)級加速和用戶級加速的過程中，對外部應(yīng)用層(例如門戶服務(wù)器或OTT服務(wù)器)提供第一 API接口作為統(tǒng)一接口供終端或系統(tǒng)開發(fā)者調(diào)用，對內(nèi)部網(wǎng)元(例如PCRF)提供第二標準接口以支持業(yè)務(wù)流程。與現(xiàn)有技術(shù)相比，由于對內(nèi)部網(wǎng)元提供了基于第二協(xié)議的第二標準接口作為統(tǒng)一接口，使得OCS和PCRF無需定制SOAP協(xié)議，能夠降低通信運營商的部署周期，降低運維成本。
[0061]實施例二
[0062]在圖1所示方法的基礎(chǔ)上，進一步的，本發(fā)明實施例提供了一種數(shù)據(jù)業(yè)務(wù)加速方法，能夠?qū)⒂脩艏壖铀贅I(yè)務(wù)和/或業(yè)務(wù)級加速業(yè)務(wù)進行融合。如圖2所示，所述方法包括:
[0063]20UUE(User Equipment,用戶終端)向服務(wù)器發(fā)送加速請求。
[0064]其中，所述服務(wù)器至少包括門戶服務(wù)器(Portal Server)和/或OTT Server,所述加速級請求至少包括用戶級加速請求和/或業(yè)務(wù)級加速請求。
[0065]具體的，所述門戶服務(wù)器由通信運營商提供，用于實現(xiàn)用戶級加速業(yè)務(wù)的訂購和實現(xiàn)，例如，通信運營商可以提供一個門戶網(wǎng)站，用戶可以登錄該網(wǎng)站定購用戶級加速業(yè)務(wù)。所述OTT Server可以由提供網(wǎng)絡(luò)內(nèi)容的廠商提供，用于實現(xiàn)業(yè)務(wù)級加速業(yè)務(wù)的訂購和實現(xiàn)，例如，當用戶使用某應(yīng)用程序在線觀看電影時，用戶可以通過該應(yīng)用程序向OTTServer發(fā)起業(yè)務(wù)請求以訂購業(yè)務(wù)級加速業(yè)務(wù)。
[0066]可選的，所述UE可以直接向所述服務(wù)器發(fā)送所述加速請求(例如，發(fā)送短信、登錄網(wǎng)站等方式)，或者，所述UE可以通過預(yù)先安裝的客戶端(Client)發(fā)送所述加速請求，但不僅限于此。
[0067]202、所述服務(wù)器接收所述加速請求，生成第一請求消息，所述第一請求消息符合第一協(xié)議。
[0068]值得說明的是，由于本實施例提供的方法能夠?qū)τ脩艏壖铀俸蜆I(yè)務(wù)加速的實現(xiàn)流程進行融合，所以本實施例中的服務(wù)器是Portal Server和OTT Server的統(tǒng)稱。具體的，當UE發(fā)起用戶級加速請求時,所述服務(wù)器為Portal Server ;當UE發(fā)起業(yè)務(wù)級加速時,所述服務(wù)器為OTT Server。
[0069]為了確保用戶級加速和業(yè)務(wù)級加速的融合，優(yōu)選的，本實施例提供的方法中，可以預(yù)先設(shè)定第一協(xié)議，以使得服務(wù)器和能力開放網(wǎng)關(guān)基于所述第一協(xié)議進行通信。[0070]一 般的，所述第一協(xié)議可以為 SOAP 協(xié)議、或 REST (Representational StateTransfer,表象化狀態(tài)轉(zhuǎn)變)協(xié)議。
[0071]203、能力開放網(wǎng)關(guān)通過第一 API接口接收所述服務(wù)器發(fā)送的第一請求消息。
[0072]其中，所述第一 API接口是符合第一協(xié)議的接口，用于供所述能力開放網(wǎng)關(guān)和服務(wù)器基于所述第一協(xié)議進行通信。另一方面，第一 API接口作為統(tǒng)一接口供終端或系統(tǒng)開發(fā)者調(diào)用。
[0073]值得說明的是，所述第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0074]需要強調(diào)的是，本實施例提供的方法用于實現(xiàn)用戶級加速業(yè)務(wù)和業(yè)務(wù)級加速業(yè)務(wù)的融合，為了便于理解，對步驟203進行進一步說明:
[0075](I)當所述第一請求消息為用戶級請求消息時:
[0076]步驟203具體為:所述能力開放網(wǎng)關(guān)通過所述第一 API接口接收門戶服務(wù)器發(fā)送的用戶級請求消息，所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY。例如，門戶服務(wù)器可以在所述第一請求消息中將業(yè)務(wù)流的源IP、源端口、目的IP、目的端口設(shè)定為任意值，即對待加速的業(yè)務(wù)流不做限定。
[0077](2)當所述第一請求消息為業(yè)務(wù)級請求消息時:
[0078]步驟203具體為:所述能力開放網(wǎng)關(guān)通過所述第一 API接口接收OTT Server發(fā)送的業(yè)務(wù)級請求消息，所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)。例如，所述OTT Server可以在所述第一請求消息中將業(yè)務(wù)流的源IP、源端口、目的IP、目的端口設(shè)定為指定值，即對指定業(yè)務(wù)流進行加速。
[0079]204、所述能力開放網(wǎng)關(guān)對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息。
[0080]其中，所述第二請求消息符合第二協(xié)議、且所述第二請求消息通過第二標準接口進行發(fā)送，所述第二請求消息用于請求為所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速，所述第二標準接口是所述能力開放網(wǎng)關(guān)上配置的接口，用于供所述能力開放網(wǎng)關(guān)與PCRF進行通信。
[0081]優(yōu)選的，為了使不同的網(wǎng)元設(shè)備較便捷的進行通信、以及減少不同的網(wǎng)元設(shè)備對同一協(xié)議進行定制造成的繁瑣，可以選擇一種通用的、無需定制的標準協(xié)議作為第二協(xié)議，例如Rx協(xié)議。
[0082]值得說明的是，本實施例中的第一請求消息和第二請求消息都是為了請求PCRF為所述用戶終端進行加速，區(qū)別在于，第一請求消息是基于第一協(xié)議，而第二請求消息是基于第二協(xié)議，即第一請求消息和第二請求消息的消息格式不同。
[0083]205、所述能力開放網(wǎng)關(guān)將所述第二請求消息通過所述第二標準接口發(fā)送至PCRF。
[0084]其中，所述第二標準接口是基于第二協(xié)議的標準接口，任意支持第二協(xié)議的設(shè)備均可以通過所述第二標準接口與所述能力開放網(wǎng)關(guān)進行通信。
[0085]206、所述PCRF接收所述第二請求消息，根據(jù)所述第二請求消息為所述用戶終端重新配置QoS策略，以及所述用戶終端重新配置與所述QoS策略對應(yīng)的PCC(Policy andCharging Control，策略與計費控制)策略。
[0086]207、所述 PCRF 將所述 QoS 策略和 PCC 策略發(fā)送至 PGW(Packet data networkGateffay,分組數(shù)據(jù)網(wǎng)關(guān))。[0087]208、所述PGW根據(jù)所述QoS策略為所述用戶終端重新配置業(yè)務(wù)承載，通過所述業(yè)務(wù)承載對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；同時，所述PGW還將所述重新配置的PCC策略發(fā)送至PGW,由所述PGW將所述PCC策略發(fā)送至OCS (Online Charging System,在線計費裝置)，以使得所述OCS根據(jù)所述PCC策略對所述用戶終端進行計費。
[0088]具體的，當所述第一請求消息為用戶級請求消息時，所述PCRF為所述用戶終端重新配置的QoS策略用于指示所述PGW為所述用戶終端的重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速；
[0089]當所述第一請求消息為業(yè)務(wù)級請求消息時，所述PCRF為所述用戶終端重新配置的QoS策略用于指示所述PGW為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0090]本發(fā)明實施例提供的數(shù)據(jù)業(yè)務(wù)加速方法，在實現(xiàn)業(yè)務(wù)級加速和用戶級加速的過程中，對外部應(yīng)用層(例如門戶服務(wù)器或OTT服務(wù)器)提供第一 API接口作為統(tǒng)一接口供終端或系統(tǒng)開發(fā)者調(diào)用，對內(nèi)部網(wǎng)元(例如PCRF)提供第二標準接口以支持業(yè)務(wù)流程。與現(xiàn)有技術(shù)相比，由于對內(nèi)部網(wǎng)元提供了基于第二協(xié)議的第二標準接口作為統(tǒng)一接口，使得OCS和PCRF無需定制SOAP協(xié)議，能夠降低通信運營商的部署周期，降低運維成本。
[0091]實施例三
[0092]用戶終端在訂購了用戶級加速業(yè)務(wù)之后，會存在如下問題:由于Rx是基于業(yè)務(wù)會話的，PCRF需要由AF來通知建立Rx會話從而向PGW下發(fā)對應(yīng)的QoS策略；而PortalServer不是標準AF，無法感知用戶業(yè)務(wù)流或PDP用戶會話狀態(tài)，因此訂購用戶級加速業(yè)務(wù)后，如果用戶終端下線后再重新上線，由于Portal Server無法感知用戶業(yè)務(wù)流或PDP用戶會話狀態(tài)，因此不會觸發(fā)PCRF申請QoS策略變更，導(dǎo)致用戶訂購的用戶級加速無法生效。
[0093]為了解決上述問題，在實施例二的基礎(chǔ)上，進一步的，本實施例提供了另一種數(shù)據(jù)業(yè)務(wù)加速方法，如圖3所示，所述方法包括:
[0094]301、所述能力開放網(wǎng)關(guān)檢測所述用戶終端是否建立IP-CAN(IP_ConnectivityAccess Network,互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò))會話。
[0095]為了便于理解，如圖4所示，本實施例提供一種用戶級加速業(yè)務(wù)和業(yè)務(wù)級加速的融合架構(gòu)以供參考。值得說明的是，圖1所示實施例一、圖2所示實施例二、以及圖3所示實施例三都可以通過圖4所示融合架構(gòu)圖進行實現(xiàn)，但不僅限于此。
[0096]302、當檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0097]具體的，關(guān)于步驟301和步驟302，本實施例提供了如下三種方法以供參考:
[0098]方法一:
[0099]通過PGW感知用戶終端是否建立所述IP-CAN會話，具體包括:
[0100]S1、對于訂購了加速業(yè)務(wù)套餐的用戶終端，服務(wù)器向能力開放網(wǎng)關(guān)訂購關(guān)于所述用戶終端的F1DP(Packet Data Protocol,包數(shù)據(jù)協(xié)議)會話上線通知事件；
[0101]S2、當PGW檢測到IP-CAN會話重建時，PGW通過AAA或者其他消息方式通知能力開放網(wǎng)關(guān)；
[0102]S3、所述能力開放網(wǎng)關(guān)將用戶上線事件通知門戶服務(wù)器；[0103]S4、所述門戶服務(wù)器向能力開放網(wǎng)關(guān)發(fā)起策略申請，攜帶套餐對應(yīng)的流描述和帶寬信息，對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。具體過程參見圖2所示實施例二中的205-208。
[0104]方法二:
[0105]通過PCRF感知所述用戶終端是否建立所述IP-CAN會話，具體包括:
[0106]S1、對于訂購了加速業(yè)務(wù)套餐的用戶終端，服務(wù)器到能力開放網(wǎng)關(guān)和PCRF安裝IP-CAN上線通知事件；PCRF在監(jiān)測到用戶終端重新上線后，將上線事件通知能力開放網(wǎng)關(guān);
[0107]S2、所述能力開放網(wǎng)關(guān)將用戶上線事件通知到門戶服務(wù)器；
[0108]S3、所述門戶服務(wù)器向能力開放網(wǎng)關(guān)發(fā)起策略申請，攜帶套餐對應(yīng)的流描述和帶寬信息，對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。具體過程參見圖2所示實施例二中的205-208。
[0109]方法三
[0110]通過所述用戶終端的客戶端感知所述用戶終端是否建立IP-CAN會話，具體包括:
[0111]S1、對于訂購了加速業(yè)務(wù)套餐的用戶終端，該用戶終端下線時，PCRF通過標準RX方式通知門戶服務(wù)器，所述門戶服務(wù)器記錄該用戶終端的在線狀態(tài)；
[0112]S2、如果所述用戶終端重新建立IP-CAN會話，安裝于所述用戶終端的客戶端感知到重建后，所述客戶端將上線事件通知所述門戶服務(wù)器；
[0113]S3、所述門戶服務(wù)器向能力開放網(wǎng)關(guān)發(fā)起策略申請，攜帶套餐對應(yīng)的流描述和帶寬信息，對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。具體過程參見圖2所示實施例二中的205-208。
[0114]本實施例提供的數(shù)據(jù)業(yè)務(wù)加速方法，適用于訂購了用戶級加速業(yè)務(wù)的用戶終端從離線狀態(tài)切換至上線狀態(tài)時激活用戶級加速業(yè)務(wù)的實現(xiàn)過程，使得用戶終端在重新上線后能夠及時激活用戶訂購用戶級加速業(yè)務(wù)，使用戶獲得更體驗。
[0115]實施例四
[0116]本實施例提供了一種數(shù)據(jù)業(yè)務(wù)加速裝置，能夠?qū)崿F(xiàn)上述所有方法實施例，所述裝置通過第一應(yīng)用程序編程API接口與門戶服務(wù)器和OTT服務(wù)器相連，所述裝置可以集成在上述方法實施例中提供的能力開放網(wǎng)關(guān)上，也可以集成在現(xiàn)有的其他網(wǎng)元設(shè)備上(例如GGSN、PGW等)，但不僅限于此。如圖5所示，所述裝置50包括:
[0117]第一接收單元501，用于通過所述第一 API接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；
[0118]協(xié)議轉(zhuǎn)換單元502，用于對所述第一接收單元501接收的第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議、且所述第二請求消息通過第二標準接口進行發(fā)送，所述第二請求消息用于請求為所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；
[0119]第一發(fā)送單元503，用于將所述協(xié)議轉(zhuǎn)換單元502得到的第二請求消息通過所述第二標準接口發(fā)送至策略與計費規(guī)則功能體PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略，并將所述QoS策略發(fā)送至分組數(shù)據(jù)網(wǎng)關(guān)PGff,由所述PGW根據(jù)所述QoS策略為所述用戶終端重新配置業(yè)務(wù)承載，通過所述業(yè)務(wù)承載對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。[0120]具體的，所述第一接收單元501獲取的第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0121]具體的，所述第一接收單元501還用于當所述第一請求消息為用戶級請求消息時，通過所述第一 API接口接收門戶服務(wù)器發(fā)送的用戶級請求消息，所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY ；
[0122]其中，所述QoS策略用于指示所述PGW為所述用戶終端的重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速。
[0123]具體的，所述第一接收單元501具體用于當所述第一請求消息為業(yè)務(wù)級請求消息時，通過所述第一 API接口接收OTT Server發(fā)送的業(yè)務(wù)級請求消息,所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)；
[0124]其中，所述QoS策略用于指示所述PGW為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0125]進一步的，如圖6所示，所述裝置還包括:
[0126]檢測單元504，用于檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話；
[0127]觸發(fā)單元505，用于當所述檢測單元504檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器或OTT服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器或OTT激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0128]可選的，所述檢測單元504具體用于通過PGW感知所述用戶終端是否建立所述IP-CAN會話；或者
[0129]所述檢測單元504還用于通過PCRF感知所述用戶終端是否建立所述IP-CAN會話；或者
[0130]所述檢測單元504還用于通過所述用戶終端的客戶端感知所述用戶終端是否建立所述IP-CAN會話。
[0131]本發(fā)明實施例提供的數(shù)據(jù)業(yè)務(wù)加速裝置，在實現(xiàn)業(yè)務(wù)級加速和用戶級加速的過程中，對外部應(yīng)用層(例如門戶服務(wù)器或OTT服務(wù)器)提供第一 API接口作為統(tǒng)一接口供終端或系統(tǒng)開發(fā)者調(diào)用，對內(nèi)部網(wǎng)元(例如PCRF)提供第二標準接口以支持業(yè)務(wù)流程。與現(xiàn)有技術(shù)相比，由于對內(nèi)部網(wǎng)元提供了基于第二協(xié)議的第二標準接口作為統(tǒng)一接口，使得OCS和PCRF無需定制SOAP協(xié)議，能夠降低通信運營商的部署周期，降低運維成本。
[0132]實施例五
[0133]本實施例提供了一種數(shù)據(jù)業(yè)務(wù)加速裝置，能夠?qū)崿F(xiàn)上述所有方法實施例，所述裝置可以集成在上述方法實施例中提供的能力開放網(wǎng)關(guān)上，也可以集成在現(xiàn)有的其他網(wǎng)元設(shè)備上(例如GGSN、PGW等)，但不僅限于此。如圖7所示，所述裝置70包括:第一 API接口701、第二標準接口 702和處理器703，其中:
[0134]所述第一 API接口 701用于與門戶服務(wù)器或者互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器OTT Server進行交互；
[0135]所述第二標準接口 702，用于與策略與計費規(guī)則功能體PCRF進行交互；[0136]所述處理器703用于:
[0137]通過所述第一API接口 701獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速；
[0138]對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議；
[0139]將所述第二請求消息通過所述第二標準接口 702發(fā)送至策略與計費規(guī)則功能體PCRF,以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略，并將所述QoS策略發(fā)送至分組數(shù)據(jù)網(wǎng)關(guān)PGW，由所述PGW根據(jù)所述QoS策略為所述用戶終端重新配置業(yè)務(wù)承載，通過所述業(yè)務(wù)承載對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0140]可選的，本實施例中，所述PCRF還用于在接收到所述處理器703發(fā)送的所述第二請求消息后，根據(jù)所述第二請求消息為所述用戶終端重新配置與所述QoS策略對應(yīng)的策略與計費控制PCC策略，并將所述重新配置的PCC策略發(fā)送至分組數(shù)據(jù)網(wǎng)關(guān)PGW，由所述PGW將所述PCC策略發(fā)送至在線計費裝置0CS，以使得所述OCS根據(jù)所述PCC策略對所述用戶終端進行計費。
[0141]具體的，所述處理器703通過所述第一 API接口 701獲取的所述第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0142]一方面，當所述第一請求消息為用戶級請求消息時，所述處理器703用于通過所述第一 API接口 701接收門戶服務(wù)器Portal Server發(fā)送的所述用戶級請求消息,所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY，用于為所述用戶的所有數(shù)據(jù)業(yè)務(wù)進行加速。。
[0143]本實施例中，當所述接收機接收的第一請求消息為用戶級請求消息時，所述PCRF用于為所述用戶終端重新配置QoS策略，所述QoS策略用于指示所述PGW為所述用戶終端重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速。
[0144]另一方面，當所述第一請求消息為業(yè)務(wù)級請求消息時，所述處理器703用于通過所述第一 API接口 701接收互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器OTT Server發(fā)送的業(yè)務(wù)級請求消息，所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)，用于為所述用戶的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0145]本實施例中，當所述處理器703接收的第一請求消息為用戶級請求消息時，所述PCRF用于為所述用戶終端重新配置QoS策略，所述QoS策略用于指示所述PGW為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)重新配置業(yè)務(wù)承載，根據(jù)重新配置的業(yè)務(wù)承載為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
[0146]可選的，所述處理器703還用于檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話；當所述處理器703檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
[0147]具體的，所述處理器703可用于通過PGW感知所述用戶終端是否建立所述IP-CAN會話；或者[0148]所述處理器703還用于通過PCRF感知所述用戶終端是否建立所述IP-CAN會話；或者
[0149]所述處理器703還用于通過所述用戶終端的客戶端感知所述用戶終端是否建立所述IP-CAN會話。
[0150]本發(fā)明實施例提供的數(shù)據(jù)業(yè)務(wù)加速裝置，在實現(xiàn)業(yè)務(wù)級加速和用戶級加速的過程中，對外部應(yīng)用層(例如門戶服務(wù)器或OTT服務(wù)器)提供第一 API接口作為統(tǒng)一接口供終端或系統(tǒng)開發(fā)者調(diào)用，對內(nèi)部網(wǎng)元(例如PCRF)提供第二標準接口以支持業(yè)務(wù)流程。與現(xiàn)有技術(shù)相比，由于對內(nèi)部網(wǎng)元提供了基于第二協(xié)議的第二標準接口作為統(tǒng)一接口，使得OCS和PCRF無需定制SOAP協(xié)議，能夠降低通信運營商的部署周期，降低運維成本。
[0151]通過以上的實施方式的描述，所屬領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可借助軟件加必需的通用硬件的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在可讀取的存儲介質(zhì)中，如計算機的軟盤，硬盤或光盤等，包括若干指令用以使得一臺計算機設(shè)備(可以是個人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述的方法。
[0152]以上所述，僅為本發(fā)明的【具體實施方式】，但本發(fā)明的保護范圍并不局限于此，任何熟悉本【技術(shù)領(lǐng)域】的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應(yīng)以所述權(quán)利要求的保護范圍為準。
【權(quán)利要求】
1.一種數(shù)據(jù)業(yè)務(wù)加速裝置，其特征在于，包括:第一應(yīng)用程序編程接口 API接口，第二標準接口和處理器； 所述第一 API接口，用于與門戶服務(wù)器或者互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器OTT Server進行交互； 所述第二標準接口，用于與策略與計費規(guī)則功能體PCRF進行交互； 所述處理器，用于: 通過所述第一 API接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速； 對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議； 將所述第二請求消息通過所述第二標準接口發(fā)送至策略與計費規(guī)則功能體PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略。
2.根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述處理器通過所述第一API接口獲取的所述第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用 戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
3.根據(jù)權(quán)利要求2所述的裝置，其特征在于，當所述第一請求消息為用戶級請求消息時，所述處理器用于通過所述第一 API接口獲取第一請求消息包括: 所述處理器用于通過所述第一 API接口接收門戶服務(wù)器Portal Server發(fā)送的所述用戶級請求消息，所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY，用于為所述用戶的所有數(shù)據(jù)業(yè)務(wù)進行加速。
4.根據(jù)權(quán)利要求2所述的裝置，其特征在于，當所述第一請求消息為業(yè)務(wù)級請求消息時，所述處理器用于通過所述第一 API接口獲取第一請求消息包括: 所述處理器用于通過所述第一 API接口接收所述OTT Server發(fā)送的業(yè)務(wù)級請求消息，所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)，用于為所述用戶的指定數(shù)據(jù)業(yè)務(wù)進行加速。
5.根據(jù)權(quán)利要求2所述的裝置，其特征在于，所述處理器還用于檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話；當所述處理器檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
6.根據(jù)權(quán)利要求5所述的裝置，其特征在于，所述處理器具體用于通過PGW感知所述用戶終端是否建立所述IP-CAN會話；或者 所述處理器還用于通過PCRF感知所述用戶終端是否建立所述IP-CAN會話；或者 所述處理器還用于通過所述用戶終端的客戶端感知所述用戶終端是否建立所述IP-CAN 會話。
7.一種數(shù)據(jù)業(yè)務(wù)加速方法，其特征在于，包括: 通過第一應(yīng)用程序編程API接口獲取第一請求消息，所述第一請求消息符合第一協(xié)議，所述第一請求消息用于請求為用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速； 對所述第一請求消息進行格式轉(zhuǎn)換，得到第二請求消息，所述第二請求消息符合第二協(xié)議； 將所述第二請求消息通過所述第二標準接口發(fā)送至策略與計費規(guī)則功能體PCRF，以使得所述PCRF根據(jù)所述第二請求消息為所述用戶終端重新配置服務(wù)質(zhì)量QoS策略。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述第一請求消息包括用戶級請求消息或業(yè)務(wù)級請求消息，其中，所述用戶級請求消息用于請求為所述用戶終端的所有數(shù)據(jù)業(yè)務(wù)進行加速，所述業(yè)務(wù)級請求消息用于請求為所述用戶終端的指定數(shù)據(jù)業(yè)務(wù)進行加速。
9.根據(jù)權(quán)利要求8所述的方法，其特征在于，當所述第一請求消息為用戶級請求消息時，所述通過第一 API接口獲取第一請求消息，包括: 通過所述第一 API接口接收門戶服務(wù)器Portal Server發(fā)送的用戶級請求消息，所述用戶級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為ANY2ANY，用于為所述用戶的所有數(shù)據(jù)業(yè)務(wù)進行加速。
10.根據(jù)權(quán)利要求8所述的方法，其特征在于，當所述第一請求消息為業(yè)務(wù)級請求消息時，所述通過第一 API接口獲取第一請求消息，包括: 通過所述第一 API接口接收互聯(lián)網(wǎng)業(yè)務(wù)服務(wù)器OTT Server發(fā)送的業(yè)務(wù)級請求消息，所述業(yè)務(wù)級請求消息包括用戶標識信息，所述用戶級請求消息攜帶的目標業(yè)務(wù)流類型為指定數(shù)據(jù)業(yè)務(wù)，用 于為所述用戶的指定數(shù)據(jù)業(yè)務(wù)進行加速。
11.根據(jù)權(quán)利要求8所述的方法，其特征在于，還包括: 檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話； 當檢測到用戶終端建立所述IP-CAN會話時，向門戶服務(wù)器發(fā)送上線提示消息，所述上線提示消息用于指示所述門戶服務(wù)器激活所述用戶終端對應(yīng)的加速業(yè)務(wù)，所述加速業(yè)務(wù)用于對所述用戶終端的數(shù)據(jù)業(yè)務(wù)進行加速。
12.根據(jù)權(quán)利要求11所述的方法，其特征在于，所述檢測所述用戶終端是否建立互聯(lián)網(wǎng)協(xié)議連接訪問網(wǎng)絡(luò)IP-CAN會話，包括: 通過PGW感知所述用戶終端是否建立所述IP-CAN會話；或者 通過PCRF感知所述用戶終端是否建立所述IP-CAN會話；或者 通過所述用戶終端的客戶端感知所述用戶終端是否建立所述IP-CAN會話。
【文檔編號】H04L29/08GK103973588SQ201310034445
【公開日】2014年8月6日 申請日期:2013年1月29日 優(yōu)先權(quán)日:2013年1月29日
【發(fā)明者】沈智敏, 劉清順, 韓文勇, 周文濤 申請人:華為技術(shù)有限公司