CN101155053B - 一种组播/广播业务实现方法和系统 - Google Patents

Abstract

本发明涉及组播/广播业务，特别涉及一种组播/广播业务实现方法和系统，用以解决现有核心网侧不支持IP组播方法时，如何以单播方式实现组播/广播业务的问题。本发明在进行组播/广播业务时，由位于接入网边界的传输处理模块和位于核心网侧的组播/广播业务的媒体提供设备之间建立单播传输通道，媒体提供设备通过所述传输通道将被请求的组播/广播媒体流单播给传输处理模块；传输处理模块再采用IP组播技术，将所述组播/广播媒体流组播/广播给终端。在核心网侧不支持IP组播方法时，实现了组播/广播业务的单播。

Description

一种组播/广播业务实现方法和系统

技术领域

本发明涉及组播/广播业务，特别涉及一种组播/广播业务实现方法和系统。

背景技术

SP(Session Initiation Protocol，会话发起协议)是由IETF(Interne工程任务组)制订的多媒体通信系统框架协议之一，是用于建立、改变或结束多媒体会话的应用层协议，与RTP(Real-time Transport Protocol，实时传输协议；)/RTCP(Real-time Transport Control Protocol，实时传输控制协议)、SDP(SessionDescription Protocol，会话描述协议)、RTSP(Real-Time Streaming Protocol，实时流协议)、DNS(Domain Name Server域名服务器)等协议配合，共同完成IMS(PMultimedia Subsystem，IP(Internet Protoeol，国际互联网协议)多媒体子系统)中的会话建立及媒体协商；一旦建立会话，媒体流将使用RTP协议在承载层中直接传送，在一次会话中可以灵活的交互多种媒体。

由于SIP基于公开的Internet标准，在语音、数据业务结合和互通方面具有天然优势，能跨越媒体和设备实现呼叫控制，支持丰富的媒体格式，可动态增/删媒体流，容易实现更加丰富的业务特性，同时，SIP支持智能向业务和终端侧发展从而减轻网络负担，其本身支持包括动态注册机制、位置管理机制、重定向机制等应用层移动性功能以及呈现Presence/Fork/订阅特性，便于扩展新业务，而且协议简单，具有公认的扩展潜力，因此获得了包括在IMS及NGN(Next Generation Network，下一代网络)中的越来越多的应用。

在通讯和IT技术高度发展的今天，随着跨链路层传输介质的IP技术的出现，互联网(Internet)应用的迅速普及，与此同时，人们也不再满足于单一的语音通信方式，而需要全新的多媒体通信方式，移动通讯网络和固定通讯网络的IP化、Internet和电信网络的融合已无可争议地成为业界公认的发展方向。为满足越来越突出的IP多媒体应用的普遍需求，3GPP(3rd GenerationPartnership Project，第三代移动通信标准化伙伴项目)在分组承载网基础上引入的全IP业务网络架构的IP多媒体子系统IMS，目标是按照个性化用户数据，屏蔽用户接入方式，控制业务能力的开放程度，提供多媒体的通信体验。

IMS是3GPP R5阶段增加的WCDMA网络中叠加在已有分组域之上的一个子系统，采用分组域为其上层控制信令和媒体传输的承载通道，引入SIP协议作为业务控制协议，利用SIP简单、易扩展、媒体组合方便的特点，通过将业务控制与承载控制分离，提供丰富的多媒体业务；IMS中主要的功能实体包括控制用户注册、会话控制等功能的呼叫控制实体CSCF(Call Session ControlFunction，呼叫会话控制功能)、提供各种业务逻辑控制功能的应用服务器AS、集中管理用户签约数据的HSS(Home Subscriber Server，归属用户服务器)以及用于实现与电路交换网互通的MGCF(Media Gateway Control Function，媒体网关控制功能)/IM-MGW(Instant messaging Media Gateway，即时消息媒体网关)，用户通过当前所在地代理节点P-CSCF(Proxy-CSCF，代理CSCF)接入IMS，会话和业务触发控制及与AS(Application Server，应用服务器)的业务控制交互则由其注册地的归属域服务节点S-CSCF(Subscriber-CSCF，归属CSCF)完成。

NGN(下一代网络)是基于分组技术的融合型网络，以分组交换为主，采用承载与控制分离的架构，它继承了原有PSTN(Public Switch TelephoneNetwork，公共交换电话网)固定网络的所有业务，也同时够继承了移动网络的业务能力。NGN综合了固定电话网、移动电话网和IP网络的优势，使得模拟用户、数字用户、移动用户、ADSL(Asymmetrical Digital Subscriber Loop非对称数字用户环线)用户、ISDN(Integrated Services Digital Network，综合业务数字网)用户、IP窄带网络用户、IP宽带网络用户甚至是通过卫星接入的用户都能作为下一代网络中的一员相互通信。

NGN整体架构中包括NASS(Network Attachment Sub-system，网络附着子系统)和RACS(Resource and Admission Control Subsystem，资源及许可控制子系统)，NASS是网络附着子系统，其主要用于对用户设备进行动态配置，进行用户接入验证，进行接入资源授权，进行接入网配配置和用户位置管理等。

如图1所示，RACS的功能架构包括：

CPE(Customer Premises Equipment(i.e.(routed)modem，residential gateway，integrated access device，用户前端设备)，CPE是用户前端设备，提供将用户终端(如PC)接入网络的能力；

A-RACF(Access-Resource and Admission Control Function，接入-资源及许可控制功能)，A-RACF接受SPDF的请求，对用户的请求进行接纳控制，另外，A-RACF也需要对来自于SPDF的策略输入进行整合以保证所有资源请求不会超出接入线能力范围；

RCEF(Resource Control Enforcement Function，资源控制执行功能)，RCEF在A-RACF的控制下执行策略强制功能，如执行接入提供商的定制策略，对授权流量进行门控等；

SPDF(Service-based Policy Decision Function，基于业务的策略决策功能)，SPDF接受AF的资源请求，根据网路运营商策略对该请求进行处理，并按需向A-RACF和/或BGF发送进一步的资源请求，资源请求的结果返回给AF；

BGF(Border Gateway Function，边界网关功能)，BGF是一个分组到分组的网关，它在SPDF的控制下执行策略并进行必要的网络地址转换功能；

L2T Point是二层协议的终结点；

Access Node一般指二层/三层接入局端设备，提供多用户线路接入，并对用户流量进行汇聚的功能，如xDSL接入技术中的DSLAM。

流媒体业务或IPTV业务是近几年迅速发展的一种新业务，流媒体业务利用流式传输技术，在包交换网络上传输多媒体文件，包括视频、音频等文件内容。这些内容在访问时无需完全下载就可以立即播放。流媒体实现的关键技术就是流式传输技术，而流式传输技术是把连续的视频和音频信息经过处理后放上网站服务器，让用户一边下载一边观看、收听，而不需要等整个文件下载到自己机器后才可以观看的网络传输技术。

以D类IP地址发送业务的技术，用于发送者同时向多个接收者(大于等于一个)发送相同业务内容时，因为相同内容只需要向指定组播地址发送一份即可，因而可以有效降低业务发送方和传输网络的负载。

为了获取组播内容，内容接收方(用户)通过加入业务组播组(如使用IGMP(Internet Group Management Protocol因特网组管理协议)协议)来要求邻接的路由器发送业务内容给自己，而路由器之间则通过组播路由协议(如PIM-SM(Protocol Independent Multicast-Sparse Mode协议无关组播-稀疏模式(协议))(协议无关组播-稀疏模式)协议等)与其它路由器交互以建立组播转发路径，这样组播业务内容就可以从组播源沿组播转发路径传递给内容接收方。

使用组播技术传送业务流，无论接收方有多少，业务发送方只需要发送一个数据流。组播数据在从业务发送点到接收方的传送路径上的传送点之间只产生单一的数据流，显而易见使用组播技术可以减轻发送者(业务提供方)的负荷，并且可以有效利用网络资源。

应用层组播通过在节点之间运行承载在单播技术上的协议进行一点到多点/多点到多点的数据发送，由于不依赖于IP组播技术，因此可以间接避开/解决IP组播的所谓信源可信，可靠组成员管理，组播数据安全等问题。

应用层组播的应用意味着终端和服务器可以作为节点建立关联关系，从而不需要对网络中间实体提出附加的需求；但此类方案却对终端提出了附加的需求，即需要特定的应用层组播协议以维护节点关系，这对于通信网络来讲未必是最佳选择。

现有技术一

在现有基于IP网络的业务系统中，若需要向多个用户传递相同内容，则一般会考虑使用IP组播技术向用户传递内容。如图2所示，为使用IP组播技术开展业务的一个示意，其过程为：

1、UE(User Equipment，用户设备)通过业务接口，如HTTP(Hyper TextTransport Protocol，超级文本传送协议)等，获得业务组播地址；UE使用IGMP通知路由器加入该组播组；

2、传输/核心网路由器之间通过三层组播路由协议(如PIM-SM等)建立组播转发表；

3、业务流以组播报文方式从组播源发送给UE。

以上方案是一个标准的组播应用流程，要求接入网和传输/核心网均支持组播功能，在UE和路由器之间使用IGMP协议，在路由器之间则使用组播路由协议，如PIM-SM等。

上述方案中由于媒体服务器对用户是否正在接收内容没有机制感知，其在商业运营中遇到一定的困难：即无法对用户进行验证和进行准确的计费。另外，IP组播也存在其固有缺陷，包括：无法进行组成员管理验证，无法保障媒体源可信，无法限制媒体流分发范围等问题。目前有一种机制是通过在接入设备上配置对应于用户线路的组播权限表对用户的IGMP/MLD(Internet GroupManagement Protocol，因特网组管理协议/Multicast Listener Discovery，组播侦听者发现(协议))请求进行过滤来间接解决类似问题。另外，对于现有技术一，如果核心传输网不支持IP组播技术，则无法在核心网络侧以IP组播技术发送媒体流，其应用受到一定的限制。

现有技术二

针对现有技术一的缺点，同时也是针对IP组播技术的固有缺点，目前出现了应用层组播技术。

应用层组播技术通过在节点之间运行承载在单播技术上的协议进行一点到多点/多点到多点的数据发送，由于不依赖于IP组播技术，因此可以间接避开/解决IP组播的所谓信源可信，可靠组成员管理，组播数据安全等问题。

应用层组播目前的一类应用是以终端和服务器作为功能节点在其间建立动态的关联或者链路关系，在发送数据时以服务器和多个节点所建立的传输关系以单播方式发送媒体流数据，但数据在该逻辑网络中的分发可能是分层复制的，因而也可以取得和IP组播类似的传输资源优化效果。

此类方案可以不需要对网络中间实体提出附加的需求；但一般却对终端提出了附加的需求，即需要特定的应用层组播协议以维护节点关系，这对于通信网络来讲未必是最佳选择。

发明内容

本发明提供一种组播/广播业务的实现方法和系统，用以解决现有核心网侧不支持IP组播方法时，如何以单播方式实现组播/广播业务的问题。

为解决上述技术问题，本发明提供如下技术方案：

一种组播/广播业务实现方法，包括如下步骤：

终端通过中间处理模块向应用处理模块请求建立所述组播/广播业务；

所述应用处理模块向媒体提供设备请求媒体资源，并接收所述媒体提供设备返回的建立所述传输通道的相关参数和组播/广播媒体流参数；

所述应用处理模块向中间处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的业务响应；

所述中间处理模块向传输处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的资源请求；

所述传输处理模块判断所述组播/广播业务的传输通道是否已经建立，如果是，则根据所述组播/广播媒体流参数，组播/广播从该传输通道上接收到的组播/广播媒体流；否则，根据所述相关参数与媒体提供设备之间建立所述传输通道，并根据所述组播/广播媒体流参数组，播/广播从该传输通道上接收到的组播/广播媒体流，其中所述相关参数包括：应用层组播类型和应用层组播通道描述参数。

所述方法中，至少两个组播/广播业务复用同一条传输通道；或者

为每一个组播/广播业务分别建立一条传输通道。

上述方法进一步包括如下步骤：

所述应用处理模块向终端返回所述组播/广播业务的组播地址；

所述终端根据所述组播地址加入接收所述组播/广播媒体流的组播组。

上述方法进一步包括如下步骤：

所述传输处理模块建立所述传输通道后或确认所述传输通道已经建立后，向所述中间处理模块返回资源请求响应；所述中间处理模块向所述终端返回携带所述组播/广播媒体流参数的业务成功响应；所述终端收到所述业务成功响应后，根据所述组播/广播媒体流参数加入接收所述组播/广播媒体流的组播组。

上述方法进一步还包括：所述应用处理模块为每一个组播/广播业务分配一个唯一的业务流标识，并且：

所述应用处理模块在发送给所述中间处理模块的业务响应中携带对应的业务流标识；所述中间处理模块在发送给所述传输处理模块的资源请求中携带所述业务流标识，所述传输处理模块记录所述业务流标识并根据记录信息判断是否已经为相应的组播/广播媒体流建立了传输通道。

如果分配了业务流标识，所述方法进一步还包括：

所述中间处理模块在发送给所述终端的业务响应中携带所述业务流标识，所述终端利用所述业务流标识在后续流程的业务层信令中标识或匹配所述组播/广播业务。

上述所有方法中，所述终端和中间处理模块之间通过SIP协议、HTTP协议或RTSP协议实现信息交互；所述中间处理模块和应用处理模块之间通过SIP协议、HTTP协议或RTSP协议实现信息交互；所述中间处理模块和传输处理模块之间通过COPS协议、H.248协议或Diameter协议实现信息交互。并且通过扩展会话描述协议SDP携带建立所述传输通道的相关参数、组播/广播媒体流参数或业务流标识。

上述方法中，所述传输通道的类型包括封装模式。其中，所述封装模式的传输通道包括隧道，建立所述隧道的相关参数至少包括：隧道类型、媒体传输设备端的隧道地址和隧道端口。所述隧道可以是GRE隧道。

或者，所述传输通道的类型包括映射模式，建立所述映射模式传输通道的相关参数至少包括：映射模式类型、媒体传输设备端的单播地址和端口。

上述方法中，所述组播/广播媒体流参数至少包括IP组播/广播地址和端口。

进一步，所述传输处理模块建立用户配置表，以用户标识为索引保存每一个用户对应的组播/广播媒体流参数，并根据该用户配置表验证请求所述组播/广播媒体流的用户终端的合法性。

本发明还提供一种组播/广播业务实现系统，包括终端和位于核心网侧的媒体提供设备，还包括：位于接入网侧的传输处理模块，应用处理模块和中间处理模块，其中，所述传输处理模块分别通过IP网络连接终端和媒体提供设备，所述应用处理模块通过接口连接中间处理模块，所述中间处理模块分别通过接口连接所述终端、传输处理模块和媒体提供设备；

终端通过中间处理模块向应用处理模块请求建立所述组播/广播业务；

所述应用处理模块向媒体提供设备请求媒体资源，并接收所述媒体提供设备返回的建立所述传输通道的相关参数和组播/广播媒体流参数，其中所述相关参数包括：应用层组播类型和应用层组播通道描述参数；

所述应用处理模块向中间处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的业务响应；

所述中间处理模块向传输处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的资源请求；

所述传输处理模块判断所述组播/广播业务的传输通道是否已经建立，如果是，则根据所述组播/广播媒体流参数，组播/广播从该传输通道上接收到的组播/广播媒体流，否则，根据所述相关参数与媒体提供设备之间建立所述传输通道。

较佳的，所述中间处理模块包括下一代网络NGN中的应用功能实体AF；所述传输处理模块具体包括NGN中的如下子功能实体：基于业务的策略决策功能实体SPDF、接入-资源及许可控制功能实体A-RACF、资源控制执行功能实体RCEF和边界网关功能实体BGF，其中：所述SPDF通过接口连接所述中间处理实体，所述A-RACF连接在SPDF和RCEF之间，所述BGF分别连接SPDF和RCEF，所述RCEF通过IP网络连接终端，所述BGF通过IP网络连接媒体提供设备。

较佳的，所述应用处理模块包括IP多媒体子系统MS中的应用服务器AS；所述中间处理模块包括IMS中的代理-呼叫会话控制功能P-CSCF及服务-呼叫会话控制功能S-CSCF。所述边界网关功能实体BGF为如下之一：支持MBMS的GPRS网络中的GGSN；3GPP2所定义的BCMCS网络中的BSN；DVB-H网络中的IPE。

较佳的，所述传输处理模块中包括存储子模块，用于存储用户配置表，该用户配置表中以用户标识为索引保存每一个用户对应的组播/广播媒体流参数，所述传输处理模块根据该用户配置表验证请求所述组播/广播媒体流的用户终端的合法性。

本发明有益效果如下：

本发明技术方案利用建立业务的信令过程，在接入网边界实体和核心网络中媒体提供设备之间建立应用层传输通道，媒体提供设备通过传输通道将组播/广播业务流单播到接入网边界实体，然后接入网边界实体再利用IP组播技术将业务流组播/广播与其连接的终端，解决了核心网不支持组播情况下进行组播/广播业务流单播传送的问题，节省了核心网和接入网之间的传输资源；

本发明技术方案还可以保证媒体提供设备接收的组播/广播媒体流的可信性和组播/广播数据的安全性，并利用用户配置表实现对接收组播/广播业务终端的合法性进行验证；另外，为建设可管理，可运营的电信级组播网络给出了有力的技术支持。

附图说明

图1为RACS功能架构示意图；

图2为现有IP组播技术实现组播业务的原理示意图；

图3为本发明所述组播/广播业务实现系统主要结构示意图；

图4为本发明所述组播/广播业务实现方法的主要流程示意图；

图5为本发明实施例一所述组播业务实现系统主要结构示意图；

图6为本发明实施例一所述组播业务实现方法的主要流程示意图；

图7为本发明实施例二所述组播业务实现系统主要结构示意图。

具体实施方式

本发明为解决现有技术存在的问题，提出以下技术构思：

在进行组播/广播业务时，由位于接入网边界的传输处理模块和位于核心网侧的组播/广播业务的媒体提供设备之间建立单播传输通道，媒体提供设备通过所述传输通道将被请求的组播/广播媒体流单播给传输处理模块；传输处理模块再采用IP组播技术，将所述组播/广播媒体流组播/广播给终端。

如图3所示，图3为本发明所述实现组播/广播业务的系统主要结构示意图，其中包括如下实体功能：

中间处理模块，为接入通信核心网的用户提供呼叫控制、路由接续等功能，可以将呼叫路由到被叫用户终端，也可以将呼叫路由到应用处理模块；

应用处理模块，用于处理用户请求，在这里进行业务逻辑处理；

媒体提供设备，位于核心网侧，可以接受应用处理模块的请求或者控制为终端传送指定的媒体文件或者媒体流，应用处理模块对媒体提供设备的请求可以经中间处理模块传递给媒体提供设备；

传输处理模块，位于接入网边界，可以接受中间处理模块的请求对业务流的传输进行控制，也可以接受中间处理模块的指示与媒体提供设备建立联系获取特定的媒体流。

终端可以向应用处理模块请求特定的组播/广播业务，如IPTV业务；

各功能实体之间通过如下接口实现通信连接：

E1：为终端和中间处理模块的接口；终端通过此接口向应用处理模块请求业务，其请求须经过中间处理模块的处理到达应用处理模块；E1接口协议可以是SIP，HTTP，RTSP等；

E2：为中间处理模块和应用处理模块的接口；中间处理模块通过此接口进行终端和应用处理模块之间信令的转接；E2接口协议可以是SIP，HTTP，RTSP等；

E3：为中间处理模块和媒体提供设备之间的接口；中间处理模块通过此接口转接应用处理模块向媒体提供设备的媒体资源请求；E3接口协议可以是SIP，Diameter，H.248等；

E4：为中间处理模块和传输处理模块的接口；中间处理模块可以通过此接口请求传输处理模块进行传输通道控制，指示传输控制模块从媒体提供设备获得特定的媒体流等；E4接口协议可以是COPS(Common Open Policy Service通用开放策略服务(协议)，用于在策略服务器和客户端设备之间交换策略信息的查询协议)，H.248，Diameter等。

终端和传输处理模块之间、传输处理模块和媒体提供设备之间分别通过IP网络连接。

实现本发明上述技术构思时，通过终端和应用处理模块之间的信令协商建立单播组播/广播业务的传输通道，传输通道为建立在媒体提供设备和传输处理模块之间的应用层组播。在协商过程中，应用处理模块在相关信令中携带用于建立传输通道所需的相关参数，相关参数实际就是对所使用的应用层组播方式的描述，可以是封装模式和映射模式。

封装模式是指媒体提供设备向传输处理模块发送的组播/广播媒体流是将原始的IP组播/广播媒体流当作某种传送协议的负载进行发送的机制，如可以使用GRE(Generic Routing Encapsulation通用路由封装)隧道，或者IPSec所定义的隧道机制等进行组播/广播媒体流的封装和发送。

映射模式是指媒体提供设备对媒体流以某种传输机制对原始媒体流进行传输，对其不再进行其它封装；在此媒体流中选取其报文特征用于接收对端识别特定的组播/广播媒体流，如可以选择媒体报文的源地址和源端口作为其识别特征；当媒体流到达传输的对端时(这里是传输处理模块)，由对端根据预先协商(或者配置)的结果从此媒体流中提取特定组播/广播流对应的媒体流的机制。

当协商过程的信令经过中间处理模块路由、呼叫控制时，由中间处理模块根据这些信息请求传输处理模块建立到媒体提供设备的媒体传输通道；由于传输处理模块和媒体提供设备之间使用应用层组播技术进行媒体传输，因而可以解决核心网不支持IP组播的问题；另外，即使核心网支持IP组播，因为基于应用层组播技术的应用处理模块或者媒体提供设备可以对传输处理模块的应用层组播传输通道建立请求进行验证，从而可以避免组播流向非法实体发送。

如图4所示，以组播业务为例，说明本发明所述组播/广播业务的主要实现流程，具体包括如下步骤：

S101、终端发出组播业务请求，该组播业务请求经中间处理模块路由到应用处理模块；

S102、应用处理模块向媒体提供设备请求该组播业务的媒体资源；

应用处理模块向媒体提供设备请求组播业务的媒体资源，媒体提供设备相应的向应用处理模块响应处理结果，这里媒体提供设备可以向应用处理模块返回如下信息：<应用层组播类型，应用层组播通道描述参数>；其中<应用层组播类型>可以是封装模式或者映射模式；其中<应用层组播通道描述参数>对于封装模式可能使用隧道技术，则可能包括<隧道类型，隧道本端地址，隧道本端端口>等，但不限于此；对于映射模式可以使用传输层参数进行标识，如<本端单播地址，本端端口>等，也可以增加其它扩展参数用于描述，不限于此。另外，还需要给出相关组播媒体流参数，包括如<组播地址，组播端口>等信息；

应用处理模块还可以为每一个组播业务的媒体流分配一个唯一对应的业务流标识，该业务流标识用于对组播媒体流进行唯一标识，后续相关信令中同时携带该业务流标识。

S103、应用处理模块通过中间处理模块向终端发送业务响应消息，该响应消息中携带<业务流标识，组播媒体流参数，应用层组播类型，应用层组播通道描述参数>等，该业务响应消息在到达终端之前需要经过中间处理模块的处理；

S104、中间处理模块根据来自应用处理模块的业务响应消息中的信息，向传输处理模块进行资源请求，该资源请求中携带<业务流标识，组播媒体流参数，应用层组播类型，应用层组播通道描述参数>等；

S105、传输处理模块根据中间处理模块所传递的应用层组播类型和应用层组播通道描述参数等建立和媒体提供设备的传输通道，该传输通道用于后续媒体流的单播发送；

多个组播业务可以复用同一条传输通道，传输处理模块通过其中携带的组播业务流参数和/或业务流标识区分不同业务，也可以为每一个业务分别建立一条传输通道。

这里，传输通道的建立可以是封装模式或者映射模式，若两种模式下传输处理模块都可以主动向应用处理模块进行传输通道建立请求，则这里直接建立就可以了。若某种模式下需要应用处理模块预先知道发送对端的地址信息，即传输处理模块的地址信息，则在步骤S101中或者在终端和应用处理模块协商的中间过程中，中间处理模块需要在经过其处理的协商信令中增加传输处理模块的地址信息，该地址信息可以是传输处理模块的地址或端口信息，也可以包括其它附加信息；该信息不需要终端理解，只需要增加在传递给应用处理模块的信令中即可。

业务流标识可以用于后续请求的优化处理，即当后续有其它用户终端请求同一个组播业务媒体流时，传输处理模块可以通过匹配该业务流标识进行识别，从而不需要再重新建立传输通道。

传输处理模块需要保存业务流标识(如果存在)以及组播媒体流参数，如果存在业务流标识，则以此标识进行后续请求的优化处理，即如果标识相同，则传输处理模块不需要再建立传输通道；若业务流标识不存在，则使用组播媒体流参数进行后续请求的优化处理。

另外，传输处理模块中可以设置存储子模块，用于存储用户配置表，用户配置表用来以用户标识(如以用户IP为标识)为索引保存各用户的组播媒体流参数，可以用于检查用户组播权限等，防止非法用户加入IP组播组。

对于映射模式而言，传输处理实体从传输通道中识别出特定映射标识的媒体流之后，可以采用此组播媒体流参数对该媒体流按IP组播方式重新打包，则仍然可以在从传输模块到终端的传输路径上使用IP组播技术进行媒体流传送。

S106、传输处理模块向中间处理模块发送响应结果，如果成功建立传输通道，则响应结果为成功响应，否则响应结果为失败响应；

响应结果中可以携带业务流标识用于请求匹配。

S107、中间处理模块收到成功响应后，向终端发送业务响应，其中携带<业务流标识，组播媒体流参数>等；

这里，中间处理模块在发送给终端的业务响应中没有发送业务层组播描述信息，因为这个信息是在网络侧所使用的，并不需要传递到终端。

终端使用现有的IP组播机制，使用组播媒体流参数加入组播组；业务流标识可以用于在后续流程中的业务层信令中，标识本次请求的组播业务。

S108、终端在收到业务响应后，可能和应用处理模块进行进一步的媒体协商直至协商结束。

在协商成功后，媒体流通过传输通道从媒体提供设备单播到传输处理模块，传输处理模块根据使用的应用层组播模式作相应的处理：

1、在封装模式下从封装报文中提取出IP组播报文，对该组播报文传输处理模块可以不加修改的向下游实体转发，如可以直接发送给终端；

2、在映射模式下根据映射参数，如可以根据报文的目的地址和端口，根据映射关系表，此映射表可以包含<IP目的地址(单播)，目的端口>到<IP组播地址，组播目的端口>的对照关系，传输处理模块收到特定媒体流时，可以把该媒体报文的地址修改为组播媒体流参数所给出的IP组播地址和端口等，然后继续向下游实体转发。

当然，传输处理模块也可以对从上面两种模式提取出的媒体流进行其它处理。

这里需要说明的是，中间处理模块向传输处理模块进行资源请求的时机根据业务请求过程的不同可能有所变化；如：只有当中间处理模块确认终端和应用处理模块的业务请求成功时才开始进行资源请求；终端和业务处理模块之间的业务协商可能需要多次才能完成，这时资源请求过程可能发生在协商的中间阶段，但应在双方完全结束协商之前。因此，上述业务流程中的步骤顺序只是为了说明发明思路，其在具体实施时存在多种可能的合理变化。

图4所示流程中，在终端请求建立组播业务的过程中，传递建立传输通道的相关参数，实际上，这些相关参数可以预先分别配置到传输处理模块和媒体提供设备上，根据组播业务的特性，传输处理模块和媒体提供设备之间随时保持所述传输通道单播组播媒体流，应用处理模块在收到终端的业务请求时，将相应的IP组播地址发送给终端，终端根据IP组播地址申请加入到组播组中，接收传输处理模块发送的组播媒体流。

下面进一步以具体实施例并结合附图详细说明本发明技术方案。

实施一、

如图5所示，传输处理模块可以实例化为TISPAN NGN中RACS，其中，终端、应用处理模块、中间处理模块、媒体提供设备以及接口E1、E2、E3、E4等的功能前文中给出，这里不再重复描述。SPDF，A-RACF，RCEF，BGF等属于RACS的定义，与相关标准(ETSI ES 282003TISPAN RACS)保持一致，具体功能在后续流程中一并给出。

另外，中间处理模块包含或实现了RACS标准中所定义的AF(ApplicationFunction，应用功能)功能。

如图6所示，基于图5所示系统结构，实现组播业务包括如下步骤：

S201、终端发出组播业务请求，该请求经中间处理模块路由到应用处理模块；

S202、应用处理模块向媒体提供设备请求媒体资源，媒体提供设备相应的向应用处理模块响应处理结果，这里媒体提供设备可以向应用处理模块返回如下信息：<应用层组播类型，应用层组播通道描述参数>；其中<应用层组播类型>可以是封装模式或者映射模式；其中<应用层组播通道描述参数>对于封装模式可能使用隧道技术，则可能包括<隧道类型，隧道本端地址，隧道本端端口>等，但不限于此；对于映射模式可以使用传输层参数进行标识，如<本端单播地址，本端端口>等，前述本端都是指媒体传输设备端，相关参数中也可以增加其它扩展参数用于描述，不限于此。

另外，还需要给出相关组播媒体流参数，包括如<组播地址，组播端口>等信息；对于媒体提供设备而言，其发送媒体流时根据应用层组播模式的不同作如下不同处理：

1、在封装模式下，媒体提供设备向传输处理模块发送的组播数据流是将原始的IP组播数据流当作某种传送协议的负载进行发送，如可以使用GRE隧道，或者IPSec所定义的IPinIP机制进行组播媒体数据的封装和发送。

2、在映射模式下，媒体提供设备对媒体流以某种传输机制对原始媒体流进行传输，对其不再进行其它封装；当媒体流到达传输的对端时(这里是传输处理模块)由对端根据预先协商(或者配置)的结果(例如映射关系表)从此媒体流中提取特定组播流对应的媒体流，如可以使用RTP传送方式，传输对端可以通过RTP流的IP地址和端口对媒体流加以区分。

同样，应用处理模块还可以为每一个组播业务的媒体流在分配一个唯一对应的业务流标识，该业务流标识用于对组播媒体流进行唯一标识，后续流程中同时携带该业务流标识，关于该业务流标识参见实施例一，后续不再重复描述。

S203、应用处理模块通过包含AF功能的中间处理模块向终端发送业务响应消息，该响应消息中携带<业务流标识，组播媒体流参数，应用层组播类型，应用层组播通道描述参数>等，该业务响应消息在到达终端之前需要经过中间处理模块的处理；

S204、AF根据应用处理模块响应消息中的信息向RACS进行资源请求，这里AF向SPDF发送的请求携带<业务流标识，组播媒体流参数，应用层组播类型，应用层组播通道描述参数>等；

S205、这里，与SPDF连接的BGF可能有多个，SPDF可以根据多种条件进行BGF的选择，如BGF负载，BGF能力等；选定BGF后，SPDF保存请求中携带的业务流标识和当前选择的BGF；后续需要将相关请求发送到同一个BGF，否则如果选了不同的BGF，则每一个BGF都要和媒体提供设备建立传输通道。

S206、SPDF根据请求信息向BGF进一步进行资源请求，该请求中携带<业务流标识，组播媒体流参数，应用层组播类型，应用层组播通道描述参数，用户线路标识和/或用户IP>等；其中：用户线路标识(该用户线路标识可以用于用户传输面的控制)可以从A-RACF获得，而A-RACF的线路标识信息则可能来自于NASS；

S207、BGF在收到上述请求后，根据应用层组播通道参数(例如：隧道描述参数)与媒体提供设备建立传输通道，该传输通道用于后续媒体流的发送。

应用层组播通道参数就是媒体提供设备在步骤S202中反馈给应用处理模块的信息。

传输通道的建立可以是封装模式或者映射模式，若两种模式下BGF都可以主动向应用处理模块进行传输通道建立请求，则这里直接建立就可以了。若某种模式下需要应用处理模块预先知道发送对端的地址信息(这里是BGF)，则在步骤S201中或者在终端和应用处理模块协商的中间过程中，中间处理模块需要在两者的协商信令经过其处理时在其中增加BGF的地址信息，该信息可以是BGF的地址和端口信息，也可以包括其它附加信息；该信息不需要终端理解，只需要增加在传递给应用处理模块的信令中即可。

在这里对于封装模式，若使用隧道机制，则可以是GRE或者IPSec所定义的IPinIP；对于映射模式，则可能仅根据IP和端口对媒体流加以区分。

同样，BGF上可以保存用户配置表，用于用户组播权限的检查等；对于映射模式而言，在从传输通道中识别出特定的媒体流之后，BGF可以采用此组播媒体流参数对该媒体流按IP组播方式重新打包，则仍然可以在从BGF到终端的传输路径上使用IP组播技术进行媒体流传送。

S208、BGF保存<业务流标识，组播媒体流参数，用户线路标识和/或用户IP>等；

这里用户线路标识和/或用户IP将用于处理后续请求时进行匹配，即当AF收到具有相同业务流标识的请求时，它只需要记录用户线路标识和/或用户IP并将其与业务流标识关联即可；用户线路标识和/或用户IP和组播媒体流参数则可以用于对组管理请求的权限验证处理，和上面的验证不同，这里指是否允许用户加入对应的组播组以接收媒体流，验证失败则拒绝发送组播媒体流给用户，验证通过则允许用户加入对应的组播组以接收媒体流。

S209、BGF向SPDF发送资源请求响应，指出处理结果；其响应中可以携带业务流标识用于请求匹配；

S2010、SPDF向中间处理模块中的AF发送资源请求响应，指出处理结果；其响应中可以携带业务流标识用于请求匹配；

S2011、AF收到成功响应后，向终端发送业务响应，其中携带<业务流标识，组播媒体流参数>等；这里AF在发送给终端的响应中没有发送它收到的应用层组播参数，因为这个信息是在网络侧所使用的，并不需要传递到终端；

S2012、终端在收到业务响应后，可能和应用处理模块进行进一步的媒体协商直至协商结束。在协商成功后，媒体流从媒体提供设备传递到BGF，传输处理模块根据使用的应用层组播模式作相应的处理：

1、在封装模式下从封装报文中提取出IP组播报文，对该组播报文传输处理模块可以不加修改的向下游实体转发，如可以直接发送给终端；

2、在映射模式下根据映射参数，如可以根据报文的目的地址和端口，把特定媒体流区分出来，对该媒体流可以把该媒体报文的地址修改为组播媒体流参数所给出的IP组播地址和端口等，可以将修改的结果继续向下游实体转发。

当然，传输处理模块也可以对从上面两种模式提取出的媒体流进行其它处理。

这里需要说明的是，中间处理模块中的AF向RACS进行资源请求的时机根据业务请求过程的不同可能有所变化；如只有当AF确认终端和应用处理模块的业务请求成功时才开始进行资源请求，对于需要多次信令交互才能完成终端和业务处理模块协商的应用，这时资源请求过程可能发生在协商的中间阶段，但应在双方完全结束协商之前。因此，上述业务流程中的步骤顺序只是为了说明发明思路，其在具体实施时存在多种合理/可能的变化。

另外，如果考虑在RCEF上进行组管理请求(IGMP或者MLD等)的控制，则SPDF在确定了BGF之后，也可以通过A-RACF向RCEF下发用于对组管理请求进行策略检查的BGF的地址；当RCEF收到终端的IGMP或者MLD请求时，它可以向BGF请求进行组管理验证，其接口可以使用Diameter等，但不限于此。

组管理具体指IP组播成员管理，IGMP/MLD分别是对应用IPv4/IPv6的组成员管理协议，一般用于终端和路由器之间，终端向路由器进行成员报告/加入/离开组播组，路由器据此判断是否向用户发送组播流；可以在路由器上进行IGMP/MLD权限判断，也就是承载层组播控制。

当然，SPDF也可以通过A-RACF向RCEF传递<(用户线路标识)和/或(用户IP)，媒体组播地址>的关联信息，则RCEF可以直接根据这些信息对用户的组管理请求进行匹配以防止非法内容请求。

当完成上述过程后，媒体提供设备可以对用户所请求的频道/媒体内容进行IP组播方式的封装，然后再将其通过隧道传送到BGF处；BGF从隧道中取出IP组播数据后就可以向网络的下游节点发送了。到这里，对于核心网不支持IP组播或者支持IP组播但希望使用应用层组播技术(这里是隧道传输)的问题已经解决；BGF向下游节点以何种方式发送也可以有多种方式，这里为了阐述的完整性予以说明。

根据接入网支持的组播技术，可以有以下应用场景：

1、支持MBMS(Multimedia Broadcast Multicast Service，多媒体广播组播业务)

当本发明上述技术方案应用于支持MBMS的GPRS(General Packet RadioService，通用分组无线业务)网络时，可以认为GGSN(Gateway GPRS SupportNode，网关GPRS支持节点)是RCEF和BGF合一的结果，或者说不存在RCEF实体；这样，根据前述方案，可以在媒体提供设备和GGSN之间建立应用层组播媒体传输通道，媒体内容以应用层组播方式下发到GGSN，GGSN对媒体内容作处理后向下游下发；在GGSN处下发的数据采用MBMS组播技术。

在MBMS网络中原有的组播控制是由GGSN向BM-SC进行请求的，这里我们通过RACS向GGSN直接下发组播策略信息，如上述流程中步骤S206中SPDF向BGF的请求；这样可以使GGSN直接进行组管理请求的策略匹配。

2、支持IGMP/MLD，并支持IP组播处理

以适用于xDSL网络状况的TISPAN NGN架构来说，其中传输层的AccessNode可以映射到DSLAM，RCEF+L2TF(Layer 2 Termination Function，2层终结功能)可以映射到BRAS。

这里可以在BGF和媒体提供设备之间建立应用层组播传输通道用于组播数据的传递；BGF把组播内容从隧道中取出后发送给下游节点，在这里就是RCEF。在这里BGF并不进行组播数据流的复制分发；根据用户使用的协议不同，目前一般复制分发点放在RCEF(BRAS)或者AccessNode(DSLAM)上，这在目前接入网中已是成熟技术。

3、支持BCMCS(Broadcast and Multicast Service，广播及组播服务)的应用方式

对于3GPP2所定义的BCMCS网络，在具体应用时可以将BSN看作图6所示的BGF，在业务过程中选定BSN，使其作为应用层组播的一个节点和媒体提供节点建立应用层组播传输通道用于组播媒体流的传输；在BSN收到相关的组播媒体流之后再向下游节点转发，如直接发送给终端。

4、支持DVB-H(Digital Video Broadcasting-Handheld，数字视频广播-手持方式)网络中的应用方式

对于DVB组织所定义的DVB-H网络，在具体应用时可以将IPE(IPEneapsulator，IP封装器)看作图6所示的BGF，在业务过程中选定IPE，使其作为应用层组播的一个节点和媒体提供节点建立应用层组播传输通道用于组播媒体流的传输；在IPE收到相关的组播媒体流之后再向下游节点转发，如直接发送给终端。

实施例二、

如图7所示，为在图6基础上采用IMS作为应用处理模块时的逻辑架构图，其中对于IMScore进行了简略表示，其具体规范在3GPP已有定义；这里终端用于和应用服务器(AS)进行业务协商，请求应用服务器提供服务。代理CSCF(P-CSCF)用于转发终端和服务CSCF(S-CSCF)之间的请求和响应消息。服务CSCF用于根据触发规则把业务请求消息触发到应用服务器(AS)，对消息进行路由；AS用于向用户提供业务，与终端进行必要的业务协商；根据协商的结果向MRFC(Media Resource Function Controller，媒体资源功能控制器)提出媒体资源请求；MRFC接收AS的媒体资源请求并控制MRFP(Media ResourceFunction Processor，媒体资源功能处理器)进行媒体资源的分配。MRFP受MRFC的控制向终端提供媒体资源，如提供视频/音频节目流。其它实体如SPDF，A-RACF，RCEF，BGF等在RACS架构中已有说明。另外，一般MRFC和MRFP也合称为MRF(Multimedia Resource Function，媒体资源功能)，在下面的流程中为了描述简洁，以MRF表示。

另外需要指出，除了中间处理模块实例化为IMScore之外，这里MRF作为媒体提供设备，而应用处理模块则由AS(应用服务器)承担，P-CSCF则实现了RACS架构中所述的AF功能。

仍参阅图7所示，基于IMS实现组播业务的主要流程简述如下：

终端发出组播业务请求，其请求经P-CSCF路由到S-CSCF，再由S-CSCF触发到到应用服务器AS进行处理；这与一般的IMS请求路由过程并没有什么不同；

应用服务器(AS)向MRF请求媒体资源，MRF相应的向AS响应处理结果，其中携带应用层组播相关参数等；

AS在这里可以分配一个业务流标识，该标识用于对组播媒体流进行唯一标识；随后AS向终端发送业务响应消息，该消息携带<业务流标识，组播媒体流参数，应用层组播参数>等，其中组播媒体流参数和应用层组播参数可以通过扩展SDP携带在SIP中的SDP中；这个响应消息在到达终端之前需要经过P-CSCF的处理；

中间过程和实施一相同，只是最终由SPDF返回的资源请求响应是发送给P-CSCF的。P-CSCF收到成功响应后，向终端发送业务响应，其中携带<业务流标识，组播媒体流参数>等；终端在收到业务响应后，可能和应用处理模块进行进一步的媒体协商直至协商结束。

需要说明的是，P-CSCF向RACS进行资源请求的时机根据业务请求过程的不同可能有所变化；如只有当P-CSCF确认终端和业务处理模块的业务请求成功时才开始进行资源请求，对于使用SIP进行业务请求时而言可能存在终端和AS的多次协商，这时资源请求过程可能发生在协商的中间阶段，但应在双方完全结束协商之前，如P-CSCF可能在收到AS的SIP200ok响应时才开始资源请求过程，因此流程也有可能有所变化，但其处理的基本思想不变。

本发明可以通过扩展SDP携带业务流标识和隧道参数，这里给出扩展说明。另外，需要指出，由于SDP是非独立协议，可以携带在SIP，HTTP，RTSP等中，因此这里的扩展并不限定于SIP使用。

这里可以通过在SDP中为业务流标识和隧道参数分别定义一个attribute来进行，如下：

a＝MID：业务流标识

这个扩展属性可以对SDP的媒体行(m)加以描述，也可以作为全局属性出现；条件是SDP中所有的媒体流属于同一个媒体组且将在同一个隧道中传输；其中业务流标识由应用处理模块分配，只需要保障其标识的全网唯一性即可。

a＝APP-MULTICAST-DATA：appType appParameters’networkProcess’

这个扩展属性可以对SDP的媒体行(m)加以描述，也可以作为全局属性出现，条件是SDP中所有的媒体流将通过同一个隧道传输；其中：

APP-MULTICAST-DATA为属性名；

appType为应用层组播类型，可以是封装模式(如encap)和映射模式(如locate)；

appParameters为应用层组播特定模式下的描述参数；

networkProcess则指出此属性需要在网络内处理而不应发送给终端。

若使用隧道模式，则可以采用类似下述定义方式：

a＝APP-MULTICAST-DATA：appType tunnelType tunnel-server-addresstunnel-port‘’ip’|’udp’|’tcp’’networkProcess’

这个扩展属性可以对SDP的媒体行(m)加以描述，也可以作为全局属性出现，条件是SDP中所有的媒体流将通过同一个隧道传输；其中：

APP-MULTICAST-DATA为属性名；

appType为应用层组播类型；

tunnelType为隧道类型；

tunnel-server-address为隧道服务器地址；

tunnel-port为隧道端口；

‘’ip’|‘udp’|’tcp”表示建立UDP隧道，TCP隧道或者IP隧道；

’networkProcess’支持此属性需要在网络内处理而不应发送给终端。

针对映射模式根据上述可以很容易给出类似定义，不再赘述。

另外，上述扩展属性的表示并非唯一，只是为了说明发明思想给出的实例，对于不同的隧道协议其参数可能不同。

上述扩展机制在具体使用时可以如下：

终端和应用处理模块进行业务协商，在信令中指出需要建立BGF和MRF之间的隧道(封装组播流)用于传送媒体数据；应用处理模块向终端的响应信息可以如下：

v＝0

o＝astv 8908447302890844732IN IP4as.example.com

a＝MID：aabbccddeeff

m＝audio65422RTP/AVP 0

a＝rtpmap：0PCMU/8000

c＝IN IP4 multicat_address

a＝APP-MULTICAST-DATA：encap GRE mrf-unicast.example.com PortXipnetworkProcess

a＝sendonly

m＝video 65113RTP/AVP 31

a＝rtpmap：32MPV/90000

c＝IN IP4 multicat_address

a＝APP-MULTICAST-DATA：encap GRE mrf-unicast.example.com PortY iptworkProcess

a＝sendonly

上述信息表示：媒体内容属同一个业务流标识：aabbccddeeff；所需建立的应用层隧道为封装模式，具体采用隧道方式为GRE(Generic RoutingEncapsulation，通用路由封装)类型，隧道对端地址为mrf-unicast.example.com，端口为40004等。

在该交互信令经过中间处理模块处理时，AF根据SDP描述信息请求进行隧道的建立，AF传递所述隧道信息到SPDF请求传输层进行隧道建立，SPDF根据前述方案进行具体的隧道建立过程。

这里给出的扩展方案是希望应用在前述的流程中，前面对应用方案已有描述，不再赘述。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (20)

1.一种组播/广播业务实现方法，其特征在于，包括如下步骤：

终端通过中间处理模块向应用处理模块请求建立所述组播/广播业务；

所述应用处理模块向媒体提供设备请求媒体资源，并接收所述媒体提供设备返回的建立所述传输通道的相关参数和组播/广播媒体流参数；

所述应用处理模块向中间处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的业务响应；

所述中间处理模块向传输处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的资源请求；

所述传输处理模块判断所述组播/广播业务的传输通道是否已经建立，如果是，则根据所述组播/广播媒体流参数，组播/广播从该传输通道上接收到的核心网媒体提供设备单播的组播/广播媒体流；否则，根据所述相关参数与核心网媒体提供设备之间建立所述传输通道，并根据所述组播/广播媒体流参数，组播/广播从该传输通道上接收到的所述媒体提供设备单播的组播/广播媒体流，其中所述相关参数包括：应用层组播类型和应用层组播通道描述参数。

2.如权利要求1所述的方法，其特征在于，至少两个组播/广播业务复用同一条传输通道；或者

为每一个组播/广播业务分别建立一条传输通道。

3.如权利要求1所述的方法，其特征在于，所述方法中还包括如下步骤：

所述应用处理模块向终端返回所述组播/广播业务的组播地址；

所述终端根据所述组播地址加入接收所述组播/广播媒体流的组播组。

4.如权利要求1所述的方法，其特征在于，所述方法中还包括如下步骤：

所述传输处理模块建立所述传输通道后或确认所述传输通道已经建立后，向所述中间处理模块返回资源请求响应；

所述中间处理模块向所述终端返回携带所述组播/广播媒体流参数的业务成功响应；

所述终端收到所述业务成功响应后，根据所述组播/广播媒体流参数加入接收所述组播/广播媒体流的组播组。

5.如权利要求1所述的方法，其特征在于，所述方法中还包括：所述应用处理模块为每一个组播/广播业务分配一个唯一的业务流标识，并且：

所述应用处理模块在发送给所述中间处理模块的业务响应中携带对应的业务流标识；

所述中间处理模块在发送给所述传输处理模块的资源请求中携带所述业务流标识，所述传输处理模块记录所述业务流标识并根据记录信息判断是否已经为相应的组播/广播媒体流建立了传输通道。

6.如权利要求5所述的方法，其特征在于，所述方法中还包括：

所述中间处理模块在发送给所述终端的业务响应中携带所述业务流标识，所述终端利用所述业务流标识在后续流程的业务层信令中标识或匹配所述组播/广播业务。

7.如权利要求1、5、6任一所述的方法，其特征在于如下之一：

所述终端和中间处理模块之间通过SIP协议、HTTP协议或RTSP协议实现信息交互；

所述中间处理模块和应用处理模块之间通过SIP协议、HTTP协议或实时流协议RTSP实现信息交互；

所述中间处理模块和传输处理模块之间通过通用开放策略服务COPS协议、H.248协议或Diameter协议实现信息交互。

8.如权利要求7所述的方法，其特征在于，通过扩展会话描述协议SDP携带建立所述传输通道的相关参数、组播/广播媒体流参数或业务流标识。

9.如权利要求1所述的方法，其特征在于，所述传输通道的类型包括封装模式。

10.如权利要求9所述的方法，其特征在于，所述封装模式的传输通道包括隧道，建立所述隧道的相关参数至少包括：隧道类型、媒体提供设备端的隧道地址和隧道端口。

11.如权利要求10所述的方法，其特征在于，所述隧道是通用路由封装GRE隧道。

12.如权利要求1所述的方法，其特征在于，所述传输通道的类型包括映射模式，建立所述映射模式传输通道的相关参数至少包括：映射模式类型、媒体提供设备端的单播地址和端口。

13.如权利要求1所述的方法，其特征在于，所述组播/广播媒体流参数至少包括：IP组播/广播地址和端口。

14.如权利要求1所述的方法，其特征在于，所述传输处理模块建立用户配置表，以用户标识为索引保存每一个用户对应的组播/广播媒体流参数，并根据该用户配置表验证请求所述组播/广播媒体流的用户终端的合法性。

15.一种组播/广播业务实现系统，包括终端和位于核心网侧的媒体提供设备，其特征在于，所述系统还包括：位于接入网侧的传输处理模块，应用处理模块和中间处理模块，其中，所述传输处理模块分别通过IP网络连接终端和媒体提供设备，所述应用处理模块通过接口连接中间处理模块，所述中间处理模块分别通过接口连接所述终端、传输处理模块和媒体提供设备；

终端通过中间处理模块向应用处理模块请求建立所述组播/广播业务；

所述应用处理模块向媒体提供设备请求媒体资源，并接收所述媒体提供设备返回的建立所述传输通道的相关参数和组播/广播媒体流参数，其中所述相关参数包括：应用层组播类型和应用层组播通道描述参数；

所述应用处理模块向中间处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的业务响应；

所述中间处理模块向传输处理模块发送携带所述传输通道相关参数和组播/广播媒体流参数的资源请求；

所述传输处理模块判断所述组播/广播业务的传输通道是否已经建立，如果是，则根据所述组播/广播媒体流参数，组播/广播从该传输通道上接收到的组播/广播媒体流，否则，根据所述相关参数与媒体提供设备之间建立所述传输通道。

16.如权利要求15所述的组播/广播业务实现系统，其特征在于，所述传输通道为封装模式传输通道或映射模式传输通道。

17.如权利要求15所述的组播/广播业务实现系统，其特征在于：

所述中间处理模块包括下一代网络NGN中的应用功能实体AF；

所述传输处理模块具体包括NGN中的如下子功能实体：基于业务的策略决策功能实体SPDF、接入-资源及许可控制功能实体A-RACF、资源控制执行功能实体RCEF和边界网关功能实体BGF，其中：

所述SPDF通过接口连接所述中间处理实体，所述A-RACF连接在SPDF和RCEF之间，所述BGF分别连接SPDF和RCEF，所述RCEF通过IP网络连接终端，所述BGF通过IP网络连接媒体提供设备。

18.如权利要求15所述的组播/广播业务实现系统，其特征在于：

所述应用处理模块包括IP多媒体子系统IMS中的应用服务器AS；

所述中间处理模块包括IMS中的代理-呼叫会话控制功能P-CSCF及服务-呼叫会话控制功能S-CSCF。

19.如权利要求18所述的组播/广播业务实现系统，其特征在于，所述边界网关功能实体BGF为如下之一：

支持多媒体广播组播业务MBMS的GPRS网络中的GGSN；

3GPP2所定义的广播及组播服务BCMCS网络中的广播服务节点BSN；

数字视频广播-手持方式DVB-H网络中的IP封装器IPE。

20.如权利要求15所述的组播/广播业务实现系统，其特征在于，所述传输处理模块中包括存储子模块，用于存储用户配置表，该用户配置表中以用户标识为索引保存每一个用户对应的组播/广播媒体流参数，所述传输处理模块根据该用户配置表验证请求所述组播/广播媒体流的用户终端的合法性。

Images