蓝牙PAN协议——不用WiFi，蓝牙也能上网？
最近刷YouTube的时候看到一个东西：蓝牙PAN。感觉挺有意思的，跟大家分享一下——嵌入式设备没有WiFi模块（或者WiFi挂了），但有经典蓝牙，能不能借手机的网络上网？PAN就是干这个的。整个链路大概是这样的：蓝牙配对 → SDP发现NAP服务 → BNEP连接 → DHCP拿IP → 正常跑TCP/IP。做个记录分析一下。 |
一、PAN是什么——蓝牙版的"网络共享"
PAN全称Personal Area Networking Profile，是 经典蓝牙（BR/EDR） 的一个Profile。核心能力就一句话：通过蓝牙链路传输以太网帧，让蓝牙设备像接了网线一样上网。
日常最常见的场景：手机开蓝牙网络共享，平板/手表/嵌入式设备连上去就能上网。跟WiFi热点比，PAN功耗更低、不占WiFi通道，但带宽也低——经典蓝牙EDR理论3Mbps，实际1~2Mbps（受环境干扰波动大，WiFi共存时可能只有700Kbps）。发个HTTP请求、跑个MQTT够用，传大文件就别想了。
和前面搞过的WiFi+Socket那套路完全不同：WiFi走的是802.11无线局域网，PAN走的是蓝牙射频。但上了IP层之后，TCP/UDP/HTTP该怎么跑还怎么跑——对应用层来说是透明的。
二、三个角色——谁提供网，谁用网
PAN里定义了三个角色：
角色 | 全称 | 干什么 | 典型设备 |
PANU | PAN User | 上网的一方（客户端） | 嵌入式设备、平板 |
NAP | Network Access Point | 提供网络接入（像路由器） | 手机、笔记本 |
GN | Group Ad-hoc Network | 自组网，设备之间互连 | 临时会议、传感器组网 |
几个关键区别：
NAP能接外网，GN不能——GN只管自己组里的设备互相通信，不提供互联网
NAP和GN都能转发包，PANU不转发
NAP和GN不能互连——一个设备要么做NAP要么做GN，不能同时是两者
嵌入式设备99%的场景是做PANU——连上手机（NAP），借手机的4G/5G/WiFi上网。
三、协议栈——BNEP是关键的"桥"
PAN的协议栈长这样：
Plain Text// PAN协议栈层级应用层（HTTP / MQTT / TCP / UDP） ↓IP层 ↓BNEP（蓝牙网络封装协议） ← 核心就在这一层 ↓L2CAP（PSM = 0x000F） ↓Baseband（蓝牙射频） |
BNEP（Bluetooth Network Encapsulation Protocol）是PAN的核心。它干的事说白了就是：把以太网帧的头扒掉，换上BNEP自己的头，然后塞进L2CAP通道传出去。 对面收到后再把BNEP头扒掉，还原成以太网帧丢给IP层处理。
对比旧方案
在PAN之前，蓝牙设备上网走的是PPP over RFCOMM——IP层到L2CAP之间得经过PPP和RFCOMM两层协议。BNEP直接桥接IP层到L2CAP，省掉了PPP和RFCOMM两层开销，效率高不少。
Plain Text// 旧方案 vs PAN旧：IP → PPP → RFCOMM → L2CAP → Baseband （四层）新：IP → BNEP → L2CAP → Baseband （三层） |
BNEP的五种包类型
类型 | 携带的地址 | 适合场景 |
GENERAL_ETHERNET | 自身MAC + 对端MAC | 多连接场景，通用 |
COMPRESSED_ETHERNET | 不带地址 | 一对一，PANU↔PANU |
COMPRESSED_DEST_ONLY | 只带对端MAC | 一对多，省自身地址 |
COMPRESSED_SOURCE_ONLY | 只带自身MAC | 一对多，省对端地址 |
CONTROL | — | 控制命令（连接/过滤器） |
一对一连接的时候用COMPRESSED模式可以省掉地址字段，包更小。BNEP的MTU最小得1691字节，L2CAP配置阶段如果给的MTU比这小，通道直接建不起来。
四、连接流程——从配对到上网
整个PAN从蓝牙配对到能上网，走了六步：
一步步拆开看：
ACL连接——标准蓝牙配对，建立底层链路
SDP服务发现——PANU去查NAP有没有PAN服务。关键信息包括：Service Class ID（标识是NAP还是GN）、BNEP版本（v1.0）、支持的以太网类型（IPv4 0x0800、ARP 0x0806）、PSM = 0x000F
L2CAP通道——基于PSM 0x000F建L2CAP连接，MTU得 ≥ 1691
BNEP Setup——PANU发 SETUP_CONNECTION_REQUEST，NAP回 SETUP_CONNECTION_RESPONSE（响应码0x0000表示成功）。到这一步BNEP通道就通了
DHCP——走标准DHCP四步（DISCOVER → OFFER → REQUEST → ACK），NAP给PANU分配IP地址
ARP——MAC地址和IP地址互相绑定，之后就可以直接用IP地址通信了
DHCP和ARP跑完，PANU就有了自己的IP地址。后面该怎么发HTTP、怎么跑MQTT，跟WiFi环境下一模一样——应用层完全感知不到底下走的是蓝牙。
五、数据收发——以太网帧怎么走蓝牙
数据走PAN的路径：
Plain Text// 发送路径（PANU → NAP → 互联网）应用数据 ↓ TCP/IP栈以太网帧（Dest MAC + Src MAC + Type + Payload） ↓ BNEP层BNEP帧（扒掉以太网头，加BNEP头） ↓ L2CAPL2CAP分包 ↓ Baseband蓝牙射频发出 |
接收就反过来：蓝牙射频收到 → L2CAP重组 → BNEP解析还原成以太网帧 → 丢给IP层。
BNEP帧格式
Plain Text// BNEP帧结构┌──────────┬──────────────┬──────────────┬──────────────┬──────────┐│ BNEP Type│ Dest Addr │ Src Addr │ Protocol Type│ Payload ││ (1 byte) │ (6B, 可选) │ (6B, 可选) │ (2 bytes) │ (变长) │└──────────┴──────────────┴──────────────┴──────────────┴──────────┘ |
BNEP Type决定了后面有没有地址字段。GENERAL_ETHERNET带全部地址，COMPRESSED模式省掉一个或两个。Protocol Type标识上层是IPv4（0x0800）还是ARP（0x0806）还是IPv6（0x86DD）。
六、嵌入式视角——MCU上怎么跑PAN
TCP/IP栈的选择
MCU上跑PAN，蓝牙协议栈管到BNEP这一层，但BNEP上面的IP/TCP/UDP得有个TCP/IP栈来处理。两个常见选项：
TCP/IP栈 | RAM占用 | 适合 |
uIP | ~几KB | 极度内存受限、低带宽场景 |
lwIP | ~几十KB | 有RTOS、功能更全 |
uIP比lwIP更轻量，适合资源紧张的场景。泰凌的BT SDK就是用uIP跑PAN的。
虚拟网卡——用环形队列模拟
PAN走的是蓝牙射频，不是真的网卡。但TCP/IP栈（不管是uIP还是lwIP）都认为自己在跟一张网卡打交道。所以得用软件模拟一张虚拟网卡：
Plain Text// 虚拟网卡架构 ┌─────────────┐ │ uIP/lwIP │ │ TCP/IP栈 │ └──────┬──────┘ 读取↓ ↑写入 ┌──────────┐ ┌──────────┐ │ RX FIFO │ │ TX FIFO │ │(环形队列)│ │(环形队列)│ └────┬─────┘ └─────┬────┘ 写入↓ ↑读取 ┌──────────────────────┐ │ BNEP收发层 │ │ （蓝牙协议栈） │ └──────────────────────┘ |
收方向：蓝牙收到BNEP帧 → 解析成以太网帧格式 → 写进RX FIFO → TCP/IP栈从RX FIFO取出处理
发方向：TCP/IP栈把以太网帧写进TX FIFO → BNEP层从TX FIFO取出 → 封装成BNEP帧 → 蓝牙发出
两个环形队列就是这张"虚拟网卡"的驱动。main loop不停地在两个FIFO之间搬数据。
带宽和适用场景
经典蓝牙EDR理论带宽3Mbps，减去协议开销实际也就~2Mbps。跑轻量级的HTTP请求、MQTT消息收发完全够用。但流媒体、大文件下载就别指望了。
什么时候考虑PAN：
设备没有WiFi模块，但有经典蓝牙——PAN是唯一的IP联网途径
WiFi环境不可靠，蓝牙做备选通道——BT+WiFi双链路容灾
不想额外开WiFi，省功耗——蓝牙本身就开着（比如在跑A2DP播歌），顺带走PAN上网
七、PAN vs 其他蓝牙联网方案
对比项 | PAN（BNEP） | SPP+PPP | BLE IPSP | WiFi热点 |
协议栈 | IP→BNEP→L2CAP | IP→PPP→RFCOMM→L2CAP | IP→6LoWPAN→L2CAP(BLE) | 标准WiFi |
蓝牙类型 | 经典BT（BR/EDR） | 经典BT | BLE 4.1+ | 不走蓝牙 |
带宽 | ~2Mbps | ~1-2Mbps（RFCOMM开销略高） | 200Kbps~1Mbps（取决于BLE版本和PHY） | 几十Mbps |
功耗 | 中 | 中 | 低 | 高 |
层级开销 | 少（3层） | 多（4层） | 少 | — |
适合 | 通用IP通信 | 老设备兼容 | BLE低功耗场景 | 高带宽 |
SPP+PPP是老方案，多了RFCOMM和PPP两层，带宽也不如PAN。BLE IPSP走的是低功耗蓝牙，功耗最低但带宽也最低，适合传感器那种数据量小的场景。WiFi热点带宽碾压，但功耗也最高。
八、PAN的硬伤——为什么实际产品里用的人不多
协议栈是完整的，技术上能跑通。但翻了一圈论坛和实测数据，PAN在蓝牙协议族里一直属于"有但没人用"的那一类。原因很现实：
带宽天花板太低
经典蓝牙EDR理论最大3Mbps，但那是射频层的峰值。走完L2CAP → BNEP → IP这一串协议开销之后，实际到应用层的吞吐量：
场景 | 实测网速 | 备注 |
BT PAN共享（WiFi同时开着） | ~700 Kbps | XDA论坛多人复现，很普遍 |
BT PAN共享（WiFi关闭） | ~1.2-1.5 Mbps | 关WiFi后明显提速 |
BT PAN共享（理想环境） | ~2 Mbps 封顶 | 协议理论上限 |
700Kbps这个数字很多人都碰到了。原因是蓝牙和WiFi共用2.4GHz频段，WiFi开着的时候蓝牙得让路（共存机制coexistence），吞吐量直接砍一半。关WiFi之后能跑到1.5Mbps左右，但也就到头了。
对比一下：WiFi热点轻松几十Mbps，USB共享跑满手机上行。PAN的带宽只够发HTTP请求、跑MQTT、传个小文件。
延迟高且抖动大
蓝牙PAN的实测ping在 100~200ms 量级（来源：XDA/SuperUser论坛多位用户实测，非官方数据），而且 抖动很大 ——有人测出来稳定200ms，有人在100~400ms之间跳。蓝牙的跳频机制和重传策略本身就不是为低延迟设计的，再叠上BNEP封装和IP栈处理，延迟没法控。
对比：WiFi局域网1~5ms，4G网络20~50ms。蓝牙PAN比4G还慢。
2.4GHz干扰敏感
蓝牙工作在2.4GHz ISM频段，跟WiFi、微波炉、无线鼠标键盘全挤在一起。WiFi密集的环境（办公室、展会）里，蓝牙跳频虽然能一定程度避开干扰，但丢包率和重传都会上去，吞吐进一步下降。
多设备共享带宽见底
PAN本质是点对点连接。一个NAP理论上能接7个PANU（piconet上限），但实际同时活跃2~3个就很吃力了——带宽是共享的，3个设备一起跑就每个只剩几百Kbps。
操作系统支持在退化
这才是最致命的。iOS不开放蓝牙PAN的PANU角色——iPhone只能做NAP给别人共享网络，不能作为PANU通过别人的蓝牙上网（不是硬件不支持，是Apple没开放这个接口）。Android虽然支持，但从Android 10开始不少厂商的ROM把蓝牙共享优先级降了，部分机型直接砍掉了PAN选项。Windows倒是一直支持，但配对流程比WiFi麻烦得多。
整个行业的趋势：WiFi Direct / WiFi Aware拿走了高带宽场景，BLE拿走了低功耗场景，PAN卡在中间两头不靠。
九、PAN能不能跑WebRTC/AI语音？——结合AI玩具场景聊聊
最近AI玩具（AI语音对话玩具、故事机、陪伴机器人）特别火，这类产品的核心链路都差不多：
Plain Text// AI玩具的典型语音交互链路MIC录音 → 音频上传云端 → ASR语音识别 → LLM大模型推理→ TTS语音合成 → 音频下载播放 |
绝大多数AI玩具走的是WiFi联网。但WiFi有个痛点：配网体验差。让小朋友或者不懂技术的家长在一个没屏幕的玩具上输WiFi密码，是很头疼的事情。蓝牙配对就简单多了——扫一下、点一下就连上了。
所以一个很自然的想法是：能不能用蓝牙PAN代替WiFi，让AI玩具通过蓝牙借手机的网络上网？ 省掉WiFi模块和配网流程，成本也能降一点。
答案是：看场景，大部分情况不行。
WebRTC实时语音通话：不行
现在不少AI语音方案（比如百度BRTC、火山引擎RTC）走的是WebRTC协议，音频通过RTP实时双向传输。WebRTC对网络的要求：
指标 | WebRTC要求 | 蓝牙PAN能提供 |
带宽（纯语音） | 40~80 Kbps双向 | ✅ 够 |
带宽（语音+视频） | 1~5 Mbps双向 | ❌ 远不够 |
单向延迟 | < 150ms | ❌ 蓝牙PAN自身就100~200ms |
端到端延迟 | < 300ms | ❌ PAN 100~200ms + 互联网 50~100ms > 300ms |
抖动 | 越小越好 | ❌ 100~400ms不可控 |
带宽跑纯语音是够的，但延迟是硬伤。蓝牙PAN自身就吃掉100~200ms，加上STUN/TURN服务器中转和对方网络延迟，端到端很容易超过300ms。超过300ms的语音通话体验就很差了——说话跟对讲机似的，得等对方说完才能接话。
而且WebRTC的拥塞控制算法（GCC）会根据延迟和丢包动态调码率。蓝牙PAN的高抖动理论上会让GCC反复误判网络状况，码率忽高忽低，音频断断续续（这是合理推测，目前没找到有人在蓝牙PAN上实测WebRTC的报告）。
HTTP/WebSocket方式的AI语音：勉强能用
不是所有AI语音方案都走WebRTC。有些方案是这样的：
Plain Text// HTTP/WS方式的AI语音交互录完一段话 → HTTP POST音频到云端 → 等云端返回TTS音频 → 播放// 或者录音 → WebSocket实时流上传 → 云端流式返回TTS → 边收边播 |
这种方式对延迟没那么敏感——用户说完一句话，等个1~2秒出结果是可以接受的（像ChatGPT那样）。蓝牙PAN跑这种场景：
带宽：一段5秒的Opus音频也就几十KB，上传没压力
延迟：多了100~200ms的蓝牙传输延迟，用户感知不明显（本来就要等LLM推理）
TTS下载：流式TTS边生成边播，每个chunk几KB，700Kbps也够用
所以非实时的AI语音交互，蓝牙PAN理论上是可以跑的。但有个前提：手机得一直开着蓝牙共享，而且不能离太远（蓝牙有效距离10米左右）。
AI玩具到底该怎么选
方案 | 带宽 | 延迟 | 配网体验 | 成本 | 适合 |
WiFi直连 | 几十Mbps | 低 | 差（要输密码） | 要WiFi模块 | WebRTC实时对话、视频 |
BLE配网+WiFi | 几十Mbps | 低 | 好（BLE引导配网） | 要WiFi+BLE | 主流AI玩具方案 |
蓝牙PAN | ~1Mbps | 高 | 好（蓝牙配对） | 省WiFi模块 | 非实时HTTP/MQTT |
4G模组 | 几Mbps | 中 | 免配网（插卡即用） | 模组+流量费 | 户外/无WiFi场景 |
现在主流AI玩具的做法是BLE配网+WiFi通信——用BLE把WiFi密码传给设备，设备再连WiFi跑业务。这样既解决了配网体验问题，又有WiFi的带宽和低延迟。
蓝牙PAN只在一个很窄的场景下有价值：设备没有WiFi模块，只有经典蓝牙，而且业务不需要实时音视频。比如一个只跑MQTT上报传感器数据的小设备，或者一个只做HTTP请求查天气/查百科的简单终端。
但说实话，现在WiFi+BT combo芯片（比如杰理AC791N、乐鑫ESP32）已经很便宜了，没什么理由非要省掉WiFi走PAN。PAN更多是一个备用通道或者技术好奇心的存在。
总的来说
PAN是个完整的技术方案，协议栈设计得很工整——BNEP做桥、SDP做发现、lwIP做TCP/IP、DHCP做地址分配，每一层该有的都有。但带宽低、延迟高、抖动大、OS支持退化这四个硬伤决定了它在实际产品里用不起来。
能跑的场景：HTTP请求、MQTT消息、REST API、小文件传输——"不着急"的IP通信。
跑不了的场景：WebRTC音视频、实时语音对话、流媒体——任何对延迟敏感的东西。
对AI玩具来说，WiFi仍然是不可替代的。PAN最多做个WiFi挂了之后的降级备份，或者在纯蓝牙芯片上做个轻量联网的备选——但这种场景在WiFi combo芯片白菜价的今天，越来越少了。