Communication system, terminal device, and base station device

JP2025024121AInactive Publication Date: 2025-02-19MITSUBISHI ELECTRIC CORP
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2024201301
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2010-10-01
Filing Date
2024-11-19
Publication Date
2025-02-19
Estimated Expiration
Not applicable · inactive patent

AI Technical Summary

Benefits of technology

【0067】 本発明の通信システム等によれば、或る種別の通信端末装置に最適な通信を維持した状態で、他の種別の通信端末装置の通信を可能とする通信システム等を構築することが可能となる。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025024121000001_ABST
    Figure 2025024121000001_ABST
Patent Text Reader

Abstract

To provide a communication system and the like capable of avoiding congestion in downstream communication or upstream communication and the resulting shortage of radio resources.SOLUTION: A communication system includes a terminal device and a base station device capable of wireless communication with the terminal device. Using an MTC control channel, which is a control channel for MTC, MTC control information, which is control information for MTC, is transmitted from the base station device to the terminal device, and radio resource information, which is information on radio resources for transmitting the MTC control channel, is transmitted from the base station device to the terminal device.SELECTED DRAWING: Figure 13
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to a communication system or the like that performs wireless communication between a plurality of communication terminal devices and a base station device. [Background technology]

[0002] Among the third-generation communication methods, the Wideband Code division Multiple Access (W-CDMA) method has been available commercially in Japan since 2001. In addition, the High Speed ​​Downlink Packet Access (HSDPA) method has been launched, which realizes even faster data transmission using the downlink by adding a packet transmission channel (High Speed-Downlink Shared Channel: HS-DSCH) to the downlink (individual data channel, individual control channel). Furthermore, the High Speed ​​Uplink Packet Access (HSUPA) method has also been launched to further increase the speed of data transmission in the uplink. W-CDMA is a communication method defined by the 3rd Generation Partnership Project (3GPP), a standardization organization for mobile communication systems, and the Release 8 edition of the specifications has been compiled.

[0003] In addition, 3GPP is considering a new communication method other than W-CDMA, called Long Term Evolution (LTE) for wireless sections and System Architecture Evolution (SAE) for the overall system configuration including the core network (also simply called the network). This communication method is also called the 3.9G (3.9 Generation) system.

[0004] In LTE, the access method, radio channel configuration and protocols will be completely different from the current W-CDMA (HSDPA / HSUPA). For example, W-CDMA uses Code Division Multiple Access, whereas LTE uses OFDM (Orthogonal Frequency Division Multiplexing) for downlink and SC-FDMA (Single Carrier Frequency Division Multiple Access) for uplink. In addition, while W-CDMA uses 5MHz bandwidth, LTE allows users to select from 1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz and 20MHz for each base station. Also, LTE does not include circuit switching like W-CDMA, and is only a packet communication method.

[0005] LTE is defined as an independent radio access network separate from the W-CDMA network, since the communication system is configured using a new core network different from the W-CDMA core network (General Packet Radio Service: GPRS). Therefore, to distinguish it from the W-CDMA communication system, in the LTE communication system, the base station that communicates with the mobile terminal (User Equipment: UE) is called eNB (E-UTRAN NodeB), and the base station control device (Radio Network Controller) that exchanges control data and user data with multiple base stations is called EPC (Evolved Packet Core) or aGW (Access Gateway). In this LTE communication system, unicast service and E-MBMS service (Evolved Multimedia Broadcast Multicast Service) are provided. The E-MBMS service is a broadcast type multimedia service, and may be simply called MBMS. Large-volume broadcast content such as news, weather forecasts, and mobile broadcasts is transmitted to multiple mobile terminals. This is also called point to multipoint service.

[0006] Current decisions on the overall architecture of the LTE system in 3GPP are described in Non-Patent Document 1 (Chapter 4.6.1). The overall architecture will be described with reference to FIG. 1. FIG. 1 is an explanatory diagram showing the configuration of an LTE communication system. In FIG. 1, if a control protocol for a mobile terminal 101, such as RRC (Radio Resource Control), and a user plane, such as PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), terminate at a base station 102, then an E-UTRAN (Evolved Universal Terrestrial Radio Access) is composed of one or more base stations 102.

[0007] The base stations 102 schedule and transmit paging signals (also called paging messages) notified from a Mobility Management Entity (MME) 103. The base stations 102 are connected to each other via an X2 interface. The base stations 102 are also connected to an Evolved Packet Core (EPC) via an S1 interface. More specifically, the base stations 102 are connected to a Mobility Management Entity (MME) 103 via an S1_MME interface and to a Serving Gateway (S-GW) 104 via an S1_U interface.

[0008] The MME 103 distributes paging signals to a single or multiple base stations 102. The MME 103 also performs mobility control in an idle state. The MME 103 manages a tracking area list when a mobile terminal is in an idle state or an active state.

[0009] The S-GW 104 transmits and receives user data to and from one or more base stations 102. The S-GW 104 serves as a local mobility anchor point during handover between base stations. The EPC also includes a P-GW (PDN Gateway), which performs packet filtering for each user and assigns UE-ID addresses.

[0010] The control protocol RRC between the mobile terminal 101 and the base station 102 performs broadcast, paging, RRC connection management, etc. The states of the base station and the mobile terminal in RRC include RRC_IDLE and RRC_CONNECTED. In RRC_IDLE, PLMN (Public Land Mobile Network) selection, system information (SI) broadcast, paging, cell reselection, mobility, etc. are performed. In RRC_CONNECTED, the mobile terminal has an RRC connection, can transmit and receive data to and from the network, and also performs handover (HO), measurement of neighbor cells, etc.

[0011] The current decisions on the frame configuration in the LTE system in 3GPP, which are described in Non-Patent Document 1 (Chapter 5), will be explained with reference to FIG. 2. FIG. 2 is an explanatory diagram showing the configuration of a radio frame used in a communication system of the LTE type. In FIG. 2, one radio frame is 10 ms. The radio frame is divided into 10 sub-frames of equal size. The sub-frame is divided into two slots of equal size. The first and sixth sub-frames of each radio frame include a downlink synchronization signal (SS). The synchronization signal includes a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0012] MBSFN (Multimedia Broadcast multicast service Single Frequency Network) and non-MBSFN channels are multiplexed on a subframe basis. MBSFN Transmission is a simulcast transmission technique that is achieved by transmitting the same waveform from multiple cells at the same time. MBSFN transmissions from multiple cells in an MBSFN Area appear to mobile terminals as a single transmission. MBSFN is a network that supports such MBSFN transmissions. Hereinafter, a subframe for MBSFN transmission is referred to as an MBSFN sub-frame.

[0013] Non-patent document 2 describes an example of signaling when allocating MBSFN subframes. FIG. 3 is an explanatory diagram showing the configuration of an MBSFN frame. In FIG. 3, an MBSFN subframe is allocated for each MBSFN frame. The MBSFN frame is repeated at an allocation period (radio frame allocation period). The MBSFN subframe is a subframe allocated for MBSFN in a radio frame defined by an allocation period and an allocation offset (radio frame allocation offset), and is a subframe for transmitting multimedia data. A radio frame that satisfies the following formula (1) is a radio frame that includes an MBSFN subframe.

[0014] SFN mod radioFrameAllocationPeriod=radioFrameAllocationOffset …(1) MBSFN subframe allocation is done by 6 bits. The leftmost bit defines the MBSFN allocation for subframe 2 (#1). The second bit defines the MBSFN allocation for subframe 3 (#2), the third bit defines the MBSFN allocation for subframe 4 (#3), the fourth bit defines the MBSFN allocation for subframe 7 (#6), the fifth bit defines the MBSFN allocation for subframe 8 (#7), and the sixth bit defines the MBSFN allocation for subframe 9 (#8). If the bit indicates "1", it indicates that the corresponding subframe is allocated for MBSFN.

[0015] Current decisions on channel configuration in the LTE system in 3GPP are described in Non-Patent Document 1 (Chapter 5). It is assumed that the same channel configuration as that of a non-CSG cell is used in a CSG cell (Closed Subscriber Group cell). The physical channel will be explained using FIG. 4. FIG. 4 is an explanatory diagram explaining the physical channel used in the LTE communication system.

[0016] In FIG. 4, the Physical Broadcast channel (PBCH) 401 is a downlink channel transmitted from the base station 102 to the mobile terminal 101. The BCH transport block is mapped to four subframes in a 40 ms interval. There is no explicit signaling of the 40 ms timing. The Physical Control Format Indicator Channel (PCFICH) 402 is transmitted from the base station 102 to the mobile terminal 101. The PCFICH informs the base station 102 to the mobile terminal 101 about the number of OFDM symbols to use for the PDCCHs. The PCFICH is transmitted every subframe.

[0017] A physical downlink control channel (PDCCH) 403 is a downlink channel transmitted from the base station 102 to the mobile terminal 101. The PDCCH reports resource allocation, HARQ (Hybrid Automatic Repeat reQuest) information related to DL-SCH (a downlink shared channel which is one of the transport channels shown in FIG. 5 described later), and PCH (a paging channel which is one of the transport channels shown in FIG. 5). The PDCCH carries an uplink scheduling grant. The PDCCH carries Acknowledgement (Acknowledgement) / Nack (Negative Acknowledgement) which are response signals to uplink transmission. The PDCCH is also called an L1 / L2 control signal.

[0018] The Physical Downlink Shared Channel (PDSCH) 404 is a downlink channel transmitted from the base station 102 to the mobile terminal 101. The PDSCH is mapped with the DL-SCH (downlink shared channel) which is a transport channel and the PCH which is a transport channel. The Physical Multicast Channel (PMCH) 405 is a downlink channel transmitted from the base station 102 to the mobile terminal 101. The PMCH is mapped with the MCH (multicast channel) which is a transport channel.

[0019] The Physical Uplink Control Channel (PUCCH) 406 is an uplink channel transmitted from the mobile terminal 101 to the base station 102. The PUCCH carries Ack / Nack, which is a response signal to a downlink transmission. The PUCCH carries a Channel Quality Indicator (CQI) report. The CQI is quality information indicating the quality of received data or the quality of a communication path. The PUCCH also carries a Scheduling Request (SR). The Physical Uplink Shared Channel (PUSCH) 407 is an uplink channel transmitted from the mobile terminal 101 to the base station 102. The PUSCH is mapped with the UL-SCH (the uplink shared channel, which is one of the transport channels shown in FIG. 5).

[0020] A Physical Hybrid ARQ Indicator Channel (PHICH) 408 is a downlink channel transmitted from the base station 102 to the mobile terminal 101. The PHICH carries an Ack / Nack that is a response to an uplink transmission. A Physical Random Access Channel (PRACH) 409 is an uplink channel transmitted from the mobile terminal 101 to the base station 102. The PRACH carries a random access preamble.

[0021] A downlink reference signal is a symbol known in mobile communication systems. Reference symbol received power (RSRP) is one of the physical layer measurements of a mobile terminal.

[0022] The transport channel described in Non-Patent Document 1 (Chapter 5) will be explained with reference to Fig. 5. Fig. 5 is an explanatory diagram explaining the transport channel used in the LTE communication system. Fig. 5(A) shows the mapping between the downlink transport channel and the downlink physical channel. Fig. 5(B) shows the mapping between the uplink transport channel and the uplink physical channel.

[0023] A broadcast channel (BCH) for downlink transport channels is broadcast to the entire coverage of the base station (cell). The BCH is mapped to a physical broadcast channel (PBCH).

[0024] Retransmission control using Hybrid ARQ (HARQ) is applied to the Downlink Shared Channel (DL-SCH). DL-SCH can be broadcast to the entire coverage of a base station (cell). DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called persistent scheduling. DL-SCH supports Discontinuous reception (DRX) of mobile terminals to reduce power consumption of mobile terminals. DL-SCH is mapped to the Physical Downlink Shared Channel (PDSCH).

[0025] The Paging Channel (PCH) supports DRX of mobile terminals to enable low power consumption of the mobile terminals. The PCH is required to be broadcast to the entire coverage of the base station (cell). The PCH is mapped to physical resources such as the Physical Downlink Shared Channel (PDSCH) that can be dynamically used for traffic, or the Physical Downlink Control Channel (PDCCH) of other control channels.

[0026] The Multicast Channel (MCH) is used for broadcasting to the entire coverage of a base station (cell). The MCH supports SFN combining of MBMS services (MTCH and MCCH) in multi-cell transmission. The MCH supports semi-static resource allocation. The MCH is mapped to the PMCH.

[0027] The Uplink Shared Channel (UL-SCH) is subject to retransmission control using Hybrid ARQ (HARQ). The UL-SCH supports dynamic or semi-static resource allocation. The UL-SCH is mapped to the Physical Uplink Shared Channel (PUSCH).

[0028] The Random Access Channel (RACH) shown in FIG. 5B is limited to control information. The RACH has a risk of collision. The RACH is mapped to the Physical Random Access Channel (PRACH).

[0029] Here we explain HARQ. HARQ is a technology that improves the communication quality of a transmission line by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. It has the advantage that error correction works effectively by retransmission even for transmission lines whose communication quality changes. In particular, it is possible to obtain further quality improvement by combining the reception result of the initial transmission and the reception result of the retransmission when retransmitting.

[0030] An example of a retransmission method will be described below. If the received data cannot be decoded correctly on the receiving side, in other words, if a CRC (Cyclic Redundancy Check) error occurs (CRC=NG), the receiving side will send a "Nack" to the transmitting side. The transmitting side that receives the "Nack" will retransmit the data. If the received data can be decoded correctly on the receiving side, in other words, if no CRC error occurs (CRC=OK), the receiving side will send an "Ack" to the transmitting side. The transmitting side that receives the "Ack" will send the next data.

[0031] One example of the HARQ method is Chase Combining. Chase Combining is a method in which the same data sequence is transmitted in the initial transmission and retransmission, and the initial transmission data sequence and the retransmission data sequence are combined in the retransmission to improve the gain. This is based on the idea that even if the initial transmission data contains errors, some of the data is partially correct, and by combining the correct parts of the initial transmission data and the retransmission data, data can be transmitted with higher accuracy. Another example of the HARQ method is IR (Incremental Redundancy). IR increases redundancy, and by transmitting parity bits in the retransmission, the redundancy is increased by combining with the initial transmission, and the quality is improved by the error correction function.

[0032] The logical channels described in Non-Patent Document 1 (Chapter 6) will be explained with reference to Fig. 6. Fig. 6 is an explanatory diagram explaining logical channels used in an LTE communication system. Fig. 6(A) shows mapping between downlink logical channels and downlink transport channels. Fig. 6(B) shows mapping between uplink logical channels and uplink transport channels.

[0033] The Broadcast Control Channel (BCCH) is a downlink channel for broadcast system control information. The BCCH, which is a logical channel, is mapped to the Broadcast Channel (BCH), which is a transport channel, or the Downlink Shared Channel (DL-SCH).

[0034] The Paging Control Channel (PCCH) is a downlink channel for transmitting paging signals. The PCCH is used when the cell location of the mobile terminal is unknown to the network. The PCCH, which is a logical channel, is mapped to the Paging Channel (PCH), which is a transport channel.

[0035] The Common Control Channel (CCCH) is a channel for transmitting control information between a mobile terminal and a base station. The CCCH is used when the mobile terminal does not have an RRC connection with the network. In the downlink direction, the CCCH is mapped to the Downlink Shared Channel (DL-SCH), which is a transport channel. In the uplink direction, the CCCH is mapped to the Uplink Shared Channel (UL-SCH), which is a transport channel.

[0036] The Multicast Control Channel (MCCH) is a downlink channel for point-to-multipoint transmission. It is used for transmission of MBMS control information for one or several MTCHs from the network to mobile terminals. The MCCH is used only by mobile terminals receiving MBMS. The MCCH is mapped to the transport channel Downlink Shared Channel (DL-SCH) or Multicast Channel (MCH).

[0037] A Dedicated Control Channel (DCCH) is a channel for transmitting dedicated control information between a mobile terminal and a network. The DCCH is mapped to an Uplink Shared Channel (UL-SCH) in the uplink and to a Downlink Shared Channel (DL-SCH) in the downlink.

[0038] A Dedicated Traffic Channel (DTCH) is a one-to-one communication channel for transmitting user information to an individual mobile terminal. DTCH exists in both uplink and downlink. In uplink, DTCH is mapped to an uplink shared channel (UL-SCH) and in downlink, DTCH is mapped to a downlink shared channel (DL-SCH).

[0039] Multicast Traffic Channel (MTCH) is a downlink channel for transmitting traffic data from the network to mobile terminals. MTCH is a channel used only by mobile terminals receiving MBMS. MTCH is mapped to Downlink Shared Channel (DL-SCH) or Multicast Channel (MCH).

[0040] GCI stands for Global Cell Identity. In LTE and UMTS (Universal Mobile Telecommunication System), CSG cells (Closed Subscriber Group cells) are introduced. CSG is explained below (see Chapter 3.1 of Non-Patent Document 3). CSG (Closed Subscriber Group) is a cell in which an operator specifies available subscribers (a cell for specific subscribers).

[0041] An identified subscriber is permitted to access one or more E-UTRAN cells of a PLMN (Public Land Mobile Network). The one or more E-UTRAN cells to which an identified subscriber is permitted to access are called "CSG cell(s)". However, there are access restrictions in PLMNs. A CSG cell is a part of a PLMN that broadcasts a unique CSG identity (CSG identity, CSG-ID). Members of a pre-registered and permitted subscriber group access a CSG cell using the CSG-ID, which is access permission information.

[0042] The CSG-ID is broadcast by a CSG cell or cells. There are multiple CSG-IDs in a mobile communication system. And the CSG-ID is used by a mobile terminal (UE) to facilitate the access of CSG-related members.

[0043] The location of a mobile terminal is tracked in units of an area consisting of one or more cells. The purpose of location tracking is to enable tracking the location of a mobile terminal and calling it (the mobile terminal can receive calls) even when it is in standby mode. The area for tracking the location of a mobile terminal is called a tracking area.

[0044] The CSG White List is a list stored in the Universal Subscriber Identity Module (USIM) that records all CSG IDs of the CSG cells to which the subscriber belongs. The CSG White List is also called the Allowed CSG ID List.

[0045] A "suitable cell" is explained below (see Chapter 4.3 of Non-Patent Document 3). A "suitable cell" is a cell on which a UE can camp to receive normal services. Such a cell satisfies the following conditions (1) and (2).

[0046] (1) The cell is part of the selected PLMN or the registered PLMN, or a PLMN in the "Equivalent PLMN List".

[0047] (2) The following conditions (a) to (d) must be met in accordance with the latest information provided by the NAS (Non-Access Stratum): (a) the cell is not a barred cell; (b) The cell is not part of the "prohibited LAs for roaming" list and is part of at least one Tracking Area (TA). In that case, the cell must satisfy (1) above. (c) the cell meets the cell selection evaluation criteria. (d) For a cell that is identified by System Information (SI) as a CSG cell, the CSG-ID is part of the UE's CSG WhiteList (included in the UE's CSG WhiteList).

[0048] An "acceptable cell" is explained below (see Chapter 4.3 of Non-Patent Document 3). This is a cell on which a UE camps to receive limited services (emergency call). Such a cell shall fulfill all the following requirements. That is, the minimum set of requirements for initiating an emergency call in an E-UTRAN network is as follows: (1) The cell is not a barred cell. (2) The cell meets the cell selection evaluation criteria.

[0049] Camping on a cell means that the UE has completed the cell selection / reselection process and has selected a cell for monitoring system information and paging information.

[0050] In 3GPP, base stations called Home-NodeB (Home-NB; HNB) and Home-eNodeB (Home-eNB; HeNB) are under consideration. HNB in ​​UTRAN or HeNB in ​​E-UTRAN is a base station for home, corporate, and commercial access services, for example. Non-Patent Document 4 discloses three different modes of access to HeNB and HNB. Specifically, they are an open access mode, a closed access mode, and a hybrid access mode.

[0051] Each mode has the following characteristics: In open access mode, a HeNB or HNB is operated as a normal cell of a regular operator. In closed access mode, a HeNB or HNB is operated as a CSG cell. This is a CSG cell that can only be accessed by CSG members. In hybrid access mode, it is a CSG cell to which non-CSG members are also allowed to access at the same time. A hybrid access mode cell (also called a hybrid cell) is, in other words, a cell that supports both open access mode and closed access mode.

[0052] In 3GPP, splitting all PCIs (Physical Cell Identities) into those for CSG cells and those for non-CSG cells (called PCI split) is under discussion (see Non-Patent Document 5). PCI split information is also under discussion to be notified by a base station to mobile terminals under its control in system information. The basic operation of a mobile terminal using PCI split is disclosed. A mobile terminal that does not have PCI split information needs to perform a cell search using all PCIs (for example, using all 504 codes). In contrast, a mobile terminal that has PCI split information can perform a cell search using the PCI split information.

[0053] Furthermore, 3GPP is currently formulating standards for Long Term Evolution Advanced (LTE-A) as Release 10 (see Non-Patent Documents 6 and 7).

[0054] In the LTE-A system, support for relays (Relay Nodes (RN)) is being considered in order to obtain high communication speeds, high throughput at cell edges, new coverage areas, and the like. The relay nodes are wirelessly connected to the radio access network via donor cells (Donor eNBs; DeNBs). Within the range of the donor cell, the link from the network (Network: NW) to the relay shares the same frequency band as the link from the network to the UE. In this case, a Release 8 UE can also connect to the donor cell. The link between the donor cell and the relay node is called a backhaul link, and the link between the relay node and the UE is called an access link.

[0055] In 3GPP, in addition to normal eNBs (macro cells), pico eNBs (pico cells), HeNB / HNB / CSG cells, nodes for hot zone cells, relay nodes, remote radio heads (RRHs), and other so-called local nodes are being considered.

[0056] In 3GPP, the Machine Type Communication (MTC) technology is being studied (see Non-Patent Documents 8 and 9). Unlike conventional human-to-human (H2H) communication, MTC is machine-to-machine (M2M) communication. That is, MTC does not require human interaction, i.e., human-to-human exchange. Examples of applications of services using MTC technology (hereinafter referred to as "MTC services") include metering for gas, electricity, water, etc., and transportation and order management (Tracking & Tracing). One of the characteristics of MTC services is that the number of MTC devices (MTC Devices: MTCDs) is enormous. As an example, it is expected that there will be more than 30,000 MTCDs under one cell. Non-Patent Document 8 shows the MTC standard in 3GPP.

[0057] In the MTC service, situations arise where data is communicated from or to many MTCDs at the same time. Conventional communication methods are optimized for H2H communication, so no measures are taken for situations where many MTCDs communicate data at the same time. For this reason, when data is communicated from or to many MTCDs at the same time, problems occur in which congestion occurs in the wireless network and the core network, leading to overload.

[0058] As a method for solving congestion in downstream communications (hereinafter sometimes referred to as "downstream congestion") and the problems caused by it, 3GPP has proposed the technologies of Non-Patent Document 10, Non-Patent Document 11, and Non-Patent Document 12. Also, as a method for solving congestion in upstream communications (hereinafter sometimes referred to as "upstream congestion") and the problems caused by it, 3GPP has proposed the technology of Non-Patent Document 13. [Prior art documents] [Non-patent literature]

[0059] [Non-Patent Document 1] 3GPP TS36.300 Va.0.0 [Non-Patent Document 2] 3GPP TS36.331 V9.3.0 [Non-Patent Document 3] 3GPP TS36.304 V9.3.0 [Non-Patent Document 4] 3GPP S1-083461 [Non-Patent Document 5] 3GPP R2-082899 [Non-Patent Document 6] 3GPP TR 36.814 V9.0.0 [Non-Patent Document 7] 3GPP TR 36.912 V9.0.0 [Non-Patent Document 8] 3GPP TS 22.368 V2.0.0 [Non-Patent Document 9] 3GPP R3-100315 [Non-Patent Document 10] 3GPP R2-102962 [Non-Patent Document 11] 3GPP R2-104004 [Non-Patent Document 12] 3GPP R2-102297 [Non-Patent Document 13] 3GPP S2-103183 Summary of the Invention [Problem to be solved by the invention]

[0060] When supporting MTC services, data is communicated from or to a large number of MTCDs simultaneously, which causes congestion and an overload problem in the radio network and the core network.

[0061] As a method for solving downlink congestion and the problems caused by it, the techniques of Non-Patent Documents 10, 11, and 12 have been proposed in 3GPP as described above. These Non-Patent Documents 10 to 12 disclose a method for reducing the paging load by transmitting paging for each MTC group, not for each MTCD. However, the methods disclosed in these Non-Patent Documents 10 to 12 still have a problem that a shortage of radio resources for paging of mobile terminals that are not MTCDs occurs when paging is notified to a large number of MTCDs at the same time.

[0062] As a method for solving uplink congestion and the problems caused by it, the technology of Non-Patent Document 13 has been proposed in 3GPP as described above. Non-Patent Document 13 describes that even if there is no request for detachment processing from an MTCD, an upper node performs detachment processing. However, the method disclosed in Non-Patent Document 13 causes a problem that radio resources for uplink RACH of an MTCD are insufficient.

[0063] An object of the present invention is to provide a communication system etc. capable of avoiding congestion in downstream or upstream communications and the resulting shortage of radio resources. [Means for solving the problem]

[0064] The communication system of the present invention is a communication system including a terminal device and a base station device capable of wireless communication with the terminal device, and is characterized in that it uses an MTC control channel, which is a control channel for MTC, to transmit MTC control information, which is control information for MTC, from the base station device to the terminal device, and transmits radio resource information, which is information on radio resources for transmitting the MTC control channel, from the base station device to the terminal device.

[0065] The terminal device of the present invention is a terminal device capable of wireless communication with a base station device, The present invention is characterized in that it receives MTC control information, which is control information for MTC, from a base station device using an MTC control channel, which is a control channel for MTC, and receives radio resource information, which is information on radio resources for transmitting the MTC control channel, from the base station device.

[0066] The base station device of the present invention is a base station device capable of wireless communication with a terminal device, The present invention is characterized in that, by using an MTC control channel that is a control channel for MTC, MTC control information that is control information for MTC is transmitted to a terminal device, and radio resource information that is information on radio resources for transmitting the MTC control channel is transmitted to the terminal device. Effect of the Invention

[0067] According to the communication system of the present invention, it is possible to construct a communication system that enables communication with a certain type of communication terminal device while maintaining optimal communication with another type of communication terminal device.

[0068] The objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description and the accompanying drawings. [Brief description of the drawings]

[0069] [Figure 1] FIG. 1 is an explanatory diagram showing the configuration of an LTE communication system. [Diagram 2] FIG. 1 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. [Diagram 3] FIG. 2 is an explanatory diagram showing the structure of an MBSFN frame. [Figure 4] FIG. 2 is an explanatory diagram illustrating physical channels used in an LTE communication system. [Diagram 5] FIG. 1 is an explanatory diagram illustrating transport channels used in an LTE communication system. [Figure 6] FIG. 2 is an explanatory diagram illustrating logical channels used in an LTE communication system. [Figure 7] 1 is a block diagram showing the overall configuration of an LTE mobile communication system currently being discussed in 3GPP. [Figure 8] FIG. 8 is a block diagram showing a configuration of a mobile terminal (mobile terminal 71 in FIG. 7) according to the present invention. [Figure 9] FIG. 8 is a block diagram showing a configuration of a base station (a base station 72 in FIG. 7) according to the present invention. [Figure 10] 8 is a block diagram showing a configuration of an MME (MME unit 73 in FIG. 7) according to the present invention. [Figure 11] FIG. 8 is a block diagram showing a configuration of a HeNBGW 74 shown in FIG. 7 which is a HeNBGW according to the present invention. [Figure 12] 1 is a flowchart showing an outline of operations from cell search to standby performed by a mobile terminal (UE) in an LTE communication system. [Figure 13] FIG. 1 is an explanatory diagram showing an example of MTC architecture being considered in 3GPP. [Figure 14] FIG. 1 is a diagram showing a paging sequence in a conventional LTE communication system. [Figure 15] FIG. 4 is a diagram showing an example of information included in a paging message in the first embodiment. [Figure 16] FIG. 11 is a diagram showing an example of a paging sequence in a case where the maximum value of the number of paging records of an MTCD is set semi-statically. [Figure 17] FIG. 11 is a diagram showing an example of information included in a paging message in the second embodiment. [Figure 18] FIG. 11 is a diagram showing an example of a paging sequence when an MME associates an MTC group with an MTCD belonging to the MTC group. [Figure 19] 11 is a diagram showing an example of a paging sequence when an eNB assigns an MTC group identifier to each cell. [Figure 20] FIG. 1 is a diagram showing subframes onto which paging is mapped as defined in current LTE. [Figure 21]FIG. 13 is a diagram showing subframes to which paging for MTCD is mapped. [Figure 22] FIG. 11 is a diagram illustrating an example of a subframe in which paging for MTCD is mapped to one subframe. [Diagram 23] FIG. 13 is a diagram illustrating another example of a subframe in the case where paging for MTCD is mapped to one subframe. [Figure 24] FIG. 1 is a diagram showing radio frames (PFs) onto which paging is mapped as defined in current LTE. [Diagram 25] FIG. 1 is a diagram showing a radio frame (PF) to which paging for MTCD is mapped. [Figure 26] FIG. 13 is a diagram illustrating a configuration of a radio frame and a subframe into which an MTCD-directed paging message disclosed in a fourth embodiment is mapped. [Figure 27] FIG. 13 is a diagram showing an example in which a period, an offset value, and a subframe number are set for each of two MTC groups. [Figure 28] 13 is a flowchart showing a processing procedure of an RNTI masking method performed by an eNB in ​​the fifth embodiment. [Figure 29] 13 is a flowchart showing a procedure of a paging message receiving process of a normal UE in the fifth embodiment. [Diagram 30] 13 is a flowchart showing a processing procedure of a paging message reception process of an MTCD in the fifth embodiment. [Diagram 31] A diagram showing the correspondence relationship between downlink logical channels, downlink transport channels, and downlink physical channels in embodiment 6. [Diagram 32] 23 is a flowchart showing a processing procedure of an RNTI masking method performed by an eNB in ​​the sixth embodiment. [Diagram 33] 23 is a flowchart showing a procedure of a paging message receiving process of a normal UE in the sixth embodiment. [Diagram 34]23 is a flowchart showing a processing procedure of a paging message receiving process of an MTCD in the sixth embodiment. [Diagram 35] FIG. 23 is a diagram showing an example of information included in a paging message in the seventh embodiment. [Diagram 36] FIG. 11 is a diagram showing a sequence of a process for transmitting and receiving downlink data for an MTC service using paging. [Figure 37] FIG. 11 is a diagram showing an example of information included in a paging message when an MTCD mobile terminal identifier is transmitted in a pair with MTC data. [Figure 38] 11 is a diagram for explaining a specific example of a method for transmitting information for notifying whether data for an MTC service has occurred and downlink data for an MTC service. FIG. [Figure 39] FIG. 23 is a diagram showing a sequence of transmission and reception processing of downlink data for an MTC service in the ninth embodiment. [Diagram 40] FIG. 23 is a diagram showing a sequence of transmission and reception processing of downlink data for an MTC service in the ninth embodiment. [Diagram 41] 11 is a diagram for explaining a specific example of a notification method when data for an MTC service is changed. FIG. [Diagram 42] FIG. 13 is a diagram illustrating a specific example of turning off transmission of MTC data after a predetermined period of time has elapsed. [Diagram 43] A diagram showing the sequence of an upstream congestion avoidance method in embodiment 10. [Diagram 44] A diagram showing the sequence of an upstream congestion avoidance method in a first variant of the tenth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0070] Embodiment 1 Fig. 7 is a block diagram showing the overall configuration of an LTE-based mobile communication system currently being discussed in 3GPP. Currently, 3GPP is considering the overall configuration of a system including CSG (Closed Subscriber Group) cells (Home-eNodeB (Home-eNB; HeNB) of E-UTRAN, Home-NB (HNB) of UTRAN) and non-CSG cells (eNodeB (eNB) of E-UTRAN, NodeB (NB) of UTRAN, BSS of GERAN), and a configuration as shown in Fig. 7 has been proposed for E-UTRAN (see Chapter 4.6.1 of Non-Patent Document 1).

[0071] 7 will be described. A mobile terminal device (hereinafter referred to as a "mobile terminal" or "User Equipment (UE)") 71 is capable of wireless communication with a base station device (hereinafter referred to as a "base station") 72, and transmits and receives signals via wireless communication. The mobile terminal device corresponds to a communication terminal device. The base station 72 is classified into an eNB72-1 which is a macro cell, and a Home-eNB72-2 which is a local node. The eNB72-1 corresponds to a large-scale base station device, and has a relatively large-scale coverage as a coverage range in which communication with the mobile terminal UE71 is possible. The Home-eNB72-2 corresponds to a small-scale base station device, and has a relatively small-scale coverage as a coverage range.

[0072] The eNB72-1 is connected to an MME, an S-GW, or an MME / S-GW unit (hereinafter sometimes referred to as an "MME unit") 73 including an MME and an S-GW via an S1 interface, and control information is communicated between the eNB72-1 and the MME unit 73. A plurality of MME units 73 may be connected to one eNB72-1. The eNBs 72-1 are connected to each other via an X2 interface, and control information is communicated between the eNBs 72-1.

[0073] The Home-eNB72-2 is connected to the MME unit 73 via an S1 interface, and control information is communicated between the Home-eNB72-2 and the MME unit 73. A plurality of Home-eNB72-2 are connected to one MME unit 73. Alternatively, the Home-eNB72-2 is connected to the MME unit 73 via a Home-eNB GateWay (HeNBGW) 74. The Home-eNB72-2 and the HeNBGW74 are connected by an S1 interface, and the HeNBGW74 and the MME unit 73 are connected via an S1 interface. One or a plurality of Home-eNB72-2 are connected to one HeNBGW74, and information is communicated via the S1 interface. The HeNBGW74 is connected to one or a plurality of MME units 73, and information is communicated via the S1 interface.

[0074] Furthermore, the following configurations are currently being considered in 3GPP. The X2 interface between Home-eNBs 72-2 is not supported. From the MME unit 73, HeNBGW 74 appears as eNB 72-1. From the Home-eNB 72-2, HeNBGW 74 appears as the MME unit 73. Regardless of whether Home-eNB 72-2 is connected to the MME unit 73 via HeNBGW 74, the interface between the Home-eNB 72-2 and the MME unit 73 is the same as the S1 interface. Mobility to or from Home-eNBs 72-2 that spans multiple MME units 73 is not supported. Home-eNB 72-2 supports only one cell.

[0075] FIG. 8 is a block diagram showing the configuration of a mobile terminal (mobile terminal 71 in FIG. 7) according to the present invention. The transmission process of the mobile terminal 71 shown in FIG. 8 will be described. First, the control data from the protocol processing unit 801 and the user data from the application unit 802 are stored in the transmission data buffer unit 803. The data stored in the transmission data buffer unit 803 is passed to the encoder unit 804, where encoding such as error correction is performed. There may be data that is directly output from the transmission data buffer unit 803 to the modulation unit 805 without being encoded. The data that has been encoded by the encoder unit 804 is modulated by the modulation unit 805. The modulated data is converted into a baseband signal, and then output to the frequency conversion unit 806, where it is converted into a radio transmission frequency. Thereafter, a transmission signal is transmitted from the antenna 807 to the base station 72.

[0076] Moreover, the receiving process of the mobile terminal 71 is executed as follows. A radio signal from the base station 72 is received by the antenna 807. The received signal is converted from a radio receiving frequency to a baseband signal by the frequency conversion unit 806, and demodulated by the demodulation unit 808. The demodulated data is passed to the decoder unit 809, where decoding such as error correction is performed. Of the decoded data, the control data is passed to the protocol processing unit 801, and the user data is passed to the application unit 802. A series of processes of the mobile terminal 71 is controlled by the control unit 810. Therefore, although the control unit 810 is omitted in FIG. 8, it is connected to each of the units 801 to 809.

[0077] FIG. 9 is a block diagram showing a configuration of a base station (base station 72 in FIG. 7) according to the present invention. The transmission process of the base station 72 shown in FIG. 9 will be described. The EPC communication unit 901 transmits and receives data between the base station 72 and the EPC (MME unit 73, HeNBGW 74, etc.). The other base station communication unit 902 transmits and receives data between the base station 72 and the other base station. Since the X2 interface between the Home-eNB 72-2 is not supported, it is possible that the other base station communication unit 902 does not exist in the Home-eNB 72-2. The EPC communication unit 901 and the other base station communication unit 902 each exchange information with a protocol processing unit 903. The control data from the protocol processing unit 903, and the user data and control data from the EPC communication unit 901 and the other base station communication unit 902 are stored in the transmission data buffer unit 904.

[0078] The data stored in the transmission data buffer unit 904 is passed to an encoder unit 905, where it undergoes encoding processing such as error correction. Some data may be output directly from the transmission data buffer unit 904 to a modulator unit 906 without undergoing encoding processing. The encoded data is modulated in the modulator unit 906. The modulated data is converted into a baseband signal, and then output to a frequency converter unit 907, where it is converted into a radio transmission frequency. The transmission signal is then transmitted from an antenna 908 to one or more mobile terminals 71.

[0079] Moreover, the reception process of the base station 72 is executed as follows. A radio signal from one or more mobile terminals 71 is received by an antenna 908. The received signal is converted from a radio reception frequency to a baseband signal by a frequency conversion unit 907, and demodulated by a demodulation unit 909. The demodulated data is passed to a decoder unit 910, where decoding such as error correction is performed. Of the decoded data, control data is passed to a protocol processing unit 903 or an EPC communication unit 901 or an other base station communication unit 902, and user data is passed to the EPC communication unit 901 and the other base station communication unit 902. A series of processes of the base station 72 is controlled by a control unit 911. Therefore, although the control unit 911 is omitted in FIG. 9, it is connected to each unit 901 to 910.

[0080] The functions of the Home-eNB72-2 currently being discussed in 3GPP are shown below (see Chapter 4.6.2 of Non-Patent Document 1). The Home-eNB72-2 has the same functions as the eNB72-1. In addition, when connecting to a HeNBGW74, the Home-eNB72-2 has a function of discovering an appropriate serving HeNBGW74. The Home-eNB72-2 connects to only one HeNBGW74. In other words, when connecting to a HeNBGW74, the Home-eNB72-2 does not use the Flex function in the S1 interface. When the Home-eNB72-2 is connected to one HeNBGW74, it does not connect to another HeNBGW74 or another MME unit 73 at the same time.

[0081] The TAC and PLMN ID of the Home-eNB72-2 are supported by the HeNBGW74. When the Home-eNB72-2 is connected to the HeNBGW74, the selection of the MME unit 73 in "UE attachment" is performed by the HeNBGW74 instead of the Home-eNB72-2. The Home-eNB72-2 may be deployed without network planning. In this case, the Home-eNB72-2 is moved from one geographical area to another geographical area. Therefore, the Home-eNB72-2 in this case needs to be connected to a different HeNBGW74 depending on the location.

[0082] FIG. 10 is a block diagram showing the configuration of the MME according to the present invention. FIG. 10 shows the configuration of the MME 73a included in the MME unit 73 shown in FIG. 7 described above. The PDN GW communication unit 1001 transmits and receives data between the MME 73a and the PDN GW. The base station communication unit 1002 transmits and receives data between the MME 73a and the base station 72 via the S1 interface. If the data received from the PDN GW is user data, the user data is passed from the PDN GW communication unit 1001 to the base station communication unit 1002 via the user plane communication unit 1003, and transmitted to one or more base stations 72. If the data received from the base station 72 is user data, the user data is passed from the base station communication unit 1002 to the PDN GW communication unit 1001 via the user plane communication unit 1003, and transmitted to the PDN GW.

[0083] When the data received from the PDN GW is control data, the control data is passed from the PDN GW communication unit 1001 to the control plane control unit 1005. When the data received from the base station 72 is control data, the control data is passed from the base station communication unit 1002 to the control plane control unit 1005.

[0084] The HeNBGW communication unit 1004 is provided when a HeNBGW 74 is present, and transmits and receives data via an interface (IF) between the MME 73a and the HeNBGW 74 depending on the information type. Control data received from the HeNBGW communication unit 1004 is passed from the HeNBGW communication unit 1004 to a control plane control unit 1005. A result of processing in the control plane control unit 1005 is transmitted to the PDN GW via a PDN GW communication unit 1001. In addition, a result of processing in the control plane control unit 1005 is transmitted to one or more base stations 72 by the S1 interface via a base station communication unit 1002, and is also transmitted to one or more HeNBGW 74 via the HeNBGW communication unit 1004.

[0085] The control plane control unit 1005 includes a NAS security unit 1005-1, an SAE bearer control unit 1005-2, an idle state mobility management unit 1005-3, etc., and performs general processing for the control plane. The NAS security unit 1005-1 performs security for NAS (Non-Access Stratum) messages, etc. The SAE bearer control unit 1005-2 performs management of SAE (System Architecture Evolution) bearers, etc. The idle state mobility management unit 1005-3 performs mobility management in the standby state (LTE-IDLE state, also simply called idle), generation and control of paging signals in the standby state, addition, deletion, update, search, and tracking area (TA) list management for one or more mobile terminals 71 under its control.

[0086] The MME 73a starts a paging protocol by transmitting a paging message to a cell belonging to a tracking area (TA) in which the UE is registered. The idle state mobility management unit 1005-3 may manage the CSG, CSG-ID, and whitelist of the Home-eNB 72-2 connected to the MME 73a.

[0087] In the management of CSG-ID, the relationship between the mobile terminal corresponding to the CSG-ID and the CSG cell is managed (added, deleted, updated, searched). For example, the relationship may be between one or more mobile terminals registered for user access to a certain CSG-ID and the CSG cell belonging to the CSG-ID. In the management of whitelist, the relationship between the mobile terminal and the CSG-ID is managed (added, deleted, updated, searched). For example, the whitelist may store one or more CSG-IDs registered by a user of a certain mobile terminal. The management of these CSGs may be performed by other parts of the MME 73a. A series of processes of the MME 73a is controlled by the control unit 1006. Therefore, although the control unit 1006 is omitted in FIG. 10, it is connected to each unit 1001 to 1005.

[0088] The functions of the MME 73a currently being discussed in 3GPP are as follows (see Chapter 4.6.2 of Non-Patent Document 1). The MME 73a performs access control for one or more mobile terminals that are members of CSGs (Closed Subscriber Groups). The MME 73a allows the execution of paging optimization as an option.

[0089] Fig. 11 is a block diagram showing a configuration of the HeNBGW 74 shown in Fig. 7 which is a HeNBGW according to the present invention. An EPC communication unit 1101 transmits and receives data between the HeNBGW 74 and the MME 73a via the S1 interface. A base station communication unit 1102 transmits and receives data between the HeNBGW 74 and the Home-eNB 72-2 via the S1 interface. A location processing unit 1103 performs a process of transmitting registration information and the like out of the data from the MME 73a passed via the EPC communication unit 1101 to a plurality of Home-eNBs 72-2. The data processed by the location processing unit 1103 is passed to the base station communication unit 1102 and transmitted to one or a plurality of Home-eNBs 72-2 via the S1 interface.

[0090] Data that does not require processing in the location processing unit 1103 and is merely passed through (transmitted) is passed from the EPC communication unit 1101 to the base station communication unit 1102, and transmitted to one or more Home-eNBs 72-2 via the S1 interface. A series of processes in the HeNBGW 74 is controlled by a control unit 1104. Thus, although omitted in FIG. 11, the control unit 1104 is connected to each of the units 1101 to 1103.

[0091] The functions of the HeNBGW 74 currently being discussed in 3GPP are shown below (see Chapter 4.6.2 of Non-Patent Document 1). The HeNBGW 74 relays S1 applications. Although it is a part of the procedure of the MME 73a to the Home-eNB 72-2, the HeNBGW 74 terminates S1 applications not related to the mobile terminal 71. When the HeNBGW 74 is deployed, procedures not related to the mobile terminal 71 are communicated between the Home-eNB 72-2 and the HeNBGW 74, and between the HeNBGW 74 and the MME 73a. An X2 interface is not set between the HeNBGW 74 and other nodes. The HeNBGW 74 allows the execution of paging optimization as an option.

[0092] Next, an example of a general cell search method in a mobile communication system is shown. FIG. 12 is a flow chart showing an outline of a cell search to standby operation performed by a mobile terminal (UE) in an LTE communication system. When the mobile terminal starts a cell search, in step ST1201, the mobile terminal synchronizes slot timing and frame timing using a first synchronization signal (P-SS) and a second synchronization signal (S-SS) transmitted from a surrounding base station. A synchronization code that corresponds one-to-one to a PCI (Physical Cell Identity) assigned to each cell is assigned to the synchronization signal (SS) including the P-SS and the S-SS. Currently, 504 types of PCI are considered as the number of PCIs, and the 504 types of PCIs are used to synchronize and detect (identify) the PCI of the synchronized cell.

[0093] Next, in step ST1202, for the synchronized cell, a reference signal RS (cell-specific reference signal: CRS) transmitted from the base station for each cell is detected and the received power (also called RSRP) is measured. A code that has a one-to-one correspondence with the PCI is used for the reference signal RS, and the cell can be separated from other cells by correlating with the code. By deriving the code for the RS of the cell from the PCI identified in step ST1201, it becomes possible to detect the RS and measure the RS received power.

[0094] Next, in step ST1203, the cell with the best RS reception quality (for example, the cell with the highest RS reception power, that is, the best cell) is selected from one or more cells detected up to step ST1202.

[0095] Next, in step ST1204, the PBCH of the best cell is received to obtain the BCCH, which is broadcast information. The BCCH on the PBCH carries the MIB (Master Information Block), which includes cell configuration information. Therefore, the MIB can be obtained by receiving the PBCH and obtaining the BCCH. Examples of MIB information include the DL (downlink) system bandwidth (also called the transmission bandwidth configuration: dl-bandwidth), the number of transmitting antennas, and the SFN (System Frame Number).

[0096] Next, in step ST1205, the DL-SCH of the cell is received based on the cell configuration information of the MIB, and SIB (System Information Block) 1 in the broadcast information BCCH is obtained. SIB 1 includes information on access to the cell, information on cell selection, and scheduling information of other SIBs (SIBk; k is an integer ≧2). SIB 1 also includes a TAC (Tracking Area Code).

[0097] Next, in step ST1206, the mobile terminal compares the TAC of the SIB1 received in step ST1205 with the TAC in the tracking area (TA) list that the mobile terminal already holds. If the comparison shows that the TAC received in step ST1205 is the same as the TAC included in the TA list, the mobile terminal enters standby mode in the cell. If the comparison shows that the TAC received in step ST1205 is not included in the TA list, the mobile terminal requests a change of TA to perform a tracking area update (TAU) to a core network (EPC) (including MME, etc.) through the cell. The core network updates the TA list based on the identification number (UE-ID, etc.) of the mobile terminal transmitted from the mobile terminal together with a TAU request signal. The core network transmits the updated TA list to the mobile terminal. The mobile terminal rewrites (updates) the TAC list that the mobile terminal holds with the received TA list. After that, the mobile terminal enters standby mode in the cell.

[0098] In LTE and UMTS (Universal Mobile Telecommunication System), the introduction of CSG (Closed Subscriber Group) cells is being considered. As mentioned above, only one or more mobile terminals registered in a CSG cell are allowed to access it. A CSG cell and one or more registered mobile terminals constitute one CSG. A CSG thus constituted is assigned a unique identification number called a CSG-ID. Note that one CSG may have multiple CSG cells. Once a mobile terminal registers in one CSG cell, it can access other CSG cells in the CSG to which that CSG cell belongs.

[0099] Also, a Home-eNB in ​​LTE or a Home-NB in ​​UMTS may be used as a CSG cell. A mobile terminal registered in a CSG cell has a whitelist. Specifically, the whitelist is stored in a Subscriber Identity Module (SIM) / USIM. The whitelist stores CSG information of the CSG cell in which the mobile terminal has registered. Specifically, the CSG information may be a CSG-ID, a Tracking Area Identity (TAI), a TAC, etc. As long as the CSG-ID and the TAC are associated with each other, either one of them may be used. Also, as long as the CSG-ID and the TAC are associated with a Global Cell Identity (GCI), the GCI may be used.

[0100] From the above, a mobile terminal that does not have a whitelist (in the present invention, this also includes the case where the whitelist is empty) cannot access a CSG cell and can only access non-CSG cells. On the other hand, a mobile terminal that has a whitelist can access both the CSG cell with the registered CSG-ID and non-CSG cells.

[0101] In 3GPP, splitting all PCIs (Physical Cell Identities) into those for CSG cells and those for non-CSG cells (called PCI split) is under discussion (see Non-Patent Document 5). PCI split information is also under discussion to be notified by a base station to mobile terminals under its control in system information. Non-Patent Document 5 discloses the basic operation of a mobile terminal using PCI split. A mobile terminal that does not have PCI split information needs to perform a cell search using all PCIs (e.g., using all 504 codes). In contrast, a mobile terminal that has PCI split information can perform a cell search using the PCI split information.

[0102] Also, in 3GPP, it has been decided that the PCI for hybrid cells is not included in the range of the PCI for CSG cells (see Chapter 10.7 of Non-Patent Document 1).

[0103] In 3GPP, there are two modes for the mobile terminal to select or reselect a CSG cell. The first mode is automatic mode. The automatic mode has the following features: Selection or reselection is performed using an allowed CSG ID list in the mobile terminal. After the selection of a PLMN is completed, the mobile terminal camps on a cell in the selected PLMN only if it is a non-CSG cell or a CSG cell with a CSG ID that is in the allowed CSG list. If the allowed CSG list of the mobile terminal is empty, the mobile terminal stops the autonomous search function for CSG cells (see Chapter 5.2.4.8.1 of non-patent document 3).

[0104] The second mode is a manual mode. The features of the manual mode are as follows: The mobile terminal shows the user a list of CSGs available in the currently selected PLMN. The list of CSGs that the mobile terminal provides to the user is not limited to the CSGs included in the allowed CSG list stored in the mobile terminal. After the user selects a CSG based on the list of CSGs, the mobile terminal camps on a cell with the selected CSG ID and attempts to register (see Chapter 5.2.4.8.1 of Non-Patent Document 3).

[0105] HeNBs and HNBs are required to support various services. For example, operators register mobile terminals with certain HeNBs and HNBs and allow only registered mobile terminals to access HeNB and HNB cells, thereby increasing the wireless resources that the mobile terminals can use and enabling high-speed communication. To compensate for this, operators set a higher fee than usual.

[0106] In order to realize such services, CSG cells (Closed Subscriber Group cells) that can be accessed only by registered (subscribed, member) mobile terminals are introduced. It is required that many CSG cells (Closed Subscriber Group cells) are installed in shopping districts, apartment buildings, schools, companies, etc. For example, a CSG cell is installed for each store in a shopping district, for each room in an apartment building, for each classroom in a school, and for each section in a company, and a usage method is required in which only users registered in each CSG cell can use the CSG cell. HeNB / HNB is required not only to complement communication outside the coverage of a macro cell, but also to support various services as described above. For this reason, there are also cases where HeNB / HNB is installed within the coverage of a macro cell.

[0107] MTC technology is being studied in 3GPP (see Non-Patent Documents 8 and 9). Unlike conventional person-to-person (H2H) communication, MTC is machine-to-machine (M2M) communication. In other words, MTC does not require human interaction. Examples of service applications include metering for gas, electricity, water, etc., and transportation and order management (Tracking & Tracing). A feature of MTC services is the huge number of MTCDs. As an example, it is expected that there will be more than 30,000 MTCDs under one cell. Non-Patent Document 8 shows the MTC standard in 3GPP.

[0108] In 3GPP, MTC architecture is being considered (see Non-Patent Document 9). Fig. 13 is an explanatory diagram showing an example of MTC architecture being considered in 3GPP. Support for MTC service is being considered not only in LTE communication systems but also in WCDMA communication systems.

[0109] In Fig. 13, MTCDs 1301 to 1304 and an NB / eNB 1305 are connected via Uu interfaces 1311 to 1314. An SGSN / MME (Serving GPRS Support Node / Mobility Management Entity) 1306 is connected to the NB / eNB 1305 via an IuPS / S1 interface 1315. The MME and eNB are connected via an S1 interface. Although not shown, a radio network controller (RNC) exists between the NB and the SGSN. The NB and RNC are connected via an Iub interface, and the RNC is connected to the SGSN via an IuPS interface.

[0110] The HLR / HSS (Home Location Register / Home Subscriber Server) 1307 is connected to the SGSN / MME 1306 via a Gr / S6a interface 1316. The communication operator domain 1317 includes the NB / eNB 1305, the SGSN / MME 1306, and the HLR / HSS 1307.

[0111] The MTC server 1308 is included in a communication operator domain 1317. In addition, a case where the MTC server 1308 is not included in the communication operator domain 1317 is also being considered. An MTC user 1309 that provides an MTC service is connected to the MTC server 1308 via an application program interface (API) 1310. To which node of the communication operator domain 1317 the MTC server 1308 is connected is currently being considered in 3GPP.

[0112] Information for the MTC service is notified to the MTCDs 1301 to 1304 from the MTC server 1308 by the MTC user 1309 using the nodes of the communication operator area 1317, namely, the NB / eNB 1305, the SGSN / MME 1306, and the HLR / HSS 1307. Conversely, information from the MTCDs 1301 to 1304 is notified to the MTC server 1308 using the nodes of the communication operator area 1317, namely, the NB / eNB 1305, the SGSN / MME 1306, and the HLR / HSS 1307, and the MTC user 1309 uses the information.

[0113] In the MTC service, there are situations where data is communicated from or to many MTCDs at the same time. Such situations occur, for example, when meter reading data is transmitted from an MTCD to an MTC server once a day at 1:00 a.m., or when the MTC server requests an MTCD to transmit meter reading data. Another example is when data for software upgrades is transmitted to all MTCDs at once.

[0114] Conventional communication methods are optimized for H2H communication, so no measures have been taken for situations in which many MTCDs communicate data simultaneously. In situations in which data is communicated from or to many MTCDs simultaneously, congestion occurs in the wireless network and core network, causing the problem of these networks becoming overloaded.

[0115] For example, in the example shown in Fig. 13, when the MTC server 1308 requests the transmission of meter reading data to a large number of MTCDs 1301 to 1304 at once, a call (hereinafter sometimes referred to as "paging") is made to each of the MTCDs 1301 to 1304 at once via the Uu interfaces 1311 to 1314, which are wireless interfaces. In such a situation, the paging load increases and becomes overloaded, causing a shortage of wireless resources, which makes paging impossible.

[0116] Similarly, for example, when data is transmitted from the MTC server 1308 to a large number of MTCDs 1301 to 1304 simultaneously, a problem occurs in which a shortage of radio resources for transmitting downlink data occurs in the Uu interfaces 1311 to 1314, which are wireless interfaces, making it impossible to transmit the downlink data.

[0117] Similarly, when multiple MTCDs 1301-1304 transmit meter reading data to the MTC server 1308 simultaneously, a problem occurs in which the wireless interfaces, Uu interfaces 1311-1314, run out of wireless resources for upstream signaling and data transmission, making upstream access impossible.

[0118] As a method for solving downlink congestion and the problems caused by it, the technologies of Non-Patent Documents 10, 11, and 12 have been proposed in 3GPP. These Non-Patent Documents 10 to 12 disclose a method for reducing the paging load by transmitting paging for each MTC group, not for each MTCD. However, the methods disclosed in these Non-Patent Documents 10 to 12 still have a problem that, when a large number of MTCDs are notified of paging at the same time, there is a shortage of radio resources for paging of mobile terminals that are not MTCDs (hereinafter referred to as "normal UE"). An MTCD group corresponds to a group of terminal devices.

[0119] In addition, as a method for solving uplink congestion and the problems caused by it, the technology of Non-Patent Document 13 has been proposed in 3GPP. Non-Patent Document 13 describes that even if there is no request for detachment processing from an MTCD, an upper node performs detachment processing. However, the method disclosed in Non-Patent Document 13 causes a problem that radio resources for uplink RACH of an MTCD are insufficient.

[0120] The present invention discloses a method for avoiding the above-mentioned downlink congestion and the resulting shortage of downlink radio resources such as shortage of radio resources for paging and shortage of radio resources for downlink data, etc. Also, discloses a method for avoiding the uplink congestion and the resulting shortage of uplink radio resources such as shortage of radio resources for uplink RACH, etc.

[0121] A paging method in a conventional LTE communication system will be described below. Fig. 14 is a diagram showing a paging sequence in a conventional LTE communication system.

[0122] In Step ST1401, an incoming call message is notified from the call origin to the MME that manages the destination mobile terminal. The incoming call message includes the destination mobile terminal identifier (identification number). In Step ST1402, the MME searches the TA list for the mobile terminal identifier. At this time, the MME acquires information from the HSS as necessary.

[0123] In Step ST1403, the MME transmits a paging message to one or more eNBs. This initiates a paging procedure. The paging message includes a destination mobile terminal identifier. The destination mobile terminal identifier (UE-ID) included in the paging message transmitted in Step ST1403 includes an International Mobile Subscriber Identity (IMSI) or a Serving Temporary Mobile Subscriber Identity (s-TMSI), which is a mobile terminal identifier included in the paging message in Step ST1404 described later, and a mobile terminal identifier (UE_ID) for deriving the transmission timing of the paging message in Step ST1404.

[0124] In Step ST1404, the eNB that has received the paging message transmits the paging message to the user equipment (UE) being served by the eNB. The paging message includes a destination user equipment identifier (UE-ID). As the destination user equipment identifier (UE-ID) included in the paging message transmitted in Step ST1404, IMSI or s-TMSI is used.

[0125] The transmission of the paging message from the MME to the eNB in ​​Step ST1403 is performed using S1 signaling on the S1 interface, and the paging message is transmitted to an eNB in ​​the TA list to which the UE to which the paging is notified belongs. The transmission of the paging message from the eNB to the UE in Step ST1404 is performed using the Uu interface, which is an air interface. The transmission of the paging message in Step ST1404 is performed periodically. This is to enable the UE to perform discontinuous reception (abbreviated as DRX) and to reduce the power consumption of the UE.

[0126] The radio frame (paging frame: PF) and subframe (paging occasion: PO) in which a paging message to a UE is transmitted are derived from a mobile terminal identifier (UE_ID) for deriving paging transmission timing of each UE. Hereinafter, PF and PO may be collectively referred to as "PF / PO". The derivation formula is shown in Chapter 7 of Non-Patent Document 3. The UE_ID may be derived from the IMSI of the mobile terminal. The parameters T and nB used in the derivation formula are broadcast as system information. T is a DRX cycle, which is a cycle in which a paging message to a target UE is transmitted. nB is a parameter that determines the number of times PF / PO occurs within one DRX cycle. Using these, the parameters Ns and i_s, which represent subframe numbers and will be described later, are derived according to Non-Patent Document 3.

[0127] As described above, the paging message is mapped to the PCCH, which is a logical channel, and is further mapped to the PCH, which is a transport channel, and the PDSCH, which is a physical channel. The PDCCH of the subframe in which the paging message is transmitted includes radio resource allocation information. The radio resource allocation information for the paging message included in the PDCCH is masked using a P-RNTI (Paging-Radio Network Temporary Identity), which is an identifier for paging.

[0128] Although it has been described that the radio resource allocation information is masked, more specifically, the CRC (Cyclic Redundancy Check) parity bits of the radio resource allocation information are masked. This enables the UE to determine the presence or absence of a paging message by detecting the PDCCH of the subframe (PF / PO) at the timing when the paging message of the own station is transmitted, using the P-RNTI.

[0129] The information contained in the paging message includes a paging record list (pagingRecordList), which is a list of paging records, system information modification (systemInfoModification), and emergency information indication (etws-Indication). The paging record includes an IMSI or s-TMSI, which is a mobile terminal (UE) identifier. When a UE that receives a paging message recognizes that its own UE identifier is included in the UE identifier included in the paging record, it starts accessing the cell. The maximum value of the paging record is determined by the standard, and is set to "16".

[0130] In conventional paging in LTE, as shown in Non-Patent Document 2, the number of paging records is limited, so the number of UEs that can be called in one subframe is limited. This causes a problem that, when paging occurs simultaneously to a large number of MTCDs, a large delay occurs before all MTCDs are notified of paging. For example, 3GPP R2-102781 (hereinafter referred to as "Non-Patent Document 14") describes that a delay of 11.15 seconds occurs before all MTCDs in a cell are notified of paging.

[0131] Furthermore, a problem occurs in that paging for normal UE cannot be transmitted. When paging for normal UE and paging for MTCD occur simultaneously, all paging records on one paging message become MTCD identifiers, and it may become impossible to include the identifier of normal UE. In such a case, it becomes impossible to call normal UE. Even in the next paging occasion after the DRX cycle, there is a high possibility that paging for normal UE occurs simultaneously with paging for MTCD, and it becomes impossible to call normal UE. Therefore, a large delay time occurs until normal UE can receive a paging message addressed to itself.

[0132] Non-Patent Document 10 and Non-Patent Document 11 disclose a method for reducing the paging load by transmitting paging for each MTC group, not for each MTCD. However, even with these methods, when paging for an MTC group and paging for normal UE occur simultaneously, some or all of the paging records in one paging message become identifiers of the MTC group, and the number of identifiers of normal UEs that can be carried is reduced. This makes it impossible to call some normal UEs, and therefore causes a large delay time until the normal UE can receive a paging message addressed to itself.

[0133] Since paging to normal UE requires human interaction, an increase in delay time is not permitted. Therefore, when paging for normal UE and paging for MTCD occur simultaneously, it is an important issue to prevent an increase in delay time of paging for normal UE.

[0134] In this embodiment, in order to solve the above-mentioned problems, a method for calling an MTCD without reducing the number of normal UEs that can be called on one paging message is disclosed. As specific methods for calling an MTCD, the following two methods (1) and (2) are disclosed. (1) Paging for normal UE is prioritized over paging for MTCD, and (2) the maximum value of the number of paging records (hereinafter referred to as the "number of paging records") is set for each terminal type.

[0135] First, a specific example of the method of giving priority to paging for normal UE over paging for MTCD in the above (1) will be shown. The MME includes information indicating whether the paging by the paging message is for normal UE or MTCD in a paging message to be transmitted to the eNB. For example, one-bit information may indicate that "1" is for normal UE and "0" is for MTCD. Based on the information of the paging message received from the MME, the eNB writes the mobile terminal identifier of normal UE in preference to the mobile terminal identifier of MTCD in a paging record included in one paging message, and transmits the paging. This makes it possible to call normal UE with priority over MTCD.

[0136] The above-mentioned method can be applied even when the paging from the MME is not paging for the MTCD but paging for the MTC group. In this case, it is sufficient to include information indicating whether the paging message is for a normal UE or for an MTCD in the paging message of the paging from the MME. Based on the information of the paging message received from the MME, the eNB transmits the paging by preferentially describing the mobile terminal identifier of the normal UE in the paging record included in one paging message over the mobile terminal identifier of the MTC group or the MTCD belonging to the MTC group. This makes it possible to call the normal UE with priority.

[0137] By using the above-described method, it is possible to prevent an increase in the delay time of paging for normal UE when paging for normal UE and paging for MTCD occur simultaneously.

[0138] Next, a specific example of the method of setting the maximum number of paging records for each terminal type in (2) above will be shown. A new maximum number of paging records for MTCD is set. The conventional maximum number of paging records is used for normal UE, and the newly set maximum number of paging records is used for MTCD. The parameter indicating the conventional maximum number of paging records is set to "maxpagerec", and the maximum number of callable normal UEs is set to this. The newly set parameter indicating the maximum number of paging records is set to "mtc-maxpagerec", and the maximum number of callable MTCDs is set to this. By using this method, the maximum number of paging records included in a paging message can be set separately for normal UE and MTCD.

[0139] A paging record list may also be newly provided for MTCD. A parameter representing the conventional paging record list may be set as "pagingrecordlist", and mobile terminal identifiers up to the maximum value of the number of paging records for normal UE (maxpagerec), specifically IMSI or s-TMSI, may be described in this. A parameter representing the newly provided paging record list may be set as "mtc-pagingrecordlist", and mobile terminal identifiers up to the maximum value of the number of paging records for MTCD (mtc-maxpagerec), specifically IMSI or s-TMSI, may be described in this.

[0140] Fig. 15 is a diagram showing an example of information included in a paging message in the first embodiment. As shown in Fig. 15, the paging message includes a list of paging records (pagingrecordlist) in which the mobile terminal identifiers of normal UEs to be called are described up to the maximum value of the number of paging records (maxpagerec) of normal UEs, and a list of paging records (mtc-pagingrecordlist) in which the mobile terminal identifiers of MTCDs to be called are described up to the maximum value of the number of paging records (mtc-maxpagerec) of MTCDs.

[0141] The eNB that receives the paging message from the MME determines the timing (PF / PO) for transmitting the paging message from the mobile terminal identifier of the mobile terminal to be called. When multiple mobile terminals are called simultaneously, the multiple mobile terminals may be called with the same paging message at the same timing (PF / PO) determined by the mobile terminal identifier. When multiple MTCDs are called simultaneously, multiple mobile terminals, particularly multiple MTCDs, will be called with the same paging message at the same timing (PF / PO).

[0142] The eNB describes the mobile terminal identifiers of one or more normal UEs to be called by the same paging message in a paging record of a paging record list (pagingrecordlist) up to the maximum number of paging records (maxpagerec) of normal UEs. Furthermore, the eNB describes the mobile terminal identifiers of one or more MTCDs to be called by the same paging message in a paging record of a paging record list (mtc-pagingrecordlist) up to the maximum number of paging records (mtc-maxpagerec) of MTCDs. The paging message is periodically and discontinuously transmitted at the timing (PF / PO).

[0143] The normal UE and MTCD, which are mobile terminals, receive intermittently at the timing of PF / PO derived from the mobile terminal identifier of the own station, and receive the paging message when a paging message exists. If the mobile terminal identifier of the own station exists in the paging record of the paging record list of the paging message, the normal UE determines that there is a call and starts uplink access. If the mobile terminal identifier of the own station exists in the paging record of the mtc-paging record list of the paging message, the MTCD determines that there is a call and starts uplink access.

[0144] In this way, by providing the maximum number of paging records and the paging record list for normal UE and MTCD separately in the paging message, it is possible to suppress the impact on normal UE even in a situation where a single paging message calls many mobile terminals. This makes it possible to prevent an increase in the delay time of paging for normal UE, which has a particularly large impact on the system.

[0145] An identifier for each MTC group may be provided and described in the MTC paging record, instead of a mobile terminal identifier for each MTCD. The identifier for each MTC group may be assigned from among conventional mobile terminal identifiers (UE-ID), or an identifier dedicated to the MTC group may be provided in addition to conventional mobile terminal identifiers. When an identifier for each MTC group is described in the MTC paging record, calling for each MTC group becomes possible.

[0146] When an identifier for each MTC group is described in the paging record of the MTC, the maximum number of paging records of the MTCD (mtc-maxpagerec) may be applied to the maximum number of paging records. In this case, it is sufficient to set so that the total number of the mobile terminal identifiers for each MTCD and the identifiers for each MTC group does not exceed the maximum number of paging records of the MTCD.

[0147] When describing an identifier for each MTC group in the paging record of MTC, another method may be to set the maximum number of paging records of the MTC group separately from the maximum number of paging records of normal UE and the maximum number of paging records of MTCD. The parameter representing the maximum number of paging records of the MTC group may be set to "mtcg-maxpagerec", and the maximum number of MTC groups that can be called may be set to this. By using this method, the maximum number of paging records of the MTC group included in the paging message may be set separately from normal UE and MTCD. A paging record list may also be newly provided for the MTC group. The parameter representing the paging record list for the MTC group may be set to "mtcg-pagingrecordlist", and MTC group identifiers up to the maximum number of paging records of the MTC group (mtcg-maxpagerec) may be described in this.

[0148] The maximum number of paging records of an MTCD (mtc-maxpagerec) and the maximum number of paging records of an MTC group (mtcg-maxpagerec) may be set statically or semi-statically.

[0149] In the case of static setting, the maximum number of paging records can be recognized by the MTCD and the eNB by describing the maximum number of paging records in advance in the standard. In this case, since the signaling of the parameter is not required, communication errors do not occur, and it is possible to reduce the consumption of radio resources.

[0150] In the case of semi-static setting, the setting node may be the eNB or the MME. In the case of setting by the eNB, the maximum number of paging records may be notified to the mobile terminals under its control as system information from the eNB. In the case of setting by the MME, the maximum number of paging records may be notified to the eNB from the MME using an S1 signaling message on the S1 interface. This enables the eNB to notify the maximum number of paging records to the mobile terminals under its control.

[0151] FIG. 16 is a diagram showing an example of a paging sequence in the case where the maximum value of the number of paging records for the MTCD is set semi-statically. In Step ST1601, the MME determines the maximum value of the number of paging records for the MTCD. In Step ST1602, the MME notifies the eNB of the determined maximum value by S1 signaling. In Step ST1603, the eNB notifies the maximum value as system information to a mobile terminal (UE) being served by the eNB. This makes it possible for the mobile terminal to recognize the maximum value of the number of paging records for the MTCD included in the paging message.

[0152] Steps ST1604 to ST1607 are the same paging sequence as steps ST1401 to ST1404 shown in FIG. 14 described above, but disclose a call to an MTCD as a mobile terminal.

[0153] In Step ST1604, an incoming call message is notified to the MME from the originating party. The incoming call message includes the identifier of the destination MTCD. In Step ST1605, the MME searches the TA list for the MTCD identifier. In Step ST1606, the MME transmits a paging message to one or more eNBs. The paging message includes the identifier of the destination MTCD. In Step ST1607, the eNB that has received the paging message transmits a paging message to a mobile terminal under its control. The paging message includes the identifier of the destination MTCD.

[0154] As an index for the MME to determine the maximum value of the number of paging records of an MTCD or the number of paging records of an MTC group, the number of MTCDs under the MME or under the eNB, or the amount of radio resources used per cell may be used. In addition, a combination of these indices may be used. By making it possible to set the maximum value semi-statically using these indices, the maximum value of the number of paging records can be flexibly changed according to the number of MTCDs or the number of MTC groups present in a cell. This makes it possible to improve the efficiency of use of radio resources required for paging, and makes it possible to effectively utilize radio resources.

[0155] When the number of MTCDs or MTC groups in a cell is relatively large, the maximum number of paging records in the MTCDs or MTC groups is set to a relatively large value, and when the number of MTCDs or MTC groups in a cell is relatively small, the maximum number of paging records in the MTCDs or MTC groups is set to a relatively small value.

[0156] In the above-described method, a maximum number of paging records is set for each terminal type. Alternatively, a maximum number of paging records to be included in one paging message may be set, and the maximum number of paging records may be set for each terminal type for terminal types other than one terminal type.

[0157] For example, when the terminal types are normal UE and MTC group, it is sufficient to set the maximum number of paging records to be included in one paging message, and further set the maximum number of paging records for the MTC group. By doing so, it is possible to secure the number of paging records for normal UE, similar to the above-mentioned method.

[0158] By using the method disclosed in this embodiment, it becomes possible to call an MTCD without reducing the number of normal UEs that can be called in one paging message. This makes it possible to avoid downlink congestion and the resulting lack of radio resources such as a lack of radio resources for paging when paging for normal UE and paging for MTCD occur simultaneously. Therefore, it becomes possible to prevent an increase in the delay time of paging for normal UE, and to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0159] Embodiment 2 In this embodiment, another method for calling an MTCD without reducing the number of normal UEs that can be called via one paging message is disclosed.

[0160] As a specific method, an indicator for calling an MTCD (hereinafter, sometimes referred to as an "indicator for calling an MTCD") is provided in a paging message. It is preferable to provide an indicator for calling an MTCD as information other than a paging record of a paging message.

[0161] FIG. 17 is a diagram showing an example of information included in a paging message in the second embodiment. The indicator for calling an MTCD is "mtc-indication". As shown in FIG. 17, the paging message in the present embodiment includes "mtc-indication" in addition to information included in a conventional paging message, specifically, "pagingrecordlist", "systeminfomodification" and "etws-indication". "mtc-indication" may be 1-bit information, with "1" or "true" indicating that an MTCD is called, and "0" or "false" indicating that an MTCD is not called.

[0162] When the MTCD recognizes that the paging message of the PF / PO derived from the mobile terminal identifier of the own station includes an MTCD calling indicator (mtc-indication), that is, that the indicator is true, the MTCD starts uplink access.

[0163] With this configuration, it is not necessary to include an MTCD or MTC group identifier in the paging record of a paging message in order to call an MTCD, so that it is possible to call an MTCD without reducing the number of normal UEs that can be included in a paging record in one paging message. This makes it possible to avoid downlink congestion and the resulting shortage of radio resources for paging when paging for normal UE and paging for MTCD occur simultaneously. Therefore, it is possible to prevent an increase in the delay time of paging for normal UE, and it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0164] When an incoming call occurs not to an MTCD but to an MTC group, the MTC group and the MTCDs belonging to the MTC group need to be associated with each other in order to transmit paging to the MTCDs belonging to the MTC group. As a node that associates the MTC group with the MTCDs belonging to the MTC group, an MME or an eNB may be used.

[0165] In order to associate an MTC group with an MTCD belonging to the MTC group, it is preferable to provide a correspondence list that associates an MTC group identifier with a mobile terminal identifier of an MTCD belonging to the MTC group. The correspondence list may be configured and managed by the HSS, the MME, or the eNB.

[0166] When the MME performs the association between the MTC group and the MTCD belonging to the MTC group, the MME may acquire information required for the association in advance from the HSS, the MME itself, or the eNB. The information required for the association is the above-mentioned association list.

[0167] 18 is a diagram showing an example of a paging sequence in a case where an MME associates an MTC group with an MTCD belonging to the MTC group. In Step ST1802, the MME that has received an incoming call in Step ST1801 derives a mobile terminal identifier of an MTCD that belongs to the MTC group of the MTC group identifier, based on an MTC group identifier included in the received incoming call message. The MME may acquire, from the HSS, information required for deriving a mobile terminal identifier of an MTCD, for example, a correspondence list between an MTC group identifier and a mobile terminal identifier of an MTCD that belongs to the MTC group of the MTC group identifier.

[0168] In Step ST1803, the MME searches for the TA list of the derived mobile terminal identifier of the MTCD. In this case, the MME may also obtain information required to search for the TA list of the mobile terminal identifier of the MTCD from the HSS.

[0169] In Step ST1804, the MME initiates a paging procedure by transmitting a paging message to one or more eNBs in the TA list. The paging message includes a mobile terminal identifier of the MTCD to be called. In Step ST1805, the eNB that has received the paging message transmits a paging to a mobile terminal (UE) under its control. The paging message does not include a mobile terminal identifier of the MTCD to be called, but includes an indicator (mtc-indication) for calling an MTCD.

[0170] The paging message transmitted from the MME to the eNB may include identifiers of one or more MTCDs belonging to one MTC group to be called. In this case, the eNB that has received one paging message transmits a paging message including an MTCD calling indicator (mtc-indication) to one or more MTCDs based on the identifiers of one or more MTCDs included in the received paging message. In this way, only one paging signal is required between the MME and the eNB, so that the amount of S1 signaling can be reduced.

[0171] A TA list for the MTC group may be newly prepared. The TA list for the MTC group may be used when paging disclosed herein occurs for the MTC group. Information on the TA list for the MTC group may be listed and managed in the HSS, or may be listed and managed in the MME. In Step ST1803, the MME searches for the TA list for the MTC group instead of searching for the TA list for the derived MTCD identifier. At this time, if the TA list is listed and managed in the HSS, the MME may obtain the information from the HSS. The MME that has derived the TA list for the MTC group may transmit a paging message to one or more eNBs included in the TA list.

[0172] When the eNB performs the association between the MTC group and the MTCD belonging to the MTC group, the eNB may acquire information required for the association in advance from the HSS, the MME, or the eNB itself. When acquiring information from the HSS, the information may be acquired via the MME. The information required for the association is the above-mentioned association list.

[0173] The MME transmits a paging message including an MTC group identifier to one or more eNBs included in the TA list of the MTC group. The eNB receives the MTC group identifier and derives an MTCD belonging to the MTC group of the identifier based on the association in the above-mentioned association list. The eNB transmits a paging message to each of the derived MTCDs. The paging message includes an indicator (mtc-indication) for calling an MTCD. This allows only one paging signal between the MME and the eNB for each group, making it possible to reduce the amount of S1 signaling.

[0174] Second embodiment, modified example 1 In the method of the above-mentioned embodiment 2, there is only one MTCD calling indicator (mtc-indication). Therefore, when multiple MTC groups exist in a cell and paging occurs simultaneously to MTCDs belonging to different MTC groups, the MTCD cannot determine whether the paging is directed to the MTC group to which the MTCD belongs.

[0175] To solve this problem, in this modification, an indicator for calling an MTC group is provided in the paging message instead of an indicator for calling an MTCD.

[0176] As a specific example of the indicator for calling an MTC group, an identifier of an MTC group may be used. When the indicator for calling an MTC group is an identifier of an MTC group, the indicator for calling an MTC group may have the number of bits required for the identifier of the MTC group.

[0177] When the MTCD recognizes that the paging message of the PF / PO derived from the mobile terminal identifier of the own station contains the identifier of the MTC group to which the own MTCD belongs as an indicator for calling the MTC group, the MTCD starts uplink access.

[0178] By configuring in this way, even if paging occurs simultaneously to MTCDs belonging to different MTC groups, it is possible to notify the MTCD of which MTC group the call is for. Since the MTCD can determine whether the paging message is a call for the MTC group to which the MTCD belongs, it can determine whether to start uplink access following reception of the paging message. This makes it possible to not start uplink access when the call is not for the MTC group to which the MTCD belongs, thereby achieving low power consumption.

[0179] The MTC group identifier is assigned to each system. Since the number of MTC groups in the system is expected to be large, the number of bits required for the MTC group identifier will be large. Therefore, if the MTC group identifier is used as an indicator for calling the MTC group as in the above-mentioned method, the number of bits required for the indicator for calling the MTC group will be large.

[0180] Therefore, as another example of an indicator for calling an MTC group, an identifier of an MTC group for each cell may be used.

[0181] Considering a certain cell, the number of MTC services supported by one cell is limited. Since an MTC group may be configured for each MTC service, the number of MTC groups supported by one cell is also smaller than the number of MTC groups supported by the system. Therefore, by reassigning the MTC group identifiers in the system for each cell, it is possible to reduce the amount of information of the MTC group identifiers.

[0182] When reassigning the MTC group identifier for each cell in the system, for example, the eNB may assign the MTC group identifier for each cell. In the attach procedure between the MTCD and the MME, the eNB notifies the MTCD of the MTC group identifier for each cell of the MTC group to which the MTCD belongs by an RRC signaling message.

[0183] 19 is a diagram showing an example of a paging sequence in the case where an eNB assigns an MTC group identifier for each cell. In Step ST1901, when an MTCD starts an attach procedure, an MME performs resource configuration with an upper node, and notifies an attach accept message to an eNB in ​​Step ST1902. The attach accept message includes an MTC group identifier to which the MTCD belongs.

[0184] In step ST1903, the eNB converts the MTC group identifier in the system into an MTC group identifier for each cell. The correspondence in the conversion of the MTC group identifier is stored in the eNB. For example, the correspondence may be stored in the control unit 911 or the protocol processing unit 903 of the eNB shown in FIG.

[0185] In Step ST1904, the eNB includes the MTC group identifier for each cell after the conversion in an RRC connection reconfiguration message and transmits the message to the MTCD. The MTCD that receives the RRC connection reconfiguration message recognizes the MTC group identifier for each cell. Here, the MTC group identifier for each cell after the conversion is included in the RRC connection reconfiguration message, but this is not limiting, and the MTC group identifier for each cell after the conversion may be included in an attach completion message transmitted from the eNB to the MTCD.

[0186] The MME that has received the incoming call in Step ST1905 derives, based on the MTC group identifier included in the incoming call message, a mobile terminal identifier of an MTCD that belongs to the MTC group of the MTC group identifier in Step ST1906. The MME may acquire, from the HSS, information required for deriving a mobile terminal identifier of an MTCD that belongs to the MTC group, for example, a correspondence list between the MTC group identifier and the mobile terminal identifier of the MTCD that belongs to the MTC group of the MTC group identifier.

[0187] In Step ST1907, the MME searches for the TA list of the derived mobile terminal identifier of the MTCD. In this case, the MME may also obtain information required to search for the TA list of the mobile terminal identifier of the MTCD from the HSS.

[0188] In Step ST1908, the MME initiates a paging procedure by transmitting a paging message to one or more eNBs in the TA list. The paging message includes a mobile terminal identifier of the MTCD to be called.

[0189] In Step ST1909, the eNB that has received the paging message derives an MTC group identifier for each cell from the MTC group identifier in the system. The eNB uses the correspondence relationship in the conversion performed in Step ST1903 to derive the MTC group identifier for each cell.

[0190] In Step ST1910, the eNB transmits paging to the user equipment (UE) being served by the eNB. The paging message includes an MTC group identifier for each cell in the MTC group to be called.

[0191] When the MTCD recognizes that the paging message of the PF / PO derived from the mobile terminal identifier of the own station contains the identifier of the MTC group for each cell to which the own MTCD belongs, received in Step ST1904, as an indicator for calling an MTC group, the MTCD starts uplink access.

[0192] Also, the MTC group identifier may be an MTC group identifier for each TA, not an MTC group identifier for each cell. In this case, the MME may assign the MTC group identifier for each TA. In an attach procedure between the MTCD and the MME, the MME notifies the eNB of the MTC group identifier for each TA to which the MTCD belongs by using an attach accept message. The eNB notifies the MTCD of the MTC group identifier for each TA by using an RRC signaling message.

[0193] As described above, by providing an MTC group identifier for each cell or TA and using this identifier for calling an MTC group, the number of bits of the indicator for calling an MTC group can be reduced. This makes it possible to reduce radio resources when calling a large number of MTCDs, and to avoid congestion.

[0194] As described above, providing an MTC group identifier for each cell or TA can also be applied to the case where an MTC group identifier is used in a paging record in a paging message. This allows the number of bits of a paging record to be reduced, so that the maximum number of paging records can be increased, and the number of mobile terminals that can be called by one paging message can be increased. Therefore, it is possible to reduce the impact on normal UE calling.

[0195] Second embodiment, modified example 2 In the above-mentioned second embodiment and the first modification of the second embodiment, the case where the mobile terminal identifier of the MTCD is used to derive the PF / PO has been described. In this modification, the MTC group identifier is used instead of the mobile terminal identifier of the MTCD to derive the PF / PO. The MTC group identifier may be the MTC group identifier of the system, and may also be the MTC group identifier for each TA or the MTC group identifier for each cell.

[0196] The MTCD derives the PF / PO from the identifier of its own MTC group, and when it recognizes that the paging message contains an indicator for calling the MTC, that is, that the indicator is true, it starts uplink access.

[0197] By using this method, the PF / PO is distributed among the MTC groups, so the possibility that multiple MTC groups will have the same PF / PO is greatly reduced. This greatly reduces the possibility that an MTCD will start uplink access for paging to an MTC group other than the MTC group to which the MTCD belongs. Therefore, it is possible to reduce the power consumption of the MTCD and to reduce unnecessary uplink signaling, thereby avoiding uplink congestion.

[0198] As an MTC group identifier for deriving a PF / PO, an MTC group identifier that derives a different PF / PO for each MTC group may be assigned to each MTC group. By configuring in this way, it is possible to prevent paging messages of multiple MTC groups from being generated with the same PF / PO.

[0199] This method is about allocating MTC group identifiers only to MTCDs, so there is no need to reallocate identifiers allocated to legacy mobile terminals, i.e., mobile terminals of older release standards. Therefore, when MTC is supported in a new version, it can be easily introduced without affecting legacy mobile terminals.

[0200] Instead of providing an MTC group identifier, the same mobile terminal identifier may be assigned to all MTCDs in the same MTC group. Instead of providing a separate MTC group identifier, a mobile terminal identifier may be used as the MTC group identifier.

[0201] A mobile terminal identifier for each MTC group may be dedicated for paging. In a paging message, IMSI and s-TMSI, which are mobile terminal identifiers for each MTC group, may be used as indicators for calling the MTC group, or IMSI and s-TMSI, which are mobile terminal identifiers for each MTC group, may be included in a paging record.

[0202] Also, it may be used when deriving the PF / PO. That is, the UE_ID or IMSI for each MTC group may be used as the mobile terminal identifier used when deriving the PF / PO.

[0203] Also, a mobile terminal identifier for each MTCD may be assigned separately from the mobile terminal identifier dedicated to paging. That is, a mobile terminal identifier for each mobile terminal and a mobile terminal identifier for each MTC group may be assigned doubly to one MTCD.

[0204] The MTCD derives the PF / PO from the UE_ID or IMSI, which is a mobile terminal identifier dedicated for paging of the MTC group to which the MTCD belongs, and starts uplink access when it recognizes that the IMSI or s-TMSI, which is a mobile terminal identifier assigned to each MTC group, is described in the paging record of the paging message mapped to that subframe.

[0205] According to the method described above, MTC group identifiers can be assigned from among conventional mobile terminal identifiers, so there is no need to set up a new system or rule for identifiers, and the system can be simplified, and control at each node can be simplified.

[0206] Embodiment 3 In this embodiment, another method for calling an MTCD without reducing the number of normal UEs that can be called on one paging message is disclosed.

[0207] Non-Patent Document 12 discloses a method of resolving the shortage of radio resources for paging for normal UE by assigning a mobile terminal identifier to an MTCD such that the MTCD and normal UE have different PF / POs. However, in the method disclosed in Non-Patent Document 12, it is necessary to assign a mobile terminal identifier to an MTCD including a legacy mobile terminal so that the paging groups are different between the MTCD and normal UE. Since a mobile terminal identifier has already been assigned to a legacy mobile terminal, it is a complicated and difficult task for an operator to perform the above-mentioned assignment again.

[0208] In this embodiment, the PF / PO where paging for normal UE occurs is made different from the PF / PO where paging for MTCD occurs.

[0209] An example of a method for differentiating the PO is as follows: The subframe to which the paging message is mapped is made different in advance.

[0210] Fig. 20 is a diagram showing subframes (PO) onto which paging determined in the current LTE is mapped. "N / A" in Fig. 20 indicates that there is no corresponding value (Not Available). A subframe number is determined according to Ns derived according to Non-Patent Document 3 and i_s derived using the UE_ID or IMSI of a mobile terminal according to Non-Patent Document 3. This is set as a subframe onto which paging for normal UE is mapped, and a subframe onto which paging for MTCD is mapped is provided separately from this.

[0211] Fig. 21 is a diagram showing subframes to which paging for MTCD is mapped. "N / A" shown in Fig. 21 indicates that there is no corresponding value (Not Available). A subframe number is determined according to Ns derived according to Non-Patent Document 3 and i_s derived from the UE_ID or IMSI of the MTCD according to Non-Patent Document 3.

[0212] As shown in Figures 20 and 21, by making the subframes in which paging messages are mapped different between normal UE and MTCD in advance, paging for normal UE and paging for MTCD do not occur in the same subframe. This prevents a call to a normal UE and a call to an MTCD from being included in one paging message. In addition, the conventional method can be applied to the method of allocating mobile terminal identifiers.

[0213] Therefore, when many MTCDs exist in a cell, it becomes possible to call MTCDs, including legacy mobile terminals, without reducing the number of normal UEs that can be called by one paging message. This makes it possible to prevent an increase in the delay time of paging for normal UEs, and to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0214] The number of subframes to which paging for MTCD is mapped may be one. For example, as disclosed in the second embodiment, by making the configuration unnecessary for paging records by using an indicator for MTCD calling, the number of MTCDs that can be called by one paging message is eliminated. Therefore, it is not necessary to set multiple subframes.

[0215] Fig. 22 is a diagram showing an example of a subframe in the case where the subframe to which paging for MTCD is mapped is one. Fig. 23 is a diagram showing another example of a subframe in the case where the subframe to which paging for MTCD is mapped is one. In this way, by setting the subframe to which paging for MTCD is mapped to one, regardless of the mobile terminal identifier of the MTCD, it is possible to reduce the influence on the MBSFN subframe.

[0216] Third embodiment, variant 1 In this modification, an example of a method for differentiating the PF is shown, in which the radio frame to which the paging message is mapped is made different in advance.

[0217] 24 is a diagram showing radio frames (PFs) onto which paging is mapped, as determined in the current LTE. Here, the DRX cycle T is set to T=32, and the parameter nB, which determines the number of times PF occurs within one DRX cycle, is set to nB=16. The method of deriving the PF is described in Non-Patent Document 3.

[0218] In Fig. 24, the radio frames indicated by diagonal lines are assumed to be radio frames onto which paging for UE is mapped. Since the period T is 32, one period is made up of radio frame (rf) numbers "0" to "31". Since nB=T / 2, the radio frame (PF) in which paging occurs is an even-numbered radio frame. The subframe number in which paging occurs within the PF is assumed to be "9". This PF is assumed to be the radio frame onto which paging for normal UE is mapped, and a radio frame onto which paging for MTCD is mapped is provided separately from this.

[0219] Fig. 25 is a diagram showing radio frames (PF) to which paging for MTCD is mapped. As in Fig. 24, T=32 and nB=16. In Fig. 25, radio frames indicated by diagonal lines, specifically, radio frames with odd numbers, are assumed to be radio frames to which paging for MTCD is mapped. In this way, the radio frames to which paging for MTCD is mapped are made different from the radio frames to which paging for normal UE is mapped.

[0220] As an example of a method for deriving the radio frame (PF) to which paging for MTCD is mapped, the following derivation formula (2) may be used.

[0221] SFN mod T=(T div N)*(UE_ID mod N)+k …(2) where k=1 The value of k in formula (2) may be set according to nB. For example, when nB=T / 4, k may be set to any one of 1, 2, and 3. As another example, k may be set to 2*nB / T.

[0222] As another example, the following derived formula (3) may be used.

[0223] SFN mod T=(T div N)*(UE_ID mod N) +1+(UE_ID mod (m-1)) …(3) where m = nB / T This makes it possible to use all radio frames to which paging for normal UE is not mapped as radio frames to which paging for MTCD is mapped.

[0224] As disclosed in this modification, by making the radio frame (PF) in which paging of normal UE occurs different from the radio frame (PF) in which paging of MTCD occurs, paging for normal UE and paging for MTCD do not occur in the same radio frame. As a result, a call for normal UE and a call for MTCD are not included in one paging message. In addition, the conventional method can be applied to the method of allocating mobile terminal identifiers.

[0225] Therefore, when a large number of MTCDs exist in a cell, it becomes possible to page the MTCDs without reducing the number of normal UEs, including legacy mobile terminals, that can be paged on one paging message.

[0226] The above example is applicable when T>nB. When T≦nB, paging for normal UE is mapped to all radio frames, and therefore it is not possible to map paging for MTCD to different radio frames.

[0227] To solve this problem, the MME or eNB may determine the values ​​of T and nB according to the number of mobile terminals present in the TA or cell, i.e., the number of normal UEs and the number of MTCDs. The value of k in formula (2) may be determined in the same manner as the values ​​of T and nB, or may be statically determined in advance.

[0228] In this way, by the MME or eNB determining the values ​​of T and nB, when a large number of MTCDs exist in a cell, it becomes possible to call an MTCD without reducing the number of normal UEs that can be called by one paging message.

[0229] Alternatively, the radio frame (PF) in which paging occurs may be changed when T>nB, and the subframe (PO) in which paging occurs may be changed when T≦nB. As a method of changing the radio frame (PF) in which paging occurs when T>nB, the method disclosed in this modification may be applied, and as a method of changing the subframe (PO) in which paging occurs when T≦nB, the method disclosed in the third embodiment may be applied.

[0230] By configuring in this way, when a large number of MTCDs exist, it is possible to call the MTCDs without reducing the number of normal UEs that can be called by one paging message.

[0231] Third embodiment, variant 2 In the above-mentioned third embodiment and the first modification of the third embodiment, the same values ​​of T and nB are used for deriving the PF / PO of a normal UE and for deriving the PF / PO of an MTCD. In this modification, as another method, the values ​​of T and nB are made different for deriving the PF / PO of a normal UE and for deriving the PF / PO of an MTCD. As a specific example, T and nB are used for deriving the PF / PO of a normal UE, and new T_mtc and nB_mtc are provided for deriving the PF / PO of an MTCD.

[0232] The PF / PO may be derived by applying the methods disclosed in the third embodiment and the first modification of the third embodiment. In this case, when deriving the PF / PO of the MTCD, T_mtc and nB_mtc may be used instead of T and nB.

[0233] The eNB may report T and nB as system information to the mobile terminals under its control. By configuring in this way, the DRX cycle can be made different between normal UE and MTCD, and it becomes possible to set the DRX cycle according to the services supported by each type of mobile terminal. This makes it possible to make the power consumption during paging standby different for each type of mobile terminal.

[0234] The relationship between T and T_mtc may be as shown in the following formula (4).

[0235] T_mtc=a*T …(4) Furthermore, the relationship between nB and nB_mtc may be as shown in the following formula (5).

[0236] nB≦nB_mtc …(5) By applying the method disclosed in the first modification of the third embodiment as the above-mentioned setting, it is possible to make the radio frame (PF) in which paging of a normal UE occurs different from the radio frame (PF) in which paging of an MTCD occurs.

[0237] The MTCD derives a PF / PO for the MTCD by using the UE_ID and IMSI which are mobile terminal identifiers of the own station by the method disclosed in the third embodiment to the second modification of the third embodiment. Then, when the MTCD recognizes that the IMSI or s-TMSI which is the mobile terminal identifier of the own station is included in the paging record of the paging message, the MTCD starts uplink access.

[0238] Even if a method of calling a mobile terminal is used by placing mobile terminal identifiers of normal UE and MTCD, which are mobile terminals, in a paging record, the PF / PO of normal UE and MTCD can be made different by applying the methods disclosed in the third embodiment to the second modification of the third embodiment. Therefore, it becomes possible to call an MTCD without reducing the number of normal UEs that can be called on one paging message.

[0239] The methods disclosed in the third embodiment to the second modification of the third embodiment and the methods disclosed in the second embodiment to the second modification of the second embodiment can be used in combination. The methods disclosed in the third embodiment to the second modification of the third embodiment can also be applied to the case where an indicator for invoking MTC is provided in a paging message as disclosed in the second embodiment to the second modification of the second embodiment. This makes it possible to prevent an increase in the delay time of paging for normal UE by suppressing the effect on normal UE without significantly increasing the amount of information in the paging message.

[0240] Moreover, the methods disclosed in the third embodiment to the second modification of the third embodiment are also applicable to the case where an MTC group identifier is used. This makes it possible to prevent an increase in the delay time of paging for normal UE by suppressing the influence on normal UE without significantly increasing the amount of information in the paging message, similar to the case where the method is applied to the case where an indicator for MTC calling is provided in the paging message.

[0241] Embodiment 4 In this embodiment, another method for calling an MTCD without reducing the number of normal UEs that can be called on one paging message is disclosed.

[0242] A new radio frame and subframe are provided for mapping paging messages for MTCD. A method different from the method for deriving the PF / PO for paging is used. In other words, at least when deriving the PF, the mobile terminal identifier is not used.

[0243] It is preferable to newly set a period, an offset value, and a subframe number as the configuration of the radio frame and the subframe. For example, the period is mtc-period, the offset value is mtc-offset, and the subframe number is mtc-subframe.

[0244] FIG. 26 is a diagram showing the configuration of a radio frame and a subframe to which an MTCD-directed paging message disclosed in the fourth embodiment is mapped. The radio frame to which an MTCD-directed paging message is mapped is periodic, the period is "mtc-period", and an offset value for determining a radio frame number is "mtc-offset". Also, the subframe to which an MTCD-directed paging message is mapped is "mtc-subframe". FIG. 26 shows a case where, for example, mtc-offset is "1" and mtc-subframe is "1".

[0245] The period, offset value, and subframe number of the radio frame in which the paging message for the MTCD is mapped may be determined by the MME or eNB. Also, the period, offset value, and subframe number of the radio frame may be notified to the MTCD from the eNB as system information.

[0246] In addition, the period of the radio frame to which the paging message for MTCD is mapped may be a divisor of the maximum value of the radio frame number. When the radio frame number to which the paging message is mapped exceeds the maximum value, the period can be configured not to change even if the count is restarted from a new offset value.

[0247] By configuring in this way, it is possible to set a radio frame and a subframe to which a paging message for an MTCD is mapped, using a method different from a PF / PO for calling a normal UE. This makes it possible to flexibly set a paging cycle, offset, and subframe for an MTCD according to an MTC service. Therefore, it becomes possible to control the power supply of an MTCD suitable for an MTC service, and it becomes possible to optimize the power consumption of the MTCD.

[0248] A method for making the radio frames and subframes in which paging occurs different between normal UE and MTCD will be disclosed.

[0249] In order to make the subframe different, a subframe different from the PO of the normal UE may be set. The eNB recognizes the subframe to which the PO of the normal UE is mapped. Therefore, it is possible to make the subframe in which the paging of the MTCD occurs different.

[0250] For example, in derivation of a PO for normal UE, if T and nB are set so that Ns=2, the subframe numbers are 4 and 9. The subframes in which MTCD paging occurs may be set to other subframe numbers than 4 and 9. For example, mtc-subframe=1 may be set.

[0251] In order to make the radio frame different, a radio frame different from the PF of normal UE may be set. The eNB recognizes the radio frame to which the PF of normal UE is mapped. Therefore, it is possible to make the radio frame in which paging of the MTCD occurs different.

[0252] For example, in the derivation of a PF for normal UE, if T=32 and nB=T / 2 are set as shown in FIG. 24 described above, the radio frame will be an even number. Therefore, the radio frame in which paging of the MTCD occurs may be an odd number. For example, the period may be set to the number of even numbered radio frames, and the offset value may be set to the odd numbered radio frames. For example, mtc-period=1024 and mtc-offset=1 may be set.

[0253] In this manner, in the present embodiment, it is possible to map a paging message for MTCD avoiding subframes of PF / PO for normal UE. This makes it possible to call an MTCD without reducing the number of normal UEs that can be called on one paging message. Therefore, it is possible to prevent an increase in the delay time of paging for normal UE, and it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0254] The period, offset value and subframe number may be set for each MTC group.

[0255] 27 is a diagram showing an example of a case where a period, an offset value, and a subframe number are set for each of two MTC groups. Of the two MTC groups, the period, offset value, and subframe number of the radio frame to which a paging message for the first MTC group is mapped are set to mtc-period#1, mtc-offset#1, and mtc-subframe#1. The period, offset value, and subframe number of the radio frame to which a paging message for the second MTC group is mapped are set to mtc-period#2, mtc-offset#2, and mtc-subframe#2.

[0256] The period, offset value, and subframe number for each MTC group may be notified to the mobile terminal under its control by the eNB as system information. By configuring in this way, it is possible to set according to each MTC service. Therefore, since the power supply control of the MTCD for each MTC service is possible, it is possible to optimize the power consumption of the MTCD for each MTC service.

[0257] Also, the periods of each MTC group may be in a relationship of divisors or multiples. Alternatively, the possible periods may be a power of 2 (2 n ) and adjust the offset value of each MTC group, it is possible to prevent paging for multiple MTC groups from occurring simultaneously.

[0258] By using the method disclosed in the present embodiment, it is possible to set radio frames and subframes in which paging of an MTCD occurs relatively easily and flexibly, compared with the methods disclosed in the above-described second and third embodiments.

[0259] Embodiment 5. As a measure to reduce the paging load, a technology of introducing a special paging RNTI (MTC specific paging RNTI) into the MTC for the purpose of paging in M2M communication is disclosed in Non-Patent Document 9. By providing a special paging RNTI in the MTC in addition to the normal paging RNTI (P-RNTI), a normal UE only needs to detect the P-RNTI, and an MTCD only needs to detect the special paging RNTI in the MTC. That is, a normal UE does not need to receive a paging message for paging for the MTCD. Conversely, an MTCD does not need to receive a paging message for a normal UE. This allows a normal UE and a UE including an MTCD to simplify reception processing and reduce power consumption.

[0260] However, when paging for normal UE and paging for MTCD occur in the same subframe, a problem occurs in which the eNB cannot determine whether to mask the P-RNTI or the RNTI for paging special to the MTC in the allocation information of the paging message.

[0261] In this embodiment, a method for solving this problem is disclosed. When paging for normal UE and paging for MTCD occur in the same subframe, the eNB masks the P-RNTI in the allocation information of the paging message.

[0262] A normal UE is configured to detect the presence or absence of allocation information masked with a P-RNTI in a PDCCH of a subframe of a PF / PO derived from the mobile terminal identifier of the own station. If allocation information masked with a P-RNTI is present, the normal UE may receive a paging message according to the allocation information.

[0263] In response to this, the MTCD is configured to detect not only the presence or absence of allocation information in which a special paging RNTI is masked in the MTC, but also the presence or absence of allocation information in which a P-RNTI is masked, in the PDCCH of the subframe of the PF / PO derived from the mobile terminal identifier of the own station. When the MTC has allocation information masked with the special paging RNTI or the P-RNTI, the MTCD may receive a paging message according to the allocation information.

[0264] By configuring in this manner, even if paging for normal UE and paging for MTCD occur in the same subframe, each mobile terminal can receive the paging without causing any malfunction.

[0265] In addition, the normal UE can receive paging in the same manner as in the conventional paging reception method. This makes it possible to perform paging to the MTCD without affecting the normal UE.

[0266] Fig. 28 is a flowchart showing a processing procedure of the RNTI masking method of the eNB in ​​the fifth embodiment. The flowchart in Fig. 28 shows a case where the eNB receives a paging message. In Step ST2301, the eNB derives a PF / PO of a paging message for normal UE. In Step ST2302, the eNB derives a PF / PO of a paging message for MTCD. There may be a plurality of normal UE-oriented paging messages and a plurality of MTCD-oriented paging messages. The eNB derives a PF / PO for each of the number of paging messages.

[0267] In Step ST2303, the eNB judges whether the PF / PO of paging for normal UE is the same as the PF / PO of paging for MTCD. If there are multiple pagings of each type, it is sufficient to determine whether there are any that are the same. If the eNB judges that the PF / PO of paging for normal UE is the same as the PF / PO of paging for MTCD, it moves to Step ST2304. If the eNB judges that the PF / PO of paging for normal UE is not the same as the PF / PO of paging for MTCD, it moves to Step ST2307.

[0268] In Step ST2304, the eNB puts the UE-ID of the normal UE and the identifier of the MTC group to which the MTCD belongs in the same paging message. In Step ST2305, the eNB masks allocation information of the physical resource to which the paging message is mapped with the P-RNTI, and maps the information to the PDCCH.

[0269] In Step ST2306, the eNB transmits the PDCCH and the paging message in the subframe of the PF / PO derived in Step ST2301 or Step ST2302, and then ends all the processing.

[0270] When the eNB determines in Step ST2303 that the PF / PO of paging for normal UE is not the same as the PF / PO of paging for MTCD, the eNB determines in Step ST2307 whether or not the paging is for normal UE. When the eNB determines that the paging is for normal UE, the eNB moves to Step ST2308. When the eNB determines that the paging is not for normal UE, the eNB determines that the paging is for MTCD, and moves to Step ST2311.

[0271] In Step ST2308, the eNB places the UE-ID of the normal UE in the paging message. In Step ST2309, the eNB masks allocation information of the physical resource to which the paging message is mapped, with the P-RNTI, and maps the information to the PDCCH.

[0272] In Step ST2310, the eNB transmits the PDCCH and the paging message in the subframe of the PF / PO derived in Step ST2301, and then ends all the processing.

[0273] When the eNB determines in Step ST2307 that the paging is for the MTCD, the eNB places an identifier of the MTC group to which the MTCD belongs in the paging message in Step ST2311. In Step ST2312, the eNB masks allocation information of the physical resource to which the paging message is mapped with a paging RNTI special for MTC, and maps the information to the PDCCH.

[0274] In Step ST2313, the eNB transmits the PDCCH and the paging message in the subframe of the PF / PO derived in Step ST2302, and then ends all the processes.

[0275] With the above configuration, the eNB can prevent a situation in which it is not possible to determine which RNTI should be masked, even if paging for normal UE and paging for MTCD occur in the same subframe.

[0276] 29 is a flowchart showing a procedure of a process of receiving a paging message by normal UE in embodiment 5. In Step ST2401, the normal UE derives a PF / PO from a mobile terminal identifier of the own station. In Step ST2402, the normal UE detects the PDCCH in the subframe of the PF / PO by using the P-RNTI. This performs discontinuous reception.

[0277] In Step ST2403, the normal UE judges whether or not it has detected allocation information masked by the P-RNTI. If it has detected the allocation information, the normal UE proceeds to Step ST2404, and if it has not detected the allocation information, it judges that a paging message is not allocated to the subframe, returns to Step ST2402, and repeats the above-mentioned processing.

[0278] In Step ST2404, the normal UE receives a paging message in accordance with the allocation information of the PDCCH. In Step ST2405, the normal UE judges whether or not the paging message includes a mobile terminal identifier of its own station. If the normal UE judges that the mobile terminal identifier of its own station is included, it judges that there is paging and moves to Step ST2406, and if it judges that the mobile terminal identifier of its own station is not included, it judges that the paging message is not directed to its own station, returns to Step ST2402, and repeats the above-mentioned processing. In Step ST2406, the normal UE starts uplink access.

[0279] The above-described paging message reception process of the normal UE in the present embodiment is the same as the paging message reception process in a conventional mobile terminal, regardless of the presence or absence of an MTCD, that is, regardless of the presence or absence of a special paging RNTI in the MTC. Therefore, in the present embodiment, the normal UE can use the same process as the conventional paging reception method.

[0280] 30 is a flowchart showing a processing procedure of a paging message reception process of an MTCD in embodiment 5. In Step ST2501, the MTCD derives a PF / PO from a mobile terminal identifier of the own station. In Step ST2502, the MTCD performs discontinuous reception by detecting the PDCCH of the subframe of the PF / PO with an RNTI for paging special to the MTC.

[0281] In Step ST2503, the MTCD judges whether or not the MTCD has detected allocation information masked with a special paging RNTI in the MTC. If the MTCD judges that the allocation information has been detected, it moves to Step ST2504, and if the MTCD judges that the allocation information has not been detected, it moves to Step ST2507.

[0282] In Step ST2504, the MTCD receives a paging message according to the allocation information of the PDCCH. In Step ST2505, the MTCD judges whether or not the paging message includes an MTC group identifier of the MTC group to which the MTCD belongs. If the MTCD judges that the MTC group identifier is included, it judges that there is paging and moves to Step ST2506, and if the MTCD judges that the MTC group identifier is not included, it returns to Step ST2502 and repeats the above-mentioned processing.

[0283] In Step ST2506, the MTCD starts uplink access.

[0284] In Step ST2507, the MTCD performs detection processing of the allocation information masked with the P-RNTI. In Step ST2508, the MTCD judges whether or not it has detected the allocation information masked with the P-RNTI. If the MTCD judges that it has detected the allocation information, it moves to Step ST2509, and if it judges that it has not detected the allocation information, it returns to Step ST2502 and repeats the above-mentioned processing.

[0285] In Step ST2509, the MTCD receives a paging message according to the allocation information of the PDCCH. In Step ST2510, the MTCD judges whether or not the paging message includes an MTC group identifier of the MTC group to which the MTCD belongs. If the MTCD judges that the MTC group identifier is included, it judges that there is paging and moves to Step ST2511, and if the MTCD judges that the MTC group identifier is not included, it judges that the paging message is not directed to the MTCD, returns to Step ST2502, and repeats the above-mentioned processing. In Step ST2511, the MTCD starts uplink access.

[0286] In this way, the MTCD performs detection processing using both the paging RNTI and the P-RNTI special for the MTC, thereby enabling the MTCD to reliably receive a paging message for the MTCD.

[0287] By using the method disclosed in this embodiment, even if a special paging RNTI is provided for the MTC in addition to the normal paging RNTI to reduce the paging load, the eNB can determine which RNTI to mask in the allocation information of the paging message. This allows both normal UE and MTCD to reliably receive the paging message. Therefore, it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0288] Embodiment 6 In this embodiment, another method is disclosed for calling an MTCD without reducing the number of normal UEs that can be called when paging for normal UEs and paging for MTCDs occur simultaneously. As a specific method, multiple PCCHs are mapped to the same transmission time interval (TTI).

[0289] In the prior art, when paging occurs simultaneously for multiple mobile terminals, the identifiers of the multiple mobile terminals are carried in the same paging message on the same TTI, thereby calling the multiple mobile terminals.

[0290] In this embodiment, by mapping multiple PCCHs to the same TTI, even if paging for normal UE and paging for MTCD occur simultaneously, each paging message can be mapped to the same TTI, and both normal UE and MTCD can be called.

[0291] As an example, a plurality of PCCHs are provided for each terminal type. A PCCH (hereinafter sometimes referred to as "PCCH") to which a paging message for normal UE is mapped and a PCCH (hereinafter sometimes referred to as "MTC-PCCH") to which a paging message for MTCD is mapped are provided.

[0292] Figure 31 is a diagram showing the correspondence relationship between downlink logical channels, downlink transport channels, and downlink physical channels in the sixth embodiment. Figure 31(A) shows the mapping between the downlink logical channels and the downlink transport channels. Figure 31(B) shows the mapping between the downlink transport channels and the downlink physical channels.

[0293] As shown in Fig. 31(A), the PCCH of the logical channel is mapped to the PCH of the transport channel. Also, the MTC-PCCH of the logical channel is mapped to the MTC-PCH of the newly created transport channel. These processes are performed in the same TTI in the MAC.

[0294] As shown in FIG. 31(B), the PCH of the transport channel is mapped to the PDSCH of the physical channel. The MTC-PCH of the transport channel is also mapped to the PDSCH of the physical channel. The PDSCH is a shared channel. These processes are also performed in the same TTI in the physical layer.

[0295] In the same TTI, mapping to the PDSCH is performed separately for a paging message for normal UE and a paging message for MTCD. Therefore, allocation of physical resources for each PDSCH is also performed separately. Each allocation information is mapped to the PDCCH.

[0296] A different RNTI may be masked on the allocation information of the physical resource of the PDSCH to which a different PCCH is mapped, and then the PDCCH may be mapped. For example, the P-RNTI is masked on the allocation information of the PDSCH to which a paging message for normal UE is mapped. In addition, a new PI-MTC-RNTI is provided for the paging message for MTCD. The PI-MTC-RNTI is masked on the allocation information of the PDSCH to which a paging message for MTCD is mapped.

[0297] Fig. 32 is a flowchart showing a procedure of a process of a RNTI masking method performed by an eNB in ​​accordance with Embodiment 6. The flowchart in Fig. 32 shows a case where the eNB receives a paging message.

[0298] In Step ST2701, the eNB derives a PF / PO for a paging message for normal UE. In Step ST2702, the eNB derives a PF / PO for a paging message for MTCD. There may be a plurality of normal UE-oriented paging messages and a plurality of MTCD-oriented paging messages. The eNB derives a PF / PO for each of the number of paging messages.

[0299] In Step ST2703, the eNB judges whether the paging is for normal UE. If the eNB judges that the paging is for normal UE, it moves to Step ST2704. If the eNB judges that the paging is not for normal UE, it judges that the paging is for MTCD, and moves to Step ST2707.

[0300] In Step ST2704, the eNB places the UE-ID of the normal UE in the paging message. In Step ST2705, the eNB masks the allocation information of the physical resource to which the paging message is mapped with the P-RNTI and maps it to the PDCCH. In Step ST2706, the eNB transmits the PDCCH and the paging message in the subframe of the PF / PO derived in Step ST2701, and ends all the processing.

[0301] When the eNB determines in Step ST2703 that the paging is not for normal UE, that is, that the paging is for MTCD, in Step ST2707, the eNB places an identifier of the MTC group to which the MTCD belongs in the paging message. In Step ST2708, the eNB masks allocation information of the physical resource to which the paging message is mapped with the PI-MTC-RNTI and maps it to the PDCCH. In Step ST2709, the eNB transmits the PDCCH and the paging message in the subframe of the PF / PO derived in Step ST2702, and ends all processing.

[0302] With the above configuration, it becomes possible to map a plurality of PCCHs to the same TTI, and therefore it becomes possible to mask the allocation information of each paging message with a different RNTI and map it to the PDCCH.

[0303] In addition, since multiple PCCHs can be mapped in the same TTI, it is not necessary to determine whether paging for normal UE and paging for MTCD occur in the same TTI, and it is not necessary to perform different processing accordingly. Therefore, it is possible to simplify the paging processing in the eNB, which makes it possible to reduce processing delays and power consumption.

[0304] 33 is a flowchart showing a processing procedure of a receiving process of a paging message by a normal UE in embodiment 6. In Step ST2801, the normal UE derives a PF / PO from a mobile terminal identifier of the own station. In Step ST2802, the normal UE performs discontinuous reception by detecting the PDCCH in a subframe of the PF / PO using the P-RNTI.

[0305] In Step ST2803, normal UE judges whether or not it has detected allocation information masked with the P-RNTI. If it has detected the allocation information, normal UE proceeds to Step ST2804, and if it has not detected the allocation information, normal UE judges that a paging message is not allocated to the subframe, returns to Step ST2802, and repeats the above-mentioned processing.

[0306] In Step ST2804, the normal UE receives a paging message in accordance with the allocation information of the PDCCH. In Step ST2805, the normal UE judges whether or not the mobile terminal identifier of its own station is included in the paging message. If the normal UE judges that the mobile terminal identifier of its own station is included, it judges that there is paging and moves to Step ST2806, and if it judges that the mobile terminal identifier of its own station is not included, it judges that the paging message is not directed to its own station, returns to Step ST2802, and repeats the above-mentioned processing. In Step ST2806, the normal UE starts uplink access.

[0307] The above-described paging message reception process of normal UE in the present embodiment is the same as the paging message reception process in a conventional mobile terminal, regardless of the presence or absence of MTCD, i.e., the presence or absence of a special paging RNTI in the MTC. Therefore, in the present embodiment, normal UE can use the same process as the conventional paging reception method.

[0308] 34 is a flowchart showing a processing procedure of a receiving process of a paging message of an MTCD in the sixth embodiment. In Step ST2901, the MTCD derives a PF / PO from a mobile terminal identifier of the own station. In Step ST2902, the MTCD performs discontinuous reception by detecting the PDCCH of a subframe of the PF / PO using the PI-MTC-RNTI.

[0309] In Step ST2903, the MTCD judges whether or not it has detected allocation information masked by the PI-MTC-RNTI. If it has detected the allocation information, the MTCD proceeds to Step ST2904, and if it has not detected the allocation information, it judges that a paging message is not assigned to the subframe, returns to Step ST2902, and repeats the above-mentioned processing.

[0310] In Step ST2904, the MTCD receives a paging message according to the allocation information of the PDCCH. In Step ST2905, the MTCD judges whether or not the identifier of the MTC group to which the MTCD belongs is included in the paging message. If the MTCD judges that the identifier of the MTC group to which the MTCD belongs is included, the MTCD judges that there is a paging message addressed to the MTCD and proceeds to Step ST2906. If the MTCD judges that the identifier of the MTC group to which the MTCD belongs is not included, the MTCD judges that the paging message is not addressed to the MTCD and returns to Step ST2902, and repeats the above-mentioned processing. In Step ST2906, the MTCD starts uplink access.

[0311] Among the above-described paging message reception processes of the MTCD in the present embodiment, the processes other than the PDCCH detection process using the PI-MTC-RNTI and the determination process based thereon are the same as the paging reception process of the conventional mobile terminal. Therefore, the MTCD only needs to change the RNTI in the conventional paging message reception method.

[0312] In addition, since multiple PCCHs can be mapped to the same TTI and different RNTIs are masked in the respective physical resource allocation information, normal UEs can receive paging messages in the same manner as in the past. In addition, the MTCD can receive paging messages in the same manner as in the past, except that it is only necessary to change the RNTI.

[0313] In addition, in the method disclosed in the fifth embodiment, the MTCD needs to perform detection processing on both the paging RNTI and the P-RNTI special for the MTC, but in the present embodiment, it is sufficient to perform detection processing on the PDCCH with only the PI-MTC-RNTI. Therefore, it is possible to reduce the power consumption of the MTCD.

[0314] The PI-MTC-RNTI may be statically assigned in advance, or may be assigned from the eNB to the MTCD. When the PI-MTC-RNTI is assigned from the eNB to the MTCD, the eNB may notify the MTCD in advance by an RRC message.

[0315] Also, the PI-MTC-RNTI may be assigned for each MTC group. By assigning for each MTC group in this way, an effect is obtained that the MTCD does not need to receive a paging message for other MTC groups to which the own station does not belong. This makes it possible to further reduce the power consumption of the MTCD.

[0316] By using the method disclosed in this embodiment, even if paging for normal UE and paging for MTCD occur simultaneously, it is possible to call MTCD without reducing the number of normal UEs that can be called. This makes it possible to avoid downlink congestion and the resulting shortage of radio resources for paging when paging for normal UE and paging for MTCD occur simultaneously. Therefore, it is possible to prevent an increase in the delay time of paging for normal UE, and it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0317] Embodiment 7 In the above-mentioned first to sixth embodiments, a method for resolving congestion when paging is transmitted to a large number of MTCDs has been disclosed. Congestion in downlink communication to a large number of MTCDs occurs not only in paging transmission but also in data transmission. When downlink data is transmitted in a conventional individual channel, radio resources required for the individual channel are the same as the number of MTCDs. Therefore, in an MTC service, when downlink data transmission to a large number of MTCDs occurs simultaneously, a problem occurs in that a shortage of radio resources occurs, making it impossible to transmit the downlink data.

[0318] In this embodiment, a method for avoiding congestion that occurs when downlink data is transmitted to a large number of MTCDs is disclosed. A paging mechanism is used to transmit downlink data for an MTC service. First, the downlink data for the MTC service is included in a paging message.

[0319] FIG. 35 is a diagram showing an example of information included in a paging message in the seventh embodiment. Hereinafter, downlink data for the MTC service is referred to as "MTC data". As shown in FIG. 35, in this embodiment, in addition to information included in a conventional paging message, specifically, "pagingRecordList", which is a list of PagingRecords, "systemInfoModification", and "etws-Indication", the paging message includes, for example, MTC data, which is downlink data for the MTC service. The MTC data may be a predetermined number of bits or bytes. The number of bits or bytes, the maximum number of bits or the maximum number of bytes may be statically determined in advance.

[0320] Downlink data for the MTC service is assumed to be small in volume. Therefore, it is possible to include MTC data in a paging message. Also, by including MTC data in a paging message, it is possible to reduce information other than data required when setting an individual channel for each MTCD, i.e., overhead. This makes it possible to significantly reduce radio resources for transmitting downlink data to MTCDs, and thus avoid downlink congestion and the resulting shortage of radio resources for transmitting downlink data when downlink data for many MTCDs occurs simultaneously. Therefore, it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0321] Next, the timing of transmitting downlink data for the MTC service will be disclosed. The timing of transmitting downlink data for the MTC service is PF / PO derived from the mobile terminal identifier of the MTCD that transmits the downlink data. That is, the timing is derived by the same method as the paging transmission timing. By configuring in this way, each MTCD can perform intermittent reception in the same cycle as paging, so that it is possible to prevent an increase in power consumption of the MTCD. In addition, both the eNB and the MTCD do not need to separately determine the transmission and reception timing of the MTC data, and do not need to notify each other of the transmission and reception timing. Therefore, it is possible to reduce the amount of signaling required between the eNB and the MTCD.

[0322] Fig. 36 is a diagram showing a sequence of transmission and reception processing of downlink data for an MTC service using paging. Fig. 36 shows a case where a mobile terminal is an MTCD. In step ST3101, the MTCD derives a PF / PO of paging based on the mobile terminal identifier of the own station. Next, in step ST3102, the MTCD performs discontinuous reception at the PF / PO.

[0323] For example, when downlink data for an MTC service addressed to an MTCD is generated from the MTC server, MTC data, which is downlink data for an MTC service addressed to an MTCD, is transmitted to an eNB via an MME or an S-GW in Step ST3103. In Step ST3103, an MTCD mobile terminal identifier indicating which MTCD the data is addressed to is transmitted together with the MTC data, which is downlink data for an MTC service.

[0324] Next, in Step ST3104, the eNB derives a PF / PO for paging from the MTCD mobile terminal identifier. In Step ST3105, the eNB transmits MTC data, which is downlink data for the MTC service, on a paging message in a subframe of the PF / PO for paging of the MTCD. In Step ST3105, the eNB transmits the MTCD mobile terminal identifier together with the MTC data.

[0325] In Step ST3106, the MTCD receives the paging message through the PF / PO that is being discontinuously received. The MTCD that has received the paging message recognizes that the MTC data is addressed to the MTCD by receiving the mobile terminal identifier of the MTCD itself, and receives the MTC data included in the paging message.

[0326] After receiving the MTC data, in Step ST3107, the MTCD transitions again to discontinuous reception of the PF / PO derived from the mobile terminal identifier of the own station. In Step ST3105, the MTCD mobile terminal identifier to be transmitted together with the MTC data may be included in a paging message and transmitted as a pair with the MTC data, or may be transmitted as an overhead of the paging message, or may be transmitted by other signaling or other messages.

[0327] Fig. 37 is a diagram showing an example of information included in a paging message when an MTCD mobile terminal identifier is paired with MTC data and transmitted. When an MTCD mobile terminal identifier is paired with MTC data and transmitted, as shown in Fig. 37, a list in which an MTCD mobile terminal identifier is associated with MTC data for the MTCD represented by the MTCD identifier (hereinafter, sometimes referred to as an "MTC data list") is included in the paging message.

[0328] By configuring in this way, even if downlink data for MTC services occurs simultaneously for multiple MTCDs, MTC data for multiple MTCDs can be transmitted with one paging message. This makes it possible to reduce the delay time that occurs when an MTCD receives downlink data for an MTC service.

[0329] Also, MTC data may be for each MTC group. In this case, an MTC group identifier may be transmitted together with a paging message including data for each MTC group. This allows the MTCD to determine whether the data is downlink data for an MTC service addressed to a group to which the MTCD belongs. Also, a list in which the MTC group identifier and the MTC data for the MTC group represented by the MTC group identifier are associated with each other may be included in the paging message. This eliminates the need to list multiple MTCD mobile terminal identifiers for data for each MTC group, and only the identifier of the MTC group will suffice. Therefore, it is possible to suppress an increase in the amount of information in a paging message.

[0330] Also, a maximum value may be set for the number of MTC data (hereinafter, sometimes referred to as "MTC data number") included in one paging message. In this case, for example, MTC group identifiers up to the maximum number of MTC data and a list describing downlink data for MTC service to the MTC group represented by the MTC group identifier may be described in the paging message. The maximum number of MTC data may be statically determined, for example, as a standard, or may be semi-statically notified, for example, from the eNB as system information. This allows the MTCD to recognize the maximum number of MTC data included in the paging message, making it possible to reduce reception errors of MTC data.

[0331] Furthermore, as a method for transmitting and receiving a paging message including MTC data, the methods of the above-mentioned embodiments 1 to 6 may be applied. Even when the methods of the above-mentioned embodiments 1 to 6 are applied, the same effect as that of this embodiment can be obtained.

[0332] Embodiment 8 In the case where MTC information such as downlink data for MTC service is included in a paging message, if an MTCD exists in the same paging group as a normal UE, paging occurs even though the MTCD is not related to the normal UE. Therefore, the normal UE must receive the paging, which causes a problem of increased power consumption of the normal UE.

[0333] In order to solve this problem, this embodiment discloses a method of providing an RNTI for masking physical resource allocation information for each information type. As an example, MTC-RNTI is newly provided as an RNTI for masking physical resource allocation information for a paging message including downlink data for MTC service. The RNTI for masking physical resource allocation information for a conventional paging message not including downlink data for MTC service is P-RNTI as in the conventional case.

[0334] A normal UE is configured to detect the presence or absence of allocation information masked with a P-RNTI in the PDCCH of a subframe of a PF / PO derived from the mobile terminal identifier of the own station. Since a normal UE does not need to receive data for MTC, it is sufficient to detect only the P-RNTI masked in conventional paging information. If there is allocation information masked with a P-RNTI, the normal UE receives a paging message according to the allocation information.

[0335] In response to this, the MTCD is configured to detect not only the presence or absence of allocation information masked with the MTC-RNTI in the PDCCH of the subframe of the PF / PO derived from the mobile terminal identifier of the own station, but also the presence or absence of allocation information masked with the P-RNTI. When there is allocation information masked with the MTC-RNTI or the P-RNTI, the MTCD may receive a paging message according to the allocation information.

[0336] By configuring in this way, the normal UE can use the same processing as the conventional method for receiving paging messages, and it is possible to prevent an increase in power consumption. Therefore, it is possible to transmit downlink data for the MTC service to the MTCD without affecting the normal UE. Therefore, it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0337] In the case of an MTC service without paging to an MTCD, the MTCD does not need to detect the presence or absence of allocation information masked with a P-RNTI, and only needs to detect allocation information masked with an MTC-RNTI.

[0338] Also, 3GPP is considering including an indicator in a paging message indicating that downlink data for MTC service is broadcast in system information. The paging message including the indicator may also be masked with MTC-RNTI. This can achieve the same effect as described above.

[0339] Embodiment 9 Another method for avoiding congestion that occurs when downlink data is transmitted to a large number of MTCDs is disclosed. Radio resources, specifically radio frames and subframes, are provided for transmitting downlink data for MTC services for MTCDs or for each MTC group. Information for notifying whether data for MTC services has occurred is newly provided. For example, the information for notifying whether data for MTC services has occurred is called "MTC information notification."

[0340] Fig. 38 is a diagram for explaining a specific example of a method for transmitting information for notifying whether data for an MTC service has occurred and downlink data for an MTC service. Fig. 38(a) is a diagram showing a transmission setting for downlink data for an MTC service (hereinafter, sometimes referred to as "MTC data Config"), and Fig. 38(b) is a diagram showing a transmission setting for information for notifying whether data for an MTC service has occurred (hereinafter, sometimes referred to as "MTC data Notification Config").

[0341] In this embodiment, radio resources for downlink data (MTC data) for MTC services (hereinafter, sometimes referred to as "MTC data radio resources") are provided periodically. The period is called the "MTC data repetition period (mtc-dataRepetitionPeriod)". An offset value is provided to determine the radio frame of the MTC data radio resources. The offset value is called "mtc-Offset". Subframe allocation information is provided to determine the subframe of the MTC data radio resources. The subframe allocation information is called "mtc-AllocInfo". The allocation information may be one or multiple subframe numbers, or may be a bitmap in which each bit corresponds to each subframe number. FIG. 38 shows a case in which the allocation information is represented as a bitmap.

[0342] As shown in Fig. 38(a), in the radio resource for MTC data, MTC data is repeatedly transmitted for a predetermined period. This predetermined period is called "mtc-dataModificationPeriod." The same MTC data may be repeatedly transmitted for the predetermined period.

[0343] In the case where the MTC data differs for each MTCD, radio resources on a subframe may be allocated to the MTC data for each MTCD, and the allocation information may be masked with the mobile terminal identifier of the MTCD, for example, the UE-ID or C-RNTI, and then mapped to the PDCCH. The MTCD searches the subframe in the radio frame of the MTC data using the MTCD mobile terminal identifier of the own station, and determines whether or not the MTC data exists. When the MTCD detects that the MTCD mobile terminal identifier of the own station is masked, it may receive the MTC data according to the allocation information.

[0344] In a case where the same MTC data is transmitted to all MTCDs under the cell, a special RNTI, for example, mtc-data-RNTI, may be provided, and the allocation information of radio resources for MTC data may be masked with the RNTI and mapped to the PDCCH. This allows the MTCD to receive the MTC data by detecting the allocation of radio resources for MTC data using the RNTI, i.e., mtc-data-RNTI. If the MTCD cannot detect the RNTI, specifically, mtc-data-RNTI, it may determine that MTC data has not been generated and not perform the reception process of the MTC data. This allows the power consumption of the MTCD to be reduced.

[0345] As shown in FIG. 38(b), the timing at which information for notifying whether data for an MTC service has occurred (MTC information notification) can be transmitted is set to be periodic. The period is called "mtc-dataNotificationPeriod". An offset value is also set to determine the radio frame of the MTC information notification. The offset value is called "mtc-notificationOffset". Subframe allocation information is also set to determine the subframe of the MTC information notification. The subframe allocation information is called "mtc-notificationSFindex". It is preferable to set the allocation of subframes to one, and use the subframe number. Also, there may be multiple subframes for the MTC information notification, and the subframe allocation information may be the subframe number, or it may be a bitmap in which each bit corresponds to each subframe number.

[0346] The MTC data notification period may be set to the same as the mtc-dataModificationPeriod. Also, the offset value (mtc-notificationOffset) may be set to the same as the mtc-Offset. In this way, the MTCD that detects the MTC information notification can immediately perform the reception process of the MTC data. Therefore, it is possible to reduce the control delay until the MTCD receives the MTC data.

[0347] Furthermore, when discontinuous reception is performed in the MTCD, the mtc-dataNotificationPeriod may be set to the same cycle as the discontinuous reception cycle, thereby enabling the power consumption of the MTCD to be reduced.

[0348] The MTC information notification may be mapped to the PDCCH. The MTC information notification may not include physical resource allocation information for the PDSCH. This allows notification with fewer radio resources. There is no allocation of PMCH or PDSCH.

[0349] A special RNTI, for example, mtc-notification-RNTI, may be provided, and the MTC information notification may be masked with the RNTI and mapped to the PDCCH. This allows the MTCD to know the occurrence of MTC data by detecting the MTC information notification on the PDCCH using the RNTI. If the MTCD cannot detect the RNTI at the timing when the MTC information notification is transmitted, the MTCD can recognize that the MTC data has not occurred, and therefore does not need to perform the reception process of the MTC data. This makes it possible to reduce the power consumption of the MTCD. In addition, it is possible to prevent the normal UE from receiving the PDCCH.

[0350] mtc-notification-RNTI may be unique for MTC. It may also be statically determined in advance, or may be notified by system information. When it is statically determined, it is possible to reduce the amount of information that requires signaling. When it is notified as system information, it is not necessary to reserve it in advance, and it is possible to change it, so that the system can be operated flexibly and efficiently.

[0351] FIG. 39 and FIG. 40 are diagrams showing a sequence of transmission and reception processing of downlink data for MTC service in the ninth embodiment. FIG. 39 and FIG. 40 are connected at the position of the boundary line A1. FIG. 39 and FIG. 40 show a case where a mobile terminal is an MTCD. In step ST3401, an eNB determines a configuration of radio resources for MTC data prior to transmission of MTC data. Then, in step ST3402, an eNB determines a configuration of radio resources for MTC information notification, which is information for notifying whether data for MTC service has occurred. In step ST3403, an eNB broadcasts the configuration of radio resources for MTC data as system information to a mobile terminal (UE) being served by the eNB. Also, in step ST3404, an eNB broadcasts the configuration of radio resources for MTC information notification as system information to a mobile terminal (UE) being served by the eNB. An MTCD receives the configuration of radio resources for MTC data and the configuration of radio resources for MTC information notification broadcast by the eNB.

[0352] In Step ST3405, the MTCD discontinuously receives the radio resources in accordance with the configuration of the radio resources for MTC information notification, and detects the PDCCH of the subframe using mtc-notification-RNTI, which is the RNTI for MTC information notification.

[0353] For example, when downlink data for an MTC service addressed to an MTCD is generated from the MTC server, MTC data, which is downlink data for an MTC service addressed to an MTCD, is transmitted to an eNB via an MME or an S-GW in Step ST3406. In Step ST3406, an MTCD mobile terminal identifier indicating which MTCD the data is addressed to is transmitted together with the MTC data.

[0354] Next, in Step ST3407, the eNB masks the RNTI for information on information for notifying whether data for the MTC service has occurred, and maps the information to the PDCCH of the subframe of the radio resource for the information determined in Step ST3402. In addition, in Step ST3408, the eNB maps MTC data to the radio resource for MTC data determined in Step ST3401, masks allocation information of the radio resource with mtc-data-RNTI, which is the RNTI for MTC data, and maps the information to the PDCCH.

[0355] In Step ST3409, the eNB transmits the MTC information notification using the radio resource determined in Step ST3402. Then, in Step ST3410, the eNB transmits the MTC data and allocation information for that data using the radio resource determined in Step ST3401.

[0356] The MTCD performing discontinuous reception in Step ST3405 receives the MTC information notification by detecting the mtc-notification-RNTI in Step ST3411. The MTCD can recognize that the MTC data is being sent by receiving the MTC information notification. Therefore, in Step ST3412, the MTCD performs detection processing on the PDCCH of the radio resource for MTCD data with the mtc-data-RNTI, and in Step ST3413, when detecting the mtc-data-RNTI, receives the MTC data allocation information of the PDCCH and receives the MTC data in accordance with the received allocation information.

[0357] This makes it possible to transmit and receive downlink data for the MTC service without using paging.

[0358] As described above, by providing radio frames and subframes that are radio resources for transmitting downlink data for an MTCD or an MTC service for each MTC group, and by providing new information for notifying whether data for an MTC service has occurred, it is possible to reduce information other than data that is required when configuring an individual channel for each MTCD at the timing for each MTCD, i.e., the overhead portion.

[0359] This makes it possible to transmit downlink data for MTC services without using a logical control channel for MTC, and thus makes it possible to significantly reduce radio resources for transmitting downlink data to MTCDs. Therefore, it is possible to avoid downstream congestion caused by the simultaneous generation of downlink data for many MTCDs and the resulting shortage of radio resources for transmitting downlink data, making it possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0360] In addition, in this embodiment, since information for notifying whether data for MTC service has occurred is used, the MTCD can explicitly recognize the case where downlink data for MTC service has occurred. This allows the eNB to use radio resources for other communication when downlink data for MTC service has not occurred. Therefore, it is possible to improve the usage efficiency of radio resources used for downlink data communication as a communication system.

[0361] In the present embodiment, the radio resources for transmitting information for notifying whether downlink data for the MTC service for the MTCD or for each MTC group and data for the MTC service have been generated are set periodically. This enables the MTCD to perform discontinuous reception, thereby making it possible to suppress an increase in the power consumption of the MTCD.

[0362] In the present embodiment described above, a new MTC information notification is provided as information for notifying whether data for an MTC service has been generated. However, a new MTC information notification may also be provided as information for notifying whether data for an MTC service has been changed, rather than whether data for an MTC service has been generated.

[0363] For example, the MTC data may be changed in the next mtc-dataModificationPeriod following the mtc-dataModificationPeriod during which the MTC data is repeated. In order to notify that the MTC data has been changed, an MTC information notification may be used.

[0364] Fig. 41 is a diagram for explaining a specific example of a notification method when data for an MTC service is changed. Fig. 41(a) is a diagram showing a transmission setting (MTC data Config) of downlink data for an MTC service, and Fig. 41(b) is a diagram showing a transmission setting (MTC data Notification Config) of information for notifying whether data for an MTC service has been changed or generated.

[0365] The radio resource configuration for transmitting MTC data, which is downlink data for MTC services, shown in Fig. 41(a) is the same as the configuration shown in Fig. 38(a) above. After the same MTC data is repeatedly transmitted for a predetermined period (mtc-dataModificationPeriod), the MTC data is modified, and the modified MTC data is repeatedly transmitted for the next predetermined period (mtc-dataModificationPeriod).

[0366] The radio resource configuration of the MTC information notification, which is information for notifying whether data for MTC service has occurred, shown in Fig. 41(b) is the same as the configuration shown in Fig. 38(b) above. The radio resource is configured periodically for each MTC-dataNotificationPeriod. In the radio resource of the MTC-dataNotificationPeriod corresponding to the MTC-dataModificationPeriod, the MTC information notification for notifying that MTC data has occurred is transmitted.

[0367] If the MTC data is changed during the MTC-dataModificationPeriod, which is a predetermined period during which the next MTC data is repeatedly transmitted, an MTC information notification is transmitted in the radio resources of the MTC-dataNotificationPeriod corresponding to the MTC-dataModificationPeriod to notify that the MTC data has been changed.

[0368] In this way, not only when MTC data occurs but also when MTC data is changed, the MTCD can recognize that the MTC data has been changed by transmitting the MTC information notification, which is information for notifying whether data for MTC service has occurred. Therefore, even if the MTC data is continuously transmitted, the MTCD can recognize that the MTC data is different from the previous MTC data, and can selectively receive the changed MTC data. The MTC information notification is mapped to, for example, the PDCCH. There is no allocation of the PMCH or PDSCH.

[0369] The information for notifying whether data for an MTC service has been generated or changed may include information indicating whether the data is the same as the previous MTC-dataModificationPeriod. This information indicating whether the data is the same as the previous MTC-dataModificationPeriod may be used as an indicator. For example, as 1-bit information, "0" may indicate that the data is the same, and "1" may indicate that the data is different.

[0370] The MTCD can receive necessary MTC data by receiving information indicating whether the MTC data is the same data or not, which is included in information for notifying whether data for MTC service has been generated or changed. For example, when the same MTC data is transmitted over a plurality of MTC-dataModificationPeriods, the MTCD that received the MTC data in the first MTC-dataModificationPeriod does not need to receive the MTC data in the subsequent MTC-dataModificationPeriods as long as the information indicating whether the MTC data is the same data or not indicates that the data is the same. The MTCD receives information indicating whether the MTC data is the same data or not, and only when the information indicates that the data is different, it is sufficient for the MTCD to receive the MTC data selectively. This allows the MTCD to selectively receive the MTC data, which can eliminate unnecessary reception processing and achieve low power consumption.

[0371] Information for notifying whether data for an MTC service has been generated or changed may be notified intermittently or periodically within mtc-dataNotificationPeriod. The period at that time may be the MTC data repetition period (mtc-dataRepetitionPeriod). The MTCD does not need to receive information for notifying whether data for an MTC service has been generated or changed every mtc-dataRepetitionPeriod, and may receive the information once within mtc-dataNotificationPeriod.

[0372] FIG. 41(b) also shows a case where information for notifying whether data for an MTC service has been generated or changed is notified intermittently. The subframe configuration in each radio frame may be the same. The information for notifying whether data for an MTC service has been generated or changed is intermittently transmitted, for example, from a radio frame derived from MTC-notificationOffset and MTC-dataNotificationPeriod, and a subframe indicated by MTC-notificationSFindex, as indicated by reference symbol "4000" in FIG. 41(b). The information may be intermittently transmitted for a predetermined period, or may be intermittently transmitted a predetermined number of times. The predetermined period or the predetermined number of times may be notified as system information from the eNB. The information for notifying whether data for an MTC service has been generated or changed may be notified as system information having the same radio resource configuration.

[0373] As a result, even if the MTCD cannot receive information for notifying whether the MTC service data has been generated or changed, the MTCD can recognize whether the MTC data has been generated or changed by receiving the subsequent information. This makes it possible to reduce the reception error of the MTCD.

[0374] The MTC information notification may be provided for each MTC group. For example, the information for notifying whether data for the MTC service has been generated or changed on the PDCCH is n bits, and the n bits are 2 to the power of 2 (2 n ) may correspond to each MTC group.

[0375] The value of n and the correspondence between the value of n and the MTC group identifier may be determined as a system, or may be determined for each TA or cell. The value of n and the correspondence between the value of n and the MTC group identifier may be statically determined, for example, in advance according to a standard. Also, they may be determined semi-statically. For example, the value for each TA or for each cell may be broadcast as system information from the eNB to the mobile terminals under its control. Also, a method of using the MTC group identifier in the system, the MTC group identifier in the TA, the MTC group identifier in the cell, etc. disclosed in the first modification of the second embodiment may be applied as the MTC group identifier.

[0376] When transmitting MTC data for each MTC group, an RNTI for each MTC group may be provided, and the radio resource allocation information of the MTC data of each MTC group may be masked and mapped to the PDCCH. In this way, the MTCD can receive the MTC data allocation information and the MTC data using the RNTI of the MTC group to which the own station belongs. This makes it possible to prevent the MTCD from receiving the MTC data allocation information and the MTC data of other MTC groups. Therefore, since the transmission and reception of the MTC data for each MTC group is possible, the reception power consumption of the MTCD can be reduced.

[0377] When the MTC data differs for each MTCD, the MTC data for each MTCD may be assigned to an individual channel. For example, MTC data for one MTCD may be mapped to a DTCH, multiplexed for each MTCD, and mapped to a DL-SCH. When multiplexing is not required, the multiplexing may be omitted. The DL-SCH may be mapped to a PDSCH as in the past. When an uplink control channel can be transmitted for each MTCD, HARQ may be performed on the MTC data in the MAC layer.

[0378] In the case where the same MTC data is transmitted to all MTCDs under the cell, the MTC data may be assigned to a common channel. For example, the logical channel of the common channel may be mtc-CTCH. The mtc-CTCH may be mapped to the transport channel DL-SCH and may be mapped to the PDSCH. In the case of MTC-CTCH, since HARQ cannot be performed for each MTCD, it is preferable not to perform HARQ.

[0379] In the case where the MTC data is different for each MTC group and the same MTC data is used within an MTC group, the MTC data may be assigned to a channel for each MTC group. For example, the logical channel for each MTC group is set as mtc-TCH, and MTC data for one MTC group is mapped to mtc-TCH, and multiplexed for each MTC group and mapped to DL-SCH. If multiplexing is not required, multiplexing may be omitted. DL-SCH is mapped to PDSCH as before. In the case of a channel for each MTC group, HARQ for each MTCD cannot be performed, so it is better not to perform HARQ.

[0380] By doing so, it becomes unnecessary to transmit downlink data to each MTCD, and therefore it becomes possible to greatly reduce radio resources for transmitting downlink data for the MTC service.

[0381] Also, a radio resource configuration for MTC data and a radio resource configuration for information for notifying whether data for MTC service has occurred may be set for each MTC group. That is, the radio resource configuration may be different for each MTC group. The radio resource configuration for each MTC group may be notified to a mobile terminal under the control of an eNB by system information. The radio resource configurations of all MTC groups may be associated with an MTC group identifier and included in the same system information block (SIB). In this way, a radio resource configuration according to an MTC service for each MTC group can be set. Therefore, since the radio resource configuration can be flexibly set according to the MTC service, it is possible to improve the usage efficiency of radio resources.

[0382] Regarding the period of information for notifying whether data for MTC services has occurred (mtc-dataNotificationPeriod), the values ​​for each MTC group may be set to be multiples or divisors of each other. This makes it possible to align the timing at which MTCDs belonging to multiple MTC groups require reception. This makes it possible to reduce the power consumption of the MTCDs.

[0383] Similarly to the information for notifying whether data for MTC services has been generated, the period of the radio resource for MTC data (mtc-dataModificationPeriod) may be set so that the values ​​for each MTC group are multiples or divisors of each other, thereby achieving the same effect.

[0384] Ninth embodiment, variant 1 In this embodiment, radio resources for MTC data, which is downlink data for the MTC service, are periodically provided, and the MTC data is repeatedly transmitted for a certain period. In this modification, the transmission of MTC data is turned off, i.e., stopped, after the predetermined period has elapsed.

[0385] Fig. 42 is a diagram explaining a specific example of a case where transmission of MTC data is turned off after a predetermined period of time has elapsed. Fig. 42(a) is a diagram showing a transmission setting (MTC data Config) for downlink data for an MTC service, and Fig. 42(b) is a diagram showing a transmission setting (MTC data Notification Config) for information for notifying whether data for an MTC service has been generated.

[0386] The radio resource configuration of the MTC information notification, which is information for notifying whether data for the MTC service has been generated, shown in Fig. 42(b) is the same as the configuration shown in Fig. 41(b) above. The radio resource configuration for the MTC data, which is downlink data for the MTC service, shown in Fig. 42(a) is partially different from the configuration shown in Fig. 41(a) above. The different parts will be described.

[0387] In this modification, a period during which MTC data is transmitted and a period during which MTC data is not transmitted are provided within the MTC-dataModificationPeriod. For example, the period during which MTC data is transmitted is set as MTC-dataTransPeriod. During the MTC-dataTransPeriod, MTC data is repeatedly transmitted at a cycle of MTC-dataRepetitionPeriod. After the MTC-dataTransPeriod, MTC data is not transmitted and transmission is turned off until the next MTC-dataModificationPeriod.

[0388] During the period when MTC data is not transmitted, radio resources may be used for other communications without being reserved for MTC data.

[0389] As another example of providing a period during which MTC data is transmitted and a period during which MTC data is not transmitted, the number of times MTC data is repeatedly transmitted may be set. For example, the number of times of transmission is set to n. In this case, since MTC data is repeatedly transmitted at a cycle of MTC-dataReprtitonPeriod, the period during which MTC data is transmitted is n*MTC-dataReprtitonPeriod.

[0390] The period during which the MTC data is transmitted may be set to be equal to or greater than the period or number of times during which the MTC information notification disclosed in this embodiment is repeatedly transmitted. By doing so, the MTCD can receive the MTC data at least once regardless of which MTC information notification it receives and recognizes whether the MTC data has been generated or changed.

[0391] The period in which MTC data is transmitted and the period in which MTC data is not transmitted may be notified as system information from the eNB. They may be notified as the same system information as the configuration of radio resources for MTC data, which is downlink data for MTC services. The period in which MTC data is transmitted and the period in which MTC data is not transmitted do not have to be notified of both, and only one of them may be sufficient. They can be derived from the MTC-dataModificationPeriod. Also, instead of the period in which MTC data is transmitted, a difference value between the period in which MTC information notification is repeatedly transmitted may be notified.

[0392] By adopting the method disclosed in this modification, the eNB does not need to transmit the same MTC data more than necessary. This makes it possible to reduce the amount of downlink data information on the Uu interface, and therefore makes it possible to reduce congestion in downlink data transmission when a large number of MTCDs exist. In addition, during the period when the transmission of MTC data is turned off, it becomes possible to allocate radio resources to other communications. Therefore, it becomes possible to increase the amount of data transmission information and the data transmission speed of the system.

[0393] Ninth embodiment, variant 2 In the ninth embodiment and the first modification of the ninth embodiment, a method is adopted in which the logical control channel for MTC is not used to transmit MTC data, which is downlink data for the MTC service. As an example, a method is adopted in which the radio resource configuration of the downlink data for the MTC service is notified by broadcast information, and an MTC information notification is provided on the PDCCH to notify whether MTC data has been generated or changed. When the MTCD receives the MTC information notification and recognizes the existence of MTC data, the MTCD receives the MTC data according to the radio resource configuration of the downlink data for the MTC service in the broadcast information.

[0394] In this modification, a control channel for MTC (hereinafter sometimes referred to as "MTC control channel") is provided. Configuration information of radio resources of MTC data of all MTC groups is mapped to the control channel for MTC. The control channel for MTC may be a common channel, not an individual channel for each MTCD. The configuration of radio resources to which the control channel for MTC is mapped is notified as system information from the eNB to mobile terminals under its control.

[0395] A specific example of the configuration of the radio resource to which the control channel for MTC is mapped may be the same as the radio resource configuration of the MTC information notification. The radio resource to which the control channel for MTC is mapped may be periodic, and the period, an offset value for determining a radio frame, and a subframe number or a subframe allocation for determining a subframe may be set.

[0396] Also, a special RNTI for the control channel for MTC, for example, MTC-control-RNTI, may be provided, and allocation information of physical resources of the control channel for MTC may be masked with the RNTI and mapped to the PDCCH. This enables the MTCD to receive the control channel for MTC by detecting the allocation information using the RNTI.

[0397] The MTCD receives the MTC control channel according to the information on the radio resource configuration of the MTC control channel broadcast from the eNB, and receives the configuration information of the MTC service downlink data for the MTC group to which the MTCD belongs. The MTCD receives the MTC data according to the configuration information of the downlink data for the MTC service. In this way, the MTCD can receive the MTC data transmitted for each MTC group.

[0398] Since the radio resource configuration information of the MTC data of the MTC group is mapped to the control channel for MTC, it is not necessary to broadcast the radio resource configuration of the downlink data for the MTC service as broadcast information. This makes it possible to reduce the amount of broadcast information. This effect becomes more noticeable when the number of supported MTC groups increases.

[0399] In the above specific example, the configuration information of the radio resources of the MTC data of all MTC groups is mapped onto the control channel for MTC. In addition to this, the configuration information of the MTC information notification that notifies whether data for the MTC service has been generated or changed, as disclosed in the ninth embodiment and the first variant of the ninth embodiment, may also be included in the mapping.

[0400] The MTCD receives the MTC control channel in accordance with information on the radio resource configuration of the MTC control channel broadcast from the eNB, and receives configuration information of the MTC information notification together with configuration information of the downlink data for the MTC service for the MTC group to which the MTCD belongs.

[0401] The MTCD receives the MTC information notification according to the configuration information of the MTC information notification, and recognizes whether MTC data has been generated or changed. The MTCD that recognizes that the MTC data has been generated or changed may receive the MTC data according to the configuration information of the MTC data of the MTC group to which the own station belongs, which is mapped to the MTC control channel.

[0402] In this way, the MTCD can receive the MTC data after recognizing the occurrence or change of the MTC data transmitted for each MTC group. This makes it possible to eliminate unnecessary reception processing for receiving the MTC data in the MTCD, thereby enabling low power consumption.

[0403] Embodiment 10 There are cases where many MTCDs transmit uplink RACHs simultaneously. For example, there is an attach process when the power is turned on after being turned off once. This is because the detach process is often set to be performed when the power is turned off.

[0404] When the power-on times of many MTCDs are set to be the same as the MTC service, the attach process occurs simultaneously. The attach process starts with an uplink RACH procedure. As a method for avoiding the simultaneous occurrence of the attach process of many MTCDs, the MTCD may not perform the detach process when the power is turned off. However, if the detach process is not performed, the resources of the upper node remain reserved.

[0405] It is assumed that there is a long interval between the time when the MTCD is turned off and the next communication. Therefore, it is wasteful and inefficient to keep the resources of the upper node reserved for a long time. As a countermeasure, Non-Patent Document 13 describes that the upper node performs the detachment process even if there is no detachment process from the MTCD. Non-Patent Document 13 does not describe specific operations.

[0406] Here, an example of a specific operation of a method of performing a detachment process by an upper node when there is no detachment process from the MTCD is disclosed. For example, when the MTCD transmits uplink data after the attach process, the upper node performs the detachment process after the transmission of the uplink data from the MTCD is completed, and the resource of the upper node is released. As a result, the MTCD does not need to perform the detachment process, and can turn off the power after the transmission of the uplink data is completed.

[0407] However, when the detachment process is performed by the upper node, even if the period until the next uplink data transmission by the MTCD is short, the MTCD needs to perform the attach process at the time of the next uplink data transmission. This leads to an increase in the uplink RACH. In addition, when the detachment process is performed by the upper node, the MTCD has a problem that it is unclear whether the attach process is necessary at the time of the next uplink data transmission or when the power is turned on.

[0408] In this embodiment, a method for solving these problems and avoiding uplink congestion due to an increase in uplink RACH is disclosed. In this embodiment, information on whether or not an attach process is necessary when an MTCD transmits (hereinafter, sometimes referred to as "attach necessity information") is provided, and the upper node notifies the MTCD in advance. The information may be information on whether or not an attach process is necessary when an MTCD is powered on.

[0409] As specific examples of an upper node that notifies an MTCD of the attach necessity information, the following three (1) to (3) are disclosed: (1) MME, (2) SGSN, and (3) HSS. In addition, the upper node that notifies an MTCD of the attach necessity information may be the same as the upper node that automatically starts the detach process.

[0410] As specific examples of a method of notifying the attach necessity information, the following four methods (1) to (4) are disclosed. (1) Notify at the time of the initial attach process from the MTCD. (2) Notify when notifying the MTCD of the next transmission time or power-on time from the upper node. (3) Notify at the time of TAU process from the MTCD. (4) Notify at the time of service request process from the MTCD. For example, when the MME notifies at the time of the initial attach process from the MTCD, the MME includes the attach necessity information in an attach accept message on S1 signaling and notifies the eNB. The eNB that has received the attach necessity information notifies the MTCD of the attach necessity information by including it in an RRC connection reconfiguration message. Not limited to this, the attach necessity information may be included in an attach completion message transmitted from the eNB to the MTCD.

[0411] As specific examples of information on whether or not attachment is required when an MTCD transmits or turns on its power, i.e., information on whether or not attachment is required, the following two items (1) and (2) are disclosed: (1) a threshold for determining whether or not attachment is required, and (2) an indicator of whether or not attachment is required.

[0412] A specific example will be disclosed in which the attach necessity information is a threshold for determining whether or not attach is necessary. A threshold is set for the time from the end of the MTCD's uplink data transmission to the next transmission. For example, the threshold is Th-attach. If the time from the end of the MTCD's uplink data transmission to the next transmission is equal to or greater than Th-attach, the MTCD performs attach. If the time from the end of the MTCD's uplink data transmission to the next transmission is equal to or less than Th-attach, or is less than Th-attach, the MTCD does not perform attach. It is preferable that the entity that determines whether or not attach is necessary be the MTCD. It is preferable that the MTCD make the determination based on the threshold and the time until the next uplink data transmission.

[0413] A specific example will be disclosed in which the attachment necessity information is an indicator of whether or not attachment is necessary. For example, the attachment necessity information is set to 1 bit, and if it is "1", attachment is performed at the time of the next uplink data transmission, and if it is "0", attachment is not performed at the time of the next uplink data transmission. The subject that determines whether or not attachment is necessary may be an upper node. For example, when the upper node recognizes the next uplink data transmission time of the MTCD, it may determine whether or not attachment is necessary based on the next uplink data transmission time of the MTCD.

[0414] When a threshold value for determining whether or not attachment is required is used as the attachment necessity information regarding whether or not attachment is required when the MTCD transmits or when the power is turned on, the threshold value may be statically determined. For example, the threshold value may be determined in advance as a standard. By statically determining the threshold value in this manner, notification to the MTCD is not required, and therefore, an effect of reducing the amount of signaling can be obtained.

[0415] The upper node releases resources according to a predetermined condition. The following two (1) and (2) are disclosed as specific examples of the predetermined condition. The conditions shown below correspond to disconnection conditions: (1) when a threshold for determining whether or not attachment is necessary is exceeded, and (2) when it is determined that attachment is necessary at the time of the next uplink data transmission of the MTCD.

[0416] As specific examples of resources of an upper node, the following five (1) to (5) are disclosed: (1) a radio control link between an MTCD and an eNB, (2) a radio data link between an MTCD and an eNB, (3) a radio access bearer between an eNB and an S-GW, (4) registration information of an MTCD on an HSS, and (5) a communication path setting between an S-GW and a P-GW. One of these may be used, or a plurality of them may be used.

[0417] FIG. 43 is a diagram showing a sequence of an uplink congestion avoidance method in the tenth embodiment. In Step ST3701, the MTCD performs an initial attach process. As this attach process, a method described in 3GPP TS 23.401 V9.4.0 (hereinafter referred to as "Non-Patent Document 15") may be applied. The attach process is started by RACH transmission from the MTCD. In this initial attach process, in Step ST3702, the MME includes Th-attach, which is a threshold for determining whether or not attach is necessary, in an attach accept message on S1 signaling and notifies the eNB. The eNB that has received Th-attach includes the received information in an RRC connection reconfiguration message and notifies the MTCD. In Step ST3703, the MTCD performs an uplink data transmission process. The uplink data transmission process is performed via one or more nodes of the MTCD, the eNB, the MME, the HSS, the S-GW (Serving GW), and the P-GW (PDN GW).

[0418] After performing the uplink data transmission process in Step ST3703, the MTCD may turn off the power in Step ST3704. In Step ST3705, the MME that has finished the uplink data transmission process from the MTCD in Step ST3703 judges whether or not the time since the previous uplink data transmission process is equal to or longer than Th-attach. If the time since the previous uplink data transmission process is shorter than Th-attach, the MME returns to Step ST3705 and performs the judgment process of Step ST3705 again. If the time since the previous uplink data transmission process is equal to or longer than Th-attach, the MME proceeds to Step ST3706 and performs a detach process of MME activation. In Step ST3707, the eNB and the upper node MME, HSS, S-GW or P-GW perform a detach process and a resource release process. As a result, the resources of the upper node that have been reserved up until now are released and can be used for communication with other mobile terminals.

[0419] In step ST3708, the MTCD judges whether or not the next uplink data is generated, and if not, returns to step ST3708 and repeats the judgment process of step ST3708 again. If the next uplink data is generated, the MTCD moves to the judgment process of step ST3712. If the MTCD turned off the power in step ST3704, the MTCD turns on the power in step ST3709, and receives, in step ST3710, the system information broadcast from the eNB in ​​step ST3711.

[0420] If the MTCD does not turn off the power supply in step ST3704, the reception of the system information in step ST3710 may be performed as appropriate. The MTCD may selectively turn off the power supply partially in step ST3704 in order to recognize whether or not the next uplink data is generated. For example, the MTCD may turn off the power supply of one or more parts such as the frequency conversion unit 806, the modulation unit 805, the demodulation unit 808, the encoder unit 804, and the decoder unit 809 shown in FIG. 8 described above. Whether or not uplink data is generated may be determined by any one or more parts of the transmission data buffer unit 803, the application unit 802, the protocol processing unit 801, and the control unit 810. This makes it possible to determine whether or not the next uplink data is generated while reducing power consumption.

[0421] Also, if the power-on time is set in advance or notified in advance from the MTC server, the process of determining whether or not the next uplink data occurs in step ST3708 may be performed after the power is turned on. This makes it possible to turn on the power at a preset time, rather than depending on whether or not the next uplink data occurs.

[0422] In step ST3712, the MTCD judges whether or not the time since the end of the previous uplink data transmission process is equal to or longer than Th-attach. If the time since the previous uplink data transmission process is shorter than Th-attach, the MTCD judges that the upper node has not started uplink data transmission process, and performs uplink data transmission process in step ST3714 without performing the attach process in step ST3713. If the time since the previous uplink data transmission process is equal to or longer than Th-attach, the MTCD judges that the upper node has started uplink data transmission process, and performs the attach process in step ST3713, and then performs uplink data transmission process in step ST3714.

[0423] After that, each node returns to A and repeats the process from step ST3704 to step ST3714.

[0424] In this way, when a predetermined time or more has passed since the previous uplink data transmission process, the upper node performs the detach process, so that the MTCD does not necessarily perform the attach process at the time of the next uplink data transmission or when the power is turned on after the uplink data transmission process is completed, and it is possible to suppress an increase in the uplink RACH. Also, depending on whether a predetermined time or more has passed since the previous uplink data transmission process, the MTCD can determine whether the attach process is necessary at the time of the next uplink data transmission or when the power is turned on. This provides an effect that it is possible to avoid uplink congestion due to an increase in the uplink RACH and to enable the MTCD to transmit uplink data. Therefore, it is possible to build a communication system that enables M2M communication while maintaining optimal communication for H2H.

[0425] Whether or not a predetermined time has passed since the previous uplink data transmission process corresponds to a prediction condition under which the base station device predicts that communication with the mobile terminal has been disconnected. The fact that a predetermined time has passed since the previous uplink data transmission process means that the prediction condition is satisfied.

[0426] The information on whether or not attachment is necessary is not limited to a predetermined time, and may be information on whether or not attachment is necessary when the MTCD transmits or when the power is turned on. It is possible to obtain the same effect.

[0427] Tenth embodiment, variant 1 When a threshold value is set for determining whether or not attachment is necessary, and the MTCD determines whether or not attachment is necessary at the time of the next transmission or power-on according to the threshold value, even if the time until the next transmission is within the threshold value, there are cases where it is better to perform an attachment process, i.e., a location registration process, when the MTCD moves to another tracking area (TA). For example, when the MTCD moves to another TA, the connected upper node changes, and so resource reconfiguration is required. Therefore, if the attachment process is not performed when the MTCD moves to another TA, resource reconfiguration is not performed, and the resources of the node connected in the old TA remain reserved, resulting in a waste of resources. Furthermore, the upper node is not changed and resources are not configured in the new TA, making communication impossible.

[0428] In this modification, a method for solving these problems is disclosed. Whether or not the cell is within a predetermined cell is added as a judgment index for whether or not attachment is required at the time of the next transmission or power-on of the MTCD. As a specific example, whether or not the cell selected when the MTCD performs the next transmission or powers on is included in a predetermined list may be used as the judgment index. As specific examples of the predetermined list, the following three (1) to (3) are disclosed. (1) TA list, (2) cell list for each MTC service, and (3) cell list for each MTC group.

[0429] The upper node notifies the MTCD of a predetermined list in advance. The notification method may be the notification method disclosed in the tenth embodiment, which notifies information on whether or not attachment is required when the MTCD transmits or when the power is turned on.

[0430] Figure 44 is a diagram showing a sequence of an uplink congestion avoidance method in Modification 1 of the tenth embodiment. In Figure 44, steps corresponding to the steps shown in the above-mentioned Figure 43 are given the same reference numerals, and common explanations are omitted. Figure 44 shows a case where whether or not a cell selected by an MTCD is included in a TA list is added as a judgment index.

[0431] In Step ST3801, the MME notifies the eNB of the TA list at the time of the initial attach process from the MTCD, and the eNB notifies the MTCD of the TA list notified from the MME. For example, the MME includes the TA list in an attach accept message on S1 signaling and notifies the eNB, and the eNB includes the TA list in an RRC connection reconfiguration message and notifies the MTCD.

[0432] In step ST3708, the MTCD judges that the next uplink data is generated, turns on the power in step ST3709, receives system information in step ST3710, and then judges whether or not the selected cell is included in the TA list in step ST3802. The MTCD receives system information from the selected cell, receives the TAC or TAI in the received system information, and judges whether or not the received TAC or TAI is present in the TA list received in step ST3801. If the selected TAC or TAI is included in the TA list, the MTCD performs the process of step ST3712 described above. If the selected TAC or TAI is not included in the TA list, the MTCD performs the attach process of step ST3713 without performing the process of step ST3712. That is, the MTCD performs the attach process regardless of the time from the end of the previous uplink data transmission process.

[0433] By adopting the method disclosed in this modification, when a TA moves from a TA in the TA list to another TA outside the TA list, it is possible to change the upper node and set resources in the new TA, and communication becomes possible. In addition, the resources of the upper node in the original TA are also released, so that it is possible to improve the usage efficiency of radio resources. In addition, when there is no movement from a TA in the TA list, it is possible to obtain an effect that uplink congestion due to an increase in uplink RACH is avoided and the MTCD can transmit uplink data.

[0434] The method disclosed in the present invention can be applied not only to eNB / NB but also to so-called local nodes such as HeNB, HNB, pico eNB (LTE pico cell (EUTRAN pico cell)), pico NB (WCDMA pico cell (UTRAN pico cell)), node for hot zone cell, relay node, remote radio head (RRH), etc. By performing the method disclosed in the present invention on a local node supporting MTC service, it becomes possible to avoid problems caused by downlink congestion and uplink congestion and problems caused by them.

[0435] In each of the above embodiments, the LTE system (E-UTRAN) has been mainly described, but the communication system of the present invention can also be applied to a W-CDMA system (UTRAN, UMTS) and LTE-Advanced (LTE-Advanced).

[0436] Although the present invention has been described in detail, the above description is illustrative in all respects and is not intended to limit the present invention. It is understood that countless variations not illustrated can be envisioned without departing from the scope of the present invention. [Explanation of symbols]

[0437] 1301 to 1304 MTCD, 1305 NB / eNB, 1306 SGSN / MME, 1307 HLR / HSS, 1308 MTC server, 1309 MTC user, 1310 API, 1311 to 1314 Uu interface, 1315 IuPS / S1 interface, 1316 Gr / S6a interface, 1317 communication operator area.

Claims

1. A communication system including a terminal device and a base station device capable of wireless communication with the terminal device, Transmitting MTC control information, which is control information for MTC, from the base station device to the terminal device using an MTC control channel, which is a control channel for MTC; A communication system comprising: a base station device transmitting, to said terminal device, radio resource information, which is information on radio resources for transmitting said MTC control channel.

2. The communication system according to claim 1 , wherein the MTC control information includes radio resource information that is information on radio resources for transmitting data for MTC.

3. The communication system according to claim 1 , wherein the terminal device receives the MTC control channel and acquires MTC control information for the terminal device itself.

4. The communication system according to claim 1 , wherein the terminal device receives data for MTC based on the MTC control information.

5. 2. The communication system according to claim 1, wherein the MTC control channel is a common channel that can be used in common by a plurality of terminal devices.

6. The communication system according to claim 5, wherein the radio resources for transmitting the MTC control channel are arranged periodically.

7. The communication system according to claim 1 , wherein the radio resource information includes a period of the radio resource.

8. A terminal device capable of wireless communication with a base station device, Receive MTC control information, which is control information for MTC, from the base station device using an MTC control channel, which is a control channel for MTC; A terminal device characterized in that it receives radio resource information, which is information on radio resources for transmitting the MTC control channel, from the base station device.

9. A base station device capable of wireless communication with a terminal device, Transmitting MTC control information, which is control information for MTC, to the terminal device using an MTC control channel, which is a control channel for MTC; A base station device characterized in that it transmits radio resource information, which is information on radio resources for transmitting the MTC control channel, to the terminal device.

Citation Information

Patent Citations

  • Base station device and communication control method

    WO2008105316A1

  • Communication system and individual control information transmitting / receiving method

    WO2009013810A1

  • Radio communication system, base station device, mobile station device, radio transmission method, and radio reception method

    WO2009157487A1