Method and apparatus to establish a decentralized multi-device experience network

Abstract

Methods and apparatuses are provided for establishing decentralized multi-device experience (MDE) networks without relying on cloud infrastructure. A user equipment (UE) obtains a secure context, including one or more keys associated with the UE and a second apparatus for wireless communication, within a cloud-less network for MDE, and communicates securely with the second apparatus. In some examples, the secure context is obtained through out-of-band (OOB) confirmation using near field wireless communication. In some examples, the UE updates the secure context with additional apparatuses through OOB confirmations and broadcasts the updated context using near field communication. In some examples, the secure context functions as a trust secure context, linking multiple MDE networks and allowing devices from different networks to communicate securely regardless of the original equipment manufacturer (OEM). Thus, the disclosed methods and apparatuses provide enhanced interoperability and security in MDE networks.

Description

METHOD AND APPARATUS TO ESTABLISH A DECENTRALIZED MULTI-DEVICE EXPERIENCE NETWORKTECHNICAL FIELD

[0001] The present disclosure generally pertains to the field of wireless communication, and more particularly, to methods and apparatuses for establishing decentralized or cloud-less multi-device experience networks.

[0002] DESCRIPTION OF THE RELATED TECHNOLOGY

[0003] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0004] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example telecommunication standard is 5G New Radio (NR) . 5G NR is part of a continuous mobile broadband evolution promulgated by Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (such as with Internet of Things (IoT) ) , and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB) , massive machine type communications (mMTC) , and ultra-reliable low latency communications (URLLC) . Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. There exists a need for further improvements in 5G NR technology. These improvements also may be applicable to other multi-access technologies and the telecommunication standards that employ these technologies.SUMMARY

[0005] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0006] One innovative aspect of the subject matter described in this disclosure may be implemented in a first apparatus for wireless communication, which may be a user equipment (UE) . The first apparatus includes one or more memories, and one or more processors each communicatively coupled with at least one of the one or more memories. The one or more processors, individually or in any combination, are operable to cause the first apparatus to obtain a secure context including one or more keys associated with the first apparatus and a second apparatus for wireless communication, which may be another UE, in a cloud-less network for a multi-device experience (MDE) . The one or more processors, individually or in any combination, are further operable to cause the apparatus to communicate, in association with the obtained secure context, with the second apparatus.

[0007] Another innovative aspect of the subject matter described in this disclosure may be implemented in a method for wireless communication performable at a UE. The method includes obtaining a secure context including one or more keys associated with a first wireless communication device such as a first UE and a second wireless communication device such as a second UE, the secure context being obtained in a cloud-less network for a MDE, and communicating, in association with the obtained secure context, with the second wireless communication device.

[0008] In some implementations of the apparatus or method, the secure context is obtained in response to an out-of-band (OOB) confirmation of the second apparatus to the cloud-less network using near field wireless communication.

[0009] In some implementations of the apparatus or method, the first apparatus and the second apparatus are associated with different original equipment manufacturers (OEMs) or a same OEM.

[0010] In some implementations of the apparatus or method, the one or more processors, individually or in any combination, are further operable to cause the first apparatus to store the secure context in the one or more memories of the first apparatus, where one or more memories of the second apparatus further include the secure context.

[0011] In some implementations of the apparatus or method, the one or more processors, individually or in any combination, are further operable to cause the first apparatus to obtain an OOB  confirmation of an additional apparatus for wireless communication, which may be another UE, to the cloud-less network. The one or more processors, individually or in any combination, are further operable to cause the apparatus to update the secure context with a key of the additional apparatus in response to the OOB confirmation.

[0012] In some implementations of the apparatus or method, the one or more processors, individually or in any combination, are further operable to cause the first apparatus to send the updated secure context to the additional apparatus.

[0013] In some implementations of the apparatus or method, the one or more processors, individually or in any combination, are further operable to cause the first apparatus to send the updated secure context in a broadcast to the second apparatus and the additional apparatus using near field wireless communication.

[0014] In some implementations of the apparatus or method, the secure context is a trust secure context, the cloud-less network includes a first network and a second network respectively for the MDE, the first apparatus is in the first network, and the second apparatus is in the second network, the trust secure context associating the first network and the second network.

[0015] In some implementations of the apparatus or method, the one or more processors, individually or in any combination, are further operable to cause the first apparatus to send the trust secure context in a first broadcast to a third apparatus for wireless communication in the first network using near field wireless communication, which third apparatus may be another UE. The trust secure context may further be in a second broadcast from the second apparatus to a fourth apparatus in the second network using the near field wireless communication, which fourth apparatus may be another UE. The third apparatus in the first network may be associated with the fourth apparatus in the second network.

[0016] To the accomplishment of the foregoing and related ends, the one or more aspects include the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a diagram illustrating an example of a wireless communications system and an access network.

[0018] Figure 2A is a diagram illustrating an example of a first subframe within a 5G NR frame structure.

[0019] Figure 2B is a diagram illustrating an example of DL channels within a 5G NR subframe.

[0020] Figure 2C is a diagram illustrating an example of a second subframe within a 5G NR frame structure.

[0021] Figure 2D is a diagram illustrating an example of UL channels within a 5G NR subframe.

[0022] Figure 3 is a block diagram illustrating an example of a base station and a user equipment (UE) involved in wireless communication.

[0023] Figure 4 is a block diagram illustrating an example of a multi-device experience (MDE) network using a cloud as a trust center.

[0024] Figure 5 is a block diagram illustrating an example of a cross-user MDE network using a cloud as a trust center.

[0025] Figure 6 is a block diagram illustrating an example of a decentralized MDE network.

[0026] Figure 7 is a block diagram illustrating an example of a cross-user, decentralized MDE network, which includes a trusted relationship between multiple MDE networks respectively belonging to different users.

[0027] Figure 8 shows an example call flow diagram between a first UE and a second UE in a decentralized MDE network.

[0028] Figure 9 shows an example call flow diagram between a first UE and a second UE in a cross-user, decentralized MDE network.

[0029] Figure 10 shows a flowchart of an example method or process for wireless communication.

[0030] Figure 11 shows a flowchart of another example method or process for wireless communication.

[0031] Figure 12 shows a diagram illustrating an example of a hardware implementation for an apparatus for wireless communication.

[0032] Like reference numbers and designations in the various drawings indicate like elements.DETAILED DESCRIPTION

[0033] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0034] Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0035] By way of example, an element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems on a chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0036] Accordingly, in one or more example implementations, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that may be accessed by a computer. By way of example, and not  limitation, such computer-readable media may include a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that may be used to store computer executable code in the form of instructions or data structures that may be accessed by a computer.

[0037] Multi-Device Experience (MDE) is a design paradigm where users interact with digital services across multiple devices seamlessly. As the number of smart devices and the Internet of Things (IoT) grow, MDE becomes increasingly important. It focuses on creating an integrated experience, where activities on one device enhance the experience on another. For instance, MDE allows for a user to start a movie on one user equipment (UE) and continue it on another UE, facilitated by data synchronization across devices via Wi-Fi-based protocols.

[0038] MDE Networks are systems where connected UEs or other devices share information to function as an integrated unit. These networks involve various UEs such as smartphones, tablets, and smart TVs, operating across different systems and interfaces to perform MDE use cases. Examples of use cases include features that allow UEs to copy content on one device and paste it on another, to start a task on one device and continue it on another, and to work on documents with others in real-time so that users may perceive changes on different devices as they happen.

[0039] In an MDE network, devices communicate through a central server or cloud-based system, which synchronizes data and ensures a consistent user experience. The cloud stores and manages secure contexts, which include cryptographic keys and device lists, to facilitate secure communication between devices in the network. The secure contexts allow for authorized devices to access data for MDE use cases, maintaining data integrity, confidentiality, and availability. User keys are applied to encrypt and decrypt the data, while device lists track authorized UEs which communicate this data. These secure contexts are synchronized across devices and their users, allowing seamless and secure interactions in the MDE network.

[0040] Original Equipment Manufacturers (OEMs) play an important role in MDE networks of UEs by producing the hardware for these UEs or other devices. In MDE networks including devices sharing a single OEM, compatibility and seamless integration may be provided, since the UEs come from the same manufacturer. In contrast, when devices come from different manufacturers or the UEs are cross-OEM, communication challenges may arise due to OEM- specific ecosystems or “walled gardens, ” in which the cloud prevents interoperability and synchronization between the different devices in the MDE network.

[0041] Therefore, while current MDE networks provide secure multi-device interactions via a cloud-based trust center that synchronizes secure contexts via Wi-Fi-based protocols, challenges such as reliance on centralized cloud systems, lack of interoperability between different OEMs, high cloud maintenance costs, and potential internet disruptions are significant. To overcome these challenges, example implementations establish an MDE network without cloud dependency. These implementations eliminate the need for network-based device registration and storage, reduce Internet reliance, and enhance interoperability across various OEMs.

[0042] Accordingly, various aspects of the subject matter described in this disclosure relate generally to wireless communication systems, and more particularly to methods and apparatuses for establishing decentralized MDE networks without relying on cloud infrastructure. Some aspects specifically relate to allowing secure and seamless communication across devices from different OEMs using near field wireless communication. In various examples, apparatuses and methods are provided in which a first apparatus such as a UE obtains a secure context including one or more keys associated with the first apparatus and a second apparatus for wireless communication such as another UE. The secure context is obtained in a cloud-less network for a multi-device experience (MDE) . The first apparatus communicates, in association with the obtained secure context, with the second apparatus.

[0043] In some implementations, the MDE network may eliminate issues such as cloud dependency, latency, offline risks, and OEM walled gardens associated with cloud-based MDE networks. Devices from different OEMs may interact without relying on a shared cloud. Devices may store their secure context including cryptographic keys and device lists locally, allowing for seamless communication across the network.

[0044] In some implementations, the MDE network may apply near field wireless technology, such as  near-field communication (NFC) , ultra-wideband (UWB) , Wi-Fi or other technology for close-proximity communication. The use of near field wireless communication allows for devices in the MDE network to communicate secure contexts and data to other UEs with low latency, providing for efficient data transfer between nearby devices in the network without reliance on internet connectivity.

[0045] In some implementations, a secure context assignment or a trust secure context assignment may be performed directly between devices in same or different MDE networks using near field wireless technology. For instance, devices in a network may perform an out-of-band (OOB)  confirmation, where one device sends a personal identification number (PIN) or password or other identifier to another device in the same or different network for the latter device to confirm, in response to which confirmation the devices generate a secure context in the same network or a trust secure context in a different network. These secure contexts may include cryptographic keys and device lists for the various devices within the same or different MDE networks, facilitating seamless interaction between single and cross-OEM devices.

[0046] In some implementations, a UE may provision, or add, another device to its MDE network. For instance, the UE and the other device may perform an OOB confirmation to connect the other device to the UE’s network. Afterwards, the UE may update its secure context or trust secure context to account for the other device, and the UE may broadcast the updated secure context to other devices in its MDE network. If the other device being added is in another MDE network, that device may similarly broadcast the updated trust secure context to its own devices within its MDE network. Therefore, devices in the same or different MDE networks may have the latest secure context information for various devices. UEs may recognize and interact with other UEs securely without relying on a centralized cloud infrastructure. Moreover, UEs may broadcast secure contexts to their own devices in the MDE network while trusted devices may handle their own broadcasting in other MDE networks, thereby maintaining security and integrity within the MDE networks.

[0047] Particular aspects of the subject matter described in this disclosure may be implemented to realize one or more potential advantages. For example, the disclosed methods and apparatuses may enhance interoperability and security in MDE networks by allowing UEs to respectively obtain secure contexts including one or more keys associated with the UEs within a cloud-less MDE network and communicate securely with one another. The absence of a central cloud-based server may allow the MDE network to remain operational even if a central server goes offline. In traditional cloud-based solutions, if the cloud service is disrupted, connected devices lose their ability to communicate effectively. However, in the decentralized MDE network, devices may continue to function and communicate with other devices in the network, enabling uninterrupted service.

[0048] In some implementations, cross-OEM communication may be supported in the MDE network, in contrast to traditional MDE networks that often restrict communication to devices from the same manufacturer. This interoperability allows users to integrate a wide range of devices from different manufacturers into a single cohesive network, enhancing the flexibility and utility of the MDE. Additionally, supported hardware capabilities of UEs for wireless communication,  such as and Wi-Fi, may be leveraged for communication in the MDE network without additional infrastructure or hardware investments. This not only reduces costs of deploying MDE networks but also simplifies the deployment process, making the network accessible to a wide variety of UEs. Likewise, the performance of MDE networks may be superior to that of traditional internet-based networks. Through the use of near field wireless technology, faster transmission speeds and greater stability may be achieved compared to typical Wi-Fi protocols, especially when the devices in the network are in close proximity. This improvement in performance is particularly beneficial for typical MDE use cases or applications that utilize high-speed data transfer and low latency, such as real-time collaboration and multimedia sharing. The stability of the MDE network is also enhanced, as it is less affected by external factors such as internet congestion and server downtimes.

[0049] Accordingly, in various implementations, a distributed MDE network or a distributed, trusted, cross-user MDE network may be established which utilizes near field wireless technology, addressing the limitations of current cloud-centric MDE networks. By eliminating the need for a centralized cloud infrastructure and enhancing the interoperability and security of the devices within the network or of devices across different users, the MDE network provides a more robust and reliable multi-device experience. The secure context, which includes user keys and the list of user devices, allows for multiple devices within the network to recognize and interact with each other securely, allowing for various MDE use cases. Similarly, the trust secure context, which includes trust keys and the list of trusted devices, allows for multiple devices within the network to recognize and interact with each other securely while providing for various cross-user MDE use cases. This distributed approach not only enhances the security of the MDE network or cross-user MDE network, but also improves its reliability and performance, providing a seamless and secure multi-device experience for users.

[0050] Figure 1 is a diagram illustrating an example of a wireless communications system and an access network 100. The wireless communications system (also referred to as a wireless wide area network (WWAN) ) includes base stations 102, user equipment (s) (UE) 104, an Evolved Packet Core (EPC) 160, and another core network 190 (such as a 5G Core (5GC) ) . The base stations 102 may include macrocells (high power cellular base station) or small cells (low power cellular base station) . The macrocells include base stations. The small cells include femtocells, picocells, and microcells.

[0051] The base stations 102 configured for 4G Long Term Evolution (LTE) (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access  Network (E-UTRAN) ) may interface with the EPC 160 through first backhaul links 132 (such as S1 interface) . The base stations 102 configured for 5G New Radio (NR) (collectively referred to as Next Generation RAN (NG-RAN) ) may interface with core network 190 through second backhaul links 184. In addition to other functions, the base stations 102 may perform one or more of the following functions: transfer of user data, radio channel ciphering and deciphering, integrity protection, header compression, mobility control functions (such as handover, dual connectivity) , inter-cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, Multimedia Broadcast Multicast Service (MBMS) , subscriber and equipment trace, RAN information management (RIM) , paging, positioning, and delivery of warning messages. The base stations 102 may communicate directly or indirectly (such as through the EPC 160 or core network 190) with each other over third backhaul links 134 (such as X2 interface) . The first backhaul links 132, the second backhaul links 184, and the third backhaul links 134 may be wired or wireless.

[0052] The base stations 102 may wirelessly communicate with the UEs 104. Each of the base stations 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, the small cell 102' may have a coverage area 110' that overlaps the coverage area 110 of one or more macro base stations 102. A network that includes both small cell and macrocells may be known as a heterogeneous network. A heterogeneous network also may include Home Evolved Node Bs (eNBs) (HeNBs) , which may provide service to a restricted group known as a closed subscriber group (CSG) . The communication links 120 between the base stations 102 and the UEs 104 may include uplink (UL) (also referred to as reverse link) transmissions from a UE 104 to a base station 102 or downlink (DL) (also referred to as forward link) transmissions from a base station 102 to a UE 104. The communication links 120 may use multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, or transmit diversity. The communication links may be through one or more carriers. The base stations 102  / UEs 104 may use spectrum up to Y megahertz (MHz) (such as 5, 10, 15, 20, 100, 400, etc. MHz) bandwidth per carrier allocated in a carrier aggregation of up to a total of Yx MHz (x component carriers) used for transmission in each direction. The carriers may or may not be adjacent to each other. Allocation of carriers may be asymmetric with respect to DL and UL (such as more or fewer carriers may be allocated for DL than for UL) . The component carriers may include a primary component carrier and one or more secondary component carriers. A  primary component carrier may be referred to as a primary cell (PCell) and a secondary component carrier may be referred to as a secondary cell (SCell) .

[0053] Certain UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL / UL WWAN spectrum. The D2D communication link 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH) , a physical sidelink discovery channel (PSDCH) , a physical sidelink shared channel (PSSCH) , and a physical sidelink control channel (PSCCH) . D2D communication may be through a variety of wireless D2D communications systems, such as for example, WiMedia,  Wi-Fi based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, LTE, or NR.

[0054] The wireless communications system may further include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 via communication links 154, such as in a 5 gigahertz (GHz) unlicensed frequency spectrum or the like. When communicating in an unlicensed frequency spectrum, the STAs 152  / AP 150 may perform a clear channel assessment (CCA) prior to communicating in order to determine whether the channel is available.

[0055] The small cell 102' may operate in a licensed or an unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell 102' may employ NR and use the same unlicensed frequency spectrum (such as 5 GHz, or the like) as used by the Wi-Fi AP 150. The small cell 102', employing NR in an unlicensed frequency spectrum, may boost coverage to or increase capacity of the access network.

[0056] The electromagnetic spectrum is often subdivided, based on frequency / wavelength, into various classes, bands, channels, etc. In 5G NR, two initial operating bands have been identified as frequency range designations FR1 (410 MHz –7.125 GHz) and FR2 (24.25 GHz –52.6 GHz) . The frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Although a portion of FR1 is greater than 6 GHz, FR1 is often referred to (interchangeably) as a “sub-6 GHz” band in various documents and articles. A similar nomenclature issue sometimes occurs with regard to FR2, which is often referred to (interchangeably) as a “millimeter wave” band in documents and articles, despite being different from the extremely high frequency (EHF) band (30 GHz –300 GHz) which is identified by the International Telecommunications Union (ITU) as a “millimeter wave” band.

[0057] With the above aspects in mind, unless specifically stated otherwise, it should be understood that the term “sub-6 GHz” or the like if used herein may broadly represent frequencies that may be less than 6 GHz, may be within FR1, or may include mid-band frequencies. Further, unless  specifically stated otherwise, it should be understood that the term “millimeter wave” or the like if used herein may broadly represent frequencies that may include mid-band frequencies, may be within FR2, or may be within the EHF band.

[0058] A base station 102, whether a small cell 102' or a large cell (such as macro base station) , may include or be referred to as an eNB, gNodeB (gNB) , or another type of base station. Some base stations, such as gNB 180 may operate in a traditional sub 6 GHz spectrum, in millimeter wave frequencies, or near millimeter wave frequencies in communication with the UE 104. When the gNB 180 operates in millimeter wave or near millimeter wave frequencies, the gNB 180 may be referred to as a millimeter wave base station. The millimeter wave base station 180 may utilize beamforming 182 with the UE 104 to compensate for the path loss and short range. The base station 180 and the UE 104 may each include a plurality of antennas, such as antenna elements, antenna panels, or antenna arrays to facilitate the beamforming.

[0059] The base station 180 may transmit a beamformed signal to the UE 104 in one or more transmit directions 182'. The UE 104 may receive the beamformed signal from the base station 180 in one or more receive directions 182”. The UE 104 also may transmit a beamformed signal to the base station 180 in one or more transmit directions. The base station 180 may receive the beamformed signal from the UE 104 in one or more receive directions. The base station 180  / UE 104 may perform beam training to determine the best receive and transmit directions for each of the base station 180  / UE 104. The transmit and receive directions for the base station 180 may or may not be the same. The transmit and receive directions for the UE 104 may or may not be the same.

[0060] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, an MBMS Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may be in communication with a Home Subscriber Server (HSS) 174. The MME 162 is the control node that processes the signaling between the UEs 104 and the EPC 160. Generally, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are transferred through the Serving Gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to the IP Services 176. The IP Services 176 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, or other IP services. The BM-SC 170 may provide functions for MBMS user service provisioning and delivery. The BM-SC 170 may serve as an entry point for content provider MBMS  transmission, may be used to authorize and initiate MBMS Bearer Services within a public land mobile network (PLMN) , and may be used to schedule MBMS transmissions. The MBMS Gateway 168 may be used to distribute MBMS traffic to the base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start / stop) and for collecting eMBMS related charging information.

[0061] The core network 190 may include an Access and Mobility Management Function (AMF) 192, other AMFs 193, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may be in communication with a Unified Data Management (UDM) 196. The AMF 192 is the control node that processes the signaling between the UEs 104 and the core network 190. Generally, the AMF 192 provides Quality of Service (QoS) flow and session management. All user IP packets are transferred through the UPF 195. The UPF 195 provides UE IP address allocation as well as other functions. The UPF 195 is connected to the IP Services 197. The IP Services 197 may include the Internet, an intranet, an IMS, a Packet Switch (PS) Streaming Service, or other IP services.

[0062] The base station may include or be referred to as a gNB, Node B, eNB, an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a transmit reception point (TRP) , or some other suitable terminology. The base station 102 provides an access point to the EPC 160 or core network 190 for a UE 104. Examples of UEs 104 include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA) , a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (such as MP3 player) , a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similar functioning device. Some of the UEs 104 may be referred to as IoT devices (such as parking meter, gas pump, toaster, vehicles, heart monitor, etc. ) . The UE 104 also may be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0063] In certain aspects, the UE 104 may include an MDE component 198 that is configured to obtain a secure context, including one or more keys associated with the UE and a second apparatus for  wireless communication, within a cloud-less network for a multi-device experience. The first apparatus and the second apparatus may both be UEs 104, for example, allowing them to communicate securely using the obtained secure context.

[0064] Although the present disclosure may focus on 5G NR, the concepts and various aspects described herein may be applicable to other similar areas, such as LTE, LTE-Advanced (LTE-A) , Code Division Multiple Access (CDMA) , Global System for Mobile communications (GSM) , or other wireless / radio access technologies.

[0065] Figure 2A is a diagram 200 illustrating an example of a first subframe within a 5G NR frame structure. Figure 2B is a diagram 230 illustrating an example of DL channels within a 5G NR subframe. Figure 2C is a diagram 250 illustrating an example of a second subframe within a 5G NR frame structure. Figure 2D is a diagram 280 illustrating an example of UL channels within a 5G NR subframe. The 5G NR frame structure may be frequency division duplexed (FDD) in which for a particular set of subcarriers (carrier system bandwidth) , subframes within the set of subcarriers are dedicated for either DL or UL, or may be time division duplexed (TDD) in which for a particular set of subcarriers (carrier system bandwidth) , subframes within the set of subcarriers are dedicated for both DL and UL. In the examples provided by Figures 2A, 2C, the 5G NR frame structure is assumed to be TDD, with subframe 4 being configured with slot format 28 (with mostly DL) , where D is DL, U is UL, and F is flexible for use between DL / UL, and subframe 3 being configured with slot format 34 (with mostly UL) . While subframes 3, 4 are shown with slot formats 34, 28, respectively, any particular subframe may be configured with any of the various available slot formats 0-61. Slot formats 0, 1 are all DL, UL, respectively. Other slot formats 2-61 include a mix of DL, UL, and flexible symbols. UEs are configured with the slot format (dynamically through DL control information (DCI) , or semi-statically / statically through radio resource control (RRC) signaling) through a received slot format indicator (SFI) . Note that the description infra applies also to a 5G NR frame structure that is TDD.

[0066] Other wireless communication technologies may have a different frame structure or different channels. A frame, such as of 10 milliseconds (ms) , may be divided into 10 equally sized subframes (1 ms) . Each subframe may include one or more time slots. Subframes also may include mini-slots, which may include 7, 4, or 2 symbols. Each slot may include 7 or 14 symbols, depending on the slot configuration. For slot configuration 0, each slot may include 14 symbols, and for slot configuration 1, each slot may include 7 symbols. The symbols on DL may be cyclic prefix (CP) orthogonal frequency-division multiplexing (OFDM) (CP-OFDM)  symbols. The symbols on UL may be CP-OFDM symbols (for high throughput scenarios) or discrete Fourier transform (DFT) spread OFDM (DFT-s-OFDM) symbols (also referred to as single carrier frequency-division multiple access (SC-FDMA) symbols) (for power limited scenarios; limited to a single stream transmission) . The number of slots within a subframe is based on the slot configuration and the numerology. For slot configuration 0, different numerologies μ 0 to 4 allow for 1, 2, 4, 8, and 16 slots, respectively, per subframe. For slot configuration 1, different numerologies 0 to 2 allow for 2, 4, and 8 slots, respectively, per subframe. Accordingly, for slot configuration 0 and numerology μ, there are 14 symbols / slot and 2μ slots / subframe. The subcarrier spacing and symbol length / duration are a function of the numerology. The subcarrier spacing may be equal to 2^μ*15 kilohertz (kHz) , where μ is the numerology 0 to 4. As such, the numerology μ=0 has a subcarrier spacing of 15 kHz and the numerology μ=4 has a subcarrier spacing of 240 kHz. The symbol length / duration is inversely related to the subcarrier spacing. Figures 2A-2D provide an example of slot configuration 0 with 14 symbols per slot and numerology μ=2 with 4 slots per subframe. The slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs. Within a set of frames, there may be one or more different bandwidth parts (BWPs) (see Figure 2B) that are frequency division multiplexed. Each BWP may have a particular numerology.

[0067] A resource grid may be used to represent the frame structure. Each time slot includes a resource block (RB) (also referred to as physical RBs (PRBs) ) that extends 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs) . The number of bits carried by each RE depends on the modulation scheme.

[0068] As illustrated in Figure 2A, some of the REs carry reference (pilot) signals (RS) for the UE. The RS may include demodulation RS (DM-RS) (indicated as Rx for one particular configuration, where 100x is the port number, but other DM-RS configurations are possible) and channel state information reference signals (CSI-RS) for channel estimation at the UE. The RS also may include beam measurement RS (BRS) , beam refinement RS (BRRS) , and phase tracking RS (PT-RS) .

[0069] Figure 2B illustrates an example of various DL channels within a subframe of a frame. The physical downlink control channel (PDCCH) carries DCI within one or more control channel elements (CCEs) , each CCE including nine RE groups (REGs) , each REG including four consecutive REs in an OFDM symbol. A PDCCH within one BWP may be referred to as a control resource set (CORESET) . Additional BWPs may be located at greater or lower frequencies across the channel bandwidth. A primary synchronization signal (PSS) may be  within symbol 2 of particular subframes of a frame. The PSS is used by a UE 104 to determine subframe / symbol timing and a physical layer identity. A secondary synchronization signal (SSS) may be within symbol 4 of particular subframes of a frame. The SSS is used by a UE to determine a physical layer cell identity group number and radio frame timing. Based on the physical layer identity and the physical layer cell identity group number, the UE may determine a physical cell identifier (PCI) . Based on the PCI, the UE may determine the locations of the aforementioned DM-RS. The physical broadcast channel (PBCH) , which carries a master information block (MIB) , may be logically grouped with the PSS and SSS to form a synchronization signal (SS)  / PBCH block (also referred to as SS block (SSB) ) . The MIB provides a number of RBs in the system bandwidth and a system frame number (SFN) . The physical downlink shared channel (PDSCH) carries user data, broadcast system information not transmitted through the PBCH such as system information blocks (SIBs) , and paging messages.

[0070] As illustrated in Figure 2C, some of the REs carry DM-RS (indicated as R for one particular configuration, but other DM-RS configurations are possible) for channel estimation at the base station. The UE may transmit DM-RS for the physical uplink control channel (PUCCH) and DM-RS for the physical uplink shared channel (PUSCH) . The PUSCH DM-RS may be transmitted in the first one or two symbols of the PUSCH. The PUCCH DM-RS may be transmitted in different configurations depending on whether short or long PUCCHs are transmitted and depending on the particular PUCCH format used. The UE may transmit sounding reference signals (SRS) . The SRS may be transmitted in the last symbol of a subframe. The SRS may have a comb structure, and a UE may transmit SRS on one of the combs. The SRS may be used by a base station for channel quality estimation to enable frequency-dependent scheduling on the UL.

[0071] Figure 2D illustrates an example of various UL channels within a subframe of a frame. The PUCCH may be located as indicated in one configuration. The PUCCH carries uplink control information (UCI) , such as scheduling requests, a channel quality indicator (CQI) , a precoding matrix indicator (PMI) , a rank indicator (RI) , and hybrid automatic repeat request (HARQ) acknowledgement (ACK)  / non-acknowledgement (NACK) feedback. The PUSCH carries data and may additionally be used to carry a buffer status report (BSR) , a power headroom report (PHR) , or UCI.

[0072] Figure 3 is a block diagram of a base station 310 such as base station 102 / 180 in communication with a UE 350 such as UE 104 in an access network. IP packets from the EPC 160 may be provided to one or more controllers / processors 375 of base station 310. The one or more  controllers / processors 375 implement layer 3 and layer 2 functionality. Layer 3 includes a radio resource control (RRC) layer, and layer 2 includes a service data adaptation protocol (SDAP) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The one or more controllers / processors 375 provide RRC layer functionality associated with broadcasting of system information (such as MIB, SIBs) , RRC connection control (such as RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release) , inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression  / decompression, security (ciphering, deciphering, integrity protection, integrity verification) , and handover support functions; RLC layer functionality associated with the transfer of upper layer protocol data units (PDUs) , error correction through ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs) , re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs) , demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0073] The one or more transmit (TX) processors 316 and the one or more receive (RX) processors 370 of base station 310 implement layer 1 functionality associated with various signal processing functions. Layer 1, which includes a physical (PHY) layer, may include error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The one or more TX processors 316 handle mapping to signal constellations based on various modulation schemes (such as binary phase-shift keying (BPSK) , quadrature phase-shift keying (QPSK) , M-phase-shift keying (M-PSK) , M-quadrature amplitude modulation (M-QAM) ) . The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an OFDM subcarrier, multiplexed with a reference signal (such as pilot) in the time or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from a channel estimator 374 may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a reference signal or channel  condition feedback transmitted by the UE 350. Each spatial stream may then be provided to a different antenna 320 via a separate transmitter 318TX. Each transmitter 318TX may modulate an RF carrier with a respective spatial stream for transmission.

[0074] At the UE 350, each receiver 354RX receives a signal through its respective antenna 352. Each receiver 354RX recovers information modulated onto an RF carrier and provides the information to the one or more receive (RX) processors 356. The one or more TX processors 368 and the one or more RX processors 356 of UE 350 implement layer 1 functionality associated with various signal processing functions. The one or more RX processors 356 may perform spatial processing on the information to recover any spatial streams destined for the UE 350. If multiple spatial streams are destined for the UE 350, they may be combined by the one or more RX processors 356 into a single OFDM symbol stream. The one or more RX processors 356 then convert the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT) . The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are recovered and demodulated by determining the most likely signal constellation points transmitted by the base station 310. These soft decisions may be based on channel estimates computed by the channel estimator 358. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the base station 310 on the physical channel. The data and control signals are then provided to the one or more controllers / processors 359 of UE 350, which implement layer 3 and layer 2 functionality.

[0075] The one or more controllers / processors 359 may each be associated with one or more memories 360 that store program codes and data. The one or more memories 360, individually or in any combination, may be referred to as a computer-readable medium and may be any of the types of computer-readable mediums discussed herein (such as RAM, ROM, EEPROM, optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer) . The one or more controllers / processors 359 provide demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, and control signal processing to recover IP packets from the EPC 160. The one or more controllers / processors 359 are also responsible for error detection using an ACK or NACK protocol to support HARQ operations.

[0076] Similar to the functionality described in connection with transmission by the base station 310, the one or more controllers / processors 359 of UE 350 provide RRC layer functionality associated with system information (such as MIB, SIBs) acquisition, RRC connections, and measurement reporting; PDCP layer functionality associated with header compression  / decompression, and security (ciphering, deciphering, integrity protection, integrity verification) ; RLC layer functionality associated with the transfer of upper layer PDUs, error correction through ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0077] Channel estimates derived by a channel estimator 358 from a reference signal or feedback transmitted by the base station 310 may be used by the one or more TX processors 368 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the one or more TX processors 368 may be provided to different antenna 352 via separate transmitters 354TX. Each transmitter 354TX may modulate an RF carrier with a respective spatial stream for transmission.

[0078] The transmission is processed at the base station 310 in a manner similar to that described in connection with the receiver function at the UE 350. Each receiver 318RX receives a signal through its respective antenna 320. Each receiver 318RX recovers information modulated onto an RF carrier and provides the information to one or more RX processors 370.

[0079] The one or more controllers / processors 375 may each be associated with one or more memories 376 that store program codes and data. The one or more memories 376, individually or in any combination, may be referred to as a computer-readable medium and may be any of the types of computer-readable mediums discussed herein (such as RAM, ROM, EEPROM, optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer) . The one or more controllers / processors 375 provide demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover IP packets from the UE 350. IP packets from the one or more controllers / processors 375 may be provided to the EPC 160. The one or more  controllers / processors 375 are also responsible for error detection using an ACK or NACK protocol to support HARQ operations.

[0080] At least one of the one or more TX processors 368, the one or more RX processors 356, and the one or more controllers / processors 359, may be configured to perform aspects in connection with MDE component 198 of Figure 1.

[0081] Multi-Device Experience (MDE) refers to a design and interaction paradigm where users engage with digital services or applications across multiple devices, often simultaneously. These devices may be from a single original equipment manufacturer (OEM) or cross-OEM, involving devices from different manufacturers. An MDE network is a network in which connected devices share information to seamlessly work as an integrated system. More specifically, an MDE network refers to an interconnected system of multiple devices that support MDE. These networks may be complex, involving not only multiple types of UEs 104 such as smartphones, tablets, smart TVs, wearable devices, and the like, but also different operating systems, screen sizes, input methods, and more. Examples of MDE applications include content transfer between UEs, task continuation on different UEs, and real-time collaborative work on shared documents.

[0082] OEMs provide various UEs designed to communicate within an MDE network. These UEs 104 are registered under a same cloud system to interact. For example, UEs 104 may register with a cloud to communicate with other UEs in the MDE network. This cloud dependency on communication applies even to devices belonging to a same OEM, as the UEs 104 rely on the cloud to establish a trust relationship and synchronize secure contexts.

[0083] A secure context in wireless communications involves the use of cryptographic keys and the management of device lists to ensure that authorized and trusted devices can communicate securely. For instance, a secure context may be a framework that includes one or more cryptographic keys, such as user keys or trust keys, and one or more device lists, such as a user device list or a trust device list, which devices may use to communicate with one another securely. This framework may help to protect data integrity, confidentiality, and availability by preventing unauthorized access and ensuring that participating devices are authenticated and trusted.

[0084] A typical cloud registration process of an MDE network involves the UE 104 logging into the cloud, which then authenticates the UE 104 and synchronizes the secure context, including user keys and the list of registered devices. For example, UEs 104 may send a request to the cloud, which generates and synchronizes a secure context, including keys and a device list, to other  UEs in the MDE network. Similarly, in a trust cloud-based scenario involving MDE networks of multiple users, UEs 104 may send trust network requests to the cloud, which generates and assign trust keys and associates them with the devices. The cloud sends the trust keys and secure context to UEs 104 in multiple users' networks. This allows the UEs to recognize and interact with other devices in both single user and cross-user MDE networks.

[0085] Figure 4 illustrates an example of an MDE network 400 using a cloud 402 as a trust center. Such MDE networks 400 predominantly rely on a centralized cloud infrastructure to function as the trust center. This centralized approach involves several procedures to provide secure and seamless interaction among a user's devices. Initially, a user logs into their cloud account on UE 404, corresponding to UE 104. The cloud authenticates the user's account, registers the UE 404, and synchronizes a secure context 406 of the user. The secure context 406 includes elements such as user keys and a list of registered devices synchronized to the device. These user keys are cryptographic keys that are used to encrypt and decrypt data exchanged between the devices, ensuring that the communication remains secure. The device list contains information about the devices which allows them to recognize and interact with one another. This process allows for the UEs 404 to be recognized and trusted within the user's ecosystem. The cloud 402 synchronizes the secure context 406 in a broadcast to the respective devices of the MDE network 400.

[0086] For UEs 404 that lack internet capability, these devices typically are provisioned by another UE 404 that has internet access. For instance, a user may use UE 404, such as a smartphone, to provision another of UEs 404, such as a headset. This provisioning allows the headset to register with the cloud 402. Once the user's devices are registered and have obtained the same secure context 406 from the cloud, the UEs 404 may perform MDE functions securely. For example, the UEs 404 may perform seamless data transfer and task continuation across devices.

[0087] Figure 5 illustrates an example of a cross-user MDE network 500 using a cloud 502 as a trust center. Such cross-user MDE networks 500 also rely heavily on a centralized cloud infrastructure to establish and maintain trust relationships between devices such as UEs 504, which correspond to UEs 104 and belong to different users 506. The typical procedures for setting up cross-user MDE network 500 involve several steps to provide secure and seamless interaction between UEs 504 of different users 506, which are represented by users A and user B in Figure 5.

[0088] Initially, the UEs 504 of user A and user B initiate a trust relationship by sending a request to the cloud 502. This request is the first step in building a trust secure context 508 that the devices  may use to interact safely and effectively. Once the cloud 502 receives the trust relationship request, the cloud 502 associates user A and user B together. The cloud generates the trust secure context 508, which includes the same information as secure context 406 in Figure 4 in addition to trust relationship elements such as trust keys and a trust device list. These trust keys are cryptographic keys that are used to encrypt and decrypt data exchanged between devices of different users 506, ensuring that the communication remains secure. The trust device list contains information about the devices of different users 506 that are part of the trust relationship, allowing them to recognize and interact with one another. The cloud synchronizes this trust secure context 508 in a broadcast to the respective devices of user A and user B. After the trust secure context 508 has been synchronized, the UEs 504 of user A and user B may perform MDE use cases securely. For example, the UEs 504 may collaborate on work projects, share files, or engage in other activities while utilizing secure communication. The trust secure context 508 ensures that the data exchanged between the devices is protected and that access to the data is restricted to trusted devices.

[0089] While the cloud-centric approaches for MDE networks 400, 500 described with respect to Figures 4 and 5 provide for a seamless and secure multi-device experience across different devices of a same user or trusted devices of different users, these MDE networks 400, 500 have several significant problems. One of the primary issues is these networks’ heavy reliance on cloud 402, 502 as the central trust authority. If the cloud service goes offline or experiences disruptions, the MDE network or cross-user MDE network may be rendered inoperative or severely degraded. This dependency on a single point of failure poses a substantial risk to the reliability and availability of the MDE services.

[0090] Another problem is the proprietary nature of these clouds 402, 502, which creates walled gardens around different OEMs. UEs 404, 504 from different OEMs cannot interact with each other because each OEM's cloud is typically proprietary and incompatible with other OEM devices. This lack of interoperability limits a user's ability to create a cohesive multi-device ecosystem if they own devices from multiple manufacturers. For example, UEs 404, 504 belonging to different OEMs may not be able to establish a trust relationship and interact securely, limiting the use cases of single-user and cross-user MDE networks.

[0091] Another limitation of clouds 402, 502 is that they utilize internet connectivity to synchronize the secure context 406 or trust secure context 508 across devices. If a device such as UE 404, 504 does not have internet access, that device cannot receive the updated, secure context 406 or trust secure context 508 from the cloud. This may lead to inconsistencies and communication  failures within the MDE network 400, 500. For example, if the UE 404, 504 provisions or adds a new device such as a headset to the MDE network 400, 500 such as illustrated in Figure 4, the UE 404, 504 may update the cloud 402, 502 with the new, secure context 406 or trust secure context 508, but the headset will not receive this update from cloud 402, 502 since it lacks internet access. This results in the provisioned UE having an outdated secure context or outdated trust secure context, preventing UEs 404, 504 in the MDE network 400, 500 from communicating effectively with the provisioned device.

[0092] Additionally, building and maintaining a cloud infrastructure in MDE networks 400, 500 is costly. OEMs may invest significant resources into developing, deploying, and maintaining these cloud services, which may drive up costs for both the manufacturers and the end-users. Furthermore, the reliance on internet connectivity introduces issues related to internet delays and instability. Users 506 may experience degraded performance or interruptions in their MDE services due to network latency or connectivity issues, which can negatively impact the overall user experience.

[0093] Thus, current cloud-based systems for MDE networks 400, 500 face significant latency problems and the risk of the cloud 402, 502 going offline, which may disrupt the network. While these MDE networks 400, 500 rely on UEs 404, 504 to have network capability to obtain secure contexts 406, 508 and log in and store information in the cloud 402, 502, many devices do not support network connectivity which limits their ability to be part of the MDE network. Additionally, if the MDE network 400, 500 is unstable or unavailable, the communication between UEs 404, 504 may be disrupted, leading to a poor user experience. Furthermore, UEs from different OEMs cannot communicate with one another due to the proprietary nature of their respective cloud systems. Likewise, the clouds 402, 502 of different OEMs cannot access one another for device communication. This lack of interoperability or walled garden effect further limits the use cases of MDE. Additionally, broadcasting the secure context 406 or trust secure context 508 to the devices in multiple users’ networks may lead to security concerns if the secure context 406, 508 is sent to unintended devices in either network. Furthermore, even if the devices belong to the same OEM, they still may face limitations in terms of interoperability and communication.

[0094] To mitigate the aforementioned problems such as dependency on the cloud 402, 502, latency, and the inability to work across different OEMs, implementations move away from a centralized, cloud-based system towards a decentralized MDE network. A decentralized network refers to a network where control, decision-making, and data storage are distributed  across multiple devices rather than being concentrated in a single central authority or location. For instance, in a decentralized network, each UE 404, 504 may operate independently and can interact directly with other devices without the need for a central server or intermediary such as cloud 402, 502. Thus, in the context of an MDE network, a decentralized network is one in which respective UEs 104 store and manage their own secure contexts and may communicate directly with other devices, without the need for a central cloud server such as cloud 402, 502.

[0095] This decentralized approach not only addresses the aforementioned latency issues associated with MDE networks 400, 500 but also enhances the interoperability of devices from different OEMs, providing a more seamless and robust multi-device experience. More particularly, instead of using a cloud-based centralized server, the MDE network distributes the secure contexts 406, 508 and the registration process to the UEs 104. The devices may use near field wireless communication, such as  NFC, UWB, Wi-Fi  or other close-proximity technology, to communicate with other devices in the MDE network. This approach allows UEs 104 to initialize the network by sending requests to other UEs to join the network rather than cloud 402, 502, followed by acknowledgments. The UEs 104 may establish the secure context 406, 508 with their own cryptographic keys and store copies of these keys and device lists in their respective memories such as one or more memories 360. Once the MDE network is initialized, new devices may be provisioned or added in a similar manner. However, instead of sending a provisioning request to the cloud 402, 502, UEs 104 may communicate with the new device using  NFC, or other close-proximity technology. The updated secure context may be broadcast to the different UEs 104 in the network, and the UEs 104 may communicate in MDE securely.

[0096] This implementation may be extended to establish trust between UEs 104 from different users such as users 506. Initially, one UE from a respective user, such as UE 504, may initiate the trust network. This initiation is similarly done as in single user scenarios by using near field wireless technology to exchange trust keys and establish the trust secure context using an OOB confirmation. For example, referring to Figure 5, user A’s UE may display a password or PIN, which user B may enter in a user interface of user B’s UE to confirm the connection with user A’s UE. This confirmation generates a trust key used for secure communication between the devices. After the initial trust is established, user A's UE may send a list of user A's devices in its MDE network to user B's devices in its MDE network, and vice versa. This ensures that one user's devices are informed of the other user's devices. The UEs 104 may broadcast the updated secure context, including the list of trusted devices, to other devices within their respective  networks. This allows for UEs within the respective networks to have the latest secure context updates so that the devices may recognize and interact with UEs of other users securely. For example, once user A's UE and user B's UE have established a trust relationship with a trust secure context, user A's UE and user B's UE may communicate securely using the same trust key. This allows for seamless and secure communication across various devices within the network, regardless of the users’ internet connectivity.

[0097] Figure 6 illustrates an example of a decentralized MDE network 600. This implementation provides for the establishment of a distributed MDE network using near field wireless technology such as NFC, UWB, Wi-Fi or other close-proximity technology. This approach addresses the limitations of the current cloud-centric MDE networks such as MDE network 400 by eliminating the need for a centralized cloud infrastructure and enhancing the interoperability and security of the devices within the network. The typical procedures for setting up this distributed MDE network involve several steps to ensure secure and seamless interaction among a user's devices such as UEs 602, which correspond to UEs 104 or UEs 404.

[0098] The first step in this process is the initialization of the MDE network 600 by two devices or UEs 602 belonging to a user. These two devices negotiate and generate a secure context 604, which corresponds to secure context 406 and similarly includes elements such as user keys 606 and a list of user devices 608. This negotiation is conducted via near field wireless technology, providing for a direct and secure connection between the UEs 602. The user keys 606 may be cryptographic keys used to encrypt and decrypt data exchanged between the UEs 602, and the list of user devices 608 may contain information about the UEs 602 that are part of the MDE network 600. The secure context 604 in the distributed, MDE network 600 thus allows for the UEs 602 within the network to recognize and interact with one another securely.

[0099] UEs 602 may confirm the establishment of this secure context 604 through an OOB confirmation, such as entering and verifying a user input PIN or password. The OOB confirmation may be applied by using a different frequency band in near field communication than that applied for data communication. It may be employed for the UE 602 to communicate a password or PIN to another UE to confirm the setup of secure context 604. This additional layer of security allows for authorized devices but not unauthorized devices to join the MDE network 600. Once the secure context 604 is generated, the UEs 602 may store the secure context 604 on their respective devices, and the foundation of the distributed MDE network may thus be formed. By storing this secure context 604 locally on respective devices, the MDE  network 600 eliminates the need for the centralized cloud infrastructure of MDE network 400, reducing the risk of a single point of failure and enhancing the overall security and reliability of MDE communications.

[0100] UEs 602 may provision or add other one (s) of UEs 602 to the MDE network 600. For example, a user might add a headset 610 or other new device to the network using one of UEs 602. Either of the UEs 602, which already hold the secure context 604, may initiate the provisioning process by recognizing the new device and prompting the user to confirm that the headset 610 belongs to them again via an OOB confirmation. Once the user confirms ownership of the headset 610, the initiating UE may update the secure context 604 to include the new device. This updated, secure context 604 may be synchronized to the new device and broadcasted to other existing devices in the MDE network 600. This ensures that UEs 602 within the network including headset 610 have the same secure context, allowing the devices to recognize and interact with one another securely. Moreover, when the updated security context is broadcasted to the devices in the network, UEs 602 including headset 610 may receive the secure context 604 regardless of their internet connectivity. This broadcasting approach allows for UEs 602 to respectively have the same secure context, eliminating the inconsistencies and communication failures seen in cloud-based MDE networks such as MDE network 400.

[0101] Once the UEs 602 respectively have the same, secure context 604 stored locally in memory such as in one or more memories 360, the UEs 602 may perform various MDE use cases securely. For instance, users may copy and paste content across different ones of UEs 602 in MDE network 600, and users may start a task on one of UEs 602 and continue it on another UE 602 seamlessly in MDE network 600. The secure context 604 ensures that the data exchanged between the devices is protected, and that trusted, OOB-confirmed devices within the network but not untrusted devices may access it. This distributed approach not only enhances the security of the MDE network 600 but also improves its reliability and performance by eliminating current network dependency on a centralized cloud infrastructure.

[0102] Figure 7 illustrates an example of a cross-user, decentralized MDE network 700, which includes a trusted relationship between multiple MDE networks 600 respectively belonging to different users. The implementation similarly provides for an establishment of a distributed, trusted, cross-user MDE using near field wireless technology such as NFC, UWB, Wi-Fi  or other close-proximity technology. This approach addresses the limitations of current cloud-centric MDE networks such as MDE network 500 by eliminating the need for a centralized cloud infrastructure and enhancing the interoperability and security  of devices across different users. The typical procedures for setting up this distributed cross-user MDE network involve several steps to ensure secure and seamless interaction between UEs 702 or other devices, corresponding to UEs 104 or UEs 504, of different users 704, such as users 506 represented by user A and user B.

[0103] The first step in this process is the initialization of the MDE network 700 or trust network by two devices or UEs 702 belonging to different users 704. These two devices negotiate and exchange a trust secure context 706, which corresponds to secure context 508 and similarly includes elements such as trust keys 708 and a list of trusted devices 710 across multiple users, in addition to user keys 606 and user devices 608 of respective single users. This negotiation is conducted via near field wireless technology, providing for a direct and secure connection between the UEs 702. The trust keys 708 may be cryptographic keys used to encrypt and decrypt data exchanged between the UEs 702 across the multiple MDE networks 600, and the list of trusted devices 710 in one MDE network 600 may contain information about the UEs 702 that are part of the other MDE network 600. Similarly, trust secure context 706 may include user keys 606 to encrypt and decrypt data exchanged between the UEs 702 within one MDE network 600, and the list of user devices 608 containing information about the UEs 602 that are part of the same MDE network 600. The trust secure context 706 in the distributed, MDE network 700 thus allows for the UEs 702 within different MDE networks 600 to recognize and interact with one another securely.

[0104] Similar to the confirmation of secure context 604 in the MDE network 600 of Figure 6, UEs 702 across MDE networks 600 may confirm the establishment of the trust secure context 706 through an OOB confirmation, such as entering and verifying a user input PIN or password. This additional layer of security ensures allows for authorized devices to join the trusted, MDE network 700 but not unauthorized devices, forming the foundation of the distributed cross-user MDE network. Once the trust secure context 706 is established, the UEs 702 broadcast this context to their respective users' devices in their respective MDE networks 600. For example, user A's UE 702 may broadcast the trust secure context 706 to user A's other UEs, while user B's UE 702 may broadcast the trust secure context 706 to user B's other UEs. This broadcasting allows for the UEs 702 within the users’ networks to respectively have the same, trust secure context 706, allowing them to recognize and interact with one another securely. The broadcasting of the updated, trust secure context 706 to UEs 702 in the MDE network 700 also ensures that the devices may receive the latest updates regardless of their internet connectivity. This broadcasting thus provides for the UEs 702 to respectively have the same trust secure  context 706, eliminating the inconsistencies and communication failures typically seen in cloud-based MDE networks such as MDE network 500. The UEs 702 may store this trust secure context 706 locally in their respective device on top of the secure context 604 previously stored, eliminating the need for a centralized cloud infrastructure, reducing the risk of a single point of failure and enhancing the overall security and reliability of the MDE network 700.

[0105] With the trust secure context 706 in place, the UEs 702 from users 704 may perform various MDE use cases securely. For instance, the UEs 702 may perform collaborative work, where devices from multiple users 704 may share files, communicate, and collaborate on projects seamlessly. The trust secure context 706 allows for the data exchanged between the devices to remain protected, restricting the data to trusted devices within the network but not unauthorized devices. This distributed approach not only enhances the security of the cross-user MDE network 700 but also improves its reliability and performance by eliminating the dependency on a centralized cloud infrastructure.

[0106] Accordingly, the MDE networks 600, 700 significantly enhance the functionality, security, and efficiency of MDE networks 400, 500. One of the primary enhancements is the establishment of a decentralized, distributed local network. Unlike traditional cloud-centric networks that rely on a central server such as MDE networks 400, 500, this decentralized approach shown for example in Figures 6 and 7 allow for the network to continue to function effectively even if one or more UEs 602, 702 go offline. This resilience is achieved by storing the secure context 604 or trust secure context 706 locally on a respective device, allowing the UEs 602, 702 to recognize and interact with one another independently of cloud 402, 502 or other central authority. This decentralized nature of MDE network 600, 700 not only enhances the reliability of the network but also reduces the risk of a single point of failure, making the system more robust and dependable.

[0107] Another significant enhancement is the ability of MDE networks 600, 700 to break the OEM walled garden inherent in MDE networks 400, 500, allowing for interaction across UEs 602, 702 from different manufacturers. Traditional MDE networks such as MDE networks 400, 500 often face interoperability issues due to proprietary cloud systems such as cloud 402, 502 that restrict communication to devices from the same OEM. The MDE networks 600, 700 overcome this limitation by allowing for UEs to negotiate secure contexts 604, 706 via near field wireless technology and storing the secure contexts 604, 706 on the respective device. Thus, UEs 602, 702 from an OEM that supports near field communication or similar wireless technology may be integrated into the MDE network 600, 700. This cross-OEM interaction fosters a more  inclusive and flexible ecosystem than MDE network 400, 500, allowing users to seamlessly connect and interact with UEs 602, 702 without being confined to a single manufacturer's ecosystem.

[0108] MDE networks 600, 700 also offer the advantage of no additional cost compared to MDE networks 400, 500. By fully leveraging near field wireless capabilities of devices such as UEs 602, 702, the MDE networks 600, 700 eliminate the need for additional infrastructure or services. This cost-effectiveness is particularly beneficial for both manufacturers and end-users, as it reduces the financial barriers to implementing and maintaining a robust MDE network such as MDE network 600, 700. The use of existing hardware capabilities of UEs 602, 702 allows for the MDE networks 600, 700 to be deployed widely without incurring extra expenses, making it an attractive option for a broad range of applications.

[0109] In terms of performance, the MDE networks 600, 700 are both faster and more stable compared to traditional internet-based networks such as MDE networks 400, 500. Local near field wireless networks, such as those using  or other near field communication technology including the MDE networks 600, 700, offer larger bandwidth and faster transmission speeds than typical internet connections of MDE networks 400, 500. This high-speed communication is helpful for applications that utilize real-time data exchange and low latency, such as collaborative work and multimedia sharing and other MDE use cases. Additionally, local near field wireless networks such as MDE networks 600, 700 are less susceptible to the various factors that can affect internet communication quality, such as network congestion and server downtimes. The primary factor influencing the performance of near field wireless networks such as MDE networks 600, 700 is the physical distance between UEs 602, 702, which is typically minimal in MDE scenarios. This results in a more stable and reliable network than MDE network 400, 500, ensuring consistent performance even in environments with limited or unstable internet connectivity.

[0110] The decentralized, distributed local network model of MDE network 600, 700 also enhances security and privacy compared to MDE network 400, 500. By storing the secure context 604, 706 locally and using direct device-to-device communication, the MDE networks 600, 700 address the exposure of sensitive data to external networks. This localized approach reduces the risk of data breaches and unauthorized access, as the data does not need to traverse the internet or be stored on external servers. The use of cryptographic keys for encrypting and decrypting data further provides for authorized devices in the MDE network 600, 700 but not  unauthorized devices to access the information, maintaining the confidentiality and integrity of the communication.

[0111] Figure 8 illustrates an example call flow diagram 800 between a first UE 802 and a second UE 804 in a decentralized MDE network. The decentralized MDE network may be, for example, MDE network 600 of Figure 6. Here, first UE 802 and second UE 804 may respectively correspond to UEs 602, which UEs 802, 804 may be from different OEMs 806 or a same OEM 806. The illustrated example depicts the initialization of the MDE network by two devices negotiating and generating a secure context via near field wireless technology, allowing for a direct and secure connection between the UEs. This secure context includes user keys and a list of user devices, allowing the UEs within the network to recognize and interact with one another securely.

[0112] Initially, first UE 802 and second UE 804 may perform an OOB confirmation 807 using near field wireless technology 808 such as using NFC, UWB, Wi-Fi or other close-proximity technology. For example, this may involve one UE displaying a password or PIN, which the other UE enters to confirm the connection. This confirmation generates a key used for secure communication between the devices, ensuring that authorized devices can join the network. In response to the OOB confirmation 807, at blocks 810 respectively, UEs 802, 804 may obtain secure context 812, which corresponds to secure context 604 and includes keys 814 and device identifiers 816 associated with the UEs 802, 804. For example, the secure context may be obtained through a negotiation process using near field wireless communication, allowing the UEs 802, 804 to establish a secure and direct connection using synchronized cryptographic keys and device identifiers. Keys 814 here may correspond to user keys 606, and device identifiers 816 here may correspond to UE identifiers in the list of user devices 608. A cloud-less MDE network 818 including UEs 802, 804 may thus be formed, corresponding to MDE network 600. For example, this network may be established by directly connecting the UEs 802, 804 using near field wireless technology, eliminating the need for centralized cloud infrastructure. Afterwards, at blocks 820 respectively, the UEs 802, 804 may store the secure context 812 in one or more memories of the respective UE. For example, the UEs 802, 804 may store the secure context 812 locally, ensuring that the cryptographic keys and device identifiers are readily accessible for secure communication. Following obtaining and storing of secure context 812, UEs 802, 804 may communicate data 822 for MDE 824, including performing one or more of various MDE use cases. For example, UE 802, 804 may seamlessly transfer data, continue tasks across devices, or collaborate in real-time.

[0113] Subsequently, first UE 802 may provision or add an additional UE 826, such as headset 610 in Figure 6, to the cloud-less MDE network 818 using an OOB confirmation 827 from the additional UE 826. For example, the first UE 802 may recognize the additional UE 826 and prompt its user to confirm ownership via entry of a PIN in a user interface. Afterwards, first UE 802 may at block 828 update the secure context 812, including keys 814 and device identifiers 816 associated with UEs 802, 804, to further include keys 830 and device identifier (s) 832 associated with additional UE 826. For example, the first UE 802 may integrate the additional UE 826 into the cloud-less MDE network 818 by updating the secure context 812 with the additional UE’s cryptographic keys and identifiers. Then, first UE 802 may broadcast or multicast an updated secure context 834, which was updated at block 828, to additional UE 826 and second UE 804. Following this transmission, the UEs 802, 804, and additional UE 826 may respectively communicate data 822 among one another for MDE 824 again using near field wireless technology 808, including performing one or more of the aforementioned MDE use cases.

[0114] Figure 9 illustrates an example call flow diagram 900 between a first UE 902 and a second UE 904 in a cross-user, decentralized MDE network. The cross-user, decentralized MDE network may be, for example, MDE network 700 of Figure 7. Here, first UE 902 and second UE 904 may respectively correspond to UEs 702, which may be from different OEMs 906 or a same OEM 906. First UE 902 also may correspond to first UE 802 in Figure 8. The illustrated example depicts the initialization of a trust secure context between devices from different users using near field wireless technology. This process involves exchanging trust keys and establishing a secure connection, allowing devices from separate networks to recognize and interact with one another securely. The illustrated example also may occur in some implementations during or following the example call flow diagram 800 depicted in Figure 8, such as after cloud-less MDE network 818 is initially formed or after additional UE provisioning. Thus, first UE 902 may be part of a first cloud-less MDE network 908 with other UEs belonging to the same user, which cloud-less MDE network 908 corresponds to cloud-less MDE network 818 of Figure 8. Similarly, second UE 904 may be part of a second cloud-less MDE network 910 with other UEs belonging to a different user, which cloud-less MDE network 910 also may correspond to another instance of cloud-less MDE network 818 of Figure 8.

[0115] Initially, first UE 902 and second UE 904 may perform an OOB confirmation 912 using near field wireless technology 914 such as using NFC, UWB, Wi-Fi or other close-proximity technology. For example, this may involve one UE displaying a  password or PIN, which the other UE enters to confirm the connection. This process generates a trust key, establishing a secure communication channel between the devices and ensuring that authorized devices can join the network. In response to the OOB confirmation 912, at blocks 916 respectively, UEs 902, 904 may obtain trust secure context 918, which corresponds to trust secure context 706 and includes trust keys 920 and trust device identifiers 922 associated with the UEs 902, 904 in different cloud-less MDE networks 908, 910. For example, this process may involve negotiating a secure connection using near field wireless technology, allowing the UEs 902, 904 to exchange trust keys and identifiers. Trust secure context 918 also may include the keys 814 and device identifiers 816 of Figure 8, which may have been previously associated with the UE 902 in first cloud-less MDE network 908 and the UE 904 in second cloud-less MDE network 910, respectively. Trust keys 920 may correspond to user keys 708, and trust device identifiers 922 may correspond to identifiers in the list of trusted devices 710. A cloud-less MDE network 924 corresponding to MDE network 700 may thus be formed, including UEs 902, 904 of first cloud-less MDE network 908 and second cloud-less MDE network 910, respectively. For example, cloud-less MDE network 924 may be established by linking the UEs 902, 904 from the different networks 908, 910 through the trust secure context 918, allowing them to communicate directly using near field wireless technology. Afterwards, at blocks 926 respectively, the UEs 902, 904 may store the secure context trust secure context 918 locally in one or more memories of the respective UE.

[0116] Following obtaining and storing of trust secure context 918, UEs 902, 904 may broadcast or multicast the trust secure context 918 to other UEs in their respective, cloud-less MDE networks 908, 910. For instance, first UE 902 may broadcast trust secure context 918 to a third UE 928, corresponding to second UE 804 in Figure 8, and an additional UE 930, corresponding to additional UE 826 in Figure 8, in first cloud-less MDE network 908 using near field wireless technology 932. Near field wireless technology 932 may be a same close-proximity technology as or a similar close-proximity technology to that used in near field wireless technology 914. Similarly, second UE 904 may broadcast trust secure context 918 to a fourth UE 934 and another UE 936 in second cloud-less MDE network 910 using near field wireless technology 932. Following the sending of trust secure context 918, the UEs 902, 904, 928, 930, 934, 936 may respectively communicate data 938 among one another for MDE 940 again using near field wireless technology, including performing one or more of various MDE use cases. For example, the UEs may seamlessly transfer data, collaborate on projects, and continue tasks across different devices.

[0117] Figure 10 is a flowchart 1000 of an example method or process for wireless communication. The method may be performed by a first UE such as the UE 104, 350, 602, 702, 802, 902, or apparatus 1202 or its components as described herein. The first UE may be in communication with a second UE such as the UE 104, 350, 804, 904. The second UE also may be referred to as an apparatus or wireless communication device, and similarly, the first UE, the second UE, and other UEs may be referred to as apparatuses or wireless communication devices. The method allows for establishing a secure, cloud-less MDE network by obtaining and managing secure contexts through near field wireless technology such as NFC, UWB, Wi-Fi  or other close-proximity technology, allowing for seamless and secure interaction across devices irrespective of OEM.

[0118] At block 1002, the first UE obtains a secure context including one or more keys associated with the first UE and the second UE for wireless communication, the secure context being obtained in a cloud-less network for MDE. For example, block 1002 may be performed by secure context component 1240. For instance, the controller (s)  / processor (s) 359, the RX processor (s) 356, or a combination of these processor (s) of UE 802, 902 may decode, demodulate, and receive via antennas 352, from second UE 804, 904, or generate from decoded, demodulated, and received information such as keys 814, 920 and device identifiers 816, 922, secure context 812 or trust secure context 918. For example, the obtaining may involve establishing a secure connection using near field wireless technology, in which the UEs 802, 804 or UEs 902, 904 exchange information such as cryptographic keys and UE device identifiers, and either receiving the secure context from the other UE or generating the secure context from the exchanged information. The keys 814, 920 are associated with the first UE 802, 902 and second UE 804, 904 for wireless communication. For example, these keys may be exchanged between these UEs during the secure context negotiation process using near field wireless technology, allowing for encrypted communication between the devices. The secure context 812 or trust secure context 918 are obtained in cloud-less network 818, 924 for MDE 824, 940.

[0119] At block 1004, the first UE communicates, in association with the obtained secure context at block 1002, with the second UE. For example, block 1004 may be performed by communication component 1242. For instance, the controller (s)  / processor (s) 359, the RX processor (s) 356, or a combination of these processor (s) of first UE 802, 902 may decode, demodulate, and receive via antennas 352, from second UE 804, 904, or the controller (s)  / processor (s) 359, the TX processor (s) 368, or a combination of these processor (s) of first UE 802, 902 may encode, modulate, and transmit via antennas 352, to second UE 804,  904, data 822, 938 for MDE 824, 940. The communication between first UE 802, 902 and second UE 804, 904 are in association with the obtained secure context 812, 918. For example, the UEs may utilize the secure context to encrypt and decrypt data exchanged between the devices, ensuring that communications are secure and protected.

[0120] Figure 11 is a flowchart 1100 of an example method or process for wireless communication. The method may be performed by a first UE such as the UE 104, 350, 602, 702, 802, 902, or apparatus 1202 or its components as described herein. The first UE may be in communication with a second UE such as the UE 104, 350, 804, 904. The second UE also may be referred to as an apparatus or wireless communication device, and similarly, the first UE, the second UE, and other UEs may be referred to as apparatuses or wireless communication devices. Optional aspects are illustrated in dashed lines. The method, similar to that of Figure 10, allows for establishing a secure, cloud-less MDE network by obtaining and managing secure contexts through near field wireless technology such as NFC, UWB, Wi-Fi or other close-proximity technology.

[0121] At block 1102, the first UE may obtain a secure context including one or more keys associated with the first UE and the second UE for wireless communication, the secure context being obtained in a cloud-less network for MDE.

[0122] In some implementations, the secure context is obtained in response to an OOB confirmation of the second UE to the cloud-less network using near field wireless communication. For instance, the first UE 802, 902 may obtain secure context 812 or trust secure context 918 at block 1002, 1102 in response to OOB confirmation 807, 912 from second UE 804, 904 to cloud-less MDE network 818, 924 using near field wireless technology 808, 914.

[0123] In some implementations, the first UE and the second UE are associated with different OEMs or a same OEM. For instance, the first UE 802, 902 and the second UE 804, 904 may be associated with different OEMs 806, 906 or a same OEM 806, 906.

[0124] At block 1104, the first UE may store the secure context in the one or more memories of the first UE, where one or more memories of the second UE further include the secure context. For instance, the controller (s)  / processor (s) 359 of first UE 802, 902 may store, at block 820 or 926, secure context 812 or trust secure context 918 in one or more memories 360 of the first UE 802, 902. Similarly, one or more memories 360 of the second UE 804, 904 may include secure context 812 or trust secure context 918.

[0125] At block 1106, the first UE may obtain an OOB confirmation of an additional apparatus for wireless communication to the cloud-less network. For instance, the controller (s)  / processor (s)  359 of first UE 802, 902 may obtain OOB confirmation 827 from additional UE 826, 930, in response to which OOB confirmation 827 the additional UE 826, 930 is added to cloud-less MDE network 818, 908, 924.

[0126] At block 1108, the first UE may update the secure context with a key of the additional UE in response to the OOB confirmation at block 1106. For instance, the controller (s)  / processor (s) 359 of first UE 802, 902 may, at block 828, update secure context 812 or trust secure context 918 with keys 830 of additional UE 826, 930 in response to OOB confirmation 827, thereby creating updated secure context 834.

[0127] At block 1110, the first UE may send the updated secure context at block 1108 to the additional UE. For instance, the controller (s)  / processor (s) 359 of first UE 802, 902 may send updated secure context 834 to additional UE 826, 930.

[0128] At block 1112, in some implementations of block 1110, the first UE may send the updated secure context in a broadcast to the second UE and the additional apparatus using near field wireless communication. For instance, the controller (s)  / processor (s) 359 of first UE 802, 902 may broadcast updated secure context 834 to second UE 804, also represented by third UE 928, and additional UE 826, 930 using near field wireless technology 808, 932.

[0129] In some implementations, the secure context obtained at block 1102 is a trust secure context, the cloud-less network includes a first network and a second network respectively for the MDE, the first UE is in the first network, and the second UE is in the second network. For instance, the first UE 802, 902 may obtain trust secure context 918 at block 1002, 1102 in cloud-less network 924 for MDE 940. The cloud-less network 924 may include first cloud-less MDE network 908 and second cloud-less MDE network 910 respectively for MDE 940, where first UE 802, 902 is in the first cloud-less MDE network 908 or cloud-less MDE network 818 and the second UE is in the second cloud-less MDE network 910 or a separate instance of cloud-less MDE network 818. The trust secure context associates the first network and the second network. For instance, referring to the Figures, the trust secure context 918 may associate first cloud-less MDE network 908 and second cloud-less MDE network 910.

[0130] At block 1114, the first UE may send the trust secure context in a first broadcast to a third apparatus for wireless communication in the first network using near field wireless communication. For instance, the controller (s)  / processor (s) 359 of first UE 802, 902 may broadcast trust secure context 918 to third UE 928 and additional UE 930 in first cloud-less MDE network 908 using near field wireless technology 932. The trust secure context may further be in a second broadcast from the second UE to a fourth apparatus in the second network  using the near field wireless technology. For instance, referring to the Figures, trust secure context 918 of second UE 904 may be similarly broadcast to fourth UE 934 and UE 936 in second cloud-less MDE network 910 using near field wireless technology 932. The third apparatus in the first network may be associated with the fourth apparatus in the second network. For instance, referring to the Figures, trust secure context 918 may associate third UE 928 in first cloud-less MDE network 908 and fourth UE 934 in second cloud-less MDE network 910.

[0131] In some implementations, the trust secure context further includes a device identifier respectively for the first UE, the second UE, the third apparatus, and the fourth apparatus. For instance, trust secure context 918 may include trust device identifiers 922 along with trust keys 920 for the first UE 902, second UE 904, third UE 928, and fourth UE 934, in addition to device identifiers 832 and keys 830 for respective UEs in their networks.

[0132] Finally, at block 1116, the first UE may communicate, in association with the obtained secure context at block 1102, with the second UE.

[0133] Figure 12 is a diagram 1200 illustrating an example of a hardware implementation for an apparatus 1202 for wireless communication. In one example, the apparatus 1202 may be a UE such as UE 104, 350, 602, 702, 802, 902 and includes one or more cellular baseband processors 1204 (also referred to as a modem) coupled to a cellular RF transceiver 1222 and one or more subscriber identity modules (SIM) cards 1220, an application processor 1206 coupled to a secure digital (SD) card 1208 and a screen 1210, a near-field wireless module 1212, a wireless local area network (WLAN) module 1214, a Global Positioning System (GPS) module 1216, and a power supply 1218. The one or more cellular baseband processors 1204 communicate through the cellular RF transceiver 1222 with the BS 102 or another UE 104, such as UE 804, 904. For example, the cellular RF transceiver 1222 may correspond to or include the transmitters 354TX, receivers 354RX, and antennas 352 of UE 350.

[0134] The one or more cellular baseband processors 1204 may each include a computer-readable medium  / one or more memories. The computer-readable medium  / one or more memories may be non-transitory. The one or more cellular baseband processors 1204 are responsible for general processing, including the execution of software stored on the computer-readable medium  / one or more memories individually or in combination. The software, when executed by the one or more cellular baseband processors 1204, causes the one or more cellular baseband processors 1204 to, individually or in combination, perform the various functions described supra. The computer-readable medium  / one or more memories also may be used individually  or in combination for storing data that is manipulated by the one or more cellular baseband processors 1204 when executing software. The one or more cellular baseband processors 1204 individually or in combination further include a reception component 1230, a communication manager 1232, and a transmission component 1234. The communication manager 1232 includes the one or more illustrated components. The components within the communication manager 1232 may be stored in the computer-readable medium  / one or more memories or configured as hardware within the one or more cellular baseband processors 1204. The one or more cellular baseband processors 1204 may be components of the UE 104, 350, 602, 702, 802, 902, and may individually or in combination include the one or more memories 360 or at least one of the one or more TX processors 368, at least one of the one or more RX processors 356 and at least one of the one or more controllers / processors 359. For example, the computer-readable medium  / one or more memories may correspond to or include the one or more memories 360, the reception component 1230 may correspond to or include the one or more RX processors 356, the communication manager 1232 may correspond to or include the one or more controllers / processors 359, and the transmission component 1234 may correspond to or include the one or more TX processors 368. In one configuration, the apparatus 1202 may be a modem chip and include just the one or more baseband processors 1204, and in another configuration, the apparatus 1202 may be the entire UE (such as UE 350 of Figure 3) and include the aforediscussed additional modules of the apparatus 1202.

[0135] The communication manager 1232 may include a secure context component 1240 that is configured to obtain a secure context including one or more keys associated with the apparatus 1202 and a second apparatus for wireless communication, the secure context being obtained in a cloud-less network for MDE, such as described in connection with block 1002, 1102 of Figures 10 and 11. The communication manager 1232 may further include a communication component 1242 that is configured to communicate, in association with the obtained secure context, with the second apparatus, such as described in connection with blocks 1002, 1116 of Figures 10 and 11.

[0136] The apparatus may include additional components that perform each of the blocks of the algorithm in the aforementioned flowcharts of Figures 10 and 11. As such, each block in the aforementioned flowcharts of Figures 10 and 11 may be performed by a component and the apparatus may include one or more of those components. The components may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors individually or in combination configured to perform  the stated processes / algorithm, stored within a computer-readable medium for implementation by one or more processors, or some combination thereof.

[0137] In one configuration, the apparatus 1202, and in particular the one or more cellular baseband processors 1204, includes means for obtaining a secure context including one or more keys associated with a first wireless communication device and a second wireless communication device, the secure context being obtained in a cloud-less network for a MDE, and means for communicating, in association with the obtained secure context, with a second wireless communication device.

[0138] The aforementioned means may be one or more of the aforementioned components of the apparatus 1202 configured to perform the functions recited by the aforementioned means. Moreover, as described supra, the apparatus 1202 may include the one or more TX processors 368, the one or more RX processors 356, and the one or more controllers / processors 359. As such, in one configuration, the aforementioned means may be at least one of the one or more TX processors 368, at least one of the one or more RX processors 356, or at least one of the one or more controllers / processors 359, individually or in any combination configured to perform the functions recited by the aforementioned means.

[0139] It is understood that the specific order or hierarchy of blocks in the processes  / flowcharts disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes  / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0140] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein but is to be accorded the full scope consistent with the language claims, where reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” Terms such as “if, ” “when, ” and “while” should be interpreted to mean “under the condition that” rather than imply an immediate temporal relationship or reaction. That is, these phrases, such as “when, ” do not imply an immediate action in response to or during the occurrence of an action, but simply imply that if a condition is met then an action will occur, but without requiring a specific or immediate time constraint for the action to  occur. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”

[0141] As used herein, a processor, at least one processor, or one or more processors, individually or in combination, configured to perform or operable for performing a plurality of actions (such as the functions described supra) is meant to include at least two different processors able to perform different, overlapping or non-overlapping subsets of the plurality actions, or a single processor able to perform all of the plurality of actions. In one non-limiting example of multiple processors being able to perform different ones of the plurality of actions in combination, a description of a processor, at least one processor, or one or more processors configured or operable to perform actions X, Y, and Z may include at least a first processor configured or operable to perform a first subset of X, Y, and Z (such as to perform X) and at least a second processor configured or operable to perform a second subset of X, Y, and Z (such as to perform Y and Z) . Alternatively, a first processor, a second processor, and a third processor may be respectively configured or operable to perform a respective one of actions X, Y, and Z. It should be understood that any combination of one or more processors each may be configured or operable to perform any one or any combination of a plurality of actions.

[0142] Similarly as used herein, a memory, at least one memory, a computer-readable medium, or one or more memories, individually or in combination, configured to store or having stored thereon instructions executable by one or more processors for performing a plurality of actions (such as the functions described supra) is meant to include at least two different memories able to store different, overlapping or non-overlapping subsets of the instructions for performing different, overlapping or non-overlapping subsets of the plurality actions, or a single memory able to store the instructions for performing all of the plurality of actions. In one non-limiting example of one or more memories, individually or in combination, being able to store different subsets of the instructions for performing different ones of the plurality of actions, a description of a memory, at least one memory, a computer-readable medium, or one or more memories configured or operable to store or having stored thereon instructions for performing actions X, Y, and Z may include at least a first memory configured or operable to store or having stored thereon a first subset of instructions for performing a first subset of X, Y, and Z (such as instructions to perform X) and at least a second memory configured or operable to store or having stored thereon a second subset of instructions for performing a second subset of X, Y, and Z (such as instructions to perform Y and Z) . Alternatively, a first memory, a second memory, and a third memory may be respectively configured to store or have stored thereon a respective one of a first subset of instructions for performing X, a second subset of instruction for performing Y, and a third subset of instructions for performing Z. It should be understood that any combination of one or more memories each may be configured or operable to store or have stored thereon any one or any combination of instructions executable by one or more processors to perform any one or any combination of a plurality of actions. Moreover, one or more processors may each be coupled to at least one of the one or more memories and configured or operable to execute the instructions to perform the plurality of actions. For instance, in the above non-limiting example of the different subset of instructions for performing actions X, Y, and Z, a first processor may be coupled to a first memory storing instructions for performing action X, and at least a second processor may be coupled to at least a second memory storing instructions for performing actions Y and Z, and the first processor and the second processor may, in combination, execute the respective subset of instructions to accomplish performing actions X, Y, and Z. Alternatively, three processors may access one of three different memories each storing one of instructions for performing X, Y, or Z, and the three processors may in combination execute the respective subset of instruction to accomplish performing actions X, Y, and Z. Alternatively, a single processor may execute the instructions  stored on a single memory, or distributed across multiple memories, to accomplish performing actions X, Y, and Z.

[0143] The following examples are illustrative only and may be combined with aspects of other implementations or teachings described herein, without limitation.

[0144] Clause 1. A first apparatus for wireless communication, including: one or more memories; and one or more processors each communicatively coupled with at least one of the one or more memories, the one or more processors, individually or in any combination, operable to cause the first apparatus to: obtain a secure context including one or more keys associated with the first apparatus and a second apparatus for wireless communication, the secure context being obtained in a cloud-less network for a MDE; and communicate, in association with the obtained secure context, with the second apparatus.

[0145] Clause 2. The first apparatus of clause 1, where the secure context is obtained in response to an OOB confirmation of the second apparatus to the cloud-less network using near field wireless communication.

[0146] Clause 3. The first apparatus of clause 1 or clause 2, where the first apparatus and the second apparatus are associated with different OEMs or a same OEM.

[0147] Clause 4. The first apparatus of any of clauses 1 to 3, where the one or more processors, individually or in any combination, are further operable to cause the first apparatus to: store the secure context in the one or more memories of the first apparatus, where one or more memories of the second apparatus further include the secure context.

[0148] Clause 5. The first apparatus of any of clauses 1 to 4, where the one or more processors, individually or in any combination, are further operable to cause the first apparatus to: obtain an OOB confirmation of an additional apparatus for wireless communication to the cloud-less network; and update the secure context with a key of the additional apparatus in response to the OOB confirmation.

[0149] Clause 6. The first apparatus of clause 5, where the one or more processors, individually or in any combination, are further operable to cause the first apparatus to: send the updated secure context to the additional apparatus.

[0150] Clause 7. The first apparatus of clause 5 or clause 6, where the one or more processors, individually or in any combination, are further operable to cause the first apparatus to: send the updated secure context in a broadcast to the second apparatus and the additional apparatus using near field wireless communication.

[0151] Clause 8. The first apparatus of any of clauses 1 to 7, where the secure context is a trust secure context, the cloud-less network includes a first network and a second network respectively for the MDE, the first apparatus is in the first network, and the second apparatus is in the second network, the trust secure context associating the first network and the second network.

[0152] Clause 9. The first apparatus of clause 8, where the one or more processors, individually or in any combination, are further operable to cause the first apparatus to: send the trust secure context in a first broadcast to a third apparatus for wireless communication in the first network using near field wireless communication, the trust secure context being further in a second broadcast from the second apparatus to a fourth apparatus in the second network using the near field wireless communication, and the third apparatus in the first network being associated with the fourth apparatus in the second network.

[0153] Clause 10. A method of wireless communication performable at a first wireless communication device, including: obtaining a secure context including one or more keys associated with the first wireless communication device and a second wireless communication device, the secure context being obtained in a cloud-less network for a MDE; and communicating, in association with the obtained secure context, with the second wireless communication device.

[0154] Clause 11. The method of clause 10, where the secure context is obtained in response to an OOB confirmation of the second wireless communication device to the cloud-less network using near field wireless communication.

[0155] Clause 12. The method of clause 10 or clause 11, where the first wireless communication device and the second wireless communication device are associated with different OEMs.

[0156] Clause 13. The method of clause 10 or clause 11, where the first wireless communication device and the second wireless communication device are associated with a same OEM.

[0157] Clause 14. The method of any of clauses 10 to 13, further including: storing the secure context in one or more memories of the first wireless communication device, where one or more memories of the second wireless communication device further include the secure context.

[0158] Clause 15. The method of any of clauses 10 to 14, further including: obtaining an OOB confirmation of an additional wireless communication device to the cloud-less network; and updating the secure context with a key of the additional wireless communication device in response to the OOB confirmation.

[0159] Clause 16. The method of clause 15, further including: sending the updated secure context to the additional wireless communication device.

[0160] Clause 17. The method of clause 15 or clause 16, further including: sending the updated secure context in a broadcast to the second wireless communication device and the additional wireless communication device using near field wireless communication.

[0161] Clause 18. The method of any of clauses 10 to 17, where the secure context is a trust secure context, the cloud-less network includes a first network and a second network respectively for the MDE, the first wireless communication device is in the first network, and the second wireless communication device is in the second network, the trust secure context associating the first network and the second network.

[0162] Clause 19. The method of clause 18, further including: sending the trust secure context in a first broadcast to a third wireless communication device in the first network using near field wireless communication, the trust secure context being further in a second broadcast from the second wireless communication device to a fourth wireless communication device in the second network using the near field wireless communication, and the third wireless communication device in the first network being associated with the fourth wireless communication device in the second network.

[0163] Clause 20. The method of clause 19, where the trust secure context further includes a device identifier respectively for the first wireless communication device, the second wireless communication device, the third wireless communication device, and the fourth wireless communication device.

Claims

1.A first apparatus for wireless communication, comprising:one or more memories; andone or more processors each communicatively coupled with at least one of the one or more memories, the one or more processors, individually or in any combination, operable to cause the first apparatus to:obtain a secure context including one or more keys associated with the first apparatus and a second apparatus for wireless communication, the secure context being obtained in a cloud-less network for a multi-device experience (MDE) ; andcommunicate, in association with the obtained secure context, with the second apparatus.2.The first apparatus of claim 1, wherein the secure context is obtained in response to an out-of-band (OOB) confirmation of the second apparatus to the cloud-less network using near field wireless communication.3.The first apparatus of claim 1, wherein the first apparatus and the second apparatus are associated with different original equipment manufacturers (OEMs) or a same OEM.4.The first apparatus of claim 1, wherein the one or more processors, individually or in any combination, are further operable to cause the first apparatus to:store the secure context in the one or more memories of the first apparatus, wherein one or more memories of the second apparatus further include the secure context.5.The first apparatus of claim 1, wherein the one or more processors, individually or in any combination, are further operable to cause the first apparatus to:obtain an out-of-band (OOB) confirmation of an additional apparatus for wireless communication to the cloud-less network; andupdate the secure context with a key of the additional apparatus in response to the OOB confirmation.6.The first apparatus of claim 5, wherein the one or more processors, individually or in any combination, are further operable to cause the first apparatus to:send the updated secure context to the additional apparatus.7.The first apparatus of claim 5, wherein the one or more processors, individually or in any combination, are further operable to cause the first apparatus to:send the updated secure context in a broadcast to the second apparatus and the additional apparatus using near field wireless communication.8.The first apparatus of claim 1, wherein the secure context is a trust secure context, the cloud-less network includes a first network and a second network respectively for the MDE, the first apparatus is in the first network, and the second apparatus is in the second network, the trust secure context associating the first network and the second network.9.The first apparatus of claim 8, wherein the one or more processors, individually or in any combination, are further operable to cause the first apparatus to:send the trust secure context in a first broadcast to a third apparatus for wireless communication in the first network using near field wireless communication, the trust secure context being further in a second broadcast from the second apparatus to a fourth apparatus in the second network using the near field wireless communication, and the third apparatus in the first network being associated with the fourth apparatus in the second network.10.A method of wireless communication performable at a first wireless communication device, comprising:obtaining a secure context including one or more keys associated with the first wireless communication device and a second wireless communication device, the secure context being obtained in a cloud-less network for a multi-device experience (MDE) ; andcommunicating, in association with the obtained secure context, with the second wireless communication device.11.The method of claim 10, wherein the secure context is obtained in response to an out-of-band (OOB) confirmation of the second wireless communication device to the cloud-less network using near field wireless communication.12.The method of claim 10, wherein the first wireless communication device and the second wireless communication device are associated with different original equipment manufacturers (OEMs) .13.The method of claim 10, wherein the first wireless communication device and the second wireless communication device are associated with a same original equipment manufacturer (OEM) .14.The method of claim 10, further comprising:storing the secure context in one or more memories of the first wireless communication device, wherein one or more memories of the second wireless communication device further include the secure context.15.The method of claim 10, further comprising:obtaining an out-of-band (OOB) confirmation of an additional wireless communication device to the cloud-less network; andupdating the secure context with a key of the additional wireless communication device in response to the OOB confirmation.16.The method of claim 15, further comprising:sending the updated secure context to the additional wireless communication device.17.The method of claim 15, further comprising:sending the updated secure context in a broadcast to the second wireless communication device and the additional wireless communication device using near field wireless communication.18.The method of claim 10, wherein the secure context is a trust secure context, the cloud-less network includes a first network and a second network respectively for the MDE, the first wireless communication device is in the first network, and the second wireless communication device is in the second network, the trust secure context associating the first network and the second network.19.The method of claim 18, further comprising:sending the trust secure context in a first broadcast to a third wireless communication device in the first network using near field wireless communication, the trust secure context being further in a second broadcast from the second wireless communication device to a fourth wireless communication device in the second network using the near field wireless communication, and the third wireless communication device in the first network being associated with the fourth wireless communication device in the second network.20.The method of claim 19, wherein the trust secure context further includes a device identifier respectively for the first wireless communication device, the second wireless communication device, the third wireless communication device, and the fourth wireless communication device.

Images