Systems, methods, and devices for decentralized distributed computing

Abstract

The present disclosure generally relates to systems, methods, and devices for decentralized distributed computing. A solution for decentralized distributed computing within a wireless environment is provided. A set of local wireless devices (e.g., user equipments (UEs)) may form a sub-network with one another. The UEs may support various functions to enable compute tasks to be offloaded from some sub-network devices and performed by other sub-network devices. Results generated by executing the task may be returned to the device that offloads the task. The management node of the sub-network may connect to a base station and / or directly to the management of another sub-network. A computing task may be offloaded from one sub-network, performed by another sub-network or network device, such as the base station or network server, and the result of the task being performed may be returned to the sub-network from which the task is offloaded.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 608,170, filed on Dec. 8, 2023, and U.S. Patent Application No. 18 / 962,318, filed on Nov. 27, 2024, the entire contents of both of which are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure relates to wireless communication networks and mobile device capabilities. Background Art

[0004] Wireless communication networks and wireless communication services are becoming increasingly dynamic, complex, and ubiquitous. For example, some wireless communication networks can be developed to implement fourth-generation (4G), fifth-generation (5G), or New Radio (NR) technologies. Such technologies can include solutions for enabling user equipment (UE) and network devices (such as base stations) to communicate with each other. In some scenarios, such communication can involve enabling devices to share resources and collaboratively perform tasks. Brief Description of the Drawings

[0005] The present disclosure will be readily understood and implemented through the detailed description and the drawings. The same reference numerals can designate the same features and structural elements. The drawings and the corresponding description are provided as non-limiting examples of aspects, embodiments, etc. of the present disclosure, and the reference to "one" or "a" aspect, embodiment, etc. may not necessarily refer to the same aspect, embodiment, etc., and can mean at least one, one or more, etc.

[0006] Figure 1 is a diagram that is an example of an overview of one or more embodiments described herein.

[0007] Figure 2 is a diagram of an example network of one or more embodiments described herein.

[0008] Figure 3 is a diagram that is an example of decentralized distributed computing within a sub-network of one or more embodiments described herein.

[0009] Figure 4 is a diagram that is an example of the functionality of one or more embodiments described herein.

[0010] Figure 5 is a diagram that is an example of the functionality and nodes of one or more embodiments described herein.

[0011] Figures 6 - 7 is a diagram that is an example of the node and functionality arrangement of one or more embodiments described herein.

[0012] Figure 8 A diagram of an example of functions, nodes, and user equipment (UE) according to one or more specific implementations described herein.

[0013] Figure 9 A diagram of an example of a UE according to one or more specific implementations described herein.

[0014] Figures 10 - 11 A diagram of an example of the arrangement of UEs and nodes within a subnetwork according to one or more specific implementations described herein.

[0015] Figure 12 A diagram of an example of nodes of a subnetwork according to one or more specific implementations described herein.

[0016] Figures 13 - 14 A diagram of an example of a process for decentralized distributed computing according to one or more specific implementations described herein.

[0017] Figures 15 - 16 A diagram of an example of a process for decentralized distributed computing according to one or more specific implementations described herein.

[0018] Figures 17 - 19 A diagram of an example of a process for decentralized distributed computing according to one or more specific implementations described herein.

[0019] Figure 20 A diagram of an example of decentralized distributed computing between subnets according to one or more specific implementations described herein.

[0020] Figure 21 A diagram of an example of an alternative for decentralized distributed computing between subnets according to one or more specific implementations described herein.

[0021] Figure 22 A diagram of an example of decentralized distributed computing involving a subnet server according to one or more specific implementations described herein.

[0022] Figure 23 A diagram of an example of network nodes for decentralized distributed computing according to one or more specific implementations described herein.

[0023] Figures 24 - 25 A diagram of an example of negotiating a computational offloading control function according to one or more specific implementations described herein.

[0024] Figures 26 - 27 A diagram of an example of a process for decentralized distributed computing between subnets according to one or more specific implementations described herein.

[0025] Figures 28 - 29 is a diagram of an example of a process for decentralized distributed computing between sub - networks according to one or more specific implementations described herein.

[0026] Figures 30 - 31 is a diagram of an example of a process for decentralized distributed computing between sub - networks according to one or more specific implementations described herein.

[0027] Figure 32 is a diagram of an example of components of a device according to one or more specific implementations described herein.

[0028] Figure 33 is a block diagram illustrating components that can read instructions from a machine - readable medium or a computer - readable medium (e.g., a non - transitory machine - readable storage medium) and perform any one or more of the methods discussed herein according to one or more specific implementations described herein.

[0029] Figures 34 - 36 is a diagram of an example of a process for decentralized distributed computing according to one or more specific implementations described herein. Detailed Description

[0030] The following detailed description refers to the accompanying drawings. The same reference numerals in different drawings can identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description, as other specific implementations can be utilized and structural or logical changes can be made without departing from the scope of the present disclosure.

[0031] A telecommunications network can include user equipment (UE) capable of communicating with a base station and / or other network access nodes. UEs can also communicate directly with each other via device - to - device (D2D) connections. The UE and the base station can implement various technologies and communication standards for enabling the UE and the base station to discover each other, establish and maintain connectivity, and exchange information in an ongoing manner. The purposes of such technologies can include enabling devices (e.g., UE and / or base station) to share resources and collaboratively perform tasks. This can be referred to as decentralized distributed computing. Generally, distributed computing can include tasks associated with a first device (e.g., UE) being transferred to another device (e.g., another UE) and executed by the other device to produce a result that is returned to the first device. Distributed computing can be decentralized in the sense that it removes network control from the distributed computing protocol and enables that control to be deployed by different devices (e.g., devices that are not network nodes).

[0032] One or more of the techniques described herein may enable decentralized distributed computing within a wireless environment. A group of local wireless devices (e.g., UEs) may form a subnetwork with each other. These UEs may support various functions to enable computing tasks to be offloaded from some subnetwork devices and executed by other subnetwork devices. Results generated by performing the tasks may be returned to the device that offloaded the task. A management node (MN) of the subnetwork may be connected to a base station and / or directly connected to an MN of another subnetwork. Computing tasks may be offloaded from a subnetwork, executed by another subnetwork or network device (such as a base station or network server), and the results of the executed tasks may be returned to the subnetwork that offloaded the task. These and many other features and techniques are described in detail herein.

[0033] Figure 1 FIG. is an example overview 100 of decentralized distributed computing according to one or more particular implementations described herein. As shown, overview 100 may include UEs 110 grouped into subnetworks 150-1 and 150-2. The UEs may include various different types of wireless devices such as smart phones, desktop computers, virtual reality devices, augmented reality devices, wearable devices, and laptop computers. The subnetworks may be connected to a base station 120. The subnetworks may also be directly connected to each other. One or more of the techniques described herein may enable the UEs 110 to participate in decentralized distributed computing among UEs 110 within the same subnetwork 150, among UEs 110 of different subnetworks 150 via the base station 120, and / or among UEs 110 of different subnetworks 150 via a direct connection between subnetworks 150-1 and 150-2. Details and examples of these and other features and techniques are described below with reference to the figures.

[0034] Figure 2 FIG. is an example network 200 according to one or more particular implementations described herein. Example network 200 may include UEs 210, 210-2, etc. (collectively referred to as “UEs 210” and individually referred to as “UE 210”), a radio access network (RAN) 220, a core network (CN) 230, an application server 240, an external network 250, and a computing server 260.

[0035] The systems and devices of example network 200 may operate according to one or more communication standards, such as the 3rd Generation (3G), 4th Generation (4G) (e.g., Long Term Evolution (LTE)), and / or 5th Generation (5G) (e.g., New Radio (NR)) communication standards of the 3rd Generation Partnership Project (3GPP). Additionally or alternatively, one or more of the systems and devices in example network 200 may operate according to other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., 6th Generation (6G) standard, 7th Generation (7G) standard, etc.), Institute of Electrical and Electronics Engineers (IEEE) standards (e.g., Wireless Metropolitan Area Network (WMAN), etc.), and so on.

[0036] As shown, UE 210 may include a smart phone (e.g., a handheld touchscreen mobile computing device capable of connecting to one or more wireless communication networks). Additionally or alternatively, UE 210 may include other types of mobile or non-mobile computing devices capable of wireless communication, such as a Personal Data Assistant (PDA), pager, laptop computer, desktop computer, wireless handset, etc. In some embodiments, UE 210 may include an Internet of Things (IoT) device (or IoT UE), which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. In addition to or alternatively, the IoT UE may utilize one or more types of technologies, such as machine-to-machine (M2M) communication or machine type communication (MTC) (e.g., for exchanging data with an MTC server or other devices via a Public Land Mobile Network (PLMN)), proximity-based service (ProSe) or device-to-device (D2D) communication, sensor networks, IoT networks, etc. Depending on the scenario, the M2M or MTC data exchange may be machine-initiated, and the IoT network may include interconnected IoT UEs with short-term connections (which may include uniquely identifiable embedded computing devices within the Internet infrastructure). In some scenarios, the IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connection of the IoT network.

[0037] UE 210 can communicate with and establish connections with one or more other UEs 210 via one or more wireless channels 212, and each of the one or more wireless channels may include a physical communication interface / layer. The connections may include M2M connections, MTC connections, D2D connections, SL connections, etc. The connections may involve the PC5 interface. In some specific implementations, UEs 210 may be configured to discover each other, negotiate wireless resources between each other, and establish connections between each other without involving the intervention or communication of RAN nodes 222 or another type of network node. In some specific implementations, discovery, authentication, resource negotiation, registration, etc. may involve communication with RAN nodes 222 or another type of network node.

[0038] Various techniques for communicating between UEs 210 to facilitate offloading or computing operations are within the scope of the present disclosure. As described herein, in an example, UE 210 may communicate with RAN node 222 to request SL resources. RAN node 222 may respond to the request by providing UE 210 with dynamic grant (DG) or configured grant (CG) regarding the SL resources. UE 210 may communicate with RAN node 222 using a licensed band and communicate with another UE 210 using an unlicensed or licensed band. In another example, UE 210 may communicate directly without involving RAN node 222, such as through a resource pool, etc.

[0039] The UE 210 may communicate with and establish a connection (e.g., communicatively couple) to the RAN 220, which may involve one or more radio channels 214-1 and 214-2, each of which may include a physical communication interface / layer. In some embodiments, the UE may be configured with dual connectivity (DC) as multi-radio access technology (multi-RAT) or multi-radio dual connectivity (MR-DC), where the UE capable of multi-receive and transmit (Rx / Tx) may use resources provided by different network nodes (e.g., 222-1 and 222-2), and the different network nodes may be connected via a non-ideal backhaul (e.g., one network node provides NR access and the other network node provides E-UTRA for LTE or NR access for 5G). In such scenarios, one network node may operate as a master node (MN), and the other node may operate as a secondary node (SN). The MN and SN may be connected via a network interface, and at least the MN may be connected to the CN 230. Additionally, at least one of the MN or SN may operate via shared spectrum channel access, and the functions specified for the UE 210 may be used for integrated access and backhaul mobile termination (IAB-MT). Similar to the UE 210, the IAB-MT may access the network using one network node or using two different nodes with an enhanced dual connectivity (EN-DC) architecture, a new radio dual connectivity (NR-DC) architecture, etc. In some embodiments, a base station (as described herein) may be an example of the network node 222. In some scenarios, the RAN 120 may coordinate with the core network 130 via interfaces 124, 126, and / or 128.

[0040] As shown, the UE 210 may additionally or alternatively be connected to an access point (AP) 216 via a connection interface 218, which may include an air interface enabling the UE 210 to be communicatively coupled to the AP 216. The AP 216 may include a wireless local area network (WLAN), a WLAN node, a WLAN endpoint, etc. The connection 216 may include a local wireless connection, such as a connection compliant with any IEEE702.11 protocol, and the AP 216 may include a wireless fidelity router or other AP. Although not explicitly depicted in Figure 2 , the AP 216 may be connected to another network (e.g., the Internet) without being connected to the RAN220 or the CN 230.

[0041] RAN 220 may include one or more RAN nodes 222-1 and 222-2 (collectively referred to as RAN nodes 222 and individually referred to as RAN node 222) that enable the establishment of channels 214-1 and 214-2 between the UE 210 and the RAN 220. The RAN nodes 222 may include network access points that are configured to provide radio baseband functions for data and / or voice connections between users and the network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc.). Thus, by way of example, the RAN node may be an E-UTRAN Node B (e.g., enhanced Node B, eNodeB, eNB, 4G base station, etc.), a next-generation base station (e.g., 5G base station, NR base station, next-generation eNB (gNB), etc.). The RAN nodes 222 may include roadside units (RSUs), transmit receive points (TRxP or TRP), and one or more other types of terrestrial stations (e.g., terrestrial access points). In some scenarios, the RAN nodes 222 may be dedicated physical devices such as macrocell base stations and / or low-power (LP) base stations for femtocells, picocells, etc. that provide a smaller coverage area, smaller user capacity, or higher bandwidth compared to macrocells.

[0042] Some or all or portions of the RAN nodes 222 may be implemented as one or more software entities running on a server computer and as part of a virtual network that may be referred to as a centralized RAN (CRAN) and / or a virtual baseband unit pool (vBBUP). In these specific implementations, the CRAN or vBBUP may implement RAN function splitting, such as packet data convergence protocol (PDCP) splitting, where the radio resource control (RRC) and PDCP layers may be operated by the CRAN / vBBUP, and other layer 2 (L2) protocol entities may be operated by individual RAN nodes 222; medium access control (MAC) / physical (PHY) layer splitting, where the RRC, PDCP, radio link control (RLC), and MAC layers may be operated by the CRAN / vBBUP, and the PHY layer may be operated by individual RAN nodes 222; or "lower PHY" splitting, where the RRC, PDCP, RLC, MAC layers, and the upper portion of the PHY layer may be operated by the CRAN / vBBUP, and the lower portion of the PHY layer may be operated by individual RAN nodes 222. This virtualization framework may allow the idle processor cores of the RAN nodes 222 to conduct or execute other virtualization applications.

[0043] In some specific implementations, the individual RAN node 222 may represent an individual gNB distributed unit (DU) connected to the gNB control unit (CU) via an individual F1 or other interface. In such specific implementations, the gNB-DU may include one or more remote radio heads or radio frequency (RF) front-end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in the RAN 220 or by a server pool (e.g., a group of servers configured to share resources) in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes in the RAN node 222 may be a next-generation eNB (i.e., gNB), which may provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol termination to the UE 210 and may be connected to the 5G core network (5GC) 230 via the NG interface.

[0044] Any one of the RAN nodes in the RAN node 222 may serve as an endpoint of the air interface protocol and may be the first point of contact for the UE 210. In some specific implementations, any one of the RAN nodes in the RAN node 222 may perform various logical functions of the RAN 220, including but not limited to the functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. The UE 210 may be configured to communicate with each other or with any one of the RAN nodes in the RAN node 222 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to OFDMA communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink (SL) communication), but the scope of such specific implementations is not limited in this regard. The OFDM signal may include a plurality of orthogonal subcarriers.

[0045] One or more of the techniques described herein may enable decentralized distributed computing within a wireless environment. A group of local wireless devices (e.g., UE 210) may form a subnetwork with each other. UE 210 may support various functions to enable computational tasks to be offloaded from some subnetwork devices and executed by other subnetwork devices. Results generated by performing the tasks may be returned to the device that offloaded the task. The MN of a subnetwork may be connected to the base station 222 and / or directly connected to the MN of another subnetwork. Computational tasks may be offloaded from a subnetwork, executed by another subnetwork or network device (such as base station 222, computing server 260, application server 240, and / or one or more other types of network devices), and the results of the executed tasks may be returned to the subnetwork that offloaded the task. These and many other features and techniques are described in detail herein.

[0046] RAN nodes 222 may be configured to communicate with each other via interface 223. In a particular implementation where the system is an LTE system, interface 223 may be an X2 interface. In an NR system, interface 223 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 222 (e.g., two or more eNB / gNBs or a combination thereof) connected to the evolved packet core (EPC) or CN 230, or between two eNBs connected to the EPC. In some particular implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). X2-U may provide a flow control mechanism for user packets transmitted through the X2 interface and may be used to convey information regarding the delivery of user data between eNBs or gNBs. For example, X2-U may provide specific sequence number information regarding user data transmitted from the master eNB (MeNB) to the secondary eNB (SeNB); information regarding the successful in-sequence delivery of PDCP packet data units (PDUs) from the SeNB to the UE 210 for user data; information regarding PDCP PDUs not delivered to the UE 210; information regarding the current minimum desired buffer size at the SeNB for transmitting user data to the UE; and so on. X2-C may provide access mobility functions within LTE (e.g., including context transfer from a source eNB to a target eNB, user plane transmission control, etc.), load management functions, and inter-cell interference coordination functions.

[0047] As shown in the figure, the RAN 220 can be connected (e.g., communicatively coupled) to the CN 230. The CN 230 can include a plurality of network elements 232, which are configured to provide various data and telecommunications services to customers / subscribers (e.g., users of the UE 210) connected to the CN 230 via the RAN 220. In some specific implementations, the CN 230 can include an evolved packet core (EPC), a 5G CN, and / or one or more additional or alternative types of CNs. The components of the CN 230 can be implemented in one physical node or in separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some specific implementations, network function virtualization (NFV) can be used to virtualize any or all of the above network node roles or functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). The logical instantiation of the CN 230 can be referred to as a network slice, and the logical instantiation of a part of the CN 230 can be referred to as a network sub-slice. The network function virtualization (NFV) architecture and infrastructure can be used to virtualize one or more network functions onto physical resources that include a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, the NFV system can be used to perform virtual or reconfigurable implementations of one or more EPC components / functions.

[0048] As shown in the figure, the CN 230, the application server 240, and the external network 250 can be connected to each other via interfaces 234, 236, 238, and 254, which can include IP network interfaces. The application server 240 can include one or more server devices or network elements (e.g., virtual network functions (VNFs)), which provide applications that use IP bearer resources together with the CM 230 (e.g., Universal Mobile Telecommunications System Packet Service (UMTS PS) domain, LTE-PS data services, etc.). The application server 240 can additionally or alternatively be configured to support one or more communication services of the UE 210 via the CN 230 (e.g., Internet Protocol voice (VoIP) sessions, push-to-talk (PTT) sessions, group communication sessions, social network services, etc.). Similarly, the external network 250 can include one or more of a variety of networks (including the Internet), thereby providing the mobile communication network and the UE 210 with network access to a variety of additional services, information, interconnections, and other network features.

[0049] Figure 3FIG. It is a diagram of an example 300 of decentralized distributed computing within a sub-network according to one or more specific embodiments described herein. As shown, example 300 may include UE 210, base station 222, and MN 310. MN 310 may include UE 210 or another type of wireless device. In stage 1, MN 310 may communicate with local UE 210 to create a sub-network. Thus, the sub-network may include multiple local nodes, such as smart phones, laptops, wearable devices (e.g., wireless necklaces, watches, etc.), and / or one or more other types of UE 210. MN 310 may generate and convey control plane and user plane information to create the sub-network and enable decentralized distributed computing within the sub-network. MN 310 may use various frequency ranges to communicate with other UE 210, including high-frequency spectral bands (e.g., frequencies in the terahertz (THz) band (e.g., frequencies between 0.3 THz and 3.0 THz)).

[0050] In stage 2, MN 310 may communicate with base station 222 to register the sub-network with base station 222. Creating the sub-network may enable decentralized distributed computing between the UE 210 of the sub-network, and in stage 3, re-registering the sub-network with base station 222 may enable decentralized distributed computing between the UE 210 of different sub-networks (not shown). In some specific embodiments, the UE 210 of different sub-networks may directly participate in decentralized distributed computing (e.g., without base station 222 acting as an information relay or intermediary). Details and examples of these features will be discussed in more detail below with reference to the subsequent figures.

[0051] Figure 4 FIG. It is a diagram of an example 400 of functions according to one or more specific embodiments described herein. As shown, example 400 may include an offloading function (OF) 410, a computing function (CF) 420, a compute offload control function (CCF) 430, and a routing function (RF) 440. One or more of functions 410-440 may be referred to as nodes rather than functions. For example, OF 410 may be referred to as offloading node 420, which may indicate a device (e.g., UE 210) that performs or conducts the offloading function. Thus, functions 410-440 may be implemented by one or more UE 210 of the sub-network.

[0052] OF 410 may include a set of operations performed by UE 210 to identify tasks to be offloaded to another UE 210. The task may be a computing task that may involve receiving, processing, or computing and / or communicating one or more types of information. Offloading the task may cause the task to be executed by the UE 210 to which the task is offloaded. The UE 210 that receives the task may include CF420, which enables the UE 210 to receive the task, execute the task, and return the result of executing the task to OF 410.

[0053] CCF 430 may include a set of operations that control whether a task is offloaded from OF 410 to CF 420, which tasks are offloaded from OF 410 to CF 420, and when a task is offloaded from OF 410 to CF 420. CCF 430 may collect information about the computing capabilities of the UEs 210 in the subnetwork, receive and evaluate requests to offload tasks, and prevent, cause, or enable the offloading of tasks from OF 410 to CF 420. RF 440 may include a set of operations that enable communication between functions 410 - 430. For example, RF 440 may enable CCF 430 to collect UE capability information from UEs 210 within the subnetwork, implement and manage the offloading of tasks from OF 410 to CF 420, and / or implement or manage the sending of responses or results of computing tasks from CF 420 to OF 410.

[0054] Figure 5 is a diagram of an example 500 of functions and nodes according to one or more specific implementations described herein. As shown, example 500 may include functions 410 - 440, which may be performed by one or more of different combinations of MN 310, one or more high - capability (HC) nodes 520, and one or more low - capability (LC) nodes 530. MN 310 was described above with reference to Figure 3 Whether a device in the subnetwork is an HC node 520 or an LC node 530 may depend on the resources available to the device (e.g., processing power, memory capacity, storage capacity, wireless communication capabilities, etc.). A device with a relatively large amount of resources may be an HC node 520, while a device with a relatively small amount of resources may be an LC node 530. MN310 may be an HC node, and HC nodes 520 and LC nodes 530 may or may not be directly connected to the base station. As shown in the examples described below, different arrangements of MN 310, HC nodes 520, and / or LC nodes 530 may perform one or more of functions 410 to 440.

[0055] Figures 6 - 7Diagrams of examples 600 and 700 arranged according to nodes and functions of one or more specific implementations described herein. Refer to Figure 6 , MN 310 can be configured to execute CCF 430, RF 440, and CF 420. LC 530 can be configured to execute OF 410. Thus, according to example 600, decentralized distributed computing within the subnetwork can be performed between MN 310 and LC 530. Refer to Figure 7 , MN 310 can be configured to execute CCF 430 and RF 440. LC 530 can be configured to execute OF410. HC node 520 can be configured to execute CF 420. Thus, decentralized distributed computing within the subnetwork according to example 700 can be performed between LC 530 and HC 520 under the control of CCF 430 of MN 310. The techniques described herein also include other arrangements of nodes and functions. In some specific implementations, functions 410-440 can be performed by HC node 520 and LC node 530 such that MN 310 does not perform any of functions 400. In some specific implementations, functions can be performed by more than one node. For example, parts of RF 444 can be performed by different HC nodes. Additionally or alternatively, the subnetwork can have multiple instances of one type of function. For example, the subnetwork can have multiple LC nodes each capable of executing OF 410 and / or multiple HC nodes each capable of executing CF 420.

[0056] Figure 8 Diagram of example 800 of functions, nodes, and UEs according to one or more specific implementations described herein. As shown, example 800 can include functions 410-440, which can be performed by one or more of different combinations of MN 310, one or more high-capacity (HC) nodes 520, and one or more low-capacity (LC) nodes 530. Similarly, MN 310, HC node 520, and LC node 530 can be implemented by one or more UEs 210-1, UE210-2......UE 210-N (where N is greater than or equal to 3) of the subnetwork. Refer to Figures 9 - 12 for Figure 8 description.

[0057] Figure 9 Diagram of an example of the type of UE 210 according to one or more specific implementations described herein. As shown, UE 210 can include wearable devices (e.g., wireless necklaces, wireless watches, etc.), smart phones, desktop computers, virtual reality systems, augmented reality systems, laptop computers, and so on. Figures 10 - 11It is a diagram of examples 1000 and 1100 of the arrangement of UEs and nodes within a subnetwork according to one or more specific embodiments described herein. Referring to example 1000, the subnetwork may include UEs 210-1 and 210-2. UE 210-1 may be configured to operate as MN 310 and HC node 520. UE 210-2 may be configured to operate as LC node 530. Referring to Figure 11 , the subnetwork may include UEs 210-1, 210-2, and 210-3. UE 210-1 may be configured to operate as MN 310. UE 210-2 may be configured to operate as LC node 530. UE 210-2 may be configured to operate as HC node 520. Thus, depending on the subnetwork, different UEs 210 may operate as different types of nodes. Figure 12 It is a diagram of example 1200 of the nodes of a subnetwork according to one or more specific embodiments described herein. As shown, subnetwork 1200 may include MN 310, HC node 520, and LC node 530. Each node may be implemented as one or more UEs 210, and each node may support or execute one or more functions 410-440 and communicate with each other to achieve decentralized distributed computing.

[0058] Collectively, examples 1000, 1100, and 1200 illustrate the non-limiting flexibility and non-limiting variability of the configuration of distributed computing with a subnetwork as described herein. Example 1000 illustrates that a single UE 210 may act as MN 310 and HC node 520. Example 1100 illustrates that different UEs 210 may implement different types of nodes (e.g., MN 310 does not need to be designated or configured to operate as HC node 520 or LC node). Example 1200 illustrates that the distributed computing as described herein may be implemented as a subnetwork including one or more MNs 310, one or more HC nodes 520, and / or one or more LC nodes 530. Each node (310, 520, and 530) may be implemented by different UEs 210 or the same UE 210 (e.g., MN 310 and HC 520).

[0059] Referring to Figure 8, a particular UE 210 can change between operating as an MN 310, an HC node 520, and an LC node 530. For example, UE 210 can be an HC node 520 while UE 210 is in an idle mode or otherwise has a resource quantity above a given threshold, but if / when UE 210 activates a local process that uses these resources, UE 210 can transition to an LC node 530 for the purpose of decentralized distributed computing. Once the local process is complete and the corresponding resources become available, UE 210 can transition back to an HC node again for the purpose of decentralized distributed computing. Similarly, one or more functions 410-440 performed by a particular node 310-530 can change. For example, when UE 210 is an HC node 520, UE 210 can support one or more of CF 420, CCF 430, and RF 440. However, if or when UE 210 transitions to an LC node 530, UE 210 can stop supporting one or more of CF 420, CCF 430, and RF 440 and instead support OF 410 because local resources may have become scarce. Similar changes can occur when UE 210 enters and / or leaves a subnetwork. Thus, the relationships between functions 410-440, nodes 310-530, and UE 210 can be dynamic.

[0060] Figures 13 - 14 is a diagram of an example of process 1300 for decentralized distributed computing according to one or more specific implementations described herein. Process 1300 can be implemented by base station 222, MN 310, and one or more UEs 210-1 and 210-2. In some specific implementations, some or all of process 1300 can be performed by one or more other systems or devices (including Figure 2 one or more of the devices). Additionally, process 1300 can include one or more operations that are fewer than, additional to, differently ordered than, and / or arranged differently than those shown in Figures 13 - 14 . In some specific implementations, some or all of the operations of process 1300 can be performed independently of, sequentially with, simultaneously with, etc., one or more of the other operations of process 1300. Thus, the techniques described herein are not limited to Figures 13 - 14 the number, sequence, arrangement, timing, etc., of the operations or processes depicted.

[0061] Procedure 1300 may include calculating an offloading scenario that can be maintained within a local subnetwork. The MN 310 of the subnetwork is also the CCF of the subnetwork, and there is no participation from any other CCF. Therefore, CCF negotiation is not involved in Procedure 1300. As shown, Procedure 1300 may include stage 1 subnetwork creation (at 1310). As described above, this may involve the MN 310 communicating with the local UE 210 to create the subnetwork. Procedure 1300 may also include stage 2 subnetwork registration (at 1320). This may include the MN 310 communicating with the base station 222 to register the subnetwork with the base station 222. Although not shown, registering the subnetwork with the base station 222 may enable the devices of the subnetwork to participate in decentralized distributed computing involving one or more other subnetworks. In some specific implementations, stage 2 may be optional because the computing offloading is maintained within the local subnetwork. In this case, the MN 310 may be a private HC node (e.g., the UE 210) configured to provide support to other LC nodes in the subnetwork. Alternatively, the MN 310 may be a network or third-party-owned HC node configured to support the LC nodes in the subnetwork based on a subscription model. For example, it may be authenticated in stage 1 subnetwork creation (1310) without involving other networks or third-party entities (e.g., the base station 222, the core network 230, the application server 240, the computing server 260, etc.). In such a scenario, the computing distribution may be maintained within the subnetwork (e.g., under the control of the MN 310).

[0062] As shown, one or more UEs 210-2 configured with CF may convey computing capability updates to the MN 310 (at 1330). The computing capability updates may include a CF identifier (ID), floating-point operations per second (FLOPS), memory capacity, processing capacity, and / or one or more types of information regarding the ability of the UE 210-2 to operate computing functions. In some specific implementations (Alternative 1), Procedure 1500 may include subnetwork CCF control configuration, where the MN 310 may aggregate and / or combine the CCF computing capabilities within the subnetwork (at 1340). In such scenarios, the MN 310 may forward the aggregated and combined CF capabilities to the UE 210-1 configured with OF (at 1350). In other specific implementations (Alternative 2), the MN 310 may forward the CF capabilities to the UE 210-1 configured with OF without aggregation and combination (at 1360).

[0063] At some point, UE 210-1 may determine to offload a computing task to one or more CF UEs 210-2. Thus, UE 210-1 may send a computing offloading request to MN 310 (at 1370). In some embodiments, the computing offloading request may include one or more types of information related to the task and / or task completion, such as a computing task ID, a CF ID, a battery power calculation capacity requirement, a memory requirement, a latency requirement, etc.

[0064] MN 310 may select a UE 210-2 configured with a CF to receive the computing task (at 1410). In some embodiments, MN 310 may evaluate or analyze the computing offloading request and / or the task information associated with the request to identify a suitable UE 210-2 for computing the task (at 1420). This may be based on, for example, comparing the computing capacity information to be received from UE 210-2 with the task information or requirements (e.g., CF ID, task type, task ID, time sensitivity or scheduling requirements of the task, computing capacity requirements, memory requirements, latency requirements, etc.). Based on the result of the evaluation (e.g., when there is no suitable UE 210-2 for the task), MN 310 may send a computing offloading response indicating rejection of the offloading request to UE 210-1 (1430). Alternatively, MN 310 may send a computing offloading request with appropriate task information to a suitable UE 210-2 (at 1440). UE 210-2 may receive the request, compute the corresponding task, and send a computing offloading response to MN 310 (at 1450). In some embodiments, the response may also include an update on the computing capacity of UE 210-2. UE 210-1 may receive the computing offloading response and forward or relay the computing offloading response to UE 210-1. In this way, process 1300 may provide one or more example solutions for decentralized distributed computing.

[0065] Figures 15 - 16 is a diagram of examples of processes 1500 and 1600 for decentralized distributed computing according to one or more embodiments described herein. Processes 1500 and 1600 may be implemented by base station 222, MN 310, and one or more UEs 210-1 and 210-2. In some embodiments, some or all of processes 1500 and 1600 may be performed by one or more other systems or devices (including Figure 2 one or more of the devices). Additionally, processes 1500 and 1600 may include Figures 15 - 16Those operations shown as compared to fewer, additional, differently ordered, and / or arranged one or more operations. In some particular implementations, some or all of the operations of processes 1500 and 1600 may be performed independently, sequentially, simultaneously, etc. relative to one or more of the other operations of processes 1500 and 1600. Thus, the techniques described herein are not limited to Figures 15 - 16 the number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0066] Process 1500 may include calculating an offloading scenario that can be maintained within a local subnetwork. As described below, process 1500 includes offloading tasks via a direct connection between OF UE 210-1 and CF UE 210-2. For example, OF UE 210-1 may be wireless glasses within the same subnetwork as a laptop computer, and the wireless glasses directly offload tasks to the laptop computer for computing. In such a scenario, the CF UE of OF UE 210-1 and CF UE 210-2 may negotiate with each other regarding which device will run the CCF for the decentralized distributed computing protocol.

[0067] As shown, process 1500 may include stage 1 subnetwork creation (at 1510). As described above, this may involve the MN 310 communicating with the local UE 210 to create a subnetwork. This may also include parameter exchange between the MN 310, UE 210-1, and UE 210-2. Parameters may be exchanged between UE 210-1 and UE 210-2 via the MN 310, and these parameters may enable the establishment of a direct connection between UE 210-1 and UE 210-2. Examples of parameters may include transmit and receive resource pools and discovery resources to allow direct communication via the sidelink (SL), information enabling communication via listen before talk (LBT), or any other proprietary pairing protocol that allows direct communication between nodes. Additionally or alternatively, examples of parameters may include CCF IDs, device types, and categories, etc. for all devices in the subnetwork. This may be used by all devices in the subnetwork to populate their respective databases, which may later be used for the direct connection computing offloading protocol.

[0068] The process 1500 may further include stage 2 sub-network registration (at 1520). This may include the MN 310 communicating with the base station 222 to register the sub-network with the base station 222. Although not shown, registering the sub-network with the base station 222 may enable the devices of the sub-network to participate in decentralized distributed computing involving one or more other sub-networks. In some specific implementations, stage 2 may be optional since the computing offloading is maintained within the local sub-network. In this case, the MN 310 may be a private HC node (e.g., the UE 210) configured to provide support to other LC nodes in the sub-network. Alternatively, the MN 310 may be a network or third-party-owned HC node configured to support the LC nodes in the sub-network based on a subscription model. For example, it may be authenticated in the stage 1 sub-network creation (1510) without involving other networks or third-party entities (e.g., the base station 222, the core network 230, the application server 240, the computing server 260, etc.). In such a scenario, the computing distribution may be maintained within the sub-network (e.g., under the control of the MN 310).

[0069] As shown, the process 1500 may include the MN 310, the UE 210-1, and the UE 210-2 participating in a negotiation (at 1530) regarding which device may operate as the CCF for the offloading procedure. An example for negotiating which device may operate as the CCF of the sub-network is discussed below with reference to Figures 17 - 19 An alternative (Alternative 1) to the process 1600 since the process 1500 may include a scenario where the UE 210-2 is designated as the CCF 430, and the process 1600 may include a scenario where the UE 210-1 is designated as the CCF 430. Figure 16

[0070] In some scenarios (e.g., alternative 1), in addition to operating as a CF 420, UE 210-2 can also be selected to operate as a CCF (430). In such scenarios, UE 210-2 can convey a computing power update to UE 210-1. The computing power update can include a CF ID, FLOPS, memory capacity, processing capacity, and / or one or more types of information regarding the ability of UE 210-2 to operate a computing function. In some embodiments, UE 210-2 can select a CCF (e.g., CCF ID) for a computing task, which can be based on a comparison of one or more requirements of the task with the computing power reported by one or more UE 210-2. UE 210-1 can send a compute offloading request (at 1560) to the selected UE 210-2. The request can include compute task information such as CF type or CF category, task type, task ID, time sensitivity or scheduling requirements of the task, compute capacity requirements, memory requirements, latency requirements, etc. The CF type or CF category can indicate the type or category of computing function to be applied to the task information. UE 210-2 can receive and complete the computing task and can send a compute offloading message response (at 1570) to UE 210-1. The compute offloading response can include the result of applying the CF to the task information. In some embodiments, UE210-2 can also send updated capacity or capability information to UE 210-1.

[0071] See Figure 16 , process 1600 can include scenarios where compute offloading can be kept within a local subnetwork. As described below, process 1600 includes offloading a task via a direct connection between OF UE 210-1 and CF UE 210-2. For example, OF UE210-1 can be wireless glasses within the same subnetwork as a laptop computer, and the wireless glasses directly offload a task to the laptop computer for computing. In such a scenario, the OF UE 210-1 and the CF UE of CF UE 210-2 can negotiate with each other regarding which device will run the CCF 430 for a decentralized distributed computing protocol.

[0072] As shown, process 1600 may include phase 1 sub-network creation (at 1610). As described above, this may involve the MN 310 communicating with the local UE 210 to create a sub-network. This may also include parameter exchange between the MN 310, UE 210-1, and UE 210-2. Parameters may be exchanged between UE 210-1 and UE 210-2 via the MN 310, and these parameters may enable the establishment of a direct connection between UE 210-1 and UE 210-2. Examples of parameters may include transmit and receive resource pools and discovery resources to allow for direct communication via SL, information enabling communication via listen-before-talk (LBT), or any other proprietary pairing protocol that allows for direct communication between nodes. Additionally or alternatively, examples of parameters may include CCF ID, device type, and category, etc. for all devices in the sub-network. This may be used by all devices in the sub-network to populate their respective databases, which may later be used for direct connection computing offloading procedures.

[0073] Process 1600 may also include phase 2 sub-network registration. This may include the MN 310 communicating with the base station 222 to register the sub-network with the base station 222 (at 1620). Although not shown, registering the sub-network with the base station 222 may enable the devices of the sub-network to participate in decentralized distributed computing involving one or more other sub-networks. In some specific implementations, phase 2 may be optional as the computing offloading is kept within the local sub-network. In such a case, the MN 310 may be a private HC node (e.g., UE 210) configured to provide support to other LC nodes in the sub-network. Alternatively, the MN 310 may be a network or third-party-owned HC node configured to support LC nodes in the sub-network based on a subscription model, e.g., which may be authenticated in phase 1 sub-network creation (1610) without involving other networks or third-party entities (e.g., base station 222, core network 230, application server 240, computing server 260, etc.). In such a scenario, the computing distribution may be kept within the sub-network (e.g., under the control of the MN 310).

[0074] As shown, process 1600 may include the MN 310, UE 210-1, and UE 210-2 participating in a negotiation (at 1630) regarding which device may operate as the CCF for the offloading procedure. An example of negotiating which device may operate as the CCF for the sub-network is discussed below with reference to Figures 17 - 19 Process 1600 may include Figure 15An alternative to process 1500 (Alternative 2), since process 1600 can include a scenario in which UE 210-1 is designated as the CCF 430, and process 1500 can include a scenario in which UE 210-2 is designated as the CCF 430.

[0075] In some scenarios (e.g., Alternative 2), in addition to operating as the OF 410, UE 210-1 can also be selected to operate as the CCF (430). UE 210-1 can convey a computing capability request to UE 210-2, which can include the OF ID (at 1640), and in response, UE 210-2 can convey a computing capability update to UE 210-1 (at 1650). The computing capability update can include the CF ID, FLOPS, memory capacity, processing capacity, and / or one or more types of information regarding the ability of UE 210-2 to operate the computing function. UE 210-1 can send a computing offloading request to the selected UE 210-2 (at 1670). The request can include computing task information such as the CF type or category, task type, task ID, time sensitivity or scheduling requirements of the task, computing capacity requirements, memory requirements, latency requirements, etc. The CF type or category can indicate the type of computing function to be applied to the task information. UE 210-2 can receive and complete the computing task, and can send a computing offloading message response to UE 210-1 (at 1680). The computing offloading response can include the result of applying the CF to the task information. In some embodiments, UE 210-2 can also send updated capacity or capability information to UE 210-1.

[0076] Figures 17 - 19 is a diagram of examples of processes 1700, 1800, and 1900 for decentralized distributed computing according to one or more embodiments described herein. Processes 1700, 1800, and 1900 can be implemented by base station 222, MN 310, and one or more UEs 210-1 and 210-2. In some embodiments, some or all of processes 1700, 1800, and 1900 can be performed by one or more other systems or devices (including Figure 2 one or more of the devices of). Additionally, processes 1700, 1800, and 1900 can include one or more operations that are fewer, additional, differently ordered, and / or arranged compared to those shown in Figures 17 - 19 In some embodiments, some or all of the operations of processes 1700, 1800, and 1900 can be performed independently, continuously, simultaneously, etc. relative to one or more of the other operations of processes 1700, 1800, and 1900. Thus, the techniques described herein are not limited to Figures 17 - 19The number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0077] As shown, process 1700 may include stage 1 sub-network creation (at 1710). As described above, this may involve the MN 310 communicating with the local UE 210 to create the sub-network. This may also include parameter exchange between the MN 310, UE 210-1, and UE 210-2, including an indication of the capabilities of each UE 210 that may enable determination of which UE 210s are HC UEs 210 and which are LC UEs 210.

[0078] Process 1700 may also include stage 2 sub-network registration (1720). This may include the MN 310 communicating with the base station 222 to register the sub-network with the base station 222. Although not shown, registering the sub-network with the base station 222 may enable the devices of the sub-network to participate in decentralized distributed computing involving one or more other sub-networks. In some specific implementations, stage 2 may be optional as the computation offloading is maintained within the local sub-network. In such a case, the MN 310 may be a private HC node (e.g., UE 210) configured to provide support to other LC nodes in the sub-network. Alternatively, the MN 310 may be a network or third-party-owned HC node configured to support LC nodes in the sub-network based on a subscription model, e.g., which may be authenticated in stage 1 sub-network creation (1710) without involving other network or third-party entities (e.g., base station 222, core network 230, application server 240, computing server 260, etc.). In such a scenario, the computation distribution may be maintained within the sub-network (e.g., under the control of the MN 310).

[0079] Processes 1700, 1800, and 1900 may include scenarios where the MN 310, UE 210-1 running OF 410, and UE 210-2 running CF 420 may each support the CCF 430. This would require negotiation between them regarding control of who takes the computation offloading control logic. Process 1700 includes a first example of negotiation between the devices regarding which device will operate the CCF 430. Process 1800 includes a second example of negotiation between the devices regarding which device will operate the CCF 430. And process 900 includes an alternative outcome of processes 1700 and 1800.

[0080] Procedure 1700 may include where MN 310 determines which devices will support the implementation of managing the CCF (at 1720). MN 310 may make this determination based on the capabilities or capacity information received from UE 210-1 and / or UE 210-2 (not shown). MN 310 may receive the capabilities or capacity information during or after Phase 1 or Phase 2. This determination may be based on which device has more available capacity, whether each device has a certain set of capabilities, whether the received capabilities or capacity information exceeds one or more preselected thresholds, and / or one or more other types of criteria.

[0081] Procedure 1700 may also include MN 310 sending a message to UE210-1 and UE 210-2 indicating which device will be the managing CCF. The managing CCF may include the primary CCF used by the devices of the subnet for offloading computing tasks. In some implementations, MN 310 may re-evaluate which devices should be the managing CCF based on a prompt (e.g., a request from UE 210), scheduling (e.g., periodically), and / or a specified event (e.g., a device leaving the subnet). As shown in Alternative 1, based on the indication from MN310, UE 210-2 may become the managing CCF 430. Conversely, as shown in Alternative 2, based on the indication from MN 310, UE 210-1 may become the managing CCF 430.

[0082] Procedure 1800 may include procedures similar to Phases 1 and 2 (1810 and 1820) explained above Figure 17 In contrast to Procedure 1700, MN 310 in Procedure 1800 may not have a central role in determining which devices support CCF 430. Instead, the negotiation process is limited to other devices, such as UE 210-1 and UE 210-2. As shown, UE 210 may broadcast its computing capabilities / requests and their CCF IDs to other UEs 210 in the subnet (at 1830). Each broadcast may include a CCF status update with one or more types of information related to evaluating whether the sending device should be designated to provide the CCF for the subnet. Examples of such information may include the CCF ID, the battery life of UE 210, the computing capabilities of the UE, the received (Rx) signal strength, etc.

[0083] Each UE 210 may receive and evaluate the broadcast information from other devices (not shown). The evaluation may include applying one or more types of rules, thresholds, criteria, and / or one or more other types of evaluation techniques to the received information. Based on this evaluation, each UE 210 may determine which UE 210 will operate as the CCF for the subnet. For purposes of explanation Figure 18For the purpose, it is assumed that UE 210-2 is more eligible to support the CCF than UE 210-1. Thus, UE 210-2 can send a management CCF indication and a CCF ID (at 1840) to UE 210-1, and in response, UE 210-1 can send (e.g., via unicast or broadcast) a management CCF response message including the CCF ID of UE 210-2 and an acknowledgement indication. Thus, UE 210-2 can operate as the management CCF 430 of this subnetwork. In some specific implementations, UE 210-1 may ultimately operate as the management CCF 430 of the subnetwork.

[0084] Procedure 1900 may include phases 1 and 2 (1910 and 1920) procedures similar to those described above with reference to Figure 17 and Figure 18 Explanation. Similar to procedure 1800, the MN 310 of procedure 1900 may not have a central role in determining which devices support the CCF 430 of the subnetwork. However, in contrast to procedure 1800, procedure 1900 may involve request-based CCF negotiation, where the CCF devices can be determined based on request messages between UEs 210 rather than broadcast messages.

[0085] As shown, UE 210-1 can send a CCF status request (at 1930) to UE 210-2. The request may include one or more types of information related to a request for sending the CCF status or capabilities of UE 210-2 to UE 210-2. Examples of such information may include information related to sending UE 210-1, such as CF ID, battery power calculation capacity requirements, memory requirements, latency requirements, etc. UE 210-2 can receive the message and evaluate the information from UE 210-1. The evaluation may include applying one or more types of rules, thresholds, criteria, and / or one or more other types of evaluation techniques to the received information. In some specific implementations, the evaluation may also or alternatively include a comparison of the capabilities information of UE 210-2 with the information received from UE 210-1. Based on this evaluation, UE 210-2 can determine whether UE 210-2 can specifically operate as the CCF of UE 210-1 or as the CCF of the subnetwork. For explanation Figure 19For the purpose of decentralized distributed computing, it is assumed that UE 210-2 is eligible to operate the CCF. Thus, UE 210-2 can send a CCF status response message with one or more types of information to UE 210-1. Examples of such information can include information related to the sending UE 210, such as CCF ID, battery power calculation capacity requirements, memory requirements, latency requirements, etc. UE 210-1 can receive the message and evaluate the information from UE 210-2. Thus, UE 210-2 can operate as the management CCF 430 of this subnet. In some specific embodiments, UE 210-1 can ultimately operate as the management CCF 430 of the subnet.

[0086] Figure 20 FIG. 2000 is a diagram of an example of decentralized distributed computing between subnets according to one or more specific embodiments described herein. As shown, example 2000 can include a subnet, UE 210, base station 222, and MN 310. MN 310 can include UE 210 or another type of wireless device. In phase 1, MN 310 can communicate with local UE 210 to create a subnet. Thus, the subnet can include multiple local nodes, such as smartphones, laptops, wearable devices (e.g., wireless necklaces, watches, etc.), and / or one or more other types of UE 210. MN 310 can generate and convey control plane and user plane information to create the subnet and enable decentralized distributed computing within the subnet. MN 310 can use various frequency ranges to communicate with other UE 210, including high-frequency spectral bands (e.g., frequencies in the terahertz (THz) band (e.g., frequencies between 0.3 THz and 3.0 THz)).

[0087] In phase 2, MN 310 can communicate with base station 222 to register the subnet with base station 222. Creating the subnet can enable decentralized distributed computing between the UEs 210 of the subnet, and in phase 3, registering the subnet with base station 222 can enable decentralized distributed computing between the UEs 210 of different subnets, which can include similar types of devices (e.g., MN 310 and UE 210) and can also be registered with base station 222. In some specific embodiments, the UEs 210 of different subnets can directly participate in decentralized distributed computing (e.g., without base station 222 acting as an information relay or intermediary). In other specific embodiments, the UEs 210 and MN 310 of different subnets can rely on direct communication between MN 310 and MN 310 (e.g., without base station 222 being used as an information relay or intermediary) to perform decentralized distributed computing between them. Details and examples of these features will be discussed in more detail below with reference to the subsequent figures.

[0088] Figure 21 This is a diagram of an example 2100 of a node for a sub - network for decentralized distributed computing according to one or more specific embodiments described herein. As shown, sub - network (SUB NW) 2150 - 1 and sub - network (SUB NW) 2150 - 2 may each include MN 310, HC node 520, and LC node 530. Each node may be implemented as one or more UEs 210, and each node may support or execute one or more functions 410 - 440 and communicate with each other to achieve decentralized distributed computing as described herein. In some specific embodiments, decentralized distributed computing may occur between sub - networks 2150 - 1 and 2150 - 2 via the connection between MN 2150 and base station 222 (Option A). Additionally or alternatively, decentralized distributed computing may occur between direct connections between MNs 2150 (Option B).

[0089] Figure 22 This is a diagram of an example 2200 of decentralized distributed computing involving a sub - network server according to one or more specific embodiments described herein. As shown, sub - networks 2150 - 1, 2150 - 2, 2150 - 3, and 2150 - 4 may each include MN, HC, and LC nodes 2250. Each node may be implemented as one or more UEs 210, and each node may support or execute one or more functions 410 - 440 and communicate with each other to achieve decentralized distributed computing as described herein. Each sub - network 2150 may be connected to base station 222 - 1 or 222 - 1, which in turn may be connected to core network 230 and one or more computing servers 260. This arrangement of networks and devices may enable different types of decentralized distributed computing, the details and examples of which are described below with reference to the subsequent figures.

[0090] Figure 23 This is a diagram of an example 2300 of a network node for decentralized distributed computing according to one or more specific embodiments described herein. As shown, example 2300 includes base station 222, CN 230, and one or more computer servers 250. As described herein, similar to different arrangements of how different UEs 210 within a sub - network may perform functions, the specific embodiments described herein include scenarios in which one or more network entities (e.g., base station 222, CN 230, and one or more computer servers 250) may perform or support one or more functions (e.g., CF 420, CCF 430, RF 440, etc.) to achieve decentralized distributed computing.

[0091] Figures 24 - 25 This is a diagram of examples 2400 and 2500 of negotiating computing offloading control functions according to one or more specific embodiments described herein. SeeFigure 24 , the CCF 430s of different subnets can participate in the negotiation between subnets or be the subject of such negotiation, regarding which CCF 430 can operate as the management CCF 430-1 and which can operate as the supporting CCF. See Figure 25 , in addition to handling the management of resources and process management functions that support the CCF 430, the management CCF 430-1 can also enable the management CCF 430-1 to control the overall distribution logic involved in decentralized distributed computing. The supporting CCF can delegate (e.g., to the management CCF 430-1) some or all of the computing distribution logic and the management of resources and process management functions. In some specific implementations, the deployment within a network device (e.g., a base station, CN, server, etc.) or a subnet device (e.g., UE 210) can be anywhere, and the negotiation between different CCFs to determine which CCF operates as the management CCF and which CCF operates as the supporting CCF is described in more detail with reference to the subsequent figures.

[0092] Figures 26 - 27 is a diagram of an example of process 2600 for decentralized distributed computing between subnets according to one or more specific implementations described herein. Process 2600 can be implemented by the base station 222, and the MNs 310-1 and 310-2 of subnets 2150-1 and 2150-2. As shown, the MNs 310-1 and 310-2 can include CCFs. In some specific implementations, some or all of process 2600 can be performed by one or more other systems or devices (including Figure 2 one or more of the devices). Additionally, process 2600 can include one or more operations that are fewer than, additional to, differently ordered than, and / or arranged differently from those shown in Figures 26 - 27 . In some specific implementations, some or all of the operations of process 2600 can be performed independently of, consecutively with, simultaneously with, etc. one or more of the other operations of process 2600. Thus, the techniques described herein are not limited to Figures 26 - 27 the number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0093] As shown, example 2600 can include subnet 2150-1, MN 310-1, base station 222, subnet 2150-2, and MN 310-2. Subnets 2150-1 and 2150-2 can include more devices and nodes, such as Figure 26As shown. In Phase 1, MN310-1 and 310-2 can communicate with local UE 210 (not shown) to create subnets 2150-1 and 2150-2. Thus, subnets 2150-1 and 2150-2 can include multiple local nodes such as smart phones, laptops, wearable devices (e.g., wireless necklaces, watches, etc.) and / or one or more other types of UE 210. MN 310-1 and 310-2 can generate and convey control plane and user plane information to create the subnets and enable decentralized distributed computing within subnets 2150-1 and 2150-2. MN 310-1 and 310-2 can use various frequency ranges to communicate with other UE 210, including high frequency spectrum bands (e.g., frequencies in the terahertz (THz) band (e.g., frequencies between 0.3 THz and 3.0 THz)). In some specific implementations, base station 222 can be replaced by another subnet similar to subnets 2150-1 and 2150-2, and can undergo Phase 2 subnet creation in a similar manner.

[0094] In Phase 2, MN 310-1 and 310-2 can communicate with base station 222 to register subnets 2150-1 and 2150-2 with base station 222. Creating subnets 2150-1 and 2150-2 can enable decentralized distributed computing between UE 210 in subnets 2150-1 and 2150-2, and in Phase 3, re-registering the subnets with base station 222 can enable decentralized distributed computing between UE 210 in different subnets 2150-1 and 2150-2 via base station 222. In some specific implementations, UE 210 in different subnets 2150-1 and 2150-2 can directly participate in decentralized distributed computing (e.g., without base station 222 acting as an information relay or intermediary).

[0095] Phase 2 can be a mandatory or optional step, depending on the scenario or specific implementation. For example, when accessing the computing resources of another subnet via base station 222, Step 2 can be mandatory. Although the CCF of base station 222 may not be triggered, the communication of base station 222 can be utilized such that subnets 2150-1 and 2150-2 can be registered via Phase 2. When accessing the computing resources of another subnet via directed MN-to-MN communication, Phase 2 can be optional because MN 310-1 and 310-2 of subnets 2150-1 and 2150-2 can communicate without using base station 222. Details and examples of these features will be discussed in more detail below with reference to the subsequent figures.

[0096] Process 2600 may include an example of CCF negotiation to enable decentralized distributed computing between different sub-networks 2150-1 and 2150-2. This may be common for some or all decentralized computing offloading scenarios, where different available CCF entities negotiate with each other to decide which one of the involved CCFs will play the role of the managing CCF, while the remaining ones act as supporting CCFs.

[0097] MN 310-2 may send a CCF status update to base station 222 (at 2630). The CCF status update may include the CCF ID of the CCF of MN 310-2. The CCF status update may also or alternatively include information such as the battery level of MN 310-2 and / or sub-network 2150-2, sub-network computing requests, Rx signal strength, etc. Base station 222 may send a CCF status update to MN 310-1 (at 2640). The CCF status update may include the CCF ID of the CCF of base station 222 (not shown). The CCF status update may also or alternatively include information such as the battery level of base station 222, base station computing capacity, base station computing requests, RX signal strength, etc. MN 310-1 may send a CCF status update to base station 222 (at 2650). The CCF status update may include the CCF ID of the CCF of MN 310-1. The CCF status update may also or alternatively include information such as the battery level of MN 310-1 and / or sub-network 2150-1, base station computing capacity, base station computing requests, RX signal strength, etc.

[0098] Base station 222 may send a CCF status update to MN 310-2 (at 2660). The CCF status update may include the CCF ID of the CCF of base station 222 (not shown). The CCF status update may also or alternatively include information such as the battery level of base station 222, base station computing capacity, base station computing requests, RX signal strength, etc. MN 310-2 may send a CCF status update to MN 310-1 (at 2670). The CCF status update may include the CCF ID of the CCF of MN 310-2. The CCF status update may also or alternatively include information such as the battery level of MN 310-2 and / or sub-network 2150-2, sub-network computing capacity, sub-network computing requests, RX signal strength, etc.

[0099] MN 310-1 can send a CCF status update (at 2680) to MN 310-2. The CCF status update can include the CCF ID of the CCF of MN310-1. The CCF status update can also or alternatively include the battery level, sub-network computing capacity, sub-network computing requests, RX signal strength, etc. of MN 310-1 with respect to MN 310-1 and / or sub-network 2150-1. Thus, sub-networks 2150-1 and 2150-2 can each know the status, availability, capacity, etc. of MN 310-1, MN 310-2, and / or base station 222. In some specific implementations, one or more of operations 2630-2680 can occur in a different operational arrangement or order.

[0100] One or more of the above CCF status updates can be periodically transmitted in response to an event trigger using broadcast, multicast, or unicast communication (e.g., via SIB or dedicated signaling).

[0101] See Figure 27 In process 2600 of, base station 222 and MNs 310-1 and 310-2 can evaluate the information received from each other to determine (e.g., negotiate) which device will operate as the management CCF (at 2710, 2720, and 2730). Based on this evaluation, base station 222 and MNs 310-1 and 310-2 can wait to receive a management CCF indicator or send a management CCF indicator to each other. This determination can be standardized or left to each manufacturer's own decision metric. Each entity receiving a management CCF indicator can determine whether to reject or confirm the management CCF indicator. This can include each entity (e.g., MN 310, base station 222, etc.) comparing the information in the management CCF indicator with similar information of the receiving entity to determine whether the receiving entity is more suitable to operate as the management CCF. When an entity receives multiple management CCF indicators, the entity can compare the information from each of the management CCF indicators and use the similar information of the receiving entity to determine which entity is most suitable to operate as the management CCF. In response to this evaluation, each entity can store the CCF ID of its management CCF or the CCF ID of any of its supporting CCFs (i.e., when acting as the management CCF). The management CCF can store the CCF IDs of all CCFs (i.e., supporting CCFs) that have indicated that the management CCF is configured as their management CCF.

[0102] In some embodiments, the base station 222 may determine that the base station 222 will be the managing CCF and may convey a managing CCF indication message (at 2740) to the MNs 310-1 and 310-2. In this embodiment, the managing CCF indication message may include a CCF ID associated with the CCF of the base station 222. Doing so may notify the MNs 310-1 and 310-2 that the CCF of the base station 222 is the managing CCF 430-1 for decentralized distributed computing between the sub-networks 2150-1 and 2150-2. In some embodiments, the MNs 310-1 and 310-2 may respond to the managing CCF indication message from the base station 222 by sending a managing CCF response message (at 2750). The managing CCF response message may include an indication of the CCF ID and an indication of whether the CCF of the CCF ID is accepted or rejected as the managing CCF for decentralized distributed computing between the sub-networks 2150-1 and 2150-2. As shown, the result of these managing CCF response messages may include the MN 310-1 or the MN 310-2 becoming the managing CCF 430-1 (e.g., instead of the CCF of the base station 222 becoming the managing CCF 430-1) (at 2760).

[0103] Figures 28 - 29 is a diagram of an example of process 2800 for decentralized distributed computing between sub-networks according to one or more embodiments described herein. Process 2800 may be implemented by the base station 222, and the MNs 310-1 and 310-2 of the sub-networks 2150-1 and 2150-2. As shown, the MNs 310-1 and 310-2 may include CCFs. In some embodiments, some or all of process 2800 may be performed by one or more other systems or devices (including Figure 2 one or more of the devices). Additionally, process 2800 may include one or more operations fewer than, additional to, differently ordered than, and / or arranged differently than those shown in Figures 28 - 29 In some embodiments, some or all of the operations of process 2800 may be performed independently of, sequentially with, simultaneously with, etc., one or more of the other operations of process 2800. Thus, the techniques described herein are not limited to Figures 28 - 29 the number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0104] As shown, example 2800 may include the sub-network 2150-1, the MN 310-1, the base station 222, the sub-network 2150-2, and the MN 310-2. The sub-networks 2150-1 and 2150-2 may include more devices and nodes, such as Figure 28As shown. In Phase 1, MN310-1 and 310-2 can communicate with a local UE 210 (not shown) to create subnets 2150-1 and 2150-2. Thus, subnets 2150-1 and 2150-2 can include multiple local nodes such as smart phones, laptops, wearable devices (e.g., wireless necklaces, watches, etc.) and / or one or more other types of UE 210. MN 310-1 and 310-2 can generate and convey control plane and user plane information to create subnets and enable decentralized distributed computing within subnets 2150-1 and 2150-2. MN 310-1 and 310-2 can use various frequency ranges to communicate with other UE 210, including high-frequency spectral bands (e.g., frequencies in the terahertz (THz) band (e.g., frequencies between 0.3 THz and 3.0 THz)). In some specific implementations, base station 222 can be replaced by another subnet similar to subnets 2150-1 and 2150-2, and can undergo Phase 2 subnet creation in a similar manner.

[0105] In Phase 2, MN 310-1 and 310-2 can communicate with base station 222 to register subnets 2150-1 and 2150-2 with base station 222. Creating subnets 2150-1 and 2150-2 can enable decentralized distributed computing between UE 210 in subnets 2150-1 and 2150-2, and in Phase 3, re-registering the subnets with base station 222 can enable decentralized distributed computing between UE 210 in different subnets 2150-1 and 2150-2 via base station 222. In some specific implementations, UE 210 in different subnets 2150-1 and 2150-2 can directly participate in decentralized distributed computing (e.g., without base station 222 acting as an information relay or intermediary).

[0106] Phase 2 can be a mandatory or optional step, depending on the scenario or specific implementation. For example, when accessing the computing resources of another subnet via base station 222, Step 2 can be mandatory. Although the CCF of base station 222 may not be triggered, the communication of base station 222 can be utilized such that subnets 2150-1 and 2150-2 and 2150-2 can be registered via Step 2. When accessing the computing resources of another subnet via directed MN-to-MN communication, Phase 2 can be optional because MN 310-1 and 310-2 of subnets 2150-1 and 2150-2 can communicate without using base station 222.

[0107] Procedure 2800 can include a method for CCF negotiation, where CCF status updates can be sent as a response to an explicit request (e.g., a CCF status request), rather than being periodic or event-triggered.

[0108] Process 2800 may include an example of CCF negotiation to enable decentralized distributed computing between different sub-networks 2150-1 and 2150-2. This may be common for some or all decentralized computing offloading scenarios, where different available CCF entities negotiate with each other to decide which of the involved CCFs will play the role of the managing CCF, while the remaining ones act as supporting CCFs. MN 310-2 may send a CCF status request (at 2830) to base station 222. The CCF status request may include the CCF ID of the CCF of MN 310-2. The CCF status update may also or alternatively include battery level, sub-network computing requests, Rx signal strength, etc. The request may proxy as a request for the target CCF of base station 222 to operate as the managing CCF of MN 310-2. Base station 222 may send a CCF status request (at 2840) to MN 310-1. The CCF status request may include the CCF ID of the CCF of base station 222. The CCF status update may also or alternatively include battery level, sub-network computing requests, Rx signal strength, etc. The request may proxy as a request for the target CCF of MN 310-1 to operate as the managing CCF of base station 222.

[0109] Base station 222 may send a CCF status update (at 2850) to MN 310-1. The CCF status update may include the CCF ID of the CCF of base station 222 (not shown). The CCF status update may also or alternatively include battery level, base station computing capacity, base station computing requests, Rx signal strength, etc. The CCF status update may include an acknowledgement that base station 222 may operate as the managing CCF of a supporting CCF with the CCF ID of sub-network 2150-2. Thus, base station 222 may operate as the managing CCF of a supporting CCF with the CCF ID of sub-network 2150-2, and MN 310-2 may register the managing CCF with the CCF ID of the CCF of base station 222.

[0110] See Figure 29 , process 2800 may include MN 310-1 sending a CCF status update (at 2910) to base station 222. The CCF status update may include the CCF ID of the CCF of MN 310-1. The CCF status update may also or alternatively include the battery level of MN 310-1, sub-network computing capacity, sub-network computing requests, Rx signal strength, etc. regarding MN310-1 and / or sub-network 2150-1. The CCF status update may also include a rejection response regarding base station 222 operating as the managing CCF to MN 310-1 and / or sub-network 2150-1.

[0111] The MN 310-1 may send a CCF status request (at 2920) to the base station. The CCF status request may include the CCF ID of the CCF of the MN 310-1. The CCF status update may also or alternatively include the battery level, sub-network computing capacity, sub-network computing request, Rx signal strength, etc. of the MN 310-1. The base station 222 may respond by sending a CCF status update to the MN 310-2 (at 2930). The CCF status update may include the CCF ID of the CCF of the base station 222. The CCF status update may also or alternatively include the battery level, computing capacity, computing request, Rx signal strength, etc. of the base station 222 with respect to the base station 222.

[0112] The CCF status update may also include an acknowledgement response regarding the base station 222 that manages the CCF operations of the MN 310-1 and / or the sub-network 2150-1. Thus, the base station 222 may operate as a management CCF with the CCF ID of the base station 222, and the base station 222 may operate as a management CCF that supports the CCFs of the sub-networks 2150-1 and 215-2. In this way, Figures 28 - 29 Examples may include a request-based method for CCF negotiation, where the CCF status update is sent as a response to an explicit request (specifically, a CCF status request), rather than being periodic or event-triggered. When the response = acknowledgement, the responding CCF may act as the management CCF of the requesting CCF. When the response = rejection, the requesting CCF may have to request from another CCF by sending another CCF status request message.

[0113] Generally, the CCF status request message may indicate the computing capacity, requests, and Rx signal strength of the node, as well as other parameters. The request may also proxy as a request to the target CCF to act as a management CCF. In response to the request, the node may respond with a CCF status update message, which may include the computing capacity, requests, and Rx signal strength, as well as other parameters, and may also include a response message that acknowledges or rejects the request. When the response = acknowledgement, the responding CCF may then operate as the management CCF of the requesting CCF. When the response = rejection, the CCF that issued the request will request from another CCF by sending another CCF status request message (e.g., highlighted by message exchange in the sub-network 2150-1 in the MSC). For example, when the response = rejection, the requesting CCF may request from another CCF by sending another CCF status request message. In Figure 29In this case, MN 310-1 can send a CCF status update message to base station 222, where the response = reject (at 2910), and MN 310-1 can also send a CCF status request message to base station 222 (at 2920), and as a response, can wait for a CCF status update message 2930 from base station 222. This procedure can then be for all MN 310s, UEs 210, and base station 222 to decide on managing the CCF and supporting CCF roles. In some scenarios, this negotiation option is viable regardless of whether a direct physical connection between sub-networks is possible. However, for non-physical connections, there may be a consensus among the devices on certain aspects of the communication to be established (e.g., IP address, application, etc.) to allow such non-physical direct communication.

[0114] Figures 30 - 31 is a diagram of an example of process 3000 for decentralized distributed computing between sub-networks according to one or more specific implementations described herein. As shown, process 3000 can include sub-network 2150-1, MN310-1, base station 222, sub-network 2150-2, and MN 310-2. Sub-networks 2150-1 and 2150-2 can include more devices and nodes, as Figure 30 shown. In phase 1, MN 310-1 and 310-2 can communicate with local UEs 210 (not shown) to create sub-networks 2150-1 and 2150-2. Thus, sub-networks 2150-1 and 2150-2 can include multiple local nodes, such as smart phones, laptops, wearable devices (e.g., wireless necklaces, watches, etc.) and / or one or more other types of UEs 210. MN 310-1 and 310-2 can generate and convey control plane and user plane information to create sub-networks and enable decentralized distributed computing within sub-networks 2150-1 and 2150-2. MN 310-1 and 310-2 can use various frequency ranges to communicate with other UEs 210, including high frequency spectral bands (e.g., frequencies in the terahertz (THz) band (e.g., frequencies between 0.3 THz and 3.0 THz)).

[0115] In Phase 2, MNs 310-1 and 310-2 can communicate with base station 222 to register subnets 2150-1 and 2150-2 with base station 222. Creating subnets 2150-1 and 2150-2 enables decentralized distributed computing among UEs 210 of subnets 2150-1 and 2150-2, and in Phase 3, re-registering the subnets with base station 222 enables decentralized distributed computing among UEs 210 of different subnets 2150-1 and 2150-2 via base station 222. In some specific implementations, UEs 210 of different subnets 2150-1 and 2150-2 can directly participate in decentralized distributed computing (e.g., without base station 222 acting as an information relay or intermediary).

[0116] Phase 2 can be a mandatory or optional step, depending on the scenario or specific implementation. For example, when accessing the computing resources of another subnet via base station 222, Step 2 can be mandatory. Although the CCF of base station 222 may not be triggered, the communication of base station 222 can be utilized such that subnets 2150-1 and 2150-2 and 2150-2 can be registered via Step 2. When accessing the computing resources of another subnet via directed MN-to-MN communication, Phase 2 can be optional because MNs 310-1 and 310-2 of subnets 2150-1 and 2150-2 can communicate without using base station 222.

[0117] Example 3000 can include examples that support the CCF being in a non-transparent (e.g., MN 310-2) or transparent mode. (e.g., MN310-1). As shown, the CCF in the transparent mode (e.g., MN 310-1) may not evaluate the required computing tasks and available computing resources within the local subnet, regardless of whether some computing tasks can be locally executed (at 3020). The CCF in the non-transparent mode (e.g., MN 310-2) can evaluate the required computing tasks and available computing resources within the local subnet and decide which tasks can be locally offloaded (at 3030). The CCF in the transparent mode (e.g., MN 310-1) can issue a request for all subnet computing tasks and computing capabilities to the management CCN (e.g., base station 222) (at Figure 31 3110). In contrast, the CCF in the non-transparent mode (e.g., MN 310-2) can issue a request for excess subnet computing tasks or capabilities (i.e., after aggregating all local subnet 2150-2 computing tasks and capabilities and calculating the excess or deficiency), and this request cannot be processed by the local subnet (at Figure 31at 3110). The management CCF (e.g., base station 222) can then take full control (e.g., full management CCF control) of the distribution of the computing offloading process among all available computing resources.

[0118] Figure 32 is a diagram of an example of components of a device according to one or more specific implementations described herein. In some specific implementations, device 3200 may include application circuitry 3202, baseband circuitry 3204, RF circuitry 3206, front-end module (FEM) circuitry 3208, one or more antennas 3210, and power management circuitry (PMC) 3212 (coupled together as shown at least). In some specific implementations, device 3200 may include fewer components (e.g., a RAN node may not utilize application circuitry 3202 but may include a processor / controller to process data received from the core network). In some specific implementations, device 3200 may include additional components such as, for example, memory / storage, a display, a camera, sensors (including one or more temperature sensors, such as a single temperature sensor, multiple temperature sensors at different locations in device 3200, etc.), or input / output (I / O) interfaces. In other specific implementations, the following components may be included in more than one device (e.g., these circuits may be included separately in more than one device for cloud-RAN (C-RAN) implementations).

[0119] The application circuitry 3202 may include one or more application processors. For example, the application circuitry 3202 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled to the memory / storage or may include the memory / storage and may be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on device 3200. In some specific implementations, the processors of the application circuitry 3202 may process data packets received from the core network.

[0120] The baseband circuit 3204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuit 3204 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of the RF circuit 3206 and to generate baseband signals for the transmit signal path of the RF circuit 3206. The baseband processing circuit 3204 may interact with the application circuit 3202 to generate and process baseband signals and to control the operation of the RF circuit 3206. For example, in some embodiments, the baseband circuit 3204 may include a 3G baseband processor 3204A, a 4G baseband processor 3204B, a 5G baseband processor 3204C, or other baseband processors 3204D for other existing generations, generations under development, or generations to be developed in the future (e.g., 5G, 6G, 7G, etc.). The baseband circuit 3204 (e.g., one or more of the baseband processors 3204A-D) may process various radio control functions that enable communication with one or more radio networks via the RF circuit 3206. In other embodiments, some or all of the functions of the baseband processors 3204A-D may be included in modules stored in the memory 3204G and executed via the central processing unit (CPU) 3204E. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuitry of the baseband circuit 3204 may include fast Fourier transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the baseband circuit 3204 may include convolutional, tail-biting convolutional, turbo, Viterbi, or low density parity check (LDPC) encoder / decoder functions. The embodiments of the modulation / demodulation and encoder / decoder functions are not limited to these examples and may include other suitable functions in other aspects.

[0121] In some embodiments, the memory 3204G may receive and / or store information and instructions for decentralized distributed computing within a wireless environment. A group of local wireless devices (e.g., UE 210) may form a subnetwork with each other. The UE 210 may support various functions to enable computing tasks to be offloaded from some subnetwork devices and executed by other subnetwork devices. The results generated by executing the tasks may be returned to the device that offloaded the task. The MN 310 of the subnetwork may be connected to the base station 222 and / or directly connected to the MN 310 of another subnetwork. Computing tasks may be offloaded from a subnetwork, executed by another subnetwork or network device (such as the base station 222 or network server), and the results of the executed tasks may be returned to the subnetwork that offloaded the task. These and many other features and techniques are described in detail herein.

[0122] In some specific implementations, the baseband circuit 3204 may include one or more audio digital signal processors (DSPs) 3204F. The audio DSP 3204F may include elements for compression / decompression and echo cancellation, and in other specific implementations may include other suitable processing elements. In some specific implementations, the components of the baseband circuit 3204 may be appropriately combined on a single chip, a single chipset, or disposed on the same circuit board. In some specific implementations, some or all of the component parts of the baseband circuit 3204 and the application circuit 3202 may be implemented together, such as, for example, on a system-on-chip (SOC).

[0123] In some specific implementations, the baseband circuit 3204 may provide communication compatible with one or more radio technologies. For example, in some specific implementations, the baseband circuit 3204 may support communication with NG-RAN, evolved universal terrestrial radio access network (EUTRAN), or other wireless metropolitan area network (WMAN), wireless local area network (WLAN), wireless personal area network (WPAN), etc. Specific implementations in which the baseband circuit 3204 is configured to support radio communication for more than one wireless protocol may be referred to as multimode baseband circuits.

[0124] The RF circuit 3206 may enable communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various specific implementations, the RF circuit 3206 may include switches, filters, amplifiers, etc. to facilitate communication with the wireless network. The RF circuit 3206 may include a receive signal path, which may include circuitry for down-converting the RF signal received from the FEM circuit 3208 and providing the baseband signal to the baseband circuit 3204. The RF circuit 3206 may also include a transmit signal path, which may include circuitry for up-converting the baseband signal provided by the baseband circuit 3204 and providing the RF output signal to the FEM circuit 3208 for transmission.

[0125] In some specific embodiments, the receive signal path of the RF circuit 3206 may include a mixer circuit 3206A, an amplifier circuit 3206B, and a filter circuit 3206C. In some specific embodiments, the transmit signal path of the RF circuit 3206 may include a filter circuit 3206C and a mixer circuit 3206A. The RF circuit 3206 may further include a synthesizer circuit 3206D for synthesizing the frequencies used by the mixer circuits 3206A of the receive signal path and the transmit signal path. In some specific embodiments, the mixer circuit 3206A of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 3208 based on the synthesized frequency provided by the synthesizer circuit 3206D. The amplifier circuit 3206B may be configured to amplify the down-converted signal, and the filter circuit 3206C may be a low-pass filter (LPF) or a band-pass filter (BPF), which is configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to the baseband circuit 3204 for further processing. In some specific embodiments, the output baseband signal may be a zero-frequency baseband signal, but this may not be necessary. In some specific embodiments, the mixer circuit 3206A of the receive signal path may include a passive mixer, but the scope of specific embodiments is not limited in this regard.

[0126] In some specific embodiments, the mixer circuit 3206A of the transmit signal path may be configured to up-convert the input baseband signal based on the synthesized frequency provided by the synthesizer circuit 3206D to generate an RF output signal for the FEM circuit 3208. The baseband signal may be provided by the baseband circuit 3204 and may be filtered by the filter circuit 3206C. In some specific embodiments, the mixer circuit 3206A of the receive signal path and the mixer circuit 3206A of the transmit signal path may include two or more mixers and may be arranged respectively for quadrature down-conversion and up-conversion. In some specific embodiments, the mixer circuit 3206A of the receive signal path and the mixer circuit 3206A of the transmit signal path may include two or more mixers and may be arranged for image rejection. In some specific embodiments, the mixer circuit 3206A of the receive signal path and the mixer circuit 3206A may be arranged respectively for direct down-conversion and direct up-conversion. In some specific embodiments, the mixer circuit 3206 of the receive signal path and the mixer circuit 3206A of the transmit signal path may be configured for superheterodyne operation.

[0127] In some specific implementations, the output baseband signal and the input baseband signal can be analog baseband signals, although the scope of the specific implementations is not limited in this regard. In some alternative specific implementations, the output baseband signal and the input baseband signal can be digital baseband signals. In these alternative specific implementations, the RF circuit 3206 can include an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) circuit, and the baseband circuit 3204 can include a digital baseband interface for communicating with the RF circuit 3206.

[0128] In some dual-mode specific implementations, separate radio integrated circuits can be provided to process the signals of each spectrum, but the scope of the specific implementations is not limited in this regard. In some specific implementations, the synthesizer circuit 3206D can be a fractional-N synthesizer or a fractional N / N+1 synthesizer, but the scope of the specific implementations is not limited in this regard, as other types of frequency synthesizers can also be suitable. For example, the synthesizer circuit 3206D can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0129] The synthesizer circuit 3206D of the RF circuit 3206 can be configured to synthesize an output frequency based on a frequency input and a frequency divider control input for use by the mixer circuit 3206A of the RF circuit 3206. In some specific implementations, the synthesizer circuit 3206D can be a fractional N / N+1 synthesizer. In some specific implementations, the frequency input can be provided by a voltage-controlled oscillator (VCO). The frequency divider control input can be provided by the baseband circuit 3204 or the application processor 3202 according to the desired output frequency. In some specific implementations, the frequency divider control input (e.g., N) can be determined from a look-up table based on the channel indicated by the application circuit 3202.

[0130] The synthesizer circuit 3206D of the RF circuit 3206 can include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some specific implementations, the frequency divider can be a dual-mode frequency divider (DMD), and the phase accumulator can be a digital phase accumulator (DPA). In some specific implementations, the DMD can be configured to divide an input signal by N or N+1 (e.g., based on a carry output) to provide a fractional division ratio. In some exemplary specific implementations, the DLL can include a cascaded, tunable, delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these specific implementations, the delay element can be configured to divide the VCO period into Nd equal phase bins, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO period.

[0131] In some specific implementations, the synthesizer circuit 3206D may be configured to generate a carrier frequency as the output frequency, while in other specific implementations, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and may be used in conjunction with an orthogonal generator and a frequency divider circuit to generate multiple signals having multiple different phases relative to each other at that carrier frequency. In some specific implementations, the output frequency may be the LO frequency (fLO). In some specific implementations, the RF circuit 3206 may include an in-phase / quadrature (I / Q) / polarity converter.

[0132] The FEM circuit 3208 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 3210, amplify the received signals, and provide an amplified version of the received signals to the RF circuit 3206 for further processing. The FEM circuit 3208 may also include a transmit signal path, which may include circuitry configured to amplify transmit signals provided by the RF circuit 3206 for transmission via one or more of the one or more antennas 3210. In various specific implementations, the amplification performed via the transmit signal path or the receive signal path may be done only in the RF circuit 3206, only in the FEM circuit 3208, or in both the RF circuit 3206 and the FEM circuit 3208.

[0133] In some specific implementations, the FEM circuit 3208 may include a transmit / receive switch to switch between transmit mode and receive mode operations. The FEM circuit 3208 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit 3208 may include a low-noise amplifier to amplify the received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuit 3206). The transmit signal path of the FEM circuit 3208 may include a power amplifier to amplify an input RF signal (e.g., provided by the RF circuit 3206); and one or more filters to generate RF signals for subsequent transmission (e.g., via one or more of the one or more antennas 3210).

[0134] In some specific implementations, the PMC 3212 may manage the power provided to the baseband circuit 3204. Specifically, the PMC 3212 may control power selection, voltage scaling, battery charging, or direct current (DC) to DC (DC-to-DC) conversion. When the device 3200 is capable of being powered by a battery, e.g., when the device 3200 is included in a UE, the PMC 3212 is typically included. The PMC 3212 may improve power conversion efficiency while providing the desired specific implementation size and thermal characteristics.

[0135] whereas Figure 32 shows PMC 3212 coupled only to baseband circuitry 3204. However, in other embodiments, PMC 3212 may additionally or alternatively be coupled to other components such as, but not limited to, application circuitry 3202, RF circuitry 3206, or FEM circuitry 3208, and perform similar power management operations.

[0136] In some embodiments, PMC 3212 may control or otherwise be part of various power saving mechanisms of device 3200. For example, if device 3200 is in the RRC_Connected state, where device 3200 remains connected to a RAN node because device 3200 expects to receive traffic immediately, then after a period of inactivity, device 3200 may enter a state known as discontinuous reception mode (DRX). During this state, device 3200 may power down for short intervals, thereby saving power.

[0137] If there is no data traffic activity for an extended period, device 3200 may transition to the RRC_Idle state, in which device 3200 disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. Device 3200 may enter a very low power state, and device 3200 may perform paging, where device 3200 may wake up periodically again to listen for the network, and then power down again. Device 3200 may not receive data while in this state; to receive data, device 3200 may transition back to the RRC_Connected state.

[0138] Additional power saving modes may cause device 3200 to be unavailable to the network for a time period exceeding the paging interval (ranging from a few seconds to several hours). During this time, device 3200 may not be able to connect to the network and may power down completely. Any data transmitted during this time may incur significant latency, and device 3200 may assume the latency is acceptable.

[0139] The processors of application circuitry 3202 and baseband circuitry 3204 may be used to execute elements of one or more instances of a protocol stack. For example, the processor of baseband circuitry 3204 may be used, alone or in combination, to perform functions of layer 3, layer 2, or layer 1, while the processor of baseband circuitry 3204 may utilize data received from these layers (e.g., packet data) and further perform functions of layer 4 (e.g., transport control protocol (TCP) and user datagram protocol (UDP) layers). As mentioned herein, layer 3 may include a radio resource control layer. As mentioned herein, layer 2 may include a media access control layer, a radio link control layer, and a packet data convergence protocol layer, which will be described in further detail below. As mentioned herein, layer 1 may include the physical layer of the UE / RAN node.

[0140] Figure 33 is a block diagram illustrating components capable of reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein. Specifically, Figure 33 illustrates a schematic diagram of hardware resources 3300, including one or more processors (or processor cores) 3310, one or more memory / storage devices 3320, and one or more communication resources 3330, each of which may be communicatively coupled via a bus 3340. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 3300.

[0141] The processor 3310 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) (such as a baseband processor), an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 3312 and processor 3314.

[0142] The memory / storage device 3320 may include a main memory, a disk memory, or any suitable combination thereof. The memory / storage device 3320 may include, but is not limited to, any type of volatile or non-volatile memory, such as 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 storage devices, etc.

[0143] In some embodiments, the memory / storage device 3320 may receive and / or store information and instructions 3355 for decentralized distributed computing within a wireless environment. A group of local wireless devices (e.g., UE 210) may form a sub-network with each other. The UE 210 may support various functions such that computing tasks can be offloaded from some sub-network devices and executed by other sub-network devices. Results generated by performing the tasks may be returned to the device that offloaded the task. The MN310 of the sub-network may be connected to the base station 222 and / or directly connected to the MN 310 of another sub-network. Computing tasks may be offloaded from a sub-network, executed by another sub-network or a network device (such as the base station 222 or a network server), and the results of the executed tasks may be returned to the sub-network that offloaded the task. These and many other features and techniques are described in detail herein.

[0144] The communication resource 3330 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 3304 or one or more databases 3306 via a network 3308. For example, the communication resource 3330 may include a wired communication component (e.g., for coupling via a Universal Serial Bus (USB)), a cellular communication component, an NFC component, a component (e.g., low power consumption), a component, and other communication components.

[0145] The instructions 3350 may include software, programs, applications, applets, application programs, or other executable code for causing at least any one of the processors 3310 to execute any one or more of the methods discussed herein. The instructions 3350 may reside entirely or partially within the processor 3310 (e.g., within the cache memory of the processor), within at least one of the memory / storage devices 3320, or in any suitable combination thereof. Additionally, any portion of the instructions 3350 may be transmitted from any combination of the peripheral devices 3304 or the database 1506 to the hardware resource 3300. Thus, the memory of the processor 1310, the memory / storage device 1520, the peripheral device 1504, and the database 1506 are examples of computer-readable and machine-readable media.

[0146] Figure 34 is a diagram of a process 3400 for decentralized distributed computing according to one or more specific implementations described herein. The process 3400 may be implemented by the UE 210. In some specific implementations, some or all of the process 3400 may be performed by one or more other systems or devices (including Figure 2 one or more of the devices of Figure 34 ). Additionally, the process 3400 may include one or more operations that are fewer than, additional to, differently ordered than, and / or arranged differently than those shown in Figure 34 . In some specific implementations, some or all of the operations of the process 3400 may be performed independently of, sequentially with, simultaneously with, etc., one or more of the other operations of the process 3400. Thus, the techniques described herein are not limited to

[0147] the number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0148] Figure 35 is a diagram of process 3500 for decentralized distributed computing according to one or more specific embodiments described herein. Process 3500 may be implemented by UE 210. In some specific embodiments, some or all of process 3500 may be performed by one or more other systems or devices, including Figure 2 one or more of the devices of). Additionally, process 3500 may include one or more operations that are fewer, additional, differently ordered, and / or arranged than those shown in Figure 35 . In some specific embodiments, some or all of the operations of process 3400 may be performed independently of, sequentially with, simultaneously with, etc., one or more of the other operations of process 3500. Accordingly, the techniques described herein are not limited to Figure 35 the number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0149] Process 3500 may include receiving a Compute Offloading Control Function (CCF) status update from MN 310 (block 3510). Process 3500 may include evaluating MN 310 based on the CCF status update (block 3520). Process 3500 may include receiving a management CCF indication from MN 310 (block 3530). Process 3500 may include communicating a management CCF response to the base station, the management CCF response indicating the base station's confirmation as the management CCF of the UE's subnetwork (block 3540).

[0150] Figure 36 is a diagram of process 3600 for decentralized distributed computing according to one or more specific embodiments described herein. Process 3600 may be implemented by base station 222. In some specific embodiments, some or all of process 3600 may be performed by one or more other systems or devices, including Figure 2 one or more of the devices of). Additionally, process 3600 may include one or more operations that are fewer, additional, differently ordered, and / or arranged than those shown in Figure 36 . In some specific embodiments, some or all of the operations of process 3600 may be performed independently of, sequentially with, simultaneously with, etc., one or more of the other operations of process 3600. Accordingly, the techniques described herein are not limited to Figure 36 the number, sequence, arrangement, timing, etc. of the operations or processes depicted.

[0151] Process 3600 may include sending a CCF status update to compute the offloading control function (CCF) of multiple sub-networks (block 3610). Process 3600 may include receiving a CCF status update from the CCFs of multiple sub-networks (block 3620). Process 3600 may include evaluating a base station based on the CCF status update (block 3630). Process 3600 may include communicating an administrative CCF instruction to the CCF (block 3640). Process 3600 may include receiving an administrative CCF response from at least one of the CCFs of multiple sub-networks, the administrative CCF response indicating confirmation of the base station as the administrative CCF of at least one sub-network (block 3650).

[0152] Embodiments and / or specific implementations herein may include subject matter such as a method, components for performing actions or blocks of the method, at least one machine-readable medium including executable instructions that, when executed by a machine (e.g., a processor with a memory, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), cause the machine to perform actions of a method or apparatus or system for concurrent communication using multiple communication technologies according to the specific implementations and embodiments described.

[0153] In Embodiment 1, which may also include one or more of the embodiments described herein, a user equipment (UE) may include: a memory; and one or more processors configured to cause the UE, when executing instructions stored in the memory, to: receive, by an offloading function (OF) of the UE, computing capacity originating from a computing function (CF); communicate a computing offloading request for a computing task to the CF; and receive a computing offloading response from the CF including an acknowledgement or rejection response for the requested computing task.

[0154] In Embodiment 2, which may also include one or more of the embodiments described herein, the computing capacity is received via a computing offloading control function (CCF).

[0155] In Embodiment 3, which may also include one or more of the embodiments described herein, the computing offloading request is communicated to the CF via an update of computing requirements including the CCF.

[0156] In Embodiment 4, which may also include one or more of the embodiments described herein, the computing offloading request includes a CF identification (ID) associated with the CF.

[0157] In Embodiment 5, which may also include one or more of the embodiments described herein, the result of the computing task is received by the OF from the CF.

[0158] In Embodiment 6, which may also include one or more of the embodiments described herein, computing capabilities are received in response to communicating a computing capabilities status request to the CF and receiving a computing capabilities update in response thereto.

[0159] In Embodiment 7, which may also include one or more of the embodiments described herein, the UE is configured to operate as a management CCF in response to receiving a management CCF indication.

[0160] In Embodiment 8, which may also include one or more of the embodiments described herein, the UE is configured to operate as a supporting CCF in response to receiving a supporting CCF indication.

[0161] In Embodiment 9, which may also include one or more of the embodiments described herein, the UE is configured to confirm a management CCF indication received from the CF.

[0162] In Embodiment 10, which may also include one or more of the embodiments described herein, the UE is configured to communicate a CCF status request to the CF and receive a CCF status update in response thereto.

[0163] In Embodiment 11, which may also include one or more of the embodiments described herein, the UE is a low-capacity (LC) node of a subnetwork, and the CF corresponds to a high-capacity (HC) node of the subnetwork, and the subnetwork is managed by a management node (MN).

[0164] In Embodiment 12, which may also include one or more of the embodiments described herein, a user equipment (UE) includes: a memory; and one or more processors configured to cause the UE, when executing instructions stored in the memory, to: receive a computing offloading control function (CCF) status update from a management node (MN); evaluate the MN based on the CCF status update; receive a management CCF indication from the MN; and communicate a management CCF response to the MN, the management CCF response indicating confirmation of the MN as the management CCF of the UE's subnetwork.

[0165] In Embodiment 13, which may also include one or more of the embodiments described herein, the UE is configured to communicate a CCF status update to the MN and receive a CCF status update in response thereto.

[0166] In Embodiment 14, which may also include one or more of the embodiments described herein, the UE is configured to communicate a CCF status request to the MN and receive a CCF status update in response thereto.

[0167] In Embodiment 15, which may also include one or more of the embodiments described herein, the management CCF is configured to implement decentralized distributed computing between the sub-network of the UE and another sub-network via the management CCF of the MN.

[0168] In Embodiment 16, which may also include one or more of the embodiments described herein, a base station includes: a memory; and one or more processors configured to cause the UE to: send a CCF status update to a computing offloading control function (CCF) of a plurality of sub-networks; receive a CCF status update from the CCFs of the plurality of sub-networks; evaluate the base station based on the CCF status update; convey a management CCF indication to the CCF; and receive a management CCF response from at least one of the CCFs of the plurality of sub-networks, the management CCF response indicating confirmation of the base station as the management CCF of at least one sub-network when executing instructions stored in the memory.

[0169] In Embodiment 17, which may also include one or more of the embodiments described herein, the base station is configured to receive at least one management CCF response that indicates rejection of the base station as the management CCF.

[0170] In Embodiment 18, which may also include one or more of the embodiments described herein, the base station is configured to operate as the management CCF for at least one of the CCFs of a plurality of sub-networks.

[0171] In Embodiment 19, which may also include one or more of the embodiments described herein, the CCF status update from the CCFs of the plurality of sub-networks includes a CCF status request.

[0172] In Embodiment 20, which may also include one or more of the embodiments described herein, the management CCF is configured to enable decentralized distributed computing between a plurality of sub-networks.

[0173] In Embodiment 21, which may also include one or more of the embodiments described herein, a method includes operations according to one or more of the embodiments described herein.

[0174] In Embodiment 22, which may also include one or more of the embodiments described herein, a computer-readable medium includes one or more instructions that, when executed by one or more processors, cause the one or more processors to perform according to one or more of the embodiments described herein.

[0175] In Embodiment 23, which may also include one or more of the embodiments described herein, a baseband processor includes: a memory; and one or more processors configured to cause the baseband processor to perform in accordance with one or more of the embodiments described herein when executing instructions stored in the memory.

[0176] In Embodiment 24, which may also include one or more of the embodiments described herein, a method may include receiving a Compute Offloading Control Function (CCF) status update from a Management Node (MN); evaluating the MN based on the CCF status update; receiving a Manage CCF indication from the MN; and communicating a Manage CCF response to the MN, the Manage CCF response indicating an acknowledgement of the MN as the Manage CCF of the UE's subnetwork.

[0177] In Embodiment 25, which may also include one or more of the embodiments described herein, a method may include communicating a CCF status update to the MN and receiving, in response thereto, a CCF status update.

[0178] In Embodiment 26, which may also include one or more of the embodiments described herein, a method may include communicating a CCF status request to the MN and receiving, in response thereto, a CCF status update.

[0179] In Embodiment 27, which may also include one or more of the embodiments described herein, decentralized distributed computing is implemented between the UE's subnetwork and another subnetwork via the Manage CCF of the MN.

[0180] The embodiments discussed above also extend to method, computer-readable media, and apparatus plus function claims and specific implementations, which may include one or more of the features or operations of any one or combination of the embodiments mentioned above.

[0181] The above description of the exemplary examples, specific implementations, aspects, etc. of the subject matter of the present disclosure, which includes what is described in the abstract of the specification, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. While specific examples, specific implementations, aspects, etc. are described herein for illustrative purposes, various modifications can be contemplated within the scope of such examples, specific implementations, aspects, etc., as will be recognized by those skilled in the relevant art.

[0182] In this regard, while the subject matter of the present disclosure has been described in connection with various examples, specific implementations, aspects, etc. and the corresponding drawings, it should be understood that, where applicable, other similar aspects may be used or modifications and additions may be made to the disclosed subject matter to perform the same, similar, alternative, or substitute functions of the subject matter without departing from the disclosed subject matter. Accordingly, the disclosed subject matter should not be limited to any single example, specific implementation, or aspect described herein, but should be construed in accordance with the breadth and scope of the following appended claims.

[0183] Particularly with respect to the various functions performed by the above-described components or structures (assemblies, devices, circuits, systems, etc.), unless otherwise specified, the terms used to describe such components (including references to "means") are intended to correspond to any component or structure that performs the specified function of the component (e.g., functionally equivalent), even if not structurally equivalent to the disclosed structures that perform the functions in the exemplary specific implementations illustrated herein. Additionally, although a particular feature has been disclosed with respect to only one of several specific implementations, for any given application, such feature may be combined with one or more other features of one or more other specific implementations, which may be desirable and advantageous.

[0184] As used herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied in any of the foregoing instances. Additionally, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless otherwise specified or clearly apparent from the context to be in the singular form. Further, to the extent that the terms "comprising", "comprises", "having", "has", "with", or variants thereof are used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term "including". Additionally, in the case of discussing one or more numbered items (e.g., "first X", "second X", etc.), generally, the one or more numbered items may be different or they may be the same, but in some instances, the context may indicate that they are different or indicate that they are the same.

[0185] It is well known that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and disposed of to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1. A user equipment (UE), comprising: Memory; and one or more processors, wherein the one or more processors are configured to, when executing instructions stored in the memory, cause the UE to: receiving, by an offload function (OF) of the UE, computing power originating from a computing function (CF); Communicating a computation offloading request for a computation task to the CF; as well as A computation offloading response including a confirmation or rejection response to the computation task is received from the CF.

2. The UE of claim 1, wherein the computing capability is received via a computing offload control function (CCF).

3. The UE of claim 1, wherein the computation offload request is communicated to the CF via an update including a computation requirement of the CCF. 4 . The UE of claim 1 , wherein the computation offload request comprises a CF identification (ID) associated with the CF.

5. The UE of claim 1, wherein the result of the computing task is received by the OF from the CF.

6. The UE of claim 1, wherein the computing capability is received in response to communicating a computing capability status request to the CF and in response thereto receiving a computing capability update.

7. The UE of claim 1, wherein the UE is configured to operate as a managing CCF in response to receiving a managing CCF indication.

8. The UE of claim 1, wherein the UE is configured to operate as supporting CCF in response to receiving a supporting CCF indication.

9. The UE of claim 1, wherein the UE is configured to acknowledge a management CCF indication received from the CF.

10. The UE of claim 1, wherein the UE is configured to communicate a CCF status request to the CF and receive a CCF status update in response thereto.

11. The UE according to claim 1, wherein the UE is a low capacity (LC) node of a sub-network, and the CF corresponds to an HC node of the sub-network, and the sub-network is managed by a management node (MN).

12. A method performed by a user equipment (UE), comprising: receiving a computation offload control function (CCF) status update from a management node (MN); evaluating the MN based on the CCF status update; receiving a management CCF indication from the MN; and A managing CCF response is communicated to the MN, the managing CCF response indicating confirmation of the MN as the managing CCF of the subnetwork of the UE.

13. The method according to claim 12, further comprising: A CCF status update is communicated to the MN and the CCF status update is received in response thereto.

14. The method according to claim 12, further comprising: A CCF status request is communicated to the MN and the CCF status update is received in response thereto.

15. The method according to claim 12, wherein decentralized distributed computing is implemented between the subnetwork of the UE and another subnetwork via the management CCF of the MN.

16. A base station, comprising: Memory; and one or more processors, wherein the one or more processors are configured to, when executing instructions stored in the memory, cause the base station to: Send CCF status updates to calculate offload control functions (CCFs) for multiple subnetworks; receiving CCF status updates from the CCFs of the plurality of subnetworks; updating and evaluating the base station based on the CCF status; Communicate management CCF instructions to said CCF; as well as A managing CCF response is received from at least one of the CCFs of the plurality of sub-networks, the managing CCF response indicating confirmation of the base station as a managing CCF for at least one sub-network. 17 . The base station of claim 16 , wherein the base station is configured to receive at least one managing CCF response, the at least one managing CCF response indicating rejection of the base station as a managing CCF. 18 . The base station according to claim 16 , wherein the base station is configured to operate as the management CCF of the at least one CCF among the CCFs of the plurality of sub-networks.

19. The base station of claim 16, wherein the CCF status updates from the CCFs of the plurality of subnetworks comprise CCF status requests.

20. The base station of claim 16, wherein the management CCF is configured to implement decentralized distributed computing among the plurality of sub-networks.

Images