[go: up one dir, main page]

WO2008143559A1 - Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms) - Google Patents

Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms) Download PDF

Info

Publication number
WO2008143559A1
WO2008143559A1 PCT/SE2007/050338 SE2007050338W WO2008143559A1 WO 2008143559 A1 WO2008143559 A1 WO 2008143559A1 SE 2007050338 W SE2007050338 W SE 2007050338W WO 2008143559 A1 WO2008143559 A1 WO 2008143559A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
mbms session
session
sgsn
mbms
Prior art date
Application number
PCT/SE2007/050338
Other languages
English (en)
Inventor
Lars Gunnar Folke AHLSTRÖM
Lasse Olsson
Peter Ramle
Hans Bertil RÖNNEKE
Gunnar Rydnell
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to CN200780053033A priority Critical patent/CN101675670A/zh
Priority to PCT/SE2007/050338 priority patent/WO2008143559A1/fr
Publication of WO2008143559A1 publication Critical patent/WO2008143559A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition

Definitions

  • 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.
  • MBMS Multimedia Broadcast/Multicast Service
  • the purpose is to redirect the MBMS session without having to initiate a complete distribution tree for the MBMS session.
  • 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
  • BM-SC Broadcast Multicast Service Centre
  • 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.
  • 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 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.
  • MBMS Multimedia Broadcast/Multicast Service
  • a method 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.
  • 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.
  • 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 node layer is a Serving GPRS Support Node (SGSN) layer.
  • SGSN Serving GPRS Support Node
  • 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 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.
  • TEID Tunnel End Point Identifier
  • 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.
  • said node layer is a Gateway GPRS Support Node (GGSN) layer and said lower node layer is a Serving GPRS Support Node (SGSN) layer.
  • GGSN Gateway GPRS Support Node
  • SGSN Serving GPRS Support Node
  • 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.
  • the node layer is a Broadcast Multicast Service Centre (BM-SC) and the lower node layer is a Gateway GPRS Support Node (GGSN) layer.
  • BM-SC Broadcast Multicast Service Centre
  • GGSN Gateway GPRS Support Node
  • 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.
  • Fig. 10 shows a flowchart for the embodiment of figure 9 according to the invention.
  • 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.
  • 3G-UMTS 3rd Generation - Universal Mobil Telecommunications System
  • FIG. 1 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • GGSN 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.
  • 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.
  • 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.
  • 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.
  • the SGSN 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.
  • 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.
  • each SGSN includes all SGSNs that belong to the same SGSN pool in 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.
  • 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.
  • BM-SC initiates the MBMS broadcast session.
  • the list of SGSNs for the session is included in the message to GGSN1 and GGSN2.
  • the list will contain SGSN1 , SGSN2 and SGSN3.
  • SGSN2 is available for the session, but is not used in this session.
  • GGSN1 and GGSN2 send an "MBMS Session Start Request" to all SGSNs in the list, including a list of SGSNs for the session.
  • 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.
  • SGSN1 and SGSN3 send an "MBMS Session Start Request" to all RNCs available.
  • different RNCs will be able to connect to the different SGSNs. This may e.g. be a "first come - first served" mechanism.
  • RNC1 , RNC2 and RNC4 will connect to SGSN1 and RNC3 and RNC5 will connect to SGSN3.
  • a fourth step 204 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.
  • SGSN3 sends an "MBMS Session Stop Request" to the connected RNC3 and RNC5.
  • 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.
  • 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.
  • a "MBMS Session Start Request" message may be sent directly.
  • SGSN 1 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.
  • 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.
  • the GGSNs and the SGSNs that received a reject response in the initial start-up of the session will continue to retry the connection to a lower node at a regular interval.
  • an SGSN terminates due to maintenance, that node will be connected to another higher node.
  • a failure in a lower node i.e. an SGSN terminates due to maintenance
  • 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).
  • each SGSN 403 comprised in the system and available for an MBMS session are grouped in an SGSN pool 405.
  • 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.
  • 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.
  • 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.
  • 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.
  • the list will contain SGSN1 , SGSN2 and SGSN3.
  • GGSN1 and GGSN2 send an "MBMS Session Start Request" to all SGSNs in the list, in this example to SGSN1 , SGSN2 and SGSN3.
  • SGSN1 will connect to GGSN1
  • SGSN3 will connect to GGSN2.
  • SGSN1 and SGSN3 send an "MBMS Session Start Request" to all RNCs available.
  • different RNCs will connect to the SGSN in a known manner.
  • RNC1 , RNC2 and RNC4 will connect to SGSN1 and RNC3 and RNC5 will connect to SGSN3.
  • 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.
  • 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.
  • SGSN2 sends an "MBMS Session Start Request" to all the available RNCs in order to connect those to the ongoing MBMS session.
  • 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.
  • 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.
  • the GGSNs and the SGSNs that received a reject response in the initial start-up of the session will continue to retry the connection to a lower node at a regular interval.
  • an SGSN terminates due to maintenance
  • that node will be connected to another higher node.
  • all SGSNs will retry to connect to the RNCs 604.
  • RNC6 will be disconnected when SGSN4 terminates.
  • 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).
  • 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.
  • an uplink node e.g. a GGSN 702
  • the downlink node e.g. an SGSN 703
  • 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.
  • 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
  • GTP-C GPRS Tunneling Protocol - Control plane
  • 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.
  • 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.
  • GTP-U TEID TEID, Tunnel End Point Identifier
  • IP-address and TEID for the CP CP, Control Plane
  • the SGSN can initiate a move of the associated CP if so desired.
  • 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.
  • GGSNs 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.
  • a third step 803 (MBMS Session Start Request/Response) all SGSNs send an "MBMS Session Start Request" to all RNCs available.
  • RNCs will connect to the SGSN in a known manner.
  • RNC1 , RNC2 and RNC3 will connect to SGSN.
  • a fourth step 804 (MBMS Session Data) the MBMS session is ongoing with payload sent to the SGSN from the GGSN.
  • a fifth step 805 (MBMS Session Data) the MBMS session is ongoing with payload sent to the RNCs from the SGSN.
  • a sixth step 806 (MBMS Session Update Request/Response)
  • 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.
  • 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.
  • an eighth step 808 (MBMS Session Data) the MBMS session is continued with payload sent to the RNCs from the SGSN.
  • 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.
  • 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.
  • 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.
  • the old MBSM session will have to be aborted.
  • the end user will notice a disruption or even an abortion of the MBSM session.
  • the GGSNs 902 will transfer the GTP-C tunnel information (IP-address and
  • 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.
  • GTP-C tunnel information IP-address and TEID
  • GGSN 1 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.
  • SGSN1 and SGSN2 including the GTP-C tunnel information.
  • 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.
  • 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.
  • GGSN2 sends a reject reply to the BM-SC and only GGSN1 is used in the beginning of the MBMS session.
  • 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.
  • 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.
  • an update request message e.g. an "MBMS Session Update Request”
  • SGSN information i.e. the IP-address and TEID for each SGSN.
  • a third step 1003 (MBMS Session Start Request/Response)
  • all SGSNs send an "MBMS Session Start Request" to all RNCs available.
  • RNCs will connect to the SGSNs in a known manner.
  • 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.
  • a fifth step 1005 (RAR/RAA (SGSNx info)
  • 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.
  • a sixth step 1006 the MB-SC sends MBMS session payload to GGSN2, which sends the MBMS session payload further to the SGSNs.
  • 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.
  • the SGSN will be able to send back control plane messages back to GGSN2.
  • this message could also be sent before the MBMS session is continued in step six.
  • 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.
  • the redirection of the MBMS session may be performed in the following way.
  • 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).
  • 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.
  • the procedure in the new GGSN may be started in parallel to the session in the old GGSN.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention porte sur un procédé pour la redirection d'une session de service de diffusion/multidiffusion multimédia (MBMS) dans un système de communication comprenant une pluralité de couches de nœuds, la session MBMS étant redirigée d'un nœud à l'autre dans la même couche de nœud, de telle sorte que la session MBMS n'est pas abandonnée. L'avantage de l'invention est qu'une session MBMS peut être redirigée d'un nœud à l'autre sans abandonner la session MBMS et ainsi il n'y a pas besoin d'initialiser une nouvelle session MBMS lorsqu'un nœud dans un système de communication tombe en panne.
PCT/SE2007/050338 2007-05-21 2007-05-21 Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms) WO2008143559A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN200780053033A CN101675670A (zh) 2007-05-21 2007-05-21 用于重定向mbms会话的方法
PCT/SE2007/050338 WO2008143559A1 (fr) 2007-05-21 2007-05-21 Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2007/050338 WO2008143559A1 (fr) 2007-05-21 2007-05-21 Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms)

Publications (1)

Publication Number Publication Date
WO2008143559A1 true WO2008143559A1 (fr) 2008-11-27

Family

ID=40032148

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2007/050338 WO2008143559A1 (fr) 2007-05-21 2007-05-21 Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms)

Country Status (2)

Country Link
CN (1) CN101675670A (fr)
WO (1) WO2008143559A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104994482A (zh) * 2015-07-15 2015-10-21 大唐移动通信设备有限公司 一种业务板故障后teid资源的回收方法及装置
US20160072665A1 (en) * 2013-04-16 2016-03-10 Telefonaktiebolaget L M Ericsson (Publ) Mbms session restoration in eps for path failure

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002085048A1 (fr) * 2001-04-12 2002-10-24 Telefonaktiebolaget L M Ericsson (Publ) Procede de transfert dans un systeme de communication gprs
US20030055977A1 (en) * 2001-09-17 2003-03-20 Miller Michael J. System for automated, mid-session, user-directed, device-to-device session transfer system
US20050091399A1 (en) * 2003-09-30 2005-04-28 Candan Kasim S. Resource-aware adaptive multicasting in a shared proxy overlay network
US20060171369A1 (en) * 2005-02-03 2006-08-03 Telefonaktiebolaget L M Ericsson (Publ) Resource utilization for multimedia broadcast multicast services (MBMS)

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002085048A1 (fr) * 2001-04-12 2002-10-24 Telefonaktiebolaget L M Ericsson (Publ) Procede de transfert dans un systeme de communication gprs
US20030055977A1 (en) * 2001-09-17 2003-03-20 Miller Michael J. System for automated, mid-session, user-directed, device-to-device session transfer system
US20050091399A1 (en) * 2003-09-30 2005-04-28 Candan Kasim S. Resource-aware adaptive multicasting in a shared proxy overlay network
US20060171369A1 (en) * 2005-02-03 2006-08-03 Telefonaktiebolaget L M Ericsson (Publ) Resource utilization for multimedia broadcast multicast services (MBMS)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 7)", 3GPP TS 23.246 V7.2.0, March 2007 (2007-03-01), pages 17, 21, 27 - 45, XP003021552 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160072665A1 (en) * 2013-04-16 2016-03-10 Telefonaktiebolaget L M Ericsson (Publ) Mbms session restoration in eps for path failure
US10193743B2 (en) * 2013-04-16 2019-01-29 Telefonaktiebolaget Lm Ericsson (Publ) Multimedia broadcast multicast service (MBMS) gateway for restoring an MBMS session after path failure
US11595246B2 (en) 2013-04-16 2023-02-28 Telefonaktiebolaget Lm Ericsson (Publ) MBMS session restoration in EPS for path failure
CN104994482A (zh) * 2015-07-15 2015-10-21 大唐移动通信设备有限公司 一种业务板故障后teid资源的回收方法及装置
CN104994482B (zh) * 2015-07-15 2018-06-26 大唐移动通信设备有限公司 一种业务板故障后teid资源的回收方法及装置

Also Published As

Publication number Publication date
CN101675670A (zh) 2010-03-17

Similar Documents

Publication Publication Date Title
US11595246B2 (en) MBMS session restoration in EPS for path failure
EP3831098B1 (fr) Fourniture de services de multidiffusion/diffusion dans des réseaux 5g
JP5066251B2 (ja) 異なる無線アクセス技術のネットワーク間を移動する移動ノードのためのマルチキャストデータのサービスコンテンツ同期
CN1166097C (zh) 无线通信网络中的切换
CN115398973B (zh) 移动期间的组播和广播服务连续性
CN101010893B (zh) 无线通信系统中无线电资源控制连接的建立
EP1821563A2 (fr) Fourniture d'un service de diffusion/multidiffusion multimédia (MBMS) pour un équipement utilisateur se déplaçant parmi les cellules dans un système de communication mobile cellulaire
EP2053899A1 (fr) Transfert de paramètres d'algorithme d'optimisation pendant le transfert d'une station mobile entre sous-systèmes de réseau radio
EP2245783B1 (fr) Commande de transmissions point à multipoint de données de contenu sur une interface radio
US10939491B2 (en) Maintaining user plane session and restoring control plane session in case of control plane module failure of gateway for multicast transmissions
KR20220143898A (ko) 데이터 스트림 전송 방법, 단말 및 네트워크측 기기
JP4820952B2 (ja) セルラ通信システムにおける無線ベアラの管理
US20050091315A1 (en) Method, system and radio access network nodes for user data connection re-establishment
JP4846640B2 (ja) 通信方法および通信システム
JP2023537056A (ja) マルチキャストおよびブロードキャストサービスのための方法および装置
JP2009077037A (ja) 基地局制御装置およびデータ転送制御方法
US20040085923A1 (en) Method and apparatus for cell reselection within a communications system
US7260070B1 (en) System and method for providing information to a mobile unit
WO2008143559A1 (fr) Procédé de redirection d'une session de service de diffusion/multidiffusion multimédia (mbms)
RU2466513C2 (ru) Изменения обслуживающих точек доступа прямой линии связи и обратной линии связи
US7839809B2 (en) Uninterrupted multicast service in a radiocommunication system
WO2000070899A1 (fr) Procede de conduite de scenarios de retrotransferts dans des en telecommunications
US7342933B2 (en) Packet delivery method for packet radio networks
CN101128012A (zh) 一种移动终端进行快速切换的方法
JP2009225291A (ja) 移動通信システムおよび無線基地局

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780053033.0

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07748499

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07748499

Country of ref document: EP

Kind code of ref document: A1