Communication system, mobile terminal, base station, mobility management device, and gateway device

Abstract

A communication system and the like are provided that can check the status of a communication terminal device while suppressing processing load and power consumption. [Solution] A communication system includes a mobile terminal and a base station that performs wireless communication with the mobile terminal. Data is transmitted and received between the mobile terminal and the base station during a random access process. The random access process includes a first step of transmitting a random access preamble message from the mobile terminal to the base station, a second step of transmitting a random access response message from the base station to the mobile terminal, a third step of transmitting a scheduled transmission message from the mobile terminal to the base station, and a fourth step of transmitting a contention resolution message from the base station to the mobile terminal. Data is transmitted and received using the scheduled transmission message of the third step. The scheduled transmission message of the third step is an RRC (Radio Resource Control) message.

Description

[Technical Field]

[0001] The present invention relates to a communication system and the like. [Background technology]

[0002] Among the third-generation communication systems, the Wideband Code Division Multiple Access (W-CDMA) system has been commercially available in Japan since 2001. Also, the High Speed ​​Downlink Packet Access (HSDPA) service has been launched, which achieves even faster data transmission speeds on the downlink by adding a packet transmission channel (High Speed-Downlink Shared Channel: HS-DSCH) to the downlink (dedicated data channel, dedicated control channel). Furthermore, the High Speed ​​Uplink Packet Access (HSUPA) service has also been launched to further increase the speed of data transmission in the uplink. W-CDMA is a communication system defined by the 3rd Generation Partnership Project (3GPP), a standardization organization for mobile communication systems, and Release 10 of the standard is currently being compiled.

[0003] 3GPP is also considering a new communication method other than W-CDMA, which is called Long Term Evolution (LTE) for the wireless section and System Architecture Evolution (SAE) for the overall system configuration including the core network and radio access network (hereinafter collectively referred to as the network). This communication method is also called the 3.9G (3.9 Generation) system.

[0004] LTE's access method, wireless channel configuration, and protocols are completely different from those of W-CDMA (HSDPA / HSUPA). For example, W-CDMA uses Code Division Multiple Access, while LTE uses Orthogonal Frequency Division Multiplexing (OFDM) for downlinks and Single Carrier Frequency Division Multiple Access (SC-FDMA) for uplinks. Furthermore, while W-CDMA's bandwidth is 5 MHz, LTE allows base station users to select from 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, and 20 MHz. Also, unlike W-CDMA, LTE does not use circuit switching and is packet-only.

[0005] In LTE, the communication system is constructed using a new core network that is different from GPRS (General Packet Radio Service), which is the core network of W-CDMA, so the LTE radio access network is defined as an independent radio access network separate from the W-CDMA network.

[0006] Therefore, to distinguish it from a W-CDMA communication system, in an LTE communication system, the core network is called EPC (Evolved Packet Core) and the radio access network is called E-UTRAN (Evolved Universal Terrestrial Radio Access). In the radio access network, a base station that communicates with a mobile terminal (User Equipment: UE), which is a communication terminal device, is called eNB (E-UTRAN NodeB). The EPC also performs the function of a base station controller (Radio Network Controller) that exchanges control data and user data with multiple base stations. The EPC is also called aGW (Access Gateway). The system consisting of the EPC and E-UTRAN is called EPS (Evolved Packet System).

[0007] The LTE communication system provides unicast service and E-MBMS (Evolved Multimedia Broadcast Multicast Service). E-MBMS service is a broadcast multimedia service. E-MBMS service is sometimes simply called MBMS. E-MBMS service transmits large-volume broadcast content such as news, weather forecasts, and mobile broadcasts to multiple mobile terminals. This is also called point-to-multipoint service.

[0008] The decisions made by 3GPP regarding the overall architecture of the LTE system are described in Non-Patent Document 1 (Chapter 4). The overall architecture will be explained using Fig. 1, which 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 in a base station 102, E-UTRAN is composed of one or more base stations 102.

[0009] The base stations 102 schedule and transmit paging signals (also referred to as 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 the mobility management entity (MME) 103 via an S1_MME interface and to a serving gateway (S-GW) 104 via an S1_U interface.

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

[0011] 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). The P-GW performs packet filtering for each user and assigns UE-ID addresses.

[0012] The control protocol RRC between the mobile terminal 101 and base station 102 performs broadcast, paging, RRC connection management, etc. The states between the base station and 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 re-selection, mobility, etc. are performed. In RRC_CONNECTED, the mobile terminal has an RRC connection and can transmit and receive data to and from the network. In addition, in RRC_CONNECTED, handover (HO), measurement of neighbor cells, etc. are performed.

[0013] The decisions made by 3GPP regarding the frame configuration in the LTE system, as described in Non-Patent Document 1 (Chapter 5), will be explained using Figure 2. Figure 2 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. In Figure 2, one radio frame is 10 ms. The radio frame is divided into 10 equally sized subframes. Each subframe is divided into two equally sized slots. The first and sixth subframes of each radio frame include a downlink synchronization signal (SS). The synchronization signals include a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0014] Channels for MBSFN (Multimedia Broadcast Multicast Service Single Frequency Network) and channels for other than MBSFN are multiplexed on a subframe basis. MBSFN transmission is a simultaneous broadcast transmission technique achieved by transmitting the same waveform from multiple cells at the same time. MBSFN transmissions from multiple cells in an MBSFN area are recognized by mobile terminals as a single transmission. MBSFN is a network that supports such MBSFN transmission. Hereinafter, a subframe for MBSFN transmission is referred to as an MBSFN subframe.

[0015] Non-Patent Document 2 describes an example of signaling when allocating MBSFN subframes. Fig. 3 is an explanatory diagram showing the structure of an MBSFN frame. As shown in Fig. 3, radio frames including MBSFN subframes are allocated for each allocation period (radio frame allocation period). MBSFN subframes are subframes allocated for MBSFN in radio frames defined by an allocation period and an allocation offset (radio frame allocation offset), and are subframes for transmitting multimedia data. A radio frame that satisfies the following formula (1) is a radio frame that includes an MBSFN subframe. SFN mod radioFrameAllocationPeriod=radioFrameAllocationOffset …(1)

[0016] MBSFN subframe allocation is performed using 6 bits. The leftmost bit defines the MBSFN allocation for the second subframe (#1). The second bit from the left defines the MBSFN allocation for the third subframe (#2), the third bit from the left defines the MBSFN allocation for the fourth subframe (#3), the fourth bit from the left defines the MBSFN allocation for the seventh subframe (#6), the fifth bit from the left defines the eighth subframe (#7), and the sixth bit from the left defines the MBSFN allocation for the ninth subframe (#8). If the bit indicates "1", it indicates that the corresponding subframe is allocated for MBSFN.

[0017] The decisions made by 3GPP regarding the channel configuration in the LTE system 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 (Closed Subscriber Group) cell. The physical channel will be explained using Fig. 4. Fig. 4 is an explanatory diagram explaining the physical channels used in an LTE communication system.

[0018] In Figure 4, a Physical Broadcast Channel (PBCH) 401 is a channel for downlink transmission from a base station 102 to a mobile terminal 101. A BCH transport block is mapped to four subframes in a 40 ms interval. There is no explicit signaling of the 40 ms timing.

[0019] The Physical Control Format Indicator Channel (PCFICH) 402 is a channel for downlink transmission from the base station 102 to the mobile terminal 101. The PCFICH notifies the mobile terminal 101 of the number of OFDM symbols used for PDCCHs from the base station 102. The PCFICH is transmitted in each subframe.

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

[0021] The physical downlink shared channel (PDSCH) 404 is a channel for downlink transmission from the base station 102 to the mobile terminal 101. A downlink shared channel (DL-SCH), which is a transport channel, and a PCH, which is also a transport channel, are mapped to the PDSCH.

[0022] The physical multicast channel (PMCH) 405 is a channel for downlink transmission from the base station 102 to the mobile terminal 101. A multicast channel (MCH), which is a transport channel, is mapped to the PMCH.

[0023] The Physical Uplink Control Channel (PUCCH) 406 is a channel for uplink transmission from the mobile terminal 101 to the base station 102. The PUCCH carries Ack / Nack, which is a response signal to downlink transmission. The PUCCH carries a CQI (Channel Quality Indicator) report. The CQI is quality information indicating the quality of received data or the quality of the communication path. The PUCCH also carries a Scheduling Request (SR).

[0024] The Physical Uplink Shared Channel (PUSCH) 407 is a channel for uplink transmission from the mobile terminal 101 to the base station 102. The Uplink Shared Channel (UL-SCH), which is one of the transport channels shown in FIG. 5, is mapped to the PUSCH.

[0025] A physical hybrid ARQ indicator channel (PHICH) 408 is a channel for downlink transmission from the base station 102 to the mobile terminal 101. The PHICH carries Ack / Nack, which is a response signal to uplink transmission. A physical random access channel (PRACH) 409 is a channel for uplink transmission from the mobile terminal 101 to the base station 102. The PRACH carries a random access preamble.

[0026] Downlink reference signals (RS) are symbols known in mobile communication systems. Five types of downlink reference signals are defined: Cell-specific Reference Signals (CRS), MBSFN reference signals, UE-specific reference signals such as Demodulation Reference Signals (DM-RS), Positioning Reference Signals (PRS), and Channel-State Information Reference Signals (CSI-RS). Reference signal received power (RSRP) measurements are available as a physical layer measurement for mobile terminals.

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

[0028] Of the downlink transport channels shown in Fig. 5(A), a broadcast channel (BCH) is broadcast to the entire coverage of the base station (cell). The BCH is mapped to a physical broadcast channel (PBCH).

[0029] The Downlink Shared Channel (DL-SCH) is subject to retransmission control using Hybrid ARQ (HARQ). 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) for mobile terminals to reduce power consumption. DL-SCH is mapped to the Physical Downlink Shared Channel (PDSCH).

[0030] The Paging Channel (PCH) supports DRX for mobile terminals to enable low power consumption. The PCH is required to 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.

[0031] 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.

[0032] Among the uplink transport channels shown in Figure 5(B), the uplink shared channel (UL-SCH) is subject to retransmission control using HARQ (Hybrid ARQ). The UL-SCH supports dynamic or semi-static resource allocation. The UL-SCH is mapped to the physical uplink shared channel (PUSCH).

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

[0034] We will explain HARQ. HARQ is a technology that improves the communication quality of a transmission channel by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction works effectively by retransmission even on transmission channels where communication quality varies. In particular, by combining the reception results of the initial transmission and the retransmission when retransmitting, it is possible to obtain further quality improvement.

[0035] An example of a retransmission method will be explained below. If the receiving side is unable to decode the received data correctly, 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, having received the "Nack," will retransmit the data. If the receiving side is able to decode the received data correctly, in other words, if no CRC error occurs (CRC=OK), the receiving side will send an "Ack" to the transmitting side. The transmitting side, having received the "Ack," will send the next data.

[0036] One example of an HARQ scheme is Chase Combining. Chase Combining is a scheme in which the same data is transmitted in the initial transmission and in the retransmission, and the gain is improved by combining the initial transmission data with the retransmission data in the retransmission. Chase Combining is based on the idea that even if the initial transmission data contains errors, some of the data may be correct, and by combining the correct parts of the initial transmission data with the retransmission data, data can be transmitted with higher accuracy. Another example of an HARQ scheme is IR (Incremental Redundancy). IR increases redundancy by transmitting parity bits in the retransmission, which increases redundancy in combination with the initial transmission, and improves quality through error correction functionality.

[0037] The logical channels described in Non-Patent Document 1 (Chapter 6) will be explained using 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.

[0038] 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).

[0039] The Paging Control Channel (PCCH) is a downlink channel for transmitting paging information and system information changes. 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.

[0040] 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.

[0041] The Multicast Control Channel (MCCH) is a downlink channel for point-to-multipoint transmission. The MCCH is used to transmit 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 Multicast Channel (MCH), which is a transport channel.

[0042] A Dedicated Control Channel (DCCH) is a channel that transmits dedicated control information between a mobile terminal and a network on a one-to-one basis. The DCCH is used when the mobile terminal is in an RRC connection. 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.

[0043] A Dedicated Traffic Channel (DTCH) is a point-to-point 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, it is mapped to a downlink shared channel (DL-SCH).

[0044] The Multicast Traffic Channel (MTCH) is a downlink channel for transmitting traffic data from the network to mobile terminals. The MTCH is a channel used only by mobile terminals receiving MBMS. The MTCH is mapped to the Multicast Channel (MCH).

[0045] CGI stands for Cell Global Identification. ECGI stands for E-UTRAN Cell Global Identification. Closed Subscriber Group (CSG) cells are introduced in LTE, Long Term Evolution Advanced (LTE-A) (described later), and Universal Mobile Telecommunication System (UMTS). CSG cells are described below (see Chapter 3.1 of Non-Patent Document 3).

[0046] A CSG (Closed Subscriber Group) cell is a cell for which an operator has identified available subscribers (hereinafter referred to as a "specific subscriber cell"). The identified subscribers are permitted to access one or more cells in a PLMN (Public Land Mobile Network). The one or more cells to which the identified subscribers are permitted to access are called "CSG cell(s)." However, there are access restrictions within the PLMN.

[0047] A CSG cell is part of a PLMN that broadcasts a unique CSG identity (CSG ID; CSG-ID) and broadcasts a CSG indication of "TRUE." Members of a pre-registered and authorized subscriber group access the CSG cell using the CSG-ID, which is access permission information.

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

[0049] The location of a mobile terminal is tracked in units of an area consisting of one or more cells. Location tracking is performed to track the location of a mobile terminal even when it is in standby mode and to enable the mobile terminal to be called, in other words, to allow the mobile terminal to receive calls. The area used for tracking the location of a mobile terminal is called a tracking area.

[0050] The CSG White List is a list that may be stored in a Universal Subscriber Identity Module (USIM) and records all CSG IDs of CSG cells to which a subscriber belongs. The CSG White List is sometimes simply called a white list or an Allowed CSG List. The MME performs access control for mobile terminal access through CSG cells (see Chapter 4.3.1.2 of Non-Patent Document 4). Specific examples of mobile terminal access include attach, combined attach, detach, service request, and Tracking Area Update procedure (see Chapter 4.3.1.2 of Non-Patent Document 4).

[0051] The service types of a mobile terminal in standby mode are explained below (see Non-Patent Document 3, Chapter 4.3). Service types of a mobile terminal in standby mode include limited service (also called limited service), standard service (normal service), and operator service. Limited services include emergency calls, ETWS (Earthquake and Tsunami Warning System), and CMAS (Commercial Mobile Alert System) on acceptable cells, which will be described later. Standard service (also called normal service) is a public service on an appropriate cell, which will be described later. Operator service is a service only for operators on reserved cells, which will be described later.

[0052] The term "suitable cell" is explained below. A "suitable cell" is a cell on which a UE may camp to receive normal service. Such a cell must satisfy the following conditions (1) and (2).

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

[0054] (2) The latest information provided by the NAS (Non-Access Stratum) and the following conditions (a) to (d) must be met. (a) The cell is not a barred cell. (b) The cell is part of a Tracking Area (TA) that is not part of the "Prohibited LAs for Roaming" list. In that case, the cell must satisfy (1) above. (c) the cell satisfies 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", i.e., is included in the UE's CSG WhiteList.

[0055] The term "acceptable cell" is explained below. An "acceptable cell" is a cell on which a UE may camp to receive limited services. Such a cell must satisfy all of the following requirements (1) and (2).

[0056] (1) The cell is not a forbidden cell (also known as a "barred cell"). (2) The cell meets the cell selection evaluation criteria.

[0057] A "barred cell" is designated in the system information. A "reserved cell" is designated in the system information.

[0058] "Camping on a cell" refers to a state in which a UE completes a cell selection or cell reselection process and selects a cell for monitoring system information and paging information. The cell on which a UE camps is sometimes called a "serving cell."

[0059] 3GPP is studying base stations called Home-NodeB (Home-NB; HNB) and Home-eNodeB (Home-eNB; HeNB). HNB in ​​UTRAN and HeNB in ​​E-UTRAN are base stations for access services for homes, businesses, and businesses, for example. Non-Patent Document 5 discloses three different modes of access to HeNB and HNB. Specifically, it discloses an open access mode, a closed access mode, and a hybrid access mode.

[0060] Each mode has the following characteristics: In the open access mode, the HeNB and HNB are operated as normal cells of a regular operator. In the closed access mode, the HeNB and HNB are operated as CSG cells, which are accessible only by CSG members. In the hybrid access mode, the HeNB and HNB are operated as CSG cells, which are simultaneously accessible by non-CSG members. In other words, a cell in the hybrid access mode (also called a hybrid cell) is a cell that supports both the open access mode and the closed access mode.

[0061] In 3GPP, among all PCIs (Physical Cell Identities), there is a PCI range reserved by the network for use in CSG cells (see Non-Patent Document 1, Chapter 10.5.1.1). Dividing a PCI range is sometimes called PCI split. Information about PCI splits (also called PCI split information) is broadcast from a base station to mobile terminals under its control by system information. Being under the control of a base station means that the base station is the serving cell.

[0062] Non-Patent Document 6 discloses the basic operation of a mobile terminal using PCI split. A mobile terminal that does not have PCI split information must use all PCIs, for example, all 504 codes, to perform a cell search. On the other hand, a mobile terminal that has PCI split information can perform a cell search using the PCI split information.

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

[0064] In the LTE-A system, support for relays and relay nodes (RNs) is being considered to achieve high communication speeds, high throughput at cell edges, new coverage areas, and so on. The relay node, which is a relay device, is wirelessly connected to the radio access network via a cell called a donor cell (hereinafter sometimes referred to as a "donor eNB (DeNB)"). Within the range of the donor cell, the link from the network (NW) to the relay node shares the same frequency band as the link from the network to the UE. In this case, UEs compatible with 3GPP Release 8 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.

[0065] In the FDD (Frequency Division Duplex) backhaul link multiplexing method, transmission from DeNB to RN is performed in the downlink (DL) frequency band, and transmission from RN to DeNB is performed in the uplink (UL) frequency band. In the relay resource division method, the link from DeNB to RN and the link from RN to UE are time-division multiplexed in one frequency band, and the link from RN to DeNB and the link from UE to RN are also time-division multiplexed in one frequency band. This prevents the transmission of a relay from interfering with the reception of the relay itself.

[0066] 3GPP is considering not only regular eNBs (macro cells) but also pico eNBs (pico cells), HeNBs (HNBs, CSG cells), nodes for hot zone cells, relay nodes, remote radio heads (RRHs), repeaters, and other so-called local nodes. A network consisting of the various types of cells mentioned above is sometimes called a heterogeneous network (HETNET).

[0067] In LTE, frequency bands available for communication (hereinafter sometimes referred to as "operating bands") are predetermined. Non-Patent Document 9 describes these frequency bands.

[0068] In the LTE-A system, carrier aggregation (CA) is being considered, which aggregates two or more component carriers (CCs) to support wider frequency bandwidths (transmission bandwidths) up to 100 MHz.

[0069] While a UE that supports LTE (3GPP Release 8 or 9) can transmit and receive on only one CC corresponding to one serving cell, a UE that supports 3GPP Release 10 is expected to have the capability to simultaneously transmit and receive on multiple CCs corresponding to multiple serving cells, or to receive only, or to transmit only.

[0070] Each CC uses the configuration of 3GPP Release 8 or 9, and CA supports contiguous CCs, non-contiguous CCs, and CCs with different frequency bandwidths. A UE cannot configure more uplink CCs (UL CCs) than the number of downlink CCs (DL CCs). CCs configured by the same eNB do not need to provide the same coverage. CCs are compatible with 3GPP Release 8 or 9.

[0071] In CA, there is one independent HARQ entity per serving cell in both uplink and downlink. A transport block is generated per TTI per serving cell. Each transport block and HARQ retransmission is mapped to a single serving cell.

[0072] When CA is configured, the UE has only one RRC connection with the network. In the RRC connection, one serving cell provides NAS mobility information and security input. This cell is called the primary cell (PCell). In the downlink, the carrier corresponding to the PCell is the downlink primary component carrier (DL PCC). In the uplink, the carrier corresponding to the PCell is the uplink primary component carrier (UL PCC).

[0073] Depending on the UE's capabilities, a secondary cell (SCell) is configured to form a pair of a PCell and a serving cell. In the downlink, the carrier corresponding to the SCell is a downlink secondary component carrier (DL SCC). In the uplink, the carrier corresponding to the SCell is an uplink secondary component carrier (UL SCC).

[0074] For one UE, a set of one PCell and a serving cell consisting of one or more SCells is configured.

[0075] 3GPP is currently studying the aforementioned LTE Advanced (LTE-A) as a new, more advanced wireless communication method (see Non-Patent Document 7 and Non-Patent Document 8). LTE-A is based on the LTE wireless communication method, and is configured by adding several new technologies to it. These new technologies include wider bandwidth extension, a technology that supports wider bandwidths, and Coordinated Multiple Point transmission and reception (CoMP). CoMP, which is being studied by 3GPP for LTE-A, is described in Non-Patent Document 10.

[0076] CoMP is a technology that aims to expand the coverage of high data rates, improve throughput at cell edges, and increase throughput in communication systems by coordinating transmission or reception between multiple geographically separated points. CoMP is divided into downlink CoMP (DL CoMP) and uplink CoMP (UL CoMP).

[0077] In DL CoMP, PDSCH to one mobile terminal (UE) is transmitted in a coordinated manner across multiple points. The PDSCH to one UE may be transmitted from one point in the multipoint system, or from multiple points in the multipoint system. In DL CoMP, the serving cell is the single cell that transmits resource allocation via the PDCCH.

[0078] As methods for DL ​​CoMP, joint processing (JP) and coordinated scheduling (CS) or coordinated beamforming (CB) (hereinafter sometimes referred to as "CS / CB") are being considered.

[0079] In JP, data is available at each point in the CoMP cooperating set. JP includes joint transmission (JT) and dynamic point selection (DPS). DPS includes dynamic cell selection (DCS). In JT, PDSCH transmission is performed from multiple points at a given time, specifically from some or all of the CoMP cooperating set. In DPS, PDSCH transmission is performed from one point in the CoMP cooperating set at a given time.

[0080] The CS / CB is available only for data transmission from the serving cell, where user scheduling or beamforming decisions are made along with coordination among cells corresponding to the CoMP cooperating set.

[0081] Units and cells are considered as points for transmitting and receiving data at multipoints, and base stations (NB, eNB, HNB, HeNB), RRUs (Remote Radio Units), RREs (Remote Radio Equipment), RRHs (Remote Radio Heads), relay nodes (RNs), etc. Units and cells that perform coordinated multipoint transmission are sometimes called multipoint units and multipoint cells, respectively. [Prior art documents] [Non-patent literature]

[0082] [Non-Patent Document 1] 3GPP TS36.300 V10.5.0 [Non-patent document 2] 3GPP TS36.331 V10.3.0 [Non-patent document 3] 3GPP TS36.304 V10.3.0 Chapter 3.1, Chapter 4.3, Chapter 5.2.4 [Non-patent document 4] 3GPP TR 23.830 V9.0.0 [Non-patent document 5] 3GPP S1-083461 [Non-patent document 6] 3GPP R2-082899 [Non-Patent Document 7] 3GPP TR 36.814 V9.0.0 [Non-patent document 8] 3GPP TR 36.912 V10.0.0 [Non-Patent Document 9] 3GPP TS 36.101 V10.3.0 [Non-Patent Document 10] 3GPP TR 36.819 V11.0.0 [Non-Patent Document 11] 3GPP TR 23.888 V1.6.0 [Non-Patent Document 12] 3GPP TR 22.801 V12.0.0 [Non-Patent Document 13] 3GPP TS 23.401 V11.0.0 [Non-Patent Document 14] 3GPP TS 24.301 V11.1.0 [Non-Patent Document 15] 3GPP R2-120444 [Non-Patent Document 16] 3GPP S2-114341 Summary of the Invention [Problem to be solved by the invention]

[0083] With the development of cellular wireless communication, such as the aforementioned 3GPP standard, various forms of communication between applications using wireless networks are being implemented or are being attempted to be implemented. For example, there is Machine Type Communication (MTC) in 3GPP and communication between applications that are intended for wired communication, such as the IEEE802.3 standard.

[0084] Such applications are used in environments and forms that are different from those envisioned in conventional mobile communications, and therefore pose various challenges and problems.

[0085] For example, it is considered that a communication terminal device that performs MTC (hereinafter referred to as "MTC terminal") will be installed in a gas meter, an animal, or other such environment (see Non-Patent Document 11). In such cases, since the MTC terminal will be battery-powered, it must be assumed that battery replacement and recharging will be difficult. Therefore, even lower power consumption is required compared to ordinary communication terminal devices. In addition, risks such as theft and destruction must be considered, so monitoring of the MTC terminal is also necessary.

[0086] Furthermore, in applications other than MTC, such as communications using HTTP (HyperText Transfer Protocol) and TCP (Transmission Control Protocol), small packets of data (hereinafter referred to as "keep-alive packets") may be periodically transmitted for the sole purpose of monitoring session connections between applications at the end of the communication (see Non-Patent Document 12). In this case, the communication terminal device must periodically perform connection processing, specifically, transmission processing, to transmit the keep-alive packets.

[0087] This connection process consumes system resources in the wireless access network, causing problems such as an increase in the processing load on wireless resources and communication nodes. Furthermore, performing the connection process periodically also increases the power consumption of communication terminal devices.

[0088] An object of the present invention is to provide a communication system that can check the status of a communication terminal device while reducing the processing load and power consumption. [Means for solving the problem]

[0089] The communication system of the present invention is a communication system comprising a mobile terminal and a base station that performs wireless communication with the mobile terminal, and data is transmitted and received between the mobile terminal and the base station during a random access process, the random access process including a first step of transmitting a random access preamble message from the mobile terminal to the base station, a second step of transmitting a random access response message from the base station to the mobile terminal, a third step of transmitting a scheduled transmission message from the mobile terminal to the base station, and a fourth step of transmitting a contention resolution message from the base station to the mobile terminal, and the data is transmitted and received using the scheduled transmission message of the third step, which is an RRC (Radio Resource Control) message. The mobile terminal of the present invention is a mobile terminal that performs wireless communication with a base station, and transmits and receives data with the base station during a random access process, the random access process including a first step of transmitting a random access preamble message from the mobile terminal to the base station, a second step of transmitting a random access response message from the base station to the mobile terminal, a third step of transmitting a scheduled transmission message from the mobile terminal to the base station, and a fourth step of transmitting a contention resolution message from the base station to the mobile terminal, and the data is transmitted and received using the scheduled transmission message of the third step, which is an RRC (Radio Resource Control) message. The base station of the present invention is a base station that performs wireless communication with a mobile terminal, and transmits and receives data with the mobile terminal during a random access process, the random access process including a first step of transmitting a random access preamble message from the mobile terminal to the base station, a second step of transmitting a random access response message from the base station to the mobile terminal, a third step of transmitting a scheduled transmission message from the mobile terminal to the base station, and a fourth step of transmitting a contention resolution message from the base station to the mobile terminal, and the data is transmitted and received using the scheduled transmission message of the third step, which is an RRC (Radio Resource Control) message. The mobility management device of the present invention is a mobility management device in a communication system comprising a mobile terminal, a base station which performs wireless communication with the mobile terminal, a mobility management device which manages the mobility of the mobile terminal, and a gateway device which transmits and receives data to and from the base station, and which transmits and receives data between the base station and the gateway device using an interface between the base station and the gateway device or via the mobility management device.When data is transmitted and received between the base station and the gateway device via the mobility management device, data is transmitted and received between the mobile terminal and the base station during a random access process, and the random access process includes a first step of transmitting a random access preamble message from the mobile terminal to the base station, a second step of transmitting a random access response message from the base station to the mobile terminal, a third step of transmitting a scheduled transmission message from the mobile terminal to the base station, and a fourth step of transmitting a contention resolution message from the base station to the mobile terminal.Data is transmitted and received between the base station and the mobile terminal using the scheduled transmission message of the third step, and the scheduled transmission message of the third step is an RRC (Radio Resource Control) message. The gateway device of the present invention comprises a mobile terminal, a base station which performs wireless communication with the mobile terminal, a mobility management device which manages the mobility of the mobile terminal, and a gateway device which transmits and receives data to and from the base station, and is a gateway device in a communication system in which data is transmitted and received between the base station and the gateway device using an interface between the base station and the gateway device or via the mobility management device. When data is transmitted and received between the base station and the gateway device via the mobility management device, data is transmitted and received between the mobile terminal and the base station during a random access process, the random access process including a first step of transmitting a random access preamble message from the mobile terminal to the base station, a second step of transmitting a random access response message from the base station to the mobile terminal, a third step of transmitting a scheduled transmission message from the mobile terminal to the base station, and a fourth step of transmitting a contention resolution message from the base station to the mobile terminal. Data is transmitted and received between the base station and the mobile terminal using the scheduled transmission message of the third step, and the scheduled transmission message of the third step is an RRC (Radio Resource Control) message. [Effects of the Invention]

[0090] According to the communication system of the present invention, it is possible to check the state of a communication terminal device while suppressing the processing load and power consumption.

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

[0092] [Figure 1] FIG. 1 is an explanatory diagram showing the configuration of an LTE communication system. [Figure 2] FIG. 1 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. [Figure 3] FIG. 1 is an explanatory diagram showing the structure of an MBSFN frame. [Figure 4] FIG. 1 is an explanatory diagram illustrating physical channels used in an LTE communication system. [Figure 5] FIG. 1 is an explanatory diagram illustrating transport channels used in an LTE communication system. [Figure 6] FIG. 1 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 being discussed in 3GPP. [Figure 8] FIG. 8 is a block diagram showing the configuration of a mobile terminal 71 shown in FIG. 7, which is a mobile terminal according to the present invention. [Figure 9] FIG. 8 is a block diagram showing the configuration of a base station 72 shown in FIG. 7, which is a base station according to the present invention. [Figure 10] 8 is a block diagram showing the configuration of an MME unit 73 shown in FIG. 7, which is an MME according to the present invention. [Figure 11] FIG. 8 is a block diagram showing the 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 operation performed by a mobile terminal (UE) in an LTE communication system. [Figure 13] FIG. 1 is a diagram illustrating an example of a sequence of TAU processing periodically executed in an LTE communication system. [Figure 14] FIG. 2 is a diagram showing an example of a sequence of the communication system according to the first embodiment. [Figure 15] FIG. 10 is a diagram showing an example of a sequence of a communication system according to a second modification of the first embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of a sequence of a random access process. [Figure 17] FIG. 13 is a diagram showing an example of a sequence of a communication system according to a fourth modification of the first embodiment. [Figure 18] FIG. 13 is a diagram showing another example of the sequence of the communication system according to the fourth modification of the first embodiment. [Figure 19] FIG. 1 is a diagram illustrating an example of a sequence of paging processing in an LTE communication system. [Figure 20] FIG. 1 is a diagram illustrating an example of a sequence of paging processing in an LTE communication system. [Figure 21] FIG. 13 is a diagram showing an example of a sequence of a communication system according to a fifth modification of the first embodiment. [Figure 22] FIG. 13 is a diagram showing an example of a sequence of a communication system according to a fifth modification of the first embodiment. [Figure 23] FIG. 13 is a diagram showing another example of the sequence of the communication system according to the fifth modification of the first embodiment. [Figure 24] FIG. 13 is a diagram showing another example of the sequence of the communication system according to the fifth modification of the first embodiment. [Figure 25] FIG. 13 is a diagram showing another example of the sequence of the communication system according to the fifth modification of the first embodiment. [Figure 26] FIG. 13 is a diagram showing another example of the sequence of the communication system according to the fifth modification of the first embodiment. [Figure 27] FIG. 10 is a diagram showing a sequence for explaining a problem to be solved in the second embodiment. [Figure 28] FIG. 10 is a diagram showing a sequence for explaining a problem to be solved in the second embodiment. [Figure 29] FIG. 10 is a diagram showing a sequence for explaining a problem to be solved in the second embodiment. [Figure 30] FIG. 10 is a diagram showing an example of a sequence of a communication system in the second embodiment. [Figure 31] FIG. 11 is a diagram showing a sequence for explaining a problem to be solved in the third embodiment. [Figure 32] FIG. 11 is a diagram showing a sequence for explaining a problem to be solved in the third embodiment. [Figure 33] FIG. 11 is a diagram showing an example of a sequence of a communication system in the third embodiment. [Figure 34] FIG. 11 is a diagram showing an example of a sequence of a communication system in the third embodiment. [Figure 35] FIG. 11 is a diagram showing an example of a sequence of a communication system in the third embodiment. [Figure 36] FIG. 13 is a diagram showing an example of a sequence of a communication system according to a first modification of the third embodiment. [Figure 37] FIG. 13 is a diagram showing an example of a sequence of a communication system according to a first modification of the third embodiment. [Figure 38] FIG. 13 is a diagram showing an example of a sequence of a communication system in the fourth embodiment. [Figure 39] FIG. 13 is a diagram showing an example of a sequence of a communication system in the fourth embodiment. [Figure 40] FIG. 13 is a diagram showing an example of a sequence of a communication system in a first modification of the fourth embodiment. [Figure 41] FIG. 13 is a diagram showing an example of a sequence of a communication system in a first modification of the fourth embodiment. [Figure 42] FIG. 13 is a diagram showing an example of a sequence of a communication system in the fifth embodiment. [Figure 43] FIG. 13 is a diagram showing an example of a sequence of a communication system in the fifth embodiment. [Figure 44] FIG. 20 is a diagram showing an example of a sequence of a communication system in the sixth embodiment. [Figure 45] FIG. 20 is a diagram showing an example of a sequence of a communication system in the sixth embodiment. [Figure 46] FIG. 20 is a diagram showing an example of a sequence of a communication system in the sixth embodiment. [Figure 47] FIG. 20 is a diagram showing an example of a sequence of a communication system in the sixth embodiment. [Figure 48] FIG. 20 is a diagram showing another example of the sequence of the communication system in the sixth embodiment. [Figure 49] FIG. 20 is a diagram showing another example of the sequence of the communication system in the sixth embodiment. [Figure 50] FIG. 20 is a diagram showing a sequence for explaining a problem to be solved by a first modification of the sixth embodiment. [Figure 51] FIG. 20 is a diagram showing a sequence for explaining a problem to be solved by a first modification of the sixth embodiment. [Figure 52]FIG. 22 is a diagram showing an example of a sequence of a communication system in a first modification of the sixth embodiment. [Figure 53] FIG. 22 is a diagram showing an example of a sequence of a communication system in a first modification of the sixth embodiment. [Figure 54] FIG. 20 is a diagram showing another example of the sequence of the communication system in the first modification of the sixth embodiment. [Figure 55] FIG. 20 is a diagram showing another example of the sequence of the communication system in the first modification of the sixth embodiment. [Figure 56] FIG. 20 is a diagram showing another example of the sequence of the communication system in the first modification of the sixth embodiment. [Figure 57] FIG. 20 is a diagram showing a sequence for explaining a problem of the seventh embodiment. [Figure 58] FIG. 20 is a diagram showing a sequence for explaining a problem of the seventh embodiment. [Figure 59] FIG. 20 is a diagram showing an example of a sequence of a communication system in a seventh embodiment. [Figure 60] FIG. 20 is a diagram showing an example of a sequence of a communication system in a seventh embodiment. [Figure 61] FIG. 20 is a diagram showing an example of a sequence of a communication system in a seventh embodiment. [Figure 62] FIG. 13 is a diagram showing another example of the sequence of the communication system in the seventh embodiment. [Figure 63] FIG. 13 is a diagram showing another example of the sequence of the communication system in the seventh embodiment. [Figure 64] FIG. 13 is a diagram showing another example of the sequence of the communication system in the seventh embodiment. [Figure 65] FIG. 13 is a diagram showing another example of the sequence of the communication system in the seventh embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0093] Embodiment 1 Fig. 7 is a block diagram showing the overall configuration of an LTE mobile communication system being discussed in 3GPP. 3GPP is studying 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 has proposed a configuration as shown in Fig. 7 for E-UTRAN (see Chapter 4.6.1 of Non-Patent Document 1).

[0094] Referring now to Figure 7, a mobile terminal device (hereinafter referred to as "mobile terminal (User Equipment: UE)") 71, which is a communication terminal device, is capable of wireless communication with a base station device (hereinafter referred to as "base station") 72, and transmits and receives signals via wireless communication. The base station 72 is classified into an eNB 72-1, which is a macro cell, and a Home-eNB 72-2, which is a local node. The eNB 72-1 has a relatively large-scale coverage, which is the range over which communication with the mobile terminal (UE) 71 is possible. The Home-eNB 72-2 has a relatively small-scale coverage, which is its coverage.

[0095] 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. Multiple MME units 73 may be connected to one eNB72-1. The MME units 73 are included in the EPC, which is a core network. The eNBs 72-1 are connected to each other via an X2 interface, and control information is communicated between the eNBs 72-1.

[0096] 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-eNBs 72-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 HeNBGW 74 are connected via an S1 interface, and the HeNBGW 74 and the MME unit 73 are connected via the S1 interface.

[0097] One or more Home-eNBs 72-2 are connected to one HeNBGW 74, and information is communicated through the S1 interface. The HeNBGW 74 is connected to one or more MME units 73, and information is communicated through the S1 interface.

[0098] The MME unit 73 and the HeNBGW 74 are upper node devices, and control connections between the eNB 72-1 and the Home-eNB 72-2, which are base stations, and the mobile terminal (UE) 71. The MME unit 73 and the HeNBGW 74 are included in the EPC, which is a core network.

[0099] Furthermore, 3GPP is considering the following configuration: The X2 interface between Home-eNBs 72-2 is supported. That is, Home-eNBs 72-2 are connected via the X2 interface, and control information is communicated between the Home-eNBs 72-2. From the MME unit 73, HeNBGW 74 appears as Home-eNB 72-2. From the Home-eNB 72-2, HeNBGW 74 appears as MME unit 73.

[0100] In either case where the Home-eNB72-2 is connected to the MME unit 73 via the HeNBGW 74 or where the Home-eNB72-2 is connected directly to the MME unit 73, the interface between the Home-eNB72-2 and the MME unit 73 is the same, the S1 interface. The HeNBGW 74 does not support mobility to or from the Home-eNB72-2 that spans multiple MME units 73. The Home-eNB72-2 configures and supports only one cell.

[0101] A base station device supports only one cell, such as the Home-eNB 72-2, but is not limited to this, and one base station device may support multiple cells. When one base station device supports multiple cells, each cell functions as a base station device.

[0102] FIG. 8 is a block diagram showing the configuration of the mobile terminal 71 shown in FIG. 7, which is a mobile terminal according to the present invention. The transmission process of the mobile terminal 71 shown in FIG. 8 will be described. First, control data from a protocol processing unit 801 and user data from an application unit 802 are stored in a transmission data buffer unit 803. The data stored in the transmission data buffer unit 803 is passed to an encoder unit 804, where it undergoes encoding processes such as error correction. Some data may be output directly from the transmission data buffer unit 803 to a modulator unit 805 without undergoing encoding processes. The data encoded by the encoder unit 804 is modulated by the modulator unit 805. The modulated data is converted into a baseband signal, and then output to a frequency converter unit 806, where it is converted into a radio transmission frequency. The transmission signal is then transmitted from an antenna 807 to the base station 72.

[0103] Furthermore, the receiving process of the mobile terminal 71 is performed 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 processes such as error correction are performed. Of the decoded data, control data is passed to the protocol processing unit 801, and 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.

[0104] Figure 9 is a block diagram showing the configuration of the base station 72 shown in Figure 7, which is a base station according to the present invention. The transmission processing of the base station 72 shown in Figure 9 will be described. An EPC communication unit 901 transmits and receives data between the base station 72 and the EPC (MME unit 73, HeNBGW 74, etc.). An other base station communication unit 902 transmits and receives data with other base stations. The EPC communication unit 901 and the other base station communication unit 902 each exchange information with a protocol processing unit 903. Control data from the protocol processing unit 903, and user data and control data from the EPC communication unit 901 and the other base station communication unit 902 are stored in a transmission data buffer unit 904.

[0105] The data stored in the transmission data buffer unit 904 is passed to an encoder unit 905, where it undergoes encoding processes 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 processes. The encoded data is modulated by 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.

[0106] The reception process of the base station 72 is performed 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 converter 907, and demodulated by a demodulator 909. The demodulated data is passed to a decoder 910, where decoding processes such as error correction are performed. Of the decoded data, control data is passed to the protocol processor 903 or the EPC communication unit 901 or other base station communication unit 902, and user data is passed to the EPC communication unit 901 and other base station communication unit 902. A series of processes of the base station 72 is controlled by a controller 911. Therefore, although the controller 911 is omitted in FIG. 9 , it is connected to each of the units 901 to 910.

[0107] The functions of the Home-eNB72-2 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 and another MME unit 73 at the same time.

[0108] 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. Therefore, the Home-eNB72-2 in this case needs to be connected to different HeNBGW74 depending on its location.

[0109] Figure 10 is a block diagram showing the configuration of an MME according to the present invention. Figure 10 shows the configuration of an MME 73a included in the MME unit 73 shown in Figure 7 above. A PDN GW communication unit 1001 transmits and receives data between the MME 73a and a PDN GW. A base station communication unit 1002 transmits and receives data via the S1 interface between the MME 73a and a base station 72. 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 a 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.

[0110] If 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. If 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.

[0111] 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 the control plane control unit 1005. The result of processing in the control plane control unit 1005 is transmitted to the PDN GW via the PDN GW communication unit 1001. In addition, the result of processing in the control plane control unit 1005 is transmitted to one or more base stations 72 via the base station communication unit 1002 by the S1 interface, and is also transmitted to one or more HeNBGWs 74 via the HeNBGW communication unit 1004.

[0112] 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, and the like, and performs overall 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 idle state (also called the LTE-IDLE state or simply idle), generation and control of paging signals in the idle state, addition, deletion, update, and search of tracking areas (TAs) for one or more mobile terminals 71 under its control, and management of the tracking area list (TA List).

[0113] The MME 73a initiates 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.

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

[0115] The functions of the MME 73a 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 a Closed Subscriber Group (CSG). The MME 73a optionally allows the execution of paging optimization.

[0116] Fig. 11 is a block diagram showing the 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 processing to transmit registration information and the like out of the data from the MME 73a passed via the EPC communication unit 1101 to multiple 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 multiple Home-eNBs 72-2 via the S1 interface.

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

[0118] The functions of the HeNBGW 74 discussed in 3GPP are as follows (see Chapter 4.6.2 of Non-Patent Document 1). The HeNBGW 74 relays S1 applications. Although it is part of the procedure of the MME 73a to the Home-eNB 72-2, the HeNBGW 74 terminates S1 applications that are not related to the mobile terminal 71. When the HeNBGW 74 is deployed, procedures that are 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 established between the HeNBGW 74 and other nodes. The HeNBGW 74 allows the execution of paging optimization as an option.

[0119] Next, an example of a cell search method in a mobile communication system is shown. Fig. 12 is a flowchart showing an outline of the process from 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, it synchronizes slot timing and frame timing using a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS) transmitted from a surrounding base station.

[0120] P-SS and S-SS are collectively called the synchronization signal (SS). The synchronization signal (SS) is assigned a synchronization code that corresponds one-to-one to the PCI (Physical Cell Identity) assigned to each cell. 504 different PCIs are being considered. These 504 different PCIs are used to achieve synchronization and to detect (identify) the PCI of the synchronized cell.

[0121] Next, in step ST1202, for the synchronized cell, a cell-specific reference signal (CRS), which is a reference signal (RS) transmitted from the base station for each cell, is detected and the RS received power (Reference Signal Received Power: RSRP) is measured. The reference signal (RS) uses a code that has a one-to-one correspondence with the PCI. By correlating with this code, it is possible to separate the cell from other cells. By deriving the code for the RS of the cell from the PCI identified in step ST1201, it is possible to detect the RS and measure the RS received power.

[0122] 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.

[0123] Next, in step ST1204, the PBCH of the best cell is received to obtain the BCCH, which is broadcast information. A MIB (Master Information Block), which includes cell configuration information, is mapped to the BCCH on the PBCH. 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 transmission bandwidth configuration: dl-bandwidth), the number of transmitting antennas, and the SFN (System Frame Number).

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

[0125] Next, in step ST1206, the mobile terminal compares the TAC of the SIB1 received in step ST1205 with the TAC part of the tracking area identity (TAI) in the tracking area (TA) list that the mobile terminal already has. The TA (Tracking Area) list is also called a TAI list. The TAI is an identifier of the TA and is composed of an MCC (Mobile Country Code), an MNC (Mobile Network Code), and a TAC (Tracking Area Code). The MCC is a country code. The MNC is a network code. The TAC is the code number of the TA.

[0126] If the comparison in step ST1206 shows that the TAC received in step ST1205 is the same as the TAC included in the TA (Tracking Area) list, the mobile terminal enters standby mode in that cell. If the comparison shows that the TAC received in step ST1205 is not included in the TA (Tracking Area) list, the mobile terminal requests a core network (EPC) including an MME, etc., to change the TA (Tracking Area) in order to perform a TAU (Tracking Area Update) through that cell.

[0127] The core network updates the TA (Tracking Area) list based on the identification number (UE-ID, etc.) of the mobile terminal sent from the mobile terminal along with the TAU request signal. The core network transmits the updated TA (Tracking Area) list to the mobile terminal. The mobile terminal rewrites (updates) the TAC list held by the mobile terminal based on the received TA (Tracking Area) list. The mobile terminal then enters standby mode in the cell.

[0128] The introduction of Closed Subscriber Group (CSG) cells is being considered for LTE, LTE-A, and Universal Mobile Telecommunication System (UMTS). As mentioned above, access is permitted only to one or more mobile terminals registered with a CSG cell. A CSG cell and one or more registered mobile terminals constitute one CSG. A CSG configured in this way is assigned a unique identification number called a CSG-ID. One CSG may have multiple CSG cells. Once a mobile terminal registers with one CSG cell, it can access other CSG cells in the CSG to which that CSG cell belongs.

[0129] Furthermore, a Home-eNB in ​​LTE and LTE-A 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 SIM (Subscriber Identity Module) or USIM. The whitelist stores CSG information of the CSG cell in which the mobile terminal has registered. Specific examples of CSG information include a CSG-ID, a Tracking Area Identity (TAI), and a TAC. As long as the CSG-ID and the TAC are associated with each other, either one may be used. Furthermore, as long as the CSG-ID and the TAC are associated with the ECGI, the ECGI may also be used.

[0130] 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 a CSG cell with a registered CSG-ID and a non-CSG cell.

[0131] HeNBs and HNBs are required to support various services. For example, in one service, an operator registers mobile terminals with certain HeNBs and HNBs and allows only registered mobile terminals to access cells of the HeNBs and HNBs, thereby increasing the radio resources available to the mobile terminals and enabling high-speed communication. To compensate for this, the operator sets a higher-than-normal charging fee.

[0132] To realize such services, CSG (Closed Subscriber Group) cells have been introduced, which can only be accessed by registered (subscribed, member) mobile terminals. It is required that many CSG (Closed Subscriber Group) cells be installed in shopping malls, apartment buildings, schools, companies, etc. For example, a CSG cell is installed for each store in a shopping mall, 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.

[0133] HeNB / HNBs are required not only to complement communications outside the coverage of a macro cell (area complementing HeNB / HNB), but also to support the various services mentioned above (service providing HeNB / HNB). For this reason, there are cases where HeNB / HNBs are installed within the coverage of a macro cell.

[0134] The problem to be solved in the first embodiment will be explained again below. In the MTC and the like, a measure has been disclosed to lengthen the cycles of periodically executed LAU (Location Area Update) processing, RAU (Routing Area Update) processing, and TAU (Tracking Area Update) processing in order to reduce power consumption (see Non-Patent Document 11, Chapter 6.20).

[0135] FIG. 13 is a diagram showing an example of a sequence of TAU processing that is periodically executed in an LTE communication system (see Non-Patent Document 13).

[0136] In Step ST1301, the UE notifies the MME of a TAU request message via the eNB. Specifically, the UE notifies the MME of the TAU request message using the NAS (Non-Access-Stratum) protocol (see Non-Patent Document 14).

[0137] In Step ST1302, the MME performs processing for authentication and security control of the UE using information of a Home Subscriber Server (HSS).

[0138] When the MME that has received the TAU request message from the UE in Step ST1301 permits the TAU request, the MME notifies the UE of a TAU accept message via the eNB in ​​Step ST1303. Specifically, the MME notifies the UE of the TAU accept message using the NAS (Non-Access-Stratum) protocol (see Non-Patent Document 14).

[0139] In Step ST1304, the UE that has received the TAU accept message from the MME in Step ST1303 notifies the MME of a TAU complete message via the eNB. Specifically, the UE notifies the MME of the TAU complete message using the NAS (Non-Access-Stratum) protocol (see Non-Patent Document 14).

[0140] The above-described processes of steps ST1301 to ST1304 are collectively referred to as step ST1305, and the process of step ST1305 is referred to as TAU procedure.

[0141] For example, the case where TAU is executed for each set cycle of a periodic TAU timer will be described as follows: The cycle of the TAU to be executed periodically is set in the periodic TAU timer.

[0142] When the TAU period 1306 of the periodic TAU timer expires, the TAU procedure is executed in step ST1307. In step ST1307, the same processing as that in steps ST1301 to ST1304 described above is executed.

[0143] Furthermore, when the TAU period 1308 of the periodic TAU timer expires, the TAU procedure is executed in step ST1309. In step ST1309, the same processing as the processing in steps ST1301 to ST1304 described above is executed.

[0144] Similarly, when a TAU period 1310 of a periodic TAU timer expires, a TAU procedure is executed in step ST1311. When a TAU period 1312 of a periodic TAU timer expires, a TAU procedure is executed in step ST1313. When a TAU period 1314 of a periodic TAU timer expires, a TAU procedure is executed in step ST1315.

[0145] Next, a case where a measure is taken to lengthen the period of TAU, which is periodically executed, in order to reduce power consumption of MTC and the like will be described.

[0146] For example, the case where TAU is executed for each set period of a long periodic TAU timer will be described as follows. The long periodic TAU timer is set with a period for TAU to be executed periodically. The TAU period set in the long periodic TAU timer is longer than the TAU period set in the periodic TAU timer described above.

[0147] When the TAU period 1316 of the long periodic TAU timer expires, a TAU procedure is executed in step ST1315. In step ST1315, the same processing as the processing in steps ST1301 to ST1304 described above is executed.

[0148] In this way, by lengthening the cycle of the LAU procedure, RAU procedure, and TAU procedure that are periodically executed, it is possible to omit, for example, the TAU procedure in steps ST1307, ST1309, ST1311, and ST1313 in Fig. 13. This makes it possible to reduce the power consumption of MTC, etc.

[0149] However, if the LAU procedure, RAU procedure, and TAU procedure that are periodically performed are lengthened, the network-based monitoring or mobility monitoring process that is performed in the TAU procedure of, for example, step ST1307, step ST1309, step ST1311, and step ST1313 in Fig. 13 will not be performed. Therefore, there is a problem that this has an adverse effect from the viewpoint of monitoring and mobility monitoring.

[0150] The solution in the first embodiment is as follows: A UE monitoring message is provided between the UE and the eNB. The UE periodically transmits the UE monitoring message to the eNB. If the eNB receives the UE monitoring message from the UE within the period, it determines that the UE is detected. If the eNB does not receive the UE monitoring message from the UE within the period, it determines that the UE is not detected. By using the UE monitoring message in this way, it becomes possible to perform monitoring at the required frequency even if the TAU processing period is lengthened.

[0151] In the following description, the period at which the UE transmits a UE monitoring message to the eNB may be referred to as a "UE monitoring period."

[0152] Alternatively, the UE may transmit a UE monitoring message after or when a timer expires. This timer may be referred to as a "UE monitoring timer."

[0153] The following description will be mainly based on the UE monitoring period, but the UE monitoring timer can also be used.

[0154] When the eNB receives a UE monitoring message transmitted from the UE, the eNB may transmit acknowledgement information to the UE. Alternatively, when the eNB receives a UE monitoring message from the UE within a period, the eNB may transmit acknowledgement information to the UE. A specific example of the acknowledgement information is a response message (ACK) in the RLC layer. The acknowledgement information may be a status PDU.

[0155] The eNB may use the UE monitoring message to determine whether a UE is present (hereinafter, also referred to as "non-detection determination"). If the eNB determines that a UE is not present, i.e., that a UE is not detected, the eNB may perform non-detection processing.

[0156] As specific examples of non-detection determination, the following seven items (1) to (7) are disclosed. (1) If the eNB does not receive a UE monitoring message within the period, it determines that the UE is not detected. If the eNB receives a UE monitoring message within the period, it determines that the UE is present, i.e., that the UE is detected.

[0157] (2) If the eNB does not receive a UE monitoring message within a period for a predetermined number of consecutive times, the eNB determines that the UE has not been detected. The predetermined number of times may be determined statically or semi-statically. When the predetermined number of times is determined semi-statically, the eNB may notify the UE of the predetermined number of times from or via the eNB.

[0158] As specific examples of the method of notifying a predetermined number of times, the following four methods (2-1) to (2-4) are disclosed. (2-1) Notify by notification information. (2-2) Notification will be made by individual information. (2-3) Notification is made by TAU processing. Specifically, notification is made by a TAU Accept message or the like. (2-4) Notification is made through the attach process, specifically, through an attach accept, an RRC connection reconfiguration message, or the like.

[0159] (3) If the eNB does not receive a UE monitoring message within a predetermined period, the eNB determines that the UE has not been detected. The predetermined period may be longer than the cycle at which the UE transmits the UE monitoring message. The predetermined period may be determined statically or semi-statically. When the predetermined period is determined semi-statically, the eNB may notify the UE of the predetermined period from or via the eNB. A specific example of a method for notifying the predetermined period is the same as the method for notifying the predetermined number of times in the specific example (2) of non-detection determination, and therefore a description thereof will be omitted.

[0160] (4) Periodic LAU processing, RAU processing, and TAU processing may be used in combination. If the eNB receives a UE monitoring message within the period, it determines that a UE has been detected. If the eNB does not receive a UE monitoring message within the period, it notifies the MME. If the TAU processing is performed within the period, the MME determines that a UE has been detected. If the TAU processing is not performed within the period, the MME determines that a UE has not been detected. This allows the MME to handle the situation appropriately even if the reason the eNB does not receive a UE monitoring message is because the UE has moved out of the coverage area of ​​the eNB. In other words, the MME can appropriately determine that a UE has been detected.

[0161] (5) If the eNB does not receive the UE monitoring message within the period, the eNB may transmit a notification to that effect (hereinafter, this may be referred to as a "UE monitoring message parameter notification") to the neighboring eNB. The UE monitoring message parameter notification may be transmitted to the neighboring eNB using the X2 interface or the S1 interface.

[0162] A neighboring eNB that receives a UE monitoring message parameter notification starts receiving a UE monitoring message from the UE. A neighboring eNB that receives a UE monitoring message from a UE notifies the eNB that sent the UE monitoring message parameter notification that it has received the UE monitoring message. A neighboring eNB that does not receive a UE monitoring message from the UE notifies the eNB that sent the UE monitoring message parameter notification that it will not receive the UE monitoring message.

[0163] An eNB determines that a UE has been detected when it receives a notification from a neighboring eNB that a UE monitoring message has been received. Also, an eNB determines that a UE has not been detected when it receives a notification from a neighboring eNB that a UE monitoring message has not been received, or when it does not receive a UE monitoring message from a neighboring eNB.

[0164] As specific examples of a method for transmitting a UE monitoring message parameter notification, the following two methods (5-1) and (5-2) are disclosed. (5-1) Create a new X2 signal or X2 message, or create a new S1 signal or S1 message. (5-2) Use an existing X2 signal or X2 message. Alternatively, provide an existing S1 signal or S1 message. This specific example (5-2) is effective compared to specific example (5-1) in that it does not require the provision of a new signal. This specific example (5-2) can avoid the communication system from becoming complicated.

[0165] As specific examples of parameters that are mapped to the X2 signal or the S1 signal, the following four (5-a) to (5-d) are disclosed. (5-a) The identification number of the mobile terminal (UE-ID, etc.). (5-b) The mobile terminal is a UE that transmits a UE monitoring message to the eNB. The mobile terminal may be an MTC. (5-c) UE monitoring period. (5-d) A combination of (5-a) to (5-c).

[0166] According to this specific example (5), even if the reason why the eNB does not receive the UE monitoring message is that the UE has moved out of the coverage area of ​​the eNB, the UE can be properly detected. In addition, it is possible to obtain an effect that the UE can continue to transmit the UE monitoring message at the destination eNB under the same conditions, for example, the same period. Furthermore, it is possible to obtain an effect that the UE can continue to transmit the UE monitoring message without newly exchanging parameters between the destination eNB and the UE, thereby preventing a control delay.

[0167] (6) After determining that the UE is not detected in steps (1) to (5), a paging message is sent to the UE. If there is a response from the UE, it is determined that the UE is detected. If there is no response from the UE, it is determined that the UE is not detected. (7) A combination of (1) to (6) above.

[0168] As specific examples of non-detection processing, the following three (1) to (3) are disclosed. (1) The eNB notifies a predetermined notification destination that the UE has not been detected. Specific examples of the predetermined notification destination include an OAM (Operation, Administration, and Maintenance) server, an application server, and an MTC server. (2) Detach processing is started. The detach processing is used as a trigger. (3) A combination of (1) and (2) above.

[0169] The following four (1) to (4) are disclosed as specific examples of purposes for which a UE notifies an eNB of a UE monitoring message. (1) To let the other person know that you are alive. To keep them alive. (2) To let others know that you exist. (3) To let you know that it's not down and that it's working properly. (4) A combination of (1) to (3) above.

[0170] As specific examples of UE monitoring messages, the following four (1) to (4) are disclosed. (1) A message is sent only at the Uu point. The Uu point is the interface point between the UE and eNB, the UE and HeNB, or the UE and RN. In this specific example (1), the TAU is notified from the UE to the MME, and therefore is a message related to the Uu point and the S1 point (see steps ST1301, ST1302, ST1303, and ST1304 in FIG. 13). This specific example (1) shortens the communication time between the UE and eNB, enabling low power consumption by the UE.

[0171] (2) The message does not need to be notified to a higher-level device of the eNB. Specific examples of higher-level devices include the MME and HSS. In this specific example (2), unlike a UE monitoring message, the TAU is a message that needs to be notified to the MME and HSS (see step ST1301 and step ST1302 in FIG. 13). This specific example (2) shortens the communication time between the UE and the eNB, enabling low power consumption of the UE.

[0172] (3) RRC Message In this specific example (3), unlike the UE monitoring message, the TAU is an NAS message. (4) A combination of (1) to (3) above.

[0173] As specific examples of when the UE monitoring message is an RRC message, the following two examples (1) and (2) are disclosed. (1) A new RRC signal or RRC message is established. (2) Existing RRC signals or RRC messages are used. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of new signals. This specific example (2) can avoid the communication system from becoming complicated.

[0174] The following four (1) to (4) are disclosed as specific examples of parameters to be newly mapped to RRC signals. (1) Messages indicating that the UE is for monitoring, that it is "alive," that it is a keep-alive, that it exists, that it is not down, that it is operating normally, etc.

[0175] (2) UE Identifier The UE identifier may be a mobile terminal identifier (UE-ID) or an international mobile subscriber identity (IMSI).

[0176] (3) Sequence number. The sequence number may be incremented for each transmission. It may also be used as a sequence number for strengthening security measures. Even if the encryption key is obtained, if the sequence number is not correct, the message cannot be decrypted, thereby strengthening security measures. Furthermore, if the sequence number is initialized in a TAU process or the like, it is possible to prevent the number of bits required to transmit the sequence number from becoming too large. (4) A combination of (1) to (3) above.

[0177] Next, a specific example of using existing RRC signals will be disclosed, in which a Measurement Report message is used.

[0178] Examples of parameters that need to be added to existing RRC signaling include: UE monitoring message, "alive", keep-alive, existing, not down, and operating normally.

[0179] The UE monitoring message may be transmitted as data encrypted using the encryption key agreed upon in the TAU authentication process. This allows the eNB to detect UE monitoring messages impersonating unauthorized UEs unless the encryption key and the sequence number for enhanced security measures are decrypted. The encryption key may be changed appropriately during the TAU authentication process, taking into account the communication volume and period.

[0180] Furthermore, a message authentication code may be added to perform message authentication.

[0181] When the eNB detects UE impersonation, it may execute processing in accordance with the operation policy of the service provider (hereinafter referred to as "rogue UE detection processing"). As specific examples of the fraudulent UE detection processing, the following three (1) to (3) are disclosed. (1) The eNB notifies a predetermined notification destination of the detection of the unauthorized UE. Specific examples of the predetermined notification destination include the OAM, the application server, and the MTC server. (2) Detach processing is started. The detach processing is used as a trigger. (3) A combination of (1) and (2) above.

[0182] As specific examples of methods for setting the UE monitoring period, the following four methods (1) to (4) are disclosed. (1) Notification by broadcast information According to this specific example (1), there is no need to notify each UE, and therefore it is possible to obtain the effect of making effective use of radio resources. (2) Notification by individual information This specific example (2) allows the setting value to be determined for each UE, making it possible to build a flexible communication system. (3) Notification is made by TAU processing, specifically, by a TAU Accept message or the like. (4) Notification is made by the attach process, specifically, by an attach accept message or an RRC connection reconfiguration.

[0183] The following two examples (1) and (2) are disclosed as specific examples of operations when the UE monitoring period and the period of the periodically executed TAU expire at the same time. (1) Execute both the UE monitoring process and the TAU process. This specific example (1) allows the process to be determined for each period, thereby achieving the effect of avoiding the complexity of control.

[0184] (2) The TAU process may be performed without performing the UE monitoring process. According to this specific example (2), the UE does not need to transmit a UE monitoring message. Since the network side can monitor the UE by the TAU process, omitting the transmission of the UE monitoring message can provide the effect of reducing the power consumption of the UE.

[0185] A specific example of the setting values ​​of the UE monitoring period and the period of the periodically executed TAU is a value set in a periodic TAU timer.

[0186] The period of the periodically executed TAU may be an integer multiple of the UE monitoring period, or an inverse multiple of the integer (1 / integer multiple). This increases the chances that the UE monitoring period and the periodically executed TAU period expire simultaneously, making it easier to achieve the effect of reducing the power consumption of the UE.

[0187] As specific examples of the setting value of the UE monitoring period, the following four (1) to (4) are disclosed. (1) Number of radio frames. (2) Number of subframes. (3) When the UE monitoring period is set to an integer multiple of the period of the periodically executed TAU, or an inverse multiple of the integer (1 / integer multiple), the "integer" is set as the setting value of the UE monitoring period. (4) A combination of (1) to (3) above.

[0188] Next, a specific example of a sequence of the communication system in the first embodiment will be described with reference to Fig. 14. Fig. 14 is a diagram showing an example of a sequence of the communication system in the first embodiment. Fig. 14 shows a sequence in the case where a UE transmits a UE monitoring message for each UE monitoring period. Since the sequence shown in Fig. 14 is similar to the sequence shown in Fig. 13, the same step numbers are assigned to the same steps, and common explanations will be omitted.

[0189] In step ST1414, the TAU procedure is executed in the same manner as in step ST1305 described above.

[0190] In Step ST1402, the UE notifies the eNB of a UE monitoring message in a UE monitoring period 1401.

[0191] In Step ST1403, the eNB that has received the UE monitoring message transmits acknowledgement information to the UE.

[0192] The processes of steps ST1402 and ST1403 are collectively referred to as step ST1404, and the process of step ST1404 is referred to as UE monitoring process.

[0193] In Step ST1406, a UE monitoring process is performed between the UE and the eNB in ​​a UE monitoring period 1405.

[0194] In addition, in step ST1408, a UE monitoring process is performed between the UE and the eNB in ​​a UE monitoring period 1407.

[0195] Also, in step ST1410, a UE monitoring process is performed between the UE and the eNB in ​​a UE monitoring period 1409.

[0196] If the UE monitoring period 1411 and the period 1412 of the periodically executed TAU occur simultaneously, the TAU procedure is executed in step ST1413.

[0197] The above-described first embodiment can provide the following effects: By providing a new UE monitoring process, monitoring by the UE monitoring process becomes possible even if the period of the periodic TAU process is lengthened.

[0198] By configuring the UE monitoring process to consume less power than the TAU process, it is possible to obtain the effect of reducing power consumption.

[0199] The UE monitoring period and the TAU period can be set separately, which has the effect of enabling flexible operation of TAU processing.

[0200] As a result, it is possible to reduce the power consumption of communication terminal devices and to appropriately realize network-based monitoring and mobility surveillance.

[0201] Therefore, according to the communication system of this embodiment, it is possible to check the state of the UE while reducing the processing load and power consumption.

[0202] In this embodiment, the UE monitoring message is transmitted from the UE to the eNB, and the eNB determines the state of the UE based on whether or not it has received the UE monitoring message from the UE. This makes it possible to realize a communication system that can check the state of the UE while reducing the processing load and power consumption, as described above.

[0203] First embodiment, variant 1 Variation 1 of Embodiment 1 shows further improvements to the above-described Embodiment 1. In this variation, differences from the solution of the above-described Embodiment 1 will be mainly explained, and parts that are not explained will be the same as in Embodiment 1.

[0204] When the eNB receives a UE monitoring message from the UE, the eNB transmits a response message to the UE monitoring message to the UE. In this first modification, the response message may be ciphered. Compared to the delivery confirmation information of the first embodiment which is a simple confirmation message, for example, ACK information, in this first modification, an encrypted response message to the UE monitoring message is transmitted, making it possible to detect eNB spoofing by the UE.

[0205] The response message to the UE monitoring message may be an RRC message. The following two examples (1) and (2) are disclosed as specific examples of when the response message to the UE monitoring message is an RRC message. (1) A new RRC signal or RRC message is established. (2) Existing RRC signals or RRC messages are used. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of new signals. This specific example (2) can avoid the communication system from becoming complicated.

[0206] The following four (1) to (4) are disclosed as specific examples of parameters to be newly mapped to RRC signals. (1) Indicates that this is a response message to a UE monitoring message. (2) Cell identifier, which may be PCI, CGI, or ECGI.

[0207] (3) Sequence number. The sequence number may be incremented for each transmission. It may also be used as a sequence number for strengthening security measures. Even if the encryption key is obtained, if the sequence number is not correct, the message cannot be decrypted, thereby strengthening security measures. Furthermore, if the sequence number is initialized in a TAU process or the like, it is possible to prevent the number of bits required to transmit the sequence number from becoming too large. (4) A combination of (1) to (3) above.

[0208] Next, a specific example of using existing RRC signals will be disclosed. An RRC connection reconfiguration message is used.

[0209] A specific example of a parameter that needs to be added to the existing RRC signaling is a message indicating that the message is a response message to a UE monitoring message. The message indicating that the message is a response message to a UE monitoring message may be notified by being included in a "cause" parameter set in the existing RRC signaling.

[0210] A response message to a UE monitoring message may be transmitted as data encrypted using an encryption key agreed upon in the TAU authentication process. This allows the UE to detect a response message to a UE monitoring message sent by a fraudulent eNB, unless the encryption key and the sequence number for enhanced security measures are decrypted. The encryption key may be changed appropriately during the TAU authentication process, taking into account the communication volume and period.

[0211] Furthermore, a message authentication code may be added to perform message authentication.

[0212] When the UE detects that an eNB is spoofing, it may execute a process in accordance with the operation policy of the service provider (hereinafter referred to as "rogue eNB detection process"). A specific example of the rogue eNB detection process is deleting internal information.

[0213] Next, a specific example of a sequence of the communication system according to the first modification of the first embodiment will be described with reference to FIG.

[0214] In Step ST1403, the eNB that has received the UE monitoring message in Step ST1402 transmits a response message to the UE monitoring message to the UE.

[0215] In addition to the effects of the first embodiment, the first modification of the first embodiment described above can provide the following effects: It becomes possible to detect UE masquerading as an eNB.

[0216] Embodiment 1 Variation 2 In Variation 2 of Embodiment 1, a different solution to the same problem as in the above-described Embodiment 1 is disclosed. The solution in Variation 2 of Embodiment 1 is shown below. In this variation, the explanation will focus on the parts that are different from the solution in the above-described Embodiment 1, and the parts that are not explained will be the same as in Embodiment 1.

[0217] In this modification, a UE monitoring message is provided between the UE and the eNB. The eNB periodically transmits the UE monitoring message to the UE. When the UE receives the UE monitoring message, it notifies the eNB of delivery confirmation information. When the eNB receives the delivery confirmation information, it determines that the UE is detected. When the eNB does not receive the delivery confirmation information, it determines that the UE is not detected. By using the UE monitoring message in this way, even when the TAU process is performed at a long cycle, it is possible to perform monitoring at the required frequency.

[0218] In the following description, the period at which the eNB transmits a UE monitoring message to the UE may be referred to as a "UE monitoring period."

[0219] Alternatively, the eNB may transmit a UE monitoring message after or when the timer expires. This timer may also be referred to as a "UE monitoring timer."

[0220] The following description will be mainly based on the UE monitoring period, but the UE monitoring timer can also be used.

[0221] A specific example of the acknowledgement information is a response message (ACK) in the RLC layer, or a status PDU.

[0222] The eNB may use the delivery confirmation information for the UE monitoring message to determine whether or not a UE is present (hereinafter, also referred to as "non-detection determination"). If the eNB determines that a UE is not present, i.e., that a UE is not detected, the eNB may perform non-detection processing.

[0223] As specific examples of non-detection determination, the following six examples (1) to (6) are disclosed. (1) If the eNB does not receive the acknowledgement information within the period, it determines that the UE is not detected. If the eNB receives the acknowledgement information within the period, it determines that the UE is present, i.e., that the UE is detected.

[0224] (2) If the eNB does not receive the acknowledgement information within the period for a predetermined number of consecutive times, the eNB determines that the UE has not been detected. The predetermined number of times may be determined statically or semi-statically. When the predetermined number of times is determined semi-statically, the eNB may notify the UE of the predetermined number of times from or via the eNB.

[0225] As specific examples of the method of notifying a predetermined number of times, the following four methods (2-1) to (2-4) are disclosed. (2-1) Notify by notification information. (2-2) Notification will be made by individual information. (2-3) Notification is made by TAU processing. Specifically, notification is made by a TAU Accept message or the like. (2-4) Notification is made through the attach process, specifically, through an attach accept message, an RRC connection reconfiguration message, or the like.

[0226] (3) If the eNB does not receive the delivery confirmation information within a predetermined period, the eNB determines that the UE has not been detected. The predetermined period may be longer than the cycle at which the UE transmits a UE monitoring message. The predetermined period may be determined statically or semi-statically. When the predetermined period is determined semi-statically, the eNB may notify the UE of the predetermined period from or via the eNB. A specific example of a method for notifying the predetermined period is the same as the method for notifying the predetermined number of times in the specific example (2) of non-detection determination, and therefore a description thereof will be omitted.

[0227] (4) Periodic LAU processing, RAU processing, and TAU processing may be used in combination. If the eNB receives acknowledgement information within the period, it determines that a UE has been detected. If the eNB does not receive acknowledgement information within the period, it notifies the MME. If the TAU processing is performed within the period, the MME determines that a UE has been detected. If the TAU processing is not performed within the period, the MME determines that a UE has not been detected. This allows the MME to handle the situation appropriately even if the reason the eNB does not receive a UE monitoring message is because the UE has moved out of the coverage area of ​​the eNB. In other words, the MME can appropriately determine that a UE has been detected.

[0228] (5) After determining that the UE is not detected in steps (1) to (4), a paging message is sent to the UE. If there is a response from the UE, it is determined that the UE is detected. If there is no response from the UE, it is determined that the UE is not detected. (6) A combination of (1) to (5) above.

[0229] A specific example of the non-detection process is the same as that in the first embodiment, and therefore a description thereof will be omitted.

[0230] Furthermore, if the UE does not receive a UE monitoring message within the period, the UE may notify the eNB of this fact, which allows the eNB or the network side to detect an abnormality.

[0231] The following four (1) to (4) are disclosed as specific examples of purposes for which the eNB notifies the UE of a UE monitoring message. (1) Inquiry about "being alive." (2) Querying the presence of a UE. (3) Inquiry that the UE is operating normally. (4) A combination of (1) to (3) above.

[0232] As specific examples of UE monitoring messages, the following three (1) to (3) are disclosed. (1) Messages are limited to the Uu point. The Uu point is the interface point between the UE and eNB, the UE and HeNB, or the UE and RN. (2) RRC message In this specific example (2), unlike the UE monitoring message, the TAU is an NAS message. (3) A combination of (1) and (2) above.

[0233] As specific examples of when the UE monitoring message is an RRC message, the following two examples (1) and (2) are disclosed. (1) A new RRC signal or RRC message is established. (2) Existing RRC signals or RRC messages are used. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of new signals. This specific example (2) can avoid the communication system from becoming complicated.

[0234] The following four (1) to (4) are disclosed as specific examples of parameters to be newly mapped to RRC signals. (1) A message indicating that the query is "alive," that the UE exists, that the UE is operating normally, etc. (2) Cell identifier, which may be PCI, CGI, or ECGI.

[0235] (3) Sequence number. The sequence number may be incremented for each transmission. It may also be used as a sequence number for strengthening security measures. Even if the encryption key is obtained, if the sequence number is not correct, the message cannot be decrypted, thereby strengthening security measures. Furthermore, if the sequence number is initialized in a TAU process or the like, it is possible to prevent the number of bits required to transmit the sequence number from becoming too large. (4) A combination of (1) to (3) above.

[0236] Next, a specific example of using existing RRC signals will be disclosed below: An RRC Connection Reconfiguration message is used.

[0237] Examples of parameters that need to be added to existing RRC signaling include an inquiry to see if the UE is alive, an inquiry to see if the UE is present, and an inquiry to see if the UE is operating normally.

[0238] The UE monitoring message may be transmitted as data encrypted using an encryption key agreed upon in the TAU authentication process. This allows the UE to detect UE monitoring messages impersonating an unauthorized eNB unless the encryption key and the sequence number for enhanced security measures are decrypted. The encryption key may be changed appropriately during the TAU authentication process, taking into account the communication volume and period.

[0239] Furthermore, a message authentication code may be added to perform message authentication.

[0240] When the UE detects that an eNB is spoofing, it may execute a fraudulent eNB detection process in accordance with the operation policy of the service provider. A specific example of the fraudulent eNB detection process is deleting internal information.

[0241] As specific examples of the setting value of the UE monitoring period, the following five (1) to (5) are disclosed. (1) Number of radio frames. (2) Number of subframes. (3) When the UE monitoring period is set to an integer multiple of the period of the periodically executed TAU, or an inverse multiple of the integer (1 / integer multiple), the "integer" is set as the setting value of the UE monitoring period.

[0242] (4) The timing is the same as the timing of receiving a paging message, or the timing of receiving a paging message is an integer multiple of the UE monitoring period or an inverse multiple of an integer (1 / integer multiple). A specific example of the case where the UE monitoring period is set to the same timing as the timing of receiving a paging message is when a paging frame (PF) or a paging occasion (PO) is used as the UE monitoring period (see Non-Patent Document 3). This eliminates the need to set a new UE monitoring period, and has the effect of enabling effective use of radio resources. Furthermore, the UE can synchronize its reception timing of the paging message with that of the UE monitoring message, thereby reducing the number of times the UE powers on its receiving circuit. This reduces the power consumption of the UE. (5) A combination of (1) to (4) above.

[0243] Next, a specific example of a sequence of a communication system in Modification 2 of Embodiment 1 will be described with reference to Fig. 15. Fig. 15 is a diagram showing an example of a sequence of a communication system in Modification 2 of Embodiment 1. Fig. 15 shows a sequence in the case where an eNB transmits a UE monitoring message for each UE monitoring period. Since the sequence shown in Fig. 15 is similar to the sequence shown in Fig. 13, the same step numbers are assigned to the same steps, and common explanations will be omitted.

[0244] In Step ST1502, the eNB notifies the UE of a UE monitoring message in a UE monitoring period 1501.

[0245] In Step ST1503, the UE that has received the UE monitoring message transmits acknowledgement information to the eNB.

[0246] The processes of steps ST1502 and ST1503 are collectively referred to as step ST1504, and the process of step ST1504 is referred to as UE monitoring process.

[0247] In Step ST1506, a UE monitoring process is performed between the UE and the eNB in ​​a UE monitoring period 1505.

[0248] Also, in step ST1508, a UE monitoring process is performed between the UE and the eNB in ​​a UE monitoring period 1507.

[0249] Also, in step ST1510, a UE monitoring process is performed between the UE and the eNB in ​​a UE monitoring period 1509.

[0250] If the UE monitoring period 1511 and the TAU period 1512 that is periodically executed occur simultaneously, the TAU procedure is executed in step ST1513.

[0251] The second modification of the first embodiment described above can provide the same effects as those of the first embodiment.

[0252] First embodiment, variant 3 Variation 3 of Embodiment 1 shows further improvements to the solution of Variation 2 of Embodiment 1 described above. In this variation, differences from the solution of Variation 2 of Embodiment 1 described above will be mainly explained, and parts that are not explained will be the same as Variation 2 of Embodiment 1.

[0253] When the UE receives a UE monitoring message from the eNB, the UE transmits a response message to the UE monitoring message to the eNB. In this modification, the response message may be ciphered. While the delivery confirmation information in the second modification of the first embodiment is a simple confirmation message, such as ACK information, in the third modification, a response message to the UE monitoring message is transmitted, making it possible to detect UE impersonation by the eNB.

[0254] The response message to the UE monitoring message may be an RRC message. The following two examples (1) and (2) are disclosed as specific examples of when the response message to the UE monitoring message is an RRC message. (1) A new RRC signal or RRC message is established. (2) Existing RRC signals or RRC messages are used. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of new signals. This specific example (2) can avoid the communication system from becoming complicated.

[0255] The following four (1) to (4) are disclosed as specific examples of parameters to be newly mapped to RRC signals. (1) Indicates that this is a response message to a UE monitoring message. (2) UE identifier, which may be specifically UE-ID or IMSI. (3) Sequence number. The sequence number may be incremented for each transmission. It may also be used as a sequence number for strengthening security measures. Even if the encryption key is obtained, if the sequence number is not correct, the message cannot be decrypted, thereby strengthening security measures. Furthermore, if the sequence number is initialized in a TAU process or the like, it is possible to prevent the number of bits required to transmit the sequence number from becoming too large. (4) A combination of (1) to (3) above.

[0256] Next, a specific example of using existing RRC signals will be disclosed: An RRC Connection Reconfiguration Complete message is used.

[0257] A specific example of a parameter that needs to be added to the existing RRC signaling is a message indicating that the message is a response message to a UE monitoring message. The message indicating that the message is a response message to a UE monitoring message may be notified by being included in the "Establishment Cause" parameter set in the existing RRC signaling.

[0258] A response message to a UE monitoring message may be transmitted as data encrypted using an encryption key agreed upon in the TAU authentication process. This allows the eNB to detect a response message to a UE monitoring message impersonated by an unauthorized UE, unless the encryption key and the sequence number for enhanced security measures are decrypted. The encryption key may be changed appropriately during the TAU authentication process, taking into account the communication volume and period.

[0259] Furthermore, a message authentication code may be added to perform message authentication.

[0260] When the eNB detects spoofing of a UE, it may execute a fraudulent UE detection process in accordance with the operation policy of the service provider. A specific example of the fraudulent UE detection process is the same as that in the first embodiment, and therefore a description thereof will be omitted.

[0261] Next, a specific example of a sequence of the communication system according to the third modification of the first embodiment will be described with reference to FIG.

[0262] In Step ST1503, the UE that has received the UE monitoring message transmits a response message to the UE monitoring message to the eNB.

[0263] In addition to the effects of Modification 2 of Embodiment 1, the above-described Modification 3 of Embodiment 1 can provide the following effects: It becomes possible to detect UE spoofing by an eNB.

[0264] First embodiment, variant 4 In the fourth modification of the first embodiment, a different solution to the same problem as in the first embodiment will be disclosed. The solution in the fourth modification of the first embodiment will be described below.

[0265] In this modification, the UE periodically transmits UE monitoring messages to the eNB without establishing an RRC connection. In other words, the UE periodically transmits UE monitoring messages to the eNB in ​​an RRC idle state (RRC_Idle). This eliminates the need for procedures to establish and release an RRC connection, resulting in the effects of reducing the power consumption of the UE and enabling effective use of radio resources.

[0266] A specific example of a method for transmitting a UE monitoring message without establishing an RRC connection is a method for transmitting a UE monitoring message during a random access process. This method does not require the establishment of a new process, and therefore has the effect of avoiding the complexity of the communication system.

[0267] The existing random access process will be described with reference to Fig. 16 (see Non-Patent Document 1). Fig. 16 is a diagram showing an example of the sequence of the random access process.

[0268] In Step ST1601, the UE transmits a random access preamble to the eNB.

[0269] In Step ST1602, the eNB transmits a random access response to the UE. The random access radio network temporary identity (RA-RNTI) on the PDCCH is addressed. Timing alignment (TA), an initial uplink grant, and allocation of a cell radio network temporary identity (C-RNTI) are performed via the DL-SCH.

[0270] In Step ST1603, the UE transmits a scheduled transmission to the eNB. Initial access is performed. An RRC connection request is transmitted by the RRC layer. The C-RNTI of the UE is notified.

[0271] In Step ST1604, the eNB transmits a contention resolution to the UE, in which the C-RNTI on the PDCCH is addressed for the UE in the RRC connection.

[0272] The following two methods (1) and (2) are disclosed as specific examples of methods for transmitting a UE monitoring message during RACH processing. (1) A random access preamble is used. Examples of parameters that need to be added include: indicating that the message is for UE monitoring, indicating that the device is "alive," indicating that the device is a keep-alive, indicating that the device exists, that the device is not down, and indicating that the device is operating normally.

[0273] (2) A scheduled transmission message is used. More specifically, an RRC connection request message (see Non-Patent Document 2) is used. Specific examples of parameters that need to be added include: a message for UE monitoring; an "alive" message; a keep-alive message; a message that exists; a message that is not down; a message that is operating normally; etc. These may be notified by being included in the "establishment cause" parameter set in the message.

[0274] The following two methods (1) and (2) are disclosed as specific examples of methods for transmitting a response message to a UE monitoring message during RACH processing. (1) A random access response is used. A specific example of a parameter that needs to be added is a message indicating that the message is a response to a UE monitoring message. (2) A Contention Resolution message is used. More specifically, an RRC Connection Setup message is used. A specific example of a parameter that needs to be added is a message indicating that the message is a response to a UE monitoring message.

[0275] Next, a specific example of a sequence of a communication system in Modification 4 of Embodiment 1 will be described with reference to Fig. 17. Fig. 17 is a diagram showing an example of a sequence of a communication system in Modification 4 of Embodiment 1. Fig. 17 shows a sequence when a UE monitoring message is notified using a random access preamble. The sequence shown in Fig. 17 is similar to the sequence shown in Fig. 16, and therefore the same steps are assigned the same step numbers and common explanations will be omitted.

[0276] In Step ST1701, the UE transmits a UE monitoring message to the eNB by using a random access preamble.

[0277] In Step ST1702, the eNB judges whether or not the random access preamble received in Step ST1701 notifies a UE monitoring message. If it is judged in Step ST1702 that the random access preamble notifies a UE monitoring message, it proceeds to Step ST1703, and if it is judged that the random access preamble does not notify a UE monitoring message, it proceeds to Step ST1602.

[0278] Specifically, if the random access preamble does not include information indicating that it is a UE monitoring message, it is determined that the UE monitoring message is not to be notified, and the process proceeds to step ST1602. In other words, it proceeds to normal random access processing. On the other hand, if the random access preamble includes information indicating that it is a UE monitoring message, it is determined that the UE monitoring message is to be notified, and the process proceeds to step ST1703.

[0279] In Step ST1703, the eNB transmits acknowledgement information for the UE monitoring message to the UE. A specific example of the acknowledgement information is a response message in the RLC layer. The acknowledgement information may be a status PDU. The acknowledgement information for the UE monitoring message may be transmitted using a random access response. Thereafter, the processing ends. In other words, the processing for RRC connection performed in Steps ST1602 and ST1604, etc. is not performed.

[0280] Next, a specific example of a sequence of a communication system in Modification 4 of Embodiment 1 will be described with reference to Fig. 18. Fig. 18 is a diagram showing another example of a sequence of a communication system in Modification 4 of Embodiment 1. Fig. 18 shows a sequence in the case where a UE monitoring message is notified using an RRC connection request. The sequence shown in Fig. 18 is similar to the sequences shown in Figs. 16 and 17, so the same step numbers are assigned to the same steps and common descriptions will be omitted.

[0281] In Step ST1801, the UE transmits a UE monitoring message to the eNB by using an RRC connection request.

[0282] In Step ST1802, the eNB judges whether or not the RRC connection request received in Step ST1801 notifies a UE monitoring message. If it is judged in Step ST1802 that the RRC connection request notifies a UE monitoring message, the eNB moves to Step ST1803, and if it is judged that the RRC connection request notifies a UE monitoring message, the eNB moves to Step ST1804.

[0283] Specifically, if the RRC connection request does not include information indicating that it is a UE monitoring message, it is determined that the UE monitoring message is not to be notified, and the process proceeds to step ST1604. In other words, the process proceeds to normal random access processing. On the other hand, if the RRC connection request includes information indicating that it is a UE monitoring message, it is determined that the UE monitoring message is to be notified, and the process proceeds to step ST1803.

[0284] In Step ST1803, the eNB transmits a response message to the UE monitoring message to the UE. The response message to the UE monitoring message may be transmitted by using an RRC connection setup. After that, the processing ends. In other words, the processing for RRC connection performed in Step ST1604 and the like is not performed.

[0285] There is an existing message indicating an MME overload that can be sent from the MME to the eNB. This message is an "Overload START" message on the S1 interface (see 3GPP TS36.413 V10.4.0). The action that the MME requests the eNB that has received the "Overload START" message to take is notified as an "Overload Action" information element of the "Overload START" message (see 3GPP TS36.413 V10.4.0). The "Overload Action" mainly specifies that an RRC connection be rejected in response to an RRC connection request.

[0286] In other words, in the existing technology, the MME cannot prohibit a message notification from a UE to an eNB using this modification in which a message is notified to the eNB without establishing an RRC connection with the eNB. This becomes a problem when the MME is overloaded.

[0287] As a solution to the above problem, a parameter that prohibits message notification without establishing an RRC connection is added to "Overload Action." This makes it possible to prohibit message notification without establishing an RRC connection when the MME is overloaded.

[0288] The fourth modification of the first embodiment can be used in combination with the first embodiment or the first modification of the first embodiment described above.

[0289] In addition to the effects of the first embodiment, the fourth modification of the first embodiment described above can provide the following effects: The procedures for establishing and releasing an RRC connection are no longer necessary, which can reduce the power consumption of the UE, and radio resources can be used effectively.

[0290] Embodiment 1 Variation 5 Variation 5 of Embodiment 1 discloses a different solution to the same problem as in the above-described Embodiment 1. The solution in Variation 5 of Embodiment 1 is described below.

[0291] In this modification, the eNB periodically transmits a UE monitoring message to the UE without establishing an RRC connection. In other words, the eNB periodically transmits a UE monitoring message to the UE in an RRC idle state (RRC_Idle). This eliminates the need for procedures to establish and release an RRC connection, resulting in the effects of reducing the power consumption of the UE and enabling effective use of radio resources.

[0292] A specific example of a method for transmitting a UE monitoring message without establishing an RRC connection is a method for transmitting a UE monitoring message during a paging process. This method does not require the establishment of a new process, and therefore has the effect of avoiding the complexity of the communication system.

[0293] Existing paging processing will be described with reference to Figures 19 and 20 (see Non-Patent Document 2). Figures 19 and 20 are diagrams showing an example of a paging processing sequence in an LTE communication system. Figures 19 and 20 are connected at the position of boundary line BL1.

[0294] In Step ST1901, the MME transmits a paging message addressed to the UE to an eNB that belongs to the tracking area in which the UE is located.

[0295] In Step ST1902, the eNB transmits the paging message received in Step ST1901 to the UEs within its coverage area.

[0296] In Step ST1903, the UE judges whether or not it is time to receive a paging message. If it is judged in Step ST1903 that it is time to receive a paging message, it proceeds to Step ST1904, and if it is judged that it is not time to receive a paging message, it repeats the processing of Step ST1903.

[0297] In Step ST1904, the UE receives the PDCCH at the timing of receiving the paging message, and determines whether or not a paging-radio network temporary identity (P-RNTI) is present in the PDCCH. In other words, the UE determines whether or not the P-RNTI is addressed. If it is determined in Step ST1904 that the PDCCH has a P-RNTI, the UE proceeds to Step ST1905, and if it is determined that the P-RNTI does not have a P-RNTI, the UE returns to Step ST1903.

[0298] In Step ST1905, the UE judges whether or not it is in RRC_IDLE. If it is judged in Step ST1905 that it is in RRC_IDLE, it moves to Step ST1906, and if it is judged that it is not in RRC_IDLE, it moves to Step ST1911 in FIG. 20.

[0299] In Step ST1906, the UE determines whether the UE-ID in the paging message matches its own UE-ID. The paging message is a message that is mapped to the PCCH, which is a logical channel, to the PCH, which is a transport channel, and to the PDSCH, which is a physical channel. If it is determined in Step ST1906 that the UE-ID in the paging message matches its own UE-ID, it proceeds to Step ST1907, and if it is determined that the UE-ID in the paging message does not match its own UE-ID, it proceeds to Step ST1911 in FIG. 20.

[0300] In Step ST1907, the UE transmits an RRC connection request message to the eNB.

[0301] In Step ST1908, the eNB transmits an RRC connection setup message to the UE.

[0302] In Step ST1909, the UE transmits an RRC connection setup complete message to the eNB.

[0303] In Step ST1910, the UE, eNB, and MME execute a service request process using the RRC connection established in Steps ST1907 to ST1909.

[0304] In Step ST1911, the UE judges whether or not a system information modification indicator, which is information indicating a change in system information, is present in the paging message. If it is judged in Step ST1911 that a system information modification indicator is present in the paging message, the UE proceeds to Step ST1912, and if it is judged that a system information modification indicator is not present in the paging message, the UE proceeds to Step ST1913.

[0305] In Step ST1912, the UE receives the system information and proceeds to Step ST1913.

[0306] In Step ST1913, the UE judges whether or not an ETWS indicator (Earthquake and Tsunami Warning System Indicator) is present in the paging message. If it is judged in Step ST1913 that an ETWS indicator is present in the paging message, the UE proceeds to Step ST1914, and if it is judged that an ETWS indicator is not present in the paging message, the UE proceeds to Step ST1915.

[0307] In Step ST1914, the UE receives the ETWS information. The ETWS information is mapped to specific system information. Upon receiving the ETWS information, the UE proceeds to Step ST1915.

[0308] In Step ST1915, the UE determines whether or not a CMAS indicator (Commercial Mobile Alert Service Indicator) is present in the paging message. If it is determined in Step ST1915 that a CMAS indicator is present in the paging message, the UE proceeds to Step ST1916, and if it is determined that a CMAS indicator is not present in the paging message, the UE ends the processing.

[0309] In Step ST1916, the UE receives the CMAS information. The CMAS information is mapped to specific system information. When the CMAS information is received, the process ends.

[0310] The following three methods (1) to (3) are disclosed as specific examples of methods for transmitting a UE monitoring message during a paging process. (1) A new identifier is provided in the PDCCH to notify the presence or absence of a UE monitoring message. The identifier is, for example, a Multimedia Broadcast / Multicast Service Radio Network Temporary Identity (M-RNTI). The UE receives the PDCCH at a UE monitoring period and determines whether the M-RNTI is present in the PDCCH. In other words, the UE determines whether the M-RNTI is addressed. If it is determined that the M-RNTI is present in the PDCCH, the UE determines that it has received a UE monitoring message. If it is determined that the M-RNTI is not present in the PDCCH, the UE determines that it has not received a UE monitoring message. Unlike specific examples (2) and (3) described below, this specific example (1) does not require the reception of a paging message, and therefore has the effect of preventing control delays.

[0311] (2) An indicator indicating transmission of a UE monitoring message is mapped in a paging message. The UE determines whether or not there is an indicator indicating transmission of a UE monitoring message in the paging message. If it is determined that there is an indicator indicating transmission of a UE monitoring message in the paging message, the UE determines that it has received the UE monitoring message. If it is determined that there is no indicator indicating transmission of a UE monitoring message in the paging message, the UE determines that it has not received the UE monitoring message. Unlike the specific example (1), this specific example (2) can also use P-RNTI and reduces the number of times the UE decodes the PDCCH, thereby achieving the effect of reducing the load on the UE.

[0312] (3) A UE monitoring message is mapped into a paging message. Specific examples of parameters that need to be added include an inquiry as to whether the UE is "alive," an inquiry as to whether the UE exists, an inquiry as to whether the UE is operating normally, etc. Compared to the specific example (1), the specific example (3) can use the P-RNTI in combination and reduces the number of times the UE decodes the PDCCH, thereby achieving the effect of reducing the load on the UE.

[0313] A specific example of a method for transmitting a response message to a UE monitoring message during RACH processing is a method for transmitting the response message during service request processing. An example of a parameter that needs to be added is a message indicating that the message is a response message to a UE monitoring message.

[0314] A specific example of a method for transmitting during service request processing is a method for transmitting during RACH processing during service request processing. A specific example of a parameter that needs to be added is a message indicating that the message is a response message to a UE monitoring message.

[0315] As specific examples of methods for transmitting during RACH processing in service request processing, the following (1) and (2) are disclosed. (1) A random access preamble is used. A specific example of a parameter that needs to be added is a message indicating that the message is a response message to a UE monitoring message.

[0316] (2) A scheduled transmission message is used. More specifically, an RRC connection request message is used (see Non-Patent Document 2). A specific example of a parameter that needs to be added is a message indicating that the message is a response message to a UE monitoring message. The message indicating that the message is a response message to a UE monitoring message may be notified by being included in the "Establishment Cause" parameter set in the message.

[0317] Next, a specific example of a sequence of a communication system in Modification 5 of Embodiment 1 will be described with reference to Figures 21 and 22. Figures 21 and 22 are diagrams showing an example of a sequence of a communication system in Modification 5 of Embodiment 1. Figures 21 and 22 are connected at the position of boundary line BL2. Figures 21 and 22 show a sequence in the case where a UE monitoring message is notified by providing a new identifier in the PDCCH for notifying the presence or absence of a UE monitoring message. The sequences shown in Figures 21 and 22 are similar to the sequences shown in Figures 19 and 20, and therefore the same steps are assigned the same step numbers and common descriptions will be omitted.

[0318] In Step ST1904, the UE receives the PDCCH at the timing of receiving the paging message and determines whether or not the P-RNTI is present in the PDCCH. In other words, the UE determines whether or not the P-RNTI is addressed. If it is determined in Step ST1904 that the PDCCH has a P-RNTI, it proceeds to Step ST1905, and if it is determined that the P-RNTI is not present in the PDCCH, it proceeds to Step ST2001.

[0319] In Step ST1905, the UE judges whether or not it is in RRC_IDLE. If it is judged in Step ST1905 that it is in RRC_IDLE, it moves to Step ST1906, and if it is judged that it is not in RRC_IDLE, it moves to Step ST2001.

[0320] In Step ST1906, the UE judges whether or not the UE-ID in the paging message matches its own UE-ID. If it is judged in Step ST1906 that the UE-ID in the paging message matches its own UE-ID, it proceeds to Step ST2003, and if it is judged that the UE-ID in the paging message does not match its own UE-ID, it proceeds to Step ST2001.

[0321] In step ST2001, the UE determines whether or not the PDCCH has an M-RNTI. In other words, the UE determines whether or not the M-RNTI is addressed. If it is determined in step ST2001 that the PDCCH has an M-RNTI, the UE proceeds to step ST2002, and if it is determined that the PDCCH does not have an M-RNTI, the UE returns to step ST1903.

[0322] In Step ST2002, the UE transmits a response message to the UE monitoring message to the MME. The response message to the UE monitoring message may be transmitted using a random access preamble, a scheduled transmission, or an RRC connection request. After that, the UE proceeds to Step ST1911 in FIG. 22.

[0323] In Step ST2003, the UE determines whether or not the PDCCH has an M-RNTI. In other words, the UE determines whether or not the M-RNTI is addressed. If it is determined in Step ST2003 that the PDCCH has an M-RNTI, the UE proceeds to Step ST2004, and if it is determined that the PDCCH does not have an M-RNTI, the UE proceeds to Step ST1907.

[0324] In Step ST2004, the UE adds a response message to the UE monitoring message to an RRC connection request.

[0325] The response message to the UE monitoring message may be added to a normal response message to paging. The response message to the UE monitoring message may be added to a random access preamble or a scheduled transmission. After that, the UE proceeds to Step ST1907.

[0326] Next, a specific example of a sequence of a communication system in Modification 5 of Embodiment 1 will be described with reference to Figures 23 and 24. Figures 23 and 24 are diagrams showing another example of a sequence of a communication system in Modification 5 of Embodiment 1. Figures 23 and 24 are connected at the position of boundary line BL3. Figures 23 and 24 show a sequence in the case where an indicator indicating transmission of a UE monitoring message (hereinafter also referred to as a "UE monitoring indicator") is mapped in a paging message and the UE monitoring message is notified. The sequences shown in Figures 23 and 24 are similar to the sequences shown in Figures 19 and 20, so the same step numbers are assigned to the same steps and common descriptions will be omitted.

[0327] In Step ST2101 of Fig. 24, the UE judges whether or not a UE monitoring indicator is present in the paging message. If it is judged in Step ST2101 that a UE monitoring indicator is present, the UE proceeds to Step ST2102, and if it is judged that a UE monitoring indicator is not present, the UE ends the processing.

[0328] In Step ST2102, the UE transmits a response message to the UE monitoring message to the MME. The response message to the UE monitoring message may be transmitted using a random access preamble, a scheduled transmission, or an RRC connection request.

[0329] Next, a specific example of a sequence of a communication system in Modification 5 of Embodiment 1 will be described with reference to Figures 25 and 26. Figures 25 and 26 are diagrams showing another example of a sequence of a communication system in Modification 5 of Embodiment 1. Figures 25 and 26 are connected at the position of boundary line BL4. Figures 25 and 26 show a sequence in the case where a UE monitoring message is mapped in a paging message and the UE monitoring message is notified. The sequences shown in Figures 25 and 26 are similar to the sequences shown in Figures 19 and 20, so the same step numbers are assigned to the same steps and common descriptions will be omitted.

[0330] In Step ST2201 of FIG. 26, the UE judges whether or not a UE monitoring message is mapped in a paging message. In other words, the UE judges whether or not a UE monitoring message is present in the paging message. If it is judged in Step ST2201 that a UE monitoring message is present in the paging message, the UE proceeds to Step ST2102, and if it is judged that a UE monitoring message is not present in the paging message, the UE ends the processing.

[0331] The fifth modification of the first embodiment can be used in combination with the second modification of the first embodiment or the third modification of the first embodiment described above.

[0332] In addition to the effects of the first embodiment, the fifth modification of the first embodiment described above can provide the following effects: The procedures for establishing and releasing an RRC connection are no longer necessary, which can reduce the power consumption of the UE, and radio resources can be used effectively.

[0333] Embodiment 1, Variation 6 Variation 6 of Embodiment 1 shows further improvements to the above-described Embodiment 1. In this variation, differences from the solution of the above-described Embodiment 1 will be mainly explained, and parts that are not explained will be the same as in Embodiment 1.

[0334] In this modification, the delivery confirmation information from the eNB to the UE includes information about the eNB or the system on the network side to which the eNB belongs.

[0335] As specific examples of information about the system, the following four items (1) to (4) will be disclosed. (1) Status information or restriction information. As specific examples of status information and restriction information, the following three items (1-1) to (1-3) are disclosed. (1-1) Indication of normality / abnormality of the eNB or the network to which the eNB belongs. (1-2) Indication of congested / non-congested status of the eNB or the network to which the eNB belongs. (1-3) Indication of availability / unavailability of the eNB or the network to which the eNB belongs. (2) The system information itself, which may be part of the system information. (3) The date and time when changes such as those in (1) to (2) above occurred. (4) A combination of (1) to (3) above.

[0336] Variant 6 of embodiment 1 can be used in combination with the above-mentioned variant 1 of embodiment 1, variant 2 of embodiment 1, variant 3 of embodiment 1, variant 4 of embodiment 1, or variant 5 of embodiment 1.

[0337] When the sixth modification of the first embodiment is combined with the first modification of the first embodiment, the response message to the UE monitoring message may include information about the eNB or the system on the network side to which the eNB belongs.

[0338] When combining variant 6 of embodiment 1 with variant 2 of embodiment 1 or variant 3 of embodiment 1, the UE monitoring message from the eNB to the UE simply needs to include information about the eNB or the system on the network side to which the eNB belongs.

[0339] In addition to the effects of the first embodiment, the sixth modification of the first embodiment described above can provide the following effects: The UE can acquire information about the eNB or the system on the network side to which the eNB belongs at the UE monitoring period.

[0340] Embodiment 2 The problem to be solved in the second embodiment will be described below. The current 3GPP E-UTRAN standard does not specify a means for notifying the E-UTRAN of an RRC connection release initiated by the UE side in the RRC_CONNECTED state. Therefore, when the UE transitions to the RRC_IDLE state in response to a command from an application, the RRC states of the UE and E-UTRAN do not match, resulting in a problem that the E-UTRAN continues to reserve system resources unnecessarily.

[0341] 27 to 29 are diagrams showing sequences for explaining the problem to be solved in embodiment 2. Fig. 27 and Fig. 28 are connected at the position of boundary line BL5. Fig. 28 and Fig. 29 are connected at the position of boundary line BL6.

[0342] The UE has an application (hereinafter sometimes referred to as "APP") that runs on TCP / IP.

[0343] 27 to 29 show a case where the UE is in the RRC_IDLE state and the ECM (EPS Connection Management)_IDLE state in Step ST5101, the eNB is in the RRC_IDLE state with respect to the UE in Step ST5102, and the MME is in the ECM_IDLE state with respect to the UE in Step ST5103. The RRC state of the eNB refers to the RRC state of the UE that the eNB assumes as a target (hereinafter, may be simply referred to as the "RRC state of the eNB").

[0344] When the application of the UE starts access, the application of the UE makes an access request to the NAS of the UE in Step ST5104. In response to this access request, the UE starts service request procedure A in Step ST5105.

[0345] A specific example of the service request process A in Step ST5105 is shown below: In Step ST5106, the NAS of the UE makes a service request to the AS (Access Stratum) (RRC).

[0346] In Step ST5107, which includes the processes of Steps ST5108 to ST5110, the UE performs an RRC connection setup procedure with the eNB.

[0347] In Step ST5108, the AS (RRC) of the UE notifies the eNB of an RRC connection request. In Step ST5109, the eNB notifies the AS (RRC) of the UE of an RRC connection setup. In Step ST5110, the AS (RRC) of the UE notifies the AS (RRC) of an RRC connection setup complete.

[0348] In this way, when the RRC connection setup procedure in Step ST5107 is completed, the UE transitions to the RRC_CONNECTED state and the ECM_CONNECTED state in Step ST5111. Also, the eNB transitions the UE to the RRC_CONNECTED state in Step ST5112.

[0349] In this way, after establishing an RRC connection between the UE and the eNB and transitioning to an RRC_CONNECTED state, the UE notifies the eNB of a service request message in Step ST5113.

[0350] In Step ST5114, the eNB that has received the service request message notifies the MME of the service request message.

[0351] In Step ST5115, authentication processing and security control processing are performed between the UE, the MME, and the HSS.

[0352] In Step ST5116 of FIG. 28, the MME notifies the eNB of an initial context setup request message in order to activate the radio bearer and the S1 bearer.

[0353] In Step ST5117, which includes the processes of Steps ST5118 and ST5119, the eNB that has received the initial context setup request message performs a radio bearer establishment procedure with the UE.

[0354] In Step ST5118, the eNB notifies the UE of an RRC connection reconfiguration message. In Step ST5119, the UE notifies the eNB of an RRC connection reconfiguration complete message.

[0355] In Step ST5120, the eNB, which has established the radio bearer and configured the S1 bearer between the UEs in this manner, notifies the MME of an initial context setup complete message.

[0356] In Step ST5121, the MME that has received the initial context setup complete message notifies the S-GW of a modify bearer request message.

[0357] The S-GW that has received the modify bearer request message performs the process of Step ST5122, which includes the processes of Steps ST5123 to ST5125. Specifically, in Step ST5123, the S-GW notifies the P-GW of the modify bearer request message. In Step ST5124, the P-GW that has received the bearer request message performs IP connectivity access network (IP-CAN) session control with the PCRF (Policy and Charging Rule Function) in accordance with the bearer request message. Specifically, the P-GW performs an IP-CAN session modification. The IP-CAN session modification is sometimes called a "PCEF Initiated IP-CAN Session Modification."

[0358] In Step ST5126, the S-GW that has received the modify bearer response message in Step ST5125 notifies the MME of a modify bearer response message.

[0359] In Step ST5127, the MME that has received the modify bearer response message transitions to the ECM_CONNECTED state for the UE. Alternatively, the MME may transition to the ECM_CONNECTED state for the UE upon completion of establishment of the S1 connection for the UE. The MME recognizes that establishment of the S1 connection for the UE has been completed by receiving the initial context setup complete message in Step ST5120.

[0360] Through these processes, in Step ST5128, an EPS bearer is established between the UE and the P-GW.

[0361] As a result of the service request processing in step ST5105 establishing an EPS bearer, in step ST5129 an end-to-end service is executed between the UE and the application server (APP server), and in step ST5130 application data is communicated from the UE to the application server.

[0362] In LTE, there is no provision for a means for the UE and eNB to notify E-UTRAN of an RRC connection release initiated by the UE in the RRC_CONNECTED state. Therefore, unless an RRC connection release is initiated from the network side, the RRC_CONNECTED state is maintained between the UE and eNB, and the ECM_CONNECTED state is maintained between the UE and MME.

[0363] The network side cannot recognize whether data is generated in the UE application. Therefore, even if there is no data generated in the UE application, the network side cannot recognize the situation and cannot immediately start the RRC connection release procedure. The network side continues to maintain the RRC_CONNECTED state between the UE and eNB and the ECM_CONNECTED state between the UE and MME.

[0364] To solve this problem, the network side may determine whether data has been transmitted or received within a predetermined period, and if not, initiate an S1 release procedure, which releases the RRC connection and S1 bearer, transitions the state between the eNB to RRC_IDLE, and transitions the state between the UE and MME to ECM_IDLE.

[0365] However, even if such processing is performed, for example, when a UE application instructs the UE to transition to RRC_IDLE, the UE transitions to the RRC_IDLE state, but the E-UTRAN remains in the RRC_CONNECTED state, so the RRC states of the UE and E-UTRAN do not match, and the E-UTRAN continues to reserve system resources unnecessarily. This remains a problem.

[0366] An example in which the RRC states become inconsistent will be described with reference to Figures 27 to 29. For example, when no more data is generated in the application of the UE, in Step ST5131 of Figure 29, the NAS of the UE notifies the AS of an instruction to release a connection.

[0367] In Step ST5101, the UE performs an RRC connection release procedure and transitions to RRC_IDLE. After transitioning from RRC_IDLE, the UE may also transition to ECM_IDLE. However, since the network side cannot recognize this state, the eNB maintains the RRC_CONNECTED state in Step ST5112.

[0368] The eNB monitors whether data has been transmitted or received, and if no data has been transmitted or received within a predetermined period, it starts S1 release procedure A in Step ST 5134. A data monitoring timer is set as the predetermined period, and in Step ST 5133, the eNB determines whether the data monitoring timer has expired.

[0369] In S1 release processing A, the eNB performs the processing of Steps ST5135 to ST5140. In Step ST5135, the eNB notifies the MME of a UE context release request. In Step ST5136, the MME notifies the S-GW of a Release Access Bearers Request. In Step ST5137, the S-GW notifies the MME of an access bearers release response. In Step ST5138, the MME notifies the eNB of a UE context release command. In Step ST5139, the eNB notifies the UE of an RRC connection release. In Step ST5140, the eNB notifies the MME of UE context release complete. As a result, the radio bearer, S1 bearer, and EPS bearer for the UE are released. In Step ST5141, the eNB transitions to the RRC_IDLE state, and in Step ST5142, the MME transitions to the ECM_IDLE state.

[0370] In this way, when there is no more application data generated, the UE transitions to the RRC / ECM_IDLE state in Step ST5101, but the eNB and MME do not start the S1 release procedure and remain in the RRC_CONNECTED state and the ECM_CONNECTED state until the data monitor timer expires. Therefore, as shown in Step ST5132, a period occurs in which the states of the UE, the eNB, and the MME do not match.

[0371] The solution in the second embodiment is as follows: A message for notifying the RRC connection state of the UE between the UE and the eNB (hereinafter, may be referred to as "Uu keep alive indication", "Uu keep alive ind", or "uu-keep-alive") is provided.

[0372] The UE periodically transmits "Uu keep alive ind" to the eNB. The eNB may use the "Uu keep alive ind" to determine the RRC state of the UE (hereinafter, sometimes referred to as "RRC state determination"). Specific examples of RRC state determination will be described later.

[0373] As a result, when the UE transitions to RRC_IDLE in response to a command from the UE application, the periodic transmission of "Uu keep alive ind" from the UE to the eNB stops. Therefore, the eNB can determine that the UE's RRC state is not RRC_CONNECTED, that is, RRC_IDLE. This solves the problem of the RRC states on the UE and network (E-UTRAN) side not matching, causing E-UTRAN to continue to reserve system resources unnecessarily.

[0374] The period in which the UE transmits "Uu keep alive ind" to the eNB may be referred to as the "Uu keep alive ind" transmission period. The UE may also transmit "Uu keep alive ind" after a timer expires or when the timer expires. This timer may also be referred to as the "Uu keep alive ind" transmission timer.

[0375] The following description will be mainly based on the "Uu keep alive ind" transmission period, but a "Uu keep alive ind" transmission timer can also be used.

[0376] The eNB may transmit acknowledgement information when it receives "Uu keep alive ind." Alternatively, the eNB may transmit acknowledgement information when it receives "Uu keep alive ind" within the period. A specific example of the acknowledgement information is a response message (ACK) in the RLC layer. The acknowledgement information may be a status PDU.

[0377] The following three (1) to (3) are disclosed as specific examples of the purpose for which the UE notifies the eNB of "Uu keep alive ind." (1) To communicate "RRC_CONNECTED". (2) To request continuation of "RRC_CONNECTED". (3) A combination of (1) and (2) above.

[0378] As specific examples of RRC state determination, the following four (1) to (4) are disclosed. (1) If the eNB does not receive "Uu keep alive ind" within the "Uu keep alive ind" transmission period, it determines that the UE is in RRC_IDLE, or has transitioned from RRC_CONNECTED to RRC_IDLE, or does not request continuation of RRC_CONNECTED (hereinafter, collectively referred to as "determining as RRC_IDLE"). Also, if the eNB receives "Uu keep alive ind" within the "Uu keep alive ind" transmission period, it determines that the UE is in RRC_CONNECTED, or will continue RRC_CONNECTED, or will request continuation of RRC_CONNECTED (hereinafter, collectively referred to as "determining as RRC_CONNECTED"). The method of determining and notifying the "Uu keep alive ind" transmission period will be described later.

[0379] (2) If the eNB does not receive "Uu keep alive ind" within the "Uu keep alive ind" transmission period for a predetermined number of consecutive times, the eNB determines that the state is RRC_IDLE. The predetermined number of times may be determined statically or semi-statically. The method of determining and notifying the predetermined number of times will be described later.

[0380] (3) If the eNB does not receive "Uu keep alive ind" within a predetermined period, it determines that the UE is in RRC_IDLE. The predetermined period may be longer than the UE's "Uu keep alive ind" transmission cycle. The predetermined period may be determined statically or semi-statically. The method of determining and notifying the predetermined period will be described later. This predetermined period may be used as the data monitoring timer. Therefore, during the period in which the UE requests to continue in "RRC_CONNECTED", the eNB can avoid initiating a transition to RRC_IDLE due to the expiration of the data monitoring timer. This makes it possible to maintain the RRC_CONNECTED state between the UE and the eNB. The data monitoring timer starts when data is received at the Uu point. When new data is received at the Uu point, the data monitoring timer is stopped, reset, and started from the beginning. The following three examples (3-1) to (3-3) are disclosed as specific examples of data at the Uu point. (3-1) Data at the RRC level (3-2) Data at the NAS level. (3-3) A combination of (3-1) and (3-2). (4) A combination of (1) to (3) above.

[0381] Specific examples of entities that determine the "Uu keep alive ind" transmission cycle include the UE, eNB, and APP server (application).

[0382] As specific examples of methods for determining the "Uu keep alive ind" transmission period of the UE, the following six methods (1) to (6) are disclosed. (1) It may be determined depending on the application. The NAS of the UE may determine the "Uu keep alive ind" transmission period based on the QoS, QCI, bearer information, session timer, etc. required by the application. Alternatively, the period may be a period for periodically transmitting small packets (hereinafter referred to as "keep-alive packets") for the sole purpose of monitoring the session connection between end-to-end applications in communication, or may be an inverse integer multiple (1 / integer multiple) of the period.

[0383] (2) The "Uu keep alive ind" transmission period may be determined depending on the DRX period notified by the eNB. The "Uu keep alive ind" transmission period may be an integer multiple of the DRX period, or an inverse integer multiple of the DRX period (1 / integer multiple). This allows the DRX period, which is the timing at which a UE in RRC_CONNECTED state monitors the PDCCH, to coincide as closely as possible with the "Uu keep alive ind" transmission period, which is the timing at which the "Uu keep alive ind" is transmitted, thereby achieving the effect of reducing the power consumption of the UE.

[0384] (3) The period may be determined depending on the data monitoring timer notified by the eNB. The "Uu keep alive ind" transmission period may be set to a value shorter than the data monitoring timer. This prevents the eNB from initiating a transition to RRC_IDLE due to the expiration of the data monitoring timer while the UE is requesting to remain in "RRC_CONNECTED" state.

[0385] (4) The "Uu keep alive ind" transmission period may be determined depending on the validity period of the timing advance. The "Uu keep alive ind" transmission period may be set to an integer multiple of the validity period of the timing advance, or an inverse integer multiple (1 / integer multiple) of the validity period of the timing advance. This allows the validity period of the timing advance, which is the timing at which a UE in RRC_CONNECTED performs RACH processing, to coincide as closely as possible with the "Uu keep alive ind" transmission period, which is the timing at which the "Uu keep alive ind" is transmitted, thereby achieving the effect of reducing the power consumption of the UE.

[0386] (5) Determined based on the UE load status and remaining battery power. If the load status is high or the remaining battery power is low, the "Uu keep alive ind" transmission cycle is lengthened. If the load status is low or the remaining battery power is high, the "Uu keep alive ind" transmission cycle is shortened or kept normal. This makes it possible to reduce the UE load and take measures when the remaining battery power is low. (6) A combination of (1) to (5) above.

[0387] The following two methods (1) and (2) are disclosed as specific examples of a method for the UE to notify the eNB of the determined "Uu keep alive ind" transmission cycle. (1) Notify together with "Uu keep alive ind." It may be notified with each "Uu keep alive ind" or only once at the beginning. Compared to notifying every time, notifying only once at the beginning can have the effect of reducing the amount of information.

[0388] (2) The notification is made prior to the transmission of "Uu keep alive ind." It may also be made once. Compared to specific example (1), it is possible to obtain an effect that the eNB can prepare for receiving "Uu keep alive ind." As specific examples, the following two examples (2-1) and (2-2) are disclosed. (2-1) Establish new RRC signaling or NAS signaling. (2-2) Existing RRC signaling or NAS signaling is used. This specific example (2-2) is effective compared to the specific example (2-1) in that it does not require the provision of a new signal. This specific example (2-2) can avoid the communication system from becoming complicated.

[0389] The following four (1) to (4) are disclosed as specific examples of parameters to be newly mapped to RRC signaling or NAS signaling. (1) “Uu keep alive ind” transmission period. (2) UE identifier, which may be specifically UE-ID or IMSI. (3) Information about the application server to which you are connecting. (4) A combination of (1) to (3) above.

[0390] A specific example of using an existing RRC signal is the use of an RRC connection reconfiguration "RRC Connection Request" message.

[0391] Specific examples of parameters that need to be added to existing RRC signaling include (1) the "Uu keep alive ind" transmission cycle, and (2) information about the application server to which the connection is made.

[0392] A specific example of using an existing NAS signal is the use of a service request "Service Request" message.

[0393] Specific examples of parameters that need to be added to existing NAS signaling include (1) the "Uu keep alive ind" transmission cycle, and (2) information about the application server to which the connection is made.

[0394] The following five methods (1) to (5) are disclosed as specific examples of methods for determining the "Uu keep alive ind" transmission period by the eNB. (1) The "Uu keep alive ind" transmission period may be determined depending on the DRX period. The "Uu keep alive ind" transmission period may be an integer multiple of the DRX period, or an inverse integer multiple of the DRX period (1 / integer multiple). This allows the DRX period, which is the timing at which a UE in RRC_CONNECTED state monitors the PDCCH, to coincide as closely as possible with the "Uu keep alive ind" transmission period, which is the timing at which the "Uu keep alive ind" is transmitted, thereby achieving the effect of reducing the power consumption of the UE.

[0395] (2) The period may be determined depending on the data monitoring timer or the application session timer. The "Uu keep alive ind" transmission period may be set to a value shorter than the data monitoring timer. This prevents the eNB from initiating a transition to RRC_IDLE due to the expiration of the data monitoring timer during the period when the UE requests to continue in "RRC_CONNECTED" state.

[0396] (3) The "Uu keep alive ind" transmission period may be determined depending on the validity period of the timing advance. The "Uu keep alive ind" transmission period may be set to an integer multiple of the validity period of the timing advance, or an inverse integer multiple (1 / integer multiple) of the validity period of the timing advance. This allows the validity period of the timing advance, which is the timing at which a UE in RRC_CONNECTED performs RACH processing, to coincide as closely as possible with the "Uu keep alive ind" transmission period, which is the timing at which the UE transmits "Uu keep alive ind," thereby achieving the effect of reducing the power consumption of the UE.

[0397] (4) Determined based on the load status of the eNB and the load status of the network. When the load status is high, the "Uu keep alive ind" transmission cycle is lengthened or "Uu keep alive ind" transmission is prohibited, in other words, "Uu keep alive ind" transmission is set to infinity. When the load status is low, the "Uu keep alive ind" transmission cycle is shortened or kept normal. This makes it possible to reduce the load on the eNB and the network. The network load status is notified from the MME to the eNB by an existing message indicating MME overload. The "Overload START" message on the S1 interface may also be used. A parameter related to "Uu keep alive ind" may be added to "Overload Action". A parameter for prohibiting "Uu keep alive ind" may also be added. (5) A combination of (1) to (4) above.

[0398] The following six methods (1) to (6) are disclosed as specific examples of a method for notifying the UE of the "Uu keep alive ind" transmission period determined by the eNB. (1) Notify by broadcast information. (2) Notification will be made by individual information. (3) Notification by TAU processing. A specific example is a method of notifying by "TAU Accept" or the like. (4) Notification in the attach process. Specific examples include a method of notification by "Attach Accept" or "RRC Connection Reconfiguration." (5) Notification is made in the RRC Connection Setup Procedure. A specific example is a method of notifying by "RRC Connection Setup" or the like. (6) Notification is made in the Service Request Procedure. A specific example is a method of notifying by "RRC Connection Reconfiguration."

[0399] A specific example of a method for determining the "Uu keep alive ind" transmission period of the APP server is disclosed below.

[0400] The "Uu keep alive ind" transmission period may be determined depending on the application. The "Uu keep alive ind" transmission period may be determined based on the QoS, QCI, bearer information, session timer, etc. required by the application. Alternatively, the period may be set to a period for periodically transmitting small packets (hereinafter referred to as "keep-alive packets") for the sole purpose of monitoring the session connection between applications at the end-to-end of the communication, or may be set to a reciprocal multiple of an integer (1 / integer multiple) of the period.

[0401] The APP server notifies the eNB of the determined "Uu keep alive ind" transmission period, and also notifies the UE via the eNB. Specific examples of entities that determine the predetermined number of times include the UE, the eNB, and the APP server (application).

[0402] The following three methods (1) to (3) are disclosed as specific examples of methods for determining the predetermined number of times for a UE. (1) It may be determined depending on the application. The NAS of the UE may determine a predetermined number of times based on the QoS, QCI, bearer information, session timer, etc. required by the application. Also, it may be a period for periodically transmitting small packets (hereinafter referred to as "keep-alive packets") for the sole purpose of monitoring the session connection between applications at the end-to-end of the communication, or a "UE keep alive ind" transmission period.

[0403] (2) The predetermined number of times may be determined depending on the data monitoring timer notified by the eNB. The predetermined number of times may be the data monitoring timer or the "Uu keep alive ind" transmission period. This prevents the eNB from initiating a transition to RRC_IDLE during the period when the UE requests to continue in "RRC_CONNECTED". (3) A combination of (1) and (2) above.

[0404] A specific example of a method for the UE to notify the eNB of the predetermined number of times determined by the UE is similar to the specific example of a method for notifying the eNB of the "Uu keep alive ind" transmission period determined by the UE, and therefore a description thereof will be omitted.

[0405] A specific example of how the eNB determines the predetermined number of times is disclosed below. The predetermined number of times may be determined based on a data monitoring timer or a session timer of an application. The predetermined number of times may be the data monitoring timer or the "Uu keep alive ind" transmission period. This prevents the eNB from initiating a transition to RRC_IDLE during the period when the UE requests to continue in "RRC_CONNECTED" state.

[0406] A specific example of a method for notifying the UE of the predetermined number of times determined by the eNB is similar to a specific example of a method for notifying the UE of the "Uu keep alive ind" transmission period determined by the eNB, and therefore a description thereof will be omitted.

[0407] A specific example of how the APP server determines the predetermined number of times is disclosed below. The predetermined number of times may be determined depending on the application. The predetermined number of times may be determined based on the QoS, QCI, bearer information, session timer, etc. required by the application. The predetermined number of times may also be determined as a periodic transmission cycle for small packets (hereinafter referred to as "keep-alive packets") for the sole purpose of monitoring the session connection between applications at the end-to-end of the communication, or as a "UE keep alive ind" transmission cycle.

[0408] The APP server notifies the eNB of the predetermined number of times determined, and also notifies the UE via the eNB.

[0409] Specific examples of entities that determine the predetermined period include the UE, the eNB, and the APP server (application).

[0410] As specific examples of methods for determining the predetermined period of time for a UE, the following six methods (1) to (6) are disclosed. (1) The period may be determined depending on the application. The NAS of the UE may determine the predetermined period based on the QoS, QCI, bearer information, session timer, etc. required by the application. Alternatively, the period may be a period for periodically transmitting small packets (hereinafter referred to as "keep-alive packets") for the sole purpose of monitoring the session connection between end-to-end applications in communication, or an inverse integer multiple (1 / integer multiple) of the period. Alternatively, the data amount, data transmission period, etc. may be notified to other nodes as a predetermined period. Based on the QoS, QCI, bearer information, etc. required by the application, the period for which the NAS of the UE requests RRC_CONNECTED or the period for which RRC_CONNECTED is expected may be determined as a predetermined period.

[0411] (2) The period may be determined depending on the DRX cycle notified by the eNB. The predetermined period may be an integer multiple of the DRX cycle or an inverse integer multiple of the DRX cycle (1 / integer multiple). This allows the DRX cycle, which is the timing at which a UE in RRC_CONNECTED state monitors the PDCCH, to coincide as closely as possible with the predetermined period, which is the timing at which the "Uu keep alive ind" is transmitted, thereby achieving the effect of reducing the power consumption of the UE.

[0412] (3) The period may be determined depending on the data monitoring timer notified by the eNB. The predetermined period may be set to a value shorter than the data monitoring timer. This prevents the eNB from initiating a transition to RRC_IDLE due to the expiration of the data monitoring timer while the UE is requesting to remain in "RRC_CONNECTED".

[0413] (4) The timing advance may be determined depending on the validity period of the timing advance. The predetermined period may be an integer multiple of the validity period of the timing advance, or an inverse integer multiple (1 / integer multiple) of the validity period of the timing advance. This allows the validity period of the timing advance, which is the timing when the UE in RRC_CONNECTED performs RACH processing, to coincide as closely as possible with the predetermined period, which is the timing when the "Uu keep alive ind" is transmitted, thereby achieving the effect of reducing the power consumption of the UE.

[0414] (5) Determined based on the UE load status and remaining battery power. If the load status is high or the remaining battery power is low, the predetermined period is extended. If the load status is low or the remaining battery power is high, the predetermined period is shortened or kept as normal. This makes it possible to reduce the UE load and take measures when the remaining battery power is low. (6) A combination of (1) to (5) above.

[0415] A specific example of how the eNB determines the predetermined period is similar to the method by which the eNB determines the "Uu keep alive ind" transmission period, and therefore a description thereof will be omitted.

[0416] Specific examples of how the APP server determines the predetermined period are disclosed below. The predetermined period may be determined depending on the application. The predetermined period may be determined based on the QoS, QCI, bearer information, session timer, etc. required by the application. Alternatively, the predetermined period may be determined as a period for periodically transmitting small packets (hereinafter referred to as "keep-alive packets") for the sole purpose of monitoring the session connection between end-to-end applications in communication, or as an inverse integer multiple (1 / integer multiple) of the period. Alternatively, the data amount, data transmission period, etc. may be notified to other nodes as a predetermined period. Based on the QoS, QCI, bearer information, etc. required by the application, the period during which the UE's NAS requests RRC_CONNECTED or the period during which RRC_CONNECTED is expected may be determined as a predetermined period.

[0417] The notification method for each decision-making entity is similar to the method for determining and notifying the "Uu keep alive ind" transmission period, and therefore a description thereof will be omitted.

[0418] When the eNB determines that the RRC state is RRC_IDLE, the eNB may execute IDLE transition processing. The following three examples (1) to (3) are disclosed as specific examples of IDLE transition processing.

[0419] (1) Release the system resources reserved by E-UTRAN for the UE in the CONNECTED state. Specific examples of system resources include the radio bearer, S1 bearer, EPS bearer, etc. for the UE. Specific examples of release methods include initiating an S1 release procedure by the eNB, releasing the UE context to the MME by the eNB, releasing the access bearer to the S-GW, and releasing the RRC connection to the UE.

[0420] (2) The ECM state on the network side is changed to ECM_IDLE. The ECM state of the MME is changed to ECM_IDLE. A specific example of the change method is the same as the specific example of the release method in (1) above, so a description thereof will be omitted.

[0421] (3) The RRC state on the network side is changed to RRC_IDLE. The RRC state of the eNB is changed to RRC_IDLE. A specific example of the change method is the same as the specific example of the release method in (1) above, and therefore a description thereof will be omitted.

[0422] As specific examples of "Uu keep alive ind", the following four (1) to (4) are disclosed. (1) Messages are limited to the Uu point. The Uu point is the interface point between the UE and eNB, the UE and HeNB, or the UE and RN. (2) The message does not need to be notified to a higher-level device of the eNB. Examples of higher-level devices include MME and HSS. (3) RRC message. (4) A combination of (1) to (3) above.

[0423] As specific examples of when "Uu keep alive ind" is used as an RRC message, the following two examples (1) and (2) are disclosed. (1) A new RRC signal or RRC message is established. (2) Existing RRC signals or RRC messages are used. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of new signals. This specific example (2) can avoid the communication system from becoming complicated.

[0424] The following seven (1) to (7) are disclosed as specific examples of parameters to be newly mapped to RRC signals. (1) Indication that the status is "Uu keep alive ind", that the status is "RRC_CONNECTED", and that continuation of "RRC_CONNECTED" is being requested, etc. (2) UE identifier, which may be specifically UE-ID or IMSI.

[0425] (3) Sequence number. This may be a sequence number that increments with each transmission. This may also be a sequence number for strengthening security measures. Even if the encryption key is obtained, if the sequence number is not correct, the message cannot be decrypted, thereby strengthening security measures.

[0426] (4) "Uu keep alive ind" transmission period. When the eNB receives the "Uu keep alive ind" transmission period, it may set the data monitor timer to a value longer than the "Uu keep alive ind" transmission period. The eNB may set the DRX period to an integer multiple of the "Uu keep alive ind" transmission period, or an inverse multiple of the integer (1 / integer multiple). The "Uu keep alive ind" transmission period may be notified only when the UE is the one that determines it.

[0427] (5) A predetermined number of times used when determining the RRC state. The predetermined number of times may be notified only when the UE is the one that determines the predetermined number of times. (6) A predetermined period used when determining the RRC state. The predetermined number of times may be notified only when the UE is the determining entity. (7) A combination of (1) to (6) above.

[0428] Even when the "Uu keep alive ind" transmission cycle is not determined depending on the DRX cycle, the "Uu keep alive ind" may be transmitted at the timing of the DRX cycle. The "Uu keep alive ind" may be transmitted during the active period (on duration) of the DRX cycle. This allows the DRX cycle, which is the timing at which a UE in RRC_CONNECTED state monitors the PDCCH, and the "Uu keep alive ind" transmission cycle, which is the timing at which the "Uu keep alive ind" is transmitted, to coincide as closely as possible, thereby achieving the effect of reducing the power consumption of the UE.

[0429] A specific example of a method for transmitting "Uu keep alive ind" at the timing of the DRX cycle when the "Uu keep alive ind" transmission cycle is not determined depending on the DRX cycle will be disclosed below.

[0430] "Uu keep alive ind" is transmitted at the timing of the DRX cycle immediately after the expiration of the "Uu keep alive ind" transmission cycle. In this case, the eNB may receive "Uu keep alive ind" at the timing of the DRX cycle immediately after the expiration of the "Uu keep alive ind" transmission cycle.

[0431] Furthermore, since "Uu keep alive ind" shown in the second embodiment is a message for notifying the connection state, unlike normal user data transmission, the DRX length may not be changed by this data transmission. As a specific example, "Uu keep alive ind" does not cause a transition from a relatively long DRX cycle to a relatively short DRX cycle.

[0432] The sequence shown in FIG. 30 is similar to the sequences shown in FIGS. 27 to 29, so the same step numbers are assigned to the same steps, and common explanations will be omitted.

[0433] In Step ST5101, Steps ST5103 to ST5105, and Steps ST5129 to ST5130, an end-to-end service is executed between the UE and the application server, and application data is communicated from the UE to the application server.

[0434] In Steps ST5201 to ST5204, the UE notifies the eNB of a "Uu keep alive indication" until an RRC connection release procedure is activated by an instruction to transition to RRC_IDLE from the NAS.

[0435] By notifying the eNB of "Uu keep alive indication," the UE indicates to the eNB that the UE has not yet transitioned to RRC_IDLE, i.e., is in the RRC_CONNECTED state. By receiving the "Uu keep alive indication" from the UE, the eNB recognizes that the UE has not yet transitioned to RRC_IDLE, i.e., is in the RRC_CONNECTED state.

[0436] The eNB determines the state of the RRC connection with the eNB based on whether or not it has received a "Uu keep alive indication" from the UE. The eNB determines whether or not it has received a "Uu keep alive indication" from the UE at the timing of the "Uu keep alive indication" transmission cycle.

[0437] In Steps ST5201 to ST5204, the UE periodically transmits a "Uu keep alive indication" to the eNB, and then, when no data is generated in the UE application, the UE performs an RRC connection release process in Step ST5131 in response to an instruction from the NAS, and transitions to RRC_IDLE in Step ST5101. When the UE transitions to RRC_IDLE, it stops transmitting the "Uu keep alive indication."

[0438] If the UE stops transmitting the "Uu keep alive indication," the eNB will not be able to receive the "Uu keep alive indication" at the timing of the "Uu keep alive indication" transmission cycle. That is, in Step ST5205, the keep alive transmission cycle timer expires without reaching the keep alive. Therefore, the eNB can recognize that the RRC connection between the eNB and the UE is not being maintained normally due to some reason, such as the UE transitioning to RRC_IDLE or moving out of the eNB's coverage area.

[0439] In Step ST5205, if the eNB is unable to receive a "Uu keep alive indication" at the timing of the "Uu keep alive indication" transmission cycle, the eNB activates an S1 release procedure A in Step ST5134.

[0440] When the S1 release procedure is performed in Step ST5134, the eNB transitions to the RRC_IDLE state for the UE in Step ST5102, and the MME transitions to the ECM_IDLE state for the UE in Step ST5103. In the S1 release procedure, the eNB and MME release system resources for the UE.

[0441] The method disclosed in this embodiment allows E-UTRAN to recognize the RRC connection status of the UE, so that the period of the status inconsistency can be kept within the "Uu keep alive indication" transmission period at most. Therefore, it is possible to significantly reduce the impact of the status inconsistency. For example, it is possible to eliminate unnecessary consumption of resources for the UE in the eNB. It is also possible to reduce the frequency of occurrence of a state in which calling to the UE is not possible.

[0442] Furthermore, by relating the "Uu keep alive ind" transmission cycle to the DRX cycle, which is the timing at which a UE in RRC_CONNECTED state monitors the PDCCH, and the "Uu keep alive ind" transmission cycle, which is the timing at which the UE transmits "Uu keep alive ind," can be made to coincide as closely as possible, thereby achieving the effect of reducing the power consumption of the UE.

[0443] Furthermore, by associating the "Uu keep alive ind" transmission period with the data monitoring timer, it is possible to prevent the eNB from initiating a transition to RRC_IDLE due to expiration of the data monitoring timer during the period when the UE requests continuation of the "RRC_CONNECTED" state. This makes it possible to maintain the RRC_CONNECTED state between the UE and the eNB.

[0444] Embodiment 3 The problem to be solved in the third embodiment will be described below. As described above, the periodically transmitted keep-alive packets (hereinafter also referred to as "APP keep alive packets") consume system resources in the radio access network, which causes an increase in the radio resources and the processing load in the communication nodes. Another problem is that the power consumption of the UE increases.

[0445] These problems occur as follows: In the UE, an application-level session is connected, but there is no data transmission, so the UE performs processing to release the RRC connection and radio access bearer, and transitions to IDLE. However, when a keep-alive packet is sent from the application, the UE performs processing to set up the RRC connection and radio access bearer. The above-mentioned problems occur when the UE repeats the processing to release and set up the RRC connection and radio access bearer in this way.

[0446] Figures 31 and 32 are diagrams showing sequences for explaining the problem to be solved in embodiment 3. Figures 31 and 32 are connected at the position of boundary line BL7. The sequences shown in Figures 31 and 32 are similar to the sequences shown in Figures 27 to 29, so the same step numbers are assigned to the same steps and common explanations will be omitted.

[0447] In Step ST5101, Steps ST5104 to ST5105, and Steps ST5129 to ST5130, an end-to-end service is executed between the UE and the application server, and application data is communicated from the UE to the application server.

[0448] The eNB monitors whether data has been transmitted or received, and if no data has been transmitted or received within a predetermined period of time, it starts S1 release procedure A in Step ST5134. A data monitoring timer may be set as the predetermined period. In Step ST7101, it determines whether the data monitoring timer has expired. The radio bearer, S1 bearer, and EPS bearer are released by the S1 release procedure in Step ST5134. The UE transitions to the RRC / ECM_IDLE state in Step ST5101. Furthermore, the eNB transitions to the RRC_IDLE state, and the MME transitions to the ECM_IDLE state.

[0449] Thereafter, in Step ST7102, an "APP keep alive packet" is periodically transmitted from the application of the UE, and the UE activates service request processing A in Step ST5105 again in response to the "APP keep alive packet." Service request processing A causes the UE to transition to the RRC / ECM_CONNECTED state. Furthermore, the eNB transitions to the RRC_CONNECTED state with respect to the UE, and the MME transitions to the ECM_CONNECTED state with respect to the UE. This enables communication between the UE and the application server.

[0450] In Step ST7103, the UE transmits an "APP keep alive packet" to the application server.

[0451] The eNB monitors whether data has been transmitted or received, and if no data has been transmitted or received after the UE has transmitted an "APP keep alive packet" to the application server and the data monitoring timer expires in Step ST7104, the eNB starts the S1 release procedure A again in Step ST5134. This S1 release procedure A releases the radio bearer, S1 bearer, and EPS bearer, and the UE transitions to the RRC / ECM_IDLE state again in Step ST5101. Furthermore, the eNB transitions to the RRC_IDLE state, and the MME transitions to the ECM_IDLE state.

[0452] Since there are many cases where application data is not generated after the transmission of the "APP keep alive packet" is completed and the "APP keep alive packet" is transmitted periodically, as described above, the RRC connection state between the UE and the eNB frequently changes, and when the RRC connection state changes frequently, the amount of signaling required for the RRC connection state change increases, which causes problems such as an increase in system resources in the radio access network and an increase in power consumption by the UE.

[0453] Furthermore, in a UE, the RRC state and the ECM state transition in conjunction with each other. When the RRC connection is released in a UE in the ECM_CONNECTED state, the UE transitions to the ECM_IDLE state. When the RRC connection is released, the UE transitions to the RRC_IDLE state. Therefore, when the RRC connection is released, the UE transitions from RRC_CONNECTED to RRC_IDLE, and in conjunction with this, the UE transitions from ECM_CONNECTED to ECM_IDLE (see Chapter 4.6.4 of Non-Patent Document 14).

[0454] In the network, the RRC state and the ECM state transition in conjunction with each other. If it is assumed that the RRC state of the target UE transitions to RRC_IDLE in an eNB in ​​the ECM_CONNECTED state, an S1 release procedure is initiated. Since the S1 connection is released, the UE transitions from ECM_CONNECTED to ECM_IDLE. Therefore, in conjunction with the transition to RRC_IDLE, the S1 connection is released and the UE transitions from ECM_CONNECTED to ECM_IDLE (see Chapter 4.6.4 of Non-Patent Document 14).

[0455] As mentioned above, frequent transitions of the RRC connection state result in frequent transitions of the ECM state, which in turn leads to frequent control processes for establishing and releasing S1 bearers, resulting in an increase in the amount of signaling and a problem of increased system resources in the radio access network.

[0456] The solution to the above problem in the third embodiment is as follows. To solve the above problem, the RRC state at the Uu point is matched with the connection state of the APP session. The eNB recognizes the RRC state of the UE, thereby recognizing the connection state of the APP session, and notifies the network side entity, for example, the S-GW, of this information. The network side entity, for example, the S-GW, that receives the notification controls the transmission of pseudo keep-alive packets (hereinafter also referred to as "pseudo APP keep alive packets" or "local APP keep alive packets").

[0457] The eNB's recognition of the RRC state of the UE complies with the current 3GPP standard.

[0458] Furthermore, the UE shall not transmit keep-alive packets requested for transmission by the application on the Uu point.

[0459] The following are specific examples of entities that determine whether to execute the method of matching the RRC state at the Uu point with the connection state of the APP session: (1) UE. (2) Network side. Specifically, S-GW or P-GW.

[0460] As specific examples of judgment, the following two cases (1A) and (2A) are disclosed. (1A) The case where the decision is made by the UE will be disclosed. The UE makes a decision based on the application that made the access request. It determines whether the application is requesting transmission of a keep-alive packet.

[0461] If the UE determines, as a result of the above-mentioned judgment, that the application is one that requests the transmission of a keep-alive packet, the UE (NAS) notifies the UE application of an Ack (local Ack) for the transmission of the local APP keep-alive packet.

[0462] The UE also notifies the network side of the result of the determination (hereinafter, also referred to as "APP keep alive information"). A specific example of the network side is an entity that transmits a local APP keep alive packet to an application server, such as an S-GW.

[0463] As a specific example of a notification method, the UE notifies the MME of a request to transmit a local APP keep alive packet. Upon receiving the request to transmit the local APP keep alive packet, the MME notifies the S-GW of the request to transmit the local APP keep alive packet.

[0464] The following two methods (1) and (2) are disclosed as specific examples of a method in which the UE notifies the MME of a request to transmit a local APP keep alive packet. (1) A new NAS signal will be established. (2) Use of an existing NAS signal. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of a new signal. This specific example (2) can avoid the communication system from becoming complicated.

[0465] As specific examples of parameters to be newly mapped to the NAS signal, the following five items (1) to (5) are disclosed. (1) Information indicating that the request is for sending a local APP keep alive packet, information for setting the RRC state at the Uu point to match the connection state of the APP session, etc. Hereinafter, this information may be referred to as "APP keep alive information." (2) UE identifier, which may be specifically UE-ID or IMSI. (3) Information about the application server to which you are connecting. (4) The transmission period of keep-alive packets. (5) A combination of (1) to (4) above.

[0466] A specific example of using an existing NAS signal is the use of a service request message.

[0467] The following three (1) to (3) are disclosed as specific examples of parameters that need to be added to existing NAS signaling. (1) Information for setting the RRC state at the Uu point to match the connection state of the APP session, such as a request to send a local APP keep alive packet. (2) Information about the application server to which you are connecting. (3) The transmission period of keep-alive packets.

[0468] The following two methods (1) and (2) are disclosed as specific examples of a method in which the MME notifies the S-GW of a request to transmit a local APP keep alive packet. (1) A new S11 signal will be established. (2) Use of the existing S11 signal. This specific example (2) is effective compared to specific example (1) in that it does not require the provision of a new signal. This specific example (2) can avoid the communication system from becoming complicated.

[0469] As specific examples of parameters to be newly mapped to the S11 signal, the following five (1) to (5) are disclosed. (1) Information for setting the RRC state at the Uu point to match the connection state of the APP session, such as a request to send a local APP keep alive packet. (2) UE identifier, which may be specifically UE-ID or IMSI. (3) Information about the application server to which you are connecting. (4) Keep-alive packet transmission period: Upon receiving the keep-alive packet transmission period, the S-GW may set the local APP keep-alive packet transmission period to the same as the keep-alive packet transmission period. (5) A combination of (1) to (4) above.

[0470] A specific example of using the existing S11 signal is when a Modify Bearer Request message is used.

[0471] The following three (1) to (3) are disclosed as specific examples of parameters that need to be added to the existing S11 signaling. (1) Information for setting the RRC state at the Uu point to match the connection state of the APP session, such as a request to send a local APP keep alive packet. (2) Information about the application server to which you are connecting. (3) The transmission period of keep-alive packets, etc.

[0472] The S-GW that has received the transmission cycle of the keep-alive packets may set the transmission cycle of the local APP keep-alive packets to the same as the transmission cycle of the keep-alive packets.

[0473] (2A) This section describes the case where the decision maker is the network side, for example, the S-GW. The S-GW makes the decision based on the application that made the access request. It determines whether the application is requesting the transmission of keep-alive packets.

[0474] If the S-GW determines as a result of the above-mentioned determination that the application is requesting transmission of a keep-alive packet, it transmits a local APP keep-alive packet to the application server.

[0475] Furthermore, the S-GW notifies the UE side of the result of the determination (hereinafter, also referred to as "APP keep alive information").

[0476] As a specific example of a notification method, the S-GW notifies the MME of a request to transmit an Ack (local Ack) for the transmission of a local APP keep alive packet. The MME, having received the request to transmit an Ack (local Ack) for the transmission of the local APP keep alive packet, notifies the UE via the eNB of the request to transmit an Ack (local Ack) for the transmission of the local APP keep alive packet.

[0477] The following two methods (1) and (2) are disclosed as specific examples of a method in which the S-GW notifies the MME of a request to transmit an Ack (local Ack) in response to transmission of a local APP keep alive packet. (1) A new S11 signal will be established. (2) Use of the existing S11 signal. This specific example (2) is effective compared to specific example (1) in that it does not require the provision of a new signal. This specific example (2) can avoid the communication system from becoming complicated.

[0478] As specific examples of parameters to be newly mapped to the S11 signal, the following five (1) to (5) are disclosed. (1) Information for setting the RRC state at the Uu point to match the connection state of the APP session, such as a request to send an Ack (local Ack) in response to the transmission of a local APP keep alive packet. (2) UE identifier, which may be specifically UE-ID or IMSI. (3) Information about the application server to which you are connecting. (4) Local APP keep alive packet transmission period. (5) A combination of (1) to (4) above.

[0479] A specific example of using the existing S11 signal is the use of a Modify Bearer Response message.

[0480] The following three (1) to (3) are disclosed as specific examples of parameters that need to be added to the existing S11 signaling. (1) Information for setting the RRC state at the Uu point to match the connection state of the APP session, such as a request to send an Ack (local Ack) in response to the transmission of a local APP keep alive packet. (2) Information about the application server to which you are connecting. (3) The transmission period of local APP keep alive packets.

[0481] The following two methods (1) and (2) are disclosed as specific examples of a method in which the MME notifies the UE of a request for an Ack (local Ack) for transmission of a local APP keep alive packet. (1) Establish a new signal. (2) Use of existing signals. This specific example (2) is advantageous compared to specific example (1) in that it does not require the provision of new signals. This specific example (2) can avoid the communication system from becoming complicated.

[0482] As specific examples of parameters to be newly mapped to the NAS signal, the following five items (1) to (5) are disclosed. (1) Information indicating that the request is for sending an Ack (local Ack) in response to the transmission of a local APP keep alive packet, and information for setting the RRC state at the Uu point to match the connection state of the APP session. Hereinafter, this information may be referred to as "APP keep alive information." (2) UE identifier, which may be specifically UE-ID or IMSI. (3) Information about the application server to which you are connecting. (4) Local APP keep alive packet transmission period. (5) A combination of (1) to (4) above.

[0483] Next, as a specific example of using existing signals, a service request process is used, such as an initial context setup request, an RRC connection reconfiguration, etc. during the service request process.

[0484] The following three (1) to (3) are disclosed as specific examples of parameters that need to be added to existing signaling. (1) Information for setting the RRC state at the Uu point to match the connection state of the APP session, such as a request to send an Ack (local Ack) in response to the transmission of a local APP keep alive packet. (2) Information about the application server to which you are connecting. (3) The transmission period of local APP keep alive packets.

[0485] Figures 33 to 35 are diagrams showing an example of a sequence of a communication system in the third embodiment. Figures 33 and 34 are connected at boundary line BL8. Figures 34 and 35 are connected at boundary line BL9. The sequences shown in Figures 33 to 35 are similar to the sequences shown in Figures 27 to 29, so the same step numbers are used for the same steps and common explanations will be omitted.

[0486] The UE has an application that runs on TCP / IP. 33 to 35 show a case where the UE is in the RRC_IDLE state in Step ST5101, the eNB is in the RRC_IDLE state with respect to the UE in Step ST5102, and the MME is in the ECM_IDLE state with respect to the UE in Step ST5103.

[0487] When the application of the UE starts access, the application of the UE makes an access request to the NAS of the UE in Step ST5104. In response to this access request, the UE starts a service request procedure B in Step ST7201.

[0488] The service request process B in step ST7201 can be achieved by modifying part of the service request process A in step ST5105 in Fig. 27. The modified part will be described below.

[0489] In Step ST7202, the service request message notified from the NAS of the UE to the AS includes "APP keep alive information." The "APP keep alive information" is information for setting the RRC state at the Uu point to match the connection state of the APP session. For example, the "APP keep alive information" may be information indicating whether or not to set it, or the information may be included in the message only if it is set.

[0490] In Step ST7203, the UE includes "APP keep alive information" in a service request message and notifies the eNB of the message.

[0491] The eNB that has received the "APP keep alive information" in Step ST7203 includes the "APP keep alive information" in a service request message in Step ST7204 and notifies the MME of the message.

[0492] The MME that has received the "APP keep alive information" includes the "APP keep alive information" in a modify bearer request message of Step ST7205 and notifies the S-GW of the message. In this way, it becomes possible to notify the S-GW, which is an entity on the network side, of whether or not to set the RRC state at the Uu point to match the connection state of the APP session. Therefore, the S-GW can perform processing depending on whether or not to set the RRC state at the Uu point to match the connection state of the APP session.

[0493] The examples shown in Figures 33 to 35 show a case where the "APP keep alive information" in steps ST7202, ST7203, ST7204, and ST7205 is set so that the RRC state at the Uu point and the connection state of the APP session are matched.

[0494] The UE shall not transmit, over the Uu point, a keep-alive packet for which a transmission request has been made by the application. In Step ST7206 of FIG. 35, the UE determines whether or not the APP keep alive packet transmission period timer (hereinafter, may be referred to as the "keep alive transmission period timer") has expired in the application. If it determines that the keep alive transmission period timer has expired, in Step ST7207, the UE transmits an "APP keep alive packet" to the NAS. When an "APP keep alive packet" is generated, the UE does not transmit the "APP keep alive packet" over the Uu point, and therefore does not start service request processing.

[0495] In the UE, the NAS that receives the "APP keep alive packet" from the application may notify the application of a response message in Step ST7209. This response message is called a local response. The NAS of the UE recognizes the RRC / ECM state, and if in the RRC / ECM_CONNECTED state, notifies the application of an Ack (local Ack). If in the RRC / ECM_IDLE state, notifies the application of a Nack (local Nack).

[0496] The UE application that receives the local Ack determines that the RRC / ECM is connected and continues to send "APP keep alive packets" to maintain the session connection state. The UE application that receives the local Nack determines that the RRC / ECM is not connected and stops sending "APP keep alive packets". The session connection may also be disconnected.

[0497] If the application that has received the local Ack from the NAS in Step ST7209 determines in Step ST7211 that the keep alive transmission period timer has expired, the application continues to transmit "APP keep alive packets" in Step ST7213. Since the RRC / ECM state of the UE is the connected state, in Step ST7215, the NAS notifies the application of the local Ack.

[0498] On the other hand, a network-side entity, for example, an S-GW, controls the transmission of pseudo keep-alive packets (hereinafter also referred to as "local APP keep alive packets"). Upon receiving "APP keep alive information" that matches the RRC state at the Uu point with the connection state of the APP session, the S-GW generates a local APP keep alive packet and decides to send it to the application server.

[0499] The S-GW generates a local APP keep alive packet periodically or periodically, and as long as the EPS bearer is established, the local APP keep alive packet is generated periodically or periodically and sent to the application server.

[0500] In Step ST7205, the S-GW receives the “APP keep alive information” for setting the RRC state at the Uu point to match the connection state of the APP session. In Step ST7208, the S-GW determines whether or not the local APP keep alive packet transmission period timer (hereinafter, may be referred to as the “local keep alive transmission period timer”) has expired.

[0501] When determining that the local keep alive transmission period timer has expired, the S-GW transmits a local APP keep alive packet to the application server in Step ST7210.

[0502] The S-GW determines whether or not an EPS bearer has been established, and if it determines that an EPS bearer has been established, it continues to determine whether or not a local keep alive transmission period timer has expired in Step ST7212. If it determines that the local keep alive transmission period timer has expired, the S-GW transmits a local APP keep alive packet to the application server in Step ST7214.

[0503] Here, the APP server that has received the local APP keep alive packet may transmit a response signal (Ack) to the S-GW. The response signal may be a response message. When the application side terminates the session with the UE, the APP server may be configured not to transmit the response signal to the S-GW.

[0504] When the S-GW receives a response signal from the APP server in response to the local APP keep alive packet, the S-GW may determine that the session for the UE is continuing. On the other hand, when the S-GW does not receive a response signal from the APP server in response to the local APP keep alive packet, the S-GW may determine that the session for the UE has ended. When the S-GW determines that the session for the UE has ended, the S-GW may initiate a release process for the EPS bearer.

[0505] In Step ST7216, the eNB monitors whether or not data has been transmitted or received. If no data has been transmitted or received within a predetermined period, the eNB activates S1 release processing A in Step ST5134. If a setting is made to match the RRC state at the Uu point with the connection state of the APP session, the eNB sets the data monitor timer to a longer period in Step ST7216. It is preferable to set the data monitor timer to a longer period than the data monitor timers shown in Step ST7101, Step ST7104, and Step ST7118 in FIG. 31 and FIG. 32.

[0506] The radio bearer, S1 bearer, and EPS bearer are released by S1 release procedure A in Step ST5134. In Step ST5101, the UE moves to the RRC / ECM_IDLE state. In Step ST5102, the eNB moves to the RRC_IDLE state with respect to the UE. In Step ST5103, the MME moves to the ECM_IDLE state with respect to the UE.

[0507] The UE may also monitor whether data has been transmitted or received. If no data has been transmitted or received within a predetermined period, the NAS of the UE may not notify the application of a local response even if it receives an "APP keep alive packet" from the application. This allows the application on the UE to recognize that the session has been terminated.

[0508] Furthermore, if no data is transmitted or received for a predetermined period of time, the UE notifies the MME of a request to stop transmitting local APP keep alive packets. The MME that has received the request to stop transmitting local APP keep alive packets may also notify the S-GW of a request to stop transmitting local APP keep alive packets. The S-GW that has received the request to stop transmitting local APP keep alive packets stops transmitting local APP keep alive packets. This makes it possible for the application on the APP server side to also terminate the session with the UE.

[0509] The UE, which has recognized that it has entered the RRC / ECM_IDLE state in Step ST5101, notifies the application in Step ST7218 that it has entered the RRC / ECM_IDLE state. This message is called a local release. The application that receives the local release determines that the RRC / ECM is not connected, and stops transmitting "APP keep alive packets." It may also disconnect the session.

[0510] On the other hand, the S-GW, which has recognized that the EPS bearer has been released, stops generating local APP keep alive packets (hereinafter may be referred to as “local keep alive packets”) in Step ST7217.

[0511] In Step ST7219, the S-GW notifies the application server of an application session release (Local APP Session Release) message. The application session release message may include information about the reason for stopping the generation of local APP keep alive packets. Alternatively, a new application session release message may be provided for stopping the generation of local APP keep alive packets. The application session release message for stopping the generation of local APP keep alive packets is referred to as a local application release. The application server that receives the application release message may determine that an EPS bearer has not been established, and may disconnect the session. Alternatively, the session may be restarted.

[0512] By using the above method, the RRC state at the Uu point can be made consistent with the connection state of the APP session, eliminating the need to change the RRC and RAB states as needed when a keep-alive packet is sent from the application at the Uu point.

[0513] Setting the data monitor timer in Step ST7216 to a long period of time makes it possible to reduce the frequency with which the S1 release procedure A in Step ST5134 is activated. This makes it possible to reduce the frequency with which the radio bearer, S1 bearer, and EPS bearer are released, and to reduce the signaling required to transition the RRC / ECM state in order to transmit an "APP keep alive packet" from the application. This makes it possible to suppress an increase in unnecessary signaling due to the generation of keep-alive packets from the application, and to reduce the impact on system resources.

[0514] Third embodiment, variant 1 The problem to be solved by the first modification of the third embodiment is the same as the problem in the third embodiment described above, and will be described below. In the third embodiment, the state of the RRC connection between the UE and the eNB is used, so the problem of a mismatch in the states between the UE and the eNB, as mentioned in the second embodiment above, may occur.

[0515] In order to solve the above-mentioned problem, in Modification 1 of Embodiment 3, the countermeasure proposed in the above-mentioned Embodiment 2 is applied to Embodiment 3. Figures 36 and 37 are diagrams showing an example of a sequence of a communication system in Modification 1 of Embodiment 3. Figures 36 and 37 are connected at the position of boundary line BL10. The sequences shown in Figures 36 and 37 are similar to the sequences shown in Figures 33 to 35, so the same step numbers are assigned to the same steps and common explanations will be omitted.

[0516] In Steps ST5101 to ST5104, Step ST7201, and Steps ST5129 to ST5130, an end-to-end service is executed between the UE and the application server, and application data is communicated from the UE to the application server.

[0517] In this modification, the method disclosed in the above-described third embodiment is used, and therefore, as the service request process, service request process B using "APP keep alive information" is performed in step ST7201. Figures 36 and 37 show a sequence when the "APP keep alive information" is set so that the RRC state at the Uu point and the connection state of the APP session are consistent with each other.

[0518] As disclosed in the third embodiment, the UE does not transmit, at point Uu, a keep-alive packet for which a transmission request has been made by an application. Also, a network side entity, for example, an S-GW, controls the transmission of local APP keep-alive packets. For this reason, the processes of steps ST7206 to ST7215 are performed.

[0519] In the above-described third embodiment, after data transmission in step ST5130, the data monitor timer expires in step ST7216, and the RRC connection state between the UE and the eNB is maintained until the S1 release procedure is performed in step ST5134. In this state, the RRC connection state with the eNB may not be maintained normally due to some cause, such as the UE moving out of the eNB's coverage area or deterioration of reception quality at the UE. In such a case, the UE transitions its RRC state to RRC_IDLE, but the eNB remains in the RRC_CONNECTED state. This causes a problem of a state mismatch between the UE and the eNB.

[0520] Furthermore, when a state mismatch occurs between the UE and the eNB, the UE recognizes that it has entered the RRC_IDLE state and notifies the application that it has entered the RRC_IDLE state. The application that receives this notification determines that the RRC is not connected, stops sending "APP keep alive packets", and ends the session. In this way, the session is ended in the UE application. However, since the eNB maintains the RRC_CONNECTED state, the MME maintains the ECM_CONNECTED state, and the S-GW continues to generate and send local keep alive packets to the application server. Therefore, the application server recognizes that the session is connected. In this way, a state mismatch also occurs between the application on the UE side and the application server.

[0521] In the above-mentioned second embodiment, in order to solve the problem of such state mismatch, a method was disclosed in which a message for notifying the state of the UE during the RRC connection at the Uu point is provided, and the UE periodically or cyclically transmits a "Uu keep alive indication" when in the RRC_CONNECTED state.

[0522] In this modification, the countermeasure proposed in this Embodiment 2 is applied. In the example shown in Fig. 36 and Fig. 37, after data transmission in Step ST5130, the UE in the RRC_CONNECTED state periodically notifies the eNB of a "Uu keep alive indication" as shown in Steps ST7301 to ST7305. By notifying the eNB of the "Uu keep alive indication", the UE indicates to the eNB that it has not yet transitioned to RRC_IDLE, that is, that it is in the RRC_CONNECTED state.

[0523] By receiving a "Uu keep alive indication" from the UE, the eNB recognizes that the UE has not yet transitioned to RRC_IDLE, i.e., is in the RRC_CONNECTED state. The eNB determines the state of the RRC connection with the eNB based on whether or not it has received a "Uu keep alive indication" from the UE. The eNB determines whether or not it has received a "Uu keep alive indication" from the UE at the timing of the "Uu keep alive indication" transmission cycle.

[0524] In Step ST7304, the UE transmits a "Uu keep alive indication" to the eNB. However, for some reason, the RRC connection state between the UE and the eNB may not be maintained normally, and the "Uu keep alive indication" may not reach the eNB. In this case, in Step ST5205, the eNB will not receive the "Uu keep alive indication" at the timing of the "Uu keep alive indication" transmission cycle. Therefore, the eNB recognizes that the UE has not maintained a normal RRC connection state between the eNB and the UE for some reason, and activates S1 release procedure A in Step ST5134.

[0525] When the S1 release procedure is performed in Step ST5134, the UE transitions to the RRC_IDLE state in Step ST5101. The eNB transitions to the RRC_IDLE state for the UE in Step ST5102. The MME transitions to the ECM_IDLE state for the UE in Step ST5103. In the S1 release procedure, the eNB and MME release system resources for the UE.

[0526] The UE, which has recognized that it has entered the RRC / ECM_IDLE state in Step ST5101, notifies the application that it has entered the RRC / ECM_IDLE state in Step ST7218. The application that has received the local release determines that the RRC / ECM is not connected, and stops transmitting the "APP keep alive packet." It may also disconnect the session.

[0527] The S-GW, which has recognized that the S1 release procedure has been performed in Step ST5134 and that the EPS bearer has been released, stops generating local APP keep alive packets in Step ST7217.

[0528] In Step ST7219, the S-GW notifies the application server of a local application session release message. The application server that receives the local application release message may determine that the EPS bearer has not been established and may disconnect the session.

[0529] The method disclosed in this embodiment allows E-UTRAN to recognize the RRC connection state of the UE, thereby eliminating the period of state inconsistency that occurs in the method disclosed in the third embodiment. This makes it possible to significantly reduce the impact of the state inconsistency. For example, it makes it possible to eliminate unnecessary consumption of resources for the UE in the eNB. It also makes it possible to reduce the frequency of occurrence of a state in which calling to the UE is not possible.

[0530] In the examples shown in FIGS. 36 and 37, the UE transitions to the RRC / ECM_IDLE state in Step ST5101 as a result of the S1 release procedure in Step ST5134. As another method, when a UE in the RRC_CONNECTED state transitions to the RRC_IDLE state for some reason such as deterioration in reception quality, the UE may determine that it has transitioned to the RRC_IDLE state and notify the application in the UE of a local release message. When the UE transitions to the RRC_IDLE state, the UE may also determine that it has transitioned to the ECM_IDLE state at the same time. In this case, the UE transitions to the RRC / ECM_IDLE state before the S1 release procedure in Step ST5134, and the application in the UE stops transmitting "APP keep alive packets" or disconnects the session.

[0531] In this case, the period of the status mismatch occurring in the method disclosed in the third embodiment can be kept within the "Uu keep alive indication" transmission period at most. Therefore, it is possible to significantly reduce the impact of the status mismatch. For example, it is possible to reduce unnecessary consumption of resources for the UE in the eNB and reduce the frequency of occurrence of a state in which calling the UE is not possible.

[0532] Embodiment 4 The problem to be solved in the fourth embodiment is the same as the problem to be solved in the third embodiment described above, and will be explained below.

[0533] In the above-described third embodiment, since it is desired to make the state of the RRC connection consistent with the state of the application-level session, it is necessary to maintain the RRC connection while the application-level session is connected. This is highly effective in avoiding the influence of keep-alive packets, but at the cost of using radio resources to maintain the RRC connection.

[0534] The solution to the above problem in the fourth embodiment is as follows. To solve the above problem, a Uu point message (uu keep alive packet) is provided to notify the connection state of an application session in the RRC_IDLE state. The UE, when transitioned to the RRC_IDLE state, periodically or periodically transmits the "uu keep alive packet." The eNB recognizes the connection state of the UE's application session from receiving the "uu keep alive packet" from the UE and the RRC state for the UE, and notifies some network device, for example, the S-GW, of this information. The S-GW, which is the network device that receives the notification, controls the transmission of local APP keep alive packets. The "uu keep alive packet" is transmitted only when the UE is in RRC_IDLE. The RRC state is not changed when the "uu keep alive packet" is transmitted. In other words, in IDLE, the notification is made without opening an RRC connection. For example, the notification is made using the RACH. As in the third embodiment described above, the UE does not transmit keep-alive packets requested for transmission by an application over the Uu point.

[0535] Figures 38 and 39 are diagrams showing an example of a sequence of a communication system in embodiment 4. Figures 38 and 39 are connected at the position of boundary line BL11. The sequences shown in Figures 38 and 39 are similar to the sequences shown in Figures 33 to 35, so the same step numbers are assigned to the same steps and common explanations will be omitted.

[0536] In Steps ST5101 to ST5104, Step ST7201, and Steps ST5129 to ST5130, an end-to-end service is executed between the UE and the application server, and application data is communicated from the UE to the application server.

[0537] In this modification, the method disclosed in the above-described third embodiment is used, and therefore, as the service request process, service request process B using "APP keep alive information" is performed in step ST7201. Figures 38 and 39 show a sequence when the "APP keep alive information" is set so that the RRC state at the Uu point and the connection state of the APP session are matched.

[0538] As disclosed in the third embodiment, the UE does not transmit, at point Uu, a keep-alive packet for which a transmission request has been made by an application. Also, a network side entity, for example, an S-GW, controls the transmission of local APP keep-alive packets. For this reason, the processes of steps ST7206 to ST7215 are performed.

[0539] In the above-described third embodiment, since it is desired to make the state of the RRC connection coincide with the state of the application-level session, it is necessary to maintain the RRC connection while the application-level session is connected. Therefore, after data transmission in Step ST5130 is performed, the state of the RRC connection between the UE and the eNB is maintained until the data monitoring timer expires in Step ST7216 and an S1 release procedure is performed in Step ST5134. This has a significant effect in avoiding the influence of keep-alive packets, but at the cost of using radio resources to maintain the RRC connection.

[0540] This embodiment discloses a method for improving such a problem. After data transmission in Step ST5130 in FIG. 38 is performed, the eNB, whose RRC connection with the UE is in an RRC_CONNECTED state, monitors whether or not data is generated for the UE for a predetermined period. Alternatively, it may monitor whether or not an individual radio bearer with the UE is necessary. A timer may be provided as means for measuring the predetermined period. Hereinafter, this timer will be referred to as an "RRC data monitoring timer."

[0541] If no data is generated for the UE in Step ST7402 and the RRC data monitoring timer expires, the eNB starts a procedure to release the RRC connection in Step ST7403. As a result of this procedure, the eNB and the UE transition to the RRC_IDLE state in Steps ST7404 and ST7405.

[0542] In the above process, only the RRC connection state between the UE and the eNB is transitioned from the RRC_CONNECTED state to the RRC_IDLE state, which allows the UE and the eNB to release the radio resources for the RRC connection.

[0543] Although it has been disclosed that the UE transitions to the RRC_IDLE state in response to an RRC connection release message from the eNB, as another method, the UE may also monitor whether data is generated at the eNB. Alternatively, the UE may monitor whether an individual radio bearer with the eNB is required. If no data is generated and the RRC data monitoring timer on the UE side expires, the UE initiates an RRC connection release procedure and transitions to the RRC_IDLE state. Alternatively, the UE may transition to the RRC_IDLE state in accordance with RRC specifications. Examples of RRC specifications include RLF (Residual Link Failure).

[0544] In this embodiment, the UE that has transitioned to the RRC_IDLE state in step ST7404 does not notify the application that it has entered the RRC_IDLE state. Alternatively, the UE that has transitioned to the RRC_IDLE state may notify the application that it has entered the RRC_IDLE state, but the application may not stop transmitting "APP keep alive packets" or disconnect the session when it receives the notification that it has entered the RRC_IDLE state. The notification of the transition to the RRC_IDLE state may include information indicating that only the RRC state has transitioned to the RRC_IDLE state. Alternatively, the notification may include information indicating which state, such as the RRC state or the ECM state, has transitioned to IDLE in the UE. Alternatively, the notification may include information indicating which bearer, such as the radio bearer, the S1 bearer, or the EPS bearer, has been released. Based on the information, the application in the UE can determine whether to stop transmitting "APP keep alive packets" or disconnect the session.

[0545] The UE that has transitioned to the RRC_IDLE state in Step ST7404 transmits a "uu keep alive packet" to the eNB in ​​Step ST7207 in order to notify the eNB that the application session is connected. The UE continues to transmit the "uu keep alive packet" periodically in Steps ST7406 to ST7408 as long as the application session is connected.

[0546] The eNB determines the RRC state and receives a "uu keep alive packet" in the RRC_IDLE state, thereby becoming aware of the connection state of the UE application session. When the UE application session is in a connected state, the eNB does not perform S1 release processing or other S1 bearer and EPS bearer release processing. Since the S1 release processing is not performed, the S-GW generates a local keep alive packet and notifies the application server. This allows the application server to recognize the connection with the UE and maintain the session in a connected state.

[0547] The "uu keep alive packet" is transmitted only when the UE is in RRC_IDLE, but the RRC state does not change when the "uu keep alive packet" is transmitted. In other words, when the UE is in IDLE, the notification is made without establishing an RRC connection. For example, the notification is made using RACH. This eliminates the need to transition the RRC state when transmitting the "uu keep alive packet," making it possible to reduce the amount of signaling.

[0548] When the application session is in a connected state, the UE transmits a "uu keep alive packet" to the eNB in ​​Step ST7409. However, for some reason, the "uu keep alive packet" may not reach the eNB. For example, this occurs when the UE moves out of the coverage area of ​​the eNB. In this case, in Step ST7410, the eNB will not be able to receive the "uu keep alive packet" at the timing of the "uu keep alive packet" transmission cycle.

[0549] Therefore, the eNB recognizes that the UE is unable to establish an RRC connection between the eNB and the UE for some reason, and activates an S1 release procedure A in Step ST5134.

[0550] In addition to the existing S1 release procedure, a new message may be provided by the eNB to notify the S-GW of the transition of the UE to the RRC_IDLE state.

[0551] A specific example of the newly provided message is a message for performing an S1 bearer release process without RRC connection process when the eNB has released the radio resources for the UE. Alternatively, in the existing S1 release process, information indicating whether or not there are radio resources for the UE may be newly provided. The information may be an active flag.

[0552] When S1 release procedure A is performed in Step ST5134, the UE transitions to the RRC / ECM_IDLE state in Step ST5101. In Step ST5102, the eNB maintains the RRC_IDLE state for the UE. In Step ST5103, the MME transitions to the ECM_IDLE state for the UE. In the S1 release procedure, the eNB and MME release system resources for the UE.

[0553] The UE, which has recognized that it has entered the RRC / ECM_IDLE state in Step ST5101, notifies the application that it has entered the RRC / ECM_IDLE state in Step ST7218. The application that has received the local release determines that the RRC / ECM is not connected and stops transmitting the "APP keep alive packet." It may also disconnect the session.

[0554] In Step ST5134, the S-GW has recognized that the S1 release procedure has been performed and the EPS bearer has been released, and in Step ST7217, the S-GW stops generating local APP keep alive packets.

[0555] In Step ST7219, the S-GW notifies the application server of a local application session release message. The application server that receives the local application release message may determine that the EPS bearer has not been established and may disconnect the session.

[0556] The method disclosed in this embodiment allows the UE to transition to RRC_IDLE while keeping the application session connected. This eliminates the need to maintain an RRC connection between the UE and the eNB, thereby reducing the use of unnecessary radio resources.

[0557] In the method disclosed in this embodiment, it is necessary to transmit a "uu keep alive packet" in the RRC_IDLE state, and therefore radio resources are used for the transmission. Therefore, it is advisable to appropriately select a method from among the methods disclosed in the other embodiments depending on the operational situation.

[0558] Fourth embodiment, variant 1 The problem to be solved by the first modification of the fourth embodiment is the same as the problem in the fourth embodiment described above, and will be described below. In the fourth embodiment as well, the state of the RRC connection is used until the RRC connection release process is performed due to expiration of the RRC data monitor timer, so the problem of a state mismatch between the UE and the eNB, as mentioned in the second embodiment, may occur. In addition, the application level session state is determined from two pieces of information: information from the "uu keep alive packet" in IDLE mode and the RRC state, which makes implementation complicated.

[0559] In order to solve the problem in the first modification of the fourth embodiment, the countermeasure proposed in the second embodiment described above is applied to the fourth embodiment. Note that, as in the second embodiment described above, the DRX length should not be changed by transmitting a "Uu keep alive indication" in the RRC_CONNECTED state. Furthermore, the transmission of a "Uu keep alive indication" in the RRC_CONNECTED state and the RRC data monitor timer are operated independently. That is, regardless of the RRC connection state, the UE notifies the eNB that an application session is connected by notifying a "Uu keep alive indication" or a "Uu keep alive packet." In the RRC_CONNECTED state, the "Uu keep alive indication" is used, and in the RRC_IDLE state, the "Uu keep alive packet" is used. The "Uu keep alive indication" and the "Uu keep alive packet" may be used as a message with the same name, for example, "Uu keep alive," and may be usable regardless of the RRC connection state.

[0560] Figures 40 and 41 are diagrams showing an example of a sequence of a communication system in Variation 1 of Embodiment 4. Figures 40 and 41 are connected at the position of boundary line BL12. The sequences shown in Figures 40 and 41 are similar to the sequences shown in Figures 38 and 39, so the same step numbers are assigned to the same steps and common explanations will be omitted.

[0561] In service request procedure B in Step ST7201, the UE and the eNB transition to the RRC_CONNECTED state and the ECM_CONNECTED state.

[0562] In Step ST5130, an end-to-end service is executed between the UE and the application server, and application data is communicated from the UE to the application server.

[0563] In Step ST7501, in order to maintain the connection of the application session, the UE transmits a "Uu keep alive indication" in the RRC_CONNECTED state to the eNB, and notifies the eNB that the application session is connected.

[0564] In order to notify the eNB that the application session is connected, the UE in the RRC_CONNECTED state continuously and periodically transmits a "Uu keep alive indication" to the eNB. Upon receiving this indication, the eNB recognizes that the application session is connected.

[0565] Therefore, while the eNB receives the notification, it does not perform release processing of the S1 bearer and the EPS bearer, such as the S1 release processing. Since the S1 release processing is not performed, the S-GW generates a local keep alive packet and notifies the application server. This allows the application server to recognize the connection with the UE and keep the session connected.

[0566] Meanwhile, the eNB monitors whether data is being sent to the UE for a predetermined period of time. Alternatively, the eNB may monitor whether an individual radio bearer with the UE is required. A timer may be provided as a means for measuring the predetermined period of time. Hereinafter, this timer will be referred to as an "RRC data monitoring timer."

[0567] If no data is generated for the UE and the RRC data monitoring timer expires in Step ST7505, the eNB activates a procedure to release the RRC connection in Step ST7506. By this procedure, the radio bearer between the eNB and the UE is released, and the UE and the eNB transition to the RRC_IDLE state in Steps ST7404 and ST7405.

[0568] In the above process, only the RRC connection state between the UE and the eNB is transitioned from the RRC_CONNECTED state to the RRC_IDLE state, which allows the UE and the eNB to release the radio resources for the RRC connection.

[0569] Although it has been disclosed that the UE transitions to the RRC_IDLE state in accordance with the RRC connection release message from the eNB, as another method, the UE may also monitor whether or not data is generated at the eNB. Alternatively, the UE may monitor whether or not an individual radio bearer with the eNB is required. In Step ST7404, if no data is generated and the RRC data monitoring timer on the UE side expires, the UE starts the RRC connection release procedure and transitions to the RRC_IDLE state. Alternatively, the UE may transition to the RRC_IDLE state in accordance with RRC specifications. Examples of RRC specifications include RLF (Residual Link Failure).

[0570] In Step ST7406, the UE that has transitioned to the RRC_IDLE state transmits a "Uu keep alive packet" in the RRC_IDLE state to the eNB in ​​order to maintain the connection of the application session, thereby notifying the eNB that the application session is connected. In order to notify the eNB that the application session is connected, the UE in the RRC_CONNECTED state continues to periodically transmit a "Uu keep alive indication" to the eNB. By receiving this notification, the eNB recognizes that the application session is connected.

[0571] Therefore, while the eNB receives the notification, it does not perform release processing of the S1 bearer and the EPS bearer, such as the S1 release processing. Since the S1 release processing is not performed, the S-GW generates a local keep alive packet and notifies the application server. This allows the application server to recognize the connection with the UE and keep the session connected.

[0572] In Step ST7409, the process when the eNB confirms that the "keep alive packet" has not been delivered can be carried out in accordance with the fourth embodiment described above, and therefore a description thereof will be omitted here.

[0573] The method disclosed in this embodiment reduces the state mismatch between the UE and the eNB, thereby reducing the impact on system resources. Also, the eNB can determine the application-level session state only based on a message notifying that the application session is connected, specifically, "uu keep alive indication" in the RRC_CONNECTED state and "uu keep alive packet" in the RRC_IDLE state, which makes implementation easier.

[0574] In the method disclosed in this embodiment, it is necessary to transmit the "uu keep alive indication" and the "uu keep alive packet" in the RRC_IDLE state and the RRC_CONNECTED state, and therefore the radio resources are used for the transmission. Therefore, it is advisable to appropriately select a method from among the methods including those of the other embodiments depending on the operational situation.

[0575] Embodiment 5. The problem to be solved in the fifth embodiment is the same as the problem in the third embodiment, the first modification of the third embodiment, the fourth embodiment, and the first modification of the fourth embodiment, and will be described below.

[0576] In the above-described embodiment and variants, the "uu keep alive" message at point Uu is used to address the problem caused by the keep-alive packets that are transmitted periodically, but this results in the use of radio resources for maintaining the RRC connection.

[0577] In order to solve the above problem, this embodiment discloses a method of using "uu keep alive," which is a message at the Uu point, and not maintaining an RRC connection.

[0578] The eNB and the UE monitor whether data is generated within a predetermined period. The eNB and the UE have a session connection determination function that determines that the application-level session is disconnected if no data is generated within the predetermined period, and determines that the session is connected if data is generated within the predetermined period.

[0579] The eNB notifies a network device, for example, an S-GW, of session connection status information. The S-GW, which is the network device that has received the notification of the session connection status information, controls transmission of local APP keep alive packets.

[0580] Figures 42 and 43 are diagrams showing an example of a sequence of a communication system in embodiment 5. Figures 42 and 43 are connected at the position of boundary line BL13. The sequences shown in Figures 42 and 43 are similar to the sequences shown in Figures 38 and 39, so the same step numbers are assigned to the same steps and common explanations will be omitted.

[0581] After the data transmission in Step ST5130, the eNB whose RRC connection to the UE is in the RRC_CONNECTED state monitors whether or not data is generated for the UE. As disclosed in the above-mentioned fourth embodiment, if no data is generated for the UE within a predetermined period and the RRC data monitoring timer expires, in Steps ST7404 and ST7405, the eNB and the UE transition to the RRC_IDLE state.

[0582] In the above process, only the RRC connection state between the UE and the eNB is transitioned from the RRC_CONNECTED state to the RRC_IDLE state, which allows the UE and the eNB to release the radio resources for the RRC connection.

[0583] In this embodiment, unlike the fourth embodiment described above, a UE that has transitioned to the RRC_IDLE state does not transmit "uu keep alive," which is a message at the Uu point for notifying a session connection, to an eNB.

[0584] In this embodiment, the UE and the eNB monitor whether data is generated within a predetermined period. The eNB and the UE have a session connection determination function that determines that the application-level session is disconnected if no data is generated within the predetermined period, and determines that the session is connected if data is generated within the predetermined period.

[0585] The eNB and UE are configured to monitor whether data is generated during a predetermined period, but may also monitor whether an S1 bearer is required for the UE. Also, it may monitor whether an ECM_CONNECTED state is required for the UE. A timer may be provided as a means for measuring the predetermined period. Hereinafter, this timer is referred to as the "NAS data monitoring timer." The UE may have the session connection function as a NAS function. Alternatively, it may have the session connection function as an AS function. If the session connection function is an AS function, when the NAS data monitoring expires, the AS may notify the NAS of this fact. The eNB may have the session connection function as an AS function.

[0586] The UE monitors whether data is generated, and if the NAS data monitoring timer expires in Step ST7601, the UE transitions to the RRC / ECM_IDLE state in Step ST5101. The UE, which has recognized that it has entered the RRC / ECM_IDLE state in Step ST5101, notifies the application that it has entered the RRC / ECM_IDLE state in Step ST7218.

[0587] An application that receives a local release determines that the RRC / ECM is not connected, and stops sending "APP keep alive packets." It may also disconnect the session.

[0588] The eNB monitors whether or not data is generated, and when the NAS data monitoring timer expires in Step ST7602, the eNB activates the S1 release process A in Step ST5134.

[0589] When S1 release procedure A is performed in Step ST5134, the eNB maintains the RRC_IDLE state for the UE in Step ST5102. In Step ST5103, the MME transitions to the ECM_IDLE state for the UE. In the S1 release procedure, the eNB and MME release system resources for the UE.

[0590] The S-GW, which has recognized that the S1 release process A has been performed in Step ST5134 and that the EPS bearer has been released, stops generating local APP keep alive packets in Step ST7217.

[0591] In Step ST7219, the S-GW notifies the application server of a local application session release message. The application server that receives the local application release message may determine that the EPS bearer has not been established and may disconnect the session.

[0592] In the above method, it is disclosed that the UE and the eNB have a session connection determination function. Alternatively, the UE may not have the session connection determination function, and the eNB may have the session connection determination function. In this case, the eNB monitors whether data is generated, and when the NAS data monitoring timer expires, it initiates the S1 release procedure.

[0593] By performing the S1 release procedure, the UE transitions to the RRC / ECM_IDLE state. When the UE recognizes that it has entered the RRC / ECM_IDLE state, it notifies the application that it has entered the RRC / ECM_IDLE state. When the application receives the local release, it determines that the RRC / ECM is not connected and stops sending "APP keep alive packets." It may also disconnect the session.

[0594] This eliminates the need for the UE to monitor NAS data, simplifying control.

[0595] The method disclosed in this embodiment makes it possible to determine whether a session should be established or not without using "uu keep alive," a message at the Uu point for notifying a session establishment, and without maintaining an RRC connection. This makes it possible to reduce the amount of radio resources used. Furthermore, because transitions in the RRC connection state and transitions in the application session connection state can be controlled only by data monitor timers such as an RRC data monitor timer and an NAS data monitor timer, implementation is easy.

[0596] Furthermore, the NAS data monitor timer disclosed in this embodiment may be made to match the session timer of the application. The UE may notify the eNB of the session timer. This allows the connection control time of the application to match the connection control time of the communication system, thereby reducing malfunctions of the system. Matching the NAS data monitor timer with the session timer of the application can also be applied to other embodiments, including modified examples.

[0597] In addition, the method disclosed in this embodiment is more effective when used taking into account the characteristics of the application, such as for applications that are not expected to connect frequently and for which the NAS data monitor timer value can be set short.

[0598] Embodiment 6 The problem to be solved in the sixth embodiment will be described below. The same problem as in the third embodiment occurs with applications that are always running and periodically send and receive relatively small amounts of data, such as instant messaging and SNS (Social Networking Service). In this case, it is necessary to transmit information to a server or the like that is the actual destination, and the solutions in the third to fifth embodiments cannot be used as they are.

[0599] For example, Non-Patent Documents 15 and 16 propose a concept of transmitting user data using a NAS signaling bearer without establishing a dedicated radio access bearer. In this proposal, when end-to-end communication is between a UE and a server in a certain PDN (Public Data Network), a data transmission session is set up between a P-GW corresponding to the PDN and an MME in which the target UE resides, and communication is performed using a data transmission path and a NAS signaling bearer.

[0600] A conceptual diagram is shown in Figure 1(a) of Non-Patent Document 15. Furthermore, communication in the configuration of Figure 1(a) is considered to be connection-lite communication, and communication in the configuration of Figure 1(b) is considered to be connection-oriented communication.

[0601] Figure 1 of Non-Patent Document 16 discloses a procedure for connecting to a PDN that is set when Figure 1(a) of Non-Patent Document 15 is applied and executed. Here, in response to a PDN connection request from a UE, a session is established in an IP connection access network (IP-CAN).

[0602] The aforementioned Non-Patent Document 15 suggests using connection-lite and connection-oriented together. According to Non-Patent Document 15, when it is desired to transmit large data that should not be transmitted via connection-lite, it suggests transmitting it via a normal transmission path (connection-oriented).

[0603] However, the method for achieving this, for example, how to switch between connection-lite and connection-oriented, is not clearly stated. Therefore, it is impossible to switch between connection-lite and connection-oriented, which creates the problem of being unable to build a stable communication system.

[0604] The solution in the sixth embodiment is described below. In this embodiment, a method for switching between connection-lite and connection-oriented is disclosed. The UE, P-GW, or S-GW determines whether to transmit in connection-lite or connection-oriented. As specific examples of the determination method, the following three methods (1) to (3) are disclosed.

[0605] (1) Make a decision based on the data. Specifically, make a decision based on the size of the data. (2) Make a decision based on the situation. (3) A combination of (1) and (2) above.

[0606] The switching between connection-lite and connection-oriented may be the same when the UE transmits data and when the APP server transmits data, or may be different. A specific example of different switching modes is when the UE transmits data using connection-lite and when the APP server transmits data using connection-oriented.

[0607] As specific examples of methods for making judgments based on data, the following two methods (1) and (2) are disclosed. (1) If the amount of data is greater than the threshold, it is determined to transmit in connection-oriented mode, and if it is less than the threshold, it is determined to transmit in connection-lite mode.

[0608] (2) If the traffic volume is greater than a threshold, it is determined to transmit in connection-oriented mode, and if it is equal to or less than the threshold, it is determined to transmit in connection-lite mode. It may also be determined whether the traffic is small. A specific example of traffic volume is the amount of data per unit time. As disclosed in Non-Patent Document 16, when determining based on data volume, there is a possibility that switching between connection-lite and connection-oriented occurs on a packet-by-packet basis. On the other hand, when determining based on traffic volume, there is no switching between connection-lite and connection-oriented during the unit time, which has the effect of reducing control overhead.

[0609] The threshold values ​​disclosed above may be different between the UE and the P-GW or S-GW. Different threshold values ​​may be used for uplink and downlink. The amount of data or traffic treated as small data can be optimized for the configuration within the P-GW or S-GW and the configuration within the UE. The amount of data or traffic treated as small data can be optimized according to the load conditions for uplink and downlink.

[0610] Hereinafter, data determined to be transmitted in connection-oriented mode may be referred to as normal size data. Data determined to be transmitted in connection-lite mode may be referred to as small size data or small data.

[0611] As specific examples of methods for determining the thresholds, for example, the threshold for the amount of data and the threshold for the amount of traffic, the following nine methods (1) to (9) are disclosed.

[0612] (1) The threshold may be determined depending on the application. The threshold may be determined depending on the connection destination requested by the application. The NAS of the UE, the P-GW, or the S-GW may determine the threshold based on the QoS, QCI, bearer information, etc. requested by the application.

[0613] (2) The eNB and MME may be determined based on the state of the communication system between the eNB and MME. The state of the communication system of the S1 interface may also be used. Specific examples of the state of the communication system include a statically determined maximum transmission capacity and a load situation.

[0614] (3) The MME and S-GW may be determined based on the state of the communication system between the MME and S-GW. The state of the communication system of the S11 interface may also be used. Specific examples of the state of the communication system include a statically determined maximum transmission capacity and a load status.

[0615] (4) It may be determined depending on an operator policy. It may be determined depending on a small data transmission policy. The small data transmission policy may be set by an operator.

[0616] (5) It may be determined based on the state of the communication system of the S5 / S8 interface, which is the interface between the S-GW and the P-GW. It may be determined by the P-GW or the S-GW.

[0617] (6) May be decided by OAM. (7) Determined based on UE capabilities. (8) A combination of (1) to (7) above. (9) Statically determined.

[0618] As specific examples of threshold notification methods, the following eight methods (1) to (8) are disclosed. (1) No notification. When using threshold determination method (1), the UE and the S-GW or P-GW each determine the threshold depending on the same application. Notification is also not required when using threshold determination method (5). Notification method (1) is effective compared to the following notification methods (2) to (4) in that it does not require consideration of communication errors and reduces the control load.

[0619] (2) The eNB notifies the determined value to the UE and the S-GW or P-GW. (3) The MME notifies the UE and the S-GW or P-GW of the determined value. (4) The value determined by the S-GW is notified to the UE and P-GW. This may be notified using TFT (Traffic Flow Templates). By notifying the small data transmission policy and threshold using TFT, the following effects can be obtained. The small data transmission policy and the threshold that determines whether the data is small and should be transmitted via connection-lite or normal-sized data and should be transmitted via connection-oriented can be notified together. Since the "small data transmission policy" and "threshold" required to determine whether to use connection-lite or connection-oriented can be received together, processing becomes easier.

[0620] (5) The P-GW notifies the UE of the determined value. This may be notified using TFT (Traffic Flow Templates). By notifying the small data transmission policy and threshold using TFT, the following effects can be obtained. The small data transmission policy and the threshold that determines whether the data is small and should be transmitted via connection-lite or normal-sized data and should be transmitted via connection-oriented can be notified together. Since the "small data transmission policy" and the "threshold" required to determine whether to use connection-lite or connection-oriented can be received together, processing becomes easier.

[0621] (6) The operator notifies the P-GW or S-GW and the UE of the determined value. (7) The OAM notifies the determined value to the P-GW or S-GW and the UE. (8) When exchanging a small data transmission policy between network entities and a UE, a threshold value is also exchanged. Since both the "small data transmission policy" and the "threshold value" required to determine whether to use connection-lite or connection-oriented can be received, processing becomes easier.

[0622] A specific example of a method for making a determination depending on the state is disclosed below. Whether to perform connection-lite communication or connection-oriented communication is determined based on the ECM connection state and RRC connection state with the target UE. Even if an EPS bearer is established, it may be in the ECM_IDLE state or the RRC_IDLE state. Therefore, the method using the ECM connection state and RRC connection state with the target UE as the switching determination criterion can prevent the need for a lot of signaling for bearer connection compared to the method using whether an EPS bearer is established as the switching determination criterion.

[0623] A specific example is explained below. When ECM_CONNECTED and RRC_CONNECTED are in effect, it is advisable to perform communication in a connection-oriented manner. It is advisable to perform communication in a connection-oriented manner regardless of the amount of data or traffic generated. Even when small data is generated, communication is performed in a connection-oriented manner.

[0624] In the case of ECM_IDLE or RRC_IDLE, it is preferable to perform connection-lite communication when small data occurs, and to perform connection-oriented communication when normal data occurs. Even if an EPS bearer has been established, in the case of ECM_IDLE, S1-U or RRC is not necessarily in a connected state. Therefore, by performing connection-lite communication when small data occurs, it is possible to reduce the signaling required for U-plane connection. Furthermore, connection-lite communication in the case of RRC_IDLE may be performed without transitioning to the RRC_CONNEXTED state. This eliminates the need to initiate the RRC connection setup procedure. Specific methods include, for example, transmitting small data using a RACH procedure or transmitting small data using a paging procedure. The method of transmitting small data using a RACH procedure is the same as that of Variant 4 of the first embodiment, and therefore a description thereof will be omitted. The method of transmitting small data using a paging procedure is the same as that of Variant 5 of the first embodiment, and therefore a description thereof will be omitted.

[0625] The above disclosed criteria may be added to the small data transmission policy and maintained by the UE and the S-GW or the P-GW. Separate from the small data transmission policy, the UE and the S-GW or the P-GW may also have a data transmission policy.

[0626] In the above description, it has been disclosed that the determination of whether to perform connection-lite communication or connection-oriented communication is based on the ECM connection state and RRC connection state with the target UE, but this is not limiting, and the determination of whether to perform connection-lite communication or connection-oriented communication may also be based on the establishment state of the S1-U bearer and the establishment state of the radio bearer with the target UE. This can be achieved by replacing the ECM connection state with the establishment state of the S1-U bearer and the RRC connection state with the establishment state of the radio bearer.

[0627] When a UE transmits data (also called MO), it must determine whether to communicate in connection-lite or connection-oriented mode. Therefore, the UE must be aware of the RRC state or ECM state.

[0628] The UE recognizes the RRC state. Conventionally, the RRC state and the ECM state match, so the UE can also recognize the ECM state. However, as disclosed in the fourth embodiment, the fifth embodiment, or the seventh embodiment described later, there are cases where the RRC state and the ECM state differ. In such cases, the UE cannot recognize the ECM state.

[0629] This problem can be solved by the following method: When the RRC state and the ECM state are different, the MME or eNB may notify the UE of information indicating the ECM state.

[0630] When the APP server sends data (also called MT), the P-GW or S-GW decides whether to communicate in connection-lite or connection-oriented mode. Therefore, the P-GW or S-GW needs to be aware of the RRC state or ECM state.

[0631] The S-GW recognizes the ECM state. Conventionally, the RRC state and the ECM state match, so the S-GW can also recognize the RRC state. However, as disclosed in the fourth embodiment, the fifth embodiment, or the seventh embodiment described later, there are cases where the RRC state and the ECM state differ. In such cases, the S-GW cannot recognize the RRC state.

[0632] This problem can be solved by the following method. When the RRC state and the ECM state are different, the eNB may notify the S-GW of information indicating the RRC state. Alternatively, the UE may notify the S-GW of information indicating the RRC state.

[0633] Furthermore, the P-GW is not necessarily aware of the RRC state and the ECM state. Information indicating the ECM state may be notified from the MME to the P-GW. Furthermore, information indicating the ECM state may be notified from the S-GW to the P-GW. Information indicating the RRC state may be notified from the eNB to the P-GW. Furthermore, information indicating the RRC state may be notified from the UE to the P-GW.

[0634] By doing this, the UE in the MO, and the P-GW or S-GW in the MT, can determine whether to communicate in connection-lite or connection-oriented mode.

[0635] The method for switching from connection-lite to connection-oriented is disclosed below. When the UE determines to transmit in connection-oriented mode in the connection-lite state, the UE initiates a service request procedure. This is the same as normal call processing, so it is possible to obtain the effect of preventing the communication system from becoming complicated.

[0636] In the Connection-lite state, if the network side such as the P-GW or S-GW decides to transmit in connection-oriented mode, the P-GW starts a dedicated bearer activation procedure (see Chapter 5.4.1 of Non-Patent Document 13). Since this is the same as normal incoming call processing, it is possible to obtain the effect of preventing the communication system from becoming complicated.

[0637] When switching from connection-lite to connection-oriented occurs, functions and settings for transmitting small data on S1-MME and S11 do not need to be deactivated. For example, functions and settings for including small data in NAS messages, functions and settings for including small data in GTP-C, etc. do not need to be deactivated. This eliminates the need for reconfiguration when signaling or switching back to connection-lite occurs, thereby reducing the processing load on the communication system.

[0638] Next, a specific example of a sequence of a communication system in the sixth embodiment will be described with reference to Figures 44 to 47. Figures 44 to 47 are diagrams showing an example of a sequence of a communication system in the sixth embodiment. Figures 44 and 45 are connected at the position of boundary line BL14. Figures 45 and 46 are connected at the position of boundary line BL15. Figures 46 and 47 are connected at the position of boundary line BL16. Figures 44 to 47 show a sequence in which, in a connection-lite state, a UE side transmits large amounts of data and transitions to a connection-oriented state.

[0639] First, step ST9101 to step ST9122 in FIG. 44 and FIG. 45 show a PDN connection procedure disclosed in Non-Patent Document 16 that is set when connection-lite is executed.

[0640] In Step ST9101, an application or TPC / IP of the UE makes an access request to the NAS.

[0641] In Step ST9102, the NAS of the UE starts a PDN establishment procedure. The PDN establishment procedure in Step ST9102 includes the processes of Steps ST9103 to ST9121.

[0642] In Step ST9103, the NAS of the UE transmits a PDN connectivity request message to the AS (Access Stratum). The NAS of the UE may notify the RRC layer.

[0643] In Step ST9104, the RRC layer of the UE starts an RRC connection setup procedure. The RRC connection setup procedure in Step ST9104 includes the processes of Steps ST9105 to ST9107.

[0644] In Step ST9105, the RRC layer of the UE transmits an RRC connection setup request message to the eNB.

[0645] In Step ST9106, the eNB, which has received the RRC connection setup request message in Step ST9105, transmits an RRC connection setup message to the RRC layer of the UE.

[0646] In Step ST9107, the UE that has received the RRC connection setup message in Step ST9106 transmits an RRC connection setup complete message to the eNB.

[0647] In Step ST9108, the RRC layer of the UE transmits a PDN connectivity request message to the eNB.

[0648] In Step ST9109, the eNB that has received the PDN connection request message in Step ST9108 transmits the PDN connection request message to the MME.

[0649] In Step ST9110, the MME transmits a create session request message to the S-GW.

[0650] In Step ST9111, the S-GW that has received the create session request message in Step ST9110 transmits the create session request message to the P-GW.

[0651] In Step ST9112, the P-GW executes session establishment of the IP connectivity access network (IP-CAN).

[0652] When the establishment of the IP-CAN session is completed in Step ST9112, in Step ST9113, the P-GW transmits a create session response message to the S-GW.

[0653] In Step ST9114, the S-GW that has received the create session response message in Step ST9113 transmits the create session response message to the MME.

[0654] In Step ST9115, the MME transmits an activate default bearer context request message to the eNB.

[0655] In Step ST9116, the eNB, which has received the activate default bearer context request message in Step ST9115, transmits an activate default bearer context request message to the UE.

[0656] In Step ST9117, the UE, which has received the activate default bearer context request message in Step ST9116, transmits an activate default bearer context response message to the eNB.

[0657] In Step ST9118, the eNB that has received the activate default bearer context response message in Step ST9117 transmits an activate default bearer context response message to the MME.

[0658] Then, using the aforementioned PDN connection procedure, a small data transmission policy is exchanged between the network side entities and the UE, which enables small data transmission between the UE and the application server via the eNB, MME, S-GW, and P-GW.

[0659] In Step ST9119, an S11 bearer is established between the MME and the S-GW. Small data can be transmitted over the S11 between the MME and the S-GW (S11(sml)).

[0660] In Step ST9120, an S5 / S8 bearer is established between the S-GW and the P-GW. Small data can be transmitted over the S5 / S8 between the S-GW and the P-GW (S5 / S8(sml)).

[0661] In Step ST9121, an S1 bearer is established between the eNB and the MME. Small data can be transmitted over the S1 between the eNB and the MME (S1(sml)).

[0662] This enables data to be transmitted from the UE to the application server (APP server) via the eNB, MME, S-GW, and P-GW in Step ST9122.

[0663] Hereinafter, this state may be referred to as a “connection-lite state.” It may be possible to transmit small amounts of data.

[0664] In Step ST9123 of FIG. 46, the application of the UE requests the NAS to transmit data of a normal size, and the transmission data is transmitted.

[0665] The NAS of the UE that has received normal-sized data in Step ST9123 determines in Step ST9124 whether to transmit in connection-lite or connection-oriented mode. Although not shown in the figure, the determination may be made depending on the above-mentioned state. Specifically, the NAS determines whether the data to be transmitted is small data or not. If it is determined in Step ST9124 that the data is small, it determines to transmit in connection-lite mode and moves to Step ST9125. If it is determined in Step ST9124 that the data is not small, it determines to transmit in connection-oriented mode and moves to Step ST9126.

[0666] In Step ST9125, the NAS of the UE transmits the transmission data in a connection-lite state. The transmission may be performed using a bearer opened for small data or a bearer that has been established in connection-lite mode (hereinafter, also referred to as a "Connection-lite bearer").

[0667] In Step ST9126, the NAS of the UE starts preparation for connection-oriented transmission. As a specific example, it starts a service request procedure C.

[0668] The service request processing C in step ST9126 includes the processing in steps ST9127 to ST9147.

[0669] In Step ST9127, the NAS of the UE transmits a service request message to the AS, and may notify the RRC layer.

[0670] The UE that has received the service request message in Step ST9127 starts an RRC connection setup procedure in Step ST9128. Details of the RRC connection setup procedure are the same as the process in Step ST9104 in FIG. 44, and therefore description thereof will be omitted.

[0671] In Step ST9132, the RRC layer of the UE transmits a service request message to the eNB.

[0672] In Step ST9133, the eNB that has received the service request message in Step ST9132 transmits a service request message to the MME.

[0673] In Step ST9134 of FIG. 47, the MME, which has received the service request message in Step ST9133, transmits an initial context setup request message to the eNB.

[0674] In Step ST9135, the eNB, which has received the initial context setup request message in Step ST9134, initiates a radio bearer establishment procedure.

[0675] The radio bearer establishment process of Step ST9135 includes the processes of Steps ST9136 to ST9137.

[0676] In Step ST9136, the eNB transmits an RRC connection reconfiguration message to the UE.

[0677] In Step ST9137, the UE that has received the RRC connection reconfiguration message in Step ST9136 transmits an RRC connection reconfiguration complete message to the eNB.

[0678] In Step ST9138, the eNB, which has received the RRC connection reconfiguration complete message in Step ST9137, transmits an initial context setup complete message to the MME.

[0679] In Step ST9139, the MME transmits a Modify Bearer Request message to the S-GW.

[0680] In Step ST9141, the S-GW that has received the modify bearer request message in Step ST9139 transmits a modify bearer request message to the P-GW.

[0681] In Step ST9142, the P-GW executes a session modification (IP-CAN Session Modification) of the IP connectivity access network (IP-CAN). The session modification of the IP-CAN may also be referred to as a "PCEF initiated IP-CAN Session Modification."

[0682] When the IP-CAN session change is completed in Step ST9142, in Step ST9143, the P-GW transmits a Modify Bearer Response message to the S-GW.

[0683] In Step ST9144, the S-GW that has received the modify bearer response message in Step ST9143 transmits a modify bearer response message to the MME.

[0684] In Step ST9145, an S1 bearer is established between the eNB and the S-GW.

[0685] In Step ST9146, an S5 / S8 bearer is established between the S-GW and the P-GW.

[0686] In Step ST9147, an EPS bearer is established between the UE and the P-GW.

[0687] As a result, in Step ST9148, it becomes possible to transmit data from the UE to the application server (APP Server) via the eNB, S-GW, and P-GW. Hereinafter, this state may also be referred to as a connection-oriented state. It may also be possible to transmit normal size data.

[0688] Next, a specific example of a sequence of the communication system in the sixth embodiment will be described with reference to Figures 48 and 49. Figures 48 and 49 are diagrams showing another example of a sequence of the communication system in the sixth embodiment. Figures 48 and 49 are connected at the position of boundary line BL17. The sequences shown in Figures 48 and 49 are similar to the sequences shown in Figures 44 to 47, so the same step numbers are used for the same steps and common explanations will be omitted. Figures 48 and 49 show the sequence when, in a connection-lite state, the network (NW) side transmits large amounts of data and transitions to a connection-oriented state.

[0689] In Step ST9201, the application server requests the P-GW to transmit data of a normal size, and the transmission data is transmitted.

[0690] The P-GW that has received normal-sized data in Step ST9201 determines in Step ST9202 whether to transmit it in connection-lite or connection-oriented. Specifically, it determines whether the data to be transmitted is small or not. Although not shown in the figure, it may be configured to make a determination according to the above-mentioned state. If it is determined in Step ST9202 that the data is small, it determines to transmit it in connection-lite and moves to Step ST9203. If it is determined in Step ST9202 that the data is not small, it determines to transmit it in connection-oriented and moves to Step ST9204.

[0691] In Step ST9203, the P-GW transmits the transmission data in a connection-lite state. The transmission may be performed using a connection lite bearer.

[0692] In Step ST9204, the P-GW starts preparation for connection-oriented transmission. As a specific example, the P-GW starts a dedicated bearer activation procedure.

[0693] The dedicated bearer activation procedure in Step ST9204 includes the processes of Steps ST9205 to ST9146.

[0694] In Step ST9205, the P-GW transmits a Create Bearer Request message to the S-GW.

[0695] In Step ST9206, the S-GW that has received the bearer creation request message in Step ST9205 transmits the bearer creation request message to the MME.

[0696] In Step ST9135, the MME, which has received the bearer creation request message in Step ST9206, starts a radio bearer establishment procedure.

[0697] In Step ST9208, the eNB transmits a bearer setup response message to the MME.

[0698] In Step ST9209, the UE transmits a "Direct Transfer" to the eNB, or may transmit a session management response message.

[0699] In Step ST9210, the eNB, which has received the session management response message in Step ST9209, transmits a session management response message to the MME.

[0700] In Step ST9211, the MME, which has received the session management response message in Step ST9210, transmits a create bearer response message to the S-GW.

[0701] In Step ST9212, the S-GW that has received the create bearer response message in Step ST9211 transmits the create bearer response message to the P-GW.

[0702] The above-described sixth embodiment can provide the following effects: It is possible to realize the combined use of connection-lite and connection-oriented. By determining the implementation method, it is possible to build a stable communication system.

[0703] Sixth embodiment, variant 1 The problems to be solved by the first modification of the sixth embodiment will be described below. When the sixth embodiment described above is carried out, the following problems arise.

[0704] For example, when the sequences shown in Figures 44 to 47 are executed, even though the connection is to the same application server, the establishment of an IP connection access network (IP-CAN) session will be set up twice, for example, in step ST9112 of Figure 45 and step ST9142 of Figure 47. This may result in unnecessary procedures being executed for the same application session. Furthermore, in some cases, this may cause a problem, as the PDN side may not allow the connection, regarding it as an invalid request.

[0705] In addition, in the connection-lite state, when normal-sized data is transmitted from both the UE and the NW, the following problem occurs.

[0706] Based on a service request from the UE, a radio bearer establishment procedure is initiated, and based on a create bearer request from the P-GW, a radio bearer is set up again, even though it is the same bearer.

[0707] A specific example of the problem of Modification 1 of Embodiment 6 will be described using Figures 50 and 51. Figures 50 and 51 are diagrams showing sequences for explaining the problem solved by Modification 1 of Embodiment 6. Figures 50 and 51 are connected at the position of boundary line BL18. The sequences shown in Figures 50 and 51 are similar to the sequences shown in Figures 44 to 47, 48 and 49, so the same step numbers are assigned to the same steps and common descriptions will be omitted.

[0708] In FIGS. 50 and 51, in order to establish the same radio bearer, the radio bearer establishment procedure is initiated redundantly in Step ST9135.

[0709] The solution in the first modification of the sixth embodiment is as follows. If a connection lite bearer already exists, or if a bearer whose establishment has been completed in connection-oriented (hereinafter also referred to as "Connection oriented bearer") exists, the P-GW does not execute procedures related to the IP-CAN session. Alternatively, the IP connectivity access network (IP-CAN) session is maintained by the initially set PDN connectivity request, and the P-GW does not execute procedures related to the IP-CAN session. This makes it possible to prevent unnecessary procedures for sessions of the same application.

[0710] Next, the MME determines whether the bearer to be used in connection-oriented between the UE and the P-GW is in the establishment procedure, in the modification procedure, or has already been established. Hereinafter, this determination may be referred to as "bearer establishment determination." If the bearer is not in the establishment procedure, in the modification procedure, or has not already been established, the MME initiates the establishment procedure for the bearer to be used in connection-oriented. Alternatively, the MME determines whether the RRC / ECM state is CONNECTED or IDLE, and if it is IDLE, initiates the establishment procedure for the bearer to be used in connection-oriented. If the bearer is in the establishment procedure, in the modification procedure, or has already been established, the MME does not initiate the establishment procedure for the bearer to be used in connection-oriented. Alternatively, the MME determines whether the RRC / ECM state is CONNECTED or IDLE, and if it is CONNECTED, does not initiate the establishment procedure for the bearer to be used in connection-oriented. This makes it possible to avoid setting up duplicate bearers.

[0711] The following describes a case where the UE transmits data. The MME may initiate a bearer establishment determination upon receiving a service request.

[0712] If the bearer is in the process of being established or has not yet been established, the MME initiates the procedure for establishing the bearer to be used in connection-oriented. As a specific example, the MME executes the normal service request procedure. For example, the MME sends an Initial Context Setup Request message to the eNB.

[0713] If the establishment procedure is in progress or has already been established, the UE is notified of this fact, or the process may be terminated without notification.

[0714] This section describes the case where an APP server transmits data. When a data transmission request is received from an application server and the transmission data is sent, the P-GW or S-GW starts a determination of whether an existing bearer exists.

[0715] If it is determined that an existing bearer exists, the MME is notified of this fact. Alternatively, the MME may be notified only if an existing bearer exists.

[0716] As a notification method, a new message to be notified from the P-GW to the MME may be created, such as a Bearer Change Request message. Alternatively, an information element indicating the existence of an existing bearer may be added to the existing Create Bearer Request message.

[0717] The MME that receives the bearer change request message may initiate a bearer establishment determination.

[0718] If the bearer is in the establishment procedure or has not yet been established, the MME initiates the procedure to establish the bearer to be used in connection-oriented. As a specific example, the MME requests the P-GW to initiate a normal dedicated bearer activation procedure. Specific examples of the request method include creating a new Create Bearer Response or Bearer Change Response, or creating a new Bearer Set Request.

[0719] The MME may send a reject signal in response to the Bearer Change Request, indicating that the bearer is currently being established or has already been established as the reason. Alternatively, the MME itself may send a Bearer Setup Request / Session Management Request to the eNB and initiate a Dedicated Bearer Activation Procedure.

[0720] If the bearer is in the process of being established or has already been established, the P-GW is notified of this. Specific examples of notification methods include a Modify Bearer Request or a Bearer Change Response.

[0721] The P-GW, upon receiving the notification that the establishment procedure is in progress or that the establishment has already been completed, transmits downlink data to the UE using the newly established bearer.

[0722] In the method disclosed above, the MME determines whether or not the bearer used in connection-oriented between the UE and the P-GW is in the process of being established or has already been established.

[0723] As another method, the UE, or the P-GW or the S-GW may determine whether or not a bearer to be used in connection-oriented has been established between the UE and the P-GW, and notify the P-GW or the MME.

[0724] This section describes a case where a UE transmits data. The UE determines whether a connection lite bearer or a connection oriented bearer exists. Hereinafter, this determination may be referred to as "determination of the presence or absence of an existing bearer." The UE notifies the network side of the result of the determination of the presence or absence of an existing bearer. Specifically, the UE notifies the P-GW or S-GW.

[0725] As specific examples of the notification content of the result of the determination of the presence or absence of an existing bearer, the following three items (1) to (3) are disclosed. (1) Whether or not there is an existing bearer. Or, only whether there is an existing bearer. Or, only whether there is no existing bearer. (2) Whether or not the EPS bearer needs to be changed. Or, only that the EPS bearer needs to be changed. Or, only that the EPS bearer does not need to be changed. If an existing bearer exists, the EPS bearer does not need to be changed. If there is no existing bearer, the EPS bearer needs to be changed. (3) Whether procedures related to IP-CAN sessions are necessary. Or, only that procedures related to IP-CAN sessions are necessary. Or, only that procedures related to IP-CAN sessions are not necessary. If there is an existing bearer, procedures related to IP-CAN sessions are not necessary. If there is no existing bearer, procedures related to IP-CAN sessions are necessary.

[0726] A specific example of a method for notifying the result of determining whether or not an existing bearer exists will be disclosed below. The UE notifies the P-GW or S-GW via the MME. For example, the UE notifies the MME of the result of determining whether or not an existing bearer exists using a NAS signal. As specific examples of this case, the following two cases (1) and (2) are disclosed. (1) A new NAS signal will be established. (2) Use an existing NAS signal. An information element for determining whether or not an existing bearer exists can be added to an existing signal. A specific example of an existing signal is a service request message.

[0727] The MME that has received the result of the determination of the presence or absence of the existing bearer notifies the S-GW and P-GW of the result of the determination of the presence or absence of the existing bearer received from the UE. As specific examples of this case, the following two (1) and (2) are disclosed. (1) Establish a new signal. (2) Use an existing signal. An information element for determining whether an existing bearer exists can be added to an existing signal. Examples of existing signals include a Modify Bearer Request message and a Delete Bearer Request message.

[0728] The S-GW or P-GW that receives the result of the existing bearer existence determination determines whether to execute the procedure for the IP-CAN session based on the received result of the existing bearer existence determination. Specifically, it makes the determination as follows (1) and (2).

[0729] (1) If it is notified that there is an existing bearer, or that an EPS bearer change is not required, or that a procedure related to the IP-CAN session is not required, the P-GW determines that a procedure related to the IP-CAN session is not required. Regardless of the dynamic PCC referenced in a Modify Bearer Request, etc., the P-GW may determine that a procedure related to the IP-CAN session is not required.

[0730] (2) If it is notified that there is no existing bearer, or that an EPS bearer needs to be changed, or that procedures regarding the IP-CAN session are required, it is determined that procedures regarding the IP-CAN session are required.

[0731] This section describes the case where the APP server sends data. In this case, the P-GW or S-GW determines whether an existing bearer exists. Based on the result, the S-GW or P-GW determines whether to execute a procedure related to the IP-CAN session. Specifically, the determination is made as follows: (1) and (2) below.

[0732] (1) If an existing bearer exists, it is determined that no procedures related to the IP-CAN session are necessary. (2) If there is no existing bearer, it is determined that a procedure related to the IP-CAN session is necessary. For example, the normal Dedicated Bearer Activation Procedure is initiated.

[0733] Next, a specific example of a sequence of a communication system in Modification 1 of Embodiment 6 will be described with reference to Figures 52 and 53. Figures 52 and 53 are diagrams showing an example of a sequence of a communication system in Modification 1 of Embodiment 6. Figures 52 and 53 are connected at the position of boundary line BL19. The sequences shown in Figures 52 and 53 are similar to the sequences shown in Figures 44 to 47, so the same step numbers are used for the same steps and common explanations will be omitted. Figures 52 and 53 show a sequence in which a UE in a connection-lite state transmits large amounts of data and transitions to a connection-oriented state.

[0734] In Step ST9401, the UE determines whether or not there is an existing bearer. The NAS of the UE may make this determination. If it determines that there is no existing bearer, the UE activates a normal service request procedure. In Figures 52 and 53, the description of the normal service request procedure is omitted and is indicated as "end." If it determines that there is an existing bearer, the UE proceeds to Step ST9402.

[0735] In Step ST9402, the NAS of the UE transmits a service request to the AS, to which an information element for determining whether or not an existing bearer exists is added. The NAS of the UE may notify the RRC layer.

[0736] In Step ST9403 of FIG. 53, the RRC layer of the UE transmits to the eNB a service request message to which an information element for determining whether or not an existing bearer exists is added.

[0737] The eNB, which has received the service request message to which the information element for determining whether or not an existing bearer exists has been added in Step ST9403, transmits, to the MME, a service request message to which the information element for determining whether or not an existing bearer exists has been added in Step ST9404.

[0738] The MME that has received the service request message in Step ST9404 determines whether a connection oriented bearer is in the process of being established or has already been established. That is, it determines whether a bearer is established. The MME may determine whether a bearer is established when it receives a notification that an existing bearer exists based on the result of the determination whether an existing bearer exists.

[0739] If the establishment procedure is in progress or has already been established, the process ends. If necessary, the MME may send a response message to the UE via the eNB. Upon receiving the response message, the UE waits for the establishment of an RRC connection for the established bearer and transmits normal data. Even if there is no response message, transmission is possible by setting up an RRC connection for the established or established bearer.

[0740] If the establishment procedure is in progress or the bearer has not yet been established, the MME proceeds to Step ST9410, and transmits an initial context setup request message to the eNB. The initial context setup request message may include an information element for determining whether or not an existing bearer exists.

[0741] In Step ST9411, the eNB transmits an initial context setup complete message to the MME. An information element for determining whether or not an existing bearer exists may be added to the initial context setup complete message.

[0742] In Step ST9406, the MME transmits a Modify Bearer Request to the S-GW, to which an information element for determining whether or not an existing bearer exists has been added.

[0743] In Step ST9406, the S-GW receives the modify bearer request message to which an information element for determining whether an existing bearer exists has been added, and in Step ST9407 transmits to the P-GW a modify bearer request message to which an information element for determining whether an existing bearer exists has been added.

[0744] The P-GW that receives the modify bearer request message to which the information element for determining whether or not an existing bearer exists has been added in Step ST9407 does not execute any procedure related to the IP-CAN session.

[0745] In Step ST9408, the P-GW transmits a Modify Bearer Response to the S-GW. The P-GW may also notify the S-GW that the EPS bearer has not been changed or that a procedure related to the IP-CAN session has not been performed.

[0746] In Step ST9409, the S-GW that has received the modify bearer response message in Step ST9408 transmits a modify bearer response message to the MME.

[0747] Next, a specific example of the sequence of the communication system in Modification 1 of Embodiment 6 will be described with reference to Figures 54 to 56. Figures 54 to 56 are diagrams showing another example of the sequence of the communication system in Modification 1 of Embodiment 6. Figures 54 and 55 are connected at the position of boundary line BL20. Figures 55 and 56 are connected at the position of boundary line BL21. The sequences shown in Figures 54 to 56 are similar to the sequences shown in Figures 44 to 49, so the same step numbers are used for the same steps and common explanations will be omitted. Figures 54 to 56 show the sequence when, in a connection-lite state, the network (NW) side transmits large amounts of data and transitions to a connection-oriented state.

[0748] In Step ST9501 of Figure 55, the P-GW determines whether or not an existing bearer exists. If the P-GW determines that there is no existing bearer, it moves to Step ST9204 and activates a normal dedicated bearer activation procedure. If the P-GW determines that there is an existing bearer, it moves to Step ST9502.

[0749] In Step ST9502, the P-GW notifies the MME that there is an existing bearer. Specifically, the P-GW notifies the MME of a bearer change request message.

[0750] The MME that has received the information that an existing bearer exists in Step ST9502 determines, in Step ST9405, whether a connection oriented bearer is in the process of being established or has already been established. That is, it executes a determination as to whether a bearer is established.

[0751] If the establishment procedure is in progress or has already been established, the MME proceeds to Step ST9501, and notifies the P-GW of that fact.

[0752] If the bearer is in the establishment procedure or has not yet been established, the MME proceeds to Step ST9504, and requests the P-GW to activate a normal dedicated bearer activation procedure.

[0753] In Step ST9505 of FIG. 56, the P-GW transmits data to the UE by using the bearer opened in Step ST9148. That is, the P-GW transmits normal size data, and then ends the process.

[0754] In Step ST9506, the P-GW judges whether or not a new bearer has been established. If it is judged that a new bearer has not been established, the P-GW repeats the judgment of Step ST9506. If it is judged that a new bearer has been established, the P-GW proceeds to Step ST9507.

[0755] In Step ST9507, the P-GW transmits data to the UE using the newly established bearer. That is, the P-GW transmits normal size data, and then ends the process.

[0756] In addition to the effects of the first embodiment described above, the first modification of the sixth embodiment can provide the following effects.

[0757] It is possible to avoid unnecessary procedures to the IP connection access network. Since the process of opening an EPS bearer is executed redundantly, it is possible to avoid the risk of the PDN rejecting the connection as an invalid request.

[0758] Furthermore, unnecessary radio bearer settings can be avoided, and duplication of control processes and instability of the communication system due to duplication of control processes can be avoided.

[0759] This makes it possible to switch communication bearers in a safe manner and also to reduce the impact of operations of external networks on communication.

[0760] Sixth embodiment, variant 2 The problem to be solved by the second modification of the sixth embodiment will be described below. It is assumed that the connection-lite transmission of the sixth embodiment will be used when the amount of data transmitted at one time is small. However, assuming transmission using IP packets, for example, the IP header of IPv6 (Internet Protocol Version 6) specified in RFC2460 etc. is 40 bytes, and even when considering header compression in PDCP, the header overhead relative to the amount of transmitted data is not small.

[0761] In the above situation, it is assumed that only one IP address is assigned to the UE, and since it can be considered equivalent to the UE ID, at least the transmission of the UE's IP address information will result in a waste of radio resources. Also, since the IP addresses of devices with which the UE can communicate are limited, the transmission of the IP addresses of the devices with which the UE can communicate may also result in a waste of radio resources.

[0762] To solve the above problem, the following measures are taken: When transmitting at the Uu point in the case of connection-lite, the network address information in the IP header is not transmitted, and the elements indicating the upper protocol and the source address in the IP header are degenerated and reconstructed as a separate header.

[0763] A specific example of an entity that performs IP header degradation and reconstructs other headers is the MME.

[0764] The following seven parameters (1) to (7) are disclosed as specific examples of parameters to be reduced and reconstructed as a different header. (1) Source Address: Since it is assumed that only one IP address is assigned to a UE, it is possible to reconstruct the address by degenerating it. Since it is assumed that the devices with which the UE communicates are also limited, it is also possible to reconstruct the address by degenerating it.

[0765] (2) Destination Address: Since it is assumed that only one IP address is assigned to a UE, it is possible to reconstruct the address by degenerating it. Since it is assumed that the devices with which the UE communicates are also limited, it is also possible to reconstruct the address by degenerating it. (3) Version: The version of the IP header used in the communication method defined by 3GPP is statically determined, so communication can be carried out without any problems even if it is degenerated. (4) Traffic class. Since it is statically determined when the EPS bearer is set up (sometimes called "call setup"), communication can be carried out without any problems even if it is degenerated. (5) Hop limit: When the network terminates at a mobile terminal, that is, when there are no further hops beyond the mobile terminal, communication can be carried out without any problems even when degenerated.

[0766] (6) Flow Label. (7) A combination of (1) to (6) above.

[0767] This modification can be used in combination with the sixth embodiment and the first modification of the sixth embodiment.

[0768] The second modification of the sixth embodiment described above provides the following advantages: It is possible to reduce the amount of transmission for the IP addresses, and it is possible to reduce the amount of wireless resources used.

[0769] Sixth embodiment, variant 3 The problem to be solved by the third modification of the sixth embodiment will be described below. In the case of connection-lite transmission proposed in Non-Patent Document 15, data is transmitted after establishing a wireless connection (RRC connection). However, assuming that the data is small and that one packet is being transmitted, establishing a wireless connection has a significant impact on the power consumption and wireless resources of the communication terminal device.

[0770] In order to solve the above-mentioned problem, the following measures are taken, similar to those in the fourth modification of the first embodiment.

[0771] In the case of connection-lite, the small data is transmitted using the fourth modification of the first embodiment described above. The small data is transmitted to the eNB in ​​the RRC standby state (RRC_IDLE). The small data is transmitted during random access processing. The details are the same as those of the fourth modification of the first embodiment described above, and therefore will not be described again.

[0772] This modification can be used in combination with the sixth embodiment, the first modification of the sixth embodiment, and the second modification of the sixth embodiment.

[0773] The third modification of the sixth embodiment described above provides the following advantages: Since an RRC connection is not established, the procedure can be omitted, and power consumption and radio resources of the communication terminal device can be reduced.

[0774] Sixth embodiment, variant 4 The problem to be solved by the fourth modification of the sixth embodiment is the same as that solved by the third modification of the sixth embodiment described above.

[0775] In order to solve the above-mentioned problem, the following measures similar to those of the fifth modification of the first embodiment are taken.

[0776] In the case of connection-lite, the small data is transmitted using the fifth modification of the first embodiment described above. The small data is transmitted to the eNB in ​​the RRC standby state (RRC_IDLE). The small data is transmitted during paging processing. The details are the same as those of the fifth modification of the first embodiment described above, and therefore will not be described again.

[0777] This modification can be used in combination with the sixth embodiment, the first modification of the sixth embodiment, the second modification of the sixth embodiment, and the third modification of the sixth embodiment.

[0778] The fourth modification of the sixth embodiment described above can provide the following advantages: Since an RRC connection is not established, the procedure can be omitted, and power consumption and radio resources of the communication terminal device can be reduced.

[0779] Sixth embodiment, variant 5 The problem to be solved by the fifth modification of the sixth embodiment will be described below. In the sixth embodiment and its first to fourth modifications, when the state of the EMC (RRC) connection between the UE and the eNB is used,...

Claims

1. A communication system including a mobile terminal and a base station that performs wireless communication between the mobile terminal and the base station, transmitting and receiving data between the mobile terminal and the base station during a random access process; The random access process includes: a first step of transmitting a random access preamble message from the mobile terminal to the base station; a second step of transmitting a random access response message from the base station to the mobile terminal; a third step of transmitting a scheduled transmission message from the mobile terminal to the base station; a fourth step of transmitting a contention resolution message from said base station to said mobile terminal; The data is transmitted and received using the scheduled transmission message of the third step; The communication system is characterized in that the scheduled transmission message in the third step is an RRC (Radio Resource Control) message.

2. the scheduled transmission message of the third step includes configuration reason information; 2. The communication system according to claim 1, wherein the setting reason information includes information indicating that the setting reason information is the data.

3. A communication system including, in addition to the mobile terminal and the base station, a mobility management device that manages the mobility of the mobile terminal, and a gateway device that transmits and receives data between the mobile terminal and the base station, wherein data is transmitted and received between the base station and the gateway device using an interface between the base station and the gateway device or via the mobility management device, The communication system according to claim 1, characterized in that when data is transmitted and received between the base station and the gateway device via the mobility management device, data is transmitted and received between the mobile terminal and the base station during random access processing.

4. A mobile terminal that performs wireless communication with a base station, transmitting and receiving data to and from the base station during a random access process; The random access process includes: a first step of transmitting a random access preamble message from the mobile terminal to the base station; a second step of transmitting a random access response message from the base station to the mobile terminal; a third step of transmitting a scheduled transmission message from the mobile terminal to the base station; a fourth step of transmitting a contention resolution message from said base station to said mobile terminal; The data is transmitted and received using the scheduled transmission message of the third step; The mobile terminal is characterized in that the scheduled transmission message in the third step is an RRC (Radio Resource Control) message.

5. A base station that performs wireless communication with a mobile terminal, transmitting and receiving data to and from the mobile terminal during a random access process; The random access process includes: a first step of transmitting a random access preamble message from the mobile terminal to the base station; a second step of transmitting a random access response message from the base station to the mobile terminal; a third step of transmitting a scheduled transmission message from the mobile terminal to the base station; a fourth step of transmitting a contention resolution message from said base station to said mobile terminal; The data is transmitted and received using the scheduled transmission message of the third step; The base station, wherein the scheduled transmission message in the third step is a Radio Resource Control (RRC) message.

6. A mobility management device in a communication system comprising a mobile terminal, a base station that performs wireless communication with the mobile terminal, a mobility management device that manages the mobility of the mobile terminal, and a gateway device that transmits and receives data to and from the base station, wherein data is transmitted and received between the base station and the gateway device using an interface between the base station and the gateway device or via the mobility management device, When data is transmitted and received between the base station and the gateway device via the mobility management device, data is transmitted and received between the mobile terminal and the base station during a random access process; The random access process includes: a first step of transmitting a random access preamble message from the mobile terminal to the base station; a second step of transmitting a random access response message from the base station to the mobile terminal; a third step of transmitting a scheduled transmission message from the mobile terminal to the base station; a fourth step of transmitting a contention resolution message from said base station to said mobile terminal; transmitting and receiving data between the base station and the mobile terminal using the scheduled transmission message of the third step; The mobility management device is characterized in that the scheduled transmission message in the third step is an RRC (Radio Resource Control) message.

7. A gateway device in a communication system includes a mobile terminal, a base station that performs wireless communication with the mobile terminal, a mobility management device that manages the mobility of the mobile terminal, and a gateway device that transmits and receives data to and from the base station, and transmits and receives data between the base station and the gateway device using an interface between the base station and the gateway device or via the mobility management device, When data is transmitted and received between the base station and the gateway device via the mobility management device, data is transmitted and received between the mobile terminal and the base station during a random access process; The random access process includes: a first step of transmitting a random access preamble message from the mobile terminal to the base station; a second step of transmitting a random access response message from the base station to the mobile terminal; a third step of transmitting a scheduled transmission message from the mobile terminal to the base station; a fourth step of transmitting a contention resolution message from said base station to said mobile terminal; transmitting and receiving data between the base station and the mobile terminal using the scheduled transmission message of the third step; The gateway device is characterized in that the scheduled transmission message in the third step is an RRC (Radio Resource Control) message.

Images