There is a version of the coverage problem that sounds almost solved. Cellular networks already cover most cities and suburbs. In developed countries, the uncovered population is a small fraction of the total. If you are reading this in an urban area, you have probably never thought much about coverage.

But “most” is not “all.” Large parts of the world—rural regions, oceans, disaster zones—have no terrestrial infrastructure and no realistic prospect of getting it. Building a cell tower that serves a hundred users in a remote region is not an economically viable proposition for any commercial operator. The terrestrial network closes the gap where density justifies deployment; but everywhere else, coverage ends.

Ubiquitous Connectivity—one of 6G’s three new scenarios—is the proposal to close that remaining gap using non-terrestrial platforms: satellites in low Earth orbit (LEO), medium Earth orbit (MEO), and geostationary orbit (GEO), as well as high-altitude platform stations (HAPS) and aerial vehicles. The vision is a network where a handset in the middle of the Pacific Ocean, or on a cargo ship, or in a rural region with no tower in sight, can still reach the network.

The gap between vision and engineering reality is the interesting part.

Two very different approaches to the same goal

The phrase “satellite connectivity for phones” covers two architecturally distinct ideas, and conflating them causes a lot of confusion.

The first is NTN Direct-to-Cell (D2C). Here the satellite operates so that an ordinary, unmodified handset sees it as a regular base station. The phone does not know it is talking to something moving at 7 km/s in orbit. No software update, no new handset—the satellite handles the adaptation on its end. This is attractive commercially because the installed base of existing phones is enormous. The challenge is that doing this cleanly requires the satellite to compensate for all the complications—Doppler shift, propagation delay, timing advance—before the signal reaches the handset.

The second approach is NTN NR (3GPP NR for NTN), standardized beginning with Release 17. Here the handset is NTN-aware. It knows it is talking to a satellite and participates in compensating for the challenges. It can pre-compensate for Doppler based on its own GNSS position, use extended timing advance for the longer round-trip delay, and handle other protocol-level adjustments. The phone needs to support these extensions, but the overall system design is cleaner because the work is shared.

The industry’s standardization momentum sits with 3GPP Rel-17, which actually defines two NTN flavours: a more “IOT”-friendly, low-data-rate track (IoT-NTN, built on NB-IoT and eMTC) and the NTN NR track described above. The former is likely the first to roll out—its simpler protocol stack and existing infrastructure made it the earlier candidate, initially for low-rate messaging and IoT. NTN NR follows, with devices that implement the NTN-specific extensions becoming available over the next several years.

What Starlink actually is—and is not

A clarification worth making explicitly: the Starlink most people are familiar with is not direct-to-cell connectivity. The original Starlink service requires a dedicated terminal—the flat phased-array dish colloquially known as Dishy—installed at a fixed or semi-fixed location. That terminal handles the satellite link and then provides Wi-Fi or Ethernet to devices nearby. A phone connected to Starlink via this route is effectively connecting to a local Wi-Fi access point, not to a satellite. The satellite link is backhaul.

This is a fundamentally different architecture from what “NTN for 5G/6G” implies. In the NTN vision, the phone’s cellular radio—the same radio it uses to call a terrestrial tower—connects directly to the satellite. No dish, no dedicated hardware on the ground, no special terminal.

SpaceX has announced direct-to-cell capability for newer Starlink satellites, and several carriers have signed partnership agreements. But this capability is distinct from the consumer Starlink service, uses different satellite hardware, and is still in early rollout. The earlier generation of Starlink constellation was not designed for it.

The distinction matters because the engineering problems are completely different. A large phased-array dish on the ground can handle the link budget, the pointing, and the protocol adaptation on behalf of the attached devices. A handset must do all of this within the power and antenna constraints of something designed to fit in a pocket.

Why putting a handset on a satellite link is hard

The engineering challenges of NTN are real and substantial. Each one is solvable in principle; the question is how much they cost in performance and complexity.

Distance and delay. A LEO satellite orbits at roughly 500 to 2,000 km altitude. Even at the low end, the one-way propagation delay is around 2 to 5 milliseconds—compared to microseconds for a nearby ground tower. Protocols designed for terrestrial cells assume very short round-trip times. NTN NR extends timing advance to handle this, but the delay has ripple effects throughout the protocol stack: random access preambles must be longer, HARQ retransmission timers need to accommodate the longer round-trip, and scheduling becomes harder to do at low latency. GEO satellites at 35,786 km have round-trip delays around 250 ms (one-way propagation alone is roughly 120 ms), which makes low-latency applications essentially infeasible from GEO—LEO is the only viable option for interactive use.

Doppler shift. A LEO satellite moves at roughly 7 km/s relative to the ground. At cellular frequencies, this produces Doppler shifts that can be orders of magnitude larger than those seen in terrestrial channels. A terrestrial channel might see a few hundred Hz of Doppler from a fast-moving vehicle; a LEO satellite can produce shifts of tens of kHz. Standard receiver designs would misinterpret this as a frequency error. NTN NR asks the handset to pre-compensate based on its known position and the satellite’s ephemeris data—which works, but requires that the handset knows where it is (GNSS) and where the satellite is (ephemeris broadcast).

Handset transmit power. A smartphone transmits at most around 23 to 26 dBm (roughly 200 to 400 mW). A base station can transmit at tens of watts. In a terrestrial cell, the uplink from handset to tower is often the limiting link—the tower hears the weak phone, not the other way around. Bridging an additional 500 km with a low-power handset is a link budget problem. The satellite needs large antennas and sensitive receivers to close the link; the handset has essentially no room to increase its transmit power.

Cell size and capacity. A single LEO satellite at 600 km altitude with a reasonable beam pattern might illuminate a footprint several hundred kilometres in diameter. This is not like a terrestrial cell covering a neighbourhood—it is a cell covering a region the size of a small country. The number of users in that footprint can be very large. Massive MIMO and beam-forming on the satellite can subdivide the footprint into narrower spot beams, which is how most modern LEO NTN systems are designed. But each spot beam still covers tens of kilometres, not hundreds of metres, and the capacity implications are real.

Handover. A LEO satellite moves across the sky in roughly 5 to 15 minutes from horizon to horizon. This means handover—from one satellite to the next, or from satellite to a terrestrial base station when one comes into range—happens frequently and must work reliably. Terrestrial handover has milliseconds to execute; NTN handover must be planned well in advance because the geometry is predictable.

Frequency matters more than you might expect

The choice of frequency band has an outsized effect on what is and is not feasible for NTN.

Lower frequencies—L-band (1–2 GHz), S-band (2–4 GHz)—propagate well, penetrate buildings better, and require less transmit power to close the link at satellite distances. Iridium and Inmarsat, which have offered satellite connectivity to specialized terminals for decades, use L-band. The trade-off is that lower frequencies have less available bandwidth, which caps throughput.

Higher frequencies—Ku-band (12–18 GHz), which Starlink’s dish-based service uses for its user link, and Ka-band (26–40 GHz), which it uses for gateway links—offer much more bandwidth and support high throughput to large terminals. But for a handset, the link budget at these frequencies with a small antenna and limited transmit power simply does not close without heroic effort on the satellite side.

For NTN direct-to-cell, the industry is mostly looking at lower frequency bands: S-band and, in some cases, the existing cellular bands (especially the lower ones around 700–900 MHz). This is partly why LTE is first to roll out—LTE has always operated in these bands, and the protocol was designed for them. The frequency choice is not just a performance decision; it determines whether the link is physically possible with a standard handset at all.

The industry is still sorting itself out

NTN is not a solved problem waiting for deployment. The standardization is relatively new—Rel-17 was completed in 2022, with device implementations still maturing. The commercial agreements between satellite operators and terrestrial carriers are being negotiated. The link budget analyses are being validated against real constellations. Several technical questions remain open: how to handle interference when satellite and terrestrial cells overlap in the same band, how to hand over reliably between satellite and ground, what service guarantees are actually achievable given the capacity constraints of a large footprint, and how to handle the regulatory patchwork of different frequency allocations across jurisdictions.

The space is also commercially crowded and fast-moving. AST SpaceMobile, which is targeting direct-to-cell with large-aperture satellites, is at a different stage of deployment than SpaceX’s Direct to Cell programme, which in turn is architecturally different from OneWeb’s or Amazon Kuiper’s approach. Each company has made different trade-offs between satellite size, frequency band, constellation altitude, and target use case. It is not yet clear which architecture will prove most tractable.

Is this the future?

I honestly don’t know.

The coverage argument is real. There are parts of the world where terrestrial connectivity will not appear in any foreseeable commercial timeframe, and satellite NTN is probably the only credible path to connecting them. Maritime and aviation connectivity, which have historically required large specialized equipment, could be transformed by LEO NTN at reasonable cost. Emergency and disaster response use cases are compelling precisely because they need coverage when terrestrial infrastructure has failed.

But the capacity argument is harder. A satellite serving a footprint of hundreds of thousands of square kilometres is not going to replace a dense urban network. For high-traffic environments, the satellite can serve as a fallback—a safety net—not a primary access mechanism. Whether that is worth the complexity of integrating it into the 3GPP stack is a question the field is still working out.

What I am more confident about is that the engineering problems NTN is forcing the community to solve are hard and interesting. Handling large Doppler in a standard protocol stack, closing a link budget to a low-power handset from orbit, doing predictive handover across a fast-moving cell—these problems are accelerating innovation in areas that will benefit wireless systems more broadly, regardless of whether satellite connectivity becomes ubiquitous. In that sense, it is a bit like the moon landing: the goal may not be the point. The engineering dragged along in pursuit of it often is.

This closes the three-part series on 6G’s new scenarios. Next, I will turn to some of the research directions that sit at the intersection of these themes—starting with how AI-native approaches are changing the way we think about channel estimation and resource management in practice.

References

[1] ITU-R, “Framework and overall objectives of the future development of IMT for 2030 and beyond,” Recommendation ITU-R M.2160, International Telecommunication Union, Geneva, Nov. 2023. [Online]. Available: https://www.itu.int/rec/R-REC-M.2160/en

[2] 3GPP, “Solutions for NR to support non-terrestrial networks (NTN),” 3GPP TR 38.821 V16.0.0, Jan. 2020.

[3] O. Kodheli et al., “Satellite communications in the new space era: A survey and future challenges,” IEEE Communications Surveys & Tutorials, vol. 23, no. 1, pp. 70–109, 2021.

[4] F. Rinaldi et al., “Non-terrestrial networks in 5G & beyond: A survey,” IEEE Access, vol. 8, pp. 165178–165200, 2020.

A radar and a base station look different from the outside. One is pointed at a certain region of interest (e.g., the sky scanning for aircraft or the sea scanning for vessels). The other is mounted on a rooftop, pointed at streets and buildings. But at the signal processing level, they are doing something surprisingly similar. And that similarity is the foundation of ISAC.

What a radar actually does

A radar works on a simple principle: you transmit a signal (one you designed and know exactly), and that signal travels outward, hits an object, and some fraction of the energy reflects back. You receive the echo, compare it to what you originally sent, and from that comparison you can infer three things: how far away the object is (from the round-trip delay), how fast it is moving (from the Doppler frequency shift), and roughly what direction it came from (from the angle of arrival at your antenna array).

The key is that reference. Because you know what you transmitted, any deviation in the echo is signal, not noise. The delay tells you range. The frequency shift tells you velocity. The angle tells you direction. Radar is, at its core, matched filtering applied to a known waveform.

A base station already does most of this

Now think about what a base station does during channel estimation. It transmits a known pilot signal, which is in effect a reference sequence both transmitter and receiver know in advance. The receiver measures what arrived and compares it to what was sent. From that comparison, it estimates how the channel distorted the signal: which paths exist, at what delays and angles, with what amplitudes.

That channel estimate is, implicitly, a description of the physical environment. The delay spread tells you something about the distances to the dominant scatterers. The angle of arrival tells you something about where objects are relative to the base station. The base station is already doing something structurally similar to radar; it is just using that information only for equalization, not for sensing.

The hardware prerequisites are largely similar. Wide bandwidth gives you range resolution: the finer the bandwidth, the shorter the delay differences you can distinguish, and therefore the more precise your range estimate. A massive MIMO antenna array gives you angular resolution: the more antennas, the narrower the spatial beams you can form, and the more precisely you can locate a scatterer. 5G base stations have both of these.

So why is ISAC a 6G feature rather than a 5G one? Partly standardization: sensing was not designed into the 5G specification. But more fundamentally, a 5G base station was not designed with sensing in mind. Its waveform, pilot structure, and resource allocation are all optimized for communication. Using it for sensing is possible, but you are working against some of its design choices rather than with them.

The constraint you cannot escape

A dedicated radar engineer has a freedom that a base station does not: the freedom to choose the waveform. Want better range resolution? Use a wider bandwidth chirp. Want to suppress range-Doppler ambiguity? Carefully design the pulse repetition interval. The waveform IS the radar’s primary design variable.

A base station must primarily transmit communications signal (conventionally, an OFDM waveform), because that is what its users expect. OFDM happens to work reasonably for sensing—the subcarrier structure gives you a natural time-frequency grid for delay-Doppler estimation, and you can extract channel information subcarrier by subcarrier. But “happens to work” is different from “designed for it.” Certain sensing tasks, like detecting slow-moving targets in high-clutter environments, for example, are hard with OFDM in ways they would not be with a purpose-built radar waveform.

The analogy is something like this: imagine someone who is an excellent musician asked to also take phone calls during a performance. They can do it. They may even handle both surprisingly well during quiet passages. But their attention is divided, and there will be moments where one task suffers for the other. A base station serving dense, high-traffic areas has limited spare capacity for sensing. A base station in a lightly loaded cell, with idle resource blocks and guard intervals, has much more headroom.

This is actually the intuition behind one of ISAC’s more defensible use cases: using the “quiet time” (unused slots, guard periods, idle bandwidth) for sensing at essentially zero comms cost. You are not competing with your primary job if there is no primary job happening at that moment.

Where the value actually is

If a dedicated radar is better at sensing (which it generally is) why build ISAC at all? There are two arguments that hold up under scrutiny.

The infrastructure argument. A radar network with the density of a cellular network would be staggering to deploy. Every city block, every indoor space, every industrial floor. To cover them with dedicated sensing hardware, the economics do not work for most applications. A 6G network, by contrast, will be deployed for communications reasons regardless. If each base station also senses, you get ubiquitous environmental awareness as a consequence of infrastructure that was going to exist anyway. The sensing might be lower quality than a dedicated radar, but its coverage is city-scale by default. That trade-off is worth taking seriously.

The synergy argument. A standalone radar produces data—tracks of objects, maps of the environment—that then has to be transmitted to, processed by, and acted upon by some other system. In a cellular network, the sensing output can feed directly back into the communications system that generated it. Know where users are? Predict their beam before they move. Know there is a truck blocking a propagation path? Anticipate the shadow fading and adapt the link. The environment map is not a separate product delivered to a separate customer—it is an input to the comms system’s own operations. This closed-loop synergy has no analogue in standalone radar.

Taken together, these two arguments describe a scenario where ISAC is compelling not because it is a great radar, but because it is a good-enough sensor at a scale and integration depth that no dedicated sensor network can match.

But be careful about the hype

Compared to a purpose-built radar system, an ISAC system will generally have worse sensing performance for a given hardware budget. The waveform is constrained. The antenna geometry is chosen for communications coverage, not radar cross-section optimization. Interference between the sensing and communications functions, particularly in multi-cell environments, is a real and open problem.

There is also a more subtle issue. Some of the most cited ISAC use cases (high-accuracy localization, gesture recognition, indoor mapping) require sensing quality that an ISAC system may not reliably deliver, especially in loaded networks where comms traffic leaves little room for sensing. The cases where ISAC clearly wins are the ones where moderate sensing quality, deployed everywhere, beats excellent sensing quality deployed somewhere. Not every application fits that description.

The engineering goes deeper than one post can cover

This post has only sketched the shape of the argument. The actual engineering of an ISAC system—how you design waveforms that trade off comms and sensing performance, how you allocate resources between the two functions, how multiple ISAC nodes cooperate to form a distributed sensor array, what the fundamental limits look like—is a deep research area. So is the question of when ISAC’s value proposition holds up under rigorous system-level analysis, and when a hybrid deployment of simpler dedicated sensors alongside the base station would just be more practical.

A proper treatment of ISAC’s strengths, weaknesses, open research directions, and realistic deployment scenarios deserves its own post—one that goes further into the technical mechanics rather than staying at the conceptual level.

For now, the short version: ISAC is one of 6G’s most interesting bets. The hardware prerequisites are largely there. The value proposition for ubiquitous infrastructure sensing and comms-sensing synergy is real. But it will need honest benchmarking against alternatives—not just against other ISAC designs, but against the question of whether a standalone sensor network, or a hybrid approach, would serve the use case better.

Next in the series: Ubiquitous Connectivity—what it means for 6G to extend coverage beyond where cell towers are economical to build, and why satellites and aerial platforms are part of that answer.

References

[1] ITU-R, “Framework and overall objectives of the future development of IMT for 2030 and beyond,” Recommendation ITU-R M.2160, International Telecommunication Union, Geneva, Nov. 2023. [Online]. Available: https://www.itu.int/rec/R-REC-M.2160/en

[2] F. Liu, C. Masouros, A. P. Petropulu, H. Griffiths, and L. Hanzo, “Joint radar and communication design: Applications, state-of-the-art, and the road ahead,” IEEE Transactions on Communications, vol. 68, no. 6, pp. 3834–3862, Jun. 2020.

[3] C. Sturm and W. Wiesbeck, “Waveform design and signal processing aspects for fusion of wireless communications and radar sensing,” Proceedings of the IEEE, vol. 99, no. 7, pp. 1236–1259, Jul. 2011.

[4] A. Liu et al., “A survey on fundamental limits of integrated sensing and communication,” IEEE Communications Surveys & Tutorials, vol. 24, no. 2, pp. 994–1034, 2022.

The ITU’s framing—AI and Communication, not “AI for communication”—is intentional (I believe). The proposition is not that AI will enhance a communication network from the outside. It is that AI becomes part of the design fabric of the network itself (so-called “AI-native”). What does that actually mean in practice?

The short version: some of the assumptions that wireless systems were built on are worth revisiting. They are not wrong exactly, but are perhaps simplifications that kept the mathematics and analysis tractable, and they served the field well. However, at higher frequencies, where a significant share of 5G’s and 6G’s performance ambitions live, those simplifications start to cost something real and measurable. AI-native design is, in part, a proposal to stop leaving that performance on the table.

Simplification in our comfort zone

When a signal traverse through the air, it doesn’t go point to point in a single straight line. It scatters, bounces off buildings, diffracts around corners, reflects off vehicles, gets absorbed by foliage. By the time it arrives at the receiver, it comprises dozens of paths, each at a slightly different angle, different delay, and different amplitude.

Characterising that precisely is, in general, very hard. So classical theory made a practical decision: if you have many independent random contributions summing together, invoke the central limit theorem, and the aggregate looks Gaussian, i.e., white noise, Rayleigh fading. A handful of parameters with tractable models.

This is an impressive line of reasoning, and it has been extraordinarily productive. Shannon capacity, optimal receiver design, error-correcting codes—most of what we actually deploy runs on Gaussian foundations.

But it is still an approximation. And as we push into higher frequencies like millimetre-wave and upper mid-bands (in line with 6G’s ambition for high throughputs), that approximation starts to cost us something real.

The channel that gets simpler and stranger at the same time

Here is something that might surprise people when they first encounter it. You might expect that going to higher frequencies makes the wireless channel more chaotic. More reflections, more unpredictability. In fact, it goes the other way.

At higher frequencies (millimetre-wave for instance), signals attenuate aggressively. Most of those scattered bounces just disappear. What you are left with is a small number of dominant propagation paths: a line-of-sight component if you are lucky, a strong reflection off a nearby surface, and then basically nothing else (at least not discernible from the background noise). The channel is sparse in the angular domain. Energy arrives from a few directions, not all of them.

This is not a messier channel. It is, in a meaningful sense, a more structured one.

The problem is that a Gaussian model does not know this. It has no prior that says energy should be concentrated in any particular direction. It treats all angles equally. It is like trying to find a face in a photograph by averaging over every possible configuration of pixels—technically defensible, practically wasteful.

The performance cost shows up most clearly in how the network designs its codebook, i.e., the set of beams it uses to serve users across a cell.

A concrete example: the codebook problem

In a massive MIMO system, the base station does not broadcast in all directions at once. It forms focused beams and allocates them to users. The collection of beams it can choose from is the codebook.

The uninformed approach is to spread those beams uniformly across all possible angles. If a user could be anywhere, cover everything equally. That is fig. 3a: several beams, evenly spaced, no assumptions made about the world.

Now add the environment. Users are in buildings, on streets, in corridors. The geometry constrains where they actually are. Some angular directions from any given base station are simply not accessible—blocked by a wall, a building, a car park. That is fig. 3b. The codebook has not changed, but now it is obvious that some beams are pointing at regions where no user will ever be. Those are wasted degrees of freedom, since they are capacity you provisioned for but cannot use.

Fig. 3c is where it gets interesting. Same number of beams, but now shaped around where users can actually be. The inaccessible zones get nothing. The accessible ones get finer angular resolution, tighter beams, better spatial separation between users. The codebook has not grown; it has been informed.

The performance difference between a uniform and an informed codebook is not small. In dense urban deployments, it translates directly into how many users a cell can serve simultaneously—the kind of gain that shows up in system-level throughput, not just in link-level simulations [3]. The question is how you get the informed version. You could derive it analytically if you have a sufficiently accurate model of the environment. But real environments are messy, partial, and irregular—the clean analytical derivation gets complicated quickly. The increasingly practical answer is to learn it.

Structure you can learn without being able to describe

Learned estimators sidestep the commitment that compressed sensing requires, and this is where the argument connects back to the non-Gaussian point.

If you know the channel is sparse, you can exploit it directly. Compressed sensing algorithms (e.g., matching pursuit, LASSO) recover sparse signals from far fewer measurements than a Gaussian estimator would require. You don’t need to probe every direction if you know most directions are empty. This idea has been influential in 5G channel estimation research [2].

But compressed sensing requires you to specify the sparsity structure: which basis the channel is sparse in, how sparse, what the noise model looks like. Get those wrong and the gains disappear. Real millimetre-wave channels are sparse in ways that are approximately but not exactly what a textbook model says—the support varies with environment, there are correlations across antenna arrays that the standard basis ignores.

A learned estimator sidesteps this commitment. Train a neural network on empirical channel data from the actual deployment (the real buildings, the real mobility patterns, the real interference) and it absorbs the statistical structure of that environment without requiring you to write it down analytically. It learns that energy arrives from these angular ranges, in these cluster shapes. Not because you specified it. Because the data showed it.

The adapted codebook in fig. 3c is one illustration of the same principle. But the logic extends to channel estimation, CSI compression, beam management—anywhere the system currently makes a Gaussian assumption and pays a performance tax for it.

Why this is an architecture problem, not just an algorithm problem

Here is the part that often gets skipped over, and it matters.

The interface contracts between layers of the communications stack were designed around the Gaussian assumption—what the physical layer measures and reports, what the UE feeds back to the base station, what the channel model looks like to the scheduler. Pilot structures, feedback codebook formats, link adaptation curves: most of it was dimensioned for a particular model of what channels look like.

If you swap in a better estimator but leave those interfaces unchanged, you recover some performance. But you are still operating through specifications built for a different world. An AI-native system is one where those interface contracts are redesigned from the ground up around the assumption that learned representations will be doing the heavy lifting. Change the estimator and the contract, and the gains compound.

This is the architectural claim in IMT-2030’s AI and Communication scenario. The network is not getting a smarter add-on. It is being rethought from the physical layer up, around the premise that the old approximations were holding it back.

What this enables

The practical consequence is a network that adapts to its actual environment rather than a textbook approximation of it.

Conventional systems are designed to worst-case specifications—dimensioned for a channel that could be anywhere in the space the Gaussian model defines. A system that has learned the real distribution of channels in its deployment can afford to be more aggressive: finer codebooks, more targeted estimation, beam management tuned to local geometry. In dense urban millimetre-wave deployments, where the channel is sparse and structured, the gap between designed-for-the-model and designed-for-the-reality is large and exploitable.

The deeper point is about information. Real channels carry more structure than Gaussian models capture. A system built to learn and exploit that structure gets more performance from the same spectrum and hardware—not because it is more powerful, but because it has stopped making assumptions that were never quite true or overly pessimistic.

That is the AI-native proposition. Not AI as a layer on top of a classical system. AI as the thing that finally lets the network close the gap between the world it was designed for and the world it actually operates in.

Next in the series: the other two new 6G scenarios—what it means for a network to also be a sensor (ISAC), and how 6G plans to extend coverage to places a cell tower was never economical to build (Ubiquitous Connectivity).

References

[1] ITU-R, “Framework and overall objectives of the future development of IMT for 2030 and beyond,” Recommendation ITU-R M.2160, International Telecommunication Union, Geneva, Nov. 2023. [Online]. Available: https://www.itu.int/rec/R-REC-M.2160/en

[2] W. U. Bajwa, J. Haupt, A. M. Sayeed, and R. Nowak, “Compressed channel sensing: A new approach to estimating sparse multipath channels,” Proceedings of the IEEE, vol. 98, no. 6, pp. 1058–1076, Jun. 2010.

[3] A. Alkhateeb, O. El Ayach, G. Leus, and R. W. Heath, “Channel estimation and hybrid precoding for millimeter wave cellular systems,” IEEE Journal of Selected Topics in Signal Processing, vol. 8, no. 5, pp. 831–846, Oct. 2014.

The complicated answer is that 5G is very different in terms of how cellular networks operate behind the scenes, which is generally not visible to the everyday user. But rather than getting into that, this post focuses on what 5G was meant to be for. Because it was not designed to simply make downloads faster or streaming smoother. It could, with the extra bandwidth, but that is not the revolution. Rather, 5G was designed with enterprise in mind (think smart factories, hospitals, autonomous vehicles). To see why, we need to revisit what “fast” actually means.

Rate is a fraction. There is more than one way to make it bigger.

When we talk about data rate or communication rate, we mean the amount of data divided by time—i.e., bits per second. If we want a higher rate, the obvious move is to send more data per transmission. But another way is actually to shrink the denominator, and finish the transmission in less time.

Most of us picture the first case. When downloading a large file, the data size is fixed, and we want the transfer to finish quickly. We do this by “expanding” our pipe, using more resources and packing more bits per symbol. This is eMBB: Enhanced Mobile Broadband, the flavor of “fast” that consumers recognize.

But are there alternative perspectives to this?

What if the data is tiny, but the time has to be near-zero?

Imagine a robot on a factory floor receiving time-sensitive commands from a controller. Each command is maybe a few tens to hundred bytes, messages that are not very big. But the robot cannot afford to wait! A delay of more than a millisecond could mean a missed step, a damaged part, or worse, an accident or injury. Here, the “data” in the numerator is small; yet, what matters most is that the denominator, i.e., time or latency, is kept extremely low. (And also that the link almost never fails.)

This is URLLC: Ultra-Reliable Low-Latency Communication. The target is generally end-to-end latency on the order of sub-millisecond with reliability of 99.999% (we sometimes call it “five nines”). One can imagine this being highly relevant and important for remote teleoperated surgery, autonomous vehicles reacting to hazards, or electrical grid control.

These requirements are hard, not because the data is large, but because of the physics of wireless communication (fading, interference, retransmissions) fights against guaranteed low latency. The required setup looks almost nothing like eMBB. We now have a completely different set of tradeoffs, as well as a new set of tools and techniques to realize these, such as short packets, grant-free access, dedicated resource scheduling and spatial diversity.

What if you have a million devices, each barely transmitting at all?

Now imagine a city where every electricity meter, water pipe sensor, parking space, and shipping container is wirelessly connected. Each device sends a small report every few minutes. Individually, the data rate per device is negligible. But you might have tens of thousands, or even millions of these devices packed in a small area, all sharing the same network.

This is mMTC: massive Machine-Type Communication, which is effectively when we scale IoT use case significantly. The challenge is no longer throughput or latency, but rather connection density and energy efficiency. These devices often run on small batteries and need to last years in the field. And while the aggregate data across all these devices does add up to significant throughput, the bigger challenge is that every device brings its own identity—and with it, authentication headers, addressing, protocol handshakes. This overhead per message is no longer negligible when you multiply it by a million. The protocols designed for cellular phones (to negotiate a connection, exchange credentials, then transmit) were not meant for the deployment density of million devices waking up sporadically in a single cell. Such a network has to handle extreme congestion without demanding much from each device node.

So the same question of “how do we get a higher rate from the network?” gives rise to three completely different considerations, depending on which part of the fraction you are squeezing, and for whom.

5G was designed to handle all three

5G (IMT-2020, standardized from around 2018) was explicitly built around these different perspectives, giving rise to a single flexible network (the so-called “5G New Radio (NR)”) configurable for eMBB, URLLC, or mMTC depending on the deployment. However, in practice, most consumer 5G today is eMBB, for faster downloads in dense urban areas and better coverage in stadiums (e.g., the ``Taylor Swift Concert Effect’’ on mobile networks link ). URLLC and mMTC capabilities are the part of 5G that industry is still building out, mostly in private 5G deployments at factories and ports/logistics hubs. That is where the more interesting engineering continues to happen.

6G expands the envelope further

And so, what is 6G? Here’s a quick look in a nutshell.

Fast forward to 2023, ITU released the IMT-2030 framework (the de facto vision for 6G). The familiar triangle that describes 5G’s 3 use cases sits in the middle. But moving forward, they have evolved with ambitious targets. Immersive Communication (from eMBB) targets for peak data rates up to 1 Tbps, Hyper-Reliable Low Latency Communication (from URLLC) strives to achieve 0.1 ms latency with “seven-nines” reliability, and Massive Communication (from mMTC) caters to connection densities an order of magnitude higher.

But the more interesting part of IMT-2030 is not the bigger numbers or more ambitious targets; rather, it is how three additional scenarios have been identified that have no counterpart in 5G, further “expanding” the triangle into a hexagon. They are, namely,

Integrated Sensing and Communication (ISAC): the network no longer just carry data; rather, it can also use the same hardware and its own radio signals to sense the physical environment, detecting objects and estimating device locations. The antenna that used to only convey information is now also a radar.

AI and Communication: rather than running AI on top of the network as an afterthought, intelligence ought to be designed into the network architecture itself; for example, they can be used to revolutionize the way we do channel estimation, resource allocation, beam management, and network resource optimization. The network becomes an intelligent and proactive agent, not just a passive pipe.

Ubiquitous Connectivity: seamless integration of terrestrial cells with satellites and aerial platforms, so that coverage is no longer bounded by where a cell tower was economical to build. We can thus reach deep rural areas, and serve maritime and aviation industries, thereby realizing the goal of “connecting the unconnected”.

Taken together, the vision for 6G is a shift from a communication network to a platform for communication, sensing, and computation—one that increasingly serves machines, infrastructure, and industrial systems as much as people holding phones.

The bottom line

If your 4G works fine for streaming and browsing, that will probably continue to be the case. What 5G and 6G are trying to solve is the set of problems that comes next: connecting the physical world at scale, enabling latency-sensitive control over wireless links, and building a network infrastructure that industry can rely on.

All in all, “faster internet” can mean more than just faster download speeds. The more precise framing is: higher rates for different kinds of traffic, with different reliability and latency requirements, for many more types of users than just humans with smartphones. That distinction is also what drives some of the exciting research and development works in the space of 5G, 6G and beyond.

Next in the series: we will spend some time to discuss more on the three new scenarios set forth in IMT-2030/6G, and what they might actually involve technically, together with where the active research efforts are.