CN100464530C - Method for notifying the start of a multimedia broadcast multicast session - Google Patents

Abstract

A process for notifying start of multimedia televise multicasting session comprises the following steps: a) according to the different types of RNC, parameters in messages sent to RNC by SGSN are different; b) RNC returns a message back to SGSN; or also comprise the steps: a) according to the different types of RNC, SGSN sends different messages to RNC; b) RNC returns a message back to SGSN. By increasing indication bit to messages, the present invention simplifies processing burden at RNC side, shortens the time for building Iu user plane caused by UE movement, and then ensures the minimization of data loss of users.

Description

Method for notifying the start of a multimedia broadcast multicast session

technical field

The invention relates to the third generation mobile communication system, in particular to a method for notifying a wireless unit controller of session start at a serving GPRS support node.

Background technique

MBMS is a new service for which relevant standards are being formulated in the third generation mobile communication system partnership project for standardization. The MBMS service is a one-way point-to-multipoint service (that is, multimedia data broadcast from a single data source is sent to multiple users for reception through network transmission). The biggest feature of this kind of business is that it can effectively utilize wireless resources and network resources. MBMS services are mainly used in wireless communication network systems, such as wideband code division multiple access communication systems and global mobile communication systems. The transmission of business data in MBMS basically goes through several processes: data source transmission, intermediate network transmission, destination cell air transmission, and user reception. Fig. 3 is a logical network equipment diagram of a wireless communication system capable of providing MBMS services. In this figure, MBMS actually utilizes a General Packet Radio Service (hereinafter referred to as GPRS) network as a core transmission network. As shown in Figure 3, the broadcast and multicast service center (hereinafter referred to as BM-SC) is the data source for sending MBMS service data; the gateway GPRS support node (hereinafter referred to as GGSN) is used for the communication between the GRPS network and the external network (such as the Internet network) Connection; in the MBMS business, the gateway GPRS support node connects to BM-SC and sends MBMS data to a specific serving GPRS support node (hereinafter referred to as SGSN); the cell broadcast center is the data source of the cell broadcast, and in MBMS, the cell broadcast center Interconnected with BM-SC, so that the cell broadcast center can provide MBMS service announcement function; SGSN is used for UE access control and mobility management, and at the same time sends MBMS data from GGSN to a specific radio unit controller (hereinafter referred to as RNC) ); RNC is used to control a group of base stations and transmit multimedia data to a specific base station; the base station establishes an air physical channel for the MBMS service of a certain cell under the control of RNC; user terminal equipment (hereinafter referred to as UE) is Terminal equipment that receives MBMS data.

Figure 4 shows the entire process of the MBMS service from service announcement, user joining, service notification, radio bearer establishment to the final user leaving.

401 Subscription establishes the connection between the user and the service provider, and the authorized user can receive related MBMS services.

402 Service announcement notifies the user of the MBMS service to be provided. For example, the system wants to broadcast a football match in downtown Beijing at 7:00 pm.

403 Join means that the user joins a group, that is, the user tells the network that he or she is willing to receive this multicast service.

404 MBMS session start indicates establishment of network resources for MBMS data transmission.

405 The MBMS notification informs the user of the upcoming MBMS data transmission.

406 Data transmission indicates the process of transmitting MBMS service data to the user.

407 The end of the MBMS session indicates that the network resources are released after the transmission of the MBMS service data is completed.

408 Leaving is corresponding to 403 Joining, indicating that the user wants to leave a group, that is, no longer wants to receive data of a certain service.

In the existing MBMS system, when an MBMS session starts, the SGSN should notify the RNC of the start of the session, the service quality parameters related to the MBMS service, and the multicast service area. Figure 2 describes how the SGSN notifies the RNC of the session start. In the prior art, there are three types of RNCs below the SGSN: one is the RNC in the last known routing area (RA), and the cell under the control of the RNC contains user equipment in an idle state (PMM_IDLE); the other is the serving radio unit The controller (SRNC), the cell under the control of the RNC includes the user equipment in the connected state (PMM_CONNECTED), and the RNC is the SRNC of the UE; the third is the floating radio unit controller (DRNC), the cell under the control of the RNC includes the user equipment in the User equipment in the connected state (PMM_CONNECTED), but the RNC is not the SRNC of the UE, but the DRNC of the UE. For user equipments in the PMM_IDLE state, because the SGSN knows the routing area (RA) where the user equipment is located, the SGSN knows the RNC where these UEs are located according to the mapping relationship between the routing area and the RNC. These RNCs send session start indication messages, such as 205 among Fig. 2 (we assume that PMM_IDLE UE is included in RNC#2 wherein), and this message includes service identifier, the corresponding QoS parameter of this service, multicast service area. For the user equipment in the PMM_CONNECTED state, due to the mobility of the user equipment, the SGSN only knows the SRNC of the UE, but not the DRNC of the UE. In other words, DRNC is shielded from SGSN. Therefore the SGSN can only send the session start instruction message to the SRNC where the UE is located, as shown in 205 in Figure 2 (we assume that RNC#2 is the SRNC of some user equipment), and the message includes a service identifier, the service quality corresponding to the service Parameter, multicast service area. If some UEs move to a cell controlled by the DRNC, RNC#1 in Figure 2 belongs to the DRNC of some UEs. Since the SGSN does not know the existence of this type of RNC, it is impossible for the SGSN to send a session start instruction to the RNC. There are two methods in the prior art to make the SGSN aware of the existence of such RNCs, so as to notify these RNCs of the start of the session: the first one, as shown in 201 in Figure 2, when the first UE that activates the MBMS service moves to the RNC, the The RNC knows the ID of the MBMS service activated by the UE, and if the RNC has not established the context for the service, establish it. Then the RNC sends a "MBMS RNC Registration Request" message to the SGSN. After receiving the message, the SGSN shall store the identity of the RNC in its bearer context, so that the RNC may be notified when the session starts. After the session starts, the SGSN checks the RNC identifier contained in its context, sends 207 to the RNC, and notifies the RNC that the session starts, and the message includes the service identifier, the corresponding QoS parameter of the service, and the multicast service area; In 206 in FIG. 2, after the session starts, the SRNC of the UE will first receive the "MBMS Session Start Indication" message sent from the SGSN. The SRNC sends a 203 "MBMS Attach Request" message to the DRNC where the UE is located, that is, RNC#1, to inform the DRNC of the service identifiers that these UEs have joined and the session has started. The DRNC returns the "MBMS Attach Response" message to the SRNC, if the DRNC has not established the context for this service, then establish it. Then the DRNC sends a "MBMS RNC Registration Request" message to the SGSN. After the SGSN receives this message, it will save the identifier of the RNC in its bearer context. In this case, the session has already started, so the SGSN sends 207 to the RNC to notify the RNC that the session starts. The message contains the service identifier. QoS parameters corresponding to this service, multicast service area.

From the description in Figure 2, we can see that no matter which of the three RNCs, the session start indication message sent by the SGSN to the RNC is the same, and the parameters carried are also the same, that is, the SGSN is different Distinguish these three kinds of RNC. For the RNC in the last known routing area, the location of the UE is at the routing area level for the SGSN. One RA may contain one or more RNCs, and one RNC may also contain multiple RAs. One RA corresponds to multiple cells. When the session starts, it is necessary to ensure that all user equipments know that the session starts, so that the UE knows to listen to the multicast control channel (MCCH), especially for the user equipments in the PMM_IDLE state, only the SGSN notifies the RNC of the routes where these UEs are located In this way, the RNC can accurately send MBMS notifications to the cells included in the RA, so that the UE knows that the session has started. It can be seen that, for the "session start indication" message sent to this type of RNC, the location information of the UE should also be included. For SRNC and DRNC, since the location of the controlled UE is visible at the cell level, the SRNC can decide which cells to send MBMS notifications to, and the SGSN does not need to specify the location of the UE. It can be seen that, for these two types of RNCs, the "session start indication" sent to them by the SGSN does not need to contain information about the location of the UE. The prior art does not distinguish these three different RNCs, which means that after receiving the "session start indication" message, the RNC either sends MBMS notifications to the entire area where the RNCs are located, or does not send them at all. This unified processing solution will either increase the signaling bearer on the air interface, or cause some users not to receive MBMS notifications, so it is necessary to improve the existing technology. In addition, if some RNCs in an RA have user equipments, it is very likely that these user equipments will move from these RNCs to other RNCs in the same RA. Therefore, we can also save the session parameters in the business of these RNCs In this context, the user plane between RNC and SGSN can also be established for later use.

In addition, if an SGSN contains at least one UE's MBMS context, since the UE may move within the control range of the SGSN, the session start can be sent to all RNCs controlled by the SGSN.

Since the SGSN keeps the Mobility Management (MM) context for each user equipment, the SGSN knows how many UEs are within its control range. If the SGSN can inform the RNC of the number of users in advance, if the number of users is relatively small, then the RNC can directly determine the point-to-point or point-to-multipoint channel type.

Contents of the invention

The present invention aims to solve the problem that different RNCs perform different operations according to different messages or different information contents contained in the same message after learning that the session start is received.

In order to achieve the above object, a method for notifying the start of a multimedia broadcast multicast session comprises steps:

The serving general radio packet service GPRS support node SGSN sends a "session start indication" message to the radio network controller RNC, and the message includes a "notification area";

The radio network controller RNC sends an MBMS notification in the cells included in the "notification area";

The radio network controller RNC returns a "session start confirmation" message to the SGSN.

The present invention simplifies the processing burden on the RNC side by adding indication information in the message, and shortens the time for establishing the Iu user plane caused by UE movement, thereby ensuring the minimization of user data loss.

Description of drawings

Fig. 1 is the flowchart of using the same message to notify different RNC sessions to start;

Fig. 2 is the flow chart of notifying RNC session start in the prior art;

FIG. 3 is a schematic structural diagram of the MBMS system;

Fig. 4 is the MBMS multicast service process;

Fig. 5 is the flowchart of using different messages to notify different RNC sessions to start;

Fig. 6 is the topology used in the example;

Fig. 7 is the node action of RNC when using the same message;

Figure 8 is the node action of SGSN when using the same message;

Fig. 9 is the node action of RNC when using different messages;

Figure 10 is the node action of SGSN when different messages are used.

Detailed ways

Hereinafter, examples of the present invention will be described in detail with reference to the accompanying drawings. Only the parts necessary for understanding the description will be described below, and other parts will be omitted in order to highlight the key points.

Figure 1 describes the process of using the same message to notify different RNCs of session start.

The plot described in Figure 1 is carried out according to the relationship between each RNC in Figure 6. According to Figure 6, RNC1 and RNC6 are included in RA1, RNC4 is included in RA2, RNC5 is included in RA3, RNC2 and RNC2 are included in RA4 RNC3.

Before the session starts, RNC4 is the SRNC of some user equipments, and RNC5 is the DRNC of some user equipments, and RNC1 contains user equipments that activate MBMS services and are in PMM_IDLE state. According to the prior art, the DRNC may register with the SGSN before the session starts.

101 in the above-mentioned figure 1, DRNC sends " MBMS RNC registration request " message to SGSN, and the message includes service identification list, and after SGSN receives this message, will add this RNC in the list of downstream nodes in its bearer context. For the bearer context of the SGSN, please refer to the prior art. The composition of the downstream node list will be described in detail later.

At 102 in FIG. 1, the SGSN receives the "MBMS session start" message sent by the GGSN, and includes the service identifier, service quality parameter, and multicast service area contained in the message in the bearer context of the service. The SGSN sends a message to the RNC contained in the downstream node list in its bearer context, notifying the RNC that the MBMS service session starts.

At 103 in FIG. 1, the SGSN sends a "session start indication" message to RNC4, which includes parameters such as service identifier, service quality parameter, multicast service area, and tunnel identifier. Since RNC4 is the SRNC of some UEs, this RNC has the possibility to provide these UEs with point-to-point or point-to-multipoint services. Therefore, the message can also include the tunnel identifier between the SGSN side RNC and the SGSN. to transmit data.

At 104 in FIG. 1 above, the SRNC returns a "session start confirmation" message to the SGSN, which includes "future use indication", parameters about the establishment of the user plane on the RNC side, such as the tunnel identifier. If the SRNC is to provide point-to-multipoint channels to cells under its control or to provide point-to-point channels to user equipment with RRC connections with it, then the "future use indication" can be set to No, indicating that after receiving the message, the SGSN will Data can be transferred. Otherwise, if the SRNC neither needs to provide point-to-multipoint channels to the cells under its control, nor needs to provide point-to-point channels to user equipment with RRC connections with it, then the "future use indication" is set to true, indicating that the SGSN has received After this message, there is no need to transmit data, but the user plane tunnel identifier for this service needs to be saved, and the data transmission of this user plane can be resumed later.

In step 105 in FIG. 1, the SGSN sends a "session start indication" message to RNC1, which includes parameters such as service identifier, service quality parameter, multicast service area, notification area, and tunnel identifier. After receiving the message, the RNC maps the notification area into a cell identifier, sends an "MBMS notification" message to the cell under its control, and notifies the UE in the PMM_IDLE state that the service has started. The message may also include the number of users, so that the RNC can directly decide to use the point-to-point channel when the number of users is relatively small. The RNC judges whether the cell under its control contains user equipment, and if it does, it indicates that the user plane is required for data transmission, and the "future use indication" is set to No, otherwise the user plane is not required, and the "future use indication" is set to true. However, regardless of whether there is user equipment in the cell under its control, the user plane can be established at this time, and the RNC returns 106 "session start confirmation" message to the SGSN, which includes future use instructions and parameters about the establishment of the user plane on the RNC side, Such as tunnel ID.

In step 107 in FIG. 1, the SRNC sends a "MBMS Attach Request" message to the DRNC. The message includes a service identifier, a list of UE identifiers, a list of cells, and a list of URAs. In this way, the DRNC can know which cells or URAs it controls contain user equipment in the PMM_CONNECTED state. If the DRNC does not receive the "session start indication" message from the SGSN, it is possible that the RNC is neither the SRNC of any user equipment in connected mode, nor does the RA it belongs to include any user in PMM_IDLE who has activated the MBMS service equipment, and other RNCs (if any) to which the RA belongs have not registered with the SGSN. Then the DRNC registers with the SGSN, and sends 109 a "MBMS RNC Registration Request" message, which includes a "service identifier".

110 in the above-mentioned figure 1, the SGSN will add the RNC to the MBMS bearer context of the service, and then send a "session start indication" message to the RNC5, which includes the service identifier, service quality parameter, multicast service area, and tunnel identifier and other parameters. If the DRNC is to provide point-to-multipoint channels to the cells under its control, then the "indication for future use" can be set to No, indicating that the SGSN can transmit data after receiving the message. Otherwise, if the DRNC does not need to provide point-to-multipoint channels to the cells under its control, then the "future use indication" is set to true, indicating that after the SGSN receives the message, it does not need to transmit data, but it needs to save the The user plane tunnel ID for .

In step 111 in FIG. 1 above, DRNC returns a "session start confirmation" message to SGSN, which contains future use instructions, parameters about user plane establishment on the RNC side, such as tunnel ID.

112 in the above-mentioned figure 1, it is assumed that when a UE moves from a cell under RNC4 under SRNC to a cell controlled by RNC2 under DRNC, SRNC sends an "MBMS Attach Request" message to DRNC, and the message includes service identifier, user equipment identifier and cell identifier .

At step 113 in FIG. 1, the DRNC returns an "MBMS Attach Response message" to the SRNC.

114 in the above-mentioned Fig. 1 represents the first UE activating the MBMS service under the RNC2, so now RNC2 will establish the MBMS service context, and then send 115 "MBMS RNC registration request" message to SGSN, which contains "service logo".

116 in the above Figure 1, the SGSN will add the RNC to the downstream node list in the MBMS bearer context of the service, and then send a "session start indication" message to RNC2, which includes the service identifier, service quality parameter, multicast service area , tunnel ID and other parameters. Since it is the first UE, DRNC does not need to provide point-to-multipoint channels to the cells under its control, then the "future use indication" is set to true, indicating that after the SGSN receives the message, it does not need to transmit data, but it needs to save User plane tunnel identifier for this service.

In step 117 in FIG. 1, the DRNC returns a "session start confirmation" message to the SGSN, which contains "future use indication", parameters about the establishment of the user plane on the RNC side, such as the tunnel identifier. Since RNC2 and RNC3 are both in RA4, a "session start indication" message is also sent to RNC3, but since the RNC does not contain any UE, the service parameters are sent to the RNC only to better support the mobility of the user equipment, Therefore, an information element is added to the message at step 118: notification indication. This information element indicates that the RNC does not need to perform the process of counting the number of users in its area. The RNC also does not need to use the user to transmit data, so "Future Use Indication" is set to true. When the system decides to send session start to all RNCs under the control of the same SGSN, the processing method of RNC3 is the same as now.

In step 119 in FIG. 1 , the RNC returns a "session start confirmation" message to the SGSN, which contains future use instructions, parameters about the establishment of the user plane on the RNC side, such as the tunnel ID.

When a user equipment newly joins the service in the cell controlled by RNC2 or an idle user moves to the cell controlled by RNC2, the SGSN sends 120 "MBMS UE connection request" to RNC2, and the message contains the MBMS service ID that the UE joined list. RNC2 sends 121 "MBMS UE Connection Response" to SGSN.

At 122 in FIG. 1 above, the RNC2 judges whether the service subscribed by the UE has not established a context, and if so, establishes it. The SGSN adds the RNC to the MBMS bearer context of the service, and then sends 123 a "session start indication" message to RNC2, which includes parameters such as service identifier, service quality parameter, multicast service area, and tunnel identifier. Since it is the first UE, RNC2 needs to provide point-to-point channels to the cells under its control, then the "future use indication" is set to No, indicating that the SGSN needs to transmit data after receiving the message.

In step 124 in FIG. 1 , the DRNC returns a "session start confirmation" message to the SGSN, which contains future use instructions, parameters about user plane establishment on the RNC side, such as tunnel identifiers. Since RNC2 and RNC3 are both in RA4, a 125 "Session Start Indication" message is also sent to RNC3, but since the RNC does not contain any UE, the service parameters are sent to the RNC only to better support the mobility of the user equipment , so an information element is added to the message at 125: notification indication. This information element indicates whether the RNC needs to perform the process of counting the number of users in its area. If this information element is included in the message, it does not need to count the number of users, otherwise it counts the number of users. The RNC also does not need to transmit data for the user, so "future use indication" is set to true. When the system decides to send session start to all RNCs under the control of the same SGSN, the processing method of RNC3 is the same as now.

At 126 in FIG. 1 , the RNC returns a "session start confirmation" message to the SGSN, which includes future use indications, parameters about the establishment of the user plane on the RNC side, such as tunnel identifiers.

If there are other RNCs in the same RA as RNC4 or RNC5, then when the service starts, the SGSN also sends a "session start indication" to these RNCs. The content of the message is the same as that in 125, and then the content of the message returned by the RNC is also the same as in 126. When the system decides to send a session start to all RNCs under the control of the same SGSN, these RNCs are handled in the same way as now.

FIG. 5 describes the process of notifying different RNCs of session start using different messages.

The plot described in Figure 5 is carried out according to the relationship between the RNCs in Figure 6. According to Figure 6, RNC1 and RNC6 are included in RA1, RNC4 is included in RA2, RNC5 is included in RA3, RNC2 and RNC2 are included in RA4 RNC3.

Before the session starts, RNC4 is the SRNC of some user equipments, and RNC5 is the DRNC of some user equipments, and RNC1 contains user equipments that activate MBMS services and are in PMM_IDLE state. According to the prior art, the DRNC may register with the SGSN before the session starts.

501 in the above-mentioned figure 5, DRNC sends " MBMS RNC registration request " message to SGSN, and the message includes service identification list, after SGSN receives this message, will add this RNC in the downstream node list in its bearer context.

At 502 in FIG. 5 above, the SGSN receives the "MBMS session start" message sent by the GGSN, and includes the service identifier, service quality parameter, and multicast service area included in the message in the bearer context of the service. The SGSN sends a message to the relevant RNC in the downstream node list of its bearer context to notify the RNC that the MBMS service session starts.

503 among the above-mentioned Fig. 5, SGSN sends " MBMS RAB distribution request " message to RNC4, comprises service identification, service quality parameter, multicast service area, parameters such as tunnel identification. Since RNC4 is the SRNC of certain UEs, this RNC has the possibility to provide these UEs with point-to-point or point-to-multipoint services, so this message also includes the user plane tunnel between the RNC and SGSN allocated by the SGSN side Identifier, used to transmit data.

504 in the above-mentioned Fig. 5, SRNC returns " MBMS RAB allocation response " message to SGSN, and this message includes future use instruction, the parameter about user plane establishment of RNC side, as tunnel identifier. If the SRNC is to provide point-to-multipoint channels to cells under its control or to provide point-to-point channels to user equipment with RRC connections with it, then the "future use indication" can be set to No, indicating that after receiving the message, the SGSN will Data can be transferred. Otherwise, if the SRNC neither needs to provide point-to-multipoint channels to the cells under its control, nor needs to provide point-to-point channels to user equipment with RRC connections with it, then the "future use indication" is set to true, indicating that the SGSN has received After this message, there is no need to transmit data, but the user plane tunnel identifier for this service needs to be saved.

505 in the above-mentioned Fig. 5, SGSN sends " MBMS RAB distribution request " message to RNC1, comprises service identification, service quality parameter, multicast service area, parameters such as notification area and tunnel identification. After the RNC receives the message, it judges whether the cell under its control contains user equipment. If it does, it indicates that the user plane is required for data transmission, and the "future use indication" is set to No, otherwise the user plane is not required, and the "future use indication" set to true. However, regardless of whether there is user equipment in the cell under its control, the user plane can be established, and the RNC returns a 506 "MBMSRAB Assignment Response" message to the SGSN. logo. The message may also include the number of users, so that the RNC can directly decide to use the point-to-point channel when the number of users is relatively small.

In step 507 in FIG. 5, the SRNC sends a "MBMS Attach Request" message to the DRNC, and the message includes a service identifier, a list of UE identifiers, a list of cells, and a list of URAs. In this way, the DRNC can know which cells or URAs it controls contain user equipment in the PMM_CONNECTED state. If the DRNC does not receive the "session start indication" message from the SGSN, it is possible that the RNC is neither the SRNC of any user equipment in connected mode, nor does the RA it belongs to include any user in PMM_IDLE who has activated the MBMS service equipment, and other RNCs (if any) to which the RA belongs have not registered with the SGSN. Then DRNC registers with SGSN and sends 509 "MBMS

RNC registration request" message, which contains the "service identifier".

At 510 in Figure 5 above, the SGSN will add the RNC to the MBMS bearer context of the service, and then send the "MBMS RAB Assignment Request" message to the RNC5, which includes the service identifier, service quality parameters, multicast service area, tunnel ID and other parameters. If the DRNC is to provide point-to-multipoint channels to the cells under its control, then the "indication for future use" can be set to No, indicating that the SGSN can transmit data after receiving the message. Otherwise, if the DRNC does not need to provide point-to-multipoint channels to the cells under its control, then the "future use indication" is set to true, indicating that after the SGSN receives the message, it does not need to transmit data, but it needs to save the The user plane tunnel ID for .

511 in the above-mentioned Fig. 5, DRNC returns " MBMS RAB allocation response " message to SGSN, and this message includes future use indication, the parameter about user plane establishment of RNC side, as tunnel identifier.

512 in the above-mentioned figure 5, it is assumed that when a UE moves from a cell under RNC4 under SRNC to a cell controlled by RNC2 under DRNC, SRNC sends a "MBMS Attach Request" message to DRNC, and the message includes service identifier, user equipment identifier and cell identifier .

In step 513 in FIG. 5, the DRNC returns an "MBMS Attach Response message" to the SRNC.

514 in the above-mentioned figure 5 indicates that if the UE is the UE that activates the MBMS service for the first UE, then RNC2 will establish a service context at this time, and then send a 515 "MBMS RNC Registration Request" message to the SGSN, which includes " Business ID".

516 in the above-mentioned figure 5, the SGSN will add the RNC to the downstream node list of the MBMS bearer context of the service, and then send the "MBMS RAB allocation request" message to the RNC5, which includes the service identifier, service quality parameter, multicast Parameters such as service area and tunnel ID. Since it is the first UE, DRNC does not need to provide point-to-multipoint channels to the cells under its control, then the "future use indication" is set to true, indicating that after the SGSN receives the message, it does not need to transmit data, but it needs to save User plane tunnel identifier for this service.

517 in the above-mentioned Fig. 5, DRNC returns " MBMS RAB allocation response " message to SGSN, and this message includes future use indication, the parameter that RNC side is about user plane establishment, as tunnel identifier. Since RNC2 and RNC3 are both in RA4, they need to send a "session start indication" message to RNC3, but since this RNC does not contain any UE, sending service parameters to this RNC is only for better supporting the mobility of user equipment. This message indicates that the RNC does not need to perform the process of counting the number of users in its area. The RNC also does not need to use the user to transmit data, so "Future Use Indication" is set to true. When the system decides to send session start to all RNCs under the control of the same SGSN, the processing method of RNC3 is the same as now.

In step 519 in FIG. 5 , the RNC returns a "session start confirmation" message to the SGSN, which contains future use instructions, parameters about the establishment of the user plane on the RNC side, such as the tunnel ID.

In the above Figure 5, when a user equipment newly joins the service in the cell controlled by RNC2 or a user in an idle state moves to the cell controlled by RNC2, the SGSN sends 520 "MBMS UE connection request" to RNC2, and the message includes UE List of MBMS service identifiers to be added. RNC2 sends 521 "MBMS UE Connection Response" to SGSN.

In step 522 in FIG. 5 above, RNC2 judges whether the service subscribed by the UE has not established a context, and if so, establishes it. SGSN adds this RNC to the MBMS bearer context of this service, and then sends 523 "MBMS RAB allocation request" message to RNC2, which includes parameters such as service identifier, service quality parameter, multicast service area, and tunnel identifier. Since it is the first UE, RNC2 needs to provide point-to-point channels to the cells under its control, then the "future use indication" is set to No, indicating that the SGSN needs to transmit data after receiving the message.

524 in the above-mentioned Fig. 5, DRNC returns " MBMS RAB distribution response " message to SGSN, and this message includes future use indication, the parameter about user plane establishment of RNC side, as tunnel identifier. Since RNC2 and RNC3 are both in RA4, they need to send 525 "Session Start Indication" message to RNC3, but since this RNC does not contain any UE, the service parameters are sent to this RNC only to better support the mobility of user equipment. This message indicates whether the RNC needs to perform the process of counting the number of users in its area. If this information element is true, it does not need to count the number of users, otherwise it counts the number of users. The RNC also does not need to transmit data for the user, so "future use indication" is set to true. When the system decides to send session start to all RNCs under the control of the same SGSN, the processing method of RNC3 is the same as now.

At 526 in FIG. 5 above, the RNC returns a "session start confirmation" message to the SGSN, which contains future use indications, parameters related to the establishment of the user plane on the RNC side, such as tunnel identifiers.

If there are other RNCs in the same RA as RNC4 or RNC5, then when the service starts, the SGSN also sends a "session start indication" to these RNCs. The content of the message is the same as that in 525, and then the content of the message returned by the RNC is also the same as in 526. When the system decides to send a session start to all RNCs under the control of the same SGSN, these RNCs are handled in the same way as now.

The formation method of the downstream node list of the MBMS service bearer context in the SGSN: the SGSN saves the MBMS service identifier subscribed to for each UE it serves. SGSN knows which UEs have subscribed to those MBMS services. After the UE subscribes to the MBMS service, if the UE is in the PMM_IDLE state, the SGSN adds the RNC contained in the RA where the UE is located to the downstream node list of the bearer context corresponding to all the services subscribed by the UE. If the UE is in the PMM_CONNECTED state, the SGSN adds the RNC included in the SRNC where the UE is located to the list of downstream nodes that the UE subscribes to the bearer context corresponding to all services. If the DRNC where the UE is located registers with the SGSN, the SGSN will also add the RNC to the list of downstream nodes that the UE subscribes to the bearer context corresponding to all services. At the same time, the SGSN will also add all other RNCs in the same RA as any SRNC and the registered DRNC to the downstream node list of the bearer context of the corresponding service. This process can be performed before the session starts, that is, when the UE joins any MBMS service, or it can be performed when the session starts.

In order to distinguish these four different RNCs, SGSN can add an identifier in its bearer context: RNC type identifier, which is used to distinguish different types of RNCs, so as to decide to send different "session start indication" messages or send different message types" MBMS RAB allocation request" or "session start indication" message.

Table 1: SGSN bearer context content

parameter describe IP multicast address business logo APNs business logo service quality Provide the quality of service required by the MBMS service Multicast service area Areas where MBMS services should be distributed list of downstream nodes The RNC that needs to notify the start of the session, the RNC that may have established the user plane RNC status type In the RNC of the last known routing area (RA), the cells under the control of the RNC include user equipment in the idle state (PMM_IDLE); the Serving Radio Unit Controller (SRNC), the cells under the control of the RNC include the user equipment in the connected state ( PMM_CONNECTED), and the RNC is the SRNC of the UE; the floating radio unit controller (DRNC), the cell under the control of the RNC includes the user equipment in the connected state (PMM_CONNECTED), but the RNC is not the SRNC of the UE, but UE's DRNC. Other RNCs belonging to the same RA as some SRNCs or registered DRNCs

Example

1) Node processing flow of RNC

Figure 7 describes the node processing flow of the RNC when using the same message.

In stage 701, the RNC receives a message from the SGSN.

The 702 stage judges whether the message received from the SGSN is a "session start instruction", if so, then turns to 703, otherwise turns to 701. In the 703 stage, the RNC saves the QoS parameter specified by the SGSN in its service context, the multicast service area, Tunnel identifier on the SGSN side, and establish the Iu user plane between RNC and SGSN, distribute the tunnel identifier on the RNC side, and turn to 704. In the 704 stage, the RNC checks whether the message includes a "notification indication", and if so, turns to 705, otherwise Turn to 706. In the 705 stage, the RNC decides not to send MBMS notifications to the cells under it, that is, it does not count the number of users. In the RNC stage, the user plane is reserved for future use, and the "future use indication" is set to true, and turns to 709. In the 706 stage, the RNC checks Whether the message contains "notification area", if so, turn to 707, otherwise turn to 708. In 707 stage, RNC will map the area into cells according to the configuration, send MBMS notification in each cell, and count the number of users in the cell. RNC can decide whether to use the Iu user plane to carry out data transmission immediately according to whether there is a user in the cell ("instruction for future use" is no), or leave it for later use ("instruction for future use" is true), and then turn to 709. The 708 stage, If the RNC is an SRNC, it will judge whether to provide point-to-multipoint transmission mode for the cell under its control, or to establish a point-to-point channel for the UE with RRC connection with it, if it is set to "future use indication" to no, if both If not, set "Future Use Indication" to true. If RNC is DRNC, then judge whether to provide point-to-multipoint transmission mode for the sub-district under its control, if set " future use instruction " as no, otherwise set to true, turn to 709. In 709 stage, RNC sends " session to SGSN Start confirmation" message, which includes parameters about the user plane such as the tunnel ID on the RNC side, future use instructions, and so on.

Figure 9 describes the node processing flow of the RNC when different messages are used.

In stage 901, the RNC receives a message from the SGSN.

The 902 stage judges whether the message received from the SGSN is "MBMS RAB allocation request", if so, then turns to 903, otherwise turns to 908. In the 903 stage, the RNC stores the QoS parameters specified by the SGSN in its service context, and the multicast service area , the tunnel ID on the SGSN side, and establish the Iu user plane, distribute the tunnel ID on the RNC side, and turn to 904. In the 904 stage, the RNC checks whether the message contains a "notification area", and if so, then turns to 905, otherwise turns to 906. 905 In the stage, the RNC will map the area into cells according to the configuration, send MBMS notifications in each cell, and count the number of users in the cell. RNC can decide whether to use the Iu user plane to carry out data transmission immediately according to whether there is a user in the cell ("use indication in the future" is no), or leave it for later use ("use indication in the future" is true), and then turn to 906. The 906 stage, If the RNC is an SRNC, it judges whether to provide a point-to-multipoint transmission mode for the cells under its control, or to establish a point-to-point channel for the UE with an RRC connection with it, if so, set the "future use indication" to no, otherwise if both If both are false, set "Future Use Indication" to true. If the RNC is a DRNC, then judge whether to provide point-to-multipoint transmission mode for the sub-district under its control, if so, set the "indication for future use" to be no, otherwise set it to true, and turn to 907. In the 907 stage, the RNC sends "" to the SGSN" MBMS RAB Assignment Response" message, which includes parameters about the user plane such as the tunnel ID on the RNC side, future use instructions, and so on.

2) Node processing of SGSN

Figure 8 describes the node processing flow of SGSN when using the same message.

In stage 801, the SGSN receives a message from the GGSN or the RNC.

The 802 stage judges whether the message is the "MBMS session start" sent by the GGSN, if so, turns to 803, otherwise turns to 810. The SGSN checks the RNC type in its bearer context in the 803 stage, and turns to 804. If the 804 stage judges that the RNC belongs to the PMM_IDLE UE RA, then turn to 805, otherwise turn to 806. At stage 805, the SGSN will include a "notification area" in the "session start indication" message, this area is the RA that contains the PMM_IDLE UE, and the RA will contain the RNC or the RNC contains multiple Such a RA, so the notification area can be one or more RAs, or the entire RNC, and then turn to 809. The 806 stage judges whether the RNC is an SRNC or a registered DRNC, if so, turn to 809, otherwise turn to 807. 807 stage Judging whether the RNC belongs to the same RA with the SRNC or registered DRNC, if so, then turn to 808, otherwise turn to 801. In the 808 stage, the SGSN will include a "notification indication" in the "session start indication" message, which indicates that the RNC does not Need to count the number of users, turn to 809. In the 809 stage, the SGSN sends a "session start indication" message to the RNC. In addition to the possible notification area and notification indication, the message also needs to include the quality of service parameters of the service. The tunnel on the SGSN side logo and so on.

In 810 stage, judge whether the message received by SGSN is "MBMS RNC registration request", if so, turn to 811, otherwise turn to 813. In 811 stage, SGSN adds this RNC and other RNCs in the same RA with this RNC to the service In the bearer context, go to 812. In the 812 stage, judge whether the service is in progress, if so go to 803, otherwise go to 801.

In stage 813, it is judged whether there is a new RNC that needs to be added to the bearer context. The RNC either has a UE in a cell under its control to join the service, or has an idle UE moving to a cell under the RNC's control to become an SRNC. Turn to 814. In the 814 stage, the SGSN adds the RNC and other RNCs in the same RA as the RNC to the bearer context of the service, and turns to 812.

Figure 10 describes the node processing flow of SGSN when different messages are used.

In stage 1001, the SGSN receives a message from the GGSN or the RNC.

The 1002 stage judges whether the message is the "MBMS session start" sent by the GGSN, and if so, turns to 1003, otherwise turns to 1011. The SGSN checks the RNC type in its bearer context in the 1003 stage, and turns to 1004. If the 1004 stage judges that the RNC belongs to the PMM_IDLE UE RA, then turn to 1005, otherwise turn to 1006. At 1005, the SGSN should include a "notification area" in the "session start indication" message. Such a RA, so the notification area can be one or more RAs, or the entire RNC, and then turn to 1007. The 1006 stage judges whether the RNC is an SRNC or a registered DRNC, if so, turn to 1007, otherwise turn to 1008. 1007 stage , the SGSN sends the "MBMS RAB Assignment Request" message to the RNC. In addition to the possible notification area, the message also needs to include the quality of service parameters of the service, the tunnel identifier on the SGSN side, and so on. In the 1008 stage, it is judged whether the RNC belongs to the same RA as the SRNC or the registered DRNC. If so, it turns to 1009; Quality parameters, tunnel ID on the SGSN side, etc.

In the 1010 stage, it is judged whether the message received by the SGSN is "MBMS RNC registration request", if so, it turns to 1011, otherwise it turns to 1013. In the 1011 stage, the SGSN adds the RNC and other RNCs in the same RA as the RNC to the service In the bearer context, go to 1012. In the 1012 stage, judge whether the service is in progress, if so go to 1003, otherwise go to 1001.

In stage 1013, it is judged whether there is a new RNC that needs to be added to the bearer context. The RNC either has a UE in a cell under its control to join the service, or has an idle UE moving to a cell under the RNC's control to become an SRNC. Go to 1014. In the 1014 stage, the SGSN adds the RNC and other RNCs in the same RA as the RNC to the bearer context of the service, and goes to 1012.

Claims (2)

1. method of notifying the multimedia broadcasting and multicast session to begin comprises step:

Service general grouping service wireless GPRS Support Node SGSN sends " session begins indication " message and gives radio network controller (RNC), and this message comprises " notification area ";

Radio network controller (RNC) sends the MBMS notice in the sub-district that described " notification area " comprises;

Radio network controller (RNC) returns " session begins to confirm " message to SGSN.

2. method according to claim 1 is characterized in that described " notification area " is one or more Routing Area RA.

Images