CN101047528A - Processing method and system for information in multi-media broadcast/multicast service - Google Patents

Abstract

The invention discloses an information processing method and system for realizing multimedia broadcast/multicast MBMS service. In the present invention, a bearer judging unit is set in the intermediate node to judge whether the downstream node can receive MBMS data. When the downstream node can receive the data, the intermediate node returns a bearer unavailable message to the upstream node, and the upstream node according to the notification of the downstream node The message is further processed, thereby avoiding the waste of resources caused by the upstream node not knowing whether the downstream node can receive the data, and continuously sending data, but the downstream node cannot receive it.

Description

Method and system for realizing information processing in multimedia broadcast/multicast service

technical field

The present invention relates to multimedia broadcast/multicast service (Multimedia Broadcast Multiple Service, MBMS) realization technology, particularly relates to a kind of bearer processing technology in MBMS service.

Background technique

With the development of the third-generation mobile communication technology, the third-generation mobile communication can provide services with a higher data rate than the second-generation mobile communication, thereby supporting various business forms. Services such as video calls, picture downloads, and high-speed Internet browsing. One of the characteristics of one type of service is that the service can be sent to users who have subscribed to the service in the wireless network at the same time. For example, weather forecasts, news clips, sports highlights and so on. Taking advantage of the simultaneous transmission of these services, the third-generation mobile communication system introduces the concept of multicast/broadcast from Rel-6, which can more effectively use priority air interface resources and provide higher system capacity.

In the broadcast/multicast service, for an intermediate node, no matter how many nodes are expected to receive data in its downstream, its upstream node always sends a piece of data to the intermediate node; after the intermediate node receives the data, it The number of downstream nodes expecting to receive the data copies the data and distributes the data to the downstream nodes expecting to receive the data. In this way, each branch of the multicast/broadcast service data transmission tree has only one copy of data for transmission, occupying one The same is true for the data transmission between the root node and its downstream nodes. The difference between the multicast service and the broadcast service is only that: the multicast service only sends corresponding information to users who have subscribed to certain information, while the broadcast service sends information to all users in the wireless network. It can be seen from the above description that providing the same information to a large number of users at the same time through the multicast/broadcast service can greatly save network resources.

In order to effectively utilize the resources of the mobile communication network, the third generation mobile communication global standardization organization (3GPP) proposed the MBMS of the mobile communication network, thereby providing a point-to-multipoint service in which one data source sends data to multiple users in the mobile communication network , realize network resource sharing, and improve the utilization rate of network resources, especially air interface resources. The MBMS proposed by 3GPP can not only realize the multicast and broadcast of plain text and low-rate messages, but also realize the multicast and broadcast of high-speed multimedia services, which undoubtedly conforms to the trend of future mobile data development.

Figure 1 is a schematic diagram of a wireless network structure supporting broadcast/multicast services, as shown in Figure 1, in the existing 3GPP, the wireless network entity supporting broadcast/multicast services is a broadcast/multicast service server (BM-SC), BM -SC is connected with gateway GPRS support node (GGSN, Gateway GPRSSupport Node) through Gmb interface or Gi interface, and one BM-SC can be connected with multiple GGSNs; GGSN is connected with serving GPRS support node (SGSN, Serving GPRS Support Node) through Gn/Gp interface Node), one GGSN can be connected with multiple SGSNs; SGSN can be connected with Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) 104 through Iu interface, then UTRAN 104 is connected with UE 106 through Uu interface, SGSN also It can be connected with the Enhanced Radio Access Network (GERAN) of the Global System for Mobile Communications through the Iu/Gb interface, and then the GERAN is connected with the UE through the Um interface. Wherein, the GGSN and the SGSN belong to the nodes in the core network (CN) in the wireless network.

From the network structure shown in Figure 1, it can be seen that in order to support MBMS services, a mobile network functional entity—broadcast and multicast service center, namely BM-SC, is added in the third generation mobile communication system, and the BM-SC is The content provider's entrance is used to authorize and initiate MBMS services in the mobile network, and transmit MBMS content according to a predetermined time plan. In addition, MBMS-related functions are added to functional entities such as UE, UTRAN, GERAN, SGSN, and GGSN.

MBMS includes a multicast mode and a broadcast mode. In the multicast mode, a user is required to subscribe to a corresponding multicast group, activate a service, and generate corresponding charging information. Due to the difference in business requirements between the multicast mode and the broadcast mode, the respective business processes are also different, as shown in Figure 2 and Figure 3, Figure 2 is a schematic diagram of the business process of the MSMS multicast mode, and Figure 3 is a schematic diagram of the MSMS broadcast mode Business process diagram.

As shown in Figure 2, the processing process involved in the MBMS multicast service includes: Subscription, Service announcement, Joining, Session Start, MBMS notification, data transmission (Data transfer), session end (SessionStop) and user exit (Leaving). Among them, the signing process is used to establish the relationship between the user and the service provider, allowing the user to pre-subscribe the required MBMS service; the service announcement process is used for the BM-SC to announce the currently available services, that is, to notify the user of the relevant MBMS services Information; the user joining process is the MBMS service activation process. During the joining process, the UE notifies the network that it is willing to become a member of the current multicast group and receive data corresponding to the MBMS service. Create an MBMS UE context for recording UE information; during the session start process, the BM-SC prepares for data transmission, and notifies the network to establish the bearer resources of the corresponding core network and access network; the MBMS notification process is used for the RNC to notify the UE that the MBMS multicast session is about to Start; during the data transmission process, the BM-SC transmits data to the UE through the bearer resources established during the session initiation process. There are two modes for MBMS service transmission between UTRAN and UE: point-to-multipoint (PTM) mode and point-to-point (PTP) mode, the PTM mode sends the same data through the MBMS point-to-multipoint traffic channel (MTCH), all UEs that join the multicast service or are interested in the broadcast service can receive it, and the PTP mode sends data through the DTCH logical channel, only A corresponding UE can receive it; the session end process is used to release the bearer resources established in the session start process; the user exit process makes the subscribers in the group leave the multicast group, that is, the user no longer receives multicast data, and this process will MBMS UE context deletion.

As shown in Fig. 3, the process involved in the MBMS broadcast service is similar to that of the MBMS multicast service, except that before the session starts, there is no need to execute the subscription process and the user join process, and after the session ends, the user logout process does not need to be performed.

Fig. 4 is a schematic flowchart of the session establishment function in the existing MBMS service. As shown in Figure 4, it mainly includes the following steps

Step 401: The BM-SC session and sending function (Session and Transmission Function) sends a session start request (Session Start Request) message, indicating upcoming data transmission, and providing session attributes (TMGI, QoS, MBMS service area, session identifier, Estimated session duration, broadcast/multicast mode, list of downstream nodes for GGSN to use (broadcast mode only)) and 2G/3G indication. This message is sent by the BM-SC proxy and transport function (Proxy and Transport Function), and sent to all GGSNs in the "list of downstream nodes" parameter in the MBMS bearer context. The BM-SC Proxy and Transport Function sets the Status attribute in the MBMS Bearer Context to "Active". For the broadcast MBMS bearer service, GGSN creates an MBMS bearer context. The GGSN stores the session attribute and the list of downstream nodes in the MBMS bearer context, sets the state attribute in the MBMS bearer context to "Active", and returns a session start response (Session StartResponse) message to the BM-SC agent and transport function, and the BM-SC The Proxy and Transport functions forward it to the BM-SC Session and Send functions. The BM-SC proxy and transport function will also send a session start request (Session Start Request) message to the BM-SC membership function (Membership Function) for charging purposes.

Step 402: GGSN sends a session start request (Session Start Request) message, providing session attributes (TMGI, QoS, MBMS service area, session identifier, estimated session duration, broadcast/multicast mode) and 2G/3G instructions. This message is sent to all SGSNs in the "list of downstream nodes" parameter of the MBMS bearer context in the GGSN. For the broadcast MBMS bearer service, the SGSN creates an MBMS bearer context. The SGSN stores the session attribute and the 2G/3G indication in the MBMS bearer context, sets the status attribute in the MBMS bearer context to "Active", and returns a Session Start Response (Session Start Response) message to the GGSN, providing the TEID for the bearer plane , the GGSN uses the TEID to forward MBMS data. For the MBMS bearer service, if the SGSN receives multiple MBMS session start request (Session Start Request) messages, the SGSN only needs to establish a bearer plane with one of the GGSNs.

Step 403: SGSN sends a session start request (Session Start Request) message, providing session attributes (TMGI, QoS, MBMS service area, session identifier, estimated session duration, broadcast/multicast mode). This message is sent to all BSCs and/or RNCs connected to this SGSN. SGSN uses 2G/3G instructions to determine whether the MBMS session start request (Session Start Request) message should be sent only to all BSCs, or only to all RNCs, or to all RNCs and BSCs at the same time. For the multicast MBMS bearer service, the SGSN may include the number of UEs in the PMM-IDLE state in a routing area RA. For the broadcast MBMS bearer service, BSC/RNC creates MBMS service context. The BSC and RNC under the Iu mode store the session attribute in the MBMS service context, set the status attribute in the MBMS service context to "Active", and return the session start response (Session Start Response) message to the SGSN, under the RNC and Iu mode The BSC will include the TEID for the bearer plane in the session start response (Session Start Response) message, and the SGSN uses the TEID to forward the MBMS data. If the BSC in Gb mode does not serve the MBMS service area, it does not need to store session attributes. If BSC/RNC receives multiple MBMS session start request (Session Start Request) messages, it only needs to establish a bearer plane with one of the SGSNs.

Step 404: BSC/RNC establishes necessary radio resources for transmitting MBMS data to interested UEs.

It can be seen that in the existing broadcasting service, when BM-SC sends Session StartRequest to GGSN, GGSN returns Session Start Response to BM-SC, but according to the existing process, there is such a problem: GGSN returns Session Start Response to BM-SC After the response, the BM-SC thinks that the GGSN can receive the data. However, after the GGSN sends a Session Start Request to the downstream SGSN, if all the downstream SGSNs do not respond to the GGSN, or give a rejection response, the BM-SC does not know Yes, in this way, the BM-SC will send data to the GGSN, but the GGSN has no way to send the data downwards, and the GGSN can only discard the data, which actually wastes the processing resources of the GGSN.

SGSN does not respond to GGSN, and returns a rejection response. Possible reasons include: SGSN restarts or a configuration error occurs, and does not respond to GGSN; SGSN does not support MBMS capabilities; and many other possible reasons, such as "Request Accepted", "Context not found", "No resources available", "No memory is available", "System failure", "Mandatory IE incorrect", "Mandatory IE missing", "Optional IE incorrect", "Invalid message format" and so on.

Similarly, according to the existing process, after the SGSN returns a response to the GGSN, the GGSN thinks that the SGSN can receive the data. However, after the SGSN sends a Session Start Request to the downstream BSC/RNC, if all the downstream BSC/RNCs do not respond to the SGSN, Or the GGSN does not know the response of rejection. In this way, the GGSN will send data to the SGSN, but the SGSN has no way to send the data downwards. The SGSN can only discard the data, which also wastes the processing resources of the SGSN.

Contents of the invention

In view of this, the technical problem to be solved by the present invention is to provide a method and system for implementing information processing in MBMS services. When the downstream cannot receive data, it will notify the upstream that its bearer is unavailable, thereby avoiding data transmission caused by BM-SC. Waste of resources caused by inability to continue forwarding.

Another technical problem to be solved by the present invention is to provide an intermediate node for implementing the MBMS service system, so as to solve the problem in the prior art that the issued MBMS service data cannot be received because the bearer of the intermediate node is unavailable. The problem of wasting resources.

In order to achieve the above object, technical solution of the present invention is achieved in that way:

The present invention provides an information processing method for realizing multimedia broadcast/multicast MBMS service, which mainly includes the following steps:

When an intermediate node receives a service request from an upstream node, it judges whether its downstream node can receive data. If the result of the judgment is that the downstream node cannot receive data, the intermediate node sends a bearer unavailable message to the upstream node.

When the intermediate node receives the session start request from the upstream node, it sends a session start request message to the downstream node and starts a timer at the same time.

Before the timer expires, if the intermediate node does not receive a response from the downstream node or does not receive any response from the downstream node indicating that it can receive data, it will send a bearer unavailable message to the upstream node.

If the bearer unavailable message only informs the upstream node that the node is currently unavailable, the upstream node will set the intermediate node to the state of not being able to receive data after receiving the bearer unavailable message sent by the intermediate node. During this period, no data is sent to the intermediate node, and no session start request is sent to the intermediate node, or the upstream node directly deletes the intermediate node from its downstream node list.

The bearer unavailable message may also carry a reason description, the reason why the downstream node cannot receive data. The reasons include: MBMS capability not supported, not enough resources available or IE error.

If the cause of the bearer unavailable message is a permanent cause, the upstream node no longer tries to send a session start request to the intermediate node or directly deletes the intermediate node from the list of downstream nodes in the upstream node; if the bearer is unavailable The reason for using the message is a temporary reason, and the upstream node sends the session start request message to the intermediate node multiple times in a regular or irregular manner.

The upstream node no longer tries to send a session start request to the intermediate node through a session termination request/response message, and the process of directly deleting the intermediate node from the downstream node list in the upstream node is implemented through the MBMS logout process accomplish.

The intermediate node includes a gateway GPRS support node GGSN and/or a serving GPRS support node SGSN. When the intermediate node is a GGSN, its corresponding upstream node is a broadcast/multicast service center BM-SC, and its corresponding downstream node is SGSN; when the intermediate node is SGSN, its corresponding upstream node is GGSN, and its corresponding downstream node is RNC and/or BSC.

The present invention also provides a communication system for implementing multimedia broadcast/multicast MBMS services, including a root node and at least one intermediate node, wherein at least one intermediate node is provided with a bearer judging unit for when the upstream node issues a service request , to judge whether the downstream node can receive data, and send a bearer unavailable message to the upstream node when the downstream node cannot receive data.

When the intermediate node receives the session start request from the upstream, it sends a session start request message to the downstream node, and at the same time, the bearer judging unit starts a timer event.

Before the timer expires, if the intermediate node does not receive a response from the downstream node or does not receive any response from the downstream node indicating that it can receive data, it will send a bearer unavailable message to the upstream node.

After the upstream node receives the bearer unavailable message sent by the intermediate node, it sets the intermediate node to the state of not being able to receive data, and does not send any data to the intermediate node during the MBMS session, and does not try to send the intermediate node any more data. Send a session start request, or the upstream node directly deletes the intermediate node from its downstream node list.

The intermediate nodes include: gateway GPRS support node GGSN and/or serving GPRS support node SGSN, when the intermediate node is GGSN, its corresponding upstream node is broadcast/multicast service center BM-SC, and its corresponding downstream node is SGSN; when the intermediate node is SGSN, its corresponding upstream node is GGSN, and its corresponding downstream node is RNC and/or BSC.

The present invention also provides a node, which is used in a communication system for implementing MBMS services. The node is used as an intermediate node to carry services. The node is provided with a bearer judging unit for judging when receiving a service request from the upstream. Whether its downstream can receive data.

The bearer judging unit is implemented through a timer event. The node starts the timer while forwarding the service request to the downstream. Before the timer expires, if no response from the downstream is received or no response indicates that the downstream can receive data, then It is judged that the downstream cannot receive data.

The node also includes a bearer information sending unit, configured to send a bearer unavailable message upstream when the bearer judging unit judges that the downstream cannot receive data.

When the bearer judging unit judges that the downstream cannot receive data, the node sends a bearer unavailable message upstream.

The node is a Gateway GPRS Support Node GGSN or a Serving GPRS Support Node SGSN.

Compared with the prior art, the present invention sets a bearer judging unit at an intermediate node in a communication system implementing MBMS services to judge whether its downstream node can receive MBMS data, and returns a corresponding message to inform the upstream node, and the upstream node according to The notification message of the downstream node is further processed, thereby avoiding the waste of resources caused by the upstream node not knowing whether the downstream node can receive data, and continuously sending data, but the downstream node cannot receive it.

Description of drawings

Fig. 1 is a schematic structural diagram of a wireless network supporting broadcast/multicast services;

Fig. 2 is a schematic diagram of the service flow of the MSMS multicast mode;

FIG. 3 is a schematic diagram of a service flow in the MSMS broadcast mode;

Fig. 4 is the information processing flowchart of existing MBMS service;

FIG. 5 is a schematic diagram of a first preferred embodiment of an information processing method in an MBMS service provided by the present invention;

Fig. 6 is a detailed flow diagram of Fig. 5;

FIG. 7 is a schematic diagram of a second preferred embodiment of an information processing method in an MBMS service provided by the present invention;

Fig. 8 is a detailed flow diagram of Fig. 7;

Fig. 9 is a schematic diagram of a third preferred implementation manner of an information processing method in an MBMS service provided by the present invention.

Fig. 10 is a schematic block diagram of a communication system for implementing MBMS services provided by the present invention.

Detailed ways

In order to make the purpose, technical solution and advantages of the present invention clearer, further detailed description will be given below in conjunction with the accompanying drawings and preferred implementation modes of the present invention.

The first preferred implementation mode provided by the present invention is shown in Figure 5. In the implementation of the MBMS service system, a bearer judgment unit is set in the GGSN to judge whether the subsequent data can be received when the BM-SC sends data. If If the subsequent data cannot be received, a message is sent to inform the BM-SC that its bearer is unavailable, and the reason is specified in the notification message. The BM-SC performs further processing according to the notification message, so as to avoid the problem that the data delivered by the BM-SC to the GGSN cannot continue to be forwarded due to the fact that the BM-SC does not know that the SGSN cannot receive the data.

The detailed flowchart of the information processing method in the MBMS service according to the first preferred embodiment of the present invention is shown in Figure 6, which mainly includes the following steps:

Step 601: The BM-SC session and sending function sends a Session StartRequest message to the GGSN to indicate upcoming data transmission and provide session attributes. The GGSN returns a SessionStart Response to the BM-SC upon receipt of the session start request from the BM-SC.

Step 602: The GGSN sends a session start request to the downstream SGSN, and the GGSN bearer judgment unit starts a timer at the same time;

If the GGSN does not receive any response from the SGSN before the timer expires, then execute step 603;

If the GGSN receives a response from a certain SGSN before the timer expires, indicating that MBMS data can be received, the GGSN will not perform further bearer judgment processing;

If before the timer expires, the GGSN does not receive a response from any SGSN indicating that it can receive MBMS data, that is, all responses sent to the GGSN indicate that these SGSNs cannot receive data, then perform step 603, and the SGSN cannot Possible reasons for receiving data include: MBMS capability not supported, insufficient available resources, information element error, and so on.

Step 603: The GGSN bearer judgment unit judges that the GGSN bearer is unavailable, and sends a bearer unavailable message to the BM-SC to notify that the current GGSN is unavailable.

If the GGSN only informs the BM-SC that the GGSN is currently unavailable, the BM-SC will set the GGSN as "unable to receive data", and will not send any data to the GGSN during this MBMS session, nor will it attempt to send data to the GGSN. GGSN sends a session start request. Or, directly delete the GGSN from the "downstream node list" in the BM-SC.

If the GGSN notifies the BM-SC that the current GGSN is unavailable, it carries a detailed explanation of the reasons in the notification message, indicating that the downstream SGSN does not respond or that the downstream SGSN cannot receive MBMS data, that is, it must inform the BM-SC in the notification or response , is it due to permanent or temporary reasons that the GGSN is in the state of "unable to receive data", if it is a temporary reason, the subsequent BM-SC can send Session StartRequest to the GGSN multiple times in a regular or irregular manner, depending on the implementation ; If it is a permanent reason, the BM-SC sets the GGSN as "unable to receive data", does not send any data to the GGSN during the MBMS session, and does not try to send a Session Start Request to the GGSN again, or, Directly delete the GGSN from the "downstream node list" in the BM-SC.

The above process can be realized by using the STR/STA (Session Termination Request/Response) message in the Diameter protocol, or the existing MBMS logout process can be used to notify the BM-SC to remove the GGSN from the "downstream node list" in the BM-SC delete.

The second preferred embodiment provided by the present invention is shown in Figure 7, similar to the first preferred embodiment, it is also necessary to confirm whether the downstream can receive data between the SGSN and the BSC/RNC, when the GGSN sends data, A bearer judging unit is set in the SGSN to judge whether the BSC/RNC can receive data. If not, the SGSN feeds back a notice that the bearer is unavailable to the GGSN, and the GGSN performs corresponding processing according to the notice.

Figure 8 is a detailed flow chart of the second preferred embodiment of the present invention, the second preferred embodiment is similar to the first preferred embodiment, it mainly sets the bearer judging unit at the SGSN, when receiving After the session start request, while sending the session request to the downstream BSC/RNC, the SGSN bearer judgment unit starts a timer event to judge whether its downstream can receive data, and if the timer expires, it reports the bearer unavailable message to the upstream GGSN. It specifically includes the following steps:

Step 801: The SGSN receives a session start request message from the GGSN, and returns a session start response message.

Step 802: The SGSN sends a session start request message to the downstream BSC/RNC, and the SGSN bearer judgment unit starts a timer at the same time.

If the SGSN does not receive any response from the BSC/RNC before the timer expires, then execute step 803;

If the SGSN receives a response from a certain BSC/RNC before the timer expires, which indicates that MBMS data can be received, the SGSN will not perform further bearer judgment processing;

If the SGSN does not receive a response from any BSC/RNC indicating that it can receive MBMS data before the timer expires, that is, all responses sent to the SGSN indicate that none of these BSC/RNCs can receive data, then step 803 is performed.

Step 803: The SGSN sends a bearer unavailable message to the GGSN, which may carry a reason statement, indicating the reason why the downstream BSC/RNC does not respond or the downstream BSC/RNC cannot receive MBMS data. The GGSN sets the SGSN as "unable to receive data", and will not send any data to the SGSN during the MBMS session, nor will it try to send a session start request to the SGSN, or remove the SGSN from the GGSN Deleted from the "Downstream Node List".

If all SGSNs send the bearer unavailable message to the GGSN, the GGSN sends the bearer unavailable message to the BM-SC, and the subsequent related processing flow is similar to step 603 in the first preferred embodiment.

The third preferred implementation mode provided by the present invention is shown in FIG. 9 . Both the GGSN and the SGSN are provided with a bearer judgment unit to judge whether the downstream can receive data. When judging whether the downstream can receive data, they can also separately Implemented with timer events.

First, when the GGSN receives the session start request message from the BM-SC, it returns a session start response message to the BM-SC.

Secondly, the GGSN sends a session start request message to the SGSN, and at the same time, the bearer judgment unit of the GGSN starts a timer.

Before the timer expires, the GGSN receives a response from a certain SGSN, indicating that the MBMS data can be received, and the GGSN does not perform further bearer judgment processing. The SGSN continues to send a session start request to its downstream BSC/RNC, and the bearer judgment unit in the SGSN starts a timer event to further judge whether its downstream can receive data. The specific steps for judging whether the BSC/RNC can receive data in the SGSN are the same as those in the second preferred embodiment of the present invention, and will not be repeated here.

Before the timer expires, the GGSN does not receive any response from the SGSN, and then sends a bearer unavailable message to the BM-SC, and the BM-SC performs corresponding processing according to the details, and the process is roughly the same as that in the first preferred embodiment, here No more details.

When the GGSN does not receive a response from any SGSN indicating that it can receive MBMS data before the timer expires, that is, all responses sent to the GGSN indicate that these SGSNs cannot receive data, the GGSN sends a bearer unavailable message to the BM-SC . The message may carry a reason description. The BM-SC performs further processing according to the message, and the processing method is substantially the same as that in the first preferred embodiment, and will not be repeated here.

As shown in Figure 10, it is a schematic diagram of a communication system for implementing MBMS services provided by the present invention. The system includes a root node and several intermediate nodes. The intermediate nodes are provided with a bearer judgment unit and a bearer information sending unit. When a node sends a session request response, the intermediate node sends a session request response to an upstream node, and sends a session request response to a downstream node, and at the same time, the bearer judgment unit judges whether the downstream node can receive data, and if the downstream node cannot receive data, the The bearer information sending unit sends a bearer unavailable message to an upstream node. The upstream node performs further processing according to the bearer unavailable message.

Specifically, when the intermediate node receives the session start request from the upstream, it sends a session start request message to the downstream node, and at the same time, the bearer judging unit starts a timer event. Before the timer expires, if the intermediate node does not receive a response from the downstream node or does not receive any response from the downstream node indicating that it can receive data, it will send a bearer unavailable message to the upstream node.

After the upstream node receives the bearer unavailable message sent by the intermediate node, it sets the intermediate node to the state of not being able to receive data, and does not send any data to the intermediate node during the MBMS session, and does not try to send the intermediate node any more data. Send a session start request, or the upstream node directly deletes the intermediate node from its downstream node list.

The intermediate node can be GGSN and/or SGSN. If the intermediate node is GGSN, its corresponding upstream node is BM-SC, and its corresponding downstream node is SGSN. If the intermediate node is SGSN, its corresponding upstream node is SGSN, and its corresponding downstream node is RNC and/or BSC.

The above descriptions are only process and method embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of the present invention. within the scope of protection.

Claims (18)

1, a kind of information processing method that realizes multimedia broadcast/multicast MBMS service, it is characterized in that comprising the following steps: When the intermediate node receives the service request from the upstream node, it judges whether its downstream node can receive data, If the judgment result is that the downstream node cannot receive data, the intermediate node sends a bearer unavailable message to the upstream node. 2. The method according to claim 1, characterized in that: after receiving the session start request from the upstream node, the intermediate node sends a session start request message to the downstream node and starts a timer at the same time. 3. The method according to claim 2, characterized in that: before the timer expires, if the intermediate node does not receive a response from a downstream node or does not receive any response from a downstream node indicating that it can receive data, it will send a bearer unavailable message to the upstream node. information. 4. The method according to claim 1, characterized in that: after the upstream node receives the bearer unavailable message sent by the intermediate node, it sets the intermediate node to the state of unreceivable data, and no longer sends the message during the MBMS session. Any data is sent to the intermediate node, and no attempt is made to send a session start request to the intermediate node, or the upstream node directly deletes the intermediate node from its downstream node list. 5. The method according to claim 1, characterized in that: the bearer unavailable message carries a reason description, which is used to indicate the reason why the downstream node cannot receive data. 6. The method according to claim 5, wherein the reasons include: not supporting MBMS capability, not having enough available resources or information element error. 7. The method according to claim 5, wherein if the cause of the bearer unavailable message is a permanent cause, the upstream node no longer tries to send a session start request to the intermediate node or directly removes the intermediate node from the upstream If the cause of the bearer unavailable message is a temporary reason, the upstream node sends a session start request message to the intermediate node multiple times in a regular or irregular manner. 8. The method according to claim 4 or 7, characterized in that: the upstream node no longer tries to send a session start request to the intermediate node through a session termination request/response message, and the direct transfer of the intermediate node to The process of deleting from the downstream node list in the upstream node is realized through the MBMS deregistration process. 9. The method according to any one of claims 1 to 7, wherein the intermediate node includes a gateway GPRS support node GGSN and/or a serving GPRS support node SGSN; when the intermediate node is a GGSN, its corresponding The upstream node is broadcast/multicast service center BM-SC, and its corresponding downstream node is SGSN; when the intermediate node is SGSN, its corresponding upstream node is GGSN, and its corresponding downstream node is radio network controller RNC And/or Base Station Controller BSC. 10. A communication system for realizing multimedia broadcast/multicast MBMS services, comprising a root node and at least one intermediate node, characterized in that: At least one intermediate node is provided with a bearer judging unit, which is used to judge whether the downstream node can receive data when the upstream node sends a service request, and sends a bearer unavailable message to the upstream node when the downstream node cannot receive data. 11. The system according to claim 10, wherein the intermediate node sends a session start request message to the downstream node after receiving the session start request from the upstream, and at the same time, the bearer judging unit starts a timer event. 12. The system according to claim 11, characterized in that: before the timer expires, if the intermediate node does not receive a response from the downstream node or does not receive any response from the downstream node indicating that it can receive data, it will send a bearer unavailable message to the upstream node. information. 13. The method according to claim 10, characterized in that: after receiving the bearer unavailable message sent by the intermediate node, the upstream node sets the intermediate node to the state of not being able to receive data, and does not send any more data during the MBMS session. Any data is sent to the intermediate node, and no attempt is made to send a session start request to the intermediate node, or the upstream node directly deletes the intermediate node from its downstream node list. 14. The system according to any one of claims 10 to 13, wherein the intermediate nodes include: a gateway GPRS support node GGSN and/or a serving GPRS support node SGSN, when the intermediate node is a GGSN, its The corresponding upstream node is broadcast/multicast service center BM-SC, and its corresponding downstream node is SGSN; when the intermediate node is SGSN, its corresponding upstream node is GGSN, and its corresponding downstream node is RNC and/or BSc. 15. A node used in a communication system for implementing MBMS services, characterized in that: the node is used as an intermediate node to carry services, and the node is provided with a bearer judging unit for receiving a service request from the upstream , to determine whether its downstream can receive data. 16. The node according to claim 15, characterized in that: the bearer judgment unit is realized by a timer event, and the node starts the timer while forwarding the service request to the downstream, and does not receive the service request before the timer expires. If there is no response to any downstream or no response indicates that the downstream can receive data, it is judged that the downstream cannot receive data. 17. The node according to claim 15 or 16, wherein the node further comprises a bearer information sending unit, configured to send a bearer unavailable message upstream when the bearer judging unit judges that the downstream cannot receive data. 18. The node according to claim 17, wherein the node is a Gateway GPRS Support Node (GGSN) or a Serving GPRS Support Node (SGSN).

Images