演进多媒体广播组播业务接入网关、基站和方法

摘要

本发明提出了一种支持网络组播的演进多媒体广播组播业务(EMBMS)接入网关，包括：接收/响应装置，用于接收来自广播组播服务中心的多媒体广播组播业务会话开始消息，并在接收到所述多媒体广播组播业务会话开始消息后向广播组播服务中心返回响应消息；存储装置，用于存储各个多媒体广播组播业务服务区与各个基站之间的映射关系；确定装置，用于在所述接收/响应装置接收到所述多媒体广播组播业务会话开始消息时，根据存储的所述映射关系，确定与所述多媒体广播组播业务相关联的基站；以及发送装置，用于向所确定的基站发送所述多媒体广播组播业务会话开始消息。

说明书

技术领域

本发明涉及移动通信领域，尤其是第三代移动通信领域的系统结构演进/长期演进(SAE/LTE)，更具体地，涉及一种支持因特网协议(IP)组播的演进多媒体广播组播业务(EMBMS)接入网关、基站和方法。

背景技术

与演进前的网络结构相比，目前基于SAE/LTE的网络结构更加平坦。一方面，无线接入网部分由原有的两个网络节点结构(基站NodeB+无线网络控制器RNC)简化成一个网络节点结构(基站eNodeB，以下简写作eNB)；另一方面，类似网格的网络连接方式被引入，也就是说一个eNB可以和多个接入网关(aGW)通过S1接口相连接；一个eNB也可以和邻近的多个eNB通过X2接口相连接，这种连接可以是物理的也可以是逻辑的，如果是逻辑相连，两个eNB在物理上可以通过aGW转接。SAE/LTE的网络结构如图1所示。

具体地，参考图1，两个接入网关aGW1和aGW2分别通过S1接口与三个基站eNB1、eNB2和eNB3相连，以及三个基站eNB1、eNB2和eNB3之间通过X2接口彼此相连。图1中示出了各个节点之间存在物理连接的情况。如果eNB1和eNB3之间不存在X2接口连接，则eNB1可以通过aGW1或aGW2与eNB3相连，从而构成eNB1与eNB3之间的逻辑连接。

从3GPP Rel7开始，定义了SAE/LTE的规范，在SAE/LTE的网络结构中，MBMS被称为EMBMS(Evolved-MBMS，演进MBMS)。这种平坦的网络结构给多媒体广播组播业务(MBMS)数据的有效发送带来了新的挑战：是沿用Rel7版本前的GTP协议(GPRS隧道协议)连接eNB和aGW还是引入其他技术。在3GPP目前的讨论中，提出将IP组播技术引入广播组播业务的网络结构中，但目前的规范中还没有定义在用户平面如何连接eNB和aGW，也就是说3GPP目前没有定义S1接口上的协议结构。本发明在给出了S1接口上的协议结构的基础上，讨论了如何发送MBMS的控制信息，进而提出了一种支持IP组播的EMBMS接入网关、基站和方法。

据Nokia和Vodafone于2006年5月在RAN3的52次会议上提交的文稿(R3-060652 MBMS aspects in SAE/LTE work，Nokia；R3-060694Support of MBMS in E-UTRAN)显示，他们赞成将IP组播引入EMBMS，并初步分析了如何在S1接口上发送EMBMS的控制信息。对于组播业务，Nokia建议将MBMS会话开始(MBMS Session Start)消息发送给包含在服务区(Service Area，下文简称为SA)范围内、并且包含在有感兴趣用户的跟踪区(Tracking area，下文简称为TA)范围内的那些eNB；Vodafone建议将MBMS会话开始消息发送给包含在有感兴趣的用户的TA范围内的那些eNB。对于广播业务，Nokia和Vodafone公司都认为MBMS会话开始消息需要发送给包含在SA范围内的那些eNB。

但是，上面两篇参考文献只是提出可以将IP组播引入EMBMS，而没有给出具体的协议栈结构和操作方法，所以IP组播如何在业务数据发送方面发挥作用是不明确的。

因此，需要一种支持IP组播的EMBMS接入网关、基站和方法，能够指出在SAE/LTE的框架下，如何使用IP组播发送EMBMS的业务数据，使得从aGW发出的MBMS业务数据更加有效地到达eNB。

上面两篇参考文献虽然给出了EMBMS的流程设计方案，但在技术方面仍然存在缺陷。例如，对于组播业务，在aGW选择哪些eNB来向其发送MBMS业务开始消息的问题上，存在着有可能造成一些需要接收MBMS会话开始消息的eNB未能接收MBMS会话开始消息的缺陷。

因此，需要一种支持IP组播的EMBMS接入网关、基站和方法，一方面使eNB能够从aGW得到足够的信息，另一方面能够在各种可能的场景下为eNB的功能实现和流程设计提供方便。

发明内容

本发明的目的是提供一种支持IP组播的EMBMS接入网关，能够从接入网关得到足够的信息，使得从接入网关发出的MBMS业务数据更加有效地到达eNB，本发明还提供了相应的基站和IP组播的EMBMS接入网关及基站的操作方法。

根据本发明的一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)接入网关，包括：接收/响应装置，用于接收来自广播组播服务中心的多媒体广播组播业务会话开始消息，并在接收到所述多媒体广播组播业务会话开始消息后向广播组播服务中心返回响应消息；存储装置，用于存储各个多媒体广播组播业务服务区与各个基站之间的映射关系；确定装置，用于在所述接收/响应装置接收到所述多媒体广播组播业务会话开始消息时，根据存储的所述映射关系，确定与所述多媒体广播组播业务相关联的基站；以及发送装置，用于向所确定的基站发送所述多媒体广播组播业务会话开始消息。

根据本发明的另一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)接入网关的操作方法，包括以下步骤：接收来自广播组播服务中心的、针对多媒体广播组播业务的多媒体广播组播业务会话开始消息；在接收到所述多媒体广播组播业务会话开始消息后向广播组播服务中心返回响应消息；根据所存储的各个多媒体广播组播业务服务区与各个基站之间的映射关系，确定与所述多媒体广播组播业务相关联的基站；以及向所确定的基站发送多媒体广播组播业务会话开始消息。

根据本发明的再一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)接入网关，包括：存储装置，用于存储路由表；接收装置，用于接收来自广播组播服务中心的数据，并将接收到的数据还原成因特网协议组播包；分组数据会聚协议数据包处理装置，用于将因特网协议组播包封装成分组数据会聚协议包；因特网协议组播包处理装置，用于从所还原的因特网协议组播包中提取因特网协议组播地址，以所提取的因特网协议组播地址作为因特网协议组播地址，将封装后的分组数据会聚协议包重新封装成因特网协议组播包，以及根据所提取出的因特网协议组播地址和所存储的路由表，确定要接收重新封装后的因特网协议组播包的基站；一个或多个传输协议处理装置，分别与各个基站相关联，根据相应的传输协议处理对重新封装后的因特网协议组播包进行处理；以及一个或多个发送装置，分别与各个基站相关联，用于向所确定的基站发送根据相应的传输协议处理的数据包。

根据本发明的再一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)接入网关的操作方法，包括以下步骤：接收来自广播组播服务中心的数据，并将接收到的数据还原成因特网协议组播包；从还原后的因特网协议组播包中提取因特网协议组播地址；将接收到的因特网协议组播包封装成分组数据会聚协议包；以所提取的因特网协议组播地址作为因特网协议组播地址，将分组数据会聚协议包重新封装成因特网协议组播包；根据所提取的因特网协议组播地址和所存储的路由表，确定要接收重新封装后的因特网协议组播包的基站；根据相应的传输协议对重新封装后的因特网协议组播包进行处理；以及向所确定的基站发送经传输协议处理的数据包。

根据本发明的再一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)基站，包括：接收/响应装置，用于接收来自接入网关的多媒体广播组播业务会话开始消息和多媒体广播组播业务会话更新消息，并向接入网关返回响应消息；存储装置，用于存储各个多媒体广播组播业务的服务区与所述基站所管理的各个小区之间的映射关系；通告过程处理装置，用于在所需小区内发起通告过程，并返回通告过程的结果；发送装置，用于向各个小区发送各种信息和数据；以及基站控制器，用于控制所述基站的操作，根据所接收到的多媒体广播组播业务会话开始消息或多媒体广播组播业务会话更新消息、和所存储的映射关系，确定是否需要在所管理的各个小区内发起通告过程。

根据本发明的再一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)基站的操作方法，包括以下步骤：从接入网关接收多媒体广播组播业务会话开始消息和多媒体广播组播业务会话更新消息，向接入网关返回响应消息；针对所述基站所管理的各个小区，根据所接收到的多媒体广播组播业务会话开始消息和多媒体广播组播业务会话更新消息、以及所存储的映射关系，分别执行以下操作：确定该小区是否需要发起通告过程，如果需要，则发起通告过程，并等待通告过程的结果；确定是否需要为该小区分配无线承载；如果需要为该小区分配无线承载，则分配无线承载，并将无线承载配置信息通知给用户设备；以及如果不需要为该小区分配无线承载，则确定是否需要发送多媒体广播组播业务的状态信息，如需要发送，则进行发送。

根据本发明的再一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)基站，包括：接收装置，用于接收来自接入网关的多媒体广播组播业务数据；存储装置，用于存储各个多媒体广播组播业务的服务区与所述基站所管理的各个小区之间的映射关系；因特网协议组播数据包处理装置，用于接收因特网协议组播数据包，提取因特网协议组播数据包的内容，并根据所存储的映射关系，确定需要接收所述因特网协议组播数据包的内容的小区；无线接口协议处理装置，与所述基站所管理的各个小区相关联，用于对来自因特网协议组播数据包处理装置的数据进行无线接口协议处理，并将处理后的数据提供给发送装置；发送装置，用于向各个小区发送各种信息和数据；以及基站控制器，用于控制所述存储装置和所述因特网协议组播数据包处理装置，将所述接收装置接收到的因特网协议组播包提供给所述因特网协议组播数据包处理装置。

根据本发明的再一个方面，提供了一种支持网络组播的演进多媒体广播组播业务(EMBMS)基站的操作方法，包括以下步骤：接收来自接入网关的多媒体广播组播业务数据；接收因特网协议组播数据包，提取因特网协议组播数据包的内容；根据所存储的各个多媒体广播组播业务的服务区与所述基站所管理的各个小区之间的映射关系，确定需要接收所述因特网协议组播数据包的内容的小区；对因特网协议组播数据包的内容进行无线接口协议处理；以及向所确定的小区发送处理后的数据。

附图说明

下面将参照附图，对本发明的优选实施例进行详细的描述，其中：

图1是示出了SAE/LTE的网络结构的示意图；

图2是引入IP组播之后网络结点的协议栈结构的示意图；

图3A是示出了MBMS业务开始过程的时序图；

图3B是用于解释需要向哪些eNB发送MBMS会话开始消息的示意图；

图3C是用于解释需要向哪些eNB发送MBMS会话开始消息的示意图；

图4是示出了根据本发明的接入网关的结构的方框图；

图5A是示出了接入网关的MBMS会话开始消息发送处理的流程图；

图5B是示出了对接入网关的数据包进行的处理的流程图；

图6是示出了根据本发明的基站的结构的方框图；

图7是示出了基站在收到MBMS会话开始消息后的处理的流程图；

图8是示出了基站在收到IP组播数据包后的处理的流程图；以及

图9是用于详细解释本发明的、网络连接和规划的典型场景的示意图。

具体实施方式

下面结合附图说明本发明的具体实施方式。应该指出，所描述的实施例仅是为了说明的目的，而不是对本发明范围的限制。所描述的各种数值并非用于限定本发明，这些数值可以根据本领域普通技术人员的需要进行任何适当的修改。

图2是引入IP组播之后网络结点的协议栈结构的示意图。

在用户平面，因为IP组播要被引入基站(eNB)，所以IP组播可以作为S1接口用户平面数据的承载协议，那么各网络结点的协议栈如图2所示。其中广播组播服务中心(BM-SC)和3GPP Rel6中的BM-SC的功能相同。接入网关(aGW)和BM-SC通过Gi接口连接。

整个MBMS业务的传输涉及两层IP组播的封装。第一层涉及应用层，并在BM-SC、aGW和UE侧得到识别。第二层涉及S1接口上的传输层技术，其协议结构以图2中的阴影部分表示。在IP组播协议层之下，还有其他传输层的协议，图2中统一用传输网络层(TNL)来标识。本发明对它们使用的协议栈没有限制，可以沿用现有规范中的传输网络层协议栈。

标准的IP组播路由器在收到IP组播包之后，不做额外处理，直接向IP组播地址转发所接收到的IP组播包。但是，在将IP组播引入到EMBMS之后，因为PDCP(分组数据会聚协议)是在aGW第一层实现的，要在PDCP包的基础上对处在aGW第二层的IP组播进行再打包。因此，在IP组播的传播路径中，aGW不再是一个标准的IP组播的路由器，它需要从收到的IP组播包中解析出IP组播地址，然后用解析出的IP组播地址对IP组播的第二层进行封装。此后，利用路由功能将IP组播包分发至所有需要IP组播包的eNB。对于不同的业务，aGW可能需要把数据发给不同的eNB，这是由IP组播组管理协议和路由表来保证的，由于这些内容不涉及到本发明的实质内容，在此省略对其的详细描述。

图3A是示出了MBMS业务开始过程的时序图。

如图3A所示，在控制平面，MBMS业务的开始由上游节点通过MBMS会话开始(MBMS Session Start)过程通知下游节点。

在收到来自BM-SC的MBMS会话开始消息后，aGW返回MBMS会话开始响应消息给BM-SC作为应答。然后，aGW需要判断和它相连的哪些eNB需要获得MBMS会话开始消息。这里，EMBMS仍然沿用MBMS的原则，即在一个预先定义好的地理区域(这个区域被称为服务区SA)内为用户提供业务。不同的业务可以有不同的SA。因为运营商在进行网络规划时，可以在同一个地理区域用不同层次的多个小区共同覆盖。

在本发明中，如果某个eNB至少包含一个属于某个MBMS业务的SA范围内的小区时，此eNB就需要接收这个业务的MBMS会话开始消息。

例如，图3B示出了用于解释需要向哪些eNB发送MBMS业务1的MBMS会话开始消息的示意图。对于eNB11而言，虽然只有小区1属于SA1，小区2不属于SA1，但eNB1也需要接收MBMS会话开始消息。对于eNB2，小区3和4都属于SA1，因此eNB12需要接收MBMS会话开始消息。但是，对于eNB13，其所管理的小区5并不属于SA1，因此eNB13不需要接收MBMS会话开始消息。

这也意味着，aGW需要保存SA和eNB的映射关系(参考表1)。aGW可以利用各种方式获得SA和eNB的映射关系。例如，运营商可以在OMC(操作、管理、控制)设备里维护SA到小区的映射表、以及每个eNB管理哪些小区的映射表。然后由这两个映射表推断出SA和eNB的映射关系，在aGW初始化的时候通过静态配置告知aGW。OMC设备也可以在某个MBMS业务的会话开始时，由这两个映射表推断出对于该MBMS业务而言的SA和eNB的映射关系，然后将这个关系告知给aGW。但是，在本发明中，并不限制aGW获得上述映射关系的方法。

例如，对于图3B所示的情形，aGW可以保存如下映射关系(表1)：

表1

  服务区(SA)  基站(eNB)  SA1  eNB11、eNB12  SA2  eNB11、eNB13

在MBMS会话开始消息中，aGW需要将SA告知eNB。因为eNB保存有SA和小区的映射关系(参考表2)，eNB就可以在其管理的小区的空中接口上发送业务开始或业务正在进行的状态信息。对组播业务而言，这些信息可以触发通告过程，从而在空中接口上进一步触发计数或投票过程，这些过程可以由网络触发或者由用户设备(UE)主动发起。通过这些过程，eNB可以判断一个小区是否有感兴趣的用户，然后进一步判断是否有必要在此小区为这个业务建立无线承载(RB)。在本发明中，根据eNB不同的实现方式，由eNB自行确定在什么情况下发送业务开始或业务正在进行的状态信息。eNB可以灵活地使用这些信息完成所需要的功能。

例如，对于图3B所示的情形，eNB11～eNB13可以保存如下映射关系(表2)：

表2

现有的方案建议把MBMS会话开始消息发到包含在有感兴趣的UE的TA范围内的eNB，但是包含在业务服务区范围内而不包含感兴趣的UE的eNB也应该收到MBMS会话开始消息。

具体地讲，参考图3C，对某个MBMS组播业务感兴趣的空闲状态的UE1和连接状态的UE2分别驻留在小区1和小区5中，TA2包含的小区3和小区4内没有对此业务感兴趣UE，小区1的相邻小区是小区2和小区3。此MBMS组播业务使用专用载频发送业务数据，在图3C所示的五个小区中，小区2没有配置专用载频。按照现有的方案，尽管eNB11、eNB12和eNB13都包含在SA的范围内，只有eNB11和eNB13能收到MBMS会话开始消息。所以，eNB12不可能在小区3和小区4的空中接口上发送任何MBMS信息。当UE1因为移动离开小区1时，因为缺乏小区3和小区4的专用载频信息，UE1在进行小区重选时，很可能选择没有配置专用载频的小区2。但是，考虑到接收业务的连续性，希望UE1能够小区重选到小区3。所以，本发明认为，在实际操作中，eNB12也应该收到MBMS会话开始消息，从而具备在SA的范围内的所有小区的空中接口上发送MBMS信息的能力，以备UE使用。本发明给出的是一个典型例子，并不限制网络，例如，eNB如何使用这些MBMS信息完成相应的功能等均不受限制。

因为eNB不保存空闲状态UE的信息，沿用3GPP Rel6的机制，aGW需要将包含已定制某个MBMS业务的空闲状态UE的TA列表通过MBMS会话开始消息发给eNB。根据此信息，eNB可以在SA的区域内进一步缩小需要触发通告过程的小区集合。

3GPP定义了使用专用载频发送EMBMS业务的可能性。专用载频可以是MBMS业务独享的，也可以是和单播业务共用的。如果运营商在网络中为EMBMS配置了专用载频，用户需要在空中接口上得知这个消息，以便能选择到正确的小区去接收某个业务。这就需要aGW在MBMS会话开始消息中携带专用载频信息。

所以，MBMS会话开始消息中可能携带如下信息：

1)业务标识；

2)业务类型(广播或组播)；

3)服务区域；

4)包含已定制某个业务的空闲状态用户设备的跟踪区域列表；

5)专用载频标识(可选，在MBMS业务被配置在专用载频上发送业务数据时包括)。

eNB从aGW接收到MBMS会话开始消息后，发送MBMS会话开始响应消息给aGW作为应答。

当包含已定制某个业务的空闲状态的UE的TA列表发生变化时，aGW利用MBMS会话更新消息通知eNB，MBMS会话更新消息携带列表的变化信息。MBMS会话更新消息的发送原则可以和MBMS会话开始消息的原则相同，即发送给在SA范围内的所有eNB；也可以不同，比如只发送给包含在变化的TA范围内的那些eNB。。

eNB在从aGW接收到MBMS会话更新消息后，发送MBMS会话更新响应消息给aGW作为应答。

图4是示出了根据本发明的接入网关的结构的方框图。

接入网关aGW1000包括接收/响应装置1001、确定单元1100、IP组播数据包处理单元1002、PDCP数据包处理单元1003、传输协议处理单元1004、发送装置1005，和存储单元1006。因为aGW1000具备路由功能，所以与其他设备相连的每个物理端口都具有传输协议处理单元1004和发送装置1005。

接收/响应装置1001用于接收来自BM-SC的MBMS会话开始消息，并将MBMS会话响应消息返回给BM-SC。此外，接收/响应装置1001用于通过Gi接口接收来自BM-SC的数据，并将接收到的数据还原成IP组播包并传输给IP组播数据包处理单元1002。

确定单元1100用于在接收/响应装置1001接收到来自BM-SC的针对一个MBMS业务的MBMS会话开始消息时，根据存储在存储单元1006中的SA与eNB的映射关系，确定与所述MBMS业务相关联的eNB。

IP组播数据包处理单元1002在接收到来自接收装置1001的IP组播包后，解析出IP组播地址，再将IP组播包传输给PDCP数据包处理单元1003。

PDCP数据包处理单元1003用来将接收到的数据封装成PDCP包再返回IP组播数据包处理单元1002。

通过查找存储在存储单元1006中的路由表，IP组播数据包处理单元1002知道应该把IP组播包转发至哪儿个传输协议处理单元1004，并通过发送装置1005，经由S1接口发送给需要接收MBMS业务数据的eNB。

此外，发送装置1005还根据来自确定单元1100的指示，向eNB发送MBMS会话开始消息。

接下来，将参照图5，对根据本发明的接入网关的处理操作进行详细的描述。

图5A是示出了接入网关的MBMS会话开始消息发送处理的流程图。

首先，在步骤S300，根据本发明的接入网关的MBMS会话开始消息的发送处理过程开始。在步骤S302，接收来自BM-SC的、针对MBMS业务的MBMS会话开始消息。然后，在步骤S304，将MBMS会话响应消息返回给BM-SC。接下来，在步骤S306，根据所存储的各个MBMS SA与各个eNB之间的映射关系(参见表1)，确定与所述MBMS业务相关联的eNB。在步骤S308，向所确定的eNB发送MBMS会话开始消息。在步骤S310，接入网关的MBMS会话开始消息的发送处理过程结束。

图5B是示出了对接入网关的数据包进行处理的流程图。

首先，在步骤S400，根据本发明的aGW的数据包处理开始。在步骤S402，aGW1000通过接收装置1001经由Gi接口从BM-SC接收业务数据，并将接收到的数据还原成IP组播包。之后，在步骤S404，通过IP组播数据包处理单元1002解析出IP组播地址，(这里假设aGW解出的IP组播地址为IP A)。然后，在步骤S408，通过PDCP数据包处理单元1003，按照PDCP的协议规范对IP组播包进行IP头压缩，以便保证空中接口上的传输效率。在步骤S410，通过IP组播数据包处理单元1002，对PDCP包进行传输层的IP组播封装，并使用IP地址＝IP A的IP数据包头。最后，在步骤S412，通过传输协议处理单元1004和发送装置1005，将IP组播包经由S1接口，通过物理连接发送给eNB。

在S1接口上引入IP组播之后，MBMS业务数据在S1接口上的分发就变得非常简单。根据IP组播的数据分发机制，aGW将封装好的IP组播数据包发往IP组播地址。这样，加入以这个地址为标识的IP组播组的所有eNB都能接收到IP组播数据包。

图6是示出了根据本发明的基站的结构的方框图。

eNB2000包括S1接口消息/数据接收装置2001、eNB控制器2100、IP组播数据包处理单元2002、通告过程处理单元2003(每个小区一个单元)、RB分配单元2004(每个小区一个单元)、状态信息组装单元2005(每个小区一个模块)、IP组播组处理单元2006、无线接口协议处理单元2007(每个小区一个单元)、发送装置2008和存储单元2009。

S1接口消息/数据接收装置2001用于通过S1接口接收来自aGW的消息和业务数据，并将接收到的各种消息和业务数据传输给eNB控制器2100。在接收到来自aGW的MBMS会话开始消息或MBMS会话更新消息后，S1接口消息/数据接收装置2001将MBMS会话响应消息返回给aGW。

eNB控制器2100判断是否需要触发通告过程处理单元2003、RB分配单元2004和状态信息组装单元2005的相应处理，并将接收到的业务数据传输给IP组播数据包处理单元2002。

通告过程处理单元2003用来在空中接口上发起通告过程，并将通告过程的结果返回给eNB控制器2100。

RB分配单元2004用来根据eNB控制器2100的指示，为某个MBMS业务分配RB，并将RB的配置信息告知状态信息组装单元2005。RB分配单元2004还用来判断是否需要触发IP组播组处理单元2006的相应处理。

状态信息组装单元2005，根据eNB控制器2100的指示，组装需要通过发送装置2008在空中接口上发送的状态信息和RB配置信息。

IP组播组处理单元2006用来触发eNB向aGW发起的加入或离开某个IP组播组的流程。

IP组播数据包处理单元2002用来从eNB控制器2100接收IP组播包。解析出IP组播包的内容后，将数据传输给无线接口协议处理单元2007。

无线接口协议处理单元2007用来将接收到的数据进行RLC(无线链路控制)、MAC(媒体接入控制)和物理层协议的处理，然后通过发送装置2008把业务数据经由空口接口发送给用户。

通过查找存储在存储单元2009中的SA和小区的映射关系，eNB控制器2100可以判断需要在哪些小区触发通告过程处理单元2003、RB分配单元2004和状态信息组装单元2005的相应处理。

通过查找存储在存储单元2009中的需要接收业务数据的小区的列表信息，IP组播数据包处理单元2002，可以判断需要将IP组播数据包传输给哪些小区的无线接口协议处理单元2007。

图7是示出了基站在收到MBMS会话开始消息后的处理的流程图。

首先，在步骤S600，根据本发明的eNB收到MBMS会话开始消息后的处理流程开始，S1接口消息/数据接收装置2001接收MBMS会话开始消息，并返回MBMS会话响应消息给aGW作为应答。在步骤S602，eNB控制器2100根据通过S1接口消息/数据接收装置2001接收到的MBMS会话开始消息，从eNB管理的某个小区开始，判断是否需要在当前小区发起通告过程。

如果在此小区不需要发起通告过程(步骤S602中的“否”)，在步骤S604，eNB控制器2100判断是否需要向小区分配承载业务数据的RB。如果不需要(步骤S604中的“否”)，eNB控制器2100在步骤S605判断是否需要发送业务状态信息(业务开始或正在进行)。如果需要发送此信息(步骤S605中的“是”)，eNB控制器2100在步骤S606告知状态信息组装单元2005，指示它在组装状态信息后，通过发送装置2008在空中接口上发送状态信息。如果不需要发送此信息(步骤S605中的“否”)，eNB控制器2100在步骤S612判断，是否已经对eNB管理的所有小区都进行过处理，如果是，则流程结束，否则，eNB控制器2100在步骤S614，转到下一个小区，然后返回步骤S602。

如果在此小区需要发起通告过程(步骤S602中的“是”)，在步骤S603，eNB控制器2100通知通告过程处理单元2003，指示它在此小区发起通告过程。在完成通告过程之后，通告过程处理单元2003将通告过程的结果返回给eNB控制器2100。根据通告过程的结果，eNB控制器2100在步骤S604判断是否要向当前小区分配RB。如果需要分配(步骤S604中的“是”)，eNB控制器2100在步骤S607指示RB分配单元2004，在本小区内为当前业务分配RB。之后，RB分配单元2004在步骤S608将RB的配置信息告知状态信息组装单元2005，并通过发送装置2008将RB配置信息通知给用户。同时，在步骤S609，RB分配单元2004触发IP组播组处理单元2006的判断，即判断eNB是否已经加入当前业务的IP组播组。如果已经加入(步骤S609中的“是”)，流程跳到步骤S612。如果eNB没有加入IP组播组(步骤S609中的“否”)，IP组播组处理单元2006在步骤S610向aGW发起申请加入IP组播组的流程，然后再执行步骤S612的处理。

图8是示出了基站在收到IP组播数据包的处理流程图。

首先，在步骤S800，根据本发明的eNB收到IP组播数据包后的处理流程开始。在步骤S802，IP组播数据包处理单元2002收到从eNB控制器2100来的IP组播包后，解析出IP组播包的内容。在步骤S804，通过查找存储在存储单元2009中的需要接收业务数据的小区的列表信息，IP组播数据包处理单元2002判断需要将IP组播数据包传输给哪些小区的无线接口协议处理单元2007。之后，在步骤S806，无线接口协议处理单元2007对从IP组播数据包处理单元2002收到的数据进行RLC、MAC和物理层协议的处理。在步骤S808，将处理过的数据通过发送装置2008经由空中接口传输给用户。

图9是用于详细解释本发明的、网络连接和规划的典型场景的示意图。

这里描述aGW如何发送MBMS会话开始消息，eNB在收到MBMS会话开始消息后如何处理。为了能够确定地描述问题可以假设一种典型的场景，如图9所示。为简化起见，这里不失一般性地给出了只有一个aGW参与业务数据发送的场景。

在该场景中不失一般性地假设：

1)小区1-5都属于MBMS业务A的SA区域；

2)小区1和2属于TA1，小区3和4属于TA2，小区5属于TA3；

3)aGW在发送MBMS会话开始消息给eNB之前，只有小区1有连接状态的对MBMS业务A感兴趣的用户UE01；

4)aGW在发送MBMS会话开始消息给eNB之前，小区4中驻留有对MBMS业务A感兴趣的空闲状态的用户UE02。

依照上面的假设，aGW将MBMS会话开始消息发往eNB11、eNB12和eNB13。MBMS会话开始消息中携带的“包含空闲用户的TA列表”信息是TA2。如果运营商给此业务配置了专用载频，MBMS会话开始消息还要携带专用载频的标识。

图9中的三个eNB11、eNB12和eNB13在收到MBMS会话开始消息后，都会在空中接口上发送业务开始的信息。如果MBMS会话开始消息携带了专用载频信息，eNB11、eNB12和eNB13都会在空中接口上发送MBMS业务使用的专用载频信息。

具体地，结合图4到图9，对本发明的具体实例进行详细的描述。eNB11、eNB12和eNB13在收到MBMS会话开始消息后，由于每个eNB11、eNB12和eNB13遇到的情况可能不同，他们的处理结果也可能不同。在图9给出的场景下，对三个eNB11、eNB12和eNB13的处理过程如下说明：

eNB11收到MBMS会话开始消息后，检测到小区1已经有连接状态的对MBMS业务A感兴趣的UE01，所以eNB11判断不需要在小区1发起通告过程，但需要为小区1分配RB。而eNB11管辖的小区1和2都不属于TA2，而且小区2内没有连接状态的对MBMS业务A感兴趣的UE，所以eNB1确定不需要在小区2中发起通告过程，也不需要分配RB，但需要在空中接口上发送业务开始的状态信息。既然eNB11在收到MBMS会话开始消息之前，就已经知道小区1有连接状态的对MBMS业务A感兴趣的UE01，eNB11必定已经是IP组播组的成员，这点是由IP组播组管理协议来保证的，不需要在本发明中详细解释。

eNB12在收到MBMS会话开始消息后，因为发现它管理的小区3和4属于TA2，eNB12在小区3和4都发起通告过程。通告过程的结果显示，只有小区4中有感兴趣的UE02，eNB12只给小区4分配RB，并在小区3的空中接口上发送业务开始的状态信息。如果eNB12发现自己不是IP组播组的成员，eNB12会向aGW发起加入IP组播组的请求消息。

eNB13在收到MBMS会话开始消息后，因为发现它管理的小区5不属于TA2，eNB13确定不需要在小区5发起通告过程，也不需要分配RB，但可以在空中接口上发送业务开始的状态信息。

eNB在收到MBMS会话更新消息后的处理流程和图7类似，在业务的进行过程中，如果有空闲状态的UE02从小区4移动到小区5，aGW会发现包含空闲状态的感兴趣的UE的TA列表发生了变化。aGW可以把变化的列表通过MBMS会话更新消息发给所有属于服务区范围的eNB11、eNB12和eNB13。aGW也可以把变化的列表通过MBMS会话更新消息只发给受到影响的eNB13。eNB13收到MBMS会话更新消息后，在小区5发起通告过程。如果通告过程的结果显示，小区5中有感兴趣的UE02，eNB13给小区5分配RB，如果eNB13发现自己不是IP组播组的成员，eNB13会向aGW发起加入IP组播组的请求消息。

本发明给出了引入IP组播之后涉及EMBMS网络结构的各网络节点的协议栈结构，明确了数据包从aGW发送到eNB时，需要做哪些处理。

与现有方案相比，根据本发明的MBMS会话开始处理流程是完备的。本发明充分考虑到eNB的功能需求，在消息中携带了足够的信息为eNB的功能实现和流程设计提供方便。本发明还为空中接口的流程设计提供更多的灵活性。

最后所应说明的是：以上实施例仅仅用以说明而非限制本发明的技术方案，尽管参照上述实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明进行修改或者等同替换，而不脱离本发明的精神和范围的任何修改或局部替换，其均应涵盖在本发明的权利要求范围当中。