[go: up one dir, main page]

WO2005046261A1 - A transmission method of conversation data in multicasting/broadcasting service - Google Patents

A transmission method of conversation data in multicasting/broadcasting service Download PDF

Info

Publication number
WO2005046261A1
WO2005046261A1 PCT/CN2004/001277 CN2004001277W WO2005046261A1 WO 2005046261 A1 WO2005046261 A1 WO 2005046261A1 CN 2004001277 W CN2004001277 W CN 2004001277W WO 2005046261 A1 WO2005046261 A1 WO 2005046261A1
Authority
WO
WIPO (PCT)
Prior art keywords
session data
session
information
network controller
retransmission request
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2004/001277
Other languages
English (en)
French (fr)
Inventor
Hai Zhang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of WO2005046261A1 publication Critical patent/WO2005046261A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • 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/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • 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

Definitions

  • the present invention relates to data transmission technology, and particularly to a session data transmission method applied to multicast / broadcast services. Background of the invention
  • the third generation mobile communication can provide a higher data transmission rate service than the second generation mobile communication, so that the third generation mobile communication supports a variety of business forms, such as video telephony, picture download , High-speed browsing of the Internet (Internet) and other services.
  • the third generation of mobile communication supports a business form that sends certain information to users who have subscribed to certain information in the wireless network at the same time.
  • the information can be weather forecasts, news clips, sports competition highlights, and so on.
  • the third generation mobile communication introduced a description of multicast / broadcast services.
  • the nodes on each branch will copy the data according to the number of all end users belonging to the node, and then send the corresponding copies to the corresponding downstream nodes according to the number of end users belonging to its downstream nodes. This way, it will occupy too many transmission resources, especially for the root node. During the entire data transmission process, each end user belonging to the root node always occupies transmission resources, as shown in Figure 1. .
  • the multicast / broadcast service performs single-path forwarding during the process of transmitting data from the source node to the destination node. That is, for an intermediate node, no matter how many downstream nodes it expects to receive data, its upstream node always sends a copy of the data to the intermediate node; after the intermediate node receives the data, it The number of nodes replicates the data and distributes the data to each downstream node that expects to receive the data. In this way, multicast / broadcast Each branch of the service data transmission tree has only one piece of data to transmit, and it occupies one piece of transmission resources.
  • the multicast service only sends corresponding information to users who have subscribed to certain information
  • the broadcast service sends information to all users in the wireless network. It can be seen from the above description that the same information can be provided to a large number of users through the multicast / broadcast service at the same time, which can greatly save network resources.
  • FIG. 3 is a schematic diagram of a wireless network structure that supports multicast / broadcast services.
  • a wireless network structure that supports multicast / broadcast services in the existing 3rd Generation Partnership Project (3GPP) is a broadcast / multicast service center.
  • (BM-SC) 301 is connected to a Gateway General Packet Radio Service (GPRS) Support Node (GGSN) 302 through a Gmb interface or a Gi interface.
  • GPRS General Packet Radio Service
  • GGSN 302 is connected through The Gn / Gp interface is connected to a serving GPRS support node (SGSN, Serving GPRS Support Node) 303.
  • SGSN Serving GPRS Support Node
  • One GGSN 302 can be connected to multiple SGSN 303s.
  • the SGSN 303 can be connected to the Universal Mobile Telecommunications System (UMTS) terrestrial radio access network through an Iu interface.
  • UMTS Universal Mobile Telecommunications System
  • UTRAN Universal Mobile Telecommunications System
  • GERAN Enhanced Radio Access Network
  • the Um interface is connected to the communication terminal 307.
  • the wireless network usually retransmits the same session data multiple times to ensure that the communication terminal can accurately and reliably receive the multicast / broadcast session data delivered by the wireless network.
  • the BM-SC will resend the session data after a certain period of time.
  • the retransmitted session data is transmitted, and
  • the sent session data is not different from ordinary multicast / multicast service data, and it is also necessary to establish corresponding multicast / multicast service bearers.
  • the session data is then sent to all communication terminals in the multicast group or in the wireless network.
  • retransmitting session data When retransmitting session data, it is not performed on the wireless network coverage area or communication terminal that needs to retransmit session data, but on the entire multicast group or the entire wireless network.
  • the retransmission of session data includes areas that do not require retransmission of session data, which wastes network resources. Summary of the invention
  • an object of the present invention is to provide a method for transmitting session data in a multicast / broadcast service, to make the transmission of session data in a multicast / broadcast service more reliable, and to effectively save network resources.
  • the present invention provides a method for transmitting session data in a multicast / broadcast service.
  • the communication terminal detects that there is unreceived session data in the multicast / broadcast service.
  • the method includes the following steps:
  • the communication terminal sends a session data retransmission request carrying the session information to the radio network controller to which it belongs;
  • the radio network controller receives the session data retransmission request, and sends a session data retransmission request carrying the session information to an associated service support center;
  • the service support center receives the session data retransmission request, acquires the session data that needs to be retransmitted according to the session information, and then sends the session data to the administered wireless network controller to start News
  • the wireless network controller that sent the session data retransmission request under the jurisdiction of the service support center receives the session data start message, returns a session data start acceptance response to the service support center, and establishes user plane resources;
  • the service support center retransmits the session data to the wireless network controller that has returned the session data and starts to accept the response through the user plane resource. After receiving the retransmitted data, the wireless network controller retransmits and receives the communication data to the jurisdictional communication terminal. To the session data.
  • the method further includes: the radio network controller returns a session data retransmission response to the communication terminal under its jurisdiction.
  • step A the method further includes the following steps:
  • the communication terminal generates a random delay and starts the timing of the random delay timer.
  • A02. The communication terminal determines whether the session data retransmission response returned by the wireless network controller is received within the time range of the random delay counting. Delay the timer, otherwise, go to step 8.
  • step A After performing step A, the method further includes: return to step A01.
  • the method further includes: the radio network controller stores the session information.
  • the method further includes: the radio network controller judges whether the received session data retransmission request is directed to the session data based on the stored session information. Initial session data retransmission request for session data. If yes, send a session data retransmission request to the service support center to which it belongs; otherwise, no operation is performed.
  • the session data start message in step C carries session information
  • the step of sending the session data start message to the wireless network controller under management in step C is: the service support center according to the wireless network controller of the multicast / broadcast service to which the session data belongs List, and send a session data start message to the administered wireless network controller, after step C, the method further includes: the wireless network controller administered by the service support center receives the session data start message, and determines whether the session information is stored, and if yes, The session data carrying the user plane resource information is returned to the service support center to start accepting the response, and the user plane resource is established, otherwise, the session data is returned to the service support center to start the rejection response.
  • the step B further includes: the radio network controller records the cell information where the communication terminal is located.
  • the step C further includes: the service support center returns a session data retransmission response to the radio network controller under its jurisdiction.
  • the method Before sending the session data retransmission request carrying the session information to the affiliated service support center described in step B, the method further includes the following steps:
  • the wireless network controller generates a random delay and starts the timing of the random delay timer
  • step B After performing step B, the method further includes: return to step Bl.
  • the step C includes: receiving, by the service support center, the session data retransmission request, storing wireless network controller information, obtaining session data that needs to be retransmitted according to the session information, and then, according to the stored wireless network controller information, The wireless network controller described in the wireless network controller information sends a session data start message.
  • the session data retransmission request in step A further carries communication terminal information
  • the method further includes: the radio network controller stores the communication terminal information
  • the retransmission of the received session data to the communication terminal under the jurisdiction described in step E includes: the radio network controller 4 retransmits the received session data to the communication terminal under the jurisdiction corresponding to the communication terminal information according to the stored communication terminal information. Session data.
  • Obtaining the session data that needs to be retransmitted according to the session information in step C includes: The service support center requests the content providing server to provide session data corresponding to the session information according to the session information, and the content providing server provides the session data to the service support center. .
  • the method further includes: the service support center stores session information.
  • the method further includes: the service support center determines, according to the stored session information, whether the received session data retransmission request is the initial session data for the session data.
  • the retransmission request if it is, requests the content providing server to provide session data corresponding to the session information, otherwise, no operation is performed.
  • the session data start response in step D carries radio network controller information.
  • the method further includes: the service support center stores the radio network controller information.
  • the service support center in step E sends the service support center to the managed
  • the wireless network controller retransmitting the session data after returning the session data and starting to accept the response includes: the service support center retransmits the session data to the wireless network controller through user plane resources according to the stored wireless network controller information.
  • the communication terminal sends the session data retransmission request to the radio network controller through a random access process or a shared channel.
  • the communication terminal detects whether there is unreceived session data through a sliding window mechanism.
  • the communication terminal when it detects that there is unreceived session data, it sends a session data retransmission request to the network side.
  • the network side When the network side retransmits the session data, it retransmits only to the downstream node that expects to receive the session data. Session data, and can be expected to receive session data
  • the communication terminal retransmits the session data and achieves the purpose of targeted session data retransmission. Under the premise of rational use of wireless network and core network resources, the communication terminal and downstream nodes can more reliably receive the session data that they expect to receive. .
  • the invention saves the investment cost of the multicast / broadcast service, and improves the satisfaction rate.
  • the present invention provides multiple implementation manners, which can be flexibly selected according to the actual application situation, and can be combined in a case where there is no conflict in the specific implementation process, thereby realizing retransmission of session data. The best way to achieve it. Brief description of the drawings
  • Figure 1 is a schematic diagram of the unicast service transmission process
  • Figure 2 is a schematic diagram of the multicast / broadcast service transmission process
  • FIG. 3 is a schematic diagram of a wireless network structure supporting multicast / broadcast services
  • FIG. 4 is a schematic diagram of a session data retransmission process in the present invention. Mode of Carrying Out the Invention
  • a communication terminal After a communication terminal detects that there is unreceived session data, it sends a session data retransmission request to the RNC to which it belongs, and after receiving the session data retransmission request, the RNC sends a session data retransmission request to the service support center to which it belongs.
  • FIG. 4 is a schematic diagram of a session data retransmission process according to the present invention. As shown in FIG. 4, the implementation process of retransmitting session data generally includes the following steps:
  • Steps 401 to 405 The communication terminal detects that there is unreceived session data, and sends a session data retransmission request to the RNC to which it belongs, requesting the network side to resend the unreceived session data to it; the RNC receives the session data retransmission.
  • the session data retransmission request is sent to the SGSN to which it belongs; after receiving the session data retransmission request, the SGSN sends a session data retransmission request to the GGSN to which it belongs; after receiving the session data retransmission request, the GGSN sends it to it
  • the associated BM-SC sends a session data retransmission request.
  • the above steps are a process of transmitting a retransmission request in the reverse direction and establishing a retransmission tree.
  • Steps 406 to 409 After receiving the session data retransmission request, the BM-SC acquires the session data that needs to be retransmitted, and initiates a multimedia broadcast / multicast service (MBMS, Multimedia Broadcast / Multicast Service) when the session data can be sent. ) The session starts, and then sends a session data start message to the GGSN under its jurisdiction. The GGSN that sent the session data retransmission request under the jurisdiction of the BM-SC returns the session data to the BM-SC to which it belongs. Start to accept the response and establish user plane resources; the GGSN that returned the session data and started accepting the response sends a session data start message to the SGSN under its jurisdiction.
  • MBMS Multimedia Broadcast / Multicast Service
  • the SGSN that sent the session data retransmission request under the GGSN jurisdiction receives the session data start message, Return the session data to its own GGSN to start accepting the response and establish the user plane resource.
  • the SGSN that returned the session data and start accepting the response sends a session data start message to the RC under its jurisdiction.
  • the SGSN manages the RNC that sent the session data retransmission request. After receiving the session data start message, it returns it to the SGSN to which it belongs. The data back to the session starts to accept the response and establishes the user plane resource.
  • the steps described above are the forward session activation process.
  • Steps 410 to 413 The BM-SC retransmits the session data to the GGSN through the established user plane resources. After the GGSN receives the session data, it retransmits the session data to the SGSN through the established user plane resources. After the SGSN receives the session data, By establishing user plane resources to The RNC retransmits the session data; after receiving the session data, the RNC retransmits the session data to the communication terminal.
  • the above steps are the forward session data transmission process.
  • the detailed implementation process of the present invention is described in detail below.
  • the implementation process of retransmitting session data specifically includes the following steps:
  • Step A1 The communication terminal detects that there is unreceived session data. For example, the network side will notify the communication terminal in advance that it will send session data, but the communication terminal does not receive the corresponding session data, or the communication terminal uses a sliding window mechanism. It is detected that there is unreceived session data, and the network side needs to retransmit the session data.
  • the communication terminal sends a session data retransmission request to the RNC to which it belongs.
  • the session data retransmission request carries session information, and the session information may include a service identifier and a session identifier.
  • the RC After receiving the session data retransmission request carrying the session information, the RC determines whether the received session data retransmission request is the first session data retransmission request for the session data, and if the received session data The retransmission request is the first session data retransmission request for the session data, and the RC returns a session data retransmission response to all communication terminals in its jurisdiction through multicast / broadcast to notify the communication terminal that the network side has accepted the session Data retransmission request, and then store the session information of the session data in the MBMS Service Context, record the information of the cell to which the communication terminal belongs, and then send a session data retransmission request to the SGSN to which it belongs, and the session data is retransmitted
  • the request carries session information; if the received session data retransmission request is not the first session data retransmission request for the session data, the RNC records only the information of the cell to which the communication terminal belongs.
  • the RC can determine whether the session information carried in the session data retransmission request is stored, and determine whether the received session data retransmission request is the first session data retransmission request for the session data. If the session data retransmission request is stored, The session information carried in the transmission request, the received session data retransmission request is the first session data retransmission request for the session data; if the session information carried in the session data retransmission request is not stored, the received Session data retransmission request is not Is the first session data retransmission request for this session data.
  • the communication terminal may generate a random delay of a certain length of time before sending a session data retransmission request to the RC to which it belongs, and then the communication terminal waits for the RNC to return a session data retransmission response within the random delay. If the communication terminal receives the session data retransmission response returned by the RC within a random delay time, it no longer sends a session data retransmission request to the RNC to which it belongs, and stops the timing of the random delay; if the communication terminal is in a random delay If the session data retransmission response returned by the RNC is not received within the length of time, the session data retransmission request is sent to the RNC to which it belongs, and then the timing of the random delay can be directly ended, instead of waiting for the RNC to return a session data retransmission response; Generate a random delay again or use the original random delay, and continue to wait for the session data retransmission response returned by the RNC within the length of the random delay.
  • the random delay generated by the communication terminal enables each communication terminal located in the same cell to send session data retransmission requests to the RC at different times, avoiding the network caused by a large number of communication terminals sending session data retransmission requests to the RNC at the same time. congestion.
  • the RNC receives a session data retransmission request for the same session data from other communication terminals in the same cell, it may be that the RNC receives the first session data retransmission request and returns a session data retransmission response to all communication terminals located in the cell. In the meantime, the session data retransmission request sent by other communication terminals in the cell. After the RNC receives the first session data retransmission request, if it receives a session data retransmission request for the session data, it only records the cell information so that it can retransmit the session data based on the record.
  • the SGSN sends a session data retransmission request. In this way, the signaling traffic in the network can be reduced and the purpose of saving wireless network resources can be achieved.
  • Step A3 After receiving the session data retransmission request carrying the session information, the SGSN judges Whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data retransmission request is the first session data retransmission request for the session data, the The SGSN stores the session information of the session data in the MBMS Bearer Context, and then sends a session data retransmission request to the GGSN to which it belongs.
  • the session data retransmission request carries the session information; if the received session data is The transmission request is not the first session data retransmission request for the session data, so the SGSN does nothing, that is, the SGSN no longer sends a session data retransmission request to the GGSN to which it belongs, so that the SGSN requests a session data retransmission. Aggregation of the signaling, reduces signaling traffic in the wireless network, and saves wireless network resources.
  • Step A4 After receiving the session data retransmission request carrying the session information, the GGSN determines whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data is retransmitted, The transmission request is the first session data retransmission request for the session data, then the GGSN stores the session information of the session data in the MBMS bearer context, and then sends a session data retransmission request to the BM-SC to which it belongs. The retransmission request carries session information; if the received session data retransmission request is not the first session data retransmission request for the session data, the GGSN does nothing, that is, the GGSN no longer sends to the BM to which it belongs. -The SC sends a session data retransmission request. In this way, the GGSN aggregates the signaling of the session data retransmission request, reduces the signaling traffic in the network, and saves network resources.
  • Step A5 After receiving the session data retransmission request carrying the session information, the BM-SC determines whether the received session data retransmission request is the first session data retransmission request for the session data.
  • the data retransmission request is the first session data retransmission request for the session data
  • the BM-SC requests the content providing server to provide the session data according to the session information; if the received session data retransmission request is not for the session
  • the first session data retransmission request of the data the BM-SC does nothing, that is, the BM-SC is no longer Request the content providing server to provide the session data.
  • the BM-SC aggregates the signaling of the session data retransmission request, reduces the signaling traffic in the wireless network, and saves wireless network resources.
  • Step A6 After the content providing server provides session data that needs retransmission to the BM-SC requesting session data, the BM-SC initiates the MBMS session start process when it can send the session data, and according to the multicast / broadcast to which the session data belongs
  • the downstream node list of services sends a session data start message to the GGSN under its jurisdiction.
  • the session data start message carries not only session information, but also quality of service (QoS) parameters, and multicast / broadcast service domain information.
  • QoS quality of service
  • Step A7 After receiving the session data start message carrying the session information, the GGSN determines whether the session information is stored in the MBMS bearer context. If the session information is stored in the MBMS bearer context, the GGSN accepts retransmission of the session data. The session data is returned to the BM-SC to which it belongs, and the user plane resource is established. The session data begins to accept the response, which carries the information of the GGSN node and the user plane resource information. After receiving the session data, the BM-SC starts to accept the response.
  • GGSN node information is routing information for retransmitting session data
  • user plane resource information is resource information for retransmitting session data
  • the downstream node list sends a session data start message to the SGSN under its jurisdiction.
  • the session data start message carries not only session information, but also QoS parameters, and multicast / broadcast service domain information. If the session information is not stored in the MBMS bearer context, the GGSN rejects the retransmission of the session data and returns the session data to the BM-SC to which it belongs to start a rejection response.
  • Step A8 After receiving the session data start message carrying the session information, the SGSN determines whether the session information is stored in the MBMS bearer context. If the session information is stored in the MBMS bearer context, the SGSN accepts retransmission of the session data. The session data is returned to the GGSN to which it belongs, and the user plane resource is established. The session data is opened. The initial acceptance response carries the information of the SGSN node and the user plane resource information. After the GGSN receives the session data and starts accepting the response, it stores the SGSN node information and the user plane resource information. The SGSN node information is the routing information for retransmitting the session data.
  • the user The plane resource information is the resource information for retransmitting the session data; then the SGSN sends a session data start message to the RC under its jurisdiction according to the downstream node list of the multicast / broadcast service to which the session data belongs.
  • the session data start message not only carries the session data
  • the session information also carries QoS parameters, multicast / broadcast service domain information, and so on. If the session information is not stored in the MBMS bearer context, the SGSN rejects the retransmission of the session data, returns the session data to the GGSN to which it belongs, and starts a rejection response.
  • Step A9 After receiving the session data start message carrying the session information, the RNC determines whether the session information is stored in the MBMS service context. If the session information is stored in the MBMS service context, the RNC accepts retransmission of the session data. Return the session data to its SGSN and start accepting the response to establish user plane resources.
  • the session data start accepting response carries the RNC information and user plane resource information.
  • the SGSN After receiving the session data and starting accepting the response, the SGSN stores the RNC information and the user. Plane resource information, RNC information is routing information for retransmitting session data, and user plane resource information is resource information for retransmitting session data. If the session information is not stored in the MBMS service context, the RNC rejects the retransmission of the session data and returns the session data to the SGSN to which it belongs to start a rejection response.
  • Step A10 When the BM-SC retransmits the session data, it no longer retransmits the session data to all the GGSNs under its jurisdiction based on the list of downstream nodes of the multicast / broadcast service to which the retransmitted session data belongs, but according to the GGSN stored in step A7.
  • the node information through the established user plane resource, retransmits the session data to the corresponding GGSN that has returned the session data retransmission acceptance response under its jurisdiction.
  • the retransmitted session data can be encoded using a coding method with stronger error correction capability and higher reliability.
  • the coding method can be a forward error correction coding method, an increased redundancy coding method, or a deeper interleaved depth coding. Way, etc.
  • Step All After receiving the retransmission session data, the GGSN no longer retransmits the session data to all the SGSNs under its jurisdiction according to the list of downstream nodes of the multicast / broadcast service to which the retransmission session data belongs, but according to the SGSN stored in step A8.
  • the node information retransmits the session data to the corresponding SGSN that has returned the session data retransmission acceptance response through the established user plane resource.
  • Step A12 After receiving the retransmission session data, the SGSN no longer retransmits the session data to all RCs under its jurisdiction according to the list of downstream nodes of the multicast / broadcast service to which the retransmission session data belongs, but according to the RNC stored in step A9 Information, through the established user plane resource, to the corresponding RNC that resends the session data retransmission acceptance response under its jurisdiction to retransmit the session data.
  • Step A13 When the RNC receives the retransmission session data, it retransmits the session data to the communication terminal located in the corresponding cell by multicast / broadcast according to the cell information recorded by it.
  • the above-mentioned implementation process of session data retransmission only includes the operation that the RNC returns a session data retransmission response to the communication terminal.
  • the session data retransmission response can be returned to the downstream node to prevent the upstream node from receiving a large number of session data retransmission requests sent by the downstream node for the same session data, and to reduce the flow of uplink session data retransmission request signaling.
  • the specific implementation process includes The following steps:
  • Steps B1 to B2 are the same as steps A1 to A2.
  • Step B3 After receiving the session data retransmission request carrying the session information, the SGSN determines whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data is retransmitted, The transmission request is the first session data retransmission request for the session data, then the SGSN returns a session data retransmission response to all RNCs under its jurisdiction through multicast / broadcast, notifying the RNC that it has accepted the session data retransmission request, and Store the session information of the session data in the MBMS bearer context, and then send a session data retransmission request to the GGSN to which it belongs, where the session data retransmission request carries the session information; If the session data retransmission request is not the first session data retransmission request for the session data, the SGSN no longer sends a session data retransmission request to the GGSN to which it belongs.
  • the R C may generate a random delay within a certain length of time before sending a session data retransmission request to the SGSN to which it belongs; then the communication terminal waits for the session data retransmission response returned by the SGSN within the random delay. If the RNC receives a session data retransmission response returned by the SGSN within a random delay, it will no longer send a session data retransmission request to the SGSN to which it belongs, and stop the timing of the random delay; if the RC is within the random delay, If the session data retransmission response returned by the SGSN is not received, the session data retransmission request is sent to the SGSN to which it belongs, and then the timing of the random delay can be directly ended, instead of waiting for the SGSN to return a session data retransmission response; it can also be generated again.
  • each RNC belonging to the same SGSN can send session data retransmission requests to the SGSN at different times, avoiding that the SGSN receives a large number of session data retransmission requests at the same time, and reduces the processing speed of the SGSN; and It can avoid network congestion caused by a large number of RNCs sending session data retransmission requests to the SGSN at the same time.
  • the SGSN may be between the time when the SGSN receives the first session data retransmission request and returns a session data retransmission response to the RNC under its jurisdiction. Session data retransmission request.
  • Step B4 After receiving the session data retransmission request carrying the session information, the GGSN determines whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data is retransmitted, The transmission request is the first session data retransmission request for the session data, then the GGSN returns a session data retransmission response to all the SGSNs under its control by multicast / broadcast, notifying the SGSN that it has accepted the session data retransmission request, and Store session information of session data in the MBMS bearer context, and then send it to the BM-SC Send a session data retransmission request, where the session data retransmission request carries session information; if the received session data retransmission request is not the first session data retransmission request for the session data, the GGSN no longer sends it to it The associated BM-SC sends a session data retransmission request.
  • the SGSN may generate a random delay of a certain length of time before sending a session data retransmission request to the GGSN to which it belongs, and then the communication terminal waits for the session data retransmission response returned by the GGSN within the random delay.
  • the SGSN If the SGSN receives the session data retransmission response returned by the GGSN within the random delay time, it no longer sends a session data retransmission request to the GGSN to which it belongs and stops the timing of the random delay; if the SGSN is within the random delay time If the session data retransmission response returned by the GGSN is not received, the session data retransmission request is sent to the GGSN to which it belongs, and then the timing of the random delay can be directly ended, instead of waiting for the GGSN to return a session data retransmission response; it can also be generated again. Random delay or use the original random delay and continue to wait for the session data retransmission response returned by the GGSN within the length of the random delay.
  • the random delay timing can be started multiple times in this way, such as 4 times.
  • each SGSN belonging to the same GGSN can send session data retransmission requests to the GGSN at different times, avoiding that the GGSN receives a large number of session data retransmission requests at the same time, and reducing the processing speed of the GGSN; and It can avoid network congestion caused by a large number of SGSNs sending session data retransmission requests to the GGSN at the same time.
  • the GGSN may be between the time when the GGSN receives the first session data retransmission request and returns a session data retransmission response to the SGSN under its jurisdiction. Session data retransmission request.
  • Step B5 After receiving the session data retransmission request carrying the session information, the BM-SC determines whether the received session data retransmission request is the first session data retransmission request for the session data.
  • the data retransmission request is the first session data retransmission request for the session data, then the BM-SC returns a session data retransmission response to all GGSNs under its jurisdiction through multicast / broadcast, notifying the GGSN that it has accepted session data retransmission.
  • BM-SC no longer requests the content providing server to provide the session data.
  • the GGSN may generate a random delay of a certain length of time before sending a session data retransmission request to the BM-SC to which it belongs, and then the communication terminal waits for the session data retransmission response returned by the BM-SC within the random delay.
  • the GGSN If the GGSN receives a session data retransmission response returned by the BM-SC within a random delay, it will no longer send a session data retransmission request to its BM-SC and stop the timing of the random delay; if the GGSN is at random If no session data retransmission response is received from the BM-SC within the length of the delay, the session data retransmission request is sent to the BM-SC to which it belongs, and then the timing of the random delay can be directly ended, and no longer waiting for the BM-SC to return Session data retransmission response; it is also possible to generate a random delay again or use the original random delay, and continue to wait for the session data retransmission response returned by BM-SC within the length of the random delay.
  • the random delay timing can be started multiple times in this cycle. Such as 4 times.
  • each GGSN belonging to the same BM-SC can send session data retransmission requests to the BM-SC at different times, avoiding that the BM-SC receives a large number of session data retransmission requests at the same time, reducing the BM-SC processing speed; and can avoid network congestion caused by a large number of GGSNs sending session data retransmission requests to BM-SC at the same time.
  • the BM-SC receives a session data retransmission request for the same session data, it may be between the time when the BM-SC receives the first session data retransmission request and the session data retransmission response is returned to the BM-SC.
  • Steps B6 to B13 are the same as steps A6 to A13.
  • the upstream node can also store the downstream node information while storing the session information; then, the upstream node no longer performs the downstream of the multicast / broadcast service to which the retransmission session data belongs.
  • Node list sending retransmission session data start messages to all downstream nodes under its jurisdiction, but only to downstream nodes that store node information Send the session data start message; downstream nodes that receive the session data start message no longer need to determine whether the downstream node has stored the corresponding session information, directly accept the retransmission of the session data, and establish a user plane resource.
  • the specific implementation process includes the following steps: :
  • Steps C1 to C2 are the same as steps A1 to A2.
  • Step C3 After receiving the session data retransmission request carrying the session information, the SGSN determines whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data is retransmitted, The transmission request is the first session data retransmission request for the session data. The SGSN stores the RC information of the session data retransmission request, stores the session information of the session data in the MBMS bearer context, and then sends the session data to the GGSN to which it belongs.
  • the session data retransmission request carries session information; if the received session data retransmission request is not the first session data retransmission request for the session data, the SGSN only stores the transmission session The RC information of the data retransmission request no longer sends a session data retransmission request to the GGSN to which it belongs.
  • Step C4 After receiving the session data retransmission request carrying the session information, the GGSN determines whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data is retransmitted, The transmission request is the first session data retransmission request for the session data.
  • the GGSN stores the SGSN node information that sent the session data retransmission request, stores the session information of the session data in the MBMS bearer context, and then sends the session data to the
  • the BM-SC sends a session data retransmission request, and the session data retransmission request carries session information; if the received session data retransmission request is not the first session data retransmission request for the session data, the GGSN only Store the information of the SGSN node that sent the session data retransmission request, and no longer send the session data retransmission request to the BM-SC to which it belongs.
  • Step C5 After receiving the session data retransmission request carrying the session information, the BM-SC determines whether the received session data retransmission request is the first session data retransmission request for the session data, and if the received session The data retransmission request is the first meeting of the session data.
  • Data retransmission request the BM-SC stores information of the GGSN node that sent the session data retransmission request, and requests the content providing server to provide the session data according to the session information; if the received session data retransmission request is not for the session data
  • the first session data retransmission request the BM-SC only stores the information of the GGSN node that sent the session data retransmission request, and no longer requests the content providing server to provide the session data.
  • Step C6 After the content providing server provides the session data that needs to be retransmitted to the BM-SC requesting the session data, the BM-SC initiates the MBMS session initiation process when it can send the session data, and then according to the stored GGSN node information, The corresponding GGSN sends a session data start message.
  • Step C7 After receiving the session data start message, the GGSN accepts the retransmission of the session data, returns the session data to the BM-SC to which it belongs, and starts a response to establish a user plane resource.
  • the session data starts to accept the response that carries the GGSN node.
  • Information and user plane resource information BM-SC stores the GGSN node information and user plane resource information after receiving the session data and starting to accept the response.
  • the GGSN then sends a session data start message to the corresponding SGSN according to the stored SGSN node information.
  • Step C8 After receiving the session data start message, the SGSN accepts the retransmission of the session data, returns the session data to the GGSN to which it belongs, and starts a response to establish a user plane resource.
  • the session data starts to accept the response and carries the information of the SGSN node and User plane resource information;
  • the GGSN After receiving the session data and starting to accept the response, the GGSN stores SGSN node information and user plane resource information. The SGSN then sends a session data start message to the corresponding RNC according to the stored R C information.
  • Step C9 After receiving the session data start message, the RNC accepts the retransmission of the session data, returns the session data to the SGSN to which it belongs, and starts to accept the response, and establishes a user plane resource.
  • the session data begins to accept the response and carries the information of the RNC and the user. Plane resource information; SGSN stores RC information and user plane resource information after receiving session data and accepting the response.
  • Steps CIO to C13 are the same as steps A10 to A13.
  • the session data is retransmitted in the cell under the jurisdiction of the RNC, that is, the RNC retransmits the session data to the communication terminal located in the cell under its jurisdiction.
  • the most cost-effective way is to enable the RNC to retransmit the session data only to the communication terminals that need to retransmit the session data, so that the session data retransmission can achieve point-to-point transmission, thereby minimizing the occupation of network resources.
  • the specific implementation process includes the following steps: Step D1: The communication terminal detects that there is unreceived session data, and the network side needs to retransmit the session data. The communication terminal sends a session data retransmission request to the R C to which it belongs, and the session data retransmission request carries communication terminal information and session information.
  • Step D2 After receiving the session data retransmission request carrying the session information, the RNC determines whether the received session data retransmission request is the first session data retransmission request for the session data. If the received session data is retransmitted, The transmission request is the first session data retransmission request for the session data, and the RC returns a session data retransmission response to the communication terminal, informing the communication terminal that the network side has accepted the session data retransmission request sent by the RC, and then stores the request.
  • Communication terminal information and store session data session information in the MBMS service context, and then send a session data retransmission request to the SGSN to which it belongs, where the session data retransmission request carries the session information; if the received session data is retransmitted If the request is not the first session data retransmission request for the session data, the RNC records the communication terminal information and may return a session data retransmission response to the communication terminal.
  • Steps D3 to D12 are the same as steps A3 to A12.
  • Step D13 When the RNC receives the retransmission session data, it retransmits the session data to the corresponding communication terminal according to the communication terminal information recorded by the RNC.
  • the communication terminal may send a session data retransmission request to the RNC to which it belongs through a random access process, or may send a session data retransmission to the RNC through a shared channel.
  • the RNC to which the communication terminal belongs refers to the RC where the communication terminal is currently located.
  • the first session data retransmission request described above is for a session data transmission, and the upstream node receives the first session data retransmission request sent by the downstream node under its jurisdiction, that is, a transmission for a session data Request for retransmission of the initial session data.
  • a transmission for a session data Request for retransmission of the initial session data For example, for the communication terminal and the network side, after the session data transmission of the multicast service is performed, 50% of the communication terminals in the multicast group do not receive the session data, and these communication terminals need to request the network side to retransmit the session data.
  • Session data so send session data retransmission requests to the network side in succession, so the first session data retransmission request received by the network side is the initial session data retransmission of the current session data retransmission for 50% of the communication terminals.
  • the 50% of the communication terminals still do not receive the session data, which accounts for 10% of the number of multicast group communication terminals.
  • These communication terminals still need the network side to respond to Session data is retransmitted again. Therefore, session data retransmission requests are sent to the network side.
  • the first session data retransmission request received by the network side is the current session data retransmission for 10% of the communication terminals.
  • Initial session data retransmission request is the initial session data retransmission request.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种組播 /广播业务中会话数据的传输方法
技术领域
本发明涉及数据传输技术，特别是指一种应用于组播 /广播业务中的 会话数据传输方法。 发明背景
随着第三代移动通信技术的发展， 第三代移动通信可比第二代移动 通信提供更高数据传输速率的服务， 从而使第三代移动通信支持多种业 务形式， 如视频电话、 图片下载、 高速浏览互联网 （ Internet )等业务。 第三代移动通信支持一种向无线网络中订阅了一些特定信息的用户同 时发送该信息的业务形式， 这些信息可为天气预报、 新闻短片、 体育比 赛集锦等。 根据上述业务同时发送的特点， 第三代移动通信引入了对组 播 /广播业务的描述。
单播业务的数据发送过程中， 每个分支上的节点， 都会根据归属于 该节点的所有最终用户数量复制数据， 然后根据归属于其各下游节点的 最终用户数量， 向相应下游节点发送相应份数的数据， 这样， 会占用过 多的传输资源， 尤其是对于根节点而言， 在整个数据传输过程中， 归属 于该根节点的每个最终用户始终占用着传输资源， 如图 1所示。
然而， 組播 /广播业务在数据的传输方式上， 与单播业务的本质区别 在于： 组播 /广播业务在将数据从源节点传输到目的节点的过程中， 进行 的都是单径转发， 即： 对于一个中间节点而言， 无论其下游包含多少个 期待接收数据的节点， 其上游节点总是向该中间节点发送一份数据； 该 中间节点收到数据后， 根据其下游期待接收数据的节点数量复制该数 据， 并向其下游各期待接收该数据的节点分发该数据， 这样， 组播 /广播 业务数据传输树的每一条分支都只有一份数据进行传输， 占用一份传输 资源， 根节点与其下游节点的数据传输也是如此， 如图 2所示。 组播业 务和广播业务的区别点仅在于： 组播业务只向订阅了某些信息的用户发 送相应信息， 广播业务则向无线网络中的所有用户发送信息。 由以上描 述可见， 通过组播 /广播业务同时向大量用户提供相同信息， 能够极大地 节省网絡资源。
图 3为支持组播 /广播业务的无线网络结构示意图， 如图 3所示， 现 有第三代合作伙伴计划 （3GPP ) 中支持组播 /广播业务的无线网络结构 为广播 /组播业务中心（BM-SC ) 301通过 Gmb接口或 Gi接口与网关通 用分组无线业务（ GPRS )支持节点（ GGSN, Gateway GPRS Support Node ) 302相连， 一个 BM-SC 301可与多个 GGSN 302相连； GGSN 302通过 Gn/Gp接口与服务 GPRS支持节点（ SGSN, Serving GPRS Support Node ) 303相连， 一个 GGSN 302可与多个 SGSN 303相连； SGSN 303可通过 Iu接口与通用移动通信系统（UMTS ) 陆地无线接入网 （UTRAN ) 304 相连， 然后 UTRAN 304通过 Uu接口与通信终端 306相连， SGSN 303 也可通过 Iu/Gb 接口与全球移动通信系统 （GSM ) 增强无线接入网 ( GERAN ) 305相连， 然后 GERAN 305通过 Um接口与通信终端 307 相连。
无线网络通常会对同一会话数据进行多次重传， 以保证通信终端能 够准确可靠地接收无线网络下发的组播 /广播会话数据。 BM-SC在发送 一个会话数据后， 会在一定的时间之后重新发送该会话数据。 对于无线 网络中的其他下游节点，如 GGSN、 SGSN,无线接入网絡（RAN, Radio Access Network )中的无线网络控制器（ RNC , Radio Network Controller ) 等， 对重新发送的会话数据进行传输， 重新发送的会话数据与普通的组 播 /多播业务数据没有区别， 同样需要建立相应的组播 /多播业务承载， 然后将该会话数据发送给组播群组内或无线网络中的所有通信终端。 但是， 对会话数据进行简单重传， 无法确保通信终端收到相应的会 话数据， 又由于对会话数据进行多次重传， 势必会造成对网络资源的浪 费， 使组播 /广播业务节省网络资源的优势大大减弱， 并提高了組播 /广 播业务的投资成本。在整个无线网络中，各个地区的网络条件并不一致， 一些覆盖区域的无线网络性能较好， 位于这些区域的通信终端能够正确 接收会话数据； 一些覆盖区域的无线网络性能较差， 位于这些区域的通 信终端无法正确接收会话数据。 目前， 不存在选择性重传会话数据的机 制， 在重传会话数据时没有针对需要重传会话数据的无线网络覆盖区域 或通信终端进行， 而是在整个组播群组或整个无线网络中进行的， 会话 数据的重传包括了不需要进行会话数据重传的区域， 浪费了网络资源。 发明内容
有鉴于此，本发明的目的在于提供一种组播 /广播业务中会话数据的 传输方法， 使组播 /广播业务会话数据的传输更加可靠， 并能够有效节省 网络资源。
为了达到上述目的 ,本发明提供了一种组播 /广播业务中会话数据的 传输方法， 通信终端检测到有未收到的组播 /广播业务会话数据， 该方法 包含以下步骤：
A、 通信终端向所属的无线网络控制器发送携带有会话信息的会话 数据重传请求；
B、 无线网络控制器接收所述会话数据重传请求， 向所属的服务支 持中心发送携带有会话信息的会话数据重传请求；
C、 服务支持中心接收所述会话数据重传请求， 根据会话信息获取 需要重传的会话数据， 然后向管辖的无线网络控制器发送会话数据开始 消息；
D、 所述服务支持中心管辖的发送了会话数据重传请求的无线网络 控制器接收所述会话数据开始消息， 向该服务支持中心返回会话数据开 始接受响应， 建立用户平面资源；
E、 服务支持中心通过所述用户平面资源， 向管辖的返回了会话数 据开始接受响应的无线网络控制器重传会话数据， 无线网络控制器收到 重传数据后， 向管辖的通信终端重传收到的会话数据。
步骤 B中所述无线网络控制器接收所述会话数据重传请求之后， 进 一步包括： 无线网络控制器向管辖的通信终端返回会话数据重传响应。
所述步骤 A之前进一步包括以下步骤：
A01、 通信终端生成随机延迟， 并启动随机延迟定时器的计时； A02、 通信终端判断是否在随机延迟计时的时间范围内收到无线网 络控制器返回的会话数据重传响应， 如果是， 停止随机延迟定时器的计 时， 否则， 执行步骤八。
执行所述步骤 A之后， 进一步包括： 返回执行步骤 A01。
步骤 B中所述无线网络控制器接收所述会话数据重传请求之后， 进 一步包括： 无线网絡控制器存储会话信息。
步骤 B中所述向所属的服务支持中心发送携带有会话信息的会话数 据重传请求之前， 进一步包括： 无线网络控制器根据存储的会话信息， 判断收到的会话数据重传请求是否为针对该会话数据的起始会话数据 重传请求， 如果是， 向所属的服务支持中心发送携带有会话信息的会话 数据重传请求； 否则， 不进行操作。
步骤 C中所述会话数据开始消息中携带有会话信息，
步骤 C中所述向管辖的无线网络控制器发送会话数据开始消息是： 服务支持中心根据所述会话数据所属组播 /广播业务的无线网絡控制器 列表， 向管辖的无线网络控制器发送会话数据开始消息 , 所述步骤 C之后进一步包括： 服务支持中心管辖的无线网络控制器 接收会话数据开始消息， 判断是否存储有所述会话信息， 如果是， 向该 服务支持中心返回携带有用户平面资源信息的会话数据开始接受响应， 建立用户平面资源， 否则， 向所述服务支持中心返回会话数据开始拒绝 响应。
所述步骤 B进一步包括： 无线网络控制器记录通信终端所在小区信 所述步骤 C进一步包括： 服务支持中心向管辖的无线网络控制器返 回会话数据重传响应。
步骤 B中所述向所属的服务支持中心发送携带有会话信息的会话数 据重传请求之前， 进一步包括以下步骤：
Bl、无线网络控制器生成随机延迟，并启动随机延迟定时器的计时；
B2、 无线网络控制器是否在随机延迟计时的时间范围内收到服务支 持中心返回的会话数据重传响应，如果是，停止随机延迟定时器的计时， 否则， 向所属的服务支持中心发送携带有会话信息的会话数据重传请 求。
执行所述步骤 B之后， 进一步包括： 返回执行步骤 Bl。
所述步骤 C包括： 服务支持中心接收所述会话数据重传请求， 存储 无线网络控制器信息， 根据会话信息获取需要重传的会话数据， 然后根 据存储的无线网络控制器信息， 向对应于所述无线网络控制器信息的无 线网络控制器发送会话数据开始消息。
步骤 A中所述会话数据重传请求进一步携带有通信终端信息， 步驟 B中所述无线网络控制器接收所述会话数据重传请求之后， 进 一步包括： 无线网络控制器存储通信终端信息， 步骤 E中所述向管辖的通信终端重传收到的会话数据包括： 无线网 络控制器 4艮据存储的通信终端信息， 向管辖的对应于所述通信终端信息 的通信终端重传收到的会话数据。
步骤 C中所述根据会话信息获取需要重传的会话数据包括： 服务支 持中心根据会话信息， 请求内容提供服务器提供对应于会话信息的会话 数据， 内容提供服务器向该服务支持中心提供所述会话数据。
步骤 C中所述服务支持中心接收所述会话数据重传请求之后， 进一 步包括： 服务支持中心存储会话信息。
步骤 C中所述服务支持中心接收所述会话数据重传请求之后， 进一 步包括： 服务支持中心根据存储的会话信息， 判断收到的会话数据重传 请求是否为针对该会话数据的起始会话数据重传请求， 如果是， 请求内 容提供服务器提供对应于会话信息的会话数据， 否则， 不进行操作。
步驟 D中所述会话数据开始响应携带有无线网络控制器信息， 所述步骤 D之后进一步包括： 服务支持中心存储无线网絡控制器信 步驟 E中所述服务支持中心通过用户平面资源， 向管辖的返回了会 话数据开始接受响应的无线网络控制器重传会话数据， 包括： 服务支持 中心才艮据存储的无线网络控制器信息， 通过用户平面资源， 向所述无线 网络控制器重传会话数据。
通信终端通过随机接入过程， 或共享信道向无线网络控制器发送所 述会话数据重传请求。
通信终端通过滑动窗口机制检测是否有未收到的会话数据。
根据本发明提出的方案，通信终端在检测到有未收到的会话数据时， 向网络侧发送会话数据重传请求， 网络侧重传会话数据时， 只向期待接 收该会话数据的下游节点重传会话数据， 并能够向期待接收会话数据的 通信终端重传会话数据， 实现了有针对性进行会话数据重传的目的， 在 合理使用无线网络和核心网络资源的前提下 , 使通信终端及下游节点能 够更加可靠地接收其期待接收的会话数据。通过本发明节省了组播 /广播 业务的投资成本， 并提高了用 >的满意度。 另外， 本发明提供了多种实 现方式， 可根据实际应用情况进行灵活地选择， 并可在具体实现过程没 有冲突的情况下， 将几种实现方式进行组合， 从而实现对会话数据进行 重传的最理想实现方式。 附图简要说明
图 1为单播业务传输过程示意图；
图 2为组播 /广播业务传输过程示意图；
图 3为支持组播 /广播业务的无线网络结构示意图；
图 4为本发明中会话数据重传过程示意图。 实施本发明的方式
下面结合附图对本发明进行详细描述。
本发明中， 通信终端检测到有未收到的会话数据后， 向其所属的 RNC发送会话数据重传请求， RNC收到会话数据重传请求后， 向其所 属的服务支持中心发送会话数据重传请求； 服务支持中心收到会话数据 重传请求后， 获取需要重传的会话数据， 然后向其管辖的 RNC发送会 话数据开始消息，服务支持中心管辖的发送了会话数据重传请求的 RNC 向服务支持中心返回会话数据开始接受响应， 建立用户平面资源； 服务 支持中心获取需要重传的会话数据， 通过建立的用户平面资源向其管辖 的返回了会话数据开始接受响应的 RNC重传会话数据， R C向通信终 端重传会话数据。以上所述服务支持中心包括 SGSN、 GGS 和 BM-SC。 图 4为本发明中会话数据重传过程示意图， 如图 4所示， 对会话数 据进行重传的实现过程大致包括以下步骤：
步骤 401〜步驟 405: 通信终端检测到有未收到的会话数据， 向其所 属的 RNC发送会话数据重传请求， 请求网络侧向其重新发送未收到的 会话数据； RNC收到会话数据重传请求后， 向其所属的 SGSN发送会话 数据重传请求； SGSN收到会话数据重传请求后， 向其所属的 GGSN发 送会话数据重传请求； GGSN 收到会话数据重传请求后， 向其所属的 BM-SC发送会话数据重传请求。 以上步驟为反向传输重传请求、建立重 传树的过程。
步骤 406〜步驟 409: BM-SC收到会话数据重传请求后，获取需要重 传的会话数据， 并在可发送该会话数据时， 发起多媒体广播 /组播服务 ( MBMS, Multimedia Broadcast/Multicast Service )会话开始过程， 然后 向其管辖的 GGSN发送会话数据开始消息， 该 BM-SC管辖的发送了会 话数据重传请求的 GGSN收到会话数据开始消息后，向其所属的 BM-SC 返回会话数据开始接受响应， 建立用户平面资源； 返回了会话数据开始 接受响应的 GGSN向其管辖的 SGSN发送会话数据开始消息，该 GGSN 管辖的发送了会话数据重传请求的 SGSN收到会话数据开始消息后， 向 其所属的 GGSN返回会话数据开始接受响应， 建立用户平面资源； 返回 了会话数据开始接受响应的 SGSN向其管辖的 R C发送会话数据开始 消息， 该 SGSN管辖的发送了会话数据重传请求的 RNC收到会话数据 开始消息后， 向其所属的 SGSN返回会话数据开始接受响应， 建立用户 平面资源。 以上所述步骤为正向会话激活过程。
步骤 410〜步骤 413: BM-SC通过建立的用户平面资源向 GGSN重 传会话数据； GGSN收到会话数据后，通过建立的用户平面资源向 SGSN 重传该会话数据； SGSN收到会话数据后， 通过建立的用户平面资源向 RNC重传该会话数据； RNC收到会话数据后， 向通信终端重传会话数 据。 以上所述步骤为正向会话数据传输过程。
下面对本发明的具体实现过程进行详细描述， 重传会话数据的实现 过程具体包括以下步骤：
步骤 A1: 通信终端检测到有未收到的会话数据， 例如， 网络侧会事 先通知通信终端将向其发送会话数据， 但该通信终端却没有收到相应会 话数据， 或通信终端通过滑动窗口机制检测到有未收到的会话数据， 需 要网络侧重传该会话数据。 通信终端向其所属的 RNC发送会话数据重 传请求， 该会话数据重传请求中携带有会话信息， 会话信息可包括业务 标识和会话标识。
' 步骤 A2: R C收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求， 则该 R C通过组播 /广播方式向其管辖区域的所有通信 终端返回会话数据重传响应， 通知通信终端网络侧已接受会话数据重传 请求， 然后在 MBMS业务上下文（MBMS Service Context )中存储会话 数据的会话信息， 并记录通信终端所属小区的信息， 然后向其所属的 SGSN发送会话数据重传请求，该会话数据重传请求中携带有会话信息； 如果收到的会话数据重传请求不是针对该会话数据的第一个会话数据 重传请求， 则该 RNC仅对通信终端所属小区的信息进行记录。 R C可 通过判断是否存储有会话数据重传请求中携带的会话信息， 判断出收到 的会话数据重传请求是否为针对该会话数据的第一个会话数据重传请 求， 如果存储有会话数据重传请求中携带的会话信息， 则收到的会话数 据重传请求是针对该会话数据的第一个会话数据重传请求； 如果没有存 储会话数据重传请求中携带的会话信息， 则收到的会话数据重传请求不 是针对该会话数据的第一个会话数据重传请求。
通信终端可在向其所属的 R C发送会话数据重传请求之前， 生成 一定时间长度的随机延迟； 然后通信终端在该随机延迟的时间长度内等 待 RNC返回会话数据重传响应。 如果通信终端在随机延迟的时间长度 内收到 R C返回的会话数据重传响应， 则不再向其所属的 RNC发送会 话数据重传请求， 并停止随机延迟的计时； 如果通信终端在随机延迟的 时间长度内没有收到 RNC 返回的会话数据重传响应， 则向其所属的 RNC发送会话数据重传请求， 然后可直接结束随机延迟的计时， 不再等 待 RNC返回会话数据重传响应； 也可再次生成随机延迟或使用原随机 延迟， 并在该随机延迟的时间长度内继续等待 RNC返回的会话数据重 传响应， 可如此循环多次启动随机延迟计时， 如 4次。 通过通信终端生 成的随机延迟， 可使位于同一小区的各通信终端在不同时刻向 R C发 送会话数据重传请求， 避免因大量通信终端在同一时刻向 RNC发送会 话数据重传请求， 而导致的网络拥塞。
如果 RNC 收到同一小区其他通信终端针对同一会话数据的会话数 据重传请求， 可能是在 RNC收到第一个会话数据重传请求和向位于该 小区的所有通信终端返回会话数据重传响应之间， 该小区其他通信终端 发送的会话数据重传请求。 RNC收到第一个会话数据重传请求后， 如果 再收到针对该会话数据的会话数据重传请求时， 则只是对小区信息进行 记录， 以使其在重传会话数据时， 能够根据记录的小区信息只向需要重 传该会话数据的小区重传会话数据， 从而实现在无线网络覆盖区域内， 有针对性地重传会话数据， 进而节省无线网络资源； 并且 RNC 不再向 其所属的 SGSN发送会话数据重传请求， 这样， 可减少网络中的信令流 量， 实现节省无线网络资源的目的。
步骤 A3: SGSN收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求 , 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求，则该 SGSN在 MBMS承载上下文（ MBMS Bearer Context ) 中存储会话数据的会话信息，然后向其所属的 GGSN发送会话数据重传 请求， 该会话数据重传请求中携带有会话信息； 如果收到的会话数据重 传请求不是针对该会话数据的第一个会话数据重传请求， 则该 SGSN不 作任何操作，即该 SGSN不再向其所属的 GGSN发送会话数据重传请求， 这样， SGSN对会话数据重传请求的信令进行汇聚， 减少无线网絡中的 信令流量， 实现对无线网络资源的节省。
步骤 A4: GGSN收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求， 则该 GGSN在 MBMS承载上下文中存储会话数据的会 话信息， 然后向其所属的 BM-SC发送会话数据重传请求， 该会话数据 重传请求中携带有会话信息； 如果收到的会话数据重传请求不是针对该 会话数据的第一个会话数据重传请求， 则该 GGSN不作任何操作， 即该 GGSN不再向其所属的 BM-SC发送会话数据重传请求， 这样， GGSN 对会话数据重传请求的信令进行汇聚， 减少网络中的信令流量， 实现对 网络资源的节省。
步骤 A5: BM-SC收到携带有会话信息的会话数据重传请求后， 判 断收到的会话数据重传请求是否为针对该会话数据的第一个会话数据 重传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会 话数据重传请求， 则该 BM-SC根据会话信息， 请求内容提供服务器提 供该会话数据； 如果收到的会话数据重传请求不是针对该会话数据的第 一个会话数据重传请求， 则该 BM-SC不作任何操作， 即该 BM-SC不再 请求内容提供服务器提供该会话数据，这样， BM-SC对会话数据重传请 求的信令进行汇聚， 减少无线网络中的信令流量， 实现对无线网絡资源 的节省。
步骤 A6: 内容提供服务器向请求会话数据的 BM-SC提供需要重传 的会话数据后， 该 BM-SC在可发送该会话数据时， 发起 MBMS会话开 始过程， 根据该会话数据所属组播 /广播业务的下游节点列表， 向其管辖 的 GGSN发送会话数据开始消息，该会话数据开始消息中不仅携带有会 话信息， 还携带有服务质量（QoS )参数、 组播 /广播业务域信息等。
步骤 A7: GGSN收到携带有会话信息的会话数据开始消息后， 判断 MBMS承载上下文中是否存储有该会话信息， 如果 MBMS承载上下文 中存储有该会话信息， 则该 GGSN接受会话数据的重传， 向其所属的 BM-SC返回会话数据开始接受响应， 建立用户平面资源， 该会话数据开 始接受响应中携带有该 GGSN节点的信息和用户平面资源信息； BM-SC 收到会话数据开始接受响应后，存储 GGSN节点信息和用户平面资源信 息， GGSN节点信息是重传会话数据的路由信息， 用户平面资源信息是 重传会话数据的资源信息； 然后该 GGSN根据该会话数据所属组播 /广 播业务的下游节点列表， 向其管辖的 SGSN发送会话数据开始消息， 该 会话数据开始消息中不仅携带有会话信息， 还携带有 QoS参数、 组播 / 广播业务域信息等。 如果 MBMS承载上下文中没有存储该会话信息， 则该 GGSN拒绝会话数据的重传， 向其所属的 BM-SC返回会话数据开 始拒绝响应。
步骤 A8: SGSN收到携带有会话信息的会话数据开始消息后， 判断 MBMS承载上下文中是否存储有该会话信息， 如果 MBMS承载上下文 中存储有该会话信息， 则该 SGSN接受会话数据的重传， 向其所属的 GGSN返回会话数据开始接受响应， 建立用户平面资源， 该会话数据开 始接受响应中携带有该 SGSN节点的信息和用户平面资源信息； GGSN 收到会话数据开始接受响应后， 存储 SGSN节点信息和用户平面资源信 息， SGSN节点信息是重传会话数据的路由信息， 用户平面资源信息是 重传会话数据的资源信息；然后该 SGSN根据该会话数据所属组播 /广播 业务的下游节点列表， 向其管辖的 R C发送会话数据开始消息， 该会 话数据开始消息中不仅携带有会话信息， 还携带有 QoS参数、 组播 /广 播业务域信息等。 如果 MBMS承载上下文中没有存储该会话信息， 则 该 SGSN拒绝会话数据的重传，向其所属的 GGSN返回会话数据开始拒 绝响应。
步骤 A9: RNC收到携带有会话信息的会话数据开始消息后， 判断 MBMS业务上下文中是否存储有该会话信息， 如果 MBMS业务上下文 中存储有该会话信息， 则该 RNC接受会话数据的重传， 向其所属的 SGSN返回会话数据开始接受响应， 建立用户平面资源， 该会话数据开 始接受响应中携带有该 RNC信息和用户平面资源信息； SGSN收到会话 数据开始接受响应后， 存储 RNC信息和用户平面资源信息， RNC信息 是重传会话数据的路由信息， 用户平面资源信息是重传会话数据的资源 信息。 如果 MBMS业务上下文中没有存储该会话信息， 则该 RNC拒绝 会话数据的重传， 向其所属的 SGSN返回会话数据开始拒绝响应。
步骤 A10: BM-SC重传会话数据时， 不再根据重传会话数据所属组 播 /广播业务的下游节点列表， 向其管辖的所有 GGSN重传会话数据， 而是根据步骤 A7中存储的 GGSN节点信息，通过建立的用户平面资源， 向其管辖的返回了会话数据重传接受响应的相应 GGSN重传会话数据。 可对重传的会话数据采用纠错能力更强、 可靠性更高的编码方式进行编 码，所述编码方式可为前向错误纠正编码方式、或增加冗余度编码方式、 或加深交织深度编码方式等。 步骤 All: GGSN收到重传会话数据后， 不再根据重传会话数据所 属组播 /广播业务的下游节点列表， 向其管辖的所有 SGSN重传会话数 据， 而是根据步骤 A8中存储的 SGSN节点信息， 通过建立的用户平面 资源， 向其管辖的返回了会话数据重传接受响应的相应 SGSN重传会话 数据。
步骤 A12: SGSN收到重传会话数据后， 不再根据重传会话数据所 属组播 /广播业务的下游节点列表，向其管辖的所有 R C重传会话数据， 而是根据步驟 A9中存储的 RNC信息， 通过建立的用户平面资源， 向其 管辖的返回了会话数据重传接受响应的相应 RNC重传会话数据。
步骤 A13: RNC收到重传会话数据时， 根据其记录的小区信息， 通 过组播 /广播方式向位于相应小区的通信终端重传会话数据。
以上描述的会话数据重传实现过程中， 仅包括 RNC 向通信终端返 回会话数据重传响应的操作， 实际上， 网络侧的每个上游节点在收到第 一个会话数据重传请求后， 都可向下游节点返回会话数据重传响应， 避 免上游节点收到大量下游节点向其发送的针对同一会话数据的会话数 据重传请求， 减少上行会话数据重传请求信令的流量， 具体实现过程包 括以下步骤：
步驟 B 1〜步驟 B2与步骤 A1〜步骤 A2相同。
步骤 B3: SGSN收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求， 则该 SGSN通过组播 /广播方式向其管辖的所有 RNC返 回会话数据重传响应 ,通知 RNC已接受会话数据重传请求，并在 MBMS 承载上下文中存储会话数据的会话信息，然后向其所属的 GGSN发送会 话数据重传请求， 该会话数据重传请求中携带有会话信息； 如果收到的 会话数据重传请求不是针对该会话数据的第一个会话数据重传请求， 则 该 SGSN不再向其所属的 GGSN发送会话数据重传请求。
R C可在向其所属的 SGSN发送会话数据重传请求之前，生成一定 时间长度内的随机延迟； 然后通信终端在该随机延迟的时间长度内等待 SGSN返回的会话数据重传响应。如果 RNC在随机延迟的时间长度内收 到 SGSN返回的会话数据重传响应， 则不再向其所属的 SGSN发送会话 数据重传请求， 并停止随机延迟的计时； 如果 R C在随机延迟的时间 长度内没有收到 SGSN返回的会话数据重传响应， 则向其所属的 SGSN 发送会话数据重传请求， 然后可直接结束随机延迟的计时， 不再等待 SGSN返回会话数据重传响应； 也可再次生成随机延迟或使用原随机延 迟， 并在该随机延迟的时间长度内继续等待 SGSN返回的会话数据重传 响应， 可如此循环多次启动随机延迟计时， 如 4次。 通过 RNC生成的 随机延迟， 可使归属于同一 SGSN的各 RNC在不同时刻向 SGSN发送 会话数据重传请求，避免 SGSN在同一时刻收到大量会话数据重传请求， 降低该 SGSN的处理速度； 并可避免因大量 RNC在同一时刻向 SGSN 发送会话数据重传请求， 而导致的网络拥塞。
如果 SGSN收到针对同一会话数据的会话数据重传请求， 可能是在 SGSN收到第一个会话数据重传请求和向其管辖的 RNC返回会话数据 重传响应之间， 其管辖的其他 R C发送的会话数据重传请求。
步骤 B4: GGSN收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求 , 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求， 则该 GGSN通过组播 /广播方式向其管辖的所有 SGSN 返回会话数据重传响应， 通知 SGSN 已接受会话数据重传请求， 并在 MBMS承载上下文中存储会话数据的会话信息，然后向其所属的 BM-SC 发送会话数据重传请求， 该会话数据重传请求中携带有会话信息； 如果 收到的会话数据重传请求不是针对该会话数据的第一个会话数据重传 请求， 则该 GGSN不再向其所属的 BM-SC发送会话数据重传请求。
SGSN可在向其所属的 GGSN发送会话数据重传请求之前， 生成一 定时间长度的随机延迟； 然后通信终端在该随机延迟的时间长度内等待 GGSN返回的会话数据重传响应。 如果 SGSN在随机延迟的时间长度内 收到 GGSN返回的会话数据重传响应，则不再向其所属的 GGSN发送会 话数据重传请求， 并停止随机延迟的计时； 如果 SGSN在随机延迟的时 间长度内没有收到 GGSN返回的会话数据重传响应， 则向其所属的 GGSN发送会话数据重传请求， 然后可直接结束随机延迟的计时， 不再 等待 GGSN返回会话数据重传响应；也可再次生成随机延迟或使用原随 机延迟，并在该随机延迟的时间长度内继续等待 GGSN返回的会话数据 重传响应， 可如此循环多次启动随机延迟计时， 如 4次。 通过 SGSN生 成的随机延迟，可使所属于同一 GGSN的各 SGSN在不同时刻向 GGSN 发送会话数据重传请求，避免 GGSN在同一时刻收到大量会话数据重传 请求， 降低该 GGSN的处理速度； 并可避免因大量 SGSN在同一时刻向 GGSN发送会话数据重传请求， 而导致的网络拥塞。
如果 GGSN收到针对同一会话数据的会话数据重传请求，可能是在 GGSN收到第一个会话数据重传请求和向其管辖的 SGSN返回会话数据 重传响应之间， 其管辖的其他 SGSN发送的会话数据重传请求。
步骤 B5: BM-SC收到携带有会话信息的会话数据重传请求后， 判 断收到的会话数据重传请求是否为针对该会话数据的第一个会话数据 重传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会 话数据重传请求， 则该 BM-SC 通过组播 /广播方式向其管辖的所有 GGSN返回会话数据重传响应， 通知 GGSN已接受会话数据重传请求， 并根据会话信息请求内容提供服务器提供该会话数据； 如果收到的会话 数据重传请求不是针对该会话数据的第一个会话数据重传请求， 则该
BM-SC不再请求内容提供服务器提供该会话数据。
GGSN可在向其所属的 BM-SC发送会话数据重传请求之前， 生成 一定时间长度的随机延迟； 然后通信终端在该随机延迟的时间长度内等 待 BM-SC返回的会话数据重传响应。 如果 GGSN在随机延迟的时间长 度内收到 BM-SC返回的会话数据重传响应， 则不再向其所属的 BM-SC 发送会话数据重传请求， 并停止随机延迟的计时； 如果 GGSN在随机延 迟的时间长度内没有收到 BM-SC返回的会话数据重传响应， 则向其所 属的 BM-SC发送会话数据重传请求， 然后可直接结束随机延迟的计时， 不再等待 BM-SC返回会话数据重传响应； 也可再次生成随机延迟或使 用原随机延迟， 并在该随机延迟的时间长度内继续等待 BM-SC返回的 会话数据重传响应， 可如此循环多次启动随机延迟计时， 如 4次。 通过 GGS 生成的随机延迟， 可使所属于同一 BM-SC的各 GGSN在不同时 刻向 BM-SC发送会话数据重传请求，避免 BM-SC在同一时刻收到大量 会话数据重传请求，降低该 BM-SC的处理速度；并可避免因大量 GGSN 在同一时刻向 BM-SC发送会话数据重传请求， 而导致的网絡拥塞。
如果 BM-SC 收到针对同一会话数据的会话数据重传请求， 可能是 在 BM-SC收到第一个会话数据重传请求和向其管辖的 GGSN返回会话 数据重传响应之间 , 其管辖的其他 GGSN发送的会话数据重传请求。
步驟 B6〜步骤 B13与步骤 A6~步驟 A13相同。
另外， 上游节点在收到下游节点发送的会话数据重传请求后， 在存 储会话信息的同时， 还可存储下游节点信息； 然后上游节点不再根据重 传会话数据所属组播 /广播业务的下游节点列表，向其管辖的所有下游节 点发送重传会话数据开始消息， 而是只向存储了节点信息的下游节点发 送会话数据开始消息； 收到会话数据开始消息的下游节点不需再判断该 下游节点是否存储有相应会话信息， 直接接受会话数据的重传， 建立用 户平面资源即可， 具体实现过程包括以下步骤：
步骤 C1〜步骤 C2与步骤 A1〜步骤 A2相同。
步骤 C3: SGSN收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求， 则该 SGSN存储发送会话数据重传请求的 R C信息， 并在 MBMS承载上下文中存储会话数据的会话信息， 然后向其所属的 GGSN发送会话数据重传请求，该会话数据重传请求中携带有会话信息； 如果收到的会话数据重传请求不是针对该会话数据的第一个会话数据 重传请求， 则该 SGSN仅存储发送会话数据重传请求的 R C信息， 不 再向其所属的 GGSN发送会话数据重传请求。
步骤 C4: GGSN收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求，则该 GGSN存储发送会话数据重传请求的 SGSN节点信 息， 并在 MBMS承载上下文中存储会话数据的会话信息， 然后向其所 属的 BM-SC发送会话数据重传请求， 该会话数据重传请求中携带有会 话信息； 如果收到的会话数据重传请求不是针对该会话数据的第一个会 话数据重传请求，则该 GGSN仅存储发送会话数据重传请求的 SGSN节 点信息， 不再向其所属的 BM-SC发送会话数据重传请求。
步骤 C5: BM-SC收到携带有会话信息的会话数据重传请求后， 判 断收到的会话数据重传请求是否为针对该会话数据的第一个会话数据 重传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会 话数据重传请求， 则该 BM-SC存储发送会话数据重传请求的 GGSN节 点信息， 并根据会话信息请求内容提供服务器提供该会话数据； 如果收 到的会话数据重传请求不是针对该会话数据的第一个会话数据重传请 求， 则该 BM-SC仅存储发送会话数据重传请求的 GGSN节点信息， 不 再请求内容提供服务器提供该会话数据。
步骤 C6: 内容提供服务器向请求会话数据的 BM-SC提供需要重传 的会话数据后， 该 BM-SC在可发送该会话数据时， 发起 MBMS会话开 始过程，然后根据存储的 GGSN节点信息，向相应 GGSN发送会话数据 开始消息。
步骤 C7: GGSN收到会话数据开始消息后， 接受会话数据的重传， 向其所属的 BM-SC返回会话数据开始接受响应， 建立用户平面资源， 该会话数据开始接受响应携带有该 GGSN 节点的信息和用户平面资源 信息； BM-SC收到会话数据开始接受响应后， 存储 GGSN节点信息和 用户平面资源信息。 然后该 GGSN根据存储的 SGSN节点信息， 向相应 SGSN发送会话数据开始消息。
步骤 C8: SGSN收到会话数据开始消息后， 接受会话数据的重传， 向其所属的 GGSN返回会话数据开始接受响应， 建立用户平面资源， 该 会话数据开始接受响应携带有该 SGSN 节点的信息和用户平面资源信 息； GGSN收到会话数据开始接受响应后， 存储 SGSN节点信息和用户 平面资源信息。 然后该 SGSN根据存储的 R C信息， 向相应 RNC发送 会话数据开始消息。
步骤 C9: RNC收到会话数据开始消息后， 接受会话数据的重传， 向其所属的 SGSN返回会话数据开始接受响应， 建立用户平面资源， 该 会话数据开始接受响应携带有该 RNC 的信息和用户平面资源信息； SGSN收到会话数据开始接受响应后，存储 R C信息和用户平面资源信 步骤 CIO〜步骤 C13与步骤 A10〜步骤 A13相同。
此外， 以上各实现过程的描述中， 均以 RNC 管辖的小区为单位进 行会话数据的重传， 即 RNC向位于其管辖小区内的通信终端重传会话 数据， 为使网络资源的使用最为合理和最为节省， 可使 RNC仅向需要 重传会话数据的通信终端重传该会话数据， 使会话数据重传实现点到点 的传输，从而使网络资源的占用达到最低，具体实现过程包括以下步驟： 步骤 D1 :通信终端检测到有未收到的会话数据，需要网络侧重传该 会话数据。 通信终端向其所属的 R C发送会话数据重传请求， 该会话 数据重传请求中携带有通信终端信息和会话信息。
步骤 D2: RNC收到携带有会话信息的会话数据重传请求后， 判断 收到的会话数据重传请求是否为针对该会话数据的第一个会话数据重 传请求， 如果收到的会话数据重传请求是针对该会话数据的第一个会话 数据重传请求， 则该 R C向该通信终端返回会话数据重传响应， 通知 该通信终端网络侧已接受其发送的会话数据重传请求， 然后存储通信终 端信息， 并在 MBMS 业务上下文中存储会话数据的会话信息， 然后向 其所属的 SGSN发送会话数据重传请求， 该会话数据重传请求中携带有 会话信息； 如果收到的会话数据重传请求不是针对该会话数据的第一个 会话数据重传请求， 则该 RNC对通信终端信息进行记录， 并可向该通 信终端返回会话数据重传响应。
步驟 D3〜步骤 D12与步棟 A3〜步骤 A12相同。
步骤 D13: RNC收到重传会话数据时，根据其记录的通信终端信息， 向相应通信终端重传会话数据。
以上实现过程中， 通信终端可通过随机接入过程向其所属的 RNC 发送会话数据重传请求， 也可通过共享信道向 RNC发送会话数据重传 请求。 通信终端所属的 RNC是指通信终端当前所在的 R C。
以上所述的第一个会话数据重传请求是针对某次会话数据传输后， 上游节点收到其管辖的下游节点发送来的第一个会话数据重传请求， 即 针对某会话数据进行一次传输的起始会话数据重传请求。 例如， 对于通 信终端与网络侧而言， 进行一次组播业务的会话数据传输后， 组播群组 内有 50%的通信终端没有收到该会话数据， 这些通信终端都需要请求网 络侧重传该会话数据， 因此纷纷向网络侧发送会话数据重传请求， 那么 网络侧收到的第一个会话数据重传请求， 即为当前针对 50%通信终端进 行会话数据重传的起始会话数据重传请求； 会话数据进行第一次重传 后， 这 50%的通信终端中依然有未收到该会话数据的， 占组播群组通信 终端数量的 10%， 这些通信终端仍然需要网络侧对该会话数据进行再次 重传， 因此纷纷向网络侧发送会话数据重传请求， 此时， 网络侧收到的 第一个会话数据重传请求， 即为当前针对 10%通信终端进行会话数据重 传的起始会话数据重传请求。
在具体实现过程没有冲突的情况下， 可将上述几种实现方式进行组 合， 从而实现本发明最理想的实现方式。
总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本发 明的保护范围。

Claims

权利要求书
1、 一种组播 /广播业务中会话数据的传输方法， 其特征在于， 通信 终端检测到有未收到的组播 /广播业务会话数据， 该方法包含以下步骤：
A、 通信终端向所属的无线网络控制器发送携带有会话信息的会话 数据重传请求；
B、 无线网络控制器接收所述会话数据重传请求， 向所属的服务支 持中心发送携带有会话信息的会话数据重传请求；
C、 服务支持中心接收所述会话数据重传请求， 根据会话信息获取 需要重传的会话数据， 然后向管辖的无线网络控制器发送会话数据开始 消息；
D、 所述服务支持中心管辖的发送了会话数据重传请求的无线网络 控制器接收所述会话数据开始消息， 向该服务支持中心返回会话数据开 始接受响应， 建立用户平面资源；
E、 服务支持中心通过所述用户平面资源， 向管辖的返回了会话数 据开始接受响应的无线网络控制器重传会话数据， 无线网络控制器收到 重传数据后， 向管辖的通信终端重传收到的会话数据。
2、 根据权利要求 1所述的方法， 其特征在于， 步骤 B中所述无线 网络控制器接收所述会话数据重传请求之后， 进一步包括： 无线网络控 制器向管辖的通信终端返回会话数据重传响应。
3、 根据权利要求 2所述的方法， 其特征在于， 所述步骤 A之前进 一步包括以下步驟：
A01、 通信终端生成随机延迟， 并启动随机延迟定时器的计时； A02、 通信终端判断是否在随机延迟计时的时间范围内收到无线网 络控制器返回的会话数据重传响应， 如果是， 停止随机延迟定时器的计 时， 否则， 执行步骤八。
4、 根据权利要求 3所述的方法， 其特征在于， 执行所述步骤 A之 后， 进一步包括： 返回执行步骤 A01。
5、 根据权利要求 1所述的方法， 其特征在于， 步骤 B中所述无线 网络控制器接收所述会话数据重传请求之后， 进一步包括： 无线网络控 制器存储会话信息。
6、 根据权利要求 5所述的方法， 其特征在于， 步驟 B中所述向所 属的服务支持中心发送携带有会话信息的会话数据重传请求之前， 进一 步包括： 无线网络控制器根据存储的会话信息， 判断收到的会话数据重 传请求是否为针对该会话数据的起始会话数据重传请求， 如果是， 向所 属的服务支持中心发送携带有会话信息的会话数据重传请求； 否则， 不 进行操作。
7、 根据权利要求 5所述的方法， 其特征在于， 步骤 C中所述会话 数据开始消息中携带有会话信息，
步骤 C中所述向管辖的无线网络控制器发送会话数据开始消息是： 服务支持中心根据所述会话数据所属组播 /广播业务的无线网络控制器 列表， 向管辖的无线网络控制器发送会话数据开始消息，
所述步骤 C之后进一步包括： 服务支持中心管辖的无线网络控制器 接收会话数据开始消息， 判断是否存储有所述会话信息， 如果是， 向该 服务支持中心返回携带有用户平面资源信息的会话数据开始接受响应 , 建立用户平面资源， 否则， 向所述服务支持中心返回会话数据开始拒绝 响应。
8、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 B进一步 包括： 无线网络控制器记录通信终端所在小区信息。
9、 根据权利要求 1所述的方法， 其特征在于， 所述步驟 C进一步 包括： 服务支持中心向管辖的无线网络控制器返回会话数据重传响应。
10、 根据权利要求 9所述的方法， 其特征在于， 步驟 B中所述向所 属的服务支持中心发送携带有会话信息的会话数据重传请求之前， 进一 步包括以下步骤：
Bl、无线网络控制器生成随机延迟，并启动随机延迟定时器的计时； B2、 无线网络控制器是否在随机延迟计时的时间范围内收到服务支 持中心返回的会话数据重传响应，如果是，停止随机延迟定时器的计时， 否则， 向所属的服务支持中心发送携带有会话信息的会话数据重传请 求。
11、 根据权利要求 10所述的方法， 其特征在于， 执行所述步骤 B 之后， 进一步包括： 返回执行步骤 Bl。
12、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 C包括： 服务支持中心接收所述会话数据重传请求， 存储无线网络控制器信息， 根据会话信息获取需要重传的会话数据， 然后根据存储的无线网络控制 器信息， 向对应于所述无线网络控制器信息的无线网络控制器发送会话 数据开始消息。
13、 根据权利要求 1所述的方法， 其特征在于， 步驟 A中所述会话 数据重传请求进一步携带有通信终端信息，
步骤 B中所述无线网络控制器接收所述会话数据重传请求之后， 进 一步包括： 无线网络控制器存储通信终端信息，
步骤 E中所述向管辖的通信终端重传收到的会话数据包括： 无线网 络控制器根据存储的通信终端信息， 向管辖的对应于所述通信终端信息 的通信终端重传收到的会话数据。
14、 根据权利要求 1所述的方法， 其特征在于， 步骤 C中所述根据 会话信息获取需要重传的会话数据包括： 服务支持中心根据会话信息， 请求内容提供服务器提供对应于会话信息的会话数据， 内容提供服务器 向该服务支持中心提供所述会话数据。
15、 根据权利要求 14所述的方法， 其特征在于， 步骤 C中所述服 务支持中心接收所述会话数据重传请求之后， 进一步包括： 服务支持中 心存储会话信息。
16、 根据权利要求 15所述的方法， 其特征在于， 步骤 C中所述服 务支持中心接收所述会话数据重传请求之后， 进一步包括： 服务支持中 心根据存储的会话信息 , 判断收到的会话数据重传请求是否为针对该会 话数据的起始会话数据重传请求， 如果是， 请求内容提供服务器提供对 应于会话信息的会话数据， 否则， 不进行操作。
17、 根据权利要求 1所述的方法， 其特征在于，
步骤 D中所述会话数据开始响应携带有无线网络控制器信息， 所述步骤 D之后进一步包括： 服务支持中心存储无线网络控制器信 步骤 E中所述服务支持中心通过用户平面资源， 向管辖的返回了会 话数据开始接受响应的无线网络控制器重传会话数据， 包括： 服务支持 中心根据存储的无线网络控制器信息， 通过用户平面资源， 向所述无线 网络控制器重传会话数据。
18、 根据权利要求 1所述的方法， 其特征在于， 通信终端通过随机 接入过程， 或共享信道向无线网络控制器发送所述会话数据重传请求。
19、 根据权利要求 1所述的方法， 其特征在于， 通信终端通过滑动 窗口机制检测是否肴'未收到的会话数据。
PCT/CN2004/001277 2003-11-11 2004-11-10 A transmission method of conversation data in multicasting/broadcasting service Ceased WO2005046261A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200310114072.0 2003-11-11
CNB2003101140720A CN100396051C (zh) 2003-11-11 2003-11-11 一种组播/广播业务中会话数据的传输方法

Publications (1)

Publication Number Publication Date
WO2005046261A1 true WO2005046261A1 (en) 2005-05-19

Family

ID=34558467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2004/001277 Ceased WO2005046261A1 (en) 2003-11-11 2004-11-10 A transmission method of conversation data in multicasting/broadcasting service

Country Status (2)

Country Link
CN (1) CN100396051C (zh)
WO (1) WO2005046261A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100525192C (zh) * 2005-07-29 2009-08-05 华为技术有限公司 一种宽带接入设备、系统及方法
CN1933651B (zh) * 2005-09-12 2010-05-12 北京三星通信技术研究有限公司 Lte系统中的会话接入方法
CN1992707B (zh) * 2005-12-29 2012-05-23 上海贝尔阿尔卡特股份有限公司 一种组播业务快速恢复方法及网络设备
US9602297B2 (en) * 2007-03-12 2017-03-21 Nokia Technologies Oy Establishment of reliable multicast/broadcast in a wireless network
CN101330648B (zh) * 2007-09-19 2011-12-07 中兴通讯股份有限公司 恢复广播模式的多媒体广播组播业务的方法
CN102202207A (zh) * 2011-06-13 2011-09-28 中兴通讯股份有限公司 视频通话的传送方法及系统、增强型广播组播业务中心
EP3038299A4 (en) * 2013-09-25 2016-09-28 Huawei Tech Co Ltd METHOD FOR RECORDING SESSION INFORMATION AND RECORD SERVER
US10932095B2 (en) 2017-11-22 2021-02-23 Huawei Technologies Co., Ltd. Method and system for multicast and broadcast services
CN110958068B (zh) * 2018-09-27 2021-09-21 华为技术有限公司 一种视频传输的方法和设备
CN110022218B (zh) * 2019-03-07 2021-06-04 金证财富南京科技有限公司 组播通讯方法、终端设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6404739B1 (en) * 1997-04-30 2002-06-11 Sony Corporation Transmitter and transmitting method, receiver and receiving method, and transceiver and transmitting/receiving method
CN1366752A (zh) * 2000-04-06 2002-08-28 株式会社Ntt都科摩 多点传播传送方法及多点传播传送系统与移动台及基地台

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6404739B1 (en) * 1997-04-30 2002-06-11 Sony Corporation Transmitter and transmitting method, receiver and receiving method, and transceiver and transmitting/receiving method
CN1366752A (zh) * 2000-04-06 2002-08-28 株式会社Ntt都科摩 多点传播传送方法及多点传播传送系统与移动台及基地台

Also Published As

Publication number Publication date
CN100396051C (zh) 2008-06-18
CN1617523A (zh) 2005-05-18

Similar Documents

Publication Publication Date Title
AU2005204215B2 (en) Repairing errors in data of MBMS service
CN100566212C (zh) 用于移动通信的无线资源控制连接请求装置和方法
CN1720678B (zh) 在广播或者多址通信服务中建立反馈的装置和方法
CN100442701C (zh) 网络侧获知用户接收多媒体广播/组播业务情况的方法
US20070177608A1 (en) Method for implementing data segmentation and concatenation and reassembly and transmitter thereof
WO2018058468A1 (zh) 一种多播业务的发送方法和设备
CN101175252B (zh) 多媒体广播组播服务中建立会话的方法和网络系统
CN1711793A (zh) 上下文链接模式
CN100396051C (zh) 一种组播/广播业务中会话数据的传输方法
WO2005069646A1 (en) A registering method for multimedia broadcast multicast service
JP4422763B2 (ja) マルチメディアブロードキャスト・マルチキャストサービスの起動方法
WO2008025206A1 (en) A method and network for creating the control plane tunnel in the multicast service of the mobile communicating system
WO2007066975A2 (en) Multimedia broadcast multicast service providing system and method thereof
CN100356730C (zh) 一种实现多媒体广播/组播业务调度的业务传输方法
CN100568819C (zh) 多媒体广播组播服务会话开始的异常处理方法
CN100563361C (zh) 广播组播业务去激活的方法及设备
CN101141669B (zh) 在ip无线接入网中下发多媒体广播/组播服务业务的方法
WO2005053331A1 (en) A method of implementing multicasting service
CN101459873B (zh) 一种多媒体广播组播业务的接入方法
CN100428749C (zh) 一种多媒体广播/组播业务组播激活的方法
CN101232701B (zh) 广播组播业务去激活的方法及设备
WO2007093103A1 (en) Method and device for activating multimedia broadcast/multicast service
WO2007006225A1 (en) A method for processing data after reconfiguring the window parameter of the receiver in the radio link control layer
CN1859779A (zh) 一种多媒体广播/组播业务链接的方法
CN1581986A (zh) 区分mbms业务请求与其它业务请求的方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase