CN101043431A - 一种缩短多方通话业务建立时间的方法与系统 - Google Patents

Abstract

本发明涉及一种缩短多方通话业务建立时间的方法及系统，该系统包括用户终端、BM－SC、服务器，服务器与用户终端之间进行IMS业务的数据传输，其中，使用IMS应用的用户终端完成IMS注册后，发起至少一个通用MBMS会话的建立过程，与BM－SC预建立至少一个通用MBMS上下文，当服务器确定需要通过广播多播机制发送数据时，使用上述已建立的通用MBMS上下文向用户终端发送数据。因此，本发明在业务会话建立前就建立好一个通用MBMS上下文承载，在真正建立业务会话时直接使用该通用MBMS上下文，而不需要重新建立MBMS上下文，从而有效降低会话建立的时间，提高用户的满意度。

Description

一种缩短多方通话业务建立时间的方法与系统

技术领域

本发明涉及多媒体广播/组播(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有一定的改变，具体如下所述。

第三实施方式步骤310：PoC客户端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多播地址和对应的端口号。

但上述仅为本发明的较佳实施方式，并非用于限定本发明的保护范围，任何熟悉本技术领域的技术人员应当认识到，凡在本发明的精神和原则范围之内，所做的任何修饰、等效替换、改进等，均应包含在本发明的权利保护范围之内。

Claims (30)

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。

Images