專利名稱：通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)及其方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別涉及通信網(wǎng)絡(luò)中業(yè)務(wù)交互能力管理的實(shí)現(xiàn)技術(shù)。
背景技術(shù)：
網(wǎng)際協(xié)議多媒體子系統(tǒng)(IP Multimedia Subsystem，簡(jiǎn)稱“IMS”)是第三代移動(dòng)通信合作伙伴項(xiàng)目(3rd Generation Partnership Project，簡(jiǎn)稱“3GPP”)R5階段提出的提供網(wǎng)際協(xié)議(Internet Protocol，簡(jiǎn)稱“IP”)多媒體業(yè)務(wù)的子系統(tǒng)。它采用分組域?yàn)槠渖蠈涌刂菩帕詈兔襟w傳輸?shù)某休d通道，并引入會(huì)話初始協(xié)議(Session Initial Protocol，簡(jiǎn)稱“SIP”)作為業(yè)務(wù)控制協(xié)議，利用SIP簡(jiǎn)單、易擴(kuò)展、媒體組合方便的特點(diǎn)，通過將業(yè)務(wù)控制與承載控制分離提供豐富的多媒體業(yè)務(wù)，是業(yè)界普遍認(rèn)同的解決移動(dòng)和固定網(wǎng)絡(luò)融合的理想方案和發(fā)展方向。
IMS網(wǎng)絡(luò)架構(gòu)中的主要功能實(shí)體包括控制用戶注冊(cè)、會(huì)話等功能的呼叫會(huì)話控制功能實(shí)體(Call Session Control Function，簡(jiǎn)稱“CSCF”)、集中管理用戶簽約數(shù)據(jù)的歸屬用戶服務(wù)器(Home Subscriber Server，簡(jiǎn)稱“HSS”)、提供各種業(yè)務(wù)邏輯控制功能的應(yīng)用服務(wù)器(Application Server，簡(jiǎn)稱“AS”)，其它還有多媒體資源控制功能實(shí)體(Multimedia Resource Control Function，簡(jiǎn)稱“MGFC”)、策略判決功能實(shí)體(Policy Decision Function，簡(jiǎn)稱“PDF”)等。其中CSCF按照角色功能又分為代理CSCF(Proxy-CSCF，簡(jiǎn)稱“P-CSCF”)、查詢CSCF(Interrogating-CSCF，簡(jiǎn)稱“I-CSCF”)、服務(wù)CSCF(Serving-CSCF，簡(jiǎn)稱“S-CSCF”)等類型，在邏輯功能上分別完成SIP會(huì)話路由中不同的功能，在物理上可以合一也可以分置。用戶通過當(dāng)前所在地代理節(jié)點(diǎn)P-CSCF接入IMS，會(huì)話和業(yè)務(wù)觸發(fā)控制及與AS的業(yè)務(wù)控制交互則由其注冊(cè)地的歸屬域服務(wù)節(jié)點(diǎn)S-CSCF完成，而I-CSCF則起到路由查詢的作用。
IMS的提出是為了基于IP向用戶提供更為優(yōu)質(zhì)、廉價(jià)的多媒體業(yè)務(wù)和應(yīng)用。AS在業(yè)務(wù)提供過程中扮演了業(yè)務(wù)執(zhí)行者的角色。業(yè)務(wù)的提供過程可分為下列四個(gè)步驟(這里假設(shè)從會(huì)話的發(fā)起側(cè)考慮)1)IMS業(yè)務(wù)檔案的下載，在用戶注冊(cè)的過程中，一個(gè)包含業(yè)務(wù)和用戶相關(guān)數(shù)據(jù)的業(yè)務(wù)檔案由HSS下載到服務(wù)于此用戶S-CSCF中。業(yè)務(wù)檔案中的初始過濾準(zhǔn)則，包含了是否將用戶的請(qǐng)求路由到相關(guān)的AS的觸發(fā)信息。在這里，觸發(fā)信息可能是根據(jù)請(qǐng)求消息的請(qǐng)求URI(例如一個(gè)語音信箱voice@ims.com)或請(qǐng)求的類型(如立即消息的MESSAGE請(qǐng)求)等來制定。
2)用戶請(qǐng)求的生成，用戶需要某種業(yè)務(wù)時(shí)，利用自己的設(shè)備生成相關(guān)的請(qǐng)求。例如，用戶想要建立一個(gè)語音通話。他利用UE生成一個(gè)INVITE請(qǐng)求(包含請(qǐng)求URI，媒體描述等信息)，這條請(qǐng)求經(jīng)P-CSCF，到達(dá)服務(wù)于他的S-CSCF。
3)AS的選擇，用戶的請(qǐng)求到達(dá)S-CSCF后，S-CSCF檢索與請(qǐng)求的發(fā)起者匹配的業(yè)務(wù)檔案。根據(jù)業(yè)務(wù)檔案中的初始過濾準(zhǔn)則，S-CSCF決定將請(qǐng)求路由到相應(yīng)的AS或是直接進(jìn)行轉(zhuǎn)發(fā)。
4)AS執(zhí)行相關(guān)的服務(wù)，在收到請(qǐng)求后，AS開始執(zhí)行相關(guān)的服務(wù)。為了開展服務(wù)，AS可以工作在以下四種模式終止UA-在這種模式下，AS充當(dāng)了UE。比如，在消息類業(yè)務(wù)中，假設(shè)消息的接收方設(shè)置了某種過濾的準(zhǔn)則，當(dāng)其得到滿足時(shí)，AS可能會(huì)代表接收方生成一個(gè)最終響應(yīng)這時(shí)AS是作為一個(gè)SIP UA。
CSCF不再需要處理業(yè)務(wù)邏輯，而是通過基于規(guī)則的業(yè)務(wù)觸發(fā)機(jī)制，根據(jù)用戶的簽約數(shù)據(jù)的初始過濾規(guī)則(initial Filtering Constraint，簡(jiǎn)稱“iFC”)，由CSCF分析并觸發(fā)到規(guī)則指定的應(yīng)用服務(wù)器，由應(yīng)用服務(wù)器完成業(yè)務(wù)邏輯處理。這樣的方式下，使得IMS成為了一個(gè)真正意義上的控制層設(shè)備，與業(yè)務(wù)的藕合降低到最小。ISC接口基于SIP這一唯一的協(xié)議，這樣更有利于業(yè)務(wù)的開放，同時(shí)由于IMS與業(yè)務(wù)做到了高度的獨(dú)立，為新增業(yè)務(wù)而進(jìn)行控制層設(shè)備大范圍網(wǎng)絡(luò)升級(jí)的情況將得到根本改觀，業(yè)務(wù)的快速推出成為可能。
IMS作為下一代電信網(wǎng)絡(luò)體系架構(gòu)，必然是一種多業(yè)務(wù)的應(yīng)用架構(gòu)，在多業(yè)務(wù)應(yīng)用的情況下，必然產(chǎn)生多種業(yè)務(wù)之間的協(xié)同性和一致性問題，先有的iFC觸發(fā)機(jī)制所能解決的業(yè)務(wù)交互管理問題顯然已經(jīng)不能勝任將來多網(wǎng)融合、多業(yè)務(wù)種類并行的情況。多業(yè)務(wù)交互沖突所存在的問題不能得到解決，則嚴(yán)重阻礙下一代通信網(wǎng)絡(luò)的演進(jìn)。
目前業(yè)界提出的實(shí)現(xiàn)業(yè)務(wù)能力交互管理(Service Capability InteractionManager，簡(jiǎn)稱“SCIM”)的功能實(shí)體，也被形象地稱為業(yè)務(wù)經(jīng)紀(jì)人(servicebroker)。所謂的Service broker的作用，就是提供多業(yè)務(wù)融合，解決多業(yè)務(wù)間的交互和可能出現(xiàn)的沖突問題，service broker的概念在IMS域內(nèi)和域外都有所應(yīng)用，但根本的焦點(diǎn)還是解決IMS域內(nèi)各個(gè)AS的業(yè)務(wù)交互或沖突問題。到目前為止，service broker已經(jīng)被引入了3GPP的相應(yīng)規(guī)范，在OSA GW的相應(yīng)規(guī)范中也有所體現(xiàn)。service broker的邏輯功能，可以位于AS上，也可以作為獨(dú)立邏輯實(shí)體，3GPP引入SCIM，其位于AS上，其主要的作用就是完成service broker的功能。
目前3GPP還沒有對(duì)service broker或SCIM給出具體的完整規(guī)范，各個(gè)主流廠家也還沒有給出具體的技術(shù)實(shí)現(xiàn)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)及其方法，使得通信網(wǎng)絡(luò)中多業(yè)務(wù)交互和沖突問題得到解決，實(shí)現(xiàn)多業(yè)務(wù)能力交互管理功能。
為實(shí)現(xiàn)上述目的，本發(fā)明提供了一種通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，包含至少一個(gè)仲裁者模塊和一個(gè)管理者模塊，所述仲裁者模塊用于在受本次呼叫產(chǎn)生的消息觸發(fā)并獲得控制權(quán)后，根據(jù)預(yù)先配置的規(guī)則和通過與所述管理者模塊交互得到的本次呼叫相關(guān)信息，對(duì)本次呼叫產(chǎn)生的消息進(jìn)行處理，并對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁；所述管理者模塊用于管理所有呼叫相關(guān)信息，管理控制權(quán)的轉(zhuǎn)交，通過與所述仲裁者模塊交互以更新本次呼叫相關(guān)信息并向所述仲裁者提供查詢。
其中，所述仲裁者模塊對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁時(shí)，修改本次呼叫產(chǎn)生的消息，并轉(zhuǎn)發(fā)給目的網(wǎng)元，然后修改所述業(yè)務(wù)的狀態(tài)，并移交控制權(quán)給對(duì)應(yīng)的應(yīng)用服務(wù)器。
此外在所述系統(tǒng)中，所述應(yīng)用服務(wù)器根據(jù)所對(duì)應(yīng)的業(yè)務(wù)的狀態(tài)決定業(yè)務(wù)的動(dòng)作，所述業(yè)務(wù)的狀態(tài)包含懸掛、嵌套、中斷、互斥，其中，當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為嵌套且第一個(gè)業(yè)務(wù)嵌套在第二個(gè)業(yè)務(wù)中時(shí)，第一個(gè)業(yè)務(wù)處于嵌套狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為中斷且第一個(gè)業(yè)務(wù)中斷第二個(gè)業(yè)務(wù)時(shí)，第一個(gè)業(yè)務(wù)處于中斷狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為互斥且第一個(gè)業(yè)務(wù)優(yōu)先級(jí)高于第二個(gè)業(yè)務(wù)時(shí)，執(zhí)行第一個(gè)業(yè)務(wù)，并終止第二個(gè)業(yè)務(wù)。
此外在所述系統(tǒng)中，所述管理者模塊還用于給所述仲裁者模塊配置規(guī)則、記錄呼叫處理信息，并決定控制權(quán)在所述仲裁者模塊及應(yīng)用服務(wù)器之間轉(zhuǎn)交。
此外在所述系統(tǒng)中，所述管理者模塊還用于管理呼叫相關(guān)信息，包含呼叫的處理過程、呼叫的業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)、呼叫的注冊(cè)業(yè)務(wù)信息、和呼叫的處理規(guī)則。
此外在所述系統(tǒng)中，所述仲裁者通過執(zhí)行預(yù)先配置的腳本，對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁。
此外在所述系統(tǒng)中，所述仲裁者用于在獲得控制權(quán)后，執(zhí)行腳本進(jìn)行仲裁，先根據(jù)本次呼叫產(chǎn)生的消息和待仲裁業(yè)務(wù)，查找二維規(guī)則表，根據(jù)表項(xiàng)中規(guī)則條件與本次呼叫相關(guān)信息匹配結(jié)果，執(zhí)行仲裁。
此外在所述系統(tǒng)中，所述管理者模塊控制所述仲裁者模塊的產(chǎn)生與消亡，所述仲裁者模塊在與其相關(guān)的消息觸發(fā)時(shí)產(chǎn)生，在與其相關(guān)的交互業(yè)務(wù)終止后消亡。
本發(fā)明還提供了一種通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，包含步驟A由本次呼叫產(chǎn)生的消息觸發(fā)，對(duì)應(yīng)仲裁者模塊獲得控制權(quán)；B該仲裁者模塊與所述管理者模塊交互，得到本次呼叫相關(guān)信息；C該仲裁者模塊根據(jù)預(yù)先配置的規(guī)則及本次呼叫相關(guān)信息，對(duì)本次呼叫產(chǎn)生的消息進(jìn)行處理，并對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁；D所述管理者模塊更新本次呼叫相關(guān)信息。
其中，所述步驟C包含以下子步驟C1所述仲裁者模塊根據(jù)預(yù)先配置的規(guī)則及本次呼叫相關(guān)信息進(jìn)行仲裁；C2所述仲裁者模塊修改本次呼叫產(chǎn)生的消息，并轉(zhuǎn)發(fā)給目的網(wǎng)元；C3所述仲裁者模塊修改所述業(yè)務(wù)的狀態(tài)，并移交控制權(quán)給對(duì)應(yīng)的應(yīng)用服務(wù)器。
此外在所述方法中，所述步驟C3進(jìn)一步包含以下子步驟
所述應(yīng)用服務(wù)器根據(jù)所對(duì)應(yīng)的業(yè)務(wù)的狀態(tài)決定業(yè)務(wù)的動(dòng)作，所述業(yè)務(wù)的狀態(tài)包含懸掛、嵌套、中斷、互斥，其中，當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為嵌套且第一個(gè)業(yè)務(wù)嵌套在第二個(gè)業(yè)務(wù)中時(shí)，第一個(gè)業(yè)務(wù)處于嵌套狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為中斷且第一個(gè)業(yè)務(wù)中斷第二個(gè)業(yè)務(wù)時(shí)，第一個(gè)業(yè)務(wù)處于中斷狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為互斥且第一個(gè)業(yè)務(wù)優(yōu)先級(jí)高于第二個(gè)業(yè)務(wù)時(shí)，執(zhí)行第一個(gè)業(yè)務(wù)，并終止第二個(gè)業(yè)務(wù)。
此外在所述方法中，還包含步驟所述管理者模塊預(yù)先給所述仲裁者模塊配置規(guī)則，在呼叫過程中記錄該呼叫的處理信息，并決定控制權(quán)在所述仲裁者模塊及應(yīng)用服務(wù)器之間轉(zhuǎn)交。
此外在所述方法中，所述管理者模塊所管理的呼叫相關(guān)信息包含呼叫的處理過程、呼叫的業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)、呼叫的注冊(cè)業(yè)務(wù)信息、和呼叫的處理規(guī)則。
此外在所述方法中，所述步驟C中所述仲裁者通過執(zhí)行預(yù)先配置的腳本，對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁。
此外在所述方法中，所述步驟C中所述仲裁者在獲得控制權(quán)后，執(zhí)行腳本進(jìn)行仲裁，先根據(jù)本次呼叫產(chǎn)生的消息和待仲裁業(yè)務(wù)，查找二維規(guī)則表，根據(jù)表項(xiàng)中規(guī)則條件與本次呼叫相關(guān)信息匹配結(jié)果，執(zhí)行仲裁。
此外在所述方法中，還包含以下步驟所述管理者模塊控制所述仲裁者模塊的產(chǎn)生與消亡，使得所述仲裁者模塊在與其相關(guān)的消息觸發(fā)時(shí)產(chǎn)生、在與其相關(guān)的交互業(yè)務(wù)終止后消亡。
此外在所述方法中，在預(yù)先配置規(guī)則時(shí)包含以下步驟首先對(duì)所有業(yè)務(wù)進(jìn)行分類管理，使得不同類業(yè)務(wù)之間不存在交互；再對(duì)同一類業(yè)務(wù)進(jìn)行特征分析，獲得任意兩個(gè)業(yè)務(wù)之間的交互關(guān)系；
根據(jù)交互關(guān)系配置規(guī)則。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的主要區(qū)別在于，通過設(shè)置service broker邏輯功能，處理AS之間的業(yè)務(wù)交互，屏蔽交互對(duì)AS產(chǎn)生的影響，保證AS的獨(dú)立性，并實(shí)現(xiàn)多業(yè)務(wù)交互的管理功能；在service broker中設(shè)置動(dòng)態(tài)產(chǎn)生和消亡的仲裁者和全局管理者模塊，仲裁者用于負(fù)責(zé)對(duì)應(yīng)AS間的業(yè)務(wù)交互仲裁，管理者負(fù)責(zé)呼叫相關(guān)信息的維護(hù)，管理控制權(quán)的移交，并提供仲裁者查詢信息，配置仲裁規(guī)則；通過業(yè)務(wù)分類管理、特征分析、生成規(guī)則實(shí)現(xiàn)一種通用的預(yù)先配置規(guī)則的方法，解決多業(yè)務(wù)情況下的仲裁規(guī)則配置問題；引入業(yè)務(wù)狀態(tài)轉(zhuǎn)移機(jī)制和業(yè)務(wù)交互模型，包括懸掛、嵌套、中斷和互斥等狀態(tài)，和基于這些狀態(tài)所建立的解決多業(yè)務(wù)交互的實(shí)現(xiàn)機(jī)制；通過預(yù)置的處理腳本和查表、規(guī)則匹配機(jī)制來簡(jiǎn)化仲裁的復(fù)雜邏輯，實(shí)現(xiàn)提高處理效率。
這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，即結(jié)合IMS的特征，針對(duì)3GPP的應(yīng)用業(yè)務(wù)架構(gòu)，提出IMS域內(nèi)service broker的一種實(shí)現(xiàn)方案，解決多業(yè)務(wù)間的交互和沖突，保持各個(gè)AS的獨(dú)立性，多業(yè)務(wù)間的一致性和協(xié)調(diào)性。對(duì)service broker的邏輯功能給出了一種有效的實(shí)現(xiàn)機(jī)制，基于這種機(jī)制，使得service broker的業(yè)務(wù)邏輯處理有序化，規(guī)則化，解決復(fù)雜的多業(yè)務(wù)交互處理問題，為IMS的多業(yè)務(wù)應(yīng)用提供了基本的解決方法；其中通過仲裁者和管理者功能的劃分簡(jiǎn)化了系統(tǒng)實(shí)現(xiàn)難度，通過業(yè)務(wù)狀態(tài)轉(zhuǎn)移機(jī)制的建模明確了交互問題解決方式，通過仲裁者的動(dòng)態(tài)產(chǎn)生和消亡機(jī)制提高系統(tǒng)處理資源利用率，通過用腳本描述規(guī)則來簡(jiǎn)化系統(tǒng)邏輯結(jié)構(gòu)、提高系統(tǒng)執(zhí)行效率，通過規(guī)則生成的通用化方法提高業(yè)務(wù)能力交互管理系統(tǒng)的通用性和可擴(kuò)展性。


圖1是本發(fā)明的業(yè)務(wù)交互能力管理系統(tǒng)的基本結(jié)構(gòu)圖；圖2是根據(jù)本發(fā)明的第一實(shí)施方式的業(yè)務(wù)交互能力管理系統(tǒng)的基本框架圖；圖3是根據(jù)本發(fā)明的第三實(shí)施方式的嵌套業(yè)務(wù)交互處理流程圖；圖4是根據(jù)本發(fā)明的第三實(shí)施方式的互斥業(yè)務(wù)交互處理流程圖；圖5是根據(jù)本發(fā)明的第四實(shí)施方式的業(yè)務(wù)交互能力管理方法流程圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步地詳細(xì)描述。
本發(fā)明結(jié)合IMS的特征，針對(duì)3GPP的應(yīng)用業(yè)務(wù)架構(gòu)，提出IMS域內(nèi)service broker的一種實(shí)現(xiàn)方案，解決多業(yè)務(wù)間的交互和沖突，保持各個(gè)AS的獨(dú)立性，多業(yè)務(wù)間的一致性和協(xié)調(diào)性?；谝环N新定義的機(jī)制，使得servicebroker的業(yè)務(wù)邏輯處理有序化，規(guī)則化。
基于該問題的要求，為了使得AS獨(dú)立，本發(fā)明通過設(shè)置專門處理業(yè)務(wù)交互問題的service broker層，由該層統(tǒng)一處理業(yè)務(wù)交互所引發(fā)的問題，屏蔽交互對(duì)單個(gè)AS的影響，使得業(yè)務(wù)交互或沖突問題對(duì)AS透明。圖1是本發(fā)明的給出SCIM系統(tǒng)的基本構(gòu)架。
在S-CSCF層與AS層之間存在service broker邏輯功能，而且任意兩個(gè)AS之間的交互均經(jīng)過service broker邏輯功能實(shí)現(xiàn)，由service broker對(duì)AS的操作完成AS業(yè)務(wù)交互或沖突問題的處理，保證AS獨(dú)立性。
本發(fā)明的關(guān)鍵在于service broker邏輯功能的具體實(shí)現(xiàn)及其與其他網(wǎng)絡(luò)功能實(shí)體的交互體制的建立。本發(fā)明設(shè)置至少一個(gè)仲裁者模塊和一個(gè)管理者模塊來實(shí)現(xiàn)service broker邏輯功能實(shí)體。其中任意一個(gè)仲裁者都是唯一對(duì)應(yīng)于兩個(gè)AS之間，即專門解決兩個(gè)AS之間的交互問題，而管理者則作為全局問題的管理角色，記錄呼叫全程處理信息，配置仲裁者具體規(guī)則，負(fù)責(zé)管理控制權(quán)轉(zhuǎn)交給某一個(gè)仲裁者，由仲裁者去執(zhí)行。
當(dāng)消息一開始觸發(fā)到service broker層，該層產(chǎn)生對(duì)應(yīng)的仲裁者對(duì)其處理，仲裁者對(duì)消息的處理是先將其上報(bào)給管理者，得到控制權(quán)后進(jìn)行仲裁，然后轉(zhuǎn)發(fā)給AS，AS處理過程中產(chǎn)生的消息將由對(duì)應(yīng)仲裁者處理，消息使得控制權(quán)轉(zhuǎn)交給對(duì)應(yīng)的仲裁者，該仲裁者查詢管理者中各種信息進(jìn)行處理，完成業(yè)務(wù)交互，并把控制權(quán)給新的AS，依次類推。
可見，核心步驟在于通過發(fā)生消息的方式使得控制權(quán)在AS與仲裁者間轉(zhuǎn)交，當(dāng)發(fā)生業(yè)務(wù)交互時(shí)，仲裁者先與管理者交互，然后根據(jù)預(yù)先配置的規(guī)則進(jìn)行仲裁，這時(shí)AS的狀態(tài)被修改；另外，預(yù)先配置規(guī)則這一步非常關(guān)鍵，需要預(yù)先根據(jù)業(yè)務(wù)種類、相互關(guān)系設(shè)定這些仲裁規(guī)則，由仲裁者去執(zhí)行。
為了保證業(yè)務(wù)鏈上的各個(gè)AS之間的獨(dú)立性，不能出現(xiàn)前面的業(yè)務(wù)處理依賴于后面的業(yè)務(wù)處理的中間狀態(tài)，或依賴于后面處理結(jié)果的影響。如果出現(xiàn)了上面這兩種依賴性，都必須由service broker來處理，進(jìn)行轉(zhuǎn)換和屏蔽。因此，每出現(xiàn)一次懸掛/嵌套，或懸掛/中斷，都必然要求service broker充當(dāng)仲裁角色，從這一點(diǎn)來考慮，該業(yè)務(wù)鏈上和service broker的每一次交點(diǎn)都是一個(gè)仲裁，該鏈上假設(shè)有n個(gè)AS，則需要經(jīng)過service broker達(dá)n+1次，即可能會(huì)產(chǎn)生n個(gè)仲裁。顯然必須保證這n個(gè)仲裁之間是相互獨(dú)立的(即不能互相感知)，同時(shí)可以確定，一個(gè)仲裁僅僅能夠在屬于自己范圍內(nèi)的兩個(gè)AS之間進(jìn)行仲裁。根據(jù)這一原理，本發(fā)明的第一實(shí)施例給出了service broker內(nèi)部結(jié)構(gòu)解決方案。
圖2是根據(jù)本發(fā)明的第一實(shí)施例的業(yè)務(wù)交互能力管理系統(tǒng)框架圖。首先包含多個(gè)AS服務(wù)器10-1，10-2等，然后是service broker邏輯功能20，還有S-CSCF功能實(shí)體30。其中service broker邏輯功能20包括多個(gè)仲裁者21-1、21-2、21-3等和管理者22。
仲裁者模塊用于在受本次呼叫產(chǎn)生的消息觸發(fā)并獲得控制權(quán)后，根據(jù)預(yù)先配置的規(guī)則及與管理者模塊22交互得到的本次呼叫相關(guān)信息，對(duì)本次呼叫產(chǎn)生的消息進(jìn)行處理，并對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁。
而管理者模塊22則充當(dāng)本地?cái)?shù)據(jù)庫的角色，用于管理所有呼叫相關(guān)信息，同時(shí)也充當(dāng)控制模塊的角色，管理控制權(quán)的轉(zhuǎn)交，通過與所有仲裁者模塊交互以更新本次呼叫相關(guān)信息并向仲裁者提供查詢。
其中在一次端對(duì)端呼叫過程中，用戶A發(fā)起呼叫經(jīng)過S-CSCF功能30路由到AS服務(wù)器10-1，這時(shí)必須先經(jīng)過service broker功能20，在servicebroker功能20中產(chǎn)生第一個(gè)仲裁者21-1來處理這個(gè)消息，對(duì)于呼入消息不存在多種業(yè)務(wù)交互，因此直接轉(zhuǎn)發(fā)給AS服務(wù)器10-1，但同時(shí)需要上報(bào)給管理者22，由管理者22記錄該呼叫的相關(guān)信息，并跟蹤記錄該呼叫之后的處理過程。呼叫經(jīng)由AS服務(wù)器10-1服務(wù)后產(chǎn)生消息，引起業(yè)務(wù)交互，這時(shí)觸發(fā)發(fā)生業(yè)務(wù)交互的兩個(gè)業(yè)務(wù)間的仲裁者，由仲裁者對(duì)消息進(jìn)行處理，仲裁者首先通知管理者22，獲得該呼叫的相關(guān)信息，再根據(jù)預(yù)先配置的仲裁規(guī)則，假定仲裁結(jié)果為AS服務(wù)器10-2進(jìn)行處理，對(duì)消息進(jìn)行修改后轉(zhuǎn)發(fā)給AS服務(wù)器10-2，然后按仲裁結(jié)果修改AS服務(wù)器10-1和10-2的狀態(tài)，比如被中斷的AS服務(wù)器10-1改為懸掛狀態(tài)，中斷AS服務(wù)器10-2則開始運(yùn)行業(yè)務(wù)。如此反復(fù)進(jìn)行，直到呼叫處理結(jié)束。
歸納上述工作流程的幾個(gè)基本步驟如下首先由本次呼叫產(chǎn)生的消息觸發(fā)，對(duì)應(yīng)仲裁者模塊獲得控制權(quán)；該仲裁者模塊與管理者模塊交互，得到本次呼叫相關(guān)信息；然后，該仲裁者模塊根據(jù)預(yù)先配置的規(guī)則及本次呼叫相關(guān)信息，對(duì)本次呼叫產(chǎn)生的消息進(jìn)行處理，并對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁；同時(shí)，管理者模塊更新本次呼叫相關(guān)信息。這個(gè)流程就是本發(fā)明的業(yè)務(wù)交互能力管理方法的一個(gè)基本實(shí)施方式。
本發(fā)明的第二實(shí)施例在第一實(shí)施例的基礎(chǔ)上，給出更詳細(xì)的解決方案。在本實(shí)施例中，仲裁者對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁時(shí)，修改本次呼叫產(chǎn)生的消息，并轉(zhuǎn)發(fā)給目的網(wǎng)元，然后通過修改業(yè)務(wù)的狀態(tài)實(shí)現(xiàn)交互，之后移交控制權(quán)給對(duì)應(yīng)的AS，AS根據(jù)業(yè)務(wù)狀態(tài)執(zhí)行。這里仲裁者是通過修改業(yè)務(wù)狀態(tài)來通知AS如何動(dòng)作，以避免沖突或者順利完成交互，從根本上實(shí)現(xiàn)AS對(duì)業(yè)務(wù)交互的透明。
業(yè)務(wù)交互及業(yè)務(wù)狀態(tài)機(jī)制的建立需要預(yù)先通過業(yè)務(wù)分析實(shí)現(xiàn)，本實(shí)施例基于IMS當(dāng)前各種業(yè)務(wù)交互情況，給出一種通用的業(yè)務(wù)分析、模型建立方法，該方法分為業(yè)務(wù)分類管理、業(yè)務(wù)特征分析、仲裁規(guī)則生成三步實(shí)現(xiàn)。在給仲裁者預(yù)先配置規(guī)則時(shí)，首先對(duì)所有業(yè)務(wù)進(jìn)行分類管理，使得不同類業(yè)務(wù)之間不存在交互；再對(duì)同一類業(yè)務(wù)進(jìn)行特征分析，獲得任意兩個(gè)業(yè)務(wù)之間的交互關(guān)系；根據(jù)交互關(guān)系配置規(guī)則。
如何制定service broker的交互處理規(guī)則，是面臨的一個(gè)關(guān)鍵的問題，這一問題的解決雖然不影響本發(fā)明的基本構(gòu)架，但是本發(fā)明第一實(shí)施例中基本構(gòu)架運(yùn)行的關(guān)鍵。本發(fā)明第二實(shí)施例給出了一般通用的步驟來分析制定交互仲裁規(guī)則。
分類管理就是將紛雜的多種多樣的業(yè)務(wù)進(jìn)行分類，保證不同類別之間的交互盡量單一化和簡(jiǎn)單化；特征分析就是在已經(jīng)分好類的某一個(gè)類中間，對(duì)多個(gè)業(yè)務(wù)可能出現(xiàn)的交互點(diǎn)進(jìn)行分析，定義和描述，對(duì)不同類間，不同群間也進(jìn)行同樣的分析；生成規(guī)則就是依據(jù)特征分析的結(jié)果生成最后的規(guī)則，表明在什么條件下，采取什么仲裁措施。
分類管理就是將關(guān)聯(lián)性較強(qiáng)的業(yè)務(wù)歸結(jié)為一個(gè)類中，沒有關(guān)聯(lián)性和關(guān)聯(lián)性單一的歸結(jié)為不同類中，一般有如下分類電話業(yè)務(wù)中呼叫相關(guān)類業(yè)務(wù)或補(bǔ)充業(yè)務(wù)包括呼叫建立，完成類補(bǔ)充業(yè)務(wù)CW/CH/MPTY/3part，群類Centrex群或CUG，前轉(zhuǎn)類補(bǔ)充業(yè)務(wù)，號(hào)碼顯示類，呼叫閉鎖限制類(包括長話權(quán)，黑白名單以及各種閉鎖)；電話業(yè)務(wù)中非呼叫相關(guān)類補(bǔ)充業(yè)務(wù)包括激活去激活類，登記去登記，注冊(cè)去注冊(cè)；消息類業(yè)務(wù)包括UC，SMS，MMS，Chat，IM；使能類業(yè)務(wù)，一般指XDMS/Presence；根據(jù)上面的分類，可以保證不同類之間的交互是一種確定的單一化關(guān)系，同種類業(yè)務(wù)的交互則依賴于下面的特征分析?；谝呀?jīng)完成的分類，可以引入群的概念，將有共同特征的多個(gè)類歸結(jié)為一個(gè)更抽象的群。
在得到業(yè)務(wù)分類之后，對(duì)于每一類業(yè)務(wù)需要繼續(xù)進(jìn)行特征分析，這個(gè)過程是最復(fù)雜也是最關(guān)鍵的過程，service broker的核心就是保證各個(gè)AS業(yè)務(wù)的相對(duì)獨(dú)立，所有的交互和沖突都只能由service broker自身來完成，對(duì)AS/S-CSCF都是透明的。該步驟需要給出業(yè)務(wù)各種交互關(guān)系的定義以及交互處理原則。
本發(fā)明第二實(shí)施例根據(jù)現(xiàn)有業(yè)務(wù)的各種交互關(guān)系歸納如下業(yè)務(wù)狀態(tài)轉(zhuǎn)移模型業(yè)務(wù)的狀態(tài)包含懸掛、嵌套、中斷、互斥，其中，當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為嵌套且第一個(gè)業(yè)務(wù)嵌套在第二個(gè)業(yè)務(wù)中時(shí)，第一個(gè)業(yè)務(wù)處于嵌套狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為中斷且第一個(gè)業(yè)務(wù)中斷第二個(gè)業(yè)務(wù)時(shí)，第一個(gè)業(yè)務(wù)處于中斷狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為互斥且第一個(gè)業(yè)務(wù)優(yōu)先級(jí)高于第二個(gè)業(yè)務(wù)時(shí)，執(zhí)行第一個(gè)業(yè)務(wù)，并終止第二個(gè)業(yè)務(wù)。
可見在本發(fā)明第二實(shí)施例中，業(yè)務(wù)交互和沖突被抽象為一種應(yīng)用業(yè)務(wù)的前提條件被另外一種應(yīng)用業(yè)務(wù)所破壞，基于這種抽象定義上述四種狀態(tài)，對(duì)于各種業(yè)務(wù)交互關(guān)系及其狀態(tài)的進(jìn)一步描述如下嵌套當(dāng)一種業(yè)務(wù)A處理過程中間又觸發(fā)了另外一種業(yè)務(wù)B，則構(gòu)成嵌套，當(dāng)且僅當(dāng)后面的嵌套B處理完畢，才繼續(xù)處理本層業(yè)務(wù)A，嵌套可以允許多層次的嵌套，可以想到，嵌套是構(gòu)成業(yè)務(wù)交互的根本；
中斷和嵌套類似，但中斷不允許被再次嵌套或中斷，即一次中斷是排它性和獨(dú)占性的，當(dāng)中斷完全處理完畢，才回到原來的位置繼續(xù)處理，這種情況也可以看成是嵌套的一個(gè)最簡(jiǎn)特例。一般而言，純事件的觸發(fā)，消息類業(yè)務(wù)都可以定義為中斷；互斥前面分析的結(jié)果，和本次的判決具有互斥性，這種情況最為復(fù)雜，理論上要根據(jù)具體的業(yè)務(wù)和場(chǎng)景來綜合判斷，為了簡(jiǎn)單起見，我們可以采用先得出的結(jié)論優(yōu)先，類似于順序優(yōu)先，也有采用覆蓋(override)，即最后結(jié)果優(yōu)先的，到底采用哪種方法依賴于不同的實(shí)現(xiàn)。典型的如前轉(zhuǎn)兩次的彩鈴業(yè)務(wù)；懸掛懸掛是相對(duì)而言的，當(dāng)出現(xiàn)嵌套/中斷時(shí)，被嵌套被中斷的業(yè)務(wù)就處于懸掛狀態(tài)，其必和嵌套/中斷相關(guān)聯(lián)產(chǎn)生。懸掛并不是指一旦被懸掛后必須等待其中的嵌套處理完畢，而是指該懸掛可能被某條消息去懸掛后，躍遷到一個(gè)新狀態(tài)，再次進(jìn)入另一種狀態(tài)的懸掛。
由此service broker的業(yè)務(wù)交互可以分解為嵌套/中斷，完全沖突(互斥)，懸掛等幾種類型，上面4種機(jī)制是完全對(duì)等的，不存在誰優(yōu)先的問題，任何兩種業(yè)務(wù)交互必然各自產(chǎn)生上面4種中的一種，否則這兩種業(yè)務(wù)被認(rèn)為不存在交互和沖突，此時(shí)service broker僅僅起到一個(gè)純粹的代理(Proxy)功能，由于Proxy角色已經(jīng)在相關(guān)協(xié)議規(guī)范中有明確的定義，即主要完成消息轉(zhuǎn)發(fā)等功能。
給出業(yè)務(wù)狀態(tài)轉(zhuǎn)移機(jī)制和仲裁規(guī)則配置方案后，整個(gè)系統(tǒng)僅需要管理者功能實(shí)現(xiàn)后即可完成預(yù)期的目的。本實(shí)施例中，管理者模塊用于給仲裁者模塊配置規(guī)則、記錄呼叫處理信息，并決定控制權(quán)在仲裁者模塊及應(yīng)用服務(wù)器之間轉(zhuǎn)交，使得AS正常服務(wù)，并通過仲裁者有序仲裁后順利完成交互。
這里提出兩個(gè)新的術(shù)語相關(guān)鏈型集和控制權(quán)轉(zhuǎn)移，它們都是管理者模塊的概念。當(dāng)每一次消息到達(dá)，仲裁者都會(huì)向管理者詢問是否具有控制權(quán)，并得到當(dāng)前的相關(guān)鏈型集的拓?fù)湟晥D，以匹配對(duì)應(yīng)的規(guī)則并觸發(fā)相應(yīng)的過程。實(shí)際上，這里的管理者就是一個(gè)本地?cái)?shù)據(jù)庫，保存有當(dāng)前處理的消息狀態(tài)，以及各種視圖數(shù)據(jù)，如控制權(quán)和拓?fù)涞?。而管理者模塊需要管理的呼叫相關(guān)信息包含呼叫的處理過程、呼叫的業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)、呼叫的注冊(cè)業(yè)務(wù)信息、呼叫的處理規(guī)則。這些呼叫相關(guān)信息必須在過程中動(dòng)態(tài)更新，以提供仲裁者做出正確仲裁。
所謂相關(guān)鏈型集，是指將各個(gè)AS在整條鏈中流暢地鏈接起來，保證讓各個(gè)AS完全獨(dú)立起來，而看不到自己的前后有其它業(yè)務(wù)在并行觸發(fā)。相關(guān)鏈型集的拓?fù)浔仨氂幸粋€(gè)管理者，因此service broker必須有一種管理機(jī)制，記錄并維護(hù)n+1個(gè)相關(guān)鏈型觸發(fā)，也稱為相關(guān)鏈型集。
所謂控制權(quán)轉(zhuǎn)移，是指控制權(quán)先從S-CSCF轉(zhuǎn)移到service broker，再轉(zhuǎn)到AS1，再到service broker，再到AS2，如此循環(huán)，這個(gè)機(jī)制保證避免多個(gè)AS同時(shí)處理而導(dǎo)致錯(cuò)誤，一個(gè)給定的時(shí)刻只有一個(gè)AS在處理。
至此，本實(shí)施例中的系統(tǒng)已經(jīng)能夠?qū)崿F(xiàn)消息觸發(fā)仲裁、仲裁與管理交互、仲裁控制業(yè)務(wù)狀態(tài)、AS根據(jù)業(yè)務(wù)狀態(tài)執(zhí)行。此外，本實(shí)施例為了提高設(shè)計(jì)效率和執(zhí)行效率，還用設(shè)計(jì)腳本來執(zhí)行以實(shí)現(xiàn)仲裁功能。規(guī)則配置的實(shí)現(xiàn)即由service broker產(chǎn)生一個(gè)運(yùn)行腳本(script)，仲裁者便于按照該腳本來執(zhí)行。
用腳本實(shí)現(xiàn)規(guī)則能夠方便系統(tǒng)的實(shí)現(xiàn)和擴(kuò)展，但腳本的設(shè)計(jì)將影響執(zhí)行效率。本實(shí)施例通過多維表格查詢和規(guī)則匹配的方法實(shí)現(xiàn)腳本。仲裁者在獲得控制權(quán)后，執(zhí)行腳本進(jìn)行仲裁，先根據(jù)本次呼叫產(chǎn)生的消息和待仲裁業(yè)務(wù)，查找二維規(guī)則表，根據(jù)表項(xiàng)中規(guī)則條件與本次呼叫相關(guān)信息匹配結(jié)果，執(zhí)行仲裁。
在本發(fā)明中，每一個(gè)仲裁者都是一個(gè)三維的概念，第一個(gè)維度是是否具有處理控制權(quán)，第二個(gè)維度是相關(guān)鏈型集的拓?fù)湟晥D(包括狀態(tài)，前次仲裁結(jié)果模型)，收到的消息和方法，第三個(gè)維度是被仲裁的業(yè)務(wù)對(duì)象的觸發(fā)條件和規(guī)則，這3個(gè)維度組合起來形成一次仲裁的最終結(jié)果。
首先建立一張二維表格，這個(gè)表的內(nèi)容是仲裁規(guī)則，而表格由所有消息和業(yè)務(wù)分別索引，對(duì)應(yīng)某一種業(yè)務(wù)，當(dāng)發(fā)生某種消息或事件實(shí)，查表得到對(duì)應(yīng)表項(xiàng)給出了被觸發(fā)的可能性和優(yōu)先級(jí)等信息，供仲裁者參考執(zhí)行。
另外，引入規(guī)則模型(Rule module)用來標(biāo)識(shí)什么樣的情況下執(zhí)行什么樣的操作，這個(gè)規(guī)則模型包括觸發(fā)的條件規(guī)則和期望的處理方式，最終以XML等語言的形式表示出來，被service broker的仲裁者所使用，以達(dá)到解決業(yè)務(wù)交互的控制處理。這個(gè)規(guī)則模型非常類似于3GPP的iFC，即滿足一定的條件，觸發(fā)相應(yīng)的過程。
由此可見，根據(jù)規(guī)則進(jìn)行仲裁的方法流程歸納如下當(dāng)Server broker收到任何消息，首先向管理者詢問控制權(quán)，若沒有控制權(quán)，則只能緩存該消息或簡(jiǎn)單拋棄；若仲裁者獲得控制權(quán)，則向管理者詢問拓?fù)湟晥D，獲取仲裁對(duì)象，各個(gè)對(duì)象當(dāng)前處理的消息狀態(tài)，前次仲裁結(jié)果模型，和收到的消息和方法進(jìn)行匹配，若不匹配則進(jìn)入一般的SIP錯(cuò)誤處理；若匹配則根據(jù)收到的消息或方法中攜帶的關(guān)鍵信息和特征，來查詢表格，匹配表項(xiàng)中的觸發(fā)條件和規(guī)則，若不能匹配，則進(jìn)入一般SIP錯(cuò)誤處理，若匹配則獲得最終的處理結(jié)果，并依據(jù)該結(jié)果進(jìn)行消息處理和控制過程。
最后，還需要指出一點(diǎn)，本發(fā)明第二實(shí)施例還采用了仲裁者模塊動(dòng)態(tài)產(chǎn)生與消亡機(jī)制以節(jié)省處理器資源。如前所述，每兩個(gè)AS之間需要存在一個(gè)仲裁者模塊，然后AS眾多必然使得仲裁者模塊太多而無法高效實(shí)現(xiàn)，但注意到每次呼叫時(shí)僅僅是所涉及到的AS所對(duì)應(yīng)的幾個(gè)仲裁者模塊在起作用，大多數(shù)仲裁者模塊不需要執(zhí)行功能。
因此本發(fā)明用動(dòng)態(tài)產(chǎn)生和消亡的方式。由管理者模塊控制仲裁者模塊的產(chǎn)生與消亡，仲裁者模塊在與其相關(guān)的消息觸發(fā)時(shí)產(chǎn)生，在與其相關(guān)的交互業(yè)務(wù)終止后消亡。比如呼叫觸發(fā)時(shí)，產(chǎn)生對(duì)應(yīng)的仲裁者，而當(dāng)呼叫所涉及的業(yè)務(wù)AS中某一種業(yè)務(wù)終止使得該AS不起作用，這時(shí)與該AS相關(guān)的所有仲裁功能都失去意義，便可以消亡。這種方式使得系統(tǒng)處理器可以動(dòng)態(tài)調(diào)用，大大節(jié)約處理器資源，提高系統(tǒng)效率。
本發(fā)明第三實(shí)施例首先根據(jù)具體應(yīng)用情況給出幾種交互模式的處理流程。定義ServiceBroker針對(duì)不同關(guān)系需要進(jìn)行的處理是一個(gè)復(fù)雜的過程，根據(jù)上文分析，歸納為下面幾種懸掛/嵌套這種關(guān)系的情況下，仲裁者首先保存有前后兩個(gè)UA(假定為A/B)呼叫處理的歷史狀態(tài)，當(dāng)從B收到后續(xù)的響應(yīng)消息時(shí)，仲裁者將從管理者數(shù)據(jù)庫查詢相關(guān)控制信息和處理規(guī)則，并依據(jù)預(yù)置的腳本決定處理步驟，當(dāng)匹配到某條規(guī)則時(shí)，將該規(guī)則定義的處理結(jié)果發(fā)給A，A根據(jù)仲裁者修改后的消息進(jìn)行處理，繼而完成A的業(yè)務(wù)邏輯。顯然這時(shí)控制權(quán)已經(jīng)由B轉(zhuǎn)移到A，當(dāng)A處理完畢后，放棄控制權(quán)，此時(shí)A已經(jīng)從一種狀態(tài)的懸掛進(jìn)入到另一種狀態(tài)的懸掛。嵌套業(yè)務(wù)的處理流程如圖3所示。
懸掛/中斷在這種關(guān)系下，基本和懸掛/嵌套類似，不同之處在于A不會(huì)放棄控制權(quán)，而是繼續(xù)進(jìn)行自身的后續(xù)處理。
互斥這種關(guān)系的處理比較簡(jiǎn)單，當(dāng)仲裁者已經(jīng)完成仲裁后，相互排斥的業(yè)務(wù)不會(huì)同時(shí)出現(xiàn)在相關(guān)鏈型集中。這時(shí)如果需要繼續(xù)選定的業(yè)務(wù)處理，則被排斥的業(yè)務(wù)原有邏輯必須被先行終止?；コ鈽I(yè)務(wù)的處理流程如圖4所示。
本發(fā)明的第四實(shí)施例是一種典型應(yīng)用場(chǎng)景下的各個(gè)步驟和環(huán)節(jié)的具體實(shí)現(xiàn)方案。最簡(jiǎn)單的應(yīng)用就是通話，比如移動(dòng)發(fā)端呼叫終端時(shí)需要觸發(fā)呼叫等待(Call Waiting，簡(jiǎn)稱“CW”)，呼叫到達(dá)時(shí)觸發(fā)呼叫顯示(Call screening)，而無應(yīng)答時(shí)觸發(fā)前轉(zhuǎn)(forward)、語音郵箱(VoiceMail)等業(yè)務(wù)，這些業(yè)務(wù)都是和呼叫相關(guān)的呼叫建立業(yè)務(wù)，因此都?xì)w類為電話業(yè)務(wù)中呼叫相關(guān)類業(yè)務(wù)或補(bǔ)充業(yè)務(wù)，相互之間存在交互關(guān)系。
對(duì)這一類業(yè)務(wù)進(jìn)行特征分析CW就是在傳統(tǒng)意義上的呼叫等待；Call Screening是指在入呼到達(dá)時(shí)，主叫用戶信息必須先行被記錄并顯示給被叫用戶，被叫據(jù)此主叫信息來決定不同的操作，通過按下不同的功能選擇鍵決定是否接受或拒絕該次呼叫，如何選擇不同的功能鍵將通過語音提示來完成；VoiceMail是指語音郵箱功能，在用戶無應(yīng)答/忙時(shí)，可以前轉(zhuǎn)到語音郵箱。
通過分析，顯然語音郵箱和CW/CallScreening出現(xiàn)了沖突，若該次呼叫到達(dá)語音郵箱，則到目標(biāo)用戶的呼叫建立必然是失敗的，從這個(gè)意義上分析，結(jié)果要么是CW/CallScreening呼叫建立成功，要么是建立失敗而前轉(zhuǎn)到語音郵箱；其次，CW/CallScreening，這兩個(gè)業(yè)務(wù)都是在Invite時(shí)觸發(fā)，但由于CallScreening為呼叫建立之前的預(yù)處理，因此在時(shí)間上應(yīng)該先處理，當(dāng)CallScreening處理完畢，則可以繼續(xù)正常的被叫流程，此后才觸發(fā)被叫的CW流程，因此順序?yàn)镸T procedure-CallScreening success-CW procedure；另外，語音郵箱是在4XX時(shí)觸發(fā)的，觸發(fā)時(shí)機(jī)不同于CW/CallScreening。
從上面的分析可以看出，CallScreening和CW形成懸掛/嵌套關(guān)系；CallScreening/CW和VoiceMail形成互斥關(guān)系。
可以預(yù)見，在呼叫過程中將產(chǎn)生以下業(yè)務(wù)交互情形當(dāng)被叫的service broker在收到終端Invite時(shí)，會(huì)觸發(fā)CallScreening以及CW，CallScreening具有高優(yōu)先級(jí)，因此觸發(fā)CallScreening；當(dāng)被叫的service broker在收到終端Invite時(shí)，會(huì)觸發(fā)CallScreening以及CW，高優(yōu)先級(jí)CallScreening已經(jīng)觸發(fā)而激活，因此觸發(fā)具有次優(yōu)先級(jí)的CW；當(dāng)被叫的service broker在收到4XX時(shí)，企圖觸發(fā)前轉(zhuǎn)語音郵箱，由于語音郵箱和CallScreening/CW是互斥的，因此要想觸發(fā)語音郵箱，必須先將CallScreening/CW終結(jié)掉，并同時(shí)存取4XX事件；最后觸發(fā)語音郵箱，完成放音或留言；針對(duì)這一情況，接著需要建立仲裁規(guī)則，一般而言，觸發(fā)業(yè)務(wù)的順序依賴于觸發(fā)點(diǎn)所在呼叫信令的順序，如CW肯定依賴于MT的Invite，因此必然在Invite的時(shí)機(jī)觸發(fā)，而無應(yīng)答前轉(zhuǎn)肯定是在4XX時(shí)觸發(fā)等。但同樣依賴于Invite的多個(gè)業(yè)務(wù)的順序就只能依據(jù)具體的業(yè)務(wù)來指定了，目前沒有一定的規(guī)律，依據(jù)不同的實(shí)現(xiàn)而不同。針對(duì)這種情況，有必要引入優(yōu)先級(jí)，同種條件下，要求先觸發(fā)的業(yè)務(wù)具有高優(yōu)先級(jí)，依據(jù)不同的優(yōu)先級(jí)，可以很好地解決這個(gè)問題。若高優(yōu)先級(jí)已經(jīng)觸發(fā)，也需要在管理者中形成記錄，便于其它仲裁者查詢。由此需要建立如下所示的二維表格描述這些規(guī)則。

上表中僅給出涉及到的業(yè)務(wù)，其它業(yè)務(wù)的觸發(fā)處理優(yōu)先級(jí)順序沒有給出。根據(jù)定義完畢的該種表格，可以得出，當(dāng)Invite到達(dá)時(shí)，最先觸發(fā)CallScreening，然后觸發(fā)CW，依此類推。
對(duì)于上述表項(xiàng)的內(nèi)容，還需要給出規(guī)則條件，生成腳本如下，其和特征分析一一對(duì)應(yīng)Rule3a獲得控制權(quán)后，收到終端Invite，拓?fù)鋱D無，前次仲裁結(jié)果無，且被叫簽約數(shù)據(jù)為CallScreening/CW，則期望的處理為先處理高優(yōu)級(jí)CallScreening；Rule3b獲得控制權(quán)后，收到終端Invite，拓?fù)錇镸T→CallScreening，且被叫簽約數(shù)據(jù)為CallScreening/CW，則期望的處理為處理第二優(yōu)先級(jí)CW；Rule3c獲得控制權(quán)后，收到4XX消息，拓?fù)錇镸T→CallScreening→CW，且被叫簽約了CallScreening/CW/VoiceMail，4XX原因?yàn)闊o應(yīng)答，則期望的處理為存取4XX消息和事件，反向釋放CW/CallScreening；Rule3d獲得控制權(quán)后，如果釋放完畢，拓?fù)湟呀?jīng)變?yōu)閂oiceMail，4XX事件存在還未處理，且被叫簽約了VoiceMail，則期望的處理為前轉(zhuǎn)到語音郵箱。
完成規(guī)則配置后，先描述一個(gè)動(dòng)態(tài)工作流程假設(shè)主叫用戶為Jane，被叫B簽約有CW/CallScreening/VoiceMail等業(yè)務(wù)?？紤]一個(gè)有代表性的應(yīng)用場(chǎng)景，Jane發(fā)起一個(gè)呼叫到B，B無應(yīng)答后前轉(zhuǎn)到語音郵箱的情況。為了簡(jiǎn)單清晰起見，只考慮B的service broker邏輯的處理。
如圖5所示，處理流程如下第一次收到Invite，則必然匹配到Rule3a，因此CallScreening被激活，CallScreening完成相應(yīng)操作，記錄主叫Jane的名字，然后將Invite再次發(fā)給service broker，并向管理者告知仲裁者1已經(jīng)建立MT→CallScreening的鏈型拓?fù)洌|發(fā)消息狀態(tài)為Invite。
service broker再次收到Invite時(shí)，則必然匹配到Rule3b，因此CW被激活，CW完成相應(yīng)操作，然后將Invite再次發(fā)給service broker，這時(shí)servicebroker僅僅起到Proxy的角色，將Invite發(fā)給用戶B，并向管理者告知仲裁者2建立了CallScreening→CW的鏈型拓?fù)?，觸發(fā)消息為Invite。至此總的拓?fù)錇镸T→CallScreening→CW。
用戶B返回180，定時(shí)器超時(shí)后返回?zé)o應(yīng)答4XX，service broker檢測(cè)到無應(yīng)答事件，匹配到Rule3c，轉(zhuǎn)而存取4XX事件到管理者，并反向釋放CW/CallScreening。注意此時(shí)仍然只有仲裁者1和仲裁者2存在。
service broker完成正常的釋放過程，因此向管理者刪除拓?fù)銶T→CallScreening→CW，同時(shí)發(fā)現(xiàn)還有4XX事件沒有處理，因此匹配到Rule3d，則觸發(fā)語音郵箱，并告知管理者仲裁者3已經(jīng)建立MT→VoiceMail的拓?fù)?，觸發(fā)事件為4XX。
熟悉本領(lǐng)域的技術(shù)人員可以理解，上述各個(gè)實(shí)施例給出的具體實(shí)現(xiàn)方案是為了幫助理解而具體說明，在實(shí)際應(yīng)用中可以有其它可行的實(shí)現(xiàn)方式，這些情況比如在對(duì)多種業(yè)務(wù)進(jìn)行分類的情況下，可以根據(jù)其它法則進(jìn)行分類，或者抽象為群的概念并引入群管理，將有相同屬性的分類再次歸結(jié)為一個(gè)更抽象的更高層次的群，使管理者的功能更加具體化和層次化，從而提供一種更為強(qiáng)化的管理者功能；對(duì)于兩種業(yè)務(wù)之間的交互類型的抽象可以更加具體，如對(duì)于中斷可以細(xì)分為無條件中斷和有條件中斷，對(duì)于嵌套也可以細(xì)分為觸發(fā)新業(yè)務(wù)的嵌套和觸發(fā)新會(huì)話的嵌套；在配置規(guī)則時(shí)，不同群之間Rule module的定義、不同種類業(yè)務(wù)之間Rulemodule的定義、同種類內(nèi)不同業(yè)務(wù)的Rule module的定義，都可以根據(jù)實(shí)際情況實(shí)現(xiàn)；在可能出現(xiàn)一對(duì)多業(yè)務(wù)的情況下(如Forking，Group)，相關(guān)鏈型集將可以出現(xiàn)多條子鏈并存的情況，需要增強(qiáng)管理功能，實(shí)現(xiàn)多條子鏈的管理關(guān)聯(lián)性；另外，經(jīng)過分類管理、特征分析、生成腳本之后，還可以根據(jù)不同的應(yīng)用場(chǎng)景和本地策略，對(duì)最終生成的腳本進(jìn)行一定的靜態(tài)配置，以適應(yīng)不同運(yùn)營商的需要；類似上述各種情況，采用其它可行方式實(shí)現(xiàn)發(fā)明目的，均不影響本發(fā)明的實(shí)質(zhì)和范圍。
雖然通過參照本發(fā)明的某些優(yōu)選實(shí)施方式，已經(jīng)對(duì)本發(fā)明進(jìn)行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細(xì)節(jié)上對(duì)其作各種改變，而不偏離本發(fā)明的精神和范圍。
權(quán)利要求
1.一種通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，包含至少一個(gè)仲裁者模塊和一個(gè)管理者模塊，所述仲裁者模塊用于在受本次呼叫產(chǎn)生的消息觸發(fā)并獲得控制權(quán)后，根據(jù)預(yù)先配置的規(guī)則和通過與所述管理者模塊交互得到的本次呼叫相關(guān)信息，對(duì)本次呼叫產(chǎn)生的消息進(jìn)行處理，并對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁；所述管理者模塊用于管理所有呼叫相關(guān)信息，管理控制權(quán)的轉(zhuǎn)交，通過與所述仲裁者模塊交互以更新本次呼叫相關(guān)信息并向所述仲裁者提供查詢。
2.根據(jù)權(quán)利要求1所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述仲裁者模塊對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁時(shí)，修改本次呼叫產(chǎn)生的消息，并轉(zhuǎn)發(fā)給目的網(wǎng)元，然后修改所述業(yè)務(wù)的狀態(tài)，并移交控制權(quán)給對(duì)應(yīng)的應(yīng)用服務(wù)器。
3.根據(jù)權(quán)利要求2所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述應(yīng)用服務(wù)器根據(jù)所對(duì)應(yīng)的業(yè)務(wù)的狀態(tài)決定業(yè)務(wù)的動(dòng)作，所述業(yè)務(wù)的狀態(tài)包含懸掛、嵌套、中斷、互斥，其中，當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為嵌套且第一個(gè)業(yè)務(wù)嵌套在第二個(gè)業(yè)務(wù)中時(shí)，第一個(gè)業(yè)務(wù)處于嵌套狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為中斷且第一個(gè)業(yè)務(wù)中斷第二個(gè)業(yè)務(wù)時(shí)，第一個(gè)業(yè)務(wù)處于中斷狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為互斥且第一個(gè)業(yè)務(wù)優(yōu)先級(jí)高于第二個(gè)業(yè)務(wù)時(shí)，執(zhí)行第一個(gè)業(yè)務(wù)，并終止第二個(gè)業(yè)務(wù)。
4.根據(jù)權(quán)利要求1所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述管理者模塊還用于給所述仲裁者模塊配置規(guī)則、記錄呼叫處理信息，并決定控制權(quán)在所述仲裁者模塊及應(yīng)用服務(wù)器之間轉(zhuǎn)交。
5.根據(jù)權(quán)利要求4所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述管理者模塊還用于管理呼叫相關(guān)信息，包含呼叫的處理過程、呼叫的業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)、呼叫的注冊(cè)業(yè)務(wù)信息和呼叫的處理規(guī)則。
6.根據(jù)權(quán)利要求1所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述仲裁者通過執(zhí)行預(yù)先配置的腳本，對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁。
7.根據(jù)權(quán)利要求6所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述仲裁者用于在獲得控制權(quán)后，執(zhí)行腳本進(jìn)行仲裁，先根據(jù)本次呼叫產(chǎn)生的消息和待仲裁業(yè)務(wù)，查找二維規(guī)則表，根據(jù)表項(xiàng)中規(guī)則條件與本次呼叫相關(guān)信息匹配結(jié)果，執(zhí)行仲裁。
8.根據(jù)權(quán)利要求1至7中任一項(xiàng)所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)，其特征在于，所述管理者模塊控制所述仲裁者模塊的產(chǎn)生與消亡，所述仲裁者模塊在與其相關(guān)的消息觸發(fā)時(shí)產(chǎn)生，在與其相關(guān)的交互業(yè)務(wù)終止后消亡。
9.一種通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，包含步驟A由本次呼叫產(chǎn)生的消息觸發(fā)，對(duì)應(yīng)仲裁者模塊獲得控制權(quán)；B該仲裁者模塊與所述管理者模塊交互，得到本次呼叫相關(guān)信息；C該仲裁者模塊根據(jù)預(yù)先配置的規(guī)則及本次呼叫相關(guān)信息，對(duì)本次呼叫產(chǎn)生的消息進(jìn)行處理，并對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁；D所述管理者模塊更新本次呼叫相關(guān)信息。
10.根據(jù)權(quán)利要求9所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，所述步驟C包含以下子步驟C1所述仲裁者模塊根據(jù)預(yù)先配置的規(guī)則及本次呼叫相關(guān)信息進(jìn)行仲裁；C2所述仲裁者模塊修改本次呼叫產(chǎn)生的消息，并轉(zhuǎn)發(fā)給目的網(wǎng)元；C3所述仲裁者模塊修改所述業(yè)務(wù)的狀態(tài)，并移交控制權(quán)給對(duì)應(yīng)的應(yīng)用服務(wù)器。
11.根據(jù)權(quán)利要求10所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，所述步驟C3進(jìn)一步包含以下子步驟所述應(yīng)用服務(wù)器根據(jù)所對(duì)應(yīng)的業(yè)務(wù)的狀態(tài)決定業(yè)務(wù)的動(dòng)作，所述業(yè)務(wù)的狀態(tài)包含懸掛、嵌套、中斷、互斥，其中，當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為嵌套且第一個(gè)業(yè)務(wù)嵌套在第二個(gè)業(yè)務(wù)中時(shí)，第一個(gè)業(yè)務(wù)處于嵌套狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為中斷且第一個(gè)業(yè)務(wù)中斷第二個(gè)業(yè)務(wù)時(shí)，第一個(gè)業(yè)務(wù)處于中斷狀態(tài)并執(zhí)行，第二個(gè)業(yè)務(wù)處于懸掛狀態(tài)并暫停；當(dāng)兩個(gè)交互業(yè)務(wù)的關(guān)系為互斥且第一個(gè)業(yè)務(wù)優(yōu)先級(jí)高于第二個(gè)業(yè)務(wù)時(shí)，執(zhí)行第一個(gè)業(yè)務(wù)，并終止第二個(gè)業(yè)務(wù)。
12.根據(jù)權(quán)利要求9所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，還包含步驟所述管理者模塊預(yù)先給所述仲裁者模塊配置規(guī)則，在呼叫過程中記錄該呼叫的處理信息，并決定控制權(quán)在所述仲裁者模塊及應(yīng)用服務(wù)器之間轉(zhuǎn)交。
13.根據(jù)權(quán)利要求9所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，所述管理者模塊所管理的呼叫相關(guān)信息包含呼叫的處理過程、呼叫的業(yè)務(wù)拓?fù)浣Y(jié)構(gòu)、呼叫的注冊(cè)業(yè)務(wù)信息和呼叫的處理規(guī)則。
14.根據(jù)權(quán)利要求9所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，所述步驟C中所述仲裁者通過執(zhí)行預(yù)先配置的腳本，對(duì)本次呼叫產(chǎn)生的交互業(yè)務(wù)進(jìn)行仲裁。
15.根據(jù)權(quán)利要求9所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，所述步驟C中所述仲裁者在獲得控制權(quán)后，執(zhí)行腳本進(jìn)行仲裁，先根據(jù)本次呼叫產(chǎn)生的消息和待仲裁業(yè)務(wù)，查找二維規(guī)則表，根據(jù)表項(xiàng)中規(guī)則條件與本次呼叫相關(guān)信息匹配結(jié)果，執(zhí)行仲裁。
16.根據(jù)權(quán)利要求9所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，還包含以下步驟所述管理者模塊控制所述仲裁者模塊的產(chǎn)生與消亡，使得所述仲裁者模塊在與其相關(guān)的消息觸發(fā)時(shí)產(chǎn)生、在與其相關(guān)的交互業(yè)務(wù)終止后消亡。
17.根據(jù)權(quán)利要求9至16中任意一項(xiàng)所述的通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理方法，其特征在于，在預(yù)先配置規(guī)則時(shí)包含以下步驟首先對(duì)所有業(yè)務(wù)進(jìn)行分類管理，使得不同類業(yè)務(wù)之間不存在交互；再對(duì)同一類業(yè)務(wù)進(jìn)行特征分析，獲得任意兩個(gè)業(yè)務(wù)之間的交互關(guān)系；根據(jù)交互關(guān)系配置規(guī)則。
全文摘要
本發(fā)明涉及通信領(lǐng)域，公開了一種通信網(wǎng)絡(luò)中業(yè)務(wù)能力交互管理系統(tǒng)及其方法，使得通信網(wǎng)絡(luò)中多業(yè)務(wù)交互和沖突問題得到解決，實(shí)現(xiàn)多業(yè)務(wù)能力交互管理功能。本發(fā)明中，通過設(shè)置serVice broker邏輯功能，處理AS之間的業(yè)務(wù)交互；在service broker中設(shè)置動(dòng)態(tài)產(chǎn)生和消亡的仲裁者和全局管理者模塊，仲裁者用于對(duì)應(yīng)AS間的業(yè)務(wù)交互仲裁，管理者用于呼叫相關(guān)信息的維護(hù)，管理控制權(quán)的移交，并提供仲裁者查詢信息，配置仲裁規(guī)則；引入業(yè)務(wù)狀態(tài)轉(zhuǎn)移機(jī)制和業(yè)務(wù)交互模型，包括懸掛、嵌套、中斷和互斥等狀態(tài)，和基于這些狀態(tài)建立的解決多業(yè)務(wù)交互的實(shí)現(xiàn)機(jī)制。
文檔編號(hào)H04L29/06GK1905489SQ20061011056
公開日2007年1月31日 申請(qǐng)日期2006年8月8日 優(yōu)先權(quán)日2006年8月8日
發(fā)明者葉進(jìn)洲 申請(qǐng)人:華為技術(shù)有限公司