Rapid Matchmaking for Terahertz Network Transmitters and Receivers

New technique can help establish links in a single shot

2 min read
Radiation of varying frequencies emanate from a leaky waveguide at different angles.
Illustration: Mittleman Lab/Knightly Lab/Brown University

Scientists may have solved a fundamental problem that would have put a snag in efforts to build wireless terahertz links for networks beyond 5G, a new study finds.

Terahertz waves lie between optical waves and microwaves on the electromagnetic spectrum. Ranging in frequency from 0.1 to 10 terahertz, they could be key to future 6G wireless networks, which will transmit data at terabits (trillions of bits) per second.

But whereas radio waves can transmit data via omnidirectional broadcasts, higher frequency waves diffract less, so communications links involving them employ narrow beams. This makes it more challenging to quickly set up links between transmitters and receivers.

When it comes to the frequencies used for the 5G wireless networks currently being deployed, the conventional approach for locating devices and connecting them to a network has been to let transmitters scan an area using these narrow beams. However, this strategy for “link discovery” is not practical for terahertz networks. Because these transmitters’ beams are 10 times as narrow as those used in 5G networks, it would take much longer to scan for receivers.

Scientists have been searching for other ways that a terahertz access point (which one can think of as a wireless router) might link with receivers. They found that by placing a component known as a leaky waveguide on a terahertz access point, they could enable link discovery in just one shot without wasting time methodically scanning an entire area for potential receivers.

The scientists detailed their findings online in the 24 April edition of the journal Nature Communications.

A leaky waveguide is essentially just two metal plates with a space between them in which radiation can travel. One of these plates has a narrow slit cut into it that allows some of the radiation to leak out. When a pulse comprising a wide range of terahertz frequencies is directed between the plates, each frequency leaks out of the slit at a different angle. (Imagine a rainbow leaking out, with each color inclined in its own unique way.)

Depending on a receiver’s position relative to a transmitter equipped with a leaky waveguide, it will see different frequencies. The receiver can then send a signal back to the access point explaining which frequencies it saw; this lets the access point know exactly where the receiver is located.

“The fact that you can make this measurement fast means that you can do it many times per second, which means that you can keep track of a receiver even if it is moving,” says study senior author Daniel Mittleman, a physicist at Brown University. “That means that we can now envision terahertz networks that incorporate a mobile receiver.”

Also important to this strategy is equipping each receiver with a leaky waveguide. The range of incoming frequencies a receiver sees through the leaky waveguide make it possible to deduce how the access point and receiver are oriented with respect to one another. This will make it fairly easy to tell whether, say, a receiver is swiveling in place.

Mittleman cautions that the team’s work was only a small-scale feasibility test involving a very-short-range link (spanning at most 30 centimeters). “A more realistic test-bed at real-world scales would be a very interesting future step,” he says. Future research can also investigate how terahertz networks might deal with terahertz waves that bounce off walls, floors, and other objects before they reach receivers, he adds.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less