Joint Communication And Sensing

Building a Practical JCAS System: What the Papers Don't Tell You

Joint Communication And Sensing is fundamentally about making one radio do two jobs that actively fight each other. Your communication link wants high spectral efficiency and low error rates. Your radar wants high peak-to-sidelobe ratio, wide bandwidth, and precise timing. When you try to run both from the same waveform and the same hardware, you immediately run into a problem: the radar echo coming back into your receiver is sometimes 80 to 100 dB stronger than the communication signal you're trying to decode. This isn't theoretical. I ran into this firsthand while simulating a 60 GHz JCAS prototype last year, and it took three weeks just to get the interference cancellation stage to stop corrupting the QPSK demodulation. The core idea behind JCAS is straightforward on paper. You design a transmit waveform that carries communication symbols while also serving as a probing signal for sensing surrounding objects. The reflected signal comes back, and you process it to estimate range, velocity, and angle. All of this happens using shared spectrum, shared antennas, and increasingly shared hardware. The alternative is running two completely separate systems, which doubles your cost, your power consumption, and your spectral footprint. Nobody wants to do that anymore, especially not in automotive or drone applications where space and weight are constrained.

The Waveform Problem Nobody Simplifies

Most introductory materials present JCAS as if you just take an existing OFDM waveform and call it a day. That's wrong. Standard LTE or 5G NR OFDM has a cyclic prefix that creates poor autocorrelation properties for radar. The sidelobes sit around -13 dB, which means a strong reflector will completely mask weaker targets nearby. In my own simulations, I tried using a pure OFDM waveform with 256 subcarriers at 60 GHz with 2 GHz bandwidth, and the radar performance was unusable. Close targets drowned in the sidelobe clutter from far targets. The fix is either to modify the OFDM spectrum or switch to a different waveform family. One approach that actually works in practice is to apply amplitude weighting across subcarriers using a Dolph-Chebyshev window. This pushes the sidelobes down to roughly -25 to -30 dB at the cost of slightly widening the main lobe. Range resolution degrades by about 10 percent, but you can now detect targets adjacent to strong reflectors. Another option is to use a phase-coded waveform like a Zadoff-Chu sequence, which has constant amplitude and excellent autocorrelation. The tradeoff is that phase-coded waveforms carry less communication data because the symbol mapping becomes more complex. If you need high data rates, stick with shaped OFDM. If you need decent radar performance with moderate data rates, phase coding is viable.

Self-Interference Cancellation: Where It Gets Messy

This is the part that breaks most JCAS implementations. When you transmit and receive on the same frequency, even with time division, leakage from the transmitter couples into the receiver through the antenna isolation, through the power amplifier nonlinearity, and through the circulator or switch. I spent an entire sprint debugging what I thought was a processing bug. The receiver kept showing constellation diagrams that looked like they had been thrown through a blender. It turned out the self-interference signal was passing through the power amplifier again on the leakage path, introducing nonlinear distortion that was completely non-stationary. Linear cancellation alone wasn't enough. The workaround I settled on was a hybrid approach. First stage: analog cancellation using a tapped delay line that models the direct path leakage. This reduces the bulk of the interference by about 30 to 40 dB. Second stage: digital cancellation in the baseband processor, where I estimated the residual interference using a Volterra series model to account for the PA nonlinearity. This brought the total self-interference suppression to around 70 to 75 dB. The remaining 10 to 15 dB gap was handled by time division—making sure the radar receive window didn't overlap with the communication transmit window, and vice versa. This TDM approach is simpler than full-duplex JCAS and good enough for most automotive and drone applications where latency requirements aren't ultra-tight.

Hardware Considerations That Matter

If you're building this for real, not just simulating it, you need to think about the hardware early. The power amplifier is the biggest bottleneck. JCAS waveforms tend to have high peak-to-average power ratios, especially when you're combining communication symbols with radar coding. A PA operating at 6 dB back-off from saturation will introduce AM-PM distortion that wrecks both the communication EVM and the radar pulse compression. I measured an EVM degradation of about 4 percent when the PA went from 3 dB to 6 dB back-off, and the radar sidelobe level rose by nearly 6 dB. Running the PA harder saves power but destroys performance on both fronts. Phase noise is another hidden killer. At 60 GHz, even a decent local oscillator will have phase noise that spreads energy across adjacent subcarriers. This widens the radar main lobe and increases the communication inter-carrier interference. I found that using a phase-locked loop with a narrow loop bandwidth helped, but it made the system more sensitive to temperature drift. A warm-up period of about 10 minutes was necessary before the oscillator stabilized enough for reliable JCAS operation. If you're deploying this in a vehicle that starts and stops frequently, this matters a lot. Antenna design is equally critical. A shared aperture is ideal for minimizing size, but it requires a wideband circulator or a fast RF switch. Commercial circulators at 60 GHz typically provide only 20 to 25 dB of isolation, which is nowhere near enough on its own. You need the analog cancellation stage I described above to make up the difference. If you use separate antennas for transmit and receive, you get natural isolation of 30 to 40 dB, but that defeats some of the size and cost savings of JCAS. The right choice depends entirely on your application constraints.

Common Implementation Pitfalls

One mistake I see repeatedly is assuming that standard channel estimation techniques work for the sensing part. They don't. Communication channel estimation gives you a multipath profile, which is useful for equalization but useless for accurate range estimation. You need cross-correlation or matched filtering against the known transmitted waveform to extract range and Doppler information. These are fundamentally different operations. I wasted two days trying to use a pilot-based channel estimator for radar ranging before realizing the mismatch. Another pitfall is underestimating the computational load. Radar processing with 2 GHz bandwidth and millimeter-scale range resolution requires high-rate sampling and large FFT sizes. A 4096-point FFT for range processing followed by another for Doppler estimation, all running in real time alongside communication decoding, is not trivial on typical embedded hardware. I ended up using a custom FPGA implementation for the radar signal processing and offloaded the communication PHY to a soft-core processor. Even with this split, the power draw was higher than I originally budgeted. If you're targeting battery-powered platforms, plan for significant power management overhead.

When JCAS Is the Wrong Choice

Joint Communication And Sensing is not a universal solution. If your application requires high-data-rate communication above 1 Gbps and simultaneously needs centimeter-level radar resolution at long ranges, a joint system will compromise both. In those cases, separate dedicated systems remain the better option. The spectral efficiency gain from sharing is real but modest—usually in the 15 to 25 percent range for well-optimized designs. The complexity penalty is substantial. I've seen projects where the JCAS approach saved roughly $40 to $60 in bill-of-materials cost per unit but added six months of development time and required a completely different test and validation pipeline. For volume automotive production, that tradeoff might be worth it. For a prototype drone project with a tight deadline, it's probably not. Before committing to hardware, build a simulation. MATLAB and Python both have toolchains that can model a basic JCAS link. Start with a simple OFDM waveform, implement the TDM schedule, add a realistic self-interference channel model, and verify that your cancellation stages bring the interference below the receiver noise floor. Test with different waveform shapes—standard OFDM, windowed OFDM, and phase-coded—and compare the radar ambiguity function against the communication BER. This step alone will save you weeks of hardware debugging. I learned that the hard way after building my first prototype without adequate simulation coverage. There's no single open-source JCAS framework that covers the full stack from waveform generation to radar processing to communication decoding. Most research code is fragmented across different repositories. The closest thing to a practical starting point is adapting existing 5G NR PHY layers and adding a radar processing block on top. This requires understanding both the communication standard and the radar signal processing pipeline, which is a steep learning curve. But once you have the pieces connected, the system behaves predictably, and you can iterate from there.