<!-- title: 测速五百兆，发图却转圈 -->

## 概述

5G满格、下行测速五百兆，发一段60秒视频却转圈两分钟，视频通话里对方看你像幻灯片——这几乎是每个用户都遇过、却很少有人讲清楚的问题。本文回答三个问题：为什么移动网络的上行天生比下行弱？第三方实测数据和学术论文是怎么证实“上行受限”的？运营商和设备商这些年用什么方案补上行、效果如何？文中数据均锚定华为官方新闻稿、Opensignal报告、3GPP规范与arXiv论文等可查来源。

## 目录

- 一、被测速软件藏起来的半张网
- 二、上行天生瘸腿：压在终端头上的三座大山
- 三、第三方实测与论文：上行受限不是错觉，是结论
- 四、补上行三板斧：从超级上行到AI上行池
- 五、一线排查：转圈到底是谁的锅
- 六、AI时代，上行第一次当主角
- 七、结论：下次投诉前，先看上行

## 一、被测速软件藏起来的半张网

干了十八年核心网和无线优化，我处理过的“网速慢”投诉里，有个反复出现的模式：用户满腔怒火地打来电话，工程师上门一测下行，四五百兆，漂亮得很；再让他发个东西出去——卡住了。卡的不是下行，是上行。

这事被测速软件的展示习惯进一步掩盖了。几乎所有测速App的默认大数字都是下行速率，上行缩在角落里一行小字，多数用户从来没看过它。而运营商的营销物料更是如此——“下行千兆”是卖点，上行 rarely 出现在广告里。于是用户的心理预期被训练成“我的5G很快”，一旦发图转圈、直播掉帧，第一反应就是“运营商骗人”。

其实感知上的账很好算。你的手机上网是两条腿走路：下行负责“收”，刷视频、下载、看网页都靠它；上行负责“发”，发消息、传文件、视频通话里让对方看到你，都靠它。这两条腿的粗细完全不对称——第三方测速机构Opensignal在其2026年1月发布的《美国移动网络体验报告》中明确写道：上传速度通常慢于下载速度，因为当前移动宽带技术把资源集中用于给用户尽可能好的下载体验（来源见文末）。这不是美国一家的现象，是全球TDD/FDD网络的通病。

几个典型场景，上行的重要性立刻显形：

- **视频通话**：你看到的对方画面走的是对方的下行和你的下行，清晰流畅；而对方看到的你，走的是你的上行。上行一抖，你在对方的屏幕里就变成幻灯片。
- **直播推流**：观众端画质的上限，是主播手机的上行。上行撑不住，平台会自动把码率往下砍，观众看到的就是“高清变流畅”的降级画面。
- **相册备份、发大文件**：纯上行活，下行再快也帮不上忙。
- **家庭监控、FWA宽带**：摄像头往云端推流、家里多台设备同时上传，全部压在蜂窝网上行这一根管子上。

换句话说，用户感知里的“网慢”，相当一部分根本不是下行问题，而是这条从来不打广告的半张网在拖后腿。

## 二、上行天生瘸腿：压在终端头上的三座大山

上行为什么弱？不是谁偷懒，是三个物理与设计层面的结构性约束叠加的结果，我称之为三座大山。

**第一座山：功率。** 3GPP规范TS 38.101-1第6.2.1节规定了终端的功率等级，智能手机默认的Power Class 3最大发射功率是23dBm，也就是200毫瓦（规范原文见文末3GPP链接）。而宏站侧，一个单通道功放普遍在10瓦到40瓦量级，换成64通道大规模天线整机，发射功率可达数百瓦。做个直观对比：基站单通道对手机是两百倍的功率差（约23dB），上整机更是千倍量级。无线上行链路靠的是手机那200毫瓦“喊话”，喊到小区边缘自然先哑。做链路预算的同行都知道一句话：上行几乎总是5G覆盖规划中的受限链路——这不是经验之谈，是算出来的。

**第二座山：时隙配比。** 国内主流的5G频段（2.6GHz、3.5GHz）用TDD制式，上下行共用同一频段、靠时间轮流。为了让“刷视频”这种下行业务爽，行业普遍采用了重度偏下行帧结构，比如常见的DDDSU配比：5个时隙里3个纯下行、1个纯上行、1个上下行混合但大头仍给下行。折算成无线资源，上行占比通常不到三成。这其实是4G时代延续下来的理性选择——移动互联网十年都是下行主导，把资源倾斜给下行是对的。但代价是上行的容量天花板天生就低。

**第三座山：频率。** 5G主力频段在3.5GHz上下，比4G时代1.8GHz的老频段高了不少。按自由空间传播公式折算，同距离下路损高出约6dB，穿一堵墙还要再亏几个dB。基站可以用加大功率来补偿频率劣势，手机的200毫瓦却是焊死的——频率越高、上行越吃亏，且终端没有任何补偿手段。

| 维度 | 下行 | 上行 | 用户感知后果 |
| --- | --- | --- | --- |
| 发射功率 | 宏站单通道10-40W，整机动辄数百瓦 | 终端上限23dBm（200mW），规范锁死 | 小区边缘发图先卡，刷视频却还能看 |
| 时隙配比 | DDDSU等主流配比下行占七成以上 | 上行资源不足三成 | 上行峰值速率天花板低，忙时先拥塞 |
| 频率路损 | 基站可加功率补偿 | 终端无补偿手段 | 3.5GHz室内上传比下行劣化更早 |

三座大山叠在一起，结论就一条：**下行决定你能刷多快，上行决定你能发多爽——而后者先天不足。**

## 三、第三方实测与论文：上行受限不是错觉，是结论

感觉要变成结论，得看数据。这里给三块独立的证据。

**证据一：第三方测速机构的报告。** Opensignal在《美国移动网络体验报告》（2026年1月版）中把“上行慢于下行”作为行业常态写入正文。往前翻它的历史报告更直观：2024年1月版美国报告里，T-Mobile的5G下行均速达到204.9Mbps、首次突破200Mbps大关，而上行冠军Verizon的5G上行速率只有下行的零头——头部运营商尚且如此，上下行的量级鸿沟是全球性的。值得注意的是，Opensignal在同一批报告里专门提醒：随着用户从“消费内容”转向“创作和分享内容”，上行正变得越来越重要。

**证据二：学术论文。** 2025年11月提交的arXiv论文《Evaluations of High Power User Equipment (HPUE) in Urban Environment》（arXiv:2511.19871）开篇即指出：元宇宙、物联网、智慧城市等新型应用对上行吞吐提出高需求，而终端23dBm的功率上限制约了上行体验，因此3GPP在5G TDD频段引入了高功率终端（HPUE），允许终端以超过23dBm的功率发射，以改善小区边缘的吞吐、体验质量与可靠性。学术界把“上行受限”当作前提写进论文，说明这在工程界早已是共识。

**证据三：标准本身。** 3GPP把终端功率等级白纸黑字写在TS 38.101-1里，FR1频段默认Power Class 3即23dBm——二十年来手机功率就没变过，而基站功率、天线数、频谱带宽一路狂飙。链路预算教材里那句“上行几乎总是受限链路”，就是这套规范的现实投影。

需要说明的是：Opensignal的数据来自其用户众包测速，反映真实用户环境；arXiv论文与3GPP规范则是原理层面的论证。三者口径不同，但指向一致。

## 四、补上行三板斧：从超级上行到AI上行池

上行这块短板，行业不是不知道，而是补了七年。按时间线捋一遍主流方案：

**第一板斧：标准层——SUL补充上行。** 3GPP在R15就定义了SUL（Supplementary Uplink）：给TDD频段配一条FDD低频的“上行专用辅路”。TDD大带宽负责近点的上行高速率，手机到了边缘就自动把上行切到低频FDD上——低频路损小、绕射强，同样200毫瓦能喊得更远。上行载波聚合（UL CA）思路类似，把两个上行载波捆绑，边覆盖边提容。

**第二板斧：商用层——超级上行。** 这是目前最著名的上行增强商用品牌。2019年6月MWC上海期间，中国电信与华为联合发布5G超级上行解决方案，核心就是TDD/FDD协同、高低频互补、上下行时频域聚合。2019年8月22日，华为官方新闻稿宣布：中国电信上海与华为开通全球首个5G超级上行网络，在同济大学完成性能验证——从发布到首网只用了两个月，建成小规模连续覆盖。新闻稿披露的验证结果是：**在无线环境良好的点位，上行速率提升20%~100%；小区边缘上行速率提升到原来的4倍**（厂商联合验证口径，见文末华为官方链接）。随后上海电信把超级上行用到了第二届中国国际进口博览会上做实战保障。要提醒读者的是，“边缘4倍”是特定网络、特定点位下的验证数据，规模网络上的收益会随场景浮动，但它证明了方向的有效性。

**第三板斧：终端与AI层。** 终端侧，就是前文arXiv论文研究的HPUE：在TDD频段放开更高功率等级，让手机“嗓门”超过23dBm，直接改善边缘上行。AI侧，据RCR Wireless 2025年6月26日报道，中国电信与华为发布了面向5G-A的上行增强新技术——AI驱动的上行资源池化，用AI动态调度来改善速率、时延与覆盖，明确指向车联网、可穿戴设备和AI助手等新兴业务的上行需求。上行问题，正在从“无线优化题”变成“AI调度题”。

```mermaid
timeline
    title 上行补强这些年
    2018 : R15冻结 : SUL写入标准
    2019 : MWC上海发布超级上行 : 同济完成首网验证 : 进博会实战
    2020后 : R16上行天线切换增强 : HPUE高功率终端起步
    2025 : 电信华为发布5G-A AI上行增强
```

| 方案 | 引入时间 | 原理一句话 | 公开效果数据 | 现状 |
| --- | --- | --- | --- | --- |
| SUL补充上行 | R15（2018冻结） | TDD借FDD低频作上行辅路 | 边缘上行显著改善 | 标准配置 |
| 超级上行 | 2019年6月发布 | TDD/FDD协同、时频聚合 | 好点+20%~100%，边缘4倍（同济验证） | 中国电信规模应用 |
| 上行载波聚合 | R15/R16 | 捆绑两个上行载波 | 视配置可近翻倍 | 主流设备支持 |
| HPUE高功率终端 | 逐步引入 | 终端功率突破23dBm | 改善边缘吞吐与QoE（arXiv论文评估） | 依赖终端芯片支持 |
| AI上行池化 | 2025年发布 | AI动态调度上行资源 | 改善速率、时延、覆盖（RCR报道） | 5G-A阶段试点 |

## 五、一线排查：转圈到底是谁的锅

讲了原理和方案，回到一线。用户抱怨“网慢”时，怎么快速判断是不是上行拖的后腿？给大家一套我在现场用了多年的简化流程：

```mermaid
flowchart TD
    A["用户说网慢"] --> B["先测下行"]
    B -->|不达标| C["覆盖或拥塞问题"]
    B -->|达标| D["重点查上行"]
    D --> E["看终端发射功率"]
    E -->|顶格23dBm| F["功率受限接近边缘"]
    E -->|余量充足| G["看上行BLER与MCS"]
    G -->|BLER高| H["上行干扰或弱覆盖"]
    G -->|正常| I["帧结构调度受限"]
    F --> J["对策加站或上SUL"]
    I --> K["对策调整帧结构"]
```

拆开讲几个关键点：

- **让用户先测下行**。下行不达标，是覆盖或拥塞问题，按老路子处理；下行漂亮还卡，九成在上行。
- **看终端发射功率**。手机工程模式或网优类App能看到发射功率，如果长期顶在23dBm打满，说明手机已经把嗓门喊到最大还够不着基站——功率受限，位置接近边缘。
- **功率没顶格却还慢，查干扰和帧结构**。上行BLER高通常是干扰；BLER正常但速率上不去，要怀疑上行资源分配。这里有个我记忆很深的教训：某年一个直播商家聚集的片区，投诉爆发，我们按干扰排查了两天底噪，一无所获，最后发现是新开站割接时帧结构模板抄错了，上行时隙配比比规划少了一半——干扰指标一切正常，上行资源天生被砍，商家直播集体卡顿。改回配置，投诉当场消停。**配置错误不会报错，只会慢慢折磨用户**，这是上行排查里最阴的一类。
- **别忽略终端自己**。手机握持时手掌捂住边框天线、直播半小时后温控降功率，都会让上行悄无声息地掉速。让用户换个握姿、歇两分钟再测，经常有奇效。至于网上卖的“信号增强贴”，省下这份钱。

对普通用户，就记一条：**视频通话里对方看你卡、发东西转圈，先想想自己的上行——换个靠窗的位置，往往比重启十次都管用。**

## 六、AI时代，上行第一次当主角

过去二十年，上行是被商业模式“压抑”的半张网——没人为它付费，没人为它营销。但2025年之后，风向明显变了，三个推力同时发力：

**一是AI终端的原生上行需求。** 智能眼镜的第一视角视频要往云端传、AI助手要同步上下文、车端摄像头要回传数据——这些全是持续、稳定、时延敏感的上行流。前文提到的中国电信与华为5G-A上行增强，据RCR Wireless报道，目标场景正是联网汽车、可穿戴设备与AI助手。厂商已经把上行当成AI基础设施的一部分来卖。

**二是FWA把家庭上行搬上了蜂窝网。** 用5G CPE替代宽带的家庭越来越多，相册备份、多路监控上传、远程办公视频会议，把过去有线宽带上行才扛的活全压到蜂窝网上行，短板被进一步放大。

**三是行业场景的上行刚需。** 从2019年超级上行发布时华为点名的直播、教育、制造、医疗、安防，到今天直播基地、智慧矿山、远程操控，2B市场为上行付费的意愿远比2C明确——这也是运营商愿意真金白银补上行的重要原因。

| 场景 | 上行需求特征 | 卡住时的表现 |
| --- | --- | --- |
| 视频通话/会议 | 持续1-5Mbps，时延敏感 | 对方看你卡成幻灯片 |
| 直播推流 | 持续4-10Mbps，不能断流 | 掉帧、画质自动降级 |
| FWA家庭/监控回传 | 多路并发、7×24小时 | 上传队列积压、丢帧 |
| AI眼镜/车端回传 | 第一视角视频流，突发+持续 | 端云协同失灵 |

## 七、结论：下次投诉前，先看上行

把全文收拢成三句话：

**第一，上行慢是结构性的，不是运营商偷懒。** 200毫瓦对数百瓦的功率差、不足三成的时隙占比、3.5GHz的额外路损，三座大山决定了上行的先天地位。理解这一点，你对“满格信号发图转圈”就有了物理层的宽容。

**第二，行业补了七年，且越来越认真。** 从R15的SUL，到2019年同济大学验证的超级上行（好点提升20%~100%、边缘4倍），到HPUE放开终端功率，再到2025年的AI上行池化——上行正在从无线优化里的“配角指标”变成AI时代的基础能力。

**第三，给读者三个立刻能用的建议**：测速别只看下行大数字，上行那一行才是发图、通话、直播的命门；视频通话卡，先检查自己的位置和握姿，你的上行决定对方眼里的你；在家里给监控、FWA规划上传业务前，先实测一次上行速率，别等装完才发现管子不够粗。

网络的下半场，拼的不再是“你能收多快”，而是“你能发多稳”。被忽视了十几年的半张网，终于走到了聚光灯下。

## 参考来源

1. [China Telecom Shanghai and Huawei Debut World's First 5G Super Uplink Network — 华为官方新闻稿（2019-08-22）](https://www.huawei.com/en/news/2019/8/shanghai-telecom-5g-superul) — 全球首个超级上行网络、同济大学验证数据（+20%~100%、边缘4倍）与进博会应用的原始出处
2. [China Telecom and Huawei Jointly Release 5G Super Uplink Innovation Solution — Telecoms.com](https://www.telecoms.com/5g-6g/china-telecom-and-huawei-jointly-release-5g-super-uplink-innovation-solution) — MWC19上海期间超级上行联合发布的第三方报道
3. [China Telecom, Huawei debut 5G-A uplink tech — RCR Wireless（2025-06-26）](https://www.rcrwireless.com/20250626/5g/china-telecom-huawei) — 5G-A阶段AI上行池化增强，面向车联网/可穿戴/AI助手
4. [USA January 2026 Mobile Network Experience Report — Opensignal](https://insights.opensignal.com/reports/2026/01/usa/mobile-network-experience) — 第三方众包实测口径：“上传通常慢于下载”
5. [TS 38.101-1: NR User Equipment radio transmission and reception — 3GPP Portal](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3283) — 终端功率等级规范（Power Class 3 = 23dBm）
6. [Evaluations of High Power User Equipment (HPUE) in Urban Environment — arXiv:2511.19871](https://arxiv.org/html/2511.19871v1) — 上行受限问题与HPUE高功率终端的学术评估

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
