Techniques for device clustering and node transfer in pervasive computing
By introducing DCMF and DCA to manage computing resources, the problems of low efficiency in computing resource allocation and insufficient privacy protection in wireless networks are solved, achieving efficient offloading of computing tasks and resource discovery, and enhancing user privacy protection.
Patent Information
- Application Number
- CN202511132860.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-07-31
- Filing Date
- 2025-08-13
- Publication Date
- 2026-03-03
AI Technical Summary
Existing wireless networks suffer from inefficiencies in computing resource allocation and management, as well as insufficient protection of user privacy, especially in distributed computing environments where there is a lack of effective mechanisms for task offloading and resource discovery.
It employs Distributed Computing Management Function (DCMF) and Distributed Computing Agent (DCA) to manage and coordinate the allocation of computing resources, offloads tasks through clustered computing nodes, and utilizes network functions such as DCMF, NCRF, and DCA to discover computing resources and protect user privacy.
It improves the efficiency of computing resource allocation, enhances user privacy protection, and enables efficient offloading of computing tasks and resource discovery in wireless networks.
Smart Images

Figure CN121604036A_ABST
Abstract
Description
[0001] Related patent applications
[0002] This application claims priority to U.S. Provisional Application 63 / 685,218, filed August 20, 2024, which is incorporated herein by reference in its entirety. Technical Field
[0003] This application relates generally to communication networks, and more specifically to techniques for ubiquitous computing in wireless networks. Background Technology
[0004] The 3GPP (3rd Generation Partnership Project) Technical Specifications (TS) define the standards for wireless networks. These TS describe various aspects involving the signaling of services through systems containing wireless networks. Attached Figure Description
[0005] Figure 1 Examples of network environments based on some implementation schemes are provided.
[0006] Figure 2 An architectural approach based on some implementation schemes is illustrated.
[0007] Figure 3 Another network environment based on some implementation schemes is illustrated.
[0008] Figure 4 Another network environment based on some implementation schemes is illustrated.
[0009] Figure 5 Another network environment based on some implementation schemes is illustrated.
[0010] Figure 6 Another network environment based on some implementation schemes is illustrated.
[0011] Figure 7 Another network environment based on some implementation schemes is illustrated.
[0012] Figure 8 Another network environment based on some implementation schemes is illustrated.
[0013] Figure 9 The operational flow / algorithm structure according to some implementation schemes is illustrated.
[0014] Figure 10 Another operational flow / algorithm structure based on some implementation schemes is illustrated.
[0015] Figure 11 Another operational flow / algorithm structure based on some implementation schemes is illustrated.
[0016] Figure 12Examples of devices based on some implementation schemes are shown.
[0017] Figure 13 Examples of network devices based on some implementation schemes are shown. Detailed Implementation
[0018] The following detailed description refers to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as particular structures, architectures, interfaces, and techniques, are set forth for illustrative and non-limiting purposes to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to those skilled in the art that various aspects of the various embodiments may be practiced in other examples departing from these specific details. In some instances, descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrases “A / B” and “A or B” refer to (A), (B), or (A and B); and the phrase “based on A” means “at least partially based on A,” for example, it can be “based solely on A” or it can be “partially based on A.”
[0019] The following is a glossary of terms that may be used in this disclosure.
[0020] As used herein, the term "circuit" refers to, is part of, or includes a hardware component configured to provide the described functionality. Hardware components may include electronic circuitry, logic circuitry, processors (shared, dedicated, or grouped) or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable system-on-a-chip (SoCs)), or digital signal processors (DSPs). In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements (or combinations of circuits used in electrical or electronic systems) and program code for executing the functionality. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.
[0021] As used herein, the term "processor circuit" means, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may also refer to an application processor, baseband processor, central processing unit (CPU), graphics processing unit, single-core processor, dual-core processor, triple-core processor, quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional procedures).
[0022] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as buses, I / O interfaces, peripheral component interfaces, and network interface cards.
[0023] As used herein, the term "user equipment" or "UE" refers to equipment having radio communication capabilities that allow a user to access network resources within a communication network. The term "user equipment" or "UE" may be considered synonymous with and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. Furthermore, the term "user equipment" or "UE" can include any type of wireless / wired equipment or any computing device that includes a wireless communication interface.
[0024] As used herein, the term "computer system" means any type of interconnected electronic device, computer device, or component thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or network resources.
[0025] As used herein, the term "resource" means a physical or virtual device, a physical or virtual component or asset within a computing or network environment, or a physical or virtual component within a device or component that is accessible to or usable by the device or component. Resources may include, but are not limited to, memory space / usage, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, port or network sockets, channel / link allocation, throughput, or workload units. "Hardware resource" may refer to computing, storage, or network resources provided by physical hardware components. "Virtualization resource" may refer to computing, storage, or network resources provided by virtualization infrastructure to an application, device, or system. The term "communication resource" may refer to resources accessible to or usable by a computer device / system for transmitting information through channels of a communication network. For example, communication resources may include, but are not limited to, time / frequency resources, code resources, demodulation resources, etc. The term "system resource" may refer to any kind of shared entity used to provide services and may include computing or network resources. System resources can be viewed as a coherent set of functions, network data objects, or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.
[0026] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a means or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection between two devices used for transmitting and receiving information.
[0027] As used in this article, the terms "instantiate" and "instantiate" refer to the creation of an instance. "Instance" also refers to the concrete occurrence of an object, which may occur, for example, during the execution of program code.
[0028] The term "connection" can refer to an established signaling relationship between two or more elements at a common communication protocol layer through a communication channel, link, interface, or reference point.
[0029] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as a networked computer, network hardware, network equipment, network node, or virtualized network function.
[0030] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of an information element, or the data element that contains that content. An information element may include one or more additional information elements.
[0031] Figure 1 A network environment 100 according to some implementation schemes is illustrated. Network environment 100 may include user equipment (UE) 102, relay node 104, and desktop computer 106 communicatively coupled to a base station 108 of a radio access network (RAN). UE 102, relay node 104, and desktop computer 106 can communicate with base station 108 via an air interface compatible with 3GPP TS (such as those defining sixth-generation (6G) systems or higher).
[0032] The network environment 100 may also include a core network coupled to the base station 108 via fiber optic or wireless backhaul. The core network can provide various network functions for the devices in the network environment.
[0033] Network environment 100 can represent a centralized approach to the 3GPP core network with an integrated compute and network fabric that provides distributed intelligence that collects and analyzes information about communication and computing resources in a mobile wireless network, discovers the optimal resources / paths (e.g., communication paths to computing resources) to offload computing tasks, while protecting user privacy and assisting in the offloading process.
[0034] The new network capabilities may include Distributed Computing Management Function (DCMF) 110, Distributed Computing Agent (DCA) 112, and Networked Computing Repository Function (NCRF) 116.
[0035] DCMF 110 can be a network function responsible for onboarding, supplying computing resources to network nodes, and fulfilling their computing needs. DCMF 110 can also discover optimal computing resources and communication paths within the framework of trust and privacy requirements from application providers and users. DCMF 110 can interact with Application Function (AF) 118 (directly or through the Network Open Framework), Session Management Function (SMF) 120, and DCA 112. In this context, UE 102 can also be considered a network node.
[0036] DCA 112 is an entity embedded in a network node that provides / requests computing resources. DCA 112 has server-side and client-side instantiations. DCA 112 is responsible for communication with DCMF 110.
[0037] NCRF 116 can provide some storage library functions similar to the 5G Network Storage Library Function (NRF). NCRF 116 can also be responsible for registering network nodes with computing resources (which are also third parties) and assisting in the network node registration and discovery process.
[0038] Figure 2 An architectural approach 200 based on some implementation schemes is illustrated.
[0039] The first approach can be a device-centric approach, which can be an extension or reuse of Proximity Service (ProSe) discovery / D2D communication. Autonomous subnetworks can use local controllers acting as base stations + devices or cluster heads. Therefore, a local network can be maintained without a core network (CN). The computing aspect can be considered the "application layer." Local devices can support local versions of application-enabled / 3GPP network layer functions.
[0040] The second approach could be an application enablement layer, which can be network-independent. For example, the solution could be deployed separately from the carrier network. Companies can deploy relevant servers / functions that can be used on devices associated with the company. In some instances, Figure 1 The computational NF can be understood as being deployed through application-enabled or application-centric approaches.
[0041] The third approach could be the 3GPP network layer approach. In this approach, functions and entities can be controlled by the operator. Critical functions can reside in the operator's CN (Network Component).
[0042] Figure 3 Another network environment based on some implementation schemes is illustrated.
[0043] Unlike 5G, where computing functions and services are primarily defined as "top" services or provided behind 3GPP "border" gateways such as User Plane Functions (UPF), 6G computing functions can be a central or integral part of the 3GPP network itself. This can benefit from the architecture and corresponding network elements that form part of the 3GPP network.
[0044] The embodiments disclosed herein provide a system architecture and basic framework for ubiquitous computing from a device-centric perspective. This can be accomplished by adding interactions between components and distributed computing network functions.
[0045] The proposed aspects revolve around the idea that computational functionalities (such as DCMF or NCR F) can be performed on a server in the CN (referred to as Central DCMF / Central NCRF 304) or hosted at a local device instance (referred to as Local DCMF / Local NCRF 308), for example, on a powerful device. While the DCMF-DCA process is considered agnostic to the communication / connectivity layer, computational functionality is expected to form a separate functional layer as part of the 6G network itself.
[0046] The implementation scheme disclosed herein addresses how: UEs can form clusters of computing nodes and the basic framework and structure for such clusters; how nodes in the cluster can work collaboratively on computing tasks by implementing task extensions on multiple devices; and how a device / node can be promoted to the cluster head (or control node / master node) while other devices act as processing nodes / worker nodes.
[0047] In addition to single-node operation, compute nodes can be organized as multiple distributed nodes within a compute cluster. A compute cluster collaboratively manages workloads by distributing compute tasks across multiple nodes. A compute cluster can include a control (master) node and processing (worker) nodes. There can be more than one control node in a cluster. Compute nodes in a cluster can belong to the same user (primary use case) or different users.
[0048] The DCA typically resides on the control node. If a device can only act as a processing node, it will also require a DCA. Therefore, both the control node and the processing node can host the DCA. The DCA functionality provided by the control node can be broader than that provided by the processing node. The control node hosts the computational control functionality for the entire cluster, as well as optional local data processing functionality. In such a setup, there will be two types of DCAs: the primary DCA and the secondary DCA. Alternatively, the two types of DCAs can be organized as two separate components (therefore only the primary DCA is referred to as the DCA, and the secondary DCA as the other—but this depends on the protocol model discussed elsewhere in this document).
[0049] Computing clusters can be formed by: DCMF 110s to increase (or reach) the computing power required for larger workloads; by a single user to achieve offloading and efficient load distribution among their own devices (the user can further reconfigure the cluster according to their preferences, enabling or disabling compute nodes, changing node types, etc.); or, depending on the device type, computing framework (application layer) and software environment, hardware requirements, or user preferences, formed as a layout (defined or pre-configured). The protocols used for communication between devices (e.g., DCAs and nodes) further depend on the device capabilities, whether sidelinks or relays are supported, etc.
[0050] The first aspect of this disclosure (referred to herein as aspect 1) relates to the primary DCA and the secondary DCA.
[0051] Devices that host control nodes / master nodes may include a master DCA and control (master) node functionality. The master DCA can act as an interface for external communication with other compute nodes and DCMFs. The DCA also provides a set of application programming interfaces (APIs) and a stack interface.
[0052] The control (master) node function can be implemented as a standalone function or as part of the DCA. The control node function may include one or more of the following functions.
[0053] The Job Control Function (JCF) is used to manage probing and measurement, supervise node operations, control alarm handling, and monitor the resources of jobs running on nodes.
[0054] The scheduler function (SF) is used to allocate workloads for execution on nodes according to a scheduling algorithm, including assigning (related) tasks for execution. The scheduling algorithm can be controlled / configured by the job controller and / or DCA / DCMF.
[0055] A State and Storage Manager (SSM) is used to store the internal state of compute nodes in a cluster, such as for workloads. The SSM can act as a distributed, consistent data store for configuration, service discovery, and scheduler coordination among distributed nodes in the cluster. Multiple nodes can share the same SSM as shared state, including, for example, multiple control nodes.
[0056] In some implementations, when workloads are configured to run on the control node itself, the control node functionality may optionally include a runtime environment (RE) or one or more work units (WUs). In some instances, this can make isolation between workloads more difficult to achieve.
[0057] Examples of devices that can host control nodes include laptops / desktop computers, UEs, relay nodes, fixed wireless access (FWA) devices, base stations, etc.
[0058] Devices hosting processing nodes / worker nodes may include secondary DCAs, which may include APIs and communication interfaces as well as processing (worker) node functionality. Processing (worker) node functionality, which may be implemented as a standalone function or as part of a DCA, may include REs for executing scheduled workloads and interacting with the operating system and the Work Unit (WU). The WU may include, for example, one or more containers, virtual machines, part of an application with one or more OS tasks, or any other form of image / code representation. A work unit can represent the finest granularity of a workload that can be scheduled on a single node or in a cluster.
[0059] Examples of processing nodes include, but are not limited to, UEs, wearable devices, computers, or any type of device (including control nodes).
[0060] In some implementations, the protocol model for distributed computing communication (e.g., DCA to DCMF / NC RF communication) can correspond to one of the following two options.
[0061] According to some implementation schemes, option one may include, for example: Figure 4 The indirect control is shown in the network environment 400. DCMF / NCRF 404 communicates with the primary DCA 408 (and vice versa). The primary DCA 408 communicates with secondary DCA 412 and 416 (and vice versa). The primary DCA 408 can operate at layer N+1 and can be associated with multiple layer N functions hosted by the same device. Layer N functions may include, for example, JCF 420, RE 424, multiple WU 428, SF 432, and SSM 436. The secondary DCA 412 can operate at layer N+1 and can be associated with multiple layer N functions hosted by the same device. Layer N functions may include, for example, RE 440 and multiple WU 444. The secondary DCA 416 can operate at layer N+1 and can be associated with multiple layer N functions hosted by the same device. Layer N functions may include, for example, RE 448 and multiple WU 452.
[0062] Two sub-options can be considered for option one. In the first sub-option, secondary DCA 412 and 416 are not visible to DCMF; for example, primary DCA 408 appears as a single agent to DCMF. However, to achieve proper workload (offloading tasks) matching at DCMF, primary DCA 408 can still indicate how many and what types of control / processing nodes it supports, and what the capabilities of these control / processing nodes are. In the second sub-option, secondary DCA 412 and 416 are visible to DCMF through primary DCA 408; that is, primary DCA 408 acts as a relay. However, the composite distribution and scheduling of workloads in the cluster still occur via primary DCA 408.
[0063] According to some implementation schemes, option two may include, for example: Figure 5 The network environment 500 illustrates direct control. Network environment 500 includes master DCAs 508, 512, and 516, each of which may include functions similar to those shown and described with respect to master DCA 408. Each master DCA 508, 512, and 516 communicates with DCMF / NCRF 504 via a direct link, thereby indicating whether the DCA can (in a fixed manner) act as or can (in a flexible manner) be configured as: a control node / master node, a processing node / worker node, or both.
[0064] In implementations using direct communication, DCMF can handle cluster control when all nodes are configured as control / master nodes. However, workloads can still be distributed across multiple nodes as long as it is clear which node acts as the cluster head. Including multiple nodes with control / master capabilities in the cluster allows for the possibility of switching the cluster head from one node to another. This process can be controlled by DCMF. Alternatively, nodes can autonomously elect the cluster head using a pre-programmed algorithm or an algorithm configured by DCMF. See aspect 5 of this disclosure.
[0065] The second aspect of this disclosure (referred to herein as aspect 2) relates to topological resilience.
[0066] Topology resilience can be provided through a wireless mesh network. In this implementation, each UE or base station with a DCA connected to the DCMF / NCRF hosts a mesh node. Any such node allows access from other DCAs in the community or group (or from a defined specific access level), for example via SL, another RAT, or a non-3GPP access technology. The mesh node is responsible for forwarding data traffic from other mesh nodes, and these interconnected nodes form the network. In this way, even if a direct link fails, the local DCMF / NCRF, the next DCA, or the next cluster head (control node / master node) can remain available.
[0067] Alternatively or additionally, nodes in the device cluster can be managed and connected via a service mesh—this is only an optional component. This option does not necessarily require dedicated protocol functions for cluster head election. The service mesh's control plane can be responsible for its management and configuration.
[0068] The third aspect of this disclosure (referred to herein as Aspect 3) relates to a protocol model for inter-node communication between a control node and a processing node. This can be accomplished according to one or more of the following three options.
[0069] In the first option, inter-node messages are transmitted from DCA to DCA, where each DCA communicates with its underlying compute node functionality. See also, according to some implementation schemes... Figure 6 Network environment 600. Similar to network environment 500, network environment 600 may include a primary DCA 608, a secondary DCA 612, and a secondary DCA 616. However, in network environment 600, each DCA can be directly connected to each other. The DCA acts as a connectivity layer or gateway / agent for compute nodes, for example, carrying inter-node messages or creating individual messages on behalf of compute nodes.
[0070] In the second option, the compute node has a separate sub-function or inter-node communication (INC) node that provides a connectivity layer or proxy / gateway for node-level inter-node communication. See also, according to some implementation schemes... Figure 7 Network Environment 700. Similar to Network Environment 500, Network Environment 700 may include a primary DCA 708, a secondary DCA 712, and a secondary DCA 716. However, in Network Environment 700, each device may include an inter-node communicator (INC) as a Layer N function, such as INC 720, INC 724, and INC 728. The INC will communicate with the corresponding DCA on the same device and will communicate with other INCs on other devices. Therefore, the INC will provide direct inter-node communication between nodes at a different protocol level than the DCA. This option allows communication between DCA-DCMF / NCRF or DCA-DCA to operate as a separate protocol, independent of communication between compute nodes (with less coupling).
[0071] The third option can be similar to the second option, but here, each node implements an inter-node communication proxy (INP) or sidecar (SC) (with protocol adaptation capabilities) capable of communicating via a service-based interface. See also some implementation schemes. Figure 8Network environment 800. Similar to network environment 500, network environment 800 may include a primary DCA 808, a secondary DCA 812, and a secondary DCA 816. However, in network environment 800, each device may include an INP or SC, such as INP or SC 820, INP or SC 824, and INP or SC 828. An INP or SC will communicate with the corresponding DCA on the same device and will communicate with other INPs or SCs on other devices via a service-based interface 832. This option allows nodes in the cluster to operate as a service mesh. Using the service-based interface 832 makes it easier to adapt or migrate some APIs from a CN-based service interface, which can sit on top of Hypertext Transfer Protocol (HTTP). Therefore, local cloud computing principles can be used for communication within the node cluster.
[0072] For topology resilience, devices can interconnect via a mesh network (e.g., via side links (SL) or non-3GPP). In the event of a direct link failure: devices maintain connectivity with other nodes in the system via alternative links; protocol messages can be rerouted to their appropriate destinations via the mesh; secondary DCAs can communicate with the base station on behalf of the primary DCA (acting as SL relays). Alternatively, point-to-point (P2P) connections are also possible (via SL, non-3GPP, or where the base station acts as a relay).
[0073] The fourth aspect of this disclosure (referred to herein as aspect 4) relates to node handover and UE capabilities.
[0074] There may be situations where the primary DCA must be switched to the secondary DCA. For example, if the computer disappears, the UE can take over the remaining devices in the cluster. The switchover can be based on device capabilities; that is, the UE (or any device) can indicate whether it can instantiate and run all the components required for a control node, and it can further indicate whether it can also act as a DCMF / NCRF and / or processing node. These capabilities can be organized as (separate) UE capabilities, where the device can indicate whether it can perform one or more of the following roles: local DCMF; local NCRF; hybrid DCMF / NCRF; control node only; processing node only; or a combination of control and processing node.
[0075] The fifth aspect of this disclosure (referred to herein as aspect 5) relates to cluster head selection and / or reassignment.
[0076] If the cluster head disappears or becomes unresponsive, you can use one or more of the following options to select a new cluster head.
[0077] In the first option, DCMF assigns a new control node as the cluster head. This can be accomplished, for example, via the DCA-DCMF protocol.
[0078] In the second option, the old cluster head transfers control to the new cluster head before exiting service. This can happen after a handshake with another device or with DCMF.
[0079] In the third option, the device autonomously selects (or elects) a new cluster head.
[0080] For example, the choice between the above options may depend on the scenario and the overall configuration of the cluster, as well as whether direct or indirect control is used, as described in Aspect 1. This choice may be based on a general configuration or rule that covers one or more of the following: pre-programmed into the device; configured by the device owner; configured and allocated by the network; controlled by the network operator; or otherwise specified.
[0081] The selection / re-selection of the autonomous cluster head (control / master) node (e.g., the third option discussed above) can be performed as follows.
[0082] Each node acquires parameters describing its own computing resources and its ability to act as a control / master node, and maps these to a "capability ID." This mechanism ensures that no two nodes can have the same capability ID. It can be a hash function. More generally, capability IDs can be sorted in a specific order according to configurable rules (associating higher / lower values with weights). For example, a higher-numbered capability ID identifies the device as eligible to act as the cluster head.
[0083] In some implementations, ranges of capability IDs can be defined. For example, range 1 can be used for processing nodes / worker nodes, and range 2 (with higher ID numbers) can be used for control nodes / master nodes. Only IDs in range 2 can participate in elections. Other orders are also possible, based on rules or starting from the lowest ID number.
[0084] When the control node becomes unavailable, the remaining nodes in the cluster select or elect a new cluster head based on defined configuration mapping rules and election algorithms. Both configuration mapping rules and election algorithms can be configured by the network via DCMF-DCA signaling (e.g., as part of DCA registration) or can be predefined for the nodes in the cluster.
[0085] Although only the control node participates in the election, nodes that cannot act as control nodes (e.g., simple processing nodes / worker nodes) can still send announcement messages to all other nodes in the cluster to notify them of the failure (the unresponsive control node ID can be a parameter). The first (qualified) control node to receive the announcement then initiates the election. Similarly, any control node can initiate an election.
[0086] Figure 9 An operational flow / algorithm structure 900 according to some implementation schemes is illustrated. The operational flow / algorithm structure 900 may be executed by, or implemented in, a device (e.g., UE 102, relay node 104, desktop computer 106, or base station 108) or a component in the device (such as processor circuitry 1204 or 1304).
[0087] The operation flow / algorithm structure 900 may include implementing a primary DCA at 904 to establish a computing cluster. The primary DCA can be used to communicate with computing nodes of other devices (e.g., UE, relay node, desktop computer, base station, etc.) and computing NFs of the core network. The computing NF can be, for example, a DCMF 110 or an NCRF 116.
[0088] In some implementations, the primary DCA can communicate directly with secondary DCAs located on other devices, either via INC (e.g., INC 720) or via INP or SC (e.g., INP or SC 820). For example, the primary DCA can directly send / receive inter-node messages to / from another DCI. Additionally / alternatively, the primary DCA can send / receive inter-node messages to / from another DCI via the INC function. Additionally / alternatively, the primary DCA can use a service-based interface to send / receive inter-node messages to / from another DCI via INP or SC.
[0089] The operation flow / algorithm structure 900 may also include a control node function implemented at 908 to control the operation of the computing cluster. The control node function may be a JCF (e.g., JCF 420) used to manage probing and measurement, supervise node operation, control alarm handling, and monitor resource execution for jobs running on the computing nodes. The control node function may additionally / optionally be an SF (e.g., SF 432) used to allocate workloads for execution on the nodes based on a scheduling algorithm. The control node function may additionally / optionally be an SSM (e.g., SF 436) used to store the internal state of the computing nodes in the computing cluster.
[0090] In some implementations, the operational process / algorithm structure 900 may also include an implementation of the RE (e.g., RE 424). The RE can interact with the operating system of the device hosting the RE to perform scheduled workloads.
[0091] In some implementations, the operation flow / algorithm structure 900 may also include an implementation of WU (e.g., WU 428). WU can handle workloads scheduled as part of distributed computing operations of a computing cluster.
[0092] In some implementations, the operational process / algorithm structure 900 may also include a hosted mesh node to provide access to another DCA.
[0093] In some implementations, the operational flow / algorithm structure 900 may also include switching from implementing the primary DCA to implementing the secondary DCA. In these implementations, another device in the computing cluster can take over the primary DCA.
[0094] Figure 10 An operational flow / algorithm structure 1000 according to some implementation schemes is illustrated. The operational flow / algorithm structure 1000 may be executed by, or implemented in, a device (e.g., UE 102, relay node 104, desktop computer 106, or base station 108) or a component in the device (such as processor circuitry 1204 or 1304).
[0095] The operation flow / algorithm structure 1000 may include implementing a secondary DCA at 1004 to communicate with the primary DCA, which is part of the computing cluster.
[0096] The operation flow / algorithm structure 1000 may also include a processing node function implemented at 1008 to perform operations of the computing cluster. The processing node function may be a RE (e.g., RE 440 or RE 448), which interacts with the operating system to execute scheduled workloads. The processing node function may additionally / alternatively be a WU, which handles workloads scheduled as part of a distributed computing operation.
[0097] In some implementations, the operation flow / algorithm structure 1000 may also include switching from implementing a secondary DCA to implementing a primary DCA.
[0098] Figure 11 An operational flow / algorithm structure 1100 according to some implementation schemes is illustrated. The operational flow / algorithm structure 1100 may be executed by, or implemented in, a device (e.g., UE 102, relay node 104, desktop computer 106, or base station 108) or a component in the device (such as processor circuitry 1204 or 1304).
[0099] The operation process / algorithm structure 1100 may include determining at 1104 that a node will stop or has already stopped operating as the cluster head.
[0100] The operation process / algorithm structure 1000 can also include switching to the cluster head role after making a determination at 1008 and 1104.
[0101] In some implementations, switching to the cluster head role can be based on receiving an assignment from the DCMF, performing a handshake with a node that previously operated as a cluster head, or performing an autonomous cluster head reselection based on a capability ID. The capability ID can be based on computing resources or capabilities that functioned as a cluster head.
[0102] Figure 12 Device 1200 is illustrated according to some implementation schemes. Device 1200 may be similar to and substantially interchangeable with any device such as a managed node discussed herein.
[0103] Device 1200 can be any mobile or non-mobile computing device, such as a mobile phone, computer, tablet, industrial wireless sensor (e.g., microphone, carbon dioxide sensor, pressure sensor, humidity sensor, thermometer, motion sensor, accelerometer, laser scanner, level sensor, inventory sensor, voltmeter / ammeter, or actuator), video surveillance / monitoring device (e.g., camera or camcorder), wearable device (e.g., smartwatch), or Internet of Things device.
[0104] Device 1200 may include a processor 1204, an RF interface circuit 1208, a memory / storage device 1212, a user interface 1216, a sensor 1220, a drive circuit 1222, a power management integrated circuit (PMIC) 1224, an antenna 1226, and a battery 1228. Components of device 1200 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 12 The block diagram is intended to show a high-level view of some of the components of the device 1200. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific implementations.
[0105] The components of device 1200 can be coupled to various other components via one or more interconnects 1232, which can represent any type of interface, input / output, bus (local, system, or extension), transmit line, trace, or optical connection, allowing various circuit components (on common or different chips or chipsets) to interact with each other.
[0106] Processor 1204 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 1204A, central processing unit circuitry (CPU) 1204B, and graphics processing unit circuitry (GPU) 1204C. Processor 1204 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional procedures from memory / storage device 1212) to cause device 1200 to perform ubiquitous computing operations as described herein. Processor 1204 may also include interface circuitry 1204D for communicatively coupling the processor circuitry to one or more other components of device 1200.
[0107] In some implementations, the baseband processor 1204A can access the communication protocol stack 1236 in the memory / storage device 1212 to communicate over a 3GPP-compliant network. Generally, the baseband processor 1204A can access the communication protocol stack 1236 to: perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and perform control plane functions at the PHY, MAC, RLC, PDCP, RRC, and NAS layers. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuitry 1208.
[0108] The baseband processor 1204A can generate or process baseband signals or waveforms carrying information in 3GPP-compliant networks. In some implementations, the waveforms used for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (DFT-S-OFDM) in the uplink.
[0109] The memory / storage device 1212 may include one or more non-transitory computer-readable media, which include instructions (e.g., a communication protocol stack 1236) that can be executed by one or more processors in processor 1204 to cause device 1200 to perform ubiquitous computing operations as described herein.
[0110] Memory / storage device 1212 includes any type of volatile or non-volatile memory that can be distributed throughout device 1200. In some embodiments, some memory / storage devices in memory / storage device 1212 may be located on the processor 1204 itself (e.g., memory / storage device 1212 may be part of a chipset corresponding to baseband processor 1204A), while other memory / storage devices 1212 are located external to processor 1204 but are accessible via a memory interface. Memory / storage device 1212 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.
[0111] RF interface circuitry 1208 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allows device 1200 to communicate with other devices via a radio access network. RF interface circuitry 1208 may include various components arranged in the transmit or receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.
[0112] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna 1226, and further filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which downconverts the RF signal into a baseband signal that is provided to the baseband processor of processor 1204.
[0113] In the transmission path, the transceiver's transmitter up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM can then amplify the RF signal using a power amplifier before it is radiated across the air interface via antenna 1226.
[0114] In various implementations, the RF interface circuit 1208 can be configured to transmit / receive signals in a manner compatible with NR access technologies.
[0115] Antenna 1226 may include antenna elements for converting electrical signals into radio waves to travel through the air and for converting received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna 1226 may have omnidirectional, directional, or combinations thereof antenna panels to enable beamforming and multiple-input multiple-output communication. Antenna 1226 may include a microstrip antenna, patch antenna, phased array antenna, or a printed antenna fabricated on the surface of one or more printed circuit boards. Antenna 1226 may have one or more panels designed for a specific frequency band (including bands in FR1 or FR2).
[0116] User interface 1216 includes various input / output (I / O) devices designed to enable a user to interact with device 1200. User interface 1216 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual components for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, or a headset. Output device circuitry includes any physical or virtual components for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). Output device circuitry may include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary status indicators such as light-emitting diodes (LEDs) and multi-character visual outputs) or more complex outputs such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, and projectors), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of device 1200.
[0117] Sensor 1220 may include devices, modules, or subsystems designed to detect events or changes in its environment and transmit information about the detected events (sensor data) to other devices, modules, or subsystems. Examples of such sensors include: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors); depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other similar audio capture devices.
[0118] The driving circuitry 1222 may include software and hardware elements that operate to control a specific device embedded in, attached to, or otherwise communicatively coupled to the device 1200. The driving circuitry 1222 may include various drivers that allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the device 1200. For example, the driving circuitry 1222 may include a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface, a sensor driver for obtaining sensor readings of sensor 1220 and controlling and allowing access to sensor 1220, a driver for obtaining actuator positions of electromechanical components or controlling and allowing access to electromechanical components, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.
[0119] The PMIC 1224 manages the power supplied to various components of the device 1200. Specifically, relative to the processor 1204, the PMIC 1224 controls power source selection, voltage scaling, battery charging, or DC-DC conversion.
[0120] Battery 1228 can power device 1200, but in some examples, device 1200 may be mounted or deployed in a fixed location and may have a power source coupled to the power grid. Battery 1228 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, battery 1228 may be a typical lead-acid automotive battery.
[0121] Figure 13 Network device 1300 is illustrated according to some implementation schemes. Network device 1300 may be similar to and largely interchangeable with base stations or nodes that implement NF (such as NCRF / DCMF).
[0122] Network device 1300 may include processor 1304, RF interface circuitry 1308 (if implemented as a base station), CN interface circuitry 1314, memory / storage device circuitry 1312, and antenna structure 1326.
[0123] The components of network device 1300 can be coupled to various other components via one or more interconnectors 1328.
[0124] The processor 1304, RF interface circuit 1308, memory / storage device circuit 1312 (including communication protocol stack 1310), antenna structure 1326, and interconnect 1328 can be similar to those relative to... Figure 12 Similar named elements are shown and described.
[0125] Processor 1304 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 1304A, central processing unit circuitry (CPU) 1304B, and graphics processing unit circuitry (GPU) 1304C. Processor 1304 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from memory / storage device circuitry 1312) to configure network device 1300 as described herein. Processor 1304 may also include interface circuitry 1304D to communicatively couple processor circuitry to one or more other components of network device 1300.
[0126] The CN interface circuit 1314 can provide connectivity to a core network (e.g., a 6GC using a 6th generation core network (6GC) compatible network interface protocol, such as Carrier Ethernet or some other suitable protocol). Network connectivity can be provided to / from network device 1300 via fiber optic or wireless backhaul. The CN interface circuit 1314 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 1314 may include multiple controllers for providing connectivity to other networks using the same or different protocols.
[0127] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.
[0128] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples below. As another example, circuitry associated with the UE, base station, or network element described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described in the Embodiments section below.
[0129] Example
[0130] Further exemplary implementations are provided in the following sections.
[0131] Example 1 includes a method comprising: implementing a master DCA to communicate with compute nodes and compute NFs (e.g., DCMF or NCRF); and implementing control node functions to control the operation of the compute cluster, the control node functions including JCF, SF, or SSM.
[0132] Example 2 includes the method according to Example 1 or some other embodiment herein, wherein the control node functionality includes a JCF for managing probing and measurement, monitoring node operation, controlling alarm handling, or performing resource monitoring on jobs running on compute nodes in the compute cluster.
[0133] Example 3 includes the method according to Example 1 or some other embodiment herein, wherein the control node function includes an SF, the SF being used to allocate workloads for execution on the node based on a scheduling algorithm.
[0134] Example 4 includes the method according to Example 1 or some other embodiment herein, wherein the control node function includes an SSM for storing the internal state of the compute nodes in the compute cluster.
[0135] Example 5 includes the method according to Example 1 or some other embodiment of this document, the method further comprising: implementing a runtime environment for executing scheduled workloads while interacting with an operating system.
[0136] Example 6 includes the method according to Example 1 or some other embodiment herein, the method further comprising: implementing work units to process workloads scheduled as part of distributed computing operations of the computing cluster.
[0137] Example 7 includes the method according to Example 1 or some other embodiment of this document, the method further comprising: hosting mesh nodes to provide access to another DCA.
[0138] Example 8 includes the method according to Example 1 or some other embodiment of this document, the method further comprising: sending inter-node messages directly from the primary DCA to another DCA; or receiving inter-node messages directly from the primary DCA to another DCA.
[0139] Example 9 includes the method according to Example 1 or some other embodiment of the present invention, the method further comprising: sending an inter-node message to another inter-node communication function via an inter-node communication function; or receiving an inter-node message from another inter-node communication function via an inter-node communication function.
[0140] Example 10 includes the method according to Example 1 or some other embodiment of this document, the method further comprising: sending an inter-node message to another node via a service-based interface; or receiving an inter-node message from another node via a service-based interface.
[0141] Example 11 includes the method according to Example 1 or some other embodiment of this document, the method further comprising: switching from implementing the primary DCA to implementing the secondary DCA.
[0142] Example 12 includes a method comprising: implementing a secondary DCA to communicate with a primary DCA as part of a computing cluster; and implementing processing node functionality to perform operations of the computing cluster, the processing node functionality including a runtime environment (RE) or a work unit (WU).
[0143] Example 13 includes the method according to Example 12 or some other embodiment herein, wherein the one or more processing node functions include a runtime environment for executing scheduled workloads while interacting with an operating system.
[0144] Example 14 includes the method according to Example 12 or some other embodiment herein, wherein the one or more processing node functions include a work unit for processing workloads scheduled as part of a distributed computing operation.
[0145] Example 15 includes the method according to Example 12 or some other embodiment herein, the method further comprising: switching from implementing the secondary DCA to implementing the primary DCA.
[0146] Example 16 includes a method comprising: determining that a node will stop or has stopped operating as a cluster head role; and switching to the cluster head role based on the determination.
[0147] Example 17 includes the method according to Example 16 or some other embodiment herein, the method further comprising: receiving an assignment from the DCMF; and switching to the cluster head role based on receiving the assignment.
[0148] Example 18 includes the method according to Example 16 or some other embodiment herein, the method further comprising: performing a handshake operation with the node operating as the cluster head role; and switching to the cluster head role based on performing the handshake operation.
[0149] Example 19 includes the method according to Example 16 or some other embodiment herein, the method further comprising: performing an autonomous cluster head reselection operation based on a capability ID; and switching to the cluster head role based on performing the autonomous cluster head reselection operation.
[0150] Example 20 includes the method according to Example 19 or some other embodiment herein, wherein the capability ID is based on computing resources or a capability acting as the cluster head role.
[0151] Another embodiment may include an apparatus comprising one or more elements for performing the method described or associated with any one of embodiments 1 to 20 or any other method or process described herein.
[0152] Another embodiment may include one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method or any other method or process described herein according to any one of embodiments 1 to 20.
[0153] Another embodiment may include an apparatus comprising one or more elements for performing the methods described or associated with any one of embodiments 1 to 20 or any other methods or processes described herein.
[0154] Another embodiment may include the methods, techniques or processes described or associated with any one of embodiments 1 to 20 or any part or component thereof.
[0155] Another embodiment may include an apparatus comprising: one or more processors; and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described or associated with any one or more of embodiments 1 to 20.
[0156] Another embodiment may include signals described or associated with any one of embodiments 1 to 20 or any part or component thereof.
[0157] Another embodiment may include datagrams, information elements, packets, frames, segments, PDUs, or messages described or associated with any one of embodiments 1 to 20 or any part or component thereof, or otherwise described in this disclosure.
[0158] Another embodiment may include a signal encoded with data as described or associated with any one of embodiments 1 to 20 or a portion or component thereof, or otherwise described in this disclosure.
[0159] Another embodiment may include signals encoded as datagrams, IEs, packets, frames, segments, PDUs, or messages as described or associated with any one of embodiments 1 to 20 or any part or component thereof, or otherwise described in this disclosure.
[0160] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process described or associated with any one or more of embodiments 1 to 20.
[0161] Another embodiment may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process described or associated with any one or a portion thereof according to Embodiments 1 to 20.
[0162] Another embodiment may include signals in a wireless network as shown and described herein.
[0163] Another embodiment may include a method for communicating in a wireless network as shown and described herein.
[0164] Another embodiment may include a system for providing wireless communication as shown and described herein.
[0165] Another embodiment may include a device for providing wireless communication as shown and described herein.
[0166] Unless otherwise expressly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be obtained from the practice of various embodiments.
[0167] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.
Claims
1. A method for wireless communication, the method comprising: Implement a master distributed computing agent (DCA) to communicate with the device's compute nodes and distributed computing management function (DCMF) or networked compute storage function (NCRF) to establish a computing cluster; as well as Implement control node functions to control the operation of the computing cluster, including job control function (JCF), scheduler function (SF), or state and storage manager (SSM).
2. The method according to claim 1, wherein the control node function includes a JCF, the JCF being used to manage probing and measurement, supervise node operation, control alarm processing, or perform resource monitoring on jobs running on computing nodes in the computing cluster.
3. The method of claim 1, wherein the control node function includes an SF, the SF being used to allocate workloads for execution on the node based on a scheduling algorithm.
4. The method according to claim 1, wherein the control node function includes an SSM, the SSM being used to store the internal state of the computing nodes in the computing cluster.
5. The method according to claim 1, further comprising: Implement a runtime environment for executing scheduled workloads while interacting with the operating system.
6. The method according to claim 1, further comprising: Implement work units to handle workloads scheduled as part of the distributed computing operations of the computing cluster.
7. The method according to claim 1, further comprising: Host mesh nodes to provide access to another DCA.
8. The method according to claim 1, further comprising: The primary DCA directly sends inter-node messages to the other DCA; or The primary DCA receives inter-node messages directly from another DCA.
9. The method according to claim 1, further comprising: Send inter-node messages to another inter-node communication function via the inter-node communication function; or Receive inter-node messages from another inter-node communication function via the inter-node communication function.
10. The method according to claim 1, further comprising: Send inter-node messages to another node via a service-based interface; or Receive inter-node messages from another node via a service-based interface.
11. The method according to claim 1, further comprising: Switch from implementing the primary DCA to implementing the secondary DCA.
12. A method for wireless communication, the method comprising: Implement a secondary distributed computing agent (DCA) to communicate with the primary DCA, which is part of the computing cluster; as well as Implement processing node functions to perform operations of the computing cluster, the processing node functions including runtime environment (RE) or work unit (WU).
13. The method of claim 12, wherein the one or more processing node functions include a runtime environment for executing scheduled workloads while interacting with an operating system.
14. The method of claim 12, wherein the one or more processing node functions include a work unit for processing workloads scheduled as part of a distributed computing operation.
15. The method according to claim 12, further comprising: Switch from implementing the secondary DCA to implementing the primary DCA.
16. A method for wireless communication, the method comprising: Determine whether the node will stop or has already stopped operating as the cluster head; as well as Based on the determination, switch to the cluster head role.
17. The method according to claim 16, further comprising: Receive assignment from DCMF; as well as Switch to the cluster head role based on the received assignment.
18. The method according to claim 16, further comprising: Perform a handshake operation with the node operating in the cluster head role; as well as The cluster head role is switched based on the handshake operation performed.
19. The method according to claim 16, further comprising: Perform autonomous cluster head reselection based on capability ID; as well as The cluster head role is switched by performing the autonomous cluster head reselection operation.
20. The method of claim 19, wherein the capability ID is based on computing resources or capabilities acting as the cluster head role.