JP2012182587A - Mobile communication system, base station device, mme and mobile station device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a mobile communication system or the like in which network resources can be utilized effectively by determining a control method of allocating the network resources efficiently by the counting function of a base station device.SOLUTION: In the MBMS bearer service, information of the MBMS bearer that allocates and establishes the MBMS bearer resources is contained in an MBMS bearer context. A base station device (eNB) transmits a confirmation message containing a service identifier to a mobile station device (UE), counts the number of mobile station devices (UE) that are participating in the delivery of multicast data based on the response from the mobile station device (UE), and transmits the MBMS unsubscription request of multicast data to the MME if the count is 0.

Description

  The present invention relates to a mobile communication system that performs multicast data distribution from a BM-SC by a mobile station device connected to a base station device via an MBMS GW and an MME in which an MBMS bearer is established.

  In 3GPP, MBMS (Multimedia Broadcast / Multicast Service) is standardized as a method for providing an MBMS bearer service that performs multicast data distribution and broadcast data distribution by Evolved Packet Core (EPS).

  For example, according to Non-Patent Document 1, an MBMS service area is defined as a range in which an MBMS session is performed. For example, a service area is set in units of regions such as nationwide and Kanto, and is configured by cells of a plurality of base station devices in the service area. Then, a multicast distribution route is set in a radio access network such as UTRAN connected to the core network, and the base station device (eNodeB) and the radio network control station (RNC) of each cell in the service area are connected to a terminal (UE) An MBMS bearer is set in and the data is distributed.

  Here, in order to start the MBMS service, first, MBMS registration must be performed. MBMS registration is the creation of a distribution list that describes a delivery destination device in a data delivery device.

  In MBMS registration, a distribution list is created by a device in a radio access network such as URTRAN or a device in a core network. Thus, after performing MBMS registration, the mobile station device can receive data from the delivery source device via a plurality of devices by starting an MBMS session.

  Such conventional multicast data distribution is distributed in units of MBMS service areas, not in units of cells of the base station apparatus. Therefore, even when there is a cell in the MBMS service area where a terminal to be distributed is not located, multicast data is distributed to the base station apparatus of that cell.

  In the future, it is expected that such multicast data distribution services will be diversified, for example, in addition to the conventional broadcast service in which the service area is relatively wide, the number of broadcast services only for a narrow range is increasing.

  Furthermore, if the service forms are diversified in this way, it is expected that the multicast data to be distributed will also be diversified from the public use that is widely distributed to the personal community, and the types will be significantly increased.

  For example, as described in Non-Patent Document 2, there are use cases such as a guided tour of travel. In addition, for example, a multicast service for customers at a customer collection facility such as a sports or concert venue or a shopping center can be considered. Furthermore, there may be a case where information is distributed only to the victims in the disaster-stricken area.

  Without optimizing for such a service form and the increasing flow of distribution data, communication paths such as MBMS bearers are established for all multicast distribution data in a unified manner regardless of the presence or absence of receiving terminals. Data was distributed over the communication channel. As a result, new problems such as an increase in traffic and a shortage of radio resources occur.

  In order to solve such problems, in recent years, a base station device has started to study a counting function for counting terminals that are receiving multicast data. When the base station apparatus detects that there is no receiving terminal, the communication band of the radio link allocated for multicast data delivery between the base station apparatus and the terminal is released or optimized by changing the mode, etc. Efficient use of resources in the radio section. Further, when the terminal appears again, the radio resources are reassigned. As described above, studies have been made on the efficient use of radio resources by the counting function.

TS 23.246, Technical Specification Group Services and Architecture; Multimedia Broadcast / Multicast Service (MBMS); Architecture and functional description 3GPP TR 22.947, Technical Specification Group Services and System Aspects; Study on Personal Broadcast Service

  The efficiency improvement based on the counting result of the conventional base station apparatus is only a method of efficiently using the resources of the wireless communication section between the base station apparatus and the terminal, and between the base station apparatus and the multicast data distribution source apparatus. There was no way to efficiently use resources in the communication section inside the network.

  That is, even if the base station device detects that there is no terminal that receives the multicast data by the counting function, the multicast data is delivered from the multicast distribution source device installed in the network to the base station device. Until now, there has been no solution that uses the counting function to reduce traffic and efficiently use network resources.

  As described above, although effective use of radio resources between the base station apparatus and the terminal is considered by the counting function, there is a problem that the network resources in the network cannot be used efficiently.

  In the above-mentioned Non-Patent Document 1, a procedure for canceling MBMS registration for a certain service is shown. As a method for that, a base station device takes the lead in providing multicast data and broadcast data to a device. The procedure for canceling MBMS registration is shown.

  However, no specific means for determining the start of the MBMS deregistration procedure in the base station apparatus is shown. Further, in each device located upstream of the data delivery path, there is no specific means for starting the MBMS deregistration procedure for the further upstream data delivery source device.

  Furthermore, considering user convenience, it is necessary to perform an MBMS registration procedure and an MBMS deregistration procedure in response to the presence or absence of the user's viewing, but in the past, they could not be performed efficiently.

  Specifically, in the multicast mode, a deactivation procedure for requesting the user to leave the service is performed, and the MBMS deregistration procedure is started upon completion of the deactivation procedure. Furthermore, activation for service participation is also required when resuming distribution. Therefore, even when the mobile station apparatus is temporarily powered off or temporarily disconnected from the base station apparatus that provides the MBMS service, a deactivation procedure is necessary.

  As described above, communication resources are used inefficiently, such as the need to send and receive control messages such as deactivation procedures for MBMS deregistration. In addition, the MBMS deregistration procedure originally does not require processing in the mobile station device, but the deactivation procedure requires transmission / reception of a control message to / from the mobile station device. In other words, the mobile station apparatus requires a complicated procedure that does not require MBMS deregistration without processing, which is inefficient.

  Thereby, when the base station apparatus detects that there is no data receiving terminal based on the counting result, the mobile station apparatus (terminal) has moved to a different base station apparatus without requesting resource release, When the base station apparatus detects that the power of the station apparatus has been turned off, the MBMS deregistration that does not involve the mobile station apparatus cannot be performed efficiently. As a result, although network resources are not actually required, traffic flows while being allocated, and resources are wasted.

  In addition, as a method of temporarily stopping distribution in order to effectively use network resources, a method of performing a conventional session stop procedure can be considered. However, in the conventional method, only a procedure for stopping a session from the distribution source to the distribution destination is defined, and it is impossible to request a session stop from the distribution destination to the distribution source. That is, the session stop cannot be requested from the base station apparatus to the distribution source.

  Even if the base station device is extended to request a session stop from the distribution source, a new problem arises. The device that has received the session stop request can stop distribution and temporarily release resources, but does not delete the distribution list. Therefore, for example, conventionally, when 1) a session is started and 2) only the session is stopped by the base station apparatus, 3) all the sessions are led by the delivery source of multicast data (broadcast data). 4) All nodes included in the distribution list (for example, MBMS GW, base station apparatus) when all sessions are resumed led by the delivery source of multicast data (broadcast data) after being stopped Communication resources have been allocated to the network, and even a session that was stopped by the base station device has been resumed. That is, although unnecessary resources are released in 1), unnecessary resources are allocated again.

  Therefore, in order to efficiently use communication resources, the distribution list is updated by the MBMS deregistration procedure, and the session is resumed at the initiative of the multicast data (broadcast data) delivery source as in 4), for example. In addition, it is necessary to prevent delivery to an unnecessary apparatus from being resumed. This is necessary not only for improving the efficiency of resources for data delivery but also for eliminating the need for control procedures for unnecessary devices.

  In order to solve the above-described problems, an object of the present invention is to provide a mobile communication system or the like that can effectively use network resources by defining a control method for efficiently allocating network resources by a counting function of a base station apparatus. It is an object.

  In order to solve the above problems, a mobile communication system according to the present invention has the following features.

The mobile communication system of the present invention is
A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In a mobile communication system that performs multicast data distribution by MBMS bearer service to a device,
The MME has MBMS registered the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
The base station device
A confirmation message including a service identifier is transmitted to the mobile station device, and the number of mobile station devices that require multicast data distribution is counted based on a response from the mobile station device, and the counted number is 0 In this case, an MBMS deregistration request for the multicast data is transmitted to the MME.

  In the mobile communication system of the present invention, the service identifier includes TMGI (Temporary Mobile Group Identify).

  Further, in the mobile communication system according to the present invention, when the MME receives an MBMS deregistration request, the MME deletes the base station apparatus that has transmitted the MBMS deregistration request from the MBMS bearer context distribution list. To do.

  In the mobile communication system of the present invention, the base station apparatus releases MBMS bearer resources in conjunction with transmitting an MBMS deregistration request to the MME.

In the mobile communication system of the present invention, when the base station apparatus included in the delivery list of the MBMS bearer context disappears, the MME sends an MBMS deregistration request associated with the MBMS bearer context to the MBMS GW. Send
The MBMS GW deletes the base station apparatus that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context.

Also, in the mobile communication system of the present invention, the MBMS GW is configured to register an MBMS associated with an MBMS bearer context when the base station apparatus that distributes multicast data included in the distribution list of the MBMS bearer context disappears. Send a cancellation request to BM-SC,
The BM-SC deletes the MBMS GW that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context.

The mobile communication system of the present invention is based on a BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) where MBMS (Multimedia Broadcast / Multicast Service) bearers are established. In a mobile communication system that performs broadcast data distribution by an MBMS bearer service to a mobile station device connected to a station device,
The MME has MBMS registered the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
The base station device
A confirmation message including a service identifier is transmitted to the mobile station device, and the number of mobile station devices that require broadcast data distribution is counted based on a response from the mobile station device, and the counted number is 0 In this case, an MBMS deregistration request for the broadcast data is transmitted to the MME.

  In the mobile communication system of the present invention, the service identifier includes TMGI (Temporary Mobile Group Identify).

  In the mobile communication system of the present invention, when the MME receives an MBMS deregistration request, the MME deletes the base station apparatus that has transmitted the MBMS deregistration request from the MBMS bearer context distribution list. To do.

  In the mobile communication system of the present invention, the base station apparatus transmits a session including a stop request together with transmitting an MBMS deregistration request to the MME.

In the mobile communication system of the present invention, when the base station apparatus that performs broadcast data distribution included in the distribution list of the MBMS bearer context disappears, the MME cancels the MBMS registration associated with the MBMS bearer context. Send request to MBMS GW,
The MBMS GW deletes the base station apparatus that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context.

In the mobile communication system of the present invention, the MBMS GW deregisters an MBMS associated with an MBMS bearer context when there is no base station apparatus that performs broadcast data distribution included in the MBMS bearer context distribution list. Send the request to BM-SC,
The BM-SC deletes the MBMS GW that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context.

The base station apparatus according to the present invention provides a base from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established. In a base station device connected to a mobile communication system that performs multicast data distribution by MBMS bearer service to a mobile station device connected to the station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
The base station apparatus transmits an MBMS deregistration request for multicast data to be transmitted to the MME when there is no mobile station apparatus that requires multicast data distribution.

The base station apparatus according to the present invention provides a base from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established. In a base station device connected to a mobile communication system that performs broadcast data distribution by MBMS bearer service to a mobile station device connected to the station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
A confirmation message including a service identifier is transmitted to the mobile station device, and the number of mobile station devices that require broadcast data distribution is counted based on a response from the mobile station device, and the counted number is 0 In this case, an MBMS deregistration request for the broadcast data is transmitted to the MME.

The MME of the present invention is a base station apparatus from a BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established. In the MME connected to the mobile communication system that performs multicast data distribution by the MBMS bearer service to the mobile station device connected to
MBMS registration of the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
Receiving from the base station device an MBMS deregistration request for multicast data transmitted when there is no mobile station device requiring multicast data distribution;
When the MBMS deregistration request is received, the base station apparatus that has transmitted the MBMS deregistration request is deleted from the MBMS bearer context distribution list.

The MME of the present invention is a base station apparatus from a BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established. In an MME connected to a mobile communication system that performs broadcast data distribution by an MBMS bearer service to a mobile station device connected to
MBMS registration of the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
Receiving an MBMS deregistration request for broadcast data transmitted when there is no mobile station device requiring broadcast data distribution from the base station device;
When the MBMS deregistration request is received, the base station apparatus that has transmitted the MBMS deregistration request is deleted from the MBMS bearer context distribution list.

  The mobile station apparatus of the present invention is connected to the mobile communication system described in the above-described invention.

  According to the present invention, in a mobile communication system that performs multicast data distribution by MBMS bearer service from a BM-SC to an MBMS GW and an MME for which an MBMS bearer has been established, and a mobile station device connected to the base station device, Uses the counting function to detect that the number of UEs receiving multicast data is 0, and when it decides to cancel MBMS deregistration for multicast data distribution, sends an MBMS deregistration request to the MME. By releasing the MBMS registration of the multicast data and stopping the session, the delivery from the MBMS GW is stopped.

  Thus, conventionally, the procedure for canceling the MBMS registration was regulated by the base station apparatus, but the MBMS registration procedure and the MBMS registration cancellation procedure could not be performed in response to the presence or absence of viewing by the user.

  However, the base station device deletes the delivery destination device in the distribution list by the MBMS deregistration procedure based on the result of the necessity of reception of the mobile station device, and also releases the resources performed by the session stop procedure. Will be able to do.

  Also, as in the multicast mode, a deactivation procedure for requesting the user to leave the service is performed, and the MBMS deregistration procedure is started upon completion of the deactivation procedure. However, it is possible to stop the service distribution without performing the deactivation procedure by detecting the presence / absence of the user's viewing by the counting function, and in such a case, when resuming the service distribution It is possible to receive the service without performing the activation procedure. In addition, even when the mobile station apparatus is temporarily powered off or temporarily disconnected from the base station apparatus that provides the MBMS service, it is not necessary to perform the deactivation procedure.

  As described above, transmission / reception of a control message such as a deactivation procedure is not required for MBMS deregistration, so that communication resources can be used efficiently. In addition, the deactivation procedure does not require transmission / reception of control messages to / from the mobile station apparatus, and MBMS registration cancellation can be efficiently performed under the initiative of the base station apparatus without performing processing by the mobile station apparatus.

Thereby, when the base station apparatus detects that there is no data receiving terminal based on the counting result, the mobile station apparatus (terminal) has moved to a different base station apparatus without requesting resource release, When the base station apparatus detects that the power of the station apparatus is turned off, it is possible to perform efficient MBMS deregistration without processing in the mobile station apparatus. As a result, it is possible to avoid a situation where traffic flows while being allocated even though network resources are not actually needed, and resources are wasted.
Further, in the conventional method, only a procedure for stopping a session from the distribution source to the distribution destination is defined, and it is impossible to request a session stop from the distribution destination to the distribution source. That is, the session stop cannot be requested from the base station apparatus to the distribution source. Furthermore, even if the base station apparatus expands to request a session stop from the distribution source, the apparatus that has received the session stop request can stop the distribution and temporarily release the resource. Do not delete.

  Therefore, for example, when 1) a session is started and 2) only the session is stopped by eNB, 3) after all sessions are stopped by BM-SC, 4) BM-SC When all sessions are resumed, communication resources are allocated to all nodes (MBMS GW, MME, base station apparatus) included in the distribution list, and even the session stopped by NB initiative There was a problem of being resumed.

  However, even when the distribution destination device is updated from the distribution list by the MBMS deregistration procedure and the session is resumed led by BM-SC as in 4), unnecessary sessions are not started.

  In addition, since the session is not started unnecessarily, the exchange of control information required when starting the session can be reduced, and the communication resource required for the session start procedure is not used inefficiently. Can be effectively utilized.

It is the figure which showed the outline of the mobile communication system in 1st Embodiment. It is a figure for demonstrating the function structure of BM-SC in 1st Embodiment. It is the figure which showed an example of the data structure of MBMS service DB in BM-SC. It is the figure which showed an example of the data structure of the MBMS bearer context in BM-SC. It is the figure which showed an example of the data structure of the MBMS UE bearer context in BM-SC. It is a figure for demonstrating the function structure of MBMS GW in 1st Embodiment. It is the figure which showed an example of the data structure of the MBMS bearer context in MBMS GW. It is the figure which showed an example of the data structure of upstream control node DB in MBMS GW. It is the figure which showed an example of the data structure of the MBMS UE bearer context in MBMS GW. It is a figure for demonstrating the function structure of MME in 1st Embodiment. It is the figure which showed an example of the data structure of the MBMS bearer context in MME. It is the figure which showed an example of the data structure of the MBMS UE bearer context in MME. It is a figure for demonstrating the function structure of eNB in 1st Embodiment. It is the figure which showed an example of the data structure of the MBMS bearer context in eNB. It is the figure which showed an example of the data structure of the radio | wireless frame information in eNB. It is the figure which showed an example of the data structure of the MBMS UE bearer context in eNB. It is a figure explaining the flow of the process in 1st Embodiment. It is a figure explaining the flow of the process in 1st Embodiment. It is a figure for demonstrating the change of the bearer context in 1st Embodiment. It is a figure explaining the flow of the process in 1st Embodiment. It is a figure explaining the flow of the process in 1st Embodiment. It is a figure explaining operation | movement in 1st Embodiment. It is a figure explaining operation | movement in 1st Embodiment. It is a figure explaining the flow of the process in 2nd Embodiment. It is a figure for demonstrating the change of the bearer context in 2nd Embodiment. It is a figure explaining the flow of the process in 2nd Embodiment. It is a figure explaining the flow of the process in 2nd Embodiment.

The best mode for carrying out the present invention will be described below with reference to the drawings.
[1. First Embodiment]
[1.1 System configuration]
FIG. 1 is a diagram for explaining an outline of a mobile communication system 1 when the present invention is applied. The mobile communication system 1 includes a BM-SC (Broadcast-Multicast Service Center) 10 that is a broadcast / multicast service center, an MBMS GW (MBMS GateWay) 20 that is a gateway device, and an MME (Mobility Management Entity) 30 that is a service control device. The core network 5 is included, the base station device is an eNB 40, and the mobile station device is a UE 50.

  The eNB 40 is connected to the core network 5, and the UE 50 can be connected to the eNB 40. Specifically, the MBMS GW 20 is connected to the lower level of the BM-SC 10, and the eNB 40 is connected to the lower level of the MBMS GW 20 via the MME 30 or directly. Furthermore, UE50 is connected to the lower level of eNB40.

  Here, in FIG. 1 of the present embodiment, each component device is described as one for convenience of explanation, but a plurality of devices may be connected. For example, the mobile communication system 1 includes one or a plurality of MBMS GWs, and one or a plurality of MMEs and eNBs are connected to the lower layers of each MBMS GW. Also, one or more UEs can be connected to the eNB.

[1.2 Device configuration]
Subsequently, the functional configuration of each apparatus will be described with reference to the drawings.

[1.2.1 BM-SC]
A functional configuration of the BM-SC 10 will be described with reference to FIG. In the BM-SC 10, a transmission / reception unit 110 and a storage unit 120 are connected to the control unit 100.

  The control unit 100 is a functional unit for controlling the entire BM-SC 10. The control unit 100 realizes various functions by reading and executing various programs stored in the storage unit 120, and is configured by, for example, a CPU (Central Process Unit).

  The transmission / reception unit 110 is an interface unit connected to a network, and is connected to the MBMS GW 20 via the network, for example.

  The storage unit 120 is a functional unit that stores various programs and various data necessary for the operation of the BM-SC 10. The storage unit 120 includes, for example, a semiconductor memory, an HDD (Hard Disk Drive), or the like. In the present embodiment, an MBMS service DB 122, an MBMS bearer context 124, and an MBMS UE context 126 are stored.

  The MBMS service DB 122 is a DB that stores a service identifier of distribution data for each MBMS bearer service in order to manage a distributable MBMS bearer service. FIG. 3 shows an example of the data configuration of the MBMS service DB 122.

Here, various “service identifiers” are used. For example,
(1) TMGI (Temporary Mobile Group Identity) identifying MBMS bearer context
(2) Other identifiers (for example, identifiers assigned by businesses that operate the BM-SC 10 and perform service businesses) can be used.

  In the present embodiment, description will be made assuming that TMGI of (1) is used. Specifically, TMGI that identifies the MBMS bearer context 124 generated for each service is used when multicast data is distributed in the MBMS bearer service. Here, TMGI is temporarily assigned subscriber identification information used in a conventional cellular phone service, but is used as information for identifying an MBMS bearer service in MBMS.

  The MBMS bearer context 124 is MBMS bearer management information that is generated for each MBMS bearer service and is established to deliver multicast data. FIG. 4 shows an example of the data configuration of the MBMS bearer context 124.

  The MBMS bearer context 124 includes an MBMS bearer service identifier (eg, “TMGI1”) required for MBMS registration, an identifier of a session established for distribution (eg, “session ID”), multicast, A mode (for example, “multicast”) for identifying the mode or broadcast mode, status information (for example, “active”) that manages whether the MBMS bearer is active or suspended, and a data distribution destination distribution node ( For example, “MBMS GW20”) and UE counter (for example, “N”) are included.

  Here, the distribution node stores information for specifying the node to be distributed, and stores, for example, an IP address (in the case of FIG. 4, the IP address of the MBMS GW 20). Here, one or a plurality of distribution nodes can be stored.

  In addition, since a distribution node or a higher-level distribution node described later is stored in each device, a distribution list of the mobile communication system 1 is formed. The distribution list is for specifying a distribution node, and a bearer between the BM-SC 10 and the UE 50 is established according to the distribution list.

  Here, when each device is registered in a predetermined distribution list, the information regarding the distribution node of the MBMS bearer context stored in each device may be updated and registered. On the other hand, when the information is not included in the distribution list, the predetermined device may be deleted from the information regarding the distribution node of the MBMS bearer context stored in each device.

  Here, the UE counter is the number of UEs that need to receive multicast data of the MBMS bearer service. This is based on the number counted by the counting function of the base station apparatus (eNB 40). For example, it may be the number of UEs 50 connected to the eNB 40, or the UE 50 participates in a multicast group. The number of UEs 50 may be used. Furthermore, the number of the terminal (UE50) that the user is actually viewing, that is, the number excluding the UE50 that is not viewing temporarily by detecting a state in which the user has not activated the viewing application, It may be the number of UEs 50 that notify the user that reception is necessary.

  Furthermore, when the MBMS bearer context 124 stores MBMS GW information that is a plurality of delivery nodes, the BM-SC 10 can store different UE counters for each MBMS GW and count the number of UEs. . Therefore, the BM-SC 10 can store the number of viewing terminals of multicast data distributed to the MBMS GW 20.

The MBMS UE context 126 is generated for each MBMS service, and is UE management information indicating that the UE participates in the MBMS service. The BM-SC 10 can refer to the MBMS UE context 126, perform user registration for each MBMS service, and charge for each MBMS service. FIG. 5 shows an example of the data configuration of the MBMS bearer context 126.

  The MBMS UE context 126 includes an IP multicast address (for example, “IP multicast address 1”) required when activating to the MBMS service, and an APN (necessary when the UE 50 acquires an IP address at the time of initial connection. Access Point Name) information (for example, “APN1”) and IMSI (International Mobile Subscriber Identity) information (for example, “IMSI1”) used to identify the UE are included.

[1.2.2 MBMS GW]
Next, the functional configuration of the MBMS GW 20 will be described with reference to FIG. In the MBMS GW 20, a transmission / reception unit 210 and a storage unit 220 are connected to the control unit 200.

  The control unit 200 is a functional unit for controlling the entire MBMS GW 20. The control unit 200 implements various functions by reading and executing various programs stored in the storage unit 220, and is configured by, for example, a CPU (Central Process Unit).

  The transmission / reception unit 210 is an interface unit connected to the network, and is connected to, for example, the BM-SC 10, the MME 30, and the eNB 40 via the network.

  The storage unit 220 is a functional unit that stores various programs and various data necessary for the operation of the MBMS GW 20. The storage unit 220 includes, for example, a semiconductor memory, an HDD (Hard Disk Drive), or the like. In the present embodiment, an MBMS bearer context 222, an upstream control node DB 224, and an MBMS UE context 226 are stored. Here, the MBMS bearer context 222 can be uniquely identified by TMGI.

  The MBMS bearer context 222 is management information that is generated for each MBMS bearer service and is necessary for delivering multicast data. In FIG. 7, an example of a data structure of the MBMS bearer context 222 is shown.

  The MBMS bearer context 222 includes an MBMS bearer service identifier such as TMGI (for example, “TMGI1”), an identifier of a session established for distribution (for example, “session ID”), and an IP multicast for performing IP multicast communication. An address (for example, “IP multicast address 1”), a mode for identifying the multicast mode or the broadcast mode (for example, “multicast”), and status information for managing whether the state of the MBMS bearer is active or suspended (for example, “Active”), MBMS control device information (eg, “MME30”), information about distribution nodes (eg, MME30), and UE counter (eg, “N”).

  Here, the distribution node stores information for specifying a node to be distributed, and stores, for example, an IP address (in the case of FIG. 7, the IP address of the eNB 40). A plurality of distribution nodes can be stored.

  The IP multicast address is stored for each MBMS bearer service that generates an MBMS bearer context.

  The UE counter is the number of mobile station apparatuses (terminals) that receive the multicast data of the MBMS bearer service. This is based on the number counted by the counting function of the base station apparatus (eNB 40), and is the number of mobile station apparatuses actually viewed by the user.

  Furthermore, when the MBMS bearer context 222 stores information on eNBs 40 that are a plurality of distribution nodes, the MBMS GW 20 can store different UE counters for each eNB 40 and count the number of UEs. Therefore, the MBMS GW 20 can store the number of viewing terminals of multicast data distributed to the eNB 40.

  The upstream control node DB 224 is a DB for storing information for specifying an upstream multicast data distribution apparatus. FIG. 8 shows an example of the configuration of the upstream control node DB 224. In the present embodiment, information related to the BM-SC 10 is stored, for example, the IP address of the BM-SC 10 is stored.

  The upstream control node DB 224 stores one upstream control node (BM-SC 10) as shown in FIG. Alternatively, a plurality of upstream control nodes (BM-SC 10) may be stored for each service. In that case, the information is stored for each MBMS bearer context that can be identified by TMGI or the like.

  The MBMS UE context 226 is management information of the UE 50 that is generated for each MBMS service and indicates that the UE 50 participates in the MBMS service. The MBMS GW 20 performs MBMS registration when the first MBMS UE context is generated in a certain MBMS service. Also, in a certain MBMS service, when the last MBMS UE context 226 is deleted, the MBMS registration is canceled. In FIG. 9, an example of a data structure of the MBMS UE context 226 is shown.

  The MBMS UE context 226 includes an IP multicast address (for example, “IP multicast address 1”) required when activating to the MBMS service, and an APN required when the UE 50 acquires an IP address at the initial connection. Information (for example, “APN1”), eNB (for example, “eNB40”) through which the service is delivered, and IMSI information (for example, “IMSI1”) used to identify the UE are included.

[1.2.3 MME]
Next, the functional configuration of the MME 30 will be described with reference to FIG. In the MME 30, a transmission / reception unit 310 and a storage unit 320 are connected to the control unit 300.

  The control unit 300 is a functional unit for controlling the entire MME 30. The control unit 300 implements various functions by reading and executing various programs stored in the storage unit 320, and is configured by, for example, a CPU (Central Process Unit).

  The transmission / reception unit 310 is an interface unit connected to the network, and is connected to the MBMS GW 20 and the eNB 40 via the network, for example.

  The storage unit 320 is a functional unit that stores various programs necessary for the operation of the MME 30 and various data. The storage unit 320 includes, for example, a semiconductor memory, an HDD (Hard Disk Drive), or the like. In the present embodiment, an MBMS bearer context 322 and an MBMS UE context 324 are stored.

  The MBMS bearer context 322 is generated for each MBMS bearer service and is management information necessary for delivering multicast data. In FIG. 11, an example of a data structure of the MBMS bearer context 322 is shown. Here, the MBMS bearer context 322 can be uniquely identified by TMGI.

  Specifically, an MBMS bearer service identifier such as TMGI (for example, “TMGI1”), an identifier of a session established for distribution (for example, “session ID”), and an IP multicast address for performing IP multicast communication (For example, “IP multicast address 1”, a mode for identifying the multicast mode or the broadcast mode (for example, “multicast”), and status information for managing whether the MBMS bearer is active or suspended (for example, “ Active ”), a data distribution destination distribution node (for example,“ NB40 ”), a higher level distribution node (for example,“ MBMS GW20 ”), and a UE counter (for example,“ N ”). include.

  Here, the distribution node and the higher-level distribution node store information for specifying each node, for example, an IP address (in the case of FIG. 11, the NB 40 or the IP address of the MBMS GW 20) is stored. A plurality of distribution nodes can be stored.

  The IP multicast address is stored for each MBMS bearer service that generates the MBMS bearer context 322.

  The UE counter is the number of mobile station apparatuses (terminals) that receive the multicast data of the MBMS bearer service. This is based on the number counted by the counting function of the base station apparatus (eNB 40), and is the number of terminals that the user is actually viewing.

  Further, when the MME 30 stores information on eNBs that are a plurality of distribution nodes in the MBMS bearer context 322, the MME 30 can store different UE counters for each eNB and count the number of UEs. Therefore, the MME 30 can store the number of viewing terminals of multicast data distributed to the eNB 40.

  The MBMS UE context 324 is generated for each MBMS bearer service, and is management information for the UE 50 in multicast data distribution. The MME 30 performs MBMS registration when the first MBMS UE context 324 is generated in a certain MBMS service. In addition, when a final MBMS UE context is generated in a certain MBMS service, MBMS registration is canceled. In FIG. 12, an example of a data structure of the MBMS UE context 324 is shown.

  The MBMS UE context 324 includes an IP multicast address (for example, “IP multicast address 1”) required when activating to the MBMS service and an APN required when the UE 50 acquires an IP address at the initial connection. Information (for example, “APN1”), data distribution destination distribution node information (for example, “eNB40”), higher level distribution node information (for example, “MBMS GW20”), and UE 50 TMGI (for example, “TMGI1”) indicating the multicast service to participate in is included.

[1.2.4 eNB]
Next, the functional configuration of the eNB 40 will be described using FIG. In the eNB 40, a transmission / reception unit 410 and a storage unit 420 are connected to the control unit 400.

  The control unit 400 is a functional unit for controlling the entire eNB 40. The control unit 400 realizes various functions by reading and executing various programs stored in the storage unit 420, and is configured by, for example, a CPU (Central Process Unit).

  The transmission / reception unit 410 is an interface unit connected to the network. For example, the transmission / reception unit 410 is connected to the MBMS GW 20 and the MME 30 via the network, and the UE 50 can be connected thereto.

  The storage unit 420 is a functional unit that stores various programs necessary for the operation of the eNB 40 and various data. The storage unit 420 includes, for example, a semiconductor memory, an HDD (Hard Disk Drive), or the like. In this embodiment, MBMS bearer context 422, radio frame information 424, and MBMS UE context 426 are stored.

  The MBMS bearer context 422 is management information that is generated for each MSMS bearer service and is necessary for delivering multicast data. In FIG. 14, an example of a data structure of the MBMS bearer context 422 is shown.

  The MBMS bearer context 422 includes an MBMS bearer service identifier such as TMGI (eg, “TMGI1”), an identifier of a session established for distribution (eg, “session ID”), and an IP multicast for performing IP multicast communication. An address (for example, “IP multicast address 1”), a mode for identifying the multicast mode or the broadcast mode (for example, “multicast”), and status information for managing whether the MBMS bearer is active or suspended (for example, , “Active”), MBMS control device information (for example, “MME30”), higher-level distribution node information (for example, “MBMS GW20”), and UE counter (for example, “N”) ) And are included.

  Here, the information related to the higher-level delivery node stores information for specifying the node, for example, an IP address (in the case of FIG. 14, the IP address of the MME 30). The IP multicast address is stored for each MBMS bearer service that generates an MBMS bearer context.

  The UE counter is the number of mobile station apparatuses (terminals) that receive the multicast data of the MBMS bearer service. This is based on the number counted by the counting function of the eNB 40, and is the number of mobile station apparatuses (UE50) that the user is actually viewing.

  The radio frame information 424 stores radio frame information for the eNB 40 to transmit to the UE 50 through the radio section for each MBMS bearer service. FIG. 15 shows an example of the data configuration of the radio frame information 424.

  Specifically, mode information (for example, “frame mode”) indicating the multicast mode or the unicast mode is stored for each identifier for identifying the MBMS bearer service (for example, for each TMGI). Furthermore, in the case of the unicast mode, identification information such as IMSI (International Mobile Subscriber Identity) of the UE 50 that delivers the frame is stored. Here, a plurality of UEs (identification information) for frame delivery can be stored.

  The MBMS UE context 426 is generated for each MBMS bearer service, and is management information of the UE 50 in multicast data distribution. The eNB 40 performs MBMS registration when the first MBMS UE context is generated in a certain MBMS service. In addition, when a final MBMS UE context is generated in a certain MBMS service, MBMS deregistration is performed. In FIG. 16, an example of a data structure of the MBMS UE context 426 is shown.

  The MBMS UE context 426 includes an IP multicast address (for example, “IP multicast address 1”) required when activating to the MBMS service, and an APN (necessary when the UE 50 acquires an IP address at the initial connection). For example, “APN1”) and TMGI (for example, “TMGI1”) indicating a multicast service in which the UE participates are included.

[1.3 Procedure processing]
Subsequently, a procedure process of the mobile communication system 1 in the present embodiment will be described with reference to the drawings.

[1.3.1 Service announcement procedure]
First, as shown in FIG. 17, the BM-SC 10 first performs a service announcement procedure for the UE 50 (S100). That is, the BM-SC 10 notifies the UE 50 of services that can be distributed. The UE 50 thereby detects the multicast service.

  The BM-SC 10 notifies the UE 50 by notifying the service identifier that the service managed by the MBMS service DB 122 can be distributed. Furthermore, information describing a service such as a program title, a content title, and a distribution start time may be added and notified.

Here, various service identifiers are used. For example,
(1) TMGI
(2) Other identifiers (for example, other identifiers that can be set by the operator to identify the MBMS bearer service)
Etc. are available. In the present embodiment, description will be made assuming that TMGI of (1) is used.

  In addition, various methods are conceivable as specific notification methods. For example, SMS (Short Message Service) or the like is used to notify the UE 50 that can be distributed in advance or an unspecified number of UEs 50. Or the information may be posted on the WEB, and the UE 50 may acquire the information by accessing the WEB server.

[1.3.2 Activation procedure]
Subsequently, the UE 50 performs an activation procedure for participating in the multicast service notified by the service announcement (S102). Here, an activation procedure for the UE 50 to participate in the multicast service will be described with reference to FIG.

  This procedure starts the activation procedure when the UE 50 makes an IGMP join request to the MBMS GW 20 (S200). Here, there are various request methods for the UE 50 to participate in the MBMS service to the MBMS GW 20. For example, the UE 50 may notify the MBMS GW 20 of information uniquely indicating the service notified from the service announcement. Is possible. Specifically, an IGMP Membership Report is transmitted when communicating with IPv4, and an MLD Membership Report is transmitted when communicating with IPv6.

  Next, the MBMS GW 20 transmits an MBMS approval request for the UE 50 to participate in the service to the BM-SC 10 (S202). The BM-SC 10 that has received the MBMS approval request approves the UE 50 that requested the participation based on the service agreement. Here, the charging process may be performed on the UE 50 to be approved.

  Subsequently, the BM-SC 10 transmits an approval response indicating that the UE 50 has been approved to the MBMS GW 20 (S204). Here, the BM-SC 10 transmits the approval response including the APN. However, when the BM-SC 10 does not allow the UE 50 to participate in the service, the approval response may not be transmitted.

  Next, the MBMS GW 20 transmits an MBMS notification request to the MME 30 (S206). Here, the MBMS GW 20 transmits the IP multicast address and APN. The IP multicast address is an address at which the UE 50 has requested to participate. Next, the MME 30 transmits an MBMS notification response to the MBMS GW 20 (S208).

  Further, the MME 30 transmits an MBMS context activation request to the UE 50 in order to validate the MBMS UE context (S210). Here, the MME 30 transmits the MBMS context request including the IP multicast address and the APN.

  The UE 50 that has received the MBMS context activation request creates an MBMS UE context and transmits an MBMS context activation response to the MME 30 (S212). Here, the MBMS context activation response includes an IP multicast address, an APN, and information on QoS that can be processed by the UE. In addition, the MBMS UE context includes an IP multicast address, an APN, information on an MBMS GW that is an upper delivery node, and TMGI.

  Next, the MME 30 that has received the MBMS UE context activation response from the UE 50 creates an MBMS UE context and transmits an MBMS context request to the MBMS GW 20 (S214). Here, the MME 30 transmits the MBMS context request including the IP multicast address and the APN. The MBMS UE context includes an IP multicast address, an APN, and information on the MME 30 that is a distribution node.

  Next, the MBMS GW 20 that has received the MBMS context request from the MME 30 transmits an MBMS approval request to the BM-SC 10 in order to confirm service participation by the UE 50 (S216). The BM-SC 10 that has received the MBMS approval request from the MBMS GW 20 creates the MBMS UE context 126 after confirming service participation by the UE 50. The MBMS UE context includes an IP multicast address and an APN. Subsequently, the BM-SC 10 transmits an MBMS approval response to the MBMS GW 20 (S220).

  The MBMS GW 20 that has received the MBMS acknowledgment response from the BM-SC 10 creates the MBMS UE context 226 and transmits the MBMS context response to the MME 30 (S222).

  Then, MME30 which received the MBMS context response from MBMS GW20 creates the MBMS UE context 324, and transmits the notification of MBMS UE context to NB40 (S224).

  The eNB 40 that has received the MBMS UE context notification from the MME 30 creates the MBMS UE context 426. The MBMS UE context 426 includes an IP multicast address, an APN, and a TMGI.

  Next, the MME 30 transmits an MBMS context activation permission response to the UE 50 (S226). The MME 30 transmits TMGI in the MBMS context activation permission response. Here, TMGI is an identifier that uniquely indicates the MBMS service.

[1.3.3 MBMS registration procedure]
Next, the MBMS registration procedure in a certain MBMS service will be described with reference back to FIG. A communication path from the BM-SC 10 to the UE 50 is established by the MBMS registration procedure.

  For establishing the communication path, the MBMS bearer context 124 is created in the BM-SC 10, the MBMS bearer context 222 in the MBMS-GW 20, the MBMS bearer context 322 in the MME 30, the MBMS bearer context 422 in the NB 40, and the MBMS bearer context 124 in the BM-SC 10. The MBMS bearer context 222 in the MBMS GW 20 and the MBMS bearer context 322 in the MME 30 need to be registered in the respective distribution node lists.

  That is, information on MBMS GW 20 is registered in the distribution node in BM-SC 10, information on eNB 40 is registered in the distribution node in MBMS GW 20, and information on eNB 40 is registered in the distribution node in MME 30. In addition, information regarding a plurality of downlink nodes may be registered in each distribution node in the BM-SC 10, MBMS GW 20, and MME 30.

  First, the eNB 40 starts the MBMS registration procedure by detecting the UE 50 participating in the MBMS service. Here, there are various detection methods for the UE 50 in which the eNB 40 participates in the MBMS service. For example, the UE 50 can notify the eNB 40 of information uniquely indicating the service notified from the service announcement.

  Here, the eNB 40 may generate the MBMS UE context 426 of the UE 50 that participates in the service. The MBMS UE context 446 includes an IP multicast address, APN, and TMGI. Furthermore, if the eNB 40 has generated the first MBMS UE context 446 including this TMGI, the eNB 40 may signal the MBMS registration start procedure.

  Furthermore, the trigger for the eNB 40 to start the MBMS registration procedure may be performed at any timing other than the above, depending on the operator's policy or the like.

  Next, the eNB 40 transmits an MBMS registration request for MBMS registration of the service designated by the UE 50 to the MME 30 (S104). Here, the eNB 40 transmits the MBMS registration request including TMGI, the IP multicast address, and the APN.

  The MME 30 that has received the MBMS registration request from the eNB 40 transmits the MBMS registration request to the MBMS GW 20 (S106). Here, the MBMS registration request includes information on the eNB 40 registered in the distribution node, TMGI, IP multicast address, and APN.

  Here, the MME 30 generates an MBMS bearer context 322 corresponding to the service. The MBMS bearer context 322 includes TMGI that identifies the service. Further, the status information of the bearer resource in the MBMS bearer context 322 is set to “standby”.

  Here, the MBMS UE context 324 of the UE 50 participating in the service may be generated. The MBMS UE context 324 includes an IP multicast address, an APN, a TMGI, and information on the MBMS GW that is a higher-level delivery node.

  MBMS GW20 which received the MBMS registration request from MME30 produces | generates the MBMS bearer context 222, and transmits a MBMS registration request to BM-SC (S108). Here, the state information of the bearer resource in the MBMS bearer context 222 is set to “standby”.

  Here, the MBMS GW 20 may generate the MBMS UE context 226 of the UE 50 that participates in the service. The MBMS UE context 226 includes an IP multicast address, an APN, and information on the eNB 40 that is a distribution node.

  The BM-SC 10 that has received the MBMS registration request from the MBMS GW 20 registers the information of the MBMS GW 20 that has transmitted the MBMS registration request to the MBMS bearer context in the distribution node, and returns an MBMS registration response (S110). Here, the MBMS registration response includes information about TMGI and QoS.

  The MBMS GW 20 that has received the MBMS registration request from the MME 30 in S106 registers the MME 30 that has transmitted the MBMS registration request in the MBMS control device of the MBMS bearer context 222, and the BM-SC 10 that has received the MBMS registration response in S110 in the upper delivery node. The information about the eNB 40 included in the MBMS registration request is registered in the delivery node in the MBMS bearer context 222, and an MBMS registration response is returned to the MME 30 (S112). Here, the MBMS registration response includes TMGI and information related to the bearer required for this MBMS service.

  The MME 30 that has received the MBMS registration request from the eNB 40 in S104 registers information regarding the eNB 40 that has transmitted the MBMS registration request in the distribution node of the MBMS bearer context 322, and relates to the MBMS GW 20 that has transmitted the MBMS registration response in S112 to the higher distribution node. Information is registered and an MBMS registration response is returned (S114). At this time, the MBMS GW 20 having an MBMS registration response is included.

  The eNB 40 that has received the MBMS registration response from the MME in S114 registers information related to the MME 30 that has transmitted the MBMS registration response in S114 in the MBMS control device of the MBMS bearer context 422, and the MBMS registration included in S114 in the upper delivery node. Information on the MBMS GW 20 included in the response is registered.

  By forming a distribution list between the UE 50 and the BM-SC 10 by the above service announcement procedure, activation procedure, and MBMS registration procedure, the multicast distribution data of the service transmitted by the BM-SC 10 is delivered to the eNB 40. A route for doing this can be generated.

  Note that the nodes registered in the distribution list need not follow the above, and may be registered in advance by an operator. Here, FIG. 19A shows the MBMS bearer context 422 stored in the eNB 40 after the MBMS registration procedure. As shown in FIG. 19A, the MBMS bearer service identifier is “TMGI1”, the IP multicast address is “IP multicast address 1”, the mode is “multicast”, and the status information is “standby”. In the MBMS control apparatus, information of “MME30” is stored, and information of “MBMS GW20” is stored in the upper delivery node.

  In addition, although the process when MME30 received the MBMS registration cancellation | release request | requirement was demonstrated above, also when other MME receives a MBMS registration cancellation | release request from eNB40, the procedure similar to MME30 is performed.

  Similarly, in the MBMS GW, the processing when the MBMS GW 20 receives the MBMS registration request has been described. However, when the other MBMS GW receives the MBMS registration request from the MME 30, the same procedure as the MBMS GW 20 is performed.

  Similarly, in the BM-SC, the processing when the BM-SC 10 receives the MBMS registration request has been described. However, when other BM-SCs receive the MBMS registration request from the MBMS GW 20, the same as the BM-SC 10 is performed. Follow the procedure.

[1.3.4 Session start procedure]
Next, the session start procedure to be executed will be described with reference to FIG. Through the session start procedure, an MBMS bearer is established and preparations for data transmission are made. The BM-SC 10 specifies a service and transmits a session start request to the MBMS GW 20 (S300).

  Here, a session identifier for identifying the session is generated, and the generated session identifier and TMGI for designating the service are included in the session start request and transmitted. This starts the session start procedure.

  Also, a session identifier is registered in the corresponding MBMS bearer context 124 (identifiable by TMGI), and status information is registered actively.

  The session start request is transmitted to all MBMS GWs 20 registered in the delivery node of the MBMS bearer context 124.

  The MBMS GW 20 receives the session start request, transmits a session start response to the BM-SC 10, and responds (S302). In addition, the session identifier is registered in the corresponding MBMS bearer context 222 (identifiable by TMGI), and the state information is registered actively. Information regarding the eNB 40 is registered in the distribution node. Here, a plurality of eNBs are registered in the distribution node.

  The eNB 40, which is a distribution node to be registered, may be registered in advance by an operator, or a list of distribution nodes (eNB 40, etc.) for each MBMS service area registered through the MBMS registration procedure is used. The corresponding eNB 40 may be selected based on the MBMS service area identifier included in the session start request transmitted from the BM-SC 10.

  Through the above procedure, an MBMS bearer that is a delivery path that secures communication quality for multicast data delivery between the BM-SC 10 and the MBMS GW 20 is established.

  Further, in order to perform transmission using the MBMS bearer by IP multicast communication, an IP multicast address is assigned to the service and registered in the MBMS bearer context 222.

  The MBMS GW 20 transmits a session start request (S304) to the MME 30 registered in the MBMS controller of the MBMS bearer context 222. In order to specify a service, the session start request includes TMGI, a session identifier, and an IP multicast address.

  The session start request is transmitted to all MMEs registered in the MBMS control device of the MBMS bearer context 222.

  The MME 30 receives the session start request, transmits a session start response to the MBMS GW 20, and responds (S310). Also, an MBMS bearer context 322 is generated, TMGI, a session identifier, and an IP multicast address are registered, and status information is registered actively.

  Information regarding the eNB 40 is registered in the distribution node. Here, a plurality of eNBs are registered in the distribution node.

  The MME 30 transmits a session start request (S306) to the eNB 40 registered in the delivery node of the MBMS bearer context 322. The session start request includes TMGI, a session identifier, and an IP multicast address.

  In addition, the session start request is transmitted to all eNBs registered in the delivery node of the MBMS bearer context 322.

  The eNB 40 receives the session start request, transmits a session start response to the MME 30, and responds (S308). In addition, the MBMS bearer context 422 is generated, the TMGI, the session identifier, and the IP multicast address are registered, and the state information is registered actively.

  Furthermore, information regarding the MBMS GW 20 that is the higher-level delivery node that transmitted the request is registered.

  Through the above procedure, an MBMS bearer that is a delivery path that secures communication quality for multicast data delivery between the MBMS GW 20 and the eNB 40 is established.

  Here, the eNB 40 performs an IP multicast participation process (S314). The eNB 40 refers to the MBMS bearer context 422 and makes a participation request using an IP multicast address corresponding to the service. Specifically, an IGMP Membership Report message is transmitted when communicating with IPv4, and an MLD Membership Report is transmitted when communicating with IPv6.

  Thereby, an IP multicast packet is delivered to the MBMS bearer established by BM-SC10, MBMS GW20, and eNB40. The multicast data is transmitted from the BM-SC 10 to the eNB 40 by IP multicast.

  Further, the eNB 40 performs radio resource allocation processing to be transmitted to the UE 50 and registers information for delivery in the radio frame information 424. Specifically, mode information indicating whether the radio frame mode is the multicast mode or the unicast mode is registered for each service identifier. TMGI can be used as the service identifier.

  In addition, when transmitting in the multicast mode, the frame is transmitted to an unspecified number of UEs, so it is not necessary to retain UE information, but when transmitting in the unicast mode, a radio frame is transmitted to each UE. In this case, in the case of the activation procedure, the IMSI is held as UE information and registered as UE information.

  Through the above service announcement procedure, MBMS registration procedure, and session start procedure, a communication path is established between the UE 50 and the BM-SC 10, and the data transmitted by the BM-SC 10 can be delivered to the eNB 40.

  Finally, the eNB 40 transmits an MBMS start notification to the UE 50 (S316). The start notification includes a service identifier for identifying the service. Thereby, UE50 starts reception of multicast data.

Here, various service identifiers are used. For example,
(1) TMGI registered in the MBMS bearer context 422
(2) Session ID registered in MBMS bearer context 422
(3) Other identifiers (for example, identifiers that can identify the MBMS bearer service between the eNB 40 and the UE 50)
Etc. In the present embodiment, the TMGI of (1) is used. However, in the case of (3), the service identifier and the MBMS bearer context 422 are registered in association with each other.

  In the above example, the processing when the MBMS GW 20 receives a session start request has been described. However, when another MBMS GW receives a session start request from the BM-SC 10, the same procedure as the MBMS GW 20 is performed.

  Similarly, in the MME, the processing when the MME 30 receives the session start request has been described. However, when other MMEs receive the session start request from the MBMS GW, the same procedure as the MME 30 is performed.

  Similarly, in the eNB, the process when the eNB 40 receives a session start request has been described, but the same procedure as the eNB 40 is performed when another eNB receives a session start request from the MME.

  Similarly, in the UE, the process when the UE 50 receives the session start request has been described. However, when other UEs receive the session start request from the eNB, the same procedure as the UE 50 is performed.

  Thereby, the multicast data distributed by the BM-SC 10 is hierarchically delivered to the UE via a plurality of MBMS GWs, MMEs, and eNBs.

  Here, FIG. 19B illustrates the MBMS bearer context 422 held by the eNB 40 after the session start procedure. As shown in FIG. 19B, “TMGI1” is the MBMS bearer service identifier, “session 1” is the session identifier, “IP multicast address 1” is the IP multicast address, and “multicast” is the mode. However, “active” is stored in the status information, “MME30” information is stored in the MBMS control apparatus, and “MBMS GW20” is stored in the upper distribution node. Compared with FIG. 19A, the session identifier is newly stored, and the state information is changed from standby to active.

[1.3.5 MBMS deregistration procedure and session stop processing]
Next, the MBMS deregistration procedure and the session stop procedure will be described with reference to FIG.

  In this embodiment, the session stop procedure is performed after the MBMS deregistration procedure. However, the order is not limited to this order, and the MBMS deregistration procedure may be performed after the session stop procedure. In the MBMS deregistration procedure, an example of starting based on the counting procedure result in the eNB 40 will be described. However, the start trigger is not limited to this, and the procedure can be started from the eNB 40.

  First, the counting procedure that triggers the MBMS deregistration procedure will be described. The procedure is performed between the eNB 40 and the UE 50. eNB40 transmits the message which confirms whether it receives service including a service identifier with respect to UE50 connected.

  Here, although eNB40 transmits the message which confirms whether it receives service addressed to UE50 registered into the radio | wireless frame information 424, you may transmit to all UE which connects.

Here, various service identifiers are used. For example,
(1) TMGI registered in the MBMS bearer context 422
(2) Session ID registered in MBMS bearer context 422
(3) Other identifiers (for example, identifiers that can identify the MBMS bearer service between the eNB 40 and the UE 50)
Etc. can be used. In the present embodiment, description will be made assuming that TMGI of (1) is used.

  Thereby, eNB40 can acquire the number of UE50 which needs to receive multicast data actually. The obtained number of UEs 50 is registered in the UE counter of the MBMS bearer context 422. The number of UEs 50 that actually need to receive multicast data may be, for example, the number of UEs 50 connected to the base station apparatus, or the number of UEs 50 participating in the multicast group among these UEs 50. . Furthermore, the number may be the number excluding the UE 50 that is not temporarily viewed by detecting a state in which the user has not activated the viewing application, or the UE 50 that notifies the user that reception is necessary. You may register by counting.

  The confirmation message from the eNB 40 may be transmitted without including the service identifier. In that case, if there is a service that needs to be received, the UE 50 responds including a service identifier. The service identifier can be selected by, for example, acquiring and storing it in the service announcement procedure.

  The eNB 40 that has received the response identifies the MBMS bearer context from the service identifier, and registers the number of UEs 50 that have responded in the UE counter. Thus, the counting procedure (S400) is completed.

  The eNB 40 performs a counting process for confirming whether the UE counter of the MBMS bearer context 422 has become zero (S402). When the UE counter reaches zero, the eNB 40 cancels MBMS registration (S404). The eNB 40 refers to the TMGI that is the target of the counting process, and deletes the UE 50 from the information on the distribution node of the corresponding MBMS bearer context 422.

  Subsequently, the eNB 40 performs a session stop process (S406). Here, when the bearer resource is allocated to the service identified by TMGI between the UE 50 and the eNB 40, the eNB 40 releases the bearer resource. Further, when the status information in the MBMS bearer context 422 is “active”, the state is set to “standby”.

  Next, the eNB 40 transmits an MBMS deregistration request for the corresponding service to the MME 30 (S408). The MME to be transmitted is solved by the information of the MBMS control device of the MBMS bearer context 422, and is transmitted to the MME 30 in this embodiment. The eNB 40 transmits to the MME 30 an MBMS deregistration request including the TMGI registered in the MBMS bearer context 422, the service identifier, the session identifier, and the information of the MBMS GW 20 that is the higher delivery node.

  The MME 30 that has received the MBMS deregistration request performs MBMS deregistration processing (S410). The MME 30 refers to the TMGI included in the MBMS deregistration request received from the eNB 40 and deletes the eNB 40 from the distribution node information of the corresponding MBMS bearer context 322.

  Subsequently, the MME 30 performs a session stop process (S412). Here, when the status information in the MBMS bearer context 322 is “active”, it is set to “standby”.

  Next, the MME 30 transmits an MBMS registration cancellation response to the eNB 40 (S414). The eNB 40 that has received the MBMS deregistration response deletes the MBMS bearer context 422 corresponding to the TMGI included in the MBMS deregistration request.

  The MME 30 transmits an MBMS deregistration request for the corresponding service to the MBMS GW 20 (S416). The MBMS GW to be transmitted is resolved by the information of the higher delivery node (MBMS GW 20) of the MBMS bearer context 422, and is transmitted to the MBMS GW 20 in this embodiment. The MME 30 transmits an MBMS deregistration request including the TMGI registered in the MBMS bearer context 422, the service identifier, the session identifier, and the information of the eNB 40 that has received the MBMS deregistration request to the MBMS GW 20.

  The MBMS GW 20 that has received the MBMS deregistration request performs MBMS deregistration processing (S418). The TMGI included in the MBMS deregistration request received from the MME 30 is referred to, and the eNB 40 information included in S416 is deleted from the distribution node information of the corresponding MBMS bearer context 222.

  Subsequently, the MBMS GW 20 performs a session stop process (S420). Here, when a bearer resource is set for a service identified by TMGI between the MME 30 and the MBMS GW 20, the MBMS GW 20 releases the bearer resource. Further, when the status information in the MBMS bearer context is “active”, it is set to “standby”.

  Next, the MBMS GW 20 transmits an MBMS deregistration response to the MME 30 (S422). The MME 30 that has received the MBMS deregistration response deletes the MBMS bearer context 222 corresponding to the TMGI included in the MBMS deregistration request transmitted in S416.

  MBMS GW20 confirms eNB of the information of the delivery node in MBMS bearer context 222, and completes this process, when eNB is registered.

  On the other hand, when all the eNB information is deleted from the delivery node information in the MBMS bearer context 222 (EMPTY), the MBMS GW 20 sends an MBMS deregistration request for the corresponding service to the BM-SC 10. (S424).

  The BM-SC to be transmitted is resolved by the BM-SC information of the MBMS bearer context 222, and is transmitted to the BM-SC 10 in this embodiment. The MBMS GW 20 transmits an MBMS deregistration request including TMGI registered in the MBMS bearer context 222, a service identifier, a session identifier, and information on the MBMS GW 20 to the BM-SC 10.

  The BM-SC 10 that has received the MBMS deregistration request performs MBMS deregistration processing (S426). The TMGI included in the MBMS deregistration request received from the MBMS GW 20 is referred to, and the information of the MBMS GW 20 is deleted from the information of the delivery node of the corresponding MBMS bearer context 124.

  Subsequently, the BM-SC 10 performs a session stop process (S428). Here, when a bearer resource is set for the service identified by TMGI between the MBMS GW 20 and the BM-SC 10, the BM-SC 10 releases the bearer resource. Further, when the status information in the MBMS bearer context 124 is “active”, the state is set to “standby”.

  Next, the BM-SC 10 transmits an MBMS registration cancellation response to the MBMS GW 20 (S430). The MBMS GW 20 that has received the MBMS deregistration response deletes the MBMS bearer context 124 corresponding to the TMGI included in the MBMS deregistration request transmitted in S424. Further, when the MBMS UE context 226 corresponding to the TMGI included in the MBMS deregistration request is held, the MBMS GW 20 may delete all the MBMS UE contexts 226 including the TMGI.

  The BM-SC 10 deletes the MBMS bearer context 124 identified by TMGI that has requested MBMS deregistration. The BM-SC 10 confirms the MBMS GW 20 of the information on the delivery node in the MBMS bearer context 124, and completes this process when the MBMS GW 20 is registered.

  On the other hand, the BM-SC 10 deletes the MBMS bearer context 124 when all MBMS GWs have been deleted from the distribution nodes in the MBMS bearer context 124 (EMPTY).

  Through the above procedure, the eNB 40 can efficiently cancel the MBMS registration using the counting function. The MBMS deregistration procedure of the eNB 40 can detect that the distribution of the multicast service for each MBMS bearer that can be identified by TMGI or the like is unnecessary by the counting procedure.

  Furthermore, it can be started by detecting that the user is not viewing, as in the case where the user is not viewing because the application is turned off. Then, the MBMS deregistration procedure can be started with this detection as a trigger.

  FIG. 22A shows each node that exchanges control information before the MBMS deregistration procedure and session stop processing in a hierarchical structure, and FIG. 22B shows the exchange of control information after the MBMS deregistration procedure and session stop processing. Each node that performs is shown in a hierarchical structure.

  In FIG. 22, eNB1 and eNB2 each perform counting processing (S402) for an arbitrary service. In eNB2, the UE counter does not become zero, and in eNB1, the UE counter becomes zero. Indicates that session processing has started.

  The eNB 1 that has decided to perform the MBMS deregistration procedure and the session stop process performs the MBMS deregistration process (S404). That is, UE connected to eNB1 is deleted from the delivery node of MBMS bearer context 422.

  Moreover, eNB1 performs a session stop process (S406). That is, when a bearer resource is allocated between UEs connected to eNB1, the bearer resource is released.

  Subsequently, eNB1 transmits an MBMS registration cancellation request to MME1 (S408). MME1 performs MBMS deregistration processing based on the MBMS deregistration request from eNB1 (S410). That is, the eNB is deleted from the delivery node of the MBMS bearer context 322 held by the MME 1.

  Subsequently, the MME performs a session stop process (S412). That is, when the status information in the MBMS bearer context is “active”, it is changed to “standby”. Subsequently, an MBMS deregistration request is transmitted to the MBMS GW 1 (S416). The MBMS GW1 performs MBMS deregistration processing based on the MBMS deregistration request from the MME1 (S418). That is, eNB1 is deleted from the delivery node of MBMS bearer context 222 held by MBMS GW1.

  Subsequently, the MBMS GW1 performs a session stop process (S420). That is, when a bearer resource is allocated between MBMS GW1 and eNB1, the bearer resource is released. Here, since the eNB 3 is registered in the delivery node of the MBMS bearer context 222 in the MBMS GW1, the MBMS deregistration procedure is completed. It can be seen that eNB1 is deleted from the control information exchange destination of MBMS GW1 in the hierarchical structure for exchanging control information after the MBMS deregistration procedure and the session stop process in FIG. Here, eNB3 did not perform the MBMS deregistration procedure and the session stop procedure process because eNB3 confirmed that UE3 received the data.

  FIG. 23A shows an MBMS deregistration procedure corresponding to FIG. 22A and a distribution tree before the session stop process, and FIG. 23B shows an MBMS deregistration procedure corresponding to FIG. The distribution tree after session stop processing is shown. The distribution tree indicates a route through which data is distributed from the BM-SC 10 to the UE via the MBMS GW 20 and the eNB 40. Compared to FIG. 23 (a), it can be seen that in FIG. 23 (b), UE1 and UE2 are deleted, and eNB1 and eNB2 are deleted. As a result, the data is distributed only to the eNB 3 via the MBMS GW 1 and further distributed only to the UE 3 from the eNB 3.

  In the above procedure, the deactivation process (deregistration of service registration by the UE) was not performed. When the eNB 40 can detect that the UE has requested to receive the service using the counting function or the like, the service reception can be resumed without performing the activation process by the UE.

  On the other hand, using the counting function of eNB 40, MBMS deregistration was triggered when the UE counter became zero, but after performing the deactivation procedure, all MBMS UE contexts in a certain service were deleted The MBMS deregistration procedure may be performed using this as a trigger. When the deactivation registration procedure is performed, it is removed from the registration of the BM-SC service, and the billing process can be stopped.

  In this way, each device recognizes that the service to be registered is the multicast mode, and holds it in the MBMS bearer context. Specifically, the BM-SC 10 registers with the MBMS bearer context 124 mode as multicast, the MBMS GW 20 registers with the MBMS bearer context 222 mode as multicast, the MME 30 registers with the MBMS bearer context 322 mode as multicast, The eNB 40 registers with the mode of the MBMS bearer context 422 as multicast.

  Accordingly, when determining MBMS deregistration, the MBMS bearer context 124 in the BM-SC 10, the MBMS bearer context 222 in the MBMS GW 20, the MBMS bearer context 322 in the MME 30, and the MBMS bearer context 422 in the eNB 40 are referred to, respectively. In some cases, MBMS registration can be canceled.

  Furthermore, in the above case, when the state information in the MBMS bearer context 124 in the BM-SC 10, the MBMS bearer context 222 in the MBMS GW 20, the MBMS bearer context 322 in the MME 30, and the MBMS bearer context 422 in the eNB 40 is active, the state information Can be changed to standby, and session stop, multicast data distribution, and reception stop.

  Specifically, in the eNB 40, when the multicast MBMS deregistration request is transmitted (S408), if the mode of the MBMS bearer context 422 is multicast, the transmission of the MBMS deregistration request, the MBMS deregistration process, the release of the MBMS bearer, Multicast data distribution and reception stop.

  In the MME 30, when the multicast MBMS deregistration request is transmitted (S416), if the mode of the MBMS bearer context 322 is multicast, the MBMS deregistration request is transmitted, the MBMS deregistration process, the release of the MBMS bearer, multicast data distribution, and reception stop. I do.

  In the MBMS GW 20, when a multicast MBMS deregistration request is transmitted (S424), if the mode of the MBMS bearer context 222 is multicast, the MBMS deregistration request is transmitted, the MBMS bearer is released, multicast data is distributed, and reception is stopped.

  When receiving the multicast MBMS deregistration request (S424), if the mode of the MBMS bearer context 222 is multicast, the BM-SC 10 performs MBMS deregistration processing, MBMS bearer release, and multicast data distribution stop.

  Conventionally, it has been stipulated that the eNB 40, which is a base station apparatus, takes the initiative to cancel MBMS registration, but the necessity of reception of the mobile station apparatus by the base station apparatus without performing the activation procedure and the deactivation procedure. If it is confirmed that there is no need for distribution, the MBMS registration could not be canceled efficiently. In this embodiment, the base station apparatus can perform the MBMS deregistration procedure and the session stop procedure based on the result of necessity of reception of the mobile station apparatus without performing the activation procedure and the deactivation procedure. become. In other words, MBMS deregistration and session suspension can be performed while maintaining activation of the mobile station apparatus.

  Further, only by the MBMS deregistration procedure, it is possible to delete the delivery destination device from the delivery destination list and to release the resources that were conventionally performed by stopping the session. Furthermore, the session stop procedure required for session stop can be omitted and simplified. If the session is not stopped when canceling the MBMS registration, the session is not started unless the MBMS registration is performed again by canceling the MBMS registration and stopping the session.

  For example, in the conventional method, only a procedure for stopping a session from a distribution source to a distribution destination is defined, and a session stop cannot be requested from the distribution destination to the distribution source. That is, the session stop cannot be requested from the base station apparatus (eNB) to the distribution source. Furthermore, even if the base station apparatus (eNB) expands to request a session stop from the distribution source, the apparatus that receives the session stop request can stop the distribution and temporarily release the resource, but the distribution node is deleted. Do not do.

  Therefore, for example, when 1) a session is started and 2) only the session is stopped by eNB, 3) after all sessions are stopped by BM-SC, 4) BM-SC When all the sessions are resumed, communication resources are allocated to all nodes (MBMS GW, eNB) included in the distribution list, and even the session stopped by the eNB is resumed. There was a problem.

  However, even when the distribution destination device is updated from the distribution list by the MBMS deregistration procedure and the session is resumed led by BM-SC as in 4), unnecessary sessions are not started.

  According to the present embodiment, since the session is not started unnecessarily, the exchange of control information required when starting the session can be reduced, and communication resources required for the session start procedure are used inefficiently. Thus, it is possible to effectively use communication resources.

  If the session is not started, communication resources are not used unnecessarily, and communication resources can be used efficiently. In addition, since the session is not started unnecessarily, the exchange of control information required when starting the session can be reduced, and the communication resource required for the session start procedure is not used inefficiently. Can be effectively utilized.

[2. Second Embodiment]
Next, a second embodiment will be described. In the second embodiment, an MBMS registration procedure is performed using a counting function in a system targeted for broadcast distribution.

  In the first embodiment, the MBMS registration procedure is started by performing the activation procedure and performing service registration from the UE. However, in the case of broadcast, the MBMS registration procedure may be performed without performing the activation procedure. It becomes possible. Here, in the broadcast distribution, unlike the multicast distribution, since the activation procedure is not performed, the MBMS UE context is not generated.

  The system configuration and each device configuration in the second embodiment are the same as the system configuration and each device configuration shown in the first embodiment, and a description thereof will be omitted.

  Note that, in a system targeted for broadcast distribution, service registration is not requested from the UE 50, and an activation procedure does not occur. Therefore, it differs in that an MBMS UE context is not created in each of the eNB 40, the MME 30, the MBMS GW 20, and the BM-SC 10.

  Further, the distribution of the “multicast service” has been described in the first embodiment, but the second embodiment will be described by applying to the “broadcast service”. For example, the UE counter in the second embodiment is the number of UEs that need to receive the MBMS bearer service broadcast data. This is based on the number counted by the counting function of the base station apparatus (eNB 40), and may be the number of UEs 50 connected to the eNB 40, for example. Furthermore, it is the number excluding UE 50 that is not viewed temporarily by detecting the terminal (UE 50) that the user is actually viewing, that is, the state in which the user has not activated the viewing application. The number of UEs 50 that notify the user that reception is necessary may be used.

[2.1 Process flow]
[2.1.1 Service announcement procedure]
The service announcement procedure in this embodiment will be described. As illustrated in FIG. 24, the BM-SC 10 first performs a service announcement procedure for the UE 50. The BM-SC 10 notifies the UE 50 of services that can be distributed (S500). The UE 50 thereby detects the broadcast service.

  The BM-SC 10 notifies the UE 50 by notifying the service identifier that the service managed by the MBMS service DB 122 can be distributed. Furthermore, information describing a service such as a program title, a content title, and a distribution start time may be added and notified.

Here, various service identifiers are used. For example,
(1) TMGI
(2) Other identifiers (for example, other identifiers that can be set by the operator to identify the MBMS bearer service)
Etc. are available. In the present embodiment, description will be made assuming that TMGI of (1) is used.

  In addition, various methods are conceivable as specific notification methods. For example, SMS (Short Message Service) or the like is used to notify the UE 50 that can be distributed in advance or an unspecified number of UEs 50. Or the information may be posted on the WEB, and the UE 50 may acquire the information by accessing the WEB server.

[2.1.2 MBMS registration procedure]
Next, the MBMS registration procedure will be described. The MBMS registration procedure in the MBMS service is shown in FIG. A communication path from the BM-SC 10 to the UE 50 is established by the MBMS registration procedure.

  For establishment of the communication path, an MBMS bearer context 124 in the BM-SC 10, an MBMS bearer context 222 in the MBMS GW 20, an MBMS bearer context 322 in the MME 30, and an MBMS bearer context 422 in the eNB 40 are respectively generated, and the MBMS bearer context 124 in the BM-SC 10. The MBMS bearer context 222 in the MBMS GW 20, the MBMS bearer context 322 in the MME 30, and the MBMS bearer context 422 in the eNB 40 need to be registered in the respective distribution node lists. The MBMS bearer context 124, the MBMS bearer context 222, the MBMS bearer context 322, and the MBMS bearer context 422 can be identified by TMGI.

  That is, MBMS GW20 is registered in the delivery node in BM-SC10, and eNB40 is registered in the delivery node in MBMS GW20, respectively. In addition, a plurality of downlink nodes may be registered in each distribution node in the BM-SC 10, the MBMS GW 20, and the eNB 40.

  First, the eNB 40 starts the MBMS registration procedure by detecting the UE 50 that receives the MBMS service. Here, there are various detection methods for the UE 50 from which the eNB 40 receives the MBMS service. For example, the UE 50 that receives the MBMS service may be detected using a counting function in the eNB 40. In other words, the UE 50 can request MBMS registration to the eNB 40 by the counting procedure.

  First, eNB40 transmits the message which confirms whether it receives service including a service identifier with respect to UE50 connected.

  Here, although eNB40 transmits the message which confirms whether it receives service addressed to UE50 registered into the radio | wireless frame information 424, you may transmit to all UE which connects.

Here, various service identifiers are used. For example,
(1) TMGI registered in the MBMS bearer context 422
(2) Session ID registered in MBMS bearer context 422
(3) Other identifiers (for example, identifiers that can identify the MBMS bearer service between the eNB 40 and the UE 50)
Etc. are available. In the present embodiment, description will be made assuming that TMGI of (1) is used.

  Thereby, eNB40 can acquire the number of UE50 which needs to receive broadcast data actually. The obtained number of UEs 50 is registered in the UE counter of the MBMS bearer context 422. The number of UEs 50 that actually need to receive broadcast data may be the number of UEs 50 connected to the eNB 40, for example. Furthermore, the number may be the number excluding the UE 50 that is not temporarily viewing by detecting a state in which the user has not activated the viewing application, or the UE 50 that notifies the user that reception is necessary. You may register by counting.

  The confirmation message from the eNB 40 may be transmitted without including the service identifier. In that case, if there is a service that needs to be received, the UE 50 responds including a service identifier.

  The service identifier can be selected by, for example, acquiring and storing it in the service announcement procedure.

  The eNB 40 that has received the response identifies the MBMS bearer context from the service identifier, and registers the number of UEs 50 that have responded in the UE counter. Thus, the counting procedure is completed (S502). If it is determined that the UE counter is not 0 as a result of the counting procedure, the MBMS registration procedure may be started.

  Furthermore, the trigger for the eNB 40 to start the MBMS registration procedure may be performed at any timing other than the above, depending on the operator's policy or the like. In addition to the above, it may be performed at an arbitrary timing according to an operator's policy or the like when an eNB (base station apparatus) is installed or started.

  Next, the eNB 40 transmits an MBMS registration request for MBMS registration of the service designated by the UE to the MME 30 (S504). Here, the eNB 40 includes the TMGI and IP multicast address in the MBMS registration request.

  The MME 30 that has received the MBMS registration request from the eNB 40 transmits the MBMS registration request to the MBMS GW 20 (S506). Here, the MBMS registration request includes the eNB 40, the TMGI, and the IP multicast address that have made the MBMS registration request.

  The MME 30 generates an MBMS bearer context 322 corresponding to the service. The MBMS bearer context 322 includes TMGI that identifies the service. Furthermore, the state information of the bearer resource in the MBMS bearer context 322 is set to “standby”, and the eNB 40 is added to the distribution node.

  MBMS GW20 which received the MBMS registration request from MME30 produces | generates the MBMS bearer context 222, and transmits a MBMS registration request to BM-SC10 (S508). Here, the state information of the bearer resource in the MBMS bearer context is set to “standby”.

  The BM-SC 10 that has received the MBMS registration request from the MBMS GW 20 registers the information of the MBMS GW 20 that has transmitted the MBMS registration request to the MBMS bearer context in the distribution node, and returns an MBMS registration response (S510). Here, the MBMS registration response includes TMGI and the bearer capacity required for the service.

  The MBMS GW 20 that has received the MBMS registration request from the MME 30 in S506 registers the eNB 40 included in the MBMS registration request in the delivery node of the MBMS bearer context 222, and the BM-SC10 included in the MBMS registration response in S510 in the higher delivery node. And an MBMS registration response is returned (S512). Here, the information regarding TMGI and the bearer required for this MBMS service is included in the MBMS registration response.

  MME30 which received the MBMS registration request from eNB40 in S504 registers the information of eNB40 which transmitted the MBMS registration request to the delivery node of MBMS bearer context 322, and transmits a MBMS registration response (S514). Here, the MBMS registration response includes the information of the MBMS GW 20 that made the MBMS registration response in S512.

  The eNB 40 that has received the MBMS registration response from the MME 30 in S514 registers information related to the MME 30 that has transmitted the MBMS registration response in S514 in the MBMS control device of the MBMS bearer context 422, and the MBMS registration response to the upper delivery node of the MBMS bearer context 422. The information of MBMS GW20 included in is registered.

  By forming a distribution list between the UE 50 and the BM-SC 10 by the service announcement procedure and the MBMS registration procedure described above, the broadcast distribution data of the service transmitted by the BM-SC 10 generates a route for distribution to the eNB 40. be able to. The node registered in the distribution node does not need to follow the above, and may be registered in advance by an operator.

  Here, FIG. 25A shows the MBMS bearer context 422 held by the eNB 40 after the MBMS registration procedure. As shown in FIG. 25A, the MBMS bearer service identifier is “TMGI1”, the IP multicast address is “IP multicast address 1”, the mode is “broadcast”, and the status information is “standby”. “MME30” is stored in the MBMS control device, and “MBMS GW20” is stored in the upper delivery node.

  In the above example, the processing when the MME 30 receives the MBMS registration cancellation request has been described. However, when the other MME receives the MBMS registration cancellation request from the eNB 40, the same procedure as the MME 30 is performed.

  Similarly, in the MBMS GW 20, the processing when the MBMS GW 20 receives the MBMS registration request has been described, but when the other MBMS GW receives the MBMS registration request from the MME, the same procedure as the MBMS GW 20 is performed.

  Similarly, in the BM-SC 10, the processing when the BM-SC 10 receives the MBMS registration cancellation request has been described. However, when other BM-SCs receive the MBMS registration cancellation request from the GGNS, Follow the same procedure.

[2.1.3 Session start procedure]
Next, a session start procedure to be executed will be described with reference to FIG. Through the session start procedure, an MBMS bearer is established and preparations for data transmission are made. The BM-SC 10 specifies a service and transmits a session start request to the MBMS GW 20 (S600). Here, a session identifier for identifying the session is generated, and the generated session identifier and TMGI for designating the service are included in the session start request and transmitted. This starts the session start procedure.

  In the corresponding MBMS bearer context 124 (identifiable by TMGI), a session identifier is registered, and status information is registered as “active”.

  The session start request is transmitted to all MBMS GWs registered in the delivery node of the MBMS bearer context 124.

  The MBMS GW 20 receives the session start request, transmits a session start response to the BM-SC 10, and responds (S602). Also, the session identifier is registered in the corresponding MBMS bearer context 222 (identifiable by TMGI), and the status information is registered as “active”. Information related to the MME 30 is registered in the MBMS control apparatus, and information related to the eNB 40 is registered in the distribution node. Here, a plurality of eNBs are registered in the distribution node.

  The eNB 40, which is a distribution node to be registered, may be registered in advance by an operator, or a list of distribution nodes (eNB 40, etc.) for each MBMS service area registered through the MBMS registration procedure is used. The corresponding eNB 40 may be selected based on the MBMS service area identifier included in the session start request transmitted from the BM-SC 10.

  Through the above procedure, an MBMS bearer, which is a delivery path that secures communication quality for broadcast data distribution between the BM-SC 10 and the MBMS GW 20, is established.

  Further, in order to perform transmission using the MBMS bearer by IP multicast communication, an IP multicast address is assigned to the service and registered in the MBMS bearer context 222.

  The MBMS GW 20 transmits a session start request (S604) to the MME 30 registered in the distribution node of the MBMS bearer context 222. In order to specify a service, the session start request includes TMGI, a session identifier, and an IP multicast address.

  Further, the session start request is transmitted to all MMEs registered in the delivery node of the MBMS bearer context 222.

  The MME 30 receives the session start request, transmits a session start response to the MBMS GW 20, and responds (S610). Also, the TMGI, the session identifier, and the IP multicast address are registered in the MBMS bearer context 322, and the status information is registered as “active”.

  Information regarding the eNB 40 is registered in the distribution node. Here, a plurality of eNBs are registered in the distribution node.

  The MME 30 transmits a session start request (S606) to the eNB 40 registered in the distribution node of the MBMS bearer context 322. The session start request includes TMGI, a session identifier, and an IP multicast address.

  In addition, the session start request is transmitted to all eNBs registered in the delivery node of the MBMS bearer context 322.

  The eNB 40 receives the session start request, transmits a session start response to the MME 30, and responds (S608). Also, an MBMS bearer context 422 is generated, TMGI, a session identifier, an IP multicast address are registered, and status information is registered as “active”.

  Through the above procedure, an MBMS bearer, which is a delivery path that secures communication quality for broadcast data delivery, between the MBMS GW 20 and the eNB 40 is established.

  Thereby, an IP multicast packet is delivered to the MBMS bearer established by BM-SC10, MBMS GW20, and eNB40. Broadcast data is transmitted from the BM-SC 10 to the eNB 40 by IP multicast.

  Here, the eNB 40 performs IP multicast participation processing (S614). The eNB 40 refers to the MBMS bearer context 422 and makes a participation request using an IP multicast address corresponding to the service. Specifically, an IGMP Membership Report message is transmitted when communicating with IPv4, and an MLD Membership Report is transmitted when communicating with IPv6.

  Further, the eNB 40 performs radio resource allocation processing to be transmitted to the UE 50 and registers information for delivery in the radio frame information 424. Specifically, mode information indicating whether the radio frame mode is the broadcast mode or the unicast mode is registered for each service identifier. TMGI can be used as the service identifier.

  Finally, the eNB 40 transmits an MBMS start notification to the UE 50 (S616). The start notification includes a service identifier for identifying the service. Thereby, UE50 starts reception of broadcast data.

Here, various service identifiers are used. For example,
(1) TMGI registered in the MBMS bearer context 422
(2) Session ID registered in MBMS bearer context 422
(3) Other identifiers (for example, identifiers that can identify the MBMS bearer service between the eNB 40 and the UE 50)
Etc. In the present embodiment, the TMGI of (1) is used. However, in the case of (3), the service identifier and the MBMS bearer context 422 are registered in association with each other.

  In the above example, the processing when the MBMS GW 20 receives a session start request has been described. However, when another MBMS GW receives a session start request from the BM-SC 10, the same procedure as the MBMS GW 20 is performed.

  Similarly, in the MME, the processing when the MME 30 receives the session start request has been described. However, when other MMEs receive the session start request from the MBMS GW, the same procedure as the MME 30 is performed.

  Similarly, in the eNB, the process when the eNB 40 receives a session start request has been described, but the same procedure as the eNB 40 is performed when another eNB receives a session start request from the MME.

  Similarly, in the UE, the process when the UE 50 receives the session start request has been described. However, when other UEs receive the session start request from the eNB, the same procedure as the UE 50 is performed.

  Thereby, the broadcast data distributed by the BM-SC 10 is hierarchically delivered to the UE via the plurality of MBMS GWs and eNBs.

  Here, the MBMS bearer context 422 held by the eNB 40 after the session start procedure is shown in FIG. As shown in FIG. 25 (b), the MBMS bearer service identifier is “TMGI1”, the session identifier is “session 1”, the IP multicast address is “IP multicast address 1”, and the mode is “broadcast”. However, “active” is stored in the status information, “MME30” information is stored in the MBMS control device, and “MBMS GW20” information is stored in the upper distribution node. Compared with FIG. 25A, the session identifier is newly stored, and the status information is changed from “standby” to “active”.

[2.1.4 MBMS deregistration procedure and session stop procedure]
Next, the MBMS deregistration procedure and the session stop procedure will be described with reference to FIG.

  In the present embodiment, the session stop process is performed after the MBMS deregistration process. However, the order is not limited to this order, and the MBMS deregistration process procedure may be performed after the session stop process. In the MBMS deregistration procedure, an example of starting based on the counting procedure result in the eNB 40 will be described, but the start trigger is not limited to this, and the procedure can be started from the eNB 40.

  First, the counting procedure that triggers the MBMS deregistration procedure will be described. The procedure is performed between the eNB 40 and the UE 50. eNB40 transmits the message which confirms whether it receives service including a service identifier with respect to UE50 connected.

  Here, although eNB40 transmits the message which confirms whether it receives service addressed to UE50 registered into the radio | wireless frame information 424, you may transmit to all UE which connects.

Here, various service identifiers are used. For example,
(1) TMGI registered in the MBMS bearer context 422
(2) Session ID registered in MBMS bearer context 422
(3) Other identifiers (for example, identifiers that can identify the MBMS bearer service between the NB 40 and the UE 50)
Etc. are available. In the present embodiment, description will be made assuming that TMGI of (1) is used.

  Thereby, eNB40 can acquire the number of UE50 which needs to receive multicast data actually. The obtained number of UEs 50 is registered in the UE counter of the MBMS bearer context 422.

  The confirmation message from the eNB 40 may be transmitted without including the service identifier. In that case, if there is a service that needs to be received, the UE 50 responds including a service identifier.

  The service identifier can be selected by, for example, acquiring and storing it in the service announcement procedure.

  The eNB 40 that has received the response identifies the MBMS bearer context from the service identifier, and registers the number of UEs 50 that have responded in the UE counter. Thus, the counting procedure (S700) is completed.

  The eNB 40 performs a counting process for confirming whether the UE counter of the MBMS bearer context 422 has become zero (S702). When the UE counter becomes zero, the eNB 40 performs the MBMS deregistration process for the corresponding service (S704). The eNB 40 refers to the TMGI that is the target of the counting process, and deletes the UE 50 from the distribution node of the corresponding MBMS bearer context 422.

  Subsequently, the eNB 40 performs a session stop process (S706). Here, when the bearer resource is allocated to the service identified by TMGI between the UE 50 and the eNB 40, the eNB 40 releases the bearer resource. Further, when the status information in the MBMS bearer context 422 is “active”, the state is set to “standby”.

  Next, the eNB 40 transmits an MBMS deregistration request for the corresponding service to the MME 30 (S708). The MME to be transmitted is resolved by the MME information of the MBMS bearer context 422, and is transmitted to the MME 30 in this embodiment.

  Here, the eNB 40 transmits an MBMS deregistration request including the TMGI registered in the MBMS bearer context 422, a service identifier, a session identifier, and information on the eNB 40 to the MME 30.

  The MME 30 that has received the MBMS deregistration request performs MBMS deregistration processing (S710). The MME 30 refers to the TMGI included in the MBMS deregistration request received from the eNB 40, and deletes the eNB 40 from the corresponding MBMS bearer context 322 distribution node. Subsequently, the MME 30 performs a session stop process (S712). Here, when the status information in the MBMS bearer context 322 is “active”, it is set to “standby”.

  Next, the MME 30 transmits an MBMS registration cancellation response to the eNB 40 (S714). The eNB 40 that has received the MBMS deregistration response deletes the MBMS bearer context 422 corresponding to the TMGI included in the MBMS deregistration request (S708).

  Subsequently, the MME 30 transmits an MBMS deregistration request for the corresponding service to the MBMS GW 20 (S716). The MBMS GW to be transmitted is resolved by the MBMS GW information of the MBMS bearer context 422, and is transmitted to the MBMS GW 20 in this embodiment.

  The MME 30 transmits an MBMS deregistration request including the TMGI registered in the MBMS bearer context 322, the service identifier, the session identifier, and the information of the MME 30 to the MBMS GW 20.

  The MBMS GW 20 that has received the MBMS deregistration request performs MBMS deregistration processing (S718). The TMGI included in the MBMS deregistration request received from the MME 30 is referenced, and the eNB 40 is deleted from the distribution node of the corresponding MBMS bearer context 222.

  Subsequently, the MBMS GW 20 performs a session stop process (S720). Here, when a bearer resource is set for the service identified by TMGI between the eNB 40 and the MBMS GW 20, the MBMS GW 20 releases the bearer resource. Further, when the status information in the MBMS bearer context 222 is “active”, the state is set to “standby”.

  Next, the MBMS GW 20 transmits an MBMS registration cancellation response to the MME 30 (S722). The MME 30 that has received the MBMS deregistration response deletes the MBMS 222 bearer context corresponding to the TMGI included in the MBMS deregistration request (S716).

  The MBMS GW 20 confirms the eNB (or eNB identifier) of the distribution node in the MBMS bearer context 222, and completes this process if the eNB is registered.

  On the other hand, when all the eNBs are deleted from the distribution node in the MBMS bearer context 222 (EMPTY), the MBMS GW 20 transmits an MBMS deregistration request for the corresponding service to the BM-SC 10 (S724). ). The BM-SC to be transmitted is resolved by the BM-SC information of the MBMS bearer context 222 in the MBMS GW 20, and is transmitted to the BM-SC 10 in this embodiment. The MBMS GW 20 transmits an MBMS deregistration request including TMGI registered in the MBMS bearer context 222, a service identifier, a session identifier, and information on the MBMS GW 20 to the BM-SC 10.

  The BM-SC 10 that has received the MBMS deregistration request performs MBMS deregistration processing (S726). With reference to the TMGI included in the MBMS deregistration request received from the MBMS GW 20, the MBMS GW 20 is deleted from the delivery node of the corresponding MBMS bearer context 124.

  Subsequently, the BM-SC 10 performs a session stop process (S728). Here, when a bearer resource is set for the service identified by TMGI between the MBMS GW 20 and the BM-SC 10, the BM-SC 10 releases the bearer resource. Further, when the state information in the MBMS bearer context is active, it is set to standby.

  Next, the BM-SC 10 transmits an MBMS registration cancellation response to the MBMS GW 20 (S730). The MBMS GW 20 that has received the MBMS deregistration response deletes the MBMS bearer context 222 corresponding to the TMGI included in the MBMS deregistration request (S724).

  The BM-SC 10 deletes the MBMS bearer context 124 identified by TMGI that has requested MBMS deregistration.

  Through the above procedure, the eNB 40 can efficiently cancel the MBMS registration and stop the session by using the counting function. The MBMS deregistration procedure of the eNB 40 can detect that the broadcast service distribution for each MBMS bearer that can be identified by TMGI or the like is unnecessary by the counting procedure.

  Furthermore, it can be started by detecting that the user is not viewing, as in the case where the user is not viewing because the application is turned off. Then, the MBMS deregistration procedure can be started with this detection as a trigger.

  In this way, each device recognizes that the service to be registered is the broadcast mode and stores it in the respective MBMS bearer context. Specifically, the BM-SC 10 broadcasts to the MBMS bearer context 124 mode, the MBMS GW 20 broadcasts to the MBMS bearer context 222 mode, the MME 30 broadcasts to the MBMS bearer context 322 mode, and the eNB 40 to the MBMS bearer context 422. Register to broadcast mode.

  Thereby, when determining MBMS deregistration, each apparatus can refer to the MBMS bearer context, and can cancel MBMS registration in the broadcast mode. Further, in the above case, when the state information in the MBMS bearer context is active, the state information can be changed to “standby” to stop the session, broadcast data distribution, and reception.

  Further, in the above case, when the state information in the MBMS bearer context 124 in the BM-SC 10, the MBMS bearer context 222 in the MBMS GW 20, the MBMS bearer context 322 in the MME 30, and the MBMS bearer context 422 in the eNB 40 are active, The status information can be changed to standby to stop the session, broadcast data distribution, and reception.

  Specifically, in the eNB 40, when the broadcast MBMS deregistration request is transmitted (S708), when the mode of the MBMS bearer context 422 is broadcast, the MBMS deregistration request is transmitted, the MBMS deregistration process, the release of the MBMS bearer, Multicast data distribution and reception stop.

  When transmitting the broadcast MBMS deregistration request (S716), if the mode of the MBMS bearer context 322 is broadcast, the MME 30 performs MBMS deregistration processing and session stop.

  When transmitting a broadcast MBMS deregistration request (S724), when the mode of the MBMS bearer context 222 is broadcast, the MBMS GW 20 transmits an MBMS deregistration request, releases an MBMS bearer, distributes broadcast data, and stops receiving.

  In the BM-SC 10, when the broadcast MBMS deregistration request is received (S724), if the mode of the MBMS bearer context 124 is broadcast, MBMS deregistration processing, MBMS bearer release, and broadcast data distribution stop are performed.

  Conventionally, it has been stipulated that the base station apparatus (eNB) takes the initiative to cancel the MBMS registration. However, the base station apparatus (eNB) confirms whether the mobile station apparatus (UE) needs to be received, When it was detected that it was not necessary, the MBMS registration could not be canceled efficiently.

  According to the present embodiment, the base station apparatus (eNB) can perform the MBMS deregistration procedure and the session stop procedure based on the result of necessity of reception of the mobile station apparatus (UE). In addition, the MBMS deregistration procedure makes it possible to delete the delivery destination device from the delivery destination list and to release resources that were conventionally performed by stopping the session. Furthermore, the session stop procedure required for session stop can be omitted.

  If the session is not stopped when MBMS registration is cancelled, the session is not started unless MBMS registration is performed again by canceling the MBMS registration and stopping the session.

  For example, in the conventional method, only a procedure for stopping a session from a distribution source to a distribution destination is defined, and a session stop cannot be requested from the distribution destination to the distribution source. That is, the session stop cannot be requested from the base station apparatus to the distribution source. Furthermore, even if the base station apparatus expands to request a session stop from the distribution source, the apparatus that receives the session stop request can stop the distribution and temporarily release resources, but does not delete the distribution node. .

  Therefore, for example, when 1) a session is started and 2) only the session is stopped by eNB, 3) after all sessions are stopped by BM-SC, 4) BM-SC When all the sessions are resumed, communication resources are allocated to all nodes (MBMS GW, eNB) included in the distribution list, and even the session stopped by the eNB is resumed. There was a problem.

  However, even when the distribution destination device is updated from the distribution list by the MBMS deregistration procedure and the session is resumed led by BM-SC as in 4), unnecessary sessions are not started.

  According to the present embodiment, since the session is not started unnecessarily, the exchange of control information required when starting the session can be reduced, and communication resources required for the session start procedure are used inefficiently. Thus, it is possible to effectively use communication resources.

  If the session is not stopped when MBMS registration is cancelled, the session is not started unless MBMS registration is performed again by canceling the MBMS registration and stopping the session.

  For example, conventionally, when 1) a session is started and 2) only the session is stopped by the eNB, 3) after all the sessions are stopped by the BM-SC, 4) BM-SC When all the sessions are resumed by initiative, communication resources are allocated to all nodes (MBMS GW, eNB) included in the distribution list, and even the sessions stopped by the eNB are resumed. I was sorry.

  In this embodiment, by canceling the MBMS registration, after 3) all the sessions led by BM-SC are stopped, 4) even when all the sessions led by BM-SC are resumed. The session will not be started unnecessarily. If the session is not started, communication resources are not used unnecessarily, and communication resources can be used efficiently.

  In addition, since the session is not started unnecessarily, the exchange of control information required when starting the session can be reduced, and the communication resource required for the session start procedure is not used inefficiently. Can be effectively utilized.

[3. Modified example]
The embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and the design and the like within the scope of the present invention are also within the scope of the claims. include.

  In each embodiment, a program that operates in each device is a program that controls a CPU or the like (a program that causes a computer to function) so as to realize the functions of the above-described embodiments. Information handled by these devices is temporarily stored in a temporary storage device (for example, RAM) at the time of processing, then stored in various ROM or HDD storage devices, and read and corrected by the CPU as necessary. • Writing is performed.

Here, as a recording medium for storing the program, a semiconductor medium (for example, ROM, a nonvolatile memory card, etc.), an optical recording medium / a magneto-optical recording medium (for example, a DVD (Digital Versatile Disc), an MO (Magneto Optical) Disc), MD (Mini Disc), CD (Compact Disc), BD, etc.), magnetic recording medium (for example, magnetic tape, flexible disk, etc.), etc. In addition, by executing the loaded program, not only the functions of the above-described embodiment are realized, but also based on the instructions of the program, the processing is performed in cooperation with the operating system or other application programs. The functions of the invention may be realized.

  In addition, when distributing to the market, the program can be stored and distributed in a portable recording medium, or transferred to a server computer connected via a network such as the Internet. In this case, of course, the storage device of the server computer is also included in the present invention.

In addition, a part or all of each device in the above-described embodiments may be realized as an LSI (Large Scale Integration) that is typically an integrated circuit. Each functional block of each device may be individually formed as a chip, or a part or all of them may be integrated into a chip. Further, the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. In addition, when integrated circuit technology that replaces LSI appears due to progress in semiconductor technology, it is of course possible to use an integrated circuit based on this technology.

10 BM-SC
100 Control Unit 110 Transmission / Reception Unit 120 Storage Unit 122 MBMS Service DB
124 MBMS bearer context 126 MBMS UE context 20 MBMS GW
200 Control Unit 210 Transmission / Reception Unit 220 Storage Unit 222 MBMS Bearer Context 224 Upstream Control Node DB
226 MBMS UE Context 30 MME
300 Control Unit 310 Transmitting / Receiving Unit 320 Storage Unit 322 MBMS Bearer Context 324 MBMS UE Context 40 eNB
400 Control Unit 410 Transmission / Reception Unit 420 Storage Unit 422 MBMS Bearer Context 424 Radio Frame Information 426 MBMS UE Context 50 UE

Claims (17)

A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In a mobile communication system that performs multicast data distribution by MBMS bearer service to a device,
The MME has MBMS registered the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
The base station device
A confirmation message including a service identifier is transmitted to the mobile station device, and the number of mobile station devices that require multicast data distribution is counted based on a response from the mobile station device, and the counted number is 0 In this case, the mobile communication system is characterized by transmitting an MBMS deregistration request for the multicast data to the MME.   The mobile communication system according to claim 1, wherein the service identifier includes a TMGI (Temporary Mobile Group Identify).   The said MME deletes the base station apparatus which transmitted the MBMS deregistration request from the delivery list | wrist of a MBMS bearer context, when the MBMS deregistration request is received, The movement of Claim 1 or 2 characterized by the above-mentioned. Communications system.   The mobile communication system according to any one of claims 1 to 3, wherein the base station apparatus releases an MBMS bearer resource together with transmitting an MBMS deregistration request to the MME. When the base station apparatus included in the delivery list of the MBMS bearer context disappears, the MME sends an MBMS deregistration request associated with the MBMS bearer context to the MBMS GW.
The mobile communication system according to any one of claims 1 to 4, wherein the MBMS GW deletes the base station apparatus that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context. The MBMS GW sends an MBMS deregistration request associated with the MBMS bearer context to the BM-SC when the base station apparatus that performs multicast data delivery included in the delivery list of the MBMS bearer context disappears,
The mobile communication system according to any one of claims 1 to 5, wherein the BM-SC deletes the MBMS GW that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context. A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In a mobile communication system that performs broadcast data distribution to an apparatus by MBMS bearer service,
The MME has MBMS registered the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
The base station device
A confirmation message including a service identifier is transmitted to the mobile station device, and the number of mobile station devices that require broadcast data distribution is counted based on a response from the mobile station device, and the counted number is 0 In this case, the mobile communication system transmits an MBMS deregistration request for the broadcast data to the MME.   The mobile communication system according to claim 7, wherein the service identifier includes a TMGI (Temporary Mobile Group Identify).   The said MME deletes the base station apparatus which transmitted the MBMS deregistration request from the delivery list of MBMS bearer context, when the MBMS deregistration request is received. Communications system.   The mobile communication system according to any one of claims 7 to 9, wherein the base station device transmits a session including a stop request together with transmitting an MBMS deregistration request to the MME. . The MME sends an MBMS deregistration request associated with the MBMS bearer context to the MBMS GW when the base station apparatus that performs broadcast data delivery included in the delivery list of the MBMS bearer context disappears,
The mobile communication system according to any one of claims 7 to 10, wherein the MBMS GW deletes the base station apparatus that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context. The MBMS GW transmits an MBMS deregistration request associated with the MBMS bearer context to the BM-SC when there is no base station apparatus that performs broadcast data distribution included in the distribution list of the MBMS bearer context,
The mobile communication system according to any one of claims 7 to 11, wherein the BM-SC deletes the MBMS GW that has transmitted the MBMS deregistration request from the distribution list in the MBMS bearer context. A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In a base station device connected to a mobile communication system that performs multicast data distribution by MBMS bearer service to the device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
In the base station apparatus, an MBMS deregistration request for multicast data transmitted when there is no mobile station apparatus requiring multicast data distribution is transmitted to the MME. A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In a base station device connected to a mobile communication system that performs broadcast data distribution by MBMS bearer service to the device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
A confirmation message including a service identifier is transmitted to the mobile station device, and the number of mobile station devices that require broadcast data distribution is counted based on a response from the mobile station device, and the counted number is 0 In this case, the base station apparatus transmits an MBMS deregistration request for the broadcast data to the MME. A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In an MME connected to a mobile communication system that performs multicast data distribution by MBMS bearer service to a device,
MBMS registration of the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
Receiving from the base station device an MBMS deregistration request for multicast data transmitted when there is no mobile station device requiring multicast data distribution;
The MME, wherein when receiving the MBMS deregistration request, the base station apparatus that has transmitted the MBMS deregistration request is deleted from the distribution list of the MBMS bearer context. A mobile station connected to a base station apparatus from an BM-SC (Broadcast Multicast Service Center) via an MBMS GW (MBMS GateWay) and an MME (Mobility Management Entity) in which an MBMS (Multimedia Broadcast / Multicast Service) bearer is established In an MME connected to a mobile communication system that performs broadcast data distribution by MBMS bearer service to a device,
MBMS registration of the base station device,
In the MBMS bearer service, MBMS bearer context information including MBMS bearer resources allocated and established is included in the MBMS bearer context,
Receiving an MBMS deregistration request for broadcast data transmitted when there is no mobile station device requiring broadcast data distribution from the base station device;
The MME, wherein when receiving the MBMS deregistration request, the base station apparatus that has transmitted the MBMS deregistration request is deleted from the distribution list of the MBMS bearer context. A mobile station apparatus connected to the mobile communication system according to any one of claims 1 to 12.

Images