CN1882178A - 一种解决无线网络中主被叫碰撞的方法 - Google Patents

Abstract

本发明公开了一种解决无线网络中主被叫碰撞的方法，该方法包括：当移动交换中心MSC接收到移动台MS的主叫请求和呼叫该MS的被叫请求，并确定该MS发生主被叫碰撞后，MSC给所述MS指配信道，并通过该信道向该MS发送主被叫碰撞信息；MS根据主被叫碰撞的提示信息向MSC返回当前优先处理呼叫的信息，MSC根据所述当前优先处理的呼叫信息处理对应的请求。根据本发明公开的方法，当发生主被叫碰撞时，MSC通知发生主被叫碰撞的用户，由用户选择主叫优先还是被叫优先，MSC根据用户返回的信息处理对应的呼叫，因此用户知道发生了主被叫碰撞，且可以根据自己的需求接通被叫或继续呼叫。

Description

一种解决无线网络中主被叫碰撞的方法

技术领域

本发明涉及无线通信技术，特别是指一种解决无线网络中主被叫碰撞的方法。

背景技术

无线通信系统，包括移动交换中心(MSC)、归属位置寄存器(HLR)、拜访位置寄存器(VLR)、基站控制器(BSC)、移动台(MS)等。MSC完成全部必须的信令功能以建立主被叫用户之间的连接。HLR存储有关开户MS的所有签约数据，并存储关于MS当前位置相关的信息；VLR是存储MS位置信息的动态数据库，当MS漫游进入某个MSC控制区域时，必须向与该MSC相关的VLR登记，以能够提供建立呼叫接续的必要条件。一般情况下VLR和MSC合设在同一个设备上，称为MSC/VLR。BSC管理各种接口，承担无线资源和无线参数的管理。

在通信过程中，可能出现主被叫碰撞的情况，如：当用户A拨打用户B的过程中，恰好用户B拨打用户C，这时，对于用户B就是主被叫碰撞。从用户B所在MSC/VLR的角度来看，MSC/VLR正在处理被叫，正准备给BSC下发寻呼消息或者已经下发寻呼消息而还没有得到MS的寻呼响应，这时，MSC/VLR收到BSC上发的业务请求。从用户B的MS的角度来看，MS正在进行接入试探，同时空中信道正在对该MS进行寻呼。

一般情况下，MSC/VLR采用“用户状态抢占”的处理机制，即在MSC/VLR中保留一个用户状态：对于同一个用户，如果被叫请求先到MSC/VLR，则被叫将用户状态置为“保护态”，此后MSC/VLR将拒绝该用户上发的主叫业务请求；如果主叫请求先到MSC/VLR，则主叫将用户状态置为“保护态”，此后MSC/VLR将拒绝呼叫该用户的被叫请求。

下面举例说明主被叫碰撞带来的影响。当A用户呼叫B用户时，又恰好B用户呼叫C用户，此时B用户发生主被叫碰撞。假设，A用户呼叫B用户的被叫请求先到B用户所在MSC/VLR，图1所示为主被叫碰撞时B用户所在网络侧的流程图，详细描述如下。其中的呼叫流程以CDMA2000的信令流程为例，包括其它流程的说明。

步骤101：MSC/VLR收到呼叫B用户的被叫请求，由于被叫请求先到MSC/VLR，因此被叫将B用户状态置为“保护态”；

步骤102：MSC/VLR向该B用户MS所在的BSC下发寻呼请求(PagingRequest)；

步骤103：BSC寻呼该B用户MS；

步骤104：当B用户MS收到步骤103所述寻呼时，B用户又恰好呼叫C用户，B用户MS向BSC发起呼叫；

步骤105：BSC根据B用户MS的主叫请求向MSC/VLR上发业务请求(Service Request)；

步骤106：MSC/VLR判断出主被叫碰撞，并根据“用户状态抢占”的处理机制，拒绝BSC上发的业务请求消息；

步骤107：由于B用户MS正处于主叫接入过程无法处理步骤103的寻呼消息，所以寻呼超时，一般情况下，MSC/VLR在寻呼超时之后会下发二次寻呼，如步骤109、110；

步骤108：由于B用户发起呼叫而长时间无法接通时，也会重新发起呼叫，如步骤111、112；

步骤109：MSC/VLR向该B用户MS所在的BSC下发寻呼请求；

步骤110：BSC寻呼该B用户MS；

步骤111：B用户重新发起呼叫，B用户MS重新向BSC发起呼叫；

步骤112：BSC根据B用户MS的主叫请求向MSC/VLR上发业务请求；

步骤113：如果步骤108所述的呼叫过程发生在步骤110之后MS还没来得及处理该寻呼时，又会发生主被叫碰撞，MSC/VLR再次判断出主被叫碰撞。

按照上述流程，如果没有处理主被叫碰撞的机制，则对于主被叫碰撞的用户来说，不仅主叫接续时间变长，而且无法成功呼叫到该用户。

现有技术中，按照优先处理主叫的方法来解决上述主被叫碰撞的问题，即：MSC/VLR判断出主被叫碰撞后，拒绝被叫请求和清除被叫的“保护态”，然后处理主叫请求，同时主叫将用户状态置为“保护态”。

按照上述方法，当主被叫碰撞时，主叫优先、拒绝被叫的处理方法存在缺点：越是业务繁忙的用户，碰撞的概率越高，按照上述主叫优先的方法，往往会漏掉一些电话，因此用户对上述现有的主叫优先的处理方法不能接受或感到不满。而且，发生主被叫碰撞的用户并不能知道发生了碰撞，觉得发起呼叫的接入时间变长，因此，会抱怨网络质量不好。

发明内容

有鉴于此，本发明的主要目的在于提供一种解决无线网络中主被叫碰撞的方法，以提供发生主被叫碰撞时的处理方法。

为达到上述目的，本发明提供一种解决无线网络中主被叫碰撞的方法，该方法包括：

a.当移动交换中心MSC接收到移动台MS的主叫请求和呼叫该MS的被叫请求，并确定该MS发生主被叫碰撞后，MSC向该MS发送主被叫碰撞信息；

b.MS根据主被叫碰撞信息向MSC返回当前优先处理呼叫的信息，MSC根据所述当前优先处理的呼叫信息处理对应的请求。

其中，步骤a所述主被叫碰撞信息是MSC通过闪动请求Flash Request消息携带；或，步骤a中所述主被叫碰撞信息是MSC通过指配信道请求消息携带。

其中，所述主被叫碰撞信息包括：碰撞产生时呼叫该MS的对方用户终端的号码、选择主叫优先还是被叫优先的选择项、文字、图片、声音中的一种或任意组合。

其中，步骤b所述当前优先处理呼叫的信息为MS向MSC返回挂机操作或不挂机操作信息，如果返回挂机操作信息，MSC处理被叫请求；如果返回不挂机操作信息，MSC处理主叫请求。

其中，步骤b所述当前优先处理的呼叫信息为主叫请求信息，则MSC拒绝被叫请求，然后处理该MS的主叫请求。

其中，步骤b所述当前优先处理的呼叫信息为主叫请求信息，如果MSC确定被叫请求已被清除，则处理该MS的主叫请求。

其中，步骤b所述当前优先处理的呼叫信息为被叫请求信息，则MSC处理被叫请求。

其中，所述步骤a之前进一步包括：在归属位置寄存器HLR中保存该MS签约主被叫碰撞通知业务的信息；

步骤a所述MSC确定该MS主被叫碰撞后进一步包括：MSC从HLR中获取该MS的签约数据，如果确定该MS签约主被叫碰撞通知业务，则向MS发送主被叫碰撞信息；如果确定该MS没有签约该业务，则处理主叫请求，结束本流程。

其中，所述在HLR中保存该MS签约主被叫碰撞通知业务的信息步骤包括：MS向MSC发送签约主被叫碰撞通知业务的请求，MSC根据该MS的请求，在HLR记录该MS签约主被叫碰撞通知业务的信息；

或，所述该MS签约主被叫碰撞通知业务的信息是预先保存在HLR中。

其中，步骤b所述MS根据主被叫碰撞信息向MSC返回当前优先处理呼叫的信息的步骤包括：MS中配置主被叫碰撞信息所对应的内部操作，根据用户选择结果，向MSC返回相应的操作信息。

根据本发明提供的解决主被叫碰撞的方法，当发生主被叫碰撞时，MSC通知发生主被叫碰撞的用户，由用户选择主叫优先还是被叫优先，MSC根据用户返回的信息处理对应的呼叫，因此用户知道发生了主被叫碰撞，且可以根据自己的需求接通被叫或继续呼叫，提高用户的满意程度。

附图说明

图1所示为背景技术中主被叫碰撞流程图；

图2所示为HLR中用户签约数据更改之后，主动发出请求更新MSC/VLR中用户数据的流程图；

图3所示为本发明中用户通过远程操作办理或更改业务签约数据的流程图；

图4所示为MSC/VLR获取HLR中用户签约数据的流程图；

图5所示为本发明中主被叫碰撞的用户选择主叫优先时的处理流程图；

图6所示为本发明中主被叫碰撞的用户选择被叫优先时的处理流程图；

图7所示为本发明中当被叫请求主动被结束时，主被叫碰撞的用户选择被叫优先时的处理流程图；

图8所示为本发明中通过指配信道请求消息携带主被叫碰撞信息的处理流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面举具体实施例，对本发明作进一步详细的说明。

本发明的核心思想是：当MSC/VLR判断出主被叫碰撞时，首先按照主叫优先处理，接受主叫的业务请求并发起指配信道的操作，指配成功后，向用户发送发生主被叫碰撞的信息，由用户选择接通被叫还是继续发起主叫，然后根据用户的选择，继续处理主叫或被叫即可。其中，主被叫碰撞信息中可以携带以下内容，例如，对方用户的电话号码、选择主叫优先还是被叫优先的选择项、其他文字、图片、声音等。

在HLR中设置用户申请主被叫碰撞通知业务的签约数据，并且可以通过两种方式实现。

一种是：预先直接将用户申请主被叫碰撞通知业务的签约数据保存在HLR中，HLR中签约数据变更之后，主动向MSC/VLR发出更改用户数据的请求，如图2所示，HLR向MSC/VLR发出更改用户签约数据的请求，MSC/VLR根据该请求，更新用户签约数据之后向HLR返回响应。

另一种是：用户终端通过远程操作实现在HLR中设置“主被叫碰撞通知”业务的用户签约信息。用户终端可以通过拨打签约主被叫碰撞通知业务的特定号码办理该业务，如图3所示，按照该方法，用户还可以远程更改业务签约数据，详细介绍如下所述：

步骤301：用户终端向BSC发送被叫为特定号码的呼叫请求，BSC收到该呼叫请求后，根据该特定号码向MSC/VLR发起呼叫；

步骤302：MSC/VLR确定所呼叫的号码为签约“主被叫碰撞通知”业务签约数据的特定号码，向HLR发送更改HLR中签约数据的请求；

步骤303：HLR收到上述请求之后，向MSC/VLR发送更改VLR中签约数据的请求；

步骤304：MSC/VLR根据步骤303中请求，先更改MSC/VLR中签约数据之后，向HLR返回更改签约数据的响应；

步骤305：HLR收到步骤302中的请求和步骤304中MSC/VLR返回的响应之后，更改HLR中签约数据，然后向MSC/VLR返回更改签约数据的响应；

步骤306：MSC/VLR向BSC发送用户更改签约数据的结果，然后由BSC通知用户该结果。

当MS漫游到新的MSC/VLR或MSC/VLR数据丢失等情况下，按照如图4所示，MSC/VLR向HLR发送能够获取用户签约数据的请求，例如位置登记、资格请求或者资格指示等；HLR收到上述请求之后，向MSC/VLR返回用户签约数据的响应，MSC/VLR获取用户的签约数据。

综上所述，HLR中签约数据被更改或MS漫游到新的MSC/VLR等情况下，MSC/VLR都能及时获取HLR中用户签约数据，因此MSC/VLR在收到主叫请求或被叫请求之后，如果发生主被叫碰撞，则MSC从VLR可以获取用户签约数据，确定该用户是否是申请主被叫碰撞通知的用户，如果是，通知用户发生主被叫碰撞，进而户解决主被叫碰撞的问题。

在本发明中，需要设置选择当前优先处理的呼叫对应的操作或信息。例如：对于用户挂机操作，表明选择被叫优先；不挂机操作，即无任何操作，表明选择主叫优先。根据该项业务的设置，用户收到主被叫碰撞信息之后，如果要选择主叫优先，则不挂机；如果要选择被叫优先，则挂机。为了用户使用该项业务更方便，MS中可以配置与主被叫碰撞信息对应的内部操作，或者返回对应的信息给MSC。例如，对主被叫碰撞信息中选择主叫优先还是被叫优先的选择项配置对应的内部操作，用户选择被叫优先时，MS内部处理挂机操作。

用户发起呼叫或被叫，MSC/VLR获取该用户签约数据，当MSC/VLR判断出该用户发生主被叫碰撞时，根据所获取的签约数据判断出该用户是“主被叫碰撞通知”业务的签约用户，则暂时优先处理主叫，即指配信道，然后向用户发出主被叫碰撞的信息，由用户选择主叫优先还是被叫优先。如果MSC/VLR在延时一段时间后仍没有检测到挂机操作或对应的信息，则认为用户选择了主叫优先，然后清除被叫请求，接续主叫；如果MSC/VLR检测到挂机操作或对应的信息，则认为用户选择了被叫优先，然后执行寻呼，接续被叫。下面结合具体实施例，详细介绍发生主被叫碰撞时解决主被叫碰撞的方法。当A用户呼叫B用户时，又恰好B用户呼叫C用户，此时B用户发生主被叫碰撞。假设，A用户呼叫B用户的被叫请求先到B用户所在MSC/VLR，下面几个实施例中均给出主被叫碰撞时B用户所在网络侧的流程图。

图5所示为，B用户发生主被叫碰撞，且该用户选择主叫优先时的处理流程图，其中下面所述MS是属于B用户。

步骤501：MSC/VLR收到呼叫MS的被叫请求；

步骤502：MSC/VLR向该MS所在的BSC下发寻呼请求(PagingRequest)；

步骤503：BSC寻呼该MS；

步骤504：MS收到步骤503所述寻呼时，该MS的用户恰好发起呼叫，MS向BSC发起呼叫；

步骤505：BSC根据MS的呼叫请求向MSC/VLR上发业务请求(ServiceRequest)；

步骤506：MSC/VLR判断出主被叫碰撞，暂时优先处理主叫，如步骤507～510；

步骤507：MSC/VLR向BSC发送指配请求(Assignment Request)；

步骤508：BSC给MS指配信道；

步骤509：MS向BSC发送指配信道成功响应(Assignment Complete)；

步骤510：BSC向MSC/VLR返回指配成功的响应；

步骤511：MSC/VLR向BSC发送闪动请求(Flash Request)消息，其中携带主被叫碰撞的信息，例如，对方用户A的电话号码、选择主叫优先还是被叫优先的选择项、其他文字、图片、声音等；

步骤512：BSC给MS发送上述主被叫碰撞的信息；

步骤513：B用户获取上述主被叫碰撞信息之后，没有执行挂机操作，即B用户选择了主叫优先；

步骤514：MSC/VLR在步骤511之后延时一段时间后，没有检测到发生主被叫碰撞MS的挂机操作，因此判断出B用户选择了主叫优先；

步骤515：MSC/VLR清除被叫请求，继续接续主叫。

之后，B用户作为主叫呼叫C用户成功，两者之间建立通信话路。

图6所示为，B用户发生主被叫碰撞时，该用户选择被叫优先时的处理流程图。

步骤601～步骤612：同步骤501～步骤512；

步骤613：B用户获取主被叫碰撞的信息之后，执行挂机操作，即B用户选择了被叫优先；

步骤614：MS向BSC发送挂机信息；

步骤615：BSC向MSC/VLR发送清除请求(Clear Request)；

步骤616：MSC/VLR向BSC发送清除命令(Clear Command)；

步骤617：BSC清除业务信道之后，向MSC/VLR发送清除完成(ClearComplete)；

步骤618：MSC/VLR检测到清除完成之后，判断出B用户在主被叫碰撞时优先选择被叫；

步骤619：MSC/VLR向BSC发送寻呼请求(Paging Request)；

步骤620：BSC寻呼MS；

步骤621：MS向BSC返回寻呼响应；

步骤622：BSC向MSC/VLR返回寻呼响应(Paging Response)。

之后，B用户作为被叫，被A用户呼叫成功，两者之间建立了通信话路。

在上述实施例中，如果A用户拨号后长时间没接通，则有可能会主动挂机，这时，处理流程图如图7所示。

步骤701～步骤705：同步骤601～步骤605；

步骤706：MSC/VLR判断出发生了主被叫碰撞，暂时优先处理主叫；

步骤707：A用户主动结束本次呼叫，MSC/VLR侧的被叫请求被拆除；

步骤708～步骤713：同步骤607～步骤612；

步骤714：B用户获取主被叫碰撞信息之后，如果没有执行挂机操作，即B用户选择主叫优先时，MSC/VLR接续主叫；如果执行挂机操作，即B用户选择被叫优先时，MSC/VLR执行步骤715～724；

步骤715～步骤718：同步骤614～步骤617；

步骤719：B用户等待A用户再次发起呼叫；

步骤720：A用户再次发起呼叫，MSC/VLR再次收到被叫请求；

步骤721～步骤724：同步骤619～步骤622；

在图7所述的流程中，如果步骤714中，B用户选择被叫优先时，可以根据步骤713中的主被叫碰撞信息中的A用户的号码回拨该A用户即可。

上述几个实施例中，通过Flash Request携带主被叫碰撞信息，通知发生碰撞的用户，除此之外，还可以通过指配请求携带主被叫碰撞信息，通知发生碰撞的用户，如图8所示。

步骤801～步骤806：同步骤501～步骤506；

步骤807：MSC/VLR向BSC发送指配请求，其中携带主被叫碰撞信息；

步骤808：BSC给MS指配信道，并携带上述主被叫碰撞信息；

步骤809～步骤810：同步骤509～步骤510；

步骤811：B用户获取上述主被叫碰撞信息之后，可以根据自己的需求选择主叫优先或被叫优先。

B用户选择主叫优先后的处理过程如同图5所示的流程，被叫优先后的处理过程如同图6所示的流程，不再详细介绍。

如果B用户作为主叫呼叫C用户的主叫业务请求先到MSC/VLR，然后MSC/VLR收到A用户呼叫B用户的被叫请求，且对于用户B恰好发生主被叫碰撞时，则MSC/VLR在主被叫碰撞后的处理流程如同上述的实施例，首先暂时按照主叫优先建立信道之后，并通知B用户，然后根据用户的选择结果处理主叫或被叫请求。

上述解决主被叫碰撞的方法虽然使用CDMA2000的信令方式描述，但其方法适用于所有无线通信网络，例如GSM、宽带码分多址(WCDMA)、CDMA2000、时分同步码分多址(TD-SCDMA)等，其中具体呼叫流程中的信令有可能不一样，但是，处理主被叫碰撞的主要思想都一样，即：当确定发生主被叫碰撞之后，首先按照主叫优先指配信道，并向用户发送发生主被叫碰撞的信息，然后根据用户的选择，继续处理主叫请求或被叫请求。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1、一种解决无线网络中主被叫碰撞的方法，其特征在于，该方法包括：

a.当移动交换中心MSC接收到移动台MS的主叫请求和呼叫该MS的被叫请求，并确定该MS发生主被叫碰撞后，MSC向该MS发送主被叫碰撞信息；

b.MS根据主被叫碰撞信息向MSC返回当前优先处理呼叫的信息，MSC根据所述当前优先处理的呼叫信息处理对应的请求。

2、根据权利要求1所述的方法，其特征在于，

步骤a所述主被叫碰撞信息是MSC通过闪动请求Flash Request消息携带；或，步骤a中所述主被叫碰撞信息是MSC通过指配信道请求消息携带。

3、根据权利要求1或2所述的方法，其特征在于，所述主被叫碰撞信息包括：碰撞产生时呼叫该MS的对方用户终端的号码、选择主叫优先还是被叫优先的选择项、文字、图片、声音中的一种或任意组合。

4、根据权利要求1所述的方法，其特征在于，步骤b所述当前优先处理呼叫的信息为MS向MSC返回挂机操作或不挂机操作信息，如果返回挂机操作信息，MSC处理被叫请求；如果返回不挂机操作信息，MSC处理主叫请求。

5、根据权利要求1所述的方法，其特征在于，步骤b所述当前优先处理的呼叫信息为主叫请求信息，则MSC拒绝被叫请求，然后处理该MS的主叫请求。

6、根据权利要求1所述的方法，其特征在于，步骤b所述当前优先处理的呼叫信息为主叫请求信息，如果MSC确定被叫请求已被清除，则处理该MS的主叫请求。

7、根据权利要求1所述的方法，其特征在于，步骤b所述当前优先处理的呼叫信息为被叫请求信息，则MSC处理被叫请求。

8、根据权利要求1所述的方法，其特征在于，所述步骤a之前进一步包括：在归属位置寄存器HLR中保存该MS签约主被叫碰撞通知业务的信息；

步骤a所述MSC确定该MS主被叫碰撞后进一步包括：MSC从HLR中获取该MS的签约数据，如果确定该MS签约主被叫碰撞通知业务，则向MS发送主被叫碰撞信息；如果确定该MS没有签约该业务，则处理主叫请求，结束本流程。

9、根据权利要求8所述的方法，其特征在于，所述在HLR中保存该MS签约主被叫碰撞通知业务的信息步骤包括：MS向MSC发送签约主被叫碰撞通知业务的请求，MSC根据该MS的请求，在HLR记录该MS签约主被叫碰撞通知业务的信息；

或，所述该MS签约主被叫碰撞通知业务的信息是预先保存在HLR中。

10、根据权利要求3所述的方法，其特征在于，步骤b所述MS根据主被叫碰撞信息向MSC返回当前优先处理呼叫的信息的步骤包括：MS中配置主被叫碰撞信息所对应的内部操作，根据用户选择结果，向MSC返回相应的操作信息。

Images