Terminal device, base station device, and wireless communication system

Abstract

The terminal device has a reception unit and a processing unit. The reception unit is capable of receiving an RRC message and a first signal from a base station device. When the RRC message includes the first parameter, the processing unit is capable of setting in accordance with the first parameter. The first parameters include a second parameter, and the first parameters also include a third parameter associated with a setting of a first LTM candidate and the first LTM candidate. The processing unit performs cell handover to the first LTM candidate when a first signal is received from the base station device, does not perform the first processing when the value of the third parameter is the same as the value of the second parameter, and performs the first processing when the value of the third parameter is different from the value of the second parameter. The value of the second parameter is replaced with the value of the third parameter.

Description

Technical Field

[0001] This invention relates to terminal devices, base station devices, and wireless communication systems. Background Technology

[0002] In the current network landscape, wireless communication networks utilizing mobile terminals (smartphones, feature phones, etc.) are expanding. This expansion of wireless communication demands further increases in speed and capacity.

[0003] Within the 3rd Generation Partnership Project (3GPP) (registered trademark), an international standardization project, technical research and standardization of cellular mobile communication systems are underway. For example, E-UTRA (Evolved Universal Terrestrial Radio Access), a Radio Access Technology (RAT) for the 3.9th Generation (3.9G) and 4th Generation (4G), has been standardized; and EPC (Evolved Packet Core), a Core Network (CN) technology, has been standardized. Furthermore, NR (New Radio), a RAT for the 5th Generation (5G), has been standardized; and 5GC (5G Core), a Core Network technology, has been standardized. Additionally, these extended technologies are also under continuous research and standardization.

[0004] As for technologies related to NR or 5G systems, such as those described in Non-Patent Documents 1 to 12 below.

[0005] Existing technical documents

[0006] Non-patent literature

[0007] Non-Patent Document 1: TS38.300 V17.5.0 Summary Specification

[0008] Non-Patent Document 2: TS38.211 V17.5.0 PHY Channel and Modulation Specifications

[0009] Non-Patent Document 3: TS38.321 V17.5.0 MAC Specification

[0010] Non-patent document 4: TS38.322 V17.3.0 RLC specification

[0011] Non-Patent Document 5: TS38.323 V17.5.0 PDCP Specification

[0012] Non-Patent Document 6: TS37.324 V17.0.0 SDAP Specification

[0013] Non-Patent Document 7: TS38.304 V17.5.0 Idle Mode and Inactive Mode Specifications

[0014] Non-patent document 8: TS38.331 V17.5.0 RRC specification

[0015] Non-Patent Document 9: RP-223520

[0016] Non-patent document 10: R2-2211642

[0017] Non-patent document 11: R2-2211795

[0018] Non-Patent Document 12: TS33.501 V17.10.0 5G System Security Specification Summary of the Invention

[0019] The problem that the invention aims to solve

[0020] As one of the extended technologies, research was conducted on technologies related to improving mobility. One of the research projects is a technology called LTM (L1 / L2-triggered mobility), which achieves effects such as reducing latency in mobility by changing the serving cell of the terminal device through the use of layer 1 and / or layer 2 signals (Non-Patent Document 9).

[0021] However, the specific methods for LTM have not been standardized. For example, details regarding the recovery method for RRC connections, taking into account security measures in the handling of terminal devices in the event of LTM-based cell handover failure, have not been determined. Furthermore, for example, details regarding specifications for performing previous handovers (reconfiguration with synchronization) while the terminal device is configured with LTM have not been determined. Additionally, for example, there has been no discussion regarding LTM across CUs (Centralized Units).

[0022] Therefore, the purpose of this disclosure is to provide base station devices, terminal devices, and wireless communication systems that can flexibly change the serving cell.

[0023] Methods for solving problems

[0024] This disclosure discloses a terminal device, characterized in that it comprises: a receiving unit that receives an RRC message and a first signal from a base station device; and a processing unit that, when the RRC message includes a first parameter, is capable of setting according to the first parameter, the first parameter including a second parameter, the first parameter further including a third parameter related to the setting of a first LTM candidate and the first LTM candidate, the processing unit performing cell handover to the first LTM candidate when receiving the first signal from the base station device, not performing first processing when the value of the third parameter is the same as the value of the second parameter, and performing first processing when the value of the third parameter is different from the value of the second parameter, replacing the value of the second parameter with the value of the third parameter.

[0025] Furthermore, this disclosure discloses a base station apparatus, characterized in that it comprises: a transmitting unit that transmits an RRC message and a first signal to a terminal device; and a processing unit capable of performing the following control: the RRC message includes a first parameter, causing the terminal device to perform a setting according to the first parameter, the first parameter including a second parameter, the first parameter further including a third parameter related to the setting of a first LTM candidate and the first LTM candidate; the processing unit transmits the first signal from the transmitting unit to the terminal device, causing the terminal device to perform a cell handover to the first LTM candidate; if the value of the third parameter is the same as the value of the second parameter, no first processing is performed; if the value of the third parameter is different from the value of the second parameter, the first processing is performed, replacing the value of the second parameter with the value of the third parameter.

[0026] Furthermore, this disclosure discloses a wireless communication system, characterized in that it comprises: a base station device that transmits an RRC message and a first signal; and a terminal device that receives the RRC message and the first signal, and when the RRC message includes a first parameter, performs setting according to the first parameter, the first parameter including a second parameter, the first parameter further including a third parameter related to the setting of a first LTM candidate and the first LTM candidate, the terminal device performing cell handover to the first LTM candidate when receiving the first signal from the base station device, and when the value of the third parameter is the same as the value of the second parameter, no first processing is performed, and when the value of the third parameter is different from the value of the second parameter, the first processing is performed, replacing the value of the second parameter with the value of the third parameter.

[0027] Invention Effects

[0028] This disclosure allows for flexible changes to the service area. Attached Figure Description

[0029] Figure 1 This is a diagram illustrating an example of the structure of a wireless communication system.

[0030] Figure 2 This is a diagram illustrating an example of the structure of a base station device.

[0031] Figure 3 This is a diagram illustrating an example of the structure of a terminal device.

[0032] Figure 4 This is a diagram illustrating an example of the U-Plane protocol stack.

[0033] Figure 5 This is a diagram illustrating an example of the C-Plane protocol stack.

[0034] Figure 6 This is a diagram illustrating an example of the message format for RRCReconfiguration.

[0035] Figure 7 This is a diagram illustrating an example of the structure of a cell group in a communication system.

[0036] Figure 8 This is a diagram illustrating an example of a reset with synchronization.

[0037] Figure 9 This is a diagram illustrating an example of a four-step random access handover process.

[0038] Figure 10 This is a diagram representing an example of an LTM sequence.

[0039] Figure 11 This is a diagram illustrating an example of the sequence for cell handover failure detection and cell handover failure handling.

[0040] Figure 12 This diagram illustrates an example of how to handle a handover failure in the first cell.

[0041] Figure 13 This diagram illustrates an example of a method for handling handover failures in a second cell.

[0042] Figure 14 This diagram illustrates an example of a method for handling handover failures in a third cell.

[0043] Figure 15 This diagram illustrates an example of how to handle a handover failure in the fourth cell.

[0044] Figure 16 This is a diagram illustrating an example of the processing corresponding to the selected cell.

[0045] Figure 17 This is a diagram illustrating an example of LTM-related parameters contained in the RRCReconfiguration message.

[0046] Figure 18 This diagram illustrates the first example of the switching process in the LTM setting.

[0047] Figure 19 This is a diagram illustrating the second example of the switching process in LTM settings.

[0048] Figure 20 This is a diagram illustrating the third example of the switching process in LTM settings. Detailed Implementation

[0049] Hereinafter, this embodiment will be described in detail with reference to the accompanying drawings. The issues and embodiments in this specification are examples and do not limit the scope of this application. In particular, even if the described manifestations are different, as long as they are technically the same, the technology of this application can be applied even if the manifestations are different, and the scope of the application is not limited.

[0050] Furthermore, in this embodiment, the names and processing of various devices, nodes, functions, protocols, entities, signaling, messages, parameters, etc., are described for cases where the wireless access technology is E-UTRA or NR, and for cases where the core network is EPC or 5GC. However, this embodiment can also be used for other wireless access technologies. The names of the nodes and entities in each embodiment can be other names.

[0051] <Structure Example of Communication System 10>

[0052] Figure 1 This is a diagram illustrating a structural example of a wireless communication system 10. The communication system 10 includes a terminal device 100, base station devices 200-1 and 2, and a core network 300. The communication system 10 can be a diagram of a wireless communication system in which the terminal device 100 communicates with either base station device 200-1 or base station device 200-2, or it can be a wireless communication system in which the terminal device 100 communicates with both base station devices 200-1 and 200-2 via MR-DC (Multi Radio Dual Connectivity), as described later. In the case of communication via MR-DC, for example, base station device 200-1 is a master base station device, and base station device 200-2 is a secondary base station device. Hereinafter, the master base station device will sometimes be referred to as MN (Master Node), and the secondary base station device as SN (Secondary Node).

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

[0054] Base station devices 200-1 and 200-2 (hereinafter sometimes referred to as base station device 200) are communication devices that wirelessly connect to terminal device 100 for wireless communication. Alternatively, base station devices 200-1 and 200-2 may be connected to each other via a wired connection for communication. Base station device 200 may be connected to core network 300 via a wired connection for communication. Base station device 200 may be, for example, either an eNodeB (eNB) provided by E-UTRA as a RAT or a gNodeB (gNB) provided by NR as a RAT.

[0055] Core network 300 corresponds to a specific generation of network. For example, core network 300 is 5GC, which is oriented towards 5G standardization, and EPC, which is oriented towards 4G standardization.

[0056] The details of the MR-DC implemented in communication system 10 will be described later.

[0057] <Structural Example of Base Station Device 200>

[0058] Figure 2 This is a diagram illustrating a structural example of a base station device 200. The base station device 200 is a communication device or relay device having a CPU (Central Processing Unit) 210, a storage unit 220, a memory unit 230, a wireless communication circuit 240, and a network interface 250.

[0059] Storage 220 is an auxiliary storage device such as flash memory, HDD (Hard Disk Drive), or SSD (Solid State Drive) that stores programs and data. Storage 220 stores wireless communication program 221 and base station-side program 222.

[0060] Memory 230 is the area where programs stored in memory 220 are loaded. Additionally, memory 230 can also be used as an area for storing data by programs.

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

[0062] The NI (Network Interface) 250 is, for example, a communication device that connects to other base station devices 200 and enables inter-base station communication. Furthermore, the NI 250 is, for example, a communication device that connects to and communicates with the core network 300 (the communication devices constituting the core network 300). The NI 250 is, for example, a NIC (Network Interface Card). The base station device 200 receives signals from other communication devices and transmits signals to other communication devices via the NI 250.

[0063] CPU210 is a processor that loads the program stored in memory 220 into memory 230, executes the loaded program, builds various parts, and performs various processes.

[0064] CPU 210 performs wireless communication processing by executing wireless communication program 221. Wireless communication processing includes wirelessly connecting to terminal device 100 to conduct wireless communication with terminal device 100, or relaying communication between terminal device 100 and other communication devices.

[0065] CPU 210 executes base station-side program 222 to construct a second transmitting unit, a second receiving unit, and a second processing unit, performing base station-side processing. When base station device 200 communicates with terminal device 100 using MR-DC, base station-side processing may include MR-DC master node processing and MR-DC slave node processing. In this case, MR-DC master node processing performs control processing on the master node side of the MR-DC, and MR-DC slave node processing performs control processing on the slave node side of the MR-DC. In MR-DC master node processing and MR-DC slave node processing, base station device 200 performs communication corresponding to various types of MR-DCs described later.

[0066] <Structure Example of Terminal Device 100>

[0067] Figure 3 This is a diagram showing a structural example of terminal device 100. Terminal device 100 is a communication device having a CPU 110, a storage 120, a memory 130, and a wireless communication circuit 140.

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

[0069] Memory 130 is the area where programs stored in memory 120 are loaded. Additionally, memory 130 can also be used as an area for storing data by programs.

[0070] The wireless communication circuit 140 is a circuit that communicates wirelessly with the base station device 200. The terminal device 100, for example, receives signals transmitted from the base station device 200 via the wireless communication circuit 140 and transmits signals to the base station device 200. The wireless communication circuit 140 is, for example, a network interface card (NIC) corresponding to a wireless connection.

[0071] CPU110 is a processor that loads the program stored in memory 120 into memory 130, executes the loaded program, builds various parts, and performs various processes.

[0072] CPU 110 performs terminal-side wireless communication processing by executing wireless communication program 121. Terminal-side wireless communication processing is the process of wirelessly connecting to base station device 200 and communicating with base station device 200, or communicating with other communication devices via base station device 200.

[0073] CPU 110 executes terminal-side program 122 to construct a transmitting unit, a receiving unit, and a processing unit, and performs terminal-side processing. When terminal device 100 communicates with base station device 200 using MR-DC, terminal-side processing may include terminal-side MR-DC processing. In this case, terminal-side MR-DC processing is the processing that controls communication within the MR-DC. Terminal device 100 performs communication corresponding to various types of MR-DCs described later in the terminal-side MR-DC processing.

[0074] <Protocol Stack>

[0075] An example of the protocol stack of communication system 10 will be explained. In communication system 10, the hierarchical structure of a series of protocols used for data transmission and reception 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. Furthermore, the terminal device 100 (UE: User Equipment) corresponds to one or both of E-UTRA and NR.

[0076] The protocol stacks of U-Plane (User Plane) and C-Plane (Control Plane) are described below. U-Plane is used, for example, in communication for sending and receiving user data. C-Plane is used, for example, in communication for sending and receiving control signals (messages). Furthermore, in each embodiment, unless specifically mentioned as "user data" or "control signals (messages)," "data" refers to one or both of the user data and control signals (messages).

[0077] Figure 4 This is a diagram illustrating an example of the U-Plane protocol stack when the core network is 300 with a 5GC architecture. Furthermore, Figure 5 This is a diagram illustrating an example of the protocol stack of C-Plane when the core network 300 is 5GC. Figure 4 , Figure 5 In this context, 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) represent the layer names. Hereinafter, PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS are sometimes 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 are sometimes referred to as the MAC sublayer, RLC sublayer, PDCP sublayer, and SDAP sublayer, respectively. Additionally, MAC, RLC, PDCP, and SDAP are sometimes referred to as the MAC entity, RLC entity, PDCP entity, and SDAP entity, respectively. It should be noted that in the case of a 300 core network with EPC, the U-Plane protocol stack becomes... Figure 4 The protocol stack in this system does not include SDAP. That is, it consists of a protocol stack of PHY, MAC, RLC, and PDCP. Furthermore, in the case of a core network 300 being an EPC, the C-Plane protocol stack becomes... Figure 5 In China, NAS exists in AMF (Access and Mobility Management Function) and also in MME (Mobility Management Entity).

[0078] In the case of RAT being E-UTRA and NR, the functions in each layer are sometimes the same and sometimes different. In the following description, unless E-UTRA or NR is specified, the functions are assumed to be common to both E-UTRA and NR.

[0079] In addition, within each sub-layer, the data provided from the upper layer and the data provided to the upper layer are called SDUs (Service Data Units). That is, the data provided from the upper layer to MAC, RLC, PDCP, and SDAP, and the data provided from MAC, RLC, PDCP, and SDAP to the upper layer are respectively called MAC SDU, RLC SDU, PDCP SDU, and SDAP SDU.

[0080] Furthermore, within each sublayer, the data provided to and received from the lower layer is called a PDU (Protocol Data Unit). Specifically, the data provided from MAC, RLC, PDCP, and SDAP to the lower layer, and the data provided from the lower layer to MAC, RLC, PDCP, and SDAP, are respectively called MAC PDU, RLC PDU, PDCP PDU, and SDAP PDU. Additionally, RLC, PDCP, and SDAP contain control PDUs, sometimes referred to as control PDUs. Furthermore, to distinguish them from control PDUs, other PDUs are sometimes referred to as data PDUs.

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

[0082] Here's an example illustrating the function of the PHY. The PHY is the wireless physical layer, using a physical channel to transmit control information and data between the terminal device 100 and the base station device 200. Sometimes, the direction from the base station device 200 to the terminal device 100 is called the downlink (DL), and the direction from the terminal device 100 to the base station device 200 is called the uplink (UL). Furthermore, within both the terminal device 100 and the base station device 200, the PHY connects to the MAC layer (the upper layer) via a transport channel, and data moves between the PHY and MAC via the transport channel. To identify various control information, the PHY uses an RNTI (Radio Network Temporary Identifier).

[0083] An example of the MAC's function will be explained. The MAC is the Media Access Control layer, responsible for mapping between transport channels and logical channels (LCH), multiplexing and demultiplexing MAC SDUs, scheduling reports (SR), error correction for HARQ (Hybrid Automatic Repeat reQuest), priority control, etc. Within the terminal device 100 and the base station device 200, the MAC connects to the upper-layer RLC via the logical channel, and data moves between the MAC and RLC via the logical channel. The logical channel can be identified by its Logical Channel Identifier (LCID). Furthermore, the base station device 200 uses the MAC control element (CE) to control the terminal device 100, etc. Additionally, the terminal device 100 uses the MAC CE to report to the base station device 200, etc.

[0084] RLC (Radio Link Control) operates in three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). On the transmitting side, RLC performs PDU transmission, sequence number assignment (UM and AM), SDU segmentation (UM and AM), and re-segmentation (AM). On the receiving side, it performs SDU reassembly (UM and AM), duplicate detection (AM), and SDU discarding (UM and AM). Additionally, RLC re-establishment occurs on both the transmitting and receiving sides. The segmented SDUs are called SDU segments. Furthermore, RLC has data retransmission and / or Automatic Repeat reQuest (ARQ) functions (AM). In the case of E-UTRA RLC, it also includes functions for data combination on the transmitting side, reordering on the receiving side, and ordered transmission.

[0085] PDCP is the packet data aggregation protocol layer, responsible for U-Plane and C-Plane data transmission, PDCP sequence number management, header compression / decompression, encryption / decryption, integrity protection / integrity verification, timer-based SDU discarding, routing for segmented bearers, reordering, and ordered delivery. It should be noted that in E-UTRA PDCP, the timer-based SDU discarding, reordering, and ordered delivery functions are limited to the segmented bearer scenarios described later.

[0086] SDAP is the Service Data Adaptive Protocol Layer, which performs mapping of QoS (Quality of Service) flows and Data Radio Bearers (DRBs) as described later, and marks QoS Flow Identifiers (QFIs) for downlink (DL) packets and uplink (UL) packets.

[0087] As upper layers of U-Plane, there exist layers such as IP (Internet Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), Ethernet, and application layers. The layer including IP, TCP, UDP, Ethernet, etc., can be called the PDU layer. Furthermore, IMS (IP Multimedia Subsystem), which performs session control, can be included in the application layer.

[0088] exist Figure 5 In this architecture, the AS (Access Stratum) C-Plane consists of PHY, MAC, RLC, PDCP, and RRC, terminating at the terminal device 100 and the base station device 200. Furthermore, the NAS C-Plane consists of NAS, terminating between the terminal device 100 and the AMF (Active Network Function) of the device serving as the core network 300. The PHY, MAC, RLC, and PDCP components are the same as those in the U-Plane.

[0089] RRC performs functions such as broadcasting system information (SI) associated with AS and NAS, paging, establishing / maintaining / releasing RRC connections between terminal device 100 and 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 bearer (SRB) and data radio bearer (DRB), mobility functions, QoS management functions, terminal device measurement reports and report control, detection and recovery of radio link failure (RLF), and transmission of NAS messages.

[0090] NAS performs authentication, activity management, and security control on the core network side.

[0091] <channel>

[0092] The channels used in communication system 10 will be described below. Examples of channels corresponding to NR are shown below, but the channels used are not limited to these. Furthermore, channels with the same name may also be used for the same or similar purposes in RATs other than NR, such as E-UTRA.

[0093] <1. Physical Channel>

[0094] PBCH (Physical Broadcast Channel) is a channel used to send broadcast information from base station device 200 to terminal device 100.

[0095] The PDCCH (Physical Downlink Control Channel) is a channel used to send downlink control information (DCI) from the base station device 200 to the terminal device 100.

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

[0097] PUCCH (Physical Uplink Control Channel) is a channel used to send uplink control information (UCI) from terminal device 100 to base station device 200.

[0098] PUSCH (Physical Uplink Shared Channel) is a channel used to send data from the upper layer from the terminal device 100 to the base station device 200.

[0099] PRACH (Physical Random Access Channel) is a channel used to send random access preambles, etc., from terminal device 100 to base station device 200.

[0100] <2. Transmission Channel>

[0101] BCH (Broadcast Channel) is mapped to PBCH, which is a physical channel.

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

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

[0104] UL-SCH (UpLink Shared Channel) is mapped to PUSCH, which is a physical channel.

[0105] RACH (Random Access Channel(s)) is mapped to PRACH as a physical channel.

[0106] <3. Logical Channel>

[0107] BCCH (Broadcast Control Channel) is a downlink channel used for broadcasting system information, mapped to the BCH or DL-SCH of the transport channel.

[0108] PCCH (Paging Control Channel) is a downlink channel used to carry paging messages, mapped to the transport channel.

[0109] CCCH (Common Control Channel) is a channel used to send control information (RRC messages, etc.) between terminal device 100 and base station device 200. It is a channel used by terminal device 100 that does not maintain (do not have) an RRC connection with base station device 200. The downlink is mapped to DL-SCH of the transport channel, and the uplink is mapped to UL-SCH of the transport channel.

[0110] The DCCH (Dedicated Control Channel) transmits dedicated control information (RRC messages, etc.) between the terminal device 100 and the base station device 200 through a point-to-point bidirectional channel. It is used by the terminal device 100, which has an RRC connection with the base station device 200. The downlink is mapped to the DL-SCH of the transport channel, and the uplink is mapped to the UL-SCH of the transport channel.

[0111] The DTCH (Dedicated Transport CHannel) sends user information (user data) through a point-to-point dedicated bi-directional channel for the terminal. The downlink is mapped to the DL-SCH of the transport channel, and the uplink is mapped to the UL-SCH of the transport channel.

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

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

[0114] <RRC state (mode)>

[0115] The RRC state of the terminal device 100 is the state related to the RRC connection of the terminal device 100. The state where the RRC connection with the base station device 200 is not established is called the RRC idle mode (RRC_IDLE). The state where the RRC connection with the base station device 200 is established is called the RRC connected mode (RRC_CONNECTED). The state where the RRC connection with the base station device 200 is temporarily suspended (suspended) is called the RRC inactive mode (RRC_INACTIVE). It should be noted that when the core network 300 is an EPC, the state where the RRC connection with the base station device 200 is not temporarily suspended may not be called the RRC inactive mode, but other names such as the suspension of the RRC.

[0116] <RRC message>

[0117] The RRC explains the message. The RRC message is a message containing the information required for communication in the cell, including the MIB (Master Information Block), system information group (SIB: System Information Block), etc. Sometimes the parameters contained in the RRC message are called fields or information elements (IE: Information Element).

[0118] In addition, RRC messages include messages related to the establishment of an RRC connection. For example, in the case of NR, there are RRC setup request messages (RRCSetupRequest), RRC setup messages (RRCSetup), and RRC setup complete messages (RRCSetupComplete). Similarly, in the case of E-UTRA, there are RRC connection setup request messages (RRCConnectionSetupRequest), RRC connection setup messages (RRCConnectionSetup), and RRC connection setup complete messages (RRCConnectionSetupComplete).

[0119] In addition, RRC messages include messages related to the initial activation of AS (Access Stratum) security. Examples of messages related to the initial activation of AS security include SecurityModeCommand messages.

[0120] In addition, RRC messages include messages related to the reconfiguration of RRC connections. For example, in the case of NR, there are RRC Reconfiguration messages and RRC Reconfiguration Complete messages. Similarly, in the case of E-UTRA, there are RRC Connection Reconfiguration messages and RRC Connection Reconfiguration Complete messages. Furthermore, in addition to establishing, configuring, changing, releasing, and reconfiguring radio bearers and cell groups (described later), RRC connection reconfiguration messages also include establishing, configuring, changing, and releasing measurement information.

[0121] After initial activation of AS security, terminal device 100 receives an initial RRC reset message from base station device 200, obtaining all or at least all the settings required for communication (data communication) with base station device 200 in the cell to which terminal device 100 is connected. Sometimes, these all or at least all the settings required for communication (data communication) with base station device 200 are referred to as, for example, complete settings.

[0122] It should be noted that after the initial activation of AS security for the terminal device 100, the base station device 200 can send an initial RRC reset message and further send other RRC reset messages to update the settings required for communication (data communication) between the terminal device 100 and the base station device 200. In this case, the base station device 200 includes a differential setting relative to the complete setting currently set on the terminal device 100 in the RRC reset message. This differential setting is sometimes referred to as the Δ setting. When the terminal device 100 receives the RRC reset message containing the Δ setting, it generates a new setting by applying the Δ setting to the currently used complete setting.

[0123] In addition, RRC messages include messages related to the re-establishment of RRC connections. For example, in the case of NR, there are RRC Re-establishment Request messages, RRC Re-establish messages, and RRC Re-establishment Complete messages. Similarly, in the case of E-UTRA, there are RRC Connection Re-establishment Request messages, RRC Connection Re-establish messages, and RRC Connection Re-establish Complete messages.

[0124] In addition, RRC messages also include messages related to the release and suspension of RRC connections, messages related to the restart of RRC connections, messages related to the capabilities of the terminal device, messages related to terminal information, and messages related to MCG failure information and SCG failure information.

[0125] It should be noted that in MR-DC, when the master node is an eNB, the eNB can include the NR RRC message and parameters received from the gNB (as a secondary node) as a container in an E-UTRA RRC message and send it to the terminal device 100, thereby performing NR-related settings on the terminal device 100. Furthermore, the terminal device 100 can include a completion message for the NR-related settings as a container in an E-UTRA RRC message and send it to the eNB (as the master node).

[0126] Furthermore, in MR-DC, when the master node is a gNB, the gNB can include 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 send it to the terminal device 100, thereby performing E-UTRA-related settings on the terminal device 100. Additionally, the terminal device 100 can include a completion message for E-UTRA-related settings as a container in the NR RRC message and send it to the gNB (which is the master node).

[0127] Figure 6 This is a diagram illustrating an example of the message format for RRCReconfiguration. Format E1 represents the parameters of RRCReconfiguration.

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

[0129] radioBearerConfig and radioBearerConfig2 are settings related to MN terminated bearers or SN terminated bearers, including SRB settings, DRB settings, and security settings. SRB settings (DRB settings) include the SRB identifier (DRB identifier), PDCP settings, and parameters instructing PDCP re-establishment. Security settings include a parameter (keyToUse) indicating whether to use the master key or the subkey.

[0130] masterCellGroup and secondaryCellGroup are the MCG and SCG settings, respectively, including cell group identifiers, RLC bearer settings, and SpCell settings. RLC bearer settings include logical channel identifiers, RLC settings, and radio bearer identifiers (SRB identifiers or DRB identifiers) associated with the RLC bearer. SpCell settings include information required for reconfiguration with synchronization.

[0131] masterKeyUpdate contains the information needed to update the master key.

[0132] sk-counter contains the information needed to generate the secondary key.

[0133] Format E11 is a diagram showing an example of the parameters of RadioBearerConfig contained in RRCReconfiguration.

[0134] Format E12 is a diagram showing an example of the parameters of CellGroupConfig contained in RRCReconfiguration.

[0135] Format E111 is a diagram representing an example of the parameters of SRB-ToAddMod contained in RadioBearerConfig.

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

[0137] Format E113 is a diagram showing an example of the parameters of SecurityConfig contained in RadioBearerConfig.

[0138] Format E121 is a diagram showing an example of the parameters of RLC-BearerConfig contained in CellGroupConfig.

[0139] Format E122 is a diagram showing an example of the parameters of SpCellConfig contained in CellGroupConfig.

[0140] <Wireless Bearer>

[0141] An example of the wireless bearer of the communication system 10 is explained.

[0142] <1. Signaling Radio Bearer>

[0143] The Signaling Radio Bearer (SRB) is a radio bearer used to send RRC messages and NAS messages.

[0144] SRB0 is a radio bearer used for RRC messages using the CCCH logical channel.

[0145] SRB1 is a radio bearer established prior to the establishment of SRB2 (described later) for RRC messages and NAS messages using the DCCH logical channel.

[0146] SRB2 is a radio bearer used for sending and receiving NAS messages and transmitting RRC messages containing logged historical measurement information, using the DCCH logical channel. The priority of SRB2 can also be lower than that of SRB1, and is set by the base station device 200 after AS security is activated.

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

[0148] <2. Data Radio Bearer>

[0149] A data radio bearer (DRB) is a radio bearer used to transmit user data.

[0150] <Protocol Composition of SRB and DRB>

[0151] The protocol composition of SRB and DRB in the terminal device 100 will be described.

[0152] There is no PDCP entity in SRB0, and it consists of an RLC bearer. The RLC bearer consists of an RLC entity and a MAC logical channel. The mode of the RLC entity of SRB0 is TM.

[0153] SRB1 and SRB2 each consist of one PDCP entity and one or more RLC bearers. The mode of the RCL entity is AM.

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

[0155] A DRB consists of one PDCP entity and one or more RLC bearers. The mode of the RLC entity is UM or AM. When the RLC entity of the DBR is UM, it is sometimes called UM DBR, and when the RLC entity is AM, it is sometimes called AM DRB. In addition, the DRB associates with one SDAP when the core network 300 is 5GC, and associates with one EPS bearer (or EPS bearer identity) when the core network 300 is EPC.

[0156] It should be noted that there is one MAC entity in each cell group described below.

[0157] <Cell and Cell Group>

[0158] The cells and cell groups (CG: Cell Group) constituted by the terminal device 100 will be described.

[0159] A cell group can consist of a special cell (SpCell). Additionally, a cell group can consist of one SpCell and one or more secondary cells (SCells). It should be noted that the SpCell in the master cell group (MCG) described later is sometimes referred to as the primary cell (PCell). Furthermore, the SpCell in the secondary cell group (SCG) described later is sometimes referred to as the primary SCG cell (PSCell).

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

[0161] SCell is a cell that provides additional radio resources in addition to SpCell when Carrier Aggregation (CA) is configured in terminal device 100.

[0162] A 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 PSCells in the SCG.

[0163] It should be noted that the cell used by the terminal device 100 in communication with the base station device 200 when it is in RRC connection state is sometimes referred to as the serving cell. When CA is not configured, SpCell is the serving cell; when CA is configured, both SpCell and SCell become serving cells.

[0164] MCG is a CG in the case where DC (Dual Connectivity) is not configured in the terminal device 100, or a CG belonging to the master node (MN) when DC is configured in the terminal device 100. DC is a technology in which the terminal device 100 wirelessly connects to the base station device 200 as the master node and the base station device 200 as the secondary node (SN), and uses the carriers (cell groups) of each base station device 200 for wireless communication.

[0165] SCG is the GC of the secondary node that is set when DC is set in terminal device 100, other than MCG.

[0166] Figure 7 This is a diagram illustrating an example of the structure of a cell group in communication system 10. Figure 7 In this configuration, the primary node (MN) is base station device 200-1, and the secondary node (SN) is base station device 200-2. The primary node is the base station device 200 in the DC that provides C-Plane connectivity to the core network 300. The secondary node is the base station device 200 in the MR-DC that does not provide C-Plane connectivity to the core network 300 but provides additional radio resources to the terminal device 100. Figure 7 In this context, the MCG consists of one PCell and two SCells. Furthermore, in... Figure 7 In this system, the SCG consists of one PSCell and two SCells.

[0167] It should be noted that the base station device 200 can configure the Bandwidth Part (BWP) for the cell set in the terminal device 100 and adjust it to use a limited frequency band from the cell's entire frequency band. The BWP can consist of a portion of the frequency band of each cell. Furthermore, multiple BWPs can be configured for each cell (e.g., up to four). The BWP can be configured via an RRC reset message. The assignment or switching of the BWP used in each cell can be performed via an RRC reset message or via DCI.

[0168] <Reset with synchronization>

[0169] The following explains the reconfiguration with synchronization. Reconfiguration with synchronization refers to the process performed in the terminal device 100 by including a parameter (reconfigurationWithSync: hereinafter sometimes referred to as the reconfiguration parameter with synchronization) in the RRC reconfiguration message (RRCReconfiguration) sent by the base station device 200 to the terminal device 100, which means to perform a reconfiguration with synchronization.

[0170] The synchronized reset parameters are included under the parameters for MCG settings (hereinafter, sometimes referred to as MCG setting parameters) and the parameters for SCG settings (hereinafter, sometimes referred to as SCG setting parameters), respectively. That is to say, if it is included under the MCG setting parameters, it means a synchronized reset of the MCG; if it is included under the SCG setting parameters, it means a synchronized reset of the SCG.

[0171] The synchronized reset is the process by which the terminal device 100 changes the SpCell, including random access to the new (changed destination, target) SpCell, MAC reset, PDCP data recovery (in the case of AM DRB), and other actions.

[0172] Sometimes, the process of including synchronized reset parameters under MCG setting parameters is called handover. Additionally, sometimes the process of including synchronized reset parameters under SCG setting parameters is called PSCell addition and / or PSCell change. Furthermore, sometimes the PCell / PSCell from which the change originates is called the source PCell / source PSCell, and sometimes the PCell / PSCell from which the change originates is called the target PCell / target PSCell. Furthermore, since synchronized resets sometimes involve CA, the terminology of serving cell is sometimes used, referring to the source serving cell and target serving cell. Additionally, sometimes the term "serving cell" is omitted, and the terms "source cell" and "target cell" are used interchangeably.

[0173] Terminal device 100 can generate the settings for the target cell by applying the Δ settings contained in the RRC reset message to the settings of the source cell.

[0174] Additionally, a synchronized reset sometimes involves a change of the security key. In this case, in addition to the above, a PDCP re-establishment is also performed.

[0175] When a security key is changed, a new key is generated through the RRC of the terminal device 100 to re-establish the PDCP, thereby applying the new key to the PDCP.

[0176] Figure 8 This diagram illustrates an example of processing when the reset parameters with synchronization are included under the parameters for setting the MCG. The reset parameters with synchronization include settings for the target PCell, a new C-RNTI (Cell Radio Network Temporary Identifier), RACH settings, and a timer for handover failure detection. The terminal device 100 performs random access (RA) in the target PCell according to the settings, changing the current source PCell to the target PCell (S1).

[0177] Random access during handover

[0178] Handover random access can be either contention-free random access (CFRA) or contention-based random access. Contention-based random access (CBRA) also exists, which can be performed in two steps: a four-step process and a two-step process.

[0179] Figure 9 This is a diagram illustrating an example of a four-step random access handover process. Figure 9 (A) represents the 4-step CFRA-based handover process. Figure 9 (B) represents the 4-step CBRA-based switching process.

[0180] right Figure 9 The sequence of (A) is explained.

[0181] The base station device 200 sends an RRC reset message (S901) including reset parameters with synchronization to the terminal device 100.

[0182] When the reset parameters with synchronization include a 4-step CFRA setting and a reference signal with an RSRP (Reference Signal Received Power) of a threshold or higher exists in the reference signal specified in the 4-step CFRA setting, the terminal device 100 performs a 4-step CFRA-based handover. Furthermore, when the reset parameters with synchronization include a 2-step CFRA setting and a reference signal with an RSRP of a threshold or higher exists in the reference signal specified in the 2-step CFRA setting, the terminal device 100 performs a 2-step CFRA-based handover. Additionally, when the reset parameters with synchronization do not include either a 4-step CFRA setting or a 2-step CFRA setting, or when the reset parameters with synchronization include either a 4-step CFRA setting or a 2-step CFRA setting but no reference signal with an RSRP of a threshold or higher exists in the reference signal specified in either the 4-step CFRA setting or the 2-step CFRA setting, the terminal device 100 performs a 4-step or 2-step CFRA.

[0183] Terminal device 100 sends a random access preamble (RA preamble) to base station device 200 in the target PCell (S902).

[0184] When the base station device 200 receives the random access preamble (S902), it sends a random access response (RAresponse) (S903).

[0185] In the case of CFRA, the preamble is included in the CFRA setting, so contention resolution is not required. Therefore, the handover is successful when the terminal device 100 receives the random access response in the target PCell.

[0186] When a random access response is received (S903), the terminal device 100 sends an RRC reset completion message as a response message to the RRC reset message to the base station device 200 in the target serving cell (S904).

[0187] Next, for Figure 9 The sequence of (B) is explained.

[0188] The base station device 200 sends an RRC reset message (S905) to the terminal device 100, which includes reset parameters with synchronization. Since the reset parameters with synchronization do not include CFRA settings, the terminal device 100 performs a CBRA-based handover (step 2 or step 4).

[0189] Terminal device 100 sends a random access preamble (S906) to base station device 200 in the target PCell.

[0190] When the base station device 200 receives the random access preamble (S906), it sends a random access response (S907).

[0191] In the case of CBRA, since an arbitrary random access preamble is used, it may compete with random access preambles sent by other terminal devices. Therefore, when terminal device 100 receives a random access response (S907), the handover fails.

[0192] When the terminal device 100 receives the random access response (S907), it sends an RRC reset completion message to the base station device 200 in the target serving cell (S908).

[0193] When the base station device 200 receives the RRC reset completion message (S908), it sends a MAC CE indicating contention resolution to the terminal device 100 in the target serving cell (S909).

[0194] In the case of CBRA, when the terminal device 100 receives a MAC CE indicating contention resolution (S909), the handover is successful.

[0195] That is, in a 4-step CFRA-based handover, the RRC reset completion message (S904) is sent after the handover is successful, but in a 4-step CBRA-based handover, the RRC reset completion message (S908) is sent before the handover is successful.

[0196] Furthermore, if the uplink resources allocated by the terminal device 100 in step S907 are sufficiently large, in step S908, in addition to the RRC reset completion message, uplink data generated in the DRB can also be sent. That is, in a handover based on the 4-step CBRA, it is possible to send uplink data generated in the DRB before the handover is successful.

[0197] It should be noted that in the case of a two-step random access handover, in both CBRA and CFRA scenarios, the terminal device 100 sends the RRC reset completion message in step S904 after sending the random access preamble in step S902 and before receiving the random access response in step S903. That is, in a two-step random access handover, in either CFRA or CBRA scenario, the RRC reset completion message is sent before the handover is successful, thus it is possible to send uplink data generated in the DRB before the handover is successful.

[0198] Furthermore, in E-UTRA handovers, sometimes a handover without random access, i.e., a RACH-free handover, is performed. In a RACH-free handover, no random access is performed. The target serving cell sends an RRC reset completion message to the base station device 200, and the handover succeeds when the target serving cell receives a MAC CE indicating contention resolution from the base station device 200. That is, in a RACH-free handover, the RRC reset completion message is sent before the handover succeeds; therefore, it is possible to send uplink data generated in the DRB before the handover succeeds.

[0199] <Handling of Switching Failures>

[0200] If the terminal device 100 fails to complete the handover within a certain period of time after receiving the RRC reset message including the synchronized reset parameters, the handover fails. "Handover failure within a certain period of time" can mean that the handover failure detection timer, which is started upon receiving the RRC reset message including the synchronized reset parameters, expires before the handover is successfully completed.

[0201] In the event of a handover failure, the terminal device 100 will revert to the settings used in the source PCell and initiate the RRC connection re-establishment process. During the revert to the settings used in the source PCell, the values ​​of the state variables in each entity of each radio bearer will also revert to the values ​​used in the source (the values ​​immediately preceding the handover process).

[0202] During the re-establishment of the RRC connection, the terminal device 100 performs cell selection. If an NR cell is selected, it sends an RRC Reestablishment Request message (RRCReestablishmentRequest) to the base station device 200. The RRC Reestablishment Request message is sent via SRB0. Since SRB0 does not have a PDCP entity, it does not perform PDCP-based security processing for the RRC Reestablishment Request message. Furthermore, upon receiving a response message (RRCReestablishment) from the base station device 200 for the RRC Reestablishment Request message, the terminal device 200 updates its security key.

[0203] Conditional switching

[0204] Conditional Handover (CHO) is a handover performed by the terminal device 100 (initiative) when one or more handover execution conditions are met. The terminal device 100 receives an RRC reset message including conditional reset parameters from the base station device 200 and stores the conditional reset parameters. The conditional reset parameters include pairs of setting parameters for one or more PCell change destination candidates, including synchronization reset parameters, and execution condition parameters for performing a handover to that PCell change destination candidate. Execution condition parameters may include, for example, parameters related to measurement settings. Upon receiving the conditional reset parameters, the terminal device 100 begins cell measurement. If any PCell in the measured cell meets the execution conditions, the terminal device 100 applies the setting parameters of the PCell change destination candidate of the PCell that meets the execution conditions and performs a conditional handover to that PCell. After a successful conditional handover, the terminal device 100 releases the conditional reset parameters.

[0205] It should be noted that the conditional reset parameters may include a pair of settings on the SCG side, namely, setting parameters for the PSCell change destination candidate, and execution condition parameters for performing a change to the PSCell change destination candidate. When the terminal device 100 receives the conditional reset parameters from the SCG side, it begins to measure the execution conditions. If the measurement result meets the execution conditions, it performs a conditional PSCell change (CPC).

[0206] Conditional handover and unconditional handover (hereinafter sometimes simply referred to as handover) detect handover failures in the same way and perform post-handover-failure processing. When a conditional handover fails or during the re-establishment process of the RRC connection after a handover failure, if the selected cell is a candidate for the PCell change destination, the terminal device 100 can send an RRC reconfiguration complete message instead of an RRC re-establishment request message to the base station device 200 to attempt a handover and restore the RRC connection. It should be noted that when the cell selected by the terminal device 100 is a candidate for the PCell change destination, the case where an RRC reconfiguration complete message can be sent to the base station device 200 instead of an RRC re-establishment request message is limited to the case where a conditional reconfiguration attempt parameter (attemptCondReconfig) that allows this process is set in the terminal device 100.

[0207] <AS Security and Key Stream>

[0208] The processing of AS security is implemented in the PDCP entity of radio bearers other than SRB0 using security keys (encryption key, integrity protection key) generated by RRC. In AS security processing, there are ciphering and integrity protection, which are executed using the encryption key and integrity protection key respectively.

[0209] When the PDCP entity of each radio bearer receives a PDCP SDU from the upper layer, it performs AS security processing on the received PDCP SDU using an input called a key stream. The key stream is composed of four elements, for example, KEY, COUNT, BEARER, and DIRECTION.

[0210] KEY represents, for example, a security key.

[0211] COUNT is one of the state variables of the PDCP entity and represents, for example, a sequence number. The COUNT value is set to an initial value of "0" and increases by 1 each time a PDCP PDU is delivered to the lower layer. The maximum value of the COUNT value is, for example, the value obtained by subtracting 1 from 2 to the 32nd power, that is, '4294967295'.

[0212] BEARER represents, for example, the value of a radio bearer identifier. DIRECTION indicates whether it is an uplink or a downlink. In the case of an uplink, it is '0', and in the case of a downlink, it is '1'.

[0213] In terms of AS security, from a security perspective, reusing the key stream is prohibited. For example, in the terminal device 100, when transmitting data from a certain radio bearer, as long as the security key is not updated, it is prohibited to use the COUNT value used in the past in that radio bearer for AS security processing.

[0214] In addition, the definition of terms such as the key stream may vary slightly depending on the specification. In this embodiment, the key stream is described in terms of four elements: KEY, COUNT, BEARER, and DIRECTION.

[0215] [Embodiment]

[0216] Hereinafter, each embodiment will be described.

[0217] <L1 / L2 Initiated Mobility>

[0218] An example of the outline of L1 / L2 Initiated Mobility (LTM: L1 / L2 Triggered Mobility) in the current specification development will be described.

[0219] Figure 17 It is a figure showing an example of the parameters related to LTM included in the RRCReconfiguration message. It should be noted that in Figure 17 the parameters described in Figure 6 are omitted. In addition, it may also include parameters other than the parameter examples shown in Figure 17 In addition, the parameter names are just examples and may not be like this.

[0220] Format E2 is a parameter of RRC Reconfiguration. RRC Reconfiguration includes ltm-Config indicating the LTM setting. When LTM-Config is included in SetupRelease, ltm-Config makes a new setting or change to the LTM setting. When nothing is included in SetupRelease, ltm-Config means the solution of the LTM setting.

[0221] Format E21 contains parameters included in the LTM settings. ltm-ReferenceConfiguration is the reference configuration described later. ltm-CandidateToAddModList is a list of cell change destination candidate settings. That is, ltm-CandidateToAddModList contains one or more cell change destination candidate settings. ltm-ServingCellNoResetID is an identifier used by terminal device 100 to determine whether an L2 reset (Layer 2 reset) is required during cell handover as described later. The initial value of ltm-ServingCellNoResetID or ltm-ServingCellNoResetID can be the group identifier of the serving cell used by base station device 200 when sending an RRC reset message including the cell change destination candidate settings to terminal device 100 in step S1001 described later. ltm-ServingCellNoResetID can be stored in terminal device 100 as a variable representing the group identifier of the current serving cell. Additionally, ltm-ServingCellNoResetID is a parameter that must exist when setting up a new LTM configuration, and does not exist otherwise.

[0222] Format E211 contains parameters included in the cell change destination candidate settings. LTM-Candidate is the setting of the cell change destination candidate. ltm-CandidateId is an identifier or index uniquely identifying one or more cell change destination candidate settings within the terminal device 100. ltm-CandidateConfig is a parameter used to generate settings used in the cell handover destination (target). As described later, ltm-CandidateConfig can be a complete setting or a Δ setting. ltm-CandidateConfig can be composed of parameters included in the RRC reset message. ltm-NoResetID is an identifier used by the terminal device 100 to determine whether an L2 reset (Layer 2 reset) is required during the cell handover described later. ltm-NoResetID can be a group identifier of the cell of the cell change destination candidate. Additionally, L2 reset (Layer 2 reset) is an example of the first process. Additionally, LTM-Config is an example of the first parameter. ltm-ServingCellNoResetID is an example of the second parameter. ltm-NoResetID is an example of the third parameter.

[0223] Figure 10 This is a diagram representing an example of an LTM sequence.

[0224] The base station device 200 includes the setting of one or more cell change destination candidates (setting of target cell candidates) in the RRC reset message and sends it to the terminal device 100 (S1001).

[0225] When terminal device 100 receives an RRC reset message (S1001), it stores the LTM setting information (including the setting of the cell change destination candidate) contained in the received message. In addition, terminal device 100 may store the value of ltm-ServingCellNoResetID contained in the LTM setting in a variable representing the group identifier of the current serving cell.

[0226] Furthermore, cell change destination candidates can be, for example, only PCells or include SCells. The settings for each cell change destination candidate only need to be uniquely determined within the terminal device 100 using an index (ltm-CandidateId). Moreover, the settings for cell change destination candidates do not include parameters indicating security key updates. That is, the LTM-based security key is not updated. Additionally, the settings for cell change destination candidates may include the same parameters as the reset parameters with synchronization.

[0227] Alternatively, the terminal device 100 may retain the cell change destination candidate settings received and stored in step S1001 after a successful cell handover, without releasing them. In this case, the retained cell change destination candidate settings can also be used for subsequent cell handovers. However, when retaining the cell change destination candidate settings for subsequent cell handovers, it is sometimes impossible to set the cell change destination candidate settings to a Δ setting (applying a Δ setting to the source settings to generate the target cell settings). This phenomenon occurs because the source settings differ depending on the order in which the cells are changed through the cell handover.

[0228] Therefore, in step S1001, the RRC reset message sometimes includes a reference setting as part of the cell handover destination candidate's settings, in addition to the settings of the cell handover destination candidate. The reference setting, for example, is used to make the settings used in the cell handover destination (target) complete. When the RRC reset message includes a reference setting, the settings of each cell handover destination candidate included in the RRC reset message can be a differential setting (Δ setting) with respect to the reference setting. That is, the terminal device 100 can generate the settings used in the cell handover destination (target), i.e., the complete settings used in the cell handover destination, based on the reference setting and the cell handover destination candidate's settings (Δ setting). For example, when a cell handover signal to cell X, which is a cell handover destination candidate, is received from the base station device 200 in step S1002 (described later), the terminal device 100 generates the settings for cell X by applying the settings of cell X to the reference setting.

[0229] Furthermore, in step S1001, the RRC reset message sometimes does not include reference settings. When the RRC reset message does not include reference settings, the settings of each cell change destination candidate included in the RRC reset message are, for example, complete settings. That is, the terminal device 100 can generate the settings used in the cell change destination (target) by replacing the settings used in the current cell with the settings of the cell change destination candidate. For example, when the terminal device 100 receives a cell handover signal from the base station device 200 to cell X, which is a cell change destination candidate, in step S1002 (described later), it replaces the settings of the current cell with the settings of cell X, thereby generating the settings used in cell X. However, when the settings of the cell change destination candidate are set to complete settings, a portion of the settings may be omitted. A portion of the settings may include, for example, settings that do not change due to cell handover (fixed settings). Settings that do not change due to cell handover (fixed settings) may include, for example, some or all of the radio bearer settings. In this case, when the terminal device 100 receives a cell handover signal from the base station device 200 to cell X, which is a candidate for cell change destination, it replaces the current cell settings with the cell X settings, except for the fixed settings, thereby generating the settings used in cell X.

[0230] It should be noted that, regardless of whether the RRC reset message includes or does not include the reference settings, the terminal device 100 can prevent some or all of the values ​​of state variables, timers, etc. used in each entity (SDAP entity, PDCP entity, RLC entity, MAC entity, etc.) from returning to their initial state when generating settings used in the cell handover destination. Furthermore, the terminal device 100 can retain some or all of the buffers in each entity. In other words, the terminal device 100 can maintain some or all of the values ​​of state variables, timers, etc. used in each entity. Additionally, the terminal device 100 can retain some or all of the buffers in each entity.

[0231] The base station device 200 sends a cell handover signal to the terminal device 100 for switching the serving cell of the terminal device 100 from the current serving cell to one of the cell change destination candidates (S1002). In addition, the cell handover signal is an example of the first signal.

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

[0233] The cell handover signal contains at least an index (ltm-CandidateId). Terminal device 100 applies the cell change destination (denoted as cell X) specified by the received cell handover signal. It should be noted that cell X can consist of only PCells, or it can consist of PCells and one or more SCells.

[0234] Terminal device 100 performs a 4-step or 2-step CFRA or CBRA (S1003) between cell X and base station device 200, depending on the cell X settings. Furthermore, if the cell X settings include parameters indicating a no-RACH cell handover, the processing in step S1003 is not performed. Additionally, if the ltm-NoResetID of cell X is the same as the ltm-ServingCellNoResetID or the variable representing the group identifier of the current serving cell, terminal device 100 does not perform an L2 reset. Furthermore, if the ltm-NoResetID of cell X is different from the ltm-ServingCellNoResetID or the variable representing the group identifier of the current serving cell, terminal device 100 performs an L2 reset and overwrites the ltm-ServingCellNoResetID or the variable representing the group identifier of the current serving cell with the ltm-NoResetID of cell X. An L2 reset can be, for example, RLC re-establishment. Another example of an L2 reset is PDCP data recovery.

[0235] Terminal device 100 sends a notification indicating a cell handover to base station device 200 in cell X (S1004). This notification is equivalent to an RRC reset completion message during handover or conditional handover. The notification indicating a cell handover can be an RRC message such as an RRC reset completion message, or it can be a MAC CE. Alternatively, the notification can also be a physical signal such as UCI.

[0236] Furthermore, the notification indicating a cell handover may include at least the identifier of cell X in terminal device 100. Additionally, if a two-step CFRA or CFRA is performed in step S1003, the notification indicating a cell handover is sent before receiving the random access response in step S1003. Furthermore, uplink data generated in the DRB may also be sent along with the notification indicating a cell handover.

[0237] If a 4-step or 2-step CBRA is performed in step S1003, or if a cell handover without RACH is performed, the base station device 200 sends a contention resolution signal to the terminal device 100 (S1005).

[0238] Terminal device 100 receives a contention resolution signal in cell X, for example (S1005). The contention resolution signal may include at least an identifier in cell X of terminal device 100.

[0239] The timing of a successful cell handover can be the same as the timing of a successful handover in a handover or conditional handover. That is, in the case of a cell handover using 4-step or 2-step CFRA, the handover is successful at the moment the random access response is received. Furthermore, in the case of a cell handover using 4-step or 2-step CBRA or a cell handover without RACH, the handover is successful at the moment contention resolution occurs. When the timing of a successful cell handover is the same as the timing of a successful handover in a handover or conditional handover, similarly to handovers using 4-step CFRA, in a cell handover using 4-step CFRA, no notification indicating a cell handover has been sent, nor uplink data generated in the DRB, is sent before the handover is successful. However, in the case of a cell handover using 4-step CBRA, a cell handover using 2-step CFRA or CBRA, and a cell handover without RACH, a notification indicating a cell handover has been sent before the handover is successful, and uplink data generated in the DRB is also sent simultaneously.

[0240] Additionally, the terminal device 100 may perform downlink synchronization and / or uplink synchronization with one or more cell change destination candidates during the period from after executing step S1001 to before sending the cell handover signal in step S1002. During uplink synchronization, the base station device 200 may determine the Timing Advance (TA) relative to one or more cell change destination candidates for the terminal device 100. Uplink synchronization may also be performed by the base station device 200 instructing the terminal device 100 to send a random access preamble. The base station device 200 may instruct the terminal device 100 to send different random access preambles for one or more cell change destination candidates, or it may instruct the terminal device 100 to send a common random access preamble for a group of multiple cell change destination candidates. The TA determined by the base station device 200 may be sent to the terminal device 100 using a Random Access Response (RAR) or the cell handover signal from step S1002. Thus, sometimes uplink synchronization is performed between the time the terminal device 100 executes step S1001 and the time the cell handover signal is sent in step S1002, which is called early TA determination or early TA acquisition.

[0241] Furthermore, cell handover can also be referred to as LTM. Additionally, cell handover can be referred to by other terms indicating LTM-based cell handover. In the future, cell handover and cell change may sometimes be treated as synonymous terms.

[0242] <Cell handover failure handling>

[0243] In the event of a cell handover failure, the RRC connection re-establishment process can be performed in the same manner as a handover failure process or a conditional handover failure process.

[0244] Figure 11 This is a diagram illustrating an example of the sequence for cell handover failure detection and cell handover failure handling. Figure 11 The processing of steps 1001 and 1002 in the process and Figure 10 The processing of steps 1001 and 1002 is the same.

[0245] When the terminal device 100 receives a cell handover signal (S1002), it starts a timer for detecting cell handover failure (S1101) and begins cell handover processing (not shown) to the cell specified by the received cell handover signal (let's call it cell X).

[0246] When a cell handover is successful before the timer expires, the terminal device 100 stops the timer (not shown). On the other hand, when the timer expires, the terminal device 100 detects that the cell handover to cell X has failed (S1102).

[0247] When a cell handover failure is detected (S1102), the terminal device 100 performs cell handover failure processing (S1103). The terminal device 100 can return to the settings used in the source PCell during the cell handover failure processing to perform the RRC connection re-establishment process.

[0248] <Keystream reuse issues in cell handover failure handling>

[0249] The following scheme is proposed in LTM: In the process of re-establishing the RRC connection during the cell handover failure handling, if the selected cell is one of the cell change destination candidates, the RRC connection is restored in the same way as in the case of conditional handover, that is, instead of sending the RRC re-establishment request message in the selected cell, the cell handover is performed to the selected cell (e.g., non-patent document 10, non-patent document 11).

[0250] However, during the re-establishment of an RRC connection following a failed 4-step CBRA cell handover, a failed 2-step CFRA or CBRA cell handover, or a failed RACH-free cell handover, if the selected cell is one of the cell change destination candidates, performing a cell handover in the selected cell instead of sending an RRC re-establishment request message may cause key stream reuse issues.

[0251] As described above, in cell handovers using 4-step CBRA, 2-step CFRA or CBRA, and RACH-free cell handovers, uplink data is sometimes sent along with a notification indicating that the cell has been handed over before the handover is successful. Assuming that the notification indicating the cell handover is an RRC message sent from an SRB other than SRB0 (e.g., SRB1), the RRC message undergoes security processing within the PDCP entity of SRB1 and is sent as a PDCP data PDU through the lower layer. The COUNT value for security processing within the PDCP entity of this RRC message is, for example, set to n.

[0252] Furthermore, when uplink data is sent from a DRB (denoted as DRB1) along with a notification indicating a cell handover, the uplink data undergoes security processing within the PDCP entity of DRB1 and is transmitted as a PDCP data PDU through the lower layer. The COUNT value used in the security processing of this uplink data (within the PDCP entity of this uplink data) is, for example, m.

[0253] In the event of a cell handover failure, terminal device 100 reverts to the settings used in the source PCell and initiates the RRC connection re-establishment process. Upon reverting to the settings used in the source PCell, the values ​​of the state variables in each entity of each radio bearer also revert to the values ​​used in the source, thus the COUNT value returns to the state before receiving the cell handover signal. During the RRC connection re-establishment process, if the selected cell is one of the cell change destination candidates and a cell handover is performed on the selected cell, terminal device 100 sends an RRC message in that cell as a notification of the cell handover. When sending this RRC message, the COUNT value is again 'n' in the security processing of the PDCP entity in SRB1. Furthermore, when the initial uplink message is sent from DRB1 in that cell, the COUNT value is again 'm' in the security processing of the PDCP entity in DRB1. In LTM cell handovers, no security key change is performed; the same security key and the same COUNT value are used for the same direction (uplink) of the same radio bearer. That is, a key stream reuse problem may occur.

[0254] <Cell handover failure handling to avoid key stream reuse issues 1>

[0255] Figure 12 This diagram illustrates an example of a method for handling a first cell handover failure. The method for handling a first cell handover failure is as follows: During the re-establishment of the RRC connection in the cell handover failure handling process, if the terminal device 100 selects an NR cell, regardless of whether the NR cell is one of the cell change destination candidates, it sends an RRC re-establishment request message to the base station device 200 in the selected NR cell.

[0256] Terminal device 100 detects that the cell handover to cell X has failed (S1102).

[0257] Next, the terminal device 100 returns the settings to the settings used in the source PCell and performs the RRC connection re-establishment process (S1201). When returning to the settings used in the source PCell, the values ​​of the state variables in each entity of each radio bearer also return to the values ​​used in the source. Figure 11 The value received during cell handover signal reception in step S1002, or the value received immediately prior to that reception. It should be noted that the terminal device 100 can release the stored cell change destination candidate settings during the RRC connection re-establishment process. In the case of releasing the stored cell change destination candidate settings, this release process can be performed before the processing in step S1202 described later.

[0258] During the re-establishment of the RRC connection, the terminal device 100 performs cell selection, for example, selecting an NR cell. The terminal device 100 sends an RRC re-establishment request message to the base station device 200 in the selected NR cell (S1202).

[0259] It should be noted that during the re-establishment of the RRC connection, if the selected cell is a RAT other than NR, the terminal device 100 switches to RRC idle mode. Furthermore, if the terminal device 100 is unable to select a cell within a certain period of time, it switches to RRC idle mode.

[0260] <Cell handover failure handling to avoid key stream reuse issues 2>

[0261] Figure 13 This diagram illustrates an example of a second cell handover failure handling method. The second cell handover failure handling method is as follows: During the re-establishment of the RRC connection in the cell handover failure handling process, if the cell selected by the terminal device 100 is one of the cells that meets the second condition and at least meets the first condition, the cell handover process to the selected cell is performed by applying the cell change destination candidate setting of the selected cell.

[0262] The second condition includes, for example, that the cell is a candidate cell change destination stored in the terminal device 100. Furthermore, the second condition includes, for example, that the cell is a cell that allows the restoration of RRC connections after a cell handover failure.

[0263] Cells that allow the restoration of RRC connections after a cell handover failure include, for example, cells that are cell change destination candidates stored in terminal device 100 and belong to the same group as the cell that failed the handover (e.g., cell X). The determination of whether a cell belongs to the same group as cell X is made, for example, by using a group identifier pre-set in the cell change destination candidate settings. The group identifier can be renamed as a no-reset identifier.

[0264] Furthermore, the cell that allows the restoration of RRC connection after a cell handover failure is, for example, a cell change destination candidate stored in the terminal device 100, and includes a cell whose settings in the cell change destination candidate include information indicating that the restoration of RRC connection after a cell handover failure is allowed.

[0265] Furthermore, if the cell selected by the terminal device 100 is one of the cells that meets the second condition, and at least the first condition is met, the process of applying the cell change destination candidate setting of the selected cell to perform cell handover processing to the selected cell can also be performed if at least the first parameter is set in the terminal device 100.

[0266] Terminal device 100 detects that the cell handover to cell X has failed (S1102).

[0267] Next, the terminal device 100 returns the settings to the settings of the source PCell and performs the RRC connection re-establishment process (S1301). When the terminal device 100 returns to the settings used in the source PCell, the values ​​of the state variables in each entity of each radio bearer also return to the values ​​used in the source. Figure 11 The value of the cell handover signal received in step S1002 or the value immediately preceding the reception.

[0268] During the re-establishment of the RRC connection, the terminal device 100 performs cell selection and processing corresponding to the selected cell and the first condition (S1302).

[0269] The first condition is, for example, receiving... Figure 11 In step S1002, during the cell handover process to cell X after the cell handover signal, a 4-step CFRA cell handover process is performed, that is, the setting of the cell change destination candidate for cell X includes a 4-step CFRA setting.

[0270] Furthermore, the first condition could be, for example, upon receiving... Figure 11 In step S1002, during the cell handover process to cell X after the cell handover signal, only the CFRA-based cell handover process based on step 4 was performed. That is, the setting of the cell change destination candidate for cell X includes the CFRA setting of step 4, and in the initial random access resource selection, there is a reference signal with RSRP above the threshold.

[0271] Furthermore, the first condition could also be, for example, upon receiving... Figure 11 In step S1002, during the cell handover process to cell X after the cell handover signal, a 4-step CFRA-based cell handover process is performed. That is, the setting of the cell change destination candidate for cell X includes a 4-step CFRA setting, and it is the initial cell selection after the cell handover failure detection in step S1102.

[0272] Furthermore, the first condition could also be, for example, upon receiving... Figure 11 In step S1002, during the cell handover process to cell X after the cell handover signal, only the CFRA-based cell handover process based on step 4 was performed. That is, the setting of the cell change destination candidate for cell X includes the CFRA setting of step 4. In the initial random access resource selection, there is a reference signal with RSRP above the threshold, and it is the initial cell selection after the cell handover failure detection in step S1102.

[0273] It should be noted that a cell handover process that only performs a 4-step CFRA can be renamed as a cell handover process that performs a 4-step CFRA and does not send a MAC PDU to the Msg3 (message 3) buffer. Furthermore, a cell handover process that only performs a 4-step CFRA can also be renamed as a statement indicating that a 4-step or 2-step CBRA was not performed prior to the 4-step CFRA cell handover process.

[0274] Moreover, the first condition could be, for example, upon receiving... Figure 11 During the period from the cell handover signal in step S1002 to the detection of cell handover failure in step S1102, no PDCP data PDU is sent from the terminal device 100 through the lower layer, that is, no RRC message is sent from the SRB other than SRB0 and / or no uplink data is sent from the DRB.

[0275] Moreover, the first condition could be, for example, upon receiving... Figure 11 During the period from the cell handover signal in step S1002 to the detection of cell handover failure in step S1102, no PDCP data PDU is sent from the terminal device 100 through the lower layer, that is, no RRC message is sent from the SRB other than SRB0 and / or no uplink data is sent from the DRB, and this is the initial cell selection after the cell handover failure detection in step S1102.

[0276] Moreover, the first condition could be, for example, upon receiving... Figure 11 During the period from the cell handover signal in step S1002 to the detection of cell handover failure in step S1102, the terminal device 100 only sends a second signal.

[0277] Moreover, the first condition could be, for example, upon receiving... Figure 11 During the period from the cell handover signal in step S1002 to the detection of cell handover failure in step S1102, the terminal device 100 sends only a second signal, which is the initial cell selection after the cell handover failure detection in step S1102.

[0278] The second signal is Figure 10 The notification sent in step S1004. The second signal could be, for example, a MAC CE. Alternatively, the second signal could be a physical layer signal.

[0279] Furthermore, sending only the second signal from the terminal device 100 may mean that no MAC SDU is sent from the terminal device 100.

[0280] During the re-establishment of the RRC connection, the terminal device 100 performs cell selection. The terminal device 100 selects an NR cell, and if this NR cell is one of the cells satisfying the second condition (e.g., cell Y) and the first condition is also met, the terminal device 100 applies the cell change destination candidate setting to cell Y and performs a cell handover process to cell Y. Furthermore, the cell handover process to cell Y may also be limited to cases where a first parameter is set in the terminal device 100. The first parameter, for example, is a parameter indicating that if the cell selected in the cell handover failure process is one of the cells satisfying the second condition and the first condition is also met, a cell handover process will be performed on that cell.

[0281] Furthermore, during the re-establishment of the RRC connection, if the selected cell is an NR cell and meets some or all of the following conditions A to C, the terminal device 100 sends an RRC re-establishment request message to the base station device 200 in the selected cell. At this time, the terminal device 100 may release the stored cell change destination candidate settings before sending the RRC re-establishment request message to the base station device 200.

[0282] Condition A: The selected community is not one of the communities that meet the second condition.

[0283] Condition B: The first condition is not met.

[0284] Condition C: The first parameter is not set.

[0285] Furthermore, during the re-establishment of the RRC connection, if the selected cell is a RAT cell other than NR or if the cell selection is not performed within the specified time, the terminal device 100 switches to RRC idle mode.

[0286] It should be noted that the terminal device 100 can be set or designed (hereinafter, sometimes referred to as transmission prohibition setting) to... Figure 11 In step S1002, no PDCP data PDU is transmitted during the period from receiving the cell handover signal to detecting the cell handover failure in step S1102. The transmission prohibition setting is, for example, setting or designing to use only the 4-step CFRA in random access during cell handover processing. Furthermore, setting or designing to use only the 4-step CFRA in random access during cell handover processing means including a 4-step CFRA setting in the settings for each cell change destination candidate.

[0287] In addition, sending is prohibited, for example, in Figure 10The notification in step S1004 uses MAC CE or physical layer signaling, and in step S1004, uplink data generated through DRB, etc., is not sent. Not sending uplink data generated through DRB, etc., means, for example, not sending MAC SDU.

[0288] When the terminal device 100 has set a transmission prohibition setting, the process in step S1302 is as follows.

[0289] During the re-establishment of the RRC connection, the terminal device 100 performs cell selection. When the selected cell is an NR cell and is one of the cells that meet the second condition (e.g., cell Y), the terminal device 100 applies the cell change destination candidate setting for cell Y and performs cell handover processing to cell Y. Furthermore, the cell handover processing to cell Y may be limited to cases where the second parameter is set in the terminal device 100.

[0290] For example, when the cell selected in the cell handover failure handling is one of the cells that the terminal device 100 meets the second condition, the second parameter is a parameter indicating that cell handover handling is performed on the cell.

[0291] In addition, the second parameter may be, for example, a parameter indicating that if the cell selected in the cell handover failure processing is one of the cells that meets the second condition and is the initial cell selection after the cell handover failure detection in step S1102, the cell handover processing is performed on that cell.

[0292] Furthermore, when the terminal device 100 has a transmission prohibition setting, during the re-establishment of the RRC connection, if the cell selected by the terminal device 100 is an NR cell and meets some or all of the following conditions D and E, the terminal device 100 sends an RRC re-establishment request message to the base station device 200 in the selected cell. At this time, before sending the RRC re-establishment request message to the base station device 200, the terminal device 100 releases the stored cell change destination candidate settings.

[0293] Condition D: The selected community is not one of the communities that meet the second condition.

[0294] Condition E: The first parameter is not set.

[0295] Furthermore, during the re-establishment of the RRC connection, if the selected cell is a RAT cell other than the NR, or if cell selection is not performed within the specified time, the terminal device 100 switches to RRC idle mode.

[0296] <Cell handover failure handling to avoid key stream reuse issues 3>

[0297] Figure 14 This diagram illustrates an example of a third-cell handover failure handling method. The third-cell handover failure method is as follows: After a cell handover failure is detected, when the terminal device 100 returns to the settings of the source PCell, it retains the values ​​of some or all of the state variables. During the re-establishment of the RRC connection, if the cell selected by the terminal device 100 is an NR cell and is one of the cells that meet the second condition, the setting of the cell change destination candidate for the selected cell is applied, and a cell handover process is performed to the selected cell. It should be noted that the process of retaining the values ​​of some or all of the state variables when the terminal device 100 returns to the settings of the source PCell after the cell handover failure is detected is performed, for example, when at least the second parameter is set in the terminal device 100. Furthermore, during the re-establishment of the RRC connection, if the cell selected by the terminal device 100 is one of the cells that meet the second condition, the process of applying the setting of the cell change destination candidate for the selected cell and performing a cell handover to the selected cell is performed, for example, when at least the second parameter is set in the terminal device 100. It should be noted that when the terminal device 100 sends an RRC re-establishment request message to the base station device 200 in the selected cell, it returns the maintained state variables to the settings of the source PCell before sending the RRC re-establishment request message.

[0298] Terminal device 100 detects that the cell handover to cell X has failed (S1102).

[0299] Next, the terminal device 100 returns the settings to the settings used in the source PCell and performs the RRC connection re-establishment process (S1401). When returning to the settings used in the source PCell, some or all of the state variables of each entity in each radio bearer are not returned to the values ​​used in the source PCell. Figure 11 The state variables maintained include, for example, the COUNT value in the PDCP entity. Furthermore, when returning to the settings used in the source PCell, the process of maintaining some or all of the state variables in each entity of each radio bearer is performed, for example, if a second parameter is set in the terminal device 100.

[0300] Next, during the re-establishment of the RRC connection, the terminal device 100 performs cell selection and performs processing corresponding to the selected cell and the first condition (step S1402).

[0301] In terminal device 100, when the selected cell is an NR cell and is one of the cells that meet the second condition (e.g., cell Y), terminal device 100 applies the cell change destination candidate setting for cell Y and performs cell handover processing to cell Y. For example, when the second parameter is set in terminal device 100, processing for cell Y is performed.

[0302] For example, when the cell selected in the cell handover failure handling is one of the cells that the terminal device 100 meets the second condition, the second parameter is a parameter indicating that cell handover handling is performed on the cell.

[0303] In addition, the second parameter may be, for example, a parameter indicating that if the cell selected in the cell handover failure processing is one of the cells that meets the second condition and is the initial cell selection after the cell handover failure detection in step S1102, the cell handover processing is performed on that cell.

[0304] It should be noted that the values ​​of some or all of the state variables in each entity of each radio bearer are, for example, the values ​​of some or all of the state variables in each entity of each DRB.

[0305] Furthermore, during the re-establishment of the RRC connection, if the selected cell is an NR cell and meets some or all of the following conditions F and G, the terminal device 100 sends an RRC re-establishment request message to the base station device 200 in the selected cell. At this time, for example, before sending the RRC re-establishment request message to the base station device 200, the terminal device 100 releases the stored cell change destination candidate settings. Additionally, at this time, the terminal device 100 may, for example, return the value of the state variable held in step S1401 to the value used in the source PCell before sending the RRC re-establishment request message to the base station device 200. Figure 11 The value of the cell handover signal received in step S1002, or the value immediately preceding the reception. Before sending the RRC re-establishment request message to the base station device 200, the process of returning the value of the state variable held in step S1401 to the value used in the source is performed, for example, if a second parameter is set.

[0306] Condition F: The selected cell is not one of the cells that meets the second condition.

[0307] Condition G: No second parameter is set.

[0308] Furthermore, during the re-establishment of the RRC connection, if the selected cell is a RAT cell other than the NR, or if cell selection is not performed within the specified time, the terminal device 100 switches to RRC idle mode.

[0309] <Cell handover failure handling to avoid key stream reuse issues 4>

[0310] Figure 15 This diagram illustrates an example of how to handle a handover failure in the fourth cell.

[0311] Terminal device 100 detects that the cell handover to cell X has failed (S1102).

[0312] Next, the terminal device 100 performs a cell selection process (S1501). The terminal device 100 may stop some or all of the timers in operation before performing the cell selection process. Furthermore, the terminal device 100 may start a timer to limit the time of the cell selection process to a certain duration. The terminal device 100 may perform the cell selection process using the settings of the terminal device 100 at the time of cell handover failure, instead of returning the settings to the settings of the source PCell.

[0313] Furthermore, during the cell selection process, the terminal device 100 retains some or all of the values ​​of state variables, timers, etc. in each entity, as well as some or all of the buffers in each entity, when returning the settings to the settings of the source PCell.

[0314] Without returning the settings to the source PCell settings, the terminal device 100 performs the cell selection process using the settings of the terminal device 100 at the time of cell handover failure. Furthermore, when returning the settings to the source PCell settings, the terminal device 100 retains some or all of the values ​​of state variables, timers, etc., as well as some or all of the buffers in each entity, during the cell selection process. This cell selection process is performed, for example, when either or both of the following conditions are met: a parameter indicating LTM is set in the terminal device 100, or at least a second parameter is set in the terminal device 100.

[0315] Furthermore, the cell selection process can be performed as part of the RRC connection re-establishment process, or it can be performed separately from the RRC connection re-establishment process. Additionally, if at least the second parameter is not set, the terminal device 100 may skip step S1602 (described later) and instead perform steps S1604 and S1605.

[0316] Next, the terminal device 100 performs processing corresponding to the selected cell (S1502).

[0317] Figure 16 This diagram illustrates an example of the processing corresponding to the selected cell in step S1502. The terminal device 100 begins the processing corresponding to the selected cell (S1601).

[0318] Terminal device 100 determines whether the selected cell is one of the cells that meets the second condition (S1602).

[0319] If the selected cell is one of the cells that meet the second condition (e.g., cell Y) ("Yes"), the terminal device 100 performs a cell handover to the selected cell (cell Y) (S1603). The process of performing a cell handover to the selected cell if the selected cell is one of the cells that meet the second condition may be performed if either or both of the following conditions are met: the terminal device 100 has set a parameter indicating LTM, and the terminal device 100 has at least set the second parameter.

[0320] The second parameter, for example, indicates the parameter for performing cell handover processing on a cell when the cell selected in the cell handover failure handling is one of the cells that meets the second condition.

[0321] In addition, the second parameter may be, for example, a parameter indicating that the cell selected in the cell handover failure processing is one of the cells that meets the second condition, and is the initial cell selection after the cell handover failure detection in step S1102, and that cell handover processing is performed on that cell.

[0322] When performing a cell handover to cell Y or before performing a handover, the terminal device 100 may also release a portion of its owned information. This owned information may include, for example, information obtained through early TA determination or early TA acquisition. Information obtained through early TA determination or early TA acquisition may include, for example, information containing TA and information about the value of the TA timer for that TA.

[0323] When performing a cell handover to cell Y, or before performing the handover, terminal device 100 can generate cell Y settings for cell Y. That is, if a reference setting is stored, terminal device 100 generates the settings used in cell Y by applying the stored cell Y settings to the reference setting. Furthermore, if no reference setting is stored, or if the settings of the cell change destination candidate to be stored are complete settings, terminal device 100 can generate the settings used in cell Y by replacing the settings used in the current cell with the settings of cell Y to be stored, or by replacing the settings used in the current cell with the settings of cell Y to be stored, excluding fixed settings. When generating settings used in the cell handover destination, terminal device 100 sometimes does not return 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 state. That is, terminal device 100 may retain some or all of the values ​​of state variables, timers, etc., used in each entity. Furthermore, when generating settings used in the cell handover destination, terminal device 100 sometimes does not 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 can retain some or all of the buffers in each entity.

[0324] Furthermore, when performing a cell handover to cell Y, terminal device 100 can perform a 4-step or 2-step CFRA, a 4-step or 2-step CBRA, or a RACH-free cell handover. Terminal device 100 can also determine which cell handover method to use (4-step or 2-step CFRA, 4-step or 2-step CBRA, or RACH-free) based on the settings of cell Y. Additionally, when performing a cell handover to cell Y, terminal device 100 can perform a RACH-free cell handover if a third condition is met. The third condition includes, for example, the terminal device 100 having a valid TA for cell Y. A valid TA includes, for example, a TA timer for that TA that has not expired.

[0325] When or after a cell handover to cell Y, terminal device 100 sends a notification indicating that a cell handover has occurred. Figure 10 (Processing step S1004). The notification indicating a cell handover may include information indicating the restoration of the RRC connection after a cell handover failure. Furthermore, information related to the uplink resources used to send the notification indicating a cell handover may be included, for example, in the RAR, or dynamically allocated by the base station device 200 after the cell handover, or included in the cell Y settings.

[0326] In step S1602, the terminal device 100 determines whether the selected cell is one of the cells that meet the second condition. If the selected cell is not one of the cells that meet the second condition ("No"), the settings are returned to the settings in the source PCell (step S1604). At this time, the terminal device 100 can also return the values ​​of state variables, timers, etc. used in each entity to the values ​​specified in the source PCell.

[0327] Next, the terminal device 100 re-establishes the RRC connection or transitions to RRC idle mode (step S1605). For example, when the selected cell is an NR cell, the terminal device 100 re-establishes the RRC connection. When the selected cell is an NR cell, the terminal device 100 sends an RRC re-establishment request message to the base station device 200 in the selected cell. At this time, before sending the RRC re-establishment request message to the base station device 200, the terminal device 100, for example, releases the stored cell change destination candidate settings. Furthermore, for example, if the selected cell is a RAT cell other than NR, or if cell selection fails within a predetermined time, the terminal device 100 transitions to RRC idle mode.

[0328] The processing in step S1605 is performed, for example, as part of the RRC connection re-establishment process. It should be noted that if the cell selection processing in step S1501 is performed separately from the RRC connection re-establishment process, the terminal device 100 may omit the cell selection process during the RRC connection re-establishment process. Furthermore, the terminal device 100 may reset the MAC address and suspend some or all radio bearers before performing the processing in step S1605. The suspended radio bearers may at least exclude SRB0. Additionally, the terminal device 100 may release some or all of its owned information before performing the processing in step S1605. Furthermore, the terminal device 100 may stop some or all of the timers in operation before performing the processing in step S1605.

[0329] Therefore, in the cell handover failure handling of the terminal device 100, the terminal device 100 and the base station device 200 can avoid the problem of key stream reuse and conduct secure communication.

[0330] Additionally, in handling cell handover failures, the selected cell may be one of the cell change destination candidates stored in the terminal device 100, for example, in the case where the selected cell is one of the PCells of the cell change destination candidates stored in the terminal device 100. Furthermore, the selected cell may be one of the cell change destination candidates stored in the terminal device 100, for example, in the case where the selected cell is... Figure 11The case of one of the PCells included in the setting of the cell change destination candidate received in step S1001. That is, in the cell handover failure handling, even if the selected cell is one of the cells included in the cell change destination candidates stored in the terminal device 100, when the selected cell is an SCell, it may not be regarded as one of the cell change destination candidates stored in the terminal device 100.

[0331] Similarly, in the cell handover failure handling, the selected cell is one of the cells that satisfy the second condition. For example, it includes the case where the selected cell is one of the PCells that satisfy the second condition.

[0332] In addition, this embodiment has described the handling after a cell handover failure based on LTM, but it can also be applied to other technologies. For example, it can also be applied to the handling after a handover (reconfiguration with synchronization) failure in NTN (Non Terrestrial Network).

[0333] In addition, this embodiment has described the handling after a cell handover failure based on LTM, but it can also be applied to the handling after a handover (reconfiguration with synchronization) failure. That is, the signal received by the terminal device 100 from the base station device in step S1002 can be an RRC reconfiguration message including reconfiguration parameters with synchronization. In this case, the handover target may not be a cell change destination candidate stored in the terminal device 100. In addition, in this case, the cell handover failure detection in step S1102 can be a handover failure detection. The terminal device 100 can perform the cell handover failure handling disclosed in this embodiment after the handover failure detection. In addition, when the terminal device 100 performs the cell handover failure handling disclosed in this embodiment after the handover failure detection, a part of the cell handover failure handling can be performed when the RRC reconfiguration message including reconfiguration parameters with synchronization does not include a parameter indicating master key update. A part of the cell handover failure handling is, for example, the handling of maintaining the value of part or all of the state variables when returning the setting of the terminal device 100 to the setting of the source PCell.

[0334] In addition, 4 cell handover failure handling methods are disclosed in this embodiment, but the cell handover failure handling method to be applied can be selected according to whether it is the handling after a cell handover failure based on LTM or the handling after a handover (reconfiguration with synchronization) failure. For example, cell handover failure 4 is applied in the case of the handling after a cell handover failure based on LTM, and cell handover failure 1 or cell handover failure 2 or cell failure handling 3 is applied in the case of the handling after a handover (reconfiguration with synchronization) failure.

[0335] <Handover Processing in LTM Setting>

[0336] When LTM settings are configured in terminal device 100, i.e., when terminal device 100 stores settings for at least one cell change destination candidate, base station device 200 may also send a handover (reset with synchronization) instruction to terminal device 100, i.e., an RRC reset message containing reset parameters with synchronization. However, conventional RRC reset messages containing reset parameters with synchronization do not include the group identifier of the target PCell. Therefore, the following problem exists: terminal device 100 cannot determine whether the ltm-ServingCellNoResetID or the variable representing the group identifier of the current serving cell has changed due to handover. Therefore, it is required to avoid handover processing in the LTM settings of this issue.

[0337] Figure 18 This diagram illustrates a first example of handover processing in LTM settings. Terminal device 100 receives an RRC reset message including reset parameters with synchronization from base station device 200 (S1800). Upon receiving the RRC reset message including the reset parameters with synchronization, terminal device 100 checks whether an LTM setting is configured in terminal device 100. If an LTM setting is configured in terminal device 100, the LTM setting is released (S1801). Next, terminal device 100 performs a reset with synchronization (S1802). It should be noted that in this first example of handover processing in LTM settings, the RRC reset message including reset parameters with synchronization may include LTM settings, which include settings for at least one cell change destination candidate. In this case, the LTM setting is a new LTM setting. Furthermore, the reset parameters with synchronization are an example of a fourth parameter.

[0338] Figure 19This diagram illustrates a second example of the handover process in LTM settings. Terminal device 100 receives an RRC reset message including LTM settings from base station device 200 (S1900). It should be noted that the RRC reset message including LTM settings may include reset parameters with synchronization. Upon receiving the RRC reset message including LTM settings, terminal device 100 reconfigures or updates the LTM settings according to the LTM settings (step S1901). For example, if the received LTM settings include ltm-ServingCellNoResetID, terminal device 100 keeps the newly received ltm-ServingCellNoResetID value as the latest value, regardless of whether the ltm-ServingCellNoResetID value has already been kept. Terminal device 100 can keep the newly received ltm-ServingCellNoResetID value as the latest value by storing it in a variable representing the group identifier of the current serving cell. The definition of ltm-ServingCellNoResetID is set to be a parameter that is required, for example, in the case of setting a new LTM setting, and is optional in other cases. Furthermore, the terminal device 100 performs a synchronized reset when the RRC reset message including the received LTM setting includes a synchronized reset parameter.

[0339] Figure 20 This diagram illustrates a third example of handover processing in LTM settings. Terminal device 100 receives an RRC reset message including reset parameters with synchronization from base station device 200 (S2000). Upon receiving the RRC reset message including reset parameters with synchronization, terminal device 100 checks whether the received RRC reset message includes a parameter representing a group identifier. If the received RRC reset message includes a parameter representing a group identifier, the value of this parameter representing the group identifier is stored as the latest value of ltm-ServingCellNoResetID (S2001). Terminal device 100 can maintain the value of the parameter representing the group identifier as the latest value by storing it in a variable representing the group identifier of the current serving cell.

[0340] Therefore, even when a terminal device 100 with LTM settings receives a handover instruction, it can maintain the latest group identifier.

[0341] <LTM processing across CUs>

[0342] exist Figure 10Step S1001 states that the setting of the cell change destination candidate does not include parameters indicating security key updates, i.e., the LTM-based security key is not updated. This is because LTM across CUs is not envisioned in current discussions within 3GPP. However, in the case of LTM across CUs (Centralized Units), security key updates are necessary.

[0343] In a Change-of-House (CHO) scenario, when the target PCell belongs to a different CU, the settings parameters for changing the destination candidate in the PCell must include a parameter indicating an update to the security key, namely, masterkey update. Therefore, even in the case of a CHO across CUs, a security key update is performed. Furthermore, in a CHO, after the terminal device 100 releases the CHO settings, the base station device 200 re-configures the CHO for the terminal device 100. Therefore, even if a cross-CU CHO is performed again after a cross-CU CHO, a security key update can still be performed. However, in the case of LTM, to support subsequent cell sell switches, whether it crosses CUs depends on which cell in the cell sell destination candidate is observed. Therefore, a method for updating the security key in the terminal device 100 needs to be investigated.

[0344] In the first instance of cross-CU LTM processing, when the base station device 200 performs LTM settings on the terminal device 100, if the cell change destination candidates include at least one cell change destination candidate belonging to a different cell of a CU, the master key update is included in the settings of all cell change destination candidates. Therefore, even if cross-CU LTM is performed again during a subsequent cell handover, the terminal device 100 can still update the security key.

[0345] In the second example of cross-CU LTM processing, when the base station device 200 performs LTM settings on the terminal device 100, the cell change destination candidate does not include a master key update, but the cell handover signal includes a parameter indicating a security update. That is, when the base station device 200 instructs the terminal device 100 to perform cross-CU LTM, the cell handover signal includes a parameter indicating a security update. Alternatively, when the base station device 200 instructs the terminal device 100 to perform non-cross-CU LTM, the cell handover signal may or may not include a parameter indicating a security update. The parameter indicating a security update may include a parameter indicating whether a security update is needed and / or a parameter indicating a method for updating the security key. When the parameter indicating a security update includes both a parameter indicating whether a security update is needed and a parameter indicating a method for updating the security key, the terminal device 100, upon receiving a cell handover signal whose parameter indicating whether a security update is needed indicates a security update is needed or includes a parameter indicating a method for updating the security key, updates the security key according to the parameter indicating the method for updating the security key. Furthermore, if the terminal device 100 receives a cell handover signal and the parameter indicating whether a security update is required indicates that a security update is not required, or if the signal does not contain a parameter indicating a method for updating the security key, then the terminal device 100 will not update the security key.

[0346] The parameters indicating security updates or representing the method of updating security keys included in the cell handover signal may include some or all of the information of the master key update parameters included in the RRC reset message. The inclusion of a portion of the master key update parameters in the cell handover signal means, for example, that it only includes the parameter indicating whether the new security key generation method is horizontal or vertical derivation, namely, the Nexthop Chaining Count (NCC) information. In this case, it is assumed that LTM across AMFs is not performed. Alternatively, the inclusion of a portion of the master key update parameters in the cell handover signal can be achieved by pre-determining the new security key generation method to be either horizontal or vertical derivation only, omitting parameters indicating the security key update method such as NCC, and only including parameters indicating whether a security update is needed, thereby generating a new security key. Furthermore, if the parameters indicating security updates or the method of updating the security key included in the cell handover signal contain a portion of the master key update parameters, it means, for example, that a new security key can be generated with less information than when NCC is included, by setting "0" to no security update, "1" to horizontal generation, and "2" to vertical generation. When the parameters indicating security updates or the method of updating the security key included in the cell handover signal contain a portion of the master key update parameters, the base station device 200 appropriately updates the security information via the RRC reset message, enabling the terminal device 100 to update the security key without problems. Therefore, even if LTM is performed again across CUs during a subsequent cell handover, the terminal device 100 can still update the security key.

[0347] In the third example of cross-CU LTM processing, terminal device 100 deletes the LTM settings after a security update has been performed via LTM, i.e., the master key is updated in the target's ltm-CandidateConfig. Then, base station device 200 performs a new LTM setting on terminal device 100, thereby enabling terminal device 100 to perform cross-CU LTM again.

[0348] In the fourth example of cross-CU LTM processing, after the base station device 200 instructs the terminal device to perform a cross-CU LTM, it updates the LTM settings of the terminal device 100 before instructing the next LTM. Thus, even if a cross-CU LTM is performed again during a subsequent cell handover, the terminal device 100 can still update the security key.

[0349] <Other>

[0350] Sometimes, some messages in the above sequence are not processed in order, and sometimes the order of some messages is changed. In addition, sometimes some messages in the sequence are not processed.

[0351] Furthermore, the functions and processing described as those of the terminal device 100 can also be the functions and processing of the base station device 200.

[0352] Furthermore, when referring to a radio bearer simply as a "radio bearer" without distinguishing between signaling radio bearers and data radio bearers, the radio bearer can be a signaling radio bearer, a data radio bearer, or both.

[0353] In addition, the phrases "A can be renamed B" and "A can be renamed B" not only mean renaming A to B, but also include the meaning of renaming B to A.

[0354] Furthermore, when condition "A" and condition "B" are opposite, condition "B" can also be expressed as an "other" condition of condition "A".

[0355] In summary:

[0356] (1) A terminal device comprising: a receiving unit that receives an RRC message and a first signal from a base station device; and a processing unit that, when the RRC message includes a first parameter, is capable of setting according to the first parameter, the first parameter including a second parameter, the first parameter further including a third parameter related to the setting of a first LTM candidate and the first LTM candidate; when receiving the first signal from the base station device, performs cell handover to the first LTM candidate; when the value of the third parameter is the same as the value of the second parameter, does not perform the first processing; when the value of the third parameter is different from the value of the second parameter, performs the first processing and replaces the value of the second parameter with the value of the third parameter.

[0357] (2) According to the terminal device of (1), wherein the processing unit releases the LTM setting set on the terminal device when it receives the RRC message including the fourth parameter from the base station device.

[0358] (3) The terminal device according to (1) or (2), wherein the second parameter is a parameter that must be included when the first parameter is initially set, but is optional to be included otherwise.

[0359] (4) The terminal device according to (1) or (2) or (3), wherein the first signal is an LTM cell handover signal, the first parameter is an LTM setting, the second parameter is that the current cell number does not need to be reset, the third parameter is that the number does not need to be reset, and the first process is a layer 2 reset.

[0360] (5) The terminal device according to (2) or (3) or (4), wherein the fourth parameter is a synchronized reset.

[0361] Furthermore, while each embodiment describes an example of the device, the present disclosure is not limited to cellular phones, smartphones, tablet terminals, base station devices, etc., and can be applied to other electronic devices, such as electronic devices mounted on automobiles, trams, airplanes, artificial satellites, etc., electronic devices mounted on drones, etc., robots, AV equipment, household appliances, office equipment, vending machines, other living equipment, industrial equipment, and other devices.

[0362] Furthermore, while E-UTRA and NR are described as wireless access technologies and EPC and 5GC as core networks in each embodiment, the application of this disclosure is not limited to these. For example, the form of this disclosure can also be applied to different generations of wireless access technologies and networks, such as sixth-generation and seventh-generation technologies.

[0363] Furthermore, it is not limited to the above-described implementation method and can be implemented with various modifications.

[0364] In addition, various embodiments have been described in detail with reference to the accompanying drawings, but the specific structure is not limited to the disclosed drawings and the manner of description.

[0365] Explanation of reference numerals in the attached figures

[0366] 10. Communication System

[0367] 100 terminal devices

[0368] 110 CPU

[0369] 120 memory

[0370] 121 Wireless Communication Program

[0371] 122 Terminal-side program

[0372] 130 Memory

[0373] 140 Wireless Communication Circuit

[0374] 200 base station devices

[0375] 210 CPU

[0376] 220 memory

[0377] 221 Wireless Communication Program

[0378] 222 Base Station Side Procedure

[0379] 230 Memory

[0380] 240 Wireless Communication Circuit

[0381] 250 network interfaces

[0382] 300 core network

Claims

1. A terminal device, characterized in that, have: The receiving unit is capable of receiving RRC messages and a first signal from the base station device; and The processing unit, when the RRC message includes a first parameter, is capable of setting the parameters according to the first parameter. The first parameter includes the second parameter. The first parameter also includes a third parameter related to the setting of the first LTM candidate and the first LTM candidate. When the processing unit receives the first signal from the base station device, it performs a handover to the first LTM candidate cell. If the value of the third parameter is the same as the value of the second parameter, it does not perform the first processing. If the value of the third parameter is different from the value of the second parameter, it performs the first processing and replaces the value of the second parameter with the value of the third parameter.

2. The terminal device according to claim 1, wherein, Upon receiving the RRC message including the fourth parameter from the base station device, the processing unit releases the LTM setting set for the terminal device.

3. The terminal device according to claim 1 or 2, wherein, The second parameter is a parameter that must be included when the first parameter is initially set, but is optional in other cases.

4. The terminal device according to claim 1, wherein, The first signal is an LTM cell handover signal, the first parameter is an LTM setting, the second parameter is that the current cell number does not need to be reset, the third parameter is that the cell number does not need to be reset, and the first process is a Layer 2 reset.

5. The terminal device according to claim 2, wherein, The fourth parameter is a synchronized reset.

6. A base station device, characterized in that, have: The transmitting unit sends an RRC message and a first signal to the terminal device; and The processing unit is capable of controlling the following: including a first parameter in the RRC message, and causing the terminal device to perform settings according to the first parameter. The first parameter includes the second parameter. The first parameter also includes a third parameter related to the setting of the first LTM candidate and the first LTM candidate. The processing unit controls the sending unit to send the first signal to the terminal device, causing the terminal device to hand over to the first LTM candidate cell. If the value of the third parameter is the same as the value of the second parameter, no first processing is performed. If the value of the third parameter is different from the value of the second parameter, the first processing is performed, and the value of the second parameter is replaced with the value of the third parameter.

7. The base station apparatus according to claim 6, wherein, The processing unit controls the sending unit to send the RRC message including the fourth parameter to release the LTM setting set on the terminal device.

8. The base station apparatus according to claim 6 or 7, wherein, The second parameter is a parameter that must be included when the first parameter is initially set, and is optional to be included otherwise.

9. A wireless communication system, characterized in that, have: The base station device transmits an RRC message and a first signal; and The terminal device receives the RRC message and the first signal, and if the RRC message includes a first parameter, performs settings according to the first parameter. The first parameter includes the second parameter. The first parameter also includes a third parameter related to the setting of the first LTM candidate and the first LTM candidate. When the terminal device receives the first signal from the base station device, it performs a handover to the first LTM candidate cell. If the value of the third parameter is the same as the value of the second parameter, no first processing is performed. If the value of the third parameter is different from the value of the second parameter, the first processing is performed, and the value of the second parameter is replaced with the value of the third parameter.

Images