專利名稱：基于會話業(yè)務的網(wǎng)絡側發(fā)起承載建立的方法
技術領域：
本發(fā)明涉及一種發(fā)起承載建立的方法，屬于移動通信技術中的分組域領域，尤其涉及一種基于會話業(yè)務的網(wǎng)絡側發(fā)起承載建立的方法。
背景技術：
如圖1所示，為PCC(基于策略的QoS控制和計費)系統(tǒng)架構示意圖。PCC通過策略機制，將業(yè)務的數(shù)據(jù)流與所分配的資源進行綁定，在數(shù)據(jù)網(wǎng)關上執(zhí)行策略，從而完成QoS控制和計費規(guī)則的應用。圖中的主要網(wǎng)元包括PCRF(Policy and Charging Rule Function，策略與計費規(guī)則功能)為用戶所接入的業(yè)務制定資源和計費策略；本文中也用PCRF指代完成PCRF功能的網(wǎng)元。
PCEF(Policy and Charging Enforcement Function，策略執(zhí)行功能)執(zhí)行來自PCRF的策略的功能，通常在用戶面的網(wǎng)關中，完成資源控制和計費；本文中也用PCRF指代完成PCRF功能的網(wǎng)元。
AF(Application Function，應用功能)處于業(yè)務網(wǎng)中的應用服務器，或者IMS網(wǎng)絡中為承載提供業(yè)務信息功能的網(wǎng)元，如P-CSCF。
SPR(Subscription Profile Repository，簽約信息庫)用戶業(yè)務相關的簽約信息庫。
PCC相關技術到目前已經(jīng)完成基本的通過策略機制協(xié)商和分配所需資源及計費規(guī)則的方法和流程。主要包括終端發(fā)起的承載建立時的策略協(xié)商、決定和執(zhí)行，策略的修改，以及承載的釋放時的策略取消。這些流程能夠處理會話相關和會話無關兩種類型業(yè)務的承載的策略管理。其缺點是這些流程是由UE發(fā)起的承載建立請求觸發(fā)，或PCEF觸發(fā)，或對用戶簽約信息的改變觸發(fā)，對于PCRF而言，它只是被動的接受建立、修改、終止策略的請求，再根據(jù)業(yè)務信息制定或終止相應策略。
對于網(wǎng)絡側如何發(fā)起承載的建立，到目前為止并沒有任何公開的解決方案。

發(fā)明內容
本發(fā)明所要解決的技術問題在于提供一種基于會話業(yè)務的網(wǎng)絡側發(fā)起承載建立的方法，以實現(xiàn)由網(wǎng)絡側發(fā)起承載建立或策略修改的流程。
1、為解決上述技術問題，本發(fā)明提供一種基于會話業(yè)務的網(wǎng)絡側發(fā)起承載建立的方法，首先在網(wǎng)絡側增設一個具有承載決定能力的邏輯網(wǎng)元BDF；當用戶發(fā)起會話業(yè)務，通過信令承載建立會話信息時，相關的會話和業(yè)務信息被發(fā)送給所述BDF；然后該BDF根據(jù)該運營網(wǎng)絡對此業(yè)務的控制方式(包括是否可控，業(yè)務所需要的服務質量等條件)，決定由網(wǎng)絡側發(fā)起實現(xiàn)該業(yè)務的承載的建立，并把該建立承載的決定作為指示發(fā)送給網(wǎng)絡側的負責發(fā)起承載建立請求的網(wǎng)元。
所述具有承載決定能力的邏輯網(wǎng)元可以被整合入網(wǎng)絡側的策略與計費規(guī)則功能網(wǎng)元PCRF中。當用戶發(fā)起會話業(yè)務，通過信令承載建立會話信息，并通過應用功能網(wǎng)元AF將相關的會話和業(yè)務信息發(fā)送給策略規(guī)則功能網(wǎng)元PCRF之后，PCRF根據(jù)業(yè)務類型及運營商為此業(yè)務類型所分配的資源策略，即所需要的服務質量條件，能夠決定由網(wǎng)絡側發(fā)起實現(xiàn)該業(yè)務的承載的建立，并把該決定發(fā)送給網(wǎng)絡側的負責發(fā)起承載建立請求的網(wǎng)元，如信令面負責會話管理的網(wǎng)元，或者用戶面負責策略執(zhí)行的網(wǎng)元等。
另外，PCRF在決定網(wǎng)絡側發(fā)起承載建立之后，可以通過會話信令通知終端承載由網(wǎng)絡側建立。
如果用戶面負責策略執(zhí)行的網(wǎng)元PCEF收到PCRF的創(chuàng)建承載指示，以及為該承載制定的PCC規(guī)則，可以由PCEF創(chuàng)建承載上下文信息并執(zhí)行策略綁定，以及將承載建立請求信息向終端方向的用戶面網(wǎng)元以及終端依次發(fā)送，并向策略規(guī)則功能網(wǎng)元PCRF響應承載建立完成消息。
本發(fā)明通過對網(wǎng)絡要承載的業(yè)務進行策略判斷，決定是否由網(wǎng)絡側發(fā)起新承載建立或原有承載策略規(guī)則的修改，將PCRF作為網(wǎng)絡發(fā)起的承載建立的觸發(fā)網(wǎng)元，針對會話業(yè)務實現(xiàn)了由網(wǎng)絡側發(fā)起承載建立或策略修改。


圖1為現(xiàn)有技術中關于PCC架構的示意圖；圖2為根據(jù)本發(fā)明第一實施例所述的網(wǎng)絡側發(fā)起的承載建立方法流程圖；圖3為根據(jù)本發(fā)明第二實施例所述的網(wǎng)絡側發(fā)起的承載建立方法流程圖；圖4為下一代系統(tǒng)架構演進(SAE)中的網(wǎng)絡示意圖；圖5為根據(jù)本發(fā)明第三實施例所述的網(wǎng)絡側發(fā)起的承載建立方法流程圖。
具體實施例方式
要解決由網(wǎng)絡側如何發(fā)起承載的建立的問題，首先要考慮的是如何觸發(fā)網(wǎng)絡側的網(wǎng)元發(fā)起承載建立。
因此，我們可以在網(wǎng)絡側增設一個具有承載建立判斷功能的邏輯網(wǎng)元BDF(Bearer Decision Function)。當用戶發(fā)起會話業(yè)務，通過信令承載和具有應用功能的網(wǎng)元(如AF)建立會話信息鏈接之后，AF將相關的會話和業(yè)務信息發(fā)送給該具有承載建立判斷功能的邏輯網(wǎng)元BDF。該網(wǎng)元可以和AF以及能發(fā)起承載建立請求的網(wǎng)元(如某個用戶面通路上的GW)連接，并且和用戶的業(yè)務簽約數(shù)據(jù)庫連接，這樣BDF將根據(jù)會話所請求的業(yè)務類別和簽約情況，綜合考慮決定是否為此業(yè)務建立一個新的承載。該網(wǎng)元可以存儲用戶的承載信息，以決定是否采用已有的承載來傳輸請求的業(yè)務。
BDF可以整合入現(xiàn)有的網(wǎng)絡設備中，嵌入后形成一個新的整體的邏輯功能實體?？紤]到在PCC的架構中，PCRF和承載的建立時所需要的策略密切相關，也能感知到所有能控制的業(yè)務類型，因此，可以考慮將BDF嵌入到PCRF中，作為網(wǎng)絡發(fā)起的承載建立的觸發(fā)網(wǎng)元。當然，也可以根據(jù)實際需要而將BDF嵌入其他現(xiàn)有網(wǎng)絡設備中，本發(fā)明對此不作限制。
但出于描述方便的需要，本發(fā)明下面的實施例中所述及的PCRF，是指整合有BDF的PCRF。
對于非會話類業(yè)務(和AF無關)，PCRF只能從PCEF獲取業(yè)務信息，即PCEF在PCRF之前獲得了業(yè)務信息，因此此時PCRF不能做觸發(fā)。
對于會話類業(yè)務(和AF有關)，PCRF從AF獲取業(yè)務信息和建立承載所需要的信息(如IP地址，端口號等)，因此可以判斷和發(fā)起承載的建立。
基于上述分析，在網(wǎng)絡側觸發(fā)承載建立的具體實現(xiàn)方式上，應當包括以下特征1、PCRF作承載建立判斷和觸發(fā)的方法用于會話相關的業(yè)務(AF相關)；2、需要定義由PCRF通過對會話業(yè)務的會話信息和業(yè)務類型的感知來觸發(fā)網(wǎng)絡側發(fā)起的基于會話的業(yè)務的承載的建立機制；3、需要定義從策略執(zhí)行網(wǎng)元向終端側發(fā)起基于會話的承載建立的流程，該流程中融合了策略的分配和執(zhí)行。
下面結合附圖，對本發(fā)明的實施例進行詳說明。
第一實施例PCRF通過指示的方式觸發(fā)會話業(yè)務承載建立的方法和流程。
本流程適合于會話相關的數(shù)據(jù)業(yè)務承載(或稱用戶面承載)建立，一個前提條件是已存在一條用于會話信令交互的承載。當用戶發(fā)起新的會話業(yè)務時，首先通過信令承載建立會話信息，AF將相關的會話和業(yè)務信息發(fā)送給PCRF。本步驟是現(xiàn)有技術。PCRF根據(jù)業(yè)務所需QoS條件，運營策略，同時可能參考用戶簽約情況，決定是否發(fā)起新的承載。本實施例中的新承載所用到的用戶IP地址和已存在的用于會話信令的承載的用戶IP地址相同。
承載建立流程如圖2所示(1)AF收到需要建立會話連接的請求信令，請求中攜帶了會話信息和業(yè)務信息。AF根據(jù)信息中的IP地址或配置信息等為用戶的當前業(yè)務找到對應的PCRF，向PCRF發(fā)送為該業(yè)務授權資源的請求，授權信息中攜帶業(yè)務相關信息。本步驟為已有技術。
(2)PCRF收到授權請求信息后，根據(jù)攜帶的業(yè)務信息(如用戶IP地址)查找PCRF上該用戶的上下文，在沒有查到的情況下，需要創(chuàng)建該用戶的相關上下文信息，并從SPR獲取的用戶簽約信息和運營商為業(yè)務制定的策略信息保存在上下文中。本步驟為已有技術。
(3)PCRF根據(jù)簽約信息和用戶當前的隧道信息，以及要請求的業(yè)務，PCRF判斷是否為用戶新建一條承載實現(xiàn)該業(yè)務，還是選擇當前的某一條承載實現(xiàn)該業(yè)務。在沒有承載的情況下，將作出決定為用戶建立承載。
(4)PCRF將該決定通過一個指示的形式包含在消息中返回給AF，該指示用于通知終端，該業(yè)務的承載從網(wǎng)絡側發(fā)起建立。本步驟是現(xiàn)有技術的改進，即需要更改消息中的參數(shù)，即擴展相關的傳輸協(xié)議，同時終端要能識別該指示。更改部分是本發(fā)明內容。
(5)PCRF將指示消息通過Gx接口發(fā)送給PCEF。消息中攜帶了會話信息(包括IP地址，端口號等)。本步驟為本發(fā)明內容。
(6)PCEF根據(jù)指示消息中的內容創(chuàng)建承載上下文信息。本步驟為本發(fā)明內容。
(7)PCEF向PCRF發(fā)送策略請求消息。本步驟為已有技術。
(8)PCRF制定的策略發(fā)送給PCEF。本步驟為已有技術。
(9)PCEF執(zhí)行策略綁定，本步驟為已有技術。
(10)如果在線計費系統(tǒng)(OCS)可用，則PCEF向OCS獲取信用。
(11)PCEF將承載建立請求信息向終端方向的用戶面網(wǎng)元以及終端依次發(fā)送。請求消息中包含了創(chuàng)建上下文所需要的信息，如承載標識，用戶標識等。所發(fā)送的網(wǎng)元地址可以在已經(jīng)建立的信令承載的上下文記錄查到。本步驟為本發(fā)明內容。
(12)PCEF將收到承載建立完成消息。消息中可能包含承載標識和用戶標識，用戶地址等信息。本步驟為本發(fā)明內容。
(13)PCEF向PCRF回應建立完成消息。消息中可能包含承載標識和用戶標識，用戶地址等信息。本步驟為本發(fā)明內容。
注流程第4步，也可以放在最后一步之后進行。這時承載已經(jīng)建立完成。PCRF可以將承載標識發(fā)送給AF進而帶回給終端，以告知終端通過此承載傳輸業(yè)務。
第二實施例PCRF通過策略決策觸發(fā)會話業(yè)務承載建立的方法。
本流程適合于會話相關的數(shù)據(jù)業(yè)務承載(或稱用戶面承載)建立，一個前提條件是已存在一條用于會話信令交互的承載。當用戶發(fā)起新的會話業(yè)務時，首先通過信令承載建立會話信息，AF將相關的會話和業(yè)務信息發(fā)送給PCRF。本步驟是現(xiàn)有技術。PCRF根據(jù)業(yè)務所需QoS條件，同時可能參考用戶簽約情況，決定是否發(fā)起新的承載。本實施例中的新承載所用到的用戶IP地址和已存在的用于會話信令的承載的用戶IP地址相同。
本實施例與實施例一的區(qū)別在于本例中PCRF將承載指示和策略規(guī)則放在一起一次發(fā)給PCEF，減少了PCRF與PCEF的一次信令交互。但相應的要對Gx接口進行擴展。
承載建立流程如圖3所示(1)AF收到需要建立會話連接的請求信令，請求中攜帶了會話信息和業(yè)務信息。AF根據(jù)信息中的IP地址或配置信息等為用戶的當前業(yè)務找到對應的PCRF，向PCRF發(fā)送為該業(yè)務授權資源的請求，授權信息中攜帶業(yè)務相關信息。本步驟為已有技術。
(2)PCRF收到授權請求信息后，根據(jù)攜帶的業(yè)務信息(如用戶IP地址)查找PCRF上該用戶的上下文，在沒有查到的情況下，需要創(chuàng)建該用戶的相關上下文信息，并從SPR獲取的用戶簽約信息和運營商為業(yè)務制定的策略信息保存在上下文中。本步驟為已有技術。
(3)PCRF根據(jù)簽約信息和用戶當前的隧道信息，以及要請求的業(yè)務，PCRF判斷是否為用戶新建一條承載實現(xiàn)該業(yè)務，還是選擇當前的某一條承載實現(xiàn)該業(yè)務。在沒有承載的情況下，將作出決定為用戶建立承載。同時根據(jù)已有的業(yè)務信息為該承載制定PCC規(guī)則。本步驟中承載建立部分相關部分為本發(fā)明內容，PCC規(guī)則部分為現(xiàn)有技術。
(4)PCRF將該決定通過一個指示的形式包含在消息中返回給AF，該指示用于通知終端，該業(yè)務的承載從網(wǎng)絡側發(fā)起建立。本步驟是現(xiàn)有技術的改進，即需要更改消息中的參數(shù)，即擴展相關的傳輸協(xié)議，同時終端要能識別該指示。更改部分是本發(fā)明內容。
(5)PCRF將承載指示以及PCC規(guī)則通過Gx接口發(fā)送給PCEF。消息中攜帶了指示承載建立，建立所需要的會話信息(包括IP地址，端口號等)，以及為該承載建立所制定的策略規(guī)則。本步驟中策略規(guī)則部分為已有技術，新增的承載指示及會話信息為本發(fā)明內容。
(6)如果在線計費系統(tǒng)(OCS)可用，則PCEF根據(jù)用戶信息向OCS獲取信用。
(7)PCEF根據(jù)指示消息中的內容創(chuàng)建承載上下文信息，同時完成策略的綁定。本步驟為本發(fā)明內容。
(8)PCEF將承載建立請求信息向終端方向的用戶面網(wǎng)元以及終端依次發(fā)送。請求消息中包含了創(chuàng)建上下文所需要的信息，如隧道標識，用戶標識等。所發(fā)送的網(wǎng)元地址可以在已經(jīng)建立的信令承載的上下文記錄查到。本步驟為本發(fā)明內容。
(9)PCEF將收到承載建立完成消息。消息中可能包含承載標識和用戶標識，用戶地址等信息。本步驟為本發(fā)明內容。
(10)PCEF向PCRF回應建立和綁定完成消息。消息中可能包含承載標識和用戶標識，用戶地址等信息。本步驟中的綁定完成為已有技術，新增建立完成消息的內容為發(fā)明內容。
注流程第4步，也可以放在最后一步之后進行。這時承載已經(jīng)建立完成。PCRF可以將承載標識發(fā)送給AF進而帶回給終端，以告知終端通過此承載傳輸業(yè)務。
第三實施例PCRF通過指示信令面網(wǎng)元的方式觸發(fā)會話業(yè)務承載建立的方法和流程。
本實施例以SAE架構和流程為背景。SAE架構如圖4所示，MME/UPE中的MME是負責信令面的移動性管理和會話管理的邏輯功能實體。IASA是負責用戶面數(shù)據(jù)流轉發(fā)和傳輸?shù)木W(wǎng)關，具有PCEF的功能。本圖中AF處于Op，IP Serv部分中。
參考圖5，本實施例與第一實施例的不同在于本例中PCRF指示了負責會話管理的信令面網(wǎng)元發(fā)起承載建立請求(參考步驟5、步驟6)，請求到PCEF時，PCEF再向PCRF請求PCC規(guī)則(參考步驟7)。其他同第一實施例類似。
權利要求
1.一種基于會話業(yè)務的網(wǎng)絡側發(fā)起承載建立的方法，其特征在于，包括在網(wǎng)絡側增設一個具有承載決定能力的邏輯網(wǎng)元BDF；當用戶發(fā)起會話業(yè)務，通過信令承載建立會話信息時，相關的會話和業(yè)務信息被發(fā)送給所述BDF；該BDF根據(jù)運營網(wǎng)絡對此業(yè)務的控制方式，決定由網(wǎng)絡側發(fā)起實現(xiàn)該業(yè)務的承載的建立，并把該建立承載的決定作為指示發(fā)送給網(wǎng)絡側的負責發(fā)起承載建立請求的網(wǎng)元。
2.如權利要求1所述的方法，其特征在于，所述具有承載決定能力的邏輯網(wǎng)元可以被整合入網(wǎng)絡側的策略與計費規(guī)則功能網(wǎng)元PCRF中。
3.如權利要求1所述的方法，其特征在于，所述將相關的會話和業(yè)務信息發(fā)送給所述BDF的步驟，是通過應用功能網(wǎng)元AF將相關的會話和業(yè)務信息發(fā)送給所述具有承載決定能力的邏輯網(wǎng)元。
4.如權利要求1所述的方法，其特征在于，所述將相關的會話和業(yè)務信息發(fā)送給所述具有承載決定能力的邏輯網(wǎng)元的步驟，是通過應用功能網(wǎng)元AF將相關的會話和業(yè)務信息發(fā)送給策略與計費規(guī)則功能網(wǎng)元PCRF，再由所述PCRF發(fā)送給所述具有承載決定能力的邏輯網(wǎng)元。
5.如權利要求2所述的方法，其特征在于，進一步包括所述整合有該具有承載決定能力的網(wǎng)元的PCRF在決定網(wǎng)絡側發(fā)起承載建立之后，通過會話信令將承載由網(wǎng)絡側建立的決定通知終端。
6.如權利要求1所述的方法，其特征在于，所述網(wǎng)絡側的負責發(fā)起承載建立請求的網(wǎng)元包括用戶面負責策略執(zhí)行的網(wǎng)元PCEF，其中當該PCEF接收到所述PCRF的創(chuàng)建承載指示時，進一步從PCRF獲取該承載的PCC規(guī)則，由PCEF創(chuàng)建承載上下文信息并執(zhí)行策略綁定，將承載建立請求信息向終端方向的用戶面網(wǎng)元以及終端依次發(fā)送，并向所述PCRF響應承載建立完成消息。
7.如權利要求1所述的方法，其特征在于，所述網(wǎng)絡側的負責發(fā)起承載建立請求的網(wǎng)元包括信令面負責會話管理的網(wǎng)元，其中當該信令面負責會話管理的網(wǎng)元接收到所述PCRF的創(chuàng)建承載指示后，向用戶面負責策略執(zhí)行的網(wǎng)元PCEF發(fā)起承載建立請求，所述PCEF進一步從PCRF獲取該承載的PCC規(guī)則，由PCEF創(chuàng)建承載上下文信息并執(zhí)行策略綁定，將承載建立請求信息向終端方向的用戶面網(wǎng)元以及終端依次發(fā)送，并向所述PCRF響應承載建立完成消息。
8.如權利要求1所述的方法，其特征在于，所述該業(yè)務所需要的服務質量條件，根據(jù)業(yè)務類型及運營商為此業(yè)務類型所分配的資源策略確定。
9.如權利要求2所述的方法，其特征在于，所述決定由網(wǎng)絡側發(fā)起實現(xiàn)該業(yè)務的承載的建立的步驟，包括根據(jù)簽約信息和用戶當前的隧道信息，以及要請求的業(yè)務，所述整合有該具有承載決定能力的網(wǎng)元的PCRF判斷并決定是否為用戶新建一條承載實現(xiàn)該業(yè)務，還是選擇當前的某一條承載實現(xiàn)該業(yè)務，其中，在沒有承載的情況下，將決定為用戶新建立一條承載。
10.如權利要求6所述的方法，其特征在于，所述PCEF接收到PCRF的創(chuàng)建承載指示時，進一步從PCRF獲取該承載的PCC規(guī)則的步驟，是由PCRF將所述承載指示與PCC規(guī)則放在一起，一次發(fā)送給PCEF。
11.如權利要求6所述的方法，其特征在于，所述PCEF接收到PCRF的創(chuàng)建承載指示時，進一步從PCRF獲取該承載的PCC規(guī)則的步驟，由PCEF首先向PCRF發(fā)送規(guī)則請求，然后由PCRF將所述為該承載制定的PCC規(guī)則發(fā)送給PCEF。
12.如權利要求5所述的方法，其特征在于，所述整合有該具有承載決定能力的網(wǎng)元的PCRF通過會話信令將承載由網(wǎng)絡側建立的決定通知終端的步驟，包括PCRF將該決定通過一個指示的形式包含在消息中返回給AF，該指示用于通知終端，該業(yè)務的承載從網(wǎng)絡側發(fā)起建立。
13.如權利要求5所述的方法，其特征在于，所述整合有該具有承載決定能力的網(wǎng)元的PCRF通過會話信令將承載由網(wǎng)絡側建立的決定通知終端的步驟，包括PCRF將收到的建立完成響應消息中攜帶的承載標識發(fā)送給AF，并進而帶回給終端，以告知終端通過該承載傳輸業(yè)務。
14.如權利要求6或7所述的方法，其特征在于，進一步包括如果在線計費系統(tǒng)OCS可用，則PCEF根據(jù)用戶信息向OCS獲取信用。
15.如權利要求1所述的方法，其特征在于，所述該具有承載決定能力的網(wǎng)元可以和應用功能網(wǎng)元AF以及能發(fā)起承載建立請求的網(wǎng)元連接，并且和用戶的業(yè)務簽約數(shù)據(jù)庫連接，這樣BDF將根據(jù)會話所請求的業(yè)務類別和簽約情況，綜合考慮決定是否為此業(yè)務建立一個新的承載。
16.如權利要求1所述的方法，其特征在于，所述BDF網(wǎng)元存儲用戶的承載信息，以決定是否采用已有的承載來傳輸請求的業(yè)務。
全文摘要
本發(fā)明公開了一種基于會話業(yè)務的網(wǎng)絡側發(fā)起承載建立的方法，在網(wǎng)絡側增設一個具有承載決定能力的邏輯網(wǎng)元BDF；當用戶發(fā)起會話業(yè)務，通過信令承載建立會話信息時，相關的會話和業(yè)務信息被發(fā)送給所述BDF；該BDF根據(jù)該運營網(wǎng)絡對此業(yè)務的控制方式，決定由網(wǎng)絡側發(fā)起實現(xiàn)該業(yè)務的承載的建立，并把該建立承載的決定作為指示發(fā)送給網(wǎng)絡側的負責發(fā)起承載建立請求的網(wǎng)元。本發(fā)明針對會話業(yè)務實現(xiàn)了由網(wǎng)絡側發(fā)起承載建立或策略修改。
文檔編號H04L12/16GK101087248SQ20061009390
公開日2007年12月12日 申請日期2006年6月23日 優(yōu)先權日2006年6月23日
發(fā)明者王志海, 王衛(wèi)斌 申請人:中興通訊股份有限公司