: DSDS模式下的IMS/VoLTE注册与通话管理)
系列文章目录本文是“骁龙移动平台双卡双待DSDS的技术内幕”系列的第六篇聚焦双卡场景下IMS服务注册和VoLTE/VoNR通话管理的技术细节。1. IMS在DSDS中的特殊性1.1 为什么IMS在双卡中复杂IMS 在 DSDS 中的挑战每张卡需要独立的 IMS 注册独立的 SIP REGISTER独立的 IMS PDN (APN: ims)独立的 IPSec 安全通道但RF 资源共享IMS PDN 保活 (Keep-alive) 需要周期性通信SIP Re-REGISTER 需要网络交互VoLTE 通话需要持续的 RF 占用跨卡通话冲突SIM1 VoLTE 通话中SIM2 来电DSDS 模式下无法同时接听需要向用户提供选择 (挂断/拒接/合并?)1.2 IMS双注册架构┌─────────────────────────────────────────────────────────┐ │ IMS 双注册架构 │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ IMS Stack 0 │ │ IMS Stack 1 │ │ │ │ (Sub0/SIM1) │ │ (Sub1/SIM2) │ │ │ │ │ │ │ │ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ │ │ │SIP Engine │ │ │ │SIP Engine │ │ │ │ │ │(REGISTER, │ │ │ │(REGISTER, │ │ │ │ │ │ INVITE...) │ │ │ │ INVITE...) │ │ │ │ │ └─────┬──────┘ │ │ └─────┬──────┘ │ │ │ │ │ │ │ │ │ │ │ │ ┌─────▼──────┐ │ │ ┌─────▼──────┐ │ │ │ │ │IMS PDN │ │ │ │IMS PDN │ │ │ │ │ │(APN: ims) │ │ │ │(APN: ims) │ │ │ │ │ │IP: 10.x.x.1│ │ │ │IP: 10.x.x.2│ │ │ │ │ └─────┬──────┘ │ │ └─────┬──────┘ │ │ │ └────────┼─────────┘ └────────┼─────────┘ │ │ │ │ │ │ ┌────────▼─────────────────────────▼──────────────┐ │ │ │ Modem Data Layer │ │ │ │ Bearer 5 (QCI5, IMS Signaling, Sub0) │ │ │ │ Bearer 6 (QCI5, IMS Signaling, Sub1) │ │ │ │ Bearer 7 (QCI1, VoLTE Media, 按需) │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘2. IMS注册流程双卡场景2.1 启动时的双注册时序开机/SIM插入后 T0s: Modem完成网络注册Sub0 Sub1 T1s: IMS Framework启动 检查Sub0 IMS能力carrier config 检查Sub1 IMS能力carrier config T2s: Sub0 IMS PDN建立 AP → 「启动网络接口」WDS服务APNimsSub0 Modem → EPS Bearer Activated (QCI5) T3s: Sub1 IMS PDN建立 AP → 「启动网络接口」WDS服务APNimsSub1 Modem → EPS Bearer Activated (QCI5) T4s: Sub0 SIP REGISTER IPSec通道建立 SIP REGISTER → P-CSCF → S-CSCF 200 OK注册成功 T5s: Sub1 SIP REGISTER IPSec通道建立 SIP REGISTER → P-CSCF → S-CSCF 200 OK注册成功 T6s: 双卡IMS注册完成 两张卡都可以接打VoLTE电话2.2 IMS PDN 保活与 RF 冲突IMS PDN 保活需要定期发送SIP Re-REGISTER每3600s由运营商配置CRLF Keep-alive每120sTCP 保活NATT Keep-alive每30sIPSec NAT穿透在DSDS模式下的冲突场景Sub0 正在数据传输Sub1 需要 IMS 保活方案1利用 Tune-Away 间隙Sub1 的 keep-alive 很小几十字节在 tune-away 时顺带发送方案2使用 Sub0 的 HARQ 间隙当 Sub0 数据有 HARQ 等待时间快速切到 Sub1 发送保活包方案3IMS 层面优化延长 keep-alive 间隔非 DDS 卡减少 RF 切换频率3. VoLTE 通话管理3.1 单卡 VoLTE 呼叫建立┌─────┐ ┌──────┐ ┌────────┐ ┌───────┐ │ App │ │ IMS │ │ Modem │ │ NW │ │ │ │Stack │ │ │ │(网络) │ └──┬──┘ └──┬───┘ └───┬────┘ └───┬───┘ │ dial() │ │ │ ├───────────►│ │ │ │ │ SIP INVITE │ │ │ ├─────────────►├──────────────►│ │ │ │ 100 Trying │ │ │◄─────────────┤◄──────────────┤ │ │ │ │ │ │ │ Dedicated Bearer Setup │ │ │ (QCI1, GBR) │ │ │ │◄──────────────┤ │ │ │ Bearer ACK │ │ │ ├──────────────►│ │ │ │ │ │ │ 180 Ringing │ │ │ │◄─────────────┤◄──────────────┤ │ringback │ │ │ │◄───────────┤ │ │ │ │ 200 OK │ │ │ │◄─────────────┤◄──────────────┤ │ │ ACK │ │ │ ├─────────────►├──────────────►│ │connected │ │ │ │◄───────────┤ RTP/RTCP Media Flow │ │ │◄────────────►│◄─────────────►│3.2 双卡通话冲突处理场景1: SIM1 VoLTE 通话中, SIM2 来电DSDS: RF 被 SIM1 通话独占→ SIM2 无法 tune-away 接收 paging→ 网络侧发现 UE 不可达→ 来电方听到您拨打的电话暂时无法接通–优化方案a运营商侧Call Waiting over IMS – 网络通过SIM1的IMS连接转发SIM2来电通知b终端侧利用VoLTE静默帧间隙监听SIM2 pagingc完美方案DSDA独立RF场景2SIM1通话中用户主动用SIM2拨出DSDS系统提示需要先结束SIM1通话DSDA允许同时进行两路通话场景3两张卡同时有来电理论上DSDS不会发生RF一次只监听一个但tune-away间隙可能检测到第二路来电处理第一路来电优先第二路排队或拒绝3.3 VoLTE与数据并发DSDS限制DSDS 模式下 SIM1 VoLTE 通话时的数据策略: ┌─────────────────────────────────────────────┐ │ 数据策略选项: │ │ │ │ 1. SIM1 数据继续 (同一张卡) │ │ ├── VoLTE Bearer (QCI1) Data (QCI9) │ │ ├── 同频可以共存 │ │ └── 但通话质量可能受影响 │ │ │ │ 2. 数据暂停 (传统 DSDS) │ │ ├── SIM1 VoLTE 独占 RF │ │ ├── SIM1 数据暂停 │ │ ├── SIM2 数据不可用 (RF 被 SIM1 占用) │ │ └── 通话期间完全无数据 │ │ │ │ 3. EP-DSDS (Enhanced Processing) │ │ ├── SIM1 VoLTE 通话 │ │ ├── SIM1 数据在通话间隙传输 │ │ ├── 利用 VoLTE 20ms 帧间隔 │ │ └── 数据速率有限但不完全中断 │ └──────────────────────────────────────────────┘4. IMS 注册状态管理4.1 IMS 状态机每个 Sub 独立┌──────────┐ PDN建立成功 ┌────────────┐ │ NOT │────────────────────►│ PDN │ │REGISTERED│ │CONNECTED │ │ │◄────PDN断开─────────│ │ └──────────┘ └─────┬──────┘ │ SIP REGISTER成功 │ ▼ ┌────────────┐ │REGISTERED │ │(VoLTE Ready)│ └─────┬──────┘ │ Re-Register失败 │ ▼ ┌────────────┐ │REGISTERING │ │(重试中) │ └────────────┘4.2 Cross-SIM IMS 冲突// ImsManager 处理双卡 IMS 状态的逻辑classImsServiceController{ImsManager[]mImsManagersnewImsManager[2];voidonImsRegistrationStateChanged(intsubId,intstate){if(stateREGISTERED){// 检查是否需要更新 IMS capabilityupdateImsCapabilities(subId);// 通知 TelecomManager 该卡可以 VoLTEnotifyVoLTECapable(subId,true);}if(stateDEREGISTERED){// 检查原因intreasongetDeregReason(subId);if(reasonRF_UNAVAILABLE){// tune-away 导致 IMS 注册失败// 重新调度注册 (等待 RF 可用)scheduleReregistration(subId,DELAY_MS);}}}}4.3 IMS 注册的 tune-away 影响IMS REGISTER 事务时序要求: SIP REGISTER ──(发送)──► ... ──(等待)──► 200 OK ↑ 必须在 32s 内收到响应 (SIP Timer F) DSDS 下的风险: ├── Sub1 发送 REGISTER 后RF 切回 Sub0 ├── 如果 Sub0 长时间占用 RF (大文件下载) ├── Sub1 可能错过 200 OK ├── 超时后重试 → 延长注册时间 └── 极端情况: 反复超时 → 注册失败 Modem 优化: ├── IMS 信令优先级高于普通数据 ├── 检测到 IMS 事务进行中时缩短 tune-away 间隔 └── 确保 Sub1 有足够的 RF 时间完成注册事务5. 实践指南5.1 IMS 注册状态查看# 查看双卡 IMS 注册状态 adb shell dumpsys telephony.registry | grep -A 5 mImsRegistered # 查看 IMS 服务状态 adb shell dumpsys carrier_config | grep ims # 查看 IMS PDN 连接状态 adb shell ifconfig | grep -A 3 rmnet_ims # 详细 IMS 状态 adb shell dumpsys activity service com.android.phone \ | grep -A 30 ImsManager5.2 VoLTE 通话问题排查# 1. 确认 VoLTE 是否启用 adb shell settings get global enhanced_4g_mode_enabled # 或 adb shell content query --uri content://telephony/siminfo \ --projection enhanced_4g_mode_enabled # 2. 抓取 IMS 日志 adb logcat -b radio | grep -iE ims|volte|sip|register # 3. 关键日志标记 # ImsRegistration: REGISTERED - 注册成功 # ImsRegistration: DEREGISTERED reasonXXX - 注册失败 # ImsCall: onCallStarted - VoLTE 通话开始 # ImsCall: onCallTerminated - VoLTE 通话结束 # 4. QXDM IMS 过滤器 # IMS SIP Message (查看 REGISTER/INVITE) 相关日志分类 (具体 log code 见高通 QXDM 文档, 需 NDA) # IMS Registration Status 相关日志分类 (具体 log code 见高通 QXDM 文档, 需 NDA) # IMS PDN Status 相关日志分类 (具体 log code 见高通 QXDM 文档, 需 NDA)5.3 双卡 VoLTE 功能验证测试矩阵如下测试项验证内容双注册两张卡同时 IMS 注册成功SIM1 MOSIM1 主叫 VoLTE 正常SIM2 MTSIM2 被叫 VoLTE 正常跨卡冲突SIM1通话中SIM2来电的处理注册恢复网络波动后 IMS 自动重注册PDN 保活长时间待机后 IMS 仍然注册SRVCCVoLTE回落到3G语音的切换# 验证命令示例 # 1. 确认双注册 adb shell dumpsys telephony.registry | grep mImsRegistered # 期望输出mImsRegisteredtrue出现两次 # 2. 模拟通话冲突 # 终端1呼叫SIM1同时终端2呼叫SIM2 # 观察日志中的冲突处理逻辑5.4 运营商配置对 IMS 双卡的影响!-- carrier_config.xml 中双卡 IMS 相关配置 -- carrier_config_list !-- Sub0 运营商 -- carrier_config mcc460 mnc00 !-- 是否支持 VoLTE -- boolean namecarrier_volte_available_bool valuetrue !-- IMS APN -- string nameims_apn_name valueims !-- 非默认数据卡时是否保持 IMS 注册 -- boolean nameims_on_non_dds_bool valuetrue !-- SIP REGISTER 超时 -- int nameims_registration_timeout value30000 /carrier_config !-- Sub1 运营商 -- carrier_config mcc460 mnc01 boolean namecarrier_volte_available_bool valuetrue boolean nameims_on_non_dds_bool valuetrue !-- 跨卡来电通知能力 -- boolean namecross_sim_calling_bool valuefalse /carrier_config /carrier_config_list6. 关于Cross-SIM Calling6.1 概念Cross-SIM Calling 允许在一张卡的 IMS 连接上为另一张卡提供通话服务场景: SIM2 信号极弱, SIM1 有强 WiFi/LTE 连接 传统 DSDS: SIM2 无法接打电话 (信号不足) Cross-SIM Calling: SIM2 的通话通过 SIM1 的 IMS/WiFi 连接进行 ┌────────────────────────────────────────┐ │ SIM2 来电 → 网络 → SIM1的IMS通道 │ │ → 转发给 SIM2 模块 │ │ → 用户正常接听 │ └────────────────────────────────────────┘6.2 限制需要运营商网络支持两张卡可能需要来自同一运营商目前仅少数运营商/平台支持6.3 SRVCC 与 EPS Fallback 在双卡中的处理6.3.1 SRVCC (Single Radio Voice Call Continuity)SRVCC 是 VoLTE 通话过程中当 LTE 信号衰减到无法维持通话质量时将语音业务无缝切换到 3G/2G CS 域的机制。SRVCC 基本流程单卡 VoLTE 通话中 LTE RSRP 持续下降如 -120 dBm Modem 触发 B2 测量事件LTE弱 3G可用 eNB 发起 SRVCC HO Command UE 执行切换 释放 LTE RRC 连接 建立 3G/2G CS 连接 语音流从 IMS 切到 CS 域 通话继续用户感知短暂静音 ~ 300msDSDS 下 SRVCC 的特殊性┌─────────────────────────────────────────────────────────────┐ │ DSDS 场景下的 SRVCC 复杂性 │ │ │ │ 场景: SIM1 VoLTE 通话触发 SRVCC → 回落到 3G │ │ │ │ RF 影响: │ │ ├── 切换前: RF 在 LTE 频段 (如 Band3, 1800MHz) │ │ ├── 切换后: RF 需要到 3G 频段 (如 Band1, 2100MHz) │ │ ├── 3G 频段可能与 SIM2 当前驻留频段冲突 │ │ └── SIM2 的 paging 监听可能受到影响 │ │ │ │ 副卡状态变化: │ │ ├── SRVCC 执行期间: SIM2 完全暂停 (RF 被独占) │ │ ├── SRVCC 完成后: SIM2 需要重新获取 RF 时间片 │ │ ├── 如果 3G 通话占用 RF 更密集 (无 DRX 间隙) │ │ └── SIM2 的 tune-away 可能更加困难 │ │ │ │ 关键问题: │ │ ├── 3G CS 通话期间副卡可达性更差 (3G 无法灵活调度) │ │ ├── SRVCC DSDS 副卡几乎无法接来电 │ │ └── 部分 OEM 在 SRVCC 后暂时禁用副卡 paging │ └─────────────────────────────────────────────────────────────┘bSRVCC (back to VoLTE)当用户移动回 LTE 覆盖区域时从 CS 域切回 VoLTE 的反向过程。在 DSDS 中bSRVCC 意味着 RF 资源重新回到 LTE 频段副卡的 tune-away 条件改善。6.3.2 EPS Fallback (5G → 4G 语音回落)当 VoNRVoice over NR不可用时UE需要通过EPS Fallback回到LTE进行VoLTE通话┌─────────────────────────────────────────────────────────────┐ │ EPS Fallback 两种方式对比 │ │ │ │ 方式1: 重定向 (Redirection) │ │ ├── 5G NR → RRC Release with redirect info → LTE │ │ ├── 完全释放 NR 连接后再建立 LTE 连接 │ │ ├── 延迟较大 (~2-3s) │ │ └── 实现简单兼容性好 │ │ │ │ 方式2: 切换 (Handover) │ │ ├── 5G NR → Handover Command → LTE │ │ ├── 无缝切换不释放信令连接 │ │ ├── 延迟较小 (~500ms) │ │ └── 实现复杂需要网络侧支持 │ │ │ │ DSDS 下的特殊考量: │ │ ├── SIM1 (5G) 执行 EPS Fallback 到 4G │ │ ├── SIM2 可能已经在 4G (频段可能相同!) │ │ ├── 回落后两卡都在 LTE → 标准 DSDS tune-away 模式 │ │ └── 如果 SIM2 在 5G: 两卡都可能需要频段调整 │ └─────────────────────────────────────────────────────────────┘双卡EPS Fallback的QMI消息流AP Modem │ │ │ 用户拨号 (SIM1, 5G NR) │ │ 「拨号请求」(Voice 服务) │ ├───────────────────────────►│ │ │ 检测到 VoNR 不可用 │ │ 触发 EPS Fallback │ 「系统信息指示」(NAS 服务) │ │ (SIM1: NR→LTE 切换中) │ │◄───────────────────────────┤ │ │ │ │ 完成 Fallback 到 LTE │ │ 在 LTE 上建立 IMS PDN │ │ 发起 VoLTE 呼叫 │ 「呼叫状态指示」(Voice 服务) │ │ (DIALING on LTE) │ │◄───────────────────────────┤6.3.3 Emergency Call 在 DSDS 中的特殊处理紧急呼叫如 112/911是所有蜂窝通信中优先级最高的业务在 DSDS 中有特殊的处理逻辑┌─────────────────────────────────────────────────────────────┐ │ 紧急呼叫在 DSDS 中的特殊行为 │ │ │ │ 原则: 紧急呼叫可以使用 *任何* 可用网络 │ │ │ │ 选网策略: │ │ ├── 优先使用有 SIM 且信号最强的卡 │ │ ├── 如果所有 SIM 无服务可 No-SIM 紧急呼叫 │ │ ├── 可以使用非 HPLMN 的网络 │ │ └── 不受 Forbidden PLMN 限制 │ │ │ │ RF 资源处理: │ │ ├── 紧急呼叫发起: 立即独占所有 RF 资源 │ │ ├── 另一张卡: 完全抑制 (不再 tune-away) │ │ ├── 如果另一张卡正在通话: 强制挂断 │ │ └── 紧急呼叫结束后: 恢复正常 DSDS 调度 │ │ │ │ Modem 侧处理: │ │ ├── CM (Call Manager) 标记 EMERGENCY 优先级 │ │ ├── MCS 为紧急呼叫分配所有 RF Chain │ │ ├── NAS 在所有可用 PLMN 上尝试建立紧急承载 │ │ └── 超时未建立成功 → 尝试下一个 PLMN/频段 │ │ │ │ Android Framework 处理: │ │ ├── TelecomManager 识别紧急号码 │ │ ├── 选择 best phone (信号最强的卡) │ │ ├── 如果选中的卡无服务尝试另一张卡 │ │ └── 如果都无服务进入 Emergency Callback Mode │ └──────────────────────────────────────────────────────────────┘// Android Framework 紧急呼叫路由逻辑简化 class EmergencyCallHelper { Phone selectPhoneForEmergencyCall() { // 1. 优先选择信号最强且已注册的卡 Phone bestPhone null; int bestSignal Integer.MIN_VALUE; for (Phone phone : PhoneFactory.getPhones()) { if (phone.getServiceState().isEmergencyOnly() || phone.getServiceState().getState() STATE_IN_SERVICE) { int signal phone.getSignalStrength().getLevel(); if (signal bestSignal) { bestSignal signal; bestPhone phone; } } } // 2. 如果没有已注册的卡选择任何可以扫到网络的卡 if (bestPhone null) { bestPhone getPhoneWithAnyService(); } return bestPhone; } }6.3.4 实践SRVCC/EPS Fallback问题排查# 关键日志关键字 adb logcat -b radio | grep -iE srvcc|fallback|eps_fb|ho_cmd|redirect # QXDM 过滤器 # LTE NAS EMM State (观察回落前后状态变化) 相关日志分类 (具体 log code 见高通 QXDM 文档需 NDA) # LTE RRC Reconfiguration (HO Command) 相关日志分类 (具体 log code 见高通 QXDM 文档需 NDA) # IRAT Handover (跨制式切换) 相关日志分类 (具体 log code 见高通 QXDM 文档需 NDA) # IMS Call Status 相关日志分类 (具体 log code 见高通 QXDM 文档需 NDA) # NR RRC State (5G 连接状态) 相关日志分类 (具体 log code 见高通 QXDM 文档需 NDA)常见SRVCC/EPS Fallback失败原因失败现象原因DSDS 相关性排查方法SRVCC 掉话3G 目标小区信号不足低检查 B2 测量配置SRVCC 后单通CS 域 codec 协商失败低抓取 NAS CC 信令EPS FB 超时LTE 小区拥塞接入失败中检查 RACH 重试日志EPS FB 后无语音IMS→CS 域切换时序错误中对比 IMS/CS 事件时序副卡通话中触发 SRVCC 异常RF 资源冲突高检查 MCS 优先级仲裁紧急呼叫选错卡信号评估不准确高dumpEmergencyCallHelper7. 总结本文详细分析了DSDS模式下IMS/VoLTE的注册和通话管理双卡各自维护独立的IMS注册和PDN连接VoLTE通话时RF独占带来的跨卡冲突及处理策略IMS注册受tune-away影响的问题与优化运营商配置对双卡IMS行为的关键作用下一篇DSDS功耗优化与DRX/eDRX策略
