Terminal device, base station device, and method

Abstract

This terminal device receives an RRC message from a base station device, configures the settings of the terminal device in accordance with the RRC message, and performs handover failure processing on the basis of the expiration of a first timer of the terminal device. In the handover failure processing, processing is performed to, on the basis of the fulfillment of at least a first condition, maintain a portion of the settings, among the settings of the terminal device, with respect to some or all wireless bearers, and to restore the settings, other than at least said portion of the settings, to the settings that were being used by a resource PCell.

Description

Terminal device, base station device, and method

[0001] The present invention relates to a terminal device, a base station device, and a method. This application claims priority to Japanese Patent Application No. 2020-210122, filed on December 18, 2020, the contents of which are incorporated herein by reference.

[0002] 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 radio access, core networks, services, etc.

[0003] For example, technical studies and standardization of E-UTRA (Evolved Universal Terrestrial Radio Access) have begun in 3GPP as a radio access technology (RAT) for 3.9th and 4th generation cellular mobile communication systems. 3GPP is currently conducting technical studies and standardization of E-UTRA extension technologies. E-UTRA is also called Long Term Evolution (LTE: registered trademark), and the extension technologies are sometimes called LTE-Advanced (LTE-A) and LTE-Advanced Pro (LTE-A Pro) (see Non-Patent Document 2, etc.).

[0004] Furthermore, 3GPP has begun technical studies and standardization of NR (New Radio, or NR Radio access) as a radio access technology (RAT) for 5th generation (5G) cellular mobile communication systems. 3GPP is currently conducting technical studies and standardization of NR extension technologies (see Non-Patent Document 1, etc.).

[0005] 3GPP TS 38.300v 16.2.0,"NR;NR and NG-RAN Overall description; Stage 2" pp10-1343GPP 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

[0006] As one of the NR enhancement technologies, a mechanism to enhance the existing NR mobility technology is being considered. One of the NR mobility technology enhancements is conditional handover, which is a technology that improves handover robustness by allowing a terminal device to perform a handover procedure when one or more handover execution conditions are met.

[0007] The operation of conditional handover is being standardized, but further study is required on the detailed operation.

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

[0009] 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, wherein the processing unit configures the terminal device according to the RRC message; and, based on the expiration of a first timer of the terminal device, performs handover failure processing; and, based on at least a first condition being satisfied in the handover failure processing, performs processing to retain some of the settings of the terminal device for some or all radio bearers and restore settings other than at least the some of the settings to settings used in a source PCell; and, based on at least the first condition not being satisfied in the handover failure processing, performs processing to restore settings of the terminal device to settings used in the source PCell, wherein the first condition includes at least that a first configuration is configured in the terminal device and that the conditional handover performed by the terminal device does not involve key update; and the conditional handover is a handover in which a handover procedure is executed by the terminal device when a conditional handover execution condition configured in the terminal device is satisfied.

[0010] Another aspect of the present invention is a base station device that communicates with a terminal device, the base station device comprising: a transmitter that transmits an RRC message to the terminal device; and a processor, the processor 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 retain some of the settings of the terminal device for some or all radio bearers based on the fact that at least a first condition is satisfied, and causes the settings excluding at least the some of the settings to be transferred to a source PC. and, in the handover failure processing, performs a process of restoring the settings of the terminal device to the settings used in the source PCell based on the fact that at least the first condition is not satisfied, wherein 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 the terminal device executes a handover procedure when a conditional handover execution condition set in the terminal device is satisfied.

[0011] A method for a terminal device communicating with a base station device, wherein the terminal device receives an RRC message from the base station device, configures the terminal device according to the RRC message, performs handover failure processing based on expiration of a first timer of the terminal device, and in the handover failure processing, retains some of the settings of the terminal device for some or all radio bearers based on at least a first condition being satisfied, and performs processing to restore settings excluding at least the some of the settings to settings used in a source PCell, and in the handover failure processing, restores settings of the terminal device to settings used in the source PCell based on at least the first condition not being satisfied, wherein the first condition includes at least that a first setting is configured in the terminal device and that the conditional handover performed by the terminal device does not involve key update, and the conditional handover is a handover in which a handover procedure is executed by the terminal device when a conditional handover execution condition configured in the terminal device is satisfied.

[0012] Another aspect of the present invention is a method of a base station device communicating with a terminal device, wherein the base station device transmits an RRC message to the terminal device, 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, causes the terminal device to retain some of the settings of the terminal device for some or all radio bearers based on at least a first condition being satisfied in the handover failure processing, causes the terminal device to perform processing to restore all settings except for at least the some of the settings to settings used in a source PCell, and causes the terminal device to perform processing to restore all settings except for the some of the settings to settings used in the source PCell based on at least the first condition not being satisfied in the handover failure processing, wherein the first condition includes at least that a first configuration is configured in the terminal device and that the conditional handover performed by the terminal device does not involve key update, 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.

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

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

[0015] 1 is a schematic diagram of a communication system according to an embodiment of the present invention. 2 is a diagram of an example of an E-UTRA protocol configuration according to an embodiment of the present invention. 3 is a diagram of an example of an NR protocol configuration according to an embodiment of the present invention. 4 is a diagram showing an example of a procedure flow for various settings in RRC according to an embodiment of the present invention. 5 is a block diagram showing the configuration of a terminal device according to an embodiment of the present invention. 6 is a block diagram showing the configuration of a base station device according to an embodiment of the present invention. 7 is an example of an ASN.1 description included in a message regarding reconfiguration of an RRC connection in NR according to an embodiment of the present invention. 8 is an example of an ASN.1 description included in a message regarding reconfiguration of an RRC connection in E-UTRA according to an embodiment of the present invention. 9 is an example of an ASN.1 description representing fields and / or information elements related to the configuration of a conditional handover according to an embodiment of the present invention. 10 is a diagram showing an example of processing in a terminal device according to an embodiment of the present invention.

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

[0017] LTE (and LTE-A, LTE-A Pro) and NR may be defined as different radio access technologies (RATs). NR may also be defined as a technology included in LTE. LTE may also be defined as a technology included in NR. LTE that can connect to NR via 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. Conventional LTE may refer to LTE that does not implement technologies standardized in 3GPP Release 15 or later. Embodiments of the present invention may be applied to NR, LTE, and other RATs. In the following description, terms related to LTE and NR are used; however, embodiments of the present invention may be applied to other technologies that use other terminology. In the embodiments of the present invention, the term E-UTRA may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

[0018] In the embodiments of the present invention, the names of the nodes and entities and the processes performed by the nodes and entities are described when the radio access technology is E-UTRA or NR, but the embodiments of the present invention may be used for other radio access technologies. The names of the nodes and entities in the embodiments of the present invention may be different names.

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

[0020] E-UTRA 100 may be a radio access technology. 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 referred to as a Uu interface. eNB (E-UTRAN Node B) 102 may be a base station device of E-UTRA 100. eNB 102 may have the E-UTRA protocol described below. The E-UTRA protocol may be composed of an E-UTRA User Plane (UP) protocol described below and an E-UTRA Control Plane (CP) protocol described below. eNB 102 may terminate the E-UTRA User Plane (UP) protocol and the E-UTRA Control Plane (CP) protocol for UE 122. A radio access network composed of eNBs may be referred to as E-UTRAN.

[0021] The EPC (Evolved Packet Core) 104 may be a core network. The interface 112 is an interface between the eNB 102 and the EPC 104 and may be referred to as 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 referred to as an S1-MME interface. The user plane interface of the interface 112 may be referred to as an S1-U interface.

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

[0023] The NR 106 may be a radio access technology. The NR 106 may also 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 consist of the NR User Plane (UP) protocol described below and the NR Control Plane (CP) protocol described below. The gNB 108 may terminate the NR User Plane (UP) protocol and the NR Control Plane (CP) protocol for the UE 122.

[0024] 5GC110 may be a core network. Interface 116 is an interface between gNB108 and 5GC110 and may be referred to as 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 in an Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 116 may terminate in a User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 116 may be referred to as an NG-C interface. The user plane interface of interface 116 may be referred to as an NG-U interface.

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

[0026] The eNB102 may have the capability to connect to the 5GC110. The eNB102 with the capability to connect to the 5GC110 may be referred to as an ng-eNB. The interface 114 is an interface between the eNB102 and the 5GC110 and may be referred to as an NG interface. The interface 114 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 114 may terminate in an Access and Mobility Management Function (AMF: not shown) in the 5GC110. The user plane interface of the interface 114 may terminate in a User Plane Function (UPF: not shown) in the 5GC110. The control plane interface of the interface 114 may be referred to as an NG-C interface. The user plane interface of the interface 114 may be referred to as an NG-U interface. A radio access network consisting of an ng-eNB or a gNB may be referred to as an NG-RAN. The NG-RAN, E-UTRAN, eNB, ng-eNB, gNB, etc. may simply be referred to as a network.

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

[0028] The gNB 108 may have the ability to connect to the EPC 104. A gNB 108 with the ability to connect to the EPC 104 may be referred to as an en-gNB. Interface 118 is an interface between the gNB 108 and the EPC 104 and may be referred to as an S1 interface. Interface 118 may have a user plane interface through which user data passes. The user plane interface of interface 118 may terminate at an S-GW (not shown) in the EPC 104. The user plane interface of interface 118 may be referred to as 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 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 referred to as an X2 interface.

[0029] The interface 124 is an interface between the EPC 104 and the 5GC 110, and may be an interface that passes only the CP, only the UP, or both the CP and the UP. Also, some or all of the interfaces such as the interface 114, the interface 116, the interface 118, the interface 120, and the interface 124 may not exist depending on the communication system provided by the communication carrier or the like.

[0030] The UE 122 may be a terminal device capable of receiving broadcast information and paging messages transmitted from the eNB 102 and / or the gNB 108. The UE 122 may also be a terminal device capable of wireless connection with the eNB 102 and / or the gNB 108. The UE 122 may also be a terminal device capable of simultaneously establishing a wireless connection with the eNB 102 and a wireless connection with the gNB 108. The UE 122 may have an E-UTRA protocol and / or an NR protocol. The wireless connection may be a Radio Resource Control (RRC) connection.

[0031] When the UE 122 communicates with the eNB 102 and / or the gNB 108, a radio connection may be established by establishing a radio bearer (RB) between the UE 122 and the eNB 102 and / or the gNB 108. A radio bearer used for CP may be referred to as a signaling radio bearer (SRB). A radio bearer used for UP may be referred to as a data radio bearer (DRB Data Radio Bearer). Each radio bearer may be assigned a radio bearer identity (ID). A radio bearer identity for an SRB may be referred to as an SRB identity (SRB ID). A radio bearer identity for a DRB may be referred to as a DRB identity (DRB ID).

[0032] Furthermore, the UE 122 may be a terminal device capable of connecting to the EPC 104 and / or the 5GC 110 via the eNB 102 and / or the gNB 108. When the core network to which the eNB 102 and / or the gNB 108, with which the UE 122 communicates, is connected is the EPC 104, each DRB established between the UE 122 and the eNB 102 and / or the gNB 108 may be uniquely associated with each EPS (Evolved Packet System) bearer passing through the EPC 104. Each EPS bearer may be identified by an EPS bearer identifier (Identity, or ID). Furthermore, the same QoS may be guaranteed for data such as IP packets and Ethernet frames passing through the same EPS bearer.

[0033] Furthermore, if the core network to which the eNB102 and / or gNB108 with which the UE122 communicates is connected is the 5GC110, each DRB established between the UE122 and the eNB102 and / or gNB108 may be further linked to one of the PDU (Packet Data Unit) sessions established within the 5GC110. 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). Furthermore, each QoS flow may be identified by a QoS flow identifier (Identity, Identifier, or ID). Furthermore, the same QoS may be guaranteed for data such as IP packets and Ethernet frames passing through the same QoS flow.

[0034] There may be no PDU sessions and / or QoS flows in EPC 104, and no EPS bearers in 5GC 110. When UE 122 is connected to EPC 104, UE 122 has information about the EPS bearers but may not have information about the PDU sessions and / or QoS flows. When UE 122 is connected to 5GC 110, UE 122 has information about the PDU sessions and / or QoS flows but may not have information about the EPS bearers.

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

[0036] FIG. 2 is a diagram showing an example of an E-UTRA protocol architecture according to an embodiment of the present invention. FIG. 3 is a diagram showing an example of an NR protocol architecture according to an embodiment of the present invention. Note that the functions of each protocol described using FIG. 2 and / or FIG. 3 are only some of the functions closely related to the embodiment of the present invention, and other functions may also be included. Note that in the embodiment of the present invention, an uplink (UL) may be a link from a terminal device to a base station device. Also, in each embodiment of the present invention, a downlink (DL) may be a link from a base station device to a terminal device.

[0037] 2A is a diagram of an E-UTRA user plane (UP) protocol stack. As shown in FIG. 2A, 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 a PHY (Physical layer) 200, a MAC (Medium Access Control) layer 202, a RLC (Radio Link Control) layer 204, and a PDCP (Packet Data Convergence Protocol) layer 206.

[0038] Figure 3(A) is a diagram of the NR user plane (UP) protocol stack. As shown in Figure 3(A), the NRUP 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 a radio physical layer PHY 300, a medium access control layer MAC 302, a radio link control layer RLC 304, a packet data convergence protocol layer PDCP 306, and a service data adaptation protocol layer SDAP (Service Data Adaptation Protocol) 310.

[0039] 2(B) is a diagram of the E-UTRAN control plane (CP) protocol configuration. As shown in FIG. 2(B), in the E-UTRAN CP protocol, RRC (Radio Resource Control) 208, which is a radio resource control layer, may be a protocol between the UE 122 and the eNB 102. That is, RRC 208 may be a protocol that terminates at the eNB 102 on the network side. Also, in the E-UTRAN CP protocol, 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, NAS 210 may be a protocol that terminates at the MME on the network side.

[0040] 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, the radio resource control layer RRC 308 may be a protocol between the UE 122 and the gNB 108. That is, the RRC 308 may be a protocol that terminates at the gNB 108 on the network side. Also, in the E-UTRAN CP protocol, the non-AS layer NAS 312 may be a protocol between the UE 122 and the AMF. That is, the NAS 312 may be a protocol that terminates at the AMF on the network side.

[0041] The AS (Access Stratum) layer may be a layer that terminates between the UE 122 and the eNB 102 and / or the gNB 108. That is, 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.

[0042] In the embodiments of the present invention, the terms PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be used without distinguishing between the E-UTRA protocol and the NR protocol. In this case, PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may respectively refer to 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.

[0043] In the embodiments of the present invention, when distinguishing between E-UTRA protocols and NR protocols, the PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 may be referred to 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, and E-UTRA RRC or LTE RRC, respectively. The PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 may also be referred to 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, and E-UTRA RRC or LTE RRC, respectively. Furthermore, when distinguishing between E-UTRA protocols and NR protocols, PHY 300, MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as NR PHY, NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Furthermore, PHY 200, MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as NR PHY, NR MAC, NR RLC, NR PDCP, and NR RRC, respectively.

[0044] This section 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.

[0045] Note that data provided from MAC, RLC, PDCP, and SDAP to lower layers, and / or data provided from lower layers to MAC, RLC, PDCP, and SDAP, may be referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU, respectively. Data provided from higher layers to MAC, RLC, PDCP, and SDAP, and / or data provided from MAC, RLC, PDCP, and SDAP to higher layers, may be referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. A segmented RLC SDU may be referred to as an RLC SDU segment.

[0046] An example of the functions 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, an RNTI (Radio Network Temporary Identifier) ​​may be used to identify various control information.

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

[0048] The physical channels used for wireless communication between a terminal device and a base station device may include the following physical channels.

[0049] 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)

[0050] The PBCH may be used to broadcast system information required by the terminal device.

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

[0052] 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 also be referred to as DCI formats) may be defined for transmitting the downlink control information. That is, a field for the downlink control information may be defined as 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 a serving cell. Monitoring the 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 RRC messages (described later), and the like.

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

[0054] The PDSCH may be used to transmit downlink data (DL-SCH: Downlink Shared CHannel) from the MAC layer, and may also be used to transmit system information (SI) and random access responses (RAR) in the downlink.

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

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

[0057] An example of the MAC function will be described. MAC may be called a MAC sublayer. MAC may have the function of mapping various logical channels to corresponding transport channels. Logical channels may be identified by a logical channel identity (or logical channel ID). MAC may be connected to the higher-level RLC via logical channels. Depending on the type of information to be transmitted, logical channels may be divided into control channels that transmit control information and traffic channels that transmit user information. Logical channels may also be divided into uplink logical channels and downlink logical channels. MAC may have the function of multiplexing MAC SDUs belonging to one or more different logical channels and providing them to the PHY. MAC may also have the function of demultiplexing MAC PDUs provided by the PHY and providing them to the higher layer via the logical channel to which each MAC SDU belongs. MAC may also have the 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 to perform prioritized processing between terminal devices using dynamic scheduling. The MAC may also have a function to perform prioritized processing between logical channels within one terminal device. The MAC may also have a function to perform prioritized processing of overlapping resources within one terminal device. The E-UTRA MAC may have a function to identify Multimedia Broadcast Multicast Services (MBMS). The NR MAC may also have a function to identify Multicast / Broadcast Services (MBS). The MAC may have a function to select a transport format.The MAC may have functions such as discontinuous reception (DRX) and / or discontinuous transmission (DTX), a random access (RA) procedure, a power headroom report (PHR) function that notifies information about available transmission power, and a buffer status report (BSR) function that notifies information about the amount of data in the transmission buffer. The NR MAC may have a bandwidth adaptation (BA) function. The MAC PDU format used in the E-UTRA MAC may differ from the MAC PDU format used in the NR MAC. The MAC PDU may also include a MAC control element (MAC CE), which is an element for performing control in the MAC.

[0058] This section describes logical channels for uplink (UL) and / or downlink (DL) used in E-UTRA and / or NR.

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

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

[0061] A 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.

[0062] A DCCH (Dedicated Control Channel) may be a logical channel for transmitting dedicated control information bidirectionally, point-to-point, 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.

[0063] A 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. A DTCH may be a logical channel for transmitting dedicated user data. Dedicated user data may be user data dedicated to each terminal device. A DTCH may exist in both the uplink and the downlink.

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

[0065] The MCCH (Multicast Control Channel) 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 receives MBMS or is interested in receiving MBMS.

[0066] 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 multicast logical channel. 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).

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

[0068] This section describes the mapping of logical channels and transport channels for the uplink in E-UTRA and / or NR.

[0069] The CCCH may be mapped to an uplink shared channel (UL-SCH), which is an uplink transport channel.

[0070] The DCCH may be mapped to an uplink shared channel (UL-SCH), which is an uplink transport channel.

[0071] The DTCH may be mapped to an uplink shared channel (UL-SCH), which is an uplink transport channel.

[0072] This section describes the mapping of logical channels and transport channels for the downlink in E-UTRA and / or NR.

[0073] The BCCH may be mapped to a downlink transport channel, a Broadcast Channel (BCH) and / or a Downlink Shared Channel (DL-SCH).

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

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

[0076] The DCCH may be mapped to a DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

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

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

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

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

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

[0082] An example of the RLC function will be described. The RLC may be called an RLC sublayer. The E-UTRA RLC may have the function of segmenting and / or concatenating data provided by the PDCP in the upper layer and providing it to the lower layer. The E-UTRA RLC may have the function of reassembling and reordering data provided by the lower layer and providing it to the upper layer. The NR RLC may have the function of adding a sequence number independent of the sequence number added by PDCP to data provided by the PDCP in the upper layer. The NR RLC may also have the function of segmenting data provided by PDCP and providing it to the lower layer. The NR RLC may also have the function of reassembling data provided by the lower layer and providing it to the upper layer. The RLC may also have the function of data retransmission and / or retransmission request (Automatic Repeat reQuest: ARQ). RLC may also have a function for performing error correction using ARQ. The control information sent from the receiving side of RLC to the transmitting side to indicate data that needs to be retransmitted in order to perform ARQ may be called a status report. The instruction to send a status report sent from the transmitting side of RLC to the receiving side may be called a poll. RLC may also have a function for detecting data duplication. RLC may also have a data discard function. RLC may have three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). In TM, data received from the upper layer is not segmented, and an RLC header need not be added. The TM RLC entity is a unidirectional entity and may be configured as a transmitting TM RLC entity or a receiving TM RLC entity.In UM, the segmentation and / or concatenation of data received from a higher layer, the addition of an RLC header, etc. are performed, but data retransmission control is not required. The UM RLC entity may be a unidirectional entity or a bidirectional entity. If the UM RLC entity is a unidirectional entity, it may be configured as a transmitting UM RLC entity or a receiving UMRLC entity. If the UM RLC entity is a bidirectional entity, it may be configured as a UM RLC entity consisting of a transmitting side and a receiving side. In AM, the segmentation and / or concatenation of data received from a higher layer, the addition of an RLC header, data retransmission control, etc. are 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. Note that data provided to a lower layer in TM and / or data provided from a lower layer may be called a TMD PDU. Furthermore, data provided to a lower layer in UM and / or data provided from a lower layer may be referred to as a UMD PDU. Furthermore, data provided to a lower layer in AM and / or data provided from a lower layer may be referred to as an AMD PDU. The RLC PDU format used in E-UTRA RLC may differ from the RLC PDU format used in NR RLC. Furthermore, RLC PDUs may include data RLC PDUs and control RLC PDUs. Data RLC PDUs may be referred to as RLC DATA PDUs (RLC Data PDUs). Control RLC PDUs may be referred to as RLC CONTROL PDUs (RLC Control PDUs).

[0083] An example of state variables used in an RLC entity is described below. In an RLC entity, some or all of the state variables, including the following state variables (A) to (K), may be used. (A) A response state variable used by the transmitting side of an AM RLC entity. This indicates the value of the sequence number of the RLC SDU that will next receive a positive response. This may be a state variable named TX_Next_Ack. (B) A transmit state variable used by the transmitting side of an AM RLC entity. This indicates the value of the sequence number to be assigned to the next newly created AMD PDU. This may be a state variable named TX_Next. (C) A poll state variable used by the transmitting side of an AM RLC entity. This indicates the value of the highest sequence number of the AMD PDU submitted to the lower layer when this state variable is set. This may be a state variable named POLL_SN. (D) A receive state variable used by the receiving side of an AM RLC entity. This indicates the value following the last sequence number of the RLC SDU that was successfully received in order. This may be a state variable named RX_Next. (E) Reassembly timer state variable used by the receiving side of the AM RLC entity. It indicates the value of the sequence number that follows the sequence number of the AMD PDU that triggered the reassembly timer. It may be a state variable named RX_Next_Status_Trigger. (F) Maximum STATUS transmit state variable used by the receiving side of the AM RLC entity. It indicates the value of the sequence number of the AMD PDU that is reported as a successfully received AMD PDU when a status PDU needs to be created. It may be a state variable named RX_Highest_Status. (G) Highest receive state variable used by the receiving side of the AM RLC entity. It indicates the value of the sequence number that follows the highest sequence number among the received AMD PDUs. It may be a state variable named RX_Next_Highest. (H) Transmit state variable used by the transmitting side of the UM RLC entity.This indicates the value of the sequence number to be assigned when the next newly created UMD PDU is segmented. It may be a state variable named TX_Next. (I) A UM reception state variable used by the receiving side of the UM RLC entity. It indicates the lowest sequence number of UMD PDUs for which reassembly is considered. It may be a state variable named RX_Next_Reassembly. (J) A UM reassembly timer state variable used by the receiving side of the UM RLC entity. It indicates the value of the sequence number next to the sequence number of the UMD PDU that started the reassembly timer. It may be a state variable named RX_Timer_Trigger. (K) A UM reception state variable used by the receiving side of the UM RLC entity. It indicates the value of the sequence number next to the highest sequence number among the received UMD PDUs. It may be a state variable named RX_Next_Highest.

[0084] An example of a counter used in an RLC entity will be described. In an RLC entity, counters including some or all of the following counters (A) to (C) may be used: (A) A counter that counts the number of AMD PDUs sent since the last poll bit transmission. This may be a counter named PDU_WITHOUT_POLL. (B) A counter that counts the number of data bytes sent since the last poll bit transmission. This may be a counter named BYTE_WITHOUT_POLL. (C) A counter that counts the number of times an RLC SDU or RLC SDU segment has been retransmitted. This may be a counter named RETX_COUNT.

[0085] An example of a timer used in an RLC entity will be described. In the RLC entity, counters including some or all of the following timers (A) to (C) may be used. (A) A timer used in the transmitting side of an AM RLC entity to retransmit polls. It may be a timer named t-PollRetransmit. (B) A timer used in the receiving side of an AM RLC entity and a receiving UM RLC entity to detect RLC PDU loss. It may be a timer named t-Reassembly. (C) A timer used in the receiving side of an AM RLC entity to prohibit the transmission of status PDUs. It may be a timer named t-StatusProhibit.

[0086] An example of PDCP functions will be described. PDCP may be called a PDCP sublayer. PDCP may have a function for maintaining sequence numbers. PDCP may also have a header compression / decompression function for efficiently transmitting user data such as IP packets and Ethernet frames over wireless interfaces. The protocol used for IP packet header compression / decompression may be called the ROHC (Robust Header Compression) protocol. The protocol used for Ethernet frame header compression / decompression may be called the EHC (Ethernet (registered trademark) Header Compression) protocol. PDCP may also have a data encryption / decryption function. PDCP may also have a data integrity protection / integrity verification function. The data encryption / decryption function and / or the data integrity protection / integrity verification function may be referred to as security functions. PDCP may also have a re-ordering function. PDCP may also have a PDCP SDU retransmission function. PDCP may also have a function to discard data using a discard timer. PDCP may also have a duplication function. PDCP may also have a function to discard duplicately received data. A 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 E-UTRA PDCP may differ from the PDCP PDU format used in NR PDCP. PDCP PDUs may include data PDCP PDUs and control PDCP PDUs. A data PDCP PDU may be called a PDCP DATA PDU (PDCP Data PDU). A control PDCP PDU may be called a PDCP CONTROL PDU (PDCP Control PDU).

[0087] In PDCP, the COUNT value may be used when performing ciphering or integrity protection processing. The COUNT value may be composed of a PDCP state variable, HFN (Hyper Frame Number), and a sequence number (SN) added to the header of a PDCP PDU. The sequence number may be incremented by one each time a PDCP DATA PDU is generated in the transmitting PDCP entity. The HFN may be incremented by one each time the sequence number reaches its maximum value in the transmitting PDCP entity and the receiving PDCP entity. In addition, some or all of the following state variables (A) to (F) may be used to manage the COUNT value in the transmitting PDCP entity and the receiving PDCP entity. (A) A state variable indicating the COUNT value of the next PDCP SDU to be transmitted. This may be a state variable named TX_NEXT. (B) A state variable indicating the sequence number of the next PDCP SDU to be transmitted in this PDCP entity. This may be a state variable named Next_PDCP_TX_SN. (C) A state variable representing the HFN value used to generate the COUNT value for a PDCP PDU in this PDCP entity. It may be a state variable named TX_HFN. (D) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next in the receiving PDCP entity. It may be a state variable named RX_NEXT. (E) A state variable indicating the sequence number of the PDCP SDU that is expected to be received next in the receiving PDCP entity. It may be a state variable named Next_PDCP_RX_SN. (F) A state variable representing the HFN value used to generate the COUNT value for a received PDCP PDU in this PDCP entity. It may be a state variable named RX_HFN.

[0088] In addition, for purposes such as replay protection, LTE and NR prohibit the use of the same COUNT value more than once for the same security key (encryption key and / or integrity protection key) for uplink data and downlink data on each radio bearer.

[0089] Furthermore, in PDCP, reordering may refer to a process of storing PDCP SDUs in a receive buffer (reordering buffer) and delivering the PDCP SDUs to a higher layer in the order of the COUNT values ​​obtained from the header information of the PDCP DATA PDUs. In reordering, if the COUNT value of a received PDCP DATA PDU is the COUNT value of the first PDCP SDU that has not yet been delivered to a higher layer, the stored PDCP SDUs may be delivered to the higher layer in the order of the COUNT values. In other words, in reordering, if a PDCP data PDU with a COUNT value smaller than the COUNT value of the received PDCP data PDU has not been received (a PDCP data PDU has been lost), the received PDCP data PDU may be converted into a PDCP SDU and stored in the reordering buffer, and all lost PDCP data PDUs may be received, converted into PDCP SDUs, and then delivered to a higher layer. In reordering, a reordering timer (a timer named t-Reordering) may be used to detect loss of PDCP data PDUs. Also, some or all of the following state variables (A) to (F) may be used for reordering. (A) A state variable indicating the COUNT value of the PDCP SDU expected to be received next at the receiving PDCP entity. This may be a state variable named RX_NEXT. (B) A state variable indicating the sequence number of the PDCP SDU expected to be received next at the receiving PDCP entity. This may be a state variable named Next_PDCP_RX_SN. (C) A state variable indicating the HFN value used to generate the COUNT value for the received PDCP PDU at this PDCP entity. This may be a state variable named RX_HFN. (D) A state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not yet been delivered to the upper layer at the receiving PDCP entity. This may be a state variable named RX_DELIV.(E) In the receiving PDCP entity, this state variable indicates the PDCP PDU sequence number of the PDCP SDU that was last delivered to the upper layer. It may be a state variable named Last_Submitted_PDCP_RX_SN. (F) In the receiving PDCP entity, this state variable indicates the COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer. It may be a state variable named RX_REORD or a state variable named Reordering_PDCP_RX_COUNT.

[0090] This section explains status reporting in PDCP. In a DRB (AM DRB: Acknowledged Mode Data Radio Bearer) using RLC in acknowledged mode and configured by the upper layer to transmit PDCP status reports, the receiving PDCP entity may trigger a PDCP status report when any of the following conditions (A) to (D) is met. Also, in a DRB (UM DRB: Unacknowledged Mode Data Radio Bearer) using RLC in unacknowledged mode and configured by the upper layer to transmit PDCP status reports, the receiving PDCP entity may trigger a PDCP status report when the following condition (C) is met: (A) The upper layer requests re-establishment of the PDCP entity. (B) The upper layer requests PDCP data recovery. (C) The upper layer requests an uplink data switch. (D) The upper layer reconfigures this PDCP entity to release DAPS (Dual Active Protocol Stack), and a parameter named "daps source release" is set.

[0091] When the transmission of a PDCP status report is initiated, the receiving PDCP entity may generate a PDCP status report by storing information about the pending PDCP SDUs in a PDCP control PDU for the PDCP status report, including the COUNT value of the first pending PDCP SDU that has not yet been delivered to the upper layer. After generating the PDCP status report, the receiving PDCP entity may submit the generated PDCP status report to the lower layer via the transmitting PDCP entity.

[0092] In an embodiment of the present invention, a PDCP entity of a UM DRB configured by a higher layer to transmit a PDCP status report may determine that a PDCP data recovery has been requested by the higher layer. The PDCP entity of a UM DRB that has determined that a PDCP data recovery has been requested by the higher layer may create a PDCP status report in the receiving PDCP entity based on the PDCP data recovery request from the higher layer and submit the created PDCP status report to a lower layer via the transmitting PDCP entity. The lower layer may be a UM RLC entity of an RLC bearer associated with the PDCP entity. In an embodiment of the present invention, a PDCP entity of a UM DRB configured by a higher layer to transmit a PDCP status report may determine that a PDCP data recovery has been requested by the higher layer only if the UM DRB is not a DAPS bearer. A DAPS bearer may be a bearer in which one or more RLC entities for a source cell and one or more RLC entities for a target cell are associated with the PDCP entity. The above-mentioned PDCP data recovery may also be called by another name, which means that an upper layer requests the PDCP to send a status report.

[0093] The following describes ROHC. In an embodiment of the present invention, ROHC may be referred to as the ROHC protocol. ROHC may have a function for compressing and decompressing header information such as IP, UDP, TCP, and RTP. In ROHC, a compressor may have a header compression function for compressing header information. In ROHC, a decompressor may have a header decompression function for decompressing header information. A compressor may perform header compression using a context held by the compressor. A decompressor may perform header decompression using a context held by the decompressor. In an embodiment of the present invention, a context may be referred to as a ROHC context. A context in a decompressor may be generated by receiving all header information from the compressor. A context in a compressor and a decompressor may be held for each IP flow. A context identifier (CID) may be used to identify a context. Information on the maximum value of the context identifier, profile information indicating the header compression / decompression method, etc. may be negotiated between the compressor and decompressor before header compression / decompression is performed.

[0094] In ROHC, header information may be classified into static parts and dynamic parts. The static part of the header information in ROHC may be information that rarely changes among the header information of each packet belonging to an IP flow. The static part of the header information in ROHC may be information including, for example, the source address, destination address, and version in an IPv4 header or IPv6 header, and the source port and destination port in a UDP header or TCP header. The dynamic part of the header information in ROHC may be information that may change from packet to packet among the header information of each packet belonging to an IP flow. The dynamic part of the header information in ROHC may be information including, for example, the traffic class and hop limit in an IPv6 header, the type of service and time to live in an IPv4 header, the checksum in a UDP header, the RTP sequence number and RTP timestamp in an RTP header.

[0095] A ROHC compressor may have three states: IR (Initialization and Refresh), FO (First Order), and SO (Second Order). When the IR state is used, the compressor may not compress the header information to be compressed and may send all of the header information to the decompressor. When the FO state is used, the compressor may compress most of the static parts of the header information to be compressed and may send some static and dynamic parts to the decompressor without compressing them. When the SO state is used, the header compression rate is at its highest, and the compressor may send only limited information such as the RTP sequence number.

[0096] A ROHC decompressor may have three states: NC (No Context), SC (Static Context), and FC (Full Context). The initial state of the decompressor may be the NC state. If the context is acquired in the NC state and header decompression is performed correctly, the decompressor may transition to the FC state. If header decompression fails consecutively in the FC state, the decompressor may transition to the SC or NC state.

[0097] There may be three ROHC processing modes: U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode), and R-mode (Bidirectional Reliable mode). In U-mode, ROHC feedback packets may not be used. In U-mode, a transition from low compression mode to high compression mode in the compressor, i.e., a transition from IR state to FO state, and / or a transition from FO state to SO state, and / or a transition from IR state to SO state, may be performed by transmitting a certain number of packets. In U-mode, a transition from high compression mode to low compression mode in the compressor, i.e., a transition from SO state to FO state, and / or a transition from FO state to IR state, and / or a transition from SO state to IR state, may be performed at regular intervals, thereby periodically transmitting information required for header decompression to the decompressor. In O-mode, the decompressor may request a context update from the compressor by transmitting a ROHC feedback packet to the compressor. In R-mode, the compressor may transition from low compression mode to high compression mode by receiving a header decompression success notification from the decompressor via a ROHC feedback packet. Also, in R-mode, the compressor may transition from high compression mode to low compression mode by receiving a context update request from the decompressor via a ROHC feedback packet. The ROHC processing mode may start from U-mode. The transition of the ROHC processing mode may be determined by the decompressor. The decompressor may prompt the compressor to transition the processing mode using a ROHC feedback packet.

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

[0099] An example of the functions of the RRC will be described. The RRC may have a broadcast function. The RRC may have a paging function from the EPC 104 and / or the 5GC 110. The RRC may have a paging function from the gNB 108 or the eNB 102 connected to the 5GC 100. The RRC may also have an RRC connection management function. The RRC may also have a radio bearer control function. The RRC may also have a cell group control function. The RRC may also have a mobility control function. The RRC may also have terminal device measurement reporting and terminal device measurement reporting control functions. The RRC may also have a QoS management function. The RRC may also have a radio link failure detection and recovery function. The RRC may use RRC messages to perform broadcasting, paging, RRC connection management, radio bearer control, cell group control, mobility control, terminal device measurement reporting and terminal device measurement reporting control, QoS management, radio link failure detection and recovery, 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.

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

[0101] RRC messages sent using the BCCH may include, for example, Master Information Blocks (MIBs), various types of System Information Blocks (SIBs), and other RRC messages. RRC messages sent using the PCCH may include, for example, paging messages and other RRC messages.

[0102] RRC messages sent in the uplink (UL) direction using the CCCH may include, for example, an RRC Setup Request message, an RRC Resume Request message, an RRC Reestablishment Request message, an RRC System Info Request message, etc. They may also include, for example, an RRC Connection Request message, an RRC Connection Resume Request message, an RRC Connection Reestablishment Request message, etc. They may also include other RRC messages.

[0103] RRC messages sent in the downlink (DL) direction using the CCCH may include, for example, an RRC connection reject message (RRC Connection Reject), an RRC connection setup message (RRC Connection Setup), an RRC connection reestablishment message (RRC Connection Reestablishment Reject), an RRC connection reestablishment reject message (RRC Connection Reestablishment Reject), etc. They may also include, for example, an RRC reject message (RRC Reject), an RRC setup message (RRC Setup), an RRC resume message (RRC Resume), etc. They may also include other RRC messages.

[0104] RRC messages sent in the uplink (UL) direction using the DCCH may include, for example, a Measurement Report message, an RRC Connection Reconfiguration Complete message, an RRC Connection Setup Complete message, an RRC Connection Reestablishment Complete message, a Security Mode Complete message, a UE Capability Information message, etc. Also, for example, a Measurement Report message, an RRC Reconfiguration Complete message, an RRC Setup Complete message, an RRC Reestablishment Complete message, an RRC Resume Complete message, a Security Mode Complete message, a UE Capability Information message, a Counter Check Response message, etc. Other RRC messages may also be included.

[0105] RRC messages sent in the downlink (DL) direction using the DCCH may include, for example, an RRC connection reconfiguration message, an RRC connection release message, a security mode command message, a UE capability inquiry message, etc. They may also include, for example, an RRC reconfiguration message, an RRC resume message, an RRC release message, an RRC reestablishment message, a security mode command message, a UE capability inquiry message, a counter check message, etc. Other RRC messages may also be included.

[0106] An example of the functions of the NAS will be described. 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.

[0107] 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. Also, some or all of the functions of each layer may be included in another layer.

[0108] Note that layers (not shown) above the AS layer of the terminal device may include an IP layer, a TCP (Transmission Control Protocol) layer above the IP layer, a UDP (User Datagram Protocol) layer, and the like. Furthermore, an Ethernet layer may be present above the AS layer of the terminal device. The layer above the AS layer of the terminal device may be called a PDU layer (PDU layer). The PDU layer may include an IP layer, a TCP layer, a UDP layer, an Ethernet layer, and the like. An application layer may be present above the IP layer, the TCP layer, the UDP layer, the Ethernet layer, the PDU layer, and the like. 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 by 3GPP. Furthermore, the application layer may include RTP (Real-time Transport Protocol) used for media communication, and / or protocols such as RTCP (Real-time Transport Control Protocol) and HTTP (HyperText Transfer Protocol) for media communication control. Furthermore, the application layer may include codecs for various media. The RRC layer may also be a layer above the SDAP layer.

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

[0110] Note that when UE 122 is connected to the EPC, it does not have the RRC_INACTIVE state, but the suspension of the RRC connection may be initiated by E-UTRAN. When UE 122 is connected to the EPC, when the RRC connection is suspended, UE 122 may transition to the RRC_IDLE state while retaining the UE AS context and an identifier (resume identity) used for resume. A layer above the RRC layer of UE 122 (e.g., the NAS layer) may initiate the restoration of the suspended RRC connection when UE 122 retains the UE AS context, RRC connection restoration is permitted by E-UTRAN, and UE 122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state.

[0111] 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 (when dormant in RRC_IDLE state) and when UE 122 is connected to 5GC (when dormant in RRC_INACTIVE state).

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

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

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

[0115] A cell group configured by a base station device for a terminal device will now be described. 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 when a MAC entity is associated with a master cell group (MCG), the SpCell may refer to a primary cell (PCell). Note that when a MAC entity is associated with a secondary cell group (SCG), the SpCell may refer to a primary SCG cell (PSCell). Note that when a MAC entity is not associated with a cell group, the SpCell may refer to a PCell. The PCell, PSCell, and SCell are serving cells. The SpCell may support PUCCH transmission and contention-based random access, and may always be activated. The PCell may be a cell used for the RRC connection establishment procedure when a terminal device in an RRC idle state transitions to an RRC connected state. The PCell may also be a cell used for the RRC connection re-establishment procedure when a terminal device re-establishes an RRC connection. The PCell may also be a cell used for the random access procedure during handover. The PSCell may be a cell used for the random access procedure when a secondary node (SN) is added, as described below. The SpCell may also be a cell used for purposes other than those mentioned above. Note that when a cell group is composed of an SpCell and one or more SCells, it may be said that carrier aggregation (CA) is configured for this cell group.Furthermore, for a terminal device in which CA is configured, a cell that provides additional radio resources to an SpCell may refer to an SCell.

[0116] A group of serving cells configured by RRC that uses the same timing reference cell and the same timing advance value for the uplink configured cells may be called a Timing Advance Group (TAG). A TAG including the SpCell of a MAC entity may refer to a Primary Timing Advance Group (PTAG). A TAG other than the above PTAG may refer to a Secondary Timing Advance Group (STAG).

[0117] Furthermore, when Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) is performed, a cell group may be added from a base station device to a terminal device. DC may be a technology for performing data communication using radio resources of cell groups 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, a first base station device may add a second base station device. The first base station device may be called a master node (MN). A cell group configured by the master node may be called a master cell group (MCG). The second base station device may be called a secondary node (SN). A cell group configured by the secondary node may be called a secondary cell group (SCG). The master node and secondary node may be configured within the same base station device.

[0118] Furthermore, when a DC is not configured, a cell group configured in a terminal device may be called an MCG. Furthermore, when a DC is not configured, an SpCell configured in a terminal device may be a PCell.

[0119] Note that 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. Examples of MR-DC that use E-UTRA for MCG and NR for SCG include EN-DC (E-UTRA-NR Dual Connectivity) that uses EPC for the core network and NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity) that uses 5GC for the core network. Examples of MR-DC that use NR for MCG and E-UTRA for SCG include NE-DC (NR-E-UTRA Dual Connectivity) that uses 5GC for the core network. Examples of MR-DC that use NR for both MCG and SCG include NR-DC (NR-NR Dual Connectivity) that uses 5GC for the core network.

[0120] 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, there may be one MAC entity for the MCG and one MAC entity for the SCG. The MAC entity for the MCG in the terminal device may always be established in the terminal device in all states (such as RRC idle state, RRC connected state, and RRC inactive state). The MAC entity for the SCG in the terminal device may be created by the terminal device when an SCG is configured in the terminal device. The MAC entity for each cell group in the terminal device may be configured by the terminal device receiving an RRC message from the base station device. In the 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. 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. In NR-DC, the MAC entities for the MCG and SCG may both be NR MAC entities. The existence of one MAC entity for each cell group may be rephrased as the existence of one MAC entity for each SpCell. The existence of one MAC entity for each cell group may be rephrased as the existence of one MAC entity for each SpCell.

[0121] The following describes radio bearers. SRB0 to SRB2 may be defined as SRBs for E-UTRA, or other SRBs may be defined. SRB0 to SRB3 may be defined as SRBs for NR, or other SRBs may be defined. SRB0 may be an SRB for RRC messages transmitted and / or received using the logical channel CCCH. SRB1 may be an SRB for RRC messages and for NAS messages before the establishment of SRB2. RRC messages 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 transmitted and / or received using SRB1. SRB2 may be an SRB for NAS messages and for RRC messages including logged measurement information. The logical channel DCCH may be used for all RRC messages and NAS messages transmitted and / or received using SRB2. Furthermore, SRB2 may 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. The logical channel DCCH may be used for all RRC messages and NAS messages transmitted and / or received using SRB3. Other SRBs may also be prepared for other uses. DRB may be a radio bearer for user data. The logical channel DTCH may be used for RRC messages transmitted and / or received using DRBs.

[0122] The following describes a radio bearer in a terminal device. A radio bearer may include an RLC bearer. An RLC bearer may consist of one or two RLC entities and logical channels. When an RLC bearer has two RLC entities, 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 consist of one RLC bearer. The RLC bearer of SRB0 may consist of a TM RLC entity and a logical channel. SRB0 may always be established in a terminal device in all states (such as RRC idle state, RRC connected state, and RRC inactive state). 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 the RRC idle state to the RRC connected state. SRB1 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB1 may consist of an AM RLC entity and a logical channel. SRB2 may be established and / or configured in a terminal device in an RRC connected state with AS security activated by an RRC message received from a base station device. SRB2 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB2 may consist of an AM RLC entity and a logical channel. Note that 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 a terminal device in an RRC connected state with AS security activated by an RRC message received from a base station device when a secondary node in EN-DC, NGEN-DC, or NR-DC is added or when the secondary node is changed. SRB3 may be a direct SRB between the terminal device and the secondary node. SRB3 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB3 may consist of an AM RLC entity and a logical channel. The PDCP on the base station device side of SRB3 may be placed in the secondary node.One or more DRBs may be established and / or configured in a terminal device by an RRC message received from a base station device by a terminal device in an RRC connected state with AS security activated. A DRB may consist of one PDCP entity and one or more RLC bearers. An RLC bearer of a DRB may consist of an AM or UM RLC entity and a logical channel.

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

[0124] 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 an MN terminated MCG bearer and / or an 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 an SN terminated SCG bearer. Also, when MR-DC is configured in a terminal device, the bearer type of the DRB established / and / or configured in the terminal device may be any of all bearer types.

[0125] For an RLC bearer established and / or configured in a cell group configured with 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 configured with NR, the RLC entity established and / or configured may be an NR RLC. When an EN-DC is configured in the terminal device, the PDCP entity established and / or configured for an MN-terminated MCG bearer may be either an E-UTRA PDCP or an NR PDCP. When an EN-DC is configured in the terminal device, the PDCP entity 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. When an NGEN-DC, NE-DC, or NR-DC is configured in the terminal device, the PDCP entity established and / or configured for radio bearers of all bearer types may be an NR PDCP.

[0126] In NR, a DRB established and / or configured in a terminal device may be associated with 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 channels 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.

[0127] Regardless of whether MR-DC is configured, a network configuration in which the master node is eNB102 and EPC104 is the core network may be called E-UTRA / EPC. Also, a network configuration in which the master node is eNB102 and 5GC110 is the core network may be called E-UTRA / 5GC. Also, a network configuration in which the master node is gNB108 and 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.

[0128] Next, handover in LTE and NR will be described. Handover may be a process in which a UE 122 in an RRC connected state changes its serving cell. Handover may be performed when the UE 122 receives an RRC message instructing handover from the eNB 102 and / or the gNB 108. The RRC message instructing handover may be a message related to reconfiguration of the RRC connection including a parameter instructing handover (e.g., an information element named MobilityControlInfo or an information element named ReconfigurationWithSync). 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 above-mentioned information element named ReconfigurationWithSync may be rephrased as a reconfiguration with synchronization information element, or reconfiguration with synchronization. The RRC message instructing handover may be a message indicating movement to a cell of another RAT (e.g., MobilityFromEUTRACommand or MobilityFromNRCommand). Alternatively, handover may be referred to as reconfiguration with sync. The conditions under which UE 122 can perform handover may include some or all of the following: AS security is activated, an SRB2 is established, and at least one DRB is established.

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

[0130] In FIG. 4, the base station device creates an RRC message (step S400). The base station device may create an RRC message in order to deliver system information (SI) or paging information. The base station device may also create an RRC message in order to have a specific terminal device perform a process. The process to be performed by the specific terminal device may include, for example, security settings, RRC connection reconfiguration, handover to a different RAT, RRC connection suspension, and RRC connection release. The RRC connection reconfiguration process may include, for example, radio bearer control (establishment, modification, release, etc.), cell group control (establishment, addition, modification, release, etc.), measurement setting, handover, security key update, etc. The base station device may also create an RRC message in order to respond to an RRC message transmitted from the 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, a response to an RRC resumption request, etc. The RRC message includes parameters for various information notifications and settings. These parameters may be called fields and / or information elements and may be described using a description format called ASN.1 (Abstract Syntax Notation One). In the embodiments of the present invention, parameters may also be referred to as information.

[0131] 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 as a response to the base station device (not shown).

[0132] The RRC messages may be used for other purposes, not limited to the above examples.

[0133] 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, an NR RRC message may be included in the form of a container in an E-UTRA RRC message transmitted and received between the eNB 102 and the UE 122. In NE-DC, an E-UTRA RRC message may be included in the form of a container in an NR RRC message transmitted and received between the gNB 108 and the UE 122. The RRC message for SCG side configuration may be transmitted and received between the master node and a secondary node.

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

[0135] An example of parameters included in an RRC message related to RRC connection re-establishment will be described. FIG. 7 shows an example of ASN.1 description representing fields and / or information elements related to radio bearer establishment included in a message related to RRC connection re-establishment in NR in FIG. 4. FIG. 8 shows an example of ASN.1 description representing fields and / or information elements related to radio bearer establishment included in a message related to RRC connection re-establishment in E-UTRA in FIG. 4. In the ASN.1 examples according to the embodiments of the present invention, including but not limited to FIGS. 7 and 8, "omitted" and "omitted" are not part of the ASN.1 notation and indicate that other information has been omitted. Note that information elements may be omitted even in places where "omitted" or "omitted" is not written. Note that the ASN.1 examples according to the embodiments of the present invention do not strictly follow the ASN.1 notation. The ASN.1 examples according to the embodiments of the present invention show an example of parameters of an RRC message according to the embodiments of the present invention, and other names and notations may be used. In addition, to avoid complication of explanation, the ASN.1 examples only show 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, fields, information elements, etc. described in ASN.1 included in an 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.

[0136] 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 and an SDAP setting information element, which will be described later. The information element represented by RadioBearerConfig may be referred to as a radio bearer setting information element or radio bearer setting. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be referred to as an information element indicating SRB (signaling radio bearer) setting. The information element represented by SRB-ToAddMod may be referred to as an SRB setting information element or SRB setting. Furthermore, 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 referred to as an information element 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 DRB configurations. Note that SRB configuration and DRB configuration may also be referred to as radio bearer configuration.

[0137] The field represented by srb-Identity in the SRB configuration information element is information about the 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 configuration information element may be referred to as the SRB identifier field or the SRB identifier. The SRB identifier may also be referred to as the radio bearer identifier.

[0138] The field represented by drb-Identity in the DRB setting information element is information about 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 Figure 7, the value of the DRB identifier is an integer value from 1 to 32, but it may take on a different value. In the case of DC, the DRB identifier may be unique within the scope of UE 122. The DRB identifier may also be referred to as the radio bearer identifier.

[0139] The field represented by cnAssociation in the DRB configuration information element may be a field indicating whether the radio bearer is associated with a field represented by eps-bearerIdentity (described later) or with an information element represented by SDAP-Config (described later). 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 later) when the terminal device connects to the EPC104. Furthermore, the field represented by cnAssociation may include an information element (SDAP-Config) indicating an SDAP configuration (described later) when the terminal device connects to the 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 represented by eps-bearerIdentity may be referred to as an EPS bearer identifier field or EPS bearer identifier.

[0140] The information element represented by SDAP-Config may be information related to 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 SDAP configuration.

[0141] 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 PDU session identifier. The PDU session identifier may be the PDU session identifier of the PDU session. Furthermore, the corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

[0142] The field indicated by mappedQoS-FlowsToAdd included in the SDAP configuration information element may be information indicating a list of QoS Flow Identity (QFI) 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 the QoS flow of the PDU session indicated by the PDU session included in this SDAP configuration information element. Furthermore, the corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

[0143] Furthermore, 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 from 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. Furthermore, the corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

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

[0145] Furthermore, the information element represented by PDCP-Config among the SRB configuration information element and the DRB configuration information element may be an information element related to the configuration of the NR PDCP entity. The information element represented by PDCP-Config may be referred to as the PDCP configuration information element or the PDCP configuration. The information element related to 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 a profile of ROHC (Robust Header Compression), a field indicating the value of the re-ordering timer, and the like.

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

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

[0148] The field represented by srb-Identity in the SRB configuration information element is information about the 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 configuration 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 SRB identifier in Figure 8 may have the same role as the SRB identifier in Figure 7.

[0149] The field represented by drb-Identity in the DRB setting is information about 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 on 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.

[0150] The field represented by eps-BearerIdentity in the DRB setting information element may be an EPS bearer identifier that uniquely identifies an EPS bearer in each terminal device. The 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 Figure 8, but it may take on a different value. The EPS bearer identifier in Figure 8 may have the same role as the EPS bearer identifier in Figure 7. Furthermore, there may be a one-to-one correspondence between the EPS bearer identifier and the DRB identifier in each terminal device.

[0151] Furthermore, the information element represented by PDCP-Config among the SRB configuration information element and the DRB configuration information element may be an information element related to the configuration of an 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 an E-UTRA PDCP entity may include a field indicating the size of a sequence number, a field indicating a profile of RObust Header Compression (ROHC), a field indicating a value of a re-ordering timer, etc.

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

[0153] 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 also 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.

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

[0155] In NR, information elements related to RLC bearer configuration, such as information elements related to NR RLC entity configuration for each radio bearer, information elements indicating logical channel identifier (ID) information, and information elements related to logical channel configuration, may be included in information elements related to cell group configuration (not shown) rather than in the information elements represented by RadioBearerConfig in FIG. 7. Information elements related to cell group configuration may be included in messages related to RRC connection reconfiguration. Information elements related to cell group configuration may be referred to as cell group configuration information elements or cell group configuration. Information elements related to NR RLC entity configuration may be referred to as RLC configuration information elements or RLC configuration. Information elements indicating logical channel identifier information may be referred to as logical channel identifier information elements or logical channel identifiers. Information elements related to logical channel configuration may be referred to as logical channel configuration information elements or logical channel identifiers. Note that logical channel identifiers may be linked to radio bearer identifiers.

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

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

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

[0159] 5 includes a receiver 500 that receives RRC messages and the like from a base station device, a processor 502 that performs processing according to parameters included in the received messages, and a transmitter 504 that transmits RRC messages and the like to the base station device. The base station device may be the eNB 102 or the gNB 108. The processor 502 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processor 502 may include some or all of the functions of the physical layer processor, MAC layer processor, RLC layer processor, PDCP layer processor, SDAP processor, RRC layer processor, and NAS layer processor.

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

[0161] 6 includes a transmitter 600 that transmits an RRC message or the like to the UE 122, a processor 602 that creates an RRC message including parameters and transmits the message to the UE 122, causing the processor 502 of the UE 122 to process the message, and a receiver 604 that receives the RRC message or the like from the UE 122. The processor 602 may include some or all of the functions of various layers (e.g., the 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 functions of the physical layer processor, MAC layer processor, RLC layer processor, PDCP layer processor, SDAP processor, RRC layer processor, and NAS layer processor.

[0162] A conditional handover (CHO) according to an embodiment of the present invention will be described. The conditional handover may be the conditional handover described in Non-Patent Document 1 or the like. A terminal device may configure a conditional handover by receiving an RRC message including conditional handover configuration parameters from a base station device. The conditional handover configuration parameters may include configuration parameters for a target candidate SpCell and execution condition parameters for applying the configuration to the target candidate SpCell and executing a handover. The conditional handover may be a handover in which a handover procedure is executed by the terminal device when one or more execution conditions are satisfied. Note that the conditional handover may also be referred to as conditional reconfiguration. The conditional handover may also be referred to as handover. Note that the RRC message including the conditional handover configuration information element may be a message related to reconfiguration of an RRC connection or an RRC reconfiguration message.

[0163] A handover failure process according to an embodiment of the present invention will now be described. In the event of a handover failure, the UE 122 reverts back to the settings used at the handover source and performs an RRC re-establishment procedure. In the RRC re-establishment procedure, the UE 122 performs a cell search, then transmits an RRC re-establishment request message to a base station device in a cell selected by the cell search, receives a response message (RRC re-establishment message) from the base station device, and transmits the response message (RRC re-establishment completion message) to the base station device, thereby reestablishing the RRC connection. In the RRC re-establishment procedure, security keys are updated, and radio bearer state variables, timers, etc. are initialized. However, if the UE 122 is configured with the "attemptCondReconfig" setting (described later) and the cell selected in the RRC re-establishment procedure is one of the candidate handover destinations (targets) for a conditional handover, a conditional handover is performed in the selected cell. When a conditional handover is performed, if the conditional handover does not involve key updating, the radio bearer state variables, timers, etc. are not initialized. Because the configuration, including the state variables, reverts to the configuration used in the source when the handover fails, when the conditional handover is performed, the UE 122 may use the same state variable values ​​as the state variables used in the target before the handover failure. This creates a problem where the same COUNT value is used twice for the same security key, and also creates a problem where the RLC entity processes different data as if they were the same data.

[0164] 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 FIG. 9 may be an information element indicating a target candidate SpCell in a conditional handover and configuration of a conditional handover execution condition. The information element represented by ConditionalReconfiguration may be referred to as a conditional handover configuration information element or conditional handover configuration. The conditional handover configuration information element may also be used for a conditional PSCell change.

[0165] 9, a field represented by "attemptCondReconfig" included in the conditional handover configuration information element may be configured to indicate that, if this field exists, a conditional reconfiguration is performed on a candidate SpCell when the first selected cell after a handover failure is one of the candidate SpCells included in the conditional handover configuration information element. The field represented by "attemptCondReconfig" may be referred to as an "attempt conditional reconfiguration field" or "attempt conditional reconfiguration."

[0166] 9, the information element represented by CondReconfigToRemoveList included in the conditional handover configuration 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.

[0167] 9, an information element represented by CondReconfigToAddModList included in the conditional handover configuration information element may be a list of candidate SpCell configurations 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. Furthermore, 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.

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

[0169] 9, a field represented by condExecutionCond included in the conditional reconfiguration information element may be an execution condition that must be met to trigger 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.

[0170] In Figure 9, the information element represented by condRRCReconfig 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. The information element represented by condRRCReconfig may be referred to as the conditional reconfiguration information element or conditional reconfiguration. Furthermore, the inclusion of the conditional reconfiguration information element in the information elements and / or fields of the RRC reconfiguration message included in the conditional reconfiguration information element may be prohibited.

[0171] The above-mentioned conditional reconfiguration information element may include, for example, some or all of the following configurations (A) to (F): (A) Cell group configuration (which may be an information element represented by the name CellGroupConfig). (B) Information indicating whether or not it is a full configuration (which may be a field represented by fullConfig). (C) NAS layer message (which may be an information element represented by the name DedicatedNAS-message). (D) Key update configuration (which may be an information element represented by the name MasterKeyUpdate). (E) Measurement configuration (which may be an information element represented by the name MeasConfig). (F) Radio bearer configuration.

[0172] Furthermore, the above-mentioned cell group configuration information may include, for example, some or all of the following configurations (1) to (6): (1) Cell group identifier (which may be an information element represented by the name CellGroupId). (2) RLC bearer configuration (which may be an information element represented by the name RLC-BearerConfig). (3) Cell group MAC layer configuration (which may be an information element represented by the name MAC-CellGroupConfig). (4) Cell group physical (PHY) layer configuration (which may be an information element represented by the name PhysicalCellGroupConfig). (5) SpCell configuration (which may be an information element represented by the name SpCellConfig). (6) SCell information (which may be an information element represented by the name SCellConfig). Note that the SpCell configuration in (5) may include a synchronized reconfiguration information element. The synchronized reconfiguration information element included in the SpCell configuration in (5) may include a physical cell identifier of the target candidate SpCell (which may be an information element represented by the name PhysCellId).

[0173] Furthermore, the radio bearer configuration described above may include some or all of the following configurations (1) to (3): (1) SRB configuration, (2) DRB configuration, and (3) security configuration (which may be an information element named "SecurityConfig"). The security configuration (3) may include information on the integrity protection algorithm and encryption algorithm for the SRB and / or DRB (which may be an information element named "SecurityAlgorithmConfig"), and / or information indicating whether to use an MCG key or an SCG key (which may be a field named "keyToUse").

[0174] The above-mentioned candidate SpCell may be referred to as a target candidate SpCell. Also, the SpCell may be referred to as a Cell, a PCell, or a PSCell.

[0175] An example of processing by a terminal device in an embodiment of the present invention will be described with reference to Fig. 10. The example of processing by a terminal device in an embodiment of the present invention, which will be described with reference to Fig. 10, is an example of a method for solving the problem in the case of a handover failure described above.

[0176] FIG. 10 is a diagram showing an example of processing by 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)

[0177] An example of the initiation 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 if the first synchronization-added reconfiguration information element is not included in the conditional handover configuration information element, the processing unit 502 of the UE 122 may apply the first synchronization-added reconfiguration information element and initiate the handover procedure for the first SpCell in accordance with the first synchronization-added reconfiguration information element. The above-mentioned case where the RRC message received from the base station device includes the first synchronization-added reconfiguration information element and the first synchronization-added reconfiguration information element is not included in the conditional handover configuration information element may be a case of non-conditional handover or normal handover. Note that if the RRC message received from the base station device does not include the first synchronization-added reconfiguration information element, the handover procedure for the first SpCell does not need to be initiated. (Step S1002)

[0178] Another 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 conditional handover configuration information element, the processing unit 502 of the UE 122 may configure the UE 122 according to the above-mentioned conditional handover configuration information element. Here, the above-mentioned handover configuration information element may include a conditional reconfiguration list information element. Furthermore, the above-mentioned conditional reconfiguration list information element may include first to Nth conditional reconfiguration information elements (where N is a positive integer). At a certain point in time, if the mth conditional reconfiguration execution condition included in the mth conditional reconfiguration information element configured in the UE 122 is satisfied, the processing unit 502 of the UE 122 may perform processing including the following (A). Here, the above-mentioned m may be an integer greater than or equal to 1 and less than or equal to N. (A) The mth conditional reconfiguration information element included in the above-mentioned mth conditional reconfiguration information element may be applied, and a handover procedure for the mth SpCell may be initiated in accordance with the mth synchronized reconfiguration information element included in the above-mentioned mth conditional reconfiguration information element. Note that the above-mentioned handover for the mth SpCell may be rephrased as the above-mentioned conditional handover for the mth SpCell. Also, if the above-mentioned mth conditional reconfiguration execution condition is not satisfied, the processing unit 502 of the UE 122 does not need to perform the above-mentioned process (A). (Step S1002)

[0179] In step S1002, the first SpCell and the mth SpCell may be the same cell. Also in step S1002, the processing unit 502 of the UE 122 may start a first timer for the first SpCell when performing handover to the first SpCell. Also in step S1002, the processing unit 502 of the UE 122 may start the first timer for the mth SpCell when performing handover to the mth SpCell. When starting the first timer for the first SpCell, the processing unit 502 of the UE 122 may apply a value to be applied to the first timer, which is included in the first synchronized reconfiguration information element, to the first timer. Furthermore, when activating the first timer for the mth SpCell, the processing unit 502 of the UE 122 may apply a value to be applied to the first timer, which is included in the mth synchronized reconfiguration information element, to the first timer. The first timer may be a timer used to detect a handover failure, for example. The first timer may be a timer that starts when an RRC message instructing a handover is received and stops when random access to the corresponding (handover destination) SpCell is successful, for example. When the first timer expires, the handover may be considered to have failed. The first timer may be a timer named T304.

[0180] When the 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).

[0181] In the handover failure procedure of step S1004, the processing unit 502 of the UE 122 checks whether a first configuration has been performed on the UE 122. The first configuration may be the conditional reconfiguration described above. That is, the first configuration may be a configuration indicating that conditional reconfiguration is to be performed on a candidate SpCell if the cell initially selected after a handover failure is one of the candidate SpCells included in the conditional handover configuration information element. The fact that the first configuration has been performed may also be expressed as the RRC message received in step S1000 including (or including) a conditional handover configuration information element including an attempt conditional reconfiguration field. The processing unit 502 of the UE 122 may also check whether the handover of the UE 122 in step S1002 involved a security key update. The handover of UE 122 in step S1002 involving security key updating may be rephrased as "the RRC reconfiguration message or RRC reconfiguration information element applied to the handover in step S1002 included (or includes) the above-mentioned parameters related to key update configuration." The handover of UE 122 in step S1002 not involving security key updating may be rephrased as "the RRC reconfiguration message or RRC reconfiguration information element applied to the handover in step S1002 did not include (or does not include) the above-mentioned parameters related to key update configuration." The handover in step S1002 may be the above-mentioned normal handover, i.e., a handover to the first SpCell in accordance with the above-mentioned first synchronized reconfiguration information element. The handover in step S1002 may also be the above-mentioned conditional handover, i.e., a handover to the mth SpCell in accordance with the above-mentioned mth conditional reconfiguration information element. Furthermore, the handover of the UE 122 in step S1002 may be rephrased as a previous handover, or a handover, or a previous synchronized reconfiguration, or a synchronized reconfiguration, or the like.Furthermore, the handover of UE 122 in step S1002 may be replaced with another term as long as it means the handover that caused the expiration of the first timer in step S1002. The above-mentioned parameter related to the key update setting may be an information element named "MasterKeyUpdate" and / or a field named "masterKeyUpdate." Note that security key update may be replaced with key update.

[0182] 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 (C) based on the satisfaction of at least the first condition described above: (A) retain some of the configurations of the UE 122 for some or all of the radio bearers established and / or configured in the UE 122; (B) revert back the configurations of the UE 122, excluding at least the some of the configurations described above (the configurations retained in (A) above), to the configurations used in the source PCell; (C) re-establish some entities for some or all of the radio bearers established and / or configured in the UE 122. Note that in the above (A) and (C), some or all of the radio bearers established and / or configured in the UE 122 may be some or all of the SRBs and / or DRBs established and / or configured in the UE 122. Furthermore, in the above (A), "some of the settings" may include some or all of the state variables and / or timers and / or parameters and / or counters in the PDCP entity and / or the RLC entity and / or the radio bearer. Furthermore, in the above (A), "maintaining the settings" may mean not restoring the settings to the settings used in the source PCell, but maintaining the settings immediately before the expiration of the first timer. Furthermore, in the above (C), "some of the entities" may include the RLC entity. Furthermore, the above (C) may be rephrased as "re-establishing the RLC entity for the SRB."

[0183] Furthermore, 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 (D) to (F) based on the fact that at least the first condition is satisfied: (D) retain some of the configurations of the UE 122; (E) revert back all of the configurations of the UE 122, excluding at least the above-mentioned some of the configurations (the configurations retained in the above-mentioned (D)), to the configurations used in the source PCell; (F) reestablish some of the entities. In the above-mentioned (D), the some of the configurations may include some or all of the state variables and / or timers and / or parameters and / or counters of the PDCP entity and / or the RLC entity and / or the radio bearer. In the above-mentioned (D), retaining the configurations may mean not reverting the configurations to the configurations used in the source PCell, but maintaining the configurations immediately before the expiration of the above-mentioned first timer. In the above-mentioned (F), the some of the entities may include the RLC entity.

[0184] In the handover failure procedure of step S1004, the above-mentioned first condition 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 was not accompanied by a security key update. Also, 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 was not accompanied by a security key update.

[0185] Furthermore, in the handover failure procedure of step S1004, the above-described processes (A) and (B) may be processes of applying the target PCell's (or the target PCell's) configuration to some of the settings after restoring the UE 122's configuration to the configuration used in the source PCell for some or all of the radio bearers established and / or configured in the UE 122. Furthermore, in the handover failure procedure of step S1004, the above-described processes (D) and (E) may be processes of applying the target PCell's (or the target PCell's) configuration to some of the settings after restoring the UE 122's configuration to the configuration used in the source PCell.

[0186] Furthermore, in the handover failure procedure of step S1004, the processing unit 502 of the UE 122 may perform a process of restoring the configuration of the UE 122 to the configuration used in the source PCell, based on the fact that at least the above-mentioned first condition is not satisfied. The fact that the above-mentioned first condition is not satisfied may mean that some or all of the following conditions are not met: the above-mentioned first configuration is configured in the UE 122; and the handover of the UE 122 in step S1002 was not accompanied by key updating.

[0187] In addition, in the handover failure procedure in step S1004, the fact that the first condition is not satisfied may be rephrased as an "else" condition for the fact that the first condition is satisfied.

[0188] After the handover failure process of step S1004, the processing unit 502 of the UE 122 may further perform processes including some or all of the following processes (F) to (G): (F) Store information about the above-mentioned handover failure in a variable related to a radio link failure of the UE 122. (G) Initiate an RRC connection re-establishment procedure. The variable related to the radio link failure in the above-mentioned (F) may be a variable named VarRLF-Report. Furthermore, the RRC connection re-establishment procedure in the above-mentioned (G) may be an RRC re-establishment procedure. The RRC re-establishment procedure may include a procedure in which the terminal device selects a cell to re-establish the RRC connection, transmits an RRC re-establishment request message to the base station device, and receives the RRC re-establishment message from the base station device.

[0189] In the above-described RRC reconnection procedure after the handover failure process in step S1004 (not shown), the processing unit 502 of the UE 122 may perform a process of applying the configuration of the target PCell (or that was used in the target PCell) to some of the configurations of the UE 122 for some or all of the radio bearers established and / or configured in the UE 122, based on whether at least some or all of the following conditions (1) to (4) are met: (1) The above-described first configuration is performed in the UE 122; (2) The handover of the UE 122 in step S1002 did not involve key updating; (3) The selected cell is one of the candidate SpCells for the conditional handover; or (4) The conditional handover to the selected cell does not involve key updating. Note that the above-described some or all of the radio bearers established and / or configured in the UE 122 may be some or all of the SRBs and / or DRBs established and / or configured in the UE 122. Furthermore, the above-mentioned part of the settings may include some or all of the state variables and / or timers and / or parameters and / or counters in the PDCP entity and / or RLC entity and / or radio bearer.

[0190] The handover failure process of step S1004 described above may be performed based on the fact that at least some or all of the following conditions (H) to (I) are not met: (H) A DAPS (Dual Active Protocol Stack) bearer is established. (I) A radio link failure in the source PCell is not detected. The DAPS bearer in the above (H) may be the DAPS bearer described in Non-Patent Document 1, etc. The DAPS bearer may be a radio bearer that has some or all of the radio (AS) protocols in both the source and target since it uses resources from both the source and target during DAPS handover. The source described above may be the source PCell. The source described above may also be a source base station device. The target described above may also be a target PCell. The target described above may also be a target base station device.

[0191] In an embodiment of the invention, the "configuration of UE 122" when restoring the configuration of UE 122 to the configuration used in the source PCell may be interpreted as including the state variables and parameters of each radio bearer. Also, in an embodiment of the invention, the "configuration of UE 122" when restoring the configuration of UE 122 to the configuration used in the source PCell may be interpreted as including the state variables and parameters of each radio bearer unless otherwise specified.

[0192] In embodiments of the invention, Cell, PCell, SpCell, PSCell, MCG, SCG, and cell group may be interchangeable.

[0193] In this way, in an embodiment of the present invention, by appropriately maintaining state variables, etc. in processing after a handover failure, security issues, etc. can be avoided and efficient communication can be performed when a terminal device is handed over.

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

[0195] In the above description, expressions such as "link," "associate," and "link" may be interchangeable.

[0196] In the above description, "the above-mentioned" may be replaced with "the above-mentioned."

[0197] In the above description, the "SpCell of an SCG" may be replaced with the "PSCell."

[0198] Furthermore, in each example of processing or each example of processing flow in the above description, some or all of the steps may not be executed. Furthermore, in each example of processing or each example of processing flow in the above description, the order of the steps may be different. Furthermore, in each example of processing or each example of processing flow in the above description, some or all of the processing within each step may not be executed. Furthermore, in each example of processing or each example of processing flow in the above description, the order of the processing within each step may be different. Furthermore, in the above description, "performing B based on A being true" may be rephrased as "performing B." In other words, "performing B" may be executed independently of "A being true."

[0199] 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".

[0200] 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."

[0201] Various aspects of the terminal device, base station device, and method according to the embodiments of the present invention will be described below.

[0202] (1) A terminal device communicating 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, wherein the processing unit configures the terminal device according to the RRC message; performs handover failure processing based on expiration of a first timer of the terminal device; and, in the handover failure processing, performs processing to retain some of the configurations of the terminal device for some or all radio bearers based on at least a first condition being satisfied, and to restore the configurations excluding at least the some of the configurations to the configurations used in a source PCell; and, in the handover failure processing, performs processing to restore the configurations of the terminal device to the configurations used in the source PCell based on at least the first condition not being satisfied, wherein the first condition includes at least that a first configuration is configured in the terminal device and that the conditional handover performed by the terminal device does not involve key update, and the conditional handover is a handover in which a handover procedure is executed by the terminal device when a conditional handover execution condition configured in the terminal device is satisfied.

[0203] (2) A base station device that communicates with a terminal device, the base station device comprising: a transmitter that transmits an RRC message to the terminal device; and a processor, the processor 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, retains some of the configurations of the terminal device for some or all radio bearers based on the fact that at least a first condition is satisfied, and transfers the configurations excluding at least the some of the configurations to a source PCell. and, in the handover failure processing, performs a process of restoring the settings of the terminal device to the settings used in the source PCell based on the fact that at least the first condition is not satisfied, wherein 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 performed by the terminal device when a conditional handover execution condition set in the terminal device is satisfied.

[0204] (3) A method of a terminal device communicating with a base station device, wherein the terminal device receives an RRC message from the base station device, configures the terminal device according to the RRC message, performs handover failure processing based on expiration of a first timer of the terminal device, and in the handover failure processing, performs processing to retain some of the settings of the terminal device for some or all radio bearers and restore settings other than at least the some of the settings to settings used in a source PCell based on at least a first condition being satisfied, and in the handover failure processing, performs processing to restore settings of the terminal device to settings used in the source PCell based on at least the first condition not being satisfied, wherein the first condition includes at least that a first setting is configured in the terminal device and that the conditional handover performed by the terminal device does not involve key update, and the conditional handover is a handover in which a handover procedure is executed by the terminal device when a conditional handover execution condition configured in the terminal device is satisfied.

[0205] (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 perform configuration in accordance with the RRC message, causing the terminal device to perform handover failure processing based on expiration of a first timer of the terminal device, causing the terminal device to perform processing to retain some of the settings of the terminal device for some or all radio bearers and restore settings other than at least the some of the settings to settings used in a source PCell based on at least a first condition being satisfied in the handover failure processing, causing the base station device to perform processing to restore settings of the terminal device to settings used in the source PCell based on at least the first condition not being satisfied in the handover failure processing, the first condition including at least that a first configuration is configured in the terminal device and that the conditional handover performed by the terminal device does not involve key update, the conditional handover being 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.

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

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

[0208] It should be noted that a part of the device in the above-described embodiment may be realized by a computer. In this case, a program for realizing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be read by a computer system and executed to realize the control function. The "computer system" referred to here is 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, etc.

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

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

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

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

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

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

Claims

1. 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; Initiate a conditional handover; Starting a first timer; performing a handover failure process based on the expiration of a first timer of the terminal device; In the handover failure process, based on the fact that a first condition is satisfied, a process of retaining some of the settings of the terminal device for some or all of the radio bearers and returning the settings other than the some of the settings to the settings used in the source PCell; performing a process of returning a setting of the terminal device to a setting used in the source PCell based on the fact that at least the first condition is not satisfied in the process of the handover failure; The first condition includes at least that a first setting is performed on the terminal device and that the conditional handover 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.

2. The first configuration is a configuration indicating that, when a cell initially selected after a handover failure is one of the target candidate SpCells included in the conditional handover configuration, a conditional reconfiguration is performed on the target candidate SpCell. The terminal device according to claim 1 .

3. 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; Initiating a conditional handover; Starting a first timer; 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 process, based on a first condition being satisfied, a process is performed in which some of the settings of the terminal device are retained for some or all of the radio bearers, and settings other than the some of the settings are restored to settings used in a source PCell; performing a process of returning a setting of the terminal device to a setting used in the source PCell, based on the fact that at least the first condition is not satisfied in the process of the handover failure; The first condition includes at least that a first setting is performed on the terminal device and that the conditional handover 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.

4. The first configuration is a configuration indicating that, when a cell initially selected after a handover failure is one of the target candidate SpCells included in the conditional handover configuration, a conditional reconfiguration is performed on the target candidate SpCell. The base station device according to claim 3 .

5. 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; Initiate a conditional handover; Starting a first timer; performing a handover failure process based on the expiration of a first timer of the terminal device; In the handover failure process, based on the fact that a first condition is satisfied, a process of retaining some of the settings of the terminal device for some or all of the radio bearers and returning the settings excluding at least the some of the settings to the settings used in the source PCell; performing 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 in the process of the handover failure; The first condition includes at least that a first setting is performed on the terminal device and that the conditional handover 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, The first configuration is a configuration indicating that, when a cell initially selected after a handover failure is one of target candidate SpCells included in the conditional handover configuration, a conditional reconfiguration is performed on the target candidate SpCell. method.