SDR(Software Defined Radio)  

 

 

 

Overview

Followings are the topics that I will discuss on this page. These tend to be very casual talks and I will keep adding topics as they pop up in my mind.

What is it ?

What is SDR ?

SDR stands for Software Defined Radio.

What does it mean ?

Theoretically... a radio that is implemented purely in Software ?

Does it mean a radio that does not use any hardware at all ?

I wish it could be possible. But in reality, it is not possible to remove all the hardware in Radio even in the most advanced SDR now.

Then a questions comes .. which part of the Radio would be replaced (implemented) by Software to be labeled as a SDR ?

Let's look into general structure of a Radio Communication Device. It would be illustrated as shown below. As you see, you see pretty complicated hardware structure and relatively small portions of the software at the very end.

< Figure 1 : General Architecture of Radio Transceiver >

The evolution of Radio Communication Device has been done to simply these structure. In one aspect, this effort of simplification has been done on hardware side as described in RF System Introduction page (Type 1 -> Type 2 -> Type 3). And in the other espect, the effort has been done on Software Side trying to replace some of the hardware with a software (basically Digital Signal Processing).

Which part of the hardware can be replaced by Software ? The ideal solution that you may want to get would be as follows. Basically this is for replacing almost all the hardware except the antenna and ADC/DAC. This would be the goal for current SDR.

You want to remove even those Antenna and ADC/DAC ? Don't dream about this. It is theoretically not possible unless some people came out with a super smart idea.

< Figure 2 : Ideal structure of SDR >

Even though we have such a goal as shown above, it will be tricky to implement this kind of SDR unless you have ADC/DAC with super wide dynamic range and extremely high resolution. In addition, the ADC/DAC sampling rate should be extremely high if RF frequency is very high.

With various technical challenges, SDR has been evolved in multiple steps.

The first stage of SDR has been as follows. At this stage, ADC and DAC is done at IF stage and removes the most of hardwares (Downconvert/upconvert for IF to Baseband and various filters) for baseband processing.

< Figure 3 : First Evolution of SDR >

Next stage of evolution would look as shown below. As shown here, ADC and DAC is done directly at the RF stage, but a couple of Amplifiers are still remaining at hardware stage.

< Figure 4 : Second Evolution of SDR >

As of now, you would see SDR in both as in Figure 3 and Figure 4 depending on the application.

How far we can go with SDR ?

It is said that SDR emerged around the end of 1990s.. meaning it is approaching almost 30 years by now (as of 2025). It is supposed to be pretty mature technology by now. However I still see a couple of extreme perception of SDR.

Pro SDR : Now it is the era of software and we have extremely powerful microprocessors anywhere even in personal computer and in mobile phone. We can remove all the hardware except antenna and ADC/DAC if we decided to do.

Anti SDR : SDR guys has said they can do everything with software and they will replace all the hardware from day 1, but even now they are not showing any powerful SDR solution implementing the latest technology as effectively as hardware solution.

Which side am I on ? I am in between them :).

I don't think we can implement every radio systems with SDR. It is not because the concept of SDR is bluffing and never been mature in terms of real technology but because the requirement of radio system has been expanded so fast. However, if you set a reasonable goal for the requirement, SDR can be a really meaningful/feasible solution.

Let me give you some practical examples that might give you more practical understanding of current SDR.

Would give me an example of the most advanced Radio Technology ?

I think LTE can be a good example. Considering the data throughput (over 100 Mbps) and timing requirement (1 ms TTI), you might think it would be hard to implement this in SDR.

It is not true. Trust me, there are already several LTE Network Simulator (from eNB to Core network) purely based on SDR. You may purchase them with low cost for general function testing or even building your own private LTE network. You might see solutions with small hardware + a PC or small hardware with an embedded process fully functioning as a complete LTE Network (Just try google 'LTE SDR', 'LTE Private Network' etc). I heard aready 300 Mbps IP layer throughput has been tried and confirmed working in a commerical LTE SDR and will soon achieve 450 Mbps.

Then can we remove the cellular chipset completely from our Smart phone ? Probably it would be a little tricky considering the fact that we need multiple cellular technology in a mobile phone and the processing power of a mobile phone might not be powerful enough to perform radio protocol in the background and do all such a complicated graphic processing. Even more importantly, you may have to recharge the bettery several times even in an hour if those radio stack is running in SDR.

How about 5G ? Can SDR meet the 5G requirement ?

We don't know what the 5G requirement is for now, but it is highly likely that SDR will play an important role especially on network side. Even though eMBB (enhanced Mobile Broadband, super high data rate in layman term) or mission critical latency would be hard to be implemented by SDR, many of other features can more easily and more efficiently done by SDR.

Open Source vs Commercial Product

First of all, I would like to express my sincere appreciation and respect for those who is contributing any open source project.

After I struggled for a couple of years trying to understand the details of radio protocol, I came across an open Source project about the field that I was interested in. You might think ... Now I have the full source code and the project provides even hardware information as well.  I would have fully functioning SDR system if I buy the hardware and compile the source code and just run it.

However, as I always says... nothings goes as textbook says in engineering... probably same in our life.

Once you really try it and you will learn it is start of another big, big problem... (but every problem .. you will learn new things ..  I don't have any intention of discouraging you here). You might learn that even software compilation would not go as expected .. and had to spend a lot of time and effort just to compile it. And then you get the hardware, you would learn what the 'hard' life is. You need to do some of assembly job for several components that are delivered seperately. If you are not a hardware people (like me), even opening the shield case and connecting a daughter board and connect some of wires.. this kind of simple things for hardware experts will be like bulding a rocket. And the it will take another long time and effort until you see the small led lit on the hardware...

Now let's look into the source code. After spending too long time on struggling with 3GPP specification which looks like an encrypted text to me, I expected that I would be able to decrypt all those secretes right away if I see the source code. But I soon relealized that the source code is also another type of encryption that I need to make a lot of effort to make sense out of it.

Again I am not trying to discourage you in any way.. all of every single trial and error would teach you and raise you as an engineer.

As far as I experienced in the industry as an engineer working in companies who is under consistant pressure for commercialization, the typical procedure of product cycle can be described as follows.

    i) building up core knowledge

    ii) Initial implementation (Just make it work in very controlled/restricted condition)

    iii) testing ... testing ... testing ... testing ...

    iv) fixing..., updating.. updatating ... and make it more reliable/stable

    v) testing.. testing ... testing ...

    vi) bug report from outside of development team (mostly from the customer) ..

    vii) debugging ... fixing ... debugging ... fixing ...

    viii) testing with another device ...,testing with other settings  ... to extend the coverage of the product

    ix) implemeting new feature added to international specification

    x) go to step iii)

I think step i) and ii) can be done by one or a few genius or dedicated person, but it will be difficult to go through the endless cycle of iii) through x) with a relatively small/limited resource. Especially for those product which requires hardware as part of product (SDR is also fall into this category), it would require many people, team work and budget to survive to repeat these cycle. Purchasing a commericialized product means purchasing the result of these full cycle and more importantly purchasing the commitment to support you (the customer).

If your current goal is just to understand the core knowledge and accumulate the initial experience, I think OpenSource can be a good economic solution. However, if you need to do any mission critical task especially winthin a certain deadline, I would recommend to try with commercialized product. I think getting direct access to technical support provided by the commercial product would also be a strong motivation for the commercial product.

My personal experience of switching back and forth between OpenSource and commercial product is as follows. I am going back to the time when I have no (or almost no) knowledge about the radio protocol.

At this stage, Open Source SDR was not so much help for me since my knowledge level was so low and I couldn't make sense out of the source code and couldn't understand the technical documents (unlike commercialized product provide a lot of beginer level of document, OpenSource document usually requires a certain level of knowledge to understand the document).

Then, I was given chance with playing with various commercial product about Radio product, mostly Cellular communication related product. With these product, I learned many things about cellular technology just as if many kids learn how to use joy stick and how a button/stick is associated movements in a Game character. It is completely like blackbox analysis approach. Starting from a given configuration which is proven to be working and change the parameter one by one and see how those changed parameter changes the communication process. With these practice, some of technical documents (e.g, technical specification or product document) started making sense to me.

Repeating these practice, accumulating knowledge in the field and reading a lot of documents, I got pretty good understandings on what's going on during the radio communication process. I wanted to know about the every details of the process and I realize that it would be almost impossible to understand all those details without implementing it on your own or look into the source code. However, in most case commercialized product does not disclose their source code (To be honest, at least more than 60 % of those source code would be almost same as OpenSource code and no harm to the intellectual properties of the company, but I haven't seen any company (at least in Radio/Cellular area) to open even a part of the source code). There is where I turned again to OpenSource. The source code and technical document really helps me to broaden and deepen my knowledge.

Advantage / Motivation

SDRs offer a wide range of advantages due to their reliance on software for functionality rather than fixed hardware designs. It provide unmatched flexibility and efficiency in modern communication systems. From telecom to defense, education, and disaster management, their potential lies in their ability to evolve with minimal investment, bridging the gap between innovation and practicality.

Flexibility and Adaptability

SDRs can adapt to different communication standards without requiring hardware changes. For example:

Example:

  • A single SDR can switch between 4G LTE and 5G NR protocols in a telecom base station. This eliminates the need for separate hardware for each standard, especially in regions transitioning to new networks.
  • Military communication systems benefit from SDRs by dynamically switching between encrypted protocols or frequency bands to avoid jamming or interference during operations.

Cost-Effectiveness

By centralizing functions in software, SDRs minimize the need for redesigning hardware for each new standard.

Example:

  • In most case it cost less to implement something in SDR rather than dedicated hardware. If the number of product is very small it may cost more with SDR due to initial development cost but once the initial development is done, cost efficiency of SDR gets uncomparable with the cost of dedicated hardware. You can just copy the code with SDR whereas this kind of copy is not possible with hardware.
  • For startups or smaller network operators, SDRs lower the cost barrier of deploying base stations that can be updated to match evolving network requirements, such as new spectrum allocations.

Upgradability

Software updates extend the lifespan of SDR devices, allowing them to incorporate new features without hardware modifications.

  • A base station can receive a software update to support carrier aggregation or new modulation schemes without replacing physical components.
  • SDRs in satellite communication allow for in-orbit upgrades, enabling them to adapt to new communication protocols, enhancing their operational life.

Multi-Functionality

A single SDR can support various applications, making it an all-in-one solution for many industries.

Example:

  • A police department could use the same SDR device for communication across multiple frequencies and standards, such as VHF, UHF, and LTE, without needing separate equipment.
  • SDR platforms can serve as a testbed for telecom R&D, simulating different network environments (e.g., 3G, 4G, 5G) with just software adjustments, aiding in testing new protocols.

Scalability

SDRs can scale from individual use cases to large deployments with ease.

Example :

  • Telecom operators can use SDRs to roll out micro-cell networks in dense urban areas and expand coverage by simply reprogramming devices to add new frequencies or configurations.

Interoperability

SDRs can bridge communication systems that use different protocols or standards.

Example :

  • Disaster response teams benefit by using SDRs to interconnect communication systems from various agencies operating on incompatible legacy systems, ensuring seamless collaboration.

Educational and Experimental Use

SDRs are excellent tools for research and development due to their programmability.

Example :

  • Universities and labs use SDR platforms like USRP (Universal Software Radio Peripheral) for experimenting with AI-driven radio networks, exploring dynamic spectrum access, or prototyping next-gen wireless technologies.

Disadvantage/Challenges

While SDRs open the door to innovative applications, their potential disadvantages—ranging from security risks to performance limitations—highlight the need for careful design, robust security measures, and adherence to regulations. Addressing these challenges can unlock their full potential while minimizing associated risks.

Performance Limitations

Despite their versatility, the RF (Radio Frequency) performance of SDRs can be constrained by the capabilities of the transceiver ICs.

Example:

  • SDRs may struggle to maintain signal integrity at high frequencies, making them less effective for applications like millimeter-wave 5G.
  • In satellite communication, SDRs might exhibit performance degradation under extreme environmental conditions, such as temperature fluctuations or radiation.

Mitigation:

  • Combining SDRs with high-performance RF front-end modules and specialized hardware can address these limitations for specific use cases.
  • Offloading calculation intensive algorithms to a dedicated hardware (e.g, offloading LDPC process to a dedicated hardware)

Security Vulnerabilities

SDRs, being highly programmable, can be exploited by unauthorized users for malicious purposes.

Example:

  • Hackers could exploit vulnerabilities in an SDR-based communication system to intercept or manipulate sensitive data, such as in military or financial networks.
  • SDRs used in IoT devices could be hijacked through software vulnerabilities, creating an entry point for broader network attacks.

Mitigation:

  • Implementing robust encryption, secure boot mechanisms, and software integrity checks can minimize such risks.

Complexity of Development

The flexibility of SDRs comes at the cost of increased software and hardware design complexity.

Example :

  • Developers must possess expertise in both radio frequency engineering and software development, which could limit adoption among small companies or teams.

Mitigation:

  • Providing comprehensive SDKs, documentation, and training for developers can ease the learning curve.

Dynamic Range Issues

Some SDR designs have limited dynamic range, which can impair their ability to process weak signals in the presence of strong interference.

Example:

  • In crowded RF environments, such as urban areas with many cellular and Wi-Fi signals, an SDR might struggle to isolate a weak emergency signal due to its reduced ability to differentiate signal strengths.
  • Military applications requiring long-distance communication can face challenges when SDRs fail to filter out nearby strong signals from other sources.

Mitigation:

  • Enhancing analog front-end designs and leveraging advanced filtering algorithms can help improve dynamic range.

Software Complexity

Developing software for SDRs to support multiple protocols and platforms is challenging, increasing development time and cost.

Example:

  • An SDR designed for public safety communication might need to support both legacy analog protocols and modern digital standards, requiring significant development effort.
  • Startups aiming to deploy SDR solutions for diverse applications (e.g., IoT and satellite communication) may face barriers due to the expertise and time required for software development.

Mitigation:

  • Providing modular frameworks and pre-built libraries for common protocols can simplify development.

Analog-Digital Interfacing

Seamlessly interfacing analog RF components with digital processing modules is a critical and challenging aspect of SDR design.

Example:

  • SDRs for satellite ground stations often require precise synchronization between the analog and digital domains, which can be hard to achieve without introducing signal degradation.
  • High-frequency SDRs used in radar applications may suffer from performance losses due to inefficiencies in analog-to-digital interfacing.

Mitigation:

  • Using high-quality analog front-end components and advanced calibration techniques can address interfacing challenges.

ADC Limitations

The performance of the Analog-to-Digital Converter (ADC) in an SDR sets a hard limit on the maximum frequency and resolution that the system can handle.

Example:

  • In wideband communication systems, such as those operating in millimeter-wave frequencies, ADC limitations can restrict the bandwidth that the SDR can process.
  • SDR-based cognitive radios may fail to scan large frequency ranges efficiently due to ADC constraints, limiting their ability to dynamically utilize available spectrum.

Mitigation:

  • Employing higher-performance ADCs or combining multiple ADCs for parallel processing can expand frequency range capabilities.

Power Consumption

SDRs typically consume more power compared to purpose-built hardware radios, posing challenges for battery-operated devices.

Example:

  • SDR-based handheld radios for first responders may have reduced operational time due to high power demands, requiring frequent battery replacement.
  • In remote sensing or space missions, SDR power consumption becomes a critical factor as battery life and energy efficiency are paramount.

Mitigation:

  • Optimizing software algorithms for energy efficiency and employing low-power hardware accelerators can reduce power consumption.

Malicious Usage

Technically speaking, the items listed below is not from the limitation of SDR itself. Actually we can say it comes from the flexibility of SDR. The topics listed here would be largely from human factors like black-hacker mindset.

Privacy Concerns

    The capability of SDRs to monitor a wide range of frequencies can infringe on privacy.

    Example:

    • Malicious actors could use SDRs to intercept cellular or Wi-Fi signals, potentially extracting user location or sensitive information.
    • In densely populated urban areas, SDRs could be deployed to track individual devices by monitoring unique identifiers, such as IMSI (International Mobile Subscriber Identity) numbers, compromising privacy.

    Mitigation:

    • Enforcing regulatory constraints and encrypting device identifiers can help prevent privacy breaches.

Interference

    The programmable nature of SDRs makes them a tool for generating intentional interference, disrupting legitimate communications.

    Example: SDRs can be programmed to jam emergency communication channels, leading to serious consequences during disasters or security incidents.

    Extended Use Case: Industrial espionage could involve SDR-based interference to disrupt competitors’ wireless sensors or communication systems in manufacturing plants.

    Mitigation: Developing robust interference detection systems and implementing spectrum monitoring can help identify and counter such threats.

Malware Risks

    The flexibility of SDRs introduces the possibility of malicious software or malware being loaded into the system.

    Example:

    • An SDR-controlled base station could be infected with malware, causing it to redirect traffic to unauthorized networks or compromise data integrity.
    • SDRs in satellite systems, if compromised, could disrupt global communication or navigation services by sending erroneous signals.

    Mitigation: Regular software audits, sandboxing SDR applications, and using secure, authenticated updates can mitigate malware risks.

Regulatory Challenges

    SDRs’ capability to access multiple frequencies raises concerns about regulatory compliance.

    Example :

    • Unauthorized frequency usage could lead to legal penalties or conflicts with spectrum allocation authorities.

    Mitigation:

    • Embedding spectrum governance policies into SDR software can ensure regulatory adherence.

Reference

YouTube