多媒体回落特性指导书.docx
《多媒体回落特性指导书.docx》由会员分享，可在线阅读，更多相关《多媒体回落特性指导书.docx（14页珍藏版）》请在冰豆网上搜索。
多媒体回落特性指导书
WMFD-161300_多媒体回落特性描述
定义
根据3GPPTS23.172的定义，回落（fallback）是指在呼叫建立过程中，多媒体业务降质为语音业务的过程。
MSOFTX3000所支持的多媒体回落是指在呼叫接续或通话过程中，当主叫用户发起视频电话VP（VideoPhone）呼叫时，若主叫或被叫侧属于以下情况，网络可以自动将此呼叫回落到语音呼叫：
∙主叫用户或被叫用户所在的网络不支持VP业务。
∙被叫终端不支持VP呼叫。
∙主叫用户或被叫用户未签约VP业务。
∙被叫用户在GSM网络中。
∙VP呼叫过程中，主叫用户或被叫用户其中一方切换到GSM网络。
受益
受益方
受益描述
运营商
多媒体回落业务能够在无法建立或保持视频呼叫的场景下，视频呼叫自动回落为语音呼叫，有助于提高呼叫接通成功率和降低通话过程中的掉话率。
用户
系统向用户提供多媒体回落业务后，发起视频呼叫的用户可以在无法建立或保持视频呼叫的场景下，视频呼叫自动回落为语音呼叫，保证了呼叫的正常接续。
可获得性
涉及网元
多媒体回落特性涉及的网元及其版本支持情况如表1所示。
表1多媒体回落特性涉及的网元
涉及网元
版本支持
功能说明
RNC
BSC6800V100R008及后续版本
同MSCServer配合完成有关呼叫的各种信令处理、数据分析等。
MSCServer
V100R006C02及后续版本
对多媒体呼叫进行处理，完成多媒体回落后语音业务的接续，保证多媒体回落后语音业务的正常进行。
MGW
UMG8900V200R007C01及后续版本
主要负责多媒体回落业务中的承载建立。
硬件兼容性
多媒体回落特性对硬件能力要求如下：
∙RNC必须支持空中接口资源由多媒体承载修改为语音承载。
说明：
在本文后续介绍中，如果不明确说明RI的值的情况，都默认为“supportofservicechangeandfallback”。
对系统的影响
本特性对系统无影响。
与其它特性的交互
本特性与其它特性无交互关系。
应用场景
适用于UMTSR99/R4所有市场，特别是2G/3G互存网络。
在由于某种情况无法建立视频呼叫的情况下，可以通过多媒体回落特性将视频呼叫降质为语音呼叫，从而保证呼叫接通。
实现原理
说明：
前转流程都以在MGW选择前发生前转为例，根据实际情况前转到不同的落地局后，再建立用户面承载。
多媒体回落特性的具体功能包括以下几类：
1.支持主叫用户发起视频电话，被叫用户（终端支持VP业务）所在的网络不支持VP业务的回落：
∙如果取路由信息（SendRoutingInfo）发生在主叫端局，MSCServer通过发送携带语音承载能力的Call_Proceeding消息通知主叫用户回落。
∙如果取路由信息（SendRoutingInfo）发生在关口局或者落地局，则通过特定原因值拆线。
2.支持主叫发起视频电话，而主叫用户出现所处网络不支持VP业务、未签约VP业务、不支持多媒体业务的情况的回落：
∙如果主叫端局属于2G网络，则直接拆线。
∙如果主叫用户没有签约VP业务，MSCServer通过发送携带语音承载能力的Call_Proceeding消息通知主叫用户回落。
3.支持主叫发起视频电话，被叫用户没有签约VP业务的回落：
∙如果取路由信息（SendRoutingInfo）发生在主叫端局，MSCServer通过发送携带语音承载能力的Call_Proceeding消息通知主叫手机回落。
∙如果取路由信息（SendRoutingInfo）发生在关口局或者落地局，则通过特定原因值拆线。
4.支持RNC上报承载修改请求时的回落：
∙当主叫用户、被叫用户进行视频通话时，RNC无法维持视频呼叫，主动向MSCServer上报RAB_MODIFY_REQUEST消息，触发In-CallModification流程，业务回落为语音呼叫。
5.支持用户从3G网络切换到2G网络的回落：
∙当主叫用户、被叫进行多媒体通话时，发生3G网络到2G网络的切换，触发In-CallModification流程，业务回落为语音呼叫。
6.支持视频呼叫建立失败后提示手机重新发起语音呼叫：
∙当视频呼叫不支持回落时，如果系统无法建立视频呼叫，以特定原因值通知用户拆线，由终端提示用户是否重新发起语音呼叫。
多媒体回落特性的实现原理包括以下几类：
∙主叫用户没有签约多媒体呼叫触发的回落
∙被叫用户没有签约多媒体呼叫触发的回落
∙被叫用户在2G网络触发的回落
∙被叫用户手机不支持多媒体呼叫触发的回落
∙被叫用户手机不支持RepeatIndicator指示触发的回落
∙切换到2G触发的多媒体回落
∙RNC发送承载修改请求触发的回落
主叫用户没有签约多媒体呼叫触发的回落
此场景多媒体回落业务由MSCServer向VLR查询主叫用户签约数据时触发。
实现原理如图1所示。
图1主叫用户没有签约多媒体呼叫的回落实现原理
呼叫处理流程如下：
1.主叫用户在3G网络中，MSCServer收到主叫用户拨打被叫用户电话号码的呼叫，其中呼叫携带双BC，第一个BC为多媒体BC，第二个BC为语音BC。
2.MSCServer携带双BC向VLR查询主叫签约数据。
3.VLR执行签约性检查，由于主叫没有签约多媒体呼叫业务，VLR返回失败响应。
4.MSCServer发送Call_Proceeding消息，携带语音承载信息通知手机。
5.MSCServer以语音BC继续后续呼叫处理。
被叫用户没有签约多媒体呼叫触发的回落
此场景多媒体回落业务由MSCServer向HLR请求路由信息时触发。
实现原理如图2所示。
图2被叫用户没有签约多媒体呼叫的回落实现原理
呼叫处理流程如下：
1.主叫用户在3G网络中，MSCServer收到主叫用户拨打被叫用户电话号码的呼叫，其中呼叫携带双BC，第一个BC为多媒体BC，第二个BC为语音BC。
2.MSCServer以多媒体BC向被叫所在的HLR请求路由信息。
3.HLR执行兼容性和签约性检查后，由于被叫没有签约多媒体业务，发送SRI响应给主叫端局，携带原因值“BEARER_SERVICE_NOT_SUPPORTED”。
4.MSCServer以语音BC向被叫所在的HLR请求路由信息。
5.HLR发送SRI响应给主叫端局，携带漫游号码。
6.MSCServer发送Call_Proceeding消息，携带语音承载信息通知手机。
7.MSCServer以语音BC继续后续呼叫处理。
说明：
此种场景目前只支持SRI发生在主叫端局的多媒体回落,SRI发生在关口局/被叫端局的情况下，MSCServer会拆除呼叫，后续由手机重新发起呼叫。
被叫用户在2G网络触发的回落
此场景多媒体回落业务由MSCServer向HLR请求路由信息时触发。
实现原理如图3所示。
图3被叫用户在2G网络的回落实现原理
呼叫处理流程如下：
1.主叫用户在3G网络，被叫用户在2G网络中，MSCServer收到主叫用户拨打被叫用户电话号码的呼叫，其中呼叫携带双BC，第一个BC为多媒体BC，第二个BC为语音BC。
2.MSCServer以多媒体BC向被叫所在的HLR请求路由信息。
3.HLR执行兼容性和签约性检查后，携带多媒体BC向被叫用户所在的VLR发起取漫游号码请求。
4.由于用户处于BSC下，VLR向HLR回PRN错误响应，其中携带原因值“FACILITY_NOT_SUPPORTED”。
5.HLR发送SRI响应给主叫端局，携带原因值“FACILITY_NOT_SUPPORTED”。
6.MSCServer以语音BC向被叫所在的HLR请求路由信息。
7.HLR执行兼容性和签约性检查后，携带语音BC向被叫用户所在的VLR发起取漫游号码请求。
8.VLR分配漫游号码后，向HLR回PRN成功响应。
9.HLR发送SRI响应给主叫端局，携带漫游号码。
10.MSCServer发送Call_Proceeding消息，携带语音承载信息通知主叫手机。
11.MSCServer发送IAM消息，携带语音BC发送到被叫端局。
说明：
此种场景目前只支持SRI发生在主叫端局的多媒体回落,SRI发生在关口局/被叫端局的情况下，MSCServer会拆除呼叫，后续由手机重新发起呼叫。
被叫用户手机不支持多媒体呼叫触发的回落
此场景多媒体回落业务由被叫手机向MSCServer发送Call_Confirmed时触发。
实现原理如图4所示。
图4被叫用户手机不支持多媒体呼叫的回落实现原理
呼叫处理流程如下：
1.主被叫用户都在3G网络中，MSCServer收到主叫用户拨打被叫用户电话号码的呼叫，其中呼叫携带双BC，第一个BC为多媒体BC，第二个BC为语音BC。
2.MSCServer向被叫手机发送Setup消息，携带RepeatIndicator和双BC，其中RI指示为“supportofservicechangeandfallback”，第一个BC为多媒体BC，第二个BC为语音BC。
3.由于被叫手机不支持多媒体呼叫，被叫手机向MSCServer发送Call_Confirmed消息，只携带语音承载能力。
4.MSCServer发送Call_Proceeding消息，只携带语音承载信息通知主叫手机。
说明：
此种场景目前只支持局内呼叫的回落，如果是局间呼叫，被叫端局会向前向局发送REL消息拆除呼叫，后续由手机重新发起呼叫。
被叫用户手机不支持RepeatIndicator指示触发的回落
此场景多媒体回落业务由MSCServer给被叫手机发送SETUP时触发。
实现原理如图5所示。
图5被叫用户手机不支持RepeatIndicator指示的回落实现原理
呼叫处理流程如下：
1.主被叫用户都在3G网络中，MSCServer收到主叫用户拨打被叫用户电话号码的呼叫，其中呼叫携带双BC，第一个BC为多媒体BC，第二个BC为语音BC。
2.MSCServer向被叫手机发送Setup消息，携带RI指示和双BC，其中RI指示为“supportofservicechangeandfallback”，第一个BC为多媒体BC，第二个BC为语音BC。
3.由于被叫手机不认识RI为“supportofservicechangeandfallback”的值，被叫手机向MSCServer发送Status消息，携带原因值为“ConditionalIEerror”。
4.MSCServer根据软参P1000BIT1配置，如果软参设为1，只携带多媒体承载信息重新发送Setup消息给手机，如果软参设置为0，只携带语音承载信息重新发送Setup消息给手机，默认值为1。
5.被叫手机返回CallConfirmed给MSCServer。
6.如果在第4步中MSCServer发送给被叫手机的Setup消息中携带语音承载信息，则MSCServer发送Call_Proceeding消息，只携带语音承载信息通知主叫手机回落为语音呼叫，后续以语音业务建立呼叫。
如果在第4步中MSCServer发送给被叫手机的Setup消息中携带多媒体承载信息，则MSCServer发送Call_Proceeding消息，只携带多媒体承载信息通知主叫手机，后续以多媒体业务建立呼叫。
说明：
如果软参设置为0，以语音建立呼叫。
此种场景目前只支持局内呼叫的回落，如果是局间呼叫，被叫端局会向前向局发送REL消息拆除呼叫，后续由手机重新发起呼叫。
切换到2G触发的多媒体回落
此场景多媒体回落业务由RNC向MSCServer发送Relocation_Required切换请求到2G网络时触发的。
实现原理如图6所示。
图6切换到2G触发的多媒体回落实现原理
呼叫处理流程如下：
1.主被叫用户都在3G网络中，开始两用户以视频业务进行通话，RNC发起到2G网络的切换请求消息Relocation_Required消息。
2.MSCServer拒绝切换请求。
3.MSCServer携带语音承载信息向本端手机发送MODIFY消息。
4.手机回MODIFY_COMPLETE消息给MSCServer。
5.MSCServer携带语音承载信息向另一侧手机发送MODIFY消息。
6.手机回MODIFY_COMPLETE消息给MSCServer，随后MSCServer通过MODREQ和RAB_ASSIGNMENT_REQ修改陆地和空口资源，此后双方用户以语音继续呼叫。
RNC发送承载修改请求触发的回落
此场景多媒体回落业务由RNC向MSCServer发送RAB_MODIFY_REQ消息时触发的。
实现原理如图7所示。
图7RNC发送承载修改请求触发的回落实现原理
呼叫流程处理如下：
1.主被叫用户都在3G网络中，开始两用户以视频业务进行通话，RNC发送RAB_MODIFY_REQ消息给MSCServer。
2.MSCServer携带语音承载信息向本端手机发送MODIFY消息。
3.手机回MODIFY_COMPLETE消息给MSCServer。
4.MSCServer携带语音承载信息向另一侧手机发送MODIFY消息。
5.手机回MODIFY_COMPLETE消息给MSCServer，随后MSCServer通过MODREQ和RAB_ASSIGNMENT_REQ修改陆地和空口资源，此后双方用户以语音继续呼叫。
计费与话单
多媒体回落特性的计费与话单情况如表2所示。
表2多媒体回落特性话单情况
呼叫用户类型
话单情况
主叫为A，被叫为B。
∙如果在呼叫还未进入稳态时的多媒体回落，对A出一张语音MOC（MobileOriginatedCall）话单，对B出一张语音MTC（MobileTerminatedCall，移动终结）话单。
∙如果呼叫稳态后发生的多媒体回落，在成功多媒体回落后，出一张业务变更的中间话单。
软参说明
与多媒体回落特性相关的软参如表3所示。
表3多媒体回落特性相关软参
软参名
说明
P177（CM软参10）BIT7
该比特用于控制是否按照协议24008-6a0中的描述来判断手机是否支持多媒体回落。
默认值：
1。
∙=0：
对于所有多媒体呼叫，手机携带双BC，多媒体为第一个，语音为第二个，RI指示为“supportoffallback”，则视为手机支持多媒体回落到语音呼叫。
其它情况认为手机不支持多媒体回落。
∙=1：
按照协议24008-6a0中描述，对于模拟多媒体呼叫，手机携带双BC，多媒体为第一个，语音为第二个，RI指示为“supportoffallback”，则视为手机支持多媒体回落到语音呼叫。
对于UDI/RDI多媒体呼叫，手机携带双BC，多媒体为第一个，语音为第二个，RI指示为“supportofservicechangeandfallback”，则视为手机支持多媒体回落到语音呼叫。
其它情况认为手机不支持多媒体回落。
P1000（CM软参11）BIT1
该比特用于控制MSC再次给被叫终端发送的SETUP消息中的BC是多媒体BC还是语音BC。
默认值：
1。
∙=0：
发送语音BC。
∙=1：
发送多媒体BC。
特性规格
本特性无特殊规格。
应用限制
在此特性的使用过程中，有如下的限制：
∙呼叫建立过程中多媒体回落需要手机终端和MSCServer支持。
∙呼叫稳态后的多媒体回落需要手机终端、RNC、UMG和MSCServer支持。
∙UE必须支持发送和接收的SETUP消息中携带双BC（BearCapability，承载能力），第一个为多媒体BC，第二个为语音BC；同时必须支持SETUP消息里的RI指示为“supportoffallback”或“supportofservicechangeandfallback”。
如果手机即使携带了双BC（第一个为多媒体BC，第二个为语音BC），但RI值不正确，MSCServer则认为该呼叫只是一个普通视频呼叫，不支持多媒体回落。
∙从始发局到落地局的所有Nc接口必须走BICC或者SIP协议，中间不能有ISUP协议。
遵循标准
多媒体回落特性遵循标准如表4所示。
表4多媒体回落特性遵循的标准
标准类别
标准用途
标准名称
备注
3GPP协议
描述移动无线接口层三协议
3GPPTS24.008
-
3GPP协议
描述CS多媒体回落协议
3GPPTS23.172
-
发布历史
发布次数
发布时间
发布版本
发布说明
第一次发布
2009-05-30
V200R008C02
第一次在ATCA版本发布
父主题：
可选特性
华为所有和机密
版权所有©华为技术有限公司
升级会员 