The Wireless Industry’s Hidden Bottleneck. A Conversation with XRComm CEO Ahsan Aziz
When Ahsan Aziz was demoing one of the first millimeter wave 5G systems at Brooklyn5G, something clicked. The demo was a success — but sitting there afterward, he couldn’t stop thinking about how much better it could be done. That moment became XRComm.
In this interview, the founder and CEO of XRComm explains why the test and measurement industry was never purpose-built for wireless, why AI at the edge is a completely different problem than AI in the cloud, and why the gap between lab performance and field reality is costing the wireless industry years of development time. With 6G and non-terrestrial networks introducing physics that legacy platforms simply weren’t designed for, Ahsan makes the case that the prototyping infrastructure itself needs a reinvention — and why now is exactly the right moment.
When we started working in the early days of 5G, at National Instruments we were probably one of the only companies doing high-end prototypes — proving out millimeter wave, massive MIMO, all the key core technologies of 5G. We built solutions, but we also discovered that there are better ways to do things. It was very hard to do that on a platform that was already existing. If we had a clean sheet of paper, we would probably approach it in a different way. My colleagues and I were thinking: what is the best way to do this? If we had no restrictions, how would we go about it? We had a lot of ideas on how to do it but it was very difficult to do it, because the platform was already baked. Everything was designed, and it was not purpose-built for wireless.
Something purpose-built for wireless — to solve the complex problem of prototyping and testing communication systems that are increasingly getting complex — is what was needed. 5G, now going to 6G: throughput increases, latency goes down, quality of service expectations go up. On top of that, AI and ML come in. You can’t use a platform that was designed 10 or 20 years back. You have to do it from the ground up. That’s absolutely possible now because of technologies that didn’t exist back then — new AI chipsets, new RF chipsets, and compute platforms, which are critical for achieving real-time operations.
Now the question is how to combine all of that — the capabilities of test and measurement — and also bring in the learning from real-time systems deployed in the field.
So I did this work at National Instruments, doing prototypes and early development testing for 5G, gaining a deep understanding of the platform. Then when I came to Meta, I had the option to work with other test vendors, not just National Instruments. We had access to any test vendor we wanted. Even at Meta, we ended up creating our own test suites — not just scripting, but literally writing our own receiver algorithms hooked into the rest of the chain for system-level testing. We had several people just to maintain that. I was thinking: why should companies have to build this in-house? Why not provide this in a way where the framework exists and it’s easy for people to start from a solid point and customize from there?
Also with O-RAN, transceiver chipsets that were previously proprietary became more widely available. The idea was: how do you take that and combine it with test and measurement (which is predominantly not real-time) and create something that gives results quickly, reliably, and at the same time lets you track improvements or system issues in real time while the system is operating?
The moment for me was during 5G development. We were doing demos in Brooklyn5G, demoing one of the first millimeter wave systems. It was a big success. Right after, I was sitting there thinking: how can we do this better with everything we have learnt in the process? How can we make a product catered toward these prototypes and tests? That’s when, coming out of Meta, we started working on XRComm.
It’s two things. Cellular is evolving — going more toward 6G. And 6G is not necessarily just adding more throughput and less latency. It’s actually looking at new verticals: communication sensing, XR, new application spaces. Some of it is completely new and couldn’t have been done before because we didn’t have the compute capability or the RF capability. Now it’s there. You have all the pieces of the puzzle to build the whole picture.
On top of that, you have non-terrestrial communication. It started as something Apple would offer on your phone for SOS and special cases, but it’s starting to pick up as mainstream. Starlink is providing services, but it’s not at global cellular scale yet — though it’s going to get there. In the 3GPP roadmap, previously it was incremental improvements in throughput, lower latency, better coverage. Now we’ve saturated terrestrial networks and we’re looking at space. That’s a huge difference. It changes the dynamics of the networks. You can’t use the same old test equipment to test this completely new paradigm.
You have a ton of data, which means you have to process it really fast. And machine learning cannot be an afterthought — it has to be baked into the whole solution. A lot of the problem we see is: you collect data, you send it off, and you try to make sense of it. But in these situations, knowing what’s happening and responding right away makes a huge difference. Think about first responders, emergency situations — they need to react right away, not 10 minutes later. So you have to have real time.
I wouldn’t say they haven’t looked at the problem — they have, because they know about it. But if you look at traditional test and measurement, the mode of operation is that they didn’t require this type of capability before. They built platforms focused on RF fidelity, not so much on computation in a very tight time window. That’s a new requirement. Can they address it? Yes — but they would have to introduce a new line of products, build a whole new organization, and start looking at that problem from a different angle. That’s completely new work, and it requires people who understand both sides — being a customer of test equipment and also building it.
That is exactly how XRComm is structured. We have people who have worked both building infrastructure and building test equipment. They were sitting there thinking, ‘I wish I had that feature.’ Now they have the opportunity to build it. It will take the other test companies time to catch up.
It’s the fundamental architecture. You can’t change an architecture on the fly.
When most test vendors say they have AI capabilities, what they’re doing is capturing data, sending it offline, and doing analysis. That works in many cases — in the lab it’s perfect. But when you collect data in the field, you don’t have time to react to it. What our system allows you to do is analyze at the edge. You train first, then do inferencing and react. That ability to react — that’s the difference. Most test instruments don’t react. We can react. That’s the big deal.
After leading innovation at companies like Meta and National Instruments, what convinced you that real-world, field-driven experimentation had become a critical bottleneck for next-generation wireless innovation?
At Meta, what we were doing was augmenting existing test instruments. Every single call with test vendors involved asking: do you have real-time capability? Do you have a way to really analyze certain things dynamically? Today, a lot of measurements are one-directional. You send a waveform or a beam and you measure it. You switch and you measure. But you cannot respond to it. The response I got from most vendors when we were doing beam switching and beam tracking was: script everything. Script how the beams are going to switch and how things will react. That’s not real life.
If you take a scripted system out to the field, it will fail many times. You pass with flying colors in the lab, you take it to the field, it doesn’t pass, and you go back to engineering. That iteration continues. When you start with a system that can react and do real-time field testing, your objective is not to satisfy lab conditions but to satisfy real field conditions.
In lab conditions, it’s a nicely set up simulation environment. But in reality, even a slight change in weather, a vehicle moving, or a person walking by changes your RF channel completely. These are conditions the actual system has to deal with. The traditional argument is that you can do enough testing in the lab. That policy has been going on, but it increases time to market. Customers we’re working with confirm it: they want to solve the problem in the field. The results in the field versus the lab are different.
It’s the dynamic condition of the RF environment. It’s not predictable. It’s how your RF front end behaves. In satellite conditions, the satellite is moving. Your system has to track it. There’s the satellite itself, its moving antenna, how it’s transmitting the waveform, propagation through space, your receive antenna, your surroundings, whether you’re moving, vehicles around you — all of these components add up. It’s very hard to emulate these scenarios in the lab.
3GPP started with purely statistical channel models, and that’s still primary. But now they’re starting to add ray-tracing models and alternative approaches. Why? Because there’s an understanding that the model has to evolve. The antennas are different, the environments are different, new types of applications are being served. 3GPP gives you minimum requirements — it doesn’t tell you what your secret sauce is. What we’re enabling customers to do is see what they’re actually going to encounter in the field.
Current instruments are challenged by the limited time span of a satellite pass, higher data throughput, and the need to process data, identify problems, and feed back results quickly so the satellite can be adjusted and retested on the next pass. Is that the only way it can be done?
That’s one part of the story. During deployment phases, you’re not going to have continuous satellite coverage. You do a test, then for periods of time there’s nothing to test, or you have to go to a specific location to collect data. Companies face the question of whether the data they collected is correct. If you’re taking smaller snippets, things could have gone wrong in that snippet. Unless you’re capturing everything, you’re missing something.
Current instruments can capture everything, but then you have to take it back to the lab, process it, and months later you find out you had a problem somewhere. It takes a long time to identify the problem. Even if you capture everything, sitting through all that data is a lot of work. You’re not interested in 99.99% of it — it’s that 0.01% you need. But you have to go through the huge amount of data to find that needle in a haystack.
With our system, before the satellite passes by, you know what happened.
The customer knows — and there’s a quote I really like: if it takes a researcher half a year or a year just to get to their actual problem, that’s a huge time lost. It’s not acceptable. This is the reason people have shied away from prototyping.
In academia, a master’s or PhD student has a limited amount of time. They don’t have 10 engineers working on a problem — they have one student working on it. They might be onto an excellent idea for next-generation wireless or machine learning, but if it takes a year before they can even touch their own problem, it creates fear of touching hardware in the future. Pure theory is easier, but theory has to be implemented.
What we’re trying to do is reduce that time frame. When a student or researcher gets this unit, they’re not worried about all the infrastructure complexities. They’re focusing on their own problem. We want to put them in their comfort zone: Python, C++, FPGA, GPU, CPU — their choice. We provide a sandbox with all the hooks in place so they don’t spend time building from scratch.
In industry research labs, the challenge is different. They’re working on technologies a few to ten years ahead of products. Either they build hardware themselves — which is not cheap and not their main thing — or they depend on product teams, who are busy and can’t give full-time support. The hardware doesn’t have all the bells and whistles needed, so researchers spend time integrating components, often abandon the effort, and start building their own. Every iteration is expensive. Eventually the platform has to be redone completely.
Our job is to maintain the prototyping platform, keep it up with the latest standards, and give researchers the flexibility they need — both in industry and academia.
You’re not dealing with one system. Take Doppler as a simple example. In a terrestrial network, you have a certain amount of Doppler and carrier frequency offset — it’s manageable. We know how to deal with it. But if you’re driving and you switch to a non-terrestrial network, your Doppler is completely different. Then you switch back to terrestrial and it’s different again. This back and forth between networks with completely different physics is challenging. It’s hard to build a system that supports all of that. Fundamentally, that’s what’s baked into our system — from the ground up we’ve thought about and built the logic and hardware requirements to support it.
When you take a system to the field, it’s not just one network — it’s multiple networks, multiple components that can go wrong. The question becomes: who is at fault? The subscriber unit? The satellite signal strength? The customer terminal?
This is exactly where our system comes in. It acts like a golden test unit. It measures exactly the way a handset would, but it also tells you the actual signal condition. To the handset providers, it says: this is what we’re seeing in real life, this is what you’ll have to deal with. We correct for all the impairments seen and give the customer terminal a clean signal that it should be able to demodulate. We can also switch between the clean signal and the true signal by flipping a switch. That lets developers identify root cause — is the problem the signal in the field, or the device?
You identify failure modes in real time. If a failure shows up 70% of the time and another 20% of the time, you know which to prioritize. Is it a critical problem or an annoying one? Classifying those in real time saves a huge amount of time. Otherwise you have to go through tons of data just to identify failure modes.
The most important thing is knowing the failure modes in the field. As you test systems in real time, you start to understand those failure modes. You should be able to observe them in the field and ask: am I seeing any of these failure cases? If not, I’m performing very well.
Let me give an example. When I was at Motorola working on echo cancellers, we’d get recorded clips with echoes, take them to the lab, run them in MATLAB, update our algorithms, give the customer a new build. They’d take it to the field and find new issues. That iterative process could become like whack-a-mole. Field testing makes a difference because you identify the problem right then and there. You know the failure modes. When a developer has data on a failure that occurs 70% of the time in the field, they can hone in on it. Even just prioritizing — is this a critical problem or just an annoying one? — classifying that in real time saves enormous time.
A system used to collect data and test in real time needs to be a very good replication of the actual deployed system. It has to have all those hooks in place. Antenna controls, gain controls, correct AGC behavior — everything is time-critical. Non-real-time scanning can miss the relevant link. If you’re doing scanning, you might be pointing in the wrong direction. A reactive system that aligns to the signal you’re connected to ensures you’re measuring what you need to measure, not something irrelevant.
MIMO scaling, timing, latency across the chain, distributed processing — these are fundamental today. They weren’t problems in earlier generations of wireless, but now they’re absolutely critical. The way things are tested now is one instrument for one thing, then switch to another instrument for something else — a beam scanner, then an emulator. We combine it all to behave like the real system in the field, which is ultimately the problem everybody should be solving.
I personally think it’s not about throughput or latency. It has to bring fundamental changes in the way we operate and improve people’s lives. Cellular changed how people communicate. The iPhone changed how we look at a phone — it became something we use every day, always connected. What is the next thing that improves people’s lives? Being able to download a movie 10 times faster — I don’t think that changes my life.
The whole industry is exploring what that next thing is. NTN is very promising. Motorola tried to solve this problem a long time ago with Iridium — they were ahead of their time, and the technology ultimately ended up in the Smithsonian. Then GPS, which we now can’t imagine living without.
There are so many places around the world that are not connected, and laying fiber or building base stations is not an option there. If we can connect them into the network, it changes the economics and dynamics of everything. We have to bring it to a point where it’s sustainable — like standard cell phones today. That’s why I feel this could be the next revolution.
Ahsan, thank you so much for your time. It was a pleasure talking with you and a pleasure to be part of your team.
Thank you, Michel.