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 requesting registration with a first wireless network, wherein: the first wireless device has a dual boot relationship with a second wireless device, and the first wireless device and the second wireless device share a same set of subscription data; 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; and at least one subset of context information of the first wireless device.

Description

Technical Field

[0001] This disclosure relates to wireless communications, including 5G and 6G technologies, and particularly to a first wireless device securely registering and communicating with one or more wireless communication networks in consideration of a second wireless device, wherein the first and second wireless devices have a dual streer 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 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 related to wireless communication. Embodiments describe a first wireless device that securely registers and communicates with one or more wireless communication networks, taking into account a second wireless device, wherein the first and second wireless networks 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 requesting registration with a first wireless network, wherein: the first wireless device and a second wireless device served by a second core network element 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 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; and obtaining at least one subset of context information of the first wireless device, the context information including at least one of: a second SUPI; dual-booting capability of the second wireless device; 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 network element, includes: receiving a first message from a unified data management (UDM) associated with 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 a first SUPI and a second SUPI, respectively; the context information includes at least one of: a second SUPI; an access type of the second wireless device; or a state of the second wireless device.

[0006] In one embodiment, this disclosure describes a method for wireless communication. The method, performed by a first wireless device, includes: transmitting a first message to a first core network element for requesting registration with 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; 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.

[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 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: a 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-booting strategy applicable to the first wireless device and the second wireless device.

[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 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 on which computer code is stored. When executed by a processor, the computer code may cause the processor to perform any of the methods described above.

[0010] Other aspects and alternatives of the above embodiments and their implementations 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 for one or more wireless networks is shown.

[0017] Figure 7 An exemplary dual-boot setup 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 for a dual-booting UE to register with the network, taking into account its accompanying dual-booting UE, is shown. 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. For example, carrier network 102 may include access network 120 and core network 130. Carrier network 102 may be configured to transmit voice, data, and other information (collectively referred to as 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 radio access or wired access via radio resources. 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, which can be accessed by terminal devices 110 and 112 through the core network 130 of operator network 102. Service application 140 can be deployed as a data network outside the core network 130. Similarly, other data networks 150 can be accessed by terminal devices 110 and 112 through the core network 130 and can appear as data destinations or data sources 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 provisioning and routing functions for the core network 130. The terms "network node" and "network function" are used interchangeably in this disclosure.

[0022] Figure 2 An exemplary partitioning of network functions in the core network 130 of the communication network 200 is further illustrated. Although in 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 Various solid lines indicate this. Such signaling and data exchange can be carried through signaling or data messages that follow a predetermined format or protocol.

[0023] Above Figure 1 and 2 The implementation methods described herein can be applied to 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 (used as...) Figure 2 Terminal equipment 110), Radio Access Network (RAN) 320 (used as terminal equipment 110), Radio Access Network (RAN) 320 Figure 2 The network consists of an access network 120, a data network (DN) 150, and a core network 130. The core network 130 includes an access management function (AMF) 330 (used as...). Figure 2 AMNN 230), Session Management Function (SMF) 340 (used as AMNN 230), Session Management Function (SMF) 340 Figure 2 SMNN 240), Application Function (AF) 390 (used as Figure 2 ADMNN 210), User Plane Function (UPF) 350 (used as Figure 2 DRNN 250), policy control function 322 (used as Figure 2 PCNN 220), Authentication Server Function (AUSF) 360 (used as Figure 2 AUNN 260) and Universal Data Management (UDM) function 370 (used as Figure 2 (UDMNN 270 in the text). Again, although in Figure 3 Only a single instance of some network functions or nodes of 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 is... 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 similar devices. 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 carried over the air (OTA) radio interface, such as... Figure 3 As indicated by 311 in the document.

[0025] continue 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 repository and processing functions (ARPF, such as...). Figure 3 As shown in section 370, it is used to store long-term security credentials for user authentication and to perform calculations of encryption keys using such long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, 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 the various communication interfaces indicated by solid lines connecting these network nodes or functions. The AMF / SEAF 330 can handle UE-to-Non-Access Stratum (NAS) signaling management and provide registration and access for UE 310 to the core network 130, as well as allocation to the SMF 340, thereby supporting the communication needs of specific UEs. The AMF / SEAF 330 can further handle UE mobility management. The AMF may also include Security Anchoring Functions (SEAFs, such as...) Figure 3As indicated by AMF / SEAF 330 (as described in more detail below), this security anchoring function 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 interact with UDM / ARPF 370 to complete such user registration / authentication / key generation.

[0027] The SMF 340 can be allocated by the AMF / SEAF 330 for specific communication sessions instantiated in the wireless communication network 300. The SMF 340 can be responsible for allocating the UPF 350 to support communication sessions and data flows within the user data plane, and for provisioning / regulating the allocated UPF 350 (e.g., for developing packet detection and forwarding rules for the allocated UPF 350). Alternatively, the UPF 350 can be allocated by the AMF / SEAF 330 for specific communication sessions and data flows. The UPF 350, allocated and provisioned by the 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, the 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 can be applied to other types of wireless and wired communication networks.

[0030] Figure 3Network identification and data security in the wireless communication network 300 can be managed via a user authentication process provided by AMF / SEAF 330, AUSF 360, 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 the user contract and subscription data in UDM / ARPF 370. The communication session established for UE 310 after user authentication with the wireless communication network 300 can then be protected by various levels of encryption / decryption keys. The generation and management of these keys can be coordinated by AUSF 360 and other network functions within 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 the 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 Authentication and Key Management (AKMA) framework. The AKMA framework can be based on various authentication processes, such as the 5G Authentication and Key Protocol (5G-AKA) method, the Extensible Authentication Protocol for 3G Authentication and Key Negotiation (EAP-AKA) method, the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) method, and so on.

[0032] Figure 4 An example of an electronic device 500 for implementing various network nodes, network elements, and network entities, such as network base stations (e.g., radio access network nodes), core networks (CNs), core network elements / entities (e.g., AMF, UDM, AAnF, etc.), operations and maintenance (OAM), etc., is shown. Optionally, in one embodiment, the example electronic device 500 may include wireless transmit / receive (Tx / Rx) circuitry 508 to transmit / receive communications with the UE and / or other base stations. Optionally, in one embodiment, the electronic device 500 may also include network interface circuitry 509 to enable communication between the base station and other base stations and / or core networks (e.g., 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 communicating 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 use by one or more processors 521 to perform functions of the network node. Parameters 528 may include parameters that support 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, AF, can be implemented in hardware, software, or a combination of hardware and software, and can be implemented or integrated in electronic device 500. They can also be implemented as logical entities hosted by electronic device 500.

[0035] Figure 5 An example of an electronic device for implementing a terminal device 600 (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, with 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, for example, facilitates the decoding and playback of music and video, such as MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; runs applications; accepts user input; saves and retrieves application data; establishes, maintains, and terminates cellular phone calls or data connections, for example, for internet connections; establishes, maintains, and terminates wireless network connections, Bluetooth connections, or other connections; and displays relevant information on user interface 610. User interface 610 and input / output (I / O) interface 606 may include a graphical user interface, a touch-sensitive display, haptic feedback or other haptic outputs, voice or facial recognition inputs, buttons, switches, speakers, and other user interface elements. Additional examples of I / O interface 606 may include a microphone, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headphone and microphone input / output jacks, a universal serial bus (USB) connector, a memory card slot, radiation sensors (e.g., IR sensors), and other types of inputs.

[0036] refer to Figure 5 The communication interface 602 may include radio frequency (RF) transmitting (Tx) and receiving (Rx) circuitry 616 that processes the transmission and reception of signals via one or more antennas 614. The communication interface 602 may include one or more transceivers. These transceivers may be wireless transceivers, including modulation / demodulation circuitry, digital-to-analog converters (DACs), shapers, analog-to-digital converters (ADCs), 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, the communication interface 602 may include transceivers supporting transmission and reception under 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA)+, 4G / LTE, 5G, and 6G standards. However, the techniques described below are applicable to other wireless communication technologies, whether they originate 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 624, instructions 626, and parameters 628. Processor 621 is configured to execute instructions 626 to implement the desired functions of UE 600. Parameters 628 may be provided and specify configuration and operating options for instructions 626. Memory 622 may also store any BT, WiFi, 3G, 4G, 5G, 6G, 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 each radio), the UE can maintain a security context that includes a set of security parameters such as: Key Set Identifier (KSI) (e.g., ngKSI (Next Generation KSI), 5G-GUTI (5G Globally Unique Temporary Identifier), KAMF (AMF Key, also denoted as K...). AMF The prefix K means "key" and KgNB (i.e., the key of gNB).

[0040] In some example implementations, KAMF is composed of ME (Mobile Equipment, referring to a part of the UE together with other parts of the UE, such as the Universal Subscriber Identity Module (USIM)) and K SEAF The key derived from SEAF. KAMF can be used to generate, for example, integrity keys (such as K) 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 (such as K KN3IWF ).

[0041] In some example implementations, the KgNB is used to derive a new KgNB when horizontal or vertical key derivation is performed during handover, and is also used to derive the keys KUPenc, KUPint, KRRCenc, and KRRCint, respectively, used for confidentiality and integrity protection of User Plane (UP) services and Radio Resource Control (RRC) signaling. As mentioned above, the KgNB can be derived from 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 type of security context parameter indicating 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 a value of KSIAMF, and when the current 5G NAS security context is a mapped type, ngKSI has a value of 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. The security context may include information such as ngKSI1, 5G-GUTI1, and K... AMF Parameters such as 1 and KgNB1. Meanwhile, for this UE, AMF 1 stores ngKSI1, 5G-GUTI1, and K. AMF 1. The UDM stores the UE context for Radio 1 and AMF 1, as well as the mapping between Radio 1 and AMF 1. That is, from the UDM's perspective, the UE is using Radio 1 and is being served by AMF 1. Furthermore, the UDM can also store security context information for the (AMF1, Radio 1) pair. Note that security context information can be stored at the granularity of each 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 technology. 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, for example, user preferences, UE capabilities, service protocols, service profiles, etc. For example, user preferences may lean towards lower rates, in which case a lower-cost radio connection can be selected; user preferences may also lean towards higher data speeds / throughput, and radio 2 can be added on top of radio 1 to achieve the goal; user preferences may also lean towards better signal quality, and a radio with better coverage can be selected; user preferences may also lean towards power efficiency, and a radio with lower power consumption can 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 wireless fidelity (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, etc.; or Radio 1 may use a 3GPP-based access technology and Radio 2 may use a WLAN-based access technology. In some example embodiments, both Radio 1 and Radio 2 may 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 this example, the UE establishes two radio connections 710 and 712 pointing to 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 is achieved using two wireless devices.

[0047] Besides the dual radio access described above, where the same UE has two different radio accesses, another scenario exists where two radio devices (e.g., two physically separate radio devices) form a dual-booting relationship, such that each radio device has one radio access. These two radio devices are bound together due to the dual-booting relationship, and they can share the same set of subscription data. Each of the two radio devices can have its own SIM card. 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 is served by AMF1. UE2 is assigned SUPI2 and is 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 the dual-booting relationship between UE1 and UE2, they can be referred to as companion UEs.

[0049] This article 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 are registered with a network (the same network or different networks), traffic can be bootstrapped in both downlink and / or uplink directions. For example, when a video streaming application (APP) is running in UE1, the downlink traffic for the video can be bootstrapped to UE2, allowing the user to watch the video on the smart TV and take advantage of the larger screen. In another example, when a push notification is received, it will be bootstrapped to UE1 due to privacy concerns.

[0050] How to perform traffic redirection 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, traffic delay, and transmission power.

[0052] Billing rate for each radio access.

[0053] The type of application.

[0054] Application Quality of Service (QoS) requirements.

[0055] User preferences. For example, if users prefer a larger screen, or a smaller screen with a better resolution.

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

[0057] Implementing dual-booting mode in wireless networks presents unique challenges. Dual-booting involves coordination among various network elements, including two wireless devices bound together by a dual-booting relationship (in which UE1 and UE2 are mutually dependent). To determine how to bootstrap downlink and / or uplink traffic, a UE may need to know various parameters of its dependent UE. For example, UE1 needs to know UE2's state, access type, identifier (such as SUPI), and serving AMF, and vice versa. In another example, the same dual-booting strategy can be applied to both UE1 and UE2 simultaneously to achieve consistent traffic booting results. Therefore, dual-booting strategy synchronization is another factor to consider when implementing dual-booting features.

[0058] In this disclosure, the UE context is extended to accommodate dual-booting features. Specifically, parameters related to 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] The state of the UE. The state of the UE may include: connected state; idle state; powered off state; powered on state; inactive state; state within the coverage area; or state outside the coverage area.

[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; Proprietary access type and similar access types.

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

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

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

[0066] Various embodiments are described in this disclosure to address the aforementioned technical problems in dual-boot deployments.

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

[0068] 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 or share the same set of subscription data. UE1 and UE2 can have their own Subscription Permanent Identifiers (SUPI), SUPI1 and SUPI2.

[0069] Figures 9A to 9B ( Figure 9B yes Figure 9A (Continued from the previous section) This illustrates an example flowchart of UE1 registering with the network after its companion UE (i.e., UE2) via a dual-boot relationship has completed its registration with the network. An exemplary method may include some or all of the following steps.

[0070] Step 1: UE1 communicates with the wireless access point (such as a base station, for example) Figure 9A and Figure 9B The gNB1 shown sends a Registration Request (RR) message. This RR message may 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 may further carry a dual-booting indication, indicating 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 or share the same set of subscription data; or the registration type is dual-booting registration. Through such indication, the network side (e.g., gNB1, AMF1) can identify the need for dual-booting-specific settings / operations. This indication serves as a signal to the network that a special dual-booting scenario is involved.

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

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

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

[0074] Please note that one or more of the above parameters (such as SUPI2, UE2 access type, or UE2 state) carried in the response message can be considered as part of the UE1 context, or more specifically, they can be considered as dual-booting related context.

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

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

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

[0078] In another scenario, the link between AMF1 and the old AMF may be broken, so UE context transfer may not be possible.

[0079] AMF1 can send an identifier request message to UE1 to request UE1's identifier, such as a Subscribe Hidden Identifier (SUCI).

[0080] Step 6: UE1 can respond to AMF1 with an identifier response message, which may carry UE1's SUCI.

[0081] 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), AMF1 can select an AUSF in its home network based on the Mobile Country Code (MCC), Mobile Network Code (MNC), and the routing indicator in UE1's SUCI, and send a Nausf_UEAuthentication_Authenticate request message to that AUSF, which carries the SUCI and the service network name.

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

[0083] 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 extensible authentication protocol method for authentication and key negotiation, or another method, described below using 5G-AKA as an example). The UDM then calculates CK' and IK', and replaces CK and IK with CK' and IK' (i.e., the UDM updates the cryptographic key CK and the integrity key IK). The UDM then returns the 5G HE AV (5G Home Location Authentication Vector) along with an indication that the 5G HE AV will be used for 5G AKA to the AUSF in the Nudm_UEAuthentication_Get response. If the SUCI has already been included in the Nudm_UEAuthentication_Get request, the UDM will include the SUPI in the Nudm_UEAuthentication_Get response after de-hiding the SUCI in the SIDF.

[0084] Step 10: AUSF temporarily stores XRES* together with the received SUCI or SUPI. AUSF should then calculate HXRES* from XRES* and from K... AUSF Calculate K SEAF And in 5G HE AV, replace XRES* with HXRES*, and use K SEAF Replace K AUSF This is used to generate 5G AV from the 5G HE AV received from the UDM. Then, AUSF can remove K. SEAFIn the Nausf_UEAuthentication_Authenticate response, the 5G SE AV (RAND, AUTN, HXRES*) is returned to AMF1.

[0085] Step 11: AMF1 can send RAND and AUTN to UE1 in the NAS message authentication request. This message may also include ngKSI1 (i.e., ngKSI for AMF1), which will be used by the UE and AMF1 to identify K. AMF 1. And a portion of the native security context created upon successful authentication. This message may also include anti-analysis-based degradation (ABBA) parameters.

[0086] 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, then K AMF The UEID parameter P0 used in the (key 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 both 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 received the UE2 status before the current registration request, so UE1 can determine whether UE2 has already registered.

[0087] Step 12: The ME of (UE1) may 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 so, 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 GPRS Kc in the USIM or ME. The ME should then calculate RES* from RES. The ME then calculates K from CK||IK. AUSF ME should be from K AUSF Calculate K SEAFThe ME accessing 5G should check during authentication whether the "separation bit" in the AUTN's AMF field is set to 1. The "separation bit" is bit 0 in the AUTN's AMF field. UE1 can then return RES* to AMF1 in the NAS message authentication response.

[0088] 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 the RES* received from UE1 to AUSF in the Naus_UEAuthentication_Authenticate request message.

[0089] Step 14: When 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, AUSF considers authentication unsuccessful from the home network's perspective. After successful authentication, AUSF stores K based on the home network operator's policy. AUSF 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 considers authentication successful. The AUSF should notify the UDM of the authentication result. The AUSF should indicate to AMF1 in the Nausf_UEAuthentication_Authenticate response whether authentication was successful from the home network's perspective. If authentication is successful, then K SEAF It can be sent to SEAF in the Nausf_UEAuthentication_Authenticate response. If authentication is successful, AUSF can also include SUPI1 in the Nausf_UEAuthentication_Authenticate response message.

[0090] Step 15: AMF1 uses K SEAF To calculate K AMF 1. Using K AMF 1. Calculate the integrity protection key and encryption key, and calculate K. gNB 1. And send a NAS security mode command message to the UE. This message carries ngKSI, UE security capability information, and a NAS MAC checksum calculated using the NAS integrity protection key.

[0091] Step 16: UE uses K SEAF To calculate K AMF 1. At the same time, according to KAMF 1. Calculate the corresponding integrity protection key and encryption key, and calculate K. gNB 1. The NAS MAC is checked using the integrity key. If the integrity check is successful, a NAS secure mode completion message is returned to AMF1, carrying the NAS MAC verification value obtained by using the integrity key.

[0092] In some example implementations, if the registration type is dual-boot registration (e.g., registration will consider the accompanying UE2 used in dual-booting), and UE1 receives an indication that UE2 has successfully registered, then K AMF 1. The UE ID parameter P0 used in the AMF1 key 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.

[0093] Both steps 17a and 17b are optional.

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

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

[0096] Step 17a2 is optional. If the UDM decides to respond immediately after step 17a1 with readily available information (e.g., dual-booting related context information), the UDM may then send a response message. This response may carry the dual-booting related context information of 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). Note that the response indicates binding information, which shows the binding of UE1 and UE2 via dual-booting features. UE2's SUPI (i.e., SUPI2) is passed to the receiving entity via the binding information. If step 17a2 is performed, the process can skip directly to step 24a.

[0097] Alternatively, the UDM may decide to obtain more information before responding to step 17a1. In this case, step 17a2 is skipped, and the process can proceed directly to either step 17b or step 18.

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

[0099] In step 17b1, if AMF1 does not have the UE's subscription data, AMF1 can use Nudm_SDM_Get to retrieve access and mobility subscription data, SMF selection subscription data, UE context in SMF data, and LCS mobile initiation call.

[0100] Step 17b2 is optional. If the UDM decides to respond immediately after step 17b1 with readily available information, the UDM may then send a response message. If step 17a did not pass the dual-booting context information of UE1 to AMF1, the response in 17b2 may carry the dual-booting context information of UE1 (details of which are described in step 17a above). If step 17b2 is executed, the process can skip directly to step 24a.

[0101] If AMF1 already has the UE's subscription data, 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] Alternatively, the UDM may decide to obtain more information before responding to step 17b1. In this case, step 17b2 is skipped, and the process can proceed directly to step 18.

[0103] Step 18: If UE2 has already registered with the network, the UDM can send a message to AMF2, such as a Namf_Communication_UEBindingUpdate request message, based on the address of the AMF2 serving UE2 (e.g., the UDM can use SUPI2 to look up AMF2). This message can carry context information about UE1, such as SUPI1; the state of UE1; the dual-booting capability of UE1; and the access type of UE1. As mentioned earlier, the access type can include: 3GPP NR access type; NTN access type; NPN access type; proprietary access type; and similar types. This context information can also carry SUPI2 (so that AMF2 can identify the specific UE to which the message is addressed).

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

[0105] 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 policies for UE1 and UE2. Note that dual-boot policy can be a type of UE policy, in addition to other types of UE policies.

[0106] 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 (UE1 is bound to UE2 due to dual bootstrapping); the dual bootstrapping policy of UE1 and UE2 (this policy can be encapsulated in a UE policy container); UE1's state; UE1's dual bootstrapping capability; and UE1's access type (e.g., 3GPP 5G NR, NTN, or NPN). Through this step, relevant context information for UE1 is passed to UE2.

[0107] 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 one or more subsequent processes. UE2 can respond to AMF2 using, for example, a UL NAS message.

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

[0109] Step 22: AMF2 can respond to UDM using, for example, a Namf_Communication_UEBindingUpdate response message, which may carry at least one of the following: the dual-booting policy for UE1 and UE2 (which 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's address / identifier. UE1 (and / or UE2) may establish / create / update one or more dual-booting sessions (such as Packet Data Unit (PDU) sessions) based on the rules and traffic descriptors outlined in the dual-booting policy. The dual-booting policy may define a set of guidelines or instructions specifying when and how to initiate or modify these sessions to optimize network performance and / or meet specific dual-booting requirements.

[0110] Step 23: The UDM has obtained more dual-booting related information from AMF2, such as UE2 status, UE2 access type, dual-booting policy, and PCF address / identifier. The UDM can now send a response message to AMF1 (for the previous step 17a1 or 17b1). This response message may carry at least one of the following: the dual-booting policy for UE1 and UE2 (which may be encapsulated in a UE policy container), the status of UE2, the dual-booting capability of UE2, the access type of UE2 (e.g., 3GPP 5GNR, NTN, or NPN), and the PCF address / identifier.

[0111] Step 24a: Upon receiving a successful response, AMF1 can subscribe to the UDM so that it is 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.

[0112] Step 24b: When the UDM stores the associated access type (e.g., 3GPP access) along with UE1's current serving AMF (i.e., AMF1), it will cause the UDM to 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. The deregistration process can be implemented, for example, by sending a Nudm_UECM_DeregistrationNotification message to the old AMF.

[0113] Step 24c: 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 data.

[0114] Step 25: If the Namf_Communication_UEBindingUpdate response message in Step 22 does not carry the PCF address (or identifier), then AMF1 may select the PCF instance based on at least one of the following: dual booting capability of UE1 and / or UE2; the range to which SUPI1 belongs; the range to which SUPI2 belongs; or the result from the NRF discovery process. This discovery process may use at least one of the following as input: dual booting capability, SUPI1, or SUPI2.

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

[0116] Step 26: In this step, for dual-boot management UE and Access and Mobility Management (AM) policies, 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.

[0117] Please note: If UE2 is not registered, steps 25 and 26 are required. Otherwise, steps 25 and / or 26 can be skipped.

[0118] Step 27: AMF1 can assign 5G-GUTI2 (a new GUTI replacing 5G-GUTI1) to UE1 and return a registration acceptance message to UE1. This message may carry the newly assigned 5G-GUTI2. The message may also carry dual-booting related context information about UE2, such as SUPI2 (which is the SUPI accompanying the UE); UE2 state; or UE2 access type. As previously mentioned, the access type may include: 3GPP NR access type; NTN access type; NPN; proprietary access type; and similar types.

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

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

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

[0122] UE 1 can then return a registration complete message to AMF1.

[0123] From this point onward, UE1 and UE2 can perform dual-booting operations (e.g., bootstrapping or switching) on ​​the uplink / downlink data streams based on the dual-booting strategy for UE1 and UE2 and the dual-booting context information in subsequent processes. For example, UE1 can bootstrap downlink traffic of the video stream to UE2; or UE2 can bootstrap uplink traffic to UE1.

[0124] 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 associated with UE2, such as SUPI2, UE2 state, UE2 access type, UE2 dual-booting capability, etc. Additionally, during the registration process, a dual-booting policy (which may be part of a UE policy) can be created / updated and distributed to both UE1 and UE2 simultaneously. The dual-booting policy defines rules for the UE to bootstrap downlink and / or uplink traffic. For example, based on the dual-booting policy, UE1 can bootstrap certain downlink traffic (e.g., traffic associated with QoS flows, Packet Data Unit (PDU) sessions, etc.) to UE2, and UE2 can bootstrap certain uplink traffic to UE1.

[0125] During the registration process, AMF1, which serves UE1, can retrieve UE2-related dual-booting context information from UDM. Furthermore, AMF1 can subscribe to UDM to receive notifications when requested data (e.g., dual-booting context information) is updated.

[0126] In this disclosure, the AMFs (AMF1 and AMF2) and the UDM can act as bridges for transmitting UE information to each other. For example, AMF1 can pass UE1 information to the UDM, the UDM can pass the information to AMF2, and AMF2 can relay the UE1 information to UE2. Meanwhile, knowing the UE1 information, AMF2 can request the PCF to update the dual-boot policy and distribute the updated dual-boot policy to both UE2 and UE1 (e.g., via the UDM and AMF1).

[0127] In this disclosure, the UDM can act as a hub for exchanging dual-booting related information between UE1 / AMF1 and UE2 / AMF2.

[0128] It should be noted that in this disclosure, some steps in the embodiments may be optional, while others provide alternative solutions that can be paralleled with other steps. For example, AMF1 may obtain dual-booting related context information (e.g., SUPI2, UE2 state, UE2 access type) from various steps (such as steps 4, 17a, 17b, or 23). In this case, for example, steps 4, 17a, 17b, and 23 may provide parallel solutions, and steps from one or more of them may be included in the method according to the embodiments. When parallel solutions exist, not all solutions need to be included in the implementation.

[0129] 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 requesting registration with a first wireless network, wherein: the first wireless device and a second wireless device served by a second core network element 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 the following: 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 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; Step 2: Obtaining at least one subset of context information of the first wireless device, the context information including at least one of the following: a second SUPI; the access type of the second wireless device; or the status of the second wireless device.

[0130] In any part or combination of the above embodiments, each of the first core network element and the second core network element includes an access and mobility management function (AMF).

[0131] In any part or combination of the above embodiments, the access type of the second wireless device includes at least one of the following: 3GPP NR access type; NTN access type; or NPN access type.

[0132] In any part or combination of the above embodiments, 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 the coverage area state; or outside the coverage area state.

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

[0134] Please 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 are received in one step, while other parameters are received in other steps). Not all steps are mandatory, as long as the complete dual-boot context information has been received (e.g., via AMF and / or UE).

[0135] 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 included in this disclosure as long as the basic principle is the same, for example, if the messages are used for the same purpose.

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

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

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

[0139] The accompanying drawings and description provide specific example embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments set forth herein. A 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 above-described method embodiments can be implemented by a component, apparatus, or system including a memory and a processor by executing computer code stored in the memory.

[0140] Throughout the specification and claims, terms may have subtle meanings implied or implied in the context that go beyond their explicitly stated meaning. 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 different embodiments. For example, the subject matter intended to be protected may include a combination of all or some of the exemplary embodiments.

[0141] 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 include a variety of meanings, which depend at least in part on the context in which they are used. Typically, “or” means A, B, and C in an inclusive sense when used with an associative list, such as A, B, or C, and in an exclusive sense when used with A, B, or C. Additionally, the term “one or more,” as used herein, depends at least in part on the context and can be used to describe any feature, structure, or characteristic in a singular sense, or in a plural sense to describe a combination of features, structures, or characteristics. Similarly, terms such as “a,” “an,” or “the” can be understood to convey either a singular or plural usage, at least in part on the context. Furthermore, the term “based on” can be understood to not necessarily convey a set of exclusive factors and may allow for additional factors not explicitly described, at least in part on the context.

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

[0143] Furthermore, in one or more embodiments, the features, advantages, and characteristics of this solution can be combined in any suitable manner. Those skilled in the art will recognize from the description herein that this solution can be implemented 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 can be identified 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 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; 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 the context information of the first wireless device, the context information including at least one of the following: The second SUPI; The second wireless device has dual-boot capability; 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. as well as Obtaining at least one subset of the context information includes receiving at least one subset of the context information from the old core network element.

6. The method according to claim 5, wherein, At least one subset of the context information received includes: A second message requesting at least a subset of the context information is transmitted to the old core network element; and Receive a third message from the old core network element carrying at least a subset of the 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 of claim 5, further comprising transmitting to the first wireless device a ninth message carrying at least one of the following: At least a subset of the context information; or The second 5G-GUTI is assigned to the first wireless device.

9. 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 Kamf1 is derived based on at least one of the following: the first SUPI or the second SUPI.

10. The method according to claim 9, 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.

11. The method according to 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, 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.

12. The method according to any one of claims 1 to 4, wherein, Obtaining at least one subset of the 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 of the following: At least one subset of the context information; The dual-booting strategy is applied to the dual-booting feature of the first wireless device; or The identifier or address of the policy control function (PCF) that provides policy rules to the first wireless device.

13. The method according to claim 12, 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.

14. The method according to claim 12, wherein, The fourth message triggers the UDM to retrieve at least one of the following from the second core network element: A subset of the context information; The dual-guidance strategy; or Provide the first wireless device with the identifier or address of the policy rule's PCF.

15. The method according to claim 14, wherein, The dual-boot strategy is shared by the first wireless device and the second wireless device.

16. The method of claim 14, wherein, The dual-boot strategy is part of the UE strategy of the first wireless device.

17. The method according to claim 12, further comprising: In response to the first message, an eighth message accepting the registration request is transmitted to the first wireless device, the eighth message carrying at least one of the following: At least one subset of the context information; The second 5G-GUTI assigned to the first wireless device; or The dual-guide strategy.

18. The method according to claim 12, 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 fifth 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 Repository 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 UE policies.

19. 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 the unified data management (UDM) associated with the second wireless device, the first message including at least one of the following: a first subscription persistent identifier (SUPI) of the first wireless device; or context information of 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 access type of the second wireless device; or The status of the second wireless device.

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

21. The method according to claim 19, wherein, The first core network element includes access and mobility management functions (AMF).

22. The method according to claim 19, 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.

23. The method according to claim 19, 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.

24. The method according to any one of claims 19 to 23, 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 following: the first wireless device; Or the second wireless device, wherein the second message includes 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.

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

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

27. The method of claim 24, 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.

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

29. The method of claim 28, further comprising receiving a response to the third message, the response including an uplink (UL) NAS message.

30. The method of claim 24, further comprising transmitting a fourth message to the UDM as a response to the first message, the fourth message comprising 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 identifier of the PCF; or The address of the PCF.

31. 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 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.

32. The method according to claim 31, wherein, The first core network element includes access and mobility management functions (AMF).

33. The method according to any one of claims 31 to 32, 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 Kamf1 is derived based on at least one of the following: the first SUPI or the second SUPI.

34. The method according to claim 33, 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.

35. The method according to any one of claims 31 to 32, further comprising: The first core network element receives a second message accepting the registration request as a response to the first message, the second message carrying at least one of the following: The context information of the first wireless device includes at least one of the following: The second SUPI; The access type of the second wireless device; or The status of the second wireless device; The second 5G-GUTI assigned to the first wireless device replaces the first 5G-GUTI; or The dual-booting strategy is applied to the dual-booting feature of the first wireless device.

36. The method according to claim 35, 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.

37. The method of claim 35, 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.

38. The method according to any one of claims 35, further comprising: The downlink reception or uplink transmission is performed based on the dual-guidance strategy.

39. A wireless communication method performed by a first wireless device, the method comprising receiving a first message from a first core network element, 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 a first Subscription Permanent Identifier (SUPI) and a second SUPI, respectively; and The first message carries at least one of the following: The second wireless device has a 5G globally unique temporary identifier (5G-GUTI). 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.

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

41. The method according to claim 39, wherein, The first core network element includes access and mobility management functions (AMF).

42. The method according to claim 39, 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.

43. The method according to claim 39, 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.

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

45. The method according to any one of claims 39 to 43, 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.

46. ​​The method according to any one of claims 39 to 43, the method further comprising: The downlink reception or uplink transmission is performed based on the dual-guidance strategy.

47. An apparatus comprising a memory for storing computer instructions and a processor in communication with the memory, wherein, The processor is configured to perform the method according to any one of claims 1 to 46 when executing the computer instructions.

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

Images