Abstract:
The present invention provides an Evolved Multimedia Broadcast/Multicast Service (EMBMS) access gateway supporting network multicast, comprising: receiving/responding means for receiving a Multimedia Broadcast/Multicast Service (MBMS) Session Start message from a Broadcast/Multicast-Service Center (BM-SC) and for returning a response message to the BM-SC after receiving the MBMS Session Start message; storage means for storing a mapping relationship between respective MBMS service areas (SAs) and respective base stations; determining means for determining base station(s) associated with the MBMS based on the stored mapping relationship when the receiving/responding means receives the MBMS Session Start message; and transmitting means for transmitting the MBMS Session Start message to the determined bases station(s).

Description:
BACKGROUND OF THE INVENTION 
     1. Field of Invention 
     The present invention relates to the mobile communication field, especially, System Architecture Evolution/Long Term Evolution (SAE/LTE) in the 3G mobile communication field, and more particularly, to an Evolved Multimedia Broadcast/Multicast Service (EMBMS) access gateway, a base station, and methods thereof, which support Internet Protocol (IP) multicast. 
     2. Description of Prior Art 
     Current network architectures based on SAE/LTE are flatter than those before evolution. On one hand, a two-node architecture (base station NodeB+Radio Network Controller RNC) of radio access network portions is simplified into an one-node architecture (base station eNodeB, “eNB” for short hereinafter). On the other hand, mesh like connections are introduced. That is to say, one eNB may be connected to multiple access gateways (aGWs) via an S 1  interface, and one eNB may be connected to multiple neighboring eNBs via an X 2  interface. Such connections may be physical or logical. Two eNBs, if logically connected, may be physically connected via an aGW. The architecture of SAE/LTE is shown in  FIG. 1 . 
     Specifically, referring to  FIG. 1 , two access gateways aGW 1  and aGW 2  are connected to three base stations eNB 1 , eNB 2  and eNB 3  via S 1  interfaces respectively, and the three base stations eNB 1 , eNB 2  and eNB 3  are connected to each other via X 2  interfaces.  FIG. 1  shows a situation where there are physical connections between the respective nodes. If there is no X 2  interface connection between eNB 1  and eNB 3 , than eNB 1  may be connected to eNB 3  via aGW 1  or aGW 2 , so that there is a logical connection between eNB 1  and eNB 3 . 
     Specifications for SAE/LTE have been defined from the time of 3GPP Re17. In the architecture of SAE/LTE, MBMS is termed as EMBMS (Evolved-MBMS). Such flat architecture brings a new challenge to efficient transmission Multimedia Broadcast/Multicast Service (MBMS) data: whether to continue to use the GTP protocol (GPRS tunneling protocol) before the Re17 version in connecting eNBs and aGWs, or to introduce other techniques. In current discussions on 3GPP, it is proposed to introduce IP multicast into the architecture of broadcast/multicast service. However, in current specifications, how to connect an eNB and an aGW on a user plane has not been defined. That is to say, 3GPP has not defined protocol architecture on the S 1  interface. In the present invention, protocol architecture on the S 1  interface is provided and further how to transmit MBMS control information is discussed, and thereby an EMBMS access gateway, a base station and methods thereof, which support IP multicast, are provided. 
     Documents proposed by Nokia and Vodafone in the 52 nd  Conference of RAN3 in May, 2006 (R3-060652 MBMS aspects in SAE/LTE work, Nokia; R3-060694 Support of MBMS in E-UTRAN) show that they approve of introducing IP multicast into EMBMS, with some simple analyses on how to transmit EMBMS control information on the S 1  interface. For multicast services. Nokia proposes to transmit an MBMS Session Start message to eNBs included in a Service Area (“SA” for short hereinafter) and also included in a Tracking Area (“TA” hereinafter) hosting interested users. Vodafone proposes to transmit an MBMS Session Start message to eNBs included in a TA hosting interested users. Further, for broadcast services, both Nokia and Vodafone hold that an MBMS Session Start message should be transmitted to eNBs included in an SA. 
     However, the above two documents just proposed that IP multicast may be introduced into EMBMS, without any discussions on the protocol stack architecture and operations. Therefore, it is still unknown how to let IP multicast play a role in transmission of service data. 
     Therefore, there is a need for an EMBMS access gateway, a base station and methods thereof, which support IP multicast, and from which it can be known how to transmit EMBMS service data by means of IP multicast under the framework of SAE/LTE so that MBMS service data from an aGW arrive at an eNB more efficiently. 
     The above two documents, though giving a flow design scheme for EMBMS, have some problems in the technical aspects. For example, for multicast services, when an aGW select eNBs to which an MBMS Session Start message is transmitted, there may be a problem that some eNBs which indeed need receipt of the MBMS Session Start message actually do not receive such MBMS Session Start message. 
     Therefore, there is a need for an EMBMS access gateway, a base station and methods thereof supporting IP multicast, which on one hand enable an eNB to get sufficient information from an aGW, and on the other hand facilitate function implementation and flow design of the eNB in various possible situations. 
     SUMMARY OF THE INVENTION 
     It is an object of the present invention to provide an EMBMS access gateway supporting IP multicast, from which sufficient information can be obtained so that MBMS service data from the access gateway can arrive at eNBs more efficiently. The present invention also provides a corresponding base station and methods of operating the EMBMS access gateway and the base station for IP multicast. 
     According to an aspect of the invention, there is provided an Evolved Multimedia Broadcast/Multicast Service (EMBMS) access gateway supporting network multicast, comprising: receiving/responding means for receiving a Multimedia Broadcast/Multicast Service (MBMS) Session Start message from a Broadcast/Multicast-Service Center (BM-SC) and for returning a response message to the BM-SC after receiving the MBMS Session Start message; storage means for storing a mapping relationship between respective MBMS service areas (SAs) and respective base stations; determining means for determining base station(s) associated with the MBMS based on the stored mapping relationship when the receiving/responding means receives the MBMS Session Start message; and transmitting means for transmitting the MBMS Session Start message to the determined bases station(s). 
     According to another aspect of the invention, there is provided a method of operating an Evolved Multimedia Broadcast/Multicast Service (EMBMS) access gateway supporting network multicast, comprising steps of: receiving a Multimedia Broadcast/Multicast Service (MBMS) Session Start message with respect to a multimedia broadcast/multicast service from a Broadcast/Multicast-Service Center (BM-SC); returning a response message to the BM-SC after receiving the MBMS Session Start message; determining base station(s) associated with the multimedia broadcast/multicast service based on a stored mapping relationship between respective MBMS service areas (SAs) and respective base stations; and transmitting the MBMS Session Start message to the determined bases station(s). 
     According to still another aspect of the invention, there is provided an Evolved Multimedia Broadcast/Multicast Service (EMBMS) access gateway supporting network multicast, comprising: storage means for storing a routing table; receiving means for receiving data from a Broadcast/Multicast-Service Center (BM-SC) and for converting the received data back to Internet Protocol (IP) multicast packets; Packet Data Convergence Protocol (PDCP) packet processing means for packaging the IP multicast packets into PDCP packets; IP multicast packet processing means for extracting an IP multicast address from the converted IP multicast packets, re-packaging the packaged PDCP packets into IP multicast packets with the extracted IP multicast address as the IP multicast address, and determining base station(s) to receive the re-packaged IP multicast packets based on the extracted IP multicast address and the stored routing table; one or more transport protocol processing means, associated with respective base stations respectively, for processing the re-packaged IP multicast packets based on corresponding transport protocol(s); and one or more transmitting means, associated with respective base stations respectively, for transmitting the packets which have been processed based on the corresponding transport protocol(s) to the determined base station(s). 
     According to still another aspect of the invention, there is provided a method of operating an Evolved Multimedia Broadcast/Multicast Service (EMBMS) access gateway supporting network multicast, comprising steps of: receiving data from a Broadcast/Multicast-Service Center (BM-SC), and converting the received data back to Internet Protocol (IP) multicast packets; extracting an IP multicast address from the converted IP multicast packets; packaging the received IP multicast packets into Packet Data Convergence Protocol (PDCP) packets; re-packaging the PDCP packets into IP multicast packets with the extracted IP multicast address as the IP multicast address; determining base station(s) to receive the re-packaged IP multicast packets based on the extracted IP multicast address and a stored routing table; processing the re-packaged IP multicast packets based on corresponding transport protocol(s); and transmitting the packets which have been processed based on the corresponding transport protocol(s) to the determined base station(s). 
     According to still another aspect of the invention, there is provided an Evolved Multimedia Broadcast/Multicast Service (EMBMS) base station supporting network multicast, comprising: receiving/responding means for receiving a Multimedia Broadcast/Multicast Service (MBMS) Session Start message and an MBMS Session Update message from an access gateway (aGW), and for returning a response message to the aGW; storage means for storing a mapping relationship between respective MBMS service areas (SAs) and respective cells managed by the base station; notification procedure processing means for initiating a notification procedure in a desired cell and returning a result of the notification procedure; transmitting means for transmitting various information and data to the respective cells; and base station controller for controlling operations of the base station, and determining whether to initiate a notification procedure or not in each of the managed cells based on the received MBMS Session Start message or MBMS Session Update message and the stored mapping relationship. 
     According to still another aspect of the invention, there is provided a method of operating an Evolved Multimedia Broadcast/Multicast Service (EMBMS) base station supporting network multicast, comprising steps of: receiving a Multimedia Broadcast/Multicast Service (MBMS) Session Start message and an MBMS Session Update message from an access gateway (aGW), and returning a response message to the aGW; with respect to each of cells managed by the base station, carrying out the following operations based on the received MBMS Session Start message and MBMS Session Update message and a stored mapping relationship: determining whether it is necessary to initiate a notification procedure in this cell, and initiating the notification procedure if it is necessary and waiting for a result of the notification procedure; determining whether it is necessary to allocate a radio bearer (RB) to this cell; allocating the RB to this cell if it is necessary, and informing a user equipment (UE) of the RB configuration information; and determining whether it is necessary to transmit state information of the multimedia broadcast/multicast service if it is not necessary to allocate an RB to this cell, and transmitting the state information if it is necessary. 
     According to still another aspect of the invention, there is provided an Evolved Multimedia Broadcast/Multicast Service (EMBMS) base station supporting network multicast, comprising: receiving means for receiving Multimedia Broadcast/Multicast Service (MBMS) data from an access gateway (aGW); storage means for storing a mapping relationship between respective MBMS service areas (SAs) and respective cells managed by the base station; Internet Protocol (IP) multicast packet processing means for receiving IP multicast packets, extracting contents of the IP multicast packets, and determining cell(s) to receive the contents of the IP multicast packets based on the stored mapping relationship; radio interface protocol processing means, associated with the respective cells managed by the base station, for carrying out radio interface protocol processing on the data from the IP multicast packet processing means, and supplying the processed data to transmitting means; the transmitting means for transmitting various information and data to the respective cells; and a base station controller for controlling the storage means and the IP multicast packet processing means, and supplying the IP multicast packets received by the receiving means to the IP multicast packet processing means. 
     According to still another aspect of the invention, there is provided a method of operating an Evolved Multimedia Broadcast/Multicast Service (EMBMS) base station supporting network multicast, comprising steps of: receiving Multimedia Broadcast/Multicast Service (MBMS) service data from an access gateway (aGW); receiving Internet Protocol (IP) multicast packets, and extracting contents of the IP multicast packets; determining cell(s) to receive the contents of the IP multicast packets based on a stored mapping relationship between respective MBMS service areas (SAs) and respective cells managed by the base station; carrying out radio interface protocol processing on the contents of the IP multicast packets; and transmitting the processed data to the determined cell(s). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred embodiments of the present invention will be described in detail hereinafter with reference to attached drawings, wherein: 
         FIG. 1  is a schematic view showing a network architecture of SAE/LTE; 
         FIG. 2  is a schematic view showing protocol stack architectures of network nodes wherein IP multicast has been introduced; 
         FIG. 3A  is a time sequence chart showing a procedure of MBMS service initiation; 
         FIG. 3B  is a schematic view for explaining to which eNBs an MBMS Session Start message should be transmitted; 
         FIG. 3C  is a schematic view for explaining to which eNBs an MBMS Session Start message should be transmitted; 
         FIG. 4  is a block diagram showing an access gateway according to the present invention; 
         FIG. 5A  is a flow chart showing a process of transmitting an MBMS Session Start message by the access gateway; 
         FIG. 5B  is a flow chart showing the process on packets by the access gateway; 
         FIG. 6  is a block diagram showing a base station according to the present invention; 
         FIG. 7  is a flow chart showing the process of the base station after receiving an MBMS Session Start message; 
         FIG. 8  is a flow chart showing the process of the base station after receiving IP multicast packets; and 
         FIG. 9  is a schematic view showing an exemplary scenario of network connections and plans for explaining the present invention in detail. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     Hereinafter, embodiments of the present invention are explained with reference to the drawings. It is to be noted that the embodiments are just provided for the purpose of illumination, rather than limitation on the invention. Various numeral values provided here are not intended to limit the present invention, and may be modified by those skilled in the art as desired. 
       FIG. 2  is a schematic view showing protocol stack architectures of network nodes wherein IP multicast has been introduced. 
     On a user plane, since IP multicast is to be introduced into a base station (eNB). IP multicast may serve as a bearer protocol of user plane data for an S 1  interface. Thus, protocol stacks of respective nodes are shown as  FIG. 2 . A Broadcast/Multicast-Service Center (BM-SC) has same functions as BM-SC in 3GPP Re 16. An access gateway (aGW) is connected to the BM-SC via a Gi interface. 
     The whole transfer of MBMS services involves two layers of IP multicast packaging. The first layer relates to the application layer, and is identified at the side of BM-SC, aGW and UE. The second layer relates to the transport layer at the S 1  interface, with a protocol architecture shown by hatching portions in  FIG. 2 . Under the IP multicast protocol layer, there are other transport layer protocols, which are totally indicated as Transport Network Layer (TNL) in  FIG. 2 . In the present invention, there is no specific limitation on the protocol stacks of these transport layer protocols, and the transport network layer protocol stacks in the existing specifications may be followed. 
     After receiving IP multicast packets, a standard IP multicast router forwards the received IP multicast packets to an IP multicast address, without performing additional process. However, when IP multicast is introduced into EMBMS, since PDCP (Packet Data Convergence Protocol) is implemented in the first layer of the aGW, it is necessary to carry out re-packaging, on basis of PDCP packets, for IP multicast at the second layer of the aGW. Therefore, in a transmission path of IP multicast, the aGW is no more a standard IP multicast router, and it must parse the IP multicast address from the received IP multicast packets and then carry out packaging for IP multicast at the second layer with use of the IP multicast address. After that, the IP multicast packets are distributed to all eNBs which need the IP multicast packets by means of routing. For different services, the aGW may need to distribute the data to different eNBs. This is guaranteed by the IP multicast group management protocol and a routing table, which have no relation to the present invention, and detailed descriptions of which are omitted. 
       FIG. 3A  is a time sequence chart showing a procedure of MBMS service initiation. 
     As shown in  FIG. 3A , on the control plane, the initiation of MBMS service is informed to a downstream node by an upstream node by means of MBMS Session Start. 
     After receiving the MBMS Session Start message from the BM-SC, the aGW returns an MBMS Session Start Response message as a replay to the BM-SC. Then, the aGW judges which eNB(s) connected thereto to obtain the MBMS Session Start message. Here. EMBMS follows the principle of MBMS, that is, to provide a service to users within a predefined geographic area (which area is termed as Service Area SA). Different services may have different SAs. This is because one same geographic area may be covered by several cells of different levels when operators make the network plans. 
     In the present invention, if an eNB at least includes a cell belonging to an SA of an MBMS service, then this eNB needs to receive an MBMS Session Start message for this service. 
     For example,  FIG. 3B  is a schematic view for explaining to which eNBs the MBMS Session Start for MBMS service  1  should be transmitted. For eNB 11 , though it has only cell  1  belonging to SA 1  and cell  2  not belonging to SA 1 , it must receive the MBMS Session Start message. For eNB 12 , with cells  3  and  4  both belonging to SA 1 , it should receive the MBMS Session Start message. However, for eNB 13  managing cell  5  which does not belong to SA 1 , it needs not to receive the MBMS Session Start message. 
     This also means that the aGW must keep a mapping relationship between SAs and eNBs (referring to Table 1). The aGW may obtain the mapping relationship between SAs and eNBs in various ways. For example, an operator may maintain a mapping table of SAs to cells and a mapping table about cells managed by respective eNBs at an OMC (Operation, Management, Control) device. Then, the mapping relationship between SAs and eNBs may be inferred from these two mapping tables, and is informed to the aGW by means of a static configuration at initialization of the aGW. The OMC device may also, at initiation of a session for an MBMS service, infer the mapping relationship between SAs and eNBs with respect to this MBMS service from these two mapping tables, and than inform the aGW of this relationship. However, in the present invention, the ways in which the aGW obtains the above mapping relationship are not limited. 
     For example, in the situation as shown in  FIG. 3B , the aGW may keep the following mapping relationship (Table 1): 
     
       
         
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Service Area (SA) 
                 Base Station (eNB) 
               
               
                   
                   
               
             
             
               
                   
                 SA1 
                 eNB11, eNB12 
               
               
                   
                 SA2 
                 eNB11, eNB13 
               
               
                   
                   
               
             
          
         
       
     
     In the MBMS Session Start message, the aGW should inform the eNB of the SA. Since the eNB keep the mapping relationship between SAs and cells (referring to Table 2), the eNB may transmit state information that the service is initiated or the service is ongoing on air interfaces of the cells managed thereby. For multicast service, such information may trigger a notification procedure, and further trigger a counting or voting procedure on the air interfaces. These procedures may be triggered by the network or by a User Equipment (UE) voluntarily. By these procedures, the eNB is able to judge whether a cell hosts an interested user or not, and further judge whether it is necessary to establish a Radio Bearer (RB) for this service in this cell. In the present invention, the eNB itself determines situations under which the state information that the service is initiated or the service is ongoing should be transmitted, depending on the implementations of the eNB. The eNB may flexibly use such information to achieve the desired functions. 
     For example, in the situation as shown in  FIG. 3B , eNB 11 -eNB 13  may keep the following mapping relationship (Table 2). 
     
       
         
               
               
               
             
               
             
               
               
               
             
               
             
               
               
               
             
               
             
               
               
               
             
           
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 SA 
                 Cell 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                 eNB11 
               
             
          
           
               
                   
                 SA1 
                 Cell1 
               
               
                   
                 SA2 
                 Cell2 
               
             
          
           
               
                 eNB12 
               
             
          
           
               
                   
                 SA1 
                 Cell3, Cell4 
               
               
                   
                 SA2 
                 — 
               
             
          
           
               
                 eNB13 
               
             
          
           
               
                   
                 SA1 
                 — 
               
               
                   
                 SA2 
                 Cell5 
               
               
                   
                   
               
             
          
         
       
     
     Existing solutions propose to transmit the MBMS Session Start message to eNB(s) included in a TA hosting interested UE(s). However, eNB(s) which is/are included in the service area but do/does not host any interested UE should receive the MBMS Session Start message too. 
     Specifically, referring to  FIG. 3C , UE  1  in idle state and UE  2  in connection state, which both are interested in an MBMS multicast service, reside in cell  1  and cell  5  respectively. There is no UE interested in this service in cell  3  and cell  4  included in TA  2 . Cell  1  is in neighbor to cell  2  and cell  3 . This MBMS multicast service transmits service data by a dedicated carrier. Among 5 cells shown in  FIG. 3C , cell  2  has no dedicated carrier configured thereto. According to the prior art, though eNB 11 , eNB 12  and eNB 13  are all within the SA, only eNB 11  and eNB 13  can receive the MBMS Session Start message. Therefore, eNB 12  cannot transmit any MBMS information on the air interfaces of cell  3  and cell  4 . When UE  1  moves away from cell  1 , since there is no information on the dedicated carriers of cell  3  and cell  4 , it is likely that UE  1  will select cell  2 , which has no dedicated carrier configured thereto, in cell reselecting. However, to ensure the continuity of service receiving, it is desired that UE  1  will select cell  3  in cell reselecting. Therefore, according to the present invention, eNB 12  should receive the MBMS Session Start message in practical operations, so that there is an ability to transmit the MBMS information for use by the UEs on the air interfaces of all cells within the SA. Here, only an exemplary example is provided, the networks are not limited. For example, ways in which the eNBs use the MBMS information to achieve corresponding functions are not limited. 
     Because the eNBs do not keep the information on the UEs in idle state, following the mechanism of 3GPP Re 16, the aGW must transmit a list of TA(s) hosting UE(s) in idle state, which has/have subscribed an MBMS service, to the eNBs by means of the MBMS Session Start message. Based on this information, the eNBs may further narrow down the group of cells in which the notification procedure should be triggered. 
     3GPP has defined the possibility of transmitting an EMBMS service by means of a dedicated carrier. The dedicated carrier may be exclusively used by the MBMS service, or may be shared with a unicast service. If the operator has configured a dedicated carrier for EMBMS in the network, then the users should know this information on the air interfaces, so as to be capable of selecting a proper cell to receive the service. Thus, the aGW should include the information on the dedicated carrier in the MBMS Session Start message. 
     Therefore, the MBMS Session Start message may contain following information:
     1) Service ID;   2) Service type (broadcast or multicast);   3) Service Area;   4) a list of TA(s) hosting UE(s) in idle state, which has/have subscribed a service; and   5) Dedicated carrier ID (optional, included if an MBMS service is configured to transmit service data by a dedicated carrier).   

     After receiving the MBMS Session Start message from the aGW, the eNBs transmit an MBMS Session Start Response message as a reply to the aGW. 
     When the list of TA(s) hosting UE(s) in idle state, which has/have subscribed a service, is changed, the aGW notify this to the eNBs by means of an MBMS Session Update message. The MBMS Session Update message carries the information on the change of the list. The principle to transmit the MBMS Session Update message may be same as that to transmit the MBMS Session Start message, that is, to transmit it to all eNBs within the SA; or they may be different, and for example, it may be only transmitted to eNBs included in the TA(s) which has/have changed. 
     After receiving the MBMS Session Update message from the aGW, the eNBs transmit an MBMS Session Update Response message as a replay to the aGW. 
       FIG. 4  is a block diagram showing an access gateway according to the present invention. 
     The access gateway aGW  1000  comprises receiving/responding means  1001 , a determining unit  1100 , an IP multicast packet processing unit  1002 , a PDCP packet processing unit  1003 , a transport protocol processing unit  1004 , transmitting means  1005  and a storage unit  1006 . Since the aGW  1000  has the function of routing, there are the transport protocol processing unit  1004  and the transmitting means  1005  at each physical port through which it is connected to another device. 
     The receiving/responding means  1001  is adapted to receive an MBMS Session Start message from the BM-SC, and to return an MBMS Session Start Response message to the BM-SC. Further, the receiving/responding means  1001  is adapted to receive data from the BM-SC via the Gi interface, and to convert the received data back to IP multicast packets, which in turn are transmitted to the IP multicast packet processing unit  1002 . 
     The determining unit  1100  is adapted to determine, when the receiving/responding means  1001  receives an MBMS Session Start message with respect to an MBMS service, eNB(s) associated with the MBMS service based on a mapping relationship between SAs and eNBs stored in the storage unit  1006 . 
     After receiving the IP multicast packets from the receiving means  1001 , the IP multicast packet processing unit  1002  parses the IP multicast address, and then transmits the IP multicast packets to the PDCP packet processing unit  1003 . 
     The PDCP packet processing unit  1003  is adapted to package the received data into PDCP packets, which in turn are returned to the IP multicast packet processing unit  1002 . 
     By looking up a routing table stored in the storage unit  1006 , the IP multicast packet processing unit  1002  knows to which transport protocol processing unit(s)  1004  the IP multicast packets should be forwarded, which then are transmitted to the eNB(s) which need(s) to receive the MBMS service data by means of the transmitting means  105  via the S 1  interface. 
     Further, the transmitting means  1005  transmits the MBMS Session Start message to the eNB(s) based on the instruction from the determining unit  1100 . 
     Next, the operations of the access gateway according to the present invention will be described in detail with reference to  FIG. 5 . 
       FIG. 5A  is a flow chart showing a process of transmitting an MBMS Session Start message by the access gateway according to the present invention. 
     First, at step S 300 , the process of transmitting an MBMS Session Start message by the access gateway according to the present invention is started. As step S 302 , an MBMS Session Start message with respect to an MBMS service is received from the BM-SC. Then, at step S 304 , an MBMS session response message is returned to the BM-SC. Next, at step S 306 , eNB(s) associated with the MBMS service is/are determined based on the stored mapping relationship between respective MBMS SAs and respective eNBs (referring to Table 1). As step S 308 , the MBMS Session Start message is transmitted to the determined eNB(s). At step S 310 , the process of transmitting an MBMS Session Start message by the access gateway is ended. 
       FIG. 5B  is a flow chart showing the process on packets by the access gateway. 
     First, at step S 400 , the process on packet by the aGW according to the present invention is started. At step S 402 , the aGW  1000  receives the service data from the BM-SC via the Gi interface by means of the receiving means  1001 , and converts the received data back to IP multicast packets. Then, at step S 404 , the IP multicast address is parsed by the IP multicast packet processing unit  1002  (here it is assumed that the IP multicast address parsed by the aGW is IP A). Then, at step S 408 , the PDCP packet processing unit  1003  carries out IP header compression on the IP multicast packets based on the PDCP protocol specifications, so as to ensure the efficiency of transmission on the air interface. At step S 410 , the IP multicast packet processing unit  1002  carries out IP multicast packaging at the transport layer on the PDCP packets, with an IP header having IP address=IP A. Finally, at step S 412 , the IP multicast packets are transmitted to the eNB(s) over physical connections via the S 1  interface by means of the transport protocol processing unit  1004  and the transmitting means  1005 . 
     After IP multicast is introduced into the S 1  interface, the distribution of the MBMS service data on the S 1  interface is simplified. Based on the data distribution mechanism of IP multicast, the aGW distributes the packaged IP multicast packets to the IP multicast address. Thus, all the eNBs joining an IP multicast group, which is identified by this address, will receive the IP multicast packets. 
       FIG. 6  is a block diagram showing a base station according to the present invention. 
     The eNB  2000  comprises S 1  interface message/data receiving means  2001 , an eNB controller  2100 , an IP multicast packet processing unit  2002 , a notification procedure processing unit  2003  (one unit per cell), an RB allocating unit  2004  (one unit per cell), a state information assembling unit  2005  (one module per cell), an IP multicast group processing unit  2006 , a radio interface protocol processing unit  2007  (one unit per cell), transmitting means  2008  and a storage unit  2009 . 
     The S 1  interface message/data receiving means  2001  is adapted to receive messages and service data from the aGW via the S 1  interface, and to transmit the received messages and service data to the eNB controller  2100 . After receiving an MBMS Session Start message or an MBMS Session Update message from the aGW, the S 1  interface message/data receiving means  2001  returns an MBMS Session Response message to the aGW. 
     The eNB controller  2100  judges whether it is necessary to trigger corresponding processes of the notification procedure processing unit  2003 , the RB allocating unit  2004  and the state information assembling unit  2005  or not, and transmits the received service data to the IP multicast packet processing unit  2002 . 
     The notification procedure processing unit  2003  is adapted to initiate a notification procedure on the air interface, and to return a result of the notification procedure to the eNB controller  2100 . 
     The RB allocating unit  2004  is adapted to allocate an RB to an MBMS service based on an instruction from the eNB controller  2100 , and to inform the RB configuration information to the state information assembling unit  2005 . The RB allocating unit  2004  is further adapted to judge whether it is necessary to trigger corresponding processes of the IP multicast group processing unit  2006 . 
     The state information assembling unit  2005  assembles the state information and the RB configuration information, which are to be transmitted on the air interface by the transmitting means  2008 , based on an instruction from the eNB controller  2100 . 
     The IP multicast group processing unit  2006  is adapted to trigger a procedure of joining or leaving an IP multicast group initiated by the eNB towards the aGW. 
     The IP multicast packet processing unit  2002  is adapted to receive the IP multicast packet from the eNB controller  2100 . After parsing the IP multicast packet, it transmits the data to the radio interface protocol processing unit  2007 . 
     The radio interface protocol processing unit  2007  is adapted to carry out processing of RLC (Radio Link Control), MAC (Media Access Control) and physical layer protocols on the received data, and then to transmit the service data to the users via the air interface by means of the transmitting means  2008 . 
     By looking up the mapping relationship between SAs and cells stored in the storage unit  2009 , the eNB controller  2100  is able to determine cells in which the corresponding processes of the notification procedure processing unit  2003 , the RB allocating unit  2004  and the state information assembling unit  2005  should be triggered. 
     By looking up a list of cells, which need to receive the service data, stored in the storage unit  2009 , the IP multicast packet processing unit  2002  is able to determine cell(s) to the radio interface protocol processing unit(s)  2007  of which the IP multicast packets should be transmitted. 
       FIG. 7  is a flow chart showing the process of the base station after receiving an MBMS Session Start message. 
     First, at step S 600 , the process of the eNB according to the present invention after receiving an MBMS Session Start message is stated, wherein the S 1  interface message/data receiving means  2001  receives an MBMS Session Start message and returns an MBMS Session Response message as a reply to the aGW. At step S 602 , the eNB controller  2100  judges whether it is necessary to initiate a notification procedure in a current cell, starting from one of the cells managed by the eNB, based on the MBMS Session Start message received by the S 1  interface message/data receiving means  2001 . 
     If there is no need to initiate a notification procedure in this cell (“No” in step S 602 ), then at step S 604 , the eNB controller  2100  judges whether it is necessary to allocate an RB carrying the service data to this cell. If no (“No” in step S 604 ), then at step S 605 , the eNB controller  2100  judges whether it is necessary to transmit service state information (the service is initiated or is ongoing). If it is necessary to transmit such information (“Yes” in step S 605 ), then at step S 606 , the eNB controller  2100  informs the state information assembling unit  2005  to instruct it to transmit the state information on the air interface by means of the transmitting means  2008  after assembling the state information. If there is no need to transmit such information (“No” in step S 605 ), then at step S 612 , the eNB controller  2100  judges whether all the cells managed by the eNB have been processed. If so, then this flow ends; or otherwise, the eNB controller  2100  proceeds to a next cell at step S 614 , and then returns to step S 602 . 
     If it is necessary to initiate a notification procedure in this cell (“Yes” in step S 602 ), then at step S 603 , the eNB controller informs the notification procedure processing unit  2003  to instruct it to initiate the notification procedure in this cell. After the notification procedure is completed, the notification procedure processing unit  2003  returns the result of the notification procedure to the eNB controller  2100 . Based on the result of the notification procedure, the eNB controller  2100  judges whether or not it is necessary to allocate an RB to the current cell at step S 604 . If it is necessary to allocate the RB (“Yes” in step S 604 ), then at step S 607 , the eNB controller  2100  instructs the RB allocating unit  2004  to allocate the RB for the current service in this cell. Then, at step S 608 , the RB allocating unit  2004  informs the state information assembling unit  2005  of the RB configuration information, and also informs the users of the RB configuration information by means of the transmitting means  2008 . At the same time, at step S 609 , the RB allocating unit  2004  triggers judgment by the IP multicast group processing unit  2006 , that is, to judge whether the eNB has joined an IP multicast group of the current service or not. If the eNB has joined the group (“Yes” in step S 609 ), then the flow proceeds to step S 612 . If the eNB has not joined the IP multicast group (“No” in step S 609 ), then at step S 610 , the IP multicast group processing unit  2006  makes an application for joining the IP multicast group to the aGW, and then the flow proceeds to step S 612 . 
       FIG. 8  is a flow chart showing the process of the base station after receiving IP multicast packets. 
     First, at step S 800 , the process of the eNB according to the present invention after receiving IP multicast packets is started. At step S 802 , the IP multicast packet processing unit  2002  receives the IP multicast packets from the eNB controller  2100 , and then parses contents of the IP multicast packets. At step S 804 , by looking up a list of cells, which need to receive the service data, stored in the storage unit  2009 , the IP multicast packet processing unit  2002  determines cell(s) to the radio interface protocol processing unit(s)  2007  of which the IP multicast packets should be transmitted. Then, at step S 806 , the radio interface protocol processing unit(s)  2007  carries(carry) out processing of RLC, MAC and physical layer protocols on the data received from the IP multicast packet processing unit  2002 . At step S 808 , the processed data are transmitted to the users over the air interfaces by means of the transmitting means  2008 . 
       FIG. 9  is a schematic view showing an exemplary scenario of network connections and plans for explaining the present invention in detail. 
     Here, descriptions on how an aGW transmits an MBMS Session Start message and how an eNB carries out processing when receiving the MBMS Session Start message are provided. To make a definite analysis, a typical scenario is assumed, as shown in  FIG. 9 . For simplification, there is provided a scenario where just one aGW is involved in transmission of service data, without losing generality. 
     Without losing generality, in this scenario it is assumed that:
     1) cells  1 - 5  all belong to SA of an MBMS service A;   2) cells  1  and  2  belong to TA 1 , cells  3  and  4  belong to TA 2 , and cell  5  belongs to TA 3 ;   3) only cell  1  hosts a user UE 01  which is in connection state and is interested in the MBMS service A, before the aGW transmits an MBMS Session Start message to the eNB; and   4) a user UE 02  which is in idle state and is interested in the MBMS service A resides in cell  4 , before the aGW transmits an MBMS Session Start message to the eNB.   

     Based on the above assumption, the aGW transmits the MBMS Session Start message to eNB 11 , eNB 12  and eNB 13 . The MBMS Session Start message contains information about “a list of TA(s) hosting idle user(s)” which indicates “TA 2 ”. If the operator configures a dedicated carrier for this service, then the MBMS Session Start message also contains an ID of the dedicated carrier. 
     All three of eNB 11 , eNB 12  and eNB 13  shown in  FIG. 9  transmit information that the service is initiated on the air interfaces, after receiving the MBMS Session Start message. If the MBMS Session Start message carries information on the dedicated carrier, eNB 11 , eNB 12  and eNB 13  will transmit the information on the dedicated carrier for use by the MBMS service on the air interfaces. 
     Specifically, with reference to  FIGS. 4-9  in combination, the embodiment of the present invention is described in detail. After receiving the MBMS Session Start message, eNB 11 , eNB 12  and eNB 13  may carry out different processes, depending on their respective situations. In the scenario shown in  FIG. 9 , the processes of eNB 11 , eNB 12  and eNB 13  are as follows. 
     After receiving the MBMS Session Start message, eNB 11  detects that cell  1  hosts UE 01  which is in connection state and is interested in the MBMS service A, and thus eNB 11  determines that there is no need to initiate a notification procedure in cell  1  but it is necessary to allocate an RB to cell  1 . However, cells  1  and  2  managed by eNB 11  do not belong to TA 2  and there is no UE which is in connection state and is interested in the MBMS service A in cell  2 , so eNB 11  determines there is no need to initiate a notification procedure in cell  2  and also there is no need to allocate an RB, but it is necessary to transmit state information that the transmission of the service is initiated on the air interface. Since eNB 11  knows cell  1  hosts UE 1 , which is in connection state and is interested in the MBMS service A, before receiving the MBMS Session Start message, eNB 11  must have already been a member of the IP multicast group. This is ensured by the IP multicast group management protocol, and is omitted in the present application. 
     After receiving the MBMS Session Start message, eNB 12  initiates notification procedures in both cell  3  and cell  4  because it finds cells  3  and  4  managed thereby belong to TA 2 . The result of the notification procedures shows that only cell  43  hosts interested UE  02 . eNB 12  only allocates an RB to cell  4 , and transmits the state information that the transmission of the service is initiated on the air interface of cell  3 . If eNB 12  finds it is not a member of the IP multicast group, eNB 12  will transmit a request for joining the IP multicast group to the aGW. 
     After receiving the MBMS Session Start message, eNB 13  determines there is no need to initiate a notification procedure in cell  5  and also there is no need to allocate an RB, but the state information that the transmission of the service is initiated may be transmitted on the air interface, because it finds cell  5  managed thereby does not belong to TA 2 . 
     The processes of the eNBs after receiving the MBMS Session Update message are similar to those shown in  FIG. 7 . During the progress of the service, if UE 02  in idle state moves from cell  4  to cell  5 , the aGW will find the list of TA(s) hosting interested UE(s) which is/are in idle state has changed. The aGW may transmit the changed list to all of eNB 11 , eNB 12  and eNB 13  belonging to the service area by means of the MBMS Session Update message. Alternatively, the aGW may transmit the changed list only to eNB 13  which is affected by means of the MBMS Session Update message. After receiving the MBMS Session Update message, eNB 13  initiates a notification procedure in cell  5 . If the result of the notification procedure shows that cell  5  hosts interested UE 02 , then eNB 13  allocates an RB to cell  5 . If eNB 13  finds it is not a member of the IP multicast group, eNB 13  will make a request for joining the IP multicast group to the aGW. 
     The present invention has provided respective protocol stack architectures for respective network nodes of the EMBMS network architecture after IP multicast is introduced therein, and has defined processes to be carried out when data packets are transmitted from an aGW to an eNB. 
     As compared with the prior art, the process of MBMS session start is more complete. In the present invention, functional requirements of eNBs are fully taken into account, and sufficient information is carried in messages, resulting in convenience in function implementation and flow design of the eNBs. Further, according to the present invention, it is possible to provide more flexibility in flow design of air interfaces. 
     It is to be noted that the above embodiments are provided just for illustration rather than limitation on the present invention. Though the present invention is described in detail with reference to the above embodiments, it is to be understood by those skilled in the art that modifications or equivalents may be made thereto. Any modifications or partial substitutions without departing from the spirit and scope of the present invention all fall into the scope defined by the appended claims.