專利名稱：移動通信網絡中處理應用功能實體信息的方法
技術領域：
本發(fā)明涉及移動通信技術領域，尤其涉及一種對應用功能實體發(fā)來的信息進行處理的方法。
背景技術：
隨著移動分組數據業(yè)務應用的逐漸廣泛，如何對移動分組數據業(yè)務進行準確合理地進行計費，已成為移動運營商普遍關注的課題。當前通用分組無線業(yè)務(General Packet Radio Service，GPRS)網絡結構，針對用戶數據流只能識別到接入點名稱(Access Point Name，APN)和分組數據協議內容(Packet DataProtocol context，PDP Context)這一級別。而現實中并行的多個業(yè)務數據流很可能使用同一個PDP Context承載，而不同業(yè)務則可能采用不同的計費方式，而當前GPRS網絡無法滿足這一需求。例如，用戶可能同時進行流媒體業(yè)務和多媒體消息業(yè)務，兩個業(yè)務同時承載在同一個APN和PDP Context中，但計費規(guī)則不同，如流媒體業(yè)務根據用戶數據流量或時間計費，多媒體消息業(yè)務則根據事件計費，如發(fā)送或接收一條消息。
為了對不同類型的IP連接網絡能使用相同的計費解決方案，需要對當前GPRS提出一種新的承載計費結構，采用一種通用的基于流的計費機制。
針對這種情況，目前第三代移動通信標準化的伙伴項目(3rd GenerationPartnership Project，3GPP)正在討論如何實現基于IP流的計費(Flow BasedCharging，FBC)，對于一個分組數據業(yè)務來說，用戶在使用該項業(yè)務所消耗的數據量稱為業(yè)務數據流(Service Data Flow，SDF)，業(yè)務數據流是多個IP流組成的集合。而在一個PDP context中可以承載多個不同的業(yè)務，因此基于IP流的計費粒度可以小于基于PDP context的計費粒度，從而能夠為運營商以及業(yè)務提供商提供更為豐富的計費手段。
在3GPP的TS 23.125中對FBC的系統結構、功能要求以及消息流程等方面進行了描述。
其中支持在線計費的FBC系統結構如圖1所示，支持離線計費的FBC系統結構如圖2所示。
FBC系統的各個功能模塊的作用分別為傳輸面功能模塊(Traffic Plane Function，TPF)是承載分組業(yè)務數據流的功能模塊，可以區(qū)分屬于不同業(yè)務數據流的分組數據包，用于離線計費信息收集和執(zhí)行在線信用控制，當承載發(fā)生變化的時候，比如承載的建立，修改和刪除過程中，TPF通過Gx接口向基于業(yè)務流計費的計費規(guī)則功能模塊(service dataflow based Charging Rule Function，CRF)請求計費規(guī)則，消息中可以攜帶用戶和終端相關的信息，如移動臺國際ISDN號碼MSISDN、國際移動用戶標識IMSI，承載特性，如Qos信息以及網絡相關的信息，如移動網編碼MNC，移動國家碼MCC。根據CRF返回的計費規(guī)則，TPF在對應的業(yè)務數據流上執(zhí)行分組過濾和計費數據收集。
一個TPF可以由一個或者多個CRF服務，根據UE的標識信息來選擇，可以支持預定義的計費規(guī)則以及預定義的過濾器。
CRF是保存計費規(guī)則的功能模塊，支持動態(tài)(根據業(yè)務準則實時生成一些計費規(guī)則數據)和靜態(tài)(在用戶使用數據業(yè)務過程中計費規(guī)則是一成不變的，靜態(tài)計費規(guī)則可以被動態(tài)的激活)的計費規(guī)則。CRF通過接收到的TPF信息、應用功能模塊(Application Function，AF)信息以及在線計費系統(OnlineCharging System，OCS)信息作為輸入，用于選取適當的計費規(guī)則，在TPF請求或者有特定事件觸發(fā)的時候將選取的計費規(guī)則發(fā)送給TPF一個CRF可以對應多個TPF。
AF代表所有和應用相關的功能模塊，可以是運營商自己的，也可以是第三方業(yè)務提供商的，AF向CRF提供相應的信息使得CRF可以選擇或配置相應的計費規(guī)則，AF提供的信息包括業(yè)務數據流的標識信息(可以通配)；計費規(guī)則選擇的信息；應用/業(yè)務標識，應用/業(yè)務計費規(guī)則觸發(fā)事件，用戶信息(比如用戶標識等)，流類型(視頻，音頻)(可選)，流速率(可選)。
一個AF可以對應于多個CRF，AF可以根據UE的標識信息選擇CRF進行交互。
信用控制模塊(Credit Control，CC)是執(zhí)行信用控制的功能模塊，只用于在線計費系統，是通過在現有的OCS中增加新的功能來實現的，通過Ry接口，OCS可以向CRF提供計費規(guī)則選擇的輸入信息。
計費網關功能模塊(Charging Gateway Function，CCF)和計費信息收集功能模塊(Charging Collection Function，CGF)這兩個功能模塊是用于離線計費系統的，可以沿用現有的GPRS網絡計費中的實現。
如果承載網絡是GPRS網絡的話，則TPF位于GGSN處，AF為PDN中的一個業(yè)務網關，或是業(yè)務服務器，當IMS承載在GPRS網絡之上的時候AF就是P-CSCF，CRF為新增的邏輯模塊。
同樣，這種計費機制也可以應用于3GPP2和WLAN的網絡結構中。
同時，3GPP提出了基于業(yè)務的本地策略控制，并定義了UE本地承載業(yè)務、GPRS承載業(yè)務和外部承載業(yè)務之間的交互，以及這些組合在一起為分組域端到端業(yè)務提供QoS。IP承載管理功能(IP BS Manager)在UE和GGSN中都可能存在，一般使用差分服務(DiffServ)或綜合服務/資源預留(IntServ/RSVP)與外部IP網絡進行互通。
3GPP描述了為分組域提供端到端QoS的IP層必需機制，通過基于業(yè)務的本地策略控制機制實現。如圖3所示代理呼叫狀態(tài)控制功能(P-CSCF)作為應用功能的一種，和UE通過SIP協議交互，PDF從應用功能實體處得到應用層協議如會話描述協議(Session Description Protocol，SDP)中的參數，將該應用層參數信息映射到IP QoS參數，如RSVP，該映射遵守特定的策略規(guī)則。策略決策功能實體(Policy Decision Function，PDF)的決策將傳送到GGSN中的IP承載管理功能，進一步通過翻譯/映射功能映射到UMTS承載管理功能上，GGSN完成相應的IP策略執(zhí)行點(IP Policy Enforcement Point，PEP)功能。PDF和GGSN之間的Go接口采用COPS協議，傳送QoS相關信息和策略。
R5中只為IMS業(yè)務提供基于業(yè)務的QoS控制，所以PDF是IMS實體P-CSCF中的邏輯實體。R6階段PDF是一個單獨的功能實體，可以為所有分組域業(yè)務提供基于業(yè)務的QoS策略控制。當其他類型的承載網絡要實現基于業(yè)務的策略控制的時候，PEP就在對應的網關設備上實現。當使用IMS的時候，AF就是P-CSCF。
當UE請求建立傳送業(yè)務數據的承載連接時，PEP向PDF發(fā)送請求(Request，REQ)消息，其中攜帶客戶端的對話信息，用于標識對應PDF的授權令牌以及該會話中一個或者多個流的標識；如果通過了授權，則PDF返回決定(Decision，DEC)消息給PEP，其中攜帶客戶端的對話信息，控制層面計費標識，上下行指示，授權的QOS信息，過濾器信息以及對應的通道是否打開的狀態(tài)信息；然后GGSN會根據DEC的執(zhí)行情況，返回報告(Report，RPT)消息給PDF，報告執(zhí)行的結果等。
策略和計費控制架構則同時提供基于業(yè)務的本地策略控制功能和基于流的計費功能，統一和合并了策略控制和流計費的結構和實現過程，同時考慮了終端用戶簽約時候的差異性以及在策略控制和計費控制方面的通用性，處理的時候將業(yè)務和承載結合起來考慮。
目前策略和計費控制框架和基于業(yè)務數據流計費的框架類似，如圖4所示其中很多功能實體和基于業(yè)務數據流的計費是一樣的，在此不再贅述，新增的實體的功能為策略和計費控制節(jié)點(Policy and Charging Control Node，PCCN)同時包含PDF和CRF的功能，向GW提供有關QOS策略和計費的控制。
網關(GateWay，GW)同時包括PEP和TPF的功能，提供對業(yè)務的QOS控制，基于流的分組計數功能，在線和離線計費交互功能。
這種框架也可以應用于3GPP2和WLAN的網絡結構中。
根據現有的基于業(yè)務數據流計費的實現機制，在承載建立、修改和刪除的時候，TPF都需要向CRF上報一些承載相關信息用于選擇計費規(guī)則，CRF根據來自TPF、AF和OCS的信息進行選擇，決定計費規(guī)則的實施。
和TPF向CRF請求計費規(guī)則的過程相獨立的，AF和OCS也可以向CRF提供選擇計費規(guī)則的輸入信息，其中AF提供的信息和應用層業(yè)務相關，OCS提供的信息則和在線計費中業(yè)務的信用相關，CRF根據可用的信息綜合選擇某個業(yè)務數據流承載計費應該實施的計費規(guī)則。簡單的，可以用圖5說明AF向CRF提供輸入供選擇計費規(guī)則使用1、AF發(fā)送應用/業(yè)務數據流計費信息給CRF；2、CRF確認收到該輸入信息。
通過Rx接口，AF向CRF提供應用/業(yè)務數據流計費信息，CRF根據該信息，選擇和構造適當的計費規(guī)則發(fā)送給TPF。AF決定什么時候發(fā)送該信息給CRF，CRF從收到該信息的那一刻開始在計費規(guī)則的選擇和決定上將應用/業(yè)務信息考慮在內。
在現有的FBC計費方案中，AF和CRF之間存在接口，提供一些和應用相關的信息，用于CRF選擇適當的計費規(guī)則，或者配置計費規(guī)則中的一些參數，運營商在配置CRF中的計費規(guī)則時，可以決定來自AF的哪些數據可用于計費規(guī)則的選擇。目前，AF提供給CRF的信息包括標識業(yè)務數據流的信息基于IP五元組(源IP地址，目的IP地址，源端口號，目的端口號，IP層以上的協議號)的過濾器，端口號和協議號可以通配，IP地址也可以通配或者帶掩碼前綴，來表示很多IP流的聚合；特殊的過濾器，需要深入到分組包的更深層次，或者需要復雜的操作來支持，比如維持狀態(tài)等，這些過濾器可以預先配置在TPF中，由CRF調用。這種過濾器可以用來支持那些基于IP層以上的傳輸層和應用層協議的業(yè)務數據流，比如HTTP和WAP；可選的應用層記錄信息，該信息包含在AF和TPF產生的計費信息中，用于后付費處理的時候關聯計費記錄；支持計費規(guī)則選擇的信息應用/業(yè)務標識，應用/業(yè)務相關事件標識，媒體流類型(視頻，音頻)(可選)，媒體流速率(可選)，用戶信息(比如用戶標識等)。
在現有的策略控制實現中，AF通過Gq接口和PDF交換基于業(yè)務的策略建立信息，以及從PDF中請求授權令牌。目前，AF提供給PDF的信息和FBC中AF提供給CRF的信息類似，包括，IP五元組信息(源IP地址，目的IP地址，源端口號，目的端口號，IP層以上的協議號)，用于關聯計費記錄的IMS計費標識(ICIDIMS Charging IDentifier)，應用標識，各類媒體成分的描述信息(比如媒體流類型，速率等)等等。策略和計費控制框架中，因為PCCN是融合了PDF和CRF兩個功能實體，因此AF提供給PCCN的信息可以認為至少是AF提供給CRF和AF提供給PDF信息的集合，此外，考慮到結合策略實施的計費控制以及集合計費實施的策略控制，今后還可能增加一些新的輸入信息。
在策略和計費控制框架中，為了能夠根據用戶簽約的不同在QOS控制和計費實施上體現出差異，增加了一個簽約文件數據庫，用于為策略和計費控制提供和簽約相關的輸入信息。如圖6所示目前CRF的輸入信息主要來自OCS，AF和TPF，PDF的輸入信息主要來自AF和PEP，PCCN的輸入信息主要來自OCS，AF，TPF，PEP和簽約文件數據庫(Subscription Profile Repository，SPR)。其中OCS、TPF、PEP以及SPR都是位于和CRF、PDF或PCCN同一個運營商的網絡中，因此，來自這些功能實體的輸入信息是可以保證其安全性和有效性的，即這些信息對于CRF來說，不會造成不良影響，而且都是有用的信息。
而AF這個功能實體，具體可以看作是多個應用服務器，它們既可能是運營商網絡中的實體，也可能是第三方網絡中的實體，對于運營商網絡中的實體來說，其安全性是可以保證的，有效性一般來說也是可以保證的，但是對于第三方網絡中的實體，則可能存在不安全的隱患，比如AF輸入一些和當前策略控制或者計費控制無關的信息，CRF、PDF或者PCCN就不得不浪費一部分處理能力來對這些輸入信息進行檢查，判斷其無用之后，做相應的處理，比如丟棄，如果一個AF懷有惡意，可能連續(xù)不斷的輸入應用層相關的信息，而這些信息在CRF、PDF或者PCCN檢查之后可能都是沒有用處的，但是在防火墻是無法檢查出的，因此這種輸入信息會造成其他有效的輸入信息得不到處理能力，從而造成業(yè)務產生較大時延甚至導致超時中斷。這是運營商以及用戶都無法接受的。而且，還可能CRF、PDF或者PCCN收到的來自應用層相關信息完全是正確的和可用的，但是這些信息卻是一個非法的應用功能實體發(fā)送的，這種情況下，如果不對應用層相關信息的來源進行檢查，就可能使用這些看似正確其實是非法的信息選擇計費規(guī)則，造成計費的錯誤或者策略控制的錯誤。
在策略和計費控制結構中，雖然增加了一個和簽約信息相關的數據庫SPR，但是這個數據庫定位是只提供和簽約信息相關的輸入，供PCCN進行QOS策略控制和計費控制使用，也沒有用來對提供應用層輸入信息的AF進行簽約檢查。

發(fā)明內容
本發(fā)明的目的是提出移動通信網絡中處理應用功能實體信息的方法，確?？刂乒?jié)點處理的來自應用層的相關信息都是合法有效的信息，從而避免了無效信息占用控制節(jié)點的處理能力。
為此，本發(fā)明采用如下方案一種移動通信網絡中處理應用功能實體信息的方法，其特征在于包括以下步驟
a、當應用功能實體向控制節(jié)點發(fā)送信息時，根據簽約信息判斷所述應用功能實體是否在簽約信息列表存在，如果是，則轉至步驟b，否則轉至步驟c；b、控制節(jié)點接收所述信息，并進行處理，過程結束；c、控制節(jié)點放棄所述信息。
所述控制節(jié)點可以是計費規(guī)則功能實體，也可以是策略決策功能實體，還可以是策略和計費控制節(jié)點。
所述步驟a進一步包括以下步驟a11、控制節(jié)點設置簽約信息列表，所述簽約信息列表包含有所有向所述控制節(jié)點提供應用層輸入信息的應用功能實體的簽約信息；a12、當應用功能實體向控制節(jié)點發(fā)送信息時，控制節(jié)點在所述簽約信息列表中查找所述應用功能實體發(fā)送的信息中包含的應用/業(yè)務標識，如果有，則判斷所述應用功能實體在簽約信息列表存在，否則所述應用功能實體不在簽約信息列表存在。
所述步驟a12還包括以下步驟a121、控制節(jié)點結合用戶信息中的用戶標識，在所述簽約信息列表中查找和所述用戶相關的服務器中是否包含了所述應用功能實體。
所述步驟a12還包括以下步驟a122、控制節(jié)點結合應用/業(yè)務相關事件標識，在所述簽約信息列表中查找和所述事件相關的服務器中是否包含了所述應用功能實體。
所述步驟a進一步包括以下步驟a21、在一個數據庫中設置簽約信息列表，所述簽約信息列表包含有所有向所述控制節(jié)點提供應用層輸入信息的應用功能實體的簽約信息；a22、當應用功能實體向控制節(jié)點發(fā)送信息時，控制節(jié)點向所述數據庫發(fā)送查詢請求消息，所述數據庫收到查詢請求消息后，在所述簽約信息列表中查找所述應用功能實體發(fā)送的信息中包含的應用/業(yè)務標識，如果有，則轉至步驟a23，否則轉至步驟a24；
a23、所述數據庫向控制節(jié)點返回成功應答消息，控制節(jié)點判斷所述應用功能實體在簽約信息列表存在；a24、所述數據庫向控制節(jié)點返回失敗應答消息，控制節(jié)點判斷所述應用功能實體不在簽約信息列表存在。
所述數據庫可以是簽約文件數據庫，也可以是歸屬簽約用戶服務器，還可以是經過安全認證的數據庫。
所述的方法，如果所述數據庫是簽約文件數據庫，策略和計費控制節(jié)點在向所述數據庫發(fā)送查詢請求消息中可以請求用戶終端的簽約信息，則所述成功應答消息還可以包括所述簽約文件數據庫提供給策略和計費控制節(jié)點的用戶終端的簽約信息。
所述步驟a22還包括以下步驟a221、控制節(jié)點結合用戶信息中的用戶標識，請求所述數據庫在所述簽約信息列表中查找和所述用戶相關的服務器中是否包含了所述應用功能實體。
所述步驟a22還包括以下步驟a222、控制節(jié)點結合應用/業(yè)務相關事件標識，請求所述數據庫在所述簽約信息列表中查找和所述事件相關的服務器中是否包含了所述應用功能實體。
所述步驟a進一步包括以下步驟a31、在一個通過安全性和信息有效性認證的應用功能實體上設置簽約信息列表，所述簽約信息列表包含有所有向所述控制節(jié)點提供應用層輸入信息的應用功能實體的簽約信息；a32、其他應用功能實體首先向設置有簽約信息列表的應用功能實體發(fā)送信息，設置有簽約信息列表的應用功能實體在所述簽約信息列表中查找其他應用功能實體發(fā)送的信息中包含的應用/業(yè)務標識，如果有，則轉至步驟a33，否則所述應用功能實體不在簽約信息列表中存在；a33、設置有簽約信息列表的應用功能實體判斷所述應用功能實體在簽約信息列表存在，并將所述來自應用功能實體的信息轉發(fā)給控制節(jié)點。
采用了本發(fā)明，通過增加對輸入應用層相關信息的功能實體的合法性檢查，確?？刂乒?jié)點處理的來自應用層的相關信息都是合法有效的信息，從而避免了無效信息占用控制節(jié)點的處理能力，避免出現業(yè)務較大的時延或者因超時而導致的業(yè)務中斷，提高用戶對業(yè)務的滿意程度。


圖1是支持在線計費的FBC系統結構圖；圖2是支持離線計費的FBC系統結構圖；圖3是基于業(yè)務的本地策略控制系統結構圖；圖4是策略和計費控制框架示意圖；圖5是現有技術中處理應用功能實體信息的流程圖；圖6是包含有簽約文件數據庫的策略和計費控制框架示意圖；圖7是本發(fā)明中第一種具體實施方式
的流程圖；圖8是本發(fā)明中第二種具體實施方式
的流程圖。
具體實施例方式
下面結合說明書附圖來說明本發(fā)明的具體實施方式
。
本發(fā)明的技術方案中應用到簽約信息列表，該表就是和運營商進行了簽約的一些信息的一個集合，用于在應用過程中通過檢查區(qū)分合法有效的簽約信息和未簽約的其他信息。在本發(fā)明中，如果只是針對應用/業(yè)務標識進行檢查，實現的時候簽約信息列表可以就是所有簽約的應用功能/業(yè)務服務器的標識信息的集合，檢查的時候，用收到的應用/業(yè)務標識在該簽約信息列表中進行查找，找到的話，說明這個應用功能/業(yè)務服務器是合法有效的應用功能/業(yè)務服務器，否則，說明沒有簽約。如果是同時結合應用/業(yè)務標識和用戶標識進行檢查，則簽約信息列表可以是所有簽約的應用功能/業(yè)務服務器以及對應用戶的標識信息的集合。
第一種具體實施方式
是控制節(jié)點處保存和應用相關的服務器簽約信息列表。CRF、PDF或PCCN處維持一個和所有可能提供應用層相關輸入信息給自己處理的服務器的簽約信息列表，當某個AF第一次提供輸入信息給CRF、PDF或PCCN的時候，CRF、PDF或PCCN根據輸入信息中的應用/業(yè)務標識，如果發(fā)現該服務器屬于簽約信息列表，則CRF、PDF或PCCN才進一步處理收到的來自該AF的其他信息，進行計費規(guī)則和/或策略決策的配置或者選擇；進一步的，可以結合用戶標識，檢查簽約信息列表中和該用戶相關的服務器中是否包含了該服務器，包含的話才進行處理；進一步的，還可以結合應用/業(yè)務相關事件標識，檢查簽約信息列表中和對應事件相關的服務器中是否包含了該服務器，包含的話才進行處理；此外，還可以同時結合應用/業(yè)務標識，用戶標識和應用/業(yè)務相關事件標識執(zhí)行上述檢查。
如果簽約檢查沒有通過，則CRF、PDF或PCCN執(zhí)行相應的處理，如丟棄這些輸入信息，返回失敗應答，其中可能帶錯誤原因指示。
考慮到CRF、PDF或PCCN處對AF的檢查主要是確定來自AF的輸入信息是否是有效的，避免無效信息的處理占用大量設備處理能力，因此，一般對應用/業(yè)務標識進行檢查就足夠了，結合用戶標識以及其他信息的檢查可以在應用/業(yè)務標識檢查通過之后的業(yè)務處理過程中同時進行。
如圖7所示，AF發(fā)送應用/業(yè)務相關的做計費和/或策略控制所需的信息給CRF、PDF或PCCN；CRF、PDF或PCCN對于收到的輸入信息，首先根據其中的應用/業(yè)務標識在簽約服務器列表中進行檢查，如果通過，則進行后續(xù)處理，否則，直接丟棄；然后返回確認消息，確認該AF的輸入，對于無效的輸入，可能會指示AF檢查沒有通過。
第二種具體實施方式
是CRF、PDF或PCCN和保存應用相關服務器簽約信息的數據庫之間存在接口。在這種實現方案中，CRF、PDF或PCCN處和保存應用服務器簽約信息的數據庫之間存在接口，這個數據庫可以是策略和計費控制結構中的SPR或者HSS或者其它一個屬于運營商網絡的數據庫，其關鍵點在于這個數據庫中保存了應用服務器的簽約信息。當某個AF第一次提供輸入信息給CRF、PDF或PCCN的時候，CRF、PDF或PCCN根據輸入信息中的應用/業(yè)務標識，有時候還可以結合用戶信息中的用戶標識，以后也可能根據需求擴展到結合其他信息，構造消息，其中包括應用/業(yè)務標識信息，有時候也可以包括用戶標識等信息，進一步的，還可以結合應用/業(yè)務相關事件標識，通過這個接口向該數據庫發(fā)送查詢請求消息，該數據庫收到該請求之后，在本地的簽約信息中進行查找，檢查簽約信息列表中是否包含了該服務器，包含的話才進行處理；此外，還可以同時結合應用/業(yè)務標識，用戶標識和應用/業(yè)務相關事件標識執(zhí)行上述檢查。如果通過了簽約檢查，則返回成功應答，在策略和計費控制結構中，如果這個數據庫是SPR，則在成功應答消息中還可以包括SPR提供給PCCN的簽約相關的信息，如果沒有通過簽約檢查，則返回失敗應答，指示檢查沒有通過，而且應答消息中不攜帶提供給PCCN的簽約相關信息。
CRF、PDF或PCCN只有在收到成功應答的時候才進一步處理收到的來自該AF的其他信息，進行計費規(guī)則和/或策略決策的配置或者選擇，收到失敗應答的時候則執(zhí)行相應的處理，如丟棄這些輸入信息，直接返回確認消息，其中可能帶錯誤原因指示。
考慮到CRF、PDF或PCCN處對AF的檢查主要是確定來自AF的輸入信息是否是有效的，避免無效信息的處理占用大量設備處理能力，因此，一般數據庫中對應用/業(yè)務標識進行檢查就足夠了，結合用戶標識以及其他信息的檢查可以在應用/業(yè)務標識檢查通過之后的業(yè)務處理過程中同時進行。
如圖8所示，AF發(fā)送應用/業(yè)務相關的和計費和/或策略控制所需的信息給CRF、PDF或PCCN；CRF、PDF或PCCN構造消息向保存應用服務器簽約信息的數據庫請求檢查來自該AF的信息是否是有效的，其中包括應用/業(yè)務標識，如果該數據庫中同時保存用戶相關的簽約信息，也可以在這個消息中同時請求；該數據庫根據收到的應用/業(yè)務標識對該AF的有效性進行檢查，如果通過了返回成功應答，其中可以同時包括請求的用戶簽約信息，如果沒有通過，則返回帶錯誤原因的應答消息；CRF、PDF或PCCN根據收到的應答消息中的結果，決定對收到的來自AF的輸入信息的處理，如果通過，則進行后續(xù)處理，否則，直接丟棄；然后返回確認消息，確認該AF的輸入，對于無效的輸入，可能會指示AF檢查沒有通過。
第三種具體實施方式
是AF處統一對提供輸入信息給CRF、PDF或PCCN的應用服務器的身份進行檢查。為了減輕CRF、PDF或PCCN的負擔，在這種實現方案中，將檢查應用服務器身份的功能放在了AF來實現，但是要求這個AF是一個特定的代理應用服務器，該AF和CRF、PDF或PCCN之間的連接是完全可以信任的，不但包括安全性還包括信息的有效性，凡是這個AF向CRF、PDF或PCCN提供的應用/業(yè)務相關信息一定是有效的信息，可以用于本地策略的制定和/或計費規(guī)則的選擇。在這種實現中，這個AF上設置簽約信息列表，簽約信息列表包含有所有向CRF、PDF或PCCN提供應用層輸入信息的應用功能實體的簽約信息，其他的應用服務器都向這個AF發(fā)送信息而不是直接和CRF、PDF或PCCN交互，該AF收到來自其他應用服務器的應用/業(yè)務相關信息之后，在所述簽約信息列表中查找其他AF發(fā)送的信息中包含的應用/業(yè)務標識，如果有，這個AF判斷這些應用功能實體在簽約信息列表存在，并將來自應用功能實體的信息轉發(fā)給CRF、PDF或PCCN。否則不將所述來自應用功能實體的信息轉發(fā)給CRF、PDF或PCCN。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何熟悉該技術的人在本發(fā)明所揭露的技術范圍內，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明的保護范圍應該以權利要求的保護范圍為準。
權利要求
1.一種移動通信網絡中處理應用功能實體信息的方法，其特征在于包括以下步驟a、當應用功能實體向控制節(jié)點發(fā)送信息時，根據簽約信息判斷所述應用功能實體是否在簽約信息列表存在，如果是，則轉至步驟b，否則轉至步驟c；b、控制節(jié)點接收所述信息，并進行處理，過程結束；c、控制節(jié)點放棄所述信息。
2.如權利要求1所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述控制節(jié)點可以是計費規(guī)則功能實體，也可以是策略決策功能實體，還可以是策略和計費控制節(jié)點。
3.如權利要求1或2所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a進一步包括以下步驟a11、控制節(jié)點設置簽約信息列表，所述簽約信息列表包含有所有向所述控制節(jié)點提供應用層輸入信息的應用功能實體的簽約信息；a12、當應用功能實體向控制節(jié)點發(fā)送信息時，控制節(jié)點在所述簽約信息列表中查找所述應用功能實體發(fā)送的信息中包含的應用/業(yè)務標識，如果有，則判斷所述應用功能實體在簽約信息列表存在，否則所述應用功能實體不在簽約信息列表存在。
4.如權利要求3所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a12還包括以下步驟a121、控制節(jié)點結合用戶信息中的用戶標識，在所述簽約信息列表中查找和所述用戶相關的服務器中是否包含了所述應用功能實體。
5.如權利要求3所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a12還包括以下步驟a122、控制節(jié)點結合應用/業(yè)務相關事件標識，在所述簽約信息列表中查找和所述事件相關的服務器中是否包含了所述應用功能實體。
6.如權利要求1或2所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a進一步包括以下步驟a21、在一個數據庫中設置簽約信息列表，所述簽約信息列表包含有所有向所述控制節(jié)點提供應用層輸入信息的應用功能實體的簽約信息；a22、當應用功能實體向控制節(jié)點發(fā)送信息時，控制節(jié)點向所述數據庫發(fā)送查詢請求消息，所述數據庫收到查詢請求消息后，在所述簽約信息列表中查找所述應用功能實體發(fā)送的信息中包含的應用/業(yè)務標識，如果有，則轉至步驟a23，否則轉至步驟a24；a23、所述數據庫向控制節(jié)點返回成功應答消息，控制節(jié)點判斷所述應用功能實體在簽約信息列表存在；a24、所述數據庫向控制節(jié)點返回失敗應答消息，控制節(jié)點判斷所述應用功能實體不在簽約信息列表存在。
7.如權利要求6所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述數據庫可以是簽約文件數據庫，也可以是歸屬簽約用戶服務器，還可以是經過安全認證的數據庫。
8.如權利要求7所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于如果所述數據庫是簽約文件數據庫，策略和計費控制節(jié)點在向所述數據庫發(fā)送查詢請求消息中可以請求用戶終端的簽約信息，則所述成功應答消息還可以包括所述簽約文件數據庫提供給策略和計費控制節(jié)點的用戶終端的簽約信息。
9.如權利要求6所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a22還包括以下步驟a221、控制節(jié)點結合用戶信息中的用戶標識，請求所述數據庫在所述簽約信息列表中查找和所述用戶相關的服務器中是否包含了所述應用功能實體。
10.如權利要求6所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a22還包括以下步驟a222、控制節(jié)點結合應用/業(yè)務相關事件標識，請求所述數據庫在所述簽約信息列表中查找和所述事件相關的服務器中是否包含了所述應用功能實體。
11.如權利要求1或2所述的移動通信網絡中處理應用功能實體信息的方法，其特征在于所述步驟a進一步包括以下步驟a31、在一個通過安全性和信息有效性認證的應用功能實體上設置簽約信息列表，所述簽約信息列表包含有所有向所述控制節(jié)點提供應用層輸入信息的應用功能實體的簽約信息；a32、其他應用功能實體首先向設置有簽約信息列表的應用功能實體發(fā)送信息，設置有簽約信息列表的應用功能實體在所述簽約信息列表中查找其他應用功能實體發(fā)送的信息中包含的應用/業(yè)務標識，如果有，則轉至步驟a33，否則所述應用功能實體不在簽約信息列表中存在；a33、設置有簽約信息列表的應用功能實體判斷所述應用功能實體在簽約信息列表存在，并將所述來自應用功能實體的信息轉發(fā)給控制節(jié)點。
全文摘要
本發(fā)明提出了移動通信網絡中處理應用功能實體信息的方法，包括以下步驟a.當應用功能實體向控制節(jié)點發(fā)送信息時，根據簽約信息判斷所述應用功能實體是否在簽約信息列表存在，如果是，則轉至步驟b，否則轉至步驟c；b.控制節(jié)點接收所述信息，并進行處理，過程結束；c.控制節(jié)點放棄所述信息。本發(fā)明確?？刂乒?jié)點處理的來自應用層的相關信息都是合法有效的信息，從而避免了無效信息占用控制節(jié)點的處理能力，避免出現業(yè)務較大的時延或者因超時而導致的業(yè)務中斷，提高用戶對業(yè)務的滿意程度。
文檔編號H04L12/14GK1805405SQ20051000196
公開日2006年7月19日 申請日期2005年1月13日 優(yōu)先權日2005年1月13日
發(fā)明者武亞娟 申請人:華為技術有限公司