VOLTE语音业务培训材料2-理论与案例 201702...

提纲：

1、volte语音业务信令流程：前台、完整流程、炎强、博瑞得、基站侧；未接通案例，掉话案例。 关键节点：UE、eNodeB、MME、SAE（SGW&PGW）、PCRF、SBC（SBC\\P-CSCF\\ AGCF\\ ATGW）、I/S-CSCF、AS（MMtel）、HSS

2、初始注册、重注册 关键节点：初始注册有401,nonce值为空，会影响业务；重注册无401，nonce值不为空，不影响业务。另外，expires为60000表示要注册，如果为0则表示去注册。 Nonce是RAND+AUTN的B编码。 3、eSRVCC流程、案例

关键节点：handover command是在Handover from E-UTRAN Command里面解出来,如果到2G之后320ms（T3214）收不到physical information，则会返回4G重建。 4、附录内容

一．VOLTE语音业务完整信令流程

UE(O)MME(O)SAE GW(O)PCRF(O)VoLTE SBC(O)I/S-CSCF(O)MMTel AS(O)MMTel AS(T)HSS(T)I/S-CSCF(T)VoLTE SBC(T)PCRF(T)SAE GW(T)MME(T)UE(T)1.INVITE2.AAR3.RAR6.Creat bearer request8.Creat bearer response4.RAA5.AAA7.空口流程9.CCR-U10.CCA-U11.RAR12.RAA13.INVITE14.INVITE15.INVITE16.INVITE17.LIR18.LIA19.INVITE20.UDR21.IDR22.IDA23.UDA24.INVITE25.INVITE26.INVITE27.18328.AAR35.18336.18337.18338.18339.18340.18341.18331.AAA29.RAR30.RAA32.Creat bearer request34.Creat bearer response33.空口流程42.18343.PRACK/200 OK44.AAR45.RAR46.RAA48.Update bear request49.空口流程47.AAA50.Update bear response51.UPDATE52.UPDATE53.UPDATE54.UPDATE55.UPDATE56.UPDATE57.UPDATE58.UPDATE59.UPDATE60.200 OK61.200 OK62.200 OK63.200 OK.200 OK65.200 OK66.200 OK67.200 OK68.200 OK69.被叫振铃70.180 Ringing71.200 OK/ACK通话建立72.BYE73.BYE75.STR76.RAR77.RAA79.Delete bear request80.空口流程74.BYE82.STR83.RAR78.AAA85.STA84.RAA81.Delete bear response.200 OK86. Delete bearer request88.Delete bearer response.空口流程 1 2

主叫用户UE(O)的呼叫请求发送到主叫P-CSCF。呼叫请求中包含precondition（为了确保呼叫建立之后有足够的主叫PCSCF通过AAR消息向PCC申请通话资源（临时），同时请求主叫用户位置信息。

媒体资源供会话使用）相关参数，其中主叫侧和被叫侧均为none。

按标准流程，VoLTE SBC（P-CSCF向PCRF发送AAR消息，携带用户IP、媒体部件信息（关键参数包含Media-Type、Flow-Description、Flow-Status）和AF应用标识等信息。

VOLTE SBC（P-CSCF）计算出相应的带宽信息满足与该次通话协商的编码。消息除了携带业务流信息外，消息中还携带AF-Charging-Identifier，通知PCRF ICID。消息中携带的终端地址为IPv6地址。同时携带Specific-Action AVP，其值为CHARGING_CORRELATION_EXCHANGE (1)，VoLTE SBC（P-CSCF）要求PCRF上报接入网侧的计费标识。并携带Specific-Action AVP，其值为为ACCESS_NETWORK_INFO_REPORT (12)，携带Required-Access-Info AVP，填写为USER_LOCATION (0)；)。

3~4 主叫侧PCRF通过RAR消息向S/P-GW下发策略。

Gx接口的RAR请求消息中，携带QoS（QoS关键参数包含QCI，ARP，GBR和MRB）策略(共1个规则)。相应的带宽信息满足与该次通话协商的编码要求，音频呼叫时含有QCI=1。RAR消息中Charging-Rule-Install AVP除了携带QOS参数外，该AVP中携带Charging-Correlation-Indicator AVP。同时还携带Event-Trigger AVP，取值为CHARGING_CORRELATION_EXCHANGE (28)，指示P-GW需要上报GCID。RAR消息中同时还携带AF-Charging-Identifier信息。 5

主叫侧PCRF向SBC返回AAA响应。

S/P-GW向PCRF返回主叫EPC侧情况。 PCRF向SBC上报主叫EPC侧情况。

P-CSCF将INVTIE消息转发给主叫侧S-CSCF（因为在用户注册时，P-CSCF已经知道用户在哪台S-CSCF上）

6~8 主叫侧预留无线侧资源，MME在消息8中携带主叫位置信息（TAI+E-CGI），与资源预留情况 9~10 11~12 13~16

主叫侧根据用户在HSS签约的IFC完成业务触发，主叫AS进行被叫号码补齐 +86，之后主叫S-CSCF通过查询ENUM/DNS获取被叫I-CSCF地址并将呼叫请求发送至被叫I-CSCF。 17~18

被叫I-CSCF查询HSS获取被叫用户注册的S-CSCF。

19 被叫触发至VoLTE AS，基本呼叫和补充业务触发完成后触发SCC AS。 20 SCC AS进行被叫域选择，向HSS查询T-ADS信息。 21~22 24~26 28~34 35~42 44~50 51~59 60~68 69~71 72~74 75~81 82~88

融合HLR/HSS通过IDR消息向MME(T)查询被叫用户的T-ADS信息。 呼叫请求转发至被叫UE。 被叫侧申请通话资源。

183响应按照呼叫路径被转发至主叫。 主叫侧根据协商结果修改资源申请。

主叫UE通过空口流程获知通话资源预留成功，向被叫侧发起UPDATE，其中的precondition参数主叫侧为被叫UE通过空口流程获知通话资源预留成功，向主叫返回200 OK，其中的precondition参数主被叫均为主被叫双方完成呼叫信令流程，双方开始通话。

主叫侧挂机，UE向SBC发送BYE消息，之后消息转发至被叫SBC和UE。 主叫侧进行资源释放。 被叫侧进行资源释放。

23 HSS向SCC AS返回T-ADS信息，包含IMS Voice over PS supported。

27 被叫UE返回183其中包含被叫SDP信息，precondition参数中主叫侧和被叫侧均为none。

sendrecv，被叫侧为none。 sendrecv。

前台VOLTE业务正常起呼信令流程图

主叫侧信令流程

被叫侧信令流程

前台信令流程详解：

1. 主叫发INVITE消息，触发主叫RRC建立过程，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码

等。之后2条信令的是进行鉴权请求；

2. 主叫建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载。

3. 核心网侧收到主叫的INVITE消息以后，给主叫发送INVITE的应答消息，INVITE 100表示正在处理中； 4. 主叫建立QCI1的数据无线承载，用于承载语音数据，使用UM方式。

5. MME向被叫所在的eNodeB发起寻呼；

6. 被叫响应paging消息并触发RRC建立流程；

7. 被叫侧建立SRB2信令无线承载，QCI9默认承载和QCI5 SIP信令无线承载。 8. 在被叫建立完成QCI5后，UE接收到INVITE消息； 9. 被叫对INVITE消息的响应；

10. 被叫方通知主叫方，自己所支持的媒体类型和编码； 11. 被叫建立QCI1的数据无线承载； 12. 主叫收到被叫的INVITE183消息；

13. 网络通过被叫上发的INVITE183消息携带的信息给主叫下发modify请求；

14. 主叫收到INVITE183消息以后，发送确认消息PRACK，启动资源预留过程，被叫收到主叫的PRACK消息后，发

送确认消息PRACK 200，启动资源预留过程；

15. 主叫收到被叫的PRACK200以后，发送UPDATE消息，标明资源预留成功。被叫收到主叫的UPDATE消息后，得

知主叫UE的资源预留成功，被叫发送UPDATE200，标明被叫资源预留成功；

16. 被叫发送INVITE180，被叫振铃，主叫放回铃音。随后主叫收到INVITE180后主叫终端开始放回铃音；

17. 被叫摘机，被叫向主叫发送INVITE OK 200，主叫收到INVITE OK 200得知被叫已摘机，并回复INVITE ACK消息表

示确认，当INVITE ACK被回传到被叫后通话正式建立。

炎强VOLTE业务正常起呼信令流程图

1. 主叫有空闲态起呼将默认（QCI5/9）后，UE通过QCI5将INVITE消息发送到SBC，SBC回复100 trying给UE，表

示响应本次INVITE请求；

2. 主叫专载建立过程（专载建立流程可以参照volte业务完整信令流程中2到12步说明）； 3. 主叫专载建立完成后，主叫SBC通过CSCF将INVITE请求转送到被叫；

4. 被叫SBC给被叫UE下发invite请求（若被叫初始为空闲态则MME下发paging消息到被叫UE，被叫UE成功建

立了RRC连接和默认承载后才能收到INVITE消息）； 5. 被叫UE收到接收到INVITE消息后回复trying 100响应；

6. 被叫UE返回INVITE 183，被叫SBC收到invite 183后触发被叫专载建立（与主叫专载建立流程一致，不累赘说

明）；

7.被叫上发的INVITE 183通过CSCF转送到主叫SBC，随后主叫SBC发起modify流程；

8．主被叫PRACK流程及UPDATE流程；

10.被叫ringing180 及摘机流程；

博瑞得VOLTE业务起呼流程：

博瑞得系统中，综合话单可以看到S11（SGW-MME）和S1-MME（eNodeB-MME）、S1-U（eNodeB-SGW）、S6a（HSS-MME）口消息，所以综合话单主要作用是查询无线承载的建立、修改、删除及保存情况同时还能看到每个时段UE占用小区（ECI）及相应时段的切换序列（对于各种投诉能大致定位到出现问题的小区及相关的异常信令，其中S1-U口中的消息能看到响应时段的数据业务情况但如果是SIP信令则不能解码）。 如下话单（主叫）：

1. SGW给MME发送Create Bearer Request；

2. 随后MME给eNodeB下发专载建立请求；

3. 专载建立成功后MME给SGW回复Create Bearer Response；

上述1、2、3步可以对应VOLTE业务完整信息流程中的6、7、8流程 4. SGW给MME发送Update Bearer Request；

5. 随后MME给eNodeB下发专载修改（modify）请求；

6. 专载建立成功后MME给SGW回复Update Bearer Response；

上述4、5、6步可以对应VOLTE业务完整信息流程中的48、49、50流程

被叫的博瑞得信令及话单与主叫大同小异，只是没有专载修改（modify）的步骤，不在累赘说明。

eNodeB信令中 VOLTE业务起呼流程

eNodeB侧信令主要是RRC层的消息及S1AP口的消息，所以eNodeB侧信令与博瑞得消息大致相同，但会多了UU口的消息，具体信令流程如下（主叫）：

1. MME给eNodeB下发E_RAB SETUP REQUEST(Activate dedicated EPS bearer context request)（专载建立请求）； 2. eNodeB根据E_RAB SETUP REQUEST(Activate dedicated EPS bearer context request)携带的消息生成重配消息下发

给eNodeB；

3. UE完成专载建立；

4. eNodeB回复专载建立情况；

5. UE通过RRC的上行直传消息将NAS将Activate dedicated EPS bearer context accept发生到eNodeB； 6. eNodeB将携带Activate dedicated EPS bearer context accept的NAS消息转送到MME后专载建立完成；

1到6步为eNodeB和UE侧专载建立流程，7到12步为eNodeB和UE侧专载修改（modify）流程大致与专载建立过程相同，不再累赘说明。

VOLTE业务被叫eNodeB侧信令流程相比主要信息流程上了专载修改（modify）过程，不再累赘说明。。

前台VOLTE业务正常挂机信令流程图

前台VOLTE业务正常挂机信令详解：

1. 主叫发起挂机流程，上发BYE REQUEST; 2. 被叫收到主叫发生的BYE REQUEST；

3. 被叫上发BYE OK 200表示确认本次挂机请求；

4. 网络收到被叫的回复的BYE OK 200后给被叫终端下发专载拆除消息； 5. 主叫收到被叫上报的BYE OK 200消息；

6. 主叫网络收到被叫上报的BYE OK 200消息后给主叫终端下发专载拆除消息。

炎强volte业务挂机流程：

1.主叫侧挂机，UE向SBC发送BYE消息，之后消息转发至被叫SBC和UE。 2.主叫侧进行资源释放。 3.被叫侧进行资源释放。

博瑞得VOLTE业务挂机流程：

博瑞得VOLTE业务挂机综合话单流程：

1.SGW给MME发送Delete Bearer Request； 2.随后MME给eNodeB下发专载释放请求；

3.专载释放成功后MME给SGW回复Delete Bearer Response；

博瑞得VOLTE业务挂机信令流程：

初始注册及重注册信令流程：

一、终端完成LTE下的附着过程：

携带IMS APN，发起AttachReq请求，在LTE下完成相应的鉴权处理，位置更新，并建立QCI=5的默认承载，携带P-CSCF的地址给终端用户；

二、终端通过默认承载发送IMS注册消息到IMS网络侧：

进行终端对于IMS网络，网络对终端的双向鉴权，完成鉴权处理，并从HSS中获取用户的业务信息，完成用户的注册过程。

UE1.Attach RequesteNBMMES/PGWPCRFHSSI-CSCFS-CSCFTAS2.Attach Request3.Identity Request4.Identity Response5.Authentication/Security6.Authentication/Security7.Update Location Request(Homogeneous Support of IMS Voice over PS Sessions)8.Update Location Answer9.Create Session Request(APN=CMNET)10.CCR11.CCA(QCI=9)12.Create Session Response(QCI=9)13.Initial Context Setup Request/Attach Accept14.RRC Connection Reconfiguration/Attach Accept15.RRC Connection Reconfigurationn Complete16.Initial Context Setup Response17.Direct Transfer/Attach Complete18.Attach Complete19.Modify Bearer Request21. UE decide to create IMS PDN connection20.Modify Bearer Response22. PDN Connectivity Request(APN=IMS, PCO:P-CSCF addr )23.Create Session Request(APN=IMS, PCO: P-CSCF addr request)24.CCR25.CCA(QCI=5)26.Create Session Response(QCI=5, PCO:P-CSCF addr)27.Initial Context Setup Request/PDN Connectivity Accept(PCO: P-CSCF addr)28.RRC Connection Reconfiguration/PDN Connectivity Accept(PCO:P-CSCF addr)29.RRC Connection Reconfigurationn Complete30.Initial Context Setup Response31.Direct Transfer32.PDN Connectivity Complete33.Modify Bearer Request34.Modify Bearer Response35.REGISTER (IMPI=IMSI@ims.mnc000.mcc460.3gppnetwork.org, IMPU=sip:IMSI@ims.mnc000.mcc460.3gppnetwork.org)36.REGISTER37.UAR38.UAA(S-CSCF cap set)39.REGISTER40.MAR41.MAA(RAND,IK CK,XRES,AUTN)42.401(RAND,IK CK,XRES,AUTN)43.401(RAND,IK CK,XRES,AUTN)44.401(RAND,AUTN)45.REGISTER (RES)46.REGISTER (RES,STN-SR)47.UAR48.UAA(Stored S-CSCF)49.REGISTER (RES,STN-SR)50.SAR51.SAA(user profile)52.REGISTER(original REGISGTER message)53.200 OK54.200 OK55.200 OK56.200 OK57. UDR58.UDA(SRVCC capability)59.MESSAGE (ATU-STI,C-MSISDN)60.MESSAGE (ATU-STI,C-MSISDN)61.200 OK[to MESSAGE]62.200 OK[to MESSAGE]63.PUR(STN-SR).PUA65.IDR(STN-SR)66.IDA

1~2 UE发起EPC附着请求。

3~6 EPC网络对用户进行认证鉴权。

7~8 认证通过后，MME向HSS进行用户的EPC位置更新，并告知HSS IMS Voice homogeneous support。 9 MME根据用户签约发起默认PDN连接建立（默认APN为CMNET APN） 10~11 SAE GW向PCRF获取默认规则，PCRF返回QCI=9。 12~20 完成默认承载建立后续流程。

21 UE在发起IMS注册前需要建立IMS PDN连接。

22 UE发起新的PDN连接建立请求，其中携带APN为IMS，PCO获取P-CSCF地址。

23 MME向SAE GW发起PDN连接建立请求，其中携带APN为IMS，PCO获取P-CSCF地址。 24~25 SAE GW向PCRF获取默认规则，PCRF返回QCI=5. 26 SAE GW返回PDN连接建立响应，其中包含P-CSCF地址 27~34 完成IMS PDN连接建立后续流程

35 UE通过IMS PDN默认承载发起IMS 注册请求，其中包含通过IMSI导出的IMPU/IMPI 36 SBC中的ATCF功能决定锚定后续呼叫，分配一个STN-SR指向自己，并将STN-SR携带在注册请求中发送到S-CSCF，注册请求经SBC转发至I-CSCF；

37~38 I-CSCF向HSS发起查询，HSS返回S-CSCF的能力集

39 I-CSCF根据HSS返回的能力集选择S-CSCF并向其转发注册请求 40~41 S-CSCF向HSS查询用户的鉴权信息

42~44 S-CSCF向UE返回401响应，发起鉴权挑战 45~49 UE计算鉴权结果后再次发起注册请求

50~51 UE鉴权通过，S-CSCF向HSS获取用户签约信息

52~53 S-CSCF向AS发起第三方注册，并在其中携带UE发起的核心网注册请求消息，并携带SBC分配的STN-SR 54~56 S-CSCF向UE返回注册成功响应

57~58 SCC AS从HSS中读取用户数据，判断终端是否支持SRVCC

59~62 AS根据三方注册消息中的ATCF management URI向其发送MESSAGE请求，包含ATU-STI和C-MSISDN 63~ SCC AS需要比较本地配置的STN-SR和三方注册请求中携带的STN-SR是否一致，如果不一致，则更新HSS中存储的STN-SR

65~66 HSS向MME推送STN-SR

网元介绍：

CSCF按其位置和功能又可分为 P/S/I 三种类型其中： P-CSCF(Proxy CSCF)：是IMS中与用户的第一个连接点， 提供代理（Proxy）功能，即接受业务请求并转发它们；P-CSCF也可提供用户代理（UA）功能，即在异常情况下中断和产生SIP会话；

S-CSCF(Serving CSCF)：S-CSCF在IMS核心网中处于核心的控制地位，负责对UE的注册鉴权和会话控制，执行针对主叫端及被叫端IMS用户的基本会话路由功能，并根据用户签约的IMS触发规则，在条件满足时进行到AS的增值业务路由触发及业务控制交互；

I-CSCF(Interrogating CSCF)：类似IMS的关口节点，提供本域用户服务节点分配、路由查询以及IMS域间拓朴隐藏功能；I-CSCF是归属IMS网络的统一的初步入口点。

P/S/I-CSCF在物理实体上完全可以是合一的，在实际组网时，其划分和部署需综合考虑对IMS业务接入方式、CSCF的容量、能力及用户业务量需求等因素。 HSS（The Home Subscriber Server ）：HSS是归属网络中保存IMS用户的签约信息，包括基本标识、路由信息以及业务签约信息等集中综合数据库，位于IMS核心网络架构的最顶层，HSS中保存的主要信息包括： 1、IMS用户标识（包括公共及私有标识）、号码和地址信息 2、IMS用户安全上下文：用户网络接入认证的密钥信息

3、IMS用户的路由信息：HSS支持用户的注册，并且存储用户的位置信息 4、IMS用户的业务签约信息：包括其他AS的增值业务数据

前台初始注册及重注册信令流程：

1.终端向网络发生Register Request（首先要完成attach请求，并建立起QCI5的PDN连接后才能发生SIP消息），该

消息携带用户的IMSI号及当前的VPI6地址，当Register Request消息Authorization头字段nonce消息携带的值为空值时，本次注册为初始注册消息；

2.网络回复Register unauthorized 401消息，该消息中携带CSCF的地址，及相关的加密方式和密钥。

3.终端获取Register unauthorized 401消息后发起重注册的Register Request，

4.网络回复register ok 200 表现初始注册完成，该消息携带了周期注册是的时间如下截图expires=3600单位秒；

5.发起订阅通知请求，将被订阅的信息发送给订阅方。一般与SUBSCRIBE请求配合使用，SUBSCRIBE发起对信息的订阅，NOTIFY将所订阅的信息发送给订阅方。

SUBSCRIBE是一个用来请求对方节点的当前状态以及后续状态变化的请求方法,从网络订阅消息，NOTIFY是用于向服务器请求返回当前状态消息。

6.下一次周期注册则按照register ok 200中expires携带的值减去600为周期进注册。（周期注册信令相比初始注册少了1和2步，不在累赘说明）

炎强初始注册及重注册信令流程：

esvrcc信令流程

UE Source E-UTRAN Source MME MSC Server/ MGW Target MSC Target SGSN Target BSS S-GW / PDN GW IMS 1. Measurement reports 2. Decision for HO 3. Handover Required 4. Bearer Splitting 5.PS to CS Req 6.Prep HO Req 7. HO Request/Ack 8.Prep HO Resp 9. Establish circuit 10. Initiation of Session Transfer (STN-SR or E-STN-SR) 11. Session transfer and Update remote end 12. Release of IMS access leg 13.PS to CS Resp 14. Handover Command 15. HO from EUTRAN command 16. UE tunes to GERAN 17. HO Detection 18. Suspend (see TS 23.060) 18. Suspend Request / Response 18. Suspend 19. HO Complete 20.SES (HO Complete) 21. ANSWER 22. PS to CS Complete/Ack 23a. TMSI Reallocation 23b.UpdateLoc 24. Subscriber Location Report 22a. Bearer handling and suspension HSS/ HLR GMLC 1.用户终端向E-UTRAN发送测量报告

2.基于用户终端的测量报告，E-UTRAN决定触发一个到GERAN的SRVCC切换

3.源E-UTRAN向源MME发送切换需求（目标ID，源到目标的透明容器，SRVCC切换指示），E-UTRAN在源到目标透明容器中为 CS域设置“Old BSS to New BSS information IE”,SRVCC切换指示向MME表明目标只有CS能力，因此这是一个只面向 CS域的SRVCC切换操作。该消息包含一个 UE在目标蜂窝中PS服务不可用的标识

4.基于与语音承载相关联的QCI和SRVCC切换指示，源MME将语音承载从非语音承载中分离出来，并对MSC Server启动语音承载的PS-CS切换流程

5.MME向MSC Server发送一个SRVCC PS to CS Request消息(国际移动用户标识符IMSI，目标 ID，STN-SR,C-MSISDN，源到目标透明容器， MM上下文，紧急标识)，如果正在进行的是紧急会话，则消息中将包含紧急标识。对于 UE在受限服务模式下操作的情况，MME也将在请求消息中包含设备识别符。如果认证过的 IMSI和C-MSISDN可用的话，也被包含在请求消息中。MME从HSS接收在E-UTRAN附着流程期间下载的C-MSISDN和STN-SR作为 Subscription profile的一部分。MME上下文包含相关的安全信息，CS安全密钥由MME从E- UTRAN/EPS域密钥派生，并在MM上下文中发送

6.MSC Server通过向目标MSC发送准备切换请求(Prepare Handover Request)消息，使 PS-CS切换请求和MSC之间的切换请求实现互操作。MSC Server分配一个默认SAI作为在到目标MSC的接口上的源ID。并用 BSSMAP为准备切换请求进行封装。 NOTE1:SAI的默认值是在MSC中配置的，它允许release 8及其后的BSC识别SRVCC切换的源是E-UTRAN.为了保证在目标BSS中准确的统计量，默认的SAI应该跟UTRAN中使用的SAIs区别开来。 SAI:Service Area Identifier

7.目标MSC通过与目标BSS交换切换请求/确认消息来进行资源分配

8.目标MSC向MSC Server发送一个准备切换响应消息(Prepare Handover Response)

9.在目标MSC和与MSC Server关联的MGW 之间建立电路连接。例如使用ISUP IAM和 ACM messages. ISUP IAM:ISDN User Part Initial Address Message

10. 对于非紧急会话，MSC Server用STN-SR 启动会话迁移(Session Transfer)。例如：向 IMS发送一个ISUP IAM(STN-SR)。对于紧急会话，MSC Server用本地配置的E-STN-SR 启动会话迁移。在会话迁移过程中执行标准的IMS业务连续性或紧急IMS业务连续性。 NOTE2:该步骤可在8后就开始。 NOTE3:如果MSC Server正在使用一个ISUP 接口，则在用户平面(subscriber profile)包含的CAMEL触发器对于优先切换不可用的情况下，非紧急会话的会话迁移可能失败

11.远端(remote end)在会话迁移流程期间被 CS access leg的SDP更新。此时，VoIP分组的下行数据流被交换到CS access leg

12.源IMS access leg被释放。 NOTE4:Step 11、12与13相

13.MSC Server发送一个SRVCC PS to CS响应消息(目标到源透明容器)到源MME

14.源MME发送一个切换命令(Handover Command)消息到源E-UTRAN，该消息只包含语音组件的相关信息 15.源E-UTRAN发送一个Handover from E- UTRAN Command 消息到UE 16.UE调整(tunes to)到GERAN

17.目标BSS进行切换检测(Handover Detection).UE通过目标BSS发送一个切换完成(Handover complete)消息到目标MSC，如果目标MSC不是MSC Server,则目标MSC 发送一个SES(Handover Complete)消息到 MSC Server 18.UE开始挂起(Suspend)流程。从GUTI中派生TLLI和RAI对。这将触发目标SGSN向源 MME发送挂起通知消息，MME向目标 SGSN返回挂起确认。 NOTE5:MME也许不能从接收到的P-TMSI和 RAI对中派生出GUTI，因此它可能不能辨识出与挂起通知消息相关联的是哪一个UE的上下文，在这种情况下，承载也将被在step 22a去激活或挂起 19.目标BSS向目标MSC发送切换完成 (Handover Complete)消息

20.目标MSC发送一个SES(Handover Complete)消息到MSC Server.语音电路在 MSC Server/MGW中完成连接 21.用到MSC Server的ISUP Answer 消息完成建立流程

22.MSC Server发送一个SRVCC PS to CS Complete Notification到源MME，通知它 UE已经到达目标侧。源MME发送一个 SRVCC PS to CS Complete Acknowledge 消息到MSC Server进行应答

22a.MME修改语音承载，并设置PS to CS 切换指示器，移除其他的GBR承载，MME还将到S-GW和P-GW的非GBR承载挂起，将所有EPS承载的S1-U承载释放。所有GBR承载通过在MME、S-GW、P-GW中删除GBR承载上下文而被去激活。至于GTP-based s5/s8,S-GW通过发送Modify Bearer Request Message请求P-GW删除所有GBR承载上下文。 GBR:Guaranteed Bit Rate PCC:Policy and Charging Control

23a.如果IMSI在VLR(拜访位置寄存器)中未知，则MSC Server将执行到HSS/HLR的 MAP Update Location,一种例外是不存在认证过的IMSI(例如对于一个用认证IMSI的紧急会话服务)

23b.如果MSC Server执行MAP Update Location，并且如果多个MSC/VLR为相同的 LAI服务，则MSC Server用一个带有它自己的网络资源标识符(NRI)的非广播LAI执行到 UE的TMSI重分配。 LAI:Location Area Identity 24.对于紧急服务会话，在切换完成以后，源MME或MSC Server可能向源或目标侧关联的GMLC(Gateway Mobile Location Center)发送一个MSC Server 标识的用户位置报告(Subscriber Location Report)

在CS语音会话结束后，如果UE仍在GERAN中，则UE 将通过向SGSN发送一个路由区域更新请求(Routing Area Update Request )来恢复PS服务。更新类型依赖于GERAN网络的操作模式，如果UE在CS语音会话结束后已经返回到E-UTRAN，则UE将通过发送 TAU(Track Area Update)到MME来恢复PS服务。 MME将通知S-GW和P-GW恢复挂起的承载

前台esrvcc信令流程：

1. 2. 3. 4. 5.

UE上发B2测量MR； 下发esrvcc切换命令；

UE解析mobility from eutra command消息获得切换目标小区的信息； UE接收GSM小区的物理信道重配消息； TMSI重新分配后esrvcc完成。

炎强esrvcc信令流程：

1. 2. 3. 4. 5. 6.

eNodeB给MME上发handover required携带：ps-service-not-available； MME给MSC上发SRVCC PS TO CS REQUEST，当MSC回复SRVCC PS TO CS RESPONSE后说明GSM网络已准备成功； 源MME发送一个切换命令(Handover Command)消息到源E-UTRAN，该消息只包含语音组件的相关信息； LTE通话迁移到GSM网络；

MSC Server发送一个SRVCC PS to CS Complete Notification到源MME，通知它 UE已经到达目标侧； LTE侧会话拆除。

博瑞得esrvcc信令流程：

博瑞得esrvcc综合话单流程：

二．volte常用和关注的无线参数及定时器说明

定时器常用配置

参数英文类别 名 增加该参数的取值，可以提高UE 该参数表示UE侧控制RRC connection 的RRC connection establishmentestablishment过程的定时器。在UE发送过程中随机接入的成功率。但是，当RRCConnectionRequest后启动。 UE选择的小区信道质量较差或负载 在超时前如果：1.UE收到RRCConnectionSetup较大时，可能增加UE的无谓随机接或 RRCConnectionReject；2.触发入尝试次数。 T300 Cell-reselection过程；3.NAS层终止RRC 减少该参数的取值，当UE选择connection establishment过程。则定时器停止。 的小区信道质量较差或负载较大时，接入类定时器 如定时器超时，则UE重置MAC层、释放MAC层可能减少UE的无谓随机接入尝试次配置、重置所有已建立RBs（Radio Bears）的RLC数。但是，可能降低UE的RRC 实体。并通知NAS层RRC connection establishmentconnection establishment过程中随失败 机接入的成功率 T302用于控制eUTRAN拒绝UE的RRC连接建立到UE下一次发起RRC连接建立过程的时间。UE接收T302 RRCConnectionReject信息后得到其中的参数waitTime，定时器T302的取值由waitTime决定。 立的RRC不能及时被建立，影响用户感知 N310设置的越大，UE对RL失步的判断就越不敏感，可能造成本来不可 该参数表示接收连续“失步（out-of-sync）”指用的RL迟迟不能被上报RL失步进而N310 示的最大数目，达到最大数目后触发T310定时器的无法触发后续的恢复或重建操作；该启动。 参数设置过小，会造成不必要的RRC重建 T310设置的越大，UE察觉RL下行 UE的RRC层检测到physical layer problems时，失步的时间就越长，此时间内相关资掉线类定时器启动定时器T310.该定时器运行期间，如果无线链路及常量 T310 恢复，则停止该定时器，否则一直运行。该定时超时，作或响应新的资源建立请求，影响用认为无线链路失败。 户的感知。该参数设置过小，会造成不必要的RRC 重建 N311设置的越大，越可以保证RL恢复下行同步的可靠性，但相应的也 该参数用于设置停止T310定时器所需要收到的最N311 大连续“in-sync”指示的个数 T310超时，就会触发RL FAILURE原因的连接重建流程； n10} 会增加导致T310超时的风险，一旦n1 n3, n4, n5, n6, n8, ENUMERATED {n1, n2, 源无法及时释放，也无法发起恢复操1000ms ms500, ms1000, ms2000} ms50, ms100, ms200, ENUMERATED {ms0, n20} n20 n3, n4, n6, n8, n10, ENUMERATED {n1, n2, 设置过大会造成UE RRC连接拒绝后时长过大，使本能够再次建2s INTEGER (1..16) ms1500,ms2000} ms1000, 1000ms ms400, ms600, ms200, ms300, ENUMERATED { ms100, 功能描述 对网络质量的影响 议 范围 取值建3GPP协议规定的取值 在“E-UTRAN内切换”和“切换入E-UTRAN的系统ENUMERATED {ms50, 间切换”的情况下，UE在收到带有 用于系统内切换，该值设置过大会T304 For 切换类定时器 Intra-Lte 启动定时器，在完成新小区的随机接入后停止定时RRC连接重建过程 器；定时器超时后UE需恢复原小区配置并发起RRCspare1} 重建请求 设置值越大，UE进行小区选择过程中所被允许的时间越长， RRC T311用于UE的RRC连接重建过程，T311控制UET311 开始RRC连接重建到UE选择一个小区过程所需的时间，期间UE执行cell-selection过程。 Connection Reestablishment过程越滞后；如果该参数设置过小，可能在某些链路可以被挽救的情况下，却由于定时器设置不合理而进入IDLE状态，引起掉话，严重影响用户感知。 增加该参数的取值，可以提高UE的RRC connection 重建立类定时器 在UE上传RRCConnection 信道质量较差或负载较大时，可能增ReestabilshmentRequest后启动。在超时前如果收加UE的无谓随机接入尝试次数。减T301 到UE收到RRCConnectionReestablishment或少该参数的取值，当UE选择的小区RRCConnectionReestablishmentReject，则定时器停信道质量较差或负载较大时，可能减止。定时器超时，则UE变为RRC_IDLE状态 少UE的无谓随机接入尝试次数。但是，可能降低UE的RRC connection re-establishment过程中随机接入的成功率 ms1500,ms2000} ms1000, 600ms ms400, ms600, ms200, ms300, re-establishment过程中随机接入的成功率。但是，当UE选择的小区ENUMERATED { ms100, ENUMERATED {ms1000, ms3000, ms5000, 1000ms ms10000, ms15000,ms20000, ms30000} ms1000,ms2000, “mobilityControlInfo”的RRC连接重配置消息时导致切换失败无法及时回退并发起500ms ms200, ms500, ms100, ms150,

关于inactivity定时器说明：

1) 中兴：tUserInac：该参数为UE不活动定时器，当UE不活动时长达到10s基站将会发起RRC Release。对建立

了QCI1的UE会加多50秒，共60秒。

2) 爱立信：UE RRC释放时间由tInactivityTimer+nactivityTimerOffset决定的，原来设置是10+0秒，现针对

VOLTE采用特殊设置，即tInactivityTimer+nactivityTimerOffset=10+30(QCI1\\2\\5)=40S,而QCI9仍然是10秒。

UE定时器：Tcall、Tqos

Tcall：UE设置为10s。当UE上发INVITE请求后启动，10s内如果终端未收到网络回复的trying 100时该定时器超时，终端转CSFB继续通话请求；

Tqos：UE设置为6s。当UE上发INVITE请求，网络回复trying100后6s若未收到网络下发的专载建立请求该定时器超时，终端转CSFB继续通话请求。

测量参数常用值

参数 A1(10) A2(20) A2(32) A2(40) A3(50) A3(70) A4(288) A5(80) B2(1010) GERAN B2(QCI1) 功能 关闭频间、系统间测量 开启频间测量 打开系统间测量(语音业务) 开启重定向测量 基于覆盖的同频切换测量 基于覆盖的异频切换测量 基于覆盖的异频切换测量 基于覆盖的异频切换测量 基于覆盖的系统间切换判决 基于覆盖的系统间切换本系统判决门限(语音业务) 事件判决的RSRP门限(dBm) 室内E频-106，室外D频-96，室外F频-88 室内E频-110，室外D频-100，室外F-92 室内E频-110，室外D频-104，室外F-104 小于等于-122 / / -96 第一门限-103，第二门限-100 第一门限-116，第二门限-90 -116 Offset / / / / 2 2 / / / hysteresis 0 0 0 0 1 1 0 0 0 timeToTrigger 320ms 320ms 320ms 320ms 320ms 320ms 320ms 320ms 0ms / / / VOLTE用户系统内切换继承数据业务用户的切换方式，主要区别在于异系统切换，数据业务采用盲重定向，而VOLTE采用基于A2+B2的eSRVCC切换方式，故合理地配置A2和B2门限能有效加强VOLTE网络的稳定性，切换过早容易引起不必要的eSRVCC，降低MOS值影响用户感知，在接通阶段也容易引起bSRVCC导致未接通，切换过晚容易造成RLF导致掉话。现场经过长期验证，配置B2本系统门限为-116，异系统门限-90为最佳，异系统起测门限当前因受限终端测量能力，设置频间测量与系统间测量同时起测，A2/B2具体配置如下： A2(20)：满足该门限开启频间测量

A2(32)：满足该门限开启系统间测量(语音业务)

频间测量和系统间测量是否同时下发：该参数当前设置为“频间测量和系统间测量同时下发”，即当终端满足A2(20)或A2(32)其中一个门限的时候，将同时开启频间和系统间测量。

B2(1010)：满足该门限基站可发起系统间切换判决

PerQCI测量配置开关：该开关配置为打开，可区分QCI单独配置B2本系统门限

打开上述开关后，perQCI异系统测量配置生效，可针对QCI1单独配置B2门限，而数据业务如果采用B2策略则依然采用B2(1010)配置的门限，对于VOLTE终端基站将会选取B2(1010)与GERAN B2事件RSRP门限的较大值作为B2

测控下发。

三、未接通典型案例

1.流程冲突问题-S1切换与专载建立、修改冲突

UU关键：前面伴有S1切换、TAU，PRACK 200后，未见下发Modify EPS bearer context request，随后收到INVITE 503。 案例说明：

主叫发起呼叫请求，被叫正常响应，主叫呼叫流程走到IMS_SIP_PRACK 200后，未见下发Modify EPS bearer context request，随后收到网络侧下发的IMS_SIP_INVITE 503。

案例分析

查看博瑞得综合话单的S11口消息中Create Bearer（专载建立）或者Update Bearer（专载修改）失败的原因为110:Temporarily rejected due to handover procedure in progress。

初步分析是在爱立信MME上发生流程冲突，MME在处理S1-handover的时候收到SAEGW下发的update bearer request，当MME进行S1 HANDOVER处理的同时发生MME改变的时候，收到Update Bearer Request，MME会拒绝Update Bearer Request，并带cause code 110:Temporarily rejected due to handover procedure in progress。建专载时有create bearer 和 update bearer 两个流程段都会在S1切换的过程中发生冲突；S1切换会成功，但是专载建立会失败。

解决方案：（已定位，未解决）

SGW版本16a升级（尚未升级，预计2月份会升级），优化修改SGW与MME的处理流程，让源MME记录的专载信息可以转达到目标MME。

2.流程冲突问题-S1与TAU流程冲突（在跨POOL的TAU未完成前发S1切换都会发生）

UU关键：跨POOL的TAU未完成之前，发起”S1切换准备”10秒内起呼发INVITE，收到trying 100后3秒左右收到invite 503。 案例说明：

S1切换后ue进行TAU流程，在TAU流程尚未完成前再次发起S1切换请求，但该请求MME一直未响应。10s后eNodeB设置的S1 handover command等待定时器超时。在此过程中UE起呼MME下发专载建立请求，eNodeB由于正在进行S1切换，所以eNodeB回复的response消息均为：S1 Intra system Handover triggered，在MME专载建立等待定时器3s超时后专载建立失败网络下发503导致未接通。

案例分析：

MME在TAU尚未完成时，eNodeB发起的S1切换请求MME是自动丢弃不作处理，而eNodeB S1 handover command等待定时器超时前eNodeB对MME下发的专载建立、专载修改、专载删除等请求均会回复S1 Intra system Handover triggered，导致异常事件发生。 博瑞得信令如下：

CTS信令如下：

解决方案：（已定位，未解决） 1.MME流程优化（尚未有进展）

2.eNodeB S1 handover command等待定时器优化，暂时规避方案从10秒降到1.5秒，尚未推广，跨POOL的TAU完成时间有些会很长大于3秒（大于专载建立时长3秒），所以不能从根本解决该类问题。 3.无线切换优化（减少跨pool的乒乓或频繁切换）

3.PCRF功能问题-PCRF未响应AAR导致modify未下发

UU关键：前面没有有S1切换、TAU，PRACK 200后，未见下发Modify EPS bearer context request，随后收到INVITE 503。

案例说明：

UE在16-06-19 11:11:43.209上发invite请求，无线环境良好，rsrp为-91，sinr为20，信令交互到主叫收到网络侧下发PRACK200，主叫UE没有上发update，相隔6S之后收到网络侧invite503（Content = Warning: 399 00000.00000.A.005.412.228.255.255.00045.00000003 \"Media Bearer Lost\" ） ，软件记录未接通1次。经分析，主要是由于主叫信令异常，主叫上发prack之后，没有收到网络侧下发LTE NAS-->Modify EPS bearer context request告知被叫信息导致主叫UE没有上发upate。

案例分析：

前台底层信令分析定位

通过QCAT分析，主叫建立的专载TFT为空，在未收到modify消息时，主叫终端IPV6地址全为空值，终端不会上发update消息。收到503后，终端发起csfb请求。

炎强信令平台分析定位

炎强信令记录中无MME侧信令记录，未能定位MME是否下发Modify EPS bearer context request消息，但从eNodeB侧信令中未找到Modify EPS bearer context request消息。

已定位为PCRF内部进程交互机制瑕疵。当单用户PCRF的Dialog进程处于关闭瞬间，会导致PCRF接收到的AAR消息被丢弃，最后导致SBC 503。

解决方案：（已定位，已做规避方案）

1、通过开启Graceful Dialog Shutdown功能解决该问题，但解决不了。

开启后在单个用户的Dialog进程关闭过程中接收的消息进行Buffer处理，避免丢弃导致的呼叫失败。但该功能开启后PCRF未响应AAR的情况仍有发生。

2、11月集团考核前，PCRF打了补丁，将单用户PCRF的Dialog进程处于关闭瞬间的间隔由1s拉长到5s，后该类问题未见复现，但该方案并未能从根本上解决此类问题，在被叫寻呼及专载建立时长长的时候（若183比较晚才到主叫SBC，SBC发AAR到PCRF可能刚好在5秒的瞬间），也有可能出现该情况。

4.增值平台不转发SIP消息-彩铃彩印平台不转发ringing180导致未接通

UU关键：无线质量良好，被叫已发ringing180,但主叫没有收到。 案例说明：

在风茂街，主叫在11:33:23.425占用广州番禺区北区商业中心D-ZLH-103（RSRP:-96，SINR:21.3)发起IMS_SIP_INVITE->Request，随后信令交互至UPDATE200，一直未收到IMS_SIP_INVITE->Ringing 180，11:33:57.184主叫主动上发CANCEL，结束起呼，软件统计为未接通；对比被叫，11:33:24.720收到IMS_SIP_INVITE->Request，之后信令交互正常，11:33:25.999被叫上发IMS_SIP_INVITE->Ringing 180，11:33:57.480收到CANCEL。

案例分析：

从炎强信令来看，被叫上发的ringing180消息被交互到gzcpcsas1bhw彩印平台后不在转发到主叫SBC导致主叫接收不到ringing180消息

解决方案：

1、增值平台工程师进行排查。

2、通过对测试手机设置自动接听来规避。

5.SIP信令丢失-丢失-SAE不转发invite183

UU关键：无线质量良好，被叫已发183，但未见专载建立请求下发。 案例说明：

主叫占用广州天河D-ZLH-102小区上发invite，随后收到Trying 100 ，主叫完成专载建立，被叫收到invite，同时上发Trying 100被叫上发Invite 183，但没有收到专载建立请求，被叫再次上发Invite 183，亦没有收到专载建立请求，被叫上发Invite 580,由于专载未建立，被叫回落2G。

案例分析：

被叫UE收到invite请求后马上回复trying100请求但未见有invite183回复8S未收到专载的建立请求后UE回复580 precondition failure随后主叫invite请求被转送到MGCF被叫通过CSFB来建立通话。

从前台信令和炎强信令记录对比可以发现被叫上报的invite183并未上报到SBC，S1-U口消息中能找到被叫上报了invite 183消息。该问题初步判断为invite 183丢失被叫未触发专载建立，而invite183的丢失主要是发生在SAE到SBC之间，从S1-U口信令捉包可以确定eNodeB已正常上发SIP信令。

解决方案：

被叫invite 183丢失问题、sip信令SAE延时下发问题，这两种类问题建议核心网测试通过跟踪SAE到SBC两侧进行跟踪排查sip丢失及延时发生情况。

经排查及反馈GZSAEGW1802BEr经常出现sip信令丢失情况，SAE工程师反馈该SAEWG负荷较大，已做规避方案，但该类问题还是时有发生。

6.SIP信令丢失-SAE不转发PRACK 200信令

UU关键：无线质量良好，被叫已发PRACK 200,但主叫没有收到。 案例说明：

15:17:14.129主叫上发Invite，15:17:14.420主叫完成专载建立，15:17:15.528被叫收到Invite，经过Invite 183/PRACK,被叫占用广州华威达D-ZLH-2小区从15:17:18.725起4次上发PRACK 200，但主叫一直未能收到PRACK 200，15:17:22.177主叫收到网络下发的PRACK 500,15:17:22.257主叫上发CANCEL，软件统计为一次未接通。

案例分析：

查看炎强S1-U口信令，被叫UE连续4次上发PRACK 200到SAE，但被叫SBC一直未能收到,初步怀疑SAE未转发，主叫在17：19.278收到PRACK 500 导致未接通。

解决方案：（未定位，未解决）

SAE侧信令丢失一直未能定位具体原因，主要是因为SGW捉包较难实现，该问题尚在跟进及捉包复现中。

7. 基站功能问题(E///)-X2切换与专载释放冲突导致QCI1 DRB未拆，影响后续专载建立

UU关键：无线质量良好，起呼收到trying 100随后收到invite 503;查看上一个呼叫，发bye与切换相差不长时间，没收到DeactivateEPSBearerContextRequest。 案例说明：

主叫09:21:26.074上报invite-request（占用小区：广州从化区河滨南路D-ELH-102），网络下发trying100后紧跟下发了503（Content = Warning: 39903100.09230.A.005.405.228.255.255.00060.00000000.00000 \"BearerReleased\" ）并进行转CSFB流程。

Log名称：ATU_20161225_LTE本地网_广州_4G_VOLTE语音_{$强行归类-运营商-中国移动$}-LTE TDD_A52早忙_0x51000002_082100_MS6.lte

问题分析：

查看主叫上一个call，发现上一个call结束时(占用小区：广州从化区河滨南路D-ELH-101)，收到BYE后还未拆专载，马上就发生了切换（从广州从化区河滨南路D-ELH-101切换到广州从化区河滨南路D-ELH-102），导致专载未拆除。直到下一次起呼时一直占用广州从化区河滨南路D-ELH-102。被叫没有收到该invite-request。

综上所述，初步推断该问题点是由于上一个call专载未释放，一下个call专载不能建立，导致未接通。

前台log截图:

炎强LOG分析：

从炎强上看，主叫侧MME向ENB发 Activate dedicated EPS bearer context request，11:44:01 ENB返回 E_RABSetupResponse [RadioNetwork-cause=multiple-E-RAB-ID-instances]，其中e-RAB-ID: 7。回查上个CALL，发现并未完成专载拆除流程E_RABReleaseResponse [RadioNetwork-cause=interaction-with-other-procedure]，其中e-RAB-ID: 7，与本次CALL冲突，导致本次呼叫专载未建立成功。 上个CALL专载拆除流程-炎强log：

本次CALL专载建立流程-炎强LOG：

问题定位与解决：

流程冲突导致专载未拆，影响后续转载建立，17A版本中问题解决情况：

从升级前的例子中看到，被叫12:29:11.339收到BYE后0.3s左右发生切换，从路测log信令流程看，网络处理切换后未拆转载，导致下一个call专载建立失败未接通，截图：

17A站点测试结果如下，被叫11:25:34.406收到BYE后0.4s发生切换，从路测log上看，网络先拆被叫专载，之后处理切换，截图：

另外一个升级后的例子，结论相同：

升级后的站点未再出现DRB与切换流程冲突问题。

四、掉话典型案例

1.基站功能问题-CPU高负荷导致小区接入失败引发掉话

UU关键：多次上发MR没响应，RRC建立请求被拒，随机接入失败；查相应时段基站CC板CPU峰值利用率100%。 案例说明：

终端上发INVITE呼叫请求，主被叫正常接通，通话过程中，被叫连续向广州番禺区大学城华工宿舍楼D-ZLH-3发起RRC Connection Request，均收到RRC Connection Reject，无法接入，主被叫均发bye结束通话，导致主被叫掉话。

案例分析：

大学城华工北路与大学城内环东路，被叫占用广州内环东路和广州大学城信息楼F-ZLH-5（ECI: 1687395,RSRP=-103,SINR=2.4），向广州番禺区大学城华工宿舍楼D-ZLH-3（ECI:6911163,RSRP:-94）发起切换，未切换命令，继续行驶后信号下降拖死，在14:30:15.093发起RRC Connection Reestablish Request过程，重建未成功，手机转为空闲状态，尝试在广州番禺区大学城华工宿舍楼D-ZLH-3驻留链接回来，连续多次发起RRC Connection Request并收到回复RRC Connection Reject，无法接入，主被叫均发bye结束通话，平台统计为未满180s主被叫掉话。

问题定位：

通过CTS数据分析，在该时间段（9月2日14:30-14:15），广州内环东路和广州大学城信息楼F-ZLH-5（ECI: 1687395）向广州番禺区大学城华工宿舍楼D-ZLH-3（ECI:6911163）连续发起多次切换请求，均收到handoverPreparationFail（CauseRadioNetwork_Root_unspecified），未切换成功。

进一步通过后台提取告警及KPI指标分析，在测试时段，该站点存在“CPU过载严重告警”和 “CPU过载告警”， 根据当前版本定义的CPU过载告警和CPU过载严重告警两种，触发机制是：当CC板在20秒内，连续监测到CPU占用率大于90%时，上报“CPU过载严重告警”；连续监测到CPU占用率大于80%时，上报“CPU过载告警”：进行统计分析，在此时段存在连续26s的CPU使用率为100%情况，过载严重，导致上报“CPU过载严重告警”和 “CPU过载告警”； CPU利eNB CC板峰值CPU开始时间 结束时间 网元名称 利用率 eNB CC板平均CPU利用率 用率过载时间(秒) [LTE]CPU峰值使用率 [LTE]CPU平均使用率 [LTE]CPU使用过载比率 2016-09-02 14:30:00 2016-09-02 14:45:00 广州番禺区大学城华工宿舍楼D-ZLH(691116) 100.00% 66.00% 26 100.00% 66.00% 2.% 通常在多用户，多切换，多任务及cc板处理能力问题情况下会造成CPU过载，针对此情况进行排查： ① 排查各小区RRC连接建立最大用户数、上下行业务量、PRB利用率未出现异常，不存在高用户、高业务情况：

0416-上RRC连MR-小区空口上行业务开始时间 14:30:00 14:30:00 14:30:00 14:30:00 14:30:00 14:30:00 结束时间 14:45:00 14:45:00 14:45:00 14:45:00 14:45:00 14:45:00 小区名称 广州番禺区大学城华工宿舍楼D-ZLH-1 广州番禺区大学城华工宿舍楼D-ZLH-2 广州番禺区大学城华工宿舍楼D-ZLH-3 广州番禺区大学城华工宿舍楼D-ZLH-101 广州番禺区大学城华工宿舍楼D-ZLH-102 广州番禺区大学城华工宿舍楼D-ZLH-103 字节数（MB） 16.0997 15.9634 125.66 29.0853 36.6047 11.4244 MR-小区空口下行业务字节数（MB） 106.5194 94.1422 550.7699 198.2432 255.3205 51.2671 接建立最大用户数 99 90 166 124 104 87 RRC连接建立平均用户数 38.44 47.01 63.93 62.39 67.90 20.93 行PRB平均利用率 14.51% 12.56% 33.62% 22.71% 19.% 12.41% 0416-下行PRB平均利用率 10.87% 7.70% 26.76% 17.78% 14.13% 10.22% ② 排查小区切换指标入指标（15分钟粒度），共发生系统切换入请求次数4653，共失败916次，失败率19.69%，

未出现多切换情况，但切换入指标下降严重，其余时段正常：

③ 对各小区其余KPI指标进行对比，其余时段各项指标正常，问题时段各项指标均下降（各小区均值）：

600版本-YY-RRC连接建立开始时间 2016-09-02 14:15:00 2016-09-02 14:30:00 2016-09-02 14:45:00 结束时间 2016-09-02 14:30:00 2016-09-02 14:45:00 2016-09-02 15:00:00 成功率 99.94% 94.81% 99.98% YY-ERAB建立成功率 100.00% 99.72% 100.00% YY-无线接通率 99.94% 94.54% 99.98% YY-无线掉线率 0.04% 0.83% 0.03% YY-ERAB掉线率 0.02% 0.22% 0.02% YY-切换成功率 99.78% 99.06% 99.80% 平均噪声干扰(分贝毫瓦) -115.113 -114.973 -115.713 综上所述，通过对后台提取的各项指标分析，未出现高用户数、高业务、多切换情况，怀疑在14:40-14:45时间段存在某个小时间段业务量高度集中，站点高负荷，导致出现RRC连接无法连接、切换困难、掉话等异常现象。 解决方案：

目前对于持续CPU负荷高的站点，采用更换CCE1板（处理能力更强）的措施。

2.流程冲突-X2切换与TAU流程冲突（在跨POOL的TAU未完成前发X2切换都会发生）

UU关键：跨POOL的TAU未完成之前，发起X2切换，没收到测控的重配，随后RRC释放。最终TAU与X2切换均

失败。 案例说明：

主被叫在10:53:41.913正式建立通话，通话过程中，被叫占用广州天河区龙洞北路F-ZLH-1（ECI：6848001，RSRP：-94，SINR：-3，）上报A4事件，目标小区广州天河区筲箕窝西D-ZLH-102（RSRP：-91，跨POOL切换），切换后发起TAU流程，于10:56:30.657被叫上报A3事件，目标小区广州天河区广河高速入口D-ZLH-2（RSRP：-83），于10:56:30.935再次发起TAU请求，10:56:40.970收到网络侧下发的RRC释放和TAU被拒消息（EMMCause = (9)UE identity cannot be derived by the network），被叫在10:56:42.999发起Attach请求，软件统计为被叫一次掉话。

案例分析：

上一次跨pool切换后ue发起TAU流程，在TAU未完成前，再次发起X2切换流程，当eNodeB收到网络给源小区下发的DOWNLINK NAS TRANSPORT(Tracking area update accept)时回复MME NAS NON DELIVERY

INDICATION（ radioNetwork = 35 : TS1AP_CauseRadioNetwork_Root_x2_handover_triggered）之后不将该直传消息下发给UE。

随后目标小区上发PATH SWITCH REQUEST，请求资源的确认，但MME在TAU未完成前不响应该消息，随后eNodeB给ue下发RRCConnectionRelease导致掉话。

导致该情况发生的原因是因为MME在处理TAU流程时不处理X2切换，但eNodeB却是处理X2切换不处理TAU，MME与eNodeB的处理方式冲突。

解决方案：（已定位，部分解决）

MME16A版本升级能解决非跨pool切换后TAU与切换冲动的情况，但跨pool后TAU与切换冲突的情况仍然未能解决。EPC工程师表示接续跟进并制定解决方案。

3.流程冲突-挂机时发生跨POOL的S1切换，TAU后QCI1、5丢失

UU关键：跨POOL的S1切换之后，看TAU request与accept里面的承载状态。 案例说明：

12:31:37.091主叫上发Invite，12:31:41.703主被叫正常建立通话，通话满180S后，12:34:42.106主叫上发bye，接着在12:34:42.179主叫进行S1切换[从广州天河区棠德花园东D-ZLH-2（CI=2087252，TAC=10042)切换到广州天河区泰安北路灯杆拉远(345-2)D-ZLH-5(CI=6913845,TAC=9493)],同时发起TAU申请，12:34:44.195主叫TAU完成后，之后QCI9激活，QCI1/5被释放。12:34:43.854被叫收到bye消息，接着上发bye ok 200，主叫未能收到bye ok 200，软件统计为一次掉话。

案例分析：

炎强信令平台分析定位

炎强S1-U口消息中，被叫BYE 200OK消息已给主叫eNodeB转发，但主叫未能收到。

博瑞得平台分析（同类型问题点分析）

主叫挂机时发生了一次S1切换并发起TAU请求，但TAU Request是携带了3条激活承载，但目标MME回复的TAU accept消息中只携带了1条激活承载，QCI1和5同时被释放，由于QCI5被释放导致主叫收不到 BYE 200 OK消息。

继续分析S11口消息，发现MME回复的Delete Bearer Request的response消息中携带了异常的原因值：110:Temporarily rejected due to handover procedure in progress，承载删除被拒。

IMS、PDN连接在通话时，有两个承载，一个用于传输sip信令（QCI 5），另外一个为语音专用承载(QCI 1)。 在S1 handover过程中，信令冲突，SAE向源MME发delete bear request，响应失败，随后新MME向新SAE发起的一个modify bear request也失败了，这条modify bear request信令中同时包含EPS bear ID 6 & 7，之后MME将这两个承载都释放了。如下：

定位结果：

此案例的原因是MME在处理S1 handover 的modify流程与SAE发送 delete bear request(volte释放流程)冲突，导致delete bear request被reject。（MME处理S1切换过程中会拒绝冲突的语音专载建立，修改或删除请求） 解决方案：（已定位，未解决）

SGW版本16a升级（尚未升级，预计2月份会升级），优化修改SGW与MME的处理流程，让源MME记录的QCI5承载信息可以转达到目标MME，保持QCI5。

4.终端bug-终端不发RTP包导致掉话

UU关键：看RTP包，主叫或被叫上行或下行只要连接20秒丢RTP包，UE会主动发BYE掉话。 案例说明：

16:38:11.310主叫上发invite请求，16:38:15.953主被叫建立通话，通话未满180S，主叫主动上发bye请求，软件统计为掉话。 案例分析： 前台信令分析：

查看主叫整个通话过程中，主叫只有网络侧到UE的RTP包，被叫只有UE到网络侧的RTP包。

炎强RTP分析过程：

根据炎强平台RTP分析过程发现，从16:38:21开始主叫只有下行包没有上行包，而被叫只有上行包却没有下行包，截图如下：

分析结果：

通过对比前台log和炎强RTP过程分析结果，初步判断为终端侧不发RTP包导致本次异常事件。 解决方案：

终端厂家及芯片厂商进行跟进。

5.终端bug- T+50终端在GSM未进行周期注册T+60后初始注册

UU关键：看测试LOG，主叫发初始注册（初始注册前10分钟在2G），被叫会收到网络下发BYE（because of USER DEREGISTRATION）。 案例说明：

测试车辆在新明记餐饮附近行驶，主被叫在17:16:39.428正常建立VoLTE通话，通话过程中主叫终端没有发起attch 也没有发起IMS去激活，却在17:16:55.823发起IMS初始注册请求（占用ECI=2097133,RSRP=-82 SINR=25），随后网络侧下发IMS_SIP_REGISTER->Unauthorized 401，初始注册完成后被叫收到网络侧下发的IMS_SIP_BYE->Request（Content = Reason: Q.850;cause=31,SIP;text=\"S.gd.chinamobile.com.261.005.123.00045 CSCF released the session because of USER DEREGISTRATION\" ），主叫QCI1专载拆线，软件统计为一次主叫掉话（发起下个invite时判断）。

案例分析：

终端在15:26:53.733和16:16:54.0各发起一次IMS周期性注册，终端本应该在50min后17:06:54期间发起IMS周期性注册。但是由于上一个call是通过CSFB到GSM进行通话，且17:06:54仍然在GSM网络，未能在该时段正常发起IMS周期注册。

按CMCC规范，终端在CSFB通话结束返回LTE网络后应马上左一次周期注册，但终端在返回LTE网络后并未发起周期注册而是在T+60min期间发起了一次初始注册，后MME下发专载去激活请求，同时sbc下发bye（ontent = Reason: Q.850;cause=31,SIP;text=\"S.gd.chinamobile.com.261.005.123.00045 CSCF released the session because of USER DEREGISTRATION\"）导致掉话。

解决方案：

1、IMS:虽然终端在GSM网络返回LTE网络后未按规范发起重注册请求，但IMS是清楚终端的注册状态，该情况是

否能做规避操作。

2、终端:版本升级，HTC没有版本。N1 MAX的CR号:CR#943239, CR#997337。

6.SAE转发sip消息时延-S1-U口bye 200 ok延时导致掉话

UU关键：无线质量良好，被叫已发200 ok，但主叫隔了10多秒才收到。 案例说明：

通话满3分钟，主叫11:41:50.314发起bye，被叫收到bye并于11:41:50.926回复ok 200（bye），但主叫一直没有收到被叫回复的ok 200，挂机异常导致产生掉话事件。

直到下一次起呼，主叫才收到上一个call的ok 200（bye）：

案例分析：

炎强显示主叫SBC收到被叫回复的ok 200（bye）并转发，但S1-u口抓包显示S1-u转发延时： SBC转发ok 200（bye）记录：（SBC已发给SAE，GM口看到的是SBC到UE）

S1-U一直无转发ok 200（bye）记录，从源地址和目标地址IP可以看到，对应时间段S1-u口下行无数据包,直到下一次呼叫起呼时，11:42:08.545 S1-u才给主叫转发ok 200（bye）：

解决方案：

SAE侧信令丢失一直未能定位具体原因，主要是因为SGW捉包较难实现，该问题尚在跟进及捉包复现中。

五、esrvcc切换失败典型案例

1.esrvcc切换到不合理2G小区（特殊单点优化B2-2门限）

案例说明：

UE占用广州西区昌岗路F-ZLH-2（RSRP=-117 SINR=-3） 上报B2，随后eSRVCC至gsm小区(BCCH: 79, BSIC: 67， rxlev sub=-90)，但只接收到RR Handover Command，没有RR Physical Information下发，eSRVCC失败后重建回LTE。

案例分析：

在乐教路自东向西测试，主被叫建立通话，主叫占用广州西区昌岗路F-ZLH-2 （RSRP=-117 SINR=-3） 上报B2，随后eSRVCC至gsm小区(BCCH: 79, BSIC: 67，rxlev sub=-90)，但只接收到RR Handover Command，没收到RR Physical Information，随后重建回LTE，平台统计为eSRVCC失败。

问题路段多次测试2G，该路段主要由GSM小区9500-32558（BCCH: 44, BSIC: 75，rxlev sub=-74，RXQUAL_SUB_SERVING_CELL = 0）作主覆盖，然而esrvcc切换失败目标gsm小区是9462-29037(BCCH: 79, BSIC: 67)，该小区在该复测时并未占用，从邻区列表看该小区信号强度-86dBm左右，初步怀疑切换不合理2G小区导致本次事件，建议调整B2门限。该2G小区参数配置无误、无干扰、无告警。

解决方案：

由于eSRVCC失败目标小区在该路段覆盖较弱，且有其它较强GSM小区，调整B2设置2门限，由-90改为-85。 方案实施效果：

多次复测时占用广州西区昌岗路F-ZLH-2，触发eSRVCC 至GSM小区(RX=-83,BCCH: 44, BSIC: 75) ，均切换成功。修改门限后提取该站点eSRVCC切换对指标，均未发现有切换失败。

2.参数设置问题- B2参数不合理触发eSRVCC案例

案例说明：

测试车辆在第二街附近，在11:31:16.时分主叫占用（ECI=2074421，RSRP=-101），触发ESRVCC，要求切换至（BCCH: 74, BSIC:62），因GSM网络问题导致ESRVCC切换失败，主叫收到RR Handover Command信令，但未收到GSM网络下发的RR Physical Information，而导致切换失败。从QCAT底层信令分析：发现终端接收到的2G信号普遍在-92dBm左右，存在2G弱覆盖。

案例分析：

经后台查询发现ECI=2074421 小区B2门限值为-100，B2参数设置不合理且切换成功率低，将门限调整为-116能有效减少ESRVCC申请数。

解决方案：

建议将ECI=2074421小区B2门限值由-100修改为-116。 方案实施效果：

问题点路段保持在4G信号上通话，多次复测均未触发eSRVCC切换。

3.站点故障-基站退服导致的eSRVCC失败

案例说明：

在大学城广美宿舍楼附近测试，主被叫于09:34:19.711时分建立通话，到09:35:11.844时分，主叫占用广州广工中区F-ZLH-2（RSRP=-117，SINR=0.7）触发eSRVCC切换至P1DGGJ3(BCCH: 79, BSIC: 12)，由于终端只接收到RR Handover Command，未收到RR Physical Information从而导致eSRVCC切换失败，随后重建回LTE，继续完成180秒通话,未出现volte掉话。

案例分析：

从QCAT底层信令来看：发现终端测量到的2G信号值普遍在-97dB左右。

据区域反馈：测试当天4G、2G主覆盖小区广州番禺区广美宿舍区D-ZLH、广美宿舍区D因断电导致退服。 综上所述：由于主覆盖小区4G、2G基站都退服导致esrvcc切换失败，优化建议：加快广州番禺区广美宿舍区D-ZLH、广美宿舍区D退服处理。 解决方案：

加快广州番禺区广美宿舍区D-ZLH、广美宿舍区D-ZLH退服处理。 方案实施效果：

广州番禺区广美宿舍区D-ZLH、广美宿舍区D-ZLH故障处理后该路段无线覆盖良好，未出现esrvcc情况。

六、附volte拓扑图

业务平台彩铃业务平台彩印业务平台定位业务平台UtIP短信网关（IP-SM-GW）VoLTE AS/MRFCAPCAP智能网SCP业务配置代理网关核心网PCCIMS域ShSLh/SLgCx/Sh/Zh/S6a/SLhIBCF用户数据ZhJ三合一HSSC/D2G/3G电路域PCRFRx/Gx信令网MxISCSLsCxI/S/E-CSCF/BGCF/TRF/LRF/EATFDNS/ENUMMGCF/IM-MGWNc/NbMwMg/MjDRARxP-CSCF/ATCF/ATMw/I2GW/AGWGMSCNcS1-MMESGiSAE GW/GGSN/PCEF分组域Nanocell网关Gr/S6aS11/Gn/GpS6a/SLgMME/SGSNS1-UGxeMSCSv/SGs承载网承载网S1-U接入网NanocellLTE接入eNodeBS1-MMEGmUuGbBTS/BSCA2G接入终端 UEUmUt 七、附网元说明

➢ PCC（Policy and Charging Control 策略与计费控制）: 提供策略控制、计费控制功能、业务数据流的事件报

告等功能。

➢ 包括: PCEF（Policy and Charging Enforcement Function 策略和计费执行功能）:主要包含业务数据流的检测、

策略执行和基于流的计费功能。 ➢ PCRF（Policy and Charging Rule Function策略和计费规则功能）:包含策略控制决策和基于流计费控制的功能，

PCRF接受来自PCEF、SPR和AF的输入，向PCEF提供关于业务数据流检测、门控、基于QoS和基于流计费的网络控制功能。并结结合PCRF的自定义信息做出PCC决策。

➢ SBC（Session Border Control 会话边界控制器）: IMS网络中一个重要的网络节点，其位于IMS网络的边界，

起着将终端用户接入到IMS核心网的重要作用。它的主要功能包括接入许可控制，网络拓扑隐藏，NAT以及NAT穿越，QoS及带宽策略，和网络安全机制等。

➢ S-CSCF（Serving Call Session Control Function 服务会话控制功能）: 是IMS的核心所在，它位于归属网络，

为UE进行会话控制和注册请求，但当UE处于会话中时，S-CSCF处理网络中的会话状态。在同一个运营商的网络中，可以有多个S-CSCF。 ➢ P-CSCF（Proxy Call Session Control Function 代理会话控制功能）:是IMS中用户的第一个联系点（在信令平面），

从SIP的角度来看，它是一个出站/入站的SIP代理服务器，所有的SIP信令，无论是来自用户设备UE，还是发送给UE的，都必须经过P-CSCF。UE使用本地CSCF发现机制可以获得P-CSCF的地址。P-CSCF负责验证请求，将它转发给指定的目标，并且处理和转发响应。

➢ I-CSCF（Interrogating Call Session Control Function 协商会话控制功能）: I-CSCF是一个运营商网络内部的接触

点，所有与这个网络运营商的用户连接都要经过这个实体。在一个网络中可以有多个I-CSCF。

➢ MGCF（Multimedia Gateway Control Function 多媒体网关控制功能）: 在IP多媒体子系统(IMS)的一个组

成部分，与CSCF通信和体信道在一个IMS-MGW中的连接。它在ISDN部分(ISUP)和IMS呼机控制协议之间执行协议转换。

➢ IM-MGW（IP Multimedia Gateway IP多媒体网关）: IM-MGW负责IMS与PSTN/CS域之间的媒体流互通，

提供CS CN网络和IMS之间的用户面链路，支持PSTN/电路域TDM承载和IMS用户IP承载的转换。主要功能是承载和媒体处理。在IMS终端不支持CS端编码时IM-MGW完成编解码的转换工作。IM-MGW也可以在MGCF的控制下完成呼叫的连续。 ➢ BGCF()：在从IMS到PLMN/PSTN的呼叫流程中会涉及BGCF网元。BGCF从与S-CSCF之间的Mi接口接收SIP

消息，如果被叫PLMN/PSTN处在同一网络中，则BGCF直接通过Mj接口将消息转发至MGCF；如果被叫PLMN/PSTN处在不同网络中，BGCF则通过Mk接口将消息转发至目的网络中的BGCF，目的网络BGCF通过Mj接口将消息转发至相应MGCF。

➢ IBCF()：IBCF用于不同IMS网络之间的互通。当一个IMS用户呼叫另一运营商的IMS用户时，CSCF通过Mx

接口将消息发送至IBCF，IBCF通过Ici接口与其他运营商的IBCF进行交互。IBCF的功能包括：网络拓扑隐藏、应用层网关、传输层控制、SIP消息过滤、媒体编解码控制。

➢ ATCF（Access Transfer Control Function）：信令锚点。决定是否需要对媒体面会话进行锚定；执行会话切换，

通知SCC AS发生eSRVCC切换。 ➢ ATGW（AccessTransfer Gateway）：媒体流锚点。在ATCF的控制下对媒体面进行锚定和释放。 ➢ SCC AS：锚定和关联会话，提供C-MSISDN和ATU-STI等信息。

八、附volte主要接口

九、附SIP说明

请求消息：

方法名 INVITE ACK BYE CANCEL REGISTER SUBSCRIBE PUBLISH NOTIFY UPDATE MESSAGE PRACK INFO 应用场景 用于会话的建立和会话属性的修改。 用于对INVITE消息最终响应的确认。 用于会话的释放。 用于取消INVITE请求。 用于注册和注销。 用于对事件的订阅。 用于发布网元状态。 用于对订阅事件的通知。 用于会话建立完成前的会话媒体修改。 用于即时消息。 用于对临时响应消息的确认。 用于在会话内传送会话相关的控制信息。 REFER OPTIONS 响应消息：

状态码 1XX 2XX 3XX 4XX 5XX 6XX 常见响应消息： 用于通知第三方对会话进行控制。 用于服务器能力查询。也可用作心跳消息。 含义 临时响应，表示请求消息正在被处理。 成功响应，表示请求已被成功接收，完全理解并被接受。 重定向响应，表示需采取进一步以完成该请求。 客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求。 服务器错误，表示服务器无法完成合法请求。 全局故障，表示任何服务器无法完成该请求。 状态码 100 180 181 183 200 401 403 408 486 487 488 503

含义 Trying Ringing Call is Being Forwarded Session Progress OK Unauthorized Forbidden Request Timeout Busy Here Request Terminated Not Acceptable Here Service Unavailable 说明 表示呼叫发生了前转业务 请求需要用户认证 服务端支持这个请求，但是拒绝执行请求 表明invite请求被BYE或者CANCEL所终止 特定媒体资源不能接受 十、附切X2/S1换流程图

跨MME的S1切换流程图：

UE Source eNodeB Source Target MME eNodeB Downlink User Plane data Target MME Source Serving GW Target Serving GW PDN GW HSS 1. Decision to trigger a relocation via S1 2. Handover Required 3. Forward Relocation Request 4. Create Session Request 4a. Create Session Response 5. Handover Request 5a. Handover Request Acknowledge 6. Create Indirect Data Forwarding Tunnel Request 6a. Create Indirect Data Forwarding Tunnel Response 7. Forward Relocation Response . 8. Create Indirect Data Forwarding Tunnel Request 8a. Create Indirect Data Forwarding Tunnel Response 9. Handover Command 9a. Handover Command 10. eNB Status Transfer 10a. Forward Access Context Notification 10b. Forward Access Context Acknowledge 10c. MME Status Transfer 11a. Only for Direct forwarding of data 11b. Only for Indirect forwarding of data Detach from old cell and synchronize to new cell 12. Handover Confirm Downlink data Uplink User Plane data 13. Handover Notify 14. Forward Relocation Complete Notification 14b. Forward Relocation Complete Acknowledge 15. Modify Bearer Request 16. Modify Bearer Request 17. Modify Bearer Response Downlink User Plane data 18. Tracking Area Update procedure 19c. Delete Session Request (B) 19b. UE Context Release Complete 19d. Delete Session Response 20a. Delete Indirect Data Forwarding Tunnel Request 20b. Delete Indirect Data Forwarding Tunnel Response 21a. Delete Indirect Data Forwarding Tunnel Request 21b. Delete Indirect Data Forwarding Tunnel Response 19a. UE Context Release Command (A) 16a. Modify Bearer Response