Method for registering a dual terminal to a dual access network

Abstract

The present disclosure relates generally to wireless communication. A method performed by a first core network element includes receiving, from a first wireless device, a first message for a registration request with a first wireless network, wherein: the first wireless device has a dual boot relationship with a second wireless device; the first wireless device and the second wireless device are respectively identified by a first SUPI and a second SUPI; the first message carries at least one of: a first 5G-GUTI of the first wireless device; a SUCI of the first wireless device; a dual boot capability of the first wireless device; a first indication that the first wireless device has the dual boot capability; or a second indication that the first wireless device has the dual boot relationship with the second wireless device; and obtaining at least one subset of first context information for the first wireless device.

Description

Technical Field

[0001] This disclosure relates to wireless communications including 5G and 6G technologies, and in particular, to enabling a first wireless device to securely register with and communicate with a wireless communication network, taking into account a second wireless device, wherein the first and second wireless devices have a dual steer relationship. Background Technology

[0002] In a communication network, mutual authentication between the UE and the communication network can be performed to allow only authenticated UEs and authenticated communication networks to communicate with each other. An efficient and robust authentication mechanism involving two wireless devices with a dual-booting relationship is crucial for providing secure communication between dual-booting capable wireless devices and the wireless network. Summary of the Invention

[0003] This disclosure discloses methods, systems, apparatus, and storage media relating to wireless communication. An embodiment is described that enables a first wireless device to securely register with and communicate with a wireless communication network, taking into account a second wireless device, wherein the first and second wireless devices have a dual-booting relationship.

[0004] In one embodiment, this disclosure describes a method for wireless communication. The method, performed by a first core network element, includes: receiving from a first wireless device a first message for a registration request to a first wireless network, wherein: the first wireless device and a second wireless device have a dual-booting relationship, and the first and second wireless devices share the same set of subscription data; the first and second wireless devices are identified by a first Subscription Permanent Identifier (SUPI) and a second SUPI, respectively; the first message carries at least one of: a first 5G Globally Unique Temporary Identifier (5G-GUTI) of the first wireless device; a Subscription Hidden Identifier (SUCI) of the first wireless device; dual-booting capability of the first wireless device; a first indication indicating that the first wireless device possesses dual-booting capability; or a second indication indicating that the first wireless device and the second wireless device have a dual-booting relationship; and obtaining at least one subset of first context information for the first wireless device, the first context information including at least one of: a second SUPI; an identifier or address of a second core network element serving the second wireless device; the access type of the second wireless device; or the status of the second wireless device.

[0005] In one embodiment, this disclosure describes a method for wireless communication. The method, performed by a first core network element serving a first wireless device, includes: receiving a first message from a second core network element serving a second wireless device, the first message including at least one of: a first subscription permanent identifier (SUPI) of the first wireless device, or context information for the first wireless device, wherein: the first wireless device and the second wireless device have a dual-booting relationship; the first wireless device and the second wireless device are identified by the first SUPI and the second SUPI, respectively; the context information includes at least one of: a second SUPI; an identifier or address of the second core network element; an access type of the first wireless device; dual-booting capability of the first wireless device; or the state of the first wireless device.

[0006] In one embodiment, this disclosure describes a method for wireless communication. The method, performed by a first wireless device, includes: receiving a first message from a first core network element, wherein: the first wireless device and a second wireless device served by a second core network element have a dual-bootstrapping relationship; the first wireless device and the second wireless device are identified by a first Subscription Permanent Identifier (SUPI) and a second SUPI, respectively; and the first message carries at least one of: a 5G Globally Unique Temporary Identifier (5G-GUTI) of the second wireless device; the access type of the second wireless device; the state of the second wireless device; or a dual-bootstrapping strategy applicable to the first wireless device and the second wireless device.

[0007] In one embodiment, this disclosure describes a method for wireless communication. The method, performed by a first wireless device, includes receiving a first message from a first core network element, wherein: the first wireless device and a second wireless device served by a second core network element have a dual-bootstrapping relationship; the first and second wireless devices are identified by a first Subscription Permanent Identifier (SUPI) and a second SUPI, respectively; and the first message carries at least one of: a 5G Globally Unique Temporary Identifier (5G-GUTI) of the second wireless device; the access type of the second wireless device; the state of the second wireless device; or a dual-bootstrapping strategy applicable to the first and second wireless devices.

[0008] In another embodiment, a network element or wireless device including a processor and memory is disclosed. The processor can be configured to read computer code from the memory to implement any of the methods described above.

[0009] In yet another embodiment, a computer program product is disclosed, comprising a non-transitory computer-readable program medium having computer code stored thereon. When executed by a processor, the computer code can cause the processor to perform any of the methods described above.

[0010] The above embodiments, as well as other aspects and alternatives to their implementation, are explained in more detail in the following drawings, description and claims. Attached Figure Description

[0011] Figure 1 An exemplary communication network is shown, including various terminal devices, carrier networks, data networks, and service applications.

[0012] Figure 2 Exemplary network functions or network nodes in a communication network are shown.

[0013] Figure 3 An exemplary network function or network node in a wireless communication network is shown.

[0014] Figure 4 An example wireless network node (or network element, network entity, entity) is shown.

[0015] Figure 5 An example user device is shown.

[0016] Figure 6 An exemplary UE with dual radio access to a wireless network is shown.

[0017] Figure 7 An exemplary dual-boot configuration with two UEs is shown.

[0018] Figure 8 Two UEs with a dual-booting relationship are shown.

[0019] Figures 9A to 9B An exemplary logic flow is shown for a UE with dual-booting capability to register to the network, taking into account its accompanying dual-booting UE. Detailed Implementation

[0020] like Figure 1The exemplary communication network shown in 100 may include terminal devices 110 and 112, carrier network 102, various service applications 140, and other data networks 150. Carrier network 102 may include, for example, access network 120 and core network 130. Carrier network 102 may be configured to transmit voice, data, and other information (collectively, data traffic) between terminal devices 110 and 112, between terminal devices 110 and 112 and service applications 140, or between terminal devices 110 and 112 and other data networks 150. Communication sessions and corresponding data paths may be established and configured for such data transmission. Access network 120 may be configured to provide network access to core network 130 to terminal devices 110 and 112. Access network 120 may, for example, support wireless access via radio resources or wired access. Core network 130 may include various network nodes or network functions configured to control communication sessions and perform network access management and data traffic routing. Service application 140 can be hosted by various application servers and is accessible to terminal devices 110 and 112 via the core network 130 of operator network 102. Service application 140 can be deployed as a data network outside of core network 130. Similarly, other data networks 150 can be accessible to terminal devices 110 and 112 via core network 130 and can be presented as the data destination or data source for specific communication sessions instantiated in operator network 102.

[0021] Figure 1 The core network 130 may include various geographically distributed and interconnected network nodes or functions to provide network coverage for the service area of ​​the operator network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or software entities. Each network node may be configured with one or more types of network functions. These network nodes or network functions may collectively provide configuration and routing capabilities for the core network 130. In this disclosure, the terms "network node" and "network function" are used interchangeably.

[0022] Figure 2 An exemplary division of network functions in the core network 130 of the communication network 200 is also shown. Although Figure 2 Only a single instance of a network node or function is shown, but those skilled in the art will readily understand that each of these network nodes can be instantiated as multiple instances of network nodes distributed throughout the core network 130. Figure 2As shown, the core network 130 may include, but is not limited to, network nodes such as Access Management Network Node (AMNN) 230, Authentication Network Node (AUNN) 260, Network Data Management Network Node (NDMNN) 270, Session Management Network Node (SMNN) 240, Data Routing Network Node (DRNN) 250, Policy Control Network Node (PCNN) 220, and Application Data Management Network Node (ADMNN) 210. Exemplary signaling and data exchange between various types of network nodes through various communication interfaces is provided by… Figure 2 The solid lines in the diagram represent various signaling and data exchanges. These exchanges can be carried by signaling or data messages that follow a predetermined format or protocol.

[0023] Above Figure 1 and Figure 2 The implementation methods described herein can be applied to both wireless and wired communication systems. Figure 3 It shows the basis Figure 2 An exemplary cellular wireless communication network 300 is a general implementation of the communication network 200. Figure 3 The wireless communication network 300 is shown to include a user equipment (UE) 310 (acting as...) Figure 2 Terminal equipment 110), Radio Access Network (RAN) 320 (acting as) Figure 2 The network comprises an access network 120, a data network (DN) 150, and a core network 130, the core network 130 including an access management function (AMF) 330 (which acts as...). Figure 2 AMNN 230), Session Management Node (SMNN) 340 (acting as AMNN 230), Session Management Node (SMNN) 340 Figure 2 SMNN 240), Application Function (AF) 390 (acting as Figure 2 ADMNN 210), User Plane Function (UPF) 350 (acting as Figure 2 DRNN 250), policy control function 322 (acting as Figure 2 PCNN 220), Authentication Server Function (AUSF) 360 (acting as Figure 2 AUNN 260) and Unified Data Management (UDM) function 370 (acting as Figure 2 UDMNN 2). Again, although Figure 3 Only a single instance of some network functions or nodes for the wireless communication network 300 (particularly the core network 130) is shown, but those skilled in the art will readily understand that each of these network nodes or functions can have multiple instances distributed throughout the wireless communication network 300. While AF 390 in Figure 3While depicted as part of the core network 130, these functions can be considered associated with specific service applications 140 and can be considered outside the core network 140. In this disclosure, the various functions deployed in the wireless network as described above can also be referred to as functional entities, which can be implemented as network nodes, network elements, or logical functions via hardware, software, or a combination thereof.

[0024] exist Figure 3 In this implementation, UE 310 can be configured to access core network 130 via RAN 320 for various types of mobile devices. UE 310 can include, but is not limited to, mobile phones, laptops, tablets, Internet of Things (IoT) devices, distributed sensor network nodes, wearable devices, and the like. The UE can also be a UE with multi-access edge computing (MEC) capabilities that support edge computing. For example, RAN 320 can include multiple radio base stations distributed throughout the service area of ​​the operator's network. Communication between UE 310 and RAN 320 can be achieved through various means, such as... Figure 3 It is carried in the air (OTA) radio interface indicated by 311 in the document.

[0025] Continue to refer to Figure 3 The UDM 370 can form a persistent storage or database for user contract and subscription data. The UDM can also include an authentication credential store and processing capabilities (ARPF, such as...). Figure 3 As indicated by 370, the UDM / ARPF 370 is used to store long-term security credentials for user authentication and to perform calculations on encryption keys using such long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, the UDM / ARPF 370 can be located in a secure network environment of a network operator or a third party.

[0026] The AMF / SEAF 330 can communicate with RAN 320, SMF 340, AUSF 360, UDM / ARPF 370, and Policy Control Function (PCF) 322 via communication interfaces indicated by various solid lines connecting these network nodes or functions. The AMF / SEAF 330 can handle UE-to-Non-Access Stratum (NAS) signaling management, UE 310 configuration registration and access to the core network 130, and SMF 340 allocation to support specific UE communication needs. The AMF / SEAF 330 can also handle UE mobility management. The AMF may also include Security Anchoring Functions (SEAFs, such as...) Figure 3As indicated by AMF 330 (described in more detail below), it interacts with AUSF 360 and UE 310 for user authentication and management of encryption / decryption keys at various levels. AUSF 360 can terminate user registration / authentication / key generation requests from AMF / SEAF 330 and interacts with UDM / ARPF 370 to complete such user registration / authentication / key generation.

[0027] SMF 340 can be assigned by AMF / SEAF 330 for specific communication sessions instantiated in wireless communication network 300. SMF 340 can be responsible for assigning UPF 350 to support communication sessions and data flows in the user data plane, and for configuring / regulating the assigned UPF 350 (e.g., defining packet detection and forwarding rules for the assigned UPF 350). As an alternative to assignment by SMF 340, UPF 350 can be assigned by AMF / SEAF 330 for specific communication sessions and data flows. UPF 350, assigned and configured by SMF 340 and AMF / SEAF 330, can be responsible for data routing and forwarding, and for reporting network usage for specific communication sessions. For example, UPF 350 can be responsible for routing end-to-end data flows between UE 310 and DN 150, and between UE 310 and serving application 140. DN 150 and service application 140 may include, but are not limited to, data networks and services provided by the operator of wireless communication network 300 or by third-party data networks and service providers.

[0028] PCF 322 can manage and provide AMF / SEAF 330 and SMF 340 with policies and rules at various levels applicable to communication sessions associated with UE 310. Therefore, for example, AMF / SEAF 330 can assign SMF 340 to a communication session based on the policies and rules associated with UE 310 and obtained from PCF 322. Similarly, SMF 340 can assign UPF 350 to handle data routing and forwarding for the communication session based on the policies and rules obtained from PCF 322.

[0029] Although Figures 1 to 3 The various exemplary embodiments described below are based on cellular wireless communication networks, but the scope of this disclosure is not limited thereto, and the basic principles are applicable to other types of wireless and wired communication networks.

[0030] Figure 3Network identity and data security in the wireless communication network 300 can be managed via user authentication processes provided by AMF / SEAF 330, AUSF360, and UDM / ARPF 370. Specifically, UE 310 can first communicate with AMF / SEAF 330 for network registration, and then be authenticated by AUSF 360 based on user contracts and subscription data in UDM / ARPF 370. After user authentication to the wireless communication network 300, the communication session established for UE 310 can then be protected by various levels of encryption / decryption keys. The generation and management of various keys can be coordinated by AUSF360 and other network functions in the communication network 300.

[0031] In wireless communication networks, application functions (AFs, or application function entities) can provide application services to UEs. AFs can be deployed in various locations, such as the UE's home public land mobile network (HPLMN), the UE's access public land mobile network (VPLMN) (e.g., when the UE roams to a VPLMN), or a data network (DN) outside the HPLMMN and VPLMN. Secure or encrypted data communication between the AF and the UE can be implemented within an application-oriented authentication and key management (AKMA) framework. The AKMA framework can be based on various authentication processes, such as the 5G Authentication and Key Agreement (5G-AKA) method, the Extensible Authentication Protocol for 3G-AKA (EAP-AKA) method, the Extensible Authentication Protocol – Transport Layer Security (EAP-TLS) method, or similar methods.

[0032] Figure 4 An example of an electronic device 500 is shown for implementing various network nodes, network elements, network entities, such as network base stations (e.g., radio access network nodes), core networks (CNs), core network elements / entities (e.g., AMFs, UDMs, AAnFs, etc.), operations and maintenance (OAM) systems, and the like. Optionally, in one embodiment, the example electronic device 500 may include radio transmit / receive (Tx / Rx) circuitry 508 for transmitting / receiving communications with the UE and / or other base stations. Optionally, in one embodiment, the electronic device 500 may also include network interface circuitry 509 for enabling the base station to communicate with other base stations and / or the core network, such as optical or wired interconnects, Ethernet, and / or other data transmission media / protocols. The electronic device 500 may optionally include an input / output (I / O) interface 506 for communication with operators or similar personnel.

[0033] Electronic device 500 may also include system circuitry 504. System circuitry 504 may include one or more processors 521 and / or memory 522. Memory 522 may include operating system 524, instructions 526, and parameters 528. Instructions 526 may be configured for one or more processors 521 to perform functions of the network node. Parameters 528 may include parameters for supporting the execution of instructions 526. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping allocation, and / or other parameters.

[0034] In this disclosure, network functions / network entities / entities (such as AMF, AUSF, UDM, AAnF, NEF, and AF) may be implemented in hardware, software, or a combination of hardware and software, and may be implemented or integrated in electronic device 500. They may also be implemented as logical entities hosted by electronic device 500.

[0035] Figure 5An example of an electronic device 600 for implementing a terminal device (e.g., a UE) is shown. The UE 600 may be a mobile device, such as a smartphone or a mobile communication module installed in a vehicle. The UE 600 may include some or all of the following: a communication interface 602, system circuitry 604, input / output interfaces (I / O) 606, display circuitry 608, and storage device 609. The display circuitry may include a user interface 610. The system circuitry 604 may include any combination of hardware, software, firmware, or other logic / circuit. The system circuitry 604 may be implemented, for example, using one or more system-on-chip (SoC), application-specific integrated circuit (ASIC), discrete analog and digital circuitry, and other circuitry. The system circuitry 604 may be part of an implementation of any desired functionality in the UE 600. In this regard, system circuitry 604 may include logic that facilitates, for example, decoding and playing music and video, such as MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user input; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for (for example) internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on user interface 610. User interface 610 and input / output (I / O) interface 606 may include a graphical user interface, touch-sensitive display, haptic feedback or other haptic output, voice or facial recognition input, buttons, switches, speakers, and other user interface elements. Additional examples of I / O interface 606 may include a microphone, video and still image camera, temperature sensor, vibration sensor, rotation and orientation sensor, headset and microphone input / output jacks, Universal Serial Bus (USB) connector, memory card slot, radiation sensor (e.g., IR sensor), and other types of input.

[0036] refer to Figure 5The communication interface 602 may include radio frequency (RF) transmit (Tx) and receive (Rx) circuitry 616, which processes the transmission and reception of signals via one or more antennas 614. The communication interface 602 may include one or more transceivers. This transceiver may be a wireless transceiver, including modulation / demodulation circuitry, a digital-to-analog converter (DAC), a shaping table, an analog-to-digital converter (ADC), filters, waveform shapers, preamplifiers, power amplifiers, and / or other logic for transmission and reception via one or more antennas or (for some devices) via a physical (e.g., wired) medium. The transmitted and received signals may conform to any of a variety of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM), frequency channels, bit rates, and encodings. As a specific example, communication interface 602 may include a transceiver supporting transmission and reception under 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA)+, 4G / Long Term Evolution (LTE), 5G, 6G, or any next-generation communication. However, the techniques described below are applicable to other wireless communication technologies, whether originating from the 3rd Generation Partnership Project (3GPP), the GSM Association, 3GPP2, IEEE, or other partners or standards bodies.

[0037] refer to Figure 5 System circuitry 604 may include one or more processors 621 and memory 622. Memory 622 stores, for example, an operating system 324, instructions 626, and parameters 628. Processor 621 is configured to execute instructions 626 to perform desired functions for UE 600. Parameters 628 can be provided and specify configuration and operational options for instructions 626. Memory 622 may also store any BT, WiFi, 3G, 4G, 5G, or other data that UE 600 will send or has received via communication interface 602. In various embodiments, system power for UE 600 may be supplied by power storage devices such as batteries or transformers.

[0038] UE security parameters and dual radio access

[0039] When a UE uses multiple radio connections via multiple radio access points, for each radio connection, the UE needs to register with the AMF associated with or assigned to the radio access point (i.e., the AMF serves the radio access point). In this disclosure, for simplicity, the radio access point may be referred to as a radio. For each successful registration (i.e., for each radio connection or for each radio), the UE can maintain a security context, which includes a set of security parameters such as a Key Set Identifier (KSI) (e.g., ngKSI (Next Generation KSI)), a 5G-GUTI (5G Globally Unique Temporary Identifier), and a KAMF (AMF key, also denoted as K). AMF The prefix K means "key" and KgNB (i.e., the key used for gNB).

[0040] In some example implementations, KAMF is derived from ME (Mobile Equipment, which refers to a part of the UE along with other parts of the UE, such as the Universal Subscriber Identity Module (USIM)) and SEAF from K SEAF Derived keys. KAMF can be used to generate integrity keys (such as K...) for example, for Non-Access Stratum (NAS) signaling. NASint ) and encryption keys (such as K) NASenc ), keys for RAN (e.g., KgNB), and keys for non-3GPP access (e.g., K... KN3IWF ).

[0041] In some example implementations, a KgNB is used to derive a new KgNB when horizontal or vertical key derivation is performed during handover, and to derive keys KUPenc, KUPint, KRRCenc, and KRRCint, which are used for confidentiality and integrity protection of user plane (UP) traffic and radio resource control (RRC) signaling, respectively. As described above, a KgNB can be derived from a KAMF.

[0042] In some example implementations, the key set identifier ngKSI is assigned by the AMF during the primary authentication and key negotiation process, or, for mapped 5G NAS security contexts, during inter-system changes. ngKSI may include a value and a security context parameter type to indicate whether the 5G NAS security context is a native 5G NAS security context or a mapped 5G NAS security context. For example, when the 5G NAS security context is a native 5G NAS security context, ngKSI has the value KSIAMF, and when the current 5G NAS security context is a mapped type, ngKSI has the value KSIASME.

[0043] As an example, when a UE registers with AMF 1 via radio access point 1 (hereinafter referred to as radio 1), the UE stores security context information associated with radio 1 and AMF 1. This security context may include information such as ngKSI1, 5G-GUTI1, and K... AMF The parameters of 1 and KgNB1. Simultaneously, for this UE, AMF1 stores ngKSI1, 5G-GUTI1, and K. AMF 1. The UDM stores the UE context for Radio 1 and AMF 1, as well as the correspondence between Radio 1 and AMF 1. That is, from the UDM's perspective, the UE is using Radio 1 and is served by AMF 1. Furthermore, the UDM can also store security context information for the pair (AMF 1, Radio 1). Note that the security context information can be stored at a per-UE per-radio level, ensuring that a security context exists for each radio access for each UE. In this case, Radio 1 utilizes a radio access technology, such as 3GPP or non-3GPP radio access technologies. The UE can add another radio access (such as another 3GPP radio access) via Radio Access Point 2 (hereinafter referred to as Radio 2) to access the wireless network. Therefore, the UE can have dual connectivity via two radios (Radio 1 and Radio 2). Radio 1 and Radio 2 may or may not be in the same core network and may or may not belong to the same access technology. The selection of Radio 1 and / or Radio 2 can be determined by factors such as user preferences, UE capabilities, service protocols, service profiles, etc. For example, a user preference might favor lower rates, in which case a radio connection with lower cost could be selected; a user preference might also favor higher data speeds / throughput, and a radio 2 could be added on top of radio 1 to achieve the goal; a user preference might also favor better signal quality, and a radio with better coverage could be selected; a user preference might also favor power efficiency, and a radio with lower power consumption could be selected. In some example implementations, multiple user preferences can be combined and considered together.

[0044] Radio 1 and Radio 2 may use the same or different access technologies. For example, Radio 1 and Radio 2 may be part of a terrestrial communication network (TN network), a non-terrestrial communication network (NTN network), or a non-public network (NPN network or private network). The access technology may be based on cellular access, wireless local area network (WLAN) access, or Wi-Fi access. Various combinations of Radio 1 and Radio 2 are supported in this disclosure. For example, both Radio 1 and Radio 2 may be based on 3GPP-based access networks, such as gNB, eNB, ng-eNB, and the like; or Radio 1 may use a 3GPP-based access technology, and Radio 2 may use a WLAN-based access technology. In some example embodiments, Radio 1 and Radio 2 may both belong to the same vendor or service provider. In some example embodiments, they may belong to different vendors. In some example embodiments, Radio 1 and Radio 2 may each belong to different Public Land Mobile Networks (PLMNs). In some example embodiments, Radio 1 and Radio 2 may each belong to different Radio Access Networks (RANs). In some example embodiments, Radio 1 may belong to a PLMN, and Radio 2 may belong to a private network.

[0045] Figure 6 A UE with exemplary dual radio access is illustrated. In the example, the UE establishes two radio connections 710 and 712 destined for a data network (DN) 720, and both radio connections are 3GPP accesses. Radio 712 is connected to PLMN2. On the other hand, radio 710 can be connected to a different PLMN (PLMN1), or a non-public network (NPN), such as a standalone NPN (SNPN). In some example implementations, radio 710 and radio 712 are served by the same core network (CN). In some example implementations, radio 710 and radio 712 are served by different core networks.

[0046] Dual-boot network access using two wireless devices

[0047] Besides the dual radio access scenario described above, where the same UE has two different radio accesses, there is another scenario where two radio devices (e.g., two physically separate radio devices) form a dual-booting relationship, allowing each of the radio devices to have radio access. Due to this dual-booting relationship, the two radio devices are bound together, and they can share the same set of subscription data. Each of the two radio devices can have its own SIM. Figure 7 An example of dual booting using two UEs is shown. UE1 uses 3GPP Access 730 to access the network, while UE2 uses 3GPP Access 732 to access the network.

[0048] Figure 8 This illustrates an example binding relationship (or dual-booting relationship) between two wireless devices. UE1 is assigned SUPI1 and served by AMF1. UE2 is assigned SUPI2 and served by AMF2. Figure 8 As shown, UE1 and UE2 use the same set of subscription data (or subscription profile). UE1 and UE2 are bound together via a dual-booting relationship. Due to their dual-booting relationship, UE1 and UE2 can be referred to as companion UEs.

[0049] This document describes an exemplary use case for dual-booting. In this scenario, UE1 can be a smartphone, and UE2 can be a smart TV. When both UE1 and UE2 register with a network (the same network or different networks), service bootstrapping can be implemented in both downlink and / or uplink directions. For example, when a video streaming application (APP) is running on UE1, downlink services for video can be bootstrapping to UE2, allowing the user to watch the video on the smart TV to take advantage of the larger screen size. As another example, when a push notification is present, it may be bootstrapping to UE1 for reasons such as privacy.

[0050] How to implement business guidance can be determined by the various factors listed below.

[0051] • Signal quality and coverage for each radio access (for UE1 and UE2), such as signal strength, service delay, and transmission power.

[0052] • Billing rates for each radio access.

[0053] • The type of application.

[0054] • The application's Quality of Service (QoS) requirements.

[0055] • User preferences. For example, do users prefer a larger screen or a smaller screen with a higher resolution?

[0056] These factors can be included and stored in user profiles, UE contexts, UE policies, or dual-boot policies. UE boot policies can be considered a type of UE policy.

[0057] Implementing dual-booting mode in wireless networks presents unique challenges. Dual-booting involves a coordinated effort among various network elements, including two wireless devices bound together by a dual-booting relationship (in which UE1 and UE2 are companion UEs to each other). To make decisions on how to bootstrap downlink and / or uplink traffic, a UE may need to know various parameters of its companion UE. For example, UE1 needs to know UE2's status, access type, identifiers (such as SUPI), and the AMF serving UE2, and vice versa. Furthermore, AMF1 serving UE1 and AMF2 serving UE2 may need to be able to discover and communicate with each other, for example, to exchange registration and authentication information.

[0058] In this disclosure, the UE context is extended to accommodate dual-booting features. Specifically, parameters associated with the accompanying UE used for dual-booting are added to the UE context. These parameters may include, for example:

[0059] • Identifiers accompanying the UE, such as the SUPI accompanying the UE.

[0060] • Accompanying UE state. The UE state can include connected state; idle state; powered off state; powered on state; or inactive state.

[0061] • UE's dual-boot capability.

[0062] • The access type accompanying the UE. This access type may include: 3GPP New Radio (NR) access type; Non-Terrestrial Network (NTN) access type; Non-Public Network (NPN) access type; Private access type; and similar access types.

[0063] • Identifier or address of the AMF that accompanies the UE.

[0064] The parameters mentioned above can be referred to as dual-boot context information, which can belong to the UE context. Therefore, certain parameters of a UE can be reflected in the UE context accompanying the UE.

[0065] In addition, a dual-booting strategy was introduced to coordinate dual-booting efforts. The dual-booting strategy applies to two wireless devices in a dual-booting relationship and can be used to define rules for bootstrapping downlink and / or uplink traffic.

[0066] In this disclosure, examples may be given using UE1 and UE2 for illustrative purposes. The basic principles and concepts apply to all other types of wireless devices, including but not limited to: tablets, laptops, smartwatches, smart TVs, and Internet of Things (IoT) devices.

[0067] Various embodiments are described in this disclosure in order to address the aforementioned technical problems in dual-boot deployment.

[0068] Example 1: Dual-booting using two wireless devices

[0069] In this embodiment, UE1 and UE2 have a dual-booting relationship, such as... Figure 8 As shown. For example, UE1 and UE2 can be assigned to the same set of subscription data, or share the same set of subscription data. UE1 and UE2 can have their respective Subscription Permanent Identifiers (SUPI), namely SUPI1 and SUPI2.

[0070] Figures 9A to 9B ( Figure 9B yes Figure 9A (Continued from the previous section) shows an example flowchart for enabling UE1 to register with the network after its accompanying UE (i.e., UE2) via a dual-boot relationship has completed its registration with the network. The exemplary method may include some or all of the following steps.

[0071] Step 1: UE1 sends a Registration Request (RR) message to the radio access point, such as a base station (e.g., ...). Figure 9A and Figure 9B (See gNB1). The RR message can carry UE1's 5G-GUTI1 (i.e., 5G-GUTI1 is assigned to UE1) and / or UE1's SUCI. Since UE1 has dual-booting capability, the RR message can also carry a dual-booting indication, which indicates at least one of the following: UE1 has dual-booting capability; UE1 has dual-booting capability; UE1 and UE2 (which is different from UE1) have a dual-booting relationship; UE1 and UE2 are assigned the same set of subscription data, or share the same set of subscription data; or the registration type is dual-booting registration. Through such an indication, the network side (e.g., gNB1, AMF1) can identify the need for dual-booting-specific setup / operation. This indication acts as a signal to notify the network of specific dual-booting scenarios.

[0072] Step 2: gNB1 forwards the registration request message to AMF1.

[0073] Step 3: If the RR message carries 5G-GUTI1, then AMF1 can locate the old AMF that served UE1 before UE1 made the current registration request (i.e., the old AMF is the AMF that most recently served UE1). AMF1 can then request UE1's UE context, for example, by sending a Namf_Communication_UEContextTransfer message to the old AMF. This message can carry UE1's 5G-GUTI1.

[0074] Step 4: The old AMF can send a response message such as the Namf_Communication_UEContextTransfer response message to AMF1. This response message can carry the context of UE1. Furthermore, since UE1 and UE2 have a dual-booting relationship, this response message can carry UE2's SUPI2 as an indication or identifier for accompanying the UE (via the dual-booting relationship). This response message can also carry the identifier and / or address of AMF2, which is the AMF serving UE2. Note that AMF2 is bound to SUPI2 (and / or UE2). This response message can also carry UE2's access type. Access types can include: 3GPP New Radio (NR) access type; Non-Terrestrial Network (NTN) access type; Non-Public Network (NPN) access type; Private access type; and similar access types. The response message can also carry the status of UE2, which can include: connected status; idle status; powered off status; powered on status; inactive status; within coverage area status; or outside coverage area status. Based on UE2's status, it can be determined whether UE2 is registered. For example, when UE2 is in a connected state, idle state, powered-on state, or inactive state, UE2 can be considered to have registered with the network.

[0075] Note that one or more of the aforementioned parameters carried in the response message (such as SUPI2, the identifier or address of AMF2, the access type of UE2, or the state of UE2) can be considered as part of the context of UE1, or more specifically, these parameters can be considered as dual-booting related context.

[0076] Step 5: There is a possibility that AMF1 may not be able to obtain the context for UE1 from the old AMF.

[0077] In some scenarios, the legacy AMF may not be able to provide context for UE1. For example, the legacy AMF may not be able to locate or retrieve the context of UE1 based on 5G-GUTI1, in which case the response message may carry a reason for failure.

[0078] In some scenarios, based on local policies, AMF1 may be unable or not permitted to obtain UE1's context from the legacy AMF. Local policies may include slice isolation or vertical industry security policies.

[0079] In another scenario, the link between AMF1 and the old AMF may be broken, thus preventing UE context passing.

[0080] AMF1 can send an Identity Request message to UE1 to request an identity, such as UE1's Subscription Hidden Identifier (SUCI).

[0081] Step 6: UE1 can respond to AMF1 using an Identity Response message, which can carry UE1's SUCI.

[0082] Step 7: If AMF1 receives UE1's SUCI in step 1 (RR message) or step 6, or if AMF1 determines to initiate primary authentication based on local policies (e.g., AMF1 may decide not to trust the UE context received in step 4), then AMF1 can select AUSF in its home network based on the Mobile Country Code (MCC), Mobile Network Code (MNC) and Routing Indicator in UE1's SUCI, and send a Nausf_UEAuthentication_Authenticate request message to AUSF, which carries the SUCI and the service network name.

[0083] Step 8: AUSF selects a UDM based on the SUCI, and AUSF sends a Nudm_UEAuthentication_Get request to the UDM. This message can carry the SUCI and the service network name.

[0084] Step 9: The UDM decrypts the SUCI using its private key to obtain the SUPI, and selects the authentication method 5G-AKA (5G Authentication and Key Negotiation) based on the SUPI (or EAP-AKA'—an improved scalable authentication protocol method for authentication and key negotiation, or another approach, described below using 5G-AKA as an example). The UDM then calculates CK' and IK', and replaces CK' and IK' with CK' and IK' (that is, the UDM updates the encryption key CK and the integrity key IK). The UDM then returns the 5G HE AV (5G Home Authentication Vector) along with an indication that the 5G HE AV will be used for 5G AKA in the Nudm_UEAuthentication_Get response to AUSF. If the SUCI is included in the Nudm_UEAuthentication_Get request, the UDM will include the SUPI in the Nudm_UEAuthentication_Get response after the SIDF dehides the SUCI.

[0085] Step 10: The AUSF temporarily stores XRES* along with the received SUCI or SUPI. Then, the AUSF should generate a 5G AV based on the 5G HE AV received from the UDM by calculating HXRES* from XRES* and KSEAF from KAUSF, replacing XRES* with HXRES* and KAUSF with KSEAF in the 5G HE AV. The AUSF can then remove KSEAF and return the 5G SE AV (RAND, AUTN, HXRES*) to AMF1 in the Nausf_UEAuthentication_Authenticate response.

[0086] Step 11: AMF1 can send RAND and AUTN to UE1 in the NAS message Authentication Request. This message may also include ngKSI1 (i.e., the ngKSI for AMF1), which will be used by the UE and AMF1 to identify KAMF1 and, in the event of successful authentication, a portion of the native security context created. This message may also include Anti-Bidding Down Between Architectures (ABBA) parameters.

[0087] Furthermore, if the registration type is dual-boot registration (e.g., registration will consider the peer UE used in dual-boot), and UE1 has already received an indication that UE2 has successfully registered, the UE ID parameter P0 used in KAMF1 (the key used for AMF1) calculation (e.g., as defined in A.7 of 3GPP TS33.501) can be extracted from SUPI1; or when UE2 registers in the network, it can be extracted from SUPI1 and SUPI2, for example, UE ID parameter P0 = IMSI1 || IMSI2 or P0 = IMSI2 || IMSI1, where || is a concatenation operation. Note that when the SUPI type is IMSI, IMSI1 and IMSI2 are set to SUPI1 and SUPI2, respectively. Note that UE1 may have previously received UE2's status before the current registration request, so UE1 can determine whether UE2 has registered.

[0088] Step 12: The ME (of UE1) can forward the RAND and AUTN received in the NAS message authentication request to the USIM (of UE1). Upon receiving the RAND and AUTN, the USIM should verify the freshness of the received values ​​by checking whether the AUTN is acceptable. If the AUTN is acceptable, the USIM calculates the response RES. The USIM should return RES, CK, and IK to the ME. If the USIM uses the conversion function c3 to calculate Kc (i.e., GPRS Kc) from CK and IK and sends it to the ME, the ME should ignore such GPRS Kc and not store the GPRS Kc on the USIM or in the ME. Then, the ME should calculate RES* from RES. Then, the ME should calculate KAUSF from CK||IK. The ME should calculate KSEAF from KAUSF. The ME accessing 5G should check during authentication whether the "separation bit" in the AMF field of the AUTN is set to 1. The "separation bit" is the 0th bit of the AMF field of the AUTN. Then, UE1 can return RES* to AMF1 in the NAS message authentication response.

[0089] Step 13: AMF1 can then calculate HRES* from RES*, and AMF1 can compare HRES* and HXRES*. If they match, AMF1 considers authentication successful from the perspective of the serving network. AMF1 can send RES*, as received from UE1, to AMF1 in the Nausf_UEAuthentication_Authenticate request message.

[0090] Step 14: When the AUSF receives a Nausf_UEAuthentication_Authenticate request message including RES* as authentication confirmation, it can verify whether the 5G AV has expired. If the 5G AV has expired, from the home network's perspective, the AUSF can consider authentication unsuccessful. Upon successful authentication, the AUSF stores the KAUSF based on the home network operator's policy. The AUSF should compare the received RES* with the stored XRES*. If RES* and XRES* are equal, from the home network's perspective, the AUSF can consider authentication successful. The AUSF should notify the UDM of the authentication result. From the home network's perspective, the AUSF should indicate to AMF1 whether authentication was successful in the Nausf_UEAuthentication_Authenticate response. If authentication is successful, KSEAF can be sent to SEAF in the Nausf_UEAuthentication_Authenticate response. If authentication is successful, the AUSF can also include SUPI1 in the Nausf_UEAuthentication_Authenticate response message.

[0091] Step 15: AMF1 uses KSEAF to calculate KAMF1; uses KAMF1 to calculate the integrity protection key and encryption key; calculates KgNB1; and sends a NAS Security Mode Command message to the UE. This message carries ngKSI, UE security capability information, and the NAS MAC checksum calculated using the NAS integrity protection key.

[0092] Step 16: The UE calculates KAMF1 using KSEAF; simultaneously, it calculates the corresponding integrity protection key and encryption key based on KAMF1; calculates KgNB1; and verifies the NAS MAC using the integrity key. If the integrity verification is successful, a NAS Security Mode Complete message is returned to AMF1, which carries the verification value NAS MAC used for integrity protection using the integrity key.

[0093] In some example implementations, if the registration type is dual-boot registration (e.g., the registration will consider the accompanying UE2 used in dual-boot), and UE1 receives an indication that UE2 has successfully registered, the UE ID parameter P0 used in the KAMF1 (key for AMF1) calculation can be extracted from SUPI1; or when UE2 registers in the network, it can be extracted from SUPI1 and SUPI2, for example, UE ID parameter P0 = IMSI1 || IMSI2 or P0 = IMSI2 || IMSI1, where || is a concatenation operation. Note that when the SUPI type is IMSI, IMSI1 and IMSI2 are set to SUPI1 and SUPI2, respectively.

[0094] Both steps 17a and 17b can be optional.

[0095] Step 17a: Step 17a includes two sub-steps, 17a1 and 17a2.

[0096] In step 17a1, after successfully verifying the integrity of the NAS security mode completion message, AMF1 can initiate a registration process with UDM. This registration request message may include a Nudm_UECM_Registration message.

[0097] In step 17a2, the UDM then sends a response message. This response may carry dual-booting related context information for UE1. For example, the response message may carry UE2's SUPI2 as an indication or identifier for the accompanying UE (via the dual-booting relationship). The response message may also carry the identifier and / or address of AMF2, which is the AMF serving UE2 if UE2 has registered with AMF2. Note that this response indicates binding information showing the binding of UE1 and UE2 via the dual-booting feature. Through this binding information, UE2's SUPI (i.e., SUPI2) and the AMF serving UE2 (i.e., AMF2) are passed to the receiving entity.

[0098] Step 17b: Step 17b includes two sub-steps, 17b1 and 17b2.

[0099] In step 17b1, after AMF1 has successfully completed the Nudm_UECM_Registration operation, and if AMF1 does not have subscription data for the UE, AMF1 can use Nudm_SDM_Get to retrieve access and mobility subscription data, SMF selection subscription data, UE context in SMF data, and LCS initiation call.

[0100] In step 17b2, the UDM then sends a response message. If the dual booting context information for UE1 is not passed to AMF1 in step 17a, the response in step 17b2 may carry the dual booting context information for UE1 (details about the dual booting context information are described in step 17a above).

[0101] If AMF1 already has subscription data for the UE, but the roaming guidance (SoR) update indicator in the UE context requires AMF1 to retrieve SoR information based on the NAS registration type ("Initial Registration" or "Emergency Registration"), then AMF1 uses, for example, Nudm_SDM_Get to retrieve the roaming guidance information. Note that UDM can retrieve SoR information from UDR via Nudr_DM_Query.

[0102] Step 17c: After receiving a successful response, AMF1 can subscribe to the UDM to be notified when the requested data is modified using Nudm_SDM_Subscribe. The UDM can subscribe to the UDR using Nudr_DM_Subscribe. If the Common Public Subscription Identifier (GPSI) is available in the UE subscription data, the GPSI is provided to AMF1 in the access and mobility subscription data from the UDM.

[0103] Using a subscription service, if the AMF2 address stored in the UDM changes due to, for example, UE mobility (e.g., UE2 moves to a different AMF), the UDM can send a notification to AMF1 with the updated AMF2 address. Similarly, AMF2 can also subscribe to the UDM to be notified, for example, when the AMF1 address is updated, so that AMF2 can update its records about AMF1.

[0104] Step 17d: When the UDM stores the associated access type (e.g., 3GPP access) along with UE1's current serving AMF (i.e., AMF1), it will initiate a deregistration process with the old AMF corresponding to the same access type (3GPP access), causing the old AMF to deregister UE1's radio access with the same access type. This deregistration process can be implemented, for example, via a Nudm_UECM_DeregistrationNotification message to the old AMF.

[0105] Step 17e: This step is optional. If the old AMF does not have a UE context (associated with UE1) for another access type (i.e., non-3GPP access), the old AMF uses Nudm_SDM_unsubscribe to unsubscribe from the UDM for the subscription data.

[0106] Step 18: In this step, AMF1 can begin synchronizing dual-booting context information with AMF2 (which is the AMF serving UE2). Specifically, AMF1 has already obtained AMF2 information in step 4, step 17a, or step 17b. AMF1 can send a message to AMF2, such as a Namf_Communication_UEBindingUpdate request message. This message can carry dual-booting related context information about UE1, such as SUPI1; the identifier and / or address of AMF1, which is the AMF serving UE1; the state of UE1; and the access type of UE1. As described above, the access type can include: 3GPP NR access type; NTN access type; NPN access type; private access type; and similar access types. The context information can also carry SUPI2 (allowing AMF2 to identify the specific accompanying UE to which the message is addressed).

[0107] Step 19: AMF2 sends a UE Policy Update Request message to the PCF associated with AMF2. This message may carry SUPI2 and the bound SUPI1 (i.e., SUPI1 is bound to SUPI2 due to the dual-booting relationship), and the message may also carry a dual-booting indication indicating that at least one of the following is true: UE2 and / or UE1 have dual-booting capability; UE1 and / or UE2 have dual-booting capability; UE2 and UE1 have a dual-booting relationship (UE1 is different from UE2); UE1 and UE2 are assigned the same set of subscription data, or share the same set of subscription data.

[0108] The PCF updates the dual-boot policy and sends a UE policy update response message with a UE policy container to AMF2. This UE policy container includes the updated dual-boot policy for UE1 and UE2. Note that the dual-boot policy can be a type of UE policy other than other types of UE policies.

[0109] Step 20: If UE2 is in an idle state, AMF2 can send a paging message to UE2. If UE2 is in a connected state, AMF2 can send a downlink (DL) non-access stratum (NAS) message to UE2, which may carry at least one of the following: SUPI1 (because UE1 is bound to UE2 due to dual bootstrapping); the dual bootstrapping policy for UE1 and UE2 (this policy can be encapsulated in a UE policy container); the state of UE1; and the access type of UE1 (e.g., 3GPP 5G NR, NTN, or NPN). Through this step, dual bootstrapping context information related to UE1 is passed to UE2.

[0110] Step 21: UE2 stores the parameters received in the DL NAS message. Based on the dual-booting strategy, UE2 can perform operations or adjustments, such as rerouting and / or switching downlink and / or uplink data streams. These operations can take effect in subsequent processes. UE2 can respond to AMF2 using, for example, UL NAS messages.

[0111] Note: If dual booting operates at the application layer or is triggered by the application layer (such as an app running on a wireless device), steps 20 and 21 can be skipped.

[0112] Step 22: AMF2 can respond to AMF1 using, for example, a Namf_Communication_UEBindingUpdate response message, which may carry at least one of the following: a dual-booting policy for UE1 and UE2 (this policy may be encapsulated in a UE policy container), the state of UE2, the access type of UE2 (e.g., 3GPP 5G NR, NTN, or NPN), and the PCF address. UE1 (and / or UE2) can establish / create / update dual-booting sessions (such as Packet Data Unit (PDU) sessions) based on the rules and service descriptors outlined in the dual-booting policy. The dual-booting policy may specify a set of guidelines or instructions that define when and how these sessions should be initiated or modified to optimize network performance and / or meet specific dual-booting requirements.

[0113] Step 23: If the PCF's address (or identifier) ​​is not carried in the Namf_Communication_UEBindingUpdate response message in step 22, AMF1 may select the PCF instance based on at least one of the following: the dual-booting capability of UE1 and / or UE2; the range to which SUPI1 belongs; the range to which SUPI2 belongs; or the result of a discovery process with the NRF. This discovery process may use at least one of the following as input: the dual-booting capability of UE1 and / or UE2, SUPI1, or SUPI2.

[0114] If the address (or identifier) ​​of the PCF is provided in step 22, step 23 can be skipped.

[0115] Step 24: In this step, UE policies and Access and Mobility (AM) policies are managed for dual boots. AMF1 can invoke the AM / UE policy association creation procedure or the AM / UE policy association update procedure to create or update UE / AM policies using PCF.

[0116] Note: If UE2 is not registered, steps 23 and 24 are required. Otherwise, steps 23 and / or 24 can be skipped.

[0117] Step 25: AMF1 can allocate 5G-GUTI2 (a new GUTI to replace 5G-GUTI1) to UE1 and return a Registration Accept message to UE1. This message can carry the newly allocated 5G-GUTI2. The message can also carry dual-booting related context information about UE2, such as SUPI2 (which is the SUPI accompanying the UE); UE2 status; or UE2 access type. As described above, the access type can include: 3GPP NR access type; NTN access type; NPN access type; private access type; and similar access types.

[0118] The message can also carry dual-boot policies for UE1 (and UE2) by using, for example, a UE policy container.

[0119] Note: If the application layer operation / triggers dual bootstrapping (or the dual bootstrapping is initiated from the application layer), the registration accept message may only need to carry the 5G-GUTI2 assigned to UE1.

[0120] Step 26: After receiving the registration acceptance message, UE1 can store the received parameters, such as dual-booting related context information (e.g., SUPI2, UE2 status, UE2 access type). UE1 can also store the newly allocated 5G-GUTI2 to replace 5G-GUTI1.

[0121] Then, UE1 can return a Registration Complete message to AMF1.

[0122] From this point onward, UE1 and UE2 can perform dual-booting operations (such as bootstrapping or handover) on the uplink / downlink data streams in subsequent processes based on the dual-booting strategy used for UE1 and UE2 and the dual-booting related context information. For example, UE1 can bootstrap downlink services used for video streaming to UE2; or UE2 can bootstrap uplink services to UE1.

[0123] In this disclosure, there are two wireless devices (e.g., UE1 and UE2) with a dual-booting relationship. In some example implementations, UE2 has already registered with a network (which may be the same or different from the network that UE1 will register with). When UE1 initiates a registration request, dual-booting related context information (such as SUPI1, UE1 state, UE1 access type, UE1 dual-booting capability) associated with UE1 can be forwarded to UE2. At the end of registration, UE1 will also receive dual-booting related context information (such as SUPI2, UE2 state, UE2 access type, UE2 dual-booting capability, etc.) associated with UE2. Furthermore, during the registration process, a dual-booting policy (which may be part of a UE policy) can be distributed to both UE1 and UE2. The dual-booting policy defines the rules for enabling the UE to bootstrap downlink and / or uplink services. For example, based on the dual-booting policy, UE1 can bootstrap certain downlink services (e.g., associated with QoS flows, Packet Data Unit (PDU) sessions, etc.) to UE2, and UE2 can bootstrap certain uplink services to UE1.

[0124] During the registration process, AMF1 serving UE1 can retrieve information about AMF2 serving UE2 (e.g., the identifier or address of AMF2). Various methods are provided to allow the use of various sources. For example, AMF1 can obtain AMF2 from an older AMF that served UE1 before UE1 moved to AMF1. AMF1 can also obtain AMF2 information from the UDM. Furthermore, AMF1 can subscribe to the UDM to be notified when AMF2 is updated.

[0125] In this disclosure, AMFs (AMF1 and AMF2) can act as bridges to exchange UE information. For example, AMF1 can pass UE1 information to AMF2, and AMF2 can relay UE1 information to UE2. Simultaneously, upon receiving UE1 information, AMF2 can request the PCF to update the dual-boot policy and distribute the updated dual-boot policy to UE2 and UE1 (via AMF1).

[0126] It should be noted that some steps described in one embodiment of this disclosure may be optional, while some steps provide alternative parallel solutions relative to others. For example, AMF1 may obtain dual-booting related context information (e.g., SUPI2, UE2 state, UE2 access type, AMF2 address / identifier) ​​from various steps, such as step 4, step 17a, step 17b, or step 22. In this case, for example, steps 4, 17a, 17b, and 22 may provide parallel solutions, and one or more of these steps may be included in the method according to the embodiment. When parallel solutions exist, not all solutions need to be included in one implementation.

[0127] An exemplary method according to embodiments of this disclosure may include some or all of the following steps: Step 1: Receiving a first message from a first wireless device for a registration request to a first wireless network, wherein: the first wireless device and a second wireless device have a dual-booting relationship, and the first wireless device and the second wireless device share the same set of subscription data; the first wireless device and the second wireless device are identified by a first SUPI and a second SUPI, respectively; the first message carries at least one of the following: a first 5G-GUTI of the first wireless device; a subscription hidden identifier (SUCI) of the first wireless device; a first indication indicating that the first wireless device has dual-booting capability; or a second indication indicating that the first wireless device and the second device have a dual-booting relationship; Step 2: Obtaining at least one subset of first context information for the first wireless device, the first context information including at least one of the following: a second SUPI; an identifier or address of a second core network element serving the second wireless device; the access type of the second wireless device; or the status of the second wireless device.

[0128] In any part or combination of the above embodiments, each of the first core network element and the second core network element includes an AMF.

[0129] In any part or combination of the above embodiments, the access type of the wireless device includes at least one of the following: 3GPP NR access type; non-terrestrial network (NTN) access type; or non-public network (NPN) access type.

[0130] In any part or combination of the above embodiments, the state of the wireless device includes at least one of the following: connected state; idle state; inactive state; powered off state; powered on state; within coverage area state; or outside coverage area state.

[0131] In any part or combination of the above embodiments, the method may further include: determining, based on the first 5G-GUTI of the first wireless device, an old core network element that served the first wireless device before the first wireless device switched to the first core network element; and obtaining at least one subset of the first context information includes: receiving at least one subset of the first context information from the old core network element.

[0132] Note that the term "at least one subset of the first context information" can refer to a subset of the first context information (i.e., a part of the first context information) or the complete first context information (the entire set of the first context information).

[0133] Note that in this disclosure, context information may be received as a whole in one step, or it may be received in multiple steps (i.e., some parameters may be received in one step, while other parameters may be received in other steps). Not all steps are mandatory, provided that the complete dual-boot context information has been received (e.g., by the AMF and / or the UE).

[0134] In this disclosure, message type and / or message name (e.g., such as Figures 9A to 9B (As shown) are for illustrative purposes only. Different message types and / or message names may be selected in implementations, and should still be covered by this disclosure as long as the basic principle is the same (e.g., if the message is for the same purpose).

[0135] In this disclosure, a single message can be split into multiple sub-messages. Multiple messages can also be combined and sent in a single message.

[0136] In this disclosure, a single information element in a message can be broken down into multiple information elements. Multiple information elements can also be combined into a single information element.

[0137] In this disclosure, the steps in each embodiment are for illustrative purposes only, and other alternatives may be derived from the disclosed embodiments as needed. For example, only a portion of the steps may need to be performed. For another example, the order of the steps may be adjusted. For another example, multiple steps may be combined (e.g., multiple messages may be combined into one message). For another example, a single step may be split (e.g., a message may be transmitted via two sub-messages). For another example, the embodiments described in this disclosure may be split into sub-embodiments based on practical needs; therefore, not all steps in one embodiment are necessary.

[0138] The above description and accompanying drawings provide specific example embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and therefore the subject matter covered or claimed is intended to be construed as not being limited to any of the example embodiments set forth herein. A reasonably broad scope is intended for the claimed or covered subject matter. Among other things, the subject matter can be embodied as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Therefore, embodiments can take the form, for example, hardware, software, firmware, storage medium, or any combination thereof. For example, the method embodiments described above can be implemented by a component, apparatus, or system including memory and a processor by executing computer code stored in memory.

[0139] Throughout this specification and claims, terms may have subtle meanings implied or suggested in the context, rather than just explicitly stated meanings. Similarly, the phrase "in one embodiment / implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" as used herein does not necessarily refer to a different embodiment. For example, it is intended that the claimed subject matter encompass all or part of a combination of exemplary embodiments.

[0140] Generally, terms can be understood at least in part from their usage in context. For example, terms such as “and,” “or,” or “and / or,” as used herein, can come in a variety of meanings that can depend at least in part on the context in which such terms are used. Typically, if “or” is used with an associative list, such as A, B, or C, it is intended to mean A, B, and C, used here in an inclusive sense; and A, B, or C, used here in an exclusive sense. Furthermore, depending at least in part on the context, the term “one or more,” as used herein, can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, depending at least in part on the context, terms such as “a,” “one,” or “the” can be understood to convey either a singular or a plural usage. Moreover, the term “based on” can be understood to not necessarily convey an exclusive set of factors, and can again, depending at least in part on the context, allow for additional factors that are not necessarily explicitly described.

[0141] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable using this solution should be or are included in any single implementation thereof. Rather, references to features and advantages are to be understood as meaning that a particular feature, advantage, or characteristic described in conjunction with an embodiment is included in at least one embodiment of this solution. Therefore, throughout this specification, discussions of features and advantages, as well as similar language, may, but are not necessarily, of the same embodiments.

[0142] Furthermore, the features, advantages, and characteristics described in this solution can be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, based on the description herein, that this solution can be practiced without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of this solution may be recognized in certain embodiments.

Claims

1. A method for wireless communication executed by a first core network element, the method comprising: Receive a first message from the first wireless device for requesting registration with the first wireless network, wherein: The first wireless device and the second wireless device have a dual-booting relationship, and the first wireless device and the second wireless device share the same set of subscription data; The first wireless device and the second wireless device are identified by a first subscription persistent identifier (SUPI) and a second SUPI, respectively; The first message carries at least one of the following: The first 5G globally unique temporary identifier (5G-GUTI) of the first wireless device. The subscription hidden identifier (SUCI) of the first wireless device; The dual-boot capability of the first wireless device; A first indication that the first wireless device has dual-booting capability; or A second indication indicating a dual-booting relationship between the first wireless device and the second wireless device; and Obtain at least one subset of first context information for the first wireless device, the first context information including at least one of the following: The second SUPI; The identifier or address of the second core network element serving the second wireless device; The access type of the second wireless device; or The status of the second wireless device.

2. The method according to claim 1, wherein, Each of the first core network element and the second core network element includes access and mobility management functions (AMF).

3. The method according to claim 1, wherein, The access type of the second wireless device includes at least one of the following: 3rd Generation Partnership Project (3GPP) New Radio (NR) access type; Non-terrestrial network (NTN) access type; or Non-public network (NPN) access type.

4. The method according to claim 1, wherein, The state of the second wireless device includes at least one of the following: connected state; idle state; inactive state; powered off state; powered on state; within coverage area state; or outside coverage area state.

5. The method according to any one of claims 1 to 4, wherein: The method further includes: determining, based on the first 5G-GUTI of the first wireless device, the old core network element that previously served the first wireless device before the first wireless device switched to the first core network element; and Obtaining at least one subset of the first context information includes: receiving at least one subset of the first context information from the old core network element.

6. The method according to claim 5, wherein, The at least one subset of receiving the first context information includes: Transmit a second message to the old core network element for requesting at least one subset of the first context information; and Receive a third message from the old core network element carrying at least one subset of the first context information.

7. The method according to claim 6, wherein, The second message includes a Namf_Communication_UEContextTransfer message, and the third message includes a Namf_Communication_UEContextTransfer response message.

8. The method according to claim 5, further comprising: An authentication request with the first wireless device is initiated based at least in part on the AMF key (Kamf1) of the first core network element, wherein the Kamf1 is derived based on at least one of the following: the first SUPI, or the second SUPI.

9. The method according to claim 8, wherein, When the second wireless device registers with the second wireless network, Kamf1 is derived based on the cascading of the first SUPI and the second SUPI, wherein the second wireless network is the same as the first wireless network, or the second wireless network is different from the first wireless network.

10. The method of claim 5, further comprising: The security mode command process with the first wireless device is initiated at least in part based on the AMF key (Kamf1) of the first core network element, wherein when the second wireless device registers with the second wireless network, the Kamf1 is derived based on the concatenation of the first SUPI and the second SUPI, and wherein the second wireless network is the same as the first wireless network, or the second wireless network is different from the first wireless network.

11. The method according to any one of claims 1 to 4, wherein, Obtaining at least one subset of the first context information includes: Sending a fourth message to Unified Data Management (UDM); and A fifth message is received from the UDM as a response to the fourth message, the fifth message carrying at least one subset of the first context information.

12. The method according to claim 11, wherein: The fourth message includes a Nudm_UECM_Registration message, and the fifth message includes a response to the Nudm_UECM_Registration message; or The fourth message includes a Nudm_SDM_Get message, and the fifth message includes a response to the Nudm_SDM_Get message.

13. The method according to claim 11, wherein, When the second wireless device registers with the second wireless network, the at least one subset of the first context information includes the identifier or address of the second core network element serving the second wireless device, wherein the second wireless network is the same as the first wireless network, or the second wireless network is different from the first wireless network.

14. The method according to any one of claims 1 to 4, further comprising: A sixth message is transmitted to the second core network element, the sixth message including second context information for the second wireless device, the second context information including at least one of the following: The first SUPI; The second SUPI; The identifier or address of the first core network element; The access type of the first wireless device; or The status of the first wireless device.

15. The method of claim 14, further comprising: The second core network element is determined based on its identifier or address.

16. The method of claim 14, wherein, Obtaining at least one subset of the first context information for the first wireless device includes receiving a seventh message from the second core network element as a response to the sixth message, the seventh message including the at least one subset of the first context information.

17. The method according to claim 16, wherein, The seventh message also includes at least one of the following: The identifier or address of the Policy Control Function (PCF) that provides policy rules to the first wireless device; or A UE strategy applicable to the dual-booting feature of the first wireless device.

18. The method according to claim 17, wherein, The UE policy is shared by the first wireless device and the second wireless device.

19. The method of claim 17, further comprising: An eighth message is transmitted to the first wireless device as a response to the first message to accept the registration request, the eighth message carrying at least one of the following: The at least one subset of the first context information; The second 5G-GUTI assigned to the first wireless device; or The UE strategy.

20. The method of claim 17, further comprising: The PCF is determined using one of the following methods: The PCF is determined based on the identifier or address of the PCF carried in the seventh message; or The PCF is determined based on at least one of the following: the dual-booting capability of UE1; the dual-booting capability of UE2; the scope to which SUPI1 belongs; the scope to which SUPI2 belongs; or the query results based on the discovery process performed with the Network Storehouse Function (NRF); as well as Invoke the UE and Access and Mobility Management (AM) policy association creation process or the UE / AM policy update process to create or update the UE policy applicable to the dual-booting features of the first radio device.

21. The method according to any one of claims 1 to 4, further comprising: A ninth message carrying at least one subset of the first context information is transmitted to the first wireless device.

22. A method for wireless communication performed by a first core network element serving a first wireless device, the method comprising: A first message is received from a second core network element serving the second wireless device, the first message including at least one of the following: a first subscription permanent identifier (SUPI) of the first wireless device; or context information for the first wireless device, wherein: The first wireless device and the second wireless device have a dual-booting relationship; The first wireless device and the second wireless device are identified by the first SUPI and the second SUPI, respectively; The context information includes at least one of the following: The second SUPI; The identifier or address of the second core network element; The access type of the first wireless device; The first wireless device has dual-boot capability; or The status of the first wireless device.

23. The method according to claim 22, wherein, The first wireless device and the second wireless device share the same set of subscription data.

24. The method according to claim 22, wherein, Each of the first core network element and the second core network element includes access and mobility management functions (AMF).

25. The method according to claim 22, wherein, The access type of the second wireless device includes at least one of the following: 3rd Generation Partnership Project (3GPP) New Radio (NR) access type; Non-terrestrial network (NTN) access type; or Non-public network (NPN) access type.

26. The method according to claim 22, wherein, The state of the second wireless device includes at least one of the following: connected state; idle state; inactive state; powered off state; powered on state; or outside the coverage area state.

27. The method according to any one of claims 22 to 26, further comprising: A second message is sent to the Policy Control Function (PCF) to request an update to the dual-boot policy applicable to at least one of the first wireless device or the second wireless device, the second message including at least one of the following: This indicates that the first wireless device has dual-boot capability; This indicates that the second wireless device has dual-boot capability; The first wireless device and the second wireless device have a dual-booting relationship; or The first wireless device and the second wireless device share the same set of subscription data; as well as Receive a response to the second message from the PCF, the response including an updated dual-boot policy updated by the PCF based on the second message.

28. The method according to claim 27, wherein, The second message includes a UE policy update request message.

29. The method of claim 27, further comprising: In response to the first wireless device being in an idle state, a paging message is transmitted to the first wireless device.

30. The method of claim 27, further comprising: In response to the first wireless device being in a connected state, a third message is transmitted to the first wireless device, the third message including at least one of the following: The updated dual-boot strategy; The second SUPI; The status of the second wireless device; or The access type of the second wireless device.

31. The method according to claim 30, wherein, The third message includes downlink (DL) non-access stratum (NAS) messages.

32. The method of claim 31, further comprising: Receive a response to the third message, the response including an uplink (UL) NAS message.

33. The method of claim 27, further comprising: A fourth message, in response to the first message, is transmitted to the second core network element, the fourth message including at least one of the following: The updated dual-boot strategy; The status of the first wireless device; The access type of the first wireless device; The dual-boot capability of the first wireless device; The identifier of the PCF; or The address of the PCF.

34. A method for wireless communication performed by a first wireless device, the method comprising: A first message for requesting registration with the first wireless network is transmitted to the first core network element, wherein: The first wireless device and the second wireless device served by the second core network element have a dual-booting relationship, and the first wireless device and the second wireless device share the same set of subscription data; The first wireless device and the second wireless device are identified by a first subscription persistent identifier (SUPI) and a second SUPI, respectively; The first message carries at least one of the following: The first 5G globally unique temporary identifier (5G-GUTI) of the first wireless device. The subscription hidden identifier (SUCI) of the first wireless device; A first indication that the first wireless device has dual-booting capability; or A second indication that the first wireless device and the second wireless device have a dual-booting relationship.

35. The method according to claim 34, wherein, Each of the first core network element and the second core network element includes access and mobility management functions (AMF).

36. The method according to any one of claims 34 to 35, further comprising: The authentication process with the first core network element is performed at least in part based on the AMF key (Kamf1) of the first core network element, wherein the Kamf1 is derived based on at least one of the first SUPI or the second SUPI.

37. The method according to claim 36, wherein, When the second wireless device registers with the second wireless network, Kamf1 is derived based on the cascading of the first SUPI and the second SUPI, wherein the second wireless network is the same as the first wireless network, or the second wireless network is different from the first wireless network.

38. The method according to any one of claims 34 to 35, further comprising: The first core network element receives a second message as a response to the first message to accept the registration request, the second message carrying at least one of the following: Context information for the first wireless device, the context information including at least one of the following: The second SUPI; The identifier or address of the second core network element; The access type of the second wireless device; or The status of the second wireless device; A second 5G-GUTI is assigned to the first wireless device to replace the first 5G-GUTI; or A UE strategy applicable to the dual-booting feature of the first wireless device.

39. The method according to claim 38, wherein, The access type of the second wireless device includes at least one of the following: 3rd Generation Partnership Project (3GPP) New Radio (NR) access type; Non-terrestrial network (NTN) access type; or Non-public network (NPN) access type.

40. The method of claim 38, wherein, The state of the second wireless device includes at least one of the following: connected state; idle state; inactive state; powered off state; powered on state; within coverage area state; or outside coverage area state.

41. The method of claim 38, further comprising: The downlink reception or uplink transmission is performed based on the UE policy.

42. A method for wireless communication, performed by a first wireless device, the method comprising: Receive the first message from the first core network element, including: The first wireless device and the second wireless device served by the second core network element have a dual-booting relationship; The first wireless device and the second wireless device are identified by a first Subscription Permanent Identifier (SUPI) and a second SUPI, respectively; and The first message carries at least one of the following: The 5G globally unique temporary identifier (5G-GUTI) of the second wireless device. The access type of the second wireless device; The status of the second wireless device; or A dual-boot strategy applicable to both the first wireless device and the second wireless device.

43. The method according to claim 42, wherein, The first wireless device and the second wireless device share the same set of subscription data.

44. The method according to claim 42, wherein, Each of the first core network element and the second core network element includes access and mobility management functions (AMF).

45. The method according to claim 42, wherein, The access type of the second wireless device includes at least one of the following: 3rd Generation Partnership Project (3GPP) New Radio (NR) access type; Non-terrestrial network (NTN) access type; or Non-public network (NPN) access type.

46. ​​The method according to claim 42, wherein, The state of the second wireless device includes at least one of the following: connected state; idle state; inactive state; powered off state; powered on state; or outside the coverage area state.

47. The method according to any one of claims 42 to 46, wherein, The first message includes downlink (DL) non-access stratum (NAS) messages.

48. The method according to any one of claims 42 to 46, further comprising: A response message to the first message is transmitted to the first core network element, wherein the response message includes an uplink (UL) NAS message.

49. The method according to any one of claims 42 to 46, further comprising: The downlink reception or uplink transmission is performed based on the dual-booting strategy.

50. An apparatus comprising a memory for storing computer instructions and a processor in communication with said memory, wherein, When executing the computer instructions, the processor is configured to implement the method according to any one of claims 1 to 49.

51. A computer program product comprising a non-transitory computer-readable program medium having computer code stored thereon, the computer code, when executed by one or more processors, causing the one or more processors to perform the method according to any one of claims 1 to 49.

Images