WO2005013514A1

WO2005013514A1 - Method of providing multiple qos for mbms service

Info

Publication number: WO2005013514A1
Application number: PCT/KR2004/001930
Authority: WO
Inventors: Sung-Ho Choi; Kook-Heui Lee; Chang Duan; Detao Li
Original assignee: Samsung Electronics Co., Ltd.; Beijing Samsung Telecom R & D Center
Priority date: 2003-07-31
Filing date: 2004-07-30
Publication date: 2005-02-10
Also published as: CN1581744A

Abstract

A method of providing multiple QOS for an MBMS service in a wideband CDMA mobile communication system is proposed in the present invention. With the multiple QOS proposed in the present invention for MBMS service, the opportunity and capability of accessing MBMS service has been greatly improved for the downstream network nodes and the efficiency of the application of network resource has been improved also. The downstream network nodes can adjust the available resources for themselves.

Description

METHOD OF PROVIDING MULTIPLE QOS FOR MBMS SERVICE

BACKGROUND OF THE INVENTION

Field of the Invention The present invention relates to a method of providing multiple QOS for an MBMS service in a WCDMA communication system.

Description of the Prior Art Multimedia Broadcast and Multicast Service (hereinafter referred to as MBMS) is a new service under standardization by 3^rd Generation Partnership Project (hereinafter referred to as 3GPP). MBMS service is an unidirectional point-to-multipoint (p-t-m) service, whose most remarkable characteristic is that it can make use of radio resources and network resources efficiently. To explain MBMS service better, Figure 1 shows a structure of the system that provides MBMS service. As an example, Figure 2 shows a flowchart that a downstream network node applies for logging in MBMS service from an upstream network node. As shown in Figure 1, MBMS network structure is based on the core network of General Packet Radio Service (hereinafter referred to as GPRS) and adds new network elements. A Broadcast and Multicast Service Center 101 (hereinafter referred to as BM-SC) is the service control center of the MBMS system. A Gateway GPRS

Supporting Node 102 (hereinafter referred to as GGSN) and a Service GPRS Supporting Node 103 (hereinafter referred to as SGSN) compose the transmission network of MBMS service and provide routes for data transfer. A UMTS Terrestrial Radio Access Network 104 (hereinafter referred to as RAN ) provides radio resources for MBMS service over the air-interface. An User Equipment 105 (hereinafter referred to as UE) is a terminal device for receiving data. A Home Location Register 106 (hereinafter referred to as HLR) saves the data related to user and can provide services such as authentication of user. Gn/Gp 107 represents an interface between SGSN and GGSN. Gi 108 represents an interface between BM-SC and GGSN, and the protocol stack for this interface is based on the Internet Protocol (hereinafter referred to simply as IP protocol). Gmb 109 represents an interface between BM-SC and GGSN, and the protocol for this interface is specifically used to transfer MBMS signaling parameters. Radio resources used by MBMS service are not dedicated for one user, but are shared by all users using this service. It is necessary to e.- plain that MBMS service is an unidirectional downstream service, i.e., MBMS data is transferred sequentially from BM-SC to GGSN, from GGSN to SGSN, from SGSN to RNC, then from RNC to a UE via the air-interface. For the MBMS service, GGSN is the downstream node of BM-SC, which can transmit data to a plurality of GGSNs; SGSN is the downstream node of GGSN, which can transmit data to SGSNs; RNC is the downstream node of SGSN, which can transmit data to a plurality ofRNCs. Before the BM-SC decides to transmit MBMS data, it sends a session start message in advance to establish the corresponding network resources. The BM-SC sends the session start message to a plurality of GGSNs, then the GGSNs send MBMS session start message to a plurality of SGSNs, next the SGSNs also send MBMS session start notification to a plurality of RNCs. During this process, each downstream network node sends a corresponding feedback message to the upstream network node to establish the network resources once it receives the message from the upstream network node. For detailed information on this process, please refer to the embodiment portion of the present invention described latter. Here, only the idea that a downstream network node should apply for logging in MBMS service in advance if it wants to receive MBMS message or MBMS data from the corresponding upstream network node will be explained. And Figure 2 is taken as an example to describe a flowchart that a downstream network node applies for logging in MBMS service from the corresponding upstream network node in the existing technique. In Step 201 of the Figure 2, a RNC sends MBMS Login Request message to a SGSN. The MBMS Request message includes a Service ID and a RNCs address. In Step 202 of the Figure 2, after the SGSN receives the Login Request message from the RNC, it sends an MBMS Login Request message to a GGSN if it has not logged in the MBMS service from its upstream node (i.e., GGSN) yet. This message includes such parameters as a Service ID and a SGSN's address; otherwise, it skips to implement Step 206 directly. In Step 203 of the Figure 2, after the GGSN receives the Login Request message from the SGSN, it sends an MBMS Login Request message to a BM-SC if it has not logged in the MBMS service from its upstream node (i.e., BM-SC) yet. This message includes such parameters as a Service ID and a GGSN's address; otherwise, it skips to implement Step 205 directly. In Step 204 of the Figure 2, after the BM-SC receives the Login Request message from the GGSN, it records the GGSN's address into the corresponding MBMS service (which is specified by the Service ID in the received message) context. Then it sends the

MBMS Login Response message to the GGSN. In Step 205 of the Figure 2, after the GGSN receives the MBMS Login Response message transmitted in Step 204 from BM-SC, it establishes the corresponding MBMS service context, and records the SGSN's address in the message received in Step 202 into the MBMS service context. Then it sends the MBMS Login Response message to the SGSN. In Step 206 of the Figure 2, after the SGSN receives the MBMS Login Response message transmitted in Step 205 from the GGSN, it establishes the corresponding MBMS service context, and records the RNCs address in the message received in Step 201 into the MBMS service context. Then it sends the MBMS Login Response message to a RNC. Once the RNC receives this response message, it establishes the MBMS service context. Now, the login process completes. It is necessary to explain that the process from Step 202 to 205 in the Figure 2 could also be initialized by a UE in activating MBMS service. In this case, the SGSN can record the RNCs address into its MBMS service context implicitly, due to the message transmitted from the UE to the SGSN is via the RNC. Therefore, Step 201 and 206 can be omitted here. Because it is an existing technique, no more detail will be given here. In the existing MBMS service, only one QOS is provided. Therefore, when a session starts, if a certain network node (e.g., RNC, SGSN or GGSN) does not support the provided QOS, the MBMS service will be abandoned, for the QoS negotiating is not allowed for MBMS service. Thus, not only the network resource has been wasted, but also the possibility that network nodes provide MBMS service has been reduced to a lower level.

SUMMARY OF THE INVENTION

The object of the present invention is to provide a method such that when a session starts, an MBMS service provides multiple QOS. In this way, if a certain network node can not support the best QOS, it can select an appropriate lower QOS for itself. With this method, the network nodes can make a choice among the provided QOS so that the opportunity and capability of applying MBMS service has been greatly improved and the network resource has been well saved. In order to realize the above object, a method of providing multiple QOS for MBMS service comprising the steps of: (1) starting a session by a BM-SC, and sending to a GGSN a Session Start message, in which a plurality of QOS parameters are included; (2) selecting a supporting QOS and allocating a TEID for this QOS once the GGSN receives the Session Start message sent from the BM-SC in step (1), and sending to the BM-SC a Session Start Response message, in which the parameter TEID and QOS are included; (3) saving, by the BM-SC, the parameter TEID and QOS included in the received message after receiving the Session Start Response message sent by the GGSN in step (2), to indicate the success of establishing the bearer associating with the QOS between the GGSN and the BM-SC; (4) sending, by the GGSN, to a SGSN the MBMS Session Start message in which a plurality of QOS parameters are included after having sent the Session Start Response message in step (2); (5) selecting a supporting QOS and allocating TEID for this QOS after the SGSN receives the MBMS Session Start message sent by the GGSN in step (4), and sending to the GGSN the Session Start Response message in which the parameter TEID and QOS are included; (6) saving, by the GGSN, the parameter TEID and QOS included in the received message after receiving the MBMS Session Start Response message sent by the SGSN in step (5), to indicate the success of establishing the bearer associating with the QOS between the SGSN and the GGSN; (7) sending, by the SGSN, to RNCs a MBMS Session Start Notification message in which a plurality of QOS parameters are included after having sent the MBMS Session Start Response message in step (5); (8) selecting the supporting QOS and allocating TEID for this QOS after the RNC receives the MBMS Session Start Notification message sent by the SGSN in step (7), and counting the number of UEs and allocating air-resources for the UEs according to the QOS; (9) sending to the SGSN the MBMS Session Start Notification message in which the QOS and TEID parameter selected by the RNC in step 8 are included after the RNC implements step (8); (10) saving, by the SGSN, the parameter TEID and QOS included in the received message after receiving the MBMS Session Start Notification Response message sent by the RNC in step (9), to indicate the success of establishing the bearer associating with the QOS between the RNC and the SGSN. With the multiple QOS proposed in the present invention for MBMS service, the opportunity and capability of accessing MBMS service has been greatly improved for the downstream network nodes and the use efficiency of the network resource has been improved also. The downstream network nodes can adjust the available resources for themselves.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates the logic structure of an MBMS system; Figure 2 shows a process that a downstream network node applies for logging in MBMS service from its upstream network node in the existing technique; Figure 3 shows a process that an MBMS session starts in the present invention; Figure 4 illustrates the first process of refreshing the bearer between a RNC and a SGSN in the present invention; Figure 5 illustrates the second process of refreshing the bearer between a RNC and a SGSN in the present invention; Figure 6 illustrates the first process of establishing a new bearer between a SGSN and a GGSN in the present invention; Figure 7 illustrates the second process of establishing a new bearer between a SGSN and a GGSN in the present invention; Figure 8 illustrates a process of removing the bearer between a SGSN and a GGSN in the present invention; Figure 9 illustrates the first process of establishing a new bearer between a GGSN and a BM-SC in the present invention; Figure 10 illustrates the second process of establishing a new bearer between a GGSN and a BM-SC in the present invention; Figure 11 illustrates a process of removing the bearer between a GGSN and a

BM-SC in the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention is mainly composed of following three processes: The process of establishing network resource when the session starts;

> The process of establishing new bearers between RNC and SGSN, SGSN and GGSN, GGSN and BM-SC during the process of a session;

> The process of releasing old bearers between RNC and SGSN, SGSN and GGSN, GGSN and BM-SC during the process of a session.

Explanation on terminology: QOS: Quality of Service, it refers to the quality parameter of a service. It includes such attributes as service type, bearing bit rate and so on. These attributes are applied to customize the characteristic of a bearer. TEID: Bearer Identifier, it is applied to indicate the bearer established between the network nodes (e.g., GGSN and SGSN). Downstream Bearer: it refers to the bearer for transmitting downstream data. And the downstream data refers to the data that is transmitted from an upstream node to a downstream node, i.e., from BM-SC to GGSN, GGSN to SGSN, and SGSN to RNC and UE. BM-SC transmits MBMS service data in the unit of "session". When an MBMS service session starts, BM-SC transmits the "Session Start" message in advance and waits for a predetermined period to make the network have sufficient time in preparing network resources. Then it transmits the real data. During a session, BM-SC transmits data a plurality of times. When BM-SC prepares to terminate the session, it sends out the

"Session Over" message to release the network resources. The period of a session process can last either several days long or several minutes short, depending on the requirements of the MBMS service. Figure 3 illustrates a process that BM-SC initializes a session in the present invention. In Step 301 of Figure 3, the MBMS service context in BM-SC mainly includes following parameters:

> Service ID Service Area

> QOS List ■ QOS1 ■ QOS2 ■ QOSn

> GGSN List (GGSN information list): ■ GGSN1 information Address - QOS&TEID List • (QOSl, TEIDl) • • (QOSn, TEIDn) BM-SC's service contexts are established by the operators with the function of

O&M (Operation and Maintenance). For each MBMS service, there exists a corresponding service context. Here, the Service ID uniquely identifies the MBMS service corresponding to the service context. The Service Area (Service Area parameter) indicates the area of using the MBMS service. It can be specified to a cell. The QOS List refers to a parameter group, including one to more QOS parameters denoted by from

QOSl to QOSn. The QOSl indicates the highest service quality, i.e., if a network device providing MBMS service supports QOSl, the quality of the MBMS service that it provides is the best; QOSn indicates the lowest service quality. From QOSl to QOSn, the corresponding service qualities degrade gradually, i.e., the corresponding service qualities are arranged in descending sort from QOSl to QOSn. The GGSN List is a parameter group. Because a BM-SC rules many GGSNs, it allocates each GGSN (which has logged in MBMS service) an information entry for saving the relevant information of the GGSN in this parameter group. The information of each GGSN is generated after the GGSN sends the Login Request message for the first time. But at time moment, only the corresponding GGSN's address information has been saved in the BM-SC's service context, and the QOS&TEID List is empty, for TEID and selected QOS can not be obtained until the GGSN sends the Session Start Response message corresponding to the Session Start message sent by the BM-SC, as shown in Step 304 of Figure 3. Here, the TEID is the bearer address of the data generated by the GGSN, the QOS is the one that the GGSN selects from the QOS List included in the session start message sent by the

BM-SC. One TEID corresponds to one QOS. And the QOS&TEID List indicates that if a GGSN has selected multiple QOS, the GGSN should allocate a unique TEID for each QOS. In Step 302 of the Figure 3, the BM-SC sends the Session Start message to the GGSN. This message mainly includes following parameters:

> Service ID

> Service Area

> QOS List ■ QOSl ■ QOS2

QOSn The Service ED uniquely identifies the service whose session starts. The Service Area indicates the area of using the service. The QOS List indicates all levels of QOS that the service supports (denoted by from QOS l to QOSn), where: QOSl indicates the best service quality and QOSn indicates the poorest service quality. The corresponding service qualities are arranged in descending sort from QOS l to QOSn. In Step 303 of the Figure 3, after the GGSN receives the Session Start message sent by the BM-SC in Step 302, it finds the corresponding MBMS service context according to the Service ID included in the received message and saves the parameter Service Area and the QOS List into the corresponding entries of its MBMS service context. The GGSN's service context is established after the GGSN is responded by the BM-SC to the Login Request message sent by the GGSN in Figure 2. It mainly includes following parameters:

> Service ID (Service Identifier)

> Service Area (Service Area)

> QOS List ■ QOSl ■ QOS2

■ QOSn

> SGSN List (SGSN information list): ■ SGSN1 information - Address - QOS&TEID List • (QOSh, TEIDh) • • (QOSn, TEIDn)

> Local QOS&TEID List ■ (QOSm, TEIDm)

■ (QOSn, TEIDn) wherein the Service ID is a parameter that has been saved when the context is established. The Service Area and the QOS List are saved into the context after the Session Start message from the BM-SC has been received. The SGSN List is a parameter group. Because a GGSN rules many SGSNs, it allocates each SGSN (which has logged in MBMS service) an information entry for saving the relevant information of the SGSN in this parameter group. The information of each SGSN includes such parameters as the address and the QOS&TEID List. The information of each SGSN is joined in by the GGSN after the SGSN sends the Login Request message to the GGSN for the first time, but only the address will be recorded by the GGSN, and the QOS&TEID List is empty. The QOS&TEID Lists of the SGSN information entry in the SGSN List is a parameter group, which includes a plurality of binary parameters with each including the two parameters of QOS and TEID. After the GGSN sends the MBMS Session Start message to the SGSN in Step 305 of Figure 3, and once it receives an MBMS Session Start Response message from the SGSN, it considers the QOS and TEID included in the received message as a binary parameter and saves it into the service context's QOS&TEID List corresponding to the SGSN. In Step 304 of Figure 3, the GGSN selects the supporting highest QOS from the QOS List provided by the BM-SC (assuming it be QOSm, then it is a QOS that lies in those from QOSl to QOSn, i.e., l≤m≤n) and allocates a TEID (assuming it be TEID ) for the selected QOS. The relationship between the TEID and the QOS is one to one correspondence. At this moment, the Local QOS&TEID List in the GGSN's MBMS service context is empty. And the GGSN adds a new binary entry (QOSm, TEIDm) into the Local QOS&TEID List. The Local QOS&TEID List in the GGSN's MBMS service context is used to save the TEID and QOS for each bearer established between the node (GGSN) and its upstream network node (BM-SC). Then the GGSN transmits the selected QOSm and TEIDm to the BM-SC by including them into the Session Start Response message. After the BM-SC receives the Session Start Response message from the GGSN, it will find the QOS&TEID List in the GGSN information entry corresponding to the GGSN from the GGSN List in the service context and add a new binary entry (QOSm, TEIDm) in it. This indicates that a new downstream data bearer identified by TEIDm has been established between the GGSN and BM-SC. It is necessary to note that the GGSN may reply the BM-SC with a plurality of Session Start Response messages in the subsequent steps with each including the binary entry (QOS, TEID). Both the QOS and the TEID are unique and are to be saved into the QOS&TEID List corresponding to the GGSN in the BM-SC's service context. In this way, when the

BM-SC transmits data to the GGSN in step 314, if a plurality of downstream data bearers identified by different TEIDs have been established between the BM-SC and the GGSN, the BM-SC transmits a piece of data with the QOS corresponding to the TEID via each of the downstream data bearers uniquely identified by the TEIDs. In step 305 of the Figure 3, the GGSN sends an MBMS Session Start message to the SGSN. This message mainly includes following parameters:

> Service ID Service Area

> QOS List ■ QOSm

QOSn The Service ID uniquely identifies the service whose session starts. The Service Area indicates the area of using the service. The QOS List indicates that the service supports one to more levels of QOS. Note: because the QOS that the GGSN has selected from the QOS List included in the Session Start message sent by the BM-SC in step 302 is the highest that the GGSN can support, i.e., QOSm (QOSm lies in those from QOSl to QOSn, i.e., l≤m≤n), the range of the QOS List included in the MBMS Session Start message that the GGSN sends to the SGSN is from QOSm to QOSn. In step 306 of the Figure 3, after the SGSN receives the Session Start message sent by the GGSN in step 305, it finds the corresponding MBMS service context according to the Service ID included in the received message and saves the parameter Service Area and the QOS List into the corresponding entries of its MBMS service context. SGSN's service context is established after the SGSN is responded by the GGSN to the Login Request message sent by the SGSN in Figure 2. It mainly includes following parameters: Service ID (Service Identifier)

> Service Area (Service Area)

> QOS List ■ QOSm

■ QOSn

> RNC List (RNC information list): ■ RNC1 information - Address - QOS - TEID ■ RNC2 information - Address - QOS - TEID

> Local QOS&TEID List ■ (QOSh, TEIDh)

(QOSn, TEIDn) wherein the Service ID is a parameter that has been saved when the context is established. The Service Area and QOS List are saved into the context after the Session Start message from the GGSN has been received. Since the QOS in the QOS List included in the MBMS Session Start message sent by the GGSN ranges from QOSm to

QOSn (l≤m≤n) (which is mentioned in step 305), the QOS saved in the QOS List of the SGSN also ranges from QOSm to QOSn. The RNC List is a parameter group. Because an SGSN rules many RNCs, it allocates each RNC (which has logged in MBMS service) an information entry for saving the relevant information of the RNC in this parameter group. The information about each RNC includes such parameters as the address, the QOS and the TEID. For each RNC, when the SGSN registers it as the one that requires MBMS service for the first time, the SGSN saves the information of the RNC But at this moment, only the address has been recorded by the SGSN, while both QOS and TEID entries are empty. Note: only one QOS and TEID have been saved in SGSN's

RNC List for each RNC. This is because that: between each RNC and SGSN, RNC selects only one QOS. For this QOS, the RNC allocates TEID, establishes the downstream data bearer identified by the TEID in the lu interface (between RNC and SGSN) and allocates the air-resources in the Uu interface (between RNC and UE). This is not similar to that in the Gn interface (between the SGSN and GGSN), possible multiple QOS corresponds to the downstream data bearer of each QOS, as will be explained in the subsequent steps. After SGSN sends the MBMS Session Start Notification message to RNC in step 308 of Figure 3, and once it receives an MBMS Session Start Notification Response message from some RNCs in step 311 of Figure 3, it saves the QOS and TEID included in the received message into the RNC-related information entry in the service context. In step 307 of Figure 3, the SGSN selects the supporting highest QOS from the QOS List provided by the GGSN (assuming it be QOSk, then it should be a QOS that lies among those from QOSm to QOSn, i.e., m≤k≤n) and allocates a TEID (assuming it be TEEDk) for the selected QOS. The relationship between the TEID and the QOS is one to one correspondence. At this moment, the Local QOS&TEID List in the SGSN's MBMS service context is empty. And the SGSN adds a new binary entry (QOSk, TEIDk) into the Local QOS&TEID List. The Local QOS&TEID List in the SGSN's service context is used to save the TEID and QOS for each bearer established between the node (SGSN) and its upstream network node (GGSN). Then the SGSN transmits the selected QOSk and TEIDk to the GGSN by including them into the Session Start Response message. After the GGSN receives the Session Start Response message from the SGSN, it will find the QOS&TEID List in the information of the SGSN from the SGSN List in the service context and add a new binary entry (QOSk, TEIDk) in it. This indicates that a new downstream data bearer identified by TEIDk has been established between the SGSN and GGSN. It should be noted that the SGSN may reply the GGSN with a plurality of Session Start Response messages in the subsequent steps with each including the binary entry (QOS, TEED). Both the QOS and the TEID are unique and are to be saved into the QOS&TEID List corresponding to the SGSN in the GGSN's service context. In this way, when the GGSN receives the data from the BM-SC and transmits to the SGSN in step 314, if a plurality of downstream data bearers identified by different TEIDs have been established between the GGSN and the SGSN, the GGSN transmits a liece of data with the QOS corresponding to the TEID via each of the downstream data bearers uniquely identified by the TEIDs. En step 308a of Figure 3, the GGSN compares the QOSk received in step 307 with the QOSs in all binary entries (QOS, TEED) saved in its own Local QOS&TEID List. If the former is not the same as any of the latter, it indicates that the GGSN has established no downstream data bearer for the QOS between the GGSN and the BM-SC yet. In this case, the GGSN allocates a new TEEDh for the QOSk and saves (QOSk, TEIDh) into the Local QOS&TEID List. Then the GGSN sends the Session Start Response message to the BM-SC, including such parameters as the QOS (QOSk) and the TEID (TEIDh). After receiving this message, the BM-SC operates the same as that in step 304, saving the binary entry (QOS, TEID) into the QOS&TEID List corresponding to the GGSN.

This indicates that a new downstream data bearer identified by TEID (TEIDh) has also been established between the BM-SC and the GGSN. In step 308b of the Figure 3, the SGSN sends an MBMS Session Start Notification message to the RNC. This message mainly includes following parameters: > Service ED (Service Identifier) Service Area (Service Area)

> QOS List ■ QOSk ■ QOSn wherein the Service ID uniquely identifies the service whose session starts. The Service Area indicates the area of using the service. The QOS List indicates that the service supports one to more levels of QOS. Note: because the QOS that the SGSN has selected from the QOS List included in the Session Start message sent by the GGSN in step 305 is the highest that the SGSN can support, i.e., QOSk (QOSk lies in those from QOSm to

QOSn, i.e., m≤k≤n), the range of the QOS List included in the MBMS Session Start Notification message that tiV SGSN sends to the RNC is from QOSk to QOSn. En step 309 of the Figure 3, after the RNC receives the MBMS Session Start Notification message from the SGSN in step 308b, if the RNC has no service context for this MBMS service yet, it will establish a MBMS service context directly and save all parameters included in the MBMS Session Start Notification message into it; otherwise, it will find the corresponding MBMS service context according to the Service ID included in the received message and save the parameter Service Area and the QOS List into the corresponding entries of its MBMS service context. RNCs MBMS service context mainly includes following parameters:

> Service ID (Service Identifier) Service Area (Service Area)

> QOS List ■ QOSk

■ QOSn

> QOS

> TEID wherein the Service ED is a parameter that has been saved when the context is established. The Service Area and the QOS List are saved into the context after the Session Start message from the SGSN has been received. Since the QOS in the QOS List included in the MBMS Session Start Notification message sent by the SGSN ranges from QOSk to QOSn (m≤k≤n), as described in step 308b, the QOS saved in the QOS List of RNC also ranges from QOSk to QOSn. According to current resource conditions, the RNC selects the highest QOS (QOSn≤QOS≤QOSk) that it can support among those from QOSk to QOSn, and allocates a TEID for the selected QOS. Then it saves the QOS and TEED into the service context. In step 310 of the Figure 3, the RNC counts the number of UEs which use MBMS service by the in-the-air paging, and allocates the resource of air-interface according to the counting result. In step 311 of the Figure 3, the RNC transmits the QOS and the TEED selected in step 309 to the SGSN by including them into the MBMS Session Start Notification message. Note: only one downstream data bearer identified by TEED is established between the RNC and the SGSN for each MBMS service. While between the SGSN and the GGSN, or between the GGSN and the BM-SC, a plurality of downstream data bearers are possible established for each MBMS service. In step 312 of the Figure 3, after the SGSN receives the Session Start Notification Response message from the RNC, it will find the information entry of the RNC from the RNC List in the service context and save the QOS and TEID in it. This indicates that a new downstream data bearer identified by the TEID has been established between the SGSN and the RNC. Then, the SGSN compares the QOS included in the received message with the QOSs in all binary entries (QOS, TEID) saved in its own Local QOS&TEID List. If the former is not the same as any of the latter, it indicates that the SGSN has established no downstream data bearer for the QOS between the SGSN and GGSN yet. In this case, the SGSN allocates a new TEID for the QOS and saves it into the Local QOS&TEID List in the form of a binary entry (QOS, TEID) and transmits the binary entry to the GGSN by including it into the MBMS Session Start Response message. In step 313 of the Figure 3, if the GGSN receives the Session Start Notification Response message from the SGSN, it will find the QOS&TEID List in the information entry of the SGSN from the SGSN List in the service context and save the QOS and TEED as a new binary entry (QOS, TEED) in it. This indicates that a new downstream data bearer identified by TEED has been established between the SGSN and GGSN. Then, the GGSN compares the QOS included in the received message with the QOSs in all binary entries (QOS, TEED) saved in its own Local QOS&TEED List. If the former is not the same as any of the latter, it indicates that GGSN has established no downstream data bearer for the QOS between the GGSN and the BM-SC yet. In this case, the GGSN allocates a new TEED for the QOS and saves it into the Local QOS&TEID List in the form of a binary entry (QOS, TEED) and transmits the binary entry to the BM-SC by including it into the MBMS Session Start Response message. After receiving this message, the BM-SC operates the same as that in step 304, saving the binary entry (QOS, TEID) into the QOS&TEED List corresponding to the GGSN. This indicates that a new downstream data bearer identified by the TEID (TEIDh) has also been established between the BM-SC and GGSN. In step 314 of the Figure 3, the BM-SC transmits real MBMS data via the data bearers established between the BM-SC and GGSN after a predetermined period (the length of the period can be preset by the operator enough for the nodes of GGSN, SGSN and RNC in resources preparing) when the Session Start message is sent out in step 301. If a plurality of downstream data bearers have been established between the BM-SC and GGSN, the BM-SC transmits a piece of data via each of the downstream data bearers, and the QOS used for transmitting the data should be in accordance with the one corresponding to the bearer. After the GGSN receives the MBMS data, it transmits the received data via the data bearer established between the GGSN and SGSN. If a plurality of downstream data bearers have been established between GGSN and SGSN, the GGSN transmits a piece of data via each of the downstream data bearers, and the QOS applied to transmit the data should be in accordance with the one corresponding to the bearer. After SGSN receives the MBMS data, it transmits the received data via the data bearer established between SGSN and RNC. Since only one downstream data bearer exists between the SGSN and RNC, the SGSN transmits only one piece of data to each RNC, and the QOS used for transmitting the data should be in accordance with the one corresponding to the bearer. After receiving the MBMS data, the RNC transmits it to UEs via the air-interface. At the beginning of a session, if the RNC has not enough resource, it may select a lower QOS to establish the bearer, i.e., in step 309 of Figure 3, the RNC may select a 5 lower QOS and allocate a TEID for it, then transmit the QOS and TEID by message to SGSN. If the RNCs resources increase during the process of a session (i.e., the session is not over) because that the number of UEs ruled by the RNC reduces, or the number of MBMS services provided by the RNC reduces or for other reasons, the RNC will interact with the SGSN, requesting to establish a new bearer for some MBMS service

L0 (this bearer possesses higher QOS) and release old bearers. Figure 4 illustrates the first method of implementing this process and Figure 5 illustrates the second method of implementing this process. In step 401 of the Figure 4, since resources available for RNC increase, the RNC checks the QOS of the bearer established for some MBMS service. If it finds out that L5 this QOS is lower than the maximum among those saved in the QOS List of its service context (i.e., the service context mentioned in step 309 of Figure 3) and it thinks that it could support a QOS higher than the one, it will transmit the MBMS service's Service ED and the bearer's TEED by the MBMS Bearer Update Request message to the SGSN. In step 402 of the Figure 4, after the SGSN receives the message from the RNC, if

20 the SGSN accepts this RNCs request, it finds the RNC information entry in the RNC List of the service context and deletes the QOS and TEID from the RNC information entry, and sends the MBMS Bearer Update Response message to the RNC, including the parameter Cause, which indicates success or failure. Here, the Cause indicates success. If the SGSN does not accept the RNCs request, it performs no more operation than to

25 send the MBMS Bearer Update Response message to the RNC, including the parameter Cause, which indicates failure here. After the RNC receives the MBMS Bearer Update Response message from the SGSN, if the parameter Cause indicates success, the RNC deletes the QOS and TEID saved in its context. This indicates that the bearer previously established between the RNC and SGSN has been successfully removed; if the 0 parameter Cause indicates failure, the RNC performs no more operation. In step 403 of the Figure 4, if the SGSN has accepted the RNCs request in step 402, it checks the QOS List saved in its own service context and transmits the QOSs from the maximum one that it can support to QOSn to the RNC in the form of QOS List by the MBMS Session Start Notification message which includes the Service ID also. 5 In step 404 of the Figure 4, after the RNC receives the message sent by the SGSN in step 403, it finds the corresponding MBMS service context according to the Service ED included in the received message and saves the parameter QOS List into the corresponding entry of its MBMS service context. According to current resource conditions, the RNC selects the highest QOS that it can support from the QOS List transmitted by the SGSN in step 403 and allocates a TEID for the selected QOS. Then it saves the QOS and TEID into the service context. Then, the RNC counts the number of

UEs which use MBMS service via the in-the-air paging, and re-allocates the resource of air-interface according to the counting result. In step 405 of the Figure 4, the RNC transmits the selected QOS and allocated TEID in step 404 to the SGSN by including them in the MBMS Session Start Notification Response message, which also includes the parameter Cause, which indicates the reason of success or failure. After the SGSN receives the message from the RNC, if the parameter Cause indicates success, the SGSN saves the QOS and TEID in the corresponding RNC information entry in its service context. This indicates that a new bearer with higher QOS has been successfully established between the RNC and SGSN; If the parameter Cause indicates failure, the SGSN performs no more operation than to abandon the parameters in the received message. As another method of requesting to change bearers by RNC, the main difference between the process illustrated in Figure 5 and that illustrated in Figure 4 lies in that: in the process illustrated in Figure 5, the parameters transmitted by message are slightly different to that of figure. This is because RNC can request QOS for the new bearer on its own. Of course, the QOS should be selected from the QOS List saved by the RNC. In step 501 of the Figure 5, since resources available for RNC increase, the RNC checks the QOS of the bearer established for some MBMS service. If it finds out that this QOS is lower than the maximum among those saved in the QOS List of its service context (i.e., the service context mentioned in step 409 of Figure 4) and it thinks that it could support a QOS higher than the one, it will again select the highest QOS that it can support from the QOS List and transmit the selected highest QOS and the MBMS service's Service ID and the bearer's TEID to the SGSN by the MBMS Bearer Update Request message. The new QOS in the MBMS Bearer Update Request message is just the highest one that RNC has selected again. In step 502 of the Figure 5, after the SGSN receives the message from the RNC, if the SGSN accepts this RNCs request, it finds the RNC information entry in the RNC List of the service context and deletes the QOS and TEED from the RNC information entry, and sends the MBMS Bearer Update Response message to RNC, including the parameter Cause, which indicates success or failure. Here, the Cause indicates success.

If the SGSN does not accept the RNCs request, it performs no more operation than to send the MBMS Bearer Update Response message to RNC, including the parameter Cause, which indicates failure here. After the RNC receives the MBMS Bearer Update Response message from the SGSN, if the parameter Cause indicates success, the RNC deletes the QOS and TEID saved in its context. This indicates that the bearer previously established between the RNC and SGSN has been successfully removed; if the parameter Cause indicates failure, the RNC performs no more operation. In step 503 of the Figure 5, if the SGSN has accepted the RNCs request in step 502, it transmits the parameter New QOS (which is included in the message received in step 501) and the MBMS Service ID to the RNC by the MBMS Session Start Notification message. In step 504 of the Figure 5, after the RNC receives the message sent by the SGSN in step 503, it finds the corresponding MBMS service context according to the Service ID included in the received message and allocates a TEID to the QOS in the message, then saves the parameter the QOS and TEED into its service context. Then the RNC counts the number of UEs which use MBMS service the in-the-air paging, and re-allocates the resource of air-interface according to the counting result. In step 505 of the Figure 5, the RNC transmits the newly allocated TEID in step 504 to the SGSN by including it in the MBMS Session Start Notification Response message, which also includes the parameter Cause, which indicates the reason of success or failure. After the SGSN receives the message from the RNC, if the parameter Cause indicates success, the SGSN saves the TEID included in the message and the New QOS included in the message received in step 501 into the corresponding RNC information entry in its service context. This indicates that a new bearer with higher QOS has been successfully established between the RNC and SGSN; if the parameter Cause indicates failure, the SGSN performs no more operation than to abandon the TEED and the New QOS. After the processes described in Figure 4 and Figure 5, new data bearers have been established while the old ones between RNCs and SGSN have been released. Since new bearers are associated with new QOSs and the data transmitted by the SGSN via the bearers originates from the upstream node GGSN, the SGSN requires to check whether the corresponding bearers between itself and the GGSN have already been established or not (the QOSs of these bearers match that of the new bearers between RNCs and SGSN). If not, the SGSN is required to interact with the GGSN to establish new bearers; meanwhile, since the old bearer between the SGSN and the RNC has been released, the SGSN requires checking the QOS of the released bearer. If QOS of the released bearer is not associated with any of the bearers established between the SGSN and all RNCs ruled by the SGSN, the SGSN should interact with the GGSN to release the data bearer associating with the QOS between the SGSN and GGSN. There are two methods for interacting to establish a bearer between the SGSN and GGSN: one is described in Figure 6 and the other is described in Figure 7. The process of interacting to release a bearer between the SGSN and GGSN is illustrated in figure 8. Figure 6 illustrates the first method of establishing a bearer between the SGSN and GGSN. In step 601 of the Figure 6, since a new bearer between the SGSN and RNC has been established while the old one has been released in the processes mentioned in Figure 4 and Figure 5, and the new bearer associates with new QOS, the SGSN checks the QOS. If none of the bearers established between the SGSN and GGSN associates with the QOS, the SGSN sends the MBMS Bearer Establishment Request message to the GGSN to initiate the process of establishing a new bearer. This message includes the

Service ED and QOS, wherein the parameter QOS is just the one associated with the bearer that the SGSN wants to establish. En step 602 of the Figure 6, after the GGSN receives the message from the SGSN, if the GGSN accepts the request, it sends the MBMS Bearer Establishment Response message to the SGSN, including the parameter Cause, which indicates the reason of success or failure. En step 603 of the Figure 6, if the GGSN has accepted SGSN's request in step 602, it sends SGSN the MBMS Session Start message which is used to establish the data bearer between the GGSN and SGSN. This message includes the Service ED (Service Identifier) and the QOS. Wherein the QOS is just the one that the SGSN requires in the

MBMS Bearer Establishment Request message in step 601. In step 604 of the Figure 6, after the SGSN receives the message transmitted by the GGSN in step 603, it allocates a TEID for the QOS and saves the TEID and QOS into the service context's QOS&TEID List as a binary entry. Then the SGSN sends the GGSN a MBMS Session Start Response message, which includes the parameters QOS and TEED, wherein TEID is just the one that the SGSN allocates, and the QOS is the one included in the message that the GGSN sends out in step 603. After the GGSN receives the MBMS Session Start Response message from the SGSN, it saves QOS and TEID into the corresponding information entry of the SGSN in the SGSN List. Therefore, a new bearer identified by the TEED and associated with the QOS has been established between the SGSN and GGSN. Figure 7 illustrates the second method of establishing a bearer between the SGSN and GGSN. In step 701 of the Figure 7, since a new bearer between the SGSN and RNC has been established while the old one has been released in the processes mentioned in Figure 4 and Figure 5, and the new bearer associates with new QOS, the SGSN checks the QOS. If none of the bearers established between the SGSN and GGSN associates with the QOS, the SGSN sends the MBMS Bearer Establishment Request message to the GGSN to initiate the process of establishing a new bearer. This message includes the Service ID (Service Identifier), QOS and TEED, wherein the parameter QOS is just the one associated with the bearer that the SGSN wants to establish and the TEED is the identifier that the SGSN allocates to the bearer. In step 702 of the Figure 7, after the GGSN receives the MBMS Session Start Response message from the SGSN, it saves QOS and TEID into the corresponding information entry of the SGSN in the SGSN List, and sends SGSN the MBMS Bearer Establishment Response message, which includes the parameter Cause (which indicates the reason for success or failure). Therefore, a new bearer identified by the TEID and associated with the QOS has been established between the SGSN and GGSN. Figure 8 illustrates a process that SGSN interacts with GGSN to release a bearer. In step 801 of the Figure 8, since the old bearer associated with a QOS between the SGSN and RNC has been released while a new one has been established in the processes mentioned in Figure 5 and Figure 6, the SGSN checks the QOS. If none of the bearers established between the SGSN and the GGSN associates with the QOS, it indicates that no bearer is using this QOS. Also, the SGSN should release any bearer that associates with the QOS between the SGSN and the GGSN. Then the SGSN sends the GGSN the MBMS Bearer Release Request message, which includes the Service ED, TEED and NSAPI. TEID identifies the bearer to be released, NSAPI and TEID identify the parameters like QOS, etc. associated with bearer to be released. In step 802 of the Figure 8, after the GGSN receives the MBMS Bearer Release Request message from the SGSN, it finds the corresponding information entry of the SGSN according to the parameters included in the received message, and deletes the QOS and TEED from the information entry. Then the GGSN sends the SGSN the MBMS

Bearer Release Response message, which includes the parameter Cause (which indicates the reason for success or failure). Once the SGSN receives the message from the GGSN, it also deletes the corresponding QOS and TEID. Therefore, the bearer associating with an unused QOS and identified by TEID has been released between the SGSN and GGSN. After the processes described in Figure 6 and Figure 7, new data bearers have been established between the SGSN and GGSN. Since new bearers are associated with new QOSs and the data transmitted by GGSN via the bearers originates from the upstream node BM-SC, the SGSN requires to check whether the corresponding bearers between itself and the BM-SC have already been established or not (the QOSs of these bearers match that of the new bearers between SGSN and GGSN). If not, the GGSN is required to interact with the BM-SC to establish new bearers. There are two methods for interacting to establish a bearer between the GGSN and BM-SC: one is described in Figure 9 and the other is described in Figure 10. Figure 9 illustrates the first method of establishing a bearer between GGSN and BM-SC. In step 901 of the Figure 9, since a new bearer between GGSN and SGSN has been established in the processes mentioned in Figure 6 and Figure 7, and the new bearer associates with a new QOS, the SGSN checks the QOS. If none of the bearers established between the GGSN and BM-SC associates with the QOS, the GGSN sends the MBMS Bearer Establishment Request message to the BM-SC to initiate the process of establishing a new bearer. This message includes the Service ID (Service Identifier) and QOS, where the parameter QOS is just the one associated with the bearer that the

GGSN wants to establish. In step 902 of the Figure 9, after the GGSN receives the message from the BM-SC, if the BM-SC accepts the request, it sends the MBMS Bearer Establishment Response message to the GGSN, including the parameter Cause, which indicates the reason of success or failure. In step 903 of the Figure 9, if the BM-SC has accepted GGSN's request in step 902, it sends the GGSN the MBMS Session Start message which is used to establish the data bearer between the BM-SC and GGSN. This message includes the Service ID (Service

Identifier) and the QOS. The QOS is just the one that the GGSN requires in the MBMS Bearer Establishment Request message in step 901. In step 904 of the Figure 9, after the GGSN receives the message transmitted by the BM-SC in step 903, it allocates a TEID for the QOS and saves the TEID and QOS into its own Local QOS&TEID List as a binary entry. Then the GGSN sends the BM-SC the MBMS Session Start Response message, which includes the parameters QOS and TEID, wherein TEED is just the one that the GGSN allocates, and QOS is the one included in the message that the BM-SC sends out in step 903. After the BM-SC receives the MBMS Session Start Response message from the GGSN, it saves QOS and TEID into the corresponding information entry of the GGSN in the GGSN List. Therefore, a new bearer identified by the TEED and associated with the QOS has been established between the GGSN and BM-SC. Figure 10 illustrates the second method of establishing a bearer between GGSN and BM-SC. En step 1001 of the Figure 10, since a new bearer between the GGSN and SGSN has been established in the processes mentioned in Figure 6 and Figure 7, and the new bearer associates with a new QOS, the SGSN checks the QOS. If none of the bearers established between the GGSN and BM-SC associates with the QOS, the GGSN sends the MBMS Bearer Establishment Request message to the BM-SC to initiate the process of establishing a new bearer. This message includes the Service ID (Service Identifier), QOS and TEID, wherein the parameter QOS is just the one associated with the bearer that the GGSN wants to establish and TEID is the identifier that the GGSN allocates to the bearer. In step 1002 of the Figure 10, after the BM-SC receives the MBMS Session Start

Response message from the GGSN, it saves QOS and TEE) into the corresponding information entry of the GGSN in the GGSN List, and sends the GGSN the MBMS Bearer Establishment Response message, which includes the parameter Cause (which indicates the reason for success or failure). Therefore, a new bearer identified by the TEID and associated with the QOS has been established between the GGSN and

BM-SC. Figure 11 illustrates a process that GGSN interacts with BM-SC to release a bearer. En step 1101 of the Figure 11, since the old bearer associated with a QOS between GGSN and SGSN has been released in the process mentioned in Figure 8, the GGSN checks the QOS. If none of the bearers established between GGSN and SGSN associates with the QOS, it indicates that no bearer is using this QOS. Also, the GGSN should release any bearer that associates with the QOS between GGSN and BM-SC. Then the GGSN sends BM-SC the Bearer Release Request message, which includes the Service ID, TEID and NSAPI. TEID identifies the bearer to be released, NSAPI and TEID identify the parameters like QOS, etc. associated with bearer to be released. En step 1102 of the Figure 11, after the BM-SC receives the Bearer Release Request message from the GGSN, it finds the corresponding information entry of the GGSN according to the parameters included in the received message, and deletes the QOS and TEID from the information entry. Then the BM-SC sends the GGSN the Bearer Release Response message, which includes the parameter Cause (which indicates the reason for success or failure). Once the GGSN receives the message from the BM-SC, it also deletes the corresponding QOS and TEED. Therefore, the bearer associating with an unused QOS and identified by TEID has been released between the GGSN and BM-SC.

Claims

WHAT IS CLAIMD IS:

1. A method of providing multiple QOS for MBMS service comprising the steps of: (1) starting a session by a BM-SC, and sending to a GGSN a Session Start message, in which a plurality of QOS parameters are included; (2) selecting a supporting QOS and allocating a TEID for this QOS once the GGSN receives the Session Start message sent from the BM-SC in step (1), and sending to the BM-SC a Session Start Response message, in which the parameter TEID and QOS are included; (3) saving, by the BM-SC, the parameter TEID and QOS included in the received message after receiving the Session Start Response message sent by the GGSN in step (2), to indicate the success of establishing the bearer associating with the QOS between the GGSN and the BM-SC; (4) sending, by the GGSN, to a SGSN the MBMS Session Start message in which a plurality of QOS parameters are included after having sent the Session Start Response message in step (2); (5) selecting a supporting QOS and allocating TEID for this QOS after the SGSN receives the MBMS Session Start message sent by the GGSN in step (4), and sending to the GGSN the Session Start Response message in which the parameter TEID and QOS are included; (6) saving, by the GGSN, the parameter TEID and QOS included in the received message after receiving the MBMS Session Start Response message sent by the SGSN in step (5), to indicate the success of establishing the bearer associating with the QOS between the SGSN and the GGSN; (7) sending, by the SGSN, to RNCs a MBMS Session Start Notification message in which a plurality of QOS parameters are included after having sent the MBMS Session Start Response message in step (5); (8) selecting the supporting QOS and allocating TEH) for this QOS after the RNC receives the MBMS Session Start Notification message sent by the SGSN in step (7), and counting the number of UEs and allocating air-resources for the UEs according to the QOS; (9) sending to the SGSN the MBMS Session Start Notification message in which the QOS and TEED parameter selected by the RNC in step 8 are included after the RNC implements step (8); (10) saving, by the SGSN, the parameter TEID and QOS included in the received message after receiving the MBMS Session Start Notification Response message sent by the RNC in step (9), to indicate the success of establishing the bearer associating with the QOS between the RNC and the SGSN.

2. The method as claimed in Claim 1, further comprising the steps of: allocating, by the GGSN, a new TEID for itself and sending to the BM-SC another Session Start Response message including the parameters of TEED and QOS, if the QOS associated with the bearer established between the GGSN and the SGSN is not associated with any of the bearers between the GGSN and the BM-SC; saving the parameters of TEID and QOS that are included in the received message after the BM-SC receives the Session Start Response message from the GGSN, to indicate the success of establishing a new bearer associating with the QOS between the GGSN and the BM-SC.

3. The method as claimed in Claim 1, further comprising the steps of: allocating, by the SGSN, a new TEID for itself and sending to the GGSN another Session Start Response message including the parameters of TEID and QOS, if the QOS associated with the bearer established between the RNC and the SGSN is not associated with any of the bearers between the SGSN and the GGSN; saving the parameters of TEED and QOS that are included in the received message after the GGSN receives the Session Start Response message from the SGSN, to indicate the success of establishing a new bearer associating with the QOS between the SGSN and the GGSN.

4. The method as claimed in Claim 1, further comprising the steps of: allocating, by the GGSN, a new TEED for itself and sending to the BM-SC another Session Start Response message including the parameters of TEED and QOS, if the QOS associated with the bearer established between the SGSN and the GGSN is not associated with any of the bearers between the GGSN and the BM-SC; saving the parameters of TEID and QOS that are included in the received message after the BM-SC receives the Session Start Response message from the GGSN, to indicate the success of establishing a new bearer associating with the QOS between the GGSN and the BM-SC.

5. The method as claimed Claim 1, further comprising a step of initiating the process of QOS updating by the RNC: (1) sending, by the SGSN, to the RNC a MBMS Bearer Update Request message including the parameter TEED or the parameter QOS, wherein the QOS is the new one that RNC requires; (2) sending the MBMS Bearer Update Response message to the RNC after the SGSN receives the message sent by the RNC in step (1); (3) sending, by the SGSN, the MBMS Session Start Notification message to the RNC, wherein if the MBMS Bearer Update Request message sent by the RNC in step (1) includes the parameter of QOS, the MBMS Session Start Notification message includes the only QOS that the RNC requires, if the MBMS Bearer Update Request message sent by the RNC in step (1) does not include the parameter of QOS, the MBMS

Session Start Notification message includes a plurality of QOS parameters; (4) carrying out, by the RNC, the process of counting the number of UEs and the process of configuring air resources according to the QOS, if the MBMS Bearer Update Request message sent by the RNC in step (1) includes the parameter of QOS; otherwise, selecting a QOS from the MBMS Session Start Notification message sent by the SGSN in step (3) and carrying out the process of counting the number of UEs and the process of configuring air resources according to the selected QOS; (5) sending, by the RNC, to the SGSN the MBMS Session Start Notification message including the parameter TEID, wherein if the MBMS Bearer Update Request message sent by the RNC in step (1) includes the parameter of QOS, this MBMS

Session Start Notification message does not include the parameter QOS; otherwise, this message includes the parameter QOS that the RNC has selected.

6. The method as claimed in Claim 1, further comprising a step of initiating the process of QOS updating by the SGSN: (1) initiating the process of establishing a bearer that associates with a QOS by the SGSN; (2) initiating the process of removing a bearer that associates with a QOS by the SGSN.

7. The method as clamed in Claim 1, further comprising a step of initiating the process of QOS updating by the GGSN: (1) initiating the process of establishing a bearer that associates with a QOS by the GGSN; (2) initiating the process of removing a bearer that associates with a QOS by the GGSN.

8. The method as claimed in Claim 6, the step of initiating the process of establishing a bearer that associates with a QOS by the SGSN comprising the steps of: (1) sending, by the SGSN, to the GGSN the MBMS Bearer Establishment

Request message including the parameters of Service ID and QOS; (2) sending, by the GGSN, to the SGSN the MBMS Bearer Establishment Response message; (3) sending, by the GGSN, to the SGSN the MBMS Session Start message including the parameters of Service ID and QOS; (4) sending, by the SGSN, to the GGSN the MBMS Session Start Response message including the parameters of TEED and QOS.

9. The method as claimed in Claim 6, the step of initiating the process of establishing a bearer that associates with a QOS by the SGSN comprising the steps of: (1) sending, by the SGSN, to the GGSN the MBMS Bearer Establishment Request message including the parameters of Service ID, QOS and TEID; (2) sending, by the GGSN, to the SGSN the MBMS Bearer Establishment Response message.

10. The method as claimed in Claim 6, the step of initiating the process of removing a bearer that associates with a QOS by the SGSN comprising the steps of: (1) sending, by the SGSN, to the GGSN the MBMS Bearer Release Request message including the parameters of Service ED, TEED and NSAPI; (2) sending, by the GGSN, to the SGSN the MBMS Bearer Release Response message.

11. The method as claimed in Claim 7, the step of initiating the process of establishing a bearer that associates with a QOS by the GGSN comprising the steps of: (1) sending, by the GGSN, to the BM-SC the MBMS Bearer Establishment Request message including the parameters of Service ID and QOS; (2) sending, by the BM-SC, to the GGSN an MBMS Bearer Establishment

Response message; (3) sending, by the BM-SC, to the GGSN the MBMS Session Start message including the parameters of Service ID and QOS; (4) sending, by the GGSN, to the BM-SC the MBMS Session Start Response message including the parameters of TEED and QOS.

12. The method as claimed in Claim 7, the step of initiating the process of establishing a bearer that associates with a QOS by the GGSN comprising the steps of: (1) sending, by the GGSN, to the BM-SC the MBMS Bearer Establishment Request message including the parameters of Service ID, QOS and TEID; (2) sending, by the BM-SC, to the GGSN the MBMS Bearer Establishment Response message.

13. The method as claimed in Claim 7, the step of initiating the process of removing a bearer that associates with a QOS by the GGSN comprising the steps of: (1) sending, by the GGSN, to the BM-SC the MBMS Bearer Release Request message including the parameters of Service ID, TEID and NSAPI; (2) sending, by the BM-SC, to the GGSN the MBMS Bearer Release Response message.