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

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

[0001] METHOD, APPARATUS, AND SYSTEM FOR ENHANCED AUTHENTICATION,

[0002] AUTHORIZATION, AND CONNECTION MANAGEMENT IN CELLULAR NETWORKS

[0003] FIELD OF THE INVENTION

[0004] 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.

[0005] BACKGROUND OF THE INVENTION

[0006] 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).

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] SUMMARY OF THE INVENTION

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] According to a third aspect of the invention, it is proposed a user equipment comprising the apparatus of the first aspect.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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

[0038] In the following drawings:

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

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

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

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

[0043] 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;

[0044] 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;

[0045] 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;

[0046] 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;

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

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

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

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

[0051] 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;

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

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

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

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

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

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

[0058] 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

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

[0060] DETAILED DESCRIPTION OF EMBODIMENTS

[0061] 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.

[0062] 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.

[0063] 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.

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

[0065] 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.

[0066] 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.

[0067] [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.

[0068] 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).

[0069] 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).

[0070] 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.

[0071] [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.

[0072] 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.

[0073] [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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] [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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] [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.

[0084] 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.

[0085] 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.

[0086] 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;

[0087] 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.

[0088] 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;

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

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

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] Dual steer: basic introduction

[0097] 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.

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

[0099] 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.

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

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

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

[0107] 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.

[0108] 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.

[0109] 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.

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

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

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

[0113] 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).

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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

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

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

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

[0125] - 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;

[0126] - 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;

[0127] - 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;

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

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

[0130] Section: Dual steer - Registration and verification that a DualSteer UE is connected to two or more networks

[0131] 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:

[0132] Inti:

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

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

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

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

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

[0138] Int8: (UE(SIM2) -> ) UE(SIM1) -> PLMNI -> PLMN2 (-> UE(SIM2)) ( -> PLMN2)

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] Section: Dual steer - further authentication aspects

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.:

[0154] Stop the second primary authentication procedure;

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

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

[0157] 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:

[0158] - reject the second primary authentication procedure,

[0159] - instruct the UE 1100 to switch back to the first serving network 1101,

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

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

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

[0163] 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.

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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.

[0169] 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.

[0170] 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.

[0171] 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:

[0172] 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.

[0173] 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).

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

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

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

[0177] 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).

[0178] 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.

[0179] 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.

[0180] 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.

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

[0182] 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,

[0183] 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

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

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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. :

[0195] 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.

[0196] 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.

[0197] 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

[0198] 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.

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

[0200] 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.

[0201] 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.

[0202] 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.

[0203] 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.

[0204] 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.

[0205] Section: DualSteer - (re)establishing of a connection with a second network triggered by the first network.

[0206] 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:

[0207] 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.

[0208] 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 :

[0209] 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.

[0210] 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.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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:

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

[0216] 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

[0217] 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.

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

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

[0220] 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:

[0221] 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.

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

[0223] 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.

[0224] 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.

[0225] 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.

[0226] 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.

[0227] 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.

[0228] 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.

[0229] 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:

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

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

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

[0233] 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.

[0234] 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.

[0235] 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),

[0236] 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”).

[0237] 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.

[0238] 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.

[0239] 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).

[0240] 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.

[0241] 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.

[0242] 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.

[0243] 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.:

[0244] (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;

[0245] (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.

[0246] 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.

[0247] 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.

[0248] 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.

[0249] 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.

[0250] 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.

[0251] 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.

[0252] 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).

[0253] 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.

[0254] 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

[0255] 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

[0256] 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.

[0257] 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.

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

[0259] 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.

[0260] 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.

[0261] 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.

[0262] 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.

[0263] 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.

[0264] 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.

[0265] 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.

[0266] 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.

[0267] 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.

[0268] 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.

[0269] 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.

[0270] 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.

[0271] 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.

[0272] Section: DualSteer - Steering of roaming information

[0273] 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.

[0274] Section: Multiple networks / RATs and PC5 interface

[0275] 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.

[0276] 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.

[0277] 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.

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

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

[0280] 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.

[0281] 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:

[0282] (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

[0283] (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.

[0284] 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.

[0285] Section: Dual steer - Lawful interception

[0286] 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:

[0287] (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.

[0288] (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.

[0289] (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.

[0290] Section: Dual steer - adaptation of communication parameters

[0291] 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:

[0292] 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.

[0293] 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.

[0294] 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.

[0295] 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.

[0296] Section: ATSSS - non-3GPP access

[0297] 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.

[0298] 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.

[0299] 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).

[0300] 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).

[0301] 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.

[0302] 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).

[0303] 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.

[0304] 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.

[0305] 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.

[0306] 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.

[0307] 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.

[0308] 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.

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

[0310] 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.

[0311] 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.

[0312] 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.

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

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

[0315] 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).

[0316] 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.

[0317] 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.

[0318] 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).

[0319] 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.

[0320] 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.

[0321] 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.

[0322] 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.

[0323] 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.

[0324] 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.

[0325] 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.

[0326] 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.

[0327] 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.

[0328] 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.

[0329] 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.

[0330] 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.

[0331] 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.

[0332] 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.

[0333] 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.

[0334] 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.

[0335] 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.

[0336] 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.

[0337] 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.

[0338] 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.

[0339] 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.

[0340] 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,

[0341] 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.

[0342] 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.

[0343] 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.

[0344] 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.

[0345] 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:

[0346] 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).

[0347] 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.

[0348] 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.

[0349] 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.

[0350] 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).

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

[0352] 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.

[0353] 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).

[0354] 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.

[0355] 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.

[0356] 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)).

[0357] 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.

[0358] 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.

[0359] 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.

[0360] 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.

[0361] 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.

[0362] 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.

[0363] 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.

[0364] 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.

[0365] 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).

[0366] 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.

[0367] 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.

[0368] 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.

[0369] 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:

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

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

[0372] • 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.

[0373] 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.

[0374] Section: NTN - Procedures to enable UE-Satellite-UE communications

[0375] 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;

[0376] 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.

[0377] 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.

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

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

[0380] 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;

[0381] 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.

[0382] 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;

[0383] 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,

[0384] 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;

[0385] 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;

[0386] 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;

[0387] 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.

[0388] 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.

[0389] 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.

[0390] 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.

[0391] 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.

[0392] 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.

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

[0394] 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.

[0395] Section: NTN - Procedures for secure UE-Satellite-UE communications

[0396] 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.

[0397] 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.

[0398] 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).

[0399] 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.

[0400] 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.

[0401] 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.

[0402] 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.

[0403] 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.

[0404] 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).

[0405] 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).

[0406] 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.

[0407] 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.

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

[0409] 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.

[0410] 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.

[0411] 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.

[0412] 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.

[0413] 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.

[0414] 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.

[0415] 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.

[0416] 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.

[0417] 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.

[0418] 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.

[0419] 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.

[0420] 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.

[0421] 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.

[0422] 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.

[0423] Section: NTN - Virtual handover

[0424] 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,

[0425] 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).

[0426] 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.

[0427] 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.

[0428] 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.

[0429] 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.

[0430] 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.

[0431] 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 2A16 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.

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

[0433] 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.

[0434] This leads however to two main problems:

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

[0436] 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.

[0437] 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.

[0438] 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.

[0439] 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.

[0440] 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.

[0441] 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.

[0442] 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.

[0443] 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.

[0444] 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.

[0445] 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.

[0446] 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.

[0447] 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).

[0448] 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’ .

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

[0450] 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.

[0451] 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.

[0452] 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.

[0453] Section: NTN - Further Lawful interception aspects

[0454] 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.

[0455] 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:

[0456] 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.

[0457] 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.

[0458] 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).

[0459] 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.

[0460] 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.

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

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

[0463] • 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.

[0464] • 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.

[0465] They lead to new requirements aligned with above embodiment:

[0466] • 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.

[0467] • 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.

[0468] • 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.

[0469] • 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.

[0470] • 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).

[0471] • 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.

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

[0473] • 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.

[0474] • 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.

[0475] • 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).

[0476] • 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.

[0477] 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.

[0478] 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.

[0479] 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.

[0480] 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.

[0481] In another embodiment that ...

Claims

Claims1. 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, andDualSteer 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 theauthentication 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 asecond 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 anS&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, comprisingthe 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, andMPQUIC.

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.

Images