Terminal devices and distributed units

Abstract

Embodiments of this disclosure relate to a communication device and method. A CU transmits security key update information for an LTM cell switchover to a DU. When a decision is made to perform an LTM cell switchover to a candidate cell, the DU transmits a MAC CE indicating the LTM cell switchover to the candidate cell to a terminal device. The MAC CE contains security key update information. The terminal device updates its security key based on the security key update information in the MAC CE. In this way, security key updates can be performed during inter-CU LTM, and an enhancement of inter-CU LTM can be achieved.

Description

[[Technical Field]]

[0001] Embodiments of the present disclosure generally relate generally to the field of telecommunications, and in particular, to communication apparatuses and methods for layer 1 (L1) / layer 2 (L2) triggered mobility (LTM). [[Background Art]]

[0002] As is known, it has been proposed to trigger change, addition or release of a serving cell through lower layer signaling such as L1 / L2 signaling, which is also referred to as LTM. LTM can reduce mobility latency. Currently, when the source cell and the target candidate cell belong to the same Central Unit (CU), only intra-CU LTM is supported. To further expand LTM scenarios, it is expected to support inter-CU LTM where the source cell and the target candidate cell belong to different CUs. [[Summary of Invention]]

[0003] In general, embodiments of the present disclosure provide communication methods, devices, and computer storage media for inter-CU LTM.

[0004] In a first aspect, a terminal device is provided. The terminal device comprises a processor. The processor is configured to cause the terminal device to: receive a Medium Access Control (MAC) Control Element (CE) indicating cell handover from a serving cell to a candidate cell from a Distributed Unit (DU) of a network device; and update a security key based on security key update information in accordance with a determination that the MAC CE comprises the security key update information.

[0005] In a second embodiment, a DU of a network device is provided. The DU comprises a processor. The processor is configured to cause the DU to receive security key update information from the CU of the network device for cell switching from a serving cell to a candidate cell that permits LTM, and to send a MAC CE containing security key update information indicating cell switching to a candidate cell to a terminal device in accordance with the decision that cell switching to a candidate cell is to be performed.

[0006] In a third aspect, a CU of a network device is provided. The CU comprises a processor. The processor is configured to cause the CU to send security key update information for cell switching from a serving cell to a candidate cell that will authorize LTM to the DU of the network device.

[0007] In a fourth aspect, a method of communication is provided. This method includes the steps of: a terminal device receiving a MAC CE from a DU of a network device indicating a cell switch from a serving cell to a candidate cell; and updating a security key based on security key update information, in accordance with the determination that the MAC CE contains security key update information.

[0008] In a fifth aspect, a method of communication is provided. This method includes the steps of: the DU of a network device receiving security key update information for cell switching from a serving cell to a candidate cell that permits LTM from the CU of a network device; and, in accordance with the decision that cell switching to a candidate cell is to be performed, sending a MAC CE containing security key update information indicating cell switching to a candidate cell to a terminal device.

[0009] In a sixth aspect, a method of communication is provided. This method includes the step of a CU of a network device sending security key update information for cell switching from a serving cell to a candidate cell that permits LTM to a DU of a network device.

[0010] In the seventh aspect, a computer-readable medium storing instructions is provided. When the instructions are executed on at least one processor, they cause at least one processor to perform a method according to any of the fourth to sixth aspects of the present disclosure.

[0011] Other features of this disclosure will be readily apparent from the following description.

[0012] The above and other purposes, features, and advantages of this disclosure will become more apparent through a more detailed description of some embodiments of this disclosure in the attached drawings. [Brief explanation of the drawing]

[0013] [Figure 1A] This figure shows an exemplary communication network in which several embodiments of this disclosure may be implemented.

[0014] [Figure 1B] This schematic diagram illustrates network protocol layer entities that may be established for a user plane (UP) protocol stack in a device according to some embodiments of the present disclosure.

[0015] [Figure 1C] This schematic diagram illustrates network protocol layer entities that may be established for a control plane (CP) protocol stack in a device according to some embodiments of the present disclosure.

[0016] [Figure 1D] This is a schematic diagram illustrating exemplary LTM procedures in which several embodiments of this disclosure may be implemented.

[0017] [Figure 2] This is a schematic diagram illustrating the communication process according to the embodiments of the present disclosure.

[0018] [Figure 3] It is a schematic diagram illustrating another communication process according to an embodiment of the present disclosure.

[0019] [Figure 4] It is a schematic diagram illustrating another communication process according to an embodiment of the present disclosure.

[0020] [Figure 5] It is a schematic diagram illustrating another communication process according to an embodiment of the present disclosure.

[0021] [Figure 6] It illustrates an exemplary communication method implemented in a terminal device according to some embodiments of the present disclosure.

[0022] [Figure 7] It is a diagram illustrating an exemplary communication method implemented in a Distributed Unit of a network device according to some embodiments of the present disclosure.

[0023] [Figure 8] It is a diagram illustrating an exemplary communication method implemented in a Centralized Unit of a network device according to some embodiments of the present disclosure.

[0024] [Figure 9] It is a simplified block diagram of a device suitable for implementing an embodiment of the present disclosure. DETAILED DESCRIPTION OF EMBODIMENTS

[0025] Throughout the drawings, identical or similar reference numerals represent identical or similar elements.

[0026] The principles of this disclosure will be explained below with reference to several embodiments. These embodiments are described for illustrative purposes only and should be understood as helping those skilled in the art to understand and implement this disclosure, without implying any limitation on the scope of this disclosure. The disclosures described herein can be implemented in various forms other than those described below.

[0027] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meanings as those generally understood by those skilled in the art to which this disclosure belongs.

[0028] As used herein, the term “terminal device” refers to any device having wireless or wired communication capabilities. Examples of terminal devices include user equipment (UE), personal computers, desktops, mobile phones, cellular phones, smartphones, personal digital assistants (PDAs), portable computers, tablets, wearable devices, Internet of Things (IoT) devices, Ultra-reliable and Low Latency Communication (URLLC) devices, Internet of Everything (IoE) devices, machine type communication (MTC) devices, in-vehicle devices for V2X communication (where X stands for pedestrian, vehicle, or infrastructure / network), Integrated Access and Backhaul (IAB), spacecraft-borne vehicles, or devices for aircraft-borne vehicles in Non-terrestrial networks (NTN) including High Altitude Platforms (HAP) encompassing satellites and Unmanned Aircraft Systems (UAS), eXtended Reality (XR) devices including different types of reality such as Augmented Reality (AR), Mixed Reality (MR), and Virtual Reality (VR), unmanned aerial vehicles (UAVs), commonly known as drones, and high-speed aircraft. Examples of image capture devices include, but are not limited to, devices on train (HST), or digital cameras, sensors, game devices, music storage and playback devices, or internet devices that enable wireless or wired internet access and browsing.The “Terminal Device” may further have “Multicast / Broadcast” capabilities to support public safety and mission-critical, V2X applications, transparent IPv4 / IPv6 multicast distribution, IPTV, smart TV, wireless services, software distribution over the radio, group communications, and IoT applications. It may also incorporate one or more Subscriber Identity Modules (SIMs), known as multi-SIMs. The term “Terminal Device” can be used interchangeably with UE, mobile station, subscriber station, mobile terminal, user terminal, or wireless device.

[0029] The term "network device" refers to a device that can provide or host a cell or coverage from which terminal devices can communicate. Examples of network devices include, but are not limited to, Node B (NodeB or NB), evolved Node B (eNodeB or eNB), next generation Node B (gNB), transmission reception point (TRP), remote radio unit (RRU), radio head (RH), remote radio head (RRH), IAB node, low-power nodes such as femtonodes, piconodes, and reconfigurable intelligent surface (RIS).

[0030] Terminal devices or network devices may possess artificial intelligence (AI) or machine learning capabilities. Generally, terminal devices or network devices may include models trained from a large amount of collected data for a specific function, and may be used to predict certain information.

[0031] Terminal or network devices can operate over several frequency ranges, such as FR1 (410 MHz to 7125 MHz), FR2 (24.25 GHz to 71 GHz), frequency bands greater than 100 GHz, and Tera Hertz (THz). They can also operate over licensed / unlicensed / shared spectrum. Terminal devices may have two or more connections to network devices under Multi-Radio Dual Connectivity (MR-DC) application scenarios. Terminal or network devices can operate in full-duplex mode, flexible duplex mode, and cross-division duplex mode.

[0032] Embodiments of the present disclosure may be implemented in test equipment, such as signal generators, signal analyzers, spectral analyzers, network analyzers, test terminal devices, test network devices, and channel emulators.

[0033] In one embodiment, a terminal device may be connected to a first network device and a second network device. One of the first and second network devices may be a master node, and the other may be a secondary node. The first and second network devices may use different radio access technologies (RATs). In one embodiment, the first network device may be a first RAT device, and the second network device may be a second RAT device. In one embodiment, the first RAT device is an eNB, and the second RAT device is a gNB. Information regarding different radio access technologies may be transmitted to the terminal device from at least one of the first or second network devices. In one embodiment, the first information may be transmitted from the first network device to the terminal device, and the second information may be transmitted from the second network device directly or via the first network device to the terminal device. In one embodiment, information relating to the configuration of a terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information related to the reconfiguration of a terminal device configured by a second network device may be transmitted from the second network device directly to the terminal device or via the first network device.

[0034] Where used herein, a singular expression includes plural expressions unless the context clearly indicates otherwise. The term “includes” and its variations should be read as an open term meaning “includes, but not limited to.” The term “based on” should be read as “based on, at least in part.” The terms “one embodiment” and “an embodiment” should be read as “at least one embodiment.” The term “another embodiment” should be read as “at least one other embodiment.” Terms such as “first,” “second,” etc., may refer to different or the same subject. Other explicit and implicit definitions may include:

[0035] In some examples, values, procedures, or devices are referred to as “best,” “worst,” “highest,” “minimum,” “maximum,” etc. Such descriptions are intended to show that a choice may be made from among many usable functional alternatives, and it will be understood that such a choice does not need to be superior, smaller, higher, or otherwise preferable to other choices.

[0036] In the context of this disclosure, the term “cell switching” may be used interchangeably with “reconfiguration with synchronization for a secondary cell group (SCG) or master cell group (MCG)” or “cell change.” The term “PSCell” refers to an SCG SpCell, the term “PCell” refers to an MCG SpCell, and the term “SpCell” refers to a primary cell of an SCG or MCG. The term “SCell” refers to a secondary cell. “Lower-layer signaling” may be used interchangeably with “L1 / L2 signaling.” The term “radio resource control (RRC) reconfiguration” may be used interchangeably with “RRC reconfiguration message.” The term “candidate cell” may be used interchangeably with “LTM candidate cell” or “candidate cell enabling LTM.” The term “target cell” may be used interchangeably with “target candidate cell,” “candidate target cell,” or “LTM target candidate cell.”

[0037] LTM is a procedure in which a network device (e.g., a gNB) receives L1 measurement reports (or multiple reports) from a terminal device (e.g., a UE) and, based on these reports, changes the serving cell of the terminal device via a cell switching command signaled through MAC CE. The cell switching command indicates an LTM candidate cell configuration previously prepared by the network device and provided to the terminal device via RRC signaling. The terminal device then switches to the target candidate cell in accordance with the cell switching command. The LTM procedure can be used to reduce mobility latency.

[0038] As mentioned above, it is expected that support for inter-CU LTM will be added to further extend the LTM scenario. In this case, security key updates during inter-CU LTM should be considered.

[0039] With this in mind, embodiments of the present disclosure provide a communication solution for security key updates in interCU LTM. In this solution, a CU of a network device sends security key update information for a cell switch from the serving cell to a candidate cell that will authorize the LTM to a DU of the network device. When a decision is made to perform a cell switch to a candidate cell, the DU sends a MAC CE indicating the cell switch to the candidate cell to a terminal device. The MAC CE contains security key update information. Based on the security key update information, the terminal device updates its security key. In this way, security key updates can be performed during interCU LTM, and hardening of interCU LTM can be achieved.

[0040] The principles and implementation forms of this disclosure will be described in detail below with reference to the drawings.

[0041] Examples of communication networks Figure 1A shows a schematic diagram of an exemplary communication network 100A in which several embodiments of the present disclosure may be implemented. As shown in Figure 1A, the communication network 100A may include a terminal device 110 and network devices 120 and 130. Network device 120 may provide one or more cells (illustrated cells 122-1 and 123-1) to serve one or more terminal devices. Network device 130 may also provide one or more cells (illustrated cells 131 and 132) to serve one or more terminal devices.

[0042] As shown in Figure 1A, the network device 120 may comprise a CU 121 and DUs 122 and 123. The CU 121 can communicate with DUs 122 and 123. The two DUs 122 and 123 are shown for illustrative purposes only, and it should be understood that more or fewer DUs may be provided in relation to implementations of embodiments of this disclosure.

[0043] As shown in Figure 1A, DU122 provides cell 122-1, and DU123 provides cell 123-1. This is just an example, and it should be understood that either DU122 or DU123 can provide more cells. Terminal device 110 can communicate with any of these cells. In this example, terminal device 110 is located in cell 123-1 and is served by network device 120.

[0044] Although not shown, network device 130 may comprise a CU and one or more DUs, as described in relation to network device 120. Alternatively, network device 130 does not have to be implemented in a CU-DU architecture, but may be implemented in an integrated architecture as shown.

[0045] CU121 can communicate with network device 130. In some embodiments, where network device 130 includes a CU and one or more DUs, CU121 can communicate with the CU of network device 130.

[0046] As shown in Figure 1A, the communication network 100A may further include a core network (CN) 135. A terminal device 110 can communicate with CN 135 via network devices 120 and / or 130. In this example, terminal device 110 can communicate with CU 121 via DU 123, and CU 121 can further communicate with CN 135.

[0047] It should be understood that the number of devices, cells, CUs, or DUs in Figure 1A is given for illustrative purposes only and does not imply any limitation to this disclosure. The communication network 100A may include any appropriate number of network devices and / or terminal devices and / or cells and / or CUs and / or DUs adapted to implement the implementation of this disclosure.

[0048] Communications in the communication network 100A may comply with any suitable standard, including but not limited to Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), New Radio (NR), Wideband Code Division Multiple Access (WCDMA®), Code Division Multiple Access (CDMA), GSM EDGE Radio Access Network (GERAN), and Machine Type Communication (MTC). Embodiments of this disclosure may be implemented in accordance with any generation of communication protocol that is currently known or will be developed in the future. Examples of communication protocols include, but are not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocols, 5.5G, 5G-Advanced networks, or sixth generation (6G) networks.

[0049] Communication from terminal device 110 to network device 120 is called uplink (UL) communication, and communication from network device 120 to terminal device 110 is called downlink (DL) communication. Terminal device 110 can move between cells of network devices 120 and 130, and possibly between cells of other network devices. In UL communication, terminal device 110 can transmit UL data and control information to network device 120 or 130 via the UL channel. In DL communication, network device 120 or 130 can transmit DL data and control information to terminal device 110 via the DL channel.

[0050] Communication in the communication network 100A may be performed according to the UP and CP protocol stacks. Generally speaking, in the case of a communication device (for example, a terminal device or a network device), the protocol stack may contain multiple entities of multiple network protocol layers, which may be configured to implement corresponding processing for data transmitted from the communication device, data received by the communication device, or signaling. Figure 1B shows schematic diagram 100B illustrating network protocol layer entities that may be established for the UP protocol stack in a device according to some embodiments of the present disclosure. For convenience, the following description will use network device 120 as an example of a network device.

[0051] As shown in Figure 1B, in UP, each of the terminal device 110 and the network device 120 may comprise L1 layer entities, i.e., physical (PHY) layer entities (also called PHY entities), and one or more entities of higher layers (L2 layer and layer 3 (L3) layer, i.e., higher layers), one or more entities which include MAC layer entities (also called MAC entities), radio link control (RLC) layer entities (also called RLC entities), packet data convergence protocol (PDCP) layer entities (also called PDCP entities), and service data application protocol (SDAP) layer entities (also called SDAP entities, which are established in 5G and higher generation networks).

[0052] Figure 1C shows a schematic diagram 100C illustrating network protocol layer entities that may be established in a device for a CP protocol stack according to some embodiments of the present disclosure. For convenience, the following description will use network device 120 as an example of a network device.

[0053] As shown in Figure 1C, in the CP, each of the terminal device 110 and the network device 120 may comprise L1 layer entities, i.e., PHY layer entities (also called PHY entities), and one or more entities of higher layers (L2 and L3 layers), one or more of which include MAC layer entities (also called MAC entities), RLC layer entities (also called RLC entities), PDCP layer entities (also called PDCP entities), and RRC layer entities (also called RRC entities). The RRC layer may also be called the access stratum (AS) layer, and therefore RRC entities may also be called AS entities. As shown in Figure 1C, the terminal device 110 may also comprise non-access stratum (NAS) layer entities (also called NAS entities). The network-side NAS layer is located within the CN, not within the network device.

[0054] In the context of this disclosure, L1 refers to the PHY layer, L2 refers to the MAC, RLC, PDCP, or SDAP layer, and L3 refers to the RRC layer. In the context of this disclosure, L1 or L2 may be collectively referred to as lower layers, and L3 may be referred to as upper layers. Therefore, L1 or L2 signaling may be referred to as lower layer signaling, and L3 signaling may be referred to as upper layer signaling.

[0055] Returning to Figure 1A, a CU (e.g., CU121) can be responsible for performing the functions of the RRC entity, SDAP entity, and PDCP entity, and a DU (e.g., DU122 or DU123) can be responsible for performing the functions of the RLC entity, MAC entity, and PHY entity. In some embodiments, the CU and DU may be implemented on separate devices. In some embodiments, the CU and DU may be implemented on the same device. In some embodiments, different DUs may be implemented on separate devices. In some embodiments, different CUs are implemented on separate devices.

[0056] In the context of this disclosure, a CU (also referred to herein as a gNB-CU) is a logical node that hosts the RRC, SDAP, and PDCP protocols of a gNB, or the RRC and PDCP protocols of an en-gNB, controlling the operation of one or more DUs (also referred to herein as gNB-DUs). The gNB-CU terminates the F1 interface connected to the gNB-DU. A DU is a logical node that hosts the RLC, MAC, and PHY layers of a gNB or en-gNB, and its operation is partially controlled by the gNB-CU. A single gNB-DU supports one or more cells. A single cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU.

[0057] Generally, communication channels are classified into logical channels, transmit channels, and physical channels. A physical channel is the channel through which the PHY layer actually transmits information. For example, physical channels may include the physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), physical random access channel (PRACH), PDCCH, physical downlink shared channel (PDSCH), and physical broadcast channel (PBCH).

[0058] The transmit channel is the channel between the PHY layer and the MAC layer. For example, the transmit channel may include a broadcast channel (BCH), a downlink shared channel (DL-SCH), a paging channel (PCH), an uplink shared channel (UL-SCH), and a random access channel (RACH).

[0059] A logical channel is a channel between the MAC layer and the RLC layer. For example, logical channels may include a dedicated control channel (DCCH), a common control channel (CCCH), a paging control channel (PCCH), a broadcast control channel (BCCH), and a dedicated traffic channel (DTCH).

[0060] Generally, the channel between the RRC layer and the PDCP layer is called a radio bearer (RB). Terminal device 110 may consist of at least one data radio bearer (DRB) for carrying data plane data and at least one signaling radio bearer (SRB) for carrying control plane data. Four types of SRBs, namely SRB0, SRB1, SRB2, and SRB3, may be defined in the RRC layer. SRB0 uses CCCH for RRC connection establishment or re-establishment. SRB1 uses DCCH and is established when the RRC connection is established. SRB2 uses DCCH and is established during RRC reconfiguration and after initial security activation. SRB3 uses DCCH and is established between terminal device 110 and SN when a dual connection is established.

[0061] Continuing to refer to Figure 1A, in some embodiments, the terminal device 110 may be located within the coverage of cell 123-1, and the terminal device 110 may communicate with DU 123 of network device 120 based on the network configuration. In this case, cell 123-1 may be referred to as the serving cell for the terminal device 110. Cells 122-1, 131, and 132 may be referred to as candidate cells for the terminal device 110.

[0062] In some embodiments, terminal device 110 can establish dual connections (i.e., simultaneous connections) with network devices 120 and 130. In some embodiments, network device 120 can function as a master node (MN). In these embodiments, terminal device 110 can communicate with network device 120 via a set of serving cells. The set of serving cells forms an MCG, and the primary cell within the MCG is called a PCell. In some scenarios, the PCell can be changed from cell 123-1 to cell 131. This is called a handover (HO). In some embodiments, network device 120 can function as a secondary node (SN). In these embodiments, the set of serving cells provided by network device 120 forms an SCG, and the primary cell within the SCG is called a PSCell. In some scenarios, the PSCell can be changed from cell 123-1 to cell 131. This is called a PSCell change.

[0063] In some scenarios, network device 120 can receive L1 measurement reports from terminal device 110. Based on the L1 measurement reports, network device 120 can change the serving cell of terminal device 110 via MAC CE. This procedure is called LTM. Network device 120 can prepare one or more candidate cells and provide the candidate cell configurations to terminal device 110 via RRC messages. The LTM cell switch is then triggered by network device 120 selecting one of the candidate cell configurations as the target configuration for the LTM.

[0064] Figure 1D is a schematic diagram showing process 100D of the LTM, which can implement several embodiments of the present disclosure. For convenience of explanation, process 100D will be described with reference to Figure 1A. Process 100D may include a terminal device 110 and a network device 120, as shown in Figure 1A. Network device 120 may be an MN or SN that provides services to terminal device 110. In this example, network device 120 provides a serving cell to terminal device 110, and another network device (such as network device 130) provides a target candidate cell to terminal device 110.

[0065] As shown in Figure 1D, during the LTM preparation phase, the terminal device 110 can send a measurement report message to the network device 120 (140). The network device 120 can decide to use LTM and begin LTM candidate preparation (141). The network device 120 can send an RRC reconfiguration message to the terminal device 110 containing the configuration of one or more LTM candidate target cells (also referred herein as LTM configuration or LTM candidate configuration) (142). The terminal device 110 can store the configuration of the LTM candidate target cell(s) and send an RRC reconfiguration complete message to the network device 120 (143).

[0066] In the early sync phase, terminal device 110 can perform downlink (DL) synchronization with candidate cell(s) before receiving a cell switch command (144). Terminal device 110 can perform early TA acquisition with candidate cell(s) requested by network device 120 (i.e., perform uplink (UL) synchronization with candidate cell(s)) before receiving a cell switch command (145). This may be done via contention-free random access (CFRA) triggered by a PDCCH sequence from the source cell, after which terminal device 110 sends a preamble to the indicated candidate cell. To minimize data interruption of the source cell by CFRA to the candidate cell, terminal device 110 does not receive a random access response (RAR) for the purpose of acquiring the TA value, and the TA value of the candidate cell(s) is indicated by the cell switch command. Terminal device 110 does not maintain a TA timer for the candidate cell and relies on the network implementation to ensure the validity of the TA.

[0067] During the LTM execution phase, terminal device 110 can perform L1 measurements on the configured LTM candidate target cell(s) and send a lower layer measurement report to network device 120 (146). L1 measurements can be performed insofar as RRC reconfiguration is applied in step 142. Network device 120 may decide to perform an LTM cell switch to the target cell (147) and send a MAC CE that triggers the LTM cell switch by including the candidate configuration index of the target cell (148). Terminal device 110 can switch to the target cell (149) and apply the configuration indicated by the candidate configuration index. If terminal device 110 does not have a valid TA for the target cell, terminal device 110 performs an RA procedure toward the target cell (150).

[0068] At the LTM completion stage, terminal device 110 can complete the LTM cell switching procedure by sending an RRC reconfiguration completion message to the target cell (151). If terminal device 110 performs the RA procedure in step 150, terminal device 110 can consider the LTM execution to have completed successfully when the RA procedure completes successfully. In the case of RACH-less LTM, terminal device 110 can consider the LTM execution to have completed successfully when terminal device 110 determines that network device 120 has successfully received the first UL data from terminal device 110.

[0069] Steps 144-151 can be executed multiple times for subsequent LTM cell switching using the LTM candidate cell configuration(s) provided in step 142.

[0070] Returning to Figure 1A, in some scenarios, terminal device 110 can receive a MAC CE indicating a cell switch from cell 123-1 to cell 122-1, under the control of the same CU 121. This cell switch procedure is referred to herein as Intra-CU LTM. In some scenarios, network device 120 can function as MN in a dual connection. In this case, this cell switch procedure is also referred to herein as Intra-MN LTM. In some scenarios, network device 120 can function as SN in a dual connection. In this case, this cell switch procedure is also referred to herein as Intra-SN LTM.

[0071] Continuing to refer to Figure 1A, in some scenarios, terminal device 110 can receive a MAC CE indicating a cell switch from cell 123-1, which is under the control of CU 121, to cell 131. Cell 131 is either not under the control of CU 121 or is under the control of another CU. This cell switch procedure is referred to herein as inter-CU LTM. In some scenarios, network device 120 can function as MN in a dual connection. In this case, this cell switch procedure is also referred to herein as inter-MN LTM. In some scenarios, network device 120 can function as SN in a dual connection. In this case, this cell switch procedure is also referred to herein as inter-SN LTM.

[0072] In the conventional HO procedure, the configuration for security key updates is indicated to the terminal device via an HO command. For intra-MN LTMs, the security key is not updated because the PDCP anchor remains unchanged. For inter-CU LTMs, the security key needs to be updated due to security requirements. However, due to the need to support subsequent LTMs, it is impossible to configure security key update information in the RRC message. How to perform security key updates for inter-CU LTMs remains unclear.

[0073] Embodiments of this disclosure provide a communication solution for security key updates during inter-CU LTM. In this solution, security key update information is included in the LTM cell switching command. In this way, terminal devices can update their security keys during inter-CU LTM. This will be explained in more detail with reference to Figures 2 to 5 below.

[0074] Implementation methods for security key updates Figure 2 shows a schematic diagram illustrating a communication process 200 according to an embodiment of the present disclosure. For convenience of explanation, process 200 will be described with reference to Figure 1A. Process 200 may include a terminal device 110, DU123 and CU121 of network device 120, and network device 130, as shown in Figure 1A. In this example, DU123 of network device 120 provides terminal device 110 with a serving cell (e.g., cell 123-1), and network device 130 provides terminal device 110 with a target candidate cell (hereinafter also referred to as a candidate cell) (e.g., cell 131). The serving cell may be a SpCell, PCell, or PSCell of terminal device 110.

[0075] As shown in Figure 2, CU121 can send security key update information (also referred to herein as security key update information for convenience) for cell switching (also referred herein as LTM cell switching for convenience) from the serving cell to a candidate cell that will permit LTM (210).

[0076] In some embodiments, security key update information may include an indicator (such as a key set change indicator) that shows whether the key set has been changed.

[0077] In some embodiments, security key update information may include the value of the next hop chaining count (NCC). In some embodiments, the NCC value may be a value associated with the NCC value configured in the RRC signaling.

[0078] In some embodiments, security key update information may include the value of a security key counter (e.g., an sk counter or an SN counter). It should be understood that any combination of the above information is also possible.

[0079] Continuing to refer to Figure 2, once it is determined that an LTM cell switchover from cell 123-1 to cell 131 should be performed for terminal device 110, DU123 can send a MAC CE indicating the LTM cell switchover to cell 131 to terminal device 110 (220). Security key update information received from CU121 is included in the MAC CE. The MAC CE may also include the target configuration identity (ID), timing advance command, transmission configuration indication (TCI) status ID, UL TCI status ID, and CFRA configuration.

[0080] Referring to Figure 2, when terminal device 110 receives MAC CE, it determines whether MAC CE contains security key update information (230). If MAC CE contains security key update information, terminal device 110 can derive or update the security key based on the security key update information in MAC CE during LTM cell switching (240).

[0081] In some embodiments, the terminal device 110 indicates security key update information from its MAC layer to a higher layer of the terminal device 110, and the higher layer can derive or update the security key based on the security key update information. That is, when the MAC layer of the terminal device 110 receives the LTM cell switching command MAC CE, it indicates security key update information to a higher layer of the terminal device 110 (e.g., the RRC layer). The RRC layer of the terminal device 110 derives or updates the security key based on the security key update information received from a lower layer (e.g., the MAC layer).

[0082] In some embodiments, if an indicator is received that the key set has been changed (e.g., such as a key set change indicator), the terminal device 110 will perform an access and mobility management function (AMF) (e.g., K AMFMaster keys can be derived or updated based on keys such as (etc.).

[0083] In some embodiments, the terminal device 110 uses at least the value of the NCC to determine the master key (i.e., K gNB The NCC value can be used to derive or update the master key based on the current master key or key NH (derived by the mobile equipment (ME) and AMF to provide forward security).

[0084] In some embodiments, the terminal device 110 determines the secondary key (i.e., SK) based on the master key and the value of the received security key counter. gNB ) can be derived or updated.

[0085] Continuing to refer to Figure 2, in some embodiments, if the MAC CE contains security key update information, the terminal device 110 can perform a set of L2 procedures (250). In some embodiments, the set of L2 procedures may include at least one of the following: configuring at least one PDCP entity of a DRB or SRB to apply an encryption algorithm and encryption key; configuring at least one PDCP entity of a DRB or SRB to apply an integrity protection algorithm and integrity protection key; re-establishing at least one PDCP entity of a DRB; re-establishing at least one PDCP entity of an SRB; or re-establishing an RLC entity of at least one radio bearer (e.g., an SRB or DRB).

[0086] In some embodiments where at least one PDCP entity of a DRB or SRB is configured to apply an encryption algorithm and a key for encryption, with respect to a DRB, if the PDCP entity of the DRB is not configured to disable encryption, the terminal device 110 may configure the PDCP entity with an encryption algorithm and key for encrypting user data associated with a master key or secondary key, as shown in keytoUse, i.e., the encryption configuration shall apply to all subsequent PDCP PDUs sent and received by the UE. In some embodiments, with respect to an SRB, the terminal device 110 may configure the PDCP entity to apply an encryption algorithm and key for encrypting RRC signaling associated with a master key or secondary key, i.e., the encryption configuration shall apply to all subsequent messages sent and received by the terminal device 110, including a message used to indicate that the procedure has been successfully completed.

[0087] In some embodiments, with respect to a DRB, if the PDCP entity of at least one DRB or SRB is configured to apply an integrity protection algorithm and a key for integrity protection, with respect to a DRB, if the PDCP entity of that DRB is configured for integrity protection, the terminal device 110 can configure the PDCP entity with an integrity protection algorithm according to a security configuration (e.g., securityConfig) and apply the key for integrity protection of user data associated with a master key or secondary key, as shown in keytoUse. In some embodiments, with respect to an SRB, the terminal device 110 can configure the PDCP entity to apply an integrity protection algorithm and a key for integrity protection of RRC signaling associated with a master key or secondary key, i.e., the integrity protection configuration is applied to all subsequent messages sent and received by the terminal device 110, including a message used to indicate that the procedure has been successfully completed.

[0088] Continuing to refer to Figure 2, in some embodiments, if security key update information is not included in the LTM cell switching command MAC CE, the terminal device 110 can perform one or more corresponding actions (260).

[0089] In some embodiments, if security key update information is not included in the LTM cell switching command MAC CE, the terminal device 110 may not derive or update the security key, for example, the master key or the secondary key.

[0090] In some embodiments, if security key update information is not included in the LTM cell switching command MAC CE, the terminal device 110 may trigger a PDCP entity of at least one SRB to perform service data unit (SDU) decommissioning.

[0091] In some embodiments, if security key update information is not included in the LTM cell switching command MAC CE, the terminal device 110 may determine whether to perform an L2 reset procedure based on the identity (ID) value of the serving cell and the ID value of the candidate cell. In some embodiments, if the ID values ​​of the serving cell and the candidate cell are the same, the terminal device 110 may determine that the L2 reset procedure is not performed. In some embodiments, if the ID values ​​of the serving cell and the candidate cell are different, the terminal device 110 may determine that the L2 reset procedure is performed. In some embodiments, the L2 reset procedure may include at least one of triggering a PDCP entity of at least one DRB to perform data recovery, or re-establishing an RLC entity of at least one wireless bearer.

[0092] Up to this point, we have explained in detail the security key update behavior on the terminal device side. Below, we will mainly explain the security key update behavior on the network side (for example, DU123 and CU121) in relation to Figures 3 to 5.

[0093] Figure 3 shows a schematic diagram illustrating another communication process 300 according to an embodiment of the present disclosure. For convenience of explanation, process 300 will be described with reference to Figure 1A. Process 300 may include a terminal device 110, DU123 and CU121 of network device 120, and network device 130, as shown in Figure 1A. In this example, DU123 of network device 120 provides terminal device 110 with a serving cell (e.g., cell 123-1), and network device 130 provides terminal device 110 with a target candidate cell (hereinafter also referred to as a candidate cell) (e.g., cell 131). The serving cell may be a SpCell, PCell, or PSCell of terminal device 110.

[0094] As illustrated in Figure 3, DU123 can decide to perform an LTM cell switch to a candidate cell (e.g., cell 131) (310). In this case, DU123 can send information about the candidate cell to CU121 (320). In some embodiments, DU123 can send information about the candidate cell by an F1 message. For example, the F1 message may be a UE context change request message. It should be understood that any other suitable method is also achievable.

[0095] In some embodiments, candidate cell information may include the candidate cell's ID, e.g., cell global ID (CGI), or any other appropriate form. In some embodiments, candidate cell information may include the ID of the LTM configuration associated with the candidate cell. It should be understood that any other appropriate information is also possible.

[0096] Based on the candidate cell information, CU121 can send security key update information for LTM cell switching to DU123 (330). In some embodiments, CU121 can send security key update information by an F1 message. For example, the F1 message may be a UE context change confirmation message. It should be understood that any other suitable method is also achievable.

[0097] In some embodiments, security key update information may include at least one of the following: an indicator showing whether the key set has been changed (e.g., a key set change indicator), the value of the NCC, or the value of a security key counter (e.g., an sk counter or an SN counter). Other details of the security key update information are the same as those described in step 210 of Figure 2, and will not be repeated here for brevity.

[0098] Continuing to refer to Figure 3, DU123 generates and sends a MAC CE indicating the switch of the LTM cell to a candidate cell to the terminal device 110 (340). The security key update information received from CU121 is included in the MAC CE. The MAC CE may also include the target configuration ID, timing advance command, TCI status ID, UL TCI status ID, and CFRA configuration.

[0099] Referring to Figure 3, CU121 can transmit candidate cell information and the security key associated with the candidate cell to network device 130 providing the candidate cell (i.e., cell 131) (350). In other words, the source CU can transmit LTM target cell information and the security key used for LTM cell switching to the target CU. In some embodiments, CU121 can transmit candidate cell information and the security key by an Xn message. For example, the Xn message may be a handover request message or a handover success message. For example, the Xn message may be an SN change request message. It should be understood that any other suitable method is also achievable.

[0100] In some embodiments, candidate cell information may include the candidate cell ID, e.g., cell global ID (CGI) or any other appropriate form. In some embodiments, candidate cell information may include the ID of the LTM configuration associated with the candidate cell. It should be understood that any other appropriate information is also possible. In some embodiments, the security key is the intermediate key K NG-RAN *It can also be called

[0101] Continuing to refer to Figure 3, when terminal device 110 receives MAC CE, it can derive or update the security key during LTM cell switching (360). The operation in step 360 is the same as the operation in steps 230-260 in Figure 2, so for brevity, it will not be repeated here.

[0102] In some embodiments, the LTM cell switching may be inter-MN cell switching or inter-gNB PCell switching. In this case, DU123 and CU121 (i.e., gNB-DU and gNB-CU) are source gNB devices, and network device 130 (i.e., target gNB(CU)) is the target gNB device.

[0103] In some embodiments, the LTM cell switching may be an interSN PSCell switching. In this case, DU123 and CU121 (i.e., gNB-DU and gNB-CU) are MN devices, and network device 130 (i.e., target gNB(CU)) is the target SN.

[0104] Please understand that there are no restrictions on the order of steps 330-350 in process 300, and any suitable order is possible.

[0105] Figure 4 shows a schematic diagram illustrating another communication process 400 according to an embodiment of the present disclosure. For convenience of explanation, process 400 will be described with reference to Figure 1A. Process 400 may include a terminal device 110, DU123 and CU121 of network device 120, and network device 130, as shown in Figure 1A. In this example, DU123 of network device 120 provides terminal device 110 with a serving cell (e.g., cell 123-1), and network device 130 provides terminal device 110 with a target candidate cell (hereinafter also referred to as a candidate cell) (e.g., cell 131). The serving cell may be a SpCell, PCell, or PSCell of terminal device 110.

[0106] As shown in Figure 4, terminal device 110 can access network device 120 via, for example, cell 123-1 of DU123 (410). In this case, DU123 can send an access instruction from terminal device 110 to CU121 (420). In other words, gNB-DU notifies gNB-CU of access to or switching of a serving cell (e.g., PCell or PSCell).

[0107] Based on an access instruction from terminal device 110, CU121 can send security key update information for LTM cell switching to DU123 (430). In some embodiments, CU121 can send security key update information by an F1 message. For example, the F1 message may be a UE context change request message. It should be understood that any other suitable method is also achievable.

[0108] In some embodiments, security key update information may include at least one of the following: an indicator showing whether the key set has been changed (e.g., a key set change indicator), the value of the NCC, or the value of a security key counter (e.g., an sk counter or an SN counter). Other details of the security key update information are the same as those described in step 210 of Figure 2, and will not be repeated here for brevity.

[0109] Continuing to refer to Figure 4, CU121 can send a set of security keys associated with a set of candidate cells that permit LTM to a set of network devices providing the set of candidate cells (e.g., one or more candidate CUs) (440). In other words, the source gNB-CU sends the security key to be used for each of the list of LTM candidate cells to the set of LTM candidate gNB-CUs. In some embodiments, CU121 can send the security keys by an Xn message. For example, the Xn message may be a handover request message. In another example, the Xn message may be an SN change request message. It should be understood that any other suitable method is also achievable. In some embodiments, the security key is an intermediate key K NG-RAN *It can also be called

[0110] Continuing to refer to Figure 4, terminal device 110 can send an L1 measurement report to DU123 (450). DU123 can decide to perform an LTM cell switch to a candidate cell (e.g., cell 131) (460). In this case, DU123 can generate and send a MAC CE indicating the switch of the LTM cell to the candidate cell to terminal device 110 (470). Security key update information received from CU121 is included in the MAC CE. The MAC CE may also include the target configuration ID, timing advance command, TCI status ID, UL TCI status ID, and CFRA configuration.

[0111] Continuing to refer to Figure 4, when terminal device 110 receives MAC CE, it can derive or update the security key during LTM cell switching (480). The operation in step 480 is the same as the operation in steps 230-260 in Figure 2, so for brevity it will not be repeated here. Using the updated security key, terminal device 110 can communicate with the candidate cell (i.e., the target candidate cell).

[0112] In some embodiments, the LTM cell switching may be inter-MN cell switching or inter-gNB PCell switching. In this case, DU123 and CU121 (i.e., gNB-DU and gNB-CU) are source gNB devices, and LTM candidate gNB(CU) ​​is an LTM candidate gNB device.

[0113] In some embodiments, the LTM cell switching may be interSN PSCell switching. In this case, DU123 and CU121 (i.e., gNB-DU and gNB-CU) are MN devices, and the LTM candidate gNB(CU) ​​is the LTM candidate SN.

[0114] Please understand that there are no restrictions on the order of steps 430-440 in process 400, and any suitable order is possible.

[0115] Figure 5 shows a schematic diagram illustrating another communication process 500 according to an embodiment of the present disclosure. For convenience of explanation, process 500 will be described with reference to Figure 1A. Process 500 may include a terminal device 110, DU123 and CU121 of network device 120, and network device 130, as shown in Figure 1A. In this example, DU123 of network device 120 provides terminal device 110 with a serving cell (e.g., cell 123-1), and network device 130 provides terminal device 110 with a target candidate cell (hereinafter also referred to as a candidate cell) (e.g., cell 131). The serving cell may be a SpCell, PCell, or PSCell of terminal device 110.

[0116] As shown in Figure 5, terminal device 110 can access network device 120 via, for example, cell 123-1 of DU123 (510). In this case, DU123 can send an access instruction from terminal device 110 to CU121 (520). In other words, gNB-DU notifies gNB-CU of access to or switching of a serving cell (e.g., PCell or PSCell).

[0117] Based on an access instruction from terminal device 110, CU121 can send security key update information for LTM cell switching to DU123 (530). In some embodiments, CU121 can send security key update information by an F1 message. For example, the F1 message may be a UE context change request message. It should be understood that any other suitable method is also achievable.

[0118] In some embodiments, security key update information may include at least one of the following: an indicator showing whether the key set has been changed (e.g., a key set change indicator), the value of the NCC, or the value of a security key counter (e.g., an sk counter or an SN counter). Other details of the security key update information are the same as those described in step 210 of Figure 2, and will not be repeated here for brevity.

[0119] Continuing to refer to Figure 5, terminal device 110 can send an L1 measurement report to DU123 (540). DU123 can decide to perform an LTM cell switch to a candidate cell (e.g., cell 131) (550). In this case, DU123 can generate and send a MAC CE indicating the switch of the LTM cell to the candidate cell to terminal device 110 (560). Security key update information received from CU121 is included in the MAC CE. The MAC CE may also include the target configuration ID, timing advance command, TCI status ID, UL TCI status ID, and CFRA configuration.

[0120] DU123 can transmit candidate cell information to CU121 (570). In some embodiments, DU123 can transmit candidate cell information via an F1 message. For example, the F1 message may be a UE context change request message. It should be understood that any other suitable method is also achievable.

[0121] In some embodiments, candidate cell information may include the candidate cell ID, e.g., CGI or any other suitable form. In some embodiments, candidate cell information may include the ID of the LTM configuration associated with the candidate cell. It should be understood that any other suitable information is also possible.

[0122] Based on the candidate cell information, CU121 can transmit the candidate cell information and the security key associated with the candidate cell to the network device 130 providing the candidate cell (i.e., cell 131) (580). In other words, the source CU can transmit the LTM target cell information and the security key used for LTM cell switching to the target CU. In some embodiments, CU121 can transmit the candidate cell information and security key by an Xn message. For example, the Xn message may be a handover request message or a handover success message. As another example, the Xn message may be an SN change request message. It should be understood that any other suitable method is also achievable. Using the security key, the candidate cell (i.e., the target candidate cell) can communicate with the terminal device 110.

[0123] In some embodiments, candidate cell information may include the candidate cell ID, e.g., CGI or any other suitable form. In some embodiments, candidate cell information may include the ID of the LTM configuration associated with the candidate cell. It should be understood that any other suitable information is also possible. In some embodiments, the security key is the intermediate key K NG-RAN *It can also be called

[0124] Continuing to refer to Figure 3, when terminal device 110 receives MAC CE, it can derive or update the security key during LTM cell switching (590). The operation of step 590 is the same as the operation of steps 230-260 in Figure 2, so for brevity it will not be repeated here. Using the updated security key, terminal device 110 can communicate with the candidate cell (i.e., the target candidate cell).

[0125] In some embodiments, the LTM cell switching may be inter-MN cell switching or inter-gNB PCell switching. In this case, DU123 and CU121 (i.e., gNB-DU and gNB-CU) are source gNB devices, and network device 130 (i.e., target gNB(CU)) is the target gNB device.

[0126] In some embodiments, the LTM cell switching may be an interSN PSCell switching. In this case, DU123 and CU121 (i.e., gNB-DU and gNB-CU) are MN devices, and network device 130 (i.e., target gNB(CU)) is the target SN.

[0127] Please understand that there are no restrictions on the order of steps 550-580 in process 500, and any suitable order is possible.

[0128] Security key updates during inter-CU LTM can be performed using any of processes 200 to 500, thereby achieving enhanced inter-CU LTM. The operations of processes 200 to 500, as described in relation to Figures 2 to 5, can be performed separately or in any appropriate combination.

[0129] Example implementation of the method Therefore, embodiments of this disclosure provide communication methods implemented in terminal devices, specifically in the DU and CU of network devices. These methods will be described below with reference to Figures 6 to 8.

[0130] Figure 6 shows exemplary methods 600 of communication implemented in a terminal device according to several embodiments of the present disclosure. For example, method 600 may be performed in a terminal device 110 as shown in Figure 1A. For convenience of explanation, method 600 will be described below with reference to Figure 1A. Method 600 may include additional blocks not shown, and / or some of the illustrated blocks may be omitted, and it should be understood that the scope of the present disclosure is not limited in this respect.

[0131] In block 610, terminal device 110 receives a MAC CE from network device 120 (e.g., DU123) indicating a cell switch from a serving cell to a candidate cell.

[0132] In block 620, terminal device 110 determines that MAC CE contains security key update information. In some embodiments, the security key update information may include at least one of the following: an indicator indicating whether the key set has been changed, an NCC value, or a security key counter value.

[0133] In block 630, the terminal device 110 updates the security key based on security key update information. In some embodiments, the terminal device 110 can transmit information from the MAC layer to the upper layer of the terminal device 110, and the upper layer can update the security key based on the security key update information.

[0134] In some embodiments, the terminal device 110 can update the master key based on the key for AMF, if it is an indicator that the key set has been changed. In some embodiments, the terminal device 110 can update the master key based on at least the NCC value. In some embodiments, the terminal device 110 can update the secondary key based on the master key and the security key counter values.

[0135] In some embodiments, if the MAC CE includes security key update information, the terminal device 110 may perform a procedure including at least one of the following: configuring the PDCP entity of at least one DRB or SRB to apply an encryption algorithm and encryption key; configuring the PDCP entity of at least one DRB or SRB to apply an integrity protection algorithm and integrity protection key; re-establishing the PDCP entity of at least one DRB; re-establishing the PDCP entity of at least one SRB; or re-establishing the RLC entity of at least one radio bearer.

[0136] In some embodiments, if the MAC CE does not contain security key update information, the terminal device 110 may perform at least one of the following actions: not perform a security key update; trigger a PDCP entity of at least one SRB to perform SDU disposal; or determine whether an L2 reset procedure is performed based on the ID value of the serving cell and the ID value of the candidate cell.

[0137] In some embodiments, the L2 reset procedure may include at least one of the following: triggering a PDCP entity of at least one DRB to perform data recovery, or re-establishing an RLC entity of at least one radio bearer.

[0138] Method 600 can be used to achieve security key updates on the terminal device side.

[0139] Figure 7 shows exemplary methods 700 of communication implemented in a DU of a network device according to several embodiments of the present disclosure. For example, method 700 may be performed in DU 122 or 123, as shown in Figure 1A. For convenience of explanation, method 600 will be described below with reference to DU 123 in Figure 1A. Method 600 may include additional blocks not shown, and / or some of the illustrated blocks may be omitted, and it should be understood that the scope of the present disclosure is not limited in this respect.

[0140] In block 710, DU123 of network device 120 receives security key update information for cell switching from a serving cell to a candidate cell that will permit LTM from network device 120 CU121. In some embodiments, the security key update information may include at least one of an indicator that the key set has been changed, an NCC value, or a security key counter value.

[0141] In some embodiments, when cell switching to a candidate cell is performed, DU123 can send information about the candidate cell to CU121. DU123 can then receive security key update information from CU121.

[0142] In some embodiments, the candidate cell information may include at least one of the following: candidate cell identification information or identification information of the LTM configuration associated with the candidate cell.

[0143] In some embodiments, when a terminal device 110 accesses a serving cell, the DU 123 can send an access instruction to the CU 121. The DU 123 can then receive security key update information from the CU 121.

[0144] In block 720, DU123 determines that a cell switch to the candidate cell will be performed.

[0145] In block 730, DU123 sends a MAC CE to terminal device 110 indicating cell switching to a candidate cell, and the MAC CE includes security key update information.

[0146] Method 700 can achieve security key updates on the DU side.

[0147] Figure 8 illustrates exemplary methods 800 of communication implemented in a CU of a network device, according to several embodiments of the present disclosure. For example, method 800 may be performed in CU 121, as illustrated in Figure 1A. For convenience of explanation, method 800 will be described below with reference to Figure 1A. Method 800 may include additional blocks not shown, and / or some of the illustrated blocks may be omitted, and the scope of the present disclosure is not limited in this respect.

[0148] In block 810, the CU121 of network device 120 transmits security key update information for cell switching from the serving cell to a candidate cell that will allow LTM to the network device 120 (e.g., DU123). In some embodiments, the security key update information may include at least one of an indicator that the key set has been changed, an NCC value, or a security key counter value.

[0149] In some embodiments, CU121 can receive candidate cell information (e.g., cell 131) from DU123. CU121 can then send security key update information to DU123. In some embodiments, candidate cell information may include at least one of candidate cell identification information or LTM configuration identification information associated with the candidate cell. In some embodiments, CU121 can send candidate cell information and the security key associated with the candidate cell to a further network device (e.g., network device 130) providing the candidate cell.

[0150] In some embodiments, CU121 can receive an instruction from DU123 that terminal device 110 is accessing a serving cell (e.g., cell 123-1). CU121 can then send security key update information to DU123. In some embodiments, CU121 can send a set of security keys associated with a set of candidate cells that permit LTM to a set of network devices providing the set of candidate cells.

[0151] Method 800 can achieve security key updates on the CU side.

[0152] The operation of methods 600-800 corresponds to that described in relation to Figures 2-5, and therefore, please understand that other details will not be repeated here for the sake of brevity.

[0153] Exemplary implementations of devices Figure 9 is a simplified block diagram of a device 900 suitable for implementing an embodiment of the present disclosure. Device 900 can be considered as a further exemplary implementation of a DU or CU of a terminal device 110 or a network device 120 or 130, as shown in Figure 1. Thus, device 900 may be implemented in, or as at least a part thereof, a DU or CU of a terminal device 110 or a network device 120 or 130.

[0154] As shown in the figure, device 900 includes a processor 910, a memory 920 coupled to the processor 910, a preferred transceiver 940 coupled to the processor 910, and a communication interface coupled to the transceiver 940. At least a portion of program 930 is stored in the memory 910. The transceiver 940 may be for bidirectional or unidirectional communication depending on the requirements. The transceiver 940 may include at least one of a transmitter 942 or a receiver 944. The transmitter 942 and receiver 944 may be functional modules or physical entities. The transceiver 940 has at least one antenna to facilitate communication, but in practice, the access node referred to in this application may have multiple antennas. The communication interface may represent any interface necessary for communication with other network elements, such as the X2 / Xn interface for bidirectional communication between eNBs / gNBs, the S1 / NG interface for communication between Mobility Management Entity (MME) / Access and Mobility Management Function (AMF) / SGW / UPF and eNBs / gNBs, the Un interface for communication between eNBs / gNBs and relay nodes (RNs), or the Uu interface for communication between eNBs / gNBs and terminal devices.

[0155] It is assumed that program 930, when executed by the associated processor 910, includes program instructions that enable device 900 to operate according to embodiments of the present disclosure as described herein with reference to Figures 1 to 8. Embodiments of the present disclosure may be implemented by computer software executable by the processor 910 of device 900, by hardware, or by a combination of software and hardware. The processor 910 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 910 and memory 920 may form processing means 950 adapted to implement various embodiments of the present disclosure.

[0156] The memory 920 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as non-temporary computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. Although only one memory 920 is shown for device 900, device 900 may have multiple physically separate memory modules. The processor 910 may be of any type suitable for a local technology network and may include, as non-limiting examples, one or more of a general-purpose computer, a dedicated computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 900 may have multiple processors, such as application-specific integrated circuit chips that are time-dependent to a clock that synchronizes the main processor.

[0157] In some embodiments, the terminal device includes circuitry configured to receive a MAC CE from a network device's DU indicating a cell switch from a serving cell to a candidate cell, and to update the security key based on the security key update information, in accordance with the determination that the MAC CE contains security key update information.

[0158] In some embodiments, the DU of a network device includes circuitry configured to receive security key update information from the CU of the network device for cell switching from a serving cell to a candidate cell that will authorize LTM, and to send a MAC CE containing the security key update information indicating cell switching to a candidate cell to a terminal device, in accordance with the decision that cell switching to a candidate cell will be performed.

[0159] In some embodiments, the CU of a network device includes circuitry configured to send security key update information for cell switching from a serving cell to a candidate cell that will authorize LTM to the DU of a network device.

[0160] As used herein, the term “circuit” may refer to a hardware circuit and / or a combination of a hardware circuit and software. For example, a circuit may be a combination of an analog and / or digital hardware circuit and software / firmware. As a further example, a circuit may be any part of a hardware processor having software including digital signal processors, software, and memory, which work together to cause a device such as a terminal device or network device to perform various functions. As yet another example, a circuit may be a hardware circuit and / or processor, such as a microprocessor or a part of a microprocessor, which requires software / firmware for operation, although the software may not be present if it is not necessary for operation. As used herein, the term “circuit” also encompasses the implementation of a hardware circuit or processor, or a part of a hardware circuit or processor, and its (or their) accompanying software and / or firmware.

[0161] In general, various embodiments of the present disclosure may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some embodiments may be implemented in hardware, while others may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various embodiments of the present disclosure are shown and described as block diagrams, flowcharts, or using any other graphical representation, it will be understood that the blocks, apparatus, systems, techniques, or methods described herein may be implemented, in non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or any combination thereof.

[0162] This disclosure also provides at least one computer program product tangibly stored in a non-temporary computer-readable storage medium. The computer program product includes computer-executable instructions, such as those contained in a program module, which are executed on a target real or virtual processor within a device to perform the processes or methods described above with reference to Figures 1 to 8. Generally, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The functionality of program modules may be combined or divided among program modules as desired in various embodiments. The machine-executable instructions for a program module may be executed in a local or distributed device. In a distributed device, the program module may reside in both local and remote storage media.

[0163] Program code for carrying out the methods of this disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a dedicated computer, or other programmable data processing device, so that when executed by the processor or controller, the program code implements the functions / operations specified in the flowcharts and / or block diagrams. The program code can run entirely on a machine, partially on a machine, as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0164] The program code described above may be embodied on a machine-readable medium, which may be any tangible medium capable of containing or storing a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any preferred combination thereof. More specific examples of machine-readable storage media include electrical connections with one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any preferred combination thereof.

[0165] Furthermore, although the operations are described in a specific order, this should not be understood as requiring that such operations be performed in a specific or sequential order, or that all described operations be performed, in order to achieve the desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Similarly, while details of some specific implementations are included in the above description, these should not be interpreted as limitations on the scope of this disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any preferred subcombination.

[0166] While this disclosure has been described in language specific to structural features and / or methodological behavior, it should be understood that the disclosure as defined in the attached claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as exemplary forms that implement the claims.

Claims

1. Terminal device, For the aforementioned terminal device, Receiving a medium access control (MAC) control element (CE) from the distributed unit (DU) of the network device, which indicates cell switching from a serving cell to a candidate cell, In accordance with the determination that the MAC CE includes security key update information, the security key is updated based on the security key update information. A processor configured to perform this task. A terminal device equipped with the following features.

2. The update information of the security key is An indicator showing whether the key set has been changed. The value of the next hop chain count, or Security key counter value, The terminal device according to claim 1, comprising at least one of the following.

3. In accordance with the determination that the indicator shows the key set has been changed, update the master key based on the key for the access and mobility management function (AMF). At least update the master key based on the value of the next-hop chain count, or The secondary key is updated based on the master key and the security key counter values. The terminal device according to claim 2, configured to update the security key by at least one of the following.

4. The medium access control (MAC) layer displays the information to the upper layer of the terminal device, Based on the update information of the security key, the upper layer updates the security key, The terminal device according to claim 1, configured to update the security key by

5. In accordance with the determination that the MAC CE includes the update information for the security key, a procedure including at least one of the following, namely: To apply the encryption algorithm and encryption key, configure at least one data radio bearer (DRB) or signaling radio bearer (SRB) packet data convergence protocol (PDCP) entity. To apply the integrity protection algorithm and the integrity protection key, the PDCP entity of the at least one DRB or SRB is configured. Re-establishing the PDCP entity of at least one DRB, Re-establishing the PDCP entity of at least one SRB, or Re-establish the radio link control (RLC) entity of at least one radio bearer, Perform a procedure that includes at least one of the following: The terminal device according to claim 1, further configured as follows.

6. In accordance with the determination that the MAC CE does not contain the update information for the security key, an action including at least one of the following: Do not update the aforementioned security key. Triggering a packet data convergence protocol (PDCP) entity of at least one signaling radio bearer (SRB) to perform service data unit (SDU) decommissioning, or To determine whether a layer 2 (L2) reset procedure is performed based on the identity (ID) value of the serving cell and the ID value of the candidate cell, Perform an action that includes at least one of the following: It is further constructed in such a way. The terminal device according to claim 1.

7. The L2 reset procedure described above is: Triggering the PDCP entity of at least one data radio bearer (DRB) to perform data recovery, or Re-establish the radio link control (RLC) entity of at least one radio bearer. The terminal device according to claim 6, comprising at least one of the following.

8. A distributed unit (DU) of a network device, In the aforementioned DU, Receiving update information for security keys for cell switching from a serving cell to a candidate cell, which permits layer 1 or layer 2 triggered mobility (LTM), from the central unit (CU) of the network device, In accordance with the decision that the cell switching to the candidate cell is performed, a medium access control (MAC) control element (CE) indicating the cell switching to the candidate cell, the MAC CE including the update information of the security key, is transmitted to the terminal device. A processor configured to perform this task. A distributed unit (DU) equipped with this feature.

9. The update information for the security key is An indicator showing whether the key set has been changed. The value of the next hop chain count, or Security key counter value, The DU according to claim 8, comprising at least one of the following.

10. In accordance with the decision to perform the cell switching to the candidate cell, the information of the candidate cell is transmitted to the CU, The CU receives the update information of the security key, The DU according to claim 8, configured to receive the update information of the security key.

11. The information of the candidate cell is Identification information of the candidate cell, or Identification information of the LTM configuration associated with the candidate cell, The DU according to claim 10, comprising at least one of the following.

12. In accordance with the determination that the terminal device is accessing the serving cell, the CU transmits an instruction indicating that it is accessing the cell. The CU receives the update information of the security key, The DU according to claim 8, configured to receive the update information of the security key.

13. A central unit (CU) of a network device, The aforementioned CU, Send security key update information for cell switching from a serving cell to a candidate cell, which allows layer 1 or layer 2 triggered mobility (LTM), to the distributed unit (DU) of the network device. A processor configured to do so A central unit (CU) equipped with this.

14. The update information for the security key is An indicator showing whether the key set has been changed. The value of the next hop chain count, or Security key counter value, The CU according to claim 13, comprising at least one of the following.

15. Receiving information about the candidate cell from the DU, Sending the update information of the security key to the DU, The CU according to claim 13, configured to transmit the update information of the security key by means of the above.

16. The information of the candidate cell is Identification information of the candidate cell, or Identification information of the LTM configuration associated with the candidate cell, The CU according to claim 15, comprising at least one of the following.

17. The information of the candidate cell and the security key associated with the candidate cell are transmitted to a further network device that provides the candidate cell. The CU according to claim 15, further configured as follows.

18. The terminal device receives an instruction from the DU to access the serving cell, Sending the update information of the security key to the DU, The CU according to claim 13, configured to transmit the update information of the set of security keys.

19. Send a set of candidate cells that allow LTM and a set of associated security keys to a set of network devices that provide the set of candidate cells. The CU according to claim 18, further configured as follows.

Images