Bibliographic record
Abstract
Fog computing recently emerged as a novel distributed virtualized computing paradigm, where cloud services are extended to the edge of the network, thereby increasing network capacity and reducing latencies for distributed IoT applications. A fog network consists of communication between resource-constrained fog nodes, which are computational networking storage and acceleration devices. By adopting the microservice architecture, applications are designed as a collection of independent and loosely coupled modular services called microservices installed in application containers. The placement problem is to efficiently allocate limited fog resources to applications with diverse resource requirements. This determines the overall system performance in terms of energy consumption, communication cost, load balancing and others. Placement of microservices can be done in two ways which presents a tradeoff between two placement objectives. The first strategy is placing maximal communicating microservices on each fog node. This keeps the chaining costs between the microservices low, but at the same time, it leads to high utilization at some fog nodes. Also, this strategy may not be feasible due to limited resources at fog nodes. On the other hand, the second strategy is to split communicating microservices over a network of fog nodes. This leads to data exchange between the fog nodes, which is referred to as communication cost. This strategy results in a load-balanced system, but at the same time, increases communication costs. We want low energy consumption at fog nodes and low communication costs of the applications. Placement strategies for cloud computing are generally centralized and not well suited for decentralized fog systems. Therefore distributed solutions with self-organization and management capabilities are required for efficient allocation of fog resources to applications with diverse resource requirements.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.003 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.002 |
| Science and technology studies | 0.003 | 0.001 |
| Scholarly communication | 0.006 | 0.004 |
| Open science | 0.002 | 0.004 |
| Research integrity | 0.003 | 0.002 |
| Insufficient payload (model declined to judge) | 0.592 | 0.388 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".