Dual boot session management

Abstract

An apparatus configured to: generate a first request message for establishing a first Protocol Data Unit (PDU) session with a first access network, wherein the first request message includes an indication regarding support for dual-booting functionality; process a first acceptance message indicating that a first PDU session has been established with the first access network, wherein the first acceptance message further includes a PDU session identifier (ID) of the first PDU session; generate a second request message for establishing a second PDU session with a second access network, wherein the second request message includes an indication regarding support for dual-booting functionality and a PDU session ID of the first PDU session; and process a second acceptance message indicating that a second PDU session has been established with the second access network, wherein the first session and the second session are associated PDU sessions with dual-booting functionality.

Description

[0001] Priority / Citation This application claims priority to U.S. Provisional Application Serial No. 63 / 573,088, filed April 2, 2024, entitled “Dual Steer Session Management,” the entire contents of which are incorporated herein by reference. Background Technology

[0002] User equipment (UE) can establish connections with multiple different networks or multiple types of networks. Some UEs and networks support multiple access (MA). UEs that support MA can be referred to as dual-booted UEs. In 3GPP networks such as 5G New Radio (5G NR) networks, Long Term Evolution (LTE) networks, and other similar networks, a UE can request the network to establish an MA session for the UE using a Multiple Access Dual Bootstrapping Protocol Data Unit (MADS-PDU). A typical use of a MADS-PDU session is for accessing a 3GPP network and another type of network (e.g., a Wi-Fi network). There is an expectation that multiple networks will be 3GPP type networks. However, when both access networks are 3GPP type networks, there is currently no process for establishing and managing MADS-PDU sessions. Summary of the Invention

[0003] Some example embodiments relate to an apparatus having processing circuitry configured to: generate a first request message for establishing a first Protocol Data Unit (PDU) session with a first access network for transmission to the first access network, wherein the first request message includes an indication regarding support for dual-booting functionality; process, based on signaling received from the first access network, a first acceptance message indicating that a first PDU session has been established with the first access network, wherein the first acceptance message further includes a PDU session identifier (ID) of the first PDU session; generate a second request message for establishing a second PDU session with a second access network for transmission to the second access network, wherein the second request message includes an indication regarding support for dual-booting functionality and a PDU session ID of the first PDU session; and process, based on signaling received from the second access network, a second acceptance message indicating that a second PDU session has been established with the second access network, wherein the first PDU session and the second PDU session are associated PDU sessions with dual-booting functionality.

[0004] Other example implementations relate to a method for: processing a first request message for establishing a first Protocol Data Unit (PDU) session with a first access network based on signaling received from a first user equipment (UE) with dual-booting functionality, wherein the first request message includes an indication that the first UE supports dual-booting functionality; selecting a Session Management Function (SMF) and a User Plane Function (UPF) for establishing the first PDU session with the first UE; reporting the SMF identifier (ID) of the SMF to a Unified Data Management (UDM) function; and generating a first acceptance message indicating that the first PDU session has been established with the first access network for transmission to the first UE, wherein the first acceptance message also includes a PDU session identifier (ID) of the first PDU session.

[0005] Another example implementation relates to a method for: processing a first request message for establishing a first Protocol Data Unit (PDU) session with a first access network based on signaling received from a first user equipment (UE) with dual-booting functionality, wherein the first request message includes an indication of supporting dual-booting functionality and a session identifier (ID) of a second PDU session associated with the dual-booting UE; determining an SMF hosting the second PDU session based on a mapping between the SMFID of a Session Management Function (SMF) hosting the second PDU session and a session ID stored in a Unified Data Management (UDM) function; selecting an SMF hosting the second PDU session to establish the first PDU session with the first UE; and generating an acceptance message indicating that the first PDU session has been established with the first access network for transmission to the first UE. Attached Figure Description

[0006] Figure 1 Example network layouts based on various example implementation schemes are shown.

[0007] Figure 2 Example user equipment (UE) is shown according to various example implementation schemes.

[0008] Figure 3 Example base stations based on various example implementation schemes are shown.

[0009] Figure 4 An example registration process for a dual-boot UE is shown according to various example implementation schemes.

[0010] Figure 5 Example session management procedures for dual-boot UEs are shown according to various example implementation schemes.

[0011] Figure 6 A second example session management process for a dual-boot UE is shown according to various example implementation schemes.

[0012] Figure 7 An end-to-end call flow for the session management process of a home-routed MADS-PDU session is illustrated according to various example implementations.

[0013] Figure 8 An end-to-end call flow is shown for the session management process of handing over a home route MADS-PDU session to a second tributary, according to various example implementations.

[0014] Figure 9 An end-to-end call flow for a session management process for locally navigating MADS-PDU sessions is illustrated according to various example implementations.

[0015] Figure 10 A home routing architecture diagram for dual-boot support for PDU session handover is shown, based on various example implementations.

[0016] Figure 11 An alternative home routing architecture diagram for dual-boot support for PDU session handover is shown according to various example implementations.

[0017] Figure 12 A home routing architecture diagram for dual-boot support for MADS-PDU session handover is shown according to various example implementations.

[0018] Figure 13 An alternative home routing architecture diagram for dual-boot support for MADS-PDU session handover is shown according to various example implementations.

[0019] Figure 14 A localized routing architecture diagram for dual-boot support of MADS-PDU sessions is shown, based on various example implementations.

[0020] Figure 15 An alternative local routing architecture diagram for dual-boot support of MADS-PDU sessions is shown, based on various example implementations.

[0021] Figure 16 A localized routing architecture diagram for dual-boot support for MADS-PDU session handover is shown, based on various example implementations.

[0022] Figure 17 An alternative local routing architecture diagram for dual-boot support for MADS-PDU session handover is shown, based on various example implementations.

[0023] Figure 18 An example layer diagram of a dual-boot UE with a Single Subscriber Identity Module (SIM) and an instantiated Non-Access Stratum (NAS) layer is shown according to various example implementations.

[0024] Figure 19 Example layer diagrams are shown for dual-boot UEs with a single SIM and instantiated NAS, AS, and 2 layers, according to various example implementations.

[0025] Figure 20 Example layer diagrams of dual-boot UEs with dual SIMs and instantiated NAS, AS, and tier 2 layers are shown according to various example implementations.

[0026] Figure 21 An example layer diagram of a dual-boot UE with two separate physical UEs is shown according to various example implementations.

[0027] Figure 22 Examples of 5G Session Management (5GSM) capabilities IE are shown according to various example implementation schemes.

[0028] Figures 23A to 23C illustrate examples of dual-boot containers according to various example implementations.

[0029] Figure 24 Examples of dual-boot IEs are shown, illustrating dual-boot specific information from the UE to the network or from the network to the UE, according to various example implementation schemes.

[0030] Figure 25 Examples of PDU session establishment requests transmitted by the UE to the network to initiate the establishment of a PDU session are shown according to various example implementations.

[0031] Figure 26 An example is shown of a PDU session establishment accept message transmitted from the network to the UE to indicate that a PDU session has been successfully established, according to various example implementations.

[0032] Figure 27 Examples of PDU session establishment rejection messages transmitted from the network to the UE to indicate that a PDU session has not been successfully established are shown, according to various example implementations.

[0033] Figure 28 Examples of PDU session modification requests transmitted by the UE to request modifications to the PDU session are shown according to various example implementations.

[0034] Figure 29 Examples of PDU session modification command messages transmitted from the network to the UE, according to various example implementations, are shown.

[0035] Figure 30 An example of a PDU session release request transmitted by a UE to the network to request the release of a PDU session, according to various example implementations, is shown.

[0036] Figure 31 Examples of PDU session release commands transmitted from the network to the UE to indicate the release of a PDU session are shown according to various example implementations. Detailed Implementation

[0037] The example implementation can be further understood with reference to the following description and related figures, in which the same elements have the same reference numerals. The example implementation relates to a session management procedure for a user equipment (UE) with dual boot capability. Specifically, the session management procedure relates to a scenario where both access networks are 3GPP type networks.

[0038] The example implementation is described with reference to a UE. However, reference to the UE is provided for illustrative purposes only. The example implementation can be used with any electronic component capable of establishing a connection with an accessory device and configured with hardware, software, and / or firmware for exchanging information and data with the accessory device. Therefore, the UE described herein is used to represent any electronic component.

[0039] Example implementations are also described with reference to 5G New Radio (NR) networks. However, example implementations can also be implemented in other types of networks, including but not limited to LTE networks, future evolutions of cellular protocols (e.g., 5G evolved networks, 6G networks, etc.), or any other type of network.

[0040] The example implementation involves dual-booting between two 3GPP networks. A dual-booting UE is capable of bootstrapping and handing over user services between two 3GPP access networks connected to the same or different Public Land Mobile Networks (PLMNs). The dual-booting UE can be a single UE for non-simultaneous transmission or two separate UEs for simultaneous transmission. For example, a subscriber of a dual-booting UE may have two subscriptions and identifiers (e.g., a Subscription Permanent Identifier (SUPI)) sharing a subscription profile from the same operator. At any given time, a dual-booting UE can transmit all services of a service on only one of the two 3GPP access networks.

[0041] The UE can register with the 3GPP access network in either single registration or dual registration mode. The UE can provide appropriate credentials in the registration message, such as a 5G-GUTI (if the UE has one available), a Subscription Hidden Identifier (SUCI), or a Permanent Device Identifier (PEI).

[0042] The UE can also register for non-3GPP access, where single / dual registration modes are not applicable. For non-3GPP access registration, the UE can provide a 5G-GUTI (if available) or SUCI as credentials. The UE can register separately for 3GPP and non-3GPP access, as the network only learns the type of access being used based on how it receives the registration request for a specific access. When registering on the same Public Land Mobile Network (PLMN), 3GPP and non-3GPP access registrations share the same 5G-GUTI identifier. When registering on different PLMNs, the registration has different 5G-GUTIs. The UE can register with different Access and Mobility Management Function (AMF) entities depending on the deployment. The UE and network can also exchange DualSteer-ST (including supported dual-booting functionality and booting modes) capability information during Protocol Data Unit (PDU) activation or modification as part of 5GSM capability exchange.

[0043] As stated above, a dual-booted UE subscriber can have two subscriptions / SUPIs sharing a single subscription profile from the same operator. For any particular service, at any given time, a dual-booted UE can send all traffic for that service using only a single 3GPP access network. The example implementation considers the following example scenarios with two networks of 3GPP type. The example implementation includes access networks connected to the 3GPP core network, and different combinations of these networks are permitted. For simplicity, these combinations may be referred to as access networks. In the first scenario, two NR / 5GC accesses within a single PLMN (HPLMN or VPLMN), where each access is either an NR terrestrial network (TN) or an NR non-terrestrial network (NTN). In the second scenario, two NR / 5GC accesses within two different PLMNs (including two visited PLMNs (VPLMNs), or including a VPLMN and a home PLMN (HPLMN)), where each access is either an NR TN or an NR NTN. In the third scenario, NR / 5GC access and Evolved UMTS Terrestrial Radio Access (E-UTRA) / Evolved Packet Core (EPC) access are provided in two different PLMNs (including two VPLMNs, or including a VPLMN and an HPLMN). In the fourth scenario, NR / 5GC access and E-UTRA / EPC access are provided in a single PLMN (HPLMN or VPLMN). In the fifth scenario, access is provided in a public network integrated with a non-public network (PNI-NPN) (integrated with an HPLMN or a VPLMN) and PLMNs (TN / NTN plus TN or NTN). This scenario assumes only non-simultaneous transmission. The example implementations are not limited to these example scenarios. These example scenarios are provided only as examples of different types of dual-booting environments where the example implementations can be used.

[0044] Various aspects may exist to support dual-boot UEs, including but not limited to enhancing the overall architecture and functionality of 5GS to support dual-boot UEs, enhancing the subscription aspects of dual-boot UEs, influencing the registration process of dual-boot UEs, enhancing network policies provided by HPLMN to dual-boot UEs, and supporting dual-boot UEs within the network.

[0045] The example implementations relate to aspects of enhancing the session management process used for the initial booting and possible subsequent handover of dual-booted UEs between different access networks (e.g., as described above). These exemplary implementations will be described in more detail below.

[0046] Figure 1 An example network arrangement 100 according to various example implementations is shown. Example network arrangement 100 includes a UE 110. UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smartphone, embedded device, wearable device, Internet of Things (IoT) device, etc. A real network arrangement may include any number of UEs used by any number of users. Therefore, for illustrative purposes, only one example of UE 110 is provided. UE 110 is a device with dual-boot capability, as will be described in more detail below.

[0047] UE 110 can be configured to communicate with one or more networks. In the example of network deployment 100, UE 110 can wirelessly communicate with two 5G NR radio access networks (RANs) 120 and 122. However, UE 110 can also communicate with other types of networks (e.g., 5G cloud RAN, next-generation RAN (NG-RAN), legacy cellular networks, etc.), and UE 110 can also communicate with networks via wired connections. The above describes some example scenarios of different types of access networks with which the UE can establish MADS-PDUs. Therefore, using two 5G NR RANs is merely an example. Referring to the example implementation, UE 110 can establish connections with 5G NR RANs 120 and 122. Therefore, UE 110 can have a 5G NR chipset to communicate with NR RANs 120 and 122.

[0048] 5G NR RAN 120 and 122 can be parts of a cellular network that can be deployed by network operators (e.g., Verizon, AT&T, T-Mobile, etc.). RAN 120 and 122 can include cells or base stations configured to transmit and receive services from UEs equipped with appropriate cellular chipsets. In this example, 5G NR RAN 120 includes gNB 120A, and 5G NR RAN 122 includes gNB 122A. However, the reference to gNB is provided merely for illustrative purposes, and any appropriate base station or cell can be deployed (e.g., Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macro cell, micro cell, small cell, femtocell, etc.).

[0049] Any association procedure can be performed to connect UE 110 to 5G NR RANs 120 and 122. For example, as discussed above, 5G NR RANs 120 and 122 can be associated with a specific network operator where UE 110 and / or its user have contract and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR RANs 120 and 122, UE 110 can send the corresponding credential information to associate with 5G NR RANs 120 and 122. More specifically, UE 110 can be associated with a specific cell (e.g., gNB 120A and / or gNB 122A). An example registration procedure for dual access is described below.

[0050] Network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 manages traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network services backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 can generally be described as a collection of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 in communicating with various networks.

[0051] The cellular core network 130 may include one or more network functions. Figure 1In the example, the cellular core network 130 includes Access and Mobility Management Function (AMF) 131, Session Management Function (SMF) 132, User Plane Function (UPF) 133, Unified Data Management (UDM) Function 134, and Policy Control Function (PCF) 135. The cellular core network may include multiple instances of each of these functions.

[0052] AMF 131 can perform mobility management-related operations, such as, but not limited to, paging between UE 110 and core network 130, non-access stratum (NAS) management, and registration process management. AMF 131 may be equipped with one or more communication interfaces (e.g., N1, N2, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). Example implementations are not limited to AMFs performing the operations mentioned above. Furthermore, reference to a single AMF 131 is for illustrative purposes only; actual network deployments may include any appropriate number of AMFs. AMF 131 can also communicate directly with SMF 132. For example, AMF 131 can communicate with SMF 132 via the N11 interface.

[0053] The SMF 132 can perform operations related to session management, such as, but not limited to, session establishment, session release, IP address allocation, policy and Quality of Service (QoS) enforcement. The SMF 132 may be equipped with one or more communication interfaces (e.g., N11) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). The example implementation is not limited to an SMF performing the operations mentioned above. Furthermore, the reference to a single SMF 132 is for illustrative purposes only; actual network deployments may include any appropriate number of SMFs.

[0054] UPF 133 performs operations related to Packet Data Unit (PDU) session management and other types of data flow management. For example, UPF 133 can facilitate a connection between UE 110 and a data network (e.g., Internet 140) via the N6 interface. UPF 133 may be equipped with one or more communication interfaces (e.g., N3, N4, N6, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). The example implementation is not limited to a UPF performing the operations mentioned above. Furthermore, reference to a single UPF 133 is for illustrative purposes only; actual network deployments may include any appropriate number of UPFs.

[0055] UDM 134 manages data used for operations such as access authorization, user registration, and data network profiles. UDM 134 also manages subscriber data. The example implementation is not limited to a UDM performing the operations mentioned above. Furthermore, the reference to a single UDM 134 is for illustrative purposes only; actual network deployments may include any appropriate number of UDMs.

[0056] The PCF 135 can perform control plane-related operations, such as, but not limited to, managing policy rules for control plane functions, including network slicing, roaming, and mobility management. The PCF 135 may be equipped with one or more communication interfaces (e.g., N7) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). The example implementation is not limited to a PCF performing the operations mentioned above. Furthermore, the mention of a single PCF 135 is merely illustrative; actual network deployments may include any appropriate number of PCFs.

[0057] The following describes in more detail the operations related to dual-boot capability performed by the network function in the example implementation.

[0058] Figure 2 Example UE 110 according to various example implementations is shown. (Refer to...) Figure 1 The network layout 100 is used to describe UE 110. UE 110 can represent any electronic device and may include processor 205, memory layout 210, display device 215, input / output (I / O) device 220, transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, batteries providing limited power supply, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, sensors for detecting the condition of UE 110, etc.

[0059] Processor 205 may be configured to execute multiple engines for UE 110. For example, an engine may include a dual-boot engine 235 for performing operations related to MADS-PDU session management. For example, dual-boot engine 235 may include logic and / or circuitry for requesting the establishment of a MADS-PDU session, requesting modification of a MADS-PDU session, measuring link quality on different branches of a MADS-PDU session, bootstrapping or switching services between different branches of a MADS-PDU session, etc. Each of these example operations will be described in more detail below.

[0060] The engine 235 mentioned above, as an application (e.g., a program) executed by processor 205, is merely an example. The functionality associated with the engine may also be represented as a separate, integrated component of UE 110, or as a modular component coupled to UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine may also be embodied as one or more separate applications. Furthermore, in some UEs, the functionality described for processor 205 is split between two or more processors, such as a baseband processor and an application processor. Example implementations may be implemented according to any of these or other configurations of the UE.

[0061] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling a user to input data. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen).

[0062] Transceiver 225 may be a hardware component configured to establish connections with 5G NR-RAN 120, LTE-RAN (not shown), legacy RAN (not shown), WLAN (not shown), etc. Accordingly, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a continuous set of frequencies). Transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded using information used to implement any of the methods described herein. Processor 205 may be operatively coupled to transceiver 225 and configured to receive signals from and / or transmit signals to transceiver 225. Processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station in the network) for use in implementing any of the methods described herein.

[0063] Figure 3 An example base station 300 is shown according to various example implementations. Base station 300 may represent gNB 120A or gNB122A, or any other access node through which UE 110 can establish connections and manage network operations.

[0064] Base station 300 may include processor 305, memory arrangement 310, input / output (I / O) devices 315, transceiver 320, and other components 325. Other components 325 may include, for example, audio input devices, audio output devices, batteries, data acquisition devices, ports for electrically connecting base station 300 to other electronic devices and / or power sources, etc.

[0065] Processor 305 can be configured to execute multiple engines for UE 110. For example, an engine may include dual-boot engine 335 for relaying MADS-PDU information between UE 110 and core network 130. Each of these example operations will be described in more detail below. Although engines 335 and 340 are shown as separate engines, in some embodiments, engines 335 and 340 may be combined into a single engine.

[0066] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware component or port that enables a user to interact with the base station 300.

[0067] Transceiver 320 may be a hardware component configured to exchange data with UE 110 and any other UE in network arrangement 100. Transceiver 320 may operate on a variety of different frequencies or channels (e.g., a continuous set of frequencies). Transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded using information used to implement any of the methods described herein. Processor 305 may be operatively coupled to transceiver 320 and configured to receive signals from and / or transmit signals to transceiver 320. Processor 305 may be configured to encode and / or decode signals (e.g., signaling from a UE) for use in implementing any of the methods described herein.

[0068] As stated above, the example implementation involves aspects of enhancing the session management process for a UE with dual-booting capabilities. This may include the initial bootstrapping of the dual-booting UE between different access networks and possible subsequent handovers. Before describing the example implementation, some terminology related to dual-booting UEs will be provided.

[0069] The guided description describes the process associated with selecting one of two access networks (e.g., two 3GPP access networks) for the service that will be processed on that access network.

[0070] The switching description relates to the process of transferring services from one of two access networks to the other. Examples of different access networks are provided above.

[0071] Dual-booting UEs possess the capability and functionality to bootstrap and / or handover user services across two access points based on provided dual-booting rules (e.g., UE Routing Policy (URSP) rules). The UE can use or apply 1) higher-layer functionality, which operates above the Internet Protocol (IP) layer using Multipath TCP (MPTCP); or 2) lower-layer functionality, which operates below the IP layer using DualSteer-Lower Layer (DualSteer-LL). For example, the UE can monitor link quality (e.g., Quality of Service (QoS), Quality of Experience (QoE), Round-Trip Time (RTT), etc.) on both branches of a MADS-PDU session and determine service bootstrap and handover decisions based on this monitoring and / or DualSteer rules.

[0072] PCF 135 can provide DualSteer service routing rules to UE 110 via SMF 132. SMF 132 can provide N4 interface rules to UPF 133, indicating how downlink services should be routed. Performance Management Function (PMF) messages can be exchanged between UE 110 and UPF 133 for RTT measurements on each access type. Therefore, dual bootstrapping enables intelligent routing of device services across two simultaneous network connections.

[0073] Before describing the example session management process, the following section describes some example registration processes for dual-boot UEs.

[0074] Figure 4 An example registration process 400 for a dual-boot UE 401 is illustrated according to various example implementations. The registration process 400 can be performed between the dual-boot UE 401, which includes a first UE 402 and a second UE 404, and a first access network 406 and a second access network 408. The first UE 402 and the second UE 404 can be part of the same physical device (e.g., a smartphone) or can be two separate physical devices (e.g., a smartphone and a connected wearable device). As described above, access networks 406 and 408 can be two 3GPP access networks. Furthermore, access networks 406 and 408 each have a corresponding AMF, to which the dual-boot UE 401 will register.

[0075] In step 410, the first UE 402 of the dual-booting device 401 transmits a registration request to the first access network 406. The registration request includes an indication that the first UE 402 has dual-booting capability, the SUPI of the first UE 402, and an indication that the first UE 402 wishes to use the access network as its primary access. The primary access indication tells the network that the first UE 402 wishes to use the access network to receive, for example, paging, control messages, etc. In some example embodiments, the SUCI or PEI of the first UE 402 may be indicated as a substitute for or supplement to the SUPI. In some example embodiments, the registration request may also include the SUPI, SUCI, or PEI of the second UE 404.

[0076] The AMF of the first access network 406 can perform various operations after receiving a registration request, such as verifying that the first UE 402 has dual boot capability and dual boot subscription to the network's UDM function, and creating a context for the first UE 402 in the network.

[0077] In step 415, the AMF of the first access network 406 transmits a registration acceptance message to the first UE 402. The registration acceptance message may include a 5G-GUTI-1 as a temporary identifier for the first UE 402, an indication that the first UE 402's subscription supports dual-booting capability, and a list of PLMNs available for use by the dual-booting UE 401.

[0078] Operation 415 assumes successful registration. In the event of unsuccessful registration (e.g., the first UE 402 does not have a dual-bootstrapping subscription), the AMF of the first access network 406 may transmit a registration rejection message in 420. For the purposes of this example implementation, the registration process can be considered successful.

[0079] After the first UE 402 successfully registers with the first access network 406, the dual-booting UE 401 may then attempt to register the second UE 404 with the second access network 408. In step 425, the second UE 404 of the dual-booting UE 401 transmits a registration request to the second access network 408. The registration request includes an indication that the second UE 404 has dual-booting capability, the second UE 404's SUPI, the 5G-GUTI-1 assigned to the first UE 402, and an indication that the second UE 404 wishes to use this access network as a secondary access. The secondary access indication tells the network that the second UE 404 does not wish to use this access for receiving services such as paging or mobile termination (MT) to conserve UE battery power. Similarly, in some example implementations, the second UE 404's SUCI or PEI may be indicated as an alternative to or supplement to the SUPI.

[0080] The AMF of the second access network 408 can perform various operations upon receiving a registration request. In this case, since the registration request includes the 5G-GUTI-1 assigned to the first UE 402 by the first access network 406, the AMF of the second access network 408 will determine that the second UE 404 is a dual-booting UE. The AMF of the second access network 408 can then contact the network's UDM function again to verify that the second UE 404 has dual-booting capability and a dual-booting subscription. Based on this information, the UDM will now, for example, learn about the two access networks 406 and 408 used by the dual-booting UE 401 by storing the AMF identifier (ID) in the UDM. The AMF of the second access network 408 can also create a context for the second UE 404 in the network.

[0081] In step 430, the AMF of the second access network 408 transmits a registration acceptance message to the second UE 404. The registration acceptance message may include 5G-GUTI-2 as a temporary identifier for the second UE 404, an indication of the first UE 402's subscription support for dual-booting capability, and a list of PLMNs available for use by the dual-booting UE 401.

[0082] Operation 430 assumes successful registration. In the event of unsuccessful registration, the AMF of the second access network 408 may transmit a registration rejection message in 435. For the purposes of this example implementation, the registration process can be considered successful.

[0083] Therefore, at this point, the dual-booting UE 401 can be considered to have successfully registered with both access networks 406 and 408; for example, the registration rejection messages in 420 and 435 are not executed. Later, in 440, access networks 406 and 408 can receive incoming MT calls for the dual-booting UE 401. As described above, in this example, the dual-booting UE 401 has already registered to receive primary access (e.g., paging) via the first access network 406 using the first UE 402. Therefore, the second access network 408 can ignore the MT call, and the first access network 406 can transmit an AMF paging message to the first UE 402 of the dual-booting UE 401 in 445. This is merely one example operation that can be performed when the dual-booting UE 401 is currently registered with both access networks 406 and 408.

[0084] In addition, at any time, UE 402 or UE 404 may transmit deregistration requests 450 and 455 respectively to deregister from the access network.

[0085] In other example implementations, the registration request may not include an indication of primary or secondary access, but instead include a paging restriction. For example, a paging restriction may indicate that the UE will accept paging or that the UE will not accept paging. The result may be similar to the example described above, except that there is no indication of whether a particular access network is a primary or secondary access network.

[0086] The following section provides an example of a session management process that can be used for dual-boot UEs.

[0087] Figure 5 Example session management procedure 500 for dual-boot UE 501 is shown according to various example implementations. Similar to... Figure 4 The registration process, session management process 500, is performed between dual-boot UE 501, which includes first UE 502 and second UE 504, and first access network 506 and second access network 508.

[0088] In step 510, dual-booting UE 501 performs a registration procedure with the first access network 506 and the second access network 508, such that the first UE 502 registers with the first access network 506 and the second UE 504 registers with the second access network 508. The registration procedure can be, for example, the registration procedure 400 described above or any other applicable registration procedure for dual-booting UEs.

[0089] In step 515, the first UE 502 of the dual-booting UE 501 transmits a PDU session establishment request to the first access network 506. The PDU session establishment request may include the dual-booting capabilities of the first UE 502, such as the DualSteer-ST IE of the 5G Session Management (5GSM) Capability Information Element (IE). See below for reference. Figure 22 An example of a 5GSM-capable Internet Explorer is provided.

[0090] The PDU session establishment request may also include an indication that the request is an initial request for a PDU session and that a MADS-PDU session is being requested. The MADS-PDU session described above, for example, has two branches, one each for access networks 506 and 508. In some example implementations, instead of establishing a MADS-PDU session, two separate PDU sessions may be established, for example, one PDU session for each 3GPP access network.

[0091] When the AMF of the first access network 506 receives a PDU session establishment request, the AMF can perform certain operations. For example, based on the first UE identification information, the AMF can determine, according to the UE context with the first access network 506, that the first UE 502 is a dual-booting UE and is attempting to establish a dual-booting PDU session. The AMF can select an SMF with dual-booting capability and can pass the dual-booting capability, UE ID, and other information of the first UE 502 to the SMF. Then, the SMF selects a UPF with dual-booting capability, and the PDU session is established. In some cases, the network can select a UPF such that the UPF acts as a common PDU session anchor point for the DualSteer device.

[0092] If the above operation is successful, then in step 520, the AMF of the first access network 506 transmits a PDU session establishment acceptance message to the first UE 502. The PDU session establishment acceptance message may include the PDU session ID, the dual-booting container (which may include, for example, rules and / or policies for the PDU session), and the selected PDU session type. The PDU session type indicates the type of PDU session, such as a dual-booting PDU session or a single PDU session. That is, if the AMF determines that the UE does not support dual-booting capability, the network may establish only a single PDU session in response to the PDU session establishment request.

[0093] If an error occurs during PDU session establishment, in step 525, the AMF of the first access network 506 may transmit a PDU session establishment rejection message, which indicates the reason for the failure to establish the PDU session, such as a 5GSM reason code. For the purposes of the example implementation, the dual-boot PDU session can be considered to have been established successfully.

[0094] In step 530, the second UE 504 of the dual-booting UE 501 transmits a PDU session establishment request to the second access network 508 for establishing a second tributary of the dual-booting PDU session. Similar to the PDU session establishment request described above, this request may also include the second UE 504's dual-booting capability (e.g., DualSteer-ST IE), an indication that the request is an initial request for a PDU session and that a MADS-PDU session is being requested. The PDU session establishment request may also include the PDU session ID returned to the first UE 502 in step 520.

[0095] When the AMF of the second access network 508 receives a PDU session establishment request, the AMF can perform certain operations. The indication of the PDU session ID in the PDU session establishment request indicates to the AMF of the second access network 508 that this is a request for the second tributary of the dual-booted PDU session. The AMF of the second access network 508 can use the PDU session ID to query the UDM whether a first PDU session has already been established for the DualSteer device. If so, the AMF can query the UDM for the identifier of the SMF selected for the first access network 506 to host the dual-booted PDU session. The selected SMF then selects the same UPF with dual-booting capability (which acts as the common PDU session anchor (PSA)), and the second tributary of the PDU session is established.

[0096] If the above operation is successful, then in step 535, the AMF of the second access network 508 transmits a PDU session establishment acceptance message to the second UE 504. The PDU session establishment acceptance message may include the PDU session ID of the PDU session, the dual bootstrap container (which may include, for example, rules and / or policies for the PDU session), and the selected PDU session type, as described above.

[0097] If an error occurs during PDU session establishment, in step 540, the AMF of the second access network 508 may transmit a PDU session establishment rejection message, which indicates the reason for the failure to establish the PDU session, such as a 5GSM reason code. For the purposes of the example implementation, the dual-boot PDU session can be considered to have been established successfully.

[0098] In the example above, the PDU session IDs of the first and second branches are the same, and this PDU session ID is associated with both branches of a dual-booting PDU session. For example, the network will use the same SMF and UPF for both branches. In some example implementations, different identifiers may be used to associate the two branches of a dual-booting PDU session. For example, the network may generate some other type of identifier, such as a related identifier or association identifier, to associate the two branches. In any case, this identifier may be returned to the first UE 502 in the PDU session establishment acceptance message, and the second UE 504 may include the identifier in the PDU session establishment request. Therefore, the use of the PDU session ID is only an example, and other ways of associating the two branches of a dual-booting PDU session may exist.

[0099] After a dual-booted PDU session is established, it can be modified for any number of reasons to change the session's attributes. For example, the first UE 502 can request a change to the Quality of Service (QoS) of the current PDU session. This is just an example, and the example implementation can be applied to modification requests for any reason. Figure 5 In the example, the first UE 502 sends a modification request to the network, but the second UE 504 can also send a modification request.

[0100] In step 545, the first UE 502 transmits a PDU session modification request to the first access network 506. The PDU session modification request may include dual bootstrapping capability, indications that the request is for an existing PDU session and that the request is for a MADS-PDU session.

[0101] If the network can satisfy the modification request, then in 550, the AMF of the first access network 506 transmits a PDU session establishment command indicating a change to the PDU session to the first UE 502. The PDU session establishment command may include the PDU session ID of the PDU session, a dual boot container (which may include, for example, rules and / or policies for the PDU session), and the selected PDU session type, as described above.

[0102] If an error occurs while modifying the PDU session, in step 555, the AMF of the first access network 506 can transmit a PDU session modification rejection message. This message indicates the reason for not modifying the PDU session, such as a 5GSM reason code. For the purposes of this example implementation, the dual-boot PDU session modification can be considered successful.

[0103] In some example implementations, dual-booting UE 501 may also enable user plane resources for preferred access to services used to deliver specific services. Examples of preferred access networks have been described above. For instance, when a dual-booting PDU session begins, neither the first nor the second tributary may be indicated as preferred access. Based on link monitoring, dual-booting UE 501 can determine that one of UEs 502 and 504 should be the preferred access for the service being performed. Figure 5 In the example below, the first UE 502 issues a request for user plane resources intended for use as a first access network, which is the preferred access. While the example below describes a request to establish user plane resources for preferred access, this request can also be used to establish that access as primary access. A request for primary access instructs the network that all paging and MT termination messages should be routed through the access network designated as primary access.

[0104] In step 560, the first UE 502 transmits a registration request to the first access network 506. The registration request may include dual boot capability, the SUPI of the first UE 502, and an indication of a request for primary access.

[0105] In operation 565, the AMF of the first access network 506 can transmit a registration acceptance message to the first UE 502. This registration acceptance message includes the first UE 502's 5G-GUTI-1, an indication that the UE has subscribed to support dual-booting capability, and a list of PLMNs that the first UE 502 can use for dual-booting. Therefore, upon completion of operation 565, the first UE 502 and the first access network 506 can be used as primary access via a dual-booting PDU session.

[0106] In some example implementations, a PDU session on an access network can be released, and a new PDU session can be established using a different access network.

[0107] In step 570, the first UE 502 transmits a PDU session release request to the first access network 506 to release the first access of the dual-booted PDU session. In step 575, the first access network 506 transmits a PDU session release command to release the first access of the current dual-booted PDU session. Therefore, at this point, the second branch of the dual-booted PDU session is the only active branch. Thus, the services of this session can be switched to the second branch. Service handover across PDU sessions does not change the primary / secondary access, because the concept of primary or secondary access network is service-independent; rather, it specifies which access network the UE will receive paging and mobile termination control messages from the network through, thereby optimizing UE battery life. From DualSteer's perspective, the access network can be preferentially selected based on link conditions, and services can therefore be booted or switched to that access network and the corresponding PDU session.

[0108] The preferred access network does not necessarily have to be the primary access network. The access network is the preferred one to carry a certain type of service, while the primary access network is more suitable for paging and MT calls, etc. In this sense, terrestrial networks are more suitable as primary access networks than non-terrestrial networks.

[0109] At a later time, the first UE 502 can establish a new dual-booting PDU session with the access network. This process is underway. Figure 5 Operations 580 to 590 are shown in the diagram. Operations 580 to 590 are similar to operations 515 to 525 described above for establishing a dual-boot PDU session, and will not be described again.

[0110] In some example implementations, user plane resources can be enabled for preferred access using service requests instead of registration requests. Examples of preferred access have been described above. Similarly, in... Figure 5 In the example, the first UE 502 issues a request for user plane resources, but the second UE 504 can also issue the same request.

[0111] In step 593, the first UE 502 transmits a service request to the first access network 506. The service request may include dual booting capability, the first UE 502's SUPI, and an indication of a request to also become the primary access to the first access network.

[0112] In operation 597, the AMF of the first access network 506 can transmit a service acceptance message to the first UE 502. This service acceptance message includes the 5G-GUTI-1 of the first UE 502, an indication regarding the UE's subscription to support dual-booting capability, and a list of PLMNs that the first UE 502 can use for dual-booting. Therefore, upon completion of operation 597, the first UE 502 and the first access network 506 can be used as primary access via a dual-booting PDU session.

[0113] Figure 6 A second example session management procedure 600 for a dual-boot UE 601 is illustrated according to various example implementations. The session management procedure 600 is performed between the dual-boot UE 601, which includes a first UE 602 and a second UE 604, and a first access network 606 and a second access network 608. Operations 610 to 655 are similar to those described in the reference above. Figure 5 Operations 510 to 555 are described and therefore will not be described again.

[0114] exist Figure 6 In the examples, it is not necessary to use, such as Figure 5 Instead of using a release request / command to switch access from one tributary of a dual-booted PDU session to another, the access network uses a pause request on one tributary of the dual-booted PDU session. This way, the access network does not need to release the context associated with the paused tributary of the PDU session, allowing the paused tributary to be resumed later without establishing a new PDU session. These example implementations are described below.

[0115] In step 660, the first UE 602 transmits a PDU session suspension request to the AMF of the first access network 606. As stated above, this request may be associated with the dual-booting UE 601 (e.g., based on link monitoring as described above) determining that the PDU session tributary between the first UE 602 and the first access network 606 is not the optimal tributary for the service being served. In order to switch the service to another tributary of the dual-booting PDU session, the dual-booting UE 601 requests suspension of the poorly performing tributary of the PDU session, so that the service can be routed through the other tributary.

[0116] In step 665, the AMF of the first access network 606 transmits a PDU session pause accept message, which indicates to the first UE 602 that this branch of the dual-booted PDU session is paused. Therefore, the other branch of the dual-booted PDU session (e.g., the unpaused branch) will be used to exchange the services of the dual-booted PDU session.

[0117] Later, dual-booting UE 601 may wish to resume the suspended tributary of the dual-booting PDU session. For example, link monitoring may indicate that the tributary is now the optimal tributary for service. Therefore, in 670, first UE 602 transmits a PDU session resumption request to the AMF of first access network 606. Because the tributary of the PDU session associated with first UE 602 is only suspended and not released, the first access network can still include the context of first UE 602's PDU session. Therefore, the AMF of first access network 606 can resume the tributary of the dual-booting PDU session associated with first UE 602 and transmit a PDU session resumption accept message to first UE 602. Because the tributary of the dual-booting PDU session is indicated as the preferred access, the service can subsequently be switched back to that tributary of the PDU session.

[0118] Similar to about Figure 5 In some example implementations, the described operations allow service requests to be used to enable user plane resources for preferred access. Similarly, in... Figure 6 In the example, the first UE 602 issues a request for user plane resources, but the second UE 604 can also issue the same request.

[0119] In step 680, the first UE 602 transmits a service request to the first access network 606. The service request may include dual booting capability, the first UE 602's SUPI, and an indication of a request to also become the primary access to the first access network.

[0120] In operation 685, the AMF of the first access network 606 can transmit a service acceptance message to the first UE 702. This service acceptance message includes the 5G-GUTI-1 of the first UE 602, an indication that the UE has subscribed to support dual-booting capability, and a list of PLMNs that the first UE 702 can use for dual-booting. Therefore, upon completion of operation 685, the first UE 602 and the first access network 606 can be used as primary access via a dual-booting PDU session.

[0121] Figure 7An end-to-end call flow 700 for a session management procedure for a home-routed MADS-PDU session, according to various example embodiments, is illustrated. Call flow 700 includes a dual-booting UE 701, comprising a first UE 702 having a first SUPI-1 and a second UE 704 having a second SUPI-2. Call flow 700 also includes a first access network 710, comprising AMF 712, SMF 714, and UPF 716. Call flow 700 further includes a second access network 720, comprising AMF 722, SMF 724, and UPF 726.

[0122] In 730, the first UE 702 performs a registration procedure with the AMF 712 using SUPI-1, such as registration procedure 400 described above. The first UE 702 may indicate during the registration procedure whether it supports dual-booting capability. The AMF 712 may indicate to the UE 702 that the network supports dual-booting capability during the registration procedure (e.g., in a registration acceptance message).

[0123] Similarly, in 735, the second UE 704 performs a registration procedure with the AMF 722 using SUPI-2, such as registration procedure 400 described above. The second UE 704 may indicate during the registration procedure whether it supports dual-booting capability. The AMF 722 may indicate to the UE 704 that the network supports dual-booting capability during the registration procedure (e.g., in a registration acceptance message).

[0124] If AMF 712 indicates that dual booting is not supported, UE 702 may not initiate a PDU session activation / modification for dual booting (until indicated by AMF 712 in the registration acceptance or modified during the configuration update command process based on a subscription change indicated by UDM) or a registration process performed on a new Tracking Area (TA) or PLMN. UE 702 may request PDU session activation that includes the same single Network Slice Selection Assistance Information (S-NSSAI) on both accesses only if S-NSSAI is in the list of allowed NSSAIs. Similar operations and restrictions apply when AMF 722 indicates that dual booting is not supported.

[0125] For UE 701 configured to operate in dual-boot mode, if dual-boot registration fails during the SUPI-2 registration process and no other PLMN can provide dual-boot service, UE 701 may periodically search for PLMNs that can provide dual-boot service (e.g., based on 3GPP Technical Specification (TS) 23.122, based on access type). In this state, UE 701 may not attempt to register in normal mode. For example, in NTN access, UE search may rely on satellite almanac information for search and camping.

[0126] In 740, the first UE 702 transmits a PDU session establishment request to the SMF 714 via AMF 712. As described above, the PDU session establishment request may include a DualSteer-ST IE and a request type indicating the dual-booting type of the PDU session activation. UE 702 SUPI-1 may include the request type in the uplink (UL) Non-Access Stratum (NAS) transport message. The request type may indicate whether a MADS-PDU session or a single-tribute PDU session is requested.

[0127] In 745, AMF 712 updates the UDM with information about the SMF 714 selected for the dual-boot PDU session. The UDM maintains a mapping table that maps active SMF IDs to SUPI. This operation is used for dual-boot functionality to assist the AMF in SMF selection. The concept is that when activating a PDU session on the second tributary using SUPI-2, the same home SMF (H-SMF) is contacted. Therefore, as stated above, AMF 712 updates the home UDM (H-UDM) with the SMF ID of the SMF 714 selected to activate the PDU session. This information can then be used later when the second UE 704 initiates PDU session activation on the second tributary of the MADS-PDU session.

[0128] In 750, SMF 714 selects a UPF (e.g., UPF 716) and provides the IP address of the PDU session to the first UE 702. AMF 712 and / or SMF 714 can determine whether the PDU session requires local routing or home routing. The Session and Service Continuity (SSC) mode can be determined based on the configuration or by the SSC mode provided by UE 702 in the session establishment request.

[0129] In 755, SMF 714 queries UPF 716 to determine whether UE 702 is allowed to have a MADS-PDU session based on operator policies and subscription data. If UE 702 indicates "DualSteer-LL capability," SMF 714 derives bootstrapping and handover rules. SMF 714 can also provide measurement assistance information to UE 702. SMF 714 can instruct UPF 716 to perform measurement performance measurements. SMF 714 can also provide MPTCP proxy information and UE 702's "link-specific multipath" address / prefix in the PDU session establishment accept message.

[0130] In 760, a PDU session is created on the second tributary (e.g., UE 704 and access network 720) by selecting H-SMF 724 derived from the UDM (which is the same SMF as 712), where the UDM maintains a mapping table of SMF IDs and SUPIs (e.g., SUPI-1 of the SMF ID mapped to SMF 714). Therefore, by the time 760 completes, both tributaries of the MADS-PDU session have been established.

[0131] Figure 8 An end-to-end call flow 800 is illustrated, according to various example embodiments, for a session management procedure to hand over a home-routed MADS-PDU session to a second tributary. Call flow 800 includes a dual-booting UE 801, comprising a first UE 802 having a first SUPI-1 and a second UE 804 having a second SUPI-2. Call flow 800 also includes a first access network 810, comprising AMF 812, SMF 814, and UPF 816. Call flow 800 further includes a second access network 820, comprising AMF 822, SMF 824, and UPF 826.

[0132] Operations 830 to 855 are similar to those mentioned above. Figure 7 Operations 730 to 755 are described and will not be described again.

[0133] In 860, UE 802 loses network coverage, but UE 804 remains within network coverage. For example, dual-boot UE 801 may wish to hand over to the second tributary of the MADS-PDU session. The example of lost coverage is merely illustrative; there may be other reasons why dual-boot UE 801 might wish to switch to the second tributary of the MADS-PDU session.

[0134] In 865, UE 806 transmits a PDU session establishment request with reqType "existing PDU session" for handing over the PDU session established on access network 710 to access network 720 (e.g., the second branch of a MADS-PDU session).

[0135] In 870, a PDU session is created on tributary 2 by selecting an H-SMF exported from a UDM that maintains a mapping table of SMF IDs and SUPIs, such as the SMF ID of SMF 814.

[0136] Figure 9 An end-to-end call flow 900 for a session management procedure for locally routing MADS-PDU sessions, according to various example implementations, is illustrated. Call flow 900 includes a dual-booting UE 901, comprising a first UE 902 having a first SUPI-1 and a second UE 904 having a second SUPI-2. Call flow 900 also includes an AMF 912, an SMF 914, a UPF 916, and an H-UDM 918.

[0137] Operations 930 to 955 are similar to those mentioned above. Figure 7 Operations 730 to 755 are described and will not be described again. However, in this example, UPF selection 945 can be performed before AMF 912 updates H-UDM 918 regarding SMF ID. In 960, a data radio bearer (DRB) is established for UE 902.

[0138] In 970, UE 902 detects coverage loss or packet measurement characteristics (e.g., RTT, packet loss, latency, etc.) on the UE 902 link, which indicate that the connection is insufficient for the ongoing service.

[0139] In 975, dual-booting UE 901 determines that it needs to perform a DRB transfer to UE 904. Therefore, UE 904 initiates a PDU session establishment request to SUPI-2, indicating that it is a request for dual booting.

[0140] In the 980, the AMF 912 obtains the SMF ID to be selected from the H-UDM 918 (e.g., the SMF ID of the SMF 914) because it is a dual-boot type PDU session.

[0141] In 985, UE 904 transmits a PDU session establishment request, which includes the same PDU session ID (received on SUPI1), DualSteer-ST IE, and a request type indicating a dual-booting type for PDU session activation. UE 904 includes the request type in the UL NAS transport message. The request type may indicate a request to establish a MADS PDU session. UE 904 may also indicate "DualSteer-LL capability" or MPTCP functionality, or both.

[0142] In 990, SMF 914 establishes new N9 and N3 tunnels, and if necessary, updates the dual-booting rules in the DualSteer container IE in the PDU session establishment accept message. In 995, a DRB is established for UE 904.

[0143] The following section provides some example network architectures for configuring dual-booting capabilities for home routing architecture and local routing.

[0144] Figure 10 A home routing architecture diagram 1000 for dual-boot support for PDU session handover is illustrated according to various example implementations. To support PDU session handover from one access network to another in a home routing configuration, the UE (SUPI2) provides the 5G-GUTI-1 received by the UE (SUPI1) during the registration process and transmits a service request (or new NAS message) to the AMF-1 via the AMF-2. The AMF-1 decrypts and successfully performs an integrity protection check on the service request message (or new NAS message) transmitted by the UE (SUPI-1). The AMF-1 then transmits the SMF-1 and all other PDU session details (UE SUPI1 context) to the AMF-2 on tributary 1. The AMF-2 can then use this context to select the SMF, and subsequently the H-SMF, and thus the H-UPF, to continue the PDU session using the "existing PDU session" type.

[0145] Figure 11Figure 1100 illustrates an alternative home routing architecture for dual-boot support of PDU session handover, based on various example implementations. To support PDU session handover from one access network to another in a local routing configuration, during the activation of any new PDU session on tributary 1, AMF-2 updates the UDM with regard to the SMF ID selected for SMF PDU session creation. Any PDU session release may result in an update of the UDM for either SMF. Similarly, in tributary 2, when the AMF detects a transfer of a PDU session from tributary 1 (if the PDU session type is "existing PDU session," then it obtains information from the UDM about the SMF to select), in this case, the H-SMF.

[0146] Figure 12 A home routing architecture diagram 1200 for dual-booting support for MADS-PDU session handover, according to various example implementations, is shown. To support dual-booting MADS-PDU sessions from one access network to another in a local routing configuration, the UE (SUPI2) provides (received on the UE (SUPI1) during the registration process) a 5G-GUTI-1 and transmits a service request message (or new NAS message) to the AMF-1 via the AMF-2. The AMF-1 decrypts and successfully performs an integrity protection check on the service request message (or new NAS message) transmitted by the UE (SUPI-1). The AMF-1 then transmits the SMF-1 ID and all other PDU session details to the AMF-2 on tributary 1. The AMF-2 selects the SMF, and therefore the UPF, to continue the PDU session using the "existing PDU session" type.

[0147] Figure 13 Figure 1300 illustrates an alternative home routing architecture for dual-boot support of MADS-PDU session handover, based on various example implementations. To support MADS-PDU sessions across two access networks in a home routing configuration, during the activation of any new PDU session on tributary 1, AMF-2 updates the UDM regarding the SMF ID selected for SMF PDU session creation. A PDU session may result in an update of the UDM for either SMF.

[0148] Figure 14Diagram 1400 illustrates a localized routing architecture for dual-booting support of MADS-PDU sessions according to various example implementations. To support dual-booting MADS-PDU sessions from one access network to another in a localized routing configuration, the UE (SUPI2) provides (received by the UE (SUPI1) during the registration process) a 5G-GUTI-1 and transmits a service request message (or a new NAS message) to the AMF-1 via the AMF-2. The AMF-1 decrypts and successfully performs an integrity protection check on the service request message (or new NAS message) transmitted by the UE (SUPI-1). The AMF-1 then transmits the SMF-1 ID and all other PDU session details to the AMF-2 on tributary 1. The AMF-2 can select the SMF and therefore the UPF to continue the PDU session using the "existing PDU session" type.

[0149] Figure 15 Figure 1500 illustrates an alternative local routing architecture for dual-booting support of MADS-PDU sessions, based on various example implementations. In this example, the UE camps on two access networks (e.g., NTN and TN) using the same AMF and different or the same UPF in the home network, or, in a local routing configuration for MADS-PDU sessions, camps on two branches in the same VPLMN. Operation in this architecture is related to... Figure 14 The operations described in the architecture 1400 are similar to those operations.

[0150] Figure 16 Diagram 1600 illustrates a localized routing architecture for dual-boot support of MADS-PDU session handover, based on various example implementations. To support PDU session handover from one access network to another in a localized routing configuration, the UE (SUPI2) provides (received on the UE (SUPI1) during the registration process) a 5G-GUTI-1 and transmits a service request message (or new NAS message) to the AMF-1 via the AMF-2. The AMF-1 decrypts and successfully performs an integrity protection check on the service request message (or new NAS message) transmitted by the UE (SUPI-1). The AMF-1 then transmits the SMF-1 and all other PDU session details (UE SUPI1 context) to the AMF-2 on tributary 1. The AMF-2 can use this context to select the SMF, and thus the UPF, to continue the PDU session using the "existing PDU session" type.

[0151] Figure 17Figure 1700 illustrates an alternative local routing architecture for dual-boot support of MADS-PDU session handover, based on various example implementations. To support PDU session handover from one access network to another in a local routing configuration, AMF-2 can update the UDM regarding the SMF ID selected for SMF PDU session creation during the activation of any new PDU session on tributary 1. Similarly, in tributary 2, when the AMF detects a transfer of a PDU session from tributary 1 (if the PDU session type is "existing PDU session," it obtains information from the UDM regarding the SMF to be selected), in this case, SMF-1.

[0152] The following provides some example layer diagrams for implementing dual-boot capability for dual-boot UEs.

[0153] Figure 18 Example layer diagram 1800 illustrates a dual-boot UE with a Single Subscriber Identity Module (SIM) and an instantiated Non-Access Stratum (NAS) layer, according to various example implementations. In this example, the Common Universal SIM (USIM) stores the NAS context of each instance of NAS-1 and NAS-2 in a separate base file (EF). Based on a service loss or service recovery on one branch, the other NAS entity can initiate a search using the same AS layer.

[0154] Figure 19 Example layer diagram 1900 illustrates a dual-booting UE with a single SIM and instantiated NAS, Access Stratum (AS), and Layer 2, according to various example implementations. In this example, the common USIM stores the NAS context for each instance of NAS-1 and NAS-2 in separate EFs, and the AS and Radio Link Control (RLC) layers are also instantiated. Based on service loss or service recovery on one of the tributaries, the other NAS and AS entities utilize the same Physical Layer (PHY) and RF for searching.

[0155] Figure 20 Example layer diagram 2000 illustrates a dual-boot UE with dual SIMs and instantiated NAS, Access Server (AS), and Layer 2, according to various example implementations. In this example, a separate USIM stores the NAS context for each NAS-1 / AS-1 and NAS-2 / AS-2 instance. The two NAS instances can exchange messages with each other. Based on service loss or service recovery on one tributary, the other NAS and AS entities utilize the same PHY and RF for searching.

[0156] Figure 21Example layer diagram 2100 of a dual-boot UE with two separate physical UEs is shown according to various example implementations. In this example, separate USIMs on the separate UEs store the corresponding NAS and AS contexts. The two NAS instances can exchange messages with each other. Based on service loss or service recovery on one of the tributaries, the other NAS and AS entities utilize the same PHY and RF for searching.

[0157] The following section provides some example session management messages that can be exchanged between the dual-boot UE and the access network during dual-boot operation.

[0158] Figure 22 Examples of 5G Session Management (5GSM) capability IE 2200 according to various example implementations are shown. The DualSteer-ST IE of the 5GSM capability IE 2200 can indicate the dual-booting functionality and booting modes supported by the dual-booting UE, for example, as transmitted in PDU session establishment request 515. These dual-booting functionalities and booting modes may include, but are not limited to: not supporting dual-booting; supporting dual-booting lower layers (DualSteer... DualSteer-LL functionality with any boot mode allowed by DualSteer-LL; supports MPTCP functionality with any boot mode and DualSteer-LL functionality with only active-standby boot mode; supports MPTCP functionality with any boot mode and DualSteer-LL functionality with any boot mode allowed by DualSteer-LL; supports Multipath Fast UDP Internet Connection (MPQUIC) functionality with any boot mode and DualSteer-LL functionality with only active-standby boot mode; supports MPQUIC functionality with any boot mode and DualSteer-LL functionality with any boot mode allowed by DualSteer-LL; supports MPTCP functionality with any boot mode, MPQUIC functionality with any boot mode and DualSteer-LL functionality with only active-standby boot mode; supports MPTCP functionality with any boot mode, MPQUIC functionality with any boot mode and DualSteer-LL functionality with any boot mode allowed by DualSteer-LL. These are just examples of the supported dual-boot functionality and boot modes.

[0159] As stated above, the information received by a dual-booting UE when it receives a message related to a dual-booting PDU session (e.g., the PDU session establishment accept message in 525) from the access network may include a dual-booting container, which includes various information related to the dual-booting PDU session. Figures 23A to 23C illustrate examples of dual-booting containers according to various example embodiments.

[0160] Figure 23A shows an example of a dual-boot container information element 2300 that includes various information related to a dual-boot PDU session. Figure 23B shows an example of dual-boot container content 2310 included in the dual-boot IE 2300. Figure 23C shows an example of dual-boot parameters 2320 included in the dual-boot container content 2310. This is only an example of information that can be included in a dual-boot container, and it may include additional information.

[0161] The dual-boot container IE 2300 transmits parameters associated with dual-boot functionality. In some example implementations, the dual-boot container IE 2300 is a type 6IE with a minimum length of 3 octets and a maximum length of 65538 octets. This is merely an example of a dual-boot IE. Dual-boot parameters 2320 are the contents of the dual-boot container and indicate parameters associated with dual-boot functionality (e.g., dual-boot rules). The dual-boot container content 2310 may include one or more dual-boot parameters.

[0162] Figure 24 Examples of dual-boot IE 2400s are shown, illustrating dual-boot specific information from the UE to the network or from the network to the UE according to various example implementations. In some examples, the dual-boot IE 2400 is a Type 4 information element with a length of 3 octets, but is not limited to that type or length of IE.

[0163] The first example field for dual-boot IE 2400 is the 3GPP primary access type (e.g., byte 3, bit 1). If this bit is set to 0, the 3GPP access used in dual-boot is not primary. If this bit is set to 1, the 3GPP access used in dual-boot is primary.

[0164] The second example field for dual-boot IE 2400 is the 3GPP secondary access type (e.g., byte 3, bit 2). If this bit is set to 0, the 3GPP access used in dual-boot is not secondary. If this bit is set to 1, the 3GPP access used in dual-boot is secondary.

[0165] The third example field of the dual-boot IE 2400 is the dual-boot registration (DSR) included only in the direction from the network to the UE (e.g., octet 3, bit 3). If this bit is set to 0, dual-boot registration is not enabled. If this bit is set to 1, dual-boot registration is enabled.

[0166] The fourth example field of the dual-boot IE 2400 is the single-branch PDU session DualSteer PDU (DSP) (e.g., octet 3, bit 4). If this bit is set to 0, the PDU session is not a dual-boot PDU. If this bit is set to 1, the PDU session is a dual-boot PDU.

[0167] Figure 25 An example of a PDU session establishment request 2500 transmitted by a UE to the network to initiate the establishment of a PDU session, according to various example implementations, is shown. This request can be transmitted by the UE to the network, for example... Figure 5 Operation 515. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0168] The first field may be an IE indicating whether the UE supports dual-booting functionality and includes 5GSM capability with dual-booting boot mode. The second field may be a dual-booting field indicating the UE supports dual-booting functionality and wishes to establish a PDU session for the affected tributary. The third field may be a dual-booting PDU session ID indicating the UE supports dual-booting functionality and wishes to establish a PDU session for the affected second tributary. This IE indicates the PDU session ID of the first tributary where the PDU session was previously created.

[0169] Figure 26 An example is shown of a PDU session establishment accept message 2600 transmitted from the network to the UE to indicate successful establishment of a PDU session, according to various example implementations. This request can be transmitted from the network to the UE, for example... Figure 5 Operation 520. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0170] The first field can be the dual-boot container described above with reference to Figures 23A to 23C. This information element can be included if the network establishes a PDU session for session management at the request of the UE.

[0171] Figure 27 An example is shown of a PDU session establishment rejection message 2700 transmitted from the network to the UE, indicating that a PDU session has not been successfully established, according to various example implementations. This request can be transmitted from the network to the UE, for example... Figure 5 Operation 525. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0172] The first field can be a 5GSM reason field indicating the reason (cause) why a dual-boot UE cannot establish a PDU session for dual-boot switching or service booting.

[0173] Figure 28An example of a PDU session modification request 2800 transmitted by a UE to request modification of a PDU session, according to various example implementations, is shown. This request can be transmitted by the UE to the network, for example... Figure 5 Operation 545. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0174] The first field can be a 5GSM capability field indicating whether the UE supports dual-booting functionality and, if the UE wishes to modify it, includes dual-booting mode. The second field can be a dual-booting field indicating that the UE supports dual-booting functionality and wishes to modify the dual-booting tributaries of the PDU session.

[0175] Figure 29 An example of a PDU session modification command message 2900, indicating a modification of the PDU session, transmitted from the network to the UE according to various example implementations, is shown. This request can be transmitted from the network to the UE, for example... Figure 5 Operation 550. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0176] The first field can be the dual-boot container described above with reference to Figures 23A to 23C. This information element can be included if the network establishes a PDU session for session management at the request of the UE.

[0177] Figure 30 An example of a PDU session release request 3000 transmitted by a UE to the network to request the release of a PDU session, according to various example implementations, is shown. This request can be transmitted by the UE to the network, for example... Figure 5 Operation 570. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0178] The first field can be a dual-booting field indicating which tributary of the PDU session the dual-booting UE wishes to release due to dual-booting functionality. This IE indicates which access (primary or secondary) is being released and whether the session supports dual-booting functionality.

[0179] Figure 31 An example of a PDU session release command 3100 transmitted from the network to the UE to instruct the release of a PDU session, according to various example implementations, is shown. This request can be transmitted from the network to the UE, for example... Figure 5 Operation 575. For the purposes of this description, only those fields related to dual-boot functionality will be described.

[0180] The first field can be a dual-boot field indicating that the dual-boot PDU session has been released.

[0181] Example In a first embodiment, a method includes: generating the first request message for establishing a first Protocol Data Unit (PDU) session with a first access network and sending it to the first access network, wherein the first request message includes an indication regarding support for dual-booting functionality; processing the first acceptance message, based on signaling received from the first access network, indicating that the first PDU session has been established with the first access network, wherein the first acceptance message further includes a PDU session identifier (ID) of the first PDU session; generating the second request message for establishing a second PDU session with a second access network and sending it to the second access network, wherein the second request message includes an indication regarding support for the dual-booting functionality and the PDU session ID of the first PDU session; and processing the second acceptance message, based on signaling received from the second access network, indicating that the second PDU session has been established with the second access network, wherein the first PDU session and the second PDU session are associated PDU sessions of the dual-booting functionality.

[0182] In a second embodiment, according to the method of the first embodiment, the first request message further includes an indication that the request type of the first request message is an initial request.

[0183] In a third embodiment, according to the method of the second embodiment, the second request message further includes an indication that the request type of the second request message is an initial request.

[0184] In the fourth embodiment, according to the method of the first embodiment, the first request message further includes an indication that the first PDU session is a Multiple Access DualSteer PDU (MADS-PDU) session, and the second request message further includes an indication that the second PDU session is the MADS-PDU session.

[0185] In the fifth embodiment, according to the method of the first embodiment, the first PDU session is a PDU session independent of the second PDU session.

[0186] In a sixth embodiment, according to the method of the first embodiment, the first receive message further includes a dual boot container, the dual boot container including information related to the dual boot functionality.

[0187] In the seventh embodiment, according to the method of the sixth embodiment, the information related to the dual-booting functionality includes UE routing policy (URSP) rules related to the service that selects the first access network or the second access network to exchange the service being performed, as well as parameters and parameter values ​​associated with the URSP rules.

[0188] In the eighth embodiment, according to the method of the first embodiment, the method further includes: generating a modification request for modifying the first PDU session with the first access network for sending to the first access network, wherein the modification request includes an indication of supporting the dual-boot functionality and an indication of the request type of the modification request for an existing PDU session.

[0189] In the ninth embodiment, according to the method of the eighth embodiment, the method further includes: processing a signaling received from the first access network that indicates that the establishment command of the first PDU session has been modified, wherein the establishment command includes the PDU session ID of the first PDU session and a dual boot container including information related to the dual boot functionality.

[0190] In the tenth embodiment, according to the method of the eighth embodiment, the method further includes: processing a modification rejection message indicating that the first access network has not modified the first PDU session based on signaling received from the first access network, wherein the modification rejection message includes a reason code indicating the reason for not modifying the first PDU session.

[0191] In the eleventh embodiment, according to the method of the first embodiment, the method further includes: generating a registration request for the first access network to be sent to the first access network, so that the first access network supporting the dual-boot functionality becomes the primary access.

[0192] In the twelfth embodiment, according to the method of the eleventh embodiment, the registration request includes an indication and identifier of the dual-boot functionality.

[0193] In the thirteenth embodiment, according to the method of the twelfth embodiment, the identifier includes a subscription persistent identifier (SUPI).

[0194] In the fourteenth embodiment, according to the method of the eleventh embodiment, the registration request is generated based on the type of the first access network and its connection to the core network, so as to receive all paging and mobile termination messages through the primary access.

[0195] In the fifteenth embodiment, according to the method of the eleventh embodiment, the method further includes: processing a registration acceptance message indicating that the first access network is the primary access network being served, based on signaling received from the first access network.

[0196] In the sixteenth embodiment, according to the method of the fifteenth embodiment, the registration acceptance message includes a fifth-generation globally unique temporary identifier (5G-GUTI), an indication of a public terrestrial mobile network (PLMN) supporting the dual-booting functionality, and an indication of subscribing to support the dual-booting functionality.

[0197] In the seventeenth embodiment, according to the method of the first embodiment, the method further includes: determining that the first access network does not meet the criteria for operating as preferred access for a service being executed; generating a session release message for sending to the first access network so that the first access network releases the first PDU session; and processing a session release command indicating that the first access network has released the first PDU session based on signaling received from the first access network, wherein the second access network supporting the second PDU session operates as preferred access for the service being executed based on URSP rules.

[0198] In the eighteenth embodiment, according to the method described in the seventeenth embodiment, the method further includes: determining, based on the link quality of the first access network, that the first access network does not meet the criteria.

[0199] In the nineteenth embodiment, according to the method of the seventeenth embodiment, the method further includes: generating a third request for establishing a third PDU session with the first access network for sending to the first access network, wherein the third request includes an indication regarding support for the dual-boot functionality; and processing a third acceptance message indicating that the third PDU session has been established with the first access network based on signaling received from the first access network, wherein the third acceptance message further includes a PDU session ID of the third PDU session.

[0200] In the twentieth embodiment, according to the method of the first embodiment, the method further includes: generating a service request to be sent to the first access network, so that the first access network establishes user plane resources for the service being executed on the dual-booting functional first access network, and makes the first access network the primary access.

[0201] In the twenty-first embodiment, according to the method of the twenty-first embodiment, the service request includes an indication and identifier of the dual-boot functionality.

[0202] In the twenty-second embodiment, according to the method of the twenty-first embodiment, the identifier includes a subscription persistent identifier (SUPI).

[0203] In the twenty-third embodiment, according to the method of the twenty-tenth embodiment, the generation of the service request to make the first access network the primary access is based on the type of the first access network and its connection to the core network, so as to receive all paging and mobile termination messages through the primary access.

[0204] In the twenty-fourth embodiment, according to the method of the twenty-tenth embodiment, the method further includes: processing a service acceptance message indicating that the first access network is the primary access for the service based on signaling received from the first access network.

[0205] In the twenty-fifth embodiment, according to the method of the twenty-fourth embodiment, the service acceptance message includes a fifth-generation globally unique temporary identifier (5G-GUTI), an indication of a public terrestrial mobile network (PLMN) supporting the dual-booting functionality, and an indication of subscribing to support the dual-booting functionality.

[0206] In the twenty-sixth embodiment, according to the method of the first embodiment, the method further includes: determining, based on UE routing policy (URSP) rules, that the first access network does not meet the criteria for operating as preferred access for a service being executed; generating a session suspension request to be sent to the first access network so that the first access network suspends the first PDU session; and processing, based on signaling received from the first access network, a session suspension acceptance message indicating that the first access network has suspended the first PDU session, wherein the second PDU session operates as the preferred access for the service.

[0207] In the twenty-seventh embodiment, according to the method of the twenty-sixth embodiment, the determination that the first access network does not meet the criterion for becoming the preferred access is based on the link quality of the first access network.

[0208] In the twenty-eighth embodiment, according to the method of the twenty-sixth embodiment, the method further includes: generating a session recovery request for resuming the first PDU session with the first access network for sending to the first access network; and processing a session recovery acceptance message indicating that the first access network has resumed the first PDU session based on signaling received from the first access network.

[0209] In the twenty-ninth embodiment, one or more processors are configured to perform any of the methods described according to the first to twenty-eighth embodiments.

[0210] In the thirtieth embodiment, a user equipment (UE) is configured to perform any of the methods described according to the first to twenty-eighth embodiments.

[0211] In a thirty-first embodiment, a method includes: processing a first request message for establishing a first Protocol Data Unit (PDU) session with a first access network based on signaling received from a first UE with dual-booting functionality, wherein the first request message includes an indication that the first UE supports dual-booting functionality; selecting a Session Management Function (SMF) and a User Plane Function (UPF) for establishing the first PDU session with the first UE; reporting an SMF identifier (ID) of the SMF to a Unified Data Management (UDM) function; and generating a first acceptance message indicating that the first PDU session has been established with the first access network for transmission to the first UE, wherein the first acceptance message further includes a PDU session identifier (ID) of the first PDU session.

[0212] In the thirty-second embodiment, according to the method of the thirty-first embodiment, the first request message further includes an indication that the request type of the first request message is an initial request.

[0213] In the thirty-third embodiment, according to the method of the thirty-first embodiment, the first request message further includes an indication that the PDU session is a Multiple Access DualSteer PDU (MADS-PDU) session.

[0214] In the thirty-fourth embodiment, according to the method of the thirty-first embodiment, the first accept message further includes a dual boot container, the dual boot container including information related to the dual boot functionality.

[0215] In the thirty-fifth embodiment, according to the method of the thirty-fourth embodiment, the information related to the dual-booting functionality includes rules processed by the UPF for selecting the first access network or the second access network to exchange services being performed by the dual-booting UE, as well as parameters and parameter values ​​associated with the rules.

[0216] In the thirty-sixth embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a modification request for modifying the first PDU session with the first access network based on signaling received from the first UE, wherein the modification request includes an indication regarding the first UE supporting the dual-boot functionality and an indication regarding the request type of the modification request for an existing PDU session.

[0217] In the thirty-seventh embodiment, according to the method of the thirty-sixth embodiment, the method further includes: generating an establishment command indicating that the first PDU session has been modified for sending to the first UE, wherein the establishment command includes the PDU session ID of the first PDU session and a dual boot container including information related to the dual boot functionality.

[0218] In the thirty-eighth embodiment, according to the method of the thirty-sixth embodiment, the method further includes: generating a modification rejection message indicating that the first access network has not modified the first PDU session for sending to the first UE, wherein the modification rejection message includes a reason code indicating the reason for not modifying the first PDU session.

[0219] In the thirty-ninth embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a registration request for the first access network based on signaling received from the first UE, so that the dual-booting functional first access network becomes the primary access for the service being performed by the dual-booting UE.

[0220] In the fortieth embodiment, according to the method of the thirty-ninth embodiment, the registration request includes an indication of the dual-boot functionality and an identifier of the first UE.

[0221] In the forty-first embodiment, according to the method of the forty-first embodiment, the identifier of the first UE includes the subscription hidden identifier (SUCI) of the first UE.

[0222] In the forty-second embodiment, according to the method of the thirty-ninth embodiment, the method further includes: generating a registration acceptance message indicating that the first access network is the primary access of the dual-booting functional UE for sending to the first UE.

[0223] In the forty-third embodiment, according to the method described in the forty-second embodiment, the registration acceptance message includes the first UE's fifth-generation globally unique temporary identifier (5G-GUTI), an indication of a Public Land Mobile Network (PLMN) supporting the dual-booting functionality, and an indication of the first UE's subscription to support the dual-booting functionality.

[0224] In the forty-fourth embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a session release message based on signaling received from the first UE, so that the first access network releases the first PDU session; and generating a session release command indicating that the first access network has released the first PDU session for transmission to the first UE, wherein the second access network is operating as preferred access to a service performed by the dual-booting functional UE as support for the second PDU session.

[0225] In the forty-fifth embodiment, according to the method of the forty-fourth embodiment, the method further includes: processing a request for establishing a new PDU session with the first access network based on signaling received from the first UE, wherein the request includes an indication that the first UE supports dual boot functionality; and generating an acceptance message indicating that the new PDU session has been established with the first access network for transmission to the first UE, wherein the acceptance message further includes a PDU session ID of the new PDU session.

[0226] In the forty-sixth embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a service request for the first access network based on signaling received from the first UE, so that the first access network with dual-boot functionality becomes the primary access for the service being performed by the dual-boot UE.

[0227] In the forty-seventh embodiment, according to the method of the forty-sixth embodiment, the service request includes an indication of the dual-booting functionality and an identifier of the first UE.

[0228] In the forty-eighth embodiment, according to the method of the forty-seventh embodiment, the identifier of the first UE includes the subscription hidden identifier (SUCI) of the first UE.

[0229] In the forty-ninth embodiment, according to the method of the forty-sixth embodiment, the method further includes: generating a service acceptance message indicating that the first PDU session is the primary access service being performed by the dual-booting UE for sending to the first UE.

[0230] In the fiftieth embodiment, according to the method of the forty-ninth embodiment, the service acceptance message includes the first UE's fifth-generation globally unique temporary identifier (5G-GUTI), an indication of a public terrestrial mobile network (PLMN) supporting the dual-booting functionality, and an indication of the first UE's subscription to support the dual-booting functionality.

[0231] In the fifty-first embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a session suspension request to suspend the first PDU session on the first access network based on signaling received from the first UE; and generating a session suspension acceptance message indicating that the first access network has suspended the first PDU session for sending to the first UE, wherein the second access network operates as the preferred access for the second PDU session and supports the service being performed by the dual-booted UE.

[0232] In the fifty-second embodiment, according to the method of the fifty-first embodiment, the method further includes: processing a session recovery request for resuming the first PDU session with the first access network based on signaling received from the first UE; and generating a session recovery acceptance message indicating that the first access network has resumed the first PDU session for sending to the first UE.

[0233] In the fifty-third embodiment, according to the method of the thirty-first embodiment, the method further includes: verifying to the UDM function that the subscription of the first UE supports the dual-boot functionality.

[0234] In the fifty-fourth embodiment, according to the method described in the thirty-first embodiment, the method further includes: determining whether the first PDU session is a home routing session or a local routing session.

[0235] In the fifty-fifth embodiment, one or more processors are configured to perform any of the methods described according to the thirty-first to fifty-fourth embodiments.

[0236] In the fifty-sixth embodiment, a network function is configured to perform any of the methods described according to the thirty-first to fifty-fourth embodiments.

[0237] In a fifty-seventh embodiment, a method includes: processing a first request message for establishing a first Protocol Data Unit (PDU) session with a first access network based on signaling received from a first UE of a dual-booting functional user equipment (UE), wherein the first request message includes an indication of supporting dual-booting functionality and a session identifier (ID) of a second PDU session associated with the dual-booting functional UE; determining the SMF hosting the second PDU session based on a mapping between the SMF ID of a Session Management Function (SMF) hosting the second PDU session and the session ID stored in a Unified Data Management (UDM) function; selecting the SMF hosting the second PDU session to establish the first PDU session with the first UE; and generating an acceptance message indicating that the first PDU session has been established with the first access network for transmission to the first UE.

[0238] In the fifty-eighth embodiment, one or more processors are configured to perform the method according to the fifty-seventh embodiment.

[0239] In the fifty-sixth embodiment, a network function is configured to perform the method according to the fifty-seventh embodiment.

[0240] Those skilled in the art will understand that the example embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Example hardware platforms for implementing the example embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Example embodiments of the methods described above may be embodied as programs containing lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0241] Although this application describes various embodiments that have different features in various combinations, those skilled in the art will understand that any feature of one embodiment can be combined with features of other embodiments in any way that is not expressly excluded or that is not functionally or logically inconsistent with the operation of the device or the specified function of the disclosed embodiment.

[0242] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0243] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover modifications and variations thereof, provided they fall within the scope of the appended claims and their equivalents.

Claims

1. An apparatus comprising a processing circuit configured to: A first request message is generated for establishing a first Protocol Data Unit (PDU) session with a first access network and sent to the first access network, wherein the first request message includes an indication of supporting dual-boot functionality; Based on the signaling received from the first access network, a first accept message indicating that a first PDU session has been established with the first access network is processed, wherein the first accept message further includes a PDU session identifier (ID) of the first PDU session. A second request message is generated for establishing a second PDU session with the second access network and sent to the second access network, wherein the second request message includes an indication of supporting the dual-boot functionality and the PDU session ID of the first PDU session; as well as Based on signaling received from the second access network, a second accept message is processed indicating that a second PDU session has been established with the second access network, wherein the first PDU session and the second PDU session are associated PDU sessions of the dual-boot functionality.

2. The apparatus of claim 1, wherein the first request message further includes an indication that the request type of the first request message is an initial request.

3. The apparatus of claim 2, wherein the second request message further includes an indication that the request type of the second request message is an initial request.

4. The apparatus of claim 1, wherein the first request message further includes an indication that the first PDU session is a Multiple Access DualSteer PDU (MADS-PDU) session, and the second request message further includes an indication that the second PDU session is the MADS-PDU session.

5. The apparatus of claim 1, wherein the first PDU session is a PDU session independent of the second PDU session.

6. The apparatus of claim 1, wherein the first receive message further includes a dual boot container, the dual boot container including information related to the dual boot functionality.

7. The apparatus of claim 6, wherein the information related to the dual-boot functionality includes UE routing policy (URSP) rules related to the service that selects the first access network or the second access network to exchange services being performed, and parameters and parameter values ​​associated with the URSP rules.

8. The apparatus of claim 1, wherein the processing circuit is further configured to: A modification request for modifying the first PDU session with the first access network is generated and sent to the first access network, wherein the modification request includes an indication of supporting the dual-boot functionality and an indication of the request type for the existing PDU session.

9. The apparatus of claim 8, wherein the processing circuit is further configured to: Based on the signaling received from the first access network, the processing indicates that the establishment command of the first PDU session has been modified, wherein the establishment command includes the PDU session ID of the first PDU session and a dual boot container including information related to the dual boot functionality.

10. The apparatus of claim 8, wherein the processing circuit is further configured to: Based on signaling received from the first access network, a modification rejection message indicating that the first access network has not modified the first PDU session is processed, wherein the modification rejection message includes a reason code indicating the reason for not modifying the first PDU session.

11. The apparatus of claim 1, wherein the processing circuit is further configured to: A registration request is generated for the first access network and sent to the first access network to make the first access network, which supports the dual-boot functionality, the primary access network.

12. The apparatus of claim 11, wherein the registration request includes an indication and identifier of the dual-boot functionality.

13. The apparatus of claim 12, wherein the identifier includes a Subscription Permanent Identifier (SUPI).

14. The apparatus of claim 11, wherein the processing circuitry generates the registration request based on the type of the first access network and its connection to the core network, so as to receive all paging and mobile termination messages through the primary access.

15. The apparatus of claim 11, wherein the processing circuit is further configured to: Based on the signaling received from the first access network, a registration acceptance message indicating that the first access network is the primary access network being served is processed.

16. The apparatus of claim 15, wherein the registration acceptance message includes a fifth-generation globally unique temporary identifier (5G-GUTI), an indication of a public terrestrial mobile network (PLMN) supporting the dual-boot functionality, and an indication of subscribing to a service supporting the dual-boot functionality.

17. The apparatus of claim 1, wherein the processing circuit is further configured to: It is determined that the first access network does not meet the criteria for operation as the preferred access for the service being performed; Generate a session release message to send to the first access network, so that the first access network releases the first PDU session; and Based on signaling received from the first access network, a session release command is processed indicating that the first access network has released the first PDU session, wherein the second access network supporting the second PDU session operates as the preferred access for the service being executed based on URSP rules.

18. A method, the method comprising: Based on signaling received from a first UE with dual-boot functionality, a first request message for establishing a first protocol data unit (PDU) session with a first access network is processed, wherein the first request message includes an indication that the first UE supports dual-boot functionality; Select the Session Management Function (SMF) and User Plane Function (UPF) used to establish the first PDU session with the first UE. Report the SMF identifier (ID) of the SMF to the Unified Data Management (UDM) function; and A first accept message is generated indicating that a first PDU session has been established with the first access network for transmission to the first UE, wherein the first accept message further includes a PDU session identifier (ID) of the first PDU session.

19. The method of claim 18, wherein the first request message further includes an indication that the request type of the first request message is an initial request.

20. The method of claim 18, wherein the first request message further includes an indication that the PDU session is a Multiple Access DualSteer PDU (MADS-PDU) session.

Images