VoNR（Voice over New Radio）是5G SA网络中基于IMS的语音业务实现方案。与VoLTE相比，VoNR在IMS信令层面继承了完全相同的SIP/SDP交互机制，但在底层QoS保障路径上发生了根本性变化：EPS Bearer被替换为5G QoS Flow，PCRF被替换为PCF，Gx/Rx接口演变为N7/N5接口。
VoNR主叫（Mobile Originated, MO）呼叫建立的核心挑战在于：SIP信令交互必须与5G QoS资源预留严格同步。这意味着UE发出INVITE后，不能等到对端振铃（180 Ringing）才开始建立媒体承载，而是在收到183 Session Progress后立即触发专用QoS Flow建立，并通过SIP UPDATE消息确认资源预留完成。这一机制被称为SIP Preconditions（RFC 3312），是VoNR呼叫建立延迟优化的关键设计。
本文基于 3GPP TS 23.228 Section 5.3、TS 24.229 Section 5.1、TS 23.502 Section 4.3.4 及 RFC 3312，对VoNR MO呼叫建立全流程进行逐消息拆解，重点分析SDP Preconditions属性、P-CSCF/PCF/SMF的QoS策略交互、以及专用媒体承载建立时序。
VoNR呼叫涉及的核心网元和接口如下：
| 网元 | 角色 | 关键接口 |
|---|---|---|
| UE | 主叫/被叫终端 | Uu（空口）、N1（NAS） |
| gNB | 5G无线接入 | N2（NGAP）、Uu |
| AMF | 接入与移动性管理 | N1、N2、N11 |
| SMF | 会话管理 | N11、N4（PFCP）、N7 |
| UPF | 用户面功能 | N3、N4 |
| PCF | 策略控制 | N5（P-CSCF）、N7（SMF） |
| P-CSCF | IMS代理呼叫控制 | N5、Mw（SIP） |
| S-CSCF | IMS服务呼叫控制 | Mw、Mn、ISC |
| I-CSCF | IMS查询呼叫控制 | Mw、Cx |
| TAS | 电话应用服务器 | ISC |
VoNR呼叫的显著特征是信令面与媒体面分离：
graph TB
subgraph "IMS SIP Signaling Path - 5QI=5"
UE1[UE<br/>Calling] -->|SIP| PCSCF1[P-CSCF<br/>Calling]
PCSCF1 -->|SIP| SCSCF1[S-CSCF<br/>Calling]
SCSCF1 -->|SIP| ICSCF[I-CSCF<br/>Called]
ICSCF -->|SIP| SCSCF2[S-CSCF<br/>Called]
SCSCF2 -->|SIP| PCSCF2[P-CSCF<br/>Called]
PCSCF2 -->|SIP| UE2[UE<br/>Called]
end
subgraph "Voice Media Path - 5QI=1"
UE1 -.->|RTP| UPF1[UPF<br/>Calling]
UPF1 -.->|RTP/N6| UPF2[UPF<br/>Called]
UPF2 -.->|RTP| UE2
end
subgraph "QoS Policy Control"
PCSCF1 -.->|N5/Rx| PCF[PCF]
PCF -.->|N7| SMF[SMF]
SMF -.->|N4| UPF1
SMF -.->|N11| AMF[AMF]
AMF -.->|N2| GNB[gNB]
end
style UE1 fill:#e1f5fe
style UE2 fill:#e8f5e9
style PCF fill:#fff3e0
style SMF fill:#fce4ec
以下是基于 TS 23.228 Section 5.3.2.1 的MO呼叫建立完整信令流程：
sequenceDiagram
participant UE_O as UE (Calling)
participant PCSCF_O as P-CSCF (O)
participant SCSCF_O as S-CSCF (O)
participant TAS as TAS
participant ICSCF_T as I-CSCF (T)
participant SCSCF_T as S-CSCF (T)
participant PCSCF_T as P-CSCF (T)
participant UE_T as UE (Called)
participant PCF as PCF
participant SMF as SMF
Note over UE_O,UE_T: Phase 1 - SIP INVITE with Preconditions
UE_O->>PCSCF_O: SIP INVITE<br/>SDP Offer (precondition: none)
PCSCF_O->>SCSCF_O: SIP INVITE (forwarded)
SCSCF_O->>TAS: SIP INVITE (service invocation)
TAS->>SCSCF_O: SIP INVITE (forwarded)
SCSCF_O->>ICSCF_T: SIP INVITE
ICSCF_T->>SCSCF_T: SIP INVITE (route to called)
SCSCF_T->>PCSCF_T: SIP INVITE
PCSCF_T->>UE_T: SIP INVITE
Note over UE_O,UE_T: Phase 2 - 183 Session Progress & QoS Authorization
UE_T-->>PCSCF_T: 100 Trying
UE_T->>PCSCF_T: 183 Session Progress<br/>SDP Answer (precondition: none)
PCSCF_T->>PCF: N5 AAR (media authorization request)
PCF->>PCSCF_T: N5 AAA (media authorization answer)
PCSCF_T->>SCSCF_T: 183 Session Progress
SCSCF_T->>ICSCF_T: 183 Session Progress
ICSCF_T->>SCSCF_O: 183 Session Progress
SCSCF_O->>PCSCF_O: 183 Session Progress
PCSCF_O->>PCF: N5 AAR (media authorization request)
PCF->>PCSCF_O: N5 AAA
PCSCF_O->>UE_O: 183 Session Progress
Note over UE_O,SMF: Phase 3 - QoS Flow Establishment (5QI=1)
PCF->>SMF: N7 SM Policy Association Update<br/>(install QoS rule for 5QI=1)
SMF->>SMF: Initiate PDU Session Modification
Note over SMF: Establish dedicated QoS Flow (5QI=1)
UE_O->>UE_O: NAS: PDU Session Modification Complete
UE_T->>UE_T: NAS: PDU Session Modification Complete
Note over UE_O,UE_T: Phase 4 - PRACK for 183
UE_O->>PCSCF_O: PRACK (for 183)
PCSCF_O->>PCSCF_T: PRACK (forwarded)
PCSCF_T->>UE_T: PRACK
UE_T->>PCSCF_T: 200 OK (for PRACK)
PCSCF_T->>PCSCF_O: 200 OK (for PRACK)
PCSCF_O->>UE_O: 200 OK (for PRACK)
Note over UE_O,UE_T: Phase 5 - SIP UPDATE (Preconditions Met)
UE_O->>PCSCF_O: SIP UPDATE<br/>SDP (curr:qos local sendrecv)
PCSCF_O->>PCSCF_T: UPDATE (forwarded)
PCSCF_T->>UE_T: UPDATE
UE_T->>PCSCF_T: 200 OK (UPDATE)<br/>SDP (curr:qos remote sendrecv)
PCSCF_T->>PCSCF_O: 200 OK (UPDATE)
PCSCF_O->>UE_O: 200 OK (UPDATE)
Note over UE_O,UE_T: Phase 6 - Alerting & Answer
UE_T->>PCSCF_T: 180 Ringing
PCSCF_T->>PCSCF_O: 180 Ringing
PCSCF_O->>UE_O: 180 Ringing
UE_T->>PCSCF_T: 200 OK (INVITE)<br/>SDP Answer (final)
PCSCF_T->>PCSCF_O: 200 OK (INVITE)
PCSCF_O->>UE_O: 200 OK (INVITE)
UE_O->>PCSCF_O: ACK
PCSCF_O->>PCSCF_T: ACK
PCSCF_T->>UE_T: ACK
Note over UE_O,UE_T: Voice Session Active - 5QI=1 QoS Flow
规范引用：TS 23.228 Section 5.3.2.1、TS 24.229 Section 5.1.2.2.1、RFC 3312 Section 5
主叫UE发起INVITE时，SDP Offer中必须包含Preconditions属性。这是VoNR与普通SIP呼叫的核心区别——先协商媒体参数，再建立QoS资源，最后才振铃。
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bK12345
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>
Call-ID: call-12345@2001:db8::1
CSeq: 1 INVITE
Contact: <sip:+8613800138001@[2001:db8::1]:5060>
P-Preferred-Identity: <sip:[email protected]>
P-Access-Network-Info: 3GPP-Access;utran-cell-id-3gpp=460003FFFFFFF
Require: precondition
Supported: 100rel, precondition
Content-Type: application/sdp
v=0
o=- 12345 1 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
m=audio 49152 RTP/AVP 96 97 98
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=5.9-24.4; bw=nb-wb; max-red=220
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-set=0,1,2,3,4; mode-change-period=2
a=rtpmap:98 telephone-event/16000
a=fmtp:98 0-15
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=sendrecv
a=ptime:20
a=maxptime:240
SDP中Preconditions属性的关键IE说明：
| IE | 取值 | 含义 |
|---|---|---|
a=curr:qos local none |
none | 本地QoS资源尚未预留 |
a=curr:qos remote none |
none | 远端QoS资源尚未预留 |
a=des:qos mandatory local sendrecv |
mandatory sendrecv | 本地必须预留双向QoS资源 |
a=des:qos mandatory remote sendrecv |
mandatory sendrecv | 远端必须预留双向QoS资源 |
a=conf:qos remote sendrecv |
remote sendrecv | 请求远端在资源就绪后发送确认 |
Require: precondition |
- | INVITE消息级别要求Precondition支持 |
设计意图：Precondition机制确保只有在双方QoS资源都预留成功后，会话才进入振铃阶段。这避免了"振铃后因QoS不足导致通话质量差"的用户体验问题。
规范引用：TS 23.228 Section 5.3.2.1 Step 4-6、TS 29.514（N5接口）
被叫UE收到INVITE后，返回183 Session Progress（带SDP Answer），其中包含被叫方选定的编解码器和Precondition状态。关键点：183到达P-CSCF后触发QoS资源授权流程。
被叫P-CSCF → PCF: N5 AAR (Diameter AAR)
- Media-Component-Description:
- Media-Component-Number: 1
- Media-Type: AUDIO
- Max-Requested-Bandwidth-UL: 41000
- Max-Requested-Bandwidth-DL: 41000
- Flow-Status: ENABLED
- Codec-Data: "audio/rtpmap:96 EVS/16000"
- AF-Application-Identifier: "ims-voice"
PCF → 被叫P-CSCF: N5 AAA (Diameter AAA)
- Auth-Application-Id: 167772363
- Result-Code: DIAMETER_SUCCESS
同样，主叫P-CSCF在收到转发的183后，也向PCF发起N5 AAR请求，触发主叫侧QoS授权。
stateDiagram-v2
[*] --> Idle
Idle --> INVITE_Sent: UE sends INVITE
INVITE_Sent --> Wait_183: Forward INVITE to S-CSCF
Wait_183 --> QoS_Authorization: Receive 183<br/>with SDP Answer
QoS_Authorization --> Wait_Resource: Send N5 AAR to PCF<br/>Forward 183 to UE
Wait_Resource --> Resource_Confirmed: Receive QoS confirmation<br/>(5QI=1 flow established)
Resource_Confirmed --> Wait_UPDATE: Local precondition met<br/>Send/receive UPDATE
Wait_UPDATE --> Session_Active: Preconditions met on both sides
Session_Active --> [*]
QoS_Authorization --> Error: PCF rejects AAR
Wait_Resource --> Error: QoS setup timeout
Error --> [*]
规范引用：TS 23.502 Section 4.3.4（PDU Session Modification）、TS 29.512（N7接口）
P-CSCF通过N5接口完成QoS授权后，PCF通过N7接口向SMF下发QoS策略规则，触发PDU Session Modification流程建立专用QoS Flow。
PCF向SMF发送的策略更新包含以下关键参数：
| 参数 | 取值 | 说明 |
|---|---|---|
| QoS Flow 5QI | 1 | 会话类语音（Conversational Voice） |
| ARP Priority | 20 | 语音优先级 |
| ARP Pre-emption Capability | Enabled | 可抢占低优先级承载 |
| ARP Pre-emption Vulnerability | Not Vulnerable | 不被抢占 |
| GFBR UL | 41 kbps | 上行保证比特率 |
| GFBR DL | 41 kbps | 下行保证比特率 |
| MFBR UL | 41 kbps | 上行最大比特率 |
| MFBR DL | 41 kbps | 下行最大比特率 |
| Session-AMBR | 由运营商策略决定 | 聚合最大比特率 |
sequenceDiagram
participant PCF
participant SMF
participant AMF
participant gNB
participant UE
participant UPF
PCF->>SMF: N7: SMPolicyAssociationUpdate<br/>(Add QoS rule: 5QI=1)
SMF->>UPF: N4: Session Modification Request<br/>(Install FAR+QER for 5QI=1)
UPF-->>SMF: N4: Session Modification Response
SMF->>AMF: N11: N1N2MessageTransfer<br/>(N2 SM info: QoS Flow Setup)
AMF->>gNB: N2: PDU Session Resource Setup
gNB->>UE: RRC Reconfiguration<br/>(Add DRB for QoS Flow)
UE-->>gNB: RRC Reconfiguration Complete
gNB-->>AMF: N2: PDU Session Resource Setup Response
AMF-->>SMF: N11: Update SM Context Response
Note over UE,UPF: Dedicated QoS Flow (5QI=1) Active
关键细节： - SMF通过N4接口在UPF上安装QoS Enforcement Rule（QER），用于上行/下行速率管控 - SMF通过N2 SM Information向gNB下发QoS Flow参数，gNB据此建立无线DRB - UE通过RRC Reconfiguration获得专用无线承载 - 整个过程对SIP信令层面完全透明——SIP消息流不中断
规范引用：RFC 3262（Reliability of Provisional Responses）
183 Session Progress是一个临时响应（Provisional Response），在标准SIP中不需要可靠传输。但在VoNR中，183携带了关键的SDP Answer和Precondition信息，必须通过PRACK机制确保可靠传输。
UE_O → P-CSCF_O → S-CSCF_O → ... → UE_T:
PRACK sip:[email protected]
RAck: 1 1 INVITE ; 对应183中的RSeq: 1, CSeq: 1 INVITE
Content-Length: 0
UE_T → ... → UE_O:
SIP/2.0 200 OK
CSeq: 2 PRACK ; PRACK自身的CSeq
| 消息 | 作用 |
|---|---|
| PRACK | 确认收到183，保证临时响应的可靠传输 |
| 200 OK (PRACK) | 确认PRACK已收到 |
注意：PRACK的CSeq值与INVITE不同，它使用独立的CSeq序列号。RAck头部中的值对应183中的RSeq值。
规范引用：RFC 3312 Section 5.1、TS 24.229 Section 5.1.2.2.1
当5QI=1的专用QoS Flow建立成功后，UE在SIP层面需要通过UPDATE消息通知对端"本地资源已就绪"。这是Precondition机制的核心步骤。
UPDATE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP [2001:db8::1]:5060;branch=z9hG4bK99999
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>;tag=xyz789
Call-ID: call-12345@2001:db8::1
CSeq: 3 UPDATE
Content-Type: application/sdp
v=0
o=- 12345 2 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
m=audio 49152 RTP/AVP 96
a=rtpmap:96 EVS/16000/1
a=curr:qos local sendrecv ; 本地资源已就绪
a=curr:qos remote none ; 远端资源尚未就绪
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
SIP/2.0 200 OK
CSeq: 3 UPDATE
Content-Type: application/sdp
v=0
o=- 67890 2 IN IP6 2001:db8::2
s=-
c=IN IP6 2001:db8::2
t=0 0
m=audio 49170 RTP/AVP 96
a=rtpmap:96 EVS/16000/1
a=curr:qos local sendrecv ; 被叫本地资源已就绪
a=curr:qos remote sendrecv ; 主叫远端资源也已就绪
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
状态转换对照：
| Precondition状态 | INVITE时 | 183时 | UPDATE时 | 200 OK(UPDATE)时 |
|---|---|---|---|---|
| local curr | none | none | sendrecv | sendrecv |
| remote curr | none | none | none | sendrecv |
只有当双方local和remote的curr:qos都变为sendrecv时，Precondition才算完全满足，被叫UE才会开始振铃（180 Ringing）。
规范引用：TS 23.228 Section 5.3.2.1 Step 7-10
Precondition满足后，进入正常振铃和应答阶段：
UE_T → UE_O: 180 Ringing ; 被叫振铃
UE_T → UE_O: 200 OK (INVITE) ; 被叫摘机应答
SDP Answer (final) ; 最终SDP确认
UE_O → UE_T: ACK ; 三次握手完成
200 OK (INVITE)的特点：
- SDP中不再包含precondition属性（a=curr:qos可省略）
- 编解码器已最终确定（通常为EVS或AMR-WB）
- 会话进入Active状态
VoNR中SDP编解码协商遵循优先级列表原则，UE在Offer中按优先级排列编解码器，被叫在Answer中选择第一个支持的：
| 优先级 | 编解码器 | RTP Payload Type | 带宽范围 | 备注 |
|---|---|---|---|---|
| 1 | EVS | 96 | 5.9-24.4 kbps | 5G首选编解码器 |
| 2 | AMR-WB | 97 | 6.6-23.85 kbps | LTE兼容 |
| 3 | AMR-NB | (可选) | 4.75-12.2 kbps | 窄带兼容 |
| 4 | telephone-event | 98 | - | DTMF事件 |
编解码器选择策略： - 同一运营商内VoNR↔VoNR：优先选择EVS（5G新定义的编解码器，支持更宽频带） - VoNR↔VoLTE/3G：退回AMR-WB/AMR-NB - 不同运营商间：根据互联协议确定
P-CSCF通过N5接口（基于Diameter协议，与4G Rx接口兼容）向PCF发起媒体授权请求：
| AVP名称 | 说明 | 典型取值 |
|---|---|---|
| Media-Component-Description | 媒体组件描述 | 包含以下子AVP |
| Media-Component-Number | 媒体组件编号 | 1（音频） |
| Media-Type | 媒体类型 | AUDIO |
| Max-Requested-Bandwidth-UL | 上行最大请求带宽 | 41000 (bps) |
| Max-Requested-Bandwidth-DL | 下行最大请求带宽 | 41000 (bps) |
| Flow-Status | 流状态 | ENABLED (0) |
| Codec-Data | 编解码器数据 | "uplink\naudio\nrtpmap:96 EVS/16000" |
| AF-Application-Identifier | 应用标识 | "ims-voice" |
| SIP-Forking-Indication | SIP分叉指示 | SINGLE_DIALOG (0) |
| Priority | 优先级 | 0 (IMS语音) |
PCF向SMF下发的QoS策略规则（PCC Rule）结构：
graph TB
subgraph "PCC Rule Structure"
PR["PCC Rule<br/>rule_id: voice-5qi1"]
PR --> QR["QoS Data<br/>5QI: 1<br/>ARP: pri=20, cap=1, vul=0<br/>GFBR-UL: 41kbps<br/>GFBR-DL: 41kbps"]
PR --> SDF["SDF Filter<br/>src: UE IP<br/>dst: Remote IP<br/>protocol: 17 (UDP)<br/>srcPort: any<br/>dstPort: 49152"]
PR --> GA["Gating Action<br/>permit (0)"]
PR --> PRIO["Precedence<br/>10"]
end
subgraph "QoS Flow Mapping"
QF["QoS Flow<br/>QFI: 1<br/>5QI: 1"]
QR --> QF
SDF --> QF
end
style PR fill:#e3f2fd
style QR fill:#fff3e0
style SDF fill:#e8f5e9
style QF fill:#fce4ec
| 对比维度 | VoLTE (4G) | VoNR (5G) |
|---|---|---|
| QoS模型 | EPS Bearer (QCI=1) | QoS Flow (5QI=1) |
| 承载建立方式 | Dedicated Bearer Setup | PDU Session Modification |
| 策略接口 | Rx (P-CSCF↔PCRF) + Gx (PCRF↔PGW) | N5 (P-CSCF↔PCF) + N7 (PCF↔SMF) |
| 控制面协议 | GTP-C (S11/MME↔SGW) | PFCP (N4/SMF↔UPF) + NGAP (N2) |
| 默认承载 | QCI=5 (IMS信令) + QCI=9 (默认) | 5QI=5 (IMS信令) + 5QI=9 (默认) |
| 语音编解码器 | AMR-WB (主) + AMR-NB | EVS (主) + AMR-WB + AMR-NB |
| 编解码器协商 | 基于SDP Offer/Answer | 相同机制，EVS优先 |
| 资源预留触发 | PCRF→PGW→MME→eNB | PCF→SMF→AMF→gNB |
| Precondition | RFC 3312 | 相同（RFC 3312） |
| 呼叫建立延迟 | ~1.5-2s | 目标<1.5s（5G NR低延迟优势） |
| EPS Fallback | 不适用 | 支持回退至VoLTE |
| 功率控制 | TPC (LTE) | TPC + Beamforming (NR) |
Wireshark过滤VoNR SIP信令：
# 过滤IMS SIP信令（5QI=5的QoS Flow上）
sip && ip.addr==<P-CSCF_IP>
# 过滤特定Call-ID的完整呼叫流
sip.Call-ID contains "call-12345"
# 过滤183 Session Progress
sip.Status-Code == 183
# 过滤UPDATE消息（Precondition确认）
sip.Method == "UPDATE"
# 过滤N5/Rx Diameter交互
diameter && diameter.cmdcode == 265 # AAR/AAA
Wireshark过滤5G QoS Flow建立：
# NGAP QoS Flow建立
ngap && ngap.pDUSessionResourceSetupItem
# PFCP会话修改（QoS Flow创建）
pfcp && pfcp.msg_type == 52 # Session Modification Request
| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| INVITE发出后无183返回 | P-CSCF路由失败、S-CSCF未找到被叫 | 检查P-CSCF→S-CSCF的Via/Route头部；检查I-CSCF的Cx查询 |
| 183后QoS Flow未建立 | PCF拒绝N5 AAR、SMF策略安装失败 | 检查Diameter AAR的Result-Code；检查N7 SMPolicyAssociationUpdate响应 |
| UPDATE发送后对端无响应 | 被叫侧QoS Flow建立失败 | 检查被叫SMF日志、被叫gNB RRC Reconfiguration是否成功 |
| 183后长时间无180 Ringing | Precondition未满足（某方QoS资源建立超时） | 检查双方a=curr:qos状态变化时序；关注PDU Session Modification Complete |
| 呼叫建立延迟过大（>2s） | QoS Flow建立耗时过长 | 分析SMF→AMF→gNB信令时序；检查gNB无线资源是否充足 |
| 200 OK (INVITE)后无媒体 | UPF N4规则未安装或RTP端口不匹配 | 检查N4 Session Modification；对比SDP中的端口与实际RTP流 |
| EVS编解码协商失败回落AMR-WB | 被叫不支持EVS或fmtp参数不兼容 | 检查SDP Offer中EVS的fmtp参数；确认双方EVS能力集 |
| ## 八、端到端时序优化分析 |
VoNR呼叫建立延迟是影响用户体验的关键指标。整个流程中各阶段耗时分布如下：
| 阶段 | 典型耗时 | 占比 | 优化方向 |
|---|---|---|---|
| INVITE路由到被叫 | 50-100ms | 5-8% | DNS缓存、S-CSCF直连 |
| 183返回与SDP协商 | 50-100ms | 5-8% | 快速编解码选择 |
| N5 AAR/AAA授权 | 30-50ms | 3-4% | P-CSCF与PCF同机房部署 |
| N7策略下发 | 20-40ms | 2-3% | PCF与SMF同机房部署 |
| QoS Flow建立（含空口） | 200-500ms | 25-40% | 最大瓶颈，优化RRC过程 |
| PRACK/200 OK往返 | 30-50ms | 3-4% | 压缩传输 |
| UPDATE/200 OK往返 | 30-50ms | 3-4% | 压缩传输 |
| 被叫振铃到摘机 | 用户行为 | - | 早期振铃（Early Ringing） |
| 总计（信令+承载） | ~500-900ms | 100% | - |
优化重点：QoS Flow建立（含N4/N2/RRC空口流程）是最大延迟瓶颈，占整体延迟的25-40%。5G NR通过更短的帧结构和更快的RRC过程，相比LTE缩短了约30%的空口建立时间。
Q1: VoNR中183 Session Progress和180 Ringing的区别是什么？
A: 183 Session Progress是会话进展指示，携带SDP Answer用于媒体参数协商和触发QoS资源预留；180 Ringing是振铃指示，表示被叫正在振铃。在Precondition机制下，183先于180发送——只有在双方QoS资源都预留成功（通过UPDATE确认）后，才会发送180 Ringing。如果不存在Precondition机制，某些实现中可能直接用180携带SDP Answer。
Q2: 为什么VoNR需要SIP UPDATE而不是直接在200 OK (INVITE)中确认资源预留？
A: 因为在Precondition机制下，振铃（180 Ringing）必须在资源预留完成后才能发送。如果等待200 OK (INVITE)才确认，意味着UE在资源未就绪时就已经开始振铃，用户接听后可能出现短暂静音或质量下降。UPDATE允许在INVITE事务进行中独立更新SDP参数，实现资源预留与振铃的精确同步。
Q3: 如果QoS Flow建立失败，VoNR呼叫会怎么处理？
A: 根据RFC 3312和TS 24.229的规定，如果QoS资源无法预留（如gNB无足够无线资源），Precondition将永远无法满足。通常的实现是设置定时器（一般4-8秒），超时后： - 主叫侧：发送CANCEL取消呼叫，或收到480/503响应 - 被叫侧：不发送180 Ringing，等待超时后释放会话 - 如果支持EPS Fallback，SMF/AMF可触发UE切换到LTE，回落到VoLTE建立语音
Q4: VoNR中的N5接口和4G VoLTE中的Rx接口有什么关系？
A: N5接口和Rx接口在功能上等价，都是P-CSCF（AF）与策略控制节点（PCF/PCRF）之间的Diameter接口，用于媒体授权和QoS资源请求。区别在于： - 协议层面：N5使用与Rx相同的Diameter应用（Auth-Application-Id: 167772363），信令格式完全兼容 - 部署层面：5GC中PCF替代了EPC中的PCRF，SMF替代了PGW-C - 接口组合：5G中PCF同时提供N7接口给SMF（等效于4G的Gx），形成N5+N7策略链路（对应4G的Rx+Gx）
Q5: EVS编解码器相比AMR-WB有哪些改进，为什么VoNR优先选择EVS？
A: EVS（Enhanced Voice Services）在3GPP TS 26.441中定义，相比AMR-WB的改进包括： - 更宽音频范围：EVS支持窄带(NB)到超宽频(SWB)，而AMR-WB仅支持宽频(WB) - 更低码率下的更高质量：EVS在5.9kbps时的语音质量优于AMR-WB在8.85kbps的质量 - 更高码率选项：EVS最高支持24.4kbps（SWB），提供接近CD的语音质量 - 更好的抗抖动能力：EVS的max-red参数支持更大的冗余偏移 - 向后兼容：EVS包含AMR-WB IO模式，可与不支持EVS的终端互通
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。