CSFB业务流程中MME和CSFBMSC寻呼参数设置研究图文精.docx

CSFB业务流程中MME和CSFBMSC寻呼参数设置研究图文精.docx

《CSFB业务流程中MME和CSFBMSC寻呼参数设置研究图文精.docx》由会员分享，可在线阅读，更多相关《CSFB业务流程中MME和CSFBMSC寻呼参数设置研究图文精.docx（9页珍藏版）》请在冰豆网上搜索。

CSFB业务流程中MME和CSFBMSC寻呼参数设置研究图文精

CSFB业务流程中（MME和CSFBMSC寻呼参数设置研究

1.引言

CSFallback语音业务,是一种协议规定的电路域回落语音解决方案。

用户同时注册在EPS（EvolvedPacketSystem网络和传统的电路域网络,发起语音业务时,由EPS网络指示用户回落到目标电路域网络之后,再发起语音业务。

该语音解决方案就是CircuitSwitchedFallbackinEvolvedPacketSystem,简称CSFallback（或CSFB。

在CSFB过程中,存在一个重要的流程——寻呼,不同设备上寻呼参数的设置对于业务流程成功和用户感知都有非常重要的影响,本文主要讨论一下MME和CSFBMSC上寻呼参数的设置。

2.CSFB实现原理

LTE网络部署初期,一般是LTE做热点覆盖。

此时LTE覆盖的面积小,且连续覆盖小。

从LTE是后期建网来考虑,在LTE建网时应合理地规划TA（TrackingArea,即将TA覆盖范围的2G/3GLA（LocationArea规划为由同一个MSCServer管理,这样,当UE做联合TA/LA更新时,才能做LA更新选择到当前2G/3GRAN对应的MSCServer,以尽量避免MSCServer更新不及时而导致漫游重呼

（RoamingRetry的发生。

MME可以覆盖多个热点地区,采用IP组网和多个MSCServer相连。

需要在MME上配置数据,将TA映射成对应的VLRnumber,从而选定对端SGs接口的MSCServer。

2.1网络架构图

CSFallback是通过重用Gs接口的方法来实现的,即MME（MobilityManagementEntity和MSC（MobileSwitchingCenterServer之间存在一个类似现有SGSN（ServingGPRSSupportNode和MSCServer之间Gs接口的SGs接口。

CSFallback逻辑架构如图1所示。

图1CSFallback逻辑架构

2.2SGs接口

CSFallback特性中,最主要的接口是SGs接口,它是MME和MSCServer之间的接口,用来处理EPS和CS域之间的移动性管理和语音业务寻呼。

SGs接口中,SGsAP（SGsApplicationPart作为SGs的应用层协议。

SCTP协议作为传输层协议,用于保证传输的可靠性。

该接口可实现功能如下:

1移动性管理:

SGs接口类似于3G的Gs接口,

通过该接口可以完成联合

附着、联合位置更新、IMSI/EPSdetach功能。

2语音寻呼:

UE的主叫业务不经过SGs接口,因为MME收到带有UE发送的CSFB标识（指示回落后,直接通过eNodeB指示UE回落到CS域。

当UE有被叫业务时,Paging消息经CS发送到MME,由MME发起回落流程。

被叫回落流程和主叫回落流程类似。

SMS传输功能:

对于SMS业务,EPC网络并不会要求终端回落到传统电路域再发送或者接收短消息,而是直接在EPC网络中用LTENAS信令直接传递,大幅提升了SMS业务效率。

SGs接口协议栈如图2所示。

图2SGs接口协议栈

2.3语音主叫业务

如图3所示,UE发起CSFallback语音主叫业务,MME指示eNodeB（evolvedNodeB需要将UE回落到GERAN/UTRAN网络,eNodeB指示UE回落到GERAN/UTRAN网络,UE在GERAN/UTRAN网络发起主叫语音业务。

图3语音主叫流程

1.UE发起CSFallback语音业务请求。

2.（可选MME向MSCServer发送SGsAP-SERVICE-REQUEST消息,携带信元MOFallbackindicator,指示主叫侧UE回落。

3.MME发送S1-APUECONTEXTMODIFICATIONREQUEST消息给eNodeB,包含CSFallbackIndicator。

该消息指示eNodeB,UE因CSFallback业务需要回落到UTRAN/GERAN。

4.eNodeB要求UE开始系统的小区测量,并获得UE上报的测量报告,确定重定向的目标系统小区。

然后向UE发送目标系统具体的无线配置信息,并释放连接。

5.UE接入目标系统小区,发起CS域的业务请求CMServiceRequest。

6.如果目标系统小区归属的MSCServer与UE附着EPS网络时登记的MSCServer不同,则该MSCServer收到UE的业务请求时,由于没有该UE的信息,可以采取隐式位置更新流程,接受用户请求。

如果MSCServer不支持隐式位置更新,且MSCServer没有用户数据（即服务MSCServer与EPS/IMSI登记的MSCServer不同,则拒绝该用户的业务请求。

如果MSCServer拒绝用户的业务请求会导致UE发起一个CS域位置更新流程。

7.CS域语音呼叫建立流程。

2.4语音被叫业务

如图4所示,MSCServer收到对UE的被叫语音请求,通过存在的SGs关联和MME信息,向该MME发起寻呼请求。

MME通过eNodeB在空口寻呼该UE,并指示UE回落到目标GERAN/UTRAN网络。

UE接入到目标网络后,在电路域继续进行语音呼叫。

图4语音被叫流程

1.MSCServer收到入局IAM消息。

2.MSCServer根据存在的SGs关联和MME信息,发送SGsAP-PAGING-REQUEST消息（携带IMSI,TMSI,Serviceindicator,CLI,LAC,Channelneeded信元给MME。

3.MME发送Paging消息给eNodeB。

eNodeB发起空口的Paging流程。

4.UE建立连接并发送ExtendedServiceRequest消息给MME。

5.MME发送SGsAP-SERVICE-REQUEST消息给MSCServer。

MSCServer收到此消息,不再向MME重发寻呼请求消息。

为避免呼叫接续过程中,主叫等待时间过长,MSCServer收到包含空闲态指示的SGsAP-SERVICE-REQUEST消息,先通知主叫,呼叫正在接续过程中。

6.MME发送InitialUEContextSetup消息给eNodeB,包含CSFallbackIndicator。

该消息指示eNodeB,UE因CSFB业务需要回落到UTRAN/GERAN。

7.UE从E-UTRAN回落到UTRAN/GERAN。

8.伴随着空口、A/Iu-CS接口连接的建立,UE回PagingResponse消息或者位置更新请求消息给MSCServer。

即使BSC/RNC没有向该UE发起过寻呼请求,这里的BSC/RNC需要能处理UE的寻呼响应。

如果寻呼响应消息中的位置区信息和VLR中保存的不一致,则VLR在业务接入成功之后将SGs关联置为没有关联。

9.MSCServer收到UE的寻呼响应后,停掉寻呼响应定时器并建立CS连接。

3.CSFB中的寻呼流程

CSFB组网下,当用户作为被叫时,MSCServer会通过SGs接口下发PagingRequest消息,MME寻呼手机,并指示UE需要回落到2G/3G,UE在回落到2G/3G后,向MSCServer回应寻呼响应,如图5所示。

图5CSFB终结语音呼叫流程

针对此流程有个关键点需要关注:

1、无线侧RNC/BSC一定要配置正确的4G邻区,否则会导致无法收到PagingResponse寻呼响应消息,对该4G用户的终结呼叫拆线。

2、核心网侧（MME和CSFBMSC一定要配置正确的寻呼策略和寻呼时长,否则会发生UE回应寻呼响应时,MSC侧已寻呼超时,对该4G用户终结呼叫拆线。

以下主要讨论MME和CSFBMSC上寻呼策略和寻呼时长的设置。

3.1现网信令追踪消息分析

为了更好的说明相关寻呼参数的设置,我们先来看一段在MME设备上抓取的现网CSFB流程语音被叫业务的消息追踪,结合信令消息进行分析说明。

图6跟踪消息截图

从追踪的消息来看,CSFBMSC通过SGS接口一共向MME发送了三次SGSAP_MM_PAGING_REQ,第一次发送之后等待了6S发起第二次,第二次发送之后等待了5S发起第三次,没有发起第四次,所以CSFBMSC上设置的寻呼次数一共是三次,时长应该是6S-5S-XS,这个“X”表示根据现有的消息无法判断第三次发起后CSFBMSC的等待时长。

但是,在第三次发起之后等待了6S,MME出现了一条内部消息AC_US_RESET_CONN_RSP,如图7所示。

图7AC_US_RESET_CONN_RSP

这条消息的内容是

e-MM-TIMEOUT-REGISTIDLE-WAIT-EXTENDED-SERVICE-REQ,从这条消息可以看出,第三次SPU_S1AP_PAGING_REQ流程超时了,而超时是由MME判断的,而且超时后并没有任何消息通过SGS接口反馈给CSFBMSC。

3.2MME寻呼相关参数的设置3.1节中对现网信令追踪消息做了分析，可以看出只有在第三次的SPU_S1AP_PAGING_REQ流程超时后，MME发挥了作用，在内部消息中判断流程超时，并记录了CHR，之后也没有触发其他动作，那么在MME上，寻呼参数到底是怎么设置的呢？

查询EMM（EPSMobilityManagement）参数：

LSTEMM:

;%%LSTEMM:

;%%RETCODE=0操作成功T3422（s=6N3422（次数=4T3450（s=6N3450（times=4T3460（s=6N3460（times=4T3470（s=6N3470（times=4T3412（min=54T3402（min=12T3413（s=6N3413（times=2重寻呼间隔递增值（s=0移动可达定时器（min=58不可达用户隐式分离定时器（min=0GUTI重分配定时器（h=0Attach或TAU中重分配GUTI=重分配GUTIHandover准备定时器（s=10源侧Handover完成定时器（s=10目标侧Handover完成定时器（s=10T3定时器（s=10切换流程资源释放定时器定时器（s=2（结果个数=1--END根据现网的配置，和寻呼相关的参数有两个T3413和N3413:

1、T3413参数的含义为：

此定时器用于控制MME发起寻呼与UE响应的时间间隔。

在MME发送PagingRequest消息后启动，在收到ServiceRequest消息后停止，超时后，MME重发PagingRequest消息。

2、N3413参数的含义为：

该参数用于指定在寻呼流程中，没有收到UE的响应消息，MME重复发送PagingRequest消息的次数。

也就是说MME设置的寻呼方式是一共寻呼3次，每次等待6S，一共18S后没有收到回应，认为寻呼超时。

从3.1节中的消息看出，在CSFB业务流程中MME收到SGS接口的SGSAP_MM_PAGING_REQ的消息后就下发寻呼，但是时间间隔并不是每次都是6S，而且第二次、第三次的寻呼都收收到SGS接口的SGSAP_MM_PAGING_REQ的消息后发起的，也就是说，MME设备上的寻呼参数几乎没有生效。

在CSFB流程中发起的寻呼究竟应该遵循什么原则呢？

从3GPP规范中我们可以看出一些端倪，如图8所示。

图83GPPTS23.272V12.1.03GPP协议TS23.272V12.1.0版本中第7节有描述，MSC负责SGS接口上寻呼消息的定时器、排队和转发，而MME不使用本身的寻呼方案。

这就解释了3.1节中消息的表现。

为了进一步印证这一原则，我们把MME上的T3413修改为4S，N3413仍然为2，再一次进行消息跟踪，如图9所示。

图9跟踪消息截图

从抓取的消息可以验证MME确实遵循了协议的规定，不使用自身的寻呼方案，第一次寻呼4S超时后，MME只是自身记录了寻呼超时，但是没有触发任何其他的动作，等待第二次收到SGS接口发来的寻呼消息后，才出发了第二次寻呼。

接下来，我们需要验证CSFBMSC设备上是否确实设置的寻呼方案为3次，且间隔为6S-5S-XS。

3.3CSFBMSC寻呼相关参数的设置我们在CSFBMSC上查询相关参数：

%%LSTPGCTRL:

;%%RETCODE=0操作成功。

LAI号码=e寻呼类型=所有寻呼类型呼叫优先级=所有优先级紧急容灾数据标志=否寻呼次数=3首次寻呼时长=6第二次寻呼时长=5第三次寻呼时长=4第四次寻呼时长=4第五次寻呼时长=4TMSI/IMSI指示=首次寻呼（0-使用TMSI=第二次寻呼（0-使用TMSI=第三次寻呼（0-使用TMSI=第四次寻呼（0-使用TMSI=第五次寻呼（0-使用TMSI所有RAN寻呼指示=首次寻呼（0-1个LAI=第二次寻呼（0-1个LAI=第三次寻呼（0-1个LAI=第四次寻呼（0-1个LAI=第五次寻呼（0-1个LAILAI类型=LAI--END下面来解读下CSFBMSC上寻呼参数的配置：

1、LAI号码中“e”为通配符，表示所有的位置区。

2、寻呼次数用于指定在一次寻呼流程中所允许发起寻呼的最大次数，其取值范围为1～5，系统默认值为“3”。

一个完整的寻呼流程是指从MSC发起寻呼到收到MS寻呼响应或寻呼失败的整个过程；一次寻呼是指下发一次寻呼消息，

一个寻呼流程包含一次或多次寻呼。

需要指出的是，在一次寻呼流程中，系统默认等待寻呼响应或寻呼失败消息的最大时长为20秒，因此，操作员在配置“寻呼次数”、“首次寻呼时长”、“第二次寻呼时长”等参数时，其有效的寻呼时长之和应小于或等于20秒。

3、首次寻呼时长用于指定从第一次寻呼到第二次寻呼之间的时间间隔，其取值范围为1～10、单位为“秒”，系统默认值为“6”。

4、第二次寻呼时长用于指定从第二次寻呼到第三次寻呼之间的时间间隔，其取值范围为1～10、单位为“秒”，系统默认值为“5”。

5、第三次寻呼时长用于指定从第三次寻呼到第四次寻呼之间的时间间隔，其取值范围为1～10、单位为“秒”，系统默认值为“4”。

由于寻呼次数配置为3次，所以第四次寻呼时长和第五次寻呼时长实际上是没有起作用的。

从前面抓取的消息我们可以验证6S-5S-XS中的“X”是4S。

4结论CSFB业务流程中的寻呼参数需要MME和CSFBMSC配合设置，否则可能会导致寻呼成功率较低，用户感知变差等后果，主要遵循以下原则：

CSFBMSC上每一次的寻呼时长建议都比MME上寻呼的时长多一秒，这样就可以避免MME在最后1S寻呼到用户时，CSFBMSC上的寻呼时长已经超时造成被叫拆线等后果。