专利名称：用于在无线通信系统中进行有效寻呼的方法和装置的制作方法
技术领域：
本发明一般涉及通信，并且更具体地，涉及用于在无线通信系统 中进行有效寻呼和监测寻呼消息的方法和装置。
背景技术：
通信系统被广泛地部署来提供比如语音、分组数据等等的各种通 信服务。这些系统可以是时分多址系统，频分多址系统和/或码分多 址系统，其能够通过共享可用的系统资源来同时支持与多个用户的通
信。此种多址系统的实例包括码分多址(CDMA)系统，多载波CDMA (MC-CDMA)，宽带CDMA (W-CDMA)，高速下行链路分组接入 (HSDPA)，时分多址(TDMA)系统，频分多址(FDMA)系统，
以及正交频分多址(OFDMA)系统。
因此，在本领域中，需要一种用于在无线通信系统中进行有效寻
呼和监测寻呼消息的方法和装置。
发明内容
所公开的实施例提供了用于监测寻呼信道的方法和装置。 一方 面，用于监测寻呼信道的方法包括在安排的寻呼时隙针对寻呼消息来 监测寻呼信道，确定错误在给定的寻呼时隙已经发生，以及在至少一 个安排的重寻呼时隙针对重寻呼消息来监测寻呼信道，其中，该重寻 呼时隙发生在给定的寻呼时隙之后但在下一安排的寻呼时隙之前。另 一方面，用于监测寻呼信道的方法包括在安排的寻呼时隙针对寻呼消 息来监测多个寻呼信道中的第一寻呼信道，确定错误在给定的寻呼时 隙已经发生，以及针对该寻呼消息监测所述多个寻呼信道中的至少第 二寻呼信道。
从下述结合附图进行的详细的描述中，本发明的特征和特点将会 变得更加明显，在附图中，在整个说明书中，相似的参考标记相应地 一致，而且其中
图1示出了用于在通信网络中监测寻呼信道的一个实施例；
图2示出了一个寻呼过程的流程图3示出了多信道寻呼的一个方案；
图4示出了多信道寻呼的另一个方案；以及
图5示出了接入点和接入终端的方块图。
详细描述
单词"示例性的"在这里被用来表示"用作一个例子、示例和图 例"。这里被描述为"示例性"的任何实施例不必被解释为相比其他 实施例是优选的或具有优势。
"接入终端"指的是提供到用户的语音和/或数据连接的设备。接 入终端可以连接到例如膝上型电脑或桌上型电脑的计算设备，或者它 可以是例如个人数字助理的自包含式设备。接入终端也可以称为用户 单元，移动基站，移动站，远程站，远程终端，用户终端，用户代理 或用户装备。接入终端可以是用户站，无线设备，蜂窝电话，PCS电 话，无绳电话，会话发起协议(SIP)电话，无线本地环路(WILL) 站，个人数字助理(PDA),具有无线连接能力的手持设备，或与无 线调制解调器连接的其它处理设备。
"接入点"指的是经由空中接口通过一个或多个扇区与接入终端 通信的接入网络中的设备。接入点通过将接收到的空中接口帧转换成 IP分组来用作接入终端和接入网的其它部分之间的路由器，其中接入 网可以包括IP网络。接入点还协调对空中接口的属性的管理。
图1示出了用于在无线通信网络中监测寻呼信道的一个实施例。 在一个实施例中，空闲的接入终端(AT)按照分隙寻呼模式进行操 作，也就是，AT以不变的间隔监测寻呼信道，并且返回到睡眠模式 以节省电池功率。在AT成功地接收到寻呼信道并且在寻呼信道上观
测到寻呼的情况下，如102所示，AT进行连接到该系统的接入尝试
(即，从空闲状态转换到连接状态)。在连接模式下接收到数据后， AT可以重进入睡眠模式，如104所示。然而，如果AT成功地接收 到寻呼信道但是在寻呼信道上没有观测到寻呼，即，接入网(AN) 没有设置寻呼，则AT可以重进入睡眠模式，如106所示。
术语
API:接入点，AT当前正从该接入点监测寻呼。
AP2:接入点，AT可以移动到该接入点。
AAP:锚点AP， AT的会话所位于的、以及产生寻呼的AP。 通过骨干网络将寻呼递送到API和AP2，并且API和AP2在其中 AT被获知来监测寻呼信道的时隙中通过空中传递来发送寻呼。
AN:包括所有AP和骨干基础设施的系统。
寻呼时隙AT唤醒来监测寻呼信道时的时间场合。这些时间 场合可为AT和AN获知。
重寻呼当AN没有接收到对它之前发送的寻呼的答复时再次 发送的寻呼。
寻呼错误AT处的事件，AT通过该事件来确定不能读取寻呼 信道，例如，寻呼信道上的CRC错误，或一些其它错误。
基于区域的寻呼每个AP都告知它的寻呼区域ID。从包括某 些AP的寻呼区域中的所有AP处发送寻呼。寻呼区域是通过网络来 界定的，并且可以或不可以是分离的。AT在每次进入新的寻呼区域 (如通过区域ID来识别)时注册。
基于距离的注册每个AP都告知它的就纬度和经度而言的位 置，以及还告知它的注册半径。如果AT希望从AP (比方说API) 接收到寻呼，其中该AP距离AT最后注册的AP (比方说APO)比注 册距离更远。AN向AT保证，寻呼将从在最后注册AP的注册距离 内的所有AP发送。
在一个实施例中，由于错误而导致AT可能观察不到AN所设置 的寻呼。寻呼错误可能是由于若干原因导致的，其包括
AT移动到新的AP:如果AT从API移动到AP2而同时AT处
于空闲状态，那么在AT唤醒来监测寻呼信道之后，AT可能在APl 上具有不足的强度，并且可能还没有获得AP2的参数，该参数允许 AT读取AP2上的寻呼。在这种情况下，在AT唤醒并发现它己经移 动到AP2时，AT可能不得不在能识别出AP2的寻呼时隙之前搜索 AP2的定时信息。这可能会引起延迟，在该延迟期间， 一些安排的寻 呼可能会错过。当AP1和AP2不是时间同步时，由于在AP之间的 定时偏移，AP2可能会比AT预想的更早地发送寻呼，上述问题更加 严重，从而将会导致错过更多的寻呼。
衰落AT在寻呼时隙中可能在自AP开始的前向链路上经历 衰落。
寻呼错误一般会导致一个或多个下述问题
等待时间错过的寻呼导致AT的等待时间。AT可能不得不 等待到下一个寻呼时隙，对低等待时间需求的应用(例如一键通型应 用)来说，这可能会引起不期望的延迟。
网络负载如果AT没有回复寻呼，那么AN就可能假定AT 在寻呼区域之外，并且可能在更大的区域进行重寻呼。因此，当寻呼 错误事件发生时，AN就可能在没有必要的大区域中寻呼。
在一个实施例中，除了及时定期发生的寻呼时隙外，如上面所讨 论的，AT和AN定义了一个或多个快速重寻呼时隙，每个重寻呼时 隙在安排的寻呼时隙之后一个时间周期发生。例如，如图1中所示， 安排的寻呼时隙120彼此间隔5秒，而每个快速重寻呼时隙130可以 为每个安排的寻呼时隙之后0.5秒钟。在一个实施例中，多于一个的 重寻呼时隙可以在寻呼时隙120之后但在随后的安排的寻呼时隙之 前发生。
监测过程-重寻呼
如果AT在安排的寻呼时隙经历寻呼失败，如图108所示，那 么AT可以在至少一个随后的重寻呼时隙唤醒(如110所示)来监测 重寻呼消息。如果AT仍然不能读取重寻呼消息，那么AT可能顺序
地或以其他的方式监测更多的重寻呼时隙，直到它成功地监测到重寻
呼消息。如果AT在所有的重寻呼时隙都经历寻呼失败，那么AT唤 醒来读取下一个安排的寻呼时隙。然而，如果AT在寻呼时隙成功地 监测到寻呼信道，那么AT就不会为了重寻呼时隙而被唤醒。
寻呼过程-重寻呼
图2示出了寻呼接入终端的流程图。为了传输到目标AT (如206 所示)，AAP向API (如202所示)和/或向AP2 (如204所示)发送 寻呼请求。如果AAP在预定时间周期(如210所示)内例如由于寻 呼错误208而没有接收到来自AT的、对它在寻呼时隙发送的寻呼请 求的响应，则AAP向API和/或向AP2发送重寻呼请求212。然后 API和/或AP2可以在至少一个随后的重寻呼时隙中重寻呼AT，如 214所示。如果AAP在该时间周期210内接收到对寻呼请求的响应， 则AAP就不会发出重寻呼请求。
监测过程-有效集
在一个实施例中，AT监测来自多于一个的小区/扇区的寻呼，例 如以减少错过寻呼消息的几率。AT可以在有效集中维护这种小区/扇 区。
同步情形图3示出了一个实施例，其中，有效集中的AP上的 寻呼时隙同时发生；因此，AT的监测过程与监测仅仅一个AP的情 形是相同的，如上面结合图1和图2所讨论的。AT在安排的寻呼时 隙唤醒并且尝试解调寻呼信道，并且如果AT不能成功地监测寻呼消 息，则它尝试从有效集中的至少一个其它AP解调该寻呼信道。在一 个实施例中，如果下面的条件都是真的，那么AT就认为寻呼被成功 接收-
成功地对来自至少一个AP的寻呼信道进行解调(例如，采用 CRC匹配)，以及
被成功解码的寻呼信 12
不同的吋间发生时的一个实施例。AT首先在AP1的寻呼时隙期间唤 醒，如402所示(具有最早的定时偏移量)。如果成功地对寻呼信道 进行解码，则它等待直到下一个安排的寻呼信道404，并且对于当前 的寻呼吋隙，不从有效集中的其它AP中读取寻呼。然而，如果AT 不能成功地对API进行解码，那么AT就在AP2的寻呼时隙唤醒， 如406所示。根据需要，在监测多个AP的情况下，这个过程可以继 续；由此增加有效解码寻呼信道的几率。在一个实施例中，可以将监 测重寻呼消息和监测多于一个的寻呼信道相组合。
维护有效集的一个实施例包括在一些或所有信道上发送对应目 标AT的寻呼的AN。因而，如果该系统正在使用基于区域的寻呼， 那么AT可以将有效集限制到它当前所在的寻呼区域内的AP。如果 该系统使用基于距离的寻呼，则AT可以按照有效集中的所有AP处 于先前注册位置的注册距离内的方式来进行注册。
图5示出了用于实现结合图1到图4所讨论的公开的实施例的接 入点110x和接入终端120x的方块图。对于反向链路，在终端120x， 发射(TX)数据处理器514从数据缓冲器512接收业务数据，根据 选择的编码和调制方案处理(例如编码，交织，和符号映射)每个数 据分组，并且提供数据符号。数据符号是数据的调制符号，而导频符 号是导频(它是事先知道的)的调制符号。调制器516接收数据符号， 导频符号和用于反向链路的可能的信令，执行OFDM调制和/或由系 统指定的其它处理，并且提供输出码片流。发射机单元(TMTR) 518 处理(例如转换成模拟的，滤波，放大和上变频)输出码片流，并且 生成从天线520发射出的调制信号。
在接入点110x，由终端120x和与接入点110x通信的其它终端 发射的调制信号由天线552接收。接收机单元(RCVR) 554处理(例 如，调整和数字化)从天线552接收的信号并且提供接收到的采样。 解调器(Demod) 556处理(例如，解调和检测)接收到的采样并且 提供检测到的数据符号，该检测到的数据符号是由终端向接入点110x 发射的数据符号的噪声估计。接收(RX)数据处理器558为每个终 端处理(例如，符号解映射，解交织，解码)所检测到的数据符号并
且为相应的终端提供解码数据。
对于前向链路，在接入点110x，业务数据由TX数据处理器560 进行处理以生成数据符号。调制器562接收数据符号，导频符号，和 前向链路的信令，执行OFDM调制和/或其它相关的处理，以及提供 输出码片流，这些码片流由发射机单元564进一步调整并且从天线 552发射出。前向链路的信令可以包括由控制器570为所有终端生成 的、在反向链路上发射到接入点110x的功率控制命令。在终端120x， 接入点110x所发射的调制信号由天线520接收，由接收单元522进 行调整和数字化，并且由解调器524进行处理以获得检测到的数据符 号。RX数据处理器526处理检测到的数据符号并且为终端提供解码 数据并且提供前向信令。控制器530接收功率控制命令，并且控制到 接入点110x的数据传输和反向链路上的发射功率。控制器530和570 分别导引终端120x和接入点110x的操作。存储单元532和572分别 存储由控制器530和570使用的程序代码和数据，以实现所公开的实 施例。
所公开的实施例可以应用到下面技术中的任-"个或其组合码分 多址(CDMA)系统，多载波CDMA (MC-CDMA)，宽带CDMA
(W-CDMA)，高速下行分组接入(HSDPA)，时分多址(TDMA) 系统，频分多址(FDMA)系统，以及正交频分多址(OFDMA)系 统。
在这里描述的信令发射技术可以通过多种方式实施。例如，这些 技术可以用硬件，软件或者它们的组合来实现。对于硬件实现，用来 处理(例如，压縮和编码)信令的处理单元可以在以下设备内实现 一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号 处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、 处理器、控制器、微控制器、微处理器、设计成执行这里所述功能的 其它电子单元、或者它们的组合。用来解码和解压縮信令的处理单元 也可以用一个或多个ASIC， DSP等等来实现。
对于软件实现而言，所述信令发射技术可以用执行这里所述功能 的模块(例如过程、功能等等)来实现。软件代码可以被存储在存储器单元(例如，在图5中的存储单元532或572)中，并可由处理器(例如， 控制器530或570)执行。存储器单元可以在处理器内实现或在处理器 外实现。 _
提供所述公开的实施例的上述描述可使得本领域的技术人员能 够实现或者使用本发明。对于本领域的技术人员来说，这些实施例的 各种修改是显而易见的，并且这里定义的总体原理也可以在不脱离本 发明的主旨或范围的基础上应用于其他实施例。因此，本发明并不限 于这里示出的实施例，而是与符合这里公开的原理和新颖特征的最广 范围相一致。
权利要求
1、一种用于监测寻呼信道的方法，所述方法包括在安排的寻呼时隙针对寻呼消息来监测寻呼信道；确定错误在给定的寻呼时隙已经发生；并且在至少一个安排的重寻呼时隙针对重寻呼消息来监测寻呼信道，其中，所述至少一个重寻呼时隙发生在所述给定的寻呼时隙之后但在下一个安排的寻呼时隙之前。
2、 根据权利要求1所述的方法，其中，所述重寻呼消息是基于 检测到所述错误而传送的。
3、 根据权利要求2所述的方法，其中，所述错误表明在所述给 定的寻呼时隙内没有成功地接收到所述寻呼消息。
4、 一种用于寻呼目标接入终端(AT)的方法，所述方法包括 在安排的寻呼时隙发送要发到目标接入终端(AT)的寻呼消息；以及如果在给定的寻呼时隙检测到错误，那么在安排的重寻呼时隙发 送要发到所述目标AT的重寻呼消息，所述重寻呼时隙发生在所述给 定的寻呼时隙之后但在下一个安排的寻呼时隙之前。
5、 根据权利要求4所述的方法，其中，在没有接收到所述AT 已经成功地监测到所述寻呼消息的响应时，所述错误被检测到。
6、 一种用于监测寻呼信道的方法，所述方法包括 在安排的寻呼时隙针对寻呼消息监测多个寻呼信道中的第一寻呼信道；确定错误在给定的寻呼时隙已经发生；并且 针对所述寻呼消息监测所述多个寻呼信道中的至少第二寻呼信道。
7、 根据权利要求6所述的方法，其中，所述多个寻呼信道是时 间同步的。
8、 根据权利要求6所述的方法，其中，所述多个寻呼信道不是 时间同步的，并且寻呼消息的下一次监测在下一个安排的寻呼时隙发 生在所述第二信道上。
9、 一种计算机可读介质，包含用于实现监测寻呼信道的方法的 模块，所述方法包括在安排的寻呼时隙针对寻呼消息监测寻呼信道；确定错误在给定的寻呼时隙已经发生；并且在至少一个安排的重寻呼时隙针对重寻呼消息监测所述寻呼信 道，所述至少一个重寻呼时隙发生在所述给定的寻呼时隙之后但在下 一个安排的寻呼时隙之前。
10、 根据权利要求9所述的介质，其中，所述重寻呼消息是基于 检测到所述错误而传送的。
11、 根据权利要求10所述的介质，其中，所述错误表明在所述 给定的寻呼时隙没有成功地接收到所述寻呼消息。
12、 一种计算机可读介质，包含用于实现寻呼目标接入终端(AT) 的方法的模块，所述方法包括在安排的寻呼时隙发送要发到目标接入终端(AT)的寻呼消息；并且如果在给定的寻呼时隙检测到错误，那么在安排的重寻呼时隙发 送要发到所述目标AT的重寻呼消息，所述重寻呼时隙发生在所述给 定的寻呼时隙之后但在下一个安排的寻呼时隙之前。
13、 根据权利要求12所述的介质，其中，在没有接收到AT己 经成功地监测到所述寻呼消息的响应时，所述错误被检测到。
14、 一种计算机可读介质，包含用于实现监测寻呼信道的方法的 模块，所述方法包括在安排的寻呼时隙针对寻呼消息监测多个寻呼信道中的第一寻 呼信道；确定错误在给定的寻呼时隙已经发生；并且 针对所述寻呼消息监测所述多个寻呼信道中的至少第二寻呼信道。
15、 根据权利要求14所述的介质，其中，所述多个寻呼信道是 时间同步的。
16、 根据权利要求14所述的介质，其中，所述多个寻呼信道不 是时间同步的，并且寻呼消息的下一次监测在下一个安排的寻呼时隙 发生在所述第二信道上。
17、 一种用于监测寻呼信道的设备，包括 用于在安排的寻呼时隙针对寻呼消息监测寻呼信道的装置； 用于确定错误在给定的寻呼时隙已经发生的装置；以及 用于在至少一个安排的重寻呼时隙针对重寻呼消息监测所述寻呼信道的装置，所述至少一个重寻呼时隙发生在所述给定的寻呼时隙 之后但在下一个安排的寻呼时隙之前。
18、 根据权利要求17所述的设备，其中，所述重寻呼消息是基 于检测到所述错误而传送的。
19、 根据权利要求18所述的设备，其中，所述错误表明在所述给定的寻呼时隙没有成功地接收到所述寻呼消息。
20、 一种用于寻呼目标接入终端(AT)的设备，包括 用于在安排的寻呼时隙发送要发到目标接入终端(AT)的寻呼消息的装置；以及用于如果在给定的寻呼时隙检测到错误，那么在安排的重寻呼时 隙发送要发到所述目标AT的重寻呼消息的装置，所述重寻呼时隙发 生在所述给定的寻呼时隙之后但在下一个安排的寻呼时隙之前。
21、 根据权利要求20所述的装置，其中，在没有接收到所述AT 已经成功地监测到所述寻呼消息的响应时，所述错误被检测到。
22、 一种用于监测寻呼信道的设备，包括-用于在安排的寻呼时隙针对寻呼消息监测多个寻呼信道中的第一寻呼信道的装置；用于确定错误在给定的寻呼时隙己经发生的装置；以及 用于针对所述寻呼消息监测所述多个寻呼信道中的至少第二寻呼信道的装置。
23、 根据权利要求22所述的设备，其中，所述多个寻呼信道是 时间同步的。
24、 根据权利要求22所述的设备，其中，所述多个寻呼信道不 是时间同步的，寻呼消息的下一次监测在下一个安排的寻呼时隙发生 在所述第二信道上。
25、 至少一个处理器，被配置来实现监测寻呼信道的方法，所述 方法包括在安排的寻呼时隙针对寻呼消息监测寻呼信道； 确定错误在给定的寻呼时隙已经发生；并且 在至少一个安排的重寻呼时隙针对重寻呼消息监测所述寻呼信 道，所述至少一个重寻呼时隙发生在所述给定的寻呼时隙之后但在下 一个安排的寻呼时隙之前。
26、 根据权利要求25所述的处理器，其中，所述重寻呼消息是 基于检测到所述错误而传送的。
27、 根据权利要求26所述的处理器，其中，所述错误表明在所 述给定的寻呼时隙没有成功地接收到所述寻呼消息。
28、 至少一个处理器，被配置来实现寻呼目标接入终端(AT) 的方法，所述方法包括在安排的寻呼时隙发送要发到目标接入终端(AT)的寻呼消息；以及如果在给定的寻呼时隙检测到错误，那么在安排的重寻呼时隙发 送要发到所述目标AT的重寻呼消息，所述重寻呼时隙发生在所述给 定的寻呼时隙之后但在下一个安排的寻呼时隙之前。
29、 根据权利要求28所述的处理器，其中，在没有接收到所述 AT已经成功地监测到所述寻呼消息的响应时，所述错误被检测到。
30、 至少一个处理器，被配置来实现监测寻呼信道的方法，所述 方法包括在安排的寻呼时隙针对寻呼消息监测多个寻呼信道中的第一寻 呼信道；确定错误在给定的寻呼时隙己经发生；并且 针对所述寻呼消息至少监测所述多个寻呼信道中的第二寻呼信道。
31、 根据权利要求30所述的处理器，其中，所述多个寻呼信道 是时间同步的。
32、根据权利要求30所述的处理器，其中，所述多个寻呼信道 不是时间同步的，寻呼消息的下一次监测在下一个安排的寻呼时隙发 生在所述第二信道上。
全文摘要
本公开的实施例提供了用于监测寻呼信道的方法和系统。一方面，用于监测寻呼信道的方法包括在安排的寻呼时隙针对寻呼消息监测寻呼信道，确定错误在给定的寻呼时隙已经发生，并且在至少一个安排的重寻呼时隙针对重寻呼消息监测寻呼信道，所述至少一个重寻呼时隙发生在所述给定的寻呼时隙之后但在下一个安排的寻呼时隙之前。另一方面，用于监测寻呼信道的方法包括在安排的寻呼时隙针对寻呼消息监测多个寻呼信道中的第一寻呼信道，确定错误在给定的寻呼时隙已经发生，以及针对所述寻呼消息监测所述多个寻呼信道中的第二寻呼信道。
文档编号H04W68/02GK101107873SQ200580047159
公开日2008年1月16日 申请日期2005年12月22日 优先权日2004年12月22日
发明者F·乌卢珀纳尔, N·J·帕雷柯, N·贾因, R·普拉卡什 申请人:高通股份有限公司