Pith. sign in

REVIEW 3 major objections 3 minor 35 references

LRScheduler: A Layer-aware and Resource-adaptive Container Scheduler in Edge Computing

T0 review · 3 major / 3 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A layer-aware Kubernetes scheduler plugin cuts average container download time by 39%.

desk verdict A working Kubernetes layer-aware scheduler with real measurements; the headline 39% reduction vs default holds up, but the text overclaims against the static-weight baseline and the layer-matching mechanism is underspecified. read the letter →

arxiv 2506.03694 v1 pith:ARJUDSAB submitted 2025-06-04 cs.DC

Zhiqing Tang , Wentao Peng , Jianxiong Guo , Jiong Lou , Hanshuai Cui , Tian Wang , Yuan Wu , Weijia Jia This is my paper
classification cs.DC
keywords containerschedulinglayer-awareKubernetesedgecomputingimagelayersdownloadcostloadbalancingschedulerplugin
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that container scheduling in edge computing can be made cheaper by exploiting the layered structure of container images, and it supports that claim with a working implementation. The scheduler periodically reads image-layer metadata from the Docker registry, matches it against layers already cached on each edge node, and scores each node by the fraction of the required image bytes it already holds. It then blends this layer-sharing score with the default Kubernetes scheduler score using a dynamic weight that favors layer sharing when a node is lightly loaded and favors balanced placement when load is high. On a real five-node Kubernetes cluster, the authors report an average 39% reduction in download time compared with the default scheduler while keeping node resource loads balanced.

What carries the argument

The load-bearing object is a per-node layer-sharing score $S_{\mathrm{Layer}}^{k,n}(t)$, the ratio of the size of requested layers already cached on the node to the total size of layers the container needs, scaled to 100. It is combined with the Kubernetes default score $S_{\mathrm{K8s}}^{k,n}(t)$ through a dynamic weight $\omega$ selected by an Iverson-bracket condition that checks three thresholds: cached layer size above $h_{\mathrm{size}}$, CPU usage below $h_{\mathrm{CPU}}$, and resource-balance standard deviation below $h_{\mathrm{STD}}$. This score is what reduces image downloads, and the threshold condition is what keeps node loads balanced.

What would settle it

Log the exact layer matches LRScheduler uses for each deployment, then compare each chosen node's matched cached-layer size with the bytes Docker actually had before the pull; if any logged score disagrees with the real cached bytes, the 39% average reduction is not reproducible as stated.

Watch

Extended reading notes

Core claim

The central claim is that layer sharing can be turned into an automatic scheduling signal inside Kubernetes. When a container is requested, the scheduler computes $S_{\mathrm{Layer}}^{k,n}(t) = 100 \cdot D_n^c(t) / \sum_{l \in L_c} d_l$, where $D_n^c(t)$ is the total size of requested layers already cached on node $n$ and $d_l$ is the size of layer $l$. It then forms the final score $S^{k,n}(t) = \omega \cdot S_{\mathrm{Layer}}^{k,n}(t) + S_{\mathrm{K8s}}^{k,n}(t)$ with the default scheduler score, and the node with the highest score gets the container. The weight $\omega$ is switched between a high value ($\omega_1=2$) when the node is idle and balanced and has enough cached bytes, and a low value ($\omega_2=0.5$) otherwise. The authors report that this plugin, running in a five-node Kubernetes cluster, reduces average download time by 39% compared with the default scheduler while keeping node loads balanced.

Load-bearing premise

The layer-sharing score assumes the registry metadata cached in cache.json matches the layer identities the Docker API reports on every node; if those two sources disagree, the score in Eq. (3) is meaningless and LRScheduler degenerates to the default scheduler with arbitrary weights.

Editorial extensions

If this is right

  • Edge clusters with limited bandwidth can deploy the same workloads with less image traffic, because layers already cached on the chosen node are reused instead of downloaded.
  • The savings are largest when bandwidth is scarce, matching the paper's observation that the advantage becomes more pronounced at low bandwidth.
  • Operators can keep using existing Kubernetes scheduling policies such as affinity, taints, and topology spread alongside the layer score, since the plugin only adds a weighted scoring extension point.
  • Repeated deployments of similar images accumulate savings, as the 20-container run shows cumulative download size staying below the default scheduler.
  • The trade-off between layer sharing and load balancing can be tuned through the two weight values and the three thresholds, giving operators a direct knob for their own cost model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the same layer-matching data could drive eviction and scale-down decisions, choosing to remove images with the least overlap with future workloads and thereby extending savings beyond initial placement.
  • Editorial inference: the claimed 39% reduction depends on layer identities matching between the registry metadata and node-local Docker data; in a deployment where the Docker API is not exposed, the score would be meaningless and the scheduler would silently behave like the default one.
  • Editorial inference: the dynamic-weight thresholds are effectively a hand-set cost model, so tuning them with reinforcement learning, which the paper names as future work, could make the trade-off adapt to changing workload mixes.
  • Editorial inference: extending the registry watcher to multiple registries or to cloud-edge layer transfer would require adding network-transfer latency into the score rather than relying only on local cache presence.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 3 minor

Summary. The paper proposes and implements LRScheduler, a Kubernetes scheduling plugin for edge clusters that combines a layer-sharing score with the default scheduler score. The layer-sharing score in Eq. (3) measures the fraction of the requested container image already cached on each node, and Eq. (13) dynamically changes its weight according to a node's CPU usage, resource-balance proxy, and cached-layer size. The system is implemented on the Kubernetes scheduling framework and evaluated on a real cluster of 3-5 nodes with 20 container deployments and several bandwidth settings. The main reported result is a 39% average reduction in download time relative to the default scheduler while preserving resource balance.

Significance. If the implementation premise is reliable, the paper makes a useful practical contribution: it demonstrates that a layer-aware scoring plugin can be built inside the standard Kubernetes scheduling framework, with automatic registry metadata retrieval and dynamic weighting to trade off layer reuse against load balance. The architecture description and scalability discussion are concrete, and the direction of the main comparison is supported: summing Table I gives about 4021 MB and 1612 s for the default scheduler versus about 2502 MB and 1022 s for LRScheduler. The paper also honestly reports the trade-off that the static-weight Layer scheduler achieves even lower download cost at the expense of worse resource balance. At the same time, the experimental claim depends on an implementation detail that is not documented or verifiable from the manuscript, and one textual claim about Table I is contradicted by the table's own sums.

major comments (3)
  1. [Section V.2, steps 3-5] The layer-sharing score in Eq. (3) is only meaningful if L_n(t), the set of cached layers on each node, is known exactly. The paper obtains this set by calling the Docker API at http://IP:2375, retrieving cached image names/tags, and then looking those tags up in the registry-derived cache.json. The manuscript does not state whether the Docker daemon's remote API was enabled in the test cluster, how the tag-to-layer mapping in cache.json is kept consistent with the actual image state on each node, how stale tags or images pulled by digest are handled, or what the exact matching rule is. The reference to 'Listing ??' is also broken, and no source code is provided. Without this information, the 39% download-time reduction cannot be independently verified; if the Docker API is not reachable or cache.json is stale, the layer score becomes wrong or zero and LRScheduler degenerates to the default scheduler plus a constant weight.
  2. [Section VI, paragraph after Fig. 4 and Table I] The text states that 'While LRScheduler may not have the smallest download size at each step, it ultimately results in the lowest total download cost and time.' This is contradicted by Table I: summing the download sizes and times gives about 2475 MB and 1012 s for the static-weight Layer scheduler, versus about 2502 MB and 1022 s for LRScheduler. LRScheduler is the lowest only among the default-scheduler comparison, not among all three schedulers. This overclaim should be corrected, and the comparison with the static-weight Layer scheduler should be discussed consistently with the preceding sentence that 'the Layer scheduler reduces costs further but increases the STD.'
  3. [Sections IV.A and VI.A] The resource-adaptive mechanism is one of the two central contributions, but the thresholds and weights in Eq. (13) are given only as fixed values (h_size=10, h_CPU=0.6, h_STD=0.16, omega_1=2, omega_2=0.5) with no sensitivity analysis or justification. Since the claimed advantage over a static-weight Layer scheduler rests on these parameters, the paper should at least show how the download cost and the STD metric vary over a range of these values, or justify the chosen values from cluster characteristics. Without this, it is difficult to assess whether the adaptive weighting is robust or tuned specifically to the reported experiment.
minor comments (3)
  1. [Section V.2, Listing 1] The listing reference appears as 'Listing ??' in the text, and several field names appear to contain typos, such as 'CatchFile' and the JSON tag 'name_without_repo'; these should be fixed for clarity.
  2. [Section IV.A, Eq. (11)] The quantity S_k,n_STD(t) is called a standard deviation but is actually half the absolute normalized difference between CPU and memory usage. This is a valid imbalance indicator, but the label 'STD' and the y-axis 'Average Standard Deviation' in Fig. 3(f) and the 'STD' column in Table I should be replaced with a name such as 'resource-imbalance score' to avoid misleading readers.
  3. [Section VI.A] The experimental description says images and resource limits are chosen randomly, but does not report the random seed, the number of repeated runs, or confidence intervals. Adding these details, or at least stating that each presented number is a single run, would improve reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Eq. (3) is a monotone transform of Eq. (1), but the reported 39% reduction is an empirical comparison against the default Kubernetes scheduler, not a consequence of the equations alone.

full rationale

The paper defines the download cost C_n^c(t) in Eq. (1) and the layer sharing score S_Layer in Eq. (3) as a normalized version of the complementary cached-bytes term D_n^c(t). Maximizing Eq. (3) is therefore equivalent to minimizing Eq. (1) by construction. This is not a hidden circularity, however: the paper states this equivalence explicitly ('The aim of layer-aware scheduler is to minimize the download cost, i.e., maximize the layer sharing score') and uses it as the scheduling objective, not as a prediction. The central claimed result — that LRScheduler reduces download time by an average of 39% versus the default scheduler — is supported by a real-system comparison in Section VI, where download sizes and times are measured outcomes of the Kubernetes cluster, including the influence of the default-scheduler component S_K8s and the dynamic weights of Eq. (13). Those weights and thresholds (omega1=2, omega2=0.5, hsize=10, hCPU=0.6, hSTD=0.16) are hand-set rather than fitted to the reported outcome. The paper cites prior work by the same authors (e.g., [2], [6], [19]) for background and problem context, but no load-bearing step reduces to such a self-citation. The main weakness is an unverified implementation premise (the Docker API/cache.json handshake in Section V.2, the broken Listing 1 reference, and no supplied code), which is a correctness and reproducibility concern, not a circularity.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The algorithm depends on five hand-set thresholds and on the ability to retrieve and match layered-image metadata from a registry and from each node's Docker daemon. These are not derived from theory or validated with sensitivity analysis, and the paper provides no code or data to check them.

free parameters (5)
  • omega_1 = 2
    Layer-sharing weight applied when the dynamic condition in Eq. (13) is satisfied; value chosen by hand, no sensitivity analysis.
  • omega_2 = 0.5
    Layer-sharing weight applied when Eq. (13) is not satisfied; chosen by hand.
  • h_size = 10
    Threshold for cached layer size (units not stated) in Eq. (13); chosen by hand.
  • h_CPU = 0.6
    CPU utilization threshold in Eq. (13); chosen by hand.
  • h_STD = 0.16
    Resource-balance threshold in Eq. (13); chosen by hand.
assumptions (4)
  • domain assumption Download cost dominates container startup cost, so deployment cost can be modeled as the sum of missing layer sizes.
    Section III-B states that the paper focuses on download cost, citing [2], without empirical support in this paper.
  • domain assumption Container image layers are independent and additive, and layer IDs and sizes can be obtained from the registry and the Docker API on each node.
    Section V.2 assumes the scheduler can match required layers with node-cached layers via metadata from cache.json and the Docker API.
  • ad hoc to paper The dynamic-weight triggering condition in Eq. (13) is a reasonable proxy for low load and balanced resources.
    No derivation justifies the product-of-Iverson-brackets form or the specific thresholds; it is a heuristic choice.
  • domain assumption Kubernetes scheduling framework extension points and the Docker registry /v2/_catalog endpoint behave as documented.
    Section V relies on these interfaces working in a real cluster, and no failure handling is described.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LRScheduler: A Layer-aware and Resource-adaptive Container Scheduler in Edge Computing." pith.science (2026). https://pith.science/paper/ARJUDSAB

@misc{pith2026250603694,
  author       = {Pith},
  title        = {Pith review of: LRScheduler: A Layer-aware and Resource-adaptive Container Scheduler in Edge Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ARJUDSAB}},
  note         = {Machine review of arXiv:2506.03694}
}
read the original abstract

Lightweight containers provide an efficient approach for deploying computation-intensive applications in network edge. The layered storage structure of container images can further reduce the deployment cost and container startup time. Existing researches discuss layer sharing scheduling theoretically but with little attention paid to the practical implementation. To fill in this gap, we propose and implement a Layer-aware and Resource-adaptive container Scheduler (LRScheduler) in edge computing. Specifically, we first utilize container image layer information to design and implement a node scoring and container scheduling mechanism. This mechanism can effectively reduce the download cost when deploying containers, which is very important in edge computing with limited bandwidth. Then, we design a dynamically weighted and resource-adaptive mechanism to enhance load balancing in edge clusters, increasing layer sharing scores when resource load is low to use idle resources effectively. Our scheduler is built on the scheduling framework of Kubernetes, enabling full process automation from task information acquisition to container dep=loyment. Testing on a real system has shown that our design can effectively reduce the container deployment cost as compared with the default scheduler.

Figures

Figures reproduced from arXiv: 2506.03694 by the authors.

Figure 1
Figure 1. Overview of LRScheduler some basic schedulers requiring prior knowledge of layer in￾formation [4]. To fill in such gaps, we develop a custom layer￾aware scheduler within the Kubernetes scheduling framework that automatically retrieves and updates layer information from the Docker registry, integrating seamlessly with Kubernetes deployments [21]. Layer information is periodically retrieved from the registry and cache… view at source ↗
Figure 2
Figure 2. LRScheduler implementation in Kubernetes system [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Performance with different number of nodes [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Performance with different bandwidth                 & #!" !(!$ [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Accumulated download size for 20 pods layer sharing and resource balancing [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

35 extracted references · 33 canonical work pages

  1. [1]

    Edge computing: Vision and challenges,

    W. Shi, J. Cao, Q. Zhang, Y . Li, and L. Xu, “Edge computing: Vision and challenges,” IEEE internet of things journal , vol. 3, no. 5, pp. 637–646, 2016

    2016

  2. [2]

    Layer dependency-aware learning schedul- ing algorithms for containers in mobile edge computing,

    Z. Tang, J. Lou, and W. Jia, “Layer dependency-aware learning schedul- ing algorithms for containers in mobile edge computing,” IEEE Trans- actions on Mobile Computing , vol. 22, no. 6, pp. 3444–3459, 2023

    work page 2023

  3. [3]

    Efficient live migration of edge services leveraging container layered storage,

    L. Ma, S. Yi, N. Carter, and Q. Li, “Efficient live migration of edge services leveraging container layered storage,” IEEE Transactions on Mobile Computing, vol. 18, no. 9, pp. 2020–2033, 2018

    work page 2020

  4. [4]

    Fast and efficient container startup at the edge via dependency scheduling,

    S. Fu, R. Mittal, L. Zhang, and S. Ratnasamy, “Fast and efficient container startup at the edge via dependency scheduling,” in Proceedings of 3rd USENIX Workshop on Hot Topics in Edge Computing (HotEdge) , 2020

    work page 2020

  5. [5]

    Kubernetes scheduling: Taxonomy, ongoing issues and challenges,

    C. Carri ´on, “Kubernetes scheduling: Taxonomy, ongoing issues and challenges,” ACM Computing Surveys , vol. 55, no. 7, pp. 1–37, 2022

    work page 2022

  6. [6]

    Multi-user layer- aware online container migration in edge-assisted vehicular networks,

    Z. Tang, F. Mou, J. Lou, W. Jia, Y . Wu, and W. Zhao, “Multi-user layer- aware online container migration in edge-assisted vehicular networks,” IEEE/ACM Transactions on Networking, vol. 32, no. 2, pp. 1807–1822, 2024

    2024

  7. [7]

    Latency-aware container scheduling in edge cluster upgrades: A deep reinforcement learning approach,

    H. Cui, Z. Tang, J. Lou, W. Jia, and W. Zhao, “Latency-aware container scheduling in edge cluster upgrades: A deep reinforcement learning approach,” IEEE Transactions on Services Computing , 2024

    work page 2024

  8. [8]

    On-demand container loading in {AWS} lambda,

    M. Brooker, M. Danilov, C. Greenwood, and P. Piwonka, “On-demand container loading in {AWS} lambda,” in Proceedings of 2023 USENIX Annual Technical Conference (USENIX ATC 23) , 2023, pp. 315–328

    work page 2023

Show all 35 references
  1. [9]

    Custom scheduling in kubernetes: A survey on common problems and solution approaches,

    Z. Rejiba and J. Chamanara, “Custom scheduling in kubernetes: A survey on common problems and solution approaches,” ACM Computing Surveys, vol. 55, no. 7, pp. 1–37, 2022

    2022

  2. [10]

    H-container: Enabling heterogeneous-isa container migration in edge computing,

    T. Xing, A. Barbalace, P. Olivier, M. L. Karaoui, W. Wang, and B. Ravin- dran, “H-container: Enabling heterogeneous-isa container migration in edge computing,” ACM Transactions on Computer Systems , vol. 39, no. 1-4, pp. 1–36, 2022. TABLE I: Performance analysis for 20 contain...

    2022

  3. [11]

    Extend cloud to edge with kubeedge,

    Y . Xiong, Y . Sun, L. Xing, and Y . Huang, “Extend cloud to edge with kubeedge,” in Proceedings of 2018 IEEE/ACM Symposium On Edge Computing (SEC). IEEE, 2018, pp. 373–377

    2018

  4. [12]

    [Online]

    K3s: Lightweight kubernetes. [Online]. Available: https://k3s.io

  5. [13]

    [Online]

    Akraino. [Online]. Available: https://www.lfedge.org/projects/akraino/

  6. [14]

    [Online]

    Qos based scheduling system koordinator. [Online]. Available: https://koordinator.sh

  7. [15]

    [Online]

    V olcano. [Online]. Available: https://volcano.sh

  8. [16]

    [Online]

    Katalyst. [Online]. Available: https://gokatalyst.io

  9. [17]

    Lopo: An out-of- order layer pulling orchestration strategy for fast microservice startup,

    L. Gu, J. Huang, S. Huang, D. Zeng, B. Li, and H. Jin, “Lopo: An out-of- order layer pulling orchestration strategy for fast microservice startup,” in Proceedings of 2023 IEEE Conference on Computer Communications (INFOCOM). IEEE, 2023, pp. 1–9

    2023

  10. [18]

    Layer aware microservice placement and request scheduling at the edge,

    L. Gu, D. Zeng, J. Hu, B. Li, and H. Jin, “Layer aware microservice placement and request scheduling at the edge,” in Proceedings of 2021 IEEE Conference on Computer Communications (INFOCOM) . IEEE, 2021, pp. 1–9

    2021

  11. [19]

    Efficient container assignment and layer sequencing in edge computing,

    J. Lou, H. Luo, Z. Tang, W. Jia, and W. Zhao, “Efficient container assignment and layer sequencing in edge computing,”IEEE Transactions on Services Computing , vol. 16, no. 2, pp. 1118–1131, 2022

    2022

  12. [20]

    [Online]

    Scheduling framework. [Online]. Available: https://kubernetes.io/docs/ concepts/scheduling-eviction/scheduling-framework/

  13. [21]

    [Online]

    Deployments. [Online]. Available: https://kubernetes.io/docs/concepts/ workloads/controllers/deployment/

  14. [22]

    Fifer: Tackling resource underutilization in the serverless era,

    J. R. Gunasekaran, P. Thinakaran, N. C. Nachiappan, M. T. Kandemir, and C. R. Das, “Fifer: Tackling resource underutilization in the serverless era,” in Proceedings of the 21st International Middleware Conference (Middleware), 2020, pp. 280–295

    2020

  15. [23]

    [Online]

    Scheduler configuration. [Online]. Available: https://kubernetes.io/docs/ reference/scheduling/config/

  16. [24]

    Exploring the layered structure of containers for design of video analytics application migration,

    C. Rong, J. H. Wang, J. Liu, T. Yu, and J. Wang, “Exploring the layered structure of containers for design of video analytics application migration,” in 2022 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, 2022, pp. 842–847

    2022

  17. [25]

    Layer- aware containerized service orchestration in edge networks,

    M. Dolati, S. H. Rastegar, A. Khonsari, and M. Ghaderi, “Layer- aware containerized service orchestration in edge networks,” IEEE Transactions on Network and Service Management , vol. 20, no. 2, pp. 1830–1846, 2022

    2022

  18. [26]

    How to share: balancing layer and chain sharing in industrial microservice deployment,

    Y . Liu, B. Yang, Y . Wu, C. Chen, and X. Guan, “How to share: balancing layer and chain sharing in industrial microservice deployment,” IEEE Transactions on Services Computing , vol. 16, no. 4, pp. 2685–2698, 2022

    2022

  19. [27]

    Edge-based communication optimization for distributed federated learning,

    T. Wang, Y . Liu, X. Zheng, H.-N. Dai, W. Jia, and M. Xie, “Edge-based communication optimization for distributed federated learning,” IEEE Transactions on Network Science and Engineering , vol. 9, no. 4, pp. 2015–2024, 2021

    2015

  20. [28]

    An intelligent dynamic offloading from cloud to edge for smart iot systems with big data,

    T. Wang, Y . Liang, Y . Zhang, X. Zheng, M. Arif, J. Wang, and Q. Jin, “An intelligent dynamic offloading from cloud to edge for smart iot systems with big data,” IEEE Transactions on Network Science and Engineering, vol. 7, no. 4, pp. 2598–2607, 2020

    2020

  21. [29]

    Harnessing edge computing resources for accelerating industrial tasks,

    T. Xing, H. Cui, Y . Chen, Z. Luo, B. Guo, Z. Yu, X. Guo, and Y . Ma, “Harnessing edge computing resources for accelerating industrial tasks,” in Proceedings of 2023 19th International Conference on Mobility, Sensing and Networking (MSN) . IEEE, 2023, pp. 652–659

    2023

  22. [30]

    Online resource allocation for edge intelligence with colocated model retraining and inference,

    H. Cai, Z. Zhou, and Q. Huang, “Online resource allocation for edge intelligence with colocated model retraining and inference,” in Proceedings of 2024 IEEE Conference on Computer Communications (INFOCOM). IEEE, 2024, pp. 1–9

    2024

  23. [31]

    Dynamic edge- centric resource provisioning for online and offline services co-location,

    T. Ouyang, K. Zhao, X. Zhang, Z. Zhou, and X. Chen, “Dynamic edge- centric resource provisioning for online and offline services co-location,” in Proceedings of 2023 IEEE Conference on Computer Communications (INFOCOM). IEEE, 2023, pp. 1–10

    2023

  24. [32]

    Dynamic parallel multi-server selection and allocation in collaborative edge computing,

    C. Xu, J. Guo, Y . Li, H. Zou, W. Jia, and T. Wang, “Dynamic parallel multi-server selection and allocation in collaborative edge computing,” IEEE Transactions on Mobile Computing , 2024

    2024

  25. [33]

    Dynamic task offloading and resource allocation for noma-aided mobile edge computing: An energy efficient design,

    Y . Chen, J. Xu, Y . Wu, J. Gao, and L. Zhao, “Dynamic task offloading and resource allocation for noma-aided mobile edge computing: An energy efficient design,” IEEE Transactions on Services Computing , 2024

    2024

  26. [34]

    Joint channel estimation and reinforcement learning-based resource allocation of intelligent reflecting surface-aided multicell mobile edge computing,

    W. Xu, J. Yu, Y . Wu, and D. H.-K. Tsang, “Joint channel estimation and reinforcement learning-based resource allocation of intelligent reflecting surface-aided multicell mobile edge computing,”IEEE Internet of Things Journal, 2023

    2023

  27. [35]

    Large-scale analysis of docker images and performance implications for container storage systems,

    N. Zhao, V . Tarasov, H. Albahar, A. Anwar, L. Rupprecht, D. Skourtis, A. K. Paul, K. Chen, and A. R. Butt, “Large-scale analysis of docker images and performance implications for container storage systems,” IEEE Transactions on Parallel and Distributed Systems , vol. 32, no. ...

    2020

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.