处理紧急呼叫、紧急呼叫回叫中被叫用户的方法及其应用

摘要

本发明公开了一种处理紧急呼叫中被叫用户的方法，接入控制节点接收来自核心网CN的寻呼消息，所述寻呼消息指示本次寻呼为紧急呼叫；接入控制节点向所述紧急呼叫中的被叫用户进行寻呼，并指示本次寻呼为紧急呼叫；所述紧急呼叫中的被叫用户忽略SSACB，直接向接入控制节点进行接入。本发明还公开了一种处理紧急呼叫回叫中被叫用户的方法，一种被叫用户处理紧急呼叫的方法，以及一种处理紧急呼叫的用户侧装置。通过本发明提过的技术方案，提高了涉及紧急呼叫的呼通率。

说明书

技术领域

本发明涉及紧急呼叫的处理方法，尤其涉及一种处理紧急呼叫中被叫用户的方法和处理紧急呼叫回叫中被叫用户的方法以及被叫用户处理紧急呼叫的方法。

背景技术

在现有通信系统中，允许在某些业务或地点受限的情况下，主叫用户也可以拨打110，119等紧急号码，从而保证用户能够在第一时间向外界发出紧急求救信息。

下面以UE(User Equipment，用户设备)A拨打110警察局电话为例介绍现有紧急呼叫的处理过程。

(1)UE A拨打110；

(2)CN(Core Network，核心网)中的警察局控制中心接收到这个紧急电话后，根据预定算法找到其下属的一个具体用户设备UE B(如警局内部一个办公室的固定电话或某个警员的手机)，将该紧急呼叫映射到UE B。此后，CN向LTE中的ENODEB(增强型节点B)下发寻呼(paging)消息，所述寻呼消息用以指示ENODE B向UE B进行寻呼。

(3)ENODE B进而再向UE B下发寻呼(paging)消息；

(4)UE B接收到这个寻呼后，根据当前自己的情况决定是拒绝还是允许此次寻呼。

UE B拒绝寻呼的原因有多种，例如，当系统超负荷时，为了限制寻呼应答，UE在MM(Mobility Management，移动性管理)层对变量″Paging Responseto CS Services Restriction″设置为受限，进而，UE B就会拒绝此后收到的寻呼。又例如，系统如果要对某种业务或某些小区禁止的时候，会在系统广播消息中下发被禁止项目，然后UE便存储起来，通过“接入级别禁止列表Access ClassBarred list”方式将被禁项目予以存储。进而，拒绝其接收到的涉及所述被禁项目的所有寻呼。通常而言，将包括但不限于上述禁止项目的所有内容统筹为“特殊服务接入级别禁止(SSACB，Service Specific Access Class Barring)。总而言之，UE自ENODE B接收到寻呼消息后，会根据SSACB内容决定是否拒绝此次寻呼。如果该寻呼涉及SSACB中的禁止项目，则拒绝此次寻呼，不再进行后续的接入处理；如果该寻呼不涉及SSACB中的禁止情况，则允许此次寻呼，继续与ENODE B进行后续的接入处理，以便和主叫UE A通话。

(5)如果UE B允许此次寻呼，则向ENODE B发起连接请求，进而ENODEB根据当前的系统资源情况决定是否允许此次接入。

UE B既可以是一个紧急呼叫的被叫用户，也同样可以是一个普通呼叫的被叫用户，当其作为一个普通用户UE C(如UE B的亲属)呼叫UE B时的被叫情况下，处理流程如下：

(1)UE C拨打UE B的号码

(2)核心网CN向ENODE B下发寻呼(paging)消息，所述寻呼消息用以指示ENODE B向UE B进行寻呼。

此后的处理流程和紧急呼叫中的步骤(3)至(5)完全相同，不再赘述。

对比上述UE B同样作为被叫的紧急呼叫和普通呼叫的处理流程可知，CN向ENODE B发送的寻呼UE B的寻呼消息，以及后续ENODE B和UE B之间的接入连接等过程，就两者而言是完全相同的。换而言之，接入侧ENODE B对作为紧急呼叫的被叫和普通呼叫的被叫同样对待，由于接入过程中存在多种导致紧急呼叫无法呼通的可能情况，例如系统超负荷等涉及SSACB中的禁止项目，因此，无法保证紧急呼叫中的被叫具有较高的呼通率，进而使得紧急呼叫中的主叫无法及时获得被叫的救助。

另外，有时候用户拨打了紧急呼叫后，对方(比如警察)可能正在忙，于是会过一会儿再联系。此后，当对方(警察)再打过来时，此前的紧急呼叫主叫就变成了被叫，即紧急呼叫回叫中的被叫，基于与前述同样的理由，仍然无法保证紧急呼叫回叫中的被叫具有较高的呼通率。

发明内容

本发明实施例要解决的问题是提供一种处理紧急呼叫中被叫用户的方法，以使紧急呼叫中的被叫能够保持较高的呼通率。本发明的目的还在于提供一种紧急呼叫回叫中被叫的处理方法，使得紧急呼叫回叫中的被叫能够保持较高的呼通率。

为解决上述技术问题，本发明实施例的目的是通过以下技术方案实现的：

一种处理紧急呼叫中被叫用户的方法，所述方法包括：接入控制节点接收来自核心网CN的寻呼消息，所述寻呼消息指示本次寻呼为紧急呼叫；接入控制节点向所述紧急呼叫中的被叫用户进行寻呼，并指示本次寻呼为紧急呼叫；所述紧急呼叫中的被叫用户忽略特殊业务接入级别禁止SSACB，直接向接入控制节点进行接入。

一种处理紧急呼叫回叫中被叫用户的方法，所述方法包括：CN记录此次紧急呼叫的主、被叫对应关系；CN根据上述记录的紧急呼叫的主、被叫对应关系，识别出所述紧急呼叫的回叫；在识别出所述紧急呼叫的回叫情况下，通过接入控制节点向所述紧急呼叫回叫的被叫用户下发寻呼消息，并指示本次寻呼为紧急呼叫；所述紧急呼叫回叫中的被叫用户忽略SSACB，直接向接入控制节点进行接入。

一种被叫用户处理紧急呼叫的方法，所述方法包括：被叫用户自接入控制节点接收指示为紧急呼叫的寻呼消息；所述被叫用户忽略SSACB，直接向接入控制节点进行接入。

一种处理紧急呼叫的用户侧装置，所述装置包括：接收单元，用以接收来自接入控制节点的寻呼消息；消息解析单元，用以解析所述寻呼消息的内容；接入处理单元，用以在消息解析单元解析出所述寻呼为紧急呼叫的情况下，忽略SSACB直接向接入控制节点进行接入。

通过以上技术方案可以看出，在本发明中，当涉及紧急呼叫或紧急呼叫回叫的寻呼时，通过向被叫用户指示本次呼叫为紧急呼叫，使得被叫用户可以忽略SSACB直接进行接入，从而提高了紧急呼叫或紧急回叫的呼通率。

附图说明

图1为本发明处理紧急呼叫中被叫用户的方法第一实施例流程图；

图2为图1所示步骤140的具体子流程A；

图3为本发明处理紧急呼叫回叫中被叫用户的方法第一实施例流程图；

图4为图3所示步骤330的具体子流程C；

图5为本发明处理紧急呼叫中被叫用户的方法第二实施例流程图；

图6为本发明处理紧急呼叫回叫中被叫用户的方法第二实施例流程图；

图7为本发明处理紧急呼叫中被叫用户的方法第三实施例流程图；

图8为本发明处理紧急呼叫的用户侧装置结构示意图。

具体实施方式

下面结合附图，对本发明各实施例做更详细的介绍。

请参阅图1，其为本发明处理紧急呼叫中被叫用户的方法第一实施例流程图。

本实施例的主要思想是为寻呼(paging)消息中的paging cause增加一个值emergency；在广播消息中增加一个indication指示，用以指明系统是否允许MT EC忽略SSACB(Service Specific Access Class Barring，特殊业务接入级别禁止)，为下面叙述方便，将该指示称为紧急允许指示；在UE(用户设备)侧的CM(Connection Management，连接管理)层增加一个变量″ignoreSSACB(忽略SSACB)″，根据前述广播消息中的紧急允许指示设置该变量，进而指示MT EC(Mobile Terminating Emergency Call，紧急呼叫中的被叫用户)是否可以忽略SSACB。

步骤110：LTE系统中的ENODEB(增强型节点B)向UE发送系统广播消息，所述系统广播消息中增加一个指示即前述的紧急允许指示。需要说明，本发明各实施例中所述的ENODEB还可以RNC是(无线网络控制)等其他接入控制节点，换而言之，本发明技术方案中所述的接入控制节点包括但不限于LTE系统中的ENODEB和UMTS系统中的RNC，例如还可以是GSM系统中的BSC。

步骤120：系统中的UE1接收到上述系统广播消息，根据系统广播消息中的紧急允许指示设置变量“ignore(忽略)SSACB”。

如果所述紧急允许指示指明系统允许MT EC忽略SSACB，那么UE就把CM层的变量“ignore SSACB”置位为“MT EC忽略SSACB”，否则把该变量置位为“MT EC正常进行SSACB”。

步骤130：Cn(Core Network，核心网)收到一个来自UE 2的紧急呼叫，其根据某些算法找到一个空闲的电话，映射到该电话，即MT EC UE 1上，进而，此次紧急呼叫的主叫用户是UE 2，被叫用户是UE 1。然后，通过ENODEB向UE1下发paging消息。所述paging消息中的paging cause值是“emergency(紧急)”。

步骤140：UE1收到paging消息后，根据变量“ignore SSACB”以及pagingcause值进行后续处理。本步骤的具体过程请参看图2所示的子流程A。

子步骤S141：CM层检查变量“ignore SSACB”是否等于“MT EC忽略SSACB”。如果是，则执行步骤S142；如果否，则执行子步骤S144。

子步骤S142：检查paging cause值是否等于“emergency”。如果是，则执行步骤S143；如果否，则执行步骤S144。

子步骤S143：MT EC忽略SSACB，直接进行接入。具体而言，MT EC把pagingcause(emergency)拷贝到接入原因中，并向ENODE B发送包含接入原因的接入请求消息。此后，执行子步骤S145。需要说明，也可以不在接入请求时发送接入原因，可以在ENODEB允许MT EC接入后再通知ENODEB本次接入原因为紧急呼叫，进而ENODEB会在分配资源等方面给与此次接入较高的优先权。

子步骤S144：MT EC照常执行SSACB，进行和现有被叫用户接入相同的处理，不再赘述。此后，执行子步骤S145。

子步骤S145：ENODE B判断系统是否允许接入。本步骤只在某些特殊情况下存在，例如，无论接入原因是什么，ENODE B都不允许接入。如果系统允许接入，则执行子步骤146；如果不允许接入，则结束接入过程。

子步骤S146：ENODE B判断接入原因是否为“emergency”。如果是，则执行子步骤S147；如果否，则执行子步骤S148。

子步骤S147：ENODE B给与该接入请求最高的接入服务级别ASC(Accessservice classes)(如ASC0)，即让其具有较高优先权，直接接入。如果在紧急呼叫过程中发生小区重选，所有该PLMN(公用陆地移动网络)内的小区都认为是“正常”的，可以重选。如果出现当前PLMN超出覆盖区的情况，UE1可以进行PLMN重选，以选择另外的PLMN。对于EC，网络侧认为所有的PLMN都是“正常”的，不受限。

子步骤S148：ENODEB按照现有的常规接入流程进行处理，不再赘述。

请参阅图3，其为本发明处理紧急呼叫回叫中被叫用户的方法第一实施例流程图，本实施例与前述处理紧急呼叫中被叫用户的方法第一实施例，在寻呼涉及紧急呼叫(紧急呼叫或其回叫)的被叫用户过程上具有类似的技术方案。

步骤310：LTE系统中的ENODEB向UE发送系统广播消息，所述系统广播消息包括前述的紧急允许指示，所述紧急允许指示用以指明系统是否允许MTEC忽略SSACB。

步骤320：系统中的UE 2接收到上述系统广播消息，根据系统广播消息中的紧急允许指示设置变量“ignore SSACB”。

如果所述紧急允许指示指明系统允许MT EC忽略SSACB，那么UE2就把CM层的变量“ignore SSACB”置位为“MT EC忽略SSACB”，否则把该变量置位为“MT EC不忽略SSACB”。

步骤330：Cn处理来自UE2的紧急呼叫，以及紧急呼叫的回叫。具体过程详见图4所示的子流程C。

子步骤S331：Cn收到来自UE2的紧急呼叫后，根据某些算法进行电话映射。

具体而言，如果找到一个空闲的电话MT EC UE 1，则直接向其进行寻呼。如果找到的MT EC此时不空闲，则CN给被叫电话UE 1特殊的提示音或短消息，由被叫自己决定是否切断目前的通话转而接通紧急呼叫。如果被叫决定切断目前通话，直接切到紧急呼叫上来；如果被叫决定不切断目前通话，则由被叫自己决定是否过一会儿callback(回叫)。此后执行子步骤S332。

子步骤S332：CN记录此次紧急呼叫的主叫和被叫的对应关系(如信息表的形式)。例如，记录此次紧急呼叫的主叫用户是UE2，被叫用户是UE1。具体对应关系的实现方式有多种，例如采用IMSI或EMSI的对应方式等等。如果有SIM(Subscriber Identity Module，用户识别)卡，就可以通过IMSI(用户标识)来进行主被叫的对应关系，如果没有SIM卡，可以用EMSI(设备标识)或其他设备识别号对应。另外，可以为该对应关系做一个标记，如“emergencySSACB”，以表明所述对应关系属于紧急呼叫的主、被叫对应关系。同时，为所述紧急呼叫的主、被叫对应关系记录设置一个定时器并启动该定时器，为与系统中的其他定时器相区别，将其称为“紧急呼叫回叫定时器1”，可以根据需要设置所述定时器1的有效时间，比如30分钟。如果所述“紧急呼叫回叫定时器1”超过预置的有效时间，那么CN就删除所述对应关系记录。此外，CN还可以通过ENODEB给原紧急呼叫的主叫UE2下发一个消息，通知UE2也启动一个定时器，为叙述一致，可将其称为“紧急呼叫回叫定时器2”，所述UE2侧的“紧急呼叫回叫定时器2”与“紧急呼叫回叫定时器1”保持同步，两者设置的值相同。当然，还可以事先由用户侧和CN侧约定好上述两个定时器的值，当UE2发起紧急呼叫的时候就启动所述“紧急呼叫回叫定时器2”，或者通过别的特定消息触发启动。

子步骤S333：在所述“紧急呼叫回叫定时器1”未超时时，CN发现一个特殊号码(比如警察局)发起了呼叫，于是CN就去查找子步骤S332记录的标记有“emergency SSACB”的主、被叫对应关系。

子步骤S334：CN根据记录的紧急呼叫的主、被叫对应关系，判断本次呼叫是否为此前紧急呼叫的回叫。如果是，则执行子步骤S335；如果否，则执行子步骤S336。例如，假设所述特殊号码的呼叫是来自UE1呼叫，其呼叫的对象是UE2，那么根据子步骤S336中关于紧急呼叫的记录：紧急呼叫的主叫用户是UE2，被叫用户是UE1，即可判断出该呼叫为此前UE2发起的紧急呼叫的回叫，即前述记录的紧急呼叫的回叫中的主叫用户是UE1，被叫用户是UE2。

子步骤S335：CN下发寻呼消息，所述寻呼消息中指示本次呼叫为紧急呼叫，具体而言，paging消息中的paging cause值是“emergency”。

子步骤S336：CN通过ENODEB向UE下发paging消息，所述paging消息中的paging cause值是“unknown(未知)”或“Terminating call”或“其他非emergency”。换而言之，对非紧急呼叫的回叫，按照现有正常呼叫处理，具体过程不再赘述。

步骤340：UE2收到paging消息后，根据变量“ignore SSACB”以及pagingcause值进行后续处理。本步骤的具体过程同前述实施例中的步骤130和140，即UE2可以忽略SSACB，直接进行接入，接入侧的ENODEB给予其最高接入服务级别。从而，保证紧急呼叫回叫中的被叫用户能够保持较高的呼通率。另外，为了能够成功完成紧急呼叫的CALLBACK，在“紧急呼叫回叫定时器2”时间范围内，该UE能选择任何PLMN，驻留任何小区。如果在UE2的PLMN列表中该PLMN是受限的，或者在CELL列表中该小区是受限的，接收寻呼的时候检测paging cause，只要该值是“emgergency”，就接受此次寻呼；否则拒绝此次寻呼。如果定时器超时，PLMN和CELL的选择、驻留都是按正常流程进行。

请参阅图5，其为本发明处理紧急呼叫中被叫用户的方法第二实施例流程图。本实施例采用了与前述处理紧急呼叫中被叫用户的方法第二实施例类似的技术方案。

步骤500：ENODEB/RNC是否允许紧急呼叫的被叫(MT EC)忽略SSACB，可以通过O&M或全局变量等进行设置。然后LTE的ENODEB(UMTS系统的RNC)设置这个变量“emergency SSACB”。如果是要求MT EC忽略SSACB的，就设置该变量为“MT EC忽略SSACB”，否则设置为“正常处理SSACB”

步骤510：CN收到一个紧急呼叫(该紧急呼叫的被叫用户是警察局的UE1)后，向LTE的ENODEB(UMTS系统的RNC)下发paging消息，其中paging cause值是“emergency”。

步骤520：Enodeb收到paging消息，检查变量“emergency SSACB”，如果变量值为“MT EC忽略SSACB”，则下发给UE1的paging就带有paging cause值是“emergency”。否则，paging cause中值设为“unknown”或“其他非emergency”。

步骤530：UE1收到这个寻呼消息后，检查paging cause，如果是“emergency”，则忽略SSACB，直接进行接入。否则，进行正常接入过程。本步骤的具体流程，与前述处理紧急呼叫中被叫用户的方法第一实施例中的子步骤S142至S148雷同，故不再赘述。

请参阅图6，其为本发明处理紧急呼叫回叫中被叫用户的方法第二实施例流程图。

步骤600：ENODEB/RNC是否允许紧急呼叫的被叫(MT EC)忽略SSACB，可以通过O&M或全局变量等进行设置。然后LTE的ENODEB(UMTS系统的RNC)设置这个变量“emergency SSACB”。如果是要求MT EC忽略SSACB的，就设置该变量为“MT EC忽略SSACB”，否则设置为“正常处理SSACB”。

步骤610：CN处理来自UE2的紧急呼叫，以及来自UE1的紧急呼叫回叫。如果是紧急呼叫的回叫，则向ENODE下发的寻呼消息中paging cause值是“emergency”，否则paging cause值是“unknown”或“Terminating call”或“其他非emergency”等。本步骤的具体过程与前述步骤330的具体过程相同，详见图4所示的子流程C，此处不再赘述。

步骤620：Enodeb收到paging消息，检查变量“emergency SSACB”，如果变量值为“MT EC忽略SSACB”，则下发给UE2的paging就带有paging cause值是“emergency”。否则，paging cause中值设为“unknown“或“Terminating call”或“其他非emergency”。

步骤630：UE2根据收到的寻呼消息是否指示为紧急呼叫进行后续处理。本步骤的处理过程与前述实施例中的步骤530雷同，即收到寻呼消息后，检查paging cause，如果是“emergency”，则忽略SSACB，直接进行接入。否则，进行正常接入过程。另外，为了能够成功完成紧急呼叫的回叫(CALLBACK)，UE2在根据CN侧指示下启动的“紧急呼叫回叫定时器2”(子步骤S332中还提供了定时器2启动的其他情况，此处不再赘述)的时间范围内，UE2能选择任何PLMN，驻留任何小区。如果在UE 2的PLMN列表中该PLMN是受限的，或者在CELL列表中该小区是受限的，接收寻呼的时候检测paging cause，只要该值是“emgergency”，就接受此次寻呼；否则拒绝此次寻呼。如果定时器超时，PLMN和CELL的选择、驻留都是按正常流程进行。

通过前述公开的本发明处理紧急呼叫中被叫用户的方法两个实施例，以及处理紧急呼叫回叫中被叫用户的方法两个实施例可以总结得到，ENODEB可以通过广播消息通知用户在其作为紧急呼叫被叫时是否执行忽略SSACB操作，或者ENODEB通过全局变量自行控制，是否向所述紧急呼叫中的被叫用户指示本次寻呼为紧急呼叫，这样操作的目的在于，系统可以控制紧急呼叫中的被叫或紧急呼叫回叫中的被叫是否允许忽略SSACB，当系统不允许涉及紧急呼叫的被叫忽略SSACB情况下，就与现有正常呼叫的处理流程完全相同。本领域技术人员应该意识到，系统也可以默认紧急呼叫中的被叫或紧急呼叫回叫中的被叫必须执行忽略SSACB操作，这种情况下，ENODEB无需通过广播消息通知用户在其作为紧急呼叫被叫时是否执行忽略SSACB操作，也无需ENODEB自行决定是否向所述紧急呼叫(或回叫)中的被叫用户指示本次寻呼为紧急呼叫。具体而言，在UE中无需设置“ignore SSACB”变量，只要ENODEB下发的寻呼消息中指示本次呼叫为紧急呼叫，那么UE就执行忽略SSACB操作，反之正常处理SSACB；同理，也无需在ENODEB中设置“emergency SSACB”变量，只要CN发给ENODEB的寻呼消息中指示本次呼叫为紧急呼叫，那么，ENODEB在向UE寻呼时也同样指示本次呼叫为紧急呼叫。这种处理情况较前述各实施例更为简单，请参看图7，其为本发明处理紧急呼叫中被叫用户的方法第三实施例流程图。

步骤700：如果CN收到一个紧急呼叫，则向LTE的ENODEB(UMTS系统的RNC)下发paging消息，其中paging cause值是“emergency”；否则，下发的paging cause值是“非emergency”。

步骤720：ENODEB收到paging消息后，转发给UE。如果ENODEB自CN收到的paging消息中的paging cause值是“emergency”，则下发给UE侧的pagingcause值也是“emergency”；否则，下发给UE侧的paging cause值是“非emergency”。

步骤730：UE收到这个寻呼消息后，检查paging cause，如果是“emergency”，则忽略SSACB，直接进行接入。否则，进行正常接入过程。由于本步骤的具体处理过程前述多个实施例中已经做过详细介绍，故此处不再赘述。

基于与前述处理涉及紧急呼叫中被叫用户的方法多个实施例的同一发明构思，本发明实施例还公开了一种处理紧急呼叫的用户侧装置，该装置可以设置在各种用户设备中，如固定电话、移动电话等。请参阅图8，为本发明用户侧装置实施例的结构示意图，同时，为了更清楚的叙述本实施例装置，也在图中给出了与该装置直接通信的接入控制节点。同理，本实施例中的接入控制节点包括但不限于LTE系统中的ENODEB、UMTS系统中的RNC以及GSM系统中的BSC。下面结合该装置的工作原理，进一步揭示其内部结构。当然，由于前述多个方法实施例中已经公开过许多相同或相应的技术特征，因此，下面仅简单叙述。

首先由接收单元81接收来自接入控制节点的寻呼消息，然后由消息解析单元82从所述寻呼消息中解析寻呼原因或者寻呼消息中的紧急呼叫指示，所述寻呼原因或者寻呼消息中的紧急呼叫指示可能是紧急呼叫，也可能是非紧急呼叫，关于寻呼消息的具体内容前文已有详述，故此处不再赘述。

在消息解析单元82解析出寻呼原因或者寻呼消息中的紧急呼叫指示后，则交由接入处理单元83进行后续处理。具体而言，所述接入处理单元83包括紧急接入处理子单元831和普通接入处理子单元832，如果消息解析单元82解析出的寻呼原因或者寻呼消息中的紧急呼叫指示不是紧急呼叫，则由普通接入处理子单元832正常执行SSACB，进行常规接入；如果消息解析单元82解析出的寻呼原因或者寻呼消息中的紧急呼叫指示是紧急呼叫，则由紧急接入处理子单元831忽略SSACB，直接向接入控制节点进行接入。就紧急接入处理子单元831而言，其又具体包括接入原因处理模块和接入请求处理模块，其中，通过接入原因处理模块将作为寻呼原因的紧急呼叫拷贝到接入原因中或者根据寻呼消息中的紧急呼叫指示来设定接入原因，然后再由接入请求处理模块向接入控制节点发送包含接入原因为紧急呼叫的接入请求，所述接入原因中的紧急呼叫作为接入控制节点给予此次接入请求最高优先权的依据。换而言之，接入控制节点给予接入原因为紧急呼叫的接入请求最高接入服务级别，给予该次接入最高的优先级，使该紧急呼叫或紧急呼叫的回叫能够尽量呼通。

进一步，还可以在接入处理单元83中设置控制子单元，通过所述控制子单元控制紧急接入处理子单元是否被禁止，例如通过一个全局变量来控制，该全局变量的值可以系统广播消息中的紧急允许指示进行设置(此部分的详细内容参看前文)。如果所述紧急接入处理子单元831被禁止(如系统不允许被叫用户忽略SSACB)，则在消息解析单元82解析出的寻呼原因或者寻呼消息中的紧急呼叫指示为紧急呼叫的情况下，控制子单元就会控制普通接入处理子单元832代替紧急接入处理子单元831进行处理，换而言之，此种情况下，虽然接入控制节点下发的寻呼信息指示本次呼叫为紧急呼叫，但是用户侧仍然作为普通寻呼处理。如果所述紧急接入处理子单元831没有被禁止，则在消息解析单元82解析出的寻呼原因或者寻呼消息中的紧急呼叫指示为紧急呼叫的情况下，仍然由紧急接入处理子单元831进行后续接入处理。通过以上多个具体的实施例可以看出，在本发明技术方案中，通过向紧急呼叫或紧急呼叫回叫中的被叫用户指示本次寻呼为紧急呼叫，以及被叫用户忽略SSACB直接进行接入的操作，使得所述被叫用户不再受SSACB的限制，具有较高的优先权，因此提高了涉及紧急呼叫的寻呼的呼通率，使得受困用户可以在第一时间得到帮助。

进一步，由于涉及紧急呼叫的被叫用户在向接入控制节点进行接入时，告知了接入原因为紧急呼叫，进而，接入控制节点给与该接入请求最高的接入服务级别，使得该接入请求能够优先得到各种分配资源，使涉及紧急呼叫的被叫用户优先接入系统，从而进一步保证了紧急呼叫或其回叫的呼通率。

以上介绍了本发明处理紧急呼叫中被叫用户的方法第三实施例，相应的，本实施例的技术方案也同样适用于紧急呼叫的回叫过程中寻呼被叫用户，此处不再赘述。

以上对本发明所提供的处理紧急呼叫或紧急呼叫回叫中被叫用户的方法以及被叫用户处理紧急呼叫的方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

以上对本发明所提供的一种处理紧急呼叫中被叫用户的方法和处理紧急呼叫回叫中被叫用户的方法以及被叫用户处理紧急呼叫的方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。