Method, apparatus, and system for enhanced authentication, authorization, and connection management in cellular networks

Abstract

This invention describes a method, apparatus, and system for authenticating, authorizing, and managing a connection in a cellular system to allow a user to retrieve / send some data, e.g., from / to an application function (AF) or to communicate with another remote user over multiple networks in an optimized / secure manner. The user may have one or multiple devices (UEs) using (e.g., connected to) multiple / different networks, e.g., a device with multiple subscriber identity modules (SIMs) and / or different radio access technologies.

Description

[0001] METHOD, APPARATUS, AND SYSTEM FOR ENHANCED AUTHENTICATION, AUTHORIZATION, AND CONNECTION MANAGEMENT IN CELLULAR NETWORKS

[0002] FIELD OF THE INVENTION

[0003] This invention relates to a system for enhanced communication with a device connected to one or multiple networks or using one or more radio access technologies, e.g., a device using a terrestrial network and / or a non-terrestrial network or a device downloading data through two different cellular core networks.

[0004] BACKGROUND OF THE INVENTION

[0005] In conventional cellular networks, a primary station serves a plurality of secondary stations located within a cell served by this primary station. Wireless communication from the primary station towards each secondary station is done on downlink channels. Conversely, wireless communication from each secondary towards the primary station is done on uplink channels. The wireless communication can include data traffic (sometimes referred to as “user data”), and control information (sometimes referred to as “signalling”). This control information typically comprises information to assist the primary station and / or the secondary station to exchange data traffic (e.g., resource allocation / requests, physical transmission parameters, information on the state of the respective stations).

[0006] In the context of cellular networks as standardized by 3GPP, the primary station is referred to a base station, or a gNodeB (or gNB) in 5G (NR) or an eNodeB (or eNB) in 4G (LTE). The eNB / gNB is part of the Radio Access Network RAN, which interfaces to functions in the Core Network (CN). In the same context, the secondary station corresponds to a mobile station, or a User Equipment (or a UE) in 4G / 5G, which is a wireless client device or a specific role played by such device. The term “node” is also used to denote either a UE or a gNB / eNB.

[0007] Additionally, for example, in the case of a PC5 interface or sidelink communication, it is possible to have direct communication between secondary stations, here UEs. It is then also possible for UEs to operate as Relays to allow for example out of coverage UEs to get an intermediate (or indirect) connection to the eNB or gNB. To be able to work as a relay, a UE may use discovery messages to establish new connections with other UEs.

[0008] Therefore, the role of a relay node has been introduced in 3rd Generation Partnership Project (3 GPP. which is a partnership project bringing together national Standards Development Organizations (SDOs) from around the globe initially to develop technical specifications for the 3rd generation of mobile, cellular telecommunications). This relay node is a wireless communication station that includes functionalities for relaying communication between a primary station, e.g., a gNB and a secondary station, e.g., a UE. This relay function may for example allow to extend the coverage of a cell to an out-of-coverage (OoC) secondary station. This relay node may be a mobile station or could be a different type of device. In the specifications for 4G, the Proximity Services (ProSe) functions are defined inter alia in 3GPP specifications TS 23.303 and TS 24.334 to enable - amongst others - connectivity for a cellular User Equipment (UE) that is temporarily not in coverage of the cellular network base station (e.g., eNB) serving the cell. This particular function is called ProSe UE-to-network relay, or “Relay UE” for short. The Relay UE relays application and network traffic in two directions between the OoC UE and the eNB. The local communication between the Relay UE and the OoC UE is called device-to-device (D2D) communication or Sidelink (also known as PC5) communication in 3GPP TS 23.303 and TS 24.334. Once the relaying relation is established, the OoC-UE is, e.g., IP- connected via the Relay UE and acts in a role of “Remote UE”. This situation means the Remote UE has an indirect network connection to selected functions of the Core Network as opposed to a direct network connection to all Core Network functions that is the normal case.

[0009] Further, it has been introduced the role of a UE-to-UE relay node, i.e., a relay node relaying the communication between two UE devices. The relay node relays the communications between UE devices. UEs may connect to the core network through a base station when in-coverage. In such relay scenarios, the relay devices may receive and store some information for some time before forwarding it towards the target device. This information that may be stored and forwarded may be discovery messages received from a source UE whereby the relay UE may release them at some point of time later. This information that may be stored and forwarded may be a SIB that may contain a timestamp.

[0010] Furthermore, cellular networks are evolving to enable more mobile access devices such as satellites, unmanned aerial vehicles, buses or trains that are capable of storing data for some time before forwarding it further. An example relates to a satellite that receives and stores certain data when it is close to a terrestrial gateway and only releases it when the receiving party becomes in coverage. Such mobile access devices may work in a transparent manner or in a regenerative manner. In a transparent mode, the mobile access device acts as a reflector / smart repeater that retransmits the communication sent by, e.g., a gateway, e.g., a Non-Terrestrial Network gateway, towards a UE. In a regenerative mode, the mobile access device works as a base station and is able to setup a connection with a UE. In store and forward mode, the mobile access device may be able to cache same data obtained from the UE or NTN gateway and transmit it when it is within communication range of the receiver.

[0011] Moreover, cellular networks are evolving to allow for dual steer wherein UEs can get access through multiple networks (different networks and different radio access technologies such as terrestrial and non-terrestrial networks). In this case, it is required to coordinate access through those different networks. 3GPP TR 22.841 captures a set of use cases and potential service requirements related to 5G system support of traffic steering, splitting and switching of UE’s user data (pertaining to the same data session), across two 3GPP access networks.

[0012] Furthermore, the usage of a radio access technology such as a non-terrestrial network using satellites may introduce further challenges or opportunities. For instance, the storage functionality of satellites may interfere with the current operation of security procedures. Similarly, the large coverage of satellites may also allow UEs to directly communicate with each other.

[0013] These situations lead to multiple challenges, for instance, how to authenticate a UE and allow the UE to establish a subsequent connection.

[0014] SUMMARY OF THE INVENTION

[0015] It is an object of the present invention to address the above desirable features by enabling enhanced security procedures that allow a device to authenticate, establish a connection, and communicate data when connected to one or multiple core networks or different radio access technologies such as non-terrestrial networks.

[0016] This object is achieved by a method, by an apparatus, by a user equipment, and by a computer program product as defined in the appended claims.

[0017] According to a first aspect of the invention, it is proposed a method for operating an apparatus to manage a connection wherein the method comprises: the apparatus checking or selecting a preferred authentication procedure; the apparatus performing the preferred authentication procedure with a first core network through a first access device; and the apparatus setting up a connection with the first core network.

[0018] According to a second aspect of the invention, it is proposed an apparatus comprising a receiver, a transmitter, a controller, and a medium storage including instructions to perform a method for managing a connection, comprising: the apparatus checking or selecting a preferred authentication procedure; the apparatus performing the preferred authentication procedure with a first core network through a first access device; and the apparatus setting up a communication connection with the first core network.

[0019] According to a third aspect of the invention, it is proposed a user equipment comprising the apparatus of the first aspect. According to a fourth aspect of the invention, it is proposed a computer program product comprising code means for producing the steps of the methods of the first aspect, when run on a computer device.

[0020] In a first variant of any of the first to fourth aspect of the invention, the apparatus checking or selecting a preferred authentication procedure comprises receiving a store and forward indication from the first access device and determining the preferred authentication procedure based on the indication and a configuration stored in the apparatus. Optionally, the method further comprises receiving, by the apparatus, a first authentication message, wherein the determining of the preferred authentication procedure is also based on the first authentication message.

[0021] In another variant which may be combined with the first variant or used in any of the first to fourth aspects of the invention, the first access device is on a satellite, and the preferred authentication procedure is one of: an authentication procedure with the first core network on the ground when the first access device does not indicate store and forward mode; or an authentication procedure with the first core network in the satellite when the first access device indicates store and forward mode and the apparatus has credentials; or an authentication procedure with the first core network in the satellite when the first access device does not indicate store and forward mode and the apparatus has credentials and a configuration preferring absence of the store and forward mode.

[0022] In another variant, the preferred authentication method is an authentication procedure preferred by the first access device. Optionally, the checking or selecting the preferred authentication procedure includes the apparatus transmitting at least a first identifier and a second identifier, the first identifier for a first authentication procedure and the second identifier for a second authentication procedure; and the apparatus receiving a message with an indication of the preferred authentication procedure selected by the first access device.

[0023] In another variant which may be combined with any of the variants or aspects of the invention, the method further comprises the apparatus performing an authentication procedure with the first core network on ground through the first access device, the apparatus receiving a first update message with parameters of an authentication procedure with the first core network in a satellite. In another variant, the method further comprises the apparatus performing an authentication procedure with the first core network through the first access device, the apparatus receiving a first update message, said first update message comprising a presence parameter indicative of a presence or absence of a list of satellite access device identifier(s), wherein the list of satellite access device identifiers lists candidate access devices that the apparatus may connect to access the first core network.

[0024] In another variant, the method further comprises: the apparatus receiving a first update message, wherein the first update message comprises a updated list of satellite access device identifiers and / or a timer, the method comprising the apparatus updating a list of satellite access device identifiers stored on the apparatus, and wherein the timer is indicative of a time window during which a listed access device is expected to provide a Non-Terrestrial Network, NTN, service or a time estimate to the nextNTN gateway.

[0025] In another variant, the method further comprises: the apparatus receiving a first update message, wherein the first update message comprises a first list of access device identifiers, the apparatus receiving a second update message, wherein the second update message comprises a second list of access device identifiers, and the apparatus updating the first list of access device identifiers with the second list of access device identifiers.

[0026] Optionally the method may further comprise: receiving, by the apparatus, a first configuration, the first configuration comprising an authorized access device identifier. For example, the method comprises verifying, by the apparatus, whether the access device identifiers received in the first update message and / or second update message are authorized to be used by means of the first configuration.

[0027] In a variant, the preferred authentication procedure is an authentication procedure with a first core network in the first access device and the method comprises: the apparatus storing a root key arranged to derive a first authentication key; the apparatus receiving a first message from the first access device containing one of:

[0028] - an indication whether the first authentication key needs to be updated based on a first value m, wherein the first value m is transmitted in a field and indicates the version of the first authentication key, or

[0029] - a first value m indicating part of a first authentication key identity.

[0030] Optionally, the first value of m is transmitted implicitly. In another variant, the preferred authentication procedure is an authentication procedure with a first core network in the first access device and the method comprises: the apparatus storing a root key arranged to derive a first authentication key; the apparatus receiving a first message from the first access device containing an authentication token, wherein the authentication token includes a sequence number and an authentication code, the apparatus determining a first value from the sequence number, wherein the first value indicates a version of the first authentication key, the apparatus computing a second authentication key from the first value, the apparatus verifying the authentication code by means of the first and / or second authentication key.

[0031] In another variant, the preferred authentication procedure is an authentication procedure with a first core network in the first access device; and the method comprises: the apparatus storing a root key arranged to derive a first authentication key identified by a first authentication key identifier; the apparatus receiving a first message from the first access device containing an encrypted field including a received first authentication key identifier, the apparatus decrypting the encrypted field by means of the first authentication key and determining whether the first authentication key used in the decryption is correct by checking whether the decrypted received first authentication key identifier matches the first key authentication identifier, and depending on the outcome of the first authentication key identifier verification, the apparatus performing one or a combination of the following:

[0032] ■ proceeding with the processing of the first message when the first authentication key used in the decryption is classified as correct;

[0033] ■ attempting to decrypt the encrypted field with a second authentication key if the first authentication key is classified as incorrect; and

[0034] ■ sending an authentication response containing a failure message indicating the failure cause.

[0035] In any of the previous two variants, the verification by means of the second authentication key may trigger the usage of the second authentication key instead of the first authentication key when performing the preferred authentication procedure and the storage of the fust value.

[0036] In another variant, the first authentication key is identified by a function of a second value n transmitted in an AMF field and the first value m, and the apparatus stores a list of (n,m) tuples, where each tuple indicates whether the first authentication key with which it is associated, is enabled or disabled.

[0037] In another variant, the method comprises deriving the first authentication key from the root key based on a key derivation function, and the derivation function uses one or more input parameters; the one or more input parameters change when all values of the first value m are used; and the one or more input parameters comprise the root key and / or an identifier indicating that all values of the first value m are used, and / or an indicator of the first authentication key version.

[0038] In another variant, the apparatus receives a sequence number, SQN, in the first message and retrieves a local sequence number SQN’ identified by one of: an 8-bit value, IND; or a number of satellite identifiers, being a value n; or

[0039] IND and a subset of bits of n.

[0040] In another variant, a successful authentication procedure with apparatus or the reception of a confirmation message from a managing entity causes the first access device to send a request message to the managing entity requesting a new first authentication key .

[0041] Optionally, the request message comprises one or more of: the next sequence number, and proof from the apparatus of the successful execution of the authentication procedure, and the confirmation message includes one or more of: fresh m value, the next sequence number, a new first authentication key.

[0042] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

[0043] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0044] BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In the following drawings:

[0046] Fig. 1 schematically shows block diagrams of network architectures connecting to multiple networks or through different radio access technologies; Fig. 2 schematically shows block diagrams and communication paths through multiple networks and / or through different radio access technologies;

[0047] Fig. 3 schematically shows block diagrams and communication paths through multiple networks and / or through different radio access technologies;

[0048] Fig. 4 schematically shows block diagrams and communication paths through multiple networks;

[0049] Fig. 5 schematically describes the components of a DualSteer device; and

[0050] Fig. 6 schematically shows a wireless system based on cellular networks.

[0051] DETAILED DESCRIPTION OF EMBODIMENTS

[0052] Dual steer (R19) is a SAI study item reflected in TR 22.841 of 3GPP. The TR includes multiple use cases (UC) in which UEs can access through multiple networks (different PLMNs, TN, NTN, etc) and it is required to coordinate access through those different networks. The TR captures a set of use cases and potential service requirements related to 5G system support of traffic steering, splitting and switching of UE’s user data (pertaining to the same data session), across two 3GPP access networks. Different scenarios are covered: same Public Land Mobile Network (PLMN), two PLMNs, or between a PLMN and a non-public network (NPN), solely considering a single PLMN subscription. Use cases cover various example combinations of 3GPP access networks using same or different radio access technology (RAT), including terrestrial New Radio (NR) plus NR or NR plus Evolved UMTS Terrestrial Radio Access (E-UTRA) (e.g. using a combined Evolved Packet Core (EPC) and 5G Core Network (5GC)), mix of terrestrial plus satellite NR, as well as dual NR satellite access (e.g. using same or different non-terrestrial network (NTN) orbits, e.g., Geostationary Equatorial Orbit (GEO) / Medium Earth Orbit (MEO) / Low Earth Orbit (LEO)). In case of inter-PLMN / NPN scenarios, a proper business agreement is assumed to be in place between the two network operators (no impact on normal inter- PLMN roaming), and UE’s user data transferred over the two networks is anchored in the home PLMN (HPLMN) core network.

[0053] Prior to the SAI study summarized in TR 22.841, there has been already work allowing access over multiple networks. A current architecture is described in clause 4.2.10 of TS 23.501. For instance, Fig. 4.2.10-1 in TS 23.501 describes the architecture for non-roaming and roaming with Local Breakout architecture for ATSSS support. The N1 interface is responsible for the communication of NAS signalling messages between the user equipment (UE) and the access and mobility management function (AMF) and it goes in this case over two different types of access networks. It is used for registration management, connection management, and session management. The N2 interface is used for communication between the Radio Access Network and the core network. The N3 interface is used for providing user plane connectivity between the 5G RAN and the 5GC. The N3 interface provides user plane connectivity between the 5G RAN and the 5GC, uses the GPRS tunnelling protocol GTP-U for tunneling user data, supports new packet data unit (PDU) session container for 5G user plane encapsulation, separates N3 instance for each connection if the same PDU session is connected to multiple data networks. The N4 interface is the interface between the session management function (SMF) and the user plane function (UPF), SMF uses this interface to control the UPF and handle user plane packet forwarding, buffering, duplication, and dropping. Tasks of the N4 interface are the control of the activation, modification, and deactivation of QoS flows, monitoring the status of the N4 session, including the status of the user plane and QoS flows; sending and receiving UP function related information, such as statistics and congestion status; handling security related issues and perform authentication and authorization for the UP function; and providing the UPF with the necessary information for the UP function to perform the required actions for the user plane traffic, such as IP address allocation, and routing information.

[0054] Furthermore, device-to-device communication and proximity services have been standardized in 4G and 5G allowing communication between UEs, e.g., direct communication between two UEs, communication of a remote UE over a relay UE with the CN, or UE-to-UE relay communication.

[0055] Furthermore, 3GPP SA2 group is studying in TR 23.700-29-020 enhancements to integrate satellite components in the 5G architecture. In this context, a serving satellite refers to a satellite providing the satellite access to a UE (e.g. providing the serving cell(s)). Depending on the orbit, the serving satellite is covering a given geographic area for a limited period of time;

[0056] S&F (Store and Forward) Satellite operation: operation mode providing communication service (in storing and forwarding information) to a UE in periods of time and / or geographical areas in which the serving satellite is not simultaneously connected to the ground network via feeder link or ISL. For the case of UL, "store" refers to on-board storage of UL information from UE and "forward" refers to forwarding of stored UL information to the ground network. For the case of DL, "store" refers to on-board storage of DL information from the ground network and "forward" refers to forwarding of stored DL information to the UE.

[0057] Embodiments of the present invention are now described based on a cellular communication network environment, such as 5G. However, the present invention may also be used in connection with other wireless technologies in which TI or metaverse applications are provided or can be introduced. The present invention may also be applicable to other applications such as video streaming services, video broadcasting services, or data storage.

[0058] Throughout the present disclosure, the abbreviation “gNB” (5G terminology) or “BS” (base station) is intended to mean a wireless access device such as a cellular base station or a WiFi access point or a ultrawide band (UWB) personal area network (PAN) coordinator. The gNB may consist of a centralized control plane unit (gNB-CU-CP), multiple centralized user plane units (gNB- CU-UPs) and / or multiple distributed units (gNB-DUs). The gNB is part of a radio access network (RAN), which provides an interface to functions in the core network (CN). The RAN is part of a wireless communication network. It implements a radio access technology (RAT). Conceptually, it resides between a communication device such as a mobile phone, a computer, or any remotely controlled machine and provides connection with its CN. The CN is the communication network’s core part, which offers numerous services to customers who are interconnected via the RAN. More specifically, it directs communication streams over the communication network and possibly other networks.

[0059] Furthermore, the terms “base station” (BS) and “network” may be used as synonyms in this disclosure. This means for example that when it is written that the “network” performs a certain operation it may be performed by a CN function of a wireless communication network, or by one or more base stations that are part of such a wireless communication network, and vice versa. It can also mean that part of the functionality is performed by a CN function of the wireless communication network and part of the functionality by the base station.

[0060] Dual steer: basic introduction

[0061] The following embodiments are directed to enhanced authentication in a wireless system to allow a user to retrieve / send some data, e.g., from / to an application function (AF) or to communicate with another remote user over multiple networks in an optimized / secure manner.

[0062] Fig. 1 schematically shows block diagrams of network architectures connecting to multiple networks or through different radio access technologies.

[0063] The network architecture comprises a first user equipment (UE1) 100, in which first and second SIMs 101, 102 may be installed. Additionally, a second user equipment (UE2) 103 is provided, in which first and second SIMs 104, 105 may be installed.

[0064] The first and second UEs 100, 103 may comprise respective sensors 126, 127 that may be used for biometric-enhanced authentication / authorization.

[0065] A communication interface 120 is configured to allow direct communication between the first and second UEs 100, 103, e.g., a PC5 interface in 5G.

[0066] Furthermore, the network architecture comprises a radio access network (RAN) 106 with two or more access devices (e.g., gNBs) 107, 108 of a cellular network, wherein the first access device 107 may be configured to serve the first SIM 101 of the first UE 100 (or the first SIM 104 of the second UE 103) and the second access device 108 may be configured to serve the first and / or the second SIM 102 of the first UE 100 (or the first and / or second SIM 105 of the second UE 103. Standard communication interfaces 121, 122 (e.g., Un interfaces in 5G) are provided between the RAN 106 and the first and second UEs 100,103.

[0067] Additionally, a first core network 109 of the cellular network comprises network functions 110 to 113, e.g., an access and mobility management function (AMF), an authentication server function (AUSF), a unified data repository (UDR), an AKMA anchor function AAnF, a network exposure function (NEF), a location management function (LMF), and the like.

[0068] Moreover, a second core network 114 of the cellular network is provided, which comprises network functions 115 to 118, e.g., an access and mobility management function (AMF), an authentication server function (AUSF), a unified data repository (UDR), an AKMA anchor function (AAnF), a network exposure function (NEF), a location management function (LMF), and the like.

[0069] Further, an application function (AF) 119 is provided, which is a control plane function that provides application services to subscribers, e.g., for video streaming service. If the AF 119 is trusted, it can interact directly with above core network functions or if it is a third party, then it could interact with an NEF.

[0070] The User Plane Function allows a UE to access the data network. The UPF may be controlled by the SMF via the N4 interface.

[0071] In addition, the network architecture of Fig. 1 comprises a different type of device 123 (e.g., an unmanned aerial vehicle (UAV) such as a satellite) that is configured to provide connectivity to one or more UEs, e.g., the first UE 100 and / or the second UE 103. The different type of device 123 may be configured to use a different type of RAT, wherein a first communication interface 124 is provided between the RAN 106 or a local gateway towards the different type of device 123. Furthermore, a second communication interface 125 is provided between the different type of device 123 and the first UE 100.

[0072] In the context of dual steer, a UE 100 may have two SIMs, and may refer to a dual steer device as per the current definition in TS 22.841 comprising two logical “UEs” allowing for simultaneous data transmission over two networks or a single UE in case of non-simultaneous data transmission over two networks, but in the context of this invention a single UE may also be used in case of simultaneous data transmission over two networks or RATs.

[0073] A SIM contains the credentials of a user including the user identity (e.g., a subscription permanent identifier (SUPI), IMSI, or PEI) or other keys used to perform primary authentication according to TS 31.102. The SIMs of a UE may belong to the same core network or to two different core networks.

[0074] In the architecture of Fig. 1, several embodiments may be implemented, for instance:

[0075] In a first embodiment, only the first UE 100 is present and uses both SIMs 101, 102 for using (registering / accessing) the same network.

[0076] In a second embodiment, only the first UE 100 is present and uses both SIMs 101, 102 for using (registering / accessing) different networks.

[0077] In a third embodiment, only the first UE 100 is present and uses only the first SIM 101 for uses (accessing) different networks / RATs (Radio Access Technology).

[0078] In a fourth embodiment, both first and second UEs 100 and 103 are present (which in case of DualSteer may be two logical UEs in the same DualSteer device), wherein the first UE 100 includes its first SIM 101 and the second UE 103 includes its first SIM 104 and both SIMs 101, 104 are associated to the same or different networks.

[0079] The SIMs 101, 102, 104, 105 may be physical SIMs or eSIMs that may be installed in an embedded universal smart circuit card (USCC). An eSIM is an industry -standard digital SIM that allows activating a mobile plan from a network provider without having to use a physical SIM.

[0080] Given the above architectures of Fig. 1, different embodiments are proposed to improve the authentication and authorization procedures in cellular networks.

[0081] A first scenario considers a UE that has one, two, or more (e)SIM cards and is associated or connected to different networks and / or is capable of two different radio access technologies, in particular TN andNTN. It is also assumed that the network(s) potentially support a combined procedure, e.g., communication procedure or positioning procedure or sensing procedure, e.g., a combined AKMA procedure. In the case of AKMA, we can further assume that the UE desires to access an application function, e.g., external (i.e., in the Internet) or internal to one of the networks. The challenge consists in potentially sharing the network resources of both networks to ensure that the combined communication / sensing / positioning procedure can be performed, e.g., that the AKMA-secured data exchanged between UE and AF can be exchanged over both networks and successfully combined at UE / AF.

[0082] In an embodiment addressing this scenario, network access (random access) and / or primary authentication is performed by the UE 100 for both SIM 101 and 102 (whereby SIM 101 and SIM 102 could be operated by two “logical” UEs within a same DualSteer device) with the core network of both networks, e.g., the first core network (PLMN1) 109 and the second core network (PLMN2) 114. This means that the UE 100 may perform network access over a first RAN (e.g., RAN 106) and a subsequent primary authentication with the first network, PLMN1 109, and then a subsequent primary authentication with the second network, PLMN2 114. This means that the UE 100 uses the first SIM

[0083] 101 for the security process with the first network PLMN1 109 and the UE 100 uses the second SIM

[0084] 102 for the security process with the second network PLMN2 114. In some cases, one of the PLMNs may act as the serving PLMN of the other PLMN, e.g., PLMN1 109 may act as the serving PLMN of PLMN2 114. In this case, PLMN1 109 may have keying materials (e.g., key K SEAF of the security anchor function, key K AMF of the access and mobile management function, etc.) and UE identifiers (e.g., a subscription permanent identifier (SUPI) which may be a string of 15 decimal digits, of which the first three digits represent the Mobile Country Code (MCC), the next two or three represent the Mobile Network Code (MNC) identifying the network operator) for both SIMs 101, 102 in the UE 100. This may be used by the serving PLMN for a better service provisioning.

[0085] In a related embodiment, network access / primary authentication is performed by the first UE 100 for SIM 101 using two different radio access technologies (RAT), e.g., terrestrial and nonterrestrial. For instance, the UE 100 may do network access / primary authentication over a terrestrial access device (e.g., a gNB) and the network may check that the UE 100 is also authorized to use a nonterrestrial RAT / access device, so that the UE 100 also connects over the non-terrestrial link. The UE 100 in this case may be a mobile device such as a boat or a UAV. The network can check that / whether the UE 100 is authorized to use a non-terrestrial RAT / access device in the UE subscription policy that may be stored in the unified data management (UDM) / unified data repository (UDR) / SIM. When this is detected, the network may contact a non-terrestrial gateway, e.g., a satellite gateway, to inform about the upcoming connection. The network may retrieve information about the non-terrestrial RAT / access device to use, and the network may inform the UE 100 about it over the terrestrial RAT so that the UE 100 can connect to the non-terrestrial RAT / access device.

[0086] Similarly, UE 100 may use SIM 102 (which may be operated by a separate “logical” UE within the same device) to connect over the non-terrestrial RAT / access device. Thus, the UDM / UDR may link the two SIMs and / or stores which of the two SIMs can connect to which RAT (which may be different or the same for both) and / or whereby the two SIMs have stored information to associate the two SIMs and / or which of the two SIMs can connect to which RAT (which may be different or the same for both). Similarly, UE 100 and UE 103 (which may be operated in the same device) may communicate with each other and / or may have stored information in their respective SIMs to associate the two UEs and / or which of the two UEs can connect to which RAT (which may be different or the same for both). Such information may also be stored in the UDM / UDR.

[0087] In a related embodiment, the UE 100 may require some services, e.g., AKMA services between the UE 100 and the AF119, and to this end, the UE 100 may need to choose how (over which networks / RAT) the services, e.g., AKMA services, are provided. The UE 100 may then send an indication (e.g. about which services it requires) to the first core network (PLMN1) 109 and / or the second core network (PLMN2) 114. The UE 100 may also have a policy determining which services can be performed over which network / RAT and may route those services accordingly. The policy may be stored in one or more of its SIM cards and / or stored and operated by one or more of its “logical UEs'. In case that a service can be provided by more than a single network / RAT, the UE 100 may decide to apply a multipath configuration giving an indication to the network about this. In case that the service is routed through two or more networks, one of the networks may act as a master network coordinating the service delivery with the rest of the networks.

[0088] In a related embodiment, the UE 100 may require a given service (e.g., AKMA, or communication, or sensing, or positioning, etc) and to this end, the UE 100 may need to choose how the service is preferred to be provided or delivered. This choice may be based a policy. The policy may be stored in the core network (e.g., UDM / UDR, PCF, SMF...) or UE (e.g., SIM). This choice may also be taken by one of the networks, e.g., a master network as in the previous embodiment variant. The UE 100 may then send an indication (e.g. about which services it requires) to the first core network 109 and / or the second core network 114. The indication to the first core network 109 may be NAS-protected. For instance, a network may wish to deliver positioning services to a UE that requires such positioning services. However, the terrestrial network the UE 100 is connected to offer low accuracy. Thus, the network or the UE 100 may choose to add additional anchor devices (i.e., devices used to determine the location of the UE 100) based on non-terrestrial access devices such as LEO satellites or unmanned aerial vehicles. The UE 100 may be informed by the network about the positioning parameters used by suitable non-terrestrial access devices, e.g., satellites. These positioning parameters may include frequency / timing of positioning signals, identity of positioning signals, etc.

[0089] In a related embodiment that may be combined with other embodiments or used independently, each SIM (for example when active) has and / or is connected to a policy / user subscription that determines whether it allows for a Dual Steer connection. A user may select in his / her UE which of the SIMs is acting as the primary / initial SIM to connect to the network. A user may select in his / her UE whether a Dual Steer SIM may be used as a Dual Steer SIM enabling Dual Steer connections or not. When a UE, e.g., 100, registers / requests a Dual Steer connection for its both SIMs (e.g., 101 and 102), the core network may determine whether the connection may be Dual Steer or not.

[0090] The above embodiments may help to identify which policies may be needed to support DualSteer traffic steering and switching, in particular:

[0091] - Whether and what policies needs to be provided by the HPLMN to guide the DualSteer device to decide to connect to an additional PLMN / PNI-NPN, or an additional 3 GPP access network within the same PLMN;

[0092] - For DualSteer traffic steering, whether and what policies need to be provided by the HPLMN to guide the DualSteer device to select a 3GPP access network to be used for the new service;

[0093] - For DualSteer traffic switching, whether and what policies need to be provided by the HPLMN to guide the DualSteer device for traffic switching between two connected 3GPP access networks;

[0094] - Whether and what policies are provided within the network(s) to handle DualSteer traffic steering and / or DualSteer traffic switching;

[0095] - Study whether and how the policy enhancements for DualSteer device have impacts on existing UE policies.

[0096] Section: Dual steer - Registration and verification that a DualSteer UE is connected to two or more networks In some scenarios, the UE 100 (which may possibly include two SIMs that may be operated by two “logical UEs”) may be connected to multiple networks, but the networks (e.g., PLMN1 109 and PLMN2 114) may not be aware of it and may need to verily it. Thus, in a related embodiment, in order for the PLMNs, PLMN1 109 and PLMN2 114, to confirm that the UE 100 (which may include two SIMs that may be operated by two “logical UEs”) is connected to other PLMNs, PLMN1 109 (and / or PLMN2 114) may send a token to the UE 100, and the UE 100 may send the token received from PLMN1 109 (and / or PLMN2 114) to PLMN2 114 (and / or PLMN1 109) so that PLMN2 114 can verify it. Other possible interactions (Intj) may include:

[0097] IntL PLMNl -> UE(SIMl) (-> UE(SIM2)) -> PLMN2.

[0098] Int2: PLMN1 -> UE(SIMl) (-> UE(SIM2)) -> PLMN2 -> PLMN1 ( -> PLMN2).

[0099] Int3: PLMN2 (-> UE(SIM2)) -> UE(SIMl) -> PLMN1.

[0100] Int4: PLMN2 (-> UE(SIM2)) -> UE(SIMl) -> PLMN1 -> PLMN2 ( -> PLMN1).

[0101] Int5: UE(SIMl) -> PLMN1 -> PLMN2 (-> UE(SIM2)) -> UE(SIMl) ( -> UE(SIM2)).

[0102] Int6: (UE(SIM2) ->) PLMN2 -> PLMN1 -> UE(SIM1) -> UE(SIM2) ( -> UE(SIMl)).

[0103] Int7: UE(SIMl) (-> UE(SIM2)) -> PLMN2 -> PLMN1 -> UE(SIMl) ( -> PLMN1)

[0104] Int8: (UE(SIM2) -> ) UE(SIM1) -> PLMN1 -> PLMN2 (-> UE(SIM2)) ( -> PLMN2)

[0105] In the above interactions, e.g., “Intj” refers to Interaction number j with j= 1 to 8, A - > B (without brackets) refers to entity A sending a message to entity B, (A -> B) (between brackets) refers to an optional entity A sending an optional message to entity B, e.g., a final acknowledgement. As in the example the first and last entities in the chain of interactions perform the verification. For instance, an optional entity may be SIM2 when a UE has a single SIM / subscription that is used to connect to two different networks.

[0106] In a related embodiment variant, the token used in above variants may be: a random value (as a challenge), an authorization token that is a signed statement, a cryptographic function (keyed hash, encrypted value, etc) of a random value or counter (e.g., a nonce) using a key shared between SIMi and PLMNi, e.g., a root key, a key derived from a root key such as a key used in the NAS security context.

[0107] A random value may be applicable to the above interactions, e.g., interactions 2, 4, 5, 6, 7 and 8 because whatever value is sent to the UE 100 (which may include two SIMs that may be operated by two “logical UEs”) over the communication link secured based on PLMN1 / SIM1 (e.g., NAS context associated to PLMN1 / SIM1) needs to be received through a communication interface between PLMN1 / PLMN2. For instance, in Int2: PLMNI 109 may send a token / random value protected end-to-end from PLMNI 109 to SIMI 101 / UE 100 using a key (derived / based on) secrets stored in SIMI 101. SIMI 101 / UE 100 may check the token / random value based on those secrets and instruct SIM2 102 / UE 100 to protect the same token / random value based on keys (derived / based) in SIM2 102. The UE 100 may share said secret with PLMN2 114 that may verify the token / random value. Finally, the PLMN2 114 may securely share the token / random value with PLMNI 109. If PLMNI 109 receives the same token / random value as initially sent, then PLMNI 109 can verily that the UE 100 is connected through two different networks. Finally, PLMNI 109 may send an optional confirmation message to PLMN2 114 indicating the positive / negative verification. Note that for interaction 5 (similar for interaction 6), if UE(SIMl) 100 encrypts (in general, protects because multiple techniques may be used to protect the transactions, e.g., a message integrity code may also be generated) a random value using a key shared with PLMNI 109, and PLMNI 109 decrypts and sends to PLMN2 114, and PLMN2 114 encrypts with a key shared with SIM2 102, and SIM2 102 decrypts, then SIM2 102 can share the decrypted value with UE(SIMl) 100 and SIMI 101 can verily it. The fact that SIMI 101 verifies means that all entities SIMI 101 / SIM2 102 / PLMNI 109 / PLMN2 114 agree with the transaction. This also means that UE(SIMl) and UE(SIM2) are in the same physical UE. In interaction 5, the last step is optional and can be considered a last verification step.

[0108] An authorization token may be applicable, e.g., for interactions 1 and 3 because PLMNi might sign an authorization token for PLMNj stating that it authorizes a common communication link for the UE. The authorization token may include a validity time and / or other contextual information. Such an authorization token can be used by PLMNi to inform both UE and PLMNj that it agrees / allows a combined communication procedure.

[0109] In a related embodiment, a token may be sent / exchanged next to metadata determining the features of the communication so that both networks determine / learn the features of the networks / connection. For instance, the token may include information about: the SIMs (including credentials, user identifiers, etc) that are used together, the networks that are working together, the services that may be provided and the services that may not be provided, the network entity that is in charge of providing / managing the services. In a related embodiment variant that may be combined with other embodiments or used independently, the UE 100 (which may include two SIMs that may be operated by two “logical UEs”) or the application function 119 may only use (be requested to use) both core networks 109 and 114 to perform a certain combined service, e.g., communication, e.g., AKMA-based communication, if both core networks 109, 114 approve the combined service, e.g., by means of an authorization token. Note that the authorization tokens may be valid for a given transaction, for a given period of time, or in a given context (e.g., location). An entity, e.g., 302 in Fig. 2, in a core network, e.g., the first core network 109, is in charge of managing the combined service delivery.

[0110] Section: Dual steer - further authentication aspects

[0111] In some scenarios, a UE may use the capability of connecting to multiple networks to establish two or more independent connections, instead of a single connection over two or more networks. This can mean that a user / UE can misuse the capability of establishing a connection over two or more networks to establish two or more independent connections. It is therefore important to address this threat by means of the above embodiments or by means of the following additional embodiments.

[0112] In a related embodiment that may be combined with other embodiments or used independently, a UE may use two or more serving networks to establish a connection, e.g., as illustrated by Fig. 2 or Fig. 4. In Fig. 4, a UE (1100) with a home PLMN 1103 connects through serving networks 1101 and 1102. To connect to the serving networks, the UE has to register to serving networks 1101 and 1102. To this end, it can perform network registration / primary authentication with its home PLMN 1103 through serving network 1101 first (e.g., AMF of the first serving network). The home network 1103 may check whether the UE is authorized to establish a multi-path network connection. The UE may send in this first primary authentication procedure or in a later message to the home PLMN 1103 an indication about the intention to connect through a second serving network 1102. The home PLMN 1103 may also send an indication to the UE about the need to establish a multi-path connection through a second serving network 1102.

[0113] In a related embodiment that may be combined with other embodiments or used independently, the initial messages used to register a UE (e.g., 1100) in the network may include the capabilities of the UE, e.g., whether it supports connectivity via multiple networks.

[0114] In a related embodiment that may be combined with other embodiments or used independently, once the first primary authentication has been performed, the UE 1100 may perform a second network registration / primary authentication through the second serving network 1102. In this case, when the home PLMN 1103 receives it, the home PLMN 1103 (e.g., UDM) checks whether the UE 1100 is authorized to have a multi-path multi-network connection, i.e., a connection over multiple networks, i.e., a DualSteer Connection. If UE 1100 is not authorized, the home PLMN informs the second serving network 1102 (e.g., AMF) and stops the second primary authentication procedure. If UE 1100 is authorized, home PLMN 1103 finishes the second primary authentication procedure, i.e., by sending a Registration Accept Message.

[0115] It is to be noted that UE 1100 in previous and subsequent embodiments may be same / similar to UE 100 in Fig. 2 comprising two SIM cards (that may be operated by two “logical UEs”) with the respective credentials so that each primary authentication is executed with the credentials of one of the SIMs, e.g., a different SUPI.

[0116] In a related embodiment that may be combined with other embodiments or used independently,, the home PLMN 1103 may start a home network triggered primary authentication through serving network 1102 to verily the identity of UE 1100 as well as to verify the intention of UE 1100 of establishing the multi-path connection.

[0117] In a related embodiment that may be combined with other embodiments or used independently,, the home PLMN 1103 may share with serving network 1102 the keys derived by means of the first primary authentication, e.g., K SEAF as well as the identity of the UE, e.g., SUPI, GUTI. These keys / identities (serve as token as in other embodiments) can be used by UE 1100 to join serving network 1102 because when UE 1100 sends its registration request, serving network 1102 already has a suitable security context, and can use it to verify UE 1100’s registration request.

[0118] In a related embodiment that may be combined with other embodiments or used independently,, the home PLMN 1103 may provide UE 1100 with a token, e.g., a random number or an authorization token, etc through the first serving network 1101. This token is to be used when UE 1100 wishes to perform network registration through the second serving network 1102 as part of a second primary authentication procedure. When home PLMN receives this token, the home PLMN knows that is a UE that is already connected to the first serving network 1101 and may, e.g.:

[0119] Stop the second primary authentication procedure;

[0120] Share keys / identity of the UE established / known from the first primary authentication procedure with the second serving network;

[0121] Inform the second serving network that it is steered by the first serving network.

[0122] In another related embodiment that may be combined with other embodiments or used independently, the home PLMN 1103 performs different actions depending on whether the UE 1100 has an active connection through a first serving network 1101 or not, when the UE 1100 starts a second primary authentication procedure through a second serving network 1102. The home PLMN 1103 first checks the status of the connection through the first serving network 1101. If the connection is still active and the UE is not entitled to have two independent connections, but a single multi-path, the home PLMN 1103 may do one or more of the following:

[0123] - reject the second primary authentication procedure,

[0124] - instruct the UE 1100 to switch back to the first serving network 1101, - notify the first serving network 1101 of the UE 1100's attempt to connect through the second serving network 1102,

[0125] - initiate a handover procedure between the two serving networks 1101, 1102,

[0126] - indicate to the second network that the connection can only used in multipath mode wherein the first network 1101 may be in steering role.

[0127] On the other hand, if the connection is not active, the home PLMN 1103 may do one or more of the following actions: allow the second primary authentication procedure, instruct the UE 1100 to disconnect from the first serving network 1101, notify the first serving network 1101 of the UE 1100's movement to the second serving network 1102, release any resources (e.g., the steering role in a multipath connection) that were allocated for the UE 1100 in the first serving network 1101.

[0128] Section: Dual steer - further registration aspects

[0129] In a scenario, a UE / dualsteer device (e.g., UE 100 which may have two SIMs that may be operated by two “logical UEs”) registers over a first 3GPP access network PLMN1. The device starts an application / service, and based on URSP rules, determines that the application / service requires a multipath connection (e.g., a DualSteer PDU Session). The device selects the network to provide the second 3GPP access, e.g., based on a policy by the HPLMN. The selection may trigger the device to send a Registration Request message to the second network PLMN2. The Registration Request message may include: an indication that the registration is for a second 3 GPP access leg to be used for DualSteer, an identifier of the network where the device has a first registration (PLMN1). The second network (e.g., AMF) may determine whether to accept or reject the registration based on the type of registration (e.g. whether the registration is for a second 3GPP access network), and on the identity of the network where the device has a first registration. If the AMF accepts the registration, it sends a Registration Accept message to the device, including guidance on registration / connection / mobility management procedures over the second 3GPP access network. This scenario has a number of limitations, e.g., the AMF of the second network cannot determine whether the device is connected to the first network or not. The following embodiments aim at improving this situation.

[0130] In an embodiment related to the registration of a UE / dualsteer device that may be combined with other embodiments or used independently, the registration request message of a UE / dualsteer device to the second network may include a token so that the second network can verify that the UE / dualsteer device is connected to the first network.

[0131] In an embodiment related to the registration of a UE / dualsteer device that may be combined with other embodiments or used independently, the registration request message of a UE / dualsteer device to the second network may proceed to perform primary authentication, and once the related SIM (e.g. 101 and / or 102) is authenticated, and the AUSF and / or UDM have checked the user subscription, the AUSF / UDM may determine whether the connection is allowed, and inform the SEAF and AMF of the second network.

[0132] In a second scenario, a UE / dualsteer device (e.g., UE 100 including a first SIM and a second SIM that may be operated by two “logical UEs”) may connect to a first RAN and send a registration request to a mobility function, e.g., AMF, in a first network. The request may include the capability of the UE / dualsteer device to establish a connection over two networks. Next, a registration procedure, e.g., as defined specified in clause 4.2.2 of TS 23.502, may be executed, e.g., before the mobility function retrieve the subscription profile from a data function (e.g., UDM) containing the subscriber data / profile. The subscription profile may include whether the first SIM 101 is allowed to manage a connection over two networks. It may include related information to the second SIM 102. If authorized, the following steps specified in clause 4.2.2 of TS 23.502 may be performed. The first mobility function may send a Registration Accept message to the UE / dualsteer device. The message may include the indication of allowing connection over two networks. The UE / dualsteer device may connect to a second RAN / RAT and may send a registration request to a second mobility function (e.g., a second AMF) in a second network using the second SIM 102. Then the registration procedure as defined specified in clause 4.2.2 of TS 23.502 may be performed. The second mobility function may send the Registration Accept message to the UE / dualsteer device. Finally, the UE / dualsteer device may trigger a Mobility Registration Update procedure to the first network by sending a new registration request including the information of the second SIM and / or Access Network information (i.e. ID of the second network, access network type and RAT type etc.) for the core network to associate the two SIM registration context. During the Mobility Registration Update procedure, the association information will be stored in first network (e.g., mobility function or a policy function) and the PCF may be reselected to ensure the two USIMs will be served by the same network, e.g., PCF.

[0133] It is to be noted that as in other embodiments the Mobility Registration Update procedure may serve as a token to verify that both USIMs / SIMs are aware of the UE connection over both networks, in particular, Mobility Registration Update procedure may use a cryptographic function (keyed hash, encrypted value, etc) of a random value or counter (e.g., a nonce) as token whereby a key shared between SIMi and PLMNi, e.g., a root key, may be used, e.g., a key derived from a root key such as a key used in the NAS security context, e.g., a token as in above embodiments.

[0134] In a further embodiment that may be combined with other embodiments or used independently, a token such as the Mobility Registration Update procedure may include information about the SUPIs that are linked to each other, the type of services that are allowed / enabling using multiple networks / RATs, the target QoS, etc.

[0135] In a further embodiment that may be combined with other embodiments or used independently, the first network may inform the UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) about the services that it may trigger using the connection over both networks / RATs. For instance, the first network may assess whether a given service is allowed, and it may provide a configuration of said services to the UE / dualsteer device. The UE / dualsteer device may have also requested said services previously.

[0136] In a further embodiment that may be combined with other embodiments or used independently, upon receiving the Mobility Registration Update procedure, the first network (e.g., first mobility function, data function, etc may verily that the UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) is currently connected to the second network. For instance, if both SIMs belong to the same home network, then the data function is aware of both network registration / primary authentication procedures for both the first SIM 101 and the second SIM2 102. The Mobility Registration Update sent by the UE / dualsteer device 100 serves as final confirmation so that the first mobility function checks with the data function this event. The UE / dualsteer device 100 may include in the Mobility Registration Update procedure the requested parameters / services (for the second network) that may also be verified by the first network.

[0137] In a further scenario, a UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may use a first SUPI of a first SIM 101 to register. UE / dualsteer device 100 sends to a first mobility function (e.g., AMF) via a first RAN a registration request including its capability / request to support a connection via multiple networks. The UE / dualsteer device 100 may include in the registration a token, if previously received from this serving network. The first mobility function may then trigger the authentication of the SUPI / SIM. If successful, the mobility function may request a data function to register itself as the serving mobility function. The mobility function may indicate that it is capable of handling a connection over multiple networks. The data function may then check whether the SUPI is linked to a subscription to enable connections / services over multiple networks and whether it is a primary SUPI. The data function provides a token, e.g., an identifier used to enable the functionality over multiple networks and identify the SUPI pair, and an authorization indication to the mobility function. The mobility function may then send a registration accept to SIM 101 in UE / dualsteer device 100, authorizing the usage of the capability of communication / services over multiple networks. The UE / dualsteer device can then determine whether it can behave as device using the capability of communication / services over multiple networks or not, and if yes, whether perform registration with the secondary SUPI. The token can be used to identify the second SUPI. UE / dualsteer device 100 may use a second SUPI of a second SIM 102 to register. UE / dualsteer device 100 may send to a second mobility function (e.g., AMF) via a second RAN a registration request including its capability / request to support a connection via multiple networks. The UE / dualsteer device 100 may include in the registration a token, if previously received from this serving network. The second mobility function may then trigger the authentication of the second SUPI / SIM. If successful, the mobility function may request a data function to register itself as the serving mobility function. The mobility function may indicate that it is capable of handling a connection over multiple networks. The data function may then check whether the SUPI is linked to a subscription to enable connections / services over multiple networks and whether it is a secondary SUPI. The data function may reject the connection if the primary SUPI is not active. The data function may then provide the same token associated to the primary SUPI and the first mobility function to the second mobility function. The second mobility function may reject the registration, e.g., if the UE / dualsteer device 100 is not allowed to use the SUPI in its current location. Otherwise, it may send a registration accept. Finally, UE / dualsteer device 100 may correlate both the first and the second SUPIs to support the communication / connection / services over multiple networks based on the token. This further scenario has some issues, e.g., it seems that the same data function is used to deliver the token in the first and second registrations, but this cannot happen if SIM 101 and SIM 102 are associated to different home networks. Thus, the embodiments in this invention may address some of these concerns:

[0138] In an embodiment related to the registration of a dualsteer device that may be combined with other embodiments or used independently, a SUPI may be a primary or a secondary SUPI and its role may be determined on the fly or by the user. For instance, a user may use UE 100 (which may include a first SIM and a second SIM that may be operated by two “logical UEs”) to determine / configure a SIM (e.g., 101) to be the primary SIM (including then the primary SUPI). Then the first registration message may indicate that it is working as primary SUPI. This may also trigger to identify another SIM (e.g., 102) as the secondary SIM (including then the secondary SUPI). Then the second registration message may indicate that it is working as the secondary SUPI.

[0139] In an embodiment that may be combined with other embodiments or used independently, a DualSteer connection (i.e., a connection over two networks) may be active, e.g., using a first SIM 101 / SUPI as primary SUPI and a second SIM 102 / SUPI as secondary SUPI. The user may then determine that the roles should be inverted, i.e., SIM 102 should act as primary SUPI and SIM 101 as secondary SUPI. This may trigger a reconfiguration of roles in which the control of the DualSteer connection moves from the first serving network (associated to SIM 101) to the second serving network (associated to SIM 102). For instance, a UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may send a request to the second network to become the primary network, and the second serving network may send a token indicating its confirmation. The UE / dualsteer device may then send another request to the first serving network to become the secondary network, maybe including said token. The token may serve as a proof for the first network that the second network is accepting to take over the role. The first serving network may then confirm the change to the UE / dualsteer device and may also confirm the change to the second serving network, either directly, or through the UE / dualsteer device (e.g., by means of another token).

[0140] In an embodiment (6DS_c) that may be combined with other embodiments or used independently, the token may contain additional information such as:

[0141] Role a first SUPI is authorized to take (primary, secondary),

[0142] Role the serving network is authorized to take,

[0143] SUPI or SUPIs (or other user identity such as GUTI, etc) that may be associated with the primary / secondary SUPI (or other user identity), services that may be provided by means of the DualSteer connection, conditions under which the services may be provided (e.g., a given UE location), or the RAT that may be used (e.g., WLAN, NTN, etc) for a given connection (e.g., primary connection or secondary connection in a DualSteer connection).

[0144] In an embodiment that may be combined with other embodiments or used independently, the networks may communicate directly or through the UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) to agree on the roles. For instance, in previous scenario, the data functions of a first and second network may interact with each other, directly or indirectly (e.g., through NEF or UEs) to check which role each SIM / SUPI is taking.

[0145] A DualSteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may be associated to two SIMs / USIMs / eSIMs / SIM cards each with a SUPI and the corresponding credentials. These two SIMs / SUPIs are supposed to work together within the same (physical) device. These peer SIMs may be a main / primary / first SIM SIM l with SUPI l and a secondary / second SIM SIM2 with SUPI 2. However, there is a risk (as indicated in other embodiments) that they are misused and plugged to two different devices. To deal with this risk, in an embodiment that may be combined with other embodiments or used independently, each SIM may be configured, next to the own SUPI, the peer SUPI, e.g., SIM l also contains SUPI 2. Furthermore, the SIMs may have credentials, e.g., a key, to verily / authenticate themselves when they are plugged to the same device. Furthermore, a first SIM / SUPI may be the main SIM / SUPI and a second SIM / SUPI may be the secondary SIM / SUPI. When a DualSteer SIM card is plugged in a device, the SIM card may check whether the peer SIM card is in the same device / active, e.g., by performing a security protocol such as an authentication protocol such as a challenge / response authentication protocol, and depending on the authentication result and the type of SIM / SUPI determine the type of allowed operation for the UE / mobile equipment. For instance, a user may need to enter the PIN to unlock SIM l and the PIN to unlock SIM 2, and within a time window, both SIM cards may need to perform the security protocol. If this security protocol does not succeed, then the functionality provided by the SIM (and the mobile equipment)) may be restricted. For instance, only the main SIM (SIM l) may enable connectivity, but the secondary peer SIM (SIM 2) may not enable connectivity (e.g., it may only be used in emergency mode). In other words, if the SIM l is plugged in a first device Device l, and SIM 2 is plugged in a second device Device_2, Device l and SIM l may work as a normal UE, but Device_2 + SIM 2 may not be operational, may not connect to the network, e.g., SIM 2 may remain locked (e.g., only provide emergency access). In other situations, none of the SIMs / SUPIs may enable connectivity, if they are not plugged to the same physical device.

[0146] In general, it is described an apparatus (6DS SIM) for enabling a cellular connection wherein the apparatus is adapted to: be plugged to a mobile equipment, receive a PIN, perform an unlock procedure based on the received PIN, check / verify / determine the presence of a peer SIM plugged to the same mobile equipment, adjust the enabled communication parameters based on the peer SIM check, and apply them when interacting with the mobile equipment.

[0147] In general, the apparatus (6DS SIM 1) may be adapted to consider at least three types of enabled communication parameters:

[0148] Emergency only, when the apparatus cannot check the presence of the peer SIM plugged to the same mobile equipment and the apparatus contains a secondary SUPI,

[0149] Standard UE, when the apparatus cannot check the presence of the peer SIM plugged to the same mobile equipment and the apparatus contains a primary SUPI, and

[0150] DualSteer UE, when the apparatus can check the presence of the peer SIM plugged to the same mobile equipment.

[0151] In an embodiment that may be combined with other embodiments or used independently, the SIMs (e.g. SIM1 / SIM2 as in previous embodiment) may be configured in a DualSteer device by the home PLMN, e.g., when a user owns a first SIM that may be the primary SIM with a primary SUPI and when the DualSteer device, already configured with this first SIM, is connected to the home PLMN and using the credentials of the first SIM, the user may request a second SIM with a secondary SUPI for the DualSteer device, and this eSIM may be downloaded to the DualSteer device. The secondary SUPI and the link between the primary SUPI and secondary SUPI may then be stored in the data function (e.g., UDM). The secondary SUPI may then be configured in the first SIM. The second SIM may also have a key derived from a master secret in the first SIM so that the first SIM can verily that the second SIM is a SIM paired to it as a secondary SIM.

[0152] In an embodiment that may be combined with other embodiments or used independently, the token used / delivered by different networks may be different and may serve as a confirmation of the communication / connection or part of it. For instance, in earlier scenarios, after the first registration network, the first network may deliver a first token, e.g., a first (authorization) token. For instance, in earlier scenarios, after / in the second registration network, the UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may send the first (authorization) token. For instance, the second network may check the first (authorization) token before issuing a second (authorization) token. For instance, the UE / dualsteer device may receive the second (authorization) token and check that both (authorization) tokens are compatible (e.g., first token authorizes the first SIM to act as primary SUPI and second token authorizes second SIM to act as secondary SUPI of the first SUPI). Finally, the UE / dualsteer device may send the second token to the first network for final enabling of the service / connection.

[0153] In this invention, a UE / dualsteer device (e.g. UE 100 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may use two SIMs to establish a connection over two networks and / or RATs. Such a connection may be denoted as a DualSteer connection, whereby such connection may comprise a joint PDU session (e.g. DualSteer PDU session) operated by both SIMs (e.g. having a same PDU session ID or another shared identifier) or set of PDU sessions operated by either one of the SIMs (but part of the same logical connection, e.g. having same IP address and / or anchored in the same UPF. Such a connection may be used to deliver a given service over the DualSteer connection. For the two networks and / or RATs, one of the networks and / or RATs may act as the primary network / RAT and the other network and / or RAT may act as the secondary network and / or RAT.

[0154] In a further scenario, a UE / DualSteer device (e.g. UE 100 as in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”), capable of a connection over two RATs / networks, may send a registration request over a first RAT (e.g., terrestrial network) to a first mobility function (e.g., AMF1) where this first request is based on the credentials of a first SIM 101. The first mobility function may authenticate it by interacting with an authentication function and data function (e.g., AUSF / UDM by using Authentication / Nudm SDM Get). If successful, it may send a Registration Accept. The mobility function may interact with a policy function (e.g., PCF) to perform a UE policy association establishment procedure (e.g., as in clause 4.16.11 in TS 23.502). Then this policy may be delivered to the UE / dualsteer device 100 that may configure, e.g., the connection for a second SIM 102, as illustrated in other embodiments. This policy may trigger a later registration step to the second RAT / network using the credentials of a second SIM 102. The registration request may go to a second mobility function, that may interact with an authentication function / data function to authenticate the device. If it is successful, it may then trigger the registration accept. Then the UE / dualsteer device 100 may perform the PDU session establishment via the second network.

[0155] In such a scenario, the UE / dualsteer device 100 may be able to connect or may be connected through two networks / RATs to receive a given service. However, it is not clear when the UE / dualsteer device should use which network / RAT. Furthermore, which two SIMs / credentials are used in a combined manner is determined earlier in the process by the network without the networking knowing whether the UE / dualsteer device may have more than two SIMs / set of credentials. Thus, embodiments in this invention may be applied to determine how such connection / service is to be enabled.

[0156] In an embodiment that may be combined with other embodiments or used independently, the UE 100 in Fig. 1 may have two or more sets of credentials, such as SIM cards, eSIMs, or software certificates, that allow it to access different networks / RATs or different services within the same network / RAT, whereby each (e)SIM or software certificate may be operated by a “logical UE” within the same device. For example, the UE 100 may have a SIM card for a cellular network, an eSIM for a satellite network, or a software certificate for a WLAN network. Alternatively, the UE 100 may have multiple SIM cards or eSIMs for different cellular networks or different service providers. The UE 100 may include a credential selection module that selects one or more sets of credentials to use in a dualsteer connection according to a given criterion or policy. The credential selection module may be part of the policy module or a separate module or a user interface.

[0157] The credential selection module (2DSb) may select the sets of credentials based on the user preference, the network availability, the service requirement, or the network policy. For example, the user may prefer to use a satellite network for video streaming, a cellular network for voice calls, and a WLAN network for web browsing and may have backfall preferences in case that the primary network fails or has lower availability. Alternatively, the network may indicate which sets of credentials are suitable or preferable for a certain service or purpose. For example, the network may prioritize a cellular network over a satellite network for low-latency services, or vice versa for high-bandwidth services. The service may also specify which sets of credentials are required or optimal for its functionality or quality. For example, a service may require a secure connection through a trusted network, or a reliable connection through a robust network.

[0158] The credential selection module may include the available and / or (pre-) selected sets of credentials in an initial message sent to the network, such as an initial registration request, an authentication request, or a PDU session establishment request. The initial message may include the identities of the UE / user / device associated with the selected sets of credentials, such as SUPI, SUCI, GUTI, IMEI, etc. The initial message may also include the desired service or the purpose of the connection, such as voice call, video streaming, web browsing, etc. The network may then, based on this information, preselect one or more sets of credentials that are suitable for the desired service, and indicate this to the UE, e.g., in the registration accept message once the first set of credentials (e.g., SUPI) as been authenticated. The one or more set of credentials may be provided according to a given priority. The policies provided after the first registration may be chosen for that selection. For example, the network may select a cellular network and a satellite network for video streaming, and provide policies that split the traffic between them according to the bandwidth availability. Alternatively, the network may select a cellular network and a WLAN network for web browsing and provide policies that switch between them according to the signal strength. The credential selection module may then use the selected sets of credentials to establish a dual-steer connection through the corresponding networks / RATs according to the policies.

[0159] In another related embodiment that may be combined with other embodiments or used independently, a UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) includes a credential selection module that selects one or more sets of credentials corresponding to three different SIMs for establishing a dual-steer connection through multiple networks / RATs. The credential selection module may receive an indication from the network about which SIM to use for the second registration when the first registration request / primary authentication is done for a first SIM 101. For example, the network may know that the UE / dualsteer device 100 also has two other SIMs, and based on the context (e.g., the desired service, the user identity, the network conditions, etc.), the network may provide the UE / dualsteer device 100 with an indication about which SIM to use for the second registration to use in the dual-steer connection. The network may send this indication in the registration accept message or in a subsequent message after the first registration is completed. The credential selection module may then use the indicated SIM to perform the second registration and establish the dual-steer connection through the corresponding network / RAT. For example, the network may indicate that the UE / dualsteer device 100 should use the third SIM associated with a non-terrestrial network operator for the second registration, and the UE / dualsteer device 100 may then establish a dual-steer connection through a terrestrial network (e.g., LTE) using the SIM 101 and a non-terrestrial network (e.g., LEO) using the third SIM. Alternatively, the network may indicate that the UE / dualsteer device 100 should use the second SIM associated with a different terrestrial network operator for the second registration, and the UE / dualsteer device 100 may then establish a dual-steer connection through two different terrestrial networks (e.g., NR and WLAN) using the SIMs 101 and 102.

[0160] In a related embodiment that may be combined with other embodiments or used independently, a UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) includes a policy module that stores and executes a communication policy for using multiple networks / RATs in a dual-steer connection. This policy module may steer block 1806 in Fig. 5 or be part of it. The communication policy may be configured by the user, the service provider, or the network operator, and may be updated dynamically according to the network conditions, the user preferences, or the service requirements. The policy module may communicate, directly or indirectly, with the protocol stacks and the application layer of the UE / dualsteer device 100 to monitor and control the communication paths through different networks / RATs. The communication policy may specify the conditions for using a second network / RAT in addition to or instead of a first network / RAT in a dual-steer connection. For example, the first network / RAT may be a terrestrial network, such as LTE, NR, or WLAN, and the second network / RAT may be a non- terrestrial network, such as LEO, MEO, or GEO satellite network. For instance, the first network / RAT in a dual-steer connection may be a WLAN and the second network / RAT may be a terrestrial cellular network.

[0161] The policy module (2D Sc) may determine that the connection is to be based on the first network / RAT (e.g. switch / steer the application / service to use the first network / RAT, for example through URSP rules extended with one or more conditions for using a particular network / RAT in a dualsteer connection), and only if the service QoS (e.g., communication latency, jitter, bandwidth, reliability, security, etc.) drops below a given threshold, the UE / dualsteer device 100 should start using the second network / RAT (e.g. switch / steer the application / service to use the second network / RAT, for example through URSP rules extended with one or more conditions for using a particular network / RAT in a dualsteer connection). Alternatively, the policy module may determine that the connection is to be based on the second network / RAT, and only if the service QoS improves above a given threshold, the UE / dualsteer device 100 should switch to the first network / RAT. The policy module may also determine that the connection is to use both networks / RATs simultaneously and split the traffic between them according to the service QoS or the user preferences.

[0162] The policy module may receive feedback from the protocol stacks and the application layer about the current network conditions, the available networks / RATs, and the required / available service QoS. The policy module may also receive information from the core networks 109 and 114 about the network capabilities, the network load, and the network policies. Based on this information, the policy module 400 may decide whether to initiate, maintain, or terminate a dual-steer connection through different networks / RATs. The policy module may instruct: the protocol stack to perform different actions, e.g. :

[0163] Register in the RAT / network establish, modify, or release the communication paths through the networks / RATs, and the application to steer, switch, or split the traffic accordingly.

[0164] The policy module may also notify the user, the service provider, or the network operator about the communication status and the policy execution.

[0165] For instance, a UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may register to a first network, and get a configuration / policy determining that it may register to / connect to / use a second network when the service provided by the first network drops below a given level.

[0166] For instance, a UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may register to a first network, and get a configuration / policy determining that it may register to / connect to a second network, and that it may remain in a given state (e.g., IDLE or INACTIVE) as long the service provided by the first network drops below a given level. When this happens, the UE / dualsteer device may get in state CONNECTED in the second network

[0167] To enable more flexible and efficient DualSteer connection and / or ATSSS-based multipath communication, a further embodiment may involve the policy module in the control of the communication paths and the traffic distribution. The policy module may interact with the PCF (Policy Control Function) and / or the SMF (Session Management Function) of the core networks to retrieve the policy information used by the UE / dualsteer device 100 and / or to steer the connection establishment, modification, or release of the communication paths. For example, the policy module may obtain from the PCF and / or the SMF the DualSteer and / or ATSSS rules that specify the criteria for registering / using different networks and / or steering, switching, or splitting the traffic over multiple paths, as well as the performance measurement configuration that defines the metrics and thresholds for evaluating the path quality. The policy module may also provide feedback to the PCF and / or the SMF about the communication status and the policy execution, such as the connected networks, path selection, the traffic distribution, the path quality, the user preference, the application requirement, or the network condition. Based on the feedback, the PCF and / or the SMF may adjust the policy information accordingly and inform the policy module and / or the UE / dualsteer device 100 of the updated policy information. This way, the policy module may facilitate a more dynamic and adaptive DualSteer and / or ATSSS-based multipath communication that can optimize the user experience and the network resource utilization.

[0168] The policy module may receive said policy by means of the UCU procedure in Clause 4.2.4.3 in TS 23.502.

[0169] In a scenario, a data function (e.g., UDR) may include a policy or subscription related to a user that may be allowed using a UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”)to connect over two or more RATs / networks. The policy may include subscription information whether the SUPI is subscribed to DualSteer service. Associated SUPI is the SUPI co-located with the SUPI of that subscription in the UE / DualSteer device. The “DualSteer policy” may include preferred PLMN / RAT combination for service traffic descriptor with further criteria (e.g., time, location, QoS). The “DualSteer policy” may be used for both traffic steering and traffic switching.

[0170] This configuration (2DSd) may be too static, and thus, it in a further embodiment that may be combined with other embodiments or used independently, a subscription bound to a SUPI may indicate whether it may be used as part of a DualSteer connection (connection over two RAT / networks) and the conditions for such a usage (e.g., which RAT / networks are allo wed / disallo wed). The co-located SUPI can be selected on demand, e.g., based on the context or service that is required.

[0171] In a related embodiment that may be combined with other embodiments or used independently, a subscription bound to a SUPI may indicate two or more additional SUPIs that may be used as part of a DualSteer connection since different SUPIs may be used for different types of RAT and / or Networks, and a different SUPI may be preferred depending on the service wishes to receive. For instance, a subscription may include three different SUPIs that may be used together (in pairs). The UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may indicate that pair of SUPIs that it may wish to use at a specific point of time; or the network may indicate this information to the UE / dualsteer device.

[0172] In a related embodiment (2DSe) that may be combined with other embodiments or used independently, two SUPIs that are (to be) used together in a (DualSteer) connection over different RATs / networks are assigned an identifier so that said DualSteer connection can be managed in a combined manner (e.g. each pair of SUPIs stored in the UDM and / or UE may be assigned a different identifier). This identifier and / or selected (pair of) SUPI(s) may be determined or provided to the UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) once registration of a first SUPI / SIM is done in a successful manner and / or once registration of second SUPI / SIM is done in a successful manner. This identifier may be used, e.g., by the UE / dualsteer device or PCF to handle (the information of) that specific connection, and the UE / dualsteer device may include it e.g. as part of its primary and / or secondary registration and / or during PDU session establishment. If the UE / dualsteer device would then initiate a second DualSteer connection with a different pair of SUPIs (e.g. amongst for example three different SUPIs), then the second DualSteer connection can be differentiated by the network and may be managed differently by the network.

[0173] In a related embodiment that may be combined with other embodiments or used independently, a UE / dualsteer device (e.g. UE 100 in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may first perform the registration of a first SUPI based on the credentials in a first SIM in a first RAT / network. At a later point of time, a second SUPI and SIM may become available in the UE / dualsteer device / UDM / UDR, and the UE / dualsteer device may then indicate to the core network by means of a message of the availability of this second SUPI and SIM (e.g., protected in the NAS context of the first SUPI / SIM). The core network may then evaluate whether this second SUPI and SIM are suitable for a connection over multiple networks, and if positive, indicate an indication to the UE / dualsteer device to do the network registration / primary authentication using the second SUPI / SIM towards a second RAT / network. Additionally or alternatively, the second network registration message may be directly sent by the UE / dualsteer device including the second SUPI and also information about the existing connection so that the core network can link the first SUPI and the second SUPI as part of a combined connection over multiple networks. Additionally or alternatively, when the new subscription data (e.g., a second SUPI that may be used in a connection over multiple networks) is available in the UDM / UDR, the core network may trigger a home networked triggered primary authentication procedure with the purpose of adding the second SUPI / SIM to the connection over multiple RATs / networks. Section: NTN - AMF as part of the mobile access device

[0174] The 4G Mobility Management Entity (MME) is divided into the 5G Core Access and Mobility Management Function (AMF) and Session Management Function (SMF). AMF receives all connection and session related information from the User Equipment (UE) (N1 / N2) and is responsible for handling connection and mobility management tasks. All messages related to session management are forwarded over the Nil reference interface to the Session Management Function (SMF). Since a mobile access device such as a satellite keeps moving, the following advantageous embodiment proposes that the mobile access device is in charge of the connectivity with specific UEs, e.g., loT devices, and the AMF (or MME) is part of the mobile access device, for instance, entity 1405 may be part of 1402. This embodiment can simplify certain use cases, e.g., cellular loT. For instance, based on Clause 6.16.1.1 in TS 33.501, Control Plane Optimisation for 5GS CIoT is used to exchange small user data or SMS as payload of a N AS message in both uplink and downlink directions. The UE and the AMF perform integrity protection and ciphering for the small user data or SMS using NAS security context specific to the NAS connection. If AMF is integrated into the mobile access device, the mobile access device can handle the distribution / reception of loT data in a secure way without requiring the usage of the feeder link for each message exchange with an loT device. This also simplifies the handling of radio failure events (Clause 6.16.1.2) and the RRCConnectionRe-establishment Procedure since the same physical entity has the (NAS) keys used to verily that message. II alternatively, the AMF is located on earth, the connection / link between mobile access device and AMF may fail, so that the procedure may not always work. The consequence of this configuration may be that a UE, e.g., loT device, may only be in coverage when the mobile access device is close to it, this may be every few hours for a LEO mobile access device. This schedule may be configured in the UE so that it is aware when it has to wake up and (re-)connected. In some cases, the UE may only need to wake up and perform transmission.

[0175] In some cases, e.g. as indicated in S3-240701, the AMF functionality may be divided into at least one ground AMF functionality residing in the ground station and at least one onboard AMF functionality residing in the access device.

[0176] The satellite may work in store and forward mode, and this may make difficult the usage of a ground AMF. To alleviate this problem, in an embodiment that may be combined with other embodiments or used independently, the mobile access device may operate in store and forward mode, i.e. it may not have a continuous connection to the ground AMF, or it may encounter a high probability of gaps or interruptions in its connection with the ground AMF. In this case, the onboard AMF may perform its CIoT functionalities, such as exchanging small user data or SMS with the UEs via NAS messages. The onboard AMF may also keep track of the used keys, nonces, counters / timers, etc. for each UE and update them accordingly. Once the mobile access device establishes a connection with the ground AMF, it may re-synchronize the keys and other security parameters with the ground AMF, and report any user data or SMS that were exchanged in store and forward mode. This way, the ground AMF can maintain a consistent view of the security context and the session state of the UEs served by the mobile access device.

[0177] Section: NTN - Modifications in primary authentication and communication when executed over a relay device / mobile access device with store-and-forward capabilities or over multiple networks

[0178] In some scenarios discussed in herein, e.g., in an NTN scenario where a the first UE 100 tries to register and / or perform primary authentication with the network through a mobile access device, e.g, an NTN access device (e.g., satellite or other mobile access device 123), wherein the store- and-forward (S&F) functionality is invoked (e.g., due to lacking a link with an NTN gateway), the registration process and / or primary authentication procedure may not be executed successfully or the messages of different registration process and / or primary authentication procedures may be mixed up. Recall that the goal of the primary authentication (and key agreement) procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The primary authentication is described in TS 33.501. In these scenarios, the following embodiments may be considered where (1) the description is in the context of NTN but they may also applicable to other (mobile) access devices with store and forward capabilities and (2) the term primary authentication also includes the initial signaling to register in the network:

[0179] In an embodiment that may be combined with other embodiments or used independently, a first NTN access device (e.g., the mobile access device 123 (e.g., satellite)) - which may not have access to an NTN gateway - may relay the UE's messages to a second NTN access device, which has a link established with an NTN gateway and consequently with an AMF that could assist with performing the primary authentication with the UE's HPLMN. Whether the first NTN access device is allowed to relay the UE's registration / authentication messages to another satellite may be subject to a (pre-)configuration by the network and / or be on-demand e.g., by an explicit indication included in the communicated messages by the UE.

[0180] In an embodiment variant that may be combined with other embodiments or used independently, a NTN access device (e.g., the mobile access device 123) through which a UE (e.g., the first UE 100) initiates an authentication procedure (e.g., through a registration request) or the NTN access device gateway (e.g., at RAN 106) may provide the network (e.g., AMF) with assistance data (e.g., ephemeris data, estimated time window to serve the UE, whether or when the link with the UE is still active, (and if provided by the UE) UE location, speed, and direction information, etc) through an NTN gateway, or via another NTN access device (e.g., satellite). Based on this information, the NTN access device or a network function (e.g., AMF) may determine whether to perform / continue the initiated primary authentication over the said NTN access device, select another TN / NTN access device, cache the message / request until a link with the UE could be established (e.g., through another NTN access device), or drop the authentication procedure. In particular, the core network (e.g., AMF) may determine that the initiated authentication procedure is unlikely to succeed due to the connectivity status of the satellite, and the core network (e.g., AMF in combination with UDM) may trigger or schedule a subsequent networked-triggered primary authentication when the NTN connectivity is suitable.

[0181] In another embodiment variant that may be combined with other embodiments or used independently (NTN_SF_SIB), the NTN access device (e.g., the mobile access device 123 in Fig. 3) may indicate its current status as, e.g., a store-and-forward access device or a transparent access device. This status may be included in a SIB broadcasted by the mobile access device 123 (e.g., satellite), in a RRC message, etc. The NTN access device may expose its current status / operation mode, e.g., Store and Forward, to a UE through a second access device, e.g., a terrestrial access device the UE is connected to where the second access device may retrieve the NTN access device operation mode from the core network or the NTN access device.

[0182] In another embodiment variant that may be combined with other embodiments or used independently (NTN_SF policy), the UE may have a policy determining whether the UE is authorized to perform a primary authentication procedure over an access device such as an NTN access device, e.g., working in a Store and Forward mode. The policy may determine the circumstances in which this is applicable. For instance, if the UE does not have access to any (terrestrial) access device, the UE may be allowed to connect to the core network through a non-terrestrial access device. For instance, the policy may determine the timing and location in which such a connection is allowed.

[0183] This status may also be requested by a UE so that the UE can make an informed decision on whether the primary authentication procedure should be started or not, in general, whether it should connect through the NTN access device. In the case that an NTN access device providing service to a UE connects to an NTN gateway through one or more NTN access devices, the NTN access device providing service to a UE will indicate that its status is store-and-forward if any of the NTN access devices used to connect to the NTN gateway are operating in a store-and-forward mode.

[0184] In another embodiment variant that may be combined with other embodiments or used independently, a first NTN access device (NTN_ADi) (e.g., the mobile access device 123 in Fig. 3) may indicate its current status as, e.g., store-and-forward access device or a transparent access device to other NTN access devices (e.g., other mobile access devices (e.g., satellites)) so as to allow them to make an informed decision on whether to relay traffic through NTN ADi and / or through multiple NTN_ADs (e.g., if multiple NTN ADs have no link established with an NTN gateway). To that end, a parameter setting the maximum number of NTN hops allowed between the UE and the network, e.g., max NTN hop limit, may be (pre-)configured by the network or (explicitly) indicated by the UE. For instance, in an emergency case where a user / UE is stranded, and where reachable NTN access devices operate in store-and-forward mode, the UE may indicate a high max NTN hop limit parameter to attempt establishing a connection despite the potentially high latency.

[0185] According to TS 33.501, Clause 6.9.5, a UE shall not initiate a NAS registration over a second NAS connection to an AMF of the same network before primary authentication on the first NAS connection is complete. However, if the primary authentication is interrupted because of the S&F functionality of a mobile access device, then a UE may be prevented from connecting to the network. Thus, in an embodiment that may be combined with other embodiments or used independently, a UE shall not initiate a NAS registration over a second NAS connection to an AMF of the same network before primary authentication on the first NAS connection is complete unless this first NAS connection was done, e.g., through a mobile access device with S&F capability.

[0186] In another embodiment variant that may be combined with other embodiments or used independently (NTN_SF_PA_over_two_satellite_indication), it may be indicated to the core network (e.g., by the UE itself or by the gNB) that the primary authentication attempt by the first UE 100 is taking place over a NTN access device with an enabled store-and-forward functionality, so as to take into account that the NTN access device (e.g., the mobile access device 123) may not ensure / complete the authentication procedure with the first UE 100. This indication may be included in the Registration Request message. Based on this indication, the core network (e.g., the first or second core network 109, 114) may instruct (e.g., by the AMF) to redirect authentication messages (e.g., NAS authentication request) towards another TN / NTN access device that could ensure the communication link to perform / continue an initiated primary authentication procedure. Additionally or alternatively, such decision may be taken together with the 0AM that may be requested to ensure the availability of additional access devices. Such an indication may be also be part of the contents in the primary authentication procedure so that the network (e.g., AUSF) is aware of this fact. Additionally or alternatively, this indication may also be included in a message sent by the network to the UE during the initial registration / primary authentication.

[0187] In another embodiment variant that may be combined with other embodiments or used independently, an NTN access device (e.g., the mobile access device 123) or an NTN gateway (e.g., at RAN 106 in Fig. 3) may provide a list of NTN access devices to the core network (e.g., AMF or 0AM in serving network / home network) which may be used to determine the NTN access device selected to perform / continue an initiated primary authentication. The choice of the NTN access device may be based on parameters which include, but are not limited to, the satellite's (e.g., mobile access device 123) established links (e.g., with other satellites and / or NTN gateways), satellite’s ephemeris data, time estimate to nextNTN gateway, satellite's load, UE location, speed, and direction (e.g., if shared by the first UE 100), and network (pre-)configuration(s), etc.

[0188] In another embodiment variant that may be combined with other embodiments or used independently, the mobile access device 123 (e.g., satellite) may indicate to the first UE 100 and / or the core network (e.g., AMF or 0AM in serving network / home network) the connection details (e.g., potential path(s) and / or timing delay(s) (per path) or satellite identities or satellite locations used for the connection) that UE / CN messages used to perform a primary authentication may take / incur (e.g., stored and forwarded, forwarded directly to the network, forwarded through another satellite then to the network, etc.). This information can be derived based on parameters which include, but are not limited to: the established links of the mobile access device (e.g., satellite) 123 (e.g., with other satellites and / or NTN gateways), time estimate to nextNTN gateway, satellite's load, UE location, satellite’s ephemeris data, speed, and direction (e.g., if shared by the UE), and network (pre-)configuration(s), etc. This has the advantage of providing information to the first UE 100 and / or core network to e.g. select an access option and / or a suitable satellite for its / their access requirements.

[0189] In a scenario, a UE / CN may start a first primary authentication process through one or more mobile access devices (e.g., satellites) with store and forward capabilities. This first primary authentication process may be interrupted at some point of time because of the store and forward capability so that the UE / CN may start or even finish a second primary authentication process. This can lead to multiple problems. A first problem may be related to the fact that the UE or CN may need to wait a given amount of time until an answer to a previous message (stored in a satellite) is received. A second problem refers to the fact that a UE / CN may receive a first primary authentication message from a previous primary authentication procedure that had been stored for some time. In this case, the UE / CN may need to deal with such a message when a second primary authentication may be / have been performed already. Note that this may also happen when a UE connects to two different networks (e.g., the first core network 109 and the second core network 114 as in Fig. 3). To address these problems, the following embodiment variants may be applied:

[0190] In an embodiment that may be combined with other embodiments or used independently, the primary authentication may be enhanced with store -and-forward (S&F) timers that are applied at the UE and / or the CN when the primary authentication is executed over an S&F connection. The S&F timers may be applied when the UE and / or the CN determine (e.g., via an indication) that the primary authentication procedure is executed through a S&F connection. The S&F timer values may be pre-configured or based on a configuration indicated by a network entity, e.g., an NTN gateway or the AUSF. The timers may be configured and / or applied to the UE, AUSF, or AMF.

[0191] In an embodiment that may be combined with other embodiments or used independently, the primary authentication messages may be enhanced to include a timing value, e.g., a counter based on a coordinated universal time (UTC). This may allow the receiving party to determine which of two messages is newer / older. For instance, if a UE sends a first initial registration request, this first registration request would include a timing value tl. If the UE then sends a second initial registration request at a later point of time, this second registration request would include a second timing value t2. Assuming that the first registration request was stored for some time T, and that the first registration request arrives after the second registration request, the receiving party (e.g., CN) can still determine that the second registration request is the one that is currently handled by the UE because it includes a more recent timing value. The receiving party may be configured with a policy to determine which of the procedures / registration requests to execute. Note that this procedure also applies for a home-triggered primary authentication procedure.

[0192] In an embodiment that may be combined with other embodiments or used independently, the primary authentication messages may be enhanced to include an identifier that determines which messages belong to the same procedure. The party initiating a primary authentication procedure may select an identifier and include it in said primary authentication procedure. This identifier should be long enough to avoid collisions. The party receiving the primary authentication request would include this identifier in its reply to allow linking messages that belong to the same primary authentication procedure instance. This can prevent messages of different primary authentication procedures from being mixed together. The identifier may be an increasing counter, or a number selected at random.

[0193] In an embodiment that may be combined with other embodiments or used independently, a UE may have a policy determining whether it is allowed or not to use (NTN) access devices working in store and forward mode. The core network may provide the UE with credentials (e.g., an authorization token) e.g., upon primary authentication or when the network (e.g., AMF) determines that the UE may use one or more access devices in store and forward mode. The credentials (e.g., authorization tokens) may include or be linked to the conditions under which the UE may be authorized to transmit or receive data in store and forward mode. For instance, a UE transmitting data may only be allowed to transmit data of up to a size and this may be verified by the (NTN) access device by means of the credentials (e.g., authorization token). For instance, an authorization token may always be required based on policy, e.g., when large amounts of data need to be stored.

[0194] In an embodiment that may be combined with other embodiments or used independently, the credentials transmitted to one or multiple access devices may be aggregated, e.g., at the access device and / or a network function such as AMF and it may be verified whether they have been transmitted multiple times. This may give an indication of misbehaving UEs (re-using the same credentials in multiple transmissions) or whether the system is being subject to a DoS attack.

[0195] For instance, a UE may be configured with a policy to select an (NTN) access device that is not operating in store and forward mode to make sure that the emergency connection is established as fast as possible. For instance, an (NTN) access device working in store and forward mode may treat an emergency access request in a different manner. For instance, it may try to handle the emergency access request faster, e.g., by prioritizing them. For instance, an (NTN) access device working in store and forward mode may announce (e.g., in a SIB) how emergency access requests should be protected, e.g., it may request including credentials, e.g., an authorization token provided by the home network, proving that the device is authorized to transmit said emergency request. These credentials may be provided in a configuration phase and the access device may have the means to verily them. This may be required, e.g., when the access device is running out of resources, e.g., due to a DoS attack.

[0196] In a further embodiment that may be used independently or combined with other embodiments (NTN SF emergency), a UE may be pre-configured / provisioned (e.g., stored in USIM) with credentials (e.g., security materials) and / or emergency parameters e.g., emergency service code / token, whose use may depend on (NTN) access device announcement e.g., in a SIB, for emergency services support. The use of said credentials and / or parameters may implicitly indicate to the mobile access device (e.g., NTN payload) operating in S&F mode, that the UE is authorized to request emergency services, and depending on a (network / operator) policy configured at the (NTN) access device, UEs using the emergency credentials and / or parameters (e.g., emergency service code / token) may be prioritized e.g., emergency messages (e.g., SMS, audio message) received from UEs using said credentials and / or parameters may be prioritized in terms of storage (e.g., Mobile Originated (MO) messages to be stored), and / or prioritized in terms of MO messages to be forwarded to the network once a feeder link is available. Furthermore, UEs using said emergency credentials and / or parameters (e.g., emergency service code / token) may be prioritized during RRC connection setup e.g., based on RRC Establishment Cause value set to emergency and / or a combination of (emergency) RRC Establishment Cause and the use of specific emergency credentials / parameters (e.g., stored in USIM).

[0197] In another embodiment that may be combined with other embodiments, a UE requiring emergency services from an (NTN) access device may use its emergency indication, e.g., emergency service code / token, or a part thereof, or a function thereof e.g., a cryptographic function (e.g., one-way function such as SHA-256), during the initial messages of the communication establishment, e.g., RRC Connection Setup procedure’s contention resolution phase, e.g., by setting a field, e.g., the Contention Resolution Identity (CRI), or a part thereof (e.g., the K MSBs / LSBs) to an emergency service code / token, if a contention-based random access procedure is performed. Upon receipt, the (NTN) access device may perform a check on the received field, e.g., CRI values, or parts thereof, to check whether any of the received field, e.g., CRIs ,or parts thereof, match with an emergency service code / token, a part thereof, or a function thereof. The (list of) emergency service codes / tokens may be pre-configured / provisioned at the (NTN) access devices supporting emergency service, and updated If, upon checking, afield, e.g., a CRI value matches with a valid emergency service code / token, the (NTN) access device may replay / broadcast the matched CRI value, thus prioritizing the UE requesting emergency services. Additionally, or alternatively, the emergency service code / token may be configured to be expired after one-time usage, thus mitigating potential replay attacks where an unauthorized party (e.g., malicious eavesdropper) may capture the emergency service code / token and attempt to abuse emergency services.

[0198] In another embodiment that may be combined with other embodiments or used independently, the emergency credentials and / or parameters (e.g., emergency service code / token) may be used in addition to other emergency indications e.g., RRC Establishment Cause, which may be set to emergency during RRC Connection Setup, and / or Registration Type, which may be set to Emergency Registration, during NAS Registration Request, when requesting emergency services from an (NTN) access device operating in S&F mode.

[0199] In another embodiment that may combined with other embodiments or used independently, when a UE requests emergency services from an (NTN) access device, using at least one, or a combination of emergency indications, as described in previous embodiments, where said UE is prioritized, the (NTN) access device, upon feeder link availability, may forward emergency messages to the core network. Based on the priority order set by the (NTN) access device, and whether Mobile Terminated (MT) traffic, targeted at the UE requesting emergency services, is received from another party (e.g., emergency dispatcher), the core network may indicate to the (future) NTN access device, which supports emergency services, a prioritization list of UEs (e.g., which requested emergency services), based on which UEs are served (e.g., with MT traffic).

[0200] In another embodiment that may be combined with other embodiments or used independently, an (NTN) access device operating in S&F mode may have communication links (pre- established with other (NTN) access device(s) (e.g., using ISL), and although ISL may not be used during S&F operation mode, the (NTN) access device may be configured e.g., through a network / operator policy, to bypass the ISL usage limitation in S&F mode, if an authorized UE (for emergency services) requests emergency services. For instance, the authorized UEs may be configured to indicate an urgency level (e.g., low, medium, high, critical), based on which, an (NTN) access device may determine whether it should bypass ISL use limitation, and forward the emergency requests / messages to another (NTN) access device with an available feeder link.

[0201] In another embodiment that may be combined with other embodiments or used independently, the authorization of a UE to request emergency services from (NTN) access devices may be associated with its subscription details and / or its permanent equipment identifier (PEI), such that if UE does not have a USIM, it may still be able to request emergency services through an (NTN) access device (e.g., operating in S&F mode). The (NTN) access device, or a NF on-board of the satellite, may be provisioned with a list of (valid / whitelisted) PEIs corresponding to UEs authorized for emergency services, which the (NTN) access device may use to check whether a UE is authorized to request emergency services. The list of (valid / whitelisted) PEIs may be updated upon request, or periodically by the core network, upon feeder link availability. Additionally, or alternatively, emergency credentials and / or parameters (e.g., if configured at the UE / ME), used as described in previous embodiments, may be associated with PEIs, such that upon receiving a message (RRC or NAS message) with an emergency indication, an (NTN) access device may verify whether the emergency credentials / parameters used / included correspond to the PEI indicated by the UE, thus mitigating the potential abuse of emergency services by malicious actors.

[0202] In another embodiment that may be combined with other embodiments, null ciphering / integrity algorithms may be permitted to be used (e.g., on NAS and / or AS level) between UE and the (NTN) access device or NF (e.g., AMF) on-board, in the case where UE uses valid emergency credentials and / or parameters, which are checked by the (NTN) access device and / or an NF (e.g., AMF) on-board. On the (emergency service requesting) UE’s side, accepting the use of null ciphering / integrity algorithms, indicated by the NF on-board of the satellite (e.g., AMF), is dependent on whether the UE has indeed requested emergency services.

[0203] In a further embodiment that may be combined with other embodiments or used independently, UEs may be configured to provide and / or requested to provide their remaining amount of energy and / or lifetime till the energy supply is exhausted, in particular, when requesting emergency services from a mobile access device (e.g., a satellite operating in store & forward (S&F) mode). This information may allow the mobile access device to determine the urgency of the request and prioritize it accordingly. For example, a UE with low battery level or short lifetime may have a higher priority than a UE with sufficient power or long lifetime. Moreover, this information may also allow the mobile access device to determine whether an authentication procedure may be performed (while the satellite is (anyhow) in S&F mode) or whether that procedure may be skipped to save time and resources. The amount of energy or the remaining lifetime of the UE may be provided to the core network for further evaluation and possible actions (e.g., sending rescue teams, notifying relevant authorities, etc.). The UE may include this information in the NAS registration request message or in a separate NAS message sent to the mobile access device. The mobile access device may verily the validity of this information, e.g., by checking its format or consistency, and act accordingly. Depending on the information about the remaining energy budget and / or lifetime, the core network and / or mobile access device may also determine how to provide an answer to the UE. For instance, if the lifetime of the UE is 5 minutes but the next mobile access device that may carry an answer is only available in 15 minutes, the answer may be dropped or sent via another channel

[0204] In a further embodiment that may be combined with other embodiments or used independently, UEs may be configured with an authorization token proving that it is authorized to use a satellite in store and forward mode. This authorization token can be validated by the mobile access device before storing the provided information. For example, the UE may receive the authorization token from its home network during a configuration phase, including it in the NAS registration request message sent to the mobile access device. The mobile access device may verify the validity of the authorization token, e.g., by checking its signature or expiration date, and accept or reject the request accordingly. This way, the network can control which UEs are allowed to use the store and forward functionality of the satellites, preventing unauthorized or malicious usage.

[0205] In a further embodiment that may be combined with other embodiments or used independently, the core network may provide a satellite with an authorization token when the mobile access device is going to work in store and forward mode for a given amount of time. The authorization token may indicate that the satellite is authorized to receive, store, and forward data from and to UEs in its coverage area, and it may have a validity period and / or a signature associated with it. The satellite may provide the authorization token to a UE when distributing data that may have been slightly outdated due to store and forward processing, or when the satellite announces its services so that a UE becomes aware that the satellite is authorized to operate in store and forward mode. The UE may verily the authorization token, e.g., by checking its signature or expiration date, and decide whether to trust the satellite or not. This way, the network can control which satellites are allowed to offer store and forward functionality to UEs, preventing unauthorized or malicious usage.

[0206] In an embodiment that may be combined with other embodiments or used independently, a UE and a mobile access device may exchange authorization tokens during the primary authentication procedure. For example, the UE may include its authorization token in the NAS registration request message sent to the mobile access device, and the mobile access device may include its authorization token in the NAS authentication response message sent to the UE. The authorization tokens may prove that the UE and the mobile access device are authorized to use the store and forward functionality of the satellite network, and they may have validity periods and / or signatures associated with them. The UE and the mobile access device may verily the authorization tokens, e.g., by checking their signatures or expiration dates, and decide whether to trust each other or not. This way, the network can control which UEs and mobile access devices are allowed to perform primary authentication over the satellite network, and prevent unauthorized or malicious usage.

[0207] In an embodiment that may be combined with other embodiments or used independently, an access device receiving credentials (e.g., an authorization token) from a UE may share the received credentials with other access devices in its vicinity or in its communication range. The access device may use any suitable communication means, such as NTN links (e.g., ISL), to transmit the received credentials to other access devices. The purpose of sharing the received credentials is to prevent the misuse of said credentials by the same or different UEs. For example, if a UE sends the same authorization token to two different access devices, the second access device may reject the token as invalid after receiving the information from the first access device that the token has been used. Alternatively, access devices may forward received credentials to a network function (NF) in the core network, such as a credential manager (CM), which may perform the validation and revocation of the credentials. The NF may also inform the access devices about the status of the credentials periodically, upon their expiration, or upon request. This may prevent the UEs from reusing or forging the credentials for unauthorized transmissions in store and forward mode.

[0208] In an embodiment that may be combined with other embodiments or used independently, credentials issued to, or computed by, a UE for NTN access may include various pieces of data that may allow authenticating and authorizing the UE. For example, credentials may include a unique identifier of the UE, such as a subscriber permanent identifier (SUPI), a subscriber concealed identifier (SUCI), a temporary UE identifier such as a GUTI, or a public key; a service identifier that indicates the type of service that the UE is allowed to use, such as store and forward mode, direct mode, or real-time mode; a data quota that specifies how much data the UE can transmit or receive using the NTN access devices; a validity period that indicates how long the credentials are valid for; and a signature that verifies the authenticity and integrity of the credentials using the private key of the credential manager (CM). The credentials may also include other information, such as the priority level, the security level, or the access preferences of the UE. The credentials may be encoded in a suitable format, such as JSON Web Token (JWT), XML, or binary.

[0209] In some scenarios, a puzzle is used to prevent DoS of un-authenticated UEs. A UE may send a registration request, the satellite may decide to offer a puzzle to limit the DoS attack and sends it to the UE. The UE has then to solve it, and send again the registration request with the solved puzzle. If the puzzle is correct, the registration request is accepted. A puzzle may be used, e.g., as follows: the satellite generates random seed, and sends to UE in the registration message and asks to find a value V such that the k LSBs of Hash(seed, V) equal 0. The UE then has to try multiple V values (how many depend on k) until it finds one that fits the condition. Then the answer of UE to the puzzle will be that value V that is easily verifiable by the satellite. This requires an asymmetric effort, very little effort at the satellite (generate seed + perform a check) vs around 2A{k-l } hash computations at the UE. This approach is however still problematic because it introduces one additional message and round-trip. Furthermore, the presence of a fake satellite may force a UE to solve very difficult puzzles. To solve these problems, the following embodiments may apply:

[0210] In an embodiment that may be combined with other embodiments or used independently, the satellite may distribute the puzzle and the parameters in a System Information message, for example a SIB, e.g., SIB1 or SIB19. The parameters may be generic, but the answer may be device specific. For instance, if the registration request includes an identifier ID of the UE (e.g., ID may be SUCI or GUTI), the SIB may include the parameters of the puzzle (e.g., seed and parameter k as above), and the puzzle is to determine an unknown value V such that a condition is met (e.g., the k LSB of Hash(seed, ID, V) equals 0). Different UEs will then need to compute different solutions. The satellite may also change the seed value and k value depending on the determined DoS situation. If no DoS is observed, no seed may be broadcasted, while if the satellite is subject to heavy connections (e.g., an attacker with significant computation power), seed may be updated more frequently and k may take a greater value to increase difficulty. This embodiment allows a UE to determine a satellite, determine whether it is using / requiring a puzzle, and then send a message (e.g., registration request) already with the solved puzzle. This allows reducing the communication overhead. This approach is also beneficial because it requires generating a single puzzle for all potential UEs sending a request, and the answers are UE specific. Note that the seed may also be implicit or explicit, for instance, it may also be the satellite ID (e.g., similar to a PCI) concatenated with the UTC time, e.g., measured in minutes. This implicit seed ensures that each satellite uses a different puzzle and that the puzzle changes regularly. In this case, the only parameters that need to be broadcasted / distributed would be the accuracy of the time (how frequently the puzzle changes, e.g., every minute, every 2 minutes, ...) and the k parameter. Note that a problem of this is that its construction may be vulnerable to pre-computation attacks.

[0211] In a related embodiment that may be combined with other embodiments or used independently, the difficulty of the puzzle may also depend on the amount of data that needs to be stored or transmitted. For instance, storing more data in a mobile access device in store and forward mode may require the solving of a more difficult puzzle, than when the data to store is a very small message. This makes sense because the satellite may want to verily the UE before receiving / processing a large amount of data.

[0212] In a related embodiment that may be combined with other embodiments or used independently, a first message (e.g., SIB1) is used by a mobile access device to distribute the parameters of a puzzle, type / specification / identifier of puzzle, whether it is UE specific (e.g., by using the UE ID as input in the puzzle or not), and whether a puzzle is used, and to which it may apply (e.g., registration request, sending of data to mobile access devices in store and forward, etc and one or more UEs may receive this first message. One or more UEs may send a second message (e.g., registration request) solving the puzzle and the satellite verifying the puzzle before processing the second message.

[0213] In a related embodiment that may be combined with other embodiments or used independently, the puzzle may also depend on credentials (e.g., secret keys, tokens) associated with authorized access through NTN access devices. For instance, a cryptographic keyed hash function (e.g., HMAC) may be used together with the parameters (e.g., seed, k) broadcast by the satellite, to solve the puzzle and include the solution in the response message (e.g., registration request).

[0214] In a related embodiment that may be combined with other embodiments or used independently, the difficulty of the puzzle may increase depending on the time required by UE(s) to solve the puzzle, the number of requests being received, and / or the NTN payload’s resources (e.g., the less resources available, the more difficult the puzzles are).

[0215] In a related embodiment that may be combined with other embodiments or used independently, a potential issue with the presence of an attacker with significant computational resources is that the satellite may significantly increase the difficulty of the puzzle, thus affecting legitimate UEs’ ability to solve the puzzle and attempt registration. To address this issue, the satellite may allocate different challenges to different tracking areas. For instance, the satellite broadcasts in SIB messages (e.g., SIB19) a list of TAIs, each with its corresponding puzzle parameters (i.e., seeds, K) which are periodically updated to reflect the change in difficulty, based on the criteria described in the previous embodiment. This has the advantage of limiting the increased difficulty of a puzzle to a confined area. Additionally, or alternatively, if an NTN pay load receives a message with a solved puzzle after a time period T from the puzzle announcement, and T is (significantly) less, or less by a predetermined threshold, than the time period T’ which corresponds to the difficulty of the puzzle, the NTN payload may (re-)challenge the UE from which said solved puzzle was received, with a more difficult puzzle, which may also be UE specific, as described in previous embodiments.

[0216] In an embodiment that may be combined with other embodiments or used independently, a UE may be provided with a short-term key pair for NTN access by the core network or the satellite. The key pair may be based on a cryptographic algorithm, such as RSA or ECC, that allows the generation of digital signatures. The key pair may be certified by the entity that performed the authentication of the UE, such as the core network or the satellite, and may have a limited validity period, such as 30 minutes. The certificate may include the public key of the UE, the identity of the UE, the validity period, and the signature of the certifying entity. The certifying entity may also provide the UE with a certificate chain that links its own certificate to a trusted root certificate, such as the one of the NTN operator or the satellite operator. When the UE needs to connect again to an NTN access device, such as a satellite, the UE may use the private key to sign a message that includes the current UTC time and a transaction identifier. The UE may then send the message, along with the signature, the certificate, and the certificate chain, to the NTN access device. The NTN access device may verify the certificate and the signature using the public key of the certifying entity, and may also check the freshness of the message by comparing the signed UTC time with its own clock. If the message is valid and recent enough, the NTN access device may authorize the UE to use the service requested. This may prevent an attacker from eavesdropping or replaying the messages exchanged between the UE and the NTN access device.

[0217] In a related scenario to previous embodiment, a UE may use the public / private key and certificate and share it with a first mobile access device in an attach / registration request. The satellite may verify it and use the public key to encrypt a temporary ID (e.g., GUTI) that may be used later for paging the device. The first mobile access device may share this temporary ID with the core network that may use it later (share with a second mobile access device) when the second mobile access device is in communication range of the UE. This scenario benefits from above embodiment. However, the UE cannot verify that the temporary fD is coming from a trusted satellite, and this, may lead to a DoS attack. To alleviate this problem, the first mobile access device may also sign the assigned temporary ID with its own keying material (e.g., private key) and attach a certificate so that UE can verify it. This information of the first mobile access device may be included in the partial attach / registration accept (message that may include the temporary ID) or in a SIB.

[0218] In an embodiment that may be combined with other embodiments or used independently, a UE, upon successful authentication with a first mobile access device, is configured with credentials, e.g., authorization tokens, e.g., one-time passwords, or keys, for the communication with future mobile access device that will be available at the location of the UE in a given time window, e.g., the next 30'. For instance, a UE may be configured with the following information:

[0219] ID1, Keyl, In 10', ID_Mobile_Access_Device_2

[0220] ID2, Key2, In 20', ID_Mobile_Access_Device_3

[0221] ID3, Key3, In 30', ID_Mobile_Access_Device_4

[0222] The UE, when establishing a communication, or sending data to those mobile access devices may use said credentials. For instance, once the mobile access device broadcasts its system information, the UE may know the ID of the Mobile Access device, and use it to determine whether it has suitable credentials. For instance, if data is to be transmitted from UE to a second mobile access device, UE may make use of a configured key K to protect data, e.g., in AS security or NAS security. For instance, if data is to be transmitted from UE to a second mobile access device, UE may include a message authentication code computed with the configured key or one-time password. In this examples, UE may include an identifier associated to said credentials. The same credentials may have been configured in the second mobile access device upon successful authentication with the first mobile access device.

[0223] In an embodiment (related to the previous one) that may be combined with other embodiments or used independently, it is to be noted that using different identifiers for different mobile access devices is also beneficial to prevent tracking and linkability attacks of the UE. It is to be noted that the identifier may be a RAN identifier or a NAS identifier such as the GUTI. Note also that the network / mobile access devices may also use the identifier(s), for instance, the UE identifier assigned to a mobile access device may be included in a paging message so that each mobile access device can page the same UE with a different ID. The UE ID assigned to a mobile access device or to be used with a mobile access device may be computed by means of a function (e.g., a key derivation function or a hash function) taking as inputs one or more of the UE long term identifier, the ID of the mobile access device, and / or time of access, uplink or downlink identifier, and a key / random value, e.g., as:

[0224] F(UE long term identifier, mobile access device identifier, downlink message, time of access). This allows a UE to easily generate and / or check whether the ID used in a paging message is directed to the UE, and / or determine the ID that the UE has to use. This also allows using different IDs for the uplink and the downlink. Note that the function may also be implemented by means of a look up table if the UE / mobile access device is configured with all potential ID values. It is to be noted that in some scenarios, a first mobile access device may assign an interim GUTI to a UE once the UE has performed an initial registration / attach request and the mobile access device may share registration / attach request and interim GUTI with the core network (on the ground). The core network may keep it until the next second mobile access device is available to provide the Authentication Request message. The second mobile access device may then page the UE with the interim GUTI and the UE may then reply with the Attach / Registration Request including the interim GUTI. However, this scenario is still prone to tracking / linkability attacks because the initial assignment of the interim GUTI is in the clear, and thus, an attacker can misuse this value. Also the same interim GUTI is used in uplink and downlink messages. Thus, this scenario also benefits from the ideas in, e.g., previous embodiment, wherein the ID used by UE / mobile access device may be derived from a Function / table that may take as inputs one or more of the long term ID of the UE, ID of the mobile access device, access time, downlink or uplink. In particular, this approach makes it unnecessary to perform an initial assignment of an interim GUTI by the first mobile access device (so that this interim GUTI cannot be eavesdropped). The second mobile access device may be provided by the core network (on the ground) with the IDs / GUTIs to use for the downlink / uplink in a subsequent communication in a given interval of time. For instance, the second mobile access device may receive GUTI Downlink and GUTI Uplink. The second mobile access device may page the UE with GUTI Downlink. A UE may derive it as F(long term identifier, mobile access device identifier, downlink message, time of access). If the value matches, UE may derive GUTI Uplink as F(long term identifier, mobile access device identifier, uplink message, time of access). The second mobile access device may then check whether the values match, and then send the authentication request.

[0225] In a related scenario, a mobile access device may compute a NONCE and share it with the core network in the ground so that the mobile access device can compute a K specific to the mobile access device and a UE. The satellite may then broadcast the NONCE, and random value RV, e.g., in a SIB. A mobile access device may then use the NONCE to derive the same K, and it may then derive a MAC from K, RV and a random value RV’ generated by the UE and send MAC and NONCE, and RV to the mobile access device in a protected Attach / Registration request. The mobile access device can verily MAC, and if the verification succeeds, in can send back another MAC’ value (in a protected attach / registration reject message) computed in a similar way, e.g., by swapping the order of the RV and RV’. In this scenario, the mobile access device may then go on with the procedure with the core network (in the ground) that may use at a later phase a different mobile access device to finish the authentication procedure with the UE whereby the UE may trigger it by sending an (unprotected) Attach / Registration request. This scenario shares some similarities with other embodiments in this invention, and can benefit of the ideas. For instance, instead of a NONCE, a UTC-based counter can be used to determine the key to use for some time in a satellite. For instance, different satellites may have different keys. For instance, instead of requiring the exchange of random values, the UTC-based counter can be used as input in the MAC computation to ensure the freshness. The second attach / registration request by the UE that is sent unprotected, should also be sent protected, ideally using a key that is specific to the second mobile access device so that the second mobile access device only sends an Authentication Request (with AUTH and RAND) to a trusted UE.

[0226] In another embodiment that aims at optimizing communication between end UE - e.g., when at least one of the UEs is served by mobile access devices (e.g., satellites) operating in S&F mode) - and that may be combined with other embodiments, when a (first / source) UE authenticates to a first mobile access device, it may try to send Mobile Originated (MO) transactions / data (e.g., sends an SMS / voice / video) to a target entity (e.g., a second / target UE), the communication data may be stored at the first access device until a feeder link is available, and once the feeder link is available, the first mobile access device forwards the communication to the UE’s Serving or Home PLMN, which then sends it to the target entity. The target entity may respond with Mobile Terminated (MT) transactions / data, which is sent through and may be stored at the UE’s Serving or Home PLMN. Based on UE’s last known location, UE’s Serving / Home PLMN may determine a second mobile access device (e.g., satellite) that could serve the UE in the next window opportunity (i.e., the second mobile access device is the satellite that will cover the UE’s area next), then, depending on whether the second mobile access device, at the time it is selected by the Serving / Home PLMN, has a feeder link, or does not have a feeder link but will have it prior to covering the first UE’s area (e.g., next window opportunity to serve first UE is in 20 minutes, and a feeder link will be available in 5minutes), or does not have a feeder link and will not have it prior to covering the first UE’s area, the Serving / Home PLMN and / or an entity managing the satellites determines whether the second mobile access device may be selected to provide MT transactions / data to the UE. This selection may be based on the ephemeris data of the satellite and last known location of the UE. For instance, upon determining the second mobile access device that could serve the UE in the next window opportunity, if the satellite does not have a feeder link, and will not have it prior to serving the UE, the Serving / Home PLMN may select a third mobile access device, that fulfills the feeder link availability condition(s), to route the MT transactions / data through, to the first UE. Additionally, to guarantee the communication data’s authenticity and / or authorization and / or confidentiality, the MT transactions / data may be protected, e.g., signed by the Serving / Home PLMN and / or the second / third / serving (depending on which satellite will serve the first UE) mobile access device with a private (signing) key, such that it may be verified by the first UE using a public key that it has been pre-configured / provisioned with and is associated with the serving mobile access device, as described in the previous embodiment. Additionally, or alternative, the public / private key pair (or keys or one-time passwords) may have been generated by the first access device after the successful authentication of the UE and / or reception of the MO data. The public keys (or keys or one-time passwords) may be configured in the UE for the later reception of MT data. The first mobile access device may also indicate which second mobile access device may be using certain credentials based on its knowledge of which other second mobile access device may be providing coverage in that area within a time window. The counter parts of the credentials (e.g., private keys, and / or keys, and / or onetime passwords) may be provided to the Serving / Home PLMN and / or an entity managing the satellites that may use them to protect the MT data. These credentials may be linked to an identifier (credential identifier) so that the UE can determine which credentials to use to verily / decrypt the MT data.

[0227] In another embodiment that may be combined with other embodiments or used independently, and that is aimed at UE context management (e.g., to transfer the UE context shared with a first mobile access device used for MO data transfer to a second mobile access device used for MT data transfer), when a UE authenticates and establishes a link and security context(s) (e.g., NAS and / or AS) with a first mobile access device with the gNB / eNB and / or AMF / MME on-board (e.g., either with CN components on board, or through a two-round stage (e.g., when CN in on the ground), the first mobile access device may, upon feeder link availability, transfer said context(s) to a CN NF on the ground (e.g., AMF / MME), which determines, based on e.g., ephemeris data, which S&F capable future mobile access device with a feeder link, or with an opportunity to have a feeder link prior to serving UE’s area, should be selected to serve the UE, and thus provide it with the UE’s security context(s). The selected mobile access device may be provisioned with parameters to update the security context(s) (e.g., Next Hop (NH) Parameter) or it may be provided with an already updated (by AMF / MME on the ground) UE security context(s), which the (future) mobile access device may indicate to the UE through an RRC message (e.g., during RRC connection setup), in addition to parameters to update the security context(s), to be sent to the UE, for future security context update (i.e., to be used with the mobile access device that may serve the UE after the next mobile access device). The UE may update its security context(s) based on parameters (e.g., NH) received from the previous serving mobile access device, and start using the new security materials with the serving mobile access device, thus maintaining the authentication session. Additionally, or alternatively, the security context(s) may be updated based on a combination of parameters provided by the ground NFs (e.g., AMF / MME) and K’ (as described in previous embodiments), thus ensuring the legitimacy of both the UE and serving mobile access device(s), while allowing the ground NFs to have some control over UEs’ authentication session management.

[0228] In an embodiment that may be combined with other embodiments or used independently, NTN access devices may also store and check the policy information associated with the credentials received from UEs. For instance, if a UE sends an authorization token to an NTN access device, such as a satellite, the satellite may verify the signature of the token using the public key or digital certificate of the CM. The satellite may then extract the information from the token, such as the UE identity, the service identifier, the data quota, and the validity period. The satellite may check whether the UE is authorized to use the service requested, whether the data quota is sufficient for the data size, and whether the validity period has expired or not. The satellite may also check other policy information, such as priority level, security level, or access preferences of the UE, and provide appropriate service accordingly. Similarly, if a UE sends a one-time pad to an NTN access device, such as a drone, the drone may check whether the one-time pad has been assigned to the UE by the CM and whether it matches the expected value. The drone may also check the policy information associated with the one-time pad, such as the service identifier, the data quota, and the validity period, and authorize the UE accordingly. The NTN access devices may update the policy information periodically or based on certain events, such as credential expiration, revocation, or renewal.

[0229] In an embodiment that may be combined with other embodiments or used independently, a network function (NF) in a core network may act as a credential manager (CM) for the NTN access devices and UEs. The CM may have a private key to sign authorization tokens and generate one-time pads for UEs. The CM may share the corresponding public key or digital certificate with the NTN access devices so that they can verify the received authorization tokens from UEs. The CM may also share the one-time pads or other credentials, together with UE(s) identifiers which identify the UE(s) with which one-time pad(s) or other forms of credentials are associated, with the NTN access devices so that they can authenticate the UEs using store and forward mode. The CM may monitor and update the credentials periodically or based on certain events, such as expiration, revocation, or compromise of the credentials.

[0230] In an embodiment that may be combined with other embodiments, or used independently, a network function (NF) in the core network (CN), such as the credential manager (CM), may monitor the usage and validity of the credentials issued to a UE for NTN access. The CM may check with a database function (DF) in the CN, such as the unified data repository (UDR), whether the UE is authorized to use the NTN access devices, such as satellites, drones, or balloons. The DF may store and manage the subscription and policy information of the UE, such as the service level agreement (SLA), quality of service (QoS), or access preferences. If the DF confirms that the UE is authorized to use the NTN access devices, the CM may then trigger the creation and distribution of new credentials for the UE. The CM may generate new authorization tokens and one-time pads for the UE using its private key. The CM may share the new credentials securely with the UE using a NAS connection or another security procedure, such as Steering of roaming (SoR) or UE parameter update (UPU). The SoR or UPU may, by means of a signaling message sent by the CM to the UE over the NTN link, carry the new credentials encrypted with the public key of the UE. The UE may decrypt the SoR / UPU message using its private key and store the new credentials for future NTN access. The CM may also share the new credentials with the NTN access devices so that they can verify and authenticate the UE transmissions using store and forward mode. The CM may distribute the new credentials to the NTN access devices using any suitable communication means, such as NTN links, terrestrial links, or NTN relay nodes. The CM may update the credentials periodically or based on certain events, such as expiration, revocation, or compromise of the credentials. In a procedure, a mobile access device may be configured with a key K’ per UE. This K’ may be derived from a root key K stored in the UE, e.g., in the USIM, and in a database function such as the UDR. This key K’ may be used by the UE and a mobile access device to authenticate / authorize the usage of a mobile access device such as a satellite. K’ may be linked to and identified by the UE ID, e.g., IMSI / SUPI. For instance, when a UE sends a registration request, the satellite may use K’ to verify this request. K’ may be derived from K by means of a key derivation function that may take as input K and the identity of the mobile access device. This approach may be useful because it may allow authenticating the UE / mobile access device when the mobile access device is exclusively within communication reach of the UE. Once the UE is authenticated by the mobile access device and the mobile access device has again access to the ground, the stored data as well as the UE identity (e.g., IMSI / SUPI) may be transferred to a store and forward center. This store and forward center may serve as / include a second twin UE device, and it may have a second set of UE ID (a different SUPI / IMSI) and another long-term key K2 associated to said second twin UE device. These credentials may allow the twin UE device in the store and forward center to perform a second authentication with the core network on behalf of the UE itself. In other words: a first authentication / authorization is done between UE and mobile access device based on the UE ID and K’, mobile access device transfers UE ID to the store and forward center, the store and forward center containing the second twin of the UE device performs a second authentication / authorization with the CN based on a second UE ID and a second key K2.

[0231] In another procedure, a database function such as 4G HHS may be in the mobile access device, e.g., satellite. Similar to the aforementioned approach, the mobile access device may store a key K’ that is UE specific, e.g., derived from a root credential of the UE. UE and mobile access device may try to run the primary authentication, e.g., EPS AKA. A UE may indicate its identity (e.g., IMSI). If a satellite does not include the required credentials, e.g., a key K’, the satellite may send an authentication failure to the UE. Furthermore, when the mobile access device is again able to connect to the core network, the mobile access device may indicate to the core network databased function the identity of the rejected UE. The satellite may then reply with the credentials of the rejected UE. At a later stage, UE may attempt again the primary authentication with another mobile access device. If this mobile access device has the required credentials of the UE, the UE and mobile access device may perform primary authentication using, e.g., EPS AKA with the following modified operation in steps 11 and 14. In step 11, if the databased function of the mobile access device has the UE key, EPS AKA proceeds as described in clause 6.1 in 3GPP TS 33.401 [3], with K’ replacing the permanent subscriber key in all computations. In step 14, when the UE receives an Authentication Request Message from the mobile function on the mobile access device, the UE (e.g., USIM) first derives K’ from the master key, e.g., using the key derivation process specified in Annex F in TS 33.401 [3], Then, EPS AKA proceeds as described in clause 6.1 in 3GPP TS 33.401, with K’ replacing the permanent subscriber key in all computations. If successful, the mobility function on the mobile access device sends an Attach Accept Message to the base station on the satellite. Then, the base station forwards the Attach Accept message to the UE.

[0232] However, these procedures require the storage of a key K’ per device (and potentially other UE specific data). This may lead to high complexity in the management of those keys. Furthermore, this approach may require sending the UE ID (e.g., IMSI or SUPI in the clear) unless the private key of the home network is configured in the satellite itself (that may represent a security risk). Another issue is that the authentication of the UE is not end to end (between UE and core network, but it is divided into two steps). Thus, it is a goal of this invention to address these and other issues:

[0233] In an embodiment that may be combined with other embodiments or used independently, a network function (NF) in the core network (CN), such as the credential manager (CM), may generate and distribute group keys GK for UEs that are authorized to use the NTN access devices, such as satellites. A group key may be a type of credential or key that may be shared by multiple devices or UEs and may be used to prove the right to use the satellite. The CM may create one or more groups of UEs based on certain criteria, such as location, priority, service type, QoS level, or access preference. The CM may assign a group key to each group and share it securely with the UEs belonging to that group using a NAS connection or another security procedure, such as a SoR or UPU. The key may also be configured in a USIM whose purpose is to enable the secure communication with a type of mobile access devices (e.g., NTN access devices) and / or a specific operational mode of the access device (e.g., S&F mode), and allow the mobile access device to verily that the UE is authorized to make use of it in store and forward mode. The UEs may store the group key and use it to authenticate and authorize their transmissions to the NTN access devices. The CM may also share the group key with the NTN access devices so that they can verify and authenticate the UE transmissions using store and forward mode. Each mobile access device may have a different satellite-specific GK (SSGK) that may be derived by means of a key derivation function, e.g., as SSGK = KDF(GK, ID) where ID is the ID of the satellite. The CM may distribute the group key to the NTN access devices using any suitable communication means, such as NTN links, terrestrial links, or NTN relay nodes. The CM may update the group key periodically or based on certain events, such as expiration, revocation, or compromise of the group key. The use of group keys may reduce the complexity and storage requirements of the NTN access devices, as they do not need to store a key K' per device or UE. The use of group keys may also increase the efficiency and scalability of the NTN access, as the CM can manage the access rights of multiple UEs with a single group key.

[0234] In an embodiment for securing the UE ID transmission using a public / private key pair that may be combined with other embodiments or used independently, the mobile access device stores a key, e.g., K' or SSGK, e.g., K’ is UE specific and can be used to authenticate and authorize the UE transmissions using store and forward mode. The UE may obtain this key from the CM or another NF in the core network using a NAS connection or another security procedure, such as a SoR / UPU. The UE may also store the public key associated to the mobile access device, which may be configured in the UE / USIM by the home network. This public key may have been provided to the home network by the entity managing the mobile access devices, such as the satellite operator or the NTN service provider. Alternatively, the UE may obtain the public key of the mobile access device from a SIB, such as SIB1 or SIB 19, broadcasted by the mobile access device. The SIB may also indicate the credentials (e.g., a certificate or a signature) to verily the authenticity and integrity of the public key, and / or simply the identity of the mobile access device (provider) so that the UE can pick up the right credentials, e.g., public key. The UE may use the public key of the mobile access device to encrypt its ID, such as IMSI or SUPI, and send it to the mobile access device along with the encrypted data. The mobile access device may use its private key to decrypt the UE ID and use it to derive and / or determine the UE- specific key, e.g., K' or SSGK. The mobile access device may then use the UE-specific key to verily and authenticate the UE transmissions using store and forward mode. This embodiment may prevent the exposure of the UE ID in the clear and may protect it from eavesdropping or spoofing attacks. This embodiment may also avoid the need for the mobile access device to have the private key of the home network or to store a group key for multiple UEs. This embodiment may increase the security and privacy of the NTN access for the UEs.

[0235] In an embodiment related to above scenario that may be combined with other embodiments or used independently, the first authentication and authorization procedure between UE and the mobile access device is adapted to derive / compute / obtain an authentication tag using some long-term credentials, e.g., a key, shared between UE and core network (e.g., a database function such as the UDM). If the first authentication and authorization procedure succeeds, this authentication tag is transferred to the store and forward center, and then to the core network (e.g., during the second authentication and authorization procedure, or independently) that can verily the authenticity of the UE based on the tag. For instance, this tag may be computed as a cryptographic function of the current UTC time and the long term secret stored in the UE / USIM, e.g., as a cryptographic function of the long term secrert and the UTC time, e.g., as HMAC(long_term_secret, UTC time). For instance, the mobile access device may be configured (e.g., by the core network) with a seed that it may use to derive a random value, e.g., as RAND = KDF(seed, UTC time). This RAND value may be sent to the UE during the first authentication and authorization, e.g., when the mobile access device indicates its identity to the UE (so that the UE can derive K’). The UE may then compute an authentication tag as a cryptographic function of RAND and its long term secret, e.g., the authentication tag may be AT = HMAC(long_term_secret, RAND). The mobile access device - upon a successful first authentication and authorization) may transfer mobile access device ID, UTC time, RAND, AT to the store and forward center, that may then send it to the core network. The core network may verify that both the mobile access device and UE were involved in the interaction since only the mobile access device knows seed, and thus, can generate RAND and only UE knows long term secret, and thus, can generate AT given RAND. This embodiment may allow the core network to verily that UE and mobile access device were involved / performed the first authentication and authorization procedure.

[0236] In an alternative scenario, mutual authentication(s) between the UE and the Network (e.g., HPLMN) and / or between the UE and the NTN Access Device (e.g., eNB / gNB) may be inversed, such that it may be the UE which initiates the authentication procedure by generating an Authentication Vector(AV) comprising SQN, RAND, an Authentication tag / token (AT), IMSI / SUCI, IK and CK. The UE may further precompute the authentication result / response RES*. The UE may, upon successfully establishing an RRC connection with the access device (e.g., eNB / gNB) on-board of the satellite, send an authentication request containing the AV comprising SQN, RAND, AT, IMSI / SUCI and HRES* (e.g., computed based on the pre-computed RES*). Upon receiving the AV, the access device may retrieve and store HRES* and forward the AV, without HRES* to the CN or a function therein (e.g., AUSF / UDM / ARPF), which upon reception of the AV retrieves IMSI (e.g., by de-concealing SUCI), then retrieves the long term key associated with UE, derives IK, CK and verifies the AV. Upon successful verification, an authentication response e.g., XRES* is computed, then forwarded to the access device; this latter may compute HXRES* based on XRES* and verify it against the stored HRES*, if successful, the access device may forward the Authentication response (XRES*) to the UE, which upon receipt verifies it against RES*, and if successful, the authentication procedure is deemed successful. The inversed authentication procedure still requires the CN to perform the initial check of the AV, and only afterwards can the access device (e.g., MME / AMF component on-board) perform the verification, thus if CN components which perform the AV verification and compute the authentication response are not on-board and / or the subscriber’s long term keys is not available on the database function (e.g., UDR / UDM) on-board of the satellite, the authentication procedure may remain on hold until a feeder link is available. It is thus the object of the following embodiments to address this gap.

[0237] In an embodiment that may be combined with other embodiments or used independently, the authentication procedure may use an inversed authentication procedure, as described above, and the use of security materials derived from UE’s long term key and an identifier of the access device (e.g., Sat ID), such that the AV (including CK,IK) and the computed RES* are based on K’=KDF(K, Sat id), as described in the previous embodiments. The AV may further include Sat id, which may either be included by UE or by the access device prior to forwarding the AV to the CN components, and the precomputed RES*. As RES* may be computed based on K’ e.g., RES*= KDF(K’, RAND, SNN), It may be verified by the access device prior to forwarding the AV to the CN, thus mitigating potential DoS attacks against the access device. In another embodiment that may be combined with other embodiments or used independently, both the long term key (K) and K’ may be used during the authentication procedure, in such a way that enables the access device to provisionally authenticate the UE and mitigate DoS attacks, prior to CN authenticating the UE. For instance, the Authentication Tag may be computed as AT = HMAC(K’, RAND) and is checked by the access device upon receiving the AV, which may also contain the precomputed RES*. Upon successful verification of AT, the access device may compute HRES* based on RES* then forwards the AV to the CN. RES* may be based on UE’s long term key (K), and thus, the CN also computes XRES* based on K then verifies it against the received RES*. Upon successful verification, the UE is considered successfully authenticated from the CN’s point of view. HXRES* is then computed and sent to the access device, which verifies whether it matches HRES* computed earlier, upon successful verification, the UE is considered authenticated from the AD’s point of view. In an option, K’ - or a key derived from it - may also be used to protect data to be stored - temporary - in the mobile access device. This storage may be done upon successful verification of AT and may be released when the mobile access device can connect to the ground station. The data may only be accepted by the CN if the verification of XRES* (based on K) against RES* succeeds.

[0238] In another embodiment that may be combined with the previous embodiment or used independently, the UE may establish the AS security context with the access device e.g., based on K’ or a key derived from it, prior to the establishment of NAS security context with the MME / AMF, which may depend on security materials derived from the long term key K. The AS security context based on K’ may be a temporary one, until K gNB is derived and provided to the access device, following the current key hierarchy, as described in clause 6.2 of TS 33.501 (vl8.5.0). This AS security context may be used to transfer data securely, e.g., from the UE to the mobile access device in store and forward mode, for temporal storage, and implicitly verily that both parties are authenticated. Note that the security context may be derived, e.g., from a NAS key, e.g., NAS integrity key.

[0239] In a related scenario to the previous embodiment, the UE may establish the AS security context. This AS security context is used as authentication / authorization codes for the uplink / downlink RRC exchange prior to the exchange of a NAS PDU. For instance, the mobile access device may compute NAS-MAC by taking as input K NAS integrity key, the uplink / downlink NAS COUNT, RAN node ID. Then the NAS-MAC may be divided into two authentication / authorization tokens, the first 16 bits of NAS-MAC form UE Auth code (send in the uplink RRC Connection setup) and the last 16 bits form RAN Auth code (sent in the downlink RRC Connection setup). When the mobile access device is available, the UE may send an RRC Connection setup request including its UE Id, then the mobile access device may reply with the RRC Connection setup response including RAN Auth code and the UE may then reply with RRC Connection setup complete including UE Auth Code. If received, the mobile access device may send Downlink RRC message including the NAS PDU. However, this scenario is prone to attack because an attacker can send multiple RRC Connection Setup requests with different UE Id, and the attacker will get many RAN Auth Code. The attacker may then reply them to obtain from UEs the UE Auth Code. This attacker may be a MitM. With this information the attacker can then impersonate the UE. Thus, in an embodiment that may be combined with other embodiments or used independently, the computation of NAS-MAC also includes a value (e.g., NONCE) that is different in every exchange, e.g., the RRC Connection setup request including the UE Id may also include a NONCE, and the NONCE may be used to compute the NAS-MAC. Additionally or alternatively, the downlink RRC Connection setup including RAN Auth code may include a second value (e.g., NONCE’) that may be used in the computation of another NAS-MAC, e.g., as above by also taking as input NONCE and / or NONCE’, from which UE Auth Code can be derived.

[0240] In another embodiment, that may be combined with other embodiments or used independently, aimed at addressing the privacy issue associated with communicating UE identifiers (i.e., IMSI) in cleartext when the base station on-board the satellite is an eNB, the security key K’ may be used to protect (e.g., confidentiality and integrity protect) the UE identifier between UE and the access device. Additionally, or alternatively, access devices may be provisioned with a function of the IMSI (e.g., Masked IMSI (MIMSI)), linking it to the access device (e.g., satellite) when being provisioned with K’, e.g., MIMSI = F(IMSI, Sat_ID) or MIMSI = F(IMSI, Salt, Sat_ID). To further randomize MIMSI and mitigate UE tracking, UE may compute R MIMSI = F(MIMSI, RP), where F may be a cryptographic function such as a one-way function (e.g., SHA256) and RP (Randomization parameters) may comprise a UTC-based counter and / or UE rough location, and / or satellite rough location (e.g., based on ephemeris data), RAND, etc. Another option may be to compute R MIMSI directly as R MIMSI = F(IMSI, Sat ID, RP). When UE attempts access through a given satellite, UE may include R MISMI, in addition to RPs, which the access device may be lacking. In addition, K’_ID or MIMSI identifier (e.g., the K ID MSBs / LSBs) may be exchanged, which may regularly be updated after use. R MIMSI is subsequently checked by the access device based on MIMSI, associated / indexed / identified by, e.g., K’_ID and / or MIMSI identifier and / or Sat id. This has the advantage of allowing the access device to verify whether UE is authorized for access through satellite, as the satellite may only be provisioned with K’, MIMSI associated with UEs authorized to make use of NTNs, in addition to preserving UE identity privacy.

[0241] In an embodiment that may be combined with other embodiments or used independently, a first satellite (in general mobile access device) may not have the credentials (e.g., key K’ or a one time-pad) to communicate / authenticate / authorize a UE. The first satellite may indicate, when it is able to connect again, to a target entity, e.g., a store and forward center or a network function in a core network, the identity of the satellite. The target entity may then configure the first satellite or a second satellite (in general, a second mobile access device) with those credentials where the second satellite is expected / planned to be over the area of the UE within a short period of time, e.g., based on ephemeris data of the satellite. In the case that a second satellite is configured, the second satellite may be configured to actively page the UE (e.g., sending a paging message) indicating that a connection / authentication / authorization procedure is now feasible. This embodiment may allow the UE to access the NTN network via a satellite that has the appropriate credentials, even if the first satellite that encountered the UE did not have them. This embodiment may also reduce the delay and overhead of the NTN communication, as the UE does not need to wait for the first satellite to return or to relay the data through another satellite. This embodiment may improve the user experience and the efficiency of the NTN network.

[0242] In an embodiment that may be combined with other embodiments or used independently, a first mobile access device working in store and forward mode may send the estimated location of the UE (that tried to connect to it but whose connection failed due to the lack of credentials) to the target entity along with the other information, such as the UE identity, mobile access device ID, UTC time, movement direction / speed of the UE, etc. The target entity may use this location information to select a second mobile access device that is expected to be over the area of the UE within a short period of time and configure it with the credentials to communicate / authenticate / authorize the UE as well as with the expected location of the UE. The second mobile access device may then transmit a paging message to the specific area where the UE is located or expected to be located, indicating that a connection / authentication / authorization procedure is feasible. This embodiment may improve the accuracy and efficiency of the paging process, as the second mobile access device may focus its transmission on the relevant area and reduce the interference and power consumption for other areas. This embodiment may also reduce the delay and overhead of the NTN communication, as the UE does not need to wait for the first mobile access device to return or to relay the data through another mobile access device. This embodiment may improve the user experience and the efficiency of the NTN network.

[0243] In an embodiment that may be combined with other embodiments or used independently, a store and forward center that receives and buffers data from the mobile access devices working in store and forward mode may be configured with a policy to manage the mobile originated and mobile terminated traffic for the UEs. The policy may be provided by the PCF or another network entity and may specify how to handle the data based on various criteria, such as the priority, latency, size, type, or destination of the data. The policy may also indicate how long to store the data before discarding it or sending it to another entity. The store and forward center may apply the policy to the buffered data and decide whether to forward it to the core network or another mobile access device, store it until a suitable opportunity arises, or delete it if it is obsolete or irrelevant. This embodiment may improve the efficiency and reliability of the NTN communication, as the store and forward center may optimize the use of its resources and avoid congestion or duplication of data.

[0244] In an embodiment that may be combined with other embodiments or used independently, the store and forward center may act as a lawful interception enforcement point as per other embodiments, as it has access to both the credentials of the UEs and the mobile access devices. The store and forward center may decrypt the data using the private keys and inspect it for any illegal or suspicious activities. The store and forward center may also encrypt the data using the public keys and send it to the authorized entities, such as law enforcement agencies or courts. This embodiment may enhance the security and compliance of the NTN network, as the store and forward center may monitor and prevent any malicious or unlawful actions.

[0245] In an embodiment that may be combined with other embodiments or used independently, the store and forward center may also be responsible for managing the credentials of the UEs and the mobile access devices, as it may have access to their authentication and authorization information. The store and forward center may issue or verily credentials, such as authorization tokens, one-time passwords, policies, etc., as used in other embodiments, to enable or restrict the access to the NTN network or certain services or applications. The store and forward center may also update or revoke the credentials based on the changes in the status or preferences of the UEs or the mobile access devices. This embodiment may improve the flexibility and security of the NTN network, as the store and forward center may dynamically adapt to the needs and requests of the UEs and the mobile access devices.

[0246] In an embodiment that may be combined with other embodiments or used independently, a UE working in store and forward mode may determine how to authenticate to the core network depending on whether the request is sent to the core network through an access device without store and forward capabilities (e.g.., a terrestrial access device or a mobile access device not working on store and forward mode) or with store and forward capabilities. For example, the UE may receive a message, such as a system information block (SIB), such as SIB1, from the access device indicating its store and forward operation mode, and thus, this may imply, explicitly or implicitly specific authentication and authorization requirements for store and forward mode. The message may contain a field or a parameter specifying whether the UE needs to perform a normal authentication and key agreement (AKA) procedure with the core network, or a modified AKA procedure adapted for store and forward mode, or no AKA procedure at all, or send an authorization token. The UE may then select the appropriate authentication method based on the message and the type of access device. This embodiment is advantageous because it allows the UE to securely access the core network using store and forward mode. It may also allow the UE to optimize the authentication process according to the capabilities and limitations of the access device.

[0247] Section: NTN - Store and forward policies related to data storage

[0248] In an embodiment that may be combined with other embodiments or used independently, a mobile access device working in store and forward mode may be configured with a policy indicating whether it may work in this mode or not. The policy may be provided by the core network or determined locally by the access device based on various factors, such as the availability of resources, the demand from UEs, or the network conditions. The access device may indicate its policy to the UEs via a message, such as a radio resource control (RRC) message. For example, the access device may broadcast a system information block (SIB), such as SIB1, containing a flag or a parameter indicating whether it supports store and forward mode or not. Furthermore, the policy may indicate how much data the access device may store for each UE or for all UEs collectively. The access device may also indicate this information in the message, such as a SIB or another RRC message. This embodiment is advantageous because it informs the UEs about the availability and capability of the access device for store and forward mode. It may allow the UEs to adjust their data transmission accordingly, such as by compressing, prioritizing, or splitting their data to comply with the policy of the access device.

[0249] In an embodiment that may be combined with other embodiments or used independently, a mobile access device working in store and forward mode may indicate to the UE a policy for storage, e.g., how long the data may be stored (e.g., till it is expected to be forwarded) and under which circumstances it may delete data (e.g., if it receives many emergency messages) and how likely it is to be deleted (e.g., if the satellite is exposed to a high load, it may be more likely that the data may not be stored). The access device may indicate the policy to the UE via a message, such as a radio resource control (RRC) message. For example, the access device may broadcast a system information block (SIB), such as SIB1, containing a field or a parameter indicating the storage duration, the deletion criteria, and the deletion probability for the data transmitted by the UEs. Furthermore, the policy may be dynamically updated by the access device based on the network conditions, the resource availability, or the priority of the data. The access device may notify the UEs about the policy changes via another RRC message, such as a paging message or a notification message. This embodiment is advantageous because it informs the UEs about the storage policy of the access device for store and forward mode. It may allow the UEs to adjust their data transmission accordingly, such as by choosing a different access device, encrypting, prioritizing, or splitting their data to comply with the policy of the access device. It may also allow the UEs to set up a timer for the retransmission, e.g., if no answer was received before a time dependent on the time until the forwarding, the UE may decide to re-transmit the data.

[0250] In an embodiment that may be combined with other embodiments or used independently, a policy for store and forward mode may be configured by an entity managing the mobile access device or a network function in the core network. For example, a store and forward center (SFC) may be responsible for deploying and operating the mobile access devices, such as satellites, balloons, or drones. The SFC may define the policy for storage, forwarding, deletion, and prioritization of the data transmitted by UEs using store and forward mode. The policy may depend on various factors, such as the resource availability, the network conditions, the security requirements, or the service level agreements. The SFC may communicate the policy to the mobile access devices via NTN links or other suitable means. Alternatively, a network function (NF) in the core network, such as the policy control function (PCF) or the session management function (SMF), may define the policy for store and forward mode. The NF may communicate the policy to the mobile access devices via NTN links or other suitable means. The NF may also communicate the policy to the UEs via terrestrial links or other suitable means. The policy may be consistent with the subscription profile and the quality of service parameters of UEs. This embodiment is advantageous because it allows the configuration and update of the policy for store and forward mode according to the needs and preferences of the network operator or the service provider. It may also allow the coordination and synchronization of the policy among different mobile access devices and UEs.

[0251] In a general definition, it is disclosed an apparatus for authenticating, authorizing, and managing a connection wherein the apparatus is configured to: check or select a preferred authentication procedure; perform the preferred authentication procedure with a first core network through a first access device; and setup a communication connection with the first core network.

[0252] Furthermore, the apparatus is configured to: receive, prior to the check or selection of the preferred authentication procedure, a command from the first core network through a first access device to establish a connection over a specified access device using a set of configuration parameters for the connection; if not connected, connect to the specified access device; and start the connection for one or more services over the specified access device. Furthermore, the configuration parameters include one or more of: access information, in particular timing or location or physical cell identity, of the specified access device, in particular to perform a random access procedure; operation mode of the access device including regenerative, transparent or mixed regenerative / transparent operation mode as well as store and forward mode; storage time of the specified access device when working in store and forward mode; keying materials such as a key to connect to the specified access device and / or to communicate with a first user equipment through the specified access device;

[0253] IP addresses for the different communication paths; congestion state for different paths and / or for communication segments in the different paths; congestion window for different paths and / or for communication segments in the different paths; round trip time for different paths and / or for communication segments in the different paths; method to determine round trip time; method to schedule packets; and services to which the connection are applicable.

[0254] Above apparatus may further comprise one or more of the following aspects:

[0255] Aspect 1 : the apparatus is configmed for the reception of a command prior to the check or selection of the preferred authentication procedure wherein the command may be an RRC message / SIB1 including an indication wherein the indication indicates that the first access device operating in store and forward mode.

[0256] Aspect lb: the apparatus is adapted to perform the check or selection of the preferred authentication procedure based on the indication received in the RRC message / SIB1.

[0257] Aspect 2: the configuration parameters comprise keying materials wherein the keying materials may be one or more of: an authorization token, a one-time pad, a key to perform a primary authentication procedure with the first access device, wherein the first access device contains the core network functionalities, a group key to perform an authentication procedure with the first access device, wherein the first access device contains the core network functionalities, credentials authenticating and authorizing the apparatus to transfer of data when the first access device is working in store and forward mode, a policy determining the context under which the apparatus may transfer data or perform a primary authentication procedure when the first access device is operating in store and forward mode.

[0258] Aspect 3: the keying materials configured in the apparatus may be configured by means of a NAS message, a UPU message, an UCU message, or a SOR message.

[0259] Aspect 4: the apparatus is configured with a policy determining how long it needs to wait till it is requested to retransmit data or perform again a primary authentication procedure based on a time indication provided by the first device wherein the time indication indicates how long the first access device operates in store and forward mode.

[0260] Aspect 5: the apparatus is configured to receive a paging message from the first access device or a second access device indicating that the first access device and / or the second access device are configured with credentials (e.g., keys) to perform the primary authentication with the apparatus or receive data from the apparatus.

[0261] Aspect 6: the apparatus is configured, prior to the check or selection of the preferred authentication procedure, with a public key and / or may receive a public key, when performing the preferred authentication procedure, from the first access device wherein the apparatus uses the public key to protect its identity, e.g., IMSI or SUPI, so that only the first access device can decrypt it, wherein the public key may be linked to a private key that may be specific for the first access device.

[0262] Aspect 7: the apparatus is adapted to perform an authentication procedure with the first access device, the apparatus receiving a first value (RAND) from the first access device, and the apparatus computing an authentication tag based on the first value and a long-term secret shared with its home network.

[0263] Aspect 8: the apparatus is configured to provide its location to or allow for its positioning with the first access device during or after a first failed primary authentication with the first access device.

[0264] Aspect 9: the apparatus is configured to send a message to the first access device wherein the message includes an authorization token that may be used during the preferred authentication procedure, wherein the authorization token serves as proof of its authorization to send the message when the first access device is operating in store and forward mode wherein the message may be a message used to initiate or perform the preferred authentication procedure (e.g., a primary authentication) and / or transmit data.

[0265] Aspect 10: the apparatus is configured to: receive short-term credentials through the first access device after setting up a communication connection with the first core network and performing the preferred authentication procedure with the first core network through the first access device, wherein the short-term credentials are for a second preferred authentication and authorization procedure with a second access device, perform the second preferred authentication and authorization procedure with the second access device by using the short-term credentials, and exchange (send or receive) data with and / or through the second access device.

[0266] Aspect 11: the apparatus of Aspect 10 wherein the short-term credentials are valid a short-term time window and the short-term credentials may comprise at least one of:

[0267] A short-term public / private key pair and a short-term certificate, a set of keys or passwords to be used with a second access device.

[0268] Aspect 12: the apparatus of Aspects 10 and 11 wherein second preferred authentication and authorization procedure is performed by using the short-term credentials (private key or key or password) to compute an authentication tag taking as input at least one of the UTC time, a counter, a nonce, and the exchanged data, and including the authentication tag to the exchanged data with / or the second access device.

[0269] Aspect 13 : the apparatus adapted to transmit an emergency indication and / or emergency credentials and / or remaining energy and / or remaining lifetime prior to performing the preferred authentication procedure with a first core network through a first access device. Aspect 14: the apparatus of aspect 13 adapted to perform the preferred authentication procedure upon transmission of an emergency indication if the remaining energy and / or lifetime is greater than a threshold.

[0270] Aspect 15: the apparatus of aspect 13 and 14 adapted to access null-security if it sent an emergency indication and / or the remaining energy and / or lifetime is greater than a threshold.

[0271] Section: IOPS, multiple architectures

[0272] In Release 19, UE communication over NTNs will be supported for 4G considering that either part of or the whole core network is in the satellite (in general, mobile access device). An architecture wherein the whole core network is in the satellite may be based on the Isolated E-UTRAN Operation for Public Safety (IOPS) as per Annex F in TS 33.401. An architecture wherein part of the CN is in the satellite may be based, e.g., on Sol #11 in TR 23.700-29 and above embodiments.

[0273] The satellite may broadcast its status, e.g., as store and forward, e.g., via a SIB. However, which of the procedures is to be used for authentication may depend on the connectivity of the satellite, e.g., whether there is a communication link to a ground station or not. From this point of view, in an embodiment that may be combined with other embodiments or used independently, a UE and / or satellite may prefer (based on a configuration and / or policy that may be configured in the UE and / or satellite by the core network) the usage of a given solution or architecture. For instance, if connectivity is available, a UE and / or satellite may prefer an architecture / authentication procedure based on an architecture in which only part of the CN is in the satellite because it allows running an authentication procedure end- to-end with a data function such as 4G HSS or 5G UDM on the ground. However, when the satellite is in store and forward mode and / or connectivity to the ground station is not feasible and / or when the satellite lacks sufficient connectivity, the authentication procedure may need to rely on the core network local to the satellite. Based on the broadcast status of the satellite, the UE may determine how it wishes to connect and may select the authentication protocol and the corresponding parameters and transmit those parameters, e.g., it may select an IMSI (in general, device identifier) for the authentication when the whole or part of the CN is in the satellite. In some cases, the UE may transmit in an initial registration message (e.g., attach request) both device identifiers (e.g., IMSI to perform authentication when the whole CN is in the satellite and IMSI to perform authentication when part of the CN is in the satellite) so that the satellite can determine how to offer connectivity to the UE and perform the further authentication. For instance, if the satellite loses connectivity to the ground station, the satellite may communicate further using the device identifier and credentials associated to an architecture wherein the whole CN is in the satellite, e.g., based on an IOPS solution as per TS 33.401. Transmitting both identifiers may be advantageous because it allows a satellite to select the most suitable authentication protocol / approach to provide connectivity to the UE. Once the satellite has performed the selection, the satellite may indicate the selected method to the UE, e.g., in a subsequent message such as an authentication request that may indicate (implicitly or explicitly) the authentication method. Additionally or alternatively, the UE may try both authentication methods / credentials to determine the authentication / connectivity method selected by the mobile access device.

[0274] In TS 33.401 Annex F 4.2, it is described a key derivation mechanism for ‘subscriber key separation’ wherein the USIM of a UE needs to be updated in case that the data function (e.g., HSS) in a mobile access device with the whole core network is compromised because in that case the satellite key K_n, derived from a master key MK by means of the key derivation function described in A.17 of TS 33.401, is also compromised, and thus, that key needs to be updated, where n draws on the proprietary part of the Authentication Management Field (AMF), cf. Annex H of TS 33.102 and / or the IND part of the sequence number SQN, as described in Annex C.l of TS 33.102. When K_n is compromised, K_n can be updated keeping track of an “m value” that indicates the version of K_n (as described in TS 33.401 F 4.2). This is done by means of a function f realized as a table in the IOPS dedicated USIM. For instance, f(n) = n | m (where | indicates concatenation). Initially m is 0, but if K_n is compromised, m is incremented by 1 (i.e., m’=m+l), thus indicating that a different K_n is required, and the new K_n is thus derived using f(n) = n | m’. From this point of view, m (and subsequently m’) refers to the version of key K_n of a satellite (and / or contained in the HSS in the satellite). 3GPP Tdoc S3 -243318 proposes a way of informing the USIM about the current m value associated with n in K_n, namely exchange a hint of m in the 3 least significant bits of the SQN value exchanged between ME and USIM. However, using an m value of only 3 bits limits the number of keys that can be used, and this is an important drawback. Furthermore, if the m value is longer (e.g., 8 bits as per TS 33.401) and only 3 bits are included in the SQN value as per 3GPP Tdoc S3-243318, an attacker may still desynchronize the system, e.g., the attacker may have compromised a satellite using K_n corresponding to m value = 7, and then a(n updated) satellite may transmit an SQN in whose 3 LSBs the 3 LSBs of the subsequent m value = 8 are included. But these 3 LSBs are 000, so a UE may consider that those 3 LSBs correspond to K_n with m = 0 (that is also not in use anymore).

[0275] To address these drawbacks, in an embodiment that may be combined with other embodiments or used independently, when a UE is authenticated by means of an authentication method / architecture in which only part of the CN is in the satellite and the authentication is performed with a data function (e.g., HSS / UDM) that is in the ground or the whole CN is on the ground, the authentication parameters (for UE (including USIM) and satellite) for the authentication method / architecture in which the whole CN is in the satellite are (required to be) updated. In particular, the m values for the IOPS based solutions are to be updated, in particular, for satellites that are expected to offer connectivity to the UE in the subsequent time period. This is advantageous, in particular, in cases where a mobile / satellite network operators supports (e.g., has deployed) both split MME and full core network (e.g., IOPS based full CN) based NTN architectures and / or NTN and TN based network access.

[0276] In a further embodiment that may be combined with other embodiments or used independently, the m field may be included in the Authentication Request message, e.g., as part of the AUTN field, so that the UE can send this information to the USIM / UICC, and the USIM / UICC can then determine f(n) and from it the value K_n.

[0277] In a further embodiment that may be combined with other embodiments or used independently, the m field may be a decreasing field value.

[0278] In a further embodiment that may be combined with other embodiments or used independently, if the number of data functions (e.g., HSSs) and / or satellites is greater than 256 (i.e., max n), then a group / subclass of HSS / satellites share the same K_n, as described in Annex F.5 of TS 33.401. In this case, if one of the HSS / satellites in the group is compromised, the key K_n or data protected with K_n of the compromised HSS (i.e., NTN payload protected with K_n or a key derived from it) and the remaining ones (i.e., other HSSs in the subclass / group) needs to be updated, e.g., by providing a new m value and subscriber key K_n to said NTN payloads (i.e., the compromised one and HSSs in the same group / subclass) by HPLMN on the ground. The satellites (i.e., HSSs on-board) are also instructed to use a hint (e.g., an indication, e.g., as in other embodiments) indicating the usage of a new m associated to the n value identifying the satellite / HSS or group / subclass of HSSs.

[0279] According to TS 33.401, the number of HSSs / satellites is limited to 256 (the size of n), if there are more HSS / satellites, they need to be grouped. This is a drawback because credentials (e.g., K n,) on the satellites in a group (i.e., HSS group / subclass identified by n,) need to be updated when one of them is compromised. Instead, in a further embodiment that may be combined with other embodiments or used independently, each satellite / HSS may be assigned to a combination of n and m parameters. The UE / USIM may then include a table indicating whether the combination n | m (i.e., f(n)) indicates a version of the n value allowing for the update of K_n as per TS 33.401, or a unique combination of n and m values linked to a specific satellite / HSS. In this second case, if that satellite / HSS is compromised, the table contained in the UE / USIM also includes an entry indicating whether said combination of n and m values is valid / active or disabled. A UE / USIM may add a new entry for a combination of n and m if a message is received (e.g., an authentication request) for a new n / m combination and said combination is such that the UE can verify the message correctly (e.g., MAC check is successful). This is advantageous because a new satellite / HSS may be deployed and start communicating without requiring an active configuration of the UEs. Additionally or alternatively, only valid / active combinations of n and m values are kept in the table stored in a UE / USIM. This is advantageous because only explicitly configured satellites / HSSs can be used for communication. This embodiment describes how a UICC may store a table as table 2 instead of table 1. Also a combination of both tables may be feasible, e.g., when some n values are allocated to multiple m values.

[0280] Table 1

[0281] Table 2

[0282] In an lOPS-based NTN communication scenario, a UE is required to perform primary authentication every time a new lOPS-based NTN payload serves the UE. This entails that each new lOPS-based NTN payload needs to generate a corresponding Authentication Vector (AV), which uses a fresh and valid SQN. According to TS 33.102, Annex C.2.1, (2), to prevent SEQMS (i.e., the highest sequence number, corresponding to index IND, in the array stored in the USIM) from reaching the maximum batch number value SEQMAX during the lifetime of the USIM, the minimum number of steps SEQMAX / A required to reach SEQMAX, where A is the maximum difference between SEQMS and a fresh SEQ, shall be sufficiently large. Thus, in an embodiment that may be combined with other embodiments or used independently, the minimum number of steps IUMAX / A’ required to reach the maximum value of m, where A’ is the maximum value by which m is increased shall also be sufficiently large. Additionally, or alternatively, if m reaches its maximum value IHMAX, the satellite (or group / subclass of satellites) identified by n or a combination of the n and m values (e.g., n | m), for which m has reached DIMAX, may be assigned a new identifier n’, or a combination of n’ and m values (e.g., n’ | m). Additionally, or alternatively, the step by which m is increased / decreased may be chosen in such a way that allows a more efficient use of the size of m; for instance, if the initial value of m = 0, the choice for the step Ancby which m is increased may be in such a way that m’= m + Amc, is always an odd number, such that upon reaching IHMAX, the network / USIM are configured to reverse the process (i.e., starting from the highest m value <= mMAx), by choosing a step Aiec in such a way that m’=m-Adec, is always an even number, until the minimum non used value of m (i.e., niMiN=2) is used, upon which, a new value n, may be allocated to a satellite (or group / subclass of satellites). Additionally or alternatively, a UE may keep track of when m is about to wrap around (e.g., reaches mMAx) using a local counter, which may be included in f(n), in which case, only the LSBs of m need to be exchanged, while the UE / UICC keep track of the MSBs of m. Additionally or alternatively, the lOPS-based UICC / USIM may be provisioned with multiple root keys (e.g., Master Keys), such that when a satellite (or group / subclass of satellites) sharing an identifier n, whose m value is nearing HIMAX, the HPLMN on the ground may select a second root key (i.e., Master Key) to be used to derive subsequent subscriber keys (e.g., K_n), with m being reset to 0; the HPLMN may then provision lOPS-based NTN payloads / access devices with the new subscriber key, reset m value, and an identifier of the MK used. The lOPS-based NTN payload / access device, may, upon generating a fresh AV using the new subscriber key, indicate to the UE that a new root key is being used to derive the subscriber key, by including the root key identifier received from the ground HPLMN. This approach has the advantage of re-allocating both n and m values and ensuring subscriber keys are not re-used.

[0283] In an lOPS-based communication scenario, and according to TS 33.401, Annex F.5, Note 2, when a UE moves from one local HSS to another, it could happen that the second local HSS generates an authentication vector (AV) with a sequence number that is too low as seen from the USIM. This results in a re-synchronization procedure wherein the second local HSS updates its sequence number and generates an AV that will be accepted by the USIM. It is described that if the delay (i.e., due to resynchronization) is a concern, or if re-synchronization may be frequent due to frequent movement of UEs between local HSSs, then the problem could be almost completely solved by using the IND value of the sequence number to distinguish among local HSSs (i.e., set up the local HSSs such that they use only particular IND). In an lOPS-based NTN communication scenario, the delay is indeed a concern, given the limited time window which an NTN payload has to serve a UE, and the frequency of resynchronization is high, due to the movement of the lOPS-based NTN payloads, hence the burden of continuously dealing with the re-synchronization issue. Furthermore, the problem could not be solved by using the IND value to distinguish between the lOPS-based NTN payloads, since IND is limited to 5 bits, whereas the number of satellite identifiers (i.e., n) is an 8-bits value, i.e., the number of satellites may exceed, potentially by far, the number of SQNs. It is thus the object of the following embodiments to address the issue described. Thus, in an embodiment, that may be combined with other embodiments, or used independently, the IOPS USIM may be configured with an SQN array that is sufficiently large to serve the n=256 satellites (and / or groups / subclasses of satellites), where IND is also an 8-bits value, associated to and / or used by the satellite (or group / subclass of satellites) identified by n, to identify the SQN to be used. Additionally, or alternatively, the identifier n extracted from the AMF bits (as described in TS 33.401, Annex F.4.1) may serve the purpose of IND, i.e., n is itself the index identifying the SQN associated to the satellite (or group / subclass of satellites) identified by n, in which case IND may instead serve to identify a specific satellite within the group / subclass of satellites sharing the identifier n. The two options described require increasing the size of the SQN array into at least the maximum number of satellite identifiers n (i.e., 256), although, it does not solve the potential issue of re-synchronization between satellites belonging to the same group / subclass sharing the identifier n. In an additional or alternative option, where the number of lOPS-based NTN payloads exceeds the maximum number of identifiers n=256, n may be combined with IND (e.g., n | IND), to increase the capacity of identifiers, thus avoiding grouping them into subclasses, and allowing the identification of SQN using the combination of n and IND values. This has the advantage of solving the potential synchronization issue.

[0284] In another embodiment that may be combined with other embodiments or used independently, in case several satellites belong to the same group / subclass of satellites sharing an identifier (e.g., n), another option to lower the likelihood of SQN re-synchronization issue occurring could be implementation / deployment dependent; for instance, satellites belonging to the same group / subclass may be put in orbit in such a way that these satellites are not adjacent; that is, in between passes of each two satellites belonging to the same group / subclass, other satellites (e.g., at least one or more satellites) using different identifiers (e.g., n) and different sequence numbers (SQN) are in the same orbit, and could serve the UE. This has the advantage of allowing a first lOPS-based NTN payload who has used a fresh SQN / m value, to communicate said value to the ground HPLMN, thus allowing the latter to update the second lOPS-based NTN payload belonging to the same group with a fresh SQN / m value to be used. Additionally, or alternatively, the lOPS-based NTN payloads belonging to the same group / subclass of satellites, may use an intersatellite-link to transmit / receive updates associated with SQNs that have been used and require refreshing, thus circumventing the re-synchronization issue. The distribution of satellites arranged according to this embodiment may be observable by monitoring the n values assigned to the satellites. The PLMN or 0AM or entity managing the satellites may run an algorithm minimizing the time satellites in the same group are moving close (by).

[0285] In a scenario, where the value m is transmitted to the UE as part of the SQN (e.g., as described in S3 -243694), where a valid SQN is always greater than the last SQN used during an authentication procedure, and as a result m is also always greater, hence the auto-updating of m and K_n, such that old keys (i.e., old K_n) are deprecated after the successful reception of an AV with a larger SQN / m value. However, in this scenario, it is required that an lOPS-based NTN payload is required to inform HPLMN of whether the new SQN / m has been / is going to be used (i.e., an authentication vector using said SQN / m has been sent to the UE), regardless of whether the primary authentication was (or was not) successful and / or concluded. Hence, in an embodiment that may be combined with other embodiments or used independently, an lOPS-based NTN payload informs HPLMN upon having a feeder link available, of the use of an SQN / m value in an authentication vector, such that the HPLMN on the ground generates a fresh SQN / m value and subscriber key K_n associated with it, which are then provisioned to the lOPS-based NTN payload (and other lOPS-based NTN payloads in the same group / subclass sharing the identifier n). This has the advantage of promptly mitigating the risks associated with a compromised lOPS-based NTN payload (e.g., HSS),.

[0286] In another embodiment that may be combined with other embodiments or used independently, upon the usage of a fresh SQN / m in an authentication vector by an lOPS-based NTN payload / access device, regardless of whether the primary authentication with the UE was (or was not) successful, the lOPS-based NTN payload / access device may have to provide proof to the ground HPLMN that the SQN / m has been used. The proof may be computed by the UE using a cryptographic function (e.g., a KDF) using as key MK, and taking as parameters the lOPS-based NTN payload / access device (e.g., HSS) identifier n (or a combination of n and IND), the SQN / m value, and one, or more, or a combination of the following parameters: a time value (e.g., timestamp or a UTC-based counter), RAND value associated with the AV, location information, etc; the output of which is included in the authentication response (e.g., in a new field in the authentication response). Additionally or alternatively, the used SQN may be used in the computation of an authentication result to be forwarded to the ground HPLMN; for instance, the UE may compute an additional authentication result using RES =f2(K_n, RAND) to be verified by the lOPS-based NTN payload, and compute RES’ = KDF(MK, RES || SAT ID || SQN), where SAT ID may be the identifier n (or a combination of n and IND).

[0287] In another embodiment that may be combined with other embodiment or used independently, where the use of a fresh SQN / m value does not always entail the derivation / use of a new subscriber key K_n, upon receiving the fresh / updated m value, e.g., whose least significant bits or the least significant bits of a counter value are the only ones received in clear, a UE needs to verify whether the received LSBs corresponding to a fresh m value associated with the identifier n (e.g., extracted from AMF) are (or aren’t) used to derive a new subscriber key (K_n), as such, the UE uses the guessed m value (e.g., based on the clear part of the m received) to generate a new subscriber K_n, which is used to compute a first MAC, while the last used K_n is used to generate a second MAC; the two MACs are then compared against the MAC value received as part of the AUTN in the Authentication Vector to determine whether the subscriber key (K_n) is to be updated at the UE. This has the advantage of implicitly communicating to the UE that the subscriber key (K_n) is to be updated.

[0288] In another embodiment that may be combined with other embodiments or used independently, the combination of n and IND (e.g., n | IND) may be used, together with m, in computing f(n). It is worth noting that f(n) is computed upon receiving a fresh SQN / m, and only if the MAC received is successfully verified against the MAC computed using the newly derived subscriber key (K_n), does the value of f(n) get updated, thus serving as a version indicator of the subscriber key (i.e., K_n).

[0289] In another embodiment that may be combined with other embodiments, or used independently, although the MAC verification may be successful (e.g., with a new / old subscriber key K_n), the UE shall further use the subscriber key (e.g., old or new, depending on which of the first and second MAC matches the MAC received in the AV) to derive the anonymity key (AK) to retrieve the SQN (and / or the m value included therein) and verily whether the SQN value (and / or the m value included therein) meets the criteria described in TS 33.102, Annex C.2.2 (and / or the criteria described above, e.g., m value is greater / lower than previously used m value, depending on whether m is being incremented / decremented), and that it matches the m, which was guessed and used to derive the new subscriber key (K_n), if the MAC computed based of the new subscriber key is the one which matched the MAC received in the AV.

[0290] As a clarification of the embodiment, and as an embodiment that may be combined with other embodiments or be used independently, the SQN value may include the m value and the counter value. The m value may be included in the most significant bits and the counter value may be included in the least significant bits. The very least significant bits, e.g., the 3 LSBs, may not be encrypted. A UE (e.g., ME and / or USIM) may assume that a K_n value is used associated to the last known m value, and attempt to derive AK, decrypting the SQN value, using said K_n value. If the selected K_n value used to perform the decryption is correct, the UE will be able to decrypt the SQN value correctly retrieving in the most significant bits the same m value as the K_n value is associated with. However, if m changed, the retrieved most significant bits will most likely contain a different m value (because the wrong key was used). If this happens, the UE may guess the m value to be used, e.g., it may try with the next m’ value (assuming that m is an increasing or decreasing counter), derive the corresponding K_n’ key, and attempt the decryption of SQN using K_n’ checking whether the decryptedm’ value equals the m’ value associated with K_n’.

[0291] In previous embodiments, the UE has no means to check whether the m value (carried in the most significant bits of the SQN field) has changed or not. Thus, the UE may be forced to try with multiple keys (K_n and K_n’ as per the description in previous embodiment). Thus, in another embodiment that may be combined with other embodiments, or used independently, the least significant bits of the SQN field, bits that are not encrypted, include a hint of whether the m value has changed. This hint may be a flag whose value changes every time m changes. The flag may be the least significant bit of m. It may also be several bits, e.g., the least significant bits of m. Thus, the non-encrypted least significant bits of the SQN field may include a hint about the m value and a hint about the current counter value. When receiving the SQN value, the UE may use both hints to decrypt the SQN value.

[0292] In previous embodiment, the UE may have no means to check whether the m value (carried in the most significant bits of the SQN field) has changed or not. Thus, the UE may be forced to try with multiple keys (K_n and K_n’ as per the description in previous embodiment). However, this may be misused by an attacker and may force the UE to try out many multiple keys K_n’. Thus, in another embodiment that may be combined with other embodiments, or used independently, the UE includes a policy or configuration determining a maximum number of attempts to be performed for generating alternative keys K_n’ before dropping the request. For instance, the configuration may determine that up to s attempts are allowed. For instance, the configuration may be such that s is context dependent.

[0293] In another embodiment that may be combined with other embodiments or used independently, upon receiving an Authentication Vector (AV) from an HSS on-board a satellite, which uses an IOPS- based key separation mechanism, the UE initially identifies the “m” value to be used, based on the identifier “n” retrieved from the AMF field. The UE may check whether the LSBs of the SQN, which may be left in clear (i.e., unencrypted) and which may be associated with a counter (e.g., indicating the number of Authentication Vectors used and or still valid, using the same “m” value), or be part of the m value itself (i.e., the x LSBs of m, thus indicating whether the “m” value has changed).

[0294] In the first option (i.e., the LSBs are used as a counter) the UE (including USIM) may use the “m” value it has in store, which is associated with the satellite (or group / subclass of satellites) with the identifier “n”, derive the subscriber key K_n from it, and then derives AK from K_n and the RAND value received in the AV; UE then uses AK to decrypt the SQN (including the m value) and retrieves a value “mdec” which is then verified against the “m” value stored locally and used to generate K_n. If there is a match, the UE shall then verily the MAC value associated with the AV (e.g., to ensure the counter value has not been tampered with). In case of “m” values (i.e., m stored locally and mdec) mismatch and / or the counter value being (re)set to 0, the UE may derive the next subscriber key K_n’, based on the next “mnext” value (taking as a reference, the current “m” locally stored), then derive AK and using it to decrypt SQN to retrieve a value “m’dec”, which is then verified against “mnext”. In case of a match, the UE shall further verily the MAC value associated with the AV, and only upon a successful MAC generation does the UE generate an authentication response. In case of m values (i.e., “mnext” and “m’dec”) mismatch, the next subscriber key (K_n’) is discarded and an authentication response indicating the failure (e.g., including a failure cause, e.g., irretrievable m value) is sent back to the HSS on-board. In case of a failure in the MAC value verification, the authentication response, instead, indicates failure of the MAC verification. It is worth noting that deriving the subscriber keys K_n and K_n’ (i.e., based on the current and next “m” value) may be performed at once in certain scenarios e.g., when the counter is set to 0, and both “mdec” and “m’dec” are verified against “m” and “mnext”, respectively, such that if both verifications yield a mismatch, the MAC verification is skipped, and a response message indicating the failure due to irretrievable m value is sent. Whereas, in case one of the decrypted “m” values (mdecor m’dec) matches its respective “m” value at the UE’s end, the MAC verification, as described above, is performed. It is worth noting that how the m value is updated (i.e., the size of the jump between an moment and mnext) may be left to the (satellite) operator configuration. In the second option (i.e., where the LSBs sent in cleartext are part of the “m” value), the LSBs that are sent in cleartext are indicative of the next “m” value to be used. Hence, the UE guesses, as described in previous embodiments, the value of “m” to be used to derive the new subscriber key K’_n. Similarly, the UE may simultaneously or sequentially derive the subscriber key (based of the current “m” it has stored) and verily whether the MSBs retrieved from the decrypted m value(s) match the m values used in the subscriber key(s) derivation(s). Following a successful match of either one of the “m” values, the UE performs the MAC check, and only upon successful MAC verification does the UE update the “m” value stored locally (e.g., when a new m value is used). It is worth noting that the changing (e.g., incremental) LSBs of the “m” value sent in cleartext do not necessarily require the derivation of a new subscriber key with every primary authentication. For instance, only the (1-x) MSBs of the “m” value, where 1 is the m value bitlength and x the number of bits sent in cleartext, may be used in computing the f(n) parameter and subsequently in the subscriber key derivation. Hence, only when the x bits in cleartext overflow into the (1-x) MSBs is a new subscriber key derivation becomes required. In other words, in addition to a forced subscriber key update (e.g., due to compromise), this ensures a regular subscriber key update, due to the automatic change of the m value. In this case, the UE, upon receiving an AV where the x bits in cleartext are set to 0, the UE understands that the “m” value bits that affect the subscriber key derivation have now been updated, and thus a fresh subscriber key K_n may need to be derived. While this is reactive, an alternative, where such an update of the subscriber key may be foreseen, i.e., once the x bits that are sent in the clear reach their maximum (i.e., all bits set to 1, if incremental), the UE may preemptively update the subscriber key K_n based on the next anticipated m value, such that when it receives the next AV associated with the identifier “n” of the associated satellite (or group / subclass) of satellites), it already knows what to expect (i.e., x bits in cleartext set to 0 and a change in the (1-x) MSBs of the m value), hence it could verify based on the fresh subscriber key (i.e., derived using the fresh m value) whether the AV is valid (i.e., m value retrieved matches the one preemptively generated, and the MAC verification is successful).

[0295] It has been concluded in TR 33.700-29 associated with the security aspects of 5G Satellite Access that an option to limit the impact of the potential compromise of credentials stored in the HSS onboard a satellite (i.e., in full EPC onboard a satellite architecture scenario), is to use an lOPS-based keying mechanism as described in Annex F of TS 33.401. To that end, in some scenarios an in-band key deprecation for IOPS may be used. For example, the successful reception of an authentication vector with a larger m value may automatically lead to the old subscriber key being deprecated and a new subscriber key being used. Although, in some scenarios, the mechanism relies on sending the m value encrypted using AK, except for the least significant bits, which need to be in the clear to allow the UE to determine whether m has changed, and if so, estimate the new value of m. A potential issue with such a mechanism, specifically if a group of UEs share the same value m, is that in case a UE misses instances where the m value was updated, the LSBs may overflow thus carrying the change into the MSBs of the m value, in which case, when a UE tries to attach to the HSS onboard, and it receives an m value whose LSBs value is e.g., lower than the LSBs value of the m the UE has in store, the UE may not be able to determine the correct value of m, thus the need for a mechanism allowing the UE to estimate the correct m. Note that the issue may arise also in case LSBs value in the received SQN are greater or equal to the LSBs value of the m stored at the UE. Furthermore, if such a mechanism to recover the correct value of m fails, the UE may need to indicate this failure to the network onboard, so as to allow the network (e.g., on the ground) to properly resynchronize the value of m with the UE. It is therefore the object of some of the embodiments to address the issue.

[0296] In a related embodiment that may be combined with other embodiments or used independently, the number of least significant bits (LSBs) of m that is sent in the clear may be configurable and denoted as Delta m. A UE may be provided with such a configuration of Delta m via a message, e.g., by means of an RRC or NAS messages. This configuration may also be provided and / or available in the USIM.

[0297] In a further related embodiment that may be combined with other embodiments or used independently, the number of most significant bits (MSBs) of m that is sent encrypted may be configurable and denoted as Gamma m. A UE may be provided with such a configuration of Gamma m via a message, e.g., by means of an RRC or NAS messages. This configuration may also be provided and / or available in the USIM (e.g., NTN lOPS-based USIM).

[0298] In a further related embodiment that may be combined with other embodiments or used independently, the length of m may be defined as Length m. A UE may be provided with such a configuration of Length m via a message, e.g., by means of an RRC or NAS messages. This configuration may also be provided and / or available in the USIM.

[0299] In a further related embodiment that may be combined with other embodiments or used independently, given two parameters out of the three parameters Delta m, Gamma m, and Length m it is possible to obtain the third parameter, e.g.: Gamma m = Length m - Delta m.

[0300] In a further related embodiment that may be combined with other embodiments or used independently, a UE receiving a message with the m value, wherein only the Delta m LSBs of m are provided in the clear, the UE may check whether the received Delta m LSBs of m (in plaintext) match the Delta m LSBs of m stored in the USIM. If they match, the UE may perform previous actions, e.g., obtain K_n, and verify whether the MSBs retrieved from the decrypted m value match the m value used in the subscriber key(s) derivation(s).

[0301] In a further related embodiment that may be combined with other embodiments or used independently, a UE receiving a message with the m value, wherein only the Delta m LSBs of m are provided in the clear, and those received Delta m LSBs do not match the Delta m LSBs of the m stored in the USIM, the UE may perform a reconciliation / re synchronization of the m value. Since the m value that is received should only be higher, and the number of non-encrypted LSBs is Delta m, and if we call: the Delta m LSBs in the m value stored in the USIM: m usim LSBs, the Gamma m MSBs in the m value stored in the USIM: m usim MSBs, the Delta m LSBs in the m value received: m received LSBs, and the Gamma m MSBs in the m value received: m received MSBs,

[0302] Then, the newly updated m’ value equals m usim MSBs’ * 2A{Delta_m} + m usim LSBs’, where: m usim LSB’ = m received LSBs, and

[0303] (case 1) If (m received LSBs < m usim LSBs), then m usim MSBs’ = m usim MSBs + 1.

[0304] (case 2) If (m received LSBs > m using LSBs) then, m usim MSBs’ = m usim MSBs

[0305] In a further related embodiment that may be combined with other embodiments or used independently, a UE may obtain the new value m’ (reconciled / re-synchronized m’ value), e.g., as in previous embodiment. The UE may then try to decrypt the message, and check the correctness of the new value m’ by comparing the MSBs of the new value m’ with the MSBs of m, as received in the message. In case of a correct match / verification, the m value stored in the USIM is updated using m’. Alternatively, if this verification fails, in both case 1 and case 2, the UE may try to guess other m’ values, e.g., by further increasing m usim MSBs’, e.g., as m_usim_MSBs+l (particularly in case 2 first failure), and (for both cases, with more failures) m usim MSBs + 2, m usim MSBs + 3, ... , m usim MSBs + max trials, where max trials refers to a positive integer number greater than or equal to 1, and indicates how may attempts may be done. For each guessed m value, the UE may attempt to verily whether guessed m’ value is correct as in other embodiments, e.g., by trying to decrypt the message, and check the correctness of the new value m’ by comparing the MSBs of the new value m’ with the MSBs of m, as received in the message, max trials may be configured in the UE and / or USIM, e.g., via a message and / or preconfiguration. It is worth noting that the attempts to recover the correct m usim MSBs may be required given that a re-synchronization mechanism between the UE and HSS onboard a satellite to agree on another m value is not an option, as the HSS onboard is not able to derive the subscriber key by itself and instead requires the ground HSS for that, as the latter holds the Master Key associated with the UE, from which the subscriber key K_n is derived.

[0306] In a further related embodiment that may be combined with other embodiments or used independently, a UE may send a failure message indicating a failure to re-synchronize / recover m, e.g., with some of the above embodiments fails. In another embodiment that may be combined with other embodiments or used independently, the UE may request in the failure message indicating failure to re- synchronize / recover m to adapt certain parameters in previous embodiments, e.g., increase the size of Delta m; that is, the number of LSBs sent in cleartext may be expanded to provide the UE with more information allowing it a better chance to recover the correct m value.

[0307] In another embodiment that may be combined with other embodiments or used independently, the need to increase Delta m may be implicitly indicated to / understood by the HSS onboard upon receiving the failure message and / or having a failed authentication procedure. That said failure may indicate that the UE may need additional information (more bits in the clear) to be able to recover m. It is worth noting that the subsequent AV shall be fresh i.e., using fresh RAND, and subsequently a fresh AK to protect SQN. This alternative m recovery mechanism may be based on a network configuration or policy provisioned at the lOPS-based NTNs and lOPS-based NTN capable UEs e.g., in USIMs or ME. Furthermore, to ensure that such a recovery mechanism could not be used by a malicious actor to retrieve more bits of m associated with the UE, the failure message may be protected by the UE using a key (e.g., AK’) derived using the last valid subscriber key K n old (i.e., based on m value stored by the UE) and taking as input parameter a fresh random value. This requires the HSS on-board to maintain for all UEs both the most up-to-date subscriber key (K_n) and the last valid subscriber key (K n old) to be able to verily the failure message. Additionally or alternatively, the HSS may adjust the number of encrypted bits (Delta m). This may be explicitly indicated and / or implicitly indicated / adjusted based on the number of failed authentication procedures. For instance, if the HSS and UE run an authentication procedure and it fails, Delta m is increased by 1. If it fails again, Delta m increases by 1.

[0308] In an embodiment that may be combined with other embodiments or used independently, the HSS on-board may be configured with a policy / configuration allowing it to maintain for UEs the last used m value, or the difference between the last (valid) used m value and the current m, e.g., every time m is updated e.g., for a group of UEs sharing m, UEs that attach to the network and automatically update m use the network services as usual, whereas UEs that do not attach the network may be assigned a counter which increments every time m is updated and the UE does not attach, such that when the UE tries to attach to the HSS on-board, the latter could determine the difference between the m value stored at the UE and the current m to be used, and subsequently may pre-emptively adjust Delta m to allow the UE to easily recover / re-synchronize the m value it has in store. The HSS on-board (and / or UE) may be configured with a policy / configuration that enables the HSS to dynamically adjust Delta m based on conditions determined by the policy / configuration which may include e.g., a threshold for the difference between last valid m and current m, groups of UEs sharing m for which such a recovery is allo wed / disallo wed, etc.

[0309] In a further embodiment that may be combined with other embodiments or used independently, a message (e.g., authentication request) can include a flag indicating whether the satellite / HSS is using a new m value. For instance, a satellite in a group / subclass of satellites may have been compromised and the remaining satellites may receive a new m and a new K_n. Every time that this happens, the satellites (i.e., HSSs) include the flag that may be just flipping the flag value indicating that m has changed (e.g., increased / decreased). The UE / USIM may keep track of the current flag value and use the following m value when the received flag value changes its value. This description using a flag (1 bit) is equivalent to transmitting the least significant bit of the m value as indication of the m value being used. Alternatively, the b least significant bits of the m value are transmitted as indication. Upon reception of the hint (flag), the UE / UICC may determine a new m value, derive a new K_n (and / or AK), and try to verily the incoming message (e.g., MACin an authentication request). If the verification succeeds, the m value in the table is updated. If the verification fails, a failure message may be reported including as cause m desynchronization. (Add, an alternative where m is always updated, but only used to derive new K_n upon receiving the indication - indication of compromise).

[0310] In a further embodiment that may be combined with other embodiments or used independently, the m value may be transmitted as a new field (e.g., information element) and it may be signed by the entity managing the root key K used to derive K_n. This signed m value may be included in a message, e.g., an authentication request.

[0311] In a further embodiment that may be combined with other embodiments or used independently, if the LSBs of the SQN value may indicate the m value used, in other words, the least significant bits (LSBs) of SQN are equal to the LSBs of the m value. In this situation, upon reception of a SQN value, the UE may share this SQN with the USIM that prior to performing the authentication may determine whether the LSBs of the SQN correspond to the LSBs of m as stored in the USIM for the associated K_n. If they are not equal, it may then check / search for the next m with the same LSBs, and use this next m to derive the corresponding K_n. The key derivation function may take as input MK concatenated with n and m (e.g., the function f(n) mentioned in TS 33.401). This newly obtained K_n value is then used to verify / perform the authentication procedure. If the authentication succeeds, then the value of m stored in the USIM is updated. Note that this would mean that an old key does not only get deprecated after the successful reception of an authentication vector (AV) with a larger SQN value (as stated in S3-243318), but potentially also when a smaller SQN is received. This embodiment indicates that in an IOPS based solution for satellite access, the USIM is required to determine the m value given the LSBs in SQN and only update the m value when the authentication procedure (e.g., verification of a message authentication code) succeeds given the updated K_n value for the new m value and the received SQN value.

[0312] Section: Mitigation of potential DOS through unprotected NAS reject message

[0313] In an NTN communication scenario, it is concluded in 3GPP TR 23.700-29 that following the initial attach procedure, the access device may include a wait timer and a list of satellite IDs in the NAS reject message to the UE when the access device is operating in S&F mode and no feeder link is available. As described in solution #31 in TR 33.700-29, since the NAS reject message is sent unprotected, the wait timer and / or list of satellite IDs may be forged or tampered with by a malicious attacker thus resulting in a potential Denial of Service attack on the UE. Additionally, a forged list of satellite IDs may lead the UE to potentially select / attach to a malicious access device e.g., a fake base station (FBS) using one of the forged / fake satellite IDs sent to the UE in the NAS reject message. It is therefore the object of some of the embodiments to address these issues.

[0314] In an embodiment that may be combined with other embodiments or used independently, a UE may be configured with the list of satellite IDs that it is authorized to use for access and / or are authorized to serve the UE. This list may be communicated to the UE by means of a message or command, e.g., through one, or any, depending on what the UE supports, of the following:

[0315] - a protected NAS message (e.g., NAS accept following the establishment of a NAS security context);

[0316] - a Tracking Area Update (TAU) procedure where the list of satellite IDs may be considered part of the specific DRX parameters information of the UE;

[0317] - a UE configuration update procedure;

[0318] - a GUTI re-allocation procedure;

[0319] - an RRC message, where the message may be sent through or by an access device operating as part of a terrestrial or nonterrestrial network.

[0320] In an embodiment that may be combined with other embodiments, e.g., the previous one, or used independently, a UE may attempt to connect to a satellite at high altitude, e.g., a GEO satellite, and the GEO satellite may be aware of the available satellites at a lower orbit, e.g., LEO, may indicate in the reject message the IDs of those lower orbit satellites.

[0321] In an embodiment that may be combined with other embodiments, e.g., the previous one, or used independently, this list may be used by the UE with different purposes, e.g., to verify the satellite IDs received from an access device in the NAS reject message, such that if a satellite ID does not figure in the list configured at the UE, the UE may perform one or more of:

[0322] - If the list of satellite ID(s) contains only non-matching satellite ID(s), the UE may discard the NAS reject message and ignore the wait timer and satellite IDs therein;

[0323] - If the list of satellite ID(s) contain both matching and non-matching satellite ID(s), the UE may (1) keep the satellite ID(s) which do not figure within the configured list (i.e., no match found), to check with the network (e.g., by sending a request message to an access device or a network function) if the locally configured list needs to be updated, wherein the UE may include the non-matching satellite ID(s) in the update request; or / and (2) keep the satellite ID(s) which figure in the configured list (i.e., match found), and discard the ones for which no match was found.

[0324] In another embodiment that may be combined with other embodiments or used independently, the list (either (1) the list of satellite IDs included in the NAS message (e.g., NAS accept / reject message) together with the wait timer or (2) the list of satellite (IDs) that the UE is authorized to use) may further be enriched with ephemeris data associated with the satellite IDs that may be used by the UE. The UE may use this information to estimate, based on UE location, the approximate time window(s) during which said satellite may be available and / or expected to provide NTN services to the UE, for instance, an NTN service may be an uplink connection, e.g., an uplink data transmission or a downlink connection, e.g., a downlink data transmission.

[0325] Moreover, the list may be a cyclic list.

[0326] Moreover, the list may be an ordered list that reflects the order in which the satellites pass over the UE's horizon, thus allowing the UE to recognize the satellite that is serving it next.

[0327] Additionally, the list may be associated with an expiration date and / or timer, wherein the expiration date / timer may be per entry, per group of satellites, or applicable to the entire list of satellite IDs. As a matter of clarification, the timer may indicate how long the satellite may be reachable, and / or provide NTN services to the UE, e.g., an uplink connection may be feasible.

[0328] Moreover, each satellite in the list may be associated with usage conditions and / or context, e.g., expected usage, expected cost, so that the UE may determine under which conditions a specific access device may be used. Moreover, each satellite in the list may be associated to a given orbit. In another embodiment that may be combined with other embodiments or used independently, the list may further be enriched with PLMN-related information (e.g., PLMN ID consisting of MCC and MNC) to further determine which PLMN(s) are authorized and / or the UE is authorized to access to the network through. The list may also include an access management function (e.g., MME / AMF) identifier, e.g., an MME on-board identifier, or an identifier which consists of a first segment identifying the MME (i.e., shared between ground MME and the different MMEs onboard one or more satellites), and one or more segments including identities of the specific MME on-board and / or the RAN (e.g., eNB / gNB) on-board.

[0329] In another embodiment that may be combined with other embodiments or used independently, the UE may be configured with a configuration / rules / metadata that may steer the selection of a given access device (i.e., satellite) based on the context of the UE. As a matter of clarification, the context of the UE may include the list of satellite ID(s) it has been provided with e.g., through a NAS message.

[0330] In another embodiment that may be combined with other embodiments or used independently, the list of satellite IDs may be updated regularly, on-demand, or conditionally e.g., based on one or more of the following events:

[0331] - updates to the ephemeris data of satellite(s);

[0332] - new operational satellite(s) put into orbit;

[0333] - satellites getting decommissioned;

[0334] - change in the order of satellites;

[0335] - reception of satellite ID(s) that do not figure within the configured list of satellite IDs;

[0336] - expiry of the configured list at the UE.

[0337] The entity managing the list, e.g., the home PLMN, e.g., the 0AM of the home PLMN or a NF in the home PLMN may trigger the update on demand. Additionally or alternatively, the UE may trigger this update in certain situations, e.g., when the configured list has expired, e.g., when a percentage (e.g., more than x %) of the configured satellite IDs have expired, e.g., when the UE is not able to connect to any of the configured satellite (IDs).

[0338] As a matter of clarification, the update of the list of Satellite IDs may mean that a first list of Satellite IDs (received at a first time) is updated based on the reception of a new list of Satellite IDs (e.g., received at a second time, the second time after the first time), e.g., because of the reception of satellite ID(s) that do not figure within the configured list of satellite IDs.

[0339] In general, it is described a method for operating an apparatus to manage a connection wherein the method comprises, (1) the apparatus checking or selecting a preferred authentication procedure; (2) the apparatus performing the preferred authentication procedure with a first core network through a first access device; and (3) the apparatus setting up a connection with the first core network, and wherein the apparatus checking or selecting a preferred authentication procedure further comprises (1.1) receiving a store and forward indication from the first access device and (1.2) determining the preferred authentication procedure based on the indication and a configuration stored in the apparatus, and wherein (1.2.1) the indication may be a list of satellite IDs included in a (e.g., NAS) reject message (e.g., sent by a second access device) and (1.2.2.) the configuration stored in the apparatus may be a list of satellite IDs preconfigured in the apparatus and wherein performing the preferred authentication procedure with a first core network through a first access device comprises (2.1) selecting a first access device that is both in the list of satellite IDs included in the reject message and in the list of satellite IDs preconfigured in the apparatus.

[0340] Section: Application to cellular technologies

[0341] A cellular system is a wireless communication system that consists of three main components: user equipment (UE), radio access network (RAN), and core network (CN). These components work together to provide voice and data services to mobile users over a large geographic area.

[0342] User equipment (UE) is the device that a user uses to access the cellular system, such as a smartphone, a tablet, a laptop, loT device, or a wearable device. A UE typically may contain the following components:

[0343] - A universal integrated circuit card (UICC), which stores the user's identification and authentication information, such as the subscription permanent identifier (SUPI) or credentials.

[0344] - A transceiver, which converts the digital signals from the processor into analog signals for transmission and reception over the air interface. The transceiver also performs modulation, demodulation, coding, decoding, and other signal processing functions.

[0345] - A processor, which controls the operation of the UE and executes the applications and services that the user requests. The processor also communicates with the RAN and the CN using various protocols.

[0346] - A display, which shows the user the information and feedback from the UE, such as the signal strength, the battery level, the call status, the messages, the contacts, the menu, etc.

[0347] - A microphone and a speaker, which enable the user to make and receive voice calls, as well as use other audio features, such as voice mail, voice recognition, etc.

[0348] - A keyboard and / or a touch screen, which allow the user to enter and select commands, text, numbers, etc.

[0349] - A camera and / or a video recorder, which enable the user to capture and send images and videos, as well as use other multimedia features, such as video calling, video streaming, etc.

[0350] - A memory, which stores the data and programs that the user needs, such as the phone book, the messages, the photos, the videos, the applications, etc.

[0351] - A battery, which provides the power supply for the UE.

[0352] A UE access the cellular network via the radio access network, as described below. Certain UEs may communicate with each other by using device-to-device communication, also known as sidelink communication using the PC5 interface that may rely on physical sidelink (PS) broadcast channel, PS shared channel, PS control, etc.

[0353] A UE may receive a configuration by means of different procedures:

[0354] Downlink control information (DCI) is a type of control information that is sent from the BS to the UE on the physical downlink control channel (PDCCH). DCI contains various parameters that instruct the UE how / when to decode and transmit data on the physical downlink shared channel (PDSCH) and the physical uplink shared channel (PUSCH), such as the resource allocation, the modulation and coding scheme. The UE needs to monitor the PDCCH in each subframe to detect and decode the DCI that is addressed to it.

[0355] Uplink control information (UCI) is a type of control information that is sent from the UE to the BS on the physical uplink control channel (PUCCH) or the physical uplink shared channel (PUSCH). UCI contains various feedback signals that inform the BS about the status and quality of the downlink transmission, such as the HARQ acknowledgments (ACKs), the channel state information (CSI), and the scheduling requests (SRs). The UE needs to encode and transmit the UCI according to the configuration and timing indicated by the BS.

[0356] Sidelink control information (SCI) is a type of control information that is sent from the UE to another UE on the physical sidelink control channel (PSCCH) in device-to-device (D2D) communication scenarios. The main functions of SCI include resource allocation, synchronization, channel quality reporting, .

[0357] Medium access control (MAC) control element (MAC CE) is a type of control information that is sent from the BS to the UE or vice versa on the MAC layer. MAC CE contains various commands or indications that regulate the MAC layer functions, such as the buffer status report (BSR), the timing advance command (TAC), the discontinuous reception (DRX) command, etc. The UE needs to process the MAC CE according to the MAC protocol and the configuration provided by the BS.

[0358] Radio resource control (RRC) command is a type of control information that is exchanged between the BS and the UE on the RRC layer. RRC Command contains various messages that modify / configure RRC parameters and / or initiate, modify, or release the RRC connection or the radio bearers between the UE and the BS, such as the RRC connection setup, the RRC connection reconfiguration, the RRC connection release, the security mode command, the mobility from E-UTRA command, the handover from E-UTRA preparation request, etc. The UE needs to respond to the RRC Command according to the RRC protocol and the configuration provided by the BS.

[0359] Non-access stratum (NAS) messages are used for signalling between UE and core network (CN) on the non-access stratum (NAS) layer. NAS messages enable functionality such as registration, session establishment, security, and mobility management. The UE needs to respond to the NAS Command according to the NAS protocol and the configuration provided by the CN. UE parameter update (UPU) is a procedure between the UE and the home network that enables the home network to update configuration parameters in mobile phones and / or USIM using tthe UDM control plane procedure (TS 23.502). The UE can receive Parameters Update Data from the UDM after the UE has registered in the 5G network.

[0360] Steering of Roaming (SoR) enables the home network to guide the user equipment (UE) when registering on a visited network. For detailed information about the interfaces and registration in the 5G System, refer to 3GPP TS.23.501 (Release 15)

[0017] and 3GPP TS 24.501 (Release 15)

[0018] , The 5G CP-SOR is activated during or after registration to update the UE's "Operator Controlled PLMN Selector with Access Technology" list via secure NAS messages, as directed by the home PLMN based on specific operator policies, such as preferred networks or UE location.

[0361] UE configuration update (UCU) is used to update configuration parameters as per TS 23.502 that may include Access and Mobility Management related parameters decided and provided by the AMF, UE Policy provided by the PCF. When AMF wants to change the UE configuration for access and mobility management related parameters the AMF initiates the procedure defined in clause 4.2.4.2. When the PCF wants to change or provide new UE Policies in the UE, the PCF initiates the procedure defined in clause 4.2.4.3. If the UE Configuration Update procedure requires the UE to initiate a Registration procedure, the AMF indicates this to the UE explicitly. The procedure in clause 4.2.4.2 may be triggered also when the AAA Server that performed Network Slice-Specific Authentication and Authorization for an S-NSSAI revokes the authorization.

[0362] Radio access network (RAN) is the part of the cellular system that connects the UEs to the CN via the air interface. The RAN consists of base stations (BSs). A base station (BS) is a fixed or mobile transceiver that covers a certain geographic area, called a cell. In 5G, a BS is also called a gNB (next generation node B). A BS can serve multiple UEs simultaneously within its cell, by using different frequencies, time slots, codes, or beams. A BS also performs functions such as power control, handover control, channel allocation, interference management, etc. A base station can be divided into two units: a central unit (CU) and a distributed unit (DU). The CU performs the higher layer functions, such as RLC, PDCP, RRC, etc. The DU performs the lower layer functions, such as PHY and MAC. The CU and the DU can be co-located or separated, depending on the network architecture and deployment. In cellular systems, a base station may be denoted, based on context, as a cell, or gNB.

[0363] The cell may also refer to the coverage area of a base station. A BS may have different coverage areas such as a macro cell (e.g. several kilometres wide), a pico cell (e.g., for a given location such as a stadium) or a femto cell for a small location (e.g., a home or part of it).

[0364] A base station may communicate with the core network. Since there can be base stations for different cellular systems, different interfaces are required. For instance, a base station, eNB, in a 4G Long Term Evolution (LTE) system (also known as Evolved Universal Mobile Telecommunications Systems (UMTS) Terrestrial Radio Access Network (E-UTRAN)) may interface with the 4GCN known as EPC through the corresponding interface. For instance, a base station, gNB, in a 5G system (i.e., 5G New Radio or Next Generation RAN) may communicate with the 5GC through a different interface. 4G and 5G base stations may communicate with each other directly or through their corresponding core networks.

[0365] The main protocols used between the UEs and the RAN are:

[0366] - The physical layer (PHY), which defines the characteristics of the air interface, such as the frequency bands, the modulation schemes, the coding rates, the frame structure, the synchronization, etc.

[0367] - The medium access control (MAC) layer, which regulates the access of the UEs to the shared radio channel, by using techniques such as orthogonal frequency division multiple access (OFDMA), time division duplex (TDD), frequency division duplex (FDD), etc.

[0368] - The radio link control (RLC) layer, which provides reliable data transmission over the radio channel, by using techniques such as segmentation, reassembly, error detection, error correction, retransmission, etc.

[0369] - The packet data convergence protocol (PDCP) layer, which compresses and decompresses the headers of the data packets, encrypts and decrypts the data, and performs data integrity protection.

[0370] - The radio resource control (RRC) layer, which establishes, maintains, and releases the radio bearers between the UEs and the RAN, as well as exchanges the signaling messages for functions such as connection setup, handover, measurement reporting, security activation, etc.

[0371] A transmission / reception communication unit or transceiver may be used by BS and UE to transmit / receive data. Control data may be required for a physical broadcast channel, physical downlink control channel, etc. Data may be for the physical downlink shared channel.

[0372] Data may be encoded by the UE and / or BS to obtain data symbols and / or control symbols that may be exchanged over the wireless interface. The conversion from digital data into analog symbols may be done by the transmission / reception communication unit

[0373] A medium access control control-element (MAC-CE) is a MAC layer communication element that is used to control the communication between wireless devices. A MAC-CE may be exchanged in a shared channel, e.g., the physical downlink / uplink / sidelink shared channel.

[0374] The communication between a UE and a base station or the communication between UEs (when sidelink is used) may involve the exchange of reference signals. Reference signals may include primary synchronization signal (PSS), a secondary synchronization signal (SSS), a physical broadcast channel demodulation reference signal (DMRS), a channel state information reference signal (CSI-RS). Core network (CN) is the part of the cellular system that connects the RAN to other networks, such as the Internet, or other cellular systems. The CN consists of two main (control / user) domains. The control domain is responsible for providing signalling and control functions for the UEs, such as authentication, authorization, mobility management, session management, etc. The control plane consists of several network functions (NFs), such as the access and mobility management function (AMF), the session management function (SMF), the unified data management (UDM), the policy control function (PCF), the network exposure function (NEF), and the authentication server function (AUSF). The access and mobility management function (AMF) is a NF that handles the registration, deregistration, connection management, and mobility management for the UEs. The session management function (SMF) is a NF that handles the establishment, modification, and release of the sessions for the UEs. The SMF also communicates with the user plane devices to perform functions such as IP address allocation, tunneling, QoS, etc. The unified data management (UDM) is a NF that stores and manages the user data, such as the SUPI, the service profile, the subscription status, etc. The policy control function (PCF) is a NF that provides the policy rules and charging information for the UEs, such as the access type, the service level, the data rate, the quota, etc. The network exposure function (NEF) is a NF that exposes the network capabilities and services to external applications and devices, such as the IMS, the Internet of Things (loT), etc. The authentication server function (AUSF) is a NF that performs the primary authentication with the by using credentials and the SUPI. The user domain is responsible for providing data and multimedia services to the UEs, by using packets and IP addresses. The user plane consists of two main functions: the user plane function (UPF) and the data network (DN). The user plane function (UPF) is a device that forwards the data packets between the UEs and the DNs, as well as performs functions such as tunneling, firewall, QoS, charging, etc. The data network (DN) is a network that provides access to the services and applications that the UEs request, such as the Internet, the IMS, etc.

[0375] A residential gateway (RG) is a device that connects a home network to an external network, such as the Internet or a cellular system. An RG typically provides functions such as routing, switching, firewall, NAT, DHCP, DNS, VPN, etc. An RG can also support various types of interfaces, such as Ethernet, Wi-Fi, Bluetooth, USB, etc. A cellular-capable RG is an RG that has a cellular interface, such as a UICC slot, a cellular modem, or an antenna, that enables it to access the cellular system as a backup or an alternative to the wired or wireless broadband connection. A cellular-capable RG can provide benefits such as: (1) Enhanced reliability, by switching to the cellular connection in case of a failure or a degradation of the broadband connection; (2) Increased bandwidth, by aggregating the cellular connection and the broadband connection to achieve higher data rates or QoS.

[0376] A multi-SIM subscription is a subscription that allows a user to have multiple SIMs (or eSIMs) that are linked to the same account and service profile. A user can use the multi-SIM subscription to access the cellular system from different devices, such as a smartphone, a tablet, a laptop, or a wearable device, without having to switch the SIM card or the device.

[0377] In reference to Fig. 6, devices 100, 102, and 128 can play the role of UEs. Device 102 is part of a cellular-capable RG providing connectivity to a home network 129 e.g., by means of a local area network and / or wireless local area network. Device 102 is served by base station 104.

[0378] The RAN 127 comprises base station 103 and serves UE 128. UE 128 may also be a UE to Network relay given access to remote UE 136 that is out of coverage of base station 103. UEs 134 and 136 also communicate with each other via a UE-to-UE relay 135. Within the RAN, the range of base station 103 is extended via smart repeater 137 and reflective intelligent surface (RIS) 138. Smart repeater 137 and RIS 138 give access to UE 142.

[0379] The RAN 143 includes base station 104 that serves as wireless access infrastructure for the home network. Base station 104 also serves a mobile access device and / or UE as a UAV 139. UAV 139 may provide connectivity to remote UE 136.

[0380] Furthermore, a satellite gateway 141 is shown that connects to satellite 140 and may provide connectivity services to remote UE 136 or UE 100.

[0381] In Fig. 6, the 5G core network 133 may include one or more an AMF 121, SMF 123, UPF 122, AUSF 124, UDM 125, PCF 131, NEF 132 and allows the connection to a data network 130.

[0382] In Fig. 6, a second core network 142, e.g., a legacy core network as a 4G core network, is also shown that may interface with the 5G core network 133, interface with base stations denoted eNB in 4G, and provide a connection to the data network 130. The legacy 4G core network is denoted EPC and may include one or more mobility management entities (MME), a serving gateway, a multimedia broadcast multicast service gateway, a broadcast multicast service center, a packet data network gateway, etc. The mobility management entity may handle the signalling between UE and the 4G CN and may interact with the home subscriber server (HSS) in charge of the storage and management of subscriber data and secrets. The MME may provide connection management, similar to the AMF in 5G. The serving gateway may be used to exchange user internet protocol messages whereby the serving gateway may interact with the packet data network gateway that is connected to IP services. Multiple protocols in 4G and 5G have similar features. For example, the 5G network registration and 4G attach registration message are initially sent by the UE to establish a connection between the UE and the CN, which involves sending an initial request from the UE with its identity and capabilities, receiving an authentication request from the CN with a challenge, sending an authentication response from the UE with a response, receiving an authentication result from the CN with an indication of success or failure, and sending a security mode command from the CN with the selected security algorithms. As a result of this connection establishment procedure, NAS and AS keys are derived from the K AMF (5G) and K ASME (4G) where K AMF is managed by the AMF and K ASME is managed by the MME.

[0383] A UE may connect to a serving network or serving Public Land Mobile Network (PLMN). A UE may have a subscription with a home PLMN, and during the registration procedure, the (AMF of the) serving PLMN may forward the registration request to the (AUSF of the) home PLMN that may perform an initial authentication procedure between home PLMN and UE. If the authentication procedure is successful, keys are derived and the home PLMN may share derived credentials with the serving PLMN, including K SEAF, that may be used to derive K AMF, from which NAS keys and AS keys are derived. The registration request sent by the UE includes an identifier that can be used by the home PLMN to identify the UE. To prevent privacy vulnerabilities, the long-term subscriber’s identifier known as Subscriber Permanent Identifier (SUPI) may not be exchanged in the clear, but instead, either a Subscription Concealed Identifier (SUCI) or a pseudonym known as GUTI are exchanged with the AMF of the serving PLMN. The AMF of the PLMN may then forward the SUCI to the home PLMN so that the home PLMN decrypts / verifies it.

[0384] Different embodiments may be combined with each other or may be used independently as required to address requirements and / or missing capabilities.

[0385] To summarize, a method, apparatus, and system for authenticating, authorizing, and managing a connection in a cellular system have been described to allow a user to retrieve / send some data, e.g., from / to an application function (AF) or to communicate with another remote user over multiple networks in an optimized / secure manner. The user may have one or multiple devices (UEs) using (e.g., connected to) multiple / different networks, e.g., a device with multiple subscriber identity modules (SIMs) and / or different radio access technologies.

[0386] It is noted that the invention can be applied to various types of UEs or terminal devices, such as mobile phone, vital signs monitoring / telemetry devices, smartwatches, detectors, vehicles (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2X devices, Internet of Things (loT) hubs, loT devices, including low-power medical sensors for health monitoring, medical (emergency) diagnosis and treatment devices, for hospital use or first-responder use, virtual reality (VR) headsets, etc.

[0387] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated. Additionally, the expression “at least one of A, B, and C” is to be understood as disjunctive, i.e., as “A and / or B and / or C”. A single unit or device may fulfil the functions of several items recited in the claims.

[0388] The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0389] The described operations like those indicated in the above embodiments may be implemented as program code means of a computer program and / or as dedicated hardware of the related network device or function, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

862024P00447WOClaims1. A method for operating an apparatus to manage a connection wherein the method comprises: the apparatus checking or selecting a preferred authentication procedure; the apparatus performing the preferred authentication procedure with a first core network through a first access device; and the apparatus setting up a connection with the first core network.

2. The method of claim 1, wherein the apparatus checking or selecting a preferred authentication procedure comprises receiving a store and forward indication from the first access device and determining the preferred authentication procedure based on the indication and a configuration stored in the apparatus.

3. The method of claim 2, further comprising receiving, by the apparatus, a first authentication message, wherein the determining of the preferred authentication procedure is also based on the first authentication message.

4. The method of claims 1, 2, or 3, wherein the first access device is on a satellite, and wherein the preferred authentication procedure is one of: an authentication procedure with the first core network on the ground when the first access device does not indicate store and forward mode; or an authentication procedure with the first core network in the satellite when the first access device indicates store and forward mode and the apparatus has credentials; or an authentication procedure with the first core network in the satellite when the first access device does not indicate store and forward mode and the apparatus has credentials and a configuration preferring absence of the store and forward mode.

5. The method of any of claimsl, 2 or 3, wherein the preferred authentication method is an authentication procedure preferred by the first access device.872024P00447WO6. The method of claim 5, wherein the checking or selecting the preferred authentication procedure includes the apparatus transmitting at least a first identifier and a second identifier, the first identifier for a first authentication procedure and the second identifier for a second authentication procedure; and the apparatus receiving a message with an indication of the preferred authentication procedure selected by the first access device.

7. The method of any of the preceding claims, further comprising the apparatus performing an authentication procedure with the first core network on ground through the first access device, the apparatus receiving a first update message with parameters of an authentication procedure with the first core network in a satellite.

8. The method of any of the preceding claims, further comprising the apparatus performing an authentication procedure with the first core network through the first access device, the apparatus receiving a first update message, said first update message comprising a presence parameter indicative of a presence or absence of a list of satellite access device identifier(s), wherein the list of satellite access device identifiers lists candidate access devices that the apparatus may connect to access the first core network.

9. The method of any of claims 1 to 7, further comprising: the apparatus receiving a first update message, wherein the first update message comprises a updated list of satellite access device identifiers and / or a timer, the method comprising the apparatus updating a list of satellite access device identifiers stored on the apparatus, and wherein the timer is indicative of a time window during which a listed access device is expected to provide a Non-Terrestrial Network, NTN, service or a time estimate to the next NTN gateway.

10. The method of any of claims 1 to 6, further comprising: the apparatus receiving a first update message, wherein the first update message comprises a first list of access device identifiers, the apparatus receiving a second update message, wherein the second update message comprises a second list of access device identifiers, and882024P00447WO the apparatus updating the first list of access device identifiers with the second list of access device identifiers.

11. The method of any of claims 7, 8, 9 or 10, further comprising: receiving, by the apparatus, a first configuration, the first configuration comprising an authorized access device identifier.

12. The method of claim 11, further comprising: verifying, by the apparatus, whether the access device identifiers received in the first update message and / or second update message are authorized to be used by means of the fust configuration.

13. The method of any of claims 1 to 4, wherein the preferred authentication procedure is an authentication procedure with a first core network in the first access device and the method comprises: the apparatus storing a root key arranged to derive a first authentication key; the apparatus receiving a first message from the first access device containing one of:- an indication whether the first authentication key needs to be updated based on a first value m, wherein the first value m is transmitted in a field and indicates the version of the first authentication key, or- a first value m indicating part of a first authentication key identity.

14. The method of claim 13, wherein the first value of m is transmitted implicitly.

15. The method of claim 1 to 7 and 13 to 14, wherein the preferred authentication procedure is an authentication procedure with a first core network in the first access device and the method comprises: the apparatus storing a root key arranged to derive a first authentication key; the apparatus receiving a first message from the first access device containing an authentication token, wherein the authentication token includes a sequence number and an authentication code, the apparatus determining a first value from the sequence number, wherein the first value indicates a version of the first authentication key, the apparatus computing a second authentication key from the first value, the apparatus verifying the authentication code by means of the first and / or second authentication key.892024P00447WO16. The method of claim 1 to 7 and 13 to 15, wherein the preferred authentication procedure is an authentication procedure with a first core network in the first access device; wherein the method comprises: the apparatus storing a root key arranged to derive a first authentication key identified by a first authentication key identifier; the apparatus receiving a first message from the first access device containing an encrypted field including a received first authentication key identifier, the apparatus decrypting the encrypted field by means of the first authentication key and determining whether the first authentication key used in the decryption is correct by checking whether the decrypted received first authentication key identifier matches the first key authentication identifier, and depending on the outcome of the first authentication key identifier verification, the apparatus performing one or a combination of the following:■ proceeding with the processing of the first message when the first authentication key used in the decryption is classified as correct;■ attempting to decrypt the encrypted field with a second authentication key if the first authentication key is classified as incorrect; and■ sending an authentication response containing a failure message indicating the failure cause.

17. The method of claims 15 or 16, wherein the verification by means of the second authentication key triggers the usage of the second authentication key instead of the first authentication key when performing the preferred authentication procedure and the storage of the first value.

18. The method of any of claims 13 to 17, wherein the first authentication key is identified by a function of a second value n transmitted in an AMF field and the first value m, and the apparatus stores a list of (n,m) tuples, where each tuple indicates whether the first authentication key with which it is associated, is enabled or disabled.

19. The method of any of claims 13 to 18, comprising deriving the first authentication key from the root key based on a key derivation function, wherein the derivation function uses one or more input parameters; wherein the one or more input parameters change when all values of the first value m are used; and wherein the one or more input parameters comprise the root key and / or an identifier902024P00447WO indicating that all values of the first value m are used, and / or an indicator of the first authentication key version.

20. The method of any of claims 13 to 19 wherein the apparatus receives a sequence number, SQN, in the first message and retrieves a local sequence number SQN’ identified by one of:IND and a subset of bits of n, or the n value, or an 8-bit value, IND; or a number of satellite identifiers, being a value n; orIND and a subset of bits of n.

21. The method of any of claims 12 to 19, wherein a successful authentication procedure with apparatus or the reception of a confirmation message from a managing entity causes the first access device to send a request message to the managing entity requesting a new fust authentication key .

22. The method of claim 21, wherein the request message comprises one or more of: the next sequence number, and proof from the apparatus of the successful execution of the authentication procedure, and the confirmation message includes one or more of: fresh m value, the next sequence number, a new first authentication key.

23. An apparatus comprising a receiver, a transmitter, a controller, and a medium storage including instructions to perform a method for managing a connection, comprising: the apparatus checking or selecting a preferred authentication procedure; the apparatus performing the preferred authentication procedure with a first core network through a first access device; and the apparatus setting up a communication connection with the first core network.

24. A user equipment comprising the apparatus of claim 23.912024P00447WO25. A computer program product comprising code means for producing the steps of the method of any one of claims 1 to 22 when run on a computer device.

Images