METHOD FOR REDIRECTING AN MBMS SESSION

TECHNICAL FIELD

The invention relates to a method for the redirection of a Multimedia Broadcast/Multicast Service (MBMS) session, when e.g. a problem occurs in one of the support nodes or when maintenance of a support node is due. The purpose is to redirect the MBMS session without having to initiate a complete distribution tree for the MBMS session.

BACKGROUND

Using different functions in hand-held mobile phones puts an increasing demand on bandwidth in the mobile phone broadcast system. This is especially true when several users are, at the same time, accessing e.g. a streaming video portal. Every single user uses in this example one connection each. This means that if several users are accessing the same portal, e.g. during a soccer game when all users wants to see a replay, bandwidth can be saved if the portal would send the program on a common broadcast channel.

Such a point-to-multipoint service is known as a MBMS (MBMS, Multimedia Broadcast/Multicast Service) in which data is transmitted from a single source entity to multiple recipients. This is done in such a way that a BM-SC

(BM-SC, Broadcast Multicast Service Centre) sends the required program, which can be received by all users. The area in which the program is broadcasted can be selected depending e.g. on area or region. This technique is especially advantageous using a 3G communication system, due to the high bandwidth capacity of the system, which allows for e.g. streaming video transmittal.

Since all users connected to the single broadcast channel are only listening passively, there is no dedicated connection established from the single user through the base station to the service supplier. In case of a failure in one of the nodes in the system, there might therefore be an interruption in the broadcast and the session may have to be re-established.

SUMMARY

It is the object of the invention to obviate at least some of the above disadvantages and provide an improved terminal for telecommunication.

More specific, an object of the invention is therefore to provide a method that allows for a redirection of a session to another node or sub-node in the communication system without the session being aborted.

The solution to this problem according to the invention is described in the characterizing part of claim 1 regarding the method. The other claims contain advantageous embodiments and further developments of the method according to the invention.

With a method for the redirection of a Multimedia Broadcast/Multicast Service (MBMS) session in a communication system comprising a plurality of node layers, the object of the invention is achieved in that the MBMS session is redirected from a node to another node in the same node layer, such that the MBMS session is not aborted.

By this first embodiment of the method according to the invention, a method is provided, which allows the redirection of a MBMS session without having to abort the complete MBMS session, should a node in the communication system fail. The advantage of this method is that the end user will be attached to the MBMS session during the redirection. This will lead to fewer and/or shorter disruptions for the end user. This also means that the end user will not be disconnected from an MBMS session when a node fails.

In an advantageous development of the invention, information of the nodes used in a node layer for the MBMS session is included in a message sent by a higher node layer to all the nodes of said node layer. The advantage of this is that all nodes in a node layer will know what nodes are used in that layer.

In an advantageous development of the invention, a message is sent from a first node to a second node in the same node layer in order to move the MBMS session from said first node to said second node. The advantage of this is that the redirection of the MBMS session can be performed in one layer without involving other layers.

In an advantageous development of the invention, the node layer is a Serving GPRS Support Node (SGSN) layer.

In an advantageous development of the invention, information of the nodes available in a node layer for the MBMS session is included in a response message sent to a higher node layer. The advantage of this is that the higher node layer will have information of the nodes used in the lower node layer. This means that the higher node layer can redirect the MBMS session when a node in the lower node layer fails, without having to abort the complete MBMS session.

The information sent in the response message may also include GPRS Tunneling Protocol - User plane (GTP-U) or GPRS Tunneling Protocol - Control plane (GTP-C) information. The response message may also comprise an IP-address and a Tunnel End Point Identifier (TEID) of a node.

In an advantageous development of the invention, a start message from a node layer to a second node in a lower node layer using the information of the available nodes of said node layer is sent, when a first node in said node layer is no longer available, in order to move the MBMS session from said first node to said second node. The advantage of this is that redirection of the MBMS session can be performed without having to abort the complete MBMS session.

In an advantageous development of the invention, said node layer is a Gateway GPRS Support Node (GGSN) layer and said lower node layer is a Serving GPRS Support Node (SGSN) layer. In this development of the invention, the nodes in the SGSN node layer may be either the SGSNs or may be a plurality of User Plane boards comprised in an SGSN. The advantage of this is that a complete SGSN does not have to be replaced when one UP board fails.

In an advantageous development of the invention, the node layer is a Broadcast Multicast Service Centre (BM-SC) and the lower node layer is a Gateway GPRS Support Node (GGSN) layer.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in greater detail in the following, with reference to the embodiments that are shown in the attached drawings, in which

Fig. 1 shows a schematic communication system used for the first embodiment according to the invention,

Fig. 2 shows a flowchart for the first embodiment according to the invention,

Fig. 3 shows a schematic communication system used for a further embodiment according to the invention,

Fig. 4 shows a schematic communication system used for a further embodiment according to the invention,

Fig. 5 shows a flowchart for the embodiment of figure 4 according to the invention,

Fig. 6 shows a schematic communication system used for a further embodiment according to the invention,

Fig. 7 shows a schematic communication system used for a further embodiment according to the invention,

Fig. 8 shows a flowchart for the embodiment of figure 7 according to the invention,

Fig. 9 shows a schematic communication system used for a further embodiment according to the invention, and

Fig. 10 shows a flowchart for the embodiment of figure 9 according to the invention.

DETAILED DESCRIPTION

The embodiments of the invention with further developments described in the following are to be regarded only as examples and are in no way to limit the scope of the protection provided by the patent claims.

In the following, a communication system of the 3G-UMTS (3rd Generation - Universal Mobil Telecommunications System) type is used as an example of a communication system, and the abbreviations used are related to such a system using the 3GPP (3G Partnership Project) definitions of 21.905. It should be understood that the invention can be applied to other types of communication systems such as a 4G system and the like, and that the definitions used should not limit the scope of the invention.

An example of a broadcast communication system is shown in fig. 1. This system consists of a distribution tree comprising different layers of transmittal nodes. In here, a top node 101 called BM-SC (Broadcast Multicast Service Centre) is responsible for the sent data stream. A MBMS (MBMS, Multimedia Broadcast/Multicast Service) session is initiated by the BM-SC which is transmitted to a second node. The BM-SC will initiate a session depending on e.g. an input from a server or the like. The second node layer 102 comprises one or more GGSNs (GGSN, Gateway GPRS Support Node), in this example GGSN1 and GGSN2, which distributes the signals from the BM-

SC to a third node layer 103 called SGSN (SGSN, Serving GPRS Support Node). This node comprises one or more SGSNs, in this example SGSN1 , SGSN2 and SGSN3, which further distributes the signals from the GGSN to a fourth node layer 104 called RNC (Radio Network Controller). The fourth node layer comprises one or several RNCs, in this example RNC1 , RNC2, RNC3, RNC4, and RNC5, which in turn are connected to radio cells comprising radio antennas serving the end users.

In this communication system, the third node layer may be configured in different ways. Each SGSN may be addressed individually or the SGSNs may be configured in an SGSN Pool 105, which makes it possible for several SGSNs to be connected to the same RNC and vice versa. This makes load balancing between the SGSNs possible. It also makes it possible to do maintenance to an SGSN within the pool without service disruption (or at least with minimal disruption) since the Multicast Service handled by that SGSN can be re-distributed to other SGSNs in the pool. The same principles may also apply for pooling in a 4G system.

When the BM-SC initiates an MBMS broadcast session, a distribution tree is established for that MBMS session. The BM-SC will in the initiating process send a list including the SGSNs for the actual session in the message to the GGSNs. Thus, each GGSN knows which SGSNs are to be included during start-up, so that the GGSNs can try to connect to each SGSNs during initialisation. When the distribution tree is established, all RNCs will be connected to GGSNs through SGSNs, thus the MBMS session is established from the BM-SC to the end users. A problem will arise when an SGSN becomes unavailable. At those moments, the RNCs connected to that SGSN will lose contact with the system and the GGSN will in the existing systems not be able to redirect the session to other SGSNs. Instead, the MBMS session will be aborted and a new MBMS session will have to be established.

This is due to the fact that re-distribution of ongoing MBMS sessions does not exist in the present standard. Since a GGSN is not aware of the SGSN

Pool and its members, and thus does not have any knowledge of whether other SGSN pool members also handles the MBMS session, there is no possibility for a GGSN or an SGSN to move an MBMS session in case of maintenance or failure of an SGSN. This means that an ongoing MBMS session will be aborted from the failed SGSN and downwards in case of failure or during maintenance of the SGSN, even if the node itself is part of a pool. Thus, the end users attached to that part of the distribution tree will see its session aborted.

The only option for a GGSN to detect a failure of an SGSN is through the echo request mechanism, but the GGSN will in this case be unable to do anything else than send an alarm. This means that a redirection of the session is not possible. The system will receive an error code, and eventually the system may be restarted, which means that a new distribution tree must be established. This also means that all end users will see an abortion of the MBMS session. The end users will be subjected to a rather long disruption and the other end users will notice a somewhat shorter disruption, depending on the time to establish a new distribution tree. Depending on the available services provided to the end users, it is also possible that all end users must make a new attachment to the MBMS session since the initial session was aborted. This solution is slow and will not guarantee a stable transmission of the session material.

Thus, the inventive method incorporates a redirection possibility for the MBMS session between different nodes or sub-nodes, so that an abortion of the MBMS session is not necessary.

In a first embodiment of the invention, the BM-SC informs the GGSN on which SGSN that is to have the payload stream. The GGSN will forward this information to all SGSNs used during the session which means that when an SGSN receives the "MBMS Session Start Request" message, it can identify its fellow SGSN pool companions in the list of SGSNs received.

When maintenance is required for an SGSN and an MBMS session is ongoing, it will be possible for the SGSN to move its ongoing MBMS session with e.g. a separate move command. From the list of SGSNs belonging to the pool, other SGSN pool members are identified and the SGSN can move the sessions with an "MBMS session update request" to one or more of the identified SGSN pool members. The other SGSN pool members will try to connect to those RNCs that are not already connected to them, as in an ordinary start-up procedure.

The GGSN does not have to be updated since the other SGSN pool members already have ongoing MBMS data flows to them. The SGSN that is going to be powered down just terminates its session in a controlled way. It may be advantageous for the SGSN to indicate, in a cause code, the successful move to another SGSN when it terminates the session.

In a second embodiment of the invention, this is done by letting each SGSN include all SGSNs that belong to the same SGSN pool in the "MBMS Session

Start Response" message sent to the GGSN during initialisation of the session. Thus, each GGSN will know which SGSNs are members of the

SGSN pool used during the MBMS session. A GGSN therefore have the possibility to initiate an "MBMS Session Start (or Update) Request" to another member of the same SGSN pool in case of failure for the SGSN currently handling the MBMS session.

When an SGSN breaks down, it may not be possible to terminate the session in a controlled way. The detection of an SGSN failure in this case may be achieved through the "Echo request/response mechanism" in the GGSN. This mechanism is advantageously applied on both the GTP-C (GPRS Tunneling Protocol - Control plane) and the GTP-U (GPRS Tunneling Protocol - User plane) paths. The "Echo request/response mechanism" can also be used during a controlled termination.

A detailed example of the redirection procedure will now follow, with reference to fig. 2. In the parenthesis after each method step, an example of a possible message that can be used to initiate the method step is given. These examples should not limit the invention in any way.

In a first step 201 (RAR/RAA), BM-SC initiates the MBMS broadcast session. The list of SGSNs for the session is included in the message to GGSN1 and GGSN2. In this example, the list will contain SGSN1 , SGSN2 and SGSN3. SGSN2 is available for the session, but is not used in this session.

In a second step 202 (MBMS Session Start Request/Response), GGSN1 and GGSN2 send an "MBMS Session Start Request" to all SGSNs in the list, including a list of SGSNs for the session. In this example the start request is sent to SGSN1 and SGSN3. This means that SGSN1 will know that SGSN3 is included in the session and that SGSN3 will know that SGSN1 is included in the session.

In a third step 203 (MBMS Session Start Request/Response), SGSN1 and SGSN3 send an "MBMS Session Start Request" to all RNCs available. Depending on e.g. area, region or capacity, different RNCs will be able to connect to the different SGSNs. This may e.g. be a "first come - first served" mechanism. In this example, RNC1 , RNC2 and RNC4 will connect to SGSN1 and RNC3 and RNC5 will connect to SGSN3.

In a fourth step 204 (Move MBMS cmd), the redirection of the session from SGSN3, e.g. due to maintenance or load sharing, is initiated. This is done by sending a "Move MBMS" command in order to move the active MBMS sessions from SGSN3 to SGSN 1.

In a fifth step 205 (MBMS Session Stop Request/Response), SGSN3 sends an "MBMS Session Stop Request" to the connected RNC3 and RNC5.

In a sixth step 206 (MBMS Session Update Request/Response), SGSN3 sends e.g. an "MBMS Session Update Request" to SGSN1 to indicate the

move. The sent message may include information about the RNCs connected to SGSN3 (RNC3 and RNC5 in this example). SGSN1 will in this case know which of the RNCs that are not connected to an SGSN and thus to which RNCs it should try to connect to.

In a seventh step 207 (MBMS Session Start Request/Response), which ends the redirection of the MBMS session, SGSN1 sends a "MBMS Session Start Request" to the RNCs, either all of them or at least to RNC3 and RNC5, depending on the information included in the message sent in the sixth step.

Alternatively, in the sixth step, a "MBMS Session Start Request" message may be sent directly. When SGSN 1 receives this message, SGSN 1 will try to connect to all RNCs not connected to SGSN1. If the message contains information about the RNCs connected to SGSN3 (RNC3 and RNC5 in this example) SGSN1 may only try to connect to those RNCs indicated in the message.

When the redirection is ended, all RNCs will be connected to an SGSN and the MBMS broadcast session is working. Since the redirection is done in a controlled way, the end users attached to each RNC will not have noticed the redirection and the MBMS session has not been aborted.

In a second embodiment of the invention, shown in fig. 3, the BM-SC 301 will send the "MBMS Session start request" to all GGSNs 302 including a list of the SGSNs 303 included in the MBMS session. Which of the GGSNs and SGSNs that actually handles a specific MBMS session will be randomly determined by a "first served" mechanism and all other requests for the same session will be rejected.

Fig. 3 shows the MBMS data flows when the MBMS session has been set up. The dotted lines show connections that have been rejected due to the MBMS session already set up from another source.

In this embodiment, the GGSNs and the SGSNs that received a reject response in the initial start-up of the session (the dotted lines) will continue to retry the connection to a lower node at a regular interval. As soon as there is a failure in a lower node, i.e. an SGSN terminates due to maintenance, that node will be connected to another higher node. In this example, if e.g. SGSN4 is shut down, there is no need for a new connection from a GGSN to an SGSN since all SGSNs are already connected to a GGSN. At the same time, all SGSNs will retry to connect to the RNCs 304. In this example, RNC6 will be disconnected when SGSN4 terminates. Thus, one of the remaining SGSNs will connect to RNC6. This will allow the MBMS session to continue with only a short interrupt (depending on the configured timeouts).

In a further embodiment of the invention, shown in fig. 4, the SGSNs 403 comprised in the system and available for an MBMS session are grouped in an SGSN pool 405. During an initialisation of a session start, each SGSN includes a list of the other SGSNs included in the SGSN pool in the "MBMS Session Start Response" message sent to the GGSNs 402. Thus each GGSN will have knowledge of which SGSNs that are included in the SGSN pool for the present MBMS session. A GGSN will therefore have the possibility to initiate an "MBMS Session Start (or Update) Request" to another member of the same SGSN pool in case of unavailability for a specific SGSN that is currently handling the MBMS session to a number of RNCs 404.

The detection of an SGSN failure may be achieved through the "Echo request/response mechanism" in the GGSN. This mechanism is advantageously applied on both GTP-C (GPRS Tunneling Protocol - Control plane) and GTP-U (GPRS Tunneling Protocol - User plane) paths.

In this embodiment, the GGSN initiates a redirection of the MBMS session when it detects that an SGSN is unavailable. This mechanism is preferably applied in case of a failure of an SGSN, i.e. a service interrupt, when a controlled termination is not possible. It is also possible to use this

mechanism during a restart of an SGSN. In this case, the GGSN moves the MBMS session to another SGSN pool member even in case of a restart, before the restart is completed in order to minimise the disrupt.

A detailed example of the redirection procedure of this embodiment will now follow, with reference to fig. 5.

In a first step 501 (RAR/RAA), BM-SC initiates the MBMS broadcast session. The list of available SGSNs for the session is included in the message to the GGSNs, in this case GGSN1 and GGSN2. In this example, the list will contain SGSN1 , SGSN2 and SGSN3.

In a second step 502 (MBMS Session Start Request/Response), GGSN1 and GGSN2 send an "MBMS Session Start Request" to all SGSNs in the list, in this example to SGSN1 , SGSN2 and SGSN3. In this example, SGSN1 will connect to GGSN1 and SGSN3 will connect to GGSN2.

In a third step 503 (MBMS Session Start Request/Response), SGSN1 and SGSN3 send an "MBMS Session Start Request" to all RNCs available. Depending on e.g. area, region or capacity, different RNCs will connect to the SGSN in a known manner. In this example, RNC1 , RNC2 and RNC4 will connect to SGSN1 and RNC3 and RNC5 will connect to SGSN3.

In a fourth step 504 (Echo Request), SGSN3 is terminated e.g. due to failure or maintenance. GGSN2 will detect this by the "Echo request/response mechanism" in the GGSN. Thus, GGSN2 will detect the failure of SGSN3.

In a fifth step 505 (MBMS Session Start Request/Response), GGSN2 will try to connect to another SGSN in the list of SGSN pool members. If GGSN2 tries to connect to SGSN1 , a negative "MBMS Session Start Response" message will be sent by SGSN1 since SGSN1 is already connected to GGSN1. When GGSN2 tries to connect to SGSN2, by sending an "MBMS Session Start Request", a positive "MBMS Session Start Response"

message is received by the GGSN2 since SGSN2 is not connected at the moment.

In a sixth step 506 (MBMS Session Start Request/Response), which ends the redirection of the MBMS session, SGSN2 sends an "MBMS Session Start Request" to all the available RNCs in order to connect those to the ongoing MBMS session.

When the redirection is finished, all RNCs will be connected to an SGSN and the MBMS broadcast session is working. The redirection is done in a controlled way, without the need to restart the complete MBMS session.

In a further embodiment of the invention, shown in fig. 6, the BM-SC 601 will send the "MBMS Session start request" to all GGSNs 602 including a list of the SGSNs 603 available for the MBMS session. Thus all available GGSNs and all available SGSNs will be available for the MBMS session. Which of the GGSNs and SGSNs that actually handles a specific MBMS session will be randomly determined by a "first served" mechanism and all other requests for the same session will be rejected.

Fig. 6 shows the MBMS data flows when the MBMS session has been set up. The dotted lines show connections that have been rejected due to the MBMS session already set up from another source.

In this embodiment, the GGSNs and the SGSNs that received a reject response in the initial start-up of the session (the dotted lines) will continue to retry the connection to a lower node at a regular interval. As soon as there is a failure in a lower node, i.e. an SGSN terminates due to maintenance, that node will be connected to another higher node. In this example, if e.g. SGSN4 is shut down, there is no need for a new connection from a GGSN to an SGSN since all SGSNs are already connected to a GGSN. At the same time, all SGSNs will retry to connect to the RNCs 604. In this example, RNC6 will be disconnected when SGSN4 terminates. Thus, one of the remaining

SGSNs will connect to RNC6. This will allow the MBMS session to continue with only a short interrupt (depending on the configured timeouts).

In a further embodiment of the invention, the redirection of the MBMS session is performed between different sub-nodes in an SGSN. This is shown in figs. 7 and 8.

The BM-SC node 701 initiates the establishment of a distribution tree in the network, thus setting up an MBMS session. The BM-SC node is responsible for the MBMS control signalling and user payload distribution. The Control signalling for broadcast consists basically of sending "MBMS Session Start" messages down to establish the session distribution tree in the network. In this procedure, an uplink node, e.g. a GGSN 702, will receive the IP-address which the downlink node, e.g. an SGSN 703, has assigned for receiving user payload of MBMS. When the distribution tree is established, the MBMS session may be started and the users in the cells included in the distribution tree can start receiving the MBMS session.

A downlink node, e.g. an SGSN, in the MBMS distribution tree may for some reason wish to redistribute payload sent through the node. An SGSN may comprise one or more UP-boards 706, 707 (UP, User Plane) for the distribution of payload. Each UP-board used in the SGSN is connected to the GGSN through a unique IP-address, i.e. each UP-board has its own connection to the GGSN. Each UP-board may be considered to be a sub- node of the SGSN.

When one of the UP-boards needs to be disconnected, e.g. due to failure or maintenance, it may be necessary to move the payload handled by that UP- board to another UP-board in the SGSN. A different board will have a new IP-address for payload to which the GGSN shall send the payload. In the current MBMS specifications, there is no possibility for an SGSN to initiate and update the GGSN with new MBMS session information, such as the IP- address for payload. In case an UP-board in the SGSN becomes unable to

handle the MBMS payload, the distribution of the MBMS session downstream the branch from that particular SGSN will be lost. Thus, the end user will experience an abortion of the MBMS session.

In this embodiment, it is proposed to let the SGSN initiate an "MBMS Session Update Request" in order to move its GTP-U tunnel for the MBMS session.

The communication between the GGSN and the SGSN and thus the UP- board can be seen as a fixed connection during use, in which the connection on the SGSN side, i.e. the UP-board, of the communication link uses GTP-U

(GPRS Tunneling Protocol - User plane) and the communication link on the GGSN side uses GTP-C (GPRS Tunneling Protocol - Control plane).

This requires that the SGSN can initiate sending an "MBMS Session Update Request" to the GGSN from where it receives the MBMS session payload, i.e. from the actual UP-board. The message shall include an IP-address for the UP-board. The GGSN shall stop sending the user payload to the IP- address which was previously established in the "MBMS Session Start Procedure", i.e. to the first UP-board, and start sending the payload to the IP- address received in the "Update Request message", i.e. the IP-address to the UP-board that is to replace the first UP-board. Preferably the message may also include a GTP-U TEID (TEID, Tunnel End Point Identifier) for the UP-board, which the GGSN preferably will insert in each GTP-U packet header sent to the SGSN for the MBMS session and which the SGSN uses to match the packet to a specific MBMS session.

It is also possible to include the IP-address and TEID for the CP (CP, Control Plane) in the "MBMS Session Update Request" initiated by the SGSN. In this case, the SGSN can initiate a move of the associated CP if so desired.

Referring to fig. 8, this embodiment will now be described.

In a first step 801 (RAR/RAA), BM-SC initiates the MBMS broadcast session. The list of available SGSNs for the session is included in the message to the

GGSNs. In this case only one GGSN is used for clarity, and the list will only contain one SGSN.

In a second step 802 (MBMS Session Start Request/Response), all GGSNs send an "MBMS Session Start Request" to all SGSNs in the list. In this example, GGSN will connect to SGSN.

In a third step 803 (MBMS Session Start Request/Response), all SGSNs send an "MBMS Session Start Request" to all RNCs available. Depending on e.g. area, region or capacity, different RNCs will connect to the SGSN in a known manner. In this example, RNC1 , RNC2 and RNC3 will connect to SGSN.

In a fourth step 804 (MBMS Session Data), the MBMS session is ongoing with payload sent to the SGSN from the GGSN.

In a fifth step 805 (MBMS Session Data), the MBMS session is ongoing with payload sent to the RNCs from the SGSN.

In a sixth step 806 (MBMS Session Update Request/Response), after the UP-board is shut down e.g. due to maintenance, load sharing or UP-board failure in the SGSN, the SGSN will send an "MBMS Session Update Request" to the GGSN in order to move the MBMS payload to a new IP- address, i.e. another UP-board in the SGSN. The GGSN will send an "MBMS Session Update response" back to the SGSN to acknowledge the request.

In a seventh step 807 (MBMS Session Data), the GGSN sends MBMS session payload to another board in the SGSN, i.e. to the UP-board to which the MBMS payload was moved in the sixth step, using the new IP-address received from the SGSN.

In an eighth step 808 (MBMS Session Data), the MBMS session is continued with payload sent to the RNCs from the SGSN.

By the eighth step, all RNCs will be connected to an SGSN and the MBMS broadcast session continues. The redirection is done in a controlled way, without the need to restart the complete MBMS session.

In a further embodiment of the invention, a GGSN in the MBMS distribution tree may for some reason wish to redistribute payload sent through that node. This may be the case e.g. due to failure or maintenance of the GGSN. In this case, the payload of the GGSN has to be moved to another GGSN, i.e. the MBMS session has to be redirected, in order to keep the MBMS session alive and to keep the end users attached to the MBMS session.

With the existing solution, a move of the MBSM session due to a failure in a GGSN is done by the BM-SC restarting the establishment of the distribution tree. The BM-SC does this by sending an "MBMS Session Start" message to the new GGSN, which in turn will establish a connection to the SGSNs in the distribution tree. The SGSNs will in turn establish a connection to the RNCs in the distribution tree, and the MBMS session will be set up again. In order to do the restart like this, the old MBSM session will have to be aborted. Thus, the end user will notice a disruption or even an abortion of the MBSM session.

In the inventive method according to the invention, as shown in fig. 9, the GGSNs 902 will transfer the GTP-C tunnel information (IP-address and

TEID) for the SGSNs 903 available in the MBMS session to the BM-SC 901 , so that the BM-SC will have information on which SGSNs are available for the current MBMS session. In this way, a BM-SC can move the MBMS session to another GGSN in case of maintenance or failure in the first GGSN. Since the BM-SC has the GTP-C tunnel information for all SGSNs connected to the old GGSN, it can forward this information to the new GGSN. The new

GGSN can then send an "MBMS Session Update Request" to the SGSNs in order to move their GTP-C tunnels from the old GGSN to the new GGSN.

This redirection of the MBMS session can be made in a controlled way, which means that the complete MBMS session does not have to be re-

established. Thus, no abortion of the MBMS session will take place and thus the payload traffic will be almost unaffected.

Fig. 9 shows the MBMS data flow when the MBMS session is being set up to the GGSN1. The MBMS session is initiated (arrow 905) by the BM-SC. GGSN1 transfer the GTP-C tunnel information (IP-address and TEID) for SGSN1 and SGSN2 back to the BM-SC (arrow 906), so that the BM-SC knows that SGSN1 and SGSN2 are used in the current MBMS session.

After a GGSN1 shut-down, due e.g. to a crash, failure or planned maintenance, the payload flow to GGSN 1 is interrupted. Due to a watchdog function in the interface between the BM-SC and the GGSN (e.g. a DWR/DWA, Device Watchdog Request/Answer function), the BM-SC will know when the GGSN is not functioning properly. The BM-SC will then send an "MBMS Session Start Request" to GGSN2 (arrow 907). The message from the BM-SC contains the information of the SGSNs used in the MBMS session, i.e. SGSN1 and SGSN2 including the GTP-C tunnel information. Thus, GGSN2 will receive the IP-address and TEID for both SGSN1 and SGSN2. This means that GGSN2 can start sending MBMS session payload immediately to SGSN1 and SGSN2. Since SGSN1 and SGSN2 are still connected to the RNCs used in the MBMS session, the MBMS session will continue to the end users without the need to abort the MBMS session and the need to initiate a new MBMS session. Thus, the end user will still be attached to the MBMS session and may only experience a short disruption, if any.

Referring to fig. 10, this embodiment will now be described.

In a first step 1001 (RAR/RAA), BM-SC initiates the MBMS broadcast session. The list of available SGSNs for the session is included in the message to the GGSNs. All GGSNs available for the MBMS session is addressed by the BM-SC. In this example, GGSN2 sends a reject reply to the BM-SC and only GGSN1 is used in the beginning of the MBMS session.

In a second step 1002 (MBMS Session Start Request/Response), all GGSNs send an "MBMS Session Start Request" to all SGSNs in the list. In this example, the SGSNs will connect to GGSN1. GGSN1 receives information from the SGSNs in the Response message.

In step 1002a (MBMS Session Update Request/Response), the GGSNs, here GGSN1 , sends back an update request message (e.g. an "MBMS Session Update Request") to the BM-SC indicating SGSN information, i.e. the IP-address and TEID for each SGSN.

In a third step 1003 (MBMS Session Start Request/Response), all SGSNs send an "MBMS Session Start Request" to all RNCs available. Depending on e.g. area, region or capacity, different RNCs will connect to the SGSNs in a known manner.

In a fourth step 1004 (MBMS Session Data), the MBMS session is ongoing with payload sent to the SGSNs from the GGSNs and further down with payload sent to the RNCs from the SGSNs.

In a fifth step 1005 (RAR/RAA (SGSNx info)), after the GGSN is shut down, e.g. due to maintenance, load sharing or a failure in the GGSN, the BM-SC will notice that the GGSN is not working properly, e.g. with a watchdog function. The BM-SC will then send an "MBMS Session Start Request" message to GGSN2 in order to move the MBMS session GGSN2. This request message may include an RAR (RAR, Re-Authorisation Request). The request message may also include an indication that the request is due to a failure in the old GGSN, i.e. GGSN1 , so that the new GGSN, i.e. GGSN2, shall not send session start messages to the SGSNs down stream. The GGSN2 will send an "MBMS Session Start Response" message back to the MB-SC to acknowledge the request.

In a sixth step 1006 (MBMS Session Data), the MB-SC sends MBMS session payload to GGSN2, which sends the MBMS session payload further to the SGSNs.

In a seventh step 1007 (MBMS Session Update Request/Response), GGSN2 sends an "MBMS Session Update Request" message to the SGSNs, with the GGSN2 GTP-C information, i.e. IP-address and TEID for the control plane. In this way, the SGSN will be able to send back control plane messages back to GGSN2. Alternatively, this message could also be sent before the MBMS session is continued in step six.

By this embodiment, the MBMS session will continue without an abortion of the MBMS session and an initialisation of a new MBMS session. Since the MBMS session is redirected, the connection between the SGSNs and the RNCs will not be terminated. The end user will therefore still be attached to the RNCs and thus to the MBMS session.

In a further embodiment of the invention, the redirection of the MBMS session may be performed in the following way.

A decision is made to move the MBMS broadcast session to a new GGSN. The BM-SC sends an "MBMS Session Start Request" message to the new GGSN. This message advantageously includes an indication that the MBMS session is not a new session but an existing session that is to be moved to the new GGSN. The new GGSN will send an "MBMS Session Start Response" message to the BM-SC.

The new GGSN sends an "MBMS Session Update Request" message to the SGSNs in order to update the SGSNs with the new GGSN GTP-C tunnel information (IP-address and TEID). This information is to be used by an SGSN when sending control plane messages back to the GGSN.

The SGSNs sends an "MBMS Session Update Response" message back to the new GGSN including GGSN GTP-U tunnel information (IP-address and TEID for the user plane).

After that, the BM-SC sends MBMS session payload to the new GGSN and the new GGSN sends the MBMS session payload to the SGSNs.

This is advantageous, especially for the case when a planned change of GGSNs is made. In this case, the procedure in the new GGSN may be started in parallel to the session in the old GGSN.

The invention is not to be regarded as being limited to the embodiments described above, a number of additional variants and modifications being possible within the scope of the subsequent patent claims. The terminology used should not limit the scope, but it should be understood that the principle will apply to different communication standards.