CN101141784A - 一种跨接入设备的空闲态寻呼的方法、接入设备和系统 - Google Patents

Abstract

本发明公开了一种跨接入设备的空闲态寻呼的方法，该方法为：当网络中有多个接入设备向接入终端发送寻呼时，任意一个接收到接入终端寻呼响应的接入设备，通知网络中寻呼接入终端的其他接入设备，接入终端已响应寻呼。这样，其他接入设备收到该通知后，就知道接入终端已经响应了寻呼，就可以不必再向接入终端发送寻呼，大大节省了接入设备的资源和宝贵的空口资源。本发明还公开了一种实现跨接入设备空闲态寻呼的接入设备和系统。

Description

一种跨接入设备的空闲态寻呼的方法、接入设备和系统

技术领域

本发明涉及移动通信领域，特别涉及一种跨接入设备的空闲态寻呼的方法、接入设备和系统。

背景技术

现有的码分多址接入(Code Devision Multiple Access，CDMA)2000系统，包括CDMA 1x和高速分组数据(High Rate Packet Data，HRPD)系统，能提供高达153.6kbps的数据速率，可以开展视频点播(Video onDemand，VOD)、网上游戏、高速数据下载等分组数据业务，如何有效地进行业务移动性管理是非常重要的，业务的移动性管理的目的之一是在移动终端移动时保证业务的连续性。

现有的CDMA2000网络分组域结构如图1所示。在图1中，实线是承载数据的传输通路，虚线是信令的传输通路。移动终端在接入网设备(AccessNetwork，AN)/分组控制功能(Packet Control Function，PCF)的覆盖范围内，分组数据服务节点(Packet Data Serving Node，PDSN)通过点对点协议(Point-to-Point Protocol，PPP)将移动终端接入IP网络，同时为分组数据包提供下一跳的路由。

目前3GPP2标准组织为了保证其未来系统的竞争力，正在进行网络演进项目的研究，主要关注的问题是IP分组网络的长期演进问题。其主要的目的就是增强分组交换能力、简化网络结构、提高服务质量(Qulity ofService，QoS)、减少时延、提高用户数据率、提高系统容量和覆盖率、减少运营成本等，使得演进后的分组网络能够更加有效的提供对实时业务和非实时业务的承载，为用户提供更加丰富的业务。

基于网络演进的需求，提出的基本演进网络框架如图2所示。在该图中，控制接入点(Controlling Access Point，CAP)具有接入网关和无线资源管理的功能。CAP具有的接入网关的功能主要表现在，作为移动台(MobileStation，MS)的第一跳路由器，移动性管理、QoS支持、承担部分原PDSN的功能。而CAP具有的无线资源管理功能包括公用资源管理、专用资源管理、无线会话管理、维护MS的会话状态、无线链路管理等。网络移动性代理(Network Mobility Agent，NMA)提供CAP之间层三(Layer3，L3)移动性管理机制，不需要空口的移动IP信令。NMA是一个可选实体，如果不采用NMA，则CAP直接和家乡代理(Home Agent，HA)相连，他们之间的接口使用移动IP(Mobile IP，MIP)或代理移动IP(Proxy Mobile IP，PMIP)。

在使用NMA实体的情况下，终端在接入网络时，通过CAP获得的地址是在整个NMA的范围内有效的，CAP将MS的地址和CAP本身的地址在NMA进行注册绑定，以使数据能正确路由。

目前在3GPP2组织制定的HRPD规范中规定了终端在空闲状态下，在AN间移动时，发生了跨AN的情况后，终端需要主动发起AT在AN中的地址(Unicast AT Identifier，UATI)申请，更新终端的UATI参数以及用户的路由信息。为了减小终端空闲状态下在AN间移动情况下频繁地发起UATI请求，造成频繁乒乓注册，3GPP2组织定义了SecondaryColorCode功能，当终端在两个或多个AN覆盖范围内移动时，可以使用SecondaryColorCode参数标识新的AN，而无需终端在多个AN覆盖范围内频繁地发起UATI请求。

为配合SecondaryColorCode特性的使用，需要提供一种终端在空闲状态下，跨AN的空闲态寻呼的流程，以增加终端寻呼的成功率。

3GPP2组织正常讨论在当前的HRPD网络下空闲态AN之间的寻呼，以配合在C.S0024-B版本中SecondaryColorCode这个新的空口特性，其流程具体如图3所示，包括：

步骤301，AT在边界扇区注册，寻呼区域覆盖属于目标AN的扇区。这可能是由于基于距离的寻呼或SecondaryColorCode特性引入的子网滞回。

步骤302，源AN根据一定的策略判断需要通过源AN下的某些RT和目标AN下的某些RT寻呼AT。源AN发送寻呼请求消息Paging Request到目标AN。寻呼请求消息包括寻呼和表明通过前向控制信道发送到AT的寻呼信息。

步骤303，源AN和目标AN通过控制信道同时发送寻呼到AT；

发送寻呼到AT即为寻呼AT。

步骤304，当AT接收到寻呼消息之后，AT请求HRPD连接。假定目标AN接收到AT的请求。目标AN发起HRPD会话建立。UATI可以作为一个标识，使得目标AN能从源AN获得存在的HRPD会话状态信息。

事实上，AT请求HRPD连接的消息即为AT的寻呼响应。

除接收到接入终端的寻呼响应的AN外，那些寻呼接入终端却并未直接收到接入终端发送的寻呼响应的接入设备称为其他AN。

步骤305，目标AN发送A13-Session Information Request消息到源AN，为AT请求HRPD会话状态信息。A13-Session Information Request消息应该包括接收到的UATI，安全层包和sector ID。

步骤306，源AN验证A13-Session Information Request消息后，源AN通过A13-Session Information Response消息发送请求的AT的HRPD会话信息到目标AN。

步骤307，AT和目标AN之间完成HRPD会话的建立。根据AT的状态，目标AN可以重建存在的HRPD会话，或如果需要则发起新的HRPD会话。如果没有空口信令，则该步可以为空。

步骤308，如果目标AN支持位置更新过程，则通过使用位置更新过程更新AT的ANID。如果需要，AT也可以获PANID，比如，在步骤306中获得的会话配置中表明源AN不支持位置更新过程。

步骤309，目标AN发送A13-Session Information Confirm消息到源AN表明目标AN已经接收到HRPD会话信息。当接收到A13-Session InformationConfirm消息之后，源AN删除AT相关的HRPD会话信息。

步骤310，目标AN发送A9-Setup-A8消息到目标PCF，数据准备指示置为“0”。该消息包括所有A8连接需要的信息，用于IP flow映射，由源AN维持的，通过空口协商。该消息包括在步骤306通过A13-SessionInformation Response消息从源AN获得的PDSN地址。A9切换指示IE中的切换指示置为“0”。如果AT没有穿过HRPD分组区域，则目标PCF和源PCF是同一实体。

步骤311，目标PCF选择使用A9-Setup-A8消息中的PDSN或是通过PDSN选择算法选择一个PDSN，并发送A11-Registration Request消息到PDSN建立A10连接。

步骤312，PDSN验证A11-Registration Request消息之后，PDSN接受建立A10连接，发送A11-Registration Reply消息，带接受指示和配置的生命周期。如果PDSN有数据要发送，则在CVSE中带数据可用指示。如果有签约用户的QoS信息，则包括在NVSE中。在PDSN的A10连接绑定信息更新到目标PCF。

步骤313，如果PDSN有A10连接到其他PCF，比如源PCF，则发起A11-Registration Update消息关闭和那个PCF的A10连接。

步骤314，源PCF响应A11-Registration Acknowledge消息。

步骤315，源PCF发送A11-Registration Request消息到PDSN，生命周期置为0。

步骤316，PDSN发送A11-Registration Reply消息到源PCF，源PCF关闭AT的A10连接。

步骤317，假定在步骤310没有数据可用指示，目标PCF响应A9-Release-A8-Complete消息到目标AN。另外，本步骤可以发生在步骤310之后的任何时刻。

至此，跨AN的空闲态寻呼流程结束。

由于使用了SecondaryColorCode这个新特性，需要支持AN之间的空闲态寻呼。寻呼消息发送到多个AN，并通过多个AN对AT进行寻呼，包括源AN和相关的目标AN。当其中一个AN接收到AT的寻呼响应，而这时除了该AN外的其他AN都不知道AT已经响应了该寻呼，其他AN都继续进行寻呼，浪费AN资源和宝贵的空口资源。

上述是以CDMA2000系统中的跨AN的空闲态寻呼为例介绍的现有技术。事实上，在基本演进网络架构中，在空闲态寻呼时，是由接入设备的功能由CAP来完成，即向AT发送寻呼；当任意一个CAP接收到AT的寻呼响应后，同样其他的CAP也不知道AT已经响应了该寻呼，会同样存在浪费CAP资源和空口资源的问题。

发明内容

有鉴于此，本发明提供一种跨接入设备的空闲态寻呼方法，能够节省接入设备和空口资源。

本发明还提供一种实现跨接入设备的空闲态寻呼的接入设备，应用该设备进行空闲态寻呼，能够节省接入设备和空口资源。

本发明又提供一种跨接入设备的空闲态寻呼的系统，在该系统中进行空闲态寻呼，能够节省接入设备和空口资源。

为实现上述第一个发明目的，采用如下的技术方案：

一种跨接入设备的空闲态寻呼的方法，其特征在于，当网络中有多个接入设备向接入终端发送寻呼时，任意一个接收到接入终端寻呼响应的接入设备，通知网络中寻呼接入终端的其他接入设备，接入终端已响应寻呼。

较佳地，当所述接收到接入终端寻呼响应的接入设备为接入终端的源接入设备时，源接入设备直接向寻呼接入终端的其他接入设备发送通知消息，通知它们接入终端已响应寻呼。

较佳地，所述通知消息为事件通知消息或转发的寻呼响应消息。

较佳地，所述寻呼接入终端的其他接入设备接收到源接入设备发送的通知消息后，进一步返回通知应答，并停止寻呼接入终端。

较佳地，该方法包括：

a、源接入设备根据策略决定向网络中的目标接入设备发起接入设备间寻呼，并向其发送寻呼请求消息；

b、源接入设备和接收到寻呼请求消息的目标接入设备向接入终端发送寻呼；

c、源接入设备接收到接入终端的寻呼响应，向网络中寻呼接入终端的其他目标接入设备发送事件通知消息；

d、对于网络中寻呼接入终端的其他目标接入设备，接收到事件通知消息后，向源接入设备返回事件通知应答，并停止寻呼接入终端。

较佳地，当所述接收到接入终端寻呼响应的接入设备为接入终端的目标接入设备时，

目标接入设备向接入终端的源接入设备发送寻呼请求的响应消息，通知源接入设备接入终端已响应寻呼；

源接入设备接收到该寻呼请求的响应消息后，向网络中寻呼接入终端的其他目标接入设备发送通知消息，通知它们接入终端已响应寻呼。

较佳地，所述寻呼请求的响应消息中携带：接入终端发送的寻呼响应或经过目标接入设备处理后的寻呼响应内容。

较佳地，所述通知消息为事件通知消息或转发的寻呼响应。

较佳地，所述源接入设备接收到目标接入设备发送的寻呼响应后，停止寻呼接入终端；

所述寻呼接入终端的其他目标接入设备接收到源接入设备发送的事件通知消息后，进一步向源接入设备返回通知应答，并停止寻呼接入终端。

较佳地，该方法包括：

a1、源接入设备根据策略决定向网络中的某些接入设备发起接入设备间寻呼，并向其发送寻呼请求消息；

b1、源接入设备和接收到寻呼请求消息的目标接入设备向接入终端发送寻呼；

c1、某个目标接入设备接收到接入终端的寻呼响应，并向源接入设备发送寻呼请求的响应消息，源接入设备接收到寻呼请求的响应消息后，停止寻呼接入终端；

d1、对于网络中其他未接收到寻呼响应的目标接入设备，源接入设备向其发送事件通知消息；

e1、网络中其他未接收到寻呼响应的目标接入设备，向源接入设备返回事件通知应答，并停止寻呼接入终端。

为实现上述第二个发明目的，采用如下的技术方案：

一种实现跨接入设备的空闲态寻呼的接入设备，其特征在于，该接入设备至少包括接入终端寻呼模块和接入设备间寻呼模块；

所述接入终端寻呼模块，用于向接入终端发送寻呼，并将接收到的接入终端返回的寻呼响应发送给所述接入设备间寻呼模块；

所述接入设备间寻呼模块，用于接收所述接入终端寻呼模块发送的寻呼响应，并将接入终端已接收到寻呼的通知消息发送出去。

较佳地，所述接入设备为码分多址接入CDMA2000系统中的接入网设备AN或基本演进网络中的控制接入点CAP。

为实现上述第三个发明目的，采用如下的技术方案：

一种跨接入设备的空闲态寻呼的系统，其特征在于，该系统包括：接入终端和多个接入设备，其中，

所述接入终端，用于在接收到某个接入设备的寻呼后，向该接入设备返回寻呼响应；

接收到所述接入终端寻呼响应的接入设备，用于向所述接入终端发送寻呼，当接收到所述接入终端返回的寻呼响应后，通知寻呼接入终端的其他接入设备，所述接入终端已响应寻呼；

未接收到所述接入终端寻呼响应的接入设备，用于向所述接入终端发送寻呼，并接收已接收到所述接入终端寻呼响应的接入设备发送的通知。

较佳地，所述多个接入设备为源接入设备和一个目标接入设备；

所述接入终端，向所述目标接入设备发送寻呼响应；

所述目标接入设备，用于通知所述源接入设备，接入终端已收到寻呼；

所述源接入设备，用于接收所述目标接入设备发送的通知，并停止寻呼接入终端。

较佳地，所述多个接入设备为源接入设备和至少两个目标接入设备；

所述接入终端，向所述目标接入设备中的某一个发送寻呼响应；

接收到寻呼响应的目标接入设备，用于通知所述源接入设备，接入终端已收到寻呼；

所述源接入设备，用于接收所述接收到寻呼响应的目标接入设备发送的通知，并停止寻呼接入终端，还用于向未接收到寻呼响应的目标接入设备发送事件通知消息，通知它们所述接入终端已响应呼叫，并接收未接收到寻呼响应的目标接入设备返回的事件通知应答；

未接收到寻呼响应的目标接入设备，用于接收所述源接入设备发送的事件通知消息，向所述源接入设备返回事件通知应答，并停止寻呼接入终端。

较佳地，所述多个接入设备为源接入设备和至少一个目标接入设备；

所述接入终端，向所述源接入设备发送寻呼响应；

所述源接入设备，用于接收所述接入终端发送的寻呼响应，向寻呼接入终端的所述目标接入设备发送事件通知消息，通知它们所述接入终端已响应寻呼，并接收所述目标接入设备返回的事件通知应答；

所述目标接入设备，用于接收所述源接入设备发送的事件通知消息，向所述源接入设备返回事件通知应答，并停止寻呼接入终端。

较佳地，所述系统为CDMA2000系统或基本演进网络架构。

由上述可见，在本发明中，当网络中有多个接入设备向接入终端发送寻呼时，任意一个接收到接入终端寻呼响应的接入设备，通知网络中寻呼接入终端的其他接入设备，接入终端已响应寻呼。这样，其他接入设备收到该通知后，就知道接入终端已经响应了寻呼，就可以不必再向接入终端发送寻呼，大大节省了接入设备的资源和宝贵的空口资源。

附图说明

图1为现有的CDMA2000网络分组域结构图。

图2为3GPP2的基本演进网络框架结构图。

图3为当前的HRPD网络下跨AN的空闲态寻呼流程图。

图4为本发明中跨接入设备的空闲态寻呼的方法总体流程图。

图5为本发明中实现跨接入设备的空闲态寻呼的接入设备的总体结构图。

图6为本发明中实现跨接入设备的空闲态寻呼的系统总体结构图。

图7为目标接入设备响应寻呼时空闲态寻呼的流程图。

图8为源接入设备响应寻呼时空闲态寻呼的流程图。

图9为本发明实施例一中跨AN的空闲态寻呼的方法流程图。

图10为CDMA200系统中跨AN空闲态寻呼的接入设备和系统的具体结构图。

图11为本发明实施例二中跨AN的空闲态寻呼的方法流程图。

图12为本发明实施例三中跨CAP的空闲态寻呼的方法流程图。

图13为3GPP2的基本演进网络架构下跨CAP空闲态寻呼的接入设备和系统的具体结构图。

图14为本发明实施例二中跨CAP的空闲态寻呼的方法流程图。

具体实施方式

为使本发明的目的、技术手段和优点更加清楚明白，以下结合附图并举实施例说明本发明的具体实施方式。

本发明的基本思想是：当网络中有多个接入设备向接入终端发送寻呼时，任意一个接收到接入终端寻呼响应的接入设备，通知网络中寻呼接入终端的其他接入设备，接入终端已响应寻呼。

图4为本发明中跨接入设备的空闲态寻呼的方法总体流程图。如图4所示，该方法包括：

步骤401，源接入设备和某些目标接入设备共同向接入终端发送寻呼；

步骤402，接入终端响应某一接入设备的寻呼，则该接入设备通知网络中寻呼接入终端的其他接入设备，接入终端已响应寻呼。

图5为本发明中实现跨接入设备的空闲态寻呼的接入设备的总体结构图。如图5所示，该接入设备500包括：接入终端寻呼模块501和接入设备间寻呼模块502。

在接入设备500中，接入终端寻呼模块501，用于向接入终端发送寻呼，并将接收到的接入终端返回的寻呼响应发送给接入设备间寻呼模块502；接入设备间寻呼模块502，用于接收接入终端寻呼模块501发送的寻呼响应，并将接入终端已响应寻呼的通知消息发送给寻呼接入终端的其他接入设备的接入设备间寻呼模块。

图6为本发明中实现跨接入设备的空闲态寻呼的系统总体结构图。如图6所示，该系统包括：接入终端601和多个接入设备，分别为接入设备1602、接入设备2603、接入设备3603...、接入设备n603。

在该系统中，接入设备1602、接入设备2603、...、接入设备n 603共同向接入终端601发送寻呼；接入终端601接收到其中接入设备1602的寻呼，并向接入设备1602返回寻呼响应；接入设备1602接收到接入终端的寻呼响应后，通知寻呼接入终端的接入设备2603、接入设备3603、...、接入设备n 603，接入终端601已经响应寻呼；接入设备2603、接入设备3603、...、接入设备n 603，接收接入设备1602发送的通知。图6中的实线表示直接的信令消息传输方向，虚线表示接入设备1602向接入设备2603、接入设备3603、...、接入设备n 603发送的通知可能是直接发送，或经过其他设备处理后间接发送。

由上述可见，利用本发明的方法、接入设备和系统，能够实现在跨接入设备的空闲态寻呼中，收到接入终端寻呼响应的接入设备，通知网络中向接入终端发送寻呼的其他接入设备，接入终端已经响应寻呼。这样其他接入设备就可以减少发送寻呼的次数或者不再发送寻呼到接入终端，实现了节省接入设备资源和空口资源的目的。

对于接入终端发送的寻呼响应，接入终端的源接入设备和目标接入设备接收到该寻呼响应时，通知其他接入设备接入终端已响应寻呼的方式是不同的。

图7为目标接入设备响应寻呼时空闲态寻呼的流程图。如图7所示，该流程包括：

步骤701，源接入设备决定向目标接入设备1和目标接入设备2发起接入设备间寻呼；

步骤702，源接入设备向目标接入设备1和目标接入设备2发送寻呼请求消息；

步骤703，源接入设备、目标接入设备1和接入设备2向AT发送寻呼消息；

步骤704，AT向目标接入设备1发送寻呼响应；

步骤705，当目标接入设备1接收到AT的寻呼响应之后，发送与步骤702中寻呼请求消息对应的寻呼请求的响应消息到源接入设备，通知源接入设备AT已经响应寻呼。源接入设备可以停止寻呼AT或进行其他相应的处理，如减少寻呼次数等；

步骤706，当源接入设备接收到寻呼请求的响应消息后，向目标接入设备1发送寻呼响应应答消息；

步骤707，源接入设备发送通知消息到目标接入设备2，表示目标接入设备2可以停止对当前AT的寻呼或减少寻呼次数；

所述通知消息可以是事件通知消息或转发的寻呼响应，只要是能达到通知目标接入设备2，接入终端已响应寻呼的目的即可；另外，本步骤可以在步骤705之后任何时刻执行。

步骤708，当目标接入设备2接收到通知消息后，向源接入设备发送通知应答消息。

至此，网络中向接入终端发送寻呼的接入设备就都知道了接入终端已经响应寻呼的消息。接入设备就可以停止寻呼接入终端或进行其他相应的处理。

由图7的流程可以看出，当AT的目标接入设备接收到AT的寻呼响应后，需要首先通知AT的源接入设备，AT已收到寻呼，由源接入设备再通知其他目标接入设备。接下来，介绍当AT的源接入设备接收到AT的寻呼响应后，通知目标接入设备的过程。

图8为源接入设备响应寻呼时空闲态寻呼的流程图。如图8所示，该流程包括：

步骤801，源接入设备决定向目标接入设备1和目标接入设备2发起接入设备间寻呼；

步骤802，源接入设备向目标接入设备1和接入设备2发送寻呼请求消息；

步骤803，源接入设备、目标接入设备1和接入设备2向AT发送寻呼消息；

步骤804，AT向源接入设备响应寻呼消息；

步骤805，当源接入设备接收到寻呼响应消息后，向目标接入设备1和接入设备2发送通知消息；

所述通知消息可以是事件通知消息或转发的寻呼响应，只要是能达到通知目标接入设备2，接入终端已响应寻呼的目的即可。

步骤806，当目标接入设备1和接入设备2接收到事件通知消息后，向源接入设备发送事件通知应答消息。

至此，网络中向接入终端发送寻呼的接入设备就都知道了接入终端已经响应寻呼的消息。接入设备就可以停止寻呼接入终端或进行其他相应的处理。

由图8所示的流程可以看出，与图7所示的流程不同，当AT向源接入设备发送寻呼响应后，源接入设备直接向其他目标接入设备发送事件通知消息，通知它们AT已经响应寻呼。

下面就以在CDMA2000和基本演进网络架构为例，说明上述两种空闲态寻呼的具体实施方式。

实施例一和实施例二以CDMA2000系统中的跨AN空闲态寻呼为例，说明本发明在CDMA2000系统中的应用。

实施例一：

假定在本实施例中，源AN、目标AN1和目标AN2向AT发送了寻呼，AT向其中的目标AN1发送了寻呼响应。

图9为本发明实施例一中跨AN的空闲态寻呼的方法流程图。如图9所示，该方法包括：

步骤901，AT在边界扇区注册，寻呼区域覆盖属于目标AN1和目标AN2的扇区。这可能是由于基于距离的寻呼或子网滞回引入的。

步骤902，源AN根据一定的策略判断需要通过源AN下的某些RT，目标AN1下的某些RT以及目标AN2下的某些RT寻呼AT。源AN发送寻呼请求(Paging Request)消息到目标AN1和目标AN2。寻呼请求消息包括寻呼和表明通过前向控制信道发送到AT的寻呼信息。

步骤903，源AN、目标AN1和目标AN2通过控制信道同时发送寻呼到AT。

步骤904，发起HRPD会话建立；

本步骤中，当AT接收到寻呼消息之后，AT请求HRPD连接，该HRPD连接请求即为寻呼响应消息；目标AN1接收到AT的请求，目标AN1发起HRPD会话建立；UATI可以作为一个标识，使得目标AN1试图从源AN获得存在的HRPD会话状态信息。

步骤905，目标AN1发送寻呼请求的响应(Paging Response)消息到源AN；

本步骤中，当目标AN1接收到AT的寻呼响应后，利用对步骤902中寻呼请求消息的响应-Paging Response消息，携带通知发送给源AN，AT已响应寻呼；在Paging Response消息中，可以携带AT发送的寻呼响应，或者携带经过目标AN1处理后的寻呼响应的内容信息。

步骤906，当从目标AN1接收到Paging Response消息后，源AN响应寻呼响应应答(Paging Response Ack)消息；

本步骤中，源AN接收到目标AN1发送的Paging Response消息后，即停止对AT的寻呼或进行其他相应的处理。

步骤905～906可以发生在目标AN1检测到AT在其覆盖范围内之后的任何时刻。

步骤907，源AN向目标AN2发送事件通知(Event Notification)消息；

本步骤中，事件通知消息表示目标AN2可以停止对当前AT的寻呼；本步骤可以发生在步骤905之后的任何时刻。

步骤908，目标AN2响应事件通知应答(Event Notification Ack)消息；

本步骤中，目标AN2接收到源AN1发送的事件通知消息后，即可以停止对AT的寻呼或进行其他相应的处理。

步骤909，目标AN1向源AN发送会话信息请求(A13-SessionInformation Request)消息；

本步骤中，目标AN1发送会话信息请求(A13-Session InformationRequest)消息到源AN，为AT请求HRPD会话状态信息；会话信息请求(A13-Session Information Request)消息应该包括接收到的UATI，安全层包和sector ID；本步骤可以发生在步骤904之后的任何时刻。

步骤910，源AN向目标AN1发送会话信息响应(A13-SessionInformation Response)消息；

本步骤中，源AN验证A13-Session Information Request消息后，源AN通过A13-Session Information Response消息发送请求的AT的HRPD会话信息到目标AN1。

步骤911，AT和目标AN1之间完成HRPD会话的建立；

本步骤中，根据AT的状态，目标AN1可以重建存在的HRPD会话，或如果需要则发起新的HRPD会话；如果没有空口信令，则本步骤可以为空。

步骤912，进行位置更新过程；

本步骤中，如果目标AN1支持位置更新过程，则通过使用位置更新过程更新AT的ANID；如果需要，AT也可以获PANID，比如，在步骤910中获得的会话配置中表明源AN不支持位置更新过程。

步骤913，目标AN1发送会话信息确认(A13-Session InformationConfirm)消息到源AN；

本步骤中，A13-Session Information Confirm消息表明目标AN1已经接收到HRPD会话信息；当接收到A13-Session Information Confirm消息之后，源AN删除AT相关的HRPD会话信息。

步骤914，目标AN1发送A9-Setup-A8消息到目标PCF；

本步骤中，数据准备指示置为“0”。该A9-Setup-A8消息包括所有A8连接需要的信息，用于IP流(IP flow)映射，由源AN维持的，通过空口协商获得；该消息包括在步骤903中通过A13-Session Information Response消息从源AN获得的PDSN地址；A9切换指示IE中的切换指示置为“0”。

本实施例中，假定AT穿过了HRPD分组区域，因此目标PCF与源PCF为不同实体；如果AT没有穿过HRPD分组区域，则目标PCF和源PCF是同一实体。

步骤915，目标PCF发送A11-Registration Request消息到PDSN建立A10连接；

本步骤中，目标PCF选择使用A9-Setup-A8消息中的PDSN或是通过PDSN选择算法选择一个PDSN，并发送A11-Registration Request消息到PDSN建立A10连接。

步骤916，PDSN发送A11-Registration Reply消息，接受建立A10连接；

本步骤中，PDSN验证A11-Registration Request消息之后，PDSN接受建立A10连接，发送A11-Registration Reply消息，带接受指示和配置的生命周期；如果PDSN有数据要发送，则在CVSE中带数据可用指示；如果有签约用户的QoS信息，则包括在NVSE中；在PDSN的A10连接绑定信息更新到目标PCF。

步骤917，PDSN发送A11-Registration Update消息；

本步骤中，如果PDSN有A10连接到其他PCF，比如源PCF，则发起A11-Registration Update消息关闭和那个PCF的A10连接。

步骤918，源PCF响应A11-Registration Acknowledge消息。

步骤919，源PCF发送A11-Registration Request消息到PDSN，生命周期置为0。

步骤920，PDSN发送A11-Registration Reply消息到源PCF，源PCF关闭AT的A10连接。

步骤917～920为条件执行步骤，当满足步骤917中的条件时，执行步骤917～920，否则不执行步骤917～920。

步骤921，假定在步骤914中没有数据可用指示，目标PCF响应A9-Release-A8-Complete消息到目标AN1。本步骤可以发生在步骤914之后的任何时刻。

至此，本实施例中跨AN的空闲态寻呼的全过程结束。由上述过程可以看出，在空闲态寻呼时，若目标AN接收到AT的寻呼响应，则该目标AN会首先向源AN发送AT已收到寻呼的通知，再由源AN向其他目标AN发送事件通知消息，通知它们AT已响应寻呼。在AT响应寻呼后，AT与目标AN间重新建立会话和拆除原有连接关系的过程与现有技术相同。这样，不会影响现有技术的流程，同时节省了AN和空口资源。

上面介绍了本实施例中跨AN的空闲态寻呼的具体过程，本实施例还提供了用于实现跨AN空闲态寻呼的接入设备，即AN。图10即为本发明实施例中跨AN空闲态寻呼的接入设备和系统的具体结构图。

如图10所示，该系统包括：AT1000、目标AN1 1010、源AN 1020和目标AN2 1030。其中，目标AN1 1010包括接入终端寻呼模块1011和接入设备间寻呼模块1012，源AN 1020包括接入终端寻呼模块1021、接入设备间寻呼模块1022和策略判决模块1023，目标AN2 1030包括接入终端寻呼模块1031和AN间寻呼模块1032。

本系统中的目标AN1 1010、源AN 1020和目标AN2 1030即为图5中所示接入设备的具体化。其中的AN间寻呼模块即为图5中所示接入设备间寻呼模块的具体化。

在该系统中，AT 1000在边界扇区注册，寻呼区域覆盖属于目标AN1和目标AN2的扇区。源AN 1020中的策略判决模块1023根据一定的策略判定通过目标AN1和目标AN2来寻呼AT，即向AN间寻呼模块1022发送消息；AN间寻呼模块1022接收到策略判决模块1023发送的消息后，即分别向目标AN1 1010和目标AN2 1030的AN间寻呼模块1012和1032发起AN间寻呼，并通知接入终端寻呼模块1021向AT 1000发送寻呼。

目标AN1 1010中的AN间寻呼模块1012接收到源AN 1020发送的寻呼请求消息后，通知接入终端寻呼模块1011向AT 1000发送寻呼。同理，目标AN2 1030也通过接入终端寻呼模块1031向AT 1000发送寻呼。

假定AT 1000向目标AN1发送寻呼响应，目标AN1中的接入终端寻呼模块1011接收到该寻呼响应后，即将该寻呼响应发送给AN间寻呼模块1012，AN间寻呼模块1012将AT已响应寻呼的寻呼请求的响应消息发送给源AN 1020中的AN间寻呼模块1022。在发送的寻呼请求的响应消息中，如有必要可以携带AT发送的寻呼响应或经过处理后的寻呼响应的内容。

在源AN 1020中，AN间寻呼模块1022，用于接收目标AN1 1010发送的寻呼请求的响应消息，向目标AN1 1010中的AN间寻呼模块1012返回寻呼响应应答，并通知接入终端寻呼模块1021，AT 1000已响应寻呼；还用于向目标AN2 1030发送接入终端已响应寻呼的事件通知消息，并接收目标AN2 1030返回的事件通知应答消息；接入终端寻呼模块1021，接收到AN间寻呼模块1022发送的通知后，即停止对AT 1000的寻呼或进行其他相应的处理，如减少寻呼次数等。

在目标AN2 1030中，AN间寻呼模块1032，用于在接收源AN 1020发送的事件通知消息后，向源AN 1020中的AN间寻呼模块1022返回事件通知应答，并通知接入终端寻呼模块1031停止寻呼AT 1000。

关于目标AN1 1010、源AN 1020和AT 1000间建立会话和拆除原有会话的模块与现有技术相同，这里就不再赘述。

上述即为基于本实施例中基于本发明的接入设备的跨AN间空闲态寻呼的系统结构。

在本实施例中，假定共有三个AN对AT发起寻呼，当然在实际应用中，可能存在更多或更少的AN对AT发起寻呼，只要是某个目标AN接收到AT的寻呼响应，均可以按照本实施例中的方式实施本发明。

具体地，当只存在两个AN对AT发起寻呼时，目标AN接收到AT的寻呼响应后，将AT已收到寻呼的通知发送给源AN，源AN即停止寻呼AT或进行其他相应的处理；由于不存在其他寻呼AT的AN，因此源AN不必再通知其他AN，AT已响应寻呼。

当存在三个以上AN对AT发起寻呼时，目标AN接收到AT的寻呼响应后，将AT已收到寻呼的通知发送给源AN，源AN再通知未收到寻呼响应的所有寻呼AT的AN，AT已响应寻呼。

由本实施例中的实施方式可见，本发明在CDMA2000系统中进行跨AN间空闲态寻呼过程中，当任意一个目标AN接收到AT返回的寻呼响应时，均可以通知源AN，AT已收到寻呼，再由源AN通知其他寻呼AT的目标AN，AT已响应寻呼。这样，其他AN就可以不必再寻呼AT，节省了AN和空口资源。尤其当网络中寻呼AT的AN数目很大的情况下，可以极大地节省AN和空口资源。

实施例二：

假定在本实施例中，源AN、目标AN1和目标AN2向AT发送了寻呼，AT向其中的源AN发送了寻呼响应。

图11为本发明实施例二中跨AN的空闲态寻呼的方法流程图。如图11所示，该方法包括：

步骤1101～1103，AT注册到边界扇区后，源AN通知目标AN1和目标AN2共同寻呼AT；

可以看出，本实施例中的步骤1101～1103与图9中步骤901～903的操作相同，这里就不再详细描述。

步骤1104，发起HRPD会话建立；

本步骤中，当AT接收到寻呼消息之后，AT请求HRPD连接。假定源AN接收到AT的请求；源AN发起HRPD会话建立。

步骤1105，源AN向目标AN1和目标AN2发送Event Notification消息，表示目标AN1和目标AN2可以停止对当前AT的寻呼；当然在实际应用中，还可以定义Event Notification消息表示进行其他相应的处理，如减少寻呼次数等。

步骤1106，目标AN1和目标AN2响应Event Notification Ack消息。

步骤1105～1106“可以发生在源AN检测到AT在其覆盖范围内之后的任何时刻。

步骤1107，源AN发送A9-Setup-A8消息到源PCF，如果有数据需要发送，则数据准备指示置为“1”；否则置为“0”；

本步骤可以发生在步骤1104之后的任何时刻。

步骤1108，如果步骤1107中数据准备指示置为“1”，则源PCF响应A9-Connect-A8消息到源AN。

步骤1109，AT和源AN之间完成HRPD会话的建立；

本步骤中，根据AT的状态，源AN可以重建存在的HRPD会话，或如果需要则发起新的HRPD会话；如果没有空口信令，则该步可以为空。

至此，本实施例中跨AN空闲态寻呼的全过程结束。由上述过程可以看出，在CDMA2000系统中进行跨AN的空闲态寻呼时，与实施例一不同的是，若源AN接收到AT的寻呼响应，则直接向其他目标AN发送事件通知消息，通知它们AT已响应寻呼。在AT响应寻呼后，AT与源AN间建立会话的过程与现有技术相同。这样，不会影响现有技术的流程，同时节省了AN和空口资源。

上面介绍了本实施例中跨AN的空闲态寻呼的具体过程，本实施例中提供的跨AN空闲态寻呼的接入设备和系统的结构与实施例一中图10所示的接入设备和系统组成相同。但系统内部各模块间的信令传输有所不同。

在图10所示的系统中，源AN 1020、目标AN1 1010和目标AN2 1030间最初发起向AT 1000的寻呼所涉及的模块功能与实施例一中的相同，这里就不再赘述。

假定AT 1000向源AN 1020中的接入终端寻呼模块1021发送寻呼响应；源AN 1020中的接入终端寻呼模块1021接收到该寻呼响应后，即将AT已响应寻呼的消息发送给AN间寻呼模块1022；AN间寻呼模块1022分别向目标AN1 1010和目标AN2 1030的AN间寻呼模块1012和1032发送事件通知消息，通知目标AN1 1010和目标AN2 1030，AT 1000已响应寻呼。

目标AN1 1010中的AN间寻呼模块1012接收到源AN 1020发送的事件通知消息后，向源AN 1020发送事件通知应答，并通知接入终端寻呼模块1011停止寻呼AT 1000。同理，目标AN2 1030也停止寻呼AT 1000。

关于源AN 1020和AT 1000间建立会话的模块与现有技术相同，这里也不再赘述。

在本实施例中，假定共有三个AN对AT发起寻呼，当然在实际应用中，可能存在更多或更少的AN对AT发起寻呼，只要是源AN接收到AT的寻呼响应，均可以按照本实施例中的方式实施本发明。

由本实施例中的实施方式可见，本发明在CDMA2000系统中进行跨AN间空闲态寻呼过程中，当源AN接收到AT返回的寻呼响应时，均可以通知其他寻呼AT的目标AN，AT已响应寻呼。这样，其他AN就可以不必再寻呼AT，节省了AN和空口资源。

实施例一和实施例二介绍了本发明的方法和接入设备在CDMA2000系统中的应用的实施方式。

接下来，在实施例三和实施例四中，将以3GPP2的基本演进网络架构中的跨CAP空闲态寻呼为例，说明本发明在基本演进网络架构中的应用。

实施例三：

假定在本实施例中，源CAP、目标CAP1和目标CAP2向AT发送了寻呼，AT向其中的目标CAP1发送了寻呼响应。

图12为本发明实施例三中跨CAP的空闲态寻呼的方法流程图。如图12所示，该方法包括：

步骤1201，AT在边界扇区注册，寻呼区域覆盖属于目标CAP1和目标CAP2的扇区。这可能是由于基于距离的寻呼或子网滞回引入的。

步骤1202，源CAP判断需要通过源CAP，目标CAP1以及目标CAP2寻呼AT。源CAP发送寻呼请求消息page request到目标CAP1和目标CAP2。寻呼请求消息包括寻呼和表明通过前向控制信道发送到AT的寻呼信息。

步骤1203，源CAP、目标CAP1和目标CAP2发送寻呼到AT。

步骤1204，发起会话建立；

本步骤中，当AT接收到寻呼消息之后，AT请求建立连接；假定目标CAP1接收到AT的请求，目标CAP1发起会话建立。

步骤1205，目标CAP1发送Paging Response消息到源CAP；

本步骤中，当目标CAP1接收到AT的寻呼响应后，利用对步骤1202中寻呼请求消息的响应-Paging Response消息，携带通知发送给源CAP，AT已响应寻呼；在Paging Response消息中，可以携带AT发送的寻呼响应，或者携带经过目标CAP1处理后的寻呼响应的内容信息。

步骤1206，当从目标CAP1接收到Paging Response消息后，源CAP响应Paging Response Ack消息；

本步骤中，源CAP接收到目标CAP1发送的Paging Response消息后，即停止对AT的寻呼。

步骤1205～1206可以发生在目标CAP1检测到AT在其覆盖范围内之后的任何时刻。

步骤1207，源CAP向目标CAP2发送Event Notification消息；

本步骤中，Event Notification消息表示目标CAP2可以停止对当前AT的寻呼；本步骤可以发生在步骤1205之后的任何时刻。

步骤1208，目标CAP2响应Event Notification Ack消息；

本步骤中，目标CAP2接收到源CAP1发送的事件通知消息后，即可以停止对AT的寻呼。

步骤1209，目标CAP1和源CAP进行上下文转移过程；

本步骤可以发生在步骤1204之后的任何时刻。

步骤1210，目标CAP1和NMA之间进行代理移动IP注册过程；

本步骤为可选步骤，可以发生在步骤1209之后的任何时刻；当本网络中不包括NMA时，则不需要执行本步骤。

步骤1211，AT和目标CAP1之间完成会话的建立；

本步骤中，根据AT的状态，目标CAP1可以重建存在的会话，或如果需要则发起新的会话。如果没有空口信令，则该步可以为空。

至此，本实施例中跨CAP的空闲态寻呼的全过程结束。由上述过程可以看出，在空闲态寻呼时，若目标CAP接收到AT的寻呼响应，则在本实施例中目标CAP通知其他CAP的过程与实施例一中所示的处理过程相同，只是涉及到的接入设备不同。在AT响应寻呼后，CAP与目标CAP间重新建立会话和拆除原有连接关系的过程与实施例一有所不同。但都能实现节省接入设备和空口资源的目的。

上面介绍了本实施例中跨CAP的空闲态寻呼的具体过程，本实施例还提供了用于实现跨CAP空闲态寻呼的接入设备，即CAP。图13即为本发明实施例中跨CAP空闲态寻呼的接入设备和系统的具体结构图。

如图13所示，该系统包括：AT1300、目标CAP1 1310、源CAP 1320和目标CAP2 1330。其中，目标CAP1 1310包括接入终端寻呼模块1311和CAP间寻呼模块1312，源CAP 1320包括接入终端寻呼模块1321、CAP间寻呼模块1322和策略判决模块1323，目标CAP2 1330包括接入终端寻呼模块1331和CAP间寻呼模块1332。

本系统中的目标CAP1 1310、源CAP 1320和目标CAP21330即为图5中所示接入设备的具体化。其中的CAP间寻呼模块即为图5中所示设备间寻呼模块的具体化。

在该系统中，AT 1300在边界扇区注册，寻呼区域覆盖属于目标CAP1和目标CAP2的扇区。源CAP 1320中的策略判决模块1323根据一定的策略判定通过目标CAP1和目标CAP2来寻呼AT，即向CAP间寻呼模块1322发送消息；CAP间寻呼模块1322接收到策略判决模块1323发送的消息后，即分别向目标CAP1 1310和目标CAP2 1330的CAP间寻呼模块1312和1332发起CAP间寻呼，并通知接入终端寻呼模块1321向AT 1300发送寻呼。

目标CAP1 1310中的CAP间寻呼模块1312接收到源CAP 1320发送的寻呼请求消息后，通知接入终端寻呼模块1311向AT 1300发送寻呼。同理，目标CAP2 1330也通过接入终端寻呼模块1331向AT 1300发送寻呼。

假定AT 1300向目标CAP1发送寻呼响应，目标CAP1中的接入终端寻呼模块1311接收到该寻呼响应后，即将该寻呼响应发送给CAP间寻呼模块1312，CAP间寻呼模块1312将AT已响应寻呼的寻呼请求的响应消息发送给源CAP 1320中的CAP间寻呼模块1322。在发送的寻呼请求的响应消息中，如有必要可以携带AT发送的寻呼响应或经过处理后的寻呼响应的内容。

在源CAP 1320中，CAP间寻呼模块1322，用于接收目标CAP1 1310发送的寻呼请求的响应消息，向目标CAP1 1310中的CAP间模块1312返回寻呼响应应答，并通知接入终端寻呼模块1321，AT 1300已响应寻呼；还用于向目标CAP2 1330发送接入终端已响应寻呼的事件通知消息；接入终端寻呼模块1321，接收到CAP间寻呼模块1322发送的通知后，即停止对AT 1300的寻呼。

在目标CAP2 1330中，CAP间寻呼模块1332，用于在接收源CAP 1320发送的事件通知消息后，向源CAP 1320中的CAP间寻呼模块1322返回事件通知应答，并通知接入终端寻呼模块1331停止寻呼AT 1300或进行其他相应的处理，如减少寻呼次数等。

上述即为基于本实施例中基于本发明的接入设备的跨CAP间空闲态寻呼的系统结构。

在本实施例中，假定共有三个CAP对AT发起寻呼，当然在实际应用中，可能存在更多或更少的CAP对AT发起寻呼，只要是某个目标CAP接收到AT的寻呼响应，均可以按照本实施例中的方式实施本发明。具体在两个CAP与三个以上CAP寻呼AT的情况，与实施例一中的方式相同，只是涉及到的接入设备不同，这里就不再赘述。

由本实施例中的实施方式可见，本发明在3GPP2的基本演进网络架构中进行跨CAP间空闲态寻呼过程中，当任意一个目标CAP接收到AT返回的寻呼响应时，均可以通知源CAP，AT已响应寻呼，再由源CAP通知其他寻呼AT的目标CAP，AT已响应寻呼。这样，其他CAP就可以不必再寻呼AT，节省了CAP和空口资源。尤其当网络中寻呼AT的CAP数目很大的情况下，可以极大地节省CAP和空口资源。

实施例四：

假定在本实施例中，源CAP、目标CAP1和目标CAP2向AT发送了寻呼，AT向其中的源CAP发送了寻呼响应。

图14为本发明实施例四中跨CAP的空闲态寻呼的方法流程图。如图14所示，该方法包括：

步骤1401～1403，AT注册到边界扇区后，源CAP通知目标CAP1和目标CAP2共同寻呼AT；

可以看出，本实施例中的步骤1401～1403与图12中步骤1201～1203的操作相同，这里就不再详细描述。

步骤1404，发起会话建立；

本步骤中，当AT接收到寻呼消息之后，AT请求建立连接；假定源CAP接收到AT的请求，源CAP发起会话建立。

步骤1405，源CAP向目标CAP1和目标CAP2发送Event Notification消息；

本步骤中，Event Notification消息表示目标CAP1和目标CAP2可以停止对当前AT的寻呼；当然在实际应用中，还可以定义该消息表示可以进行诸如减少寻呼次数等其他相应的处理。

步骤1406，目标CAP1和目标CAP2响应Event Notification Ack消息。

步骤1405～1406可以发生在源CAP检测到AT在其覆盖范围内之后的任何时刻。

步骤1407，源CAP和NMA之间进行代理移动IP注册过程。

本步骤为可选，可以发生在步骤1404之后的任何时刻；当本网络中不包括NMA时，则不需要执行本步骤。

步骤1408，AT和源CAP之间完成会话的建立；

本步骤中，如果CAP和AT之间没有空口信令，则该步骤可以为空。

至此，本实施例中跨CAP空闲态寻呼的全过程结束。由上述过程可以看出，在空闲态寻呼时，若源CAP接收到AT的寻呼响应，则在本实施例中目标CAP通知其他CAP的过程与实施例二中所示的处理过程相同，只是涉及到的接入设备不同。在AT响应寻呼后，CAP与源CAP间重新建立会话的过程与实施例一有所不同。但都能实现节省接入设备和空口资源的目的。

上面介绍了本实施例中跨CAP的空闲态寻呼的具体过程，本实施例中提供跨CAP空闲态寻呼的接入设备和系统的结构与实施例三中图13所示的接入设备和系统组成相同。但系统内部各模块间的数据传输有所不同。

在图13所示的系统中，源CAP 1320、目标CAP1 1310和目标CAP2 1330间最初发起向AT 1300的寻呼所涉及的模块功能与实施例一中的相同，这里就不再赘述。

假定AT 1300向源CAP 1320中的接入终端寻呼模块1321发送寻呼响应；源CAP 1320中的接入终端寻呼模块1321接收到该寻呼响应后，即将AT已响应寻呼的消息发送给CAP间寻呼模块1322；CAP间寻呼模块1322分别向目标CAP1 1310和目标CAP2 1330的CAP间寻呼模块1312和1332发送事件通知消息，通知目标CAP1 1310和目标CAP2 1330，AT 1300已响应寻呼。

目标CAP1 1310中的CAP间寻呼模块1312接收到源CAP 1320发送的事件通知消息后，向源CAP 1320发送事件通知应答，并通知接入终端寻呼模块1311停止寻呼AT 1300或进行其他相应的处理。同理，目标CAP2 1330也停止寻呼AT 1300或进行其他相应的处理。

在本实施例中，假定共有三个CAP对AT发起寻呼，当然在实际应用中，可能存在更多或更少的CAP对AT发起寻呼，只要是源CAP接收到AT的寻呼响应，均可以按照本实施例中的方式实施本发明。

由本实施例中的实施方式可见，本发明在3GPP2基本演进网络架构中进行跨CAP间空闲态寻呼过程中，当源CAP接收到AT返回的寻呼响应时，均可以通知其他寻呼AT的目标CAP，AT已响应寻呼。这样，其他CAP就可以不必再寻呼AT，节省了CAP和空口资源。

实施例三和实施例四介绍了本发明的方法和接入设备在3GPP2基本演进网络架构中的应用的实施方式。

在实际应用中，本发明不限于应用在CDMA2000系统和3GPP2基本演进网络架构中，凡是具有类似网络结构，出现类似问题的移动通信系统，均可以采用本发明提供的方法和接入设备。

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

Claims (17)

1.一种跨接入设备的空闲态寻呼的方法，其特征在于，当网络中有多个接入设备向接入终端发送寻呼时，任意一个接收到接入终端寻呼响应的接入设备，通知网络中寻呼接入终端的其他接入设备，接入终端已响应寻呼。

2.根据权利要求1所述的方法，其特征在于，当所述接收到接入终端寻呼响应的接入设备为接入终端的源接入设备时，源接入设备直接向寻呼接入终端的其他接入设备发送通知消息，通知它们接入终端已响应寻呼。

3.根据权利要求2所述的方法，其特征在于，所述通知消息为事件通知消息或转发的寻呼响应消息。

4.根据权利要求2所述的方法，其特征在于，所述寻呼接入终端的其他接入设备接收到源接入设备发送的通知消息后，进一步返回通知应答，并停止寻呼接入终端。

5.根据权利要求2所述的方法，其特征在于，该方法包括：

a、源接入设备根据策略决定向网络中的目标接入设备发起接入设备间寻呼，并向其发送寻呼请求消息；

b、源接入设备和接收到寻呼请求消息的目标接入设备向接入终端发送寻呼；

c、源接入设备接收到接入终端的寻呼响应，向网络中寻呼接入终端的其他目标接入设备发送事件通知消息；

d、对于网络中寻呼接入终端的其他目标接入设备，接收到事件通知消息后，向源接入设备返回事件通知应答，并停止寻呼接入终端。

6.根据权利要求1所述的方法，其特征在于，当所述接收到接入终端寻呼响应的接入设备为接入终端的目标接入设备时，

目标接入设备向接入终端的源接入设备发送寻呼请求的响应消息，通知源接入设备接入终端已响应寻呼；

源接入设备接收到该寻呼请求的响应消息后，向网络中寻呼接入终端的其他目标接入设备发送通知消息，通知它们接入终端已响应寻呼。

7.根据权利要求6所述的方法，其特征在于，所述寻呼请求的响应消息中携带：接入终端发送的寻呼响应或经过目标接入设备处理后的寻呼响应内容。

8.根据权利要求6所述的方法，其特征在于，所述通知消息为事件通知消息或转发的寻呼响应。

9.根据权利要求6所述的方法，其特征在于，所述源接入设备接收到目标接入设备发送的寻呼响应后，停止寻呼接入终端；

所述寻呼接入终端的其他目标接入设备接收到源接入设备发送的事件通知消息后，进一步向源接入设备返回通知应答，并停止寻呼接入终端。

10.根据权利要求6所述的方法，其特征在于，该方法包括：

a1、源接入设备根据策略决定向网络中的某些接入设备发起接入设备间寻呼，并向其发送寻呼请求消息；

b1、源接入设备和接收到寻呼请求消息的目标接入设备向接入终端发送寻呼；

c1、某个目标接入设备接收到接入终端的寻呼响应，并向源接入设备发送寻呼请求的响应消息，源接入设备接收到寻呼请求的响应消息后，停止寻呼接入终端；

d1、对于网络中其他未接收到寻呼响应的目标接入设备，源接入设备向其发送事件通知消息；

e1、网络中其他未接收到寻呼响应的目标接入设备，向源接入设备返回事件通知应答，并停止寻呼接入终端。

11.一种实现跨接入设备的空闲态寻呼的接入设备，其特征在于，该接入设备至少包括接入终端寻呼模块和接入设备间寻呼模块；

所述接入终端寻呼模块，用于向接入终端发送寻呼，并将接收到的接入终端返回的寻呼响应发送给所述接入设备间寻呼模块；

所述接入设备间寻呼模块，用于接收所述接入终端寻呼模块发送的寻呼响应，并将接入终端已接收到寻呼的通知消息发送出去。

12.根据权利要求11所述的接入设备，其特征在于，所述接入设备为码分多址接入CDMA2000系统中的接入网设备AN或基本演进网络中的控制接入点CAP。

13.一种跨接入设备的空闲态寻呼的系统，其特征在于，该系统包括：接入终端和多个接入设备，其中，

所述接入终端，用于在接收到某个接入设备的寻呼后，向该接入设备返回寻呼响应；

接收到所述接入终端寻呼响应的接入设备，用于向所述接入终端发送寻呼，当接收到所述接入终端返回的寻呼响应后，通知寻呼接入终端的其他接入设备，所述接入终端已响应寻呼；

未接收到所述接入终端寻呼响应的接入设备，用于向所述接入终端发送寻呼，并接收已接收到所述接入终端寻呼响应的接入设备发送的通知。

14.根据权利要求13所述的系统，其特征在于，所述多个接入设备为源接入设备和一个目标接入设备；

所述接入终端，向所述目标接入设备发送寻呼响应；

所述目标接入设备，用于通知所述源接入设备，接入终端已收到寻呼；

所述源接入设备，用于接收所述目标接入设备发送的通知，并停止寻呼接入终端。

15.根据权利要求13所述的系统，其特征在于，所述多个接入设备为源接入设备和至少两个目标接入设备；

所述接入终端，向所述目标接入设备中的某一个发送寻呼响应；

接收到寻呼响应的目标接入设备，用于通知所述源接入设备，接入终端已收到寻呼；

所述源接入设备，用于接收所述接收到寻呼响应的目标接入设备发送的通知，并停止寻呼接入终端，还用于向未接收到寻呼响应的目标接入设备发送事件通知消息，通知它们所述接入终端已响应呼叫，并接收未接收到寻呼响应的目标接入设备返回的事件通知应答；

未接收到寻呼响应的目标接入设备，用于接收所述源接入设备发送的事件通知消息，向所述源接入设备返回事件通知应答，并停止寻呼接入终端。

16.根据权利要求13所述的系统，其特征在于，所述多个接入设备为源接入设备和至少一个目标接入设备；

所述接入终端，向所述源接入设备发送寻呼响应；

所述源接入设备，用于接收所述接入终端发送的寻呼响应，向寻呼接入终端的所述目标接入设备发送事件通知消息，通知它们所述接入终端已响应寻呼，并接收所述目标接入设备返回的事件通知应答；

所述目标接入设备，用于接收所述源接入设备发送的事件通知消息，向所述源接入设备返回事件通知应答，并停止寻呼接入终端。

17.根据权利要求13至16中任意一项所述的系统，其特征在于，所述系统为CDMA2000系统或基本演进网络架构。

Images