Edge Computing Explained

At a busy Bengaluru junction, a camera mounted on the traffic-signal pole watches the queue of vehicles building up on each arm of the intersection. Several times a minute, a controller has to decide whether to extend the green light, switch early, or hold the current phase, based on what that camera just saw. The decision has to land inside a tight window: if the answer arrives after the phase would already have changed on a fixed timer, the analysis was wasted, and vehicles queue longer than they needed to. Where should the computer that makes this decision actually sit? On a chip inside the signal cabinet, three metres from the camera? On a server in a control room across the city? Or on a cluster of GPUs in a data centre a thousand kilometres away, the kind of place that already runs the maps, the payments backend, and half the internet? The answer, worked through with real numbers below, is the entire subject of this chapter: edge computing is the discipline of putting computation as close as it needs to be, and no closer, to the point where data is generated.

What "edge" actually means

Cloud computing became the default architecture for a good reason: centralising compute in a handful of hyperscale data centres lets a provider pool hardware across millions of customers, drive utilisation up, and sell elastic capacity nobody has to own. For a very large share of workloads (a website's backend, a nightly batch job, an email inbox) this is unambiguously the right answer, because none of them care about a few tens of milliseconds of network delay. Edge computing is not a rejection of that model. It is the recognition that a growing category of workloads, generated by sensors, cameras, vehicles, and industrial machines, is bound by three constraints that centralisation makes worse rather than better: the speed of light, the cost of moving bulk data over a wide-area network, and the need to keep functioning when the network to the cloud is slow, congested, or simply down.

Formally: edge computing is a distributed computing paradigm that performs data processing physically near the point where the data is generated, rather than transporting all of it to a centralized data centre first. "Near" is doing real work in that definition: it means the same building, the same local network, or at most a short regional hop, small enough that propagation delay and the network's own capacity stop being the bottleneck. The point is not that edge devices carry smaller or cheaper chips than a data centre's, though they usually do. The point is where the first decision gets made. Raw data is filtered, summarised, or acted upon locally; only what genuinely needs a wider context, a bigger model, or long-term storage travels further.

The computing continuum: device, edge, fog, cloud

Industry, and increasingly the CBSE Emerging Trends syllabus, describes this as a continuum rather than a single fork between "device" and "cloud". Four layers are worth naming precisely, because both the diagram below and the worked example that follows depend on the distinction.

Device or sensor layer. The camera, the accelerometer, the point-of-sale terminal: the thing that generates raw data and usually cannot run much more than firmware.

Edge layer. A compute node physically co-located with, or one hop from, the device: a small server in the signal cabinet, a gateway on a factory floor, a phone's own processor. It runs a purpose-built model or rule set on one data source at a time, with no dependency on a wide-area network to make its decision.

Fog layer. A regional aggregation point, often on the same metropolitan or campus network, that collects the outputs of many edge nodes: a city traffic control room combining fifty junctions, a hospital floor server combining every patient monitor on that floor. "Fog computing" is the standard industry term for exactly this middle tier, and it exists because not every problem is single-source; some genuinely need a local join across many edge nodes, just not a global one.

Cloud layer. The centralised data centre, potentially hundreds or thousands of kilometres away, that does the work centralisation is actually good at: training the next version of a model on data pooled from every junction in the network, running long-horizon analytics, and archiving history nobody needs in real time.

The diagram below lays out these four layers for the traffic-signal example, with two things marked that a purely structural diagram usually leaves out: which direction each type of data actually flows, and the latency each path costs, because that second number is the entire justification for drawing the boundary where it is drawn.

Worked example: the traffic-light control loop

Take the Bengaluru junction from the opening and put real numbers on it. The signal controller reads a frame from the junction camera every 200 milliseconds (five times a second) and must fold the analysis of that frame into its next decision before the 200 ms window closes; missing the window does not crash anything, it just means that observation was wasted and the signal falls back on the previous count. Two architectures compete for this job.

Assumptions, stated up front (each is a deliberate, labelled modelling choice, not a measurement):

• Nearest hyperscale cloud region: 1,200 km away in a straight line, a realistic distance from a tier-2 Indian city to the nearest major cloud region.
• Real fibre routes are not straight lines; a routing overhead factor of 1.4x on the great-circle distance is a standard networking rule of thumb.
• Light travels through optical fibre at roughly c/1.5 ≈ 2 x 10^8 m/s (refractive index of fibre glass ≈ 1.5).
• One analysed frame is a 200 KB compressed JPEG.
• The camera's uplink to its ISP is a 20 Mbps dedicated line, typical for a fixed camera installation.
• A shared cloud GPU cluster, serving many camera streams at once, takes 15 ms to run inference and clear its queue for one frame.
• A local edge box sits in the signal cabinet, connected to the camera over gigabit Ethernet (1 Gbps), and runs a smaller, quantized version of the same detection model in 12 ms, since it only ever serves one camera and never queues behind anyone else's request.

The code below runs both paths through two formulas: propagation delay, bounded by the speed of light in fibre, and serialization delay, the time to push a frame's bits through a link of a given bandwidth.

def propagation_delay_ms(distance_km, routing_factor=1.4, index_of_refraction=1.5):
    speed_light_vacuum = 3e8  # m/s
    speed_in_fiber = speed_light_vacuum / index_of_refraction
    effective_distance_m = distance_km * 1000 * routing_factor
    return (effective_distance_m / speed_in_fiber) * 1000  # ms

def serialization_delay_ms(frame_bytes, bandwidth_bps):
    return (frame_bytes * 8 / bandwidth_bps) * 1000

# Cloud path: junction camera to a data centre 1,200 km away
prop = propagation_delay_ms(1200)
serialize_up = serialization_delay_ms(200_000, 20_000_000)
cloud_compute = 15
cloud_total = prop + serialize_up + cloud_compute + prop
print(f"cloud: prop={prop:.1f}ms serialize={serialize_up:.1f}ms compute={cloud_compute}ms total={cloud_total:.1f}ms")

# Edge path: junction camera to an on-site box, 50 m away
serialize_edge = serialization_delay_ms(200_000, 1_000_000_000)
edge_compute = 12
edge_total = serialize_edge + edge_compute
print(f"edge: serialize={serialize_edge:.2f}ms compute={edge_compute}ms total={edge_total:.2f}ms")

print(f"speedup = {cloud_total / edge_total:.1f}x")

Trace it by hand before trusting the output. The cloud path's propagation delay is (1,200 km x 1,000 x 1.4) / (2 x 10^8 m/s) = 1,680,000 / 200,000,000 = 0.0084 s = 8.4 ms one way, so 8.4 ms again on the way back. Serialising the 200 KB (1,600,000-bit) frame onto a 20 Mbps uplink takes 1,600,000 / 20,000,000 = 0.08 s = 80 ms, by far the largest single term, because the frame is large and the uplink modest. Add the assumed 15 ms of cloud compute and the two propagation legs, and the total is 8.4 + 80 + 15 + 8.4 = 111.8 ms, which is exactly what the script prints: cloud: prop=8.4ms serialize=80.0ms compute=15ms total=111.8ms. The edge path serialises the same frame onto a 1 Gbps local link in 1,600,000 / 1,000,000,000 = 0.0016 s = 1.6 ms, propagation over fifty metres of cable is close enough to zero to ignore, and 12 ms of local inference brings the total to 13.6 ms, matching edge: serialize=1.60ms compute=12ms total=13.60ms. The edge path finishes 111.8 / 13.6 ≈ 8.2 times faster, printed as speedup = 8.2x, and both numbers happen to fit under the 200 ms deadline in this single-camera, uncongested case, which is exactly why the comparison needs one more step.

Scale it to a city. Bengaluru's signalised junctions number well over a thousand, and every one of them would be sending the cloud a 200 KB frame five times a second under the cloud-first design: 1,000 junctions x 5 frames/s x 200,000 bytes = 1,000,000,000 bytes per second, or 8 x 10^9 bits per second: 8 Gbps of continuous inbound video, just for this one application, arriving at one data centre. That data centre's GPU cluster now has to timeslice across a thousand simultaneous streams instead of one, and the 15 ms compute assumption used above was generous for a single stream; under real contention, queueing delay grows with load, and the latency for a growing fraction of frames blows well past the 200 ms deadline, exactly when traffic is heaviest and the decision matters most. This is the actual argument for edge computing: not that the cloud is incapable of running a detection model, but that its shared, distant nature makes tail latency worse precisely when load is highest, while an edge node's 14 ms does not depend even slightly on how many other junctions exist in the city, because it never talks to them to make its own decision.

The edge design also collapses the bandwidth bill. Instead of forwarding raw frames, each edge node sends the fog and cloud layers only what changed: a 16-byte summary (vehicle count, queue length, average speed, phase recommendation) once per 200 ms decision cycle. Citywide, that is 1,000 x 5 x 16 = 80,000 bytes per second, or 640 kbps, a factor of 8,000,000,000 / 640,000 = 12,500 smaller than the raw-video design, while still giving the fog and cloud layers everything they need to build minute-level dashboards and retrain the detection model on pooled data from every junction in the city.

The misconception: "edge computing means no cloud"

The mistake most students make at this point is concluding that edge computing means eliminating the cloud, running everything locally and never talking to a data centre again. The worked example above shows exactly why that is wrong: the edge node still sends data upward, just far less of it, and the cloud still does two jobs nothing else in the architecture can do as well. First, training: the detection model running on the edge box in 12 ms was not trained on the edge box; it was trained on pooled data from every junction in the network, on hardware with far more memory and compute than a signal cabinet can host, then compressed through quantization (representing the model's weights in 8-bit integers instead of 32-bit floats) so that it fits and runs fast on cheap edge silicon. Second, long-horizon analytics: nobody needs to know a junction's queue length for a specific 200 ms window six months later, but a city planner needs the citywide, minute-by-minute pattern accumulated over months, which is exactly what the fog and cloud layers are built to store and query. Edge computing redistributes where inference happens; it does not remove the cloud from the picture, it changes what the cloud is for. The same logic explains why cloud providers have spent the last several years building infrastructure like AWS Wavelength and Azure Edge Zones, which embed cloud compute inside telecom networks physically close to users: they are moving down the same continuum from the other direction, because the physics that motivates edge computing does not go away just because the compute happens to be owned by a hyperscaler.

Active recall

Attempt all six before reading the worked answers.

1. Define edge computing in one sentence, and state one thing that distinguishes it from fog computing.
2. A different junction sits 900 km from the cloud region. Its camera produces 150 KB frames over a 10 Mbps uplink, and the same 15 ms cloud compute assumption applies, with the same 1.4x routing factor and c/1.5 fibre speed. Compute the total cloud round-trip latency.
3. An autonomous vehicle's automatic emergency braking system must decide whether to brake within single-digit milliseconds. Even with a fast 5G connection to a nearby edge server, why must this specific decision still run on the vehicle itself rather than over any network at all?
4. True or false: "a system only counts as edge computing if the device never communicates with the cloud." Justify your answer.
5. A smaller city deploys 500 cameras, each analysed at 10 frames per second, each frame 100 KB. Compute the raw-video ingress bandwidth the cloud would need, then compute the bandwidth needed if each edge node instead sends a 20-byte summary per decision. What is the reduction factor?
6. A city wants a dashboard for the mayor's office showing total citywide traffic volume by hour, updated once a day. Which layer, edge, fog, or cloud, should own this task, and why does it not belong at the edge?

Worked answers

1. Edge computing performs data processing physically near the point where the data is generated rather than in a centralized data centre; unlike fog computing, which aggregates the output of many edge nodes over a regional network for tasks like minute-level dashboards, edge computing acts on one data source at a time with no dependency on any network beyond the device itself.
2. Propagation: (900 x 1,000 x 1.4) / (2 x 10^8) = 1,260,000 / 200,000,000 = 0.0063 s = 6.3 ms one way. Serialization: (150,000 x 8) / 10,000,000 = 1,200,000 / 10,000,000 = 0.12 s = 120 ms. Total = 6.3 + 120 + 15 + 6.3 = 147.6 ms.
3. Even a fast network adds a latency floor the vehicle's own compute does not have, and that floor multiplies by the vehicle's speed into real distance travelled before a decision even starts. At 60 km/h (16.67 m/s), an extra 50 ms of round-trip network and queueing delay, entirely plausible over a live radio link, costs the vehicle 16.67 x 0.05 ≈ 0.83 metres of travel before the braking decision is even issued, on top of the mechanical stopping distance. A dropped or congested link at highway speed cannot be allowed to mean the safety system stops functioning, so the emergency-braking decision has to run on the vehicle regardless of how good the network usually is; the cloud is reserved for map updates, fleet-wide model retraining, and anything that is not safety-critical in the next few hundred milliseconds.
4. False. The worked traffic-signal example still sends a 16-byte summary to the fog and cloud layers every 200 ms, and the cloud still trains and periodically re-pushes the detection model the edge node runs. What makes it edge computing is that the latency-critical decision, extending or ending the green phase, is made locally without waiting on that network round trip, not that the network connection is absent.
5. Raw video: 500 x 10 x 100,000 bytes/s = 500,000,000 bytes/s = 4 x 10^9 bits/s = 4 Gbps. Edge summaries: 500 x 10 x 20 bytes/s = 100,000 bytes/s = 800,000 bits/s = 0.8 Mbps. Reduction factor: 4,000,000,000 / 800,000 = 5,000x.
6. Cloud, with fog doing an intermediate rollup if the city's fog layer already spans the whole metro area. The task is not latency-critical: a once-a-day update tolerates seconds or minutes of delay, so none of edge computing's core justifications (propagation delay, bandwidth pressure on a real-time link, resilience when the network drops) apply. It also requires a join across every junction in the city over a full day of history, which is precisely the kind of centralized, storage-heavy aggregation a single edge node, built to reason about one camera in the next 200 ms, is not designed to hold or compute.

Think About It

Think about this: How would you explain edge computing explained to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where edge computing explained is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting edge computing explained to at least 3 other topics you have studied.