Method and apparatus for generating key during switch of serving network node

Abstract

Embodiments of the present disclosure provide a method and an apparatus for generating key during switch of serving network node. A method (300) performed by a first network node in a communication network comprises: obtaining (S302) an identifier of a second network node; computing (S304) a key to be used for a 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 differentiates the second network node from at least the first network node. According to embodiments of the present disclosure, the exemplary embodiments of the present disclosure propose a mechanism that provides a workable security solution framework for new key computation during switch of serving network nodes. The security risk due to repeated keys may be avoid.

Description

METHOD AND APPARATUS FOR GENERATING KEY DURING SWITCH OF SERVING NETWORK NODETECHNICAL FIELD

[0001] Various example embodiments of the present disclosure relate generally to the technology of communication, and in particular to a method and apparatus for generating key during switch of serving network node.BACKGROUND

[0002] In current communication system, such as the 3rd generation partnership project (3GPP) 5th generation (5G) , new radio (NR) , etc., a serving network node for a terminal device may changes in many situations, such as due to the mobility of the terminal device, or the network node.

[0003] For example, when moving network node (such as satellites or other moving stations or moving gateways) are serving the terminal device, a last serving satellite may move away from the terminal device, and a next serving satellite may move to the terminal device. The terminal device may be disconnected from the last serving satellite and then connected to the next serving satellite. Due to security principles, some keys for encryption / decryption of communications between terminal device and the next serving satellite should be recomputed / regenerated.

[0004] However, the last serving satellite and the next serving satellite may share some configuration / parameters. When the key is computed / generated based on such shared parameters, certain key for the last serving network node and certain key for the next serving network node may be the same. Then, there might be security risks.SUMMARY

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

[0006] Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. Specific method and apparatus for generating key during switch of serving network node may be provided.

[0007] A first aspect of the present disclosure provides a method performed by a first network node in a communication network. The method comprises: obtaining an identifier of a second network node; computing a key to be used for a 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 differentiates the second network node from at least a first network node.

[0008] In exemplary embodiments of the present disclosure, the method further comprises: storing the key in a context for the terminal device; transmitting the key to the second network node; and  transmitting the identifier of the second network node to the terminal device, via a system information block, or via a radio resource control, RRC, signalling to the terminal device.

[0009] In exemplary embodiments of the present disclosure, the key is to be used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.

[0010] In exemplary embodiments of the present disclosure, the identifier of the second network node comprises: a global identifier of the second network node; a local next generation-radio access network, NG-RAN, node identifier; or an identifier of a vehicle or platform embarking the second network node.

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

[0012] In exemplary embodiments of the present disclosure, the key comprises an intermediate key KNG-RAN*; and the key is computed further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop (NH) count.

[0013] In exemplary embodiments of the present disclosure, the key is computed using a vertical key derivation and a horizontal key derivation.

[0014] In exemplary embodiments of the present disclosure, the key is used to further derivate a radio resource control, RRC, integrity key, and a RRC encryption key.

[0015] In exemplary embodiments of the present disclosure, the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.

[0016] In exemplary embodiments of the present 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 the non-terrestrial network.

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

[0018] In exemplary embodiments of the present disclosure, the method further comprises: transmitting the identifier of the second network node to the terminal device, via a system information block, or via a radio resource control, RRC, signalling to the terminal device.

[0019] In exemplary embodiments of the present disclosure, the key is computed by the second network node, or is received from the first network node; the key is used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.

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

[0021] In exemplary embodiments of the present disclosure, the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.

[0022] In exemplary embodiments of the present 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 the non-terrestrial network.

[0023] In exemplary embodiments of the present disclosure, the identifier of the second network node comprises: a global identifier of the second network node; a local next generation-radio access network, NG-RAN, node identifier; or an identifier of a vehicle or platform embarking the second network node.

[0024] In exemplary embodiments of the present disclosure, the key comprises an intermediate key KNG-RAN*; and the key is computed further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.

[0025] In exemplary embodiments of the present disclosure, the key is computed using a vertical key derivation and a horizontal key derivation.

[0026] In exemplary embodiments of the present disclosure, the key is used to further derivate a radio resource control, RRC, integrity key, and a RRC encryption key.

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

[0028] In exemplary embodiments of the present disclosure, the method further comprises: receiving the identifier of the second network node from the second network node or the first network node, via a system information block, or via a radio resource control, RRC, signalling to the terminal device; or obtaining the identifier of the second network node from an ephemeris data.

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

[0030] In exemplary embodiments of the present disclosure, the key is used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.

[0031] In exemplary embodiments of the present disclosure, the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.

[0032] In exemplary embodiments of the present 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 the non-terrestrial network.

[0033] In exemplary embodiments of the present disclosure, the identifier of the second network node comprises: a global identifier of the second network node; a local next generation-radio access network, NG-RAN, node identifier; or an identifier of a vehicle or platform embarking the second network node.

[0034] In exemplary embodiments of the present disclosure, the key comprises an intermediate key KNG-RAN*; and the key is computed by the terminal device further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.

[0035] In exemplary embodiments of the present disclosure, the key is computed using a vertical key derivation and a horizontal key derivation.

[0036] In exemplary embodiments of the present disclosure, the key is used to further derivate a radio resource control, RRC, integrity key, and a RRC encryption key.

[0037] A fourth aspect of the present disclosure provides a first network node. The first network node comprises means configured for: obtaining an identifier of a second network node; and computing a key to be used for a 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 differentiates the second network node from at least the first network node. The means comprise: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the first network node.

[0038] In exemplary embodiments of the present disclosure, the means are further configured for performing the method according to any exemplary embodiment of the first aspect.

[0039] A fifth aspect of the present disclosure provides a second network node. The second network node comprises means configured for: communicating with a terminal device, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node. The means comprise: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the second network node.

[0040] In exemplary embodiments of the present disclosure, the means are further configured for performing the method according to any exemplary embodiment of the second aspect.

[0041] A sixth aspect of the present disclosure provides a terminal device. The terminal device comprises means configured for: communicating with a second network node, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node. The means comprise: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the third network node.

[0042] In exemplary embodiments of the present disclosure, the means are further configured for performing the method according to any exemplary embodiment of the third aspect.

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

[0044] According to embodiments of the present disclosure, the exemplary embodiments of the present disclosure propose a mechanism that provides a workable security solution framework for new key computation during switch of serving network nodes. The security risk due to repeated keys may be avoid.BRIEF DESCRIPTION OF DRAWINGS

[0045] The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which like reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:

[0046] FIG. 1A is a first part of an exemplary diagram for connection resume scenario in case of Regenerative NTN NGSO satellite deployment.

[0047] FIG. 1B is a second part of an exemplary diagram for connection resume scenario in case of Regenerative NTN NGSO satellite deployment.

[0048] FIG. 1C is a third part of an exemplary diagram for connection resume scenario in case of Regenerative NTN NGSO satellite deployment.

[0049] FIG. 2 is an exemplary diagram showing a simple HO scenario considering Regenerative NTN NGSO satellite deployment.

[0050] FIG. 3A is a flow chart showing a method performed by a first network node, according to exemplary embodiments of the present disclosure.

[0051] FIG. 3B is a flow chart showing further steps of the method as shown in FIG. 3A, according to exemplary embodiments of the present disclosure.

[0052] FIG. 4A is a flow chart showing a method performed by a second network node, according to exemplary embodiments of the present disclosure.

[0053] FIG. 4B is a flow chart showing further steps of the method as shown in FIG. 4A, according to exemplary embodiments of the present disclosure.

[0054] FIG. 5A is a flow chart showing a method performed by a terminal device, according to exemplary embodiments of the present disclosure.

[0055] FIG. 5B is a flow chart showing further steps of the method as shown in FIG. 5A, according to exemplary embodiments of the present disclosure.

[0056] FIG. 6A is a diagram showing a first part of a first example call flow, according to embodiments of the present disclosure.

[0057] FIG. 6B is a diagram showing a second part of a first example call flow, according to embodiments of the present disclosure.

[0058] FIG. 6C is a diagram showing a third part of a first example call flow, according to  embodiments of the present disclosure.

[0059] FIG. 6D is a diagram showing a fourth part of a first example call flow, according to embodiments of the present disclosure.

[0060] FIG. 7A is a diagram showing a first part of a second example call flow, according to embodiments of the present disclosure.

[0061] FIG. 7B is a diagram showing a second part of a second example call flow, according to embodiments of the present disclosure.

[0062] FIG. 7C is a diagram showing a third part of a second example call flow, according to embodiments of the present disclosure.

[0063] FIG. 7D is a diagram showing a fourth part of a second example call flow, according to embodiments of the present disclosure.

[0064] FIG. 8 is a diagram showing a third example call flow, according to embodiments of the present disclosure.

[0065] FIG. 9 is a block diagram showing an exemplary structure for a first network node, according to exemplary embodiments of the present disclosure.

[0066] FIG. 10 is a block diagram showing an exemplary structure for a second network node, according to exemplary embodiments of the present disclosure.

[0067] FIG. 11 is a block diagram showing an exemplary structure for a terminal device, according to exemplary embodiments of the present disclosure.

[0068] FIG. 12 is a block diagram showing an apparatus / computer readable storage medium, according to embodiments of the present disclosure.

[0069] FIG. 13 is a block diagram showing exemplary apparatus units for a first network node, which is suitable for performing the method according to embodiments of the disclosure.

[0070] FIG. 14 is a block diagram showing exemplary apparatus units for a second network node, which is suitable for performing the method according to embodiments of the disclosure.

[0071] FIG. 15 is a block diagram showing exemplary apparatus units for a terminal device, which is suitable for performing the method according to embodiments of the disclosure.DETAILED DESCRIPTION

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

[0073] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless clearly given and / or implied from the context. Any feature of any of the embodiments 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 following any suitable communication standards (such for an internet network, or any wireless network) . For example, wireless communication standards may comprise 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” can be used interchangeably.

[0075] The term “node / network node” refers to a computing device or computing entity or computing function or any other devices (physical or virtual) in a communication network. For example, the node in the network may include a base station (BS) , an access point (AP) , or any other suitable device in a wireless communication network. The BS may be, for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNodeB or gNB) , a remote radio unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth. Further, the node may include other core network node, such as an Access and Mobility Management Function, AMF, a Session Management Function, SMF, a User Plane Function, UPF, a mobility management entity, MME, or a serving gateway, S-GW, etc.

[0076] The term “terminal device” refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE) , a non-AP device (such as a non-AP Station (STA) ) , or other suitable devices. The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, a wearable device, a vehicle-mounted wireless terminal device, a vehicle, and the like.

[0077] As one example, a terminal device may represent a device configured for communication in accordance with one or more communication standards promulgated by any standard organization, such as 3rd generation partnership project, 3GPP.

[0078] As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another terminal device and / or network equipment. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0079] It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. 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: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the  elements, or at least all the elements.

[0081] The present disclosure proposes enhancements for security key derivation. As an example for illustration without limitation, Non-Terrestrial Network (NTN) Regenerative Non-geostationary (NGSO) scenarios with full gNB on satellite considering unchanged Physical Cell Identifier (PCI) may be illustrated. However, it should be noted that, any other scenarios with need for recomputing keys may be also applicable.

[0082] 3GPP TR 38.821 V16.2.0 (2023-03) for new radio (NR) NTN study has considered the following two architecture options:

[0083] - Transparent architecture: Where the satellite payload performs frequency conversion, amplification and filtering, with the gNB located on the ground.

[0084] - Regenerative architecture: Where part or full gNB shall be onboard the satellite.

[0085] 3rd generation partnership project (3GPP) Release (Rel) -17 and Rel-18 introduced the support of NTN for transparent architecture.

[0086] NTN Enhancements in Rel-19 are expected to introduce the support for regenerative payload with full gNB on satellite or with gNB-Distributed Unit (DU) on satellite for NR NTN. The expected enhancements under NTN mobility and service continuity include ‘Enhanced support in RRC (Radio Resource Control) INACTIVE’ , ‘Enhancements to NTN mobility with Regenerative NGSO’ .

[0087] In Radio Access Network (RAN) #101 plenary discussions, the support for RRC_INACTIVE state for regenerative NGSO satellite deployments and Enhancements to NTN mobility and service continuity for regenerative NGSO satellite deployments were identified among others as key priorities to be considered in the scope of Rel-19 and beyond.

[0088] In 5th generation (5G) NR, the RRC_INACTIVE state allows NG RAN node to suspend the UE’s RRC connection while the NG RAN and the UE continue to maintain the UE 5G AS security context. The user equipment (UE) RRC connection can be resumed at a later time by allowing the UE to transition to RRC_CONNECTED state.

[0089] The UE may transition from RRC_INACTIVE state to RRC_CONNECTED state to the same last serving NG RAN node which sent the UE into RRC_INACTIVE state or to a different NG RAN node.

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

[0091] When the NG RAN node decides to suspend the UE’s RRC connection, it shall send to the UE an RRCRelease with suspendConfig message that is ciphered, and integrity protected in PDCP layer using a current AS security context.

[0092] NG RAN node shall include a fresh Inactive Radio Network Temporary Identifier (I-RNTI) , and a Next Hop Chaining Counter (NCC) in RRCRelease with suspendConfig message.

[0093] I-RNTI is used to identify both the UE and the gNB which hosts the UE context.

[0094] NCC (Next Hop Chaining Counter) is AS cryptographic key used for next hop access key derivation.

[0095] After sending RRCRelease with suspendConfig message to the UE, the NG RAN node:

[0096] - shall keep the current Access Stratum (AS) key KRRCint and delete other AS keys.

[0097] - shall store the sent I-RNTI together with the current UE context including the remainder of the AS security context.

[0098] Upon receiving the RRC Release with suspendConfig message from the NG RAN node, the UE shall verify that the integrity of the received message is correct by verifying the computed message authentication code for integrity (MAC-I) and received MAC-I fields.

[0099] On successful verification, UE shall store the following:

[0100] - Received NCC value with the current UE context.

[0101] - Current AS key KRRCint key while deleting all other AS keys.

[0102] - Received I-RNTI with the current UE context and the remainder of AS context.

[0103] When the UE decides to resume the RRC connection to transit from RRC_INACTIVE to RRC_CONNECTED, it sends RRCResumeRequest message by including I-RNTI and a ResumeMAC-I. I-RNTI is used for context identification and ResumeMAC-I is an authentication token of 16 bits length which is calculated using integrity algorithm in the stored AS security context at UE.

[0104] After sending RRCResumeRequest message, the UE shall derive a KNG-RAN*using the target PCI, target ARFCN-DL and the KgNB / NH based on either a horizontal key derivation or a vertical key derivation as defined in clause 6.9.2.1.1 and Annex A. 11 / Annex A. 12 of 3GPP TS 33.501 V18.4.0 (2023-12) .

[0105] 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 contacts the source NG RAN node (i.e., the last serving network node) based on the information in the I-RNTI by sending an Xn Application Protocol (Xn-AP) Retrieve UE Context Request message with the following included: I-RNTI, the ResumeMAC-I and target Cell-ID, in order to allow the source NG RAN node to validate the request and to retrieve the UE context including the UE 5G AS security context.

[0106] The source NG RAN node retrieves the stored UE context including the UE 5G AS security context from its database using the I-RNTI.

[0107] The source NG RAN node verifies the ResumeMAC-I using the current KRRCint key stored in the retrieved UE 5G AS security context. Upon successful verification of the ResumeMAC-I, the source NG RAN node calculates KNG-RAN*using the target cell PCI, target Absolute Radio Frequency Channel Number (ARFCN) -Downlink (DL) and the KgNB / next hop (NH) count in the current UE 5G AS security context based on either a horizontal key derivation or a vertical key derivation.

[0108] The source NG RAN node can obtain the target PCI and target ARFCN-DL from a cell configuration database by means of the target Cell-ID which was received from the target NG RAN node.

[0109] Following the above, the source NG RAN node shall respond with an Xn-AP Retrieve UE Context Response message to the target NG RAN node by including the UE context that contains the  UE 5G AS security context, which include the newly derived KNG-RAN*, the NCC associated to the KNG-RAN*, the UE 5G security capabilities, user plane (UP) security policy, the UP security activation status with the corresponding protocol data unit (PDU) session ID (s) , and the ciphering and integrity algorithms used by the UE at the source cell.

[0110] Assuming the target NG RAN node supports the ciphering and integrity algorithms used at the last source cell (otherwise the target NG RAN node shall trigger RRC connection establishment as if the UE was in IDLE) , the target NG RAN node shall derive new AS keys (RRC integrity key, RRC encryption key and UP keys) using the algorithms the UE used with the source cell and the received KNG-RAN*. The target NG RAN node shall reset all Packet Data Convergence Protocol (PDCP) COUNTs to 0 and activate the new keys in PDCP layer. The target NG RAN node shall respond to the UE with an RRC Resume message on Signaling Radio Bearer (SRB) 1 which is integrity protected and ciphered in PDCP layer using the new RRC keys.

[0111] When the UE receives the RRCResume message, the UE shall decrypt the message using the KRRCenc that was derived based on the newly derived KNG-RAN*. The UE shall also verify the “RRC Connection Resume” message by verifying the PDCP MAC-I using the KRRCint that was derived from the newly derived KNG-RAN*. If verification of the RRCResume message is successful, the UE shall delete the current KRRCint key, and the UE shall save the KRRCint from the newly derived KNG-RAN*as part of the UE current AS security context. Following this, the UE shall send the RRCResumeComplete message both integrity protected and ciphered to the target gNB / ng-eNB on SRB1 using the current KRRCint (for integrity) and KRRCenc (for encryption) .

[0112] After a successful transition from RRC_INACTIVE to RRC_CONNECTED the target NG RAN node shall perform Path Switch Request procedure with the Access and Mobility Management Function (AMF) . The AMF shall verify the UE security capability and the Session Management Function (SMF) shall verify the UE security policy.

[0113] In NTN Regenerative NGSO satellite deployment scenarios, example regenerative Low Earth Orbit (LEO) deployment with full gNB on satellite, a LEO beam footprint may range between 50 to 1000kms (with 20 to 40kms beam diameter) and the LEO satellite constantly orbits the earth with a relative speed of 7.56Km / sec. Which means, the serving satellite (serving gNB) changes at every fixed time interval even for a stationary UE on earth.

[0114] For connected mode Ues, this shall be handled by triggering handover.

[0115] But for RRC_INACTIVE state Ues, when connection needs to be resumed (e.g. due to UL or DL data) , the UE may be served by a different (new) satellite (therefore gNB) , (as constellation of NGSO satellites continuously orbits the earth) and the last serving satellite (therefore gNB) that holds the UE context might be multiple hops away.

[0116] UE context fetch that is multiple hops away in NTN Regenerative NGSO satellite deployment scenarios is not defined within existing specifications. It may be applicable in later version of specifications. The inventors of this disclosure have also made some proposals. However, in this invention, it is focused on the enhancements to the security key computation, and the specific manner for multiple hops transmission is not limited.

[0117] As per the fundamental security principle involved in RRC state transitions (and in Handover) , the UE is aware of changing cell and gNB and the UE know how to compute the keys for each cell change or gNB change.

[0118] In case of handover, the source gNB computes a fresh key (Kgnb *or K NG-RAN*) for each target gNB and the new key is sent over Xn interface. And the parameters used for key computation are target PCI, target ARFCN-DL and the KgNB / NH based on either a horizontal key derivation or a vertical key derivation.

[0119] For RRC_INACTIVE state, the source gNB computes a fresh key (Kgnb *or K NG-RAN*) for each potential target gNB using target cell PCI, target ARFCN-DL / EARFCN (Evolved Universal Terrestrial Radio Access Absolute Radio Frequency Channel Number) -DL and the KgNB / NH, and is sent to the target gNB over Xn interface.

[0120] NTN may be deployed either to have:

[0121] Earth Fixed Cells (EFCs) –wherein the satellite beam is steered on to a geographical NTN cell on earth from minimum elevation angle on one side of the horizon to the minimum elevation angle on the other side of the horizon.

[0122] Or

[0123] Earth Moving Cells (EMCs) –wherein the satellite beam shall be fixed and not steerable and moves as the satellite moves.

[0124] Considering NTN deployments with Earth Fixed Cells (EFCs) as it is less complex deployment, it may be realized via one of the following options:

[0125] Option 1: Satellite switch results into PCI change. The likely realization of this is to associate each NTN cell with a pair of PCIs, that change alternatively with satellite switch.

[0126] Option 2: PCI is unchanged due to satellite switch.

[0127] In Rel-18, RAN2 agreed to support ‘Satellite switching without PCI change’ for the case of Quasi Earth fixed cell involving hard satellite switch with same gNB.

[0128] Option 2 is very likely to be expanded to regenerative NGSO scenarios in Rel-19 for scenarios involving satellite switch involving gNB change.

[0129] If considering to realize Option 2, there is a scenario wherein, the PCI of NTN cell shall be fixed for stationary Ues and for the Ues that do not undergo cell change, even though the serving satellite (and thus the serving gNB) changes after every fixed period of time.

[0130] From security perspective, this means that the current set of parameters used in RRC_INACTIVE state:

[0131] - For key computation at source gNB: target cell PCI, target ARFCN-DL / EARFCN-DL and the KgNB / NH

[0132] - For authentication token at the UE (at the time of connection resume) : source PCI, target Cell-ID, source C-RNTI.

[0133] may introduce security risk because PCI is the same for the last serving gNB and the next serving gNB.

[0134] Thus, it requires different parameter set to derive a fresh key when the serving satellite (and the serving gNB) changes. This is the main problem this disclosure aims to address.

[0135] FIG. 1A is a first part of an exemplary diagram for connection resume scenario in case of Regenerative NTN NGSO satellite deployment.

[0136] FIG. 1B is a second part of an exemplary diagram for connection resume scenario in case of Regenerative NTN NGSO satellite deployment.

[0137] FIG. 1C is a third part of an exemplary diagram for connection resume scenario in case of Regenerative NTN NGSO satellite deployment.

[0138] FIG. 1A, 1B, 1C illustrates a simple connection resume scenario in NTN Regenerative NGSO satellite deployment with key security aspects and parameters used for connection resume and new key derivation as an example.

[0139] In this scenario, the gNB1 (NGSO satellite 1) , the gNB2 (NGSO satellite 2) , and the gNB3 (NGSO satellite3) provide coverage to the terminal device (UE) sequentially, due to the movement of the gNBs or the UE. The UE is firstly connected to the gNB1, and then released from the gNB1 (i.e., the gNB1 is the last serving network node) . When the UE needs to be connected to the network again, the gNB3 is serving the UE (i.e., the gNB3 is the next serving network node) .

[0140] It should be noted that, if the UE switches from the gNB1 to gNB 2, the gNB1 may be the last serving network node, and the gNB2 may be the next serving network node. Then when the UE switches from the gNB2 to gNB3, the gNB2 may be the last serving network node, and the gNB3 may be the next serving network node, and so on.

[0141] The FIG. 1A, 1B, 1C mainly show following steps.

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

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

[0144] In step 3: Xn connectivity assumed between consecutive gNBs in satellite orbit (and thus multiple hops for UE context fetch may be performed) ;

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

[0146] In step 5: Store AS key KRRCint, I-RNTI, AS security context in UE context;

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

[0148] In step 7: Store received NCC, Current AS key KRRCint key, received I-RNTI, AS context in the current UE context;

[0149] In step 8: UE in RRC_INACTIVE CM-CONNECTED;

[0150] In step 9: A stationary UE may remain in the same NTN cell and a moving UE may re-select a new NTN cell;

[0151] In step 10: From time T, gNB1 serves the cell;

[0152] In step 11: From time (T+T1) , gNB2 serves the cell;

[0153] In step 12: From time (T+2T1) , gNB3 serves the cell;

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

[0155] In step 14: RRCResumeRequest, I-RNTI, ResumeMAC-I;

[0156] In step 15: Derive KNG-RAN*using the target PCI, target ARFCN-DL / EARFCN-DL and the KgNB / NH;

[0157] In step 16: RETRIEVE UE CONTEXT REQUEST, I-RNTI, the ResumeMAC-I and target  Cell-ID;

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

[0159] In step 18: source gNB calculates KNG-RAN*using the source PCI, target cell Id (e.g., PCI) , target ARFCN-DL / EARFCN-DL and KgNB / NH in current UE 5G AS security context;

[0160] In step 19: source gNB includes the new derived key ‘KNG-RAN*’ in RETRIEVE UE CONTEXT RESPONSE, UE 5G AS security context (newly derived KNG-RAN*, the NCC) ;

[0161] In step 20: Derive new AS keys using received KNG-RAN*;

[0162] In step 21: RRCResume;

[0163] In step 22: 1. Decrypt the message using KRRCenc that was derived based on newly derived KNG-RAN*; 2. Verify the “RRC Connection Resume” message by verifying the PDCP MAC-I using the KRRCint that was derived from the newly derived KNG-RAN*;

[0164] In step 23: Store KRRCint from the newly derived KNG-RAN*as part of UE current AS security context;

[0165] In step 24: UE in RRC_CCONNECTED CM-CONNECTED;

[0166] In step 25: RRCResumeComplete;

[0167] In step 26: DATA FORWARDING ADDRESS INDICATION;

[0168] In step 27: PATH SWITCH REQUEST;

[0169] In step 28: PATH SWITCH REQUEST RESPONSE;

[0170] In step 29: DL data;

[0171] In step 30: UE CONTEXT RELEASE.

[0172] FIG. 2 is an exemplary diagram showing a simple HO scenario considering Regenerative NTN NGSO satellite deployment.

[0173] FIG. 2 illustrates a simple NTN mobility scenario in NTN Regenerative NGSO satellite deployment with key security aspects and parameters used in Handover for new key derivation as an example.

[0174] In FIG. 2, the UE performs handover from the gNB1 (last serving network node) to the gNB2 (next serving network node) .

[0175] The FIG. 1 mainly shows following steps.

[0176] At step 1: UE in RRC_CONNECTED, CM-CONNECTED state;

[0177] At step 2: DL data;

[0178] At step 3: From time T, gNB1 serves the cell;

[0179] At step 4: Xn connectivity assumed between consecutive gNBs in satellite orbit;

[0180] At step 5: HO decision;

[0181] At step 6, the serving satellite gNB shall compute KNG-RAN*from target PCI, its frequency ARFCN-DL and either currently active KgNB or NH (Next Hop) count;

[0182] At step 7, the serving satellite gNB initiates a HO Request including KNG-RAN*and NCC;

[0183] At step 8, the next serving (or target) gNB shall do the following:

[0184] · Use the received KNG-RAN*directly as KgNB to be used with the UE;

[0185] · Associate the NCC value received with the KgNB and include it into the prepared HO Command message.

[0186] At step 9, Handover Request Ack, includes KgNB, NCC in a transparent container.

[0187] At step 10, handover is triggered.

[0188] At step 10.1, UE shall derive the KNG-RAN*

[0189] ○ (case 1) from currently active KgNB and the target PCI and its frequency ARFCN-DL, if NCC value received in HO command is equal to NCC value associated with currently activeKgNB

[0190] ○ (case 2) otherwise, UE shall compute the KNG-RAN*from the synchronized NH parameter and the target PCI and its frequency ARFCN-DL If the UE received an NCC value that was different from the NCC associated with the currently active KgNB.

[0191] At step 11, DL data.

[0192] However, in NTN Regenerative Earth Fixed Cell (EFC) deployments, the PCI of NTN cell may remain same for stationary Ues and for the Ues that do not undergo cell change, even though the serving satellite (and thus the serving gNB) changes.

[0193] According to security principles, if the following set of parameters:

[0194] · For RRC_INACTIVE state: source PCI, target Cell-ID, source C-RNTI

[0195] · For Handover: target PCI, target ARFCN-DL and the KgNB / NH

[0196] are not changed when the serving satellite changes, then a new parameter must be introduced to differentiate the satellites.

[0197] FIG. 3A is a flow chart showing a method performed by a first network node, according to exemplary embodiments of the present disclosure.

[0198] As shown in FIG. 3A, the method 300 comprises: a step S302, obtaining an identifier of a second network node; and a step S304, computing a key to be used for a 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 differentiates the second network node from at least the first network node.

[0199] According to embodiments of the present disclosure, the exemplary embodiments of the present disclosure propose a mechanism that provides a workable security solution framework for new key computation during switch of serving network nodes. The security risk due to repeated keys may be avoid, when a key is calculated based at least on the identifier of a second network node.

[0200] FIG. 3B is a flow chart showing further steps of the method as shown in FIG. 3A, according to exemplary embodiments of the present disclosure.

[0201] In exemplary embodiments of the present disclosure, the method 300 further comprises: a step S306, storing the key in a context for the terminal device; a step S308, transmitting the key to the second network node; and a step S310, transmitting the identifier of the second network node to the terminal device, via a system information block, or via a radio resource control, RRC, signalling to the terminal device.

[0202] According to embodiments of the present disclosure, the key or the identifier of the second  network node may be transmitted to the second network node and the terminal device. Thus, the keys may be prepared in advance by the second network node and the terminal device before communication therebetween.

[0203] In exemplary embodiments of the present disclosure, the key is to be used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.

[0204] According to embodiments of the present disclosure, the first network node may be the last serving network node, and the second network node may be the next serving network node.

[0205] In exemplary embodiments of the present disclosure, the identifier of the second network node comprises: a global identifier of the second network node; a local next generation-radio access network, NG-RAN, node identifier; or an identifier of a vehicle or platform embarking the second network node.

[0206] The vehicle may be an "airborne vehicle" , and the platform may be a "High Altitude Platform Station (HAPS) " .

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

[0208] In exemplary embodiments of the present disclosure, the first network node obtains the identifier of the second network node from the second network node, or from an ephemeris data.

[0209] In exemplary embodiments of the present disclosure, the key comprises an intermediate key KNG-RAN*; and the key is computed further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.

[0210] In exemplary embodiments of the present disclosure, the key is computed using a vertical key derivation and a horizontal key derivation.

[0211] It should be noted that, any other derivation algorithm conforming to specification or standards may be also used.

[0212] In exemplary embodiments of the present disclosure, the key is used to further derivate a radio resource control, RRC, integrity key, and a RRC encryption key.

[0213] In exemplary embodiments of the present disclosure, the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.

[0214] In exemplary embodiments of the present 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 the non-terrestrial network.

[0215] FIG. 4A is a flow chart showing a method performed by a second network node, according to exemplary embodiments of the present disclosure.

[0216] As shown in the FIG. 4A, the method 400 comprises: a step S402, communicating with a terminal device, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least  a first network node.

[0217] FIG. 4B is a flow chart showing further steps of the method as shown in FIG. 4A, according to exemplary embodiments of the present disclosure.

[0218] In exemplary embodiments of the present disclosure, the method 400 further comprises: a step S404, transmitting the identifier of the second network node to the terminal device, via a system information block, or via a radio resource control, RRC, signalling to the terminal device.

[0219] In exemplary embodiments of the present disclosure, the key is computed by the second network node, or is received from the first network node; the key is used for the communication between the second network node and a terminal device, during a RRC resume initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.

[0220] In exemplary embodiments of the present disclosure, the first network node obtains the identifier of the second network node from the second network node, or from an ephemeris data.

[0221] In exemplary embodiments of the present disclosure, the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.

[0222] In exemplary embodiments of the present 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 the non-terrestrial network.

[0223] In exemplary embodiments of the present disclosure, the identifier of the second network node comprises: a global identifier of the second network node; a local next generation-radio access network, NG-RAN, node identifier; or an identifier of a vehicle or platform embarking the second network node.

[0224] In exemplary embodiments of the present disclosure, the key comprises an intermediate key KNG-RAN*; and the key is computed further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.

[0225] In exemplary embodiments of the present disclosure, the key is computed using a vertical key derivation and a horizontal key derivation.

[0226] In exemplary embodiments of the present disclosure, the key is used to further derivate a radio resource control, RRC, integrity key, and a RRC encryption key.

[0227] FIG. 5A is a flow chart showing a method performed by a terminal device, according to exemplary embodiments of the present disclosure.

[0228] As shown in FIG. 5A, the method 500 comprises: a step S502, communicating with a second network node, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node.

[0229] FIG. 5B is a flow chart showing further steps of the method as shown in FIG. 5A, according to exemplary embodiments of the present disclosure.

[0230] In exemplary embodiments of the present disclosure, the method 500 further comprises: a  step S504, receiving the identifier of the second network node from the second network node or the first network node, via a system information block, or via a radio resource control, RRC, signalling to the terminal device; or a step S506, obtaining the identifier of the second network node from an ephemeris data.

[0231] In exemplary embodiments of the present disclosure, the first network node obtains the identifier of the second network node from the second network node, or from an ephemeris data.

[0232] In exemplary embodiments of the present disclosure, the key is used for the communication between the second network node and a terminal device, during a RRC resume initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.

[0233] In exemplary embodiments of the present disclosure, the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.

[0234] In exemplary embodiments of the present 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 the non-terrestrial network.

[0235] In exemplary embodiments of the present disclosure, the identifier of the second network node comprises: a global identifier of the second network node; a local next generation-radio access network, NG-RAN, node identifier; or an identifier of a vehicle or platform embarking the second network node.

[0236] In exemplary embodiments of the present disclosure, the key comprises an intermediate key KNG-RAN*; and the key is computed by the terminal device further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.

[0237] In exemplary embodiments of the present disclosure, the key is computed using a vertical key derivation and a horizontal key derivation.

[0238] In exemplary embodiments of the present disclosure, the key is used to further derivate a radio resource control, RRC, integrity key, and a RRC encryption key.

[0239] According to embodiments of the present disclosure, it provides a workable security solution framework particularly for new key computation for RRC_INACTIVE state and for HO, when serving satellite gNB changes due to satellite switch in NTN Regenerative Earth Fixed Cell NGSO scenarios with unchanged PCI.

[0240] It should be noted that:

[0241] 1. The UE context may be retrieved over multi-hop Xn connectivity.

[0242] 2. Based on NTN agreements in 3GPP so far, the UE shall be aware of satellite switching time (i.e. therefore time for serving gNB change) . This information is expected to be conveyed via NTN specific SIB19. And UE acquires SIB19 during satellite switch.

[0243] In summary, the embodiments of the present disclosure propose to address the stated problem via the following main steps.

[0244] It is proposed to introduce “gNB Id” or any other identifier that uniquely identifies the next  serving satellite e.g. “satellite Id” , as an additional parameter for security key derivation in the case of NTN NGSO Earth Fixed Cell (EFC) scenarios involving satellite switch without PCI change. It is proposed to achieve this via the following two solution variants or embodiments 1 and 2.

[0245] In one example embodiment, this requires introducing an addition ID (e.g. following parameter S1) as input for KNG-RAN*derivation, e.g. an update to TS 33.501 V18.4.0 (2023-12) A. 11.

[0246] A.11 KNG-RAN*derivation function for target gNB

[0247] When deriving a KNG-RAN*from current KgNB or from fresh NH and the target physical cell ID in the UE and NG-RAN for handover purposes and transition from RRC_INACTIVE to RRC_CONNECTED states the following parameters shall be used to form the input S to the KDF (Key Derivation Function) .

[0248] - FC = 0x70

[0249] - P0 = PCI (target physical cell id)

[0250] - L0 = length of PCI (i.e. 0x00 0x02)

[0251] - P1 = ARFCN-DL (the absolute frequency of SSB of the target Pcell as specified in clause 13.3 of TS 38.300

[0052] )

[0252] - L1 = length of ARFCN-DL (i.e. 0x00 0x03)

[0253] - S1 = Satellite ID or gNB ID or any other ID.

[0254] - L2 = length of Satellite ID or gNB ID or any other ID

[0255] The input key KEY shall be the 256-bit NH when the index NCC in the handover increases, otherwise the current 256-bit KgNB (when source is gNB) or KeNB (when source is ng-eNB) .

[0256] FC is used to distinguish between different instances of the algorithm.

[0257] The SSB may be synchronization signal block, or synchronization signal and physical broadcast channel block.

[0258] During key generation, following keys illustrated in TS 33.501 V18.4.0 (2023-12) may be involved.

[0259] Key for NG-RAN:

[0260] - KgNB is a key derived by ME (Mobility Equipment) and AMF from KAMF. KgNB is further derived by ME and source gNB when performing horizontal or vertical key derivation. The KgNB is used as KeNB between ME and ng-eNB.

[0261] Keys for RRC signalling:

[0262] - KRRCint is a key derived by ME and gNB from KgNB, which shall only be used for the protection of RRC signalling with a particular integrity algorithm.

[0263] - KRRCenc is a key derived by ME and gNB from KgNB, which shall only be used for the protection of RRC signalling with a particular encryption algorithm.

[0264] Intermediate keys:

[0265] - NH is a key derived by ME and AMF to provide forward security as described in Clause A.10.

[0266] - KNG-RAN *is a key derived by ME and NG-RAN (i.e., gNB or ng-eNB) when performing a horizontal or vertical key derivation as specified in Clause 6.9.2.1.1 using a KDF as specified in  Clause A. 11 / A. 12.

[0267] - KAMF' is a key that can be derived by ME and AMF when the UE moves from one AMF to another during inter-AMF mobility as specified in Clause 6.9.3 using a KDF as specified in Annex A.13.

[0268] Solution embodiment 1 may include following steps.

[0269] Step 0: In this embodiment, it is assumed that the UE context (including AS security context with new key Kgnb *or Kng-ran *) of the RRC_INACTIVE state Ues is pushed to the next serving satellite gNB at the time of satellite switch.

[0270] Step 1: The last serving satellite gNB, includes ‘gNB Id’ of the next serving satellite in the SIB19. And UE shall store the ‘gNB Id’ received in SIB19 after every SIB19 acquisition for new key computation for RRC_INACTIVE state Ues.

[0271] ○ Any other identifier that uniquely identifies the serving satellite example ‘Satellite Id’ may be included instead of ‘gNB Id’ in SIB19.

[0272] ○ Here the gNB ID may be either one of the global gNB ID defined in 3GPP TS 38.413 V18.0.0 (2023-12) or the Local NG-RAN node ID as defined in annex F of the 3GPP TS 38.300 V18.0.0 (2023-12) , or any other identifier of the gNB.

[0273] Step 2: Before satellite switches, the last serving satellite gNB computes a fresh key (i.e. KNG-RAN*) using next serving satellite’s ‘gNB Id’ , i.e. using the following parameters: gNB Id of next serving satellite, target ARFCN-DL and the KgNB / NH in the current UE 5G AS security context based on horizontal key derivation or a vertical key derivation. The last serving satellite gNB pushes the new KNG-RAN*to the next serving satellite gNB.

[0274] NOTE: if local NG-RAN node ID are used over XN interface for identification of gNBs across neighbor gNBs, the last serving satellite gNB uses for the computation above the Local NG-RAN node that it earlier received (in an Xn Setup or RAN configuration update message) from the “to be next” serving satellite gNB.

[0275] Step 3: When UE triggers connection resume request (e.g. due to UL data) by sending RRCResumeRequest to the new satellite gNB, the new satellite gNB shall derive the new AS keys (RRC integrity key, RRC encryption key and UP keys) using the new “KNG-RAN*” received in step 2.

[0276] Step 4: The new satellite gNB shall activate the new keys in PDCP layer and respond to the UE with an RRCResume message on SRB1 which is integrity protected and ciphered in PDCP layer using the new RRC keys.

[0277] Step 5: UE upon receiving the RRCResume message, decrypts the message using the “KRRCenc “that was derived based on the newly derived “KNG-RAN*” using “gNB Id” stored at the UE from the latest SIB19 acquisition.

[0278] Solution embodiment 2 may include following steps.

[0279] Step 0: In this embodiment, it is assumed that the UE context (including AS security context with new key) of the RRC_INACTIVE state Ues is pushed to the next serving satellite gNB at the time of satellite switch.

[0280] Step 1: Before satellite switch, the last serving satellite gNB computes a fresh key (i.e. KNG-RAN*) using next serving satellite’s ‘gNB Id’ , i.e. using the following parameters: gNB Id of next serving satellite, target ARFCN-DL and the KgNB / NH in the current UE 5G AS security context based on horizontal key derivation or a vertical key derivation. The last serving satellite gNB pushes the new KNG-RAN*to the next serving satellite gNB.

[0281] NOTE: Here the term “gNB ID” may be either one of the global gNB ID defined in TS 38.413 V18.0.0 (2023-12) or the Local NG-RAN node ID as defined in annex F of the TS 38.300 V18.0.0 (2023-12) , or any other identifier of the gNB.

[0282] NOTE: if local NG-RAN node ID are used over Xn interface for identification of gNBs across neighbor gNBs, the last serving satellite gNB uses for the computation above the Local NG-RAN node that it earlier received (in an Xn Setup or RAN configuration update message) from the “to be next” serving satellite gNB.

[0283] Step 2: When UE triggers connection resume request in the new satellite gNB (e.g. due to UL data) , the new satellite gNB shall respond back with RRCReject including “ (next) serving satellite’s gNB Id” and optionally with ‘RejectWaitTime’ .

[0284] Step 3: The “ (next) serving satellite’s gNB Id” received in RRCReject in step 2, shall be used by the UE to derive new “KNG-RAN*” key, which in turn shall be used by the UE to derive new “KRRCenc” .

[0285] NOTE: same comment as above applies for the definition of “gNB ID” .

[0286] Step 4: On receiving RRCResumeRequest, the new satellite gNB shall derive the new AS keys (RRC integrity key, RRC encryption key and UP keys) using the new “KNG-RAN*” received in step 1.

[0287] Step 5: The new satellite gNB shall activate the new keys in PDCP layer and respond to the UE with an RRCResume message on SRB1 which is integrity protected and ciphered in PDCP layer using the new RRC keys.

[0288] Step 6: UE upon receiving the RRCResume message, shall decrypt the message using the new “KRRCenc “key that was derived based on the newly derived “KNG-RAN*” , in step 3.

[0289] Solution embodiment 3 may include following steps, with considering Handover scenarios.

[0290] Step 1: When a Handover decision is made, the last serving satellite gNB shall compute the KNG-RAN*for the new satellite gNB to which Handover is triggered, using ‘gNB Id’ of the new satellite gNB or any other identifier that uniquely identifies a serving satellite gNB as a new parameter together with target PCI, ARFCN-DL and current active KgNB or NH.

[0291] Note: a new parameter is introduced to differentiate the satellites when the PCI does not change with satellite switch.

[0292] Step 2: The new key (KNG-RAN*) derived in step 1 is included in the Handover Request message (from the last serving gNB to target gNB) .

[0293] Step 3: The new satellite gNB (or target satellite gNB, the next serving satellite gNB) shall use the received KNG-RAN*key directly as KgNB to be used with the UE.

[0294] Step 4: When Handover is triggered, the (KNG-RAN*) key derivation during handover shall additionally use a new parameter ‘gNB Id’ of the new satellite gNB (target satellite gNB to which  handover is triggered) or any other identifier that uniquely identifies a serving satellite gNB, in addition to the existing parameters ( ‘target PCI’ , ARFCN-DL) .

[0295] ○ The UE might acquire ‘gNB Id’ or any other identifier that uniquely identifies a next serving satellite gNB via dedicated RRC signaling or ephemeris data.

[0296] Further, when the embodiments of the present disclosure are implemented, there may be following signaling flows.

[0297] FIG. 6A is a diagram showing a first part of a first example call flow, according to embodiments of the present disclosure.

[0298] FIG. 6B is a diagram showing a second part of a first example call flow, according to embodiments of the present disclosure.

[0299] FIG. 6C is a diagram showing a third part of a first example call flow, according to embodiments of the present disclosure.

[0300] FIG. 6D is a diagram showing a fourth part of a first example call flow, according to embodiments of the present disclosure.

[0301] Key steps in solution embodiment are listed below.

[0302] In Step 1, the serving satellite gNB includes the ‘gNB Id’ of the next serving satellite in SIB19.

[0303] ○ An RRC_INACTIVE state UE may use it to derive a new key ‘KNG-RAN*’ , that may be needed to decrypt RRCResume message from the new satellite gNB (next serving satellite gNB) at the time of connection resume.

[0304] o Any other identity that uniquely identifies a satellite e.g. Satellite Id may also be used.

[0305] In Step 2: UE stores the gNB Id after SIB19 acquisition;

[0306] In Step 3: UE in RRC_CONNECTED, CM-CONNECTED state;

[0307] In Step 4: DL data;

[0308] In Step 5: Xn connectivity assumed between consecutive gNBs in satellite orbit;

[0309] In step 6, the (last) serving satellite gNB (or source satellite gNB) decides to suspend the RRC connection by sending RRCRelease with suspendConfig message that including fresh I-RNTI, and an NCC;

[0310] In step 7, source satellite gNB stores AS key KRRCint, I-RNTI, AS security context in UE context;

[0311] In steps 8 and 9, UE upon receiving RRC Release message with suspendConfig verify the integrity of received message by checking MAC-I field and shall store the received NCC, Current KRRCInt key, I-RNTI and AS context in the current UE context;

[0312] In Step 10: UE in RRC_INACTIVE, CM-CONNECTED;

[0313] In Step 11: A stationary UE may remain in the same NTN cell and a moving UE may re-select a new NTN cell;

[0314] In Step 12: From time T, gNB1 serves the cell;

[0315] In step 13, serving satellite gNB (gNB1) computes fresh key (i.e. KNG-RAN*) to be used by next serving satellite gNB using next serving satellite’s ‘gNB Id’a s an additional parameter i.e. using  the following parameters: gNB Id of next serving satellite, target ARFCN-DL and the KgNB / NH in the current UE 5G AS security context based on horizontal key derivation \nor a vertical key derivation;

[0316] In step 14, it is assumed that the UE context including AS security context with new key for all RRC_INACTIVE state Ues is transferred to next serving satellite at the time of satellite switch. As part of the UE context transfer, the K NG-RAN *computed at step 13 is transferred;

[0317] In step 15, satellite switch is triggered, and the new serving satellite shall be satellite 2 that is hosting gNB2;

[0318] In step 16: DATA FORWARDING ADDRESS INDICATION;

[0319] In step 17: DL data;

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

[0321] In step 19: From time (T+2T1) , gNB3 serves the cell;

[0322] In step 20: DATA FORWARDING ADDRESS INDICATION;

[0323] In step 21: DATA FORWARDING ADDRESS INDICATION;

[0324] In step 22: DL data;

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

[0326] Step 24 is similar to step 14;

[0327] In step 25: At time (T+2T1) UE has UL data to send;

[0328] In step 26, UE initiates RRCResumeRequest due to UL data;

[0329] In step 27, UE shall derive K NG-RAN*using gNB Id of the new satellite received in latest SIB19 acquisition as addition parameter or received in SIB19 of current cell;

[0330] In step 28, the new serving satellite (satellite 3 / gNB3) shall derive new AS keys (RRC integrity key, RRC encryption key and UP keys) using new KNG-RAN*key;

[0331] In step 29, new serving satellite gNB3 sends RRCResume in response to step 26;

[0332] In step 30, UE shall decrypt the received RRCResume message with the new key derived in step 27 and verify the PDCP MAC-I;

[0333] In step 31, UE stores the KRRCInt from the newly derived K NG-RAN*in the current UE AS security context;

[0334] In step 32: UE in RRC_CCONNECTED, CM-CONNECTED;

[0335] In step 33: RRCResumeComplete;

[0336] In step 34: PATH SWITCH REQUEST;

[0337] In step 35: PATH SWITCH REQUEST RESPONSE;

[0338] In step 36: DL data;

[0339] In step 37: UE CONTEXT RELEASE;

[0340] NOTE 1: Here the term “gNB ID” may be either one of the global gNB ID defined in TS 38.413 or the Local NG-RAN node ID as defined in annex F of the TS 38.300, or any other identifier of the gNB.

[0341] NOTE 2: if local NG-RAN node ID are used over Xn interface for identification of gNBs across neighbor gNBs, the serving satellite gNB uses for the computation above the Local NG-RAN node that it earlier received (in an Xn Setup or RAN configuration update message) from the “to be next” serving satellite gNB.

[0342] FIG. 7A is a diagram showing a first part of a second example call flow, according to embodiments of the present disclosure.

[0343] FIG. 7B is a diagram showing a second part of a second example call flow, according to embodiments of the present disclosure.

[0344] FIG. 7C is a diagram showing a third part of a second example call flow, according to embodiments of the present disclosure.

[0345] FIG. 7D is a diagram showing a fourth part of a second example call flow, according to embodiments of the present disclosure.

[0346] Key steps in solution embodiment are listed below.

[0347] In step 1: UE in RRC_CONNECTED, CM-CONNECTED state;

[0348] In step 2: DL data;

[0349] In step 3: Xn connectivity assumed between consecutive gNBs in satellite orbit;

[0350] In step 4, the (last) serving satellite gNB (or source satellite gNB) decides to suspend the RRC connection by sending RRCRelease with suspendConfig message that including fresh I-RNTI, and an NCC.

[0351] In step 5, source satellite gNB stores AS key KRRCint, I-RNTI, AS security context in UE context.

[0352] In steps 6 and 7, UE upon receiving RRC Release message with suspendConfig verify the integrity of received message by checking MAC-I field and shall store the received NCC, Current KRRCInt key, I-RNTI and AS context in the current UE context.

[0353] In step 8: UE in RRC_INACTIVE, CM-CONNECTED;

[0354] In step 9: A stationary UE may remain in the same NTN cell and a moving UE may re-select a new NTN cell;

[0355] In step 10: From time T, gNB1 serves the cell;

[0356] In step 11, (last) serving satellite gNB (gNB1) computes fresh key (i.e. KNG-RAN*) to be used by next serving satellite gNB using next serving satellite’s ‘gNB Id’a s an additional parameter i.e. using the following parameters: gNB Id of next serving satellite, target ARFCN-DL and the KgNB / NH in the current UE 5G AS security context based on horizontal key derivation \nor a vertical key derivation.

[0357] In step 12, it is assumed that the UE context including AS security context with new key for all RRC_INACTIVE state Ues is transferred to next serving satellite at the time of satellite switch.

[0358] In step 13, satellite switch is triggered, and the new serving satellite shall be satellite 2 that is hosting gNB2.

[0359] In step 14: DATA FORWARDING ADDRESS INDICATION;

[0360] In step 15: DL data;

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

[0362] In step 17: From time (T+2T1) , gNB3 serves the cell;

[0363] In step 18: DATA FORWARDING ADDRESS INDICATION;

[0364] In step 19: DATA FORWARDING ADDRESS INDICATION;

[0365] In step 20: DL data;

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

[0367] Step 22 is similar to step 12: UE context including AS security context with new key for all RRC_INACTIVE state Ues is transferred to next serving satellite at the time of satellite switch;

[0368] In step 23: At time (T+2T1) UE has UL data to send;

[0369] In step 24, UE initiates RRCResumeRequest due to UL data.

[0370] In step 25, new serving satellite gNB (gNB3 in fig 3) triggers a RRCReject by including “serving satellite’s gNB Id” and optionally ‘RejectWaitTime’ .

[0371] ○ The “serving satellite’s gNB Id” may be included as an octet string under ‘lateNonCriticalExtension’ filed of RrCReject-IEs as highlighted below:

[0372] In Step 26, UE shall use the “serving satellite’s gNB Id” of new satellite gNB received in RRCReject message as an additional parameter to compute new KNG-RAN*key.

[0373] ○ UE may also wait for ‘RejectWaitTime’ if included by the new serving satellite gNB (gNB3) in RRCReject to attempt RRCResumeRequest again after the ‘RejectWaitTime’ .

[0374] In step 27, the new serving satellite (satellite 3 / gNB3) shall derive new AS keys (RRC integrity key, RRC encryption key and UP keys) using new KNG-RAN*key.

[0375] In step 28, new serving satellite gNB3 sends RRCResume in response to step 26.

[0376] In step 29, UE shall decrypt the received RRCResume message with the new key derived in step 26 and verify the PDCP MAC-I.

[0377] In step 30, UE stores the KRRCInt from the newly derived K NG-RAN*in the current UE AS security context.

[0378] In step 31: UE in RRC_CCONNECTED, CM-CONNECTED;

[0379] In step 32: RRCResumeComplete;

[0380] In step 33: PATH SWITCH REQUEST;

[0381] In step 34: PATH SWITCH REQUEST RESPONSE;

[0382] In step 34: DL data;

[0383] In step 35: UE CONTEXT RELEASE;

[0384] NOTE 1: Here the term “gNB ID” may be either one of the global gNB ID defined in TS 38.413 or the Local NG-RAN node ID as defined in annex F of the TS 38.300, or any other identifier of the gNB.

[0385] NOTE 2: if local NG-RAN node ID are used over Xn interface for identification of gNBs across neighbor gNBs, the serving satellite gNB uses for the computation above the Local NG-RAN node that it earlier received (in an Xn Setup or RAN configuration update message) from the “to be next” serving satellite gNB.

[0386] FIG. 8 is a diagram showing a third example call flow, according to embodiments of the present disclosure.

[0387] Key steps in solution embodiment are listed below.

[0388] At step 1: UE in RRC_CONNECTED, CM-CONNECTED state;

[0389] At step 2: DL data;

[0390] At step 3: From time T, gNB1 serves the cell;

[0391] At step 4: Xn connectivity assumed between consecutive gNBs in satellite orbit;

[0392] At step 5, Handover decision is made.

[0393] At step 6, the (last) serving gNB computes KNG-RAN*from target PCI, ARFCN-DL, current active KgNB or NH and ‘gNB Id’ of the next satellite gNB.

[0394] ○ ‘gNB Id’ of next satellite to which the UE HO is triggered is used as an additional parameter for key computation because the target PCI may remain same in NTN regenerative NGSO deployments with Earth Fixed Cells and with fixed PCI.

[0395] At step 7, the (last) serving satellite gNB includes the new KNG-RAN*key in Handover Request towards the next satellite.

[0396] At step 10, Handover is triggered.

[0397] At step 10.1, UE may acquire the ‘gNB Id’ of the new satellite gNB after Handover either via dedicated RRC signaling or via ephemeris data.

[0398] At step 10.2, UE shall derive the KNG-RAN*either:

[0399] ○ (case 1) from currently active KgNB and the target PCI, its frequency ARFCN-DL and 'gNB Id' of new satellite gNB -if NCC value received in HO command is equal to NCC value associated with currently active KgNB.Or

[0400] ○ (case 2) from the synchronized NH parameter and the target PCI, its frequency ARFCN-DL and 'gNB Id' of new satellite gNB -If the UE received an NCC value that was different from the NCC associated with the currently active KgNB.

[0401] In step 11, DL data;

[0402] Note: For simplicity, it is considered a baseline handover in FIG. 8; however, the solution is applicable also to Condition Handover as specified for NTN.

[0403] According to such implementation of the embodiments, it provides a workable security solution framework for new key computation for RRC_INACTIVE state and for HO, when serving satellite gNB changes due to satellite switch in NTN Regenerative Earth Fixed Cell NGSO scenarios with unchanged PCI.

[0404] FIG. 9 is a block diagram showing an exemplary structure for a first network node, according to exemplary embodiments of the present disclosure.

[0405] As shown in FIG. 9, the first network node 90 comprises means 900 configured for: obtaining an identifier of a second network node; computing a key to be used for a 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 differentiates the second network node from at least the first network node.

[0406] In exemplary embodiments of the present disclosure, the means 900 comprise: at least one processor 902; and at least one memory 904 storing instructions that, when executed by the at least one processor 902, cause the performance of the first network node 90.

[0407] In exemplary embodiments of the present disclosure, the means 900 are further configured for performing the method according to any of the embodiments above mentioned, such as shown in FIG. 3A, 3B, 6A, 6B, 6C, 6D, 7A, 7B, 7C, 7D, 8.

[0408] FIG. 10 is a block diagram showing an exemplary structure for a second network node, according to exemplary embodiments of the present disclosure.

[0409] As shown in FIG. 10, the second network node 100 comprises means 1000 configured for: communicating with a terminal device, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node.

[0410] In exemplary embodiments of the present disclosure, the means 1000 comprise: at least one processor 1002; and at least one memory 1004 storing instructions that, when executed by the at least one processor 1002, cause the performance of the third network node 100.

[0411] In exemplary embodiments of the present disclosure, the means 800 are further configured for performing the method according to any of the embodiments above mentioned, such as shown in FIG. 4A, 4B, 6A, 6B, 6C, 6D, 7A, 7B, 7C, 7D, 8.

[0412] FIG. 11 is a block diagram showing an exemplary structure for a terminal device, according to exemplary embodiments of the present disclosure.

[0413] As shown in FIG. 11, the terminal device 110 comprises means 1100 configured for: communicating with a second network node, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node.

[0414] In exemplary embodiments of the present disclosure, the means 1100 comprise: at least one processor 1102; and at least one memory 1104 storing instructions that, when executed by the at least  one processor 1102, cause the performance of the fourth node 110.

[0415] In exemplary embodiments of the present disclosure, the means 1100 are further configured for performing the method according to any of the embodiments above mentioned, such as shown in FIG. 5A, 5B, 6A, 6B, 6C, 6D, 7A, 7B, 7C, 7D, 8.

[0416] The processor 902, 1002, 1102 may be any kind of processing component, such as one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs) , special-purpose digital logic, and the like. The memory 904, 1004, 1104 may be any kind of storage component, such as read-only memory (ROM) , random-access memory, cache memory, flash memory devices, optical storage devices, etc.

[0417] FIG. 12 is a block diagram showing an apparatus / computer readable storage medium, according to embodiments of the present disclosure.

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

[0419] In addition, the present disclosure may also provide a carrier containing the computer program / instructions as mentioned above. The carrier is one of an electronic signal, optical signal, radio signal, or the above computer readable storage medium. The computer readable storage medium can be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory) , a ROM (read only memory) , Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.

[0420] FIG. 13 is a block diagram showing exemplary apparatus units for a first network node, which is suitable for performing the method according to embodiments of the disclosure.

[0421] As shown in FIG. 13, the first network node 130 may include: an obtaining unit 1302, obtaining an identifier of a second network node; a computing unit 1304, computing a key to be used for a 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 differentiates the second network node from at least the first network node.

[0422] In exemplary embodiments of the present disclosure, the first network node 170 is further configured for performing the method according to any of the embodiments above mentioned, such as shown in FIG. 3A, 3B, 6A, 6B, 6C, 6D, 7A, 7B, 7C, 7D, 8.

[0423] FIG. 14 is a block diagram showing exemplary apparatus units for a second network node, which is suitable for performing the method according to embodiments of the disclosure.

[0424] As shown in FIG. 14, the second network node 140 may include: a communicating unit 1402, communicating with a terminal device, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node.

[0425] In exemplary embodiments of the present disclosure, the second network node 140 is further  configured for performing the method according to any of the embodiments above mentioned, such as shown in FIG. 4A, 4B, 6A, 6B, 6C, 6D, 7A, 7B, 7C, 7D, 8.

[0426] FIG. 15 is a block diagram showing exemplary apparatus units for a terminal device, which is suitable for performing the method according to embodiments of the disclosure.

[0427] As shown in FIG. 15, the terminal device 150 may include: a communicating unit 1502, communicating with a second network node, using a key. The key is computed, based at least on an identifier of the second network node. The identifier of the second network node differentiates the second network node from at least a first network node.

[0428] In exemplary embodiments of the present disclosure, the third network node 130 is further configured for performing the method according to any of the embodiments above mentioned, such as shown in FIG. 5A, 5B, 6A, 6B, 6C, 6D, 7A, 7B, 7C, 7D, 8.

[0429] The term ‘unit’ may have conventional meaning in the field of electronics, electrical devices and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0430] As used in the present disclosure, the term “circuitry” may refer to one or more or all of the following:

[0431] (a) hardware-only circuit implementations (such as implementations in only analogy and / or digital circuitry) and

[0432] (b) combinations of hardware circuits and software, such as (as applicable) :

[0433] (i) a combination of analogy and / or digital hardware circuit (s) with software / firmware and

[0434] (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[0435] (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. ”

[0436] This definition of circuitry applies to all uses of this term in the present disclosure, including in any claims. As a further example, as used in the present disclosure, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0437] With these units, the apparatus may not need a fixed processor or memory, any kind of computing resource and storage resource may be arranged from at least one node / device / entity / apparatus relating to the communication system. The virtualization technology and  network computing technology (e.g., cloud computing) may be further introduced, so as to improve the usage efficiency of the network resources and the flexibility of the network.

[0438] The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses) , firmware (one or more apparatuses) , software (one or more modules / units) , or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

[0439] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments 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 functionalities may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0440] The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

[0441] As described in above exemplary embodiments of this disclosure, embodiments herein afford many advantages. According to embodiments of the present disclosure, the exemplary embodiments of the present disclosure propose a mechanism that provides a workable security solution framework for new key computation during switch of serving network nodes. The security risk due to repeated keys may be avoid. Particularly, it provides a workable security solution framework for new key computation for RRC_INACTIVE state and for HO, when serving satellite gNB changes due to satellite switch in NTN Regenerative Earth Fixed Cell NGSO scenarios with unchanged PCI.

[0442] It should be understood that the above embodiments are only for illustration but not limitation. The present disclosure may be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the disclosure. All changes to these embodiments not departing from the meaning and equivalency of the appended claims are intended to be comprised herein.

[0443] REFERENCES

[0444] The followings are the references which are incorporated herein in their entirety:

[0445] 3GPP TR 38.821 V16.2.0 (2023-03)

[0446] 3GPP TS 33.501 V18.4.0 (2023-12)

[0447] 3GPP TS 38.413 V18.0.0 (2023-12)

[0448] 3GPP TS 38.300 V18.0.0 (2023-12)

[0449] ABBREVIATION    EXPLANATION

[0450] AS                  Access Stratum

[0451] AMF                 Access Management Function

[0452] ARFCN               Absolute Radio Frequency Channel Number

[0453] C-RNTI              Cell Radio Network Temporary Identifier

[0454] EFC                 Earth Fixed Cells

[0455] PCI                 Physical Cell Identifier.

[0456] LEO                 Low Earth Orbit

[0457] MAC                 Medium Access Control

[0458] NGSO                Non-geostationary

[0459] NTN                 Non-Terrestrial Network

[0460] PDCP                Packet Data Convergence Protocol

[0461] SRB                 Signaling Radio Bearer

[0462] UE                  User Equipment

[0463] NR                  New Radio

[0464] DU                  Distributed Unit

[0465] I-RNTI              Inactive Radio Network Temporary Identifier

[0466] NCC                 Next Hop Chaining Counter

[0467] MAC-I               Message Authentication Code for Integrity

[0468] Xn-AP               Xn Application Protocol

[0469] EARFCN              Evolved Universal Terrestrial Radio Access Absolute Radio Frequency Channel Number

[0470] FLSO                Hard Feeder Link Switch Over

[0471] AMF                 Access and Mobility Management Function

[0472] DL                  Downlink

[0473] CP                  Control Plane

[0474] UP                  User Plane

[0475] SMF                 Session Management Function

[0476] UPF                 User Plane Function

[0477] NTN                 Non Terrestrial Network

[0478] LEO                 Low-Earth Orbit

[0479] NG                  Next Generation

[0480] TNL                 Transport Network Layer

[0481] AN                  Access Network

[0482] TEID                Tunnel Endpoint Identifier

[0483] F-TEID              Full Qualified Tunnel Endpoint Identifier

Claims

1.A method (300) performed by a first network node in a communication network, comprising:obtaining (S302) an identifier of a second network node; andcomputing (S304) a key to be used for a communication between the second network node and a terminal device, based at least on the identifier of the second network node;wherein the identifier of the second network node differentiates the second network node from at least the first network node.2.The method (300) according to claim 1, further comprising:storing (S306) the key in a context for the terminal device;transmitting (S308) the key to the second network node; andtransmitting (S310) the identifier of the second network node to the terminal device, via a system information block, or via a radio resource control, RRC, signalling to the terminal device3.The method (300) according to claim 1 or 2,wherein the key is to be used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.4.The method (300) according to any of claims 1 to 3, wherein the identifier of the second network node comprises:a global identifier of the second network node;a local next generation-radio access network, NG-RAN, node identifier; oran identifier of a vehicle or platform embarking the second network node.5.The method (300) according to any 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 an ephemeris data.6.The method (300) according to any of claims 1 to 5,wherein the key comprises an intermediate key KNG-RAN*; andwherein the key is computed further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.7.The method (300) according to claim 6,wherein the key is computed using a vertical key derivation and a horizontal key derivation.8.The method (300) according to claim 6 or 7,wherein the key is used to further derive a radio resource control, RRC, integrity key, and a RRC encryption key.9.The method (300) according to any of claims 1 to 8,wherein the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.10.The method (300) according to any of claims 1 to 9,wherein the first network node is a first non-terrestrial network, NTN, network node in a non-terrestrial network; andwherein the second network node is a 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 (S402) with a terminal device, using a key;wherein the key is computed, based at least on an identifier of the second network node; andwherein the identifier of the second network node differentiates the second network node from at least a first network node.12.The method (400) according to claim 11, further comprising:transmitting (S404) the identifier of the second network node to the terminal device, via a system information block, or via a radio resource control, RRC, signalling to the terminal device.13.The method (400) according to claim 11 or 12,wherein the key is computed by the second network node, or is received from the first network node;wherein the key is used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.14.The method (400) according to claim 13, wherein the first network node obtains the identifier of the second network node from the second network node, or from an ephemeris data.15.The method (400) according to claim 14,wherein the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.16.The method (400) according to any of claims 13 to 15,wherein the first network node is a first non-terrestrial network, NTN, network node in a non-terrestrial network; andwherein the second network node is a second NTN network node in the non-terrestrial network.17.The method (400) according any of claims 11 to 16, wherein the identifier of the second network node comprises:a global identifier of the second network node;a local next generation-radio access network, NG-RAN, node identifier; oran identifier of a vehicle or platform embarking the second network node.18.The method (400) according to any of claims 11 to 17,wherein the key comprises an intermediate key KNG-RAN*; andwherein the key is computed further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.19.The method (400) according to claim 18,wherein the key is computed using a vertical key derivation and a horizontal key derivation.20.The method (400) according to claim 18 or 19,wherein the key is used to further derive a radio resource control, RRC, integrity key, and a RRC encryption key.21.A method (500) performed by terminal device in a communication network, comprising:communicating (S502) with a second network node, using a key;wherein the key is computed, based at least on an identifier of the second network node; andwherein the identifier of the second network node differentiates the second network node from at least a first network node.22.The method (500) according to claim 21, further comprising:receiving (S504) the identifier of the second network node from the second network node or the first network node, via a system information block, or via a radio resource control, RRC, signalling to the terminal device; orobtaining (S506) the identifier of the second network node from an ephemeris data.23.The method (500) according to claim 22, wherein the first network node obtains the identifier of the second network node from the second network node, or from an ephemeris data.24.The method (500) according to claim 23,wherein the key is used for the communication between the second network node and a terminal device, during a RRC resume procedure initiated by the terminal device, or a handover of the terminal device from the first network node to the second network node.25.The method (500) according to claim 24,wherein the first network node and the second network node are configured with the same physical cell identifier, PCI, when serving the terminal device.26.The method (500) according to any of claims 22 to 25,wherein the first network node is a first non-terrestrial network, NTN, network node in a non-terrestrial network; andwherein the second network node is a second NTN network node in the non-terrestrial network.27.The method (500) according any of claims 21 to 26, wherein the identifier of the second network node comprises:a global identifier of the second network node;a local next generation-radio access network, NG-RAN, node identifier; oran identifier of a vehicle or platform embarking the second network node.28.The method (500) according to any of claims 21 to 27,wherein the key comprises an intermediate key KNG-RAN*; andwherein the key is computed by the terminal device further based on: a physical cell identifier of the second network node, a frequency of a synchronization signal block of a primary cell of the second network node, and KgNB key or Next Hop, NH, count.29.The method (500) according to claim 28,wherein the key is computed using a vertical key derivation and a horizontal key derivation.30.The method (500) according to claim 28 or 29,wherein the key is used to further derive a radio resource control, RRC, integrity key, and a RRC encryption key.31.A first network node (90) comprising means (900) configured for:obtaining an identifier of a second network node; andcomputing a key to be used for a communication between the second network node and a terminal device, based at least on the identifier of the second network node;wherein the identifier of the second network node differentiates the second network node from at least the first network node;wherein the means (900) comprise:at least one processor (902) ; andat least one memory (904) storing instructions that, when executed by the at least one processor (902) , cause the performance of the first network node (90) .32.The first network node (90) according to claim 31, wherein the means (900) are further configured for performing the method according to any of the claims 2 to 10.33.A second network node (100) comprising means (1000) configured for:communicating with a terminal device, using a key;wherein the key is computed, based at least on an identifier of the second network node; andwherein the identifier of the second network node differentiates the second network node from at least a first network node;wherein the means (1000) comprise:at least one processor (1002) ; andat least one memory (1004) storing instructions that, when executed by the at least one processor (1002) , cause the performance of the second network node (100) .34.The second network node (100) according to claim 33, wherein the means (1000) are further configured for performing the method according to any of the claims 12 to 20.35.A terminal device (110) comprising means (1100) configured for:communicating with a second network node, using a key;wherein the key is computed, based at least on an identifier of the second network node; andwherein the identifier of the second network node differentiates the second network node from at least a first network node;wherein the means comprise:at least one processor (1102) ; andat least one memory (1104) storing instructions that, when executed by the at least one processor (1102) , cause the performance of the terminal device (110) .36.The terminal device (110) according to claim 35, wherein the means (1100) are further configured for performing the method according to any of the claims 22 to 30.37.A computer-readable storage medium (120) storing instructions (121) , which when executed by at least one processor of an apparatus, cause the at least one processor of the apparatus to perform the method according to any of claims 1 to 30.

Images