[发明专利]在用户终端拒绝呼叫时网络反馈原因的方法

说明书

技术领域

本发明涉及一种实现HRPD网络和3G1x网络互操作过程中，如果用户拒绝来自1x网络的语音业务请求，如何更合理地反馈给1xMSC当前拒绝原因。其涉及通讯领域的HRPD网络和1x网络双网覆盖区域，两个网络互相操作互相配合的有关流程。

背景技术

目前，关于HRPD网络和3G1x网络之间的互操作性，在3GPP2 HRPDIOSA.S0008-B有这样的一个流程，参见图1：

步骤a.MSC确定在其服务范围内有个到双模终端用户的语音业务，MSC向HRPD的AN和一个或者多个1x系统的BS发送Paging Request消息.MSC在此消息中可以携带主叫用户的号码或者其他信息.

步骤b.HRPD AN在其网络发送一般寻呼消息给双模终端。如果MSC携带主叫用户的信息(步骤a)，则AN将这些信息包含在Feature Notification消息中，一并发给双模终端。

步骤c.双模终端用户决定不接受来话，终端发送Release Order消息给HRPD的AN.

步骤d.HRPD AN发送一个Rejection消息给MSC并显示终端将不接受来话。

同时，3GPP2 HRPD IOS A.S0009-B有类似的流程，参见图2。

步骤a.MSC确定在其服务范围内有个到双模终端用户的语音业务，MSC向HRPD的PCF和一个或者多个1x系统的BS发送Paging Request消息.MSC在此消息中可以携带主叫用户的号码或者其他信息.

步骤b.HRPD PCF发送A14-1x Service Page message给HRPD AN。该消息包括了General Page消息.如果MSC包括主叫用户的一些信息，则PCF也包含一个Feature Notification Message，它包含了主叫用户的信息.

步骤c.HRPD AN发送A14-1x Service Page Ack消息给HRPD PCF.

步骤d.HRPD AN发送General Page消息给双模终端。如果在步骤b携带主叫用户的信息，则AN将这些信息包含在Feature Notification消息中，一并发给双模终端。

步骤e.双模终端用户决定不接受来话，终端发送Release Order消息给HRPD的AN.

步骤f.HRPD AN发送A14-1xService Transfer消息给HRPD PCF.该消息包括从终端收到的Release Order消息.

步骤g.HRPD PCF发送一个Rejection消息给MSC并显示终端将不接受来话。

这些流程主要是反映：如果MS/AT用户驻留在HRPD网络，有来自1x网络的语音业务寻呼MS/AT，而用户决定不接此语音业务，HRPD AN或者HRPD PCF将向1x MSC回复带有原因的Rejection消息。

当前标准对于该Rejection是借用3G1x网络中的的定义，为适应以上流程，在该消息中增加了一个Cause IE(信息单元)。Cause IE定义了唯一的一个字段Cause Value＝08H，表示MS busy，用以告诉MSC来话被拒绝。

对于如上所定义的Cause Value＝08H(MS busy)，我们分析认为，它不能正确反映呼叫被拒绝的原因：

(1)AT/MS在HRPD系统是空闲状态。MSC的寻呼请求中带有主叫用户的号码，正是用户本身决定不接收来自1x的语音呼叫，用户按下拒绝键或者用户对来话寻呼不予以处理，最终导致AT/MS发送Release Order消息给AN。很显然这时“MS Busy”不是真正的拒绝理由；

(2)如果AT/MS在HRPD网络正在从事分组数据业务，用户主动拒绝来自1x的语音呼叫。显然，这个时候用户的拒绝是决定性的因素，并非MSBusy(MS忙)是因素(如果用户本身愿意接听该来话，完全可以停止HRPD网络的业务而去调频到1x网络续接来话)；

(3)如果AT/MS在HRPD网络正在从事分组数据业务，用户不理睬来自1x网络的语音业务请求，这可以理解为用户拒绝来自1x的语音呼叫。当对应的定时器超时后，AT/MS发送Release Order消息给HRPD AN。用户的不作为就是拒绝，这是决定性的因素，并非MS Busy(MS忙)是因素(如果用户本身愿意接听该来话，完全可以停止HRPD网络的业务而去1x网络续接)。