This action might not be possible to undo. Are you sure you want to continue?
J.Dheeraj Kumar 3rd C.S.E
Email: firstname.lastname@example.org Cell: 9866189502
D.Rajesh 3rd C.S.E
E mail: email@example.com
Alfa College of Engineering and Technology Allagadda
Software radio is one of the more important emerging technologies for the future of wireless communication services. By moving radio functionality into software that has previously been implemented in hardware, software radio promises to change the economics of deploying and operating wireless network services...
Wireless services are increasingly ubiquitous and essential components in our global communications infrastructure. The mobility, flexibility, and reconfigurability of wireless offer compelling complements, or at times, substitutes for wired infrastructure. They enable many new services and expand the usability of old services, extending our ability to stay connected anywhere and anytime we desire. The proliferation of new wireless services being offered over satellites, over cellular networks, and over wireless LANs (WLANs) is fueling concern over how to allocate (or reallocate) scarce radio frequency (RF) spectrum. The research community and industry have responded to this challenge by developing a host of new technologies to allow spectrum to be used more flexibly and efficiently.
What is software radio?
Software radio is the art and science of building radios using software. Given the constraints of today's technology, there is still some RF hardware involved, but the idea is to get the
software as close to the antenna as is feasible. Ultimately, we're turning hardware problems into software problems.
When you say radio, what do you mean?
By radio, I mean any kind of device that intentionally transmits or receives signals in the radio frequency (RF) part of the electromagnetic spectrum. This of course includes our every day AM and FM radios such as those in our homes and cars. TV's are radios that happen to turn the signals they receive into moving pictures and sound. Cell phones and cordless phones are radios. Garage door openers are radios. Car door openers are radios. Wireless internet cards (WiFi / 802.11) are radios. Shortwave, satellite, pagers, GPS, radar, NMR / MRI, the list goes on and on.
Why we want a software radio?
Well, you might not. However, there are at least a few things that software radios can do that haven't been possible before: They can be reconfigured "on-the-fly". That is, depending on what you need, your universal communication device would reconfigure itself appropriately for your environment. It could be a cordless phones one minute, a cell phone the next, a wireless internet gadget the next, and a GPS receiver another. They can be quickly and easily upgraded with enhanced features. In fact, the upgrade could be delivered over-the-air.
They can talk and listen to multiple channels at the same. OK, so what do I care? Imagine you're a cop, or a fire fighter, or an ambulance driver. Today there are many and many places where public safety people from one organization can't talk to another. The locals can't talk to the emergency crew from the next town because they've got different kinds of radios. Software radio solves this problem. We can build new kinds of radios that have never before existed. Smart radios or cognitive radios can look at the utilization of the RF spectrum in their immediate neighborhood, and configure themselves for best performance.
What's the story with free software radio?
First off, let's make sure we're on the same page with regard to free software. Free software means the user has the freedom to run, copy, distribute, study, change and improve the software. Access to the source code of the program is a precondition for this freedom. Without the source code there is no straight forward path to study or improve a piece of code. One of the first software radios was a U.S. military project named Speakeasy. The primary goal of the Speakeasy project was to use programmable processing to emulate more than 10 existing military radios, operating in frequency bands between 2 and 200 MHz. Further, another design goal was to be able to easily incorporate new coding and modulation standards in the future, so that military communications can keep pace with advances in coding and modulation techniques. Types of speak easy are: 1. Speak easy1. 2. Speak easy2. 3. Joint tactical radio system (jtrs). 4. Armature software radios.
5. Software defined radio & RFID technology.
Coupard recommends connecting an unshielded parallel cable to your PC's parallel port connector and forming it into a coil, which you then loop around your radio's receiving antenna. You can see what this looks like in this photo.
RTAI software radio transmission antenna and AM receiver I cheated. I plugged a printer cable into my PC that had a female DB25 on its other end, and inserted the bare end of a thin copper wire into one of the data lines (pin 2 works) of the dangling end of the cable. Then, I wrapped the wire tightly around m y AM radio's telescoping antenna. Anything along those lines ought to
5 A.C.E.T Allagadda
work, but you do need a good antenna or you won't hear anything.
How it works?
First you need to know a bit about RTAI. Please bear with me, for I'm about to attempt a highly simplified two-paragraph explanation of RTAI. If you prefer all the gory details, read some of the whitepapers referenced here. Basically, RTAI is a tiny kernel that assumes ultimate control of system resources and runs Linux as a low-priority task beneath itself. Thereafter, RTAI has dominion over system Interrupts, a situation which allows it to respond in a near-instantaneous manner to certain real-world events when they occur. The term "near-instantaneous" is, of course, relative. At the risk of setting myself up for an email deluge, I'll oversimplify it like this: Linux itself is capable of handling response times, depending on who you ask, in the range of a few milliseconds to a few dozen milliseconds. RTAI, according to Lineo's specs on Embedix Real-Time, can respond to interrupts within approximately 15 microseconds -- making it around a thousand times as responsive as the Linux kernel. One further comment, before moving on, is that although RTAI can obviously greatly improve a system's responsiveness to realworld events in comparison to normal Linux that improvement comes at a price -- which is that the techniques needed to take advantage of RTAI fall outside the normal Linux programming model. You can't, for instance, simply install RTAI and instantly see improvements in applications such as streaming multimedia -- unless they were designed to take advantage of RTAI. In any case, it is this thousand-fold improvement in event responsiveness provided by RTAI that forms the essence of the software radio demo. The ideal scheme would be to attach an analog to digital converter to an antenna. A digital signal processor would read the converter, and then software would transform the stream of data from the converter to any other form.
6 A.C.E.T Allagadda
An ideal transmitter would be similar. A digital signal processor would generate a stream of numbers. These would be sent to a digital to analog converter connected to a radio antenna.
Software-defined radio infrastructure:
The flexibility of a software-defined radio system resides in its capability to operate in multiservice environments without being constrained to a particular standard. In theory, software-defined radio should be able to offer services for any already standardized system or future ones on any radio frequency band. The most attractive property of a software-defined radio system is its ability to adapt itself according to environmental conditions and traffic requirements, especially in the support of multimedia traffic. For example, a mobile operator would have the opportunity to configure the network to support the video, data or voice traffic streams that will maximize its income. Software-defined radio implies that the boundary between the analog and digital world in base stations moves as much as possible toward radio frequency, by adopting analog-to-digital and digital-to-analog wideband conversion as close as possible to the antenna; and the replacement of fixed-function dedicated hardware with technologies that can support as many radio functions as possible in software. Scalability in software-defined radio systems defines the ability to independently vary the number and size of resources (memory, processing and I/O bandwidth) that is used to support the radio infrastructure. Scalable high performance is an intrinsic characteristic of software-defined radio: the ability to scale the architectural components to meet evolving standard, traffic and service requirements, without the need to introduce
new architectural components or changing the underlying infrastructure. A good software radio must operate at any symbol rate within a wide range of rates, in order to be compatible with many protocols, so this adaptive control is crucial. It can be implemented either with a hardware linkage to the converter, or in software.
The latest implementation of the ASP architecture, called Line dancer, implements 4,000 processing units that can deliver in excess of 100 Giga operations per second, and is o perating at 266 MHz. The ASP's SIMD structure makes it suitable for supporting processing for software-defined radio infrastructures,
8 A.C.E.T Allagadda
since the available processing resources can be used to process either long filter sequences or long bit sequences of data decoding for one or more users simultaneously. Indeed, ASP implementations like the Line dancer device can deliver processing power that is typically associated with ASICs and performance flexibility that is characteristic of microprocessors. A single Line dancer device is capable of processing in true software-programmable fashion tens of CDMA users simultaneously.
Universal Software Radio Peripheral:
Current (2003) digital electronics are too slow to receive typical radio signals that range from 10 kHz to 2 GHz. An ideal software radio would have to collect and process samples at
10 A.C.E.T Allagadda
twice the maximum frequency at which it is to operate. Real software radios solve this problem by using a mixer and a reference oscillator to heterodyne the radio signal to a lower frequency. The above mixer changes the frequency of the signal. The phase information becomes more difficult to detect in it. Many digital encoding systems depend on phase encoding. The classic solution is to mix and digitize two channels, using a reference oscillator that produces two signals that are the same frequency. However, one of the frequency outputs lags the other by 90 degrees of a cycle. Thus, the two sets of samples provide th e needed phase information. Another related problem is that the information about the bittiming is lost when the frequency changes. The phase information helps recover that as well.
The sampling works best if it is at a simple multiple of the protocol's symbol rate. Since the distant transmitter and the receiver are linked only by the radio, this means that the sampling speed should somehow adapt to the distant radio's symbol rate. The phase information may therefore be used to adjust the effective sampling rate, as well. A good software radio must operate at any symbol rate within a wide range of rates, in order to be compatible with many protocols, so this adaptive control is crucial. It can be implemented either with a hardware linkage to the converter, or in software. Any signals above the sampling frequency would "interfere" with the sampling, causing spurious signals to appear in the data stream at a frequency that's the difference between the signal and the sampling frequency. For this reason, a low-pass analog electronic filter must precede the digital conversion step. Real analog-to-digital converters lack the discrimination to pick up sub-microvolt, nano watt radio signals. Therefore a low noise amplifier must precede the conversion step. The amplifier
introduces its own problems. If spurious signals are present (which is typical), these compete with the desired signals for the amplifier's power. They introduce distortion in the desired signals, or may block them completely. The standard solution is to put a filter between the antenna and the amplifier, but this reduces the radio's flexibility- the whole point of a software radio. Real software radios have two or three analog "channels" that are switched in and out. These contained matched filters, amplifiers and sometimes a mixer. Software radio technology has gained momentum as engineers everywhere are developing radio architectures that include minimal hardwired analog components. The ability to program intermediate frequency (IF), bandwidth, modulation, coding schemes and other radio functions is the appeal for such widespread interest. Besides providing all these flexibilities, software radio must improve on performance in terms of sensitivity, dynamic range and adjacent-channel rejection. Software radio is still a radio and must perform better than the conventional radio it is replacing.
High-speed data transfer over Pn4 PMC user I/O:
In some applications, it is more convenient for system integrators to move high-speed data over user-defined protocols from COTS PMC modules, leaving the system bus free for other functionalities. One such protocol that is commonly used is the front-panel data port (FPDP) protocol, which is an American National Standard Institute/VMEbus Industry Trade Association (ANSI/VITA) standard. To ensure high-speed data movement, ICS has implemented transmit and receive cores in the user FPGA to support FPDP over the Pn4 user I/O connector of the PMC module. Thus, system integrators will have a seamless way of moving data in and out of ICS PMC modules over FPDP. Other standard and proprietary data transfer protocols may also be implemented in the user FPGA. Using LVDS signaling over the Pn4 user I/O connector allows high-speed data transfer between PMC modules or from PMC
12 A.C.E.T Allagadda
modules to motherboards. This is useful as larger bandwidth and channel counts put an increasing demand on the data transfer capability. It is undesirable for system engineers to be limited by data transfer bottlenecks, preventing them from using the full feature set of a board.
Conclusions and future research:
Software radio is one of the key enabling technologies for the wireless revolution. It enhances flexibility and lowers the costs of constructing and operating wireless infrastructure. By enabling digital conversion closer to the antenna, software radio facilitates the exploitation of new techniques in wireless communications ranging from smart antennas to adaptive power management to advanced digital signal processing. By substituting software for hardware, software radio increases flexibility in the form of enhanced upgradeability, customizability, and dynamic adaptability. This in turn facilitates the replacement of dedicated hardware with generalpurpose hardware. This lowers entry barriers, facilitates system unbundling, and increases scale and scope economies. The longterm effect is likely to be increased competition all along the wireless value chain, from semiconductors through to wireless service provisioning. Consumers are likely to be the ultimate long-term beneficiaries from the increased competition. They will benefit from the expansion of the product space, reduced provider lock-in, and lower prices. Of course, realization of these benefits depends on the continued evolution of software radio and the emergence of open-interface architecture. Whether this will occur or not remains an open question, but in either case, software radio is likely to be an important technology in the years to come.
Arnott, Robert, Seshaiah Ponnekanti, Carl Taylor, and Heinz Chaloupka, "Advanced Base Station Technology," IEEE Communications Magazine, Vol. 36, Issue 2 (February
13 A.C.E.T Allagadda
1998) 96-102. Baines, Rupert, "The DSP Bottleneck," IEEE Communications Magazine, Vol. 33, Issue 5 (May 1995) 46-54. Buracchini, Enrico, ³The Software Radio Concept´, IEEE Communications Magazine, Vol. 38, Issue 9 (September 2000) 138-143. Bose, Vanu, Michael Ismert, Matt Welborn, and John Guttag, "Virtual Radios," IEEE
This action might not be possible to undo. Are you sure you want to continue?