移动通信系统中的在线通知 背景
本发明涉及移动通信系统，具体地涉及提供给移动通信系统用户的业务，更具体地涉及向移动通信系统用户通知系统中其它用户状态的技术。
随着无线(移动)通信系统用户基数的持续增长，这种系统可以提供的业务数量和类型也在增长。移动通信设备不再限于只提供传统的语音通信业务。相反，随着个人数字助理(PDA)以及其它类型的智能移动终端这样的设备引入市场，寻呼、电子邮件、普通数据传输、聊天程序以及通用目的浏览器这样的业务变得越来越平常。
目前移动通信环境中存在的一个问题是呼叫方不能知道所要的电话呼叫接收方是否将他或她的电话“在线”(即，打开或在范围内)，以使所要的接收方能够应答/接收呼叫。类似的问题针对其它类型的通信也是存在的，例如短信息业务(SMS)消息。在SMS消息情况下，呼叫方目前无法知道所要地接收方现在是否在线--这样可以增加他确实阅读了所发消息的概率，或者所要的接收方现在是否离线--这样可以增加消息在(可能)很远的将来的某个时刻才会被阅读的可能性。
缺少这种信息的问题在于，无论何时一个人进行呼叫都要花几秒钟拨号，系统还需要几秒钟呼叫B-方，然后还需要几秒钟由B-方应答或者由系统通知呼叫方(“A方”)由于(例如)电话没有打开用户此时不能接通。尽管进行一次未完成的呼叫所包含的时间量首先可能是微不足道的，但是当考虑在任一给定的天内有多少次未完成的呼叫时可能会加至相当多的时间。如果呼叫方提前知道现在不能完成呼叫，那么就不会进行呼叫尝试，同时节省所费的时间用于更有成效的活动。
在有线互连网世界有有很多这种问题的解决方案。例如，称为ICQ的产品就是已知的互连网工具，在任意时刻提供谁在线的信息，并使用户能够联系这些人。但是，由于有线互连网基础设施和移动通信世界(例如，蜂窝电话环境)所建立的基础设施之间的本质差别，已知的基于有线的解决方案在无线世界是无用的。
因此，需要提供一种机制，使移动通信系统中的呼叫方提前知道所要的呼叫或其它传输的接收方目前是否能够接收预期的呼叫或其它传输。
概述
因此，本发明的一个目的是提供将与其它移动用户关联的各种状态条件通知移动用户的系统和技术。
前述的以及其它的目标在将移动通信系统中其它用户的状态通知移动通信设备的第一用户的系统及方法中实现。在发明的一个方面，这种系统及方法包括从移动通信设备向移动通信系统中的服务节点发送信号。在服务节点，确定一个列表，向其它用户表示第一用户需要知道它们的状态。然后确定列表上每个其它用户的状态，该状态从服务节点发送到移动通信设备。
在发明的另一方面，从移动通信设备到移动通信系统中服务节点的信号发送可以根据移动通信设备上电而进行。该信号还可以包括表示移动通信设备已经上电的指示，并且在服务节点确定列有第一用户的其它列表。对于每个其它列表，可以确定相应的其它用户，并向每个相应的其它用户发出通知，表示第一用户已经在线。
在发明的一个实施例中，服务节点是原籍位置寄存器。
根据发明的另一方面，状态类型可以包括如下任意一种：列表上的每个其它用户是否在线的指示；列表上的每个其它用户是否关联于电子邮件业务的指示；以及列表上的每个其它用户的位置指示。也可以表示其它状态类型。
在发明的又一方面，通过等到状态持续存在预定一段时间，然后将用户状态更新表示该状态，防止将过渡状态报告为用户状态。这种过渡态可能包括(例如)由于开车通过隧道或者由于乘坐电梯而暂时离线。
附图的简要描述
发明的目标和优势通过结合附图阅读如下详细描述将得到理解，其中：
图1a、1b和1c说明了根据发明的一个方面，从用户观点来看示范的无线在线通知业务；
图2a、2b和2c说明了根据发明的几个方面，实现无线在线通知业务的系统示范实施例的框图；以及
图3a、3b、3c、3d和3e说明了根据发明的几个方面，移动站和服务节点之间与无线在线通知有关的信令。
详细描述
现在将针对图来描述发明的各种特性，图中类似的部件用相同的参照字符标示。
现在将描述示范的无线在线通知(WOLN)技术及装置。首先参考图1a、1b和1c，它们说明了从用户观点来看的示范WOLN业务。根据发明的一个方面，用户已经建立他对其状态感兴趣的个人列表。这类列表在本揭示中将被称为“通知我”列表。所列的个人可以是呼叫、数据传输或实际上从用户发出的任何类型通信的可能的接收方。仅为了示例，这种“通知我”列表将被假设包括三个人的名字：Peter、Anna和Sarah。当然，用户可能在列表中已经预定了更多或更少的人。在操作中，用户的无线设备，例如图1a中所画的移动站(MS)101从远端服务器(图1a中没有画出)得到信息，该服务器检查预定的“通知我”列表并对所列的每个人确定他们目前是否能够响应来自用户的预期呼叫或其它传输。如果可以，这个状态就反映在MS 101的显示部分103上。
图1b和1c是在WOLN业务的不同阶段所看到的MS 101显示部分103的放大图。在图1b的例子中，MS 101的显示部分103指示名字Peter、Anna和Sarah。每个名字旁边是一个空白框，被定为表示对应名字的人目前不能响应来自用户的任何呼叫(或其它传输)。有了这个知识，用户可以节省自己试图接通这些人中任何一个所浪费的力气。
图1c描述了称为Peter的人刚刚上线(例如，打开他的移动设备的电源)的情况。根据这种情况，远端服务器向我们的用户MS 101发送这个信息，后者在显示部分103中Peter名字所关联的框中添满作为响应。现在用户知道Peter能够响应用户可能启动的任何呼叫或者其它传输。当然，代表这种信息的空白或填充框的使用只是例子，可以很容易地使用表示这种信息的其它技术(例如包括完整的文本)作为替代。
更高层次地来看WOLN应用(驻留在用户设备和远端服务器中)，它应该执行如下任务(不一定按照所示的顺序)：
1)当用户(其标识此后用全大写的名词“USER”代表)打开他的无线设备时，无线设备通知服务器USER已经在线。
2)然后服务器得到USER的“通知我”列表(这是USER以前定义的其它用户列表并保存在WOLN数据库中)中定义的每个人的当前状态(例如，“在线”或“不在线”)。这个信息被传递到USER的移动设备中。
3)服务器也可以检查它的WOLN数据库，识别包括这个USER名字的其它列表。这些其它列表中的每一个属于相应的其它用户。因此，服务器通知目前在线的每个其它用户“USER已经在线”。识别哪些其它列表包括这个USER名字的过程可以通过检查系统中的每个“通知我”列表、并确定它们中的哪些包括USER标识来动态执行。再将USER状态的改变通知被识别出来的这些列表的所有者。在另一个实施例中，动态确定向谁通知用户状态改变事件中所包括的处理实际上可以通过产生并维护一个第二类列表来减少，下文称之为“通知其它人”列表。在这样的实施例中，除了上面描述的“通知我”列表以外，每个用户都有自己的“通知其它人”列表。“通知其它人”列表的内容列出了每当特定用户状态改变时应该通知的用户列表。在上例中，USER的“通知其它人”列表包括他们自己的“通知我”列表包括USER标识的那些其它用户的标识。
4)当USER关闭他的移动设备时，这个事件的通知被发送到服务器。服务器通过检查它的WOLN数据库来响应，识别哪些其它的“通知我”列表包括这个USER的名字。(在一个实施例中，这个任务通过使用上述的USER“通知其它人”列表的内容而大大简化。)如上所述，这些其它的“通知我”列表中的每一个属于相应的其它用户。因此服务器将“USER已经离线”通知目前在线的每个其它用户。当然，当USER在线而且他预定列表中的一个人离线时，这个信息可以简单地转发到USER的移动终端，使USER可以获悉所列举的关系人的最新状态。
图2a、2b和2c是实现WOLN业务的系统示范实施例的框图。这些例子中用户的无线设备是移动站201(在图中标为MS-A)，但是可以很容易地是包括可用于WOLN应用的恰当硬件和软件(WOLN子系统203)的任何其它类型的无线设备(例如PDA)。首先参考图2a中所示的实施例，MS-A 201包括射频(RF)部分205，根据这里不必详细描述的已知技术通过空中接口209与基站(BS)207通信。BS 207通过可以是标准的E1/T1链路的脉冲编码调制(PGM)链路211依次连接到移动交换中心(MSC)213。MSC 213连接到第二PCM链路215，与服务节点通信，在这个实施例中，就是原籍位置寄存器(HLR)/WOLN数据库217的组合。(整个本描述中HLR的表示只是为了说明的目的。本领域一般技术人员会认识到任何等效设备都可以替代所示的HLR。)BS 207、PGM链路211、215以及MSC 213是本领域(例如，移动通信全球系统Global System for Mobile communication(GSM)中，这里不必详细描述)熟知的。只考虑HLR/WOLN数据库217组合中的HLR功能的话，也是熟知的，这里不必详细描述。
WOLN应用主要通过MS-A 201中WOLN子系统203、以及服务节点(在本实施例中，为HLR/WOLN数据库217的组合)的WOLN数据库部分支持。WOLN子系统203控制MS-A的显示部分103，并至/从HLR/WOLN数据库217组合的WOLN数据库部分发送并接收恰当的信令(下面更详细描述)。系统中的中间单元(例如，BS 207和MSC 213)在MS-A201和HLR/WOLN数据库217组合之间转发WOLN有关的信息，在这种程度上也支持WOLN应用。但是，这种功能对于本领域一般技术人员是很显然的，这里不再详细描述。
图2a中所示的系统允许使用HLR提供实现WOLN业务所需的所有信息(即，WOLN服务节点在HLR本身内)。但是这个实施例所提供的业务是有限的，因为它只是为同一HLR内的终端工作，通常意味着同一经营者的用户。为了在不同经营者之间提供该业务，使用另外的实施例。在图2b所示的一个选项中，服务节点219与HLR 217′分离。服务节点219包括与WOLN业务有关的所有数据和服务节点控制软件，并且可以被很多不同系统的HLR访问。因此，WOLN业务可以跨系统边界地将其它用户的状态通知用户。这个实施例中的HLR 217′存储给定用户是否具有WOLN业务有关的信息，存储的方式大体与保存用户是否具有其它业务(例如，呼叫转发)有关的信息相同。但是，用户的实际状态信息(例如，用户是否在线)以及各种列表(“通知我”和可能的“通知其它人”)存储在服务节点219中。
图2b实施例的缺陷在于服务节点219可能变成巨大的数据库。这个问题在图2c所示的另一个替代实施例中解决。这里，多个HLR/WOLN数据库217″-1…217″-n组合按照上面针对图2a的HLR/WOLN数据库组合所描述的方式工作，但是除此之外各自还连接到超级服务节点221，后者从一个HLR/WOLN数据库向那些不同的经营者传递查询和信息。这样，所有用户状态的知识可以通过多个独立的系统传播。逻辑上，这样很象全球HLR，但是需要更少的设备，而且没有需要巨大数据库的缺陷，尽管需要一些存储空间。
现在通过几个例子描述MS-A 201和服务节点(例如，图2a的HLR/WOLN数据库217组合、图2b的服务节点219、或者图2c的HLR/WOLN数据库217”组合)之间与WOLN有关的信令。在这些例子的每个中，“HLR”和“服务节点/WOLN数据库”代表逻辑功能，并因此表示为独立的实体。但是，正如已经解释过的，这两种逻辑功能可能物理上驻留在共同节点中，也可能并非如此。
首先参考图3a，描述上电顺序。响应MS-A上电(步骤301)，它发送一条消息，将这个事实传递到HLR(步骤303)。HLR再将这个信息沿途传递到服务节点(步骤305)，后者的响应是将这个状态变化报告给MS-A的“通知其它人”列表306中所指定的那些其它用户。正如前面所解释的，HLR存储了用户是否注册了WOLN业务的指示。如果用户是WOLN用户，HLR就向服务节点发送查询，有关MS-A的关系人(“朋友”)目前哪些在线(步骤307)。在这个例子中，系统节点检查MS-A的“通知我”列表308，然后确定朋友B、C和D在线，并将这个信息传回HLR(步骤309)。HLR再将这个信息通知MS-A(步骤311)。MS-A中的WOLN子系统203则令显示部分103表示朋友B、C和D在线(步骤313)。
在线用户可以得知另一个用户的状态变化，例如另一个用户正在变为在线。与本例有关的信令在图3b中描述。这里假设MS-A已经在线，而且属于用户“E”的另一个电话(标为MS-E)打开(步骤315)，他也在MS-A的“通知我”列表上。由于本例中的每个MS遵循相同的原则，因此通知服务节点MS-E正在变为在线(步骤317)的方式与通知服务节点MS-A打开的方式大体相同。除了与MS-E的进一步通信(未表示)以外，服务节点识别用户E在MS-A列表上(例如，通过检测MS-A列在MS-E的“通知其它人”列表上(未表示))，然后向HLR发送消息，表示MS-E已经打开而且MS-A需要知道这个信息(步骤319)。HLR通过向MS-A发送消息来响应，告诉它MS-E已经打开(步骤321)。根据这条消息的接收，WOLN子系统使显示部分103表示用户E在线(步骤323)。
另一种可以保证通知的状态变化是离线。与这种通知有关的信令在图3c中说明。这里，用户A关心的一个移动设备(MS-C)离线(步骤325)。这个信息被沿途传递到服务节点(步骤327)，后者识别用户C在MS-A的列表上(例如，通过检测MS-A列在MS-C的“通知其它人”列表上(未表示))，然后向HLR发送消息，表示MS-C已经关闭而且MS-A需要知道这个信息(步骤329)。HLR通过向MS-A发送消息来响应，告诉它MS-C已经关闭(步骤331)。根据这条消息的接收，WOLN子系统使显示部分103表示用户C离线(步骤333)。
除了与通知有关的信令(例如上面描述的那些)以外，也有与建立并维持列表有关的信令。在图3d的信令例子中，MS-A 201的用户需要建立他的其它用户列表(即，他的“通知我”列表)。例如，他可以通过在话机上按下有关的键或键组合(步骤335)来表示。当然，其它类型的用户输入选择技术，例如菜单选择技术，也可作为替代使用。其话机(MS-A 201)允许他输入他需要列在最初列表上的其它用户标识，或者向现有列表添加。在本例中，其它用户被标为G、H、I和J。MS-A 201向HLR发送消息，表示它需要建立带有MS-G、H、I和J的列表(步骤337)。HLR将这条信息转发到服务节点(步骤339)。服务节点的响应是建立标有MS-G、H、I和J的新的“通知我”列表，或者向现有的“通知我”列表添加MS-G、H、I和J(步骤341)。在使用“通知其它人”列表的那些实施例中，服务节点的进一步响应是定位分别属于MS-G、H、I和J的“通知其它人”列表并将MS-A添加到这些列表的每一个中。
在最后的信令例子中，MS-A的用户需要从他的“通知我”列表中去掉另一个用户。例如，他可以通过在话机上按下有关的键或键组合(步骤343)来表示。当然，其它类型的用户输入选择技术，例如菜单选择技术，也可作为替代使用。在本例中，要去掉的另一个用户被标为K。MS-A 201向HLR发送消息，表示它需要从列表中去掉MS-K(步骤345)。HLR将这条信息转发到服务节点(步骤347)。服务节点的响应是从MS-A的“通知我”列表中去掉MS-K(步骤349)。在使用“通知其它人”列表的那些实施例中，服务节点的进一步响应是定位属于MS-K的“通知其它人”列表并将MS-A从这个列表中去掉。
上面描述的技术和装置可以用于实现很多不同种类的WOLN业务。在简单情况下，WOLN业务为用户提供有关谁目前可以接受呼叫(或其它传输)的信息，这样就避免了浪费力气向不能响应的用户打电话。
在另一个应用中，WOLN业务不仅通知用户谁目前可以接受呼叫，而且也表示这些人中的任意一个是否注册了(例如)语音邮件业务。有了这个知识，用户可以呼叫已知离线的人，因为用户知道这不是浪费力气--他总是可以留下消息。这种附加业务实现起来相对简单，因为有关一个人是否具有语音信箱的信息已经在大多数蜂窝通信系统的HLR中存在。
在另一种应用中，WOLN业务可以提供信息，表示一个人是否具有与他的话机连接的电子邮件业务、语音邮件或SMS。有了这个知识，用户可以决定发送一条书写的消息，而不是试图建立话音呼叫。
很多其它的WOLN业务应用都是可能的。例如，期望移动通信系统不久能够保留有关移动用户位置的信息。如果使用具有足够大存储器存储可显示地图的PDA，WOLN业务可以提供有关一个人目前行踪的信息，而且这种信息可以图形显示在用户PDA上。
在每个上上述的(或其它的)WOLN业务应用中，系统可以通过向每个移动用户提供是否在另一个用户的“通知我”列表上的选择来提供安全/保密性。默认可以设置为“不允许列在其它用户的列表上”，而且每个用户可以替换这个默认项。也可以提供鉴权功能。如果用户A需要将用户B列在他的“通知我”列表上，那么在更新任何列表之前，向用户B传递一条消息，询问是否可以接受。如果用户B接受被命名在用户A的“通知我”列表上，那么这个许可被发回服务节点，后者因此而更新用户A的“通知我”列表。否则，服务节点将不允许用户A将用户B添加到用户A的“通知我”列表上。
针对WOLN业务的另一个考虑是如何实现必要的信令。现有的移动话机可以用几种方式实现。一种方式是使用控制信道。但是，这种方法可能会很快地超载。或者，可以使用SMS业务，因为它不需要在空中接口上发送很多字节。在未来的系统中，建议的分组数据方案可以有利地使用，因为它们比目前的信令方法更有效，而且可以处理容量要求。
针对WOLN业务的另一个考虑是它可能向移动通信系统增加很多信令。当然，解决这个问题的一种技术是建立基础设施容量解决增加的负荷。另一种方法是从用户的观点改变WOLN业务操作的方式，使用户可以要求一个名单的快速映象。例如，用户可以按下一个键或通过话机(或PDA)上的菜单系统激活“快速映象”功能。当激活时，系统一次返回有关列表上人的数据，而不是每次某个人状态变化就返回一次。
另一种对移动环境特殊的考虑是如何处理在线的某个人暂时移动到无线覆盖很差的位置(例如，公路隧道或电梯)上。对于移动通信系统，看起来这个人变为不可能联系。有了上述的WOLN系统，这个信息会通知“通知我”列表中包括这个特定用户的每个其它用户。但是，移动用户很快又变为“可联系的”，因为他的位置是暂时的(例如，他离开了隧道或电梯)。这种随后的状态变化又会启动到将这个用户置于“通知我”列表上的所有人的信令活动。显然具有有关用户瞬时信息的好处会加重将这种额外信令施加于系统带来的负担。这个问题的一个解决方法是引入报告延迟，过滤掉状态的暂时变化。例如，当移动用户突然离线时，系统可以等待，例如2分钟，此后再检查用户是否仍然离线。如果是，那么他的离线状态的持续性可以认为足以向其它人报告。但是，如果他返回在线，那么就不执行信令。
发明已经参考特定实施例进行了描述。但是，对于本领域技术人员很显然的是可以用上述的那些优选实施例以外的其它特定形式实施本发明。这在不背离发明精神的前提下可以进行。
例如，已经针对示范实施例描述了很多列表。对本领域技术人员显然的是这些列表可以在不背离上面描述的发明概念前提下用很多种方式来实现。例如，“通知其它人”列表已经描述为与特定用户关联的列表。但是，另一个实施例可以设计为：主“通知其它人”列表存于中央站点，例如图2b中描述的服务节点219。在这样的实施例中，每个列表项可以通过指定所关心的用户来寻址，而且项目本身是应该通知所关心用户状态变化的其它用户的列表。
因此，优选实施例只是说明性的，不应该认为在任何方面有所限制。发明的范围由所附权利要求而不是前面的描述给出，而且落入权利要求范围的所有改变和等效物都认为是包含于其中的。