JP7494064B2 - Terminal device, base station device, method, and integrated circuit - Google Patents

Description

The present invention relates to a terminal device, a base station device, a method, and an integrated circuit.

The 3rd Generation Partnership Project (3GPP), a standardization project for cellular mobile communication systems, is conducting technical studies and formulating standards for cellular mobile communication systems, including wireless access, core networks, and services.

For example, technical studies and standardization of E-UTRA (Evolved Universal Terrestrial Radio Access) have begun in 3GPP as a radio access technology (Radio Access Technology: RAT) for 3.9G and 4G cellular mobile communication systems. Currently, 3GPP is also studying and standardizing E-UTRA extension technologies. E-UTRA is also called Long Term Evolution (LTE: registered trademark), and the extension technology is sometimes called LTE-Advanced (LTE-A) and LTE-Advanced Pro (LTE-A Pro).

In addition, 3GPP has begun technical studies and standardization of NR (New Radio, or NR Radio access) as a radio access technology (Radio Access Technology: RAT) for cellular mobile communication systems for the 5th generation (5G). 3GPP is currently conducting technical studies and standardization of NR extension technology.

3GPP TS 38.300v 16.2.0, “NR; NR and NG-RAN Overall description; Stage 2” pp10-134 3GPP TS 36.300 v16.2.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2” pp19-361 3GPP TS 38.331 v16.1.0, “NR; Radio Resource Control (RRC); Protocol specifications” pp21-861 3GPP TS 36.331 v16.1.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specifications” pp25-1012 3GPP TS 37.340v 16.2.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-Connectivity; Stage 2” pp6-67

As one of the extension technologies for NR, a mechanism to extend existing NR mobility technology is being considered. One of the extensions of NR mobility technology is conditional handover. Conditional handover is a technology that improves the robustness of handover by having a terminal device execute a handover procedure when one or more handover execution conditions are met.

The operation of conditional handover is being standardized, but further study is required on the details of the operation.

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

In order to achieve the above object, one aspect of the present invention takes the following measures. That is, one aspect of the present invention is a terminal device that communicates with a base station device, the terminal device comprising a receiving unit that receives an RRC message from the base station device, and a processing unit, the processing unit performs settings on the terminal device according to the RRC message, performs handover failure processing based on the expiration of a first timer of the terminal device, and in the handover failure processing, performs processing to restore the settings of the terminal device other than the state variables of the PDCP entity for each SRB to the settings used in the source PCell based on the satisfaction of a first condition, and performs processing to restore the settings of the terminal device other than the state variables of the PDCP entity for each DRB to the settings used in the source PCell for each DRB. A process is performed to restore the settings of the terminal device to the settings used in the source PCell, and in the handover failure process, a process is performed to restore the settings of the terminal device to the settings used in the source PCell based on the fact that the first condition is not satisfied, the first condition includes at least that the terminal device has a first setting and that the conditional handover performed by the terminal device does not involve key updating, and the conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

Also, one aspect of the present invention is a base station device that communicates with a terminal device, the base station device comprising a transmission unit that transmits an RRC message to the terminal device, and a processing unit, the processing unit causes the terminal device to perform settings according to the RRC message, causes the terminal device to perform handover failure processing based on the expiration of a first timer of the terminal device, and in the handover failure processing, based on the fact that a first condition is satisfied, performs processing to restore the settings of the terminal device other than the state variables of the PDCP entity for each SRB to the settings used in the source PCell, and for each DRB, causes the terminal device to perform processing to restore the settings of the terminal device other than the state variables of the PDCP entity for each SRB to the settings used in the source PCell. The terminal device performs a process of restoring the settings of the device to the settings used in the source PCell, and in the handover failure process, the terminal device performs a process of restoring the settings of the terminal device to the settings used in the source PCell based on the fact that the first condition is not satisfied, the first condition including at least that the terminal device has a first setting and that the conditional handover performed by the terminal device does not involve key updating, and the conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

Another aspect of the present invention is a method of a terminal device communicating with a base station device, in which the terminal device receives an RRC message from the base station device, configures the terminal device according to the RRC message, and performs handover failure processing based on the expiration of a first timer of the terminal device. Based on the first condition being satisfied in the handover failure processing, the terminal device performs processing to restore the settings of the terminal device other than the state variables of the PDCP entity to the settings used in the source PCell for each SRB, and performs processing to restore the settings of the terminal device to the settings used in the source PCell for each DRB. Based on the first condition not being satisfied in the handover failure processing, the terminal device performs processing to restore the settings of the terminal device to the settings used in the source PCell, and the first condition includes at least that the terminal device has a first configuration and that the conditional handover performed by the terminal device does not involve key updating. The conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

Another aspect of the present invention is a method of a base station device communicating with a terminal device, in which the base station device transmits an RRC message to the terminal device, causes the terminal device to configure itself in accordance with the RRC message, and causes the terminal device to process a handover failure based on expiration of a first timer of the terminal device, and in the handover failure process, based on a first condition being satisfied, performs a process of restoring the settings of the terminal device other than the state variables of the PDCP entity for each SRB to the settings used in the source PCell, and for each DRB, restores the settings of the terminal device to the settings used in the source PCell. In the handover failure processing, a process is performed to restore the settings of the terminal device to the settings used in the source PCell based on the fact that the first condition is not satisfied, and the first condition includes at least that the terminal device has a first setting and that the conditional handover performed by the terminal device does not involve key updating, and the conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

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 realize efficient mobility processing.

1 is a schematic diagram of a communication system according to an embodiment of the present invention. FIG. 2 is a diagram showing an example of an E-UTRA protocol configuration according to an embodiment of the present invention. FIG. 1 is a diagram of an example of an NR protocol configuration according to an embodiment of the present invention. FIG. 2 is a diagram showing an example of a procedure flow for various settings in an RRC according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a terminal device according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a base station device according to an embodiment of the present invention. 1 description included in a message regarding reconfiguration 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 related to reconfiguration of an RRC connection in E-UTRA according to an embodiment of the present invention. 1 illustrates an example of an ASN.1 description of fields and/or information elements related to the configuration of a conditional handover in an embodiment of the present invention. FIG. 4 is a diagram showing an example of processing of a terminal device in the 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, LTE-A Pro) and NR may be defined as different radio access technologies (Radio Access Technology: RAT). NR may be defined as a technology included in LTE. LTE may be defined as a technology included in NR. NR and LTE that can be connected with Multi Radio Dual connectivity (MR-DC) may be distinguished from conventional LTE. LTE that uses 5GC in the core network may be distinguished from conventional LTE that uses EPC in the core network. Note that conventional LTE may be LTE that does not implement technologies standardized after Release 15 in 3GPP. The embodiment of the present invention may be applied to NR, LTE, and other RATs. In the following description, the description will be given using terms related to LTE and NR, but the embodiment of the present invention may be applied to other technologies using other terms. Furthermore, the term E-UTRA in the embodiments of the present invention may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

In the embodiment of the present invention, the names of each node and entity and the processing in each node and entity when the radio access technology is E-UTRA or NR are described, but the embodiment of the present invention may be used for other radio access technologies. The names of each node and entity in the embodiment of the present invention may be different names.

Figure 1 is a schematic diagram of a communication system according to an embodiment of the present invention. Note that the functions of each node, radio access technology, core network, interface, etc. described using Figure 1 are only some of the functions closely related to the embodiment of the present invention, and the system may have other functions described in Non-Patent Documents 1 to 5, etc. In addition, the system may have other functions not described in Non-Patent Documents 1 to 5, etc.

E-UTRA 100 may be a radio access technology described in Non-Patent Document 2, etc. E-UTRA 100 may also be an air interface between UE 122 and eNB 102. The air interface between UE 122 and eNB 102 may be called a Uu interface. eNB (E-UTRAN Node B) 102 may be a base station device of E-UTRA 100. eNB 102 may have an E-UTRA protocol, which will be described later. The E-UTRA protocol may be composed of an E-UTRA User Plane (UP) protocol, which will be described later, and an E-UTRA Control Plane (CP) protocol, which will be described later. eNB102 may terminate E-UTRA User Plane (UP) protocols and E-UTRA Control Plane (CP) protocols for UE122.

The EPC (Evolved Packet Core) 104 may be a core network described in Non-Patent Document 2, etc. The interface 112 is an interface between the eNB 102 and the EPC 104, and may be called an S1 interface. The interface 112 may include a control plane interface through which control signals pass, and/or a user plane interface through which user data passes. The control plane interface of the interface 112 may terminate at a Mobility Management Entity (MME: not shown) in the EPC 104. The user plane interface of the interface 112 may terminate at a Serving Gateway (S-GW: not shown) in the EPC 104. The control plane interface of the interface 112 may be called an S1-MME interface. The user plane interface of the interface 112 may be called an S1-U interface.

Note that one or more eNBs 102 may be connected to the EPC 104 via an interface 112. An interface may exist between the multiple eNBs 102 connected to the EPC 104 (not shown). The interface between the multiple eNBs 102 connected to the EPC 104 may be referred to as an X2 interface.

The NR 106 may be a radio access technology described in Non-Patent Document 1, etc.
may be an air interface between the UE 122 and the gNB 108. The air interface between the UE 122 and the gNB 108 may be referred to as a Uu interface. The gNB (g Node B) 108 may be a base station device of the NR 106. The gNB 108 may have the NR protocol described below. The NR protocol may be composed of the NR user plane (User Plane: UP) protocol described below and the NR control plane (Control Plane: CP) protocol described below. The gNB 108 may terminate the NR user plane (User Plane: UP) protocol and the NR control plane (Control Plane: CP) protocol for the UE 122.

5GC110 may be a core network described in Non-Patent Document 1, etc. Interface 116 is an interface between gNB108 and 5GC110, and may be called an NG interface. Interface 116 may include a control plane interface through which control signals pass, and/or a user plane interface through which user data passes. The control plane interface of interface 116 may terminate at an Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 116 may terminate at a User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 116 may be called an NG-C interface. The user plane interface of interface 116 may be called an NG-U interface.

Note that one or more gNBs 108 may be connected to 5GC 110 via interface 116. An interface may exist between multiple gNBs 108 connected to 5GC 110 (not shown). The interface between multiple gNBs 108 connected to 5GC 110 may be referred to as an Xn interface.

eNB102 may have a function to connect to 5GC110. eNB102 with a function to connect to 5GC110 may be called ng-eNB. Interface 114 is an interface between eNB102 and 5GC110, and may be called an NG interface. Interface 114 may have a control plane interface through which control signals pass, and/or a user plane interface through which user data passes. The control plane interface of interface 114 may terminate in an Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 114 may terminate in a User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 114 may be called an NG-C interface. The user plane interface of interface 114 may be called the NG-U interface.

Note that one or more eNBs 102 may be connected to the 5GC 110 via an interface 114. An interface may exist between the multiple eNBs 102 connected to the 5GC 110 (not shown). The interface between the multiple eNBs 102 connected to the 5GC 110 may be called an Xn interface. Furthermore, the eNB 102 connected to the 5GC 110 and the gNB 108 connected to the 5GC 110 may be connected by an interface 120. The interface 120 between the eNB 102 connected to the 5GC 110 and the gNB 108 connected to the 5GC 110 may be called an Xn interface.

The gNB 108 may have a function to connect to the EPC 104. The gNB 108 having a function to connect to the EPC 104 may be called an en-gNB. The interface 118 is an interface between the gNB 108 and the EPC 104, and may be called an S1 interface. The interface 118 may have a user plane interface through which user data passes. The user plane interface of the interface 118 may terminate at an S-GW (not shown) in the EPC 104. The user plane interface of the interface 118 may be called an S1-U interface. Furthermore, the eNB 102 connecting to the EPC 104 and the gNB 108 connecting to the EPC 104 may be connected by an interface 120. The interface 120 between the eNB 102 connecting to the EPC 104 and the gNB 108 connecting to the EPC 104 may be called an X2 interface.

Interface 124 is an interface between EPC 104 and 5GC 110, and may be an interface that passes only CP, only UP, or both CP and UP. In addition, some or all of interfaces such as interface 114, interface 116, interface 118, interface 120, and interface 124 may not exist depending on the communication system provided by the telecommunications carrier, etc.

UE122 may be a terminal device capable of receiving broadcast information and paging messages transmitted from eNB and/or gNB. UE122 may also be a terminal device capable of wireless connection with eNB102 and/or gNB108. UE122 may also be a terminal device capable of wireless connection with eNB102 and wireless connection with gNB108 simultaneously. UE122 may have an E-UTRA protocol and/or an NR protocol. Note that the wireless connection may be a Radio Resource Control (RRC) connection as described in Non-Patent Document 3, Non-Patent Document 4, etc.

As described in Non-Patent Document 3, Non-Patent Document 4, etc., when UE 122 communicates with eNB 102 and/or gNB 108, a radio connection may be established between UE 122 and eNB 102 and/or gNB 108 by establishing a radio bearer (RB) between UE 122 and eNB 102 and/or gNB 108. The radio bearer used for CP may be called a signaling radio bearer (SRB). The radio bearer used for UP may be called a data radio bearer (DRB Data Radio Bearer). Each radio bearer may be assigned a radio bearer identity (ID). The radio bearer identity for SRB may be called an SRB identity (SRB Identity, or SRB ID). The radio bearer identifier for DRB is the DRB identifier (DRB
This may be referred to as the Device Recipient Identity, or DRB ID.

UE122 may be a terminal device capable of connecting to EPC104 and/or 5GC110 via eNB102 and/or gNB. When the core network to which eNB102 and/or gNB108, with which UE122 communicates, is connected is EPC104, each DRB established between UE122 and eNB102 and/or gNB108 may be uniquely linked to each EPS (Evolved Packet System) bearer passing through EPC104. Each EPS bearer may be identified by an EPS bearer identifier (Identity, or ID). In addition, the same QoS may be guaranteed for data such as IP packets and Ethernet (registered trademark) frames passing through the same EPS bearer.

In addition, when the core network to which the eNB 102 and/or gNB 108 with which the UE 122 communicates is connected is the 5GC 110, each DRB established between the UE 122 and the eNB 102 and/or gNB 108 may be further linked to one of the PDU (Packet Data Unit) sessions established in the 5GC 110. One or more QoS flows may exist in each PDU session. Each DRB may be mapped to one or more QoS flows, or may not be mapped to any QoS flow. Each PDU session may be identified by a PDU session identifier (Identity, Identifier, or ID). Each QoS flow is also identified by a QoS flow identifier Identifier.
In addition, the same QoS may be guaranteed to data such as IP packets and Ethernet frames passing through the same QoS flow.

The PDU session and/or QoS flow may not exist in EPC104. Also, the EPS bearer may not exist in 5GC110. When UE122 is connected to EPC104, UE122 has information of the EPS bearer, but may not have information of the PDU session and/or QoS flow. Also, when UE122 is connected to 5GC110, UE122 has information of the PDU session and/or QoS flow, but may not have information of the EPS bearer.

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.

Figure 2 is a diagram of an example of an E-UTRA protocol architecture according to an embodiment of the present invention. Also, Figure 3 is a diagram of an example of an NR protocol architecture according to an embodiment of the present invention. Note that the functions of each protocol described using Figure 2 and/or Figure 3 are some of the functions closely related to the embodiment of the present invention, and as shown in Non-Patent Documents 1 to 4, etc., it may have other functions. It may also have other functions that are not described in Non-Patent Documents 1 to 4, etc. Note that in the embodiment of the present invention, the uplink (UL) may be a link from a terminal device to a base station device. Also, in each embodiment of the present invention, the downlink (DL) may be a link from a base station device to a terminal device.

Figure 2(A) is a diagram of the E-UTRAN user plane (UP) protocol stack. As shown in Figure 2(A), the E-UTRAN UP protocol may be a protocol between the UE 122 and the eNB 102. That is, the E-UTRAN UP protocol may be a protocol that terminates at the eNB 102 on the network side. As shown in FIG. 2A, the E-UTRA user plane protocol stack may be composed of PHY (Physical layer) 200, which is a radio physical layer described in Non-Patent Document 2, MAC (Medium Access Control) 202, which is a medium access control layer described in Non-Patent Document 2, RLC (Radio Link Control) 204, which is a radio link control layer described in Non-Patent Document 2, and PDCP (Packet Data Convergence Protocol) 206, which is a packet data convergence protocol layer described in Non-Patent Document 2.

Figure 3 (A) is a diagram of the NR user plane (UP) protocol stack. As shown in Figure 3 (A), the NR UP protocol may be a protocol between the UE 122 and the gNB 108. That is, the NR UP protocol may be a protocol that terminates at the gNB 108 on the network side. As shown in Figure 3 (A), the E-UTRA user plane protocol stack may be composed of PHY 300, which is a radio physical layer described in Non-Patent Document 1, etc., MAC 302, which is a medium access control layer described in Non-Patent Document 1, etc., RLC 304, which is a radio link control layer described in Non-Patent Document 1, etc., PDCP 306, which is a packet data convergence protocol layer described in Non-Patent Document 1, etc., and the service data adaptation protocol layer (service data adaptation protocol layer) SDAP (Service Data Adaptation Protocol) 310 described in Non-Patent Document 1, etc.

FIG. 2B is a diagram of the E-UTRA control plane (CP) protocol configuration. As shown in FIG. 2B, in the E-UTRAN CP protocol,
etc., may be a protocol between the UE 122 and the eNB 102. That is, the RRC 208 may be a protocol that terminates at the eNB 102 on the network side. In addition, in the E-UTRAN CP protocol, the NAS (Non Access Stratum) 210, which is a non-AS (Access Stratum) layer, may be a protocol between the UE 122 and the MME. That is, the NAS 210 may be a protocol that terminates at the MME on the network side.

Figure 3 (B) is a diagram of the NR control plane (CP) protocol configuration. As shown in Figure 3 (B), in the NR CP protocol, RRC308, which is a radio resource control layer described in Non-Patent Document 1, Non-Patent Document 3, etc., may be a protocol between UE122 and gNB108. That is, RRC308 may be a protocol that terminates at gNB108 on the network side. Also, in the E-UTRAN CP protocol, NAS312, which is a non-AS layer, may be a protocol between UE122 and AMF. That is, NAS312 may be a protocol that terminates at AMF on the network side.

The AS (Access Stratum) layer may be a layer that terminates between the UE 122 and the eNB 102 and/or the gNB 108. In other words, the AS layer may be a layer that includes some or all of the PHY 200, the MAC 202, the RLC 204, the PDCP 206, and the RRC 208, and/or a layer that includes some or all of the PHY 300, the MAC 302, the RLC 304, the PDCP 306, the SDAP 310, and the RRC 308.

In the embodiments of the present invention, the E-UTRA protocol and the NR protocol are not distinguished from each other, and the terms PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be used. In this case, PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) of the E-UTRA protocol, or the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) of the NR protocol. The SDAP (SDAP layer) may also be the SDAP (SDAP layer) of the NR protocol.

In addition, in the embodiments of the present invention, when distinguishing between the E-UTRA protocol and the NR protocol, PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 may be referred to as PHY for E-UTRA or PHY for LTE, 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. In addition, PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 may be described with spaces as E-UTRA PHY or LTE PHY, E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, E-UTRA RRC or LTE RRC, etc. In addition, when distinguishing between the E-UTRA protocol and the NR protocol, PHY 300, MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as PHY for NT, MAC for NR, RLC for NR, RLC for NR, and RRC for NR, respectively. In addition, PHY 200, MAC 302, RLC 304, PDCP 306, and RRC 308 may be written with spaces between them as NR PHY, NR MAC, NR RLC, NR PDCP, and NR RRC, respectively.

The following describes entities in the AS layer of E-UTRA and/or NR. An entity having some or all of the functions of the MAC layer may be referred to as a MAC entity. An entity having some or all of the functions of the RLC layer may be referred to as an RLC entity. An entity having some or all of the functions of the PDCP layer may be referred to as a PDCP entity. An entity having some or all of the functions of the SDAP layer may be referred to as an SDAP entity. An entity having some or all of the functions of the RRC layer may be referred to as an RRC entity. The MAC entity, RLC entity, PDCP entity, SDAP entity, and RRC entity may be referred to as MAC, RLC, PDCP, SDAP, and RRC, respectively.

The data provided from MAC, RLC, PDCP, and SDAP to the lower layer, and/or the data provided from the lower layer to MAC, RLC, PDCP, and SDAP are respectively referred to as MAC PDU (Protocol Data Unit), RLC PDU, and PDCP PDU.
The data provided to the MAC, RLC, PDCP, and SDAP from higher layers and/or the data provided to the MAC, RLC, PDCP, and SDAP from higher layers may be called MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. The segmented RLC SDU may be called an RLC SDU segment.

An example of the function of the PHY will be described. The PHY of the terminal device may have a function of receiving data transmitted from the PHY of the base station device via a downlink (DL) physical channel. The PHY of the terminal device may have a function of transmitting data to the PHY of the base station device via an uplink (UL) physical channel. The PHY may be connected to a higher MAC via a transport channel. The PHY may pass data to the MAC via the transport channel. The PHY may also be provided with data from the MAC via the transport channel. In the PHY, a Radio Network Temporary Identifier (RNTI) may be used to identify various control information.

Here, we explain physical channels.

The physical channels used for wireless communication between the terminal device and the base station device may include the following physical channels:

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)

The PBCH may be used to broadcast system information required by terminal devices.

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

The PDCCH may be used to transmit (or carry) downlink control information (DCI) in downlink wireless communication (wireless communication from a base station device to a terminal device). Here, one or more DCIs (which may be referred to as DCI formats) may be defined for the transmission of the downlink control information. That is, a field for the downlink control information may be defined as a DCI and mapped to information bits. The PDCCH may be transmitted in PDCCH candidates. The terminal device may monitor a set of PDCCH candidates in the serving cell. Monitoring a set of PDCCH candidates may mean attempting to decode the PDCCH according to a certain DCI format. The DCI format may be used for scheduling the PUSCH in the serving cell. The PUSCH may be used for transmitting user data, transmitting an RRC message to be described later, and the like.

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 (UL-SCH: Uplink Shared CHannel) 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 addition, in the case of downlink, it may be used to transmit system information (SI: System Information) and random access response (RAR: Random Access Response), etc.

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

The PRACH may be used to transmit a random access preamble. The PRACH is also used for initial connection establishment.
It may be used to indicate a request for PUSCH (UL-SCH) resources, a connection re-establishment procedure, a handover procedure, a connection re-establishment procedure, synchronization (timing adjustment) for uplink transmissions, and a request for PUSCH (UL-SCH) resources.

An example of the function of the MAC will be described. The MAC may be called a MAC sublayer. The MAC may have a function of mapping various logical channels to corresponding transport channels. The logical channel may be identified by a logical channel identity (or logical channel ID). The MAC may be connected to the upper RLC by a logical channel. Depending on the type of information to be transmitted, the logical channel may be divided into a control channel that transmits control information and a traffic channel that transmits user information. The logical channel may also be divided into an uplink logical channel and a downlink logical channel. The MAC may have a function of multiplexing MAC SDUs belonging to one or more different logical channels and providing them to the PHY. The MAC may also have a function of demultiplexing the MAC PDU provided from the PHY and providing it to the upper layer via the logical channel to which each MAC SDU belongs. The MAC may also have a function of performing error correction through HARQ (Hybrid Automatic Repeat reQuest). The MAC may also have a Scheduling Report (SR) function that reports scheduling information. The MAC may also have a function of performing priority processing between terminal devices using dynamic scheduling. The MAC may also have a function of performing priority processing between logical channels within one terminal device. The MAC may also have a function of performing priority processing of overlapped resources within one terminal device. The E-UTRA MAC may have the function of identifying Multimedia Broadcast Multicast Services (MBMS). The NR MAC may have the function of identifying Multicast/Broadcast Services (MBS). The MAC may have the function of selecting a transport format. The MAC may have a function of performing discontinuous reception (DRX) and/or discontinuous transmission (DTX), a function of executing a random access (RA) procedure, a power headroom report (PHR) function for notifying information on transmittable power, a buffer status report (BSR) function for notifying data volume information of the transmission buffer, and the like. The NR MAC may have a bandwidth adaptation (BA) function. In addition, the MAC PDU format used in the E-UTRA MAC and the MAC PDU format used in the NR MAC may be different. The MAC PDU may also include a MAC control element (MAC CE), which is an element for controlling the MAC.

This article describes the logical channels for uplink (UL) and/or downlink (DL) used in E-UTRA and/or NR.

The BCCH (Broadcast Control Channel) may be a downlink logical channel for broadcasting control information such as system information (SI).

PCCH (Paging Control Channel) may be a downlink logical channel for carrying paging messages.

The Common Control Channel (CCCH) may be a logical channel for transmitting control information between a terminal device and a base station device. The CCCH may be used when the terminal device does not have an RRC connection. The CCCH may also be used between a base station device and multiple terminal devices.

The Dedicated Control Channel (DCCH) may be a logical channel for transmitting dedicated control information in a bidirectional point-to-point manner between a terminal device and a base station device. The dedicated control information may be control information dedicated to each terminal device. The DCCH may be used when the terminal device has an RRC connection.

DTCH (Dedicated Traffic Channel) may be a logical channel for transmitting user data point-to-point between a terminal device and a base station device. DTCH may be a logical channel for transmitting dedicated user data. Dedicated user data may be user data dedicated to each terminal device. DTCH may exist in both uplink and downlink.

The Multicast Traffic Channel (MTCH) may be a point-to-multipoint downlink channel for transmitting data from a base station device to a terminal device. The MTCH may be a multicast logical channel. The MTCH may be used by a terminal device only when the terminal device receives MBMS.

The Multicast Control Channel (MCCH) may be a point-to-multipoint downlink channel for transmitting MBMS control information for one or more MTCHs from a base station device to a terminal device. The MCCH may be a multicast logical channel. The MCCH may be used by a terminal device only when the terminal device is receiving MBMS or is interested in receiving MBMS.

The SC-MTCH (Single Cell Multicast Traffic Channel) may be a point-to-multipoint downlink channel for transmitting data from a base station device to a terminal device using SC-PTM. The SC-MTCH may be a logical channel for multicast. The SC-MTCH may be used by a terminal device only when the terminal device receives MBMS using SC-PTM (Single Cell Point-To-Multipoint).

The SC-MCCH (Single Cell Multicast Control Channel) may be a point-to-multipoint downlink channel for sending MBMS control information for one or more SC-MTCHs from a base station device to a terminal device. The SC-MCCH may be a logical channel for multicast. The SC-MCCH may be used by a terminal device only when the terminal device receives MBMS using SC-PTM or is interested in receiving MBMS using SC-PTM.

This article describes the mapping of logical channels and transport channels for the uplink in E-UTRA and/or NR.

CCCH is an uplink transport channel, UL-SCH (Uplink
It may be mapped to a Shared Channel.

The DCCH is an uplink transport channel, UL-SCH (Uplink
It may be mapped to a Shared Channel.

DTCH is an uplink transport channel, UL-SCH (Uplink
It may be mapped to a Shared Channel.

This article describes the mapping of logical channels and transport channels for the downlink in E-UTRA and/or NR.

The BCCH may be mapped to the downlink transport channel BCH (Broadcast Channel) and/or DL-SCH (Downlink Shared Channel).

The PCCH may be mapped to the PCH (Paging Channel), which is a downlink transport channel.

The CCCH may be mapped to the DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

The DCCH may be mapped to the downlink transport channel, DL-SCH (Downlink Shared Channel).

DTCH may be mapped to DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

The MTCH may be mapped to the MCH (Multicast Channel), which is a downlink transport channel.

The MCCH may be mapped to the MCH (Multicast Channel), which is a downlink transport channel.

The SC-MTCH may be mapped to the DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

The SC-MTCH may be mapped to the DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

An example of the function of the RLC will be described. The RLC may be called an RLC sublayer. The E-UTRA RLC may have a function of segmenting and/or concatenating data provided from the PDCP of the upper layer and providing it to a lower layer. The E-UTRA RLC may have a function of reassembling and re-ordering data provided from the lower layer and providing it to the upper layer. The NR RLC may have a function of adding a sequence number independent of the sequence number added by the PDCP to data provided from the PDCP of the upper layer. The NR RLC may also have a function of segmenting data provided from the PDCP and providing it to the lower layer. The NR RLC may also have a function of reassembling data provided from a lower layer and providing it to a higher layer. The RLC may also have a function of retransmitting data and/or a function of requesting retransmission (Automatic Repeat
reQuest (ARQ). RLC may have a function of performing error correction by ARQ. In order to perform ARQ, control information indicating data that needs to be retransmitted, which is sent from the receiving side of RLC to the transmitting side, may be called a status report. In addition, a status report transmission instruction sent from the transmitting side of RLC to the receiving side may be called a poll. RLC may have a function of detecting data duplication. In addition, RLC may have a function of discarding data. RLC may have three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). In TM, data received from an upper layer is not divided, and an RLC header does not need to be added. The TM RLC entity is a uni-directional entity and may be configured as a transmitting TM RLC entity or a receiving TM RLC entity. In UM, the UM RLC entity performs division and/or concatenation of data received from the upper layer, addition of an RLC header, etc., but does not perform data retransmission control. The UM RLC entity may be a uni-directional entity or a bi-directional entity. If the UM RLC entity is a uni-directional entity, the UM RLC entity may be configured as a transmitting UM RLC entity or a receiving UM RLC entity. If the UM RLC entity is a bi-directional entity, the UM RLC entity may be configured as a UM RLC entity consisting of a transmitting side and a receiving side. In the AM, the division and/or joining of data received from the upper layer, the addition of an RLC header, and the retransmission control of data may be performed. The AM RLC entity is a bidirectional entity and may be configured as an AM RLC consisting of a transmitting side and a receiving side. The data provided to the lower layer in the TM and/or the data provided from the lower layer may be called a TMD PDU. The data provided to the lower layer in the UM and/or the data provided from the lower layer may be called a UMD PDU. The data provided to the lower layer in the AM or the data provided from the lower layer may be called an AMD PDU. The RLC PDU format used in the E-UTRA RLC and the RLC PDU format used in the NR RLC may be different. The RLC PDU may include a data RLC PDU and a control RLC PDU. The data RLC PDU may be called an RLC DATA PDU, and the control RLC PDU may be called an RLC CONTROL PDU.

An example of the function of PDCP will be described. PDCP may be called a PDCP sublayer. PDCP may have a function of maintaining sequence numbers. PDCP may also have a header compression/decompression function for efficiently transmitting user data such as IP packets and Ethernet frames in wireless sections. The protocol used for header compression/decompression of IP packets may be called the ROHC (Robust Header Compression) protocol. The protocol used for header compression/decompression of Ethernet frames may be called the EHC (Ethernet (registered trademark) Header Compression) protocol. PDCP may also have a function of encrypting/decrypting data. PDCP may also have a function of protecting/verifying the integrity of data. PDCP may also have a function of re-ordering. The PDCP may have a function of retransmitting the PDCP SDU. The PDCP may have a function of discarding data using a discard timer. The PDCP may have a function of duplication. The PDCP may have a function of discarding duplicated received data. The PDCP entity is a bidirectional entity and may be composed of a transmitting PDCP entity and a receiving PDCP entity. The PDCP PDU format used in the E-UTRA PDCP may be different from the PDCP PDU format used in the NR PDCP. The PDCP PDU may include a data PDCP PDU and a control PDCP PDU. The data PDCP PDU may be called a PDCP DATA PDU. In addition, the control PDCP PDU may be called a PDCP CONTROL PDU (PDCP Control PDU, PDCP control PDU, PDCP control PDU).

An example of the function of SDAP will be described. SDAP is a service data adaptation protocol layer. SDAP may have a function of mapping the downlink QoS flow sent from 5GC110 to the terminal device via the base station device with the data radio bearer (DRB), and/or mapping the uplink QoS flow sent from the terminal device to 5GC110 via the base station device with the DRB. SDAP may also have a function of storing mapping rule information. SDAP may also have a function of marking the QoS flow identifier (QoS Flow ID: QFI). Note that the SDAP PDU may include a data SDAP PDU and a control SDAP PDU. The data SDAP PDU may be called the SDAP DATA PDU (SDAP Data PDU, SDAP Data PDU). In addition, the control SDAP PDU may be called the SDAP CONTROL PDU (SDAP Control PDU, SDAP Control PDU, SDAP Control PDU). Note that there may be one SDAP entity in the terminal device for each PDU session.

An example of the function of RRC will be described. RRC may have a broadcast function. RRC may have a paging function from EPC104 and/or 5GC110. RRC may have a paging function from eNB102 connected to gNB108 or 5GC100. RRC may also have an RRC connection management function. RRC may also have a radio bearer control function. RRC may also have a cell group control function. RRC may also have a mobility control function. RRC may also have a terminal device measurement reporting and terminal device measurement reporting control functions. RRC may also have a QoS management function. RRC may also have a function of detecting and recovering radio link failure. The RRC may use RRC messages to perform notification, paging, RRC connection management, radio bearer control, cell group control, mobility control, terminal device measurement reporting and terminal device measurement reporting control, QoS management, detection and recovery of radio link failures, etc. Note that the RRC messages and parameters used in E-UTRA RRC may be different from the RRC messages and parameters used in NR RRC.

The RRC message may be sent using the logical channel BCCH, may be sent using the logical channel PCCH, may be sent using the logical channel CCCH, may be sent using the logical channel DCCH, or may be sent using the logical channel MCCH.

The RRC messages sent using the BCCH may include, for example, a Master Information Block (MIB) as described in 3GPP TS 35.110 and/or 3GPP TS 35.110, various types of System Information Blocks (SIBs), and other RRC messages. The RRC messages sent using the PCCH may include, for example, a paging message as described in 3GPP TS 35.110 and/or 3GPP TS 35.110, and other RRC messages.

RRC messages sent in the uplink (UL) direction using the CCCH may include, for example, the RRC setup request message (RRC Setup Request), the RRC resume request message (RRC Resume Request), the RRC reestablishment request message (RRC Reestablishment Request), and the RRC system information request message (RRC System Info Request) described in non-patent document 3. Also, for example, the RRC connection request message (RRC Connection Request), the RRC connection resume request message (RRC Connection Resume Request), the RRC connection reestablishment request message (RRC Connection Reestablishment Request), etc. described in Non-Patent Document 4 may be included. Also, other RRC messages may be included.

The RRC message sent in the downlink (DL) direction using the CCCH may include, for example, the RRC connection reject message (RRC Connection Reject), the RRC connection setup message (RRC Connection Setup), the RRC connection reestablishment message (RRC Connection Reestablishment Reject) described in Non-Patent Document 4. It may also include, for example, the RRC reject message (RRC Reject) and the RRC setup message (RRC Setup) described in Non-Patent Document 3. It may also include other RRC messages.

RRC messages sent in the uplink (UL) direction using the DCCH may include, for example, a measurement report message (Measurement Report) described in non-patent document 4, an RRC connection reconfiguration complete message (RRC Connection Reconfiguration Complete), an RRC connection setup complete message (RRC Connection Setup Complete), an RRC connection reestablishment complete message (RRC Connection Reestablishment Complete), a security mode complete message (Security Mode Complete), and a UE capability information message (UE Capability Information). Also, for example, the measurement report message described in Non-Patent Document 3, the RRC reconfiguration complete message, the RRC setup complete message, the RRC reestablishment complete message, the RRC resume complete message, the security mode complete message, the UE capability information message, etc. may be included. Other RRC messages may also be included.

RRC messages sent in the downlink (DL) direction using DCCH may include, for example, an RRC connection reconfiguration message (RRC Connection Reconfiguration), an RRC connection release message (RRC Connection Release), a security mode command message (Security Mode Command), and a UE capability inquiry message (UE Capability Enquiry) as described in non-patent document 4. Also, for example, the RRC reconfiguration message (RRC Reconfiguration), RRC resume message (RRC Resume), RRC release message (RRC Release), RRC reestablishment message (RRC Reestablishment), security mode command message (Security Mode Command), UE capability inquiry message (UE Capability Enquiry), etc. described in Non-Patent Document 3 may be included. Also, other RRC messages may be included.

An example of the functions of the NAS is described below. The NAS may have an authentication function. The NAS may also have a function for performing mobility management. The NAS may also have a security control function.

The above-mentioned functions of PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS are merely examples, and some or all of the functions may not be implemented. In addition, some or all of the functions of each layer may be included in another layer.

In addition, the layer above the AS layer of the terminal device (not shown) may include an IP layer, and above the IP layer may be a TCP (Transmission Control Protocol) layer, a UDP (User Datagram Protocol) layer, etc. Furthermore, the layer above the AS layer of the terminal device may be an Ethernet layer. This may be called the PDU layer above the AS layer of the terminal device. The PDU layer may include an IP layer, a TCP layer, a UDP layer, an Ethernet layer, etc. An application layer may be present above the IP layer, TCP layer, UDP layer, Ethernet layer, PDU layer, etc. The application layer may include SIP (Session Initiation Protocol) and SDP (Session Description Protocol) used in IMS (IP Multimedia Subsystem), which is one of the service networks standardized in 3GPP. The application layer may also include protocols such as RTP (Real-time Transport Protocol) used for media communication, and/or RTCP (Real-time Transport Control Protocol) and HTTP (HyperText Transfer Protocol) for media communication control. The application layer may also include codecs for various media. The RRC layer may be a layer above the SDAP layer.

Next, the state transition of UE122 in LTE and NR will be described. When UE122 connected to EPC or 5GC has an RRC connection established (RRC connection has been established), UE122 may be in an RRC_CONNECTED state. The state in which the RRC connection is established may include a state in which UE122 holds some or all of the UE context described below. The state in which the RRC connection is established may also include a state in which UE122 can transmit and/or receive unicast data. When the RRC connection is suspended, UE122 may be in an RRC_INACTIVE state. Also, UE 122 may be in the RRC_INACTIVE state when UE 122 is connected to 5GC and the RRC connection is paused. When the UE is neither in the RRC_CONNECTED state nor in the RRC_INACTIVE state, UE 122 may be in the RRC_IDLE state.

In addition, when UE 122 is connected to EPC, it does not have RRC_INACTIVE state, but E-UTRAN may initiate suspension of RRC connection. When UE 122 is connected to EPC, when RRC connection is suspended, UE 122 may transition to RRC_IDLE state while retaining UE AS context and an identifier (resumeIdentity) used for resume. An upper layer (e.g., NAS layer) of the RRC layer of UE 122 may initiate restoration of the suspended RRC connection when UE 122 retains UE AS context, RRC connection restoration is permitted by E-UTRAN, and UE 122 needs to transition from RRC_IDLE state to RRC_CONNECTED state.

The definition of dormancy may be different for UE 122 connected to EPC 104 and UE 122 connected to 5GC 110. In addition, all or part of the procedure for UE 122 to return from dormancy may be different when UE 122 is connected to EPC (dormant in RRC_IDLE state) and when UE 122 is connected to 5GC (dormant in RRC_INACTIVE state).

The RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may be called the connected state, inactive state, and idle state, respectively, or the RRC connected state, RRC inactive state, and RRC idle state.

The UE AS context held by UE122 may be information including all or part of the current RRC setting, the current security context, the PDCP state including the ROHC (RObust Header Compression) state, the C-RNTI (Cell Radio Network Temporary Identifier) used in the source PCell, the cell identifier (cellIdentity), and the physical cell identifier of the source PCell. Note that the UE AS context held by any 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 included in the UE AS context held by UE122.

The security context is the encryption key at the AS level, the NH (Next Hop
The information may include all or part of the following: a 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.

The following describes a cell group (Cell Group) that is set by a base station device for a terminal device. A cell group may be composed of one special cell (SpCell). A cell group may also be composed of one SpCell and one or more secondary cells (SCells). That is, a cell group may be composed of one SpCell and, optionally, one or more SCells. Note that the SpCell in the Master Cell Group (MCG) described later may be called a Primary Cell (PCell). Also, the SpCell in the Secondary Cell Group (SCG) described later may be called a Primary SCG Cell (PSCell). The PCell may be a cell used in the RRC connection establishment procedure when a terminal device in an RRC idle state transitions to an RRC connected state. The PCell may be a cell used in the RRC connection re-establishment procedure in which the terminal device re-establishes the RRC connection. The PCell may be a cell used in the random access procedure during handover. The PSCell may be a cell used in the random access procedure when adding a secondary node (SN) to be described later. The SpCell may be a cell used for purposes other than those described above. In addition, when a cell group is composed of an SpCell and one or more SCells, it may be said that carrier aggregation (CA) is configured in this cell group.

In addition, when Dual Connectivity (DC) described in Non-Patent Document 4 and the like or Multi-Radio Dual Connectivity (MR-DC) described in Non-Patent Document 5 and the like is performed, a cell group may be added from the base station device to the terminal device. DC may be a technology for performing data communication using radio resources of cell groups respectively configured by a first base station device (first node) and a second base station device (second node). MR-DC may be a technology included in DC. To perform DC, the first base station device may add a second base station device. The first base station device may be called a master node (Master Node: MN). Also, the cell group configured by the master node may be called a master cell group (Master Cell Group: MCG). The second base station device may be called a secondary node (Secondary Node: SN). Furthermore, a cell group formed by a secondary node may be called a secondary cell group (SCG). The master node and the secondary node may be formed within the same base station device.

In addition, when DC is not configured, the cell group configured in the terminal device may be called MCG. In addition, when DC is not configured, the SpCell configured in the terminal device may be PCell.

As described in Non-Patent Document 5, MR-DC may be a technology that performs DC using E-UTRA for MCG and NR for SCG. MR-DC may also be a technology that performs DC using NR for MCG and E-UTRA for SCG. MR-DC may also be a technology that performs DC using NR for both MCG and SCG. As an example of MR-DC using E-UTRA for MCG and NR for SCG, EN-DC (E-UTRA-NR Dual Connectivity) using EPC for the core network may be used, and NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity) using 5GC for the core network may be used. As an example of MR-DC using NR for MCG and E-UTRA for SCG, NE-DC (NR-E-UTRA Dual Connectivity) using 5GC for the core network may be used.
As an example of MR-DC using NR for both MCG and SCG, there may be NR-DC (NR-NR Dual Connectivity) using 5GC for the core network.

In addition, in the terminal device, one MAC entity may exist for each cell group. For example, when DC or MR-DC is configured in the terminal device, one MAC entity for the MCG and one MAC entity for the SCG may exist. The MAC entity for the MCG in the terminal device may always be established in the terminal device in all states (RRC idle state, RRC connected state, RRC inactive state, etc.). The MAC entity for the SCG in the terminal device may be created by the terminal device when the SCG is configured in the terminal device. The MAC entity for each cell group of the terminal device may be configured by receiving an RRC message from the base station device. In EN-DC and NGEN-DC, the MAC entity for the MCG may be an E-UTRA MAC entity, and the MAC entity for the SCG may be an NR MAC entity. Also, in the NE-DC, the MAC entity for the MCG may be an NR MAC entity, and the MAC entity for the SCG may be an E-UTRA MAC entity. Also, in the NR-DC, the MAC entities for the MCG and SCG may both be NR MAC entities. Note that the existence of one MAC entity for each cell group may be rephrased as the existence of one MAC entity for each SpCell. Also, one MAC entity for each cell group may be rephrased as one MAC entity for each SpCell.

Radio bearers are described below. SRB0 to SRB2 may be defined as the SRBs of E-UTRA, or other SRBs may be defined. SRB0 to SRB3 may be defined as the SRBs of NR, or other SRBs may be defined. SRB0 may be the SRB for RRC messages that are transmitted and/or received using the logical channel CCCH. SRB1 may be the SRB for RRC messages and for NAS messages before the establishment of SRB2. RRC messages that are transmitted and/or received using SRB1 may include piggybacked NAS messages. The logical channel DCCH may be used for all RRC messages and NAS messages that are transmitted and/or received using SRB1. SRB2 may be an SRB for NAS messages and for RRC messages including logged measurement information. All RRC and NAS messages transmitted and/or received using SRB2 may use the logical channel DCCH. SRB2 may also have a lower priority than SRB1. SRB3 may be an SRB for transmitting and/or receiving specific RRC messages when EN-DC, NGEN-DC, NR-DC, etc. are configured in the terminal device. All RRC and NAS messages transmitted and/or received using SRB3 may use the logical channel DCCH. Other SRBs may also be provided for other purposes. DRB may be a radio bearer for user data. RRC messages transmitted and/or received using DRB may use the logical channel DTCH.

A radio bearer in a terminal device will be described. The radio bearer may include an RLC bearer. The RLC bearer may be composed of one or two RLC entities and logical channels. When there are two RLC entities in an RLC bearer, the RLC entities may be a TM RLC entity and/or a transmitting RLC entity and a receiving RLC entity in a unidirectional UM mode RLC entity. SRB0 may be composed of one RLC bearer. The RLC bearer of SRB0 may be composed of a TM RLC entity and logical channels. SRB0 may be always established in a terminal device in all states (RRC idle state, RRC connected state, RRC inactive state, etc.). SRB1 may be established and/or configured in the terminal device by an RRC message received from a base station device when the terminal device transitions from an RRC idle state to an RRC connected state. SRB1 may be composed of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB1 may be composed of an AM RLC entity and a logical channel. SRB2 may be established and/or configured in the terminal device by an RRC message received from the base station device by a terminal device in an RRC connected state with AS security activated. SRB2 may be composed of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB2 may be composed of an AM RLC entity and a logical channel. The PDCP on the base station device side of SRB1 and SRB2 may be placed in the master node. SRB3 may be established and/or configured in the terminal device by an RRC message received from the base station device by a terminal device in an RRC connected state with AS security activated when a secondary node is added or when a secondary node is changed in EN-DC, NGEN-DC, or NR-DC. SRB3 may be a direct SRB between the terminal device and the secondary node. The SRB3 may be composed of one PDCP entity and one or more RLC bearers. The RLC bearer of the SRB3 may be composed of an AM RLC entity and a logical channel. The PDCP on the base station side of the SRB3 may be placed in a secondary node. One or more DRBs may be established and/or configured in the terminal device by an RRC message received from the base station device by the terminal device in an RRC connected state with AS security activated. The DRB may be composed of one PDCP entity and one or more RLC bearers. The RLC bearer of the DRB may be composed of an AM or UM RLC entity and a logical channel.

In the MR-DC, a radio bearer in which the PDCP is placed in the master node may be called an MN terminated bearer. In the MR-DC, a radio bearer in which the PDCP is placed in the secondary node may be called an SN terminated bearer. In the MR-DC, a radio bearer in which the RLC bearer exists only in the MCG may be called an MCG bearer. In the MR-DC, a radio bearer in which the RLC bearer exists only in the SCG may be called an SCG bearer. In the DC, a radio bearer in which the RLC bearer exists in both the MCG and SCG may be called a split bearer.

When MR-DC is configured in a terminal device, the bearer type of SRB1 and SRB2 established/and/or configured in the terminal device may be MN terminated MCG bearer and/or MN terminated split bearer. Also, when MR-DC is configured in a terminal device, the bearer type of SRB3 established/and/or configured in the terminal device may be SN terminated SCG bearer. Also, when MR-DC is configured in a terminal device, the bearer type of DRB established/and/or configured in the terminal device may be any of all bearer types.

For an RLC bearer established and/or configured in a cell group consisting of E-UTRA, the RLC entity established and/or configured may be an E-UTRA RLC. For an RLC bearer established and/or configured in a cell group consisting of NR, the RLC entity established and/or configured may be an NR RLC. When EN-DC is configured in the terminal device, the PDCP entity established and/or configured for the MN terminated MCG bearer may be either an E-UTRA PDCP or an NR PDCP. When EN-DC is configured in the terminal device, the PDCP established and/or configured for radio bearers of other bearer types, i.e., MN terminated split bearer, MN terminated SCG bearer, SN terminated MCG bearer, SN terminated split bearer, and SN terminated SCG bearer, may be an NR PDCP. Also, when NGEN-DC, NE-DC, or NR-DC is configured in the terminal device, the PDCP entity established and/or configured for radio bearers in all bearer types may be the NR PDCP.

In addition, in NR, a DRB established and/or configured in a terminal device may be linked to one PDU session. One SDAP entity may be established and/or configured for one PDU session in the terminal device. The SDAP entity, PDCP entity, RLC entity, and logical channel established and/or configured in the terminal device may be established and/or configured by an RRC message received by the terminal device from the base station device.

Regardless of whether MR-DC is configured, a network configuration in which the master node is eNB102 and the EPC104 is the core network may be called E-UTRA/EPC. A network configuration in which the master node is eNB102 and the 5GC110 is the core network may be called E-UTRA/5GC. A network configuration in which the master node is gNB108 and the 5GC110 is the core network may be called NR or NR/5GC. When MR-DC is not configured, the above-mentioned master node may refer to a base station device that communicates with a terminal device.

Next, handover in LTE and NR will be described. Handover may be a process in which UE 122 in an RRC connected state changes the serving cell. Handover may be performed when UE 122 receives an RRC message instructing handover from eNB 102 and/or gNB 108. The RRC message instructing handover may be a message regarding reconfiguration of the RRC connection including a parameter instructing 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 3). Note that the above-mentioned information element named MobilityControlInfo may be rephrased as a mobility control setting information element, mobility control setting, or mobility control information. The information element named ReconfigurationWithSync may be referred to as a reconfiguration information element with synchronization or a reconfiguration with synchronization. The RRC message instructing a handover may be a message indicating a movement to a cell of another RAT (for example, MobilityFromEUTRACommand described in Non-Patent Document 4, or MobilityFromNRCommand described in Non-Patent Document 3). Handover may be referred to as a reconfiguration with synchronization (reconfiguration with sync). The conditions for UE122 to perform a handover may include some or all of the following: when AS security is activated, when SRB2 is established, and when at least one DRB is established.

The flow of RRC messages transmitted and received between a terminal device and a base station device will be described. FIG. 4 is a diagram showing an example of a flow of a procedure for various settings in the RRC according to an embodiment of the present invention. FIG. 4 shows an example of a 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 creates the RRC message by transmitting system information (SI).
The RRC message may be generated in order to deliver RRC Information and paging information. The base station device may generate an RRC message in order to cause a specific terminal device to perform a process. The process to be performed on a specific terminal device may include, for example, security-related settings, reconfiguration of the RRC connection, handover to a different RAT, suspension of the RRC connection, and release of the RRC connection. The RRC connection reconfiguration process may include, for example, control of the radio bearer (establishment, change, release, etc.), control of the cell group (establishment, addition, change, release, etc.), measurement setting, handover, and security key update. The base station device may generate an RRC message in order to respond to an RRC message transmitted from a terminal device. The response to the RRC message transmitted from the terminal device may include, for example, a response to an RRC setup request, a response to an RRC reconnection request, and a response to an RRC restart request. The RRC message includes information (parameters) for various information notifications and settings. As described in Non-Patent Document 3 or Non-Patent Document 4, these parameters may be called fields and/or information elements, and may be described using a description method called ASN.1 (Abstract Syntax Notation One).

In FIG. 4, the base station device then transmits the created RRC message to the terminal device (step S402). Next, the terminal device performs processing such as setting according to the received RRC message if necessary (step S404). After performing the processing, the terminal device may transmit an RRC message in response to the base station device (not shown).

The RRC message is not limited to the above example, and may be used for other purposes as described in non-patent document 3, non-patent document 4, etc.

In addition, in MR-DC, the RRC on the master node side may be used to transfer RRC messages for SCG side configuration (cell group configuration, radio bearer configuration, measurement configuration, etc.) between the terminal device. For example, in EN-DC or NGEN-DC, the NR RRC message may be included in the form of a container in the E-UTRA RRC message transmitted and received between eNB102 and UE122. Also, in NE-DC, the E-UTRA RRC message may be included in the form of a container in the NR RRC message transmitted and received between gNB108 and UE122. The RRC message for SCG side configuration may be transmitted and received between the master node and the secondary node.

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, and the RRC message for NR transmitted from gNB108 to UE122 may include an RRC message for E-UTRA.

An example of parameters included in an RRC message regarding reconfiguration of an RRC connection will be described. FIG. 7 is an example of an ASN. 1 description representing a field and/or information element related to radio bearer configuration included in a message regarding reconfiguration of an RRC connection in NR in FIG. 4. FIG. 8 is an example of an ASN. 1 description representing a field and/or information element related to radio bearer configuration included in a message regarding reconfiguration of an RRC connection in E-UTRA in FIG. 4. Not limited to FIG. 7 and FIG. 8, in the ASN. 1 examples in the embodiment of the present invention, <Omitted> and <Omitted> indicate that other information is omitted, not a part of the notation of ASN. 1. Note that information elements may be omitted even in places where <Omitted> or <Omitted> is not written. Note that the ASN. 1 examples in the embodiment of the present invention do not correctly follow the ASN. 1 notation method. The ASN. 1 examples in the embodiment of the present invention are examples of parameters of an RRC message in the embodiment of the present invention, and other names and other notations may be used. Also, in the ASN. In order to avoid complicating the explanation, the example in FIG. 1 shows only examples 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. In addition, in the embodiment of the present invention, the fields, information elements, etc. described in ASN.1 included in the RRC message may be referred to as information or parameters. 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 FIG. 7, the information element represented by RadioBearerConfig may be an information element used for setting, changing, releasing, etc., of radio bearers such as SRB and DRB. The information element represented by RadioBearerConfig may include a PDCP setting information element or an SDAP setting information element described below. The information element represented by RadioBearerConfig may be referred to as a radio bearer setting information element or a radio bearer setting. The information element represented by SRB-ToAddMod included in the information element represented by RadioBearerConfig may be an information element indicating an SRB (signaling radio bearer) setting. The information element represented by SRB-ToAddMod may be referred to as an SRB setting information element or an SRB setting. The information element represented by SRB-ToAddModList may be a list of SRB settings. The information element represented by DRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be an information element indicating a DRB (data radio bearer) setting. The information element represented by DRB-ToAddMod may be referred to as a DRB setting information element or a DRB setting. The information element represented by DRB-ToAddModList may be a list of DRB settings. Note that the SRB setting and the DRB setting may be referred to as a radio bearer setting.

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

The field represented by drb-Identity in the DRB setting information element is information on the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. The field represented by drb-Identity in the DRB setting information element may be referred to as the DRB identifier field or DRB identifier. In the example of FIG. 7, the value of the DRB identifier is an integer value from 1 to 32, but it may take another value. In the case of DC, the DRB identifier may be unique within the scope of UE122. The DRB identifier may also be referred to as the radio bearer identifier.

The field represented by cnAssociation in the DRB setting information element may be a field indicating whether the radio bearer is associated with a field represented by eps-bearerIdentity described below, or with an information element represented by SDAP-Config described below. The field represented by cnAssociation may be referred to as a core network association field or core network association. The field represented by cnAssociation may include an EPS bearer identifier field (eps-bearerIdentity) described below when the terminal device connects to EPC104. The field represented by cnAssociation may also include an information element (SDAP-Config) indicating an SDAP setting described below when the terminal device connects to core network 5GC110. The field represented by eps-bearerIdentity may be a field indicating an EPS bearer identifier that identifies the EPS bearer. The field indicated by eps-bearerIdentity may be referred to as the EPS bearer identifier field or the EPS bearer identifier.

The information element represented by SDAP-Config may be information regarding the configuration or reconfiguration of an SDAP entity. The information element represented by SDAP-Config may be referred to as an SDAP configuration information element or an SDAP configuration.

The field indicated by pdu-session included in the SDAP configuration information element may be the PDU session identifier of the PDU session to which the QoS flow mapped to the corresponding radio bearer belongs. The field indicated by pdu-session may be referred to as the PDU session identifier field or the PDU session identifier. The PDU session identifier may be the PDU session identifier of the PDU session described in Non-Patent Document 1. The corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

The field 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) fields of uplink QoS flows to be additionally mapped to the corresponding radio bearer. The field indicated by mappedQoS-FlowsToAdd may be referred to as an additional QoS flow field or an additional QoS flow. The above-mentioned QoS flow may be a QoS flow of a PDU session indicated by a PDU session included in this SDAP configuration information element. The corresponding radio bearer may be a DRB linked to a DRB identifier of a DRB configuration including this SDAP configuration field.

The field indicated by mappedQoS-FlowsToRelease included in the SDAP configuration information element may be information indicating a list of QoS flow identifier information elements of the QoS flows to be released among the QoS flows mapped to the corresponding radio bearer. The field indicated by mappedQoS-FlowsToRelease may be referred to as the QoS flow field to be released or the QoS flow to be released. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session included in this SDAP configuration information element. The corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

The SDAP setting information element may also include a field indicating whether an uplink SDAP header is present in the uplink data transmitted via the radio bearer, a field indicating whether a downlink SDAP header is present in the downlink data received via the radio bearer, and a field indicating whether the radio bearer is a default radio bearer (default DRB). The radio bearer may be a DRB associated with the DRB identifier of the DRB setting including this SDAP setting field.

In addition, among the SRB configuration information element and the DRB configuration information element, the information element represented by PDCP-Config may be an information element regarding the configuration of the NR PDCP entity. The information element represented by PDCP-Config may be referred to as a PDCP configuration information element or a PDCP configuration. The information element regarding the configuration of the NR PDCP entity may include a field indicating the size of the uplink sequence number, a field indicating the size of the downlink sequence number, a field indicating the profile of the header compression (RoHC: RObust Header Compression), a field indicating the value of the re-ordering timer, and the like.

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 FIG. 8, the information element represented by RadioResourceConfigDedicated may be an information element used for setting, changing, releasing, etc., of a radio bearer. The information element represented by SRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating SRB (signaling radio bearer) setting. The information element represented by SRB-ToAddMod may be rephrased as an SRB setting information element or SRB setting. The information element represented by SRB-ToAddModList may be a list of information indicating SRB setting. The information element represented by DRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating DRB (data radio bearer) setting. The information element represented by DRB-ToAddMod may be referred to as a DRB setting information element or DRB setting. The information element represented by DRB-ToAddModList may be a list of information indicating the DRB setting. Note that any or all of the SRB setting and the DRB setting may be referred to as a radio bearer setting.

The field represented by srb-Identity in the SRB setting information element is information of 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 field represented by srb-Identity may be referred to as an SRB identifier field or an SRB identifier. The SRB identifier may be referred to as a radio bearer identifier. The SRB identifier in FIG. 8 may have the same role as the SRB identifier in FIG. 7.

The field represented by drb-Identity in the DRB setting is information on the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. The field represented by drb-Identity in the DRB setting information element may be referred to as the DRB identifier field or DRB identifier. The value of the DRB identifier is an integer value from 1 to 32 in the example of Figure 8, but it may take a different value. The DRB identifier may also be referred to as the radio bearer identifier. The DRB identifier in Figure 8 may have the same role as the DRB identifier in Figure 7.

The field represented by eps-BearerIdentity in the DRB setting information element may be an EPS bearer identifier that uniquely identifies the EPS bearer in each terminal device. The field represented by eps-BearerIdentity may be referred to as an EPS bearer identifier field or an EPS bearer identifier. The value of the EPS bearer identifier is an integer value from 1 to 15 in the example of FIG. 8, but may take a different value. The EPS bearer identifier in FIG. 8 may have the same role as the EPS bearer identifier in FIG. 7. Furthermore, the EPS bearer identifier and the DRB identifier may have a one-to-one correspondence in each terminal device.

Among the SRB configuration information element and the DRB configuration information element, the information element represented by PDCP-Config may be an information element related to the configuration of the E-UTRA PDCP entity. The information element represented by PDCP-Config may be referred to as a PDCP configuration information element or a PDCP configuration. The information element related to the configuration of the E-UTRA PDCP entity may include a field indicating the size of the sequence number, a field indicating the size of the header compression (RoHC: RObust
The field may include a field indicating a Header Compression profile, a field indicating a re-ordering timer value, and the like.

The SRB configuration information element shown in FIG. 8 may further include a field related to E-UTRA RLC entity configuration (not shown). The field related to E-UTRA RLC entity configuration may be referred to as an RLC configuration field or an RLC configuration. The SRB configuration information element shown in FIG. 8 may further include an information element related to logical channel configuration (not shown). The information element related to logical channel configuration may be referred to as a logical channel configuration information element or a logical channel configuration.

The DRB configuration information element shown in FIG. 8 may further include an information element regarding E-UTRA RLC entity configuration (not shown). The information element regarding E-UTRA RLC entity configuration may be referred to as an RLC configuration information element or an RLC configuration. The DRB configuration information element shown in FIG. 8 may include a field indicating logical channel identifier (identity: ID) information. The field indicating logical channel identifier (identity: ID) information may be referred to as a logical channel identifier field or a logical channel identifier. The DRB configuration information element shown in FIG. 8 may further include an information element regarding logical channel configuration (not shown). The information element regarding logical channel configuration may be referred to as a logical channel configuration information element or a logical channel configuration. The logical channel identifier may be linked to a radio bearer identifier.

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

In addition, in the NR, information elements regarding RLC bearer configuration, such as information elements regarding NR RLC entity configuration for each radio bearer, information elements indicating logical channel identifier (identity: ID) information, and information elements regarding logical channel configuration, may be included in information elements regarding cell group configuration (not shown) rather than information elements represented by RadioBearerConfig in FIG. 7. Information elements regarding cell group configuration may be included in messages regarding reconfiguration of RRC connections. Information elements regarding cell group configuration may be rephrased as cell group configuration information elements or cell group configuration. Information elements regarding NR RLC entity configuration may be rephrased as RLC configuration information elements or RLC configuration. Information elements indicating logical channel identifier information may be rephrased as logical channel identifier information elements or logical channel identifiers. Information elements regarding logical channel configuration may be rephrased as logical channel configuration information elements or logical channel identifiers. Note that the logical channel identifier may be linked to a radio bearer identifier.

Furthermore, some or all of the fields and information elements described using FIG. 7 or FIG. 8 may be optional. That is, the fields and information elements described using FIG. 7 or FIG. 8 may be included in a message regarding reconfiguration of the RRC connection according to necessity or conditions. Furthermore, a message regarding reconfiguration of the RRC connection may include, in addition to information elements regarding the configuration of the radio bearer, a field indicating that the full configuration is applied. The field indicating that the full configuration is applied may be represented by an information element name such as fullConfig, and may indicate that the full configuration is applied using true, enable, etc.

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.

Figure 5 is a block diagram showing the configuration of a terminal device (UE122) in an embodiment of the present invention. Note that in order 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 is composed of a receiver 500 that receives an RRC message or the like from a base station device, a processor 502 that performs processing according to parameters included in the received message, and a transmitter 504 that transmits an RRC message or the like to the base station device. The above-mentioned 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., a physical layer, a MAC layer, an RLC layer, a PDCP layer, an SDAP layer, an RRC layer, and an NAS layer). That is, the processor 502 may include some or all of the physical layer processor, the MAC layer processor, the RLC layer processor, the PDCP layer processor, the SDAP processor, the RRC layer processor, and the NAS layer processor.

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

The base station device shown in FIG. 6 is composed of a transmitter 600 that transmits an RRC message, etc. to UE 122, a processor 602 that creates an RRC message including parameters and transmits it to UE 122 to cause the processor 502 of UE 122 to process it, and a receiver 604 that receives an RRC message, etc. from UE 122. The processor 602 may include some or all of the functions of various layers (e.g., physical layer, MAC layer, RLC layer, PDCP layer, SDAP 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, SDAP processor, RRC layer processor, and NAS layer processor.

A conditional handover (CHO) in an embodiment of the present invention will be described. The conditional handover may be the conditional handover described in Non-Patent Document 1, Non-Patent Document 3, etc. The terminal device may be configured for the conditional handover by receiving an RRC message including parameters for the conditional handover setting from the base station device. The parameters for the conditional handover setting may include a setting parameter for the target candidate SpCell and an execution condition parameter for applying the setting to the target candidate SpCell to execute the handover. The conditional handover may be a handover in which the terminal device executes a handover procedure when one or more execution conditions are satisfied. The conditional handover may be referred to as a conditional reconfiguration. The conditional handover may also be referred to as a handover. In addition, an RRC message including a conditional handover setting information element may be a message regarding reconfiguration of an RRC connection or an RRC reconfiguration message.

Figure 9 is an example of an ASN.1 description representing fields and/or information elements related to conditional handover configuration in an embodiment of the present invention. The information element represented by ConditionalReconfiguration in Figure 9 may be an information element indicating a target candidate SpCell in a conditional handover and a condition for executing the conditional handover. The information element represented by ConditionalReconfiguration may be referred to as a conditional handover configuration information element or a conditional handover configuration. The conditional handover configuration information element may also be used for a conditional PSCell change.

In FIG. 9, the field represented by attemptCondReconfig included in the conditional handover setting information element may be a setting indicating that, if this field exists, a conditional reconfiguration is performed on the candidate SpCell if the first selected cell after a conditional handover fails is one of the candidate SpCells included in the conditional handover setting information element. The field represented by attemptCondReconfig may be referred to as an attempt conditional reconfiguration field or an attempt conditional reconfiguration.

In FIG. 9, the information element represented by CondReconfigToRemoveList included in the conditional handover setting information element may be a list of candidate SpCells to be removed. The information element represented by CondReconfigToRemoveList may be rephrased as the conditional reconfiguration list information element to be removed, or the conditional reconfiguration list to be removed. The conditional reconfiguration list information element to be removed may be a list of information elements represented by CondReconfigId, which will be described later.

In FIG. 9, the information element represented by CondReconfigToAddModList included in the conditional handover setting information element may be a list of settings of the candidate SpCell to be added or changed. The information element represented by CondReconfigToAddModList may be rephrased as a conditional reconfiguration list information element or a conditional reconfiguration list. The conditional reconfiguration list information element may be a list of information elements represented by CondReconfigToAddMod. The information element represented by CondReconfigToAddMod may be rephrased as a conditional reconfiguration information element or a conditional reconfiguration.

9, a field represented by condReconfigId included in the conditional reconfiguration information element may be an identifier for identifying the configuration of a conditional handover or a conditional PSCell change. The field represented by condReconfigId may be referred to as a conditional reconfiguration identifier field or a conditional reconfiguration identifier.

In FIG. 9, the field represented by condExecutionCond included in the conditional reconfiguration information element may be an execution condition that must be satisfied to trigger the execution of the conditional reconfiguration. The field represented by condExecutionCond may be referred to as a conditional reconfiguration execution condition field or a conditional reconfiguration execution condition. The reconfiguration execution condition field may include one or more identifiers that identify the measurement configuration.

In FIG. 9, the information element represented by condRRCReconfig, which is included in the conditional reconfiguration information element, may be an RRC reconfiguration message that is applied when the conditional reconfiguration execution condition indicated in the above-mentioned conditional reconfiguration execution condition field is satisfied. That is, the information element represented by condRRCReconfig may include some or all of the information elements and/or fields included in the RRC reconfiguration message described in Non-Patent Document 3. The information element represented by condRRCReconfig may be referred to as a conditional reconfiguration information element or a conditional reconfiguration. In addition, it may be prohibited to include a conditional reconfiguration information element in the information elements and/or fields of the RRC reconfiguration message included in the conditional reconfiguration information element.

The above-mentioned conditional reconfiguration information element may include, for example, some or all of the following settings (A) to (F).
(A) Cell group configuration (which may be an information element represented by CellGroupConfig described in Non-Patent Document 3).
(B) Information indicating whether or not a full configuration is performed (this may be a field represented by fullConfig described in Non-Patent Document 3).
(C) A NAS layer message (which may be an information element represented by a DedicatedNAS-message described in non-patent document 3).
(D) Key update setting (which may be an information element represented by MasterKeyUpdate described in Non-Patent Document 3).
(E) Measurement configuration (which may be an information element represented by MeasConfig described in Non-Patent Document 3).
(F) Radio bearer setup.

Furthermore, the above-mentioned cell group configuration information may include, for example, some or all of the following settings (1) to (6).
(1) A cell group identifier (which may be an information element represented by CellGroupId described in Non-Patent Document 3).
(2) RLC bearer configuration (which may be an information element represented by RLC-BearerConfig described in non-patent document 3).
(3) MAC layer configuration of a cell group (which may be an information element represented by MAC-CellGroupConfig described in Non-Patent Document 3).
(4) Physical (PHY) layer configuration of a cell group (which may be an information element represented by PhysicalCellGroupConfig described in Non-Patent Document 3).
(5) SpCell configuration (which may be an information element represented by SpCellConfig described in Non-Patent Document 3).
(6) Information of SCell (which may be an information element represented by SCellConfig described in Non-Patent Document 3).
The SpCell configuration in (5) may include a synchronous reconfiguration information element.
The synchronized reconfiguration information element included in the pCell configuration may include a physical cell identifier of the target candidate SpCell (which may be an information element represented by PhysCellId described in non-patent document 3).

Furthermore, the above-mentioned radio bearer configuration may include some or all of the following configurations (1) to (3).
(1) SRB setting (2) DRB setting (3) Security setting (which may be an information element represented by SecurityConfig described in Non-Patent Document 3).
(3) The security settings may include information regarding the integrity protection algorithm and encryption algorithm for the SRB and/or DRB (which may be an information element represented by SecurityAlgorithmConfig described in non-patent document 3), and/or information indicating whether to use an MCG key or an SCG key (which may be a field represented by keyToUse described in non-patent document 3).

The above-mentioned candidate SpCell may be referred to as a target candidate SpCell. SpCell may also be referred to as a Cell, PCell, or PSCell.

An example of the processing of a terminal device in an embodiment of the present invention will be described with reference to FIG. 10. The example of the processing of a terminal device in an embodiment of the present invention, which will be described with reference to FIG. 10, is an example of resolving a security issue that may occur when contention-based random access, as described in Non-Patent Document 1, etc., is used for a conditional handover that does not involve security key update and that is executed by the terminal device, and the above-mentioned conditional handover fails.

Figure 10 is a diagram showing an example of the processing of a terminal device in an embodiment of the present invention. The receiver 500 of the UE 122 may receive an RRC message from the base station device. The processor 502 of the UE 122 may configure the UE 122 according to the RRC message received from the base station device. (Step S1000)

An example of the start of the handover procedure in step S1002 will be described. In step S1000, for example, if the RRC message received from the base station device includes a first synchronization-added reconfiguration information element, and the above-mentioned first synchronization-added reconfiguration information element is not an information element included in the conditional handover setting information element, the processing unit 502 of the UE 122 may apply the above-mentioned first synchronization-added reconfiguration information element and start the handover procedure for the first SpCell according to the above-mentioned first synchronization-added reconfiguration information element. When the above-mentioned RRC message received from the base station device includes a first synchronization-added reconfiguration information element, and the above-mentioned first synchronization-added reconfiguration information element is not an information element included in the conditional handover setting information element, this may be a case of non-conditional handover or normal handover. Note that if the above-mentioned first synchronization-added reconfiguration information element is not included in the RRC message received from the base station device, the handover procedure for the above-mentioned first SpCell does not need to be started. (Step S1002)

Another example of the handover procedure start in step S1002 will be described. In step S1000, for example, if the RRC message received from the base station device includes a conditional handover setting information element, the processing unit 502 of the UE 122 may configure the UE 122 according to the above-mentioned conditional handover setting information element. Here, the above-mentioned handover setting information element may include a conditional reconfiguration list information element. Also, the above-mentioned conditional reconfiguration list information element may include first to Nth conditional reconfiguration information elements (where N is a positive number). At a certain point in time, if the Nth conditional reconfiguration execution condition included in the Nth conditional reconfiguration information element set in the UE 122 is satisfied, the processing unit 502 of the UE 122 may perform the following process including (A).
(A) The Nth conditional reconfiguration information element included in the above-mentioned Nth conditional reconfiguration information element may be applied, and a handover procedure may be initiated for the Nth SpCell in accordance with the Nth synchronized reconfiguration information element included in the above-mentioned Nth conditional reconfiguration information element.
The handover to the Nth SpCell may be rephrased as a conditional handover to the Nth SpCell. If the Nth conditional reconfiguration execution condition is not satisfied, the processing unit 502 of the UE 122 does not need to perform the process (A) described above (step S1002).

In step S1002, the above-mentioned first SpCell and the above-mentioned Nth SpCell may be the same cell. Also, in step S1002, the processing unit 502 of UE 122 may start the first timer for the above-mentioned first SpCell when performing handover to the above-mentioned first SpCell. Also, in step S1002, the processing unit 502 of UE 122 may start the above-mentioned first timer for the above-mentioned Nth SpCell when performing handover to the above-mentioned Nth SpCell. When starting the above-mentioned first timer for the above-mentioned first SpCell, the processing unit 502 of UE 122 may apply the value to be applied to the above-mentioned first timer, which is included in the above-mentioned first synchronized reconfiguration information element, to the above-mentioned first timer. Furthermore, when activating the first timer for the Nth SpCell, the processing unit 502 of the UE 122 may apply the value to be applied to the first timer, which is included in the Nth synchronized reconfiguration information element, to the first timer. The first timer may be a timer used to detect handover failure, etc. The first timer may be a timer that is started when an RRC message instructing handover is received, and stopped when random access to the corresponding (handover destination) SpCell is successful. If the first timer expires, the handover may be considered to have failed. The first timer may be a timer named T304 described in Non-Patent Document 3.

When the above-mentioned first timer expires, the processing unit 502 of the UE 122 may perform a handover failure procedure. Note that a handover failure may be rephrased as a synchronous reconfiguration failure. (Step S1004)

In the handover failure procedure of step S1004, the processing unit 502 of the UE 122 checks whether a first setting has been made to the UE 112. The above-mentioned first setting may be the above-mentioned conditional reconfiguration. That is, the above-mentioned first setting may be a setting indicating that, when the first selected cell after the conditional handover fails is one of the candidate SpCells included in the conditional handover setting information element, conditional reconfiguration is performed for the candidate SpCell. In addition, the fact that the above-mentioned first setting has been made may be rephrased as the conditional handover setting information element including the attempt conditional reconfiguration field was included (or is included) in the RRC message received in step S1000. The processing unit 502 of the UE 122 may also check whether the handover of the UE 122 in step S1002 was accompanied by a security key update. The handover of UE 122 in step S1002 accompanied by security key update may be rephrased as the above-mentioned Nth conditional reconfiguration information element containing (or containing) the above-mentioned parameters related to key update configuration. The handover of UE 122 in step S1002 did not involve security key update may be rephrased as the above-mentioned Nth conditional reconfiguration information element did not contain (or does not contain) the parameters related to key update configuration. The handover of UE 122 in step S1002 may be rephrased as a previous handover, a handover, or a synchronous reconfiguration. The handover of UE 122 in step S1002 may be rephrased as a term that means a handover that caused the expiration of the first timer in step 1002. The above-mentioned parameters related to key update configuration may be an information element represented by MasterKeyUpdate and/or a field represented by masterKeyUpdate described in Non-Patent Document 3 and the like. Note that security key update can be referred to as key update.

In the handover failure procedure of step S1004, the processing unit 502 of the UE 122 may perform processing including some or all of the following (A) to (B) based on the fact that the first condition is satisfied.
(A) For some or all of the radio bearers established and/or configured in the UE 122, the settings of the UE 122 other than the state variables of the PDCP entity are reverted back to the settings used in the source PCell.
(B) In the above (A), where no process is performed to restore the settings of UE 122 other than the state variables of the PDCP entity to the settings used in the source PCell, for some or all of the radio bearers established and/or configured in UE 122, the settings of UE 122 are restored to the settings used in the source PCell.
In the above (A), a part or all of the radio bearers established and/or configured in the UE 122 may be a part or all of the SRBs established and/or configured in the UE 122. In addition, in the above (B), a part or all of the radio bearers established and/or configured in the UE 122, in which the process of restoring the settings of the UE 122 other than the state variables of the PDCP entity to the settings used in the source PCell is not performed, may be a part or all of the DRBs established and/or configured in the UE 122. That is, the above processes (A) and (B) may be rephrased as follows.
(A) For some or all of the SRBs established and/or configured in UE 122, the settings of UE 122, other than the state variables of the PDCP entity, are restored to the settings used in the source PCell.
(B) For some or all of the DRBs established and/or configured in UE 122, revert the settings of UE 122 back to the settings used in the source PCell.

The above-mentioned first condition in the handover failure procedure of step S1004 may be a condition including that the above-mentioned first setting is made in UE 122 and/or that the handover of UE 122 in step S1002 did not involve a security key update. The above-mentioned first condition may be a condition including at least that the above-mentioned first setting is made in UE 122 and that the handover of UE 122 in step S1002 did not involve a security key update.

In addition, in the handover failure procedure of step S1004, the process of restoring all or some of the radio bearers established and/or configured in UE 122 described above (A) to the settings of UE 122 used in the source PCell, other than the state variables of the PDCP entity, may be a process that includes all or some of the following processes (1) to (2) for all or some of the radio bearers established and/or configured in UE 122.
(1) Revert the settings of UE 122 to the settings used in the source PCell.
(2) Set the state variables of the PDCP entity to those of the PDCP entity of the target PCell (or that was used in the target PCell).

In addition, in the handover failure procedure of step S1004, the processing unit 502 of the UE 122 may perform a process of returning the settings of the UE 122 to the settings used in the source PCell based on the fact that the above-mentioned first condition is not satisfied. The fact that the above-mentioned first condition is not satisfied may be the fact that some or all of the following conditions are not met: the above-mentioned first setting is performed in the UE 122, and the handover of the UE 122 in step S1002 was not accompanied by key updating.

In addition, in the handover failure procedure of step S1004, the processing unit 502 of UE 122 may perform processing including some or all of the following processing (C) to (D) based on the satisfaction of the first condition described above, after restoring the settings of UE 122 to the settings used in the source PCell.
(C) For some or all of the radio bearers established and/or configured in UE 122, the settings of UE 122 other than the state variables of the PDCP entity are restored to the settings used in the source PCell.
(D) For some or all of the radio bearers established and/or configured in UE 122, set the state variables of the PDCP entity of the target PCell (or that was used in the target PCell) in the state variables of the PDCP entity.
In addition, in the above (C) and/or (D), some or all of the radio bearers established and/or configured in UE 122 may be rephrased as some or all of the SRBs established and/or configured in UE 122.

Also, in the handover failure procedure of step S1004, the processing unit 502 of UE 122 may perform processing including the following processing (E) based on the fact that the above-mentioned first condition is not satisfied, after restoring the settings of UE 122 to the settings used in the source PCell.
(E) Revert the settings of UE 122 back to the settings used in the source PCell.

In the handover failure procedure in step S1004, in the above-mentioned process (A) and process (C), "For some or all of the radio bearers established and/or configured in UE122, the settings of UE122 other than the state variables of the PDCP entity are restored to the settings used in the source PCell." may be rephrased as "The settings of UE122 other than the state variables of the PDCP entity are restored to the settings used in the source PCell." In the handover failure procedure in step S1004, in the above-mentioned process (D), "For some or all of the radio bearers established and/or configured in UE122, the state variables of the PDCP entity of the target PCell (or that was used in the target PCell) are set to the state variables of the PDCP entity." may be rephrased as "The state variables of the PDCP entity of the target PCell (or that was used in the target PCell) are set to the state variables of the PDCP entity."

In addition, in the handover failure procedure of step S1004, not satisfying the first condition described above may be rephrased as an "else" condition in addition to satisfying the first condition described above.

In addition, in the handover failure processing in step S1004, the processing unit 502 of the UE 122 may further perform processing including some or all of the following processing (F) to (G).
(F) Store information regarding the above-mentioned handover failure in a variable related to the radio link failure of UE 122.
(G) Initiate the RRC connection re-establishment procedure.
The above-mentioned (F) variable related to radio link failure may be a variable named VarRLF-Report described in Non-Patent Document 3, etc. Furthermore, the above-mentioned (G) RRC connection re-establishment procedure may be an RRC re-establishment procedure described in Non-Patent Document 3, etc. The RRC re-establishment procedure may include a procedure in which a terminal device selects a cell for re-establishing an RRC connection, transmits an RRC re-establishment request message to a base station device, and receives an RRC re-establishment message from the base station device.

In the above-mentioned RRC reconnection procedure after the handover failure processing in step S1004 (not shown), the processing unit 502 of UE 122 may set the state variables of the PDCP entity of the target PCell (or that was used in the target PCell) for some or all of the radio bearers established and/or configured in UE 122 based on the fact that some or all of the following conditions (1) to (4) are met.
(1) The first setting described above is performed on UE 122.
(2) The handover of UE 122 in step S1002 did not involve key updating.
(3) The selected cell is one of the candidate SpCells for conditional handover.
(4) The conditional handover to the selected cell described above does not involve key updating.
Note that some or all of the radio bearers established and/or configured in the UE 122 may be some or all of the SRBs established and/or configured in the UE 122. In addition, the above-mentioned "for some or all of the radio bearers established and/or configured in the UE 122, the state variables of the PDCP entity of the target PCell (or that was used in the target PCell) are set in the state variables of the PDCP entity" may be rephrased as "the state variables of the PDCP entity of the target PCell (or that was used in the target PCell) are set in the state variables of the PDCP entity."

The handover failure process in step S1004 described above may be performed based on the fact that some or all of the following conditions (H) to (I) are not met.
(H) A DAPS (Dual Active Protocol Stack) bearer is established.
(I) No radio link failure in the source PCell has been detected.
The DAPS bearer in (H) above may be the DAPS bearer described in Non-Patent Document 3 and the like. The DAPS bearer may be a radio bearer having part or all of the radio (AS) protocol in both the source and the target since it uses resources of both the source and the target during DAPS handover. The source may be the source PCell. The source may be a source base station device. The target may be a target PCell. The target may be a target base station device.

In an embodiment of the invention, the "UE122 settings" when restoring the UE122 settings to the settings used in the source PCell may include the state variables and parameters of each radio bearer. Also, in an embodiment of the invention, the "UE122 settings" when restoring the UE122 settings to the settings used in the source PCell may include the state variables and parameters of each radio bearer, unless otherwise specified.

In an embodiment of the invention, Cell, PCell, SpCell, PSCell, MCG, SCG, and cell group may be interchangeable.

In this way, in an embodiment of the present invention, efficient communication can be performed during handover of a terminal device.

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

In the above description, the expressions "link,""associate,""relate," etc. are
They may be interchangeable.

In addition, in the examples of each process or process flow in the above description, some or all of the steps may not be executed. In addition, in the examples of each process or process flow in the above description, the order of the steps may be different. In the examples of each process or process flow in the above description, some or all of the processes in each step may not be executed. In the examples of each process or process flow in the above description, the order of the processes in each step may be different. In addition, in the above description, "doing B based on A being true" may be rephrased as "doing B". In other words, "doing B" may be executed independently of "being A".

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

In addition, 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, base station device, and method in the embodiments of the present invention.

(1) A terminal device that communicates with a base station device, the terminal device comprising a receiving unit that receives an RRC message from the base station device, and a processing unit, the processing unit performs settings on the terminal device according to the RRC message, performs handover failure processing based on the expiration of a first timer of the terminal device, and performs processing to restore the settings of the terminal device other than the state variables of the PDCP entity for each SRB to the settings used in the source PCell based on the satisfaction of a first condition in the handover failure processing, and performs processing to restore the settings of the terminal device other than the state variables of the PDCP entity for each DRB to the settings used in the source PCell based on the satisfaction of a first condition in the handover failure processing. A process of restoring the settings of the terminal device to the settings used in the source PCell is performed, and in the handover failure process, a process of restoring the settings of the terminal device to the settings used in the source PCell is performed based on the fact that the first condition is not satisfied, the first condition including at least that the terminal device has a first setting and that the conditional handover performed by the terminal device does not involve key updating, and the conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

(2) A base station device that communicates with a terminal device, the base station device comprising: a transmission unit that transmits an RRC message to the terminal device; and a processing unit, the processing unit causes the terminal device to perform configuration in accordance with the RRC message; causes the terminal device to perform handover failure processing based on expiration of a first timer of the terminal device; and, in the handover failure processing, causes the terminal device to perform processing to restore settings of the terminal device other than state variables of a PDCP entity for each SRB based on a first condition being satisfied, to settings used in a source PCell; and causes the terminal device to perform processing to restore settings of the terminal device other than state variables of a PDCP entity for each DRB, based on a first condition being satisfied. and in the handover failure processing, a process is performed to restore the settings of the terminal device to the settings used in the source PCell based on the fact that the first condition is not satisfied, the first condition includes at least that a first setting is set in the terminal device and that the conditional handover performed by the terminal device does not involve key updating, and the conditional handover is a handover in which a handover procedure is executed by the terminal device when a conditional handover execution condition set in the terminal device is satisfied.

(3) A method of a terminal device communicating with a base station device, in which the terminal device receives an RRC message from the base station device, configures the terminal device according to the RRC message, and performs handover failure processing based on the expiration of a first timer of the terminal device. In the handover failure processing, based on the first condition being satisfied, a process is performed to restore the settings of the terminal device other than the state variables of the PDCP entity to the settings used in the source PCell for each SRB, and a process is performed to restore the settings of the terminal device to the settings used in the source PCell for each DRB. In the handover failure processing, based on the first condition not being satisfied, a process is performed to restore the settings of the terminal device to the settings used in the source PCell, in which the first condition includes at least that the terminal device has a first configuration and that the conditional handover performed by the terminal device does not involve key updating. The conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

(4) A method of a base station device communicating with a terminal device, the base station device transmitting an RRC message to the terminal device, causing the terminal device to configure itself in accordance with the RRC message, causing the terminal device to process a handover failure based on expiration of a first timer of the terminal device, and, based on a first condition being satisfied in the handover failure process, performing a process of restoring the settings of the terminal device other than the state variables of the PDCP entity for each SRB to the settings used in the source PCell, and, for each DRB, restoring the settings of the terminal device to the settings used in the source PCell. In the handover failure processing, a process is performed to restore the settings of the terminal device to the settings used in the source PCell based on the fact that the first condition is not satisfied, the first condition includes at least that the terminal device has a first setting and that the conditional handover performed by the terminal device does not involve key updating, and the conditional handover is a handover in which the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

(5) The first setting described in (1) to (4) above is a setting that indicates that, if the cell initially selected after the conditional handover fails is one of the target candidate SpCells included in the conditional handover setting, a conditional reconfiguration is performed on the target candidate SpCell.

The program that runs on the device according to 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 embodiments according to the present invention. The program or the information handled by the program is temporarily loaded into a volatile memory such as a Random Access Memory (RAM) during processing, or is stored in a non-volatile memory such as a flash memory or a Hard Disk Drive (HDD), and is read, modified, and written by the CPU as necessary.

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

Furthermore, "computer-readable recording medium" may also include something 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 something that stores a program for a fixed period of time, such as volatile memory within a computer system that serves as a server or client in such cases. The above program may also be one that realizes part of the functions described above, or one that can realize the functions described above in combination with a program already recorded in the computer system.

Furthermore, each functional block or feature of the device used in the above-mentioned embodiment may be implemented or performed by an electric circuit, typically an integrated circuit or a number of integrated circuits. The electric 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 an integrated circuit technology that replaces the current integrated circuits emerges due to the progress of semiconductor technology, it is also possible to use an integrated circuit based on that technology.

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

Although the embodiments of the present invention have been described above in detail with reference to the drawings, the specific configuration is not limited to this embodiment, and design modifications and the like that do not depart from the gist of the present invention are also included. Furthermore, the present invention can be modified in various ways 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. Also included are configurations in which elements described in the above embodiments are substituted for elements that have the same effect.

100 E-UTRA
102 eNB
104 EPC
106 N.R.
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 R.R.C.
310 S.D.A.P.
210, 312 NAS
500, 604 Receiving unit 502, 602 Processing unit 504, 600 Transmitting unit

Claims (5)

A terminal device that communicates with a base station device,
The terminal device includes a receiving unit that receives an RRC message from the base station device, and a processing unit,
The processing unit performs configuration on the terminal device according to the RRC message;
performing a handover failure process based on the expiration of a first timer of the terminal device;
In the handover failure processing, based on the fact that a first condition is satisfied, for each SRB, a process is performed to return the settings of the terminal device other than the state variables of the PDCP entity to the settings used in the source PCell, and for each DRB, a process is performed to return the settings of the terminal device to the settings used in the source PCell;
In the handover failure process, a process of returning a setting of the terminal device to a setting used in the source PCell based on the fact that the first condition is not satisfied is performed;
The first condition includes at least that a first setting is performed on the terminal device and that a conditional handover performed by the terminal device does not involve key updating;
The conditional handover is a handover in which a handover procedure is executed by a terminal device when a conditional handover execution condition set in the terminal device is satisfied.
Terminal device. The first setting is a setting indicating that, when a cell initially selected after the conditional handover fails is one of the target candidate SpCells included in the conditional handover setting, a conditional reconfiguration is performed on the target candidate SpCell.
The terminal device according to claim 1. A base station device that communicates with a terminal device,
The base station device includes a transmission unit that transmits an RRC message to the terminal device, and a processing unit,
The processing unit causes the terminal device to perform configuration according to the RRC message;
causing the terminal device to perform a handover failure process based on the expiration of a first timer of the terminal device;
In the handover failure processing, based on the fact that a first condition is satisfied, for each SRB, a process is performed to return the settings of the terminal device other than the state variables of the PDCP entity to the settings used in the source PCell, and for each DRB, a process is performed to return the settings of the terminal device to the settings used in the source PCell;
In the handover failure process, based on the fact that the first condition is not satisfied, a process of returning a setting of the terminal device to a setting used in the source PCell is performed;
The first condition includes at least that a first setting is performed on the terminal device and that a conditional handover performed by the terminal device does not involve key updating;
The conditional handover is a handover in which a handover procedure is executed by a terminal device when a conditional handover execution condition set in the terminal device is satisfied.
Base station equipment. The first setting is a setting indicating that, when a cell initially selected after the conditional handover fails is one of the target candidate SpCells included in the conditional handover setting, a conditional reconfiguration is performed on the target candidate SpCell.
The base station device according to claim 3. A method for a terminal device communicating with a base station device, comprising:
The terminal device receives an RRC message from the base station device,
Configure the terminal device according to the RRC message;
performing a handover failure process based on the expiration of a first timer of the terminal device;
In the handover failure processing, based on the fact that a first condition is satisfied, for each SRB, a process is performed to return the settings of the terminal device other than the state variables of the PDCP entity to the settings used in the source PCell, and for each DRB, a process is performed to return the settings of the terminal device to the settings used in the source PCell;
In the handover failure process, a process of returning a setting of the terminal device to a setting used in the source PCell based on the fact that the first condition is not satisfied is performed;
The first condition includes at least that a first setting is performed on the terminal device and that a conditional handover performed by the terminal device does not involve key updating;
The conditional handover is a handover in which a handover procedure is executed by a terminal device when a conditional handover execution condition set in the terminal device is satisfied.
Method.

Images