Method, apparatus, and system operating multi-stack devices

Abstract

This invention describes a method, apparatus, and system for enhanced communication with devices supporting multiple communication stacks by means of cross-stack optimizations, in particular, a method and apparatus for cross-stack optimization in multi-stack devices adapted to: - identify a communication service required by two or more protocol stacks, - determine a first protocol stack to perform the identified communication service, and - inform the second protocol stack about the result or configuration of the communication service performed by the first protocol stack.

Description

[0001] Method, apparatus, and system operating multi-stack devices

[0002] FIELD OF THE INVENTION

[0003] This invention relates to a method, apparatus, and system for enhanced communication with devices supporting multiple communication stacks, e.g., by means of cross-stack optimizations.

[0004] BACKGROUND OF THE INVENTION

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

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

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

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

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

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

[0011] These situations — in which wireless devices may be multi-stack capable — lead to multiple challenges, for instance, in some situations, a DualSteer (multi-stack) device and / or the radio access network and / or core network may incur unnecessary communication overhead and / or inefficiencies due to the usage of two “UEs’Vprotocol stacks within a DualSteer / multi-stack device. For instance, sometimes the multiple protocol stacks and credentials may be misused, e.g., by using them separately.

[0012] SUMMARY OF THE INVENTION

[0013] It is an object of the present invention to address the above desirable features by enabling more efficient operation of multi-stack devices, e.g., by means of cross-stack optimizations or by verifying that different protocol stacks / credentials are associated together.

[0014] This object is achieved by a method, by an apparatus, a cellular DualSteer device or WiFi Multi -Link Capable Device, and by a computer program product as in the appended claims. According to a first aspect of the invention it is proposed a method for operating a multi-stack device comprising: the multi-stack device determining (or identifying) a communication service required by two or more protocol stacks, the multi-stack device determining a first protocol stack to perform the determined communication service, and the multi-stack device informing the second protocol stack about the result or configuration of the determined communication service performed by the first protocol stack. In a first variant of the first aspect, the determining of the communication service comprises verifying of a joint operation of the two or more protocol stacks of the multi-stack device; and wherein the method comprises: the multi-stack device obtaining from each protocol stack in the multi-stack device identifier and / or device identifier and / or location information, each protocol stack in the multi-stack device receiving a confirmation message indicating whether the multi-stack device is authorized to provide the determined communication service.

[0015] In an example of this first variant, an authorization may be based on the obtained identifi- ers / location information. For example, it is proposed that the authorization is granted if: the obtained identifier and / or device identifier of the first protocol stack is associated with the obtained identifier and / or device identifier of the second protocol stack, and / or the locations of each protocol stack determined based on the obtained location information are within a geographic area.

[0016] It is to be noted that in embodiments of this invention, like in this variant, the multi-stack device may be distributed over a plurality of physical devices, each with a protocol stack.

[0017] In another variant, the method comprises the multi-stack device performing by a second protocol stack the determined communication service or part of the determined communication service upon being informed of the result or configuration of the determined communication service performed by the first protocol stack.

[0018] In another variant, in the multi-stack device determining the first protocol stack to perform the determined communication service, the determining of the first protocol stack is made to perform the determined communication service or part of the determined communication service on behalf of the second protocol stack.

[0019] In another variant of the first aspect or its variants, in the multi-stack device determining the first protocol stack to perform the determined communication service, the determining of the first protocol stack is made to perform communication services of a first set of protocol layers as a multi-stack device by using two or more protocol stacks and a second set of protocol layers as a non-multi-stack device.

[0020] In another variant of the first aspect or its variants, the method comprises the multi-stack device providing the second protocol stack with a communication parameter obtained by the first protocol stack when performing the determined communication service.

[0021] In another variant of the first aspect or its variants, the determined communication service refers to one or more of: a. a handover operation; and b. an antenna communication. In another variant of the first aspect of its variants, the determined communication service refers to at least one of: a random-access procedure; a resource-allocation procedure; a communication scheduling operation; a reception of pilot signals; a reception of a paging message; and a request of pilot signals.

[0022] In another variant of the first aspect and its variants, the communication parameter includes at least one of: signal strength of pilot signals; a communication parameter contained in a pilot signal such as a cell identifier contained in a Master Information Block, MIB, or a Public Land Mobile Network identifier, PLMN ID, contained in a System Information Block 1, SIB1, a radio access technology, a PDU session ID obtained after establishing a PDU session.

[0023] In another variant of the first aspect or its variants, the method comprises the multi-stack device sending a message to an access device or a network function, wherein the message contains configuration data, wherein the configuration data indicates the identified communication service and the first protocol stack for performing the identified communication service, and informing the second protocol stack about the result of the communication service performed by the first protocol stack.

[0024] In another variant of the first aspect or its variants, the method comprises the multi-stack device receiving a message from an access device or a network function, wherein the message contains configuration data, wherein the configuration data indicates the identified communication service and the first protocol stack for performing the identified communication service, and the multi-stack device informing the second protocol stack about the result of the communication service performed by the first protocol stack.

[0025] In accordance with a second aspect of the invention, it is proposed an apparatus comprising: a communication unit including a receiver and a transmitter, a controller, and a memory storing instructions which, when executed by the controller, cause the apparatus to: determine a communication service required by two or more protocol stacks, determine a first protocol stack to perform the identified communication service, and inform the second protocol stack about the result or configuration of the communication service performed by the first protocol stack.

[0026] In accordance with a third aspect of the invention, it is proposed a cellular DualSteer device or a WiFi Multi-Link capable Device comprising the apparatus of the second aspect.

[0027] In accordance with a third aspect of the invention, it is proposed a computer program comprising code means for producing the steps in the methods of the first aspect of the invention or its variants.

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

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

[0030] BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In the following drawings:

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

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

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

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

[0036] Fig. 5 schematically shows a handover procedure of a DualSteer device according to some embodiments of the invention; and

[0037] Fig. 6 schematically shows an architecture of a DualSteer device.

[0038] DETAILED DESCRIPTION OF EMBODIMENTS

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

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

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

[0042] Furthermore, 3GPP SA2 group has studied in TR 23.700-29 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;

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

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

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

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

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

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

[0049] 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, e.g., Wi-Fi networks.

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

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

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

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

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

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

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

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

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

[0059] Moreover, a second core network 114 of the cellular network is provided, which comprises network functions 115 to 118, e.g., an access and mobility management function (AMF), an authentication server function (AUSF), a unified data repository (UDR), an AKMA anchor function (AAnF), a network exposure function (NEF), a location management function (LMF), and the like. Further, an application function (AF) 119 is provided, which is a control plane function that provides application services to subscribers, e.g., for video streaming service. If the AF 119 is trusted, it can interact directly with above core network functions or if it is a third party, then it could interact with an NEF.

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

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

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

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

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

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

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

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

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

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

[0070] 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 and NTN. 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 communica- tion / 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.

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

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

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

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

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

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

[0077] 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 offers 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 fre- quency / 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 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.

[0078] The above embodiments may help to identify which policies may be needed to support DualSteer traffic steering and switching (S2-2403831), in particular:

[0079] - 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 3GPP access network within the same PLMN;

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

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

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

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

[0084] Section: Registration and verification that a DualSteer UE is connected to two or more networks

[0085] In some scenarios, the UE 100 (which may 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 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 be include:

[0086] Inti: PLMN 1 -> UE(SIMl) (-> UE(SIM2)) -> PLMN2.

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

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

[0089] Int4: PLMN2 (-> UE(SIM2)) -> UE(SIMl) -> PLMN1 -> PLMN2 ( -> PLMN1). Int5: UE(SIMl) -> PLMNI -> PLMN2 (-> UE(SIM2)) -> UE(SIMl) ( -> UE(SIM2)). Int6: (UE(SIM2) ->) PLMN2 -> PLMNI -> UE(SIM1) -> UE(SIM2) ( -> UE(SIMl)). Int7: UE(SIMl) (-> UE(SIM2)) -> PLMN2 -> PLMNI -> UE(SIMl) ( -> PLMN1) Int8: (UE(SIM2) -> ) UE(SIM1) -> PLMNI -> PLMN2 (-> UE(SIM2)) ( -> PLMN2)

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

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

[0092] 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 PLMN 1 / PLMN2. For instance, in Int2: PLMN 1 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, PLMNI 109 may send an optional confirmation message to PLMN2 114 indicating the positive / negative verification. Note that for interaction 5 (similar for interaction 6), if UE(SIMl) 100 encrypts (in general, protects because multiple techniques may be used to protect the transactions, e.g., a message integrity code may also be generated) a random value using a key shared with 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 SIMI 101 can verify it. The fact that SIMI 101 verifies means that all entities SIMI 101 / SIM2 102 / PLMNI 109 / PLMN2 114 agree with the transaction. This also means that UE(SIMl) and UE(SIM2) are in the same physical UE. In interaction 5, the last step is optional and can be considered a last verification step.

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

[0094] In a related embodiment, a token may be sent / exchanged next to metadata determining the features of the communication so that both networks determine / leam the features of the net- works / 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,

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

[0096] Section: further authentication aspects

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

[0098] 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. 4. In Fig. 4, a UE (1100) with a home PLMN 1103 connects through serving networks 1101 and 1102. To connect to the serving networks, the UE has to register to serving networks 1101 and 1102. To this end, it can perform network registration / primary authentication with its home PLMN 1103 through serving network 1101 first (e.g., AMF of the first serving network). The home network 1103 may check whether the UE is authorized to establish a multi-path network connection. The UE may send in this first primary authentication procedure or in a later message to the home PLMN 1103 an indication about the intention to connect through a second serving network 1102. The home PLMN 1103 may also send an indication to the UE about the need to establish a multi-path connection through a second serving network 1102.

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

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

[0101] It is to be noted that UE 1100 in above and subsequent embodiments may be same / sim- ilar 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.

[0102] 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 verify the identity of UE 1100 as well as to verify the intention of UE 1100 of establishing the multi-path connection.

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

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

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

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

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

[0108] - reject the second primary authentication procedure,

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

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

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

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

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

[0114] Section: further registration aspects

[0115] 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 PLMN 1. 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 includes: an indication that the registration is for a second 3GPP access leg to be used for DualSteer, an identifier of the network where the device has a first registration (PLMN1). The second network (e.g., AMF) may determine whether to accept or reject the registration based on the type of registration (e.g. whether the registration is for a second 3GPP access network), and on the identity of the network where the device has a first registration. If the AMF accepts the registration, it sends a Registration Accept message to the device, including guidance on registration / connection / mobility management procedures over the second 3GPP access network. This scenario has a number of limitations, e.g., the AMF of the second network cannot determine whether the device is connected to the first network or not. The following embodiments aim at improving this situation.

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

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

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

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

[0120] 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 net- works / RATs, the target QoS, etc.

[0121] 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 100. The UE / dualsteer device 100 may have also requested said services previously.

[0122] 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 verify 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 parame- ters / services (for the second network) that may also be verified by the first network.

[0123] 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 / ser- vices 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 communica- tion / 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 / ser- vices 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 / connec- tion / 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:

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

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

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

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

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

[0129] SUPI or SUPIs (or other user identity such as GUTI, etc) that may be associated with the pri- mary / secondary SUPI (or other user identity),

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

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

[0132] 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_1 with SUPI_1 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, 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 verify / 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_1 is plugged in a first device Device_l, and SIM_2 is plugged in a second device Device_2, Device_l and SIM_1 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.

[0133] In accordance with a general definition of this embodiment, it is proposed an apparatus (6DS SIM) for enabling a cellular connection wherein the apparatus is adapted to: be plugged to a mobile equipment, receive a unlocking code such as a PIN, perform an unlock procedure based on the received unlocking code, 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.

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

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

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

[0137] Dual Steer UE, when the apparatus can check the presence of the peer SIM plugged to the same mobile equipment.

[0138] In an embodiment that may be combined with other embodiments or used independently, the SIMs (e.g. SIM1 / SIM2 as described above) 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 Dual Steer 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 verify that the second SIM is a SIM paired to it as a secondary SIM.

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

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

[0141] 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 / du- alsteer device 100 may perform the PDU session establishment via the second network.

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

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

[0144] The credential selection module 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.

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

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

[0147] 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. 6 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 100 / dualsteer device to monitor and control the communication paths through different networks / RATs. The communication policy may specify the conditions for using a second network / RAT in addition to or instead of a first network / RAT in a dual-steer connection. For example, the first network / RAT may be a terrestrial network, such as LTE, NR, or WLAN, and the second network / RAT may be a non-terrestrial network, such as LEO, MEO, or GEO satellite network. For instance, the first network / RAT in a dual-steer connection may be a WLAN and the second network / RAT may be a terrestrial cellular network.

[0148] The policy module 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 latencyjitter, 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.

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

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

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

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

[0153] 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 Dual Steer and / or ATSSS-based multipath communication that can optimize the user experience and the network resource utilization.

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

[0155] 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 / net- works. 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 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.

[0156] This configuration 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 allowed / disallowed). The co-located SUPI can be selected on demand, e.g., based on the context or service that is required.

[0157] 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 1 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.

[0158] In a related embodiment 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 Dual Steer 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.

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

[0160] Section: Further details on verification of the combined operation of the two protocol stacks in DualSteer devices / multi-stack devices A DualSteer device or multi-stack device may include two or more stacks and may rely on the credentials in two or more USIMs. Assuming two USIMs, the two USIMs are supposed to be used on the same DualSteer device, one of the USIMs may contain a first SUPI and the other USIM may contain a second SUPI. The first and second SUPIs may be paired, e.g,, in a data function such as the 5G UDM, and may be supposed to be used together. For instance, a car may be a DualSteer device and a USIM may be for usage with terrestrial networks and another USIM may be for usage with non-terrestrial networks. As mentioned in earlier embodiments, a risk is that USIMs are misused and are placed in different physical devices. To address this risk the following additional embodiments may apply:

[0161] In a further embodiment that may be combined with other embodiments or used independently, the DualSteer device and / or the networks to which the DualSteer USIM are connected may perform some checks to verify that the two USIMs are co-located in the same physical DualSteer device and are not misused in different devices. For example, the DualSteer device may check that the two USIMs are installed in a device with the same device identifier, the Permanent Equipment Identifier (PEI) or International Mobile Equipment Identity (IMEI) number, which is a unique identifier of the device where this identifier may be stored in the phone memory. If the PEI / IMEI numbers do not match, the DualSteer device may reject the use of the two USIMs for a DualSteer connection.

[0162] To this end, a USIM that is enabled for Dualsteer feature may be configured with one or more stored device identifier (e.g., PEI / IMEI), whereby the stored PEI / IMEI in the two USIMs would be the same and / or would match a PEI / IMEI of the DualSteer device. The link between USIM and PEI / IMEI may have been done before initial deployment by an operator (e.g. a DualSteer device would need to be registered through a portal of the operator before the DualSteer feature can be used and / or before the USIMs would be provided to the DualSteer device). Additionally or alternatively, the DualSteer bootstrapping credentials and / or PEI / IMEI of the DualSteer as provided during an eSIM bootstrapping procedure using e.g. the GSMA’s Remote SIM Provisioning(RSP) Architecture for consumer Devices SGP.22, may be used to store a PEI / IMEI of the DualSteer device in the eSIM before it would be provisioned to the DualSteer device. The SM-DP+ or other entity involved in the eSIM bootstrapping procedure may be connected to a 5G network, e.g. in order to store the PEI / IMEI of the DualSteer device in a UDM / UDR as part of a DualSteer subscription and / or to provide the PEI / IMEI of the DualSteer device to a 5G network (e.g. through NEF) in order to be stored in a UDM / UDR as part of a DualSteer subscription, and or to verify the subscription data of a DualSteer device e.g. to check that if a second eSIM is provisioned to a DualSteer device that the PEI / IMEI matches a PEI / IMEI provided by the DualSteer device during provisioning of the first eSIM. Additionally or alternatively, a DualSteer USIM may be adapted to include an application and / or include an adapted USIM application, e.g. by using the USIM Application Toolkit (USAT) and / or Java Card Application Toolkit (CAT), that verifies if the PEI / IMEI of the device to which the USIM is inserted matches a PEI / IMEI stored in the USIM and / or verifies with the network that PEI / IMEI of the device to which the USIM is inserted matches a PEI / IMEI that may be stored in the DualSteer subscription data (e.g. stored in UDM / UDR).

[0163] Similarly, the network may block the usage of a device that is misusing a DualSteer USIM. To this end, the network may verify the PEI / IMEI information provided by the device during registra- tion / authentication to the mobile network, for example, the AMF (or other NF) may retrieve the dualsteer subscription data stored in the UDM / UDR that may include information about two SUPIs associated with the dualsteer subscription, and may include also some information about a PEI / IMEI to which the dualsteer subscription is associated (e.g. from an earlier association as in previous embodiments, or by the AMF (or other NF) storing the PEI / IMEI of the device when the device registered with a first of the two SUPIs). After retrieving the DualSteer subscription data, the AMF (or other NF) may verify if the PEI / IMEI provided by the device during registration / authentication to the mobile network matches a PEI / IMEI associated with the dualsteer subscription and / or a PEI / IMEI that the AMF stored during an earlier registration of the SUPI used by the device during current registration with the network.

[0164] Sometimes a device (mobile equipment with two SIMs) may have two PEIs / IMEIs but the PEIs / IMEIs may be paired as well and the pairing may be stored in a data function, e.g., 5G UDM. Thus, even if different device identifiers (i.e., PEIs / IMEIs) may be reported by each of the USIMs / stacks, e.g., when registering with the network, the network may verify that the device identifiers (IMEIs, PEIs) reported by the corresponding USIMs fit / match the device identifiers in the same DualSteer device.

[0165] In a further embodiment that may be combined with other embodiments or used independently,, the network may check the location of the devices that contain the two USIMs, e.g., by using positioning techniques such as GPS or cell tower / base station / access device triangulation. For instance, when the first USIM associated to the first protocol stack registers and indicates that it is a DualSteer USIM and contains a DualSteer SUPI (this may also be reported back by the data function, e.g., 5G UDM), the network may trigger a positioning procedure (e.g., involving the LMF and / or AMF and / or access devices in the RAT used by said first USIM / protocol stack). The first USIM / protocol stack may also be required to perform and share positioning measurements and send them to the network. A similar procedure may be executed with the second USIM / protocol stack also reporting positioning measurements to the network. The network, e.g., AUSF / UDM may receive a position estimate, e.g., by / from the LMF, and verify whether the estimated positions are within a given margin. If this fits, the connection can be enabled as a DualSteer connection. If the locations do not match within a certain margin of error, the network may deny the establishment or continuation of a DualSteer connection. The network may also check the pairing information of the two SUPIs stored in the data function, such as the 5G UDM, and compare it with the pairing information provided by the DualSteer device. If the pairing information does not match, the network may reject the DualSteer connection request. Additionally or alternatively, the first SUPI / protocol stack may be requested to perform and report positioning measurements for the positioning signals of the RAT to which the second SUPI / protocol stack is connected to, and the other way around. In this manner, it is possible to verify whether the positioning measurements of both protocol stacks are related / correlate.

[0166] Alternatively or additionally, the first and second USIM / protocol stack may report other information that may give an indication of their location, e.g., the cell IDs of the access devices they are connecting to. Additionally or alternatively, once the dualsteer device registers with the first SUPI to the network, the cell ID of the gNB that the dualsteer device connects to will also be provided to the network (e.g. using the location report of the RAN / gNB to the AMF). Similarly, when the dualsteer device registers with the second SUPI to the network, the cell ID of the gNB that the dualsteer device connects to will be provided. If the two cell IDs do not match, then the network may reject the registration and / or deregister the device. Note that the cell IDs may be different but the network(s) may still be able to verify whether those cell IDs correspond to access devices active in the same area, and this may still allow accepting the DualSteer device registration(s).

[0167] Additionally or alternatively, even if a first SUPI / protocol stack may not connect to the access device the second SUPI / protocol stack is connected, it may be able to “see” that access device. The network may then retrieve the location of those access devices and determine whether the first and second USIM / protocol stacks are close.

[0168] Alternatively or additionally, the first network / RAT may send a challenge, e.g., a random number that may be broadcasted periodically, e.g., in a SIB or may be provided in a NAS message protected with the keys associated with the first USIM, and the DualSteer device may be required to return the same challenge through the second network / RAT, e.g., protected in a NAS message protected with the keys associated with the second USIM.

[0169] The benefit of these location-based approaches that is one of the USIMs is moved to another device, then it would mainly be useful if with that USIM it is possible to register to other cells than the other USIM. So if the network would check if the position (e.g. cell IDs) for both registrations match, then only if both USIMs are used within the same location / cell / area it could be used, severely limiting the usefulness of such act. However, as indicated above, the networks and / or RATs may still exchange information about the location of those access devices correlating / determining whether they are ac- tive / provide coverage in the same area.In a further embodiment that may be combined with other embodiments or used independently, the network may have configured / stored a set of dualsteer policies related to a Dualsteer subscription. For example a dualsteer policy may include a restriction that SUPI1 / SUPI2 combination can only be used by a dualsteer device if SUPI1 connects to RATI and SUPI2 connects to RAT2. When a device registers to the network that uses a SUPI related to a dualsteer subscription during registration, the network (e.g. AMF or other NF) may retrieve the dualsteer policies related to the subscription involving that SUPI (e.g. SUPI1). So if the network detects that SUPI1 is used in another RAT than configured in the dualsteer policy the registration of the device may be rejected and / or the network may deregister the device. Similarly, if the dualsteer policy restricts the use of SUPI1 / SUPI2 in such a way that the SUPIs each have to connect to a different PLMN / RAT combination, then the network can detect if that is the case and if not, e.g. SUPI1 / SUPI2 are connected to the same PLMN / RAT, then it means something is wrong and the network may reject / tear down the related connections for SUPI1 / SUPI2.

[0170] Section: application to FWA

[0171] Fixed wireless access may provide a way to deliver connectivity to, e.g., home networks. Traditionally a residential gateway (RG) using a fixed wired connection or a fixed wireless link connects to the core network of the cellular system to provide access to a data network. Traditionally, a single RG, e.g., a fixed wireless access (FWA) device, is used. In some cases, a fixed wireless access system may rely on two or more FWA devices (e.g., two or more RGs) to give access to a customer premises network (CPN), e.g., a home network. A FWA device may be a residential gateway. The two or more FWA devices may act as a multi-stack device so that the coverage / capacity / reliability in the CPN increases or improves, for instance, a first FWA device may be placed in the living room and a second FWA device may be placed in the second floor. Both FWA devices may work together to enhance the coverage, reliability and capacity in the CPN. For instance, they may be used to serve a wireless device (e.g., a UE or laptop) within the CPN. For instance, when the wireless device is in the living room, the wireless device may be served by the first FWA device. For instance, when the wireless device is in the second floor, the wireless device may be served by the second FWA device. For instance, when the wireless device is in the first floor, the wireless device may be served by both the first and second FWA devices. Each of the FWA devices may have been configured with some credentials of a common subscription indicating that both FWA devices should work together. However, the two or more FWA devices may only be allowed to operate if they are physically located in the same area / location, e.g., within the same building. The reason is that otherwise the devices may be misused, e.g., a first FWA device may be used in the main home, and the second FWA device may be used in the holiday house. To avoid this situation, embodiments in this invention may be applicable. For instance, the network (e.g., access devices / gNBs) may obtain the location of the FWA devices and verify whether they are physically close to each other. If the devices are not close to each other, one or more of them may be disabled according to the network policy. For instance, the network (e.g., access devices / gNBs) may obtain the (long-term) device identifiers (e.g., PEI) of the FWA devices associated to a given network, and verify that they are associated together. For instance, an operator may deliver to a customer a pair of FWA devices and the operator may require that both FWA devices operate together (simultaneously), and thus, it may verify whether the FWA devices report the corresponding device identifiers. It is to be noted that two or more FWA devices may be considered or understood as a multi-stack device that is implemented / realized in a distributed manner. In other words, a multi-stack device may comprise two or more FWA devices working together. Section: (re)establishing of a connection with a second network triggered by the first network.

[0172] In some cases, a UE / dualsteer device may have connected to a first network and the UE / du- alsteer 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:

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

[0174] Section: Negotiation of the multipath - multi-network steering role

[0175] In a further embodiment illustrated for example with reference to Fig. 4 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. 4:

[0176] 1) The UE 1100 may send 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 net- work / 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 for example if the process is not triggered by the UE.

[0177] 2) The home PLMN 1103 and / or first serving network 1101 evaluates the UE need and / or UE request and determines 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.

[0178] 3) If the multipath connection is granted, the home PLMN 1103 and / or first serving network 1101 may 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.

[0179] 4) In this example, 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.

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

[0181] Above and next embodiments may be used to address session management enhancements to support Dual Steer traffic steering of a new service to a 3GPP 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 the following:

[0182] Whether and what enhancements are required in PDU Session establishment / modifica- tion / release;

[0183] Whether and what enhancements are required for N4 session management between the SMF and UPF, or between SMF+PGW-C and UPF+PGW-U; and For session subject to potential switching and / or to traffic steering, whether, when and how the network selects the PSA UPF(s) or UPF+PGW-U to allow routing the traffic across 3GPP access networks towards the same PSA UPF or UPF+PGW-U to support DualSteer.

[0184] Section: Traffic spliting in multi-path over multiple radio access technologies / net- works

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

[0186] 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., htps: / / 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:

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

[0188] Note that the above may also indicate a dual-connectivity setup wherein the two paths 306, 307 may be two dual -connectivity paths, a path going over a terrestrial access device and another path going over a non-terrestrial access device.

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

[0190] 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 / re- serve resources for the upcoming communication.

[0191] 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 / dualsteer 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 a(n 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 / dualsteer device 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 / dualsteer device 100 and the / AN can use the root key to authenticate / establish a secure channel, and then the UE / dualsteer device 100 can share with the RAN (e.g., the RAN 106) of the secondary second core network 114 its authorization token.

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

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

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

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

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

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

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

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

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

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

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

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

[0204] Above embodiments may 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. 6), 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. 6) 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.

[0205] Section: Impact on AKMA when executed over two networks

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

[0207] 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 aNF, e.g., the AF 119, and orthe 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.

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

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

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

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

[0212] (ii) indicating two potential lawful interception entities in the first and second core net- works 109 and 114 by the communication parameters of the multipath communication, e.g., a QUIC connection ID. Furthermore, the first and second core networks 109 and 114 may need to verify that they are entitled to disclose the information if required to a lawful interception entity.

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

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

[0215] In an exemplary embodiment variant related to AKMA, the UE / dualsteer device 100 may choose to use K_AKMA_1 derived from K_AUSF_1 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_1 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_AF 1 is used to protect the AKMA communication and that the AKMA communication is requested / required / allowed over PLMN2.

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

[0217] Section: cross-stack optimizations in a multi-stack device

[0218] Fig. 6 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 / SDAP / 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 communication link 1813 (e.g. an API and / or hardware communication link).

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

[0220] 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 Dual Steer control functionality that manages the behaviour of the communication stacks available in a UE / dualsteer device 1800 such as 1806 in Fig. 6. 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. 5 where UE 1700 (which is same / similar as UE / dualsteer device 1800) contains SIM 1701 and SIM 1702, RAN 106 contains a first access device 1707 and a second access device 1708 and the core network 1709 includes network functions UPF 1710, SMF 1711, and AUSF 1712. In steps 1713 and 1713, UE 1700 performs random access to connect to the RAN 106, namely the first access device 1707. This is done for both SIM 1701 and SIM 1702 in steps 1713 and 1714. Next, UE 1700 registers and performs primary authentication with network 1709. This is done for both SIM 1701 and SIM 1702 in steps 1715 and 1716. Then in Step 1717, UE 1700 can setup a connection with the UPF 1710, e.g., based on a multipath link or other means. At a later point of time, when UE 1700 is moving and / or needs to connect to the second access device 1708, the UE 1700 applies the policy to perform the handover from the first access device 1707 to the second access device 1708 in a consecutive manner, e.g., first moving the communication link related to the first SIM 1701 from 1707 to 1708, and then when the handover is finished moving the communication link related to the second SIM 1702 from 1707 to 1708. This policy may determine that if UE 1700 has established a connection over two SIMs, the handover procedure, in its totality or partially, may not be performed simultaneously.

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

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

[0223] In an embodiment related to Fig. 5 and Fig. 6 that may be combined with other embodiments or used independently, steps 1713 and 1714 in the procedure illustrated in Fig. 5 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 Dual Steer control functionality, e.g., when it determines that the same RAN is used.

[0224] In an embodiment related to Fig. 6 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 may otherwise determine how application traffic is split / distributed among both protocol stacks to achieve the communication goals.

[0225] In an embodiment related to Fig. 6 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.

[0226] In an embodiment related to Fig. 6 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.

[0227] In an embodiment related to Fig. 6 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.

[0228] In particular, in an embodiment a DualSteer device may be configured to receive control messages through a first protocol stack to steer the communication of both the first protocol stack and a second protocol stack. The DualSteer device may announce its capability of having the first stack receiving configuration / commands for both the first protocol stack and the second protocol stack. The first stack and the second stack may need to offer this capability when the first and second protocol stack are connected or want to connect to the same radio access network (e.g., one or more access devices of the same radio access network). The radio access network, upon receiving a message from a DualAccess device, e.g., sent through the first protocol stack, may perform a protocol to verify that control commands reach the second protocol stack. For instance, the first protocol stack may indicate its capabilities, the RAN may provide a configuration message (e.g., a DCI or UCI) for the second protocol stack, the first protocol stack may provide the configuration to the second protocol stack, and the second protocol stack of the Dual Steer may use the configuration to communicate with the radio access network. For instance, the configuration message may be a configuration received through the first protocol stack of communication resources for the downlink of data through the second protocol stack.

[0229] In an embodiment related to Fig. 6 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.

[0230] In an embodiment related to Fig. 6 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.

[0231] In an embodiment related to Fig. 6 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 (1804, 1805). This functionality has the advantage of reducing the energy consumption of the DualSteer device.

[0232] In an embodiment that may be combined with other embodiments or used independently, a DualSteer device (e.g. 1700, 1800, 100) may comprise two protocol stacks (1804, 1805) that may rely on a MIMO antenna with a number of antenna elements. Alternatively, a DualSteer device may have a single MIMO antenna with a fixed number of antenna elements, and antenna elements may be allocated to the different protocol stacks depending on the communication needs of each of the protocol stacks. For instance, a DualSteer device may have a total of N antenna elements and the first protocol stack may be used to communicate with a first base station (first communication link) and the second protocol stack may be used to communicate with the second base station (second communication link). The number of antenna elements N 1 and N2 allocated to the first and second communication stacks, respectively, such that N 1 + N2 < = N may be configurable depending on the needs of each communication link / communication stack. N1 and N2 may be configurable and controlled, e.g., by the DualSteer control functionality and / or by the protocol stacks.

[0233] In a related embodiment that may be combined with other embodiments or used independently, a DualSteer device may also have M different antennas and the antennas may be allocated to the multiple protocol stacks. How and which of the different antennas are allocated may be determined by, e.g., the DualSteer control functionality and / or the protocol stacks. For instance, consider a DualSteer device that has three antennas, two on the sides and one on the top that that each protocol stack may use one antenna at a time depending on which one is the most suitable one, e.g., depending on how the user grasps the DualSteer device and / or depending on the position of the access device. In this case, each protocol stack may indicate its preference and / or may reserve the antenna and / or may indicate (to an access device / base station) when the antenna may be be available so that resources can be allocated, etc.

[0234] In a related embodiment that may be combined with other embodiments or used independently, a DualSteer device may determine which protocol layers would be shared (by two or more protocol layers) and which protocol layers would run independently and / or in a coordinated manner. In an example, illustrated by the previous embodiments, the antennas of the (DualSteer) devices are shared / co- ordinated while the upper protocol layers run independently. In an examnple, the antennas / PHY / MAC layer run independently, but the upper protocol layers are shared / coordinated. A DualSteer (in general, multi-stack) device may determine this configuration by receiving a first configuration, e.g., by a managing entity

[0235] 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 5GHz stack is performed by means of the 2.4 GHz stack.

[0236] In an embodiment related to Fig. 6 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 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 1813 or to the DualSteer control functionality 1806, which may in turn use it to instruct and / or pro- vide / 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 1813 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.

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

[0238] 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 / cor- relate 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 forthat 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 or more 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.

[0239] In an embodiment related to Fig. 6 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 / con- figuration / 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.

[0240] Section: Steering of roaming information

[0241] In an embodiment 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. preconfigured 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.

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

[0243] Section: combined operation of two UEs

[0244] In some cases, a multi stack device may comprise two or more wireless devices. For instance, the multi stack device may be a smart watch and a smart phone. For instance, the multi stack device may be two FWA devices as in other embodiments. For instance, the multi stack device may be a car and the smart phone. In existing 3GPP 5G R19 procedures, such wireless devices work independently since traditionally a user owned a single UE. However, users are owning more and more connected devices that can be grouped together. Some of the communication may also be related. Thus, embodiments of this invention may be applied to optimize the performance of the UEs as a whole wherein a multi stack device may be considered / view as a distributed multi stack device.

[0245] For instance, consider a user making a data transfer / communication with a smart phone. Then the smart phone may not have the capacity to perform the data transfer fast enough or it needs to perform a handover hampering the QoS. In an example, the smart watch helps in those cases. The network can consider that smart watch and smart phone belong together (in fact, they have USIMs associated to a common user subscription).

[0246] For instance, when the smart phone needs to perform a handover, the smart phone will indicate this to the smart watch and / or network, and the data transfer / communication to the smart phone will be rerouted partially (e.g., multi path communication) through the smart watch, e.g., by using a multi-path connection over a UE to Network relay wherein the direct path is between base station and smart phone and the indirect path is over the smart watch, and the link between smart watch and smart phone may be, e.g., 3GPP based (e.g., Sidelink / PC5) or non-3GPP (e.g., Wi-Fi or Bluetooth Low Energy).

[0247] For instance, if the smart phone is close to a base station for just a few seconds and that is the best time to download / upload some data, but the capacity of the UL / DL to the smart phone is saturated, part of the UL / DL transfer may be done through the smart watch, e.g., using a multi-path connection as in the previous example.

[0248] To enable such functionality, in an example, a user and / or a wireless device may enable the usage of the first wireless device (e.g., smart phone) and the second wireless device (e.g., smart watch) as a multi stack device.

[0249] In an example, a first wireless device may determine when it requires support of the second access device, e.g., by sending a message / indication to the RAN.

[0250] In an example, a first wireless device may determine the type of support it requires from the second access device, e.g., by sending a message / indication to the RAN.

[0251] In an example, a wireless device may indicate the available resources (e.g., energy level, ...) so that the network can determine whether it can work in a normal mode (i.e., it works standalone without cross stack optimizations) or in a multi stack device mode.

[0252] In an example, a wireless device may indicate whether it can work in a normal mode (i.e., it works stand-alone without cross stack optimizations) or in a multi stack device mode.

[0253] In an example, a wireless device, e.g., the second wireless device (e.g., smart watch) may receive a request (e.g., from an access device) to start working on multi stack device mode.

[0254] In an example, a wireless device, e.g., the second wireless device (e.g., smart watch) may receive a request (e.g., from an access device) to start working on multi stack device mode.

[0255] In an example, one of the wireless devices (e.g., first wireless device and / or second wireless device) may receive a configuration determining whether / how / when to operate as a (logical) multi access device.

[0256] In an example, one of the wireless devices (e.g., first wireless device) may determine and / or use and / or indicate (to an access device) whether it observes the peer (e.g., the second wireless device). This information may be available from the lower (non-3GPP) layers, e.g., when the second wireless device connects to the first wireless devices via a non-3GPP link, e.g., Bluetooth or Wi-Fi. For instance, if the first wireless device does not observe the peer, then the first wireless device will not, e.g., (be able to) send a request to get support from the second wireless device.

[0257] In an example, one of the wireless devices may send (e.g., first wireless device) and / or receive (e.g., second wireless device) an indication indicating the reason for receiving support and / or the conditions for receiving support. For instance, if the first wireless device is about starting a conditional handover, the first wireless device may indicate the intention to start the conditional handover to the network. For instance, a message indicating the start of a handover procedure (by the first wireless device) towards a target access device may trigger the setup of a multi-path link through the second wireless device to ensure the continuity of the data connection. For instance, it may require the coordination of the handovers of the first and second wireless devices, e.g., the handover of the first wireless device may be triggered earlier than required and the handover of the second wireless device may be triggered once the handover of the first wireless device is fulfilled. For instance, thresholds for performing a mobility procedure may be adapted depending on whether a wireless device (e.g., first wireless device) is acting standalone or has support of the other wireless device (e.g., second wireless device).

[0258] Section: further clarifications

[0259] In some cases, a multi-stack device containing two or more protocol stacks / devices may be adapted to execute a certain communication procedure / service via one, two, or more of the protocol stacks / devices. In the following, certain clarifications are provided regarding how this invention may be interpreted when a cross-stack optimization is applied.

[0260] In an example, a common functionality may be determined, and one of the stacks may perform the functionality (e.g., communication procedure) first, and inform the other protocol stack about the result. In particular, one of the protocol stacks may take over the whole functionality of the other stack (e.g., as illustrated in other embodiments, e.g., measuring reference signals).

[0261] In some cases, the functionality of two or more stacks may be coordinated (e.g., a first handover procedure by the first protocol stack is performed before a second handover procedure executed by the second protocol stack).

[0262] In some cases, only part of a communication procedure during a communication may be replaced by a communication procedure in another protocol stack. For instance, in the case of cell selection, the measurements of the cells may be performed a single time (i.e., the monitoring the signal strength of different cells). For instance, such monitoring of synchronization signals may be done by a first protocol stack and the result may be shared with the second protocol stack. However, other parts (of an overall communication procedure) may not be shared. For instance, the actual cell selection may be done by each of the protocol stacks individually, e.g., based on the monitored synchronization signals that are monitored by a single communication stack.

[0263] In some cases, the communication procedure in two or more protocol stacks may be optimized and / or coordinated by sharing a configuration (or part of it) to perform the communication procedure. For instance, if a first communication stack has received a periodic transmission / reception schedule, the schedule may be shared with another protocol stack to, e.g., avoid simultaneous transmissions that may cause interference.

[0264] In some cases, communication procedure and / or communication service is mentioned, however, other types of procedures are not excluded, e.g., a wireless sensing procedure may be applicable, or a computing procedure may be applicable, or

[0265] In some cases, the multi-stack device and / or DualSteer device comprising two or more protocol stacks may be implemented and / or realized in a single physical device, e.g., a wireless device such as a User Equipment comprising two or more radios including PHY / MAC / RLC / PDCP layers. However, in such cases a multi-stack device and / or DualSteer device may be considered as a distributed device comprising two or more individual devices, each individual device comprising at least one radio. The two or more individual devices may then cooperate to perform a common task. For instance, each of the individual devices may be a FWA device (e.g., a residential gateway) and two or more FWA devices may cooperate to provide connectivity to a CPN.

[0266] In some cases, the multi-stack device may be such that some protocol layers are common two two or more protocol stacks / individual devices (e.g., PDCP layer), but some protocol layers are not shared but kept separate, e.g., RLC / MAC / PHY. In other words, a first set of protocol layers are not shared and work as a multi-stack device by using two or more protocol stacks and a second set of protocol layers as a non-multi-stack device working as a single protocol stack.

[0267] In some cases, a first protocol stack may inform a second protocol stack of the result of a communication service / procedure or a configuration. This step may be implicit or explicit. For instance, in an explicit way, the indication may be a confirmation of the successful execution of the communication service. In some cases, it may be implicit when performing a subsequent operation, e.g., when no failure indication is provided.

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

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

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

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

[0272] A single unit or device may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

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

Claims

Claims1. A method for operating a multi-stack device comprising: the multi-stack device determining a communication service required by two or more protocol stacks, the multi-stack device determining a first protocol stack to perform the determined communication service, and the multi-stack device informing the second protocol stack about the result or configuration of the determined communication service performed by the first protocol stack.

2. The method of claim 1, wherein the determining of the communication service comprises verifying of a joint operation of the two or more protocol stacks of the multi-stack device; and wherein the method comprises: the multi-stack device obtaining from each protocol stack in the multi-stack device identifier and / or device identifier and / or location information, each protocol stack in the multi-stack device receiving a confirmation message indicating whether the multi-stack device is authorized to provide the determined communication service, wherein the authorization is granted if: the obtained identifier and / or device identifier of the first protocol stack is associated with the obtained identifier and / or device identifier of the second protocol stack, and / or the locations of each protocol stack determined based on the obtained location information are within a geographic area.

3. The method of claim 1, comprising the multi-stack device performing by a second protocol stack the determined communication service or part of the determined communication service upon being informed of the result or configuration of the determined communication service performed by the first protocol stack.

4. The method of claim 1, wherein in the multi-stack device determining the first protocol stack to perform the determined communication service, the determining of the first protocol stack is made to perform the determined communication service or part of the determined communication service on behalf of the second protocol stack.

5. The method of claim 1, wherein in the multi-stack device determining the first protocol stack to perform the determined communication service, the determining of the first protocol stack is made to perform communication services of a first set of protocol layers as a multi-stack device by using two or more protocol stacks and a second set of protocol layers as a non- multi-stack device.

6. The method of any of the preceding claims, comprising the multi-stack device providing the second protocol stack with a communication parameter obtained by the first protocol stack when performing the determined communication service.

7. The method of claims 1 and 3, wherein the determined communication service refers to one or more of: a. a handover operation; and b. an antenna communication.

8. The method of any of the preceding claims, wherein the determined communication service refers to at least one of: a random-access procedure; a resource-allocation procedure; a communication scheduling operation; a reception of pilot signals; a reception of a paging message; and a request of pilot signals.

9. The method of any of the preceding claims in combination with claim 6, wherein the communication parameter includes at least one of: signal strength of pilot signals; a communication parameter contained in a pilot signal such as a cell identifier contained in a Master Information Block, MIB, or a Public Land Mobile Network identifier, PLMN ID, contained in a System Information Block 1, SIB1, a radio access technology,- a PDU session ID obtained after establishing a PDU session.

10. The method of any previous claims, comprisingthe multi-stack device sending a message to an access device or a network function, wherein the message contains configuration data, wherein the configuration data indicates the identified communication service and the first protocol stack for performing the identified communication service, and informing the second protocol stack about the result of the communication service performed by the first protocol stack.

11. The method of any previous claims, comprising the multi-stack device receiving a message from an access device or a network function, wherein the message contains configuration data, wherein the configuration data indicates the identified communication service and the first protocol stack for performing the identified communication service, and the multi-stack device informing the second protocol stack about the result of the communication service performed by the first protocol stack.

12. An apparatus comprising: a communication unit including a receiver and a transmitter, a controller, and a memory storing instructions which, when executed by the controller, cause the apparatus to: determine a communication service required by two or more protocol stacks, determine a first protocol stack to perform the identified communication service, and inform the second protocol stack about the result or configuration of the communication service performed by the first protocol stack.

13. A cellular DualSteer device or a WiFi Multi -Link capable Device comprising the apparatus of claim 12.

14. A computer program comprising code means for producing the steps in the methods of Claims 1- 11.

Images