CN1925480B - 互联网协议多媒体子系统业务支持方法、实体和网络 - Google Patents

Abstract

本发明提供一种支持互联网协议多媒体子系统业务的方法，包括以下步骤：建立互联网协议多媒体子系统业务会话；激活广播多播业务；建立广播多播业务承载；传输互联网协议多媒体子系统业务的上行链路数据；传输互联网协议多媒体子系统业务的下行链路数据，其中，所述互联网协议多媒体子系统业务的下行链路数据通过多广播多播业务承载进行传输。本发明还提供了相应的网络/功能实体和网络。根据本发明，参与IMS会话的多个用户终端能够通过广播多播业务的方式获取IMS业务的下行数据，尽可能的利用了能够共享的资源，减少了IMS业务对资源的浪费，并且有效地减小了不同IMS用户终端接收相同业务数据时可能经历的不同时延。

Description

互联网协议多媒体子系统业务支持方法、实体和网络

技术领域

本发明大体上涉及移动通信网络，特别地，涉及在移动通信网络中支持互联网协议(IP)多媒体子系统业务的方法、相关网络/功能实体和网络体系。

背景技术

包括第三代通用移动通信系统(UTMS)的由第三代合作伙伴项目(3GPP)标准化的现代移动通信网络能够为各种用户终端提供其所需的业务，例如，移动数据网业务以及IP多媒体业务。

其中，3GPP从版本Release 5开始将IP多媒体子系统(IMS)引入其协议框架。通过IMS系统，可以向用户终端提供电路域(CS)无法提供的多媒体增值业务，例如呈现业务(Presence)、即时消息、视讯会议等。这样，IMS使得移动通信网络和互联网多媒体应用/业务融合在一起。在网络融合的发展趋势下，标准化组织包括3GPP、欧洲电信标准协会(ESTI)和国际电联(ITU-T)，将IMS定义为基于会话发起协议(Session Initiation Protocol)/会话描述协议(Session Description Protocol)的通用平台(SIP负责信令面而SDP负责用户面)，同时支持移动网络和固定网络用户的接入的系统。它不仅能够帮助运营商逐步过渡到全IP，还可以为不同的无线网络，如GSM、CDMA2000和WLAN，建立通用的多媒体呼叫控制业务核心。这些无线网以及上述固定网络在IMS的网络结构中被称为IP连通接入网(IP-CAN)，它们作为IMS的接入网为IMS业务提供了承载。因此，IMS提供了未来统一的网络架构，已经成为业界，包括设备厂商和运营商非常关注的技术。

图1A示出了现有技术中支持IMS业务的网络系统示意图，其中以UMTS和公共交换电话网(PSTN)作为IP-CAN的示例进行说明。参考标号10表示IMS核心网；参考标号12表示连接到用户终端1至N的UMTS，其中用户终端1通过无线网络控制器(RNC)124接入UMTS 12，而用户终端2至N则通过RNC 123接入UMTS 12；参考标号14表示PSTN，其中示意性地示出固定用户终端141和142。如图1A所示，在IMS核心网10中，应用服务器(AS)101通过服务呼叫会话控制功能实体(S-CSCF)102和代理呼叫会话控制功能实体(P-CSCF)103与移动通信网络UMTS 12和PSTN 14进行通信，从而建立到用户终端1至N以及固定用户终端141和142之间点到点专用承载的IMS会话连接。

图1B示意性地示出了现有的IMS会话业务流程。IMS会话可以由单个IMS用户终端发起，或者由应用服务器代表某个IMS用户终端发起。但是，现有的IMS业务使用的是点对点承载，每个参与IMS会话的用户终端独立发起资源预定过程，以便建立此终端专用的IMS业务数据承载，例如在UMTS中为分组数据协议(PDP)上下文。这样，当例如图1A所示的系统执行图1B中的下行链路数据传输过程时，一方面对于UMTS中的用户终端2至N，它们的下行链路数据会经历多个相同网元，例如从IMS核心网10的AS 101开始到UMTS 12的S-CSCF 102、P-CSCF 103、GPRS网关支持节点(GGSN)121、GPRS服务支持节点(SGSN)122以及无线网络控制器(RNC)123等一系列网元；而用户终端1的下行链路数据与用户终端2至N的下行链路数据也同时经历了从IMS核心网10的AS 101开始到UMTS 12的S-CSCF 102、P-CSCF 103、GGSN 121、SGSN 122等一系列网元。另一方面，对于固定网络用户141、142，它们的下行链路数据也可能会同时经历从AS 101开始的一系列IMS核心网10中的网元。尽管发往不同用户终端的数据都要经过物理传输路径(包括IP-CAN中的物理路径，也包括IMS核心网中的物理路径)，网络却为不同的用户终端分配了独立的数据传输通路。

由此可见，在下行链路数据传输过程中，同一段物理传输路径上，各个网元可能要为参与IMS会话的用户保存相同数据的多个拷贝。特别是，如果参与通信的多个用户终端都位于同一运营商服务的同一个区域，这种点对点承载对网络资源的浪费将变得更加明显。另外，这种点对点的承载方式可能使不同的用户终端在接收相同业务数据时经历不同的网络时延，从而影响用户使用业务的体验。

以上虽然利用UMTS网络和PSTN网络作为示例说明了现有支持IMS业务的网络系统的缺点，但是本领域的技术人员可以理解，对于能够为IMS提供接入承载的其它通信网络，例如GSM、CDMA2000和WLAN等网络，同样存在类似问题。

发明内容

为了克服现有IP多媒体子系统业务的上述缺点，本发明旨在提供一种利用广播多播业务能力对IMS业务承载进行优化以便在传输IMS业务时能够运用资源共享支持IMS业务传输的机制。

本发明提供一种支持互联网协议多媒体子系统业务的方法，包括以下步骤：建立互联网协议多媒体子系统业务会话；激活广播多播业务；建立广播多播业务承载；传输互联网协议多媒体子系统业务的上行链路数据；传输互联网协议多媒体子系统业务的下行链路数据，其中，所述互联网协议多媒体子系统业务的下行链路数据通过多广播多播业务承载进行传输。

本发明提供一种互联网协议多媒体子系统网络实体，包括：互联网协议多媒体子系统网络接口装置，用于与互联网协议多媒体子系统网络的相应功能实体进行信令与数据通信，以实现互联网协议多媒体子系统网络会话业务；以及互联网协议多媒体子系统业务会话管理器，用于对互联网协议多媒体子系统业务会话进行管理，所述互联网协议多媒体子系统网络实体还包括：广播多播业务功能实体接口装置，用于与广播多播业务功能实体进行信令与数据通信，来通过广播多播业务承载互联网协议多媒体子系统业务的下行链路数据。

本发明提供一种广播多播业务功能实体，包括：移动通信网络接口装置，用于与移动通信网络的相应功能实体进行信令与数据通信，以实现广播多播业务，其中所述广播多播业务功能实体还包括：互联网协议多媒体子系统网络实体接口装置，用于与互联网协议多媒体子系统网络实体进行信令与数据通信，来将互联网协议多媒体子系统业务的下行链路数据承载在广播多播业务中进行传输。

本发明提供一种支持互联网协议多媒体子系统业务的网络系统，包括根据本发明的互联网协议多媒体子系统网络实体以及根据本发明的广播多播业务功能实体，其中，所述互联网协议多媒体子系统网络实体与所述广播多播业务功能实体直接进行信令和数据通信。

本发明提供一种支持互联网协议多媒体子系统业务的网络系统，包括：互联网协议多媒体子系统网络以及将多个用户终端接入所述互联网协议多媒体子系统网络的互联网连通接入网，其中所述互联网协议多媒体子系统网络通过所述互联网连通接入网支持的广播多播业务承载互联网协议多媒体子系统业务的下行链路数据，传输到所述多个用户终端的至少一个.

通过使用本发明，参与IMS会话的多个用户终端能够通过广播多播业务的方式获取IMS业务的下行数据，尽可能地利用了能够共享的资源，减少了IMS业务对资源的浪费。由于引入了广播多播业务能力作为点到多点的业务承载，有效地减小了不同IMS用户终端接收相同业务数据时可能经历的不同时延。而且，在根据本发明的技术方案中，这种结合可以尽可能地降低信令平面的处理时延。另外，本发明充分利用了现有网络架构和功能划分，通过对网络进行较小的改动达到了较好的技术效果。

结合附图阅读本发明实施方式的详细描述后，本发明的其它特点和优点将变得更加清楚。

附图说明

图1A示出了现有技术中一种支持IMS业务的网络系统示意图；

图1B示意性地示出了现有的IMS会话业务流程；

图2示出了根据本发明一个实施例的支持IMS业务的网络系统示意图；

图3示意性地示出了根据本发明一个实施例的IMS会话的业务流程图；

图4示意性地示出了根据本发明一个实施例的IMS会话过程的流程图；

图5示意性地示出了根据图4所示实施例的控制IMS应用服务器的工作流程图；

图6示意性地示出了根据图4所示实施例的参与IMS应用服务器的工作流程图；

图7示意性地示出了根据图4所示实施例的广播多播业务中心的处理流程图；

图8示意性地示出了根据本发明一个实施例的引入广播多播能力的IMS核心网从单播IMS会话到多播IMS会话的切换过程；

图9示出了根据本发明一个实施例的IMS应用服务器的示意性结构图；

图10示出了根据本发明一个实施例的广播多播业务功能实体的示意性结构图。

具体实施方式

以下参照附图，对本发明的实施例进行详细说明。

图1A和图1B分别示意性示出了现有技术中一种支持IMS业务的网络系统和IMS会话业务流程。在前文已有对图1A和图1B的说明，因此不再对其进行描述。

图2示出了根据本发明一个实施例的支持IMS业务的网络系统示意图。其中，以UMTS网络作为例子，相同的参考标号表示与图1相同的部分，在此省略对其的描述；并且参考标号225表示在UMTS中对已有的分组域功能实体如GGSN 121、SGSN 122、RNC 123、124和用户终端1至N等增加多媒体广播多播业务(MBMS)功能的广播多播业务中心(BM-SC)。

如图2所示，根据本发明一个实施例的支持IMS业务的网络系统，将UMTS 12中的BM-SC 225与IMS核心网10的AS 101进行连接，其中信令平面增加了Gx参考点用来交互控制信息，而用户面增加了Gy参考点用来传输用户数据，使得BM-SC 225作为AS 101提供的IMS业务在UMTS网络中的入口。然后，在UMTS 12中，通过多媒体广播多播业务作为承载，将IMS业务通过GGSN 121、SGSN 122和相应的RNC 123、124传输至参加IMS会话的用户终端1至N。

在图2所示的支持IMS业务的网络系统中，通过利用UMTS网络的MBMS业务承载了从AS 101到UMTS 12中的用户终端1至N的IMS业务。这使得参与IMS会话的支持MBMS业务的用户终端1至N能够从BM-SC 225到SGSN 122使用共同的数据通道，实现了IMS业务下行链路传输的资源共享，从而避免了对网络资源的浪费。本领域的技术人员可以理解，图2所示出的网络结构只是示例性的，并不能代表所有可能的应用实例。其中，最能够体现本发明优越性的情况是，当参与IMS会话的多个用户终端都位于同一个运营商的同一个无线网络控制器的管理区域，并且这些用户终端都支持MBMS业务时，网络资源能够最大程度地被多个用户终端共享。

需要指出的是，虽然以UMTS网络作为示例说明了本发明网络系统的一个实施例，但是本领域的技术人员可以理解，本发明并不限于UMTS网络本身，而是能够在其它支持广播多播业务的IP-CAN，例如GSM、CDMA2000、WLAN等网络中广泛的应用。例如，CDMA2000网络所支持的广播多播业务名称为广播多播业务(BCMCS，broadcastmulticast service)，广播多播业务网络实体对应为广播多播业务控制器(BCMCSC，BCMCS controller)和广播多播业务内容服务器(BCMCS-CS，BCMSC content server)。其中，BCMCSC是广播多播业务的控制中心，用于提供信令平面的功能；而BCMCS-CS则作为广播多播的业务源。虽然CDMA2000网络在网络实体设置上与控制功能、组播源功能集于BM-SC一身的UMST网络不同，但是本领域技术人员可以将本发明新增的Gx和Gy参考点连接到不同的网络实体，也即，Gx连接IMS AS和BCMCSC，而Gy连接IMS AS和BCMCS-CS，来实现本发明。

由于在现有网络中新增加了IMS应用服务器(例如，AS 101)和作为IP-CAN的广播多播业务功能实体(例如，BM-SC 225)的连接，相应的功能需要有所增强。

例如，在信令平面中：

-改变现有的由用户终端发起对某个多播广播业务激活流程的现有机制，而可以由广播多播业务功能实体发起多播广播业务激活流程，并由IMS AS控制何时发起这个过程。这是因为，所提供的通用网络结构需要满足有些IMS业务比现有的广播多播业务具有更强的即时性的需求。这也意味着，承载IMS业务的广播多播承载业务不能在IMS会话发生之前就建立好。所以，可以由AS告知本网内的广播多播业务功能实体何时发起这个过程。而广播多播业务功能实体在执行广播多播激活流程之后，要将广播多播激活流程的结果以例如响应的方式告知IMS AS。

-由IMS AS控制何时开始建立广播多播承载。与上面所述类似，可以由IMS AS告知本网内的广播多播业务功能实体何时发起广播多播承载建立流程。

-IMS AS还需要具备管理广播多播参与者列表的功能，用以管理能够使用广播多播承载该IMS业务的广播多播用户信息。这个信息可以来自与IMS AS相连接的同网络的广播多播业务功能实体。

在用户平面中：

-由IMS AS充当广播多播承载业务的数据源，广播多播业务功能实体把IMS AS当作内容供应商或是组播业务源。

对于图2所示的通过不支持广播多播业务的PSTN网络接入IMS核心网10的用户终端141和142来说，除了可以选择使用现有的点到点承载传输下行数据之外，还可以选择利用IMS核心网10用户平面的广播多播能力传输下行数据.这样使得在多播会话时，IMS核心网内的同一段物理传输路径上将只会有一个数据包的拷贝，进一步减少IMS会话在IMS核心网内消耗的网络资源.

需要进一步说明的是，实际上可以对所有用户终端(支持广播多播业务或者不支持广播多播业务)启用IMS核心网中用户面的广播多播能力，来进一步降低IMS会话业务在IMS核心网内的资源消耗。但是，如上所述的增加IMS AS和广播多播业务功能实体之间用户平面和信令平面接口的方式不但可以利用诸如MBMS的广播多播承载屏蔽IMS业务数据在IMS核心网内的发送，而且可以利用SIP/SDP的多播能力提高IMS业务数据的传输效率。因此，优选地，仅对经由不支持广播多播业务的IP-CAN接入的用户终端选择启用IMS核心网内用户面的多播能力。

此外，在图2所示的网络结构中，还可以包含到外部功能实体的接口(未示出)。在开放移动联盟(OMA)定义的系统框架中，为多种应用提供了公共的业务服务，例如，组管理服务和状态呈现服务。用户终端1至N和这些服务器可以通过现有3GPP的Ut接口连接，而IMS核心网10的AS 101可以通过现有3GPP的ISC接口连接。这两个接口分别定义在3GPP规范的23.002和23.228中。

图3示意性地示出了根据本发明一个实施例的IMS会话的业务流程图。

如图3所示，IMS会话建立过程301需要完成的功能是：IMS信令平面的建立；IMS用户列表的建立；IMS参与者列表的创建及更新。

IMS上行资源预约过程302需要完成的功能是：分配上行的专用资源。该过程是可选步骤(用虚线框示出)，因为对于工作在半双工状态的IMS用户终端而言，IMS上行资源预约过程要发生在IMS会话建立过程301之后并且在网络明确指示某个用户终端可以进行上行数据传输之后。

广播多播业务激活过程303需要完成的功能是：创建和更新广播多播参与者列表，建立广播多播业务信令平面和分布树。

广播多播承载建立过程304需要完成的功能是：建立广播多播承载，分配下行资源。

在上行链路数据传输过程305中，某个用户终端发起会话，并把数据发送到IMS AS。

在下行链路数据传输过程306中，AS把收到的上行链路数据进行汇聚(如果同时收到来源于多个用户终端的上行链路数据)，并把数据分发至所有能够参与IMS会话的接收用户终端。

通过上面对根据本发明一个实施例的IMS会话业务流程的描述，参照图1B所示的现有IMS会话业务流程，本领域的技术人员可以理解其中的差异。这种差异也从业务流程的角度说明了在IMS AS和广播多播业务功能实体中需要增强的功能性。

图4示意性地示出了根据本发明一个实施例的IMS会话过程的流程图。

在图4中，为了进一步说明在本发明中各个网络实体间进行的IMS会话过程，基于图2所示的网络结构，设想了一种更加复杂的情况。其中，包括两个类似于图2的IMS核心网10的互通的IMS核心网10A和10B；用户终端41和42通过UMTS 12A连接到IMS核心网10A，而用户终端43则通过UMTS 12B连接到IMS核心网10B；用户终端44类似于图2中的用户终端141，是通过例如PSTN连接到上述IMS核心网10B的不支持MBMS业务的用户终端。

如图4所示的情况，由用户终端41或者其服务AS 101A代表用户终端41发起向用户终端42、43和44的IMS会话。在这种情况下，当IMS会话涉及的用户终端41、42和用户终端43分别接受不同IMS核心网10A和10B的服务时，可以由发起IMS会话的用户终端41的服务AS 101A充当整个IMS会话的控制中心，以下称为控制AS 101A；而接收或参与用户终端43的服务AS 101B称为参与AS 101B。本领域技术人员可以理解，在网络实体中并不区分控制AS和参与AS，这种特定的功能性区分仅对于一次特定的IMS会话有意义。因为，IMS业务可以由任一用户终端发起，而在一次IMS会话中充当控制AS的AS在另一次IMS会话中可能会充当参与AS。

此外，在图4中还尽可能地省略了已被本领域技术人员所熟知的SIP信令的传输过程，以便简化示图。省略的传输过程例如包括：接收用户终端对发起用户终端的应答消息(接受会话、拒绝会话、错误应答等)未示出；无论是发起用户终端向接收用户终端的信令还是接收用户终端向发起用户终端的信令都是经过AS中转的，中转的信令未示出；由控制AS 101A发往参与AS 101B的SIP信令和数据应经由IMS核心网10A和IMS核心网10B中的相关网络功能实体中转，中转部分未示出。

以下具体描述如图4所示的IMS会话过程。

在步骤S401，用户终端41发起或者为其服务的控制AS 101A代表用户终端41发起向用户终端42、43和44的IMS会话；控制AS 101A存储包括用户终端42、43和44的接收用户终端列表；网络端根据基于业务的策略(SBLP)进行QoS的授权。

在步骤S402，每当控制AS 101A收到来自接收用户终端的接受会话的应答时，根据应答内容标记此接收用户终端可以或是不可以参与IMS会话，并更新IMS参与者列表。

在步骤S403中，当用户终端41通过QoS授权，并收到S402中描述的接收用户终端的应答时，会话发起的用户终端41和应答接收用户终端42、43和44按照现有IMS流程发起上行资源预约过程。需要注意的是，如果该IMS会话工作在半双工状态，则不进行步骤S403，因为上行资源的预约要在网络确认它可以发送上行数据时才进行(参照以下步骤S410和S411)。

在步骤S404中，当控制AS 101A发现用户终端42应答IMS会话用户终端41时，则告知用户终端42的服务BM-SC 225A，告知它启动向用户终端41、42的MBMS激活流程；当控制AS 101A发现用户终端43应答IMS会话用户终端41时，控制AS 101A发送指示给参与AS 101B，使它启动向用户终端43的MBMS激活流程；参与AS 101B根据控制AS 101A的指示，告知用户终端43的服务BM-SC225B发起向用户终端43的MBMS激活流程。

在步骤S405中，当BM-SC 225A或225B收到步骤S404中描述的启动向某个终端的MBMS激活流程指示时，就完成SIP信令ID向MBMS业务ID的映射，以此为标志向相应用户终端发起MBMS激活流程，并向网络注册使用MBMS承载。其中，MBMS激活流程可以使用IMS用户终端发送SIP信令的PDP上下文来传输MBMS信令。

在步骤S406中，BM-SC 225A、225B将MBMS激活流程执行的成功与否的响应，报告给对其发送指示的AS 101A、101B。

在步骤S407中，如果AS 101A或101B收到MBMS激活流程成功的响应，则该AS 101A或101B更新其中维护的MBMS用户列表。

在步骤S408中，当控制AS 101A收到来自所有接收用户终端42、43和44的会话应答时，告知BM-SC 225A可以启动MBMS承载建立流程；同时控制AS 101A发送指示给参与AS 101B，告知它可以启动MBMS承载建立流程；参与AS 101B根据控制AS 101A的指示，告知BM-SC 225B启动MBMS承载建立流程。

在步骤S409中，BM-SC 225A或者225B收到步骤S408中描述相应AS 101A或101B的指示时，BM-SC 225A或225B则发起MBMS承载建立流程，此时对下行链路资源进行分配。其中，相应的流程和现有的MBMS流程基本一致。但是本领域的技术人员可以理解，在分配网络资源时，UMTS 12A或12B中的RNC不需要发起信令过程来确定对某个MBMS业务感兴趣的用户的个数。因为在IMS业务应用模式中，所有IMS参与者都已经与网络建立了信令连接，也就是说，网络已经知道它们的存在。

在步骤S410中，当在步骤S408中控制AS 101A收到来自所有接收用户终端42、43和44的会话应答时，AS 101A通知发起该IMS会话的用户终端41可以启动上行数据传输。

在步骤S411中，在收到S410中所描述的启动上行数据传输的通知时，用户终端41发起上行资源的预约流程。

在步骤S412中，用户终端41发起上行IMS数据传输。

在步骤S413中，一旦收到上行数据，控制AS 101A查询MBMS参与者列表。

在步骤S414中，如果MBMS参与者列表为非空，控制AS 101A把在步骤S412中收到的IMS上行数据发送到BM-SC 225A。

在步骤S415中，当BM-SC 225A收到在步骤S414中描述的来自控制AS 101A的IMS服务数据时，沿MBMS分布树进行分发。

在步骤S416中，控制AS 101A将收到的上行数据转发给参与AS101B。

在步骤S417至S419中，参与AS 101B和其所在网络的BM-SC 255B实现与在步骤S413至S415中描述的控制AS 101A和其所在网络的BM-SC 225A类似的功能。

在步骤S420中，对于不支持广播多播承载的IMS参与者用户终端44，为其服务的AS 101B除了可以选择使用现有的点到点承载传输下行数据之外，还可以选择利用IMS核心网10B的广播多播承载在传输下行数据，以便进一步减少IMS会话在IMS核心网内消耗的网络资源(具体流程将在下文中说明)。

图4的示例中各步骤与图3所示的IMS会话业务流程的对应关系如下所述：步骤401至402对应于IMS会话建立过程301；步骤403对应于IMS上行资源预约过程302；步骤404至407对应于MBMS激活过程303；步骤408至409对应于MBMS业务承载建立过程304；步骤410至412对应于上行链路数据传输过程305；步骤413至420对应于下行链路数据传输过程306。

图5示意性地示出了根据图4所示实施例的控制IMS应用服务器的工作流程图。

在步骤500中，开始处理流程。

在步骤501中，IMS业务AS出于空闲等待状态。

在步骤502中，该AS接收到来自IMS会话发起用户终端的邀请(INVITE)信令。此时，该AS作为此次IMS会话的控制AS。

在步骤503中，该AS将邀请信令分发至发起用户终端请求的所有接收用户终端。

在步骤504中，该AS等待接收用户终端的应答。

如果，在步骤505中，该AS接收到的是来自一个接收用户终端的接受会话应答，例如200OK，则继续执行步骤506至512。如果，在步骤513中，该AS接收到的是来自上述接收用户终端的拒绝会话应答或者错误应答，则流程继续执行步骤514至516。

在步骤506中，该AS根据在步骤505中收到的接受会话应答，更新其中维护的IMS参与者列表。

在步骤507中，该AS通过例如UMTS等网络向发起用户终端转发收到的接受会话应答。

在步骤508中，该AS启动服务于该接收用户终端的BM-SC的MBMS激活流程。其中包括直接启动本网内的BM-SC的MBMS激活流程，以及通过参与AS启动其它BM-SC的MBMS激活流程。

在步骤509中，该AS收到来自相应BM-SC的MBMS激活响应。

在步骤510中，判断收到的MBMS激活响应是否表示MBMS业务成功激活。如果判断结果为“是”，则执行步骤511；如果为“否”，则流程进入步骤512。

在步骤511中，该AS根据收到的MBMS激活响应，更新其中维护的MBMS参加者列表。

在步骤512中，判断是否收到来自所有接收用户终端的应答。如果判断结果为“是”，则流程执进入步骤517；如果判断结果为“否”，则流程返回步骤504，继续等待应答。

在步骤514中，该AS根据从接收用户终端收到的拒绝或错误应答，更新其中维护的IMS参与者列表。

在步骤515中，该AS通过例如UMTS等网络向发起用户终端转发收到的拒绝会话或错误应答。

在步骤516中，判断是否收到来自所有接收用户终端的应答。如果判断结果为“是”，则流程执进入步骤517；如果判断结果为“否”，则流程返回步骤504，继续等待应答。

在步骤517中，该AS通知相关的BM-SC启动MBMS承载建立流程。

在步骤518中，该AS向发起IMS会话的用户终端发送启动上行数据传输通知。

在步骤519中，该AS接收来自发起IMS会话的用户终端的上行数据。

在步骤520中，该AS查询其中维护的MBMS参与者列表。

在步骤521中，该AS按照MBMS参与者列表通过相应的BM-SC，将IMS下行数据以MBMS承载业务的方式分发至需要的接收用户终端。

在步骤522中，开始进行所请求的IMS会话。

在步骤523中，处理流程结束。

图6示意性地示出了根据图4所示实施例的参与IMS应用服务器的工作流程图。

在步骤600中，开始处理流程。

在步骤601中，IMS应用服务器AS处于空闲等待状态。

在步骤602中，该AS等待SIP信令或者数据。

如果在步骤603中，该AS接收到来自控制AS的SIP信令，则该参与AS在步骤604中将该SIP信令转发至相应的接收用户终端.然后，返回步骤602，继续等待控制AS的进一步指示.

如果在步骤605中，该参与AS接收到来自控制AS的启动MBMS激活流程的指示通知，则继续执行步骤606至609。

在步骤606中，该AS通知相应的BM-SC启动MBMS激活流程。

在步骤607中，该AS接收来自相应的BM-SC的MBMS激活响应。

在步骤608中，判断收到的MBMS激活响应是否表示MBMS业务成功激活。如果判断结果为“是”，则执行步骤609；如果为“否”，则流程返回步骤602，继续等待控制AS的进一步指示。

在步骤609中，该参与AS根据收到的MBMS激活响应，更新其中维护的MBMS参与者列表。

如果在步骤610中该参与AS从控制AS接收到启动MBMS承载建立流程的通知，则在步骤611中，通知相关的BM-SC启动MBMS承载建立流程。然后，返回步骤602，继续等待控制AS的进一步指示。

如果在步骤612中，该参与AS接收到来自控制AS的IMS上行数据，则在步骤613中查询其中维护的MBMS参与者列表。

在步骤614中，该参与AS按照查询的MBMS参与者列表通过相应的BM-SC，将IMS下行数据以MBMS业务的方式分发至需要的接收用户终端。

在步骤615中，开始进行本次IMS会话。

在步骤616中，处理流程结束。

图7示意性地示出了根据图4所示实施例的广播多播业务中心的处理流程图。

在步骤700中，开始处理流程。

在步骤701中，广播多播业务中心BM-SC处于空闲等待状态。

在步骤702中，该BM-SC等待SIP信令或者数据。

如果在步骤703中该BM-SC接收到来自IMS应用服务器AS的启动MBMS激活流程的通知，则在步骤704中发起MBMS激活流程。

在步骤705中，向相应AS发送MBMS激活流程应答，以报告MBMS激活流程是否成功执行。然后，返回步骤702，继续等待相应AS的指示。

如果在步骤706中该BM-SC接收到来自AS的启动MBMS承载建立流程的通知，则在步骤707中发起MBMS承载建立流程。然后，返回步骤702，继续等待相应AS的指示。

如果在步骤708中该BM-SC接收到来自AS的IMS下行数据，则在步骤709中沿MBMS分布树分发由MBMS业务承载的IMS下行数据。

在步骤710中，开始进行本次IMS会话。

在步骤711中，处理流程结束。

图8示意性地示出了根据本发明一个实施例的引入广播多播能力的IMS核心网从单播IMS会话到多播IMS会话的切换过程。其中，参考标号81、82、83为类似于图4所示的用户终端43的、通过不支持广播多播业务的IP-CAN接入的用户终端。

如图8所示，用户终端81和82进行单播点对点IMS会话。当用户终端81想要邀请用户终端83加入会话时，用户终端81向AS 101发起请求。AS 101判断可以将单播会话切换到多播会话后，AS 101向用户终端83转发用户终端81的邀请信令，并在邀请信令中加入多播地址和对多播会话的描述.同时，AS重新邀请用户终端81和82加入要求切换的多播会话.当所有用户终端接受会话邀请并应答后，单播IMS会话成功的被切换至多播IMS会话.AS根据应答信令的内容收集多播会话的路由信息，将收到的上行链路数据多播至所有接收用户终端.于是，原本是单播的IMS会话可以因为有新的用户终端的加入而切换到多播会话以节约网络资源.

AS 101可以决定单播到多播的切换并分配多播地址。从单播IMS会话到多播IMS会话的切换可以由AS代表某个终端发起，也可以由AS 101直接发起。AS 101还可以在发起IMS会话时或代表某个终端其发起会话时，就要求建立多播IMS会话。

图9示出了根据本发明一个实施例的IMS应用服务器的示意性结构图。其中参考标号900表示IMS应用服务器AS；参考标号901表示用于与广播多播业务中心等广播多播业务功能实体进行信令与数据通信的广播多播业务功能实体接口装置；参考标号902表示用于与IMS网络的相应功能实体进行信令与数据通信的IMS网络接口装置；参考标号903表示用于对IMS会话进行管理的IMS会话管理器。

如图9所示，当IMS应用服务器AS 900通过IMS网络接口装置902接收到来自一个用户终端的IMS会话邀请信令，也即当其作为一次IMS会话的控制AS时，则通过IMS网络接口装置902将邀请信令分发至所有被请求进行IMS会话的接收用户终端，以建立初始信令平面以及QoS资源授权。IMS会话管理器903建立/更新本次IMS会话的IMS参与者列表。根据经由IMS网络接口装置902接收的来自接收用户终端的应答，IMS会话管理器903更新此次IMS会话的IMS参与者列表。IMS应用服务器AS 900通过广播多播业务功能实体接口装置901通知服务于接受本次IMS会话的接收用户终端的广播多播业务功能实体，启动广播多播激活流程。IMS会话管理器903需要根据从相应广播多播业务功能实体返回的广播多播激活响应，建立/更新本次IMS会话的广播多播参与者列表。如果上述响应表示成功执行了广播多播激活流程，则广播多播业务功能实体接口装置901通知相应广播多播业务功能实体启动广播多播承载建立流程。IMS应用服务器AS 900通过查询广播多播参与者列表，将IMS会话数据通过广播多播业务中心接口装置901发送给相应的广播多播业务功能实体，以便以广播多播业务承载该IMS服务传输到接收用户终端。

如果该次IMS会话涉及其它IMS核心网的用户终端(例如图4所示情况)，则IMS应用服务器AS 900还需要通过IMS网络接口装置902，与其它参与AS的IMS网络接口装置进行通信，转发/发送相关信令和数据，以便参与AS能够通过其自身的广播多播业务功能实体接口装置指示相应广播多播业务功能实体执行承载层的激活和建立流程，并利用广播多播承载IMS数据传输至相应的接收用户终端。参与AS只需在其IMS会话管理器中维护当前的广播多播参与者列表，来根据其中信息通过相应广播多播业务功能实体传输广播多播业务承载的IMS数据。

此外，IMS应用服务器AS 900的IMS会话管理器903还用于在IMS会话中引入IMS核心网的多播能力，以便为不支持广播多播业务的IP-CAN接入的用户终端提供多播IMS会话业务.IMS会话管理器903可以控制IMS网络接口装置902，使得在其发送的信令消息(SIP信令)中携带多播地址以及参数生存时间等多播业务参数，以便信令能够启动IMS核心网中的广播多播能力，在IMS核心网中以多播业务形式传输IMS会话数据.根据实际需要，IMS会话管理器903既可以将一次单播IMS会话切换为多播IMS会话，也可以在发起IMS会话时，直接控制IMS网络接口装置902建立IMS多播会话.

图10示出了根据本发明一个实施例的广播多播业务功能实体的示意性结构图。其中，参考标号1000表示广播多播业务功能实体；参考标号1001表示用于与IMS应用服务器进行信令与数据通信的IMS应用服务器接口装置；参考标号1002表示用于与移动通信网络的相应功能实体进行信令与数据通信的移动通信网络接口装置。

当从IMS应用服务器接口装置1001接收到来自IMS应用服务器AS的启动广播多播激活流程的通知时，广播多播业务功能实体1000就通过移动通信网络接口装置1002发起广播多播激活流程，并且通过IMS应用服务器接口装置1001向相应AS发送广播多播激活流程应答，以报告此次MBMS激活流程是否成功执行。随后，当通过IMS应用服务器接口装置1001接收到来自AS的启动广播多播承载建立流程的通知时，广播多播业务功能实体1000则通过移动通信网络接口装置1002发起广播多播承载建立流程。此后开始进行IMS会话，广播多播业务功能实体1000经由IMS应用服务器接口装置1001接收AS发送的IMS数据，并利用其自身提供的广播多播业务承载IMS业务，经由移动通信网络接口装置1002分发至IMS会话的接收用户终端。

通过参考图9和图10，示意性地描述了本发明一种实施例的IMS应用服务器和广播多播业务功能实体的结构及其工作方式。本领域的技术人员可以理解，其中描述的各个接口装置均包括控制(信令)平面的功能和用户平面的功能。这一点对于网络中的功能实体具有特别的意义，因为在各种网络的实现中，功能实体不一定由单独网络实体实现，而是有可能将其各部分功能分布在一个或者多个网络实体中。因此，各个接口装置的控制(信令)平面的功能和用户平面的功能可能会分布在单独网络实体(例如，对于UMTS的BM-SC)中，或者分别分布在不同的网络实体(例如，对于CDMA2000的BCMCSC和BCMCS-CS)中。

上述网络/功能实体中的各个装置的全部或者部分可以利用数字处理器芯片、专用集成电路、现场可编程阵列等方式实现，甚至还可以用软件程序指令的方式实现。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在所附权利要求的范围内做出各种变形或修改。

Claims (22)

1.一种支持互联网协议多媒体子系统业务的方法，包括以下步骤：

建立互联网协议多媒体子系统业务会话；

激活广播多播业务；

建立广播多播业务承载；

传输互联网协议多媒体子系统业务的上行链路数据；

传输互联网协议多媒体子系统业务的下行链路数据，

其中，所述互联网协议多媒体子系统业务的下行链路数据通过多广播多播业务承载进行传输。

2.根据权利要求1所述的方法，还包括以下步骤：

预约互联网协议多媒体子系统上行链路资源。

3.根据权利要求1所述的方法，其中所述激活广播多播业务的步骤还包括：

互联网协议多媒体子系统网络实体通知广播多播业务功能实体启动广播多播激活流程；

所述广播多播业务功能实体发起广播多播激活流程，并向所述互联网协议多媒体子系统网络实体报告所述广播多播激活流程是否成功执行；

所述互联网协议多媒体子系统网络实体更新其维护的广播多播参与者列表。

4.根据权利要求1所述的方法，其中所述建立广播多播业务承载的步骤包括：

互联网协议多媒体子系统网络实体通知广播多播业务功能实体启动广播多播业务承载建立流程；

所述广播多播业务功能实体发起广播多播承载建立流程。

5.根据权利要求1所述的方法，其中所述传输互联网协议多媒体子系统业务的下行链路数据的步骤包括：

互联网协议多媒体子系统网络实体查询广播多播参与者列表，向相应的广播多播业务功能实体发送所述互联网协议多媒体子系统业务的下行链路数据。

6.根据权利要求3至5之一所述的方法，其中所述互联网协议多媒体子系统网络实体包括控制互联网协议多媒体子系统网络实体和参与互联网协议多媒体子系统网络实体，

其中所述参与互联网协议多媒体子系统网络实体根据从所述控制互联网协议多媒体子系统网络实体接收的指示或者数据来执行每个所述步骤。

7.根据权利要求3至5之一所述的方法，其中所述互联网协议多媒体子系统网络实体为互联网协议多媒体子系统应用服务器，并且所述广播多播业务功能实体为广播多播业务中心。

8.根据权利要求3至5之一所述的方法，其中所述互联网协议多媒体子系统网络实体为互联网协议多媒体子系统应用服务器，并且所述广播多播业务功能实体分布在广播多播业务控制器和广播多播业务内容服务器中。

9.根据权利要求1所述的方法，其中所述建立互联网协议多媒体子系统业务会话的步骤或者所述传输互联网协议多媒体子系统业务的下行链路数据的步骤包括：

发起多播互联网多媒体子系统业务会话；

建立多播互联网多媒体子系统业务会话。

10.一种互联网协议多媒体子系统网络实体，包括：

互联网协议多媒体子系统网络接口装置，用于与互联网协议多媒体子系统网络的相应功能实体进行信令与数据通信，以实现互联网协议多媒体子系统网络会话业务；以及

互联网协议多媒体子系统业务会话管理器，用于对互联网协议多媒体子系统业务会话进行管理，

所述互联网协议多媒体子系统网络实体还包括：

广播多播业务功能实体接口装置，用于与广播多播业务功能实体进行信令与数据通信，来通过广播多播业务承载互联网协议多媒体子系统业务的下行链路数据。

11.根据权利要求10所述的网络实体，其中所述广播多播业务功能实体接口装置用于通知所述广播多播业务功能实体启动广播多播激活流程，通知所述广播多播业务功能实体启动广播多播业务承载建立流程，以及查询广播多播参与者列表，向相应的广播多播业务功能实体发送所述互联网协议多媒体子系统业务的下行链路数据。

12.根据权利要求11所述的网络实体，其中由所述互联网协议多媒体子系统业务会话管理器维护所述广播多播参与者列表，并根据所述广播多播业务功能实体接口装置接收的有关所述广播多播激活流程是否成功执行的报告，更新所述广播多播参与者列表。

13.根据权利要求12所述的网络实体，其中所述广播多播业务功能实体接口装置根据所述互联网协议多媒体子系统网络接口装置从另一个互联网协议多媒体子系统网络实体接收的指示或者数据来实现每个所述功能。

14.根据权利要求10所述的网络实体，其中所述互联网协议多媒体子系统业务会话管理器用于控制所述互联网协议多媒体子系统网络接口装置发起多播互联网多媒体子系统业务会话，并建立多播互联网多媒体子系统业务会话。

15.一种广播多播业务功能实体，包括：

移动通信网络接口装置，用于与移动通信网络的相应功能实体进行信令与数据通信，以实现广播多播业务，

其中所述广播多播业务功能实体还包括：

互联网协议多媒体子系统网络实体接口装置，用于与互联网协议多媒体子系统网络实体进行信令与数据通信，来将互联网协议多媒体子系统业务的下行链路数据承载在广播多播业务中进行传输。

16.根据权利要求15所述的广播多播业务功能实体，其中

当所述互联网协议多媒体子系统网络实体接口装置接收到来自所述互联网协议多媒体子系统网络实体的启动广播多播激活流程的通知时，就通过所述移动通信网络接口装置发起广播多播激活流程；

当所述互联网协议多媒体子系统网络实体接口装置接收到来自所述互联网协议多媒体子系统网络实体的启动广播多播业务承载建立流程的通知时，就通过所述移动通信网络接口装置发起广播多播业务承载建立流程。

17.根据权利要求16所述的广播多播业务功能实体，其中

通过所述互联网协议多媒体子系统网络实体接口装置向所述互联网协议多媒体子系统网络实体返回有关所述广播多播激活流程是否成功执行的报告。

18.一种支持互联网协议多媒体子系统业务的网络系统，包括如权利要求10所述的互联网协议多媒体子系统网络实体以及如权利要求15所述的广播多播业务功能实体，

其中，所述互联网协议多媒体子系统网络实体与所述广播多播业务功能实体直接进行信令和数据通信。

19.根据权利要求18所述的网络系统，其中所述互联网协议多媒体子系统网络实体为互联网协议多媒体子系统应用服务器，并且所述广播多播业务功能实体为广播多播业务中心。

20.根据权利要求18所述的网络系统，其中所述互联网协议多媒体子系统网络实体为互联网协议多媒体子系统应用服务器，并且所述广播多播业务功能实体分布在广播多播业务控制器和广播多播业务内容服务器中。

21.一种支持互联网协议多媒体子系统业务的网络系统，包括：互联网协议多媒体子系统网络以及将多个用户终端接入所述互联网协议多媒体子系统网络的互联网连通接入网，

其中所述互联网协议多媒体子系统网络通过所述互联网连通接入网支持的广播多播业务承载互联网协议多媒体子系统业务的下行链路数据，传输到所述多个用户终端的至少一个。

22.根据权利要求21所述的网络系统，其中在所述互联网协议多媒体子系统网络内部，通过多播业务支持互联网协议多媒体子系统业务会话。

Images