JP7739265B2 - Terminal device, method, and integrated circuit - Google Patents

Description

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

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

In addition, 3GPP is conducting technical studies and standardization of LTE-Advanced Pro, an extension of LTE, and NR (New Radio technology), a new radio access technology, as radio access methods and wireless network technologies for fifth-generation cellular systems (Non-Patent Document 1). 5GC (5 Generation Core Network), a core network for fifth-generation cellular systems, is also being studied (Non-Patent Document 2).

3GPP RP-170855, “Work Item on New Radio (NR) Access Technology” 3GPP TS 23.501 v15.3.0, “System Architecture for the 5G System; Stage 2” 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” 3GPP TS 36.331 v15.4.0, “Evolved Universal Tertrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol "specifications" 3GPP TS 36.323 v15.3.0, “Evolved Universal Tertrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) "specification" 3GPP TS 36.322 v15.3.0, “Evolved Universal Tertrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol "specification" 3GPP TS 36.321 v15.3.0, “Evolved Universal Tertrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol "specification" 3GPP TS 37.340v 15.3.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-Connectivity; Stage 2” 3GPP TS 38.300v 15.3.0, “NR; NR and NG-RAN Overall description; Stage 2” 3GPP TS 38.331 v15.4.0, “NR; Radio Resource Control (RRC); Protocol specifications” 3GPP TS 38.323 v15.3.0, “NR; Packet Data Convergence Protocol (PDCP) specification” 3GPP TS 38.322 v15.3.0, “NR; Radio Link Control (RLC) protocol specification” 3GPP TS 38.321 v15.3.0, “NR; Medium Access Control (MAC) protocol specification” 3GPP TS 23.401 v15.0.0, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access” 3GPP TS 23.502 v15.3.0, “Procedure for 5G System; Stage 2” 3GPP TS 37.324 v15.1.0, “NR; Service Data Adaptation Protocol (SDAP) specification” 3GPP Draft_Report_v1. doc, “Report of 3GPP TSG RAN2#105 meeting, Athens, Greece” http://www. 3gpp. org/ftp/TSG_RAN/WG2_RL2/TSGR2_105/Report/Draft_Report_v1. zip 3GPP RP-181544, “Revised WID: Even further mobility enhancement in E-UTRAN” 3GPP RP-181433, “New WID: NR mobility enhancements” 3GPP R2-1901364, “Detail for non-split bearer option for simultaneous connectivity” 3GPP TS 33.401 v15.9.0, “3GPP System Architecture Evolution (SAE); Security architecture” 3GPP TS 33.501 v15.6.0, “Security architecture and procedures for 5G System”

As part of the LTE technical studies, mechanisms to further extend existing LTE mobility extension technologies are being considered. Furthermore, in NR technical studies, mechanisms to extend existing NR mobility technologies are also being considered (Non-Patent Documents 18 and 19). These studies primarily include studies of Reduce User Data Interruption (RUDI), a technology that reduces interruptions in the transmission and reception of user data to close to 0 ms when a base station device and a terminal device move between connected cells (during handover), as well as studies of handover robustness improvements.

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

One aspect of the present invention has been made in consideration of the above-mentioned circumstances, and one of its objectives is to provide a terminal device, method, and integrated circuit that can efficiently control mobility.

In order to achieve the above object, one aspect of the present invention provides the following: a terminal device communicating with a base station device, 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.

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.

In addition, these comprehensive or specific aspects may be realized as a system, device, method, integrated circuit, computer program, or recording medium, or as any combination of a system, device, method, integrated circuit, computer program, and recording medium.

According to one aspect of the present invention, a terminal device can achieve efficient mobility processing.

1 is a schematic diagram of a communication system according to each embodiment of the present invention. A protocol stack diagram of the UP and CP of a terminal device and a base station device in E-UTRA in each embodiment of the present invention. Protocol stack diagram of UP and CP of a terminal device and base station device in NR in each embodiment of the present invention. FIG. 10 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. 2 is a block diagram showing the configuration of a terminal device according to each embodiment of the present invention. FIG. 2 is a block diagram showing the configuration of a base station device according to each embodiment of the present invention. 1 shows an example of processing related to handover in EUTRA in each embodiment of the present invention. An example of processing related to handover in NR in each embodiment of the present invention. 4 shows an example of conditions for starting and stopping each timer according to an embodiment of the present invention. 10 is an example of a mobilityControlInfo information element according to an embodiment of the present invention. 10 is another example of the mobilityControlInfo information element according to an embodiment of the present invention. 10 is an example of a synchronization-attached reconfiguration information element according to an embodiment of the present invention. 10 is another example of a synchronization-attached reconfiguration information element according to an embodiment of the present invention. An example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in an NR according to an embodiment of the present invention. 1 shows an example of an ASN.1 description included in a message relating to re-establishment of an RRC connection in E-UTRA according to an embodiment of the present invention. FIG. 4 is a diagram showing an example of the flow of processing A according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of the flow of processing B according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of the flow of processing C according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of the flow of processing H according to the embodiment of the present invention. 1 shows an example of an ASN.1 description indicating a parameter for setting whether or not to apply make-before-break handover to a radio bearer in each embodiment of the present invention. 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. FIG. 10 is a diagram showing another example of the flow of process E in the embodiment of the present invention. FIG. 10 is a diagram showing another example of the flow of process B according to the embodiment of the present invention. FIG. 10 is a diagram showing another example of the flow of the process LA according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a processing method of a UE 122 in each embodiment of the present invention. FIG. 10 is a diagram showing another example of a processing method of UE 122 in each embodiment of the present invention. FIG. 10 is a diagram showing yet another example of a processing method of UE 122 in each embodiment of the present invention.

The following describes in detail the embodiments of the present invention with reference to the drawings.

LTE (and LTE-A Pro) and NR may be defined as different radio access technologies (Radio Access Technology: RAT). NR may also be defined as a technology included in LTE. LTE may also be defined as a technology included in NR. LTE that can connect 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. The following description will be given using terms related to LTE and NR, but this embodiment may also be applied to other technologies using other terminology. The term E-UTRA in this embodiment may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

Figure 1 is a schematic diagram of a communication system for each embodiment of the present invention.

E-UTRA100 is a radio access technology described in Non-Patent Document 3, etc., and is composed of cell groups (CGs) consisting of one or more frequency bands. eNB (E-UTRAN Node B) 102 is a base station device for E-UTRA100. EPC (Evolved Packet Core) 104 is a core network described in Non-Patent Document 14, etc., and was designed as a core network for E-UTRA100. Interface 112 is the 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.

NR106 is a radio access technology described in Non-Patent Document 9, etc., and is composed of cell groups (Cell Groups: CGs) consisting of one or more frequency bands. gNB (g Node B) 108 is the base station equipment of NR106. 5GC110 is a core network described in Non-Patent Document 2, etc., 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.

Interface 114 is an interface between eNB 102 and 5GC 110, interface 116 is an interface between gNB 108 and 5GC 110, interface 118 is an interface between gNB 108 and EPC 104, interface 120 is an interface between eNB 102 and gNB 108, and interface 124 is an interface between EPC 104 and 5GC 110. Interfaces 114, 116, 118, 120, and 124 may be interfaces that pass only CP, only UP, or both CP and UP. Furthermore, interfaces 114, 116, 118, 120, and 124 may not exist depending on the communication system provided by the telecommunications carrier.

UE122 is a terminal device compatible with any or all of E-UTRA100 and NR106. As described in Non-Patent Document 3 and any or all of Non-Patent Document 9, when UE122 connects to the core network via any or all of E-UTRA100 and NR106, a logical path called a radio bearer (RB) is established between UE122 and any or all of E-UTRA100 and NR106. The radio bearer used for CP is called a signaling radio bearer (SRB), and the radio bearer used for UP is called a data radio bearer (DRB). Each RB is assigned an RB identity (RB ID) to uniquely identify it. The RB identifier for an SRB is called an SRB identity (SRB ID), and the RB identifier for a DRB is called a DRB identity (DRB ID).

As described in Non-Patent Document 3, when the core network to which UE 122 is connected is EPC 104, each DRB established between UE 122 and any or all of E-UTRA 100 and NR 106 is further uniquely linked to each EPS (Evolved Packet System) bearer passing through 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.

As described in Non-Patent Document 9, when the core network to which UE 122 is connected is 5GC 110, one or more DRBs established between UE 122 and any or all of E-UTRA 100 and NR 106 are further linked to one of the PDU (Packet Data Unit) sessions established within 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.

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

Figure 2 is a protocol stack diagram of the 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.

Figure 2(A) is a protocol stack diagram of the UP used when UE122 communicates with eNB102 in E-UTRA100.

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

MAC 202 is a medium access control layer that maps various logical channels to various transport channels. 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. MAC 202 has functions such as controlling PHY 200 to perform discontinuous transmission/reception (DRX/DTX), executing random access procedures, notifying transmission power information, and performing HARQ control (Non-Patent Document 7).

RLC 204 is a radio link control layer that segments data received from the higher-level PDCP (Packet Data Convergence Protocol Layer) 206 (described later) and adjusts the data size so that lower layers can transmit the data appropriately. RLC 204 has three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). In TM, data received from higher layers is not segmented and no RLC header is added. In UM, data received from higher layers is segmented and an RLC header is added, but data retransmission control is not performed. AM divides data received from higher layers, adds an RLC header, and controls data retransmission. The retransmission control function may be a function for guaranteeing the QoS (Quality of Service) required for each data. When performing data retransmission control, information about undelivered data sent from the receiving side of the RLC to the transmitting side is called a status report. Also, an instruction to prompt a status report sent from the transmitting side of the RLC to the receiving side is called a poll. Note that data sent to lower layers using TM is sometimes called a TMD PDU, data sent to lower layers using UM is sometimes called a UMD PDU, and data sent to lower layers using AM is sometimes called an AMD PDU (Non-Patent Document 6).

PDCP 206 is a packet data convergence protocol layer for efficiently transmitting user data such as IP packets over wireless sections. PDCP 206 may have a header compression function that compresses unnecessary control information. PDCP 206 may also have a data encryption function. PDCP 206 may also have a reordering function (Non-Patent Document 5).

The data processed in MAC 202, RLC 204, and PDCP 206 are called MAC PDU (Protocol Data Unit), RLC PDU, and PDCP PDU, respectively. Data passed to MAC 202, RLC 204, and PDCP 206 from higher layers, or data passed to higher layers, are called MAC SDU (Service Data Unit), RLC SDU, and PDCP SDU, respectively. A segmented RLC SDU is called an RLC SDU segment.

In addition, 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). In addition, 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).

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

The CP protocol stack includes PHY 200, MAC 202, RLC 204, and PDCP 206, as well as RRC (Radio Resource Control layer) 208 and NAS (non-access strarum) 210. RRC 208 is a radio link control layer that performs processes such as establishing, re-establishing, suspending, and resuming RRC connections, as well as reconfiguring RRC connections, such as establishing, modifying, and releasing radio bearers (RBs) and cell groups, controlling logical channels, transport channels, and physical channels, and configuring handovers and measurements. The RBs may be divided into signaling radio bearers (SRBs) and data radio bearers (DRBs), and 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. Configuration of each RB may be performed between the eNB 102 and the RRC 208 of the UE 122. Furthermore, a portion of the RBs that is configured with the RLC 204 and a logical channel may be referred to as an RLC bearer (see Non-Patent Document 4). In addition, 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 the AS (Access Stratum) layer.

The functional classification of MAC 202, RLC 204, PDCP 206, and RRC 208 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 other layers.

Note that the IP layer, and the TCP (Transmission Control Protocol) layer (TCP layer), UDP (User Datagram Protocol) layer (UDP layer), and application layer (application layer) above the IP layer are upper layers (upper layers) of the PDCP layer (not shown). The RRC layer and NAS (non-access strarum) layer are also upper layers (not shown) of the PDCP layer. In other words, the PDCP layer is a lower layer (lower layer) of the RRC layer, NAS layer, IP layer, and the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, and application layer above the IP layer.

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

Figure 3(A) is a protocol stack diagram of the UP used when UE122 communicates with gNB108 in NR106.

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

Now let's explain the physical channels.

The following physical channels may be used in wireless communication between a terminal device and a base station device:

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)

PBCH is used to broadcast system information required by terminal devices.

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

The PDCCH is used to transmit (or carry) downlink control information (DCI) in downlink wireless communication (wireless communication from the base station device 3 to the terminal device). Here, one or more DCIs (which may also be referred to as DCI formats) are defined for transmitting downlink control information. That is, a field for the downlink control information is defined as a 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.

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: Channel State Information) used to indicate the state of the downlink channel. The uplink control information may also include a scheduling request (SR: Scheduling Request) used to request UL-SCH resources. The uplink control information may also include a hybrid automatic repeat request ACKnowledgement (HARQ-ACK).

The PDSCH may be used to transmit downlink data (DL-SCH: Downlink Shared CHannel) from the MAC layer. In the case of downlink, it is also used to transmit system information (SI) and random access responses (RAR).

The PUSCH may be used to transmit uplink data from the MAC layer (UL-SCH: Uplink Shared CHannel) or uplink data together with HARQ-ACK and/or CSI. 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 RRC messages) and MAC control elements. Here, the RRC signaling transmitted from the base station device on the PDSCH may be common signaling for multiple terminal devices within a cell. The RRC signaling transmitted from the base station device may also be dedicated signaling for a certain terminal device (also referred to as dedicated signaling). That is, UE-specific information may be transmitted using dedicated signaling for a certain terminal device. Also, the PUSCH may be used to transmit UE capabilities in the uplink.

The PRACH may be used to transmit random access preambles. The PRACH may also 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.

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

RLC 304 is a radio link control layer that segments data received from the higher-level PDCP (Packet Data Convergence Protocol Layer) 306 (described later) and adjusts the data size so that lower layers can transmit the data appropriately. RLC 304 has three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). In TM, data received from higher layers is not segmented and no RLC header is added. In UM, data received from higher layers is segmented and an RLC header is added, but data retransmission control is not performed. AM divides data received from higher layers, adds an RLC header, and controls data retransmission. The retransmission control function may be a function for guaranteeing the QoS (Quality of Service) required for each data. When performing data retransmission control, information about undelivered data sent from the receiving side of the RLC to the transmitting side is called a status report. Also, an instruction to prompt a status report sent from the transmitting side of the RLC to the receiving side is called a poll. Note that data sent to lower layers using TM is sometimes called a TMD PDU, data sent to lower layers using UM is sometimes called a UMD PDU, and data sent to lower layers using AM is sometimes called an AMD PDU (Non-Patent Document 12).

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 data encryption and data integrity protection functions. PDCP 306 may also have a reordering function (Non-Patent Document 11).

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

The data processed in MAC 302, RLC 304, PDCP 306, and SDAP 310 are referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU, respectively. Data passed to MAC 302, RLC 304, PDCP 306, and SDAP 310 from higher layers or data passed to higher layers is referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. A segmented RLC SDU is referred to as an RLC SDU segment.

In addition, to distinguish between data and control, the SDAP PDU may be called the SDAP DATA PDU (SDAP Data PDU) and the SDAP CONTROL PDU (SDAP Control PDU). In addition, to distinguish between data and control, the PDCP PDU may be called the PDCP DATA PDU (PDCP Data PDU) and the PDCP CONTROL PDU (PDCP Control PDU). In addition, to distinguish between data and control RLC PDUs, the RLC PDUs may be called RLC DATA PDUs and RLC CONTROL PDUs, respectively.

Figure 3 (B) is a protocol stack diagram of the CP used by UE122 in NR106 when communicating with gNB108 and AMF (Access and Mobility Management function), a logical node that provides functions such as authentication and mobility management.

The CP protocol stack includes PHY 300, MAC 302, RLC 304, and PDCP 306, as well as RRC (Radio Resource Control layer) 308 and NAS (non-access strarum) 312. RRC 308 is a radio link control layer that performs processes such as establishing, re-establishing, suspending, and resuming RRC connections, as well as reconfiguring RRC connections, such as establishing, modifying, and releasing radio bearers (RBs) and cell groups, controlling logical channels, transport channels, and physical channels, and configuring handovers and measurements. The RB may be divided into a signaling radio bearer (SRB) and a data radio bearer (DRB), and the SRB may be used as a path for transmitting an RRC message, which is control information. The DRB may be used as a path for transmitting user data. Each RB may be configured between the gNB 108 and the RRC 308 of the UE 122. In addition, the portion of the RB consisting of the RLC 304 and a logical channel may be called an RLC bearer (Non-Patent Document 10). In addition, 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 the AS (Access Stratum) layer.

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, and all may use the logical channel DCCH (Dedicated Control CHannel). SRB2 may be an SRB for NAS messages, and all may use the logical channel DCCH. SRB2 may also 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., and all may use the logical channel DCCH. Other SRBs may also be provided for other uses.

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.

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. The PDU layer may be a layer above the user plane of the AS layer. The RRC layer and NAS (Non Access Stratum) layer may also be layers above any or all of the SDAP layer and 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, and the TCP (Transmission Control Protocol) layer, the UDP (User Datagram Protocol) layer, and the application layer above the IP layer.

In each embodiment of the present invention, any or all of the following protocols 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 for media communication or media communication control, and codecs for various media.

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 also establish and/or configure the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer in accordance with RRC messages transmitted from the RRC layer of the base station device. The MAC layer (MAC layer), RLC layer (RLC layer), PDCP layer (PDCP layer), and SDAP layer (SDAP layer) may also be referred to as the MAC sublayer (MAC sublayer), RLC sublayer (RLC sublayer), PDCP sublayer (PDCP sublayer), and SDAP sublayer (SDAP sublayer), respectively.

Note that 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 also 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. Furthermore, each layer may contain one or more entities. Furthermore, the PDCP entity and RLC entity may be established, configured, and/or controlled for each radio bearer. Furthermore, the MAC entity may be established, configured, and/or controlled for each cell group. Furthermore, the SDAP entity may be established, configured, and/or controlled for each PDU session.

The PDCP layer or PDCP entity may use the COUNT value when performing encryption or integrity protection processing. The COUNT value may be composed 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 one 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 one each time the sequence number reaches its maximum value. Furthermore, 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 a state variable named RX_NEXT as 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 in this PDCP entity to generate a COUNT value for a received PDCP PDU. This may be the state variable named RX_HFN described in Non-Patent Document 5.

In the PDCP layer or the 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 PDU. Reordering may also include a process of delivering the stored PDCP SDUs to a higher layer in the order of the COUNT values when the COUNT value of a received PDCP DATA PDU is the COUNT value of the first PDCP SDU that has not yet been delivered to a higher layer. That is, in the reordering, if a PDCP data PDU having 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 passed to an upper layer only after all the lost PDCP data PDUs have been received and converted into PDCP SDUs. In the reordering, a reordering timer (a timer named t-Reordering described in Non-Patent Document 11 or Non-Patent Document 5) may be used to detect PDCP data PDU loss. In addition, some or all of the following state variables (A) to (F) may be used for the 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 a state variable named RX_NEXT as 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 the COUNT value for the 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 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 a 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 COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity, which 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.

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

Furthermore, as shown in FIG. 1, eNB 102, gNB 108, EPC 104, and 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, RRC 208 in FIG. 2 may be replaced with RRC 308 in FIG. 3. PDCP 206 in FIG. 2 may be replaced with PDCP 306 in FIG. 3. RRC 308 in FIG. 3 may include the functions of RRC 208 in FIG. 2. PDCP 306 in FIG. 3 may be PDCP 206 in FIG. 2. Furthermore, in E-UTRA 100, NR PDCP may be used as PDCP even when UE 122 communicates with eNB 102.

Next, we will explain the state transitions of UE 122 in LTE and NR. 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 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 UE 122 can transmit and/or receive unicast data. Furthermore, UE 122 may be in the RRC_INACTIVE state when the RRC connection is inactive (if UE 122 is connected to 5GC). If neither of these cases is true, UE 122 may be in the RRC_IDLE state.

Note that 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, UE 122 transitions to the RRC_IDLE state while retaining the UE's AS context and the identifier used for resumption (resumeIdentity). When UE 122 retains the UE's AS context, and the E-UTRAN has permitted the resumption of the RRC connection, and 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).

In other words, the definition of dormancy may be different for UE122 connected to EPC and UE122 connected to 5GC. Furthermore, all or part of the procedure for UE122 to return from dormancy may be different when UE122 is connected to EPC (when it is dormant in RRC_IDLE state) and when UE122 is connected to 5GC (when it is dormant in RRC_INACTIVE state).

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

The UE AS context held by UE122 may be information including all or part of the current RRC settings, current security context, PDCP state including ROHC (RObust Header Compression) state, C-RNTI (Cell Radio Network Temporary Identifier) used in the source PCell, cell identifier (cellIdentity), and physical cell identifier of the source PCell. Note that the UE AS context held by either or all of eNB102 and gNB108 may include the same information as the UE AS context held by UE122, or may include information different from the information contained in the UE AS context held by UE122.

The security context may be information that includes all or part of the encryption key 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.

Next, handover in LTE and NR will be explained. Handover may be a process in which UE 122 in an RRC connected state changes its serving cell. Handover may be performed when UE 122 receives an RRC message instructing a handover from eNB 102 and/or gNB 108. The RRC message instructing a handover may be a message regarding reconfiguration of the RRC connection including a parameter instructing a handover (for example, 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 (for example, MobilityFromEUTRACommand described in Non-Patent Document 4, or MobilityFromNRCommand described in Non-Patent Document 10). The conditions under which UE 122 can perform a handover may also include some or all of the following: AS security is activated, SRB2 is established, and at least one DRB is established.

Figure 4 is a diagram showing an example of the flow of procedures for various settings in RRC208 and/or RRC308 in each embodiment of the present invention. Figure 4 shows an example of the flow when an RRC message is sent from a base station device (eNB102 and/or gNB108) to a terminal device (UE122).

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 specific terminal device needs to perform a process, such as security settings, reconfiguring an RRC connection (radio bearer processing (establishment, modification, release, etc.), cell group processing (establishment, addition, modification, release, etc.), measurement settings, handover settings, etc.), or releasing the RRC connection state. The RRC message may also be used as a handover command to a different RAT. The RRC message contains 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 represented by ASN. It is described using a description method called Abstract Syntax Notation One (Abstract Syntax Notation One).

In Figure 4, the base station device then transmits the created RRC message to the terminal device (step S402).The terminal device then performs processing such as setting if necessary in accordance with the received RRC message (step S404).

Note that the creation of RRC messages is not limited to the above example, and may also be created for other purposes, as described in non-patent document 4 and non-patent document 10.

For example, the RRC message may be used to configure Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) as described in non-patent document 8.

Dual Connectivity (DC) may be a technology for performing data communication using the radio resources of both cell groups formed by two base station devices (nodes), i.e., the master cell group (MCG) formed by the master node (MN) and the secondary cell group (SCG) formed by the secondary node (SN). The master node and secondary node may also 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 Technology (RATs) by RAT, assigning them to UEs, and performing data communication using the radio resources of both the MCG and SCG. In MR-DC, the master node may be a base station having the main RRC functions related to MR-DC, such as adding a secondary node, establishing, modifying, and releasing an RB, adding, modifying, releasing an MCG, and handover, and the secondary node may be a base station having some of the RRC functions, such as modifying and releasing an SCG.

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 SCG. For example, in EN-DC (E-UTRA-NR Dual Connectivity), which is an MR-DC when the core network is EPC104 and the master node is eNB102 (also referred to as enhanced eNB102), or in NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity), which is an MR-DC when the core network is 5GC110 and the master node is eNB102, the E-UTRA RRC message described in Non-Patent Document 4 may be transmitted and received between eNB102 and UE122. In this case, the RRC message may include not only LTE (E-UTRA) configuration information but also the NR configuration information described in Non-Patent Document 10. Furthermore, the RRC message transmitted from eNB 102 to UE 122 may be transmitted from eNB 102 to UE 122 via gNB 108. This RRC message configuration is non-MR-DC, and eNB 102 (enhanced eNB) uses 5GC as a core network. It may also be used for E-UTRA/5GC (option 5 described in non-patent document 17).

Conversely, in the MR-DC described in Non-Patent Document 8, in NE-DC (NR-E-UTRA Dual Connectivity), which is the MR-DC when the core network is 5GC110 and the master node is gNB108, the NR RRC message described in Non-Patent Document 10 may be transmitted and received between gNB108 and UE122. 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 gNB108 to UE122 may be transmitted from gNB108 to UE122 via eNB102.

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.

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

Figure 14 is an example of an ASN.1 description representing any or all of the fields and information elements related to radio bearer configuration included in a message related to RRC connection reconfiguration in NR in Figure 4. Figure 15 is an example of an ASN.1 description representing any or all of the fields and information elements related to radio bearer configuration included in a message related to RRC connection reconfiguration in E-UTRA in Figure 4. In the ASN.1 examples in embodiments of the present invention, including but not limited to Figures 14 and 15, the notations <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 where there is no notation <Omitted> or <Omitted>. Note that the ASN.1 examples in embodiments of the present invention do not strictly follow the ASN.1 notation method, but represent an example of parameters of a message related to RRC connection reconfiguration in an embodiment of the present invention, and other names and notations may be used. Also, in the ASN.1 examples in embodiments of the present invention, the notations <Omitted> and <Omitted> are not part of the ASN.1 notation and indicate the omission of other information. Note that the ASN.1 examples in embodiments of the present invention do not strictly follow the ASN.1 notation method and represent an example of parameters of a message related to RRC connection reconfiguration in an embodiment of the present invention, and other names and notations may be used. In order to avoid complication of explanation, Example 1 shows only an example of main information closely related to one embodiment of the present invention. Note that parameters described in ASN.1 may not be distinguished as fields, information elements, etc., and may all be referred to as information elements. Also, in the embodiment of the present invention, parameters such as fields and information elements described in ASN.1 included in an RRC message may also be referred to as information. Note that the message related to the reconfiguration of the RRC connection may be an RRC reconfiguration message in NR or an RRC connection reconfiguration message in E-UTRA.

In Figure 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 the PDCP configuration information element and SDAP configuration information element described below. 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 be referred to as radio bearer configuration.

The information element represented by SRB-Identity in the SRB setting information element is information about 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 setting information element may also be referred to as the SRB identifier information element, radio bearer identifier information element, or signaling radio bearer identifier information element.

The information element represented by DRB-Identity in the DRB setting information element is 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 setting information element may also be referred to as the DRB identifier information element, radio bearer identifier information element, or data radio bearer identifier information element. In the example of Figure 14, the value of the DRB identifier is an integer value between 1 and 32, but it may also take on other values. In the case of DC, the DRB identifier is unique within the scope of UE122.

The information element represented by cnAssociation among the DRB configuration information elements may be an information element indicating whether to use EPC104 or 5GC110 as the core network, and may also be referred to as a core network association information element. That is, when UE122 connects to EPC, the DRB may be associated with the EPS bearer identifier information element (eps-BearerIdentity) in cnAssociation, or the EPS bearer identifier (EPS bearer identity) that is the value of the EPS bearer identifier information element, and when UE122 connects to 5GC110, the DRB may be associated with an SDAP entity configured in accordance with an SDAP configuration information element (sdap-Config) described below, or with a PDU session information element described below that is included in the SDAP configuration information element, or 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 settings when core network 5GC110 is used, i.e., when EN-DC is not used.

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 map when the core network is 5GC110, and may also be referred to as an SDAP configuration information element.

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.

The information element indicated by mappedQoS-FlowsToAdd included in the SDAP configuration information element may be information indicating a list of QoS flow identifier (QFI: QoS Flow Identity) information elements (described below) 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 additional QoS flow information elements. 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.

Furthermore, the information element indicated by mappedQoS-FlowsToRelease included in the SDAP configuration information element may be information indicating a list of QoS flow identifier (QFI: QoS Flow Identity) information elements (described below) of the QoS flows whose correspondence is to be released among the QoS flows that correspond (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, and may also 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.

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 to the PDU session.

In addition, the SDAP configuration 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 configured DRB, a downlink header information element indicating whether a downlink SDAP header is present in the downlink data received via the configured DRB, and a default bearer information element indicating whether the configured DRB is a default radio bearer (default DRB).

Furthermore, among the SRB configuration information elements and DRB configuration information elements, information elements represented as pdcp-Config or PDCP-Config may be information elements for configuring the NR PDCP entity to establish or change PDCP 306 for the SRB and/or DRB, and may also be referred to as PDCP configuration information elements. Information elements for configuring the NR PDCP entity may include information elements indicating the size of the uplink sequence number, information elements indicating the size of the downlink sequence number, information elements indicating the header compression (RoHC: RObust Header Compression) profile, reordering timer information elements, etc.

The information element represented by DRB-ToReleaseList contained in the information element represented by RadioBearerConfig may contain information indicating one or more DRB identifiers to be released.

In Figure 15, the information element represented by RadioResourceConfigDedicated may be an information element used for setting up, changing, releasing, etc. a radio bearer. The information element represented by SRB-ToAddMod, which is 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, which is included in the information element represented by RadioResourceConfigDedicated, 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 a radio bearer configuration.

The information element represented by SRB-Identity in the SRB configuration information element is information about 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 that has the same role as the information element represented by SRB-Identity in Figure 14.

The information element represented by DRB-Identity in the DRB configuration is 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 the DRB identifier information element, radio bearer identifier information element, or data radio bearer identifier information element. In the example of Figure 15, the value of the DRB identifier is an integer value between 1 and 32, but it may also take on other values. The information element represented by DRB-Identity in Figure 15 may be an information element that has the same role as the information element represented by DRB-Identity in Figure 14.

The information element represented by eps-BearerIdentity among the DRB configuration information elements may be an EPS bearer identifier that uniquely identifies an EPS bearer in each terminal device. The information element represented by eps-BearerIdentity is sometimes 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 the EPS bearer identifier and the DRB identifier in each terminal device.

Furthermore, among the SRB configuration information elements and DRB configuration information elements, information elements represented as pdcp-Config or PDCP-Config may be information elements related to the configuration of the E-UTRA PDCP entity for establishing or changing PDCP 206 for the SRB and/or DRB, and may also be referred to as PDCP configuration information elements. Information elements related to the configuration of the E-UTRA PDCP entity may include information elements indicating the size of the sequence number, information elements indicating the profile of header compression (RoHC: RObust Header Compression), reordering timer information elements, etc.

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

The information element represented by DRB-ToReleaseList contained in the information element represented by RadioResourceConfigDedicated may contain information indicating one or more DRB identifiers to be released.

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

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 additional serving cells (secondary cells, SCell) may be configured along with the primary cell.

A set of serving cells consisting of two subsets may also be configured for the terminal device. The two subsets may consist of 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.

This section describes an example of operation regarding a radio link failure (RLF) by an RRC-connected terminal device.

The terminal device obtains 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 RRC messages sent to individual users. The timer values and count thresholds may also be set to default values. The names of the timers may differ between EUTRA and NR.

For radio link monitoring, the physical layer processing unit of the terminal device notifies the RRC layer processing unit, which is a higher layer, of "out-of-sync" when the radio link quality of the serving cell is estimated to be worse than a specific threshold (Qout) for a specific period (e.g., _{TEvalue_Qout} =200 ms) 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. Furthermore, the physical layer processing unit notifies the RRC layer processing unit, which is a higher layer, of "in-sync" when the radio link quality of the serving cell is estimated to be worse than a specific threshold (Qin) for a specific period (e.g., _{TEvalue_Qin} =100 ms) 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. The physical layer processing unit may notify the upper layer of out-of-sync or in-sync at intervals of at least a specific interval (for example, TReport_sync=10 ms).

Here, for example, the threshold Qout may be defined as a level at which the downlink radio link cannot be reliably received and the block error rate of a hypothetical downlink control channel (PDCCH) transmission based on default parameters is a first specific rate. Furthermore, 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 the block error rate of a hypothetical downlink control channel transmission based on default parameters is a second specific rate. Furthermore, multiple block error rates (threshold Qout and threshold Qin levels) may be defined based on the frequency used, subcarrier spacing, service type, etc. Furthermore, the first specific rate and/or the second specific rate may be default values defined in the specifications. Furthermore, the first specific ratio and/or the second specific ratio may be values notified or broadcast from the base station device to the terminal device.

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

The radio link monitoring configuration may include information indicating the purpose of monitoring and identifier information indicating a reference signal. For example, the purpose of monitoring may include monitoring for radio link failure, monitoring for beam failure, or both. Furthermore, for example, the identifier information indicating the reference signal may include information indicating an identifier (SSB-Index) of the cell's synchronization signal block (SSB). In other words, 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.

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 also stop the timer (T310) when it receives a predetermined number (N311) of consecutive in-sync notifications. When the timer (T310) 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. For example, the operation of the terminal device may differ depending on the establishment status of AS Security. If AS Security is not established, the terminal device transitions to the RRC IDLE state, and if AS Security is established, the terminal device may perform an RRC connection re-establishment procedure. In addition, when determining whether to start or restart the timer T310, a condition may be added that none of the timers T300, T301, T304, and T311 are running.

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

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 an out-of-sync notification from the physical layer processing unit a predetermined number of times (N313 times) in succession. Furthermore, the RRC layer processing unit of the terminal device may stop the timer (T313) when it receives an in-sync notification a predetermined number of times (N314 times) in succession. 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.

In addition, in an SpCell (PCell in an MCG and PSCell in an SCG), the RRC layer processing unit of the terminal device may start (Start) or restart (Restart) the timer (T310) of each SpCell when it receives a predetermined number (N310) of consecutive out-of-sync notifications from the physical layer processing unit in each SpCell. Also, the RRC layer processing unit of the terminal device may stop (Stop) the timer (T310) of each SpCell when it receives a predetermined number (N311) of consecutive in-sync notifications in each SpCell. When the timer (T310) of each SpCell expires, the RRC layer processing unit of the terminal device may transition to an idle state or perform an RRC connection re-establishment procedure if the SpCell is a PCCell. Also, if the SpCell is a PSCell, it may execute an SCG failure information procedure to notify the network of an SCG failure.

The above explanation is an example of a case where discontinuous reception (DRX) is not configured in the terminal device. If DRX is configured in the terminal device, the RRC layer processing unit of the terminal device may set the period for measuring radio link quality and the interval for reporting to upper layers to values different from those when DRX is not configured in the physical layer processing unit. Note that even when DRX is configured, when the above timers (T310, T313) are running, the period for measuring radio link quality to estimate synchronization and the interval for reporting to upper layers may be set to the values when DRX is not configured.

Also, for example, to detect early physical layer problems, the RRC layer processing unit of the terminal device may start (Start) a timer (T314) when it receives a predetermined number (N310) of consecutive early out-of-sync notifications from the physical layer processing unit. Also, the RRC layer processing unit of the terminal device may stop (Stop) the timer (T314) when it receives a predetermined number (N311) of consecutive in-sync notifications while T314 is running.

Furthermore, for example, in order to detect early physical layer improvement, the RRC layer processing unit of the terminal device may start (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 (Stop) the timer (T315) when it receives a predetermined number (N311) of consecutive synchronization notifications while T315 is running.

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

Furthermore, the RLM-RS may be undefined if it is not explicitly or implicitly configured by the network. In other words, 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).

Furthermore, the RLM-RS is a reference signal used for radio link monitoring, and multiple RLM-RS 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).

Furthermore, radio link monitoring using CRS may be performed in EUTRA cells, and radio link monitoring using RLM-RS may be performed in NR cells, but this is not limited to this.

This paper describes detection of radio link failures based on radio link monitoring.

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 multiple 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 or timer T312.

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 being performed in an SpCell, the random access problem may be notified to a higher layer (here, the RRC entity) by the MAC entity of the cell group including the SpCell.

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 begins the process of leaving RRC_CONNECTED. If AS security is activated, it begins the RRC connection re-establishment procedure.

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 begins processing to report the related information to the base station device as an SCG radio link failure.

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

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

The procedure for re-establishing an RRC connection is described below.

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

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 a handover fails (in NR, when synchronized reconfiguration in the MCG fails).
(C) When mobility to another RAT fails; (D) When an integrity check failure related to SRB1 or SRB2 is notified from a lower layer; (E) When re-establishment of the RRC connection fails.

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) Release SCell for MCG, if configured. (H) Apply default physical channel configuration. (I) Apply default MAC primary configuration for MCG. (J) Perform cell selection procedure.

When the optimal cell of the same RAT is selected through the cell selection procedure, the terminal device performs the following processing.

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 the action of leaving RRC_CONNECTED with the release reason set to "RRC connection failure". Otherwise, stop timer T311, start timer T301, and start sending an RRC connection re-establishment request message.

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

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

Explain handover.

An example of processing related to handover between the same RATs (i.e., between EUTRAs) in EUTRA will be described using Figure 7. The description using Figure 7 is just one example, and some processing may be omitted or other processing may be included. Alternatively, other processing may be performed as handover processing.

In Figure 7, the base station device (Source eNB) from which the handover is initiated configures (Configures) the terminal device to measure neighboring cells (step S701).

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

The Source eNB decides to handoff the terminal device based on information such as reported measurement results (step S703).

The Source eNB issues a handover request message to the base station device (Target eNB) to which the handover will be performed, containing information necessary to prepare for the handover (step S704).

Admission control may be performed by the Target eNB. The Target eNB configures the required resources (step S705).

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 sent transparently 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, the Target eNB's security algorithm identifier for the selected security algorithm, a dedicated random access channel preamble (random access preamble), and system information of the target cell.

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).

Note that if a make-before-break handover (MBB-HO) is configured by the first RRC connection reconfiguration message, the terminal device maintains its connection with the source eNB from the time it receives the first RRC connection reconfiguration message until at least the first uplink transmission is performed by the target eNB. Note that the make-before-break handover may be selected from multiple settings. For example, it may be determined that a make-before-break handover has been configured by setting the field makeBeforeBreak-r14 included in the mobilityControlInfo information element, which has already been specified, to true. Also, for example, a newly defined makeBeforeBreak-r16 may be included in a field of the mobilityControlInfo information element, and when the makeBeforeBreak-r16 is set to true, it may be determined that a make-before-break handover has been set. Also, the field makeBeforeBreak-r16 may have an information element containing various settings as a value.

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).

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 the 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; 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).

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

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 terminal device receives an uplink grant via the target cell's PDCCH. The terminal device uses the first available uplink grant after synchronizing with the target cell (step S710a).

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 terminal device's handover procedure. The RRC connection reconfiguration complete message includes the C-RNTI, and the target eNB verifies the C-RNTI in the received RRC connection reconfiguration complete message.

When 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. The handover procedure for the terminal device is completed when the terminal device receives a UE contention resolution identity MAC control element (UE contention resolution identity MAC control element) from the target eNB (step S711).

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

The MME sends a MODIFY BEARER REQUEST message to the serving gateway (S-GW) (step S713).

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).

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

The MME acknowledges the path switching request with a PATH SWITCH REQUEST ACKNOWLEDGE message (step S716).

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. The Target eNB may send this message after receiving the Path Switch Request Acknowledgement message (step S717).

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

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

Details of the processing of a terminal device that receives a first RRC connection reconfiguration message are described below. 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).

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) included 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 that timer. (G) Start synchronization to the downlink of the target cell.

An example of processing related to handover between the same RATs (i.e., between NRs) in NR is explained using Figure 8. The explanation using Figure 8 is just one example, and some processing may be omitted or other processing may be included. Alternatively, other processing may be performed as handover processing.

In Figure 8, the base station device (Source gNB) from which the handover is initiated 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).

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

The Source gNB issues a handover request message to the base station device (Target gNB) to which the handover is to be performed, containing information necessary to prepare for the handover (step S803).

Admission control may be performed by the Target gNB (step S804).

The Target gNB prepares for handover and sends a handover request acknowledgement message (HANDOVER REQUEST ACKNOWLEDGE message) to the Source gNB (step S805). 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 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: the target cell identifier, the new C-RNTI, the target gNB's security algorithm identifier for the selected security algorithm, the set of dedicated random access channel resources, the UE-specific CSI-RS configuration, the common random access channel resources, and the target cell's system information.

In addition, if a make-before-break handover (Make-Before-Break HO: MBB-HO) is configured by the first RRC reconfiguration message, the terminal device may maintain a connection with the source gNB from the time it receives the first RRC reconfiguration message until at least the first uplink transmission is performed by the target gNB.

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).

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 the random access channel. At this time, if a dedicated random access preamble is indicated by 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.

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.

If 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 terminal device receives the uplink grant via the target cell's PDCCH. The terminal device uses the first available uplink grant after synchronizing with the target cell.

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 terminal device's handover procedure. The RRC reconfiguration complete message includes the C-RNTI, and the target gNB may verify the C-RNTI in the received RRC reconfiguration complete message.

When 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. The handover procedure for the terminal device may be completed when the terminal device receives a UE contention resolution identity MAC control element from the target gNB (step S808).

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

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).

The AMF confirms the path switching request with a PATH SWITCH REQUEST ACKNOWLEDGE message (step S811).

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).

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

Details of the processing of a terminal device that receives a first RRC reconfiguration message are described below. 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 involving synchronization to the target SpCell (e.g., the target SpCell configuration, a new identifier for the terminal device, etc.).

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 timer T310 of the target SpCell is running, stop 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) Start synchronization to the downlink of the target cell.

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 the Source eNB or Source gNB until the first uplink transmission is performed with the Target eNB or Target gNB, or for any period of time. Currently, timer T310 stops when the first RRC connection reconfiguration message or the first RRC reconfiguration message is received. Therefore, the terminal device cannot determine whether the serving cell (source cell) of the Source eNB or Source gNB subsequently experiences a situation 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 the serving cell (source cell) of the Source eNB or Source gNB is in a situation where it is considered to have experienced a radio link failure due to a random access problem notified from the MAC layer. Furthermore, in the source cell, if the number of retransmissions in the RLC reaches the maximum number, it is considered to have experienced a radio link failure, and an RRC connection re-establishment procedure is executed.

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 Target gNB performs the first uplink transmission, or for any period of time. Therefore, Make-Before-Break Handover (MBB-HO) may also be referred to as DAPS (Dual Active Protocol Stack) 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, or two MAC entities for the source and target may be configured. Furthermore, some or all of the confidentiality keys, integrity keys, RoHC protocols, RLC bearers, and MAC bearers configured for the source and target may be used simultaneously or alternately during a handover using DAPS. Hereinafter, make-before-break handover (MBB-HO) may be read as DAPS handover.

Furthermore, in the following, "make before break handover is applied" may mean that DAPS handover is applied. Furthermore, "make before break handover (MBB-HO) is set in a terminal device" may mean that DAPS handover is set in the terminal device. Furthermore, "make before break handover (MBB-HO) is set in a terminal device (DAPS handover is set)" may mean that MBB-HO (DAPS handover) is applied to any radio bearer set in the terminal device, or that MBB-HO (DAPS handover) is applied to at least one of the radio bearers set in the terminal device.

Next, we will explain conditional handover. In NR, conditional handover may be RRC reconfiguration using an RRC reconfiguration message that includes an information element (conditional handover configuration) that includes information contained in a synchronized reconfiguration information element, and information indicating the conditions for applying that information element (conditional handover conditions). In LTE, conditional handover may be RRC connection reconfiguration using an RRC connection reconfiguration message that includes an information element (conditional handover configuration) that includes information contained in a mobility control information information element, and information indicating the conditions for applying that information element (conditional handover conditions).

In NR, conditional handover settings may include some or all of the settings (A) to (F) below.
(A) Cell group configuration information (CellGroupConfig)
(B) Information indicating whether or not the configuration is full; (C) Messages of the NAS layer; (D) System information; (E) Measurement configuration; (F) Radio bearer configuration.

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 of the cell group (4) Physical (PHY) layer configuration information of the cell group (5) SpCell configuration information (a synchronized reconfiguration information element may be included)
(6) SCell information

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 on the integrity protection algorithm and encryption algorithm for the SRB and/or DRB (securityAlgorithmConfig), information indicating whether to use the master (MCG) or secondary (SCG) key (keyToUse), etc.)

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

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 of the cell group (4) Physical (PHY) layer configuration information of the cell group

In LTE and/or NR, conditional handover conditions may include some or all of the following conditions (A) to (D):
(A) The target cell becomes better than the current (source) PC cell plus an offset. (B) The target cell becomes better than a certain threshold and the PC cell becomes worse than another threshold. (C) The target cell becomes better than a certain threshold. (D) No condition (execute immediately).

RSRP, RSRQ, and/or RS-SINR may be used as the quantity for comparison in the above conditional handover conditions. The quantity to be used may be set by the network. Information indicating the quantity to be used may also be included in the conditional handover conditions.

Information elements indicating the conditional handover settings and/or the conditional handover conditions may be included as part of an RRC message at the handover source, or may be stored in a container (an information element storing a bit string) included in the RRC message.

Based on the above explanation, 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 explanation.

An example of performing MBB-HO efficiently by changing the procedures for radio link monitoring in MBB-HO is shown.

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

The RRC layer processing unit of the UE 122 determines that a radio link failure has been detected in the MCG when any of the following conditions (A) to (E) is satisfied.
(A) When timer T310 expires. (B) When timer T312 expires. (C) When a notification of a random access problem is received from the MAC entity of the MCG when none of timers T300, T301, T304, and T311 is running. (D) When a notification of a random access problem is received from the MAC entity of the MCG when timer T304 is running under the first condition. (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.

The first condition may be that makeBeforeBreak-r16 is configured in UE122. For example, in the case of EUTRA, makeBeforeBreak-r16 may be configured when UE122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in a field of the mobilityControlInfo information element. Furthermore, for example, in the case of NR, makeBeforeBreak-r16 may be configured when UE122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in a field of the synchronized reconfiguration information element. Furthermore, makeBeforeBreak-r16 not being set means, for example, in the case of EUTRA, UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is not included in the mobilityControlInfo information element field. Also, makeBeforeBreak-r16 not being set means, for example, in the case of EUTRA, UE 122 receives an RRC connection reconfiguration message including makeBeforeBreak-r16 having a value of false. Also, makeBeforeBreak-r16 not being set means, for example, in the case of NR, receiving an RRC reconfiguration message in which makeBeforeBreak-r16 is not included in the synchronized reconfiguration information element field.

Furthermore, "makeBeforeBreak-r16 being set" may mean, for example, in the case of EUTRA, that UE122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in the terminal device-specific radio resource configuration (radioBearerConfigDedicated) information element. Furthermore, "makeBeforeBreak-r16 being set" may mean, for example, in the case of NR, that UE122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in the field of the data radio bearer configuration information element.

makeBeforeBreak-r16 may, for example, have an enumerated value including true, or may have an information element containing information required for make-before-break handover as its value.

Furthermore, 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.

When UE122 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 may set the release reason to "Other" and begin the process of leaving RRC_CONNECTED.

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

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

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 when the first condition is not met. (B) When a handover fails (in NR, when synchronized reconfiguration in the MCG fails).
(C) When mobility to another RAT fails; (D) When an integrity check failure related to SRB1 or SRB2 is notified from a lower layer; (E) When re-establishment of the RRC connection fails.

Furthermore, when any of the above conditions is met, if the first condition is met and a radio link failure has not been detected in the MCG from which the handover originates, the RRC connection re-establishment procedure may not be initiated, and a procedure for notifying the MCG from which the handover originates of the handover failure may be initiated.

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 MCG of the handover source.

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) Release SCell for MCG, if configured. (H) Apply default physical channel configuration. (I) Apply default MAC primary configuration for MCG. (J) Perform cell selection procedure.

Next, a case is being considered in which, after UE122 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 the Target MCG or Current MCG) and the handover source MCG (Source MCG) cell groups (when operating in a dual protocol stack). An example of the processing in this case is shown below. Note that the following processing is not limited to the dual protocol stack case and can also be applied to other cases.

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

The RRC layer processing unit of the UE 122 determines that a radio link failure has been detected in the Source MCG when any one 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) When a notification (indication) of a random access problem is received from the MAC entity of the Source MCG when none of timers T300, T301, T304, and T311 of the Source MCG is running. (D) When a notification of a random access problem is received from the MAC entity of the Source MCG when timer T304 of the Source MCG is running under the first condition. (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.

The first condition may be that makeBeforeBreak-r16 is set on UE122.

The first condition may also be that either makeBeforeBreak-r14 or makeBeforeBreak-r16 is set on UE122.

Furthermore, 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.

If 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.

When makeBeforeBreak-r16 is set in the Current MCG, UE122 may consider that MCG to be the Source MCG.

In addition, UE122 may consider the MCG from which the handover originated to be the Source MCG when the first uplink grant is allocated by the PDCCCH in the target cell.

Also, when UE122 sends an RRC reconfiguration complete message, it may consider the MCG from which the handover is made to be the Source MCG.

Furthermore, when UE122 receives a UE contention resolution identity MAC control element from the Target gNB, it may consider the MCG from which the handover is originated to be the Source MCG.

In addition, if a Source MCG already exists when makeBeforeBreak-r16 is set in the Current MCG, UE122 may release this MCG and consider the Current MCG as the new Source MCG.

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.

An example of MBB-HO operation is described below. Here, an example is shown in which NR uses an RRC reconfiguration message that includes a CellGroupConfig containing a synchronization-attached reconfiguration information element. Note that although the descriptions of each process below refer to receiving information elements, 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 correspond to the information elements used in non-patent document 10.

The terminal device performs process A based on the received CellGroupConfig information element. The terminal device also performs process L based on the received masterKeyUpdate information element. The terminal device also performs process I based on the received RadioBearerConfig information element.

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

(Processing A) Based on the received CellGroupConfig information element, the following processing 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 (for example, MakeBeforeBreak-r16),
(A-0-1) The current terminal device configuration (source configuration) is duplicated to become 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 process may be considered to be the "target configuration of the current terminal device." Furthermore, for example, the configuration to be duplicated 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, each entity configuration, etc.), (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 bearer configuration to be duplicated may not include the SRB-related configuration. That is, for the DRB, both the source setting and the target setting may be managed, and for the SRB, the setting may be switched from the source setting to the target setting without duplicating the setting. Also, information that can determine whether to duplicate the SRB setting 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 includes SpCell configuration information (spCellConfig information element) including synchronized reconfiguration information, then: (A-1-1) Execute processing 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 includes a list of RLC bearers to be released (rlc-BearerToReleaseList information element), then: (A-2-1) Execute processing C, which will be described later.
(A-3) If CellGroupConfig includes 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 processing E 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 includes a list of SCells to be released (sCellToReleaseList information element), (A-5-1) execute the release of SCells in process F described below.
(A-6) If CellGroupConfig includes SpCell configuration information (spCellConfig information element),
(A-6-1) SpCell is set in process G, which will be described later.
(A-7) If CellGroupConfig includes a list of SCells to be added and/or modified (sCellToAddModList information element), (A-7-1) perform the addition and/or modification of SCells in process H described below.

(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 a physical cell identifier indicated by the physical cell identifier information (physCellId) included in the synchronized reconfiguration, at the SSB frequency indicated by frequencyInfoDL.
(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 re-establishment includes information indicating MBB-HO,
(B-9-1) If there is no MAC entity in the target cell group,
(B-9-1-1) Create a MAC entity for the target cell group (also simply referred to as a target MAC entity).
(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) Apply the value of newUE-Identity 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 layer based on other information included in the synchronized reconfiguration.

(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.

(Process D)
The following processing is performed for each RLC bearer setting (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 re-establishment of RLC (reestablishRLC) is received,
(D-1-1-1) Re-establish the RLC entity. (D-1-2) Re-configure the RLC entity according to the received RLC configuration (rlc-Config).
(D-1-3) Reconfigure the logical channel 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 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) This logical channel is associated with the PDCP entity based on the radio bearer identifier information (servedRadioBearer) included in the RLC bearer configuration.

(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 identifiers of the tags included in the tag-ToReleaseList are part of the current terminal device settings, 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 a TAG (tag-ToAddModList),
(E-4-1) If the identifiers of the TAGs included in the 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 the tag-ToAddModList are part of the current terminal device configuration, for each TAG identifier,
(E-4-2-1) Re-set the tag corresponding to the tag identifier according to the received timing advance timer.

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

(Process G)
(G-1) If the SpCell configuration includes information on 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 the SpCell according to spCellConfigDedicated.
(G-3-2) If the BWP indicated by the identifier (firstActiveUplinkBWP-Id) of the first active uplink BWP (Bandwidth part) is set, the BWP is considered to be the active uplink BWP.
(G-3-3) If the BWP indicated by the identifier (firstActiveDownlinkBWP-Id) of the first active downlink BWP (Bandwidth part) is set, the 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.

(Process H)
(H-1) For each sCellIndex value included in the sCellToAddModList that is not part of the current terminal device configuration,
(H-1-1) Add the SCell corresponding to the sCellIndex.
(H-1-2) Configure the lower layers to consider the SCell to be in a deactivated state.
(H-1-3) For each measurement identifier in the list of measurement identifiers (measIdList) of the variable (VarMeasConfig) that holds 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) Remove this SCell from the list of triggered cells (cellsTriggeredList) defined in 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 the SCell corresponding to the sCellIndex.

(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) Release the DRB 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.

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

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

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 mean 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 mean that the random access procedure is successful. Detecting a certain request may mean that the random access procedure is successful in either or both of the following cases: (A) when synchronized reconfiguration is included in SpCellConfig, or (B) when the random access procedure is triggered by the RRC entity submitting to a lower layer a message notifying the 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 mean something detected by the implementation of the terminal device.

(Process J)
(J-1a) for each DRB identifier included in the drb-ToReleaseList that is part of the current terminal device 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 an 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 upper layers of the release of the DRB and the EPS bearer identifier of the released DRB.

In the case of MBB-HO, if no new bearer is 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 synchronized reconfiguration, and until a message (e.g., an RRC message, MAC CE, etc.) to release the source configuration is received in the target cell, if the same EPS bearer is associated with a 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 a message to release 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.

(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 device connects only to E-UTRA / 5GC,
(K-1-2-1-1) Configure the 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 an encryption algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameter (keyToUse) linked to the master key (KeNB or KgNB) or the 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 an integrity protection algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameter (keyToUse) linked to the master key (KeNB or KgNB) or the secondary key (S-KgNB).
(K-1-4) If the SDAP setting (sdap-config) is included,
(K-1-4-1) If the SDAP of the received PDU session does not exist,
(K-1-4-1-1) Establish an SDAP entity.
(K-1-4-1-2) If the SDAP of the received PDU session did not exist prior to receiving this re-establishment,
(K-1-4-1-2-1) Notify upper layers of the establishment of user plane resources for that 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 a DRB was configured by NR or E-UTRA with the same EPS bearer ID 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 upper layers 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 device 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 the 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 an encryption algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameter (keyToUse) linked to the master key (KeNB or KgNB) or the 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 an integrity protection algorithm according to the security configuration (securityConfig) and apply the key indicated by the parameter (keyToUse) linked to the master key (KeNB or KgNB) or the 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.

In the process K-1-4-1-2, 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 layer may be notified of the establishment of user plane resources for that PDU session. Alternatively, in the process K-1-4-1-2, 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 layer may be notified of the establishment of user plane resources for that PDU session.

In the process K-1-5-2, in the case of MBB-HO, if the DRB was not configured by NR or E-UTRA with the same EPS bearer identifier in either the source configuration or the 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 process K-1-5-2, in the case of MBB-HO, if the DRB was not configured by NR or E-UTRA with the same EPS bearer identifier 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.

(Processing L)
(L-1) If the terminal device 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) Generate (derive) the KRRCenc key and the KUPenc key. The KRRCenc key is a key used to protect the RRC signal generated from the KgNB using an encryption algorithm. Also, the KUPenc key is a key used to protect the user plane traffic (user data) generated from 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 a key used to protect the RRC signal generated from the KgNB using the integrity algorithm. The KUPint key is a key used to protect the user plane traffic (user data) generated from 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) Create 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 includes 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 linked to the integrityProtAlgorithm included in the securityAlgorithmConfig from the KgNB key.
(L-1-6-2) Otherwise,
(L-1-6-2-1) Generate 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.

An example of MBB-HO operation is described below. Here, an example is shown in which an RRC connection reconfiguration message containing a mobility control information (mobilityControlInfo) information element is used in LTE. Note that although there are descriptions of each process below that refer to receiving an information element, 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 correspond to the information elements used in non-patent document 4.

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

(Processing LA)
(LA-1) Starts timer T304 using the timer value t304 included in mobilityControlInfo.
(LA-2) If carrierFreq is included,
(LA-2-1) The cell whose physical cell identifier on the frequency indicated by carrierFreq is indicated by targetPhysCellId is considered to be the target PCell.
(LA-3) Otherwise,
(LA-3-1) The cell whose physical cell identifier on the frequency of the source PCell is indicated by targetPhysCellId is considered to be the target PCell.
(LA-4) Start synchronization to the downlink of the target PCell.
(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) is duplicated to become the target configuration, and the subsequent reconfiguration process 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 configuration to be duplicated 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 bearer configuration to be duplicated may not include the SRB configuration. That is, for DRB, both the source setting and the target setting may be managed, and for SRB, the setting may be switched from the source setting to the target setting without duplicating the setting. Also, information that can determine whether to duplicate the SRB setting may be included in an RRC connection reconfiguration message including mobilityControlInfo. For example, the information may be included in MakeBeforeBreak-r16.
(LA-7) If set, reset the MAC of the MCG and the MAC of the SCG. If MakeBeforeBreak-r16 is set, the MAC of the source MCG and the MAC of the SCG may not be reset. Alternatively, if MakeBeforeBreak-r16 is set, the MAC of the source may not be reset, but the MAC of the target may be reset.
(LA-8) PDCP is re-established for all radio bearers configured and established in the PDCP configuration. 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 establishment and/or re-establishment may be performed.
(LA-9) For all established radio bearers, if the MCG RLC and/or the SCG RLC are 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 in accordance with the received cell-common radio resource configuration (radioResourceConfigCommon).
(LA-12) Configure the lower layers according to other information contained in the received mobilityControlInfo.
(LA-13) If the received RRC connection reconfiguration message includes sCellToReleaseList,
(LA-13-1) Execute the release of SCell.
(LA-14) If the received RRC connection reconfiguration message includes sCellGroupToReleaseList,
(LA-14-1) Execute release of SCell group.
(LA-15a) If the received RRC connection reconfiguration message includes scg-Configuration,
(LA-15b) If the current configuration of the terminal device includes one or more split DRBs and the received RRC connection reconfiguration message includes DRB-ToAddModList,
(LA-15-1) Execute SCG reconfiguration.
(LA-16) If the received RRC connection reconfiguration message includes a terminal device-specific radio resource configuration (radioResourceConfigDedicated),
(LA-16-1) Execute wireless resource configuration in process LB, which will be described later.
(LA-17) If the RRC connection reconfiguration message includes 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) nextHopChainingCount - Store the value of r15.
(LA-17-5) If securityAlgorithmConfig-r15 is received,
(LA-17-5-1) Generate a KRRCint key linked to the received integrityProtAlgorithm.
(LA-17-5-2) Generate a KRRCenc key and a KUPenc key linked to the received cipheringAlgorithm. The KRRCenc key is a key used to protect the RRC signal generated from the KeNB key using an encryption algorithm. Also, KUPenc is a key used to protect user plane traffic (user data) generated from the KeNB key using an encryption algorithm.
(LA-17-6) Otherwise,
(LA-17-6-1) Generate a KRRCint key associated with the current integrityProtAlgorithm from the KeNB key.
(LA-17-6-2) Generate a KRRCenc key and a KUPenc key associated with the current cipheringAlgorithm from the KeNB key.
(LA-18) If the received RRC connection reconfiguration message includes sCellToAddModList,
(LA-18-1) Perform addition and/or modification of SCell.
(LA-19) If the received RRC connection reconfiguration message contains sCellGroupToAddModList,
(LA-19-1) Add and/or modify SCell groups.
(LA-20) If the received RRC connection reconfiguration message includes measConfig,
(LA-20-1) Execute measurement settings.
(LA-21) Perform automatic deletion of measurement identifiers.
(LA-22) Submit 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.

(Processing LB)
(LB-1) If the received radioResourceConfigDedicated contains SRB-ToAddModList,
(LB-1-1) Add and/or reset an SRB in the process LC described below.
(LB-2) If the received radioResourceConfigDedicated contains drb-ToReleaseList,
(LB-2-1) DRB release is executed in the process LD described later.
(LB-3) If the received radioResourceConfigDedicated contains DRB-ToAddModList,
(LB-3-1) In the process LE described below, the DRB is added and/or reconfigured.
(LB-4) If the received radioResourceConfigDedicated contains mac-MainConfig,
(LB-4-1) In process LF described later, the MAC main setting is executed.

(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 settings.
(LC-1-2) If rlc-BearerConfigSecondary with the 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 E-UTRA PDCP entity to activate duplication.
(LC-2) For each SRB identifier included in the SRB-ToAddModList that is part of the current terminal device configuration:
(LC-2-1) If pdcp-verChange is included (i.e., if there is a change from NR PDCP to E-UTRA PDCP),
(LC-2-1-1) Establish an E-UTRA PDCP entity with the current security settings.
(LC-2-1-2) Link 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 the 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 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 E-UTRA PDCP entity 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.

(Processed LD)
(LD-1a) for each DRB identifier included in the drb-ToReleaseList that is part of the current terminal device configuration, or
(LD-2b) For each DRB identifier value released as a result of full configuration,
(LD-2-1) If this DRB release is the result of 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 configuration,
(LD-2-2-1) Release the E-UTRA PDCP entity.
(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 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.

(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 the 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 settings 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 logical channel identifier (logicalChannelIdentity) and logical channel configuration (logicalChannelConfig) are included, establish the MCG DTCH logical channel according to logicalChannelIdentity and logicalChannelConfig.
(LE-1-1-4) If rlc-BearerConfigSecondary with the 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 DRBs are configured with the same EPS bearer identity,
(LE-1-2-1) Associate the established DRB with its EPS bearer identifier.
(LE-1-3) Otherwise, if the entry in the DRB-ToAddModList contains pdcp-config (i.e., if the bearer is established with E-UTRA PDCP),
(LE-1-3-1) Notify upper layers of the establishment of the DRB and the EPS bearer identifier of the established DRB.
(LE-2) For each DRB identifier included 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.

(Processing LF)
(LF-1) Reconfigure the MAC main configuration (MAC main configuration) according to the MA main configuration information element (mac-MainConfig), except for the configuration related to adding, modifying, and/or releasing a Secondary Timing Advance Group (STAG).
(LF-2) If the received mac-MainConfig contains information about the release of STAG (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 STAG (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 TAG 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 the 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.

Another example of MBB-HO operation is described below. Here, an example is shown in which an RRC reconfiguration message including conditional handover configuration is used in NR.

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 containing one or more information elements (conditional handover settings) that include information contained in the synchronized reconfiguration information element. Furthermore, the conditional handover information element may include an information element (conditional handover condition) that indicates the conditions for applying the conditional handover settings to each, some, or all of the conditional handover settings.

The conditional handover configuration may include some or all of the information contained in RadioBearerConfig and CellGroupConfig. The conditional handover configuration may also include information indicating MBB-HO. The conditional handover conditions may also include threshold information for determining whether the conditions are met using a reference signal. The conditional handover conditions may also include information instructing the immediate application of the conditional handover configuration. For example, if the conditional handover conditions indicate information instructing the immediate application of the conditional handover configuration and the conditional handover configuration contains information indicating MBB-HO, MBB-HO can be achieved by executing Processes A and I based on the information contained in the conditional handover configuration. Of course, even if the conditional handover conditions are other conditions, conditional MBB-HO can be achieved by executing Processes A and I based on the information contained in the conditional handover configuration if the conditions are met.

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

For example, if the core network is 5GC, in the source configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by RLC bearer configuration, and the DRB, PDCP entity, and PDU session are further linked by drb-ToAddMod. Similarly, in the target configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by RLC bearer configuration, and the DRB (or SRB), PDCP entity, and PDU session are further linked by drb-ToAddMod. In this case, for example, the logical channel, DRB (or SRB), and/or RLC bearer linked to the same DRB identifier (or SRB identifier) in the source configuration and the target configuration may be linked to a single PDCP. Also, for example, logical channels, DRBs (or SRBs), and/or RLC bearers associated with the same PDU session in the source configuration and target configuration may be associated with one PDCP.

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

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 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 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 a single 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 a single PDCP.

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

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

Another example of MBB-HO operation is described below. Here, an example is shown in which an RRC connection reconfiguration message including conditional handover configuration is used in LTE.

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 containing one or more information elements (conditional handover settings) that include information contained in the mobilityControlInfo information element. Furthermore, the conditional handover information element may include an information element (conditional handover condition) that indicates the conditions for applying the conditional handover settings to each, some, or all of the conditional handover settings.

The conditional handover configuration may include some or all of the information contained 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 conditions may also include threshold information for determining whether the conditions are met using a reference signal. The conditional handover conditions may also include information instructing that the conditional handover configuration be applied immediately. For example, if the conditional handover conditions indicate information instructing that the conditional handover configuration be applied immediately and the conditional handover configuration contains information indicating MBB-HO, MBB-HO can be achieved 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, if the condition is met, conditional MBB-HO can be realized by executing the process LA based on the information contained in the conditional handover setting.

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.

For example, if the core network is 5GC, in the source configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by RLC bearer configuration, and the DRB, PDCP entity, and PDU session are further linked by drb-ToAddMod. Similarly, in the target configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by RLC bearer configuration, and the DRB (or SRB), PDCP entity, and PDU session are further linked by drb-ToAddMod. In this case, for example, the logical channel, DRB (or SRB), and/or RLC bearer linked to the same DRB identifier (or SRB identifier) in the source configuration and the target configuration may be linked to a single PDCP. Also, for example, logical channels, DRBs (or SRBs), and/or RLC bearers associated with the same PDU session in the source configuration and target configuration may be associated with one PDCP.

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

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 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 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 a single 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 a single PDCP.

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

Also, 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.

In addition, MakeBeforeBreak-r16 may contain information indicating which layers of the target will or will not be generated before the connection to the target is completed.

In the case of NR, the (processing E) may include the following processes (E2-1) and after. For example, as shown in FIG. 22, the process (E2-1) may be executed between the process (E-1) and the process (E-2), but this is not limited thereto. In addition, in the case of LTE, the (processing LF) may include the following processes (E2-1) and after. For example, the process (E2-1) may be executed before the process (LF-1), but this is not limited thereto.
(E2-1) If it is 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.

This allows MAC entities to be generated appropriately in processing based on MAC layer settings.

In the case of NR, the process within the scope of the process (B-9) of the process B may be, for example, the process (B2-9) as shown in Fig. 23. In the case of MBB-HO, the setting for "this cell group" in the process (B-9) and subsequent processes in the process (B) may be applied to the target.
(B2-9) If the synchronized re-establishment 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) Create 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.

In addition, in the case of LTE, the processing within the scope of processing (LA-6) to processing (LA-7) in the (processing LA) may be, for example, processing (LA2-6) and processing (LA2-7) as shown in FIG.
(LA2-6) If makeBeforeBreak-r16 is set,
(LA2-6-1) The current terminal device configuration (source configuration) is duplicated to become the target configuration, and the subsequent reconfiguration process 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 configuration to be duplicated 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 bearer configuration to be duplicated may not include the SRB configuration. That is, for DRB, both the source setting and the target setting may be managed, and for SRB, the setting may be switched from the source setting to the target setting without duplicating the setting. Furthermore, information that enables determination of whether to duplicate the SRB setting 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) Create a secondary MAC entity.
(LA2-6-3) Reset the secondary MAC entity if necessary.
(LA2-7) Otherwise (LA2-7-1) If set, reset the MAC of the MCG and the MAC of the SCG.

This allows MAC entities to be generated appropriately even if the NR RRC reconfiguration message does not include MAC cell group settings. Furthermore, when the EUTRA RRC connection reconfiguration message does not include MAC primary settings, MAC entities can be generated appropriately.

Also, 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. Also, 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.

This allows for proper management of MAC entities.

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.

In addition, the terminal device may notify the base station device of some or all of the following information: (1) information indicating whether or not it supports the 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 it supports the execution of MBB-HO while maintaining communication using two or more cell groups (e.g., Dual Connectivity); (3) information indicating whether or not it supports the 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 it supports the 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. Furthermore, the information may be notified as information that does not depend on the band combinations supported by the terminal device. Furthermore, the information may be notified as information for each band combination supported by the terminal device. Furthermore, the information does not need to be notified to the base station device.

The terminal device may also release one or more cell groups other than the MCG and perform MBB-HO. The terminal device may also 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 also release one or more cell groups other than the MCG and perform MBB-SCG Change. The terminal device may also 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) that is not an MBB-SCG Change. The terminal device may also 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. The SCG change may be rephrased as an SCG reconfiguration with sync. Also, handover (HO) may be rephrased as an MCG reconfiguration with sync.

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 (at the target) after copying 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 do not have to be carried over (at the target) after copying. That is, the values before copying (at the source) may not be held (at the target) after copying, but 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 to 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 at the source, and in a DRB, the target may not inherit the values of some or all timers at the source but may initialize them. The timers to be replicated may be some or all timers of each entity 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, as described in Non-Patent Document 5 and/or Non-Patent Document 11.
(C) A reassembly timer, which is a timer used to detect loss of RLC SDUs at the receiving side of an RLC entity, 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) A poll retransmission timer, which is a timer used for retransmitting a poll at the transmitting side of the RLC entity, may be a timer named t-PollRetransmit as 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, and may be the timer named t-StatusProhibit described in Non-Patent Document 6 and/or Non-Patent Document 12.

In addition, when the current terminal device settings (source settings) are copied to become target settings (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 copying. In other words, the values before copying (source) may be held (to the target) after copying and continued in the target, that is, started or restarted from the values at the time of copying. Furthermore, the values of some or all of the state variables, counters, and other variables may be carried over (to the target) after copying. In other words, the values before copying (source) may not be held (to the target) after copying (target) but may be initialized after copying (target), or initial values may be set after copying (target). In the case of initialization, 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 target may inherit the values of some or all of the source variables, such as state variables and counters, while in a DRB, the target may initialize the source variables, such as some or all of the source variables, such as state variables and counters, without inheriting them. The replicated state variables and counters may be some or all of the state variables and counters of each entity of the PDCP entity, 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 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 a state variable named RX_DELIV described in Non-Patent Document 11.
(D) A state variable 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. This may be a state variable named RX_REORD as described in Non-Patent Document 11.

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

10 and 11, the information element represented by mobilityControlInfo is an information element including 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 indicating the time from the start to the expiration of timer T304
(C) newUE-Identity indicating the new identity (C-RNTI) of the UE 122
(D) Radio resource configuration (E) Dedicated random access channel configuration (F) makeBeforeBreak-r14, a parameter for configuring 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

Figure 10 shows an example where makeBeforeBreak-r16 is an enumeration type, and Figure 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.

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

Figure 12 shows an example where makeBeforeBreak-r16 is an enumeration type, and Figure 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.

Furthermore, some or all of the fields shown in Figures 10 to 13 may be optional. That is, the fields shown in Figures 10 to 13 may be included in the message depending on the conditions.

In addition, it may be possible to configure from the eNB102 or gNB108 whether to apply make-before-break handover (MBB-HO) for each radio bearer. When configuring whether to apply make-before-break handover for each radio bearer, parameters related to make-before-break handover may be configured below (at 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. Furthermore, when configuring whether 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 (at 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.

Figure 20 shows an example of ASN.1 indicating parameters (information elements or fields) for setting whether make-before-break handover (MBB-HO) is applied to a radio bearer to be established or configured in each embodiment of the present invention. In the example of Figure 20, an example is shown in which the parameter for setting whether make-before-break handover is applied to a radio bearer to be established or configured is located under PDCP-Config, but the parameter for setting whether make-before-break handover is applied to a radio bearer to be established or configured may be located anywhere under the radio bearer configuration. Note that the above phrase "whether make-before-break handover is applied to a radio bearer to be established or configured" may also be rephrased as "whether make-before-break handover is performed for the radio bearer to be established or configured" or similar phrases such as "whether make-before-break handover is performed for the radio bearer to be established or configured" or "whether make-before-break is applied to the radio bearer." Furthermore, the above phrase "whether or not make-before-break handover is applied to a radio bearer to be established or configured" may be rephrased as "whether or not make-before-break handover is applied to a PDCP entity," or "whether or not a PDCP entity performs make-before-break handover," or "a 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 by configuring both the source configuration and the target configuration, and/or both the primary configuration and the secondary configuration in one PDCP entity.

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 being established or configured," but other fields and/or information elements may also 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 the information element MBB-DRB as its value, and the information element MBB-DRB has one or more fields. In Figure 20(A), if a 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 linked to this PDCP entity at the handover destination (a field named targetLogicalChannelIdentity), and some or all of other parameters (not shown).

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 if a parameter equivalent to makeBeforeBreak-r16 shown in the examples of Figures 10 to 13 is not set, the field represented by mbb-drb may not be present. 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 applies is being performed, it may be determined that a make-before-break handover is being performed, or that make-before-break handover has been set.

Figure 21 shows an example of ASN.1 in which information on the radio bearer to which make-before-break handover applies exists above the radio bearer configuration. As shown in Figure 21, information on the radio bearer to which make-before-break handover applies may exist as one of the parameters of the MakeBeforeBreak-r16 information element in Figures 11 and/or 13 (e.g., parameter A or parameter B shown in Figures 11 and/or 13). In the example of Figure 21, fields expressed as mbb-drb and mbb-drbList (a list of mbb-drb) are used as parameters for "information on the radio bearer to which make-before-break handover applies," but other fields and/or information elements 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 of the radio bearer to which the make-before-break handover is applied (a field expressed as drb-Identity), the identifier of the cell group at the handover destination (a field named targetCellGroupId), the logical channel identifier associated with this PDCP entity at the handover destination (a field named targetLogicalChannelIdentity), and other parameters (not shown). Also, in the example of Figure 21, if the parameter "information on the radio bearer to which the make-before-break handover is applied" does not exist, 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 radio bearers to which make-before-break handover is applied" in FIG. 21, information on signaling radio bearers (SRBs) may also be included.

Figure 5 is a block diagram showing the configuration of a terminal device (UE122) in each embodiment of the present invention. Note that, to avoid complicating the explanation, Figure 5 shows only the main components that are closely related to one embodiment of the present invention.

The UE 122 shown in FIG. 5 comprises a receiver 500 that receives RRC messages and the like from a base station device, a processor 502 that performs processing according to any or all of the setting information, such as various information elements (IEs), various fields, and various conditions, contained in the received messages, and a transmitter 504 that transmits RRC messages and the like to the base station device. The base station device may be an eNB 102 or a gNB 108. The processor 502 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). That is, the processor 502 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

Figure 6 is a block diagram showing the configuration of a base station device in each embodiment of the present invention. Note that, to avoid complicating the explanation, Figure 6 shows only the main components that are closely related to one embodiment of the present invention. The above-mentioned base station device may be an eNB102 or a gNB108.

The base station device shown in FIG. 6 is configured to include a transmitter 600 that transmits RRC messages, etc. to UE 122; a processor 602 that creates an RRC message including any or all of the setting information, such as various information elements (IEs), various fields, and various conditions, and transmits it to UE 122, thereby causing the processor 502 of UE 122 to perform processing; and a receiver 604 that receives RRC messages, etc. from UE 122. Furthermore, the processor 602 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). That is, the processor 602 may include some or all of the physical layer processor, MAC layer processor, RLC layer processor, PDCP layer processor, RRC layer processor, and NAS layer processor.

Figure 25 shows an example of a processing method of 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 regarding reconfiguration of the RRC connection to cause UE 122 to perform processing, and transmits it to UE 122 from the transmission unit 600 (not shown). The reception unit 500 of UE 122 receives the message regarding reconfiguration of the RRC connection transmitted from the base station device (step S2500).

The processing unit 502 of UE 122 checks whether the above-mentioned message regarding the reconfiguration of the RRC connection includes first information. If the above-mentioned first information is not included, it may be determined that it is not a make-before-break handover. If the above-mentioned first information is included, it may be determined that it is a make-before-break handover. Furthermore, if the above-mentioned first information is included, it may be determined that a make-before-break handover is applied or may be applied to some or all of the radio bearers currently configured in UE 122. Furthermore, if the above-mentioned first information is included, it may be determined that a make-before-break handover (DAPS handover) is configured. Furthermore, if the above-mentioned first information is included in the message regarding the reconfiguration of the RRC connection, the processing unit 502 of UE 122 may create a cell group and/or a MAC entity for the target of the make-before-break handover. Furthermore, if the above-mentioned first information is included in the message regarding the re-establishment of the RRC connection, 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).

The processing unit 502 of UE122 may further determine, based on the first information described above, which radio bearers currently configured in UE122 are subject to make-before-break handover and/or which radio bearers are not subject to make-before-break handover (step S2504).

The processing unit 502 of UE 122 may change or reconfigure 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).

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 and associate it with the PDCP entity of the radio bearer to which the above-mentioned make-before-break handover is applied. At this time, the processing unit 502 may also associate the above-mentioned second RLC bearer with the above-mentioned second cell group (step S2506) (step S2508).

The above-mentioned 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 as described above (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 as described above (shown in Figures 21 and/or 22) exists or is set in any of the radio bearers.

Furthermore, 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.

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 a radio bearer to which the make-before-break handover is not applied is associated before the make-before-break handover is performed.

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.

Furthermore, in step S2506 and/or step S2508, both the first cell group and the second cell group may be master cell groups (MCGs). Further, 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 above-mentioned second MAC entity may be a MAC entity for the target of a make-before-break handover generated in the above-mentioned step S2502. Further, the above-mentioned 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. Further, the above-mentioned 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 a MAC entity in a case where a make-before-break handover is not performed, and the second MAC entity may be a target MAC entity in a make-before-break handover.

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. Duplication of the radio bearer may mean preparing a radio bearer with the same settings as the settings of the radio bearer. Duplication of the radio bearer may also mean preparing a radio bearer with the same settings as the settings 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. Furthermore, either the radio bearer to which make-before-break handover is not applied or the duplicated radio bearer may be stopped. 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.

In addition, instead of performing the processing of step S2504 described above, in step S2502 described above, it may be determined 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 described above contains the first information described above. In this case, the processing of step S2506 described above does not need to be performed.

Figure 26 shows another example of a processing method of UE 122 in each embodiment of the present invention. The processing unit 502 of UE 122 attempting handover from the handover source to the handover destination (target) detects that the first timer has expired (step S2600). Note that the above-mentioned first timer may be a timer used to detect handover failure, etc. Furthermore, the above-mentioned first timer may be a timer that starts when the UE 122 receives 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) or when the UE 122 moves to a cell from a different RAT (a CellChangeOrder described in Non-Patent Document 4), and stops when the handover is successful, when the CellChangeOrder is successful, or when random access to the corresponding SpCell (the handover destination) is successful. Furthermore, when the above-mentioned first timer expires, the handover may be considered to have failed. Furthermore, 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 expires, the UE 122 may return its configuration to that of the handover source (source). Furthermore, when the above-mentioned first timer 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). 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 refer to processing performed upon receiving a message regarding 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), or may refer to 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.

In step S2600, the processing unit 502 of UE 122 that detects that the first timer has expired may then determine whether the first setting has been made for UE 122. If the first setting has been made for UE 122, some or all of the settings for the handover destination (target) may be released based on the fact that the first setting has been made (step S2602). 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 case where the above-mentioned first setting has been made may be rephrased as a case where DAPS handover setting has been made for any radio bearer, or a case where DAPS handover setting has been made for at least one radio bearer, or may be rephrased by another similar expression. Note that the above-mentioned DAPS handover setting may be a setting 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 some or all of the settings of the handover target" may mean releasing some or all of the settings of the RLC entity and logical channel of the handover target for a radio bearer to which DAPS handover is applied. Furthermore, the above-mentioned "releasing the settings of the handover target" may mean releasing some or all of the settings of the PDCP entity, radio bearer identifier, RLC entity, logical channel, and SDAP QoS flow and radio bearer mapping rule of the handover target for a radio bearer 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.

Also, in step S2602, the processing unit 502 of UE 122 determines whether a first setting has been made to UE 122, and if a first setting has been made to 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 above-mentioned first setting has been made to 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).

Furthermore, in step S2600, the processing unit 502 of the UE 122 that detects the expiration of the first timer determines whether the first setting is performed on the UE 122. If the first setting is performed on the UE 122, the processing unit 502 may update the security key configured in the handover source (source) based on the fact that the first setting is performed (step S2604). Note that the 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 first setting is performed may be rephrased as a case where DAPS handover is configured for any radio bearer, a case where DAPS handover is configured for at least one radio bearer, or another similar expression. Furthermore, the security key configured in the handover source (source) may be rephrased as the security key that was configured 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 confidentiality key for SRB, the integrity key for SRB, the confidentiality key for DRB, and the integrity key for DRB.

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 process integrity protection 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.

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

Furthermore, the above-mentioned processing (C) in step S2604 may be rephrased as configuring the lower layer to perform integrity protection processing for all SRBs except SRB1 using the above-mentioned SRB integrity key or the configured SRB integrity key and the configured integrity algorithm. Furthermore, the above-mentioned processing (E) in step S2604 may be rephrased as configuring the lower layer to perform encryption processing for all SRBs except SRB1 using the above-mentioned SRB confidentiality key or the configured SRB confidentiality key and the configured confidentiality algorithm. Furthermore, some or all of the processing in step S2604 may be performed after UE 122 detects that the first timer has expired in step S2600 and before sending the 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 an initial RRC message to the handover source (source) base station. The initial RRC message may be an RRC message for notifying that the DAPS handover to the target has failed. After sending the initial 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 radio bearers using the SRB integrity key or a configured SRB integrity key and a configured integrity algorithm. Furthermore, after sending the first RRC message to the handover source base station device, 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. Furthermore, in step S2604, some or all of the radio bearers may be suspended before or after updating the security keys. Furthermore, after the UE 122 detects that the first timer has expired, some or all of the suspended radio bearers may be resumed when or before sending the first RRC message to the handover source base station device. The resumed radio bearers may include SRB1 or all of the SRBs.

Furthermore, part or all of the processing of step S2604 may be performed when or after UE 122 receives the first RRC message from the handover source (source) base station device after detecting that the first timer has expired in step S2600. Also, 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 device after 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 device may be a message regarding RRC connection re-establishment, a message regarding RRC connection resumption, or another RRC message. The parameter indicating a security key update may be included in the RRC message based on the failure of the DAPS handover. Furthermore, the parameter indicating 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.

Also, 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) described above may be performed before or after the security key update process of the handover source (source), or may be performed after 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. Also, the process of resetting the MAC entity of the handover source described above may be performed after 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. Also, 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).

Also, in step S2604, the processing unit 502 of UE 122 determines whether a first setting has been made in UE 122, and if a first setting has been made in 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 security key set in the handover source (source) may be updated and the above-mentioned processing may be performed based on the fact that the above-mentioned first setting has been made in 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).

Furthermore, in step S2604, 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, a process of reverting some or all radio bearers to the settings used in the handover source (source) may be performed. The above-mentioned process of reverting to the settings used in the handover source (source) may be performed for radio bearers to which DAPS handover does not apply. Furthermore, the above-mentioned process of reverting to the settings used in the handover source (source) for some or all radio bearers may be performed before or after the security key update process in step S2604, or may be performed before or after sending the above-mentioned first RRC message to the handover source (source) base station device after UE 122 detects that the first timer has expired.

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

Note that in step S2604, the security key does not need to be updated.

The receiving unit 500 of the UE 122 may receive a message regarding reconfiguration of the RRC connection from the base station device. The processing unit 502 of the UE 122 may establish or reconfigure a radio bearer in accordance with the message regarding reconfiguration of the RRC connection (step S2606). Note that some or all of the processing of the above-mentioned step S2604 may be performed when establishing or reconfiguring a radio bearer in step S2606.

Furthermore, in step S2604 and/or step S2606, based on the fact that the first configuration is performed on 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 may be discarded for some or all of the radio bearers. 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 the retransmission buffer. The process of discarding some or all of the data in the buffer based on the fact that the first configuration is performed on the UE 122 and/or that no radio link failure is detected in the primary cell of the handover source may be performed after a process of reverting radio bearers to which DAPS handover is not applied to the configuration used in the handover source. Also, the process of discarding some or all of the data in the buffer based on the fact that the first configuration is performed on the UE 122 and/or that no radio link failure is detected in the primary cell of the handover source may be performed after a process of reverting bearers (UM DRBs) to 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. Furthermore, the process of discarding some or all of the data in the buffer based on the first configuration of the UE 122 and/or the absence of a radio link failure 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 called "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 an upper layer at the transmitting side of the PDCP entity, and the SDU may be discarded upon expiration of the discard timer. The value of the discard timer at the target at the time the first timer expires may be applied to the discard timer value. That is, when a radio bearer is reverted to the configuration used at the source, the discard timer may be retained without being reverted to the configuration used at the source, and the discard timer value at the target may be maintained for the radio bearer reverted to the configuration used at the source. Also, the radio bearer for which a part or all of the data stored in the buffer is discarded based on the fact that the UE 122 is in the first configuration and/or that no radio link failure has been detected in the primary cell of the source may be pre-configured by an RRC message.

Furthermore, in step S2604 and/or step S2606, based on the first configuration being performed in the UE 122 and/or the fact that no radio link failure is 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 first configuration being performed in 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 after a process of reverting the configurations used in the handover source for radio bearers not applicable to DAPS handover has been performed. 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 on 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 configurations used in the handover source for the RLC UM-configured or established bearers (UM DRBs) among the radio bearers not subject to DAPS handover to those used in the handover source. 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 on 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. 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 PDCP data PDU loss at the receiving side of the PDCP entity, and may be the timer named t-Reordering, as described in Non-Patent Document 5 and/or Non-Patent Document 11.
(B) A reassembly timer, which is a timer used to detect loss of RLC SDUs at the receiving side of the RLC entity, 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) A Poll Retransmission Timer, which is a timer used for retransmitting a poll at the transmitting side of the RLC entity. This may be a timer named t-PollRetransmit described in Non-Patent Document 6 and/or Non-Patent Document 12.
(D) The status prohibit timer, which is a timer used to prohibit the transmission of a status PDU at the receiving side of the RLC entity, may be a timer named t-StatusProhibit described in Non-Patent Document 6 and/or Non-Patent Document 12.

In addition, in step S2604 and/or step S2606, based on the fact that the first configuration has been performed on 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 state variables configured in each e-entity for some or all 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 and/or resetting 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 on UE 122 and/or that no radio link failure has been detected in the primary cell of the handover source may be performed after performing a process of reverting (reverting) the configuration 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 may be performed after a process of reverting a bearer (UM DRB) in which RLC UM is configured or established, among radio bearers to which DAPS handover does not apply, to the configuration used in the handover 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 may be configured in advance by an RRC message.

Furthermore, in step S2604 and/or step S2606, based on the fact that the first configuration has been configured for UE 122 and/or that no radio link failure has been detected in the primary cell of the handover source, some or all radio bearers may be reverted to the configuration used in the handover source (source), but some or all data may not be reverted to the configuration or state used in the handover source (source). The above-mentioned some or all data may be some or all of the PDCP SDU, PDCP PDU, RLC SDU, RLC SDU segment, RLC PDU, MAC SDU, and MAC PDU. The process of reverting some or all radio bearers to the settings used in the handover source (source) based on the first setting 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 first setting 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.

Also, 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 (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 not be reverted to the settings or states used in the handover source (source), but may be set to their initial values and started or restarted. Based on the fact that the above-mentioned 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), some or all of the radio bearers are reverted to the configurations used in the handover source (source), but at this time, some or all of the timer values are not reverted to the configurations 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 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 pre-configured 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 the PDCP entity.
(C) A reassembly timer, which is a timer used to detect loss of an RLC SDU at the receiving side of the RLC entity.
(D) Poll retransmission timer, which is a timer used for retransmission of a poll at the transmitting side of the RLC entity.
(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.

Also, in step S2604 and/or step S2606, based on the fact that the first setting has been made to UE122 and/or that no radio link failure has been detected in the primary cell of the handover source, some or all radio bearers are reverted to the settings used in the handover source (source), but in this case, some or all 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 above-mentioned 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, 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 state variables are not reverted to the configuration or state 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 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 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 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.

Furthermore, in step S2604 and/or step S2606, the PDCP entities of some or all radio bearers may be instructed to transmit a status report and/or perform data recovery based on the fact that the first configuration has been performed on UE 122 and/or that no radio link failure has 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 informing the transmitting side of the COUNT value of a PDCP SDU waiting for reception (a PDCP SDU that has 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 lower layers on a radio bearer (AM DRB) for which RLC AM is configured or established. Based on the above-described 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, the process of causing the PDCP entities of some or all of the radio bearers to transmit status reports and/or perform data recovery may be performed for the radio bearers to which the DAPS handover is applied.Furthermore, based on the above-described 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, the process of causing the PDCP entities of some or all of the radio bearers to transmit status reports and/or perform data recovery may be performed for the AM DRBs to which the DAPS handover is applied.

Note that some 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, some or all of the term "handover destination" (target) in steps S2600 to S2606 may be replaced with "handover destination PCell" (target PCell) or "handover destination cell group" (target cell group).

Figure 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.

The processing unit 502 of the UE 122 attempting a handover from the handover source (source) to the handover destination (target) detects that the first timer has expired (step S2700). The above-mentioned first timer may be a timer used to detect handover failure, etc. The above-mentioned first timer may also be a timer that starts when a message related to reconfiguration of the RRC connection is received that includes a parameter indicating 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 when a cell change from a different RAT occurs (a CellChangeOrder described in Non-Patent Document 4), and stops when the handover is successful, when the CellChangeOrder is successful, or when random access to the corresponding (handover destination) SpCell is successful. Furthermore, if the first timer described above expires, the handover may be considered to have failed. Furthermore, if the first timer described above expires, the UE 122 may initiate a procedure for re-establishing the RRC connection. Furthermore, when the UE 122 initiates the re-establishment of the RRC connection after the first timer expires, the UE 122 may return its configuration to that of the handover source (source). Furthermore, if the first timer described above expires during a 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 first timer described above may be the 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 refer to processing performed upon receiving a message regarding 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), or may refer to 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.

In step S2700, the processing unit 502 of UE 122 that has detected that the first timer has expired may then determine whether the first setting has been made in UE 122 and/or whether a radio link failure has been detected in the primary cell of the handover source. If the first setting has been made in UE 122 and/or if a radio link failure has not been detected in the primary cell of the handover 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 and/or that a radio link failure has not been detected in the primary cell of the handover source. Furthermore, if the first setting is configured in the UE 122 and/or if a radio link failure is not detected in the primary cell of the handover source, the UE 122 may resume the suspended SRBs of the handover source (source) based on the fact that the first setting is configured and/or the fact that a radio link failure is not 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. The above-mentioned "first setting" may be rephrased as "DAPS handover is configured for any radio bearer," "DAPS handover is configured for at least one radio bearer," or another similar expression. The above-mentioned "DAPS handover setting" may be a setting indicating that the radio bearer is to be subjected to DAPS handover.

The processing unit 502 of UE 122 may delete some or all of the data present in the buffer of the PDCP entity and/or LC entity of the source SRB resumed in step S2702 described above. The processing unit 502 of UE 122 may also stop and/or reset the reordering timer in the PDCP entity of the source SRB resumed in step S2702 described above. The processing unit 502 of UE 122 may also set some or all of the state variables (state variables) in the PDCP entity of the source SRB resumed in step S2702 described above to the same values as the state variables of the PDCP entity of the target SRB if the message regarding the re-establishment of the RRC connection 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 also set the state variables related to reordering in the PDCP entity of the SRB of the source resumed in step S2702 to a state where there are no PDCP PDUs 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. 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 (step S2704).

In addition, 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 setting the state variable (state variable) related to reordering in the PDCP entity to 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. In addition, in the above-mentioned step S2704, the process of deleting some or all of the data existing in the buffer 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 maintaining the reordering-related state variables (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 existence of data in the buffer of the PDCP entity and/or LC entity of the SRB of the resumed source.

Furthermore, in the above-mentioned step S2704, if the message regarding the re-establishment of the RRC connection received at the time of initiating the handover does not include an information element regarding security key updating, 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 related to COUNT values.Furthermore, in the above-mentioned step S2704, if the message regarding the re-establishment of the RRC connection received at the time of initiating the handover includes an information element regarding security key updating, some or all of the state variables in the PDCP entity of the source SRB resumed in the above-mentioned step S2702 may be retained.

In step S2704, 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 a state variable named RX_NEXT as 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 in this PDCP entity to generate a COUNT value for a received PDCP PDU. This may be the state variable named RX_HFN described in Non-Patent Document 5.

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 at the receiving side of the PDCP entity. This may be a 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 the 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 the COUNT value for the 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 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 a 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 COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer at the receiving side of the PDCP entity, which 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.

In addition, in the above-mentioned step S2704, the process of setting the state variables (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 the state variable named RX_NEXT 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 the state variable named RX_DELIV 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 the state variable named RX_NEXT 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 the state variable named RX_REORD 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.

In addition, 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 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 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) indicating 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.

Note that in the above-mentioned step S2704, the process of changing the state variable (state variable) related to reordering in the PDCP entity of the SRB of the resumed source to a state where no PDCP PDUs are waiting to be received may be rephrased as a process of changing the state variable (state variable) related to reordering to a state where no reordering window exists, or may be expressed in other terms as long as it represents a process of changing the state variable related to reordering to a state where no PDCP PDUs are waiting to be received. Note that in the above-mentioned step S2704, the process of changing the state variable (state variable) related to reordering in the PDCP entity of the SRB of the resumed source to a state where no PDCP PDUs are waiting to be received may be a process of updating the state variable related to reordering to a state where no PDCP PDUs are waiting to be received while maintaining the state variable related to the COUNT value.

In addition, in steps 2700 to 2704, the reordering timer may be referred to as a timer. Also, in steps 2700 to 2704, the SRB may be referred to as a radio bearer. 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.

In this way, an embodiment of the present invention enables efficient communication during handover of UE122.

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

In the above description, a radio bearer to which DAPS handover is applied may be a DRB to which DAPS handover is applied. Also, a radio bearer to which DAPS handover is not applied may be a DRB to which DAPS handover is not applied.

In addition, in the above description, expressions such as "linked," "associated," and "associated" may be used interchangeably.

Furthermore, in each of the process examples or process flow examples in the above description, some or all of the steps may not be executed. Furthermore, in each of the process examples or process flow examples in the above description, the order of the steps may be different. Furthermore, in each of the process examples or process flow examples in the above description, some or all of the processing within each step may not be executed. Furthermore, in each of the process examples or process flow examples in the above description, the order of the processing within each step may be different.

In the above description, "in the case of MBB-HO" and/or "being MBB-HO" may refer to a case in which, in LTE, when performing an RRC connection reconfiguration including MobilityControlInfo, or in NR, when performing an RRC reconfiguration including synchronized reconfiguration, transmission and/or reception in the target cell is performed while continuing transmission and/or reception of user data in the source cell, or may be expressed by other names that imply equivalent operations. Furthermore, "in the case of MBB-HO" and/or "being MBB-HO" may refer to a case in LTE or NR where a specific information element (e.g., the MakeBeforeBreak-r16 information element shown in Figures 10 to 13 and 21, and/or the mbb-drb information element shown in Figures 20 to 22) is included in the 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.

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 an RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing an 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 the mbb-drb information element 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 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.

In the above description, "Make Before Break Handover (MBB-HO)" may also mean that a master cell group for the target is created and exists simultaneously with the master cell group for the source. Furthermore, "MBB-HO" may also mean that, when performing an RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing an RRC reconfiguration including synchronized reconfiguration in NR, some or all of the radio bearers configured in the terminal device are used to transmit and/or receive user data in the target cell while continuing to transmit and/or receive user data in the source cell, or may be expressed by other names that mean 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 the reconfiguration of the RRC connection. 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).

In addition, in the above explanation, "Make Before Break Handover (MBB-HO)" may refer to the 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 to a time approaching zero milliseconds (RUDI: Reduce User Data Interruption), or it may be expressed by another name that has this meaning.

In each embodiment of the present invention, handover may be rephrased as reconfiguration with synchronization (Reconfiguration With Sync). For example, make-before-break handover may be rephrased as make-before-break reconfiguration with synchronization.

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 include 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 include that "F may be H".

Also, 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."

The following describes various aspects of the terminal device in an embodiment of the present invention.

(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.

(2) 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. (1) Terminal device.

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

(4) A terminal device described in (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.

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

(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).

(7) One embodiment 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.

(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.

(9) A method as described in (7) or (8), wherein the first failure is a radio link failure in the source's primary cell.

(10) A method according to (7), (8), or (9), 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.

(11) A 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 PDCP SDUs waiting to be received at the receiving side of the PDCP entity and not delivered to the upper layer.

(12) A method according to (7), (8), (9), (10), or (11), wherein the third state variable is a state variable 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.

A program running on a device relating 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 relating to one aspect of the present invention. The program or information handled by the program is temporarily loaded into volatile memory such as random access memory (RAM) during processing, or stored in non-volatile memory such as flash memory or a hard disk drive (HDD), and is read, modified, and written by the CPU as needed.

It should be noted that a portion of the device in the above-described embodiments may be implemented by a computer. In this case, the program for implementing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be read by a computer system and executed to implement the function. The term "computer system" here refers to a computer system built into the device, and includes hardware such as an operating system and peripheral devices. Furthermore, the term "computer-readable recording medium" may be any of semiconductor recording media, optical recording media, magnetic recording media, etc.

Furthermore, "computer-readable recording medium" may 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. Furthermore, the above-mentioned program may be one that realizes part of the functions described above, or may be one that can realize the functions described above in combination with a program already recorded on the computer system.

Additionally, 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 those technologies may also be used.

Note that the present invention is not limited to the above-described embodiments. While the embodiments describe an example of a device, the present invention is not limited to this and can be applied to terminal devices or communication devices such as stationary or non-mobile electronic devices installed indoors or outdoors, such as AV equipment, kitchen equipment, cleaning/washing equipment, air conditioning equipment, office equipment, vending machines, and other household appliances.

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 includes design modifications within the scope of the gist of the 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 for elements that achieve the same effect are also included.

One aspect of the present invention can be used, for example, in communication systems, communication equipment (e.g., mobile phone devices, base station devices, wireless LAN devices, or sensor devices), integrated circuits (e.g., communication chips), or programs.

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

Claims (6)

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. 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 . 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 . 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. 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 . 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 .