WO2017077979A1

WO2017077979A1 - User device, base station, and connection establishment method

Info

Publication number: WO2017077979A1
Application number: PCT/JP2016/082273
Authority: WO
Inventors: 高橋　秀明; ウリアンダルマワンティハプサリ
Original assignee: 株式会社Ｎｔｔドコモ
Priority date: 2015-11-05
Filing date: 2016-10-31
Publication date: 2017-05-11

Abstract

A user device in a mobile communication system that supports a connection establishment function that involves reusing context information stored in the user device and a base station, the user device being equipped with: a transmission means for transmitting, to the base station, a first message indicating that the user device is storing user device-side context information; a receiving means for receiving, from the base station, a second message indicating that the base station is storing base station-side context information associated with the user device; and a connection means for establishing a connection with the base station by using the user device-side context information after receiving the second message.

Description

User apparatus, base station, and connection establishment method

The present invention relates to a technology in which each of the user equipment UE and the base station eNB in the mobile communication system holds a UE context.

In the LTE system, a connection state between a user apparatus UE (hereinafter referred to as UE) and a base station eNB (hereinafter referred to as eNB) is an RRC (Radio Resource Control) idle state (RRC_Idle) and an RRC connection state. (RRC_Connected).

When the UE connects to the network, a UE context is generated by MME (Mobility Management Entity) on the core NW side, and in the RRC connection state, the UE context is held in the eNB and the UE to which the UE is connected. The UE context is information including bearer related information, security related information, and the like.

When the UE transitions between the RRC idle state and the RRC connection state, a lot of call control signaling including the core NW side is generated, so how to reduce the signaling is a problem.

For example, when the UE transitions from the RRC connected state to the RRC idle state, signaling as shown in FIG. 1 occurs (Non-Patent Document 1, etc.). The case of FIG. 1 is a case where the eNB 2 detects that the communication of the UE 1 does not occur for a predetermined time, disconnects the connection with the UE 1, and transitions to the RRC idle state.

1, eNB 2 transmits a UE context release request (UE 解放 Context Release Request) to MME 3 (step 1). The MME 3 transmits a bearer release request (Release Access Bearers request) to the S-GW 4 (step 2), and the S-GW 4 returns a bearer release response (Release Access Bearers response) to the MME 3 (step 3).

The MME 3 transmits a UE context release instruction (UE Context Release Command) to the eNB 2 (step 4). eNB2 transmits RRC connection release (RRC Connection Release) to UE1 (step 5), causes UE1 to release the UE context, and transitions to the RRC idle state. Moreover, eNB2 releases UE context and transmits UE context release completion (UE | Context | Release | Complete) to MME3 (step 6).

In the signaling procedure as shown in FIG. 1, not only a large amount of signaling occurs when the RRC connection is released, but also when the UE transitions from the RRC idle state to the RRC connected state again, a large amount of signaling is required for setting the UE context. Will occur.

To reduce signaling when the UE transitions between the RRC idle state and the RRC connected state, when the UE transitions from the RRC connected state-> RRC idle state-> RRC connected state within the same eNB, the UE A method of keeping the context in the eNB and UE and reusing it has begun to be studied (Non-Patent Document 2). An example of a procedure conceivable in the method will be described with reference to FIG.

In the state shown in FIG. 2A, UE1 is in the RRC connection state, and the S1-C connection and the S1-U connection (S1-C / U in the figure) related to the UE1 are established on the core NW side. It is a state that has been. The S1-C connection is an S1 connection that sends a C-plane signal, and the S1-U connection is an S1 connection that passes a U-plane.

From the state shown in (a), as shown in (b) and (c), UE1 is transitioned to the RRC idle state by RRC connection release (RRC Connection Release). At this time, the UE context for UE1 in eNB2 is maintained, the UE context for eNB2 in UE1 is also maintained, and the S1-C / U connection for UE1 is also maintained. Then, as shown in (d), when UE1 transitions to the RRC connection state, eNB2 and UE1 reuse the UE context that has been retained, thereby reducing signaling and establishing an RRC connection. .

Here, in the case shown in (d) of FIG. 2, UE1 and eNB2 show examples in which RRC connection establishment is performed using the retained UE contexts. There are a large number of UEs, and the eNB does not know whether each UE has a UE context that can be used for connection with the eNB.

For example, as shown in FIG. 3, when the UE 6 that holds the UE context used in the connection with the eNB_B moves to the eNB_A in the RRC idle state, the eNB_A holds the UE context that the UE 6 can use for the connection with the eNB_A. It is unclear whether or not

Considering such a case, for example, the eNB_A may attempt a connection procedure that reuses the UE context, assuming that all UEs located in the cell of the eNB_A hold the UE context for the eNB_A. Conceivable. However, in this case, the connection procedure with the UE that does not hold the UE context for eNB_A fails, and the normal connection procedure that does not reuse the UE context is executed again, which may cause a delay.

The present invention has been made in view of the above points. In a mobile communication system that supports a function of establishing a connection by reusing context information held in each of a user apparatus and a base station, the user apparatus has a context. It is an object of the present invention to provide a technique that enables a base station to determine whether or not information is held.

According to an embodiment of the present invention, the user apparatus in a mobile communication system supporting a function of establishing a connection by reusing context information held in each of the user apparatus and the base station,
Transmitting means for transmitting to the base station a first message indicating that the user apparatus holds user apparatus side context information;
Receiving means for receiving, from the base station, a second message indicating that the base station holds the base station side context information associated with the user apparatus;
After receiving the second message, there is provided a user apparatus comprising: connection means for establishing a connection with the base station using the user apparatus side context information.

Further, according to the embodiment of the present invention, the base station in the mobile communication system that supports a function of establishing a connection by reusing context information held in each of the user apparatus and the base station,
Receiving means for receiving, from the user device, a first message indicating that the user device holds user device-side context information;
In response to receiving the first message, a second message indicating that the base station holds the base station side context information associated with the user apparatus is transmitted to the user apparatus. A transmission means;
After transmitting the second message, there is provided a base station comprising connection means for establishing a connection with the user apparatus using the base station side context information.

In addition, according to the embodiment of the present invention, connection establishment performed by the user apparatus in a mobile communication system that supports a function of establishing connection by reusing context information held in each of the user apparatus and the base station. A method,
A transmission step of transmitting to the base station a first message indicating that the user apparatus holds user apparatus side context information;
A receiving step of receiving, from the base station, a second message indicating that the base station holds the base station side context information associated with the user device;
After receiving the second message, there is provided a connection establishment method comprising: a connection step of establishing a connection with the base station using the user apparatus side context information.

Further, according to the embodiment of the present invention, connection establishment performed by the base station in a mobile communication system that supports a function of establishing connection by reusing context information held in each of the user apparatus and the base station A method,
A receiving step of receiving, from the user device, a first message indicating that the user device holds user device-side context information;
In response to receiving the first message, a second message indicating that the base station holds the base station side context information associated with the user apparatus is transmitted to the user apparatus. Sending step;
After transmitting the second message, there is provided a connection establishment method comprising: a connection step of establishing a connection with the user apparatus using the base station side context information.

According to an embodiment of the present invention, in a mobile communication system that supports a function of establishing a connection by reusing context information held in each of a user apparatus and a base station, the user apparatus holds the context information. There is provided a technique that enables a base station to determine whether or not there is.

It is a figure which shows the example of a signaling sequence in the case of changing to a RRC idle state. It is a figure for demonstrating the example of the process in the case of hold | maintaining UE context. It is a figure for demonstrating a subject. It is a block diagram of the communication system in embodiment of this invention. It is a figure which shows the example of the process sequence of the whole system in this Embodiment. It is a figure which shows the other example of the process sequence of the whole system in this Embodiment. It is a figure for demonstrating the connection establishment procedure in this Embodiment. It is a figure for demonstrating the connection release procedure in this Embodiment. It is a figure which shows the other example of the process sequence of the whole system. It is a figure which shows the specification modification example 1 of RRCConnectionRequest | message. It is a figure which shows the specification modification example 1 of RRCConnectionRequest | message. It is a figure which shows the example 1 of specification change of RRCConnectionSetup | message. It is a figure which shows the example 1 of specification change of RRCConnectionSetup | message. It is a figure which shows the example 1 of specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 1 of specification change of RRCConnectionRelease message. It is a figure which shows the example 1 of specification change of RRCConnectionRelease message. It is a figure which shows the example 2 of specification change of RRCConnectionRelease message. It is a figure which shows the example 2 of specification change of RRCConnectionRelease message. It is a figure which shows the example of a specification change regarding the operation | movement at the time of transmission of RRCConnectionRequest | message. It is a figure which shows the example 2 of specification change of RRCConnectionRequest | message. It is a figure which shows the example 2 of specification change of RRCConnectionRequest | message. It is a figure which shows the example of a specification change regarding the operation | movement at the time of reception of RRCConnectionSetup | message. It is a figure which shows the example 2 of specification change of RRCConnectionSetup | message. It is a figure which shows the example 2 of specification change of RRCConnectionSetup | message. It is a figure which shows the example of a specification change of UE operation | movement at the time of RRC | connection * Reject reception corresponding to Option * 1. It is a figure which shows the example of a specification change of UE operation | movement at the time of RRC (connection) Reject corresponding to Option (2). It is a figure which shows the example of a specification change of RRC (connection) Reject (message) corresponding to Option (1). It is a figure which shows the example of a specification change of RRC (connection) Reject (message) corresponding to Option (1). It is a figure which shows the example of a specification change of RRC (connection) Reject (message) corresponding to Option (2). It is a figure which shows the example of a specification change of RRC (connection) Reject (message) corresponding to Option (2). It is a figure which shows the example 3 of specification change of RRCConnectionRelease message. It is a figure which shows the example 3 of specification change of RRCConnectionRelease message. It is a figure which shows the example of a specification change regarding the operation | movement at the time of reception of RRCConnectionRelease message. It is a figure which shows the example of a specification change regarding the variable for UE content holding. It is a figure for demonstrating the example of the method of notifying the specific information of eNB. It is a figure which shows the example of a context acquisition procedure. It is a figure which shows the example 3 of specification change of RRCConnectionRequest | message. It is a figure which shows the example 3 of specification change of RRCConnectionRequest | message. It is a figure which shows the example 3 of specification change of RRCConnectionSetup | message. It is a figure which shows the example 3 of specification change of RRCConnectionSetup | message. It is a figure which shows the example 2 of a specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 2 of a specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 4 of specification change of RRCConnectionRequest | message. It is a figure which shows the example 4 of specification change of RRCConnectionRequest | message. It is a figure which shows the example 3 of specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 3 of specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 5 of a specification change of RRCConnectionRequest | message. It is a figure which shows the example 5 of a specification change of RRCConnectionRequest | message. It is a figure which shows the example 4 of a specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 4 of a specification change of RRCConnectionSetupComplete | message. It is a figure which shows the specification modification example 6 of RRCConnectionRequest | message. It is a figure which shows the specification modification example 6 of RRCConnectionRequest | message. It is a figure which shows the example 5 of a specification change of RRCConnectionSetupComplete | message. It is a figure which shows the example 5 of a specification change of RRCConnectionSetupComplete | message. It is a flowchart for demonstrating the operation example of UE. It is a flowchart for demonstrating the operation example of UE. It is a figure which shows the example of a message of RA Response. It is a figure which shows the example of a message of RA Response. It is a flowchart for demonstrating the operation example of UE. It is a figure which shows the example of a specification change regarding LCID. It is a figure which shows the example of a specification change regarding LCID. It is a figure which shows the example of a specification change regarding holding | maintenance of UE context. It is a figure which shows the example of a specification change regarding holding | maintenance of UE context. It is a block diagram of MME and S-GW. It is a block diagram of UE50. It is a HW block diagram of UE50. It is a block diagram of eNB10. It is a block diagram of eNB10. It is a HW block diagram of eNB10.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. The embodiment described below is only an example, and the embodiment to which the present invention is applied is not limited to the following embodiment. For example, in the present embodiment, an LTE system is targeted, but the present invention is not limited to LTE and can be applied. Further, in the present specification and claims, the term “LTE” is not limited to a specific Rel (release) of 3GPP unless otherwise specified.

(Whole system configuration)
FIG. 4 is a diagram showing a configuration example of a communication system in the embodiment of the present invention. As illustrated in FIG. 4, the communication system according to the present embodiment includes an eNB 10, an eNB 20, an MME 30, an S-GW (Serving Gateway) 40, and a UE 50. FIG. 4 shows only the part related to the present embodiment regarding the core network (EPC).

UE 50 is a user device such as a mobile phone. Each of the

eNBs

10 and 20 is a base station. The MME 30 is a node device that accommodates the eNB and performs location control, mobility control such as paging and handover, bearer establishment / deletion, and the like. The S-GW 40 is a node device that relays user data (U-Plane data). A system composed of the MME 30 and the S-GW 40 is called a communication control device. Alternatively, the MME 30 and the S-GW 40 may be configured as a single device and referred to as a communication control device.

As shown in FIG. 4, the MME 30 and the eNBs 10 and 20 are connected via the S1-MME interface, and the S-GW 40 and the eNBs 10 and 20 are connected via the S1-U interface. A dotted connection line indicates a control signal interface, and a solid connection line indicates a user data transfer interface.

In the present embodiment, as described above, even when the UE 50 transitions from the RRC connected state to the RRC idle state in the same eNB, the UE context of the UE 50 is held in the eNB, and the UE 50 also has the eNB. It is assumed that the UE context related to the connection is maintained. As described above, this method is a method that enables the number of signaling to be reduced.

(Overall sequence example)
First, as a sequence example of the entire communication system in the present embodiment, a method of paging from the MME 30 when there is an incoming call to the UE 50 in the RRC idle state will be described. More specifically, the processing sequence in the case where the UE 50 connects to the eNB 10 and enters the RRC connection state, enters the RRC idle state in the cell under the control of the eNB 10, and receives an incoming call later in the same cell will be described with reference to FIG. To do.

As a premise of the processing in FIG. 5, the UE 50 is in an RRC connection state in the cell of the eNB 10 and an S1-C / U connection related to the UE 50 is established. In FIG. 5, the S1-C connection includes a connection between the eNB 10 and the MME 30 and a connection between the MME 30 and the S-GW 40, and the S1-U connection includes a connection between the eNB 10 and the S-GW 40. When the connection is established, a signal (data) related to the UE 50 can be transmitted / received between the corresponding node devices without executing a procedure for connection setup such as a connection establishment signal.

Before entering the description of the procedure in FIG. 5, an outline of an example of a procedure when the UE 50 first connects to the eNB 10 will be described (Non-Patent Document 3). During random access of the UE 50, the eNB 10 transmits RRC 送信 Connection Setup to the UE 50, sets the UE 50 to the RRC connection state, and receives RRC Connection Setup Complete from the UE 50. Thereafter, the eNB 10 receives an Initial Context Setup Request from the MME 30, transmits an RRC Security Mode to the UE 50, receives an RRC Security Mode Complete from the UE 50, and transmits an RRC Connection Reconfiguration to the UE 50, RRC Connection Reconfiguration Complete is received from UE50, and InitialInContext Setup Response is transmitted to MME30. Through such a procedure, the UE context and the UE context are established and held in the UE 50 and the eNB 10.

As shown in FIG. 5, in the RRC connection state, the eNB 10 transmits a connection maintenance instruction signal to the MME 30 (step 101). Also, the MME 30 transmits a connection maintenance instruction signal to the S-GW 40 (step 102).

The connection maintenance instruction signal is a signal that instructs the MME 30 to perform the paging by holding down the downlink data in the S-GW 40 when receiving the call to the UE 50 while maintaining the S1-C / U connection related to the UE 50.

The S-GW 40 that has received the connection maintenance instruction signal transmits a confirmation response indicating that the instruction has been confirmed to the MME 30 (step 103), and the MME 30 transmits a confirmation response to the eNB 10 (step 104).

The transmission of the connection maintenance instruction signal from the eNB 10 to the MME 30 regarding the UE 50 may be triggered by, for example, an event that causes the UE 50 to transition to the RRC idle state in the eNB 10, or the UE 50 is initially under the control of the eNB 10. It may be performed immediately after entering the RRC connection state and establishing the S1-C / U connection for the UE 50.

The event that causes the transition to the RRC idle state is, for example, when it is detected that communication with the UE 50 (uplink / downlink user data communication) does not occur for a certain period of time due to expiration of a predetermined timer (eg, UE ： Inactivity Timer). However, it is not limited to this.

FIG. 5 assumes a case where it is triggered by detecting that communication with the UE 50 (uplink / downlink user data communication) does not occur for a certain period of time. After steps 101 to 104, RRC connection release (RRC Connection Release) is transmitted to the UE 50, and the UE 50 is shifted to the RRC idle state (step 105).

In the present embodiment, even when the UE 50 transitions to the RRC idle state, the UE context established at the time of RRC connection is maintained in each of the UE 50 and the eNB 10.

Thereafter, downlink data for the UE 50 is generated, and the downlink data arrives at the S-GW 40 (step 106). Here, the S1-U connection has been established, but based on the connection maintenance instruction signal received in step 102, the S-GW 40 holds the downlink data in the buffer without transferring it to the eNB 10.

The S-GW 40 transmits a downlink data incoming notification to the MME 30 (step 107), and the MME 30 transmits an S1-AP paging signal for the UE 50 to the eNB 10 (step 108). This paging itself is the same as the existing paging, and is transmitted to each eNB in the tracking area of the UE 50, but FIG. 5 shows transmission to the eNB 10.

The eNB 10 that has received the S1-AP paging signal transmits the RRC paging signal to the subordinate UE 50 (step 109).

UE50 which received the RRC paging signal performs a RRC connection establishment procedure, and establishes a RRC connection (step 110). Thereafter, the eNB 10 transmits RRC connection establishment completion, which is a signal indicating that establishment of the RRC connection is completed, to the MME 30 (step 111). The eNB 10 can determine that the RRC connection with the UE 50 has been established, for example, when the eNB 10 receives RRC Connection Setup Complete from the UE 50.

The MME 30 transmits an RRC connection establishment completion signal to the S-GW 40 (step 112). Thereby, the S-GW 40 determines that the RRC connection between the UE 50 and the eNB 10 has been established, and uses the S1-U connection related to the UE 50 that has already been established to transfer the pending downlink data to the eNB 10. Start (step 113). The downlink data reaches the UE 50 from the eNB 10 (step 114). In this way, transmission of downlink data to the UE 50 is started.

Details of the RRC connection establishment procedure in step 110 of FIG. 5 will be described later. In the RRC connection establishment procedure, the UE context established and held at the time of RRC connection in each of the UE 50 and the eNB 10 is used. Therefore, RRC Security Mode Command, RRC Security Mode Complete, RRC connection establishment can be performed without transmitting / receiving messages such as RRC RConnection Reconfiguration and RRC Connection Reconfiguration Complete.

Here, the UE context held in each of the UE 50 and the eNB 10 includes, for example, an RRC configuration (RRC configuration), a bearer configuration (including bearer configuration: RoHC state information, etc.), an AS security context (Access Stratum Security Context). , L2 / L1 parameters (MAC, PHY configuration, etc.).

Further, the UE 50 and the eNB 10 may hold the same information as the UE context, the UE 50 holds only the UE context information necessary for the connection with the eNB 10, and the eNB 10 is the UE required for the connection with the UE 50. Only context information may be retained.

More specifically, in the RRC idle state, for example, each of the UE 50 and the eNB 10 has RadioResourceConfigDedicated information carried by RRC Connection Setup, capability information carried by RRC Connection Setup Complete, and security-related information (key information etc.), RRC Security related information carried in Security Mode Command, configuration information carried in RRC Connection Reconfiguration, and the like are held as UE context. Note that these are merely examples, and information held as a UE context is not limited to these, and information may be additionally held, or part of the information may not be held.

UE10 and eNB10 each hold the above information as a UE context, so that when transitioning from the RRC idle state to the RRC connected state, RRCRRSecurity Mode Command, RRC Security Mode Complete, RRC Connection Reconfiguration, RRC Connection Reconfiguration Complete The RRC connection can be established without sending / receiving messages such as.

Also, in the present embodiment, the eNB 10 holds the UE context in the storage unit in association with the identifier (UE identifier) of the UE corresponding to the UE context. Although there is no limitation on the type of the UE identifier, in this embodiment, as an example, S-TMSI (SAE temporary mobile subscriber identity) is used as the UE identifier.

FIG. 6 is a diagram showing another example of the processing sequence of the entire system in the present embodiment. FIG. 6 is a processing sequence in the case where the UE 50 is connected to the eNB 10 to be in the RRC connected state, is in the RRC idle state in the cell under the eNB 10, and is subsequently received in the same cell, as in FIG. is there. However, the sequence shown in FIG. 6 is different from FIG. 5 in that there are steps 113 and 114. In the following, differences from FIG. 5 will be mainly described.

According to the procedure of Step 110, the UE 50 changes from the RRC idle state to the RRC connected state. At this time, the UE contexts held in the UE 50 and the eNB 10 change from the inactive state to the active state. That is, according to the procedure of step 110, the UE contexts held in the UE 50 and the eNB 10 are activated.

In step 111, the eNB 10 transmits to the MME 30 RRC connection establishment completion, which is a signal indicating that establishment of the RRC connection is completed. This RRC connection establishment completion signal may be a signal indicating that the UE context of the UE 50 has been activated. The MME 30 transmits an RRC connection establishment completion signal to the S-GW 40 (step 112).

In the example shown in FIG. 6, in step 113, the S-GW 40 transmits a response signal to the RRC connection establishment completion signal to the MME 30. In Step 114, the MME 30 transmits a response signal to the signal indicating completion of RRC connection establishment in Step 111 to the eNB 10. The response signal in step 114 may be an Ack signal for a signal indicating that the UE context has been activated.

After that, as in the case of FIG. 5, the S-GW 40 starts transferring the suspended downlink data to the eNB 10 (step 115). The downlink data reaches the UE 50 from the eNB 10 (step 116). In this way, transmission of downlink data to the UE 50 is started.

(Example of RRC connection establishment procedure)
Next, the RRC connection establishment procedure between UE50 and eNB10 in this Embodiment is demonstrated with reference to the sequence of FIG. The sequence shown in FIG. 7 assumes the procedure of step 110 in FIGS. 5 and 6, but is not limited to this. For example, the sequence shown in FIG. 7 may be in the RRC connection establishment procedure at the time of transmission from the UE 50.

7, it is assumed that the Random Access Preamble is transmitted from the UE 50 to the eNB 10 and the Random Access Response is transmitted from the eNB 10 to the UE 50 before the sequence illustrated in FIG.

The UE 50 transmits an RRC Connection Request message (RRC connection request) to the eNB 10 in Step 201 by using the resource allocated by the UL grant included in the Random Access Response. In the present embodiment, in step 201, the UE 50 notifies the eNB 10 that the UE 50 holds the UE context using a spare bit (spare bit: 1 bit) in the RRC Connection Request message. For example, when the bit is set (it is 1), it indicates that the UE 50 holds the UE context. This information indicating that the UE 50 holds the UE context will be referred to as UE context holding information.

Also, the RRC Connection Request message includes a UE identifier for identifying the UE 50 (specifically, S-TMSI (SAE temporary mobile subscriber identity)) in addition to the above bits. The S-TMSI is a temporary identifier of the UE 50 generated from the unique identifier of the UE 50, and is issued from the MME 30 when the location of the UE 50 is registered. In this Embodiment, UE50 and each eNB shall hold | maintain S-TMSI for identifying UE50.

The eNB 10 that has received the RRC Connection Request message in step 201 recognizes that the UE 50 identified by the UE identifier holds the UE context by reading the UE context holding information and the UE identifier from the message, and holds it. The UE context corresponding to the UE identifier is retrieved from the storage means from the plurality of UE contexts that are being used. That is, UE identifier matching processing is performed.

In step 202, when the eNB 10 detects the UE context corresponding to the UE identifier as a result of the search, the eNB 10 notifies the UE 50 that the eNB 10 holds the UE context of the UE 50 by an RRC Connection Setup message (RRC connection establishment message). At the same time, the UE 50 is requested to transmit information for authenticating the UE 50.

The UE 50 that has received the RRC Connection Setup message including information indicating that the UE 50 holds the UE context continues to use the held UE context (bearer, security key, configuration, etc.).

The RadioResourceConfigDedicated included in the RRC Connection Setup message includes parameter values related to the bearer, MAC, PHY configuration, and the like. Ignore the parameter value notified by, and continue to use the parameter value of the UE context that was held. The notified parameter value may be used without ignoring the parameter value notified by RadioResourceConfigDedicated. Thereby, when the parameter value already hold | maintained is changed by eNB10, the change can be reflected.

Next, in Step 203, the UE 50 transmits the RRC Connection Setup Complete message including the authentication information such as Authentication token, shortMAC-I, and the like to the eNB 10. Authentication information such as Authentication token and shortMAC-I is information used by the eNB 10 to authenticate the UE 50.

The eNB 10 that has received the RRC Connection Setup Complete message authenticates that the UE 50 is a correct UE corresponding to the UE context searched by the UE identifier, using the authentication information included in the message. After that, each of the UE 50 and the eNB 10 establishes (restarts) a connection using the held UE context. Note that when establishing (resuming) a connection using the retained UE context, step 203 is not necessarily required, and step 203 may not be performed.

(Example of RRC connection release procedure)
In the present embodiment, when the UE 50 receives the RRC Connection Release message from the eNB 10 and transits to the RRC idle state, the UE context may always be retained, or the UE context is retained in the RRC Connection Release message. It is good also as holding | maintaining UE context only when the information which instruct | indicates to be included is contained. The latter example will be described below.

As shown in FIG. 8, when the eNB 10 causes the UE 50 to transition to the RRC idle state, the eNB 10 transmits an RRCRRConnection メッセージ Release message to the UE 50 (step 301).

The RRC Connection Release message includes indication information (indication) that instructs the UE 50 to continue to hold the UE context in the RRC idle state. For the instruction information, a new indication may be included in the message, or a spare bit of an existing release cause may be used. Specific examples will be described later.

When the UE 50 detects the instruction information from the RRC Connection Release message, the UE 50 continues to hold the UE context (bearer information, security information, etc.) at the RRC idle state transition during the RRC idle state.

(Another example of the entire system processing sequence)
In the example illustrated in FIGS. 5 and 6, the UE 10 performs a transition between the RRC connection state and the RRC idle state under the same eNB 10, but here, as another example, the UE 50 connects to the eNB 10. The processing sequence when the UE enters the RRC connection state, enters the RRC idle state in the cell under the control of the eNB 10, and then moves to the cell under the control of the eNB 20 to receive the incoming call will be described with reference to FIG.

Also in the case of FIG. 9, as a premise of the processing, the UE 50 is in the RRC connection state in the cell of the eNB 10 and is in a state where the S1-C / U connection is established.

5 and 6, the eNB 10 transmits a connection maintenance instruction signal to the MME 30 (Step 401). Also, the MME 30 transmits a connection maintenance instruction signal to the S-GW 40 (step 402).

As described above, the connection maintenance instruction signal is a signal instructing to hold down the downlink data in the S-GW 40 and perform paging from the MME 30 when the UE 50 arrives while maintaining the S1-C / U connection related to the UE 50. It is.

The S-GW 40 that has received the connection maintenance instruction signal transmits a confirmation response to the MME 30 (step 403), and the MME 30 transmits a confirmation response to the eNB 10 (step 404).

ENB10 transmits RRC connection release (RRC | Connection | Release) to UE50 after step 401-404, and makes UE50 change to an RRC idle state (step 405). After this, UE50 moves to the cell under eNB20. The RRC Connection Release message includes an instruction to hold the UE context, and the UE 50 holds the UE context. However, this UE context is information used for connection with the eNB 10.

Thereafter, downlink data for the UE 50 is generated, and the downlink data arrives at the S-GW 40 (step 406). Here, the S1-U connection has been established, but based on the connection maintenance instruction signal received in step 402, the S-GW 40 holds the downlink data in the buffer without transferring it to the eNB 10.

The S-GW 40 transmits a downlink data incoming notification to the MME 30 (step 407), and the MME 30 transmits an S1-AP paging signal for the UE 50 to the eNB 20 (step 408). This paging itself is the same as the existing paging and is transmitted to each eNB (each of one or a plurality of eNBs) in the tracking area of the UE 50, but FIG. 9 shows transmission to the eNB 20.

The eNB 20 that has received the S1-AP paging signal transmits the RRC paging signal to the subordinate UE 50 (step 409).

UE50 which received RRC paging performs a RRC connection establishment procedure, and establishes a RRC connection (step 410). Further, a NAS connection procedure is executed between the eNB 20 and the core NW side (S-GW 40 in FIG. 9), and an S1-C / U connection for the eNB 20 is established (step 411).

As described above, since the connection between the UE 50 and the S-GW 40 is established, the S-GW 40 starts transmission of downlink data to the UE 50 (steps 412 and S413). Further, the UE context between the eNB 10 and the MME 30 is released, and the S1-C / U connection for the eNB 10 is released (step 414).

In the above example, in the RRC connection establishment procedure in step 410, the UE 50 transmits the message in step 201 in FIG. 7, but the eNB 20 determines that the UE context corresponding to the UE 50 is not held. An RRC connection procedure is performed. Alternatively, when the eNB 20 determines that the UE context does not hold the UE context corresponding to the UE 50, the PCI notified from the UE 50 by the message in the RRC connection establishment procedure (identifies the eNB 10 of the cell in which the UE 50 holds the UE context). The UE context of the UE 50 may be acquired from the eNB 10 based on the cell ID) and the like, and the RRC connection may be performed using the UE context.

(Specification change example)
Next, description examples (extracts) of the 3GPP specifications (3GPP TS 36.331, Non-Patent Document 3) when various notifications described with reference to FIGS. 7 and 8 are performed are shown in FIGS. 10 to 14, the changed part from Non-Patent Document 3 is underlined. The point where the changed part from the non-patent document 3 is underlined is the same in the drawings of other specification change examples.

FIG. 10A shows an example of an RRC Connection Request message transmitted from the UE 50 in Step 201 of FIG. As shown in FIG. 10A, ue-ContextStoring (example: 1 bit) is added. As illustrated in FIG. 10B, ue-ContextStoring is information indicating that the UE 50 holds the UE context used in the previous RRC connection. Also, as shown in FIG. 10A, S-TMSI is included.

FIG. 11A shows an example of an RRC Connection Setup message transmitted from the eNB 10 in step 202 of FIG. As shown in FIG. 11A, ue-ContextStored and ue-AuthenticationInfoReq are added.

As shown in FIG. 11B, ue-AuthenticationInfoReq is information requesting the UE to transmit authentication information. ue-ContextStored is information indicating that the eNB holds the UE context of the UE that is the target of RRC Connection Setup. When the UE detects the presence of this information (field), the UE ignores the radioRecourceConfigDedicated field notified by the RRC Connection Setup message. As described above, the parameter value notified by this may be applied without ignoring the radioRecourceConfigDedicated field.

FIG. 12 shows an example of an RRC Connection Setup message transmitted from the UE 50 in Step 203 of FIG. As shown in FIG. 12, authentication information ue-AuthenticationToken and ue-AuthenticationInfo are added.

13 to 14 show examples 1 and 2 of RRC Connection Release message transmitted from the eNB 10 in step 301 of FIG.

FIGS. 13A and 13B show an example (Example 1) of instructing UE context retention using Cause value. In this case, as shown in FIG. 13A, UEcontextHolding is added in ReleaseCause. As shown in FIG. 13B, the value of ue-ContextHolding indicates an instruction to keep the UE context while the UE is in the RRC idle state.

FIGS. 14A and 14B show an example (Example 2) in which a UE context retention instruction is performed using a new indication. As shown in FIG. 14A, ue-ContextHolding is added as a new indication. As shown in FIG. 14B, ue-ContextHolding indicates an instruction that the UE continues to hold the UE context while in the RRC idle state.

(Variation 1: Other example of RRC connection establishment procedure and RRC connection release procedure)
Although the RRC connection establishment procedure between the UE 50 and the eNB 10 in the present embodiment has been described with reference to the sequence of FIG. 7 and includes the contents of the signal, hereinafter, other examples of the RRC connection establishment procedure are modified. This will be described as Example 1. In addition, another example of signal contents will be described for the RRC connection release procedure. Note that the example described with reference to the sequence of FIG. 7 before the first modification is referred to as a basic example for convenience.

<Procedure for RRC connection establishment of Modification 1>
Since the sequence itself in the RRC connection establishment procedure of Modification 1 is the same as the sequence shown in FIG. 7, the RRC connection establishment procedure of Modification 1 will be described with reference to FIG. Also in the first modification, the sequence illustrated in FIG. 7 assumes the procedure of step 110 in FIGS. 5 and 6, but is not limited thereto. For example, the sequence shown in FIG. 7 may be in the RRC connection establishment procedure at the time of transmission from the UE 50.

The UE 50 transmits an RRC Connection Request message (RRC connection request) to the eNB 10 in Step 201 by using the resource allocated by the UL grant included in the Random Access Response. In the first modification, in Step 201, when the UE 50 holds the UE context, the UE 50 transmits the authentication information included in the RRC Connection Request message. The authentication information is information used by the eNB 10 to authenticate the UE 50, and includes, for example, C-RNTI, PCI, and ShortMAC-I used in the previous RRC connection.

Also, this authentication information is an example of UE context holding information for notifying the eNB 10 that the UE 50 holds the UE context.

The eNB 10 that has received the RRC Connection Request message in step 201 authenticates the UE 50 using the authentication information, and detects that the authentication has succeeded and the UE context of the UE 50 is retained. On the other hand, an RRC Connection Setup message (RRC connection establishment message) including information instructing to activate (activate) the UE context held by the UE 50 is transmitted to the UE 50 (step 202). The above detection is performed by, for example, storing the UE context corresponding to the UE-specific identifier (eg, S-TMSI, C-RNTI, shortMAC-I) from the storage unit among the plurality of UE contexts held by the eNB 10. This can be done by searching. Note that the information for instructing activation (activation) of the UE context is an example of context holding information indicating that the eNB 10 holds the UE context of the UE 50.

When the above authentication fails, the eNB 10 transmits to the UE 50 an RRCjectConnection する Reject message that rejects the RRC connection. If the eNB 10 cannot detect that the eNB 10 holds the UE context of the UE 50 even if the authentication is successful, the eNB 10 instructs to activate (activate) the UE context held by the UE 50. RRC Connection Setup message (RRC connection establishment message) not including

The UE 50 that has received the RRC Connection Setup message including information instructing activation of the UE context activates the retained UE context (bearer, security key, configuration, etc.). Activating means activating the retained UE context, and includes, for example, various radio resource settings, measurement settings, authentication key update processing, and the like. Note that the activation process is not limited to a specific process.

The RadioResourceConfigDedicated included in the RRC Connection Setup message may include parameter values related to the bearer, MAC, PHY configuration, and the like. However, the UE 50 that has received the RRC Connection Setup message including the activation instruction in Step 202 receives the RadioResourceConfigDedicated. The parameter value notified by is applied. The application is made in accordance with “5.3.105.3Radio resource configuration” in Non-Patent Document 3, for example. That is, setting is performed based on information included in RadioResourceConfigDedicated.

As an example, when the UE 50 holds the information “A” in RadioResourceConfigDedicated at the time of the previous RRC connection as part of the UE context, and receives the information “B” by RadioResourceConfigDedicated in Step 202, the UE 50 In addition to the information “A”, the information “B” can be used.

Further, the UE 50 holds information “A” in RadioResourceConfigDedicated at the time of the previous RRC connection as a part of the UE context, and is the same type as “A” but has a different value by “RadioResourceConfigDedicated” in Step 202. When “A ′” is received, the held “A” is updated (changed) by “A ′” received in step 202.

That is, according to the above processing, the parameter difference between the stored RadioResourceConfigDedicated information and the RadioResourceConfigDedicated information received in Step 202 can be set. This is called delta configuration.

Next, in step 203, the UE 50 transmits an RRC Connection Setup Complete message to the eNB 10.

<Specification change example of modification 1>
Next, description examples (extracts) of 3GPP specifications (3GPP TS 36.331, Non-Patent Document 3) in Modification 1 are shown in FIGS. In FIG. 15 to FIG. 25, the changes from Non-Patent Document 3 are underlined.

FIG. 15 shows an example of a change in the specification that defines the operation of the UE 50 when the RRC Connection Request message is transmitted from the UE 50 in Step 201 of FIG.

“1> if the UE supports the RRCConnectionRequest-r13-IEs and criticalExtRRC-ConnEstReqAllowed is included in SystemInformationBlockType2:”, “2> set the RRCConnectionRequest-r13-IEs in the RRCConnectionRequest message;” It shows that UE50 transmits the said message, when both UE50 and eNB10 support "IEs" (message which carries the authentication information in the modification 1). criticalExtRRC-ConnEstReqAllowed indicating that the eNB 10 is compatible with “RRCConnectionRequest-r13-IEs” is reported from the eNB 10 to the UE 50 by SIB2.

“1> if the UE stores the valid AS configuration into VarAS-Config:”, “2> set the ue-Identity to UE-AS-ConfigIdentity;” indicates that the UE 50 holds a valid UE context (AS configuration). In this case, the authentication information (UE-AS-ConfigIdentity) is included in ue-Identity (ue-Identity-r13 described later). Thereby, the authentication information is transmitted to the eNB 10 by the RRCRRConnection Request message. VarAS-Config is a variable for storing the UE context (AS configuration).

FIG. 16A shows an example of an RRC Connection Request message transmitted from the UE 50 in step 201 of FIG. As shown in FIG. 16A, authentication information “UE-AS-ConfigIdenity” is added. As illustrated in FIG. 16B, “UE-AS-ConfigIdenity” includes information for identifying and authenticating the AS configuration (UE context) held in the UE 50 and the E-UTRAN (that is, the eNB 10). The information includes, for example, C-RNTI, PCI, and ShortMAC-I at the previous RRC connection.

FIG. 17 shows an example of a change in the specification that defines the operation when the UE 50 receives the RRC Connection Setup message transmitted from the eNB 10 in step 202 of FIG.

In FIG. 17, “1> if> the val AS configuration is stored into VarAS-Config:”, “2> if the ue-AS-ConfigActivate is set to true and nextHopChainingCount is included in the RRCConnectionSetup message:” As described above, when receiving the RRC 当該 Connection Setup message, the UE 50 that operates according to the specification first confirms whether or not the UE context (valid AS configuration) is held. It is determined whether or not activation of the context is instructed (ue-AS-ConfigActivate is set to true) and nextHopChainingCount is included. nextHopChainingCount is a value used when updating the authentication key.

If it is determined that “UE context activation is instructed (ue-AS-ConfigActivate is set to true) and nextHopChainingCount is included,” it is determined that authentication at the eNB 10 is successful, and is retained. Activate the activated UE context.

Specifically, as described in `` 3> perform the radio resource configuration procedure in accordance with the radioResourceConfigDedicated stored into VarAS-Config and as specified in 5.3.10; '' The radio resource setting is executed according to the radioResourceConfigDedicated (radio resource setting information).

Next, as described in “3> perform 情報 the 保持 measurement configuration procedure in accordance with the measConfig stored into VarAS-Config as specified in 5.5.2 '' (Measurement configuration) is performed. Also, from “3> update the KeNB key based on the KASME key to which the current KeNB is associated, using the nextHopChainingCount value included in the RRCConnectionSetup message, as specified in TS 33.401 [32]; to apply ciphering using the previously configured algorithm, the KRRCenc key and the KUPenc key immediately, ie, ciphering shall be applied to all subsequent messages receive and sent Security key is updated according to the procedure.

On the other hand, even when the UE 50 holds the UE context, it is determined whether the activation of the UE context is instructed (ue-AS-ConfigActivate is set to true and nextHopChainingCount is included). When it becomes No (for example, when not receiving ue-AS-ConfigActivate), it can be determined that the eNB 10 does not hold the UE context. Then, as described in “2> else: 記載 3> release all the AS configuration stored into VarAS-Config;", the UE 50 releases the held UE context. “Release” means, for example, deleting the held UE context.

In both cases where the determination of “UE context activation is instructed (ue-AS-ConfigActivate is set to true) and nextHopChainingCount is included” is Yes or No The radioResourceConfigDedicated received in the RRCConnectionSetup message is applied as described in “1> perform the radio resource configuration procedure in accordance with the received radioResourceConfigDedicated and as specified in 5.3.10;". Thereby, it becomes possible to perform the delta-configuration described above.

FIG. 18A shows an example of an RRC Connection Setup message transmitted from the eNB 10 in step 202 of FIG. As shown in FIG. 18A, ue-AS-ConfigActivate and nextHopChainingCount are added. As illustrated in FIG. 18B, ue-AS-ConfigActivate indicates that the UE 50 resumes the use of the UE context that has been held.

As described above, the eNB 10 transmits an RRC connection Reject message to the UE 50 in the case of authentication NG. Regardless of whether or not the authentication is NG, the eNB 10 may reject the RRC Connection due to congestion, for example, and may send an RRC connection Reject message to the UE 50.

In Modification 1, the UE 50 that has received the RRC connection Reject message executes, for example, the following Option 1 or Option 2 operation.

Option-1: UE50 releases it when it is instructed to release AS configuration (UE context) in RRC connectionReject. On the other hand, if not (if there is no release instruction), AS configuration is retained.

Option-2: UE50 keeps holding it when it is instructed to hold (storing) AS-configuration in RRC connection-Reject. Conversely, if not (if there is no instruction to hold), the AS configuration is released.

FIG. 19 shows an example of a UE operation specification change when receiving an RRC connection Reject corresponding to Option 1 and FIG. 20 shows an example of a UE operation specification change when receiving an RRC connection Reject corresponding to Option 2.

As shown in FIG. 19, “1> if> ue-AS-ConfigRelease is included and the UE stores the AS configuration into VarAS-Config specified in 7.1: 2> release the AS configuration stored into VarAS-Config; Upon receiving the release instruction (ue-AS-ConfigRelease), the UE 50 releases the UE context. There is no release instruction as described in “1> else if ue-AS-ConfigRelease is not included and the UE stores the AS configuration into VarAS-Config: 2> keep storing the AS configuration into VarAS-Config; If so, the UE 50 continues to hold the UE context.

Also, when there is no release instruction, as described in `` 2> if2ue-AS-ConfigValidityTime is included: 3> overwrite the AS configuration validity time with the received value in ue-AS-ConfigValidityTime; '' Overwrite the context validity time (validity time) with the value of ue-AS-ConfigValidityTime. Thereby, the preservation | save time (after-mentioned) of UE context can be changed.

As shown in FIG. 20, “1> if ue-AS-ConfigStoring is included and the UE stores the AS configuration into VarAS-Config specified in 7.1: 2> keep the AS configuration stored into VarAS-Config; In option IV2, the UE 50 continues to hold the UE context when receiving the holding instruction (ue-AS-ConfigStoring). Also, in the case where there is a holding instruction, the UE is described as `` 2> if ue-AS-ConfigValidityTime is included: 3> overwrite the AS configuration validity time with the received value in ue-AS-ConfigValidityTime; '' Overwrite the context validity time (validity time) with the value of ue-AS-ConfigValidityTime.

In addition, as described in `` 1> else if ue-AS-ConfigStoring is not included and the UE stores the AS configuration into VarAS-Config: 2> release the AS configuration into VarAS-Config; If not, the UE 50 releases the UE context.

FIGS. 21A and 21B show an example of changing the specification of the RRC connection Reject message corresponding to Option 1, and Figs. 22A and 22B show an example of the specification change of the RRC connection Reject message corresponding to Option 2. As shown in FIGS. 21A, 21B, 22A, and 22B, ue-AS-ConfigValidityTime indicates the updated maximum retention time of the UE context during the RRC idle state.

<Regarding RRC Connection Release Procedure in Modification 1>
The RRC connection release procedure in the first modification is the same as the procedure described with reference to FIG. The message contents shown in FIGS. 13 and 14 may be used, or other examples may be used as described below.

FIG. 23A shows an example 3 of the RRC Connection Release message transmitted from the eNB 10 in step 301 of FIG. As shown in FIG. 23A, ue-AS-ConfigDeactive is included. ue-AS-ConfigDeactive corresponds to the UE context holding instruction described above. Further, ue-AS-ConfigValidityTime indicating a period (time) for holding the UE context is added. As shown in FIG. 23B, ue-AS-ConfigDeactive indicates that the UE 50 holds the UE context while in the RRC idle state. ue-AS-ConfigValidityTime indicates the maximum time (holding time limit) for holding the UE context while the UE 50 is in the RRC idle state.

FIG. 24 shows an example of a change in the specification that defines the operation of the UE 50 that receives the RRC Connection Release message when the RRC Connection Connection Release message shown in FIGS. As shown in the underlined portion of FIG. 24, the UE 50 operating according to the specification confirms that ue-AS-ConfigDeactive is included in the RRC Connection Release message (ue-AS-ConfigDeactive is set to true) As the UE context, the current radioResourceConfigDedicated (radio resource setting information), securityAlgorithmConfig (security algorithm setting information), and measConfig (measurement setting information) are stored in VarAS-Config. Moreover, UE50 stores PCell's physCellId in VarAS-Config, and stores the current ue-Identity in VarAS-Config.

<About UE context retention period>
The UE 50 (and the eNB 10) that has received the RRC Connection Release message including the UE context holding instruction and has shifted to the RRC idle state basically keeps holding the UE context during the RRC idle state. However, when the period in the RRC idle state is very long, for example, the UE 50 and the eNB 10 continue to hold the UE context becomes a load on each of the UE 50 and the eNB 10.

Therefore, in the first modification, the UE 50 provides a finite time (UE context retention time limit) that the UE context retains. As already described, ue-AS-ConfigValidityTime indicates the time.

For example, when the time is T, the UE 50 receives the RRC Connection Release message including the UE context holding instruction, transitions to the RRC idle state, and maintains the UE context, while the RRC idle state continues. It is determined that the UE context has become invalid when T has elapsed from the time when the UE context is held (= the time when the RRC Connection Release message including the UE context holding instruction is received), and the UE context is released ( delete. The same time T is also set in the eNB 10, and the eNB 10, like the UE 50, has passed T from the time when the UE context is held (= the time when the RRC Connection Release message including the UE context holding instruction is transmitted). At this point, it is determined that the UE context has become invalid, and the UE context is released (deleted).

FIG. 25 shows a modification example of the specification (Non-Patent Document 3) in the case where the UE context retention period as described above is provided. FIG. 25 shows that VarAS-Config, which is a variable that holds the UE context, is added to “7.1 UE variables” of the specification. As illustrated in FIG. 25, VarAS-Config includes a UE context (AS configuration) stored in UE 50 during the RRC idle state. In addition, the UE 50 determines that the UE context has become invalid when a predetermined period (the above T) has elapsed after leaving the RRC connection state.

Also, as shown in FIG. 25, VarAS-Config includes RadioResourceConfigDedicated, SecurityAlgorithmConfig, MeasConfig, NextHopChainingCount, PhysCellId, S-TMSI, and C-RNTI as the UE context (AS configuration). However, these are examples, and some of them may not be retained. Information other than these may be held.

The predetermined period for holding the UE context (the above T) may be fixed according to the specification, or set from the eNB 10 to the UE 50 using ue-AS-ConfigValidityTime as in the example of FIG. It is good.

Providing the UE context retention period as described above is also applicable to the basic example.
(Modification 2: Context Fetch)
As described above in the example of FIG. 9, even when the UE 50 moves to the cell of the eNB 20 that does not have the UE context, the eNB 20 identifies the eNB 10 based on the information notified from the UE 50, and the UE 50 of the UE 50 from the eNB 10 It is possible to obtain a context and make an RRC connection using the UE context. Thus, it is called Context Fetch that a certain eNB acquires a UE context from another eNB.

In the following, when the UE 50 changes from the RRC connected state to the RRC idle state under the control of the eNB 10 and then the UE 50 moves in a cell under the control of the eNB 20 different from the eNB 10 (example: case shown in FIG. 9), the eNB 20 The process for acquiring the UE context will be described. Note that each of the eNB 10 and the eNB 20 has a context holding function and a function of executing a context acquisition procedure as described below.

First, the process between the UE 50 and the eNB 20 will be described with reference to FIG. As a premise of the process illustrated in FIG. 26, the UE 50 is in an RRC idle state and holds a UE context at the time of connection with the eNB 10. Then, the UE 50 moves to the cell under the eNB 20 in the RRC idle state, and when the call is made or when the incoming procedure is received, the transition procedure to the RRC connected state is activated. Suppose.

In Step 451, Random Access Preamble is transmitted from the UE 50 to the eNB 20, and in Step 452, Random Access Response is returned from the eNB 20 to the UE 50.

In step 453, the UE 50 transmits an RRC Connection Request message to the eNB 20. In the message transmitted in step 453, information specifying the eNB (in this case, eNB 10) holding the eNB-side UE context corresponding to the UE context held by the UE 50, and specifying that the UE context belongs to the UE 50 Information (information for specifying the UE context of the UE 50). Further, the RRC Connection Request message includes authentication information for authenticating the UE context of the UE 50. The authentication information is, for example, C-RNTI, PCI, and ShortMAC-I at the previous RRC connection.

In this example, an ID (herein referred to as “resume ID”) having information identifying the eNB and information identifying the UE context is included in the RRC Connection Request message.

For example, the bit length of the resume ID transmitted in the RRC Connection Request message is 24 bits. Then, for example, the eNB and the UE context are made with the upper few bits and the lower few bits of the resume ID. As an example, the upper 8 bits in the resume ID transmitted in the RRC Connection で Request message may be information for specifying the eNB, and the lower 16 bits may be information for specifying the UE context. These numerical values are only examples.

However, in general, since it is assumed that many eNBs hold many UE contexts, a case where the eNB holding the UE context of a specific UE cannot be specified with a 24-bit resume ID may occur. That is, for example, when the eNB 20 has information (addresses, etc.) of a plurality of eNBs (destination candidate eNBs that perform Context Fetch) corresponding to the information for eNB identification in the resume ID of the RRC Connection Connection Request message, It cannot be determined to which eNB Context Fetch may be performed.

Therefore, in this example, in such a case, the eNB requests the UE from the eNB for a resume ID (this is called a long resume ID) that is longer than the resumeresID (this is called a short resume ID). It is said. The following steps are examples for making such a request. The short resume ID is an example of context holding information indicating that the UE holds the UE context.

In step 454, the eNB 20 transmits an RRC Connection Setup message including information requesting the UE 50 for a long resume ID to the UE 50. The RRCRRConnection Setup message includes information for activating the UE context. In step 455, the UE 50 transmits an RRC Connection Setup Complete message including long resume ID to the eNB 20.

The bit length of long resume ID is 40 bits, for example. Then, for example, it is conceivable that the upper 24 bits in the long resume ID are information for specifying the eNB and the lower 16 bits are information for specifying the UE context. These numerical values are only examples.

Also, a combination of short resume ID and long resume ID may be used. For example, the UE context may be specified by the first (upper) 16 bits of short resume ID, and the eNB may be specified by “remaining 8 bits of short resume ID + 40 bits of long resume ID = 48 bits”. Also, the resume ID is set to a predetermined bit length (eg, 40 bits), the first predetermined bit (eg, 24 bits) is included in the RRCRRConnection Request message, and the remaining predetermined bits (eg, 16 bits) are included in the RRC Connection Setup. It may be included in the Complete message.

Also, for example, the short resume ID included in the RRC Connection Request message is 40 bits, and the short resume ID is added to the eNB identification information and the UE context identification information, and the authentication of the UE corresponding to the UE context. (Information corresponding to shortMAC-I) may be included. Similarly, for example, in addition to the information for identifying the eNB and the information for identifying the UE context, information for authenticating the UE corresponding to the UE context (corresponding to shortMAC-I) Information).

If the eNB and UE context can be identified by the short Resume ID, the RRC Connection Setup is transmitted in Step 454 and the RRC Connection Setup Complete is transmitted in Step 455, but the long Resume ID request and the long Resume ID are requested. Does not include transmission. Further, when the short Resume ID indicates itself (eNB 20), that is, when the eNB 20 holds the UE context, Context Fetch for other eNBs is not performed. However, even when the eNB and the UE context can be identified by the short Resume ID, the request for the long Resume ID and transmission of the long Resume ID may be included.

In step 460, the eNB 20 identifies the eNB 10 as the eNB that holds the UE context based on the resume ID received from the UE 50 (only the short resume ID, only the long resume ID, or the combination of the long resume ID and the short resume ID). Context acquisition procedure is executed with

Next, an example of a context acquisition procedure will be described with reference to FIG. In step 455, the UE 50 transmits an RRC Connection Setup Complete message to the eNB 20.

In step 461, the eNB 20 transmits a context request message to the eNB 10 identified by the resume ID. The context request message includes a resume ID and authentication information. As will be described later, when resume 認証 ID itself includes authentication information, authentication information other than resume ID may not be included.

In step 461, the eNB 10 that has received the context request message stores information in the eNB 10 based on information identifying the UE context of the UE 50 (eg, lower 16 bits of short resume ID, lower 16 bits of long resume ID, etc.). The UE context of the UE 50 is identified and acquired from a plurality of held UE contexts, and authentication is performed using authentication information. Here, it is assumed that the authentication is successful.

In step 462, the eNB 10 transmits a context response message including the acquired UE context to the eNB 20.

ENB20 which acquired UE context of UE50 transmits the RRC | Connection * Reconfiguration message to UE50 in step 471, for example. In step 472, the UE 50 transmits an RRC Connection Reconfiguration Complete message to the eNB 20. Thereby, UE50 and eNB20 reuse UE context, establish the connection between UE50 and eNB20, and make a state change to a RRC connection state.

Note that the UE 50 and the eNB 20 can establish the RRC connection between the UE 50 and the eNB 20 by reusing the retained / acquired UE context, and therefore the steps 471 and 47 may not be executed. Alternatively, the UE 50 may ignore a part or all of the configuration information received by the RRC Connection Reconfiguration message. Moreover, you may apply the configuration information received with a RRC | Connection | Reconfiguration message, without ignoring.

Also, when the eNB 20 has executed the context acquisition procedure but failed to acquire the target UE context (step 473), for example, an RRC Connection Release message is transmitted, and the UE 50 is set in the RRC idle state (step 474).

<Specification change example of modification 2>
Next, description examples (extracts) of the 3GPP specifications (3GPP TS 36.331, Non-Patent Document 3) in Modification 2 are shown in FIGS. In FIG. 28 to FIG. 30, the changed part from Non-Patent Document 3 is underlined.

FIG. 28A shows an example of an RRC Connection Request message transmitted from the UE 50 in Step 453 of FIG.

As shown in FIG. 28A, in addition to UE-AS-ConfigIdenity that is authentication information, a shortResumeIdentity corresponding to the short-resume ID described above is added. As shown in FIG. 28B, shortResumeIdentity in this example is a 24-bit identifier for identifying the UE context (AS configuration) and the eNB that stores the UE context.

FIG. 29A shows an example of the RRC Connection Setup message transmitted from the eNB 20 in step 454 of FIG. As shown in FIG. 29A, requestLongResumeIdentity is shown in addition to the ue-AS-ConfigActivate and nextHopChainingCount described above. requestLongResumeIdentity corresponds to the request for long resume ID described above. As illustrated in FIG. 29B, requestLongResumeIdentity indicates that the UE is requested to provide longResumeIdentity (long resume ID).

FIG. 30A shows an example of the RRC Connection Setup message transmitted from the UE 50 in Step 455 of FIG.

As shown in FIG. 30A, a longResumeIdentity corresponding to the long-resume ID described above is added. As illustrated in FIG. 30B, longResumeIdentity in this example is a 40-bit identifier for identifying a UE context (AS configuration) and an eNB that stores the UE context.

The RRC Connection Request message and the RRC Connection Setup Complete message may have the contents shown in FIGS. 31A and 31B and FIGS. 32A and 32B. Again, the RRCRRConnection Setup message is the same as that shown in FIGS. 29A and 29B.

FIG. 31A shows an example of an RRC Connection Request message transmitted from the UE 50 in step 453 of FIG.

As shown in FIG. 31A, shortResumeIdentity corresponding to short resume ID is added in addition to UE-AS-ConfigIdenity which is authentication information. As shown in FIG. 31B, the shortResumeIdentity in this example identifies the UE context (AS configuration) and the eNB that stores the UE context, and further identifies a 40-bit identifier for authenticating the UE corresponding to the UE context. It is. In the present embodiment, “authenticating the UE corresponding to the UE context” also means “authenticating that the UE is a person in the stored UE context”. In this example, shortMAC-I may not be included in UE-AS-ConfigIdenity.

FIG. 32A shows an example of the RRC Connection Setup message transmitted from the UE 50 in Step 455 of FIG.

As shown in FIG. 32A, a longResumeIdentity corresponding to a longresume ID is added. As shown in FIG. 32B, the longResumeIdentity in this example identifies the UE context (AS configuration) and the eNB that stores the UE context, and also a 56-bit identifier for authenticating the UE corresponding to the UE context. It is.

Also, the RRC Connection Request message and RRC Connection Setup Complete message may have the contents shown in FIGS. 33A and B and FIGS. 34A and B. Again, the RRCRRConnection Setup message is the same as that shown in FIGS. 29A and 29B. In the examples shown in FIGS. 33A and B and FIGS. 34A and B, the resume ID is 40 bits as a whole, the first 24 bits are included in the RRC Connection Request message, and the remaining 16 bits are included in the RRC Connection Setup message. Even in this case, for the sake of convenience, the first 24 bits included in the RRC Connection Connection Request message are referred to as a “short Resume ID”, and an identifier including the remaining 16 bits included in the RRC Connection Connection Setup message and the first 24 bits is “long”. It may be called “resume ID”.

FIG. 33A shows an example of an RRC Connection Request message transmitted from the UE 50 in Step 453 of FIG.

As shown in FIG. 33A, in addition to UE-AS-ConfigIdenity which is authentication information, resumeIdentity-LSB corresponding to the above short-resume ID is added. As illustrated in FIG. 33B, the resumeIdentity-LSB is the least significant 24 bits in the UE context (AS configuration) and the resume identity for identifying the eNB storing the UE context.

FIG. 34A shows an example of the RRC Connection Complete message transmitted from the UE 50 in step 455 of FIG.

As shown in FIG. 34A, resumeIdentity-MSB is added. As shown in FIG. 34B, the resumeIdentity-MSB is the most significant (most significant) 16 bits in the UE context (AS configuration) and the resume identity for identifying the eNB storing the UE context.

Also, the RRC Connection Request message and RRC Connection Setup Complete message may have the contents shown in FIGS. 35A and B, and FIGS. 36A and B. Again, the RRCRRConnection Setup message is the same as that shown in FIGS. 29A and 29B. In the examples shown in FIGS. 35A and 35B and FIGS. 36A and 36B, information for authenticating the UE corresponding to the UE context is added to the resume ID shown in FIGS. 33A and 33B and FIGS. 34A and 34B.

FIG. 35A shows an example of an RRC Connection Request message transmitted from the UE 50 in Step 453 of FIG.

As shown in FIG. 35A, resumeIdentity-LSB is added in addition to UE-AS-ConfigIdenity which is authentication information. As illustrated in FIG. 35B, the resumeIdentity-LSB in this example identifies the UE context (AS configuration) and the eNB that stores the UE context, and further resume_identity for authenticating the UE corresponding to the UE context. The least significant 40 bits.

FIG. 36A shows an example of the RRC Connection Setup message transmitted from the UE 50 in Step 455 of FIG.

As shown in FIG. 36A, resumeIdentity-MSB is added. As shown in FIG. 36B, the resumeIdentity-MSB in this example identifies the UE context (AS configuration) and the eNB that stores the UE context, and further resume resume identity for authenticating the UE corresponding to the UE context. Most significant 16 bits.

(Variation 3: UE context holding function determination)
As described with reference to FIG. 7 and the like, in the present embodiment, the UE 50 notifies the eNB 10 that the UE context is held. This is based on the premise that the eNB 10 corresponds to a UE context holding function (a function for performing connection by reusing a retained UE context, or a function for performing connection by reusing a UE context acquired by Context Fetch). It is said.

However, not all eNBs support the UE context maintenance function. For example, it is assumed that the UE 50 is in an RRC idle state while holding the UE context under the control of the eNB 10 and moves to an eNB-X cell that does not hold the UE context holding function. Here, even if the information indicating that the UE 50 holds the UE context is notified to the eNB-X, the eNB-X cannot understand the information. From the viewpoint of performing a stable operation, the UE 50 desirably performs the UE context retention notification operation described in FIG. 7 or the like when it is confirmed that the eNB of the cell in the area has the UE context retention function.

In this third modification, an example will be described in which the UE 50 determines whether the eNB 10 has a UE context holding function. The third modification can be applied to any one of the first modification, the second modification, and the basic example. Examples 1 to 3 will be described below. Note that the “UE context maintenance function” in Modification 3 is a function of using (ie, reusing) the UE context held in a state that is not in the RRC connection state and establishing an RRC connection from the state. . In addition, the eNB does not have a UE context holding function, or the eNB does not support the UE context holding function, not only when the eNB does not hold the UE context holding function as a capability, but also as a capability. Includes the case where the function is stopped.

<Example 1>
In Example 1, the eNB 10 notifies the UE 50 of information indicating whether or not the eNB 10 is compatible with the UE context holding function using the notification information. As the notification information, for example, MIB, SIB1, and SIB2 can be used. As described above, criticalExtRRC-ConnEstReqAllowed reported by SIB2 is an example of the information.

With reference to the flowchart of FIG. 37, the operation example of UE50 regarding determination of UE context holding | maintenance function is demonstrated. In the following example, the eNB 10 broadcasts information indicating whether or not the UE context holding function is supported using the SIB1.

In step 501, the UE 50 receives SIB1 from the eNB 10. In step 502, the UE 50 reads information indicating whether the eNB 10 is compatible with the UE context holding function from the SIB1, and determines whether the eNB 10 is compatible with the UE context holding function based on the information. To do.

If the determination result in step 502 is Yes (corresponding), the process proceeds to step S503, and the UE 50 executes the procedure described in FIG. 7 and the like when transitioning to the RRC connection state. That is, the UE 50 performs notification of information indicating that the UE context is held. Note that although S503 in FIG. 34 describes that the procedure shown in FIG. 7 is executed, this is an example, and for example, the procedure shown in FIG. 26 may be executed.

If the determination result in step 502 is No (not supported), the process proceeds to step S504, and the UE 50 discards the held UE context and does not use a spare bit or the like when transitioning to the RRC connection state. A normal RRC Connection Request (or no authentication information or the like) is transmitted to the eNB 10.

<Example 2>
In Example 2, the eNB 10 notifies the UE 50 by Random Access Response in the random access procedure whether the eNB 10 supports the UE context holding function.

An example of the operation of the UE 50 in Example 2 will be described with reference to the flowchart in FIG. Here, for example, a situation is shown in which the UE 50 in the RRC idle state receives paging (or makes a call) and transitions to the RRC connected state.

In step 601, UE 50 transmits Random Access Preamble to eNB10. In step 602, the UE 50 receives Random Access Response from the eNB 10. The Random Access Response includes information indicating whether the eNB 10 supports the UE context holding function.

In step 603, the UE 50 reads information indicating whether or not the eNB 10 supports the UE context holding function from the Random Access 、 Response, and whether or not the eNB 10 supports the UE context holding function based on the information. Determine.

When the determination result in step 603 is Yes (corresponding), the process proceeds to step S604, and the UE 50 executes the procedure described in FIG. That is, the UE 50 performs notification of information indicating that the UE context is held. Note that although S604 in FIG. 38 describes that the procedure shown in FIG. 7 is executed, this is an example, and for example, the procedure shown in FIG. 26 may be executed.

If the determination result in step 603 is No (not supported), the process proceeds to step S605, and the UE 50 discards the held UE context and transmits a normal RRC Connection Request that does not use spare bits to the eNB 10 .

39 and 40 show examples of Random Access response messages in Example 2 of Modification 3 (see Non-Patent Document 4 for the conventional example). As shown in FIG. 39, MAC RAR is included in the MAC PDU. As shown in FIG. 40, in Example 2, information indicating whether or not the UE context holding function is supported is notified using a reserve bit in the MAC RAR. As an example, if the bit is 1, it indicates that the UE context holding function is supported, and if it is 0, it indicates that it is not supported. 1 and 0 may be reversed.

<Example 3>
For example 3, the basic example is targeted. In Example 3, the UE 50 maintains the UE context holding function in the eNB 10 based on whether or not the above-described ue-ContextStored (information indicating that the eNB 10 holds the UE context corresponding to the UE 50) is included in the RRC Connection Setup message. Judge whether or not it is compatible.

That is, in Example 3, the UE 50 always notifies the eNB that the UE context is held by the RRC Connection Request, and executes the operation shown in FIG. However, here, whether or not the UE context holding function is supported in the eNB 10 is determined based on the RRC Connection Setup message.

An example of the operation of the UE 50 in Example 3 will be described with reference to the flowchart in FIG. For example, when the UE 50 in the RRC idle state attempts to transition to the RRC connection state, in step 701, the UE 50 transmits an RRC Connection Request message including information indicating that the UE context is held to the eNB 10 .

In step 702, the UE 50 receives the RRC Connection Setup message from the eNB10. In step 703, the UE 50 determines whether or not ue-ContextStored is included in the RRC Connection Setup message. If the determination result is Yes (included), the UE 50 proceeds to step 704, and the determination result is No ( If it is not included, the process proceeds to step 705.

In step 704, the UE 50 continuously uses the held UE context, and transmits an RRC Connection Complete message similar to that in step 203 in FIG.

In step 705, the UE 50 discards the held UE context, and creates a UE context (bearer, MAC config, PHY config, etc.) reflecting the setting value in RadioResourceConfigDedicated included in the RRC Connection Setup message. Used for connection (communication) with the eNB 10. After step 705, the normal RRC connection procedure is executed.

(Modification regarding RRC Connection Setup message: Modification of LCID)
As described above, in the RRC connection establishment procedure in the present embodiment, UE 50 transmits an RRC Connection Request message including information indicating that the UE context is held.

By the way, between the UE and the eNB in the present embodiment, data is basically transmitted and received using DRB (Data Radio Bearer). Here, this method is called a “DRB method”. On the other hand, a method for transmitting / receiving data using SRB (Signaling Radio Bearer) has been proposed, assuming application to IoT (Internet of Things) and MTC (Machin Type Communication) in which a small amount of data is transmitted and received (non- Patent Document 5). Here, this method is called an “SRB method”. The SRB method can also be applied in this embodiment.

However, even if both the DRB method and the SRB method are supported on the eNB side, the eNB may not operate properly unless the eNB side knows which method the connected UE supports. .

Therefore, in this modified example (referred to as an LCID modified example), in the RRC connection establishment procedure shown in FIG. 7 (or FIG. 26 may be used), the UE 50 responds to each of the DRB method and the SRB method in the RRC Connection Request message. ENB 10 is notified of whether or not However, when the information bit is added by increasing the size of the RRC Connection Request message, the reception quality on the eNB side of the RRC Connection Request message transmitted from the cell edge UE is lowered, and as a result, the quality deterioration of the cell edge UE, the cell It may lead to a reduction in radius. In this modification, notification is performed as follows.

The RRC Connection Request message is transmitted by the MAC PDU using the PUSCH resource allocated by the UL grant included in the Random Access Response. Further, the RRC Connection Request message is transmitted by CCCH (Common Control Channel, common control channel) from the viewpoint of the logical channel.

Therefore, in this modification, using the LCID (Logical Channel ID) of the MAC header attached to the MAC PDU, whether the UE 10 supports each of the DRB scheme and the SRB scheme. To the eNB 10.

42A and 42B show specifications (examples of changes from the current specifications) that define the operation related to the MAC of the communication system of the present modification. The changes from the current MAC specification (Non-Patent Document 4) are underlined.

42A and 42B, when the UE supports only the SRB scheme, the CCCH is specified using the LCID “01100”. When the UE supports only the DRB scheme, the CCCH is specified using the LCID “01101”. When the UE supports both the SRB scheme and the DRB scheme, the CCCH is specified using the LCID “01110”. Note that these values are examples.

For example, when an RRC Connection Request message is transmitted from the UE 50 with a MAC PDU designating the LCID “01100” and the eNB 10 receives the RRC Connection Request message, the eNB 10 recognizes that the UE 50 supports only the DRB method. Then, data transmission / reception using DRB is performed.

In addition, when the RRC Connection Request message is transmitted from the UE 50 with the MAC PDU specifying the LCID “01101” and the eNB10 receives the RRC Connection Request message, the eNB10 recognizes that the UE50 supports only the SRB scheme. Then, data transmission / reception using the SRB is performed.

In addition, when the RRC Connection Request message is transmitted from the UE 50 with the MAC PDU designating the LCID “01110” and the eNB10 receives the RRC Connection Request message, the eNB10 supports the UE50 in both DRB and SRB methods. Know that you are. In this case, for example, the eNB 10 determines which of the DRB scheme and the SRB scheme is to be executed according to the capability of the UE 50 and the like.

With the above method, it is possible to notify whether the DRB method / SRB method can be supported without increasing the size of the RRC Connection Request message.

In the above example, when transmitting the RRC Connection Request message, the LCID is used to notify whether the DRB method / SRB method can be supported. In the message, LCID may be used to notify whether the DRB method / SRB method is supported.

(Variation 4: Regarding a variation regarding the retention period of the UE context)
In the first modification described above, the UE 50 determines that the UE context has become invalid when a predetermined period T during which the UE context is retained has elapsed from the time when the UE context has been retained, and releases the UE context. (Deleted). That is, according to the first modification, the UE 50 operates to maintain the UE context as long as the predetermined period T does not expire, regardless of the radio access technology (RAT) of the cell to be reselected. However, the UE 50 is not limited to this, and may release (delete) the UE context according to the conditions described below. In addition, cell reselection intends the operation | movement which UR50 which once changed from the RRC connection state to the RRC idle state selects (reselects) the cell which changes to an RRC connection state, for example, UE50 is another cell. And an operation of selecting one of the overlapped cells.

<Example 1-1>
When performing cell reselection, the UE 50 reselects a cell other than LTE such as UMTS or GSM (registered trademark) if the cell to be reselected is a cell other than LTE. ), The UE context may be released (deleted). In this case, the UE 50 holding the UE context attempts to establish an RRC connection in a cell to be reselected (with a RAT other than LTE) (that is, when a request to establish an RRC connection is transmitted to the base station). In addition, the UE context may be released (deleted), or the UE context may be released (deleted) after an RRC connection is established in a cell to be reselected (with another RAT other than LTE). May be.

In addition, the UE 50 holding the UE context until the RRC connection is established in the reselecting cell (with other RAT other than LTE) (that is, until the RRC connection is established in the reselecting cell). The UE context may be released (deleted) at any timing. FIG. 43 shows a specification change example (TS36.304) in this case.

When the UE 50 once accesses a cell other than LTE, it is considered that the possibility of reselecting the LTE cell immediately is low, so the memory usage of the UE 50 can be reduced.

<Example 1-2>
When the UE 50 performs cell reselection, the cell to be reselected is a cell other than LTE (for example, reselects a cell other than LTE such as UMTS, GSM (registered trademark)). Alternatively, the UE context may not be released (deleted). Even if the UE 50 once accesses a cell other than LTE, the UE context can be reused when there is a possibility of reselecting the LTE cell immediately.

<Example 2-1>
When performing cell reselection, the UE 50 indicates that the cell to be reselected is an LTE cell, and the broadcast information (SIB2) of the cell indicates that the eNB 10 supports the UE context holding function. If no information is included, the UE context may be released (deleted). In addition, when the UE 50 performs cell reselection, the cell to be reselected is an LTE cell, and the eNB 10 supports the UE context holding function in the broadcast information (SIB2) of the cell. May be prevented from being released (deleted). The information indicating that the eNB 10 is compatible with the UE context holding function may be information indicating whether the eNB 10 is compatible with the UE context holding function described in <Example 1> of the third modification. Alternatively, “up-CIOT-EPS-Optimisation” may be set in SIB2 (the same applies to Example 2-2 below). Accordingly, the UE 50 can reduce the memory usage of the UE 50 when the eNB 10 does not support the UE context holding function in the cell to be reselected.

Note that also in the third modification, the information indicating whether or not the eNB 10 supports the UE context holding function may be expressed by whether or not “up-CIOT-EPS-Optimisation” is set in the SIB2. .

<Example 2-2>
When the UE 50 performs cell reselection, when the cell to be reselected is an LTE cell, the broadcast information of the cell includes information indicating that the eNB 10 is compatible with the UE context holding function. The UE context may not be released (deleted) regardless of the case and the case where the UE context is not included. Thereby, even when the eNB 10 does not support the UE context holding function, the UE context can be reused when the eNB 10 of the cell to be reselected thereafter supports the UE context holding function. become. FIG. 44 shows a specification change example (TS36.304) corresponding to <Example 2-2>.

As described above, according to the modified example 4, when the UE 50 in the RRC idle state performs cell reselection, the conditions for holding or releasing the UE context are clarified.

In <Example 1-1>, <Example 1-2>, <Example 2-1>, and <Example 2-2> of Modification 1 and Modification 4, “UE context” It may be replaced with ResumeID ". Moreover, the above modification 4 is applicable to any of the basic example, the modification 1, the modification 2, and the modification 3. Also, <Example 1-1> or <Example 1-2> of Modification 4 above may be combined with <Example 2-1> or <Example 2-2>.

(Device configuration example)
Next, a configuration example of the apparatus in the embodiment of the present invention will be described. The configuration of each device described below shows only a functional unit particularly related to the embodiment of the invention, and operates as a device in a communication system compliant with at least LTE (LTE including EPC). It also has a function not shown. Moreover, the functional configuration shown in each figure is only an example. As long as the operation according to the present embodiment can be executed, the function classification and the name of the function unit may be anything.

<Configuration example of MME and S-GW>
First, a configuration example of the MME 30 and the S-GW 40 will be described with reference to FIG. As illustrated in FIG. 45, the MME 30 includes an eNB communication unit 31, an SGW communication unit 32, and a communication control unit 33.

The eNB communication unit 31 includes a function of transmitting and receiving control signals to and from the eNB through the S1-MME interface. The SGW communication unit 32 includes a function of transmitting / receiving control signals to / from the S-GW through the S11 interface.

When the communication control unit 33 receives a connection maintenance instruction signal from the eNB, the communication control unit 33 instructs the SGW communication unit 32 to transmit the connection maintenance instruction signal to the S-GW, and receives a confirmation response from the S-GW In addition, the SGW communication unit 32 is instructed to transmit the confirmation response to the eNB.

45, the S-GW 40 includes an eNB communication unit 41, an MME communication unit 42, an NW communication unit 43, and a communication control unit 44.

The eNB communication unit 41 includes a function of transmitting / receiving data to / from the eNB through the S1-U interface. The MME communication unit 42 includes a function for transmitting and receiving control signals to and from the MME through the S11 interface. The NW communication unit 43 includes a function of transmitting / receiving a control signal and transmitting / receiving data to / from a node device on the core NW side.

The communication control unit 44 includes a function of instructing the MME communication unit 42 to transmit a confirmation response to the MME when a connection maintenance instruction signal is received from the MME. Further, when the communication control unit 44 receives the connection maintenance instruction signal from the MME, when receiving the downlink data to the corresponding UE, the NW communication unit 43 holds the downlink data in the buffer. And a function to instruct the NW communication unit 43 to transmit the downlink data when the RRC connection establishment completion is received from the eNB.

Note that the MME 30 and the S-GW 40 can be configured as one device. In that case, communication of the S11 interface between the SGW communication unit 32 and the MME communication unit 42 is communication inside the apparatus.

Next, configuration examples of the UE 50 and the eNB 10 in the embodiment of the present invention (including the basic example, the modified example 1, the modified example 2, the modified example 3, and the LCID modified example) will be described. Note that each of the UE 50 and the eNB 10 described below may have the functions of the basic example and all the modified examples, or any one of the functions of the basic example and all the modified examples. It is also possible to have any one of the functions of the basic example and all the modified examples.

<User device UE>
In FIG. 46, the functional block diagram of a user apparatus (UE50) is shown. As illustrated in FIG. 46, the UE 50 includes a DL signal reception unit 51, a UL signal transmission unit 52, an RRC processing unit 53, and a UE context management unit 54. FIG. 46 shows only functional units that are particularly relevant to the present invention in the UE 50, and the UE 50 also has a function (not shown) for performing an operation based on at least LTE.

The DL signal receiving unit 51 includes a function of receiving various downlink signals from the base station eNB and acquiring higher layer information from the received physical layer signal, and the UL signal transmitting unit 52 is transmitted from the UE 50. It includes a function of generating various signals of the physical layer from information on higher layers to be transmitted and transmitting the signals to the base station eNB. In addition, the UL signal transmission unit 52 includes a function of notifying the eNB 10 of the availability of the DRB method / SRB method using the LCID when transmitting an RRC 送信 Connection Request message or the like.

The RRC processing unit 53 is described with reference to FIG. 7, FIG. 8, FIG. 10 to FIG. 41, etc., UE side determination processing, RRC message generation / transmission (transmission is performed via the UL signal transmission unit 52) The RRC message received by the DL signal receiving unit 51 is interpreted, and an operation based on the interpretation is performed. In addition, transmission / reception of the MAC signal in the random access procedure described with reference to FIGS. 38 to 40 may be performed by the DL signal receiving unit 51 and the UL signal transmitting unit 52. The RRC processing unit 53 also includes a function of resuming the RRC connection using the UE context held in the UE context management unit 54. As the restart function, for example, in the first modification, there is a UE context validation processing function when an activation instruction is received from the eNB.

The UE context management unit 54 includes storage means such as a memory, and holds a UE context and a UE identifier (S-TMSI or the like) in the RRC idle state based on the instruction described in FIG. Further, in the procedures shown in FIG. 7, FIG. 26, etc., it is determined whether or not the UE context is held, and when the UE context is held, information indicating that the UE context is held is notified. The RRC processing unit 53 is instructed. Further, the UE context management unit 54 regards the held UE context as invalid when a predetermined time (T) has elapsed in the RRC idle state from the time when the RRC connected state has changed to the RRC idle state. , Including the ability to release the UE context. Further, the UE context management unit 54 selects whether to release the UE context as invalid according to the radio access technology (for example, GSM (registered trademark), UMTS, LTE, etc.) of the cell to be reselected. Includes functionality. Further, when the radio access technology of the cell to be reselected is LTE, the UE context management unit 54 regards the UE context as invalid based on whether or not the eNB 10 supports the function of releasing the UE context, and releases the UE context. It includes a function to select whether or not to do. In addition, when the UE context management unit 54 performs cell reselection with a RAT different from the current RAT while holding the UE context, the UE context management unit 54 is in a period until the RRC connection is established with the different RAT (in the cell to be reselected). Includes a function to release (delete) the UE context.

The configuration of the UE 50 shown in FIG. 46 may be entirely realized by a hardware circuit (eg, one or a plurality of IC chips), a part is constituted by a hardware circuit, and the other part is a CPU and a program. And may be realized.

FIG. 47 is a diagram illustrating an example of the hardware (HW) configuration of the UE 50. FIG. 47 shows a configuration closer to the mounting example than FIG. As shown in FIG. 47, the UE 50 performs device control that performs processing such as an RE (Radio Equipment) module 151 that performs processing related to a radio signal, a BB (Base Band) processing module 152 that performs baseband signal processing, and higher layer processing. It has a module 153 and a USIM slot 154 which is an interface for accessing a USIM card.

The RE module 151 should transmit from the antenna by performing D / A (Digital-to-Analog) conversion, modulation, frequency conversion, power amplification, etc. on the digital baseband signal received from the BB processing module 152 Generate a radio signal. In addition, a digital baseband signal is generated by performing frequency conversion, A / D (Analog to Digital) conversion, demodulation, and the like on the received wireless signal, and the digital baseband signal is passed to the BB processing module 152. The RE module 151 includes functions such as a physical layer in the DL signal receiving unit 51 and the UL signal transmitting unit 52 in FIG. 46, for example.

The BB processing module 152 performs processing for mutually converting an IP packet and a digital baseband signal. A DSP (Digital Signal Processor) 162 is a processor that performs signal processing in the BB processing module 152. The memory 172 is used as a work area for the DSP 162. The BB processing module 152 includes, for example, functions such as layer 2 in the DL signal reception unit 51 and the UL signal transmission unit 52 in FIG. 46, an RRC processing unit 53, and a UE context management unit 54. Note that all or part of the functions of the RRC processing unit 53 and the UE context management unit 54 may be included in the device control module 153.

The device control module 153 performs IP layer protocol processing, various application processing, and the like. The processor 163 is a processor that performs processing performed by the device control module 153. The memory 173 is used as a work area for the processor 163. The processor 163 reads and writes data with the USIM through the USIM slot 154.

<Base station eNB>
FIG. 48 shows a functional configuration diagram of the base station eNB (eNB 10). Here, FIG. 48 does not illustrate the context fetch function of the second modification. As illustrated in FIG. 48, the eNB 10 includes a DL signal transmission unit 11, a UL signal reception unit 12, an RRC processing unit 13, a UE context management unit 14, an authentication unit 15, and an NW communication unit 16. FIG. 48 shows only functional units that are particularly related to the embodiment of the present invention in the eNB 10, and the eNB 10 also has a function (not shown) for performing at least an operation based on the LTE scheme.

The DL signal transmission unit 11 includes a function of generating and transmitting various physical layer signals from upper layer information to be transmitted from the eNB 10. The UL signal receiving unit 12 includes a function of receiving various uplink signals from the user apparatus UE and acquiring higher layer information from the received physical layer signals. The UL signal receiving unit 12 includes a function for determining whether or not the UE 50 can support the DRB scheme / SRB scheme based on the LCID in the MAC header of the MAC PDU received from the UE 50.

The RRC processing unit 13 is described with reference to FIG. 7, FIG. 8, FIG. 10 to FIG. 41, and the like, determination processing on the eNB side, generation / transmission of RRC message and broadcast information (transmission is via the DL signal transmission unit 11). Transmission), interpretation of the RRC message received by the UL signal receiving unit 12, operations based on the interpretation, and the like are performed. Further, transmission / reception of the MAC signal in the random access procedure described with reference to FIGS. 38 to 40 may be performed by the DL signal transmission unit 11 and the UL signal reception unit 12. In addition, the RRC processing unit 13 includes a function of resuming the RRC connection using the UE context held in the UE context management unit 14.

The UE context management unit 14 includes storage means such as a memory, and holds the UE context and the UE identifier (S-TMSI or the like) in the RRC idle state based on, for example, transmission of the instruction described in FIG. In the procedure shown in FIG. 7, the UE context is searched based on the UE identifier received from the UE, and after confirming that the UE context is retained, a notification indicating that the UE context is retained; Then, the RRC processing unit 13 is instructed to request authentication information. Further, in the first modification, the UE context management unit 14 instructs the authentication unit 15 to perform authentication based on the authentication information received from the UE. If the authentication is OK, the UE context management unit 14 searches for the UE context of the UE 50, and UE context Is confirmed, the RRC processing unit 13 is instructed to create and transmit a message for instructing the UE 50 to activate the UE context. In addition, the UE context management unit 14 invalidates the held UE context when a predetermined time (T) elapses in the RRC idle state from the time when the UE 50 changes from the RRC connected state to the RRC idle state. And includes the function of releasing the UE context.

In the basic example, the authentication unit 15 includes a function of receiving authentication information from the UE and authenticating the UE in Step 203 shown in FIG. Moreover, the authentication part 15 authenticates UE based on the authentication information transmitted from UE in the modification 201 in step 201 shown in FIG.

The NW communication unit 16 has a function of transmitting / receiving a control signal to / from the MME via the S1-MME interface, a function of transmitting / receiving data to / from the S-GW via the S1-U interface, and a function of transmitting a connection maintenance instruction signal , A transmission function for transmitting RRC connection establishment completion, and the like.

FIG. 49 shows a functional configuration diagram of the base station eNB (eNB 10) in the second modification. In the following, differences from the eNB 10 of FIG. 48 will be mainly described. In the eNB 10 of FIG. 49, a UE context acquisition unit 17 is added to the configuration of FIG.

The RRC processing unit 13 executes the message transmission / reception operations in steps 453 to 455 and 471 to 474 shown in FIGS. 26 and 27 together with the DL signal transmission unit 11 and the UL signal reception unit 12, for example.

For example, the UE context acquisition unit 17 executes the context acquisition procedure when the UE context necessary for establishing the RRC connection with the UE that holds the UE context is not stored in the UE context management unit 14. (Step 460 in FIG. 26, Steps 461 and 462 in FIG. 27). In addition, when receiving a context request message from another base station, the UE context acquisition unit 17 acquires the UE context from the UE context management unit 14 based on information identifying the target UE context, It has a function of returning to the other base station.

The configuration of the eNB 10 shown in FIGS. 48 and 47 may be entirely realized by a hardware circuit (eg, one or a plurality of IC chips), or a part may be configured by a hardware circuit and the other part may be a CPU. And a program.

FIG. 50 is a diagram illustrating an example of a hardware (HW) configuration of the eNB 10. FIG. 50 shows a configuration closer to the mounting example than FIGS. As illustrated in FIG. 50, the eNB 10 is connected to the network by an RE module 251 that performs processing related to a radio signal, a BB processing module 252 that performs baseband signal processing, a device control module 253 that performs processing such as an upper layer, and the like. And a communication IF 254 which is an interface for this purpose.

The RE module 251 generates a radio signal to be transmitted from the antenna by performing D / A conversion, modulation, frequency conversion, power amplification, and the like on the digital baseband signal received from the BB processing module 252. In addition, a digital baseband signal is generated by performing frequency conversion, A / D conversion, demodulation, and the like on the received radio signal, and passed to the BB processing module 252. The RE module 251 includes functions such as a physical layer in the DL signal transmission unit 11 and the UL signal reception unit 12 in FIGS.

The BB processing module 252 performs processing for mutually converting an IP packet and a digital baseband signal. The DSP 262 is a processor that performs signal processing in the BB processing module 252. The memory 272 is used as a work area for the DSP 252. The BB processing module 252 includes, for example, functions such as layer 2 in the DL signal transmission unit 11 and the UL signal reception unit 12 in FIGS. 48 and 47, an RRC processing unit 13, a UE context management unit 14, an authentication unit 15, and a UE context acquisition unit. 17 is included. Note that all or part of the functions of the RRC processing unit 13, the UE context management unit 14, the authentication unit 15, and the UE context acquisition unit 17 may be included in the device control module 253.

The device control module 253 performs IP layer protocol processing, OAM processing, and the like. The processor 263 is a processor that performs processing performed by the device control module 253. The memory 273 is used as a work area for the processor 263. The auxiliary storage device 283 is an HDD, for example, and stores various setting information for the base station eNB itself to operate.

It should be noted that the configuration (functional category) of the apparatus shown in FIGS. 45 to 50 is merely an example of a configuration that realizes the processing described in the present embodiment (including the basic example and the first and second modifications). If the processing described in the present embodiment (including basic examples and modifications 1 and 2) can be realized, the mounting method (specific functional unit arrangement, names, etc.) is limited to a specific mounting method. Not.

(Summary of embodiment)
As described above, according to the present embodiment, the user apparatus in the mobile communication system that supports a function of establishing a connection by reusing context information held in each of the user apparatus and the base station, the user apparatus Transmitting means for transmitting to the base station a connection request message including first context holding information indicating that the device holds user apparatus side context information; and a base in which the base station is associated with the user apparatus. Receiving means for receiving a connection setting message including second context holding information indicating that the station side context information is held from the base station; and after receiving the connection setting message, the user apparatus side context information is And a user device comprising a connection means for establishing a connection with the base station. .

With the above configuration, in a mobile communication system that supports a function of establishing a connection by reusing context information held in each of the user apparatus and the base station, it is determined whether the user apparatus holds the context information. It can be determined by the station.

The connection setting message includes a request for transmitting authentication information to the user apparatus in addition to the second context holding information, and the transmission means transmits authentication information to the base station based on the transmission request. It is good. With this configuration, the connection can be established after the base station authenticates the user apparatus.

The transmission means transmits, for example, a connection setting completion message including the authentication information to the base station. With this configuration, it is not necessary to send authentication information in a special message, and messages can be reduced.

The transmitting unit may transmit a connection request message including authentication information of the user device as the first context holding information to the base station. With this configuration, authentication information can be transmitted before connection setting is performed (before RRC connection is made).

The reception unit may receive a connection setting message including instruction information for activating the user apparatus side context information as the second context holding information from the base station. With this configuration, the user apparatus can determine whether or not the base station holds the context information based on whether or not the instruction information for activating the user apparatus side context information is received.

The receiving means receives from the base station a connection release message that causes the user apparatus to transition from a connected state to an idle state, and instructs to hold the user apparatus side context information from the connection release message In the idle state, the user device-side context information may be held in the storage unit. With this configuration, when the user device does not receive an instruction, the user device does not need to hold the user device-side context information, and can avoid holding the user device-side context information unnecessarily.

In addition, the user device invalidates the user device side context information held in the storage unit when a predetermined time has passed in the idle state from the time when the user device transitioned from the connected state to the idle state. It is good also as providing the management means to do. With this configuration, for example, when the idle state continues for a long time, it is possible to avoid holding the user apparatus side context information.

In addition, when the user apparatus transitions from the connected state to the idle state, the user apparatus side context information held in the storage unit is stored in accordance with the radio access technology of the cell selected to transition to the connected state again. Management means for selecting whether or not to invalidate may be provided. With this configuration, for example, when the cell to be reselected is not LTE, it is possible to avoid holding the user apparatus side context information.

Moreover, according to the present embodiment, the user apparatus in the mobile communication system that supports a function of establishing a connection by reusing context information held in each of the user apparatus and the base station, the user apparatus Transmitting a connection request message including a first identifier indicating that the user apparatus side context information is held to the base station, and a connection setting message including a request for a second identifier. Receiving means for receiving from a station, wherein the transmitting means transmits a connection setup completion message including the second identifier to the base station. A 1st identifier or a 2nd identifier is an identifier used in order to identify the base station which hold | maintains the context information of a user apparatus, and the said context information, for example. Further, the first identifier or the second identifier may include information for authenticating the user device corresponding to the context information.

Further, according to the present embodiment, the base station in the mobile communication system that supports a function of establishing a connection by reusing context information held in each of the user apparatus and the base station, wherein the user apparatus is a user In response to receiving the connection request message from the user apparatus, the base station receives a connection request message including the first context holding information indicating that the apparatus side context information is held. A transmission means for transmitting a connection setting message including second context holding information indicating that the base station side context information associated with the user apparatus is held to the user apparatus; and the connection setting message is transmitted. Then, the base station side context information is used to establish a connection with the user apparatus. Base station is provided with a connection means.

The receiving unit acquires, for example, the identifier of the user apparatus from the connection request message, and searches the base station side context information corresponding to the identifier from the plurality of base station side context information held. In this way, by using the identifier, it is possible to reliably detect the base station side context information associated with the user apparatus.

The connection setting message includes, in addition to the second context holding information, a request for transmitting authentication information to the user device, and based on the transmission request, the user device using the authentication information transmitted from the user device. Authentication means for performing the authentication may be provided. With this configuration, the connection can be established after the base station authenticates the user apparatus.

The receiving unit may receive a connection request message including authentication information of the user device as the first context holding information from the user device. With this configuration, it is possible to authenticate the user device by receiving the authentication information before the connection setting is performed (before the RRC connection is made).

The transmitting unit may transmit a connection setting message including instruction information for activating the user apparatus side context information as the second context holding information to the user apparatus. With this configuration, the user apparatus can determine whether or not the base station holds the context information based on whether or not the instruction information for activating the user apparatus side context information is received.

The transmission means includes, in a connection release message for transitioning the user device from a connected state to an idle state, information instructing to hold the user device side context information, and sends the connection release message to the user device. It is good also as transmitting. With this configuration, when the user device does not receive an instruction, the user device does not need to hold the user device-side context information, and can avoid holding the user device-side context information unnecessarily.

Further, according to the present embodiment, the base station in the mobile communication system that supports the function of establishing the connection by reusing the context information held in each of the user apparatus and the base station, the user apparatus side context information Receiving means for receiving a connection request message including a first identifier from the user apparatus holding the terminal, transmitting means for transmitting a connection setting message including a request for a second identifier to the user apparatus, and from the user apparatus A connection setting completion message including a second identifier is received, a holding base station holding the base station side context information of the user apparatus is specified based on the second identifier, and a context request message is sent to the holding base station The base station transmitted from the holding base station in response to the context request message Base station is provided and a context acquisition means for acquiring context information. Further, according to the present embodiment, the user apparatus in the mobile communication system that supports the function of establishing connection by reusing the context information held in each of the user apparatus and the base station, from the base station, A receiving unit that receives instruction information indicating whether or not the base station has a context holding function, and determines whether the base station has a context holding function based on the instruction information received by the receiving unit When the determination unit and the determination unit determine that the base station has a context holding function, a message including context holding information indicating that the user apparatus holds user apparatus side context information. There is provided a user apparatus comprising transmission means for transmitting to the base station.

Whether the base station retains the function of reusing context information in a mobile communication system that supports the function of reestablishing a connection by reusing context information retained in each of the user apparatus and the base station with the above configuration It becomes possible to determine whether or not by the user device.

The receiving means receives, for example, the instruction information included in broadcast information or a random access response. With this configuration, the user apparatus can receive the instruction signal without introducing a new signal.

The transmission unit may transmit a connection request message including the context holding information to the base station. With this configuration, it is possible to transmit a connection request message to a base station that has been confirmed to have a function of reusing context information, and to reliably establish a connection by reusing context information.

Further, according to the present embodiment, the user apparatus in the mobile communication system that supports a function of establishing connection by reusing context information held in each of the user apparatus and the base station, wherein the user apparatus is a user In the connection setting message received from the base station, a connection request message including first context holding information indicating that the apparatus side context information is held is transmitted to the base station. Determining whether or not second context holding information indicating that base station side context information associated with the user apparatus is held is included, and the determination means includes the connection setting message. When it is determined that the second context holding information is included in the user device side context, Using the multicast, a user device and a connection means for establishing a connection between said base station is provided.

Further, according to the present embodiment, the base station in the mobile communication system that supports the function of establishing the connection by reusing the context information held in each of the user apparatus and the base station, the base station In the case where it is determined that the base station has a context holding function based on the instruction information in the transmission unit that transmits instruction information indicating whether or not to have a holding function to the user device, and the user device, There is provided a base station comprising receiving means for receiving, from the user apparatus, a message including context holding information indicating that the user apparatus holds user apparatus side context information.

The transmission means transmits, for example, broadcast information including the instruction information or a random access response to the user device. With this configuration, the user apparatus can receive the instruction signal without introducing a new signal.

The receiving unit may receive a connection request message including the context holding information from the user device. With this configuration, a base station that has been confirmed to have a function of reusing context information can receive a connection request message, and a connection can be reliably established by reusing context information.

It should be noted that the “means” in the configuration of each device described above may be replaced with “unit”, “circuit”, “device”, and the like.

(Appendix)
The embodiment described above can be further described as the following supplementary notes.
[Appendix 1]
The user apparatus in a mobile communication system that supports a function of establishing connection by reusing context information held in each of a user apparatus and a base station,
Transmitting means for transmitting to the base station a connection request message including first context holding information indicating that the user apparatus holds user apparatus side context information;
Receiving means for receiving, from the base station, a connection setting message including second context holding information indicating that the base station holds base station side context information associated with the user apparatus;
A user apparatus comprising: a connection unit that establishes a connection with the base station using the context information on the user apparatus side after receiving the connection setting message.
[Appendix 2]
The connection setting message includes a request for transmitting authentication information to the user apparatus in addition to the second context holding information, and the transmission means transmits authentication information to the base station based on the transmission request. The user apparatus according to appendix 1, characterized by:
[Appendix 3]
The user apparatus according to supplementary note 2, wherein the transmission unit transmits a connection setting completion message including the authentication information to the base station.
[Appendix 4]
The user apparatus according to appendix 1, wherein the transmission unit transmits a connection request message including authentication information of the user apparatus as the first context holding information to the base station.
[Appendix 5]
The user apparatus according to appendix 1, wherein the reception unit receives a connection setting message including instruction information for activating the user apparatus side context information as the second context holding information from the base station.
[Appendix 6]
The receiving means receives from the base station a connection release message that causes the user apparatus to transition from a connected state to an idle state, and instructs to hold the user apparatus side context information from the connection release message The user device according to any one of appendices 1 to 5, wherein the user device-side context information is held in a storage unit during the idle state.
[Appendix 7]
Management means for invalidating the user device side context information held in the storage means when a predetermined time has passed in the idle state since the time when the user device transitioned from the connected state to the idle state. The user device according to appendix 6, characterized by:
[Appendix 8]
When the user apparatus transitions from the connected state to the idle state, the user apparatus side context information held in the storage unit is invalidated according to the radio access technology of the cell selected to transition to the connected state again. The user apparatus according to appendix 6 or 7, further comprising management means for selecting whether or not to perform.
[Appendix 9]
The base station in a mobile communication system that supports a function of establishing a connection by reusing context information held in each of a user apparatus and a base station,
Receiving means for receiving, from the user device, a connection request message including first context holding information indicating that the user device holds user device side context information;
In response to receiving the connection request message, a connection setting message including second context holding information indicating that the base station holds base station side context information associated with the user apparatus, Transmitting means for transmitting to the user device;
A base station comprising: connection means for establishing a connection with the user apparatus using the base station side context information after transmitting the connection setting message.
[Appendix 10]
The receiving means acquires an identifier of the user apparatus from the connection request message, and searches base station side context information corresponding to the identifier from a plurality of base station side context information held. 9. A base station according to 9.
[Appendix 11]
The connection setting message includes a request for transmitting authentication information to the user device in addition to the second context holding information,
The base station according to appendix 9 or 10, further comprising: an authenticating unit that authenticates the user device using authentication information transmitted from the user device based on the transmission request.
[Appendix 12]
The base station according to appendix 9, wherein the receiving unit receives a connection request message including authentication information of the user device as the first context holding information from the user device.
[Appendix 13]
The base station according to appendix 9, wherein the transmission means transmits a connection setting message including instruction information for activating the user apparatus side context information as the second context holding information to the user apparatus.
[Appendix 14]
The transmission means includes, in a connection release message for transitioning the user device from a connected state to an idle state, information instructing to hold the user device side context information, and sends the connection release message to the user device. The base station according to any one of appendices 9 to 13, wherein the base station transmits.
[Appendix 15]
A connection establishment method executed by the user apparatus in a mobile communication system that supports a function of establishing connection by reusing context information held in each of a user apparatus and a base station,
A transmission step of transmitting, to the base station, a connection request message including first context holding information indicating that the user apparatus holds user apparatus side context information;
A reception step of receiving from the base station a connection setting message including second context holding information indicating that the base station holds base station side context information associated with the user apparatus;
A connection establishment method comprising: a connection step of establishing a connection with the base station using the user apparatus side context information after receiving the connection setting message.
[Appendix 16]
A connection establishment method executed by the base station in a mobile communication system that supports a function of establishing connection by reusing context information held in each of a user apparatus and a base station,
Receiving a connection request message including first context holding information indicating that the user device holds user device side context information from the user device;
In response to receiving the connection request message, a connection setting message including second context holding information indicating that the base station holds base station side context information associated with the user apparatus, A transmitting step for transmitting to the user device;
A connection establishing method comprising: a connection step of establishing a connection with the user apparatus using the base station side context information after transmitting the connection setting message.

Although the embodiments of the present invention have been described above, the disclosed invention is not limited to such embodiments, and those skilled in the art will understand various variations, modifications, alternatives, substitutions, and the like. I will. Although specific numerical examples have been described in order to facilitate understanding of the invention, these numerical values are merely examples and any appropriate values may be used unless otherwise specified. The classification of items in the above description is not essential to the present invention, and the items described in two or more items may be used in combination as necessary, or the items described in one item may be used in different items. It may be applied to the matters described in (if not inconsistent). The boundaries between functional units or processing units in the functional block diagram do not necessarily correspond to physical component boundaries. The operations of a plurality of functional units may be physically performed by one component, or the operations of one functional unit may be physically performed by a plurality of components. For convenience of description, each device has been described using a functional block diagram. However, such a device may be implemented in hardware, software, or a combination thereof. Software that is operated by the processor of the apparatus according to the embodiment of the present invention includes random access memory (RAM), flash memory, read only memory (ROM), EPROM, EEPROM, register, hard disk (HDD), removable disk, CD It may be stored in any suitable storage medium such as ROM, database, server, etc.

The present invention is not limited to the above-described embodiment, and various variations, modifications, alternatives, substitutions, and the like are included in the present invention without departing from the spirit of the present invention.

This patent application is Japanese Patent Application No. 2015-218014 filed on November 5, 2015, Japanese Patent Application No. 2016-002129 filed on January 7, 2016, and filed February 4, 2016. Japanese Patent Application No. 2016-020321, Japanese Patent Application No. 2016-046348 filed on March 9, 2016, Japanese Patent Application No. 2016-153799 filed on August 4, 2016, and The priority is claimed based on Japanese Patent Application No. 2016-165170 filed on August 25, 2016, including Japanese Patent Application No. 2015-2182014, Japanese Patent Application No. 2016-002129, Japanese Patent Application No. 2016-020321, Japanese Patent Application No. 2016-046348, Japanese Patent Application No. 2 No. 16-153979, and the entire contents of Japanese Patent Application No. 2016-165170 incorporated herein by reference.

10, 20 eNB
11 DL signal transmission unit 12 UL signal reception unit 13 RRC processing unit 14 UE context management unit 15 Authentication unit 16 NW communication unit 17 UE context acquisition unit 30 MME
31 eNB communication unit 32 SGW communication unit 33 communication control unit 40 S-GW
41 eNB communication unit 42 MME communication unit 43 NW communication unit 44 communication control unit 50 UE
51 DL signal reception unit 52 UL signal transmission unit 53 RRC processing unit 54 UE context management unit 151 RE module 152 BB processing module 153 device control module 154 USIM slot 251 RE module 252 BB processing module 253 device control module 254 Communication IF

Claims

The user apparatus in a mobile communication system that supports a function of establishing connection by reusing context information held in each of a user apparatus and a base station,
Transmitting means for transmitting to the base station a first message indicating that the user apparatus holds user apparatus side context information;
Receiving means for receiving, from the base station, a second message indicating that the base station holds the base station side context information associated with the user apparatus;
A user apparatus comprising: a connection unit that establishes a connection with the base station by using the user apparatus side context information after receiving the second message.
The user apparatus according to claim 1, wherein the transmitting unit transmits the first message including authentication information of the user apparatus to the base station.
The receiving means receives from the base station a connection release message that causes the user apparatus to transition from a connected state to an idle state, and instructs to hold the user apparatus side context information from the connection release message 3. The user apparatus according to claim 1, wherein the user apparatus-side context information is held in a storage unit during the idle state when the user apparatus is detected.
Management means for invalidating the user device side context information held in the storage means when a predetermined time has passed in the idle state since the time when the user device transitioned from the connected state to the idle state. The user apparatus according to claim 3.
5. The management device for releasing the user device side context information held in the storage unit when the cell reselected by the user device is a RAT other than LTE. The user device described.
The base station in a mobile communication system that supports a function of establishing a connection by reusing context information held in each of a user apparatus and a base station,
Receiving means for receiving, from the user device, a first message indicating that the user device holds user device-side context information;
In response to receiving the first message, a second message indicating that the base station holds the base station side context information associated with the user apparatus is transmitted to the user apparatus. A transmission means;
A base station comprising: connection means for establishing a connection with the user apparatus using the base station side context information after transmitting the second message.
The reception unit acquires an identifier of the user apparatus from the first message, and searches base station side context information corresponding to the identifier from a plurality of retained base station side context information. The base station according to claim 6.
The base station according to claim 6 or 7, wherein the reception unit receives the first message including authentication information of the user device from the user device.
The transmission means includes, in a connection release message for transitioning the user device from a connected state to an idle state, information instructing to hold the user device side context information, and sends the connection release message to the user device. The base station according to any one of claims 6 to 8, wherein the base station transmits.
A connection establishment method executed by the user apparatus in a mobile communication system that supports a function of establishing connection by reusing context information held in each of a user apparatus and a base station,
A transmission step of transmitting to the base station a first message indicating that the user apparatus holds user apparatus side context information;
A receiving step of receiving, from the base station, a second message indicating that the base station holds the base station side context information associated with the user device;
A connection establishing method for establishing a connection with the base station by using the user apparatus side context information after receiving the second message.
A connection establishment method executed by the base station in a mobile communication system that supports a function of establishing connection by reusing context information held in each of a user apparatus and a base station,
A receiving step of receiving, from the user device, a first message indicating that the user device holds user device-side context information;
In response to receiving the first message, a second message indicating that the base station holds the base station side context information associated with the user apparatus is transmitted to the user apparatus. Sending step;
A connection establishing method comprising: establishing a connection with the user apparatus using the base station side context information after transmitting the second message.