CN102448017A - 一种呼叫确认的方法、系统及移动台 - Google Patents

Abstract

本发明公开了一种呼叫确认的方法、系统及移动台，所述方法包括组呼发起移动台根据网络侧单元发送的确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述组呼发起移动台向所述网络侧单元发起呼叫确认，本发明通过以上技术方案，解决了组呼发起者无法进行呼叫确认的问题。

Description

一种呼叫确认的方法、系统及移动台

技术领域

本发明涉及移动通信技术领域，尤其涉及一种呼叫确认的方法、系统及移动台。

背景技术

组呼业务包括语音组呼业务(Voice Group Call Service，VGCS)和语音广播业务(Voice Broadcast Service，VBS)等，组呼业务是多方参与的通信方式，突破了点对点通信的局限性，能够快速建立呼叫。

一个特定的组呼通信由功能码和组呼区域唯一确定，组功能码与组呼区域合起来称为组呼参考，组功能码标识该组的功能，即由哪些身份的成员参考，一个用户可以同时签约多个组功能码，并给它们设置不同的优先级，组呼区域是指组呼通信所覆盖的范围，以无线小区为基本单位，可以由一个或几个小区组成，组成组呼区域的小区称为组呼小区。

一个终端发起组呼，网络侧单元在组呼区域的每个小区中建立1条组呼信道，并开始发送组呼通知信息，当属于此组的终端检测到通知消息后，会自动调整到组呼信道上收听。

由组呼业务的定义方式可以看出，网络侧单元并不知道究竟哪些用户参加了组呼通信，对于高优先级的组呼业务，尤其是紧急呼叫，实际应用中需要对参与者进行记录以备岗位事故后分析，因此，引入呼叫确认的概念。

呼叫确认是一个可选的过程，可以要求所有或指定的被叫用户发送一个确认接收到语音组呼的消息，如果一个组呼需要在呼叫结束后进行确认，有两种方式来指示被叫用户的移动台：

1、直接指示：在组呼的通知消息中设置确认标志AF；

2、间接指示：如果通知消息中没有设置确认标志，由被叫用户的移动台对比组呼优先级和确认门限值判断是否需要确认。

在上述现有方案中，不管是采用直接指示还是间接指示，移动台都只有在收到通知消息的前提下才能确定是否需要进行呼叫确认；而对于组呼的发起者，并不是根据通知消息加入到组呼中，所以现有方案中，组呼的发起者在组呼结束时不进行呼叫确认，也无法进行呼叫确认，导致网络侧单元无法正确的判断哪些成员参加了组呼。

发明内容

本发明提供一种呼叫确认的方法、系统及移动台，解决了组呼发起者无法进行呼叫确认的问题。

为解决上述技术问题，本发明采用以下技术方案：

一种呼叫确认的方法，组呼发起移动台根据网络侧单元发送的确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述组呼发起移动台向所述网络侧单元发起呼叫确认。

网络侧单元发送确认标志的方式包括：在网络侧单元向组呼发起移动台发送的连接Connect消息中携带确认标志。

所述连接Connect消息中携带确认标志的方式包括：在所述连接Connect消息的组呼参考信息中携带确认标志。

所述的连接Connect消息的组呼参考信息中携带确认标志的方式包括：在所述连接Connect消息的组呼参考信息中增加一个或多个比特的确认标志位。

当在连接Connect消息的组呼参考信息中增加一个比特的确认标志位时，如果所述确认标志位的值为0，则组呼发起移动台根据所述确认标志判断的结果为不需要进行呼叫确认；如果所述确认标志位的值为1，则组呼发起移动台根据所述确认标志判断的结果为需要进行呼叫确认。

一种呼叫确认系统，包括组呼发起移动台和网络侧单元，所述网络侧单元用于向组呼发起移动台发送确认标志，所述组呼发起移动台用于根据所述确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述组呼发起移动台向所述网络侧单元发起呼叫确认。

所述网络侧单元在向组呼发起移动台发送的连接Connect消息中携带确认标志。

所述网络侧单元在所述连接Connect消息的组呼参考信息中增加一个或多个比特的确认标志位。

当所述网络侧单元在所述连接Connect消息的组呼参考信息中增加一个比特的确认标志位时，如果所述确认标志位的值为0，则组呼发起移动台根据所述确认标志判断的结果为不需要进行呼叫确认；如果所述确认标志位的值为1，则组呼发起移动台根据所述确认标志判断的结果为需要进行呼叫确认。

一种移动台，所述移动台在作为组呼发起者时，用于根据网络侧单元发送的确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述移动台向所述网络侧单元发起呼叫确认。

本发明提供一种呼叫确认的方法、系统及移动台，组呼发起移动台根据网络侧单元发送的确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，该组呼发起移动台向网络侧单元发起呼叫确认，解决了现有技术中，组呼发起者无法进行呼叫确认的问题。

附图说明

图1为本发明实施例组呼建立流程图；

图2为本发明实施例组呼发起移动台发起呼叫确认的流程图。

具体实施方式

下面通过具体实施方式结合附图对本发明作进一步详细说明。

实施例一：

网络侧单元用于向组呼发起移动台发送确认标志，组呼发起移动台用于根据确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，组呼发起移动台向网络侧单元发起呼叫确认，其中，网络侧单元是基站收发台(Base Transceiver Station，BTS)、基站控制器(base stationcontroller，BSC)或移动交换中心(Mobile Switching Center，MSC)。

图1为本发明实施例组呼建立流程图，如图1所示：

步骤101：组呼发起移动台向基站子系统BSS发送随机接入信道请求消息，在信道请求中指示为发起呼叫；

步骤102：基站子系统收到信道请求消息后，通过立即指配消息将所分配的信道通知组呼发起移动台；

步骤103：组呼发起移动台在分配的信道上发送建链指示消息，指示要建立语音组呼业务；

步骤104：基站子系统将建链指示消息中CM业务请求(CMservice request)的内容发送给移动业务交换中心；

步骤105：移动交换中心确认组呼发起移动台预定了组呼业务后，向组呼发起移动台发送CM业务接受消息；

步骤106：组呼发起移动台收到CM业务接受消息后，向移动交换中心发送建立消息，该建立消息中包括该组呼的具体内容，比如组呼功能号、组呼优先级等；

步骤107：移动交换中心收到建立消息后，向基站子系统发送指配请求消息；

步骤108：基站子系统收到指配消息后，分配业务信道，然后向组呼发起移动台发送指配命令消息，告知组呼发起移动台所分配的业务信道；

步骤109：组呼发起移动台收到指配命令消息后，在分配的业务信道上向基站子系统发送指配完成消息；

步骤110：基站子系统收到指配完成消息后，向移动交换中心发送指配完成消息；

步骤111：移动交换中心收到指配完成消息后，向基站子系统发送组呼建立消息，开始直接建立SCCP(signal connection control part，信令连接控制部分)连接；

步骤112：SCCP建立成功，基站子系统向移动交换中心返回组呼建立确认消息；

步骤113：移动交换中心收到组呼建立确认消息，向所有相关的基站子系统发送组呼指配请求消息，其中包含组呼参考等信息，其中组呼参考信息中包含是否需要进行呼叫确认的标志位；

步骤114：基站子系统收到组呼指配请求消息后，分配组呼信道，向移动交换中心发送组呼指配结果消息；

步骤115：基站子系统根据组呼指配请求消息的内容，发送通知消息，通知预定了该组呼的其他业务用户加入组呼。通知消息中包含该组呼是否需要进行呼叫确认；

步骤116：移动业务交换中心向组呼发起移动台发送连接Connect消息，确认组呼已经建立，并在该连接Connect消息中携带呼叫确认标志，指示组呼发起移动台是否需要进行呼叫确认。

图2为本发明实施例组呼发起移动台发起呼叫确认的流程图，如图2所示：

组呼结束后，组呼发起移动台根据网络侧单元在连接Connect消息中携带的确认标志来判断是否需要进行呼叫确认，如果判断结果为需要进行呼叫确认，组呼发起移动台向网络侧单元发起呼叫确认；如果判断结果为不需要进行呼叫确认，呼叫确认的流程结束。

当前技术方案中连接Connect消息的组呼参考信息通常为：

<call reference>::＝reference{0 spare_4|1{priorityspare_1}}

其中，reference为参考(27bits)；该域为组呼参考或组呼标识十进制数字的二进制编码(参考3GPP TS 23.003)；priority为优先级(3bits)；spare_4为四比特填充(4bits)；spare_1为一比特填充(1 bit)。

本实施例的步骤116中，在连接Connect消息中携带呼叫确认标志的方式包括：在连接Connect消息的组呼参考信息中增加一个或多个比特的确认标志位(AF)，如：

<call reference>::＝reference AF{0 spare_3|1 priority}

即，组呼参考信息Call Reference中增加确认标志AF，该确认标志AF共一个比特，设定该确认标志AF的值为1时表示需要进行呼叫确认，为0时表示不需要进行呼叫确认；spare_3为三比特填充。

在实际应用过程中，在连接Connect消息的组呼参考信息中增加一个或多个比特的确认标志位(AF)可以有多种实施方式，还例如：

<call reference>::＝reference{0 spare_3|1 priority}AF

上述实施例，其他业务移动台可以根据接收到的通知消息中的确认标志位判断是否需要进行呼叫确认，组呼的发起者可以根据网络侧单元在连接Connect消息中携带的确认标志来判断是否需要进行呼叫确认，解决了组呼发起者无法进行呼叫确认的问题，也解决了背景技术中提到的：现有技术中组呼的发起者在组呼结束时不进行呼叫确认，也无法进行呼叫确认，导致网络侧单元无法正确的判断哪些成员参加了组呼的问题。

本发明实施例可以选择在网络侧单元向组呼发起移动台发送的连接Connect消息中携带确认标志，也可以通过其他方式携带确认标志，比如，在连接Connect消息之外，另行增加一条携带确认标志消息，发送给组呼发起移动台；或者在其他消息中携带确认标志，比如在指派请求和指派命令中携带确认标志等；现有技术中连接Connect消息中包括组呼参考信息，本发明实施例在连接Connect消息的组呼参考信息中携带确认标志，本发明不局限于在连接Connect消息的组呼参考信息中携带确认标志，在实施应用中，还可以通过在Connect消息中新增加一个信元来携带确认标志；连接Connect消息的组呼参考信息中携带确认标志的方式有多种，可以采用一个或多个比特的确认标志位，本发明实施例选择在连接Connect消息的组呼参考信息中增加一个比特的确认标志位，组呼发起移动台根据该确认标志位携带的信息判断是否需要进行呼叫确认，比如，该确认标志位AF的值为1时，表示需要进行呼叫确认，为0时表示不需要进行呼叫确认，当然，也可以设定确认标志位AF的值为1时，表示不需要进行呼叫确认，为0时表示需要进行呼叫确认；1个比特的确认标志位AF所携带的信息不限于本发明的实施例，可以有多种方式，确认标志位AF也不限于一个比特，可以包括多个比特。在本发明实施例的基础上可以延伸多种实施方式，只要满足组呼发起移动台可以从网络侧单元发送的消息中识别并判断是否需要进行呼叫确认即可。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (10)

1.一种呼叫确认的方法，其特征在于，组呼发起移动台根据网络侧单元发送的确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述组呼发起移动台向所述网络侧单元发起呼叫确认。

2.如权利要求1所述的方法，其特征在于，网络侧单元发送确认标志的方式包括：在网络侧单元向组呼发起移动台发送的连接Connect消息中携带确认标志。

3.如权利要求2所述的方法，其特征在于，所述连接Connect消息中携带确认标志的方式包括：在所述连接Connect消息的组呼参考信息中携带确认标志。

4.如权利要求3所述的方法，其特征在于，所述的连接Connect消息的组呼参考信息中携带确认标志的方式包括：在所述连接Connect消息的组呼参考信息中增加一个或多个比特的确认标志位。

5.如权利要求4所述的方法，其特征在于，当在连接Connect消息的组呼参考信息中增加一个比特的确认标志位时，如果所述确认标志位的值为0，则组呼发起移动台根据所述确认标志判断的结果为不需要进行呼叫确认；如果所述确认标志位的值为1，则组呼发起移动台根据所述确认标志判断的结果为需要进行呼叫确认。

6.一种呼叫确认系统，包括组呼发起移动台和网络侧单元，其特征在于，所述网络侧单元用于向组呼发起移动台发送确认标志，所述组呼发起移动台用于根据所述确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述组呼发起移动台向所述网络侧单元发起呼叫确认。

7.如权利要求6所述的系统，其特征在于，所述网络侧单元在向组呼发起移动台发送的连接Connect消息中携带确认标志。

8.如权利要求7所述的系统，其特征在于，所述网络侧单元在所述连接Connect消息的组呼参考信息中增加一个或多个比特的确认标志位。

9.如权利要求8所述的系统，其特征在于，当所述网络侧单元在所述连接Connect消息的组呼参考信息中增加一个比特的确认标志位时，如果所述确认标志位的值为0，则组呼发起移动台根据所述确认标志判断的结果为不需要进行呼叫确认；如果所述确认标志位的值为1，则组呼发起移动台根据所述确认标志判断的结果为需要进行呼叫确认。

10.一种移动台，其特征在于，所述移动台在作为组呼发起者时，用于根据网络侧单元发送的确认标志判断是否需要进行呼叫确认，当判断结果为需要进行呼叫确认的条件下，所述移动台向所述网络侧单元发起呼叫确认。

Images