[go: up one dir, main page]

WO2005046261A1 - Procede de transmission de donnees vocales dans un service de diffusion/multidiffusion - Google Patents

Procede de transmission de donnees vocales dans un service de diffusion/multidiffusion 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)
Chinese (zh)
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/fr
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)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé de transmission de données vocales dans un service de diffusion/multidiffusion. Selon ce procédé, lorsque les terminaux de communication détectés n'ont pas reçu de données vocales d'un service de diffusion/multidiffusion, une demande de retransmission de données vocales est transmise au contrôleur du réseau sans fil auquel appartient le terminal de communication; la demande de retransmission de données vocales est transmise au centre de support de services auquel appartient le terminal de communication; le centre de support de services reçoit la demande de retransmission de données vocales et obtient les données vocales à retransmettre en fonction d'information vocale, puis transmet le message initial comportant les données vocales au contrôleur de réseau sans fil géré par le centre de support de services; le contrôleur de réseau sans fil, qui a transmis la demande de retransmission de données vocales, reçoit le message initial comportant les données vocales et renvoie des informations relatives aux données vocales au centre de support de services puis détermine les ressources de l'utilisateur, et retransmet les données vocales en fonction des ressources de l'utilisateur. Ce procédé permet de retransmettre de manière efficace des données vocales et de rationaliser l'utilisation des ressources d'un réseau sans fil et d'un réseau central.
PCT/CN2004/001277 2003-11-11 2004-11-10 Procede de transmission de donnees vocales dans un service de diffusion/multidiffusion Ceased WO2005046261A1 (fr)

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 (fr) 2005-05-19

Family

ID=34558467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2004/001277 Ceased WO2005046261A1 (fr) 2003-11-11 2004-11-10 Procede de transmission de donnees vocales dans un service de diffusion/multidiffusion

Country Status (2)

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

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 上海贝尔阿尔卡特股份有限公司 一种组播业务快速恢复方法及网络设备
CN101743716B (zh) * 2007-03-12 2013-01-23 诺基亚公司 无线网络中可靠多播/广播的建立
CN101330648B (zh) * 2007-09-19 2011-12-07 中兴通讯股份有限公司 恢复广播模式的多媒体广播组播业务的方法
CN102202207A (zh) * 2011-06-13 2011-09-28 中兴通讯股份有限公司 视频通话的传送方法及系统、增强型广播组播业务中心
CN104756447B (zh) * 2013-09-25 2018-05-18 华为技术有限公司 一种录制会话信息的方法和录制服务器
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) 用于移动通信的无线资源控制连接请求装置和方法
CN100442701C (zh) 网络侧获知用户接收多媒体广播/组播业务情况的方法
US20070177608A1 (en) Method for implementing data segmentation and concatenation and reassembly and transmitter thereof
WO2018058468A1 (fr) Procédé et dispositif d'émission de service en multidiffusion
WO2006102807A1 (fr) Procede de reception d’informations de commande de diffusion multimedia ou de service multidiffusion
CN101175252B (zh) 多媒体广播组播服务中建立会话的方法和网络系统
CN1711793A (zh) 上下文链接模式
CN100396051C (zh) 一种组播/广播业务中会话数据的传输方法
CN101356836B (zh) 控制访问多媒体广播/组播服务的方法和设备
WO2005069646A1 (fr) Procede d'enregistrement pour service multidestination a diffusion multimedia
JP4422763B2 (ja) マルチメディアブロードキャスト・マルチキャストサービスの起動方法
US20090080354A1 (en) Multimedia Broadcast Multicast Service Providing System and Method Thereof
WO2008025206A1 (fr) Procédé et réseau pour créer le tunnel de plan de contrôle dans le service de multidiffusion du système de communication mobile
CN101175297B (zh) 3g长期演进系统中多媒体广播业务的资源配置方法与系统
CN100356730C (zh) 一种实现多媒体广播/组播业务调度的业务传输方法
CN100568819C (zh) 多媒体广播组播服务会话开始的异常处理方法
WO2005053331A1 (fr) Procede de mise en oeuvre d'un service de multidiffusion
CN101296399A (zh) 广播组播业务去激活的方法及设备
CN101459873B (zh) 一种多媒体广播组播业务的接入方法
CN100428749C (zh) 一种多媒体广播/组播业务组播激活的方法
CN101232701B (zh) 广播组播业务去激活的方法及设备
WO2007093103A1 (fr) Procédé et dispositif d'activation d'un service de diffusion/multidiffusion multimedia
WO2007006225A1 (fr) Procédé de traitement de données après la reconfiguration du paramètre de la fenêtre du récepteur dans une couche de commande de liaison radio
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