LTE-U与Wi-Fi共存：5GHz免授权频段关键技术全解析-北京尧图网络

简介PPT课件围绕Wi-Fi与LTE融合展开面向通信工程、网络规划以及移动互联网相关学习者系统梳理两种技术的差异、融合必要性以及LTE-U、LAA等关键方案。内容详解LTE-U基本原理、5GHz未授权频段选择、CSAT载波感应自适应传输、不同运营商间频谱划分、小型基站场景部署以及LAA利用载波聚合实现授权与免授权频谱协同的激活/去激活流程并融入中国移动/联通/电信LTE频段分配等背景数据。压缩包内共一个文件为PowerPoint演示文稿整体大小约939KB内容按概述、频段选择、信道共享、接入方式与场景部署等模块组织结构清晰适合用于课程汇报、技术分享或自学入门。该资源已有182人学习浏览可作为理解非授权频谱利用、4G/5G融合演进路径的辅助材料帮助读者快速搭建知识框架并掌握LTE与Wi-Fi共存的实现思路。1. 为什么非要把 Wi-Fi 和 LTE 捏在一起80% 的移动流量其实都压在 Wi-Fi 上先说一个反直觉的事实你手机里绝大多数流量根本不是运营商基站扛下来的而是 Wi-Fi 扛下来的。业内统计里常说约 80% 的移动数据流量来自 Wi-Fi蜂窝网络只处理了大概 20%。所以“WiFi 与 LTE 融合”这个话题真正要解决的问题不是“用 LTE 取代 Wi-Fi”而是“既然用户都在 Wi-Fi 上能不能把 LTE 的高效调度能力也搬到免授权频段去”。运营商手里的授权频谱非常有限三大运营商 LTE 频谱资源加起来也就百来 MHz中国移动 130MHz、中国联通 90MHz、中国电信 100MHz这点宽度根本喂不饱视频和直播类流量。方案就是 LTE-U让 LTE 在 5GHz 免授权频段上工作同时不把 Wi-Fi 挤死。这篇笔记把选频段、信道共享、接入方式、HARQ/ICIC 这些关键技术和部署坑一次说清。2. LTE-U 的本质是去 5GHz “找地干活”频段选择与 CSAT 共享机制2.1 为什么偏偏是 5-6GHz而不是 2.4GHzLTE-U 第一个决策点是选哪个频段。这里直接可以排除 2.4GHz这个频段已经被 Wi-Fi、蓝牙、ZigBee 以及微波炉这类设备挤得非常满周边的干扰底噪常年很高再加上 2.4GHz 穿墙好、覆盖广任何新增系统进去都是给自己找麻烦。低于 6GHz 的频段整体上能较好地抵抗路径衰落适合做小基站覆盖这是 LTE-U 能用较低功率换取可用覆盖的基础。我比较看好的是 5-6GHz 区间尤其是靠近 6GHz 那段。5GHz 附近虽然被 WLAN 占用但具体到子频段占用情况并不一样。5.15-5.25GHz 是室内低功率频段5.25-5.35GHz 和 5.47-5.725GHz 涉及雷达避让很多国家强制走 DFS 动态频率选择真正相对“干净”又不用躲雷达的是 5.725-5.85GHz 这一带对应 Wi-Fi 的 149-165 信道。所以实际项目里做频段规划时我一般会优先看 5.725GHz 以上再往下才是那些需要做雷达检测的 DFS 信道。频段现状占用主要干扰源部署建议2.4GHz极高Wi-Fi、蓝牙、ZigBee、微波炉不推荐5.15-5.25GHz中Wi-Fi室内低功率可选功率受限5.25-5.725GHz中低Wi-Fi 雷达需 DFS慎选雷达到期要跳频5.725-5.85GHz低少量 Wi-Fi优先选择部署前建议先扫一遍现场信道占用Linux 环境下可以用 iw 工具快速看周围 AP 分布和信道占用# 扫描周围 Wi-Fi AP统计各信道占用数量 sudo iw dev wlan0 scan | grep -E freq:|SSID: | awk {print $2, $3}这段命令把扫描结果里每个 AP 的频率和 SSID 提出来频率能直接对应到信道号方便判断哪个 5GHz 子频段“空闲”。实际使用中我会反复扫三次以上因为 Wi-Fi 信道占用随时间波动很大不同时段同一位置的占用率可能差出一倍单次扫描只能算是摸底。2.2 CSATLTE 怎么做到“用一会儿、停一会儿”把信道让给 Wi-FiLTE-U 碰到的第一个大矛盾是LTE 在授权频段是连续传输的一个小区独占资源其他无线系统根本别想插进来但免授权频段是开放资源Wi-Fi 靠 CSMA/CA 机制公平竞争信道。如果 LTE-U 不做任何处理直接开跑Wi-Fi 的载波侦听会一直看到信道忙退避计时器永远走不完最后 Wi-Fi 吞吐直接崩塌。解决办法里最常被提到的就是 CSAT载波感应自适应传输。CSAT 的思路是把时间切成周期LTE-U 在 on 周期里正常传输在 off 周期里强制静默把信道让给 Wi-Fi。Wi-Fi 站点只要在静默窗口里发起传输就能逐步恢复接入。on/off 的占空比并不是定死的可以在 50% 附近动态调整如果检测到 Wi-Fi 流量大就把占空比调低给 Wi-Fi 更多时间反之则可以调高。这里要区分一个容易混的概念CSAT 和 LBT 不是一回事。LBT 是先听后说每次传输前都要做信道检测检测到忙就退避这更接近 Wi-Fi 的行为也是欧洲市场对免授权接入的强制要求CSAT 则是基于时间占空比的共享方式曾经主要用在北美这种允许“非 LBT”方式的市场。3GPP 后来在 R13 里定义的 LAA 方案实际走的是 LBT 路线。现在做方案选型时如果目标市场在欧盟基本可以直接跳过纯 CSAT 设计老老实实按 LBT 做。验证 CSAT 是否真正生效不能只看 LTE 侧吞吐要看 Wi-Fi 侧能不能恢复。常见做法是放两台 Wi-Fi 终端互打 iperf3 流同时把 LTE-U 基站开着对比开关前后的接收速率# 终端 A 上运行服务端 iperf3 -s -p 5201 # 终端 B 上运行客户端持续打流 60 秒并打印每 1 秒的吞吐 iperf3 -c 192.168.1.10 -p 5201 -t 60 -i 1接收速率能从个位数恢复到接近无干扰时的水平说明 CSAT/LBT 的静默窗口留得够如果还是被压住就要检查占空比配置是否给了 Wi-Fi 足够的传输窗口。这类问题在现场经常反复出现我一般会把抓包工具和 iperf3 同时挂上因为只看吞吐曲线很难区分“信道没让出来”和“终端功率太低”。3. 接入方式与系统架构LAA 是怎么把两段频谱“焊”在一起的3.1 三种主流候选方案横向对比把 LTE 搬上免授权频段不是简单地把基站发射功率调到免授权频段就行接入方式才是架构设计的关键。目前业界反复权衡的主要有三条路线授权辅助接入 LAA、双连接、免授权辅助接入。LAA 是最接近落地主流的一个它要求先有一个授权频段的小区作为主小区所有控制信令、切换、寻呼都走这个授权锚点免授权频段只作为辅助小区承载用户面数据。双连接则是让终端同时连着一个 LTE 宏站和一个 5GHz 小站两个站独立调度适合宏站回传能力充裕的场景。免授权辅助接入相对激进一些控制面也要尝试走免授权频段这在实际网络中几乎没人敢直接用因为免授权频段的干扰不可控控制信令丢了影响太大。方案授权频谱角色免授权频谱角色标准化成熟度终端要求LAA主小区承载全部控制面辅助小区只传数据高3GPP R13 已定义需支持载波聚合双连接宏站独立调度小站独立调度中高需支持双连接免授权辅助接入不用或弱依赖控制面用户面都走低研究阶段高基本不现实实际项目里我还没有见过谁在生产网络里用第三种方案。原因很简单免授权频段谁都能占控制信令时延抖动一上来掉线率会很难看。做方案评审时第一条就先把这种“控制面放免授权”的选项否掉这能省掉后面很多扯皮。3.2 LAA 与 CA授权频段当锚点免授权频段当辅助载波LAA 的技术核心是载波聚合。终端先通过授权频段上的主小区完成接入、鉴权、附着建立起 RRC 连接。之后基站根据业务量判断是否需要扩容如果需要就把免授权频段上的辅助小区激活把一部分下行数据流分流到免授权载波上。这里主小区始终承担着控制面终端可以随时上报测量结果基站决定何时激活或去激活辅助小区。这个架构带来的直接好处是移动性和业务连续性都有保障。用户从室外走进室内授权频段主小区一直连着即使 5GHz 辅助小区因为干扰恶化被去激活业务也只是回落到授权频谱上而不是彻底断掉。3GPP R13 定义的第一版 LAA 只支持下行后来才在增强版本里补了上行调度和反馈。辅助小区激活后调度关系是这样组织的参数主小区授权辅助小区免授权频段如 1.8GHz 或 2.1GHz5GHz 免授权频段控制面承载全部 RRC 信令不承载控制面数据面上下行均可以下行为主调度方式常驻调度按需激活需 LBT比较关键的一个工程约束是回传质量。载波聚合要求主小区和辅助小区之间回传时延足够低理想情况下是同站共址或光纤直达回传时延要控制在几百微秒级别。如果两组小区之间隔着普通的 IP 回传网时延到十几毫秒CA 的调度同步就会出问题这时候宁可采用双连接方案让两个小区各自独立调度也不要硬把它们绑成 CA。3.3 共建架构与非共建架构被忽视的建站成本差异LTE-U 在室外部署场景上有一个经常被低估的决策点基站是跟 LTE 共用还是单独新建。共建架构可以理解成把 LTE-U 功能直接做进现有 LTE 基站共用站址、回传、供电和天线系统这样架构成本和运营成本都最低也最容易保持 CA 所需的低时延回传。非共建架构则是在 LTE 宏小区覆盖下再单独布一批支持 5GHz 的微小区基站灵活性更高想往哪个热点区域补容量就往哪放但传输、供电、站址租金都是额外开销。实际规划时我会按场景来选城区已有的 LTE 站址资源充足优先做共建把新增 5GHz 载波塞进现有基站而像商场、体育场馆这种容量需求明确的室内热点用独立的小基站更合适因为它可以贴着用户部署覆盖和容量都更可控。需要提醒的是无论哪种架构都要在规划设计阶段就把 5GHz 频段的合规功率和雷达避让要求考虑进去否则等到设备上站再改频段返工成本非常高。4. 把 LTE 的看家本领搬到免授权频段集中调度、ICIC、HARQ 与时频划分4.1 集中调度为什么 LTE-U 的抗干扰比 Wi-Fi 更“讲理”LTE 在授权频段能够稳定工作的一个重要原因是集中调度。基站侧统一掌握所有终端的信道质量、缓存状态和 QoS 需求在每个调度周期里集中决策给谁分配资源块、分配多少、用什么调制编码方式。所有终端不需要像 Wi-Fi 那样去抢信道只要按基站下发的调度授权发送数据就行。这套机制搬到 LTE-U 上之后5GHz 频段上的传输也保持了同样的确定性同一个 LTE-U 小区内的用户之间不会互相撞车。这一点对理解 LTE-U 的价值很重要。在 Wi-Fi 网络里终端各自靠 CSMA/CA 抢信道用户一多碰撞重传比例急剧上升吞吐掉得很快而 LTE 的集中调度可以把同小区用户安排在不同的资源块上同时传输所以即使频段还是那个频段调度效率比 Wi-Fi 的分布式竞争机制高出不少。4.2 ICIC小区边缘的“抢频段”问题不能靠加大功率硬扛集中调度解决了小区内部的问题但解决不了小区之间的问题。LTE-U 小基站密度高小区边缘用户会同时收到多个基站的信号如果两个相邻基站给边缘用户分配了相同的物理资源块就会互相干扰。ICIC也就是小区间干扰协调在这里起到的作用是让相邻基站错开边缘频带。最常配合使用的是软频率复用或分数频率复用。简单说就是小区中心的用户可以随便用全部频带但小区边缘的用户被限制在各自的边缘频带内相邻小区的边缘频带彼此错开。加上 ICIC 之后频谱效率会有一定折损毕竟每个小区不能同时用全部资源了但换来的是边缘用户信噪比的稳定提升。在免授权频段上做 LTE-U 部署时ICIC 反而比在授权频段更重要因为 5GHz 频段里可能还有 Wi-Fi 和其他运营商 LTE-U 也在工作干扰源更多不能只盯着同运营商的邻区。4.3 HARQ比 Wi-Fi 重传更高效的自适应请求重传LTE 的物理层还有一个 Wi-Fi 不具备的兜底机制HARQ混合自动重传请求。终端收到数据后先做 CRC 校验如果失败就把这份数据的“软信息”先缓存下来然后反馈 NACK。基站收到 NACK 后重传终端把重传数据与缓存的软信息做合并解码只要合并后的信息足够就能译出来。这个机制和 Wi-Fi 的 MAC 层重传最大的区别在于Wi-Fi 重传时之前收的数据包直接被丢弃了重传的每一份数据都是独立译码而 HARQ 的重传会和旧数据合并相当于每次重传都在为最终译码增加信息量。在免授权频段这种干扰波动大的环境里HARQ 的这个特性让 LTE-U 的数据面明显更稳。实际调优时主要看重传次数和 BLER 目标值一般初始 MCS 选择会让 BLER 控制在 10% 附近低于这个值说明调制编码方式太保守白白浪费了 5GHz 频段的高信噪比优势。4.4 运营商之间怎么共享免授权频谱时间划分还是时频联合划分免授权频谱是开放资源同区域里可能同时存在着多家运营商部署的 LTE-U 系统甚至还有 Wi-Fi 热点。运营商之间也要讲共存策略常见做法分两类。第一类是直接把免授权频段按时间做永久划分比如运营商 A 用周一到周三运营商 B 用周四到周日。这种划分方式实现最简单谁也不会踩到谁的重叠窗口但问题是频谱利用率太低A 的用户半夜没人用频段也是闲置的B 那边高峰期再堵也借不过来。第二类是时间和频段联合划分把免授权频谱按时间和资源块切成二维棋盘根据各家运营商的实时业务负荷动态调整分配。这个方法复杂度明显高需要运营商之间有协调接口和实时交换负荷信息但换来的是高得多的频谱利用率综合来看更适合做 LTE-U 的城市连续覆盖。我个人的倾向是先期试点可以接受时间划分等到多运营商同时部署 LTE-U 成为常态再考虑联合划分否则一次性上一个高复杂度协调系统运维压力会非常大。提示所谓“公平使用免授权频谱”在大多数国家和地区是合规底线不是可选项。任何部署方案在评审时都要先过一遍当地对免授权频段占空比、功率和雷达避让的要求。5. LTE-U 共存实战避坑五个常见翻车现场与处置方法5.1 部署 LTE-U 后周边 Wi-Fi 吞吐直接崩塌现象在某园区部署 LTE-U 小站后周边 Wi-Fi 终端的实测速率从 200Mbps 以上掉到不足 20Mbps用户投诉视频会议频繁卡顿。原因这是最典型的“连续传输问题”。LTE-U 基站没有启用 CSAT 或 LBT以接近 100% 的占空比持续占用 5GHz 信道。Wi-Fi 的 CSMA/CA 机制一检测到信道忙所有终端都进入退避状态LTE-U 又没有主动让出静默窗口Wi-Fi 就是“饿死”的状态理论上再调整 Wi-Fi AP 功率也没用。解决把 CSAT 或 LBT 打开配置合理的占空比。建议从 50% 占空比起步on/off 周期长度设置在几十毫秒量级观察 Wi-Fi 吞吐恢复情况再微调如果场景内有语音视频这类实时业务适当缩短周期长度让静默窗口出现得更频繁把 Wi-Fi 的接入时延压下来。5.2 5GHz 信道被雷达检测触发强制跳频现象LTE-U 链路在某个时段突然中断排查基站日志发现信道状态变成“radar detected”系统被迫跳频到另一个信道业务中断几十秒。原因5.25-5.35GHz 和 5.47-5.725GHz 频段与天气雷达、军用雷达共用设备必须支持 DFS。雷达信号只要被检测到信道会在很短时间内被标记为不可用设备必须清空该信道并迁移。有些部署为了找干净频段故意选在 DFS 频段这等于给自己埋雷。解决前期频段规划直接优先选 5.725GHz 以上的非 DFS 信道比如 149、153、157、161、165 这些。如果确实只有 DFS 频段可用必须把雷达检测阈值调到正确档位并接受不可避免的跳频中断在设计上保证跳频后业务能快速恢复。5.3 拿普通 Wi-Fi AP 当 LTE-U 基站做共存测试现象测试团队用普通支持 5GHz 的 Wi-Fi AP 模拟 LTE-U 基站在测试报告里写“CSAT 参数配置无效”结论认为 LTE-U 与 Wi-Fi 无法共存。原因普通 Wi-Fi AP 完全不具备 LTE 的集中调度、HARQ 和 CSAT/LBT 能力它的发射行为本质还是 Wi-Fi当然不会体现 LTE-U 的共存特性。用错误的设备去验证一个协议特性得出的结论天然就是错的。解决共存测试必须使用支持 LTE-U/LAA 的专用小基站设备或用 USRP 加 OpenAirInterface 这类软件无线电平台搭建一个可控的 LTE-U 发射节点。测试前还要确认设备固件里 CSAT/LBT 开关真实生效而不是只停留在配置界面。5.4 终端连上了 LTE-U 却始终用不上免授权载波现象终端显示 LTE 已连接但看吞吐只有授权频段的水平5GHz 辅助小区没有激活数据面没有分流到免授权频段。原因LTE-U/LAA 依赖载波聚合能力终端必须支持相关 Release 版本且对应频段组合可用。部分终端为了通过某些市场合规认证会默认禁用 5GHz 免授权频段组合另一些老终端只支持 R12 以下的 CA根本不识别 LAA 辅助小区。解决测试前先确认终端的 CA 能力表和固件版本选定明确支持 LAA/授权辅助接入的型号在基站侧打开对应频段组合的 CA 配置并检查终端是否上报了 5GHz 频段的测量结果。最稳妥的办法是准备一台已知支持该功能的参考终端用于区分“基站问题”和“终端问题”。5.5 平均吞吐合格但 Wi-Fi 时延抖动剧烈现象共存测试的 10 分钟平均吞吐数据看起来很漂亮但 Wi-Fi 侧的实际体验极差游戏和视频通话频繁出现卡顿时延抖动非常大。原因平均吞吐掩盖了短时行为。LTE-U 的 CSAT 周期设置过长静默窗口出现频率太低Wi-Fi 终端虽然最终拿到了传输机会但每次都要等待一个接近秒级的静默窗口导致时延波动远大于正常 Wi-Fi 环境。解决在验证阶段就要同时统计时延、时延抖动和吞吐三个维度不能只看平均值。把 CSAT 周期从秒级调低到几十毫秒级并记录 P95 时延作为验收指标。此后我每次做共存测试都会把“平均吞吐、P95 时延、最差 1 秒吞吐”三组数据同时打出来缺一不可。6. 落地验证一套能直接抄的 Wi-Fi 与 LTE-U 共存测试流程真正判断一个 LTE-U 部署是否合格不能只看 LTE 侧速率要用一套可复现的流程把 Wi-Fi 侧的命运也量化出来。我常用的流程是四步先测基线再插干扰然后看指标最后调参数。第一步测基线。在 LTE-U 基站关断的状态下用 iperf3 打满 Wi-Fi 链路记录稳定吞吐、平均时延和 P95 时延。第二步插干扰。打开 LTE-U 基站用与真实部署一致的 CSAT/LBT 配置持续发射。第三步看指标。重复测 Wi-Fi 吞吐和时延重点对比吞吐损失比例和时延抖动变化。第四步调参数。不断减小 LTE-U 占空比每调整一次重复测一轮画出一条“Wi-Fi 吞吐损失 vs LTE-U 占空比”的曲线根据曲线确定最终的占空比取值。基线持续打流时可以配合抓包确认空口行为确实符合配置避免黑匣子式的“装了就当有效”# 抓取指定 AP 信道上的 5GHz 环境流量生成 pcap 供后续分析 sudo tcpdump -i wlan0 -f wlan type data -w /tmp/lteu_coexist.pcap -G 30 -W 10这段命令每 30 秒轮转一个抓包文件共保存 10 个文件总时长覆盖约 5 分钟足够包含多个 CSAT 周期。分析时重点看 Wi-Fi 数据帧之间的时间间隔如果在 LTE-U 发射期间仍然能观察到规律性的 Wi-Fi 帧突发说明静默窗口确实被 Wi-Fi 利用上了。验收标准方面我的习惯是取三个指标同时通过Wi-Fi 平均吞吐损失不超过 30%P95 时延不超过无干扰时的 2 倍且短时吞吐低于 10Mbps 的时间占比不超过 5%。这套门槛不算严苛但能拦住绝大多数“平均数据好看、实际体验崩盘”的问题。最后一轮测试时把所有参数和实测结果留档方便后续扩容时做对比。这套流程我走完一遍大概需要半天从那以后我每次做免授权频段共存测试都强制先跑基线再谈参数调整少跑一步就难免被平均数据骗一次。希望帮到你。本文还有配套的精品资源点击获取

LTE-U与Wi-Fi共存：5GHz免授权频段关键技术全解析

相关推荐

Linux进程管理与计划任务实战：从僵尸进程到systemd timer

Oracle数据库课程设计全流程：搭建、SQL到答辩避坑

拆解连锁咖啡看多研报：单店模型与扩张预测的验证方法

更多资讯

涉密项目投标前需要准备什么材料？

企业终端软件安装管控：堵住私自安装带来的内网安全缺口

lil-agents 多屏适配实战：Dock 自动隐藏时角色为何不消失？DockVisibility 深度解析

Amical听写历史与智能笔记完整指南：如何搜索、内联编辑并复用你的语音内容

HarmonyOS 7 Node.js：多语言占位符漂移发布前阻断【鸿蒙心迹】

华为IPD流程管理实战：六大阶段、DCP评审与落地避坑指南

今日更新

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？