PaperlayerView exact revision on arXiv

Source-linked AI summary

On Reducing IoT Service Delay via Fog Offloading

Ashkan Yousefpour, Genya Ishigaki, Riti Gour, Jason P. Jue

arXiv:1804.07376v1cs.NI

TL;DR

IoT applications require low latency, but cloud-centered processing can incur high response times and costly data transfer. This paper presents a general IoT-fog-cloud framework, a delay-minimizing offloading policy, and an analytical model; numerical results show reduced service delay.

  • Problem

    Cloud-centered IoT systems can face high response times and costly communication when large, redundant sensor data is sent to distant cloud servers.

  • Method

    The paper combines a general IoT-fog-cloud service-delay framework and analytical model with an offloading policy that shares load across fog nodes while accounting for request processing times and network interactions.

  • Results

    AFP generally achieves the lowest average service delay among AFP, LFP, and NFP, reducing light-task delay from 60 ms to 18 ms and heavy-task delay from 150 ms to 117 ms in one setting.

  • Takeaways & Limitations

    The framework and numerical evaluations support fog offloading as a way to reduce IoT service delay and use analytical modeling to describe policy performance.

Abstract

from arXiv · show

With the Internet of Things (IoT) becoming a major component of our daily life, understanding how to improve the quality of service (QoS) for IoT applications through fog computing is becoming an important problem. In this paper, we introduce a general framework for IoT-fog-cloud applications, and propose a delay-minimizing collaboration and offloading policy for fog-capable devices that aims to reduce the service delay for IoT applications. We then develop an analytical model to evaluate our policy and show how the proposed framework helps to reduce IoT service delay.

I. INTRODUCTION

The paper frames fog computing as an intermediate layer for reducing IoT service delay and presents a general, topology-independent IoT-fog-cloud framework and offloading policy.

  • Motivation: Cloud infrastructure supports IoT applications but can impose high response time and heavy server load because it is distant from end users.
  • Motivation: Moving applications, storage, and processing closer to IoT-generated data can reduce communication bandwidth costs and handle redundant sensor data more efficiently.
  • Fog Computing: Fog computing places cloud services nearer to users, providing low latency, location awareness, and geographically distributed computation, storage, and networking.
  • Related Work: The paper distinguishes dynamic fog offloading from static task assignment, whose global parameter knowledge and high complexity may limit practicality.
  • Contribution: The proposed policy supports arbitrary numbers and topologies of fog nodes while considering IoT-to-cloud, fog-to-cloud, and fog-to-fog interactions.
  • Framework: The framework contains IoT, fog, and cloud layers partitioned into application-specific domains, with requests processed locally or forwarded across layers.

III. FOG NODE COLLABORATION POLICY

The collaboration policy lets fog nodes process requests when capacity permits and otherwise share load through neighboring fog nodes or the cloud. It combines queueing, processing-time, and communication-delay information to choose forwarding actions.

  • Modes of Interaction: The policy offers centralized and distributed interaction modes; the paper chooses distributed interaction to avoid a dedicated central node and support less-static fog networks.
  • Modes of Interaction: Fog nodes select a neighboring node using estimated waiting time plus half the round-trip delay, and may perform multiple offloads when neighbors remain busy.
  • When to Offload a Task: The policy distinguishes Light and Heavy requests because their processing times differ across fog nodes and cloud servers.
  • When to Offload a Task: A fog node accepts a request when its estimated waiting time is below threshold θ_j; otherwise, it offloads the request to a neighbor or the cloud.
  • When to Offload a Task: Offloading is most useful when fog-node loads vary substantially, whereas it provides little benefit when all nodes are lightly or heavily loaded.

D. Checking and Updating Queue Status

The model represents IoT-fog-cloud applications and formulates average IoT service delay across local, fog, and cloud processing paths. Requests carry type information, while probabilities and mapping functions describe where processing occurs.

  • Queue status: Requests identify Light or Heavy processing types in their headers so fog nodes can update queue parameters.The application sets this field in packets generated by IoT nodes.
  • Network model: The network is modeled as an undirected graph containing IoT nodes, fog nodes, and cloud servers, with edges weighted by propagation delay and transmission rate.The topology is unrestricted except for the logical three-layer architecture.
  • Service delay: Service delay accounts for local processing, fog processing and handling, or direct cloud processing, selected through probabilities pI_i, pF_i, and pC_i.The probabilities satisfy pI_i + pF_i + pC_i = 1, while path delays include propagation, transmission, queueing, and processing terms.
  • Application model: An IoT-fog-cloud application Ψ(N, M, P) is defined over cloud-server domain N, fog-node domain M, and IoT-node domain P.Examples include video processing, temperature sensor reporting, traffic road analysis, and oil-rig pressure monitoring.
  • Optimization objective: The analytical objective is to minimize the average service delay of IoT nodes in application domain P.The model defines this objective over the IoT nodes in domain P and the associated fog and cloud domains.

C. Propagation and Transmission Delays

The delay model separates propagation and transmission components for communication between IoT, fog, and cloud layers. Transmission delay is computed from generated data and link rates, while multi-hop paths sum delays across links.

  • Layer-to-layer communication: Propagation and transmission delays are defined separately for communication between IoT, fog, and cloud layers.The model derives analogous expressions for IoT-cloud and fog-cloud transmission paths.
  • IoT-cloud paths: IoT-cloud propagation and transmission terms apply when requests go directly to the cloud, when fog is absent, or when archival storage requires cloud delivery.These terms are included in the service-delay equation for those cases.
  • Transmission delay: The transmission delay between IoT node i and fog node j is the sum of transmission delays over all links on their path.For each link, the delay depends on the request data amount and transmission rate; corresponding inter-layer expressions are derived similarly.

D. Processing Delay of IoT node

The model combines IoT processing delay with fog-layer handling and bounded fog-to-fog offloading. Processing delay reflects Light and Heavy request mixtures, while recursive terms capture forwarding and cloud fallback.

  • IoT processing: The average IoT processing delay A_i is determined by the probabilities and mean processing times of Light and Heavy requests.For exclusively Light or Heavy IoT nodes, A_i equals the corresponding single-type processing-time parameter.
  • Fog-layer processing: Fog-layer delay L_ij recursively includes queue acceptance, waiting, return communication, neighbor forwarding, and eventual cloud processing.The first fog node may process the request, forward it to its best neighbor, or send it to an associated cloud server after the forwarding limit.
  • Offloading policy: The offloading function φ(x) sends a request to another fog node while x < e_M and to the cloud when x = e_M.The integer x counts fog-layer offloads, and e_M is the forwarding limit.
  • Mapping functions: The mappings best(j) and h(j) select a fog node’s current best neighbor and associated cloud server.The best-neighbor choice depends on the current system state, so best(j) is dynamic.
  • Boundary case: When no fog forwarding is allowed, a request rejected by a fog queue is offloaded directly to the cloud.The boundary case e_M = 0 reduces the recursive path to fog acceptance or cloud fallback.

F. Average Waiting Time of Fog Node

Fog-node waiting time is derived from a two-class Markovian queueing model. Its steady-state analysis tracks Light and Heavy request counts and incorporates a fairness parameter governing service selection.

  • Steady-state analysis: Steady-state probabilities are obtained by modeling the queue as a two-dimensional Markov chain with transitions between Light and Heavy request-count states.The transition rates are defined from the state diagram and state-dependent selection function.
  • Queueing model: Fog nodes are modeled as single-server queues with Poisson Light and Heavy arrivals and exponentially distributed processing times.This yields Markovian queueing systems with multi-class traffic.
  • State representation: The queue state (n, n′) records the numbers of Light and Heavy requests at fog node j, including the request in service when applicable.The state probabilities support calculation of the fog node’s average waiting time W_j.
  • Service discipline: The fairness parameter q controls which request class receives priority when selecting the next job from segregated Light and Heavy queues.Values closer to 0 prioritize Heavy requests, values closer to 1 prioritize Light requests, and q = 0.5 gives proportional selection by class count.

H. Acceptance Probability: Pj

The acceptance probability Pj depends on whether fog node j’s estimated waiting time is below threshold θj. The waiting-time distribution is derived from sums of Light and Heavy request-processing delays, using gamma distributions and Laplace-transform convolution.

  • Acceptance rule: Pj is the probability that a request enters fog node j’s queue and depends on the node’s queuing state.When estimated waiting time exceeds θj, the request is offloaded to the best neighbor.
  • Acceptance probability derivation: The acceptance probability is evaluated from the waiting-time distribution, including the event P[Wj < θj].The derivation expands the state summation into four cases based on whether Light and Heavy request counts are zero or positive.
  • Waiting-time model: The waiting time Wj equals the sum of processing delays for all Light and Heavy requests currently in fog node j.The delays are grouped as Xj for Light requests and Yj for Heavy requests, so Wj = Xj + Yj.
  • Waiting-time model: Sums of exponentially distributed processing delays produce gamma-distributed components for the Light and Heavy waiting times.The component distributions use parameters based on the number of requests and their service rates.
  • Acceptance probability derivation: The PDF of the total waiting time is obtained by convolving the independent Light- and Heavy-request delay distributions.The corresponding Laplace transform is the product of the component transforms.

I. Arrival Rates to Fog Nodes

Fog-node arrival rates combine requests from associated IoT nodes with requests offloaded by neighboring fog nodes. The model recursively determines accepted and forwarded traffic through neighbor relationships and the offload limit.

  • Incoming traffic: Incoming Light traffic vj to fog node j consists of associated-IoT traffic Ij and offloaded traffic δj1, δj2, …, δjeM from neighboring fog nodes.The figure presents this traffic model for Light requests.
  • Arrival-rate equations: Fog node j’s Light-request arrival rate λj is determined from its incoming traffic and acceptance probability Pj.The Light-request queueing analysis is developed first; the Heavy-request rate λ′j is derived similarly.
  • Offloading flows: Requests rejected by fog node j are sent to its best neighbor or, after the offload limit eM, to the cloud.The forwarded traffic is labeled βj1 through βjeM, while cloud-bound traffic is labeled Cj.
  • Incoming traffic: The associated-IoT arrival rate Ij is obtained from the IoT nodes mapped to fog node j.The mapping function f^-1(j) identifies the set of IoT nodes sending requests to j.
  • Offloading flows: The recursive forwarding equations relate rejected traffic δjl to next-hop traffic βj(l+1) and distribute incoming offloads across neighboring fog nodes.The model approximates a neighbor’s selection probability as 1/deg(ĵ) and uses nghbr(j) to aggregate neighbors.

J. Arrival Rates to Cloud Servers

Cloud-server arrival rates account for traffic sent directly from IoT nodes and traffic offloaded by fog nodes. Separate equations are used for Light and Heavy requests.

  • Cloud arrival model: Cloud server k receives incoming traffic from both IoT nodes and fog nodes.The model derives the Light-request arrival rate using mappings from IoT nodes and fog nodes to server k.
  • Cloud arrival model: The Light-request arrival rate to cloud server k is expressed using g^-1(k) for IoT sources and h^-1(k) for fog sources.These mappings identify the respective sets of senders for server k.
  • Cloud arrival model: The Heavy-request arrival rate l′k is derived analogously to the Light-request rate by substituting the Heavy-request generation rate.The paper states that the Heavy-request equation follows the corresponding Light-request formulation.

K. Waiting Time of Cloud Server

Each cloud server is modeled as multiple M/G/1 processing queues with uniform load balancing. The average server waiting time is obtained from one processing unit using queue-length analysis and Little’s law.

  • Cloud-server model: Cloud server k is modeled as mk internal processing units, represented as mk M/G/1 queues with uniform load balancing.The arrival rate to each processing unit is Λk = (lk + l′k) / mk.
  • Cloud-server model: Uniform load balancing makes the cloud server’s average waiting time equal to the average waiting time of one processing unit.The paper denotes these quantities as Hk and Δk, respectively.
  • Waiting-time calculation: The average waiting time of a processing unit is calculated using the Pollaczek–Khinchine formula and Little’s law.The approach first determines average queue length and then converts it to average waiting time.
  • Waiting-time calculation: Processing-unit service times differ by request type: Light requests are exponential with average Zk, and Heavy requests are exponential with average Z′k.These service-time distributions determine the overall service-time statistics used in the waiting-time calculation.

V. NUMERICAL EVALUATION

The numerical evaluation uses simulation and analytical modeling to assess the proposed IoT–fog–cloud operation under varied network, workload, and processing assumptions. It compares All Fog Processing with restricted or absent fog processing and tests parameter sensitivity.

  • Simulation setup: The evaluation models 500 IoT nodes, 25 fog nodes, and 6 cloud servers connected through a hierarchical IoT–fog–cloud topology.Requests may be processed locally, sent to a corresponding fog node, offloaded among fog nodes, or forwarded to the cloud.
  • Simulation setup: Light and Heavy requests use distinct IoT–fog links, with transmission rates of 250 Kbps and 54 Mbps, respectively.The request model also uses exponentially distributed lengths averaging 100 bytes for Light tasks and 80 KB for Heavy tasks.
  • Simulation setup: Fog nodes are modeled as approximately 3000 times faster than Light-request IoT nodes and 200 times faster than Heavy-request IoT nodes.The evaluation derives these ratios from an Arduino Uno R3 and an Intel dual-core i7, while cloud processing is modeled relative to fog processing.
  • Sensitivity analysis: Varying processing-capability ratios changes average delay by only -0.77% to +5.51%, indicating limited sensitivity to the tested parameter variation.The varied ranges include Fog-to-IoT-Light U[500,4000], Fog-to-IoT-Heavy U[100,400], and Cloud-to-Fog U[50,200].
  • Compared operating modes: The proposed All Fog Processing mode permits both Light and Heavy requests to be processed in the fog layer, unlike Light Fog Processing, which restricts fog processing to Light requests.No Fog Processing sends requests either to the IoT node or directly to the cloud, while the probability settings differ across modes and request types.

6) Figure Settings:

Figure 4 evaluates policy variations and alternatives across simulation settings, examining fairness, offload limits, request-generation variability, task mix, and fog offloading. Across these settings, AFP generally achieves the lowest or significantly reduced service delay, although its advantage depends on request type and load.

  • Simulation settings: Each simulation graph uses defined parameter settings, with sample points based on 1 million requests and analytical values compared against simulation in selected panels.The figures use milliseconds as time units, and panels 4b and 4d include analytical-model results to assess agreement with simulation.
  • Fairness parameter: As q approaches 1, AFP decreases light-task delay while increasing heavy-task delay because the fairness parameter gives light processing higher priority.This q-dependent trade-off appears only in AFP; q is not defined for NFP or LFP.
  • Fog-layer offload limit: For AFP, the minimum average service delay occurs at eM = 1, whereas eM > 5 makes AFP worse than NFP under the stated simulation setting.Changing eM does not affect LFP because fog-to-fog transmission and propagation delay is negligible for short Light requests; analytical results closely match simulation.
  • Fog-routing probability: Increasing fog-routing probability reduces average service delay under each policy, while AFP and LFP outperform NFP when pI_i = 0.When pI_i = 0.2, overall delay increases because IoT nodes process requests weakly, but Light delay falls from 60 ms to 18 ms and Heavy delay from 150 ms to 117 ms.
  • Request-generation variability: Request-rate variance increases service delay, especially when Heavy requests are more prevalent; AFP performs best overall, while LFP approaches AFP as Light requests increase.The variable-rate simulations use a normal distribution whose standard deviation equals the average generation rate.
  • Policy comparisons: AFP minimizes Light-request delay and substantially outperforms the index policy because the index policy uses queue status without considering IoT–fog propagation delay or transmission rate.For Heavy requests, AFP is beneficial at high arrival rates but is slightly worse than no offloading when γ′_i < 0.041; AFP generally outperforms LFP and NFP for combined delay.

VI. CONCLUSION

The paper presents fog computing as an IoT complement to cloud computing, introducing a framework, analytical delay model, and delay-minimizing offloading policy. Numerical results examine parameter effects on average service delay and demonstrate the model’s use in evaluating the policy.

  • The paper positions fog computing as a complement to cloud computing and an essential ingredient of IoT.
  • It introduces a framework for handling IoT requests in the fog layer and an analytical model for IoT-fog-cloud service delay.
  • The proposed fog offloading policy is designed to minimize service delay and is shown to benefit IoT applications.
  • Numerical results show how parameter changes affect average service delay and how the analytical model describes policy performance.
  • The analytical model can also support other fog-computing policies, while future work includes request-data dimensions, dynamic thresholds, and delay-cost-energy tradeoffs.
Loading 1804.07376v1…