骁龙移动平台双卡双待DSDS的技术内幕(5): 双栈QMI连接下的SIM卡切换与Modem资源冲突 系列文章目录本文是“骁龙移动平台双卡双待DSDS的技术内幕”系列的第五篇聚焦于双栈QMI连接场景下SIM卡切换引发的Modem资源冲突问题与解决方案。1. 问题背景为什么SIM卡切换会产生资源冲突1.1 双栈QMI的含义在DSDS模式下“双栈QMI连接”指┌─────────────────────────────────────────────────┐ │ AP 侧 QMI Client 布局 │ │ │ │ QMI Stack 0 (Sub0) QMI Stack 1 (Sub1)│ │ ┌──────────────┐ ┌──────────────┐ │ │ │ NAS Client │ │ NAS Client │ │ │ │ WDS Client │ │ WDS Client │ │ │ │ Voice Client │ │ Voice Client │ │ │ │ UIM Client │ │ UIM Client │ │ │ │ DSD Client │ │ DSD Client │ │ │ │ IMS Client │ │ IMS Client │ │ │ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────────────────────────────────┐ │ │ │ QMI Transport (GLINK/SMD) │ │ │ └──────────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘两套独立的QMI Client栈同时与Modem保持连接。当发生SIM卡切换如DDS Switch、SIM热插拔、用户手动切换默认卡时Modem内部的有限资源需要重新分配由此产生冲突。1.2 Modem 有限资源清单Modem有限资源清单示意图包含RF、Bearer、NAS状态机等资源。资源类型数量/约束RF Chain1 (DSDS) / 2 (DSDA)NAS 上下文2 (各含独立 EMM/ESM)PDCP/RLC 实体有限需在两Sub间分配HARQ 进程8 (LTE) 需分时复用Data Bearer通常最多 8 个 EPS BearerIMS PDN每 Sub 至少 1 个GNSS 射频与蜂窝共享天线干扰RACH 资源同一时刻只能一个 Sub 接入2. SIM卡切换的典型场景2.1 DDS Switch默认数据卡切换用户将默认数据卡从SIM1切换到SIM2 DDS Switch 全流程如下阶段1: 通知 Modem 准备切换│ AP → 「DDS 切换请求」(DSD 服务) (target_sub Sub1)阶段2: Modem 释放当前 Sub0 数据资源│ ├── 断开 Sub0 的 data bearer│ ├── 释放 Sub0 占用的 PDCP/RLC 资源│ ├── 释放 Sub0 的 RF grant (数据部分)│ └── 保留 Sub0 的 NAS 上下文 (继续驻网待机)阶段3: Modem 为 Sub1 分配数据资源│ ├── 建立 Sub1 的 data bearer (PDN Connectivity)│ ├── 分配 PDCP/RLC 资源给 Sub1│ ├── 重新配置 RF grant (数据优先给 Sub1)│ └── 通知 AP 切换完成阶段4: AP 侧恢复│ ├── QMI_WDS 在 Sub1 建立 data call│ ├── 网络路由表切换│ └── 应用层网络恢复总耗时2-5秒含信令和数据通道重建2.2 通话触发的临时切换SIM2 来电导致的临时资源重分配DSDS模式正常状态 Sub0DATA占用RF Bearer Sub1IDLE仅paging监听 来电触发 Sub1 Paging → CSFB/VoLTE呼叫建立 资源冲突 RFSub0 数据需要让出 RF 给 Sub1 通话 情况ACSFBSub1 需要回落到 3G频段可能不同 情况BVoLTESub1 建立 IMS PDN VoLTE bearer Sub0 数据暂停或降速 通话结束 → Sub1 释放通话资源 → Sub0 数据恢复2.3 eSIM Profile 切换eSIM Profile 切换MEPMultiple Enabled Profiles 传统 eSIM 切换 禁用 Profile A → 重启 UICC → 启用 Profile B 耗时 5-10 秒期间双卡完全中断 MEP 切换Android 13 Port0: Profile A保持活跃 Port1: Profile B切换目标 仅影响一个 port另一张卡不中断3. 资源冲突的具体表现3.1 Data Bearer 冲突场景Sub0 持有 3 个 EPS Bearer: Bearer 1: Default (Internet) Bearer 2: IMS (SOS) Bearer 3: MMS Sub1 需要建立 VoLTE 通话: 需要IMS Bearer Dedicated Bearer (QCI1) Modem EPS Bearer 总数据限制 8 冲突处理策略 策略1优先级抢占Preemption - VoLTE QCI1 优先级高于 Internet QCI9 - 暂时释放 Sub0 低优先级 Bearer 策略2共存降级Degradation - 保持 Sub0 所有 Bearer - 降低 Sub0 数据速率修改 AMBR 策略3临时挂起Suspension - Sub0 所有 Bearer 暂停保留上下文 - 通话结束后恢复3.2 NAS 状态机冲突两个 Subscription 的 NAS 独立运行但共享无线资源 Sub0 NAS State: EMM-REGISTERED, ECM-CONNECTED Sub1 NAS State: EMM-REGISTERED, ECM-IDLE 冲突场景两个 Sub 同时需要执行 TAUTracking Area Update Sub0: 移动到新 TA需要发送 TAU Request Sub1: 同时移动到新 TA也需要发送 TAU Request RF 只有一条只能串行处理 解决Modem 内部排队机制 queue_nas_procedure(Sub0, TAU, priorityNORMAL); queue_nas_procedure(Sub1, TAU, priorityNORMAL); // 执行顺序数据卡优先3.3 RACH 冲突Random AccessRACH是建立上行连接的必经之路 Sub0 需要 RACH上行数据发送 Sub1 需要 RACH响应 paging接来电 由于共享 RF同一时刻只能一个 Sub 做 RACH 冲突解决 如果 Sub1 RACH 是响应来电 优先级来电 数据 Sub0 RACH 延迟 如果两个都是数据 DDS 对应的 Sub 优先 非 DDS Sub 排队等待4. 高通 Modem 的冲突解决框架4.1 MCS (Multi-subscription Controller/Scheduler)MCS架构示意图展示MCS在AP与Modem之间的位置及与各子模块的交互。┌─────────────────────────────────────────────────────┐ │ MCS - 多订阅控制器 │ │ │ │ ┌───────────────────────────────────────────────┐ │ │ │ Policy Engine (策略引擎) │ │ │ │ ┌─────────┐ ┌──────────┐ ┌─────────────┐ │ │ │ │ │Business │ │ Priority │ │Fairness │ │ │ │ │ │Rules │ │ Table │ │Constraints │ │ │ │ │ │(业务规则)│ │(优先级表) │ │(公平性约束) │ │ │ │ │ └─────────┘ └──────────┘ └─────────────┘ │ │ │ └───────────────────────┬───────────────────────┘ │ │ │ │ │ ┌───────────────────────▼───────────────────────┐ │ │ │ Resource Allocator (资源分配器) │ │ │ │ ┌────────┐ ┌─────────┐ ┌──────────────┐ │ │ │ │ │RF Alloc│ │Bearer │ │NAS Scheduler │ │ │ │ │ │(射频) │ │Allocator│ │(NAS 调度) │ │ │ │ │ └────────┘ └─────────┘ └──────────────┘ │ │ │ └───────────────────────┬───────────────────────┘ │ │ │ │ │ ┌───────────────────────▼───────────────────────┐ │ │ │ Conflict Resolver (冲突解决器) │ │ │ │ - Preemption (抢占) │ │ │ │ - Queuing (排队) │ │ │ │ - Negotiation (协商降级) │ │ │ └───────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘4.2 优先级表等级业务类型可被抢占P0紧急呼叫 (E911)否P1VoLTE/VoNR 通话仅被 P0P2CS 语音通话 (CSFB)仅被 P0-1P3IMS 信令 (SIP REGISTER)P0-2P4SMS (短信)P0-3P5数据 (交互式, QCI7)P0-4P6数据 (流式, QCI8)P0-5P7数据 (后台, QCI9)P0-6P8位置更新 (TAU/LAU)P0-5P9Paging 监听特殊处理注“可被抢占”列中的“P0-2”表示可被P0、P1、P2等级的业务抢占其余依此类推“Paging 监听”为特殊处理逻辑。4.3 冲突解决流程# 伪代码Modem 冲突解决算法 def resolve_conflict(request_sub, request_type, current_state): # 解决双 Subscription 资源冲突 current_sub_activity get_current_rf_owner_activity() request_priority get_priority(request_type) current_priority get_priority(current_sub_activity) if request_priority current_priority: # 数字越小优先级越高 # 新请求优先级更高 - 抢占 preempt_current_activity(current_sub_activity) grant_resource(request_sub, request_type) return GRANTED elif can_coexist(request_type, current_sub_activity): # 可以共存如利用 HARQ 间隙 schedule_interleaved(request_sub, request_type) return GRANTED_DEGRADED else: # 无法满足 - 排队等待 enqueue(request_sub, request_type) return QUEUED5. DDS Switch 深入分析5.1 完整 QMI 消息流AP Modem │ │ │ 「DDS 切换请求」(DSD 服务) │ │ (new_dds_sub Sub1) │ ├───────────────────────────────►│ │ │ 1. 验证请求合法性 │ │ 2. 开始 DDS 切换状态机 │ 「DDS 切换响应」(DSD 服务) │ │ (accepted) │ │◄───────────────────────────────┤ │ │ │ │ 3. 暂停 Sub0 数据传输 │ │ 4. Detach Sub0 data bearer │ 「分组数据服务状态指示」(WDS 服务)│ │ (Sub0: DISCONNECTED) │ │◄───────────────────────────────┤ │ │ │ │ 5. RF 资源重新分配 │ │ 6. Sub1 PDN Connectivity │ │ 7. Sub1 Attach/TAU │ │ │ 「系统信息指示」(NAS 服务) │ │ (Sub1: service available) │ │◄───────────────────────────────┤ │ │ │ 「启动网络接口」(WDS 服务) │ │ INTERFACE_REQ (Sub1) │ ├───────────────────────────────►│ │ │ 8. 建立 Sub1 data call │ 「启动网络接口」(WDS 服务) │ │ INTERFACE_RESP (success) │ │◄───────────────────────────────┤ │ │ │ 「分组数据服务状态指示」(WDS 服务)│ │ (Sub1: CONNECTED) │ │◄───────────────────────────────┤ │ │ │ 「DDS 切换完成指示」(DSD 服务) │ │ (switch_complete) │ │◄───────────────────────────────┤5.2 DDS Switch 的异常处理异常场景及处理 1. 切换过程中 Sub1 注册失败 Modem 回滚恢复 Sub0 为 DDS 「DDS 切换完成指示」DSD 服务resultFAILED AP 恢复原状态 2. 切换过程中 Sub0 来电 切换暂停来电优先 来电处理完毕后继续切换 或者取消切换用户接听了电话 3. 切换过程中飞行模式 两个 Sub 都 detach 切换状态机重置 飞行模式关闭后重新执行 4. 切换超时10s Modem SSR (Sub-System Restart) 重新初始化双线 AP 重新配置 DDS5.3 快速 DDS Switch (Temporary DDS)场景Sub1非默认数据卡需要临时上网 例如Sub1的应用发起MMS发送 传统方式完整DDS Switch2-5秒 快速方式Temporary DDS临时DDS Temporary DDS流程 1. AP → 「临时DDS设置请求」DSD服务(subSub1, duration30s) 2. Modem不断开Sub0 bearer 仅临时允许Sub1建立数据连接 通过RF时间片共享 3. Sub1完成数据传输 4. 超时或完成后自动恢复到Sub0 无需完整DDS Switch 优势切换时间 500msSub0数据仅短暂降速而非中断6. 实践指南6.1 DDS Switch 日志分析# 抓取DDS切换相关日志 adb logcat -b radio | grep -E DDS|DataSwitch|PhoneSwitcher dds_log.txt # 关键日志标记 # [PhoneSwitcher] Evaluating DDS switch: current 0, preferred 1 # [DataNetworkController] Tearing down data network: reasonDDS_SWITCH # [QmiDsd] DDS switch request sent: target_sub 1 # [QmiDsd] DDS switch complete: result SUCCESS, duration 2340 ms # [DataNetworkController] Setup data network: sub 1, apn internet6.2 监控资源冲突# QXDM 日志过滤器 MCS Policy Decision 相关日志分类具体 log code 见高通 QXDM 文档需 NDA RF Resource Manager 相关日志分类具体 log code 见高通 QXDM 文档需 NDA Data Services Operation 相关日志分类具体 log code 见高通 QXDM 文档需 NDA LTE MAC RACH 相关日志分类具体 log code 见高通 QXDM 文档需 NDA # 关键关注点 # 1. Resource conflict detected - 资源冲突发生 # 2. Preemption executed - 抢占发生 # 3. Request queued - 请求被排队 # 4. DDS switch timeout - 切换超时6.3 性能调优建议# 1. 调整 DDS Switch 超时时间 # EFS: [Modem NV配置项] # 默认 10000ms可根据网络环境调整 # 2. 启用 Fast DDS Switch # [厂商私有属性] 1 # [厂商私有属性] 1 # 3. 配置 Temporary DDS 策略 # [厂商私有属性] 30000 (ms) # [厂商私有属性] 1 # [厂商私有属性] 1 # 4. 调整冲突解决优先级需 Modem NV 修改 # 通过 QPST/QFIL 修改相关 NV items6.4 测试用例设计测试项前置条件操作预期结果基本切换SIM1 数据连接中切换数据卡到 SIM2切换成功5s通话中切换SIM1 VoLTE 通话中尝试切换数据卡切换延迟到通话结束弱信号切换SIM2 信号 -110dBm切换数据卡到 SIM2切换成功但可能较慢飞行模式DDS 切换进行中开启飞行模式切换取消两卡正常关闭热插拔SIM1 为数据卡拔出 SIM1自动切换到 SIM2并发请求双卡都需要数据MMS(SIM2) 下载(SIM1)Temp DDS 处理 MMS超时恢复网络异常DDS 切换超时回滚到原卡上报错误7. 深入QMI WDS 双连接管理7.1 WDS Client 与 Data Call 映射WDS Client与Data Call映射关系图展示Sub0/Sub1各自WDS Client与对应Bearer的关联。┌────────────────────────────────────────────────┐ │ WDS (Wireless Data Service) 双栈管理 │ │ │ │ WDS Client Pool: │ │ ┌─────────────┐ ┌─────────────┐ │ │ │WDS Client 0 │ │WDS Client 1 │ │ │ │(Bound Sub0) │ │(Bound Sub1) │ │ │ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ │ │ Data Call 0 │ │ Data Call 1 │ │ │ │ APN: internet│ │ APN: ims │ │ │ │ IP: v4v6 │ │ IP: v4v6 │ │ │ │ Bearer: 5 │ │ Bearer: 6 │ │ │ └─────────────┘ └─────────────┘ │ │ │ │ 网络接口映射: │ │ rmnet_data0 ←→ Data Call 0 (Sub0) │ │ rmnet_data1 ←→ Data Call 1 (Sub1) │ │ rmnet_ipa0 ←→ IPA (加速通道) │ └────────────────────────────────────────────────┘7.2 Data Call 冲突场景// 场景Sub0 正在下载Sub1 需要发 MMS//// 冲突点两个 WDS data call 需要同时活跃// DSDS 限制RF 同一时刻只服务一个 Sub 的数据//// 解决方案实现voidhandleConcurrentDataRequest(intrequestingSub){if(isDSDSub(requestingSub)){// 请求方是默认数据卡 → 直接允许grantDataCall(requestingSub);}else{// 请求方是非默认数据卡 → Temporary DDSif(canUseTempDDS()){startTempDDS(requestingSub,TEMP_DDS_TIMEOUT);}else{// 需要完整 DDS Switch 或拒绝rejectOrQueueRequest(requestingSub);}}}8. 总结本文深入分析了双栈 QMI 连接下的 SIM 卡切换与 Modem 资源冲突资源冲突根源有限的 RF/Bearer/NAS 资源在两个 Subscription 间的争用冲突解决框架MCS 通过优先级仲裁、抢占、排队等机制解决DDS Switch完整的切换流程、异常处理和优化方案Temporary DDSWDS 双栈管理Data Call 的生命周期和并发处理下一篇预告DSDS 模式下的 IMS/VoLTE 注册与通话管理