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

Abstract

Methods, apparatuses, and systems are described for authenticating, authorizing, and managing connections in a cellular system to allow a user to retrieve / send some data, e.g., from / to an application function (AF), or communicate with another remote user over multiple networks in an optimized / secure manner. A user may have one or more devices (UEs) using (e.g., connected to) multiple / different networks, e.g., devices with multiple subscriber identity modules (SIMs) and / or different radio access technologies.

Description

Technical Field

[0001] The present invention relates to a system for enhancing communication with devices connected to one or more networks or using one or more radio access technologies (e.g., devices using terrestrial and / or non-terrestrial networks or devices downloading data through two different cellular core networks). Background Technology

[0002] In traditional cellular networks, a master station serves multiple slave stations located within the cell served by that master station. Wireless communication from the master station to each slave station is conducted on the downlink channel. Conversely, wireless communication from each slave station to the master station is conducted on the uplink channel. Wireless communication can include data services (sometimes referred to as "user data") and control information (sometimes referred to as "signaling"). This control information typically includes information used to assist the master station and / or slave stations in exchanging data services (e.g., resource allocation / requests, physical transmission parameters, information about the status of the respective stations).

[0003] In the context of cellular networks standardized by 3GPP, a primary station is referred to as a base station or 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) and interfaces functionally with the Core Network (CN). In the same context, a secondary station corresponds to a mobile station or user equipment (UE) in 4G / 5G, which is a radio client device or a specific role played by such a device. The term "node" is also used to refer to a UE or gNB / eNB.

[0004] Additionally, for example, in the case of PC5 interface or sidelink communication, there may be direct communication between secondary stations (here, UEs). The UE may then also operate as a relay to allow, for example, UEs outside coverage area to obtain intermediate (or indirect) connections to the eNB or gNB. To be able to act as a relay, the UE can use discovery messages to establish new connections with other UEs.

[0005] Therefore, the role of relay nodes has been introduced in the 3rd Generation Partnership Project (3GPP, which was originally a partnership project that brought together national standards development organizations (SDOs) from around the world to develop technical specifications for third-generation mobile cellular telecommunications). A relay node is a wireless communication station that includes the function of relaying communication between a primary station (e.g., gNB) and a secondary station (e.g., UE). This relay function can, for example, allow the coverage of a cell to be extended to an out-of-coverage (OoC) secondary station. The relay node can be a mobile station or can be a different type of device. In the specifications for 4G, the Proximity Service (ProSe) function is defined, particularly in 3GPP specifications TS 23.303 and TS 24.334, to enable connections, in particular, for cellular user equipment (UEs) in the coverage of cellular network base stations (e.g., eNBs) that are temporarily not serving a cell. This specific function is called ProSe UE-to-Network Relay, or simply "Relay UE". The Relay UE relays applications and network services in both directions between the OoC UE and the eNB. Local communication between a relay UE and an OoC UE is referred to as device-to-device (D2D) communication or sidelink (also known as PC5) communication in 3GPP TS 23.303 and TS 24.334. Once the relay relationship is established, the OoC UE is connected via IP, for example, through the relay UE, and acts as a "remote UE". This means that the remote UE has an indirect network connection to selected functions of the core network, rather than the direct network connection to all core network functions as is normal.

[0006] Furthermore, the role of a UE-to-UE relay node has been introduced, which is a relay node that relays communication between two UE devices. The relay node relays communication between UE devices. When within coverage area, the UE can connect to the core network via a base station. In such a relay scenario, the relay device can receive and store information for a period of time before forwarding it to the target device. This information that can be stored and forwarded can be discovery messages received from the source UE, which the relay UE can then release at a later time. This information that can be stored and forwarded can also be an SIB that can contain a timestamp.

[0007] Furthermore, cellular networks are evolving to enable more mobile access devices, such as satellites, drones, buses, or trains, that can store data for a period of time before further forwarding it. One example involves a satellite that receives and stores certain data when it is near a ground gateway and releases the data only when the receiver becomes within coverage. Such mobile access devices can operate in a transparent or regenerative mode. In transparent mode, the mobile access device acts as a reflector / smart repeater that retransmits communications sent by, for example, a gateway (e.g., a non-terrestrial network (NTN) gateway) to the UE. In regenerative mode, the mobile access device acts as a base station and is able to establish a connection with the UE. In store-and-forward mode, the mobile access device is able to cache the same data received from the UE or the NTN gateway and transmit the data when the mobile access device is within the receiver's communication range.

[0008] Furthermore, cellular networks are evolving to allow dual bootstrapping, where a UE can obtain access through multiple networks (different networks and different radio access technologies, such as terrestrial and non-terrestrial networks). In this case, coordination of access across these different networks is required. 3GPP TR 22.841 captures a set of use cases and potential service requirements related to: 5G system support for traffic bootstrapping, splitting, and handover of UE user data (related to the same data session) across two 3GPP access networks.

[0009] Furthermore, the use of radio access technologies (such as non-terrestrial networks using satellites) may introduce further challenges or opportunities. For example, the storage capabilities of satellites could interfere with the current operation of security procedures. Similarly, the extensive coverage of satellites could also allow UEs to communicate directly with each other.

[0010] These situations present several challenges. For example, in some cases, the UE may need to acquire / send data, for instance, from an application function (AF) or while communicating with another remote user over multiple networks or non-terrestrial networks. Therefore, it is desirable to acquire / exchange such data from multiple networks or non-terrestrial networks in an optimized / secure manner. Summary of the Invention

[0011] The object of the present invention is to address the aforementioned desired features by implementing an enhanced security process that allows devices to transmit data when connected to one or more core networks or different radio access technologies such as non-terrestrial networks.

[0012] This objective is achieved by the method as claimed in claim 1, by the apparatus as claimed in claim 48, by the user equipment as claimed in claim 49, and by the computer program product as claimed in claim 50.

[0013] According to a first aspect of the present invention, a method for operating a device to manage a connection is provided, wherein the method comprises: The device checks or selects the preferred authentication process; The device performs the preferred authentication process with the first core network via a first access device; and The device establishes a connection with the first core network.

[0014] According to a second aspect of the invention, an apparatus is provided comprising: Receiver transmitter, Controller, and A media storage device includes instructions for executing a method for managing a connection, the method comprising: The device checks or selects the preferred authentication process; The device performs the preferred authentication process with the first core network via a first access device; and The device establishes a communication connection with the first core network.

[0015] According to a third aspect of the invention, a user equipment comprising the means of the first aspect is proposed.

[0016] According to a fourth aspect of the present invention, a method for operating a first network entity is provided, comprising: The first network entity receives / sends key material from / to the second network entity to allow the second network entity to perform legitimate interception of data exchanged through paths managed by the second network entity (in multipath connections); The first network entity negotiates the parameters of the multipath connection with the second network entity; and The first network entity executes a protocol based on privacy-enhancing technology / multi-party communication with the second network entity to determine the communication parameters of the path without disclosing private information such as available resources.

[0017] According to a fifth aspect of the invention, a computer program product is provided, comprising code units for generating the steps of the methods of the third and fourth aspects when run on a computer device.

[0018] Therefore, data can be obtained in an optimized / secure manner over multiple networks, for example, from application functions or when communicating with other remote users.

[0019] According to the first option, which can be combined with any of the first to fifth aspects, a command can be received from the first core network via the first access device to establish a multipath connection on the first access device and a designated access device and / or the second core network using a set of configuration parameters for multipath connection and / or core network, and if no connection is established, a connection can be established with the designated access device and / or the second core network via the first access device and the designated access device and / or the second core network via the application of the set of configuration parameters, and communication for one or more services can be initiated on the first access device and the designated access device and / or the second core network via the application of the set of configuration parameters via the first access device and / or the second core network via the first access device and / or the second core network via the first access device and / or the second core network via the first option.

[0020] Depending on the second option, which can be combined with the first option or any of the first to fifth aspects, the configuration parameters may include one or more of the following: Access information, particularly the timing or location or physical cell identifier of the access device, especially the execution of a random access procedure (e.g., via RACH); The operating modes of the access devices include regeneration, transparent or hybrid regeneration / transparent operating modes, as well as store and forward modes; When operating in store-and-forward mode, specify the storage time for the access device; Key materials; IP addresses for different communication paths; Congestion status for different paths and / or for communication segments within different paths; Congestion windows for different paths and / or for communication segments within different paths; Round-trip time for different paths and / or for communication segments within different paths; Methods for determining round-trip times; Methods for scheduling groups; and Services applicable to multipath communication.

[0021] According to the third option, which can be combined with the first or second option or any of the first to fifth aspects, the designated access device can be connected (e.g., via a device) by performing master authentication or by key material received in the configuration parameters, wherein the key material may include an authentication server key and / or a network access server key.

[0022] According to the fourth option, which can be combined with any of the first to third options or any of the first to fifth aspects, a first token can be exchanged with a first core network via a first access device (e.g., by the device); a second token can be exchanged with a second core network of a designated access device via a designated access device (e.g., by the device); and the first and second tokens can be checked by the device to verify the establishment of a multipath connection.

[0023] According to the fifth option, which can be combined with any of the first to fourth options or any of the first to fifth aspects, the AKMA process can be initiated by sending a first AKMA request on the first access device (e.g., by the device), and the Ua protocol can be run on the first access device and the designated access device (e.g., by the device) based on the key material of the first core network bound to the first access device.

[0024] According to a sixth option, which can be combined with any one of the first to fifth options or any one of the first to fifth aspects, an indication of an operating mode for the access device can be received (e.g., by the device), the operating mode may include at least one of regeneration, transparent or hybrid regeneration / transparent operating mode and store and forward mode, and a storage time is specified when the access device operates in store and forward mode, wherein, when performing an authentication process and / or establishing a communication connection, appropriate communication parameters can be selected (e.g., by the device) based on the received indication.

[0025] According to the seventh option, which can be combined with any of the first to sixth options or any of the first to fifth aspects, the authentication process identifier and / or timing value can be (e.g., by the device) included in the field of the message of the preferred authentication process, and the field can (e.g., by the device) be used to distinguish messages of different security processes and / or to determine whether the access device has stored the received message.

[0026] According to the eighth option, which can be combined with any of the first to seventh options or any of the first to fifth aspects, a communication link can be initiated (e.g., by the device), or a request for establishing a communication link with a remote user equipment can be initiated (e.g., by the device), a communication link can be established using the first and / or selected access device as a relay, and a relay can be used to communicate with the remote user equipment in a transparent or regenerable or store-and-forward relay communication mode (e.g., by the device).

[0027] According to the ninth option, which can be combined with any of the first to eighth options or any of the first to fifth aspects, the first access device or designated access device can be a satellite or an unmanned aerial vehicle or vehicle.

[0028] Based on the tenth option, which can be combined with any of the previous options, the method includes: The device receives a command from the first core network through the first access device to establish a multipath connection on the first access device and the designated access device and / or the second core network using a set of configuration parameters for multipath connection. If the device is not already connected to the designated access device and / or the second core network, then the device connects to the designated access device and / or the second core network; and The device initiates a multipath connection for one or more services on the first access device and the designated access device and / or the second core network by applying the set of configuration parameters.

[0029] Based on the eleventh option, which can be combined with any of the previous options, the method includes: The device receives a command from the first core network via a first access device to establish the connection using a set of configuration parameters for the connection via a specified access device; If the device is not already connected to the designated access device, then the device connects to the designated access device; and Initiate a connection for one or more services through the designated access device.

[0030] According to another option, the device can use the first SIM to perform a preferred authentication procedure with the first core network and use the credentials in the second SIM to connect to the designated access device and / or the second core network.

[0031] It should be understood that the preferred embodiments of the present invention may also be any combination of the dependent claims or the above embodiments with the corresponding independent claims.

[0032] These and other aspects of the invention will be apparent from the embodiments described below and will be illustrated with reference to the embodiments described below. Attached Figure Description

[0033] In the following figures: Figure 1 A block diagram schematically illustrates a network architecture that connects to multiple networks or accesses them via different radio technologies; Figure 2 A block diagram and communication paths are schematically illustrated through multiple networks and / or different radio access technologies; and Figure 3 A block diagram and communication paths are schematically illustrated through multiple networks and / or different radio access technologies; and Figure 4 A block diagram and communication paths are schematically illustrated through multiple networks and / or different radio access technologies; and Figure 5 This schematically illustrates the user plane communication protocol stack that enables transparent communication between the user and the UE via a mobile access device. Figure 6The control plane communication protocol stack that enables transparent communication between the mobile access device and the UE is schematically illustrated. Figure 7 The diagram schematically illustrates the user plane communication protocol stack for regenerative communication with the UE via the mobile access device. Figure 8 The diagram schematically illustrates the user plane communication protocol stack for regenerative communication with the UE via the mobile access device. Figure 9 The process for secure distribution of SIB 19 is illustrated schematically; Figure 10 The process for securely distributing SIB19 content to authorized devices is illustrated schematically. Figure 11 A block diagram and communication paths through multiple networks are schematically shown; Figure 12 The architecture of a (mobile) access device according to an embodiment is illustrated schematically; Figure 13 The illustration schematically shows the functionality available in different communication paths supported by the (mobile) access device according to an embodiment; Figure 14 The process of an authorized (mobile) access device acting as a relay device according to some embodiments is illustrated schematically; Figure 15 Multi-hop communication on a mobile access device according to some embodiments of the present invention is illustrated schematically; Figure 16 The handover process of a mobile access device according to some embodiments of the present invention is illustrated schematically; Figure 17 The switching process of a dual-guide device according to some embodiments of the present invention is illustrated schematically; Figure 18 The components of a dual-guide device are schematically depicted. Figure 19 The procedure for locating the UE via the first and second mobile access devices during the handover process is illustrated schematically. Figure 20 Further procedures for locating the UE via the first and second mobile access devices during the handover process are illustrated schematically. Figure 21 A cellular network-based wireless system is illustrated schematically. Detailed Implementation

[0034] The International Telecommunication Union (ITU) defines TI (Haptic IoT) as an internet network that combines ultra-low latency with extremely high availability, reliability, and security. Mobile internet allows for the exchange of data and multimedia content while on the move. The next step is the Internet of Things (IoT), which enables the interconnection of smart devices. TI is the next evolution that will enable real-time control of IoT. It will add a new dimension to human-machine interaction by enabling haptic and tactile perception, while simultaneously revolutionizing machine interaction. TI will allow humans and machines to interact with their environment in real time while on the move and within a certain spatial communication range.

[0035] IEEE Publication P1918.1, "Tactile Internet: Application Scenarios, Definitions and Terminology, Architecture, Functions, and Technical Assumptions," requires cellular 5G communication systems to support a mechanism to facilitate synchronization between multiple streams (e.g., haptic, audio, and video) in a multimodal communication session to avoid negative impacts on user experience. Furthermore, 5G systems will be able to support data streams that interact with applications on user equipment (UEs) or group information within a haptic and multimodal communication service, and support units that apply third-party policies to application-related streams. This policy may include a set of UEs and data streams, anticipated Quality of Service (QoS) processing and associated triggering events, and other coordination information.

[0036] Dual bootstrapping (R19) is the SA1 research project reflected in 3GPP TR 22.841. TR includes multiple use cases (UCs) where a UE can access multiple networks (different PLMNs, TNs, NTNs, etc.) and needs to coordinate access across these different networks. TR captures a set of use cases and potential service requirements related to: 5G system support for service bootstrapping, splitting, and handover of UE user data (related to the same data session) across two 3GPP access networks. Different scenarios are covered: the same Public Land Mobile Network (PLMN), two PLMNs, or between a PLMN and a Non-Public Network (NPN), considering only a single PLMN subscription. Use cases cover a variety of example combinations of 3GPP access networks using the same or different Radio Access Technologies (RATs), including New Terrestrial Radio (NR) plus NR or NR plus Evolved UMTS Terrestrial Radio Access (E-UTRA) (e.g., using a combination of Evolved Packet Core (EPC) and 5G Core Network (5GC)), hybrid terrestrial plus satellite NR, and dual NR satellite access (e.g., using the same or different Non-Terrestrial Network (NTN) orbits, such as Geostationary Equatorial Orbit (GEO) / Medium Earth Orbit (MEO) / Low Earth Orbit (LEO)). In the PLMN / NPN inter-network scenario, it is assumed that there is an appropriate service agreement between the two network operators (without affecting normal PLMN roaming), and that the UE's user data transmitted through the two networks is anchored in the Home PLMN (HPLMN) core network.

[0037] Capture the following use cases UC1 through UC17 in TR 22.841:

[0038] Prior to the SA1 study summarized in TR 22.841, there had been work allowing access through multiple networks. The current architecture is described in Clause 4.2.10 of TS 23.501. For example, in TS 23.501... Figure 4Section 2.10-1 describes the architecture for non-roaming and roaming applications, as well as the local interrupt architecture for ATSSS support. The N1 interface is responsible for communication of NAS signaling messages between the User Equipment (UE) and the Access and Mobility Management Function (AMF), and in this case, it operates through two different types of access networks. The N1 interface 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 to provide user plane connectivity between the 5G RAN and 5GC. The N3 interface provides user plane connectivity between the 5G RAN and 5GC, uses the GPRS tunneling protocol GTP-U for tunneling user data, and supports new Packet Data Unit (PDU) session containers for 5G user plane encapsulation. If the same PDU session is connected to multiple data networks, an N3 instance is separated for each connection. The N4 interface is the interface between the Session Management Function (SMF) and the User Plane Function (UPF). The SMF uses this interface to control the UPF and handle user plane packet forwarding, buffering, duplication, and dropping. The N4 interface's tasks include controlling the activation, modification, and deactivation of QoS flows; monitoring the state of the N4 session, including the user plane and QoS flow states; sending and receiving UP function-related information, such as statistics and congestion status; handling security-related issues and performing authentication and authorization for UP functions; and providing the UPF with the necessary information for UP functions to perform user plane services, such as IP address allocation and routing information.

[0039] In addition, device-to-device communication and proximity services have been standardized in 4G and 5G, enabling communication between UEs, such as direct communication between two UEs, communication between a remote UE and a CN via a relay UE, or UE-to-UE relay communication.

[0040] Furthermore, the 3GPP SA2 group is conducting research in TR 23.700-29-020 enhancements to integrate satellite components into the 5G architecture. In this context, - A serving satellite is a satellite that provides satellite access to the UE (e.g., provides service cells(s)). Depending on its orbit, a serving satellite covers a given geographic area for a limited period of time; - S&F (Storage and Forwarding) Satellite Operation: An operational mode that provides communication services to the UE (when storing and forwarding information) during time periods and / or geographical areas when the serving satellite is not simultaneously connected to the terrestrial network via a feed link or ISL. For UL (Upper Length) information, "storage" refers to onboard storage of UL information from the UE, and "forwarding" refers to forwarding the stored UL information to the terrestrial network. For DL ​​(Lower Length) information, "storage" refers to onboard storage of DL information from the terrestrial network, and "forwarding" refers to forwarding the stored DL information to the UE.

[0041] - UE-Satellite-UE Communication: refers to communication between UEs within the coverage area of ​​one or more serving satellites, using satellite access without requiring user services to be delivered via a terrestrial component; Inter-satellite links (ISLs) and feed links can function solely as transport layer links. Store-and-forward satellite operations can operate without ISLs.

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

[0043] - Enhanced NR UE-satellite-UE communication can assume the presence of a minimum set of core network entities, including at least the UPF, on the satellite; the serving satellite will be of MEO or LEO type. Furthermore, NR UE-satellite-UE communication for MMTEL service assumes communication between two UEs under the coverage of the same or different satellites.

[0044] The 5GC and EPC architectures used for satellite access in TS 23.501 and TS 23.401 are considered baselines, and it is assumed that at least eNB / gNB can be on a satellite.

[0045] Embodiments of the invention are now described within a cellular communication network environment such as 5G. However, the invention can also be used in conjunction with other wireless technologies that provide or can be introduced into TI or metaverse applications. The invention is also applicable to other applications, such as video streaming services, video broadcasting services, or data storage.

[0046] Throughout this disclosure, the abbreviation "gNB" (a 5G term) or "BS" (base station) is intended to refer to a wireless access device, such as a cellular base station, a WiFi access point, or an ultra-wideband (UWB) personal area network (PAN) coordinator. A gNB may include a centralized control plane unit (gNB-CU-CP), multiple centralized user plane units (gNB-CU-UP), and / or multiple distributed units (gNB-DU). The gNB is part of a radio access network (RAN) that provides an interface to functions in the core network (CN). The RAN is part of a wireless communication network. It implements radio access technology (RAT). Conceptually, it resides between communication devices such as mobile phones, computers, or any remotely controlled machine and provides connectivity to their CN. The CN is the core part of the communication network that provides numerous services to customers interconnected via the RAN. More specifically, it directs communication flows through the communication network and potentially other networks.

[0047] Furthermore, the terms "base station" (BS) and "network" may be used synonymously in this disclosure. This means, for example, when a "network" performs an operation, it can be performed by the 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 some functions are performed by the CN function of the wireless communication network and some functions are performed by the base station.

[0048] Dual Steer: Basic Introduction The following examples relate to enhanced authentication in wireless systems to allow users, for example, to obtain / send some data from / to an application function (AF), or to communicate with another remote user in an optimized / secure manner over multiple networks.

[0049] Figure 1 A block diagram schematically illustrates a network architecture that connects to multiple networks or accesses them via different radio technologies.

[0050] The network architecture includes a first user equipment (UE1) 100, in which a first SIM 101 and a second SIM 102 can be installed. Additionally, a second user equipment (UE2) 103 is provided, in which a first SIM 104 and a second SIM 105 can be installed.

[0051] The first UE 100 and the second UE 103 may include corresponding sensors 126, 127 that can be used for biometric-enhanced authentication / authorization.

[0052] The communication interface 120 is configured to allow direct communication between the first UE 100 and the second UE 103, for example, the PC5 interface in 5G.

[0053] Furthermore, the network architecture includes a radio access network (RAN) 106 with two or more access devices (e.g., gNBs) 107, 108 of a cellular network, wherein a first access device 107 may be configured to serve a first SIM 101 of a first UE 100 (or a first SIM 104 of a second UE 103), and a second access device 108 may be configured to serve a first and / or a second SIM 102 of the first UE 100 (or a first and / or a 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 UE 100 and the second UE 103.

[0054] In addition, the first core network 109 of the cellular network includes network functions 110 to 113, such as Access and Mobility Management Function (AMF), Authentication Server Function (AUSF), Unified Data Repository (UDR), AKMA Anchor Function (AAnF), Network Exposure Function (NEF), Location Management Function (LMF), etc.

[0055] In addition, the second core network 114 of the cellular network includes network functions 115 to 118, such as Access and Mobility Management Function (AMF), Authentication Server Function (AUSF), Unified Data Repository (UDR), AKMA Anchor Function (AAnF), Network Exposure Function (NEF), Location Management Function (LMF), etc.

[0056] In addition, Application Function (AF) 119 is provided, which is a control plane function for providing application services to subscribers, such as for video streaming services. If AF 119 is trusted, it can interact directly with core network functions, or if it is a third party, it can interact with NEF.

[0057] User plane functions allow the UE to access the data network. The UPF can be controlled by the SMF via the N4 interface.

[0058] in addition, Figure 1 The network architecture includes different types of devices 123 (e.g., unmanned aerial vehicles (UAVs) such as satellites) configured to provide connectivity to one or more UEs (e.g., first UE 100 and / or second UE 103). The different types of devices 123 can be configured to use different types of RATs, wherein a first communication interface 124 is provided between RAN 106 or a local gateway toward the different types of devices 123. Furthermore, a second communication interface 125 is provided between the different types of devices 123 and the first UE 100.

[0059] In the context of dual booting, UE 100 may have two SIMs and may refer to a dual booting device according to the current definition in TS 22.841, which includes two logical "UEs" that allow simultaneous data transmission over two networks, or a single UE that performs non-simultaneous data transmission over two networks. However, in the context of this invention, a single UE may also be used in the case of simultaneous data transmission over two networks or RAT.

[0060] The SIM contains the user's credentials, including the user's identity (e.g., Subscription Permanent Identifier (SUPI), IMSI, or PEI) or other keys used to perform master authentication according to TS 31.102. The UE's SIM can belong to the same core network or two different core networks.

[0061] exist Figure 1 Within the architecture, several implementations can be carried out, such as: In the first embodiment, only the first UE 100 exists and uses two SIMs 101, 102 to use (register / access) the same network.

[0062] In the second embodiment, only the first UE 100 exists and uses two SIMs 101, 102 to use (register / access) different networks.

[0063] In the third embodiment, only the first UE 100 exists, and only the first SIM 101 is used to access a different network / RAT (Radio Access Technology).

[0064] In the fourth embodiment, both a first UE 100 and a second UE 103 exist (in the case of dual booting, they can be two logical UEs in the same dual booting device), wherein the first UE 100 includes its first SIM 101, and the second UE 103 includes its first SIM 104, and SIMs 101 and 104 are associated with the same or different networks.

[0065] SIM 101, 102, 104, and 105 can be either physical SIMs or eSIMs that can be installed in an embedded Universal Smart Circuit Card (USCC). An eSIM is an industry-standard digital SIM that allows activation of a mobile plan from a network provider without the need for a physical SIM.

[0066] Given Figure 1 Based on the above architecture, different implementations are proposed to improve the authentication and authorization process in cellular networks.

[0067] The first scenario considers a UE with one, two, or more (e)SIM cards and associated with or connected to different networks and / or capable of using two different radio access technologies (specifically TN and NTN). It is also assumed that the networks potentially support combined processes, such as communication, location, or sensing processes, for example, combined AKMA processes. In the case of AKMA, we can further assume that the UE expects to access application functions, for example, outside (i.e., within) one of the networks or inside it. The challenge lies in potentially sharing network resources between the two networks to ensure that combined communication / sensing / location processes can be performed; for example, AKMA-secure data exchanged between the UE and AF can be exchanged across the two networks and successfully combined at the UE / AF.

[0068] In an embodiment addressing this scenario, network access (random access) and / or primary authentication are performed by UE 100 with both SIMs 101 and 102 (therefore SIMs 101 and 102 can be operated by two "logical" UEs within the same dual-boot device) and the core networks of two networks (e.g., a first core network (PLMN1) 109 and a second core network (PLMN2) 114). This means that UE 100 can perform network access on a first RAN (e.g., RAN 106) and perform subsequent primary authentication with the first network (PLMN1 109), and then perform subsequent primary authentication with the second network (PLMN2 114). This means that UE 100 uses the first SIM 101 for the security process with the first network PLMN1 109, and UE 100 uses the second SIM 102 for the security process with the second network PLMN2 114. In some cases, one PLMN can act as the serving PLMN of another PLMN; for example, PLMN1 109 can act as the serving PLMN of PLMN2 114. In this case, PLMN1 109 can have key materials for the two SIMs 101, 102 in UE 100 (e.g., the key K_SEAF for the security anchor function, the key K_AMF for the access and mobility management functions, etc.) and a UE identifier (e.g., a subscription permanent identifier (SUPI), which can be a string of 15 decimal digits, where the first three digits represent the Mobile Country Code (MCC), and the next two or three digits represent the Mobile Network Code (MNC) identifying the network operator). This can be used by the serving PLMN for better service provisioning.

[0069] In a relevant embodiment, the first UE 100 uses two different Radio Access Technologies (RATs) (e.g., terrestrial and non-terrestrial) to perform network access / primary authentication for SIM 101. For example, UE 100 can perform network access / primary authentication via a terrestrial access device (e.g., gNB), and the network can check that UE 100 is also authorized to use a non-terrestrial RAT / access device, allowing UE 100 to connect via a non-terrestrial link as well. In this case, UE 100 could be a mobile device such as a ship or UAV. The network can check whether UE 100 is authorized to use a non-terrestrial RAT / access device in the UE subscription policy, which may be stored in the Unified Data Management (UDM) / Unified Data Repository (UDR) / SIM. When this is detected, the network can contact a non-terrestrial gateway, such as a satellite gateway, to notify of the upcoming connection. The network can obtain information about the non-terrestrial RAT / access device to be used, and the network can notify UE 100 of this information via the terrestrial RAT, allowing UE 100 to connect to the non-terrestrial RAT / access device.

[0070] Similarly, UE 100 can use SIM 102 (which can be operated by separate "logical" UEs within the same device) to connect via a non-terrestrial RAT / access device. Therefore, the UDM / UDR can link two SIMs and / or store which of the two SIMs can connect to which RAT (which can be different or the same for both) and / or thus the two SIMs have stored information for associating with the two SIMs and / or which of the two SIMs can connect to which RAT (which can be different or the same for both). Similarly, UE 100 and UE 103 (which can operate within the same device) can communicate with each other and / or can store information in their respective SIMs to associate the two UEs and / or which of the two UEs can connect to which RAT (which can be different or the same for both). Such information can also be stored in the UDM / UDR.

[0071] In relevant embodiments, UE 100 may require certain services, such as AKMA service between UE 100 and AF 119, and for this purpose, UE 100 may need to select how (through which networks / RATs) to provide the service, such as AKMA service. UE 100 can then send indications (e.g., regarding which services it requires) to the first core network (PLMN1) 109 and / or the second core network (PLMN2) 114. UE 100 may also have a policy for determining which services can be performed on which networks / RATs and can route those services accordingly. The policy may be stored in one or more SIM cards in its SIM card and / or stored and manipulated by one or more "logical UEs" in its "logical UE". Where a service can be provided by more than a single network / RAT, UE 100 may decide to apply a multipath configuration that gives the network indication of this. Where a service is routed through two or more networks, one of the networks may act as the primary network for coordinating service delivery with the remaining networks.

[0072] In relevant embodiments, UE 100 may require a given service (e.g., AKMA, or communication, or sensing, or positioning, etc.), and for this purpose, UE 100 may need to choose how to preferentially provide or deliver that service. This choice may be based on a policy. The policy may be stored in the core network (e.g., UDM / UDR, PCF, SMF…) or the UE (e.g., SIM). This choice may also be taken by one of the networks (e.g., the main network as in previous embodiment variants). UE 100 may then send instructions (e.g., regarding which services it requires) to the first core network (PLMN1) 109 and / or the second core network (PLMN2) 114. The instructions to the first core network 109 may be NAS-protected. For example, the network may wish to deliver positioning services to UEs that require such positioning services. However, the terrestrial networks to which UE 100 is connected provide low accuracy. Therefore, the network or UE 100 may select to add additional anchoring equipment (i.e., equipment for determining the location of UE 100) based on non-terrestrial access equipment such as LEO satellites or unmanned aerial vehicles. The network can notify the UE 100 of positioning parameters used by appropriate non-terrestrial access devices (e.g., satellites). These positioning parameters may include the frequency / timing of the positioning signal, the identity of the positioning signal, etc.

[0073] In related embodiments that can be used in combination with other embodiments or independently, each SIM (e.g., when active) has and / or is connected to a policy / user subscription for determining whether it allows a dual-boot connection. A user can select in his / her UE which SIM acts as the primary / initial SIM to connect to the network. A user can select in his / her UE whether a dual-boot SIM can be used to implement a dual-boot connection. When a UE (e.g., 100) registers / requests a dual-boot connection for its two SIMs (e.g., 101 and 102), the core network can determine whether the connection can be dual-booted.

[0074] The above embodiments can help identify which strategies may be needed to support dual-boot service onboarding and switching, in particular: - Does the HPLMMN need to provide a policy, and if so, what policy should be provided, to guide the dual-boot device in deciding whether to connect to the additional PLMN / PNI-NPN or the additional 3GPP access network within the same PLMN? -For dual-boot service bootstrapping, does the HPLMMN need to provide a policy and what policy needs to be provided to guide dual-boot devices to select a 3GPP access network for new services? - For dual-boot service handover, does the HPLMMN need to provide policies and what policies need to be provided to guide dual-boot devices to perform service handover between two connected 3GPP access networks? - Whether to provide policies within the network and what policies to provide to handle dual-boot service booting and / or dual-boot service handover; - Investigate whether and how the policy enhancements of dual-boot devices affect existing UE policies.

[0075] Summary: Dual-booting - Registration and Authentication A dual-booting UE connects to two or more networks. In some scenarios, UE 100 (which may include two SIMs that can be operated by two "logical UEs") can connect 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. Therefore, in relevant embodiments, in order for PLMNs (PLMN1 109 and PLMN2 114) to confirm that UE 100 (which may include two SIMs that can be operated by two "logical UEs") is connected to other PLMNs, PLMN1 109 (and / or PLMN2 114) can send a token to UE 100, and UE 100 can send the token received from PLMN1 109 (and / or PLMN2 114) to PLMN2 114 (and / or PLMN1 109), allowing PLMN2 114 to verify it. Other possible interactions (Intj) may include: Int1: PLMN1-->UE(SIM1)(-->UE(SIM2))-->PLMN2).

[0076] Int2: PLMN1-->UE(SIM1)(-->UE(SIM2))-->PLMN2-->PLMN1(-->PLMN2).

[0077] Int3: PLMN2(-->UE(SIM2))-->UE(SIM1)-->PLMN1).

[0078] Int4: PLMN2(-->UE(SIM2))-->UE(SIM1)-->PLMN1-->PLMN2(-->PLMN1).

[0079] Int5: UE(SIM1)-->PLMN1-->PLMN2(-->UE(SIM2))-->UE(SIM1)(-->UE(SIM2))).

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

[0081] Int7: UE(SIM1)(-->UE(SIM2))-->PLMN2-->PLMN1-->UE(SIM1)(-->PLMN1)) Int8: (UE(SIM2)-->)UE(SIM1)-->PLMN1-->PLMN2(-->UE(SIM2))(-->PLMN2)) In the above interactions, for example, "Intj" refers to the interaction number j, where j = 1 to 8; A->B (without parentheses) means entity A sends a message to entity B; and (A->B) (within parentheses) means optional entity A sends an optional message to entity B, such as a final confirmation. As in this example, the first and last entities in the interaction chain perform verification. For example, when the UE has a single SIM / subscription for connecting to two different networks, the optional entity could be SIM2.

[0082] In related embodiment variations, the token used in the above variations can be: Random value (as a challenge), As an authorization token for signing statements, Cryptographic functions (keyed hashes, encrypted values, etc.) that use keys shared between SIMi and PLMNi (e.g., root key, keys derived from the root key (such as keys used in the NAS security context)), random values, or counters (e.g., one-time values ​​(nonce)).

[0083] Random values ​​can be applied to the interactions described above, such as interactions 2, 4, 5, 6, 7, and 8, because it is necessary to receive any value sent to UE 100 (which may include two SIMs that can be operated by two "logical UEs") via the communication interface between PLMN1 / PLMN2 on a communication link protected based on PLMN1 / SIM1 (e.g., the NAS context associated with PLMN1 / SIM1). For example, in Int2: PLMN1 109 can use a key stored (derived from / based on) secret items in SIM1 101 to send an end-to-end protected token / random value from PLMN1 109 to SIM1 101 / UE 100. SIM1 101 / UE 100 can check the token / random value based on those secret items and instruct SIM2 102 / UE 100 to protect the same token / random value based on (derived from / based on) a key in SIM2 102. UE 100 can share the secret with PLMN2 114, which can verify the token / random value. Finally, PLMN2 114 can securely share the token / random value with PLMN1 109. If PLMN1 109 receives the same token / random value as initially sent, PLMN1 109 can verify that UE 100 is connected to two different networks. Finally, PLMN1 109 can send an optional confirmation message to PLMN2 114 indicating positive / negative verification. Note that for Interaction 5 (similar to Interaction 6), if UE (SIM1) 100 encrypts (typically, for protection, as various techniques can be used to protect transactions, e.g., message integrity codes can also be generated) a random value using a key shared with PLMN1 109, and PLMN1 109 decrypts and sends it to PLMN2 114, and PLMN2 114 encrypts it using a key shared with SIM2 102, and SIM2 102 decrypts it, then SIM2 102 can share the decrypted value with UE (SIM1) 100, and SIM1 101 can verify it. The fact that SIM1 101 performs verification means that all entities SIM1 101 / SIM2 102 / PLMN1 109 / PLMN2 114 agree on the transaction. This also means that UE (SIM1) and UE (SIM2) are in the same physical UE. In Interaction 5, the final step is optional and can be considered the final verification step.

[0084] Authorization tokens can be used in interactions 1 and 3, for example, because PLMN i can sign an authorization token for PLMN j that declares its authorization for use on the UE's public communication link. The authorization token may include an expiry date and / or other contextual information. PLMN i can use such an authorization token to notify both the UE and PLMN j that PLMN i agrees to / allows the combined communication process.

[0085] In relevant embodiments, tokens can be sent / exchanged after the metadata of the communication characteristics is determined, enabling both networks to determine / learn the characteristics of the network / connection. For example, the token may include information about: - SIM cards used together (including credentials, user identifiers, etc.) - A network for working together, - Services that can be provided and services that can be omitted - The network entity responsible for providing / managing services.

[0086] In related embodiment variations that can be used in combination with other embodiments or independently, if the two core networks 109, 114 approve a combined service, for example by means of an authorization token, then UE 100 (which may include two SIMs that can be operated by two "logical UEs") or application function 119 can perform a combined service, such as communication, for example AKMA-based communication, using only (as requested) both core networks 109 and 114. Note that the authorization token can be valid for a given transaction, a given time period, or a given context (e.g., location). Entities in the core network (e.g., the first core network 109) (e.g., Figure 2 302) is responsible for managing the delivery of combined services.

[0087] Summary: Dual Guidance - Further Authentication Aspects In some scenarios, a UE may use the ability to connect to multiple networks to establish two or more independent connections, instead of establishing a single connection across two or more networks. This could mean that the user / UE might misuse the ability to establish two or more independent connections across two or more networks. Therefore, it is important to address this threat through the embodiments described above or through the additional implementations below.

[0088] In related embodiments that can be used in combination with other embodiments or independently, the UE may use two or more serving networks to establish a connection, for example, such as Figure 3 or Figure 11 As shown. In Figure 11In this configuration, a UE (1100) with a home PLMN 1103 is connected via serving networks 1101 and 1102. To connect to a serving network, the UE must register with both serving networks 1101 and 1102. To do this, it can first perform network registration / primary authentication with its home PLMN 1103 via serving network 1101 (e.g., the AMF of the first serving network). The home network 1103 can check whether the UE is authorized to establish a multipath network connection. The UE can send an indication to the home PLMN 1103 regarding its intention to connect via the second serving network 1102 during this first primary authentication process or in a later message. The home PLMN 1103 can also send an indication to the UE regarding the need to establish a multipath connection via the second serving network 1102.

[0089] In related embodiments that can be used in combination with other embodiments or independently, the initial message for registering a UE (e.g., 1100) in a network may include the UE's capabilities, such as whether it supports connections via multiple networks.

[0090] In related embodiments that can be used in combination with other embodiments or independently, once the first primary authentication has been performed, UE 1100 can perform a second network registration / primary authentication via the second serving network 1102. In this case, when the home PLMN 1103 receives it, the home PLMN 1103 (e.g., UDM) checks whether UE 1100 is authorized to have multipath multi-network connectivity, i.e., connectivity on multiple networks, i.e., dual-booted connectivity. If UE 1100 is not authorized, the home PLMN notifies the second serving network 1102 (e.g., AMF) and stops the second primary authentication process. If UE 1100 is authorized, the home PLMN 1103 completes the second primary authentication process, i.e., by sending a registration acceptance message.

[0091] It should be noted that the UE 1100 in the previous and subsequent embodiments can be with Figure 3 The UE 100 is the same / similar, and the UE includes two SIM cards with corresponding credentials (which can be operated by two "logical UEs"), such that each master authentication is performed using the credentials of one of the SIM cards (e.g., a different SUPI).

[0092] In related embodiments that can be used in combination with other embodiments or independently, the home PLMN 1103 can initiate home network-triggered primary authentication through the serving network 1102 to verify the identity of the UE 1100 and the UE 1100's intent to establish a multipath connection.

[0093] In related embodiments that can be used in combination with other embodiments or independently, the home PLMN 1103 may share with the serving network 1102 a key derived from a first primary authentication (e.g., K_SEAF) and the UE's identity (e.g., SUPI, GUTI). These keys / identities (used as tokens in other embodiments) can be used by the UE 1100 to join the serving network 1102 because the serving network 1102 already has a suitable security context when the UE 1100 sends its registration request and can use it to verify the UE 1100's registration request.

[0094] In related embodiments that can be used in combination with other embodiments or independently, the home PLMN 1103 can provide a token, such as a random number or authorization token, to the UE 1100 via the first serving network 1101. The UE 1100 will use this token when it wishes to perform network registration via the second serving network 1102 as part of a second primary authentication process. When the home PLMN receives this token, it knows that it is a UE already connected to the first serving network 1101, and can, for example: Stop the second primary authentication process; Share the UE's key / identity established / learned from the first primary authentication process with the second service network; Notify the second service network: It is guided by the first service network.

[0095] In another related embodiment, which can be used in combination with other embodiments or independently, when UE 1100 begins the second primary authentication process through the second serving network 1102, the home PLMN 1103 performs different actions depending on whether UE 1100 has an active connection through the first serving network 1101. 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 authorized to have two independent connections, but rather a single multipath, the home PLMN 1103 may perform one or more of the following: - Reject the second primary authentication process. - Instruct UE 1100 to switch back to the first serving network 1101, -Notify UE 1100 to attempt to connect via the second service network 1102 to the first serving network 1101. -Initiate a handover process between the two service networks 1101 and 1102. - Indicate to the second network that the connection can only be used in multipath mode, where the first network 1101 can be in a bootstrap role.

[0096] On the other hand, if the connection is not active, the home PLMN 1103 can perform one or more of the following: - Allows a second master authentication process. - Instruct UE 1100 to disconnect from the first serving network 1101. - Notify UE 1100 of moving to the second serving network 1102 to the first serving network 1101. - Release any resources allocated to UE 1100 in the first service network 1101 (e.g., the guiding role in a multipath connection).

[0097] Summary: Dual Guidance - Further Authentication Aspects In this scenario, a UE / dual-booting device (e.g., a UE 100 with two SIMs that can be operated by two "logical UEs") registers on a first 3GPP access network PLMN1. The device initiates an application / service and, based on URSP rules, determines that the application / service requires a multipath connection (e.g., a dual-booting PDU session). The device selects a network to provide a second 3GPP access, for example, based on HPLMN policies. This selection may trigger the device to send a registration request message to the second network PLMN2. The registration request message may include: an indication that the registration is for a second 3GPP access tributary to be used for dual-booting, and an identifier (PLMN1) of the network the device has registered with in the first instance. The second network (e.g., the AMF) may determine whether to accept or reject the registration based on the type of registration (e.g., whether the registration is for the second 3GPP access network) and the device's identity on the network it has registered with in the first instance. If the AMF accepts the registration, it sends a registration acceptance message to the device, including instructions on the registration / connectivity / mobility management procedures on the second 3GPP access network. This scenario has several limitations; for example, the AMF of the second network cannot determine whether the device is connected to the first network. The following examples are intended to improve this situation.

[0098] In embodiments relating to the registration of a UE / dual boot device that can be used in combination with or independently of other embodiments, the UE / dual boot device's registration request message to a second network may include a token that allows the second network to verify that the UE / dual boot device is connected to the first network.

[0099] In embodiments related to the registration of a UE / dual boot device that can be used in combination with other embodiments or independently, the UE / dual boot device's registration request message to the second network can proceed to perform primary authentication, and once the relevant SIM (e.g., 101 and / or 102) is authenticated, and the AUSF and / or UDM has checked the user subscription, the AUSF / UDM can determine whether to allow the connection and notify the SEAF and AMF of the second network.

[0100] In the second scenario, the UE / dual-booting device (e.g., UE 100 including a first SIM and a second SIM that can be operated by two "logical UEs") can connect to the first RAN and send a registration request to a mobility function (e.g., AMF) in the first network. This request may include the UE / dual-booting device's ability to establish connections on both networks. Next, for example, before the mobility function obtains a subscription profile from a data function (e.g., UDM) containing subscriber data / profiles, a registration procedure as specified in, for example, section 4.2.2 of TS 23.502 may be performed. The subscription profile may include whether the first SIM 101 is allowed to manage connections on both networks. It may include information related to the second SIM 102. If authorized, the following steps specified in section 4.2.2 of TS 23.502 may be performed. The first mobility function may send a registration acceptance message to the UE / dual-booting device. This message may include an indication that connections are permitted through both networks. The UE / dual-booting device can connect to a second RAN / RAT and can use the second SIM 102 to send a registration request to a second mobility function (e.g., a second AMF) in the second network. The registration procedure specified in section 4.2.2 of TS 23.502 can then be performed. The second mobility function can send a registration acceptance message to the UE / dual-booting device. Finally, the UE / dual-booting device can trigger a mobility registration update procedure to the first network to associate the dual-SIM registration context by sending a new registration request including information from the second SIM and / or access network information for the core network (i.e., the ID of the second network, access network type, and RAT type, etc.). During the mobility registration update procedure, the association information is stored in the first network (e.g., mobility function or policy function), and the PCF can be reselected to ensure that both USIMs are served by the same network (e.g., the PCF).

[0101] It should be noted that, as in other embodiments, the mobility registration update procedure can be used as a token to verify that both USIM / SIMs are aware of the UE connection on both networks. Specifically, the mobility registration update procedure can use a cryptographic function (key hash, encrypted value, etc.) of a random value or a counter (e.g., a one-time value) as a token, thereby using a key shared between SIMi and PLMNi (e.g., a root key), such as a key derived from the root key, such as a key used in the NAS security context, such as a token as in the embodiments described above.

[0102] In another embodiment, which can be used in combination with other embodiments or independently, tokens such as those used in mobility registration update processes may include information about linked SUPIs, types of services allowed / enabled using multiple networks / RATs, target QoS, etc.

[0103] In another embodiment, which can be used in combination with other embodiments or independently, the first network may notify the UE / dual-booting device (e.g., a UE 100 that may include a first SIM and a second SIM that can be operated by two "logical UEs") of its availability of services triggered by connections via both networks / RATs. For example, the first network may assess whether a given service is permitted, and it may provide the UE / dual-booting device with the configuration of said service. The UE / dual-booting device may have previously requested said service as well.

[0104] In another embodiment, which can be used in combination with other embodiments or independently, upon receiving a mobility registration update process, the first network (e.g., a first mobility function, a data function, etc.) can verify that the UE / dual-booting device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") is currently connected to the second network. For example, if both SIMs belong to the same home network, the data function is aware of both the network registration / master authentication processes of the first SIM 101 and the second SIM 102. The mobility registration update sent by the UE / dual-booting device 100 serves as final confirmation, causing the first mobility function to check the event together with the data function. The UE / dual-booting device 100 may include requested parameters / services (for the second network) that can also be verified by the first network during the mobility registration update process.

[0105] In another scenario, a UE / dual-booting device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") can register using a first SUPI of the first SIM 101. The UE / dual-booting device 100 sends a registration request via a first RAN to a first mobility function (e.g., AMF), the registration request including its ability / request to support connections over multiple networks. If a token was previously received from that serving network, the UE / dual-booting device 100 can include the token in the registration. The first mobility function can then trigger SUPI / SIM authentication. If successful, the mobility function can request the data function to register itself as a serving mobility function. The mobility function can indicate that it is capable of handling connections over multiple networks. The data function can then check whether the SUPI is linked to a subscription to enable connections / services over multiple networks, and check whether the SUPI is the primary SUPI. The data function provides the mobility function with a token, such as an identifier for enabling functions over multiple networks and identifying the SUPI pair, and an authorization indication. The mobility function can then send a registration acceptance to SIM 101 in the UE / dual-booting device 100, thereby authorizing the ability to use communications / services on multiple networks. The UE / dual-booting device can then determine whether it can act as a device capable of using communications / services on multiple networks, and if so, whether to perform registration with the secondary SUPI. A token can be used to identify the second SUPI. The UE / dual-booting device 100 can register using the second SUPI via the second SIM 102. The UE / dual-booting device 100 sends a registration request via the second RAN to the second mobility function (e.g., AMF), which includes its ability / request to support connections via multiple networks. If a token was previously received from the serving network, the UE / dual-booting device 100 can include the token in the registration. The second mobility function can then trigger authentication of the second SUPI / SIM. If successful, the mobility function can request the data function to register itself as a serving mobility function. The mobility function can indicate that it is capable of handling connections on multiple networks. The data function can then check whether the SUPI is linked to a subscription to enable connectivity / services on multiple networks, and whether the SUPI is a secondary SUPI. If the primary SUPI is inactive, the data function can refuse the connection. The data function can then provide a second mobility function with the same token associated with both the primary and primary SUPIs. For example, if the UE / dual-booting device 100 is not allowed to use the SUPI at its current location, the second mobility function can refuse registration. Otherwise, it can send a registration acceptance. Finally, the UE / dual-booting device 100 can associate both the primary and secondary SUPIs based on the tokens to support communication / connectivity / services on multiple networks.This further scenario presents some problems; for example, while it appears the same data functionality could be used to deliver tokens in both the first and second registrations, this cannot occur if SIM 101 and SIM 102 are associated with different home networks. Therefore, embodiments of the present invention can address some of these problems. In embodiments related to registration of a dual-booting device that can be used in combination with other embodiments or independently, the SUPI can be a primary SUPI or a secondary SUPI, and its role can be determined during operation or by the user. For example, a user can use UE 100 (which may include a first SIM and a second SIM that can be operated by two "logical UEs") to determine / configure a SIM (e.g., 101) as the primary SIM (and then include the primary SUPI). A first registration message can then indicate that it is operating as the primary SUPI. This can also trigger the identification of another SIM (e.g., 102) as the secondary SIM (and then include the secondary SUPI). A second registration message can then indicate that it is operating as the secondary SUPI.

[0106] In embodiments that can be used in combination with other embodiments or independently, dual-booting connectivity (i.e., connectivity between two networks) can be active, for example, using a first SIM 101 / SUPI as the primary SUPI and a second SIM 102 / SUPI as the secondary SUPI. The user can then determine that the roles should be reversed, i.e., SIM 102 should act as the primary SUPI and SIM 101 as the secondary SUPI. This can trigger a role reconfiguration, where control of the dual-booting connectivity moves from the first serving network (associated with SIM 101) to the second serving network (associated with SIM 102). For example, a UE / dual-connectivity device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") can send a request to the second network to become the primary network, and the second serving network can send a token indicating its confirmation. The UE / dual-booting device can then send another request to the first serving network to become the secondary network, possibly including the token. The token can serve as proof against the first network that the second network accepts taking over the role. The first serving network can then confirm the change to the UE / dual boot device, and can also confirm the change to the second serving network directly or through the UE / dual boot device (e.g., by means of another token).

[0107] In embodiments (6DS_c) that can be used in combination with other embodiments or independently, the token may contain additional information, such as: - The first SUPI authorized to use the roles (primary and secondary), - The roles adopted by the authorized service network, - One or more SUPIs (or other user identities, such as GUTIs) can be associated with a primary / secondary SUPI (or other user identity). - The services provided by dual-boot connection can be utilized. - Conditions under which services can be provided (e.g., given UE location), or - A RAT (e.g., WLAN, NTN, etc.) that can be used for a given connection (e.g., primary or secondary connection in a dual-boot connection).

[0108] In embodiments that can be used in combination with other embodiments or independently, the network can communicate directly or via a UE / dual boot device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") to agree on roles. For example, in a previous scenario, the data functions of the first and second networks could interact with each other directly or indirectly (e.g., via NEF or UE) to check which role each SIM / SUPI is playing.

[0109] A dual-boot device (e.g., a UE 100 that may include a first SIM and a second SIM operable by two "logical UEs") may be associated with two SIM / USIM / eSIM / SIM cards, each with a SUPI and corresponding credentials. These two SIMs / SUPIs should work together within the same (physical) device. These peer SIMs may be a primary / master / first SIM SIM_1 with SUPI_1 and a secondary / secondary SIM SIM2 with SUPI_2. However, there is a risk that they may be misused and inserted into two different devices (as indicated in other embodiments). To address this risk, in embodiments that can be used in combination with other embodiments or independently, each SIM may be configured to be adjacent to its own SUPI, with the peer SUPI (e.g., SIM_1) also containing SUPI_2. Furthermore, the SIM may have credentials (e.g., a key) to verify / authenticate itself when inserted into the same device. Additionally, the first SIM / SUPI may be the primary SIM / SUPI, and the second SIM / SUPI may be the secondary SIM / SUPI. When a dual-boot SIM card is inserted into a device, the SIM card can check whether the peer SIM card is in the same device / activity, for example, by executing security protocols such as authentication protocols or challenge / response authentication protocols, and determine the type of permitted operation for the UE / mobile device based on the authentication result and the type of SIM / SUPI. For example, a user may need to enter a PIN to unlock SIM_1 and enter a PIN to unlock SIM_2, and within a time window, both SIM cards may need to execute security protocols. If the security protocol fails, the functionality provided by the SIM (and the mobile device) can be restricted. For example, only the primary SIM (SIM_1) may enable connectivity, while the secondary peer SIM (SIM_2) may not enable connectivity (e.g., it may only be used in emergency mode). In other words, if SIM_1 is inserted into the first device Device_1 and SIM_2 is inserted into the second device Device_2, Device_1 and SIM_1 can function as a normal UE, but Device_2+SIM_2 may be inoperable and unable to connect to the network; for example, SIM_2 may remain locked (e.g., only providing emergency access). In other cases, if the SIM / SUPI is not plugged into the same physical device, neither of them can establish a connection.

[0110] Generally, a device (6DS_SIM) for implementing cellular connectivity is described, wherein the device is adapted to: Insert into mobile device Receive PIN, The unlocking process is performed based on the received PIN. Check / verify / confirm the presence of a peer SIM inserted into the same mobile device. Based on the peer-to-peer SIM check, the enabled communication parameters are adjusted, and Apply them when interacting with mobile devices.

[0111] Typically, the device (6DS_SIM_1) can be adapted to take into account at least three types of enabled communication parameters: - Only in emergencies, when the device cannot detect the presence of a peer SIM inserted into the same mobile device and the device contains a secondary SUPI. - Standard UE, when the device cannot detect the presence of a peer SIM inserted into the same mobile device and the device contains a primary SUPI, and - Dual-boot UE, when the device can detect the presence of a peer SIM inserted into the same mobile device.

[0112] In embodiments that can be used in combination with other embodiments or independently, a SIM (e.g., SIM1 / SIM2 as in previous embodiments) can be configured in a dual-booting device by a home PLMN. For example, when a user possesses a first SIM, which may be a primary SIM with a primary SUPI, and when a dual-booting device already configured with the first SIM is connected to the home PLMN and uses the credentials of the first SIM, the user can request a second SIM with a secondary SUPI for the dual-booting device, and this eSIM can be downloaded to the dual-booting device. The secondary SUPI, and the link between the primary and secondary SUPIs, can then be stored in a data function (e.g., UDM). The secondary SUPI can then be configured in the first SIM. The second SIM may also have a key derived from the master secret in the first SIM, allowing the first SIM to verify that the second SIM is the SIM paired with it as the secondary SIM.

[0113] In embodiments that can be used in combination with other embodiments or independently, the tokens used / delivered by different networks can be different and can serve as confirmation of communication / connection or a part thereof. For example, in an earlier scenario, after a first registration network, the first network can deliver a first token, such as a first (authorization) token. For example, in an earlier scenario, after / within a second registration network, a UE / dual-connectivity device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") can send the first (authorization) token. For example, the second network can check the first (authorization) token before issuing the second (authorization) token. For example, the UE / dual-booting device can receive the second (authorization) token and check that the two (authorization) tokens are compatible (e.g., the first token authorizes the first SIM to act as the primary SUPI, and the second token authorizes the second SIM to act as the secondary SUPI of the first SUPI). Finally, the UE / dual-booting device can send the second token to the first network to finally enable service / connection.

[0114] In this invention, a UE / dual-booting device (e.g., a UE 100 that may include a first SIM and a second SIM that can be operated by two "logical UEs") can use two SIMs to establish connections on two networks and / or RATs. Such a connection can be represented as a dual-booting connection, thereby including a joint PDU session operated by both SIMs (e.g., a dual-booting PDU session) (e.g., having the same PDU session ID or another shared identifier) ​​or a set of PDU sessions operated by either SIM (but part of the same logical connection, e.g., having the same IP address and / or anchored in the same UPF). Such a connection can be used to deliver a given service via a dual-booting connection. For the two networks and / or RATs, one of these networks and / or RATs may act as the primary network / primary RAT, while the other network and / or RAT may act as the secondary network and / or secondary RAT.

[0115] In another scenario, a UE / dual-booting device capable of connecting via two RATs / networks (e.g., ...) Figure 1UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs", may send a registration request to a first mobility function (e.g., AMF1) via a first RAT (e.g., a terrestrial network), wherein the first request is based on credentials of the first SIM 101. The first mobility function may authenticate it by interacting with an authentication function and a data function (e.g., AUSF / UDM using Authentication / Nudm_SDM_Get). If successful, it may send a registration acceptance. The mobility function may interact with a policy function (e.g., PCF) to perform a UE policy association establishment procedure (e.g., as in Section 4.16.11 of TS 23.502). The policy may then be delivered to UE / dual bootstrapping device 100, which may be configured, for example, for connectivity of the second SIM 102, as shown in other embodiments. The policy may use credentials of the second SIM 102 to trigger a later registration step to the second RAT / network. The registration request may be forwarded to the second mobility function, which may interact with the authentication function / data function to authenticate the device. If successful, registration acceptance can be triggered. Then, the UE / dual-boot device 100 can perform PDU session establishment via the second network.

[0116] In this scenario, the UE / dual-booting device 100 can connect to, or can connect to, two networks / RATs to receive a given service. However, it is unclear when the UE / dual-booting device should use which network / RAT. Furthermore, in cases where the network is unaware whether the UE / dual-booting device might have more than two sets of SIMs / credentials, the network determines earlier in the process which two SIMs / credentials to use in combination. Therefore, embodiments of the present invention can be applied to determine how to enable such a connection / service.

[0117] In embodiments that can be used in combination with other embodiments or independently Figure 1 The UE 100 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 can 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 be used in a dual-boot connection based on a given criterion or policy. The credential selection module may be part of a policy module, or a separate module or user interface.

[0118] The credential selection module (2DSb) can select a set of credentials based on user preferences, network availability, service requirements, or network policies. For example, a user might prefer using a satellite network for video streaming, a cellular network for voice calls, and a WLAN network for web browsing, and may have a fallback preference in the event of a primary network failure or low availability. Alternatively, the network can indicate which credential sets are suitable or preferred for a particular service or purpose. For example, for low-latency services, the network might prioritize cellular networks over satellite networks, or vice versa for high-bandwidth services. A service can also specify which credential sets are necessary or optimal for its functionality or quality. For example, a service might require a secure connection over a trusted network or a reliable connection over a robust network.

[0119] The credential selection module can include a set of available and / or (pre)selected credentials in the initial message sent to the network (such as an initial registration request, authentication request, or PDU session establishment request). The initial message may include the UE / user / equipment identifier associated with the selected credential set, such as SUPI, SUCI, GUTI, IMEI, etc. The initial message may also include the intended service or connection purpose, such as voice calling, video streaming, web browsing, etc. The network can then pre-select one or more credential sets suitable for the desired service based on this information, and indicate this to the UE, for example, in a registration acceptance message, once the first credential set (e.g., SUPI) is authenticated. One or more credential sets can be provided according to a given priority. A policy can be selected for this selection to be provided after the first registration. For example, the network can select a cellular network and a satellite network for video streaming and provide a policy to split traffic between them based on bandwidth availability. Alternatively, the network can select a cellular network and a WLAN network for web browsing and provide a policy to switch between them based on signal strength. The credential selection module can then use the selected credential set to establish a dual-boot connection via the corresponding network / RAT according to the policy.

[0120] In another related example, which can be used in combination with other embodiments or independently, the UE / dual-booting device (e.g., Figure 1The UE 100, which may include a first SIM and a second SIM that can 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-booting connection over multiple networks / RATs. When a first registration request / master authentication is completed for the first SIM 101, the credential selection module can receive an indication from the network regarding which SIM to use for the second registration. For example, the network may know that the UE / dual-booting device 100 also has two other SIMs, and based on context (e.g., desired service, user identity, network conditions, etc.), the network may provide the UE / dual-booting device 100 with an indication regarding which SIM to use for the second registration in the dual-booting connection. The network may send this indication in a registration acceptance message or in a subsequent message after the first registration is completed. The credential selection module can then use the indicated SIM to perform the second registration and establish a dual-booting connection over the corresponding network / RAT. For example, the network may instruct the UE / dual-booting device 100 to perform a second registration using a third SIM associated with a non-terrestrial network operator, and the UE / dual-booting device 100 can then establish a dual-booting connection via a terrestrial network (e.g., LTE) using SIM 101 and a non-terrestrial network (e.g., LEO) using the third SIM. Alternatively, the network may instruct the UE / dual-booting device 100 to perform a second registration using a second SIM associated with a different terrestrial network operator, and the UE / dual-booting device 100 can then establish a dual-booting connection via two different terrestrial networks (e.g., NR and WLAN) using SIMs 101 and 102.

[0121] In related example scenarios that can be used in combination with other embodiments or independently, the UE / dual-booting device (e.g., Figure 1 The UE 100, which may include a first SIM and a second SIM (operable by two "logical UEs"), includes a policy module that stores and executes communication policies for using multiple networks / RATs in a dual-boot connection. This policy module can boot... Figure 18Block 1806 or a portion thereof. Communication policies can be configured by the user, service provider, or network operator and can be dynamically updated based on network conditions, user preferences, or service requirements. The policy module can communicate directly or indirectly with the protocol stack and application layer of the UE / dual-booting device 100 to monitor and control communication paths through different networks / RATs. Communication policies can specify conditions for using a second network / RAT as a supplement or replacement for the first network / RAT in a dual-booting connection. For example, the first network / RAT can be a terrestrial network, such as LTE, NR, or WLAN, and the second network / RAT can be a non-terrestrial network, such as LEO, MEO, or GEO satellite networks. For example, the first network / RAT in a dual-booting connection can be a WLAN, and the second network / RAT can be a terrestrial cellular network.

[0122] The policy module (2DSc) can determine that the connection will be based on a first network / RAT (e.g., switching / bootstrapping applications / services to use the first network / RAT, for example, by extending URSP rules with one or more conditions for using a specific network / RAT in a dual-boot connection), and the UE / dual-booting device 100 should only begin using a second network / RAT (e.g., switching / bootstrapping applications / services to use the second network / RAT, for example, by extending URSP rules with one or more conditions for using a specific network / RAT in a dual-boot connection) when the service QoS (e.g., communication latency, jitter, bandwidth, reliability, security, etc.) drops below a given threshold. Alternatively, the policy module can determine that the connection is based on the second network / RAT, and the UE / dual-booting device 100 should only switch to the first network / RAT when the service QoS improves above a given threshold. The policy module can also determine that the connection uses both networks / RATs simultaneously and splits services between them based on service QoS or user preferences.

[0123] The policy module can receive feedback from the protocol stack and application layer regarding the current network status, available networks / RATs, and required / available service QoS. The policy module can also receive information about network capabilities, network load, and network policies from core network 109 and 114. Based on this information, the policy module 400 can decide whether to initiate, maintain, or terminate a dual-boot connection through different networks / RATs. The policy module can instruct: - The protocol stack performs different actions, such as: - Register in RAT / Network - Establish, modify, or release communication paths over the network / RAT, and - The application guides, switches, or splits the business accordingly.

[0124] The policy module can also notify users, service providers, or network operators of communication status and policy enforcement.

[0125] For example, UE / dual boot device (e.g., Figure 1 The UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs", can register to the first network and obtain a configuration / policy that determines that it can register to / connect to / use the second network when the service provided by the first network drops below a given level.

[0126] For example, UE / dual boot device (e.g., Figure 1 UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs", can register to a first network and obtain a configuration / policy that determines that it can register to / connect to a second network and remain in a given state (e.g., IDLE or INACTIVE) as long as the service provided by the first network drops below a given level. When this occurs, the UE / dual-boot device can enter a CONNECTED state in the second network.

[0127] To achieve more flexible and efficient dual-booting connections and / or ATSSS-based multipath communication, another embodiment may involve a policy module that controls communication paths and traffic allocation. The policy module can interact with the core network's PCF (Policy Control Function) and / or SMF (Session Management Function) to obtain policy information used by the UE / dual-booting device 100, and / or policy information used to bootstrap communication paths for connection establishment, modification, or release. For example, the policy module can obtain dual-booting and / or ATSSS rules from the PCF and / or SMF, which specify criteria for registering / using different networks and / or bootstrapping, switching, or splitting services on multiple paths, and define performance measurement configurations for metrics and thresholds used to evaluate path quality. The policy module can also provide feedback to the PCF and / or SMF regarding communication status and policy enforcement, such as connected networks, path selection, service distribution, path quality, user preferences, application requirements, or network conditions. Based on this feedback, the PCF and / or SMF can adjust the policy information accordingly and notify the policy module and / or UE / dual-booting device 100 of updated policy information. In this way, the policy module can facilitate more dynamic and adaptive multipath communication based on dual-booting and / or ATSSS, which can optimize user experience and network resource utilization.

[0128] The policy module can receive the policy using the UCU procedure in section 4.2.4.3 of TS 23.502.

[0129] In one scenario, data functionality (e.g., UDR) may include user-related policies or subscriptions that can allow the use of UE / dual-booting devices (e.g., Figure 1 The UE 100, which may include a first SIM and a second SIM (operable by two "logical UEs"), is connected via two or more RATs / networks. The policy may include subscription information for whether a SUPI is subscribed to a dual-booting service. The associated SUPI is a SUPI co-located with the subscribed SUPI in the UE / dual-booting device. The "dual-booting policy" may include a preferred PLMN / RAT combination with service service descriptors having further criteria (e.g., time, location, QoS). The "dual-booting policy" can be used for service bootstrapping and service switching.

[0130] This configuration (2DSd) may be too static; therefore, in another embodiment that can be used in combination with other embodiments or independently, the subscription bound to the SUPI can indicate whether it can be used as part of a dual-boot connection (a connection over two RATs / networks) and the conditions for such use (e.g., which RATs / networks are allowed / disallowed). The co-located SUPI can be selected on demand, for example, based on the required context or service.

[0131] In related embodiments that can be used in combination with other embodiments or independently, a subscription bound to a SUPI can indicate two or more additional SUPIs that can be used as part of a dual-booting connection, because different SUPIs can be used for different types of RATs and / or networks, and different SUPIs may be preferred depending on the services to be received. For example, a subscription may include three different SUPIs that can be used together (in pairs). UE / dual-booting device (e.g., Figure 1 The UE100 in the network may include a first SIM and a second SIM that can be operated by two "logical UEs" and may indicate a SUPI pair that it may wish to use at a specific point in time; or the network may indicate this information to the UE / dual boot device.

[0132] In a related embodiment (2DSe) that can be used in combination with other embodiments or independently, two SUPIs used together in (dual-booting) connections on different RAT / networks are assigned identifiers, such that the dual-booting connections can be managed in a combined manner (e.g., each pair of SUPIs stored in the UDM and / or UE can be assigned a different identifier). Once the registration of the first SUPI / SIM is successfully completed and / or once the registration of the second SUPI / SIM is successfully completed, the identifier and / or the selected (pair) of SUPIs can be determined or provided to the UE / dual-booting device (e.g., Figure 1The UE100 in the diagram may include a first SIM and a second SIM that can be operated by two "logical UEs". This identifier may be used, for example, by the UE / dual-booting device or the PCF to process the information for that particular connection, and the UE / dual-booting device may include it, for example, as part of its primary and / or secondary registration and / or during PDU session establishment. If the UE / dual-booting device then initiates a second dual-booting connection with a different pair of SUPIs (e.g., in, for example, three different SUPIs), the second dual-booting connection may be distinguishable by the network and may be managed differently by the network.

[0133] In related embodiments that can be used in combination with other embodiments or independently, the UE / dual-booting device (e.g., Figure 1 UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs," can initially perform registration of a first SUPI based on credentials in the first SIM in a first RAT / network. At a later point in time, the second SUPI and SIM may become available in the UE / dual bootstrap device / UDM / UDR, and the UE / dual bootstrap device can then, with the aid of a message indicating the availability of the second SUPI and SIM, instruct the core network (e.g., protected in the NAS context of the first SUPI / SIM). The core network can then assess whether the second SUPI and SIM are suitable for connectivity across multiple networks, and if so, instruct the UE / dual bootstrap device to perform network registration / master authentication with the second RAT / network using the second SUPI / SIM. Additionally or alternatively, a second network registration message may be sent directly by the UE / dual bootstrap device, including the second SUPI and information about existing connections, such that the core network can link the first SUPI and the second SUPI as part of a combined connectivity across multiple networks. Additionally or alternatively, when new subscription data (e.g., a second SUPI that can be used in connections on multiple networks) becomes available in the UDM / UDR, the core network may trigger a home network-triggered master authentication process with the aim of adding the second SUPI / SIM to the connection on multiple RAT / networks.

[0134] Section: Dual-booting - (re)establishment of a connection with the second network triggered by the first network.

[0135] In some cases, the UE / dual-booting device may already be connected to the first network, and either the UE / dual-booting device or the first network may determine that delivery of a given service (e.g., a communication service) requires the use of or support of the second network, for example, because the UE / dual-booting device has lost connectivity through the first network. In this situation: In another embodiment, which can be used in combination with other embodiments or independently, the first network may instruct the UE / dual boot device (e.g., Figure 1UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs," uses its second SIM 102 to connect to a second network. This instruction can be delivered via a configuration message or via a NAS message. Alternatively, the first network may contact the second network (or RAT, e.g., a satellite network) and request the second network (or RAT, e.g., a satellite network) to provide service to the UE / dual boot device. This can occur, for example, when the first network cannot reach the UE / dual boot device. The first network may determine the appropriate second network based on operator agreements or based on user subscriptions and / or locations and / or times associated with the first SIM 101 and the second SIM 102. The first network may need to obtain the user identity (e.g., SUPI) associated with the second SIM and share it with the second network so that the second network can search for / find the UE / dual boot device. The second network may contact the UE / dual boot device, for example, by sending a paging message, sending a configuration message (e.g., in a protected NAS message), and / or triggering a connection, for example, by performing home-triggered network authentication to indicate to the UE / dual boot device the need for a connection through both networks. When a connection is established through a second network, the first network can use the services of the second network (e.g., communication services, location services, sensing services, etc.) to maintain the delivery of the required services.

[0136] Summary: Negotiation of Bootstrap Roles in Dual-Booting, Multi-Path, and Multi-Network Systems In combination with or independently of other embodiments Figure 11 In another related embodiment, the first serving network 1101, the second network 1102, and the home PLMN 1103 negotiate which serving network is guiding the multipath connection. This may include referencing Figure 11 The following steps: 1) UE 1100 sends a request to its home PLMN 1103 and / or the first serving network 1101 to initiate a multipath connection on the first serving network / RAT 1101 and the second serving network / RAT 1102. This request may include information such as a QUIC or TCPLS session identifier, available radio access technologies, network capabilities, and UE policies. This step may be optional if the process is not triggered by the UE.

[0137] 2) The home PLMN 1103 and / or the first serving network 1101 assess UE requirements and / or UE requests and determine whether to allow or deny multipath connectivity for a given communication. This decision may be based on factors such as network load, quality of service, user subscriptions, and network policies / capabilities.

[0138] 3) If multipath connectivity is permitted, the home PLMN 1103 and / or the first serving network 1101 send a response to the UE 1100 containing information about the first serving network 1101 and the second serving network 1102. This response may also include an indication of which serving network is assigned a guiding role for the multipath connectivity. The guiding role may be determined by the home PLMN 1103, or delegated to one of the serving networks 1101 and 1102 based on their preferences and capabilities.

[0139] 4) UE 1100 uses information received from its home PLMN 1103 to establish communication connections with the first serving network 1101 and the second serving network 1102. The communication connection can be split between the two serving networks using QUIC multipath or TCPLS protocols. UE 1100 can also exchange URSP rules with the serving networks to coordinate service splitting and bootstrapping policies.

[0140] 5) A serving network with a guiding role can dynamically adjust the service split ratio and change the path of a multipath connection based on network conditions, user preferences, and URSP rules. The serving network can also communicate with another serving network and its home PLMN 1103 to report the status of multipath connections and its guiding role. If necessary, the serving network can also request or relinquish its guiding role from another serving network or its home PLMN 1103.

[0141] The above and following embodiments can be used to address session management enhancements to support dual-boot service bootstrapping for new services to 3GPP access networks and / or dual-boot service handover across two 3GPP access networks belonging to the same PLMN (HPLMN or VPLMN), or two different PLMNs, or PLMN and PNI-NPN, and may further include one or more of the following: - Whether enhancements are needed during PDU session establishment / modification / release, and if so, what enhancements are required; -Does N4 session management between SMF and UPF, or between SMF+PGW-C and UPF+PGW-U, require enhancement, and if so, what enhancements are needed? - For sessions affected by potential handover and / or service bootstrapping, whether, when, and how the network selects PSA UPF or UPF+PGW-U to allow services to be routed to the same PSA UPF or UPF+PGW-U across 3GPP access networks to support dual bootstrapping.

[0142] Summary: Dual-booting - Service decomposition in multipathing across multiple radio access technologies / networks Figure 2 A block diagram and communication paths are schematically shown through multiple networks and / or through different radio access technologies.

[0143] exist Figure 2 In the relevant embodiments shown, a communication connection exists, and this connection is split across two different core networks 109 and 114. This can be accomplished via QUIC (Fast UDP (User Datagram Protocol) Internet connection) over multipath, such as in QUIC multipath (https: / / datatracker.ietf.org / doc / html / draft-ietf-quic-multipath) or the TCPLS protocol (e.g., https: / / www.ietf.org / archive / id / draft-piraux- tcpls-03.html#name-tcpls-tls-extensions As specified in (), it allows QUIC / TCP connections to be split on different paths. Figure 2 Possible architectures are described, where 1 entity( (It can be a number from the set {0,1,2,3,4,5,6,7,8,9}) Figure 1 As stated in the text, and: The corresponding additional network functions 301 and 303 of the first core network 109 and the second core network 114 are responsible for session management, such as 5G SMF. In addition, another network function 302 of the first core network 109 is responsible for multipath management within the network, another network function 304 is responsible for multipath management at the data source (e.g., AF 119 or a path-splitting network), and an additional function 305 at the UE 100 is responsible for multipath management on the UE side. Two possible paths 306 and 307 may include the standard communication path 307 on the access device 106 (such as a 5G gNB) and may include a non-terrestrial network communication path 306 on a satellite, as... Figure 1 Another type of device 123.

[0144] Note that the above can also indicate a dual-connection setting, where the two paths 306 and 307 can be two dual-connection paths, one path passing through the ground access device and the other path passing through the non-ground access device.

[0145] In this scenario, a network that wishes to enable multipath (e.g., the first core network 109) can command a UE / dual boot device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") (or AF119) to establish a multipath communication connection, such as a QUIC multipath communication connection, for example, by means of NAS commands.

[0146] In this scenario, the UE / dual-booting device 100 (or AF 119) requiring a multipath communication connection can signal / indicate the need to establish a multipath connection to the first network (e.g., the first core network 109). The first network can then, for example, enable a new RAT (e.g., a non-terrestrial RAT) in the UE / dual-booting device 100, or the first network can indicate to the UE / dual-booting device 100 that a second network may be needed, or the first network can interact with the second network to initiate multipath communication, and then the second network can allocate / reserve resources for the upcoming communication.

[0147] The network (e.g., network function 302) can know the type of network and / or RAT to be used, enabling the network to inform the UE / dual-booting device 100 / AF 119 of those characteristics when requesting the initialization of multipath communication. For example, if the UE / dual-booting device 100 is connected via another type of device 123 (e.g., satellite), a first access device 107 (e.g., a gateway connected to the satellite), and a first core network 109 (e.g., a network managing the connection), and that connection is managed by network function 302, then the first core network 109 can know the services provided by other networks (e.g., a second core network 114 that can provide RAN including, for example, mobile base stations or UAVs). The (primary) first core network 109 (e.g., supplementary network function 302) can request the (secondary) second core network 114 to provide connectivity services. The (primary) first core network 109 can indicate / provide areas where supplementary (communication / sensing / location / ...) services are required. The secondary core 114 can provide information about when and where additional (communication / sensing / location / ...) services are available, for example, based on the mobility patterns of mobile access devices (such as gNBs installed on another type of device, e.g., UAVs, satellites, etc.). The primary core 109 (e.g., additional network function 302) can then configure / command the UE / dual-booting device 100 to connect to the secondary core 114 via the corresponding RAN / RAT. This may require configuring the UE / dual-booting device 100 to access the secondary core 114 with credentials. These could be long-term credentials stored in the (embedded) SIM, enabling the UE / dual-booting device 100 to perform (primary) authentication with the secondary core 114 and then begin using the secondary core 114. This could be key material (e.g., root key and / or authorization token) obtained by the primary first core network 109 / additional network function 302 after interaction with the secondary second core network 114, and configured in / shared with the primary first core network 109 in the UE 100, so that the UE / dual-booting device 100 can use the key material to securely connect to the access device of the secondary second core network 114, for example, after performing a random access procedure. For example, the UE 100 and the AN can use the root key to authenticate / establish a secure channel, and the UE 100 can subsequently share its authorization token with the RAN (e.g., RAN 106) of the secondary second core network 114.

[0148] Then, the additional function 305 in the UE / dual bootstrapping device 100 can trigger a multipath communication protocol (e.g., as described in Section 3 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC"), thereby allowing the sharing of network / RAT types and characteristics for better configuration of different paths. For example, the additional network function 302 of the first core network 109 can collect information about feasible service attributes (QoS, maximum data rate, positioning accuracy, sensing accuracy, etc.) from the secondary core network 114 (on request or as needed) and use them to determine the configuration parameters of the additional function 305 of the UE / dual bootstrapping device 100, so that the additional function 305 can use these parameters when establishing multipath services. The additional network function 302 of the first core network 109 can also consider the collected service attributes to indicate that the secondary core network 114 has its specific requirements.

[0149] In related embodiment variations, AF 119 or the server can indicate the number of required paths to the (main) network (e.g., first core network 109). For example, in the case of QUIC, the limit is reached if the transport parameter "active_connection_id_limit" is negotiated to N, and the server provides N connection IDs, and the client has actively used N paths. The server (e.g., AF 119) can share N with the (main) network. Otherwise, the main network can monitor the protocol negotiation to determine the number of required paths.

[0150] Related implementation variations address scenarios requiring the discovery and management of addresses serving multipath connections. For example, in Quic multipathing, each end host can use several IP addresses to serve connections. Specifically, multipath extensions support the following scenarios: The client uses multiple IP addresses, while the server listens on only one IP address.

[0151] The client uses only one IP address, while the server listens on several IP addresses.

[0152] The client uses multiple IP addresses, and the server listens on several IP addresses.

[0153] To address this issue, a variant of the related embodiment assumes that the network function 302 responsible for multipathing in the primary first core network 109 can interact with the secondary second core network 114, the additional function 304 (which may be a terminal host) managing multipath connections in the AF 119, and the additional function 305 managing multipath connections in the UE / dual boot device 100 to collect and configure addresses for a given multipath connection. For example, it may need to have IP addresses assigned by the secondary network (e.g., upon request from the first network). The secondary network can notify the primary network of these IP addresses. The primary network can then make them available to the additional function 304 at the AF 119 and / or the additional function 305 at the UE / dual boot device 100.

[0154] In related embodiment variations, the network function 302 responsible for multipathing, located in the primary first core network 109, can monitor the type / state of paths and provide configuration parameters suitable for them. According to multipathing protocols such as QUIC, two main parameters can be considered when processing path communication, round-trip time (RTT), and congestion status (see Section 7.1 of draft-ietf-quic-multipath-06 “Multipath Extension for QUIC”). When instructing the UE / dual-booting device 100 and / or AF 119 to establish multipath communication, the additional network function 302 can be aware of the current state. In other words, the additional network function 302 can send parameters that allow optimization of path communication during path initialization or operation. These communication parameters can be multiple, such as RTT, congestion status, congestion window size, etc.

[0155] In a related embodiment variant, the additional network function 302 responsible for multipathing in the primary first core network 109 can instruct / configure certain parameters to the additional function 305 of the UE / dual boot device 100 and the additional function 304 of the AF 119, which will be calculated to optimize the performance of end-to-end communication on the cellular network. For example, the additional network function 302 can instruct that the RTT can be calculated in a specific way (related to section 7.3 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC"), for example, that acknowledgments can always be sent via the shortest path, for example, using timestamps.

[0156] In a variant of the relevant embodiment, the additional network function 302 responsible for multipathing in the primary first core network 109 can indicate / configure to the additional function 305 of the UE / dual boot device 100 and the additional function 304 of the AF 119 the type of packet scheduler to be used for a given path (e.g., related to section 7.4 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC"), the preferred retransmission strategy for different paths (e.g., related to section 7.5 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC"), the path maximum transmission unit (MTU) to be used in different paths (e.g., related to section 7.6 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC"), and the preferred strategy for maintaining activity in different paths (e.g., related to section 7.6 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC"). (Related to Section 7.7 of "QUIC"), connection parameters (e.g., connection ID, etc.).

[0157] In a variant of the relevant embodiment, an additional network function 302 responsible for multipathing, located in the primary first core network 109, can monitor the status of the paths. For example, the additional network function 302 can know that one of the paths is based on a satellite (e.g., a LEO satellite) and can know the reachability status of said satellite. Figure 1 The satellite can be other types of equipment 123. Since the additional network function 302, as a management entity, knows / tracks the connectivity of available paths, it can also interact with the additional function 305 of the UE / dual-boot device 100 and / or the additional function of the AF 119 to stop the process of closing one of the paths (e.g., section 4.3 of draft-ietf-quic-multipath-06 "Multipath Extension for QUIC").

[0158] In a related embodiment variant, an additional network function 302 responsible for multipathing, located in the primary first core network 109, can periodically / continuously evaluate path quality (e.g., round-trip time, congestion status) and manage path changes / reselections based on path quality and / or the services provided (e.g., positioning, sensing, etc.). For example, the additional network function 302 may know that one of the paths utilizes satellites (e.g., LEO). Based on the location, path, and speed of the satellites (e.g., other types of devices 123) and the location, path, and speed of the served UE 100, the additional network function 302 can estimate the time window when the satellite link / path provides optimal service (e.g., when the satellite is above the local horizon of the UE 100), and thus estimate the point at which the link may begin to degrade. Based on this, the additional network function 302 can program path changes / reselections and instruct the UE / dual-booting device 100 to change paths accordingly. The primary first core network 109 can share context and key materials (e.g., encryption keys, authorization tokens) with entities involved in the new path to optimize link establishment.

[0159] The above embodiments are also applicable to UE / dual boot devices (e.g., UE 100, which may include a first SIM and a second SIM operable by two "logical UEs") that can first utilize a first protocol stack (e.g., Figure 18 For example, in a system that establishes a PDU session based on Section 4.3.2.2.1 of TS 23.502, and if the PDU session is successfully established and the core network indicates that connections over multiple networks / RATs are permitted, then a second protocol stack (such as...) can be established. Figure 18The second PDU session (in the first protocol stack) is established. Once established, the UE / dual-booting device can use the PDU session to communicate through two RATs / networks. Before establishing the dual PDU session, the UE / dual-booting device needs to register with both RATs / networks. This combined PDU session can be identified by the SUPI / SIM used for connection on the two RATs / networks. The first step of establishing the first PDU session using the first protocol stack can include the fact that this is a request to establish a communication link (PDU session) through the first RAT / network, and it can include other information such as PDU session ID, DNN, and S-NSSAI. The request type can be a "dual-booting PDU request," that is, a request to establish a communication link through multiple networks / RATs. The steps of establishing the second PDU session using the second protocol stack can include the fact that this is a request to establish a communication link (PDU session) through the second RAT / network, and it can include other information such as the associated communication link (first PDU session), PDU session ID, DNN, and S-NSSAI. The request type can be a "dual-boot PDU request," which is a request to establish a communication link through multiple networks / RATs. Sending these requests can be triggered by policies on the device (e.g., URSP rules).

[0160] Summary: Dual Booting - Impact on AKMA when executed on two networks In relevant embodiments, a UE / dual boot device (e.g., UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs") may select (e.g., based on configuration) to perform a given procedure, such as AKMA, based on credentials from one or more SIMs. For example, in the case of AKMA, this is based on the current security context (e.g., K_AUSF, K_AKMA) established with one or each of the networks (e.g., first core network 109 and second core network 114).

[0161] In relevant implementation examples, the UE / dual boot device (e.g., UE 100 / dual boot device, which may include a first SIM and a second SIM that can be operated by two "logical UEs") may include indications to the NF (e.g., AF 119) and / or the first core network 109 and the second core network 114 regarding credentials used in the desired service (e.g., AKMA service). The UE / dual boot device 100 may also indicate whether the desired service should be performed in a multipath manner (e.g., on two different networks).

[0162] In relevant embodiments related to AKMA (see TS 33.535), if AKMA is used on two different networks (e.g., first core network 109 and second core network 114), it is necessary to agree on which key will be used as K_AKMA (K_AKMA_a from first core network 109 or K_AKMA_b from second core network 114), and which K_AF needs to be shared with which network. This can be accomplished through a policy. This can also be indicated in the initial AKMA message sent by the UE / dual boot device 100 to AF 119. Note that different K_AKMA keys are derived because each SIM has its own set of credentials (SUPI, K_AUSF, etc.), making it possible to derive different keys.

[0163] In relevant embodiments 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 Restricted RESTful Environments (OSCORE)), and the secure connection is split across two different networks (e.g., first core network 109 and second core network 114). The UE / dual-boot device 100 and AF 119 can be configured to initiate multipath communication only once an AKMA session has been established. For example, the initial handshake for establishing a secure connection (e.g., a TLS handshake) can run on the first network, and then connections can be established on multiple paths. This can also be achieved via multipath QUIC, using the TCPLS protocol, in the case of TLS or where AKMA supports QUIC. Note that this means using the security context established on the first network / path to protect information exchanged on the second network / path.

[0164] In the relevant scenario, it is considered that two networks (paths) (e.g., first core network 109 and second core network 114) may need to meet legitimate interception requirements. The challenge in this setup is the fact that a portion of the communication occurs through the first core network 109, and another portion occurs through the second core network 114, such that even if each individual network can access the exchanged information (once AF 119 provides the corresponding key), a single network may not be able to access all the information on its own. Therefore, in a relevant embodiment variant, the first core network 109 and the second core network 114 may negotiate / verify whether they both have access to secure information (encryption keys, security algorithms in use, counters, etc.) before allowing the exchange of information. This may require, for example: (i) Additional network function 302 manages overall connectivity in the first core network 109 to obtain acknowledgments from another network (e.g., additional network function 303 of the second core network 114) that it will cache communications, and to share communications as needed, such as with additional network function 302 of the first core network 109 or directly with a legitimate intercepting entity. (ii) Two potential legitimate intercepting entities in the first core network 109 and the second core network 114 are indicated by communication parameters of multipath communication (e.g., QUIC connection ID).

[0165] Furthermore, if a legitimate intercepting entity requires it, the first core network 109 and the second core network 114 may need to verify their right to disclose information.

[0166] In related implementation variations of AKMA, the same credentials can be used to establish two independent secure connections on two networks, and the data can be combined at the UE / AF. For example, the same K_AF (e.g., associated with the first core network 109) is used to authenticate the two secure connections. The K_AF can be as defined in TS 33.535, or it can be made to depend on the serving network; that is, the K_AF used to establish a secure connection can still depend on whether the network is the first core network 109 or the second core network 114. This can be achieved by using a network identifier as input in the K_AF derivation.

[0167] Alternatively, two secure connections can be established based on credentials from both the first core network 109 and the second core network 114, and data can be combined at the UE / dual boot device 100 and / or AF 119.

[0168] In an exemplary embodiment variant related to AKMA, the UE / dual bootstrapping device 100 may optionally use K_AKMA_1 derived from K_AUSF_1 in PLMN1 associated with the first SIM 101 and the first core network 109. The UE / dual bootstrapping device 100 can then derive K_AF1, as in TS 33.535, based on K_AKMA_1 in PLMN1. However, for PLMN2, if the network (resources) will be used for the same AKMA connection, AF 119 and / or the UE / dual bootstrapping device 100 and / or PLMN1 may need to notify PLMN2 that K_AF1 is used to protect AKMA communication, and that AKMA communication is requested / required / allowed by PLMN2.

[0169] In another embodiment variant related to AKMA that can be used in combination with other embodiments or independently, the UE / dual-booting device (e.g., UE 100 that can include a first SIM and a second SIM that can be operated by two "logical UEs") can have a policy that determines that AKMA can only be performed based on the key of a single SIM, and AKMA-related messages can be exchanged over a single network, so that multipath communication is not applied.

[0170] Summary: Cross-stack optimization in dual-boot multi-stack devices A dual-boot device, as currently defined in TS 22.841, comprises two logical "UEs" that allow simultaneous data transmission over two networks or RATs, or a single UE in cases of non-simultaneous data transmission over two networks. In the context of this invention, a single UE may also be used in cases of simultaneous data transmission over two networks or RATs. The SIM contains the user's credentials, including the user's identity (e.g., a Subscription Persistent Identifier (SUPI)) or other keys used to perform master authentication according to TS 31.102. The SIMs of the UEs may belong to the same core network or two different core networks.

[0171] Figure 18 The architecture is illustrated, where 1800 refers to a dual-boot device (also referred to as a UE in this specification, for example, with...). Figure 1 The UE 100 is the same as / similar to UE 100, which may include a first SIM and a second SIM that can be operated by two "logical UEs". 1804 and 1805 refer to two protocol stacks that can exist in two logical UEs (e.g., based on 3GPP version 18 or 19). For example, in one option, the user plane protocol stack may include the PHY / MAC / RLC / PDCP / SDAP layer. For example, in another option, the user plane protocol stack may include the PHY / MAC / RLC / PDCP / SDAP / IP / UDP layer. For example, the control plane protocol stack may include the PHY / MAC / RLC / PDCP / RRC / NAS-MM / NAS-SM. 1806 represents a dual-boot control function module responsible for managing the operation of the protocol stacks. 1807 represents optional multipath logic below the application layer or IP layer, i.e., the layer responsible for enabling multipath communication layers on both protocol stacks. 1803 represents a USIM management module that manages at least two SIMs 1801 and 1802. SIMs may include the required credentials (keys, counters, user identities, etc.). The first protocol stack 1804 and the second protocol stack 1805 can communicate directly with each other via communication links (e.g., API and / or hardware communication links).

[0172] In embodiments that can be used in combination with other embodiments or independently, the UE / dual boot device 1800 may have a connection supported by two SIMs, whereby such a connection may include a joint PDU session operated by both SIMs (e.g., having the same PDU session ID or another shared identifier) ​​or a set of PDU sessions operated by either SIM (but part of the same logical connection, e.g., having the same IP address and / or anchored in the same UPF). The UE / dual boot device 1800 may have policies or configurations and logic to ensure that certain processes in the two stacks are executed in a coordinated manner.

[0173] In an embodiment, the logic can determine that the switching processes for the dual-boot data connection do not occur simultaneously, but rather one after the other. This can be managed by a dual-boot control function, which manages, for example... Figure 18 The behavior of the communication stack available in the UE / dual-boot device 1800 of 1806. In other words, a handover occurs first with the first protocol stack (using SIM1), followed by a handover with the second protocol stack (using SIM2). This embodiment improves the implemented QoS because the two handovers do not occur simultaneously. For example, the first protocol stack may be connected to a terrestrial network, and the second protocol stack may be connected to a non-terrestrial network. This embodiment achieves this through... Figure 17As shown, UE 1700 (same / similar to UE / dual-booting device 1800) includes SIM 1701 and SIM 1702, RAN 106 includes a first access device 1707 and a second access device 1708, and core network 1709 includes network functions UPF 1710, SMF 1711, and AUSF 1712. In steps 1713 and 1714, UE 1700 performs random access to connect to RAN 106, i.e., the first access device 1707. This is done for both SIM 1701 and SIM 1702 in steps 1713 and 1714. Next, UE 1700 registers with network 1709 and performs primary authentication. This is done for both SIM 1701 and SIM 1702 in steps 1715 and 1716. Then, in step 1717, UE 1700 may establish a connection with UPF 1710, for example, based on a multipath link or other means. At a later point in time, when UE 1700 is moving and / or needs to connect to the second access device 1708, UE 1700 applies a strategy to perform the handover from the first access device 1707 to the second access device 1708 in a sequential manner. For example, first, the communication link associated with the first SIM 1701 is moved from 1707 to 1708, and then, when the handover is complete, the communication link associated with the second SIM 1702 is moved from 1707 to 1708. This strategy determines that if UE 1700 has already established a connection on both SIMs, the handover process may not be performed simultaneously, either wholly or partially.

[0174] During a handover process, the dual-boot control function module 1806 can obtain indications from protocol stacks 1804 and 1805 regarding the timing of potential handovers or certain steps requiring a handover. For example, if protocol stack 1804 is configured to perform conditional handovers, it can utilize the dual-boot control function module to check whether it is permitted to perform a conditional handover. Dual booting can, for example, allow handover only if the other protocol stack 1805 does not have concurrent handovers, at least unless protocol stack 1804 is in a critical situation requiring a handover, in which case the connection will be completely lost.

[0175] The dual-guided control function 1806 can also be used to exchange certain measurements or optimize other operations, for example: In combination with or independently of other embodiments Figure 17 and Figure 18 In related embodiments, Figure 17Steps 1713 and 1714 in the process shown and described above can be combined into a single random access procedure, where UE 1700 is assigned a RAN identity (e.g., RNTI), one RAN identity per protocol stack (using SIMs 1701 and 1702). This can be accomplished if UE 1700 indicates in one of the random access messages (e.g., message 1) that it supports two SIMs (e.g., it is a dual-booting device), causing two RAN identities to be assigned. In this case, a request is made for the first protocol stack to perform the random access procedure on behalf of the second protocol stack. This request can be determined by the dual-booting control function 1806. When the first protocol stack has received two RAN identities, the stack provides the RAN identity to the other protocol stack (e.g., via communication link 1813 or indirectly via the dual-booting control function 1806). This decision to perform the combined random access procedure can be taken by the dual-booting control function, for example, when it determines that the same RAN is being used.

[0176] In combination with or independently of other embodiments Figure 18 In a related embodiment, the dual-boot control function 1806 can collect information about the quality of the communication link (e.g., available bandwidth of the path, QoS, link quality, round-trip time, etc.). The dual-boot control function may then interfere with multipath logic that can use this information, for example, to configure MPQUIC. The dual-boot control function 1806 can also determine in other ways how to split / allocate application services between the two protocol stacks to achieve communication objectives.

[0177] In combination with or independently of other embodiments Figure 18 In a related implementation, the dual-boot control function 1806 can bootstrap the first protocol stack 1804 to perform certain measurements, such as measurements related to pilot signals like SSB, SIB, PRS, etc. This information can then be exchanged directly or via the dual-boot function between the protocol stacks (1804, 1805) (e.g., between physical layers). This allows for reduced power consumption of the dual-boot device.

[0178] In combination with or independently of other embodiments Figure 18 In a related embodiment, the first protocol stack 1804 may be responsible for acquiring certain data or pilot signals, such as SSB, SIB1, and System Information (SIB), on demand. This information can then be exchanged directly or via dual-boot control between protocol stacks (1804, 1805) (e.g., between physical layers). This allows for reduced power consumption and lower signaling requirements of the dual-boot device.

[0179] In combination with or independently of other embodiments Figure 18In a relevant embodiment, the first protocol stack 1804 may be responsible for exchanging control commands (e.g., DCI / UCI). In this case, the second protocol stack 1805 may determine / indicate the communication requirements for the first protocol stack directly or through a dual-boot control function, and then the first protocol stack may exchange the control commands with the RAN (Access RAN). Specifically, DCI / UCI commands may be used to perform resource allocation to allocate communication resources, for example, for downlink and uplink communication links. This has advantages such as better synchronization of uplink and / or downlink communication links, for example, to achieve lower latency and / or higher reliability.

[0180] In combination with or independently of other embodiments Figure 18 In a related embodiment, the dual-boot control function 1806 can be responsible for distributing the same data through two communication stacks (1804, 1805) to increase communication reliability.

[0181] In combination with or independently of other embodiments Figure 18 In a related embodiment, the first protocol stack 1804 can monitor paging messages from the second protocol stack 1805. This function has the advantages of reducing network traffic and energy consumption.

[0182] In combination with or independently of other embodiments Figure 18 In related embodiments, the first protocol stack 1804 and the second protocol stack 1805 have / share a common wake-up radio unit that can be configured to wake up the first and / or second protocol stacks. This feature has the advantage of reducing the power consumption of dual-boot devices.

[0183] Besides 3GPP, other standardization bodies can introduce wireless devices with multiple protocol stacks. For example, WiFi-7 / IEEE 802.11 introduced the use of multi-link capable devices that can simultaneously use 2.4 GHz, 5 GHz, and 6 GHz protocol stacks. Therefore, similar cross-stack optimizations can also be applied, where, for example, scheduling / signaling for the 5 GHz stack is performed via the 2.4 GHz stack.

[0184] In combination with or independently of other embodiments Figure 18In a related embodiment, the dual-booting control function 1806 can request and / or obtain information from both the first and second protocol stacks (1804, 1805) regarding which networks are detected (e.g., cell ID, network identifier, 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 based on the SIM profile operated by the respective protocol stacks. Using this information, it provides instructions to the first and / or second protocol stacks, selecting which network / slice to register with, or which one or more preferred networks to register with, and / or determining whether to maintain or terminate the dual-booting connection between the first and / or second protocol stacks and a specific network. This function has the advantage of enabling the dual-booting control function to select or provide the most suitable network for the dual-booting connection from the available networks detected / measured / preferred by the two protocol stacks, assuming that the two protocol stacks can operate / configure differently (e.g., based on their respective SIM profiles). Additionally or alternatively, the dual-booting control function forwards and / or provides a subset or summary of relevant measurements and / or relevant information between the first and second protocol stacks and / or between the second and first protocol stacks, so that the respective protocol stacks can use this information to select which network to register to. After one of the protocol stacks has selected and registered to the first network, the dual-booting control function can continue to request, obtain, forward, or provide relevant measurements and / or relevant information from one protocol stack to the other protocol stack, so that the dual-booting control function and / or the other protocol stack can make an informed decision on which network to register to. Additionally or alternatively, it allows the protocol stack already registered to the first network to share measurements and / or information from the other protocol stack or a subset / summary thereof with a network function, which can use this information to perform the selection of a (preferred) network and / or create a list of (preferred) networks for the second branch, i.e., as information to be used by the other protocol stack to select the second network to register to. For this purpose, the network can provide this information about the network selection of (preferred) networks and / or the list of (preferred) networks via an existing communication session established through the first protocol stack. The first protocol stack can provide this information directly to the second protocol stack via a communication link (not shown in the figure), or to the dual boot control function 1806. The dual boot control function 1806 can then use this information to instruct the second protocol stack and / or provide / forward information to the second protocol stack about which (preferred) network the first network has selected.Additionally or alternatively, the first protocol stack may directly provide the second protocol stack or the dual bootstrap control function 1806 with information (e.g., the slice used) and / or measurements (e.g., latency, bandwidth, frequency band, QoS) about its connection to the first network via a communication link. The dual bootstrap control function 1806 may then use this information to instruct the second protocol stack and / or provide / forward information to the second protocol stack, such as information about which network the second protocol stack should select.

[0185] Additionally or alternatively, the first protocol stack may, for example, indirectly or directly via a communication link, request and / or obtain information about detected networks / measurements from the second protocol stack. A network may refer to one or more of a combination of radio access technologies, PLMNs, network operators, etc. This function has the advantage of enabling the first protocol stack to select or provide the most suitable network among available networks for dual-booting connections detected and / or measured by the second protocol stack. For example, the first protocol stack may request information about network identifiers, cell IDs, network types, signal strength, latency, bandwidth, frequency bands, or quality of service for network slices detected and / or available / permitted by the second protocol stack. Based on this information, the first protocol stack can decide whether to initiate, maintain, or terminate a dual-booting connection with a specific network. Additionally or alternatively, the first protocol stack may share this information with a network function that can use it to perform the selection of a (preferred) network and / or create a list of (preferred) networks for a second tributary, i.e., as information to be used by another protocol stack to select a second network to register. The network function may then provide this information about the network selection of (preferred) networks and / or the list of (preferred) networks to the first protocol stack via an existing communication session established through the first protocol stack. The first protocol stack may provide this information directly to the second protocol stack or to a dual-boot control function, which in turn may use this information to instruct the second protocol stack and / or provide / forward information to the second protocol stack about which (preferred) network the first network has selected.

[0186] Additionally or alternatively, as part of an RRC or NAS message (e.g., via an existing communication session established with the first primary network through the first protocol stack), the AMF or RAN may send a request to the UE / dual-booting device 1800 to provide a list of discovered networks (e.g., cell IDs and / or PLMNIDs of networks from which the UE / dual-booting device 1800 receives SIB information) and / or to provide information about which networks in the secondary network list (which may be provided to the UE / dual-booting device 1800 by the AMF or RAN) are available to the UE / dual-booting device 1800 (e.g., can be discovered by the UE / dual-booting device 1800), possibly along with measurement information of the discovered networks (e.g., signal quality, signal strength), and / or to provide location information of the UE / dual-booting device 1800 (e.g., GNSS location). The UE / dual-booting device 1800 can respond to such a request by sending an RRC or NAS message containing one or more of the requested information (e.g., using the process described above, such as obtaining information about the discovered network and / or measurements related to the discovered network from the second protocol stack by the first protocol stack). Based on the information provided by the UE / dual-booting device 1800, the network (e.g., RAN, AMF, or NF / AF used to determine the Strring-of-Roaming information to be provided / updated to the UE / dual-booting device 1800) can determine (preferably) a subset of the secondary network list and / or select (preferably) secondary networks that the UE / dual-booting device 1800 needs to register from the candidate secondary network list, and / or determine additional networks to be added to the secondary network list, and based on this determination, send an updated list of candidate networks (possibly including rules / conditions for accessing them) to the UE / dual-booting device 1800 in a response (e.g., a second message or another intermediate message). Based on the response received from the network, the UE / dual-booting device 1800 can determine whether to perform secondary registration and / or can determine which second network to use / search for to perform secondary registration. Additionally or alternatively, a network function that receives information related to which networks the UE / dual-booting device 1800 has discovered and / or measurements related to the discovered networks can forward that information or a summary / subset thereof and / or provide a determined subset of the (preferred) list of secondary networks and / or the selected (preferred) secondary network to one or more of the discovered networks (e.g., communicating with the AMF of the discovered network via the AMF of the first network, or communicating with the NF of the second network via the NEF or SBI of the first network).Additionally or alternatively, the network functions (e.g., AMF) of the first network to which the UE / dual-booting device 1800 registers can provide one or more other networks with information about the UE / dual-booting device 1800 (e.g., a set of identifiers associated with the UE (e.g., a list of one or more SUPI subscriptions of the UE), PDU session IDs or associated IDs used by the UE / dual-booting device 1800 to communicate with the first network (e.g., identifiers indicating / associating multiple PDU sessions from the UE / dual-booting device 1800 through the first and / or second networks), a set of network slices that the UE / dual-booting device 1800 is using or is allowed or not allowed for secondary registration, a list of the capabilities of the UE / dual-booting device 1800 (e.g., indicating support for dual registration and / or service splitting / handover / booting on two networks), a list of supported frequency bands, and a list of services that the UE / dual-booting device 1800 can use on the primary connection and / or secondary connection, such as registering one or more networks for dual connection / dual registration (e.g., secondary networks linked to the UE's first and / or second subscription data in the UDM). The second network (or UE / dual-booting device 1800) has provided information about one or more networks that have been discovered by the UE / dual-booting device 1800. This enables the discovered networks to prepare incoming connections from the UE / dual-booting device 1800 for secondary registration. For example, based on information received from the first network, the second network may add / remove one or more slices to / from the list of allowed slices for the UE / dual-booting device 1800, update RAN policies, reserve / schedule resources for the UE / dual-booting device 1800, perform beamforming of one or more cells toward the location of the UE / dual-booting device 1800, and send (e.g., via broadcast (updated) SIBs) information that can be received by the second protocol stack, such as information about the UE / dual-booting device 1800's registration with the first network (e.g., the network ID of the first network) or information about one or more candidate second networks to which the UE / dual-booting device 1800 wants to register.

[0187] In combination with or independently of other embodiments Figure 18In a related embodiment, the first protocol stack 1804 of the UE / dual-booting device 1800 can receive message / configuration / RRC messages (e.g., MAC IE) that can be applied to both the first and second protocol stacks (1804, 1805). Upon reception, the first protocol stack 1804 can share information with the second protocol stack 1805. The RAN can know that the device is a dual-booting device, and therefore, it can be configured to share / transmit the message / configuration only with the first or second protocol stack, or both. Sending it only to a single protocol stack can allow for optimized communication / energy saving. For example, the message may refer to the timing / configuration of an on-demand SSB distributed by the cell, and this message / configuration can be sent only to the first protocol stack, and the first protocol stack can share the message / configuration with the second protocol stack. This may require informing the radio access network (RAN) (e.g., the cell) of the fact that the device is a dual-booting device comprising two protocol stacks, and whether these protocol stacks are configured / adapted to share / transmit certain measurements internally, so that the RAN and / or UE can optimize communication overhead and energy consumption of the RAN and UE / dual-booting device. The UE / dual-booting device (e.g., 1800) and / or protocol stack (e.g., 1804 or 1805) may, for example, inform the RAN and / or CN of their configuration in the UE capabilities, allowing the RAN and / or CN to adjust their behavior. Additionally or alternatively, the RAN and / or CN may configure the UE / dual-booting device with specific configurations.

[0188] Section: Dual Guidance - Roaming Guidance Information In embodiments (SoR_DS) that can be used in combination with other embodiments or independently, the dual-booting device (e.g., 1800, 1700, 100) may be pre-configured (e.g., stored as part of the (e)SIM profile) with and / or able to receive (updates thereto) Steering-of-Roaming information from the network, as specified in 3GPP TS 23.122. To implement dual-booting functionality, the SoR information (e.g., pre-configured at the dual-booting device or provided by the network, such as by a Steering-of-Roaming application function) may include a set of network combinations (e.g., tuples including (primary network identifier, secondary network identifier) ​​allowed by the dual-booting device). After successfully registering with the first (i.e., primary) network, the dual-booting device may use the information to initiate secondary registration with the second network, thereby selecting the second (i.e., secondary) network based on whether the SoR information contains a valid combination of the second and first networks. SoR information may contain one or more conditions for selecting secondary networks and / or allowing (typically or to a specific secondary network) secondary registration, whereby such conditions may be associated with a list of secondary networks, a list of compatible networks, or a network combination (e.g., a set from a network combination, such as a tuple consisting of (primary network identifier, secondary network identifier)). Examples of such conditions may include: location-related conditions (e.g., valid only in certain tracking areas, geographic areas), signal quality-related conditions (e.g., registration to a network (or combination of networks) is allowed only if the signal strength of (one or more networks) is above a certain threshold), QoS-related conditions (e.g., registration to a secondary network is allowed if certain QoS parameters / values ​​(e.g., 5QI value, continuous data rate, or certain maximum error rate) are required for a PDU session), time-related conditions (e.g., valid only during certain time periods), availability conditions (e.g., some networks are available / forbidden or not available / forbidden), emergency situations (e.g., establishing a PDU session through multiple networks if dual-booting devices are involved and / or emergency communications need to be established), etc.

[0189] Section: Multiple Network / RAT and PC5 Interfaces 3GPP specification TR 22.841 states that a UE can exchange data across different networks / RATs. The specific case of interest refers to a UE that can receive data from two networks and / or is registered to two networks, where one of the communication interfaces / RATs is a PC5 interface. This could be, for example... Figure 1 The second UE 103 is connected to the first UE 100 via PC5 link 120 and to RAN 106 via Uu link 122. In this case, PC5 link 120 can be served by the first network and Uu link 122 can be served by the second network.

[0190] A use case for this scenario is: a second UE 103 is connected to a first UE 100 via PC5 link 120, and may have a temporary connection to RAN 106 via Uu link 122, for example, RAN 106 could be a UAV or mobile gNB. Establishing a connection via Uu link 122 may be beneficial if the second UE 103 needs to exchange more data (e.g., software updates). This large-scale exchange might take a long time on PC5 link 120, but it can be done more efficiently on Uu link 122 when RAN 106 is available.

[0191] This can be compared with Figure 2 Similar implementations are used in related embodiments, whereby the first UE 100 can typically be connected via Uu link 120. The network functions of entities in the primary first core network 109 (e.g., Figure 2 The additional network function 302) is aware that the access equipment of the secondary core network 114 may soon be available. Subsequently, the primary first core network 109 can instruct the UE 100 to access the access equipment of the secondary second core network 114. This may require network functions in the primary first core network 109 (e.g., Figure 2 Additional network function 302) Subscribe to or receive information about access devices managed by the secondary core network 114 at a given location and / or time.

[0192] Summary: Multipath communication based on ATSSS (Access Service Bootstrapping, Switching, and Splitting) Figure 3 A block diagram and communication paths are schematically shown through multiple networks and / or through different radio access technologies.

[0193] These processes can be based on the architectural reference model for ATSSS support described in section 4.2.10 of TS 23.501 V18.2.1. Specifically, Figure 3 Indicates and Figure 2 Compared to a slightly different path view. Figure 3 In this process, data is exchanged via two paths, 306 and 307. The first path, 306, passes through a first core network 109, such as PLMN1 or HPLMN, while the second path, 307, passes through a second core network 114, such as PLMN2 or NPN such as SNPN. However, in Figure 3 In this context, services are split within the first core network 109, for example, in the home UPF (similar to TS 23.501). Figure 4.2.10-3), wherein the home UPF uses the N3 interface to forward / exchange data with the 3GPP access (e.g., the first access device 107), and the home UPF uses an interface (e.g., an N9-based interface) to exchange data with the UPF of the second core network 114. In this case, the home UPF implements the functionality in TS 23.501. Figure 4 2.10-1 to Figure 3 Similar to the UPF in the original text, namely MPTCP proxy function, MPQUIC proxy function, ATSSS-LL function, and PMF (performance measurement function). Although related to some extent, several issues need to be further addressed, including how to control the functional blocks in two different (core) networks.

[0194] In an embodiment, the SMF in the home network can use the N4 interface to control both the home UPF and the UPF in the second core network 114. Additionally or alternatively, the SMF in the home network can interact with the SMF in the second core network 114 (e.g., via the N16 interface) to determine how to bootstrap the UPF in the second core network 114. This requires extension to: (i) Notifying the network / agreeing between networks to: the fact that a given connection in a UPF of another network is controlled by the home SMF; and / or (ii) Notification to the network / agreement between networks: the fact that the home SMF controls certain communication sessions in another network's SMF.

[0195] In the embodiment (DS_identifier), UE 100 may first establish a data connection via the first core network 109 (i.e., the first path 306). UE 100 may already be connected to, or may later connect to, the second core network 114. When UE 100 registers via two different 3GPP networks, UE 100 may request a Multiple Access PDU (MA-PDU) session (section 5.32.1 in Extended TS 23.501). This request may include a unique identifier generated by UE 100 (e.g., a long identifier generated randomly) such that both networks can recognize the common MA-PDU. The identifier may also be generated by one of the networks and forwarded by UE 100 to the other network. This request may also be combined with / included with / reuse tokens described in other embodiments as described in other embodiments, and used by the network to verify that UE 100 is connected to both networks, such that the MA-PDU session is established only if the verification is performed by both networks. It should be noted that the identifier may be a parameter or identifier used in the data connection, such as a PDU session ID.

[0196] In one embodiment, the first core network 109, the second core network 114, and the UE 100 can participate in the authentication / negotiation process described in the above embodiments to check / agree on the multipath setup and dual-boot setup on the two networks, wherein the first core network 109 can be used as the primary / master network (since the initial communication path is established through it), and the second core network 114 can be used as the secondary / slave network. The home UPF can then initiate the creation of a new (secondary) path 307 from the home UPF to the UPF of the first core network 114 (e.g., the N9 interface) via the (secondary) second core network 114, wherein the UPF of the second core network 114 can then communicate with the second (3GPP) access device 108 using the N3 interface. Alternatively, the home UPF can then initiate the creation of a new (secondary) path 307 from the home UPF to the second (3GPP) access device 108 of the second core network 114.

[0197] Summary: Dual-Guidance - Legitimate Interception In the legitimate interception use case, both the primary core network 109 and the secondary core network 114 can be responsible for legitimate interception. The primary primary core network 109 can access all information, but the secondary core network 114 can not access all information (because it only exchanges a portion of the data). To address these requirements, one or more of the following methods can be applied: (i) The secondary core network 114 may instruct the legitimate interception authority that the primary core network 109 is responsible for data collection for legitimate interception. It may do so before agreeing to data exchange. Once the secondary core network 114 receives confirmation of legitimate interception support (e.g., from the legitimate interception authority or the primary network), the secondary core network 114 may agree to perform multipath tasks only.

[0198] (ii) The secondary core network 114 may request a “copy” of all data exchanged through the first communication path 306 from the primary first core network 109, enabling the secondary second core network 114 to provide this information to legitimate intercepting entities upon request. This may be particularly applicable in situations where the primary and secondary networks are in different countries, and therefore different legitimate intercepting agencies may need access to the exchanged data.

[0199] (iii) If the security of the data exchanged via the first path 306 and the second path 307 depends on key materials, security information, and cipher suites established / stored in the primary first core network 109, then the secondary second core network 114 may request the primary first core network 109 to receive these key materials, security information, and cipher suites, so that the secondary second core network 114 can provide this information to a legitimate intercepting entity when needed. This exchange / supply of security parameters may be required before communication occurs, so that communication exchange on the secondary second core network 114 only occurs if the secondary second core network 114 possesses the security parameters.

[0200] Summary: Dual-booting - Adaptation to communication parameters In one aspect of the invention, the secondary core network 114 and the primary first core network 109 may wish to adapt the parameters of the communication path. To this end, the primary and secondary networks may (request) exchange parameters (also referred to as rules, configurations, or policies), including: - Required / Available / Configurable data rate - Latency requirements (requirements / availability / configuration) - Required / Available / Configurable frequency bands - Required / Available / Configurable timing, Here, "required" means network A tells network B that parameter X is required, "available" means network A tells network B that parameter X is available, and "configured" means network A tells network B that parameter X is configured. Since these parameters can be agreed upon in advance between networks, a network (e.g., the primary network) can also indicate the agreed-upon parameters to UE 100 or AF 119. This indication can be done through one or more configuration messages (e.g., NAS messages). UE 100 can use this information, for example, in QUIC, to determine the parameters for multipath communication. This can be a simpler approach than requiring the endpoints (e.g., UE 100) to determine the path latency or bandwidth themselves and, based on this, how to configure different communication flows for each path. Configuration messages can originate from the primary network or from both the primary and secondary networks. Configuration messages can include multipath session (e.g., MP-PDU) identifiers and associated communication parameters.

[0201] Section 4.2.10 of the 3GPP specification TS 23.501 declares that the UPF supports performance measurement functions, which the UE 100 can use to obtain access performance measurements on the user plane of 3GPP access and / or non-3GPP access (as described in Section 5.32.5 of TS 23.501). In the case of multiple networks and / or when the access network is based on satellite, it is important that performance is measured not only based on local conditions but also on the expected behavior of the network. For example, if the network transmits data via a satellite link or mobile access device, the mobility pattern of the device may affect performance. This information (expected performance at a given time) can be shared with / used by the UE 100.

[0202] Therefore, in an embodiment (DS_NTN_conf) that can be combined with other embodiments or implemented independently, after a MAPDU session is established and when user plane resources exist on both access networks, UE 100 can apply network-provided policies (i.e., ATSSS rules) and can consider local conditions (e.g., network interface availability, signal loss conditions, user preferences, etc.) and network / access network connectivity conditions to determine when and how to distribute uplink / downlink services / management services on two or more access networks. For example, ATSSS rules may include expected availability timing, location availability, signal strength, expected performance (RTT, jitter, bandwidth, etc.). This allows UE 100 to execute rules in advance and make decisions on splitting services in a specific manner before some local conditions occur (e.g., connection loss). This embodiment is applicable to Section 5.32.8 of TS 23.501 and is also applicable to UEs connected to / connected to a single core network.

[0203] In another embodiment, which can be used in combination with other embodiments or independently, in an NTN network scenario, the communication path to UE 100 (e.g., based on TCP or QUIC connections) can be segmented into multiple segments to enhance performance. For example, there may be a connection segment UE-NTN gateway and a connection segment NTN gateway-UPF, where the NTN gateway is the entity that handles connections to UE 100 via satellite 123. This may require protocols or one or more messages for determining / agreeing / configuring / verifying whether the path connection UE-UPF on the NTN is end-to-end (UPF to UE) or segmented (e.g., UE-NTN gateway connection and NTN gateway-UPF connection). The CN (e.g., first core network 109) may request (multipath) communication where one path passes through the UE-NTN gateway. The CN may then send a request to the UE-NTN gateway to split the path into two links for providing specific configuration parameters such as congestion windows. The communication configuration of that path can then be notified to or obtained from the network to UE 100, specifically the communication parameters assigned to each segment, whether hop-by-hop or not. The communication path can be end-to-end between UE 100 and CN, or it can be hop-by-hop between UE / CN and NTN gateway (or any other entity in the path). This allows the CN (e.g., SMF, UPF) or UE 100 to configure, for example, different (initial / maximum) congestion windows that enhance certain parameters of end-to-end performance (e.g., throughput) when the UE-UPF path connection on the NTN is segmented. This allows the CN (e.g., UPF) or UE 100 to determine whether traffic received via the NTN path is real-time / latency sensitive or may have been cached for some time, e.g., at the NTN gateway. Therefore, using this information, the endpoint (e.g., UE 100) can determine the (multipath) communication configuration.

[0204] Section: ATSSS - Non-3GPP Access The following embodiments are defined with reference to the architecture and solutions in 3GPP TR 23.700-54 v0.2.0 (particularly solutions #2.7 and #2.8 that may lack a suitable mechanism for path verification), and token-based processes as described in other embodiments may be applicable.

[0205] In embodiments that can be combined with other embodiments or implemented independently, the UE may register to the PLMN via 3GPP access using the first PDU session establishment procedure. During or after the first PDU session establishment procedure, on the established PDU session, the UE may receive (e.g., using NAS messages) the IP address and port number of the UPF accessible via non-3GPP access, and / or the IP address or other identity to be used by the UE, and / or credentials for communicating with the network (e.g., the UPF) via non-3GPP access, and / or tokens for IP address authentication, and / or tokens for QUIC path authentication (or other types of tokens as described in other embodiments). When the UE registers to the network via non-3GPP access or establishes a PDU session with the network via non-3GPP access, the UE may use the received information (or a subset thereof). For example, it can use a received token and / or UE identity in a message M to the UPF (e.g., a registration message or PDU session establishment request message) via non-3GPP access (e.g., using the received IP address and UPF port), and / or it can use credentials received from the network to protect / encrypt message M (or part of the message payload) or include a message authentication / integrity code (MAC / MIC) in message M to the UPF via non-3GPP access. When the UPF receives any message on its IP address and port open for non-3GPP access, the UPF can verify whether the message contains any of the aforementioned information; if not, the UPF can discard the message. In some cases, message M can be received directly (e.g., once a UDP / TCP connection is established). In other cases, message M can be received only if a secure connection has been established (e.g., a TLS connection has been established), allowing message M to be exchanged within the TLS connection and preventing it from being eavesdropped on and retransmitted by an attacker.

[0206] In some cases, if it does not contain any of the above information, the UPF can be configured by the PCF, for example, to block connections. The UPF can also log events and / or notify another network function or entity (e.g., OAM).

[0207] In some cases, the UPF may request additional authentication or verification checks with the UE via 3GPP access and a first PDU session, for example, when the message includes an indication of establishing multipath communication and includes an indication of the UE's identity. To this end, the UPF may send message N to / via the AUSF, SMF, or AMF, whereby message N may include information received from the UE in message M to request the AUSF, SMF, or AMF to access via 3GPP and trigger authentication or verification checks with the UE via the first PDU session. In some cases, the AUSF, SMF, and / or AMF may do this only if the UE is configured or is establishing multipath communication; for example, the SMF may have already been notified of the intention to establish a multipath connection via 3GPP and non-3GPP access. This further authentication may be triggered / completed by sending a message N' (e.g., a NAS message) to the UE that includes an authentication or verification check, and / or the UPF may send a message O (e.g., a NAS message or other type of message) that needs to be (transparently) forwarded to the UE by the AUSF / SMF / AMF to perform authentication or authorization checks. Message N' or Message O may include the UE's identity information (e.g., the identity information received in Message M), and / or a password challenge, and / or information about incoming traffic via non-3GPP access (e.g., questions for the device or its user to confirm that they have requested access to the network via non-3GPP access, possibly including timestamp information of when the UPF received the incoming message M), and / or, if the UE intends to establish, is establishing, or has already established the connection, it may request the transmission of a token / authentication value via non-3GPP access. Upon receiving such a message N' or O, the UE may perform the requested authentication or verification check, and / or the requested action, and respond using Message P, which may be sent via the first PDU session (or via previously received non-3GPP access to the UPF via the UPF's IP address / port).

[0208] Additionally or alternatively, messages N' or O, or subsequent messages (e.g., before or after a successful authentication or verification check, such as indicated by message P), may include UE credentials (e.g., in addition to or in lieu of credentials that may have been sent when establishing the first PDU session) for use in subsequent messages to the UPF via non-3GPP access (e.g., for encryption or integrity protection). For example, the core network may assign communication parameters (e.g., credentials, such as keys or certificates or IP addresses) to establish communication via non-3GPP access.

[0209] Alternatively, the UPF may use known / trusted credentials to verify whether message M is protected (e.g., encrypted) (e.g., because these credentials were provided to the UE using the first PDU session (during initial session setup or in message N' or message O or subsequent messages) and may also have been shared with the UPF). If it is not protected, the UPF may discard the message. The UPF may also log events and / or notify another network function or entity (e.g., OAM).

[0210] This implementation is motivated by the introduction of the concept of Non-Integrated Non-3GPP Access (NIN3A) in TR 23.700-54. NIN3A is a non-3GPP access network that provides a direct IP connection between the UE and the UPF without any intermediate NFs, such as Non-3GPP Interoperability Functions (N3IWF) and Trusted Non-3GPP Gateway Functions (TNFG). Here, the UE does not register to the 5GC through this non-integrated non-3GPP access. However, the UE can still access 5G resources, namely the UPF and SMF. Without defined security, the system may be prone to unauthorized access, impersonation, and denial-of-service. Therefore, a solution is needed to authenticate UEs accessing the network via non-integrated non-3GPP access.

[0211] In embodiments that can be used in combination with other embodiments or independently, the mobile access device may incorporate certain functions of the core network, including the UPF and SMF. The mobile access device may be a satellite operating in store-and-forward mode. In this case, the method for authenticating / authorizing the UE may be based on a solution that allows the UE to access the network via non-integrated, non-3GPP access, wherein when the UE needs to transmit data, the UE can connect to the mobile access device, and the UE can directly authenticate / authorize with the UPF, and transmit data to the UPF during authentication / authorization.

[0212] Other embodiments have described solutions that allow a UE to authenticate with / obtain authorization from a mobile access device (e.g., operating in store-and-forward mode). Such solutions can also be applied to non-integrated, non-3GPP access. For example, a UE can perform legacy / standard primary authentication on a 3GPP access, and the UE can obtain certain credentials through the 3GPP access. This is similar to the case where a UE authenticates with a first core network through a first mobile access device. The UE can then indicate its intention to use non-integrated, non-3GPP access, obtain certain credentials, and parameters for accessing the UPF. This indication can also be sent to the first mobile access device / core network, indicating the UE's intention to communicate through a second mobile access device at a later time. Similar credentials / parameters can be provided to the UE to access the UPF of the second mobile access device at a later time. Finally, the UE can use the provided credentials / parameters to authenticate itself against the UPF. For example, the credentials could be an authorization token or key, or a key to a one-time password. For example, these credentials can be exchanged when establishing an IP connection between the UE and the UPF, before establishing a secure channel (e.g., in the header of a security protocol such as TLS or IPSec) and / or once the secure channel is established. If credentials are exchanged before establishment, the system / UPF is more resistant to DoS attacks. If credentials are exchanged after the secure channel is established, the system is more resistant to spoofing. It should be noted that the UE can also send credentials to the UPF to allow the UPF to authenticate the UE, but the UPF can also send credentials to the UE to allow the UE to authenticate the UPF. These credentials can be considered a type of token.

[0213] Generally, an apparatus for authenticating, authorizing, and managing connections is described, wherein the apparatus is configured to: Check or select the preferred certification process; The device performs an optimal authentication process with the first core network through the first access device; and Establish a communication connection with the first core network.

[0214] Aspect a) The above-mentioned device is also suitable for: - Indicates the establishment of a connection via a non-3GPP access and / or mobile access device. - Receive configuration for non-3GPP access and / or mobile access devices, wherein the configuration may include parameters for authenticating with non-3GPP access and / or mobile access devices, and - Use the configuration described above to perform authentication with non-3GPP access and / or mobile access devices.

[0215] Aspect b) The apparatus according to aspect a) is also suitable for: - Receive configuration for non-3GPP access or mobile access devices, the configuration including the IP address of a second entity (e.g., UPF) and at least one of a first token, a second token, a third token, a fourth token, and a fifth token. - Establish an IP connection with the second entity at the received IP address, and - Perform one or more of the following actions: o Before establishing a secure connection with the second entity, send a first token (e.g., an authorization token, a one-time password). After establishing a secure connection with the second entity, send a second token (e.g., an authorization token, a one-time password). If the sixth token (e.g., an authorization token, a one-time password) received from the second entity before establishing a secure connection matches the third token, then communication is permitted. If the seventh token (e.g., an authorization token, a one-time password) received from the second entity after a secure connection is established matches the fourth token, then communication is permitted. o Use a fifth token (e.g., a symmetric key, a certificate) to establish a secure connection with the second entity (e.g., TLS, IPSec), and allow the connection if the authentication steps for establishing the secure connection are successful.

[0216] Summary: Dual-booting - Privacy-aware agreements on allocated communication resources between networks In another scenario, network A (e.g., first core 109) and network B (e.g., second core 114) may need to agree on some communication parameters. However, network A and / or B may be unwilling to disclose all data, such as the specific amount of available resources. This is because network A and network B are operated by different operators that can be considered competitors, making it desirable to limit what the other party learns, even if they might be willing to collaborate on a given task. To achieve this, in another embodiment, which can be combined with other embodiments or implemented independently, network A and network B may run a privacy-enhancing technology (PET)-based protocol when determining whether the MA-PDU can be used to communicate with the UE (e.g., UE 100) through two or more different networks. PET-based protocols can be based on, for example, multi-party computation, where two or more parties jointly compute a function without disclosing input parameters.

[0217] For example, suppose a user needs a given data rate DR, and networks A and B might want to determine / verify whether they can jointly provide services without exposing their available resources to each other. Networks A and B might then want to compute a function F(DR, a, b) without exposing parameter a to network B and parameter b to network A, where a and b represent available resources in networks A and B, respectively. This function F can be computed privately by applying a two-party computation protocol (e.g., Yao's obfuscated circuit protocol). For settings involving more than two parties (e.g., three networks), multi-party protocols based on, for example, Shamir secret sharing or additional secret sharing can be used.

[0218] In another embodiment variant, any network (e.g., first core network 109 or second core network 114) may indicate the need for a specific PET-based protocol and / or specific parameters for that PET-based protocol. The PET-based protocol and its corresponding parameters may be standardized parameters. The requesting network (e.g., the primary network) may indicate the supported PET-based protocols / parameters, and the responding network (e.g., the secondary network) may indicate the selected PET-based protocol / parameters. During this initial PET-based protocol / parameter negotiation process, the networks also agree to bind a PET protocol session identifier to the multipath communication (e.g., MP-PDU) to be established. The networks can then exchange PET-based protocol-specific content within the PET container protocol. The requesting network may send the PET-based protocol content in a PET-Requester-Container message including a PET-Requester-Container counter to track the exchanged messages. The responding network may send the PET-based protocol content in a PET-Replier-Container message including a PET-Replier-Container counter to track the exchanged messages. The counters should be unique to identify them.

[0219] Summary: NTN - Communication used to enable UE communication or UE-to-UE communication on (mobile) access devices such as satellites. Architecture Figure 4 A block diagram and communication paths are schematically shown through multiple networks and / or through different radio access technologies.

[0220] In some scenarios, Figure 1 The communication architecture described herein can be used to implement direct communication between two UEs, for example, as Figure 4As shown, another type of device 123 (e.g., a satellite) can provide a relay communication link 126 between the first UE 100 and the second UE 103. In this case, the direct communication link 120 may not exist. The relay communication link 126 can allow voice, data, and other communications between the first UE 100 and the second UE 103. The communication architecture can be based on different protocols, such as IP Multimedia System (IMS).

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

[0222] In the case of relay communication link 126, a subset of IMS functions, the IMS network, and / or SIP servers can operate on other types of devices 123 providing relay. Once a session is established, media is exchanged between the first UE 100 and the second UE 103 and the IMS network using Real-time Transport Protocol (RTP). In the case of relay communication on relay devices (such as other types of devices 123), several challenges need to be addressed, including: how to verify / authorize the use of the satellite link by the first UE 100 and the second UE 103 as a relay, how to notify the satellite that it can act as a relay for the communication, the level of security of direct communication between the first UE 100 and the second UE 103, and how to ensure QoS in the communication link, etc.

[0223] In other cases, when the (mobile) access device can operate in different modes, it is simply required that communication between the UE and the infrastructure be achieved in a manner that best determines / configures the end-to-end communication radio access network link. In some cases, access devices such as other types of equipment 123 can follow a regenerative or transparent (NTN) architecture. In a regenerative (NTN) architecture, the access device (e.g., a satellite) acts as a base station (gNB), while in a transparent (NTN) architecture, the access device (satellite) acts as a reflector, such as a smart repeater (NCR) or a reflective smart surface (RIS).

[0224] Figure 5 (User plane) and Figure 6 (Control plane) illustrates the protocol stack for a transparent NTN architecture, where "Mobile Access Device" (MAD) refers to... Figure 4Another type of device in the list is 123, and "GW" refers to a gateway.

[0225] also, Figure 7 (User plane) and Figure 8 (Control plane) shows the protocol stack used for regenerating the NTN architecture, where "Mobile Access Device" (MAD) refers to... Figure 4 Another type of device 123, and "MAD / GW-IF" refers to the interface between the mobile access device and the gateway.

[0226] (In regenerative mode) The advantage of a mobile access device acting as a base station is its ability to utilize all signaling to optimize uplink / downlink communication performance. The advantage of acting as a reflector is lower (communication) complexity, including lower energy requirements and lower latency. Nevertheless, these architectures may be suboptimal in some situations.

[0227] Therefore, the following process can be applied to address these challenges: In embodiments that can be used in combination with other embodiments or independently, the (mobile) access device can have a hybrid regenerative / transparent NTN architecture, wherein the mobile access device (e.g., satellite) 123 can be configured to operate based on a regenerative NTN architecture and / or a transparent NTN architecture for certain types of communication or phases of communication. For example, the control plane can be based on a regenerative NTN architecture, and the user plane can be based on a transparent architecture. For instance, the first phase of communication can be based on a regenerative NTN architecture, and a later phase of communication can be based on a transparent NTN architecture.

[0228] In embodiment variations that can be used in combination with other variations or embodiment variations, when the mobile access device 123 operates as an access device using a regenerated NTN architecture, Figure 4 The first UE 100 may have already established a communication link with the second UE 103 via the mobile access device (satellite) 123, such as a direct communication link via relay. Once this initial communication with the first UE 100 is established, the mobile access device 123 can be configured in a hybrid regenerable / transparent NTN architecture, in which the mobile access device 123 applies a transparent architecture to UE-to-UE communication.

[0229] In another embodiment variation, this hybrid regenerative / transparent NTN architecture can be applied to communication between the first UE 100 and the second UE 103, or to communication between the RAN 106 and the first UE 100 via the mobile access device 123, such as... Figure 4The upper part of the bold solid line path 128 is shown. An advantage of this architecture is the lower power consumption in the mobile access device 123. Another advantage is reduced communication link latency. For example, the first UE 100 and the second UE 103 can connect to the network using a regenerative NTN architecture, and when they are requested to communicate with each other, the first UE 100 and the second UE 103 can switch to a transparent NTN architecture, for example, for their specific communication links. Another advantage of using a transparent architecture is that the first UE 100 and the second UE 103 may only need to establish a direct communication link (without active relay equipment in between). This simplifies communication and security procedures.

[0230] In one aspect of this embodiment, the entity can manage the operation of (mobile) access device 123 in regenerative and / or transparent (NTN) architecture modes for use in the control plane or user plane, or for specific communication links, or for certain portions of communication. For example, conditions (e.g., RTT threshold, load / congestion threshold, availability / timing) for applying a certain communication mode (e.g., regenerative or transparent or a hybrid thereof) to communication, or a portion thereof, or its timing or communication link, can be configured by the core network (e.g., first core network 109 and / or second core network 114), for example, through policies provided to RAN 106 by the core network's AMF or by RAN 106 itself. This configuration can also be provided by the ground station (e.g., acting as a gNB-CU) to non-terrestrial access devices (e.g., mobile access device 123, which may act as, for example, a gNB-DU, NCR, or RIS).

[0231] In one aspect of this embodiment, a given communication link or the transmission of certain data may require, for example, very low latency and high reliability. To achieve this, the (mobile) access device may first transmit the data transparently (i.e., using a transparent architecture as a reflector) and then retransmit the data regeneratively (i.e., using a regenerative architecture as a base station) at least once. This approach, which can be used independently, allows the UE to receive the data or communication faster (due to the transparent architecture) and more reliably (due to the regenerative architecture). The (mobile) access device may be satellite, but may also be other types of access devices (terrestrial or non-terrestrial) with a combination of transparent and regenerative architecture capabilities, such as smart repeaters and IAB base stations, which can be configured to operate in a manner suitable for the data communication / data (re)transmission. For example, the access device may be configured to transparently and regeneratively (at least once) retransmit data received in some given communication resources (time and frequency). This can be accomplished via configuration messages such as MAC commands or RRC messages. The UE receiving the data may also be configured to receive the data at least twice, first based on the (mobile) access device's transparent architecture and once or more based on the regenerative architecture. If data is transmitted more than once based on a regenerative architecture, it is advantageous to use different frequency bands for the transmissions at the same or different times. It should be noted that if the access device is mobile, for example, in the case of satellite, the communication / channel path changes over time, and therefore it may experience a better communication / channel path.

[0232] In a relevant aspect of this embodiment, data received in some given communication resources (time and frequency) at the (mobile) access device can be retransmitted transparently (the (mobile) access device operates in a transparent manner, transparent path) and regeneratively (the (mobile) access device operates in a regenerative manner, regenerative path) in some other communication resources (time and frequency), thereby the communication resources used for transparent and regenerative retransmission can, for example, not overlap in time and frequency to facilitate reception at the receiver.

[0233] When data retransmitted via the regenerable path is sent in a different frequency band than data retransmitted via the transparent path, it may be advantageous if the frequency band is close in frequency to the guard space of the data retransmitted via the transparent path.

[0234] When data retransmitted on the regenerating path is sent in the same frequency band as data retransmitted on the transparent path, it may be advantageous if the data retransmitted on one of the paths is delayed sufficiently until a time-bound guard space prevents it from arriving at the receiver simultaneously. This may require the use of a resource allocation mechanism where the resources allocated to the first path (e.g., the regenerating path) have a delay relative to the communication resources allocated to the second path (e.g., the transparent path), where the delay depends on the data transmission time in the second path plus the processing time at the (mobile) access device for the second path. This may require the use of small data units, as they involve lower transmission times.

[0235] It should be noted that some of these considerations may not apply to, for example, continuous interference cancellation (SIC) receivers, because SIC receivers can use the data (stream) that arrives first (e.g., via a transparent path) to remove interference from the data (stream) that arrives second (e.g., via a regenerable path), even if they overlap in time / frequency resources.

[0236] In a relevant aspect of this embodiment, a given communication link / data transmission using a combined transparent / regenerative access device can be identified by its representative identifier. This allows the access device to perform transparent / regenerative operations on the communication link / data transmission, and allows the UE to receive and process data accordingly. Furthermore, the configuration message may also include the time when data is scheduled for reception and / or transmission. For example, when the access device receives data to be processed according to the hybrid architecture and which communication resources should be used for (re)transmission. For example, when the UE receives data to be processed / transmitted according to the hybrid architecture.

[0237] In a relevant aspect of this embodiment, the UE may have a specific processing pipeline for this type of data transmitted via a hybrid architecture. For example, the UE may be configured to receive first data (transparently forwarded by the access device) and, if received correctly (e.g., based on an integrity check using a CRC or error-correcting code or message integrity code), ignore subsequently received data (reproducibly sent by the access device). If the first data is not received correctly, second data may be received and processed. It may be processed independently or combined with the first data, for example, softly combined by adding received symbols.

[0238] In related aspects of this embodiment, transparent and regenerative architectures can have different levels of complexity; in other words, they can be implemented in the receive-transmit pipeline with... Figure 5-8The various numbers of functions described herein. These functions (typically) may include antennas, RF front-ends, low physical layer, high physical layer, low MAC layer, high MAC layer, low RLC layer, high RLC layer, PDCP layer, and higher protocols and / or functions in the base station, such as in Figure 12 The base stations are split into central / distributed units as shown. For example, a transparent architecture may only implement the antenna and RF front-end functions as a pure RF repeater within a given configurable frequency / time band, while a regenerative architecture may implement all or some of the aforementioned layers and protocols. This could mean that a transparent architecture can forward received data without any processing or modification, while a regenerative architecture may decode, process, and re-encode data before transmission. Complexity can affect the architecture's performance, cost, power consumption, and latency. In another configuration / variation, the transparent architecture may include antenna and RF front-end functions as well as a low physical layer involving the decoding / encoding of the bitstream. This additional processing overhead has the advantage that the transparent architecture does not act as a pure RF repeater but only retransmits resource blocks containing information. In another configuration / variation, the transparent architecture may include additional physical layer functions such as CRC and error correction. This ensures that if some symbols are not decoded correctly, the bitstream is corrected before recoding and retransmission, thus ensuring higher reliability of the end-to-end communication link.

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

[0240] In another embodiment, transparent and regenerative architectures may include different sets of layers and protocols, depending on the communication scenario, network conditions, user requirements, and / or device capabilities. For example, a transparent architecture may include only antenna, RF front-end, and low physical layer functions, while a regenerative architecture may include antenna, RF front-end, low physical layer, high physical layer, and low MAC layer functions, such as... Figure 12As shown. These functions can be implemented in hardware, software, or a combination of both. The choice of layers and protocols to include in each architecture can affect the architecture's performance, cost, power consumption, latency, and compatibility and interoperability with other devices and networks.

[0241] Mobile access device 123 can share some hardware components, such as the RF front-end or low physical layer, between transparent and regenerative architectures. This can reduce device complexity and cost, as well as switching time between architectures. Alternatively, mobile access device 123 can have dedicated hardware components for each architecture, which can increase device flexibility and robustness, as well as isolation between architectures. The sharing or separation of hardware components can depend on the communication scenario, network conditions, user requirements, and / or device capabilities. Figure 13 This breakdown is illustrated, where 1301 represents the (mobile) access device, 1306 represents the common lower layer for both architectures, 1304 and 1305 represent the replicated (lower) layers in the regenerative and transparent architectures, and 1302 and 1303 represent specific (higher) layers / functions in the regenerative and transparent architectures. This may require the (mobile) access device to indicate its characteristics to the gateway or access device responsible for its management, such as which components are included in 1306 and / or 1304 and / or 1305. This allows the gateway or access device or the (mobile) access device management service to determine configuration parameters, such as the protection time required for switching from transmit / receive through the transparent / regenerative architecture, or which port antenna should be used for the regenerative / transparent architecture / communication mode. As an example, (mobile) access devices implemented as two physically distinct, preferably co-located (or quasi-co-located, i.e., positioned such that the propagation paths from each to the UE are similar) devices will be managed by the network as two separate devices, where resource management arranges for the two devices to share the same channel, thereby allowing necessary time and frequency protection space. For example, a transparent path may include a network-controlled repeater (NCR), where the network controls the repeater operation via the repeater's NCR-MT (NCR Mobile Terminal) module; a regenerative path may include an Integrated Access and Backhaul (IAB) node, where the network controls the IAB operation via the IAB MT module of the IAB node.

[0242] This aspect, applicable to all dual-path arrangements, is that the regenerated path typically imposes more delay on the data path than the transparent path. Advantageously, the differential delay between paths on the transmitting path is arranged as an integer number of transmission slots, or preferably, with precisely aligned transmission frames at slot or frame boundaries. To facilitate this, the regenerated path can be configured by the network with timing delay, offset, or alignment parameters that adjust the output timing as needed.

[0243] As a second example, the two paths can be arranged as a shared antenna system. In this case, although the two paths are managed as separate nodes, the antennas are managed as shared resources. This can be accomplished either by always controlling the antennas via NCR-MT or IAB-MT, or by arranging the antennas to be controlled by any path that is allocated transmit or receive resources within a given time or frequency. Switching antennas between paths can be done implicitly via resource management or explicitly via signals transmitted from the network.

[0244] As a third example, paths can be combined at lower levels, allowing two paths to share the same transmitter power amplifier. This can be advantageous because the power amplifier will not need to be powered on and off between path changes, meaning the required guard space in the time domain can be minimized. If the network is aware of this, it can potentially perform more efficient scheduling. The (mobile) access device can report its configuration to the network (e.g., as part of the capabilities exposed by the mobile access device, such as when the UE capabilities are transmitted by the mobile terminal in the case where the mobile access device includes a mobile terminal), enabling the network to control the (mobile) access device appropriately.

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

[0246] In addition, different parameters can be configured for transparent and regenerative architectures, such as modulation scheme, coding rate, transmission power, frequency band, channel bandwidth, subcarrier spacing, symbol duration, frame structure, parameter set, pilot mode, resource allocation, feedback format, HARQ scheme, MIMO scheme, beamforming scheme, interference management scheme, security scheme, authentication scheme, synchronization scheme, data compression scheme, etc.

[0247] In one aspect of this embodiment, mobile access device 123 may distribute system information that informs UEs (e.g., first UE 100 or second UE 103) or other access devices (e.g., first access device 107 and / or second access device 108) of their ability to support a hybrid regenerative / transparent NTN architecture. This capability may be conveyed in a System Information Block (SIB) (e.g., SIB1 or SIB19) or in a Radio Resource Control (RRC) message. The UE may express its selection during the initial random access procedure or via an RRC message.

[0248] In one aspect of this embodiment, the mobile access device 123 or management entity may notify the first UE 100 and / or the second UE 103 or other access devices (e.g., the first access device 107 and / or the second access device 108) or the core network (e.g., the first core network 109 and / or the second core network 114) that the configuration of a given communication link is in transparent or generated mode.

[0249] In one aspect of this embodiment variation, a UE (e.g., first UE 100 and / or second UE 103) may initially connect to the network using an access device (e.g., first access device 107 and / or second access device 108) in a mode such as regenerable mode (e.g., performing random access or primary authentication via a random access channel (RACH)). Once connected, the UE / access device may switch to a different mode, such as communicating in transparent mode when the connection is suitable or communication requirements do not necessitate regenerable mode. In some cases, this communication mode switching may be performed only for a portion of the communication; for example, it may be performed for the user plane (transparent mode) but not for the control plane; or it may be performed only for certain communication links. This may result in the device needing to associate different communication parameters with different communication links. For example, the UE may need to apply different timing advances depending on the communication link it is processing, because some communication links may point to (regenerable) mobile access device 123 (operating in a regenerable manner), while other communication links may reach another access device through (transparently operating) mobile access device 123. For example, the UE can be notified or configured with the communication parameters for each communication link. For example, different communication links can be grouped into different categories, such as regenerative or transparent.

[0250] In one aspect of these embodiments (variations) or application scenarios, mobile access device 123 may refer to other mobile access devices, such as UAVs or vehicles. In some cases, mobile access device 123 may be static, such as a distributed unit or IAB device or a smart repeater (NCR) or reflective smart surface (RIS), and may switch between, for example, a distributed unit (equivalent to a regenerative architecture) and a smart repeater / NCR (equivalent to a transparent architecture) or between an IAB node and a smart repeater / NCR. Therefore, embodiments and variations of embodiments associated with hybrid regenerative / transparent access device architectures can also be applied to such application scenarios.

[0251] In one aspect of these embodiments or variations thereof, when their operating modes change, multiple UEs (e.g., first UE 100 and second UE 103) can connect to mobile access equipment 123. If the service level is triggered by a mode switch, at least some UEs will be connected during the transition. RAN 106 or core network 109, 114 can utilize them to perform multiple actions. Options may include: - Option 1: Force a handover to a new access device, which may be necessary if the access device can only operate in one mode at a time. This may require triggering of a synchronization handover (e.g., conditional handover) and a change in operating mode. Note that this may not always be received, as in regenerable or transparent modes, the UE receives signals (e.g., synchronization signals) generated or reflected from the access device (e.g., mobile access device 123).

[0252] Option 2: Configure or notify the UE of mode switching, e.g., from regenerative to transparent, so that the UE knows it can use the access device (e.g., mobile access device 123) as a reflector when communicating with other devices. In this case, the UE (e.g., first UE 100) may need to know the identifier (e.g., RAN identifier) ​​of the target UE (e.g., second UE 103). The access device may also need to know which communication resources are allocated to a given (reflected) communication link so that when the access device receives a signal from one of the UEs (e.g., first UE 100), it can reflect the signal to the location of the other UE (e.g., second UE 103). The access device can achieve this by performing resource allocation for communication between the first UE 100 and the second UE 103, e.g., tracking the locations of both UEs 100 and 103 upon request from the first UE 100 and the second UE 103, and configuring the communication beam in a manner that allows the allocated communication time slots / frequency ranges to be reflected to the target UE. It should be noted that the control logic may be located in the mobile access device 123 itself or in a ground entity such as RAN 106. The control logic needs to track communication requests from the first UE 100 and / or the second UE 103, track the location of the first UE 100 and / or the second UE 103, and perform resource allocation. One aspect here is that it may be necessary to inform the first UE 100 and / or the second UE 103 that "direct" communication between them is accomplished through an access device operating in transparent mode, such that when they perform beam alignment for a given communication, it is done for the mobile access device 123 itself.

[0253] This may mean that when the first UE 100 and the second UE 103 communicate with each other transparently through an access device (e.g., mobile access device 123), the need for direct beam alignment between the first UE 100 and the second UE 103 is disabled, and beam alignment for UE-to-UE communication can be replaced by a UE beam alignment process directed toward the access device itself. This is because when a UE aligns its beam toward the access device, communication toward the target UE will be correctly reflected. The advantages of this are a more accurate process and reduced signaling.

[0254] This could further mean that when the first UE 100 and the second UE 103 communicate with each other transparently through the access device, they need to apply different timing advance values ​​for the reflected communication path (i.e., timing advance values ​​for communication with the access device itself or the control logic of the access device in mobile access device 123 or RAN 106), or different timing advance values ​​when multiple reflected communication paths exist. The reason is that timing advance values ​​are calculated for the communication link between the UE (e.g., the first UE 100) and the control logic unit (e.g., mobile access device 123), but if, for example, two reflected communication paths exist, it may be desirable to receive the received signal synchronously. This requires the transmitting UE to transmit signals through different paths at different transmission times, where the time difference between the two transmission times is determined by the absolute length difference of the communication paths (path 1 - path 2) divided by the propagation time difference determined by the speed of light, where path 1 can pass through the first UE 100, mobile access device 123, and the second UE 103, while path 2 can pass through the first UE 100, another access device Z (… Figure 4 (not shown in the image) and the second UE 103. This requires the control logic unit of the mobile access device (where the control logic unit may be in the mobile access device 123 or in the RAN 106) to transmit the timing advance values ​​to the first UE 100 and the second UE 103, so that the first UE 100 and the second UE 103 apply these timing advance values.

[0255] - Option 3: Maintain the existing connection in the earlier mode and start the new connection in the new mode (this may be appropriate if the UE spends relatively little time in the cell before switching to the new mode: the system will eventually switch to the new mode autonomously).

[0256] - Option 4: Gradually flip existing connections to the new state (i.e., start with two, but eventually force long-lived connections to switch). Options 2, 3, and 4 may all require the mobile access device 123 to be able to operate in both states simultaneously. Since the mobile access devices 123 (e.g., satellites or NCR / IAB nodes with a regenerative / transparent architecture) can (presumably) share spectrum and radio frequency (RF) hardware resources (e.g., amplifiers, filters, antennas, etc.), they may have units for ensuring coexistence, as described above for option 2.

[0257] There may be other reasons for simultaneous operation, so the fifth option could be to allow continuous operation in two modes, where the mode is selected on a per-connection or per-link basis according to the required service level. For example, if the regenerated link has higher quality and therefore can support higher bit rates / better reliability, a UE with a demanding application may be better served by an access device with a regenerated architecture (e.g., a satellite or IAB node with a regenerated architecture).

[0258] In one embodiment, the UE may directly or indirectly select (or at least express a preference) the operating mode used for its connection. In practice, the UE may intentionally utilize multipath relay or multi-cell operation, even at the same physical node. For a node, the trade-offs may be providing the most appropriate service (e.g., highest data rate) and the least, for example, total resource consumption, such as total energy / spectrum consumption, for each UE link.

[0259] Another aspect is that this operation can be performed across multiple frequency bands. As mentioned above, it can be dynamically changed independently for each (sub)band, or different frequency bands can operate in different modes on a (semi-)permanent basis.

[0260] In an embodiment, when an access device (e.g., mobile access device 123) applies a transparent NTN architecture to a given communication link, considering that mobile access device 123 acts as a transparent access device / reflector / smart repeater, the access device may need to select a frequency range suitable for both the uplink (e.g., from the first UE 100 to mobile access device 123) and the downlink (e.g., from mobile access device 123 to the second UE 103). This is necessary because the uplink and downlink frequency ranges are typically very different, making them not easily duplicated / forwarded. Therefore, when mobile access device 123 operates in transparent mode, the uplink and downlink frequency ranges can be the same. A reasonable option could be to use sidelink frequency resources or frequency resources allocated to sidelink-type communication via satellite for this communication, since in practice, the first UE 100 and the second UE 103 will appear to be within the communication range. While the mobile access device 123 is still operating in its regeneration mode, the mobile access device 123 may send a control message to the first UE 100 to initiate sidelink communication toward the mobile access device 123, which acts as a transparent access device in a selected frequency range (e.g., a sidelink frequency range), and to retransmit the sidelink communication to the second UE 103. The first UE 100 and the second UE 103 may have been configured / notified that the communication is supported by a transparent access device (such as the mobile access device 123 (e.g., a satellite)).

[0261] In one embodiment, when relaying communication between the first UE 100 and the second UE 103, the mobile access device 123 can also act as a UE-to-UE relay. For example, the process in TS 33.503 can be adapted to implement secure communication.

[0262] In another embodiment, the first UE 100 and the second UE 103 can establish a direct communication link through a mobile access device 123 operating in transparent mode to communicate with each other. For example, the direct communication link can be based on a PC5 interface, and the direct communication can be based on a real-time communication service or protocol, such as Real-Time Transport Protocol (RTP), a network standard designed for sending audio or video data and optimized for consistent delivery of real-time data. RTP is used in communication and entertainment systems involving streaming media, such as telephone, video conferencing applications including WebRTC, television services, and web-based push-to-talk features.

[0263] In embodiments that can be used in combination with other embodiments or independently, the first UE 100 may want to establish communication with the second UE 103. In a specific case of IMS communication, the first UE 100 may send a SIP INVITATION / SIP INVITE message to the IMS network (e.g., the first core network 109). The IMS network may detect that the destination (i.e., the second UE 103) is connected or can be connected via the same access device (e.g., mobile access device 123). In this case, the IMS network may direct the SIP INVITE message to the second UE 103 (destination). The second UE 103 may then reply, for example, with a 200 OK response based on a real-time communication protocol, thereby initiating the establishment of subsequent communication. Therefore, the IMS network / CN may instruct the mobile access device 123 to act as a local relay between the first UE 100 (source) and the second UE 103 (destination / target), rather than necessarily requiring it to act as a local relay between the first UE 100 (source) and the second UE 103 (destination / target). Figure 4 This communication is performed on both paths 128 in the protocol. This could mean that mobile access device 123, for example: - Operates as a regenerative access device, acting as a local router, for example, routing IP messages, exchanging RTP messages on the IP messages, and / or - Operates as a regenerative access device, acting as a UE-to-UE relay, such as an L2 or L3 relay, with end-to-end communication exchanged over the UE-to-UE relay, and / or - It operates as a hybrid regenerator / transparent access device, functioning as a transparent access device for user plane communication between the first UE 100 and the second UE 103, while operating as a regenerator for the control plane, or - Operates as a transparent access device, enabling it to function as a transparent access device for user plane and control plane communication between the first UE 100 and the second UE 103.

[0264] It should be noted that transparent operating mode means that the first UE 100 and the second UE 103 are directly reachable, for example, without an IP router in between.

[0265] It should be noted that when the mobile access device 123 uses protocols such as Real-Time Protocol (RTP) and other protocols, the above operating mode can be applied to UE-to-UE communication on the mobile access device 123.

[0266] It should be noted that for UEs that do not support NTN connections or are not part of a subscription (i.e., are not authorized to make NTN-based connections), the IMS network will decide not to route UP traffic via satellite before forwarding the SIP invitation. Even if the UE supports NTN connections, the network may not know the exact location of the UE, making forwarding the SIP invitation potentially challenging. Therefore, the following implementation scheme can be considered.

[0267] As explained in the other embodiments above, when a UE wants to use a given RAT for a given service (e.g., IMS), the UE may include an indication of this, enabling the network to verify whether the UE is authorized to use the selected RAT for the given service. Similarly, the UE may have a policy for giving preferences to a given RAT. This can also be in or following the service message exchange (in this case, a SIPINVITE message or a 200 OK message).

[0268] In embodiments that can be used in combination with other embodiments or independently, the IMS network can interact with the 5G network to determine whether the UE supports a given type of connection (e.g., NTN connection) and / or whether it is enabled in the user's subscription. The UE can be a second UE 103.

[0269] In embodiments that can be used in combination with other embodiments or independently, the IMS network can interact with the 5G network to determine whether the UE is already in the CONNECTEDZ state, and if so, which RAT to use. Such information can be obtained from the AMF serving the UE (see 5.4.10 in 23.501).

[0270] In embodiments that can be used in combination with other embodiments or independently, when it is determined that the UE is in an inactive or IDLE state, the network may attempt to page the UE from the last known RAN and determine whether to establish a UE-Mobile Access Device-UE route based on whether it initiated a service request procedure (4.2.3.2 in TS23.502), and again use RAT information to determine whether it should use a Mobile Access Device (e.g., satellite) for device-to-device communication.

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

[0272] In another embodiment, which can be used in combination with other embodiments or independently, a decision can also be made regarding routing information via a mobile access device (e.g., enabling UP traffic to pass through the mobile access device) before receiving a response from the second UE 103.

[0273] Generally, according to at least some embodiments described herein, an apparatus and method for establishing and managing connections are proposed, wherein the apparatus is configured to: • Receive indication of one or more communication modes for the access device. • Select or receive the choice of communication mode for communication via the access device. • When communicating with the first device through the access device, receive or apply communication parameters for the communication mode selected by the access device, wherein the first device may be a UE or a control device.

[0274] In at least some embodiments, the above-described apparatus and methods may also be adapted to select or receive a selection of a communication mode for a communication phase (e.g., initial random access procedure) or for a given communication procedure (e.g., network access) or for a given type of communication (e.g., control plane), and to select or receive an indication of the selection of a different communication mode for a subsequent communication phase or for a communication procedure or communication type.

[0275] In at least some embodiments, the above-described apparatus and method may also be adapted to receive or apply communication parameters indicating one or more of the following: - Use the beam alignment process with the access device when communicating with the first device. - When communicating with the control logic unit of the access device or the first device, the configuration and use of different timing advance values, and - Configuration and use of key materials for communicating with the first device.

[0276] Summary: NTN - The process of implementing UE-satellite-UE communication In the above scenario, the first UE may need to communicate with the second UE via satellite, where the communication flow is from the first UE to the satellite / gNB, and then from the satellite / gNB to the second UE. Entities such as the gNB or NF can be responsible for one or more of the following functions: - Establish a secure link with the first UE and the second UE: The secure link with the first UE and / or the second UE can be based on standard security in the Uu interface between the UE and the gNB. This means that both the first UE and the second UE need to perform master authentication so that the corresponding key (AS key) is available at the gNB; - Verification or request for verification of whether the first UE and the second UE are authorized to communicate with each other via a satellite link: The first UE and the second UE may have a given subscription available in the core network, for example, as part of a subscription profile, stating whether they are authorized to use the satellite link for direct communication, and the context in which they can use it (e.g., location, time, permitted communicators, etc.). The access device (e.g., gNB) may send a request to the core network (e.g., one or more AMFs, AUSFs, UDMs, UDRs) to obtain this information for, for example, to establish or already establish a given communication session between the first UE and the second UE. The request may be for a single network function, or may require interaction between network functions, for example, the AUSF may interact with the UDM. Additionally or alternatively, once the UE connects to the gNB, a portion of the subscription profile may be stored at the gNB. This authorization may also depend on the location of the UE (in which jurisdiction) and the location of the mobile access device; - Acts as the enforcement point for enabling or disallowing communication links: Once the gNB has verified the permission of the two UEs to establish a communication link, the gNB allows or disallows it. - Assign keys to protect UE-to-UE communication links, especially when communication via mobile access devices is conducted in a transparent manner.

[0277] Figure 14 A potential process for integrating some of these functions is illustrated, where boxes 1401, 1402, 1403, 1404, 1405, and 1406 can respectively refer to a first UE (UE1), a (Mobile) Access Device (MAD), a second UE (UE2), an access device or gateway, an NF function responsible for access and mobility (e.g., an AMF), and one or more NFs responsible for authentication. The process may include the following message exchange. This message flow is illustrative, and messages may be exchanged once or multiple times in different orders. In some cases, certain steps may be skipped.

[0278] - In message exchange 1407, 1401 can perform the initial master authentication process; - In message exchange 1408, 1403 can perform the initial master authentication process; In message exchange 1409, a first UE (e.g., 1401) may trigger a communication request with a second UE (e.g., 1403). 1405 relates to and observes (e.g., only) that 1403 is reachable via 1402. For example, the first UE may be accessible via, for example, a terrestrial access device (such as...) Figure 14The first UE is within the coverage of a 5G gNB (not shown), while the second UE is only within the coverage of a (non-terrestrial network) access device (1402). 1405 knows that the communication path used to establish communication may involve both 1402 (used by the second device) and the terrestrial access device used to connect the first device, but since the first device may also be able to connect to 1402, 1405 may prefer / instruct the first device to communicate with the second device through 1402. This can be accomplished through message exchanges 1410-1416; Entity 1406 can also, for example, verify, upon request 1405, whether UE 1401 and UE 1403 are permitted to communicate via mobile access device 1402. This is likely because it may not be part of a subscription.

[0279] - In message exchange 1410, 1405 can send 1404 for configuration, and / or request 1404 to configure: 1401, 1402, and 1403 to perform UE-to-UE based communication on 1402. For example, if 1402 operates transparently, 1404 will retain the responsibility of managing the RAN connection; In message exchange 1411, 1405 can send a configuration to 1402 to perform UE-to-UE based communication between 1401 and 1403. For example, if 1402 operates in a regenerative manner (e.g., it functions as a base station), then 1404 will be responsible for managing the RAN connections with 1401 and 1403. - In message exchange 1412 (1413), 1405 can send 1401 (1403) configuration to perform UE-to-UE communication with 1403 (1401) via 1402. For example, it can notify 1402 of its usage, configuration parameters connected to it, etc.; - In message exchange 1414, 1404 can send 1402 configuration to enable UE-to-UE based communication between 1401 and 1403. This can occur, for example, when 1402 is operating in a transparent manner; - In message exchange 1415, 1404 can then send 1401 (1403) configuration to perform UE-to-UE communication with 1403 (1401) via 1402. This can also occur, for example, when 1402 is operating in a transparent manner; In message exchange 1416, 1402 can send 1401 (1403) configuration to perform UE-to-UE communication with 1403 (1401) via 1402. This can occur when 1402 is operating in a regenerative mode, such as in the control plane. - In message exchange 1417, communication between 1401 and 1403 occurs via 1402, for example, using 1402 in a transparent or regenerative manner on the user plane.

[0280] In the embodiments of the invention shown by the above process, those message exchanges used to send configuration (e.g., 1412) can also be used to report parameters, measurements, request configuration, etc. For example, message exchange 1415 can also imply that 1404 collects measurement reports from 1401 / 1403.

[0281] In the embodiments of the invention shown by the above process, some message exchanges may occur simultaneously. For example, message exchange 1416 may refer to control plane communication to control user plane communication in message exchange 1417.

[0282] In the embodiments of the invention illustrated by the above process, message exchange can be performed via a user plane or a control plane and / or using a transparent and / or regenerative architecture. For example, message exchange 1416 may refer to control plane communication using a regenerative architecture to control user plane communication in message exchange 1417 using a transparent architecture.

[0283] In the embodiments of the invention shown by the above process, 1405 and / or 1406 may be responsible for verifying whether 1401 and 1403 are permitted to communicate via 1402.

[0284] In the embodiments of the invention shown by the above process, 1405 and / or 1406 send an acknowledgment to 1404 and / or 1402 regarding whether the communication is permitted, and / or a configuration describing which communication is permitted, for example, it may describe the type of communication that both UEs are entitled to perform.

[0285] In the above process, 1404 and / or 1402 implement / apply the configuration.

[0286] Aspects related to UE-UE communication involve the locations of the UE and the mobile access device (e.g., satellite), particularly the jurisdiction where the UE and / or mobile access device reside. Depending on those locations, UE-satellite-UE communication may or may not be permitted. This can be based on policies that can be deployed in the mobile access device (e.g., satellite) or the core network. These policies can be used to determine whether communication can be established. This requires collecting and verifying the locations of both UEs and the mobile base station (e.g., satellite, UAV, ship, etc.). If, for example, all three devices reside in the same jurisdiction, a communication link can be established.

[0287] Summary: NTN - The process for secure UE-satellite-UE communication about Figure 141404 and / or 1402 may have already established AS security with 1401 and 1403. A security key can be used to protect RAN services between the first UE 1402 and the second UE 1404. However, no security key is available to protect end-to-end services between 1401 and 1403, for example, considering that this end-to-end service corresponds to a PDCP communication link according to TS 38.323.

[0288] Therefore, in the embodiments of the invention shown above, which can be combined with other embodiments or used independently, 1402 and / or 1404 can act as a key distribution center (KDC) responsible for managing and configuring 1401 and 1403 using key materials for UE-to-UE communication via 1402 (e.g., key materials for user plane communication via 1402 and used, for example, in the PDCP layer). The key materials may include integrity keys and confidentiality keys, which can be distributed via RRC messages sent by 1402 / 1404 to both 1401 and 1403. The messages may include configuration parameters such as sequence number, MAC-I usage, COUNT value, key ID (e.g., K_NRP-sess ID), key type (integrity or confidentiality), or key value. These keys can be bound to communication links established and enabled via 1402, such as PDCP communication. When the KDC distributes keys, it can also distribute additional security parameters, such as the algorithm selected for the communication link. These security parameters can be selected by the core network; for example, 1405 can determine them based on the type of communication to be established via 1402. The KDC is also responsible for rotating keys; for example, when a counter is about to reach its maximum value, the KDC is responsible for distributing a new, updated key. These keys can be randomly calculated, or they can be derived deterministically from some root keys. In this case, since the communication is between 1401 and 1403, and each of them can have some root key material K at the access device (e.g., K_gNB in ​​5GS), the aforementioned key can be derived from said key using a key derivation function.

[0289] In relevant embodiments of the invention, these keys can be managed by core network functions (e.g., 1405 (e.g., 1405 becomes a KDC)) and can be distributed to 1401 and 1403 protected with NAS keys. This has the advantage of ensuring which UEs can establish connections along with the non-fully trusted mobile access devices used, as they may be unable to eavesdrop on, inject, or modify services (because they lack the corresponding keys).

[0290] In relevant embodiments of the present invention that can be used in combination with other embodiments or independently, the condition for triggering a key update may be a change / switching of the mobile access device 1402 acting as a relay between UEs 1401 and 1403, i.e., a path switch. For example, refer to Figure 16 Initially, mobile access device 1602-1 enables communication between UEs 1601 and 1602. At a later point in time, mobile access device 1602-2 may become better positioned to maintain the communication link. Therefore, the handover process can trigger an update or renewal of the established or distributed key.

[0291] In relevant embodiments, the NTN Key Management Function (NKMF) can act as a KDF and serve as an entity for implementing key distribution for UE-to-UE communication. For example, similar to other embodiments, the NKMF can distribute root key material, which can allow the establishment of secure links that reuse procedures in TS 33.503, for example, for direct communication when the mobile access device is operating in transparent mode in the user plane.

[0292] In relevant embodiments of the present invention, and referring to Figure 16 A mobile access device (e.g., 1602-1) can provide a second mobile access device (e.g., 1602-2) with security context (e.g., security keys, one-time values, timers, etc.) related to UE-UE communication, which can then enable communication between UE 1601 and UE 1602. Alternatively, at least one of the UEs can trigger security context retrieval on demand by transmitting a protected link / context / path identifier transmitted to the first mobile access device 1602-1 to the second mobile access device 1602-2. After verification and link identification, the first mobile access device 1602-1 provides the security context associated with the link to the second mobile access device 1602-2.

[0293] In another embodiment of the invention, the security material for end-to-end protection of UE-UE communication can be based on a root key distributed by the mobile access device and a set of (random) parameters delivered to the UE by the network, for example, via a protected NAS message, such that an encryption and / or integrity security key is derived based on a Key Derivation Function (KDF), which takes the root key delivered by the mobile access device and randomized configuration parameters allocated by the network as input. Alternatively, the root key can be allocated and distributed to the UE by the network, for example, via a protected NAS message, while the randomized configuration parameters are distributed by the mobile access device or generated and exchanged by the UE via the mobile access device. In the latter option, updating / refreshing the encryption / integrity security key can be as simple as providing the UE with new randomized configuration parameters or an instruction to generate and exchange new randomized configuration parameters to derive a new security key based on the same root key already provided by the network.

[0294] In TS 38.323, the parameter included in the PDCP communication link is described as the K_NRP_Sess ID. Therefore, in a relevant aspect of the invention, the key configured by the KDC (e.g., 1402, 1404, or 1405) is K_NRP_Sess, which is then used by UEs 1401 and 1403 to derive NRPEK and NRPIK according to TS 33.536. Additionally or alternatively, K_NRP can also be configured by the KDC, and the new K_NRP_Sess can be derived, for example, based on section 5.3.3.1.4.3 of TS 33.536 or (e.g., based on section 5.3.3.1.4.4 of TS 33.536), for example, when a triggering event occurs.

[0295] In the relevant embodiments of the invention illustrated by the above process, the KDC can be distributed. For example, when more than a single core network function may be involved, such as when UEs 1401 and 1403 are connected to two different 1405 entities (AMFs), these entities may need to interact to agree on keys for securing communications on 1402. For example, a first AMF (e.g., the one initiating the communication) could be responsible for generating / determining the keys and then sharing them with a second AMF (e.g., the one receiving the communication). A similar distributed KDC can be applied when two 1402 entities are involved, such as... Figure 15 As shown, two mobile access devices 1502-1 and 1502-2 communicate with each other to enable communication between user equipment 1501 and 1503. In this case, the first mobile access device (e.g., 1502-1) can act as a KDC and share the generated key with the second mobile access device (e.g., 1502-2).

[0296] In some use cases, communication between two UEs on a mobile access device is established / initiated by exchanging SIP invitation requests. This can result in the establishment of an IP communication link between the two UEs via the mobile access device. Therefore, in embodiments that can be used in combination with other embodiments or independently, the IP communication link between the two UEs is protected by IPSec and / or TLS and / or MPQUIC and / or MPTCS. This may require configuring key materials (e.g., pre-shared keys or digital certificates) in the terminal devices so that they can authenticate each other and verify their communication authorization. This configuration can be done by a RAN device (e.g., 1402) or a CN function (e.g., 1405) or an AF (e.g., from the IMS network).

[0297] In embodiments that can be used in combination with other embodiments or independently, MPTCP and / or MPQUIC can be used to implement UE-UE communication, wherein one of the paths can be through a first mobile access device, and a second path can be through a second mobile access device or through a terrestrial access device.

[0298] In embodiments that can be used in combination with other embodiments or independently, the mobile access device (e.g., 1402) may include a lawful interception function that allows the interception of communication between two UEs. The lawful interception function may access key materials, such as those described in previous embodiments, or access the location of device 1402, or the locations of UEs 1401 and 1402. The lawful interception function may also include a policy for determining when communication needs to be monitored, for example, by decrypting data exchanged between the UEs. The policy may also include functionality for blocking communication and / or sending the intercepted communication to a terrestrial LI function when an LI function on the mobile access device determines that the intercepted communication meets a given criterion (e.g., is classified as dangerous).

[0299] Summary: NTN - Configuration and Security Aspects of Handover Processes in Non-Terrestrial Networks According to Section 16.14.3 of TS 38.300, UE mobility in non-terrestrial networks under different RRC states (i.e., RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED) follows the same principles as mobility and state transitions in terrestrial networks, with few additions (e.g., conditional HO) specific to NTN scenarios. Although the time an NTN gNB can serve a UE in a tracking area is limited and depends on whether the area is outside TN coverage, the frequency of handovers performed by a UE when served by an NTN gNB may be significantly higher than in TN handover cases. Furthermore, in addition to conditional handovers (CHOs) that can be performed by a UE due to time- or location-based triggering, Section 16.14.4 also describes feeder link handovers (i.e., changes in the feeder link from the source NTN gateway to the target NTN gateway), which can result in the transmission of the UE's established connection between two NTN gNBs (i.e., the transmission of the UE's context via NG- or Xn-based handovers). Clearly, the UE's security context will be transferred more frequently between serving NTN gNBs, and due to numerous events / triggers that may invoke such transfers / HOs, synchronization problems and / or key mismatches (e.g., between the UE and the target gNB) may occur. Furthermore, if multiple handovers occur between several gNBs within a short period, the security key may need to be updated without using the security key in some cases. Therefore, the following embodiments aim to address these issues.

[0300] In one embodiment, the NTN gNB (e.g., the source NTN gNB) can estimate the time when it will no longer be able to serve the UE at a location / area, and therefore can schedule a handover to ensure minimal service interruption for the served UE. The NTN gNB can thus be (pre-)configured by the network with a secure time window that allows the source NTN gNB to select a suitable target gNB and / or trigger / use a Conditional Handover (CHO), request a CHO from a candidate target gNB, and provide the UE with the configuration and execution conditions of the CHO candidate cells, thereby allowing the UE to select its own target gNB. For example, UEs in a tracking area served by the NTN gNB can be provided with configurations to determine how long they can be served by the NTN gNB and the identity of the target NTN gNB. Based on the secure window configured in the gNB, the gNB can, for example, allocate time for triggering a handover procedure within the CHO. Network functions such as the AMF or NTN gateway can be responsible for configuring the time window.

[0301] In one embodiment, the source gNB may notify the target gNB in ​​advance of potential UEs it may need to take over. This may include, for example, the timing of events, and / or a list of UEs grouped by each timing window, and / or a list of UEs grouped by each HO timing. In a particular example, the source gNB may transmit a list of UE containers, each container containing a list of UEs, and wherein each container corresponds to a specific time window, allowing the target gNB to, for example, better manage its resources, and / or anticipate the number of UEs and / or messages (e.g., RRC messages) to be received from the UE set corresponding to the upcoming time window, and / or estimate the number of local identifiers to be assigned to UEs, etc. UEs in a container may be in a given location. The timing window that may be associated with a UE container may be synchronized and / or associated with timing parameters configured in the UE to perform a CHO.

[0302] In embodiments that can be used in combination with or independently of previous embodiments, the source NTN gNB can be configured to select the target gNB to which the UE hands over based on several criteria (e.g., estimated latency due to handover, UE mobility (e.g., direction, speed), estimated target gNB service time (e.g., a first target gNB candidate may already cover the UE's location, with 5 minutes remaining beyond the UE's range, while a second target gNB candidate may soon begin covering the UE's location), target gNB type (i.e., NTN or TN), UE measurement data, etc.). Alternatively or additionally, the NTN control function can determine which target gNB(s) the UE(s) should hand over to based on the aforementioned criteria and then transmit this decision to the source gNB. Target gNB selection may be subject to a network policy that determines how to select a target gNB based on candidate target gNBs and their selection criteria; for example, if the selection is between an NTN gNB and a TN gNB, where the UE moves in the direction of the TN gNB's coverage area, then a candidate TN gNB may have higher priority than a candidate NTN gNB. For example, if choosing between two or more candidate NTN gNBs, the candidate NTN gNB with the longest estimated target gNB service time and the smallest estimated delay due to HO can be prioritized. For this purpose, all this information needs to be provided to the NTN control function along with the policy. If the source NTN / target NTN is to make a decision, all this information, including the policy, needs to be made available to them.

[0303] In another embodiment related to the requirement that the UE must meet to connect to an NTN cell, according to Section 16.14.2.2, the UE should have a valid GNSS position, ephemeris, and common timing advance (TA), and calculate the frequency Doppler shift of the serving link and autonomously pre-compensate for it in uplink transmissions; otherwise, the UE should not perform any transmissions. In the event of a UE handover to a target NTN gNB, if the UE cannot synchronize with the target gNB and cannot perform any transmissions within the (pre)configured time window, the UE can notify the source gNB so that the latter (re)selects another target gNB, and / or if it is a conditional handover, the UE can select another candidate target gNB to connect to. This has the advantage of reducing UE downtime. In other words, when the UE cannot successfully move / connect to a target gNB, the UE needs to notify the source gNB of the situation / failure reason / connection characteristics. This can facilitate the selection of different target gNBs.

[0304] In another embodiment, which can be combined with other / the above embodiments, the source gNB may be configured with a secure time window that may include and / or consider the time period during which the UE attempts to connect to the target gNB. The source gNB may, for example, start a timer when sending an RRCReconfiguration message to initiate a HO, and may instruct and / or configure the UE to perform as many attempts as possible to establish a connection with the target gNB, for example, as long as the timer allows, and / or configure the UE to attempt a limited number of times. The time window and / or the number of attempts may also be configured by the network. The time window for the UE to attempt to connect to the target gNB may also be configurable, depending on the context of the gNB (e.g., the number of UEs it is serving and / or expects to serve). This time window may also be configured to achieve the desired performance (e.g., the percentage of successful handovers). The secure time window and time window / timer configured for the UE have the advantage of ensuring that, even if a connection to the selected target gNB is not established, the UE can still request the source gNB to assign a different target gNB.

[0305] In another embodiment related to processing security context and key materials, to optimize security material refresh and ensure that security materials are not updated when not in use, the UE may be configured by a network function (e.g., AMF) and / or by an access device (e.g., source gNB) to indicate to the target gNB (e.g., NTN or TN gNB) via a message, for example, in an RRC message, whether security materials (e.g., K_gNB) obtained from the source gNB have been used and whether they should be updated. Additionally or alternatively, this configuration may also be placed on the gNB, for example by the AMF or another network function, such that, in some cases, keys are not exported during handover (e.g., NTN handover). The transmission of the indication may be conditional; for example, the UE may be (pre)configured with a time window such that if multiple handovers occur consecutively within the span of the configured time window, the UE sends the indication to the target gNB. For example, the UE may be configured to send the indication when it detects that security materials from a previous HO have not been used. Alternatively, the UE may be configured to send the indication during any HO process. Additionally or alternatively, under certain conditions (e.g., unused keys), the source gNB may also inform the target gNB that a new key will not be exported during a handover (e.g., NTN handover). It should be noted that if the security material is not updated, the source gNB should inform the target gNB of other security parameters that should be used, such as encryption algorithms, counters, etc., to avoid the source and target gNBs reusing the same counter values.

[0306] In another embodiment relating to the processing of security context and key material, the UE may be configured to perform only vertical handover in accordance with section 6.9.2.1.1 of TS 33.501 when connected via an NTN network, as a means of ensuring forward security.

[0307] In another embodiment related to the processing of security context and key materials, the UE can be configured to perform only level handover in accordance with section 6.9.2.1.1 of TS 33.501 when connected via an NTN network, as a way to optimize performance and avoid interruptions due to N2 connection with the AMF when the AMF is not installed in the access device.

[0308] In another embodiment related to the processing (e.g., retention or refresh) of security key material, the constellation of the NTN access device can be used as a gNB-DU associated with a gNB-CU, which can be on the NTN access device's board or on the ground. The NTN access device (e.g., the gNB-DU) can be configured with a policy for determining whether and / or under what conditions security key material is retained and / or refreshed during a handover process between gNB-CUs. For example, if a K_gNB derived from the source NTN gNB is not used, the source NTN gNB can forward the K_gNB, which has its associated next-hop link counter (NCC), to the target NTN gNB according to the policy, regardless of whether the source NTN gNB has (or does not have) a new {NH, NCC} pair. Additionally or alternatively, the policy can be generalized / applied in a handover scenario between gNB-CUs, where the security key (e.g., K_gNB) is retained or refreshed under the same set of conditions and / or additional conditions defined by the network in the policy and / or determined by the NF (e.g., AMF). The policy may also include the maximum number of possible switches before key refresh becomes mandatory. Similarly, in the case of more frequent key refreshes, the policy may also determine the maximum number of horizontal key exports before requiring vertical key exports.

[0309] In another embodiment, which can be used in combination with or independently of previous embodiments, the processing of security key material (e.g., retention or refresh) can be based on an autonomous / dynamic process that can be supervised by the gNB-CU and / or NF (e.g., AMF), thereby based on criteria including but not limited to: the context of the service (e.g., location, time, access device load, UE type and / or whether it is resource-constrained, etc.), the type of expected handover process (e.g., intra-gNB-CU / inter-gNB-CU, N2), the availability of NTN / TN access devices and their resources, the freshness / validity of the key material, etc., the security key is retained or refreshed, and in the case of a security key refresh, the process determines whether it should be horizontally or vertically exported.

[0310] In another embodiment, the strategy regarding whether security key material can be reused may depend on the device type. For example, resource-constrained IoT devices that can be transmitted in an irregular manner may not require key updates.

[0311] In embodiments, there may be proactive transmission or export of (security) parameters, such as key material from a source gNB to a target gNB. This takes into account the scenario where the source gNB moves away from the UE and the target UE moves closer to the UE. This proactive transmission or export of parameters can be established by the source gNB well before it moves away from the UE being served in its coverage area. The proactive transmission / export of parameters can be based on negotiation between the source gNB and a potential target gNB, whereby the source gNB selects a suitable target gNB to which it can transmit the UE context and / or exported keys. The negotiation steps can specify: a time point or time window during which the transfer / handover is scheduled to occur, the number of UEs to be handed over, and which parameters associated with the UE (e.g., identifiers, key material) will be transferred and / or expected to be generated / exported, taking into account the target gNB's resources and capacity to serve the UE to be handed over. This allows the target gNB to be prepared for secure communication and ensures a smooth transfer of the UE. Similarly, the UE can also be configured and / or exported parameters, such as key material to be used when handing over to another gNB. When selecting a suitable target gNB and transmitting the necessary parameters (e.g., identifier / key) and determining the time for triggering the handover process, the source gNB can configure the UE with the parameters needed to derive the key material to be used during handover. This allows the UE to be ready for secure communication with the target gNB and ensures that the time required for configuration is minimized. This may require keeping a set of parameters ready but inactive. This may require including conditions or times for parameters to become active.

[0312] In another embodiment, the NTN gNB can serve many UEs distributed over a large area, and as the NTN gNB moves, it can perform group handovers, where a group of UEs within a geographic area and / or UEs sharing similar characteristics (e.g., the same RRC state) are handed over together to the target gNB. Thus, the source gNB can be configured to calculate and / or assign a group identifier (e.g., based on a concatenated or key derivation function (KDF) with certain parameters such as the input source and / or target gNB / cell ID, time value, number of UEs, etc.), which is transmitted to the UEs and / or the target gNB to identify the group of UEs being handed over.

[0313] In one example, similar to previous embodiments, information about UEs belonging to a group can be pre-transmitted from the source gNB to the target gNB. Then, when the handover time arrives, the source gNB transmits the group identifier to the target gNB to initiate a group handover in batches. For example, if the group of UEs to be handed over is large (i.e., in terms of the number of UEs), the UEs can be split into subsets / batches containing a configurable number of UEs, associated with a time window during which the UEs in the batch are expected to perform the HO procedure. Each batch of UEs can be assigned a group identifier associated with the time window during which the handover is scheduled to occur. The source gNB can proactively notify / transmit a list of group identifiers and the time windows associated with them to the target gNB, and / or transmit each group identifier as a trigger to indicate to the target gNB that the group of UEs associated with that group identifier will begin performing the HO procedure and is allocated X time units (e.g., 30 seconds) to complete the HO procedure. After completing a batch of HO (Hosting On) procedures for UEs, the target gNB can report the success rate (e.g., the number and identifiers of UEs that successfully handed over) and / or failure rate (e.g., the number of UEs that attempted to connect but failed) and / or information related to the target gNB's capacity to take over more UEs. The source gNB can rely on information reported from the target gNB and / or UEs that failed to hand over to assign those UEs to different batches of UEs, which have different group identifiers and / or different timing windows, to perform another HO procedure. In the event that the first target gNB is saturated (e.g., lacks sufficient resources to take over more UEs), the source gNB can also assign the remaining batches of UEs to another target gNB, in which case the selected target gNB is proactively notified of the batch(s) of UEs it should expect to take over, similar to the first target gNB. After the source gNB has already notified / configured the parameters required to handle the UE group to be taken over (e.g., (group) identifier, key material, time value, derivation parameter, etc.) to the target gNB in ​​advance, the source gNB can continuously and proactively organize / aggregate the UEs it serves into batches / groups / subsets. These batches / groups / subsets are switched to the target gNB in ​​batches within a predetermined time window and / or triggered on demand (e.g., by transmitting the group identifier to the target gNB).

[0314] Section: NTN - Virtual Switching In another implementation that can be used in combination with or independently of previous embodiments, a UE in a given area (e.g., a given tracking area) and served by an NTN gNB can be periodically served by different NTN access devices / gNBs, for example, operating in transparent or regeneration mode. Instead of requiring active handover due to the first NTN access device moving further away from a given area (e.g., a tracking area) and the second NTN moving closer to the area (e.g., a tracking area), and where the first NTN and the second NTN have different gNB / cell identities (PCIs), the NTN access device / gNB can be assigned / configured to use a given or generated transient identifier (e.g., it can be a physical cell identifier fixed to a given area, or it can be an identifier that depends on that area (e.g., tracking area, and / or timing value / window, and / or PLMN ID, etc.)). In this way, the second NTN access device can receive the UE identity, UE parameters, key materials, etc. of the UE currently being served by the first NTN access device / gNB, and take over the identifier (e.g., physical cell identifier / transient identifier) ​​and / or generate a fresh identifier (e.g., depending on the validity of the identifier received from the source / first NTN access device), at which point the first NTN access device can stop using the identifier (e.g., physical cell identifier or transient identifier). NTN access devices / gNBs can store multiple identifiers simultaneously, depending on the area they cover (e.g., the tracking area) and / or the PLMN they serve; additionally, multiple NTN access devices / gNBs can store similar transient identifiers simultaneously, for example, when there is overlap in the tracking areas covered by these NTN access devices. This has many advantages, such as: - Reduce the number of NTN access device / gNB identifiers visible to the UE in a given area (e.g., tracking area), ensuring that the identifiers remain constant as long as they are determined by, for example, a policy (e.g., where the identifiers are location-dependent (e.g., tracking area) and / or time-dependent), regardless of the physical device providing access; the UE may only know whether the NTN provides access at a given location and time, and which is the identifier of the access device providing access, but which specific physical access devices provide access is transparent. - The UE can generate the identifier of the NTN access device based on timing and location information (e.g., before transitioning to an inactive or idle state) to request service from the NTN access devices that previously served them and / or generate the identifier of the NTN access devices that previously served them.

[0315] - The target NTN access device / gNB, for example before it moves to an inactive state and based on ephemeris data, timing and location information and coverage status, identifies potential NTN access devices / gNBs that may already be serving the UE, determines whether to request UE context from one or more of these candidate gNBs and / or whether one of these potential source NTN access devices has already provided UE context to the NTN access device.

[0316] The aforementioned handover process can be considered as a “virtual” handover process designed to prevent the UE from seeing / changing the access device in a conventional manner.

[0317] In another embodiment, which can be used in combination with other embodiments or independently, the above-described "virtual" handover process can also be implemented using dual connectivity, where the first access device acts as the primary cell and the second access device acts as the secondary cell, and can facilitate, for example, synchronization with the second cell. Then, once the UE has synchronized to the second cell, the second cell takes over the role of the primary cell, and the (new) primary cell will facilitate synchronization with the new second cell. The UE always remains connected to the "same" primary cell, even if the physical device acting as the primary cell changes.

[0318] In another embodiment, which can be used in combination with other embodiments or independently, the aforementioned “virtual” handover process can also refer to the movement of certain functions from one device to another. For example, the AMF logic in a satellite can be moved from a source access device to a target access device, such that the AMF responsible for the service area remains constant over time. In the case of AMF, if the AMF remains linked to a given area, all handovers within that area can easily be vertical handovers.

[0319] In another embodiment, which can be used in combination with or independently of previous embodiments, since the target gNB requires the UE's I-RNTI to obtain the context of the UE in the RRC_INACTIVE state from the source gNB, for example, during group handover (e.g., where all inactive UEs are handed over to the target gNB), the source gNB may provide the target gNB with a list of I-RNTIs associated with the inactive UEs. The target gNB stores them, either entirely or partially. For example, since the NG-RAN node address index segment in the I-RNTI is the same in all UEs' I-RNTIs, the target gNB may only store UE-specific references and PLMN-specific information, as well as the NG-RAN node address index and / or another gNB identifier. Additionally or alternatively, the source gNB may communicate a group identifier to the target gNB, which is stored by the target gNB and can be used (e.g., along with timing and location information, ephemeris data, etc.) to resolve the identity of the source gNB. Upon HO confirmation of the target gNB (group), the source gNB can indicate to inactive UEs in that group, or UEs transitioning to an inactive state, that they are switching, for example, via RRC messages (e.g., RRCRelease and / or RRCReconfiguration messages). Assuming the target gNB has a list of UE identifiers and / or inactive UE group identifiers and / or source NTN access device / gNB IDs, the structure of the I-RNTI sent by the UE can be optimized / modified to exclude the NG-RAN node address index, which the target gNB typically uses to resolve the identity of the source gNB. It is noteworthy that, according to Annex F of TS 38.300, a full (i.e., 40-bit) I-RNTI includes either 20 bits or 16 bits allocated for the NG-RAN node address index (depending on the profile ID used), while for a short (i.e., 24-bit) I-RNTI, it is unclear how many bits are allocated for the NG-RAN identifier. Therefore, excluding the NG-RAN node index from the I-RNTI has the advantage of providing spare bits that can be used to carry more data associated with the UE-specific reference / ID (e.g., when using a short I-RNTI), thereby avoiding potential conflicts during group handover, and / or carrying other types of information (e.g., flags / indicators / identifiers), for example, when using a full I-RNTI.Furthermore, a list of inactive UE I-RNTIs and / or group identifiers and / or source gNB identifiers, and / or mappings between them, can be stored and passed from an NTN access device serving an area (e.g., a tracking area) to the next NTN access device that can serve the same area. This allows the UE to transmit its I-RNTI (e.g., in the absence of an NG-RAN node address index) and / or timing / location information associated with the time the UE was last served by the access device whenever the UE wakes up from its inactive state. This enables the NTN access device covering the area to obtain its context, such as whether the context is in storage, and / or to determine the potential source gNB serving the UE based on information provided by the UE (e.g., timing / location information), and thus request the UE context / parameters / keys from it, for example, the source gNB still storing the UE context / parameters / keys.

[0320] In another embodiment related to UE identification, within the cell, the C-RNTI is a unique identifier used to identify RRC connections and for scheduling purposes. According to Table 7.1-1 of TS 38.321, in addition to several other RNTIs, the C-RNTI is assigned values ​​ranging from 0001 to FFF2. Therefore, the number of available C-RNTIs that the gNB can assign to a UE is limited to less than 2^16 values. Furthermore, since the gNB can cover a larger area than the TN gNB in ​​an NTN scenario, and the NTN gNB can serve more UEs, a longer identifier, such as a 32-bit RNTI, may be required. It is worth noting that some RNTIs (e.g., C-RNTIs) can be used to scramble the CRC appended to the downlink control information (DCI). Thus, according to Section 7.3.2 of TS 38.212, a 16-bit RNTI (e.g., C-RNTI) is used to mask 16 LSBs (out of 24 bits) of the CRC. Therefore, a larger C-RNTI (e.g., 32 bits) (e.g., 24 MSB / LSB) can be used to completely mask the CRC appended to the DCI. Alternatively, only 16 LSBs of the CRC can be masked using 16 bits of the C-RNTI.

[0321] Summary: Location during NTN - "Virtual" handover process In some scenarios, the RF path between the UE and the base station can be switched from a first RF path to a second RF path to maintain or improve path quality. Since the connection remains the same at higher protocol layers (e.g., the identifiers used at different protocol layers do not change), such a path switch can be described as a "virtual handover," as the UE now communicates with the base station via a second radio interface instead of the first. In some cases, such as in an NTN configuration where the RF path switches from one satellite to another, the propagation delays on each path may differ significantly, and adjustments such as timing resynchronization may be necessary. In some cases, a "virtual handover" (VHO) can be initiated during the positioning process. If the positioning process is based on measuring propagation delays, such as round-trip time (RTT), a switch from one RF path to another with different propagation delays will have a significant impact on UE Rx-TX time difference measurements before and after the handover. DraftCRs in R4-2409287 to TS 38.133v 18.5.0 stipulate that if a VHO occurs during the measurement period and after SRS reconfiguration on the target cell is complete, the UE Rx-Tx time difference measurement period should be restarted. Therefore, when a UE performs a satellite handover using resynchronization during the measurement period, the UE should restart the UE Rx-Tx time difference measurement after SRS reconfiguration on the target cell is complete. In practice, similar issues can arise in traditional handover procedures when a UE switches to a second radio endpoint or base station. Similarly, propagation paths can have different lengths, and ongoing Rx-Tx time difference measurements can be interrupted by the switch. In NTN scenarios, this can occur, for example, when a UE switches to a satellite served by a different base station, or when the satellite itself moves from one base station to another due to its orbital motion, or in regeneration deployments when the base station itself is integrated into a satellite and the UE switches from one base station to another. Various TN arrangements can also cause this phenomenon, including but not limited to intra-RAN and inter-RAN handovers, sidelink relays (including multipath), etc. Typically, it can be expected that the UE will cancel any ongoing Rx-Tx time difference measurements before the handover and restart them once the handover is complete.

[0322] However, this leads to two main problems: First, the positioning process experiences increased latency. Secondly, the accuracy of the positioning process is reduced.

[0323] This is thanks to Figure 19Note that Case 1 refers to the normal multi-RTT positioning method, in which the UE and the mobile base station perform multiple RTT measurements M1, ... Mk at times t1, ..., tk, and thus at slightly different locations of the mobile base stations p1, ..., pk. Figure 19 Case 2 refers to a situation where the positioning process is interrupted during handover, and based on R4-2409287, the positioning process needs to be restarted. In this example, the UE and the first mobile access device (satellite A) begin the positioning process of one or more measurements M1, ... at times t1, ..., without completing it before the handover occurs. When the handover occurs, the UE and the second mobile access device (satellite B) perform multiple RTT measurements M1', ..., Mk' at times t1', ..., tk', and are therefore at slightly different locations from the second mobile base station p1', ..., pk'. This means that the UE's location can be obtained at a later time point, and most likely, the positioning accuracy will be lower because the second mobile access device (satellite B) performs the positioning process when it is furthest from the UE (because it may have just entered the UE's coverage area). Therefore, the object of the present invention is to solve the above-mentioned problems through the following embodiments.

[0324] In embodiments that can be used in combination with other embodiments or independently, the positioning process of a UE using a first mobile access device and a second mobile access device can be adapted to use measurements measured by the first mobile access device before the handover process and measurements measured by the second mobile access device after the handover process, wherein the handover process is a handover process from the first mobile access device to the second mobile access device. This is achieved through... Figure 19 Scenario C illustrates a first part of the positioning process where the UE and satellite A (typically the first UE and the first mobile access device) begin before the handover process. In this first part of the positioning process, the UE and satellite A perform *s* measurements M1, ..., Ms at times t1,...ts and locations p1',...,ps'. A handover is then triggered, which can be a virtual handover. Next, the UE and satellite B perform *ks* measurements Ms+1',...,Mk' at times ts+1',...,tk' and locations ps+1',...,pk' of the second mobile access device (satellite B). This process has two advantages: first, it avoids discarding measurements, resulting in reduced latency / increased UE battery life, etc.; second, the accuracy of the positioning process may be better because p1,...,ps (satellite A) and ps+1',...,pk' (satellite B) are far apart. This means that trilateration and / or triangulation methods can work more accurately.

[0325] In variations of previous embodiments that can be used in combination or independently, each measurement can be associated with a measurement time (e.g., recorded by the UE or mobile access device) and allows determination of which mobile access device participated in the measurement.

[0326] In another variation of the foregoing embodiments, which can be used in combination or independently, the UE can be configured to perform a positioning procedure using communication parameters to perform the positioning procedure with the first mobile access device and the second mobile access device before and after the handover procedure. The communication parameters may include a set of communication resources for performing the positioning procedure, timing of the positioning procedure, antenna parameters (e.g., beamforming), etc.

[0327] In another variation of the foregoing embodiments, which can be used in combination or independently, it may be advantageous to perform the positioning process using a first mobile access device and a second mobile access device adapted and / or configured and / or capable of using measurements taken by the first mobile access device before the handover process and by the second mobile access device after the handover process, wherein the handover process is a transition from the first mobile access device to the second mobile access device. For this purpose, the timing of the positioning procedure (e.g., the start of the positioning procedure) can be adapted to fit the point in time when the handover procedure (generally, given a communication procedure) is executed, with the goal of obtaining the most accurate location estimate with the fewest possible measurements. For example, as... Figure 19 As shown in case C, if a network function (e.g., a location management function (LMF)) requests / schedules a positioning process, for example, by sending a positioning request to a first mobile access device (satellite A), then an entity (e.g., the LMF itself and / or the AMF) and / or the first mobile access device and / or the second mobile access device and / or the UE) can adapt (e.g., delay) the positioning process by a given time T1 (e.g., T2 time units) before planning / performing a handover, such that the first part of the positioning process is performed via the first mobile access device, and the second part of the positioning process is performed via the second mobile access device. T2 time units are sufficient to perform M1,...,Ms measurements, such as... Figure 19 As shown in case C, it can make the k-(s+1) measurements performed by / with satellite B (second mobile access device) equal to the s measurements performed by / with the first mobile access device, and / or minimize the total number of measurements.

[0328] In embodiments that can be used in combination with other embodiments or independently, the positioning process is based on measuring the round-trip time (RTT) between the UE and the mobile access device. Each measurement is the RTT of the mobile access device at its current location p. The UE and the mobile access device exchange signals to measure the RTT, such as a positioning reference signal or a probe reference signal. The RTT measurements are used to estimate the distance between the UE and the mobile access device using trilateration and / or triangulation methods. The UE can perform RTT measurements with the first and second mobile access devices, respectively, before and after a handover process. The UE can send the RTT measurements to a location management function, which can use the RTT measurements and the known location of the mobile access device to calculate the UE's location. Alternatively, the UE can receive the location of the mobile access device from the location management function and calculate its own location based on the RTT measurements and the location of the mobile access device.

[0329] In another embodiment, which can be used in combination with other embodiments or independently, the UE and / or LMF and / or other entities (e.g., mobile access equipment) can determine how much measurement is needed for a more accurate positioning process (e.g., before, during, and / or after handover). For example, in Figure 20 In scenarios where a handover is performed from satellite A to satellite B, samples acquired from satellite A and satellite B might come from locations that are too close together (because satellite B enters the UE's coverage area from the same area where satellite A left its coverage area). This information (e.g., the location of the mobile access device at the handover point, the direction of movement at the handover point, ephemeris, etc.) needs to be considered to determine how many measurements are required after the handover. For example, if the target mobile access device enters the coverage area at a distance from the location used by the source mobile access device to perform the measurements (…),… Figure 19 In case C), the number of measurements performed by the target mobile access device may be lower (i.e., less than the number of measurements the source mobile access device would otherwise have to perform if it had already completed the positioning process). For example, if the target mobile access device enters the coverage area close to the location where the source mobile access device would have performed the measurements ( Figure 20 If the target mobile access device (MAG) performs a higher number of measurements (i.e., more than the number of measurements the source MAG would otherwise have to perform if the source MAG had already completed the localization process), then the number of measurements required by the target MAG may be higher (i.e., more than the number of measurements the source MAG would have to perform if the source MAG had already completed the localization process). This decision (regarding the number of measurements required by the target MAG) can be made by the LMF and / or the target MAG and / or the UE considering the available measurements and the locations where they are performed, as well as the locations where new measurements are expected to be performed. In some cases, the LMF and / or the UE and / or the mobile access device may also determine a second mobile access device (e.g., Figure 20When does the second set of measurements begin on satellite B? For example, a delay T3 can be introduced from the time of the handover operation until the start of measurements in the second set of measurements. This delay T3 can prevent the second mobile access device / UE from performing measurements at a location close to the previous location of the first mobile access device (and may add a little additional location information). This delay T3 can be transmitted to the second mobile access device and / or the UE, and / or determined by the second mobile access device and / or the UE. The second mobile access device and / or the UE can start a timer after the handover and start measurements when the timer reaches T3. Additionally or alternatively, the second mobile access device can transmit and / or determine areas where measurements should not be performed (e.g., a portion of its trajectory) (e.g., this can be determined by knowing the locations where the first set of measurements were obtained and excluding any locations that are too close to them (e.g., up to a threshold)).

[0330] Note that previous embodiments may have been implemented using different positioning technologies or combinations thereof, such as round-trip time measurement, angle of arrival, time difference of arrival, carrier phase-based methods, etc.

[0331] Typically, a method for determining the location of a user equipment, which can be implemented in the user equipment, has been proposed, wherein the method includes: - A first set of positioning measurements is obtained by performing a first part of a positioning process with a first access device, wherein the first set of positioning measurements includes one or more positioning measurements. - Perform a handover from the first access device to the second access device. - A second set of positioning measurements is obtained by performing the second part of the positioning process with the second access device, wherein the second set of positioning measurements includes one or more positioning measurements, and The location of the user equipment is determined based on the first and second positioning measurement sets, and / or the first and second positioning measurement sets are sent to the location management function.

[0332] In addition, a method for determining the location of a user equipment is proposed, comprising: obtaining a first location set with a predetermined number of measurements using the first access device at a predefined time and / or location before performing a handover from a first access device to a second access device.

[0333] Additionally, a method for determining the location of a user equipment (UE) is proposed, comprising: prior to performing a handover from a first access device to a second access device, obtaining a second location set with a predetermined number of measurements using the second access device at a predefined time and / or location. In an embodiment, the time and / or location for performing the measurements and / or the predetermined number of measurements are determined based on ephemeris data of the source and target mobile access devices, the UE's location, and / or the expected accuracy of the location estimation. This allows ensuring that the accuracy of the location estimation reaches a minimum threshold and / or that the latency in obtaining the location estimation remains as low as possible and / or that resource consumption is minimized.

[0334] Summary: Security Aspects of Dual-Connectivity on NTN (Non-Landline Networks) Section 6.10.2 of TS 33.501 describes the security procedures for dual connectivity between a primary node (MN) and a secondary node (SN). In both cases, it is assumed that the MN and SN are connected via the Xn interface. The MN generates a K_SN for the SN and sends it to the SN via Xn-C. To generate the KSN, the MN associates a counter, called the SN counter, with the current AS security context. The SN counter is used as a freshness input for KSN derivation, as described in Section 6.10.3.2. When a new K_SN needs to be generated, the MN sends the value of the SN counter to the UE via the RRC signaling path. The K_SN is used to derive further RRC and UP keys used between the UE and the SN. Figure 6 Steps 1-7 in .10.2.1-1 (security aspects of the SN addition / modification procedure (MN-initiated)) need to occur when the MN and SN (Mobile Access Device) arrive, for example, when the SN is reachable from the terrestrial NTN-gateway. At this stage, the SN is configured with a K_SN that allows the UE to perform a random access procedure with the SN. To this end, the MN should ensure that the SN maintains the connection long enough before sending / receiving RRC connection reconfiguration (steps 5 and 6) so that the MN can send a notification that the SN reconfiguration is complete (step 7).

[0335] If the process is initiated by the SN (Section 6.10.2.2.3), for example when the uplink and / or downlink PDCP COUNT is about to perform a wrapback against either the SCG DRB or the SCG SRB, the SN can be in S&F mode (due to being outside coverage). Therefore, instead of obtaining the updated K_SN via the MN, the SN can trigger a K_SN update via the UE, allowing it to obtain the updated K_SN via the UE, where the UE acts as a relay forwarding the updated K_SN from the MN. For example, the UE can provide the SN with a new K_SN protected in an RRC message. Alternatively, the MN may have already configured a key K' for the SN to use in this situation, such that if the MN and SN are not directly connected, but can be connected via the UE, the MN can provide a new K_SN protected with K' (in terms of confidentiality and / or integrity).

[0336] Section: NTN - AMF as part of mobile access equipment The 4G Mobility Management Entity (MME) is divided into the 5G Core Access and Mobility Management Function (AMF) and the Session Management Function (SMF). The AMF receives all connection and session-related information (N1 / N2) from the User Equipment (UE) and is responsible for handling connection and mobility management tasks. All messages related to session management are forwarded to the Session Management Function (SMF) via the N11 reference interface. Since mobile access devices, such as satellites, remain mobile, the following advantageous embodiment proposes that the mobile access device is responsible for the connection with a specific UE (e.g., an IoT device), and the AMF (or MME) is part of the mobile access device; for example, entity 1405 may be part of 1402. This embodiment can simplify certain use cases, such as cellular IoT. For example, based on section 6.16.1.1 of TS33.501, the 5GS CIoT control plane is optimized for exchanging small user data or SMS as the payload of NAS messages in both the uplink and downlink directions. The UE and AMF use a NAS connection-specific NAS security context to perform integrity protection and encryption on the small user data or SMS. If the AMF is integrated into the mobile access device, the mobile access device can securely handle the distribution / reception of IoT data without requiring a feeder link for each message exchange with the IoT device. This also simplifies the handling of radio failure events (Section 6.16.1.2) and the RRCConnection reconstruction process because the same physical entity has the (NAS) key used to verify the message. Alternatively, if the AMF is located on Earth, the connection / link between the mobile access device and the AMF may fail, making this process potentially not always functional. As a result of this configuration, the UE (e.g., an IoT device) might only be in coverage when the mobile access device is nearby, which, for LEO mobile access devices, might be every few hours. This scheduling can be configured in the UE so that it knows when it must wake up and (re)connect. In some cases, the UE might only need to wake up and perform the transmission.

[0337] In some cases, such as those indicated in S3-240701, the AMF function can be divided into at least one ground AMF function residing in a ground station and at least one airborne AMF function residing in an access device.

[0338] Satellites can operate in store-and-forward mode, which can make using a terrestrial AMF difficult. To mitigate this issue, in embodiments that can be used in combination with other embodiments or independently, the mobile access device can operate in store-and-forward mode; that is, it may not have a continuous connection to the terrestrial AMF, or it may encounter high-probability gaps or interruptions in its connection with the terrestrial AMF. In this case, the airborne AMF can perform its CIoT functions, such as exchanging small user data or SMS with the UE via NAS messages. The airborne AMF can also track keys, one-time values, counters / timers, etc., used for each UE and update them accordingly. Once the mobile access device establishes a connection with the terrestrial AMF, it can resynchronize keys and other security parameters with the terrestrial AMF and report any user data or SMS exchanged in store-and-forward mode. In this way, the terrestrial AMF can maintain a consistent view of the security context and session state of the UEs served by the mobile access device.

[0339] Summary: NTN - Further Legitimate Interception Aspects In another embodiment of the invention related to lawful interception (LI) requirements, the setting of security materials (e.g., security keys, one-time values, counters / timers, etc.) may be dependent on or coordinated with the NF responsible for ensuring LI requirements are met, whereby the security key is provided to the LI_NF, and the network sets the security materials to the UE only upon receiving an acknowledgment from the LI_NF. Similarly, the mobile access device may provide the LI_NF with any additional configuration parameters used in the derivation of the security key (e.g., encryption / integrity key), whether these parameters are exchanged between UEs via the mobile access device or distributed by the mobile access device itself, for example, to enable UE-to-UE communication on the mobile access device. The mobile access device may provide the LI_NF directly or through an NF in the core network (e.g., AMF, etc.) to manage these keys.

[0340] Mobile access devices can be deployed / moved to different countries in such a way that when the mobile access device is within the jurisdiction of the corresponding country, it may be necessary to make all keys or data stored in the mobile access device accessible to the LI authority. To avoid this, in another embodiment that can be used in combination with other embodiments or independently: 1) The serving network, home network, or mobile access equipment provider may need to switch UE communications from a first access device (which is about to leave the country’s jurisdiction) to a second access device (which is still in the country’s jurisdiction), where the switching condition may be the fact that the first access device is about to leave the country’s jurisdiction or has already left the country’s jurisdiction.

[0341] 2) The event that the first access device is about to leave the national jurisdiction can also further trigger the removal of any stored data (e.g., user data or control data such as keys) stored in the mobile access device when the mobile access device is operating in (store and forward) S&F mode. This can also be applied to information stored in the mobile access device when the mobile access device is operating in a regenerative (base station) mode or includes some core network NF (such as the AMF described in other embodiments).

[0342] 3) The event that the first access device is about to leave the national jurisdiction can also trigger an update of the key material (e.g., AS context or NAS context). For example, the access device can indicate to the UE that the current access device root key material needs to be changed (e.g., by indicating the change of K_gNB in ​​5GS via HO ​​command message).

[0343] 4) The event that the first access device is about to leave the national jurisdiction can also trigger the first access device to send an indication to the UE (e.g., the connected UE) via SIB (e.g., SIB1 or SIB19) or RRC message, so that the UE can take the information into consideration to perform, for example, condition handover, path handover, cell reselection, etc.

[0344] The policy based on the above conditions (i.e., the first access device is about to leave the national jurisdiction) can be configured by the network operator in the network function (e.g., AMF) of the core network, in the first access device itself, or in the UE served by the first access device. The policy can specify the specific action to be performed when the condition occurs.

[0345] Based on the above embodiments, draft_s3i 240059 introduces definitions and requirements for location-related interception of NTN and mobile base stations, including the following definitions: • Interception Area: The geographical area where Location-Related Interception (LDI) is applied. It is defined by the protocol between the LEA and the Communication Service Provider (CSP).

[0346] • Location-related interception: Interception depends on the target location and / or additional contextual information, such as the vessel’s country of registration (if available) or additional territorial requirements (e.g., international maritime and aviation zones), in order to allow the CSP system to determine the applicable interception jurisdiction.

[0347] • Mobile cell: A cell whose coverage area generally moves relative to the Earth's surface. For example, such a cell can be in mobile facilities such as trains, ships, or airplanes, or in a satellite.

[0348] These lead to new requirements consistent with the embodiments described above: • R 6.3-276 Mobile Cell Identification - The CSP shall be able to report when a cell is mobile and what type of facility the cell is located in.

[0349] • R 6.3-277 Cell Mobility Identification - The CSP should be able to report in near real-time when the coverage location of a mobile cell changes.

[0350] • R 6.3-278 Mobile Cell Mapping - The CSP should be able to provide the geographic location of the mobile cell when reporting events, either periodically or as required by the LEA.

[0351] • R 6.3-279 Location of Mobile Cell - If the base station is located on a ship, the geographical location of the ship will be reported. If the base station is located on a high-altitude platform, the geographical location of the center of the cell's coverage area will be reported, taking into account the size indication of the coverage area.

[0352] • R 6.3-290 Trusted / Untrusted Locations - The location information reported to the LEMF should be location information trusted by the 3GPP network (i.e., the location information is provided or verified by the 3GPP network), if available. The CSP should also be able to report and verify possible locations using network location information from untrusted sources (e.g., provided by user equipment).

[0353] • R 6.3-600 Location verification for NTN - The CSP should be able to verify GNSS coordination reported by the UE when connecting via NTN.

[0354] • R 6.3-700 NTN positioning accuracy - The granularity of the location information verified by the network should be at least comparable to that of the terrestrial network.

[0355] • R 6.5-20 Interception Temporary Reduction - CSP should be able to pause during the interception period (e.g., when roaming out of the station internationally or crossing the interception area boundary in the case of LDI) and restore all or part of the mandatory interception artifacts.

[0356] • R 6.5-90 Location-Related Interception Management - The CSP shall be able to continuously monitor the location of a target during ongoing communications or in response to any mobility management event, and deliver the intercepted product to the applicable jurisdiction when the target is within an Interception Area (IA). For location-related interception scenarios, mutual lawful assistance may be applied between LEAs.

[0357] • R 6.5-100 Location and Context-Based LI Policies - The CSP should be able to permanently locate each target in a trustworthy (verifiable, reliable) manner with sufficient accuracy in order to determine policies based on jurisdictional requirements. Applicable policies can be defined based on UE location, network-based location, and context (e.g., ship or aircraft flags).

[0358] • R 6.5-200 Location in Non-Land Networks - The CSP should be able to obtain and report the UE location with similar granularity to that in terrestrial networks.

[0359] Related to R6.3-279, if the LI management authority / LI NF obtains the location of a mobile cell and the mobile cell is about to cross the interception area boundary, for example, leaving the jurisdiction of one country and entering the jurisdiction of another country, the LI management authority / LI NF may have deployed configurations or sent requests to the CSP to trigger some of the actions in the above embodiments.

[0360] Similarly, R 6.5-20 can also trigger some of the actions described in the above embodiments, such as removing keys that might otherwise end up in different countries / interception zones.

[0361] In another embodiment, which can be used in combination with other embodiments or independently, the mobile access device can be configured to implement UE-UE communication, wherein the communication is performed by the mobile access device. In this case, the mobile access device may need to maintain a record of the exchanged data on the user plane (e.g., through a strategy as in other embodiments). This strategy may include how long the data should be stored and to which jurisdiction it belongs. Data can be downloaded automatically or based on the strategy to a terrestrial database in the jurisdiction where data is exchanged and erased from the mobile access device, particularly if the mobile access device moves out of the jurisdiction where data is exchanged and / or upon receiving a reception acknowledgment from a terrestrial LI station.

[0362] In another embodiment, which can be used in combination with other embodiments or independently, a Lawful Interception (LI) Network Function (NF) can be deployed in a mobile access device (e.g., an NTN access device) to monitor communications between a first UE and a second UE via IMS services. The LI NF can determine, based on policies or configurations, whether communications are subject to interception by a group of LI Authorization Agencies or the LI NF, or whether communications are stored and forwarded only at a later point in time. For example, policies or configurations can specify criteria for identifying communications that need to be intercepted, such as the UE's identity, the type of IMS service, the location of the mobile access device, the content of the communications, etc. The LI NF can also determine, based on policies or configurations, whether communications can continue or be terminated in critical situations such as impending threats, legal violations, or national security concerns. If communications meet the interception criteria, the LI NF can send an alert to the LI agencies or the LI NF group and can share the communication data with them without delay. Alternatively, the LI NF can store the communication data locally in the mobile access device and periodically or on request forward the communication data to the LI Authorization Agencies or the LI NF group when a connection is established with them. If a policy or configuration indicates that communication should be terminated under critical conditions, the LI NF can also stop communication between UEs.

[0363] In another embodiment, which can be used in combination with other embodiments or independently, when a mobile access device serving or already serving the UE crosses national jurisdictions, the UE's HPLMN (Home Public Land Mobile Network) may need to perform a new master authentication with the UE to ensure that the key is not disclosed. This may occur because the UE performed a previous handover to another (new) mobile access device, and the previous (old) mobile access device moved to another area that may comply with different laws. For example, the HPLMN may send a request to the UE to initiate a new master authentication process via the new mobile access device, or the UE may detect a change in the location of the mobile access device and trigger a new master authentication process itself. After the new master authentication process is completed, the old key material may be discarded by the UE and the HPLMN. In this embodiment, the HPLMN may need to be configured with the ephemeris of the mobile access device, such as satellites, or the UE may need to notify the HPLMN of its handover process so that the HPLMN can determine when the mobile access device crosses national jurisdictions.

[0364] Summary: NTN - When in relay devices / mobile access devices with store-and-forward capabilities or in multiple networks Modifications to primary authentication and communication during execution. In some scenarios discussed herein, such as in an NTN scenario where the first UE 100 attempts to register with the network and / or perform master authentication via a mobile access device (e.g., an NTN access device (e.g., satellite or other mobile access device 123)), where the store-and-forward (S&F) function is invoked (e.g., due to a lack of link with the NTN gateway), the registration and / or master authentication processes may fail to execute successfully, or messages from different registration and / or master authentication processes may be mixed. Recall that the goal of the master authentication (and key negotiation) process is to achieve mutual authentication between the UE and the network and to provide key material that can be used between the UE and the service network in subsequent security processes. Master authentication is described in TS 33.501. In these scenarios, the following embodiments can be considered, wherein (1) are described in the context of NTN, but they can also be applied to other (mobile) access devices with store-and-forward capabilities, and (2) the term master authentication also includes initial signaling for registration in the network: In embodiments that can be used in combination with other embodiments or independently, a first NTN access device (e.g., mobile access device 123 (e.g., satellite)) that may not have access to an NTN gateway can relay UE messages to a second NTN access device that has a link established with the NTN gateway and therefore has an AMF that can assist in performing primary authentication with the UE's HPLMN. Whether the first NTN access device is allowed to relay the UE's registration / authentication messages to another satellite may be subject to the (pre)configuration of the network and / or on demand (e.g., by explicit indications included in messages transmitted by the UE).

[0365] In embodiment variations that can be used in combination with other embodiments or independently, the UE (e.g., first UE 100) may provide auxiliary data (e.g., ephemeris data, estimated time windows for UE service, whether or when the link with the UE is still active, and UE location, speed, and direction information, if provided by the UE) to the network (e.g., AMF) via the NTN access device (e.g., mobile access device 123) or NTN access device gateway (e.g., at RAN 106) that initiated the authentication process (e.g., via a registration request) or via another NTN access device (e.g., satellite) to the network (e.g., AMF). Based on this information, the NTN access device or network function (e.g., AMF) may determine whether to perform / continue the initiated primary authentication on the NTN access device, select another TN / NTN access device, cache messages / requests until a link with the UE can be established (e.g., via another NTN access device), or discard the authentication process. Specifically, the core network (e.g., AMF) can determine that the initiated authentication procedure is unlikely to succeed due to the satellite's connectivity status, and the core network (e.g., AMF in conjunction with UDM) can trigger or schedule a subsequent network-triggered primary authentication when NTN...

Claims

1. A method for operating a device to manage a connection, wherein the method includes: The device checks or selects the preferred authentication process; The device performs the preferred authentication process with the first core network via the first access device; as well as The device establishes a connection with the first core network.

2. The method according to claim 1, comprising: The device receives a command from the first core network through the first access device to establish the multipath connection on the first access device and the designated access device and / or the second core network using a set of configuration parameters for the multipath connection. If the device is not already connected to the designated access device and / or the second core network, then the device is connected to the designated access device and / or the second core network. as well as The device initiates a multipath connection for one or more services on the first access device and the designated access device and / or the second core network by applying the set of configuration parameters.

3. The method according to claim 1, comprising: The device receives a command from the first core network via a first access device to establish the connection using a set of configuration parameters for the connection via a specified access device; If the device is not already connected to the designated access device, then the device connects to the designated access device; as well as The connection for one or more services is initiated through the designated access device.

4. The method according to claims 2 and 3, comprising: The device uses a first SIM to perform the preferred authentication process with the first core network, and uses credentials in a second SIM to connect to the designated access device and / or the second core network.

5. The method according to claim 2 or 3, wherein, The set of configuration parameters includes one or more of the following: Access information, which includes parameters for a random access procedure, including the timing or location or physical cell identifier of the specified access device; The operating modes of the specified access devices (such as regeneration mode, transparent mode, or hybrid regeneration / transparent operating mode, and store and forward mode); The storage time used by the specified access device in store-and-forward mode; Key materials, such as keys connected to the designated access device; Key materials, such as keys used for communicating with the first user equipment through the designated access device; IP addresses for different communication paths; Details of a combined PDU session or a multi-address PDU session; Settings for roaming guidance information for dual-guide devices; The congestion status of different paths in the multipath communication and / or the communication path segments in the multipath communication; Congestion windows for different paths in the multipath communication and / or for communication path segments in the multipath communication; Round-trip time for different paths in the multipath communication and / or for communication path segments in the multipath communication; Methods for determining round-trip times; Methods for scheduling groups; as well as The connection is applicable to the services.

6. The method according to claim 2, 3, 4, or 5, wherein, The apparatus for connecting to the designated access device includes: performing primary authentication with an airborne core network component and / or by means of key material received in the configuration parameters, wherein the key material includes an authentication server key and / or a network access server key.

7. The method according to claim 2, 4 or 5, comprising the aforementioned apparatus: The first access device exchanges a first token with the first core network. The second token is exchanged between the designated access device and the second core network of the designated access device.

8. The method of claim 7, comprising: The device checks the first token and the second token to verify the establishment of the multipath connection.

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

10. The method according to claims 7, 8, and 9, wherein the first token and / or the second token comprises one or more of the following: A unique identifier (DS_identifier) ​​generated by the first core network or the device. The first subscriber's permanent identifier, SUPI, is authorized to assume a role (such as primary or secondary). The role that the service network is authorized to assume One or more SUPIs or other identifiers, such as GUTI, can be associated with the primary / secondary SUPI. With the help of the services available by dual-boot connection, The conditions for providing the service (e.g., given UE location), or Wireless access technologies (RATs) capable of being used for a given connection (e.g., primary or secondary connection in a dual-boot connection).

11. The method according to claims 1 and 2, comprising: The device receives or is configured with a first SIM. Obtain the first PIN for the first SIM. Unlock the first SIM using the first PIN. Verify the presence of a peer SIM that has been inserted or configured in the device. Adjusting enabled communication parameters based on the peer-to-peer SIM authentication, and The enabled communication parameters are applied when checking and executing the preferred authentication process.

12. The method according to claim 11, wherein, The device supports at least three types of enabled communication parameters: Only in emergencies, where the device cannot detect the presence of the peer SIM inserted into the same mobile device and the first SIM contains a secondary SUPI. Standard UE, wherein the device cannot detect the presence of the peer SIM inserted into the same mobile device and the first SIM contains a primary SUPI, and A dual-boot UE, wherein the device is capable of detecting the presence of the peer SIM containing a secondary SUPI inserted into the device, and the first SIM contains a primary SUPI.

13. The method according to any one of claims 2, 4, 5, 6, 7, 8, or 9, comprising: The device initiates an application-specific authentication and key management (AKMA) process by sending a first AKMA request on the first access device and running the Ua protocol on the first access device and the designated access device and / or the second core network based on the key material bound to the first core network of the first access device.

14. The method according to claim 2 or 3, comprising: The device uses a first SIM to perform the preferred authentication process with the first core network, and uses credentials in a second SIM to connect to the designated access device and / or the second core network.

15. The method according to claim 14, wherein, The method includes selecting a first voucher and a second voucher from a set of two or more vouchers.

16. The method according to claim 2, 3, 14 or 15, comprising: The device determines, through a policy, the designated access device and / or the second core network to which the connection will be directed, wherein the routing depends on the service QoS of the first core network through the first access device.

17. The method of claim 15, wherein each of the two or more credentials is linked to a corresponding subscription, the corresponding subscription indicating whether the corresponding subscription can be used as part of a dual-boot connection and the conditions of use.

18. The method according to claims 2 and 14, wherein, The configuration parameters include the identifier of the multipath or dual-boot connection.

19. The method according to claim 1, 2 or 3, comprising: The device receives an indication of the operating mode of the first access device or the designated access device, the indication including at least one of the following: Regeneration mode, transparent mode, or hybrid regeneration / transparent operation mode, and store and forward mode; and The storage time used by the specified access device in store-and-forward mode; When performing the authentication process and / or establishing the communication connection, the device selects appropriate communication parameters based on the indication of the operating mode.

20. The method according to claim 1, 2 or 3, comprising the apparatus: The fields in the message of the preferred authentication process include an authentication process identifier and / or a timing value; and The fields are used to distinguish messages from different security procedures and / or to determine whether a received message has been stored by the access device.

21. The apparatus according to claim 1, 2, 3, 19 or 20, wherein at least one of the following conditions applies to the preferred authentication process: - If the device is configured with a policy or configuration to enable the preferred authentication process, the preferred authentication process can only be performed on the access device in store-and-forward mode; - The preferred authentication process includes an indication of whether the authentication process is or can be performed by an access device in store-and-forward mode; - NAS registration requests or NAS attach requests should not be initiated on a second NAS connection with mobility capabilities to the same network before primary authentication is completed on the first NAS connection, unless the first NAS connection is completed, for example, through a mobile access device with storage and forwarding capabilities; as well as - The main authentication message includes a timer value or identifier.

22. The method according to any one of claims 1, 2, 3, 5, 19, 20 or 21, comprising the said apparatus: Initiate a communication link with a remote user equipment or receive a request to establish a communication link with the remote user equipment; as well as The communication link is established using the first access device and / or the selected access device as a relay. The device communicates with the remote user equipment using the relay in a transparent mode, a regeneration mode, or a store-and-forward relay communication mode.

23. The method of claim 22, wherein, The initiation of the communication link is performed via a SIP INVITE message to the IMS network, and the communication with the remote user equipment is performed in the user plane.

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

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

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

27. The method according to any one of claims 1, 2, 6, 19, 20, 21, 22 to 26, comprising the means receiving an authorization for establishing the communication connection with the first access device or a selected access device, or through the first or selected access device, based on at least one of the following: - User subscriptions - Type of communication connection - Whether the device can be connected to a ground-based RAT, and - The location of the device and / or relay and / or remote user equipment.

28. The method of claim 3, comprising: When the first access device moves outside the current legal interception jurisdiction or the restricted area where the device is located, the device connects to the designated access device and disconnects from the first access device.

29. The method according to claims 2, 3 and 28, wherein, Connections to the designated access device and / or the second core network are only permitted if the legitimate interception requirements are verified and the configuration meets those requirements.

30. The method of claim 3, comprising: The device stores a configuration for determining whether a key needs to be exported and for specifying the time point for key export when connecting to the designated access device. Wherein (1) the key refers to a new access layer AS key or a dual-connection key, and (2) the specified time point before the device establishes the connection.

31. The method according to claim 3, comprising: The device synchronizes with the designated access device, wherein the designated access device acts as a secondary cell, and the synchronization is accomplished by means of signaling from the first access device, which acts as the primary cell.

32. The method according to claim 3, comprising: The device receives a set of positioning configuration parameters for determining positioning measurements to be obtained from the first access device and the designated access device. The device obtains a first set of positioning measurements by performing a first part of a positioning process with the first access device, wherein the first set of positioning measurements includes one or more positioning measurements. - The device performs a handover from the first access device to the designated access device or a cell handover. - The device obtains a second set of positioning measurements by performing a second part of the positioning process with the designated access device, wherein the second set of positioning measurements includes one or more positioning measurements, and - The device determines the location of the user equipment based on the first location measurement set and the second location measurement set, and / or sends the first location measurement set and the second location measurement set to the location management function.

33. The method according to claim 3, comprising: - The device receives an SIB or an RRC message broadcast by the first access device and / or the designated access device, wherein the SIB or RRC message determines the operating mode of the first access device and / or the designated access device, wherein the operating mode is one or more of the following: -Storage and forwarding mode, -Transparency mode -Regeneration mode, - Transparent / Regenerated Hybrid Mode The device selects the preferred authentication process based on the determined operating mode.

34. The method according to claims 3 and 33, comprising: The device determines the conditions under which it is authorized to perform the main authentication process through the NTN access device based on a configuration with credentials and / or policies, wherein the conditions include one or more of the following: -Operation mode - Whether the device has access to any (ground) access device, and - Allows for timing and location of this connection.

35. The method according to claim 3 and any one of claims 28 to 34, comprising: - The device instructs the network: when the first access device operates in store-and-forward mode, the primary authentication attempt occurring on the first access device, and / or - The device receives connection details associated with the master authentication attempt via the first access device, wherein the connection details may include one or more of the following: (1) path, (2) satellite identifier, (3) timing delay, (4) S&F timer, and (5) credentials such as an encryption key for completing the master authentication attempt for the connection.

36. The method according to any one of claims 3-35, wherein, The device is configured with an S&F emergency configuration, and the method includes: - The device selects the first access device based on the S&F emergency configuration and whether the first access device announces its support for emergency services. - The device uses the S&F emergency configuration to demonstrate that the device is entitled to request emergency services, such that the emergency service request includes one or more of the following: - Critical level, - Remaining lifespan, and -Emergency certificate And the emergency service request / instruction is included in: - In the RRC message, and / or - NAS registration message.

37. The method according to any one of claims 3-36, wherein, The configuration parameters include policies and / or credentials, which include one or more of the following: - Authorization token, - One-time password, - A key used to perform the main authentication process with the first access device, wherein the first access device includes the core network functions. - A group key used to perform an authentication process with the first access device, wherein the first access device includes core network functions. - When the first access device operates in store-and-forward mode, credentials used for authenticating and authorizing the device to transmit data, or - A strategy for determining the context in which the device can transmit data or perform a master authentication process when the first access device is operating in store-and-forward mode.

38. The method according to any one of claims 3-37, comprising: The device receives a paging message from the first access device or the second access device, the paging message indicating that the first access device and / or the second access device is configured with credentials (e.g., a key) to perform primary authentication with the device or to receive data from the device.

39. The method according to any one of claims 3-38, wherein the device is configured with a public key before checking or selecting the preferred authentication process, and / or is able to receive the public key from the first access device when performing the preferred authentication process, wherein the device uses the public key to protect the identity of the device, such as IMSI or SUPI, and the public key is linked to a private key specific to the first access device, such that only the first access device can decrypt the protected identity.

40. The method according to any one of claims 3-39, comprising: The device performs an authentication process with the first access device, whereby the device receives a first value (RAND) from the first access device, and the device calculates an authentication tag based on the first value and a long-term secret shared with the device's home network.

41. The method according to any one of the preceding claims, comprising: The apparatus sends a message to the first access device and / or the designated access device, wherein the message includes an authorization token that can be used during the preferred authentication process, whereby the authorization token serves as authorization proof for sending the message when the first access device is operating in store-and-forward mode, and wherein the message can be a message for initiating or performing the preferred authentication process (e.g., primary authentication) and / or sending data.

42. The method according to any one of the preceding claims, comprising: After establishing a communication connection with the first core network and performing the preferred authentication process with the first core network through the first access device, the device receives a short-term credential through the first access device, wherein the short-term credential is used for a second preferred authentication and authorization process with the second access device. The device performs a second preferred authentication and authorization process with the second access device by using the short-term credential, and The device exchanges (sends or receives) data with and / or through the second access device.

43. The method of claim 42, wherein the short-term certificate is valid within a short-term time window, and the short-term certificate may include at least one of the following: Short-term public / private key pairs and short-term certificates, A set of keys or passwords to be used with a second access device.

44. The method of claims 42 and 43, wherein the second preferred authentication and authorization procedure is performed by: using the short-term credential (private key or key or password) to calculate an authentication tag and / or signing a message including a UTC time and a transaction identifier, and including the authentication tag and / or the signature and the short-term certificate in the data exchanged with the designated access device, wherein the calculation of the authentication tag takes at least one of the UTC time, a counter, a one-time value, and the exchanged data as input.

45. The method according to any one of the preceding claims, comprising: - The apparatus receives or determines key materials from a key distribution entity, wherein the key distribution entity is located in the first access device or a selected access device, or in a network function (NF) within the core network. -The received or determined key material is used to protect communication with remote user equipment by encrypting or authenticating the communication at the PDCP layer and / or by using one or more of the following: - IPSec - TLS, and - MPQUIC.

46. ​​The method according to any one of claims 2 and 3, comprising: The device determines, based on (1) measurements of local conditions and (2) anticipated network behavior configured by means of policies or configurations provided by the network, when and how to distribute uplink / downlink services / management services on the first access device / first core network and the selected access device / second core network.

47. The method according to any one of the preceding claims, wherein the first access device or the designated access device is a satellite, or an unmanned aerial vehicle, or a vehicle.

48. An apparatus comprising: Receiver transmitter, Controller, and A media storage device includes instructions for executing a method for managing a connection, the method comprising: The device checks or selects the preferred authentication process; The device performs the preferred authentication process with the first core network via a first access device; and The device establishes a communication connection with the first core network.

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

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

Images