Techniques to support security for store and forward satellite access

Abstract

To support secure access of a user equipment (UE) to a satellite operating in a store and forward mode, the satellite may send an authentication request to the UE that includes a portion of a key identifier (ID), which may be least significant bits. The portion of the key ID and a derived key may be configured in the satellite. The UE may reconstruct the key ID based on the portion of the key ID and may determine the derived key from the key ID and a master key provisioned to the UE. The satellite may authenticate an identity (e.g., an international mobile subscriber identity (IMSI) or subscription permanent identifier (SUPI)) for the UE using the derived key. For accessing a home network of the UE, a second identity and a second key for the UE may be used to avoid exposing the master key to a serving ground network.

Description

TECHNIQUES TO SUPPORT SECURITY FOR STORE AND FORWARD SATELLITEACCESSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This Patent Application claims priority to Greece Application No. 20240100250, filed on April 4, 2024, entitled “SECURITY FOR STORE AND FORWARD SATELLITE ACCESS,” and assigned to the assignee hereof, claims priority to Greece Application No.20240100554, filed on August 5, 2024, entitled “TECHNIQUES TO SUPPORT SECURITY FOR STORE AND FORWARD SATELLITE ACCESS,” and assigned to the assignee hereof, and claims priority to United States Provisional Application No. 63 / 554,076, filed on February 15, 2024, entitled “TRANSITIONS BETWEEN STORE AND FORWARD MODE AND REAL TIME MODE,” and assigned to the assignee hereof. The disclosures of the prior Applications are considered part of and are incorporated by reference into this Patent Application.FIELD OF THE DISCLOSURE

[0002] Aspects of the present disclosure generally relate to wireless communication and specifically relate to techniques, apparatuses, and methods for wireless communication using satellites in store and forward mode and in real time mode.BACKGROUND

[0003] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources.Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, singlecarrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0004] These multiple access technologies have been adopted in various telecommunication standards to use common protocols that enable different wireless devices to communicate on a municipal, national, regional, and global level. An example telecommunication standard is 5G New Radio (NR). 5G NR is part of a continuous mobile broadband evolution promulgated by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB),massive machine type communications (eMTC), and ultra-reliable low latency communications (URLLC). Some wireless communication networks may include non-terrestrial components. Some aspects of 5G NR may be based on the 3GPP 4G Long Term Evolution (LTE) standard.

[0005] Both 5G NR and 4G LTE can support access to wireless networks using satellites. In such cases, a mobile device may access a satellite that does not have contemporaneous access to a ground based wireless network. In this case, the mobile device and the satellite may need to support store and forward operation to enable the mobile device to access remote endpoints via a ground based wireless network. Techniques to support store and forward operation may thus be useful.SUMMARY

[0006] Some aspects described herein relate to an apparatus for wireless communication at a user equipment (UE). The apparatus may include one or more memories and one or more processors coupled to the one or more memories. The one or more processors may be configured to receive, from a space vehicle (SV) operating in a store and forward mode, an authentication request that includes an identifier (ID) associated with the SV. The one or more processors may be configured to determine a derived key from a master key that was provisioned to the UE and the ID associated with the SV, wherein the master key is different than a second key, associated with the UE, that was provisioned to a satellite store and forward center (SFC). The one or more processors may be configured to transmit, to the SV, an authentication response that includes an authentication result determined from the derived key, wherein the authentication response is used to validate a first international mobile subscriber identity (IMSI) or subscription permanent identifier (SUPI) associated with the UE.

[0007] Some aspects described herein relate to an apparatus for wireless communication at an SFC. The apparatus may include one or more memories and one or more processors coupled to the one or more memories. The one or more processors may be configured to receive, from an SV operating in a store and forward mode, mobile originated (MO) data and a first IMSI or SUPI for a UE. The one or more processors may be configured to determine a second IMSI or SUPI for the UE based on the first IMSI or SUPI. The one or more processors may be configured to receive, from a ground network, an authentication request. The one or more processors may be configured to transmit, to the ground network, an authentication response that includes an authentication result determined from a second key for the UE provisioned to the SFC, wherein the second key is different than a master key that was provisioned to the UE, and wherein the authentication response is used to validate the second IMSI or SUPI. The one or more processors may be configured to transmit, to the ground network, the MO data in response to the second IMSI or SUPI being validated.

[0008] Some aspects described herein relate to a method of wireless communication performed by a UE. The method may include receiving, from an SV operating in a store and forward mode, an authentication request that includes an ID associated with the SV. The method may include determining a derived key from a master key that was provisioned to the UE and the ID associated with the SV, wherein the master key is different than a second key, associated with the UE, that was provisioned to an SFC. The method may include transmitting, to the SV, an authentication response that includes an authentication result determined from the derived key, wherein the authentication response is used to validate a first IMSI or SUPI associated with the UE.

[0009] Some aspects described herein relate to a method of wireless communication performed by an SFC. The method may include receiving, from an SV operating in a store and forward mode, MO data and a first IMSI or SUPI for a UE. The method may include determining a second IMSI or SUPI for the UE based on the first IMSI or SUPI. The method may include receiving, from a ground network, an authentication request. The method may include transmitting, to the ground network, an authentication response that includes an authentication result determined from a second key for the UE provisioned to the SFC, wherein the second key is different than a master key that was provisioned to the UE, and wherein the authentication response is used to validate the second IMSI or SUPI. The method may include transmitting, to the ground network, the MO data in response to the second IMSI or SUPI being validated.

[0010] Some aspects described herein relate to a non-transitory computer-readable medium that stores a set of instructions for wireless communication by a UE. The set of instructions, when executed by one or more processors of the UE, may cause the UE to receive, from an SV operating in a store and forward mode, an authentication request that includes an ID associated with the SV. The set of instructions, when executed by one or more processors of the UE, may cause the UE to determine a derived key from a master key that was provisioned to the UE and the ID associated with the SV, wherein the master key is different than a second key, associated with the UE, that was provisioned to an SFC. The set of instructions, when executed by one or more processors of the UE, may cause the UE to transmit, to the SV, an authentication response that includes an authentication result determined from the derived key, wherein the authentication response is used to validate a first IMSI or SUPI associated with the UE.

[0011] Some aspects described herein relate to a non-transitory computer-readable medium that stores a set of instructions for wireless communication by an SFC. The set of instructions, when executed by one or more processors of the SFC, may cause the SFC to receive, from an SV operating in a store and forward mode, MO data and a first IMSI or SUPI for a UE. The set of instructions, when executed by one or more processors of the SFC, may cause the SFC to determine a second IMSI or SUPI for the UE based on the first IMSI or SUPI. The set ofinstructions, when executed by one or more processors of the SFC, may cause the SFC to receive, from a ground network, an authentication request. The set of instructions, when executed by one or more processors of the SFC, may cause the SFC to transmit, to the ground network, an authentication response that includes an authentication result determined from a second key for the UE provisioned to the SFC, wherein the second key is different than a master key that was provisioned to the UE, and wherein the authentication response is used to validate the second IMSI or SUPE The set of instructions, when executed by one or more processors of the SFC, may cause the SFC to transmit, to the ground network, the MO data in response to the second IMSI or SUPI being validated.

[0012] Some aspects described herein relate to an apparatus for wireless communication. The apparatus may include means for receiving, from an SV operating in a store and forward mode, an authentication request that includes an ID associated with the SV. The apparatus may include means for determining a derived key from a master key that was provisioned to the apparatus and the ID associated with the SV, wherein the master key is different than a second key, associated with the apparatus, that was provisioned to an SFC. The apparatus may include means for transmitting, to the SV, an authentication response that includes an authentication result determined from the derived key, wherein the authentication response is used to validate a first IMSI or SUPI associated with the apparatus.

[0013] Some aspects described herein relate to an apparatus for wireless communication. The apparatus may include means for receiving, from an SV operating in a store and forward mode, MO data and a first IMSI or SUPI for a UE. The apparatus may include means for determining a second IMSI or SUPI for the UE based on the first IMSI or SUPI. The apparatus may include means for receiving, from a ground network, an authentication request. The apparatus may include means for transmitting, to the ground network, an authentication response that includes an authentication result determined from a second key for the UE provisioned to the apparatus, wherein the second key is different than a master key that was provisioned to the UE, and wherein the authentication response is used to validate the second IMSI or SUPI. The apparatus may include means for transmitting, to the ground network, the MO data in response to the second IMSI or SUPI being validated.

[0014] Some aspects described herein relate to an apparatus for wireless communication at a UE. The apparatus may include one or more memories and one or more processors coupled to the one or more memories. The one or more processors may be configured to receive, from an SV operating in a store and forward mode, an authentication request that includes a portion of a key ID, wherein the portion of the key ID and a derived key are configured in the SV. The one or more processors may be configured to reconstruct the key ID based on the portion of the key ID. The one or more processors may be configured to determine the derived key from the keyID and a master key that was provisioned to the UE. The one or more processors may be configured to perform authentication with the SV using the derived key.

[0015] Some aspects described herein relate to a method of wireless communication performed by a UE. The method may include receiving, from an SB operating in a store and forward mode, an authentication request that includes a portion of a key ID, wherein the portion of the key ID and a derived key are configured in the SV. The method may include reconstructing the key ID based on the portion of the key ID. The method may include determining the derived key from the key ID and a master key that was provisioned to the UE. The method may include performing authentication with the SV using the derived key.

[0016] Some aspects described herein relate to a non-transitory computer-readable medium that stores a set of instructions for wireless communication by a UE. The set of instructions, when executed by one or more processors of the UE, may cause the UE to receive, from an SV operating in a store and forward mode, an authentication request that includes a portion of a key ID, wherein the portion of the key ID and a derived key are configured in the SV. The set of instructions, when executed by one or more processors of the UE, may cause the UE to reconstruct the key ID based on the portion of the key ID. The set of instructions, when executed by one or more processors of the UE, may cause the UE to determine the derived key from the key ID and a master key that was provisioned to the UE. The set of instructions, when executed by one or more processors of the UE, may cause the UE to perform authentication with the SV using the derived key.

[0017] Some aspects described herein relate to an apparatus for wireless communication. The apparatus may include means for receiving, from an SB operating in a store and forward mode, an authentication request that includes a portion of a key ID, wherein the portion of the key ID and a derived key are configured in the SV. The apparatus may include means for reconstructing the key ID based on the portion of the key ID. The apparatus may include means for determining the derived key from the key ID and a master key that was provisioned to the UE. The apparatus may include means for performing authentication with the SV using the derived key.

[0018] Some aspects described herein relate to an apparatus for wireless communication at an SV operating in a store and forward mode. The apparatus may include one or more memories and one or more processors coupled to the one or more memories. The one or more processors may be configured to send, to a UE, an authentication request that includes a portion of a key ID, wherein the portion of the key ID is configured in the SV, wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, and wherein the derived key is configured in the SV. The one or more processors may be configured to perform authentication with the UE using the derived key.

[0019] Some aspects described herein relate to a method of wireless communication performed by an SV operating in a store and forward mode. The method may include sending, to a UE, an authentication request that includes a portion of a key ID, wherein the portion of the key ID is configured in the SV, wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, and wherein the derived key is configured in the SV. The method may include performing authentication with the UE using the derived key.

[0020] Some aspects described herein relate to a non-transitory computer-readable medium that stores a set of instructions for wireless communication by an SV operating in a store and forward mode. The set of instructions, when executed by one or more processors of the SV, may cause the SV to send, to a UE, an authentication request that includes a portion of a key ID, wherein the portion of the key ID is configured in the SV, wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, and wherein the derived key is configured in the SV. The set of instructions, when executed by one or more processors of the SV, may cause the SV to perform authentication with the UE using the derived key.

[0021] Some aspects described herein relate to an apparatus for wireless communication in a store and forward mode. The apparatus may include means for sending, to a UE, an authentication request that includes a portion of a key ID, wherein the portion of the key ID is configured in the apparatus, wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, and wherein the derived key is configured in the apparatus. The apparatus may include means for performing authentication with the UE using the derived key.

[0022] Aspects of the present disclosure may generally be implemented by or as a method, apparatus, system, computer program product, non-transitory computer-readable medium, user equipment, base station, network node, network entity, wireless communication device, and / or processing system as substantially described with reference to, and as illustrated by, the specification and accompanying drawings.

[0023] The foregoing paragraphs of this section have broadly summarized some aspects of the present disclosure. These and additional aspects and associated advantages will be described hereinafter. The disclosed aspects may be used as a basis for modifying or designing other aspects for carrying out the same or similar purposes of the present disclosure. Such equivalent aspects do not depart from the scope of the appended claims. Characteristics of the aspects disclosed herein, both their organization and method of operation, together with associated advantages, will be better understood from the following description when considered in connection with the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The appended drawings illustrate some aspects of the present disclosure, but are not limiting of the scope of the present disclosure because the description may enable other aspects. Each of the drawings is provided for purposes of illustration and description, and not as a definition of the limits of the claims.

[0025] FIG. 1 illustrates access by a mobile device to a network via a satellite.

[0026] FIG. 2 illustrates an architecture of a satellite to support store and forward operation with discontinuous feeder links.

[0027] FIG. 3 illustrates store and forward operation via a satellite to a ground based network and remote endpoints.

[0028] FIG. 4 illustrates a first option for accessing a ground based network using store and forward operation.

[0029] FIG. 5 illustrates a second option for accessing a ground based network using store and forward operation.

[0030] FIG. 6 illustrates a third option for accessing a ground based network using store and forward operation.

[0031] FIG. 7 is a signaling flow diagram of a method of store and forward mode.

[0032] FIGs. 8 and 9 are signaling flow diagrams illustrating examples of authentication in a store and forward mode.

[0033] FIG. 10 is a flow diagram of a method of authenticating a UE in store and forward mode.

[0034] FIG. 11 is a flow diagram of a method of authenticating a store and forward center.

[0035] FIG. 12 is a flow diagram of a method, performed by a UE, of authenticating a UE and SV in a store and forward mode.

[0036] FIG. 13 is a flow diagram of a method, performed by an SV, of authenticating a UE and SV in a store and forward mode.

[0037]

[0038] FIG. 14 is a diagram illustrating an example of a hardware implementation of a UE configured to access a space vehicle.

[0039] FIG. 15 is a diagram illustrating an example of a hardware implementation of a space vehicle configured to support access by a UE.

[0040] FIG. 16 is a diagram illustrating an example of a hardware implementation of a server configured to support UE access to a space vehicle.

[0041] FIG. 17 is a diagram illustrating an example of a hardware implementation of an entity in a public land mobile network.

[0042] FIG. 18 is a block diagram of a network entity in communication with a UE in an access network.

[0043] Like reference numbers and symbols in the various figures indicate like elements, in accordance with certain example implementations. In addition, multiple instances of an element may be indicated by following a first number for the element with a single letter or with a hyphen and a second number. For example, multiple instances of an element 106 may be indicated as 106-1, 106-2, 106-3, and so on. Similarly, multiple instances of an element 104 may be indicated as 104a, 104b, 104c, and so on. When referring to such an element using only the first number, any instance of the element is to be understood (e.g., elements 106 in the previous example may refer to any of elements 106-1, 106-2, and 106-3, and element 104 in the previous example may refer to any of elements 104a, 104b, and 104c).DETAILED DESCRIPTION

[0044] Various aspects of the present disclosure are described hereinafter with reference to the accompanying drawings. However, aspects of the present disclosure may be embodied in many different forms and is not to be construed as limited to any specific aspect illustrated by or described with reference to an accompanying drawing or otherwise presented in this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. One skilled in the art may appreciate that the scope of the disclosure is intended to cover any aspect of the disclosure disclosed herein, whether implemented independently of or in combination with any other aspect of the disclosure. For example, an apparatus may be implemented or a method may be practiced using various combinations or quantities of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover an apparatus having, or a method that is practiced using, other structures and / or functionalities in addition to or other than the structures and / or functionalities with which various aspects of the disclosure set forth herein may be practiced. Any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0045] Several aspects of telecommunication systems will now be presented with reference to various methods, operations, apparatuses, and techniques. These methods, operations, apparatuses, and techniques will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, or algorithms (collectively referred to as “elements”). These elements may be implemented using hardware, software, or a combination of hardware and software. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0046] Deployment of communication systems, such as 5G New Radio (NR) systems, may be arranged in multiple manners with various components or constituent parts. In a 5G NR system, or network, a network node, a network entity, a mobility element of a network, a radio access network (RAN) node, a core network node, a network element, or a network equipment, such as a base station (BS), or one or more units (or one or more components) performing base station functionality, may be implemented in an aggregated or disaggregated architecture. For example, a BS (such as a Node B (NB), evolved NB (eNB), NR BS, 5G NB, access point (AP), a transmission reception point (TRP), or a cell, etc.) may be implemented as an aggregated base station (also known as a standalone BS or a monolithic BS) or one or more components of a disaggregated base station. A disaggregated base station may be configured to utilize a protocol stack that is physically or logically distributed among two or more units (such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs)).

[0047] FIG. 1 illustrates an example communication system 100 in which a user equipment (UE) 102 accesses a ground public land mobile network (PLMN) 108 via a space vehicle (SV) 104 and a non-terrestrial network (NTN) gateway 106. The ground PLMN 108 provides access for the UE 102 to remote endpoints 116 via the Internet 112, the public switched telephone network (PSTN) 114 and other networks 110. FIG. 1 illustrates that there may be various endpoints (e.g., remote endpoints 116a, 116b, 116c, 116c, and 116d). The remote endpoints 116 can include application functions (AFs), external clients and other UEs 102 and may be physically supported by Internet servers, computers, Internet of Things (loT) devices and other mobile devices. The radio communication link between the UE 102 and the SV 104 is referred to as service link (SL) 101 and may be based on 5G NR, 4G Long Term Evolution (LTE), a future 6G standard or some other wireless standard. The radio communication link between the SV 104 and the NTN gateway 106 is referred to as feeder link (FL) 103. In normal operation, when the UE 102 has a service link 101 to the SV 104, the SV 104 will also have a feeder link 103 to an NTN gateway 106. With a discontinuous FL (DFL), the SV 104 may provide a service link 101 to the UE 102 without the availability of a feeder link 103 to an NTN gateway 106 at the same time.

[0048] DFL can apply to low earth orbit (LEO) and medium earth orbit (MEO) SVs 104 but not normally to geostationary earth orbit (GEO) SVs 104. With no FL availability, space vehicles (SVs) 104 in view of a UE 102 may not have a feeder link. With partial FL availability, SVs in view of a UE 102 may sometimes have a feeder link for a portion of their overall accessibility time to the UE 102. With continuous SL availability, SVs 104 with SLs may continuously be available to UE 102. With discontinuous SL availability, SVs 104 with SLs may, at times, not be available to a UE 102. When an SV 104 has a feeder link, the SV 104 may operate in real time mode (also referred to as normal mode) when providing access to anyUE 102. In real time mode, the SV 104 can transfer voice, data and control information between the UE 102 and the ground PLMN 108 in real time without a need to store and later forward the information. Real time mode can include transparent operation in which the SV 104 transfers voice, data and control information between the UE 102 to the ground PLMN 108 without interpretation or modification. Real time mode can also include regenerative operation in which the SV 104 performs some interpretation and possibly protocol and format conversion for the information being transferred between the UE 102 and the PLMN 108.

[0049] With no FL availability (e.g., at a time when a FL is not available), an SV 104 may operate in store and forward (S&F) mode, in which the SV 104 stores information received from the UE 102 when a service link is available and forwards the information to the ground PLMN 108 when a feeder link is available, and similarly stores information received from the ground PLMN 108 when the feeder link is available and forwards the information to the UE 102 when the service link is available. S&F mode may support continuous SL availability, discontinuous SL availability, no FL availability, and / or partial FL availability.

[0050] To support S&F mode for UEs with access to SVs 104, PLMN functionality may be included in an SV 104 including the functionality of a RAN and core network (CN) and where an SV 104 may include complete or partial CN functionality and may perform store and forwarding at an application level in an SV 104 using an endpoint proxy which mimics the behavior of a remote endpoint and using a UE proxy in a ground based PLMN 108 or separate ground based store and forward center which mimics the behavior of a UE 102. Including complete or partial CN functionality may avoid store and forward at lower protocol levels (e.g., transport or non-access stratum (NAS) protocol level) which could complicate S&F and delay sending of MO data by a UE 102 and sending of MT data by a remote endpoint 116. Instead, a UE 102 may access an SV 104 and starting sending MO data in S&F mode almost immediately without any extra delay.

[0051] Sending or receiving data at an application level, as referred to herein, may mean that the data is sent or received at a top application protocol layer. When an element El sends data to another element E2 in a communications system, it is common for a layered set of communication protocols (e.g., the ISO 7 layer set) to be used to transfer the data. Lower layers support transport, error detection and correction, session management and other functions well known in the industry. The top application protocol layer typically defines and supports data formatting and coding and may provide additional control information to identify various aspects of the data as well as source and destination addresses in some cases. Sending or receiving data at an application level could then mean supporting all protocol layers used for the transfer. This could exclude relaying or forwarding data at a lower protocol layer (e.g., transport layer) where higher protocol layers need not be supported.

[0052] A spacer vehicle operator (SVO) may support S&F mode for UEs that have a subscription with the SVO. The subscription may be on behalf of the UE’s Home PLMN (HPLMN) with the SVO acting as an Equivalent HPLMN (EHPLMN). Due to regulations, the SVO may only indicate support for serving PLMNs in a country where an SV 104 is currently providing coverage. This may lead to a UE obtaining S&F access via a VPLMN (e.g., an AT&T® subscriber in northern Canada, and also subscribed to an SVO, accesses an SV indicating support for Telus® as the serving PLMN and not AT&T). As an alternative, an SVO may act as an PLMN operator and may provide service directly to a UE, which sees the SVO as a PLMN to which access is allowed by the UE’s HPLMN.

[0053] FIG. 2 shows an example communication system 200 in which an SV 104 provides store and forward support to enable a UE 102 to send and receive information to remote endpoints 116 while the SV 104 provides a service link 101 to the UE 102 but does not have a feeder link 103 to a ground PLMN. An SV 104 here may be referred to synonymously as either a space vehicle or a satellite. Communication system 200 may be part of communication system 100 with like entities indicated using the same labels. In communication system 200, the SV 104 supports 5G NR access by the UE 102 and includes an NR radio access network (NG-RAN) function (e.g., 205) and a 5G core (5GC) network function (e.g., 210), an endpoint proxy 240 and a satellite to ground station communication interface 242 for communicating with an NTN gateway 106. The NG-RAN function (e.g., 205) supports capabilities of a terrestrial NG-RAN in supporting access by UE 102 to the SV 104 using NR. The 5GC function 210 supports capabilities of a terrestrial 5GC in supporting all network capabilities to enable 5G access by the UE 102 to the SV 104. The NG-RAN function 205 may include functions of a base station, such as a gNB, as described later for a ground PLMN 108. The 5GC function 210 may include functions of a terrestrial 5GC as described later and may include a number of 5GC functional elements, such as an Authentication Server Function (AUSF) 212, Access and Mobility Management Function (AMF) 214, Session Management Function (SMF) 216, User Plane Function (UPF) 218, Network Exposure Function (NEF) 220, Unified Data Management (UDM) 222, Policy Control Function (PCF) 224, Short Message Service (SMS) Function (SMSF) / SMS center (SMSC) 226, IP multimedia subsystem (IMS) 230, and Media Gateway (MGW) 232.

[0054] The functional elements of the NG-RAN 205 and 5GC 210 may not be separate physical elements as in a terrestrial NG-RAN and terrestrial 5GC but may instead be different logical functions or different processes running on a single computing system in the SV 104. However, from the perspective of the UE 102, the functional elements of the SV 104 may perform the same, or almost the same, functions as functions performed by elements of a terrestrial 5G-RAN and terrestrial 5GC, and the communications and signaling between the UE 102 and the SV 104 may exactly or almost exactly correspond to signaling between a UE 102and a terrestrial NG-RAN and terrestrial 5GC. Thus, the functions performed by each of the AUSF 212, AMF 214, SMF 216, UPF 218, NEF 220, UDM 222, PCF 224, SMSF / SMSC 226, IMS 230, MGW 232 may correspond to functions described later with reference to FIG. 4 for AUSF 412, AMF 414, SMF 416, UPF 418, NEF 420, UDM 422, PCF 424, SMSF / SMSC 426, IMS 430, MGW 432, where like named elements (e.g., AUSF 212 and AUSF 412) perform the same or similar functions.

[0055] The endpoint proxy 240 may emulate or mimic the communications behavior of a remote endpoint 116 from a perspective of the UE 102. With this, UE 102 can communicate with the endpoint proxy 240 in exactly the same way as the UE 102 could communicate with a remote endpoint 116. The endpoint proxy 240 substitutes for the remote endpoint 116 and receives any mobile originated data and service information sent by the UE 102 and returns any responses to the UE 102 at a lower protocol level (e.g., a transport protocol level) to enable the mobile originated communication from the UE 102. This means that the UE 102 can originate communication to a remote endpoint 116 which is intercepted and stored by the endpoint proxy 240 in the same way as the UE 102 would originate communication to a remote endpoint 116 over a terrestrial PLMN or using an SV 104 in real time mode. The endpoint proxy 240 may be referred to as an endpoint proxy function because it may be a software of firmware function of the SV 104 and not a physical (e.g., hardware) component of the SV 104. It is to be understood that because the endpoint proxy 240 is a part of the SV 104, the actions of the endpoint proxy 240 are also actions of the SV 104. The UE 102 interaction with the endpoint proxy 240 is described later in more detail with reference to FIG. 3 and FIGs. 7-9.

[0056] The satellite to ground station communication interface 242 supports communication between the SV 104 and an NTN gateway 106 and an associated ground based store and forward center (SFC) 202. The satellite to ground station communication interface 242 is used to support a feeder link 103 and the signaling and procedures used between the satellite to ground station communication interface 242 and the SFC 202 may not be standardized and may be proprietary to a satellite vehicle operator.

[0057] FIG. 3 shows an example communication system 300 for supporting end to end communication in S&F mode between the UE 102 and one or more remote endpoints 116 using an SV 104, an SFC 202 and a ground PLMN 108. Communication system 300 may include all of communication system 200 and may correspond to communication system 100 with common elements in these communication systems indicated by the same labels.

[0058] Communication system 300 includes the SFC 202 shown in FIG. 2. The SFC 202 includes an NTN gateway 106 or is connected to an NTN gateway 106 in order to communicate with the satellite to ground station communication interface 242 in the SV 104. The SFC 202 includes a UE proxy 340. The UE proxy 340 can be similar to the endpoint proxy 240 in communication system 200 but instead of emulating the behavior of a remote endpoint 116,emulates the behavior of the UE 102 from the perspective of the remote endpoints 116. The UE proxy 340 stores mobile originated data and service information sent by the UE 102 which was originally stored by the endpoint proxy 240 in the SV 104 but which is subsequently transferred to the SFC 202 by the SV 104 when a feeder link 103 becomes available between the SV 104 and the SFC 202. The UE proxy 340 transfers the mobile originated data and service information to the remote endpoints 116 through the ground PLMN 108. The UE proxy 340 emulates the behavior of the UE 102 in accessing the ground PLMN 108 and subsequently transferring the mobile originated data and service information to the remote endpoints 116. If subsequent mobile terminated data and service information is transferred by the remote endpoints 116 towards the UE 102, this mobile terminated data and service information is stored initially in the UE proxy 340 and is later transferred to an endpoint proxy 240 in an SV 104 when a feeder link 103 becomes available to an SV 104 that will later provide a service link 101 to UE 102. The UE proxy 340 may be referred to as a UE proxy function because it may be a software of firmware function of the SFC 202 and not a physical (e.g., hardware) component of the SFC 202. It is to be understood that because the UE proxy 340 is a part of the SFC 202, the actions of the UE proxy 340 are also actions of the SFC 202. It is noted that SFC 202 can be any enhanced ground based server that provides such functions and may therefore be referred to by other names or as just “a server.” The synonymous names “store and forward center” (SFC) and “satellite store and forward center” (SSFC) are the terms used herein.

[0059] Although FIG. 2 shows SV 104 support of 5G NR access by a UE 102, alternative internal architectures for the SV 104 could support 4G LTE access, a future 6G access or other access types. For example, when the SV supports 4G LTE access, the NG-RAN 205 may be replaced by an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), the 5GC 210 may be replaced by an enhanced packet core (EPC) and the AMF 214, UPF 218 and UDM 222 plus AUSF 212 may be replaced by a Mobility Management Entity (MME), a serving gateway (SGW) plus packet data network gateway (PGW) and a Home Subscriber Server (HSS), respectively, which may support similar or the same functions as the AMF 214, UPF 218 and UDM 222 plus AUSF 212, respectively.

[0060] FIG. 3 shows two times T1 and T2. At time Tl, the SV 104 does not have a feeder link, and is providing a service link 101 to the UE 102 to enable the UE 102 to send mobile originated data and service information to the SV 104 and to enable the SV 104 to send mobile terminated data and service information to the UE 102. At time T2, the SV 104 does not have a service link to the UE 102, and has a feeder link 103 to the SFC 202 to enable the SV 104 to send mobile originated data and service information stored in the endpoint proxy 240 to the UE proxy 340 in the SFC 202 and to enable the UE proxy 340 in the SFC 202 to send mobile terminated data and service information back to the endpoint proxy 240 in the SV 104. The times Tl and T2 can be different with discontinuous feeder link support. In one example, timeT1 occurs initially when the UE 102 first starts to access an SV 104 in S&F mode; the time T2 then occurs later when the SV 104 has moved away from the location of the UE 102 and is able to access an SFC 202 associated with a ground PLMN 108. However, in another example, time T2 may occur first when the SV 104 sends mobile originated data and service information to the UE proxy 340 and SFC 202 sends mobile terminated data and service information to the endpoint proxy 240 in the SV 104. In that case, the SV 104 may move away from the location of the SFC 202 and may later provide a service link 101 to the UE 102 and send the mobile terminated data and service information received at time T1 from the SFC 202 to the UE 102 at time T2. Detailed procedures for these operations are described next.

[0061] As shown in FIG. 3, mobile originated (MO) and mobile terminated (MT) service and media data can be transferred between the UE 102 and endpoints 116 via an endpoint proxy 240 in the SV 104 and a UE proxy 340 in an SVO-operated SFC 202 which either connects to a ground based PLMN 108 as an NTN gateway 106 at a Uu level (referred to here as Option (a)), or as a gNB or Trusted Non-3GPP Gateway Function (TNGF) at an N2 level (referred to as Option (b)) or supports ground PLMN capability itself (referred to as Option (c)).

[0062] Each SV 104 internally supports all functions of a terrestrial NG-RAN and 5GC with respect to interaction with UEs 102. Each SV 104 thus supports functions of a gNB, AMF, SMF, UPF, UDM etc. and supports the Uu and N1 interfaces to a UE 102. These SV functions may interact internally according to 5GS interfaces and SBIs but may also bypass 3GPP protocols and procedures with proprietary equivalents. The UDM 222 function may be preconfigured with the identities, subscription information and security credentials for all UEs 102 subscribed to S&F mode with the SVO and its SVs 104. When no FL is available, an SV 104 may broadcast an indication of support for PLMNs allowed to provide S&F coverage at the locations covered by the SV 104 and with which the SVO has a business relationship and may indicate S&F mode in a System Information Block (SIB) 1 (SIB1). The PLMN Mobile Country Code(s) (MCC(s)) and Mobile Network Code(s) (MNC(s)) that are broadcast in the SIB1 can be the same as those broadcast for real time mode or may correspond to an MCC and MNO belonging to the SVO that are not necessarily broadcast for real time mode. UEs with an S&F subscription to the SVO and allowed to access a PLMN whose MCC and MNC are broadcast may then access the SV. UEs without S&F subscription or support, or that are not allowed to access any PLMN whose MCC and MNC are broadcast, may not attempt to access the SV 104 if S&F mode is recognized or may get rejected when attempting access otherwise.

[0063] For initial access of a UE 102 to an SV 104 operating in S&F mode where SVs 104 do not use or support Inter-satellite links (ISL), a UE 102 can perform standard RRC Connection establishment with the SV 104 (e.g., with the NG-RAN 205 element in the SV 104) and initial NAS Registration with the SV 104 (e.g., with the AMF 214 element in the SV 104). The UE 102 may then establish protocol data unit (PDU) sessions to the SV 104 (e.g., to theUPF 218 element in the SV 104) and perform IMS Registration (e.g., with the IMS 230 element in the SV 104). The SV 104 can support the initial access by UE 102 and these operations by behaving as an HPLMN or EHPLMN for the UE 102 from the UE 102 perspective. This could mean that an identity or identities for the UE 102 might need to be pre-configured in advance in the SV 104, for example in the UDM 222 element in the SV 104, along with security credentials for the UE 102. The UE 102 would also select and register with one PLMN advertised as supported by the SV 104.

[0064] The user of the UE 102 may then instigate “MO transactions” to send MO data and MO SMS, instigate outgoing IMS voice or other media calls, request Internet access or perform Email access. The SV 104 can simulate the remote endpoint 116 for each case via the endpoint proxy 240 in the SV 104 which may be created specifically for the UE 102 following the initial NAS Registration of the UE 102 with the SV 104. The endpoint proxy 240 can replace remote endpoints 116 and can accept and store whatever media and service data the UE 102 sends and any associated metadata (e.g., data network (DN) and IP addresses for PDU sessions, remote endpoint 116 addresses, transport protocol details) and can provide any replies at lower protocol levels (e.g., for TCP, NAS, session initiation protocol (SIP), and hypertext transfer protocol (HTTP)) to avoid UE 102 timeouts. The endpoint proxy 240 may receive data from, or related to, UE 102 via integration with certain network functions (NFs) in the SV 104 5GC 210 or by receiving data from NFs in the SV 104 5GC 210 over a standard service based interface (SBI) or over other interfaces from certain NFs (e.g., AMF 214, IMS 230, UPF 218). The endpoint proxy 240 may also store location and time of access information for the UE (e.g., geodetic latitude and longitude of UE 102 and time of NAS Registration). For example, the NG-RAN element (e.g., 205) of SV 104 may determine or obtain the location of UE 102 and transfer this to the AMF 214 element which in turn transfers this to the Endpoint Proxy 240.

[0065] The endpoint proxy 240 may provide replies to the UE 102 and the user of UE 102 indicating that S&F mode is in operation and indicating when MO communication from the UE 102 may reach the remote endpoints 116 and / or when replies from the remote endpoints 116 may be received back later by the UE 102. For example, for MO voice media sent by the UE 102, a pre-configured voice recording could be returned by the endpoint proxy 240 to the UE 102 and the user of UE 102 (e.g., at an application level) after a MO voice call is established by the UE 102 to the endpoint proxy 240 saying: “Communication is now in store and forward mode. Please record a message and hang up or press “0” for more options when done. Your message will be delivered in approximately X minutes and you may receive a reply in approximately X+Y minutes.” For Email access, the endpoint proxy 240 may prompt for a login / password and dates or senders of interest. For MO data, simplex operation may be supported (e.g., using a non-intemet protocol (non-IP), internet protocol (IP), user datagram protocol (UDP) plus IP (UDP / IP)) or duplex operation (e.g., using transmission control protocol(TCP) plus IP (TCP / IP)) in which the endpoint proxy returns responses at a transport level (e.g., returns an acceptance response to a request from the UE 102 for a new TCP connection) in order to allow the UE 102 to send MO data without transport protocol failure. Emergency voice calls may also be supported — but with some delay in reaching a Public Safety Answering Point (PSAP) remote endpoint 116.

[0066] For Internet access by the UE 102, the endpoint proxy 240 may return a preconfigured SV webpage in response to every Internet access and only return the correct webpage later as part of MT data. For example, if the UE 102 (or user of UE 102) enters “www.msn.com”, the endpoint proxy 240 could return an internal webpage stating “Your query to www.msn.com will be answered in approximately X minutes. Please retry your query then.” At a later time after the website has been accessed by the UE proxy 340 through the ground PLMN 108 and the website response has been received and uploaded to another SV 104 (see later) and the other SV 104 becomes accessible the UE 102, the UE 102 or user of UE 102 can retrieve the website response by reentering the query “www.msn.com.”

[0067] The UE 102 or the user of the UE 102 can continue a session with the SV 104 in S&F mode to initiate further MO transactions after which the UE 102 is de-registered by the SV 104 (e.g., by the UDM 222 element) before UE 102 access to the SV 104 will be lost (due to orbital motion of the SV 104). This can avoid maintaining a 5GC UE 102 registration state across different SVs 104 which could be complex, error prone and unnecessary. The SV 104 may not handoff the UE 102 to another SV 104 and the UE 102 may not attempt handover or cell change to another SV 104 which would not know about the registration state of the UE 102 in the previous SV 104 (without ISL). Cell change and handover of UE 102 can be avoided, for example, if each SV 104 broadcasts support of a single tracking area (TA) that is different to the TAs supported (and broadcast) by other SVs 104 and if all TAs except for the current TA of the currently accessed SV 104 are treated as forbidden TAs for the UE 102 by both the UE 102 and currently accessed SV 104. The SV 104 may also, or instead, inform the UE 102 that cell change is forbidden during the NAS Registration of UE 102 with SV 104.

[0068] After de-registering the UE 102 and due to orbital motion, the SV 104 would typically move away to where feeder link access is available to a suitable ground based PLMN 108. This may not happen immediately and, in some cases, the SV 104 may need to orbit the Earth several times before it has feeder link access available to an allowed serving ground based PLMN 108 for the UE 102. For example, the serving ground based PLMN 108 may be required by national regulations to be in the same country as the UE 102. All the MO media and service data and metadata previously sent by the UE 102 and stored by the SV 104 endpoint proxy 240 can then be copied (downloaded) (e.g., via a satellite to ground station communication interface 242 in SV 104 and an NTN gateway 106 connected to or part of SFC 202) to the SFC 202, and a UE proxy 340 can be created to manage and transfer this data to the remote endpoints 116 on behalfof the real UE 102. If the UE 102 registered in the SV 104 but did not instigate any MO transactions, just the presence of the UE 102 may be conveyed to the SFC 202 which can still result in creation of the UE proxy 340. The SFC 202 and UE proxy 340 then forward all of the MO media and service data to the remote endpoints 116 via the serving ground based PLMN 108 and may receive back MT media and service data then or later which is returned later to the UE 102.

[0069] In case SVs 104 support and use ISL, initial access by a UE 102 to an SV 104 with S&F mode can be more flexible than that just described without ISL. For the ISL case, the UE 102 can access multiple SVs 104 (e.g., with continuous SL availability), and the SVs 104 can use ISL to support UE 102 mobility to new SVs 104 via handoff or cell change. To manage this, each SV 104 can broadcast support for a different TA to force a NAS Registration Update from the UE 102 when performing cell change to a new SV 104. The current SV 104 then does not de-register the UE 102 if the UE 102 can either be handed off to another SV 104 or perform a cell change to another SV 104 before access to the current SV 104 is lost. An SV 104 may then only de-register the UE 102 if access to the UE 102 will be lost and if handover or cell change to another SV 104 by the UE 102 did not occur. For handover or cell change of the UE 102 to another SV 104, the complete UE 102 registration and connection state to the current SV 104 (e.g., for NAS, PDU sessions, IMS) and the endpoint proxy 240 state for all ongoing MO transactions of UE 102 are transferred by the current SV 104 to the new SV 104 using ISL (e.g., using ISL proprietary procedures). The endpoint proxy 240 state for completed MO transactions for UE 102 may only be transferred by the current SV 104 to the new SV 104 if the new SV 104 will reach a feeder link with access to the ground PLMN 108 before the current SV 104 will have feeder link access. This may result in a series of SVs 104 receiving MO media and service data from the UE 102 (at different times) and later accessing the SFC 202 with different (e.g., successive) endpoint proxy 240 states for the UE 102. Each of these SVs 104 then transfers its own endpoint proxy 240 state (including stored MO data from UE 102) to the SFC 202. Labels or tags can be assigned to different portions of MO data to avoid transferring information for MO transactions more than once (e.g., the SFC 202 may record transferred MO transactions and may only accept new ones).

[0070] As described previously, an SFC 202 may connect to a ground based PLMN 108 in three different ways: as an NTN gateway 106 at the Uu level (Option (a)), as a gNB or TNGF at the N2 level (Option (b)), or by supporting ground PLMN capability itself (Option (c)).

[0071] With Option (a), interaction between the SFC 202 and the ground based PLMN 108 may mimic real time UE 102 access to the ground based PLMN 108 (e.g., where UE 102 accesses the ground based PLMN 108 using an SV 104 in real time mode). The SFC 202 and UE proxy 340 then simulate the presence of the UE 102 by interacting with the ground based serving PLMN 108 as if the UE 102 was accessing a LEO or MEO SV 104 in real time. Thismay be done by simulating in the SFC 202 the presence of a virtual “stationary” SV 104 that provides coverage to all UEs 102 subscribed to S&F mode in an area where the ground based serving PLMN 108 provides S&F mode coverage via SVs 104. The SFC 202 could be part of an SVO owned NTN gateway 106 that is either used for both real time mode and S&F mode or may be dedicated just to S&F mode. The SFC 202 could interface to the ground based serving PLMN 108 as an NTN gateway 106 and could support all protocols (from the physical layer upwards) for existing NG-RAN and 5GC Uu and N 1 interfaces towards a gNB for the ground based serving PLMN 108, and could reproduce the UE 102 signaling and interaction needed to transfer the MO media and service data to the remote endpoints 116 via the ground based serving PLMN 108. The SFC 202 and UE proxy 340 could start by registering the UE 102 with the ground based serving PLMN 108 and could then set up any PDU sessions and perform any IMS Registration as performed earlier by the real UE 102 with the SV 104.

[0072] With Option (b), the SFC 202 connects to a 5GC in the ground based serving PLMN 108 as a base station, in this example a gNB, and could thus support the 5GC N2 and N3 interfaces which would avoid support of the physical layer Uu interface. The UE proxy 340 can also stay permanently in a CM CONNECTED state to avoid unnecessary paging and service requests from the ground based serving PLMN 108 5GC. As an alternative, an SFC 202 could connect as a TNGF for 5G non-3GPP access to the ground based serving PLMN 108 5GC, although this might not allow the provision of NR cell and NR TA information to the ground based serving PLMN 108 5GC.

[0073] With Option (c), the SFC 202 may comprise or may be part of the ground based serving PLMN 108. For example, the SFC 202 could be a server that supports serving PLMN interactions with other networks (e.g., Internet 112, PSTN 114, other PLMNs and networks 110) for S&F mode but may not support real time access by UEs 102. Alternatively, the ground based serving PLMN 108 could support real time access for UEs 102 via SVs 104 and / or terrestrial access by UEs 102. The SFC 202 then forwards the MO media and service data for the UE 102 to the remote endpoints 116 and may receive back MT media and service data replies using the N6, Mm and other external PLMN interfaces. With Option (c), a NAS registration or IMS registration of a UE 102 may not be performed with the ground based serving PLMN 108 but may only be performed with the UE 102’s HPLMN (when different to the ground based serving PLMN 108). In addition, the ground based serving PLMN 108 may be part of the same PLMN supported by each SV 104 when in S&F mode and may thus be owned and operated by the SVO for the SVs 104.

[0074] An SFC 202 and UE proxy 340 can interact with a Serving ground based PLMN 108 in similar ways with options (a) and (b). For example, the SFC 202 and UE proxy 340 can indicate a current serving TA identity (TAI) and a serving cell global identifier (CGI) for a UE 102 to a gNB 406 (Option (a)) or AMF 414 (Option (b)) that is based on (e.g., mapped from) alatest known geodetic location for the UE 102. For example, the UE 102 geodetic location can be mapped to a corresponding ground PLMN 108 serving TAI and serving CGI. The serving TAI and serving CGI for the UE 102 may be identifiers defined for the ground based PLMN 108 and may thus indicate to the ground based PLMN 108 (e.g., an AMF 414 or gNB 406) the actual last known location of the UE 102. Similarly, any IP addresses assigned to a UE 102 by an SV 104 (e.g., by an SMF 216 in the SV 104) can be mapped to other IP addresses for the UE 102 that are assigned by the ground based PLMN 108 (e.g., by an SMF 416 in the 5GC 310-1).

[0075] When a UE 102 is subscribed to S&F mode service from SVs 104 belonging to an SVO, the SFCs 202 for this SVO as well as the SVs 104 can be pre-configured with the UE 102 identifications(s) and security credentials. The SFC 202 (or UE proxy 340) can then treat the ground based PLMN 108 as a serving PLMN (unless the ground based PLMN 108 also belongs to the SVO when it can act as an HPLMN or EHPLMN for the UE 102) and, at least for Options (a) and (b), may perform NAS Registration and IMS Registration of the UE 102 with the ground based PLMN 108. The UE proxy 340 can then transfer MO data and service information received earlier from the endpoint proxy 240 in an SV 104 to the remote endpoints 116.

[0076] In the case of MO voice media, the UE proxy 340 may play a preconfigured voice message to a remote endpoint 116 before transferring voice media data of the UE 102 to the remote endpoint 116. For example, the preconfigured voice message might be: “This is a message from user ABC sent at time XYZ. After you have heard the message, you will be prompted to repeat the message, reply to the message or end the call.” The remote endpoint 116 (e.g., a user) may then provide a reply which is treated by the UE proxy 340 as a new MT voice message to be returned to the UE 102.

[0077] In the case of Internet access, the UE proxy 340 may provide a login if needed (and if provided by the UE 102 earlier), send out the Internet (e.g., HTTP) queries received earlier from the UE 102 and store any returned Internet (e.g., HTTP) webpages for later transfer to the UE 102.

[0078] For Email access, the UE proxy 340 may provide a login if needed (and if provided by the UE 102 earlier), query for Email, store any returned webpages and retrieve specific Emails according to earlier UE 102 preferences. Support of particular Email systems (e.g., Gmail) by SFC 202 may be needed for this.

[0079] When MO media and service data transfer is complete, the UE proxy 340 may remain in a CM CONNECTED state permanently (or at least until S&F support for UE 102 is no longer needed) to avoid later paging (e.g., by AMF 414 or gNB 406), though transition to IDLE state could also be allowed.

[0080] A more detailed illustration of Options (a), (b) and (c) is provided in FIGs. 4, 5 and 6, respectively, next.

[0081] FIG. 4 illustrates an example network architecture 400 capable of supporting satellite access for wireless communication for both real time and S&F modes (e.g., using 5G NR). Network architecture 400 may be an example of communication system 100 and may include communication systems 200 and 300. Although aspects of network architecture 400 are described using the example of 5G NR, the concepts presented herein may also be applied for other types of core networks. FIG. 4 illustrates a network architecture 400 with transparent SVs 104 in real time mode. A transparent SV 104 may implement frequency conversion and a radio frequency (RF) amplifier in both uplink (UL) and downlink (DL) directions and may correspond to an analog RF repeater. A transparent SV 104, for example, may receive uplink (UL) signals from served UEs 102 and may redirect the combined signals DL to an earth station (e.g., 106) without demodulating or decoding the signals. Similarly, a transparent SV 104 may receive a UL signal from an earth station (e.g., 106) and redirect the signal downlink to served UEs 102 without demodulating or decoding the signal. However, the SV 104 may frequency convert received signals and may amplify and / or filter received signals before transmitting the signals.

[0082] The network architecture 400 may include a number of UEs 102, a number of SVs 104-1, 104-2, 104-3 (collectively referred to herein as SVs 104), a number ofNTN gateways 106-1 to 106-3 (collectively referred to herein as NTN gateways 106), a number of NRNodeBs (gNBs) 406-1 to 406-3 (collectively referred to herein as gNBs 406) capable of communication with UEs 102 via SVs 104 and with SFCs 202 in S&F mode and that are part of an NG-RAN 305. The network architecture 400 is illustrated as further including components of a number of 5G networks including 5G Core Networks (5GCNs or 5GCs) 310-1 and 310-2 (collectively referred to herein as 5GCNs or 5GCs 310). FIG. 4 illustrates various components within 5GC1 310-1 that may operate with the NG-RAN 305. The 5GC2 310-2 and other 5GCs may include identical, similar or different components and associated NG-RANs, which are not illustrated in FIG. 4 in order to avoid unnecessary obfuscation.

[0083] The UE 102 may include and / or be referred to as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a Secure User Plane Location (SUPL) Enabled Terminal (SET), or by some other name. Moreover, UE 102 may correspond to a cellphone, smartphone, laptop, tablet, PDA, tracking device, navigation device, loT device, or some other portable or moveable device.

[0084] The UEs 102 are configured to communicate with 5GCs 310 in real time mode via the SVs 104, earth station (e.g., NTN gateway 106-3), and gNB 406-3. Access in real time mode to the 5G network is provided to UEs 102 via wireless communication between each UE 102 and a serving gNB 406-3, via an SV 104 and earth station (e.g., NTN gateway 106-3). The gNB 406- 3 may provide wireless communications access to the 5GCs 310 on behalf of each UE 102 using 5G NR.

[0085] The gNBs 406 in the NG-RAN 305 may communicate with an AMF 414 in 5GC 310- 1. For example, the gNBs 406 may provide an N2 interface to the AMF 414. An N2 interface between a gNB 406 and a 5GC 310 may be the same as or similar to an N2 interface supported between a terrestrial gNB and a 5GC 310 for terrestrial NR access by a UE 102 and may use a Next Generation Application Protocol (NGAP) between a gNB 406 and the AMF 414. The AMF 414 may support mobility of a UE 102 in real time mode, including radio cell change and handover and may participate in supporting a signaling connection to a UE 102 and possibly data and voice bearers for a UE 102.

[0086] The NEF 420 may be included in 5GC 310-1 (e.g., connected to the AMF 414). In some implementations, the NEF 420 may be connected to communicate directly with a remote endpoint 116. The NEF 420 may support secure exposure of capabilities and events concerning 5GC 310-1 and a UE 102 to a remote endpoint 116 and may enable secure provision of information from a remote endpoint 116 to 5GC 310-1.

[0087] The UPF 418 may support voice and data bearers for a UE 102 and may enable UE 102 voice and data access to other networks such as the Internet 112. The UPF 418 may be connected to gNBs 406. UPF 419 functions may include: external PDU session point of interconnect to a Data Network, packet (e.g., IP) routing and forwarding, packet inspection and user plane part of policy rule enforcement, Quality of Service (QoS) handling for user plane, downlink packet buffering and downlink data notification triggering.

[0088] As illustrated, the SMF 416 connects to the AMF 414 and the UPF 418. The SMF 416 may have the capability to control both a local and a central UPF within a PDU session. SMF 416 may manage the establishment, modification, and release of PDU sessions for a UE 102, perform IP address allocation and management for the UE 102, act as a Dynamic Host Configuration Protocol (DHCP) server for the UE 102, and select and control a UPF 418 on behalf of a UE 102.

[0089] The AMF 414 may normally support network access and registration by UEs 102 in real time mode, mobility of UEs 102, including radio cell change and handover and may participate in supporting a signaling connection to a UE 102 and possibly data and voice bearers for a UE 102. The role of an AMF 414 may be to register the UE during a registration process, as discussed herein. The AMF 414 may page a UE 102 (e.g., by sending a paging message via one or more radio cells in a tracking area in which the UE 102 is located).

[0090] The PCF 424 may support a unified policy framework to govern network behavior, provide policy rules to other NFs to enforce them, access subscription information relevant for policy decisions in a Unified Data Repository (UDR) and support PDU Set Handling.

[0091] The UDM 422 may support generation of 3GPP AKA Authentication credentials, user identification handling (e.g., storage and management of a Subscription PermanentIdentifier (SUPI) for each subscriber in the 5G system), de-concealment of privacy-protected subscription concealed identifier (SUCI), access authorization based on subscription data, MT- SMS delivery, and subscription management.

[0092] The AUSF 412 may support authentication of a UE 102 for 3GPP access and untrusted non-3GPP access and authentication of a UE for 102 a Disaster Roaming service.

[0093] An SMSF may support SMS transfer over NAS, SMS management subscription data checking and SMS delivery. An SMSF may interact with an SMSC via an SMS interworking Mobile Switching Center server (MSC) or gateway MSC to transfer MT SMS messages from a remote endpoint 116 to a UE 102 or transfer MO SMS messages from a UE 102 to a remote endpoint 116. In such cases (and others), the SMSC may act as the main relay point for SMS transfer and is typically located in the HPLMN for any UE originating an SMS message. FIG. 4 shows an SMSF / SMSC 426 which represents an SMSF, an SMSC or an SMSF combined with an SMSC.

[0094] The IMS 430 supports sessions between UEs 102 and remote endpoints 116 using SIP. The IMS 430 typically includes multiple SIP capable servers referred to as Call Session Control Functions (CSCFs), including a Proxy CSCF (P-CSCF), an Interrogating CSCF (I- CSCF), a serving CSCF (S-CSCF), and a Media Gateway Control Function (MGCF). The P- CSCF is typically the entry point to the IMS 430 for SIP messages exchanged between a UE 102 and the IMS 430. The functions performed by a P-CSCF can include forwarding a SIP Register request received from a UE 102 to an entry point (e.g., I-CSCF) in an IMS for the HPLMN of the UE 102, forwarding SIP messages received from a UE 102 to another SIP server (e.g., an S-CSCF), forwarding SIP requests and responses to a UE 102, and maintaining a security association between itself and each UE 102 (e.g., as defined in 3GPP Technical Specification (TS) 33.203).

[0095] An I-CSCF can be the contact point within the IMS 430 for all SIP connections destined to a UE 102 accessing ground PLMN 108. After a UE 102 sends a SIP Register message to a P-CSCF, the P-CSCF may typically forward the SIP Register message to an I- CSCF in the IMS for the HPLMN of the UE 102. The I-CSCF may then determine an S-CSCF for the UE 102 in the HPLMN IMS and forward the SIP Register message to this S-CSCF.

[0096] The S-CSCF performs session control services for UEs 102 and other UEs for which ground PLMN 108 is the HPLMN. It maintains a session state for support of the services. For SIP Registration, an S-CSCF may behave as a SIP Registrar as defined in International Engineering Task Force (IETF) Request for Comment (RFC) 3261. An S-CSCF may also act as a Proxy Server as defined in IETF RFC 3261 or as a User Agent as defined in IETF RFC 3261. An S-CSCF may be used to route a mobile terminated SIP call to a destination UE 102. In that case, the mobile terminated SIP call would have been initially routed to an S-CSCF in theHPLMN for the destination UE 102, and the S-CSCF would then use a previous SIP registration of the destination UE 102 to route the mobile terminated SIP call to a P-CSCF in the network serving the destination UE 102.

[0097] An MGCF may control the functions of a media gateway MGW 432. The MGW 432 can support translation of packet based media, for example voice over IP, to corresponding circuit switched based media, for example to circuit switched voice, for example, when a UE 102 originates a voice call over NR which needs to go through the PSTN 114 or when an incoming circuit switched voice call from the PSTN 114 arrives at PLMN 108 for delivery over NRto a UE 102.

[0098] As noted, while the network architecture 400 is described in relation to 5G technology, the network architecture 400 may be implemented to support other communication technologies, such as global system for mobile communications (GSM), wideband code division multiple access (WCDMA), LTE, 6G, etc., that are used for supporting and interacting with mobile devices such as a UE 102 (e.g., to implement voice, data, positioning, and other functionalities).

[0099] The communication system shown by the network architecture 400 has been described so far in terms of its support of real time access to the ground based PLMN 108 by UEs 102 accessing an SV 104 which then accesses the NTN gateway 106-3 which accesses the ground based PLMN 108 via the gNB 406-3. The communication system illustrated by the network architecture 400 can also support access by UEs 102 in store and forward mode via SVs 104. In this case, a UE 102 communicates with an SV 104 in store and forward mode as previously described, at a time when the SV 104 does not have feeder link access so the ground based PLMN 108. At a later time, SV 104 obtain feeder link access to the ground based PLMN 108 via access to an SFC 202 via an NTN gateway 106. The two SFCs 202 shown in FIG. 4 which support this are SFC 202-1 and SFC 202-2 which access gNB 406-1 and gNB 402-2. With the option (a), the SFCs 202-1 and 202-2 access gNBs 406-1 and 406-2 by emulating the communication signaling of an NTN gateway 106. The gNBs 406-1 and 406-2 may not need to be aware that they are communicating with SFCs 202 rather than communicating for real time mode with an SV 104 via an NTN gateway 106-1 or 106-2. From the perspective of the ground based PLMN 108 including the gNBs 406 and 5GC 310-1, it can appear that a UE proxy 340 and SFC 202-1 or 202-2 are a UE 102 accessing an SV 104 in real time mode via an NTN gateway 106. The access by an SFC 202 to a gNB 406 is what distinguishes the option (a) from the two other options. Both the gNBs 406 and elements in the 5GC 310-1 can treat the signaling from the UE proxies 340 as if it originates from the UE 102, which means that there may be no new impacts to the gNBs 406 or to elements of the 5GC 310-1.

[0100] FIG. 5 shows a diagram of an example network architecture 500 supporting NTN access (e.g., using 5G NR, as presented herein). While the network architecture 500 isdescribed in relation to 5G technology to illustrate the concept, the network architecture 500 may also be implemented to support other communication technologies. The network architecture 500 shown in FIG. 5 is similar to that shown in FIG. 4, like designated elements being similar or the same. FIG. 5, however, illustrates a network architecture that supports the option (b) where SFCs 202-1 and 202-2 connect to the 5GC 310-1 in the ground base PLMN 108 and not to the NG-RAN 305. That means that the SFCs 202-1 and 202-2 can emulate the behavior of a gNB 406 and connect to the AMF 414 and UPF 418 in the 5GC 310-1 in the same way as a gNB 406. For example, the SFCs 202-1 and 202-2 could support the NGAP protocol when accessing the AMF 414. The SFCs 202 and UE proxy 340 may emulate the signaling and procedures that would be performed by a gNB 406 for a UE 102 that is accessing the ground based PLMN 108 in real time mode via an SV 104 and the gNB 406.

[0101] FIG. 6 shows a diagram of an example network architecture 600 supporting NTN access (e.g., using 5G NR, as presented herein). While the network architecture 600 is described in relation to 5G technology to illustrate the concept, the network architecture 600 may also be implemented to support other communication technologies. The network architecture 600 shown in FIG. 6 is similar to those shown in FIGs. 4 and 5, like designated elements being similar or the same. FIG. 6, however, illustrates a network architecture that supports the option (c) where the SFCs 202-1 and 202-2 are part of the ground base PLMN 108. There can be two alternative types of support here. In the case of SFC 202-1, the SFC 202-1 can be part of the ground based PLMN 108 which also includes the 5GC 310-1 and possibly an NG-RAN 305 that is not shown in FIG. 6. The SFC 202-1 may then connect to elements in the 5GC 310-1 such as the AMF 414 and UPF 418 and possibly other elements also. The signaling and procedures used on the links between the SFC 202-1 and other elements in the ground based PLMN 108 such as AMF 414 and UPF 418 may not be standardized but may be proprietary to the ground based PLMN 108. However, the SFC 202-1, the UE proxy 340 contained within it and other elements in the ground based PLMN 108 can enable the UE proxy 340 to communicate with remote endpoints 116 via other networks 110, the Internet 112 and the PSTN 114 in the same way as a UE 102 would communicate with the remote endpoints 116 when accessing the ground based PLMN 108 using an SV 104 in real time mode. The SFC 202-2 corresponds to and supports a complete ground based PLMN 108 and may not contain a 5GC 310 or NG-RAN 305. The SFC 202-2 may use proprietary signaling and procedures internally and to communicate with any other elements in the ground PLMN 108 and may not necessarily support UE 102 access in real time. The SFC 202-2 may connect to other networks 110, the Internet 112 and the PSTN 114 as if it was a ground based PLMN 108 supporting real time access by UEs 102.

[0102] Although FIGs. 4, 5 and 6 show ground based PLMN 108 support of 5G NR, alternative architectures for the ground PLMN 108 could support 4G LTE access, a future 6Gaccess or other access types. For example, when the ground PLMN 108 supports 4G LTE access, the NG-RAN 305 may be replaced by an E-UTRAN, the 5GC 310 may be replaced by an EPC and the AMF 414, UPF 418 and UDM 422 plus AUSF 412 may be replaced by an MME, an SGW plus PGW and HSS, respectively, which may support similar or the same functions as the AMF 414, UPF 418 and UDM 422 plus AUSF 412, respectively.

[0103] Return of MT Data from remote endpoints 116 to a UE 102 in S&F mode is described next. For the options (a), (b) and (c), MT data can be provided to the SFC 202 and stored in the UE proxy 340 for the UE 102 which simulates continuous availability of the UE 102. With the options (a) and (b), the SFC 202 could need to recognize and respond to Paging messages from the serving ground based PLMN 108 unless the UE proxy 340 remains in CM CONNECTED state. Periodically, the SFC 202 uploads (e.g., by proprietary means) MT media and service data for the UE 102 to one or more SVs 104 which will later provide coverage at the UE 102 location. The SFC 202 may upload itself or many upload via a different SFC 202 if permitted by regulation and if a different SFC 202 can access suitable SVs 104 before the SFC 202 can.

[0104] An SV 104 endpoint proxy 240 previously used for a UE 102 for transfer of MO data from the UE 102 might be reused by an SFC 202 to transfer MT data to the UE 102. Alternatively, an endpoint proxy 240 in an SV 104 might be created specifically to transfer MO data from the UE 102 or transfer MT data to the UE 102 and might be erased from the SV 104 when transfer of MO data or MT data for the UE 102 is no longer needed.

[0105] The UE 102 may access available SVs 104 at any time to send MO data and / or to receive any available MT data, but the user may be advised (e.g., by an endpoint proxy 240) when to expect MT data replies to any MO data that was sent.

[0106] When the UE 102 accesses another SV 104 in S&F mode, the UE 102 can register with the SV 104 as described previously. The SV 104 can then look to see if there is any new MT data to send to the UE 102. If so, there may already be an endpoint proxy 240 for the UE 102 in the SV 104 or, if not, the SV 104 can create an endpoint proxy 240 for the UE 102. ISL may be used (if supported) by the SV 104 if there is no MT data for the UE 102 to handoff the UE 102 to another accessible SV 104 if there is MT data for the UE 102 in this SV 104, or ISL may be used to retrieve the MT data for the UE 102 from the other SV 104 if the other SV 104 would provide no or poorer access to the UE 102. To transfer the MT data to the UE 102 from the SV 104, and in the case of MT voice, the SV 104 or endpoint proxy 240 can establish an MT SIP call to the UE 102 from the endpoint proxy 240 which may playback voice messages to the user of UE 102 one at a time and with possibly some type of menu control (e.g., to allow the user of UE 102 to repeat and / or answer the MT voice messages).

[0107] For MT SMS, all MT SMS messages can be delivered to the UE 102 (e.g., using SMS over NAS or SMS over IMS) using existing standards.

[0108] For Internet and Email access, the user of UE 102 may reenter the original Internet address (e.g., a uniform resource identifier (URI)) and / or Internet (e.g., HTTP) query, after which a webpage received earlier from the remote endpoint 116 and forwarded by the SFC 202 to the SV 104 can be provided to the UE 102.

[0109] For Email access, the user of UE 102 can also retrieve specific Emails by repeating previous MO Email queries if the UE proxy 340 in the SFC 202 was able to access and retrieve Email from the remote endpoint 116 (e.g., an Email server) based on the UE 102 original Email query.

[0110] For simplex MT data (e.g., UDP / IP), any MT data replies from remote endpoints 116 can be provided to the UE 102 using any PDU session setup by the UE 102 that matches a PDU session setup by the UE 102 earlier to originally transfer any MO data — and using any new IP address now assigned to the UE 102.[OHl] The session between the SV 104 and UE 102 may end when all MT data to the UE 102 and any new MO data from the UE 102 have been transferred. De-registration of the UE 102 or transfer of the UE 102 to a new SV 104 can also occur as described previously.

[0112] The SV 104 may later update the SFC 202 with the delivery status of the MT data to the UE 102 and may provide any new MO data received from the UE 102. The SFC 202 may then remove the delivered MT data from all SVs 104 to which this data was earlier provided for delivery to the UE 102. ISL may also be used (if supported) to delete delivered MT data from SVs 104.

[0113] In some aspects, the procedures just described for return of MT data to a UE 102 may be performed without special user action except for MT data related to Internet and Email access. However, the user of UE 102 may then have no control over when MT data may be returned and risks receiving the same MT data multiple times from different SVs 104. In an improved method of delivery, the SV 104 (e.g., endpoint proxy 240) first sends an indication to the UE 102 that MT data is available for delivery to the UE 102. This indication could be included in an SMS message or UDP / IP message that indicates the different types of MT media and service data available in the SV 104 for the UE 102 and with a label and time of original receipt by the serving ground based PLMN 108. The user can then inspect the SMS message (or UDP / IP message) using an application (sometimes referred to as an ”App”) and then, if the MT data is new (and not yet delivered to the UE 102), the user may access an application on the SV 104 (e.g., that may be part of the endpoint proxy 240) to instigate and control delivery of the MT data (e.g., by playing voice messages one at a time, triggering delivery of all SMS and UDP / IP messages that were not yet delivered and looking at any returned Internet web pages and Email). Alternatively, an application on the UE 102 (that can be accessed by the user of UE102) could autonomously inspect the MT SMS or UDP / IP message and verify if (at least some of) the MT data is new and then alert the user only if (at least some of) the MT data is new.

[0114] To support transfer of further MO data from a UE 102 and further MT data to a UE 102, a UE 102 can be allowed to send further MO data at any time to an available SV 104 as described previously, where the MO data is subsequently transferred to the SFC 202 and then forwarded to the remote endpoints 116 as also described previously. Similarly, further MT data for the UE 102 may arrive at the UE proxy 340 in the SFC 202 at any time from one or more remote endpoints 116. The new MT data can then be uploaded by the SFC 202 to suitable SVs 104 that will later provide coverage to a last known location of the UE 102 or an expected new location of the UE 102. The new MT data may be added to any previous still undelivered MT data for the UE 102 that is already in the SV 104. The UE 102 then retrieves the new MT data, as described previously, but may selectively retrieve only MT data not previously received by the UE 102.

[0115] To support in order delivery of MO data to remote endpoints 116 and in order delivery of MT data to a UE 102, extra procedures may be used. For example, a UE 102 may access SVs 104 in a certain order (e.g., SV1, SV2, SV3, SV4, etc.). Due to orbital differences, SVs 104 accessed earlier by the UE 102 may arrive at and obtain a feeder link to SFC 202 later than other SVs 104 that were accessed later by the UE 102. For example, the order of SV 104 arrival at and feeder link access to SFC 202 might be (in this example) SV3, SV1, SV4, SV2, where SV3 and SV4 have arrived earlier. This could lead to MO related data being sent to the remote endpoints 116 and to MT related data being received by the UE 102 in a different order than sent by the UE 102 and by the remote endpoints 116, respectively. A UE proxy 340 or an SFC 202 could correctly order MO data received from an SVx (e.g., where x = 1, 2, 3 or 4 in this example) by only forwarding the MO data to the remote endpoints 116 after accessing all SVs 104 that were accessible earlier at the UE 102 than SVx and forwarding any MO data from these SVs 104 first. In the previous example, this can mean that when SV3 arrives at SFC 202, UE proxy 340 or SFC 202 delays forwarding any MO data from UE 102 provided by SV3 until both SV1 and SV2 have arrived at SFC 202. Similarly, when SV4 arrives at SFC 202, UE proxy 340 or SFC 202 can delay forwarding any MO data from UE 102 provided by SV4 until SV2 has arrived at SFC 202. An SFC 202 may know the order in which SVs 104 will arrive at SFC 202 and be visible at a known last location or expected new location of UE 102 from orbital related data for SVs 104 which may be pre-configured by an S VO in SFC 202.Alternatively, in some aspects, a UE 102 may indicate to an SV 104 the identities of previous SVs 104 to which the UE 102 has previously sent MO data, and when this SV 104 is accessed by the SFC 202, the SFC 202 can verify whether these previous SVs 104 have already been accessed by SFC 202 or will only be accessed later by the SFC 202. This variation may alsoavoid an SFC 202 waiting for the arrival of an SV 104 to which the UE 102 did not send any MO data.

[0116] Similarly, a UE proxy 340 or an SFC 202 could correctly order MT data for UE 102 received from remote endpoints 116 by uploading the MT data to any SVx such that (i) the MT data includes all MT data uploaded earlier to all SVs 104 that will only become accessible to the UE 102 after SVx unless (ii) this MT data was uploaded to another SV 104 that will become available to UE 102 before SVx. As an example, an SFC 202 has access to SVs 104 in the order SV1, SV2, SV3, SV4, and the SVs will later become accessible to the UE 102 in the order SV3, SV1, SC4, SV2. The SFC 202 may then upload currently available MT data to SV3 such that the MT data includes all data previously uploaded to SV1 and SV2. Similarly, SFC 202 may upload currently available MT data to SV4 but need not include data previously uploaded to SV2 as this data was also uploaded to SV3 which becomes available to UE 102 before SV4. If the UE 102 later receives MT data from SV3 first, it can treat the MT data received later from SV 1 and SV2 as a duplicate and not provide this MT data to the user. If the UE 102 does not access SV3 first, the data from SV1 and SV2 will be then delivered in the right order (though SV3 data would be missed).

[0117] As a UE 102 may miss accessing some SVs 104 (e.g., if the UE 102 is not powered on or does not have visibility of these SVs 104), an SFC 202 may support some redundancy in MT data delivery by including MT data already uploaded to some SVs 104 accessible earlier to the UE 102 to other SVs 104 that will be accessible later to UE 102, in order to avoid UE 102 not receiving this MT data. For the previous example, where SVs will become accessible to the UE in the order SV3, SV1, SV4, SV2, the MT data uploaded to SV1 can also be uploaded to SV2 in case the UE misses access to SV1 (and SV3) and the MT data uploaded to SV1, SV2 and SV3 can also be uploaded to SV4 in case the UE misses access to SV1 and SV3.

[0118] Supporting in order delivery of MO data and MT data as just described may add some extra delay in delivering the MO and MT data which may not be preferred, in some circumstances. A UE 102 may thus be given the choice of either minimizing delay by not performing in order MO and MT data delivery or performing in order MO and MT data delivery with some extra delay. The choice could be part of the UE 102 subscription to the SVO and preconfigured in an SFC 202 or could be indicated by the UE 102 when registering with an SV 104 and then transferred to the SFC 202. The choice could apply to both MO and MT data or could be different for MO versus MT data delivery.

[0119] Some SVs 104 may support access by UEs 102 in both real time mode and S&F mode. Transition between real time mode and S&F mode may then occur as follows. When an SV 104 loses all feeder links, it may transition from providing real time access to providing S&F access to UEs 102. All previously registered UEs 102 for real time access may then stay registered with their current serving PLMNs and may either be handed off to another SV 104that has a feeder link or may enter a coverage gap in which real time access is not possible. The SV 104 could then cease indicating support for PLMNs in real time mode and start indicating support for the same or other PLMNs that are allowed and able to provide coverage for S&F mode at the current SV location. The SV 104 could also include an indication of S&F mode in a SIB1. A UE 102 that is not subscribed to S&F mode may then remain in real time mode and may not access the SV 104. However, another UE 102 which is subscribed to S&F mode could chose to either remain in real time mode (and not access the SV 104) or switch to S&F mode and access the SV 104 in S&F mode. When switching to S&F mode, the UE 102 could locally de-register for real time mode and then perform an new initial Registration with the SV for S&F mode.

[0120] On the ground based PLMN 108 side, UEs 102 may have been previously registered in the ground based PLMN 108 for real time mode access from an SV 104. If the SV 104 accessed by one of these UEs 102 switches to S&F mode and the UE 102 remains in real time mode (and thus in a coverage gap), the ground based PLMN 108 can regard this UE 102 as out of coverage and in an IDLE state. However, if the UE 102 registers with an SV 104 for S&F mode, then the new registration may impact the previous registration in the ground based PLMN 108 for real time mode. With SFC 202 to ground based PLMN 108 interaction according to the option (c) described previously, an SV 104 can indicate to the SFC 202 and ground based PLMN 108 (if this PLMN is the same for both real time and S&F modes) that the previous registration for real time mode is no longer valid and may provide new registration information for UE 102 for S&F mode.

[0121] With SFC 202 to ground based PLMN 108 interaction according to the option (a) or the option (b) described previously, when a UE proxy 340 is first created in an SFC 202 for a UE 102, the UE proxy 340 would normally perform Initial Registration of the UE 102 with the serving ground based PLMN 108 (e.g., as described previously). The Initial Registration then proceeds and when notified to a UDM in the HPLMN for the UE 102 can cause the UDM to implicitly de-register the UE 102 for the previous real time access. To avoid possible errors, a new indication could be included in the UE 102 Initial Registration for S&F mode (e.g., as shown in FIG. 8) indicating that the Initial Registration is for S&F mode with the indication forwarded to the UDM. When the UDM receives this indication, the UDM can perform an implicit de-registration of UE 102 for real time mode.

[0122] Transition from S&F mode to real time mode for an SV 104 and UE 102 may also need to be supported. The transition from S&F mode back to real time mode can be the reverse of transition to S&F mode. Thus, when an SV 104 re-acquires a feeder link, it can transition from providing S&F access to providing real time access to UEs 102. Before making this transition, the SV 104 can indicate to UEs 102 accessing the SV 104 in S&F mode that the current SV 104 radio cell(s) will become unavailable (e.g., some time in advance to allow UEs102 to complete any MO and MT transactions for S&F mode). The SV 104 may then deregister all registered UEs 102 for S&F mode before exiting S&F mode. When the SV transitions to real time mode, any S&F indication in a SIB1 can be removed. UEs 102 which were using S&F mode may then remain in S&F mode and access other SVs providing S&F mode or switch to real time mode. When switching to real time mode, the UE 102 can perform a new Initial NAS Registration with the SV 104 (e.g., with a real time indication) which may allow the UDM in the HPLMN of the UE 102 to implicitly de-register the UE for S&F mode.

[0123] It is noted that some UEs 102 may be at a geographic location where visible SVs 104 do not have access to a feeder link. These UEs 102 would thus not see a transition between real time and S&F modes as visible SVs 104 would continuously be in S&F mode. The same can apply to UEs 102 at a geographic location where visible SVs 104 have continuous access to a feeder link. These UEs 102 would similarly not see a transition between real time and S&F modes as visible SVs 104 would continuously be in real time mode. Only UEs 102 at a location where SVs 104 only sometimes have access to a feeder link would see transitions between real time and S&F modes.

[0124] It is also noted that although an SV 104 might support both real time and S&F modes simultaneously (when a feeder link is available), this might complicate SV 104 implementation and degrade real time mode if the SV 104 first inspects all UL transmission, removes any signaling and messages associated with S&F mode, and then transparently forwards the rest of the signaling using the feeder link.

[0125] Dual registration of a UE 102 for S&F mode and real time mode may be supported in some cases. A UE 102 in an area where SVs 104 have feeder links for only a portion of total accessibility time might benefit from being able to use both S&F mode and real time mode without having to either de-register from real time mode while using S&F mode or de-register from S&F mode while using real time mode. This could lead to dual registration of a UE 102 in the same serving ground based PLMN 108 and possible in the same AMF 414 in some cases and to two sets of PDU sessions and IMS registrations. This may involve some new impact but could include some aspects similar to simultaneous dual NAS Registration on different radio access technologies (RATs), such as 3GPP NR and non-3GPP or 3GPP NR and 3GPP LTE.

[0126] Local communication between UEs 102 may also be supported in S&F Mode by an SV 104. With this, UEs 102 able to access the same SV 104 at the same time in S&F Mode could be allowed to communicate directly through the SV 104 without communication via a serving ground based PLMN 108 and SFC 202. Real time mode communication can be supported by first verifying if a destination address for an MO transaction initiated by a UE 102 in S&F mode corresponds to another UE 102 also currently registered in the SV 104. If so, real time communication can be supported by the SV 104 (e.g., NG-RAN 305 and 5GC 310) acting as a serving PLMN, serving HPLMN or serving EHPLMN for both UEs 102.

[0127] It is noted that the terms “MO data” and “MO service data,” may be used here generically to refer to any type of mobile originated data sent by a UE 102 to an SV 104 in S&F mode for later transfer to remote endpoints 116. Likewise, the terms “MT data” and “MT service data” may be used generically to refer to any type of mobile terminated data sent to a UE 102 by an SV 104 in S&F mode, where the MT data was originally sent by remote endpoints 116. The types of MO and MT data can include SMS, SIP media (e.g., voice, text or video), Emails, Internet (e.g., HTTP) queries and responses and plain MO and MT data such as UDP / IP, TCP / IP or IP packets or non IP data.

[0128] Some additional enhancements are next described that may be supported for UEs 102 accessing SVs 104 in S&F mode as described previously for FIGs. 1 to 6.

[0129] As described above, a satellite operating in store and forward (S&F) mode contains the functionally of a RAN node (eNB or gNB) plus a core network (CN) and has an on board proxy for remote endpoints, referred to as an endpoint proxy. A UE with satellite access capability sees a satellite in S&F mode as providing access to a PLMN (that is on board the satellite) and applications on the UE and the user of the UE interact with the endpoint proxy that enables data and voice transfer to occur as if performed end to end. S&F mode can support applications that are able to operate in a simplex or half duplex mode, such as SMS, control plane (CP) or user plane (UP) data transfer, one way voice message transfer, or HTTP (e.g., Internet) queries and responses.

[0130] A satellite without a feeder link may operate in S&F mode. In this mode, an S&F indication is broadcast in SIB1 along with a PLMN ID (e.g., an MCC and an MNC) for an operator of the satellite. The PLMN ID may be per country (e.g., where a different PLMN ID is broadcast in each country or where the PLMN ID is an international ID with a 9xx MCC). UEs that do not support S&F mode do not access the satellite or get rejected if they do. UEs that support S&F mode and that are allowed to access the broadcast PLMN may access the satellite using satellite access capability (e.g., may establish an RRC signaling connection and perform a NAS Attach (4G) or Registration (5G) with a new indication of S&F capability). The on board satellite CN includes a UDM or HSS that can support access for UEs as described above. UEs may also establish PDN connections or PDU sessions (to the on board satellite CN) and perform IMS Registration (to an on board satellite IMS).

[0131] The UE can then perform MO transactions such as sending short message service (SMS) messages, sending data (e.g., using IP or non-IP protocols), establishing SIP sessions and sending SIP media (e.g., voice, video, text) or sending HTTP queries. Each MO transaction is sent to the on board endpoint proxy which stores transaction data (e.g., SMS, data, voice, HTTP queries) and associated protocol and remote endpoint data and returns responses at a transport and application level that are necessary to allow correct transport and application protocoloperation, avoid timeouts and enable a user (if participating) to be aware of the one way communication status. For example, in case of a user, a preconfigured SMS, voice or HTTP reply might be returned indicating when an SMS message, voice message or HTTP query sent by the user may reach the remote endpoint.

[0132] Shortly before satellite coverage is lost, the satellite detaches or de-registers the UE. If there is a radio link failure before this, the satellite and UE both perform a local detach or local de-registration. If the UE can access a new satellite before coverage is lost, a satellite may transfer UE status including data for ongoing transactions to the new satellite using ISL, and the UE then performs a handover.

[0133] After the UE loses coverage and when the satellite obtains a feeder link to a ground based PLMN allowed to support the UE at its previous location, the satellite (or the on board endpoint proxy) transfers all of the stored data for the UE MO transactions to a ground based server, referred to as an S&F center (SFC). The SFC may belong to the satellite operator or to the Mobile Network Operator (MNO) for the ground based PLMN. The SFC contains a proxy for the UE, referred to as a UE proxy, that forwards the voice or data for each MO transaction to the associated remote endpoint and is able to receive and store voice and data for MT transactions that may be returned by the remote endpoints to the UE.

[0134] The UE proxy in the SFC may first perform a NAS Attach or Registration on behalf of the UE with the PLMN. This can occur at an Uu or N1 level (e.g., as in Option (a) in FIG. 4) where the SFC connects to an eNB or gNB for the PLMN and emulates the behavior of an NTN gateway that has real time satellite access to the UE. Alternatively, the SFC may connect to the CN of the PLMN at an S 1 or N2 level (e.g., as in Option (b) in FIG. 5) and emulate the behavior of an eNB or gNB that has real time satellite access to the UE. Alternatively, the SFC may be integrated with the ground based PLMN (e.g., as in Option (c) in FIG. 6), which can avoid use of standardized signaling and procedures between the SFC and the PLMN.

[0135] Subsequent to NAS Attach or Registration and establishment of any PDN connections or PDU sessions and IMS Registration, the UE proxy initiates MO transactions corresponding to those initiated earlier by the UE which forwards the MO voice and data to the remote endpoints. The SFC also interacts with remote endpoints to receive and store voice and data for MT transactions and, similar to the endpoint proxy in the satellite, can return responses to the remote endpoints at a transport and application level that are necessary to allow correct transport and application protocol operation, avoid timeous and enable a user at a remote endpoint to be aware of the one way communication status. For example, in the case of a user, a preconfigured SMS or voice reply might be returned indicating when an SMS message or voice message may reach the UE.

[0136] The SFC and UE proxy can simulate continuous reachability of the UE and possibly remain permanently in a Connection Management (CM) Connected state. The MT transaction data received and stored by the UE proxy is transferred to one or more satellites that are expected to later provide coverage to the UE. When the UE accesses such a satellite, the endpoint proxy in the satellite can transfer the MT transaction data to the UE along with supporting any new MO transactions from the UE.

[0137] Satellites carrying MT transaction data for the UE do not page the UE but instead rely on the UE instigating access. However, after initiating MO transactions, a UE or user can be advised when a satellite with MT transaction data in reply will first become available and / or can be provided with coverage data for satellites to facilitate access.

[0138] As described above, an MO or MT transaction can correspond to: transfer of one SMS message (e.g., using NAS or IMS), transfer of a set of data to or from one remote endpoint using Cellular loT (CIoT) or User Plane (UP), SIP session establishment to or from one remote endpoint, one way transfer of media (e.g., voice, video and / or text) followed by SIP session release, or an HTTP request and / or response where the response may be preconfigured.

[0139] FIG. 7 shows an example signaling flow 700 that in more detail shows how MO and MT transactions can be supported between a UE and remote endpoints in S&F mode.

[0140] At stage 1 in FIG. 7, a satellite 104 operating in S&F mode broadcasts an S&F indication and a PLMN ID for an operator of the satellite 104 in a SIB 1. At stage 2 and at a time Tl, a UE 102 that supports S&F mode obtains an RRC Connection and sends a NAS Attach Request (for 4G access) or NAS Registration Request (for 5G access). The UE 102 also includes an indication of its S&F capability. The MME / AMF of the satellite 104 will reject the Attach or Registration if the S&F indication is not included. The rest of the NAS Attach or NAS Registration procedure may occur as for normal 4G or 5G terrestrial access or real time satellite access but with security and access to subscription data supported as described below. If the UE 102 has data to transfer over UP or SIP media data to transfer, the UE 102 establishes PDN connection(s) or PDU session(s) and, for SIP media, performs an IMS Registration with security as described below. All UE interactions are with the RAN 205, CN 210 and endpoint proxy 240 in the satellite 104 and do not involve any ground based entities. Security for a Registration, Attach, or IMS Registration is described below in connection with FIGs. 8 and 9.

[0141] At stage 3, the UE 102 instigates one or more MO transactions to the satellite 104 on board CN 210. The on board CN 210 forwards MO transaction data and protocol and signaling information, applicable to the remote endpoint(s) 116, to the endpoint proxy 240, which stores this information and returns any responses to the UE 102 necessary to ensure correct operation of transport level and application level protocols. The endpoint proxy 240 may also return preconfigured application level messages to a user of the UE 102 to indicate S&F operation.For example, a preconfigured voice message may indicate an expected delay in forwarding MO transactions to the remote endpoint(s) 116 and may further indicate a later time when MT transaction responses may be received back at the UE 102 from the remote endpoint(s) 116. The endpoint proxy 240 may also request and obtain the location of the UE 102 (e.g., location of UE 102 at time Tl).

[0142] At stage 4, shortly before the UE 102 will lose satellite coverage, the satellite 104 performs a NAS Detach or De-registration of the UE 102. If satellite coverage is lost before this can occur, the UE 102 and on board CN 210 each perform a local Detach or local Deregistration. If ISL is supported and another satellite becomes available to the UE 102 before coverage is lost, the satellite 104 can transfer the UE state and ongoing transaction information to the new satellite using ISL and instigate UE handover. Preventing a UE attempting handover or cell change to a new satellite (e.g., when ISL is not supported) can be supported without new impact by broadcasting a different TA from each satellite and prohibiting UE access to other TAs.

[0143] At stage 5 and at a later time T2, when the satellite 104 has feeder link access to an SFC 202 with access to a PLMN 108 allowed to serve the UE 102 at its location at time Tl, the endpoint proxy 240 transfers UE status and MO transaction information to a UE proxy 340 in the SFC 202. If there were no MO transactions at step 3, an indication of UE presence only is transferred.

[0144] At stage 6, the SFC 202 and UE proxy 340 simulate satellite real time access to the UE 102 at its location at time Tl. If the PLMN 108 has defined a TA and fixed cell that covers this location, the SFC 202 and UE proxy 340 can indicate UE presence in this TA and fixed cell by indicating the TA and cell when there is an SFC connection to the PLMN 108 at an SI or N2 level. For SFC connection at a Uu or N1 level (e.g., Option (a) above), the UE proxy 340 can send the UE location at time Tl to the PLMN 108 when requested. For Option (a) or Option (b), described above for FIGs. 3 to 5, the UE proxy 340 sends a NAS Attach Request (for 4G access) or a NAS Registration Request (for 5G access) to the MME or AMF of the PLMN 108 at a Uu / Nl level (e.g., for Option (a)) or S1 / N2 level (e.g., for Option (b)) according to how the SFC 202 connects to the PLMN 108 and exchanges further NAS messages with the MME or AMF of the PLMN 108 for a 4G Attach or 5G Registration as for a UE Attach or Registration for real time mode. The rest of the NAS Attach or NAS Registration procedure, relating to registration of the UE 102 in the HPLMN 1408 for the UE 102, can occur normally (as for real time mode) for all Options (a), (b) and (c), but with security and access to subscription data supported as described below (e.g., for FIGs. 8 and 9). If the UE proxy 340 has data to transfer over UP or SIP media data to transfer, the UE proxy 340 establishes PDN connection(s) or PDU session(s) for Option (a) or (b) and, for SIP media, performs an IMS Registration with security as described below. Security for a Registration, Attach, or IMS Registration is described inconnection with FIGs. 8 and 9. It is noted that the UE proxy 340 may, but is not required to, transfer SMS messages and data using the same procedures and protocols as used in stage 3. For example, the UE 102 could use CIoT to transfer data at stage 3, whereas the UE proxy 340 could use UP at stages 7 and 8.

[0145] At stage 7, the UE proxy 340 instigates one or more MO transactions to transfer any data and SIP media for the MO transactions at stage 3 to the remote endpoint(s) 116. The UE proxy 340 may send preconfigured application level messages to a user of a remote endpoint to clarify S&F operation. For example, in the case of a SIP voice media message, the UE proxy 340 may indicate to the user that it is about to play a voice message from the UE 102, may indicate the time, and possibly location, at which the message was originally sent and may further prompt the user to replay a voice message or return a voice message reply.

[0146] At stage 8, the remote endpoint(s) 116 (e.g., a user at a remote endpoint) may instigate one or more MT transactions to return responses to the UE proxy 340 for the MO transaction(s) received at stage 7. The UE proxy 340 stores the received data and associated protocol and signaling information and returns any responses to a remote endpoint necessary to ensure correct operation of transport and application protocols. The UE proxy 340 may also send preconfigured application level messages to a user at the remote endpoint(s) 116 to clarify S&F operation. For example, application level messages may indicate an expected delay in forwarding MT transactions to the UE 102 and may further indicate a later time when MO transaction responses from the UE 102 may be received back at the remote endpoint(s) 116. The UE proxy 340 may also assemble an internal MT transaction (to be sent later to the UE 102) that may be an SMS message or voice message that confirms delivery of the MO transactions at stage 7 (e.g., indicates the times when MO transactions were delivered).

[0147] At stage 9, the SFC 202 periodically transfers MT transaction data obtained at stage 8 to one or more satellites 104 that will later provide coverage to the UE 102. Each satellite 104 passes the MT transaction data to an internal endpoint proxy 240 for the UE 102 where it is stored. The MT transaction data may be retained at the SFC 202 until a satellite 104 later indicates delivery of the MT transactions to the UE 102. The SFC 202 can maintain the UE proxy 340 in a connected state or allow the PLMN 108 to place the UE proxy 340 in an idle state. In the latter case, the SFC 202 simulates continuous reachability of the UE 102.

[0148] At stage 10 and at a later time T3, a satellite 104 that received MT transaction data for the UE 102 from the SFC 202 and UE proxy 340 at stage 9 is able to provide coverage at the UE 102 location. The satellite 104 broadcasts an S&F indication and a PLMN ID for the operator of the satellite 104 in SIB1 as at stage 1.

[0149] At stage 11, the UE 102 obtains an RRC Connection and sends a NAS Attach Request or Registration Request as at stage 2. Other actions in stage 2 are also performed.

[0150] At stage 12, the endpoint proxy 240 instigates one or more MT transactions to the UE 102 to forward the MT transactions received at stage 9. The endpoint proxy 240 may also provide preconfigured application level messages to a user of the UE 102 to indicate S&F operation. For example, transfer of voice messages to the user may be preceded by a preconfigured voice message indicating the sender of each message and the time when each message was sent by the remote endpoint.

[0151] At stage 13, the UE 102 may instigate one or more MO transactions to the endpoint proxy 240, as in stage 3, to reply to MT transactions received at stage 12 or to initiate new transactions.

[0152] At stage 14, shortly before the UE 102 will lose satellite coverage, and unless handover to a new satellite is possible using ISL, the satellite 104 performs a NAS Detach or De-registration of the UE 102, as in stage 4, or the UE 102 and on board CN 210 each perform a local Detach or local De-registration.

[0153] Orbiting LEO and MEO satellites can support S&F mode along orbital segments where no feeder link is available and real time mode along segments where a feeder link is available. UEs that only see satellites on the S&F segments or only on the real time segments would not undergo mode transitions. However, other UEs may undergo mode transitions.

[0154] When a satellite 104 supporting real time mode loses access to a feeder link, the satellite 104 would cease support for real time mode and may switch to S&F mode. UEs 102 which accessed the satellite 104 previously may be able to handover to another satellite 104 with a feeder link, if one is available, but will otherwise experience a coverage gap. Some of these UEs 102 may then commence S&F access.

[0155] When a satellite 104 supporting S&F mode obtains a feeder link, the satellite 104 may cease support for S&F mode and switch back to real time mode. UEs 102 in S&F mode can be detached or de-registered prior to cessation of S&F mode. Satellite coverage data provided to a UE (if supported) can indicate the durations of S&F satellite coverage and, separately, the durations of real time satellite coverage. UEs 102 may therefore be aware when S&F coverage will cease. When an S&F coverage gap is to occur, a UE 102 can detach or de-register from the satellite 104.

[0156] A UE 102 that switches between S&F mode and real time mode may experience errors with remote endpoints 116 because data and voice sent in real time mode could arrive (at the UE 102 or at a remote endpoint 116) before data and voice sent earlier for S&F mode. MT data sent to a UE 102 that was previously attached or registered for real time access may also be buffered in a serving PLMN 108 while the UE is in a real time coverage gap, which could lead to MT data sent later to the UE 102 (when in S&F mode) arriving first. In addition, an Attach or Registration for a UE 102 in real time mode may pre-empt and release an existing Attach orRegistration by the UE 102 for S&F mode or the reverse. When a UE 102 transitions from real time mode to S&F mode, the real time Attach or Registration is no longer needed. However, for a transition from S&F mode back to real time mode, the real time Attach or Registration may be released (e.g., if the SFC 202 instigates the Attach or Registration for S&F mode in the serving PLMN 108 after the real time Attach or Registration has occurred) or may cause a release of the Attach or Registration for S&F mode and cause ongoing MO and MT transactions for S&F mode to be aborted (e.g., if the SFC 202 Attach or Registration had occurred first).

[0157] The security process described later in connection with FIGs. 8 and 9 can avoid conflict between S&F Attach or Registration and real time Attach or Registration by using a different international mobile subscriber identity (IMSI) or SUPI for each mode. If the UE 102 (e.g., a user or an application of the UE 102) consistently uses only S&F mode or only real time mode for communication with each remote endpoint 116, mis-ordering of MO data and voice arrival may be avoided. However, mis-ordering of MT data arrival at the UE 102 may be tolerated (e.g., by the user or the application) based on an awareness of the dual usage of S&F mode and real time mode.

[0158] For UE 102 access to a satellite 104 in S&F mode, an “isolated E-UTRAN operation for public safety” (IOPS) procedure may be used with satellites 104 replacing the home subscriber servers (HSSs) previously used for IOPS. Therefore, a UE 102 may use an IOPS capable Universal Subscriber Identity Module (USIM), which can either be a normal USIM enhanced for IOPS or a dual (e.g., second) USIM that is used by the UE only for S&F access. With the IOPS procedure, and for each supported UE 102, each satellite 104 may be provisioned with an IMSI (e.g., in 4G) or a SUPI (e.g., in 5G) for the UE 102 and a security key K* derived from a long term (master or primary) key K in the USIM, using a non-reversible transformation. The derivation of K* from K may be based on a Key ID or satellite identify or identifier (ID), which may, for example, be a binary number in a range from 0 to 255 or from 0 to 65535. For example, the derivation of K* may be based on the Kid (or satellite ID) and the long term key K for the UE by ciphering the Kid using the key K. As an example, the Kid may be, or may include, a satellite ID and / or could include a random component (e.g., pseudorandom or random bits or octets), a timestamp (e.g., a current date and / or a current time), and / or an SVO identity, where, for example:K* = Hash (ciphering of Kid using K) (Equation 1)

[0159] The ciphering in Example Equation 1 may for example be Advanced Encryption Standard (AES) ciphering.

[0160] The satellite 104 does not perform the derivation of K* and instead may be provisioned with K* and Kid by an HPLMN operator for the UE 102 and / or by an operator of the satellite 104. The USIM for a UE 102 may perform the derivation after receiving the Key ID Kid or satellite ID from the satellite 104 as part of authentication (e.g., using ExampleEquation 1). The derived key K* may be used for authentication and ciphering. Each satellite 104 may have a different Key ID for each UE 102 or a different satellite ID and may be provisioned with a different K* value for each UE 102 than other satellites 104. Alternatively, groups of satellites 104 may share a common Key ID or common satellite ID and a common K* value for any UE 102. The IOPS procedure can avoid exposure of the long term (master) key K of a UE 102 to satellites 104 (and to an SFC 202) and can therefore be more secure.

[0161] For SFC 202 access to a ground based serving PLMN 108, an initial satellite 104 for a UE 102 can transfer an authenticated IMSI or SUPI for the UE 102 to the SFC 202. The SFC 202 may map the IMSI or SUPI to a second IMSI or SUPI for the UE 102 that is provisioned in the SFC 202 (e.g., by an HPLMN operator for the UE 102 and / or by an operator of the initial satellite 104). The second IMSI or SUPI may have a second long term security key K2 (different to the key K and key K*) that is also provisioned in the SFC 202. The SFC 202 may use the second IMSI or SUPI and the second key K2 to authenticate the second IMSI or SUPI to the HPLMN for the UE 102. The second IMSI or SUPI and the second key K2 may also be configured in the HPLMN HSS (e.g., in 4G) or UDM or ARPF (e.g., in 5G). The second IMSI or SUPI may also be associated with one or more existing public identifiers for the UE 102 (e.g., a mobile station international subscriber directory number (MSISDN) and / or a GPSI, which are used for real time access by the UE 102) to allow MT service data from remote endpoints 116 to reach the UE 102 without impact to the remote endpoints 116. The capability to share existing public user identities among different private identities for a UE 102 may already be supported by some PLMNs in the form of a second IMSI or SUPI for an additional user device, such as a smart watch that is associated with a primary user device (e.g., a smart phone). This capability may include simultaneous coexistence of an attach or registration by both devices. Logic specific to the HPLMN may be used to direct MT services (e.g., an MT voice call or an MT SMS message) to one or both of the devices.

[0162] In some aspects, the same second key K2 value may be provisioned in the SFC 202 for other UEs 102 for the same HPLMN operator (e.g., because authentication of a UE proxy 340 for a UE 102 can be an authentication of the SFC 202 and not authentication of the individual UE 102, which is only authenticated by the satellite 104). In other aspects, a unique second key K2 value may be provisioned for each UE 102. The second IMSI or SUPI in the SFC 202 may not be permanently assigned to the UE 102 and could be reassigned to a different UE 102 when the UE 102 moves into an area where S&F access is no longer needed (and / or not provided). The second IMSI or SUPI reassignment may be performed offline. One benefit of reassignment is that an operator of the HPLMN may assign fewer second IMSIs or SUPIs to UEs 102 for S&F access, which may be useful when a number of available IMSIs or SUPIs is limited. Using the second IMSI or SUPI for a UE 102 allows a different security key K2 in the SFC 202 than the security key K in the USIM for the UE 102. Therefore, if there is a known orsuspected security compromise to the SFC 202 (which may not be as well protected as an HSS and / or a UDM), the operator of the HPLMN may provision a new security key K2 to the SFC 202 without affecting the USIM of the UE 102. Such a result is not possible if the SFC 202 were to use the IMSI or SUPI in the USIM and the key K for a UE 102.

[0163] FIG. 8 shows an example signal flow 800 that in more detail shows authentications for S&F mode. At stage 1, an HPLMN 1408 for a UE 102 and an operator of a satellite 104 provision security related credentials for the UE 102 to the satellite 104 and an SFC 202. An operator of the HPLMN 1408 may also provide an IOPS capable USIM for the UE 102. Therefore, at stage 2a, the UE 102 is provisioned with the USIM, a first IMSI or SUPI, and a master key K. Similarly, at stage 2b, the satellite 104 is provisioned with the first IMSI or SUPI, a derived key K* and an associated key identifier (ID) Kid. At stage 2c, the SFC 202 is provisioned with the first IMSI or SUPI, a second IMSI or SUPI, a second key K2, and optionally S&F subscription information. At stage 2d, an HSS, a UDM, and / or an ARPF of the HPLMN 1408 are provisioned with the first IMSI or SUPI, the second IMSI or SUPI, the second key K2, one or more public identifiers for the UE 102, and S&F subscription information.

[0164] At stage 3, the satellite 104, without a feeder link, becomes accessible to the UE 102 (e.g., via a service link). At stage 4, the UE 102 accesses the satellite 104 (e.g., as described in connection with stages 1 and 2 of FIG. 7). At stage 5, which may include stages 5a, 5b, and 5c, the satellite 104 authenticates the first IMSI or SUPI of the UE 102 using the derived key K* and the UE 102 may also authenticate the satellite 104. For example, at stage 5a, the CN 210 in the satellite 104 sends a NAS Authentication Request to the UE 102 that includes authentication challenge data (AUTN), a random value (RAND) and the Key ID Kid (e.g., which may be an ID for the satellite 104). The Key ID Kid may be part of the authentication challenge data AUTN. At stage 5b, the UE 102 (e.g., a USIM in UE 102) determines the derived key K* from the master key K and the Key ID Kid, e.g., using Example Equation 1. The UE 102 may then verify that all or part of the authentication challenge data AUTN can be derived from the random value RAND using the derived key K* which may authenticate the satellite 104 to UE 102. At stage 5c, the UE 102 returns a NAS Authentication Response, to the CN 210 in the satellite 104, that includes an authentication result determined (e.g., by the USIM in UE 102) from the random value RAND and the derived key K*. Therefore, the CN 210 in the satellite 104 may verify the authentication result using the derived key K*, which may authenticate the UE 102 to the satellite 104.

[0165] The UE 102 and satellite 104 may then exchange MO and / or MT transaction data as described for stages 3, 12, and 13 of FIG. 7, but not shown in FIG. 8.

[0166] At stage 6, the satellite 104 (e.g., by moving) is able to access a feeder link to the SFC 202 (and may lose access to the service link to the UE 102). At stage 7, the satellite 104transfers the first IMSI or SUPI, authenticated at stage 5, to the SFC 202 (along with any MO data received from the UE 102 after stage 5). At stage 8, the SFC 202 may map the first IMSI or SUPI to the second IMSI or SUPI (e.g., for the UE 102).

[0167] At stage 9, (the UE proxy 340 of) the SFC 202 may access a ground based PLMN 108 on behalf of the UE 102 (e.g., as described in connection with stage 6 of FIG. 7). The (UE proxy 340 of) the SFC 202 may use the second IMSI or SUPI to identify the UE 102.

[0168] At stage 10, (the UE proxy 340 of) the SFC 202 may register, or may instigate registration of, the UE 102 in the HPLMN 1408 using the second IMSI or SUPI, and, as part of registering the UE 102 in the HPLMN 1408 (e.g., as part of stage 6 in FIG. 7), the HPLMN 1408 of the UE 102 may identify the UE 102 using the second IMSI or SUPI and may authenticate the UE 102 using the second key K2.

[0169] As an example of stage 10, and in the case of Option (a) or Option (b) described in FIGs. 3 to 5, the SFC 202 (e.g., the UE proxy 340) may first send either a NAS Attach Request to an MME in the ground based PLMN 108 for 4G access or a NAS Registration Request to an AMF (e.g., AMF 414) in the ground based PLMN 108 for 5G access. The NAS Attach Request may include the second IMSI, and the NAS Registration Request may include the second SUPI, to identify the UE 102 to the MME or AMF, respectively. The MME or AMF in the PLMN 108 may then send an Authentication Request for the UE 102 to the HPLMN 1408 for the UE 102 (e.g., to an AUSF, UDM, or HSS in the HPLMN 1408) that includes the second IMSI or SUPI for the UE 102. In the case of Option (c) described in FIGs. 3 and 6, and for 5G access, the SFC 202, or an AMF in PLMN 108 associated with SFC 202, may send an Authentication Request for the UE 102 to the HPLMN 1408 (e.g., to an AUSF or UDM in the HPLMN 1408) that includes the second SUPI for the UE 102. The HPLMN 1408 (e.g., a UDM in the HPLMN 1408) may then identify UE 102 based on the second SUPI and may return an Authentication Response to the AMF in PLMN 108, or to the SFC 202 (for Option (c) with 5G access and no AMF), requesting authentication of UE 102 based on the second key K2 and including authentication challenge data to perform the authentication. For all cases where the Authentication Response was sent to the MME or AMF in PLMN 108, the MME or AMF returns an authentication request to the SFC 202 (e.g., to the UE Proxy 340) requesting authentication of UE 102 and including some of the authentication challenge data to perform the authentication. The SFC 202 (e.g., the UE Proxy 340) determines authentication response data based on the second key K2 and the authentication challenge data and returns the authentication response data to the MME or AMF when the MME or AMF was used to access the HPLMN 1408. For 5G access, the AMF, when used to access the HPLMN 1408, or the SFC 202 (with Option (c) and no AMF used to access the HPLMN 148), returns the authentication response data to the HPLMN 1408, which authenticates the second SUPI. For 4G access, the MME, if used to access the HPLMN 1408, may authenticate the second IMSI. With 4G access andOption (c), no authentication of the second IMSI may be needed. Following authentication of the second IMSI or SUPI when needed, or as part of registering the UE 102 in the HPLMN 1408 when no authentication is needed, the MME or AMF, or the SFC 202 for Option (c) with no MME or AMF, can register the UE 102 in the HPLMN 1408 by sending either an Update Location Request containing the second IMSI to an HSS in the HPLMN 1408 for 4G access or a UE CM Registration Request containing the second SUPI to a UDM in the HPLMN for 5G access. The HPLMN 1408 (e.g., the HSS or UDM) may send a response to the MME, AMF or SFC 202 to complete the registration of UE 102.

[0170] Based on stage 10 in FIG. 8, the UE proxy 340 can forward MO service data for the UE 102 and receive MT service data for the UE 102 from one or more remote endpoints 116 (e.g., as described in connection with stages 7 and 8 of FIG. 7).

[0171] Some examples may differ from what is shown in FIG. 8. In one example, the UE 102 may have a dual (e.g., second) USIM that contains a permanently assigned second IMSI or SUPI and the long term key K. Mapping of the IMSI or SUPI in the SFC 202 may then be skipped. However, the second key K2 in the SFC 202 may still be different than the key K in the USIM, as long as the dual USIM is only used for S&F access, because the second IMSI or SUPI in the USIM is then authenticated only by the satellite 104, whereas the second IMSI or SUPI in the SFC 202 is authenticated only by the HPLMN 1408.

[0172] In another example, the second IMSI or SUPI and the second key K2 may be common to multiple UEs 102 (e.g., all UEs 102 for a particular HPLMN 1408). In this example, and in order to uniquely identify the UE 102 for Option (a) or Option (b), the SFC 202 may include the first IMSI or SUPI received from the satellite 104 as an extra parameter in an Attach Request or Registration Request (which also includes the second IMSI or SUPI for authentication). The SFC 202 or ground based PLMN 108 may similarly send the first IMSI or SUPI of the UE 102 to the HPLMN 1408 for Options (a), (b), and (c) as an extra parameter in any message used for registration of the UE 102 in the HPLMN 1408.

[0173] In another example (e.g., for Option (c) in FIG. 6), the SFC 202 may be integrated in the ground based serving PLMN 108 (e.g., the SFC 202 and the PLMN 108 have a common operator), and the PLMN 108 may act as an HPLMN for the UE 102. In this example, the second IMSI or SUPI and the second key K2 may not be provisioned in the SFC 202.

[0174] In some examples, the derived key K* stored in SV 104 at stage 2b in FIG. 8, and used to authenticate UE 102 at stage 5 in FIG. 8, may be present, and therefore exposed, in SV 104 over a long duration (e.g., a few days to a few months) and could be obtained by an attacker who is able to hack into SV 104 (e.g., by making use of the same signaling procedures that are used to provision K* in SV 104 at stage 1). In that case, the attacker could spoof UE 102 (e.g., use a fake UE that appears to be UE 102), obtain access to SV 104 or other SVs 104 that wereprovisioned with K*, and communicate with remote endpoints 116 posing as UE 102 or the user of UE 102. Alternatively, or additionally, the attacker could spoof the presence of SV 104 to UE 102, using a fake SV or fake terrestrial base station that uses the derived key K* to falsely authenticate the fake SV or fake base station to UE 102, and thereby communicate with UE 102 without UE 102 being aware that it is not communicating with a legitimate SV 104. Alternatively, or additionally, the attacker could simply eavesdrop on and monitor communication of UE 102 with a legitimate SV 104 and with a remote endpoint 116. Each of these possibilities would violate security for UE 102 and possibly for remote endpoints 116.

[0175] To further improve security and help avoid the spoofing examples above, the derived key K* for a UE 102 can be used by an SV 104 only for a limited period of time (e.g., one day) after which the derived key K* is no longer used (e.g., is deleted) and is replaced by a different derived key which is also only used for a similar limited period of time. Then, if an attacker obtains access to the derived key K*, it could only be used for, at most, the limited period of time and would no longer be usable after this period has expired. To enable this, a sequence of derived keys for a UE 102, Ka*, Kb*, Kc*, Kd*, Ke* etc., may be provisioned and stored in every SV 104, as at stages 1 and 2b in FIG. 8, one key at a time at periodic intervals (e.g., one key each day). At each provisioning occurrence (e.g., once each day), a new derived key in the sequence for UE 102 would be provisioned and stored in every SV 104 with the previous derived key being erased. This means that each SV 104 can have the same derived key as every other SV 104. To ensure that all SVs 104 switch to a new derived key for UE 102 at the same time, new derived keys for the UE 102 may be configured in each SV 104 a short time in advance of actual usage (e.g., one or two hours in advance), with each SV 104 switching to the derived key from a previous derived key at the same later time. This may avoid a UE 102 accessing an SV 104 which has a new derived key and later accessing another SV 104 which still has a previous derived key which could slightly increase the chance of a replay attack from a fake SV 104. In addition, once a UE 102 is no longer accessing SVs 104 in S&F mode, updating of the derived keys in SVs 104 may cease and derived keys for the UE 102 in all SVs 104 may be deleted.

[0176] To support the above updating of derived keys, the first derived key Ka* in the sequence of derived keys can be provisioned and stored in SVs 104 at some initial time. After a periodic interval (e.g., one day later), the next derived key Kb* in the sequence of derived keys is provisioned and stored in the SVs 104 and may be used immediately, or at a slightly later time, and the first derived key Ka* may also be deleted. After the next periodic interval (e.g., another day later), the third derived key Kc* in the sequence is provisioned and stored in the SVs 104 and may be used immediately, or at a slightly later time, and the second derived key Kb* may also be deleted. This sequence of events may then continue for further derived keys Kd*, Ke*, etc. until the UE 102 is no longer accessing SVs 104 in S&F mode. The sequence ofderived keys Ka*, Kb*, Ke*, Kd*, Ke*, etc. may be derived from the master key K and a sequence of corresponding key IDs Kid-a, Kid-b, Kid-c, Kid-d, Kid-e, etc. using Example Equation 1 (e.g., with Ka* derived using K and Kid-a, Kb* derived using K and Kid-b, Kc* derived using K and Kid-c, etc.). The sequence of key IDs, Kid-a, Kid-b, Kid-c, Kid-d, Kid-e, etc., may be a simple numeric sequence, such as 0, 1, 2, 3, 4, and so on.

[0177] According to stage 5a in FIG. 8, the key ID is sent by the SV 104 to the UE 102 in the Authentication Request to enable UE 102 to determine the derived key K* from the master key K in the USIM. However, in order to avoid new signaling changes to an Authentication Request or to an AUTN parameter and to avoid associated new impacts to a Mobile Equipment (ME) portion or USIM portion of a UE 102, there may be a limited number of bits available in an Authentication Request (e.g., in the AUTN parameter) to convey the key ID. The number of bits may around 5 to 8 depending on encoding and usage of the AUTN parameter. However, if a sequence of Key IDs is used to generate a corresponding sequence of derived keys, and if no derived key (or corresponding key ID) is repeated, in order to avoid reuse of a previous derived key, the values of later key IDs in the sequence may require more bits to transfer than are available in an Authentication Request (e.g., in an AUTN parameter).

[0178] To overcome the above limitation, only the least significant bits (e.g., least significant 5 or 8 bits) of any Key ID may be sent to UE 102 at stage 5a in place of the complete value of the Key ID. To reconstruct a Key ID, the UE 102 (e.g., a USIM in UE 102) may use a “last used key ID” value. This value may be set to an initial Key ID value (e.g., zero) that is configured in the UE 102 and is used when there has been no recent S&F access by the UE 102 to SVs 104, or may otherwise be the last Key ID value successfully used by UE 102 to perform authentication with an SV 104 for S&F mode. When the UE 102 (e.g., a USIM in UE 102 that is used for S&F mode) receives the least significant bits of a Key ID from a new SV 104, the UE 102 (e.g., the USIM) may assume that the complete Key ID value is the same as, or slightly greater than, the last used Key ID, and that the binary value in the most significant bits of the complete Key ID value is either the same as, or one greater than, the most significant bits for the last used key ID. This can allow a UE 102 to correctly access a new SV 104 whose derived key may, or may not have been, updated since the last UE 102 access to an SV 104. An Example Reconstruction Rule for a Key ID to enable reconstruction of a complete Key ID value could be as follows.Example Reconstruction Rule for a Key IDLet Kid-latest = value of the last used Key ID at UE 102. Let L = value of the least significant bits of Kid-latest. Let H = value of the most significant bit of Kid-latest. Let N = number of bits for L.Let L* = value of the least significant bits for a new Key ID received from a new SV 104.Then the UE 102 determines:VI = (H 2N+ L*) and V2 = ((H+l) 2N+ L*); and sets the new Key ID value to VI when VI equals or exceeds Kid-latest or to V2 otherwise.

[0179] The IOPS security solution described for FIG. 8 together with the additions described above (e.g., including sending of a sequence of derived keys and associated Key IDs to SVs 104, and / or sending of just the least significant bits of a Key ID to a UE 102 and the Example Reconstruction Rule for a Key ID) is referred to here as an “enhanced IOPS security solution.”

[0180] FIG. 9 shows an example signaling flow 900 that in more detail illustrates the enhanced IOPS security procedure. At stage 1 in FIG. 9, an HPLMN 1408 and an operator of the satellites 104 provision security related credentials for a UE 102 to the satellites 104a and 104b and an SFC 202. An operator of the HPLMN 1408 may also provide an IOPS capable USIM for the UE 102.

[0181] Therefore, at stage 2a, the UE 102 is provisioned with the USIM, a first IMSI or SUPI, a master key K and a first Key ID Kid-a. Similarly, at stage 2b, the SVs 104a and 104b are each provisioned with the first IMSI or SUPI, a first derived key Ka* and first Key ID value Kid-a, where Ka* may be determined from Kid-a and K using Example Equation 1. In some aspects, the SVs 104a and 104b may be provisioned with just the least significant bits of the first Key ID value Kid-a as SVs 104a and 104b may not use the most significant bits of the Key ID value.

[0182] At stage 2c, the SFC 202 is provisioned with the first IMSI or SUPI, a second IMSI or SUPI, a second key K2, and optionally S&F subscription information for the UE 102. At stage 2d, an HSS, a UDM, and / or an ARPF of the HPLMN 1408 are provisioned with the first IMSI or SUPI, the second IMSI or SUPI, the second key K2, one or more public identifiers for the UE 102, and S&F subscription information.

[0183] The first Key ID Kid-a at stage 2 may be zero (or one) for an initial SV access by UE 102. In that case, the first Key ID (Kid-a) value may be preconfigured (e.g., hard coded) in UE 102. Alternatively, the first Key ID Kid-a at stage 2 may be the last used Kid value for UE 102 from a previous SV 104 access (not shown in FIG. 9) that may have occurred some time (e.g., days, weeks, or months) previously.

[0184] All of part of Stages 1 and 2 may be repeated for a UE 102 at one or more later times, for example, shortly before a user of UE 102 expects to be at a location where store and forward access is needed (e.g., if the user previously notifies the HPLMN 1408 operator of this) or aftera UE 102 accesses an SV 104 in which the security credentials for stage 2b were not yet configured.

[0185] At stage 3, the SV 104a, without a feeder link, becomes accessible to the UE 102 (e.g., via a service link). At stage 4, the UE 102 accesses the SV 104a and may authenticate the SV 104a and be authenticated by the SV 104a as described for stage 5 in FIG. 8. In this case, the Key ID sent to UE 102 by SV 104a at stage 5a in FIG. 8 comprises just the least significant bits of the key ID Kid-a. The UE 102 uses this to reconstruct the Key ID Kid-a from the Key ID configured in UE 102. For example, the Example Reconstruction Rule for a Key ID described above may be used. In that case, since the UE 102 and SV 104a both have the same Key ID Kid-a, the UE 102 will determine the values VI and V2 using the Example Reconstruction Rule and select V 1 which will equal Kid-a,

[0186] As part of stage 4, and after UE 102 authentication and attach or registration have occurred, UE 102 may send MO data to SV 104a for later transfer to remote endpoints 116 via SFC 202 and PLMN 108 as described for FIGs. 7 and 8. However, this is not shown in FIG. 9 and is not described here as it is not part of the enhanced IOPS security procedure that FIG. 9 illustrates. This exclusion of MO and MT data transfer aspects applies to later stages of FIG. 9 as well which only show and describe aspects applicable to the enhanced IOPS security procedure.

[0187] At stage 5, UE 102 ceases to access SV 104a and SV 104a moves to where it has a feeder link to SFC 202 and no service link to UE 102.

[0188] At stage 6, SFC 202 or HPLMN 1408 provisions a new derived key Kb* and associated Key ID Kid-b (or least significant bits of Key ID Kid-b) for UE 102 in SV 104a. The new associated key ID Kid-b may equal (Kid-a + 1) and the new derived key Kb* may be obtained from Kid-b using Example Equation 1.

[0189] At stage 7, which may occur immediately after stage 6 or a short time after stage 6 (e.g., one or two hours later), SV 104a ceases to use the previous derived key Ka* and associated key ID Kid-a to authenticate UEs 102 and may delete these values. SV 104a also starts to use the new derived key Kb* and associated Key ID Kid-b (or least significant bits of Key ID Kid-b) that were received at stage 6 to authenticate UEs 102.

[0190] At stage 8, after the SV 104a has moved again and after stage 7 has occurred, the SV 104a, without a feeder link, again becomes accessible to the UE 102 (e.g., via a service link).

[0191] At stage 9, the UE 102 accesses the SV 104a and may authenticate the SV 104a and be authenticated by the SV 104a as described for stage 5 in FIG. 8. In this case, the Key ID sent to UE 102 by satellite 104a at stage 5a in FIG. 8 comprises the least significant bits of the Key ID Kid-b. The UE 102 uses this to reconstruct the Key ID Kid-b from the last key ID used by UE 102 which is the Key ID Kid-a that was last used at stage 4. For example, when theExample Reconstruction Rule for a Key ID described above is used and when Kid-b equals (Kid-a + 1), the least significant bits L* of Kid-b sent to UE 102 at stage 8 will equal (L + 1) MOD 2N. The values VI and V2 determined by UE 102 will then be:VI = (H 2N+ (L + 1) MOD 2N); andV2 = ((H+l) 2N+ (L + 1) MOD 2N).

[0192] If L* (i.e. (L + 1) MOD 2N) is not zero, then VI will be greater than the last used Key ID Kid-a (which equals H 2N+ L) and will be used by UE 102 as the new Key ID. If L* is zero (which means that L is all binary ones), then V 1 (which will equal H 2N) will be less than the last used Key ID Kid-a (which equals H 2N+ L) and UE 102 will select V2 as the new Key ID. So the reconstruction will be correct. UE 102 and SV 104a can then proceed with the authentication described for stage 5b and 5c in FIG. 8 and may further perform an attach or registration and transfer MO and / or MT data as described for FIG. 7.

[0193] At stage 10, the SV 104a may move away from the location of UE 102 and no longer provide access, and SV 104b, without a feeder link, becomes accessible to the UE 102 (e.g., via a service link). It is assumed here that SV 104b is still using the previous derived key Ka* with Key ID Kid-a and has not yet received or switched to the new derived key Kb* and associated key ID Kid-b for UE 102.

[0194] At stage 11, the UE 102 accesses the SV 104b and may attempt to authenticate the SV 104b and be authenticated by the SV 104b as described for stage 5 in FIG. 8. In this case, the Key ID sent to UE 102 by SV 104b at stage 5a in FIG. 8 comprises the least significant bits of the Key ID Kid-a. The UE 102 uses this to attempt to reconstruct the Key ID Kid-a from the last Key ID used by UE 102, which is Key ID Kid-b that was used at stage 9. For example, when the Example Reconstruction Rule for a Key ID described above is used and when Kid-a equals (Kid-b - I), the least significant bits L* of Kid-a sent to UE 102 at stage 10 will equal (L - 1) MOD 2N. The values VI and V2 determined by UE 102 will then be:VI = (H 2N+ (L - 1) MOD 2N); andV2 = ((H+l) 2N+ (L - 1) MOD 2N)

[0195] If L* (i.e. (L - 1) MOD 2N) is not all binary ones, then VI will be less than the last used key ID Kid-b (which equals H 2N+ L) and UE 102 will select V2 at the new key ID. If L* is all binary ones (which means that L is zero), then VI will be greater than the last used key ID Kid-b (which equals H 2N) and UE 102 will select VI as the new key ID. In either case, the reconstructed Key ID will be incorrect (i.e., will not be Kid-a), and UE 102 will not be able to correctly authenticate SV 104b as at stage 5b in FIG. 8 because UE 102 will determine an incorrect derived key (using the incorrect Key ID) to perform the authentication. So, the authentication procedure will fail, and UE 102 will not be able to access SV 104b and will then retain Kid-b as the last used Key ID for any further access to an SV 104.

[0196] Although the failure of authentication at stage 11 prevents UE 102 access to SV 104b, the failure also protects UE 102 in the case that SV 104b is being spoofed by an attacker who has obtained a previous derived Key Ka* and associated Key ID Kid-a. Although the previous derived Key Ka* and associated Key ID Kid-a in this example are only one step behind the latest derived Key Kb* and associated Key ID Kid-b in the sequence of derived keys and associated Key IDs, the same principles apply whenever an earlier derived Key and associated earlier Key ID in the sequence are used and will prevent a replay attack against UE 102 by a fake SV 104. For example, if an attacker manages to obtain an earlier derived Key and associated earlier Key ID and attempts to use these to spoof an SV 104 to UE 102 long after the earlier derived Key and associated earlier Key ID have been replaced in legitimate SVs 104, the techniques above can protect the UE 102.

[0197] The enhanced IOPS security procedure described above and illustrated in FIG. 9 may be further enhanced in a “further enhanced IOPS security procedure.” With the further enhancement, a Key ID Kid for a UE 102 that is used (e.g., by a USIM in the UE 102) to determine a derived key K*, from a master key K for the UE 102, is composed of two integers, referred to here as “n” and “m.” The Key ID Kid, and thus the two integers n and m, can be common to a group of one or more satellites 104 that the UE 102 is allowed to access - meaning that for this UE 102, each satellite 104 in the group is configured with the same Key ID Kid, and is thus configured with the same values for the two integers n and m and with the same derived key K* for the UE 102. There may be other groups of satellites 104 that the UE 102 is allowed to access, where the satellites 104 in each group are configured with the same values of n and m, and where the value of n configured in satellites 104 in each group is different to the values of n configured in satellites 104 in all the other groups. The value of n can then serve as, correspond to, and / or be referred to as, a group identity or identifier (ID) as it is different for each group of satellites 104. The value of m configured in the satellites 104 in each group can be either the same as or different from the values of m configured in satellites 104 for all other groups.

[0198] A USIM in each UE 102 can be configured to determine a derived key K* from the master key K in the USIM and the values of n and m as follows:K* = Hash (ciphering of n and m using K) (Equation 2)

[0199] As an example of Equation 2, a binary value of n containing a fixed number of binary digits (and containing leading zeros to achieve the fixed number of binary digits if needed) may be concatenated with a binary value of m also containing a fixed number of binary digits (and containing leading zeros to achieve the fixed number of binary digits if needed). The resulting concatenated binary number may then be ciphered using the master key K, with the result then converted using a known hash function to the derived key K* .

[0200] As a consequence of the different values of n configured for each group of satellites 104 for any UE 102, the value of a derived key K* configured for this UE 102 in the satellites 104 in each group is different to the value of a derived key K* configured in satellites for all other groups. This can reduce the effects of exposure of a derived key K* in any satellite X to an attacker, as the attacker would only be able to use the derived key K* to compromise UE 102 security when the UE 102 or the attacker is accessing a satellite 104 in the particular group of satellites 104 to which the satellite X belongs and not when the UE 102 or attacker is accessing a satellite 104 in any other group. The further enhanced IOPS security procedure may thereby provide better security than the enhanced IOPS security procedure described earlier.

[0201] A satellite 104 may send the values of n and m to a UE 102 as part of authentication (e.g., as part of an AUTN parameter in a NAS Authentication Request). To transfer the value of n to a UE 102, a satellite 104 may send to the UE 102 all the bits of n (e.g., 8 bits if n has values in the range 0 to 255). To transfer the value of m to a UE 102, a satellite 104 may send to the UE 102 only the least significant bits of m (e.g., the 3 least significant bits of m). A UE 102 may then reconstruct the complete value of m in a similar manner to that described for reconstruction of a Key ID Kid (e.g., as described for the Example Reconstruction Rule for a Key ID), where values of m now replace values of Kid in this description.

[0202] For example, to reconstruct a complete value of m when a UE 102 receives a complete value of n and least significant bits for m from an SV 104, a UE 102 (e.g., a USIM in UE 102) may use a “last used value of m,” which may be either (i) an initial value of m (e.g., zero or one) configured in the UE 102 (e.g., in the USIM) in association with the value of n received from the SV 104 if there has been no recent S&F access by the UE 102 to SVs 104, or (ii) may be the last value of m successfully reconstructed and used by UE 102 to perform authentication with a previous SV 104 for S&F mode, where the same value of n was received by the UE 102 from the SV 104 and from the previous SV 104. It is noted that in the further enhanced IOPS security procedure, the UE 102 may be configured with an initial value of m for each possible value of n and may further store a last value of m successfully reconstructed and used by the UE 102 to perform authentication with an SV 104 for S&F mode for each possible received value of n.

[0203] When the UE 102 receives the least significant bits of a value of m and a complete value of n from a new SV 104, the UE 102 may assume that the (complete) value of m is the same as, or slightly greater than, the last used value of m (as described above) associated with the same value of n and that the binary value in the most significant bits of the complete value of m is either the same as, or one greater than, the most significant bits for the last used value of m associated with the same value of n. This can allow a UE 102 to correctly access a new SV 104 whose derived key (e.g., m value) either has been or has not been updated since the last UE 102 access to an SV 104 configured with the same value of n.

[0204] The number of bits in the n values may be limited (e.g., may be 5 or 8 bits) and the number of bits in the m values may be larger (e.g., may be 32 or 48 bits) with just the least significant bits (e.g., 3 bits) being sent to a UE.

[0205] The groups of satellites 104 in which the same value of n is configured for any UE 102 in each group may be the same as or different to the groups of satellites 104 in which the same value of n is configured in each group for another UE 102. For example, each UE 102 may be allowed to access only certain satellites 104 which may not necessarily be the same as the satellites 104 which other UEs 102 are each allowed to access. This may sometimes lead to different groups of satellites 104 being used for each UE 102.

[0206] FIG. 10 is a flow diagram of a method 1000 of authentication in a store and forward mode (e.g., by a UE 102). Example components of a UE are provided hereafter with respect to FIG. 14.

[0207] At block 1010, the UE receives, from an SV (e.g., an SV 104) operating in a store and forward mode, an authentication request that includes an identifier (ID) associated with the SV. FIGs. 8 and 9 illustrate examples of a UE receiving an authentication request from an SV. The reception may be performed, for example, by the communications component 1498, the transceiver(s) 1422, and / or the antenna(s) 1480 of the apparatus 1404 in FIG. 14.

[0208] At block 1020, the UE determines a derived key from a master key that was provisioned to the UE (e.g., in a USIM of the UE) and the ID associated with the SV. The UE may determine the derived key using Example Equation 1. The master key is different than a second key, associated with the UE, that was provisioned to an SFC. The determination may be performed, for example, by the application processor(s) 1406 and / or the modem 1424 of the apparatus 1404 in FIG. 14.

[0209] At block 1030, the UE transmits, to the SV, an authentication response that includes an authentication result determined from the derived key. FIGs. 8 and 9 illustrate examples of a UE transmitting an authentication response. The authentication response may be used to authenticate (or validate) a first IMSI or SUPI associated with the UE. The transmission may be performed, for example, by the communications component 1498, the transceiver(s) 1422, and / or the antenna(s) 1480 of the apparatus 1404 in FIG. 14.

[0210] In some aspects, the authentication request further includes authentication challenge data, and the authentication result is further determined from the authentication challenge data. Additionally, or alternatively, the authentication request and the authentication response include NAS messages.

[0211] In some aspects, the UE is further associated with a second IMSI or SUPI that is provisioned for the UE in the SFC. For example, the second IMSI or SUPI may be different than the first IMSI or SUPI. In some aspects, the second IMSI or SUPI may be associated withat least one additional UE. Alternatively, the second IMSI or SUPI may be the same as the first IMSI or SUPI.

[0212] FIG. 11 is a flow diagram of a method 1100 of authentication in a store and forward mode (e.g., performed by an SFC 202). Example components of an SFC are provided hereafter with respect to FIG. 16.

[0213] At block 1110, the SFC receives, from an SV (e.g., an SV 104) operating in a store and forward mode, mobile originated (MO) data and a first IMSI or SUPI for a UE (e.g., a UE 102). In some aspects, the first IMSI or SUPI for the UE is authenticated by the SV when the UE accesses the SV and sends the MO data to the SV. The reception may be performed, for example, by the communications interface 1648, the transceiver(s) 1646, and / or the antenna(s) 1680 of the apparatus 1602 in FIG. 16.

[0214] At block 1120, the SFC determines a second IMSI or SUPI for the UE based on the first IMSI or SUPI. An example mapping of a first IMSI or SUPI to a second IMSI or SUPI is described in connection with FIG. 8. The determination may be performed, for example, by the store and forward component 1699 and / or the processor(s) 1642 of the apparatus 1602 in FIG. 16.

[0215] At block 1130, the SFC receives, from a ground network, an authentication request. FIG. 8 illustrates an example of an SFC 202 receiving an authentication request. The ground network may be a ground based serving PLMN (e.g., PLMN 108 in the case of Option (a) in FIG. 4 or Option (b) in FIG. 5) or may be an HPLMN for the UE (e.g., HPLMN 1408 in the case of Option (c) in FIG. 6). The reception may be performed, for example, by the communications interface 1648, the transceiver(s) 1646, and / or the antenna(s) 1680 of the apparatus 1602 in FIG. 16.

[0216] At block 1140, the SFC transmits, to the ground network, an authentication response that includes an authentication result determined from a second key for the UE provisioned to the SFC. FIG. 8 illustrates an example of an SFC 202 transmitting an authentication response. The second key may be different than a master key that was provisioned to the UE, and the authentication response may be used to authenticate (e.g., validate) the second IMSI or SUPI. The transmission may be performed, for example, by the communications interface 1648, the transceiver(s) 1646, and / or the antenna(s) 1680 of the apparatus 1602 in FIG. 16.

[0217] At block 1150, the SFC transmits, to the ground network, the MO data in response to the second IMSI or SUPI being authenticated (e.g., validated). The transmission may be performed, for example, by the communications interface 1648, the transceiver(s) 1646, and / or the antenna(s) 1680 of the apparatus 1602 in FIG. 16.

[0218] In some aspects, the authentication request further includes authentication challenge data, and the authentication result is further determined from the authentication challenge data.Additionally, or alternatively, the authentication request and the authentication response include NAS messages.

[0219] In some aspects, the second IMSI or SUPI is the same as the first IMSI or SUPI. Alternatively, the second IMSI or SUPI is different than the first IMSI or SUPI. In some aspects, the second IMSI or SUPI is associated with at least one additional UE (e.g., is associated with other UEs with the same HPLMN as the UE).

[0220] FIG. 12 is a flow diagram of a method 1200 of authentication in a store and forward mode, performed by a UE (e.g., by a UE 102). Example components of a UE are provided hereafter with respect to FIG. 14.

[0221] At block 1210, the UE receives, from a space vehicle (e.g., a SV 104) operating in a store and forward mode, an authentication request that includes a portion of a key identifier (ID), where the portion of the key ID and a derived key are configured in the SV. The enhanced IOPS security solution described previously and FIG. 9 illustrate examples of block 1210. The reception may be performed, for example, by the communications component 1498, the transceiver(s) 1422, and / or the antenna(s) 1480 of the apparatus 1404 in FIG. 14.

[0222] At block 1220, the UE reconstructs the key ID based on the portion of the key ID (e.g., as described previously for the enhanced IOPS security solution and Example Reconstruction Rule for a Key ID). The reconstruction may be performed, for example, by the application processor(s) 1406 and / or the modem 1424 of the apparatus 1404 in FIG. 14.

[0223] At block 1230, the UE determines the derived key from the key ID and a master key that was provisioned to the UE. The UE may determine the derived key using Example Equation 1. The determination may be performed, for example, by the application processor(s) 1406 and / or the modem 1424 of the apparatus 1404 in FIG. 14.

[0224] At block 1240, the UE performs authentication with the SV using the derived key (e.g., as described previously for the enhanced IOPS security solution and FIG. 9). The authentication may be performed, for example, by the communications component 1498, the transceiver(s) 1422, the application processor(s) 1406 and / or the modem 1424 of the apparatus 1404 in FIG. 14.

[0225] In some aspects, performing authentication with the SV using the derived key comprises: authenticating the SV using the derived key and the authentication request; and transmitting, to the SV, an authentication response when the SV is successfully authenticated, where the authentication response includes an authentication result determined from the derived key and the authentication request, and where the authentication result and the derived key configured in the SV can be used to authenticate the UE (e.g., as described for FIGs. 8 and 9). The authentication request may further include authentication challenge data, where theauthentication challenge data includes the portion of the key ID, and where the authentication result is further determined from the authentication challenge data.

[0226] In some aspects, the portion of the key ID comprises least significant bits of the key ID.

[0227] In some aspects, reconstructing the key ID based on the portion of the key ID comprises: determining the key ID based on the portion of the key ID and a last used key ID, where the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode (e.g., as described previously for the enhanced IOPS security solution and for FIG. 9). In some aspects, the UE may additionally: store the key ID when the authentication with the SV is successful; access a second SV in store and forward mode; receive a second authentication request from the second SV, where the second authentication request includes a portion of a second key ID; use the key ID as a new last used key ID to determine the second key ID; and perform authentication with the second SV using the second key ID (e.g., as described for FIG. 9).

[0228] In some aspects, and as described above for the further enhanced IOPS security procedure, the key ID comprises an integer n value (e.g., an integer n with a certain value) and an integer m value (e.g., an integer m with a certain value), where the integer n value is configured in each SV in a plurality of S Vs (e.g., a group of SVs). The plurality of SVs may include the SV, and the integer n value may not be configured in any SV of a second plurality of SVs (e.g., one or more other groups of SVs). In these aspects, the portion of the key ID may comprise all bits in the integer n value and least significant bits in the integer m value. Reconstructing the key ID based on the portion of the key ID may comprise determining the key ID based on the portion of the key ID and a last used integer m value (e.g., a last used value for the integer m), where the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode and from which the UE received the integer n value. The method 1200 may further comprise: storing the integer m value in association with the integer n value when the authentication with the SV is successful; accessing a second SV in store and forward mode; receiving a second authentication request from the second SV, where the second authentication request includes a portion of a second key ID, where the portion of the second key ID comprises the integer n value and least significant bits of a second integer m value; using the integer m value as a new last used integer m value to determine the second key ID; and performing authentication with the second SV using the second key ID.

[0229] FIG. 13 is a flow diagram of a method 1300 of authentication in a store and forward mode, performed by a space vehicle (e.g., an SV 104). Example components of an SV are provided with respect to network entity 1810 in FIG. 18 and network entity 1502 in FIG. 15.

[0230] At block 1310, the SV sends, to a user equipment (e.g., a UE 102), an authentication request that includes a portion of a key identifier (ID), where the portion of the key ID is configured in the SV, where the portion of the key ID enables reconstruction (e.g., by the UE) of the key ID, where the key ID enables determination (e.g., by the UE) of a derived key from a master key that was provisioned to the UE, and where the derived key is configured in the SV. The enhanced IOPS security solution described previously and FIG. 9 illustrate examples of block 1310. Block 1310 may be performed, for example, by the communications interface 1548, the transceiver(s) 1546, and / or the processor(s) 1542 of the network entity 1502 in FIG. 15.

[0231] At block 1320, the SV performs authentication with the UE using the derived key (e.g., as described in FIGs. 8 and 9). The authentication may be performed, for example, by the communications interface 1548, the transceiver(s) 1546, the store and forward component 1599, and / or the processor(s) 1542 of network entity 1502 in FIG. 15.

[0232] In some aspects, performing authentication with the UE using the derived key comprises: enabling authentication of the SV using the derived key and the authentication request; receiving, from the UE, an authentication response when the SV is successfully authenticated, where the authentication response includes an authentication result determined from the derived key and the authentication request; and authenticating the UE using the authentication result and the derived key (e.g., as described for FIG. 9). The authentication request may further include authentication challenge data, where the authentication challenge data includes the portion of the key ID, and where the authentication result is further determined from the authentication challenge data (e.g., as described for FIGs. 8 and 9).

[0233] In some aspects, the portion of the key ID comprises least significant bits of the key ID.

[0234] In some aspects, the key ID may be reconstructed based on the portion of the key ID and a last used key ID, where the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode (e.g., as described previously for the enhanced IOPS security solution and Example Reconstruction Rule for a Key ID). The SV may additionally: receive a second derived key and at least a portion of a second key ID from a trusted source at a first time; and use the second derived key and the portion of the second key ID to perform authentication with a plurality of UEs for store and forward mode at or after asecond time, where the second time is the same as, or occurs later than, the first time (e.g., as described previously for the enhanced IOPS security solution).

[0235] In some aspects, and as described above for the further enhanced IOPS security procedure, the key ID comprises an integer n value (e.g., an integer n with a certain value) and an integer m value (e.g., an integer m with a certain value), where the integer n value is configured in each SV in a plurality of S Vs (e.g., a group of UEs). The plurality of SVs may include the SV, and the integer n value may not be configured in any SV of a second plurality of SVs (e.g., one or more other groups of UEs). The portion of the key ID may comprise all bits in the integer n value and least significant bits in the integer m value. The key ID may be reconstructed (e.g., by the UE) based on the portion of the key ID and a last used integer m value, where the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed (e.g., by the UE) for a last SV with which the UE performed successful authentication for store and forward mode and from which the UE received the integer n value.

[0236] FIG. 14 is a diagram 1400 illustrating an example of a hardware implementation for an apparatus 1404. The apparatus 1404 may be a UE, a component of a UE, or may implement UE functionality. For example, the apparatus may correspond to UE 102, a component of the UE 102, or may implement the functionality or UE 102, such as any of the aspects performed by the UE 102 in any of FIGs. 7-9 or in the flowcharts in FIG. 10 or FIG. 12. In some aspects, the apparatus 1404 may include at least one cellular and satellite baseband processor 1424 (also referred to as a modem) coupled to one or more transceivers 1422 (e.g., cellular RF transceiver). The cellular and satellite baseband processor(s) 1424 may include at least one on-chip memory 1424'. In some aspects, the apparatus 1404 may further include one or more subscriber identity modules (SIM or USIM) cards 1420 and at least one application processor 1406 coupled to a secure digital (SD) card 1409 and a screen 1410. The application processor(s) 1406 may include on-chip memory 1406'. In some aspects, the apparatus 1404 may further include a Bluetooth module 1412, a wireless local area network (WLAN) module 1414, a satellite positioning service (SPS) module 1416 (e.g., a global navigation satellite system (GNSS) module), one or more sensor modules 1418 (e.g., a barometric pressure sensor / altimeter; a motion sensor, such as an inertial measurement unit (IMU), a gyroscope, and / or an accelerometer; and / or a positioning sensor, such as a light detection and ranging (LIDAR) sensor, a radio assisted detection and ranging (RADAR) sensor, a sound navigation and ranging (SONAR) sensor, a magnetometer, an audio sensor), additional memory modules 1426, a power supply (e.g., a battery) 1430, and / or a camera 1432. The Bluetooth module 1412, the WLAN module 1414, and the SPS module 1416 may include an on-chip transceiver (TRX) (or in some cases, just a receiver (RX)). The Bluetooth module 1412, the WLAN module 1414, and the SPS module 1416 may include their own dedicated antennas and / or utilize the antennas 1480 forcommunication. The cellular and satellite baseband processor(s) 1424 communicates through the transceiver(s) 1422 via one or more antennas 1480 with the UE 102, with an SV 104, and / or with an RU associated with a network entity 1402. The network entity 1402 may correspond to a ground based wireless communication network or a ground based entity, such as an SFC 202 or a gNB 406. As described herein, the apparatus 1404 may communicate with the ground based network via the SV 104. The cellular and satellite baseband processor(s) 1424 and the application processor(s) 1406 may each include a computer-readable medium / memory 1424' and 1406', respectively. The additional memory modules 1426 may also be considered a computer-readable medium / memory. Each computer-readable medium / memory (e.g., 1424', 1406’, and 1426) may be non-transitory. The cellular and satellite baseband processor(s) 1424 and the application processor(s) 1406 are each responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the cellular and satellite baseband processor(s) 1424 / application processor(s) 1406, causes the cellular and satellite baseband processor(s) 1424 / application processor(s) 1406 to perform the various functions described supra. The cellular and satellite baseband processor(s) 1424 and the application processor(s) 1406 are configured to perform the various functions described supra based at least in part of the information stored in the memory. That is, the cellular and satellite baseband processor(s) 1424 and the application processor(s) 1406 may be configured to perform a first subset of the various functions described supra without information stored in the memory and may be configured to perform a second subset of the various functions described supra based on the information stored in the memory. The computer-readable medium / memory may also be used for storing data that is manipulated by the cellular and satellite baseband processor(s) 1424 / application processor(s) 1406 when executing software. The cellular and satellite baseband processor(s) 1424 / application processor(s) 1406 may be a component of the UE 1850 and may include the at least one memory 1860 and / or at least one of the TX processor 1868, the RX processor 1856, and the controller / processor 1859. In one configuration, the apparatus 1404 may be at least one processor chip (modem and / or application) and include just the cellular and satellite baseband processor(s) 1424 and / or the application processor(s) 1406, and in another configuration, the apparatus 1404 may be the entire UE (e.g., UE 102 or UE 1850 of FIG. 18) and include the additional modules of the apparatus 1404.

[0237] The communication component 1498, or another component of the apparatus, may be further configured to perform, or to cause the apparatus to perform, any of the aspects performed by the UE 102 in any of FIGs. 7-9 and / or described in connection with the flowcharts in FIG. 10 or FIG. 12. The component 1498 may be within the cellular and satellite baseband processor(s) 1424, the application processor(s) 1406, or both the cellular and satellite baseband processor(s) 1424 and the application processor(s) 1406. The component 1498 may be one ormore hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by one or more processors, or some combination thereof. When multiple processors are implemented, the multiple processors may perform the stated processes / algorithm individually or in combination.

[0238] The apparatus may further include means for performing any of the aspects performed by a UE in any of FIGs. 7-9 and / or described in connection with the flowcharts in FIG. 10 or FIG. 12. The means may be the component 1498 of the apparatus 1404 configured to perform the functions recited by the means. As described supra, the apparatus 1404 may include the TX processor 1868, the RX processor 1856, and the controller / processor 1859. Therefore, in one configuration, the means may be the TX processor 1868, the RX processor 1856, and / or the controller / processor 1859 configured to perform the functions recited by the means.

[0239] FIG. 15 is a diagram 1500 illustrating an example of a hardware implementation for a network entity 1502. The network entity may correspond to an SV, a component of an SV, or may implement SV functionality, for example, as described for the SV 104 in any of FIGs. 7-9 and / or as described in FIG. 13. The network entity 1502 may include at least one processor 1542, which may include on-chip memory 1542'. In some aspects, the network entity 1502 may further include additional memory modules 1544 and a communications interface 1548, one or more transceivers 1546, antennas 1580, and a communications interface 1548. The network entity 1502 may be configured to communicate with the UE 102 (e.g., via a service link) and a ground based network entity 1402 (e.g., via a feeder link), as described in connection with any of FIGs. 7-9. The on-chip memory 1542' and the additional memory modules 1544 may each be considered a computer-readable medium / memory. Each computer-readable medium / memory may be non-transitory. The processor(s) 1542 are responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the corresponding processor(s) causes the processor(s) to perform the various functions described supra. The computer-readable medium / memory may also be used for storing data that is manipulated by the processor(s) when executing software.

[0240] The store and forward component 1599, or another component of network entity 1502, may be further configured to perform, or cause the network entity to perform, any of the aspects performed by the SV 104 described in connection with any of FIGs. 7-9 and / or performed by an SV as described for FIG. 13. The store and forward component 1599 may be within one or more processors of the network entity 1502. The store and forward component 1599 may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by one ormore processors, or some combination thereof. When multiple processors are implemented, the multiple processors may perform the stated processes / algorithm individually or in combination.

[0241] The network entity 1502 may further include means for performing any of the aspects performed by the SV 104 described in connection with any of FIGs. 7-9 or FIG. 13. The means may be the store and forward component 1599 of the network entity 1502 configured to perform the functions recited by the means. As described supra, the network entity 1502 may include the TX processor 1816, the RX processor 1870, and the controller / processor 1875. Therefore, in one configuration, the means may be the TX processor 1816, the RX processor 1870, and / or the controller / processor 1875 configured to perform the functions recited by the means.

[0242] FIG. 16 is a diagram 1600 illustrating an example of a hardware implementation for a network entity 1602. The network entity 1602 may be a server, a component of a server, or may implement server functionality. For example, the network entity 1602 may be configured to implement any of the aspects described for the SFC 202 described in connection with any of FIGs. 7-9 or in the flowchart in FIG. 11. The network entity 1602 may include at least one processor 1642, which may include on-chip memory 1642'. In some aspects, the network entity 1602 may further include additional memory modules 1644 and a communications interface 1648 for exchanging communication with one or more SVs 104 and with a ground based PLMN 108. In some aspects, the communications interface 1648 may include one or more transceivers 1646 and antennas 1680. The network entity 1602 may be configured to communicate with an SV 104 (e.g., via a feeder link) and with one or more ground based PLMNs 1610, such as ground based serving PLMN 108 or HPLMN 1408, as described in connection with any of FIGs. 3-6, FIGs. 7-9, and / or described in connection with the flowchart in FIG. 11. The on-chip memory 1642' and the additional memory modules 1644 may each be considered a computer- readable medium / memory. Each computer-readable medium / memory may be non-transitory. The processor(s) 1642 are responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the corresponding processor(s) causes the processor(s) to perform the various functions described supra. The computer-readable medium / memory may also be used for storing data that is manipulated by the processor(s) when executing software.

[0243] The store and forward component 1699, and / or another component of the network entity 1602, may be configured to perform, or cause the network entity to perform, any of the aspects performed by the SFC 202, as described in connection with any of FIGs. 3-6, FIGs. 7-9, and / or described in connection with the flowchart in FIG. 11. The store and forward component 1699 may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by one ormore processors, or some combination thereof. When multiple processors are implemented, the multiple processors may perform the stated processes / algorithm individually or in combination.

[0244] The network entity 1602 may further include means for performing any of the aspects performed by the SFC 202, as described in connection with any of FIGs. 3-6, FIGs. 7-9, and / or described in connection with the flowchart in FIG. 11. The means may be the store and forward component 1699 of the network entity 1602 configured to perform the functions recited by the means. As described supra, the network entity 1602 may include a TX processor, RX processor and / or controller / processer, similar to those described in connection with TX processor 1816, the RX processor 1870, and the controller / processor 1875. Therefore, in one configuration, the means may include one or more such processors configured to perform the functions recited by the means.

[0245] FIG. 17 is a diagram 1700 illustrating an example of a hardware implementation for a network entity 1760. In one example, the network entity 1760 may be within a core network. In some aspects, the network entity 1760 may be a UDM in an HPLMN (e.g., HPLMN 1408). In some aspects, the network entity 1760 may be an HSS in an HPLMN (e.g., HPLMN 1408). The network entity 1760 may include at least one network processor 1712. The network processor(s) 1712 may include at least one on-chip memory 1712'. In some aspects, the network entity 1760 may further include additional memory modules 1714. The network entity 1760 may communicate via the network interface 1780 directly (e.g., backhaul link) or indirectly (e.g., through a RAN intelligent controller (RIC)) with the SV 104 and / or the SFC 202 to enable secure data transfer between the UE 102 and an end point 116 via the SV 104 in a store and forward mode, for example, as described in connection with any of FIGs. 7-9. The on-chip memory 1712' and the additional memory modules 1714 may each be considered a computer-readable medium / memory. Each computer-readable medium / memory may be non- transitory. The network processor(s) 1712 is responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the corresponding processor(s) causes the processor(s) to perform the various functions described supra. The computer-readable medium / memory may also be used for storing data that is manipulated by the processor(s) when executing software.

[0246] The security component 1799, and / or another component of the network entity 1760, may be configured to perform, or cause the network entity to perform, any of the aspects performed by the PLMN 108 or the HPLMN 1408, as described in connection with any of FIGs. 7-9. The security component 1799 may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by one or more processors, or some combination thereof. Whenmultiple processors are implemented, the multiple processors may perform the stated processes / algorithm individually or in combination.

[0247] The network entity 1760 may further include means for performing any of the aspects performed by the PLMN 108 or the HPLMN 1408, as described in connection with any of FIGs. 7-9. The means may be the security component 1799 of the network entity 1760 configured to perform the functions recited by the means. As described supra, the network entity 1760 may include a TX processor, RX processor and / or controller / processer, similar to those described in connection with TX processor 1816, the RX processor 1870, and the controller / processor 1875. Therefore, in one configuration, the means may include one or more such processors configured to perform the functions recited by the means.

[0248] FIG. 18 is a block diagram of a network entity 1810 in communication with a UE 1850 (e.g., a UE 102) in an access network. In some aspects, the network entity 1810 may correspond to an SV 104. In some aspects, the network entity 1810 may correspond to a component of a ground based network, and the UE 1850 may communicate with the ground based network via an SV (e.g., as described in connection with FIGs. 7-9 or directly).

[0249] At the UE 1850, each receiver 1854Rx receives a signal through its respective antenna 1852. Each receiver 1854Rx recovers information modulated onto an RF carrier and provides the information to the receive (RX) processor 1856. The controller / processor 1859 can be associated with at least one memory 1860 that stores program codes and data. The at least one memory 1860 may be referred to as a computer-readable medium. In the UL, the controller / processor 1859 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, and control signal processing to recover IP packets. The controller / processor 1859 may also be responsible for error detection using an acknowledgement (ACK) and / or negative-acknowledgement (NACK) protocol to support hybrid automatic repeat request (HARQ) operations.

[0250] The UL transmission is processed at the network entity 1810 in a manner similar to that described in connection with the receiver function at the UE 1850. Each receiver 1818Rx receives a signal through its respective antenna 1820. Each receiver 1818Rx recovers information modulated onto an RF carrier and provides the information to a RX processor 1870.

[0251] The controller / processor 1875 can be associated with at least one memory 1876 that stores program codes and data. The at least one memory 1876 may be referred to as a computer-readable medium. In the UL, the controller / processor 1875 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover IP packets. The controller / processor 1875 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0252] In some aspects, DL IP packets may be provided to a controller / processor 1875. The controller / processor 1875 may implement layer 3 and layer 2 functionality. Layer 3 includes a radio resource control (RRC) layer, and layer 2 includes a service data adaptation protocol (SDAP) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The controller / processor 1875 may provide RRC layer functionality associated with broadcasting of system information (e.g., a machine information block (MIB) and / or an SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with the transfer of upper layer PDUs, error correction through automated repeat request (ARQ), concatenation, segmentation, and reassembly of RLC service data units (SDUs), re -segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0253] The transmit (TX) processor 1816 and the receive (RX) processor 1870 may implement layer 1 functionality associated with various signal processing functions. Layer 1, which includes a physical (PHY) layer, may include error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and multiple input and multiple output (MIMO) antenna processing. The TX processor 1816 may handles mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M- PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an orthogonal frequency division multiplexing (OFDM) subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from a channel estimator 1874 may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a reference signal and / or channel condition feedback transmitted by the UE 1850. Each spatial stream may then be provided to a different antenna 1820 via a separate transmitter 1818Tx.Each transmiter 1818Tx may modulate an RF carrier with a respective spatial stream for transmission.

[0254] The TX processor 1868 and the RX processor 1856 implement layer 1 functionality associated with various signal processing functions. The RX processor 1856 may perform spatial processing on the information to recover any spatial streams destined for the UE 1850. If multiple spatial streams are destined for the UE 1850, they may be combined by the RX processor 1856 into a single OFDM symbol stream. The RX processor 1856 then converts the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are recovered and demodulated by determining the most likely signal constellation points transmited by the network entity 1810. These soft decisions may be based on channel estimates computed by the channel estimator 1858. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmited by the network entity 1810 on the physical channel. The data and control signals are then provided to the controller / processor 1859, which implements layer 3 and layer 2 functionality.

[0255] Similar to the functionality described in connection with the DL transmission by the network entity 1810, the controller / processor 1859 provides RRC layer functionality associated with system information (e.g., an MIB and / or an SIB) acquisition, RRC connections, and measurement reporting; PDCP layer functionality associated with header compression / decompression, and security (ciphering, deciphering, integrity protection, integrity verification); RLC layer functionality associated with the transfer of upper layer PDUs, error correction through ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0256] Channel estimates derived by a channel estimator 1858 from a reference signal or feedback transmited by the network entity 1810 may be used by the TX processor 1868 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor 1868 may be provided to different antenna 1852 via separate transmiters 1854Tx. Each transmiter 1854Tx may modulate an RF carrier with a respective spatial stream for transmission.

[0257] The following provides an overview of some Aspects of the present disclosure:

[0258] Aspect 1 : A method of wireless communication performed by a user equipment (UE), comprising: receiving, from a space vehicle (SV) operating in a store and forward mode, anauthentication request that includes an identifier (ID) associated with the SV; determining a derived key from a master key that was provisioned to the UE and the ID associated with the SV, wherein the master key is different than a second key, associated with the UE, that was provisioned to a satellite store and forward center (SFC); and transmitting, to the SV, an authentication response that includes an authentication result determined from the derived key, wherein the authentication response is used to validate a first international mobile subscriber identity (IMSI) or subscription permanent identifier (SUPI) associated with the UE.

[0259] Aspect 2: The method of Aspect 1, wherein the authentication request further includes authentication challenge data, and the authentication result is further determined from the authentication challenge data.

[0260] Aspect 3: The method of any of Aspects 1-2, wherein the UE is further associated with a second IMSI or SUPI that is provisioned for the UE in the SFC.

[0261] Aspect 4: The method of Aspect 3, wherein the second IMSI or SUPI is different than the first IMSI or SUPI.

[0262] Aspect 5: The method of any of Aspects 3-4, wherein the second IMSI or SUPI is associated with at least one additional UE.

[0263] Aspect 6: The method of Aspect 3, wherein the second IMSI or SUPI is the same as the first IMSI or SUPI.

[0264] Aspect 7: The method of any of Aspects 3-6, wherein the authentication request and the authentication response comprise non-access stratum messages.

[0265] Aspect 8: A method of wireless communication performed by a satellite store and forward center (SFC), comprising: receiving, from a space vehicle (SV) operating in a store and forward mode, mobile originated (MO) data and a first international mobile subscriber identity (IMSI) or subscription permanent identifier (SUPI) for a user equipment (UE); determining a second IMSI or SUPI for the UE based on the first IMSI or SUPI; receiving, from a ground network, an authentication request; transmitting, to the ground network, an authentication response that includes an authentication result determined from a second key for the UE provisioned to the SFC, wherein the second key is different than a master key that was provisioned to the UE, and wherein the authentication response is used to validate the second IMSI or SUPI; and transmitting, to the ground network, the MO data in response to the second IMSI or SUPI being validated.

[0266] Aspect 9: The method of Aspect 8, wherein the authentication request further includes authentication challenge data, and the authentication result is further determined from the authentication challenge data.

[0267] Aspect 10: The method of any of Aspects 8-9, wherein the second IMSI or SUPI is the same as the first IMSI or SUPI.

[0268] Aspect 11 : The method of any of Aspects 8-9, wherein the second IMSI or SUPI is different than the first IMSI or SUPI.

[0269] Aspect 12: The method of Aspect 11, wherein the second IMSI or SUPI is associated with at least one additional UE.

[0270] Aspect 13: The method of any of Aspects 8-12, wherein the authentication request and the authentication response comprise non-access stratum messages.

[0271] Aspect 14: A method of wireless communication performed by a user equipment (UE), comprising: receiving, from a space vehicle (SV) operating in a store and forward mode, an authentication request that includes a portion of a key identifier (ID), wherein the portion of the key ID and a derived key are configured in the SV; reconstructing the key ID based on the portion of the key ID; determining the derived key from the key ID and a master key that was provisioned to the UE; and performing authentication with the SV using the derived key.

[0272] Aspect 15: The method of Aspect 14, wherein performing authentication with the SV using the derived key comprises: authenticating the SV using the derived key and the authentication request; and transmitting, to the SV, an authentication response in response to the SV being successfully authenticated, wherein the authentication response includes an authentication result determined from the derived key and the authentication request, and wherein the authentication result and the derived key configured in the SV can be used to authenticate the UE.

[0273] Aspect 16: The method of Aspect 15, wherein the authentication request further includes authentication challenge data, wherein the authentication challenge data includes the portion of the key ID, and wherein the authentication result is further determined from the authentication challenge data.

[0274] Aspect 17: The method of any of Aspects 14-16, wherein the portion of the key ID comprises least significant bits of the key ID.

[0275] Aspect 18: The method of any of Aspects 14-17, wherein reconstructing the key ID based on the portion of the key ID comprises: determining the key ID based on the portion of the key ID and a last used key ID, wherein the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for the store and forward mode.

[0276] Aspect 19: The method of Aspect 18, further comprising: storing the key ID in response to the authentication with the SV being successful; accessing an additional SV in the store and forward mode; receiving an additional authentication request from the additional SV, the additional authentication request including a portion of an additional key ID; and determining the additional key ID using the key ID as the previous key ID; and performing authentication with the additional SV using the additional key ID.

[0277] Aspect 20: The method of any of Aspects 14-19, wherein the key ID comprises an integer n value and an integer m value, wherein the integer n value is configured in each SV in a plurality of SVs that include the SV, and wherein the integer n value is not configured in any SV of an additional plurality of SVs.

[0278] Aspect 21 : The method of Aspect 20, wherein the portion of the key ID comprises all bits in the integer n value and least significant bits in the integer m value.

[0279] Aspect 22: The method of any of Aspects 20-21, wherein reconstructing the key ID based on the portion of the key ID comprises: determining the key ID based on the portion of the key ID and a last used integer m value, wherein the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode and from which the UE received the integer n value.

[0280] Aspect 23: The method of Aspect 22, further comprising: storing the integer m value in association with the integer n value in response to the authentication with the SV being successful; accessing an additional SV in the store and forward mode; receiving an additional authentication request from the additional SV, the additional authentication request including a portion of an additional key ID, wherein the portion of the additional key ID comprises the integer n value and least significant bits in an additional integer m value; determining the additional key ID using the integer m value as the previous integer m value to determine the additional key ID; and performing authentication with the additional SV using the additional key ID.

[0281] Aspect 24: A method of wireless communication performed by a space vehicle (SV) operating in a store and forward mode, comprising: sending, to a user equipment (UE), an authentication request that includes a portion of a key identifier (ID), wherein the portion of the key ID is configured in the SV, wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, and wherein the derived key is configured in the SV; and performing authentication with the UE using the derived key.

[0282] Aspect 25 : The method of Aspect 24, wherein performing authentication with the UE using the derived key comprises: enabling authentication of the SV using the derived key and the authentication request; receiving, from the UE, an authentication response in response to the SV being successfully authenticated, wherein the authentication response includes an authentication result determined from the derived key and the authentication request; and authenticating the UE using the authentication result and the derived key.

[0283] Aspect 26: The method of Aspect 25, wherein the authentication request further includes authentication challenge data, wherein the authentication challenge data includes theportion of the key ID, and wherein the authentication result can be further determined from the authentication challenge data.

[0284] Aspect 27 : The method of any of Aspects 24-26, wherein the portion of the key ID comprises least significant bits of the key ID.

[0285] Aspect 28: The method of any of Aspects 24-27, wherein the key ID can be reconstructed based on the portion of the key ID and a last used key ID, wherein the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for the store and forward mode.

[0286] Aspect 29: The method of Aspect 28, further comprising: receiving an additional derived key and at least a portion of an additional key ID from a trusted source at a first time; and performing authentication using the additional derived key and the portion of the additional key ID for the store and forward mode at or after a second time, wherein the second time is the same as, or occurs later than, the first time.

[0287] Aspect 30: The method of any of Aspects 24-29, wherein the key ID comprises an integer n value and an integer m value, wherein the integer n value is configured in each SV in a plurality of SVs that include the SV, and wherein the same value of the integer n value is not configured in any SV of an additional plurality of SVs.

[0288] Aspect 31 : The method of Aspect 30, wherein the portion of the key ID comprises all bits in the integer n value and least significant bits in the integer m value.

[0289] Aspect 32: The method of any of Aspects 30-31, wherein the key ID can be reconstructed based on the portion of the key ID and a last used integer m value, wherein the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed by the UE for a last SV with which the UE performed successful authentication for the store and forward mode and from which the UE received the integer n value.

[0290] Aspect 33: An apparatus for wireless communication at a device, the apparatus comprising one or more processors; one or more memories coupled with the one or more processors; and instructions stored in the one or more memories and executable by the one or more processors to cause the apparatus to perform the method of one or more of Aspects 1-32.

[0291] Aspect 34: An apparatus for wireless communication at a device, the apparatus comprising one or more memories and one or more processors coupled to the one or more memories, the one or more processors configured to cause the device to perform the method of one or more of Aspects 1-32.

[0292] Aspect 35: An apparatus for wireless communication, the apparatus comprising at least one means for performing the method of one or more of Aspects 1-32.

[0293] Aspect 36: A non-transitory computer-readable medium storing code for wireless communication, the code comprising instructions executable by one or more processors to perform the method of one or more of Aspects 1-32.

[0294] Aspect 37: A non-transitory computer-readable medium storing a set of instructions for wireless communication, the set of instructions comprising one or more instructions that, when executed by one or more processors of a device, cause the device to perform the method of one or more of Aspects 1-32.

[0295] Aspect 38: A device for wireless communication, the device comprising a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to cause the device to perform the method of one or more of Aspects 1-32.

[0296] Aspect 39: An apparatus for wireless communication at a device, the apparatus comprising one or more memories and one or more processors coupled to the one or more memories, the one or more processors individually or collectively configured to cause the device to perform the method of one or more of Aspects 1-32.

[0297] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects.

[0298] As used herein, the term “component” is intended to be broadly construed as hardware or a combination of hardware and at least one of software or firmware. “Software” shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, or functions, among other examples, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. As used herein, a “processor” is implemented in hardware or a combination of hardware and software. It will be apparent that systems or methods described herein may be implemented in different forms of hardware or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems or methods is not limiting of the aspects. Thus, the operation and behavior of the systems or methods are described herein without reference to specific software code, because those skilled in the art will understand that software and hardware can be designed to implement the systems or methods based, at least in part, on the description herein. A component being configured to perform a function means that the component has a capability to perform the function, and does not require the function to be actually performed by the component, unless noted otherwise.

[0299] As used herein, “satisfying a threshold” may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, or not equal to the threshold, among other examples.

[0300] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a + b, a + c, b + c, and a + b + c, as well as any combination with multiples of the same element (for example, a + a, a + a + a, a + a + b, a + a + c, a + b + b, a + c + c, b + b, b + b + b, b + b + c, c + c, and c + c + c, or any other ordering of a, b, and c).

[0301] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more.” Furthermore, as used herein, the terms “set” and “group” are intended to include one or more items and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” and similar terms are intended to be open-ended terms that do not limit an element that they modify (for example, an element “having” A may also have B). Further, the phrase “based on” is intended to mean “based on or otherwise in association with” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and / or,” unless explicitly stated otherwise (for example, if used in combination with “either” or “only one of’). It should be understood that “one or more” is equivalent to “at least one.”

[0302] Even though particular combinations of features are recited in the claims or disclosed in the specification, these combinations are not intended to limit the disclosure of various aspects. Many of these features may be combined in ways not specifically recited in the claims or disclosed in the specification. The disclosure of various aspects includes each dependent claim in combination with every other claim in the claim set.

Claims

WHAT IS CLAIMED IS:

1. An apparatus for wireless communication at a user equipment (UE), comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the UE to: receive, from a space vehicle (SV) operating in a store and forward mode, an authentication request that includes a portion of a key identifier (ID), wherein the portion of the key ID and a derived key are configured in the SV; reconstruct the key ID based on the portion of the key ID; determine the derived key from the key ID and a master key that was provisioned to the UE; and perform authentication with the SV using the derived key.

2. The apparatus of claim 1, wherein, to perform authentication with the SV using the derived key, the one or more processors are configured to cause the UE to: authenticate the SV using the derived key and the authentication request; and transmit, to the SV, an authentication response when the SV is successfully authenticated, wherein the authentication response includes an authentication result determined from the derived key and the authentication request, wherein the authentication result and the derived key configured in the SV can be used to authenticate the UE.

3. The apparatus of claim 2, wherein the authentication request further includes authentication challenge data, wherein the authentication challenge data includes the portion of the key ID, wherein the authentication result is further determined from the authentication challenge data.

4. The apparatus of claim 1, wherein the portion of the key ID comprises least significant bits of the key ID.

5. The apparatus of claim 1, wherein, to reconstruct the key ID based on the portion of the key ID, the one or more processors are configured to cause the UE to: determine the key ID based on the portion of the key ID and a last used key ID, wherein the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode.

6. The apparatus of claim 5, wherein the one or more processors are configured to cause the UE to: store the key ID when the authentication with the SV is successful; access a second SV in store and forward mode; receive a second authentication request from the second SV, the second authentication request including a portion of a second key ID; use the key ID as a new last used key ID to determine the second key ID; and perform authentication with the second SV using the second key ID.

7. The apparatus of claim 1, wherein the key ID comprises an integer n value and an integer m value, wherein the integer n value is configured in each SV in a plurality of SVs, the plurality of SVs including the SV, wherein the integer n value is not configured in any SV of a second plurality of SVs.

8. The apparatus of claim 7, wherein the portion of the key ID comprises all bits in the integer n value and least significant bits in the integer m value.

9. The apparatus of claim 7, wherein reconstructing the key ID based on the portion of the key ID comprises: determining the key ID based on the portion of the key ID and a last used integer m value, wherein the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode and from which the UE received the integer n value.

10. The apparatus of claim 9, wherein the one or more processors are configured to cause the UE to: store the integer m value in association with the integer n value when the authentication with the SV is successful; access a second SV in store and forward mode; receive a second authentication request from the second SV, the second authentication request including a portion of a second key ID, wherein the portion of the second key ID comprises the integer n value and least significant bits in a second integer m value; use the integer m value as a new last used integer m value to determine the second key ID; and perform authentication with the second SV using the second key ID.

11. A method of wireless communication performed by a user equipment (UE), comprising: receiving, from a space vehicle (SV) operating in a store and forward mode, an authentication request that includes a portion of a key identifier (ID), wherein the portion of the key ID and a derived key are configured in the SV; reconstructing the key ID based on the portion of the key ID; determining the derived key from the key ID and a master key that was provisioned to the UE; and performing authentication with the SV using the derived key.

12. The method of claim 11, wherein performing authentication with the SV using the derived key comprises: authenticating the SV using the derived key and the authentication request; and transmitting, to the SV, an authentication response when the SV is successfully authenticated, wherein the authentication response includes an authentication result determined from the derived key and the authentication request, wherein the authentication result and the derived key configured in the SV can be used to authenticate the UE.

13. The method of claim 12, wherein the authentication request further includes authentication challenge data, wherein the authentication challenge data includes the portion of the key ID, wherein the authentication result is further determined from the authentication challenge data.

14. The method of claim 11, wherein the portion of the key ID comprises least significant bits of the key ID.

15. The method of claim 11, wherein reconstructing the key ID based on the portion of the key ID comprises: determining the key ID based on the portion of the key ID and a last used key ID, wherein the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode.

16. The method of claim 15, further comprising: storing the key ID when the authentication with the SV is successful; accessing a second SV in store and forward mode; receiving a second authentication request from the second SV, the second authentication request including a portion of a second key ID;using the key ID as a new last used key ID to determine the second key ID; and performing authentication with the second SV using the second key ID.

17. The method of claim 11, wherein the key ID comprises an integer n value and an integer m value, wherein the integer n value is configured in each SV in a plurality of SVs, the plurality of SVs including the SV, wherein the integer n value is not configured in any SV of a second plurality of SVs.

18. The method of claim 17, wherein the portion of the key ID comprises all bits in the integer n value and least significant bits in the integer m value.

19. The method of claim 17, wherein reconstructing the key ID based on the portion of the key ID comprises: determining the key ID based on the portion of the key ID and a last used integer m value, wherein the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode and from which the UE received the integer n value.

20. The method of claim 19, further comprising: storing the integer m value in association with the integer n value when the authentication with the SV is successful; accessing a second SV in store and forward mode; receiving a second authentication request from the second SV, the second authentication request including a portion of a second key ID, wherein the portion of the second key ID comprises the integer n value and least significant bits in a second integer m value; using the integer m value as a new last used integer m value to determine the second key ID; and performing authentication with the second SV using the second key ID.

21. An apparatus for wireless communication performed by a space vehicle (SV) operating in a store and forward mode, comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the SV to: send, to a user equipment (UE), an authentication request that includes a portion of a key identifier (ID), wherein the portion of the key ID is configured in the SV,wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, wherein the derived key is configured in the SV; and perform authentication with the UE using the derived key.

22. The apparatus of claim 21, wherein, to perform authentication with the UE using the derived key, the one or more processors are configured to cause the SV to: enable authentication of the SV using the derived key and the authentication request; receive, from the UE, an authentication response when the SV is successfully authenticated, wherein the authentication response includes an authentication result determined from the derived key and the authentication request; and authenticate the UE using the authentication result and the derived key.

23. The apparatus of claim 22, wherein the authentication request further includes authentication challenge data, wherein the authentication challenge data includes the portion of the key ID, wherein the authentication result can be further determined from the authentication challenge data.

24. The apparatus of claim 21, wherein the portion of the key ID comprises least significant bits of the key ID.

25. The apparatus of claim 21, wherein the key ID can be reconstructed based on the portion of the key ID and a last used key ID, wherein the last used key ID is either an initial key ID configured in the UE or a previous key ID reconstructed by the UE for a last SV with which the UE performed successful authentication for store and forward mode.

26. The apparatus of claim 25, wherein the one or more processors are configured to cause the SV to: receive a second derived key and at least a portion of a second key ID from a trusted source at a first time; and use the second derived key and the portion of the second key ID to perform authentication with a plurality of UEs for store and forward mode at or after a second time, wherein the second time is the same as, or occurs later than, the first time.

27. The apparatus of claim 21, wherein the key ID comprises an integer n value and an integer m value, wherein the integer n value is configured in each SV in a plurality of SVs, theplurality of SVs including the SV, wherein the integer n value is not configured in any SV of a second plurality of SVs.

28. The apparatus of claim 27, wherein the portion of the key ID comprises all bits in the integer n value and least significant bits in the integer m value.

29. The apparatus of claim 27, wherein the key ID can be reconstructed based on the portion of the key ID and a last used integer m value, wherein the last used integer m value is either an initial integer m value configured in the UE in association with the integer n value or a previous integer m value reconstructed for a last SV with which the UE performed successful authentication for store and forward mode and from which the UE received the integer n value.

30. A method of wireless communication performed by a space vehicle (SV) operating in a store and forward mode, comprising: sending, to a user equipment (UE), an authentication request that includes a portion of a key identifier (ID), wherein the portion of the key ID is configured in the SV, wherein the portion of the key ID enables reconstruction of the key ID, wherein the key ID enables determination of a derived key from a master key that was provisioned to the UE, wherein the derived key is configured in the SV; and performing authentication with the UE using the derived key.

Images