2. Description of the Related Art Multimedia Broadcast and Multicast Service (hereinafter referred to as MBMS) is a new service under standardization by 3rd Generation Partnership Project (hereinafter referred to as 3GPP). The MBMS service is a unidirectional point-to-multipoint (p-t-m) service, whose most remarkable characteristic is that it can make use of radio resources and network resources efficiently.

Figure 1 describes the system structure of the MBMS. As shown in Figure 1, the MBMS network structure adds new network elements based on the core network of General Packet Radio Service (hereinafter referred to as GPRS). Broadcast and multicast service center 101 (hereinafter referred to as BM-SC) is a service control center of MBMS system. Gateway GPRS Supporting Node 102 (hereinafter referred to as GGSN) and Service GPRS Supporting Node 103 (hereinafter referred to as SGSN) compose the transmission network of MBMS service and provide route for data transmission. UMTS Terrestrial Radio Access Network 104 (hereinafter referred to as RAN) provides radio resources for the MBMS service over the air-interface. User Equipment 105 (hereinafter referred to as UE) is a terminal device used for receiving data. Home Location Register 106 (hereinafter referred to as HLR) saves the data related to the user and can provide services like the authentication of user. 107 Gn/Gp represents the interface between the SGSN and the GGSN. 108 Gi represents the interface between the BM-SC and the GGSN, and the interface protocol is Internet Group Management Protocol (hereinafter referred to as IGMP). 109 Gmb represents the interface between the BM-SC and the GGSN, and the interface protocol is dedicated to the transmission of the MBMS signaling parameters. Radio resources used by the MBMS service are not dedicated for one user, but are shared by all users using this service.

In the prior art, only the start time (almost the time when the real data is transmitted) of the MBMS is advertised in the MBMS service advertisement, and the UE can join in or leave the MBMS service at any time. It is disadvantageous that the certain network

resources have to be allocated to the UE even if there is no MBMS service at some time (e. g. , some MBMS service terminated in a short time) or some MBMS service starts<BR> after a long period of time (e. g. , 10 days later) so that the network resources would be wasted.

SUMMARY OF THE INVENTION The object of the present invention is to provide a method for setting time limit in joining MBMS, making all UEs join in the MBMS service within the allowed joining time preset by network. If some UEs request to join in the MBMS service beyond the preset joining time, the UEs will be refused by the network at all.

To achieve the goal mentioned above, a method for setting time limit in joining MBMS comprising steps of : advertising service parameters of an MBMS service at the service advertising phase by a BM-SC ; initiating a process of joining in the MBMS service after the start time when the join is allowed arrives by a UE receiving the service advertising message ; and judging whether the start time when said MBMS service is allowed to join in arrives or not by the network after receiving request to join MBMS service of UE, if so, the network accepts this request of the UE ; otherwise, the network refuses the request of the UE.

The present invention make the UE know when to join the MBMS service and apply the time limit to joining the MBMS service, so that the application efficiency of the network has been improved.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows the logic network structure of the MBMS system; Figure 2 illustrates the process of advertising the start time when the MBMS service is allowed to join in by service advertising in the present invention; Figure 3 illustrates the first method that the network refuses the request of the UE if the UE requests to join the MBMS service beyond the allowed time in the present invention;

Figure 4 illustrates the second method that the network refuses the request of the UE if the UE requests to join the MBMS service beyond the allowed time in the present invention; and Figure 5 is an example illustrating the relationship among the start time of the MBMS service advertising process, the start time when the MBMS service is allowed to join in and the start time of the MBMS service in the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The service advertising process is briefly described in figure 2. Before transmitting the data of the MBMS service, the BM-SC transmits the MBMS service advertisement a period of time in advance to notify the UEs of the MBMS service related parameters (such as the Service ID, Service Start Time and so on) so that the UEs can join in and use the MBMS service if they have received the service advertisement. It should be noted that the service advertising process can be implemented a long period of time (e. g., several days or weeks before the service starts) before the real service starts in the prior art. The service advertising process will be repeated several times till the advertised MBMS service is completed.

In 201 of figure 2, the service context of the BM-SC is configured by the function of operation and maintenance before a certain service starts. Before the service starts, the service context of the BM-SC mainly includes following parameters: >service ID service start time > the start time when the join is allowed > piecewise reference value The service identifier (such as the IP multicast address) uniquely identifies a certain MBMS service. The MBMS service data is transmitted in the form of one or several continuous sessions and one session can include one or several times of data transmission. When the MBMS system transmits a certain MBMS service data, it can form the service data into one or several continuous sessions, therefore, the service start time indicates the time when one or several continuous sessions of certain MBMS service start. Little or even no time can be left between the session start time and the time when the first data is transmitted. In view of the UE, the session start time is almost the time when data is transmitted. The start time when the join is allowed indicates the time when the UE can join in the MBMS service. It should be a period of time earlier

than the service start time. The function of the piecewise reference value is described in the subsequent sections.

In 202 of figure 2, the BM-SC transmits parameters of the service identifier, the service start time and the time when the join is allowed and the piecewise reference value through the service advertising message. During one process of advertising, the BM-SC can transmit several times of service advertising messages. For a certain MBMS service, the BM-SC can implement the service advertising process a long period of time (such as several days or even several weeks) before the service starts. For a certain MBMS service, the start time when the join is allowed can be set as the time several hours or scores of minutes (which is set by the network side according to experience) before the service starts so as to make the network have enough time in processing the requests of all UEs that use the MBMS service. It should be noted that N/W in figure 2 indicates the required nodes such as the GGSN, the SGSN, the RNC or the CBC via which the BM-SC transmits the service advertising message. In addition, step 2 will be repeated several times for a certain MBMS service till the MBMS service is completed.

For some reason (for instance, although the UE has received the service advertising message, errors come across the process that the UE resolves the parameter of the start time when the join is allowed because of signal's poor quality), a certain UE may initiate the process of joining in the MBMS service before the time when the join is allowed. If the network has received the MBMS service joining request before the start time when the join is allowed of this service, it should refuse this request. There are two methods for the network for refusing the error request of the UE: one is to notify the UE of the cause of error and inform the UE again of the correct start time when the join is allowed, thus, the network is required to feed back information to the UE in this method, as shown in figure 3; the other aims at reducing the burden of the network side, thus the network does not respond to the error request of the UE in this method, and when there is no response to several times of requests sent by the UE, the UE considers automatically that it fails in joining the MBMS service, as shown in figure 4.

In 301 of figure 3, the UE sends the IGMP message (which contains the IP multicast address) to the GGSN for requesting to join a certain MBMS service.

In 302 of figure 3, after the GGSN receives the IGMP message sent by the UE in step 301, it sends the BM-SC a MBMS Authentication Request message, which includes the parameter: IP multicast address.

In 303 of figure 3, after the BM-SC receives the MBMS Authentication Request message sent by the GGSN in step 302, it checks the IP multicast address included in the received message, and if the BM-SC finds that this IP multicast address indicates a valid

MBMS service, then it sends the GGSN a MBMS Authentication Response message, which includes the parameter: Cause with the value of success.

In 304 of figure 3, the GGSN interacts with the SGSN and the UE, asking the UE to initiate the process of establishing the MBMS service context, and the UE initiates the process of establishing the MBMS service context. Because the process of 304 is the prior art, no more detail will be given here. This process includes several messages, among which the last one is the MBMS Service Context Establishment Request that the SGSN sends to the GGSN, in which the parameters of the MBMS service and the identifier of the UE are included.

In 305 of figure 3, the GGSN sends a MBMS Access Request message to the BM-SC, which contains following parameters: the IP multicast address, the APN and the identifier of the UE.

In 306 of figure 3, after the BM-SC receives the message sent by the GGSN in step 305, it checks the identifier of the UE, the IP multicast address and the APN. Through checking the IP multicast address and the APN, if the BM-SC considers this MBMS service is available and valid, it goes to check the start time when the join is allowed for this MBMS service: if the start time when the join is allowed does not arrive when the BM-SC receives the message sent by the GGSN in step 305, the BM-SC sends the GGSN a MBMS Access Response message, which contains the parameter"Cause" (which indicates success or failure and the reason for failure) and"Start Time when the join is allowed", where the parameter Cause indicates failure and the reason for failure is "the start time when the join is allowed does not arrive" ; if the start time when the join is allowed has already arrived when the BM-SC receives the message sent by the GGSN in step 305, the BM-SC sends the GGSN the MBMS Access Response message, which contains the parameter"Cause"indicating success here.

In 307 of figure 3, after the GGSN receives the message sent by the BM-SC in step 306: if the parameter Cause included in the received message indicates success, the GGSN establishes the MBMS context about this UE and sends the SGSN a MBMS Context Establishment Response message, which contains the parameter Cause indicating success here; if the parameter Cause included in the received message indicates failure, the GGSN does not establish the MBMS context but send the SGSN the MBMS Context Establishment Response message according to the parameters in the received message. The MBMS Context Establishment Response message contains the parameter Cause and the start time when the join is allowed, where the parameter Cause indicates failure and reason for failure is"the start time when the join is allowed does not arrive".

In 308 of figure 3, after the SGSN receives the message sent by the GGSN in step 307: if the parameter Cause included in the received message indicates success, the SGSN establishes the MBMS context about this UE and sends the UE the MBMS Context Establishment Response message, which contains the parameter Cause indicating success here; If the parameter Cause included in the received message indicates failure, the SGSN does not establish the MBMS context but send the UE the MBMS Context Establishment Response message according to the parameters in the received message. The MBMS Context Establishment Response message contains the parameter Cause and the start time when the join is allowed, where the parameter Cause indicates failure and reason for failure is"the start time when the join is allowed does not arrive". After the UE receives the MBMS Context Establishment Response message from the SGSN: if the parameter Cause included in the received message indicates success, the UE activates its own MBMS context; and if the parameter Cause indicates failure and reason for failure is"the start time when the join is allowed does not arrive", the UE saves the parameter"the start time when the join is allowed"included in the received message and does not send the message on joining the MBMS any more before the start time when the join is allowed arrives.

In 401 of figure 4, the UE sends the IGMP message (which contains the IP multicast address) to the GGSN, requesting to join a certain MBMS service.

In 402 of figure 4, after the GGSN receives the IGMP message sent by the UE in step 401, it sends the BM-SC the MBMS Authentication Request message, which contains the parameter: IP multicast address.

In 403 of figure 4, after the BM-SC receives the message sent by the GGSN in step 402, it checks the IP multicast address. Through checking the IP multicast address, if the BM-SC considers this MBMS service is available and valid, it goes on to check the start time when the join is allowed for this MBMS service: if the start time when the join is allowed does not arrive when the BM-SC receives the message sent by the GGSN in step 402, then the BM-SC sends the GGSN the MBMS Access Response message, which contains the parameter"Cause" (which indicates success or failure and the reason for failure) and"Start Time when the join is allowed", where the parameter Cause indicates failure and the reason for failure is"the start time when the join is allowed does not arrive" ; if the start time when the join is allowed has already arrived when the BM-SC receives the message sent by the GGSN in step 402, the BM-SC sends the GGSN the MBMS Access Response message, which contains the parameter"Cause" indicating success here.

In 404 of figure 4, after the GGSN receives the MBMS Access Response message sent by the BM-SC in step 403: if the parameter Cause included in the received message

indicates success, the GGSN goes on to implement the following step 405; if the parameter Cause included in the received message indicates failure, the GGSN saves the parameter of the start time when the join is allowed included in the received message in order to determine whether to send the Access Request message to the BM-SC or not according to the start time when the join is allowed if it receives the IGMP message for joining the MBMS service again, and then the action of the GGSN is stopped so as not to enter the step 405.

In 405 of figure 4, the GGSN interacts with the SGSN and the UE to complete the process of establishing the MBMS context for the UE. The process is the prior art, no more detail will be given here. It should be noted that in the step 404, if the GGSN receives the message sent by the BM-SC in step 403 and finds that the parameter Cause included in it indicates failure, then the GGSN does not go to step 405. In this case, step 405 can not be implemented. Therefore, the UE obtains no feedback information after it sends out the IGMP message in step 401, so that the UE may send the IGMP message again for several times. If it yet obtains no feedback information, it will give up joining the MBMS service at this moment.

Figure 5 is an example illustrating the relationship among the start time of the MBMS service advertising process, the start time when MBMS service is allowed to join in and the start time of the MBMS service. In figure 5, June is taken as an example. The start time of the MBMS service advertising process is at 8 : OOAM on 10th June, a certain MBMS service is indicated to start at 8 : OOPM on 15th June (i. e. the service start time is 8: OOPM on 15th June), and the start time when the join is allowed is indicated to be at 8: OOAM on 15th June in the service advertisement. In this case, all UEs that want to join the MBMS service should initiate the process of joining the MBMS service after 8 : OOAM on 15th June. The start time when the join is allowed can be expressed as an absolute one like 8 : OOAM 15th June in the example of figure 5 or a relative one against the start time of the service, as shown in figure 5, the start time when the join is allowed <BR> <BR> can also be expressed as 12 hours, i. e. , the start time when the join is allowed is 12 hours earlier than the time when the service starts.

In figure 5, after the start time when the join is allowed has been advertised in the service advertisement, the ITEMS that have received the advertisement message and wants to receive the MBMS service will initiate the process of joining the MBMS service after the start time when the join is allowed arrives. At this moment, there may rise a problem of congestion in the air-interface resulted from that plenty of UEs simultaneously request to join the MBMS service a short period of time after the start time when the join is allowed arrives. In order to settle this problem, a further optimized solution has been proposed in the present invention as follows:

1. The period of time from the beginning to the end of the start time when the join is allowed is divided into n slots (where n is a natural number) in the network side. For the example in figure 5, divide the 12 hours into n slots, where n=12, then the time period of each slot is one hour. Then the parameter n (hereinafter referred to the piecewise reference value) is transmitted along with the start time when the join is allowed through service advertising.

2. Each UE that has received the service advertisement considers in which slot it should really initiate the process of joining the MBMS service according to the parameters (the start time when the join is allowed and the piecewise reference value n) included in the received advertisement. For example, the UE can divide its UE identifier <BR> <BR> (i. e. , IMSI, which is a positive integer) by n to get the remainder k, i. e. , IMSI mod n = k, then consider the remainder k as the start time when the join is allowed, and it is obviously that 0<kn here, the UE thus should initiate the process of joining the MBMS <BR> <BR> service in the kth slot. Also take figure 5 as an example, let n = 12, i. e. , the time period between the start time when the join is allowed and the service start time is divided into 12 slots with each slot indicating one hour. Suppose the IMSI of a certain UE be 324567, then 324567 mod 12 = 3, thus this UE should initiate the MBMS joining process in the <BR> <BR> 3rd slot, viz. , at 10: 00AM on 15tu. It should be note that a certain UE may receive the service advertisement message after the beginning of the start time when the join is allowed because of some reasons (like that UE is powered on just now). In this case, if the slot that the UE calculates for joining the MBMS service has elapsed, the UE can initiate the MBMS service joining process in current slot. In addition, after receiving the request of the UE to join the MBMS service, what the network should do is to judge whether the start time when the join is allowed or not for this MBMS service as it operates in figure 3 or figure 4, but not to further judge whether the MBMS request is initiated in the valid slot or not, for the object of the further optimized method is to avoid congestion in the air-interface.