Distributed edge computing system and method

a method for distributed edge computing (DEC) includes obtaining a request from a computational resource provider (CRP) offering computational resources of the CRP; validating the computation resources of the CRP; offering the computation resources of the CRP to a computational resource consumer (CRC); obtaining a reservation request from the CRC for a portion of the computation resources of the CRP; and installing CRC software on the CRP for DEC, where the CRP is configured to receive produced data related to the CRC software from a first localized device, the computational resources process the produced data, and forward processed data to a second localized device that has requested the processed data.

RELATED APPLICATIONS

The present application is a National Phase of International Application No. PCT/US2022/016375 filed Feb. 15, 2022.

BACKGROUND

Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. The components interact with one another in order to achieve a common goal. Distributed computing also refers to the use of distributed systems to solve computational problems. In distributed computing, a problem is divided into many tasks, each of which is solved by one or more computers, which communicate with each other via message passing.

DETAILED DESCRIPTION

In some embodiments, a distributed edge computing system (DECS) is configured to flexibly pool computing resources across multiple distributed devices. In some embodiments, a DECS is configured to connect distributed devices that are both consumers and producers of data with other distributed devices that include available computing resources for both the data consumers and producers. In some embodiments, data producers provide and data consumers consume data respectively pursuant to instructions from a respective application. In some embodiments, a DECS distributed device (DECS-D) receives data from data producers. In some embodiments, the DECS-D processes the received data pursuant to instructions from the application with resources committed for DECS usage as instructed by the application. In some embodiments, the DECS-D sends the processed data to the consumers of the data as instructed by the application. In some embodiments, unused or offered computing capacity of a DECS-D is utilized pursuant to a dynamic requirement of the application. In some embodiments, a DECS management system (DECS-M) manages DECS-Ds to process information from data producers and send the processed data to the devices consuming the processed information based on instructions from respective applications. In some embodiments, the DECS-D is a mobile device located on the edge of a network that participates in a DECS processing resources program. In some embodiments, the edge of the network consists of data producers, data consumers, and DECS-Ds for processing the data produced and providing the data to the data consumers.

In a non-limiting example, one or more data producers, one or more data consumers, and one or more DECS-Ds are in a localized area. Continuing with the non-limiting example, a data consumer's vehicular system is searching for an up-to-date traffic situation. The vehicular system transmits a request to a DECS-D requesting an up-to-date traffic situation. Within the same localized area, multiple computing devices are generating the relevant traffic information. The DECS-D acquires the relevant traffic data from the computing devices and provides the up-to-date traffic situation to the vehicular system. Continuing with the non-limiting example, increased processing demand in the localized area encourages mobile device users in the localized area to participate in the DECS with their devices. Mobile device users on the edge of a network are able to designate their devices as a DECS-D and offering their mobile devices for data processing. In some embodiments, mobile device owners are able to enter into a contract offering a portion of the mobile device processing capacity for remuneration (e.g., by owners of applications). In some embodiments, the remuneration for the use of mobile device computing resources, makes the owners of the mobile devices more likely to contribute to a DECS system and provide more computing resources to the DECS. User devices (e.g., biometric devices, smartphones, laptops, and the like) are producers of data and consumers of the processed data.

In other approaches, processing of data occurs at respective servers associated with the user devices located distant from the servers. Based on requested data, processed data is exchanged across servers for processing and decision making. The data transfer, data processing and response times are low. However, distributed computing capacity of servers leads to a large inefficiency. Also, scaling-in and scaling-out is time and cost intensive as servers are added, moved, or removed. In these prior approaches, data and processing is completely distributed, but the resource pooling is poor, and the time required to scale is large.

In other approaches, such as cloud networking, data is transferred to a remote centralized location for processing. Thus, allowing the pooling of computational resources across multiple devices and users. Inefficient computing resource utilization is eliminated by the pooling of computing capacity through cloud computing. Data from respective consumers is pooled to the cloud network, processed, and distributed to the consumers. Pooled capacity across consumers and producers and faster scaling of resources are just some of the advantages of cloud networks. However, heavy data transfers across backhaul networks and latency due to the remote location of the processing resources are just some of the disadvantages of a cloud network.

Cloud computing is the on-demand availability of computer system resources, especially data storage (cloud storage) and computing power, without direct active management by the user. Large clouds often have functions distributed over multiple locations, each location being a data center.

In other approaches, such as a fog network, data consolidation and processing are brought closer to user. Pooling of computational resources is reduced with backhaul utilization, and latency is improved as the computational resources are closer to the user. Fog networks bring computing resources closer to the backhaul network to reduce latency. Fog networks optimize resource pooling and decrease backhaul utilization and latency. However, with the increase in industry demand for ever lower latency and higher data volume consumption; latency remains too high for consumers searching for a faster response. Further, fog networks increase the loading of access networks (a type of telecommunications network, such as a RAN, which connects subscribers to their immediate service provider).

Further known as fogging, fog computing facilitates the operation of computing, storage, and networking services between end devices and cloud computing data centers. While fog computing is typically referred to the location where services are instantiated, fog computing implies distribution of the communication, computation, storage resources, and services on or close to devices and systems in the control of end-users. Fog computing is a medium weight and intermediate level of computing power. Rather than a substitute, fog computing often serves as a complement to cloud computing.

In another suggested approach, edge clouds provide data consolidation and processing even closer to the user than fog networks (e.g., at the access network). Pooling of computational resources is further reduced and response time and backhaul utilization is further improved. Computing resources are brought even closer to the devices with an edge cloud. Nevertheless, edge clouds increase dependency on access network service providers. Increasing demands due to ultra-low latency applications, such as virtual reality (VR) (entertainment (particularly video games), education (such as medical or military training) and business (such as virtual meetings)), augmented reality (AR) (interactive experience of a real-world environment where the objects that reside in the real world are enhanced by computer-generated perceptual information, sometimes across multiple sensory modalities), vehicle-to-everything (V2X) (is communication between a vehicle and any entity that affects, or may be affected by, the vehicle), and the like, push for an even further reduction in latency and faster processing of resources.

Edge computing is a distributed computing paradigm that brings computation and data storage closer to the sources of data. This improves response times and saves bandwidth.

In other approaches, there is a balance between limited and rigid architectural solutions versus multiple and varying computational resource demands spread across different localities. Currently, no solution exists for processing that is handled locally outside the data producing devices. Other approaches, include inefficient infrastructure utilization due to limited pooling across computational resources. There currently exists no pooling at a distributed level. Cloud computing is limited at an enterprise level (e.g., something that's knowledge-intensive and a significant investment). These other approaches have overlooked direct communication among localized devices. This results in a lack of localization and higher demand on a transport network for exchanging data with a centralized infrastructure.

Currently, the most pervasive electronic devices are mobile devices. Current mobile device computer processing units (CPUs) provide computational resources (e.g., the number of CPUs, the speed of the CPUs, the random-access memory (RAM) storage, and the internal storage) that are quickly approaching the computational resources of data center CPUs within cloud networks. Current mobile handsets provide CPUs and memory that are able to handle most applications. Mobile device usage during lean hours is between 10% to 30% of a mobile device's peak dimensioned capacity (based on background applications operating). Thus, most devices have between 70% and 90% of computing capacity sitting unused. Further, when the mobile device owner is sleeping or resting even greater computing capacity sits unused.

User Devices, including mobile phones, laptops, local servers, and the like, are built for managing higher computing loads to manage occasional peaks in usage. However, the user device remains idle for substantial amounts of time. For example, mobile devices remain almost entirely idle during late-night hours.

In some embodiments, a move is suggested from hyper threading (HTT) to distributed threading. HTT is simultaneous multithreading (SMT) implementation used to improve parallelization of computations (doing multiple tasks at once) performed on microprocessors. Distributed threading is a system whose components are located on different networked computers (e.g., different mobile devices on a network), which communicate and coordinate actions by passing messages to one another from any system. The components interact with one another to achieve a common goal.

In some embodiments, several user devices are available with higher processing capabilities (processing, memory & storage) with unused computing power. In some embodiments, DECS fulfills application demands and in-turn incentivizes others (such as mobile device users through monetary compensation) to turn mobile devices into DECS-D machines. Thus, DECS growth is demand driven, locality sensitive, and a passive source of income for a contributor. Users are encouraged to participate in DECS by compensation for the user of computing resources and the computation resources provide augmenting computing capacity. Through localization and consumer-demand driven infrastructure augmentation, varied computational requirements keep updating and growing.

A wide variety of resource requirements are expected to emerge with varied requirements on computational resources, latency, data volume transactions, guaranteed performance, and the like. In some embodiments, DECS meets computational requirements keeping up with the varied demands of data producers & consumers and reducing latencies (e.g., latencies of approximately 5 ms). In some embodiments, DECS accomplishes this through distributed elemental, individual centric, and idle computational resources access to a pooled community. In some embodiments, DECS passes these benefits to the service provider through quality of service (QoS). In some embodiments, DECS provides augmentation of incremental resources for a bigger pool satisfying higher computational requirements. In some embodiments, DECS provides local data/computations requirements at user machines, provides an increase in data, and provides a user perspective ecosystem change. In some embodiments, as users experience the improved performance of DECS, other users are incentivized to use personal machines as DECS-D.

FIG.1is a diagrammatic representation of a distributed edge computing system (DECS)100, in accordance with some embodiments.

DECS100includes a core network102communicatively connected to RAN104through backhaul106, which is communicatively connected to base stations, with antennas that are wirelessly connected to user equipment UEs112A,112B, and112C (together referred to as UE112) located in geographic coverage areas114. Core network102includes one or more service provider(s)116, DECS-M module (DECS-MM)118, and applications module120.

Core network102(also known as a backbone) is a part of a computer network which interconnects networks, providing a path for the exchange of information between different local area networks (LANs) or subnetworks. In some embodiments, core network102ties together diverse networks in the same building, in different buildings in a campus environment, or over wide geographic areas. In some embodiments, core network102is a cloud network.

In some embodiments, RAN104is an access network, such as a global system for mobile communications (GSM) RAN, a GSM/EDGE RAN, a universal mobile telecommunications system (UMTS) RAN (UTRAN), an evolved universal terrestrial radio access network (E-UTRAN, open RAN (O-RAN), or cloud-RAN (C-RAN) or it could be any access technology (for example, IEEE 802.11x or 802.15.XX). RAN104resides between user equipment112(e.g., mobile phone, a computer, or any remotely controlled machine) and core network102.

In a hierarchical telecommunications network, backhaul portion106of DECS100comprises the intermediate link(s) between core network102and RAN104. The two main methods of mobile backhaul implementations are fiber-based backhaul and wireless point-to-point backhaul. Other methods, such as copper-based wireline, satellite communications and point-to-multipoint wireless technologies are being phased out as capacity and latency requirements become more stringent in 4G and 5G networks. Backhaul generally refers to the side of the network that communicates with the global Internet. The connection between a base station and UE112begins with backhaul106connected to core network102. In some embodiments, backhaul106includes wired, fiber optic and wireless components. Wireless sections include using microwave bands and mesh and edge network topologies that use a high-capacity wireless channel to get packets to the microwave or fiber links.

In some embodiments, UEs112are a computer or computing system. Additionally, or alternatively, UEs112have a liquid crystal display (LCD), light-emitting diode (LED) or organic light-emitting diode (OLED) screen interface, such as user interface (UI)722(FIG.7), providing a touchscreen interface with digital buttons and keyboard or physical buttons along with a physical keyboard. In some embodiments, UEs112connect to the Internet and interconnect with other devices. Additionally, or alternatively, UE112incorporates integrated cameras, the ability to place and receive voice and video telephone calls, video games, and Global Positioning System (GPS) capabilities. Additionally, or alternatively, UEs run operating systems (OS) that allow third-party applications specialized for capabilities to be installed and run. In some embodiments, UEs112are a computer (such as a tablet computer, netbook, digital media player, digital assistant, graphing calculator, handheld game console, handheld personal computer (PC), laptop, mobile internet device (MID), personal digital assistant (PDA), pocket calculator, portable medial player, or ultra-mobile PC), a mobile phone (such as a camera phone, feature phone, smartphone, or phablet), a digital camera (such as a digital camcorder, or digital still camera (DSC), digital video camera (DVC), or front-facing camera), a pager, a personal navigation device (PND), a wearable computer (such as a calculator watch, smartwatch, head-mounted display, earphones, or biometric device), a smart card, or biometric device.

UEs112A are consumers of data (hereinafter referred to as consumers112A). In some embodiments, consumers112A receive processed data streams from UEs112C which are DECS clients or distributed devices (DECS-D). UEs112C are herein after referred to as DECS-D112C. UEs112B are producers of data (hereinafter referred to as producers112B). In some embodiments, Producers112B send data streams to DECS-D112C for processing. DECS-D112C include a lightweight agent, provided by an application), for distributed edge computing (DEC) functionality. In some embodiments, Consumers112A and producers112B communicate with DECS-D112C through wireless network interfaces such as BLUETOOTH, WIFI, WIMAX, GPRS, or WCDMA, point-to-point (P2P)/point-to-multipoint (P2MP) communication via IEEE 802.11x or 802.15.XX; or wired network interfaces such as ETHERNET, USB, IEEE-864.

In some embodiments, consumers112A, producers112B, and DECS-D112C are configured to communicate in a localized area, such as localized areas113A and113B. In some embodiments, UEs112A,112B, and112C to communicate effectively in localized areas113A and113B and maintain low latency (a few msec to micro-seconds). However, DECS100is not restricted to localized areas113A and113B and consumers112A, producers112B, and DECS-D112C are able to communicate across localized areas113A and113B.

Service provider(s)116are businesses or organizations that sell bandwidth or network access. Service provider(s)116provide direct Internet backbone access to internet service providers and usually access to network access points (NAPs). Service providers are sometimes referred to as backbone providers or internet providers. Service providers consist of telecommunications companies, data carriers, wireless communications providers, Internet service providers, and cable television operators offering high-speed Internet access.

DECS-MM118is a DECS manager. In some embodiments, DECS-MM118is a centralized DECS100controlling agent. In some embodiments, DECS-MM118registers DECS-D112C and augments and distributes incremental resources of DECS-D112C for consumers112A and producers112B. DECS-MM118manages DECS-D112C and interfaces with applications module120and applications stored within. In some embodiments, DECS-MM118is configured to manage resource allocation. DECS-MM118registers DECS-Ds with details of computing resources. A DECS agent is installed on DECS-Ds offered resources (e.g., downloaded from a PlayStore App). The DECS agent is configured to integrate available computing resources with DECS-MM118. DECS-MM118integrates the computing resources to build standard usage tiers (SUTs are standardized models of computational resources clustered to meet different market requirements across computing resource consumers112A and producers112B) and update a SUT Library. DECS-MM118is configured to reserve and allocate SUTs to DECS-Ds112C. DECS-MM is configured to handle contract agreements between consumers112A, producers112B and DECS-D112C based on resources lifespan, performance expectations & consequence management.

Applications module120stores application programs (application or app for short). Application programs are computer programs designed to carry out a specific task other than one relating to the operation of the computer itself, typically to be used by end-users or remote consumer using data from end-device. Word processors, media players, and accounting software are examples. In some embodiments, applications module120provides instructions for consumers112A and producers112B regarding the consumption and production of data. In some embodiments, applications module120provides instructions to DECS-D112C regarding computing resources onboard DECS-D112C committed for DECS100. In some embodiments, DECS-D112C fulfils the application module's instructions and in turn, the owner of DECS-D112C is incentivized (e.g., paid through cash, crypto currencies, or the like). In some embodiments, application module120installs and initiates application software on DECS-D112C. In some embodiments, application module120provides domain name system (DNS) address of DECS-D112C for forwarding data to data producer112B. In some embodiments, application module120intimates source address for reception of data to be sent to consumer112A. In some embodiments, application module120shares credentials to connect consumers112A and producers112B with DECS-D112C within a localized area, such as localized areas113A and113B. In some embodiments, DECS-D112C provides infrastructure resources to process local information received from near-by data producers112B, process the data pursuant to instructions from application module120, and pass the processed data to nearby data consumers112A.

FIG.2is a diagram of a DECS200, in accordance with some embodiments.

Reference numerals for DECS200are consistent with the reference numerals of DECS100. In some embodiments, DECS200is like DECS100. An understanding of DECS200is helpful with regards to the discussion of DECS algorithm (DECS-A)300(FIG.3) and the data and information flow between the elements of DECS200with a discussion of DECS-A300.

In some embodiments, DECS200operates independently of a network. As discussed later with reference to the examples ofFIGS.4-6, the DECS operates independently of the type of network being utilized for the computing devices. In some embodiments, the network is a wired, wireless, optical, or the like.

Thus, inFIG.2, DECS200is shown independent of the network.

FIG.3is a flow diagram of a DECS algorithm (DECS-A)300, in accordance with some embodiments.

In some embodiments, DECS-A300is configured to provide a method for implementing a DECS, such as DECS200and DECS100. While DECS-A300is presented in operations301through319, unless specified these operations need not be performed in the order discussed or presented inFIG.3.

In operation301of DECS-A300, DECS-MM218publishes a resource units (RU) demand to DECS-D212C. In some embodiments, a RU demand is sent in response to a potential DECS-D212C requesting to become a registered DECS-D212C. In some embodiments, a potential DECS-D212C had downloaded a DECS application and desires to engage in a contract to become a DECS-D212C. RU304of DECS-D212C is infrastructure resource units, such as processors, RAM, storage, and connectivity. DECS-D212C is a computational resource provider (CRP) and is a lessor of computational resources leasing to a consumer resource user (CRU), such as an application owner. In some embodiments, operation301is the registration (or deregistration) of DECS-Ds212C for resource offerings. Flow process moves from operation301to operation302.

In operation302of DECS-A300, DECS-D212C fills a RU template (or application) providing the RU data requested by DECS-MM218. In some embodiments, DECS-D212C automatically fills the RU template. In some embodiments, an owner of the DECS-D212C fills in the RU template. In some embodiments, a user provides authorization to DECS-MM218to determine the RU capabilities of DECS-D212C and automatically fills the template based on the device's capabilities. Flow proceeds from operation302to operation303.

In operation303of DECS-A300, DECS-D212C sends the completed template back to DECS-MM218. Flow proceeds from operation303to operation304where DECS-MM218validates and registers the RU320. DECS-D212C registers with DECS-MM218with details of the computing resources available. Flow proceeds from operation304to operation305.

In operation305of DECS-A300, DECS-MM218communicates with DECS-D212C to check performance records for RU320. Flow proceeds to operation306where RU320performs diagnostic tests to determine the performance of RU320. In some embodiments, the diagnostic tests determine duration cycles of availability (e.g., how often is DECS-D212C available for processing additional data). In some embodiments, the diagnostic tests determine a committed or best-effort availability of DECS-D212C. In some embodiments, DECS-MM218determines a physical location of DECS-112C. In some embodiments, DECS-MM119determines the type of connectivity with DECS-D212C. In some embodiments, a quality of performance of the RU resources and connectivity is evaluated. In some embodiments, reliability performance of RU320is determined. In some embodiments, a duration of commitments (e.g., how long with DECS-D212C be available) is determined (e.g., based on the template from operation302). In response to the completion of the diagnostic tests, DECS-D212C returns the results of the diagnostic tests to DECS-MM218. Flow proceeds from operation305to operation306.

In operation306of DECS-A300, DECS-MM218conducts pre-tests on RU320. In a non-limiting example, DECS-MM218performs a simulation of the application requesting the RU processing. In another non-limiting example, DECS-MM has RU320execute test software code that is built to test various aspects of RU320. From operation306flow proceeds to operation307.

In operation307of DECS-A300, DECS-MM218updates a standard usage tier (SUT) library322. In some embodiments, variations in tiers are used to meet variations in demands. In some embodiments, DECS-MM218clusters and orchestrates available resources in SUTs to build offerings for data consumers, such as consumers212A. In some embodiments, SUTs are based on the resource offerings, such as CPU, RAM, data storage, connectivity, and the like. In some embodiments, SUTs are based on the availability of the DECS-D212C, such as duration cycles of availability, committed/best effort availability, physical location of resource, type of connectivity with DECS-C, and the like. In some embodiments, SUTs are based on the performance observations of resources offered by DECS-D212C, such a quality performance of resources and connectivity, reliability performance of the resources, duration of commitments, and the like. In some embodiments, SUTs are based on a combination of each of the listed criteria. In some embodiments, SUTs are calculated by providing a score for each criterion where the higher the score the higher the SUT for DECS-D212C. Flow proceeds from operation307to operation308.

As part of the resource reservation and utilization, in some embodiments, SUTs, once allocated, remain reserved with the designated DECS-C. In some embodiments, DECS-C resource usage is agreed upon in a contract. In some embodiments, a DECS report provides the performance of the resources. In some embodiments, in response to the expiration of a contract, either the contract is mutually renewed, or DECS-MM218follows a de-allocation sequence where the DECS-C is removed from the SUT library322.

In operation308of DECS-A300, an application provider or computational resource consumer (CRC)324is updated with RU availability of several DECS-Ds112C. In some embodiments, the RU availability is updated in real-time. In some embodiments, RU availability is updated periodically. In some embodiments, RU availability is updated upon request by CRC324. Flow proceeds from operation308to operation309.

In operation309of DECS-A300, CRC324confirms with DECS-MM218a selection of an RU. Flow proceeds from operation309to operation310.

In operation310of DECS-A300, DECS-MM218reserves the RU and notifies the DECS-C and waits for a response confirming the resource reservation. Flow proceeds from operation310to operation311.

In operation311of DECS-A300, in response to confirmation of the resource reservation, DECS-MM218installs a DECS agent on DECS-D212C. In some embodiments, the DECS agent is a lightweight agent (e.g., a small software package) installed for DEC functionality. In some embodiments, the DECS agent is able to be downloaded as a play store application. In some embodiments, the DECS agent integrates available resources with DECS-MM218. Flow proceeds from operation311to operation312.

In operation312of DECS-A300, in response to the DECS agent being installed, a readiness confirmation notifying of the agent installation is sent to CRC324. Flow proceeds from operation312to operation313.

In operation313of DECS-A300, intimation to the application begins and application module220begins installing and initiating application software on DECS-D212C at operation314. Flow proceeds from operation314to operation315.

In operation315of DECS-A300, application module220intimates to data producers, such as producers212B the DNS address of the installed DECS agent for forwarding data from producers212B to be processed. Further, in operation316, application module220intimates a source address for reception of data to a data consumer, such as consumer112A. Flow proceeds from operation316to operation317.

In operation317of DECS-A300, data producers, such as producers212B send produced data to the DECS agent on DECS-D212C. DECS-D212C processes the received produced data pursuant to installed application software. Upon completion of the data processing the data is forwarded to the data consumer, such as consumers212A at operation318. Flow proceeds from operation318to operation319.

In operation319of DECS-A300, the data consumer, such as consumer112A, receives the processed data from the DECS agent

FIG.4is an example DECS400, in accordance with some embodiments.

DECS400includes a localized area, such as building402, that represents a resident flat or an office space. Building402is connected to a local internet service provider (ISP) network404, that is connected to cloud network406that is connected to a DECS-M408. Providers412B are in localized communication with DECS-D412C which is in communication with consumers412A.

In some embodiments, a user device, such as DECS-D412C, with storage capacity (e.g., a hard disk drive (HDD)) connected to home Wi-Fi) acts as a caching device for providers412B providing content to rest of consumers412A in local network404.

FIG.5is an example DECS500, in accordance with some embodiments.

In some embodiments, several companies,550A,550B,550C,550D,550E, and550F, have several processing resources used during the daytime. In nighttime the computing resources have very low utilization, that leads to wastage in infrastructure capacity and impacting higher carbon footprint owing to waste of energy. Huge collaboration opportunity exists of secured solution with the help of DECS intermediary.

In a non-limiting example, companies550A,550B and/or550C act as a DECS-D and process data for companies550D,550E, and/or550F and return the data. That is, companies550A,550B, and550C are 12 hours behind companies550D,550E, and550F. Thus, during the evening hours companies550A,550B, and550C operate as a DECS-D, while companies550D,550E, and550F operate as both producers and consumers of data. Further, during the evening hours companies550D,550E, and550F operate as a DECS-D, while companies550A,550B, and550C operate as both producers and consumers of data.

FIG.6is an example DECS600, in accordance with some embodiments.

In some embodiments, where multiple cars660and662have UE connected to a core network by base stations664that are connected to RAN technology. In a scenario where each car660are acting as producer of data as well as a consumer of data device, a DECS application aides to connect near-by individual devices to DECS Agent662. A DECS agent provides infrastructure resources to process local information received from near-by devices acting as producers, process the information pursuant to an application design and passes the information back to nearby consumer devices. Direct car-to-car localized communication, reducing dependency on V2X communication while aiding smart device communication like warning signals, traffic updates received from an application layer, route-plan sharing by neighbors etc.

FIG.7is a block diagram of DECS processing circuitry700in accordance with some embodiments. In some embodiments, DECS processing circuitry700is a general-purpose computing device including a hardware processing circuitry702and a non-transitory, computer-readable storage medium704. Storage medium704, amongst other things, is encoded with, i.e., stores, computer program code, i.e., a set of executable instructions706such as DECS-A300. Execution of instructions706by hardware processing circuitry702represents (at least in part) a DECS tool which implements a portion or of the methods described herein in accordance with one or more embodiments (hereinafter, the noted processes and/or methods).

Processing circuitry702is electrically coupled to a computer-readable storage medium704via a bus708. Processing circuitry702is also electrically coupled to an I/O interface710by bus708. A network interface712is also electrically connected to processing circuitry702via bus708. Network interface712is connected to a network714, so that processing circuitry702and computer-readable storage medium704are capable of connecting to external elements via network714. Processing circuitry702is configured to execute computer program instructions706encoded in computer-readable storage medium704to cause affected node processing circuitry700to be usable for performing a portion of the noted processes and/or methods. In one or more embodiments, processing circuitry702is a central processing unit (CPU), a multi-processor, a distributed processing system, an application specific integrated circuit (ASIC), and/or a suitable processing unit.

In one or more embodiments, storage medium704stores computer program code706configured to cause DECS processing circuitry700to be usable for performing a portion or of the noted processes and/or methods. In one or more embodiments, storage medium704also stores information, such as DECS-A300which facilitates performing a portion or of the noted processes and/or methods.

Affected node processing circuitry700includes I/O interface710. I/O interface710is coupled to external circuitry. In one or more embodiments, I/O interface710includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and/or cursor direction keys for communicating information and commands to processing circuitry702.

Affected node processing circuitry700is also include network interface712coupled to processing circuitry702. Network interface712allows DECS processing circuitry700to communicate with network714, to which one or more other computer systems are connected. Network interface712includes wireless network interfaces such as BLUETOOTH, WIFI, WIMAX, GPRS, or WCDMA; or wired network interfaces such as ETHERNET, USB, or IEEE-864. In one or more embodiments, a portion or noted processes and/or methods, is implemented in two or more affected node processing circuitry700.

DECS processing circuitry700is configured to receive information through I/O interface710. The information received through I/O interface710includes one or more of instructions, data, design rules, libraries, and/or other parameters for processing by processing circuitry702. The information is transferred to processing circuitry702via bus708. DECS processing circuitry700is configured to receive information related to a UI through I/O interface710. The information is stored in computer-readable medium704as user interface (UI)722.

In some embodiments, a method for distributed edge computing (DEC) includes obtaining a request from a computational resource provider (CRP) offering computational resources of the CRP; validating the computation resources of the CRP; offering the computation resources of the CRP to a computational resource consumer (CRC); obtaining a reservation request from the CRC for a portion of the computation resources of the CRP; and installing CRC software on the CRP for DEC, where the CRP is configured to receive produced data related to the CRC software from a first localized device, the computational resources process the produced data, and forward processed data to a second localized device that has requested the processed data.

In some embodiments, the method further includes installing a DEC system (DECS) agent on the CRP, where the DECS agent is assigned a domain name system (DNS) address, the DNS address of the DECS agent having been provided to the first localized device so that the first localized device has the DNS address to forward the produced data to the CRP; and where the second localized device is notified of the DNS address in which to receive the processed data from the DECS agent.

In some embodiments, the method further includes, in response to receiving a computation resource reservation from the CRC, reserving the portion of the computation resources of the CRP for use by other CRC.

In some embodiments, the method further includes testing the computation resources of the CRP.

In some embodiments, the method further includes determining a standard usage tier (SUT) based on results of the computation resource testing.

In some embodiments, the method further includes updating a SUT library based on the computational resources of the CRP.

In some embodiments, the method further includes requesting use of at least a portion of the computation resources of the CRP.

In some embodiments, the method further includes validating the computation resources of the CRP based on a template, completed at the CRP, detailing the computation resources of the CRP.

In some embodiments, the method further includes verifying previous performance records of the computation resources of the CRP.

In some embodiments, a system includes a memory having non-transitory instructions stored; and processing circuitry coupled to the memory, and being configured to execute the non-transitory instructions, thereby causing the processing circuitry to obtain a request from a computational resource provider (CRP) offering computational resources of the CRP; validate the computation resources of the CRP; offer the computation resources of the CRP to a computational resource consumer (CRC); obtain a reservation request from the CRC for a portion of the computation resources of the CRP; and install CRC software on the CRP for DEC, where the CRP is configured to receive produced data related to the CRC software from a first localized device, the computational resources process the produced data, and forward processed data to a second localized device that has requested the processed data.

In some embodiments, the non-transitory instructions further cause the processing circuitry to install a DEC system (DECS) agent on the CRP, where the DECS agent is assigned a domain name system (DNS) address, the DNS address of the DECS agent having been provided to the first localized device so that the first localized device has the DNS address to forward the produced data to the CRP; and where the second localized device is notified of the DNS address in which to receive the processed data from the DECS agent.

In some embodiments, the non-transitory instructions further cause the processing circuitry to, in response to receiving a computation resource reservation from the CRC, reserve the portion of the computation resources of the CRP for use by the CRC.

In some embodiments, the non-transitory instructions further cause the processing circuitry to test the computation resources of the CRP.

In some embodiments, the non-transitory instructions further cause the processing circuitry to determine a standard usage tier (SUT) based on results of the computation resources testing.

In some embodiments, the non-transitory instructions further cause the processing circuitry to update a SUT library based on the computational resources of the CRP.

In some embodiments, a computer-readable medium including instructions executable by processing circuitry to cause the processing circuitry to perform operations including obtaining a request from a computational resource provider (CRP) offering computational resources of the CRP; validating the computation resources of the CRP; offering the computation resources of the CRP to a computational resource consumer (CRC); obtaining a reservation request from the CRC for a portion of the computation resources of the CRP; and installing CRC software on the CRP for DEC, where the CRP is configured to receive produced data related to the CRC software from a first localized device, the computational resources process the produced data, and forward processed data to a second localized device that has requested the processed data.

In some embodiments, the instructions further cause the processing circuitry to perform operations includes installing a DEC system (DECS) agent on the CRP, where the DECS agent is assigned a domain name system (DNS) address, the DNS address of the DECS agent having been provided to the first localized device so that the first localized device has the DNS address to forward the produced data to the CRP; and where the second localized device is notified of the DNS address in which to receive the processed data from the DECS agent.

In some embodiments, the instructions further cause the processing circuitry to perform operations including, in response to receiving a computation resource reservation from the CRC, reserving the portion of the computation resources of the CRP for use by the CRC.

In some embodiments, the instructions further cause the processing circuitry to perform operations including testing the computation resources of the CRP.

In some embodiments, the instructions further cause the processing circuitry to perform operations including determining a standard usage tier (SUT) based on results of the computation resources testing.