Terminal device, base station device, and wireless communication system
The terminal and base station devices implement security key updates for flexible cell switching, addressing the lack of standards for intra-CU and inter-CU cell switching in LTM, ensuring efficient communication and failure recovery.
Patent Information
- Application Number
- PCT/JP2024/013909
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-04-04
- Publication Date
- 2025-10-09
AI Technical Summary
The existing standards for L1/L2-triggered mobility (LTM) in 5G wireless communication systems do not specify a method for seamless cell switching between intra-CU and inter-CU cells without reconfiguration using RRC messages, and there is a lack of clarity on handling cell switching failures.
A terminal device and base station device are designed to facilitate flexible cell switching by determining the necessity of security key updates based on specific generation methods, enabling efficient RRC connection recovery during mobility processing.
Enables efficient cell switching with both intra-CU and inter-CU support, ensuring seamless communication and effective handling of cell switching failures.
Smart Images

Figure JP2024013909_09102025_PF_FP_ABST
Abstract
Description
Terminal device, base station device, and wireless communication system
[0001] The present invention relates to a terminal device, a base station device, and a wireless communication system.
[0002] Currently, wireless communication networks using mobile devices (smartphones, feature phones, etc.) are expanding. With the expansion of wireless communication, there is a demand for even faster speeds and larger capacities.
[0003] The 3rd Generation Partnership Project (3GPP), an international standardization project, is conducting technical studies and formulating standards for cellular mobile communication systems. For example, E-UTRA (Evolved Terrestrial Radio Access) has been standardized as the radio access technology (RAT) for 3.9th generation (3.9G) and 4th generation (4G), and EPC (Evolved Packet Core) has been standardized as the core network (CN) technology. Furthermore, NR (New Radio) has been standardized as the RAT for 5th generation (5G), and 5G Core (5GC) has been standardized as the core network technology. Furthermore, these extension technologies are currently being continuously studied and standardized.
[0004] Technologies related to NR or 5G systems are described, for example, in the following Non-Patent Documents 1 to 11.
[0005] 3GPP TS38.300 v18.0.0 NR Overview Specification 3GPP TS38.211 v18.0.0 NR PHY Channel and Modulation Specification 3GPP TS38.321 v18.0.0 NR MAC Specification 3GPP TS38.322 v18.0.0 NR RLC Specification 3GPP TS38.323 v18.0.0 NR PDCP Specification 3GPP TS37.324 v18.0.0 NR SDAP Specification 3GPP TS38.304 v18.0.0 NR Idle Mode and Inactive Mode Specification 3GPP TS38.331 v18.1.0 NR RRC Specification 3GPP RP-223520 "Revised WID on Further NR Mobility Enhancements" 3GPP RP-240299 "Revised Work Item: NR Mobility Enhancements" Phase 4" 3GPP TS33.501 v18.4.0 5G System Security Specification
[0006] As one of the extension technologies, technical studies on improving mobility are being conducted. As one of the items under study, a technology called L1 / L2-triggered mobility (LTM) was defined in Rel-18 (Non-Patent Document 9). This technology aims to reduce latency in mobility by having a base station switch the serving cell of a terminal device using Layer 1 and / or Layer 2 signals instead of Layer 3 signals such as RRC (Radio Resource Control) messages. Furthermore, Rel-19 is expected to define specifications for LTM that further extend the LTM in Rel-18, which only supports intra-CU (intra-CU) cell switching, to also support inter-CU (inter-CU) cell switching (Non-Patent Document 10).
[0007] However, the specific method of LTM that supports both intra-CU and inter-CU cell switching has not been determined as a standard specification. For example, the specification has not been determined regarding a method for realizing cell switching between multiple LTM candidate cells that supports both intra-CU and inter-CU cell switching without reconfiguration using an RRC message. Furthermore, the specification has not been determined regarding the processing of a terminal device when cell switching by inter-CU LTM fails.
[0008] Therefore, one disclosure provides a base station device, a terminal device, and a wireless communication system that enable flexible cell switching that supports both intra-CU and inter-CU cell switching.
[0009] One disclosure is a terminal device having a receiving unit that receives a signal from a first base station device and a processing unit, wherein the receiving unit receives a first signal including a security key generation method parameter and a first candidate cell setting for a first cell, and when cell switching to the first cell is initiated, the processing unit determines whether a security key update is necessary, and if it is determined that a security key update is necessary, generates a security key using a first key corresponding to a first value if the security key generation method parameter indicates a first generation method, and generates a security key using a second key corresponding to a currently used second value if the security key generation method parameter indicates a second generation method.
[0010] Another disclosure is a base station device having a transmitting unit that transmits a signal to a terminal device and a processing unit, wherein the transmitting unit transmits a first signal including a security key generation method parameter and a first candidate cell setting for a first cell, and the processing unit causes the terminal device to determine whether a security key needs to be updated when cell switching to the first cell is initiated, and when the terminal device determines that a security key needs to be updated, if the security key generation method parameter indicates a first generation method, causes the terminal device to generate a security key using a first key corresponding to a first value, and if the security key generation method parameter indicates a second generation method, causes the terminal device to generate a security key using a second key corresponding to a second value currently used by the terminal device.
[0011] Another disclosure is a wireless communication system comprising: a base station that transmits a first signal including a security key generation method parameter and a first candidate cell setting for a first cell; and a terminal device that receives the first signal, wherein when cell switching to the first cell is initiated, the terminal device determines whether a security key update is necessary; and, if it determines that a security key update is necessary, generates a security key using a first key corresponding to a first value if the security key generation method parameter indicates a first generation method; and generates a security key using a second key corresponding to a currently used second value if the security key generation method parameter indicates a second generation method.
[0012] One disclosure enables communication that enables efficient RRC connection recovery processing when a terminal device performs mobility processing.
[0013] FIG. 1 is a diagram showing an example of the configuration of a communication system 10. FIG. 2 is a diagram showing an example of the configuration of a base station device 200. FIG. 3 is a diagram showing an example of the configuration of a terminal device 100. FIG. 4 is a diagram showing an example of a protocol stack in the U-Plane. FIG. 5 is a diagram showing an example of a protocol stack in the C-Plane. FIG. 6 is a diagram showing an example of an RRC Reconfiguration message format. FIG. 7 is a diagram showing an example of the configuration of a cell group in the communication system 10. FIG. 8 is a diagram showing an example of synchronized reconfiguration. FIG. 9 is a diagram showing an example of parameters related to LTM included in an RRC Reconfiguration message. FIG. 10 is a diagram showing an example of an intra-CU LTM sequence. FIG. 11 is a diagram showing an example of a cell switching failure detection and cell switching failure processing sequence. FIG. 12 is a diagram showing an example of a subsequence cell switching method corresponding to intra-CU and inter-CU.
[0014] The present embodiment will be described in detail below with reference to the drawings. The problems and examples in this specification are merely examples and do not limit the scope of the rights of the present application. In particular, even if the expressions used are different, the technology of the present application can be applied as long as they are technically equivalent, and do not limit the scope of the rights.
[0015] In this embodiment, the names and processes of each device, node, function, protocol, entity, signaling, message, parameter, etc. when the radio access technology is E-UTRA or NR and when the core network is EPC or 5GC are described, but the embodiment may be used for other radio access technologies. The names of each node and entity in each embodiment may be different names.
[0016] <Configuration Example of Communication System 10> Fig. 1 is a diagram showing a configuration example of the communication system 10. The communication system 10 includes a terminal device 100, base station devices 200-1 and 200-2, and a core network 300. The communication system 10 may be a wireless communication system in which the terminal device 100 communicates with the base station device 200-1 or the base station device 200-2, or may be a wireless communication system in which the terminal device 100 communicates with the base station device 200-1 and the base station device 200-2 using MR-DC (Multi Radio Dual Connectivity) described below. When communicating using MR-DC, for example, the base station device 200-1 is a master base station device, and the base station device 200-2 is a secondary base station device. Hereinafter, the master base station device may be referred to as an MN (Master Node), and the secondary base station device may be referred to as an SN (Secondary Node).
[0017] The terminal device 100 is wirelessly connected to one or both of the base station device 200-1 and the base station device 200-2 and performs wireless communication. The RAT providing the wireless connection is, for example, E-UTRA or NR. The terminal device 100 is a terminal device that supports either or both of E-UTRA and NR.
[0018] The base station devices 200-1 and 200-2 (hereinafter, sometimes referred to as base station devices 200) are communication devices that are wirelessly connected to the terminal device 100 and perform wireless communication. The base station devices 200-1 and 200-2 are, for example, wired to each other and perform communication. The base station device 200 is, for example, wired to a core network 300 and performs communication. The base station device 200 is, for example, either an eNodeB (eNB) that provides E-UTRA as the RAT or a gNodeB (gNB) that provides NR as the RAT. Note that one base station device may be composed of one CU (centralized unit) and one or more DUs (distributed units). The CU may have the functions of, for example, RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), and PDCP (Packet Data Convergence Protocol) from the protocol stack described below. The CU may also have an interface function between base station devices and an interface function between the base station device and the core network. The DU may have functions such as RLC (Radio Link Control), MAC (Medium Access Control), and PHY (PHYsical) in the protocol stack described below.
[0019] The core network 300 is a network corresponding to a certain generation. For example, the core network 300 is a 5GC that is a core network standardized for 5G, or an EPC that is a core network standardized for 4G.
[0020] The MR-DC implemented in the communication system 10 will be described in detail later.
[0021] 2 is a diagram illustrating an example of the configuration of the base station device 200. The base station device 200 is a communication device or a relay device that includes a CPU (Central Processing Unit) 210, a storage 220, a memory 230, a wireless communication circuit 240, and a network interface (NI (Network Interface)) 250.
[0022] The storage 220 is an auxiliary storage device that stores programs and data, such as a flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The storage 220 stores a wireless communication program 221 and a base station side program 222.
[0023] The memory 230 is an area into which the programs stored in the storage 220 are loaded. The memory 230 may also be used as an area in which the programs store data.
[0024] The wireless communication circuit 240 is a circuit that wirelessly connects to and communicates with the terminal device 100. The base station device 200 receives a signal transmitted from the terminal device 100 via the wireless communication circuit 240, and transmits a signal to the terminal device 100, for example.
[0025] The NI 250 is, for example, a communication device that connects to other base station devices 200 and realizes inter-base station communication. The NI 250 is also, for example, a communication device that connects to the core network 300 (communication devices that constitute the core network 300) and performs communication. The NI 250 is, for example, a network interface card (NIC). The base station device 200 receives signals from other communication devices and transmits signals to other communication devices via the NI 250.
[0026] The CPU 210 is a processor that loads programs stored in the storage 220 into the memory 230, executes the loaded programs, configures each unit, and realizes each process.
[0027] The CPU 210 performs wireless communication processing by executing the wireless communication program 221. The wireless communication processing is processing for wirelessly connecting to the terminal device 100, communicating wirelessly with the terminal device 100, and relaying communication between the terminal device 100 and other communication devices.
[0028] The CPU 210 executes the base station side program 222 to configure a second transmitting unit, a second receiving unit, and a second processing unit, and perform base station side processing. When the base station device 200 communicates with the terminal device 100 using MR-DC, the base station side processing may include MR-DC master node processing and MR-DC secondary node processing. In this case, the MR-DC master node processing is processing for controlling the master node side of the MR-DC, and the MR-DC secondary node processing is processing for controlling the secondary node side of the MR-DC. In the MR-DC master node processing and the MR-DC secondary node processing, the base station device 200 performs communication corresponding to each type of MR-DC, which will be described later.
[0029] 3 is a diagram showing an example of the configuration of the terminal device 100. The terminal device 100 is a communication device having a CPU 110, a storage 120, a memory 130, and a wireless communication circuit 140.
[0030] The storage 120 is an auxiliary storage device such as a flash memory, HDD, or SSD that stores programs and data. The storage 120 stores a wireless communication program 121 and a terminal-side program 122.
[0031] The memory 130 is an area into which the programs stored in the storage 120 are loaded. The memory 130 may also be used as an area in which the programs store data.
[0032] The wireless communication circuit 140 is a circuit that wirelessly connects to and communicates with the base station device 200. The terminal device 100, for example, receives a signal transmitted from the base station device 200 via the wireless communication circuit 140 and transmits a signal to the base station device 200. The wireless communication circuit 140 is, for example, a network card that supports wireless connection.
[0033] The CPU 110 is a processor that loads programs stored in the storage 120 into the memory 130, executes the loaded programs, configures each unit, and realizes each process.
[0034] The CPU 110 performs terminal-side wireless communication processing by executing the wireless communication program 121. The terminal-side wireless communication processing is processing for wirelessly connecting to the base station device 200 and performing wireless communication with the base station device 200 or communication with another communication device via the base station device 200.
[0035] The CPU 110 executes the terminal-side program 122 to configure a transmitting unit, a receiving unit, and a processing unit, and to perform terminal-side processing. When the terminal device 100 communicates with the base station device 200 using MR-DC, the terminal-side processing may include terminal-side MR-DC processing. In this case, the terminal-side MR-DC processing is processing for controlling communication in the MR-DC. In the terminal-side MR-DC processing, the terminal device 100 performs communication corresponding to each type of MR-DC, which will be described later.
[0036] <Protocol Stack> An example of a protocol stack of the communication system 10 will be described. In the communication system 10, a series of protocols for transmitting and receiving data, shown in a hierarchical structure, is called a protocol stack. In the following example, the base station device 200 is an eNB or gNB, and the core network 300 is an EPC or 5GC. In addition, the terminal device 100 (UE: User Equipment) is assumed to support one or both of E-UTRA and NR.
[0037] The protocol stacks of the U-Plane (User Plane) and C-Plane (Control Plane) are explained below. The U-Plane is used, for example, to send and receive user data in communications. The C-Plane is used, for example, to send and receive control signals (messages) in communications. In each embodiment, unless otherwise specified, "user data" or "control signals (messages)" refers to either user data or control signals (messages), or both.
[0038] Figure 4 is a diagram showing an example of a protocol stack for the U-Plane when the core network 300 is 5GC. Also, Figure 5 is a diagram showing an example of a protocol stack for the C-Plane when the core network 300 is 5GC. In Figures 4 and 5, PHY (PHYsical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol), SDAP (Service Data Adaptation Protocol), RRC (Radio Resource Control), and NAS (Non Access Stratum) respectively indicate the names of layers. Hereinafter, PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS may be referred to as the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer, respectively. Furthermore, MAC, RLC, PDCP, and SDAP may be referred to as a MAC sublayer, an RLC sublayer, a PDCP sublayer, and an SDAP sublayer, respectively. Furthermore, MAC, RLC, PDCP, and SDAP may be referred to as a MAC entity, an RLC entity, a PDCP entity, and an SDAP entity, respectively. Note that when core network 300 is an EPC, the protocol stack of the U-Plane is a protocol stack in which SDAP does not exist in FIG. 4. That is, it is a protocol stack consisting of PHY, MAC, RLC, and PDCP. Furthermore, when core network 300 is an EPC, the protocol stack of the C-Plane is such that, in FIG. 5, NAS exists in an AMF (Access and Mobility management Function), whereas NAS exists in an MME (Mobility Management Entity).
[0039] The functions in each layer may be common or different between the E-UTRA and NR RATs. In the following description, if there is no specification of E-UTRA or NR, the functions are common to both E-UTRA and NR.
[0040] In each sublayer, data provided from and to an upper layer is called an SDU (Service Data Unit). That is, data provided from and to an upper layer to MAC, RLC, PDCP, and SDAP is called a MAC SDU, an RLC SDU, a PDCP SDU, and an SDAP SDU, respectively.
[0041] In each sublayer, data provided to and from the lower layer is called a PDU (Protocol Data Unit). That is, data provided from MAC, RLC, PDCP, and SDAP to the lower layer, and data provided from the lower layer to MAC, RLC, PDCP, and SDAP are called MAC PDU, RLC PDU, PDCP PDU, and SDAP PDU, respectively. RLC, PDCP, and SDAP also have control PDUs, which are sometimes called control PDUs. To distinguish them from control PDUs, other PDUs are sometimes called data PDUs.
[0042] In Figure 4, the U-Plane consists of PHY, MAC, RLC, PDCP, and SDAP, and terminates at the terminal device 100 (UE) and the base station device 200 (gNB).
[0043] An example of the function of the PHY will be described. The PHY is a wireless physical layer, and transmits control information and data between the terminal device 100 and the base station device 200 using a physical channel. The direction from the base station device 200 to the terminal device 100 is sometimes called the downlink (downlink, DL), and the direction from the terminal device 100 to the base station device 200 is sometimes called the uplink (uplink, UL). Furthermore, within the terminal device 100 and the base station device 200, the PHY is connected to the MAC, which is an upper layer, via a transport channel, and data moves between the PHY and the MAC via the transport channel. In the PHY, a Radio Network Temporary Identifier (RNTI) is used to identify various control information.
[0044] An example of MAC functions will be described. MAC is a medium access control layer, and performs mapping of transport channels and logical channels (LCHs), multiplexing and demultiplexing of MAC SDUs, scheduling reports (SRs), error correction through hybrid automatic repeat reQuest (HARQ), priority control, etc. In the terminal device 100 and the base station device 200, the MAC is connected to the RLC, which is an upper layer, via a logical channel, and data moves between the MAC and the RLC via the logical channel. The logical channel may be identified by a logical channel identifier (LCID). Furthermore, the base station device 200 controls the terminal device 100 using a MAC control element (CE). Furthermore, the terminal device 100 performs reports, etc. to the base station device 200 using a MAC CE.
[0045] RLC is the radio link control layer and has three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). On the transmitting side, RLC performs PDU transmission, sequence number assignment (in the case of UM and AM), SDU segmentation (in the case of UM and AM), and re-segmentation (in the case of AM). On the receiving side, RLC performs SDU reassembly (in the case of UM and AM), duplicate detection (in the case of AM), and SDU discarding (in the case of UM and AM). It also performs RLC re-establishment on the transmitting and receiving sides. Segmented SDUs are called SDU segments. RLC also has a data retransmission function and / or a retransmission request function (ARQ: Automatic Repeat reQuest) (in the case of AM). In addition, in the case of E-UTRA RLC, there are also other functions such as data combining on the transmitting side, and reordering and in-order delivery on the receiving side.
[0046] PDCP is a packet data convergence protocol layer, and performs data transfer between the U-Plane and C-Plane, PDCP sequence number management, header compression / decompression, encryption / decryption, integrity protection / integrity verification, timer-based SDU discard, routing for split bearers, reordering and in-order delivery, etc. In E-UTRA PDCP, functions such as timer-based SDU discard, reordering and in-order delivery may be limited to the case of split bearers, which will be described later.
[0047] SDAP is a service data adaptation protocol layer that performs tasks such as mapping QoS (Quality of service) flows to Data Radio Bearers (DRBs), which will be described later, and marking downlink (DL) packets and uplink (UL) packets with QoS flow identifiers (QFIs).
[0048] The upper layers of the U-Plane include, for example, IP (Internet Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), Ethernet (registered trademark), and application layers. A layer including IP, TCP, UDP, Ethernet, etc. may be called a PDU layer. Furthermore, IMS (IP Multimedia Subsystem), which controls sessions, may be included in the application layer.
[0049] 5, the C-Plane of the AS (Access Stratum) is composed of PHY, MAC, RLC, PDCP, and RRC, and terminates at the terminal device 100 and the base station device 200. The C-Plane of the NAS is composed of the NAS, and terminates between the terminal device 100 and the AMF, which is a device in the core network 300. The PHY, MAC, RLC, and PDCP are the same as those in the U-Plane.
[0050] The RRC performs functions such as broadcasting system information (SI) related to AS and NAS, paging, establishing / maintaining / releasing RRC connections between the terminal device 100 and the base station device 200, adding / changing / releasing carrier aggregation (CA), adding / changing / releasing dual connectivity (DC), security functions including security key management, establishing / setting / maintaining / releasing signaling radio bearers (SRBs) and data radio bearers (DRBs), mobility functions, QoS management functions, controlling terminal device measurement reports and reporting, detecting and recovering from radio link failures (RLFs), and forwarding NAS messages. Radio link failures include, for example, detection of a physical layer problem, random access failures, or the maximum number of retransmissions by RLC.
[0051] The NAS performs authentication, mobility management, security control, etc. on the core network side.
[0052] <Channels> The channels used in the communication system 10 will be described. Below, examples of channels corresponding to NR are shown, but the channels used are not limited to the following. In addition, channels with the same name can be used for the same or similar purposes in RATs other than NR, such as E-UTRA.
[0053] <1. Physical Channel> The PBCH (Physical Broadcast CHannel) is a channel used for transmitting broadcast information from the base station device 200 to the terminal device 100 .
[0054] The PDCCH (Physical Downlink Control CHannel) is a channel used to transmit downlink control information (DCI) and the like from the base station device 200 to the terminal device 100 .
[0055] The PDSCH (Physical Downlink Shared CHannel) is a channel used to transmit data from an upper layer from the base station device 200 to the terminal device 100.
[0056] The PUCCH (Physical Uplink Control CHannel) is a channel used to transmit uplink control information (UCI) and the like from the terminal device 100 to the base station device 200 .
[0057] A PUSCH (Physical Uplink Shared CHannel) is a channel used to transmit data from an upper layer from the terminal device 100 to the base station device 200.
[0058] The PRACH (Physical Random Access CHannel) is a channel used to transmit a random access preamble and the like from the terminal device 100 to the base station device 200 .
[0059] 2. Transport Channels The BCH (Broadcast Channel) is mapped to the PBCH, which is a physical channel.
[0060] The DL-SCH (Downlink Shared Channel) is mapped to the PDSCH, which is a physical channel.
[0061] The PCH (Paging Channel) is mapped to the PDSCH, which is a physical channel.
[0062] The UL-SCH (Downlink Shared Channel) is mapped to the PUSCH, which is a physical channel.
[0063] Random Access Channel(s) (RACH) are mapped to a PRACH, which is a physical channel.
[0064] 3. Logical Channels The BCCH (Broadcast Control Channel) is a downlink channel for broadcasting system information, and is mapped to the transport channel BCH or DL-SCH.
[0065] A PCCH (Paging Control Channel) is a downlink channel for carrying paging messages and is mapped to the PCH of the transport channel.
[0066] The CCCH (Common Control Channel) is a channel for transmitting control information (such as RRC messages) between the terminal device 100 and the base station device 200, and is a channel used for the terminal device 100 that does not maintain (does not have) an RRC connection with the base station device 200, with the downlink mapped to the transport channel DL-SCH and the uplink mapped to the transport channel UL-SCH.
[0067] The DCCH (Dedicated Control Channel) is a point-to-point bidirectional channel that transmits dedicated control information (such as RRC messages) between the terminal device 100 and the base station device 200, and is used for the terminal device 100 that has an RRC connection with the base station device 200, with the downlink mapped to the transport channel DL-SCH and the uplink mapped to the transport channel UL-SCH.
[0068] A DTCH (Dedicated Transport Channel) is a point-to-point bidirectional channel dedicated to a terminal, which transmits user information (user data), and the downlink is mapped to the DL-SCH transport channel, and the uplink is mapped to the UL-SCH transport channel.
[0069] The MCCH (MBS Control Channel) is a point-to-multipoint downlink channel used to transmit MBS (Multicast Broadcast Service) broadcast control information corresponding to one or more MTCHs (MBS Traffic Channels) from the base station device 200 to the terminal device 100. The MCCH is mapped to the DL-SCH transport channel.
[0070] The MTCH is a point-to-multipoint downlink channel used to transmit MBS multicast session data or broadcast session data from the base station device 200 to the terminal device 100. It is mapped to the transport channel DL-SCH.
[0071] <RRC State (Mode)> The RRC state of the terminal device 100 is a state related to the RRC connection of the terminal device 100. A state in which an RRC connection with the base station device 200 is not established is called an RRC idle mode (RRC_IDLE). A state in which an RRC connection with the base station device 200 is established is called an RRC connected mode (RRC_CONNECTED). A state in which the RRC connection with the base station device 200 is temporarily suspended is called an RRC inactive mode (RRC_INACTIVE). Note that when the core network 300 is an EPC, the state in which the RRC connection with the base station device 200 is temporarily suspended may be called another name, such as RRC suspended, instead of being called an RRC inactive mode.
[0072] <RRC Message> The RRC message will be explained. The RRC message is a message that includes information necessary for communication in a cell, and includes a MIB (Master Information Block), a system information group (SIB), etc. The parameters included in the RRC message may be called fields or information elements (IEs).
[0073] The RRC message also includes a message related to the establishment of an RRC connection. For example, in the case of NR, messages related to the establishment of an RRC connection include an RRC setup request message (RRCSetupRequest), an RRC setup message (RRCSetup), and an RRC setup complete message (RRCSetupComplete). For example, in the case of E-UTRA, messages related to the establishment of an RRC connection include an RRC connection setup request message (RRCConnectionSetupRequest), an RRC connection setup message (RRCConnectionSetup), and an RRC connection setup complete message (RRCConnectionSetupComplete).
[0074] The RRC message also includes a message related to the initial activation of AS (Access Stratum) security. Examples of messages related to the initial activation of AS security include a security mode command message (SecurityModeCommand).
[0075] Furthermore, the RRC message includes a message related to the reconfiguration of the RRC connection. For example, in the case of NR, messages related to the reconfiguration of the RRC connection include an RRC reconfiguration message (RRCReconfiguration) and an RRC reconfiguration complete message (RRCReconfigurationComplete). For example, in the case of E-UTRA, messages related to the reconfiguration of the RRC connection include an RRC connection reconfiguration message (RRCConnectionReconfiguration) and an RRC connection reconfiguration complete message (RRCConnectionReconfigurationComplete). Note that messages related to the reconfiguration of the RRC connection perform the establishment, configuration, modification, and release of radio bearers, cell groups, etc., as well as synchronized reconfiguration, as described below, and also the establishment, configuration, modification, and release of measurement information, etc.
[0076] After initial activation of AS security, the terminal device 100 receives the first RRC reconfiguration message from the base station device 200, thereby obtaining all settings or all minimum required settings necessary for communication (data communication) with the base station device 200 in the cell to which the terminal device 100 is connected. These all settings or all minimum required settings necessary for communication (data communication) with the base station device 200 may be referred to as, for example, complete settings.
[0077] After initial activation of AS security for the terminal device 100, the base station device 200 can transmit a first RRC reconfiguration message and then another RRC reconfiguration message to cause the terminal device 100 to update the settings required for communication (data communication) with the base station device 200. In this case, the base station device 200 transmits an RRC reconfiguration message containing a differential setting from the complete setting currently set in the terminal device 100. This differential setting is sometimes called a delta setting. When the terminal device 100 receives an RRC reconfiguration message including the delta setting, it generates a new setting by applying the delta setting to the complete setting currently being used.
[0078] The RRC message also includes a message related to the re-establishment of the RRC connection. For example, in the case of NR, messages related to the re-establishment of the RRC connection include an RRC re-establishment request message (RRCReestablishRequest), an RRC re-establishment message (RRCReestablish), and an RRC re-establishment complete message (RRCReestablishComplete). For example, in the case of E-UTRA, messages related to the establishment of the RRC connection include an RRC connection re-establishment request message (RRCConnectionReestablishRequest), an RRC connection re-establishment message (RRCConnectionReestablish), and an RRC connection re-establishment complete message (RRCConnectionReestablishComplete).
[0079] In addition, the RRC messages further include messages regarding the release or suspension of the RRC connection, messages regarding the resumption of the RRC connection, messages regarding the capabilities of the terminal device, messages regarding terminal information, messages regarding MCG failure information, and messages regarding SCG failure information.
[0080] In addition, in MR-DC, when the master node is an eNB, the eNB may configure the terminal device 100 regarding NR by including the NR RRC message and parameters received from the gNB, which is the secondary node, as a container in the E-UTRA RRC message and transmitting it to the terminal device 100. The terminal device 100 may also include a completion message for the NR configuration as a container in the E-UTRA RRC message and transmit it to the eNB, which is the master node.
[0081] Also, in MR-DC, when the master node is a gNB, the gNB may configure the terminal device 100 for E-UTRA by including the E-UTRA RRC message and parameters received from the eNB, which is the secondary node, as a container in the NR RRC message and transmitting it to the terminal device 100. Also, the terminal device 100 may include a completion message for the E-UTRA configuration in the NR RRC message as a container and transmit it to the gNB, which is the master node.
[0082] 6 is a diagram showing an example of a message format of RRC Reconfiguration. Format E1 is a parameter of RRC Reconfiguration.
[0083] RRC Reconfiguration has radioBearerConfig, radioBearerConfig2, masterCellGroup, secondaryCellGroup, masterKeyUpdate, and sk-counter as parameters.
[0084] radioBearerConfig and radioBearerConfig2 are settings related to an MN-terminated bearer or an SN-terminated bearer, and include SRB settings, DRB settings, security settings, etc. The SRB settings (DRB settings) include an SRB identifier (DRB identifier), PDCP settings, a parameter instructing PDCP re-establishment, etc. The security settings include a parameter (keyToUse) indicating whether to use a master key or a secondary key.
[0085] The masterCellGroup and secondaryCellGroup are MCG settings and SCG settings, respectively, and include a cell group identifier, an RLC bearer setting, an SpCell setting, etc. The RLC bearer setting includes a logical channel identifier, an RLC setting, a radio bearer identifier (SRB identifier or DRB identifier) associated with the RLC bearer, etc. The SpCell setting includes information necessary for synchronized reconfiguration, etc.
[0086] masterKeyUpdate contains the information necessary for a master key update.
[0087] The sk-counter contains the information necessary for secondary key generation.
[0088] Format E11 is a diagram showing an example of parameters of RadioBearerConfig included in RRCReconfiguration.
[0089] Format E12 is a diagram showing an example of parameters of CellGroupConfig included in RRCReconfiguration.
[0090] Format E13 is a diagram showing an example of parameters of MaskerKeyUpdate included in RRCReconfiguration.
[0091] Format E111 is a diagram showing an example of parameters of SRB-ToAddMod included in RadioBearerConfig.
[0092] Format E112 is a diagram showing an example of the parameters of DRB-ToAddMod included in RadioBearerConfig.
[0093] Format E113 is a diagram showing an example of parameters of SecurityConfig included in RadioBearerConfig.
[0094] Format E121 is a diagram showing an example of parameters of RLC-BearerConfig included in CellGroupConfig.
[0095] Format E122 is a diagram showing an example of parameters of SpCellConfig included in CellGroupConfig.
[0096] <Radio Bearer> An example of a radio bearer in the communication system 10 will now be described.
[0097] <1. Signaling Radio Bearer> A signaling radio bearer (SRB) is a radio bearer for transmitting RRC messages and NAS messages.
[0098] SRB0 is the radio bearer for RRC messages that use the CCCH logical channel.
[0099] SRB1 is a radio bearer for RRC messages and NAS messages that uses the DCCH logical channel and is established before SRB2, which will be described later, is established.
[0100] SRB2 is a radio bearer for transmitting and receiving NAS messages, transmitting RRC messages including logged measurement information, etc., and uses the DCCH logical channel. The priority of SRB2 is lower than that of SRB1, and may be set by the base station apparatus 200 after AS security is activated.
[0101] SRB3 is a radio bearer for RRC messages when EN-DC, NGEN-DC, or NR-DC is set in the terminal device 100, and uses the DCCH logical channel. Note that EN-DC, NGEN-DC, and NR-DC are types of MR-DC, and details of the types of MR-DC will be described later.
[0102] <2. Data Radio Bearer> A data radio bearer (DRB) is a radio bearer for transmitting user data.
[0103] <SRB and DRB Protocol Configuration> The SRB and DRB protocol configuration of the terminal device 100 will be described.
[0104] SRB0 does not have a PDCP entity and is configured with an RLC bearer. The RLC bearer is configured with an RLC entity and a MAC logical channel. The mode of the RLC entity of SRB0 is TM.
[0105] Each of SRB1 and SRB2 consists of one PDCP entity and one or more RLC bearers, where the RLC entity is in AM mode.
[0106] SRB3 consists of one PDCP entity and one RLC bearer, and the mode of the RLC entity is AM.
[0107] A DRB consists of one PDCP entity and one or more RLC bearers. The mode of the RLC entity is UM or AM. A DBR is sometimes called a UM DBR when the RLC entity is UM, and sometimes called an AM DRB when the RLC entity is AM. Furthermore, a DRB is associated with one SDAP when the core network 300 is 5GC, and is associated with one EPS bearer (or EPS bearer identity) when the core network 300 is EPC.
[0108] It is assumed that one MAC entity exists for each cell group described below.
[0109] <Cells and Cell Groups> The cells and cell groups (CG) configured in the terminal device 100 will be described.
[0110] A cell group may be composed of one special cell (SpCell). Also, a cell group may be composed of one SpCell and one or more secondary cells (SCells). Note that an SpCell in a master cell group (MCG) (described later) may be called a primary cell (PCell). Also, an SpCell in a secondary cell group (SCG) (described later) may be called a primary SCG cell (PSCell).
[0111] The PCell is a primary frequency cell and is used to establish an RRC connection or re-establish an RRC connection. That is, when establishing an RRC connection or re-establishing an RRC connection, the cell selected by the terminal device 100 becomes the PCell. Furthermore, when the base station device 200 requests a handover (described later) from the terminal device 100, a new PCell designated by the base station device 200 is used for random access.
[0112] The SCell is a cell that provides additional radio resources in addition to the SpCell when carrier aggregation (CA) is configured in the terminal device 100.
[0113] The PSCell is a cell of the primary frequency on the SCG side. The PSCell is designated by the base station device 200 and is used for random access when adding or changing a PSCell in the SCG.
[0114] Note that the cell that the terminal device 100 in the RRC connected state uses for communication with the base station device 200 may be called the serving cell. When CA is not configured, the SpCell is the serving cell, and when CA is configured, the SpCell and SCell are the serving cells.
[0115] The MCG is a CG when DC (Dual Connectivity) is not set in the terminal device 100, or a CG that belongs to a master node (MN) when DC is set in the terminal device 100. DC is a technology in which the terminal device 100 is wirelessly connected to a base station device 200 that is a master node and a base station device 200 that is a secondary node (SN), and performs wireless communication using the carriers (cell groups) of the respective base station devices 200.
[0116] The SCG is a CG belonging to a secondary node that is set in addition to the MCG when a DC is set in the terminal device 100.
[0117] FIG. 7 is a diagram showing an example of the configuration of a cell group in the communication system 10. In FIG. 7, the master node (MN) is the base station device 200-1, and the secondary node (SN) is the base station device 200-2. The master node is, for example, in an MR-DC, the base station device 200 that provides a C-Plane connection to the core network 300. The secondary node is, for example, in an MR-DC, the base station device 200 that does not provide a C-Plane to the core network 300 but provides additional radio resources to the terminal device 100. In FIG. 7, the MCG is, for example, composed of one PCell and two SCells. Also, in FIG. 7, the SCG is, for example, composed of one PSCell and two SCells.
[0118] The base station device 200 may set a BWP (BandWidth Part) for the cell set for the terminal device 100, and adjust the cell so that a limited frequency band is used among the entire frequency band of the cell. The BWP may be configured from a portion of the frequency band of each cell. Furthermore, multiple BWPs (for example, up to four) may be set for each cell. The BWP may be set by an RRC reconfiguration message. In each cell, the BWP to be used may be specified or switched by an RRC reconfiguration message or by using DCI.
[0119] <Reconfiguration with Sync> Reconfiguration with Sync will now be described. Reconfiguration with Sync indicates a procedure executed in the terminal device 100 by including a parameter indicating that reconfiguration with Sync (reconfigurationWithSync: hereinafter, sometimes referred to as a reconfiguration parameter with sync) in an RRC reconfiguration message (RRCReconfiguration) that the base station device 200 transmits to the terminal device 100.
[0120] The synchronized reconfiguration parameters are included separately under parameters for MCG configuration (hereinafter, may be referred to as MCG configuration parameters) and under parameters for SCG configuration (hereinafter, may be referred to as SCG configuration parameters). In other words, when included under the MCG configuration parameters, it means synchronized reconfiguration of the MCG, and when included under the SCG configuration parameters, it means synchronized reconfiguration of the SCG.
[0121] The synchronized reconfiguration is a procedure in which the terminal device 100 changes the SpCell, and includes operations such as random access to the new (target, changed to) SpCell, MAC reset, and PDCP data recovery (in the case of AM DRB).
[0122] The process when the synchronized reconfiguration parameters are included under the MCG configuration parameters may be called handover. The process when the synchronized reconfiguration parameters are included under the SCG configuration parameters may be called PSCell addition and / or PSCell change. The source PCell / PSCell may be called the source PCell / source PSCell, and the destination PCell / PSCell may be called the target PCell / target PSCell. Because synchronized reconfiguration may involve CA, the term serving cell may be used, and the terms source serving cell and target serving cell may be used. The term "serving" may also be omitted, and the terms source cell and target cell may be used.
[0123] The terminal device 100 may generate the target cell configuration by applying the delta configuration included in the RRC reconfiguration message to the source cell configuration.
[0124] In addition, synchronized re-establishment may involve updating security keys. In this case, PDCP re-establishment is also performed in addition to the above.
[0125] When the security key is updated, a new key is generated by the RRC of the terminal device 100, and the PDCP is re-established, so that the new key is applied to the PDCP.
[0126] Fig. 8 is a diagram showing an example of processing when a synchronization-attached resetting parameter is included under a parameter for setting an MCG. Note that Fig. 8 is a diagram showing an example of synchronization-attached resetting.
[0127] The synchronized reconfiguration parameters include settings such as a target PCell setting, a new C-RNTI (Cell Radio Network Temporary Identifier), a RACH setting, and a timer for detecting handover failure. The terminal device 100 performs random access (RA) with the target PCell in accordance with the settings, and changes the current source PCell to the target PCell (S1). Note that RACH may refer to a random access procedure in addition to a random access channel.
[0128] <Handover Failure Processing> If the terminal device 100 receives an RRC reconfiguration message including a synchronization-enabled reconfiguration parameter and the handover is not successful within a certain time, the handover fails. The handover not being successful within the certain time may mean that the timer for detecting handover failure, which starts when the terminal device 100 receives an RRC reconfiguration message including a synchronization-enabled reconfiguration parameter, expires before the handover is successful.
[0129] If the handover fails, the terminal device 100 restores the settings to those used in the source PCell and performs an RRC connection re-establishment procedure. When restoring the settings of the terminal device 100 to those used in the source PCell, the values of the state variables in each entity of each radio bearer are also restored to the values used in the source (values immediately before the handover process).
[0130] In the RRC connection re-establishment procedure, the terminal device 100 performs cell selection, and if an NR cell is selected, it transmits an RRC re-establishment request message (RRCReestablishmentRequest) to the base station device 200. The RRC re-establishment request message is transmitted through SRB0. Since no PDCP entity exists in SRB0, security processing by PDCP is not performed on the RRC re-establishment request message. Furthermore, when an RRC re-establishment message (RRCReestablishment), which is a response message to the RRC re-establishment request message, is received from the base station device 200, the security key of the terminal device 200 is updated.
[0131] <Conditional Handover> A conditional handover (CHO) is a handover that is executed (initiated) by the terminal device 100 when one or more handover execution conditions are satisfied. The terminal device 100 receives an RRC reconfiguration message including conditional reconfiguration parameters from the base station device 200 and stores the conditional reconfiguration parameters. The conditional reconfiguration parameters include one or more pairs of configuration parameters for a PCell changeover target candidate, including synchronization reconfiguration parameters, and execution condition parameters for executing a handover to the PCell changeover target candidate. The execution condition parameters include, for example, parameters related to measurement configuration. Upon receiving the conditional reconfiguration parameters, the terminal device 100 starts cell measurement. If any PCell of the measured cells satisfies the execution conditions, the terminal device 100 applies the configuration parameters of the PCell changeover target candidate for the PCell that satisfies the execution conditions and performs a conditional handover to this PCell. After the conditional handover is successful, the terminal device 100 releases the conditional reconfiguration parameters.
[0132] The conditional reconfiguration parameters can include one or more pairs of SCG-side configuration, i.e., configuration parameters of a PSCell change destination candidate and execution condition parameters for executing a change to the PSCell change destination candidate. Upon receiving the SCG-side conditional reconfiguration parameters, the terminal device 100 starts measuring the execution conditions, and if the measurement result satisfies the execution conditions, performs a conditional PSCell addition / change (Conditional PSCell Addition Change: CPAC).
[0133] In a conditional handover, a handover failure is detected in the same way as in a non-conditional handover (hereinafter, sometimes simply referred to as a handover), and processing after the handover failure is performed. In a conditional handover failure or in a procedure for re-establishing an RRC connection after a handover failure, or in a procedure for re-establishing an RRC connection after a radio link failure, if the selected cell is a PCell changeover candidate, the terminal device 100 can transmit an RRC reconfiguration complete message to the base station device 200 instead of transmitting an RRC re-establishment request message to attempt handover and recover the RRC connection. Note that, when the cell selected by the terminal device 100 is a PCell changeover candidate, the terminal device 100 can transmit an RRC reconfiguration complete message to the base station device 200 instead of transmitting an RRC re-establishment request message only if a conditional reconfiguration attempt parameter (attemptCondReconfig), which is a parameter that permits this processing, is set in the terminal device 100.
[0134] Note that conditional handover and non-conditional handover may be referred to as handover without distinction.
[0135] <Intra-CU LTM Cell Switching> An example of an outline of cell switching in L1 / L2 Triggered Mobility (LTM) specified in Rel-18 will be described.
[0136] Fig. 9 is a diagram showing an example of parameters related to LTM included in an RRC Reconfiguration message (RRC reconfiguration message). Note that the parameters described in Fig. 6 are omitted in Fig. 9. Furthermore, parameters other than the example parameters shown in Fig. 9 may be included in the RRC reconfiguration message. Furthermore, the names of the parameters are merely examples and do not have to be as shown.
[0137] Format E2 is a parameter of RRC Reconfiguration. RRC Reconfiguration includes ltm-Config, which means LTM configuration. If LTM-Config is included in SetupRelease, LTM configuration is newly configured or changed. If SetupRelease does not include any ltm-Config, it means release of LTM configuration.
[0138] Format E21 is a parameter included in the LTM configuration. ltm-ReferenceConfiguration is a reference configuration described later. ltm-CandidateToAddModList is a list of LTM candidate cell configurations. In other words, ltm-CandidateToAddModList is a list of LTM candidate cell configurations and includes one or more LTM candidate cell configurations. ltm-ServingCellNoResetID is an identifier used by the terminal device 100 when determining whether or not an L2 reset (Layer 2 reset) is required at the time of cell switching described later. The ltm-ServingCellNoResetID or the initial value of ltm-ServingCellNoResetID may be a group identifier of the serving cell used when the base station device 200 transmits an RRC reconfiguration message including an LTM configuration to the terminal device 100 in step S1001 described later. ltm-ServingCellNoResetID is stored in the terminal device 100 as a value indicating the group identifier of the current serving cell. attemptLTM-Switch is a parameter having the same meaning as the conditional reconfiguration attempt parameter (attemptCondReconfig) in conditional handover, and is a parameter that permits recovery of the RRC connection after a cell switching failure, a handover failure, or a radio link failure.
[0139] Format E211 is a parameter included in the LTM candidate cell configuration list. LTM-Candidate is an LTM candidate cell configuration. ltm-CandidateId included in the LTM candidate cell configuration is an identifier or index that uniquely identifies one or more configured LTM candidate cell configurations within the terminal device 100. ltm-CandidateConfig is a parameter for generating a configuration to be used at the cell switching destination (target), and includes a part of the RRCReconfiguration parameters described in FIG. 6. ltm-CandidateConfig may be a complete configuration, as described below, or may be a delta configuration. ltm-CandidateConfig may be configured with parameters included in the RRC reconfiguration message. The ltm-NoResetID is an identifier used by the terminal device 100 when determining whether or not an L2 reset (Layer 2 reset) is required during cell switching, which will be described later. The ltm-NoResetID may be a group identifier of LTM candidate cells. A different value may be assigned to the ltm-NoResetID for each DU (Distributed Unit). For example, '1' may be set for all LTM candidate cells under DU1, and '2' may be set for all LTM candidate cells under DU2.
[0140] FIG. 10 is a diagram showing an example of an intra-CU LTM sequence.
[0141] The base station device 200 includes one or more cell change destination candidate settings (target cell candidate settings) in an RRC reconfiguration message and transmits the message to the terminal device 100 (S1001).
[0142] Upon receiving an RRC reconfiguration message (S1001), the terminal device 100 stores the LTM configuration information (including the configuration of candidate cell change destinations) included in the received message. The terminal device 100 may also store the value of ltm-ServingCellNoResetID included in the LTM configuration in a variable indicating the group identifier of the current serving cell.
[0143] Note that the cell change destination candidate may be, for example, only the PCell or may include the SCell. The configuration of each cell change destination candidate may be uniquely identified within the terminal device 100 using an index (ltm-CandidateId). Furthermore, the configuration of the cell change destination candidate may not include a parameter indicating an update of the security key. In other words, the security key by LTM may not be updated. Furthermore, the configuration of the cell change destination candidate may include parameters similar to the synchronized reconfiguration parameters.
[0144] The terminal device 100 may retain the configuration of the cell change destination candidate received and stored in step S1001 without releasing it after the cell change is successful, as described below. In this case, the retained configuration of the cell change destination candidate may be used for a subsequent cell switch. However, when the configuration of the cell change destination candidate is retained and used for a subsequent cell switch, it may not be possible to set the configuration of the cell change destination candidate to a delta configuration and apply the delta configuration to the source configuration to generate a target cell configuration. This phenomenon occurs because the source configuration differs depending on the order of cells changed by cell switch.
[0145] For this reason, in step S1001, the RRC reconfiguration message may include a reference configuration in addition to the configuration of the cell change destination candidate, or as part of the configuration of the cell change destination candidate. The reference configuration is used, for example, to complete the configuration to be used at the cell change destination (target). When the RRC reconfiguration message includes a reference configuration, the configuration of each cell change destination candidate included in the RRC reconfiguration message may be a differential configuration (delta configuration) from the reference configuration. In other words, the terminal device 100 can generate the configuration to be used at the cell change destination (target), i.e., the complete configuration to be used at the cell change destination, from the reference configuration and the configuration of the cell change destination candidate (delta configuration). For example, when the terminal device 100 receives a cell change signal to cell X, which is a cell change destination candidate, from the base station device 200 in step S1002 described below, the terminal device 100 generates the configuration to be used in cell X by applying the configuration of cell X to the reference configuration.
[0146] Also, in step S1001, the RRC reconfiguration message may not include a reference configuration. When the RRC reconfiguration message does not include a reference configuration, the configuration of each cell change destination candidate included in the RRC reconfiguration message is, for example, a complete configuration. That is, the terminal device 100 can generate the configuration to be used at the cell change destination (target) by replacing the configuration used in the current cell with the configuration of the cell change destination candidate. For example, in step S1002 described below, when the terminal device 100 receives a cell change signal to cell X, which is a cell change destination candidate, from the base station device 200, the terminal device 100 generates the configuration to be used in cell X by replacing the configuration of the current cell with the configuration of cell X. However, when the configuration of the cell change destination candidate is set to a complete configuration, some of the configurations may not be included. The partial configuration includes, for example, configurations that do not change due to cell change (fixed configurations). The configurations that do not change due to cell change (fixed configurations) include, for example, some or all of the radio bearer configurations. In this case, when the terminal device 100 receives a cell switching signal from the base station device 200 to cell X, which is a candidate cell change destination, it generates settings to be used in cell X by replacing the current cell settings with the cell X settings, except for fixed settings.
[0147] Note that, regardless of whether or not the RRC reconfiguration message includes a reference configuration, when generating a configuration to be used at the cell switching destination, the terminal device 100 does not need to reset some or all of the values of state variables, timers, etc. used in each entity (SDAP entity, PDCP entity, RLC entity, MAC entity, etc.) to their initial states. Furthermore, the terminal device 100 does not need to discard some or all of the buffers in each entity. In other words, the terminal device 100 can retain some or all of the values of state variables, timers, etc. used in each entity. Furthermore, the terminal device 100 may retain some or all of the buffers in each entity.
[0148] The base station device 200 transmits to the terminal device 100 a cell switching signal for switching the serving cell of the terminal device 100 from the current serving cell to one of the cell switching destination candidates (S1002).
[0149] The terminal device 100 receives a cell switching signal in the current serving cell (S1002). The cell switching signal may be, for example, a MAC CE. Alternatively, the cell switching signal may be a physical layer signal such as DCI.
[0150] The cell switching signal includes at least an index (ltm-CandidateId). The terminal device 100 applies the setting of the cell change destination (cell X) specified by the received cell switching signal. Note that cell X may be configured only with a PCell, may be configured only with a PSCell, or may be configured with a PCell or a PSCell and one or more SCells.
[0151] The terminal device 100 performs four-step or two-step contention-free random access (CFRA) or contention-based random access (CBRA) between the base station device 200 in cell X in accordance with the settings of cell X (S1003). Also, for example, if the settings of cell X include a parameter indicating that a RACH-less cell switch is to be performed, or if early TA acquisition, which will be described later, has been performed, the random access process in step S1003 is not executed. Also, if the ltm-NoResetID of cell X is the same as the ltm-ServingCellNoResetID or a variable indicating the group identifier of the current serving cell, the terminal device 100 does not perform an L2 reset. Furthermore, if the ltm-NoResetID of cell X is not the same as the ltm-ServingCellNoResetID or the variable indicating the group identifier of the current serving cell, the terminal device 100 performs an L2 reset and overwrites the ltm-ServingCellNoResetID or the variable indicating the group identifier of the current serving cell with the ltm-NoResetID of cell X. The L2 reset is, for example, an RLC re-establishment. The L2 reset is, for example, a PDCP data recovery.
[0152] The terminal device 100 transmits a notification indicating that the cell has been switched to the base station device 200 in cell X (S1004). This notification corresponds to an RRC reconfiguration complete message in handover or conditional handover. The notification indicating that the cell has been switched may use an RRC message such as an RRC reconfiguration complete message or a MAC CE. Furthermore, the notification indicating that the cell has been switched may use a physical signal such as UCI.
[0153] Furthermore, the notification indicating that the cell has been switched may include at least an identifier of cell X of the terminal device 100. Note that, if two-step CFRA or CFRA has been performed in step S1003, the notification indicating that the cell has been switched is transmitted before receiving the random access response in step S1003. Furthermore, uplink data generated in the DRB may be transmitted together with the notification indicating that the cell has been switched.
[0154] If a four-step or two-step CBRA is performed in step S1003, or if a RACH-less cell switch is performed, the base station device 200 transmits to the terminal device 100 a signal including a contention resolution signal or information indicating that the notification transmitted from the terminal device 100 in step S1004 has been successfully received (hereinafter, this may be referred to as reception success information).
[0155] Furthermore, the terminal device 100 receives, for example, a contention resolution signal or a signal including reception success information in cell X. The contention resolution signal or the reception success information may include at least an identifier of the terminal device 100 in cell X.
[0156] The timing of successful cell switching may be the same as that of successful handover in handover or conditional handover. That is, in the case of cell switching using four-step or two-step CFRA, the cell switching is successful when a random access response is received. Also, in the case of cell switching using four-step or two-step CBRA, or RACH-less cell switching, the cell switching is successful when the processing of step S1005 is performed. If the timing of successful cell switching is the same as that of successful handover in handover or conditional handover, as in handover or conditional handover, in cell switching using four-step CFRA, no notification indicating the cell switching or uplink data generated in the DRB is transmitted before the cell switching is successful. However, in the case of cell switching using four-step CBRA, cell switching using two-step CFRA or CBRA, and RACH-less cell switching, a notification indicating the cell switching is transmitted before the cell switching is successful. Additionally, uplink data generated by the DRB may be transmitted along with a notification indicating that the cell has been changed.
[0157] After executing step S1001, the terminal device 100 may perform downlink synchronization and / or uplink synchronization with one or more cell change destination candidates before transmitting the cell change destination signal in step S1002. In uplink synchronization, the base station device 200 may measure a timing advance (TA) of the terminal device 100 for one or more cell change destination candidates. Uplink synchronization may be performed by the base station device 200 instructing the terminal device 100 to transmit a random access preamble. The base station device 200 may instruct the terminal device 100 to transmit different random access preambles to one or more cell change destination candidates, or may instruct the terminal device 100 to transmit a common random access preamble to a group of multiple cell change destination candidates. The TA measured by the base station device 200 may be transmitted to the terminal device 100 using a random access response (RAR), or may be transmitted to the terminal device 100 using the cell change destination signal in step S1002. In this way, performing uplink synchronization after the terminal device 100 executes step S1001 and before the cell switching signal is sent in step S1002 may be called early TA measurement or early TA acquisition.
[0158] Note that cell switching may be referred to as LTM or LTM cell switching. Cell switching may also be referred to as other terms that represent cell switching by LTM. Hereinafter, cell switching and cell change may be treated as terms that mean the same thing.
[0159] In addition, in this embodiment, unless there is a particular distinction between cell switching of an MCG and cell switching of an SCG, cell switching is considered to be cell switching of an MCG.
[0160] In addition, in the setting of the cell change destination candidate of the MCG in the LTM setting, a synchronization reset parameter may be included under the MCG setting parameter. Similarly, in the setting of the cell change destination candidate of the SCG in the LTM setting, a synchronization reset parameter may be included under the SCG setting parameter. Therefore, the cell switching of the MCG may be referred to as a handover. Furthermore, the cell switching of the SCG may be referred to as a PSCell change.
[0161] <LTM Cell Switching Failure Processing> When the LTM cell switching fails, an RRC connection re-establishment procedure may be executed, similar to the handover failure processing and the conditional handover failure processing.
[0162] Fig. 11 is a diagram showing an example of a sequence of detecting a cell switching failure and processing the cell switching failure. The processing of steps S1001 and S1002 in Fig. 11 is the same as the processing of steps S1001 and S1002 in Fig. 10, and therefore a description thereof will be omitted.
[0163] When the terminal device 100 receives a cell switching signal (S1002), it starts a timer to detect cell switching failure (S1101) and starts cell switching processing to the cell (cell X) specified by the received cell switching signal (not shown).
[0164] If the cell switch is successful before the timer expires, the terminal device 100 stops the timer (not shown). On the other hand, if the timer expires, the terminal device 100 detects that the cell switch to cell X has failed (S1102).
[0165] When the terminal device 100 detects a cell switching failure (S1102), the terminal device 100 performs a cell switching failure process (S1103). In the cell switching failure process, the terminal device 100 may return the settings of the terminal device 100 to the settings used in the source PCell and perform an RRC connection re-establishment procedure.
[0166] Cell selection is performed in the RRC connection re-establishment procedure. If the cell selected in cell selection is one of the LTM candidate cells, the terminal device 100 can autonomously perform LTM cell switching to the selected cell. This is called fast LTM recovery or fast recovery. When performing fast LTM recovery, cell switching is initiated in the terminal device 100. Note that the terminal device 100 performs fast LTM recovery only when the LTM configuration includes a parameter indicating that fast LTM recovery is to be performed. Note that fast recovery is not limited to LTM. Fast recovery is also performed in, for example, CHO. In other words, fast recovery means that if the selected cell in the cell selection in the RRC connection re-establishment procedure after cell switching or handover failure is one of the candidate cells configured in the terminal device 100, the terminal device 100 autonomously performs cell switching or handover to this cell.
[0167] <Updating AS Security Keys During Handover> AS security processing is performed in the PDCP entities of radio bearers other than SRB0 using encryption keys and integrity protection keys generated by RRC. AS security processing includes ciphering and integrity protection, which are performed using encryption keys and integrity protection keys, respectively. The encryption keys and integrity protection keys used in SRBs other than SRB0 and DRBs are generated from a security key called KgNB. A common KgNB is generated by each of the base station device 200 and the terminal device 100. Hereinafter, unless otherwise specified, KgNB will be referred to as the security key.
[0168] In the case of handover within a base station device or within a control unit (CU), security key update is optional. That is, the base station device 200 may or may not instruct the terminal device 100 to update the security key. However, in the case of handover between base station devices or between control units (CU), security key update is mandatory. That is, the base station device 200 instructs the terminal device 100 to update the security key.
[0169] A method for updating a security key will now be described. When a security key update is necessary, the base station device 200 transmits to the terminal device 100 an RRC reconfiguration message including a MasterKeyUpdate parameter (master key update parameter) shown in format E13 of FIG. 6 . The master key update parameter includes a keySetChangeIndicator (key set change instruction) or a nextHopChainingCount (NCC). The key set change instruction is information indicating true or false, and the NCC is a non-negative integer. The initial value of the NCC is zero ('0'), and the terminal device 100 stores NCC=0 in the initial state.
[0170] If the key set change instruction of the master key update parameter is set to "true", the terminal device 100 generates a new KgNB from the NAS security key (called KAMF) of the terminal device 100.
[0171] Furthermore, if the key set change instruction of the master key update parameter is not set to "true," i.e., if it is set to "false," the terminal device 100 generates a new key according to the NCC value of the master key update parameter. In this case, the terminal device 100 generates a new key using the original key information and target cell information. If the NCC value of the master key update parameter is the same as the NCC value stored in the terminal device 100 or the NCC value previously received from the base station device 200, a security key is generated using the currently used KgNB as the original key information. This is called horizontal derivation. Furthermore, if the NCC value of the master key update parameter is different from the NCC value stored in the terminal device 100 or the NCC value previously received from the base station device 200, a new security key is generated using the NH (Next Hop) corresponding to the received NCC value as the original key information. This is called vertical derivation. The target cell information used when generating a new security key is, for example, a physical cell identity (PCI) or an absolute radio frequency channel number (ARFCN).
[0172] On the other hand, when the base station device 200 transmits an RRC reconfiguration message including a master key update parameter to the terminal device 100, if the base station device 200 is instructed by the AMF, which is a node in the core network, to use a new KgNB generated by the AMF, the base station device 200 sets the key set change instruction to "true." Furthermore, if the base station device 200 is not instructed by the AMF to use a new KgNB generated by the AMF, the base station device 200 sets the key set change instruction to "false." Furthermore, the base station device 200 determines the NCC value based on whether a new NCC and NH pair issued by the AMF has been used for the terminal device 100. If a new NCC and NH pair has not been used, the base station device 200 sets this new NCC value as the NCC. If a new NCC and NH pair has already been used, the base station device 200 sets the same NCC value as the previous NCC value as the NCC. The NCC value is incremented by 1 each time a new NCC and NH pair is issued by the AMF. Furthermore, when the terminal device 100 performs a handover from a certain base station device 200 (base station device 200-A) to a different base station device 200 (base station device 200-B), and the base station device 200-B transmits a path switch request to the AMF for this terminal device 100, the AMF issues a new NCC and NH pair for this terminal device 100 and transmits it to the base station device 200-B. [Embodiments] Each embodiment will be described below.
[0173] <Subsequent cell switching within and between CUs> The LTM specification defined in Rel-18 targets cell switching within a CU and does not support security key updating. However, security key updating is required for cell switching between CUs, which is within the scope of Rel-19.
[0174] In CHO, if the target PCell belongs to a different CU, the configuration parameters of the PCell changeover candidate must include a parameter indicating a security key update, i.e., a master key update parameter (masterKeyUpdate parameter). Therefore, even in the case of inter-CU CHO, the security key is updated according to the master key update parameter. Furthermore, in CHO, after CHO is performed, the terminal device 100 releases the CHO configuration, and the base station device 200 performs new CHO configuration on the terminal device 100. Therefore, even after inter-CU CHO is performed, CHO that supports both intra-CU and inter-CU can be performed by newly configuring a PCell changeover candidate using an RRC reconfiguration message. However, when performing subsequent cell switching, the LTM candidate cell configuration is not updated using an RRC reconfiguration message, so a method for appropriately updating the security key in the terminal device 100 is required.
[0175] <Subsequent cell switching method 1 for intra-CU and inter-CU> A first example of a subsequent cell switching method for intra-CU and inter-CU is to not support subsequent cell switching after inter-CU cell switching.
[0176] When the base station device 200 performs LTM configuration on the terminal device 100, for example, the base station device 200 does not include a master key update parameter in the configuration of an LTM candidate cell that belongs to the same CU as the CU to which the current serving cell of the terminal device 100 belongs, but includes a master key update parameter in the configuration of an LTM candidate cell that belongs to a CU different from the CU to which the current serving cell of the terminal device 100 belongs.
[0177] When performing cell switching, if the target LTM candidate cell configuration includes a master key update parameter, the terminal device 100 deletes some or all of the parameters related to the LTM configuration after the cell switching is successful. The parameters to be deleted include, for example, at least a list of LTM candidate cell configurations. After the inter-CU LTM cell switching, the base station device 200 performs, for example, new LTM configuration or updates the LTM configuration for the terminal device 100. This allows the terminal device 100 to perform cell switching corresponding to both intra-CU and inter-CU again.
[0178] After the cell switch is successful, the terminal device 100 does not release, for example, some or all of the parameters related to the LTM setting. In this case, for example, the base station device 200 updates the LTM setting for the terminal device 100, so that the terminal device 100 can again perform cell switch corresponding to the intra-CU and inter-CU.
[0179] <Subsequent Cell Switching Method 2 Corresponding to Intra-CU and Inter-CU> A second example of a subsequent cell switching method corresponding to intra-CU and inter-CU will be described using Fig. 12. Fig. 12 is a diagram showing an example of a subsequent cell switching method corresponding to intra-CU and inter-CU. Note that this method described using Fig. 12 may be performed in addition to some or all of the processing of the intra-CU LTM cell switching processing described using Fig. 10. Note that the processing from step S1203 onwards may also be applied when the terminal device 100 performs fast LTM recovery.
[0180] The base station device 200 includes parameters related to LTM in an RRC reconfiguration message and transmits the message to the terminal device 100 (S1201). The parameters related to LTM include, for example, an LTM configuration including one or more LTM candidate cell configurations (target candidate cell configurations). Upon receiving the RRC reconfiguration message, the terminal device 100 stores the LTM configuration included in the received message.
[0181] Here, the parameters related to LTM included in the RRC reconfiguration message may include parameters other than the parameters described using FIG.
[0182] The LTM-related parameters included in the RRC reconfiguration message other than the parameters described using FIG. 9 are, for example, parameters that allow the terminal device 100 to determine whether or not a security key update is required when the terminal device 100 performs cell switching. The parameter that allows the terminal device 100 to determine whether or not a security key update is required may be, for example, a group identifier set in each LTM candidate cell. Here, for example, the group identifier set in each LTM candidate cell, which is used as a parameter that allows the terminal device 100 to determine whether or not a security key update is required, is referred to as a security update no longer required identifier parameter. The security update no longer required identifier parameter may be an identifier included in each LTM candidate cell configuration, separate from the ltm-NoResetID included in the LTM candidate cell configuration (LTM-Candidate) in format E211 of FIG. 9. A different value may be assigned to the security update no longer required identifier parameter for each CU. For example, a security update no longer required identifier parameter '1' may be set for all LTM candidate cells under CU1, and a security update no longer required identifier parameter '2' may be set for all LTM candidate cells under CU2. When performing cell switching, the terminal device 100 determines that a security key update is not required if the value of the security update no longer required identifier parameter included in the target LTM cell candidate configuration is the same as the value of the security update no longer required identifier parameter of the current serving cell or the value stored in the terminal device 100 as the security update no longer required identifier parameter of the current serving cell. If the values are different, the terminal device 100 determines that a security key update is required. In addition, the initial value of the security update no longer required identifier parameter of the current serving cell may be set separately from the security update no longer required identifier parameter. The initial value of the security update no longer required identifier parameter of the current serving cell may be an identifier included under the LTM configuration, separate from ltm-ServingCellNoResetID, which is included in the LTM configuration (LTM-Config) of format E21 in FIG. 9 .
[0183] Another setting method of a parameter that enables the terminal device 100 to determine whether or not a security key update is required when the terminal device 100 performs cell switching (a method that does not use the above-mentioned security update unnecessary identifier parameter) is to further group the ltm-NoResetIDs included in the LTM candidate cell setting in format E211 of Fig. 9 as a security update unnecessary group, for example. For example, suppose that an LTM candidate cell to which ltm-NoResetID = '1' is set and an LTM candidate cell to which ltm-NoResetID = '2' is set are both cells under CU1, and an LTM candidate cell to which ltm-NoResetID = '3' is set and an LTM candidate cell to which ltm-NoResetID = '4' is set are both cells under CU2. In this case, for example, ltm-NoResetIDs '1' and '2' are set to security update-free group 1, and ltm-NoResetIDs '3' and '4' are set to security update-free group 2. The security update-free group may be included, for example, in a security update-free group parameter. The security update-free group parameter may include a security update-free group consisting of an identifier of the security update-free group and a list of ltm-NoResetIDs. The security update-free group parameter may be included, for example, under LTM configuration (LTM-Config). When performing cell switching, the terminal device 100 determines that a security key update is not required if the value of the security update-not required group identifier of the security update-not required group to which the ltm-NoResetID included in the target LTM cell candidate configuration belongs is the same as the group identifier of the current serving cell (ltm-ServingCellNoResetID) or the value of the security update-not required group identifier of the security update-not required group to which the identifier stored in the terminal device 100 as the group identifier of the current serving cell belongs, and determines that a security key update is required if they are different. Note that, for example, instead of using ltm-NoResetID, ltm-CandidateId may be used to classify security update-not required groups.
[0184] Note that a method for setting a parameter that enables the terminal device 100 to determine whether or not a security key needs to be updated when the terminal device 100 switches cells may be other than the above. Also, the names of the security update no longer required identifier parameter and the security update no longer required group parameter described above may be called by other names.
[0185] Furthermore, the parameter related to LTM other than the parameter described with reference to Fig. 9 and included in the RRC reconfiguration message is, for example, a parameter indicating a key generation method when updating a security key. The parameter indicating the key generation method may be, for example, a parameter specifying either "horizontal generation" or "vertical generation." Furthermore, for example, if a parameter indicating a key generation method when updating a security key is not included, this may mean that vertical generation is performed.
[0186] Furthermore, parameters related to LTM other than the parameters described with reference to Fig. 9 and included in the RRC reconfiguration message include, for example, a list of NCCs used to generate a security key. When performing vertical generation of a security key, the terminal device 100 generates a new security key using, for example, an NH corresponding to the value of the first NCC in the set NCC list as original key information. For example, when the generation of a new security key is completed, the terminal device 100 may delete the NCC corresponding to the NH used as the original key information from the NCC list.
[0187] Furthermore, the parameters related to LTM other than the parameters described using FIG. 9 and included in the RRC reconfiguration message are parameters indicating that the security key is to be updated in accordance with, for example, information included in a cell switching signal or information included in another signal.
[0188] Note that some or all of the parameters related to LTM other than the parameters described with reference to FIG. 9 that are included in the RRC reconfiguration message described above may not be included as parameters related to LTM.
[0189] When receiving the RRC reconfiguration message, the terminal device 100 stores parameters related to LTM included in the received message. If the LTM configuration includes an initial value of the security update no longer required identifier parameter of the current serving cell, the terminal device 100 may store this value as a value indicating the security update no longer required identifier parameter of the current serving cell.
[0190] The base station device 200 transmits to the terminal device 100 a cell switching signal for switching the serving cell of the terminal device 100 from the current serving cell to one of the LTM candidate cells, thereby initiating cell switching in the terminal device 100 (S1202).
[0191] The terminal device 100, which has received the cell switching signal and initiated cell switching, determines whether or not a security key update is required for cell switching to the target cell (S1203). To determine whether or not a security key update is required, for example, the above-mentioned parameter that enables the terminal device 100 to determine whether or not a security key update is required may be used. Furthermore, to determine whether or not a security key update is required, the terminal device 100 may determine from information included in the cell switching signal or information included in another signal transmitted from the base station device 200 simultaneously with the cell switching signal.
[0192] If the security key does not need to be updated, the terminal device 100 performs cell switching without updating the security key. If the security key needs to be updated, the terminal device 100 updates the security key (S1204).
[0193] The security key update method follows, for example, the parameters indicating the key generation method described above. For example, when a list of NCCs is not set in the terminal device 100 and vertical generation is performed, the terminal device 100 adds 1 to the value of the NCC it holds or the NCC used in the previous security key update, and performs security key update using the NH corresponding to this value as the original key information. Vertical generation is an example of a first generation method. In the first generation method, a security key is generated using a first key corresponding to a first value (e.g., a value corresponding to the NCC). In the case of horizontal generation, the terminal device 100 generates a security key using the currently used KgNB as the original key information. Key horizontal generation is an example of a second generation method. In the second generation method, a security key is generated using a second key corresponding to a second value (e.g., a value corresponding to the currently used KgNB). When it is necessary for the terminal device 100 to use a security key generated from the KAMF, the base station device 200 includes a master key update parameter in an RRC reconfiguration message, sets the key set change instruction to "true", and transmits the message to the terminal device 100. At this time, the RRC reconfiguration message may include a parameter for updating the LTM setting.
[0194] Furthermore, the method of updating the security key is based on, for example, information included in the cell switching signal or information included in another signal simultaneously transmitted from the base station device 200 with the cell switching signal. The process of determining whether or not a security key update is necessary and / or using the information included in the cell switching signal or information included in another signal simultaneously transmitted from the base station device 200 with the cell switching signal may be performed when a parameter indicating that the security key is to be updated in accordance with the information included in the above-mentioned cell switching signal or information included in the other signal is set in the terminal device 100.
[0195] The information included in the cell switching signal, or another signal sent from the base station device 200 simultaneously with the cell switching signal, includes, for example, a parameter indicating whether a security key update is necessary and / or a parameter indicating a method for updating the security key.
[0196] For example, the information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes only a parameter indicating whether a security key update is necessary. If the parameter indicating whether a security key update is necessary indicates that a security key update is necessary, the terminal device 100 updates the security key in accordance with, for example, the parameter indicating the key generation method described above.
[0197] Furthermore, for example, information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes, as parameters indicating a security key update method, information on part or all of the key set change instruction and NCC, which are master key update parameters included in the RRC reconfiguration message. The terminal device 100 updates the security key, for example, in accordance with the parameters indicating the security key update method.
[0198] Furthermore, for example, information included in the cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal includes a parameter indicating whether or not a security key update is necessary and / or the security key update method, using number information such as '0' for no security update, '1' for horizontal generation, '2' for vertical generation, '3' for key set change instruction = "true", etc. When a security key update is necessary, the terminal device 100 updates the security key in accordance with, for example, the parameter indicating the security key update method.
[0199] Note that when the information included in the above-mentioned cell switching signal or another signal sent from the base station device 200 simultaneously with the cell switching signal does not include information related to a key set change instruction, and when the base station device 200 needs to cause the terminal device 100 to use a security key generated from the KAMF, the base station device 200 includes a master key update parameter in an RRC reconfiguration message, sets the key set change instruction to "true", and transmits the message to the terminal device 100. At this time, the RRC reconfiguration message may include a parameter for updating the LTM setting.
[0200] The terminal device 100 performs cell switching to the target cell (S1205).
[0201] When cell switching to the target cell is successful, the terminal device 100 transmits an RRC reconfiguration completion message (S1206). The terminal device 100 may include an NCC value used when generating the security key in the RRC reconfiguration completion message. Note that the terminal device 100 retains the LTM configuration and / or LTM candidate cell configuration received and stored in step S1201 without releasing it. The retained LTM configuration and / or LTM candidate cell configuration are used for subsequent LTM cell switching.
[0202] In addition, when "horizontal generation" is set by the parameter indicating the key generation method described above, and the terminal device 100 performs cell switching to a target cell by updating a security key using horizontal generation, for example, immediately after successful cell switching to the target cell, the terminal device 100 may vertically generate a security key with the same cell as the target cell and autonomously perform cell switching to the same cell. The terminal device 100 that has performed cell switching to the same cell transmits, for example, an RRC reconfiguration completion message. At this time, the RRC reconfiguration completion message may include the NCC value used when generating the security key. In this case, the terminal device 100 and the base station device 200 do not transmit or receive, for example, user data and / or RRC messages having a DCCH other than the RRC reconfiguration completion message, from the time the terminal device 100 updates the security key using horizontal generation and starts cell switching to the target cell until the process of vertically generating a security key in the target cell and autonomously performing cell switching to the same cell is successfully completed.
[0203] In addition, when the terminal device 100 updates the security key using horizontal generation when switching to a target cell, the base station device 200 may send an RRC reconfiguration message including, for example, a master key update parameter to the terminal device 100, and cause the terminal device 100 to perform an intra-CU handover involving updating the security key using vertical generation.
[0204] Furthermore, when the terminal device 100 updates the security key using horizontal generation during cell switching to a target cell, the base station device 200 may change the RRC reconfiguration message to include a master key update parameter, and may cause the terminal device 100 to perform an intra-CU handover involving updating the security key using vertical generation, using a cell switching signal or a signal other than the cell switching signal. The base station device 200 may perform this processing when setting, in the terminal device 100, a parameter indicating that the security key will be updated, for example, in accordance with information included in the above-mentioned cell switching signal or information included in another signal.
[0205] These processes are necessary to ensure that security keys using horizontal generation are updated consistently at the time of the next inter-CU cell switching of the terminal device 100.
[0206] In addition, before setting parameters related to LTM for the terminal device 100 in step S1201, the base station device 200 transmits, for example, to a different CU (base station device) to which the LTM candidate cell belongs, information on the NCC to be used by the terminal device when performing inter-CU LTM cell switching, together with information on the terminal device 100.
[0207] In addition, in the second example of the subsequence cell switching method corresponding to the intra-CU and inter-CU switching, an upper limit may be set on the number of CUs to which LTM candidate cells set in the terminal device 100 belong. For example, the number of CUs to which LTM candidate cells set in the terminal device 100 belong may be set to up to two.
[0208] <Fast LTM Recovery for Intra-CU and Inter-CU> In a cell switch or handover involving security key update, or a handover (mobility) to a RAT other than NR, the terminal device 100 and the base station device 200 may erase all values and data used in the source cell. Therefore, fast LTM recovery after a cell switch or handover failure involving security key update poses implementation issues and needs to be avoided. Therefore, the terminal device 100 does not perform fast LTM recovery, for example, after an inter-CU LTM cell switch failure. Furthermore, the terminal device 100 does not perform fast LTM recovery not only after an inter-CU LTM cell switch failure, but also, for example, if a failed handover (MCG synchronized reconfiguration) involves security key update, or after a handover (mobility) failure to a RAT other than NR.
[0209] The terminal device 100 performs an RRC connection reconnection means when cell switching fails, etc. The RRC connection reconnection means performs cell selection, and if at least all of the following conditions (1) to (5) are met, the terminal device 100 performs fast LTM recovery for the selected cell. Furthermore, if some or all of the following conditions (1) to (5) are not met, fast LTM recovery is not performed.
[0210] (1) A parameter indicating that fast LTM recovery is to be performed (a parameter named attemptLTM-Switch) is set.
[0211] (2) The selected cell is one of the LTM candidate cells. (3) A failed cell switch or a failed handover (synchronized reconfiguration of MCG) does not involve security key update.
[0212] (4) This is not a means for reconnecting an RRC connection initiated due to a handover (mobility) failure to a RAT other than NR.
[0213] (5) A means for reconnecting an RRC connection initiated by a Radio Link Failure (RLF).
[0214] When performing fast LTM recovery, cell switching is initiated in the terminal device 100. When performing fast LTM recovery, the terminal device 100 follows part or all of the processing of the subsequence cell switching method 2 corresponding to intra-CU and inter-CU, which was described using Fig. 12. For example, when performing fast LTM recovery, the terminal device 100 determines whether a security key needs to be updated for cell switching to the target cell, and if a security key update is required, updates the security key.
[0215] This embodiment enables flexible communication corresponding to subsequence cell switching within a CU and between CUs. It also makes it possible to avoid fast LTM recovery after cell switching failure that involves security key update, thereby avoiding implementation issues.
[0216] <Others> Although the present embodiment has been described using the case of LTM, the present embodiment can be applied to other technologies and methods. For example, the method of determining on the terminal device 100 side whether or not a security key update is necessary, the method of setting and / or notifying the security key update method, the processing after cell switching or handover failure, and the like in the present embodiment may be applied to a method in which candidates for a synchronized reset destination are set, such as CHO or CPAC.
[0217] The messages in the above sequence may be partially executed out of order or partially reordered. Also, some messages in the sequence may not be executed at all.
[0218] Furthermore, what is described as a function or process of the terminal device 100 may be a function or process of the base station device 200. Furthermore, what is described as a function or process of the base station device 200 may be a function or process of the terminal device 100.
[0219] Furthermore, when the term "radio bearer" is used without distinguishing between a signaling radio bearer and a data radio bearer, the radio bearer may be a signaling radio bearer, a data radio bearer, or both a signaling radio bearer and a data radio bearer.
[0220] Furthermore, "A may be replaced with B" and "A may be replaced with B" include the meaning of replacing B with A in addition to replacing A with B.
[0221] Furthermore, if condition "A" and condition "B" are contradictory conditions, condition "B" may be expressed as an "other" condition of condition "A."
[0222] To summarize, the following is the case.
[0223] (1) A terminal device having a receiving unit that receives a signal from a first base station device and a processing unit, wherein the receiving unit receives a first signal including a security key generation method parameter and a first candidate cell setting for a first cell, and the processing unit determines whether a security key needs to be updated when cell switching to the first cell is initiated, and if it determines that a security key needs to be updated, generates a security key using a first key corresponding to a first value if the security key generation method parameter indicates a first generation method, and generates a security key using a second key corresponding to a currently used second value if the security key generation method parameter indicates a second generation method.
[0224] (2) The terminal device described in (1) determines whether the security key needs to be updated by determining that the security key needs to be updated if the group identifier included in the first candidate cell setting is different from the stored group identifier, and by determining that the security key does not need to be updated if the group identifier included in the first candidate cell setting is the same as the stored group identifier.
[0225] (3) The terminal device according to (1) or (2), wherein the processing unit further updates the security key using a third key corresponding to a third value when receiving a second signal from a second base station device.
[0226] Although an example of a device has been described in each embodiment, the method of the present disclosure is not limited to cellular phones, smartphones, tablet terminals, base station devices, etc., but can be applied to other electronic devices, such as electronic devices mounted on automobiles, trains, airplanes, artificial satellites, etc., electronic devices mounted on drones, etc., robots, AV equipment, home appliances, office equipment, vending machines, other household equipment, industrial equipment, and other devices.
[0227] In addition, in each embodiment, E-UTRA and NR are used as radio access technologies, and EPC and 5GC are used as core networks. However, the application of the method of the present disclosure is not limited to these. For example, the method of the present disclosure may be applied to radio access technologies and networks of different generations, such as 6th generation and 7th generation.
[0228] Furthermore, the present invention is not limited to the above-described embodiment, and various modifications can be made.
[0229] Although each embodiment has been described in detail with reference to the drawings, the specific configuration is not limited to the disclosed drawings and the described embodiments.
[0230] 10: Communication system 100: Terminal device 110: CPU 120: Storage 121: Wireless communication program 122: Terminal side program 130: Memory 140: Wireless communication circuit 200: Base station device 210: CPU 220: Storage 221: Wireless communication program 222: Base station side program 230: Memory 240: Wireless communication circuit 250: Network interface 300: Core network
Claims
1. A terminal device having a receiving unit that receives a signal from a first base station device and a processing unit, wherein the receiving unit receives a first signal including a security key generation method parameter and a first candidate cell setting for a first cell, and the processing unit, when cell switching to the first cell is initiated, determines whether a security key update is necessary, and if it is determined that a security key update is necessary, generates a security key using a first key corresponding to a first value if the security key generation method parameter indicates a first generation method, and generates a security key using a second key corresponding to a currently used second value if the security key generation method parameter indicates a second generation method.
2. The terminal device of claim 1, wherein the determination of whether the security key needs to be updated is made by: determining that the security key needs to be updated if the group identifier included in the first candidate cell setting is different from the stored group identifier; and determining that the security key does not need to be updated if the group identifier included in the first candidate cell setting is the same as the stored group identifier.
3. The terminal device according to claim 1 or claim 2, wherein the processing unit further updates the security key using a third key corresponding to a third value when a second signal is received from a second base station device.
4. A base station device comprising: a transmitting unit that transmits a signal to a terminal device; and a processing unit, wherein the transmitting unit transmits a first signal including a security key generation method parameter and a first candidate cell setting for a first cell; and wherein the processing unit, when cell switching to the first cell is initiated, causes the terminal device to determine whether a security key update is necessary; and, when the terminal device determines that a security key update is necessary, causes the terminal device to generate a security key using a first key corresponding to a first value if the security key generation method parameter indicates a first generation method, and causes the terminal device to generate a security key using a second key corresponding to a second value currently used by the terminal device if the security key generation method parameter indicates a second generation method.
5. The base station device of claim 4, wherein the determination of whether the security key needs to be updated is made by determining that the security key needs to be updated if the group identifier included in the first candidate cell setting is different from the stored group identifier, and by determining that the security key does not need to be updated if the group identifier included in the first candidate cell setting is the same as the stored group identifier.
6. The base station device according to claim 4 or claim 5, wherein the processing unit further controls the transmission of the second signal to the terminal device, and causes the terminal device to update its security key using a third key corresponding to a third value.
7. A wireless communication system comprising: a base station device that transmits a first signal including a security key generation method parameter and a first candidate cell setting for a first cell; and a terminal device that receives the first signal, wherein the terminal device, when cell switching to the first cell is initiated, determines whether a security key update is necessary; and, if it determines that a security key update is necessary, generates a security key using a first key corresponding to a first value if the security key generation method parameter indicates a first generation method; and generates a security key using a second key corresponding to a currently used second value if the security key generation method parameter indicates a second generation method.
Citation Information
Patent Citations
Method and apparatus for operating protocol layer of terminal in inactive mode in next-generation mobile communication system
US20190313333A1
Radio access network node, wireless terminal, core network node, and methods for these
WO2018029931A1
Method, device, and storage medium for implementing forward security
WO2020173451A1