專利名稱：一種業(yè)務處理方法
技術領域：
本發(fā)明涉及一種業(yè)務處理方法，尤其涉及一種根據(jù)多條流映射技術的處理IPTN業(yè)務的方法。
背景技術：
當前網(wǎng)絡技術的發(fā)展使得在分組網(wǎng)上承載語音成為可能，并且，豐富的、要求快速推出的業(yè)務需求促成了軟交換(SoftSwitch)體系結構的出現(xiàn)。同時，標志著新一代電信網(wǎng)絡時代的到來的下一代網(wǎng)絡(NGN)是開放的、基于IP的網(wǎng)絡，其中，傳統(tǒng)的電信交換設備的功能被分離，形成獨立發(fā)展的各個部件，并且各個部件之間通過標準的協(xié)議進行配合。而在IP網(wǎng)絡被商用化后，作為電信業(yè)務的基礎平臺存在問題如下1、QoS(服務質(zhì)量)問題ISP(互聯(lián)網(wǎng)服務提供商)/ICP(互聯(lián)網(wǎng)內(nèi)容提供商)沒有能力向用戶保證服務質(zhì)量，無法向用戶收取足夠的費用；且IP網(wǎng)絡暫時不能滿足專線用戶需求，很難部署實時業(yè)務，三網(wǎng)(有線電視網(wǎng)、移動通信網(wǎng)和互聯(lián)網(wǎng))的融合也還很難落實。
2、安全問題無處不在的黑客使得業(yè)務不時受到攻擊等等，這些都將導致無法提高用戶體驗，特別是使得企業(yè)用戶顧慮重重。
3、管理問題傳統(tǒng)IP網(wǎng)絡沒有定義和設計針對公眾環(huán)境的管理維護體系，從而當網(wǎng)絡發(fā)生故障時，無法對故障進行定位或者定位不夠迅速。
4、價值鏈問題傳統(tǒng)IP網(wǎng)絡的“免費”模式導致了“網(wǎng)絡泡沫經(jīng)濟”，其急需建立良性的運營模式，從而形成用戶、ISP、ICP等的良性價值鏈。
在此基礎上，為解決IP網(wǎng)絡QoS、安全、管理等問題，現(xiàn)已提出了一種IP電信網(wǎng)(IPTN)的概念和架構，對現(xiàn)有IP網(wǎng)絡進行了改造。該IP電信網(wǎng)可以承載傳統(tǒng)的PSTN(公共交換電話網(wǎng))業(yè)務和數(shù)據(jù)專線業(yè)務，同時支持電信級服務質(zhì)量(QoS)的IP新業(yè)務。
圖1顯示了IPTN的總體框架圖。
如圖1所示，該IPTN主要包括業(yè)務控制層、承載控制層、邏輯承載網(wǎng)和基礎物理網(wǎng)。其中，作為呼叫代理的CA位于業(yè)務控制層，其完成各種業(yè)務控制，該CA可以是軟交換設備、視頻點播服務器(VOD Server)、虛擬專用網(wǎng)管理器(VPNManager)等。
承載控制層中具有RM(資源管理服務器)，該RM的作用為管理邏輯承載網(wǎng)的資源；接受來自業(yè)務控制層的資源請求，決定是否接納呼叫，并指定業(yè)務流路徑，控制邊緣路由器(ER)完成業(yè)務感知，從而達到電信級業(yè)務在使用前申請資源、使用中保證資源、使用后釋放資源的效果。
邏輯承載網(wǎng)中具有邊緣路由器(ER)、匯聚路由器(BR)，該ER接受承載控制層中RM下發(fā)的QoS控制命令，完成流分類，及標簽棧壓入等工作。該BR與ER一起組成MPLS(多協(xié)議標簽交換)網(wǎng)絡，通過標簽棧把多條LSP(標簽交換路徑)連接成一條IPTN路徑，保證各種業(yè)務流能在一定QoS保證的情況下到達目的地。
其中，多個MA管理區(qū)(域)分別對應多個資源管理器RM(例如，MA1對應RM1，MA2對應RM2等)。
根據(jù)圖1所示的IPTN的總體框架，用戶可以通過呼叫發(fā)出業(yè)務請求，經(jīng)由CA、RM、ER建立與目標用戶的通話。
但是，在NGN電信級IP電話應用中，運營商對于音頻和視頻數(shù)據(jù)流的QoS有不同的要求，比如視頻流要求的帶寬比音頻流大，而對于數(shù)據(jù)的延遲，則音頻流的要求相對視頻流要高。而現(xiàn)有的技術是將視頻流和音頻流合在一起作為同一個業(yè)務由RM下發(fā)，在同一條LSP路徑中轉(zhuǎn)發(fā)，這樣兩條流(視頻流和音頻流)就有可能會互相影響，比如視頻流的帶寬會擠占音頻流的帶寬，而造成通話質(zhì)量下降。
由于上述缺點，運營商希望在開展IPTN可視電話業(yè)務的一次通話業(yè)務中，能針對語音和視頻分別下發(fā)流規(guī)則，從而分別進行QoS調(diào)度和帶寬預留，甚至最好使得音頻流和視頻流(或多種語言的語言流)分別走不同的物理鏈路。
但是在現(xiàn)有技術中，每次RM下發(fā)IPTN業(yè)務只能有一條規(guī)則，對應一個動作。要實現(xiàn)上面所述的運營商的需求，就必須針對一次通話而下發(fā)兩次業(yè)務，然而對于RM來說，由于針對一次通話的兩個業(yè)務彼此是獨立的，如果分別進行流量統(tǒng)計，這就對計費增加了難度；而且，如果其中一個業(yè)務所在的鏈路失敗，而另一個業(yè)務不能感知，則會出現(xiàn)用戶在打視頻電話時只看到畫面而沒有聲音，或者只有聲音而沒有畫面的情況，這種情況顯然不能被用戶接受。但是如果在RM資源管理器這一級，對于上述針對一個通話的兩個業(yè)務進行統(tǒng)一管理，這又增加了部署和管理的難度。
因此，有必要設計一種新的流映射技術，從而實現(xiàn)在同一業(yè)務下，多條流獨立存在，且可以統(tǒng)一計流量，統(tǒng)一進行管理。

發(fā)明內(nèi)容
本發(fā)明的目的是提供根據(jù)多條流映射技術的處理業(yè)務的方法。
根據(jù)本發(fā)明的目的，本發(fā)明提供一種業(yè)務處理方法，其用于處理源用戶對目標用戶的業(yè)務請求，包括根據(jù)所述源用戶的業(yè)務請求，由資源管理服務器向所述源用戶和目標用戶對應的路由器分別下發(fā)所述業(yè)務的多條流映射消息；所述源用戶和目標用戶對應的路由器根據(jù)所述多條流映射消息，完成流映射安裝，打開并執(zhí)行策略開關，并針對流進行報文分類、QoS動作和預留帶寬；以及所述源用戶和目標用戶對應的路由器對所述業(yè)務的多條流進行統(tǒng)一管理和計量。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述業(yè)務的每條流具有不同的規(guī)則，且對應不同的QoS指標和標簽交換路徑。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述資源管理服務器根據(jù)鏈路拓撲和資源信息判斷是否接受所述源用戶的業(yè)務請求。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述路由器在進行流映射安裝時，如果所述業(yè)務的其中一條流安裝失敗，則所述業(yè)務的所有流都不會被安裝。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述業(yè)務的進行過程中，所述業(yè)務的每條流使用同一物理鏈路或使用不同的物理鏈路。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述業(yè)務的進行過程中，當所述業(yè)務的一條流對應的物理鏈路出現(xiàn)問題時，所述路由器向所述資源管理服務器上報，且在所述資源管理服務器的指令下，刪除該條流所屬業(yè)務的所有流。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，屬于同一業(yè)務的多條流在源用戶側(cè)完成拆分。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，屬于同一業(yè)務的多條流在所述資源管理服務器側(cè)完成拆分。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述資源管理服務器在一次通話中同時下發(fā)屬于一個業(yè)務的多條流映射。
根據(jù)本發(fā)明提供的業(yè)務處理方法，其中，所述資源管理服務器在一次通話中多次下發(fā)屬于一個業(yè)務的多條流映射。
本發(fā)明的有益效果是本發(fā)明可以在一個IPTN業(yè)務中使用多條規(guī)則，執(zhí)行不同的動作，從而在一次通話中為語音和視頻分別預留各自的帶寬，保證各自不同的QoS指標，并且在同一IPTN業(yè)務下，多條流是獨立存在。另外本發(fā)明也可以實現(xiàn)針對流的統(tǒng)一計量和統(tǒng)一管理。


圖1顯示了IPTN的總體框架圖；圖2顯示了依照本發(fā)明的IPTN業(yè)務的處理流程。
具體實施例方式
圖2顯示了依照本發(fā)明的IPTN業(yè)務的處理流程。其中，IPTN業(yè)務的呼叫系統(tǒng)包括NGN業(yè)務單元100(呼叫代理100)、多個資源管理服務器(RM1、RM2、RM3)、對應RM1的MA1(管理區(qū)1)、對應RM2的MA2(管理區(qū)2)、對應RM3的MA3(管理區(qū)3)、在各個MA中的ER和BR、以及用戶終端A和B。該用戶終端A的IP地址屬于管理區(qū)1，該用戶終端B的IP地址屬于管理區(qū)3。
如圖2所示，本發(fā)明的IPTN業(yè)務的呼叫建立流程具體如下步驟1用戶終端A發(fā)起呼叫，觸發(fā)業(yè)務請求。
步驟2NGN業(yè)務單元100對來自用戶終端A的業(yè)務請求進行分析，獲取通話雙方的IP地址(用戶終端A和目標通話用戶終端B的地址)、以及TCP/UDP端口號，并且根據(jù)該業(yè)務請求中音頻和視頻數(shù)據(jù)流所需的QoS指標，向RM1申請資源。
步驟3RM1搜集鏈路拓撲和資源信息，分別計算本地所管理的資源情況，只有滿足每一個資源請求(例如QoS音頻和視頻數(shù)據(jù)流各自的請求)，呼叫才會被接納；如果RM1發(fā)現(xiàn)資源不足以建立連接，或者其中某一條請求的資源不滿足，就拒絕用戶終端A的呼叫，則RM1向NGN業(yè)務單元100返回呼叫失??；如果用戶終端A的呼叫的每一個資源請求都可以被接納，則繼續(xù)建立呼叫連接。
步驟4RM1在接納用戶終端A的呼叫后，根據(jù)通話雙方的IP地址，按照預定的選路策略進行選路，將選路結果向下一個域(對應于MA2)的RM2發(fā)出該資源請求，該RM2收到請求后同樣根據(jù)資源使用情況確定接納還是拒絕用戶終端A的呼叫，如果接受則根據(jù)選路結果再次向下一個域(對應于MA3)的RM3發(fā)出資源請求，如果RM3同樣接收該資源請求，由于RM3接收的資源請求信息中的目的IP地址(目標通話用戶終端B的地址)屬于本域，則用戶終端A的呼叫被接納。
步驟5在用戶終端A的呼叫被接納的情況下，RM3通過COPS(通用開放策略服務)協(xié)議，向?qū)谀康腎P地址(目標通話用戶終端B的地址)的ER下發(fā)多條流映射請求，其中，RM3將多條數(shù)據(jù)流(音頻流、視頻流等)的請求在同一個業(yè)務中下發(fā)，每條流具有不同的規(guī)則(例如音頻流可能使用UDP的2001端口號，而視頻流可能使用UDP的2002端口號)，且各自對應不同QoS指標以及LSP路徑。
步驟6對應于目標通話用戶終端B的ER在接收到RM3下發(fā)的流映射請求消息后，從該流映射請求消息中解析出每一條流的信息，分別安裝在本地，如果其中一條流映射安裝失敗，則包括多條流的整個業(yè)務都不會被安裝，并且該ER向RM3上報流映射安裝失??；如果在同一個業(yè)務中的所有流映射都安裝成功，則該ER向RM3上報流映射安裝成功的響應消息；其中，ER完成了多條流映射后，將打開并執(zhí)行策略開關，其用于進行之后的動作，即，針對流進行報文分類，對于匹配的流給予相應的QoS保證(執(zhí)行QoS動作，例如打優(yōu)先級標記、報文鏡像、報文重定向、報文統(tǒng)計、報文允許、報文過濾等)及帶寬預留；如果不打開并執(zhí)行策略開關，ER將把報文視為普通的流進行處理，不進行報文分類，則不能進行后續(xù)動作。之后ER向RM3上報QoS資源響應消息，從而開展用戶業(yè)務，并且ER對歸屬于同一業(yè)務的多條流的流量進行統(tǒng)一計數(shù)。
步驟7RM3在接收到來自上述步驟6中ER上報的QoS資源響應消息后，根據(jù)源IP，向上一個域的RM2轉(zhuǎn)發(fā)QoS資源響應消息。
步驟8RM2在接收到步驟7中轉(zhuǎn)發(fā)的QoS資源響應消息后，判斷該消息中的源IP是否屬于本域，由于在本實施例中，該源IP屬于對應于RM1的域，所以RM2向上一個域的RM1轉(zhuǎn)發(fā)QoS資源響應消息。
步驟9；由于LSP(標簽交換路徑)是單向路徑，如要要在終端用戶A和B之間建立通話，則必須在兩個方向上都建立LSP路徑，因此RM需要向源IP地址和目的IP地址兩者分別對應的ER下發(fā)包含內(nèi)容相同、但方向相反的業(yè)務策略的流映射請求，則此時RM1向源IP地址(終端用戶A)對應的ER下發(fā)同一個業(yè)務的多條流映射請求。
步驟10如同步驟6，源IP地址(終端用戶A)對應的ER完成多條流映射后，將執(zhí)行策略開關，針對流進行報文分類，對于匹配的流給予相應的QoS保證及帶寬預留，向RM1上報流映射安裝成功的響應信息，從而開展用戶業(yè)務，并且ER對歸屬于同一業(yè)務的多條流的流量進行統(tǒng)一計數(shù)。
步驟11RM1在接收到流映射安裝成功的響應信息后，此時通話的雙向路徑(用戶終端A和目標通話用戶終端B之間的路徑)已準備就緒，向NGN業(yè)務單元100上報QoS資源響應消息。
步驟12NGN業(yè)務單元100在接收到步驟11中上報的QoS資源響應消息后，完成連接建立過程，則目標通話用戶終端B的振鈴響起，用戶B可使用本發(fā)明提供的IPTN業(yè)務。
其中，在用戶終端A請求的業(yè)務進行的過程中，根據(jù)資源情況和選路結果，該請求的業(yè)務包含的多個流可能使用同一條物理鏈路，也可能使用不同的物理鏈路，如果其中一條流對應的鏈路出現(xiàn)問題，則ER將向RM上報流對應的LSP Down的消息，且RM在搜索到該LSP對應的業(yè)務后，向ER下發(fā)流映射刪除的命令，從而ER會將這條流對應的業(yè)務下的所有流全部刪除。
例如，如果一業(yè)務包括音頻流和視頻流，且音頻流對應的鏈路出現(xiàn)問題時(即此時只有圖像沒有聲音)，則ER將向RM上報流對應的LSP Down的消息，且RM在搜索到該LSP對應的業(yè)務后，向ER下發(fā)流映射刪除的命令，從而ER會將該業(yè)務包括的音頻流和視頻流全部刪除。從而通過統(tǒng)一管理，避免了只有聲音而沒有畫面的情況的發(fā)生。
如上所述，由于本發(fā)明中是通過RM向ER下發(fā)多條流映射的流安裝命令，所以可以在一個IPTN業(yè)務中使用多條規(guī)則(例如針對音頻和視頻的不同規(guī)則)，執(zhí)行不同的動作(例如針對音頻和視頻的不同QoS動作)，從而在一次通話中為語音和視頻分別預留各自的帶寬，保證各自不同的QoS指標。
值得注意的是，本實施例只示例的顯示了3個RM，應理解的是，本實施例也同樣適應于多個RM的環(huán)境。
<修改實施例>
在上述實施例中，是在用戶終端A完成了對流的拆分，且通過RM在一次通話中同時下發(fā)一個業(yè)務的多條流(流的拆分可由現(xiàn)有技術完成)。
而本發(fā)明并不局限于此，也可以在RM上完成對流的拆分，從而通過RM在一次通話中多次下發(fā)流映射，并對這多條流統(tǒng)一進行管理，統(tǒng)一計流量來實現(xiàn)運營商對不同的流的不同QoS需求。
其具體過程與上述步驟1-步驟12相同，只是本實施例可以重復步驟5以多次下發(fā)流映射。
綜上所述，由于IPTN業(yè)務的應用中，運營商對不同的流有不同的QoS需求。根據(jù)該目的，本發(fā)明通過RM向ER下發(fā)多條流映射的流安裝命令，所以可以在一個IPTN業(yè)務中使用多條規(guī)則，執(zhí)行不同的動作，從而在一次通話中為語音和視頻分別預留各自的帶寬，保證各自不同的QoS指標，并且在同一IPTN業(yè)務下，多條流是獨立存在。另外本發(fā)明也可以實現(xiàn)針對流的統(tǒng)一計量和統(tǒng)一管理。
對該技術領域的普通技術人員來說，根據(jù)以上實施類型可以很容易的聯(lián)想到其他的優(yōu)點和變形。因此，本發(fā)明并不局限于上述具體實施例，其僅僅作為例子對本發(fā)明的一種形態(tài)進行詳細、示范性的說明。在不背離本發(fā)明宗旨的范圍內(nèi)，本領域普通技術人員可以根據(jù)上述具體實施例通過各種等同替換所得到的技術方案，但是這些技術方案均應該包含在本發(fā)明的權利要求的范圍及其等同的范圍之內(nèi)。
權利要求
1.一種業(yè)務處理方法，其用于處理源用戶對目標用戶的業(yè)務請求，包括根據(jù)所述源用戶的業(yè)務請求，由資源管理服務器向所述源用戶和目標用戶對應的路由器分別下發(fā)所述業(yè)務的多條流映射消息；所述源用戶和目標用戶對應的路由器根據(jù)所述多條流映射消息，完成流映射安裝，打開并執(zhí)行策略開關，并針對流進行報文分類、QoS動作和預留帶寬；以及所述源用戶和目標用戶對應的路由器對所述業(yè)務的多條流進行統(tǒng)一管理和計量。
2.如權利要求1所述的業(yè)務處理方法，其中，所述資源管理服務器根據(jù)鏈路拓撲和資源信息判斷是否接受所述源用戶的業(yè)務請求。
3.如權利要求1或2所述的業(yè)務處理方法，其中，所述業(yè)務的每條流具有不同的規(guī)則，且對應不同的QoS指標和標簽交換路徑。
4.如權利要求3所述的業(yè)務處理方法，其中，所述路由器在進行流映射安裝時，如果所述業(yè)務的其中一條流安裝失敗，則所述業(yè)務的所有流都不會被安裝。
5.如權利要求4所述的業(yè)務處理方法，其中，所述業(yè)務的進行過程中，所述業(yè)務的每條流使用同一物理鏈路或使用不同的物理鏈路。
6.如權利要求5所述的業(yè)務處理方法，其中，所述業(yè)務的進行過程中，當所述業(yè)務的一條流對應的物理鏈路出現(xiàn)問題時，所述路由器向所述資源管理服務器上報，且在所述資源管理服務器的指令下，刪除該條流所屬業(yè)務的所有流。
7.如權利要求6所述的業(yè)務處理方法，其中，屬于同一業(yè)務的多條流在源用戶側(cè)完成拆分。
8.如權利要求6所述的業(yè)務處理方法，其中，屬于同一業(yè)務的多條流在所述資源管理服務器側(cè)完成拆分。
9.如權利要求7或8所述的業(yè)務處理方法，其中，所述資源管理服務器在一次通話中同時下發(fā)屬于一個業(yè)務的多條流映射。
10.如權利要求7或8所述的業(yè)務處理方法，其中，所述資源管理服務器在一次通話中多次下發(fā)屬于一個業(yè)務的多條流映射。
全文摘要
本發(fā)明提供一種根據(jù)多條流映射技術的處理業(yè)務的方法。該業(yè)務處理方法，其用于處理源用戶對目標用戶的業(yè)務請求，包括根據(jù)所述源用戶的業(yè)務請求，由資源管理服務器向所述源用戶和目標用戶對應的路由器分別下發(fā)所述業(yè)務的多條流映射消息；所述源用戶和目標用戶對應的路由器根據(jù)所述多條流映射消息，完成流映射安裝，打開并執(zhí)行策略開關，并針對流進行報文分類、QoS動作和預留帶寬；以及所述源用戶和目標用戶對應的路由器對所述業(yè)務的多條流進行統(tǒng)一管理和計量。
文檔編號H04L5/00GK1863161SQ20051012417
公開日2006年11月15日 申請日期2005年11月21日 優(yōu)先權日2005年11月21日
發(fā)明者徐銳 申請人:華為技術有限公司