LWA/LWIP/LAA：WiFi与LTE融合组网、配置与排错实践

简介：关于WiFi与LTE融合的技术讲解PPT，面向通信相关专业学习者与无线网络从业者。内容从两种技术特性对比切入，分析融合必要性与频谱资源限制，引入“约80%移动数据流量由Wi-Fi承载”等数据，并重点展开LTE-U的频段选择、CSAT信道共享、LAA授权辅助接入等关键机制，同时梳理了我国三大运营商LTE频段分配、室内外场景部署差异及授权辅助接入与双连接等候选方案对比，帮助读者系统理解未授权频谱的高效利用。包内为1个PPT文件，压缩包仅939KB，适合用作课程教案、技术分享或自学参考，可配合演示文稿逐步讲解。已有182人学习下载，对关注LTE-U、LAA及5G融合演进方向的读者具有直接参考价值。

1. WiFi与LTE融合：不是热点桥接，是协议栈上的双链路合流

WiFi与LTE融合这六个字，在网络工程师手里指的不是把手机同时开两个热点，也不是一台网关把LTE转成WiFi给办公室上网。3GPP从R13开始把这两件事做成协议栈上的合流：同一份用户面数据，由LTE基站做主，按策略拆成两条流，分别走LTE空口和WiFi空口，在接收端的PDCP层再拼回去。常见的落地形态是LWA、LWIP，以及共享5GHz非授权频谱的LAA。这套技术对室内容量卸载、工业网关、车载多接入最有价值：能用现成WiFi基础设施给LTE提速，而不是二选一。适合做运营商无线、核心网、园区网络和企业AP集成的工程师。后面所有配置和排查，我按实验室可复现的步骤写。

2. 三条主流融合路线怎么选：LWA、LWIP、LAA的代价边界

很多刚接触这个方向的工程师，第一反应是盯着“WiFi”两个字母找方案，结果把LWA和LAA当成一回事。其实这两类路线的控制面完全不同：LWA是让WiFi AP进入LTE的调度体系，LAA是让LTE跑到WiFi用的5GHz频段里。先把这个边界分清，后面配置才不会走错路。

2.1 LWA：基站做主的承载级聚合，Xw接口把AP变成“外置射频”

LWA的全称是LTE-WLAN Aggregation。核心做法是在eNB旁边加一个WLAN Termination，简称WT。WT可以落在企业AP、AC或者一台独立网关上，eNB和WT之间拉一条Xw接口，控制面用SCTP，用户面用GTP-U。

用户面数据进到eNB之后，由eNB的PDCP层决定哪部分直接走LTE空口、哪部分通过Xw-U交给WT，再由WT转换成802.11帧从WiFi空口发出去。手机侧同时收两条链路，在PDCP层做重排和合并。这个方案里LTE基站是绝对主脑，WiFi AP只负责执行转发，不参与切换决策，也不感知核心网。

LWA的优势是调度粒度细，可以按DRB甚至按PDCP SDU拆分。WiFi信号好就多放一点流量过去，WiFi信号变差就收回来。代价是WiFi AP必须支持Xw协议栈，普通家用AP和很多轻量AP都不行，企业AP还要看固件版本。另外终端必须支持LWA并发收发，不是随便拿一台手机就能跑出聚合增益。

2.2 LWIP：控制面不改、用户面加封装的松耦合路线

LWA对AP的要求劝退了不少项目，于是有了LWIP。LWIP的全称是LTE-WLAN Radio Level Integration with IPsec Tunnel。它仍然由eNB通过空口控制终端，但用户面从eNB出来之后，用IPsec链路送到WLAN侧，再由普通WiFi AP转发。AP不需要理解Xw，不需要LWA相关信令，省掉了WiFi侧的协议栈改造。

LWIP的代价也很直接：多一层封装，时延比LWA高，QoS映射粒度粗，很难做到承载级的精细拆分。它适合那种“WiFi网络已经建好、不想大改AP”的园区场景。如果你手里有现成的AC和AP，又不想做软件升级，LWIP是低成本验证融合思路的入口。但如果目标是长期承载视频和实时业务，我更推荐直接上LWA。

2.3 LAA/LTE-U：没有WiFi AP参与，也要和WiFi抢5GHz空口

LAA和前面两条路线有本质区别。LAA里根本没有WiFi AP参与，它是LTE载波聚合的扩展：主小区在授权频段，辅小区放在5GHz非授权频段。手机的主小区负责控制面和移动性，辅小区只负责容量提升。WiFi在这种场景里是“共用频段的邻居”，不是融合对象。

LAA能落地，关键在于和WiFi的共存机制。欧洲和很多地区要求LAA必须做LBT，也就是先听后说。LAA设备发数据前先侦听信道，信道忙就退避，避免把WiFi信号压死。早期LTE-U不做LBT，只在某些允许固定关断时隙的地区短暂存在过，现在新项目基本不用。如果你在实验室测LAA，旁边最好真的放一台WiFi AP打流量，专门观察LBT参数是否正常工作。

2.4 选型判断表

选型时先问三个问题：控制面能不能动？AP能不能升级？终端能不能换？三个都能，无脑选LWA。AP不能动，选LWIP。控制面不能动但基站侧可以开载波聚合，选LAA。这三个问题顺序反过来也能用，先看终端，再看AP，最后看基站。

3. 落地从RAN侧开始：LWA的Xw口与承载分流参数

LWA的配置不像网上教程写的“打开开关”就完事。一个可以复现的LWA实验环境，至少要同时配通eNB、WT、终端三侧。下面这套步骤，我按实验室常用设备的操作顺序写，字段名以你设备实际手册为准。

3.1 实验组网：需要哪些网元、哪些接口

LWA实验环境最基本的网元有四个：支持LWA的eNB、WT、AP、测试终端。WT可以独立成一台服务器，也可以和AC合设，但实验时我建议独立部署，方便抓Xw口包。

接口规划表：

组网时要把Xw-U单独划一个VLAN，不要和终端业务VLAN混在一起。这样抓包看GTP-U流量时，不会淹死在广播流量里。IP地址建议用一个独立网段，例如10.20.1.0/24，eNB侧一个地址，WT侧两个地址，分别对应Xw-C和Xw-U。

3.2 Xw口建立与LWA策略的关键参数

WT上先要有一个全局唯一的WT-ID，并把自己能管理的AP列表注册进去。eNB侧再把WT地址配上。常见设备上的简化配置长这样：

lwa-policy wt-id 100 xw-c-ip 10.20.1.2 xw-u-ip 10.20.1.3 lwa-rssi-threshold -75 lwa-split-threshold 256

这段配置不是完整设备命令，但字段逻辑是通用的。wt-id用来标识WT，多个WT共存时必须唯一。xw-c-ip和xw-u-ip分别是控制面和用户面地址，我这里故意把两个地址分开，避免控制面拥塞拖慢用户面。

lwa-rssi-threshold是LWA激活的WiFi信号门限。手机测到WiFi RSSI高于这个值，eNB才允许拆分承载。设成-75dBm，意味着WiFi信号得比-75好才走聚合；信号差就不拆。实验室里如果手机离AP远，这个值要往下调，但不要低于-85，否则WiFi链路质量差，聚合出来比单LTE还慢。

lwa-split-threshold表示触发拆分的最小数据量阈值。业务量低于这个值，eNB全部走LTE，不浪费信令。256对应的是中低速率业务，跑到高清视频或大文件下载时才会真正触发split。

配置完成后，eNB和WT之间会建Xw-C链路。用抓包能看到SCTP握手的INIT/INIT-ACK，之后会有WT Association消息。如果没有这些消息，先查IP路由和防火墙，不要急着调无线参数。

3.3 把DRB挂上LWA：一次UE上下文修改的配置

全局LWA策略开了，不代表每个用户都走LWA。还得在UE上下文里，把某个DRB标记为允许LWA。这个环节是现网最容易被漏掉的。

drb { drb-id 3 lwa-allowed true pdcp-config { reordering-timer ms200 lwa-split-threshold 256 } }

这里的关键是drb-id 3对应的QoS承载被标记成lwa-allowed true。reordering-timer ms200告诉接收端PDCP层，最多等200ms的乱序包。WiFi空口很容易出现突发重传，timer太短会把还在路上的包当成丢包，造成业务卡顿；太长又会增加端到端时延。测试语音或交互类业务时，建议先200ms，再逐步往100ms压。

这个配置下发时，终端会上报自身的LWA能力。如果终端没有LWA能力，这条消息会被拒绝。看信令时不要只看eNB是否下发，还要看UE回没回LWA相关的RRC重配置完成消息。UE不回，后面所有聚合都是假的。

3.4 LAA补容量：LBT、CCA门限、最大功率三件套

如果选择了LAA路线，无线参数完全在LTE侧，不用碰WiFi配置。但调试重点从WiFi门限转移到LBT共存参数上。

LAA调试最怕只调能量检测门限。门限调高，LAA更容易抢占信道，但旁边的WiFi空口可能被压死。门限调低，LAA很礼貌，但汇聚吞吐可能达不到预期。正确做法是先固定最大发射功率，再用WiFi AP单向打流，从-65dBm开始逐步调门限，每次看WiFi测速和LTE下行吞吐两组数。两边都掉，门限方向就错了。

4. 终端与业务侧验证：吞吐、分流比、回退怎么测

网络侧参数全配好，只算完成一半。LWA到底有没有生效，必须看终端和业务侧跑出来的数据。这一章用一套可以复现的测试方法，帮你判断聚合是真的还是“看起来开了”。

4.1 先做三条基线：LTE-only、WiFi-only、LTE+WiFi

测聚合之前，一定要先打基线。没有基线，你根本说不清吞吐提升是聚合带来的，还是测试终端本身能力强。

接收端先起一台服务器：

iperf3 -s -i 5

然后分别在三种状态下打流。第一种，断开WiFi，只留LTE空口：

iperf3 -c 192.168.10.2 -u -b 300M -t 120

第二种，断开LTE，只走WiFi：

iperf3 -c 192.168.10.2 -u -b 300M -t 120

第三种，两条链路都在，业务目标调高到600M：

iperf3 -c 192.168.10.2 -u -b 600M -t 120

这里用UDP而不是TCP，是有原因的。TCP会被乱序重传拉低吞吐，万一split bearer的PDCP重排没调好，TCP测出来跟单LTE区别不大，容易误判。先用UDP确认物理链路能并发，再用TCP测业务实际体验。

如果第三条的UDP吞吐明显高于前两条，LWA生效。如果第三条和前两条差不多，别急着怀疑AP，先看4.2的分流比。

4.2 看分流比：Per-AP计数器和Xw抓包核对

吞吐高了，还要确认流量是真的从WiFi走了，而不是LTE独自扛下所有。最直接的办法是看AP侧每个终端的计数。

在WT或企业AC上，通常会有一个Per-AP或Per-UE的统计页，里面有WiFi侧的下行字节数。拿这个字节数除以总PDCP下行字节数，就是下行分流比。信号好的办公室里，这个值做到60%以上很正常；如果一直是0%，说明DRB没挂LWA。

更可靠的办法是抓Xw-U的包：

tcpdump -i any udp port 2152 -s 96 -w /tmp/lwa_xwu.pcap

2152是GTP-U的标准端口。抓完看报文数量：如果Xw-U上有持续的GTP-U下行包，说明eNB确实往WT转了数据。再用Wireshark查看PDCP-PDU长度分布，能和LTE侧RLC字节数做粗略核对。这个方法也能排查“AP计数不准”的情况，毕竟不少AP的统计字段在不同的固件版本里含义都有偏差。

4.3 切换与回退用例：信号变差、WiFi断开、恢复

LWA的验证不止有吞吐，还有移动性。测试时至少跑三个回退用例。

第一个用例是UE从LTE-only进入WiFi覆盖区。打开WiFi，RSSI抬高到门限以上，观察信令里是否下发LWA配置，APP连接是否保持不掉。第二个用例是带着手机往AP远处走，让RSSI降到门限以下。此时应该看到LWA去激活，PDCP回落到LTE单发，业务不中断。第三个用例最狠：直接把AP断电。这时Xw链路会断，eNB必须通过WT释放流程把承载收回来，而不是等终端侧WiFi断开才反应。

每跑一个用例，都在eNB侧抓一次信令，确认UE确实收到了对应的重配置消息。不要只看无线侧日志，要同时看终端log。很多现场问题就是eNB发了，手机没收到，或者手机收了但流程不完整。

4.4 数据记录模板

最后加一列“信令确认”，记录这条用例里UE有没有回RRC重配置完成消息。有了这张表，测试报告可以直接复用，不需要临时编数据。

5. WiFi与LTE融合的避坑/常见问题：五条踩坑记录

这个方向的翻车点非常集中。下面五条是我在实验室和现网排查中反复遇到的，每一条都按现象、原因、解决三段写。

5.1 Xw口建了，RRC也配了，但AP侧就是没数据

现象：Xw-C正常建立，终端上报也正常，但AP的计数器一直是零。

原因：通常是终端上报的WiFi RSSI没有到门限，或者终端WiFi模块进入省电模式，测量周期被拉长，上报值明显低于实际信号。

解决：先在终端侧读实测RSSI，再对比eNB收到的报告值，确认差值在5dB以内。同时把终端WiFi模块的省电策略关掉，让WiFi保持在常连状态。实验室里建议固定一台支持LWA的测试终端做基线，不要频繁换手机排查。

5.2 LAA一开，旁边WiFi AP的吞吐从400M掉到几十M

现象：LAA开启后，LTE吞吐上去了，WiFi AP成了受害者，测速惨不忍睹。

原因：能量检测门限设得偏高，LAA发射功率又打得足，WiFi在做CCA时听到信道忙，只能一直退避。

解决：把能量检测门限往-62dBm以下调，同时限制每个20MHz信道的最大发射功率。测试时用两台WiFi AP在现场打流，一台放在LAA发射点近处，一台放在远处，观察功率控制是否合理。不要只看一个位置的数据就下结论。

5.3 TCP下载忽快忽慢，重传率升高，UDP却正常

现象：UDP聚合吞吐很漂亮，一换TCP业务就卡顿，重传率明显上升。

原因：split bearer走到WiFi侧的PDCP PDU，会因为WiFi空口重传发生乱序。PDCP的reordering timer太短，部分包还没等到就被判定为丢包。

解决：把reordering timer从100ms调到200ms，再跑一轮TCP。如果仍有重传，看AP的缓存是否已满。对于低时延交互业务，给这个承载单独关掉split，让它走LTE单发，不要为了聚合牺牲体验。

5.4 WiFi断开后业务卡了十几秒，最后只能重建承载

现象：AP断电或终端远离后，应用没有快速切换回LTE，而是等承载重建才恢复。

原因：LWA去激活时，Xw-U上还在传下行包，WT缓存没排空，eNB就释放了WT上下文。终端侧PDCP重排时等不到后面的包，只能触发承载级恢复。

解决：严格按Xw-C的WT释放流程走，先让WT停止转发，确认缓存计数归零，再释放DRB。抓Xw-U的包能看到停止前的GTP-U序列号，等序列号不再增长再放行承载释放，就能避开这个问题。

5.5 几台终端同时测，只有一台有聚合增益

现象：同一套LWA网络，终端A吞吐明显翻倍，终端B和终端C完全没变化。

原因：不是所有手机都开放LWA能力。有些芯片支持，但系统默认屏蔽；有些是双WiFi天线没有并发能力，导致LTE和WiFi不能同时收发。

解决：查UE capability里和LWA相关的信令位。设备手册里通常叫lwa能力或“LWA enabled”。测试前把不支持LWA的机型剔掉，单独准备一两个经过验证的测试终端做回归。这一步能省掉很多无谓的网络侧排查时间。

6. 进阶：把融合能力迁到5G-A和MulteFire：下一步怎么投入

LWA和LAA解决的是4G时代的无线接入侧融合。现在新项目如果还从零搭LWA，要先想清楚网络制式会不会很快切到5G。5G核心网里的ATSSS，也就是多接入流量调度，思路和LWA高度一致：终端同时接入3GPP和WiFi两条路径，由网络侧策略决定每条业务走哪条路。

LWA的经验可以直接迁移到ATSSS上。ATSSS里控制面下沉到SMF和UPF，数据面不再依赖Xw接口，而是用多接入PDU会话把流量按策略拆分、切换和回退。策略粒度从承载级变成应用级，比如视频走WiFi、IM走LTE、Web流量按负载均衡发到两条链路。迁移时先做的不是配策略，而是把LWA时代的RSSI门限、回退优先级、业务保序时长这些经验整理成一张策略清单。WiFi的RSSI阈值、切换迟滞、重排容忍度，这些结论在5G-A里依然适用。

另一个方向是MulteFire。它把LTE技术独立跑在非授权频谱上，没有授权锚点小区，更像一个自成一体的“LTE over 5GHz”系统。对企业园区和工业网关来说，它的意义在于不依赖运营商牌照就能用LTE调度、QoS和安全机制。但MulteFire的终端生态比LWA还少，验证前要确认测试终端支持，否则又是空忙一场。

我个人现在的习惯是：新项目先写清“哪条链路做主、哪条链路兜底、业务能容忍多少毫秒乱序”，再动手配任何参数。LWA时代踩过的RSSI门限和PDCP重排的坑，在ATSSS一个都不会少，换了名字照样翻车。先花半天把基线打扎实，比后面熬夜排查更有用。希望帮到你。

本文还有配套的精品资源，点击获取