WO2025032037A1

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

Info

Publication number: WO2025032037A1
Application number: PCT/EP2024/072125
Authority: WO
Inventors: Oscar Garcia Morchon; Noureddine SABAH; Robert James Davies; Walter Dees
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2023-08-07
Filing date: 2024-08-05
Publication date: 2025-02-13
Anticipated expiration: 2026-02-07

Abstract

Enhanced user authentication in cellular networks 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

METHOD, APPARATUS, AND SYSTEM FOR ENHANCED AUTHENTICATION,

AUTHORIZATION, AND CONNECTION MANAGEMENT IN CELLULAR NETWORKS

FIELD OF THE INVENTION

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.

BACKGROUND OF THE INVENTION

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).

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.

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.

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.

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.

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.

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.

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.

These situations lead to multiple challenges, for instance, in some situations, a UE may need to retrieve/send some data, e.g., from an application function (AF) or when communicating with another remote user, over those multiple networks or non-terrestrial network. It is therefore desirable to retrieve/exchange such data from multiple networks or non-terrestrial networks in an optimized/secure manner.

SUMMARY OF THE INVENTION

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

This object is achieved by a method as claimed in claim 1, by an apparatus as claimed in claim 48, by a user equipment as claimed in claims 49, and by a computer program product as claimed in claim 50.

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.

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.

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 method for operating a first network entity, comprising the first network entity receiving a request of/sending keying materials from/to a second network entity to allow the second network entity to perform lawful interception on the data exchanged over the path (of the multi-path connection) managed by the second network entity; the first network entity negotiating with the second network entity the parameters of the multi-path connection; and the first network entity performing a protocol based on privacy-enhancing technologies/multiparty communication with the second network entity to determine the communication parameters of the paths without disclosing private information such as available resources.

According to a fifth aspect of the invention, it is proposed a computer program product comprising code means for producing the steps of the methods of the third and fourth aspects, when run on a computer device.

Accordingly, data can be retrieved over multiple networks in an optimized/secure manner, e.g., from an application function or when communicating with other remote users.

According to a first option that may be combined with any of the first to fifth aspects, a command may be received (e.g., by the apparatus) from a first core network through a first access device to establish a multipath connection over the first access device and a specified access device and/or second core network using a set of configuration parameters for the multipath connection and/or core network, and, if not connected, a connection to the specified access device and/or the second core network may be established (e.g., by the apparatus), and the communication for one or more services may be started (e.g., by the apparatus) over the first access device and the specified access device and/or the second core network by applying the set of configuration parameters.

According to a second option that may be combined with the first option or any of the first to fifth aspects, the configuration parameters may 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 (e.g., via RACH); 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 storage-and- forward mode; keying materials; IP addresses for the different communication paths; congestion state for different 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 multipath communication are applicable.

According to a third option that may be combined with the first or second option or any of the first to fifth aspects, the specified access device may be connected (e.g., by the apparatus) by performing primary authentication or by means of keying materials received in the configuration parameters, where keying materials may include authentication server keys and/or network access server keys.

According to a fourth option that may be combined with any of the first to third options or any of the first to fifth aspects, a first token may be exchanged (e.g., by the apparatus) through the first access device with the first core network; a second token may be exchanged (e.g., by the apparatus) through the specified access device with a second core network of the specified access device; and the first and second tokens may be checked (e.g., by the apparatus) to validate the establishment of the multipath connection.

According to a fifth option that may be combined with any of the first to fourth options or any of the first to fifth aspects, an AKMA procedure may be initiated (e.g., by the apparatus) by sending a first AKMA request over the first access device and a Ua protocol may be run (e.g., by the apparatus) over the first access device and the specified access device based on keying material bound to the first core network of the first access device.

According to a sixth option that may be combined with any of the first to fifth options or any of the first to fifth aspects, an indication of the operation mode of the access device may be received (e.g., by the apparatus), which may include at least one of regenerative, transparent, or mixed regenerative/transparent operation mode as well as store-and-forward mode, and storage time of the specified access device when working in store-and-forward mode, wherein suitable communication parameters may be selected (e.g., by the apparatus) based on the received indication, when performing the authentication procedure and/or setting up the communication connection.

According to a seventh option that may be combined with any of the first to sixth options or any of the first to fifth aspects, an authentication procedure identifier and/or a timing value may be included (e.g., by the apparatus) in fields of messages of the preferred authentication procedure, and the fields may be used (e.g., by the apparatus) to differentiate messages of different security procedures and/or to determine whether a receive message has been stored by the access device.

According to an eighth option that may be combined with any of the first to seventh options or any of the first to fifth aspects, a communication link may be initiated (e.g., by the apparatus) or a request to setup a communication link with a remote user equipment may be initiated (e.g., by the apparatus), the communication link may be established (e.g., by the apparatus) using the first and/or selected access device as a relay, and the relay may be used (e.g., by the apparatus) in either transparent or regenerative or store-and-forward relay communication mode to communicate with the remote user equipment.

According to a ninth option that may be combined with any of the first to eighth options or any of the first to fifth aspects, the first access device or the specified access device may be a satellite or an unmanned aerial vehicle or a vehicle.

According to a tenth option that may be combined with any of the previous options, the method comprises: the apparatus receiving a command from the first core network through the first access device to establish a multipath connection over the first access device and a specified access device and/or a second core network using a set of configuration parameters for the multipath connection; if not yet connected to the specified access device and/or second core network, the apparatus connecting to the specified access device and/or the second core network; and the apparatus starting the multipath connection for one or more services over the first access device and the specified access device and/or the second core network by applying the set of configuration parameters.

According to an eleventh option that may be combined with any of the previous options, the method comprises the apparatus receiving 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 yet connected to the specified access device, the apparatus connecting to the specified access device; and starting the connection for one or more services over the specified access device.

In accordance with another option, the apparatus may perform the preferred authentication procedure with the first core network using a first SIM and connecting to the specified access device and/or the second core network using the credentials in a second SIM.

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.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings:

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; and

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

Fig. 4 schematically shows block diagrams and communication paths through multiple networks and/or through different radio access technologies;

Fig. 5 schematically shows a user-plane communication protocol stack to enable communication with a UE through a mobile access device in a transparent manner;

Fig. 6 schematically shows a control-plane communication protocol stack to enable communication with a UE through a mobile access device in a transparent manner;

Fig. 7 schematically shows a user-plane communication protocol stack to enable communication with a UE through a mobile access device in a regenerative manner;

Fig. 8 schematically shows a user-plane communication protocol stack to enable communication with a UE through a mobile access device in a regenerative manner;

Fig. 9 schematically shows a procedure for a secure distribution of SIB 19;

Fig. 10 schematically shows a procedure for the secure distribution of the contents of SIB19 to authorized devices;

Fig. 11 schematically shows block diagrams and communication paths through multiple networks;

Fig. 12 schematically shows an architecture of a (mobile) access device according to embodiments;

Fig. 13 schematically shows the functionalities that may be available in the different communication paths as supported by a (mobile) access device according to embodiments;

Fig. 14. schematically shows a procedure to authorize a (mobile) access device to act as a relay device according to some embodiments;

Fig. 15 schematically shows a multi -hop communication over mobile access devices according to some embodiments of the invention;

Fig. 16 schematically shows a handover procedure of mobile access devices according to some embodiments of the invention;

Fig. 17 schematically shows a handover procedure of a DualSteer device according to some embodiments of the invention;

Fig. 18 schematically describes the components of a DualSteer device;

Fig. 19 schematically describes procedures for positioning a UE via a first and a second mobile access device during a handover procedure;

Fig. 20 schematically describes a further procedure for positioning a UE via a first and a second mobile access device during a handover procedure; and

Fig. 21 schematically shows a wireless system based on cellular networks.

DETAILED DESCRIPTION OF EMBODIMENTS

The International Telecommunication Union (ITU) defines the TI (Tactile loT) as an internet network that combines ultra-low latency with extremely high availability, reliability and security. The mobile internet allowed exchange of data and multimedia content on the move. The next step is the internet of things (loT) which enables interconnection of smart devices. The TI is the next evolution that will enable the control of the loT in real time. It will add a new dimension to human-to- machine interaction by enabling tactile and haptic sensations, and at the same time revolutionise the interaction of machines. TI will enable humans and machines to interact with their environment, in real time, while on the move and within a certain spatial communication range.

IEEE publication P1918.1, “Tactile Internet: Application Scenarios, Definitions and Terminology, Architecture, Functions, and Technical Assumptions” demands that cellular 5G communication systems shall support a mechanism to assist synchronisation between multiple streams (e.g., haptic, audio and video) of a multi-modal communication session to avoid negative impact on the user experience. Moreover, 5G systems shall be able to support interaction with applications on user equipment (UE) or data flows grouping information within one tactile and multi-modal communication service and to support a means to apply 3rd party provided policies for flows associated with an application. The policy may contain a set of UEs and data flows, an expected quality of service (QoS) handling and associated triggering events, and other coordination information.

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.

The following use cases UC1 to UC17 are captured in TR 22.841:

UC1 [PR 5.1.6-001] The 5G System shall support a mechanism to steer, split, and switch the user plane traffic over two 5G satellite access networks belonging to the same PLMN, where the user plane traffic is anchored in the 5GC.

UC2 [PR 5.2.6-001] The 5G system shall be able to support mechanisms to enable steering and splitting of UE’s user plane traffic (of the same data session) across two different PLMNs each having a 3GPP access network (e.g. both using NR) and a 5G core network.

[PR 5.2.6-002] The 5G system shall be able to support mechanisms to enable switching of UE’s user plane traffic (of the same data session) for seamless mobility from one PLMN to a different PLMN, each having a 3GPP access network (e.g. both using NR) and a 5G core network.

UC3 [PR 5.3.6-001] The 5G system shall be able to support mechanisms to enable steering, split and switch of UE’s user plane traffic of one data session across two 5G networks (e.g., both using NR access) belonging to two different PLMN operators (one of which is HPLMN), or between the HPLMN and a Standalone Non-Public Network (SNPN).

UC4 [PR 5.4.6-001] The 5G system shall be able to support mechanisms to enable steering, split and switch of UE’s user plane traffic of one data session across two 5G networks (e.g., between NR terrestrial and satellite RATs) belonging to two different PLMN operators (one of which is the HPLMN).

UC5 [PR 5.5.6-001] Based on operator policy, the 5G system shall be able to support UE’s simultaneous data transmission pertaining to the same data session across two 3GPP 5G access networks (using at least one NR satellite RAT), and optimally distribute user traffic between the two access networks, taking into account connectivity conditions on both access networks (e.g., radio characteristics, mobility, congestion) and UE’s moving speed.

[PR 5.5.6-002] When two 5G access networks are used simultaneously for the same data session, the 5G system shall be able to collect charging information, for both links simultaneously.

UC6 [PR 5.6.6-001] With the mutual agreement, the 5G system shall support a mechanism to steer UE’s user traffic across different 3 GPP access network and core network for UE with dual 3 GPP access, considering service preference, traffic characteristics, radio characteristics, quality of service (QoS) etc.

[PR 5.6.6-002] With the mutual agreement, the 5G system shall support seamless service continuity by switching and splitting user traffic paths across different 3 GPP access network and core network for UE with dual 3GPP access (e.g., NR and Satellite access) in use, based on network availability, service preference, etc.

UC7 [PR 5.7.6-001] The 5G system shall be able to support mechanisms to enable dynamically steering, split and switch of UE’s user data of one application across two 3 GPP access networks (e.g., using NR and E-UTRA RATs) of the same PLMN operator, in order to meet the QoS requirement of the data application.

UC8 [PR 5.8.6-001] Based on operator’s policy, the 5G system shall be able to support mechanisms to enable steering and switching of UE’s user data, pertaining to the same application, across two 3GPP networks (e.g., anchored in a combined NR/5GC and E- UTRA/EPC) of the same PLMN operator, using single subscription and including traffic duplication over the two networks, e.g. for higher reliability.

UC9 [PR 5.9.6-001] The 5G system shall be able to support simultaneous data transmission across two 3GPP networks for the same data session, using satellite access and terrestrial access (e.g., via a gNodeB or an integrated access and backhaul node (lAB-node) mounted on an unmanned aerial vehicle (UAV)) while considering QoS requirements between these two 3 GPP networks.

[PR 5.9.6-002] The 5G system shall be able to collect charging information for simultaneous data transmission pertaining to the same user data session across two 3GPP networks.

UC12 [PR 5.12.6-001] The 5G system shall be able to support mechanisms to enable data aggregation of UE’s user data across two 3GPP networks belonging to the same PLMN, two PLMNs, or a PLMN and a SNPN, where each PLMN is a VPLMN. In case of inter- VPLMN scenarios, user data shall be anchored in the HPLMN’s core network. In case of intra- VPLMN scenarios, user data can also be anchored in the Visting PLMN (VPLMN), i.e. using VPLMN local breakout.

UC13 [PR 5.13.6-001] The 5G system shall be able to support means to transition from a UE data connection related to single subscription using two 3 GPP networks to a connection using 3GPP and non-3GPP access (e.g., ATSSS (Access Traffic Steering, Switching and Splitting)), and vice versa.

UC14 [PR 5.14.6-001] The 5G system shall be able to support mechanisms to allow a home PLMN to provide a UE with policies for the UE to connect to an additional PLMN with potentially a different RAT or to an additional RAT within the same PLMN for splitting, steering or switching of traffic pertaining to the same data session that is sent across these two access networks.

UC15 [PR 5.15.6-001] Based on operators’ policy, the 5G system shall be able to support mechanisms to enable dynamic steering, splitting and switching of a UE’s user data, pertaining to a single data session, between a Public Network Integrated NPN (PNI-NPN) and a PLMN, each having a different 3 GPP access network, to meet UEs’ QoS requirements when accessing PNI-NPN services, assuming the UE has a subscription with PNI-NPN.

UC17 [PR 5.17.6-001] Based on network providers agreed data routing policies, the 5G system shall be able to support mechanisms to allow splitting, steering and switching of loT devices data traffic (of the same data session), which is anchored in the 5GC in the HPLMN, across two access networks e.g. NTN and TN.

[PR 5.17.6-002] Based on data usage on both access networks, the 5G system shall be able to collect charging information for the loT devices.

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.

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.

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;

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.

UE-Satellite-UE Communication: refers to a communication between UEs under the coverage of one or more serving satellites, using satellite access without the user traffic transiting through the ground segment;

Inter-Satellite Links (ISL) and Feeder link may act only as transport layer links. Store and Forward Satellite Operation may work without ISL.

NR UE-Satellite-UE communication may include IMS services including multimedia telephony (MMTEL) services and mission critical communications.

The enhancement for NR UE-Satellite-UE communication may assume a minimum set of core network entities, including at least UPF, is present onboard of the satellites; the serving satellite will be of MEO or of LEO type. Furthermore, NR UE-Satellite-UE communication for MMTEL service assumes communication between two UEs under the coverage of the same satellite or different satellites.

The 5GC and EPC architecture for satellite access in TS 23.501 and TS 23.401 are considered as the baseline and it is assumed that at least eNB/gNB may be on board of a satellite.

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.

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.

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.

Dual steer: basic introduction

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.

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

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.

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

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.

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., Uu interfaces in 5G) are provided between the RAN 106 and the first and second UEs 100,103.

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.

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.

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.

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

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.

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.

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.

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

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

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

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).

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.

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. Given the above architectures of Fig. 1, different embodiments are proposed to improve the authentication and authorization procedures in cellular networks.

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.

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

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

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.

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.

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.

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.

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. 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.

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

- 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;

- 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;

- 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;

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

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

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 verify 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:

Inti:

Int3: PLMN2 (-> UE(SIM2)) -> UE(SIMl) -> PLMNI.

Int4: PLMN2 (-> UE(SIM2)) -> UE(SIMl) -> PLMNI -> PLMN2 ( -> PLMNI).

Int5: UE(SIMl) -> PLMNI -> PLMN2 (-> UE(SIM2)) -> UE(SIMl) ( -> UE(SIM2)).

Int6: (UE(SIM2) ->) PLMN2 -> PLMNI -> UE(SIM1) -> UE(SIM2) ( -> UE(SIMl)).

Int7: UE(SIMl) (-> UE(SIM2)) -> PLMN2 -> PLMNI -> UE(SIMl) ( -> PLMN1)

Int8: (UE(SIM2) -> ) UE(SIM1) -> PLMNI -> PLMN2 (-> UE(SIM2)) ( -> PLMN2)

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.

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.

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 verify that the UE 100 is connected through two different networks. Finally, PLMN1 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 PLMN 1 109, and PLMN 1 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 SIM1 101 can verily it. The fact that SIM1 101 verifies means that all entities SIM1 101 / SIM2 102 / PLMN1 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.

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.

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.

Section: Dual steer - further authentication aspects

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.

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. 3 or Fig. 11. In Fig. 11, a UE (1100) with a homePLMN 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.

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.

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.

It is to be noted that UE 1100 in previous and subsequent embodiments may be same/similar to UE 100 in Fig. 3 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.

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 verily the intention of UE 1100 of establishing the multi-path connection.

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 verily UE 1100’s registration request.

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.:

Stop the second primary authentication procedure;

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

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

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:

- reject the second primary authentication procedure,

- 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,

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

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

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.

Section: Dual steer - further registration aspects 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 3GPP access legto 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.

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.

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.

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.

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.

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.

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.

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. 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:

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.

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).

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

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

Role the serving network is authorized to take,

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).

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.

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.

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.

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

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,

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

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

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.

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.

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.

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.

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.

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.

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. 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.

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. 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. 18 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 nonterrestrial 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.

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.

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. :

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. The policy module may also notify the user, the service provider, or the network operator about the communication status and the policy execution.

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.

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

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.

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

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.

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.

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.

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.

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: DualSteer - (re)establishing of a connection with a second network triggered by the first network.

In some cases, a UE/dualsteer device may have connected to a first network and the UE/dualsteer device or the first network may determine that the delivery of a given service, e.g., a communication service, requires the usage or support of a second network, e.g., because the UE/dualsteer device has lost the connection through the first network. In this case:

In a further embodiment that may be combined with other embodiments or used independently, the first network may instruct 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”) to connect to a second network using its second SIM 102. This instruction may be done by means of a configuration message or by means of a NAS message. Additionally or alternatively, the first network may contact a second network (or RAT, e.g., a satellite network), and request the second network (or RAT, e.g., a satellite network) to provide the service to the UE/dualsteer device. This may occur, e.g., when the first network cannot reach the UE/dualsteer device. The first network may determine a suitable second network based on operator agreements or on the user subscription associated to the first and second SIMs 101 and 102 and/or location and/or time. The first network may need to retrieve the user identity (e.g., SUPI) associated to the second SIM and share it with the second network, so that the second network may search/find the UE/dualsteer device. The second network may contact the UE/dualsteer device, e.g., by sending a paging message, sending a configuration message (e.g., in a protected NAS message) and/or triggering a connection, e.g., by executing a home triggered network authentication that is used to indicate to the UE/dualsteer device that a connection through both networks is required. Upon establishment of the connection through the second network, the first network can use the services of the second network (e.g., communication services, positioning services, sensing services, etc) to keep delivering the required service.

Section: DualSteer - Negotiation of the multipath - multi-network steering role In a further embodiment related to Fig. 11 that may be combined with other embodiments or used independently, the first serving network 1101, the second network 1102 and the home PLMN 1103 negotiate which serving network is steering the multipath connection. This can include the following steps in reference to Fig. 11 :

1) The UE 1100 sends a request to the home PLMN 1103 and/or a first serving network 1101 to initiate a multipath connection over the first serving network/RAT 1101 and the second serving network/RAT 1102. The request may include information such as the QUIC or TCPLS session identifier, the available radio access technologies, the network capabilities, and the UE policy. This step may be optional if the process is not triggered by the UE.

2) The home PLMN 1103 and/or first serving network 1101 evaluate the UE need and/or UE request and determine whether to grant or deny the multipath connection for a given communication. The decision may be based on factors such as the network load, the service quality, the user subscription, and the network policy/capabilities.

3) If the multipath connection is granted, the home PLMN 1103 and/or first serving network 1101 send a response to the UE 1100 with the information of the first serving network 1101 and the second serving network 1102. The response may also include an indication of which serving network is assigned the steering role for the multipath connection. The steering role may be determined by the home PLMN 1103 or delegated to one of the serving networks 1101, 1102 based on their preferences and capabilities.

4) The UE 1100 establishes a communication connection with the first serving network 1101 and the second serving network 1102 using the information received from the home PLMN 1103. The communication connection may be split over the two serving networks using QUIC -multipath or TCPLS protocols. The UE 1100 may also exchange URSP rules with the serving networks to coordinate the traffic splitting and steering policies.

5) The serving network that has the steering role may dynamically adjust the traffic splitting ratio and change the paths for the multipath connection based on network conditions, user preferences, and URSP rules. The serving network may also communicate with the other serving network and the home PLMN 1103 to report the status of the multipath connection and the steering role. The serving network may also request or relinquish the steering role to another serving network or the home PLMN 1103 if needed.

Above and next embodiments may be used to address session management enhancements to support Dual Steer traffic steering of a new service to a 3 GPP access network and/or the DualSteer traffic switching across two 3GPP access networks belonging to the same PLMN (either HPLMN or VPLMN) or two different PLMNs or PLMN and PNI-NPN, which may further include one or more of the following:

Whether and what enhancements are required in PDU Session establishment/modification/release;

Whether and what enhancements are required for N4 session management between the SMF and UPF, or between SMF+PGW-C and UPF+PGW-U; and

For session subject to potential switching and/or to traffic steering, whether, when and how the network selects the PSA UPF(s) or UPF+PGW-U to allow routing the traffic across 3GPP access networks towards the same PSA UPF or UPF+PGW-U to support DualSteer.

Section: Dual steer - Traffic splitting in multi-path over multiple radio access technologies/networks

Fig. 2 schematically shows block diagrams and communication paths through multiple networks and/or through different radio access technologies.

In a related embodiment shown in Fig. 2, there is a communication connection and that connection is split over two different core networks 109, 114. This may be done by means of QUIC (Quick UDP (User Datagram Protocol) Internet Connections) over multipath as specified in QUIC- multipath (https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath) or TCPLS protocol (e.g., https://www.ietf.Org/archive/id/draft-piraux-tcpls-03.html#name-tcpls-tls-extensions) that allow splitting the QUIC / TCP connection over different paths. Fig. 2 describes a possible architecture wherein the 1** entities (* may be a number in the set {0,1, 2, 3, 4, 5, 6, 7, 8, 9}) are as described in Fig. 1, and:

Respective additional network functions 301, 303 of the first and second core networks 109, 114 are in charge of the session management, e.g., 5G SMF. Furthermore, a further network function 302 of the first core network 109 is in charge of the multi-path management within a network, a still further network function 304 is in charge of the multi-path management at the data origin, e.g., the AF 119, or network where paths split, etc., and an additional function 305 atthe UE 100 is in charge of the multi-path management at the UE side, wherein two possible paths 306 and 307 may include a standard communication path 307 over the access device 106 (such as a 5G gNB) and may include a non-terrestrial network communication path 306 over a satellite as the other type of device 123 of Fig. 1.

Note that the above may also indicate a dual-connectivity setup wherein the two paths

306, 307 may be two dual-connectivity paths, a path going over a terrestrial access device and another path going over a non-terrestrial access device.

In this case, a network (e.g., the first core network 109) wishing to enable multipath may command 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”) (or the AF 119) to setup a multipath communication connection, e.g., a QUIC multipath communication connection, e.g., by means of a NAS command.

In this case, the UE/dualsteer device 100 (or the AF 119) requiring a multipath communication connection may signal/indicate to the first network (e.g., the first core network 109) the need to setup a multipath connection. The first network may then, e.g., enable a new RAT in the UE/dualsteer device 100 (e.g., a non-terrestrial based RAT) or the first network may indicate to the UE/dualsteer device 100 that a second network may be required or the first network may interact with the second network to start the multipath communication and the second network may then allocate/reserve resources for the upcoming communication.

The network (e.g., network function 302) may be aware of the type of networks to use and/or RAT so that the network may inform the UE/dualsteer device 100 / AF 119 about those features when requesting the initialization of a multipath communication. For instance, if the UE/dualsteeer device 100 is connected through the other type of device 123 (e.g., a satellite), the first access device 107 (e.g., a gateway connecting to the satellite), the first core network 109 (e.g., a network managing the connection), and the connection is managed by the network function 302, the first core network 109 may be aware of services offered by other networks, e.g., the second core network 114 that may offer a RAN including e.g., a mobile base station or UAV. The (primary) first core network 109 (e.g., the additional network function 302) may request the (secondary) second core network 114 to provide connectivity services. The (primary) first core network 109 may indicate/provide the area where additional (communication/sensing/positioning/...) services are required. The (secondary) second core network 114 may provide information about when/where additional (communication/sensing/positioning/...) services can be provided, e.g., based on the mobility pattern of mobile access devices such as a gNB mounted on the other type of device (e.g., a UAV, satellite, etc.). The (primary) first core network 109 (e.g., the additional network function 302) may then configure/command the UE/dualsteer device 100 to connect to the secondary second core network 114 through the corresponding RAN/RAT. This may require configuring the UE/dualsteer device 100 with credentials to access the secondary second core network 114. This may be long term credentials stored in an(embedded) SIM so that the UE/dualsteer device 100 can perform (primary) authentication with the secondary second core network 114 and then start using the secondary second core network 114. This may be keying materials (e.g., a root key and/or an authorization token) that is obtained by the primary first core network 109 / additional network function 302 after interaction with the secondary second core network 114, and that the primary first core network 109 configures in / shares with the UE 100, so that the UE/dualsteer device 100 can use the keying materials to securely connect to the access device of the secondary second core network 114, e.g., after performing the random-access procedure. For instance, the UE 100 and the /AN can use the root key to authenticate/establish a secure channel, and then the UE 100 can share with the RAN (e.g., the RAN 106) of the secondary second core network 114 its authorization token.

The additional function 305 in the UE/dualsteer device 100 may then trigger the multipath communication protocol (e.g., as in Clause 3 in draft-ietf-quic-multipath-06 “Multipath Extension for QUIC” ) whereby the type of network/RAT and features may be shared for a better configuration of the different paths. For instance, the additional network function 302 of the first core network 109 may collect from secondary second core network 114 (upon request or on demand) information about the feasible service properties (QoS, maximum data rate, positioning accuracy, sensing accuracy, etc.), and use them to determine configuration parameters for the additional function 305 of the UE/dualsteer device 100, so that the additional function 305 can use these parameters when setting up the multipath service. The additional network function 302 of the first core network 109 may also consider the collected service properties to instruct the secondary second core network 114 with its specific requirements.

In a related embodiment variant, the AF 119 or a server may indicate to the (primary) network, e.g., the first core network 109, the number of required paths. For instance, in case of QUIC, if the transport parameter "active connection id limit" is negotiated as N, and the server provides N connection IDs, and the client is already actively using N paths, the limit is reached. The server (e.g., the AF 119) may share N with the (primary) network. Otherwise, the primary network may monitor the negotiation of the protocol to learn the number of required paths.

A related embodiment variant addresses scenarios in which it is required to discover and manage the addresses serving the multi-path connection. For instance, in Quic-multipath, each end host may use several IP addresses to serve the connection. In particular, the multipath extension supports the following scenarios:

• The client uses multiple IP addresses and the server listens on only one.

• The client uses only one IP address and the server listens on several ones.

• The client uses multiple IP addresses and the server listens on several ones.

To address this, a related embodiment variant assumes that the network function 302 in charge of multipath that is located in the primary first core network 109 may interact with the secondary second core network 114, the additional function 304 managing the multipath connection in the AF 119 (that may be an end host), and the additional function 305 managing the multipath connection in the UE/dualsteer device 100 to gather and configure the addresses for a given multipath connection. For instance, it may require the allocation of IP addresses by the secondary network (e.g., upon request by the first network). The secondary network may inform the primary network about those IP addresses. The primary network may then make them available to the additional function 304 at the AF 119 and/or the additional function 305 at the UE/dualsteer device 100. In a related embodiment variant, the network function 302 in charge of multipath, that is located in the primary first core network 109 may monitor the type/status of the paths, and provide configuration parameters that are suitable for them. According to multipath protocols such as the QUIC protocol, two main parameters may be taken into account when handling the communication of a path, Round-Trip Time (RTT) and congestion state (cf. Clause 7.1 in in draft-ietf-quic-multipath-06 “Multipath Extension for QUIC”). The additional network function 302 may be aware of the current status when commanding the UE/dualsteer device 100 and/or the AF 119 to setup a multipath communication. In other words, the additional network function 302 may send parameters that allow optimizing the communication of a path during initialization or operation of the path. These communication parameters may be multiple such as round-trip time, congestion state, congestion window size, etc.

In a related embodiment variant, the additional network function 302 in charge of multipath, that is located in the primary first core network 109 may indicate to/configure the additional function 305 of the UE/dualsteer device 100 and the additional function 304 of the AF 119 certain parameters that are to be computed to optimize the performance of the end-to-end communication over the cellular network. For instance, the additional network function 302 may indicate that the RTT may be computed in a specific way (related to Clause 7.3 in draft-ietf-quic-multipath-06 “Multipath Extension for QUIC”), e.g., acknowledgement may always be sent through the shortest path, for instance, timestamps may be used.

In a related embodiment variant, the additional network function 302 in charge of multipath, that is located in the primary first core network 109 may indicate/configure the additional function 305 of the UE/dualsteer device 100 and the additional function 304 of the AF 119 the type of packet scheduler to be used for a given path (related to, e.g., Clause 7.4 in in draft-ietf-quic-multipath- 06 “Multipath Extension for QUIC”), the preferred retransmission strategy for different paths (related to, e.g., Clause 7.5 in in draft-ietf-quic-multipath-06 “Multipath Extension for QUIC”), the path maximum transmission unit (MTU) to be used in different paths (related to, e.g., Clause 7.6 in in draft- ietf-quic-multipath-06 “Multipath Extension for QUIC”), preferred strategy for keep alive in different paths (related to, e.g., Clause 7.7 in in draft-ietf-quic-multipath-06 “Multipath Extension for QUIC”), connection parameters (e.g., connection ID, etc),

In a related embodiment variant, the additional network function 302 in charge of multipath, that is located in the primary first core network 109 may monitor the status of the paths. For instance, the additional network function 302 may be aware that one of the paths is based on a satellite (e.g., LEO satellite) and may be aware of the reachability status of said satellite. This satellite may be the other type of device 123 as per Fig. 1. As the additional network function 302 as managing entity is aware/keeps track of the connectivity of the available paths, it can also interact with the additional function 305 of the UE/dualsteer device 100 and/or the additional function of the AF 119 to stop the process to close one of the paths (e.g., Clause 4.3 in draft-ietf-quic-multipath-06 “Multipath Extension for QUIC”).

In a related embodiment variant, the additional network function 302 in charge of multipath, that is located in the primary first core network 109 may periodically /continuously evaluate the quality of paths (e.g., round-trip time, congestion state) and manage path changing/reselection based on path quality and/or the services provided (e.g., positioning, sensing ...). For instance, the additional network function 302 may be aware that one of the paths makes use of a satellite (e.g., LEO). Based on the satellite’s (e.g., other type of device 123) position, path, and velocity, and that of the served UE 100, the additional network function 302 may estimate the time window during which the satellite link/path offers the best service (e.g., while the satellite is above the local horizon of the UE 100), and consequently the point in time in which the link may start to deteriorate. Based on this, the additional network function 302 may program the path change/reselection and instruct the UE/dualsteer device 100 to change the path accordingly. The primary first core network 109 may share contexts, keying materials (e.g., cryptographic keys, authorization tokens) with the entities involved in the new path to optimize link establishment.

Above embodiments may also be applicable to a system in which 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 first establish a PDU session by means of a first protocol stack (as in Fig. 18), e.g., based on TS 23.502 Clause 4.3.2.2.1, and if the PDU session is successfully established, and the core network indicates that a connection over multiple networks / RATs is allowed, then a second PDU session for the second protocol stack (as in Fig. 18) may be established. Once this second PDU session is established, the UE/dualsteer device may communicate using the PDU sessions over two RATs / networks. Prior to establishing this double PDU session, the UE/dualsteer device needs to register to both RATs / networks. This combined PDU session may be identified by the SUPIs / SIMs used for the connection over both RATs / networks. The first step to establish a first PDU session by means of the first protocol stack may include the fact that this is a request to establish a communication link (PDU session) over a first RAT / network, it may include other information such as PDU session ID, DNN, S-NSSAI. The request type may be a “DualSteer PDU request”, i.e., a request to establish a communication link over multiple networks / RATs. The step to establish the second PDU session by means of the second protocol stack may include the fact that this is a request to establish a communication link (PDU session) over a second RAT / network, it may include other information such as a related communication link (the first PDU session), a PDU session ID, DNN, S-NSSAI. The request type may be a “DualSteer PDU request”, i.e., a request to establish a communication link over multiple networks / RATs. The sending of these requests may be triggered by a policy (e.g., URSP rules) on the device.

Section: Dual steer - Impact on AKMA when executed over two networks In a related embodiment, 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 choose (e.g., based on configuration) to perform a given procedure, e.g., AKMA, based on the credentials from one or more SIMs. For instance, in the case of AKMA, based on the current security context (e.g., K AUSF, K AKMA) established with one of or each of the networks (e.g., the first and second core networks 109 and 114).

In a related embodiment variant, the UE/dualsteer device (e.g. UE 100 /dualsteer device which may include a first SIM and a second SIM that may be operated by two “logical UEs”) may include an indication to a NF, e.g., the AF 119, and or the first and second core networks 109, 114 about the credentials to use in the required services, e.g., the AKMA services. The UE/dualsteer device 100 may also indicate whether the required service should be performed in a multi-path manner, e.g., over two different networks.

In a related embodiment related to AKMA (cf. TS 33.535), if AKMA is used over two different networks (e.g., the first and second core networks 109 and 114), it needs to be agreed which key is used as K AKMA (K AKMA a from the first core network 109 or K AKMA b from the second core network 114), and which K_AF needs to be shared with which network. This may be done by means of policy. This may also be indicated in the initial AKMA message sent by the UE/dualsteer device 100 to the AF 119. Note that different K AKMA keys are derived because each SIM has its own set of credentials (SUPI, K AUSF, etc) so that different keys maybe derived.

In a related embodiment related to AKMA, there is a secure connection enabled by AKMA (e.g., based on Transport Layer Security (TLS) or Datagram TLS (DTLS) or Object Security for Constrained RESTful Environments (OSCORE)) and the secure connection is split over two different networks (e.g., the first and second core networks 109, 114). The UE/dualsteer device 100 and the AF 119 may be configured to only start multi-path communication once the AKMA session has been established. For instance, the initial handshake to establish the secure connection (e.g., TLS handshake) may be run over a first network, and then the connection may be executed over multiple paths. This may also be enabled by means of TCPLS protocol in the case of TLS or if AKMA supports QUIC, over multipath QUIC. Note that this implies that the information exchanged over a second network/path is protected using the security context established over a first network/path.

In a related scenario, it is considered that both networks (paths) (e.g., first and second core networks 109 and 114) may need to be compliant to lawful interception requirements. A challenge in this setting refers to the fact that part of the communication takes place over the first core network 109 and part of the communication takes place over the second core network 114 so that even if each individual network may access the exchanged information (once the AF 119 provides the corresponding keys), an individual network may not be capable to access all information by itself. Thus, in a related embodiment variant, the first and second core networks 109 and 114 may negotiate/verify whether both of them have had access to security information (encryption keys, security algorithms in use, counters, etc) before allowing the exchange of information. This may require, e.g.:

(i) the additional network function 302 managing the overall connection in the first core network 109 to get a confirmation from the other network (e.g., the additional network function 303 of the second core network 114) that it will cache the communication, and when required, share it, e.g., with the additional network function 302 of the first core network 109, or directly with a lawful interception entity;

(ii) indicating two potential lawful interception entities in the first and second core networks 109 and 114 by the communication parameters of the multipath communication, e.g., a QUIC connection ID.

Furthermore, the first and second core networks 109 and 114 may need to verify that they are entitled to disclose the information if required to a lawful interception entity.

In a related embodiment variant related to AKMA, the same credentials may be used to enable two independent secure connections over both networks, and data is combined at UE/AF. For instance, the same K_AF (e.g., associated to the first core network 109) is used to authenticate both secure connections. K_AF may be as defined in TS 33.535 or it may be such that it depends on the serving network, i.e., the K_AF that is used to setup the secure connection may still depend on whether the network is the first core network 109 or the second core network 114. This can be achieved by using the network identifier as input in the derivation of K_AF.

Or alternatively, two secure connections based on the credentials of both first and second core networks 109 and 114 are set up and data is combined at the UE/dualsteer device 100 and/or the AF 119.

In an exemplary embodiment variant related to AKMA, the UE/dualsteer device 100 may choose to use K AKMA l derived from K AUSF l in PLMN1 associated to the first SIM 101 and the first core network 109. The UE/dualsteer device 100 may then derive K AF1 as in TS 33.535 based on K AKMA l in PLMN1. But for PLMN2, if the network (resources) are to be used for the same AKMA connection, the AF 119 and/or the UE/dualsteer device 100 and/or PLMN 1 may need to inform PLMN2 that K AF1 is used to protect the AKMA communication and that the AKMA communication is requested/required/allowed over PLMN2.

In another embodiment variant related to AKMA that may be combined with other embodiments or used independently, 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”) that may be a DualSteer device may have a policy determining that AKMA may only be executed based on the keys of a single SIM and AKMA related messages may only be exchanged over a single network so that multipath communication is not applied.

Section: DualSteer - cross-stack optimizations in multi-stack devices A DualSteer device as per the current definition in TS 22.841 comprises two logical “UEs” allowing for simultaneous data transmission over two networks or RATs or a single UE in case of non-simultaneous data transmission over two networks. In the context of this invention a single UE may also be used in case of simultaneous data transmission over two networks or RATs. A SIM contains the credentials of a user including the user identity (e.g., a subscription permanent identifier (SUPI)) 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.

Fig. 18 illustrates this architecture wherein 1800 refers to a DualSteer device (also denoted as UE in this description, e.g. same/similar as UE 100 as in Fig. 1 which may include a first SIM and a second SIM that may be operated by two “logical UEs”). 1804 and 1805 refer to two protocol stacks as may be present in two logical UEs (e.g. based on 3GPP Release 18 or 19). For instance, in an option the user plane protocol stack may include PHY/MAC/RLC/PDCP/SDAP layers. For instance, in another option the user plane protocol stack may include PHY/MAC/RLC/PDCP/SD AP/IP/UDP layers. For instance, the control plane protocol stack may include PHY/MAC/RLC/PDCP/RRC/NAS- MM/NAS-SM. 1806 represents a DualSteer control functionality module in charge of managing the operations of the protocol stacks. 1807 represents the optional multipath logic below the application layer or the IP layer, i.e., a layer in charge of enabling a multipath communication layer over both protocol stacks. 1803 represents the USIM management module managing at least two SIMs 1801 and 1802. SIMs may include the required credentials (keys, counters, user identities, etc). The first and second protocol stacks 1804 and 1805 may communicate directly with each other through a communication link (e.g. an API and/or hardware communication link).

In an embodiment that may be combined with other embodiments or used independently, the UE/dualsteer device 1800 may have a connection supported by both SIMs, whereby such connection may comprise a joint 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). The UE/dualsteer device 1800 may have a policy or configuration and logic to ensure that certain procedures in both stacks are performed in a coordinated manner.

In an embodiment, the logic may determine that the handover procedures for a DualSteer data connection do not happen simultaneously, but one after each other. This may be managed by a DualSteer control functionality that manages the behaviour of the communication stacks available in a UE/dualsteer device 1800 such as 1806 in Fig. 18. In other words, first the handover related to a first protocol stack (using SIM1) takes place and then the handover related to a second protocol stack (using SIM2) takes place. This embodiment improves the achieved QoS because both handovers do not happen simultaneously. For instance, the first protocol stack may connect to a terrestrial network and the second protocol stack may connect to a non-terrestrial network. This embodiment is illustrated by means of Fig. 17 where UE 1700 (which is same/similar as UE/dualsteer device 1800) contains SIM 1701 and SIM 1702, RAN 106 contains a first access device 1707 and a second access device 1708 and the core network 1709 includes network functions UPF 1710, SMF 1711, and AUSF 1712. In steps 1713 and 1713, UE 1700 performs random access to connect to the RAN 106, namely the first access device 1707. This is done for both SIM 1701 and SIM 1702 in steps 1713 and 1714. Next, UE 1700 registers and performs primary authentication with network 1709. This is done for both SIM 1701 and SIM 1702 in steps 1715 and 1716. Then in Step 1717, UE 1700 can setup a connection with the UPF 1710, e.g., based on a multipath link or other means. At a later point of time, when UE 1700 is moving and/or needs to connect to the second access device 1708, the UE

1700 applies the policy to perform the handover from the first access device 1707 to the second access device 1708 in a consecutive manner, e.g., first moving the communication link related to the first SIM

1701 from 1707 to 1708, and then when the handover is finished moving the communication link related to the second SIM 1702 from 1707 to 1708. This policy may determine that if UE 1700 has established a connection over two SIMs, the handover procedure, in its totality or partially, may not be performed simultaneously.

In the case of a handover procedure, the DualSteer control functionality module 1806 may get indications from the protocol stacks 1804 and 1805 about the points of time wherein a handover, or certain steps of the handover, may be required. For instance, if protocol stack 1804 has been configured to perform a conditional handover, the protocol stack 1804 may check with the DualSteer control functionality module whether it is allowed to perform the conditional handover. DualSteer may, e.g., only allow it if the other protocol stack 1805 does not have a concurrent handover, at least, unless protocol stack 1804 is in a critical situation requiring a handover because otherwise connectivity will be fully lost.

The DualSteer control functionality 1806 may also serve to exchange certain measurements or optimize other operations, for instance:

In an embodiment related to Fig. 17 and Fig. 18 that may be combined with other embodiments or used independently, steps 1713 and 1714 in the procedure illustrated in Fig. 17 and elaborated above may be combined in a single random -access procedure wherein UE 1700 is allocated to RAN identities (e.g., RNTIs), one for each protocol stack (using SIM 1701 and 1702). This may be done if the UE 1700 indicates in one of the random-access messages (e.g., Message 1) that it supports two SIMs (e.g., it is a DualSteer device) so that two RAN identities are allocated. In this case, a first protocol stack is requested to perform the random-access procedure on behalf of the second protocol stack. This request may be determined by the DualSteer control functionality 1806. When the first protocol stack has received both RAN identities, then the stack provides the other protocol stack the RAN identity (e.g. through communication link 1813 or indirectly through DualSteer control function 1806). This decision of performing a combined random -access procedure may be taken by the DualSteer control functionality, e.g., when it determines that the same RAN is used.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the DualSteer control functionality 1806 may gather information about the quality of the communication links (e.g., available bandwidth, QoS, link quality, round trip time of the path, etc). The DualSteer control functionality may then interfere with the Multipath logic that may use this information to, e.g., configure MPQUIC. The DualSteer control functionality 1806 may otherwise determine how application traffic is split / distributed among both protocol stacks to achieve the communication goals.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the DualSteer control functionality 1806 may steer a first protocol stack 1804 to perform certain measurements, e.g., measurements related to pilot signals such as SSBs, SIBs, PRS, etc. This information may then be exchanged between protocol stacks (1804, 1805), e.g., between the physical layers, directly or through the DualSteer functionality. This allows reducing the energy consumption of the DualSteer device.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, a first protocol stack 1804 may be in charge of retrieving on demand certain data or pilot signals, e.g., SSBs, SIB1, system information (SIB). This information may then be exchanged between protocol stacks (1804, 1805), e.g., between the physical layers, directly or through the DualSteer control functionality. This allows reducing the energy consumption of the DualSteer device and reduces the signalling requirements of the device.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, a first protocol stack 1804 may be in charge of exchanging control commands (e.g., DCI / UCI). In this case, the A second protocol stack 1805 may determine / indicate the communication needs to the first protocol stack - either directly or through the DualSteer control functionality - that may then exchange said control commands with the RAN (access device). In particular, DCI / UCI commands may be used to perform resource allocation to allocate communication resources, e.g., for downlink and uplink communication links. This has the advantage of, e.g., better synchronizing the uplink and/or downlink communication links, e.g. to achieve lower latency and/or higher reliability.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the DualSteer control functionality 1806 may be in charge of distributing the same data through both communication stacks (1804, 1805) with the goal of increasing the communication reliability.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the first protocol stack 1804 may monitor paging messages for the second protocol stack 1805. This functionality has the advantage of reducing the network traffic and reducing energy consumption.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the first protocol stack 1804 and the second protocol stack 1805 have/share a common wake-up radio that may be configured to wake-up the first and/or the second protocol stack. This functionality has the advantage of reducing the energy consumption of the DualSteer device.

Beyond 3GPP, other standardization bodies may introduce wireless devices with multiple protocol stacks. For instance, WiFi-7 / IEEE 802.11 introduces the usage of multi-link capable devices that may use 2.4 GHz, 5 GHz, and 6 GHz protocol stacks simultaneously. Thus, similar cross-stack optimizations may also be applicable there wherein, e.g., the scheduling/signaling for the 5 GHz stack is performed by means of the 2.4 GHz stack.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the DualSteer control functionality 1806 may request and/or retrieve information from both the first and second protocol stack (1804, 1805) about which networks are detected (e.g. cell IDs, network identifiers, network type) and/or measurements related to the detected networks (e.g. signal quality, signal strength) and/or information related to preferred/allowed networks (e.g. frequency bands) and/or available/allowed network slices according to the SIM profile operated by the respective protocol stack, and use this information to provide instructions to the first and/or the second protocol stack on which network/slice to select to register to or one or more preferred networks to select to register to, and/or decide whether to maintain, or terminate a DualSteer connection with a specific network by the first and/or second protocol stack. This functionality has the advantage of enabling the Dual Steer control functionality to select or provide for the most suitable networks for a DualSteer connection among the available ones detected/measured/preferred by both protocol stacks, given that both protocol stacks may operate/be configured differently (e.g. based on their respective SIM profile). Additionally or alternatively, the DualSteer control functionality forwards and/or provides a subset of the respective measurements and/or the respective information, or summary thereof between the first and the second protocol stack and/or between the second and the first protocol stack, in order for the respective protocol stack to use this information for selecting which network to register to. The DualSteer control functionality may continue to request, retrieve, forward or provide respective measurements and/or respective information from one protocol stack to the other protocol stack after one of the protocol stacks has selected and registered to a first network, in order for the DualSteer control functionality and/or the other protocol stack to be able to make an informed decision which network to select to register to. Additionally or alternatively, it allows the protocol stack that has been registered to the first network to share the measurements and/or information from the other protocol stack or subset/summary thereof with a network function that may use this information to perform the selection of a (preferred) network and/or to create a list of (preferred) networks to use for the second leg, i.e. as information to be used by the other protocol stack to select the second network to register to. To this end, the network may provide this information about the network selection of a (preferred) network and/or list of (preferred networks) via the existing communication session established via the first protocol stack. The first protocol stack may provide this information to the second protocol stack either directly through communication link (not included in the figure) or to the DualSteer control functionality 1806, which may in turn use it to instruct and/or provide/forward information to the second protocol stack which (preferred) network the first network has selected. Additionally or alternatively, the first protocol stack may provide information (e.g. slices used) and/or measurements (e.g. latency, bandwidth, frequency band, QoS) related to its connection with the first network to the second protocol stack either directly through communication link or to the DualSteer control functionality 1806, which may in turn use it to instruct and/or provide/forward information to the second protocol stack e.g. on which network to select by the second protocol stack.

Additionally or alternatively, the first protocol stack may request and/or retrieve information from the second protocol stack about the detected networks/measurements, e.g., indirectly or directly through communication link. A network may refer to one or more of a combination of a radio access technology, a PLMN, a network operator, etc. This functionality has the advantage of enabling the first protocol stack to select or provide for the most suitable network among the available ones detected and/or measured by the second protocol stack for a DualSteer connection. For example, the first protocol stack may request information about the network identifiers, cell IDs, network type, signal strength, latency, bandwidth, frequency bands or quality of service of the networks detected and/or available/allowed network slices by the second protocol stack. Based on this information, the first protocol stack may decide whether to initiate, maintain, or terminate a DualSteer connection with a specific network. Additionally or alternatively, the first protocol stack may share this information with a network function that may use this information to perform the selection of a (preferred) network and/or to create a list of (preferred) networks to use for the second leg, i.e. as information to be used by the other protocol stack to select the second network to register to, after which the network function may provide this information about the network selection of a (preferred) network and/or list of (preferred networks) to the first protocol stack via the existing communication session established via the first protocol stack. The first protocol stack may provide this information to the second protocol stack either directly or to the DualSteer control functionality, which may in turn use it to instruct and/or provide/forward information to the second protocol stack which (preferred) network the first network has selected.

Additionally or alternatively, the AMF or RAN may send as part of an RRC or NAS message (e.g. via the existing communication session established via the first protocol stack with a first primary network) a request for the UE/dualsteer device 1800 to provide a list of discovered networks (e.g. Cell IDs and/or PLMN IDs of the networks from which the UE/dualsteer device 1800 received SIB information) and/or to provide information on which networks in a list of secondary networks (that may be provided by the AMF or RAN to the UE/dualsteer device 1800) are available to the UE/dualsteer device 1800 (e.g. can be discovered by the UE/dualsteer device 1800), possibly together with measurement information (e.g. signal quality, signal strength) of the discovered networks, and/or provide location information of the UE/dualsteer device 1800 (e.g. GNSS position). The UE/dualsteer device 1800 may respond to such request by transmitting an RRC or NAS message containing one or more of the requested information (e.g. using the procedures as mentioned earlier, e.g. obtaining by the first protocol stack information about discovered networks and/or measurements related to discovered networks from the second protocol stack). Based on the information provided by the UE/dualsteer device 1800, the network (e.g. RAN, AMF, or a NF/AF responsible for determining Steering-of- Roaming information to be provisioned/updated to the UE/dualsteer device 1800) can determine a subset of the list of (preferred) secondary networks and/or select the (preferred) secondary network that the UE/dualsteer device 1800 needs to register with from a list of candidate secondary networks, and/or determine an additional network to be added to the list of secondary networks, and based on this determination send an updated list with candidate networks (possibly including the rules/conditions to access them) in a response (e.g. the second message or another intermediate message) to the UE/dualsteer device 1800. Based on the response received from the network, the UE/dualsteer device 1800 may determine whether to perform the secondary registration and/or may determine which second network to use/search for to perform the secondary registration. Additionally or alternatively, the network function that received the information related to which networks the UE/dualsteer device 1800 has discovered and/or measurements related to the discovered networks may forward this information or summary/subset thereof and/or provide the determined subset of the list of (preferred) secondary networks and/or the selected (preferred) secondary network to one or more of the discovered networks (e.g. by the AMF of the first network communicating with the AMF of a discovered network, or by a NF of the first network communicating via NEF or SBI with a NF of the second network). Additionally or alternatively, a network function of the first network (e.g. AMF) to which a UE/dualsteer device 1800 is registered may provide information about that UE/dualsteer device 1800 to one or more other networks (e.g. a set of identifiers related to that UE (e.g. a list of SUPIs of one or more subscriptions of that UE), PDU session ID used by the UE/dualsteer device 1800 for communicating with the first network or a related ID (e.g. an identifier to indicate/correlate multiple PDU sessions from a UE/dualsteer device 1800 over a first and/or second network), a set of network slices that a UE/dualsteer device 1800 is using or is allowed or not allowed to use for a secondary registration, a list of capabilities of that UE/dualsteer device 1800 (e.g. indicating support for dual registration and/or traffic splitting/switching/steering over two networks, list of supported frequency bands), a list of services that a UE/dualsteer device 1800 may use over the primary and/or secondary connection), for example to one or more networks registered for dual connectivity/dual registration (e.g. secondary network linked to first and/or second subscription data for that UE in the UDM) and/or one or more networks for which information has been provided by the UE/dualsteer device 1800 that they have been discovered by the UE/dualsteer device 1800. This enables the discovered networks to prepare for incoming connection from the UE/dualsteer device 1800 for secondary registration. For example, based on the information received from the first network, a second network may add/remove one or more slices to/from the allowed slice list for the UE/dualsteer device 1800, update RAN policies, reserve/schedule some resources for the UE/dualsteer device 1800, perform beamsteering of one or more cells towards the UE/dualsteer device 1800 location, transmit (e.g. by broadcasting an (updated) SIB) to one ormore UEs (e.g. by a cell in vicinity of the UE/dualsteer device 1800, for example based on UE location information and/or cell ID received from the first network) that may be received by the second protocol stack) some information such as information about the first network registration of the UE/dualsteer device 1800 (e.g. network ID of the first network) or about one or more candidate second networks for the UE/dualsteer device 1800 to register to.

In an embodiment related to Fig. 18 that may be combined with other embodiments or used independently, the first protocol stack 1804 of a UE/DualSteer device 1800 may receive a message/configuration/RRC message (e.g., MAC IE) that may be applicable to both the first and second protocol stacks (1804, 1805). Upon reception, the first protocol stack 1804 may share the information with the second protocol stack 1805. The RAN may be aware that the device is a DualSteer device and thus, it may be configured to share/send said messages/configurations only with the first protocol stack or the second protocol stack or both while sending it only to a single protocol stack may allow optimizing the communication/saving energy. For instance, the message may refer to the timing/configuration of on-demand SSBs distributed by a cell, and this message/configuration may be sent to the first protocol stack only, and the first protocol stack may share this message/configuration with the second protocol stack This may require informing the radio access network (RAN) (e.g., a cell) about the fact that a device is a DualSteer device comprising two protocol stacks and whether those protocol stacks are configured/adapted to share/communicate internally certain measurements so that the RAN and/or UE can optimize the communication overhead as well as energy consumption of RAN and UEs/Dualsteer devices. A UE/Dualsteer device (e.g. 1800) and/or the protocol stack (e.g. 1804 or 1805) may inform the RAN and/or CN about its configuration, e.g., in the UE capabilities, so that the RAN and/or CN can adapt their behavior. Additionally or alternatively, the RAN and/or CN may configure a UE/Dualsteer device with a specific configuration.

Section: DualSteer - Steering of roaming information

In an embodiment (SoR DS) that may be combined with other embodiments or used independently, a DualSteer device (e.g. 1800, 1700, 100) may be pre-configured (e.g. stored as part of (e)SIM profile) with and/or may receive from the network (an update to) Steering-of-Roaming information as specified in 3GPP TS 23.122. In order to enable DualSteer functionality, the SoR information (e.g. pre-configured at the DualSteer device or provided by network, e.g. by an Steering- of-Roaming Application Function) may comprise a set of combinations of networks (e.g. tuples consisting of (primary network identifier, secondary network identifier) that are allowed for a DualSteer device. The DualSteer device can use information to initiate secondary registration to a second network after successful primary registration to a first (i.e. primary) network whereby the second (i.e. secondary) network is selected based on whether the SoR information contains a valid combination of the second network with the first network. The SoR information may contain one or more conditions for selecting a secondary network and/or whether or not secondary registration (in general or to a particular secondary network) is allowed, whereby the condition may be associated with a list of secondary networks, a list of compatible networks or with a combination of networks (e.g. from the set of combinations of networks (e.g. tuples consisting of (primary network identifier, secondary network identifier)). Examples of such conditions may include location related conditions (e.g. only valid in certain tracking areas, geographical areas), signal quality related conditions (e.g. only allow registration to a certain (combination of) network(s) if the signal strength (of one or more networks) is above a certain threshold), QoS related conditions (e.g. allow registration to secondary network if certain QoS parameters/values (e.g. 5QI value or sustained data rate or certain maximum error rate) are required for a PDU session), temporal conditions (e.g. only valid during certain time periods), availability conditions (e.g. certain networks being available/forbidden or not being available/forbidden), emergency conditions (e.g. PDU session to be established over multiple networks if the DualSteer device is involved and/or needs to set up emergency communication), and the like.

Section: Multiple networks / RATs and PC5 interface

3GPP specification TR 22.841 considers that a UE may exchange data through different networks/RATs. A particular case of interest refers to a UE that may receive data from and/or when registered to two networks wherein one of the communication interfaces/RATs is a PC5 interface. This may be, e.g., the second UE 103 in Fig. 1 that is connected to the first UE 100 via PC5 link 120 and to the RAN 106 via Uu link 122. In this case, the PC5 link 120 may be served by a first network and the Uu link 122 may be served by a second network.

A use case for such a situation is that the second UE 103 is connected via the PC5 link 120 to the first UE 100 and may have temporary connectivity to the RAN 106 via the Uu link 122, e.g., the RAN 106 may be a UAV or a mobile gNB. Establishing the connection via the Uu link 122 may be beneficial in cases where the second UE 103 may require the exchange of more data, e.g., a software update. Such a bulky exchange may take a long time over the PC5 link 120, but it may be done more efficient over the Uu link 122 when the RAN 106 is available.

This may be implemented a similar way as in the embodiments related to Fig. 2 whereby the first UE 100 may usually be connected via the Uu link 120. A network function of entity in the primary first core network 109 (e.g., the additional network function 302 of Fig. 2) is aware of the fact that an access device of the secondary second core network 114 may be available soon. Then, the primary first core network 109 may instruct the UE 100 to access the access device of the secondary second core network 114. This may require the network function in the primary first core network 109 (e.g., the additional network function 302 of Fig. 2) to subscribe or receive information about the access devices managed by the secondary second core network 114 at a given location and/or time.

Section: ATSSS-based multipath communication based on ATSSS (Access Traffic Steering. Switching and Splitting)

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

The procedures may be based on the architecture reference model for ATSSS support as described in Clause 4.2.10 in TS 23.501 V18.2.1. In particular, Fig. 3 represents a slightly different view of the paths compared to Fig. 2. In Fig. 3, data is exchanged over two paths 306 and 307, where the first path 306 goes over the first core network 109, e.g., PLMN1, e.g., HPLMN, and the second path 307 goes over the second core network 114, e.g., PLMN2, e.g., an NPN such as an SNPN. However, in Fig. 3, the traffic is split in the first core network 109, e.g., in the home-UPF (similar to Figure 4.2.10- 3 in TS 23.501) wherein the home-UPF uses the N3 interface to forward/exchange data with the 3GPP access, e.g., the first access device 107, and the home-UPF uses an interface, e.g., N9 based, to exchange data with the UPF of the second core network 114. In this case, the home-UPF implements similar functionality as in the UPF in Figures 4.2.10-1 to 3 in TS 23.501, namely MPTCP Proxy functionality, MPQUIC Proxy functionality, ATSSS-LL functionality and PMF (Performance Measurement Functionality). Although to some extent related, there are several problems to further address including how to control functional blocks in two different (core) networks.

In an embodiment, the SMF in the home network may use the N4 interface to control both the home-UPF and the UPF of the second core network 114. Additionally, or alternatively, the SMF in the home network may interact with the SMF in the second core network 114 (e.g., through the N16 interface) to determine how to steer the UPF in the second core network 114. This requires extensions to:

(i) inform the networks/agree between the networks on the fact that the home-SMF controls a given connection in the UPF of another network; and/or

(ii) inform the networks/agree between the networks on the fact that the home-SMF controls certain communication sessions in the SMF of another network. In an embodiment (DS identifier), the UE 100 may establish a data connection through the first core network 109 first, i.e., the first path 306. The UE 100 may already have connected or may connect later to the second core network 114. The UE 100 may request a multi-access PDU (MA-PDU) session when the UE 100 is registered via two different 3GPP networks (extending Clause 5.32.1 in TS 23.501). The request may include a unique identifier generated by the UE 100 (e.g., a long identifier generated in a random way) so that both networks can identify the common MA-PDU. The identifier may also be generated by one of the networks and be forwarded by the UE 100 to the other network. The request may also be combined with/include/reused the token described in other embodiments and used by the networks to verify that the UE 100 is connected to both networks so that the MA-PDU session is only established once both networks have performed this verification. It is to be noted that the identifier may be a parameter or an identifier that is used in the data connection, e.g., PDU session ID.

In an embodiment, the first and second core networks 109 and 114 and the UE 100 may engage in a verification/negotiation procedure as described in the above embodiments to check/agree on the multipath settings and dual steering settings over both networks wherein the first core network 109 may work as the master/primary network (since the initial communication path was established through it) and the second core network 114 may work as a secondary /slave network. The home-UPF may then start the creation of a new (second) path 307 over (the secondary) second core network 114 from the home UPF to the UPF of the first core network 114 (e.g., N9 interface) wherein the UPF of the second core network 114 may then use the N3 interface to communicate with the second (3 GPP) access device 108. Alternatively, the home-UPF may then start the creation of the new (second) path 307 over the second core network 114 from the home UPF to the second (3GPP) access device 108 of the second core network 114.

Section: Dual steer - Lawful interception

In lawful interception use cases, both first and second core networks 109 and 114 may be accountable for lawful interception. The primary first core network 109 may have access to all information, but the secondary second core network 114 may not (because it is only exchanging part of the data). To address these needs, one or more of the following approaches may apply:

(i) The secondary second core network 114 may indicate to a lawful interception authority that primary first core network 109 is in charge of data collection for lawful interception. It may do this before agreeing on the exchange of data. The secondary second core network 114 may only agree to perform the multi-path task once it got confirmation (e.g., from the lawful interception authority or primary network) about the lawful interception support.

(ii) The Secondary second core network 114 may request the primary first core network 109 for a “copy” of all exchanged data over the first communication path 306 so that the secondary second core network 114 may provide this information to a lawful interception entity if requested. This may be especially applicable for the case in which the primary and secondary networks are, e.g., in different countries, and thus, different lawful interception authorities may require access to the exchanged data.

(iii) If the security of the exchanged data over the first and second paths 306 and 307 depends on keying materials, security information, ciphersuites established/stored in the primary first core network 109, the secondary second core network 114 may request the primary first core network 109 to receive these keying materials, security information, ciphersuites so that the secondary second core network 114 can provide this information to a lawful interception entity if required. This exchange/provisioning of security parameters may be required before the communication takes place so that the communication exchange over the secondary second core network 114 only happens if the secondary second core network 114 is in the possession of the security parameters.

Section: Dual steer - adaptation of communication parameters

In an aspect of the invention, the secondary second core network 114 and the primary first core network 109 may wish to adapt the parameters of the communication paths. To this end, primary and secondary networks may (request) exchange parameters (also known also rules, configuration or policy) including:

Required/available/configured data rate, Required/available/configured latency requirements, Required/available/configured frequency band, Required/available/configured timing, where “required” means that network A tells network B that parameter X is required, “available” means that network A tells network B that parameter X is available, and “configured” means that network A tells network B that parameter X is configured. Since these parameters may be agreed between the networks beforehand, the networks (e.g., primary network) may also indicate to the UE 100 or the AF 119 the agreed parameters. This indication may be done by means of one or more configuration messages, e.g., NAS messages. The UE 100 may use this information to determine the parameters of the multi-path communication, e.g., in QUIC. This may be a simpler approach than requiring the endpoint, e.g., the UE 100, to determine latency or bandwidth of the paths by itself and based on it, determining how to configure the different communication flows for each of the paths. The configuration messages may be coming from the primary network or from the primary and secondary networks. The configuration message may include the multi-path session (e.g., MP-PDU) identifier and associated communication parameters.

In 3GPP specification TS 23.501, Clause 4.2.10, it is stated that the UPF supports performance measurement functionality which may be used by the UE 100 to obtain access performance measurements (as in TS 23.501, clause 5.32.5) over the user-plane of 3GPP access and/or over the userplane of non-3GPP access. In the case of multiple networks and/or when an access network is satellitebased etc., it is important that performance is not only based on measurements of the local conditions, but on expected behaviour of the network. For instance, if a network delivers data over a satellite link or a mobile access device, the mobility pattern of the device may impact the performance. This information (expected performance at a given time) may be shared with/used by the UE 100.

Thus, in an embodiment (DS NTN conf) that may be combined with other embodiments or implemented independently, after the establishment of a MA PDU Session, and when there are user-plane resources on both access networks, the UE 100 may apply network-provided policy (i.e. ATSSS rules) and may consider local conditions (such as network interface availability, signal loss conditions, user preferences, etc.) as well as connectivity conditions of the networks / access network for deciding when and how to distribute the uplink/downlink traffic / manage a service across the two or more access networks. For instance, the ATSSS rules may include expected timing of availability, location availability, signal strength, expected performance (RTT, jitter, bandwidth, ...). This allows the UE 100 to execute the rule in advance and take the decision of splitting the traffic in a specific way before some local conditions arise (e.g., loss of connectivity). This embodiment may be applicable to Clause 5.32.8 in TS 23.501 and also applies to UEs that connect/are connected to a single core network.

In another embodiment that may be combined with other embodiments or used independently, in NTN-network scenarios, the communication path to the UE 100 (e.g., based on TCP or QUIC connection) may be divided into multiple segments for enhanced performance, e.g., there can be a connection segment UE-NTN gateway and connection segment NTN gateway - UPF where the NTN gateway is the entity that handles the connection to the UE 100 over the satellite 123. This can require a protocol or one or more messages that are used to determine/agree/configure/verify whether the path connection UE-UPF over the NTN is end-to-end (UPF to UE), or split into segments (e.g., a connection UE-NTN gateway and connection NTN gateway - UPF). The CN (e.g., the first core network 109) may request a (multi-path) communication where one of the paths goes over the UE-NTN gateway. The CN may then send a request to the UE-NTN gateway to split the path into two links providing specific configuration parameters such as a congestion window. The UE 100 can then be informed or retrieve the communication configuration of this path by /from the network, in particular, hop-by-hop or not, communication parameters assigned to each of the segments. This communication path may be end-to-end between the UE 100 and the CN or it may be hop-by-hop between UE/CN and the NTN gateway (or any other entity in the path). This can allow the CN (e.g., SMF, UPF) or the UE 100 to configure, e.g, different (initial/maximum) congestion windows that enhance the certain parameters of the end-to-end performance (e.g., throughput) when the path connection UE-UPF over the NTN is split into segments. This can allow the CN (e.g., UPF) or the UE 100 to determine whether the traffic received over the NTN path is real time/delay sensitive or may have been cached for some time, e.g., at the NTN gateway. Thus, with this information, the end point (e.g., the UE 100) can determine the (multi-path) communication configmation.

Section: ATSSS - non-3GPP access

The following embodiments are defined with reference to the architectures and solutions in 3GPP TR 23.700-54 v0.2.0, in particular solutions #2.7 and #2.8 that may lack a proper mechanism for the path verification and wherein a token-based procedure as described in other embodiments may be applicable.

In an embodiment that may be combined with other embodiments or implemented independently, a UE may register to a PLMN via 3GPP access using a first PDU session establishment procedure. During the first PDU session establishment procedure or afterwards over the established PDU session, the UE may receive (e.g. using a NAS message) IP address and port number of a UPF accessible for non-3GPP access and/or an IP address or other identity to be used by the UE and/or credentials to communicate with the network (e.g. the UPF) via non-3GPP access and/or a token for IP address validation and/or a token for QUIC path validation (or other types of token as described in other embodiments). The UE may use the received information (or a subset thereof) when the UE registers to the network via non-3GPP access or sets up a PDU session with the network via non-3GPP access. For example, it may use a token that it has received and/or an identity of the UE in a message M (e.g. registration message or PDU session establishment request message) to the UPF over non-3GPP access (e.g. using the received IP address and port of the UPF) and/or it may use credentials received from the network to protect / encrypt message M (or part of the message’s pay load) or include a Message Authentication/Integrity Code (MAC/MIC) in message M to the UPF over non-3GPP access. When the UPF receives any message on its IP address and port it has opened for non-3GPP access, it may verily if the message contains any of the above-mentioned information, and if not, it may discard the message. In some cases, message M may be received directly (e.g., once a UDP / TCP connection is established. In other cases, message M may be received only once a secure connection has been established, e.g., a TLS connection has been established so that message M can be exchanged in the TLS connection and it cannot be eavesdropped and resent by an attacker.

In some cases, if it does not contain any of the above-mentioned information the UPF may be configured, e.g., by the PCF, to block the connection. The UPF may also log the event and/or inform another network function or entity (e.g., 0AM).

In some cases, the UPF may request an additional verification or authentication check with the UE via the first PDU session via 3GPP access, e.g., when the message includes an indication of the establishment of a multipath communication and includes an indication of the UE identity. To this end, the UPF may send a message N to/via the AUSF, SMF or AMF, whereby message N may include information received from the UE in message M in order to request the AUSF, SMF or AMF to trigger a verification or authentication check with the UE via the first PDU session via 3GPP access. In some cases, the AUSF, SMF and/or AMF may only do this if the UE is configmed or is establishing a multipath communication, e.g., the SMF may have been notified about the intention of establishing a multipath connection over 3GPP and non-3GPP access. This further verification may be triggered/done by sending a message N’ (e.g. NAS message) that includes a verification or authentication check to the UE and/or the UPF may send a message O (e.g. NAS message or other type of message) that needs to be (transparently) forwarded by the AUSF/SMF/AMF to the UE to perform the verification or authorization check. The message N’ or message O may include identity information of the UE (e.g. identity information received in message M) and/or a cryptographic challenge and/or information about incoming traffic via non-3GPP access (e.g. question for device or user of the device to confirm that it has requested access to the network via non-3GPP access, possibly including timestamp information of when the UPF received the incoming message M), and/or may request to send a token/authentication value through the non-3GPP access, if the UE intends to establish, is establishing or has established that connection. Upon receiving such message N’ or O, the UE may perform the requested verification or authentication check and/or requested action and respond with message P that may be transmitted via the first PDU session (or via the non-3GPP access to the UPF via IP address/port of the UPF that was received earlier).

Additionally or alternatively, message N’ or O or subsequent message (e.g. before or after successful verification or authentication check e.g. as indicated by message P) may include credentials for the UE (e.g., in addition or instead of credentials that may have been transmitted upon establishing the first PDU session) to use in subsequent messages to the UPF via non-3GPP access (e.g. use for encryption or integrity protection). For instance, the core network may assign communication parameters (e.g., credentials such as keys or certificates or IP address) to establish the communication via non-3GPP access.

Additionally or alternatively, the UPF may verily if the message M is protected, e.g., encrypted, using credentials that it knows/trusts (e.g. because these have been supplied to the UE using the first PDU session (during initial session establishment or in message N’ or O or subsequent message) and may have been shared with the UPF as well). If not, the UPF may discard the message. The UPF may also log the event and/or inform another network function or entity (e.g., 0AM).

This embodiment is motivated because TR 23.700-54 introduces the concept of Non-Integrated Non-3GPP Access (NIN3A), a type of non-3GPP access network that provides direct IP connectivity between the UE and the UPF without any intermediate NF such as Non-3GPP Interworking Function (N3IWF) and Trusted Non-3GPP Gateway Function (TNFG). Here, UE does not register to the 5GC over this Non-Integrated Non-3GPP Access. However, the UE is still able to access 5G resources, i.e. UPF, SMF. If no security is defined, the system can be prone to unauthorized access, impersonation, and Denial of Service, thus, it is needed a solution to authenticate a UE accessing the network via nonintegrated non-3GPP access.

In an embodiment that may be combined with other embodiments or used independently, a mobile access device may incorporate certain functions of the core network, including UPF and SMF. The mobile access device may be a satellite working in store and forward mode. In this case, the method for authenticating/authorizing the UE may be based on a solution allowing a UE to access the network via non-Integrated non-3GPP access wherein when the UE needs to transmit data, the UE may connect to the mobile access device, and the UE may directly authenticate/authorize with the UPF, and upon authentication/authorization, transfer the data to the UPF.

Other embodiments have described solutions allowing a UE to authenticate/get authorized with a mobile access device, e.g., operating in store and forward mode. Such solutions may also be applicable to non-Integrated non-3GPP access. For instance, a UE may perform traditional/standard primary authentication over the 3GPP access, and the UE may obtain through the 3GPP access to some credentials. This is similar to the case wherein a UE authenticates through a first mobile access devices with a first core network. The UEmay indicate then its intention to use non-Integrated non-3GPP access, obtaining certain credentials as well as parameters to access the UPF. This indication may also be sent to a first mobile access device/core network indicating the intention of the UE to communicate over a second mobile access device at a later point of time. Similar credentials/parameters may be provided to the UE to access the UPF of the second mobile access device at a later point of time. Then finally, the provided credentials/parameters may be used by the UE to authenticate itself against the UPF. For instance, the credentials may be an authorization token or a key or a one-time password. These credentials may be exchanged when establishing an IP connection between UE and UPF, e.g., prior to the establishment of a secure channel (e.g., in the header of a security protocol such as TLS or IPSec when the secure channel is being established) and/or once the secure channel has been established. If the credentials are exchanged prior to the establishment, the system/UPF is more resilient to DoS attacks. If the credentials are exchanged after establishment of the secure channel, the system is more resilient to spoofing. It is to be noted that the UE may also send credentials to the UPF so that the UPF verifies the UE, but also the UPF may send credentials to the UE so that the UE verifies the UPF. These credentials can be seen as a type of token.

In general, it is described 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.

Aspect a) The above apparatus is further adapted to: indicate the establishment of a connection over non-3GPP access and/or a mobile access device, receive a configuration for the non-3GPP access and/or mobile access device wherein the configuration can include parameters for the authentication with the non-3GPP access and/or mobile access device, and use the configuration to perform the authentication with the non-3GPP access and/or mobile access device.

Aspect b) This apparatus of Aspect a) further adapted to: receive a configuration for the non-3GPP access or mobile access device including the IP address of a second entity (e.g., UPF) and at least one of a first token, a second token, a third token, a fourth token, and fifth token, establish an IP connection with the second entity at the received IP address, and perform one or more of the following actions: o transmit the first token (e.g., authorization token, one-time password) prior to the establishment of a secure connection with the second entity, o transmit the second token (e.g., authorization token, one-time password) after the establishment of a secure connection with the second entity, o allow the communication if a sixth token (e.g., authorization token, one-time password) is received from the second entity prior to the establishment of a secure connection matches the third token, o allow the communication if a seventh token (e.g., authorization token, one-time password) received from the second entity after the establishment of a secure connection matches the fourth token, and o use a fifth token (e.g., symmetric key, certificate) to establish a secure connection (e.g., TLS, IPSec) with the second entity, and allow the connection if the authentication step of the secure connection establishment succeeds.

Section: Dual steer - Privacy-aware agreement between networks on the allocated communication resources

In a further scenario, network A (e.g., the first core network 109) and network B (e.g., the second core network 114) may need to agree on some communication parameters. However, network A and/or B may not be willing to disclose all data, e.g., the specific number of resources that are available. The reason is that network A and network B are operated by different operators that can be considered as competitors, so that even if they may be willing to cooperate for a given task, they still want to limit what the other party learns. To achieve this, in a further embodiment that may be combined with other embodiments or implemented independently, network A and network B may run a protocol based on privacy enhancing technologies (PET) when determining whether a MA-PDU can be used for the communication with a UE (e.g., the UE 100) over two or more different networks. The PET-based protocol may be based, e.g., multi-party computation wherein two or more parties jointly compute a function without disclosing the input parameters.

For instance, assume that a user needs a given data rate DR and that network A and network B may want to determine/verify whether they can jointly provide the service without disclosing the available resources to each other. Then network A and B may want to compute a function F(DR, a, b) without having to disclose the parameter a to network B and without having to disclose the parameter b to network A, where a, b refer to the available resources in networks A and B, respectively. This function F may be privately computed by applying a two-party computation protocol, e.g., Yao’s garbled circuit protocol. For settings in which more than two parties are involved, e.g., three networks, a multi-party protocol, e.g., based on Shamir secret sharing or additive secret sharing, may be used.

In a further embodiment variant, any of the networks (e.g., the first core network 109 or the second core network 114) may indicate the need of a specific PET-based protocol and/or specific parameters for the PET-based protocol. The PET-based protocol as well as corresponding parameters may be standardized parameters. The requesting network (e.g., primary network) may indicate the supported PET-based protocol/parameters and the replying network (e.g., secondary network) may indicate the selected PET-based protocol/parameters. During this initial PET-based protocol/parameter negotiation procedure, the networks also agree on a PET-protocol session identifier that is bound to the multi-path communication (e.g., MP-PDU) that is to be established. The networks may then exchange the specific contents of the PET-based protocols in a PET-container protocol. The requesting network may send the contents of the PET-based protocol in a PET -Requester-Container message that includes a PET-Requester-Container counter to keep track of the exchanged messages. The replying network may send the contents of the PET-based protocol in a PET-Replier-Container message that includes a PET-Replier-Container counter to keep track of the exchanged messages. The counters should be unique to identify them.

Section: NTN - Communication architecture to enable UE communication or UE-to- UE communication over a (mobile) access device such as a satellite

Fig. 4 schematically shows block diagrams and communication paths through multiple networks and/or through different radio access technologies.

In some scenarios, the communication architecture described in Fig. 1 may be used to enable direct communication between two UEs, e.g., as shown in Fig. 4 where the other type of device 123 (e.g., a satellite) may provide a relayed communication link 126 between the first UE 100 and the second UE 103. In this case, the direct communication link 120 may not exist. The relayed communication link 126 may allow voice, data, etc. communication between the first and second UEs 100 and 103. The communication architecture may be based on diverse protocols, e.g., IP Multimedia System (IMS).

In IMS, the call setup is done using the Session Initiation Protocol (SIP). SIP is used to initiate, maintain, modify and terminate multimedia sessions, including voice, video, and messaging applications. The process involves the exchange of SIP messages between the user equipment (UE) starting the communication and the IMS network to establish a session. The UE sends an INVITE message to the IMS network, which then routes the message to the appropriate SIP server. The server sends a response back to the UE, which can be a provisional response, such as 180 Ringing, or a final response, such as 200 OK.

In case of the relayed communication link 126, a subset of IMS functionality, IMS network and/or SIP server may run on the other type of device 123 providing the relay. Once the session is established, media is exchanged between the first and second UEs 100, 103 and the IMS network using the Real-time Transport Protocol (RTP). In the case of relayed communication over a relay device such as the other type of device 123, multiple challenges need to be addressed including: how to verify/authorize the first and second UEs 100, 103 to use a satellite link as a relay, how to inform the satellite that it can act as a relay for said communication, how secure the direct communication between the first and second UEs 100, 103, how to ensure QoS in the communication link, etc.

In other cases, it is simply required to enable communication between a UE and the infrastructure in a way that it is possible to determine/configure the best way to enable the end-to-end communication radio access network link when the (mobile) access device may operate in different modes. In some situations, an access device such as the other type of device 123 may follow a regenerative or a transparent (NTN) architecture. In a regenerative (NTN) architecture, the access device (e.g., satellite) acts as a base station (gNB) while in the transparent (NTN) architectures, access device (satellite) works as a reflector, e.g., a. smart repeater (NCR) or reflective intelligent surface (RIS).

Fig. 5 (user plane) and Fig. 6 (control-plane) show protocol stacks for the case of a transparent NTN architecture where the “mobile access device” (MAD) refers to the other type of device 123 in Fig. 4 and “GW” refers to a gateway.

Furthermore, Fig. 7 (user plane) and Fig. 8 (control-plane) show protocol stacks for the case of a regenerative NTN architecture where the “mobile access device” (MAD) refers to the other type of device 123 in Fig. 4 and “MAD/GW-IF refers to an interface between the mobile access device and a gateway.

The advantage of the mobile access device acting as a base station (in regenerative mode) is that it is capable of taking advantage of all signalling to optimize uplink/downlink communication performance. The advantage of acting as a reflector is the lower (communication) complexity, including the lower energy requirements and lower latency. Still, these architectures may be suboptimal in some situations.

Thus, to address these challenges the following procedures may be applicable: In an embodiment that may be combined with other embodiments or used independently, the (mobile) access device may have a mixed regenerative/transparent NTN architecture, wherein the mobile access device (e.g., satellite) 123 may be configured to work based on a regenerative NTN architecture and/or on a transparent NTN architecture for certain types of communication or phases of the communication, for instance, control plane may be based on a regenerative NTN architecture and user plane may be based on a transparent architecture. For instance, a first phase of the communication may be based on a regenerative NTN architecture and a later phase of the communication may be based on a transparent NTN architecture.

In an embodiment variant that may be combined with other variants or embodiment variants or used independently, the first UE 100 of Fig. 4 may have established a communication link, e.g., a relayed direct communication link, with the second UE 103 over the mobile access device (satellite) 123 when the mobile access device 123 is working as an access device using a regenerative NTN architecture. Once this initial communication with the first UE 100 is established, the mobile access device 123 may be configured in a mixed regenerative/transparent NTN architecture in which the mobile access device 123 applies a transparent architecture for the UE-to-UE communication.

In a further embodiment variant, this mixed regenerative/transparent NTN architecture may be applicable to communications between the first and second UEs 100 and 103 or for a communication between the RAN 106 and the first UE 100 over the mobile access device 123, as indicated by the upper part of the solid bold path 128 in Fig. 4. An advantage of this architecture is the lower energy consumption in the mobile access device 123. Another advantage is the reduced latency of the communication link. For instance, the first and second UEs 100 and 103 may connect to the network using a regenerative NTN architecture and when they are required/requested to communicate with each other, the first and second UEs 100 and 103 may switch to a transparent NTN architecture, e.g., for their specific communication link. Another advantage for the usage of a transparent architecture is that the first and second UEs 100 and 103 may only need to setup a direct communication link (without an active relay device in between). This simplifies communication and security procedures.

In an aspect of this embodiment, an entity may manage the operation of the (mobile) access device 123 working in either a regenerative and/or transparent (NTN) architecture mode for either control or user plane or for specific communication links or for certain parts of the communication. For example, the conditions (e.g., RTT threshold, load/congestion threshold, availability/timing) for which communication or part thereof or timing thereof or for which communication links to apply a certain communication mode (e.g., regenerative or transparent or a mixture thereol) may be configured by the core network (e.g., the first and/or second core network 109, 114) e.g. through a policy provided by the AMF of the core network to the RAN 106 or by the RAN 106 itself. The configuration may also be provided by a ground station (e.g., in a role as gNB-CU) to non-terrestrial access devices (e.g., the mobile access device 123, which may act e.g. as gNB-DU or NCR or RIS). In an aspect of this embodiment, a given communication link or the transmission of certain data may require, e.g., very low latency and high reliability. To achieve this, the (mobile) access device may first transmit said data in a transparent manner (i.e., acting as a reflector using a transparent architecture) and then retransmit said data in a regenerative manner (I.e., acting a base station using a regenerative architecture) at least once. This approach, that may be used independently, can allow a UE to receive said data or communication faster (thanks to the transparent architecture) and more reliably (thanks to the regenerative architecture). The (mobile) access device that may be a satellite but also other type of access device, either terrestrial or non-terrestrial, with the combined capabilities of a transparent and regenerative architectures, e.g., a smart repeater and an IAB base station, may be configured to operate in such a manner for said data communication/data (re)transmission. For instance, the access device may be configured to both retransmit the data received in some given communication resources (time and frequency) transparently and regeneratively (at least once). This may be done by means of a configuration message such as a MAC command, or a RRC message. The UE receiving the data may also be configured to receive said data at least two times, a first time based on the transparent architecture of the (mobile) access device and one or more times based on the regenerative architecture. If the data is transmitted more than once based on the regenerative architecture, it is advantageous if said transmission is done at the same time or different times using different frequency bands. It is to be noted that if the access device is mobile, e.g., as in the case of a satellite, the communication/channel path changes over time, and thus, it may be subject to better communication/channel path.

In a related aspect of this embodiment, the data received in some given communication resources (time and frequency) at the (mobile) access device may be retransmitted in some other communication resources (time and frequency) transparently ((mobile) access device acting in transparent manner, transparent path) and regeneratively ((mobile) access device acting in a regenerative manner, regenerative path) whereby the communication resources used for the transparent and regenerative retransmission may not overlap, e.g., in time and frequency, to facilitate the reception at the receiver.

When the data retransmitted over the regenerative path is transmitted in a different frequency band as the data retransmitted over the transparent path, it may be advantageous if the frequency band is close, up to a guard space in terms of frequency, to the data retransmitted over the transparent path.

When the data retransmitted over the regenerative path is transmitted in the same frequency band as the data retransmitted over the transparent path, it may be advantageous if the data retransmitted over one of the paths is delayed long enough, up to a guard space in terms of time, so that it does not arrive simultaneously at the receiver. This may require using a resource allocation schema in which the resources allocated to a first path (e.g., regenerative path) have a delay with respect to the communication resources allocated to a second path (e.g., transparent path) where the delay depends on the data transmission time in the second path plus the processing time for the second path at the (mobile) access device. This may require using small data units since they include a lower transmission time.

It is to be noted that some of these considerations may not apply to, e.g., a successive interference cancelation (SIC) receiver, since, e.g., a SIC receiver may use the data (stream) arriving first (e.g., through the transparent path) to remove the interference from the data (stream) arriving second (e.g., arriving through the regenerative path) even if they overlap in time/frequency resources.

In a related aspect of this embodiment, a given communication link / data transmission using a combined transparent/re generative access device may be identified by a representative identifier of it. This can allow the access device to perform the transparent/regenerative operations on the communication link/data transmission and may allow the UE to receive and process the data accordingly. Furthermore, a configuration message may also include the time the data is scheduled to be received and/or transmitted. For instance, when the access device receives the data to be processed according to the mixed architecture and which communication resources should be used for the (re)transmission. For instance, when the UE receives the data processed/transmitted according to the mixed architecture.

In a related aspect of this embodiment, a UE may have a specific processing pipeline for this type of data communicated by means of a mixed architecture. For instance, a UE may be configured to receive the first data (forwarded in a transparent manner by the access device), and if received correctly (e.g., based on an integrity check such as the usage of CRCs or error correction codes or message integrity codes), ignore later received data (transmitted in a regenerative manner by the access device). If the first data is not received correctly, the second data may be received and processed. It may be processed independently, or combined with the first data, e.g., softly by adding the received symbols.

In a related aspect of this embodiment, the transparent and regenerative architectures may have different degrees of complexity, in other words, they may implement a different number of functionalities in the reception-transmission pipeline than described in Fig. 5-8. These functionalities - in general - may include antenna, RF front-end, low physical layer, high physical layer, low MAC layer, high MAC layer, low RLC layer, high RLC layer, PDCP layer and higher protocols and/or functionalities in a base station as in a base station split in a central unit / distributed unit as illustrated in Fig. 12. For instance, a transparent architecture may only implement the antenna and RF front-end functionalities acting as a pure RF repeater in a given configurable frequency/time band, while a regenerative architecture may implement all or some of the layers and protocols mentioned above. This may imply that a transparent architecture may forward the received data without any processing or modification, while a regenerative architecture may decode, process and re-encode the data before transmitting it. The degree of complexity may affect the performance, cost, power consumption and latency of the architectures. In another configurations/variants, the transparent architecture may include the antenna and RF front-end functionalities and low physical layer involving the decoding/encoding of the bitstream. This additional processing overhead comes with the advantage that the transparent architecture does not act as a pure RF repeater, but only the resource blocks containing information are retransmitted. In another configurations/variants, the transparent architecture may include further physical layer functionalities such as CRC and error correction. This makes sure that if certain symbols are not decoded correctly, the bit stream is corrected before re-encoding and re-transmission, ensuring a higher reliability of the end-to-end communication link.

In a related aspect of this embodiment, the mobile access device 123 may support both transparent and regenerative architectures and may operate both simultaneously or switch between them according to the communication scenario, the network conditions, the user requirements and/or the device capabilities. For instance, the mobile access device 123 may operate in a transparent mode when the channel quality is good and the data rate is low, or when the device has limited resources such as battery, processing power or memory. On the other hand, the mobile access device 123 may operate in a regenerative mode when the channel quality is poor and the data rate is high, or when the device has sufficient resources to perform the necessary decoding, processing and encoding operations, or when it is far from a satellite gateway. In general, architectures may be selected on a 'per-channel' or 'per-UE' basis. The switch between the architectures may be dynamic and adaptive, and may be triggered by the mobile access device 123 itself, by the network (e.g., the first and/or second core network 109, 114), by the UE (e.g., the first and/or second UE 100, 103) or by a combination of them.

In a further embodiment, the transparent and regenerative architectures may include different sets of layers and protocols, depending on the communication scenario, the network conditions, the user requirements and/or the device capabilities. For example, a transparent architecture may include only the antenna, RF front-end and low physical layer functionalities, while a regenerative architecture may include the antenna, RF front-end, low physical layer, high physical layer and low MAC layer functionalities as illustrated in Fig. 12. These functionalities may be implemented in hardware, software or a combination of both. The choice of the layers and protocols to be included in each architecture may affect the performance, cost, power consumption and latency of the architectures, as well as the compatibility and interoperability with other devices and networks.

The mobile access device 123 may share some of the hardware components between the transparent and regenerative architectures, such as the RF front-end or the low physical layer. This may reduce the complexity and cost of the device, as well as the switching time between the architectures. Alternatively, the mobile access device 123 may have dedicated hardware components for each architecture, which may increase the flexibility and robustness of the device, as well as the isolation between the architectures. The sharing or separation of the hardware components may depend on the communication scenario, the network conditions, the user requirements and/or the device capabilities. Fig. 13 illustrates such a split wherein 1301 represents the (mobile) access device, 1306 represent the common lower layers for both architectures, 1304 and 1305 represent the duplicated (lower) layers in the regenerative and transparent architectures, and 1302 and 1303 represent the specific (higher) layers/functionality in the regenerative and transparent architectures. This may require the (mobile) access device to indicate a gateway or access device in charge of its management its features, e.g., which components are included in 1306 and/or 1304 and or 1305. This allows the gateway or access device or a (mobile) access device management service to determine configuration parameters, e.g., a guard time required to switch from transmitting/receiving through the transparent/regenerative architectures or which port antenna should be used for the regenerative/transparent architecture/communication mode. By way of example, a (mobile) access device implemented as two physically -distinct, preferably co-located (or quasi-co-located, that is, located such that the propagation paths from each to the UE are similar) apparatuses would be managed by the network as two separate devices with resource management arranging for the two devices to share the same channel, allowing for necessary guard spaces in time and frequency. For example, the transparent path may comprise a network-controlled repeater (NCR), with the network controlling the repeater operation via the NCR- MT (NCR Mobile Termination) module of the repeater; the regenerative path may comprise an Integrated Access and Backhaul (IAB) node, with the network controlled the IAB operation via the IAB-MT module of the IAB node.

An aspect of this, which is applicable to all dual-path arrangements, is that the regenerative path typically imposes more delay on the data path than the transparent path. Advantageously, the differential delay between the paths on the transmit paths is arranged to be a whole number of transmission slots or, preferably, transmission frames with precise alignment on slot or frame boundaries. To facilitate this, the regenerative path may be configured by the network with a timing delay, offset or alignment parameter that adjusts the output timing as necessary.

By way of a second example, the two paths may be arranged to share an antenna system. In this case, while the two paths are managed as separate nodes, the antenna is managed as a shared resource. This might be done by always controlling the antenna via NCR-MT or IAB-MT or by arranging for the antenna to be controlled by whichever path has been assigned transmission or reception resources for a given time or frequency. Switching the antenna between paths may be done implicitly via the resource management or explicitly via a signal sent from the network.

By way of a third example, paths may be combined at a lower level stage, allowing both paths to share the same transmitter power amplifier. This may be advantageous because the power amplifier would not need to power down and power up between path changes, meaning that the guard space necessary in the time domain can be minimised. If the network is aware of this, it can potentially perform more efficient scheduling. The (mobile) access device may report its configuration (e.g., as part of the capabilities exposed by the mobile access device, e.g., as indicated by the mobile terminal when sending its UE capabilities in the cases in which the mobile access device includes a mobile terminal) to the network so that the network can control the (mobile) access device in a suitable way.

In a fourth example, if the (mobile) access node is implemented by a single logical node providing both transparent and regenerative paths, the network can control both paths by addressing the single (mobile) access node. From the end UE perspective, the UE still sees and interacts with the network via the transparent path and sees and interacts with the (mobile) access node via the regenerative path.

In addition, different parameters may be configured for the transparent and regenerative architectures, such as the modulation scheme, the coding rate, the transmission power, the frequency band, the channel bandwidth, the subcarrier spacing, the symbol duration, the frame structure, the numerology, the pilot pattern, the resource allocation, the feedback format, the HARQ scheme, the MIMO scheme, the beamforming scheme, the interference management scheme, the security scheme, the authentication scheme, the synchronization scheme, the data compression scheme, etc,

In an aspect of this embodiment, the mobile access device 123 may distribute system information informing a UE (e.g., the first or second UE 100, 103) or other access devices (e.g., the first and/or second access device 107, 108) about its capability to support a mixed regenerative/transparent NTN architecture. This capability may be communicated in a system information block (SIB) (e.g., SIB1 or SIB 19) or in a Radio Resource Control (RRC) message. A UE may express its choice, during the initial random-access procedure or by means of an RRC message.

In an aspect of this embodiment, the mobile access device 123 or a managing entity may inform the first and/or second UE 100, 103 or other access devices (e.g., the first and/or second access device 107, 108) or the core network (e.g., the first and/or second core network 109, 114) about the configuration of a given communication link to be in either transparent or generative mode.

In an aspect of this embodiment variant, a UE (e.g., the first and/or second UE 100, 103) may initially connect (e.g., perform random access via the Random Access Channel (RACH) or perform primary authentication) to the network using the access devices (e.g., first and/or second access devices 107, 108) in a mode, e.g., regenerative mode, and once connected, the UE / access device may switch to a different mode, e.g., communication in transparent mode when the connectivity is suitable or the communication requirements are not as demanding as to require the regenerative mode. In some situations, this communication mode switch may only be done for part of the communications, e.g., it may be done for the user plane (transparent mode), but it may not be done for the control plane; or, it may be done only for certain communication links. This may have the consequence that a device may need to associate different communication parameters to different communication links. For instance, a UE may need to apply a different timing advance depending on the communication link it is dealing with because some communication links may be directed to the (regenerative) mobile access device 123 (acting in regenerative manner) and other communication links may go through the mobile access device 123 (acting in transparent manner) to arrive to another access device. For instance, a UE may be informed or configured of those communication parameters per communication link. For instance, different communication links may be grouped in different categories, e.g., regenerative or transparent.

In an aspect of these embodiments (variants) or application scenarios, the mobile access device 123 may refer to other mobile access device(s) such as a UAV or a vehicle. In some cases, the mobile access device 123 may be static, e.g., such as a distributed unit or a IAB device or smart repeater (NCR) or reflective intelligent surface (RIS) and switch operation between, e.g., distributed unit (equivalent to a regenerative architecture) and smart repeater/NCR (equivalent to a transparent architecture) or between IAB node and smart repeater/NCR. Thus, embodiments and embodiment variants related to mixed regenerative/transparent access device architecture may also be applicable to such application scenarios.

In an aspect of these embodiments or their variants, multiple UEs (e.g., the first and second UEs 100, 103) may be connected to the mobile access device 123 when changing its operational mode. If traffic level is the trigger to switch between the modes, then there will be at least some UEs connected during the transition. The RAN 106 or core networks 109, 114 may perform multiple actions with them. Options might include:

Option 1 : Force handover to the new access device as it may be necessary if the access device can only operate in one mode at a time. This may require synchronizing the triggering of the handover (e.g., conditional handover) and the change of the operational mode. Note that this may not always be received because in either regenerative or transparent modes, the UE receives the signals (e.g., synchronization signals) as generated or reflected from the access device (e.g., the mobile access device 123).

Option 2: Configure or inform the UE of the mode switch, e.g., from regenerative to transparent so that the UE is aware that it can use the access device (e.g., the mobile access device 123) as a reflector when communicating with others devices. In this case, the UE, e.g., the first 100, may need to know the identity (e.g., RAN identity) of the target UE (e.g., the second UE 103). The access device may also need to know which communication resources are allocated to the given (reflected) communication link so that when the access device receives a signal from one of the UEs, e.g., the first UE 100, it can reflect the signal towards the location of the other UE, e.g., the second UE 103. The access device can achieve this by performing resource allocation for the communication between the first and second UE 100 and 103, e.g., upon request from the first and second UEs 100 and 103, tracking the location of both UEs 100, 103, and configuring the communication beams in such a way that the allocated communication slots/frequency range are reflected towards the target UE. It is to be noted that the control logic may be at the mobile access device 123 itself or in a terrestrial entity such as the RAN 106. The control logic needs to keep track of communication requests from the first UE 100 and/or the second UE 103, needs to keep track of the location of the first UE 100 and/or the second UE 103, and perform resource allocation. An aspect here is that the first UE 100 and/or the second UE 103 may need to be informed that the “direct” communication between each other is done through an access device working in transparent mode so that when they perform beam alignment for the given communication, this is done towards the mobile access device 123 itself.

This may mean that when the first and second UEs 100, 103 communicate with each other through the access device (e.g., the mobile access device 123) in transparent manner, the need to perform direct beam alignment between the first and second UEs 100, 103 is disabled and beam alignment for the UE-to-UE communication may be replaced by the UE beam alignment procedure towards the access device itself. This is because when the UE aligns its beam towards the access device, then the communication towards the target UE will be reflected properly. This has the advantage is being a more accurate process and reducing the signalling.

This may further mean that when the first and second UEs 100, 103 communicate with each other through the access device in transparent manner, they need to apply a different timing advance value (that the timing advance value for the communication with the access device itself, or the control logic of the access device that may be in mobile access device 123 or the RAN 106) for the reflected communication path, or different timing advance values when there are multiple reflected communication paths. The reason is that the timing advance value is computed for the communication link between UE (e.g., the first UE 100) and the control logic (e.g., the mobile access device 123) but if there are e.g., two reflected communication paths, it may be desirable if the received signals are received in a synchronized manner. This requires the sending UE to send the signals through different paths at different sending times, where the time difference between two sending times is determined by the propagation time difference determined by the absolute length difference (path 1 - path 2) of the communication paths divided by the speed of light, where path 1 may be through the first UE 100, the mobile access device 123, and the second UE 103, while path 2 may be through the first UE 100, another access device Z (not shown in Fig. 4), and the second UE 103. This requires the control logic of the mobile access device (where the control logic may be in the mobile access device 123 or in the RAN 106) to communicate said timing advance values to the first and second UEs 100, 103 so that the first and second UEs 100, 103 apply these timing advance values.

Option 3: Maintain existing connections in the earlier mode and start new connections in the new mode (might be appropriate if the time that a UE spends in a cell before handing over to a new one is relatively short - system will eventually hand over to the new mode autonomously).

Option 4: Gradually roll over existing connections to the new state (i.e., start with two but eventually force long connections to switch)

Options 2, 3, and 4 may all require the mobile access device 123 to be capable of operating in both states simultaneously. Since the mobile access device 123 (e.g., satellite with regenerative/transparent architecture or NCR/IAB nodes) may (presumably) share spectrum and radio frequency (RF) hardware resources (e.g., amplifiers, filters, antennas, etc.), they may have means to ensure co-existence, as described above for option 2.

There may be other reasons for simultaneous operation, so a fifth option may be to allow continuous operation in both modes with the choice of mode made on a per-connection or per- link basis dependent on the level of service required. If, for example, the regenerative link is of higher quality and could therefore support higher bit rates/better reliability, then a UE with a demanding application might be better served by an access device with a regenerative architecture (e.g., a satellite with a regenerative architecture or an IAB node).

In an embodiment, it may be possible for the UE to choose (or at least express a preference for) the operating mode for its connection, either directly or indirectly. Indeed, the UE may intentionally exploit multi-path relay, multi-cell operation albeit at the same physical node. For the node, the trade-off might be in providing the most appropriate service (e.g., highest data rate) for each UE link for the least, e.g., overall resource consumption, e.g., overall energy / spectrum consumption.

One other aspect is that the operation could be done in multiple frequency bands. It could be changed dynamically, as discussed above, for each (sub)band independently, or different bands could be operated in different modes on a (semi-) permanent basis.

In an embodiment, when the access device (e.g., the mobile access device 123) applies a transparent NTN architecture to a given communication link, the access device may need to select a frequency range that is suitable for both the uplink (e.g., from the first UE 100 to the mobile access device 123) and for the downlink (e.g., from the mobile access device 123 to the second UE 103) taking into account that the mobile access device 123 is acting as a transparent access device/reflector/smart repeater. This is needed because usually uplink and downlink frequency ranges are very different so that they cannot be simply repeated/forwarded. To this end, when the mobile access device 123 acts in a transparent mode, the frequency range for uplink and downlink can be the same. A sensible option may be to use sidelink frequency resources, or frequency resources allocated to a sidelink-over-satellite type of communication for this communication because effectively, the first UE 100 and the second UE 103 will seem to be in communication range. The mobile access device 123, when still acting in its regenerative mode, may send a control message to the first UE 100 to start the sidelink communication towards the mobile access device 123 that in the selected frequency range (e.g., sidelink frequency range) acts as a transparent access device and retransmits the sidelink communication towards the second UE 103. The first and second UEs 100 and 103 may have been configured/informed that the communication is supported by a transparent access device (such as the mobile access device 123 (e.g., satellite)).

In an embodiment, the mobile access device 123 may also act as a UE-to-UE relay when relaying the communication between the first UE 100 and the second UE 103. For instance, the procedures in TS 33.503 may be adapted to enable the secure communication.

In a further embodiment, the first and second UEs 100, 103 may setup a direct communication link through the mobile access device 123 acting in transparent mode to communicate to each other. For instance, the direct communication link may be based on the PC5 interface and the direct communication may be based on real time communication services or protocols such as the Real- Time Transport Protocol (RTP) which is a network standard designed for transmitting audio or video data, that is optimized for consistent delivery of live data. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

In an embodiment that may be combined with other embodiments or used independently, the first UE 100 may want to establish a communication with the second UE 103. In the particular case of an IMS communication, the first UE 100 may send a SIP INVITATION / SIP INVITE message towards the IMS network (e.g., the first core network 109). The IMS network may detect that the destination, i.e., the second UE 103, is connected or can be connected through the same access device (e.g., the mobile access device 123). In this case, the IMS network may direct the SIP INVITE message towards the second UE 103 (destination). The second UE 103 may then reply with, e.g., a 200 OK response, starting the setup of the subsequent communication, e.g., based on the real-time communication protocol. Thus, instead of having to execute that communication over the solid both path 128 in Fig. 4, the IMS network/CN may instruct the mobile access device 123 to act as a local relay between the first UE 100 (source) and the second UE 103 (destination/target). This can mean that the mobile access device 123, e.g.: operates as a regenerative access device, acting as a local router, e.g., routing IP messages on top of which the RTP messages are exchanged, and/or operates as a regenerative access device, acting as aUE-to-UE relay, e.g., a L2 or a L3 relay, end to end communication is exchanged on top of it, and/or operates as a mixed regenerative/transparent access device such that it works as a transparent access device for the user plane communication between the first UE 100 and the second UE 103 while for the control plane, it operates as a regenerative device, or operates as a transparent access device such that it works as a transparent access device for both the user plane and control plane communication between the first UE 100 and the second UE 103.

It is to be noted that a transparent operation mode means that the first UE 100 and the second UE 103 are directly reachable, e.g., there is no IP router in between.

It is to be noted that the above operation modes may apply to a UE-to-UE communication over the mobile access device 123 when it is using a protocol such as real time protocol (RTP), but also other protocols.

It is to be noted that a UE that does not support NTN connectivity or is not part of the subscription, i.e., not authorized for NTN-based connectivity, the IMS network would make the decision not to route the UP traffic over the satellite before forwarding the SIP invite. Even if the UE supports NTN connectivity, the network may not know where the UE is exactly located, so that it may be challenging to forward the SIP invite. Thus, the following embodiments may be considered.

As illustrated in other embodiments above, when a UE wants to use a given RAT for a given service (e.g., IMS), the UE may include an indication of it so that the network can verify whether the UE is authorized to use the selected RAT for the given service. Similarly, the UE may have a policy giving a preference to a given RAT. This may be exchanged also in or next to the service messages, in this case, the SIP INVITE message or the 200 OK message.

In an embodiment that may be combined with other embodiments or used independently, the IMS network may interact with the 5G network to determine whether a UE supports a given type of connectivity (e.g., NTN connectivity) and/or it is enabled in the user subscription. This UE may be the second UE 103.

In an embodiment that may be combined with other embodiments or used independently, the IMS network may interact with the 5G network to determine whether a UE is already in a CONNECTED state and if so, using which RAT. Such information may be retrieved from the AMF serving the UE (see 5.4.10 in 23.501).

In an embodiment that may be combined with other embodiments or used independently, when a UE is determined to be in INNACTIVE or IDLE states, the network could try to page the UE from the last known RAN and based on whether it initiates a Service Request procedure (4.2.3.2 in TS 23.502) determine whether to establish UE-mobile access device-UE route, again using the RAT information to determine whether it should use an mobile access device (e.g., satellite) for the device to device communication.

In another embodiment that may be combined with other embodiments or used independently, when a UE e.g., UE 100 tries to establish a session (e.g., call session) with another UE e.g., UE 103 using an NTN access device, the 5GS (e.g., a NF within the 5GC) may perform a check to verify whether the access-type indicated in the SIP invite matches the RAT information associated with UE 101 registration that is stored at the AMF.

In a further embodiment that may be combined with other embodiments or used independently, the decision to route the information over mobile access device, e.g., NTN access device, e.g., to have UP traffic go over the mobile access device, could also be taken before receiving the response from the second UE 103.

In general, according to at least some of the embodiments described herein, an apparatus and method for establishing and managing a connection is proposed, wherein the apparatus is configured to:

• receive an indication of one or more communication modes for an access device,

• select or receive the selection of a communication mode for the communication via the access device,

• receive or apply communication parameters for the selected communication mode of the access device when communicating with a first device through the access device where the first device may be a UE or a control device. In at least some embodiments, the above apparatus and method can be further adapted to select or receive the selection of a communication mode for a communication phase (e.g., initial random access procedure) or for a given communication procedure (e.g., network access) or for a given type of communication (e.g., control plane) and select or receive an indication of the selection of a different communication mode for a subsequent communication phase, or for a communication procedure, or type of communication.

In at least some embodiments, the above apparatus and method can be further adapted to receive or apply communication parameters indicating one or more of: a usage of the beam alignment procedure with the access device when communicating with the first device, a configuration and usage of different timing advance values when communicating with the control logic of the access device or the first device, and a configuration and usage of keying materials for the communication with the first device.

Section: NTN - Procedures to enable UE-Satellite-UE communications

In above scenarios, a first UE may need to communicate with a second UE over a satellite wherein the communication flow is first UE to satellite/gNB, then satellite/gNB to second UE. An entity such as the gNB or a NF may be in charge of one or more of the following functionalities: establishing a secure link with the first UE and the second UE: The secure link with the first UE and/or the second UE may be based on standard security in the Uu interface between UE and gNB. This means both the first and second UE are required to perform primary authentication so that the corresponding keys, AS keys, are available at the gNB; verifying or requesting the verification of whether the first UE and the second UE are authorized to communicate with each other via a satellite link: the first and second UEs may have a given subscription available in the core network, e.g., as part of the subscription profile, stating whether they are entitled to use a satellite link for direct communication, and the context in which it may be used (e.g., location, time, allowed communicating parties, etc). The access device, e.g., gNB, may send a request to the core network, e.g., one or more AMF, AUSF, UDM, UDR, to retrieve this information for a given communication session, e.g., to be established or already established between the first and the second UE. This request may be to a single network function or interactions between network functions may be required, e.g., AUSF may interact with UDM. Additionally or alternatively, (part ol) the subscription profile may be stored at the gNB once a UE is connected to the gNB. This authorization may also depend on the locations of the UEs (in which jurisdiction) and the location of the mobile access device; Acting as enforcement point enabling or disallowing a communication link: once the gNB has verified the rights of two UEs to establish a communication link, the gNB allows or disallows it;

Distributing keys used to protect the UE-to-UE communication link, in particular, when the communication through a mobile access device acting in a transparent manner.

Fig. 14 shows a potential procedure integrating some of these functionalities wherein blocks 1401, 1402, 1403, 1404, 1405, 1406 may refer to a first UE (UE1), a (mobile) access device (MAD), a second UE (UE2), an access device or gateway, a NF function in charge of access and mobility (e.g., AMF), one or more NFs in charge of authentication, respectively. The procedure may include the following message exchanges. This message flow is illustrative and messages may be exchanged in a different order, one or multiple times. In some circumstances, some steps may be skipped.

In message exchange 1407, 1401 may perform an initial primary authentication procedure;

In message exchange 1408, 1403 may perform an initial primary authentication procedure;

In message exchange 1409, the first UE (e.g., 1401) may trigger a communication request with the second UE (e.g., 1403). 1405 gets involved and observes that 1403 is (e.g., only) reachable through 1402. For instance, it may be that the first UE is in coverage, e.g., of a terrestrial access device (such as a 5G gNB not shown in Fig. 14) while the second UE is only in coverage of (a non-terrestrial network) access device (1402). 1405 knows that a communication path to establish the communication may be to get involved with both 1402 (that is used by the second device) as well as the terrestrial access device used to connect the first device, but since the first device may also be able to connect to 1402, 1405 may prefer/instruct the first device to communicate with the second device through 1402. This can be done through message exchanges 1410-1416;

Entity 1406 may also verify, e.g., upon request by 1405, whether UE 1401 and UE 1403 may be allowed to communicate over mobile access device 1402. This may be because it may not be part of the subscription.

In message exchange 1410, 1405 may send 1404 a configuration and/or request 1404 to configure 1401, 1402, and 1403 to perform UE-to-UE based communication over 1402. For instance, if 1402 acts in a transparent manner, 1404 will keep the responsibility of managing the RAN connection;

In message exchange 1411, 1405 may send 1402 a configuration to perform UE-to-UE based communication between 1401 and 1403. For instance, if 1402 acts in a regenerative manner (e.g., it has the functionalities of a base station), 1404 will have the responsibility of managing the RAN connection with 1401 and 1403,

In message exchange 1412 (1413), 1405 may send 1401 (1403) a configuration to perform UE- to-UE based communication with 1403 (1401) over 1402. For instance, it may inform about the usage of 1402, configuration parameters to connect to it, etc; In message exchange 1414, 1404 may then send 1402 a configuration to enable UE-to-UE based communication between 1401 and 1403. This can happen, e.g., when 1402 works in a transparent manner;

In message exchange 1415, 1404 may then send 1401 (1403) a configuration to perform UE- to-UE based communication with 1403 (1401) over 1402. This may also happen, e.g., when 1402 works in a transparent manner;

In message exchanges 1416, 1402 may send 1401 (1403) a configuration to perform UE-to-UE based communication with 1403 (1401) over 1402. This can happen when 1402 works in regenerative manner, e.g., in the control plane;

In message exchange 1417, the communication between 1401 and 1403 over 1402 takes place, e.g., using 1402 in a transparent manner or regenerative manner over the user plane.

In an embodiment of the invention illustrated by means of above procedure, those message exchanges (e.g. 1412) used to send a configuration, may also be used to report parameters, measurements, request a configuration, etc, e.g., message exchange 1415 may also imply that 1404 gathers measurement reports from 1401/1403.

In an embodiment of the invention illustrated by means of above procedure, some message exchanges may happen simultaneously, for instance, message exchanges 1416 may refer to the control plane communication to control the user plane communication in message exchanges 1417.

In an embodiment of the invention illustrated by means of above procedure, messages exchanges may be over user plane or control plane and/or using a transparent and/or regenerative architecture. For instance, message exchanges 1416 may refer to the control plane communication using a regenerative architecture to control the user plane communication in message exchanges 1417 using a transparent architecture.

In an embodiment of the invention illustrated by means of above procedure, 1405 and/or 1406 may be in charge of verifying whether 1401 and 1403 are allowed to communicate via 1402.

In an embodiment of the invention illustrated by means of above procedure, 1405 and/or 1406 send 1404 and/or 1402 a confirmation of whether said communication is allowed, and/or a configuration describing which communication is allowed, e.g., it may describe the type of communication both UEs are entitled to.

In above procedure, 1404 and/or 1402 enforce/apply said configuration.

An aspect related to the UE-to-UE communication relates to the location of the UEs and mobile access device (e.g., satellite), in particular, the jurisdictions where the UEs and/or mobile access device are. Depending on those locations, the UE-Sat- UE communication may be allowed or disallowed. This may be based on a policy that may be deployed in the mobile access device (e.g. satellite) or in the core network. This policy may be used to determine whether the communication may be established or not. This requires gathering and verifying the location of both UEs as well as the location of the mobile base station (e.g., satellite, UAV, ship, etc). The communication link may be established if, e.g., the jurisdiction of all three devices is the same.

Section: NTN - Procedures for secure UE-Satellite-UE communications

In relation to Fig. 14, 1404 and/or 1402 may have established AS security with 1401 and 1403. Security keys can be used to protect the RAN traffic between the first and second UEs and 1402 and/or 1404. However, there are no security keys to protect end-to-end traffic between 1401 and 1403, e.g., considering that this end-to-end traffic corresponds to a PDCP communication link as per TS 38.323.

Thus, in an embodiment of the invention illustrated by means of above procedure and that may be combined with other embodiments or may be used independently, 1402 and/or 1404 may act as a key distribution center (KDC) in charge of managing and configuring 1401 and 1403 with keying materials used for the UE to UE communication over 1402, e.g., keying materials used for the user plane communication over 1402 and used, e.g., in the PDCP layer. The keying materials may include an integrity key and a confidentiality key that may be distributed by means of RRC messages sent by 1402/1404 to both 1401 and 1403. A message may include configuration parameters such as sequence number, usage of MAC -I, COUNT value, key ID (e.g., K NRP-sess ID), key type (integrity or confidentiality), or key value. These keys may be bound to the communication link established and enabled over 1402, e.g., a PDCP communication. When the KDC distributes the keys, it may also distribute additional security parameters such as selected algorithms for the communication link, whereby said security parameters may be subject to a choice by the core network, e.g., 1405 may determine them based on the type of communication to be established over 1402. The KDC is also in charge of rotating keys, e.g., when counters are about reaching a maximum value, the KDC is in charge of distributing new updated keys. These keys may be computed at random, or they may be derived in a deterministic manner from some root keys. In this case, since the communication is between 1401 and 1403 and each of them may have some root keying material K at the access device (e.g., K gNB in the 5GS), then above keys may be derived by means of a Key Derivation Function from said keys.

In a related embodiment of the invention, these keys may be managed by a core network network function, e.g., 1405 (e.g., 1405 becomes the KDC) and may be distributed to 1401 and 1403 protected with NAS keys. This has the advantage of ensuring which UEs may establish a connection plus non-fully trusted mobile access devices used since they may not be able to eavesdrop or inject or modify the traffic (since they lack the corresponding keys).

In a related embodiment of the invention that may be combined with other embodiments or used independently, the condition that triggers the update of keys may be the change of/handover the mobile access device 1402 acting as relay between UE 1401 and 1403, i.e., the path switch. For instance, in reference to Fig. 16, at an initial time, mobile access device 1602-1 may enable the communication between UEs 1601 and 1602. At a later point of time, mobile access device 1602-2 may become in a better position to keep the communication link. Thus, the handover procedure may trigger the update or renewal of established or distributed keys.

In a related embodiment, an NTN key management function (NKMF) may act as KDF and serve as entity enabling the distribution of keys for UE-to-UE communication. For instance, similar to other embodiments, the NKMF may distribute root keying materials that may allow the establishment of a secure link reusing the procedures in TS 33.503, e.g., for direct communication when the mobile access device operates in transparent mode for the user plane.

In a related embodiment of the invention, and in reference to Fig. 16, a mobile access device e.g., 1602-1 may provide the security context related to the UE-to-UE communication (e.g., security keys, nonces, timers, etc) to a second mobile access device e.g., 1602-2 that may subsequently enable the communication between UEs 1601 and 1602. Alternatively, at least one of the UEs may trigger the security context retrieval on-demand by communicating to the second mobile access device 1602-2 a protected link/context/path identifier that is transferred to the first mobile access device 1602-1, which upon verification and link identification, provides the security context associated with said link to the second mobile access device 1602-2.

In another embodiment of the invention, the security materials for end-to-end protection of the UE-to-UE communications may be based on a root key that is distributed by the mobile access device and a set of (random) parameters that are delivered by the network to the UEs e.g., over protected NAS messages, such that encryption and/or integrity security keys are derived based on a key derivation function (KDF) taking as input the root key delivered by the mobile access device and the randomized configuration parameters assigned by the network. Alternatively, the root key may be assigned and distributed to the UEs by the network e.g., over protected NAS messages, whereas the randomized configuration parameters are either distributed by the mobile access device or generated and exchanged by the UEs over the mobile access device. In the latter option, the renewal/refreshing of encryption/integrity security keys may be as simple as providing the UEs with new randomized configuration parameters or an indication to generate and exchange new randomized configuration parameters to derive new security keys based on the same root key provisioned already by the network.

In TS 38.323 it is described that a parameter included in the PDCP communication link is the K NRP Sess ID. Thus, in a related aspect of the invention, the key that is configured by the KDC (e.g., 1402, 1404, or 1405) is K NRP Sess and it is then used by UE 1401 and 1403 to derive NRPEK and NRPIK as per TS 33.536. Additionally or alternatively, K NRP may also be configured by the KDC, and a new K NRP Sess may be derived e.g., based on Clause 5.3.3.1.4.3 in TS 33.536) or derived (e.g., based on Clause 5.3.3.1.4.4 in TS 33.536), e.g., when a situation occurs triggering this event.

In a related embodiment of the invention illustrated by means of above procedure, the KDC may be distributed, e.g., when more than a single core network function may be involved, e.g., when UE 1401 and 1403 are connected to two different 1405 entities (AMFs), those entities may need to interact to agree on the keys to be used to protect the communication over 1402. For instance, a first AMF (e.g., of the UE initiating the communication) may be in charge of generating/determining the keys, then sharing them with the second AMF (e.g., of the UE receiving the communication). Similar distributed KDC may be applied when two 1402 entities are involved as illustrated in Fig. 15 where two mobile access devices 1502-1 and 1502-2 communicate with each other to enable the communication between user equipments 1501 and 1503. In this case, the first mobile access device (e.g., 1502-1) may act as KDC and share the generated keys with the second mobile access device (e.g., 1502-2).

In some use cases, the communication between two UEs over a mobile access device is established/initiated by means of the exchanged of a SIP Invitation request. This can lead to the establishment of an IP communication link between two UEs over a mobile access device. Thus, in an embodiment that may be combined with other embodiments or used independently, the IP communication link between those two UEs is secured by means IPSec and/or TLS and/or MPQUIC and/or MPTCS. This may require configuring keying materials (e.g., a pre-shared key or digital certificates) in the end devices so that they can authenticate each other, and verily their authorization to communicate. This configuration may be done by a RAN device (e.g., 1402) or a CN function (e.g., 1405) or an AF (e.g., from the IMS network).

In an embodiment that may be combined with other embodiments or used independently, MPTCP and/or MPQUIC may be used to enable UE-to-UE communication where one of the paths may be over a first mobile access device, and a second path may be over a second mobile access device or over a terrestrial access device.

In an embodiment that may be combined with other embodiments or used independently, the mobile access device (e.g., 1402) may include a lawful interception functionality that may allow intercepting the communication between two UEs. The lawful interception functionality may have access to keying materials, e.g., as described in the previous embodiment or the location of the access device 1402, or the location of UE 1401 and 1402. The lawful interception functionality may also include a policy determining when it is required to monitor the communication, e.g., by decrypting the data exchanged between the UEs. The policy may also include the functionality to block the communication and/or transmit the intercepted communication to a on ground LI functionality when the LI functionality on the mobile access device determines that the intercepted communication fulfils a given criteria, e.g., classified as dangerous.

Section: NTN - Configuration and security aspects of the Handover procedure in NonTerrestrial Networks

According to section 16.14.3 of TS 38.300, UE's mobility in Non-Terrestrial Networks in the different RRC states (i.e., RRC IDLE, RRC INACTIVE, and RRC CONNECTED) follows the same principles as Mobility and state transitions in Terrestrial Networks, with few additions (e.g., Conditional HO) specific to the NTN scenario. Although, due to the limited time during which an NTN gNB could serve UEs in a tracking area, and depending on whether the area is outside TNs coverage, the frequency of handovers the UE exhibits when served by NTN gNBs may be significantly higher than in the TN handover cases. Moreover, in addition to Conditional Handovers (CHO), which a UE may execute due to a time or location-based trigger, clause 16.14.4 describes a feeder link switchover (i.e., feeder link changing from a source NTN gateway to a target NTN gateway) which may result in transferring UEs' established connections between two NTN gNBs (i.e., transfer of UEs' contexts by means of NG or Xn based handover). It is evident that the UE's security context would be transferred much more often between serving NTN gNBs, and due to the numerous events/triggers that may invoke such transfer/HO, synchronization issues and/or key mismatches (e.g., between the UE and target gNB(s)) may occur. Furthermore, if multiple handovers were to take place between several gNBs in a short period of time, security keys may in some instances be updated without being used. Hence, it is the object of the following embodiments to address those issues.

In an embodiment, an NTN gNB (e.g., source NTN gNB) may estimate the point in time where it will no longer be able to serve UEs over a location/area, and may consequently schedule handovers to ensure minimal service disruption for the served UEs; NTN gNBs may therefore be (pre-)configured e.g., by the network, with a safety time window that allows a source NTN gNB to select a suitable target gNB and/or trigger/use Conditional Handover (CHO), request CHO from candidate target gNBs, and provide the UEs with the configuration of CHO candidate cells and execution conditions, thus allowing the UEs to select the target gNB themselves. For instance, UEs in a tracking area that are served by an NTN gNB may be provided with a configuration determining how long they can be served by said NTN gNB, and the identity of target NTN gNB. Based on the safety window configured in a gNB, the gNB may assign, e.g., a time to trigger a handover procedure, e.g., in a CHO. A network function such as AMF or an NTN gateway may be in charge of the configuration of said time window.

In an embodiment, the source gNB may inform in advance the target gNB(s) about the potential UEs it may need to take over. This may for instance include the timing of the event, and/or a list of UEs grouped per timing window and/or per timing of HO. In a particular example, the source gNB may communicate a list of UE containers, each container containing a list of UEs and where each container corresponds to a particular time window, such that the target gNB could for instance manage its resources better, and/or expect the number of UEs and/or messages (e.g., RRC messages) to be received from the set of UEs which corresponds to an upcoming time window, and/or estimate the number of local identifiers required to be assigned to UEs, etc. The UEs in a container may be in a given location. The timing window which may be associated with the UE container may be synchronized and/or associated with the timing parameter(s) configured in UEs to perform a CHO.

In an embodiment that may be combined with the previous embodiment or used independently, a source NTN gNB may be configured to select the target gNB to which UE(s) are handed over based on several criteria e.g., estimated delay to be incurred due to handover, UE mobility (e.g., direction, velocity), estimated target gNB serving time (e.g., first target gNB candidate may already be covering UE's location with 5 minutes remaining to go over the UE's horizon, while a second target gNB candidate may be just about to start covering the UE's location), target gNB type (i.e., NTN or TN), UE's measurement data, etc. Alternatively or additionally, the decision of which target gNB the UE(s) are to be handed-over may be determined based on the aforementioned criteria by the NTN control function and then communicated to the source gNB. The target gNB selection may be subject to a network policy which determines based on the candidate target gNBs and the selection criteria thereof, how the target gNB is selection; for instance, if the selection is between an NTN gNB and a TN gNB, with the UE moving in the direction of the TN gNB's coverage area, the candidate TN gNB may be more prioritized than the candidate NTN gNB. For instance, if the selection is between two or more candidate NTN gNBs, the candidate NTN gNB with the longest estimated target gNB serving time, and the least estimated delay to be incurred due to HO, may be prioritized. To this end, all this information need to be provided to the NTN control function together with said policy. If the decision is to be taken by source NTN / target NTN, all this information needs to be made available to them, including also the policy.

In another embodiment related to the requirements that a UE must meet to connect to an NTN cell, according to clause 16.14.2.2, a UE shall have a valid GNSS position, ephemeris, and Common Timing Advance(TA), and compute the frequency Doppler shift of the service link and autonomously pre-compensate for it in the uplink transmissions, otherwise the UE shall not make any transmissions. In case a UE is handed over to a target NTN gNB, if the UE is not able to synchronize with the target gNB and cannot make any transmissions within a (pre-)configured time window, the UE may inform the source gNB in order for the latter to (re-)select another target gNB, and/or if it is a conditional handover, the UE may select another candidate target gNB to connect to. This has the advantage of reducing the UE's downtime. In other words, the UE needs to inform the source gNB about situations / failure cause / connectivity features when the UE cannot successfully move/connect to a target gNB. This can facilitate the selection of a different target gNB.

In another embodiment that may be combined with other/above embodiments, the safety time window that the source gNB may be configmed with may include and/or account for the time period during which the UE attempts to connect to the target gNB. Source gNB may for instance start a timer upon sending the RRCReconfiguration message to initiate the HO, and may indicate and/or configure the UE to perform as many attempts to establish the connection with target gNB e.g., for as long as the timer allows, and/or configure the UE to attempt for a limited number of times. The timing window and/or number of attempts may also be configured by the network. The time window during which the UE tries to connect to target gNB may also be configurable depending on the context of the gNB (e.g., the number of UEs that it is serving and/or expect to serve). This time window may also be configurable depending on the desired performance that needs to be achieved, e.g., percentage of successful handovers. The safety time window and the time window/timer the UE is configured with have the advantage of ensuring that in case of a failure to connect to the selected target gNB, the UE may still be able to request source gNB to assign a different target gNB. In another embodiment related to the handling of security context(s) and keying materials, to optimize security materials refreshment and ensure that security materials are not updated without being used, UEs may be configured by a network function (e.g., AMF) and/or by an access device (e.g., source gNB) to indicate to a target gNB (e.g., NTN or TN gNB) by means of a message, e.g., in an RRC message, whether the security materials (e.g., K gNB) retrieved from the source gNB have or have not been used and whether they should or should not be updated. Additionally or alternatively, the configuration may also be placed e.g., by AMF or another network function, on the gNBs so that under some circumstances no keys are derived during handover, e.g., NTN handover. The transmission of said indication may be conditional; for instance, the UE may be (pre-)configured with a time window such that if multiple handovers occur consecutively in the span of the configured time window, the UE transmits said indication to target gNB. For instance, the UE may be configured to transmit said indication when it detects that the security materials from the previous HO were not used. Alternatively, the UE may be configured to transmit said indication during any HO procedure. Additionally or alternatively, under certain conditions (e.g., keys not used) a source gNB may also inform target gNB that no new keys are to be derived during handover, e.g., NTN handover. It is to be noted that if the security materials are not updated, the source gNB should inform the target gNB about other security parameters, e.g., ciphering algorithms, counters, etc that should be used, e.g., to avoid reusing the same counter value by source gNB and target gNB.

In another embodiment related to the handling of security context(s) and keying materials, UEs may be configured to only perform vertical handover as per Clause 6.9.2.1.1 in TS 33.501 when connecting through an NTN network as a way to ensure forward security.

In another embodiment related to the handling of security context(s) and keying materials, UEs may be configured to only perform horizonal handover as per Clause 6.9.2.1.1 in TS 33.501 when connecting through an NTN network as a way to optimize performance and avoid disruptions due to the N2 connection with the AMF, when the AMF is not mounted in the access device.

In another embodiment related to the handling (e.g., retention or refreshment) of security key materials, a constellation of NTN access devices may serve as gNB-DUs associated with a gNB-CU that may be on board of an NTN access device or on the ground. The NTN access devices (e.g., gNB- DUs) may be configured with a policy determining whether and/or under which conditions the security key materials are retained and/or refreshed during an inter-gNB-CU handover procedure. For instance, if a K gNB which was derived by source NTN gNB was not used, source NTN gNB may according to said policy forward that K gNB with the Next Hop Chaining Counter (NCC) associated with it to the target NTN gNB, regardless of whether source NTN gNB has (or does not have) a fresh {NH,NCC} pair. Additionally or alternatively, said policy may be generalized/applied in an inter-gNB-CU handover scenario, where under the same set on conditions and/or additional conditions e.g., defined in a policy by the network and/or determined by a NF e.g., AMF, the security keys (e.g., K gNB) are either retained or refreshed. The policy may also include a maximum number of handovers that are possible before key refreshment becomes mandatory. Similarly, where keys are refreshed more often, the policy may also determine a maximum number of horizontal key derivations before it mandates a vertical key derivation.

In another embodiment that may be combined with the previous embodiment or used independently, the handling (e.g., retention or refreshment) of the security key materials may be based on an autonomous/dynamic process which may be overseen by the gNB-CU and/or a NF (e.g., AMF) whereby based on criteria including, but not limited to: the context of service (e.g., location, time, access device load, UE type and/or whether it is resource constrained, etc), type of handover procedure (e.g., intra/inter-gNB-CU, N2) anticipated, availability of NTN/TN access devices and the resources thereof, freshness/validity of the key materials, etc, the security keys are either retained or refreshed, and where it is the latter, the process determines whether it shall be a horizontal or vertical derivation.

In another embodiment, the policy on whether security key materials may be reused may depend on the device type. For instance, resource constrained loT devices that may communicate in an irregular manner may not require updating the keys.

In an embodiment, there may be a proactive transfer or derivation of (security) parameters, such as, e.g., keying materials from source gNB to target gNB. This accounts for the situation in which a source gNB moves away from a UE and a target UE gets closer to the UE. This proactive transfer or derivation of parameters may be set up by source gNB long before it moves away from served UEs in a coverage area. The proactive transfer/derivation of parameters may be based on a negotiation between source gNB and potential target gNBs whereby a source gNB selects suitable target gNB(s) to which UE contexts and/or derived keys may be transferred. The negotiation step may dictate the point in time or time window during which the transfer/handover is scheduled to occur, the number of UEs to be handed over, which parameters (e.g., identifiers, keying materials) associated with the UEs are to be transferred and/or expected to be generated/derived, taking into account target gNB(s) resources and capacity to serve the UEs to be handed over. This enables the target gNB to be ready for the secure communication and ensures a smooth transfer for UEs. Similarly, a UE may also be configured and/or derive parameters such as the keying materials to be used when handed over to another gNB. Upon selecting a suitable target gNB and transferring the required parameters (e.g., identifiers/keys) and determining the time to trigger the handover procedure, source gNB may configure the UE(s) with the parameters required to derive keying materials to use when handed over. This enables the UE to be ready for the secure communication with target gNB and ensures the time required for configuration is minimized. This can require keeping a set of parameters, ready, but innactive. This can require including a condition or time from which the parameters become active.

In another embodiment, an NTN gNB may be serving numerous UEs which are scattered across a large area, and as the NTN gNB is constantly on the move, it may perform group handovers, wherein a group of UEs within a geographical area and/or UEs which share similar features (e.g., same RRC state) are handed over together to a target gNB. As such, source gNB may be configured to compute and/or assign a group identifier (e.g., based on a function such as concatenation or key derivation function (KDF) of certain parameters such as input source and/or target gNB/cell ID, a time value, number of UEs, etc) which is communicated to the UEs and/or target gNB, and used to identify the group of UEs being handed over.

In an example, similar to previous embodiments, the information of the UEs belonging to a group may be transferred from the source gNB to the target gNB in advance. Then when the time to perform the handover comes/arrives, the source gNB communicates the group identifier to the target gNB to initiate the group handover in batch. For instance, if the group of UEs to be handed over is large (i.e., in terms of number of UEs), the UEs may be split into subsets/batches containing a configurable number of UEs, which are associated with a time window during which said batch of UEs is expected to perform the HO procedure. Each batch of UEs may be assigned a group identifier which is associated with the time window during which the handover is scheduled to take place. The source gNB may either proactively inform/communicates the list of group identifiers and the time windows to which they are associated to the target gNB, and/or communicate each group identifier as a trigger to indicate to target gNB that the group of UEs associated with that group identifier will start performing the HO procedures and are allocated X time units e.g., 30 seconds to complete the HO procedures. Following the completion of HO procedures of a batch of UEs, target gNB may report to source gNB the success rate (e.g., number of UEs and identities that were successfully handed over) and/or failure rate (e.g., number of UEs which attempted to connect but failed) and/or information related to the capacity of target gNB to take over more UEs. Source gNB may rely on the information reported from target gNB and/or UEs which were not successfully handed over to have those UEs assigned to a different batch of UEs, with a different group identifier and/or different timing window to perform another HO procedure. Source gNB may also assign the batches of UEs left to another target gNB in case the first target gNB is saturated (e.g., does not have enough resources to take over more UEs), in which case the selected target gNB is proactively informed of the batch(es) of UEs it ought to expect taking over, similarly to the first target gNB. A source gNB may continuously and proactively organize/aggregate the served UEs into batches/groups/subsets that are handed over to target gNBs in bulk, in pre-determined time windows and/or triggered on-demand (e.g., by communicating the group identifier to target gNB) after having pre-informed/configured the target gNB with the parameters (e.g., (group) identifiers, keying materials, time values, derivation parameters, etc) required to handle the group of UEs to be taken over.

Section: NTN - Virtual handover

In another embodiment that may be combined with the previous embodiments or used independently, UEs in a given area, e.g., a given tracking area, and served by NTN gNBs may be served by different NTN access devices/gNBs regularly, e.g., working in transparent or regenerative mode. Instead of requiring an active handover because a first NTN access device is getting farther from the given area, e.g., the tracking area, and a second NTN is getting closer to the area, e.g., tracking area, and wherein the first and second NTN have different gNB/cell identities (PCIs), the NTN access devices/gNBs may be assigned/configured to use a given, or generate a transient identifier, e.g., it may be a physical cell identifier that is fixed to a given area or it may be an identifier which depends on the area e.g., tracking area, and/or a timing value/window, and/or PLMN ID, etc, In this way, the second NTN access device may receive the UE identities, UE parameters, keying materials, etc of the UEs that are currently served by the first NTN access device/gNB, and take over the identifier, e.g., physical cell identifier/transient identifier and/or generates a fresh identifier (e.g., depending on the validity of the identifier received from the source/first NTN access device) when it starts serving those UEs, at which point the first NTN access device may stop using said identifier (e.g., physical cell identifier or transient identifier). An NTN access device/gNB may hold multiple Identifiers at the same time, depending on the areas, e.g., tracking areas, it has covered and/or PLMN(s) it serves; additionally, multiple NTN access devices/gNBs may hold similar transient identifiers at the same time e.g., when there is overlap in the tracking area covered by these NTN access devices. This has a number of advantages, such as: reducing the number of NTN access devices/gNBs identifiers visible to UEs in a given area, e.g., tracking area, identifiers remain constant for as long as is determined by e.g., a policy (e.g., where the identifiers are location e.g., tracking area and/or time dependent), independently of the physical device that is providing access; UEs may only be aware of whether the NTN provides access at a given location and time, or not, and which is the identifier of the access device providing access, but which specific physical access devices provide access is transparent,

UEs being able to generate the identifier(s) of the NTN access devices to request service from and/or identifiers (s) of NTN access devices which served them in the past, based on timing and location information (e.g., prior to transitioning into inactive or idle states).

Target NTN access devices/gNBs identifying the potential NTN access devices/gNBs which might have been serving a UE e.g., before it moved to inactive state and e.g., based on ephemeris data, timing and location information, and coverage status, determine whether to request the UE context from one or more of these candidate gNBs and/or whether the UE context has already been provided to the NTN access device by one of these potential source NTN access devices.

Above handover procedure could be considered as a “virtual” handover procedure that aims at preventing UEs from seeing / changing the access device in a regular manner.

In a further embodiment that may be combined with other embodiments or used independently, above “virtual” handover procedure could also be realized by means of dual connectivity wherein the first access device acts as primary cell and the second access device acts as secondary cell, and may facilitate, e.g., the synchronization with the second cell. Then once the UEs have synchronized to the second cell, the second cell takes over the role of the primary cell, and the (new) primary cell will facilitate the synchronization with a new second cell. The UE remains always connected to the “same” primary cell, even if the physical device acting as primary cell keeps changing.

In a further embodiment that may be combined with other embodiments or used independently, above “virtual” handover procedure may also refer to the movement of certain functionality from one device to another, e.g., the AMF logic in a satellite may be moved from a source access device to a target access device so that the AMF responsible for serving an area remains constant over time. In the case of the AMF, if the AMF remains linked to a given area, all handover in that area can be easily vertical handovers.

In another embodiment that may be combined with the previous embodiments or used independently, since a target gNB requires UEs' I-RNTIs to retrieve the contexts of UEs which are in RRC INACTIVE state from the source gNB, e.g., during a group handover (e.g., where all inactive UEs are handed over to a target gNB) the source gNB may provide the list of I-RNTIs associated with the inactive UEs to the target gNB, which stores them fully or partially e.g., since the NG-RAN node address index segment in the I-RNTI is the same in all UEs’ I-RNTIs, target gNB may store only UE specific references and PLMN-specific information together with the NG-RAN node address index and/or another gNB identifier). Additionally or alternatively, the source gNB may communicate a group identifier to the target gNB, which is stored by the latter and may be used (e.g., together with timing and location information, ephemeris data, etc) to resolve the identity of source gNB. Upon (group) HO acknowledgement of the target gNB, the source gNB may indicate to the group of inactive UEs or UEs that are to be transitioned to the inactive state, that they are being handed over e.g., via RRC messages (e.g., RRCRelease and/or RRCReconfiguration messages). Given that target gNB has the list of UE identifiers and/or the inactive UEs group identifier and/or the source NTN access device/gNB ID, the structure of I-RNTIs transmitted by UEs may be optimized/modified to exclude the NG-RAN node address index, which is typically used by a target gNB to resolve the identity of the source gNB. It is worth noting that according to Annex F of TS 38.300, a full (i.e., 40bit) I-RNTI includes 20bits or 16bits (depending on the profile ID used) allocated for NG-RAN node address index, whereas for a short (i.e., 24bit) I-RNTI, it is not clear how many bits are allocated for NG-RAN identification. Hence, excluding the NG-RAN node index from I-RNTI has the advantage of providing spare bits, which may be used to carry more data associated with the UE specific reference/ID (e.g., when short I-RNTI is used), thus avoiding potential collisions during group handover, and/or carry other type of information (e.g., flags/indications/identifiers) e.g., when a full I-RNTI is used. Furthermore, the list of inactive UEs I- RNTIs and/or group identifiers and/or source gNB identifiers and/or a mapping between them may be stored and passed from an NTN access device serving an area e.g., tracking area to the next NTN access device(s) that may serve the same area, such that whenever a UE wakes up from its inactive state, it can communicate its I-RNTI (e.g., without the NG-RAN node address index) and/or timing/location information associated with the last time it was being served by an access device, thus enabling the NTN access device covering the area to retrieve its context, e.g., if it is in store, and/or determine based on the information provided by the UE (e.g., timing/location information) the potential source gNB that was serving said UE and hence request the UE context/parameters/keys from it, e.g., it is has it stored still.

In another embodiment related to UE identification, within a cell, C-RNTI is a unique identifier of the UE that is used in identifying the RRC connection and for scheduling purposes. According to table 7.1-1 of TS 38.321, the C-RNTI, in addition to several other RNTIs are allocated the values ranging from 0001 to FFF2, as such the number of available C-RNTIs which a gNB could allocate to UEs is limited to less than 2^A16 values, and since in the NTN scenario, gNBs may cover a larger area than TN gNBs, NTN gNBs may serve more UEs, hence a longer identifier e.g., a 32bit RNTI, may be required. It is worth noting that some RNTI(s) e.g., C-RNTI may be used to scramble the CRC attached to Downlink Control Information (DCI), whereby, according to clause 7.3.2 of TS 38.212, the 16 LSBs (out of 24bits) of the CRC are masked using the 16bit RNTI e.g., C-RNTI. As such, a larger C-RNTI (e.g., 32bits) may be used (e.g., the 24 MSBs/LSBs) to fully mask the CRC attached to DCI. Alternatively, only 16 LSBs of the CRC may be masked using 16 bits of the C-RNTI.

Section: NTN - Positioning during a “virtual” handover procedure

In some scenarios, the RF path between a UE and the base station may be switched from a first RF path to a second RF path typically in order to maintain or improve the path quality. Since the connection remains otherwise the same at the higher protocol layers (for example, no identifiers used at different protocol layers are changed), such a path switch may be described as a 'virtual handover' in as much as the UE now communicates with the base station via a second radio interface instead of the first. In some cases, for example, NTN configurations where the RF path is switched from one satellite to another, the propagation delay on each path may differ substantially and may require some adjustment, such as timing resynchronisation, to be made. In some situations, a 'virtual handover' (VHO) may be initiated while a localisation procedure is taking place. If the localisation procedure is based on measuring propagation delay, for example, round trip time (RTT) then a switch from one RF path to another with different propagation delay will have a significant effect on UE Rx-TX time difference measurements made before and after the switch. DraftCR in R4-2409287 to TS 38.133 vl8.5.0 provides that the UE Rx-Tx time difference measurement period is restarted if a VHO occurs during the measurement period and after SRS reconfiguration on the target cell is complete. Thus, when the UE performs a satellite switching with resync during the measurement period, UE shall restart the UE Rx-Tx time difference measurement after the SRS reconfiguration on the target cell is complete. In fact, a similar issue can also arise with legacy handover procedures when the UE is handed over to a second radio endpoint or base station. Again, the propagation paths may be of different lengths and ongoing Rx-Tx time difference measurements will be disrupted by the switch. In NTN scenarios, this may occur, for example, when the UE switches to a satellite that is served by a different base station or when the satellite itself, as a result of its orbital motion, moves over from one base station to another, or, in regenerative deployments, when the base stations themselves are integrated into satellites and the UE switches from one to another. A variety of TN arrangements can also give rise to this phenomenon, including, but not limited to, intra-RAN and inter-RAN handovers, sidelink relay (including multi-path) and so on. In general, the UE might be expected to cancel any ongoing Rx-Tx time difference measurements prior to a switch and restart them once the switch is complete.

This leads however to two main problems:

First, the latency of the localization procedure increases, Second, the accuracy of the localization procedure decreases.

This is illustrated by means of Fig. 19 where in case 1 refers to a normal multi-RTT positioning method wherein a UE and mobile base station perform multiple RTT measurements Ml,...Mk at times tl,...,tk, thus, at slightly different positions of the mobile base station pl,...,pk. Fig. 19, case 2, refers to the situation wherein a positioning procedure is interrupted by a handover procedure, and based on R4-2409287, the positioning procedure needs to be restarted. In this example, UE and a first mobile access device (Satellite A) start the positioning procedure making one or more measurements Ml,... at time tl,... without completing it before the handover occurs. When the handover occurs, UE and the second mobile access device (Satellite B) perform multiple RTT measurements Ml’,...Mk’ at times tl’,...,tk’, thus, at slightly different positions of the second mobile base station pl’,...,pk’. This implies that the UE location can be obtained at a later point of time, and most likely, the positioning accuracy will be lower because the second mobile access device (satellite B) performs the localization procedure when it is farthest from the UE (since it may have just entered the coverage area of the UE). It is therefore an aim of the invention to address above issues by means of the following embodiments.

In an embodiment that may be combined with other embodiments or used independently, a positioning procedure of a UE using a first mobile access device and a second mobile access device may be adapted to use measurements measured by the first mobile access device before a handover procedure and measurements measured by the second mobile access device after the handover procedure wherein the handover procedure is a handover procedure from the first to the second mobile access device. This is illustrated by means of Fig. 19, case C, wherein a UE and satellite A (in general a first UE and a first mobile access device) start a first part of a positioning procedure before a handover procedure. In this first part of the positioning procedure, UE and satellite A perform s measurements Ml, ...Ms at time tl,...,ts at locations pl’,...,ps’. Then the handover is triggered where it may be a virtual handover. Next the UE and satellite B perform k-s measurements Ms+l’,...,Mk’ at times ts+ 1 .,tk’ at locations of the second mobile access device (Satellite B) ps+l’,...,pk’. This procedure has two advantages: first, measurements are not dropped so that latency is decreased / battery lifetime of the UE increased, etc; second, the accuracy of the positioning procedure is likely to be better because pl,...,ps (Satellite A) and ps+l’,....,pk’ (Satellite B) are far from each other. This means that trilateration and/or triangulation methods can work more accurately.

In a variant of the previous embodiments that may be combined or used independently, each measurement may be associated with a measurement time (e.g., recorded by the UE or the mobile access device) and that allows determining which mobile access device was involved in the measurement.

In another variant of the previous embodiments that may be combined or used independently, a UE may be configured to perform a positioning procedure with communication parameters to perform the positioning procedure with a first mobile access device and a second mobile access device before and after a handover procedure. Communication parameters may include a set of communication resources to perform the positioning procedure, the timing of the positioning procedure, antenna parameters (e.g., beam forming), etc.

In another variant of the previous embodiments that may be combined or used independently, it may be advantageous to perform the positioning procedure by using a first mobile access device and a second mobile access device adapted to and/or configured and/or able to use measurements measured by the first mobile access device before a handover procedure and measurements measured by the second mobile access device after the handover procedure wherein the handover procedure is a handover procedure from the first to the second mobile access device. To this end, the timing of the positioning procedure (e.g., start of the positioning procedure) may be adapted to fit the point of time when the handover procedure, in general, a given communication procedure, is executed with the goal to obtain the most accurate position estimate with the least possible amount of measurements. For example, as illustrated by means of Fig. 19, case C, if a network function, e.g., location management function (LMF), requires/schedules the positioning procedure, e.g., by sending a positioning request to the first mobile access device (Satellite A), an entity, e.g., LMF itself and/or or AMF, and/or the first mobile access device and/or second mobile access device and/or UE may adapt (e.g., delay) the positioning procedure a given time Tl, e.g., T2 time units before the handover is planned/executed so that a first part of the positioning procedure is performed via the first mobile access device and a second part of the positioning procedure is performed via the second mobile access device. The T2 time units may be enough to perform Ml,..., Ms measurements as indicated in Fig. 19, Case C, and it may be such that the k-(s+l) measurements performed by / with Satellite B (second mobile access device) equals the s measurements performed by / with the first mobile access device and/or the total amount of measurements is minimized.

In an embodiment that may be combined with other embodiments or used independently, the positioning procedure is based on measuring round trip time (RTT) between the UE and the mobile access device. Each measurement is a RTT from the mobile access device at the current location p of the mobile access device. The UE and the mobile access device exchange signals to measure the RTT such as positioning reference signals or sounding reference signals. The (RTT) measurements are used to estimate the distance between the UE and the mobile access device by trilateration and/or triangulation methods. The UE may perform the RTT measurements with the first and second mobile access devices before and after the handover procedure, respectively. The UE may send the RTT measurements to the location management function, which may use the RTT measurements and the known locations of the mobile access devices to calculate the location of the UE. Alternatively, the UE may receive the locations of the mobile access devices from the location management function and calculate its own location based on the RTT measurements and the locations of the mobile access devices.

In a further embodiment that may be combined with other embodiments or used independently, the UE and/or LMF and/or other entity (e.g., mobile access device) may determine how many measurements (e.g. before, during and/or after handover) are required for a more accurate positioning procedure. For example, in case of the scenario in Figure 20 wherein the handover is performed from Satellite A to Satellite B the samples taken from Satellites A and B may be from too close locations (because Satellite B is entering the coverage area of UE from the same region where Satellite A is leaving the coverage area). This information (e.g., location of mobile access devices at the point of handover as well as the direction of movement at the point of handover, ephemeris,...) needs to be taken into account to determine how many measurements are required after handover. For instance, if the target mobile access device enters the coverage area at a far distance from the locations that were used to perform measurements by the source mobile access device (Case C, in Fig. 19), then the number of measurements taken by the target mobile access device may be lower (i.e., less than the number of measurements that were left to take by the source mobile access device if the source mobile access devicecould have finished the positioning procedure). For instance, if the target mobile access device enters the coverage area close to the locations that were used to perform measurements by the source mobile access device (Fig. 20), then the number of measurements taken by the target mobile access device may be higher (i.e., more than the number of measurements that were left to take by the source mobile access device if the source mobile access device could have finished the positioning procedure). This decision (about the number of measurements that are required by the target mobile access device) may be taken by the LMF and/or the target mobile access device and/or UE taking into account the amount of measurements that are available and the locations where they were performed as well as the locations where the new measurements are expected to be performed. In some cases, the LMF and/or UE and/or mobile access devices may also determine when the second mobile access device (e.g., Satellite B in Fig. 20) starts measuring the second set of measurements. For instance, a delay T3 may be introduced from the point of time when the handover operation is performed till measurements of the second set of measurements start to be taken. This delay T3 may prevent the second mobile access device / UE from taking measurements at locations of the second mobile access device that are close to the location where the first mobile access device was previously (and that may add little additional position information). This delay T3 may be communicated to and/or determined by the second mobile access device and/or UE. The second mobile access device and/or UE may start a timer after handover and start the measurements when the timer reaches T3. Additionally or alternatively, the second mobile access device may be communicated and/or determine a region (e.g., part of its trajectory) where no measurements should be peformed (e.g., this can be determined by knowing the locations where the first set of measurements were obtained and excluding any locations that are too close (e.g., up to a threshold) from them.

It is noted that the previous embodiments may be implemented using different or a combination of positioning techniques such as round-trip time measurements, angle of arrival, time difference of arrival, carrier phase based, etc.

In general, it is proposed a method for determining the position of a user equipment - that may be implemented in a user equipment - wherein the method comprises: obtaining a first positioning measurement set by performing a first part of a positioning procedure with a first access device wherein the first positioning measurement set includes one or more positioning measurements, performing a handover from the first access device to a second access device, obtaining a second positioning measurement set by performing a second part of the positioning procedure with the second access device wherein the second positioning measurement set includes one or more positioning measurements, and determining the user equipment location based on the first and second set of positioning measurement sets and/or sending the first and second set of positioning measurement sets to a location management function.

Additionally, it is proposed a method for determining the position of a user equipment comprises obtaining the first positioning set with a predetermined number of measurements with a first access device at predefined instant in time and/or location before performing a handover from the first access device to a second access device.

Additionally, it is proposed a method for determining the position of a user equipment comprises obtaining the second positioning set with a predetermined number of measurements with a second access device at predefined instant in time and/or location after performing a handover from the first access device to a second access device. In an embodiment, the instants in time and/or location to perform the measurements and/or the predefined number of measurements are determined based on the ephemeris data of the source and target mobile access devices, location of the UE, and/or desired accuracy of the position estimate. This allows ensuring that the accuracy of the position estimate reaches a minimum threshold and/or latency to obtain the position estimate are kept as low as possible and/or resource consumption is kept to a minimum.

Section: NTN - Security aspects of Dual Connectivity over Non-Terrestrial Networks Clause 6.10.2 in TS 33.501 describes the security procedures for dual connectivity between Master Node (MN) and a Secondary Node (SN). In both cases, it is assumed that MN and SN are connected through the Xn interface. The MN generates the K_SN for the SN and sends it to the SN over the Xn-C. To generate the KSN, the MN associates a counter, called an SN Counter, with the current AS security context. The SN Counter is used as freshness input into KSN derivations as described in the clause 6.10.3.2. The MN sends the value of the SN Counter to the UE over the RRC signalling path when it is required to generate a new K SN. The K SN is used to derive further RRC and UP keys that are used between the UE and SN. Steps 1-7 in Fig. 6.10.2.1-1 (Security aspects in SN Addition/Modification procedures (MN initiated)) need to take place when MN and SN (mobile access device) are in reach, e.g., when SN is reachable from a terrestrial NTN-gateway. At this stage, the SN is configured with K SN that allows the UE to perform the random-access procedure with SN. To this end, MN shall make sure that SN remains connected long enough before sending/receiving the RRC Connection Reconfiguration (Step 5 and 6) so that MN is able to send the SN Reconfiguration Complete (Step 7).

If this procedure is initiated by the SN (Clause 6.10.2.2.3), e.g., When uplink and/or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs or SCG SRB, the SN may be in S&F mode (because of out of coverage). Thus, instead of getting the updated K SN through MN, SN may trigger the K SN update through the UE so that it may get the updated K SN through the UE where the UE acts as a relay forwarding the updated K SN from MN. For instance, UE may provide SN with the new K SN protected in an RRC message. Additionally or alternatively, MN may have configured SN with a key K’ to be used in such a situation, so that if MN and SN are not directly connected, but MN and SN may be connected through the UE, MN may provide the new K SN protected (in terms of confidentiality and/or integrity) with K’ .

Section: NTN - AMF as part of the mobile access device

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 cormectivity 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 NAS 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 w ithout 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 verify that message. If, alternatively, the AMF is located on earth, the connection / link between mobile access device and AMF may fail, so that the procedure may not ahvays 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 aw are when it has to wake up and (re-)connected. In some cases, the UE may only need to w ake up and perform transmission.

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.

The satellite may w ork in store and forw ard 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 w ith the ground AMF. In this case, the onboard AMF may perform its CIoT functionalities, such as exchanging small user data or SMS w’ith the UEs via NAS messages. The onboard AMF may also keep track of die used keys, nonces, counters/timers, etc. for each UE and update them accordingly. Once the mobile access device establishes a connection w’ith 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 w-ay, 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.

Section: NTN - Further Lawful interception aspects

In another embodiment of the invention that is related to lawful interception (LI) requirements, the provisioning of the security materials (e.g., security keys, nonces, counters/timers, etc) may depend on or be done in coordination with a NF (e.g. LI NF) responsible for ensuring LI requirements are met whereby, the security keys are provided to said LI NF, and only upon receiving an acknowledgment from LI NF does a network provision the security materials to the UEs. Similarly, the mobile access device may provide the LI NF with any additional configuration parameters used in the derivation of security keys e.g., encryption/integrity keys, whether these parameters are exchanged between the UEs through the mobile access device, or distributed by the mobile access device itself, e.g., to enable UE to UE communication over the mobile access device. The mobile access device may provide the LI NF directly, or through a NF in the core network, e.g., AMF, etc in charge of managing those keys.

A mobile access device may cover/move over different countries in such a way that all keys or data stored in the mobile access device may need to be made accessible to LI authorities when the mobile access device is under the corresponding country’s jurisdiction. To avoid this, in another embodiment that may be combined with other embodiments or used independently:

1) the serving network or the home network or the mobile access device provider may require to handover the UE communication from a first access device (about to leave the jurisdiction of a country) to a second access device (still in the jurisdiction of the country) where the handover condition may be the fact that the first access device is about leaving the country jurisdiction, or has left the country jurisdiction.

2) This event, the first access device is about leaving the country jurisdiction, may also further trigger the removal of any stored data (e.g., user data, or control data such as keys) stored in the mobile access device when working in (store and forward) S&F mode. This may also apply to information stored in the mobile access device when the mobile access device works in regenerative manner (base station) or includes some core network NF such as an AMF described in other embodiments.

3) This event, the first access device is about leaving the country jurisdiction, may also trigger the renewal of keying materials such as AS context or NAS context, e.g., the access device may indicate to a UE the need for changing the current access device root keying material (e.g., indicate change of K gNB in the 5GS, by means of the HO Command message).

4) The event, the first access device is about leaving the country jurisdiction, may also trigger that the first access device sends an indication to a UE, e.g., a connected UE, via a SIB (e.g., SIB1 or SIB19) or an RRC message, so that the UE may take this information into consideration to, e.g., perform a conditional handover, perform path switch, perform cell reselection, etc.

A policy that depends on above condition, i.e., that the first access device is about leaving the country jurisdiction, may be configured by the network operator in a network function of the core network, e.g., AMF, or in the first access device itself, or in a UE being served by the first access device. The policy may specify the specific actions to perform when the condition occurs.

In line with above embodiment, draft_s3i240059 introduces definitions and requirements for Location dependent Interception for NTN and moving base station, including definitions:

• Interception Area: Geographical area where Location Dependent Interception (LDI) applies. It is defined by agreement between LEA(s) and the communication service provider (CSP).

• Location Dependent Interception: The interception is dependent on the target location and/or extra context information such as the country of registration of a vessel (if available), or extra territorial requirements (e.g. international maritime and aeronautical zones) in order to let the CSP system determine the applicable jurisdiction for interception.

• Moving Cell: A cell for which the general area of coverage is moving in relation to the surface of the earth. For example, such cell may be in a moving facility such a train, a boat or an airplane or be in a satellite.

They lead to new requirements aligned with above embodiment:

• R6.3 - 276 Mobile Cell Identification - The CSP shall be able to report when a cell is capable of moving and what type of facilities the cell is located in.

• R6.3 - 277 Cell Movement Identification - The CSP shall be able to report when the coverage location of a mobile cell changes in near real time.

• R6.3 - 278 Mapping of Moving Cell - The CSP shall be able to provide the geographical location of mobile cells at the time of reported events on a periodic basis or on demand by the LEA.

• R6.3 - 279 Location of a moving cell - If a base station is located in a vessel the geographical location of the vessel will be reported. If a base station is located in a high altitude platform the geographical location of the centre of the footprint of the cell will be reported in combination with a size indication of the footprint.

• R6.3 - 290 Trusted/Untrusted Location - The location information reported to the LEMF shall be location information trusted by the 3GPP network (i.e. the location information is either 3GPP network provided or verified), if available. The CSP shall also be able to report and to verify where possible by the network location information from untrusted sources (e.g user equipment provided).

• R6.3 - 600 Location Verification for NTN - The CSP shall be able to verify the GNSS coordinated reported by the UE when connected via NTN.

• R6.3 - 700 Location Accuracy for NTN - The granularity of the network verified location information shall be at least comparable to terrestrial network ones.

• R6.5 - 20 Interception Temporary Reduction - The CSP shall be able to both suspend (e.g. when roaming outbound internationally, or crossing Interception Area boundary in case of LDI) and resume all or a portion of the obligated Interception Product during the Interception Period.

• R6.5 - 90 Location Dependent Interception Management - The CSP shall be able to continuously monitor the target’s location during on-going communications or for any mobility management event and deliver interception product to the applicable jurisdiction when the target is in the Interception Area (IA). For Location Dependent Interception situations mutual legal assistance treaties might apply between LEAs.

• R6.5 - 100 LI Policy based on Location and Context - The CSP shall be able to locate permanently each target in a trusted (verifiable, reliable) manner with sufficient accuracy in order to determine the policy based on jurisdiction requirements. The applicable policy can be defined based on the UE location, Network based location and context (e.g. flag of a vessel or an airplane).

• R6.5 - 200 Location in Non Terrestrial Network - The CSP shall be able to obtain and report UE locations with similar granularity accuracy as with terrestrial networks.

Related to R6.3 - 279, if the LI authority /LI NF obtains the location of the moving cell, and the moving cell is about crossing an Interception area boundary, e.g., leaving the jurisdiction of a country and entering the jurisdiction of another country, the LI authority/LI NF may have deployed a configuration or send a request to the CSP to trigger some of the actions in above embodiment.

Similarly, R6.5 - 20 may also trigger some of the actions in above embodiment, e.g., removal of keys that may otherwise end in the hands of a different country /interception area.

In a further embodiment that may be combined with other embodiments or used independently, a mobile access device may be configured to enable UE to UE communication where said communication is executed through the mobile access device. In this case, the mobile access device may be required, e.g., by means of a policy as in other embodiments, to keep a record of the exchanged data, e.g., over the user plane. This policy may include how long the data should be stored and to which jurisdiction it belongs. The data may be downloaded, automatically or based on policy, to a ground data base within the jurisdiction where the data was exchanged and erased from the mobile access device, in particular, if the mobile access device moves out of the jurisdiction where the data was exchanged and/or upon receiving an acknowledgment of receipt from the ground LI station.

In another embodiment that may be combined with other embodiments or used independently, a lawful interception (LI) network function (NF) may be deployed in the mobile access device, e.g., the NTN access device, to monitor communications between the first UE and the second UE over the IMS service. The LI NF may determine, based on a policy or a configuration, whether the communication is subject to interception by a group of LI authorities or LI NFs, or whether it is only to be stored and forwarded at a later point of time. For example, the policy or the configuration may specify the criteria for identifying the communication that needs to be intercepted, such as the identities of the UEs, the type of the IMS service, the location of the mobile access device, the content of the communication, etc. The LI NF may also determine, based on the policy or the configuration, whether the communication can be continued or terminated in case of a critical situation, such as an imminent threat, a legal violation, a national security issue, etc. The LI NF may send an alert to the group of LI authorities or LI NFs if the communication meets the criteria for interception, and may share the communication data with them without delay. Alternatively, the LI NF may store the communication data locally in the mobile access device and forward it to the group of LI authorities or LI NFs when a connection is established with them, either periodically or upon request. The LI NF may also stop the communication between the UEs if the policy or the configuration indicates that the communication should be terminated in case of a critical situation.

In another embodiment that may be combined with other embodiments or used independently, the UE's HPLMN (Home Public Land Mobile Network) may require performing a new primary authentication with the UE when the mobile access device serving the UE or having served the UE crosses a country jurisdiction, to make sure that the keys are not compromised. This may happen because the UE performed a previous handover to another (new) mobile access device and the previous (old) mobile access device moved to another area where it may be subject to different laws. For example, the HPLMN may send a request to the UE to initiate a new primary authentication procedure via the new mobile access device, or the UE may detect the change of the mobile access device's location and trigger the new primary authentication procedure by itself. The old keying material may be discarded by the UE and the HPLMN after the new primary authentication procedure is completed. For this embodiment, the HPLMN may need to be configured with the ephemeris of the mobile access devices, such as satellites, or the UE may need to inform the HPLMN about its handover procedures, so that the HPLMN can determine when the mobile access device crosses a country jurisdiction.

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

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:

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.

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.

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. 4) 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.

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.

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.

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. 4) 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.

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.

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.

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. 4) 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 next NTN gateway, satellite's load, UE location, speed, and direction (e.g., if shared by the first UE 100), and network (pre-)configuration(s), etc.

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 next NTN 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.

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. 4). To address these problems, the following embodiment variants may be applied:

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.

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.

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.

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.

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.

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.

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).

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.

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.

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).

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.

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.

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.

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

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.

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.

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.

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.

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.

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 2^A{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:

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.

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 verify the UE before receiving/processing a large amount of data.

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.

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).

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).

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.

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 verily 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.

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 verily that the temporary ID 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. 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:

ID1, Keyl, In 10', ID_Mobile_Access_Device_2

ID2, Key2, In 20', ID_Mobile_Access_Device_3

ID3, Key3, In 30', ID_Mobile_Access_Device_4

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.

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:

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.

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.

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. 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.

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.

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 verily 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.

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.

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.

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 configmed 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:

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.

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 SIB19, 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.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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.

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 verify 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.

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.

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

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.

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.

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. In general, 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.

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;

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.

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

Aspect 1 : the apparatus is configured 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.

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. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

Section: NTN - Protection of SIB19 in Non-Terrestrial Networks

A further embodiment may refer to non-terrestrial networks wherein non-terrestrial access devices such as satellites or unmanned aerial vehicles provide connectivity to end devices (EDs), such as UEs. Important information that needs to be verified refers to data of the non-terrestrial access devices such as ephemeris data. Fig. 9 shows schematically an embodiment of a procedure for the protection of the system information block SIB19 which was introduced by 3GPP in Release 17 providing NTN-specific parameters for serving cell and/or neighbour cells. The description of the SIB19 information element is defined in TS 38.331.

SIB 19 provides NTN-specific parameters for the serving primary station and/or close primary station. In particular, SIB 19 includes assistance information of the non-terrestrial access device, for example, Ephemeris data, common timing advance parameters, koffset, validity duration for UL synchronization epoch time, cell reference location, timing advance reporting during initial access, cell stop time as described in TS 38.331. If fake information is distributed or this information is modified, it can heavily affect the communications of the UEs/EDs because they will not be able to properly communicate. Thus, the content of SIB19 should be protected. To this end, this invention and the invention variants may be applicable. The diagram of Fig. 9 indicates message flows between entities shown on the top while the time t moves forward from the top to the bottom of Fig. 9.

According to Fig. 9, an end device (ED) or UE 1700 as well as a first base station or primary station 1701 and a second base station or primary station or an NF or an AF 1711 are involved in the procedure. Message 1702 represents a distribution of system information such as MIB or SIB1. Messages 1703 and 1704 represent a random-access procedure. Messages 1705 and 1706 represent respective requests from the ED 1700 to the first and second base stations 1701 and 1711 to retrieve a security information for SIB 19 for a given non -terrestrial primary station. The ED 1700 may also request a security information to verify the SIB 19 of non-terrestrial primary stations available in a given area at a given time (e.g., for the current hour in the location where the ED 1700 is located). The second base station 1711 may then return one or more security information messages 1707 to the ED 1700 which may then use the received security information to verify the SIB 19 (if already received). Additionally or alternatively, the ED 1700 may send a request 1708 to retrieve the SIB19. This request may also include a security information request (message 1710) related to SIB 19. The first base station 1701 then delivers the SIB19 in message 1709 and SIB19’s security information in message 1712. Additionally or alternatively, the ED 1700 may send a request to retrieve SIB19. This request may not include a security information request related to SIB19. The first base station 1701 then delivers SIB19 in message 1709. The SIB, in this case SIB 19, may include an indication of protection, so that the ED 1700 may send a subsequent security information request in message 1710. The first base station 1701 delivers the SIB19’s security information in message 1712.

Additionally or alternatively, the managing entity of the non-terrestrial primary station may not want to make the information of SIB19 public and accessible to all EDs. Thus, the managing entity may select a key K for a given time period and use K to confidentiality protect the data in SIB 19. An ED interested in the usage of the non-terrestrial primary station may send a request to the network (e.g., a NF) or an AF, e.g., representing the managing entity of the non-terrestrial primary station to get authorization to make use of said services. This request may be authenticated by means of AKMA (TS 33.535) or GBA. Upon authentication, the NF or AF may further check whether the ED is authorized, e.g., if the ED has subscribed to the services of the non-terrestrial access device. This may require sending a request to an authentication function such as AUSF or UDM where the ED profde may be located. Upon authentication, the AF/NF may securely deliver the key K to the ED. Fig. 10 shows schematically a procedure of the above overall approach according to an embodiment, where involved entities are an ED 1800, a first primary station (e.g., a non-terrestrial primary station) 1801, a second primary station (e.g., a terrestrial primary station) 1802, a network function (NF) or application function (AF) 1803 in the core network of the cellular system, and an authentication function 1804. Message 1805 represents an initial distribution of system information, e.g., MIB/SIB1. Messages 1806/1807 represent an initial process (random access procedure) to access the first primary station including a registration request. In this procedure, message 1805 may indicate that certain SIBs are confidentiality protected (in this case, SIB19) and require authentication/authorization for accessing them. In this procedure, a security information request may be sent by the ED 1800 to the first primary station 1801 with message 1808. The returned security information may indicate that certain SIBs are confidentiality protected, in this case, SIB 19, and require authentication/authorization for accessing them. Message 1809 represents a message or procedure towards the NF 1803 in the CN/AF in order to get authenticated/authorized to use the first primary station 1801. This can be a network access message or part of the primary authentication. This request 1809 may be sent through the second primary station

1802 (e.g., if it refers to an AKMA procedure), or it may be sent through the first primary station 1801 where the first primary station 1801 may only allow such message/procedure, e.g., primary authentication. Once the NF 1803 has authenticated the ED 1800, the NF 1803 may send a request to the authentication function 1804 (e.g., AUSF, UDM, or external data base) with message 1810 to verily that the ED 1800 has a valid subscription. The answer is provided in message 1811. Based on it, the NF

1803 may provide the ED 1800 with key K used to protect SIB19 (message 1812). Additionally, or alternatively, the ED 1800 may receive the content of SIB19 in this message 1812. With subsequent message 1813, the ED 1800 may request further SIB19 information from the first primary station 1801. With message 1814, the NF 1803 may provide the first primary station 1801 with the SIB19 information, and/or the key K to protect the SIB 19 information, and/or the protected data to be carried in the SIB19. Finally, with message 1815, the protected information of the SIB19 is distributed by the first primary station 1801 by means of the SIB 19. It is to be noted, that next to K, the ED 1800 may receive other auxiliary data such as the protection algorithms used to protect the SIB information (e.g., NEA and or NIA algorithms). Protection may mean confidentiality and/or integrity protection.

Throughout the above embodiments, the applications, e.g., metaverse or teleconferencing or video streaming, etc, making use of the communication infrastructure may be capable of configuring and using the communication infrastructure for optimized performance.

Section: Application to cellular technologies 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.

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:

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

- 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.

- 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.

- 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.

- 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.

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

- 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.

- 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.

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

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.

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

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.

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.

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, .

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.

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.

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.

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) [17] and 3GPP TS 24.501 (Release 15) [18], 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.

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.

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.

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).

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.

The main protocols used between the UEs and the RAN are:

- 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.

- 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.

- 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.

- 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.

- 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.

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.

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

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.

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.

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.

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.

In reference to Fig. 21, 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.

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.

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.

Furthermore, a satellite gateway 141 is shown that connects to satellite 140 and may provide connectivity services to remote UE 136 or UE 100. In Fig. 21, 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.

In Fig. 21, 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.

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.

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

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.

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.

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. 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 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

1. 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, comprising: the apparatus receiving a command from the first core network through the first access device to establish a multipath connection over the first access device and a specified access device and/or a second core network using a set of configuration parameters for the multipath connection; if not yet connected to the specified access device and/or second core network, the apparatus connecting to the specified access device and/or the second core network; and the apparatus starting the multipath connection for one or more services over the first access device and the specified access device and/or the second core network by applying the set of configuration parameters.

3. The method of claim 1, comprising: the apparatus receiving 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 yet connected to the specified access device, the apparatus connecting to the specified access device; and starting the connection for one or more services over the specified access device.

4. The method of claims 2 and 3, comprising the apparatus performing the preferred authentication procedure with the first core network using a first SIM and connecting to the specified access device and/or the second core network using the credentials in a second SIM.

5. The method of claims 2 or 3, wherein the set of configuration parameters includes one or more of: access information including parameters for a random access procedure comprising timing or location or physical cell identity of the specified access device; an operation mode of the specified access device (such as regenerative, transparent or mixed regenerative/transparent operation mode as well as store and forward mode); a storage time used by the specified access device in a store and forward mode; a keying material such as a key to connect to the specified access device; a keying material such as a key to communicate with a first user equipment through the specified access device;

IP addresses for the different communication paths; details of a joint PDU session or multiaccess PDU session; a setting for steering of roaming information for a DualSteer device; a congestion state for different paths and/or for communication path segments of the multipath communication; congestion window for different paths and/or for communication path segments of the multipath communication; round trip time for different paths and/or for communication path segments of the multipath communication; a method to determine round trip time; a method to schedule packets; and services to which the connection are applicable.

6. The method of claims 2 or 3 or 4 or 5, wherein the apparatus connecting to the specified access device includes: performing primary authentication with on-board core network components and/or by means of keying materials received in the configuration parameters, wherein the keying materials include an authentication server key and/or a network access server key.

7. The method of claims 2, 4, or 5, comprising the apparatus: exchanging a first token through the first access device with the first core network; exchanging a second token through the specified access device with the second core network of the specified access device.

8. The method of claim 7, comprising the apparatus checking the first and second tokens to validate the establishment of the multipath connection.

9. The method of claim 8, wherein validating the establishment of the multipath connection comprises checking that the first token and the second token are equal.

10. The method of claim 7, 8 and 9, wherein the first token and/or the second token contains one or more of: a unique identifier (DS identifier) generated by the first core network or the apparatus, a role that a first subscriber permanent identifier, SUPI, is authorized to take (such as primary or secondary), a role that a serving network is authorized to take,

SUPI or SUPIs or other identity such as GUTI that may be associated with the primary /secondary SUPI, services available by means of a DualSteer connection, conditions under which the services are provided (e.g., a given UE location), or a Radio Access Technology, 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).

11. The method of claims 1 and 2, comprising: the apparatus receiving or being configured with a first SIM, obtaining a first PIN for the first SIM, unlocking the first SIM by means of the first PIN, verifying the presence of a peer SIM plugged into or configured in the apparatus, adjusting the enabled communication parameters based on the peer SIM verification, and applying the enabled communication parameters when checking and performing the preferred authentication procedure.

12. The method of claim 11, wherein the apparatus supports at least three types of enabled communication parameters: emergency only, wherein the apparatus cannot check the presence of the peer SIM plugged to the same mobile equipment and the first SIM contains a secondary SUPI, standard UE, wherein the apparatus cannot check the presence of the peer SIM plugged to the same mobile equipment and the first SIM contains a primary SUPI, and

DualSteer UE, wherein the apparatus can check the presence of the peer SIM containing a secondary SUPI plugged to the apparatus and the first SIM contains a primary SUPI.

13. The method of any one of claims 2, 4, 5, or 6, 7, 8 or 9, comprising the apparatus initiating an authentication and key management for applications, AKMA, procedure by sending a first AKMA request over the first access device and running a Ua protocol over the first access device and the specified access device and/or the second core network based on keying material bound to the first core network of the first access device.

14. The method of claims 2 or 3, comprising the apparatus performing the preferred authentication procedure with the first core network using a first SIM and connecting to the specified access device and/or the second core network using the credentials in a second SIM.

15. The method of claim 14, wherein the method comprises selecting a first credential and a second credential from a set of two or more credentials.

16. The method of claims 2, 3, 14, or 15, comprising the apparatus determining by a policy the specified access device and/or the second core network that the connection is to be steered towards, wherein the steering depends on service QoS of the first core network through the first access device.

17. The method of claim 15, wherein each credential of the two or more credentials is linked to a corresponding subscription that indicates whether it can be used as part of a DualSteer connection and usage conditions.

18. The method of claim 2 and 14, wherein the configuration parameters include an identifier of the multipath or DualSteer connection.

19. The method of claims 1, 2 or 3, comprising the apparatus receiving an indication of the operation mode of the first access device or specified access device including at least one of: regenerative, transparent, or mixed regenerative/transparent operation mode as well as store-and-forward mode; and storage time used by the specified access device in a store-and-forward mode; wherein the apparatus selects suitable communication parameters based on the indication of the operation mode, when performing the authentication procedure and/or setting up the communication connection.

20. The method of claims 1, 2 or 3, comprising the apparatus: including an authentication procedure identifier and/or a timing value in fields of messages of the preferred authentication procedure; and using the fields to differentiate messages of different security procedures and/or to determine whether a received message has been stored by the access device.

21. The apparatus of claims 1, 2, 3, 19 or 20, wherein at least one of the following conditions apply to the preferred authentication procedure: the preferred authentication procedure may only be performed over an access device in Store and Forward mode if the apparatus is configured with a policy or configuration enabling it ; the preferred authentication procedure includes an indication of whether the authentication procedure is or may be performed over an access device in Store and Forward mode; a NAS registration request or NAS attach request shall not be initiated over a second NAS connection to a mobility function of the same network before primary authentication on a first NAS connection is completed unless this first NAS connection was done, e.g., through a mobile access device with store and forward capability; and primary authentication messages include a timing value or an identifier.

22. The method of any one of claims 1, 2, 3, 5, 19, 20, or 21, comprising the apparatus: initiating a communication link or receive a request to setup a communication link with a remote user equipment; and establishing said communication link using the first and/or selected access device as a relay; wherein the apparatus communicates with the remote user equipment using the relay in either transparent or regenerative or store and forward relay communication mode.

23. The method of claim 22, wherein the initiating the communication link is performed towards an IMS network by means of a SIP INVITE message and the communication with the remote user equipment is performed in user plane.

24. The method of claim 23, wherein the apparatus receives a 200 OK response from the remote user equipment through the first and/or selected access device acting as a relay.

25. The method of claims 23 and 24, wherein the SIP INVITE and/or 200 OK response includes an indication requesting/confirming the usage (authorization) of a given RAT for the IMS service.

26. The method of claims 23, 24, and 25, wherein the apparatus communicates with the remote user equipment in transparent mode and is configured with parameters for secure communication between the apparatus and the remote user equipment at PDCP layer, wherein the parameters comprise one or more of sequence number, usage of MAC-I, COUNT value, key ID, key type (integrity or confidentiality), and key value.

27. The method of any one of claims 1, 2, 6, 19, 20, 21, 22- 26, comprising the apparatus receiving an authorization to setup the communication connection with or through the first or selected access device based on at least one: a user subscription, the type of communication connection, whether the apparatus may connect to a terrestrial RAT, and the location of the apparatus and/or relay and/or remote user equipment.

28. The method of claim 3, comprising the apparatus connecting to the specified access device and disconnecting from the first access device when the first access device moves outside of the current lawful interception jurisdiction or a defined area where the apparatus is located.

29. The method of claims 2, 3 and 28, wherein the connection to the specified access device and/or the second core network is only allowed upon verification of lawful interception requirements and configuration to fulfil said lawful interception requirements.

30. The method of claim 3, comprising the apparatus storing a configuration determining whether keys need to be derived and specifying a point of time for the key derivation when connecting to the specified access device, wherein (1) the keys refer to new Access Stratum, AS, keys or dual connectivity keys and (2) the specified point of time before the apparatus establishes the connection.

31. The method of claim 3, comprising the apparatus synchronizing to the specified access device, wherein the specified access device acts as a secondary cell and the synchronization is done by means of signaling from the first access device acting as primary cell.

32. The method of claim 3, comprising: the apparatus receiving a set of positioning configuration parameters determining the positioning measurements to obtain from the first access device and a specified access device, the apparatus obtaining a first positioning measurement set by performing a first part of a positioning procedure with the first access device wherein the first positioning measurement set includes one or more positioning measurements, the apparatus performing a handover or a cell switch from the first access device to the specified access device, the apparatus obtaining a second positioning measurement set by performing a second part of the positioning procedure with the specified access device wherein the second positioning measurement set includes one or more positioning measurements, and the apparatus determining the user equipment location based on the first and second set of positioning measurement sets and/or sending the first and second set of positioning measurement sets to a location management function.

33. The method of claim 3, comprising

- the apparatus receiving a SIB broadcasted or RRC message transmitted by the first access device and/or the specified access device wherein the SIB or RRC message determines the operation mode of the first access device and/or the specified access device, where the operation mode is one or more of:

- store and forward mode,

- transparent mode,

- regenerative mode,

- transparent/regenerative mixed mode,

- the apparatus selecting a preferred authentication procedure based on the determined operation mode.

34. The method of Claims 3 and 33, comprising the apparatus determining, based on a configuration with credentials and/or a policy, the conditions under which the apparatus is authorized to perform a primary authentication procedure through an NTN access device wherein the conditions include one or more of:

- operation mode,

- whether the apparatus has access to any (terrestrial) access device, and

- the timing and location in which such a connection is allowed.

35. The method of claims 3 and any one claims of 28 to 34, comprising:

- the apparatus indicating to the network that the primary authentication attempt over a first access device is taking place when the first access device is operating in store and forward mode and/or

- the apparatus receiving the connection details associated with the primary authentication attempt over the first access device, wherein the connection details may include one or more of (1) paths, (2) satellite identity, (3) timing delay, (4) S&F timer, and (5) credentials such as cryptographic keys used to finalize the primary authentication attempt for the connection.

36. The method of any of claims 3-35, wherein the apparatus is configured with an S&F emergency configuration and the method comprising: the apparatus selecting a first access device based on the S&F emergency configuration and whether the first access device announces its support for emergency services, and the apparatus using the S&F emergency configuration to prove it is entitled to request emergency services, such that the emergency service request includes one or more of:

- urgency level,

- remaining lifetime, and

- emergency credentials, and the emergency service request/indication is included in: an RRC message, and/or a NAS registration message,

37. The method of any one of claims 3-36, wherein the configuration parameters comprise policies and or credentials which include 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 data when the first access device is working in store and forward mode, or 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.

38. The method of any one of claims 3-37, comprising the apparatus receiving 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.

39. The method of any of claims 3-38, wherein the apparatus is configured with a public key prior to the check or selection of the preferred authentication procedure and/or may receive the public key from the first access device when performing the preferred authentication procedure, wherein the apparatus uses the public key to protect its identity, e.g., IMSI or SUPI, and the public key is linked to a private key specific to the first access device such that only the first access device can decrypt the protected identity.

40. The method of any of claims 3-39, comprising the apparatus performing an authentication procedure with the first access device, whereby the apparatus receives a first value (RAND) from the first access device, and the apparatus computes an authentication tag based on the first value and a long-term secret shared with its home network.

41. The method of any of the previous claims, comprising the apparatus sending a message to the first and/or specified access device wherein the message includes an authorization token that may be used during the preferred authentication procedure, whereby the authorization token serves as proof of authorization to send the message when the first access device is operating in store and forward mode, and where the message may be a message used to initiate or perform the preferred authentication procedure (e.g., a primary authentication) and/or transmit data.

42. The method of any of the previous claims, comprising: the apparatus receiving 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 shortterm credentials are for a second preferred authentication and authorization procedure with a second access device, the apparatus performing the second preferred authentication and authorization procedure with the second access device by using the short-term credentials, and the apparatus exchanging (send or receive) data with and/or through the second access device.

43. The method of claim 42, wherein the short-term credentials are valid for a short-term time window and the short-term credentials may comprise at least one of: 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.

44. The method of claims 42 and 43, 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/or to sign a message including the UTC time and a transaction identifier, and including the authentication tag and/or the signature and short-term certificate to the exchanged data with the specified access device.

45. The method of any one of the previous claims, comprising the apparatus receiving or determining keying materials from a key distribution entity wherein the key distribution entity is located in the first or selected access device or in a Network Function, NF, in the core network wherein the received or determined keying materials are used to secure the communication with the remote user equipment by encrypting or authenticating the communication at PDCP layer and/or by using one or more of:

IPSec,

TLS, and

MPQUIC.

46. The method of any of claims 2 and 3, comprising the apparatus deciding when and how to distribute the uplink/downlink traffic / manage a service across the first access device/first core network and selected access device/second core network based on (1) measurements of local conditions, and (2) expected network behavior configured by means of a network provided policy or configuration.

47. The method of any of the previous claims, wherein the first access device or the specified access device is a satellite, or an unmanned aerial vehicle, or a vehicle.

48. 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.

49. A user equipment comprising the apparatus of claim 48.

50. A computer program product comprising code means for producing the steps of the method of any one of claims 1-47 when run on a computer device.