Background
Multimedia Broadcast Multicast Service (MBMS) is defined by the third Generation Partnership Project (3 GPP) for point-to-multipoint unidirectional Multimedia services. The MBMS sends multimedia broadcast service to users in the cell through a common channel by using an air interface, or sends multicast service ordered by the users to the users in the cell in a multicast mode, thereby saving air interface resources. The main application of MBMS is mobile tv service, in addition, services such as broadcast download and music tv MTV interaction can also be supported. MBMS is based on General Packet Radio Service (GPRS)/wideband Code Division Multiple access (wcdma) (broadband-Multicast Service center) Packet network, and implements air interface resource sharing by adding some new functional entities, such as Broadcast Multicast Service center BM-SC (Broadcast Multicast Service center), and adding MBMS functions to existing Packet domain functional entities, such as GPRS Service Support node sgsn (serving GPRS Support node), GPRS gateway Support node ggsn (gateway GPRS Support node), base Station controller (bsc), (Radio Station controller)/Radio network controller RNC (Radio network controller 11er) and user terminal ue (user equipment), and defining new logical sharing channels.
MBMS defines two services: broadcast services and multicast services.
A related processing procedure of an MBMS multicast service in the prior art is shown in fig. 1, and includes: subscription (Subscription), Service announcement (Service announcement), Joining (Joining), Session Start (Session Start), MBMS notification (MBMS notification), Data transfer (Data transfer), Session end (Session Stop), and Leaving (Leaving). Wherein, the Subscription process is used for subscribing the user to the required MBMS service in advance; the Service announcement process is used for announcing the Service which can be currently provided by the BM-SC; in the Joining process, UE informs the network that the UE is willing to become a member of the current multicast group and receives multicast data of the corresponding service, and the Joining process can create an MBMS UE context for recording UE information in the network and the UE Joining the multicast group; in the Session Start process, BM-SC prepares for data transmission and informs the network to establish the bearing resources of the corresponding core network and access network; the MBMS notification procedure is used to inform the ue that an MBMS multicast session is about to start; in the Data transfer process, BM-SC transmits Data to UE through the bearing resource established in the session starting process; the Session Stop process is used for releasing the bearing resources established in the Session Start process; the Leaving procedure leaves the group with subscribers in the group, i.e. the subscribers no longer receive multicast data, which deletes the corresponding MBMS UE context.
Fig. 2 shows a related processing procedure of an MBMS broadcast service in the prior art, which includes: service announcement (Service announcement), Session Start (Session Start), MBMS notification (MBMSnotification), Data transfer (Data transfer), and Session end (Session Stop).
No matter broadcast service and multicast service, the process of defining Session start in the prior art is shown in fig. 3, and includes the following steps:
step 301, BM-SC sends a Session Start Request message to GGSN;
BM-SC sends a 'Session Start Request' message to GGSN to indicate the data transmission to be started and the relevant attributes of the Session, including: temporary Mobile user identity (tmgi), (temporal Mobile Group identity), quality of service (qos), (quality of service), (MBMS service area), session Identity (ID), expected session duration, broadcast/multicast indication, SGSN list (only for broadcast mode), time of data transmission, 2G/3G indication, etc.
Step 302, GGSN returns Session Start Response message to BM-SC;
after receiving the "Session Start Request" message, the GGSN establishes an MBMS bearer context, stores a Session related attribute and a related SGSN identifier, and returns a "Session Start response" message to the BM-SC;
step 303, the GGSN sends an MBMS session Start Request "message to each associated SGSN;
the GGSN sends 'MBMS Session StartRequest' message to each associated SGSN according to the indication of BM-SC, and informs the related attributes of SGSN Session, including TMGI, QoS, MBMS service area, Session ID, predicted Session duration, broadcast/multicast indication, data transmission time, 2G/3G indication, etc.
Step 304, SGSN returns MBMS conversation start response 'MBMS Session StartResponse' message to GGSN;
after SGSN receives the 'MBMS Session Start Request' message sent by GGSN, it establishes MBMS bearing context, stores the attribute related to the Session, and returns the 'MBMS Session Start Response' message to GGSN. And if the SGSN receives the 'MBMS Session StartRequest' messages sent by a plurality of GGSNs, only one bearer is established with one GGSN.
Step 305, the SGSN sends an "MBMS Session StartRequest" message to the relevant BSC/RNC connected to it;
the SGSN sends an 'MBMSSession Start Request' message to the related BSC/RNC connected with the SGSN according to the received 2G/3G indication, and informs the BSC/RNC about the related attributes of the session, including TMGI, QoS, MBMS service area, session ID, predicted session duration, broadcast/multicast indication, time to data transmission, routing area RA (routing area) list, etc.
Step 306, BSC/RNC returns 'MBMS Session Start Response' message to SGSN;
BSC/RNC establishes MBMS service context, returns 'MBMS Session StartResponse' message to SGSN, BSC/RNC in Iu mode stores attribute related to conversation, BSC in Gb mode does not need to store attribute related to conversation. If the BSC/RNC receives the 'MBMSSession Start Request' message sent by a plurality of SGSNs, only one bearer is established with one SGSN.
Step 307, the BSC/RNC establishes the required radio resources.
During the research and practice of the prior art, the inventor finds that the prior art has the following problems:
in the prior art, the process of establishing connections between different network element devices in an MBMS is unidirectional, and each network element device sequentially establishes a Session from BM-SC to GGSN, SGSN, BSC/RNC, and if the Session establishment between two network element devices fails due to the unavailability of resources of a downstream network element device, the prior art does not have a corresponding process flow to ensure that a Session can be established between the two network element devices, even if the resources of a subsequent downstream network element device are available, because the connection establishment process is unidirectional, as long as the upstream network element device does not initiate a Request to the downstream network element device again, a Session cannot be established between the two network element devices, and thus a user in the area of the corresponding network element device cannot always enjoy the MBMS service, the method of establishing a Session in the prior art is not very reliable, for example, after the GGSN sends an "MBMS Session Start Request" message to the SGSN, if the session establishment fails due to the unavailability of resources as indicated in the "MBMS session Start Response" returned by the SGSN to the GGSN, the session between the GGSN and the SGSN may not be established all the time because the prior art has no corresponding processing flow, which may cause the user in the corresponding SGSN service area to not receive the MBMS session. In addition, there are similar problems with establishing sessions between the BM-SC and the GGSN, and between the SGSN and the BSC/RNC.
Detailed Description
The embodiment of the invention provides a method for establishing a session in multimedia broadcast multicast service, which can reliably establish the session in the multimedia broadcast multicast service.
Please refer to fig. 4, which is a flowchart illustrating a method for establishing a session according to an embodiment of the present invention, including the steps of:
step 401, sending a request message for establishing a session;
in a network system, a sending end sends a request message for establishing a session to a receiving end to request for establishing the session.
Step 402, receiving a returned response message;
after receiving a request message for establishing a session sent by a sending end, a receiving end returns a response message to the sending end according to the resource availability condition of the receiving end, and the sending end receives the returned response message.
Step 403, if the returned response message indicates that the session establishment fails, resending the request message for session establishment.
And when the sending end receives the returned response message and indicates that the session establishment fails due to the unavailable resources, the sending end resends the request message for establishing the session to the receiving end. The request message for re-sending the session establishment may be re-sent continuously at a set time interval until the session establishment is successful, or re-sent continuously within a maximum number of re-sending times not exceeding a set maximum number of re-sending times, or the time interval for re-sending and the number of re-sending times are considered at the same time.
For ease of understanding, the following is illustrated with a reliable session establishment between the GGSN and the SGSN.
Please refer to fig. 5, which is a flowchart illustrating a reliable session establishment procedure between a GGSN and an SGSN according to an embodiment of the present invention, including the steps of:
step 501, BM-SC sends a message of 'Session Start Request' to GGSN;
BM-SC sends a 'Session Start Request' message to GGSN to indicate the data transmission to be started and the relevant attributes of the Session, including: TMGI, QoS, MBMS service area, session ID, expected session duration, broadcast/multicast indication, SGSN list (for broadcast mode only), time of data transmission, 2G/3G indication, etc.
Step 502, GGSN returns "Session Start Response" message to BM-SC;
after receiving the "Session Start Request" message, the GGSN establishes an MBMS bearer context, stores a Session related attribute and a related SGSN identifier, and returns a "Session Start response" message to the BM-SC;
step 503, the GGSN sends an "MBMS Session Start Request" message to each associated SGSN;
the GGSN sends 'MBMS Session StartRequest' message to each associated SGSN according to the indication of BM-SC, and informs the related attributes of SGSN Session, including TMGI, QoS, MBMS service area, Session ID, predicted Session duration, broadcast/multicast indication, data transmission time, 2G/3G indication, etc.
Step 504, SGSN returns 'MBMS Session Start Response' message to GGSN to indicate that creating Session fails;
after the SGSN receives the 'MBMS Session Start Request' message sent by the GGSN, because the resource is unavailable, the MBMS bearing context can not be established, and the 'MBMS Session Start Response' message is sent to the GGSN, which indicates that the Session establishment is failed, and the reason value is 'SGSN resource unavailable'.
Step 505, the GGSN retransmits the "MBMS session start Request" message to the SGSN according to the set time interval;
after receiving the "MBMS Session StartResponse" message returned from the SGSN indicating that Session creation failed, the GGSN delays and retransmits the "MBMS Session StartRequest" message to the SGSN, so as to wait for resources available to the SGSN.
If the GGSN re-sends the 'MBMS Session Start Request' message to the SGSN, and the SGSN returns the 'MBMS Session Start Response' message indicating that the Session creation is failed, the GGSN continues to re-send after delaying for a period of time. Therefore, when the subsequent resources of the SGSN are available, the MBMS Session can be established between the GGSN and the SGSN, and the adverse effect caused by no corresponding processing flow when the MBMS Session Start Response returned from the SGSN to the GGSN indicates that the Session establishment fails in the prior art is avoided.
The time interval for the GGSN to retransmit the MBMS Session Start Request message may be configured according to network conditions, considering that the appropriate delay time may vary from network to network.
In step 506, the SGSN returns an "MBMS Session Start Response" message to the GGSN indicating that the Session creation is successful.
If the SGSN has available resources, after receiving the 'MBMS Session StartRequest' message retransmitted by the GGSN, the SGSN establishes an MBMS bearing context, stores the attribute related to the Session, and returns the 'MBMS Session Start Response' message to the GGSN, which indicates that the Session is successfully established.
Please refer to fig. 6, which is a flowchart illustrating a reliable session establishment between a GGSN and an SGSN according to an embodiment of the present invention. The main difference between the second embodiment and the first embodiment is that the GGSN retransmits the "MBMS Session Start Request" message to the SGSN for a set number of times. The figure includes the steps:
step 601, BM-SC sends a 'Session Start Request' message to GGSN;
BM-SC sends a 'Session Start Request' message to GGSN to indicate the data transmission to be started and the relevant attributes of the Session, including: TMGI, QoS, MBMS service area, session ID, expected session duration, broadcast/multicast indication, SGSN list (for broadcast mode only), time of data transmission, 2G/3G indication, etc.
Step 602, GGSN returns message "Session Start Response" to BM-SC;
after receiving the "Session Start Request" message, the GGSN establishes an MBMS bearer context, stores a Session related attribute and a related SGSN identifier, and returns a "Session Start response" message to the BM-SC;
step 603, the GGSN sends an 'MBMS Session Start Request' message to each related SGSN;
the GGSN sends 'MBMS Session StartRequest' message to each associated SGSN according to the indication of BM-SC, and informs the related attributes of SGSN Session, including TMGI, QoS, MBMS service area, Session ID, predicted Session duration, broadcast/multicast indication, data transmission time, 2G/3G indication, etc.
Step 604, SGSN returns 'MBMS Session Start Response' message to GGSN to indicate that creating Session fails;
after the SGSN receives the 'MBMS Session Start Request' message sent by the GGSN, because the resource is unavailable, the MBMS bearing context can not be established, and the 'MBMS Session Start Response' message is sent to the GGSN, which indicates that the Session establishment is failed, and the reason value is 'SGSN resource unavailable'.
Step 605, GGSN resends "MBMS session start Request" message to SGSN according to the set number of retransmissions;
after receiving the "MBMS Session Start response" message returned from the SGSN indicating that Session creation failed, the GGSN retransmits the "MBMS Session Start Request" message to the SGSN, so as to wait for an available resource to the SGSN.
If the SGSN returns the 'MBMS Session Start Response' message indicating that the Session creation is failed after the GGSN retransmits the 'MBMS Session Start Request' message to the SGSN, the GGSN continues the retransmission again. Therefore, when the subsequent resources of the SGSN are available, the MBMS Session can be established between the GGSN and the SGSN, and the adverse effect caused by no corresponding processing flow when the MBMS Session Start Response returned from the SGSN to the GGSN indicates that the Session establishment fails in the prior art is avoided.
Considering that the SGSN may actually not be able to establish the MBMS Session in some cases, the signaling load of the network will be increased if the MBMS Session establishment Request is repeatedly and continuously initiated to the SGSN, so the number of times that the GGSN repeatedly sends the "MBMS Session Start Request" message to the SGSN may be configured, that is, a maximum number of retransmissions is set.
In step 606, the SGSN returns an "MBMS Session Start Response" message to the GGSN indicating that the Session creation is successful.
If the SGSN has available resources, after receiving the 'MBMS Session StartRequest' message retransmitted by the GGSN, the SGSN establishes an MBMS bearing context, stores the attribute related to the Session, and returns the 'MBMS Session Start Response' message to the GGSN, which indicates that the Session is successfully established.
It should be noted that, in the above embodiment, the time interval and the retransmission number of the retransmission of the "MBMS Session Start Request" message may also be considered at the same time, that is, after the GGSN receives the "MBMS Session Start Response" message indicating that the Session creation is failed every time the SGSN returns, the "MBMS Session Start Request" message is retransmitted to the SGSN at the preconfigured time interval, and the retransmission number does not exceed the preconfigured maximum retransmission number.
Please refer to fig. 7, which is a flowchart illustrating reliable session establishment between a GGSN and an SGSN according to a third embodiment of the present invention. The difference between the third embodiment and the first and second embodiments is that in the third embodiment, after the SGSN returns an "MBMS Session Start Response" message indicating that the Session creation has failed to the GGSN, if resources are subsequently found to be available, the GGSN is notified actively, and the GGSN retransmits the "MBMS Session Start Request" message after receiving the notification. The figure includes the steps:
step 701, BM-SC sends a message of "Session Start Request" to GGSN;
BM-SC sends a 'Session Start Request' message to GGSN to indicate the data transmission to be started and the relevant attributes of the Session, including: TMGI, QoS, MBMS service area, session ID, expected session duration, broadcast/multicast indication, SGSN list (for broadcast mode only), time of data transmission, 2G/3G indication, etc.
Step 702, GGSN returns message of "Session Start Response" to BM-SC;
after receiving the "Session Start Request" message, the GGSN establishes an MBMS bearer context, stores a Session related attribute and a related SGSN identifier, and returns a "Session Start response" message to the BM-SC;
step 703, the GGSN sends an "MBMS Session Start Request" message to each associated SGSN;
the GGSN sends 'MBMS Session StartRequest' message to each associated SGSN according to the indication of BM-SC, and informs the related attributes of SGSN Session, including TMGI, QoS, MBMS service area, Session ID, predicted Session duration, broadcast/multicast indication, data transmission time, 2G/3G indication, etc.
Step 704, SGSN returns's MBMS Session Start Response' message to GGSN to indicate that creating Session fails;
after the SGSN receives the 'MBMS Session Start Request' message sent by the GGSN, because the resource is unavailable, the MBMS bearing context can not be established, and the 'MBMS Session Start Response' message is sent to the GGSN, which indicates that the Session establishment is failed, and the reason value is 'SGSN resource unavailable'.
Step 705, after the session establishment failure of the SGSN, recording the corresponding GGSN address and the session information;
step 706, SGSN sends 'MBMS resource available notification' message to corresponding GGSN;
when the SGSN has available resources, the newly defined MBMS resource available notification message is sent to the corresponding GGSN according to the recorded information, and the GGSN is notified that the resources are available.
The 'MBMS resource availability notification' message is a newly defined message used for the SGSN to notify the GGSN that existing resources are available.
The message format of the MBMS resource available notification message is shown in fig. 8.
As shown in fig. 8, the MBMS resource availability notification message includes an End User Address (End User identifier) cell and an Access Point Name (Access Point Name), and these two cells are necessary options and together identify a corresponding MBMS bearer service.
Step 707, the GGSN resends the "MBMS Session Start Request" message to the SGSN;
after the GGSN receives the notification message, knowing that the SGSN has available resources, the GGSN retransmits the 'MBMS Session Start Request' message to the SGSN and re-initiates the MBMS bearer establishment process.
In step 708, the SGSN returns an "MBMS Session Start Response" message to the GGSN indicating that the Session creation is successful.
If the SGSN has available resources, after receiving the 'MBMS Session StartRequest' message retransmitted by the GGSN, the SGSN establishes an MBMS bearing context, stores the attribute related to the Session, and returns the 'MBMS Session Start Response' message to the GGSN, which indicates that the Session is successfully established.
It should be noted that the above embodiment is illustrated by a reliable session establishment procedure between the GGSN and the SGSN, but not limited thereto, and similarly, the method can be generalized to a reliable session establishment between the BM-SC and the GGSN, and between the SGSN and the BSC/RNC, and the principle is the same.
The procedure for reliably establishing a session between the BM-SC and the GGSN will be briefly described below. Please refer to fig. 9, which is a flowchart illustrating reliable session establishment between a four BM-SC and a GGSN according to an embodiment of the present invention, wherein the flowchart includes the following steps:
step 901, BM-SC sends a "Session Start Request" message to GGSN;
BM-SC sends a 'Session Start Request' message to GGSN to indicate the data transmission to be started and the relevant attributes of the Session, including: TMGI, QoS, MBMS service area, session ID, expected session duration, broadcast/multicast indication, SGSN list (for broadcast mode only), time of data transmission, 2G/3G indication, etc.
Step 902, GGSN returns "Session Start Response" message to BM-SC to indicate that creating Session fails;
after the GGSN receives the message of 'Session Start Request', because the resource is not available, the MBMS bearing context can not be established, and returns 'Session Start Response' message to the BM-SC, which indicates that the establishment of the Session is failed, and the reason value is 'GGSN has no resource available'.
Step 903, BM-SC resends the "Session Start Request" message to GGSN.
The BM-SC retransmits the "Session Start Request" message to the GGSN, which may be continuously retransmitted at a set time interval until a Session is successfully established with the GGSN, or continuously retransmitted within a time period not exceeding a set maximum retransmission number, or a time interval and a retransmission number of the retransmission may be considered at the same time.
In addition, after the GGSN returns a "Session Start Response" message to the BM-SC indicating that the Session creation is failed, if the resource is found to be available subsequently, the GGSN may actively notify the BM-SC, and resend the "Session Start Request" message after receiving the notification.
Step 904, the GGSN returns a "Session Start Response" message to the BM-SC indicating that the Session was created successfully.
If the GGSN has available resources, after receiving the message of "Session StartRequest" retransmitted by the BM-SC, the GGSN establishes the MBMS bearing context, stores the relevant attributes of the Session and the relevant SGSN, and returns a message of "Session Start Response" to the BM-SC to indicate that the Session is successfully established.
Therefore, when the subsequent resources of the GGSN are available, the GGSN and the BM-SC can establish the Session, thereby avoiding the adverse effect caused by no corresponding processing flow when the GGSN returns a 'Session Start Response' message to the BM-SC to indicate that the Session is failed in the prior art.
For reliable session establishment between the SGSN and the BSC/RNC, the same principle as the reliable session establishment between the GGSN and the SGSN and between the BM-SC and the GGSN is applied, and will not be described in detail herein.
The foregoing details describe the method for establishing a session in a multimedia broadcast multicast service according to an embodiment of the present invention, and accordingly, an embodiment of the present invention provides an MBMS network system.
Please refer to fig. 10, which is a schematic diagram illustrating a MBMS network according to an embodiment of the present invention.
As shown, the MBMS network system includes: a first network element device 101 and a second network element device 102.
A first network element device 101, configured to send a request message for establishing a Session and receive a returned response message in a Session start process of a broadcast or multicast service; and if the returned response message indicates that the session establishment fails due to the unavailable resources, retransmitting the request message for establishing the session.
The second network element device 102 is configured to return a response message to the first network element device 101 after receiving the request message for establishing the session, which is sent by the first network element device 101.
The first network element device 101 includes: a transceiving unit 1011 and a retransmission unit 1012.
A transceiving unit 1011, configured to send a request message for establishing a Session and receive a returned response message in a Session start procedure of a broadcast or multicast service;
a retransmitting unit 1012, configured to retransmit the request message for establishing the session at a set time interval and/or within a maximum retransmission number not exceeding a set maximum number of retransmissions after the response message received by the transceiving unit 1011 indicates that the session establishment has failed due to the unavailability of resources.
The second network element device 102 includes: a transceiving unit 1021, a detection unit 1022 and a processing unit 1023.
A transceiving unit 1021, configured to receive the request message for establishing a session sent by the first network element device 101, and return a response message to the first network element device 101.
A detecting unit 1022, configured to detect whether there are available resources after the transceiving unit 1021 receives the request message for establishing the session, which is sent by the first network element device 101.
A processing unit 1023, configured to record service information of a session establishment failure when the detecting unit 1022 detects that no resource is available, notify the transceiving unit 1021 to return a response message indicating that a session establishment failure is caused by resource unavailability to the first network element apparatus 101, and send a notification message indicating that a resource is available to the first network element apparatus 101 when the detecting unit 1022 subsequently detects that a resource is available.
After receiving the response message indicating that the session establishment fails due to the unavailability of the resource, which is returned by the second network element device 102, the transceiver 1011 of the first network element device 101 subsequently receives the notification message indicating that the resource is available, which is sent by the second network element device 102, at this time, the retransmission 1012 of the first network element device 101 resends the request message for establishing the session to the second network element device 102 according to the notification message received by the transceiver 1011.
The first network element device 101 is a GPRS gateway support node GGSN, and the second network element device 102 is a GPRS service support node SGSN; or, the first network element device 101 is a broadcast multicast service center BM-SC, and the second network element device 102 is a GGSN; or, the first network element device 101 is an SGSN, and the second network element device 102 is a base station controller BSC/radio network controller RNC.
When the first network element device 101 is a GPRS gateway support node GGSN, and the second network element device 102 is a GPRS service support node SGSN, after the SGSN receives an "MBMS Session Start Request" message sent by the GGSN, an MBMS bearer context cannot be established because resources are unavailable, and an "MBMS Session Start Response" message is sent to the GGSN, which indicates that Session establishment fails and the reason value is "SGSN has no resources available". After receiving the 'MBMS Session Start Response' message which indicates that the Session is failed to be created and returned from the SGSN, the GGSN retransmits the 'MBMS Session Start Request' message to the SGSN after delaying a period of time according to a certain time interval so as to wait for the SGSN to have available resources. Alternatively, the GGSN retransmits the data without exceeding the set maximum number of retransmissions, but may also consider the retransmission time interval and the number of retransmissions at the same time. Therefore, when the subsequent resources of the SGSN are available, the MBMS Session can be established between the GGSN and the SGSN, and the adverse effect caused by no corresponding processing flow when the MBMS Session Start Response returned from the SGSN to the GGSN indicates that the Session establishment fails in the prior art is avoided.
The first network element device 101 is a broadcast multicast service center BM-SC, and when the second network element device 102 is a GGSN, after the GGSN receives a "Session Start Request" message, because resources are unavailable, an MBMS bearer context cannot be established, and a "Session Start Response" message is returned to the BM-SC, which indicates that the Session establishment fails, and the cause value is "GGSN has no resources available". After receiving the "Session Start Response" message indicating that the Session creation is failed, which is returned by the GGSN, the BM-SC retransmits the Session Start Request "message to the GGSN, where the message may be retransmitted continuously at a set time interval until the Session is successfully established with the GGSN, or may be retransmitted continuously within a time interval not exceeding a set maximum retransmission number, or may consider the retransmission time interval and the retransmission number at the same time.
When the first network element device 101 is an SGSN and the second network element device 102 is a base station controller BSC/radio network controller RNC, the reliable session establishment procedure between the SGSN and the BSC/RNC is the same as the reliable session establishment principle between the GGSN and the SGSN, and between the BM-SC and the GGSN.
In summary, the method for establishing a session in an MBMS in the prior art is not very reliable, and after one network element device sends a request message to another network element device, if there is no corresponding processing flow when the session establishment fails due to unavailable resources, a series of problems may be caused, and the technical solution of the embodiment of the present invention is: in the Session starting Session start process of the broadcast or multicast service, a sending end sends a request message for establishing a Session to a receiving end; receiving a response message returned by the receiving end; and if the returned response message indicates that the session establishment fails due to the unavailable resources, the sending end sends the request message for establishing the session to the receiving end again. Therefore, when the upstream network element device knows that the establishment of the session fails due to the unavailability of the resources of the downstream network element device, even if the downstream network element device is not known when the resources are available, the session can be reestablished between the downstream network element device and the downstream network element device by sending the request message for establishing the session to the downstream network element device again, so that the user in the corresponding network element device area can be ensured to share the MBMS service. Therefore, the technical scheme of the embodiment of the invention realizes the reliable establishment of the session in the MBMS and avoids a series of problems caused by no corresponding processing flow after the session establishment fails in the prior art.
Further, when the request message is retransmitted in the embodiment of the present invention, the request message may be retransmitted continuously according to a set time interval until a session is successfully established with the GGSN, or retransmitted continuously within a time period not exceeding a set maximum retransmission number, or the time interval of retransmission and the retransmission number may be considered at the same time. In addition, the request message for establishing the session can be retransmitted after the notification message indicating that the resource is available is subsequently received.
Furthermore, the method for establishing the session in the embodiment of the present invention can be applied between the GGSN and the SGSN, or between the BM-SC and the GGSN; or between the SGSN and BSC/RNC.
In summary, the method and the network system for establishing a session in a multimedia broadcast multicast service according to the embodiments of the present invention are described in detail, and a person skilled in the art may change the concept of the embodiments of the present invention in the specific implementation and application scope.