CN101094134A - 一种释放集群通信业务的方法 - Google Patents

一种释放集群通信业务的方法 Download PDF

Info

Publication number
CN101094134A
CN101094134A CN 200610090062 CN200610090062A CN101094134A CN 101094134 A CN101094134 A CN 101094134A CN 200610090062 CN200610090062 CN 200610090062 CN 200610090062 A CN200610090062 A CN 200610090062A CN 101094134 A CN101094134 A CN 101094134A
Authority
CN
China
Prior art keywords
vgcs
vbs
communication service
release
cluster
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN 200610090062
Other languages
English (en)
Inventor
王宝义
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN 200610090062 priority Critical patent/CN101094134A/zh
Publication of CN101094134A publication Critical patent/CN101094134A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

本发明涉及移动通讯领域,特别的涉及在集群***中,在中继移动交换中心(Relay MSC)发起集群通信业务释放的一种释放集群通信业务的方法,其中该集群通信业务为,语音组呼业务(VGCS)、或者语音广播业务(VBS),本发明方法,在Relay MSC向Anchor MSC发送集群通信业务释放通知中,通过增加标识集群通信业务释放原因的信元,使释放通知携带释放原因信息,以使Anchor MSC除了可以根据该释放通知,完成集群通信业务释放外,还可以根据该释放通知中新增加的标识释放原因的信元的取值,获知导致集群通信业务释放的原因。并且后续可以根据该释放原因进行相应的网络资源优化,以改善当前网络资源配置状况,保证以后的集群通信业务能够顺利建立。

Description

一种释放集群通信业务的方法
技术领域
本发明涉及移动通讯领域,特别的涉及在集群移动通讯***中,在中继移动交换中心发起集群通信业务释放的一种释放集群通信业务的方法。
背景技术
众所周知,铁路是国家经济的一大动脉,而铁路通信是铁路运输生产的主动脉。建立一个安全、可靠、可持续发展的铁路***,关系着国计民生。目前在欧洲得到广泛试验应用的铁路全球通移动通讯***(Global System forMobile communication for Railway,简称GSM-R)作为一种先进的技术体系,为铁路专用通信提供了一个功能强大、业务丰富、稳定可靠的综合信息平台。其在我国的运用前景不容小窥。
GSM-R是在全球移动通信***(Global System for Mobile communication,简称GSM)基础上,增加集群通信功能而构成的一个铁路专用的移动通信***。所增加的集群功能包含先进的话音呼叫业务(Advanced Speech Call Item,简称ASCI)功能。
ASCI功能包含了三种专用移动通信的基本业务:增强的多级优先于强占权(Enhanced Multil-Level Precedence and Pre-emption,简称eMLPP)、语音组呼业务(Voice Group Call Service,简称VGCS)和语音广播业务(VoiceBroadcast Service,简称VBS)。其中VGCS业务是指多用户讲话,更多的用户可以听话(听者数量无限制)的业务;VBS是指一用户讲活,多用户听话(听者无限制)的业务。VGCS以及VBS实现了一部分用户讲话,多方聆听的点对多点语音通信方式,突破了点对点通信的局限性,有利于快速的建立呼叫。当VGCS只有一个用户讲话时,则为VBS,因此VBS业务可以看作VGCS业务的一种特例。
其中VGCS或VBS释放的实现是VGCS或VBS的基本功能,VGCS或VBS,可以被主叫业务用户、调度员释放。其中调度员直接向主控移动交换中心(Anchor Mobile Switching Centrer,简称Anchor MSC)提出释放VGCS或VBS的指示,由Anchor MSC直接根据该指示,执行VGCS或VBS释放策略;其中主叫业务用户可以在发起VGCS或VBS呼叫时建立的专有连接上释放VGCS或VBS,还可以在占用上行后,向其所在的移动交换中心(MobileSwitching Center,简称MSC)提出终止VGCS或VBS请求。如果该主叫业务用户所在的MSC为Anchor MSC,那么Anchor MSC接收到终止VGCS或VBS请求后,直接释放该小区内的VGCS或VBS,并通过对该VGCS或VBS区域的其他小区的中继MSC(简称Relay MSC)的管理控制,释放其他小区内的VGCS或VBS;如果该主叫业务用户所在的MSC为中继移动交换中心(RelayMobile Switching Centrer,简称Relay MSC),那么该Relay MSC接收到主叫业务用户发出的终止VGCS或VBS请求后,向Anchor MSC发送VGCS或VBS释放通知--MAP消息,其中在现有的3GPP协议的定义中,该MAP消息定义为:MAP_PROCESS_GROUP_CALL_SIGNALING消息,如表1所示为该MAP消息的信元参数,Relay MSC通过VGCS或VBS释放通知,通知AnchorMSC释放整个VGCS或VBS区域的VGCS或VBS。
MAP_PROCESS_GROUP_CALL_SIGNALLING service
  信元参数名称(Parameter name)  要求(Request)   标示(Indication)
  调用序号(Invoke Id)  M   M(=)
  上行请求(Uplink Request)  C   C(=)
  上行释放指示(Uplink Release Indication)  C   C(=)
  组呼释放(Release Group Call)  C   C(=)
表1
说明:Relay MSC可以使用MAP_PROCESS_GROUP_CALL_SIGNALLING中的信元Uplink Request用于通知Anchor MSC请求上行,信元UplinkRequest用于通知Anchor MSC释放上行,信元Release Group Call用于通知Anchor MSC释放呼叫。
另外,如果VGCS过程中,非激活定时器超时,网络也会自动释放VGCS。
一般的,我们根据VGCS或VBS被释放的原因,将VGCS或VBS释放分为正常释放、以及非正常释放。通常的,把上述的主叫业务用户、调度员主动提出终止VGCS或VBS请求,申请释放VGCS或VBS的情况,以及由于VGCS中非激活定时器超时,网络自动释放VGCS的情况称为VGCS或VBS的正常释放。
但是在实际应用中,除了上述的正常释放外,还可能由于网络故障的原因,导致VGCS或VBS被释放,比如当主叫业务用户在发起VGCS或VBS连接请求后,如果该主叫业务用户所在的小区的组呼或广播信道分配失败,或者该主叫业务用户所在小区内的基站控制器(Base Staton Controller,简称BSC)的呼叫控制连接建立失败等等,都会导致VGCS或VBS的被释放,我们把由于网络的原因导致VGCS或VBS的释放的情况,称为VGCS或VBS的非正常释放。
根据发起VGCS或VBS释放所在小区的不同,对于释放在的小区为Anchor MSC覆盖的小区的情况,无论该VGCS或VBS释放是的正常释放,或者非正常释放,由于Anchor MSC均直接接收到VGCS或VBS释放的请求,其中该释放请求消息包括以下几种情况:
调度员、在Anchor MSC覆盖小区内的主叫业务用户主动向Anchor MSC提出的终止VGCS或VBS请求;或者,VGCS过程中,Anchor MSC监测到非激活定时器超时;或者,在Anchor MSC覆盖小区内的主叫业务用户建立呼叫过程中,Anchor MSC接收到VGCS或VBS建立失败的消息;或者,在主叫调度员建立呼叫过程中,Anchor MSC接收到VGCS建立失败的消息等。
Anchor MSC根据所接收到的VGCS或VBS释放的请求,执行VGCS或VBS释放策略,并根据所接收到的VGCS或VBS释放的请求,直接获知释放的原因。
而对于在Relay MSC覆盖的小区内发起VGCS或VBS释放的情况,无论该VGCS或VBS释放是正常释放,或者非正常释放,由Relay MSC接收到VGCS或VBS释放的请求,其中该释放请求消息包括以下几种情况:
主叫业务用户主动提出终止VGCS或VBS请求;主叫业务用户在发起呼叫后,建立呼叫时,VGCS或VBS建立失败的消息等,Relay MSC根据所接收到的VGCS或VBS建立失败的消息,作出释放VGCS或VBS决策,然后向Anchor MSC发送VGCS或VBS释放通知--MAP消息:MAP_PROCESS_GROUP CALL_SIGNALING消息,(如表1所示),Anchor MSC根据接收到的MAP消息,执行VGCS或VBS释放策略。
然而,由表1可以知道,Anchor MSC所接收到的只是一个VGCS或VBS释放通知,而无法根据该释放通知,获知该VGCS或VBS被释放的真正原因。特别的,如果该释放是在VGCS或VBS建立时,由于网络资源不足,或网络故障,导致VGCS或VBS建立失败,无法成功建立,导致非正常释放的情况,Anchor MSC无从获知该网络故障,进而,无法针对该网络故障,作出相应的合理的处理,无法排除该网络故障,导致该网络故障继续可能影响以后的VGCS或VBS建立。
发明内容
本发明要解决的技术问题是:提供一种释放集群通信业务的方法,以实现在Relay MSC发起VGCS或VBS释放时,Anchor MSC能够获知VGCS或VBS释放原因,并可以根据VGCS或VBS释放原因,执行对网络资源的优化配置。
为解决上述技术问题,本发明的目的是通过以下技术方案实现的:
一种释放集群通信业务的方法,其中所述的集群通信业务释放在中继移动中心发起,包括以下步骤:
A、中继移动交换中心向主控移动交换中心发送集群通信业务释放通知,并指示所述集群通信业务释放原因。
B、主控移动交换中心根据所接收的集群通信业务释放通知,释放所述的集群通信业务。
本发明所述的方法中,优选地,所述步骤B后进一步包括以下步骤:
C、主控移动交换中心根据所接收的集群通信业务释放通知,获知所述的集群通信业务释放原因,根据所述的释放原因,配置网络资源。
本发明所述的方法中,所述步骤A具体包括以下步骤:
A1、所述的中继移动交换中心接收到由主叫业务用户发送的终止集群通信业务的请求消息;
A2、所述的中继移动交换中心根据所述的请求消息,向主控移动交换中心发送集群通信业务释放通知,并在所述的释放通知中增加标识集群通信业务释放原因的信元,并标识所述的释放原因。
本发明所述的方法中,所述步骤A具体包括以下步骤:
A3、所述的主叫业务用户在发起集群通信业务呼叫后,并且,所述的中继移动交换中心在向主叫业务用户所在小区的基站控制***请求分配集群通信业务信道后,接收到由所述基站控制***发送的主叫业务用户所在小区的集群通信业务信道分配失败的消息;
A4、所述的中继移动交换中心根据所述的集群通信业务信道分配失败的消息,向主控移动交换中心发送集群通信业务释放通知,并在所述的释放通知中增加标识集群通信业务释放原因的信元,并标识所述释放原因。
本发明所述的方法中,优选地,所述步骤C具体包括以下步骤:
C1、主控移动交换中心根据所述的释放通知中标识集群通信业务释放原因的信元所标识的集群通信业务释放原因,增加主叫所在的基站控制***中的信道资源。
本发明所述的方法中,所述步骤A具体包括以下步骤:
A5、所述的主叫业务用户在发起集群通信业务呼叫后,所述的中继移动交换中心在为所述的集群通信业务,向主叫业务用户所在的基站控制***请求建立控制连接后,接收到由所述基站控制***发送的呼叫控制连接建立失败的消息;
A6、所述的中继移动交换中心根据所述的呼叫控制连接建立失败的消息,向主控移动交换中心发送集群通信业务释放通知,并在所述的释放通知中增加标识集群通信业务释放原因的信元,并标识所述释放原因。
本发明所述的方法中,优选地,所述步骤C具体包括以下步骤:
C2、主控移动交换中心根据所述的集群通信业务释放消息中标识释放原因的信元所标识的集群通信业务释放原因,增加主叫业务用户所在的基站控制***中的控制单元。
本发明所述的方法中,所述的集群通信业务为:语音组呼业务、或者语音广播业务。
以上技术方案可以看出,本发明相对于现有技术,具有以下的优点:
首先,由于在Relay MSC向Anchor MSC发送的如表1所示的VGCS或VBS释放通知中,新增加了包含标识释放原因的信元,因而,当在Relay MSC发起VGCS或VBS释放的时候,Anchor MSC既可以根据该释放通知,执行VGCS或VBS释放策略;还可以根据该释放通知中标识VGCS或VBS释放原因的信元的取值,获知该VGCS或VBS释放原因,并根据该释放原因,合理的配置网络资源。
其次,本发明方法只需要对Relay MSC向Anchor MSC发送的VGCS或VBS释放通知中,增加一标识VGCS或VBS释放原因的信元,并对Relay MSC与Anchor MSC之间的通信协议作一小改动,既能使得Anchor MSC接收到该携带标识VGCS或VBS释放原因的信元的释放通知时,能够根据该信元的取值,获知VGCS或VBS释放的原因,而无需改变现有的集群移动***网络的组网方式,本发明的技术方案易于实施。
附图说明
图1为VGCS逻辑概念示意图;
图2为主叫业务用户在Anchor MSC内发起VGCS和释放VGCS的消息流程示意图;
图3为主叫业务用户在Anchor MSC内发起VBS和释放VBS的消息流程示意图;
图4为现有技术中,由主叫业务用户在建立VGCS呼叫时,在专有连接上,向Relay MSC主动申请释放VGCS,在Relay MSC发起VGCS释放的消息流程示意图;
图5为现有技术中,由主叫业务用户在建立VBS呼叫时,在专有连接上,向Relay MSC主动申请释放VBS,在Relay MSC发起VBS释放的消息流程示意图;
图6为现有技术中,主叫业务用户在申请上行后,向Relay MSC主动申请释放VGCS,在Relay MSC发起VGCS释放的消息流程示意图;
图7为本发明实施例1中的主叫业务用户申请上行后,在Relay MSC发起VGCS释放的消息流程示意图;
图8为本发明实施例1中的为主叫业务用户在建立VBS后,向Relay MSC请求释放VBS的消息流程示意图;
图9为本发明实施例2中的主叫业务用户发起VGCS请求后,BSS为业务分配信道失败时,在Relay MSC发起VGCS释放的消息流程示意图;
图10为本发明实施例2中的主叫业务用户发起VBS请求后,BSS为业务分配信道失败时,在Relay MSC发起VBS释放的消息流程示意图;
图11为本发明实施例3中的主叫业务用户发起VGCS请求后,BSC呼叫建立连接建立失败时,在Relay MSC发起VGCS释放的消息流程示意图;
图12为本发明实施例3中的主叫业务用户发起VBS请求后,BSC呼叫建立连接建立失败时,在Relay MSC发起VBS释放的消息流程示意图。
具体实施方式
本发明的核心思想是,通过对Relay MSC向Anchor MSC发送VGCS或VBS释放通知,在该VGCS或VBS释放通知中,增加标识VGCS或VBS释放原因的信元,使得Anchor MSC除了可以根据该VGCS或VBS释放通知,完成VGCS或VBS释放外,还可以根据该释放通知中新增加的标识VGCS或VBS释放原因的信元的取值,获知导致VGCS或VBS释放原因,并根据该释放原因,进行相应的网络资源配置,以改善当前网络资源状况,保证以后的VGCS或VBS能够顺利建立。
图1所示为VGCS逻辑概念示意图,图中的VGCS1、VGCS2、VGCS3分别表示预定义在网络中的VGCS;A、B、C、D表示在网络中签约VGCS或VBS的组标识(Group ID)分别为a、b、c、d的业务用户;I、II、III、IV分别为VGCS区域(Group call area);w、x、y、z分别表示在网络中被标识为调度员(Dispatcher)的固定或移动用户。
为了使本领域的技术人员多本发明所述的VGCS业务有总体上了解,以下结合图1对VGCS业务的逻辑概念作详细的说明:
1、VGCS呼叫具体为使一个主叫用户、或者主叫调度员能够建立到目标用户的语音组呼。其中,VGCS预定义在网络中的,由Group ID和Group call area唯一标识。如上图中的Group ID:a和Group call area:I,标识出了VGCS1。
2、主叫用户和目标用户均可以是业务用户或调度员用户。
3、目标用户指的是位于VGCS区域中的由被呼Group ID标识的业务用户或调度员用户。目标业务用户应该被网络用Group ID来“通知”组呼已经发生,而不是通过“寻呼”的方式;目标调度员用户应该通过被叫标识来呼叫。业务用户进入VGCS区域后,接收到相应的VGCS通知后,可以成为目标业务用户。离开VGCS区域的目标业务用户将终止目标用户的身份。如上图中group call area I中的A用户为VGCS1的目标用户,而区域外的A用户和其它用户(B、C等)不是VGCS1的目标用户。
4、VGCS呼叫应该建立在由小区构成的VGCS区域中(VGCS区域预先配置在网络中)。当业务用户发起VGCS呼叫时,VGCS区域将被业务用户发起呼叫所在小区和所拨打的Group ID唯一确定。发起VGCS呼叫的调度员应该连接到其对应的VGCS区域,并且网络应该根据调度员标识核查调度员是否能够发起呼叫。一个调度员可以被网络预配置到多个VGCS呼叫中,调度员通过含有VGCS参考的移动台国际ISDN综合业务数字网号码(MobileStation International  Integrated  Services Digital Network Number,简称MSISDN)发起呼叫的方式来确定其发起的VGCS。VGCS呼叫建立后,所有的调度员都会被接通,并且VGCS区域中的每个小区均会建立一条VGCS通道。组呼通道是公共通道,在小区中的业务用户都会监听此通道。VGCS区域中,只有SIM卡中存储相应组ID的业务用户手机才会加入到VGCS。业务用户通过VGCS通道接入网络时,无需与网络交互消息,接入的速度要比普通的点到点呼叫寻呼快。
5、VGCS业务呼叫在任何时刻只准许1个讲者业务用户及至多5个调度员同时讲话。调度员用户应该能够听到除自己外的其他讲者的讲话,听者业务用户能够听到所有讲者用户的讲话。当有调度员讲话时,讲者业务用户应该得到可听指示。调度员可以随时讲话无需附加的信令,而希望讲话的业务用户则需要附加信令指示其想讲话。当没有讲者业务用户存在时,听者业务用户才可能成为讲者业务用户。业务用户按照先来先得的方式获得发言权,而无需队列。讲者业务用户停止讲话时应该给网络指示或网络通过定时器超时等机制来确定没有讲者业务用户存在。
6、如果VGCS已经建立成功,则网络应该通知主叫用户,以便主叫用户可以讲话。***应该提供给业务用户变为讲者的机制。
7、VGCS呼叫中对调度员和主叫业务用户可以有鉴权、加密的处理。
8、在同一个VGCS区域中可以同时存在多个不同Group ID的VGCS。在不同的VGCS区域中也可以同时存在多个相同Group ID的组呼。
9、VGCS呼叫能够被主叫业务用户,授权的调度员或网络释放。主叫调度员只有占用了上行后,才能够释放VGCS。如果VGCS过程中无语音定时器超时,网络将会自动释放呼叫。业务用户及调度员也可以离开组呼而不影响剩余部分继续通话。离开VGCS的成员还可以通过拨打组呼的方式返回组呼。
10、如果业务用户(包括讲者业务用户和听者业务用户)离开VGCS区域,则此业务用户应该离开VGCS,但VGCS仍然继续而不受影响。
11、VGCS业务呼叫可以支持漫游。
12、业务用户可以激活或激活Group ID,去、激活的信息与Group ID信息一起存储在业务用户终端SIM卡中。如果有高优先级的组呼发生,则业务用户终端有可能终止激活Group ID而参与VGCS。如果调度员用户同时作为业务用户而签约了同一个Group ID,则该调度员用户在对应的VGCS区域中时,应该激活对应的Group ID,以避免对调度员的寻呼和通知(含有Group ID)的冲突。
13、VGCS区域超过一个MSC的覆盖范围时,该组呼中会有多个MSC,其中的主控MSC为Anchor MSC,其他MSC为Relay MSC。Anchor MSC负责整个呼叫,管理的数据有VGCS属性、调度员列表、Relay MSC列表、AnchorMSC内的VGCS小区列表、VGCS状态标志(是否ongoing)。Relay MSC负责管理的数据有Relay MSC内的VGCS小区列表、Anchor MSC标识、VGCS状态标志(是否ongoing)。一个VGCS呼叫中,可以有多个Relay MSC,也可以不存在Relay MSC。
VBS***逻辑结构与VGCS的相似,所不同的是,在VBS中,只能由业务用户发起VBS呼叫,而不能调度员发起VBS呼叫,并且,业务用户成功发起,并建立VBS,一直占用语音信道,直到该VBS被释放为止。同时,VBS可以由具有释放业务用户VBS权限的调度员、或者发起该VBS的主叫业务用户释放。
对于VGCS或VBS的发起是由业务用户发起的情况,具体是由业务用户在移动台上输入Group ID号,选择VGCS或VBS服务类型来发起VGCS或VBS呼叫,Group Call Area ID将被业务用户发起呼叫所在小区标识和所拨打的Group ID唯一确定。Group ID和Group Call Area ID构成组呼或广播参考来唯一确定一个VGCS或VBS呼叫,如下:
    Group call area ID     Group ID
其中,Group ID的长度范围为1~6;Group Call Area ID唯一的标识网络中的一个VGCS或VBS区域。
组呼或广播(Group Call Reference)唯一的标识网络中的一个VGCS或VBS,组呼或广播参考由Group ID和Group Call Area构成,最大长度为8个数字。Group ID和Group Call Area组合的最大数量为108
对于VGCS的发起是由调度员发起的情况,调度员通过直接拨打组呼参考号码,来发起VGCS呼叫。Anchor MSC接收到VGCS发起请求后,检查该组呼参考对应的VGCS是否正在进行中,如果是,表示该VGCS已经建立,则直接将该调度员加入到VGCS中;如果否,表示该VGCS还没有建立,则建立该VGCS。
VGCS或VBS的释放,既可以在VGCS或VBS建立后,由主叫业务用户、主叫调度员、或者具有VGCS或VBS释放权限的调度员释放,也可以由AnchorMSC通过,非激活定时器监测到VGCS的无语音超时,而自动释放;还可以在VGCS或VBS建立过程中,由于该主叫业务用户所在小区的网络资源不足,而导致VGCS或VBS无法成功建立,而被释放。VGCS或VBS释放,既可能在Anchor MSC覆盖的小区内发起,也可能在Anchor MSC覆盖的小区外,在RelayMSC覆盖的小区内发起。
对于在Anchor MSC发起VGCS或VBS释放的情况,通常有以下几种情况:
第一种情况:发起VGCS或VBS呼叫的个体为业务用户,并且该主叫业务用户在该Anchor MSC覆盖的小区内,(如图2所示为主叫业务用户在AnchorMSC内发起VGCS和释放VGCS的消息流程示意图,如图3所示为主叫业务用户在Anchor MSC内发起VBS和释放VBS的消息流程示意图),由图可见,该主叫业务用户可以在VGCS或VBS建立时,或者VGCS或VBS建立后,向AnchorMSC发送TERMINTION_REQ消息,通知Anchor MSC执行VGCS或VBS释放策略。
第二种情况:发起VGCS或VBS呼叫的个体为业务用户,并且该主叫业务用户在该Anchor MSC覆盖的小区内,如果在建立VGCS或VBS呼叫过程中,由于该小区内的VGCS或VBS信道分配失败,或者,该小区的BSC的呼叫控制连接建立失败,而导致VGCS或VBS无法建立时,该小区内的基站***(BaseStation System,简称BSS),即Anchor BSS,Anchor BSS根据具体的原因,向Anchor MSC返回VGCS或VBS信道分配失败的消息、或者小区的BSC的呼叫控制连接建立失败的消息,Anchor MSC根据所返回的消息,执行VGCS或VBS释放策略。
第三种情况:发起在VGCS呼叫的个体为调度员,而无论主叫调度员是否处于Anchor MSC覆盖的小区内,当该主叫调度员占有上行后,该主叫调度员向Anchor MSC释放VGCS指示,通知Anchor MSC执行VGCS释放策略。
第四种情况:无论呼叫的个体为业务用户,或者为调度员,并且无论该主叫业务用户、或者主叫调度员是否在Anchor MSC所覆盖的小区内,具有VGCS或VBS释放权限的调度员,向Anchor MSC发送释放VGCS或VBS指示,通知Anchor MSC执行VGCS或VBS释放策略。
明显地,对于在Anchor MSC发起VGCS或VBS释放的情况,Anchor MSC直接接收到业务用户或调度员发送的终止VGCS或VBS请求消息,或者,接收到本小区内的BSS向Anchor MSC发送的导致VGCS或VBS释放的消息,AnchorMSC能够获知VGCS或VBS释放的原因。
对于在Relay MSC发起VGCS或VBS释放的情况,通常有以下几种情况:
第一种情况:发起VGCS或VBS呼叫的个体为业务用户,并且该主叫业务用户不在该Anchor MSC覆盖的小区内,如图4、图5所示,主叫业务用户在建立VGCS或VBS呼叫时,向Relay MSC发送TERMINTION_REQ消息;RelayMSC接收到该TERMINTION_REQ消息后,向Anchor MSC在Anchor MSC之间的主叫业务用户专用连接上,发送包含原因值为“normal call clearing”的RELEASE消息,通知Anchor执行VGCS或VBS释放策略。
第二种情况:发起VGCS呼叫的个体为业务用户,并且该主叫业务用户不在该Anchor MSC覆盖的小区内。如图6所示,主叫业务用户在建立VGCS呼叫后,并成功申请上行后,向Relay MSC发送TERMINTION_REQ消息;Relay MSC接收到该TERMINTION_REQ消息后,Relay MSC在消息PROCESS_GROUP_CALL_SIGNAL中包含release group call标识来通知Anchor MSC释放VGCS。
第三种情况:发起VGCS或VBS呼叫的个体为业务用户,并且该主叫业务用户不在该Anchor MSC覆盖的小区内。当主叫业务用户在发起VGCS或VBS呼叫请求后,VGCS或VBS建立不成功,比如由于该主叫业务用户所在的小区内的VGCS或VBS信道分配失败,或者,该主叫业务用户所在的小区的BSC的呼叫控制连接建立失败,导致VGCS或VBS无法建立时,该小区内的Relay BSS根据具体的原因,向Relay MSC返回VGCS或VBS信道分配失败的消息、或者小区的BSC的呼叫控制连接建立失败的消息,Relay MSC根据所返回的消息,作出VGCS或VBS释放策略,并向Anchor MSC发送消息PROCESS_GROUP_CALL_SIGNAL,来通知Anchor MSC执行VGCS或VBS释放策略。
下面具体针对VGCS或VBS释放,在Relay MSC覆盖的小区内发起的情况,对本发明的技术方案进行具体分析:
为了使Anchor MSC收到的VGCS或VBS释放通知,执行VGCS或VBS释放策略的同时,还可以根据该VGCS或VBS释放通知,获知VGCS或VBS释放的真正原因,本发明对Relay MSC发给Anchor MSC的VGCS或VBS释放通知--MAP消息:MAP_PROCESS_GROUP CALL_SIGNALLING消息,作了扩展,在MAP消息中,增加一携带VGCS或VBS释放原因的信元。扩展后的MAP消息定义如表2所示:
MAP_PROCESS_GROUP CALL_SIGNALLING service
信元参数名称(Parameter name)  要求(Request)   标示(Indication)
调用序号(Invoke Id)  M   M(=)
上行请求(Uplink Request)  C   C(=)
上行释放请求(Uplink Release Indication)  C   C(=)
组呼释放请求(Release Group Call)  C   C(=)
释放原因(Release Cause)  C   C(=)
表2
说明:扩展后的MAP_PROCESS_GROUP CALL_SIGNALLING消息中新增加的信元Release Cause为:标识VGCS或VBS释放原因的信元。
当Relay MSC接收到VGCS或VBS释放的请求后,作出VGCS或VBS释放的决策,并根据所接收到的VGCS或VBS释放的请求所获知的VGCS或VBS释放的原因,对消息MAP_PROCESS_GROUP CALL_SIGNALLING中的信元Release Cause进行取值,以使标识Release Cause信元的取值,标识VGCS释放的真正原因。
通过预定义Relay MSC以及Anchor MSC之间的通讯协议,可以根据RelayMSC获知的VGCS或VBS释放的不同原因,对信元Release Cause取不同的值。比如:Release Cause为:00时,表示VGCS或VBS释放原因为:正常释放;ReleaseCause为:01时,表示VGCS或VBS释放原因为:主叫业务用户所在小区的VGCS或VBS控制连接建立失败;Release Cause为:10时,表示VGCS或VBS释放原因为:主叫业务用户所在小区的VGCS或VBS信道分配失败。
值得说明的是,上述对信元Release Cause取值的预定义方法,只是为了便于技术人员理解的一种举例,而不能作为本发明技术方案的限制,在实际应用中,还可以由本发明的原理的引申,采用其他的预定义的方法,而使得ReleaSeCause信元的取值,与VGCS或VBS释放的原因相对应,使得Relay MSC根据获知的VGCS或VBS释放的不同原因,对消息:MAP_PROCESS_GROUPCALL_SIGNALLING中的Release Cause信元的取不同的值,而Anchor MSC根据接收到的消息:MAP_PROCESS_GROUP CALL_SIGNALLING,根据消息中的Release Cause信元的取值,可以获知该VGCS或VBS释放的真实原因。
总之,可以在集群通信***中,根据业务需要,以及可能导致VGCS或VBS释放的原因,对可能的原因进行分类,并根据各类型原因,预设各不相同的Release Cause值,使Release Cause值分别与VGCS或VBS释放的原因一一对应,Relay MSC根据VGCS或VBS释放的具体原因,使信元Release Cause取不同的值,当Anchor MSC接收到MAP_PROCESS_GROUP CALL_SIGNALLING消息时,根据信元Release Cause的取值,获知该VGCS或VBS释放的具体原因。这样,便实现了在Relay MSC发起VGCS或VBS释放时,Anchor MSC可以获知VGCS或VBS释放的具体原因,可以针对其VGCS或VBS释放的原因,采取相应的网络资源配置策略。
为了使本领域的技术人员更好的理解本发明的技术方案,以下结合附图以及具体实施例对在Relay MSC内释放VGCS或VBS做详细的说明:
实施例1:
本实施例针对主叫用户在VGCS或VBS建立后,主动向其所在小区的RelayMSC请求释放VGCS或VBS的情况,说明本发明的技术方案。
图7为主叫业务用户申请上行后,向Relay MSC请求释放VGCS的消息流程示意图,如图示,主叫业务用户申请上行后,向其所在小区内的Relay MSC发送请求终止VGCS的消息:TERMINATION_REQ消息,Relay MSC接收到TERMINATION_REQ消息后,向中继组呼寄存器(Relay Group call register,简称Relay GCR)发送VGCS TERMIN消息,以指示Relay GCR将相应的组呼状态置为空闲(IDLE),并Relay MSC向主叫业务用户返回VGCS释放消息:TERMIBNATION消息,指示用户可以终止VGCS,显然,Relay MSC根据TERMINATION_REQ消息,可以获知VGCS释放的原因为:主叫业务用户在申请上行后,主动请求终止VGCS。并根据所获知的VGCS释放的原因,将MAP_PROCESS_GROUP CALL_SIGNALLING消息中的Release Cause值取为所预设的,该VGCS释放原因对应的Release Cause取值,设预设该原因所对应的预设的信元Release Cause的取值为:00,并将该携带了取值后的信元ReleaseCause的MAP_PROCESS_GROUP CALL_SIGNALLING消息,发送给AnchorMSC,Anchor MSC接收到该MAP消息后,Anchor MSC接收到该MAP消息后,执行释放VGCS策略,具体如下:
Anchor MSC向主组呼寄存器(Anchor Group call register,简称AnchorGCR)发送VGCS_TERMIN消息,以指示Relay GCR将相应的组呼状态置为IDLE,并且Anchor MSC向所在的小区的基站***(Basic Station System,简称BSS),即图中的Anchor BBS,发送CLERE_CMD命令,以指示Anchor BSS释放该VGCS的信道资源,Anchor BSS根据命令完成网络资源释放后,返回CLEAR_CMP消息至Anchor MSC,通知Anchor MSC其VGCS网络资源释放完成;同时的,Anchor MSC向Relay MSC返回SEND_GROUPCALL_SIGNAL_ACK消息,以指示Relay MSC释放其与Anchor MSC之间的MAP会话,并向Relay MSC发送REALEASE消息,以指示Relay MSC释放Anchor MSC与Relay MSC之间的话路连接,Relay MSC接收到该SREALEASE消息或SEND_GROUP_CALL_SIGNAL_ACK消息后,向其所在小区的RelayBSS,发送CLEAR_CMD命令,以指示Relay BSS释放该VGCS占用的网络资源;Relay BSS接到CLEAR_CMD命令后,向业务用户发送CHANNEL_RELEASE消息,指示业务用户释放该业务用户与Relay BSS之间的信道资源;Relay BSS释放网络资源完成后,向Relay MSC返回CLEAR_CMP消息,报告Relay BSS中的网络资源释放完成;Relay MSC接收到该CLEAR_CMP消息后,向AnchorMSC发送RELEASE_COMPLETE消息,报告Relay MSC所在网络的网络资源释放完毕。
图8为主叫业务用户在建立VBS后,向Relay MSC请求释放VBS的消息流程示意图,如图示,主叫业务用户成功建立VBS后,向其所在小区内的Relay MSC发送请求终止VBS的消息:TERMINATION_REQ消息,Relay MSC接收到TERMINATION_REQ消息后,向中继组呼寄存器(Relay Group call register,简称Relay GCR)发送VBS_TERMIN消息,以指示Relay GCR将相应的广播状态置为IDLE,并且Relay MSC向主叫业务用户返回VBS释放消息:TERMIBNATION消息,指示用户可以终止VBS,显然,Relay MSC根据TERMINATION_REQ消息,可以获知VBS释放的原因为:主叫业务用户主动请求终止VBS。并且Relay MSC根据所获知的VBS释放的原因,将MAP_PROCESS_GROUP_CALL_SIGNALLING消息中的Release Cause值取为预设的,该VBS释放原因对应的Release Cause取值,设预设该原因所对应的预设的信元Release Cause的取值为:00,并将该携带了取值后的信元Release Cause的MAP_PROCESS_GROUP_CALL_SIGNALLING消息,发送给Anchor MSC,Anchor MSC接收到该MAP消息后,Anchor MSC接收到该MAP消息后,释放本小区内的VBS,并且通过控制管理其他小区的Relay MSC,释放VBS区域的其它小区的VBS。
如果VGCS或VBS区域除了该Anchor MSC以及主叫业务用户所在的RelayMSC的覆盖范围外,还包括其他的小区,即VGCS或VBS区域还包含有一个或一个以上的Relay MSC,那么Anchor MSC在收到MAP_PROCESS_GROUPCALL_SIGNALLING消息后,对其他的Relay MSC执行的VGCS或VBS释放控制策略,与对上述主叫业务用户所在的网络中的Relay MSC执行的VGCS或VBS释放控制策略相同,在此不做赘述。
Anchor MSC可以根据MAP_PROCESS_GROUP CALL_SIGNALLING消息,执行相应的VGCS或VBS释放控制策略外,还可以根据所接收到的MAP_PROCESS_GROUP CALL_SIGNALLING消息中的Release Cause信元的取值(00),获知该VGCS或VBS释放为正常释放,获知该VGCS或VBS释放不是由于网络故障引起的,不需考虑对当前的网络资源进行优化配置。
实施例2:
本实施例针对主叫业务用户所在的小区的VGCS或VBS信道分配失败导致VGCS或VBS释放的情况,具体说明本发明的技术方案。
如图9为主叫业务用户发起VGCS请求后,BSS为业务分配信道失败时,在Relay MSC发起VGCS释放的消息流程示意图,图10为本发明实施例2中的主叫业务用户发起VBS请求后,BSS为业务分配信道失败时,在Relay MSC发起VBS释放的消息流程示意图,如图9、10所示,主叫业务用户通过其所在小区内的Relay BSS,向该小区的Relay MSC发起VGCS、或VBS请求后,当MSC_R根据该VGCS或VBS请求,向主叫业务用户所在的小区内的Relay BSS,发送VGCS_ASS_REQ请求消息、或VBS_ASS_REQ请求消息,请求该Relay BSS为该VGCS或VBS分配业务信道,如果该Relay BSS接收到该VGCS_ASS_REQ请求消息、或VBS_ASS_REQ请求消息后,根据该VGCS_ASS_REQ请求消息、或VBS_ASS_REQ请求消息,为该VGCS或VBS分配信道。如果该Relay BSS为该VGCS或VBS信道分配失败时,该Relay BSS向Relay MSC,返回VGCS_ASS_FAILURE消息、或VBS_ASS_FAILURE消息,告知Relay MSC信道分配失败,Relay MSC接收到VGCS_ASS_FAILURE消息、或VBS_ASS_FAILURE消息后,作出释放VGCS或VBS的决策,并向其所在小区内的Relay GCR发送VGCS_TERMIN消息、或VBS_TERMIN消息,指示该RelayGCR将其相应的组呼、或广播状态置为IDLE(空闲),Relay MSC向主叫业务用户返回VGCS或VBS释放消息:TERMIBNATION消息,指示该主叫业务用户终止该VGCS或VBS。
显然的,Relay MSC根据接收到的VGCS_ASS_FAILURE消息、或VBS_ASS_FAILURE消息,获知VGCS或VBS释放的原因为:该主叫业务用户所在小区的话务量较高或无线信道资源过少,不能满足所请求的VGCS、或VBS需要,VGCS或VBS信道分配失败,并根据所获知的VGCS或VBS释放原因,在MAP_PROCESS_GROUP CALL_SIGNALLING消息中增加信元ReleaseCause,并根据所预设的Release Cause信元取值方法,对Release Cause信元进行取值,设预设该VGCS或VBS释放原因:信道分配失败,所对应的信元ReleaseCause取值为10,则将MAP_PROCESS_GROUP_CALL_SIGNALLING消息中信元Release Cause取值为:10,然后将该携带了取值为10的信元Release Cause的MAP_PROCESS_GROUP CALL_SIGNALLING消息,发送给Anchor MSC;Anchor MSC接收到该MAP消息后,执行释放VGCS或VBS策略,本实施例中,Anchor MSC接收到MAP_PROCESS_GROUP CALL_SIGNALLING消息后,执行释放VGCS或VBS策略,该释放VGCS或VBS策略与实施例1中的释放VGCS或VBS策略相同,在此不作赘述。
Anchor MSC根据所接收到的VGCS或VBS释放通知:MAP_PROCESS_GROUP CALL_SIGNALLING消息中的Release Cause信元的值(取值为10),可以获知该VGCS或VBS释放是由于:该主叫业务用户所在小区的话务量较高或无线信道资源过少,不能满足所请求的VGCS或VBS需要,VGCS或VBS信道分配失败所导致的。并且,Anchor MSC可以根据该VGCS或VBS释放的原因,重新配置该小区的网络资源。比如:既可以通过Anchor MSC为该组呼/广播设置较高的eMLPP优先级抢占该小区内的部分优先级较低的VGCS或VBS点对点呼叫;还可以在该小区内增加新的BSS,加分小区,以增加原小区内的网络资源。具体执行何种网络资源配置策略,可以根据实际需要,以及便利情况,进行选择。
而对于本实施中的VGCS或VBS释放的情况,如果采用现有的技术方案,Anchor MSC所接收到的释放通知:MAP_PROCESS_GROUP_CALLSIGNALLING消息,不包含信元Release Cause,Anchor MSC无从得知该VGCS或VBS释放是由于主叫业务用户所在小区的话务量较高或无线信道资源过少,导致VGCS或VBS信道分配失败引起的,也就不会针对该原因,做出重新配置网络资源的策略,增加该小区的话务资源或无线资源。当该小区内,第二次、或以后有新的VGCS或VBS发起时,仍然可能由于该小区内的话务量较高或无线信道资源过少,无法成功建立VGCS或VBS。
实施例3:
实施例针对主叫业务用户在其所在小区的BSC呼叫控制建立连接失败导致VGCS或VBS释放的情况,说明本发明的技术方案。
图11所示为主叫业务用户发起VGCS请求后,BSC呼叫建立连接建立失败时,在Relay MSC发起VGCS释放的消息流程示意图。图12所示为的主叫业务用户发起VBS请求后,BSC呼叫建立连接建立失败时,在Relay MSC发起VBS释放的消息流程示意图。如图11、12示,该主叫业务用户,通过其所在网络的Relay BSS向的Relay MSC发起VGCS或VBS请求,并且该主叫业务用户所在的Relay BBS成功为所发起的VGCS或VBS分配了VGCS或VBS信道,当RelayMSC向主叫业务用户所在的Relay BSS发送VGCS_SETUP请求消息、或VBS_SETUP请求消息,请求该Relay BSS为该VGCS或VBS建立呼叫控制连接后,Relay BSS接收到该请求消息后,Relay BSS根据请求消息,为该VGCS或VBS建立相应的呼叫控制连接,如果由于该Relay BSS中的BSC的控制资源不够,导致该呼叫控制连接建立失败时,该Relay BSS向Relay MSC反馈VGCS_SETUP_REFUSE消息、或VBS_SETUP_REFUSE消息,以通知RelayMSC该呼叫控制连接建立失败的结果,Relay MSC接收到VGCS_SETUP_REFUSE消息、或VBS_SETUP_REFUSE消息后,作出释放VGCS或VBS的决策,并向其所在网络对应的Relay GCR发送VGCS_TERMIN消息、或VBS_TERMIN消息,Relay GCR将相应的组呼、或广播状态置为IDLE(空闲);同时,Relay MSC向主叫业务用户返回VGCS或VBS释放消息:TERMINATION消息,指示用户终止VGCS或VBS。
显然的,Relay MSC根据接收到的VGCS_ASS_FAILURE消息,获知VGCS或VBS释放的原因为:该主叫业务用户所在的BSC控制资源缺乏,无法为所请求的VGCS或VBS分配所需的呼叫控制连接分配相应的控制单元。并根据所获知的VGCS或VBS释放的原因,在MAP_PROCESS_GROUP_CALLSIGNALLING消息中增加信元Release Cause,并根据所预设的信元ReleaseCause取值方法,对Release Cause信元进行取值,设预设该VGCS或VBS释放原因:呼叫控制连接建立失败,所对应的信元Release Cause取值为01,那么将信元Release Cause取值为01,然后,将该携带了信元Release Cause为01的MAP_PROCESS_GROUP CALL_SIGNALLING消息,发送给Anchor MSC;Anchor MSC接收到该MAP消息后,执行释放VGCS或VBS策略。其中,AnchorMSC接收到MAP消息后,执行释放VGCS或VBS策略与实施例1或2的释放VGCS或VBS策略相同,在此不作赘述。
Anchor MSC根据所接收到的VGCS或VBS释放通知:MAP_PROCESS_GROUP CALL_SIGNALLING消息中的信元Release Cause的取值(01),可以获知该VGCS或VBS释放是,由于该主叫业务用户所在小区内的Relay BSS中的BSC控制资源(俗称处理板)缺乏,导致该BSC拒绝为该VGCS或VBS呼叫控制建立连接,而导致的该VGCS或VBS释放,该VGCS或VBS释放为非正常VGCS或VBS释放。因此,Anchor MSC可以针对该VGCS或VBS释放的原因,重新配置该主叫业无用户所在小区的网络资源。比如,可以通过Anchor MSC拆除该主叫业务用户所在小区内的部分优先级较低的VGCS或VBS,以释放该小区内的BSC的部分控制资源,还可以,在通过在该BSC上新增加控制资源(处理板)的方式扩展BSC控制功能。
对于本实施例中导致VGCS或VBS释放的情况,如果使用现有技术,AnchorMSC所接收到的VGCS或VBS释放通知:MAP_PROCESS_GROUPCALL_SIGNALLING消息,不包含Release Cause信元,Anchor MSC无从得知该VGCS或VBS释放具体是由于主叫业务所在的BSC的呼叫控制连接建立失败引起的,也就不会针对该VGCS或VBS释放原因,做出重新配置网络资源的策略,当该小区内,下次有新的VGCS或VBS发起时,仍然可能由于BSC的可用控制资源缺乏,导致VGCS或VBS建立失败,无法成功建立VGCS或VBS。
值得说明的是,本发明在Relay MSC发起VGCS或VBS释放时,在消息MAP_PROCESS_GROUP CALL_SIGNALLING消息中携带Please Cause信元,对于非释放VGCS或VBS的情况下,MAP_PROCESS_GROUP CALL_SIGNALLING消息中既可以不携带Please Cause信元,也可以携带Please Cause信元,只是对于非释放VGCS或VBS的情况下,该信元对应的值为预设的标识非释放VGCS或VBS对应的值,具体根据实际预设情况,进行设置。
另外,由于对于Relay MSC内VGCS或VBS号码分配失败、GCR查询失败导致VGCS或VBS释放的情况,Relay MSC会在发给Anchor MSC的PREPARE_GROUP_CALL_NEGATIVE_RSP消息中携带USER ERROR信元来指示原因值,因此在该种情况下,无需在MAP消息中增加携带原因值的PleaseCause信元来重复标示VGCS或VBS释放的原因。
以上对本发明所提供的一种释放集群通信业务的方法进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

Claims (8)

1、一种释放集群通信业务的方法,其中所述的集群通信业务释放在中继移动中心发起,其特征是,包括以下步骤:
A、中继移动交换中心向主控移动交换中心发送集群通信业务释放通知,并指示所述集群通信业务释放原因。
B、主控移动交换中心根据所接收的集群通信业务释放通知,释放所述的集群通信业务。
2、根据权利要求1所述的释放集群通信业务的方法,其特征是,所述步骤B后进一步包括以下步骤:
C、主控移动交换中心根据所接收的集群通信业务释放通知,获知所述的集群通信业务释放原因,根据所述的释放原因,配置网络资源。
3、根据权利要求1或2所述的释放集群通信业务的方法,其特征是,所述步骤A具体包括以下步骤:
A1、所述的中继移动交换中心接收到由主叫业务用户发送的终止集群通信业务的请求消息;
A2、所述的中继移动交换中心根据所述的请求消息,向主控移动交换中心发送集群通信业务释放通知,并在所述的释放通知中增加标识集群通信业务释放原因的信元,并标识所述的释放原因。
4、根据权利要求1或2所述的释放集群通信业务的方法,其特征是,所述步骤A具体包括以下步骤:
A3、所述的主叫业务用户在发起集群通信业务呼叫后,并且,所述的中继移动交换中心在向主叫业务用户所在小区的基站控制***请求分配集群通信业务信道后,接收到由所述基站控制***发送的主叫业务用户所在小区的集群通信业务信道分配失败的消息;
A4、所述的中继移动交换中心根据所述的集群通信业务信道分配失败的消息,向主控移动交换中心发送集群通信业务释放通知,并在所述的释放通知中增加标识集群通信业务释放原因的信元,并标识所述释放原因。
5、根据权利要求4所述的释放集群通信业务的方法,其特征是,所述步骤C具体包括以下步骤:
C1、主控移动交换中心根据所述的释放通知中标识集群通信业务释放原因的信元所标识的集群通信业务释放原因,增加主叫所在的基站控制***中的信道资源。
6、根据权利要求1或2所述的释放集群通信业务的方法,其特征是,所述步骤A具体包括以下步骤:
A5、所述的主叫业务用户在发起集群通信业务呼叫后,所述的中继移动交换中心在为所述的集群通信业务,向主叫业务用户所在的基站控制***请求建立控制连接后,接收到由所述基站控制***发送的呼叫控制连接建立失败的消息;
A6、所述的中继移动交换中心根据所述的呼叫控制连接建立失败的消息,向主控移动交换中心发送集群通信业务释放通知,并在所述的释放通知中增加标识集群通信业务释放原因的信元,并标识所述释放原因。
7、根据权利要求6所述的释放集群通信业务的方法,其特征是,所述步骤C具体包括以下步骤:
C2、主控移动交换中心根据所述的集群通信业务释放消息中标识释放原因的信元所标识的集群通信业务释放原因,增加主叫业务用户所在的基站控制***中的控制单元。
8、根据权利要求7所述的释放集群通信业务的方法,其特征是,所述的集群通信业务为:语音组呼业务、或者语音广播业务。
CN 200610090062 2006-06-22 2006-06-22 一种释放集群通信业务的方法 Pending CN101094134A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 200610090062 CN101094134A (zh) 2006-06-22 2006-06-22 一种释放集群通信业务的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 200610090062 CN101094134A (zh) 2006-06-22 2006-06-22 一种释放集群通信业务的方法

Publications (1)

Publication Number Publication Date
CN101094134A true CN101094134A (zh) 2007-12-26

Family

ID=38992179

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 200610090062 Pending CN101094134A (zh) 2006-06-22 2006-06-22 一种释放集群通信业务的方法

Country Status (1)

Country Link
CN (1) CN101094134A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101720028A (zh) * 2009-12-01 2010-06-02 北京中星微电子有限公司 一种视频监控中实现语音广播的方法和***
CN101754419B (zh) * 2008-12-04 2012-12-19 中兴通讯股份有限公司 一种业务释放的方法及***
WO2013000212A1 (zh) * 2011-06-27 2013-01-03 中兴通讯股份有限公司 实现终端接入集群业务的方法、终端和基站
WO2014166440A1 (zh) * 2013-07-09 2014-10-16 中兴通讯股份有限公司 集群中继方法、装置、***及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101754419B (zh) * 2008-12-04 2012-12-19 中兴通讯股份有限公司 一种业务释放的方法及***
CN101720028A (zh) * 2009-12-01 2010-06-02 北京中星微电子有限公司 一种视频监控中实现语音广播的方法和***
WO2013000212A1 (zh) * 2011-06-27 2013-01-03 中兴通讯股份有限公司 实现终端接入集群业务的方法、终端和基站
WO2014166440A1 (zh) * 2013-07-09 2014-10-16 中兴通讯股份有限公司 集群中继方法、装置、***及存储介质

Similar Documents

Publication Publication Date Title
CN101616364B (zh) 一种组呼业务实现方法
CN100455070C (zh) Cdma数字集群传统式组呼的呼叫建立和呼叫控制方法
CN100527655C (zh) 一种在码分多址***中实现集群业务的方法
CN103391513A (zh) 宽带数字集群业务的实现方法及集群调度管理中心
CN101287181B (zh) 一种集群通信***中主动迟后接入方法
CN109089333B (zh) 一种数字集群***组派接实现方法
CN101860421B (zh) 实现组呼信道上行链路抢占的方法及***
CN101094134A (zh) 一种释放集群通信业务的方法
CN100353784C (zh) 集群通信中组呼业务抢占的实现方法
CN100499902C (zh) 一种释放语音组呼上行的方法
CN101621779A (zh) 一种紧急呼叫方法、装置及***
CN100426894C (zh) 发起集群通信业务的方法
CN100441030C (zh) 一种私密呼叫的建立方法
CN101106743B (zh) 一种短信的发送方法
CN100417250C (zh) 一种业务用户加入组呼的方法及***
CN101313612B (zh) 识别中继移动交换中心的方法、组呼方法及设备
CN101123759B (zh) 一种在集群通信***中针对用户分配资源的接入方法
CN105163287A (zh) 一种集群通信***中群组呼叫临时加入功能的实现方法
CN100407820C (zh) 一种主叫业务用户释放组呼上行方法
CN102857995A (zh) 一种集群用户设备的接入方法、消息发送方法及用户设备
CN100361545C (zh) 一种基于gsm技术的数字集群***ptt点对点呼叫的方法
CN100441001C (zh) 一种集群来电提示的方法
CN100349483C (zh) 基于gsm的集群数字***建立私密呼叫业务的方法
CN113179493A (zh) 一种提高B-TrunC组呼业务中话权方接通效率的方法
CN101287179A (zh) 一种组呼业务的控制方法及设备

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication