Automatic mobile Kube-Edge configuration

DE112021005136B4Active Publication Date: 2025-03-27INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
DE112021005136
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2020-11-23
Filing Date
2021-10-21
Publication Date
2025-03-27
Estimated Expiration
2041-10-21

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A computer-implemented method for determining a Kube-Edge-Pod configuration, wherein the method comprises: Identifying (204) mobile units in a service area of ​​a mobile environment, wherein the mobile units use a cloud service (120); Receiving (206) query data from the mobile units, wherein the query data includes offer data indicating a corresponding cost and resource availability for each of the mobile units operated as an edge unit for the cloud service (120); Determining (208) connection information for the mobile units, wherein the connection information indicates whether at least two of the mobile units are to be considered as connected, such that the connected mobile units have a connected cost and a connected resource availability to provide a data storage functionality shared by the connected mobile units by pooling available storage from the connected mobile units; as a result of linking the at least two mobile units, determining (210) a supply assessment of the supply area based on the supply data and the linking information, the supply assessment including the linked costs of the at least two linked mobile units; and Selecting (214) a data storage provisioning scheme for pods of the cloud service (120) based on the supply assessment, wherein As a result of the supply assessment yielding an initial result relative to a supply threshold, a status-independent data storage provisioning scheme is selected, with storage shared by all pods, and As a result of the supply assessment having a second result relative to the supply threshold, a status-dependent data storage provisioning scheme is selected, with each of the pods having its own storage.
Need to check novelty before this filing date? Find Prior Art

Description

BACKGROUND

[0001] The example embodiments relate generally to Kube-Edge computing, and more particularly to determining a Kube-Edge pod configuration to enable high provisioning and availability with minimal incentives.

[0002] Edge computing in a cloud environment makes it possible to provide data processing and / or storage closer to the devices where these operations are performed. Accordingly, edge computing eliminates the need to transfer data to be processed and / or stored to a central location (e.g., a central cloud server), which may be physically located a considerable distance from the devices. While this configuration may not result in significant changes to the services provided for individual devices, with the explosive proliferation of the Internet of Things (IoT) and the use of such devices, the demands on using cloud services are increasing exponentially (e.g., higher latency leading to lower quality, bandwidth costs, etc.).To reduce such problems, edge computing can therefore be provided.

[0003] Multi-access edge computing (MEC) provides an approach that deploys cloud computing capabilities and an IT service environment at the edge of the network. MEC provides an ecosystem where applications and services can be deployed flexibly and quickly to devices. 5G is the next generation of broadband mobile networks, with expected higher data rates. MEC implementations exist for various networks, and 5G continues to expand as service providers deploy the latest and most technologically advanced systems for their customers. While MEC and 5G are considered groundbreaking technologies in their own right, when combined, they will play a significant role in the world of computing.The advent of 5G network capabilities will increase the number of connected devices in a network, driving the need for edge computing to distribute network requests. Applications that rely heavily on consistent network connectivity, rapid deployment, and low latency include emerging technologies such as artificial intelligence (AI), IoT, virtual reality (VR), augmented reality (AR), and others. MEC and 5G networks together enable the simultaneous use of a large number of connected technologies without experiencing network outages due to traffic congestion. However, current edge deployments may not be configured to dynamically deploy edge services across different coverage areas.

[0004] US 2020 0 322 233 A1 describes a processing system that enables the provision of a client service in a mobile edge infrastructure of a telecommunications network upon request from a client device. The system checks requirements such as maximum distance or latency and selects a suitable host device to execute the service.

[0005] US 10 110 495 B1 describes a Multi-Access Edge Computing (MEC) system comprising systems, devices, methods, and computer-readable media. An MEC device includes a communication interface, a module for local cost measurements, and a service allocation module that decides whether to allocate a service to an MEC host based on an allocation policy and the local cost measurements.

[0006] US 2013 0 166 712 A1 describes cloud edge topologies, particularly cloud edge applications and resource utilization in different cloud edge topologies. Another aspect concerns the specification of cloud edge applications using a temporal language and an architecture that leverages Data Stream Management Systems (DSMS) engines in the cloud and on cloud edge computers for query execution. SUMMARY

[0007] The invention is described by the features of the independent claims. Embodiments are specified in the dependent claims.

[0008] The exemplary embodiments disclose a method, a computer program product, and a computer system for determining a Kube-Edge pod configuration. The method comprises determining mobile devices within a coverage area of ​​a mobile environment, the mobile devices using a cloud service. The method comprises receiving polling data from the mobile devices. The polling data includes bid data indicating a corresponding cost and resource availability for each of the mobile devices operating as an edge device for the cloud service. The method comprises determining connection information for the mobile devices. The connection information indicates whether at least two of the mobile devices are considered connected, such that the connected mobile devices have a connected cost and resource availability.The method includes determining a coverage rating of the coverage area based on the offer data and the connection information. The method includes selecting a data storage deployment scheme for pods of the cloud service based on the coverage rating. BRIEF DESCRIPTION OF THE DIFFERENT VIEWS OF THE DRAWINGS

[0009] The following detailed description, which is given by way of example and is not intended to limit the exemplary embodiments alone, is best understood in conjunction with the accompanying drawings in which: Fig. 1 illustrates an exemplary schematic diagram of a Kube-Edge configuration system 100 according to exemplary embodiments. Fig. 2 depicts an example flowchart of a method 200 illustrating operations of the configuration server 130 of the Kube-Edge configuration system 100 in determining a Kube-Edge pod configuration, according to example embodiments. Fig. 3 is an exemplary block diagram illustrating the hardware components of the Kube-Edge configuration system 100 of Fig. 1 according to the exemplary embodiments. Fig. 4 illustrates a cloud computing environment according to the exemplary embodiments. Fig. 5 illustrates abstraction model layers according to the exemplary embodiments.

[0010] The drawings are not necessarily to scale. The drawings are merely schematic representations and are not intended to depict specific parameters of the exemplary embodiments. The drawings are intended to illustrate only typical, exemplary embodiments. Throughout the drawings, like numbering represents like elements. DETAILED DESCRIPTION OF THE DIFFERENT VIEWS OF THE DRAWINGS

[0011] Detailed embodiments of the claimed structures and methods are disclosed herein; however, it should be understood that the disclosed embodiments are merely illustrative of the claimed structures and methods, which may be embodied in various forms. The example embodiments are merely illustrative and, therefore, may be embodied in many different forms and should not be construed as limited to the example embodiments set forth herein. Rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the example embodiments to those skilled in the art. The description may omit details of well-known functions and techniques in order not to unnecessarily obscure the present embodiments.

[0012] References in the specification to "a single embodiment," "an embodiment," "an exemplary embodiment," etc., indicate that the described embodiment may include a particular function, structure, or characteristic, but not every embodiment necessarily includes that particular function, structure, or characteristic. Furthermore, such expressions do not necessarily refer to the same embodiment. Further, where a particular function, structure, or characteristic is described in connection with one embodiment, it is asserted that it is within the skill of one skilled in the art to implement that function, structure, or characteristic in connection with other embodiments, regardless of whether it is expressly described.

[0013] To avoid obscuring the illustration of the exemplary embodiments, in the following detailed description, some processing steps or operations known in the art may be linked together for purposes of illustration and description and, in some cases, may not be described in detail. In other cases, some processing steps or operations known in the art may not be described at all. It should be understood that the following description focuses on the particular features or elements according to the various exemplary embodiments.

[0014] The exemplary embodiments relate to a method, a computer program product, and a system for determining a Kube-Edge configuration. As described in more detail below, the exemplary embodiments may provide a mechanism for automatically configuring a Kube-Edge pod configuration within a coverage area of ​​a mobile environment in which mobile devices may be present. The exemplary embodiments may dynamically determine the Kube-Edge pod configuration according to a storage provisioning scheme, for example, between a stateful provisioning and a stateless provisioning, taking into account the changing and dynamic conditions due to the mobile nature of the devices within the coverage area.Key benefits of the exemplary embodiments may include dynamic configuration discovery and a departure from a static form of Kube-Edge deployment that can function seamlessly in mobile environments. A detailed implementation of the exemplary embodiments follows.

[0015] Kube-Edge deployments in a cloud environment are generally static. Specifically, with regard to a pod configuration, the Kube-Edge deployment may have a configuration that is fixed and used by Kubernetes for the pods. For example, the storage for the pods may be set to be shared. In another example, the storage for the pods may be set to be available to each pod individually. The Kube-Edge deployment in traditional systems essentially sets one of these configurations, which is used by Kubernetes.However, deployments, such as those in the Internet of Things (IoT), have created a need for cellular-based deployments that enable Kube-Edge-based application programming interfaces (APIs) in mobile vehicles, leading to faster 5G networks in vehicular networks or enabling better coverage of remote areas by vehicular networks. Accordingly, the fixed or static approach to Kube-Edge deployments has drawbacks and cannot provide seamless operation in mobile environments.

[0016] Conventional approaches to deploying Kube-Edge systems refer to various mechanisms expected to improve Kube-Edge functionality. For example, one conventional approach describes how mobile edge computing (MEC) can be integrated with 5G technology. Another example describes fusion management of an edge cloud, where a Kube-Edge program meets the needs of resource-constrained edge nodes managed in a centralized Kubernetes system. Another example describes a Kubernetes-native infrastructure and operator structure for 5G edge cloud computing. Another example describes extending a cloud or Kubernetes ecosystem from the cloud to the edge.However, these conventional approaches do not provide a mechanism to leverage mobility patterns of mobile edge nodes and interactive data transfer with peer edge nodes to generate Kube-Edge Pod configurations that meet service scope objectives, ranging from stateless to stateful options. These conventional approaches also do not consider standard parameters related to resources and cost overhead. Accordingly, the conventional approaches do not understand the connectivity between edge units from a spatio-temporal social network analysis and do not leverage this information to provide a better trade-off between stateful and stateless deployments in Kube-Edges, which would enable better trade-off decisions.

[0017] The exemplary embodiments are configured to accommodate mobile environments, as well as service areas comprising mobile environments that have different resources based on the availability of mobile edge units and respective configurations. Therefore, the exemplary embodiments relate to providing an approach where a same Kube-Edge Pod configuration, which is not universally implemented, adds mobile environments. In mobile environments, different mobile units may be available at a given location or service area. Different units may be associated with different costs and resources.Furthermore, the availability time for these units can constantly change, as a mobile unit that is present in a coverage area at one time may not be present at another. Therefore, simply statically selecting units does not always provide an optimal solution. The example embodiments employ a dynamic approach that uses more sophisticated analysis. The example embodiments therefore provide for choosing between stateful and stateless deployment, which typically involves complex decisions due to the mobile nature of the mobile units. In this way, the example embodiments are configured to determine the optimal Kube-Edge pod configuration for a given mobile environment to enable very good coverage and availability with minimal incentives.The example embodiments are further configured to determine the optimal Kube-Edge pod configuration when multiple units are queried simultaneously.

[0018] The example embodiments are particularly described with reference to Kube-Edge and Pod configurations associated with Kubernetes in a cloud environment. However, the example embodiments that refer to such an arrangement are for illustrative purposes only. The example embodiments may be used and / or modified to be deployed in any network environment in which an edge system may be used, and the functions of the example embodiments may be properly performed to determine an optimal configuration suitable for the coverage area to be processed. The example embodiments are also described with respect to stateful and stateless deployments associated with the storage functionalities for the pods. The use of the stateful and stateless deployments, respectively, may be used in a variety of ways.However, the stateless provisioning and storage functionality are for illustrative purposes only. The example embodiments may be used and / or modified for other configurations that may relate to other functionalities.

[0019] Fig. 1 illustrates a Kube-Edge configuration system 100 according to the exemplary embodiments. According to the exemplary embodiments, the Kube-Edge configuration system 100 may include one or more intelligent devices 110, cloud services 120, and a configuration server 130, all of which may be interconnected via a network 108. While the programming and data of the exemplary embodiments may be stored on multiple remotely located servers and retrieved via the network 108, the programming and data of the exemplary embodiments may alternatively or additionally be stored locally on a few or only a single physical computing device, or on computing devices other than those illustrated. The Kube-Edge configuration system 100 represents a data transmission arrangement whose components are configured to directly or indirectly exchange data with one another.

[0020] In the exemplary embodiments, the network 108 may be a data transmission channel over which data may be exchanged between connected entities. Accordingly, the components of the Kube-Edge configuration system 100 may represent network components or network entities interconnected via the network 108. In the exemplary embodiments, the network 108 may be the Internet, which is a worldwide collection of networks and gateways to support data transmission between Internet-connected entities. Furthermore, the network 108 may utilize various types of connections, such as wired, wireless, fiber optic, etc., which may be implemented as an intranet network, local area network (LAN), wide area network (WAN), or a combination thereof.In further embodiments, the network 108 may be a Bluetooth network, a Wi-Fi network, or a combination thereof. In further embodiments, the network 108 may be a telecommunications network used to enable telephone conversations between two or more participants and may include a landline network, a wireless network, a closed network, a satellite network, or a combination thereof. In general, the network 108 may represent any combination of connections and protocols that supports the transmission of data between connected entities. For example, the network 108 may also represent direct or indirect wired or wireless connections between components of the Kube-Edge configuration system 100 that do not use the network 108.

[0021] In the exemplary embodiments, the one or more intelligent devices 110 may include an edge processing client 112, which may be an enterprise server, a laptop computer, a notebook computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a server, a personal digital assistant (PDA), a rotary phone, a touch-tone phone, a smartphone, a cellular phone, a virtual appliance, a thin client, an Internet of Things (IoT) device, or any other electronic device or computing system capable of receiving and sending data to and from other computing devices. While the intelligent device 110 is illustrated as a single device, in other embodiments, the intelligent device 110 may be comprised of a cluster or a plurality of computing devices in a modular manner, etc.that work together or independently of each other. The intelligent unit 110 is described with reference to . Fig. 3 as a hardware implementation, with reference to Fig. 4 as part of a cloud implementation and / or with reference to Fig. 5 using functional abstraction layers for processing.

[0022] The smart devices 110 may represent any mobile device that may be part of a mobile environment that may exist within a predefined coverage area. The coverage areas may be predefined in a variety of ways based on various factors (e.g., physical area boundaries, load factors, etc.). With regard to the Kube-Edge aspect of the cloud-centric mobile environment, the smart devices 110 may also represent edge devices configured to provide edge processing. In this way, the smart devices 110 may also include edge gateways within the edge computing infrastructure.

[0023] In the exemplary embodiments, the edge processing client 112 may act as a client in a client-server relationship and may be a software, hardware, and / or firmware-based application that can exchange data used in determining a Kube-Edge Pod configuration for a coverage area in a mobile environment, particularly where the smart device 110 is located, with the data being exchanged via the network 108. In embodiments, the edge processing client 112 may exchange query data and other related information and use various wired and / or wireless connection protocols for data transmission and exchange related data used for modifying a version of an application, including Bluetooth, 2.4 GHz and 5 GHz Internet, near-field communication, Z-Wave, Zigbee, etc.

[0024] The edge processing client 112 may be configured to exchange query data. In one example embodiment, the edge processing client 112 may generate query data upon entering a coverage area, which is transmitted, for example, to the configuration server 130. In this example embodiment, the intelligent device 110 may include network operations where data exchange with network components (e.g., membership processes, handshakes, roaming, etc.) may include information about whether the intelligent device 110 has entered a new coverage area and an identity of the coverage area. In another example embodiment, the edge processing client 112 may receive a request for the query data, generate the query data, and transmit a response comprising the query data, for example, to the configuration server 130.In this exemplary embodiment, the smart device 110 may have been identified as being located in a service area for which the functions of the exemplary embodiments are to be provided.

[0025] The edge processing client 112 may generate the query data to include various types of information. For example, the query data may include availability information of the smart device 110 as an edge device, location information of the smart device 110, movement information of the smart device 110, etc., as well as technical parameters or information about the smart device 110 that generated the query data. The technical information may include available mobile resources (e.g., CPU, disk space, etc.), the cost associated with use as an edge device, etc. The query data may further be used to collect other information about the smart device 110.For example, the location information and movement information can be used to determine the mobile availability time during which the smart device 110 is located in the service area to be processed. The edge processing client 112 can provide any information to be included in the query data to optimally determine the Kube-Edge pod configuration.

[0026] Cloud services 120 may represent any cloud service provider and the services provided to users associated with smart devices 110. Those skilled in the art will understand the various components, entities, connections, etc., that may be involved in providing cloud services 120. For example, cloud services 120 may utilize cloud computing, in which a network of remotely located servers and other network entities hosted over a network (e.g., the Internet) may provide data storage, management, processing, etc., as opposed to a local server or network operated by one entity. The example embodiments may be used and / or modified for use with cloud services 120 and may include any cloud service available to users of smart devices 110.

[0027] The cloud services 120 may include various characteristics associated with a cloud. For example, in deploying the cloud services 120, the cloud may include Kubernetes, which defines building blocks that provide mechanisms configured to deploy, manage, scale, etc., a plurality of applications based on various metrics. Those skilled in the art will understand the various technical aspects associated with Kubernetes and its function in the cloud. In another example, the cloud may include pods that group containerized components, where each container functionally decouples applications from the underlying host infrastructure components. The pods may include one or more containers co-located on a host machine and having the ability to share resources.In Kube-Edge systems such as the one for which the example embodiments may be practiced, the pods may be configured in a stateful or stateless deployment, where data may be stored on individual pods or by a plurality of pods on shared storage.

[0028] In the exemplary embodiments, the configuration server 130 may include an identification program 132, a bid program 134, a connection program 136, and a selection program 138, and may act as a server in a client-server relationship with the edge processing client 112. The configuration server 130 may be an enterprise server, a laptop computer, a notebook computer, a tablet computer, a netbook computer, a PC, a desktop computer, a server, a personal digital assistant (PDA), a rotary dial phone, a touch-tone phone, a smartphone, a cellular phone, a virtual appliance, a thin client, an IoT device, or any other electronic device or computer system capable of receiving and sending data to and from other computing devices.Although the configuration server 130 is illustrated as a single unit, in other embodiments, the configuration server 130 may consist of a cluster or a plurality of computing units that operate together or independently of each other. The configuration server 130 is described with reference to FIG. Fig. 3 as a hardware implementation, with reference to Fig. 4 as part of a cloud implementation and / or with reference to Fig. 5 using functional abstraction layers for processing.

[0029] According to the exemplary embodiments, the configuration server 130 may discover and activate a Kube-Edge Pod configuration with an emphasis on stateful versus stateless provisioning for a particular mobile environment, thereby enabling high provisioning and availability with minimal incentives in the context of multi-unit availability and social network considerations in the mobile environment.

[0030] In the exemplary embodiments, the identification program 132 may be a software, hardware, and / or firmware application configured to select a coverage area in a mobile environment and determine which of the smart devices 110 are present in the selected coverage area. As described above with respect to the edge processing client 112, the identification program 132 may query the smart devices 110 present in the selected coverage area and receive query data in an active or passive manner. For example, the identification program 132 may actively query the coverage area after the coverage area is selected and request that devices provide query data.The identification program 132 may generate an interrogation signal that is broadcast in the selected coverage area so that each of the smart devices 110 in the selected coverage area receives the interrogation signal. Alternatively, the identification program 132 may receive information from network components that provide identification of the smart devices 110, for which the identification program 132 may selectively transmit an interrogation signal to those smart devices 110. In another example, using the passive method, the identification program 132 may be assigned one or more coverage areas in the mobile environment. Each time the smart devices 110 enter the coverage area assigned to the identification program 132, the identification program 132 may receive interrogation data from the smart devices 110.In such a scenario, the identification program 132 may broadcast the interrogation signal passively (e.g., continuously, at irregular intervals, etc.).

[0031] In the exemplary embodiments, the bid program 134 may be a software, hardware, and / or firmware application configured to process the query data comprising bid information from the smart devices 110 within the coverage area of ​​the mobile environment. As described above, the query data may comprise bid information containing various types of inputs. For example, the query data may include information about the smart device 110, including availability information, location information, movement information, technical parameters, etc. The availability information may indicate whether the smart device 110 is available for use as an edge device for the Kube-Edge pod configuration. The location information may indicate a physical location within the coverage area.The technical parameters may include various technical characteristics of the smart device 110 (e.g., model, processor type, graphics card, etc.). The offering information included in the query data (e.g., if the smart device 110 is available as an edge device) may include information about available resources and expected costs for offering the service (e.g., as an edge device). For example, the offering information may include mobile resources (e.g., CPU, disk space, etc.), costs (e.g., processing costs, financial expenses, etc.), minimum and maximum resources required for the service (e.g., one of the cloud services 120), mobile availability time (e.g., a period of time the smart device 110 remains in the coverage area, a period of time the smart device 110 is available as an edge device for another reason, etc.).

[0032] Using the query information and the bid data, the bid program 134 can generate a utility score based on the respective cost expenditures and resources of the smart devices 110 in the utility area. The utility score can be utility-area-related, incorporating the various information of the smart devices in the utility area. The utility score can indicate whether to use a stateless deployment for the Kube-Edge pod configuration (e.g., storage is shared by all pods) or a stateful deployment for the Kube-Edge pod configuration (e.g., each pod has its own storage).The offer program 134 may generate the supply score in a range of values ​​and use a supply threshold, where a supply score on one side of the supply threshold indicates state-independent provisioning and a supply score on the other side of the supply threshold indicates state-dependent provisioning.

[0033] In an example implementation, the smart devices 110 in the coverage area may be substantially static such that the resources of each of the smart devices 110 are relatively large, the cost expenditures are relatively low, the required cloud service resources are manageable, and the smart devices 110 are available for at least a period of time during which the cloud service is to be used. In this example implementation, the bid program 134 may process the bid information and determine a coverage score that is near an extreme of the coverage score value range. For example, the coverage score may be between 0 and 1, where 1 indicates using stateful provisioning and 0 indicates using stateless provisioning.The coverage assessment may also include a coverage threshold that is midway within the range (e.g., 0.5), although the threshold may be positioned anywhere within the range for various reasons (e.g., to favor the deployment of a particular configuration over another, to account for the types of bid information, etc.). Thus, in this example implementation, the bid program 134 may determine a coverage assessment that is greater than 0.5 and closer to 1. Thus, based solely on the coverage assessment, which considers the cost expenditures and resources of the smart devices 110 in the coverage area, the stateful provisioning for this scenario can be determined.In another example implementation, the smart devices 110 within the coverage area may be substantially mobile and transient, such that the resources of each of the smart devices 110 are relatively unstable, the cost expenditures are variable, the required resources of the cloud service may or may not be manageable, and the smart devices 110 are available for indefinite periods of time that may or may not cover a duration of use of the cloud service. In this example implementation, the bid program 134 may process the bid information and determine a utility score that is near the other extreme of the utility score range. For example, the bid program 134 may determine that the utility score is less than 0.5 and closer to 0.Thus, the state-independent provisioning for this scenario can be determined solely on the basis of the supply assessment, which takes into account the cost expenditures and resources of the intelligent units 110 in the supply area.

[0034] The bid program 134 may also determine how to sort the smart devices 110 in the coverage area based on the coverage score and the bid information. For example, if the coverage score indicates a stateful deployment, the bid program 134 may identify which of the smart devices 110 should be assigned to a pod for which individual storage operations should be used. In another example, if the coverage score indicates a stateless deployment, the bid program 134 may identify which of the smart devices 110 should be assigned to the various pods for which storage space is shared between those pods.

[0035] In the exemplary embodiments, the connection program 136 may be a software, hardware, and / or firmware application configured to determine whether two or more smart devices 110 can be considered part of a set (e.g., a connection). The connection program 136 may use the query data and / or other available information (e.g., publicly available information such as on social media websites). The connection program 136 may analyze the spatio-temporal relationship in a social network between two or more users associated with the smart devices 110 and / or between two or more of the smart devices 110 themselves to determine whether a particular pair can be connected or whether a plurality of smart devices 110 can be considered a set.For example, the connection program 136 may receive information that a married couple is traveling together in a vehicle passing through the service area. The connection program 136 may therefore determine that the smart units 110 associated with the married couple may be connected for the purposes of the exemplary embodiments. In another example, the connection program 136 may determine that a group of smart units 110 is traveling in a common mode of transportation (e.g., a sports team on a bus), so that these smart units 110 may be connected or grouped as a set for the purposes of the exemplary embodiments.

[0036] The interconnection program 136 may use the interconnection information determined through the various analyses of the bid data to modify the utility assessment determined by the bid program 134. For example, the interconnection program 136 may determine that a pair of smart devices 110 may be interconnected. The interconnection program 136 may then determine that certain resources may be aggregated or otherwise considered grouped based on the interconnection. In this way, there may be an associated cost and / or resource availability for the interconnected or grouped smart devices 110.In a specific example, the connection program 136 may determine an opportunity to save resources by having the connected smart devices 110 use a shared disk in Kube-Edges. In this way, the connection program 136 and / or the bid program 134 may use this updated cost and / or resource information of the smart devices 110 in the coverage area to re-evaluate the coverage score as a modified coverage score based on the connection information. The modified coverage score may be evaluated relative to the coverage threshold, and a corresponding deployment type may be determined.

[0037] In the exemplary embodiments, the selector 138 may be a software, hardware, and / or firmware application configured to implement the determination of the deployment to use in the Kube-Edge pod configuration. Using the modified coverage score (e.g., when connection information is available to update the coverage score), the selector 138 may determine which deployment to use for the coverage area given the current conditions of the smart devices 110 present therein. As described above, the bid program 134 and / or the connection program 136 may also determine the manner in which the smart devices 110 should be sorted and / or assigned to perform operations for the cloud service 120.For example, if a stateful deployment is to be used for the Kube-Edge pod configuration, for storage purposes, one or more selected ones of the intelligent devices 110 may be selected to store data for a particular pod (e.g., based on the cost and / or resource information of all intelligent devices 110 present in the coverage area). In another example, if a stateless deployment is to be used for the Kube-Edge pod configuration, one or more selected ones of the intelligent devices 110 may be selected to store data for a plurality of pods, with storage being shared among the pods (e.g., based on the cost and / or resource information of all intelligent devices 110 present in the coverage area).

[0038] Fig. 2 depicts an exemplary flowchart of a method 200 illustrating the operations of the configuration server 130 of the Kube-Edge configuration system 100 in determining a Kube-Edge pod configuration according to exemplary embodiments. The method 200 may refer to operations performed by the identification program 132, the offer program 134, the connection program 136, and the selection program 138 of the configuration server 130. Accordingly, the method 200 will be described from the perspective of the configuration server 130.

[0039] The configuration server 130 performs a query for units in a coverage area (step 202). The configuration server 130 can query the smart units 110 in a coverage area in several ways. In an example implementation, the configuration server 130 can use an active approach in which the configuration server 130 selects the coverage area and broadcasts or transmits a query signal for the selected coverage area. The smart units 110 currently located in the coverage area and capable of receiving the query signal can respond accordingly.In another example implementation, the configuration server 130 may use a passive approach, where the configuration server 130 is responsible for a coverage area and continuously broadcasts the query signal and waits for responses from smart devices 110 located within the coverage area. In another example implementation, the configuration server 130 may be configured using both the active and passive approaches.

[0040] The configuration server 130 determines whether there are any units in the coverage area for which the Kube-Edge Pod configuration is to be determined (decision 204). Based on the polling signal and the responses to the polling signal, the configuration server 130 can determine the presence of each of the smart units 110 in the coverage area. As a result of no smart units 110 being present in the coverage area (decision 204, branch "NO"), the configuration server 130 can use a default deployment. The default deployment can be a preselected deployment, for example, selected by an administrator. The default deployment can also be dynamically selected based on historical deployments and by selecting a more frequently used deployment.

[0041] As a result of at least one of the smart devices 110 being located in the coverage area (decision 204, branch "YES"), the configuration server 130 requests bid data from each device in the coverage area (step 206). In response to the polling signal, the configuration server 130 may receive polling data from the smart devices 110 in the coverage area. The polling data may include information about the smart devices 110 (e.g., availability information, location information, movement information, etc.) as well as bid information (e.g., information related to cost and / or resources of the smart devices 110).

[0042] The configuration server 130 determines whether any offering information or whether the intelligent devices 110 are available for the KubeEdge Pod configuration (decision 208). As a result of the configuration server 130 not receiving any offering data or determining that none of the intelligent devices 110 are available (decision 208, branch "NO"), the configuration server 130 may revert to a default deployment.

[0043] As a result of the configuration server 130 receiving bid data and determining that at least one of the smart devices 110 is available (decision 208, branch "YES"), the configuration server 130 determines a coverage rating for the coverage area based on the bid information (step 210). Since the bid information indicates the cost expenditures and resources of the smart devices 110 and the cloud service 120, the configuration server 130 can determine the coverage rating as an optimization analysis.

[0044] The configuration server 130 determines whether data on spatial-temporal relationships in social networks exists between or among the smart units 110 (step 212). Specifically, the configuration server 130 determines connection information about whether a pair of the smart units 110 can be connected or whether a plurality of the smart units 110 can be considered a set. When the smart units 110 are connected or grouped, the costs and / or resources can be re-evaluated, thereby reducing costs or saving resources. For example, when the smart units 110 can be connected, a storage operation can be shared by the hard disks of the connected smart units 110. In this way, the costs and / or resources of the smart units 110 in the service area can be re-evaluated.Accordingly, the configuration server 130 may determine a modified coverage rating based on the coverage rating and the connection information.

[0045] Using the modified coverage score (e.g., when connection information is available) or the coverage score (e.g., when no connection information is available), the configuration server 130 determines a configuration to use for the coverage area (step 214). In particular, the configuration server 130 may determine whether the Kube-Edge pod configuration should be stateful, meaning each pod has its own storage, or whether it should be stateless, meaning storage is shared by all pods, with storage being provided by one or more of the intelligent entities 110 in either deployment. The configuration server 130 may also determine how the selected deployment of the Kube-Edge pod configuration should be deployed by determining which of the intelligent entities 110 to use for storage functionality.

[0046] The exemplary embodiments are configured to determine a Kube-Edge Pod configuration for a coverage area of ​​a mobile environment in which one or more mobile devices may be present. Because mobile environments involve dynamic conditions where mobile devices enter and exit the coverage area, and each mobile device as an edge device has dynamic cost expenditures and resources associated with it, the exemplary embodiments dynamically determine the Kube-Edge Pod configuration by selecting between a stateful deployment or a stateless deployment based on the existing conditions of the coverage area.

[0047] According to various features, the exemplary embodiments utilize spatio-temporal analysis of social networks in the context of multi-unit availability to determine and enable an optimal Kube-Edge Pod configuration for a given mobile environment, enabling high coverage and availability with minimal incentives. The exemplary embodiments further utilize mobility patterns of mobile nodes and their interactive data transmission with peer nodes to generate Kube-Edge Pod configurations consistent with service scope objectives, spanning the spectrum from stateless to stateful options.The exemplary embodiments further consider standard parameters related to resources and cost and recognize a potential for connecting or grouping entities based on spatio-temporal social network analysis, which is used for a better trade-off between stateful and stateless Kube-Edges, thereby enabling better trade-off decisions.

[0048] Fig. 3 shows a block diagram of units within the Kube-Edge configuration system 100 of Fig. 1 according to the exemplary embodiments. It should be noted that Fig. 3 provides only an exemplary illustration of one embodiment and does not imply limitations regarding the environments in which various embodiments may be implemented. Many changes may be made to the illustrated environment.

[0049] Units used herein may include one or more processors 02, one or more computer-readable RAMs 04, one or more computer-readable ROMs 06, one or more computer-readable storage media 08, device drivers 12, a read / write drive or interface 14, a network adapter or network interface 16, all interconnected via a data transfer structure 18. The data transfer structure 18 may be implemented using any architecture designed for transferring data and / or control information between processors (such as microprocessors, data transfer and network processors, etc.), system memory, peripheral devices, and other hardware components within a system.

[0050] One or more operating systems 10 and one or more application programs 11 are stored on one or more of the computer-readable storage media 08 for execution by one or more of the processors 02 via one or more of the respective RAMs 04 (which typically include a cache memory). In the illustrated embodiment, the computer-readable storage media 08 may each be a magnetic disk storage device of an internal hard disk drive, a CD-ROM, a DVD, a memory stick, a magnetic tape, a magnetic disk, an optical disk, a semiconductor storage device such as RAM, ROM, EPROM, flash memory, or other computer-readable physical storage device capable of storing a computer program and digital information.

[0051] Units used herein may also include a read / write drive or a read / write interface 14 for reading from and writing to one or more portable, computer-readable storage media 26. The application programs 11 on the units may be stored on one or more of the portable, computer-readable storage media 26, read via the respective read / write drive or the respective read / write interface 14, and loaded into the respective computer-readable storage media 08.

[0052] Units used here may also include a network adapter or network interface 16, for example, a TCP / IP adapter card or a wireless data transmission adapter (e.g., a 4G wireless data transmission adapter using OFDM (OFDMA) technology). The application programs 11 on the data processing units can be downloaded to the data processing unit from an external computer or external storage device via a network (e.g., the Internet, a local area network, or another wide area or wireless network) and a network adapter or network interface 16. The programs can be loaded into the computer-readable storage media 08 via the network adapter or network interface 16.The network may include copper wires, fiber optic cables, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers.

[0053] Devices used herein may also include a display screen 20, a keyboard or keypad 22, and a computer mouse or touchpad 24. The device drivers 12 interface with the display screen 20 for imaging, the keyboard or keypad 22, the computer mouse or touchpad 24, and / or the display screen 20 for print scanning during alphanumeric character entry and user selection. The device drivers 12, the read / write drive or read / write interface 14, and the network adapter or network interface 16 may comprise hardware and software (stored in computer-readable storage media 08 and / or ROM 06).

[0054] The programs described herein are identified based on the application for which they are implemented in a particular embodiment of the exemplary embodiments. However, it should be noted that particular program nomenclature is used herein only for convenience, and therefore, the exemplary embodiments should not be limited to use in any particular application identified and / or implied by such nomenclature.

[0055] Based on the foregoing, a computer system, a method, and a computer program product have been disclosed. However, numerous changes and substitutions may be made without departing from the scope of the exemplary embodiments. Therefore, the exemplary embodiments have been disclosed only by way of example and not by way of limitation.

[0056] It should be understood that, although this disclosure includes a detailed description of cloud computing, implementation of the teachings herein is not limited to a cloud computing environment. Rather, the exemplary embodiments may be implemented in conjunction with any type of computing environment now known or later invented.

[0057] Cloud computing is a service delivery model for enabling seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four implementation models.

[0058] The properties are as follows: On-demand self-service: A cloud user can unilaterally and automatically provision data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider. Broad Network Access: Functions are available over a network and accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling: The provider's computing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control or knowledge over the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center). Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling out, in some cases automatically, and released quickly for rapid scale-in. To the user, the features available for deployment often appear unlimited, and they can be purchased in any quantity at any time. Measured Service: Cloud systems automatically control and optimize resource usage by leveraging a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, creating transparency for both the provider and the user of the service.

[0059] The service models are as follows: Software as a Service (SaaS): The functionality provided to the user is to use the provider's applications running in a cloud infrastructure. The applications are accessible from various client devices via a thin client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The functionality provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, into the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly over configurations of the application hosting environment. Infrastructure as a Service (IaaS): The functionality provided to the user consists of providing processing, storage, networking, and other basic computing resources, allowing the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

[0060] The deployment models are as follows: Private Cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can be located on its own premises or on a third-party site. Community Cloud: The cloud infrastructure is shared by multiple organizations and supports a specific user community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organizations or a third party and can be located on their own premises or on someone else's premises. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services. Hybrid Cloud: Cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain separate entities but are interconnected by a standardized or proprietary technology that enables data and application portability (e.g., cloud targeting for load balancing between clouds). A cloud computing environment is service-oriented, focusing on state independence, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure consisting of a network of interconnected nodes.

[0061] With reference to Fig. 4, the illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 40 with which local computing devices used by cloud users, such as the personal digital assistant (PDA) or cellular phone 54A, the desktop computer 54B, the laptop computer 54C, and / or the automotive computer system 54N, can communicate. The nodes 40 can communicate with each other. They can be physically or virtually grouped into one or more networks, such as private, community, public, or hybrid clouds (not shown), as described above, or a combination thereof. This enables the cloud computing environment 50 to offer infrastructure, platforms, and / or software as a service, for which a cloud user does not need to maintain resources on a local computing device.It should be noted that the types of in . Fig. 4 are intended to be merely illustrative, and that the computing nodes 40 and the cloud computing environment 50 may communicate with any type of computer-based device via any type of network and / or via any type of network-accessible connection (e.g., using a web browser).

[0062] With reference to Fig. 5, a set of functional abstraction layers is shown that are implemented by the cloud computing environment 50 ( Fig. 4) are provided. It should be clear from the outset that the Fig. The components, layers, and functions shown in Figure 5 are intended to be illustrative only, and the exemplary embodiments are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0063] A hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframe computers 61; Reduced Instruction Set Computer (RISC) architecture-based servers 62; servers 63; blade servers 64; storage units 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0064] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be deployed: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks, virtual applications and operating systems 74; and virtual clients 75.

[0065] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides for the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when using resources within the cloud computing environment, as well as billing or invoicing for the use of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service level management 84 provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment 85 provides the pre-arranging and procurement of cloud computing resources for which future requirements are anticipated, in accordance with an SLA.

[0066] A workload layer 90 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and Kube-Edge configuration processing 96.

[0067] The present invention may be a system, a method, and / or a computer program product at any possible technical level of integration. The computer program product may comprise a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to carry out aspects of the present invention.

[0068] The computer-readable storage medium may be any physical device capable of retaining and storing instructions for use by an instruction-executing system. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as containing transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light traveling through an optical fiber cable), or electrical signals transmitted through a wire.

[0069] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.

[0070] Computer-readable program instructions for performing operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, as well as conventional procedural programming languages ​​such as the C programming language or similar programming languages.The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, over the Internet using an Internet service provider).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.

[0071] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer-readable program instructions.

[0072] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing device to produce a machine such that the instructions executing via the processor of the computer or other programmable data processing device produce a means for implementing the functions / steps defined in the block(s) of flowchart and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored thereon comprises an article of manufacture, including instructions that implement aspects of the function / step defined in the block(s) of flowchart and / or block diagrams.

[0073] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-executable process such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / steps defined in the block(s) of flowcharts and / or block diagrams.

[0074] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this context, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for performing the particular logical function(s). In some alternative implementations, the functions specified in the blocks may occur in a different order than shown in the figures.For example, two blocks shown in sequence may actually execute in one step simultaneously, substantially simultaneously, partially or completely overlapping in time, or the blocks may sometimes execute in reverse order depending on the respective functionality. It should also be noted that each block of the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special-purpose hardware-based systems that perform the specified functions or steps, or by special-purpose hardware and computer instructions.

Claims

[1] A method implemented on a computer for determining a Kube-Edge pod configuration, the method comprising: Detecting (204) mobile units in a coverage area of ​​a mobile environment, the mobile units using a cloud service (120); Receiving (206) query data from the mobile devices, the query data comprising bid data indicating a corresponding cost and resource availability for each of the mobile devices operating as an edge device for the cloud service (120); Determining (208) connection information for the mobile units, the connection information indicating whether at least two of the mobile units are to be considered connected such that the connected mobile units have an associated cost and resource availability to provide data storage functionality shared by the connected mobile units by merging available storage of the connected mobile units; as a result of connecting the at least two mobile units, determining (210) a coverage assessment of the coverage area based on the offer data and the connection information, wherein the coverage assessment includes the associated cost expenditure of the at least two connected mobile units; and Selecting (214) a data storage provisioning scheme for pods of the cloud service (120) based on the supply assessment, wherein as a result of the supply assessment having a first result relative to a supply threshold, a stateless data storage provisioning scheme is selected, with storage shared by all pods, and as a result of the supply assessment having a second result relative to the supply threshold, a stateful datastore deployment scheme is selected, with each of the pods having its own storage. [2] The computer-implemented method of claim 1, wherein the query data further comprises identifying information about the mobile units, the identifying information comprising availability information, location information, movement information, and / or technical parameters for each of the mobile units. [3] The computer-implemented method of claim 1, wherein the offering data comprises information related to the availability of mobile resources and / or cost expenditures to serve as an edge entity and / or the resources required for the cloud service and / or a mobile availability time. [4] The computer-implemented method of claim 1, wherein the connection information is based on data of a spatial-temporal relationship in a social network of at least one of the mobile units and the users associated with the mobile units. [5] The computer-implemented method of claim 1, wherein determining the mobile units in the coverage area comprises: Broadcasting an interrogation signal in the coverage area, wherein receiving the query data from the mobile units is a result of the mobile units transmitting the query data upon receiving the query signal. [6] The computer-implemented method of claim 1, wherein determining the mobile units in the coverage area comprises: Selecting the coverage area; and Transmitting an interrogation signal to the mobile units in the coverage area, where the query data comes from the mobile units that receive the query signal. [7] A computer program product for determining a Kube Edge Pod configuration, the computer program product comprising: one or more non-volatile, computer-readable storage media and program instructions stored on the one or more non-volatile, computer-readable storage media capable of performing a method, the method comprising: Determining mobile units in a coverage area of ​​a mobile environment, the mobile units using a cloud service (120); Receiving query data from the mobile devices, the query data comprising bid data indicating a corresponding cost and resource availability for each of the mobile devices operating as an edge device for the cloud service (120); Determining connection information for the mobile units, the connection information indicating whether at least two of the mobile units are to be considered connected such that the connected mobile units have a connected cost and resource availability to provide data storage functionality shared by the connected mobile units by merging available storage of the connected mobile units; as a result of connecting the at least two mobile units, determining a coverage assessment of the coverage area based on the offer data and the connection information, wherein the coverage assessment includes the associated cost expenditure of the at least two connected mobile units; and Selecting a data storage deployment scheme for pods of the cloud service (120) based on the supply assessment, wherein as a result of the supply assessment having a first result relative to a supply threshold, a stateless data storage provisioning scheme is selected, with storage shared by all pods, and as a result of the supply assessment having a second result relative to the supply threshold, a stateful datastore deployment scheme is selected, with each of the pods having its own storage. [8] The computer program product of claim 7, wherein the query data further comprises identifying information about the mobile units, the identifying information comprising availability information and / or location information and / or movement information and / or technical parameters for each of the mobile units. [9] The computer program product of claim 7, wherein the offer data comprises information related to the availability of mobile resources and / or cost expenditures to serve as an edge unit and / or the resources required for the cloud service and / or a mobile availability time. [10] The computer program product of claim 7, wherein the connection information is based on data of a spatial-temporal relationship in a social network of at least one of the mobile units and the users associated with the mobile units. [11] The computer program product of claim 7, wherein determining the mobile units in the coverage area comprises: Broadcasting an interrogation signal in the coverage area, wherein receiving the query data from the mobile units is a result of the mobile units transmitting the query data upon receiving the query signal. [12] The computer program product of claim 7, wherein determining the mobile units in the coverage area comprises: Selecting the coverage area; and Transmitting an interrogation signal to the mobile units in the coverage area, where the query data comes from the mobile units that receive the query signal. [13] A computer system for determining a Kube-Edge pod configuration, the computer system comprising: one or more computer processors (02), one or more computer-readable storage media (08, 26) and program instructions stored on the one or more computer-readable storage media for execution by at least one of the one or more processors (02) capable of performing a method, the method comprising: Determining mobile units in a coverage area of ​​a mobile environment, the mobile units using a cloud service (120); Receiving query data from the mobile devices, the query data comprising bid data indicating a corresponding cost and resource availability for each of the mobile devices operating as an edge device for the cloud service (120); Determining connection information for the mobile units, the connection information indicating whether at least two of the mobile units are to be considered connected such that the connected mobile units have a connected cost and resource availability to provide data storage functionality shared by the connected mobile units by merging available storage of the connected mobile units; as a result of connecting the at least two mobile units, determining a coverage assessment of the coverage area based on the offer data and the connection information, wherein the coverage assessment includes the associated cost expenditure of the at least two connected mobile units; and Selecting a data storage deployment scheme for pods of the cloud service (120) based on the supply assessment, wherein as a result of the supply assessment having a first result relative to a supply threshold, a stateless data storage provisioning scheme is selected, with storage shared by all pods, and as a result of the supply assessment having a second result relative to the supply threshold, a stateful datastore deployment scheme is selected, with each of the pods having its own storage. [14] The computer system of claim 13, wherein the query data further comprises identifying information about the mobile units, the identifying information comprising availability information and / or location information and / or movement information and / or technical parameters for each of the mobile units. [15] The computer system of claim 13, wherein the offering data comprises information related to the availability of mobile resources and / or cost expenditures to serve as an edge unit and / or the resources required for the cloud service and / or a mobile availability time. [16] The computer system of claim 13, wherein the connection information is based on data of a spatial-temporal relationship in a social network of at least one of the mobile units and the users associated with the mobile units. [17] The computer system of claim 13, wherein determining the mobile units in the coverage area comprises: Broadcasting an interrogation signal in the coverage area, wherein receiving the query data from the mobile units is a result of the mobile units transmitting the query data upon receiving the query signal. [18] The computer system of claim 13, wherein determining the mobile units in the coverage area comprises: Selecting the coverage area; and Transmitting an interrogation signal to the mobile units in the coverage area, where the query data comes from the mobile units that receive the query signal.

Citation Information

Patent Citations

  • Multi-access edge computing (MEC) service provision based on local cost measurements

    US10110495B1

  • Cloud-edge topologies

    US20130166712A1

  • Service deployment for geodistributed edge clouds

    US20200322233A1

  • US000010110495B1