[發(fā)明專利]會(huì)話的管理方法、策略服務(wù)器及應(yīng)用功能裝置

有效

• 申請(qǐng)?zhí)枺?/td>: 201410007840.0
• 申請(qǐng)日: 2014-01-08
• 公開（公告）號(hào): CN104767722B
• 公開（公告）日: 2019-02-19
• 發(fā)明（設(shè)計(jì)）人: 周曉云;吳錦花
• 申請(qǐng)（專利權(quán)）人: 中興通訊股份有限公司
• 主分類號(hào): H04L29/06
• 分類號(hào): H04L29/06;H04L29/08
• 代理公司: 北京康信知識(shí)產(chǎn)權(quán)代理有限責(zé)任公司 11240
• 代理人: 余剛;梁麗超

本發(fā)明公開了一種會(huì)話的管理方法、策略服務(wù)器及應(yīng)用功能實(shí)體，在上述方法中，策略服務(wù)器接收來(lái)自于AF的第一HTTP請(qǐng)求消息，該第一HTTP請(qǐng)求消息用于在策略服務(wù)器與AF之間建立AF會(huì)話，第一HTTP請(qǐng)求消息中攜帶有AF會(huì)話標(biāo)識(shí)信息；策略服務(wù)器接收來(lái)自于AF的第二HTTP請(qǐng)求消息，并在確定第二HTTP請(qǐng)求消息中不攜帶AF會(huì)話標(biāo)識(shí)信息的情況下，將第二HTTP請(qǐng)求消息掛起；策略服務(wù)器在感知到與AF會(huì)話對(duì)應(yīng)的承載層事件后，向AF返回與第二HTTP請(qǐng)求消息對(duì)應(yīng)的第二HTTP應(yīng)答消息，該第二HTTP應(yīng)答消息中攜帶的信息包括：AF會(huì)話標(biāo)識(shí)信息和承載層事件。由此減少了網(wǎng)絡(luò)資源的占用，降低了實(shí)現(xiàn)復(fù)雜度。

技術(shù)領(lǐng)域

本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種會(huì)話的管理方法、策略服務(wù)器及應(yīng)用功能實(shí)體。

背景技術(shù)

圖1是根據(jù)相關(guān)技術(shù)的第三代合作伙伴計(jì)劃（3rd Generation PartnershipProject，簡(jiǎn)稱為 3GPP）定義的策略和計(jì)費(fèi)控制（Policy and Charging Control，簡(jiǎn)稱為PCC）的架構(gòu)示意圖。圖2是根據(jù)相關(guān)技術(shù)的部署PC的PCC架構(gòu)示意圖。如圖1和圖2所示，策略和計(jì)費(fèi)規(guī)則功能（Policy and Charging Rules Function，簡(jiǎn)稱為PCRF）為業(yè)務(wù)使用網(wǎng)絡(luò)資源進(jìn)行服務(wù)質(zhì)量（Quality of Service，簡(jiǎn)稱為QoS）和計(jì)費(fèi)策略的制訂。而PCRF制定上述控制策略需要結(jié)合從應(yīng)用功能（Application Function，簡(jiǎn)稱為AF）接收的業(yè)務(wù)信息，從用戶簽約數(shù)據(jù)庫(kù)（Subscription Profile Repository，簡(jiǎn)稱為SPR）接收的用戶簽約信息，運(yùn)營(yíng)商配置的策略等。 PCRF將為業(yè)務(wù)制定的控制策略下發(fā)給策略和計(jì)費(fèi)執(zhí)行功能（Policy andCharging Enforcement Function，簡(jiǎn)稱為PCEF）或者承載綁定和事件上報(bào)功能（BearerBinding and Event Report Function，簡(jiǎn)稱為BBERF）執(zhí)行。與此同時(shí)，PCRF可以向PCEF和/或BBERF訂閱承載層相關(guān)事件，以便當(dāng)承載層發(fā)生上述事件時(shí)能夠及時(shí)感知，并更改控制策略。此外，PCEF以及業(yè)務(wù)檢測(cè)功能（Traffic Detection Function，簡(jiǎn)稱為TDF）能夠根據(jù)PCRF下發(fā)的PCC規(guī)則（PCEF）或應(yīng)用和檢測(cè)控制（Application Detection and Control，簡(jiǎn)稱為ADC）規(guī)則（TDF）執(zhí)行應(yīng)用檢測(cè)和控制功能。

隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，運(yùn)營(yíng)商需要與第三方數(shù)據(jù)應(yīng)用提供商進(jìn)行互通，為第三方數(shù)據(jù)應(yīng)用提供商所提供的業(yè)務(wù)進(jìn)行QoS保障。由于目前PCC支持的Rx接口采用的是 Diameter協(xié)議，而對(duì)于大多數(shù)第三方數(shù)據(jù)應(yīng)用提供商而言，其更擅長(zhǎng)基于SOAP或REST協(xié)議的開發(fā)。目前業(yè)界研究的PCC架構(gòu)支持基于SOAP/REST協(xié)議的Rx接口提出了以下兩種方案：

方案一、PCRF支持SOAP或REST協(xié)議；

方案二、在PCRF和AF之間設(shè)置一個(gè)稱為協(xié)議轉(zhuǎn)換器（Protocol Converter，簡(jiǎn)稱PC）的網(wǎng)元，用于將SOAP或REST協(xié)議轉(zhuǎn)換成Diameter協(xié)議。目前的SOAP協(xié)議可支持可擴(kuò)展標(biāo)記語(yǔ)言（XML），而REST協(xié)議可支持XML和JSON兩種語(yǔ)言。

Rx接口需要支持雙向通信，即AF向PCRF提供業(yè)務(wù)信息，PCRF需要向AF實(shí)時(shí)的提供承載層事件（Traffic Plane Event）。然而，SOAP或REST協(xié)議都是基于超文本傳輸協(xié)議（Hypertext transfer protocol，簡(jiǎn)稱HTTP），HTTP是一種無(wú)狀態(tài)的協(xié)議，客戶端請(qǐng)求一個(gè)統(tǒng)一資源定位符（URL），服務(wù)器端需要返回響應(yīng)內(nèi)容，連接端口無(wú)法實(shí)現(xiàn)雙向通信。為了能夠?qū)崿F(xiàn)服務(wù)器向客戶端主動(dòng)推送（Push）信息，相關(guān)技術(shù)中提出如下三種技術(shù)方案：

技術(shù)方案一、Polling，即瀏覽器通過(guò)不間斷地發(fā)出請(qǐng)求獲取最新數(shù)據(jù)，以模擬成push。此種方案的缺陷在于延遲高、信令開銷大。