CN101160858A

CN101160858A - 提高组播业务可运营性的实现方法及装置

Info

Publication number: CN101160858A
Application number: CNA2006800121936A
Authority: CN
Inventors: 吴海军
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2005-07-22
Filing date: 2006-07-20
Publication date: 2008-04-09
Anticipated expiration: 2026-07-20
Also published as: EP1909439B1; US8270294B2; CN1863187B; WO2007009385A1; EP1909439A4; CN101160858B; ES2423434T3; CN1863187A; US20080068990A1; EP1909439A1

Abstract

本发明涉及一种提高组播业务可运营性的实现方法及装置。本发明的核心是：提供组播业务的网络侧根据用户终端申请开展组播业务情况构造组播业务通知报文，并将所述的通知报文发送给用户终端设备；所述的组播业务通知报文包括用于响应用户申请加入组播组的回执报文，和用于通知用户组播业务异常或加入组播组失败的原因的异常通知报文。本发明这样，可以有效提高用户针对运营商提供的组播视频业务的满意度，以及组播视频网络的可运营和可管理性。

Description

提高组播业务可运营性的实现方法及装置技术领域

本发明涉及网络通信技术领域，尤其涉及一种提髙组播业务可运营性的实现方法及装置。发明背景目前，在数据网络上开展组播业务普遍采用图 1所示的组网模型。图 1所示的组播视频网络包播：视频头端系统（即头端系统）、 IP城域网（即核心设备）、接入网（即边缘设备）和家庭网络四个组成部分。

所述的视频头端系统实现视频用户管理、 CA (条件接入） /DRM (数字版权管理）、视频编码功能，然后，将视频业务流送入 IP城域网。每一个 TV和广播频道釆用 MPEG-2编码成一路码流封装到 UDP (用户数据报协议） /IP报文中。 IP城域网通过 IP组播功能将视频业务流送到宽带接入网。接入网实现视频组加入离开控制功能，并将用户需要的视频流发送给用户。

所述的接入网可以包含二层交换机和 DSLAM设备，所述的二层交换机为 ATM (异步传输模式）交换机或以太网交换机，接入网与用户之间采用 FE (快速以太网）或者 xDSL (数字用户线）等物理线路连接。视频流从 IP城域网发送到组播路由器或者二层交换机或者 DSLAM (数字用户线接入复用器）等直接接入用户的边缘设备，根据用户的 IGMP (互联网组管理协议）控制报文将视频流发送给需要的用户。

目前，作为用户设备的 PC或者 STB (机顶盒）点播组播节目，一般采用 IGMP协议（Vl、 V2或者 V3) 的组播协议， IGMP协议是承载在 IP协议上的一种协议，其实是和 IP协议并列的，在协议上定义了客户端和组播路由器两个实体，这两个实体对应上述的网络就是视频终端和接入设备。

基于所述的 IGMP协议，主机可以通知子网组播路由器其希望加入或离开组播组。例如，当某个主机加入某一个组播组时，它通过 "成员资格报告"消息通知它所在的 IP子网的组播路由器，同时将自己的 IP模块做相应的准备，以便开始接收来自该组播组传来的数据。

在用户开展组播业务之前，首先需要在 DSLAM设备上，配置基于端口的不同的组播权限。用户只能访问自己权限列表内的组播内容，如果访问其他内容，会被拒绝，终端接受不到任何内容。如图 2所示，在于接入设备 AN上的组播权限列表中配置了用户 1 (Userl ) 和用户 2 (User 2) 的组播权项，接入设备根据所述组播权限列表中的信息控制用户的观看视频业务的权限。

目前，在图 2中，用户开展组播视频业务的处理流程如图 3所示，具体包括以下步骤- 步骤 31: 用户 1选择观看频道 1时，用户设备即机顶盒 STB1发送 IGMP Join (IGMP加入）消息加入组播组 1，即 Groupl ;

为防止报文丢失引起异常，通常发送 2次 IGMP Join消息。

步骤 32: DSLAM作为 IGMP Proxy (IGMP代理），收到用户的 IGMP Join报文后，检査该用户是否有权限，或者该物理端口是否有足够的带宽支持，如果可以，检查该组是否已经有成员加入，如是该组第一个成员，则向上层的组播路由器发送 IGMP Join消息，加入组播组 1。 '

步骤 33: 上层的组播路由器收到来自 DSLAM的 IGMP Join报文，向 DSLAM发送组播组 1 的组播流； DSLAM收到组播流，并将其组播到用户端口（支持跨 VLAN/PVC组播转发）；根据网络情况和用户访问情况不同，组播路由器可能需要通过 PIM (独立组播协议） /IGMP与上层设备交换组播路由信息。

步骤 34: 用户 2也选择观看频道 1，用户设备即机顶盒 STB2发送 IGMP Join消息加入组播组 1。

步骤 35: DSLAM收到 IGMP Join消息后，发现该组已有成员加入该组，向用户发送组播流 1。

步骤 36: 用户 1切换频道或停止收看， STB1发送 IGMP Leave (IGMP离开）消息离开组播组 1。

步骤 37: DSLAM收到 IGMP Leave消息后，发送特定组査询报文以确定该端口下是否还有其它 STB在收看频道 1，若没有，则停止向该端口发送组播流 1 _; 如果采用 IGMP Quick Leave ( IGMP快速离开），则 DSLAM不发送特定组查询报文，而是直接停止向该端口转发组播流。

步骤 38: 用户 2切换频道或停止收看， STB2发送 IGMP Leave消息离开组播组 1。步骤 39: DSLAM收到 IGMP Leave消息后，发送特定组查询报文以确定该端口下是否还有其它 STB在收看频道 1 , 若没有，则停止向该端口发送组播流 1。如果采用 IGMP Quick Leave, 则 DSLAM不发送特定组查询报文，而是直接停止向该端口转发组播流。

步骤 310: DSLAM等待最后成员査询间隔后，没有收到 Report (上报）消息，认为该组已经没有成员，向 DSLAM发送 Leave (离开）报文。

在基于 DSL线路的 IPTV (互联网协议电视）业务中，由于 DSL的线路带宽会随机的变化，当线路受到瞬间的外来干扰时，会出现带宽降低或者掉线情况，此时根据组播动态的带宽控制中，当某个接入设备上的带宽申请已经超过了宽带接入设备的下行带宽，就会使得所有的节目视频出现随机丢包，使得用户观看的节目受到影响。

从上述图 3所示的用户终端开展组播业务的处理流程可以看出，由于目前的 IGMP组播协议是一个用户发起的单向过程，服务器端没有基于 IGMP协议向用户回馈信息的通道。

因此，目前针对异常情况的出现，网络侧仅选择简单拒绝用户的请求或随机丢弃发给用户终端的组播包，此时，用户的视频终端将会出现黑屏情况。也就是说，网络侧无法将用户无法观看视频节目或者观看到的视频节目质量下降的原因告知用户，导致用户针对组播视频业务的满意度下降。发明内容本发明的目的是提供一种提高组播业务可运营性的实现方法及装置，从而使得终端加入组播组过程中，终端设备可以明确获知加入组播组幵展组播业务的处理过程的情况，从而提高了组播业务开展的可运营性。

本发明的目的是通过以下技术方案实现的：

本发明提供了一种提高组播业务可运营性的实现方法，包括：

提供组播业务的网络侧根据用户终端申请开展组播业务情况构造组播业务通知报文，并将所述的组播业务通知报文发送给用户终端设备。

本发明所述的方法具体包括- 当提供组播业务的网络侧确定无法为用户终端提供期望的组播业务时，确定相应的原因；

将所述的原因承载于异常通知报文中，并作为组播业务通知报文发送给用户终端设备。

所述的当提供组播业务的网络侧确定无法为用户终端提供期望的组播业务时，确定相应的原因的处理具体包括：

当用户终端向提供组播业务的网络申请加入组播组，且网络侧确定无法将其加入到组播组中时，确定不能加入组播组的原因；和 /或，

当已经加入组播组的用户终端获取的组播业务服务质量发生改变时，则网络侧确定服务质量发生改变的原因。

所述的确定不能加入组播组的原因的处理包括：

确定用户终端不具备相应的权限，或者网络侧的物理端口没有足够的带宽支持用户终端开展组播业务作为其不能加入组播组的原因。

本发明所述的方法具体包括：

当提供组播业务的网络侧接收到用户终端设备发来的申请加入组播组的报文时，构造相应的回执报文作为组播业务通知报文发送给相应的用户终端设备。

本发明所述的方法还包括：

在向用户终端提供组播业务的网络侧设备中，当接收到用户终端发来的申请加入组播组的报文时，提取报文中的源地址信息，将待发送的组播业务通知报文的目的地址添写为所述提取的源地址信息，并发送；

或者，

在向用户终端提供组播业务的网络侧设备中，当接收到用户终端发来的申请加入组播组的报文时，记录用户的端口，将待发送的组播业务通知报文釆用组播报文承载，指定发送到记录的用户端口。

所述的组播业务通知报文是通过针对互联网组管理协议 IGMP报文的扩展获得，且所述的异常通知报文和回执报文可以为同一种类型或两种不同类型的报文。

所述的源地址信息为：

用户终端设备的媒体接入控制 MAC地址信息。

本发明还提供了一种提高组播业务可运营性的装置，包括：

组播业务通知报文构造模块：用于根据用户终端申请开展组播业务情况构造组播业务通知报文，并将所述的通知报文发送给用户终端设备。

所述的组播业务通知报文构造模块具体包括确定故障原因处理模块和异常通知报文构造模块，和 /或，回执报文构造模块，其中- 确定故障原因处理模块：当向用户提供的组播业务出现异常时，确定相应的故障原因信息；

异常通知报文构造模块：根据确定故障原因处理模块确定的原因信息构造异常通知报文，并发送给用户终端；回执报文构造模块：当接收到用户终端发来的申请加入组播组的报文后构造相应的回执报文，并发送给用户。

本发明还提供了一种提高组播业务可运营性的用户终端装置，包括：

组播业务请求发送控制模块：当用户终端设备向网络侧发送组播业务请求报文后，如果判断确定在预定的时间内未收到网络侧返回的组播业务通知报文，则控制再次进行组播业务请求报文的发送。

所述的提高组播业务可运营性的用户终端装置还包括：

异常通知报文处理模块：用于接收网络侧发来的异常通知报文，并将异常通知报文承载的异常原因信息通过显示界面显示。

由上述本发明提供的技术方案可以看出，本发明由于在网络侧收到终端申请加入组播组的报文后，向终端设备返回响应报文（即组播业务通知报文），从而使得终端能够及时获知其加入过程是否成功，以及加入失败的原因，同时，还可以在用户终端收看到的组播视频业务质量下降时获知相应的原因。这样，可以有效提髙用户针对运营商提供的组播视频业务的满意度。

本发明具体是通过扩展 IGMP协议提供回执和通知功能，以提高组播协议的稳定性，提高组播视频网络的可运营和可管理性。附图简要说明图 1为组播网络的组网模型示意图；

图 2为组播网络结构示意图；

图 3为现有技术中组播业务开展过程中示意图；

图 4为现有的 IGMP报文的格式结构示意图；

图 5为本发明中幵展组播业务的具体实现处理过程示意图；

图 6为图 5中回执报文的具体实现格式结构示意图；

图 7为图 5中异常通知报文的具体实现格式结构示意图；

图 8为本发明所述的装置的具体实现结构示意图。实施本发明的方式本发明的核心是实现提供组播业务的网络侧能够向用户终端（即用户设备，或者称为用户终端设备）提供开展组播业务过程中的情况信息，具体可以为根据用户终端申请开展组播业务情况构造组播业务通知报文，并将所述的组播业务通知报文发送给用户终端设备；所述的组播业务通知报文可以包括：用于响应用户申请加入组播组的回执报文，和 /或，用于通知用户组播业务异常或加入组播组失败的原因的异常通知报文。

也就是说，当网络资源或者用户权限无法满足用户的视频组播业务时，能够主动切换到用户提供说明原因或者免费的单独已存在视频频道，并向用户终端发送组播业务通知报文，避免出现黑屏现象且用户无法获知黑屏原因，提高客户满意度。所述的无法满足用户的视频组播业务的时候包括：用户终端申请加入过程中无法满足加入条件的情况，以及在用户终端接收组播视频业务过程中出现组播视频业务质量下降或无法接收的情况。为便于说明本发明，下面首先对现有技术中用户开展组播业务的处理过程中承载在以太网接口上的 IGMP报文格式进行说明，以 IGMP V2 RFC2236标准为例，相应的 IGMP报文的格式如图 4所示，所述报文包括- 首先是以太网报文头，其中源 MAC地址为单播 MAC地址，目的 MAC地址为组播 MAC地址，以太网协议类型 Ethertype为 IP协议，表明承载的报文为 IP报文；

其次是 IP报文头， IP报文头中源 IP地址为发送者的单播 IP地址，目的 IP地址为组播组 IP地址，该组播 IP地址通过通用的规则映射到以太网报文头中的组 MAC地址。对于 IGMP 协议， IP头中的协议类型为 IGMP协议，表明承载的数据为 IGMP协议数据。

然后是 IGMP报文头， IGMP报文根据 IGMP v2标准的定义，首先是 Type表明本 IGMP控制报文的类型，主要有以下几个类型：

0x11 = Membership Query, 组査询报文；

0x16 = Version 2 Membership Report, 组报告报文，用于加入组播组等功能； 0x17 = Leave Group, 组离开报文，用于离开指定的组播组；

0x12 = Version 1 Membership Report, 兼容 IGMP VI的报文类型；

其次是最大响应时间，最后是校验值 Checksum用于对报文的完整性进行校验，最后是组播组号。本发明的一种实现方式可以通过扩充目前的 IGMP协议和流程实现，下面将以扩展 IGMP协议和流程实现本发明为例，对本发明所述的方法的具体实现方式进行描述。本发明在具体实现过程中包括两方面考虑：

一方面为提高协议报文的可靠性，设备在收到报文以后，发出回执报文，这样可以减少盲目的多次发送 IGMP报文；

另一方面实现在用户点播请求失败的时候，将失败的原因传送给用户，需要扩展 IGMP协议，增加一种报文类型，如果用户申请的带宽不够的时候，向用户发出 IGMP组播通知信息报文。首先，对本发明修改后的用户加入组播组开展组播业务的处理过程进行说明，如图 5 所示，具体包括以下步骤：

步骤 51 : 用户 1选择观看频道 1， STB1发送 IGMP Join消息加入组播组 1，启动定时器 1，时间 2S。

步骤 52: DSLAM作为 IGMP Proxy, 收到用户的 IGMP Join报文后，记录下 STB1的源 MAC 地址，同时根据该报文的 MAC地址构造一个 IGMP报文，作为回执报文，即作为组播业务通知报文，釆用 STB1的源 MAC地址作为目的，并采用单播以太网报文发送给 STB1 ; 或者， DSLAM设备采用 IGMP组播封装，根据该用户申请报文进入的端口，指定端口将该 IGMP回执报文发送到指定用户终端；

- 同时， DSLAM还需要检査该用户是否有权限，或者该物理端口是否有足够的带宽支持，如果可以，则判断该组是否已经有成员加入，如是该组第一个成员，则向上层的组播路由器发送 IGMP Join消息，加入组播组 1。

步骤 53: STB1收到回执报文以后，确认 DSLAM已经收到 IGMP申请报文， IGMP Join 报文，则不发送备份的 IGMP报文；

如果 STB1定时器 1超时仍然没有收到回执，则再次发出 IGMP申请报文。

步骤 54: 上层的组播路由器收到来自 DSLAM的 IGMP Join报文，向 DSLAM发送组播组 1 的组播流； DSLAM收到组播流后，将其组播到用户端口（支持跨 VLAN/PVC组播转发）；根据网络情况和用户访问情况不同，组播路由器可能需要通过 PIM/IGMP与上层设备交换组播路由信息。

步骤 55: 用户 2也选择观看频道 1, 则 STB2发送 IGMP Join消息加入组播组， DSLAM收到 STB2发来的 IGMP Join报文后，记录下 STB2的源 MAC地址；

而且， DSLAM还需要检査该用户是否有权限，或者该物理端口是否有足够的带宽支持，如果可以，则执行步骤 57，如果没有权限，则执行步骤 56。

步骤 56: 根据 STB2的源 MAC地址，构造 IGMP信息异常通知报文，采用 STB2的 MAC地址为目的 MAC, 单播方式向 STB2发送消息；

或者 DSLAM设备采用 IGMP组播封装，根据该用户申请报文进入的端口，指定端口将该 IGMP信息异常通知报文发送到指定用户。

当用户接收到所述的异常通知报文，确定自身无权限观看相应的视频组播业务，则不再向网络侧发送 IGMP Join消息，即结束其申请加入组播组的处理过程。

步骤 57: DSLAM收到 IGMP Join消息后，如果检査发现该组已有成员加入该组，向用户发送组播流 1。

步骤 58: 用户 1切换频道或停止收看， STB1发送 IGMP Leave消息离开组播组 1。

步骤 59: DSLAM收到 IGMP Leave消息后，发送特定组查询报文以确定该端口下是否还有其它 STB在收看频道 1，若没有，则停止向该端口发送组播流 1。如果采用 IGMP Quick Leave, 则 DSLAM不发送特定组查询报文，而是直接停止向该端口转发组播流。

从上述本发明提供的处理流程可以看出，本发明一方面可以在用户申请加入组播组的过程向用户发送回执报文通知用户网络侧已经接收到所述的申请加入报文；另一方面，还可以在网络侧拒绝用户的加入组播组申请时，通过异常通知报文将拒绝加入的原因告知用户。所述的回执报文与异常通知报文可以合并为一种类型报文实现相应功能，在一种类型报文中可以采用不同的字段标示报文为异常通知报文或回执报文，当然，也可以通过两种类型报文实现。

除此之外，本发明中，还可以在用户开展组播业务的过程中，如果提供给用户的组播业务服务质量下降时，即网络侧无法为用户提供其期望的组播业务时，首先在网络侧确定组播业务出现异常的原因，之后，通过异常通知报文将出现组播业务服务质量下降的原因通知用户，以便用户可以获知无法正常观看组播业务的原因。针对本发明所述的组播业务处理过程涉及组播业务通知报文包括的回执报文和异常通知报文，本发明是通过扩展和修改现有的 IGMP协议报文实现，可以只扩展一种报文实现相应功能，当然，也可以通过两种报文实现。

如果采用两种报文：具体为扩展了 IGMP的协议定义，增加两种 IGMP控制报文类型：

( 1 )第一种为： 0x46 = Report Receipt, 回执报文，用于 0x16报文收到后的确认报文，该回执报文的格式如图 6所示，包括：报文类型 0x46，最大响应时间 Max Resp Time，校验值和加入的组播组号 Group Address;

(2)第二种为： 0x48 = Report Inform, 信息报文，或者称为异常通知报文，用于 0x16报文处理结果的异常通知报文，比如用户组申请加入失败以后，反馈给用户告知失败，在用户开展组播业务过程中，当组播业务出现异常时，通知用户出现异常的原因；所述信息报文的格式如图 7所示，具体包括：报文类型 0x48，最大响应时间，校验值，加入的组播组号和失败的原因，针对所述原因具体可以以字符串方式或者原因 ID表示；

通常，加入组播组失败或者组播业务出现异常的原因 ID可以包括- 0x0001 , 骨千带宽不够；

0x0002, 线路带宽不够；

0x0003, 线路恶化，等等；

如果采用字符串方式，则直接在该位置放入原因字符串，如： "Backbone bandwidth is not enough" 。当然，根据网络侧可以确定的故障类型还可以设置新的编码，并对应新的故障或异常的具体原因。

另外，现有协议中规定釆用二层组播报文来传递 IGMP报文，即二层目的 MAC地址为组播地址，如果本发明扩展的回执报文和异常通知报文仍采用组播报文进行传递的活，会将导致所有的该组的用户都会收到该报文，而不是有针对性地只通知真正需要通知的用户。

为此，本发明采用两种方法- 方法一：将回执报文中的目的 MAC地址修改为单播 MAC地址，利用用户的 IGMP申请的源 MAC地址作为相应的目的 MAC地址，这样，根据该 MAC地址相应的回执报文和异常通知报文就会被转发到指定的用户终端，从而实现有针对性的只通知到指定的需要通知的用户，这样，还可以有效节约网络中的带宽资源。 .

方法二： DSLAM设备根据用户组播申请报文加入的端口或者异常发生的端口，将回执报文和异常通知报文指定发送到该用户端口，不采用组播发送到其它端口，这样也只有有需要的用户才会收到流量。本发明还包括：当用户在开展组播业务过程中，如果视频组播业务的质量下降，例如，由于带宽限制导致丢包等情况出现时，则网络侧还可以通过图 7所示的格式构造异常通知报文通知用户终端设备出现组播视频业务质量下降的原因，以便于用户可以实时获知组播业务出现异常的原因，这样，一方面可以提高用户针对运营商提供的组播业务的满意度，另一方面也便于用户在可能的情况下及时排除导致组播业务质量下降的原因，改善组播业务质量。本发明所述的方法在具体实现过程中可以通过一个提高组播业务可靠性的实现装置来实现，所述的装置可以设置于宽带接入设备中，如 DSLAM设备等，当然，也可以独立设置。下而将结合附图对本发明所述的装置进行说明，如图 8所示，本发明所述的装置包括组播业务通知报文构造模块，该模块用于根据用户终端申请开展组播业务情况构造组播业务通知报文，并将所述的通知报文发送给用户终端设备，该模块具体包括：

确定故障原因处理模块：当向用户提供的组播业务出现异常时，则确定故障原因信息，如线路恶化，带宽不足等；

异常通知报文构造模块：根据确定故障原因处理模块确定的原因信息构造异常通知报文，并发送给用户终端，以便于用户根据异常通知报文获知组播业务出现异常的原因；

回执报文构造模块：当接收到用户终端发来的申请加入组播组的报文后构造相应的回执报文，并发送给用户。

在具体实现过程中，也可以仅包括回执报文构造模块，或者，仅包括确定故障原因处理模块和异常通知报文构造模块。

本发明提供的提高组播业务可运营性的用户终端如图 8所示，具体包括组播业务请求发送控制和异常通知报文处理模块，其中- 组播业务请求发送控制模块：当用户终端设备向网络侧发送组播业务请求报文后，如果判断确定在预定的时间内未收到网络侧返回的响应报文，则控制再次进行组播业务请求报文的发送。

异常通知报文处理模块：用于接收网络侧发来的异常通知报文，并将异常通知报文承载的异常原因信息通过显示界面显示。综上所述，本发明通过扩展 IGMP协议，提供回执和通知功能，从而提高了组播协议的稳定性，提高了组播视频网络的可运营性。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims

权利要求

1、一种提高组播业务可运营性的实现方法，其特征在于，包括：

提供组播业务的网络侧根据用户终端申请开展组播业务情况构造组播业务通知报文，并将所述的组播业务通知报文发送给用户终端设备。
2、根据权利要求 1所述的提高组播业务可运营性的实现方法，其特征在于，该方法具体包括：

当提供组播业务的网络侧确定无法为用户终端提供期望的组播业务时，确定相应的原因；

将所述的原因承载于异常通知报文中，并作为组播业务通知报文发送给用户终端设备。
3、根据权利要求 2所述的提高组播业务可运营性的实现方法，其特征在于，所述的当提供组播业务的网络侧确定无法为用户终端提供期望的组播业务时，确定相应的原因的处理具体包括：

当用户终端向提供组播业务的网络申请加入组播组，且网络侧确定无法将其加入到组播组中时，确定不能加入组播组的原因；

和 /或，

当已经加入组播组的用户终端获取的组播业务服务质量发生改变时，则网络侧确定服务质量发生改变的原因。
4、根据权利要求 3所述的提高组播业务可运营性的实现方法，其特征在于，所述的确定不能加入组播组的原因的处理包括- 确定用户终端不具备相应的权限，或者网络侧的物理端口没有足够的带宽支持用户终端开展组播业务作为其不能加入组播组的原因。
5、根据权利要求 1所述的提高组播业务可运营性的实现方法，其特征在于，该方法具体包括：

当提供组播业务的网络侧接收到用户终端设备发来的申请加入组播组的报文时，构造相应的回执报文作为组播业务通知报文发送给相应的用户终端设备。
6、根据权利要求 1至 5任一项所述的提高组播业务可运营性的实现方法，其特征在于，该方法还包括：

在向用户终端提供组播业务的网络侧设备中，当接收到用户终端发来的申请加入组播组的报文时，提取报文中的源地址信息，将待发送的组播业务通知报文的目的地址添写为所述提取的源地址信息，并发送；或者，

在向用户终端提供组播业务的网络侧设备中，当接收到用户终端发来的申请加入组播组的报文时，记录用户的端口，将待发送的组播业务通知报文采用组播报文承载，指定发送到记录的用户端口。
7、根据权利要求 6所述的提高组播业务可运营性的实现方法，其特征在于，所述的组播业务通知报文是通过针对互联网组管理协议 IGMP报文的扩展获得，且所述的异常通知报文和回执报文为同一种类型或两种不同类型的报文。
8、根据权利要求 6所述提高组播业务可运营性的实现方法，其特征在于，所述的源地址信息为：

用户终端设备的媒体接入控制 MAC地址信息。
9、一种提髙组播业务可运营性的装置，其特征在于，包括：

组播业务通知报文构造模块：用于根据用户终端申请幵展组播业务情况构造组播业务通知报文，并将所述的通知报文发送给用户终端设备。
10、根据权利要求 9所述的提高组播业务可运营性的装置，其特征在于，所述的组播业务通知报文构造模块具体包括确定故障原因处理模块和异常通知报文构造模块，和 /或，回执报文构造模块，其中：

确定故障原因处理模块：当向用户提供的组播业务出现异常时，确定相应的故障原因信息；

异常通知报文构造模块：根据确定故障原因处理模块确定的原因信息构造异常通知报文，并发送给用户终端；

回执报文构造模块：当接收到用户终端发来的申请加入组播组的报文后构造相应的回执报文，并发送给用户。
11、一种提高组播业务可运营性的用户终端装置，其特征在于，包括：

组播业务请求发送控制模块：当用户终端设备向网络侧发送组播业务请求报文后，如果判断确定在预定的时间内未收到网络侧返回的组播业务通知报文，则控制再次进行组播业务请求报文的发送。
12、根据权利要求 11所述的提高组播业务可运营性的用户终端装置，其特征在于，还包括：

异常通知报文处理模块：用于接收网络侧发来的异常通知报文，并将异常通知报文承载的异常原因信息通过显示界面显示。