Terminal device, method, and integrated circuit

Abstract

On the basis of the fact that a first setting has been established in a terminal device when a first timer has expired and a first failure has not been detected, the terminal device re-establishes a temporarily suspended source radio bearer and sets the value of a first state variable of a PDCP entity of the source radio bearer to one or both of the values of second and third state variables of the PDCP entity.

Description

[Technical Field]

[0001] The present invention relates to a terminal device, a method, and an integrated circuit. This application claims priority from Japanese Patent Application No. 2020-72141, filed on April 14, 2020, the contents of which are incorporated herein by reference. [Background technology]

[0002] A radio access method and radio network for cellular mobile communications (hereinafter referred to as "Long Term Evolution (LTE)" or "Evolved Universal Terrestrial Radio Access: EUTRA") and a core network (hereinafter referred to as "Evolved Packet Core: EPC") are being studied by the 3rd Generation Partnership Project (3GPP). EUTRA is also referred to as E-UTRA.

[0003] Furthermore, 3GPP is currently conducting technical studies and formulating standards for LTE-Advanced Pro, an extension of LTE, and NR (New Radio technology), a new radio access technology, as radio access methods and radio network technologies for fifth-generation cellular systems (Non-Patent Document 1). 5GC (5th Generation Core Network), a core network for fifth-generation cellular systems, is also being studied (Non-Patent Document 2). [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] 3GPP RP-170855, “Work Item on New Radio (NR) Access Technology” [Non-patent document 2] 3GPP TS 23.501 v15.3.0, “System Architecture for the 5G System; Stage 2” [Non-licensed document 3] 3GPP TS 36.300, v15.3.0, "Evolved Universal Terestrial Radio Access (E-UTRA) and Evolved Universal Terestrial Radio Access Network (E-UTRAN); Overall description; Stage 2"

Non-licensed Document 4

Non-licensed Document 5

Non-licensed Document 6

Non-licensed Document 7

Non-licensed literature 9

Non-licensed literature 10

Non-licensed Document 11

Non-licensed Document 12

Non-licensed Document 13

Non-licensed Document 14

Non-licensed Document 15

Non-licensed Document 16

[0005] As part of the LTE technical studies, a mechanism for further enhancing existing LTE mobility enhancement technologies is being studied. Furthermore, in the NR technical studies, a mechanism for enhancing existing NR mobility technologies is also being studied (Non-Patent Documents 18 and 19). These studies mainly include the study of Reduce User Data Interruption (RUDI), a technology for reducing interruptions in user data transmission and reception to nearly 0 ms when a base station device and a terminal device move between connected cells (during handover), and the study of handover robustness improvements.

[0006] In RUDI, a mechanism that allows two protocol stacks to exist simultaneously for one cell group (DAPS: Dual Active Protocol Stack) is being considered, but the detailed terminal operation required to efficiently control mobility has not yet been considered.

[0007] One aspect of the present invention has been made in view of the above circumstances, and an object of the present invention is to provide a terminal device, a method, and an integrated circuit that can efficiently control mobility. [Means for solving the problem]

[0008] In order to achieve the above object, one aspect of the present invention provides the following measure: a terminal device communicating with a base station device resumes a suspended source radio bearer based on a first setting being made in the terminal device when a first timer expires and a first failure is not detected, and sets the value of a first state variable of a PDCP entity of the source radio bearer to one or both of the value of a second state variable and the value of a third state variable of the PDCP entity.

[0009] Another aspect of the present invention is a method for a terminal device communicating with a base station device, which, when a first timer expires and a first failure is not detected, resumes a suspended source radio bearer based on a first setting being made in the terminal device, and sets the value of a first state variable of a PDCP entity of the source radio bearer to one or both of the value of a second state variable and the value of a third state variable of the PDCP entity.

[0010] These comprehensive or specific aspects may be realized as a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium, or may be realized as any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium. [Effects of the Invention]

[0011] According to one aspect of the present invention, a terminal device can realize efficient mobility processing. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a schematic diagram of a communication system according to each embodiment of the present invention. [Figure 2] 3A and 3B are protocol stack diagrams of UP and CP of a terminal device and a base station device in E-UTRA in each embodiment of the present invention. [Figure 3] A protocol stack diagram of the UP and CP of a terminal device and a base station device in NR in each embodiment of the present invention. [Figure 4] FIG. 10 is a diagram showing an example of a flow of procedures for various settings in the RRC 208 and / or the RRC 308 according to each embodiment of the present invention. [Figure 5] FIG. 2 is a block diagram showing the configuration of a terminal device according to each embodiment of the present invention. [Figure 6] FIG. 2 is a block diagram showing the configuration of a base station device according to each embodiment of the present invention. [Figure 7]An example of processing related to handover in EUTRA in each embodiment of the present invention. [Figure 8] An example of processing related to handover in NR in each embodiment of the present invention. [Figure 9] 4 shows an example of conditions for starting and stopping each timer according to an embodiment of the present invention. [Figure 10] 10 shows an example of a mobilityControlInfo information element according to an embodiment of the present invention. [Figure 11] 10 shows another example of the mobilityControlInfo information element according to an embodiment of the present invention. [Figure 12] 10 is an example of a synchronization-attached reconfiguration information element according to an embodiment of the present invention. [Figure 13] 10 is another example of a synchronization-attached reconfiguration information element according to an embodiment of the present invention. [Figure 14] An example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in NR in an embodiment of the present invention. [Figure 15] 10 is an example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in E-UTRA according to an embodiment of the present invention. [Figure 16] FIG. 3 is a diagram showing an example of the flow of processing A in the embodiment of the present invention. [Figure 17] FIG. 4 is a diagram showing an example of the flow of processing B in the embodiment of the present invention. [Figure 18] FIG. 10 is a diagram showing an example of the flow of processing C in the embodiment of the present invention. [Figure 19] FIG. 3 is a diagram showing an example of the flow of processing H in the embodiment of the present invention. [Figure 20] 10 is an example of an ASN.1 description showing a parameter for setting whether or not to apply make-before-break handover to a radio bearer in each embodiment of the present invention. [Figure 21] 10 is another example of an ASN.1 description showing a parameter for setting whether or not to apply make-before-break handover to a radio bearer in each embodiment of the present invention. [Figure 22] FIG. 10 is a diagram showing another example of the flow of process E in the embodiment of the present invention. [Figure 23] FIG. 10 is a diagram showing another example of the flow of process B in the embodiment of the present invention. [Figure 24] FIG. 10 is a diagram showing another example of the flow of the process LA in the embodiment of the present invention. [Figure 25] FIG. 10 is a diagram showing an example of a processing method of a UE 122 in each embodiment of the present invention. [Figure 26] FIG. 10 is a diagram showing another example of a processing method of the UE 122 in each embodiment of the present invention. [Figure 27] FIG. 10 is a diagram showing yet another example of a processing method of the UE 122 in each embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0014] LTE (and LTE-A Pro) and NR may be defined as different radio access technologies (RATs). NR may also be defined as a technology included in LTE. LTE may also be defined as a technology included in NR. LTE, which is connectable to NR via Multi Radio Dual connectivity, may be distinguished from conventional LTE. LTE whose core network is 5GC may also be distinguished from conventional LTE whose core network is EPC. This embodiment may be applied to NR, LTE, and other RATs. In the following description, terms related to LTE and NR are used, but this embodiment may also be applied to other technologies using other terminology. In this embodiment, the term E-UTRA may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

[0015] FIG. 1 is a schematic diagram of a communication system according to each embodiment of the present invention.

[0016] E-UTRA 100 is a radio access technology described in Non-Patent Document 3 and the like, and is composed of cell groups (CGs) each consisting of one or more frequency bands. eNB (E-UTRAN Node B) 102 is a base station device for E-UTRA 100. EPC (Evolved Packet Core) 104 is a core network described in Non-Patent Document 14 and the like, and was designed as a core network for E-UTRA 100. Interface 112 is an interface between eNB 102 and EPC 104, and includes a control plane (CP) through which control signals pass and a user plane (UP) through which user data passes.

[0017] NR106 is a radio access technology described in Non-Patent Document 9 and the like, and is composed of cell groups (CGs) consisting of one or more frequency bands. gNB (g Node B) 108 is a base station device for NR106. 5GC110 is a core network described in Non-Patent Document 2 and the like, and is designed as a core network for NR106, but may also be used as a core network for E-UTRA100 that has the function of connecting to 5GC110. Hereinafter, E-UTRA100 may include E-UTRA100 that has the function of connecting to 5GC110.

[0018] Interface 114 is an interface between eNB102 and 5GC110, interface 116 is an interface between gNB108 and 5GC110, interface 118 is an interface between gNB108 and EPC104, interface 120 is an interface between eNB102 and gNB108, and interface 124 is an interface between EPC104 and 5GC110. Interfaces 114, 116, 118, 120, 124, etc. may be interfaces that pass only CP, only UP, or both CP and UP. Furthermore, interfaces 114, 116, 118, 120, 124, etc. may not exist depending on the communication system provided by the communication carrier.

[0019] The UE 122 is a terminal device compatible with any or all of the E-UTRA 100 and the NR 106. As described in Non-Patent Document 3 and any or all of Non-Patent Document 9, when the UE 122 connects to the core network via any or all of the E-UTRA 100 and the NR 106, a logical path called a Radio Bearer (RB) is established between the UE 122 and any or all of the E-UTRA 100 and the NR 106. A radio bearer used for CP is called a Signaling Radio Bearer (SRB), and a radio bearer used for UP is called a Data Radio Bearer (DRB Data Radio Bearer). Each RB is assigned an RB identity (RB ID) and is uniquely identified. An RB identifier for an SRB is called an SRB identity (SRB ID), and an RB identifier for a DRB is called a DRB identity (DRB ID).

[0020] As described in Non-Patent Document 3, when the core network to which the UE 122 is connected is the EPC 104, each DRB established between the UE 122 and one or all of the E-UTRA 100 and the NR 106 is further uniquely associated with each EPS (Evolved Packet System) bearer passing through the EPC 104. Each EPS bearer is assigned an EPS bearer identifier (identity, or ID) and is uniquely identified. Furthermore, the same QoS is guaranteed for data passing through the same EPS bearer.

[0021] As described in Non-Patent Document 9, when the core network to which the UE 122 is connected is the 5GC 110, one or more DRBs established between the UE 122 and any or all of the E-UTRA 100 and the NR 106 are further linked to one of the PDU (Packet Data Unit) sessions established within the 5GC 110. Each PDU session has one or more QoS flows. Each DRB may be mapped to one or more QoS flows existing in the PDU session to which it is linked, or may not be mapped to any QoS flow. Each PDU session is identified by a PDU session identifier (Identity, or ID). Furthermore, each QoS flow is identified by a QoS flow identifier. Furthermore, data passing through the same QoS flow is guaranteed the same QoS.

[0022] Any or all of the PDU sessions and QoS flows do not exist in the EPC 104, and no EPS bearers exist in the 5GC 110. When the UE 122 is connected to the EPC 104, the UE 122 has information about the EPS bearers but does not have any or all of the PDU sessions and QoS flows. When the UE 122 is connected to the 5GC 110, the UE 122 has information about any or all of the PDU sessions and QoS flows but does not have information about the EPS bearers.

[0023] FIG. 2 is a diagram showing protocol stacks of UP and CP of a terminal device and a base station device in the E-UTRA radio access layer (radio access layer) in each embodiment of the present invention.

[0024] FIG. 2A is a diagram of a protocol stack of the UP used when the UE 122 communicates with the eNB 102 in the E-UTRA 100.

[0025] The PHY (Physical layer) 200 is a wireless physical layer that provides transmission services to an upper layer using a physical channel. The PHY 200 is connected to a higher layer, a Medium Access Control (MAC) layer 202 (described later), via a transport channel. Data moves between the MAC 202 and the PHY 200 via the transport channel. Data is transmitted and received between the PHYs of the UE 122 and the eNB 102 via the wireless physical channel.

[0026] The MAC 202 is a medium access control layer that maps various logical channels to various transport channels. The MAC 202 is connected to the higher-level RLC (Radio Link Control layer) 204 (described later) via logical channels. Logical channels are broadly categorized by the type of information transmitted, into control channels that transmit control information and traffic channels that transmit user information. The MAC 202 has functions such as controlling the PHY 200 to perform discontinuous transmission / reception (DRX / DTX), executing random access procedures, reporting transmission power information, and performing HARQ control (Non-Patent Document 7).

[0027] The RLC 204 is a radio link control layer that segments data received from the upper layer, the Packet Data Convergence Protocol (PDCP) Layer 206 (described later), and adjusts the data size so that the lower layer can transmit the data appropriately. The RLC 204 has three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). In TM, data received from the upper layer is not segmented, and an RLC header is not added. In UM, data received from the upper layer is segmented, an RLC header is added, and data retransmission control is not performed. In AM, data received from the upper layer is segmented, an RLC header is added, and data retransmission control is performed. The retransmission control function may be a function for guaranteeing the Quality of Service (QoS) required for each data. When controlling data retransmission, information about undelivered data sent from the receiving side of an RLC to the transmitting side is called a status report. An instruction to prompt a status report sent from the transmitting side of an RLC to the receiving side is called a poll. Data sent to a lower layer using TM is sometimes called a TMD PDU, data sent to a lower layer using UM is sometimes called a UMD PDU, and data sent to a lower layer using AM is sometimes called an AMD PDU (Non-Patent Document 6).

[0028] The PDCP 206 is a packet data convergence protocol layer for efficiently transmitting user data such as IP packets over wireless sections. The PDCP 206 may have a header compression function for compressing unnecessary control information. The PDCP 206 may also have a data encryption function. The PDCP 206 may also have a re-ordering function (see Non-Patent Document 5).

[0029] The data processed by the MAC 202, RLC 204, and PDCP 206 are called MAC PDUs (Protocol Data Units), RLC PDUs, and PDCP PDUs, respectively. Data passed from higher layers to the MAC 202, RLC 204, and PDCP 206, or data passed to higher layers, are called MAC SDUs (Service Data Units), RLC SDUs, and PDCP SDUs, respectively. Divided RLC SDUs are called RLC SDU segments.

[0030] To distinguish between data and control PDUs, PDCP PDUs may be called PDCP DATA PDUs (PDCP Data PDUs) and PDCP CONTROL PDUs (PDCP Control PDUs).To distinguish between data and control PDUs, RLC PDUs may be called RLC DATA PDUs (RLC Data PDUs) and RLC CONTROL PDUs (RLC Control PDUs).

[0031] FIG. 2(B) is a protocol stack diagram of a CP used when a UE 122 communicates with an eNB 102 and an MME (Mobility Management Entity) which is a logical node that provides functions such as authentication and mobility management in E-UTRA 100.

[0032] The CP protocol stack includes a PHY 200, a MAC 202, an RLC 204, a PDCP 206, a Radio Resource Control layer (RRC) 208, and a non-access stratum (NAS) 210. The RRC 208 is a radio link control layer that performs processes such as establishing, re-establishing, suspending, and resuming an RRC connection, resetting the RRC connection, for example, establishing, changing, and releasing radio bearers (RBs) and cell groups, controlling logical channels, transport channels, and physical channels, and also configuring handovers and measurements. RBs may be divided into signaling radio bearers (SRBs) and data radio bearers (DRBs). SRBs may be used as paths for transmitting RRC messages, which are control information. DRBs may be used as paths for transmitting user data. Each RB may be configured between the eNB 102 and the RRC 208 of the UE 122. Furthermore, a portion of the RB configured with the RLC 204 and a logical channel may be referred to as an RLC bearer (Non-Patent Document 4). Furthermore, in contrast to the NAS layer that carries signals between the MME and the UE 122, some or all of the layers of the PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 that carry signals and data between the UE 122 and the eNB 102 may be referred to as an AS (Access Stratum) layer.

[0033] The above-described classification of functions into MAC 202, RLC 204, PDCP 206, and RRC 208 is an example, and some or all of the functions may not be implemented. Also, some or all of the functions of each layer may be included in another layer.

[0034] The IP layer, and layers above the IP layer such as the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, and application layer are upper layers (not shown) of the PDCP layer. The RRC layer and NAS (non-access strat) layer are also upper layers (not shown) of the PDCP layer. In other words, the PDCP layer is lower layers (lower layers) of the RRC layer, NAS layer, IP layer, and layers above the IP layer such as the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, and application layer.

[0035] FIG. 3 is a diagram of the protocol stack of the UP and CP of the terminal device and base station device in the NR radio access layer in each embodiment of the present invention.

[0036] Figure 3(A) is a protocol stack diagram of the UP used when UE 122 communicates with gNB 108 in NR 106.

[0037] The PHY (Physical layer) 300 is a radio physical layer of NR and may provide transmission services to higher layers using a physical channel. The PHY 300 may be connected to a higher-level MAC (Medium Access Control layer) 302 (described later) via a transport channel. Data may be transferred between the MAC 302 and the PHY 300 via the transport channel. Data may be transmitted and received between the PHYs of the UE 122 and the gNB 108 via a radio physical channel.

[0038] Here, the physical channels will be described.

[0039] The following physical channels may be used in wireless communication between a terminal device and a base station device.

[0040] PBCH (Physical Broadcast CHannel) PDCCH (Physical Downlink Control CHannel) PDSCH (Physical Downlink Shared CHannel) PUCCH (Physical Uplink Control CHannel) PUSCH (Physical Uplink Shared CHannel) PRACH (Physical Random Access CHannel)

[0041] The PBCH is used to broadcast system information required by terminal devices.

[0042] In addition, in NR, the PBCH may be used to broadcast a time index (SSB-Index) within the period of a synchronization signal block (also referred to as an SS / PBCH block).

[0043] The PDCCH is used to transmit (or carry) downlink control information (DCI) in downlink radio communication (radio communication from the base station device 3 to the terminal device). Here, one or more DCIs (which may be referred to as DCI formats) are defined for transmitting the downlink control information. That is, a field for the downlink control information is defined as DCI and mapped to information bits. The PDCCH is transmitted in PDCCH candidates. The terminal device monitors a set of PDCCH candidates in the serving cell. Monitoring means attempting to decode the PDCCH according to a certain DCI format. A certain DCI format may be used for scheduling the PUSCH in the serving cell. The PUSCH may be used for transmitting user data, RRC messages, etc.

[0044] The PUCCH may be used to transmit uplink control information (UCI) in uplink wireless communication (wireless communication from a terminal device to a base station device). Here, the uplink control information may include channel state information (CSI) used to indicate the state of a downlink channel. The uplink control information may also include a scheduling request (SR) used to request UL-SCH resources. The uplink control information may also include a hybrid automatic repeat request ACKnowledgement (HARQ-ACK).

[0045] The PDSCH may be used to transmit downlink data (DL-SCH: Downlink Shared CHannel) from the MAC layer, and in the case of downlink, it is also used to transmit system information (SI: System Information) and random access response (RAR: Random Access Response).

[0046] The PUSCH may be used to transmit uplink data from the MAC layer (UL-SCH: Uplink Shared CHannel) or HARQ-ACK and / or CSI together with uplink data. The PUSCH may also be used to transmit only CSI, or only HARQ-ACK and CSI. That is, the PUSCH may be used to transmit only UCI. The PDSCH or PUSCH may also be used to transmit RRC signaling (also referred to as an RRC message) and MAC control elements. Here, in the PDSCH, the RRC signaling transmitted from the base station apparatus may be signaling common to multiple terminal apparatuses in a cell. The RRC signaling transmitted from the base station apparatus may also be signaling dedicated to a certain terminal apparatus (also referred to as dedicated signaling). That is, terminal apparatus-specific (UE-specific) information may be transmitted using signaling dedicated to a certain terminal apparatus. The PUSCH may also be used to transmit UE capabilities in the uplink.

[0047] The PRACH may be used to transmit a random access preamble and may be used for initial connection establishment procedures, handover procedures, connection re-establishment procedures, synchronization (timing adjustment) for uplink transmissions, and to indicate requests for PUSCH (UL-SCH) resources.

[0048] The MAC 302 is a medium access control layer that maps various logical channels to various transport channels. The MAC 302 may be connected to a higher-level RLC (Radio Link Control layer) 304 (described later) via a logical channel. Logical channels are broadly classified according to the type of information transmitted, and may be divided into control channels that transmit control information and traffic channels that transmit user information. The MAC 302 may have functions such as controlling the PHY 300 to perform discontinuous transmission / reception (DRX / DTX), executing a random access procedure, reporting transmission power information, and performing HARQ control (Non-Patent Document 13).

[0049] The RLC 304 is a radio link control layer that segments data received from the upper layer, the Packet Data Convergence Protocol Layer (PDCP) 306 (described later), and adjusts the data size so that the lower layer can transmit the data appropriately. The RLC 304 has three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). In TM, data received from the upper layer is not segmented, and an RLC header is not added. In UM, data received from the upper layer is segmented and an RLC header is added, but data retransmission control is not performed. In AM, data received from the upper layer is segmented, an RLC header is added, and data retransmission control is performed. The retransmission control function may be a function for guaranteeing the Quality of Service (QoS) required for each data. When controlling data retransmission, information about undelivered data sent from the receiving side of an RLC to the transmitting side is called a status report. An instruction to prompt a status report sent from the transmitting side of an RLC to the receiving side is called a poll. Data sent to a lower layer using TM is sometimes called a TMD PDU, data sent to a lower layer using UM is sometimes called a UMD PDU, and data sent to a lower layer using AM is sometimes called an AMD PDU (Non-Patent Document 12).

[0050] PDCP 306 is a packet data convergence protocol layer that efficiently transmits user data such as IP packets over wireless sections. PDCP 306 may have a header compression function that compresses unnecessary control information. PDCP 306 may also have functions for encrypting data and protecting data integrity. PDCP 306 may also have a re-ordering function (Non-Patent Document 11).

[0051] SDAP (Service Data Adaptation Protocol) 310 is a service data adaptation protocol layer that has the function of mapping the downlink QoS flow sent from 5GC110 to a terminal device via a base station device to a DRB, and mapping the uplink QoS flow sent from the terminal device to 5GC110 via a base station device to a DRB, and storing mapping rule information (Non-Patent Document 16).

[0052] The data processed in MAC 302, RLC 304, PDCP 306, and SDAP 310 are called MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU, respectively. Data passed from or to upper layers to MAC 302, RLC 304, PDCP 306, and SDAP 310 are called MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. Segmented RLC SDUs are called RLC SDU segments.

[0053] Furthermore, to distinguish between data and control PDUs, SDAP PDUs may be called SDAP DATA PDUs (SDAP Data PDUs) and SDAP CONTROL PDUs (SDAP Control PDUs). PDCP PDUs may be called PDCP DATA PDUs (PDCP Data PDUs) and PDCP CONTROL PDUs (PDCP Control PDUs). RLC PDUs may be called RLC DATA PDUs (RLC Data PDUs) and RLC CONTROL PDUs (RLC Control PDUs).

[0054] Figure 3(B) is a protocol stack diagram of the CP used when UE 122 communicates with gNB 108 and AMF (Access and Mobility Management function), a logical node that provides functions such as authentication and mobility management, in NR 106.

[0055] The CP protocol stack includes a PHY 300, a MAC 302, an RLC 304, a PDCP 306, a Radio Resource Control layer (RRC) 308, and a non-access stratum (NAS) 312. The RRC 308 is a radio link control layer that performs processes such as establishing, re-establishing, suspending, and resuming an RRC connection, resetting the RRC connection, for example, establishing, changing, and releasing radio bearers (RBs) and cell groups, controlling logical channels, transport channels, and physical channels, and configuring handovers and measurements. RBs may be divided into signaling radio bearers (SRBs) and data radio bearers (DRBs). The SRBs may be used as paths for transmitting RRC messages, which are control information. The DRBs may be used as paths for transmitting user data. Each RB may be configured between the gNB 108 and the RRC 308 of the UE 122. Furthermore, a portion of the RB consisting of the RLC 304 and a logical channel may be referred to as an RLC bearer (Non-Patent Document 10). Furthermore, in contrast to the NAS layer that carries signals between the AMF and the UE 122, some or all of the layers of PHY 300, MAC 302, RLC 304, PDCP 306, RRC 308, and SDAP 310 that carry signals and data between the UE 122 and the gNB 108 may be referred to as an AS (Access Stratum) layer.

[0056] The following SRBs may be defined: SRB0 to SRB3. SRB0 may be an SRB for RRC messages using the logical channel CCCH (Common Control CHannel). SRB1 may be an SRB for RRC messages (which may include piggybacked NAS messages) and for NAS messages before the establishment of SRB2, all of which may use the logical channel DCCH (Dedicated Control CHannel). SRB2 may be an SRB for NAS messages, all of which may use the logical channel DCCH. SRB2 may have a lower priority than SRB1. SRB3 may be an SRB for specific RRC messages when UE 122 is configured with EN-DC, NGEN-DC, NR-DC, etc., all of which may use the logical channel DCCH. Other SRBs may also be provided for other uses.

[0057] The functional classification of MAC 302, RLC 304, PDCP 306, SDAP 310, and RRC 308 described above is an example, and some or all of the functions may not be implemented. Furthermore, some or all of the functions of each layer may be included in another layer.

[0058] Note that the layer above the AS layer (not shown) may be referred to as the PDU layer, as described in Non-Patent Document 2. The PDU layer may include any or all of the IP layer, the TCP (Transmission Control Protocol) layer above the IP layer, the UDP (User Datagram Protocol) layer, and other layers. The application layer may be a layer above the PDU layer, or may be included in the PDU layer. Note that the PDU layer may be a layer above the user plane of the AS layer. The RRC layer and the NAS (non-access stratum) layer may also be upper layers of any or all of the SDAP layer and the PDCP layer (not shown). In other words, any or all of the SDAP layer and the PDCP layer are lower layers of any or all of the RRC layer, the NAS layer, the IP layer, the TCP (Transmission Control Protocol) layer above the IP layer, the UDP (User Datagram Protocol) layer, and the application layer.

[0059] In each embodiment of the present invention, any or all of the following may belong to the application layer: SIP (Session Initiation Protocol) and SDP (Session Description Protocol) used in IMS, RTP (Real-time Transport Protocol), RTCP (Real-time Transport Control Protocol), HTTP (HyperText Transfer Protocol), etc. used in media communication or media communication control, and codecs for various media.

[0060] The physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer of the terminal device may be established, configured, and / or controlled by the RRC layer of the terminal device. The RRC layer of the terminal device may establish and / or configure the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer according to an RRC message transmitted from the RRC layer of the base station device. The MAC layer, RLC layer, PDCP layer, and SDAP layer may be referred to as the MAC sublayer, RLC sublayer, PDCP sublayer, and SDAP sublayer, respectively.

[0061] Each layer or function of each layer belonging to the AS layer configured in any or all of the terminal device and base station device may be referred to as an entity. That is, the physical layer (PHY layer), MAC layer, RLC layer, PDCP layer, SDAP layer, and RRC layer, or the functions of each layer, which are established, configured, and / or controlled in any or all of the terminal device and base station device, may be referred to as a physical entity (PHY entity), MAC entity, RLC entity, PDCP entity, SDAP entity, and RRC entity, respectively. Each layer may contain one or more entities. The PDCP entity and RLC entity may be established, configured, and / or controlled for each radio bearer. The MAC entity may be established, configured, and / or controlled for each cell group. The SDAP entity may be established, configured, and / or controlled for each PDU session.

[0062] The PDCP layer or PDCP entity may use a COUNT value when performing encryption or integrity protection processing. The COUNT value may consist of a Hyper Frame Number (HFN) and a sequence number (SN: Sequence Number) added to the header of a PDCP PDU. The sequence number may be incremented by 1 each time a PDCP DATA PDU is generated by the PDCP layer or PDCP entity on the transmitting side. The HFN may be incremented by 1 each time the sequence number reaches its maximum value. In addition, some or all of the following state variables (A) to (F) may be used to manage the COUNT value on the transmitting and receiving sides. (A) A state variable indicating the COUNT value of the next PDCP SDU to be transmitted. This may be a state variable named TX_NEXT as described in Non-Patent Document 11. (B) A state variable indicating the sequence number of the PDCP SDU to be transmitted next in this PDCP entity. This may be a state variable named Next_PDCP_TX_SN as described in Non-Patent Document 5. (C) A state variable representing the HFN value used to generate the COUNT value of a PDCP PDU in this PDCP entity. This may be the state variable named TX_HFN described in Non-Patent Document 5. (D) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next at the receiving side of the PDCP entity. This may be the state variable named RX_NEXT described in Non-Patent Document 11. (E) A state variable indicating the sequence number of the PDCP SDU that is expected to be received next at the receiving side of this PDCP entity. This may be a state variable named Next_PDCP_RX_SN described in Non-Patent Document 5. (F) A state variable representing the HFN value used to generate a COUNT value for a received PDCP PDU in this PDCP entity. This may be the state variable named RX_HFN described in Non-Patent Document 5.

[0063] Furthermore, in the PDCP layer or PDCP entity, reordering may be a process of storing PDCP SDUs in a receive buffer and delivering the PDCP SDUs to a higher layer in the order of the COUNT values ​​obtained from the header information of the PDCP DATA PDUs. Reordering may also include a process of delivering stored PDCP SDUs to a higher layer in the order of their COUNT values ​​when the COUNT value of a received PDCP data PDU is the COUNT value of the first PDCP SDU not yet delivered to a higher layer. That is, in reordering, if a PDCP data PDU with a COUNT value smaller than the COUNT value of the received PDCP data PDU has not been received (a PDCP data PDU has been lost), the received PDCP data PDU may be converted into a PDCP SDU and stored in a reordering buffer, and the lost PDCP data PDUs may be delivered to a higher layer only after they have all been received and converted into PDCP SDUs. In reordering, a reordering timer (a timer called t-Reordering described in Non-Patent Document 11 or Non-Patent Document 5) may be used to detect loss of PDCP data PDUs. Also, some or all of the following state variables (A) to (F) may be used for reordering. (A) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next at the receiving side of the PDCP entity. This may be the state variable named RX_NEXT described in Non-Patent Document 11. (B) A state variable indicating the sequence number of the PDCP SDU that is expected to be received next at the receiving side of this PDCP entity. This may be a state variable named Next_PDCP_RX_SN described in Non-Patent Document 5. (C) A state variable representing the HFN value used to generate a COUNT value for a received PDCP PDU in this PDCP entity. This may be the state variable named RX_HFN described in Non-Patent Document 5. (D) A state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received and not yet delivered to the upper layer at the receiving side of the PDCP entity. This may be the state variable named RX_DELIV described in Non-Patent Document 11. (E) A state variable indicating the sequence number of the PDCP PDU of the PDCP SDU last delivered to the upper layer at the receiving side of this PDCP entity. This may be a state variable named Last_Submitted_PDCP_RX_SN as described in Non-Patent Document 5. (F) A state variable indicating the next COUNT value after the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity. This may be the state variable named RX_REORD described in Non-Patent Document 11 or the state variable named Reordering_PDCP_RX_COUNT described in Non-Patent Document 5.

[0064] In each embodiment of the present invention, in order to distinguish between E-UTRA protocols and NR protocols, MAC 202, RLC 204, PDCP 206, and RRC 208 may be referred to as E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Alternatively, they may be written with spaces, such as E-UTRA PDCP or LTE PDCP, or NR PDCP.

[0065] Also, as shown in FIG. 1, the eNB 102, the gNB 108, the EPC 104, and the 5GC 110 may be connected via interface 112, interface 116, interface 118, interface 120, and interface 114. Therefore, in order to support various communication systems, the RRC 208 in FIG. 2 may be replaced with the RRC 308 in FIG. 3. The PDCP 206 in FIG. 2 may be replaced with the PDCP 306 in FIG. 3. The RRC 308 in FIG. 3 may include the functions of the RRC 208 in FIG. 2. The PDCP 306 in FIG. 3 may be the PDCP 206 in FIG. 2. In E-UTRA 100, even when the UE 122 communicates with the eNB 102, NR PDCP may be used as the PDCP.

[0066] Next, the state transitions of the UE 122 in LTE and NR will be described. A UE 122 connected to EPC or 5GC may be in the RRC_CONNECTED state when an RRC connection has been established. The state in which an RRC connection is established may include a state in which the UE 122 holds some or all of the UE context described below. The state in which an RRC connection is established may also include a state in which the UE 122 can transmit and / or receive unicast data. Furthermore, the UE 122 may be in the RRC_INACTIVE state when the RRC connection is inactive (if the UE 122 is connected to 5GC). If neither of these cases is true, the UE 122 may be in the RRC_IDLE state.

[0067] Note that the UE 122 connected to the EPC does not have an RRC_INACTIVE state, but the suspension of the RRC connection may be initiated by the E-UTRAN. In this case, when the RRC connection is suspended, the UE 122 transitions to the RRC_IDLE state while retaining the UE AS context and an identifier (resumeIdentity) used for resumption. When the UE 122 retains the UE AS context, the E-UTRAN has permitted the resumption of the RRC connection, and the UE 122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state, the resumption of the suspended RRC connection may be initiated by a higher layer (e.g., the NAS layer).

[0068] That is, the definition of dormancy may be different for UE 122 connected to EPC and UE 122 connected to 5GC. Also, all or part of the procedure for UE 122 to return from dormancy may be different when UE 122 is connected to EPC (when dormant in RRC_IDLE state) and when UE 122 is connected to 5GC (when dormant in RRC_INACTIVE state).

[0069] The RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may also be referred to as the connected state (connected mode), the inactive state (inactive mode), and the idle state (idle mode), respectively, or as the RRC connected state (RRC connected mode), the RRC inactive state (RRC inactive mode), and the RRC idle mode.

[0070] The UE AS context held by the UE 122 may be information including all or some of the following: a current RRC configuration, a current security context, a PDCP state including a ROHC (Robust Header Compression) state, a C-RNTI (Cell Radio Network Temporary Identifier) ​​used in the source PCell, a cell identifier (cellIdentity), and a physical cell identifier of the source PCell. Note that the UE AS context held by one or all of the eNB 102 and the gNB 108 may include the same information as the UE AS context held by the UE 122, or may include information different from the information included in the UE AS context held by the UE 122.

[0071] The security context may be information that includes all or part of the following: encryption keys at the AS level, the Next Hop parameter (NH), the Next Hop Chaining Counter parameter (NCC) used to derive the next hop access key, an identifier for the selected AS level encryption algorithm, and a counter used for replay protection.

[0072] Next, handover in LTE and NR will be described. A handover may be a process in which a UE 122 in an RRC connected state changes its serving cell. A handover may be performed when the UE 122 receives an RRC message instructing a handover from the eNB 102 and / or the gNB 108. The RRC message instructing a handover may be a message related to reconfiguration of the RRC connection including a parameter instructing a handover (e.g., an information element named "MobilityControlInfo" described in Non-Patent Document 4 or an information element named "ReconfigurationWithSync" described in Non-Patent Document 10), or a message indicating movement to a cell of another RAT (e.g., MobilityFromEUTRACommand described in Non-Patent Document 4 or MobilityFromNRCommand described in Non-Patent Document 10). In addition, the conditions under which the UE 122 can perform a handover may include some or all of the following: AS security is activated; SRB2 is established; and at least one DRB is established.

[0073] Fig. 4 is a diagram showing an example of a procedure flow for various settings in the RRC 208 and / or the RRC 308 according to each embodiment of the present invention. Fig. 4 shows an example of a flow when an RRC message is sent from a base station device (eNB 102 and / or gNB 108) to a terminal device (UE 122).

[0074] In FIG. 4, the base station device creates an RRC message (step S400). The base station device may create an RRC message when it distributes system information (SI) or paging information, or when it determines that a process needs to be performed on a specific terminal device, such as security settings, reconfiguration of an RRC connection (radio bearer processing (establishment, modification, release, etc.), cell group processing (establishment, addition, modification, release, etc.), measurement settings, handover settings, etc.), or release of the RRC connection state. The RRC message may also be used as a handover command to a different RAT. The RRC message includes information (parameters) for various information notifications and settings. In RRC specifications such as Non-Patent Document 4 or Non-Patent Document 10, these parameters are called fields and / or information elements, and are described using a description format called ASN.1 (Abstract Syntax Notation One).

[0075] 4, the base station device then transmits the created RRC message to the terminal device (step S402). Next, the terminal device performs processing such as setting according to the received RRC message if necessary (step S404).

[0076] The creation of the RRC message is not limited to the above example, and may be created for other purposes as described in Non-Patent Document 4, Non-Patent Document 10, and the like.

[0077] For example, the RRC message may be used for settings related to Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) described in Non-Patent Document 8.

[0078] Dual Connectivity (DC) may be a technology for performing data communication using radio resources of both cell groups configured by two base station devices (nodes), i.e., a master cell group (MCG) configured by a master node (MN) and a secondary cell group (SCG) configured by a secondary node (SN). The master node and the secondary node may be the same node (same base station device). Furthermore, MR-DC, as described in Non-Patent Document 8, may be a technology for grouping cells of both E-UTRA and NR radio access technologies (RATs) into cell groups for each RAT, assigning them to UEs, and performing data communication using radio resources of both the MCG and the SCG. In MR-DC, the master node may be a base station having main RRC functions related to MR-DC, such as adding a secondary node, establishing, changing, and releasing RBs, adding, changing, releasing MCGs, and handover functions, and the secondary node may be a base station having some RRC functions, such as changing and releasing SCGs.

[0079] In the MR-DC described in Non-Patent Document 8, the RRC of the RAT on the master node side may be used to configure both the MCG and the SCG. For example, in EN-DC (E-UTRA-NR Dual Connectivity), which is an MR-DC when the core network is the EPC 104 and the master node is the eNB 102 (also referred to as enhanced eNB 102), and in NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity), which is an MR-DC when the core network is the 5GC 110 and the master node is the eNB 102, an E-UTRA RRC message described in Non-Patent Document 4 may be transmitted and received between the eNB 102 and the UE 122. In this case, the RRC message may include not only LTE (E-UTRA) configuration information but also NR configuration information described in Non-Patent Document 10. Furthermore, the RRC message transmitted from the eNB 102 to the UE 122 may be transmitted from the eNB 102 to the UE 122 via the gNB 108. In addition, this RRC message configuration may be used for E-UTRA / 5GC (option 5 described in non-patent document 17), which is non-MR-DC and in which eNB102 (enhanced eNB) uses 5GC as a core network.

[0080] Conversely, in the MR-DC described in Non-Patent Document 8, in NE-DC (NR-E-UTRA Dual Connectivity), which is an MR-DC in which the core network is 5GC 110 and the master node is gNB 108, the NR RRC message described in Non-Patent Document 10 may be transmitted and received between the gNB 108 and the UE 122. In this case, the RRC message may include not only NR configuration information but also LTE (E-UTRA) configuration information described in Non-Patent Document 4. Furthermore, the RRC message transmitted from the gNB 108 to the UE 122 may be transmitted from the gNB 108 to the UE 122 via the eNB 102.

[0081] In addition, regardless of whether MR-DC is used, the RRC message for E-UTRA transmitted from eNB102 to UE122 may include an RRC message for NR, or the RRC message for NR transmitted from gNB108 to UE122 may include an RRC message for E-UTRA.

[0082] Furthermore, a network configuration in which the master node is eNB102 and EPC104 is the core network may be called E-UTRA / EPC. A network configuration in which the master node is eNB102 and 5GC110 is the core network may be called E-UTRA / 5GC. A network configuration in which the master node is gNB108 and 5GC110 is the core network may be called NR or NR / 5GC. This terminology is not limited to cases in which DC is configured. When DC is not configured, the above-mentioned master node may refer to a base station device that communicates with a terminal device.

[0083] FIG. 14 shows an example of an ASN.1 description representing any or all of the fields and information elements related to radio bearer establishment included in the message related to RRC connection reestablishment in NR in FIG. 4 . FIG. 15 shows an example of an ASN.1 description representing any or all of the fields and information elements related to radio bearer establishment included in the message related to RRC connection reestablishment in E-UTRA in FIG. 4 . In the ASN.1 examples according to the embodiments of the present invention, including but not limited to FIGS. 14 and 15 , the symbols <Omitted> and <Omitted> are not part of the ASN.1 notation and indicate the omission of other information. Note that information elements may be omitted even when there is no notation such as <Omitted> or <Omitted>. Note that the ASN.1 examples according to the embodiments of the present invention do not strictly follow the ASN.1 notation method. They represent example parameters of a message related to RRC connection reestablishment in the embodiments of the present invention, and other names and notations may be used. Note that the ASN.1 examples shown here only represent examples of main information closely related to one embodiment of the present invention, in order to avoid complication of explanation. Note that parameters described in ASN.1 may be referred to as information elements without being distinguished as fields, information elements, etc. Also, in the embodiments of the present invention, parameters such as fields and information elements described in ASN.1 included in an RRC message may be referred to as information. Note that the message related to reconfiguration of the RRC connection may be an RRC reconfiguration message in NR or an RRC connection reconfiguration message in E-UTRA.

[0084] In FIG. 14, the information element represented by RadioBearerConfig is an information element related to the configuration of radio bearers such as SRB and DRB, and includes a PDCP configuration information element and an SDAP configuration information element, which will be described later. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be information indicating SRB (signaling radio bearer) configuration, and may also be referred to as an SRB configuration information element or a signaling radio bearer configuration information element. The information element represented by SRB-ToAddModList may be a list of information indicating SRB configuration. The information element represented by DRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be information indicating DRB (data radio bearer) configuration, and may also be referred to as a DRB configuration information element or a data radio bearer configuration information element. The information element represented by DRB-ToAddModList may be a list of information indicating DRB configuration. Note that either or both of the SRB configuration and the DRB configuration may also be referred to as radio bearer configuration.

[0085] The information element represented by SRB-Identity in the SRB configuration information element is information on the SRB identifier (SRB Identity) of the SRB to be added or changed, and may be an identifier that uniquely identifies the SRB in each terminal device. The information element represented by SRB-Identity in the SRB configuration information element may also be referred to as an SRB identifier information element, a radio bearer identifier information element, or a signaling radio bearer identifier information element.

[0086] The information element represented by DRB-Identity in the DRB configuration information element is information on the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. The information element represented by DRB-Identity in the DRB configuration information element may also be referred to as a DRB identifier information element, a radio bearer identifier information element, or a data radio bearer identifier information element. In the example of Figure 14, the value of the DRB identifier is an integer value from 1 to 32, but it may also be another value. In the case of DC, the DRB identifier is unique within the scope of the UE 122.

[0087] The information element represented by cnAssociation in the DRB configuration information element may be an information element indicating whether the EPC 104 or the 5GC 110 is used as the core network, and may also be referred to as a core network association information element. That is, when the UE 122 connects to the EPC, the DRB may be associated with the EPS bearer identifier information element (eps-BearerIdentity) in the cnAssociation or the EPS bearer identifier (EPS bearer identity) that is the value of the EPS bearer identifier information element, and when the UE 122 connects to the 5GC 110, the DRB may be associated with an SDAP entity configured according to a later-described SDAP configuration information element (sdap-Config), or with a later-described PDU session information element included in the SDAP configuration information element, or with a PDU session identifier that is the value of the PDU session information element, or with a PDU session indicated by the PDU session information element. That is, the information represented by cnAssociation may include an EPS bearer identifier information element (eps-BearerIdentity) when EPC104 is used in the core network, such as when EN-DC is used, and may also include an information element (sdap-Config) indicating SDAP configuration when core network 5GC110 is used, i.e., when EN-DC is not used.

[0088] The information element represented by sdap-Config may be information regarding the configuration or reconfiguration of an SDAP entity that determines how QoS flows and DRBs are mapped when the core network is 5GC110, and may also be referred to as an SDAP configuration information element.

[0089] The field or information element indicated by pdu-session or PDU-SessionID included in the SDAP configuration information element may be the PDU session identifier of the PDU session described in Non-Patent Document 2 to which the QoS flow that is mapped to the radio bearer corresponding to the value of the radio bearer identifier information element included in the DRB configuration information element that includes this SDAP configuration information element belongs, and may also be referred to as the PDU session identifier information element. The value of the PDU session identifier information element may be a non-negative integer. Furthermore, in each terminal device, multiple DRB identifiers may correspond to one PDU session identifier.

[0090] The information element indicated by mappedQoS-FlowsToAdd included in the SDAP configuration information element may be information indicating a list of QoS flow identity (QFI) information elements (described later) of QoS flows that are mapped to or additionally mapped to the radio bearer corresponding to the value of the radio bearer identifier information element included in the DRB configuration information element that includes this SDAP configuration information element, and may also be referred to as an additional QoS flow information element. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session information element included in this SDAP configuration information element.

[0091] Furthermore, the information element indicated by mappedQoS-FlowsToRelease included in the SDAP configuration information element may be information indicating a list of QoS flow identity (QFI) information elements (described later) of the QoS flows to be released from among the QoS flows that map to the radio bearer corresponding to the value of the radio bearer identifier information element included in the DRB configuration information element that includes this SDAP configuration information element, or may be referred to as the QoS flow information element to be released. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session information element included in this SDAP configuration information element.

[0092] The information element indicated by QFI may be a QoS flow identifier that uniquely identifies a QoS flow, as described in Non-Patent Document 2, and may also be referred to as a QoS flow identifier information element. The value of the QoS flow identifier information element may be a non-negative integer. The value of the QoS flow identifier information element may also be unique for a PDU session.

[0093] In addition, the SDAP setting information element may also include an uplink header information element indicating whether an uplink SDAP header is present in the uplink data transmitted via the DRB being set, a downlink header information element indicating whether a downlink SDAP header is present in the downlink data received via the DRB being set, and a default bearer information element indicating whether the DRB being set is a default radio bearer (default DRB).

[0094] Furthermore, information elements represented as pdcp-Config or PDCP-Config among the SRB configuration information element and the DRB configuration information element may be information elements related to the configuration of the NR PDCP entity for establishing or changing the PDCP 306 for the SRB and / or DRB, and may also be referred to as PDCP configuration information elements. The information elements related to the configuration of the NR PDCP entity may include an information element indicating the size of the uplink sequence number, an information element indicating the size of the downlink sequence number, an information element indicating the profile of the ROHC (Robust Header Compression), a re-ordering timer information element, etc.

[0095] The information element represented by DRB-ToReleaseList included in the information element represented by RadioBearerConfig may include information indicating one or more DRB identifiers to be released.

[0096] In FIG. 15, the information element represented by RadioResourceConfigDedicated may be an information element used for setting, changing, releasing, etc. a radio bearer. The information element represented by SRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating SRB (signaling radio bearer) setting, and may also be referred to as an SRB setting information element or a signaling radio bearer setting information element. The information element represented by SRB-ToAddModList may be a list of information indicating SRB setting. The information element represented by DRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating DRB (data radio bearer) setting, and may also be referred to as a DRB setting information element or a data radio bearer setting information element. The information element represented by DRB-ToAddModList may be a list of information indicating DRB setting. Note that either or both of the SRB setting and the DRB setting may also be referred to as radio bearer setting.

[0097] The information element represented by "SRB-Identity" in the SRB configuration information element is information on the SRB identifier (SRB Identity) of the SRB to be added or changed, and may be an identifier that uniquely identifies the SRB in each terminal device. The information element represented by "SRB-Identity" in the SRB configuration information element may also be referred to as an SRB identifier information element, a radio bearer identifier information element, or a signaling radio bearer identifier information element. The information element represented by "SRB-Identity" in Figure 15 may be an information element having the same role as the information element represented by "SRB-Identity" in Figure 14.

[0098] The information element represented by DRB-Identity in the DRB configuration is information on the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be a DRB identifier that uniquely identifies the DRB in each terminal device. The information element represented by DRB-Identity in the DRB configuration may also be referred to as a DRB identifier information element, a radio bearer identifier information element, or a data radio bearer identifier information element. The value of the DRB identifier is an integer value from 1 to 32 in the example of Figure 15, but it may also take on a different value. The information element represented by DRB-Identity in Figure 15 may be an information element with the same role as the information element represented by DRB-Identity in Figure 14.

[0099] The information element represented by eps-BearerIdentity in the DRB setting information element may be an EPS bearer identifier that uniquely identifies an EPS bearer in each terminal device. The information element represented by eps-BearerIdentity may also be called an EPS bearer identifier information element. The value of the EPS bearer identifier is an integer value from 1 to 15 in the example of Figure 15, but it may also take on a different value. The information element represented by eps-BearerIdentity in Figure 15 may be an information element that has the same role as the information element represented by eps-BearerIdentity in Figure 14. Furthermore, there may be a one-to-one correspondence between an EPS bearer identifier and a DRB identifier in each terminal device.

[0100] Furthermore, the information elements represented as pdcp-Config or PDCP-Config in the SRB configuration information element and DRB configuration information element may be information elements related to the configuration of the E-UTRA PDCP entity for establishing or modifying the PDCP 206 for the SRB and / or DRB, and may also be referred to as PDCP configuration information elements. The information elements related to the configuration of the E-UTRA PDCP entity may include an information element indicating the size of the sequence number, an information element indicating the profile of RObust Header Compression (RoHC), a re-ordering timer information element, etc.

[0101] Furthermore, some or all of the information elements shown in Figure 14 or 15 may be optional. That is, the information elements shown in Figure 14 or 15 may be included in a message related to RRC connection reconfiguration as necessary or depending on the conditions. Furthermore, a message related to RRC connection reconfiguration may include, in addition to information elements related to radio bearer configuration, an information element indicating that full configuration is applied. The information element indicating that full configuration is applied may be represented by an information element name such as fullConfig, and may indicate that full configuration is applied using true, enable, etc.

[0102] An information element represented by DRB-ToReleaseList included in an information element represented by RadioResourceConfigDedicated may include information indicating one or more DRB identifiers to be released.

[0103] In the following description, eNB102 and / or gNB108 will also be simply referred to as base station devices, and UE122 will also be simply referred to as terminal devices.

[0104] When an RRC connection is established, when an RRC connection is re-established, or during handover, one serving cell provides mobility information for the NAS. When an RRC connection is re-established, or during handover, one serving cell provides security input. This serving cell is referred to as the primary cell (PCell). Depending on the capabilities of the terminal device, one or more serving cells (secondary cells, SCells) may be configured in addition to the primary cell.

[0105] Furthermore, a set of serving cells consisting of two subsets may be configured for the terminal device. The two subsets may be configured with a cell group (master cell group) consisting of one or more serving cells including a primary cell (PCell), and one or more cell groups (secondary cell groups) consisting of one or more serving cells including a primary secondary cell (PSCell) but not the primary cell. The primary secondary cell may be a cell in which PUCCH resources are configured.

[0106] An example of an operation regarding a radio link failure (RLF) by an RRC-connected terminal device will be described.

[0107] The terminal device acquires information from the base station device in its coverage area, such as the values ​​(t310 and t313) of timers (e.g., T310 and T313) for detecting physical layer problems in the serving cell, N310 and N313 which are thresholds for the number of out-of-sync (OoS) detections, and N311 and N314 which are thresholds for the number of in-sync (IS) detections, via broadcast information or an RRC message for each user. Default values ​​may be set for the timer values ​​and count thresholds. The names of the timers may differ between EUTRA and NR.

[0108] For radio link monitoring, the physical layer processing unit of the terminal device determines whether the radio link quality of the serving cell is high or low for a specific period (e.g., TEvaluate) based on information such as the received power of the received reference signal and / or the received power of the synchronization signal and / or the packet error rate. _ When the radio link quality of the serving cell exceeds a certain threshold (Qout=200 ms) and is estimated to be worse than a certain threshold (Qout), the physical layer processor notifies the RRC layer processor, which is a higher layer, of "out-of-sync." In addition, the physical layer processor determines whether the radio link quality of the serving cell is worse than a certain period (e.g., TEvaluate _ When it is estimated that the received signal exceeds a specific threshold (Qin) exceeding Qin=100 ms, the physical layer processor notifies the upper layer RRC layer processor of "in-sync". Note that the physical layer processor may notify the upper layer of out-of-sync or in-sync at specific intervals (e.g., TReport_sync=10 ms) or more.

[0109] Here, for example, the threshold Qout may be defined as a level at which the downlink radio link cannot be reliably received and a hypothetical block error rate (BER) of a PDCCH transmission based on predetermined parameters is a first specific rate. Alternatively, for example, the threshold Qin may be defined as a level at which the downlink radio link quality can be significantly more reliably received than in the Qout state and a hypothetical block error rate of a PDCCH transmission based on predetermined parameters is a second specific rate. Alternatively, multiple BERs (levels of the threshold Qout and the threshold Qin) may be defined based on the frequency used, the subcarrier spacing, the type of service, and the like. Alternatively, the first specific rate and / or the second specific rate may be a default value defined in a specification. Alternatively, the first specific rate and / or the second specific rate may be a value notified or broadcast from the base station device to the terminal device.

[0110] The terminal device may perform radio link monitoring using a certain type of reference signal (e.g., a cell-specific reference signal (CRS)) in a serving cell (e.g., a PCell and / or a PSCell). The terminal device may also receive a configuration (radio link monitoring configuration: RadioLinkMonitoringConfig) indicating which reference signal is to be used for radio link monitoring in a serving cell (e.g., a PCell and / or a PSCell) from a base station device, and perform radio link monitoring using one or more configured reference signals (referred to here as RLM-RS). The terminal device may also perform radio link monitoring using other signals. When a condition for being synchronized in the serving cell (e.g., a PCell and / or a PSCell) is met, the physical layer processing unit of the terminal device may notify a higher layer that it is in synchronization.

[0111] The radio link monitoring configuration may include information indicating a monitoring purpose and identifier information indicating a reference signal. For example, the monitoring purpose may include a purpose of monitoring a radio link failure, a purpose of monitoring a beam failure, or both purposes. Furthermore, for example, the identifier information indicating the reference signal may include information indicating an identifier (SSB-Index) of a synchronization signal block (SSB) of a cell. That is, the reference signal may include a synchronization signal. Furthermore, for example, the identifier information indicating the reference signal may include information indicating an identifier linked to a channel state information reference signal (CSI-RS) configured in the terminal device.

[0112] In the primary cell, the RRC layer processing unit of the terminal device may start or restart the timer (T310) when it receives a predetermined number (N310) of consecutive out-of-sync notifications from the physical layer processing unit. The RRC layer processing unit of the terminal device may stop the timer (T310) when it receives a predetermined number (N311) of consecutive in-sync notifications. The RRC layer processing unit of the terminal device may transition to an idle state or perform an RRC connection re-establishment procedure when the timer (T310) expires. For example, the behavior of the terminal device may differ depending on the establishment status of AS security. If AS security is not established, the terminal device may transition to the RRC IDLE state. If AS security is established, the terminal device may perform an RRC connection re-establishment procedure. The determination of whether to start or restart the timer T310 may also include a condition that none of the timers T300, T301, T304, and T311 are running.

[0113] An example of the conditions for starting, stopping, and expiring each of the timers in EUTRA is shown in Figure 9. Note that in NR, the timer names and / or message names may be different, but similar conditions may be applied.

[0114] Furthermore, in the primary secondary cell, the RRC layer processing unit of the terminal device may start or restart a timer (T313) when it receives out-of-sync notification from the physical layer processing unit a predetermined number of times (N313 times) in a row. Furthermore, the RRC layer processing unit of the terminal device may stop the timer (T313) when it receives in-sync notification a predetermined number of times (N314 times) in a row. When the timer (T313) expires, the RRC layer processing unit of the terminal device may execute an SCG failure information procedure to notify the network of an SCG failure.

[0115] Furthermore, in an SpCell (PCell in an MCG and PSCell in an SCG), the RRC layer processing unit of the terminal device may start or restart a timer (T310) for each SpCell when it receives an out-of-sync notification from the physical layer processing unit for each SpCell a predetermined number of times (N310 times) consecutively. Furthermore, the RRC layer processing unit of the terminal device may stop a timer (T310) for each SpCell when it receives an in-sync notification for each SpCell a predetermined number of times (N311 times) consecutively. When the timer (T310) for each SpCell expires, the RRC layer processing unit of the terminal device may transition to an idle state or perform a procedure to re-establish an RRC connection if the SpCell is a PCell. Furthermore, if the SpCell is a PSCell, it may execute an SCG failure information procedure to notify the network of an SCG failure.

[0116] The above description is an example in which discontinuous reception (DRX) is not configured in the terminal device. When DRX is configured in the terminal device, the RRC layer processing unit of the terminal device may configure the physical layer processing unit so that the period for measuring radio link quality and the interval for reporting to higher layers take values ​​different from those when DRX is not configured. Note that even when DRX is configured, while the above timers (T310, T313) are running, the period for measuring radio link quality to estimate synchronization and the interval for reporting to higher layers may take values ​​that are used when DRX is not configured.

[0117] Also, for example, in order to detect an early physical layer problem, the RRC layer processing unit of the terminal device may start a timer (T314) when it receives an early out-of-sync notification from the physical layer processing unit a predetermined number of times (N310 times) in succession. Also, the RRC layer processing unit of the terminal device may stop the timer (T314) when it receives an in-sync notification a predetermined number of times (N311 times) in succession while T314 is running.

[0118] Furthermore, for example, in order to detect early physical layer improvement, the RRC layer processing unit of the terminal device may start a timer (T315) when it receives a predetermined number (N311) of consecutive early synchronization notifications from the physical layer processing unit. Furthermore, the RRC layer processing unit of the terminal device may stop the timer (T315) when it receives a predetermined number (N311) of consecutive synchronization notifications while T315 is running.

[0119] Also, for example, when reporting a measurement to a base station device, if the measurement configuration is set to perform a first measurement (for example, to perform a measurement using timer T312), if timer T310 is running, and if timer T312 is not running, timer T312 is started. The RRC layer processing unit of the terminal device may stop timer (T312) when it receives a synchronized message a predetermined number of times (N311 times) in succession.

[0120] Furthermore, the RLM-RS may be undefined if it is not explicitly or implicitly configured by the network, i.e., the terminal device does not need to monitor the radio link if the RLM-RS is not configured by the network (e.g., a base station device).

[0121] Furthermore, the RLM-RS is a reference signal used for radio link monitoring, and multiple RLM-RSs may be configured in a terminal device. The resource of one RLM-RS may be one SS block or one CSI-RS resource (or port).

[0122] In addition, radio link monitoring using CRS may be performed in a EUTRA cell, and radio link monitoring using RLM-RS may be performed in an NR cell, but this is not limited to this.

[0123] Radio link failure detection based on radio link monitoring is described.

[0124] The terminal device determines that a radio link failure has been detected in the MCG when timer T310 expires, or when timer T312 expires, or when the MAC layer of the MCG notifies it of a random access problem while none of the specific timers are running, or when the RLC layer of the MCG notifies it that the retransmission of an SRB or DRB has reached the maximum number of retransmissions. The specific timers do not include timer T310 and timer T312.

[0125] When the number of retransmissions of a random access preamble reaches a predetermined number in the MAC entity, if the random access preamble transmission is performed in an SpCell, the MAC entity of the cell group including the SpCell may notify a higher layer (here, the RRC entity) of the random access problem.

[0126] When the terminal device determines that a radio link failure has been detected in the MCG, it stores various information as radio link failure information. If AS security is not activated, it sets the release reason to "Other" and starts the process of leaving RRC_CONNECTED. If AS security is activated, it starts the RRC connection re-establishment procedure.

[0127] When timer T313 expires, or when the terminal device is notified of a random access problem by the MAC layer of the SCG, or when the terminal device is notified by the RLC layer of the SCG that the maximum number of retransmissions has been reached, the terminal device determines that a radio link failure has been detected in the SCG and starts processing to report related information to the base station device as an SCG radio link failure.

[0128] When timer T314 expires, the terminal device determines that an "early out-of-sync" event has been detected and initiates processing to report related information to the base station device.

[0129] When timer T315 expires, the terminal device determines that an "early synchronization in progress" event has been detected and starts processing to report related information to the base station device.

[0130] The procedure for re-establishing an RRC connection will now be described.

[0131] The purpose of the RRC connection re-establishment procedure is to re-establish the RRC connection, which may involve SRB1 resumption procedures, security reactivation, and PCell-only configuration.

[0132] The RRC connection re-establishment procedure may be initiated when any of the following conditions (A) to (E) is met: (A) When a radio link failure of the MCG is detected (B) When handover fails (in NR, when synchronized reconfiguration in MCG fails) (C) When mobility to another RAT fails (D) When an integrity check failure related to SRB1 or SRB2 is notified from the lower layer. (E) When RRC connection re-establishment fails

[0133] When the RRC connection re-establishment procedure is initiated, the terminal device performs some or all of the following processes (A) to (J). (A) If timer T310 is running, stop timer T310. (B) If timer T312 is running, stop timer T312. (C) If timer T313 is running, stop timer T313. (C) If timer T314 is running, stop timer T314. (D) Start timer T311 (E) Suspend all RBs except SRB0 (F) Reset MAC (G) If an SCell of the MCG is set, release that SCell. (H) Apply the default physical channel settings (I) Apply default MAC primary settings to MCG (J) Performing the cell selection procedure

[0134] When the optimal cell of the same RAT is selected by the cell selection procedure, the terminal device performs the following process.

[0135] If the terminal device is connected to 5GC and the selected cell can only be connected via EPC, or if the terminal device is connected to EPC and the selected cell can only be connected via 5GC, perform an action to leave RRC_CONNECTED with the release reason "RRC connection failure". Otherwise, stop timer T311, start timer T301, and start sending an RRC connection reestablishment request message.

[0136] When timer T311 expires, the terminal device performs an action to leave RRC_CONNECTED with the release reason set to "RRC connection failure."

[0137] If timer T301 expires or if the selected cell is no longer the best cell in terms of the cell selection criteria, the terminal device performs an action to leave RRC_CONNECTED with release reason "RRC connection failure".

[0138] Handover will now be described.

[0139] An example of processing related to handover between the same RATs (i.e., between EUTRAs) in EUTRA will be described with reference to Fig. 7. The description using Fig. 7 is merely an example, and some processing may be omitted or other processing may be included. Alternatively, other processing may be performed as processing related to handover.

[0140] In FIG. 7, a handover source base station (Source eNB) configures a terminal device to measure neighboring cells (Step S701).

[0141] The terminal device performs measurements set by the Source eNB and reports the measurement results to the Source eNB based on the reporting conditions (step S702).

[0142] The Source eNB determines handoff of the terminal device based on information such as the reported measurement results (step S703).

[0143] The Source eNB issues a handover request message including information required for preparing for handover to the base station device (Target eNB) that is the handover destination (step S704).

[0144] Admission control may be performed at the target eNB, which configures the required resources (step S705).

[0145] The Target eNB sends a handover request acknowledgement message (HANDOVER REQUEST ACKNOWLEDGE message) to the Source eNB (step S706). The Handover Request Acknowledgement message includes a container that is transparently sent to the terminal device as an RRC message for executing the handover. The container may include some or all of the following: a new C-RNTI, a security algorithm identifier of the Target eNB for the selected security algorithm, a preamble for a dedicated random access channel (random access preamble), and system information of the target cell.

[0146] The Source eNB sends the container (a first RRC connection reconfiguration message (RRCConnectionReconfiguration message) including a mobility control information (mobilityControlInfo) information element (IE)) received from the Target eNB to the terminal device (step S707).

[0147] When a make-before-break handover (Make-Before-Break HO: MBB-HO) is configured by the first RRC connection reconfiguration message, the terminal device maintains a connection with the source eNB from the time of receiving the first RRC connection reconfiguration message until at least the time of performing the first uplink transmission at the target eNB. The make-before-break handover may be selected from a plurality of configurations. For example, it may be determined that a make-before-break handover has been configured by setting a field makeBeforeBreak-r14 included in an already specified mobilityControlInfo information element to true. It may also be determined that a make-before-break handover has been configured by including a newly defined makeBeforeBreak-r16 field in the mobilityControlInfo information element and setting the field makeBeforeBreak-r16 to true. The field makeBeforeBreak-r16 may have an information element containing various configurations as its value.

[0148] The Source eNB sends an SN STATUS TRANSFER message to the Target eNB to convey the reception status of the uplink PDCP sequence number and the transmission status of the downlink PDCP sequence number (step S708).

[0149] If RACH-less handover is not configured by the first RRC connection reconfiguration message, the terminal device performs synchronization with the target eNB and accesses the target cell using a random access channel. At this time, if a dedicated random access preamble is indicated in the first RRC connection reconfiguration message, a contention-free random access procedure is performed, and if a dedicated random access preamble is not indicated, a contention-based random access procedure is performed. If RACH-less handover is configured by the first RRC connection reconfiguration message, the terminal device performs synchronization with the target eNB (step S709).

[0150] If a RACH-less handover has not been configured by the first RRC connection reconfiguration message, the target eNB returns information on uplink allocation and timing advance to the terminal device (step S710).

[0151] If a RACH-less handover is configured by the first RRC connection reconfiguration message and a periodic pre-allocated uplink grant has not been obtained by the first RRC connection reconfiguration message, the UE receives an uplink grant via the PDCCH of the target cell, and uses the first available uplink grant after synchronizing with the target cell (step S710a).

[0152] When RACH-less handover is not configured and the terminal device successfully accesses the target cell, the terminal device sends an RRC connection reconfiguration complete message (RRCConnectionReconfigurationComplete message) to the target eNB to confirm the handover. This RRC connection reconfiguration complete message indicates the completion of the handover procedure of the terminal device. The RRC connection reconfiguration complete message includes a C-RNTI, and the target eNB verifies the C-RNTI in the received RRC connection reconfiguration complete message.

[0153] When a RACH-less handover is configured and the terminal device receives an uplink grant, the terminal device sends an RRC connection reconfiguration complete message (RRCConnectionReconfigurationComplete message) to the target eNB to confirm the handover. The RRC connection reconfiguration complete message includes a C-RNTI, and the target eNB verifies the C-RNTI in the received RRC connection reconfiguration complete message. When the terminal device receives a UE contention resolution identity MAC control element from the target eNB, the handover procedure of the terminal device is completed (step S711).

[0154] The Target eNB sends a PATH SWITCH REQUEST message to the MME to notify that the terminal device has changed cells (step S712).

[0155] The MME sends a modify bearer request (MODIFY BEARER REQUEST) message to the serving gateway (S-GW) (step S713).

[0156] The S-GW switches the downlink data path to the target side. The S-GW sends one or more end marker packets to the Source eNB to release user plane resources to the Source eNB (step S714).

[0157] The S-GW sends a MODIFY BEARER RESPONSE message to the MME (step S715).

[0158] The MME acknowledges the path switch request with a PATH SWITCH REQUEST ACKNOWLEDGE message (step S716).

[0159] The Target eNB indicates the success of the handover and triggers the release of resources by the Source eNB by sending a UE CONTEXT RELEASE message to the Source eNB, which the Target eNB may send after receiving the Path Switch Request Acknowledge message (step S717).

[0160] Upon receiving the UE context release message, the Source eNB may release radio and C-plane related resources for the UE context, and ongoing data transfer may continue (step S718).

[0161] When timer T304 expires, the terminal device executes some or all of the following processes (A) to (D). (A) Deeming the dedicated random access channel established by the first RRC connection reconfiguration message unavailable (B) Return the terminal device configuration to the configuration used in the source PCell, excluding the dedicated physical channel configuration, the MAC layer primary configuration, and the semi-persistent schedule configuration. (C) Accumulate relevant information as handover failure information (D) Initiate the RRC connection re-establishment procedure and terminate the RRC connection reconfiguration procedure.

[0162] The following describes in detail the processing of the terminal device that has received the first RRC connection reconfiguration message. The first RRC connection reconfiguration message may include a mobility control information (mobilityControlInfo) information element. The mobilityControlInfo information element includes parameters related to network-controlled mobility from another RAT to EUTRA or within EUTRA (e.g., target cell identifier and carrier frequency information).

[0163] If the terminal device receives an RRC connection reconfiguration message (first RRC connection reconfiguration message) including a mobilityControlInfo information element and is able to comply with the settings in that message, the terminal device performs some or all of the following processes (A) to (G). (A) If timer T310 is running, stop timer T310. (B) If timer T312 is running, stop timer T312. (C) If timer T314 is running, stop timer T314. (D) Start timer T304 with the value (t304) contained in the mobilityControlInfo information element. (E) If carrier frequency information is included, determine that frequency as the frequency of the target cell, and if carrier frequency information is not included, determine the frequency of the source PCell as the frequency of the target cell. (F) If the access restriction timer is running, stop the timer. (G) Initiate downlink synchronization to the target cell

[0164] An example of a process related to handover between the same RATs (i.e., between NRs) in NR will be described with reference to Fig. 8. The description using Fig. 8 is merely an example, and some of the processes may be omitted or other processes may be included. Alternatively, other processes may be performed as the process related to handover.

[0165] In FIG. 8, the handover source base station device (Source gNB) configures the terminal device to measure neighboring cells, and the terminal device performs the measurements configured by the Source gNB and reports the measurement results to the Source gNB (step S801).

[0166] The source gNB decides to handoff the terminal device based on information such as reported measurement results (step S802).

[0167] The Source gNB issues a handover request message to the base station device (Target gNB) that is the destination of the handover, including information necessary for preparing for the handover (Step S803).

[0168] Admission control may be performed at the target gNB (step S804).

[0169] The Target gNB prepares for the handover and sends a HANDOVER REQUEST ACKNOWLEDGE message to the Source gNB (step S805). The HANDOVER REQUEST ACKNOWLEDGE message includes a container that is transparently sent to the terminal device as an RRC message for executing the handover.

[0170] The source gNB sends the container (first RRC reconfiguration message (RRCReconfiguration message)) received from the target gNB to the terminal device (step S806). The RRC reconfiguration message may include some or all of the following: a target cell identifier, a new C-RNTI, a security algorithm identifier of the target gNB for the selected security algorithm, a set of dedicated random access channel resources, a UE-specific CSI-RS configuration, common random access channel resources, and system information of the target cell.

[0171] In addition, if a make-before-break handover (MBB-HO) is configured by the first RRC reconfiguration message, the terminal device may maintain a connection with the source gNB from the time of receiving the first RRC reconfiguration message until at least the time of performing the first uplink transmission at the target gNB.

[0172] The Source eNB sends an SN STATUS TRANSFER message to the Target gNB to convey the reception status of the uplink PDCP sequence number and the transmission status of the downlink PDCP sequence number (step S807).

[0173] If RACH-less handover is not configured by the first RRC reconfiguration message, the terminal device performs synchronization with the target eNB and accesses the target cell using a random access channel. At this time, if a dedicated random access preamble is indicated in the first RRC reconfiguration message, a contention-free random access procedure may be performed, and if a dedicated random access preamble is not indicated, a contention-based random access procedure may be performed. If RACH-less handover is configured by the first RRC reconfiguration message, the terminal device performs synchronization with the target gNB.

[0174] If RACH-less handover has not been configured by the first RRC reconfiguration message, the target gNB may return uplink allocation and timing advance information to the terminal device.

[0175] If a RACH-less handover is configured by the first RRC reconfiguration message and a periodic pre-allocated uplink grant has not been obtained by the first RRC reconfiguration message, the UE receives the uplink grant via the PDCCH of the target cell, and uses the first available uplink grant after synchronization with the target cell.

[0176] When RACH-less handover is not configured and the terminal device successfully accesses the target cell, the terminal device may send an RRC reconfiguration complete message (RRCReconfigurationComplete message) to the target gNB to confirm the handover. This RRC reconfiguration complete message may indicate the completion of the handover procedure of the terminal device. The RRC reconfiguration complete message includes a C-RNTI, and the target gNB may verify the C-RNTI in the received RRC reconfiguration complete message.

[0177] When a RACH-less handover is configured and the terminal device receives an uplink grant, the terminal device may send an RRC Reconfiguration Complete message to the target gNB to confirm the handover. The RRC Reconfiguration Complete message includes a C-RNTI, and the target gNB may verify the C-RNTI in the received RRC Reconfiguration Complete message. When the terminal device receives a UE contention resolution identity MAC control element from the target gNB, the handover procedure of the terminal device may be completed (step S808).

[0178] The target eNB sends a path switch request (PATH SWITCH REQUEST) message to the AMF to cause the 5GC to switch the downlink data path to the target gNB and establish an NG-C interface instance for the target gNB (step S809).

[0179] The 5GC switches the downlink data path to the target gNB. The UPF sends one or more end marker packets to the source eNB to release user plane resources to the source gNB (step S810).

[0180] The AMF acknowledges the path switch request with a PATH SWITCH REQUEST ACKNOWLEDGE message (step S811).

[0181] The target gNB indicates the success of the handover by sending a UE CONTEXT RELEASE message to the source eNB, triggering the release of resources by the source gNB. The target gNB may send this message after receiving a PATH SWITCH REQUEST ACKNOWLEDGEMENT message from the AMF. Upon receiving the UE CONTEXT RELEASE message, the source gNB may release radio and C-plane related resources for the UE context. Ongoing data transfer may continue (step S812).

[0182] When timer T304 expires, the terminal device executes some or all of the following processes (A) to (D). (A) If timer T304 of the MCG expires, release the dedicated random access channel of the MCG established by the first RRC connection reconfiguration message. (B) If timer T304 of the MCG expires, the UE reverts to the settings used in the source PCell. (D) If timer T304 of the MCG expires, initiate the RRC connection re-establishment procedure. (E) If the SCG timer T304 expires, release the SCG dedicated random access channel established by the first RRC connection reconfiguration message. (E) If timer T304 of the SCG expires, initiate the procedure to report that the synchronized reconfiguration of the SCG has failed.

[0183] The processing of the terminal device that has received the first RRC reconfiguration message will now be described in detail. The first RRC reconfiguration message may include a reconfiguration with synchronization (reconfigurationWithSync) information element. The reconfigurationWithSync information element may be included in the SpCell configuration for each cell group (MCG or SCG) in the RRC reconfiguration message. The reconfigurationWithSync information element includes parameters related to reconfiguration with synchronization to the target SpCell (e.g., the target SpCell configuration, a new identifier for the terminal device, etc.).

[0184] A terminal device that receives an RRC reconfiguration message (first RRC reconfiguration message) including a reconfigurationWithSync information element performs some or all of the following processes (A) to (E). (A) If security is not activated, start the process of leaving RRC_CONNECTED with the release reason set to "Other", which may be a process of going to RRC_IDLE. (B) If the timer T310 of the target SpCell is running, stop the timer T310 of the target SpCell. (C) Start timer T304 of the target SpCell with the value (t304) included in the reconfigurationWithSync information element. (D) If downlink frequency information is included, determine that frequency as the SSB frequency of the target cell. If downlink frequency information is not included, determine the SSB frequency of the source SpCell as the SSB frequency of the target cell. (E) Initiate downlink synchronization to the target cell

[0185] As described above, in EUTRA and / or NR, when a make-before-break handover (MBB-HO) is configured in a terminal device, the terminal device may maintain a connection with a source eNB or a source gNB until the first uplink transmission is performed at the target eNB or the target gNB, or for an arbitrary period of time. Currently, timer T310 stops when the terminal device receives a first RRC connection reconfiguration message or a first RRC reconfiguration message. Therefore, the terminal device cannot determine whether a situation exists in the serving cell (source cell) of the source eNB or the source gNB that is considered to be a radio link failure due to a physical layer problem. Furthermore, when timer T304 is running, the terminal device cannot determine whether a situation exists in the serving cell (source cell) of the source eNB or the source gNB that is considered to be a radio link failure due to a random access problem notified from the MAC layer. Furthermore, in the source cell, if the maximum number of retransmissions in RLC is reached, it is considered that the radio link has failed, and an RRC connection re-establishment procedure is executed.

[0186] In Make-Before-Break handover (MBB-HO), active protocol layers may be used on both the source and target sides to maintain connection with the source eNB or source gNB until the target eNB or gNB performs its first uplink transmission or for an arbitrary period of time. Therefore, MBB-HO may also be referred to as a Dual Active Protocol Stack (DAPS) handover. In a DAPS handover, two confidentiality keys and / or two integrity keys and / or two RoHC protocols for the source and target may be configured in the PDCP entity, two RLC bearers for the source and target may be configured, and two MAC entities for the source and target may be configured. In addition, some or all of the confidentiality keys, integrity keys, RoHC protocol, RLC bearers, and MAC bearers set for the source and target may be used simultaneously or alternately during handover using DAPS. Hereinafter, make-before-break handover (MBB-HO) may be read as DAPS handover.

[0187] In the following, "applying make-before-break handover" may mean "applying DAPS handover." "Configuring make-before-break handover (MBB-HO) in a terminal device" may mean "configuring DAPS handover in the terminal device." "Configuring make-before-break handover (MBB-HO) in a terminal device (configuring DAPS handover)" may mean "applying MBB-HO (DAPS handover) to any radio bearer configured in the terminal device," or "applying MBB-HO (DAPS handover) to at least one of the radio bearers configured in the terminal device."

[0188] Next, a conditional handover will be described. In NR, a conditional handover may be an RRC reconfiguration using an RRC reconfiguration message including an information element (conditional handover configuration) including information included in a synchronized reconfiguration information element and information indicating a condition for applying the information element (conditional handover condition). In LTE, a conditional handover may be an RRC connection reconfiguration using an RRC connection reconfiguration message including an information element (conditional handover configuration) including information included in a mobility control information information element and information indicating a condition for applying the information element (conditional handover condition).

[0189] In NR, conditional handover configuration may include some or all of the following configurations (A) to (F): (A) Cell group configuration information (CellGroupConfig) (B) Information indicating whether the setting is full or not (C) NAS layer messages (D) System Information (E) Measurement settings (F) Radio bearer configuration

[0190] The setting information of the cell group may include some or all of the following settings (1) to (6). (1) Cell group identifier (2) RLC bearer information (3) MAC layer configuration information for the cell group (4) Physical (PHY) layer configuration information for the cell group (5) SpCell configuration information (may include a synchronized reconfiguration information element) (6) SCell information

[0191] In addition, the radio bearer configuration may include some or all of the following configurations (1) to (3). (1)SRB settings (2) DRB settings (3) Security settings (e.g., information about the integrity protection algorithm and encryption algorithm for SRB and / or DRB (securityAlgorithmConfig), information about whether to use the master (MCG) or secondary (SCG) key (keyToUse), etc.)

[0192] In LTE, conditional handover configuration may include some or all of the following configurations (A) to (E): (A) Measurement settings (B) Mobility control information element (C) NAS layer messages (D) Radio resource settings (E) Security configuration (e.g., information about integrity protection algorithms and encryption algorithms for SRB and / or DRB (SecurityAlgorithmConfig))

[0193] The radio resource configuration may include some or all of the following configurations (1) to (4). (1)SRB information (2) DRB information (3) MAC layer configuration information for the cell group (4) Physical (PHY) layer configuration information for the cell group

[0194] In LTE and / or NR, the conditional handover conditions may include some or all of the following conditions (A) through (D): (A) The target cell is better than the current source PCell with the offset. (B) The target cell becomes better than a certain threshold, and the PCell becomes worse than another threshold. (C) The target cell becomes better than a certain threshold. (D) No condition (execute immediately)

[0195] For comparison in the conditional handover condition, RSRP, RSRQ, and / or RS-SINR may be used as a quantity. The quantity to be used may be set by the network. Information indicating the quantity to be used may be included in the conditional handover condition.

[0196] The information element indicating the conditional handover configuration and / or the conditional handover condition may be included as part of the RRC message at the handover source, or may be stored in a container (information element storing a bit string) included in the RRC message.

[0197] Based on the above description, various embodiments of the present invention will be described. Note that the processes described above may be applied to the processes omitted in the following description.

[0198] This paper presents an example of how to efficiently perform MBB-HO by modifying the procedures for radio link monitoring in MBB-HO.

[0199] First, in the primary cell (PCell) that is an SpCell of the MCG, under a specific condition (first condition), the RRC layer processing unit of the UE 122 may start or restart the timer (T310) when it receives an out-of-sync notification from the physical layer processing unit a predetermined number of times (N310 times) consecutively, regardless of whether the timer T304 is running. Furthermore, the RRC layer processing unit of the UE 122 may stop the timer (T310) when it receives an in-sync notification a predetermined number of times (N311 times) consecutively. Furthermore, when determining whether to start or restart the timer T310, a condition that none of the timers T300, T301, and T311 are running may be added.

[0200] The RRC layer processing unit of the UE 122 determines that a radio link failure has been detected in the MCG when any one of the following conditions (A) to (E) is satisfied. (A) When timer T310 expires (B) When timer T312 expires (C) When a random access problem indication is received from the MAC entity of the MCG while none of timers T300, T301, T304, and T311 is running. (D) Under the first condition, when a notification of a random access problem is received from the MAC entity of the MCG while timer T304 is running. (E) When a notification is received from the RLC layer of the MCG indicating that the retransmission of an SRB or DRB has reached the maximum number of retransmissions.

[0201] The first condition may be that makeBeforeBreak-r16 is configured in the UE 122. For example, in the case of EUTRA, the setting of makeBeforeBreak-r16 may mean that the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in a field of a mobilityControlInfo information element. Furthermore, for example, in the case of NR, the setting of makeBeforeBreak-r16 may mean that the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in a field of a synchronized reconfiguration information element. Furthermore, for example, in the case of EUTRA, the setting of makeBeforeBreak-r16 may mean that the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is not included in a field of a mobilityControlInfo information element. Furthermore, "makeBeforeBreak-r16 is not set" may mean, for example, in the case of EUTRA, that UE 122 receives an RRC connection reconfiguration message including makeBeforeBreak-r16 having a value of false. Furthermore, "makeBeforeBreak-r16 is not set" may mean, for example, in the case of NR, that UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is not included in the field of the synchronized reconfiguration information element.

[0202] Furthermore, the setting of makeBeforeBreak-r16 may mean, for example, in the case of EUTRA, that the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in a terminal device specific radio resource configuration (radioBearerConfigDedicated) information element. Furthermore, the setting of makeBeforeBreak-r16 may mean, for example, in the case of NR, that the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in a field of a data radio bearer configuration information element.

[0203] makeBeforeBreak-r16 may have, for example, an enumerated value including true, or may have as its value an information element including information necessary for make-before-break handover.

[0204] Moreover, the condition (E) may be the following (E2). (E2) When a notification is received from the RLC layer of the MCG indicating that the retransmission of an SRB or DRB has reached the maximum number of retransmissions while none of the timers T300, T301, T304, and T311 is running, or when a notification is received from the RLC layer of the MCG indicating that the retransmission of an SRB or DRB has reached the maximum number of retransmissions while the timer T304 is running under the first condition.

[0205] When the UE 122 determines that a radio link failure has been detected in the MCG, it stores various information as radio link failure information, and if security in the AS is not activated, it may set the release reason to "other" and begin the process of leaving RRC_CONNECTED.

[0206] Also, when AS security is activated, if the first condition is met, the transmission of some or all of the SRBs and / or DRBs of the MCG may be suspended and the MAC entity of the MCG may be reset.

[0207] Also, if AS security is activated, an RRC connection re-establishment procedure may be initiated if the first condition is not met.

[0208] The RRC connection re-establishment procedure may be initiated when any of the following conditions (A) to (E) is met: (A) When the first condition is not met, a radio link failure of the MCG is detected. (B) When handover fails (in NR, when synchronized reconfiguration in MCG fails) (C) When mobility to another RAT fails (D) When an integrity check failure related to SRB1 or SRB2 is notified from the lower layer. (E) When RRC connection re-establishment fails

[0209] Furthermore, when any of the above conditions is met, if the first condition is met and no radio link failure is detected in the MCG of the handover source, the RRC connection re-establishment procedure may not be initiated, and instead the MCG of the handover source may initiate a procedure to notify of the handover failure.

[0210] If the first condition is that makeBeforeBreak-r16 is set in UE122, the set makeBeforeBreak-r16 may be released when timer T304 expires or when the procedure for notifying the handover failure is started in the source MCG.

[0211] When the RRC connection re-establishment procedure is initiated, the UE 122 performs some or all of the following processes (A) to (J). (A) If timer T310 is running, stop timer T310. (B) If timer T312 is running, stop timer T312. (C) If timer T313 is running, stop timer T313. (C) If timer T314 is running, stop timer T314. (D) Start timer T311 (E) Suspend all RBs except SRB0 (F) Reset MAC (G) If an SCell of the MCG is set, release that SCell. (H) Apply the default physical channel settings (I) Apply the default MAC primary settings to the MCG (J) Performing the cell selection procedure

[0212] Next, a case is considered in which, after the UE 122 transmits an RRC connection reconfiguration complete message or an RRC reconfiguration complete message to the target cell during handover processing, data is transmitted and received via both the post-handover MCG (also referred to as Target MCG or Current MCG) and the handover source MCG (Source MCG) cell groups (when operating with a dual protocol stack). An example of processing in this case will be shown below. Note that the following processing is not limited to the case of a dual protocol stack, and can also be applied to other cases.

[0213] First, in a primary cell that is an SpCell of the Source MCG, the RRC layer processing unit of UE 122 may start or restart the timer (T310) of the Source MCG when it receives an out-of-sync notification from the physical layer processing unit of the Source MCG a predetermined number of times (N310 times) consecutively, regardless of whether the timer T304 of the Source MCG is running under a specific condition (first condition). The RRC layer processing unit of UE 122 may stop the timer (T310) when it receives an in-sync notification from the physical layer processing unit of the Source MCG a predetermined number of times (N311 times) consecutively. Furthermore, when determining whether to start or restart the timer T310, a condition that none of the timer T300 of the Source MCG, the timer T301 of the Source MCG, and the timer T311 of the Source MCG are running may be added.

[0214] The RRC layer processing unit of the UE 122 determines that a radio link failure has been detected in the Source MCG when any of the following conditions (A) to (E) is satisfied. (A) When timer T310 of the Source MCG expires (B) When timer T312 of the Source MCG expires (C) Upon receiving a random access problem indication from the MAC entity of the Source MCG when none of timers T300, T301, T304, and T311 of the Source MCG are running. (D) Under the first condition, when a random access problem notification is received from the MAC entity of the Source MCG while timer T304 of the Source MCG is running. (E) When a notification is received from the RLC layer of the Source MCG indicating that the retransmission of an SRB or DRB has reached the maximum number of retransmissions.

[0215] The first condition may be that makeBeforeBreak-r16 is set in the UE 122.

[0216] Alternatively, the first condition may be that either makeBeforeBreak-r14 or makeBeforeBreak-r16 is set in the UE 122.

[0217] Moreover, the condition (E) may be the following (E2). (E2) When a notification is received from the RLC layer of the Source MCG indicating that the retransmission of an SRB or DRB has reached the maximum number of retransmissions while none of timers T300, T301, T304, and T311 of the Source MCG is running, or when a notification is received from the RLC layer of the Source MCG indicating that the retransmission of an SRB or DRB has reached the maximum number of retransmissions while timer T304 is running under the first condition.

[0218] When UE 122 determines that a radio link failure has been detected in the Source MCG, it may suspend transmission of some or all of the SRBs and / or DRBs of the Source MCG and reset the MAC entity of the Source MCG.

[0219] When makeBeforeBreak-r16 is set in the Current MCG, UE 122 may consider that MCG to be the Source MCG.

[0220] Furthermore, the UE 122 may consider the source MCG of the handover source as the Source MCG when the first uplink grant is allocated by the PDCCH in the target cell of the handover.

[0221] Furthermore, when UE 122 transmits an RRC reconfiguration complete message, UE 122 may consider the handover source MCG to be the Source MCG.

[0222] In addition, when UE 122 receives a UE contention resolution identity MAC control element from the target gNB, UE 122 may consider the MCG of the handover source to be the source MCG.

[0223] Furthermore, if a Source MCG already exists when makeBeforeBreak-r16 is set in the Current MCG, UE 122 may release this MCG and consider the Current MCG as a new Source MCG.

[0224] In this way, by distinguishing between the process of detecting radio link failure of the Source MCG and the process of detecting radio link failure of the Current MCG, unnecessary re-establishment processes in MBB-HO can be prevented, and efficient mobility can be achieved.

[0225] An example of the operation of MBB-HO will be described. Here, an example is shown in which an RRC reconfiguration message including a CellGroupConfig containing a synchronization-attached reconfiguration information element is used in NR. Note that although there is a description of receiving information elements in the following description of each process, unless otherwise specified, this may mean that the information elements are included in the RRC reconfiguration message that triggered each process. Furthermore, unless otherwise specified, the information elements used in each process may be associated with the information elements used in Non-Patent Document 10.

[0226] The terminal device executes processing A based on the received CellGroupConfig information element. The terminal device also executes processing L based on the received masterKeyUpdate information element. The terminal device also executes processing I based on the received RadioBearerConfig information element.

[0227] Note that each item of each process described below is indented and given a symbol. For example, process A, process B, process C, and process H are interpreted as the flows shown in Figures 16, 17, 18, and 19, respectively, but other processes are also interpreted in the same way.

[0228] (Process A) Based on the received CellGroupConfig information element, the following process is performed. (A-0) If CellGroupConfig includes SpCell configuration information (spCellConfig information element) including synchronized reconfiguration information, and the synchronized reconfiguration information includes information indicating that this RRC reconfiguration is MBB-HO (e.g., MakeBeforeBreak-r16), (A-0-1) The current terminal device configuration (source configuration) is duplicated as the target configuration, and the subsequent processing may be performed on the duplicated target configuration unless otherwise specified. For example, in the case of MBB-HO, the "current terminal device configuration" in each processing may be considered to be the "target configuration of the current terminal device." Furthermore, for example, the duplicated configuration may include some or all of the following: (1) bearer-related configuration (e.g., SRB-related configuration, DRB-related configuration, etc.), (2) cell group configuration (e.g., SpCell configuration, SCell configuration, and each entity configuration), (3) variables held within the terminal device (measurement configuration (VarMeasConfig), measurement results (VarMeasReportList), timers, counters, etc.), and (4) security-related configuration (e.g., each key). Furthermore, the duplicated bearer configuration may not include the SRB-related configuration. In other words, for DRB, both the source configuration and the target configuration may be managed, and for SRB, the configuration may be switched from the source configuration to the target configuration without duplicating the configuration. Furthermore, information that enables determination of whether to duplicate the SRB configuration may be included in an RRC reconfiguration message including a synchronized reconfiguration. For example, the information may be included in MakeBeforeBreak-r16. (A-1) If CellGroupConfig contains SpCell configuration information (spCellConfig information element) including synchronized reconfiguration information (A-1-1) Execute process B, which will be described later. (A-1-2) If in a suspended state, resume all suspended radio bearers and resume transmission in the SCG for all radio bearers. (A-2) If CellGroupConfig contains a list of RLC bearers to be released (rlc-BearerToReleaseList information element) (A-2-1) Execute process C, which will be described later. (A-3) If the CellGroupConfig contains a list of RLC bearers to be added and / or modified (rlc-BearerToAddModList information element), (A-3-1) Execute process D, which will be described later. (A-4) If CellGroupConfig includes the MAC configuration of the cell group (mac-CellGroupConfig information element), (A-4-1) The MAC entity of this cell group is configured (Config) in process E, which will be described later. Note that in each embodiment of the present invention, "configuring" by the terminal device using an information element included in an RRC message may mean applying the information included in the information element to the configuration of the terminal device. (A-5) If CellGroupConfig contains a list of SCells to be released (sCellToReleaseList information element) (A-5-1) SCell release is performed in process F, which will be described later. (A-6) If CellGroupConfig contains SpCell configuration information (spCellConfig information element), (A-6-1) SpCell is set in process G, which will be described later. (A-7) If CellGroupConfig contains a list of SCells to add and / or modify (sCellToAddModList information element) (A-7-1) Addition and / or modification of SCell is performed in process H described below.

[0229] (Process B) (B-1) If the security of the AS is not activated, execute the process of transitioning to RRC_IDLE and end the process B. (B-2) If the timer T310 of the corresponding SpCell is running, stop the timer T310. (B-3) The timer T304 of the corresponding SpCell is started with the timer value t304 included in the synchronized reconfiguration. (B-4) If frequency information (frequencyInfoDL) is included, (B-4-1) The target SpCell is regarded as a cell with the SSB frequency indicated by frequencyInfoDL and the physical cell identifier indicated by the physical cell identifier information (physCellId) included in the synchronized reconfiguration. (B-5) Otherwise, (B-5-1) The target SpCell is regarded as a cell with a physical cell identifier indicated by the physical cell identifier information (physCellId) included in the synchronized reconfiguration on the SSB frequency of the source SpCell. (B-6) Start synchronization with the downlink of the target SpCell. (B-7) Apply the default BCCH settings. (B-8) If necessary, the master information block (MIB), which is one of the broadcast information, is acquired. (B-9) If the synchronized reconfiguration includes information indicating MBB-HO, (B-9-1) If there is no MAC entity in the target cell group, (B-9-1-1) A MAC entity for the target cell group (also simply referred to as a target MAC entity) is generated. (B-9-2) Apply the default MAC cell group configuration to the target MAC entity. (B-9-3) If an SCell of the target cell group is configured, the SCell is considered to be in a deactivated state. (B-9-4) The value of newUE-Identity is applied as the C-RNTI of the target cell group. (B-10) Otherwise, (B-10-1) Reset the MAC entity of this cell group. (B-10-2) If an SCell of this cell group is configured, it is considered to be in a deactivated state. (B-10-3) The value of newUE-Identity is applied as the C-RNTI of this cell group. (B-11) Configure the lower layer based on the SpCell configuration (spCellConfigCommon) included in the synchronized reconfiguration. (B-12) If necessary, configure the lower layers based on other information included in the synchronized reconfiguration.

[0230] (Process C) (C-1a) for each logical channel identifier (logicalChannelIdentity) value that is part of the current terminal device configuration and is included in the rlc-BearerToReleaseList, or (C-1b) For each logical channel identifier value that is released as a result of the release of the SCG: (C-1-1) Release the corresponding logical channel and the RLC entity associated with the logical channel.

[0231] (Process D) The following processing is performed for each RLC bearer configuration (RLC-BearerConfig) included in the received rlc-BearerToAddModList information element. (D-1) If the current terminal device configuration includes an RLC bearer with the received logical channel identifier, (D-1-1) If information indicating reestablishment of RLC (reestablishRLC) is received, (D-1-1-1) Re-establish the RLC entity (D-1-2) Reconfigure the RLC entity according to the received RLC configuration (rlc-Config). (D-1-3) The logical channel is reconfigured in accordance with the received MAC logical channel configuration (mac-LogicalChannelConfig). (D-2) Otherwise, (D-2-1) If the logical channel identifier and RLC setting for the SRB are not included, (D-2-1-1) Establish an RLC entity according to the default settings. (D-2-2) Otherwise, (D-2-2-1) Establish an RLC entity according to the received RLC configuration (rlc-Config). (D-2-3) If the logical channel identifier and MAC logical channel setting for the SRB are not included, (D-2-3-1) Configure the MAC entity corresponding to the logical channel according to the default settings. (D-2-4) Otherwise, (D-2-4-1) Configure the MAC entity corresponding to the logical channel according to the received MAC logical channel configuration. (D-2-5) Based on the radio bearer identifier information (servedRadioBearer) included in the RLC bearer configuration, this logical channel is associated with the PDCP entity.

[0232] (Process E) (E-1) If the target of reconfiguration by CellGroupConfig is an SCG and the SCG MAC is not part of the current terminal device configuration, (E-1-1) Create an SCG MAC entity. (E-2) Reconfigure the MAC main configuration of the cell group according to the MAC cell group configuration (mac-Cell) except for the configuration related to adding, modifying, and / or releasing a timing advance group (TAG). (E-3) If the received MAC cell group configuration includes information about TAG release (tag-ToReleaseList), (E-3-1) If the TAG identifiers included in the tag-ToReleaseList are part of the current terminal device configuration, for each TAG identifier, release the TAG indicated by the TAG identifier. (E-4) If the received MAC cell group configuration includes information about adding and / or modifying TAG (tag-ToAddModList), (E-4-1) If the identifiers of the TAGs included in tag-ToAddModList are not part of the current terminal device configuration, then for each TAG identifier: (E-4-1-1) Add a TAG corresponding to the TAG identifier according to the received timing advance timer. (E-4-2) If the identifiers of the TAGs included in tag-ToAddModList are part of the current terminal device configuration, then for each TAG identifier: (E-4-2-1) Reset the TAG corresponding to the TAG identifier according to the received timing advance timer.

[0233] (Process F) (F-1) If the release is triggered by receiving a SCell release list (sCellToReleaseList), (F-1-1) For each SCell index (sCellIndex) value included in sCellToReleaseList, (F-1-1-1) If the current terminal device configuration includes an SCell with a value of sCellIndex, (F-1-1-1-1) Release that SCell.

[0234] (Process G) (G-1) If the SpCell configuration includes information about timers and constants related to radio link failure (RLF) (rlf-TimersAndConstants), (G-1-1) Set the RLF timers and constants for this cell group according to rlf-TimersAndConstants. (G-2) Otherwise, if rlf-TimersAndConstants is not set for this cell group, (G-2-1) Set the RLF timer and constants for this cell group using the timer and constant values ​​received in the system information. (G-3) If the SpCell configuration includes a dedicated SpCell configuration (spCellConfigDedicated), (G-3-1) Configure SpCell according to spCellConfigDedicated. (G-3-2) If the BWP indicated by the first active uplink BWP (Bandwidth part) identifier (firstActiveUplinkBWP-Id) is set, that BWP is considered to be the active uplink BWP. (G-3-3) If the BWP indicated by the first active downlink BWP (Bandwidth part) identifier (firstActiveDownlinkBWP-Id) is configured, that BWP is considered to be the active downlink BWP. (G-3-4) If the reference signal used for radio link monitoring is reconfigured by the received individual SpCell configuration, (G-3-4-1) If the timer T310 corresponding to the SpCell is running, stop the timer T310. (G-3-4-2) Stop counters N310 and N311.

[0235] (Process H) (H-1) For each value of sCellIndex included in sCellToAddModList that is not part of the current terminal device configuration, (H-1-1) Add a SCell corresponding to sCellIndex. (H-1-2) Configure lower layers to regard the SCell as being in a deactivated state. (H-1-3) For each measurement identifier in the list of measurement identifiers (measIdList) of the variable (VarMeasConfig) that stores the measurement settings, (H-1-3-1a) If the SCell is not applicable to the measurement corresponding to the measurement identifier, and (H-1-3-1b) If this SCell is included in the list of triggered cells (cellsTriggeredList) defined in the variable (VarMeasReportList) that holds the measurement report for this measurement identifier, (H-1-3-1-1) Delete this SCell from the list of triggered cells (cellsTriggeredList) defined by the variable (VarMeasReportList) that holds the measurement report for this measurement identifier. (H-2) For each value of sCellIndex included in sCellToAddModList that is part of the current terminal device settings, (H-2-1) Change the setting of SCell corresponding to sCellIndex.

[0236] (Process I) (I-1) If RadioBearerConfig includes srb3-ToRelease, (I-1-1) Release the PDCP entity and SRB identifier of SRB3. (I-2) If RadioBearerConfig includes SRB-ToAddModList, (I-2-1) Add and / or reconfigure SRB. (I-3) If RadioBearerConfig includes drb-ToReleaseList, (I-3-1) The DRB is released in process J, which will be described later. (I-4) If RadioBearerConfig includes DRB-ToAddModList, (I-4-1) Add and / or reconfigure a DRB in process K, which will be described later. (I-5) Release all SDAP entities that are not associated with the DRB, and notify the upper layer of the release of user plane resources for the PDU sessions associated with the released SDAP entities.

[0237] In the above process I, in the case of MBB-HO, in the process of adding, reconfiguring, and / or releasing an SRB, two configurations, a source configuration and a target configuration, are managed, and instead of performing processes I-1 and I-2 for the target configuration, the current SRB configuration may be reconfigured by processes I-1 and I-2. In other words, a single SRB configuration may be managed. In this case, the source SRB configuration before reconfiguration may be separately stored in order to revert to the source configuration before reconfiguration in case of a handover failure, etc.

[0238] In the above-mentioned process I-5, in the case of MBB-HO, all SDAP entities not associated with either the source-configured DRB or the target-configured DRB may be released, and the release of user plane resources of the PDU sessions associated with the released SDAP entities may be notified to higher layers. For example, MBB-HO may be performed based on an RRC reconfiguration message including a synchronized reconfiguration, and the SDAP entities associated with either or both of the source DRB and the target DRB may not be released until a message for releasing the source configuration (e.g., an RRC message, a MAC CE, etc.) is received in the target cell. When the message for releasing the source configuration is received and the source DRB is released, all SDAP entities not associated with the (target) DRB may be released, and the release of user plane resources of the PDU sessions associated with the released SDAP entities may be notified to higher layers.

[0239] The above phrase "receiving a message to release the source configuration" may be rephrased as detecting a certain request. The certain request may be rephrased as certain information. Detecting a certain request may be that a received RRC message contains a specific information element (e.g., an information element instructing the release of the source configuration), that a received MAC control element contains specific information (e.g., information instructing the release of the source configuration), or that an initial uplink grant is received in the SpCell. Detecting a certain request may be that the random access procedure is successful. Detecting a certain request may be that the random access procedure is successful in either or both of the following cases: (A) when a synchronized reconfiguration is included in the SpCellConfig, or (B) when the random access procedure is triggered by the RRC entity submitting to a lower layer a message notifying completion of RRC reconfiguration (e.g., an RRC connection reconfiguration complete message in LTE or an RRC reconfiguration complete message in NR). Detecting a certain request may also be something detected by the implementation of the terminal device.

[0240] (Process J) (J-1a) for each DRB identifier included in the drb-ToReleaseList that is part of the current endpoint configuration, or (J-1b) For each DRB identifier that is released as a result of a full configuration, (J-1-1) Release the PDCP entity and the DRB identifier. (J-1-2) If an SDAP entity associated with this DRB is configured, (J-1-2-1) Indicate the release of the DRB to the SDAP associated with this DRB. (J-1-3) If the DRB is associated with the EPS bearer identifier, (J-1-3-1) If a new bearer with the same EPS bearer identifier is not added in either NR or E-UTRA, (J-1-3-1-1) Notify the upper layer of the release of the DRB and the EPS bearer identifier of the released DRB.

[0241] In the process J-1-3-1, in the case of MBB-HO, if a new bearer is not added to the same EPS bearer in either the source or target configuration, the release of the DRB and the EPS bearer identifier of the released DRB may be notified to higher layers. For example, when MBB-HO is performed based on an RRC reconfiguration message including a synchronized reconfiguration, and a message (e.g., an RRC message, MAC CE, etc.) for releasing the source configuration is received in the target cell, if the same EPS bearer is associated with the bearer in either the source or target configuration, the release of the DRB and the EPS bearer identifier of the released DRB may not be notified to higher layers. When the message for releasing the source configuration is received and the source DRB is released, if a new bearer with the same EPS bearer identifier is not added in either NR or E-UTRA, the release of the DRB and the EPS bearer identifier of the released DRB may be notified to higher layers.

[0242] (Process K) (K-1) For each DRB identifier included in the DRB-ToAddModList that is not part of the current terminal device configuration, (K-1-1) Establish a PDCP entity and configure the PDCP entity according to the received PDCP configuration (pdcp-Config). (K-1-2) If the PDCP entity of this DRB is not configured with ciphering disabled, (K-1-2-1a) If the target RAT of the handover is E-UTRA / 5GC, or (K-1-2-1b) If the terminal equipment connects only to E-UTRA / 5GC, (K-1-2-1-1) Configure a PDCP entity using the encryption algorithm and key configuration in Non-Patent Document 4. (K-1-2-2) Otherwise, (K-1-2-2-1) Configure the PDCP entity with the encryption algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameters (keyToUse) associated with the master key (KeNB or KgNB) or secondary key (S-KgNB). (K-1-3) If the PDCP entity of this DRB is configured to perform integrity protection, (K-1-3-1) Configure the PDCP entity with the integrity protection algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameters (keyToUse) associated with the master key (KeNB or KgNB) or the secondary key (S-KgNB). (K-1-4) If SDAP configuration (sdap-Config) is included, (K-1-4-1) If the SDAP for the received PDU session does not exist, (K-1-4-1-1) Establish an SDAP entity. (K-1-4-1-2) If the SDAP for the received PDU session did not exist prior to receiving this reconfiguration, (K-1-4-1-2-1) Notify upper layers of the establishment of user plane resources for the PDU session. (K-1-4-2) Configure the SDAP entity according to the received SDAP configuration, and associate the DRB with the SDAP entity. (K-1-5) If the DRB is associated with an EPS bearer identifier, (K-1-5-1) If the DRB was previously configured by NR or E-UTRA with the same EPS bearer identifier prior to receiving this reconfiguration, (K-1-5-1-1) Link the established DRB with the corresponding EPS bearer identifier. (K-1-5-2) Otherwise, (K-1-5-2-1) Notify the upper layer of the establishment of the DRB and the EPS bearer identifier of the established DRB. (K-2) For each DRB identifier included in the DRB-ToAddModList that is part of the current terminal device configuration, (K-2-1) If the parameter reestablishPDCP is set (K-2-1-1a) If the target RAT of the handover is E-UTRA / 5GC, or (K-2-1-1b) If the terminal equipment connects only to E-UTRA / 5GC, (K-2-1-1-1) If the PDCP entity of this DRB is not configured with ciphering disabled, (K-2-1-1-1-1) Configure a PDCP entity using the encryption algorithm and key configuration in Non-Patent Document 4. (K-2-1-2) Otherwise, (K-2-1-2-1) If the PDCP entity of this DRB is not configured with ciphering disabled, (K-2-1-2-1-1) Configure the PDCP entity with the encryption algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameters (keyToUse) associated with the master key (KeNB or KgNB) or secondary key (S-KgNB). (K-2-1-2-2) If the PDCP entity of this DRB is configured to perform integrity protection, (K-2-1-2-2-1) Configure the PDCP entity with the integrity protection algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameters (keyToUse) associated with the master key (KeNB or KgNB) or secondary key (S-KgNB). (K-2-1-3) If drb-ContinueROHC is included in pdcp-Config, (K-2-1-3-1) Notify the lower layer that drb-ContinueROHC is set. (K-2-1-4) Re-establish the PDCP entity for this DRB. (K-2-2) Otherwise, if recoverPDCP is set, (K-2-2-1) Trigger the execution of data recovery for the PDCP entity of this DRB. (K-2-3) If PDCP settings are included, (K-2-3-1) Reconfigure the PDCP entity according to the received PDCP configuration. (K-2-4) If SDAP settings are included, (K-2-4-1) Reconfigure the SDAP entity according to the received SDAP configuration. (K-2-4-2) For each QFI added by mappedQoS-FlowsToAdd, if a QFI value was set, the QFI value is released from the old DRB.

[0243] The procedure K-1-4-1-2 may be such that, in the case of MBB-HO, if the SDAP of the received PDU session did not exist in either the source configuration or the target configuration prior to receiving this reconfiguration, the higher layers are notified of the establishment of user plane resources for this PDU session. Alternatively, the procedure K-1-4-1-2 may be such that, in the case of MBB-HO, if the SDAP of the received PDU session did not exist in the source configuration prior to receiving this reconfiguration, the higher layers are notified of the establishment of user plane resources for this PDU session.

[0244] In the process K-1-5-2, in the case of MBB-HO, if a DRB was not configured with the same EPS bearer identifier by NR or E-UTRA in either the source or target configuration prior to receiving this reconfiguration, the establishment of the DRB and the EPS bearer identifier of the established DRB may be notified to higher layers. Alternatively, in the case of MBB-HO, if a DRB was not configured with the same EPS bearer identifier by NR or E-UTRA in the source configuration prior to receiving this reconfiguration, the establishment of the DRB and the EPS bearer identifier of the established DRB may be notified to higher layers.

[0245] (Process L) (L-1) If the terminal equipment is connected to E-UTRA / EPC, (L-1-1) If sk-Counter is received, (L-1-1-1) Update the S-KgNB key based on the KgNB key and the received sk-Counter. (L-1-1-2) Derive the KRRCenc key and the KUPenc key. The KRRCenc key is a key used to protect the RRC signals generated by the KgNB using an encryption algorithm. The KUPenc key is a key used to protect the user plane traffic (user data) generated by the KgNB using an encryption algorithm. (L-1-1-3) Generate the KRRCint key and the KUPint key from the KgNB key. The KRRCint key is used to protect the RRC signals generated by the KgNB using the integrity algorithm. The KUPint key is used to protect the user plane traffic (user data) generated by the KgNB using the integrity algorithm. (L-2) Otherwise, (L-1-2) If the received masterKeyUpdate contains a nas-Container, (L-1-2-1) Forward the nas-Container to the upper layer. (L-1-3) If keySetChangeIndicator is "true", (L-1-3-1) Generate or update KgNB based on KAMF. (L-1-4) Otherwise, (L-1-4-1) Generate or update a KgNB key based on the current KgNB key or NextHop (NH). (L-1-5) Store the value of nextHopChainingCount. (L-1-6) Generate a key related to the KgNB key as follows: (L-1-6-1) If SecurityConfig contains securityAlgorithmConfig, (L-1-6-1-1) Generate the KRRCenc key and KUPenc key associated with the cipheringAlgorithm included in the securityAlgorithmConfig from the KgNB key. (L-1-6-1-2) Generate the KRRCint key and KUPint key associated with the integrityProtAlgorithm included in the securityAlgorithmConfig from the KgNB key. (L-1-6-2) Otherwise, (L-1-6-2-1) Generate the KRRCenc key and KUPenc key associated with the current cipheringAlgorithm from the KgNB key. (L-1-6-2-2) Generate the KRRCint key and KUPint key associated with the current integrityProtAlgorithm from the KgNB key.

[0246] An example of the operation of MBB-HO will be described. Here, an example will be shown in which an RRC connection reconfiguration message including a mobility control information (mobilityControlInfo) information element is used in LTE. Note that although there is a description that an information element is received in the description of each process below, unless otherwise specified, this may mean that the information element is included in the RRC connection reconfiguration message that triggered each process. Furthermore, unless otherwise specified, the information elements used in each process may be associated with the information elements used in Non-Patent Document 4.

[0247] The terminal device receives the RRC connection reconfiguration message including mobilityControlInfo, and if the terminal device can comply with the settings included in this message, performs the following process LA.

[0248] (Processing LA) (LA-1) Start timer T304 using the timer value of t304 included in mobilityControlInfo. (LA-2) If carrierFreq is included, (LA-2-1) A cell on the frequency indicated by carrierFreq whose physical cell identifier is indicated by targetPhysCellId is regarded as the target PCell. (LA-3) Otherwise, (LA-3-1) A cell whose physical cell identifier on the frequency of the source PCell is indicated by targetPhysCellId is regarded as the target PCell. (LA-4) Start synchronization to the target PCell downlink. (LA-5) If makeBeforeBreak is set, (LA-5-1) After the terminal device stops uplink transmission and / or downlink reception with the source cell, it performs the remaining processing of this procedure, including resetting the MAC. (LA-6) If makeBeforeBreak-r16 is set, (LA-6-1) The current terminal device configuration (source configuration) may be duplicated as the target configuration, and subsequent reconfiguration processes may be performed on the duplicated target configuration unless otherwise specified. For example, in the case of MBB-HO, the "current terminal device configuration" in each process may be considered to be the "target configuration of the current terminal device." Furthermore, for example, the duplicated configuration may include some or all of the following: (1) bearer configuration (e.g., SRB configuration, DRB configuration, etc.), (2) cell group configuration (e.g., SpCell configuration, SCell configuration, RLC entity configuration, MAC entity configuration, PHY configuration, etc.), (3) internal variables (measurement configuration (VarMeasConfig), measurement results (VarMeasReportList), timers, counters, etc.), and (4) security-related configuration (e.g., each key). Furthermore, the duplicated bearer configuration may not include the SRB configuration. In other words, for DRB, both the source configuration and the target configuration may be managed, and for SRB, the configuration may be switched from the source configuration to the target configuration without duplicating the configuration. Furthermore, information that enables determination of whether to duplicate the SRB configuration may be included in an RRC connection reconfiguration message that includes mobilityControlInfo. For example, the information may be included in MakeBeforeBreak-r16. (LA-7) If configured, reset MCG MAC and SCG MAC. If MakeBeforeBreak-r16 is configured, you may not reset the source MCG MAC and SCG MAC. Alternatively, if MakeBeforeBreak-r16 is configured, you may not reset the source MAC here, but reset the target MAC. (LA-8) PDCP configuration is configured and PDCP is re-established for all established radio bearers. If MakeBeforeBreak-r16 is configured, PDCP re-establishment applies only to the target PDCP. Alternatively, in the case of Single PDCP (described later), if MakeBeforeBreak-r16 is configured and a PDCP associated with the target radio bearer already exists, PDCP establishment and / or re-establishment may not be performed. In other words, if MakeBeforeBreak-r16 is configured and a PDCP associated with the target radio bearer does not exist, PDCP may be established and / or re-established. (LA-9) For all established radio bearers, if an MCG RLC and / or an SCG RLC is configured, re-establish the MCG RLC and / or the SCG RLC. (LA-10) The value of newUE-Identity is applied as C-RNTI. (LA-11) Configure the lower layers according to the received cell-common radio resource configuration (radioResourceConfigCommon). (LA-12) Configure the lower layers according to other information included in the received mobilityControlInfo. (LA-13) If the received RRC connection reconfiguration message contains sCellToReleaseList, (LA-13-1) Release the SCell. (LA-14) If the received RRC connection reconfiguration message contains sCellGroupToReleaseList, (LA-14-1) Release of the SCell group is executed. (LA-15a) If the received RRC connection reconfiguration message contains scg-Configuration, (LA-15b) If the current terminal device configuration includes one or more split DRBs and the received RRC connection reconfiguration message includes DRB-ToAddModList, (LA-15-1) Reconfigure the SCG. (LA-16) If the received RRC connection reconfiguration message includes a terminal device specific radio resource configuration (radioResourceConfigDedicated), (LA-16-1) Radio resource configuration is performed in process LB, which will be described later. (LA-17) If the RRC connection reconfiguration message contains security configuration (securityConfigHO-v1530), (LA-17-1) If a nas-Container is received, (LA-17-1-1) Transfer the nas-Container to the upper layer. (LA-17-2) If keyChangeIndicator-r15 is received and keyChangeIndicator-r15 is "true", (LA-17-2-1) Update the KeNB key based on the KAMF key. (LA-17-3) Otherwise, (LA-17-3-1) Update the KeNB key based on the current KeNB or NextHop (NH). (LA-17-4) Store the value of nextHopChainingCount-r15. (LA-17-5) If securityAlgorithmConfig-r15 is received, (LA-17-5-1) Generate a KRRCint key associated with the received integrityProtAlgorithm. (LA-17-5-2) Generate the KRRCenc key and KUPenc key associated with the received ciphering algorithm. The KRRCenc key is used to protect the RRC signal generated from the KeNB key using the encryption algorithm. The KUPenc key is used to protect the user plane traffic (user data) generated from the KeNB key using the encryption algorithm. (LA-17-6) Otherwise, (LA-17-6-1) Generate the KRRCint key associated with the current integrityProtAlgorithm from the KeNB key. (LA-17-6-2) Generate the KRRCenc key and KUPenc key associated with the current cipheringAlgorithm from the KeNB key. (LA-18) If the received RRC connection reconfiguration message contains sCellToAddModList, (LA-18-1) Adding and / or modifying SCells. (LA-19) If the received RRC connection reconfiguration message contains sCellGroupToAddModList, (LA-19-1) Adding and / or modifying SCell groups. (LA-20) If the received RRC connection reconfiguration message contains measConfig, (LA-20-1) Perform measurement settings. (LA-21) Perform automatic deletion of measurement identifiers. (LA-22) Submits an RRC connection reconfiguration complete message to lower layers for transmission. (LA-23) If the MAC succeeds in the random access procedure, (LA-23-1) Timer T304 is stopped and this procedure is terminated.

[0249] (Processing LB) (LB-1) If the received radioResourceConfigDedicated contains SRB-ToAddModList, (LB-1-1) Add and / or reconfigure an SRB in the processing LC described below. (LB-2) If the received radioResourceConfigDedicated contains drb-ToReleaseList, (LB-2-1) DRB release is performed using the processing LD described below. (LB-3) If the received radioResourceConfigDedicated contains DRB-ToAddModList, (LB-3-1) In process LE described later, DRB is added and / or reconfigured. (LB-4) If the received radioResourceConfigDedicated contains mac-MainConfig, (LB-4-1) In process LF, which will be described later, the MAC is set as the primary setting.

[0250] (Processing LC) (LC-1) For each SRB identifier included in the SRB-ToAddModList that is not part of the current terminal device configuration, (LC-1-1) Establish a PDCP entity with the current security configuration. (LC-1-2) If rlc-BearerConfigSecondary with value "setup" is received, (LC-1-2-1) Establish a secondary MCG RLC entity according to the received rlc-BearerConfigSecondary and associate it with the DCCH logical channel. (LC-1-2-2) Configure the PDCP entity of E-UTRA to activate duplication. (LC-2) For each SRB identifier contained in the SRB-ToAddModList that is part of the current terminal device configuration: (LC-2-1) If pdcp-verChange is included (i.e., if changing from NR PDCP to E-UTRA PDCP), (LC-2-1-1) Establish a PDCP entity for E-UTRA with the current security configuration. (LC-2-1-2) Associate the primary RLC of this SRB with the established PDCP entity. (LC-2-1-3) Release the NR PDCP for this SRB. (LC-2-2) Reconfigure the primary RLC entity according to the received rlc-Config. (LC-2-3) Reconfigure the primary DCCH logical channel according to the received logical channel configuration (logicalChannelConfig). (LC-2-4) If rlc-BearerConfigSecondary with value "Release" is included, (LC-2-4-1) Release the secondary MCG RLC entity and the DCCH logical channel associated with it. (LC-2-5) If an rlc-BearerConfigSecondary with the value "setup" is received, (LC-2-5-1) If the current SRB configuration does not include a secondary RLC bearer, (LC-2-5-1-1) Establish a secondary MCG RLC entity according to the received rlc-BearerConfigSecondary and associate it with the DCCH logical channel. (LC-2-5-1-2) Configure the PDCP entity of E-UTRA to activate duplication. (LC-2-5-2) Otherwise, (LC-2-5-2-1) Reconfigure the secondary MCG RLC entity according to the received rlc-BearerConfigSecondary and associate it with the DCCH logical channel.

[0251] (Processing LD) (LD-1a) for each DRB identifier included in the drb-ToReleaseList that is part of the current endpoint configuration, or (LD-2b) For each DRB identifier value that is freed as a result of a full configuration, (LD-2-1) If this DRB release is the result of a full configuration, (LD-2-1-1) Release the E-UTRA or NR PDCP entity. (LD-2-2) Otherwise, if the DRB is configured with PDCP enabled, (LD-2-2-1) Release the PDCP entity of E-UTRA. (LD-2-3) Otherwise, (LD-2-3-1) Re-establish the RLC entity for this DRB. (LD-2-4) Release the RLC entity. (LD-2-5) Release the DTCH logical channel. (LD-2-6) If the terminal device is connected to the EPC, (LD-2-6-1) If a DRB is configured with PDCP configuration and a new DRB is not added with the same EPS bearer identifier by either DRB-ToAddModList, nr-radioBearerConfig1, or nr-radioBearerConfig2, (LD-2-6-1-1) If this procedure is triggered by a handover, (LD-2-6-1-1-1) After the handover is successful, notify the upper layer of the release of the DRB and the EPS bearer identifier of the released DRB. (LD-2-6-1-2) Otherwise, (LD-2-6-1-2-1) Immediately notify the upper layer of the release of the DRB and the EPS bearer identifier of the released DRB.

[0252] (Processing LE) (LE-1) For each DRB identifier included in the DRB-ToAddModList that is not part of the current terminal device configuration, (LE-1-1) If DRB-ToAddModListSCG is not received or DRB-ToAddModListSCG does not contain a DRB Identifier value, (LE-1-1-1) If pdcp-Config is included, establish a PDCP entity according to pdcp-Config and configure it with the security configuration of the current MCG. (LE-1-1-2) If rlc-Config is included, establish MCG RLC according to rlc-Config. (LE-1-1-3) If the logical channel identifier (logicalChannelIdentity) and logical channel configuration (logicalChannelConfig) are included, establish the MCG DTCH logical channel according to the logicalChannelIdentity and logicalChannelConfig. (LE-1-1-4) If rlc-BearerConfigSecondary with value "setup" is included, (LE-1-1-4-1) Establish a secondary MCG RLC entity according to rlc-BearerConfigSecondary and associate it with the DTCH logical channel, and associate the established RLC entity with the E-UTRA PDCP with the same DRB identifier value as in the current UE configuration. (LE-1-2) If the DRBs are configured with the same EPS bearer identifier, (LE-1-2-1) Associate the established DRB with its EPS bearer identifier. (LE-1-3) Otherwise, if the entry in DRB-ToAddModList contains pdcp-config (i.e., if the bearer is established with PDCP in E-UTRA), (LE-1-3-1) Notify upper layers of the establishment of a DRB and the EPS bearer identifier of the established DRB. (LE-2) For each DRB identifier contained in the DRB-ToAddModList that is part of the current terminal device configuration, (LE-2-1) Reconfigure each layer and / or bearer according to the included configuration.

[0253] (Processing LF) (LF-1) Reconfigure the MAC main configuration according to the MA main configuration information element (mac-MainConfig), except for configuration related to adding, modifying, and / or releasing Secondary Timing Advance Groups (STAGs). (LF-2) If the received mac-MainConfig contains information about the release of STAGs (stag-ToReleaseList), (LF-2-1) If the STAG identifiers included in the stag-ToReleaseList are part of the current terminal device configuration, for each STAG identifier, release the STAG indicated by the STAG identifier. (LF-3) If the received mac-MainConfig contains information about adding and / or modifying STAGs (stag-ToAddModList), (LF-3-1) If the identifiers of the STAGs included in the stag-ToAddModList are not part of the current terminal device configuration, then for each STAG identifier: (LF-3-1-1) Add a STAG corresponding to the STAG identifier according to the received timeAlignmentTimerSTAG. (LF-3-2) If the identifiers of the STAGs included in stag-ToAddModList are part of the current terminal device configuration, then for each STAG identifier: (LF-3-2-1) Reconfigure the STAG corresponding to the STAG identifier according to the received timeAlignmentTimerSTAG.

[0254] Another example of the operation of MBB-HO will be described. Here, an example will be shown in which an RRC reconfiguration message including a conditional handover configuration is used in NR.

[0255] For example, a conditional handover information element may be included in an RRC message transmitted by a base station device. The conditional handover information element may include a list including one or more information elements (conditional handover configurations) including information included in the synchronized reconfiguration information element. Furthermore, the conditional handover information element may include an information element (conditional handover condition) indicating a condition for applying the conditional handover configuration to each, some, or all of the conditional handover configurations.

[0256] The conditional handover configuration may include some or all of the information included in RadioBearerConfig and CellGroupConfig. The conditional handover configuration may also include information indicating MBB-HO. The conditional handover condition may also include threshold information for determining whether the condition is met using a reference signal. The conditional handover condition may also include information instructing immediate application of the conditional handover configuration. For example, if the conditional handover condition indicates information instructing immediate application of the conditional handover configuration and the conditional handover configuration includes information indicating MBB-HO, MBB-HO can be realized by executing the above-described processes A and I based on the information included in the conditional handover configuration. Of course, even if the conditional handover condition is another condition, conditional MBB-HO can be realized by executing the above-described processes A and I based on the information included in the conditional handover configuration if the condition is met.

[0257] In the NR MBB-HO, the terminal device may have a PDCP (Single PDCP) configuration that is common to the source and target.

[0258] For example, when the core network is 5GC, in the source configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB, the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. Similarly, in the target configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB (or SRB), the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. In this case, for example, the logical channel, the DRB (or SRB), and / or the RLC bearer linked to the same DRB identifier (or SRB identifier) ​​in the source configuration and the target configuration may be linked to one PDCP. Also, for example, the logical channel, the DRB (or SRB), and / or the RLC bearer linked to the same PDU session in the source configuration and the target configuration may be linked to one PDCP.

[0259] For example, when the core network is 5GC, in the source configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB, the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. Similarly, in the target configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB (or SRB), the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. In this case, for example, the logical channel, the DRB (or SRB), and / or the RLC bearer linked to the same DRB identifier (or SRB identifier) ​​in the source configuration and the target configuration may be linked to one SDAP.

[0260] Also, for example, when the core network is EPC, in the source configuration, a DRB (or SRB), a PDCP entity, a logical channel, an RLC entity (and / or an RLC bearer), and an EPS bearer are linked. Similarly, in the target configuration, a DRB (or SRB), a PDCP entity, a logical channel, an RLC entity (and / or an RLC bearer), and an EPS bearer are linked. In this case, for example, logical channels and RLC entities (and / or RLC bearers) linked to the same DRB identifier (or SRB identifier) ​​in the source configuration and the target configuration may be linked to one PDCP entity. Also, for example, logical channels, RLC entities (and / or RLC bearers), and DRBs (or SRBs) linked to the same EPS bearer identifier in the source configuration and the target configuration may be linked to one PDCP entity.

[0261] In the above case, the terminal device may consider the source and target PDCP settings associated with one PDCP to be identical, or may apply the target PDCP settings to the source PDCP settings.

[0262] Also, when a source DRB (or SRB) and a target DRB with the same DRB identifier are associated with one PDCP entity, the source and target security keys (e.g., KUPenc, KUPint, KRRCenc, and / or KRRCint, etc.) are different, and therefore multiple security keys are managed in one PDCP entity.

[0263] Another example of the operation of MBB-HO will be described below, in which an example is shown in which an RRC connection reconfiguration message including a conditional handover configuration is used in LTE.

[0264] For example, a conditional handover information element may be included in an RRC message transmitted by a base station device. The conditional handover information element may include a list including one or more information elements (conditional handover configurations) including information included in the mobilityControlInfo information element. Furthermore, the conditional handover information element may include an information element (conditional handover condition) indicating a condition for applying the conditional handover configuration to each, some, or all of the conditional handover configurations.

[0265] The conditional handover configuration may include some or all of the information included in the cell-common radio resource configuration (radioBearerConfigCommon) and the terminal device-specific radio resource configuration (radioBearerConfigDedicated). The conditional handover configuration may also include information indicating MBB-HO (e.g., MakeBeforeBreak-r16). The conditional handover condition may also include threshold information for determining whether the condition is met using a reference signal. The conditional handover condition may also include information instructing immediate application of the conditional handover configuration. For example, if the conditional handover condition indicates information instructing immediate application of the conditional handover configuration and the conditional handover configuration includes information indicating MBB-HO, MBB-HO can be realized by executing the process LA based on the information included in the conditional handover configuration. Of course, even if the conditional handover condition is another condition, conditional MBB-HO can be realized by executing the process LA based on the information included in the conditional handover configuration if the condition is met.

[0266] In the LTE MBB-HO (MakeBeforeBreak-r16), the terminal device may have a PDCP (Single PDCP) configuration that is common to the source and target.

[0267] For example, when the core network is 5GC, in the source configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB, the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. Similarly, in the target configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB (or SRB), the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. In this case, for example, the logical channel, the DRB (or SRB), and / or the RLC bearer linked to the same DRB identifier (or SRB identifier) ​​in the source configuration and the target configuration may be linked to one PDCP. Also, for example, the logical channel, the DRB (or SRB), and / or the RLC bearer linked to the same PDU session in the source configuration and the target configuration may be linked to one PDCP.

[0268] For example, when the core network is 5GC, in the source configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB, the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. Similarly, in the target configuration, the logical channel, the DRB (or SRB), and the RLC bearer are linked by the RLC bearer configuration, and the DRB (or SRB), the PDCP entity, and the PDU session are further linked by the drb-ToAddMod. In this case, for example, the logical channel, the DRB (or SRB), and / or the RLC bearer linked to the same DRB identifier (or SRB identifier) ​​in the source configuration and the target configuration may be linked to one SDAP.

[0269] Also, for example, when the core network is EPC, in the source configuration, a DRB (or SRB), a PDCP entity, a logical channel, an RLC entity (and / or an RLC bearer), and an EPS bearer are linked. Similarly, in the target configuration, a DRB (or SRB), a PDCP entity, a logical channel, an RLC entity (and / or an RLC bearer), and an EPS bearer are linked. In this case, for example, logical channels and RLC entities (and / or RLC bearers) linked to the same DRB identifier (or SRB identifier) ​​in the source configuration and the target configuration may be linked to one PDCP entity. Also, for example, logical channels, RLC entities (and / or RLC bearers), and DRBs (or SRBs) linked to the same EPS bearer identifier in the source configuration and the target configuration may be linked to one PDCP entity.

[0270] In the above case, the terminal device may consider the source and target PDCP settings associated with one PDCP to be identical, or may apply the target PDCP settings to the source PDCP settings.

[0271] In addition, when a source DRB and a target DRB (or SRB) with the same DRB identifier are linked to one PDCP entity, the source and target security keys (e.g., KUPenc) are different, so multiple security keys are managed in one PDCP entity.

[0272] Note that MakeBeforeBreak-r16 may include information indicating which layer of the target is to be generated or not generated until the connection to the target is completed.

[0273] In the case of NR, the above-mentioned (processing E) may include the following processes (E2-1) and after. For example, as shown in FIG. 22, processing (E2-1) may be executed between processing (E-1) and processing (E-2), but this is not limited thereto. In the case of LTE, the above-mentioned (processing LF) may include the following processes (E2-1) and after. For example, processing (E2-1) may be executed before processing (LF-1), but this is not limited thereto. (E2-1) If MBB-HO and no MAC entity for the target (also called secondary MAC entity) exists as part of the current terminal device configuration, (E2-1-1) Create a secondary MAC entity.

[0274] This allows the MAC entity to be generated appropriately in processing based on the settings of the MAC layer.

[0275] In the case of NR, the process within the scope of process (B-9) of the (process B) may be, for example, process (B2-9) as shown in Fig. 23. In the case of MBB-HO, the setting for "this cell group" in process (B-9) and subsequent processes in process (B) may be applied to the target. (B2-9) If the synchronized reconfiguration includes information indicating MBB-HO, (B2-9-1) If a MAC entity (also called a secondary MAC entity) for the target does not exist as part of the current terminal device configuration, (B2-9-1-1) The existing MAC entity (also called the primary MAC entity) of this cell group is not reset. (B2-9-1-2) Generate a secondary MAC entity. (B2-9-2) A default MAC cell group configuration is applied to the secondary MAC entity, or the same configuration as the primary MAC entity may be applied to the secondary MAC entity. (B2-9-3) Reset the secondary MAC entity. (B2-9-4) If an SCell of this cell group is configured, the SCell is considered to be in a deactivated state. (B2-9-5) The value of newUE-Identity is applied as the C-RNTI of this cell group.

[0276] In the case of LTE, the processes within the scope of process (LA-6) to process (LA-7) in the (process LA) may be, for example, process (LA2-6) and process (LA2-7) as shown in FIG. (LA2-6) If makeBeforeBreak-r16 is set, (LA2-6-1) The current terminal device configuration (source configuration) may be duplicated as the target configuration, and subsequent reconfiguration processes may be performed on the duplicated target configuration unless otherwise specified. For example, in the case of MBB-HO, the "current terminal device configuration" in each process may be considered to be the "target configuration of the current terminal device." Furthermore, for example, the duplicated configuration may include some or all of the following: (1) bearer configuration (e.g., SRB configuration, DRB configuration, etc.), (2) cell group configuration (e.g., SpCell configuration, SCell configuration, RLC entity configuration, MAC entity configuration, PHY configuration, etc.), (3) internal variables (measurement configuration (VarMeasConfig), measurement results (VarMeasReportList), timers, counters, etc.), and (4) security-related configuration (e.g., each key). Furthermore, the duplicated bearer configuration may not include the SRB configuration. In other words, for DRB, both the source configuration and the target configuration may be managed, and for SRB, the configuration may be switched from the source configuration to the target configuration without duplicating the configuration. Furthermore, information that enables determining whether to duplicate the SRB configuration may be included in an RRC connection reconfiguration message including mobilityControlInfo. For example, the information may be included in MakeBeforeBreak-r16. Furthermore, the duplication may involve the creation of entities of each layer (e.g., an RLC entity, a MAC entity). (LA2-6-2) If a MAC entity (also called a secondary MAC entity) for the target does not exist as part of the current terminal device configuration, (LA2-6-2-1) The existing MAC entity (also called the primary MAC entity) of this cell group is not reset. (LA2-6-2-2) Generate a secondary MAC entity. (LA2-6-3) Reset the secondary MAC entity if necessary. (LA2-7) Otherwise (LA2-7-1) If set, reset the MCG MAC and SCG MAC.

[0277] This allows appropriate MAC entity generation even when the NR RRC reconfiguration message does not include a MAC cell group configuration. Also, when the EUTRA RRC connection reconfiguration message does not include a MAC primary configuration, the MAC entity can be generated appropriately.

[0278] Furthermore, in the above (Process I), (Process J), or other processes, when the terminal device receives a message to release the source configuration, it may release the current primary MAC entity and consider the current secondary MAC entity as the primary MAC entity. Furthermore, when the terminal device receives a message to release the source configuration, it may reset the current primary MAC entity, not consider the current primary MAC entity as the primary MAC entity, and consider the current secondary MAC entity as the primary MAC entity.

[0279] This allows for proper management of MAC entities.

[0280] In each of the above processes, if makeBeforeBreak-r16 is included in the settings of the master cell group, a handover (also referred to as MBB-HO) may be performed, and if makeBeforeBreak-r16 is included in the settings of the secondary cell group, a change of the secondary cell group (also referred to as MBB-SCG Change) may be performed.

[0281] Furthermore, the terminal device may notify the base station device of some or all of the following information: (1) information indicating whether or not the terminal device supports execution of either MBB-HO or MBB-SCG Change while maintaining communication using two or more cell groups (e.g., Dual Connectivity or Multi Connectivity); (2) information indicating whether or not the terminal device supports execution of MBB-HO while maintaining communication using two or more cell groups (e.g., Dual Connectivity); (3) information indicating whether or not the terminal device supports execution of MBB-SCG Change while maintaining communication using two or more cell groups (e.g., Dual Connectivity); and (4) information indicating whether or not the terminal device supports execution of both MBB-HO and MBB-SCG Change while maintaining Dual Connectivity. For example, the information may be included in a message (e.g., UECapabilityInformation) that notifies the base station device 3 of the radio access capability of the terminal device. The information may also be notified as information independent of the band combinations supported by the terminal device. The information may also be notified as information for each band combination supported by the terminal device. The information may not be notified to the base station device.

[0282] Furthermore, the terminal device may release one or more cell groups other than the MCG and perform MBB-HO. The terminal device may perform the MBB-HO when it does not support the execution of MBB-HO while maintaining communication using two or more cell groups. The terminal device may release one or more cell groups other than the MCG and perform MBB-SCG Change. The terminal device may perform the MBB-SCG Change when it does not support the execution of MBB-SCG Change while maintaining communication using two or more cell groups. The terminal device may also perform a normal secondary cell group change (SCG Change) other than the MBB-SCG Change. The terminal device may perform the secondary cell group change when it does not support the execution of MBB-SCG Change while maintaining communication using two or more cell groups. SCG Change may be rephrased as SCG reconfiguration with sync. Handover (HO) may be rephrased as MCG reconfiguration with sync.

[0283] In addition, when the current terminal device settings (source settings) are copied to become the target settings (above (A-0-1) and / or (LA-6-1) and / or (LA2-6-1)), the values ​​of some or all of the timers held inside the terminal device may be carried over (at the target) after copying. That is, the values ​​before copying (at the source) may be held after copying (at the target) and continued in the target, that is, started or restarted from the values ​​at the time of copying. Also, the values ​​of some or all of the timers may not be carried over (at the target) after copying. That is, the values ​​before copying (at the source) may not be held after copying (at the target) and may be initialized after copying (at the target), or initial values ​​may be set after copying (at the target). If initialized, they may be started or restarted from the initialized values ​​in the target. The process of carrying over the values ​​of some or all timers at the source at the target may be performed for some or all radio bearers. For example, in an SRB, the target may inherit the values ​​of some or all timers from the source, and in a DRB, the target may initialize some or all timers without inheriting the values ​​of some or all timers from the source. The timers to be replicated may be some or all timers of the PDCP entity, the RLC entity, and / or the MAC entity. The timers to be replicated may also include some or all of the following timers (A) to (E). (A) A discard timer, which is a timer that is started for an SDU at the transmitting side of a PDCP entity each time the SDU is received from an upper layer. When the discard timer expires, the corresponding PDCP SDU may be discarded. (B) A reordering timer, which is a timer used to detect loss of PDCP data PDUs at the receiving side of the PDCP entity, may be the timer named t-Reordering, described in Non-Patent Document 5 and / or Non-Patent Document 11. (C) A reassembly timer used to detect RLC SDU loss at the receiving side of the RLC entity. This may be a timer named t-Reassembly as described in Non-Patent Document 6 and / or a timer named t-Reordering as described in Non-Patent Document 12. (D) Poll retransmission timer, which is a timer used for retransmitting a poll on the transmitting side of the RLC entity. This may be the timer named t-PollRetransmit described in Non-Patent Document 6 and / or Non-Patent Document 12. (E) A status prohibit timer, which is a timer used to prohibit the transmission of a status PDU at the receiving side of an RLC entity. This may be a timer named t-StatusProhibit described in Non-Patent Document 6 and / or Non-Patent Document 12.

[0284] In addition, when the current terminal device configuration (source configuration) is duplicated to become the target configuration (the above (A-0-1) and / or (LA-6-1) and / or (LA2-6-1)), the values ​​of some or all of the state variables, counters, and other variables held within the terminal device may be carried over (to the target) after duplication. That is, the values ​​before duplication (source) may be held (to the target) after duplication and continued in the target, that is, started or restarted from the values ​​at the time of duplication. Furthermore, the values ​​of some or all of the state variables, counters, and other variables may be carried over (to the target) after duplication. That is, the values ​​before duplication (source) may not be held (to the target) after duplication (target) but may be initialized after duplication (target), or initial values ​​may be set after duplication (target). If initialized, they may be started or restarted from the initialized values ​​in the target. The process of carrying over the values ​​of some or all of the state variables, counters, and other variables at the source to the target may be performed for some or all of the radio bearers. For example, in an SRB, the values ​​of some or all of the source variables, such as state variables and counters, may be inherited by the target, and in a DRB, the values ​​of some or all of the source variables, such as state variables and counters, may not be inherited by the target, but may be initialized. The state variables and counters to be replicated may be some or all of the state variables and counters of the PDCP entity, and / or the RLC entity, and / or the MAC entity. The replicated state variables and counters may also include some or all of the state variables and counters listed in (A) to (E) below. (A) A state variable indicating the COUNT value of the next PDCP PDU to be transmitted at the transmitting side of the PDCP entity. This may be a state variable named TX_NEXT as described in Non-Patent Document 11. (B) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next at the receiving side of the PDCP entity. This may be a state variable named RX_NEXT as described in Non-Patent Document 11. (C) A state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received and not yet delivered to the upper layer at the receiving side of the PDCP entity. This may be the state variable named RX_DELIV described in Non-Patent Document 11. (D) A state variable indicating the next COUNT value after the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity. This may be a state variable named RX_REORD as described in Non-Patent Document 11.

[0285] Fig. 10 is an example of an ASN.1 description showing the EUTRA RRC connection reconfiguration message in Fig. 4. Fig. 11 is another example of an ASN.1 description showing the EUTRA RRC connection reconfiguration message in Fig. 4. Fig. 12 is an example of an ASN.1 description showing the NR RRC reconfiguration message in Fig. 4. Fig. 13 is another example of an ASN.1 description showing the NR RRC reconfiguration message in Fig. 4.

[0286] 10 and 11, the information element represented by mobilityControlInfo is an information element that includes parameters related to network-controlled mobility to EUTRA. The information element represented by mobilityControlInfo may include some or all of the following information (A) to (H). (A) Target physical cell identifier (B) t304, which indicates the time from the start to the expiration of timer T304 (C) newUE-Identity indicating the new identifier (C-RNTI) of UE 122 (D) Radio resource settings (E) Setting up a dedicated random access channel (F) makeBeforeBreak-r14, a parameter that configures the existing (Release 14) make-before-break handover (G) RACH-less handover setting parameter rach-Skip-r14 (H) makeBeforeBreak-r16, which is a parameter for setting the make-before-break handover in this embodiment

[0287] FIG. 10 shows an example where makeBeforeBreak-r16 is an enumeration type, and FIG. 11 shows an example where makeBeforeBreak-r16 has the information element MakeBeforeBreak-r16 as a value, and the information element MakeBeforeBreak-r16 has multiple fields.

[0288] 12 and 13, the information elements represented by synchronized reconfiguration are, for example, information elements including parameters related to PCell handover and PSCell addition or modification. The information elements represented by synchronized reconfiguration may include some or all of the following information (A) to (F). (A) SpCell settings (B) t304, which indicates the time from the start to the expiration of timer T304 (C) newUE-Identity indicating the new identifier (RNTI) of UE 122 (D) Setting up a dedicated random access channel (E) makeBeforeBreak-r16, which is a parameter for setting the make-before-break handover in this embodiment (F) rach-Skip-r16, a parameter for configuring RACH-less handover

[0289] FIG. 12 shows an example where makeBeforeBreak-r16 is an enumeration type, and FIG. 13 shows an example where makeBeforeBreak-r16 has the information element MakeBeforeBreak-r16 as a value, and the information element MakeBeforeBreak-r16 has multiple fields.

[0290] Also, some or all of the fields shown in Figures 10 to 13 may be optional, i.e., the fields shown in Figures 10 to 13 may be included in the message depending on the conditions.

[0291] Whether or not to apply make-before-break handover (MBB-HO) may be configured from the eNB 102 or the gNB 108 for each radio bearer. When configuring whether or not to apply make-before-break handover for each radio bearer, parameters related to make-before-break handover may be configured below (in a lower layer) the radio bearer configuration (information element indicated by SRB-ToAddMod and / or information element indicated by DRB-ToAddMod) or may exist below the information element indicated by PDCP-Config. When configuring whether or not to apply make-before-break handover for each radio bearer, instead of configuring parameters related to make-before-break handover below the radio bearer configuration or below the information element indicated by PDCP-Config, information on the radio bearer to which make-before-break handover is applied may be configured above (in a higher layer) the radio bearer configuration. In addition, if there is at least one radio bearer to which make-before-break handover is applied, it may be determined that a make-before-break handover is being performed, or that a make-before-break handover has been configured.

[0292] FIG. 20 shows an example of ASN.1 indicating a parameter (information element or field) for setting whether or not to apply make-before-break handover (MBB-HO) to a radio bearer to be established or configured in each embodiment of the present invention. In the example of FIG. 20, an example is shown in which the parameter for setting whether or not to apply make-before-break handover to a radio bearer to be established or configured is located under PDCP-Config. However, the parameter for setting whether or not to apply make-before-break handover to a radio bearer to be established or configured may be located anywhere under the radio bearer configuration. Note that the above-mentioned "whether or not to apply make-before-break handover to a radio bearer to be established or configured" may be rephrased as "whether or not make-before-break handover is performed for the radio bearer to be established or configured" or similar expressions such as "whether or not make-before-break handover is applied to the radio bearer to be established or configured" or "whether or not make-before-break is applied to the radio bearer." Furthermore, the above phrase "whether make-before-break handover is applied to the radio bearer to be established or configured" may be rephrased as "whether make-before-break handover is applied to the PDCP entity," or "whether the PDCP entity performs make-before-break handover," or "the PDCP entity has a second configuration and a third configuration," etc. The second configuration may be a source (handover source) configuration in a handover. The third configuration may be a target (handover destination) configuration in a handover. The second configuration may be a primary configuration. The third configuration may be a secondary configuration. Furthermore, other expressions may be used as long as they indicate that make-before-break handover is performed when both the source configuration and the target configuration, and / or both the primary configuration and the secondary configuration are configured in one PDCP entity.

[0293] In the example of Figure 20, a field represented by mbb-drb is used as the parameter for "whether or not to apply make-before-break handover to the radio bearer to be established or configured." However, other fields and / or information elements may be used. Figure 20(A) shows an example in which mbb-drb is an enumeration type, and Figure 20(B) shows an example in which mbb-drb has an information element MBB-DRB as a value, and the information element MBB-DRB has one or more fields. In Figure 20(A), if the field represented by mbb-drb is included or is true, it may indicate that make-before-break handover is applied to the PDCP entity configured by this PDCP-Config and / or the radio bearer associated with the PDCP entity. Also, in (B) of Figure 20, the MBB-DRB information element may include, as settings for the handover destination, an identifier of the cell group of the handover destination (a field named targetCellGroupId), a logical channel identifier associated with this PDCP entity at the handover destination (a field named targetLogicalChannelIdentity), and some or all of other parameters (not shown).

[0294] Note that the field represented by mbb-drb shown in Figure 20 may be optionally present only when a parameter equivalent to makeBeforeBreak-r16 shown in the examples of Figures 10 to 13 is set, and the field represented by mbb-drb may not be present when a parameter equivalent to makeBeforeBreak-r16 shown in the examples of Figures 10 to 13 is not set. Also, instead of setting a parameter equivalent to makeBeforeBreak-r16 shown in the examples of Figures 10 to 13, if at least one radio bearer to which make before break handover is applied is performed, it may be determined that the handover is a make before break handover, that a make before break handover will be performed, or that a make before break handover has been set.

[0295] Figure 21 shows an example of ASN.1 in which information on a radio bearer to which make-before-break handover is applied exists above the radio bearer setup. As shown in Figure 21, information on a radio bearer to which make-before-break handover is applied may exist as one of the parameters of the information element MakeBeforeBreak-r16 in Figure 11 and / or Figure 13 (for example, parameter A or parameter B shown in Figure 11 and / or Figure 13). In the example of Figure 21, the description uses fields expressed as mbb-drb and mbb-drbList (a list of mbb-drb) as parameters of "information on a radio bearer to which make-before-break handover is applied," but fields and / or information elements with other names may also be used. As shown in Figure 21, the information on the radio bearer to which the make-before-break handover is applied may be some or all of the radio bearer identifier (field represented by drb-Identity) of the radio bearer to which the make-before-break handover is applied, the identifier of the cell group at the handover destination (field named targetCellGroupId), the logical channel identifier associated with this PDCP entity at the handover destination (field named targetLogicalChannelIdentity), and other parameters (not shown). Also, in the example of Figure 21, if there is no parameter for "information on the radio bearer to which the make-before-break handover is applied," the make-before-break handover may be applied to all radio bearers or all data radio bearers. Also, although only information on data radio bearers (DRBs) is shown as "information on the radio bearer to which the make-before-break handover is applied" in Figure 21, information on signaling radio bearers (SRBs) may also be included.

[0296] Fig. 5 is a block diagram showing the configuration of a terminal device (UE 122) in each embodiment of the present invention. To avoid complicating the explanation, Fig. 5 shows only the main components closely related to one embodiment of the present invention.

[0297] 5 includes a receiver 500 that receives an RRC message or the like from a base station device, a processor 502 that performs processing according to any or all of the setting information among various information elements (IEs), various fields, and various conditions included in the received message, and a transmitter 504 that transmits the RRC message or the like to the base station device. The base station device may be the eNB 102 or the gNB 108. The processor 502 may include some or all of the functions of various layers (e.g., the physical layer, the MAC layer, the RLC layer, the PDCP layer, the RRC layer, and the NAS layer). That is, the processor 502 may include some or all of the functions of the physical layer processor, the MAC layer processor, the RLC layer processor, the PDCP layer processor, the RRC layer processor, and the NAS layer processor.

[0298] Fig. 6 is a block diagram showing the configuration of a base station device in each embodiment of the present invention. To avoid complicating the explanation, Fig. 6 shows only main components closely related to one embodiment of the present invention. The base station device may be an eNB 102 or a gNB 108.

[0299] 6 includes a transmitter 600 that transmits an RRC message or the like to the UE 122, a processor 602 that creates an RRC message including any or all of setting information among various information elements (IEs), various fields, and various conditions, and transmits the RRC message to the UE 122, thereby causing the processor 502 of the UE 122 to perform processing, and a receiver 604 that receives the RRC message or the like from the UE 122. The processor 602 may include some or all of the functions of various layers (e.g., a physical layer, a MAC layer, an RLC layer, a PDCP layer, an RRC layer, and an NAS layer). That is, the processor 602 may include some or all of the functions of a physical layer processor, a MAC layer processor, an RLC layer processor, a PDCP layer processor, an RRC layer processor, and an NAS layer processor.

[0300] 25 shows an example of a processing method of the UE 122 in each embodiment of the present invention. The processing unit 602 of the base station device (eNB 102 and / or gNB 108) creates a message related to re-establishment of the RRC connection for causing the UE 122 to perform processing, and transmits the message to the UE 122 from the transmission unit 600 (not shown). The reception unit 500 of the UE 122 receives the message related to re-establishment of the RRC connection transmitted from the base station device (step S2500).

[0301] The processing unit 502 of the UE 122 checks whether or not the first information is included in the message regarding the reconfiguration of the RRC connection. If the first information is not included, it may be determined that the handover is not a make-before-break handover. If the first information is included, it may be determined that the handover is a make-before-break handover. If the first information is included, it may be determined that the make-before-break handover is applied or may be applied to some or all of the radio bearers currently configured in the UE 122. If the first information is included, it may be determined that the make-before-break handover (DAPS handover) is configured. If the message regarding the reconfiguration of the RRC connection includes the first information, the processing unit 502 of the UE 122 may create a cell group and / or a MAC entity for the target of the make-before-break handover. Furthermore, if the message regarding the re-establishment of the RRC connection includes the first information, the processing unit 502 of the UE 122 may suspend the SRB of the make-before-break handover source and establish an SRB for the make-before-break handover target (step S2502).

[0302] The processing unit 502 of the UE 122 may further determine, based on the first information described above, among the radio bearers currently set in the UE 122, which radio bearers to which make-before-break handover is applied and / or which radio bearers to which make-before-break handover is not applied (step S2504).

[0303] The processing unit 502 of the UE 122 may change or reset the cell group associated with the RLC bearer of the radio bearer to which the above-mentioned make-before-break handover does not apply from the first cell group to the second cell group (step S2506).

[0304] The processing unit 502 of the UE 122 may also establish a second RLC bearer for the radio bearer to which the above-mentioned make-before-break handover is applied, associate the second RLC bearer with the PDCP entity of the radio bearer to which the above-mentioned make-before-break handover is applied, and at this time, associate the second RLC bearer with the above-mentioned second cell group (step S2506) (step S2508).

[0305] The first information in step S2502, and / or step S2504, and / or step S2506, and / or step S2508 may be information indicating whether or not make-before-break handover is to be applied to the radio bearer to be established or configured (shown in Figures 21 and / or 22), or may be information that information indicating whether or not make-before-break handover is to be applied to the radio bearer to be established or configured (shown in Figures 21 and / or 22) exists in or is set in any of the radio bearers.

[0306] In addition, in step S2506 and / or step S2508, the second cell group may be a cell group generated based on the fact that the above-mentioned first information is included in the message regarding the reconfiguration of the RRC connection in step S2502.

[0307] In addition, in step S2506, changing or reconfiguring the cell group associated with the RLC bearer of the radio bearer to which the above-mentioned make-before-break handover is not applied from the above-mentioned first cell group to the above-mentioned second cell group may also mean performing operations including some or all of the following operations (A) and (B) on the RLC entity of the radio bearer to which the above-mentioned make-before-break handover is not applied and / or the logical channel of the radio bearer to which the above-mentioned make-before-break handover is not applied. (A) Reconfigure the above-mentioned RLC entity of the first cell group as the above-mentioned RLC entity of the second cell group. (B) Reconfigure the logical channel of the first cell group as the logical channel of the second cell group. The logical channel may be a DTCH logical channel, and the first cell group may be a cell group to which radio bearers to which the make-before-break handover is not applied are associated before the make-before-break handover is performed.

[0308] In step S2508, associating the second RLC bearer with the second cell group may involve performing operations including some or all of the following operations (C) and (D). (C) Configuring or reconfiguring the RLC entity of the second RLC bearer as the RLC entity of the second cell group. (D) The logical channel of the second RLC bearer is configured or reconfigured as the logical channel of the second cell group. The above-mentioned logical channel may be a DTCH logical channel.

[0309] In step S2506 and / or step S2508, both the first cell group and the second cell group may be master cell groups (MCGs). In step S2506 and / or step S2508, the first cell group and the second cell group may be referred to as a first MAC entity and a second MAC entity, respectively. The second MAC entity may be a MAC entity for the target of a make-before-break handover generated in step S2502. The first cell group may be a source MCG in a make-before-break handover and / or an MCG in a case where a make-before-break handover is not performed. The second cell group may be a target MCG in a make-before-break handover. The first MAC entity may be a source MAC entity in a make-before-break handover and / or an MAC entity in a case where a make-before-break handover is not performed. The second MAC entity may also be a target MAC entity in a make-before-break handover.

[0310] Furthermore, in step S2506, before changing the cell group associated with the RLC bearer of the radio bearer to which make-before-break handover is not applied from the first cell group to the second cell group, the radio bearer to which make-before-break handover is not applied may be duplicated. The duplication of the radio bearer may mean preparing a radio bearer having the same configuration as the configuration of the radio bearer. The duplication of the radio bearer may also mean preparing a radio bearer having the same configuration as the configuration of the radio bearer and the same data as the data being processed by the radio bearer. The data being processed by the radio bearer may include PDUs and / or SDUs held by each layer, buffers of each layer, variables held by each layer, timer values, etc. Alternatively, either the radio bearer to which make-before-break handover is not applied or the duplicated radio bearer may be terminated. In addition, the process of "changing the cell group associated with the RLC bearer of the radio bearer to which the make-before-break handover is not applied from the first cell group to the second cell group" in step S2506 may be performed on the bearer that is not to be stopped. In addition, the stopping of the radio bearer may include stopping of uplink transmission and / or downlink reception.

[0311] Alternatively, instead of performing the process of step S2504, it may be determined in step S2502 that make-before-break handover is applied to all radio bearers based on the fact that the message regarding the re-establishment of the RRC connection includes the first information. In this case, the process of step S2506 may not be performed.

[0312] 26 shows another example of a processing method of the UE 122 in each embodiment of the present invention. The processing unit 502 of the UE 122 attempting handover from a handover source (source) to a handover destination (target) detects that a first timer has expired (step S2600). The above-mentioned first timer may be a timer used to detect a handover failure, etc. The above-mentioned first timer may be a timer that starts when a message related to reconfiguration of an RRC connection including a parameter instructing a handover (an information element named "MobilityControlInfo" described in Non-Patent Document 4 or an information element named "ReconfigurationWithSync" described in Non-Patent Document 10) is received, or when a cell change from a different RAT (CellChangeOrder described in Non-Patent Document 4) is performed, and stops when the handover is successful, when the CellChangeOrder is successful, or when random access to the corresponding (handover destination) SpCell is successful. If the above-mentioned first timer expires, the handover may be considered to have failed. Furthermore, when the first timer described above expires, the UE 122 may initiate a procedure for re-establishing the RRC connection. When the UE 122 initiates the re-establishment of the RRC connection when the first timer described above expires, the UE 122 may return its configuration to that of the handover source (source). When the first timer described above expires during handover to a different RAT, the re-establishment of the RRC connection may be performed by selecting the cell of the handover source (source). The first timer described above may be timer T304 described in Non-Patent Document 4 or Non-Patent Document 10. Note that the handover described above may be a process in which the UE 122 in an RRC connected state changes its serving cell, as described in Non-Patent Document 3.The above-mentioned handover may be a process performed when a message regarding reconfiguration of an RRC connection is received, including a parameter instructing a handover (an information element named "MobilityControlInfo" described in Non-Patent Document 4, or an information element named "ReconfigurationWithSync" described in Non-Patent Document 10), or may be a message indicating movement to a cell of another RAT (for example, MobilityFromEUTRACommand described in Non-Patent Document 4, or MobilityFromNRCommand described in Non-Patent Document 10). The above-mentioned handover may also be a DAPS handover.

[0313] In step S2600, the processing unit 502 of the UE 122 that has detected that the first timer has expired may next determine whether the first configuration has been configured in the UE 122. If the first configuration has been configured in the UE 122, some or all of the configurations of the handover destination (target) may be released based on the fact that the first configuration has been configured (step S2602). Note that the above-mentioned first configuration may be a configuration related to DAPS handover, or a configuration related to a radio bearer to which DAPS handover is applied. Furthermore, the above-mentioned case where the first configuration has been configured may be rephrased as a case where DAPS handover configuration has been configured for any radio bearer, or a case where DAPS handover configuration has been configured for at least one radio bearer, or may be rephrased by another similar expression. Note that the above-mentioned DAPS handover configuration may be a configuration indicating that the radio bearer to which DAPS handover is applied is a radio bearer to which DAPS handover is applied. Furthermore, the above-mentioned releasing of some or all of the settings of the handover target may mean releasing settings including some or all of the RLC entities and logical channels of the handover target for radio bearers to which DAPS handover is applied. Furthermore, the above-mentioned releasing of the settings of the handover target may mean releasing settings including some or all of the PDCP entities, radio bearer identifiers, RLC entities, logical channels, and SDAP QoS flow and radio bearer mapping rules of the handover target for radio bearers to which DAPS handover is not applied. Furthermore, when releasing the above-mentioned settings of the handover target, the MAC entity of the handover target may be reset.

[0314] In step S2602, the processing unit 502 of the UE 122 determines whether a first setting has been made to the UE 122, and if the first setting has been made to the UE 122, may further determine whether a radio link failure has been detected in the primary cell of the handover source (source). If a radio link failure has not been detected in the primary cell of the handover source (source), some or all of the settings of the handover destination (target) may be released based on the fact that the first setting has been made to the UE 122 and that a radio link failure has not been detected in the primary cell of the handover source (source). Note that the primary cell may be a PCell (Primary Cell) or an SpCell (Special Cell).

[0315] Furthermore, in step S2600, upon detecting that the first timer has expired, the processing unit 502 of the UE 122 determines whether the first setting has been made in the UE 122. If the first setting has been made in the UE 122, the processing unit 502 may update the security key set in the handover source (source) based on the fact that the first setting has been made (step S2604). Note that the above-mentioned first setting may be a setting related to DAPS handover, or a setting related to a radio bearer to which DAPS handover is applied. Furthermore, the above-mentioned case where the first setting has been made may be rephrased as a case where DAPS handover is set in any radio bearer, or a case where DAPS handover is set in at least one radio bearer, or may be rephrased by another similar expression. Furthermore, the security key set in the handover source (source) may be rephrased as the security key that was set in the handover source (source). Furthermore, the above-mentioned security key update may be a process including some or all of the following (A) and (B). (A) A base station key is generated from the current base station key or NH (Next Hop) information. (B) Generate some or all of the SRB confidentiality key, the SRB integrity key, the DRB confidentiality key, and the DRB integrity key.

[0316] In addition, in step S2604, after updating the security key, or before updating the security key, or without updating the security key, processing including some or all of the following (C) to (F) may be performed. (C) Configure the lower layer to process integrity protection for some or all SRBs using the above-mentioned SRB integrity key or the configured SRB integrity key and the configured integrity algorithm. (D) Configure the lower layer to perform integrity protection processing for some or all DRBs using the above-mentioned DRB integrity key or the configured DRB integrity key and the configured integrity algorithm. (E) Configure the lower layer to perform encryption processing for some or all SRBs using the above-mentioned SRB confidentiality key or the configured SRB confidentiality key and the configured confidentiality algorithm. (F) Configure the lower layer to perform encryption processing for some or all DRBs using the above-mentioned DRB confidentiality key or the configured DRB confidentiality key and the configured confidentiality algorithm.

[0317] In step S2604, the base station key may be KeNB described in Non-Patent Document 21, or may be KgNB described in Non-Patent Document 21. In step S2604, the SRB integrity key and DRB integrity key may be KRRCint and KUPint described in Non-Patent Document 21 and / or Non-Patent Document 22, respectively. In step S2604, the SRB confidentiality key and DRB confidentiality key may be KRRCenc and KUPenc described in Non-Patent Document 21 and / or Non-Patent Document 22, respectively. In step S2604, the above-mentioned NH (Next Hop) may be NH (Next Hop) described in Non-Patent Document 21 and / or Non-Patent Document 22. In step S2604, the lower layer may be a PDCP layer or a PDCP entity.

[0318] Furthermore, the above-described process (C) in step S2604 may be rephrased as configuring a lower layer to perform integrity protection processing for all SRBs except SRB 1 using the above-described SRB integrity key or the configured SRB integrity key and the configured integrity algorithm. Furthermore, the above-described process (E) in step S2604 may be rephrased as configuring a lower layer to perform encryption processing for all SRBs except SRB 1 using the above-described SRB confidentiality key or the configured SRB confidentiality key and the configured confidentiality algorithm. Furthermore, some or all of the process in step S2604 may be performed after UE 122 detects that the first timer has expired in step S2600 and before sending a first RRC message to the handover source base station device. Alternatively, some or all of the processing in step S2604 may be performed after the UE 122 detects that the first timer has expired in step S2600 and sends a first RRC message to the handover source (source) base station. The first RRC message may be an RRC message for notifying that the DAPS handover to the target has failed. After sending the first RRC message to the handover source (source) base station, lower layers may be configured to perform integrity protection processing for SRB1 or some or all of the radio bearers using the SRB integrity key or the configured SRB integrity key and the configured integrity algorithm. After sending the first RRC message to the handover source (source) base station, lower layers may be configured to perform encryption processing for SRB1 or some or all of the radio bearers using the SRB confidentiality key or the configured SRB confidentiality key and the configured confidentiality algorithm. Also, in step S2604, some or all of the radio bearers may be suspended before or after the security keys are updated.After the UE 122 detects that the first timer has expired, the UE 122 may resume some or all of the suspended radio bearers when or before sending the first RRC message to the handover source base station. The resumed radio bearers may include SRB1 or all of the SRBs.

[0319] Alternatively, a part or all of the processing of step S2604 may be performed when or after the UE 122 receives the first RRC message from the handover source (source) base station after detecting that the first timer has expired in step S2600. Alternatively, a part or all of the processing of step S2604 may be performed based on the fact that the first RRC message received from the handover source (source) base station after the UE 122 detects that the first timer has expired in step S2600 includes a parameter indicating a security key update. The first RRC message received from the handover source (source) base station may be a message regarding re-establishment of the RRC connection, a message regarding resumption of the RRC connection, or another RRC message. The parameter indicating a security key update may be included in the RRC message based on a failure of the DAPS handover. Furthermore, the parameter that indicates the update of the security key mentioned above may be a parameter (field) represented by the name securityConfigHO described in Non-Patent Document 4, or a parameter (field) represented by the name masterKeyUpdate described in Non-Patent Document 10.

[0320] In addition, in step S2604, the MAC entity of the handover source (source) may be reset. The process of resetting the MAC entity of the handover source (source) may be performed before or after the security key update process of the handover source (source), or may be performed after the UE 122 detects that the first timer has expired and before sending the first RRC message to the handover source (source) base station device, or may be performed after sending the first RRC message. The process of resetting the MAC entity of the handover source may be performed after the UE 122 detects that the first timer has expired and when or after receiving the first RRC message from the handover source (source) base station device. In addition, in step S2604, PDCP entities of some or all radio bearers may be re-established before or after the security key update process of the handover source (source).

[0321] In step S2604, the processing unit 502 of the UE 122 determines whether a first setting has been made in the UE 122, and if the first setting has been made in the UE 122, may further determine whether a radio link failure has been detected in the primary cell of the handover source (source). If a radio link failure has not been detected in the primary cell of the handover source (source), the processing unit 502 may update the security key set in the handover source (source) and perform the above-mentioned processing based on the fact that the first setting has been made in the UE 122 and that a radio link failure has not been detected in the primary cell of the handover source (source). Note that the above-mentioned primary cell may be a PCell (Primary Cell) or an SpCell (Special Cell).

[0322] In step S2604, based on the fact that the first configuration has been performed on the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source, a process of reverting some or all of the radio bearers to the configurations used in the handover source (source) may be performed. The process of reverting to the configurations used in the handover source (source) may be performed for radio bearers to which DAPS handover is not applied. The process of reverting to the configurations used in the handover source (source) may be performed before or after the security key update process in step S2604, or may be performed before or after sending the first RRC message to the handover source (source) base station after the UE 122 detects that the first timer has expired.

[0323] In step S2604, the security key may not be updated based on the first setting being made in UE 122 and / or the fact that no radio link failure has been detected in the primary cell of the handover source.

[0324] In step S2604, the security key does not necessarily need to be updated.

[0325] The receiving unit 500 of the UE 122 may receive a message related to re-establishment of the RRC connection from the base station device. The processing unit 502 of the UE 122 may establish or re-establish a radio bearer in accordance with the message related to re-establishment of the RRC connection (step S2606). Note that some or all of the processing of step S2604 may be performed when establishing or re-establishing a radio bearer in step S2606.

[0326] Furthermore, in step S2604 and / or step S2606, based on the fact that the first configuration is performed on the UE 122 and / or that a radio link failure is not detected in the primary cell of the handover source, some or all of the data present in the buffer for some or all of the radio bearers may be discarded. The data present in the buffer may be some or all of the PDCP SDUs, PDCP PDUs, RLC SDUs, RLC SDU segments, RLC PDUs, MAC SDUs, and MAC PDUs. The data present in the buffer may also include data present in a retransmission buffer. The process of discarding some or all of the data present in the buffer based on the fact that the first configuration is performed on the UE 122 and / or that a radio link failure is not detected in the primary cell of the handover source may be performed after a process of reverting the configuration used in the handover source for radio bearers to which DAPS handover does not apply. Furthermore, the process of discarding some or all of the data in the buffer based on the fact that the first configuration has been performed on the UE 122 and / or that no radio link failure has been detected in the primary cell of the handover source may be performed after a process of reverting the configuration used in the handover source for the bearers (UM DRBs) for which RLC UM is configured or established among the radio bearers to which DAPS handover does not apply. The process of discarding some or all of the data in the buffer based on the fact that the first configuration has been performed on the UE 122 and / or that no radio link failure has been detected in the primary cell of the handover source may be performed by a discard timer configured in the PDCP entity. The discard timer may be a timer named “discardTimer” described in Non-Patent Document 5 and / or Non-Patent Document 11.The discard timer may be a timer that is started for each SDU received from a higher layer at the transmitting side of the PDCP entity, and the SDU may be discarded when the discard timer expires. The discard timer value may be the value of the discard timer at the target when the first timer expires. That is, when reverting a radio bearer to the configuration used at the source, the discard timer may be retained without restoring it to the configuration used at the source. The discard timer value at the target may be maintained for the radio bearer reverted to the configuration used at the source. Furthermore, the radio bearer that discards some or all of the buffered data based on the first configuration of the UE 122 and / or the absence of a radio link failure in the primary cell of the source may be pre-configured by an RRC message.

[0327] Furthermore, in step S2604 and / or step S2606, based on the fact that the first configuration has been performed in the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source, some or all of the timers configured in each entity for some or all of the radio bearers may be stopped and / or started and / or restarted. The timers configured in the above-mentioned entities may be some or all of the timers of the PDCP entity, the RLC entity, and / or the MAC entity. The process of stopping and / or starting and / or restarting some or all of the timers configured in each entity based on the fact that the first configuration has been performed in the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source may be performed after a process of reverting the configurations used in the handover source for radio bearers to which DAPS handover does not apply. Furthermore, the process of stopping and / or starting and / or restarting some or all of the timers configured in each entity based on the above-mentioned first configuration being performed in the UE 122 and / or no radio link failure being detected in the primary cell of the handover source may be performed after a process of reverting the configuration used in the handover source for the bearers (UM DRBs) for which RLC UM is configured or established among the radio bearers to which DAPS handover does not apply. Furthermore, the radio bearers for which the process of stopping and / or starting and / or restarting some or all of the timers configured in each entity based on the above-mentioned first configuration being performed in the UE 122 and / or no radio link failure being detected in the primary cell of the handover source may be configured in advance by an RRC message. Furthermore, the timers configured in each entity may include some or all of the following timers (A) to (D): (A) A reordering timer, which is a timer used to detect loss of PDCP data PDUs at the receiving side of a PDCP entity. This may be the timer named t-Reordering, which is described in Non-Patent Document 5 and / or Non-Patent Document 11. (B) A reassembly timer used to detect RLC SDU loss at the receiving side of the RLC entity. This may be a timer named t-Reassembly as described in Non-Patent Document 6 and / or a timer named t-Reordering as described in Non-Patent Document 12. (C) Poll retransmission timer, which is a timer used for retransmitting a poll on the transmitting side of the RLC entity. This may be the timer named t-PollRetransmit described in Non-Patent Document 6 and / or Non-Patent Document 12. (D) A status prohibit timer, which is a timer used to prohibit the transmission of a status PDU on the receiving side of an RLC entity, may be a timer named t-StatusProhibit described in Non-Patent Document 6 and / or Non-Patent Document 12.

[0328] Furthermore, in step S2604 and / or step S2606, based on the fact that the first configuration has been performed in the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source, some or all of the state variables configured in each e-entity for some or all of the radio bearers may be set to initial values ​​and / or reset. The state variables configured in each of the above-mentioned entities may be some or all of the state variables of the PDCP entity, the RLC entity, and / or the MAC entity. The process of setting some or all of the state variables configured in each entity to initial values ​​based on the fact that the first configuration has been performed in the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source may be performed after a process of reverting the configurations used in the handover source for radio bearers to which DAPS handover does not apply. Furthermore, the process of setting and / or resetting some or all of the state variables set in each entity to their initial values ​​based on the fact that the first configuration has been performed on the UE 122 and / or that no radio link failure has been detected in the primary cell of the handover source (source) may be performed after a process of reverting a bearer (UM DRB) for which RLC UM is configured or established, among radio bearers to which DAPS handover is not applied, to the configuration used in the handover source (source). Furthermore, the radio bearers for which the process of setting and / or resetting some or all of the state variables set in each entity to their initial values ​​based on the fact that the first configuration has been performed on the UE 122 and / or that no radio link failure has been detected in the primary cell of the handover source (source) may be configured in advance by an RRC message.

[0329] Furthermore, in step S2604 and / or step S2606, based on the fact that the first configuration has been performed on the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source, some or all of the radio bearers may be reverted to the configuration used in the handover source (source), but some or all of the data may not be reverted to the configuration or state used in the handover source (source). The above-mentioned some or all of the data may be some or all of the PDCP SDUs, PDCP PDUs, RLC SDUs, RLC SDU segments, RLC PDUs, MAC SDUs, and MAC PDUs. The process of reverting some or all radio bearers to the settings used in the handover source (source) based on the above-mentioned first configuration being performed on the UE 122 and / or no radio link failure being detected in the primary cell of the handover source (source), but not reverting some or all data to the settings or states used in the handover source (source), may be performed for radio bearers to which DAPS handover is not applied, or for UM bearers to which DAPS handover is not applied. Furthermore, the radio bearers to which the process of reverting some or all radio bearers to the settings used in the handover source (source) based on the above-mentioned first configuration being performed on the UE 122 and / or no radio link failure being detected in the primary cell of the handover source (source), but not reverting some or all data to the settings or states used in the handover source (source), may be pre-configured by an RRC message.

[0330] Furthermore, in step S2604 and / or step S2606, based on the fact that the first setting has been made to UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source (source), some or all of the radio bearers are reverted to the settings used in the handover source (source), but at this time, the values ​​of some or all of the timers may be set to their initial values ​​and started or restarted without being reverted to the settings or states used in the handover source (source). Based on the fact that the first setting has been made to the UE 122 described above and / or that no radio link failure has been detected in the primary cell of the handover source (source), some or all of the radio bearers are reverted to the settings used in the handover source (source), but at this time, the values ​​of some or all of the timers are not reverted to the settings or states used in the handover source (source) but are set to their initial values. The start or restart process may be performed for radio bearers to which DAPS handover does not apply, or may be performed for UM bearers to which DAPS handover does not apply. Furthermore, based on the fact that the above-mentioned first configuration has been performed on the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source, some or all of the radio bearers are reverted to the configuration used in the handover source (source), but at this time, the values ​​of some or all of the timers are not reverted to the configuration or state used in the handover source (source) but are set to their initial values, and the radio bearers to be started or restarted may be configured in advance by an RRC message. The above-mentioned some or all of the timers may include some or all of the following timers (A) to (E). (A) A discard timer, which is a timer that is started for an SDU at the transmitting side of a PDCP entity each time the SDU is received from an upper layer. When the discard timer expires, the corresponding PDCP SDU may be discarded. (B) A reordering timer, which is a timer used to detect loss of PDCP data PDUs at the receiving side of a PDCP entity. (C) Reassembly timer, which is a timer used to detect loss of RLC SDUs at the receiving side of the RLC entity. (D) Poll retransmission timer, which is the timer used for retransmission of polls at the transmitting side of the RLC entity. (E) A status prohibit timer, which is a timer used to prohibit the transmission of status PDUs at the receiving side of an RLC entity.

[0331] Furthermore, in step S2604 and / or step S2606, based on the fact that the first setting has been made to UE 122 and / or that no radio link failure has been detected in the primary cell of the handover source, some or all of the radio bearers are reverted to the settings used in the handover source (source), but at this time, some or all of the state variables may not be reverted to the settings or states used in the handover source (source) but may be set to their initial values ​​and a start or restart process may be performed. Based on the fact that the first setting has been made to the UE 122 described above and / or that no radio link failure has been detected in the primary cell of the handover source (source), some or all of the radio bearers are reverted to the settings used in the handover source (source), but at this time the values ​​of some or all of the state variables are not reverted to the settings or states used in the handover source (source) but are set to their initial values. The process of starting or restarting may be performed for radio bearers to which DAPS handover does not apply, or may be performed for UM bearers to which DAPS handover does not apply. Furthermore, based on the fact that the above-mentioned first configuration has been performed on the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source, some or all of the radio bearers are reverted to the configurations used in the handover source (source), but at this time, the values ​​of some or all of the state variables are not reverted to the configurations or states used in the handover source (source) but are set to their initial values, and the radio bearers to be started or restarted may be pre-configured by an RRC message. The above-mentioned some or all of the state variables may be some or all of the state variables of the PDCP entity, some or all of the state variables of the RLC entity, or some or all of the state variables of the MAC entity.

[0332] Furthermore, in step S2604 and / or step S2606, the PDCP entities of some or all radio bearers may be instructed to transmit status reports and / or perform data recovery based on the fact that the first configuration has been performed on the UE 122 and / or that a radio link failure has not been detected in the primary cell of the handover source. The status report may be the status report described in Non-Patent Document 5 and / or Non-Patent Document 11. That is, the status report may be a report for notifying the transmitting side of the COUNT value of PDCP SDUs waiting to be received (PDCP SDUs that have not been received). The data recovery may be the data recovery described in Non-Patent Document 5 and / or Non-Patent Document 11. That is, the data recovery may be a process of retransmitting PDCP Data PDUs for which a successful transmission notification has not been received from a lower layer on a radio bearer (AM DRB) for which RLC AM is configured or established. The process of causing the PDCP entities of some or all radio bearers to transmit status reports and / or perform data recovery based on the above-mentioned first configuration being performed on the UE 122 and / or the fact that no radio link failure is detected in the primary cell of the handover source may be performed for the radio bearers to which the DAPS handover is applied.Furthermore, the process of causing the PDCP entities of some or all radio bearers to transmit status reports and / or perform data recovery based on the above-mentioned first configuration being performed on the UE 122 and / or the fact that no radio link failure is detected in the primary cell of the handover source may be performed for the AM DRB to which the DAPS handover is applied.

[0333] Note that part or all of the term "handover source" in steps S2600 to S2606 may be replaced with "handover source PCell" (source PCell) or "handover source cell group" (source cell group). Also, part or all of the term "handover destination" in steps S2600 to S2606 may be replaced with "handover destination PCell" (target PCell) or "handover destination cell group" (target cell group).

[0334] 27 shows yet another example of a processing method of UE 122 in each embodiment of the present invention. Note that the first timer in steps S2700 to S2704 described below may be a timer equivalent to the first timer in steps S2600 to S2606 described above. Also, the first setting in steps S2700 to S2704 described below may be equivalent to the first setting in steps S2600 to S2606 described above.

[0335] The processing unit 502 of the UE 122 attempting a handover from a handover source (source) to a handover destination (target) detects that a first timer has expired (step S2700). The above-mentioned first timer may be a timer used to detect a handover failure, etc. The above-mentioned first timer may be a timer that starts when a message related to reconfiguration of the RRC connection including a parameter instructing a handover (an information element named "MobilityControlInfo" described in Non-Patent Document 4 or an information element named "ReconfigurationWithSync" described in Non-Patent Document 10) is received, or when a cell change from a different RAT (CellChangeOrder described in Non-Patent Document 4) is received, and stops when the handover is successful, when the CellChangeOrder is successful, or when random access to the corresponding (handover destination) SpCell is successful. When the above-mentioned first timer expires, the handover may be considered to have failed. When the above-mentioned first timer expires, the UE 122 may initiate a procedure for re-establishing the RRC connection. Furthermore, when the UE 122 initiates re-establishment of the RRC connection after the above-mentioned first timer has expired, the UE 122 may return its configuration to that of the handover source (source). Furthermore, when the above-mentioned first timer has expired during handover to a different RAT, the re-establishment of the RRC connection may be performed by selecting the cell of the handover source (source). Furthermore, the above-mentioned first timer may be timer T304 described in Non-Patent Document 4 or Non-Patent Document 10. Note that the above-mentioned handover may be a process in which the UE 122 in an RRC connected state changes serving cells, as described in Non-Patent Document 3.The above-mentioned handover may be a process performed when a message regarding reconfiguration of an RRC connection is received, including a parameter instructing a handover (an information element named "MobilityControlInfo" described in Non-Patent Document 4, or an information element named "ReconfigurationWithSync" described in Non-Patent Document 10), or may be a message indicating movement to a cell of another RAT (for example, MobilityFromEUTRACommand described in Non-Patent Document 4, or MobilityFromNRCommand described in Non-Patent Document 10). The above-mentioned handover may also be a DAPS handover.

[0336] In step S2700, the processing unit 502 of the UE 122 that has detected the expiration of the first timer may then determine whether the first configuration has been configured in the UE 122 and / or whether a radio link failure has been detected in the primary cell of the handover source (source). If the first configuration has been configured in the UE 122 and / or if a radio link failure has not been detected in the primary cell of the handover source (source), some or all of the configurations of the handover target (target) may be released based on the first configuration being configured and / or the radio link failure not being detected in the primary cell of the handover source (source). Furthermore, if the first configuration has been configured in the UE 122 and / or if a radio link failure has not been detected in the primary cell of the handover source (source), the processing unit 502 may resume the suspended SRB of the handover source (source) based on the first configuration being configured and / or the radio link failure not being detected in the primary cell of the handover source (source) (step S2702). The above-mentioned first setting may be a setting related to DAPS handover, or a setting related to a radio bearer to which DAPS handover is applied. Furthermore, the case where the above-mentioned first setting is performed may be rephrased as a case where DAPS handover setting is performed for any radio bearer, or a case where DAPS handover setting is performed for at least one radio bearer, or may be rephrased by other similar expressions. The above-mentioned DAPS handover setting may be a setting indicating that the radio bearer is to be applied to DAPS handover.

[0337] The processing unit 502 of the UE 122 may delete some or all of the data present in the buffers of the PDCP entity and / or LC entity of the SRB of the source that was resumed in step S2702. The processing unit 502 of the UE 122 may also stop and / or reset the reordering timer in the PDCP entity of the SRB of the source that was resumed in step S2702. If the message regarding RRC connection re-establishment received at the time of handover initiation does not include an information element regarding security key update, the processing unit 502 of the UE 122 may set some or all of the state variables in the PDCP entity of the SRB of the source that was resumed in step S2702 to the same values ​​as the state variables of the PDCP entity of the target SRB. The processing unit 502 of the UE 122 may also set the state variables related to reordering in the PDCP entity of the SRB of the source that was resumed in step S2702 to a state in which no PDCP PDUs are waiting to be received. The processing unit 502 of the UE 122 may also stop and / or initialize some or all of the timers in the RLC entity of the SRB of the source resumed in step S2702 described above. The processing unit 502 of the UE 122 may also reset some or all of the state variables in the RLC entity of the SRB of the source resumed in step S2702 described above (step S2704).

[0338] In the above-mentioned step S2704, the process of stopping and / or resetting the reordering timer in the PDCP entity of the SRB of the resumed source and / or the process of keeping the reordering-related state variables in the PDCP entity in a state where there are no PDCP PDUs waiting to be received may be performed based on the fact that the reordering timer is running. Also, in the above-mentioned step S2704, the process of deleting some or all of the data existing in the buffers of the PDCP entity and / or LC entity of the SRB of the resumed source and / or the process of stopping and / or resetting the reordering timer in the PDCP entity of the SRB of the resumed source and / or the process of keeping the reordering-related state variables in the PDCP entity in a state where there are no PDCP PDUs waiting to be received may be performed based on the fact that data exists in the buffers of the PDCP entity and / or LC entity of the SRB of the resumed source.

[0339] Furthermore, in the above-mentioned step S2704, if the message regarding re-establishment of the RRC connection received upon initiation of handover does not include an information element regarding security key update, the state variables in the process of setting some or all of the state variables in the PDCP entity of the source SRB resumed in the above-mentioned step S2702 to the same values ​​as the state variables of the PDCP entity of the target SRB may be state variables regarding the COUNT value. Furthermore, in the above-mentioned step S2704, if the message regarding re-establishment of the RRC connection received upon initiation of handover includes an information element regarding security key update, some or all of the state variables in the PDCP entity of the source SRB resumed in the above-mentioned step S2702 may be maintained.

[0340] In step S2704 described above, the state variables related to the COUNT value may include some or all of the following (A) to (F). (A) A state variable indicating the COUNT value of the next PDCP SDU to be transmitted. This may be a state variable named TX_NEXT as described in Non-Patent Document 11. (B) A state variable indicating the sequence number of the PDCP SDU to be transmitted next in this PDCP entity. This may be a state variable named Next_PDCP_TX_SN as described in Non-Patent Document 5. (C) A state variable representing the HFN value used to generate the COUNT value of a PDCP PDU in this PDCP entity. This may be the state variable named TX_HFN described in Non-Patent Document 5. (D) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next at the receiving side of the PDCP entity. This may be the state variable named RX_NEXT described in Non-Patent Document 11. (E) A state variable indicating the sequence number of the PDCP SDU that is expected to be received next at the receiving side of this PDCP entity. This may be a state variable named Next_PDCP_RX_SN described in Non-Patent Document 5. (F) A state variable representing the HFN value used to generate a COUNT value for a received PDCP PDU in this PDCP entity. This may be the state variable named RX_HFN described in Non-Patent Document 5.

[0341] In step S2704 described above, the state variables related to reordering may include some or all of the following (A) to (F). (A) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next on the receiving side of a PDCP entity. This may be the state variable named RX_NEXT described in Non-Patent Document 11. (B) A state variable indicating the sequence number of the PDCP SDU that is expected to be received next on the receiving side of a PDCP entity. This may be the state variable named Next_PDCP_RX_SN described in Non-Patent Document 5. (C) A state variable representing the HFN value used to generate a COUNT value for a received PDCP PDU in this PDCP entity. This may be the state variable named RX_HFN described in Non-Patent Document 5. (D) A state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received and not yet delivered to the upper layer at the receiving side of the PDCP entity. This may be the state variable named RX_DELIV described in Non-Patent Document 11. (E) A state variable indicating the sequence number of the PDCP PDU of the PDCP SDU last delivered to the upper layer at the receiving side of this PDCP entity. This may be a state variable named Last_Submitted_PDCP_RX_SN as described in Non-Patent Document 5. (F) A state variable indicating the next COUNT value after the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity. This may be the state variable named RX_REORD described in Non-Patent Document 11 or the state variable named Reordering_PDCP_RX_COUNT described in Non-Patent Document 5.

[0342] In the above-mentioned step S2704, the process of setting the state variables related to reordering in the PDCP entity of the SRB of the resumed source to a state where there are no PDCP PDUs waiting to be received may include some or all of the following processes (E) to (F) when the RAT is NR. (E) At the receiving side of the PDCP entity, the value of a state variable (which may be a state variable named RX_NEXT as described in non-patent document 11) indicating the COUNT value of the next PDCP SDU expected to be received is set to the value of a state variable (which may be a state variable named RX_DELIV as described in non-patent document 11) indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received but not yet delivered to the upper layer at the receiving side of the PDCP entity. (F) At the receiving side of the PDCP entity, the value of a state variable (which may be a state variable named RX_NEXT as described in non-patent document 11) indicating the COUNT value of the PDCP SDU expected to be received next is set to the value of a state variable (which may be a state variable named RX_REORD as described in non-patent document 11) indicating the COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity.

[0343] In the above-mentioned step S2704, the process of setting the state variables related to reordering in the PDCP entity of the SRB of the resumed source to a state where there are no PDCP PDUs waiting to be received may include some or all of the following processes (G) to (H) when the RAT is E-UTRA. (G) At the receiving side of this PDCP entity, the value of a state variable (which may be a state variable named Next_PDCP_RX_SN as described in non-patent document 5) indicating the sequence number of the PDCP SDU expected to be received next is set to the value of a state variable (which may be a state variable named Last_Submitted_PDCP_RX_SN as described in non-patent document 5) indicating the sequence number of the PDCP PDU of the PDCP SDU last delivered to the upper layer at the receiving side of this PDCP entity. (H) In this PDCP entity, the value of a state variable (which may be the state variable named RX_HFN described in non-patent document 5) representing the HFN value used to generate a COUNT value for a received PDCP PDU and / or the value of a state variable (which may be the state variable named Next_PDCP_RX_SN described in non-patent document 5) indicating the COUNT value of the PDCP SDU expected to be received next at the receiving side of this PDCP entity is set to the value of a state variable (which may be the state variable named Reordering_PDCP_RX_COUNT described in non-patent document 5) indicating the COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of this PDCP entity.

[0344] In the above-mentioned step S2704, the process of changing the state variable related to reordering in the PDCP entity of the SRB of the resumed source to a state where there are no PDCP PDUs waiting to be received may be rephrased as a process of changing the state variable related to reordering to a state where there is no reordering window, or may be expressed in other words as long as it represents a process of changing the state variable related to reordering to a state where there are no PDCP PDUs waiting to be received. In the above-mentioned step S2704, the process of changing the state variable related to reordering in the PDCP entity of the SRB of the resumed source to a state where there are no PDCP PDUs waiting to be received may be a process of updating the state variable related to reordering to a state where there are no PDCP PDUs waiting to be received while maintaining the state variable related to the COUNT value.

[0345] Note that the reordering timer may be referred to as a timer in steps 2700 to 2704. Also, the SRB may be referred to as a radio bearer in steps 2700 to 2704. Also, in step S2702, the process of releasing some or all of the settings of the handover destination (target) may be performed after step S2704.

[0346] In this way, in the embodiment of the present invention, efficient communication can be performed when the UE 122 undergoes handover.

[0347] The radio bearers in the above description may be DRBs, SRBs, or both DRBs and SRBs.

[0348] In the above description, a radio bearer to which DAPS handover is applied may be a DRB to which DAPS handover is applied, and a radio bearer to which DAPS handover is not applied may be a DRB to which DAPS handover is not applied.

[0349] In the above description, expressions such as "tied," "associated," and "associated" may be interchangeable.

[0350] In addition, in each of the process examples or process flow examples described above, some or all of the steps may not be executed. In addition, in each of the process examples or process flow examples described above, the order of the steps may be different. In each of the process examples or process flow examples described above, some or all of the processing within each step may not be executed. In addition, in each of the process examples or process flow examples described above, the order of the processing within each step may be different.

[0351] In the above description, "in the case of MBB-HO" and / or "being MBB-HO" may refer to a case where, when performing RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing RRC reconfiguration including synchronized reconfiguration in NR, transmission and / or reception in a target cell is performed while continuing transmission and / or reception of user data in a source cell, or may be expressed by another name meaning an equivalent operation. Furthermore, "in the case of MBB-HO" and / or "being MBB-HO" may refer to a case where, in LTE or NR, a specific information element (e.g., the MakeBeforeBreak-r16 information element shown in Figures 10 to 13 and 21, and / or mbb-drb shown in Figures 20 to 22) is included in an RRC reconfiguration message. Furthermore, "in the case of MBB-HO" and / or "being MBB-HO" may mean that the time (disruption time) during which data communication is not possible between a terminal device and a base station device is set to zero milliseconds (0 msec) or close to zero milliseconds, or may be expressed by another name that means this.

[0352] In the above description, "MBB-HO related settings" may refer to settings for transmitting and / or receiving user data in a target cell while continuing transmission and / or reception in a source cell when performing RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing RRC reconfiguration including synchronized reconfiguration in NR, or may be expressed by another name meaning an equivalent setting. Furthermore, "MBB-HO related settings" may refer to a case in which a specific information element (e.g., the MakeBeforeBreak-r16 information element shown in Figures 10 to 13 and 21, and / or mbb-drb shown in Figures 20 to 21) is included in an RRC reconfiguration message in LTE or NR. Furthermore, "in the case of MBB-HO" and / or "being MBB-HO" may refer to a case in which the time during which data communication between a terminal device and a base station device is unavailable (disruption time) is set to zero milliseconds (0 msec) or close to zero milliseconds, or may be expressed by another name meaning this.

[0353] In the above description, "Make Before Break Handover (MBB-HO)" may also mean that a target master cell group is created and exists simultaneously with a source master cell group. Furthermore, "MBB-HO" may also mean that, when performing RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing RRC reconfiguration including synchronized reconfiguration in NR, transmission and / or reception in the target cell is performed while continuing transmission and / or reception of user data in the source cell on some or all of the radio bearers configured in the terminal device, or may be expressed by another name meaning equivalent processing. Furthermore, "MBB-HO" may also mean, in LTE or NR, that a specific first information element (e.g., the MakeBeforeBreak-r16 information element shown in Figures 10 to 13 and 21) is included in a message related to RRC connection reconfiguration. Furthermore, the radio bearer that performs transmission and / or reception in the target cell while continuing transmission and / or reception of user data in the source cell may be a radio bearer to which make-before-break handover is applied. The radio bearer to which make-before-break handover is applied may be a radio bearer indicated by a specific second information element (e.g., mbb-drb shown in Figures 20 and 21).

[0354] In the above explanation, "Make Before Break Handover (MBB-HO)" may also mean a process of reducing the time (interruption time) during which data communication is not possible between a terminal device and a base station device to zero milliseconds (0 msec) or approaching zero milliseconds (RUDI: Reduce User Data Interruption), or it may be expressed by another name that means this.

[0355] In each embodiment of the present invention, handover may be rephrased as reconfiguration with sync. For example, make-before-break handover may be rephrased as make-before-break synchronized reconfiguration.

[0356] In the above explanation, "A may be replaced with B" may mean replacing A with B, as well as replacing B with A. Also, in the above explanation, when it is written that "C may be D" and "C may be E", it may also mean that "D may be E". Also, in the above explanation, when it is written that "F may be G" and "G may be H", it may also mean that "F may be H".

[0357] In the above explanation, if condition "A" and condition "B" are contradictory conditions, condition "B" may be expressed as the "other" condition of condition "A."

[0358] Various aspects of the terminal device according to the embodiment of the present invention will be described below.

[0359] (1) One embodiment of the present invention is a terminal device communicating with a base station device, which, when a first timer expires and a first failure is not detected, resumes a suspended source radio bearer based on a first setting being made in the terminal device, and sets the value of a first state variable of a PDCP entity of the source radio bearer to one or both of the value of a second state variable and the value of a third state variable of the PDCP entity.

[0360] (2) The terminal device described in (1), wherein the first timer is a timer that is started when the terminal device receives an RRC reconnection message from the base station device, the RRC reconnection message including an information element that instructs a change of serving cell in an RRC connected state, and that causes the terminal device to re-establish an RRC connection when the first timer expires.

[0361] (3) A terminal device described in (1) or (2), wherein the first failure is a radio link failure in the source's primary cell.

[0362] (4) A terminal device according to (1), (2), or (3), wherein the first state variable is a state variable indicating the COUNT value of the PDCP SDU that is expected to be received next at the receiving side of the PDCP entity.

[0363] (5) A terminal device according to (1), (2), (3), or (4), wherein the second state variable is a state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received at the receiving side of the PDCP entity and not delivered to an upper layer.

[0364] (6) The third state variable is a state variable indicating the next COUNT value after the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity, in a terminal device described in (1), (2), (3), (4), or (5).

[0365] (7) One embodiment of the present invention is a method for a terminal device communicating with a base station device, in which, when a first timer expires and a first failure is not detected, a suspended source radio bearer is resumed based on a first setting being made in the terminal device, and the value of a first state variable of a PDCP entity of the source radio bearer is set to one or both of the value of a second state variable and the value of a third state variable of the PDCP entity.

[0366] (8) The method described in (7), wherein the first timer is a timer that is started when the terminal device receives an RRC reconnection message from the base station device, the RRC reconnection message including an information element that instructs a change of serving cell in an RRC connected state, and that causes the terminal device to re-establish an RRC connection when the first timer expires.

[0367] (9) The method according to (7) or (8), wherein the first failure is a radio link failure in the source's primary cell.

[0368] (10) A method according to (7), (8), or (9), wherein the first state variable is a state variable indicating a COUNT value of the PDCP SDU that is expected to be received next at the receiving side of the PDCP entity.

[0369] (11) The method according to (7), (8), (9), or (10), wherein the second state variable is a state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received at the receiving side of the PDCP entity and not yet delivered to the upper layer.

[0370] (12) The method according to (7), (8), (9), (10), or (11), wherein the third state variable is a state variable indicating the next COUNT value after the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity.

[0371] A program running on an apparatus according to one aspect of the present invention may be a program that controls a central processing unit (CPU) or the like to cause a computer to function so as to realize the functions of the above-described embodiment according to one aspect of the present invention. The program or information handled by the program is temporarily loaded into a volatile memory such as a random access memory (RAM) during processing, or stored in a nonvolatile memory such as a flash memory or a hard disk drive (HDD), and is read, modified, or written by the CPU as needed.

[0372] Note that a part of the device in the above-described embodiment may be realized by a computer. In this case, a program for realizing this control function may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read by a computer system and executed to realize the control function. The "computer system" here refers to a computer system built into the device, including hardware such as an operating system and peripheral devices. Furthermore, the "computer-readable recording medium" may be any of a semiconductor recording medium, an optical recording medium, a magnetic recording medium, etc.

[0373] Furthermore, the term "computer-readable recording medium" may also include a medium that dynamically stores a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, or a medium that stores a program for a fixed period of time, such as volatile memory within a computer system that serves as a server or client in such cases. The program may also be one that realizes part of the above-mentioned functions, or one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

[0374] Furthermore, each functional block or feature of the device used in the above-described embodiments may be implemented or performed by an electrical circuit, typically an integrated circuit or multiple integrated circuits. The electrical circuit designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each of the aforementioned circuits may be composed of digital circuits or analog circuits. Furthermore, if advances in semiconductor technology result in the emergence of integrated circuit technologies that can replace current integrated circuits, integrated circuits based on that technology may also be used.

[0375] The present invention is not limited to the above-described embodiment. Although an example of a device has been described in the embodiment, the present invention is not limited to this and can be applied to terminal devices or communication devices such as stationary or non-movable electronic devices installed indoors or outdoors, for example, AV equipment, kitchen equipment, cleaning / washing equipment, air conditioning equipment, office equipment, vending machines, and other household appliances.

[0376] Although the embodiments of the present invention have been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and design modifications and the like are also included within the scope of the gist of the present invention. Furthermore, various modifications of one aspect of the present invention are possible within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. Furthermore, configurations in which elements described in the above embodiments are substituted with elements that achieve the same effect are also included. [Industrial Applicability]

[0377] One aspect of the present invention can be used in, for example, a communication system, a communication device (for example, a mobile phone device, a base station device, a wireless LAN device, or a sensor device), an integrated circuit (for example, a communication chip), or a program. [Explanation of symbols]

[0378] 100 E-UTRA 102 eNB 104 EPC 106 NR 108 gNB 110 5GC 112, 114, 116, 118, 120, 124 Interface 122UE 200, 300 PHY 202, 302 MAC 204, 304 RLC 206, 306 PDCP 208, 308 RRC 310 SDAP 210, 312 NAS 500,604 Receiver 502, 602 Processing section 504, 600 Transmitter

Claims

1. A terminal device that communicates with a base station device, When a first timer expires and a first failure is not detected, based on a first setting being configured in the terminal device, resuming a suspended source radio bearer and setting the value of a first state variable of a PDCP entity of the source radio bearer to one or both of the value of a second state variable and the value of a third state variable of the PDCP entity; The first timer is a timer that is started when the terminal device receives, from the base station device, an RRC reconnection message including an information element instructing a change of serving cell in an RRC connected state, and that causes the terminal device to re-establish an RRC connection when the first timer expires; the first failure is a radio link failure in a source primary cell; The first state variable is a state variable indicating a COUNT value of a PDCP SDU that is expected to be received next at the receiving side of the PDCP entity. Terminal device.

2. The second state variable is a state variable indicating a COUNT value of a first PDCP PDU among PDCP SDUs waiting to be received and not yet delivered to an upper layer at a receiving side of the PDCP entity. The terminal device according to claim 1 .

3. The third state variable is a state variable indicating a COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity. The terminal device according to claim 1 or 2.

4. A method for a terminal device communicating with a base station device, comprising: When a first timer expires and a first failure is not detected, based on a first setting being configured in the terminal device, resuming a suspended source radio bearer and setting the value of a first state variable of a PDCP entity of the source radio bearer to one or both of the value of a second state variable and the value of a third state variable of the PDCP entity; The first timer is a timer that is started when the terminal device receives, from the base station device, an RRC reconnection message including an information element instructing a change of serving cell in an RRC connected state, and that causes the terminal device to re-establish an RRC connection when the first timer expires; the first failure is a radio link failure in a source primary cell; The first state variable is a state variable indicating a COUNT value of a PDCP SDU that is expected to be received next at the receiving side of the PDCP entity. method.

5. The second state variable is a state variable indicating a COUNT value of a first PDCP PDU among PDCP SDUs waiting to be received and not yet delivered to an upper layer at a receiving side of the PDCP entity. The method of claim 4.

6. The third state variable is a state variable indicating a COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity.

6. The method according to claim 4 or 5.

Images