專利名稱：在ims系統(tǒng)中傳遞事件信息的系統(tǒng)及方法
技術領域：
本發(fā)明涉及移動通信領域，尤其一種涉及IMS (IP Multimedia Subsystem, IP多Jf某體子系統(tǒng))協(xié)議層和IMS界面之間傳遞事件信息的系 統(tǒng)和方法。
背景技術：
當前對IMS ( IP多媒體子系統(tǒng))技術的探討主要集中在網(wǎng)絡側上，而缺 少對IMS客戶端的研究。在IMS規(guī)范的制訂中主要由IETF、 3GPP、 0MA (開 放移動聯(lián)盟)這三家國際標準組織來完成。根據(jù)國際標準化組織制定的協(xié)議 規(guī)則，可以很好地實現(xiàn)終端和系統(tǒng)設備直接的通訊，并能夠具有極強的兼容 性。但是終端作為一種消費品，良好的用戶交互界面是取得市場，贏得用戶 喜愛的法寶之一，特別是當廠商根據(jù)規(guī)范都能開發(fā)出相同的協(xié)議模塊時候， 大家的竟爭點就是誰的界面更人性化，更被用戶接受。
傳統(tǒng)上的方法一般是協(xié)議開發(fā)廠商封裝協(xié)議模塊，然后提供一些API函 數(shù)接口給界面開發(fā)廠商。在API函數(shù)接口里面提供了多個參數(shù)，甚至提供一 個結構體以方便進行賦值。這種傳統(tǒng)的方法，由于傳遞的數(shù)據(jù)格式不統(tǒng)一， 有一個缺點就在于如果協(xié)議廠商增加了某個函數(shù)的參數(shù)，那么界面廠商一定 要跟著修改，否則就不可能編譯通過和使用。同時每個協(xié)議廠商在函數(shù)接口 的定義方面肯定不一樣。這樣導致界面設計如果一旦選定了某家協(xié)議廠商， 那么中途要再更換就是萬萬不可能的事了 。這樣導致了 IMS界面與協(xié)議層之 間傳遞數(shù)據(jù)的接口缺乏良好的可移植性。

發(fā)明內容
本發(fā)明旨在解決現(xiàn)有技術中IMS界面與協(xié)議層的數(shù)據(jù)傳遞過程缺乏可移
植性的問題，提出了 一種在IMS中，協(xié)議層與IMS界面?zhèn)鬟f數(shù)據(jù)的系統(tǒng)和方法。 本發(fā)明的系統(tǒng)，包括IMS界面和協(xié)議層，IMS界面接收來自用戶的事件
信息，協(xié)議層接收來自網(wǎng)絡的事件信息，還包括編碼器及解析器，編碼器用
于將IMS界面接收到的事件信息編碼為固定格式的文檔并反饋給IMS界面，
IMS界面還用于將所述固定格式的文檔發(fā)送給協(xié)議層，解析器用于將協(xié)議層
從IMS界面接收到的所述固定格式的文檔解析為事件信息并反饋給協(xié)議層；
編碼器還用于將協(xié)議層接收到的事件信息編碼為固定格式的文檔并反饋給
協(xié)議層，協(xié)議層還用于將所述固定格式的文檔發(fā)送給IMS界面，解析器還用
于將IMS界面從協(xié)議層接收到的所述固定格式的文檔解析為事件信息并反
饋給IMS界面。
上述的系統(tǒng)，所述固定格式的文檔為XML文檔。
上述的系統(tǒng)，所述的固定格式的文檔中包括了地址信息和文檔長度信 息,所述IMS界面根據(jù)所述地址信息和文檔長度信息將所述固定格式的文檔 發(fā)送給協(xié)議層，所述協(xié)議層根據(jù)地址信息和文檔長度信息將所述固定格式的 文檔發(fā)送給IMS界面。
本發(fā)明中IMS界面向協(xié)議層傳遞事件信息的方法，包括如下步驟
A、 將IMS界面接收到的事件信息編碼為固定格式的文檔；
B、 IMS界面將步驟A中所述的文檔發(fā)送給協(xié)議層；
C、 對協(xié)議層在步驟B中接收到的文檔進行解析，得到步驟A中所述的 事件信息。
上述的方法，所述的固定格式的文檔為XML文檔。
上述的方法，所述的固定格式的文檔中包括了地址信息和文檔長度信 息，步驟B中，所述IMS界面根據(jù)所述地址信息和文檔長度信息將所述固定 格式的文檔發(fā)送給協(xié)議層。
本發(fā)明中協(xié)議層向IMS界面?zhèn)鬟f事件信息的方法，包括如下步驟A、 將協(xié)議層接收到的事件信息編碼為固定格式的文檔；
B、 協(xié)議層將步驟A中所述的文檔發(fā)送給IMS界面；
C、 對IMS界面在步驟B中接收到的文檔進行解析，得到步驟A中所 述的事件信息。
上述的方法，所述的固定^f各式的文檔為XML文檔。
上述的方法，所述的固定格式的文檔中包括了地址信息和文檔長度信
息，步驟B中，所述協(xié)議層根據(jù)地址信息和文檔長度信息將所述固定格式的
文檔發(fā)送給IMS界面。
本發(fā)明通過將事件信息進行封裝，使得對于任何事件信息，協(xié)議層和 IMS界面之間都可以使用統(tǒng)一的格式來進行數(shù)據(jù)傳遞，開發(fā)商不需要考慮為 不同事件信息設置不同接口，也無需擔心函數(shù)接口發(fā)生變化帶來的影響。通
過這種方法來標準化業(yè)務層模塊，使得終端廠商可以專注于設計良好的用戶 交互界面。而不再關心底層協(xié)議的實現(xiàn)。任何廠家實現(xiàn)的底層協(xié)議實現(xiàn)模塊 都能夠很好的和其他廠家的用戶界面模塊所兼容。
附圖說^


圖1為本發(fā)明系統(tǒng)的結構圖2為信息上行時，本發(fā)明的流程圖3為信息下行時，本發(fā)明的流程圖4為本發(fā)明采用XML結構時，固定格式的文檔的結構圖。
具體實施例方式
圖l表示了本發(fā)明的系統(tǒng)的結構圖。為了達到本發(fā)明的目的，IMS界面和 協(xié)議層之間傳遞的信息必須采用統(tǒng)一的格式。因此,必須對IMS界面或者協(xié) 議層收到的事件信息進行統(tǒng)一封裝，編碼為固定格式的文檔。在收到事件信 息后，先將信息傳遞給編碼器，由編碼器對其進行統(tǒng)一封裝，編碼形成固定 格式的文檔，然后再在IMS界面和協(xié)議層之間進行傳輸，對方收到后，由解 析器將封裝好的固定格式文檔進行解析，得到事件信息并反饋給IMS界面或
協(xié)議層。需要說明的是，為了使前后得到的事件信息一致，編碼器對事件信 息的編碼與解析器對固定格式文檔進行解析的規(guī)則應該 一致。這一規(guī)則可由 標準組織定義，或由廠商自行定義，或者釆用業(yè)內通用的封裝和解析規(guī)則。
例如，對于查詢聯(lián)系人列表的事件信息，可以采用如下的方法進行封裝 < xml version="l .0" encoding="UTF-8" > <do name="read contact-list"> <entry uri="sip:bHI@example.com"> <display-name>BHI Doe</display-n。me> </sntry>
<entry uri="sip:gaoy。nfeng@exarnple.com">
<display-name>Gcio Yan Feng</display-name>
</entry>
</ contact-lists >
如上所示，第1行表示這個是一個XML文檔格式的數(shù)據(jù)。第二行和最后 一行則表示這是一個查詢聯(lián)系人列表的信息。其中第三行到第五行，第六行 到第八行分別表示兩個聯(lián)系人。
下面再給出 一個發(fā)送消息的例子
< xml version="l .0" encoding="UTF-8" >
<do name="send message">
<entry uri="sip:b^ll@example.com">
<message-info>heHo world</ message-info >
<delay-time> sunday</ delay-time> </entry> </ do >
在這里，第一行表示這是一個XML文檔格式的數(shù)據(jù)，第二行和最后一行 表示這個事件信息是發(fā)送消息，第三行到第六行表示，該事件信息為向bill 這個人發(fā)送了 hello world的消息,采用了到禮拜天延遲發(fā)送的方式。
在這里需要說明的是，第二行和最后一行要同時出現(xiàn)是由公開的XML 語法決定的，是不可變更的。XML總是符合如下語法<AC>B</A>。 XML 語法是層次結構的，A代表一個層，C和B代表這個層里所要表示的內容。第 一個例子里有兩層，其中第二層有兩個并列的元素。第二個例子里有兩層，
每層都只有一個元素?？梢岳斫鉃槭且粋€樹狀結構。
在上述結構里面do代表需要協(xié)議層去完成的動作，完成動作的內容在 name里面表述，比如發(fā)送消息，獲取聯(lián)系人。在第二層里面根據(jù)每個不同 的動作可以有不同的擴展。再舉一個例子
< xml version="l .0" encoding="UTF-8" >
<do n。me="receive message">
<entry uri="sip:bHI@example.com"> <message-info>how are you</ message-info > <delay-time> </ delay-time>
</entry>
</ do >
上面這個例子就代表協(xié)議層收到網(wǎng)絡側的事件信息后傳遞給IMS界面 的數(shù)據(jù)，告知界面b川給你回了個消息，消息內容是how are you。這樣就 可以根據(jù)不同的動作和實現(xiàn)來規(guī)范定義XML結構。
本發(fā)明所述的固定格式的文檔除了可以采用上述的XML文檔外，還可以 使用一種基于文本的格式。，比如我們可以使用如下的文本格式來傳遞數(shù)據(jù)
Doname = "read contact-list" Doing = Read Contact-list [Read Contact-list] Num =3
Contact-list Name =Namel,Name2，Name3 [Namel]
Name = "zhou hai" Age = "16"
Addr = "nan jing road" [Name2]
Name = "zhang guang"
Age = "55"
Addr = "shang hai"
Name ="張四"
Age = "21" AddrJ'蘇州"
其中[Do]是固定的，表示版本號和要處理的事情。要處理的事情由 Doname決定，Doname是拳先定義的一系列值，比如"read contact-list" 表示讀4關系人列表,"receive message"表示4妄收消息,"send message"表 示發(fā)送消息。這里面的值有嚴格的規(guī)定。Doing的值表示下面的起始行從什 么地方開始解析，即[Read Contact-list]的地址。[Read Contact-list]后面是要 讀取的聯(lián)系人列表的內容，本例中，有3個聯(lián)系人，分別用Namel、 Name2、 Name3表示，Namel的內容是zhou hai， 16歲，地址為nan jing road。 Name2、 Name3以次類4偉。
下面給出 一個接收消息的例子
Doname = "receive message" Doing = Recv一Message [Recv—Message]
Uri = "sip:bni@example.com" Message—info = "how are you" D勿醒time = "2007-10-15"后面是接收到消息的內容，次例中消息來源的用戶標識 用Uri表示，消息內容為how are you, 發(fā)送時間是2007-10-15。 圖2表示了事件信息上行時，本發(fā)明所述方法的流程圖。 S201: IMS界面接收到某一事件信息輸入。例如，客戶端在IMS域里面要添 加一個聯(lián)系人，IMS界面接收到由用戶輸入的一個聯(lián)系人的uri標識； S202: IMS界面調用編碼器對這一事件信息做出處理，編碼器根據(jù)定義好的 規(guī)則將這一事件信息編碼為固定格式的文檔。例如，該文檔中可以包含添加 聯(lián)系人事件，聯(lián)系人的uri唯一標識等內容；
S203: IMS界面接收到編碼器反饋回的固定格式的文檔后，將文檔發(fā)送給協(xié) 議層。由于文檔格式固定，所以傳遞時可以采用統(tǒng)一的方式，例如可以l吏文 檔中包括文檔的地址信息和長度信息，根據(jù)文檔的地址和長度來進行傳輸。 例如，可以文檔的地址信息對應所需發(fā)送文檔的第一個字節(jié)，每傳遞一個字 節(jié)，地址加一，直至所增加的地址值等于文檔的長度為止，表示該文檔發(fā)送
完畢。這一過程可以采用固定的函數(shù)接口來傳遞。當然，也可以根據(jù)文檔類
型、文檔內容、文檔大小進行傳遞。比如固定的函凄t接口 sendto(int type, char* buf, int buf len),第一個變量type表示標準文檔的類型，比如 1表示XML格式的，2表示文本格式的。第二個變量Buf表示文檔內容，第 三個變量buflen表示文檔大小。
S204:協(xié)議層收到文檔后，調用解析器對其進行解析，解析器根據(jù)步驟S202
中同樣的規(guī)則解析出其中的事件信息。前例中，協(xié)議層根據(jù)解析出來的結構，
得知該事件信息是添加聯(lián)系人，同時得到了聯(lián)系人ur i。
S205:之后，協(xié)議層根據(jù)OMA的規(guī)范組織SIP或HTTP報文，將獲得的事件
信息發(fā)送給服務器就可以了 。
對于下行信息的傳遞，參見圖3:
S301:協(xié)議層接收到服務器的事件信息；
S302:協(xié)議層調用編碼器對這一事件信息進行封裝，編碼為固定;^各式的 文檔；
S303:協(xié)議層把封裝好的固定格式的文檔傳輸給IMS界面； S304: IMS界面調用解析器，按照S302中相同的規(guī)則，對S303中傳來 的文檔進行解析，得到其中的事件信息；
S305:將上述信息顯示在界面上以顯示給用戶。
可以使用XML格式來作為數(shù)據(jù)傳遞的標準。參見圖4，事件信息經(jīng)過解碼 后，成為如圖4所述的XML文檔。其中包括了XML頭文件、頭文件中可以包括 該文檔的地址信息和長度信息，處理事件標識、錯誤標識號及具體的XML事 件結構。在具體事件結構中，可以根據(jù)不同的事件進行擴展，比如添加聯(lián)系 人，獲耳又大頭l象，開士會——個乂015 ( voice—over—internet—protocal，網(wǎng)際音 頻協(xié)議)呼叫，關閉一個POC的會話，完成一個遠端白板控制等。
將所有的事件信息封裝成統(tǒng)一的文檔格式之后，就可以把IMS界面與協(xié)議層 之間的用戶接口合并為 一個統(tǒng)一格式的接口 。所有的文檔都可以通過該接口 在協(xié)議層與IMS界面之間進行傳遞。例如，接口可以根據(jù)XML文檔的地址和 長度來選擇要傳輸?shù)奈臋n。
權利要求
1、一種在IMS，即IP多媒體子系統(tǒng)中傳遞事件信息的系統(tǒng)，包括IMS界面和協(xié)議層，IMS界面接收來自用戶的事件信息，協(xié)議層接收來自網(wǎng)絡的事件信息，其特征在于，還包括編碼器及解析器，編碼器用于將IMS界面接收到的事件信息編碼為固定格式的文檔并反饋給IMS界面，IMS界面還用于將所述固定格式的文檔發(fā)送給協(xié)議層，解析器用于將協(xié)議層從IMS界面接收到的所述固定格式的文檔解析為事件信息并反饋給協(xié)議層；編碼器還用于將協(xié)議層接收到的事件信息編碼為固定格式的文檔并反饋給協(xié)議層，協(xié)議層還用于將所述固定格式的文檔發(fā)送給IMS界面，解析器還用于將IMS界面從協(xié)議層接收到的所述固定格式的文檔解析為事件信息并反饋給IMS界面。
2、 如權利要求1所述的系統(tǒng)，其特征在于，所述固定格式的文檔為XML 文檔。
3、 如權利要求1或2所述的系統(tǒng)，其特征在于，所述的固定格式的文 檔中包括了地址信息和文檔長度信息，所述IMS界面根據(jù)所述地址信息和文 檔長度信息將所述固定格式的文檔發(fā)送給協(xié)議層，所述協(xié)議層根據(jù)地址信息 和文檔長度信息將所述固定格式的文檔發(fā)送給IMS界面。
4、 一種在IMS中傳遞事件信息的方法，其特征在于，包括如下步驟A、 將IMS界面接收到的事件信息編碼為固定格式的文檔；B、 IMS界面將步驟A中所述的文檔發(fā)送給協(xié)議層；C、 對協(xié)議層在步驟B中接收到的文檔進行解析，得到步驟A中所述的 事件信息。
5、 如權利要求4所述的方法，其特征在于，所述的固定格式的文檔為 XML文檔。
6、 如權利要求4或5所述的方法，其特征在于，所述的固定格式的文 檔中包括了地址信息和文檔長度信息，步驟B中，所述IMS界面根據(jù)所述地 址信息和文檔長度信息將所述固定格式的文檔發(fā)送給協(xié)議層。
7、 一種IMS中傳遞事件信息的方法，其特征在于，包括如下步驟A、 將協(xié)議層接收到的事件信息編碼為固定格式的文檔；B、 協(xié)議層將步驟A中所述的文檔發(fā)送給IMS界面；C、 對IMS界面在步驟B中接收到的文檔進行解析，得到步驟A中所 述的事件信息。
8、 如權利要求7所述的方法，其特征在于，所述的固定格式的文檔為 XML文檔。
9、 如權利要求7或8所述的方法，其特征在于，所述的固定格式的文 檔中包括了地址信息和文檔長度信息，步驟B中，所述協(xié)議層根據(jù)地址信息 和文檔長度信息將所述固定格式的文檔發(fā)送給IMS界面。
全文摘要
一種在IMS領域中傳遞事件信息的系統(tǒng)，包括IMS界面和協(xié)議層，編碼器及解析器，編碼器用于將IMS界面接收到的事件信息編碼為固定格式的文檔并反饋給IMS界面，IMS界面還用于將所述固定格式的文檔發(fā)送給協(xié)議層，解析器用于將協(xié)議層從IMS界面接收到的所述固定格式的文檔解析為事件信息并反饋給協(xié)議層；編碼器還用于將協(xié)議層接收到的事件信息編碼為固定格式的文檔并反饋給協(xié)議層，協(xié)議層還用于將所述固定格式的文檔發(fā)送給IMS界面，解析器還用于將IMS界面從協(xié)議層接收到的所述固定格式的文檔解析為事件信息并反饋給IMS界面。本發(fā)明通過將事件信息進行封裝，使得任何廠家實現(xiàn)的底層協(xié)議實現(xiàn)模塊都能夠很好的和其他廠家的用戶界面模塊所兼容。
文檔編號H04L12/58GK101184057SQ20071016774
公開日2008年5月21日 申請日期2007年10月24日 優(yōu)先權日2007年10月24日
發(fā)明者周煜申 申請人:中興通訊股份有限公司