Method and apparatus for generating keys during handover of a service network node

Abstract

Embodiments of this disclosure provide a method and apparatus for generating a key during handover of a serving network node. A method (300) performed by a first network node in a communication network includes: obtaining (S302) an identifier of a second network node; and calculating (S304) a key to be used for communication between the second network node and a terminal device, based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node. According to embodiments of this disclosure, exemplary embodiments of this disclosure propose a mechanism that provides a feasible security solution framework for calculating new keys during handover of serving network nodes. Security risks due to duplicate keys can be avoided.

Description

Technical Field

[0001] Various exemplary embodiments of this disclosure generally relate to communication technologies, and particularly to methods and apparatus for generating keys during the handover of serving network nodes. Background Technology

[0002] In current communication systems, such as 3GPP 5G and NR, the service network nodes of terminal devices may change in many cases, such as due to the mobility of terminal devices or network nodes.

[0003] For example, when a mobile network node (such as a satellite or other mobile station or mobile gateway) is serving a terminal device, the last serving satellite may move away from the terminal device, and the next serving satellite may move towards the terminal device. The terminal device can disconnect from the last serving satellite and then connect to the next serving satellite. Due to security principles, some keys for encryption / decryption of communication between the terminal device and the next serving satellite should be recalculated / regenerated.

[0004] However, the last-serving satellite and the next-serving satellite can share some configurations / parameters. When keys are calculated / generated based on such shared parameters, some keys of the last-serving network node and some keys of the next-serving network node can be the same. Therefore, there may be security risks. Summary of the Invention

[0005] This summary is provided to present a simplified version of some aspects, which will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0006] Certain aspects of this disclosure and its embodiments can provide solutions to these or other challenges. Various embodiments for addressing one or more problems disclosed herein are presented. Specific methods and apparatus for generating keys during the handover of serving network nodes can be provided.

[0007] A first aspect of this disclosure provides a method performed by a first network node in a communication network. The method includes: obtaining an identifier of a second network node; and calculating a key, based at least on the identifier of the second network node, for use in communication between the second network node and a terminal device. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0008] In an exemplary embodiment of this disclosure, the method further includes: storing a key in a context for a terminal device; sending the key to a second network node; and sending an identifier of the second network node to the terminal device via a system information block or via Radio Resource Control (RRC) signaling to the terminal device.

[0009] In an exemplary embodiment of this disclosure, the key is used for communication between the second network node and the terminal device during an RRC recovery process initiated by the terminal device or during a handover of the terminal device from a first network node to a second network node.

[0010] In an exemplary embodiment of this disclosure, the identifier of the second network node includes: a global identifier of the second network node; a local next-generation radio access network (NG-RAN) node identifier; or an identifier of the vehicle or platform carrying the second network node.

[0011] In an exemplary embodiment of this disclosure, the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

[0012] In an exemplary embodiment of this disclosure, the key includes an intermediate key K. NG-RAN Furthermore, the key is calculated based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next hop (NH) count.

[0013] In an exemplary embodiment of this disclosure, the key is computed using vertical key derivation and horizontal key derivation.

[0014] In an exemplary embodiment of this disclosure, the key is used to further derive a Radio Resource Control (RRC) integrity key and an RRC encryption key.

[0015] In an exemplary embodiment of this disclosure, when serving a terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

[0016] In an exemplary embodiment of this disclosure, the first network node is a first non-terrestrial network (NTN) network node in a non-terrestrial network; and the second network node is a second NTN network node in a non-terrestrial network.

[0017] A second aspect of this disclosure provides a method performed by a second network node in a communication network. The method includes: communicating with a terminal device using a key. The key is calculated based at least on an identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least a first network node.

[0018] In an exemplary embodiment of this disclosure, the method further includes: sending an identifier of a second network node to a terminal device via a system information block or via Radio Resource Control (RRC) signaling to a terminal device.

[0019] In an exemplary embodiment of this disclosure, the key is calculated by the second network node or received from the first network node; the key is used for communication between the second network node and the terminal device during an RRC recovery process initiated by the terminal device or during a handover of the terminal device from the first network node to the second network node.

[0020] In an exemplary embodiment of this disclosure, the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

[0021] In an exemplary embodiment of this disclosure, when serving a terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

[0022] In an exemplary embodiment of this disclosure, the first network node is a first non-terrestrial network (NTN) network node in a non-terrestrial network; and the second network node is a second NTN network node in a non-terrestrial network.

[0023] In an exemplary embodiment of this disclosure, the identifier of the second network node includes: a global identifier of the second network node; a local next-generation radio access network (NG-RAN) node identifier; or an identifier of the vehicle or platform carrying the second network node.

[0024] In an exemplary embodiment of this disclosure, the key includes an intermediate key K. NG-RAN Furthermore, the key is calculated based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

[0025] In an exemplary embodiment of this disclosure, the key is computed using vertical key derivation and horizontal key derivation.

[0026] In an exemplary embodiment of this disclosure, the key is used to further derive a Radio Resource Control (RRC) integrity key and an RRC encryption key.

[0027] A third aspect of this disclosure provides a method performed by a terminal device in a communication network, the method comprising: communicating with a second network node using a key. The key is calculated based at least on an identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least a first network node.

[0028] In an exemplary embodiment of this disclosure, the method further includes: receiving an identifier of a second network node from a second network node or a first network node via a system information block or via Radio Resource Control (RRC) signaling to a terminal device; or obtaining an identifier of a second network node from ephemeris data.

[0029] In an exemplary embodiment of this disclosure, the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

[0030] In an exemplary embodiment of this disclosure, the key is used for communication between the second network node and the terminal device during an RRC recovery process initiated by the terminal device or during a handover of the terminal device from a first network node to a second network node.

[0031] In an exemplary embodiment of this disclosure, when serving a terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

[0032] In an exemplary embodiment of this disclosure, the first network node is a first non-terrestrial network (NTN) network node in a non-terrestrial network; and the second network node is a second NTN network node in a non-terrestrial network.

[0033] In an exemplary embodiment of this disclosure, the identifier of the second network node includes: a global identifier of the second network node; a local next-generation radio access network (NG-RAN) node identifier; or an identifier of the vehicle or platform carrying the second network node.

[0034] In an exemplary embodiment of this disclosure, the key includes an intermediate key K. NG-RAN Furthermore, the key is calculated by the terminal device based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

[0035] In an exemplary embodiment of this disclosure, the key is computed using vertical key derivation and horizontal key derivation.

[0036] In an exemplary embodiment of this disclosure, the key is used to further derive a Radio Resource Control (RRC) integrity key and an RRC encryption key.

[0037] A fourth aspect of the invention provides a first network node. The first network node includes components configured to: acquire an identifier of a second network node; and, based at least on the identifier of the second network node, calculate a key to be used for communication between the second network node and a terminal device. The identifier of the second network node distinguishes the second network node from at least the first network node. The components include: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause execution of the first network node.

[0038] In exemplary embodiments of this disclosure, the component is also configured to perform a method according to any exemplary embodiment of the first aspect.

[0039] A fifth aspect of the invention provides a second network node. The second network node includes components configured to communicate with a terminal device using a key. The key is calculated based at least on an identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least a first network node. The components include: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause execution of the second network node.

[0040] In exemplary embodiments of this disclosure, the component is also configured to perform a method according to any exemplary embodiment of the second aspect.

[0041] A sixth aspect of the present invention provides a terminal device. The terminal device includes components configured to: communicate with a second network node using a key. The key is calculated based at least on an identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least a first network node. The components include: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause execution by a third network node.

[0042] In exemplary embodiments of this disclosure, the component is also configured to perform a method according to any exemplary embodiment of the third aspect.

[0043] A seventh aspect of this disclosure provides a computer-readable storage medium. The computer-readable storage medium stores instructions that, when executed by at least one processor of a device, cause the at least one processor of the device to perform a method according to any exemplary embodiment of the first, second, and third aspects.

[0044] According to embodiments of this disclosure, exemplary embodiments of this disclosure propose a mechanism that provides a feasible security solution framework for calculating new keys during the handover of service network nodes. This can avoid security risks caused by duplicate keys. Attached Figure Description

[0045] The above and other aspects, features, and benefits of various embodiments of this disclosure will become more apparent by way of example from the following detailed description with reference to the accompanying drawings, wherein the same reference numerals or letters are used to denote the same or equivalent elements. The drawings are shown to facilitate a better understanding of embodiments of this disclosure and are not necessarily drawn to scale. In the drawings:

[0046] Figure 1A This is the first part of an example diagram illustrating a connection restoration scenario under the deployment of regenerated NTN NGSO satellites.

[0047] Figure 1B This is the second part of an example diagram illustrating a connection restoration scenario under the deployment of regenerated NTN NGSO satellites.

[0048] Figure 1C This is the third part of an example diagram illustrating a connection restoration scenario under the deployment of regenerated NTN NGSO satellites.

[0049] Figure 2 This is an example diagram illustrating a simple HO scenario considering the deployment of regenerated NTN NGSO satellites.

[0050] Figure 3A This is a flowchart illustrating a method performed by a first network node according to an exemplary embodiment of the present disclosure.

[0051] Figure 3B This illustrates exemplary embodiments according to this disclosure. Figure 3A A flowchart of the other steps of the method shown.

[0052] Figure 4A This is a flowchart illustrating a method performed by a second network node according to an exemplary embodiment of the present disclosure.

[0053] Figure 4B This illustrates exemplary embodiments according to this disclosure. Figure 4A A flowchart of the other steps of the method shown.

[0054] Figure 5A This is a flowchart illustrating a method performed by a terminal device according to an exemplary embodiment of the present disclosure.

[0055] Figure 5B This illustrates exemplary embodiments according to this disclosure. Figure 5A A flowchart of the other steps of the method shown.

[0056] Figure 6A This is a diagram illustrating a first portion of a first example call flow according to an embodiment of the present disclosure.

[0057] Figure 6B This is a diagram illustrating a second portion of a first example call flow according to an embodiment of the present disclosure.

[0058] Figure 6C This is a diagram illustrating a third portion of a first example call flow according to an embodiment of the present disclosure.

[0059] Figure 6D This is a diagram illustrating a fourth portion of a first example call flow according to an embodiment of the present disclosure.

[0060] Figure 7A This is a diagram illustrating a first portion of a second example call flow according to an embodiment of the present disclosure.

[0061] Figure 7B This is a diagram illustrating a second portion of a second example call flow according to an embodiment of the present disclosure.

[0062] Figure 7C This is a diagram illustrating a third portion of a second example call flow according to an embodiment of the present disclosure.

[0063] Figure 7D This is a diagram illustrating a fourth portion of a second example call flow according to an embodiment of the present disclosure.

[0064] Figure 8 This is a diagram illustrating a third example call flow according to an embodiment of the present disclosure.

[0065] Figure 9 This is a block diagram illustrating an exemplary structure of a first network node according to an exemplary embodiment of the present disclosure.

[0066] Figure 10 This is a block diagram illustrating an exemplary structure of a second network node according to an exemplary embodiment of the present disclosure.

[0067] Figure 11 This is a block diagram illustrating an exemplary structure of a terminal device according to an exemplary embodiment of the present disclosure.

[0068] Figure 12 This is a block diagram illustrating an apparatus / computer-readable storage medium according to embodiments of the present disclosure.

[0069] Figure 13 This is a block diagram illustrating an exemplary device unit of a first network node suitable for performing a method according to an embodiment of the present disclosure.

[0070] Figure 14This is a block diagram illustrating an exemplary device unit suitable for performing the methods according to embodiments of the present disclosure for a second network node.

[0071] Figure 15 This is a block diagram illustrating exemplary device units of a terminal device suitable for performing methods according to embodiments of the present disclosure. Detailed Implementation

[0072] Embodiments of this disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for a better understanding and not for limiting the scope of this disclosure. The features, advantages, and characteristics described in this disclosure may be combined in any suitable manner in one or more embodiments.

[0073] Generally, all terms used herein should be interpreted according to their ordinary meaning in the relevant art, unless otherwise expressly given and / or implied. Unless the context explicitly gives and / or implies otherwise, the steps of any method disclosed herein need not be performed in the exact order disclosed. Any feature of any embodiment disclosed herein may be applied to any other embodiment, wherever appropriate.

[0074] As used herein, the term "network" or "communication network" refers to a network that conforms to any suitable communication standard, such as the Internet or any wireless network. For example, wireless communication standards may include WLAN (Wireless Local Area Network), New Radio (NR), Long Term Evolution (LTE), LTE-Advanced, 5G NR, etc. In the following description, the terms "network" and "system" are used interchangeably.

[0075] The term "node / network node" refers to a computing device, computing entity, computing function, or any other device (physical or virtual) in a communication network. For example, a node in a network can include a base station (BS), an access point (AP), or any other suitable device in a wireless communication network. A BS can be, for example, a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next-generation Node B (gNodeB or gNB), a Remote Radio Unit (RRU), a Radio Header (RH), a Remote Radio Header (RRH), a relay, a low-power node (such as a femtosecond or picosecond), etc. Furthermore, a node can include other core network nodes, such as Access and Mobility Management Functions (AMF), Session Management Functions (SMF), User Plane Functions (UPF), Mobility Management Entities (MME), or Serving Gateways (S-GW), etc.

[0076] The term "terminal device" refers to any terminal device that can access a communication network and receive services from it. By way of example and not limitation, a terminal device refers to a mobile terminal, user equipment (UE), non-AP device (such as a non-AP station (STA)), or other suitable device. Terminal devices can include, but are not limited to, mobile phones, cellular phones, smartphones, wearable devices, in-vehicle wireless terminal equipment, vehicles, etc.

[0077] As an example, a terminal device can refer to a device configured for communication according to one or more communication standards promulgated by any standards organization, such as the 3rd Generation Partnership Project (3GPP).

[0078] As another example, in the Internet of Things (IoT) scenario, a terminal device can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another terminal device and / or network device. Specific examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances such as refrigerators, televisions, and personal wearable devices such as watches. In other scenarios, a terminal device can represent a vehicle or other device capable of monitoring and / or reporting its operational status or other functions related to its operation.

[0079] It should be understood that although the terms “first” and “second” may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed terms.

[0080] As used herein, “at least one of the following: ” and “at least one of ” and similar wording (where a list of two or more elements is connected by “and” or “or”) means at least any one of these elements, or at least any two or more of these elements, or at least all of these elements.

[0081] This disclosure proposes enhancements to secure key derivation. As an example, and not a limiting one, it illustrates a scenario of a non-terrestrial network (NTN) regenerating a non-geostationary (NGSO) network with a complete gNB on a satellite, considering an invariant Physical Cell Identifier (PCI). However, it should be noted that any other scenario requiring key recalculation may also be applicable.

[0082] 3GPP TR 38.821 V16.2.0 (2023-03) for research on New Radio (NR) NTN considers the following two architectural options: - Transparent architecture: In which the satellite payload performs frequency conversion, amplification and filtering, and the gNB is located on the ground. - Regenerative architecture: Some or all of the gNBs should be installed on the satellite.

[0083] The 3rd Generation Partnership Project (3GPP) Releases (Rel) 17 and Rel-18 introduced NTN support for transparent architecture.

[0084] The NTN enhancements in Rel-19 are expected to introduce support for regenerated payloads, using full gNBs on satellites or gNB distributed units (DUs) for NR NTN on satellites. Expected enhancements for NTN mobility and service continuity include enhanced support in RRC (Radio Resource Control) INACTIVE and enhancements to NTN mobility using regenerated NGSOs.

[0085] In the Radio Access Network (RAN) #101 plenary discussion, key priorities that need to be considered within the scope of specifications Rel-19 and later were supported, such as supporting the RRC_INACTIVE state for regenerable NGSO satellite deployment and enhancing NTN mobility and service continuity for regenerable NGSO satellite deployment.

[0086] In 5G NR, the RRC_INACTIVE state allows the NG RAN node to suspend the UE's RRC connection while the NG RAN and UE continue to maintain the UE's 5G AS security context. By allowing the UE to transition to the RRC_CONNECTED state, the UE's RRC connection can be restored later.

[0087] The UE can transition from the RRC_INACTIVE state to the RRC_CONNECTED state, and then to the same last serving NG RAN node that will transfer the UE to the RRC_INACTIVE state, or to a different NG RAN node.

[0088] When the UE is in the RRC_INACTIVE state, the UE and the last serving NG RAN node store the UE 5G AS security context. When the UE transitions from RRC_INACTIVE to RRC_CONNECTED, the UE 5G AS security context can be reactivated.

[0089] When the NG RAN node decides to suspend the UE's RRC connection, it should send an RRCRelease message to the UE. suspendConfigThe message is encrypted and is protected for integrity at the PDCP layer using the current AS security context.

[0090] NG RAN nodes should include a fresh, inactive temporary radio network identifier (I-RNTI) and a [missing information] in the RRCrease. suspendConfig Next-hop chain counter (NCC) for messages.

[0091] I-RNTI is used to identify both the UE and the gNB that manages the UE context.

[0092] NCC (Next Hop Chain Counter) is an AS encryption key used for deriving the next hop access key.

[0093] Sending data to the UE with suspendConfig Following the RRCRelease message, the NG RAN node: - The current access stratum (AS) key K should be retained. RRCint And delete other AS keys. - The transmitted I-RNTI should be stored together with the current UE context (including the rest of the AS security context).

[0094] Received from NG RAN node suspendConfig After the message is re-RRCReleaseed, the UE should verify that the integrity of the received message is correct by verifying the calculated message integrity authentication code (MAC-I) and the received MAC-I field.

[0095] After successful verification, the UE should store the following content: - The received NCC value with the current UE context. - Current AS key K RRCint The key is deleted, along with all other AS keys. - The received I-RNTI with the remainder of the current UE context and AS context.

[0096] When the UE decides to restore the RRC connection to transition from RRC_INACTIVE to RRC_CONNECTED, it sends an RRCResumeRequest message including I-RNTI and ResumeMAC-I. I-RNTI is used for context identification, and ResumeMAC-I is a 16-bit authentication token that is computed using an integrity algorithm from the AS security context stored at the UE.

[0097] After sending the RRRCResumeRequest message, the UE should, based on the horizontal key derivation or vertical key derivation defined in Clause 6.9.2.1.1 and Annexes A.11 / A.12 of 3GPP TS 33.501 V18.4.0 (2023-12), use the target PCI, target ARFCN-DL, and K... gNB / NH derived from K NG-RAN .

[0098] When the target NG RAN node (i.e., the next serving network node) receives the RRCResumeRequest message from the UE, it extracts the I-RNTI from the RRCResumeRequest message and retrieves the UE context request message by sending the Xn Application Protocol (Xn-AP). Based on the information in the I-RNTI, it contacts the source NG RAN node (i.e., the last serving network node). This message includes the I-RNTI, ResumeMAC-I, and the target cell ID, so that the source NG RAN node can verify the request and retrieve the UE context, including the UE's 5G AS security context.

[0099] The source NG RAN node uses I-RNTI to retrieve the stored UE context, including the UE 5G AS security context, from its database.

[0100] The source NG RAN node uses the current K stored in the retrieved UE 5G AS security context. RRCint Key verification ResumeMAC-I. Following successful ResumeMAC-I verification, based on horizontal or vertical key derivation, the source NGRAN node uses the target cell PCI, the target absolute radio channel number (ARFCN)-downlink (DL), and the K value in the current UE 5GAS security context. gNB / Next hop (NH) count, calculate K NG-RAN .

[0101] The source NG RAN node can obtain the target PCI and target ARFCN-DL from the cell configuration database by receiving the target cell ID from the target NG RAN node.

[0102] Based on the above, the source NG RAN node should respond to the target NG RAN node by retrieving the UE context response message using Xn-AP, which includes the UE 5G AS security context. This context includes the newly derived K... NG-RAN 、and K NG-RAN The associated NCC, UE 5G security capabilities, user plane (UP) security policies, UP security activation status with (multiple) corresponding protocol data unit (PDU) session IDs, and encryption and integrity algorithms used by the UE at the source cell.

[0103] Assuming the target NG RAN node supports the encryption and integrity algorithms used in the last source cell (otherwise, the target NG RAN should trigger RRC connection establishment as if the UE were idle), the target NG RAN should use the algorithm used by the UE with the source cell and the received K... NG-RAN Derive new AS keys (RRC integrity key, RRC encryption key, and UP key). The target NG RAN node should reset all Packet Data Convergence Protocol (PDCP) counts to 0 and activate the new keys in the PDCP layer. The target NG RAN node should respond to the UE with an RRC recovery message on Signalling Radio Bearer (SRB) 1, which is integrity-protected and encrypted using the new RRC key in the PDCP layer.

[0104] When the UE receives the RRRCResume message, the UE should use the newly derived K... NG-RAN And the derived K RRCenc The message is decrypted. The UE should also use the newly derived K... NG-RAN K derived from RRCint Verify the PDCP MAC-I to verify the "RRC Connection Restore" message. If the RRC Resume message verification is successful, the UE should delete the current K... RRCint The key, and the UE should pass the newly derived K. NG-RAN K in RRCint Saved as part of the UE's current AS security context. Afterwards, the UE should use the current K... RRCint (For integrity) and K RRCenc (For encryption) Send an integrity-protected and encrypted RRRCResumeComplete message to the target gNB / ng-eNB on SRB1.

[0105] Following a successful transition from RRC_INACTIVE to RRC_CONNECTED, the target NG RAN node should use the Access and Mobility Management Function (AMF) to perform a path handover request procedure. The AMF should verify the UE's security capabilities, and the Session Management Function (SMF) should verify the UE's security policies.

[0106] In NTN regenerative NGSO satellite deployment scenarios, such as regenerative low Earth orbit (LEO) deployments with a full gNB on the satellite, the LEO beam coverage range can be between 50 and 1000 km (beam diameter of 20 to 40 km), and the LEO satellite continuously orbits the Earth at a relative speed of 7.56 km / sec. This means that even for a stationary UE on Earth, the serving satellite (serving gNB) will change at fixed time intervals.

[0107] For connected mode UEs, the handover should be triggered.

[0108] However, for UEs in the RRC_INACTIVE state, when a connection needs to be restored (e.g., due to UL or DL ​​data), the UE can be served by a different (new) satellite (and therefore a gNB) (because the NGSO satellite constellation orbits the Earth continuously), and the last serving satellite (and therefore a gNB) that preserves the UE context can be multiple hops apart.

[0109] UE context retrieval beyond multi-hop in NTN regenerated NGSO satellite deployment scenarios is not defined in existing specifications. It may be applicable to later versions of the specification. The inventors of this disclosure have also made some suggestions. However, in this invention, it focuses on enhancements to secure key computation, and the specific manner of multi-hop transmission is not limited.

[0110] Based on the fundamental security principles involved in RRC state transitions (and handovers), the UE knows the changing cell and gNB, and the UE knows how to calculate the key for each cell change or gNB change.

[0111] In the event of a switchover, the source gNB computes a fresh key (Kgnb) for each target gNB. or K NG-RAN The new key is transmitted via the Xn interface. The parameters used for key calculation are the target PCI, target ARFCN-DL, and KgNB / NH, which are derived based on horizontal or vertical key derivation.

[0112] For the RRC_INACTIVE state, the source gNB uses the target cell PCI, the target ARFCN-DL / EARFCN (Evolved Universal Terrestrial Radio Access Absolute Radio Channel Number)-DL, and KgNB / NH to calculate a fresh key (Kgnb) for each potential target gNB. or K NG-RAN ), and transmit it to the target gNB via the Xn interface.

[0113] NTN can be deployed to have: Earth Fixed Cell (EFC) – where the satellite beam turns from the minimum elevation angle on one side of the horizon to the minimum elevation angle on the other side of the horizon to the geographic NTN cell on Earth. or Earth Moving Cell (EMC) – where the satellite beam should be fixed and unmanipulated, and move with the satellite.

[0114] Given that the deployment of NTN and Earth Fixed Cell (EFC) is not very complex, it can be achieved through one of the following options: Option 1: Satellite handover causes PCI changes. A possible implementation is to associate each NTN cell with a pair of PCIs, which change alternately with satellite handover. Option 2: PCI remains unchanged during satellite switching.

[0115] In Rel-18, RAN2 agreed to support 'satellite handover without PCI change' in cases involving hard satellite handover in quasi-Earth fixed cells with the same gNB.

[0116] For satellite handover scenarios involving gNB changes, Option 2 is likely to be extended to the regenerated NGSO scenario in Rel-19.

[0117] If we consider implementing option 2, one scenario is that even if the serving satellite (and therefore the serving gNB) changes after each fixed time period, the PCI of the NTN cell remains fixed for both stationary UEs and UEs that do not experience cell changes.

[0118] From a security perspective, this represents the current set of parameters used in the RRC_INACTIVE state: - Key calculations at the source gNB: target cell PCI, target ARFCN-DL / EARFCN-DL, and KgNB / NH - For the authentication token at the UE (when the connection is restored): source PCI, target cell ID, source C-RNTI. This could introduce security risks because the PCI is the same for the last serving gNB and the next serving gNB.

[0119] Therefore, when the serving satellite (and serving gNB) changes, a different set of parameters is needed to derive a fresh key. This is the main problem that this disclosure aims to solve.

[0120] Figure 1A This is the first part of an example diagram illustrating a connection restoration scenario under the deployment of regenerated NTN NGSO satellites.

[0121] Figure 1BThis is the second part of an example diagram illustrating a connection restoration scenario under the deployment of regenerated NTN NGSO satellites.

[0122] Figure 1C This is the third part of an example diagram illustrating a connection restoration scenario under the deployment of regenerated NTN NGSO satellites.

[0123] Figure 1A , Figure 1B , Figure 1C The illustration depicts a simple connection recovery scenario in an NTN-regenerated NGSO satellite deployment, using key security aspects and parameters for connection recovery and new key derivation as examples.

[0124] In this scenario, due to the movement of the gNB or UE, gNB1 (NGSO satellite 1), gNB2 (NGSO satellite 2), and gNB3 (NGSO satellite 3) sequentially provide coverage for the terminal equipment (UE). The UE first connects to gNB1 and then disconnects from it (i.e., gNB1 is the last serving network node). When the UE needs to reconnect to the network, gNB3 is serving the UE (i.e., gNB3 is the next serving network node).

[0125] It is important to note that if the UE switches from gNB1 to gNB2, gNB1 can be the last serving network node, and gNB2 can be the next serving network node. Then, when the UE switches from gNB2 to gNB3, gNB2 can be the last serving network node, and gNB3 can be the next serving network node, and so on.

[0126] Figure 1A , Figure 1B , Figure 1C The main steps are shown.

[0127] In step 1: The UE is in RRC_CONNECTED, Connection Management (CM) - CONNECTED state;

[0128] In step 2: downlink (DL) data;

[0129] In step 3: an assumed Xn connection is established between consecutive gNBs in the satellite orbit (and therefore multi-hop UE context retrieval can be performed);

[0130] In step 4: RRC release (with SuspendConfig(I-RNTI, NCC));

[0131] In step 5: the AS key KRRCint, I-RNTI, and AS security context are stored in the UE context;

[0132] In step 6: Verify that the integrity of the received message is correct by checking the MAC-I field;

[0133] In step 7: the received NCC, the current AS key KRRCint key, the received I-RNTI, and the AS context are stored in the current UE context;

[0134] In step 8: The UE is in RRC_INACTIVE CM-CONNECTED;

[0135] In step 9, a stationary UE can remain in the same NTN cell, and a mobile UE can reselect a new NTN cell;

[0136] In step 10: Starting from time T, gNB1 serves the cell;

[0137] In step 11: Starting from time (T+T1), gNB2 serves the cell;

[0138] In step 12: Starting from time (T+2T1), gNB3 serves the cell;

[0139] In step 13: at time (T+2T1), the UE has UL data to send;

[0140] In step 14: RRRCResumeRequest, I-RNTI, ResumeMAC-I;

[0141] In step 15: Use the target PCI, target ARFCN-DL / EARFCN-DL and KgNB / NH to derive KNG-RAN ;

[0142] In step 16: Retrieve the UE context request, I-RNTI, ResumeMAC-I, and target cell ID;

[0143] Step 17: Verify ResumeMAC-I using the current KRRCint key stored in the retrieved UE 5G AS security context;

[0144] In step 18, the source gNB uses the source PCI, the target cell ID (e.g., PCI), the target ARFCN-DL / EARFCN-DL, and the KgNB / NH in the current UE 5G AS security context to calculate K. NG-RAN ;

[0145] In step 19, the source gNB will use the newly derived key 'K' NG-RAN Including UE context retrieval response, UE 5G AS security context (newly derived KNG-RAN) In the NCC);

[0146] In step 20: Use the received K NG-RAN Derive a new AS key;

[0147] In step 21: RRCResume;

[0148] In step 22: 1. Use K based on the new derivation NG-RAN The derived KRRCenc decrypts the message; 2. By using the newly derived K NG-RAN The KRRCint derived from it verifies the PDCP MAC-I to verify the "RRC connection restored" message;

[0149] In step 23, the newly derived KNG-RAN The KRRCint in the data is stored as part of the UE's current AS security context;

[0150] In step 24, the UE is in RRC_CCONNECTED CM-CONNECTED state;

[0151] In step 25: RRCResumeComplete;

[0152] In step 26: Data forwarding address indication;

[0153] In step 27: Path switching request;

[0154] In step 28: Path switching request response;

[0155] In step 29: DL data;

[0156] In step 30: UE context release.

[0157] Figure 2 This is an example diagram illustrating a simple HO scenario considering the deployment of regenerated NTN NGSO satellites.

[0158] Figure 2 The illustration depicts a simple NTN mobility scenario in an NTN-regenerated NGSO satellite deployment, with an example of the key security aspects and parameters used in the handover for new key derivation.

[0159] exist Figure 2 During this process, the UE performs a handover from gNB1 (last serving network node) to gNB2 (next serving network node).

[0160] Figure 1 mainly illustrates the following steps.

[0161] In step 1: The UE is in the RRC_CONNECTED or CM-CONNECTED state;

[0162] Step 2: DL data;

[0163] In step 3: Starting from time T, gNB1 serves the cell;

[0164] Step 4: Assume Xn connection between consecutive gNBs in the satellite orbit;

[0165] In step 5: HO decides;

[0166] In step 6, the serving satellite gNB should, based on the target PCI, its frequency ARFCN-DL, and the current active K, gNB Or calculate KNG-RAN using NH (next hop) count. ;

[0167] In step 7, the serving satellite gNB initiates a process including K NG-RAN HO request with NCC;

[0168] In step 8, the next service (or target) gNB should perform the following operations: • Receive K NG-RAN Used directly as K to be used with UE gNB ; • Combine the received NCC value with K gNB Associate it and include it in the prepared HO command message.

[0169] In step 9, the switch request confirms that K is included in the transparent container. gNB 、NCC.

[0170] In step 10, the switch is triggered.

[0171] In step 10.1, the UE should derive K NG-RAN ○ (Case 1) If the NCC value received in the HO command is equal to the current active K gNB The associated NCC value is then derived from the current activity K. gNB The key is derived from the target PCI and its frequency ARFCN-DL. ○ (Case 2) Otherwise, if the NCC value received by the UE is different from the current active K gNBIf the associated NCC is specified, the UE should calculate K based on the synchronized NH parameters and the target PCI and its frequency ARFCN-DL. NG-RAN .

[0172] In step 11, DL data.

[0173] However, in NTN Regenerating Earth Fixed Cell (EFC) deployment, even if the serving satellite (and serving gNB) changes, the PCI of the NTN cell can remain unchanged for stationary UEs and UEs that do not experience cell changes.

[0174] According to safety principles, if the following parameter set: • For RRC_INACTIVE status: Source PCI, Target Cell ID, Source C-RNTI • For switching: Target PCI, Target ARFCN-DL and KgNB / NH If the service satellites do not change when they change, new parameters must be introduced to distinguish these satellites.

[0175] Figure 3A This is a flowchart illustrating a method performed by a first network node according to an exemplary embodiment of the present disclosure.

[0176] like Figure 3A As shown, method 300 includes: step S302, obtaining an identifier of a second network node; and step S304, calculating a key that will be used for communication between the second network node and a terminal device, based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0177] According to embodiments of this disclosure, exemplary embodiments of this disclosure propose a mechanism that provides a feasible security solution framework for calculating new keys during the handover of serving network nodes. Security risks arising from duplicate keys can be avoided when the key is calculated based at least on the identifier of the second network node.

[0178] Figure 3B This illustrates exemplary embodiments according to this disclosure. Figure 3A A flowchart of the other steps of the method shown.

[0179] In an exemplary embodiment of this disclosure, method 300 further includes: step S306, storing the key in a context for the terminal device; step S308, sending the key to the second network node; and step S310, sending the identifier of the second network node to the terminal device via a system information block or via Radio Resource Control (RRC) signaling to the terminal device.

[0180] According to embodiments of this disclosure, the key or identifier of the second network node can be transmitted to both the second network node and the terminal device. Therefore, the key can be prepared in advance by the second network node and the terminal device prior to communication between them.

[0181] In an exemplary embodiment of this disclosure, the key is used for communication between the second network node and the terminal device during an RRC recovery process initiated by the terminal device or during a handover of the terminal device from a first network node to a second network node.

[0182] According to an embodiment of the present invention, the first network node may be the last serving network node, and the second network node may be the next serving network node.

[0183] In an exemplary embodiment of this disclosure, the identifier of the second network node includes: a global identifier of the second network node; a local next-generation radio access network (NG-RAN) node identifier; or an identifier of the vehicle or platform carrying the second network node.

[0184] The means of transport can be "airborne vehicles", and the platform can be "high-altitude platform station (HAPS)".

[0185] It should be noted that any other unique identifier or related parameter may also be used.

[0186] In an exemplary embodiment of this disclosure, the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

[0187] In an exemplary embodiment of this disclosure, the key includes an intermediate key K. NG-RAN Furthermore, the key is calculated based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

[0188] In an exemplary embodiment of this disclosure, the key is computed using vertical key derivation and horizontal key derivation.

[0189] It should be noted that any other derived algorithm that conforms to the specification or standard may also be used.

[0190] In an exemplary embodiment of this disclosure, the key is used to further derive a Radio Resource Control (RRC) integrity key and an RRC encryption key.

[0191] In an exemplary embodiment of this disclosure, when serving a terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

[0192] In an exemplary embodiment of this disclosure, the first network node is a first non-terrestrial network (NTN) network node in a non-terrestrial network; and the second network node is a second NTN network node in a non-terrestrial network.

[0193] Figure 4A This is a flowchart illustrating a method performed by a second network node according to an exemplary embodiment of the present disclosure.

[0194] like Figure 4A As shown, method 400 includes: step S402, communicating with a terminal device using a key. The key is calculated based at least on the identifier of a second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0195] Figure 4B This illustrates exemplary embodiments according to this disclosure. Figure 4A A flowchart of the other steps of the method shown.

[0196] In an exemplary embodiment of this disclosure, method 400 further includes: step S404, sending the identifier of the second network node to the terminal device via a system information block or via Radio Resource Control (RRC) signaling to the terminal device.

[0197] In an exemplary embodiment of this disclosure, the key is calculated by the second network node or received from the first network node; the key is used for communication between the second network node and the terminal device during an RRC recovery initiated by the terminal device or during a handover of the terminal device from the first network node to the second network node.

[0198] In an exemplary embodiment of this disclosure, the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

[0199] In an exemplary embodiment of this disclosure, when serving a terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

[0200] In an exemplary embodiment of this disclosure, the first network node is a first non-terrestrial network (NTN) network node in a non-terrestrial network; and the second network node is a second NTN network node in a non-terrestrial network.

[0201] In an exemplary embodiment of this disclosure, the identifier of the second network node includes: a global identifier of the second network node; a local next-generation radio access network (NG-RAN) node identifier; or an identifier of the vehicle or platform carrying the second network node.

[0202] In an exemplary embodiment of this disclosure, the key includes an intermediate key K. NG-RAN Furthermore, the key is calculated based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

[0203] In an exemplary embodiment of this disclosure, the key is computed using vertical key derivation and horizontal key derivation.

[0204] In an exemplary embodiment of this disclosure, the key is used to further derive a Radio Resource Control (RRC) integrity key and an RRC encryption key.

[0205] Figure 5A This is a flowchart illustrating a method performed by a terminal device according to an exemplary embodiment of the present disclosure.

[0206] like Figure 5A As shown, method 500 includes: step S502, communicating with a second network node using a key. The key is calculated based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0207] Figure 5B This illustrates exemplary embodiments according to this disclosure. Figure 5A A flowchart of the other steps of the method shown.

[0208] In an exemplary embodiment of this disclosure, method 500 further includes: step S504, receiving an identifier of a second network node from a second network node or a first network node via a system information block or via Radio Resource Control (RRC) signaling to a terminal device; or step S506, obtaining an identifier of a second network node from ephemeris data.

[0209] In an exemplary embodiment of this disclosure, the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

[0210] In an exemplary embodiment of this disclosure, the key is used for communication between the second network node and the terminal device during an RRC recovery initiated by the terminal device or during a handover of the terminal device from a first network node to a second network node.

[0211] In an exemplary embodiment of this disclosure, when serving a terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

[0212] In an exemplary embodiment of this disclosure, the first network node is a first non-terrestrial network (NTN) network node in a non-terrestrial network; and the second network node is a second NTN network node in a non-terrestrial network.

[0213] In an exemplary embodiment of this disclosure, the identifier of the second network node includes: a global identifier of the second network node; a local next-generation radio access network (NG-RAN) node identifier; or an identifier of the vehicle or platform carrying the second network node.

[0214] In an exemplary embodiment of this disclosure, the key includes an intermediate key K. NG-RAN Furthermore, the key is calculated by the terminal device based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

[0215] In an exemplary embodiment of this disclosure, the key is computed using vertical key derivation and horizontal key derivation.

[0216] In an exemplary embodiment of this disclosure, the key is used to further derive a Radio Resource Control (RRC) integrity key and an RRC encryption key.

[0217] According to embodiments of this disclosure, it provides a feasible security solution framework, particularly suitable for new key calculations for RRC_INACTIVE state and HO, when the serving satellite gNB changes due to satellite handover in a PCI-invariant NTN Regenerating Earth Fixed Cell (NGSO) scenario.

[0218] It should be noted that: 1. The UE context can be retrieved via a multi-hop Xn connection. 2. Based on the NTN protocol in 3GPP to date, the UE should be aware of the satellite handover time (i.e., the time when the serving gNB changes). This information is expected to be conveyed via NTN-specific SIB19. The UE obtains the SIB19 during satellite handover.

[0219] In summary, the embodiments of this disclosure propose to solve the aforementioned problems through the following main steps.

[0220] An approach is proposed to introduce a “gNB Id” or any other identifier that uniquely identifies the next serving satellite, such as a “satellite Id”, as an additional parameter for security key derivation in NTN NGSO fixed-cell (EFC) scenarios involving satellite handover without PCI changes. This is implemented through two solution variants or embodiments 1 and 2.

[0221] In one example embodiment, this requires introducing an additional ID (e.g., after parameter S1) as K. NG-RAN Derived inputs, such as updates to TS 33.501 V18.4.0 (2023-12) A.11. Derived functions of target gNB When from the current K gNB Or derived from the target physical cell ID in the fresh NH and UE and NG-RAN. NG-RAN Used for cutting When changing the destination and transitioning from the RRC_INACTIVE state to the RRC_CONNECTED state, the following parameters should be used to form the KDF (keyword-based method). The input S of the key-derived function. - FC=0x70 - P0 = PCI (Target Physical Cell ID) - L0 = the length of PCI (i.e., 0x00 0x02) - P1 = ARFCN - DL (absolute SSB frequency of the target Pcell as specified in Clause 13.3 of TS 38.300

[52] ) - L1 = the length of ARFCN-DL (i.e., 0x00 0x03) - S1 = Satellite ID, gNB ID, or any other ID . - L2 = length of satellite ID, gNB ID, or any other ID When the index NCC during the switch increases, the input key KEY should be a 256-bit NH; otherwise, it should be the current 256-bit key. K gNB (When the source is gNB) or K eNB (When the source is ng-eNB).

[0222] FC is used to distinguish different instances of an algorithm.

[0223] SSB can be a synchronization signal block, or a synchronization signal and physical broadcast channel block.

[0224] During key generation, the following keys, as shown in TS 33.501 V18.4.0 (2023-12), may be involved. NG-RAN key: - K gNB It is a key derived from KAMF by ME (Mobile Device) and AMF. This is used when performing horizontal or vertical key derivation. At that time, K gNB It is further derived from ME and source gNB. K gNB K used as a bridge between ME and ng-eNB eNB 。 RRC signaling key: - K RRCint It is from K by ME and gNB gNB The derived key is used only to protect RRCs with a specific integrity algorithm. Signaling. - K RRCenc It is from K by ME and gNB gNB The derived key is used only to protect RRC messages with a specific encryption algorithm. make. Intermediate key: - NH is a key derived from ME and AMF, used to provide forward security as described in Section A.10. - K NG-RAN It is carried out by ME and NG-RAN (i.e., gNB or ng-eNB) using the KDF as specified in Article A.11 / A.12. The key derived when using horizontal or vertical key derivation as specified in Clause 6.9.2.1.1. - KAMF' is used when the UE uses the KDF specified in Annex A.13 during inter-AMF movement as specified in Clause 6.9.3. When an AMF moves to another AMF, the key can be derived from the ME and the AMF.

[0225] Solution Implementation Example 1 may include the following steps.

[0226] Step 0: In this embodiment, it is assumed that during satellite handover, the UE context of the UE in the RRC_INACTIVE state (including the UE with the new key Kgnb) or K NG-RAN The AS security context is pushed to the next service satellite gNB.

[0227] Step 1: The last serving satellite gNB includes the 'gNB Id' of the next serving satellite in SIB19. The UE should store the 'gNB Id' received in SIB19 after each SIB19 acquisition for use in the new key calculation of the UE in the RRC_INACTIVE state. ○ SIB19 may include any other identifier that uniquely identifies the service satellite, such as 'satellite ID' instead of 'gNB ID'. Here, the gNB ID can be one of the global gNB IDs defined in 3GPP TS 38.413 V18.0.0 (2023-12) or the local NG-RAN node IDs defined in Annex F of 3GPP TS 38.300 V18.0.0, or any other identifier for the gNB.

[0228] Step 2: Before satellite handover, based on horizontal or vertical key derivation, the last serving satellite gNB uses the 'gNB Id' of the next serving satellite to calculate the fresh key (i.e., K). NG-RAN That is, using the following parameters: the gNB ID of the next serving satellite, the target ARFCN-DL, and the K in the current UE 5G AS security context. gNB / NH. The last servicing satellite gNB will be the new K. NG-RAN Push to the next service satellite gNB.

[0229] Note: If the local NG-RAN node ID is used to identify adjacent gNBs via the XN interface, the last serving satellite gNB uses the local NG-RAN node it previously received from the "next" serving satellite gNB in ​​the above calculation (in the Xn setup or RAN configuration update message).

[0230] Step 3: When the UE triggers a connection restoration request by sending an RRCresumeRequest to the new satellite gNB (e.g., due to UL data), the new satellite gNB should use the new "K" received in step 2. NG-RAN "To derive new AS keys (RRC integrity key, RRC encryption key, and UP key).

[0231] Step 4: The new satellite gNB should activate the new key in the PDCP layer and respond to the UE with an RRC Resume message on SRB1. This message is protected and encrypted with the new RRC key in the PDCP layer.

[0232] Step 5: When the UE receives the RRCresume message, it uses "K RRCenc "Decrypt the message, the 'K'" RRCenc "The 'gNB Id' stored at the UE is obtained from the latest SIB19 and is based on the newly derived 'K'." NG-RAN "To derive."

[0233] Solution Implementation Example 2 may include the following steps.

[0234] Step 0: In this embodiment, it is assumed that during satellite handover, the UE context (including the AS security context with the new key) of the UE in the RRC_INACTIVE state is pushed to the next serving satellite gNB.

[0235] Step 1: Before satellite handover, based on horizontal or vertical key derivation, the last serving satellite gNB uses the 'gNB Id' of the next serving satellite to calculate the fresh key (i.e., K). NG-RAN This involves using the following parameters: the gNB ID of the next serving satellite, the target ARFCN-DL, and the K in the current UE 5G AS security context. gNB / NH. The last servicing satellite gNB will be the new K. NG-RAN Push to the next service satellite gNB.

[0236] Note: The term “gNB ID” here can be one of the global gNB IDs defined in TS 38.413 V18.0.0 (2023-12) or the local NG-RAN node IDs defined in Annex F of TS 38.300 V18.0.0 (2023-12), or any other identifier for the gNB.

[0237] Note: If the local NG-RAN node ID is used to identify adjacent gNBs via the Xn interface, the last serving satellite gNB uses the local NG-RAN node it previously received from the "next" serving satellite gNB in ​​the above calculation (in the Xn setup or RAN configuration update message).

[0238] Step 2: When the UE triggers a connection restoration request in the new satellite gNB (e.g., due to UL data), the new satellite gNB should respond with RRCReject, including "gNB Id of the (next) serving satellite", and optionally with 'RejectWaitTime'.

[0239] Step 3: The UE should use the "gNB Id of the (next) serving satellite" received in RRCReject in step 2 to derive the new "K". NG-RAN "The key, and then the UE should use that key to derive a new key 'K'." RRCenc ".

[0240] Note: The same comments as above apply to the definition of "gNB ID".

[0241] Step 4: Upon receiving the RRCresumRequest, the new satellite gNB should use the new "K" received in Step 1. NG-RAN "Derive new AS keys (RRC integrity key, RRC encryption key, and UP key).

[0242] Step 5: The new satellite gNB should activate the new key in the PDCP layer and respond to the UE with an RRC Resume message on SRB1. This message is protected and encrypted with the new RRC key in the PDCP layer.

[0243] Step 6: When the UE receives the RRCresume message, it should use the newly derived "K" in step 3. NG-RAN "And the derived new "K" RRCenc The key is used to decrypt the message.

[0244] Considering the scenario switching, Solution 3 may include the following steps.

[0245] Step 1: When the handover decision is made, the last serving satellite gNB should use the 'gNB-Id' of the new satellite gNB or any other identifier that uniquely identifies the serving satellite gNB as the new parameters, along with the target PCI, ARFCN-DL, and the current active K. gNB Or NH, calculate the K of the new satellite gNB triggered by its switching. NG-RAN .

[0246] Note: New parameters have been introduced to distinguish satellites when the PCI does not change with satellite switching.

[0247] Step 2: The new key (K) derived in Step 1 NG-RAN The handover request message (from the last serving gNB to the target gNB) is included in the handover request message.

[0248] Step 3: The new satellite gNB (or target satellite gNB, next serving satellite gNB) should transmit the received K... NG-RAN The key is used directly as the K to be used with the UE. gNB .

[0249] Step 4: When the switch is triggered, during the switch (K) NG-RAN In addition to the existing parameters ('Target PCI', ARFCN-DL), the key derivation should also use the new parameter 'gNB Id' of the new satellite gNB (to which the handover is triggered by the target satellite gNB) or any other identifier that uniquely identifies the serving satellite gNB. ○ The UE can obtain the 'gNB Id' or any other identifier that uniquely identifies the next serving satellite gNB via dedicated RRC signaling or ephemeris data.

[0250] Furthermore, when embodiments of this disclosure are implemented, the following signaling flow may exist.

[0251] Figure 6A This is a diagram illustrating a first portion of a first example call flow according to an embodiment of the present disclosure.

[0252] Figure 6B This is a diagram illustrating a second portion of a first example call flow according to an embodiment of the present disclosure.

[0253] Figure 6C This is a diagram illustrating a third part of a first example call flow according to an embodiment of the present disclosure.

[0254] Figure 6D This is a diagram illustrating the fourth part of a first example call flow according to an embodiment of the present disclosure.

[0255] The key steps in the solution implementation are as follows.

[0256] In step 1, the serving satellite gNB includes the “gNB Id” of the next serving satellite in SIB19. ○ The RRC_INACTIVE state can be used by the UE to derive a new key 'K' NG-RAN ', This key may be needed to decrypt RRCResume messages from the new satellite gNB (next serving satellite gNB) when the connection is restored. Alternatively, any other unique identifier for the satellite can be used, such as the satellite ID.

[0257] In step 2: After obtaining the gNB ID from SIB19, the UE stores the gNB ID;

[0258] In step 3: the UE is in the RRC_CONNECTED or CM-CONNECTED state;

[0259] In step 4: DL data;

[0260] In step 5: an assumed Xn connection between consecutive gNBs in the satellite orbit;

[0261] In step 6, the (final) serving satellite gNB (or source satellite gNB) transmits a message including a fresh I-RNTI and NCC. suspendConfig The message RRCRelease determines whether to suspend the RRC connection;

[0262] In step 7, the source satellite gNB transmits the AS key K RRCint I-RNTI and AS security context are stored in the UE context;

[0263] In steps 8 and 9, the UE receives a signal with... suspendConfig When receiving an RCRelease message, the integrity of the received message is verified by checking the MAC-I field, and the received NCC and current K are also checked. RRCInt The key, I-RNTI, and AS context are stored in the current UE context;

[0264] In step 10: The UE is in RRC_INACTIVE, CM-CONNECTED;

[0265] In step 11, a stationary UE can remain in the same NTN cell, and a mobile UE can reselect a new NTN cell;

[0266] In step 12: Starting from time T, gNB1 serves the cell;

[0267] In step 13, based on horizontal key derivation or vertical key derivation, the serving satellite gNB (gNB1) uses the 'gNB Id' of the next serving satellite as an additional parameter, that is, it uses the following parameters to calculate the fresh key (i.e., K) to be used by the next serving satellite gNB. NG-RAN ): The gNB ID of the next serving satellite, the target ARFCN-DL, and the K in the current UE 5G AS security context. gNB / NH;

[0268] In step 14, it is assumed that during satellite handover, the UE context, including the AS security context, is transferred to the next serving satellite. This AS security context has a new key for all UEs in the RRC_INACTIVE state. As part of the UE context transfer, the KNG-RAN calculated in step 13 is transferred. ;

[0269] In step 15, a satellite switch is triggered, and the new serving satellite should be satellite 2 hosting gNB2;

[0270] In step 16: Data forwarding address indication;

[0271] In step 17: DL data;

[0272] Step 18 is similar to step 13; based on horizontal key derivation or vertical key derivation, using the 'gNB Id' of the next serving satellite, i.e., using the following parameters, calculate the fresh key (i.e., KNG-RAN) to be used by the next serving satellite gNB. ): the gNB Id of the next serving satellite, the target ARFCN-DL, and the KgNB / NH in the current UE 5G AS security context;

[0273] In step 19: Starting from time (T+2T1), gNB3 serves the cell;

[0274] In step 20: Data forwarding address indication;

[0275] In step 21: Data forwarding address indication;

[0276] In step 22: DL data;

[0277] In step 23: DL data (tunnel);

[0278] Step 24 is similar to step 14;

[0279] In step 25: at time (T+2T1), the UE has UL data to send;

[0280] In step 26, the UE initiates an RRCresumeRequest due to UL data;

[0281] In step 27, the UE should use the gNB Id derived K of the new satellite, which was received as an additional parameter in the latest SIB19 acquisition or received in the SIB19 of the current cell. NG-RAN ;

[0282] In step 28, the new service satellite (Satellite 3 / gNB3) should use the new K... NG-RAN Derivation of new AS keys from the key (RRC integrity key, RRC encryption key, and UP key);

[0283] In step 29, the new service satellite gNB3 responds to step 26 by sending RRCResume;

[0284] In step 30, the UE should use the new key derived in step 27 to decrypt the received RRCResume message and verify the PDCP MAC-I;

[0285] In step 31, the UE will use the newly derived K NG-RAN K in RRCInt Stored in the current UE AS security context;

[0286] In step 32: The UE is in RRC_CCONNECTED CM-CONNECTED;

[0287] In step 33: RRCResumeComplete;

[0288] In step 34: Path switching request;

[0289] In step 35: Path switching request response;

[0290] In step 36: DL data;

[0291] In step 37: UE context released;

[0292] Note 1: The term “gNB ID” here may be one of the global gNB ID defined in TS 38.413 or the local NG-RAN node ID defined in Annex F of TS 38.300, or any other identifier of the gNB.

[0293] Note 2: If the local NG-RAN node ID is used to identify the gNBs between adjacent gNBs via the Xn interface, the serving satellite gNB uses the local NG-RAN node it previously received from the "next" serving satellite gNB in ​​the above calculation (in the Xn setup or RAN configuration update message).

[0294] Figure 7A This is a diagram illustrating a first portion of a second example call flow according to an embodiment of the present disclosure.

[0295] Figure 7B This is a diagram illustrating a second portion of a second example call flow according to an embodiment of the present disclosure.

[0296] Figure 7C This is a diagram illustrating a third portion of a second example call flow according to an embodiment of the present disclosure.

[0297] Figure 7D This is a diagram illustrating the fourth part of a second example call flow according to an embodiment of the present disclosure.

[0298] The key steps in the solution implementation are as follows.

[0299] In step 1: the UE is in the RRC_CONNECTED or CM-CONNECTED state;

[0300] In step 2: DL data;

[0301] In step 3: an assumed Xn connection between consecutive gNBs in the satellite orbit;

[0302] In step 4, the (final) serving satellite gNB (or source satellite gNB) transmits a signal including a fresh I-RNTI and NCC. suspendConfig The message RRCRelease is used to decide whether to suspend the RRC connection.

[0303] In step 5, the source satellite gNB transmits the AS key K RRCint I-RNTI and AS security context are stored in the UE context.

[0304] In steps 6 and 7, the UE receives a signal with... suspendConfig When receiving an RRC Release message, the integrity of the received message is verified by checking the MAC-I field, and the received NCC and current K are also checked. RRCInt The key, I-RNTI, and AS context are stored in the current UE context.

[0305] In step 8: The UE is in RRC_INACTIVE, CM-CONNECTED;

[0306] In step 9, a stationary UE can remain in the same NTN cell, and a mobile UE can reselect a new NTN cell;

[0307] In step 10: Starting from time T, gNB1 serves the cell;

[0308] In step 11, based on horizontal key derivation or vertical key derivation, the (last) serving satellite gNB (gNB1) uses the 'gNB Id' of the next serving satellite as an additional parameter, that is, it uses the following parameters to calculate the fresh key (i.e., K) to be used by the next serving satellite gNB. NG-RAN ): The gNB ID of the next serving satellite, the target ARFCN-DL, and the K in the current UE 5G AS security context. gNB / NH.

[0309] In step 12, it is assumed that during satellite handover, the UE context, including the AS security context, is transferred to the next serving satellite, and this AS security context has a new key for all RRC_INACTIVE state UEs.

[0310] In step 13, a satellite switch is triggered, and the new serving satellite should be satellite 2 hosting gNB2.

[0311] In step 14: Data forwarding address indication;

[0312] In step 15: DL data;

[0313] Step 16 is similar to step 11. Based on horizontal or vertical key derivation, using the 'gNB Id' of the next serving satellite, i.e., using the following parameters, calculate the fresh key (i.e., KNG-RAN) to be used by the next serving satellite gNB. ): the gNB Id of the next serving satellite, the target ARFCN-DL, and the KgNB / NH in the current UE 5G AS security context;

[0314] In step 17: Starting from time (T+2T1), gNB3 serves the cell;

[0315] In step 18: Data forwarding address indication;

[0316] In step 19: Data forwarding address indication;

[0317] In step 20: DL data;

[0318] In step 21: DL data (tunnel);

[0319] Step 22 is similar to step 12: During satellite handover, the UE context, including the AS security context, is transferred to the next serving satellite, where the AS security context has a new key for all RRC_INACTIVE state UEs;

[0320] In step 23: at time (T+2T1), the UE has UL data to send;

[0321] In step 24, the UE initiates an RRCresumeRequest due to UL data.

[0322] In step 25, the new service satellite gNB (gNB3 in Figure 3) triggers RRCReject by including "gNB Id of the service satellite" and optional 'RejectWaitTime'. ○ The “gNB ID of the serving satellite” can be included as an octet string in the 'lateNonCriticalExtension' field of RrCReject-IEs, as shown below: -RrCReject-IEs ::= SEQUENCE { - waitTime RejectWaitTimeOPTIONAL, -- Need N - lateNonCriticalExtension OCTET STRINGOPTIONAL, - nonCriticalExtension SEQUENCE{}OPTIONAL -}

[0323] In step 26, the UE should use the "serving satellite gNBId" of the new satellite gNB received in the RRCReject message as an additional parameter to calculate the new K. NG-RAN Key. If the new serving satellite gNB (gNB3) is included in RRCReject, the UE can also wait for "RejectWaitTime" to try RRCResumeRequest again after "RejectWaitTime".

[0324] In step 27, the new service satellite (Satellite 3 / gNB3) should use the new K... NG-RAN The key is used to derive new AS keys (RRC integrity key, RRC encryption key, and UP key).

[0325] In step 28, the new service satellite gNB3 responds to step 26 by sending RRCResume.

[0326] In step 29, the UE should use the new key derived in step 26 to decrypt the received RRCResume message and verify the PDCP MAC-I.

[0327] In step 30, the UE will use the newly derived K NG - RAN K in RRCInt Stored in the current UE AS security context.

[0328] In step 31: The UE is in RRC_CCONNECTED CM-CONNECTED state;

[0329] In step 32: RRRCResumeComplete;

[0330] In step 33: Path switching request;

[0331] In step 34: Path switching request response;

[0332] In step 34: DL data;

[0333] In step 35: UE context released;

[0334] Note 1: The term “gNB ID” here may be one of the global gNB ID defined in TS 38.413 or the local NG-RAN node ID defined in Annex F of TS 38.300, or any other identifier of the gNB.

[0335] Note 2: If the local NG-RAN node ID is used to identify the gNBs between adjacent gNBs via the Xn interface, the serving satellite gNB uses the local NG-RAN node it previously received from the "next" serving satellite gNB in ​​the above calculation (in the Xn setup or RAN configuration update message).

[0336] Figure 8 This is a diagram illustrating a third example call flow according to an embodiment of the present disclosure.

[0337] The key steps in the solution implementation are as follows.

[0338] In step 1: the UE is in the RRC_CONNECTED or CM-CONNECTED state;

[0339] In step 2: DL data;

[0340] In step 3: Starting from time T, gNB1 serves the cell;

[0341] In step 4: an assumed Xn connection between consecutive gNBs in the satellite orbit;

[0342] In step 5, the switching decision is made.

[0343] In step 6, the (final) serving gNB calculates K based on the target PCI, ARFCN-DL, the currently active KgNB or NH, and the 'gNB Id' of the next satellite gNB. NG-RAN . ○ The 'gNB Id' of the next satellite triggered by the UE HO is used as an additional parameter for key calculation because the target PCI can remain unchanged in NTN regenerative NGSO deployments with fixed Earth cells and fixed PCI.

[0344] In step 7, the (last) serving satellite gNB includes the new K in its handover request to the next satellite. NG-RAN Key.

[0345] In step 10, the switch is triggered.

[0346] In step 10.1, the UE can obtain the "gNB Id" of the new satellite gNB after the handover via dedicated RRC signaling or via ephemeris data.

[0347] In step 10.2, the UE should derive K in any of the following ways NG-RAN : ○ (Case 1) If the NCC value received in the HO command is equal to the current active K gNB The associated NCC value is then derived from the current activity K. gNB The key is derived from the target PCI, its frequency ARFCN-DL, and the 'gNB Id' of the new satellite gNB. or ○ (Case 2) If the NCC value received by the UE is different from the current active K gNB The associated NCC derives the key from the synchronization NH parameters and target PCI, its frequency ARFCN-DL, and the 'gNB Id' of the new satellite gNB.

[0348] In step 11, DL data;

[0349] Note: For simplicity, in Figure 8 This is considered a baseline switch; however, this solution also applies to conditional switches specified for NTN.

[0350] According to this implementation of the embodiment, it provides a feasible security solution framework for calculating the new key for the RRC_INACTIVE state and HO when the serving satellite gNB changes due to satellite handover in the PCI-invariant NTN Regenerating Earth Fixed Cell (NGSO) scenario.

[0351] Figure 9 This is a block diagram illustrating an exemplary structure of a first network node according to an exemplary embodiment of the present disclosure.

[0352] like Figure 9 As shown, the first network node 90 includes a component 900 configured to: obtain an identifier of a second network node; and, based at least on the identifier of the second network node, calculate a key to be used for communication between the second network node and a terminal device. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0353] In an exemplary embodiment of this disclosure, component 900 includes: at least one processor 902; and at least one memory 904 storing instructions that, when executed by at least one processor 902, cause execution of a first network node 90.

[0354] In exemplary embodiments of this disclosure, component 900 is also configured to perform methods according to any of the above embodiments, such as Figure 3A , Figure 3B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0355] Figure 10 This is a block diagram illustrating an exemplary structure of a second network node according to an exemplary embodiment of the present disclosure.

[0356] like Figure 10 As shown, the second network node 100 includes a component 1000 configured to communicate with a terminal device using a key. The key is calculated based at least on an identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0357] In an exemplary embodiment of this disclosure, component 1000 includes: at least one processor 1002; and at least one memory 1004 storing instructions that, when executed by at least one processor 1002, cause execution of a third network node 100.

[0358] In exemplary embodiments of this disclosure, component 800 is also configured to perform methods according to any of the above embodiments, such as Figure 4A , Figure 4B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0359] Figure 11 This is a block diagram illustrating an exemplary structure of a terminal device according to an exemplary embodiment of the present disclosure.

[0360] like Figure 11 As shown, terminal device 110 includes component 1100 configured to: communicate with a second network node using a key. The key is calculated based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0361] In an exemplary embodiment of this disclosure, component 1100 includes: at least one processor 1102; and at least one memory 1104 storing instructions that, when executed by at least one processor 1102, cause execution of a fourth node 110.

[0362] In exemplary embodiments of this disclosure, component 1100 is also configured to perform methods according to any of the above embodiments, such as Figure 5A , Figure 5B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0363] Processors 902, 1002, and 1102 can be any type of processing component, such as one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), application-specific digital logic, etc. Memory 904, 1004, and 1104 can be any type of storage component, such as read-only memory (ROM), random access memory, cache memory, flash memory, optical storage, etc.

[0364] Figure 12 This is a block diagram illustrating an apparatus / computer-readable storage medium according to embodiments of the present disclosure.

[0365] like Figure 12 As shown, the computer-readable storage medium 120 stores instructions 121, which, when executed by at least one processor of a network node (such as a first network node, a second network node, or a third network node) or a terminal device, cause at least one processor of the network node or the terminal device to perform a method according to any of the above embodiments, such as... Figure 3A , Figure 3B , Figure 4A , Figure 4B , Figure 5A , Figure 5B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0366] Furthermore, this disclosure may also provide a carrier including the aforementioned computer program / instructions. The carrier is an electronic signal, an optical signal, a wireless signal, or one of the aforementioned computer-readable storage media. The computer-readable storage medium may be, for example, an optical disc or an electronic storage device, such as RAM (Random Access Memory), ROM (Read-Only Memory), flash memory, magnetic tape, CD-ROM, DVD, Blu-ray disc, etc.

[0367] Figure 13 This is a block diagram illustrating an exemplary device unit of a first network node suitable for performing a method according to an embodiment of the present disclosure.

[0368] like Figure 13 As shown, the first network node 130 may include: an acquisition unit 1302, which acquires an identifier of the second network node; and a calculation unit 1304, which calculates a key to be used for communication between the second network node and the terminal device, based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0369] In an exemplary embodiment of this disclosure, the first network node 170 is also configured to perform a method according to any of the above embodiments, such as Figure 3A , Figure 3B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0370] Figure 14 This is a block diagram illustrating an exemplary device unit suitable for performing the methods according to embodiments of the present disclosure for a second network node.

[0371] like Figure 14 As shown, the second network node 140 may include a communication unit 1402 that communicates with the terminal device using a key. The key is calculated based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0372] In an exemplary embodiment of this disclosure, the second network node 140 is further configured to perform a method according to any of the above embodiments, such as Figure 4A , Figure 4B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0373] Figure 15 This is a block diagram illustrating exemplary device units of a terminal device suitable for performing methods according to embodiments of the present disclosure.

[0374] like Figure 15 As shown, terminal device 150 may include a communication unit 1502 that communicates with a second network node using a key. The key is calculated based at least on the identifier of the second network node. The identifier of the second network node distinguishes the second network node from at least the first network node.

[0375] In exemplary embodiments of this disclosure, the third network node 130 is also configured to perform methods according to any of the above embodiments, such as Figure 5A , Figure 5B , Figure 6A , Figure 6B , Figure 6C , Figure 6D , Figure 7A , Figure 7B , Figure 7C , Figure 7D , Figure 8 As shown.

[0376] The term 'unit' can have a conventional meaning in the field of electronic, electrical and / or electronic equipment, and may include, for example, electrical and / or electrical circuit systems, devices, modules, processors, memories, logic solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, programs, calculations, outputs and / or displays, as described herein.

[0377] The term "circuit system" as used in this disclosure may refer to one or more or all of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuit systems only) and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and (ii) Any part of a hardware processor (including (multiple) digital signal processors), software, and (multiple) memories that work together to enable a device such as a mobile phone or server to perform various functions, and (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or portions thereof, which require software (e.g., firmware) to function, but may be absent when not needed.

[0378] This definition of circuit system applies to all uses of the term in this disclosure, including in any claim. As another example, as used in this disclosure, the term circuit system also covers only hardware circuitry or a processor (or processors) or a portion thereof and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuit system also includes baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or networking devices.

[0379] Using these units, the device can function without a fixed processor or memory, and any type of computing and storage resources can be deployed from at least one node / device / entity / assembly associated with the communication system. Virtualization and network computing technologies (e.g., cloud computing) can be further introduced to improve the efficiency of network resource utilization and network flexibility.

[0380] The techniques described herein can be implemented through various components, such that the means for implementing one or more functions of the corresponding apparatus described by way of embodiment includes not only prior art components but also components for implementing one or more functions of the corresponding apparatus described by way of embodiment, and it may include separate components for each individual function, or components that can be configured to perform two or more functions. For example, these techniques can be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules / units), or a combination thereof. For firmware or software, implementation can be carried out by modules (e.g., processes, functions, etc.) that perform the functions described herein.

[0381] In some embodiments, some or all of the functionality described herein may be provided by a processing circuitry system that executes instructions stored in memory, which in some implementations may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry system without executing instructions stored on separate or discrete device-readable storage media, such as in a hard-wired manner. In any of these particular embodiments, the processing circuitry system may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to a single processing circuitry system or other components of the computing device, but are shared by the entire computing device and / or the end user and wireless network.

[0382] The term “non-transient” as used in this article refers to a limitation on the medium itself (i.e., tangible, not signaling), rather than a limitation on the persistence of data storage (e.g., RAM vs. ROM).

[0383] As described in the exemplary embodiments of this disclosure above, the embodiments herein offer numerous advantages. According to embodiments of this disclosure, exemplary embodiments propose a mechanism that provides a feasible security solution framework for new key calculation during the handover of serving network nodes. Security risks due to duplicate keys can be avoided. In particular, it provides a feasible security solution framework for new key calculation for the RRC_INACTIVE state and HO, when the serving satellite gNB changes due to satellite handover in a PCI-invariant NTN regenerable earth fixed cell NGSO scenario.

[0384] It should be understood that the above embodiments are for illustrative purposes only and not for limitation. This disclosure may be carried out in ways other than those specifically set forth herein without departing from its essential characteristics. All changes to these embodiments are intended to be included herein without departing from the meaning and equivalence of the appended claims.

[0385] References

[0386] The following is a complete list of references incorporated into this paper: 3GPP TR 38.821 V16.2.0 (2023-03) 3GPP TS 33.501 V18.4.0 (2023-12) 3GPP TS 38.413 V18.0.0 (2023-12) 3GPP TS 38.300 V18.0.0 (2023-12)

[0387] Abbreviation Explanation AS: Access Layer AMF: Access Management Function ARFCN: Absolute Radio Frequency Channel Number C-RNTI: Temporary Identifier for Cellular Radio Network EFC: Earth Fixed Cell PCI: Physical Cell Identifier LEO: Low Earth Orbit MAC: Media Access Control NGSO: Non-Geostationary Orbit NTN: Non-terrestrial network PDCP: Packet Data Convergence Protocol SRB: Signaling Radio Bearer UE: User Equipment NR: New Wireless DU: Distributed Unit I-RNTI: Temporary Identifier for Inactive Wireless Networks NCC: Next-Break Chain Counter MAC-I: Message Integrity Authentication Code Xn-AP: Xn Application Protocol EARFCN: Evolved Universal Terrestrial Radio Access Absolute Radio Channel Number FLSO: Hard Feeder Link Switching AMF: Access and Mobility Management Functions DL: Downlink CP: Control Plane UP: User plane SMF: Session Management Function UPF: User Plane Functionality NTN: Non-terrestrial network LEO: Low Earth Orbit NG: Next Generation TNL: Transport Network Layer AN: Access Network TEID: Tunnel Endpoint Identifier F-TEID: Fully Qualified Tunnel Endpoint Identifier

Claims

1. A method (300) performed by a first network node in a communication network, comprising: Obtain (S302) the identifier of the second network node; as well as Based at least on the identifier of the second network node, calculate (S304) the key that will be used for communication between the second network node and the terminal device; The identifier of the second network node distinguishes the second network node from at least the first network node.

2. The method (300) according to claim 1, further comprising: The key is stored (S306) in the context for the terminal device; Send the key (S308) to the second network node; as well as The identifier of the second network node is sent to the terminal device via a system information block or via Radio Resource Control (RRC) signaling to the terminal device (S310).

3. The method (300) according to claim 1 or 2. During an RRC recovery process initiated by the terminal device, or during a handover of the terminal device from the first network node to the second network node, the key will be used for the communication between the second network node and the terminal device.

4. The method (300) according to any one of claims 1 to 3, wherein the identifier of the second network node includes: The global identifier of the second network node; Local Next Generation Radio Access Network (NG-RAN) node identifier; or The identifier of the vehicle or platform carrying the second network node.

5. The method (300) according to any one of claims 1 to 4, wherein the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

6. The method (300) according to any one of claims 1 to 5. The key includes an intermediate key K. NG-RAN ;and The key is further calculated based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

7. The method (300) according to claim 6. The key is calculated using vertical key derivation and horizontal key derivation.

8. The method (300) according to claim 6 or 7. The key is used to further derive the Radio Resource Control (RRC) integrity key and the RRC encryption key.

9. The method (300) according to any one of claims 1 to 8. When serving the terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

10. The method (300) according to any one of claims 1 to 9. The first network node is the first non-terrestrial network (NTN) network node in the non-terrestrial network; and The second network node is the second NTN network node in the non-terrestrial network.

11. A method (400) performed by a second network node in a communication network, comprising: Communicating with the terminal device using a key (S402); The key is calculated based at least on the identifier of the second network node; and The identifier of the second network node distinguishes the second network node from at least the first network node.

12. The method (400) according to claim 11, further comprising: The identifier of the second network node is sent to the terminal device via a system information block or via Radio Resource Control (RRC) signaling to the terminal device (S404).

13. The method (400) according to claim 11 or 12. The key is either calculated by the second network node or received from the first network node. During an RRC recovery process initiated by the terminal device, or during a handover of the terminal device from the first network node to the second network node, the key is used for the communication between the second network node and the terminal device.

14. The method (400) of claim 13, wherein the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

15. The method (400) according to claim 14. When serving the terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

16. The method (400) according to any one of claims 13 to 15. The first network node is the first non-terrestrial network (NTN) network node in the non-terrestrial network; and The second network node is the second NTN network node in the non-terrestrial network.

17. The method (400) according to any one of claims 11 to 16, wherein the identifier of the second network node comprises: The global identifier of the second network node; Local Next Generation Radio Access Network (NG-RAN) node identifier; or The identifier of the vehicle or platform carrying the second network node.

18. The method (400) according to any one of claims 11 to 17. The key includes an intermediate key K. NG-RAN ;and The key is further calculated based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

19. The method (400) according to claim 18. The key is calculated using vertical key derivation and horizontal key derivation.

20. The method (400) according to claim 18 or 19. The key is used to further derive the Radio Resource Control (RRC) integrity key and the RRC encryption key.

21. A method (500) performed by a terminal device in a communication network, comprising: Use the key to communicate with the second network node (S502). The key is calculated based at least on the identifier of the second network node; and The identifier of the second network node distinguishes the second network node from at least the first network node.

22. The method (500) according to claim 21, further comprising: The identifier of the second network node is received from the second network node or the first network node via a system information block or via Radio Resource Control (RRC) signaling to the terminal device (S504); or The identifier of the second network node is obtained from the ephemeris data (S506).

23. The method (500) of claim 22, wherein the first network node obtains the identifier of the second network node from the second network node or from ephemeris data.

24. The method (500) according to claim 23. During an RRC recovery process initiated by the terminal device, or during a handover of the terminal device from the first network node to the second network node, the key is used for the communication between the second network node and the terminal device.

25. The method (500) according to claim 24. When serving the terminal device, the first network node and the second network node are configured with the same Physical Cell Identifier (PCI).

26. The method (500) according to any one of claims 22 to 25. The first network node is the first non-terrestrial network (NTN) network node in the non-terrestrial network; and The second network node is the second NTN network node in the non-terrestrial network.

27. The method (500) according to any one of claims 21 to 26, wherein the identifier of the second network node comprises: The global identifier of the second network node; Local Next Generation Radio Access Network (NG-RAN) node identifier; or The identifier of the vehicle or platform carrying the second network node.

28. The method (500) according to any one of claims 21 to 27. The key includes an intermediate key K. NG-RAN ;and The key is further calculated by the terminal device based on the following: the physical cell identifier of the second network node, the frequency of the synchronization signal block of the primary cell of the second network node, and K. gNB Key or next-hop NH count.

29. The method (500) according to claim 28. The key is calculated using vertical key derivation and horizontal key derivation.

30. The method (500) according to claim 28 or 29. The key is used to further derive the Radio Resource Control (RRC) integrity key and the RRC encryption key.

31. A first network node (90) comprising components (900) configured for: Obtain the identifier of the second network node; and Based at least on the identifier of the second network node, calculate the key that will be used for communication between the second network node and the terminal device; The identifier of the second network node distinguishes the second network node from at least the first network node; The component (900) mentioned above includes: At least one processor (902); as well as At least one memory (904) stores instructions that, when executed by the at least one processor (902), cause the execution of the first network node (90).

32. The first network node (90) according to claim 31, wherein the component (900) is further configured to perform the method according to any one of claims 2 to 10.

33. A second network node (100) comprising components (1000) configured for: Use a key to communicate with the terminal device; The key is calculated based at least on the identifier of the second network node; and The identifier of the second network node distinguishes the second network node from at least the first network node; The component (1000) mentioned above includes: At least one processor (1002); as well as At least one memory (1004) stores instructions that, when executed by the at least one processor (1002), cause the execution of the second network node (100).

34. The second network node (100) according to claim 33, wherein the component (1000) is further configured to perform the method according to any one of claims 12 to 20.

35. A terminal device (110) comprising a component (1100) configured for: Use the key to communicate with the second network node; The key is calculated based at least on the identifier of the second network node; and The identifier of the second network node distinguishes the second network node from at least the first network node; The components mentioned above include: At least one processor (1102); as well as At least one memory (1104) stores instructions that, when executed by the at least one processor (1102), cause the terminal device (110) to execute.

36. The terminal device (110) according to claim 35, wherein the component (1100) is further configured to perform the method according to any one of claims 22 to 30.

37. A computer-readable storage medium (120) storing instructions (121) that, when executed by at least one processor of the apparatus, cause the at least one processor of the apparatus to perform the method according to any one of claims 1 to 30.

Images