專利名稱：一種縮短多方通話業務建立時間的方法與系統的制作方法
技術領域：
本發明涉及多媒體廣播/組播(Multimedia Broadcast/Multicast Service，MBMS)技術，特別涉及一種基于MBMS機制的IMS(IP Multimedia Subsystem，IP多媒體子系統)業務的傳輸技術。
背景技術：
組播/廣播技術是一種從一個數據源向多個目標傳送數據的技術，在傳統移動通信網絡中，小區組播業務或廣播業務(CBS，Cell Broadcast Service)允許低比特率數據通過小區共享廣播信道向所有用戶終端UE(User Equipment)發送，此種業務屬于消息類業務。
現在，人們對移動通信的需求已不再滿足于電話和消息業務，隨著因特網(Internet)的迅速發展，大量移動多媒體業務涌現出來。其中一些移動多媒體業務要求多個用戶終端能同時接收相同數據，例如視頻點播、電視廣播、視頻會議、網上教育、互動游戲等。這些移動多媒體業務與一般的數據業務相比，具有數據量大、持續時間長、時延敏感等特點。目前的網際協議(IP，InternetProtocol)組播和廣播技術只適用于有線IP通信網絡，不適用于移動通信網絡，因為移動通信網絡具有特定的網絡結構、功能實體和無線接口，這些都與有線通信IP網絡不同。
為有效地利用移動通信網絡資源，第三代移動通信全球標準化組織(3GPP，3rd Generation Partnership Project)提出移動通信網絡的MBMS，從而在移動通信網絡中提供一個數據源向多個接收方發送數據的點到多點(PTM，Point ToMultipoint)業務，實現網絡資源共享，提高網絡資源的利用率，尤其是空口資源。3GPP提出的MBMS不僅能實現純文本低速率的消息類組播和廣播，而且還能實現高速多媒體業務的組播和廣播，這無疑順應了未來移動數據發展的趨勢。
圖1為支持廣播/組播業務的無線網絡結構示意圖，如圖1所示，現有3GPP中，支持廣播/組播業務的無線網絡實體為廣播/組播業務服務器(BM-SC)，BM-SC通過Gmb接口或Gi接口與關口GPRS支持節點(GGSN，Gateway GPRSSupport Node)相連，一個BM-SC可與多個GGSN相連；GGSN通過Gn/Gp接口與服務GPRS支持節點(SGSN，Serving GPRS Support Node)相連，一個GGSN可與多個SGSN相連；SGSN可通過Iu接口與通用移動通信系統(UMTS，Universal Mobile Telecommunications System)陸地無線接入網(UTRAN，UMTSTerrestrial radio access network)相連，然后UTRAN通過Uu接口與UE相連，SGSN也可通過Iu/Gb接口與全球移動通信系統增強無線接入網(GERAN)相連，然后GERAN通過Um接口與UE相連。其中，GGSN和SGSN屬于無線網絡中核心網(CN，Core Network)內的節點。
從圖1給出的網絡結構可以看出，為了支持MBMS業務，在第三代移動通信系統中增加移動網功能實體廣播組播業務中心，即BM-SC，所述BM-SC為內容提供者的入口，用于授權和在移動網中發起MBMS業務，并按照預定時間計劃傳送MBMS內容。此外，在用戶終端UE、UTRAN、GERAN、SGSN、GGSN等功能實體上增加與MBMS相關的功能。
MBMS包括組播模式和廣播模式，其中組播模式需要用戶終端簽約相應的組播組，進行業務激活，并產生相應的計費信息。由于組播模式和廣播模式在業務需求上存在不同，導致各自的業務流程也不同，分別如圖2和圖3所示，圖2為MSMS組播模式的業務流程示意圖，圖3為MSMS廣播模式的業務流程示意圖。
如圖2所示，MBMS組播業務涉及的處理過程包括簽約(Subscription)、服務宣告(Service announcement)、用戶終端加入(Joining)、會話開始(SessionStart)、MBMS通知(MBMS notification)、數據傳送(Data transfer)、會話結束(Session Stop)和用戶終端退出(Leaving)，具體如下所述。
簽約過程，用來建立用戶終端與業務提供者之間的關系，讓用戶終端預先訂閱所需的MBMS服務；服務宣告過程，用于由BM-SC宣告當前能提供的服務，即通知用戶終端MBMS業務的相關信息；用戶終端加入過程即MBMS業務激活過程，UE在加入過程中，通知網絡自身愿意成為當前組播組的成員，接收對應MBMS業務的數據，該加入過程會在網絡和加入組播組的UE中創建記錄UE信息的MBMS UE上下文；會話開始過程中，BM-SC準備好數據傳輸，通知網絡建立相應核心網和接入網的承載資源；MBMS通知過程用于由RNC(Radio Network Controller，無線網絡控制器)通知UE MBMS組播會話即將開始；在數據傳送過程中，BM-SC通過會話開始過程中建立的承載資源將數據傳輸給UE，MBMS業務在UTRAN和UE間傳輸時有兩種模式點對多點(PTM，Point To Multipoint)模式和點對點(PTP，Point To Point)模式，PTM模式通過MBMS點到多點業務信道(MTCH，MBMS point-to-multipoint Traffic Channel)發送相同的數據，所有加入組播業務或對廣播業務感興趣的UE都可以接收，PTP模式通過專用業務信道(DTCH，Dedicated Traffic Channel)邏輯信道發送數據，只有相應的一個UE可以收到；會話結束過程用于將會話開始過程建立的承載資源釋放；用戶終端退出過程使組內的訂戶離開組播組，即用戶終端不再接收組播數據，該過程會將相應MBMS UE上下文刪除。
如圖3所示，MBMS廣播業務涉及的處理過程與MBMS組播業務類似，只是在會話開始之前，不需要執行簽約過程和用戶終端加入過程，并且，在會話結束之后，不需要執行用戶終端退出過程。
在多種應用的推動下，出現基于IP的多媒體子系統IMS(IP MultimediaSubsystem)架構，目的是在移動網絡中使用一種標準化的開放的結構來實現多種多樣的多媒體應用，提供給用戶終端更多的選擇和更豐富的感受。
3GPP定義的IMS疊加在分組域網絡之上，由CSCF(呼叫狀態控制功能)、MGCF(媒體網關控制功能)、MRF(媒體資源功能)和HSS(歸屬簽約用戶終端服務器)等功能實體組成，其中CSCF又可以分成S-CSCF(服務CSCF)、P-CSCF(代理CSCF)和I-CSCF(查詢CSCF)三個邏輯實體，S-CSCF是IMS的業務交換中心，執行會話控制，維持會話狀態，負責管理用戶終端信息，產生計費信息等；P-CSCF是終端用戶終端接入IMS的接入點，完成用戶終端注冊，負責QoS控制和安全管理等，I-CSCF負責IMS域之間的互通，管理S-CSCF的分配，對外隱藏網絡拓撲和配置，產生計費數據等。MGCF控制網關，實現IMS網絡和其它網絡的互通，MRF提供媒體資源，如收放音，編解碼和多媒體會議橋。HSS是用戶終端數據庫，存儲IMS用戶終端的簽約數據和配置信息等。
3GPP定義的IMS網絡也可以應用于3GPP2中定義的分組網絡之上，提供和多種類型網絡的互通，實現和用戶終端使用終端類型的無關性。本文件并不限制IMS只應用在3GPP相關的網絡和應用上，其他類型的接入網絡和承載網絡的業務和應用也可以用IMS架構來實現。
在IMS中，使用SIP(Session Initiation Protocol，會話發起協議)作為IP多媒體會話的信令控制協議。
會話發起協議SIP用于發起會話，它能控制多個參與者參加的多媒體會話的建立和終結，并能動態調整和修改會話屬性，如會話帶寬要求、傳輸的媒體類型(語音、視頻和文本等)、媒體的編解碼格式、對組播和單播的支持等。
隨著寬帶網絡技術的快速發展，在移動通信系統出現PoC(PTT over cellular，基于蜂窩系統的即按即講)業務，所述的PoC業務是OMA(open mobile alliance，開放移動聯盟組織)定義的在分組網絡上實現的PTT(Push To Talk，即按即講)業務，其中，所述的PTT業務是一種半雙工的通信技術。
PoC業務的實現為移動通信系統引入了一種現有移動系統以及傳統語音呼叫系統無法提供的通信模式。PoC業務在滿足實時呼叫的同時，保證了開銷最小化。同時，PoC業務因其采用VoIP(分組語音)以及半雙工的方式，使得其能夠低成本、高效率地滿足用戶終端的實時通信需求。
目前，根據OMA定義可知，PoC的業務開展的模式如圖4所示，主要包括以下過程(1)具有PoC能力終端的用戶終端首先需要和PoC業務的供應商簽約，獲得PoC業務許可；(2)POC客戶端通過終端發現網絡具備PoC業務能力；(3)POC客戶端通過PoC業務供應商建立了和其他POC客戶端的聯系；(4)POC客戶端可以通過按鍵要求發言，實現業務。
相應的PoC的網絡框架結構如圖5所示，主要包括PoC client(PoC客戶端)、PoC server(PoC服務器)、SIP core(支持會話初始協議的核心網)、XDMS(XMLDocument Management Server支持XML的文件管理服務器)、Presence server(呈現業務服務器)等。
可以看到現有的PoC是將PoC基于SIP Core之上，利用SIP Core的能力實現用戶終端之間的路由和查找。所述的SIP core可以是IMS(IP多媒體子系統)網絡，也可以是其他基于SIP協議的網絡。
廣播組播業務的應用使得承載網絡能夠支持優化的多媒體數據傳輸，比如對于一個位于應用服務器上的IMS應用，如果需要發送相同的多媒體數據給一組IMS用戶終端，那么就可以利用底層承載網絡提供的廣播多播能力，使用這種節約空口資源和網絡資源的MBMS業務來傳送數據，從而使得運營商能夠提高資源的利用率，降低運營成本。
這樣的IMS應用已經存在很多，如PoC業務，conference會議業務，數字電視，多媒體聯網游戲等。這些應用一般都是限定在一個群組中進行的多方通話業務，因此會出現相同的多媒體數據需要發送給群組中的多個用戶終端的需求，因此可以使用MBMS機制來實現承載層面的數據傳輸。
目前提出的一種使用MBMS機制實現PoC業務的方案可以如圖6所示，主要包括如下步驟。
步驟101，客戶端A需要呼叫被叫PoC客戶端B時，先訪問PoC服務器，發出請求信息INVITE；
步驟102，通過SIP信令，PoC服務器通知被叫PoC客戶端B一個多播地址multicast；步驟103，PoC客戶端B分析從PoC服務器收到的INVITE消息中的多播參數相關的信息，比如用來指示客戶端B關于PoC服務器希望使用MBMS機制的上下行的地址；如果客戶端B支持MBMS機制，按照3GPP TS 23.246所描述的執行MBMS激活過程，即進行MBMS的上下文建立，然后執行步驟104；步驟104，PoC客戶端B向PoC服務器發送200OK消息；步驟105，PoC服務器根據PoC客戶端B發送的200OK消息向客戶端A返回的200OK應答消息，該200OK應答消息中指示客戶端A也加入多播承載，這個指示是通過攜帶上行用的單播地址和下行用的多播地址來實現的；步驟106，客戶端A加入多播承載，執行MBMS激活過程，即進行MBMS的上下文建立；步驟107，PoC服務器向客戶端A發送Receiving Talk Burst；步驟108，PoC服務器向客戶端B發送Receiving Talk Burst；步驟109，PoC會話的媒體數據通過多播會話進行傳輸；如果客戶端A或者B希望退出這個PoC會話，那么同時也要去激活已經建立的MBMS上下文，即同時執行步驟110與步驟111。
步驟110，客戶端A的MBMS上下文去激活過程；步驟111，客戶端B的MBMS上下文去激活過程；步驟112，PoC服務器向客戶端A發送200OK。
PoC業務本質上還是一種話音業務，因此對實時性的要求比較高，而上述的技術方案中，當PoC服務器決定使用MBMS機制傳送媒體數據的時候，通過發送的INVITE消息通知被叫用戶終端，這時候被叫用戶終端才發起MBMS會話建立過程，當MBMS上下文建立完成之后，才繼續PoC會話的協商過程；如果考慮主叫也建立MBMS上下文的過程，則建立時間就更長。相對原有的PoC會話建立過程來說，增加的建立時延太長，發起會話建立的POC客戶端很可能由于等待時間太長而放棄使用這次PoC業務，改為使用其他通信方式，同時這么長的建立時間也不符合用戶終端的使用習慣，因此這種機制必須加以改進，否則無法進行實際應用。
發明內容
有鑒于此，本發明提供一種縮短多方通話業務建立時間的方法及系統，當IMS業務的傳輸過程中引入MBMS機制來實現媒體數據傳輸時，能有效降低會話建立的時間。
一種縮短多方通話業務建立時間的方法，其中，包括步驟A，使用IMS應用的用戶終端完成IMS注冊后，發起至少一個通用MBMS會話的建立過程，預先建立至少一個通用MBMS上下文；步驟B，當服務器確定需要通過廣播多播機制發送數據時，使用上述已建立的通用MBMS上下文向用戶終端發送數據。
一種縮短多方通話業務建立時間的系統，其中，該系統包括用戶終端、BM-SC和服務器，服務器與用戶終端之間進行IMS業務的數據傳輸，其特征在于，使用IMS應用的用戶終端完成IMS注冊后，發起至少一個通用MBMS會話的建立過程，與BM-SC預建立至少一個通用MBMS上下文，當服務器確定需要通過廣播多播機制發送數據時，使用上述已建立的通用MBMS上下文向用戶終端發送數據。
與現有技術相比，由于本發明一種縮短多方通話業務建立時間的方法與系統，通過引入預建立通用MBMS上下文，在業務會話建立之前就建立好一個通用MBMS上下文，然后在真正建立業務會話的時候直接使用該通用MBMS上下文，而不需要重新建立MBMS上下文，從而能有效降低會話建立的時間，提高用戶的滿意度。
圖1為現有技術之支持廣播/組播業務的無線網絡結構示意圖。
圖2為現有技術之MSMS組播模式的業務流程示意圖。
圖3為現有技術之MSMS廣播模式的業務流程示意圖。
圖4為現有技術之PoC的業務開展的模式之示意圖。
圖5為現有技術之PoC的業務開展的模式之相應網絡框架之結構框圖。
圖6為現有技術之使用MBMS機制實現PoC業務的流程示意圖。
圖7為本發明之較佳第一實施方式之工作流程圖。
圖8為本發明之較佳第二實施方式之工作流程圖。
圖9為本發明之較佳第四實施方式之工作流程圖。
具體實施例方式
為使本發明的目的、技術方案和優點更加清楚明白，以下結合具體實施方式
以及附圖，對本發明作進一步詳細說明。
本發明提供的MBMS業務中信息接發之技術，適用于WCDMA、CDMA2000、WLAN、UTRA TDD和TD-SCDMA等使用各種無線接入方式和有線接入方式的通信系統。
本發明之技術方案適用于基于MBMS機制實現IMS業務應用的系統，比如POC業務，conference會議業務，數字電視，多媒體聯網游戲等。這些應用一般都是限定在一個群組中進行的多方通話業務，因此會出現相同的數據需要發送給群組中的多個用戶終端的需求，因此可以使用MBMS機制來實現承載層面的數據傳輸。
但為敘述的方便，本發明之較佳實施方式以PoC業務為例進行說明，且本發明的處理過程可以應用在所有位于接收方的多個PoC客戶端，但為描述方便，以下的較佳實施方式均以對一個PoC客戶端進行說明。
則當使用IMS應用的用戶終端完成IMS注冊之后，就發起至少一個MBMS會話的建立過程，預先建立至少一個MBMS會話，在建立過程中，相應確定至少一個通用MBMS上下文，即POC客戶端通過GPRS網絡中的SGSN及GGSN功能實體，和BM-SC預建立至少一個通用MBMS上下文，該通用MBMS上下文用于當服務器確定需要通過廣播多播機制發送數據時，用于向多個用戶終端發送數據。這樣當POC客戶端需要接收某個POC會話的時候，而且該POC業務可能需要用到廣播多播機制來節約網絡資源以及空口資源，就不需要花費時間來完成MBMS承載的建立過程了，從服務器接收媒體數據可以直接使用上述通用MBMS會話，從而縮短了POC業務的會話建立時間。
上述預先建立好，在真正有業務數據傳輸時直接使用的MBMS會話可以稱之為通用MBMS會話。與現有MBMS上下文的建立是為某個特定業務激活的不同，本發明POC客戶端通過事先的業務通知過程或者配置的方法獲知一個IP多播地址，這個IP多播地址在建立通用MBMS上下文的時候沒有被特別指定給某一個基于MBMS承載的業務，只是表示已建立一個MBMS承載，具體哪個業務使用該MBMS承載來發送數據在此刻并不確定，即在所述建立過程中確定的所述IP多播地址此時僅用于標識建立的所述通用MBMS上下文，可以用于任意使用所述該通用MBMS上下文的業務，具體由哪個業務使用需要由后續過程來指定。
這樣的IP多播地址可以是一個或者多個，即根據運營商的配置或者網絡狀況，可以選擇建立一個或者多個通用MBMS會話，即建立一個或者多個通用MBMS上下文，每一個通用MBMS上下文可以被分配一個IP多播地址，用于后續承載廣播多播業務的時候使用，這些通用MBMS會話的承載能力可以相同或者不同。
如果POC客戶端所在的網絡中有多個BM-SC用于支持MBMS承載業務，POC服務器無法判斷要將數據發送給哪個BM-SC的時候，可以通過POC客戶端在POC業務建立過程中通知POC服務器知道。
考慮到MBMS上下文的建立和保存是要耗費一定網絡資源的，因此可以在任意時刻盡量維持網絡中有至少一個這樣的通用MBMS上下文，這樣當有一個POC群組業務建立的時候，可以立刻使用當前所維持的這個通用MBMS上下文。在網絡資源允許的條件下，當使用完當前所有的通用MBMS上下文時，再建立一個通用MBMS上下文，這樣當有一個新的POC群組業務發起建立的時候，還是可以利用已經建立好的通用MBMS上下文來立刻完成承載建立，且網絡中最多只浪費一個這樣的通用MBMS上下文。
因為建立的是通用MBMS上下文，在建立的時候還無法確定該通用MBMS上下文是為哪個POC群組業務服務的，因此可以將同一個MBMS服務區內的所有可能使用到多播廣播機制傳輸媒體數據的POC客戶端都加進來，即每個通用MBMS上下文和一個具體業務關聯之前，其所屬MBMS服務區內所有可能用到MBMS機制接收數據的用戶終端都能使用該通用MBMS上下文。但是當建立了一個具體的POC業務并和通用MBMS上下文關聯之后，這個通用MBMS上下文中包括的一些POC客戶端就不能繼續保留在該通用MBMS上下文中了，只有屬于該具體POC群組業務的那些簽約POC客戶端才可以使用該確定的通用MBMS上下文來接收下行媒體數據。
同時，由于建立這個通用MBMS上下文的時候無法和具體業務進行關聯，因此也無法對這個通用MBMS上下文包括的POC客戶端進行鑒權，這個鑒權過程也需要在具體POC業務和通用MBMS上下文關聯的時候進行。
POC服務器首先確定當前POC業務中涉及到的POC客戶端是哪些并通過BM-SC對這些POC客戶端進行鑒權，BM-SC將該POC業務和當前已經建立的通用MBMS上下文用到的IP多播地址進行關聯，同時對POC服務器指定的POC客戶端進行鑒權，將沒有通過鑒權以及沒有指示進行鑒權的用戶終端從能夠使用該通用MBMS上下文的用戶終端信息中刪除。這些被刪除的POC客戶端就是不屬于當前建立的POC業務的那些POC客戶端，因為這些POC客戶端當前沒有了通用MBMS上下文，因此為了下一個POC群組業務建立的需要，可以再發起一個建立通用MBMS上下文的過程，其處理過程和上面描述的類似。在某些情況下，屬于同一個POC群組業務的用戶是可以事先確定的，比如Pre-arranged這種預先定義好了的POC群組，那么這類POC用戶終端可以自行建立一個通用MBMS上下文。因此，關于哪些用戶可以共同建立一個通用MBMS上下文的準則可以有很多種，這里不多贅述。
由于對于POC客戶端所在歸屬網絡的POC服務器，根據運營商的配置情況，可以配置這些IP多播地址，也可以不配置，在使用的時候由POC客戶端通知POC服務器；以及POC客戶端和其歸屬網絡的POC服務器之間可以建立預建立會話，也可以不建立。所以當主叫POC客戶端需要發送媒體數據給該POC業務會話中的其他POC客戶端時，根據被叫POC客戶端所在歸屬網絡的POC服務器是否配置IP多播地址，以及被叫POC客戶端與其歸屬網絡的POC服務器之間是否已建立預建立會話，就有不同的實現過程，具體如下所述的五個具體實施方式
。下述的實施方式描述被叫POC客戶端在接收多媒體數據所采用的流程，關于從主叫POC客戶端傳送INVITE消息到POC服務器的過程可以采用現有技術，在此省略。
如圖7所示，為本發明之較佳第一實施方式的工作流程圖。本較佳實施方式之縮短多方通話業務建立時間的系統主要包括主叫POC客戶端B(圖未示)，被叫方PoC客戶端A21、GPRS節點22、廣播/組播業務服務器BM-SC23、SIP/IPCore A24、PoC PF(Participating Function)服務器25、SIP/IP Core X26、PoC CF(Controlling Function)服務器27。其中，SIP/IP Core A24與SIP/IP Core X26為基于會話發起協議或者IP協議的核心網，PoC PF服務器25執行參與PoC會話的功能，PoC CF服務器27執行控制整個PoC會話的功能；PoC PF服務器25和PoC CF服務器27可以是同一個PoC服務器或者不同的PoC服務器，但為描述的方便，本較佳實施方式中將PoC PF服務器25和PoC CF服務器27分為不同的PoC服務器。
在該系統中，POC PF服務器25上配置IP多播地址信息，而且POC客戶端A21選擇自動接收該會話請求，POC客戶端A21和其歸屬網絡的POC PF服務器25之間已預先建立一個SIP會話，即預建立會話，以便POC CF服務器27發送到POC PF服務器25的消息可以直接使用該已建立的SIP會話進行傳送，則該系統的工作流程主要包括如下步驟。
步驟201，POC客戶端A21與BM-SC23建立一個通用MBMS上下文；當使用IMS應用的POC客戶端完成IMS注冊之后，就發起至少一個MBMS會話的建立過程，相應建立至少一個通用MBMS上下文，本較佳實施方式中，由于只涉及一個POC客戶端A21，所以以下均描述POC客戶端A21發起建立一個通用MBMS會話建立的過程，具體如下所述。
POC客戶端A21通過GPRS22網絡中的SGSN及GGSN功能實體，和BM-SC23建立一個通用MBMS上下文，以使POC客戶端A21以及其他POC客戶端能通過廣播/多播MBMS的方式接收來自網絡的下行數據。
在通用MBMS上下文建立過程中，確定POC客戶端A21和歸屬POC PF服務器25之間用于媒體在MBMS承載上傳輸所需的各種承載參數，如IP多播地址、端口號、用于空口上群組通知的TMGI(Temporary Mobile Group Identity臨時移動群組標識)，以及該MBMS承載的業務所能夠使用的QoS能力等等，其中所述IP多播地址在建立通用MBMS上下文的時候沒有被特別指定給某一個基于MBMS承載的業務，只是表示建立一個MBMS承載，具體哪個業務使用該MBMS承載來發送數據在此刻并不確定，即在所述建立過程中確定的所述IP多播地址此時僅用于標識建立的所述通用MBMS上下文，可以用于任意使用所述該通用MBMS上下文的業務，具體由哪個業務使用需要由后續過程來指定。
步驟202，POC CF服務器27將INVITE消息發送給SIP/IP Core X26；POC CF服務器27接收主叫POC客戶端B的INVITE消息時，將該INVITE消息發送給SIP/IP Core X26，其中該INVITE消息包括被叫方POC客戶端A21對應的POC地址，POC CF服務器27支持的媒體參數，POC業務指示，主叫方POC客戶端B對應的POC地址等。
步驟203，SIP/IP Core X26將接收的所述INVITE消息路由到POC客戶端A21所在的歸屬網絡；步驟204，SIP/IP Core A24將該INVITE消息路由到POC PF服務器25；SIP/IP Core A24根據所述POC客戶端A21的PoC地址以及POC業務指示，將該INVITE消息路由到POC PF服務器25。
步驟205，POC PF服務器25返回OK應答消息給控制網絡；本實施方式中，在上述完成SIP會話協商后，POC PF服務器25根據不同情況分配給該具體POC會話的通用MBMS上下文所使用的IP多播地址方式也不同，主要有如下兩種。
第一情形當POC PF服務器25判斷當前協商的POC會話要使用MBMS機制傳送媒體數據，而且本地已配置通用MBMS會話使用的IP多播地址，則此刻預留至少一個IP多播地址，即預留至少一個通用MBMS會話。
第二情形當POC PF服務器25判斷POC CF服務器27和其屬于同一個運營網絡，或者POC PF服務器25和POC CF服務器27就是同一個POC服務器，則后續媒體數據的傳送可以不用經過POC PF服務器25(即執行步驟213b的過程)，因此，可以在返回的OK應答消息中攜帶本地預留的至少一個IP多播地址和對應的端口號給POC CF服務器27。
步驟206，SIP/IP Core A24將該OK應答消息轉發給POC CF服務器27所在的控制網絡；SIP/IP Core A24接收PoC PF服務器25發送的OK應答消息并將其轉發給POC CF服務器27所在的控制網絡，該OK應答消息在第二情形下攜帶有上述IP多播地址。
步驟207，SIP/IP Core X26將該OK應答消息轉發給POC CF服務器27；SIP/IP Core X26接收SIP/IP Core A24發送的OK應答消息并將其轉發給POC CF服務器27，該OK應答消息攜帶有上述IP多播地址。
步驟208，POC PF服務器25發送CONNECT消息給POC客戶端A21；POC PF服務器25接收SIP/IP Core X26發送的OK應答消息后，發送CONNECT消息給POC客戶端A21，其中該CONNECT消息包括發起該POC會話的主叫用戶終端B的標識。
步驟209，POC客戶端A21返回Talk Burst Acknowledgement消息給POC PF服務器25以確認CONNECT消息的接收；POC客戶端A21接收POC PF服務器25發送的CONNECT消息后，向POCPF服務器25返回Talk Burst Acknowledgement消息以確認CONNECT消息的接收。
步驟210，POC CF服務器27發送Receiving Talk Burst消息給POC PF服務器25，其中包括當前發言用戶終端的標識；步驟211，POC PF服務器25修改IP地址和端口號，將Receiving Talk Burst消息發送給POC客戶端A21；POC PF服務器25收到POC CF服務器27發送的Receiving Talk Burst消息后，該Receiving Talk Burst消息的目的IP地址和端口號即為POC PF服務器25的IP地址和端口號，POC PF服務器25修改Receiving Talk Burst的目的IP地址和端口號，修改為客戶端A21的IP地址和端口號，并將Receiving Talk Burst消息發送給POC客戶端A21。
如果需要，執行步驟212，POC客戶端A21向POC PF服務器25返回確認消息，也可以不執行步驟212；步驟213，POC CF服務器27發送RTP媒體數據給POC客戶端A21。
POC CF服務器27發送RTP媒體數據給POC客戶端A21的方式根據步驟205的兩種情形，相應的RTP媒體數據發送方式也有兩種，分別如下所述。
第一種方式執行步驟213a，當POC PF服務器25判斷當前協商的POC會話要使用MBMS機制傳送媒體數據，而且本地已配置通用MBMS會話使用的IP多播地址，則根據步驟205預留的至少一個IP多播地址，即預留的至少一個通用MBMS會話，POC PF服務器25收到POC CF服務器27發送的RTP媒體數據之后，修改該RTP數據的IP地址和端口號，將下行IP地址和端口號改為預留的IP多播地址和對應的端口號，則該媒體數據將被送到BM-SC23，進而通過已經建立的通用MBMS會話發送給POC客戶端A21。
第二種方式執行步驟213b，當POC CF服務器27和POC PF服務器25屬于同一個運營網絡，或者二者是同一個POC服務器的時候，則POC CF服務器27發送的RTP媒體數據可以不經過POC PF服務器25，直接通過BM-SC23發送給POC客戶端A21，其中下行的IP地址和端口號就是步驟205中POC PF服務器25發送給POC CF服務器27的IP多播地址和端口號等信息。
本較佳第一實施方式描述的是POC PF服務器上已配置IP多播地址信息，而且POC客戶端A選擇自動接受該會話請求，POC客戶端A和自己歸屬網絡的POC服務器之間已建立預建立會話的情形。當POC客戶端A和自己歸屬網絡的POC服務器之間沒有建立預建立會話，而是使用一般的SIP會話建立過程時，其具體工作過程如圖8所示。
如圖8所示，為本發明之較佳第二實施方式的工作流程圖。圖8的工作過程與圖7的工作過程相似，也是描述被叫側的處理流程。
本較佳第二實施方式之縮短多方通話業務建立時間的系統主要包括主叫POC客戶端B(圖未示)，被叫方PoC客戶端A31、GPRS節點32、廣播/組播業務服務器BM-SC33、SIP/IP Core A34、PoC PF服務器35、SIP/IP Core X36、PoC CF服務器37。其中，PoC PF服務器35和PoC CF服務器37可以是同一個PoC服務器或者不同的PoC服務器，但為描述的方便，本較佳實施方式中將PoCPF服務器35和PoC CF服務器37分為不同的PoC服務器。
在該系統中，POC PF服務器35上已配置IP多播地址信息，而且POC客戶端A31選擇自動接收該會話請求，POC客戶端A31和自己歸屬網絡的POC服務器之間沒建立預建立會話，而使用一般的SIP會話建立過程，則該系統的工作過程主要如下所述。
本第二較佳實施方式的步驟301至步驟304與上述第一實施方式的步驟201至步驟204相似，其不同之處，從步驟305開始就有所不同，主要包括步驟301，POC客戶端A31與BM-SC33建立通用MBMS上下文；步驟302，POC CF服務器37將INVITE消息發送給SIP/IP Core X36；步驟303，SIP/IP Core X36將接收的所述INVITE消息路由到POC客戶端A31所在的歸屬網絡；步驟304，SIP/IP Core A34將該INVITE消息路由到POC PF服務器35；從步驟305開始，本第二較佳實施方式的工作過程與第一實施方式就開始有所不同，具體如下。
步驟305，POC PF服務器35通過SIP信令返回自動應答指示給控制網絡；步驟306，SIP/IP Core A34轉發自動應答指示給SIP/IP Core X36；步驟307，SIP/IP Core X36將收到的自動應答指示再轉發給PoC CF服務器37；步驟308，PoC PF服務器35產生一個INVITE消息并傳送給SIP/IP CoreA34；當SIP/IP Core A34通過SIP信令將自動應答指示經由SIP/IP Core X36傳給PoC CF服務器37之后，就使用一般SIP會話建立過程來建立POC PF服務器35和POC客戶端A31之間的SIP會話，則PoC PF服務器35產生一個INVITE消息并傳送給SIP/IP Core A34。
步驟309，SI/IP Core A34接收該INVITE消息并將其傳給PoC客戶端A31；SIP/IP Core A34接收PoC PF服務器35發送的INVITE消息，并根據該INVITE消息中的被叫方POC客戶端A31對應的POC地址將該INVITE消息發給POC客戶端A31。
步驟310，PoC客戶端A31返回OK應答消息給SIP/IP Core A34；PoC客戶端A31根據接收的SIP/IP Core A34所發送的INVITE消息，返回OK應答消息給SIP/IP Core A34。
步驟311，SIP/IP Core A34再將該OK應答消息傳給PoC PF服務器35；步驟312，PoC PF服務器35重新創建一個OK應答消息并傳給SIP/IP CoreA34；POC PF服務器35終結PoC客戶端A31發送的OK應答消息，PoC PF服務器35重新創建一個OK應答消息并傳給SIP/IP Core A34。
本實施方式中，在上述通過一般SIP會話協商后，POC PF服務器35根據不同情況分配給該具體POC會話的通用MBMS上下文所使用的IP多播地址方式也不同，主要有如下兩種。
第一情形當POC PF服務器35判斷當前協商的POC會話要使用MBMS機制傳送媒體數據，而且本地已配置通用MBMS會話使用的IP多播地址，則此刻預留至少一個IP多播地址，即預留了至少一個通用MBMS會話。
第二情形當POC PF服務器35判斷POC CF服務器37和其屬于同一個運營網絡，或者POC PF服務器35和POC CF服務器37就是同一個POC服務器，則后續媒體數據的傳送可以不用經過POC PF服務器35(即執行步驟317b的過程)，因此，可以在返回給POC CF服務器37的由POC PF服務器35創建的OK應答消息中攜帶本地預留的至少一個IP多播地址和對應的端口號。
步驟313，SIP/IP Core A34將該OK應答消息轉發給控制網絡；SIP/IP Core A34接收PoC PF服務器35發送的OK應答消息并將其轉發給SIP/IP Core X36，該OK應答消攜帶有上述IP多播地址。
步驟314，SIP/IP Core X36將該OK應答消息轉發給POC CF服務器37；SIP/IP Core X36接收SIP/IP Core A34發送的OK應答消息并將其轉發給POC CF服務器37。
步驟315，POC CF服務器37發送Receiving Talk Burst消息給POC PF服務器35；POC CF服務器37根據接收的SIP/IP Core X36發送的OK應答消息，發送Receiving Talk Burst消息給POC PF服務器35，其中該Receiving Talk Burst消息包括當前發言用戶終端的標識；步驟316，POC PF服務器35修改Receiving Talk Burst消息的IP地址和端口號，將其發送給POC客戶端A31；POC PF服務器35收到POC CF服務器37發送的Receiving Talk Burst消息后，該Receiving Talk Burst消息的目的IP地址和端口號即為POC PF服務器35的IP地址和端口號，POC PF服務器35修改Receiving Talk Burst的目的IP地址和端口號，修改為客戶端A31的IP地址和端口號，并將Receiving Talk Burst消息發送給POC客戶端A31。
步驟317，POC CF服務器37發送RTP媒體數據給POC客戶端A31。
POC CF服務器37發送RTP媒體數據給POC客戶端A31的方式根據步驟312的兩種情形，相應的RTP媒體數據發送方式也有兩種，分別如下所述。
第一種方式執行步驟317a，當POC PF服務器35判斷當前協商的POC會話要使用MBMS機制傳送媒體數據，而且本地已配置通用MBMS會話使用的IP多播地址，則根據步驟312預留的至少一個IP多播地址，即預留的至少一個通用MBMS會話，POC PF服務器35收到POC CF服務器37發送的RTP媒體數據后，修改該RTP媒體數據的IP地址和端口號，將下行IP地址和端口號改為預留的IP多播地址和對應的端口號，則該媒體數據將被送到BM-SC33，進而通過已經建立的通用MBMS會話發送給POC客戶端A31。
第二種方式執行步驟317b，當POC CF服務器37和POC PF服務器35屬于同一個運營網絡，或者二者是同一個POC服務器的時候，則POC CF服務器37發送的RTP媒體數據可以不經過POC PF服務器35，直接通過BM-SC33發送給POC客戶端A31，其中下行的IP地址和端口號就是步驟312中POC PF服務器35發送給POC CF服務器37的IP多播地址和端口號等信息。
上述第二較佳實施方式描述的工作過程的條件是POC PF服務器35上已配置IP多播地址信息，且POC客戶端A31選擇自動接收該會話請求，而POC客戶端A31和其歸屬網絡的POC服務器之間沒有建立預建立會話，而使用一般的SIP會話建立過程的工作過程。
但如果POC PF服務器35上沒有配置IP多播地址，POC客戶端A31選擇自動接收該會話請求，且POC客戶端A31和其歸屬網絡的POC服務器之間沒有預建立會話，而使用一般的SIP會話建立過程的工作過程，則其工作過程又稍有不同，具體如下所述的本發明較佳第三實施方式的工作過程。
第三實施方式的工作過程與第二實施方式的工作過程基本相似，其不同之處在于，相對應于第二實施方式的步驟310中，第三實施方式步驟310有一定的改變，具體如下所述。
第三實施方式步驟310PoC客戶端A31返回OK應答消息給SIP/IP CoreA34；PoC客戶端A31根據接收的SIP/IP Core A34所發送的INVITE消息，返回OK應答消息給SIP/IP Core A34，該OK應答消息攜帶有IP多播地址。
則通過后續的第三實施方式步驟311、312、313、314，將所述攜帶有IP多播地址的OK應答消息傳給POC CF服務器37。
其它工作過程類似于第二實施方式的工作過程，在此不多贅述。
本發明還存在一種情況，即POC PF服務器上沒有配置IP多播地址，而且POC客戶端A選擇手動接受POC會話邀請，POC客戶端A和其歸屬網絡的POC服務器之間沒有預建立會話，而使用一般的SIP會話建立過程的工作過程，則其工作過程可以如圖9所示。
如圖9所示，本較佳第四實施方式之縮短多方通話業務建立時間的系統主要包括主叫POC客戶端B(圖未示)，被叫方PoC客戶端A41、GPRS節點42、廣播/組播業務服務器BM-SC43、SIP/IP Core A44、PoC PF服務器45、SIP/IP CoreX46、PoC CF服務器47。其中，PoC PF服務器45和PoC CF服務器47可以是同一個PoC服務器或者不同的PoC服務器，但為描述的方便，本較佳實施方式中將PoC PF服務器45和PoC CF服務器47分為不同的PoC服務器。則其具體工作過程如下所述。
本較佳第四實施方式的步驟401至步驟404與第二實施方式的步驟301至步驟304相似，在此不多贅述。
從步驟405開始才有所不同，具體如下所述。
步驟405，PoC PF服務器45產生一個INVITE消息并發送給SIP/IP CoreA44；PoC PF服務器45收到PoC CF服務器47傳過來的INVITE消息之后，就使用一般SIP會話建立過程來建立POC PF服務器45和POC客戶端A41之間的SIP會話，則PoC PF服務器45產生一個INVITE消息并傳送給SIP/IP Core A44。
該PoC PF服務器45產生的INVITE消息包括被叫方POC客戶端A41對應的POC地址，POC CF服務器47支持的媒體參數，POC業務指示，主叫方POC客戶端B對應的POC地址等。
步驟406，SIP/IP Core A44將PoC PF服務器45發送的INVITE消息轉發給被叫方PoC客戶端A41；SIP/IP Core A44根據PoC PF服務器45發送的INVITE消息中的被叫方POC客戶端A41對應的POC地址將該INVITE消息轉發給被叫方PoC客戶端A41。
步驟407，PoC客戶端A41發送Alerting消息(即振鈴消息)給SIP/IP CoreA44；步驟408，SIP/IP Core A44將該Alerting消息發送給PoC PF服務器45；步驟409，PoC PF服務器45返回該Alerting消息給SIP/IP Core A44；步驟410，SIP/IP Core A44將該Alerting消息發送給SIP/IP Core X46；步驟411，SIP/IP Core X46將該Alerting消息轉發給PoC CF服務器47；步驟412至步驟419相對應之第二實施方式的步驟310至步驟317基本相似，只不過在步驟412至步驟416過程中，IP多播地址由PoC客戶端A41通過OK應答消息經由SIP/IP Core A44、PoC PF服務器45、SIP/IP Core X46傳給PoCCF服務器47，其傳送過程與第二實施方式的步驟310至步驟314的過程相似。
其它工作過程類似于第二實施方式的工作過程，在此不多贅述。
本發明還存在一種情況，即POC PF服務器上配置了IP多播地址，而且POC客戶端A選擇手動接受POC會話邀請，POC客戶端A和其歸屬網絡的POC服務器之間沒有預建立會話，而使用一般的SIP會話建立過程的工作過程，則其工作過程也可如圖9所示，只不過對IP多播地址的處理過程如同第一實施方式中的步驟205。
本第五實施方式中，使用一般的SIP會話完成后，POC PF服務器45根據不同情況分配給該具體POC會話的通用MBMS上下文所使用的IP多播地址方式也不同，主要有如下兩種。
第一情形當POC PF服務器45判斷當前協商的POC會話要使用MBMS機制傳送媒體數據，而且本地已配置通用MBMS會話使用的IP多播地址，則此刻預留至少一個IP多播地址，即預留至少一個通用MBMS會話。
第二情形當POC PF服務器45判斷POC CF服務器47和其屬于同一個運營網絡，或者POC PF服務器45和POC CF服務器47就是同一個POC服務器，則后續媒體數據的傳送可以不用經過POC PF服務器45，因此，可以在返回給POC CF服務器47的由POC PF服務器45創建的OK應答消息中攜帶本地預留的至少一個IP多播地址和對應的端口號。
但上述僅為本發明的較佳實施方式，并非用于限定本發明的保護范圍，任何熟悉本技術領域的技術人員應當認識到，凡在本發明的精神和原則范圍之內，所做的任何修飾、等效替換、改進等，均應包含在本發明的權利保護范圍之內。
權利要求
1.一種縮短多方通話業務建立時間的方法，其特征在于，包括步驟A，使用IMS應用的用戶終端完成IMS注冊后，發起至少一個通用MBMS會話的建立過程，預先建立至少一個通用MBMS上下文；步驟B，當服務器確定需要通過廣播多播機制發送數據時，使用上述已建立的通用MBMS上下文向用戶終端發送數據。
2.如權利要求1所述的一種縮短多方通話業務建立時間的方法，其特征在于，步驟A中預先建立至少一個通用MBMS上下文過程為用戶終端通過GPRS網絡中的SGSN及GGSN功能實體，和BM-SC建立至少一個通用MBMS上下文。
3.如權利要求1所述的一種縮短多方通話業務建立時間的方法，其特征在于，在建立過程中確定所述通用MBMS上下文使用的IP多播地址。
4.如權利要求3所述的一種縮短多方通話業務建立時間的方法，其特征在于，在建立過程中確定的所述IP多播地址此時僅用于標識建立的所述通用MBMS上下文，可以用于任意使用所述該通用MBMS上下文的業務，具體由哪個業務使用需要由后續過程來指定。
5.如權利要求3或4所述的一種縮短多方通話業務建立時間的方法，其特征在于，所述IP多播地址可以是一個或者多個，即當建立一個或者多個通用MBMS上下文時，每一個通用MBMS上下文被分配一個IP多播地址。
6.如權利要求2所述的一種縮短多方通話業務建立時間的方法，其特征在于，當用戶終端所在的網絡中有多個BM-SC用于支持MBMS承載業務時，服務器要將數據發送給哪個BM-SC是通過用戶終端在業務建立過程中通知服務器的。
7.如權利要求1所述的一種縮短多方通話業務建立時間的方法，其特征在于，步驟B之后還包括，當業務使用完當前已經建立的通用MBMS上下文時，可以再建立一個通用MBMS上下文，以維持網絡中存在至少一個空閑的通用MBMS上下文。
8.如權利要求1所述的一種縮短多方通話業務建立時間的方法，其特征在于，每個通用MBMS上下文和一個具體業務關聯之前，其所屬MBMS服務區內所有可能用到MBMS機制接收數據的用戶終端都能使用該通用MBMS上下文。
9.如權利要求8所述的一種縮短多方通話業務建立時間的方法，其特征在于，步驟B具體為當建立一個具體業務并與該通用MBMS上下文關聯后，只有該具體業務的簽約用戶終端才能使用該通用MBMS上下文來接收數據。
10.如權利要求9所述的一種縮短多方通話業務建立時間的方法，其特征在于，用戶終端在接收數據之前還進行與其所關聯的業務的鑒權過程，其鑒權過程在所述業務和通用MBMS上下文關聯的時候進行。
11.如權利要求10所述的一種縮短多方通話業務建立時間的方法，其特征在于，所述鑒權過程具體為服務器確定當前業務中涉及到的用戶終端是哪些并通過BM-SC對所確定的用戶終端進行鑒權；BM-SC將該業務和當前已經建立的通用MBMS上下文用到的IP多播地址進行關聯，并對服務器指定的用戶終端進行鑒權過程，將沒有通過鑒權以及沒有指示進行鑒權的用戶終端從能夠使用該通用MBMS上下文的用戶終端信息中刪除。
12.如權利要求1所述的一種縮短多方通話業務建立時間的方法，其特征在于，步驟B中數據傳輸過程具體為數據從服務器傳到BM-SC，再使用所述已建立的通用MBMS會話從BM-SC傳給用戶終端。
13.如權利要求3或4所述的一種縮短多方通話業務建立時間的方法，其特征在于，如果服務器已配置所述IP多播地址信息，則用戶終端與其歸屬網絡的服務器之間完成SIP會話協商后，服務器預留至少一個所述IP多播地址，即相應預留至少一個所述通用MBMS會話。
14.如權利要求3或4所述的一種縮短多方通話業務建立時間的方法，其特征在于，如果服務器未配置所述IP多播地址或者由用戶終端通知服務器有關IP多播地址，則用戶終端與其歸屬網絡的服務器之間完成SIP會話協商后，用戶終端將所述通用MBMS會話所使用的IP多播地址傳給服務器。
15.如權利要求14所述的一種縮短多方通話業務建立時間的方法，其特征在于，所述服務器包括執行參與會話的PF服務器和控制會話的CF服務器，當PF服務器和CF服務器不是使用同一個POC服務器實現的時候，IP多播地址的傳送是用戶終端將IP多播地址傳給PF服務器，PF服務器再傳給CF服務器。
16.如權利要求13所述的一種縮短多方通話業務建立時間的方法，其特征在于，所述服務器包括執行參與會話的PF服務器和控制會話的CF服務器，則CF服務器將數據傳給PF服務器，PF服務器修改該數據的下行IP地址和對應的端口號，將所述下行IP地址和端口號改為預留的IP多播地址和對應的端口號，再將該數據傳給BM-SC，進而通過已經建立的通用MBMS會話發送給用戶終端。
17.如權利要求13所述的一種縮短多方通話業務建立時間的方法，其特征在于，所述服務器同時具有執行參與會話和控制會話的功能，則服務器使用該預留的IP多播地址和對應的端口號將數據傳給BM-SC。
18.一種縮短多方通話業務建立時間的系統，其特征在于，該系統包括用戶終端、BM-SC和服務器，服務器與用戶終端之間進行IMS業務的數據傳輸，其特征在于，使用IMS應用的用戶終端完成IMS注冊后，發起至少一個通用MBMS會話的建立過程，與BM-SC預建立至少一個通用MBMS上下文，當服務器確定需要通過廣播多播機制發送數據時，使用上述已建立的通用MBMS上下文向用戶終端發送數據。
19.如權利要求18所述的一種縮短多方通話業務建立時間的系統，其特征在于，所述與BM-SC預建立至少一個通用MBMS上下文具體為用戶終端通過GPRS網絡中的SGSN及GGSN功能實體，與BM-SC建立至少一個通用MBMS上下文。
20.如權利要求18所述的一種縮短多方通話業務建立時間的系統，其特征在于，在建立過程中確定所述通用MBMS上下文使用的IP多播地址。
21.如權利要求20所述的一種縮短多方通話業務建立時間的系統，其特征在于，在建立過程中確定的所述IP多播地址此時僅用于標識建立的所述通用MBMS上下文，可以用于任意使用所述該通用MBMS上下文的業務，具體由哪個業務使用需要由后續過程來指定。
22.如權利要求20或21所述的一種縮短多方通話業務建立時間的系統，其特征在于，所述IP多播地址可以是一個或者多個，即當建立一個或者多個通用MBMS上下文時，每一個通用MBMS上下文被分配一個IP多播地址。
23.如權利要求20或21所述的一種縮短多方通話業務建立時間的系統，其特征在于，用戶終端所在歸屬網絡的服務器配置所述IP多播地址；或由用戶終端通知服務器有關IP多播地址。
24.如權利要求23所述的一種縮短多方通話業務建立時間的系統，其特征在于，如果服務器已配置所述IP多播地址信息，則用戶終端與其歸屬網絡的服務器之間完成SIP會話協商后，服務器預留至少一個所述IP多播地址，即相應預留至少一個所述通用MBMS會話。
25.如權利要求23所述的一種縮短多方通話業務建立時間的系統，其特征在于，如果服務器未配置所述IP多播地址或由用戶終端通知服務器有關IP多播地址，則用戶終端與其歸屬網絡的服務器之間完成SIP會話協商后，用戶終端將所述通用MBMS會話所使用的IP多播地址傳給服務器。
26.如權利要求25所述的一種縮短多方通話業務建立時間的系統，其特征在于，所述服務器包括執行參與會話的PF服務器和控制會話的CF服務器，當PF服務器和CF服務器不是使用同一個POC服務器實現的時候，IP多播地址的傳送是用戶終端將IP多播地址傳給PF服務器，PF服務器再傳給CF服務器。
27.如權利要求18所述的一種縮短多方通話業務建立時間的系統，其特征在于，當用戶終端所在的網絡中有多個BM-SC用于支持MBMS承載業務時，服務器要將數據發送給哪個BM-SC是通過用戶終端在業務建立過程中通知服務器的。
28.如權利要求18所述的一種縮短多方通話業務建立時間的系統，其特征在于，當業務使用完當前已經建立的通用MBMS上下文時，可以再建立一個通用MBMS上下文，以維持網絡中存在至少一個空閑的通用MBMS上下文。
29.如權利要求24所述的一種縮短多方通話業務建立時間的系統，其特征在于，所述服務器包括執行參與會話的PF服務器和控制會話的CF服務器，則CF服務器將數據傳給PF服務器，PF服務器修改該數據的下行IP地址和對應的端口號，將所述下行IP地址和端口號改為預留的IP多播地址和對應的端口號，再將該數據傳給BM-SC，進而通過已經建立的通用MBMS會話發送給用戶終端。
30.如權利要求24所述的一種縮短多方通話業務建立時間的系統，其特征在于，所述服務器同時具有執行參與會話和控制會話的功能，則服務器使用該預留的IP多播地址和對應的端口號將數據傳給BM-SC。
全文摘要
本發明涉及一種縮短多方通話業務建立時間的方法及系統，該系統包括用戶終端、BM－SC、服務器，服務器與用戶終端之間進行IMS業務的數據傳輸，其中，使用IMS應用的用戶終端完成IMS注冊后，發起至少一個通用MBMS會話的建立過程，與BM－SC預建立至少一個通用MBMS上下文，當服務器確定需要通過廣播多播機制發送數據時，使用上述已建立的通用MBMS上下文向用戶終端發送數據。因此，本發明在業務會話建立前就建立好一個通用MBMS上下文承載，在真正建立業務會話時直接使用該通用MBMS上下文，而不需要重新建立MBMS上下文，從而有效降低會話建立的時間，提高用戶的滿意度。
文檔編號H04L12/16GK101043431SQ20061006128
公開日2007年9月26日 申請日期2006年6月22日 優先權日2006年6月22日
發明者武亞娟 申請人:華為技術有限公司