[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Economist: Wireless broadband: Open spectrum, closed

From: John Gilmore
Subject: [Discuss-gnuradio] Economist: Wireless broadband: Open spectrum, closed chips
Date: Wed, 19 Jan 2005 01:52:56 -0800

[This is part of why GNU Radio and unconstrained research hardware are so
 important.  And why the right to reverse-engineer is also critical.  --gnu]

*Wireless broadband*

Jan 6th 2005

*Computer chips for “open-spectrum” devices are a closed book*

TELECOMMUNICATIONS used to be a closed game, from the copper and fibre 
that carried the messages, to the phones themselves. Now, openness 
reigns in the world of wires. Networks must interconnect with those of 
competitors, and users can plug in their own devices as they will. One 
result of this openness has been a lot of innovation.

Openness is coming to the wireless world, too. Cheap and powerful 
devices that use unlicensed and lightly regulated parts of the radio 
spectrum are proliferating. But there is a problem. Though the spectrum 
is open, the microprocessor chips that drive the devices which use it 
are not. The interface information—the technical data needed to write 
software that would allow those chips to be used in novel ways—is 
normally kept secret by manufacturers. The result could be a lot less 
innovation in the open wireless world than in the open wired one.

Take, for example, the Champaign-Urbana Community Wireless Network 
(CUWiN), in Illinois. This group is trying to create a so-called meshed 
Wi-Fi network. Wi-Fi is a wireless technology that allows broadband 
internet communication over a range of about 50 metres. That range 
could, however, be extended if the devices in an area were configured to 
act as “platforms” that both receive and transmit signals. Messages 
would then hop from one platform to another until they got to their 
destination. That would allow such things as neighbourhood mobile-phone 
companies and a plethora of radio and TV stations, and all for almost no 
cost. But to make such goodies work, CUWiN needs to tweak the underlying 
capabilities of Wi-Fi chips in special ways. 

When its engineers requested the interface information from the firms 
that furnish the chips, however, they were often rebuffed. A few 
companies with low-end, older technology supplied it. But Broadcom and 
Atheros, the two producers of the sophisticated chips that CUWiN needs 
if its system is to sing properly, refused. Nor is CUWiN alone in its 
enforced ignorance. SeattleWireless and NYCwireless, among other groups, 
have similar ideas, but are similarly stymied. Christian Sandvig of the 
University of Illinois at Urbana-Champaign, who has been studying the 
brouhaha, believes regulators ought to enforce more openness.

Broadcom and Atheros say that making the interface information public 
would be illegal, because it could allow users to change the parameters 
of a chip in ways that violate the rules for using unlicensed spectrum 
(for example, by increasing its power or changing its operating 
frequency). That is a worry, but it depends on rather a conservative 
interpretation of the law. The current rules apply to so-called 
“software-defined radios” (where the ability to send and receive signals 
is modifiable on the chip), and do not apply directly to Wi-Fi. Also, by 
supplying the data, manufacturers would not be held liable if a user 
chose to tweak the chip in unlawful ways. And in any case, if the firms 
are really worried, they could release most of the interface, keeping 
back those features that are legally sensitive.

Nor is the interface information commercially sensitive. Engineers are 
not asking for the computer code that drives the interfaces, merely for 
the means to talk to them. And having the interface information in the 
public domain should eventually result in more chips being sold. So it 
is hard to see what the problem is beyond a dog-in-the-mangerish desire 
not to give anything away. Time to open it up, boys.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]