Terminal device, base station device, and wireless communication system

Abstract

This terminal device has a reception unit and a processing unit. The reception unit receives signals from a first master base station device and a first secondary base station device. The reception unit also receives, from the first master base station device, a first signal including a first configuration for a first candidate cell. When a first cell-switching command to the first candidate cell is received from the first master base station device, the processing unit performs a first determination for determining whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device. Meanwhile, when the first candidate cell is a cell belonging to the second master base station device, the control unit performs first processing related to the configuration of the master base station device and second processing related to the configuration of a secondary base station device, and performs cell switching to the first candidate cell.

Description

Terminal device, base station device, and wireless communication system

[0001] The present invention relates to a terminal device, a base station device, and a wireless communication system.

[0002] Currently, wireless communication networks using mobile devices (smartphones, feature phones, etc.) are expanding. With the expansion of wireless communication, there is a demand for even faster speeds and larger capacities.

[0003] The 3rd Generation Partnership Project (3GPP), an international standardization project, is conducting technical studies and formulating standards for cellular mobile communication systems. For example, E-UTRA (Evolved Terrestrial Radio Access) has been standardized as the radio access technology (RAT) for 3.9th generation (3.9G) and 4th generation (4G), and EPC (Evolved Packet Core) has been standardized as the core network (CN) technology. Furthermore, NR (New Radio) has been standardized as the RAT for 5th generation (5G), and 5G Core (5GC) has been standardized as the core network technology. Furthermore, these extension technologies are currently being continuously studied and standardized.

[0004] Technologies related to NR or 5G systems are described, for example, in the following Non-Patent Documents 1 to 11.

[0005] 3GPP TS38.300 v18.0.0 NR Overview Specification 3GPP TS38.211 v18.0.0 NR PHY Channel and Modulation Specification 3GPP TS38.321 v18.0.0 NR MAC Specification 3GPP TS38.322 v18.0.0 NR RLC Specification 3GPP TS38.323 v18.0.0 NR PDCP Specification 3GPP TS37.324 v18.0.0 NR SDAP Specification 3GPP TS38.304 v18.0.0 NR Idle Mode and Inactive Mode Specification 3GPP TS38.331 v18.1.0 NR RRC Specification 3GPP RP-223520 "Revised WID on Further NR Mobility Enhancements" 3GPP RP-241515 "Revised Work Item: NR Mobility Enhancements" Phase 4" 3GPP TS33.501 v18.4.0 5G System Security Specification

[0006] As one of the extension technologies, technical studies on improving mobility are being conducted. As one of the items under study, a technology called L1 / L2-triggered mobility (LTM) was defined in Rel-18 (Non-Patent Document 9). This technology aims to reduce latency in mobility by having a base station switch the serving cell of a terminal device using Layer 1 and / or Layer 2 signals instead of Layer 3 signals such as RRC (Radio Resource Control) messages. Furthermore, Rel-19 is expected to define specifications for LTM that further extend the LTM in Rel-18, which only supports intra-CU (intra-CU) cell switching, to also support inter-CU (inter-CU) cell switching (Non-Patent Document 10).

[0007] However, the specific method of LTM that supports both intra-CU and inter-CU cell switching has not been determined as a standard specification. For example, the specification has not been determined regarding a method for realizing cell switching between multiple LTM candidate cells that supports both intra-CU and inter-CU cell switching without reconfiguration using an RRC message. Furthermore, the specification has not been determined regarding the processing of a terminal device when cell switching by inter-CU LTM fails. Furthermore, the specific method of LTM that supports both intra-CU and inter-CU cell switching when DC (Dual Connectivity) is set in the terminal device has not been determined as a standard specification.

[0008] Therefore, one disclosure provides a base station device, a terminal device, and a wireless communication system that enable flexible cell switching that supports both intra-CU and inter-CU cell switching.

[0009] One disclosure is a terminal device having a receiving unit that receives signals from a first master base station device and a first secondary base station device, and a processing unit, wherein the receiving unit receives a first signal from the first master base station device that includes a first setting for a first candidate cell, and when the processing unit receives a first cell switching command to the first candidate cell from the first master base station device, performs a first determination to determine whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device, and if the first candidate cell is a cell belonging to the second master base station device, performs a first process related to the setting of the master base station device and a second process related to the setting of the secondary base station device, and performs cell switching to the first candidate cell.

[0010] Another disclosure is a base station device in which the processing unit controls the terminal device to transmit a first cell switching command to the first candidate cell, thereby causing the terminal device to make a first determination of whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device, and if the first candidate cell is a cell belonging to the second master base station device, causes the terminal device to perform a first process related to the configuration of the master base station device and a second process related to the configuration of a secondary base station device, and performs cell switching to the first candidate cell.

[0011] Another disclosure is a wireless communication system having a first master base station device, a first secondary base station device, and a terminal device that receives signals from the first master base station device and the first secondary base station device, wherein the terminal device receives a first signal from the first master base station device that includes a first setting for a first candidate cell, and when the terminal device receives a first cell switching command to the first candidate cell from the first master base station device, performs a first determination to determine whether the first candidate cell is a cell that belongs to a second master base station device that is different from the first master base station device, and if the first candidate cell is a cell that belongs to the second master base station device, performs a first process related to the setting of the master base station device and a second process related to the setting of the secondary base station device, and performs cell switching to the first candidate cell.

[0012] According to one disclosure, when a terminal device in which a DC is set performs mobility processing, communication that efficiently performs processing related to setting a secondary node becomes possible.

[0013] FIG. 1 is a diagram showing an example of the configuration of a communication system 10. FIG. 2 is a diagram showing an example of the configuration of a base station device 200. FIG. 3 is a diagram showing an example of the configuration of a terminal device 100. FIG. 4 is a diagram showing an example of a protocol stack in the U-Plane. FIG. 5 is a diagram showing an example of a protocol stack in the C-Plane. FIG. 6 is a diagram showing an example of an RRC Reconfiguration message format. FIG. 7 is a diagram showing an example of the configuration of a cell group in the communication system 10. FIG. 8 is a diagram showing an example of synchronized reconfiguration. FIG. 9 is a diagram showing an example of parameters related to LTM included in an RRC Reconfiguration message. FIG. 10 is a diagram showing an example of an intra-CU LTM sequence. FIG. 11 is a diagram showing an example of a cell switching failure detection and cell switching failure processing sequence. FIG. 12 is a diagram showing an example of a subsequence cell switching method corresponding to intra-CU and inter-CU.

[0014] The present embodiment will be described in detail below with reference to the drawings. The problems and examples in this specification are merely examples and do not limit the scope of the rights of the present application. In particular, even if the expressions used are different, the technology of the present application can be applied as long as they are technically equivalent, and do not limit the scope of the rights.

[0015] In this embodiment, the names and processes of each device, node, function, protocol, entity, signaling, message, parameter, etc. when the radio access technology is E-UTRA or NR and when the core network is EPC or 5GC are described, but the embodiment may be used for other radio access technologies. The names of each node and entity in each embodiment may be different names.

[0016] <Configuration Example of Communication System 10> Fig. 1 is a diagram showing a configuration example of the communication system 10. The communication system 10 includes a terminal device 100, base station devices 200-1 and 200-2, and a core network 300. The communication system 10 may be a wireless communication system in which the terminal device 100 communicates with the base station device 200-1 or the base station device 200-2, or may be a wireless communication system in which the terminal device 100 communicates with the base station device 200-1 and the base station device 200-2 using MR-DC (Multi Radio Dual Connectivity) described below. When communicating using MR-DC, for example, the base station device 200-1 is a master base station device, and the base station device 200-2 is a secondary base station device. Hereinafter, the master base station device may be referred to as an MN (Master Node), and the secondary base station device may be referred to as an SN (Secondary Node).

[0017] The terminal device 100 is wirelessly connected to one or both of the base station device 200-1 and the base station device 200-2 and performs wireless communication. The RAT providing the wireless connection is, for example, E-UTRA or NR. The terminal device 100 is a terminal device that supports either or both of E-UTRA and NR.

[0018] The base station devices 200-1 and 200-2 (hereinafter, sometimes referred to as base station devices 200) are communication devices that are wirelessly connected to the terminal device 100 and perform wireless communication. The base station devices 200-1 and 200-2 are, for example, wired to each other and perform communication. The base station device 200 is, for example, wired to a core network 300 and performs communication. The base station device 200 is, for example, either an eNodeB (eNB) that provides E-UTRA as the RAT or a gNodeB (gNB) that provides NR as the RAT. Note that one base station device may be composed of one CU (centralized unit) and one or more DUs (distributed units). The CU may have the functions of, for example, RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), and PDCP (Packet Data Convergence Protocol) from the protocol stack described below. The CU may also have an interface function between base station devices and an interface function between the base station device and the core network. The DU may have functions such as RLC (Radio Link Control), MAC (Medium Access Control), and PHY (PHYsical) in the protocol stack described below.

[0019] The core network 300 is a network corresponding to a certain generation. For example, the core network 300 is a 5GC that is a core network standardized for 5G, or an EPC that is a core network standardized for 4G.

[0020] The MR-DC implemented in the communication system 10 will be described in detail later.

[0021] 2 is a diagram illustrating an example of the configuration of the base station device 200. The base station device 200 is a communication device or a relay device that includes a CPU (Central Processing Unit) 210, a storage 220, a memory 230, a wireless communication circuit 240, and a network interface (NI (Network Interface)) 250.

[0022] The storage 220 is an auxiliary storage device that stores programs and data, such as a flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The storage 220 stores a wireless communication program 221 and a base station side program 222.

[0023] The memory 230 is an area into which the programs stored in the storage 220 are loaded. The memory 230 may also be used as an area in which the programs store data.

[0024] The wireless communication circuit 240 is a circuit that wirelessly connects to and communicates with the terminal device 100. The base station device 200 receives a signal transmitted from the terminal device 100 via the wireless communication circuit 240, and transmits a signal to the terminal device 100, for example.

[0025] The NI 250 is, for example, a communication device that connects to other base station devices 200 and realizes inter-base station communication. The NI 250 is also, for example, a communication device that connects to the core network 300 (communication devices that constitute the core network 300) and performs communication. The NI 250 is, for example, a network interface card (NIC). The base station device 200 receives signals from other communication devices and transmits signals to other communication devices via the NI 250.

[0026] The CPU 210 is a processor that loads programs stored in the storage 220 into the memory 230, executes the loaded programs, configures each unit, and realizes each process.

[0027] The CPU 210 performs wireless communication processing by executing the wireless communication program 221. The wireless communication processing is processing for wirelessly connecting to the terminal device 100, communicating wirelessly with the terminal device 100, and relaying communication between the terminal device 100 and other communication devices.

[0028] The CPU 210 executes the base station side program 222 to configure a second transmitting unit, a second receiving unit, and a second processing unit, and perform base station side processing. When the base station device 200 communicates with the terminal device 100 using MR-DC, the base station side processing may include MR-DC master node processing and MR-DC secondary node processing. In this case, the MR-DC master node processing is processing for controlling the master node side of the MR-DC, and the MR-DC secondary node processing is processing for controlling the secondary node side of the MR-DC. In the MR-DC master node processing and the MR-DC secondary node processing, the base station device 200 performs communication corresponding to each type of MR-DC, which will be described later.

[0029] 3 is a diagram showing an example of the configuration of the terminal device 100. The terminal device 100 is a communication device having a CPU 110, a storage 120, a memory 130, and a wireless communication circuit 140.

[0030] The storage 120 is an auxiliary storage device such as a flash memory, HDD, or SSD that stores programs and data. The storage 120 stores a wireless communication program 121 and a terminal-side program 122.

[0031] The memory 130 is an area into which the programs stored in the storage 120 are loaded. The memory 130 may also be used as an area in which the programs store data.

[0032] The wireless communication circuit 140 is a circuit that wirelessly connects to and communicates with the base station device 200. The terminal device 100, for example, receives a signal transmitted from the base station device 200 via the wireless communication circuit 140 and transmits a signal to the base station device 200. The wireless communication circuit 140 is, for example, a network card that supports wireless connection.

[0033] The CPU 110 is a processor that loads programs stored in the storage 120 into the memory 130, executes the loaded programs, configures each unit, and realizes each process.

[0034] The CPU 110 performs terminal-side wireless communication processing by executing the wireless communication program 121. The terminal-side wireless communication processing is processing for wirelessly connecting to the base station device 200 and performing wireless communication with the base station device 200 or communication with another communication device via the base station device 200.

[0035] The CPU 110 executes the terminal-side program 122 to configure a transmitting unit, a receiving unit, and a processing unit, and to perform terminal-side processing. When the terminal device 100 communicates with the base station device 200 using MR-DC, the terminal-side processing may include terminal-side MR-DC processing. In this case, the terminal-side MR-DC processing is processing for controlling communication in the MR-DC. In the terminal-side MR-DC processing, the terminal device 100 performs communication corresponding to each type of MR-DC, which will be described later.

[0036] <Protocol Stack> An example of a protocol stack of the communication system 10 will be described. In the communication system 10, a series of protocols for transmitting and receiving data, shown in a hierarchical structure, is called a protocol stack. In the following example, the base station device 200 is an eNB or gNB, and the core network 300 is an EPC or 5GC. In addition, the terminal device 100 (UE: User Equipment) is assumed to support one or both of E-UTRA and NR.

[0037] The protocol stacks of the U-Plane (User Plane) and C-Plane (Control Plane) are explained below. The U-Plane is used, for example, to send and receive user data in communications. The C-Plane is used, for example, to send and receive control signals (messages) in communications. In each embodiment, unless otherwise specified, "user data" or "control signals (messages)" refers to either user data or control signals (messages), or both.

[0038] Figure 4 is a diagram showing an example of a protocol stack for the U-Plane when the core network 300 is 5GC. Also, Figure 5 is a diagram showing an example of a protocol stack for the C-Plane when the core network 300 is 5GC. In Figures 4 and 5, PHY (PHYsical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol), SDAP (Service Data Adaptation Protocol), RRC (Radio Resource Control), and NAS (Non Access Stratum) respectively indicate the names of layers. Hereinafter, PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS may be referred to as the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer, respectively. Furthermore, MAC, RLC, PDCP, and SDAP may be referred to as a MAC sublayer, an RLC sublayer, a PDCP sublayer, and an SDAP sublayer, respectively. Furthermore, MAC, RLC, PDCP, and SDAP may be referred to as a MAC entity, an RLC entity, a PDCP entity, and an SDAP entity, respectively. Note that when core network 300 is an EPC, the protocol stack of the U-Plane is a protocol stack in which SDAP does not exist in FIG. 4. That is, it is a protocol stack consisting of PHY, MAC, RLC, and PDCP. Furthermore, when core network 300 is an EPC, the protocol stack of the C-Plane is such that, in FIG. 5, NAS exists in an AMF (Access and Mobility management Function), whereas NAS exists in an MME (Mobility Management Entity).

[0039] The functions in each layer may be common or different between the E-UTRA and NR RATs. In the following description, if there is no specification of E-UTRA or NR, the functions are common to both E-UTRA and NR.

[0040] In each sublayer, data provided from and to an upper layer is called an SDU (Service Data Unit). That is, data provided from and to an upper layer to MAC, RLC, PDCP, and SDAP is called a MAC SDU, an RLC SDU, a PDCP SDU, and an SDAP SDU, respectively.

[0041] In each sublayer, data provided to and from the lower layer is called a PDU (Protocol Data Unit). That is, data provided from MAC, RLC, PDCP, and SDAP to the lower layer, and data provided from the lower layer to MAC, RLC, PDCP, and SDAP are called MAC PDU, RLC PDU, PDCP PDU, and SDAP PDU, respectively. RLC, PDCP, and SDAP also have control PDUs, which are sometimes called control PDUs. To distinguish them from control PDUs, other PDUs are sometimes called data PDUs.

[0042] In Figure 4, the U-Plane consists of PHY, MAC, RLC, PDCP, and SDAP, and terminates at the terminal device 100 (UE) and the base station device 200 (gNB).

[0043] An example of the function of the PHY will be described. The PHY is a wireless physical layer, and transmits control information and data between the terminal device 100 and the base station device 200 using a physical channel. The direction from the base station device 200 to the terminal device 100 is sometimes called the downlink (downlink, DL), and the direction from the terminal device 100 to the base station device 200 is sometimes called the uplink (uplink, UL). Furthermore, within the terminal device 100 and the base station device 200, the PHY is connected to the MAC, which is an upper layer, via a transport channel, and data moves between the PHY and the MAC via the transport channel. In the PHY, a Radio Network Temporary Identifier (RNTI) is used to identify various control information.

[0044] An example of MAC functions will be described. MAC is a medium access control layer, and performs mapping of transport channels and logical channels (LCHs), multiplexing and demultiplexing of MAC SDUs, scheduling reports (SRs), error correction through hybrid automatic repeat reQuest (HARQ), priority control, etc. In the terminal device 100 and the base station device 200, the MAC is connected to the RLC, which is an upper layer, via a logical channel, and data moves between the MAC and the RLC via the logical channel. The logical channel may be identified by a logical channel identifier (LCID). Furthermore, the base station device 200 controls the terminal device 100 using a MAC control element (CE). Furthermore, the terminal device 100 performs reports, etc. to the base station device 200 using a MAC CE.

[0045] RLC is the radio link control layer and has three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). On the transmitting side, RLC performs PDU transmission, sequence number assignment (in the case of UM and AM), SDU segmentation (in the case of UM and AM), and re-segmentation (in the case of AM). On the receiving side, RLC performs SDU reassembly (in the case of UM and AM), duplicate detection (in the case of AM), and SDU discarding (in the case of UM and AM). It also performs RLC re-establishment on the transmitting and receiving sides. Segmented SDUs are called SDU segments. RLC also has a data retransmission function and / or a retransmission request function (ARQ: Automatic Repeat reQuest) (in the case of AM). In addition, in the case of E-UTRA RLC, there are also other functions such as data combining on the transmitting side, and reordering and in-order delivery on the receiving side.

[0046] PDCP is a packet data convergence protocol layer, and performs data transfer between the U-Plane and C-Plane, PDCP sequence number management, header compression / decompression, encryption / decryption, integrity protection / integrity verification, timer-based SDU discard, routing for split bearers, reordering and in-order delivery, etc. In E-UTRA PDCP, functions such as timer-based SDU discard, reordering and in-order delivery may be limited to the case of split bearers, which will be described later.

[0047] SDAP is a service data adaptation protocol layer that performs tasks such as mapping QoS (Quality of service) flows to Data Radio Bearers (DRBs), which will be described later, and marking downlink (DL) packets and uplink (UL) packets with QoS flow identifiers (QFIs).

[0048] The upper layers of the U-Plane include, for example, IP (Internet Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), Ethernet (registered trademark), and application layers. A layer including IP, TCP, UDP, Ethernet, etc. may be called a PDU layer. Furthermore, IMS (IP Multimedia Subsystem), which controls sessions, may be included in the application layer.

[0049] 5, the C-Plane of the AS (Access Stratum) is composed of PHY, MAC, RLC, PDCP, and RRC, and terminates at the terminal device 100 and the base station device 200. The C-Plane of the NAS is composed of the NAS, and terminates between the terminal device 100 and the AMF, which is a device in the core network 300. The PHY, MAC, RLC, and PDCP are the same as those in the U-Plane.

[0050] The RRC performs functions such as broadcasting system information (SI) related to AS and NAS, paging, establishing / maintaining / releasing RRC connections between the terminal device 100 and the base station device 200, adding / changing / releasing carrier aggregation (CA), adding / changing / releasing dual connectivity (DC), security functions including security key management, establishing / setting / maintaining / releasing signaling radio bearers (SRBs) and data radio bearers (DRBs), mobility functions, QoS management functions, controlling terminal device measurement reports and reporting, detecting and recovering from radio link failures (RLFs), and forwarding NAS messages. Note that a radio link failure may be, for example, detection of a physical layer problem, a random access failure, or the maximum number of retransmissions by RLC.

[0051] The NAS performs authentication, mobility management, security control, etc. on the core network side.

[0052] <Channels> The channels used in the communication system 10 will be described. Below, examples of channels corresponding to NR are shown, but the channels used are not limited to the following. In addition, channels with the same name can be used for the same or similar purposes in RATs other than NR, such as E-UTRA.

[0053] <1. Physical Channel> The PBCH (Physical Broadcast CHannel) is a channel used for transmitting broadcast information from the base station device 200 to the terminal device 100 .

[0054] The PDCCH (Physical Downlink Control CHannel) is a channel used to transmit downlink control information (DCI) and the like from the base station device 200 to the terminal device 100 .

[0055] The PDSCH (Physical Downlink Shared CHannel) is a channel used to transmit data from an upper layer from the base station device 200 to the terminal device 100.

[0056] The PUCCH (Physical Uplink Control CHannel) is a channel used to transmit uplink control information (UCI) and the like from the terminal device 100 to the base station device 200 .

[0057] A PUSCH (Physical Uplink Shared CHannel) is a channel used to transmit data from an upper layer from the terminal device 100 to the base station device 200.

[0058] The PRACH (Physical Random Access CHannel) is a channel used to transmit a random access preamble and the like from the terminal device 100 to the base station device 200 .

[0059] 2. Transport Channels The BCH (Broadcast Channel) is mapped to the PBCH, which is a physical channel.

[0060] The DL-SCH (Downlink Shared Channel) is mapped to the PDSCH, which is a physical channel.

[0061] The PCH (Paging Channel) is mapped to the PDSCH, which is a physical channel.

[0062] The UL-SCH (Downlink Shared Channel) is mapped to the PUSCH, which is a physical channel.

[0063] Random Access Channel(s) (RACH) are mapped to a PRACH, which is a physical channel.

[0064] <3. Logical Channel> The BCCH (Broadcast Control Channel) is a downlink channel for broadcasting system information, and is mapped to the transport channel BCH or DL-SCH.

[0065] A PCCH (Paging Control Channel) is a downlink channel for carrying paging messages and is mapped to the PCH of the transport channel.

[0066] The CCCH (Common Control Channel) is a channel for transmitting control information (such as RRC messages) between the terminal device 100 and the base station device 200, and is a channel used for the terminal device 100 that does not maintain (does not have) an RRC connection with the base station device 200, with the downlink mapped to the transport channel DL-SCH and the uplink mapped to the transport channel UL-SCH.

[0067] The DCCH (Dedicated Control Channel) is a point-to-point bidirectional channel that transmits dedicated control information (such as RRC messages) between the terminal device 100 and the base station device 200, and is used for the terminal device 100 that has an RRC connection with the base station device 200, with the downlink mapped to the transport channel DL-SCH and the uplink mapped to the transport channel UL-SCH.

[0068] A DTCH (Dedicated Transport Channel) is a point-to-point bidirectional channel dedicated to a terminal, which transmits user information (user data), and the downlink is mapped to the DL-SCH transport channel, and the uplink is mapped to the UL-SCH transport channel.

[0069] The MCCH (MBS Control Channel) is a point-to-multipoint downlink channel used to transmit MBS (Multicast Broadcast Service) broadcast control information corresponding to one or more MTCHs (MBS Traffic Channels) from the base station device 200 to the terminal device 100. The MCCH is mapped to the DL-SCH transport channel.

[0070] The MTCH is a point-to-multipoint downlink channel used to transmit MBS multicast session data or broadcast session data from the base station device 200 to the terminal device 100. It is mapped to the transport channel DL-SCH.

[0071] <RRC State (Mode)> The RRC state of the terminal device 100 is a state related to the RRC connection of the terminal device 100. A state in which an RRC connection with the base station device 200 is not established is called an RRC idle mode (RRC_IDLE). A state in which an RRC connection with the base station device 200 is established is called an RRC connected mode (RRC_CONNECTED). A state in which the RRC connection with the base station device 200 is temporarily suspended is called an RRC inactive mode (RRC_INACTIVE). Note that when the core network 300 is an EPC, the state in which the RRC connection with the base station device 200 is temporarily suspended may be called another name, such as RRC suspended, instead of being called an RRC inactive mode.

[0072] <RRC Message> The RRC message will be explained. The RRC message is a message that includes information necessary for communication in a cell, and includes a MIB (Master Information Block), a system information group (SIB), etc. The parameters included in the RRC message may be called fields or information elements (IEs).

[0073] The RRC message also includes a message related to the establishment of an RRC connection. Examples of messages related to the establishment of an RRC connection include, for example, in the case of NR, an RRC setup request message (RRCSetupRequest), an RRC setup message (RRCSetup), and an RRC setup complete message (RRCSetupComplete). Examples of messages related to the establishment of an RRC connection include, for example, in the case of E-UTRA, an RRC connection setup request message (RRCConnectionSetupRequest), an RRC connection setup message (RRCConnectionSetup), and an RRC connection setup complete message (RRCConnectionSetupComplete).

[0074] The RRC message also includes a message related to the initial activation of AS (Access Stratum) security. Examples of messages related to the initial activation of AS security include a security mode command message (SecurityModeCommand).

[0075] Furthermore, the RRC message includes a message related to the reconfiguration of the RRC connection. For example, in the case of NR, messages related to the reconfiguration of the RRC connection include an RRC reconfiguration message (RRCReconfiguration) and an RRC reconfiguration complete message (RRCReconfigurationComplete). For example, in the case of E-UTRA, messages related to the reconfiguration of the RRC connection include an RRC connection reconfiguration message (RRCConnectionReconfiguration) and an RRC connection reconfiguration complete message (RRCConnectionReconfigurationComplete). Note that messages related to the reconfiguration of the RRC connection perform the establishment, configuration, modification, and release of radio bearers, cell groups, etc., as well as synchronized reconfiguration, as described below, and also the establishment, configuration, modification, and release of measurement information, etc.

[0076] After initial activation of AS security, the terminal device 100 receives the first RRC reconfiguration message from the base station device 200, thereby obtaining all settings or all minimum required settings necessary for communication (data communication) with the base station device 200 in the cell to which the terminal device 100 is connected. These all settings or all minimum required settings necessary for communication (data communication) with the base station device 200 may be referred to as, for example, complete settings.

[0077] After initial activation of AS security for the terminal device 100, the base station device 200 can transmit a first RRC reconfiguration message and then another RRC reconfiguration message to cause the terminal device 100 to update the settings required for communication (data communication) with the base station device 200. In this case, the base station device 200 transmits an RRC reconfiguration message containing a differential setting from the complete setting currently set in the terminal device 100. This differential setting is sometimes called a delta setting. When the terminal device 100 receives an RRC reconfiguration message including the delta setting, it generates a new setting by applying the delta setting to the complete setting currently being used.

[0078] The RRC message also includes a message related to the re-establishment of the RRC connection. For example, in the case of NR, messages related to the re-establishment of the RRC connection include an RRC re-establishment request message (RRCReestablishRequest), an RRC re-establishment message (RRCReestablish), and an RRC re-establishment complete message (RRCReestablishComplete). For example, in the case of E-UTRA, messages related to the establishment of the RRC connection include an RRC connection re-establishment request message (RRCConnectionReestablishRequest), an RRC connection re-establishment message (RRCConnectionReestablish), and an RRC connection re-establishment complete message (RRCConnectionReestablishComplete).

[0079] In addition, the RRC messages further include messages regarding the release or suspension of the RRC connection, messages regarding the resumption of the RRC connection, messages regarding the capabilities of the terminal device, messages regarding terminal information, messages regarding MCG failure information, and messages regarding SCG failure information.

[0080] In addition, in MR-DC, when the master node is an eNB, the eNB may configure the terminal device 100 regarding NR by including the NR RRC message and parameters received from the gNB, which is the secondary node, as a container in the E-UTRA RRC message and transmitting it to the terminal device 100. The terminal device 100 may also include a completion message for the NR configuration as a container in the E-UTRA RRC message and transmit it to the eNB, which is the master node.

[0081] Also, in MR-DC, when the master node is a gNB, the gNB may configure the terminal device 100 for E-UTRA by including the E-UTRA RRC message and parameters received from the eNB, which is the secondary node, as a container in the NR RRC message and transmitting it to the terminal device 100. Also, the terminal device 100 may include a completion message for the E-UTRA configuration in the NR RRC message as a container and transmit it to the gNB, which is the master node.

[0082] 6 is a diagram showing an example of a message format of RRC Reconfiguration. Format E1 is a parameter of RRC Reconfiguration.

[0083] RRC Reconfiguration has radioBearerConfig, radioBearerConfig2, masterCellGroup, secondaryCellGroup, masterKeyUpdate, and sk-counter as parameters.

[0084] radioBearerConfig and radioBearerConfig2 are settings related to an MN-terminated bearer or an SN-terminated bearer, and include SRB settings, DRB settings, security settings, etc. The SRB settings (DRB settings) include an SRB identifier (DRB identifier), PDCP settings, a parameter instructing PDCP re-establishment, etc. The security settings include a parameter (keyToUse) indicating whether to use a master key or a secondary key.

[0085] The masterCellGroup and secondaryCellGroup are MCG settings and SCG settings, respectively, and include a cell group identifier, an RLC bearer setting, an SpCell setting, etc. The RLC bearer setting includes a logical channel identifier, an RLC setting, a radio bearer identifier (SRB identifier or DRB identifier) ​​associated with the RLC bearer, etc. The SpCell setting includes information necessary for synchronized reconfiguration, etc.

[0086] masterKeyUpdate contains the information necessary for a master key update.

[0087] The sk-counter contains the information necessary for secondary key generation.

[0088] Format E11 is a diagram showing an example of parameters of RadioBearerConfig included in RRCReconfiguration.

[0089] Format E12 is a diagram showing an example of parameters of CellGroupConfig included in RRCReconfiguration.

[0090] Format E13 is a diagram showing an example of parameters of MaskerKeyUpdate included in RRCReconfiguration.

[0091] Format E111 is a diagram showing an example of parameters of SRB-ToAddMod included in RadioBearerConfig.

[0092] Format E112 is a diagram showing an example of the parameters of DRB-ToAddMod included in RadioBearerConfig.

[0093] Format E113 is a diagram showing an example of SecurityConfig parameters included in RadioBearerConfig.

[0094] Format E121 is a diagram showing an example of parameters of RLC-BearerConfig included in CellGroupConfig.

[0095] Format E122 is a diagram showing an example of parameters of SpCellConfig included in CellGroupConfig.

[0096] <Radio Bearer> An example of a radio bearer in the communication system 10 will now be described.

[0097] <1. Signaling Radio Bearer> A signaling radio bearer (SRB) is a radio bearer for transmitting RRC messages and NAS messages.

[0098] SRB0 is the radio bearer for RRC messages that use the CCCH logical channel.

[0099] SRB1 is a radio bearer for RRC messages and NAS messages that uses the DCCH logical channel and is established before SRB2, which will be described later, is established.

[0100] SRB2 is a radio bearer for transmitting and receiving NAS messages, transmitting RRC messages including logged measurement information, etc., and uses the DCCH logical channel. The priority of SRB2 is lower than that of SRB1, and may be set by the base station apparatus 200 after AS security is activated.

[0101] SRB3 is a radio bearer for RRC messages when EN-DC, NGEN-DC, or NR-DC is set in the terminal device 100, and uses the DCCH logical channel. Note that EN-DC, NGEN-DC, and NR-DC are types of MR-DC, and details of the types of MR-DC will be described later.

[0102] <2. Data Radio Bearer> A data radio bearer (DRB) is a radio bearer for transmitting user data.

[0103] <SRB and DRB Protocol Configuration> The SRB and DRB protocol configuration of the terminal device 100 will be described.

[0104] SRB0 does not have a PDCP entity and is configured with an RLC bearer. The RLC bearer is configured with an RLC entity and a MAC logical channel. The mode of the RLC entity of SRB0 is TM.

[0105] Each of SRB1 and SRB2 consists of one PDCP entity and one or more RLC bearers, where the RLC entity is in AM mode.

[0106] SRB3 consists of one PDCP entity and one RLC bearer, and the mode of the RLC entity is AM.

[0107] A DRB consists of one PDCP entity and one or more RLC bearers. The mode of the RLC entity is UM or AM. A DRB may be called a UM DRB if the RLC entity is UM, or an AM DRB if the RLC entity is AM. Furthermore, a DRB is associated with one SDAP if the core network 300 is a 5GC, and is associated with one EPS bearer (or EPS bearer identity) if the core network 300 is an EPC.

[0108] It is assumed that one MAC entity exists for each cell group described below.

[0109] <Cells and Cell Groups> The cells and cell groups (CG) configured in the terminal device 100 will be described.

[0110] A cell group may be composed of one special cell (SpCell). Also, a cell group may be composed of one SpCell and one or more secondary cells (SCells). Note that an SpCell in a master cell group (MCG) (described later) may be called a primary cell (PCell). Also, an SpCell in a secondary cell group (SCG) (described later) may be called a primary SCG cell (PSCell).

[0111] The PCell is a primary frequency cell and is used to establish an RRC connection or re-establish an RRC connection. That is, when establishing an RRC connection or re-establishing an RRC connection, the cell selected by the terminal device 100 becomes the PCell. Furthermore, when the base station device 200 requests a handover (described later) from the terminal device 100, a new PCell designated by the base station device 200 is used for random access.

[0112] The SCell is a cell that provides additional radio resources in addition to the SpCell when carrier aggregation (CA) is configured in the terminal device 100.

[0113] The PSCell is a cell of the primary frequency on the SCG side. The PSCell is designated by the base station device 200 and is used for random access when adding or changing a PSCell in the SCG.

[0114] Note that the cell that the terminal device 100 in the RRC connected state uses for communication with the base station device 200 may be called the serving cell. When CA is not configured, the SpCell is the serving cell, and when CA is configured, the SpCell and SCell are the serving cells.

[0115] The MCG is a CG when DC (Dual Connectivity) is not set in the terminal device 100, or a CG that belongs to a master node (MN) when DC is set in the terminal device 100. DC is a technology in which the terminal device 100 is wirelessly connected to a base station device 200 that is a master node and a base station device 200 that is a secondary node (SN), and performs wireless communication using the carriers (cell groups) of the respective base station devices 200.

[0116] The SCG is a CG belonging to a secondary node that is set in addition to the MCG when a DC is set in the terminal device 100.

[0117] FIG. 7 is a diagram showing an example of the configuration of a cell group in the communication system 10. In FIG. 7, the master node (MN) is the base station device 200-1, and the secondary node (SN) is the base station device 200-2. The master node is, for example, in an MR-DC, the base station device 200 that provides a C-Plane connection to the core network 300. The secondary node is, for example, in an MR-DC, the base station device 200 that does not provide a C-Plane to the core network 300 but provides additional radio resources to the terminal device 100. In FIG. 7, the MCG is, for example, composed of one PCell and two SCells. Also, in FIG. 7, the SCG is, for example, composed of one PSCell and two SCells.

[0118] The base station device 200 may set a BWP (BandWidth Part) for the cell set for the terminal device 100, and adjust the cell so that a limited frequency band is used among the entire frequency band of the cell. The BWP may be configured from a portion of the frequency band of each cell. Furthermore, multiple BWPs (for example, up to four) may be set for each cell. The BWP may be set by an RRC reconfiguration message. In each cell, the BWP to be used may be specified or switched by an RRC reconfiguration message or by using DCI.

[0119] <Bearer types of MR-DC> Bearer types in MR-DC will be explained. Hereinafter, a configuration in which PDCP terminates at the master node and has PDCP on the master node side may be called MN-terminated. Also, a configuration in which PDCP terminates at the secondary node and has PDCP on the secondary node side may be called SN-terminated. Bearer types are classified into the following six types.

[0120] (1) An MCG bearer that is MN-terminated and has an RLC bearer on the MCG side.

[0121] (2) A split bearer that is MN-terminated and in which the RLC bearer exists in both the MCG and the SCG.

[0122] (3) An SCG bearer that is MN-terminated and has an RLC bearer on the SCG side.

[0123] (4) An MCG bearer that is SN-terminated and has an RLC bearer on the MCG side.

[0124] (5) A split bearer that is SN-terminated and in which the RLC bearer exists in both the MCG and the SCG.

[0125] (6) An SCG bearer that is SN-terminated and has an RLC bearer on the SCG side.

[0126] A DRB is configured with any of the six bearer types listed above.

[0127] SRB1 and SRB2 are configured as MN-terminated MCG bearers or MN-terminated split bearers. When SRB1 and SRB2 are configured as MN-terminated split bearers, they may be called split SBR1 and split SBR2, respectively.

[0128] SBR3 consists of an SN-Terminated SCG bearer.

[0129] Furthermore, in the case of a split bearer, a primary path is set. The primary path indicates the base station device 200 to which the terminal device 100 initially transmits data (priority). The primary path is specified by a cell group (MCG, SCG) and an LCH. The terminal device 100 transmits data to the base station device 200 on the primary path as long as the amount of uplink data transmission does not exceed a threshold. If the threshold is exceeded, the terminal device 100 may transmit data to either base station device 200.

[0130] Furthermore, the security keys used in PDCP differ between the MN-terminated case (master key) and the SN-terminated case (secondary key).

[0131] <Reconfiguration with Sync> Reconfiguration with Sync will now be described. Reconfiguration with Sync indicates a procedure executed in the terminal device 100 by including a parameter indicating that reconfiguration with Sync (reconfigurationWithSync: hereinafter, sometimes referred to as a reconfiguration parameter with sync) in an RRC reconfiguration message (RRCReconfiguration) that the base station device 200 transmits to the terminal device 100.

[0132] The synchronized reconfiguration parameters are included separately under parameters for MCG configuration (hereinafter, may be referred to as MCG configuration parameters) and under parameters for SCG configuration (hereinafter, may be referred to as SCG configuration parameters). In other words, when included under the MCG configuration parameters, it means synchronized reconfiguration of the MCG, and when included under the SCG configuration parameters, it means synchronized reconfiguration of the SCG.

[0133] The synchronized reconfiguration is a procedure in which the terminal device 100 changes the SpCell, and includes operations such as random access to the new (target, changed to) SpCell, MAC reset, and PDCP data recovery (in the case of AM DRB).

[0134] The process when the synchronized reconfiguration parameters are included under the MCG configuration parameters may be called handover. The process when the synchronized reconfiguration parameters are included under the SCG configuration parameters may be called PSCell addition and / or PSCell change. The source PCell / PSCell may be called source PCell / source PSCell, and the destination PCell / PSCell may be called target PCell / target PSCell. Since synchronized reconfiguration may involve CA, the term serving cell may be used, and the cells may be referred to as source serving cell and target serving cell. The term "serving" may also be omitted, and the cells may be referred to as source cell and target cell.

[0135] The terminal device 100 may generate the target cell configuration by applying the delta configuration included in the RRC reconfiguration message to the source cell configuration.

[0136] In addition, synchronized re-establishment may involve updating security keys. In this case, PDCP re-establishment is also performed in addition to the above.

[0137] When the security key is updated, a new key is generated by the RRC of the terminal device 100, and the PDCP is re-established, so that the new key is applied to the PDCP.

[0138] Fig. 8 is a diagram showing an example of processing when a synchronization-attached resetting parameter is included under a parameter for setting an MCG. Note that Fig. 8 is a diagram showing an example of synchronization-attached resetting.

[0139] The synchronized reconfiguration parameters include settings such as a target PCell setting, a new C-RNTI (Cell Radio Network Temporary Identifier), a RACH setting, and a timer for detecting handover failure. The terminal device 100 performs random access (RA) with the target PCell in accordance with the settings, and changes the current source PCell to the target PCell (S1). Note that RACH may refer to a random access procedure in addition to a random access channel.

[0140] <Handover Failure Processing> If the terminal device 100 receives an RRC reconfiguration message including a synchronization-enabled reconfiguration parameter and the handover is not successful within a certain time, the handover fails. The handover not being successful within the certain time may mean that the timer for detecting handover failure, which starts when the terminal device 100 receives an RRC reconfiguration message including a synchronization-enabled reconfiguration parameter, expires before the handover is successful.

[0141] If the handover fails, the terminal device 100 restores the settings to those used in the source PCell and performs an RRC connection re-establishment procedure. When restoring the settings of the terminal device 100 to those used in the source PCell, the values ​​of the state variables in each entity of each radio bearer are also restored to the values ​​used in the source (values ​​immediately before the handover process).

[0142] In the RRC connection re-establishment procedure, the terminal device 100 performs cell selection, and if an NR cell is selected, it transmits an RRC re-establishment request message (RRCReestablishmentRequest) to the base station device 200. The RRC re-establishment request message is transmitted through SRB0. Since no PDCP entity exists in SRB0, security processing by PDCP is not performed on the RRC re-establishment request message. Furthermore, when an RRC re-establishment message (RRCReestablishment), which is a response message to the RRC re-establishment request message, is received from the base station device 200, the security key of the terminal device 200 is updated.

[0143] <Conditional Handover> A conditional handover (CHO) is a handover that is executed (initiated) by the terminal device 100 when one or more handover execution conditions are satisfied. The terminal device 100 receives an RRC reconfiguration message including conditional reconfiguration parameters from the base station device 200 and stores the conditional reconfiguration parameters. The conditional reconfiguration parameters include one or more pairs of configuration parameters for a PCell changeover target candidate, including synchronization reconfiguration parameters, and execution condition parameters for executing a handover to the PCell changeover target candidate. The execution condition parameters include, for example, parameters related to measurement configuration. Upon receiving the conditional reconfiguration parameters, the terminal device 100 starts cell measurement. If any PCell of the measured cells satisfies the execution conditions, the terminal device 100 applies the configuration parameters of the PCell changeover target candidate for the PCell that satisfies the execution conditions and performs a conditional handover to this PCell. After the conditional handover is successful, the terminal device 100 releases the conditional reconfiguration parameters.

[0144] The conditional reconfiguration parameters can include one or more pairs of SCG-side configuration, i.e., configuration parameters of a PSCell change destination candidate and execution condition parameters for executing a change to the PSCell change destination candidate. Upon receiving the SCG-side conditional reconfiguration parameters, the terminal device 100 starts measuring the execution conditions, and if the measurement result satisfies the execution conditions, performs a conditional PSCell addition / change (Conditional PSCell Addition Change: CPAC).

[0145] In a conditional handover, a handover failure is detected in the same way as in a non-conditional handover (hereinafter, sometimes simply referred to as a handover), and processing after the handover failure is performed. In a conditional handover failure or in a procedure for re-establishing an RRC connection after a handover failure, or in a procedure for re-establishing an RRC connection after a radio link failure, if the selected cell is a PCell changeover candidate, the terminal device 100 can transmit an RRC reconfiguration complete message to the base station device 200 instead of transmitting an RRC re-establishment request message to attempt handover and recover the RRC connection. Note that, when the cell selected by the terminal device 100 is a PCell changeover candidate, the terminal device 100 can transmit an RRC reconfiguration complete message to the base station device 200 instead of transmitting an RRC re-establishment request message only if a conditional reconfiguration attempt parameter (attemptCondReconfig), which is a parameter that permits this processing, is set in the terminal device 100.

[0146] Note that conditional handover and non-conditional handover may be referred to as handover without distinction.

[0147] <Intra-CU LTM Cell Switching> An example of an outline of cell switching in L1 / L2 Triggered Mobility (LTM) specified in Rel-18 will be described.

[0148] Fig. 9 is a diagram showing an example of parameters related to LTM included in an RRC Reconfiguration message (RRC reconfiguration message). Note that the parameters described in Fig. 6 are omitted in Fig. 9. Furthermore, parameters other than the example parameters shown in Fig. 9 may be included in the RRC reconfiguration message. Furthermore, the names of the parameters are merely examples and do not have to be as shown.

[0149] Format E2 is a parameter of RRC Reconfiguration. RRC Reconfiguration includes ltm-Config, which means LTM configuration. If LTM-Config is included in SetupRelease, LTM configuration is newly configured or changed. If SetupRelease does not include any ltm-Config, it means release of LTM configuration.

[0150] Format E21 is a parameter included in the LTM configuration. ltm-ReferenceConfiguration is a reference configuration described later. ltm-CandidateToAddModList is a list of LTM candidate cell configurations. In other words, ltm-CandidateToAddModList is a list of LTM candidate cell configurations and includes one or more LTM candidate cell configurations. ltm-ServingCellNoResetID is an identifier used by the terminal device 100 when determining whether or not an L2 reset (Layer 2 reset) is required at the time of cell switching described later. The ltm-ServingCellNoResetID or the initial value of ltm-ServingCellNoResetID may be a group identifier of the serving cell used when the base station device 200 transmits an RRC reconfiguration message including an LTM configuration to the terminal device 100 in step S1001, which will be described later. ltm-ServingCellNoResetID is stored in the terminal device 100 as a value indicating the group identifier of the current serving cell. Note that attemptLTM-Switch may be included in format E21. attemptLTM-Switch is a parameter that has the same meaning as the conditional reconfiguration attempt parameter (attemptCondReconfig) in conditional handover, and is a parameter that permits recovery of the RRC connection after a cell switching failure, a handover failure, or a radio link failure.

[0151] Format E211 is a parameter included in the LTM candidate cell configuration list. LTM-Candidate is an LTM candidate cell configuration. ltm-CandidateId included in the LTM candidate cell configuration is an identifier or index that uniquely identifies one or more configured LTM candidate cell configurations within the terminal device 100. ltm-CandidateConfig is a parameter for generating a configuration to be used at the cell switching destination (target), and includes a part of the RRCReconfiguration parameters described in FIG. 6. ltm-CandidateConfig may be a complete configuration, as described below, or may be a delta configuration. ltm-CandidateConfig may be configured with parameters included in the RRC reconfiguration message. The ltm-NoResetID is an identifier used by the terminal device 100 when determining whether or not an L2 reset (Layer 2 reset) is required during cell switching, which will be described later. The ltm-NoResetID may be a group identifier of LTM candidate cells. A different value may be assigned to the ltm-NoResetID for each DU (Distributed Unit). For example, '1' may be set for all LTM candidate cells under DU1, and '2' may be set for all LTM candidate cells under DU2.

[0152] FIG. 10 is a diagram showing an example of an intra-CU LTM sequence.

[0153] The base station device 200 includes one or more cell change destination candidate settings (target cell candidate settings) in an RRC reconfiguration message and transmits the message to the terminal device 100 (S1001).

[0154] Upon receiving an RRC reconfiguration message (S1001), the terminal device 100 stores the LTM configuration information (including the configuration of candidate cell change destinations) included in the received message. The terminal device 100 may also store the value of ltm-ServingCellNoResetID included in the LTM configuration in a variable indicating the group identifier of the current serving cell.

[0155] Note that the cell change destination candidate may be, for example, only the PCell or may include the SCell. The configuration of each cell change destination candidate may be uniquely identified within the terminal device 100 using an index (ltm-CandidateId). Furthermore, the configuration of the cell change destination candidate may not include a parameter indicating an update of the security key. In other words, the security key by LTM may not be updated. Furthermore, the configuration of the cell change destination candidate may include parameters similar to the synchronized reconfiguration parameters.

[0156] The terminal device 100 may retain the configuration of the cell change destination candidate received and stored in step S1001 without releasing it after the cell change is successful, as described below. In this case, the retained configuration of the cell change destination candidate may be used for a subsequent cell switch. However, when the configuration of the cell change destination candidate is retained and used for a subsequent cell switch, it may not be possible to set the configuration of the cell change destination candidate to a delta configuration and apply the delta configuration to the source configuration to generate a target cell configuration. This phenomenon occurs because the source configuration differs depending on the order of cells changed by cell change.

[0157] For this reason, in step S1001, the RRC reconfiguration message may include a reference configuration in addition to the configuration of the cell change destination candidate, or as part of the configuration of the cell change destination candidate. The reference configuration is used, for example, to complete the configuration to be used at the cell change destination (target). When the RRC reconfiguration message includes a reference configuration, the configuration of each cell change destination candidate included in the RRC reconfiguration message may be a differential configuration (delta configuration) from the reference configuration. In other words, the terminal device 100 can generate the configuration to be used at the cell change destination (target), i.e., the complete configuration to be used at the cell change destination, from the reference configuration and the configuration of the cell change destination candidate (delta configuration). For example, when the terminal device 100 receives a cell change signal to cell X, which is a cell change destination candidate, from the base station device 200 in step S1002 described below, the terminal device 100 generates the configuration to be used in cell X by applying the configuration of cell X to the reference configuration.

[0158] Also, in step S1001, the RRC reconfiguration message may not include a reference configuration. When the RRC reconfiguration message does not include a reference configuration, the configuration of each cell change destination candidate included in the RRC reconfiguration message is, for example, a complete configuration. That is, the terminal device 100 can generate the configuration to be used at the cell change destination (target) by replacing the configuration used in the current cell with the configuration of the cell change destination candidate. For example, in step S1002 described below, when the terminal device 100 receives a cell change signal to cell X, which is a cell change destination candidate, from the base station device 200, the terminal device 100 generates the configuration to be used in cell X by replacing the configuration of the current cell with the configuration of cell X. However, when the configuration of the cell change destination candidate is set to a complete configuration, some of the configurations may not be included. The partial configuration includes, for example, configurations that do not change due to cell change (fixed configurations). The configurations that do not change due to cell change (fixed configurations) include, for example, some or all of the radio bearer configurations. In this case, when the terminal device 100 receives a cell switching signal from the base station device 200 to cell X, which is a candidate cell change destination, it generates settings to be used in cell X by replacing the current cell settings with the settings of cell X, except for fixed settings.

[0159] Note that, regardless of whether or not the RRC reconfiguration message includes a reference configuration, when generating a configuration to be used at the cell switching destination, the terminal device 100 does not need to reset some or all of the values ​​of state variables, timers, etc. used in each entity (SDAP entity, PDCP entity, RLC entity, MAC entity, etc.) to their initial states. Furthermore, the terminal device 100 does not need to discard some or all of the buffers in each entity. In other words, the terminal device 100 can retain some or all of the values ​​of state variables, timers, etc. used in each entity. Furthermore, the terminal device 100 may retain some or all of the buffers in each entity.

[0160] The base station device 200 transmits to the terminal device 100 a cell switching signal for switching the serving cell of the terminal device 100 from the current serving cell to one of the cell switching destination candidates (S1002).

[0161] The terminal device 100 receives a cell switching signal in the current serving cell (S1002). The cell switching signal may be, for example, a MAC CE. Alternatively, the cell switching signal may be a physical layer signal such as DCI.

[0162] The cell switching signal includes at least an index (ltm-CandidateId). The terminal device 100 applies the setting of the cell change destination (cell X) specified by the received cell switching signal. Note that cell X may be configured only with a PCell, may be configured only with a PSCell, or may be configured with a PCell or a PSCell and one or more SCells.

[0163] The terminal device 100 performs four-step or two-step contention-free random access (CFRA) or contention-based random access (CBRA) between the base station device 200 in cell X in accordance with the settings of cell X (S1003). Also, for example, if the settings of cell X include a parameter indicating that RACH-less cell switching is to be performed, or if early TA acquisition, which will be described later, has been performed, the random access process in step S1003 is not executed. Also, if the ltm-NoResetID of cell X is the same as the ltm-ServingCellNoResetID or a variable indicating the group identifier of the current serving cell, the terminal device 100 does not perform L2 reset. Furthermore, if the ltm-NoResetID of cell X is not the same as the ltm-ServingCellNoResetID or the variable indicating the group identifier of the current serving cell, the terminal device 100 performs an L2 reset and overwrites the ltm-ServingCellNoResetID or the variable indicating the group identifier of the current serving cell with the ltm-NoResetID of cell X. The L2 reset is, for example, an RLC re-establishment. The L2 reset is, for example, a PDCP data recovery.

[0164] The terminal device 100 transmits a notification indicating that the cell has been switched to the base station device 200 in cell X (S1004). This notification corresponds to an RRC reconfiguration complete message in handover or conditional handover. The notification indicating that the cell has been switched may use an RRC message such as an RRC reconfiguration complete message, or may use a MAC CE. Furthermore, the notification indicating that the cell has been switched may use a physical signal such as UCI.

[0165] Furthermore, the notification indicating that the cell has been switched may include at least an identifier of cell X of the terminal device 100. Note that, if two-step CFRA or CFRA has been performed in step S1003, the notification indicating that the cell has been switched is transmitted before receiving the random access response in step S1003. Furthermore, uplink data generated in the DRB may be transmitted together with the notification indicating that the cell has been switched.

[0166] If a four-step or two-step CBRA is performed in step S1003, or if a RACH-less cell switch is performed, the base station device 200 transmits to the terminal device 100 a signal including a contention resolution signal or information indicating that the notification transmitted from the terminal device 100 in step S1004 has been successfully received (hereinafter, this may be referred to as reception success information).

[0167] Furthermore, the terminal device 100 receives, for example, a contention resolution signal or a signal including reception success information in cell X. The contention resolution signal or the reception success information may include at least an identifier of the terminal device 100 in cell X.

[0168] The timing of successful cell switching may be the same as that of successful handover in handover or conditional handover. That is, in the case of cell switching using four-step or two-step CFRA, the cell switching is successful when a random access response is received. Also, in the case of cell switching using four-step or two-step CBRA, or RACH-less cell switching, the cell switching is successful when the processing of step S1003 or step S1004 is performed. If the timing of successful cell switching is the same as that of successful handover in handover or conditional handover, as in handover or conditional handover, in cell switching using four-step CFRA, no notification indicating the cell switching or uplink data generated in the DRB is transmitted before the cell switching is successful. However, in the case of cell switching using four-step CBRA, cell switching using two-step CFRA or CBRA, and RACH-less cell switching, a notification indicating the cell switching is transmitted before the cell switching is successful. Furthermore, uplink data generated by the DRB may be transmitted together with a notification indicating that the cell has been switched.

[0169] After executing step S1001, the terminal device 100 may perform downlink synchronization and / or uplink synchronization with one or more cell change destination candidates before transmitting the cell change destination signal in step S1002. In uplink synchronization, the base station device 200 may measure a timing advance (TA) of the terminal device 100 for one or more cell change destination candidates. Uplink synchronization may be performed by the base station device 200 instructing the terminal device 100 to transmit a random access preamble. The base station device 200 may instruct the terminal device 100 to transmit different random access preambles to one or more cell change destination candidates, or may instruct the terminal device 100 to transmit a common random access preamble to a group of multiple cell change destination candidates. The TA measured by the base station device 200 may be transmitted to the terminal device 100 using a random access response (RAR), or may be transmitted to the terminal device 100 using the cell change destination signal in step S1002. In this way, performing uplink synchronization after the terminal device 100 executes step S1001 and before the cell switching signal is sent in step S1002 may be called early TA measurement or early TA acquisition.

[0170] Note that the cell switching may be referred to as LTM or LTM cell switching. Furthermore, the cell switching may be referred to as another term that represents cell switching by LTM. Hereinafter, the cell switching and the cell change may be treated as terms that mean the same thing.

[0171] In addition, in this embodiment, unless there is a particular distinction between cell switching of an MCG and cell switching of an SCG, cell switching is considered to be cell switching of an MCG.

[0172] In addition, in the setting of the cell change destination candidate of the MCG in the LTM setting, a synchronization reset parameter may be included under the MCG setting parameter. Similarly, in the setting of the cell change destination candidate of the SCG in the LTM setting, a synchronization reset parameter may be included under the SCG setting parameter. Therefore, the cell switching of the MCG may be referred to as a handover. Furthermore, the cell switching of the SCG may be referred to as a PSCell change.

[0173] <LTM Cell Switching Failure Processing> When the LTM cell switching fails, an RRC connection re-establishment procedure may be executed, similar to the handover failure processing and the conditional handover failure processing.

[0174] Fig. 11 is a diagram showing an example of a sequence of detecting a cell switching failure and processing the cell switching failure. The processing of steps S1001 and S1002 in Fig. 11 is the same as the processing of steps S1001 and S1002 in Fig. 10, and therefore a description thereof will be omitted.

[0175] When the terminal device 100 receives a cell switching signal (S1002), it starts a timer to detect cell switching failure (S1101) and starts cell switching processing to the cell (cell X) specified by the received cell switching signal (not shown).

[0176] If the cell switch is successful before the timer expires, the terminal device 100 stops the timer (not shown). On the other hand, if the timer expires, the terminal device 100 detects that the cell switch to cell X has failed (S1102).

[0177] When the terminal device 100 detects a cell switching failure (S1102), the terminal device 100 performs a cell switching failure process (S1103). In the cell switching failure process, the terminal device 100 may return the settings of the terminal device 100 to the settings used in the source PCell and perform an RRC connection re-establishment procedure.

[0178] Cell selection is performed in the RRC connection re-establishment procedure. If the cell selected in cell selection is one of the LTM candidate cells, the terminal device 100 can autonomously perform LTM cell switching to the selected cell. This is called fast LTM recovery or fast recovery. When performing fast LTM recovery, cell switching is initiated in the terminal device 100. Note that the terminal device 100 performs fast LTM recovery only when the LTM configuration includes a parameter indicating that fast LTM recovery is to be performed. Note that fast recovery is not limited to LTM. Fast recovery is also performed in, for example, CHO. In other words, fast recovery means that if the selected cell in the cell selection in the RRC connection re-establishment procedure after cell switching or handover failure is one of the candidate cells configured in the terminal device 100, the terminal device 100 autonomously performs cell switching or handover to this cell.

[0179] <Updating AS Security Keys During Handover> AS security processing is performed in the PDCP entities of radio bearers other than SRB0 using encryption keys and integrity protection keys generated by RRC. AS security processing includes ciphering and integrity protection, which are performed using encryption keys and integrity protection keys, respectively. Furthermore, encryption keys and integrity protection keys are generated for SRBs and DRBs, respectively. The encryption key for SRB is called KRRCenc, the integrity protection key for SRB is called KRRCint, the encryption key for DRB is called KUPenc, and the integrity protection key for DRB is called KUPint. The encryption keys and integrity protection keys used for SRBs other than SRB0 and the DRB are generated from a security key called KgNB. A common KgNB is generated by the base station device 200 and the terminal device 100. Hereinafter, unless otherwise specified, KgNB will be referred to as the security key.

[0180] In the case of handover within a base station device or within a control unit (CU), security key update is optional. That is, the base station device 200 may or may not instruct the terminal device 100 to update the security key. However, in the case of handover between base station devices or between control units (CU), security key update is mandatory. That is, the base station device 200 instructs the terminal device 100 to update the security key.

[0181] A method for updating a security key will now be described. When a security key update is necessary, the base station device 200 transmits to the terminal device 100 an RRC reconfiguration message including a MasterKeyUpdate parameter (master key update parameter) shown in format E13 of FIG. 6 . The master key update parameter includes a keySetChangeIndicator (key set change instruction) or a nextHopChainingCount (NCC). The key set change instruction is information indicating true or false, and the NCC is a non-negative integer. The initial value of the NCC is zero ('0'), and the terminal device 100 stores NCC=0 in the initial state.

[0182] If the key set change instruction of the master key update parameter is set to "true", the terminal device 100 generates a new KgNB from the NAS security key (called KAMF) of the terminal device 100.

[0183] Furthermore, if the key set change instruction of the master key update parameter is not set to "true," i.e., if it is set to "false," the terminal device 100 generates a new key according to the NCC value of the master key update parameter. In this case, the terminal device 100 generates a new key using the original key information and target cell information. If the NCC value of the master key update parameter is the same as the NCC value stored in the terminal device 100 or the NCC value previously received from the base station device 200, a security key is generated using the currently used KgNB as the original key information. This is called horizontal derivation. Furthermore, if the NCC value of the master key update parameter is different from the NCC value stored in the terminal device 100 or the NCC value previously received from the base station device 200, a new security key is generated using the NH (Next Hop) corresponding to the received NCC value as the original key information. This is called vertical derivation. The target cell information used when generating a new security key is, for example, a physical cell identity (PCI) or an absolute radio frequency channel number (ARFCN).

[0184] On the other hand, when the base station device 200 transmits an RRC reconfiguration message including a master key update parameter to the terminal device 100, if the base station device 200 is instructed by the AMF, which is a node in the core network, to use a new KgNB generated by the AMF, the base station device 200 sets the key set change instruction to "true." Furthermore, if the base station device 200 is not instructed by the AMF to use a new KgNB generated by the AMF, the base station device 200 sets the key set change instruction to "false." Furthermore, the base station device 200 determines the NCC value based on whether a new NCC and NH pair issued by the AMF has been used for the terminal device 100. If a new NCC and NH pair has not been used, the base station device 200 sets this new NCC value as the NCC. If a new NCC and NH pair has already been used, the base station device 200 sets the same NCC value as the previous NCC value as the NCC. The NCC value is incremented by 1 each time a new NCC and NH pair is issued by the AMF. Furthermore, when the terminal device 100 performs a handover from a certain base station device 200 (say, base station device 200-A) to a different base station device 200 (say, base station device 200-B), and the base station device 200-B sends a path switch request to the AMF for this terminal device 100, the AMF issues a new NCC and NH pair for this terminal device 100 and sends it to the base station device 200-B.

[0185] <SN-side security key in MR-DC> When a DC is configured in the terminal device 100, it is necessary to generate an SN-side security key. The SN-side security key will be described using FIG. 6. S-KgNB, which is the SN-side security key, is generated from KgNB, which is the MN-side security key. Specifically, S-KgNB is generated from KgNB and a parameter called sk-counter (shown in E1 in FIG. 6). sk-counter is a non-negative integer. In addition, the SN-side SRB encryption key, SRB integrity protection key, DRB encryption key, and DRB integrity protection key are generated from S-KgNB.

[0186] Hereinafter, the security key on the MN side may be referred to as the master key, and the security key on the SN side may be referred to as the secondary key. The master key is applied to MN-terminated radio bearers, and the secondary key is applied to SN-terminated radio bearers. The base station device 200 uses a parameter called keyToUse (shown in E113 in FIG. 6 ) to indicate whether the PDCP entity of the DRB set in the terminal device 100 exists on the MN or SN. For a DRB with the keyToUse parameter set to master, the terminal device 100 can determine that the PDCP entity on the base station device 200 exists on the MN side. Furthermore, for a DRB with the keyToUse parameter set to secondary, the terminal device 100 can determine that the PDCP entity on the base station device 200 exists on the SN side.

[0187] [Embodiments] Each embodiment will be described below.

[0188] <Subsequent cell switching within and between CUs> The LTM specification defined in Rel-18 targets cell switching within a CU and does not support security key updating. However, security key updating is required for cell switching between CUs, which is within the scope of Rel-19.

[0189] In CHO, if the target PCell belongs to a different CU, the configuration parameters of the PCell changeover candidate must include a parameter indicating a security key update, i.e., a master key update parameter (masterKeyUpdate parameter). Therefore, even in the case of inter-CU CHO, the security key is updated according to the master key update parameter. Furthermore, in CHO, after CHO is performed, the terminal device 100 releases the CHO configuration, and the base station device 200 performs new CHO configuration on the terminal device 100. Therefore, even after inter-CU CHO is performed, CHO that supports both intra-CU and inter-CU can be performed by newly configuring a PCell changeover candidate using an RRC reconfiguration message. However, when performing subsequent cell switching, the LTM candidate cell configuration is not updated using an RRC reconfiguration message, so a method for appropriately updating the security key in the terminal device 100 is required.

[0190] Furthermore, when an MR-DC (hereinafter referred to as DC) is set in the terminal device 100, if the security key on the MN side is updated, it is essential to update the security key on the SN side. That is, when DC is set in the terminal device 100 and cell switching is performed between CUs in the MN, it is necessary to devise a method for causing the terminal device 100 to appropriately update the security key on the MN side and the security key on the SN side.

[0191] Hereinafter, when the term "security key" is simply mentioned without specifying whether it is the MN side or the SN side, it refers to the security key on the MN side.

[0192] <Subsequent cell switching method 1 for intra-CU and inter-CU> A first example of a subsequent cell switching method for intra-CU and inter-CU is to not support subsequent cell switching after inter-CU cell switching.

[0193] When the base station device 200 performs LTM configuration on the terminal device 100, for example, the base station device 200 does not include a master key update parameter in the configuration of an LTM candidate cell that belongs to the same CU as the CU to which the current serving cell of the terminal device 100 belongs, but includes a master key update parameter in the configuration of an LTM candidate cell that belongs to a CU different from the CU to which the current serving cell of the terminal device 100 belongs.

[0194] When performing cell switching, if the target LTM candidate cell configuration includes a master key update parameter, the terminal device 100 deletes, for example, some or all of the parameters related to the LTM configuration after the cell switching is successful. The parameters to be deleted include, for example, at least a list of LTM candidate cell configurations. The parameters to be deleted also include, for example, SN-related configurations. The SN-related configurations include, for example, SRB3 configurations, SN-terminated DRB configurations, and some or all of the SCG configurations. The terminal device 100 may also change the SCG bearer and / or split bearer to an MCG bearer. After the inter-CU LTM cell switching, the base station device 200 performs, for example, new LTM configuration or updates the LTM configuration for the terminal device 100. This allows the terminal device 100 to perform cell switching corresponding to both intra-CU and inter-CU again.

[0195] After the cell switch is successful, the terminal device 100 does not release, for example, some or all of the parameters related to the LTM setting. In this case, for example, the base station device 200 updates the LTM setting and / or the setting related to the SN for the terminal device 100, so that the terminal device 100 can perform cell switch corresponding to the intra-CU and inter-CU again.

[0196] <Subsequent Cell Switching Method 2 Corresponding to Intra-CU and Inter-CU> A second example of a subsequent cell switching method corresponding to intra-CU and inter-CU will be described using FIG. 12. FIG. 12 is a diagram showing an example of a subsequent cell switching method corresponding to intra-CU and inter-CU. Note that this method described using FIG. 12 may be performed in addition to some or all of the processing of the intra-CU LTM cell switching processing described using FIG. 10. Note that this example described using FIG. 12 is a description of the case where the CU is an MN, but the same procedure may also be applied when the CU is an SN. Furthermore, when DC is set in the terminal device 100, the base station device corresponding to the SN is not shown in FIG. 12. Note that the processing from step S1203 onwards may also be applied when the terminal device 100 performs fast LTM recovery.

[0197] The base station device 200 includes parameters related to LTM in an RRC reconfiguration message and transmits the message to the terminal device 100 (S1201). The parameters related to LTM include, for example, an LTM configuration including one or more LTM candidate cell configurations (target candidate cell configurations). When receiving the RRC reconfiguration message, the terminal device 100 stores the LTM configuration included in the received message. When storing the LTM configuration, some or all of the parameters included in the LTM configuration may be stored as variables of the terminal device 100. Hereinafter, when describing parameters, the term may refer not to parameters included in the RRC reconfiguration message but to parameters stored as variables of the terminal device 100. Furthermore, the base station device 200 sets, for example, different reference configuration parameters (ltm-ReferenceConfiguration) for each CU. When setting different reference configuration parameters for each CU, for example, a parameter indicating which CU the reference configuration parameter relates to is set. The parameter indicating which CU the reference configuration parameter relates to is, for example, a security update unnecessary identifier parameter described below. The message transmitted in step S1201 is an example of a first signal, and at least some of the parameters related to LTM are an example of a first setting for the first candidate cell.

[0198] Here, the parameters related to LTM included in the RRC reconfiguration message may include parameters other than the parameters described using FIG.

[0199] The LTM-related parameters included in the RRC reconfiguration message other than the parameters described using FIG. 9 are, for example, parameters that allow the terminal device 100 to determine whether or not a security key update is required when the terminal device 100 performs cell switching. The parameter that allows the terminal device 100 to determine whether or not a security key update is required may be, for example, a group identifier set in each LTM candidate cell. Here, for example, the group identifier set in each LTM candidate cell, which is used as a parameter that allows the terminal device 100 to determine whether or not a security key update is required, is referred to as a security update no longer required identifier parameter. The security update no longer required identifier parameter may be an identifier included in each LTM candidate cell configuration, separate from the ltm-NoResetID included in the LTM candidate cell configuration (LTM-Candidate) in format E211 of FIG. 9. A different value may be assigned to the security update no longer required identifier parameter for each CU. For example, a security update no longer required identifier parameter '1' may be set for all LTM candidate cells under CU1, and a security update no longer required identifier parameter '2' may be set for all LTM candidate cells under CU2. When performing cell switching, the terminal device 100 determines that a security key update is not required if the value of the security update no longer required identifier parameter included in the target LTM candidate cell configuration is the same as the value of the security update no longer required identifier parameter of the current serving cell or the value stored in the terminal device 100 as the security update no longer required identifier parameter of the current serving cell. If they are different, the terminal device 100 determines that a security key update is required. Furthermore, the initial value of the security update no longer required identifier parameter of the current serving cell may be set separately from the security update no longer required identifier parameter. The initial value of the security update no longer required identifier parameter of the current serving cell may be an identifier included under the LTM configuration, separate from ltm-ServingCellNoResetID, which is included in the LTM configuration (LTM-Config) of format E21 in FIG. 9 . Note that the security update no longer required parameter may have a different name, such as a security cell set identifier.

[0200] Another setting method of a parameter that enables the terminal device 100 to determine whether or not a security key update is required when the terminal device 100 performs cell switching (a method that does not use the above-mentioned security update unnecessary identifier parameter) is to further group the ltm-NoResetIDs included in the LTM candidate cell setting in format E211 of Fig. 9 as a security update unnecessary group, for example. For example, suppose that an LTM candidate cell to which ltm-NoResetID = '1' is set and an LTM candidate cell to which ltm-NoResetID = '2' is set are both cells under CU1, and an LTM candidate cell to which ltm-NoResetID = '3' is set and an LTM candidate cell to which ltm-NoResetID = '4' is set are both cells under CU2. In this case, for example, ltm-NoResetIDs '1' and '2' are set to security update-free group 1, and ltm-NoResetIDs '3' and '4' are set to security update-free group 2. The security update-free group may be included, for example, in a security update-free group parameter. The security update-free group parameter may include a security update-free group consisting of an identifier of the security update-free group and a list of ltm-NoResetIDs. The security update-free group parameter may be included, for example, under LTM configuration (LTM-Config). When performing cell switching, the terminal device 100 determines that a security key update is not required if the value of the security update-not required group identifier of the security update-not required group to which the ltm-NoResetID included in the target LTM candidate cell configuration belongs is the same as the group identifier of the current serving cell (ltm-ServingCellNoResetID) or the value of the security update-not required group identifier of the security update-not required group to which the identifier stored in the terminal device 100 as the group identifier of the current serving cell belongs, and determines that a security key update is required if they are different. Note that, for example, instead of using ltm-NoResetID, ltm-CandidateId may be used to classify security update-not required groups.

[0201] Note that a method for setting a parameter that enables the terminal device 100 to determine whether or not a security key needs to be updated when the terminal device 100 switches cells may be other than the above. Also, the names of the security update no longer required identifier parameter and the security update no longer required group parameter described above may be called by other names.

[0202] Furthermore, the parameter related to LTM other than the parameter described with reference to Fig. 9 and included in the RRC reconfiguration message is, for example, a parameter indicating a key generation method when updating a security key. The parameter indicating the key generation method may be, for example, a parameter specifying either "horizontal generation" or "vertical generation." Furthermore, for example, if a parameter indicating a key generation method when updating a security key is not included, this may mean that vertical generation is performed.

[0203] Furthermore, parameters related to LTM included in the RRC reconfiguration message other than the parameters described with reference to FIG. 9 are, for example, a list of NCCs used to generate security keys. When performing vertical generation of a security key, the terminal device 100 generates a new security key using, for example, the NH corresponding to the value of the NCC at the top of the configured NCC list as the original key information. For example, when the generation of a new security key is completed, the terminal device 100 may delete the NCC corresponding to the NH used as the original key information from the NCC list. Note that deleting from the NCC list means, for example, deleting from the NCC list stored as a variable in the terminal device 100. A parameter indicating a key generation method when updating a security key is included, for example, directly below the LTM configuration (in format E21 in FIG. 9 ).

[0204] Furthermore, the parameters related to LTM other than the parameters described with reference to Fig. 9 and included in the RRC reconfiguration message are parameters indicating that security keys on the MN side and / or SN side are updated in accordance with, for example, information included in a cell switching signal or information included in other signals. The parameters indicating that security keys on the MN side and / or SN side are updated in accordance with, for example, information included in a cell switching signal or information included in other signals are included immediately below the LTM configuration (in format E21 in Fig. 9).

[0205] Furthermore, the parameters related to LTM other than the parameters described using FIG. 9 and included in the RRC reconfiguration message are parameters required for a secondary key generation method, for example, when updating a secondary key. The parameter required for the secondary key generation method is, for example, an sk-counter. The sk-counter is set, for example, as a list of sk-counters. When updating a secondary key, the terminal device 100 generates a new secondary key, for example, using the sk-counter at the top of the set sk-counter list. For example, when the generation of a new secondary key is completed, the terminal device 100 may delete the used sk-counter from the sk-counter list. Note that deleting from the sk-counter list means deleting from the sk-counter list stored as a variable of the terminal device 100, for example. The list of sk-counters is included, for example, immediately below the LTM setting (in format E21 in FIG. 9). Note that a different index or identifier may be assigned to each sk-counter included in the list of sk-counters.

[0206] Furthermore, the sk-counter is set, for example, under the LTM candidate cell configuration (LTM-Candidate in format E211 in FIG. 9 ). When updating the secondary key, the terminal device 100 generates a new secondary key using the sk-counter included in the target LTM candidate cell configuration. Note that the sk-counter included in the LTM candidate cell configuration may be a list of sk-counters.

[0207] Note that some or all of the parameters related to LTM other than the parameters described with reference to FIG. 9 that are included in the RRC reconfiguration message described above may not be included as parameters related to LTM.

[0208] When receiving the RRC reconfiguration message, the terminal device 100 stores parameters related to LTM included in the received message. If the LTM configuration includes an initial value of the security update no longer required identifier parameter of the current serving cell, the terminal device 100 may store this value as a value indicating the security update no longer required identifier parameter of the current serving cell.

[0209] The base station device 200 transmits to the terminal device 100 a cell switching signal for switching the serving cell of the terminal device 100 from the current serving cell to one of the LTM candidate cells, thereby initiating cell switching for the terminal device 100 (S1202). Note that the cell switching signal transmitted in step S1202 is an example of a first cell switching command. Furthermore, by transmitting the signal in step S1202, the base station device 200 can cause the terminal device 100 to execute processing related to cell switching (e.g., at least a part of steps S1203 to S1206).

[0210] The terminal device 100, which has received the cell switching signal and initiated cell switching, determines whether a security key update is required for cell switching to the target cell (S1203). The determination of whether a security key update is required may be made using, for example, the above-described parameter that allows the terminal device 100 to determine whether a security key update is required. The determination of whether a security key update is required may also be made based on information included in the cell switching signal or information included in another signal transmitted from the base station device 200 simultaneously with the cell switching signal. The determination of whether a security key update is required may also be rephrased as a determination of whether the cell switching is inter-CU LTM cell switching or intra-CU LTM cell switching. That is, the determination that a security key update is required may be the same as the determination that the cell switching is inter-CU LTM cell switching. The determination that a security key update is not required may be the same as the determination that the cell switching is intra-CU LTM cell switching. The determination made in step S1203 is an example of a first determination. In step S1203, the terminal device 100 may determine whether the target cell belongs to the base station device 200 to which the pre-switching cell belongs, and determine whether a security key needs to be updated. Also, in step S1203, the terminal device 100 may determine whether the target cell belongs to a base station device 200 different from the base station device 200 to which the pre-switching cell belongs, and determine whether a security key needs to be updated. For example, the terminal device 200 determines that a security key needs to be updated when the target cell belongs to a base station device 200 (e.g., a second base station device) different from the base station device 200 (e.g., a first base station device) to which the pre-switching cell belongs.

[0211] If it is determined in step S1203 that a security key update is not necessary, the terminal device 100 performs the processing of step S1205, described below, without performing the security key update. Furthermore, if DC is configured in the terminal device 100 and it is determined in step S1203 that a security key update is not necessary, the terminal device 100 performs the processing of step S1205, described below, without performing the processing related to SN configuration. If it is determined in step S1203 that a security key update is necessary, the terminal device 100 updates the security key and applies the updated key. Furthermore, if DC is configured in the terminal device 100 and it is determined in step S1203 that a security key update is necessary, the terminal device 100 performs the processing related to SN configuration (S1204). Note that the security key update is an example of a processing related to MN configuration. Furthermore, the security key update is an example of a first processing related to master base station device or master cell configuration. The processing related to SN configuration is an example of a second processing related to secondary base station device configuration or a second processing related to secondary cell configuration. The process related to setting the SN may be described as a process of updating the security key of the secondary base station device or the secondary cell.

[0212] The security key update method is, for example, a method of updating using the method described in step S1201, using a parameter indicating the key generation method included in the signal transmitted in step S1201. Note that, for example, when an NCC list is not set in the terminal device 100 and vertical generation is performed, the terminal device 100 adds 1 to the value of the NCC it holds or the NCC used in the previous security key update, and performs security key update using the NH corresponding to this value as the original key information. Note that vertical generation is an example of a first generation method. Also, in the first generation method, a security key is generated using a first key corresponding to a first value (e.g., a value corresponding to the NCC). Also, in the case of horizontal generation, the terminal device 100 generates a security key using the currently used KgNB as the original key information. Note that horizontal generation is an example of a second generation method. Also, in the second generation method, a security key is generated using a second key corresponding to a second value (e.g., a value corresponding to the currently used KgNB). When it is necessary for the terminal device 100 to use a security key generated from the KAMF, the base station device 200 includes a master key update parameter in an RRC reconfiguration message, sets the key set change instruction to "true", and transmits the message to the terminal device 100. At this time, the RRC reconfiguration message may include a parameter for updating the LTM setting.

[0213] The security key is updated in accordance with, for example, information included in the cell switching signal or information included in another signal simultaneously transmitted from the base station device 200 with the cell switching signal. The process of determining whether or not a security key needs to be updated and / or the security key update method using the information included in the cell switching signal or information included in another signal simultaneously transmitted from the base station device 200 with the cell switching signal may be performed when a parameter indicating that the security keys on the MN side and / or the SN side are to be updated in accordance with the information included in the cell switching signal or information included in the other signal is set in the terminal device 100.

[0214] The information included in the cell switching signal, or another signal sent from the base station device 200 simultaneously with the cell switching signal, includes, for example, a parameter indicating whether a security key update is necessary and / or a parameter indicating a method for updating the security key.

[0215] For example, the information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes only a parameter indicating whether a security key update is necessary. If the parameter indicating whether a security key update is necessary indicates that a security key update is necessary, the terminal device 100 updates the security key in accordance with, for example, the parameter indicating the key generation method described above.

[0216] Furthermore, for example, information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes, as parameters indicating a security key update method, information on part or all of the key set change instruction and NCC, which are master key update parameters included in the RRC reconfiguration message. The terminal device 100 updates the security key, for example, in accordance with the parameters indicating the security key update method.

[0217] Furthermore, for example, information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes a parameter indicating whether or not a security key update is necessary and / or the security key update method, using number information such as '0' for no security update, '1' for horizontal generation, '2' for vertical generation, '3' for key set change instruction = "true", etc. When a security key update is necessary, the terminal device 100 updates the security key in accordance with, for example, the parameter indicating the security key update method.

[0218] Note that, when the information included in the above-mentioned cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal does not include information related to a key set change instruction, and when the base station device 200 needs to cause the terminal device 100 to use a security key generated from the KAMF, the base station device 200 includes a master key update parameter in an RRC reconfiguration message, sets the key set change instruction to "true", and transmits the RRC reconfiguration message to the terminal device 100. At this time, a parameter for updating the LTM setting may be included in this RRC reconfiguration message. Furthermore, the information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes other information, for example, information indicating which reference setting to apply.

[0219] The terminal device 100 generates an SRB encryption key, an SRB integrity protection key, a DRB encryption key, and a DRB integrity protection key from the updated security key, and applies these to the PDCP entities of the MN-terminated radio bearers among the radio bearers set in the terminal device 100. Applying each of the generated keys to the PDCP entities of the MN-terminated radio bearers means, for example, setting an encryption algorithm and / or the generated DRB encryption key for the PDCP of some or all of the MN-terminated DRBs set in the terminal device 100 when a parameter (cipheringDisabled) indicating that encryption is disabled is not set in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the MN-terminated radio bearers means, for example, when a parameter (integrityProtection) indicating the application of integrity protection is set in the terminal device 100, setting an integrity protection algorithm and / or the generated DRB integrity protection key for the PDCP entities of some or all of the MN-terminated DRBs set in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the MN-terminated radio bearers means, for example, initiating PDCP re-establishment for the PDCP entities of some or all of the MN-terminated DRBs set in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the MN-terminated radio bearers means, for example, setting an encryption algorithm and / or the generated SRB encryption key for the PDCP entities of some or all of the MN-terminated SRBs configured in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the MN-terminated radio bearers means, for example, setting an integrity protection algorithm and / or the generated SRB integrity protection key for the PDCP entities of some or all of the MN-terminated SRBs configured in the terminal device 100.Furthermore, applying each generated key to the PDCP entities of the MN-terminated radio bearers means, for example, initiating PDCP re-establishment for the PDCP entities of some or all of the MN-terminated SRBs set in the terminal device 100.

[0220] The process related to setting the SN will be described below. The process related to setting the SN is, for example, a process of updating and applying the secondary key.

[0221] The secondary key is updated by the method described in step S1201, for example, using parameters required for the secondary key generation method when updating the secondary key as described in step S1201.

[0222] The secondary key is updated in accordance with, for example, information included in the cell switching signal or information included in another signal simultaneously transmitted from the base station device 200 with the cell switching signal. The secondary key update process using the information included in the cell switching signal or information included in another signal simultaneously transmitted from the base station device 200 with the cell switching signal may be performed when a parameter indicating that the security keys on the MN side and / or the SN side are to be updated in accordance with the information included in the cell switching signal or information included in the other signal is set in the terminal device 100.

[0223] The information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes, for example, a parameter indicating whether a secondary key update is necessary and / or a parameter required for the secondary key generation method. The parameter required for the secondary key generation method may be, for example, an sk-counter. The terminal device 100 updates the secondary key using, for example, the information included in the cell switching signal or an sk-counter included in another signal sent from the base station device 200 simultaneously with the cell switching signal. Furthermore, the parameter required for the secondary key generation method may be, for example, an index or identifier indicating which sk-counter is used from a list of sk-counters set in the terminal device 100. The terminal device 100 updates the secondary key using, for example, an sk-counter corresponding to the information included in the cell switching signal or an index or identifier included in another signal sent from the base station device 200 simultaneously with the cell switching signal.

[0224] The terminal device 100 generates an SRB encryption key, an SRB integrity protection key, a DRB encryption key, and a DRB integrity protection key from the updated secondary key, and applies these to the PDC entities of the SN-terminated radio bearers among the radio bearers set in the terminal device 100. Applying each of the generated keys to the PDCP entities of the SN-terminated radio bearers means, for example, setting an encryption algorithm and / or the generated DRB encryption key for the PDCP of some or all of the SN-terminated DRBs set in the terminal device 100 when a parameter (cipheringDisabled) indicating that encryption is disabled is not set in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the SN-terminated radio bearers means, for example, when a parameter (integrityProtection) indicating the application of integrity protection is set in the terminal device 100, setting an integrity protection algorithm and / or the generated DRB integrity protection key for the PDCP entities of some or all of the SN-terminated DRBs set in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the SN-terminated radio bearers means, for example, initiating PDCP re-establishment for the PDCP entities of some or all of the SN-terminated DRBs set in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the SN-terminated radio bearers means, for example, setting an encryption algorithm and / or the generated SRB encryption key for the PDCP entities of some or all of the SN-terminated SRBs configured in the terminal device 100. Furthermore, applying each generated key to the PDCP entities of the SN-terminated radio bearers means, for example, setting an integrity protection algorithm and / or the generated SRB integrity protection key for the PDCP entities of some or all of the SN-terminated SRBs configured in the terminal device 100.Furthermore, applying each generated key to the PDCP entities of the SN-terminated radio bearers means, for example, initiating PDCP re-establishment for the PDCP entities of some or all of the SN-terminated SRBs set in the terminal device 100. The SN-terminated SRB is, for example, SRB3.

[0225] Furthermore, the processing related to the SN setting is, for example, processing to release the SN setting. The release of the SN setting includes, for example, some or all of the release of the SRB3, the release of the SN-terminated DRB, and the release of the SCG setting. The release of the SN setting also includes, for example, the release of the SCG bearer. The release of the SN setting also includes, for example, changing the SCG bearer and / or split bearer to an MCG bearer. Note that the processing to release the SN setting includes, for example, the release of the SN setting included in the reference setting stored as a variable in the terminal device 100. The processing to release the SN setting also includes, for example, the release of the SN setting included in the LTM candidate cell setting stored as a variable in the terminal device 100.

[0226] The MN-terminated radio bearer may be a radio bearer in which the keyToUse parameter is set to "master." The SN-terminated radio bearer may be a radio bearer in which the keyToUse parameter is set to "secondary." The terminal device 100 performs cell switching to the target cell (S1205).

[0227] After performing cell switching to the target cell, the terminal device 100 transmits an RRC reconfiguration complete message (S1206). The terminal device 100 may include, in the RRC reconfiguration complete message, the NCC value used when generating the security key. The terminal device 100 may also include, in the RRC reconfiguration complete message, information on the sk-counter used when generating the secondary key. Note that the terminal device 100 retains the LTM configuration and / or LTM candidate cell configuration received and stored in step S1201 without releasing it. The retained LTM configuration and / or LTM candidate cell configuration are used for subsequent LTM cell switching. Note that when inter-CU LTM cell switching is performed, the terminal device 100 transmits an RRC reconfiguration complete message to the base station device 200 to which the target cell belongs.

[0228] In addition, when "horizontal generation" is set by the parameter indicating the key generation method described above, and the terminal device 100 performs cell switching to a target cell by updating a security key using horizontal generation, for example, immediately after successful cell switching to the target cell, the terminal device 100 may vertically generate a security key with the same cell as the target cell and autonomously perform cell switching to the same cell. The terminal device 100 that has performed cell switching to the same cell transmits, for example, an RRC reconfiguration completion message. At this time, the RRC reconfiguration completion message may include the NCC value used when generating the security key. In this case, the terminal device 100 and the base station device 200 do not transmit or receive RRC messages using DCCH other than, for example, user data and / or an RRC reconfiguration completion message, from the time the terminal device 100 updates the security key using horizontal generation and starts cell switching to the target cell until the process of vertically generating a security key in the target cell and autonomously performing cell switching to the same cell is successfully completed.

[0229] In addition, when the terminal device 100 updates the security key using horizontal generation when switching to a target cell, the base station device 200 may send an RRC reconfiguration message including, for example, a master key update parameter to the terminal device 100, and cause the terminal device 100 to perform an intra-CU handover involving updating the security key using vertical generation.

[0230] Furthermore, when the terminal device 100 updates the security keys using horizontal generation during cell switching to a target cell, the base station device 200 may change the RRC reconfiguration message to include a master key update parameter, and may cause the terminal device 100 to perform an intra-CU handover involving updating of the security keys using vertical generation, using a cell switching signal or a signal other than the cell switching signal. The base station device 200 may perform this processing when, for example, the base station device 200 sets in the terminal device 100 a parameter indicating that the security keys on the MN side and / or SN side will be updated, according to information included in the above-mentioned cell switching signal or information included in another signal.

[0231] These processes are necessary to ensure that security keys using horizontal generation are updated consistently at the time of the next inter-CU cell switching of the terminal device 100.

[0232] Note that the cell switching signal, and / or another signal (hereinafter referred to as signal A) sent from base station device 200 simultaneously with the cell switching signal in step S1205, and / or a signal other than the cell switching signal for performing an intra-CU handover accompanied by security key update (hereinafter referred to as signal B) may be a MAC CE, an RRC message, or a DCI. If the cell switching signal is an RRC message, it may be, for example, an RRC message dedicated to cell switching. The RRC message dedicated to cell switching is, for example, an RRC message including information necessary for cell switching. Furthermore, if signal A is an RRC message, it may be, for example, an RRC message dedicated to notifying a method for updating a security key. The RRC message dedicated to notifying a method for updating a security key is, for example, an RRC message including information necessary for notifying a method for updating a security key, as described in step S1203. Furthermore, if signal B is an RRC message, it may be, for example, an RRC message dedicated to performing an intra-CU handover accompanied by security key update. A dedicated RRC message for performing an intra-CU handover accompanied by a security key update is, for example, an RRC message that includes information necessary to perform an intra-CU handover accompanied by a security key update.

[0233] Furthermore, the cell switching signal, and / or signal A, and / or signal B may be integrity protected / verified. To perform the integrity protection / verification, for example, a message authentication code for integrity (MAC-I) is added to the cell switching signal, and / or signal A, and / or signal B. The input value used to generate the MAC-I is a predetermined value, for example, "all binary '1'." When the cell switching signal, and / or signal A, and / or signal B are MAC CEs, the integrity verification may be performed in the MAC layer or in an upper layer. When the integrity verification is performed in an upper layer, for example, the MAC entity forwards the received cell switching signal to the upper layer. When the integrity verification is performed in an upper layer, for example, the upper layer notifies the MAC layer, which is a lower layer, of the result of the integrity verification. Note that the upper layer is, for example, the PDCP layer. Also, the upper layer is, for example, the RRC layer.

[0234] In addition, before setting parameters related to LTM for the terminal device 100 in step S1201, the base station device 200 transmits, for example, to a different CU (base station device) to which the LTM candidate cell belongs, information on the NCC to be used by the terminal device when performing inter-CU LTM cell switching, together with information on the terminal device 100.

[0235] Furthermore, when the terminal device 100 performs inter-CU LTM cell switching, after successfully receiving the RRC reconfiguration completion message in step S1206, the base station device 200 may notify all or some of the CUs to which the LTM candidate cells set in the terminal device 100 belong of the latest security key information of the terminal device 100. The latest security key information of the terminal device 100 is, for example, information on the security key updated by the terminal device 100 during inter-CU LTM cell switching. Furthermore, the base station device 200 that has notified all or some of the CUs to which the LTM candidate cells set in the terminal device 100 belong of the latest security key information of the terminal device 100 may receive, from the CU to which the notification is directed, information required for updating the security key used when the terminal device 100 performs inter-CU LTM cell switching to the CU to which the notification is directed. The information required for updating the security key is, for example, an NCC.

[0236] In addition, in the second example of the subsequence cell switching method corresponding to the intra-CU and inter-CU switching, an upper limit may be set on the number of CUs to which LTM candidate cells set in the terminal device 100 belong. For example, the number of CUs to which LTM candidate cells set in the terminal device 100 belong may be set to up to two or up to eight.

[0237] <Fast LTM Recovery for Intra-CU and Inter-CU> In a cell switch or handover involving security key update, or a handover (mobility) to a RAT other than NR, the terminal device 100 and the base station device 200 may erase all values ​​and data used in the source cell. Therefore, fast LTM recovery after a cell switch or handover failure involving security key update poses implementation issues and needs to be avoided. Therefore, the terminal device 100 does not perform fast LTM recovery, for example, after an inter-CU LTM cell switch failure. Furthermore, the terminal device 100 does not perform fast LTM recovery not only after an inter-CU LTM cell switch failure, but also, for example, if a failed handover (MCG synchronized reconfiguration) involves security key update, or after a handover (mobility) failure to a RAT other than NR.

[0238] When cell switching fails, the terminal device 100 performs an RRC connection reconnection procedure. In the RRC connection reconnection procedure, a cell is selected, and if at least all of the following conditions (1) to (4) are met, the terminal device 100 performs fast LTM recovery for the selected cell. Furthermore, if some or all of the following conditions (1) to (4) are not met, fast LTM recovery is not performed.

[0239] (1) A parameter indicating that fast LTM recovery is to be performed (a parameter named attemptLTM-Switch) is set.

[0240] (2) The selected cell is one of the LTM candidate cells. (3) The failed cell switch or failed handover (MCG synchronized reconfiguration) did not involve security key update.

[0241] (4) This is not a method for reconnecting an RRC connection initiated due to a handover (mobility) failure to a RAT other than NR.

[0242] Furthermore, if a parameter is set indicating that fast LTM recovery will be performed, for example, after a failure in inter-CU LTM cell switching, or after a failure in handover involving security key update (reconfiguration with MCG synchronization), or after a failure in handover (mobility) to a RAT other than NR, the terminal device 100 performs fast LTM recovery if the selected cell is an LTM candidate cell and the CU to which the selected LTM candidate cell belongs is different from the CU to which the source cell belongs.

[0243] The terminal device 100 performs an RRC connection reconnection means when cell switching fails, etc. The RRC connection reconnection means performs cell selection, and if at least all of the following conditions (1) to (2) are met, the terminal device 100 performs fast LTM recovery for the selected cell. Furthermore, if some or all of the following conditions (1) to (2) are not met, fast LTM recovery is not performed.

[0244] (1) A parameter indicating that fast LTM recovery is to be performed (a parameter named attemptLTM-Switch) is set.

[0245] (2) The selected cell is one of the LTM candidate cells, and the CU to which the selected LTM candidate cell belongs is different from the CU to which the source cell belongs.

[0246] Note that the CU to which the selected LTM candidate cell belongs is different from the CU to which the source cell belongs, for example, when the security update no longer required identifier parameter of the selected LTM candidate cell is different from the security update no longer required identifier parameter of the source cell. Also, the CU to which the selected LTM candidate cell belongs is different from the CU to which the source cell belongs, for example, when the security update no longer required identifier parameter of the selected LTM candidate cell is different from the security update no longer required identifier parameter of the current serving cell.

[0247] Note that, if the cell switching fails, the terminal device 100, for example, returns the settings of the terminal device 100 to the settings used in the source cell or the source PCell. When the terminal device 100 returns the settings of the terminal device 100 to the settings used in the source cell or the source PCell, for example, the terminal device 100 holds the state variables of the PDCP entities of some or all of the radio bearers set in the terminal device 100. Some or all of the radio bearers are, for example, SRBs linked to the MCG. Note that, for example, fast LTM recovery is not permitted after fast LTM recovery has failed.

[0248] When performing fast LTM recovery, cell switching is initiated in the terminal device 100. When performing fast LTM recovery, the terminal device 100 follows part or all of the processing of the subsequence cell switching method 2 corresponding to intra-CU and inter-CU, which was described using Fig. 12. For example, when performing fast LTM recovery, the terminal device 100 determines whether a security key needs to be updated for cell switching to the target cell, and if a security key update is required, updates the security key.

[0249] This embodiment enables flexible communication corresponding to subsequence cell switching within a CU and between CUs. It also makes it possible to avoid fast LTM recovery after cell switching failure that involves security key update, thereby avoiding implementation issues.

[0250] <Others> Although the present embodiment has been described using the case of LTM, the present embodiment can be applied to other technologies and methods. For example, the method of determining on the terminal device 100 side whether or not a security key update is necessary, the method of setting and / or notifying the security key update method, the processing after cell switching or handover failure, and the like in the present embodiment may be applied to a method in which candidates for a synchronized reset destination are set, such as CHO or CPAC.

[0251] The messages in the above sequence may be partially executed out of order or partially reordered. Also, some messages in the sequence may not be executed at all.

[0252] Furthermore, what is described as a function or process of the terminal device 100 may be a function or process of the base station device 200. Furthermore, what is described as a function or process of the base station device 200 may be a function or process of the terminal device 100.

[0253] Furthermore, when the term "radio bearer" is used without distinguishing between a signaling radio bearer and a data radio bearer, the radio bearer may be a signaling radio bearer, a data radio bearer, or both a signaling radio bearer and a data radio bearer.

[0254] Furthermore, "A may be replaced with B" and "A may be replaced with B" include the meaning of replacing B with A in addition to replacing A with B.

[0255] Furthermore, if condition "A" and condition "B" are contradictory conditions, condition "B" may be expressed as an "other" condition of condition "A."

[0256] To summarize, the following is the case.

[0257] (1) A terminal device having a receiving unit that receives signals from a first master base station device and a first secondary base station device, and a processing unit, wherein the receiving unit receives a first signal from the first master base station device, the first signal including a first setting for a first candidate cell, and when the processing unit receives a first cell switching command to the first candidate cell from the first master base station device, performs a first determination to determine whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device, and when the first candidate cell is a cell belonging to the second master base station device, performs a first process related to the setting of the master base station device and a second process related to the setting of the secondary base station device, and performs cell switching to the first candidate cell.

[0258] (2) The terminal device described in (1), wherein the first processing is a processing of updating and applying a first security key for the first master base station device to a security key for the second master base station device.

[0259] (3) The terminal device according to (1) or (2), wherein the second processing is processing of updating and applying a second security key for the first secondary base station device.

[0260] (4) The terminal device according to (1) or (2), wherein the second process is a process of releasing a setting related to the first secondary base station device.

[0261] (5) The terminal device according to (1), (2), (3), or (4), wherein the first determination is to determine that the first candidate cell is a cell belonging to the second master base station device if the group identifier included in the first setting is different from the stored group identifier.

[0262] (6) The terminal device according to (1), (2), (3), or (4), wherein the first judgment is to judge that the first candidate cell is a cell belonging to the second master base station device if the first cell switching command includes parameters related to security key update.

[0263] (7) The terminal device according to (1), (2), (3), (4), (5), or (6), further comprising: when receiving a cell switching command to the first candidate cell from the first master base station device, the processing unit performs a first determination to determine whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device, and if the first candidate cell is a cell belonging to the first master base station, the processing unit performs cell switching to the first candidate cell without performing the first processing and the second processing.

[0264] (8) A base station device having a transmitting unit that transmits a signal to a terminal device and a processing unit, wherein the transmitting unit transmits a first signal to the terminal device, the first signal including a first setting for a first candidate cell, and the processing unit controls the terminal device to transmit a first cell switching command to the first candidate cell, thereby causing the terminal device to make a first determination of whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device, and if the first candidate cell is a cell belonging to the second master base station device, causing the terminal device to perform a first process related to the setting of the master base station device and a second process related to the setting of a secondary base station device, and causing cell switching to the first candidate cell.

[0265] Although an example of a device has been described in each embodiment, the method of the present disclosure is not limited to cellular phones, smartphones, tablet terminals, base station devices, etc., but can be applied to other electronic devices, such as electronic devices mounted on automobiles, trains, airplanes, artificial satellites, etc., electronic devices mounted on drones, etc., robots, AV equipment, home appliances, office equipment, vending machines, other household equipment, industrial equipment, and other devices.

[0266] In addition, in each embodiment, E-UTRA and NR are used as radio access technologies, and EPC and 5GC are used as core networks. However, the application of the method of the present disclosure is not limited to these. For example, the method of the present disclosure may be applied to radio access technologies and networks of different generations, such as 6th generation and 7th generation.

[0267] Furthermore, the present invention is not limited to the above-described embodiment, and various modifications can be made.

[0268] Although each embodiment has been described in detail with reference to the drawings, the specific configuration is not limited to the disclosed drawings and the described embodiments.

[0269] 10: Communication system 100: Terminal device 110: CPU 120: Storage 121: Wireless communication program 122: Terminal side program 130: Memory 140: Wireless communication circuit 200: Base station device 210: CPU 220: Storage 221: Wireless communication program 222: Base station side program 230: Memory 240: Wireless communication circuit 250: Network interface 300: Core network

Claims

1. A terminal device comprising: a receiving unit that receives signals from a first master base station device and a first secondary base station device; and a processing unit, wherein the receiving unit receives a first signal including a first setting for a first candidate cell from the first master base station device; and when the processing unit receives a first cell switching command to the first candidate cell from the first master base station device, performs a first determination to determine whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device; and when the first candidate cell is a cell belonging to the second master base station device, performs a first process related to the setting of the master base station device and a second process related to the setting of the secondary base station device, and performs cell switching to the first candidate cell.

2. The terminal device according to claim 1, wherein the first processing is processing for updating a first security key for the first master base station device to a security key for the second master base station device and applying the updated security key.

3. The terminal device according to claim 1, wherein the second process is a process of updating and applying a second security key for the first secondary base station device.

4. The terminal device according to claim 1, wherein the second process is a process of releasing a setting related to the first secondary base station device.

5. The terminal device according to claim 1, wherein the first determination is to determine that the first candidate cell is a cell belonging to the second master base station device if the group identifier included in the first setting is different from the stored group identifier.

6. The terminal device according to claim 1, wherein the first determination is to determine that the first candidate cell is a cell belonging to the second master base station device when the first cell switching command includes parameters related to security key update.

7. The terminal device according to claim 1, wherein the processing unit further performs cell switching to the first candidate cell without performing the first process and the second process when the first candidate cell is a cell belonging to the first master base station.

8. A base station device comprising: a transmitting unit that transmits a signal to a terminal device; and a processing unit, wherein the transmitting unit transmits a first signal to the terminal device, the first signal including a first setting for a first candidate cell; and the processing unit controls the terminal device to transmit a first cell switching command to the first candidate cell, thereby causing the terminal device to make a first determination of whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device, and if the first candidate cell is a cell belonging to the second master base station device, causing the terminal device to perform a first process related to the setting of the master base station device and a second process related to the setting of a secondary base station device, and performing cell switching to the first candidate cell.

9. A wireless communication system comprising: a first master base station device; a first secondary base station device; and a terminal device that receives signals from the first master base station device and the first secondary base station device, wherein the terminal device receives a first signal including a first setting for a first candidate cell from the first master base station device; when receiving a first cell switching command to the first candidate cell from the first master base station device, performs a first determination to determine whether the first candidate cell is a cell belonging to a second master base station device different from the first master base station device; and if the first candidate cell is a cell belonging to the second master base station device, performs a first process related to the setting of the master base station device and a second process related to the setting of the secondary base station device, and performs cell switching to the first candidate cell.

Images