三星与谷歌Pixel设备BLE通知丢包及MTU回落问题技术问询

一、Android分包机制与MTU恢复方案 #

1. 能否移除/重新配置Android分包机制？
   Android的BLE分包是蓝牙核心规范定义的ATT层分段行为，属于协议栈底层逻辑，无法直接移除。但可通过以下方式优化：

   • 确保BLE连接建立后主动发起MTU交换，将MTU固定为设备支持的最大值247，避免链路质量下降时系统自动回退到最小MTU（32）。
   • 在固件中添加链路质量检测逻辑，当RSSI恢复至稳定阈值（如<-60）并持续一定时长后，主动触发MTU重协商流程。

2. 拥堵解除后如何恢复MTU至247？
   固件日志中的not enough resource - Error 17是蓝牙控制器资源耗尽的典型报错，链路拥堵时控制器会自动降低MTU以减少负载。要恢复MTU：

   • 在固件中实现链路状态监测：当检测到连续多个数据包发送成功、且RSSI稳定超过2秒时，调用对应蓝牙SDK的MTU重协商接口（如Nordic的sd_ble_gattc_exchange_mtu_request）。
   • 链路拥堵时临时降低数据包发送速率，待资源释放后再恢复原速率与MTU配置。

二、iPhone、Oppo等设备无此问题的原因 #

不同厂商蓝牙协议栈的资源调度逻辑差异导致：

• iPhone：CoreBluetooth对BLE链路资源管理更激进，链路质量下降时优先调整连接参数（如增大连接间隔）而非降低MTU，且MTU协商完成后不会自动回退。
• Oppo/Vivo：定制Android系统针对音频+BLE共存场景做了优先级调度优化，避免音频占用带宽导致BLE链路资源耗尽。
• 三星/Pixel：接近原生的Android系统依赖蓝牙控制器默认逻辑，音频高负载下易触发MTU回退机制。

三、conn_interval与conn_latency参数调整建议 #

结合音频+BLE数据传输的场景，建议针对性调整：

1. 低延迟参数（LE_LL_CONNECTION_PARAMS）：
   当前conn_interval_min=30ms、conn_interval_max=50ms的间隔过短，会与音频链路抢占射频资源，加剧拥堵。建议将连接间隔调整为CONN_INT_MS(40)至CONN_INT_MS(60)，保留conn_latency=0以保证数据实时性。
2. 低功耗参数（LE_LP_CONNECTION_PARAMS）：
   conn_latency=4会导致链路质量差时数据包堆积，加重资源耗尽问题。建议将conn_latency降至1或0，同时适当增大连接间隔（如CONN_INT_MS(100)至CONN_INT_MS(120)），平衡功耗与稳定性。
3. LE Audio空闲参数（LEA_IDLE_CONNECTION_PARAMS）：
   当前参数基本合理，可增加场景切换逻辑：音频播放时切换到低延迟参数，停止播放时切回空闲参数，减少资源占用。

补充优化建议 #

• 在固件中增加流量控制：检测到Error 17时，暂停1-2个周期的数据包发送，待资源释放后再恢复，避免持续触发错误导致MTU锁定在32。
• 针对三星/Pixel设备，在APP侧增加MTU监测逻辑，发现MTU降至32时主动发起重协商请求。

内容的提问来源于stack exchange，提问作者user1767221