Same UE, Same MCS, Different Throughput: What I Check First

A capability profile describes support. It does not show which resources carried data during your test.

Watch my English explanation: Same Phone, Different 5G Speeds?

Supported versus active 5G resources

When two tests use the same phone but produce different data rates, I compare what actually operated during the observation interval. Equal reported CQI and MCS do not establish equal throughput. Active component carriers, allocated resource blocks, spatial layers, transmission opportunities and retransmissions still matter.

This article is for engineers who know basic LTE/5G terminology. My previous registration example asked whether a data session had been established. This question starts after connectivity: why did the measured performance differ?

A supported feature is not an observed allocation

Here is an instructor-authored teaching comparison, not a customer trace or a new measurement.

ConditionRun ARun B
Supported UE profileSameSame
Active component carriers21
Allocated PRB in the intervalHigherLower
Observed downlink Rank21
Reported CQI / MCSSame valuesSame values
Application throughputHigherLower

A phone may support CA or four-layer reception without using every supported carrier or layer in a particular transfer. I check the actual combination, configuration and activation state, then the resources used over time.

What the table cannot prove

Several conditions changed together. I cannot use this table to assign the whole gap to Rank, calculate a precise Mbps value, or prove an antenna fault. A screenshot of MCS also does not describe all successful new data delivered over an interval.

I align the measurement layer and time window first. Then I record active CCs, PRB allocation, MCS, actual Rank, transmission opportunities and retransmissions. Comparing successful radio delivery with PDCP and application data helps identify where the gap opens.

Few PRBs: congestion or too little data to send?

If enough data is waiting but allocation remains small, scheduling and cell load deserve investigation. If the buffer frequently empties, the server or TCP may not be supplying enough data. A small allocation alone does not settle which explanation is correct.

I keep radio conditions comparable, change either the server or stream count, and observe buffers, grants and application speed together. Changing several conditions at once can improve a result without explaining the limiting stage.

Low Rank: choose a comparison before naming a fault

I first confirm the layer support of the selected combination and the network configuration. Next, I vary one condition such as orientation or location while recording RI, actual Rank, MCS and successful delivery. If Rank rises but MCS falls, the final transport-block sizes and received data determine whether the change helped.

My test note has five parts: suspected cause, conditions held fixed, one controlled change, associated counters, and the result that would change my conclusion. If radio delivery is adequate but the application remains slow, I follow the processing path into TCP, the server and the UE.

Practice the reasoning, not just the terminology

My VoLTE/IMS & 5G/LTE Throughput: Big Tech Interview Prep course connects signaling, resource calculations and performance diagnosis. Lessons 7–12 work through OFDM, UE capability, CA/MIMO and controlled comparisons. It is intended for mobile-device development, validation and performance engineers, including those preparing to explain their reasoning in technical interviews. No separate measurement equipment or paid analysis software is required.

View the course curriculum and previews →

The companion video uses English narration. This article is self-contained.

References: MathWorks lteTBS · LTE carrier aggregation example

Comments

Post a Comment

Popular posts from this blog

Vibe Coding and AI Agents: A 30-Day Project Diary

Prologue: From a personal dashboard to content projects, starting with a $20/month AI subscription Building an AI one-person content studio with ChatGPT, Codex, and human judgment Turning one idea into a finished result requires more roles than it first appears. Someone has to define the problem, break the work into tasks, create the files, review the result, and decide what should happen next. This series documents how I ran that process as an AI-agent collaboration using ChatGPT and Codex. I set the direction and quality bar. ChatGPT structured the requirements and content. Codex handled execution at the level of code, files, documents, and production packages. The first proof case was a personal asset-management automation system. I then applied the same operating model to YouTube Shorts, webtoons, motion comics, blogs, and a future book. The result is becoming a multi-channel publishing system for an AI one-person content studio. Why I started The project did not begin with a grand...
Read more

From Webtoon to Novel: Adapting One Story Across Formats

Image
The creative background behind Learning to Take My Place, from visual storytelling to a published novel What a one-person AI studio taught me about expanding an IP instead of copying it I did not set out to make a film or write a novel. The original plan was much smaller: spend thirty days finding out what a non-developer could actually build with a $20 monthly AI subscription, then turn the experience into a book. The project refused to stay inside that book. One of its lessons became a webtoon. An incident in the webtoon became a motion comic, then a three-minute, fifty-three-second short film. The same characters eventually moved into an eighteen-chapter workplace thriller. From the outside, it may look as if I made one thing and reused it several times. The opposite was true. The moments that failed most often were the ones where I trusted an existing asset to work in a new medium without rebuilding it. Episode 6 opens with a question rather than an explanation: if the accident nev...
Read more

VoLTE Call Connected but No Audio? Check SIP, SDP, and RTP Separately

Image
  A connected-call indicator does not prove that usable audio is reaching the listener. I separate three questions: was the session established, what media conditions were negotiated, and what packets actually arrived? That separation helps narrow down a VoLTE no-audio problem without guessing the cause. 1. Which request received the 200 OK? SIP controls session establishment, modification, and termination. A 200 OK for REGISTER is different from a 200 OK for INVITE. Identify the call using its Call-ID and CSeq, then correlate the successful INVITE response with its ACK. This is evidence about call setup; it is not evidence that speech reached either listener. 2. Read SDP as receive destinations and media conditions Compare the offer and answer currently in effect: audio receive addresses, ports, codecs, and direction. If an UPDATE or re-INVITE changed the session, the initial SDP alone is insufficient. c= : connection address. A media-level c= overrides the session-level add...
Read more