用于订阅互联网协议多媒体子系统(ims)应用服务注册状态的系统和方法
【专利摘要】允许移动设备应用从经由互联网协议多媒体子系统(IMS)访问的应用服务，接收在注册状态中的变化的系统和方法。在移动设备上的应用订阅接收请求的服务的注册状态变化的通知。当服务的注册状态变化发生时，通知消息被传输到移动设备上的应用。状态变化的通知从而由在每个应用服务基础上的每个应用接收。在一些实施例中，当请求向应用注册失败时，相应的通知消息包括失败的原因。在一些实施例中，通知消息由在IMS中运行的注册管理器发起，并被传输至在移动设备上运行的IMS客户端。在一些实施例中，通知消息由每个应用服务发起并直接传输到订阅的应用。
【专利说明】用于订阅互联网协议多媒体子系统(IMS)应用服务注册状态的系统和方法
[0001]对相关申请的交互引用
[0002]本申请要求2011年2月23日递交的申请名称为“SUBSCRIBING FOR INTERNETPROTOCOL MEDIA SUBSYSTEMS (IMS) SERVICES REGISTRATION STATUS” 的美国临时专利申请61 / 445，958，本申请参考引用了该申请的全部内容。
【背景技术】
[0003]互联网协议多媒体子系统(MS)是一种用于提供互联网协议(“IP”)多媒体至移动用户，如智能手机或平板电脑等移动设备的用户的架构框架。頂S核心网络(“IMS core”)允许有线和无线设备访问多媒体、消息、语音应用和服务。MS标准和规范已经由第三代合作伙伴计划(“3GPP”?)颁布。为了允许MS核心网被与互联网资源集成，3GPP规范使用MS核心网内的互联网工程任务组协议，如会话发起协议(“SIP”)和直径(Diameter)。SIP是一种信令协议，用于创建，修改和终止由一个或多个媒体流构成的两方或多方会话。移动设备注册它的IP地址，SIP注册服务器在MS核心“注册”的方法令牌生成和发送SIP请求消息。一旦注册成功,移动设备可能随后建立通过MS核心的多媒体会话。
[0004]在移动设备上的MS客户端(或MS堆栈)软件组件允许在移动设备上的一个或多个应用注册在MS网络上提供的各种应用服务。如果注册成功，则移动设备应用稍后可以利用其所向之注册的应用服务所提供的功能。然而，如果注册失败，则应用将不能利用所提供的功能。在所请求的注册失败的情况下，请求的应用可能会受益于收到失败通知。在目前的系统中，请求的应用可能会收到一个通用通知，警告移动设备已发生一个或多个注册故障，无需提供特定服务注册失败的指示。这个缺点导致被拒绝的应用服务触发器注销所有应用，即使那些应用不一定需要被终止。此外，在目前的系统中，通用通知可以省略描述失败原因的性质的信息。传送到移动设备上的应用的信息缺乏意味着它无法有效地评估为了向应用服务注册应采取什么额外的步骤(如果有的话)。
[0005]图1A和IB提供根据目前系统的IMS应用服务注册程序的概念式(high level)说明。在图1A中，应用I发送请求到MS客户端以注册应用服务，确定为ICSI_1 (步骤I);应用2发送请求到IMS客户端以注册应用服务，确定为ICSI_2 (步骤2)；以及应用3发送请求到IMS客户端以注册应用服务，确定为ICSI_3 (步骤3)。接收服务注册请求后，IMS客户端传输所有接收到的注册请求至MS网络(步骤4)，其返回一个确认消息到MS客户端(步骤5)。在步骤6中，MS网络发送应用服务的注册请求，确定为应用服务器3的ICSI_3 (其与ICSI_3相关联)；在步骤7中，IMS网络发送应用服务的注册请求，确定为应用服务器2的ICSI_2 (其与ICSI_2相关联)，以及，在步骤8中，IMS网络发送应用服务的注册请求，确定为应用服务器I的ICSI_1 (其与ICSI_1相关联)。在IMS网络发送每一个注册请求到其相关的应用服务器之后，每个相应的应用服务器返回给MS网络一个指示注册是否成功或失败的确认。例如，在步骤9中，应用服务器3返回“0K”的确认以通知MS网络注册成功；在步骤10中，应用服务器2返回“0K”的确认以通知MS网络注册成功，并在步骤11中，应用服务器I返回“OK”的确认以通知MS网络注册成功。
[0006]相应地，图1A说明了一个成功的注册流程，其中每个请求的注册对每一个请求的服务都是成功的。然而，在实践中，一个或多个请求的注册可能失败。例如，图1B示出与图1A相同的注册流程除了在步骤9中，应用服务器3将返回一个“Ν0Κ”的确认。不同于图1A中的步骤9中的“0K”的确认，图1B的步骤9中的“Ν0Κ”的确认指示应用服务的注册，确定为ICSI_3，已失败。
[0007]当这样的失败发生时，请求的注册的应用可能会受益于接收失败发生的通知。因此，应用可以订阅接收通知，通知指示请求的注册是否成功或不成功。在实践中，单个应用可以请求注册或多个服务。例如，单个应用可请求服务A的注册，其最终成功；并可以请求服务B的注册，其最终成功注册；并可以请求服务C的注册，其最终失败。在目前的系统中，应用将只通知收到的失败，应用将不会被通知收到失败的特定的应用服务。换句话说，该应用会知道至少一个应用服务失败了，但应用将不知道失败是否相对于服务A、服务B、服务C发生了。其结果是，该应用将被迫终止所有的应用服务(即，应用将终止服务A、服务B和服务C)，而不是只终止失败的一个服务(即，服务C)。此外，在目前的系统中，应用不会收到失败的原因。例如，应用不知道所请求的注册是否因为移动设备用户没有支付访问失败的服务，因为不能建立至所请求的服务相关联的服务器的物理连接，或一系列可能的其他原因而失败。
【专利附图】
【附图说明】
[0008]图1A是说明MS服务的成功注册的流程图。
[0009]图1B是说明MS服务的不成功的注册的流程图。
[0010]图2A是代表互联网协议多媒体子系统(MS)环境的示意图，在该环境中，应用服务可由移动设备订阅。
[0011]图2B是移动设备中的组件的方框图，该移动设备在每一个应用的基础上，接收注册状态变化的通知。
[0012]图3A是示出了发送到移动设备的应用服务简化图的方框图。
[0013]图3B是在每一个应用的基础上，提供注册状态变化通知的呼叫会话控制功能(CSCF)网络节点的组件的框图。
[0014]图4是示出了 IMS服务的部分不成功的注册的流程图。
[0015]图5是示出了 IMS服务的成功的注册的流程图，在该IMS服务中每一个请求应用接收来自MS客户端的注册状态通知。
[0016]图6是示出了 IMS服务中的部分不成功的注册的流程图，在该IMS服务中，每个请求应用接收来自相关应用服务的注册状态通知。
[0017]图7是示出了注册状态机、基于每个应用注册状态机和基于每个服务注册状态机之间的关系的框图。
[0018]图8是提供应用的注册状态细节的XML文档的例子。
[0019]图9是示出了注册状态机和基于每个应用的注册状态机的方框图。
【具体实施方式】[0020]本文公开了允许移动设备应用接收来自可以被经由互联网协议多媒体子系统(MS)访问的应用服务的注册状态中的变化的系统和方法。在移动设备上的应用传送请求，以向经由MS网络的一个或多个可用的应用服务注册。在移动设备上的应用订阅接收一个或多个请求的服务的注册状态变化的通知。当服务注册状态的变化发生时-特别是服务的终止-通知消息传送到移动设备上的应用。通过在每一个应用服务(per-application-service)的基础上接收状态中变化的通知,在移动设备中的应用能够更好地评估什么补救措施，如果有的话，可被采取以重新订阅应用服务，定位不同的应用的服务，或停止，或以其他方式调节当前的应用的的操作，如果注册失败发生。
[0021]在一些实施例中，当向应用服务注册的请求失败时，相应的通知消息包括失败的原因。失败的原因可以被传送到移动设备，例如，可扩展标记语言(XML)文档中。失败的原因提供了额外的信息以协助在移动设备上的应用确定什么，如果有的话，补救措施应被采取。在一些实施例中，通知消息扩展订阅为由请求注解(RFC)中的互联网工程任务组(IETF)定义的注册信息。在一个实施例中，MS通信服务标识符(ICSIs)和MS应用注册表标识符(IARIs)被用来传达个别服务的状态。
[0022]在一些实施例中，通知消息由在MS中操作的注册管理器发起。注册管理器传送通知消息至在移动设备上操作的MS客户端，其中消息的内容被分发到在移动设备上的订阅的应用。在一些实施例中，通知消息由每个应用服务发起，并直接传送到在移动设备上的订阅的应用。
[0023]现在将描述本发明的各种实施例。下面的描述提供了这些实施例的透彻了解和可行说明的具体细节。然而，本领域技术人员将理解，没有许多这些细节也可以实施本发明。此外，一些知名的结构或功能可能未被详细显示或描述，以避免不必要地模糊各种实施例的相关描述。在下面的描述中所使用的术语的旨在以其最广泛的合理方式来解释，即使它被与本发明的某些特定实施例的详细描述配合使用。
[0024]代表件环塏
[0025]图2A是典型的互联网协议多媒体子系统(MS)环境200的示意图，图中来自应用反映注册状态变化的程序服务的通知消息被传送到移动设备。在环境200中，移动设备202被配置来与受信任的无线接入网络(RAN) 204和/或不受信任的RAN203进行通信，或通过受信任的无线接入网络(RAN) 204和/或不受信任的RAN203进行通信，以为了向MS核心207注册并利用IMS核心207。IMS允许服务提供商实施一系列引人注目的移动设备的移动服务。不同的IMS服务的IMS注册可以基于在请求注解(RFC) 3680中定义的注册信息的SIP事件包和在3GPP测试规范(TS) 24.229中定义的程序。
[0026]用户可以采用移动设备202与其他用户和设备进行通信。此外，用户可以采用移动设备202接收、提供或以其他方式与多个MS服务互动。例如，基于位置的服务是使用移动设备的实际的或近似的位置以向移动设备提供增强或补充的服务。基于位置的服务，包括但不限于，紧急服务(如E911)、资产跟踪或恢复服务(例如，被盗车的追踪)、基于位置的警报或广告服务(例如，依赖于移动设备用户的位置的有针对性的广告)、社交网络服务(例如，报告家人或朋友的相对位置的服务)和/或类似物。此外，用户还可以采用移动设备202接收、提供或以其他方式与另外的MS服务交互，另外的MS服务包括图像共享服务、游戏服务、多媒体电话服务、即时消息和在线服务、视频会议和共享服务、无线一键通(PoC)服务、3GPP组合服务(CSI)，和其他电信和互联网融合服务。一旦移动设备202向MS核心网207成功注册，该设备可建立MS核心管理的多媒体会话，以便访问促进通信的应用和服务、基于位置的服务和/或其他服务。
[0027]移动设备202可以几乎包括通过无线网络进行通信的任何设备。这些设备包括移动电话，如全球移动通信系统(GSM)电话、时分多址(TDMA)电话、通用移动通信系统(UMTS)电话、演进数据优化(EVDO)电话、长期演进(LTE)电话、通用接入网络(GAN)电话、非授权移动接入(UMA)电话和其它移动计算机或设备，如互联网语音协议(VoIP)设备、安全用户平面定位(SUPL)启用终端(SETs)、个人数字助理(PDAs)、无线电频率设备、红外设备、掌上电脑、笔记本电脑、可佩戴的计算机、平板计算机、寻呼机，前述设备中的一个或多个组合的集成器件，等等。
[0028]如在图2B中示出，其是典型的移动设备的框图，每个移动设备202通常包括用于执行处理指令的处理器270，数据存储介质组件280 (例如，硬盘驱动器、闪存、记忆卡等)，易失性存储器和/或非易失性存储器290，电源300，一个或多个网络接口(例如，蓝牙接口250 ;和网络通信接口 255，其使得移动电话通过经由电信网络的使用许可，半许可或未许可的频谱发送和接收无线信号来进行通信)，音频接口 285，显示器260，小键盘或键盘265，以及其他的输入和/或输出接口 295。移动设备的各个组件可以通过总线相互连接。易失性和非易失性存储器一般包括用于存储信息，例如处理器可读指令，数据结构，程序模块或其他数据的存储介质。可被存储的信息的一些例子包括基本输入/输出系统(BIOS)，操作系统，和应用。所存储的信息可以包括一个或多个能够产生，传输和解释语法上是正确的SIP消息的SIP客户端。SIP客户端允许移动设备向ISM核心207注册并通过ISM核心207通?目。
[0029]返回到图2Α，移动设备202可以由受信任的RAN204或不可信的RAN203连接到MS核心207。这两种类型的RAN s提供移动设备202和MS核心网之间的第一物理无线链路。单个移动设备可能能够使用一种或两种类型的RANs。RANs203、204可以使用任何无线通信和数据协议或标准，如GSM、TDMA, UMTS, EVDO, LTE、GAN、UMA、码分多址(CDMA)协议(包括IS-95、IS-2000和IS-856协议)，高级LTE或LTE+、正交频分多址接入(OFDM)、通用分组无线业务(GPRS)、增强数据GSM环境(EDGE)、高级移动电话系统(AMPS)、WiMAX协议(包括IEEE802.16e-2005和IEEE802.16m协议)、无线保真(WiFi)、高速分组接入(HSPA)(包括高速下行分组接入(HSDPA)和高速上行分组接入(HSUPA))、超移动宽带(UMB)、SUPL，等等。
[0030]受信任的RAN204是由MS核心207的运营商或与MS核心运营商相关联的其他值得信赖的一方(例如，运营商的承包商，联盟或行业合作伙伴)所经营的RAN。为了通过受信任的RAN进行无线通信，移动设备202可能需要通过部分由受信任的RAN实施的初步的验证/授权检查。受信任的RAN通过专用回程(例如，不向公众开放的私有网络)和中间组件206被连接至MS核心并与MS核心通信。中间组件可包括，例如，网关GPRS支持节点(GGSN)、服务GPRS支持节点(SGSN)或类似的促进移动性管理、会话管理和受信任的RAN204内的IP数据包服务的传输的组件。
[0031]不受信任的RAN203是通过公共网络(如Internet)连接到MS核心网207的RAN。不受信任的RAN可能无法实现足以防止基于MS核心的安全攻击的认证/授权测试。在一些例子中，移动设备202使用WiF1、GAN或UMA协议在无线接入点连接到不受信任的RAN。[0032]中间组件206和不受信任的RAN103都连接到MS核心网207。IMS核心包括各种呼叫会话控制功能(CSCF)和其他组件，其中包括提供SIP注册和代理功能。IMS核心包括代理 CSCF (P-CSCF) 208、询问 CSCF (1-CSCF) 212、服务 CSCF (S-CSCF) 216、安全网关(SEG) /会话边界控制器(SBC) 210，归属用户服务器(HSS) 214。MS核心组件的基本功能由3GPP颁布的标准描述，3GPP颁布的标准包括3GPP TS23.002，版本9.2.0第9版，其通过引用将其全部并入于此。
[0033]如图2A中所示，中间组件206通过P — CSCF208连接受信任的RAN204至MS核心网207。与此相反，不受信任的网络203通过SEG / SBC210间接地连接到P — CSCF208。SEG / SBC在移动设备202和MS核心之间可以建立安全IP隧道。在一些实例中，受信任的网络204可以通过SEG / SBC连接到P— CSCF。在其他实施例中，不受信任的网络通过互联网直接连接到P — CSCF。
[0034]为了向MS核心网207注册，移动设备202上运行的SIP客户端生成并通过受信任的RAN204或不受信任的RAN203发送初始SIP注册消息到MS核心网。初始注册消息包括REGISTER方法令牌和扩展头的信息，包括与移动设备202相关联的MEI和MSI。该P—CSCF208接收初始的SIP注册消息并将消息转发到I一CSCF212。本领域技术人员将会理解，在一些实施例中，P-CSCF也可以执行SEG / SBC210的部分或全部的功能。
[0035]该I一CSCF212和/或S — CSCF216可以利用在接收的注册消息中的MEI / IMSI标识符通过Diameter协议生成和发送用户授权请求(UAR)至HSS214。UAR尤其包括与移动设备202相关联的MEI和MSI。在一些实施例中，在I一CSCF利用从P — CSCF转发的SIP注册消息生成并发送UAR至HSS以及S — CSCF实施额外的标准的MS注册方法。在其他实施例中，I一CSCF不生成和发送UAR，而是查询HSS以识别注册消息被转发至哪一个S—CSCF0在这样的例子中，在I一CSCF转发接收到的SIP注册消息至被识别的$—CSCF。如在本文中更详细地描述，S — CSCF稍后利用SIP注册消息以产生并向HSS发送UAR。S — CSCF发送SIP注册信息的一个或多个应用服务器220、225和230，以完成注册过程。S — CSCF还实施了更多的标准的頂S注册方法(例如，HTTP摘要认证和密钥协议(AKA)认证)。
[0036]HSS214是一个主用户数据库，其中包含与订阅有关的信息，如订户配置文件。该HSS执行移动设备202的认证和授权，并提供关于移动设备的IP地址的信息。该HSS可以执行标准的如3GPP规范和标准所描述的MS注册程序。该HSS也验证在UAR中的MEI /IMSI标识符，以便确定是否拒绝到移动设备202的注册。该HSS也可以使用接收的MEI，以确定移动设备的性能。
[0037]IMS服备沣册的概沭
[0038]图3A是提供到移动设备的IMS应用服务的注册及交付的简化视图的方框图。在移动设备305上运行的应用使用MS客户端325在MS网络中注册应用服务。MS客户端(或MS堆栈)维护MS注册，只要应用需要保持与相应的应用服务的联系。在MS网络中的MS代理(*-CSCFs) 330保持由移动设备发起的注册，并为MS通信提供合适的路由。当出于任何原因的其中一个的应用服务器被涉及拒绝初始注册请求，IMS服务无法用于移动设备，并且移动设备上的应用的功能可以基本上或完全由注册失败所影响。
[0039]在图3A中，在移动设备305上的三个应用被描述为使用应用服务，即应用A (310)、应用B (315)和应用N(320)。在移动设备上的应用与MS网络通过MS客户端325进行通信。MS客户端325位于移动设备内，并管理移动设备应用和在MS网络中的其他组件之间的通信。例如，頂S客户端325接收来自移动设备的应用(310、315、320)的注册请求，转发接收的注册请求到IMS网络370，接收来自移动设备应用的注册状态通知订阅请求，并转发接收到的注册状态通知订阅请求到MS网络。在一些实施例中，MS客户端325额外地接收来自应用服务340、350和360的注册状态通知，并转发接收到的状态通知到适当的移动设备应用。那些本领域技术人员将会理解的頂S客户端325可以在Android?、WindoWs?、iOS?中，或由移动设备所使用的其他操作系统环境中被执行。
[0040]IMS客户端325连接到MS网络中的一个或多个CSCF330内的注册管理器组件335。注册管理器组件335位于MS网络中，并且管理在一个或多个移动设备应用310、315、320和一个或多个应用服务340、350、360之间的注册。例如，注册管理器335接收来自移动设备应用的注册请求，将接收到的注册请求转发至合适的应用服务器，从MS客户端接收注册状态通知订阅请求，并转发接收到的注册状态通知订阅请求到合适的应用服务器。在一些实施例中，注册管理器335可以接收起到注册请求和登记状态通知订阅请求功能的单个请求。收到请求后，注册管理器335可以将请求转发到合适的应用服务，并自动订阅应用以接收与该服务相关的状态通知。在一些实施例中，注册管理器335额外地从一个或多个应用服务器接收注册状态通知并转发接收到的注册状态通知到MS客户端325。
[0041]图3B是执行注册管理器组件335的的功能的MS网络370内的CSCF330节点的框图。CSCF330可能包含一个或多个用于执行处理指令的处理器375、数据存储介质组件385 (例如，硬盘驱动器，闪存，存储卡等)，易失性存储器和/或非易失性存储器380。执行注册管理器335功能的指令可被存储在数据存储介质和/或存储器中并由处理器执行。虽然注册管理器组件335的功能在图3B中被描述为位于CSCF330内，但是应当理解的是注册管理器组件335可以独立于CSCF330被执行。也就是说，注册管理器组件335可作为MS网络370内的一个独立服务被操作，或可以包含在MS网络370内的其它网络节点中。
[0042]返回到图3A，IMS网络370可以被连接到多个提供应用服务的应用服务器。例如，注册管理器335可以连接应用服务A内的状态通知组件345，连接到应用服务B内的状态通知组件355，以及连接到应用服务N内的状态通知组件365。每个状态通知组件(345、355、365)位于其各自的应用服务内，管理其各自的应用服务器和MS网络之间的通信，并处理注册请求(即，发起在发起注册请求的应用和所请求的服务位于其上的应用服务器之间的主动连接)。例如,状态通知组件355接收来自MS网络的注册请求，处理所请求的注册,并生成注册状态的通知，该通知指示所请求的注册是否成功或不成功。在一个实施例中，状态通知组件355发送所生成的通知到IMS网络，其稍后转发所生成的通知给请求应用。在另一个实施例中，状态通知组件355直接将所生成的通知发送到应用，该应用请求注册至服务。在图3A中，三个服务是相互独立的，也就是说，应用服务A提供的价值不依赖于应用服务B或应用服务C是否可用。此外，服务A将继续可用即使访问服务B不获批准或以其他方式因任何原因终止。
[0043]IMS服务的注册及注册信息的订阅
[0044]图4是示出了 MS服务的部分不成功的注册的流程图。应用A连接到IMS客户端(步骤I)，请求到MS网络的注册(步骤2)。MS网络认证请求的应用位于其上的移动设备，以及向MS客户端发送IMS网络的注册是否成功或不成功的指示。例如，在步骤3中，IMS网络返回“2000K”状态到MS客户端，从而表明到MS网络的注册成功。在步骤4中，IMS客户端转发状态成功的指示到应用A。在步骤5中，在接收到注册请求后，MS网络转发注册请求(源自应用A)的应用到程序服务A。应用服务A可返回应用服务注册是否成功或不成功的指示到頂S网络。例如，在步骤6，应用服务A返回“2000K”状态到MS网络，从而表明应用服务A注册成功。
[0045]接着，应用B连接到MS客户端(步骤7)以请求到MS网络(步骤8)的注册。因为应用B位于其上的移动设备先前被连接到MS网络(步骤2)，连接被简单地刷新而不是重新建立(步骤8)。然后，MS网络发送MS网络的刷新是否成功或不成功的指示到IMS客户端。例如，在步骤9中，IMS网络返回“2000K”状态至IJ IMS客户端，从而表明到IMS网络的注册(即，刷新)成功。在步骤10中，IMS客户端转发成功状态指示到应用B。在步骤11中，在接收注册请求之后，IMS网络转发注册请求(源自应用B)应用服务B。应用服务B可以返回应用服务注册是否成功或不成功的指示到MS网络。例如，在步骤12中，应用服务B返回“200N0K”状态到MS网络的，从而表明到应用服务B的注册失败。
[0046]为了代表性任何失败的注册请求，应用A可请求订阅以接收有关的任何请求的连接的通知。例如，在步骤13中，应用A发送订阅请求到MS客户端。在步骤14中，MS客户端转发订阅请求到MS网络。MS网络然后发送接收通知的订阅是否成功或不成功的指示到IMS客户端。例如，IMS网络返回“2000K”确认至IJ IMS客户端(步骤14.1)，然后将确认转发至应用A (步骤14.2)。
[0047]在步骤15中，MS网络发送通知信息到MS的客户端。MS客户端确认收到通知(步骤16.1)和转发收的通知到应用A(步骤16.2)，因为应用A先前订阅接收通知(步骤13)。
[0048]在步骤17中，应用B发送订阅请求到MS客户端。在步骤18中，MS客户端转发订阅请求到IMS网络。IMS网络稍后发送接收通知的订阅是否成功或不成功的指示到IMS客户端。例如，頂S网络返回“2000K”确认到MS客户端(步骤18.1)，然后转发确认到应用B (步骤18.2)。
[0049]在步骤19中，MS网络发送通知信息到MS客户端。MS客户端确认收到通知(步骤19.1)，并转发收到通知到应用B (步骤20)，因为应用B先前订阅接收通知(步骤17)。此外，IMS客户端转发收到的通知到应用A(步骤20.1)，因为应用A先前也订阅收到通知(步骤13)。通知信息在服务的基础上提供服务状态指示至每个应用。提供通知信息到应用允许应用更好地确定当应用服务状态变化时应采取什么样的行动。
[0050]图5是示出MS服务的成功注册的流程图，在MS服务中，每一个请求应用从MS客户端325接收注册状态通知。应用I发送注册服务的请求至MS客户端以被确定为ICSI_1 (步骤I);应用2发送注册服务的请求至IMS客户端以被确定为ICSI_2 (步骤2)；应用3发送注册服务的请求至IMS客户端以被确定为ICSI_3 (步骤3)。在接收服务注册请求后，MS客户端发送所有接收到的请求到MS网络(步骤4)，其返回确认消息到MS客户端(步骤5)。在步骤6中，IMS网络发送服务的注册请求确定为ICSI_3至应用服务3(其与ICSI_3相关联)，在步骤7中，IMS网络发送注服务的册请求确定为ICSI_2至应用服务2(其与ICSI_2相关联)，以及在步骤9中，IMS网络发送服务的注册请求确定为ICSI_1至应用服务I (其与ICSI_1相关联)。在步骤8，IMS网络接收来自MS客户端的订阅请求以接收有关MS客户端发送的所有注册请求的通知信息。在步骤10中，MS网络发送请求的确认至MS客户端。MS客户成功订阅以接收通知后，IMS网络从每一个注册曾被请求的服务接收注册状态:在步骤11中，应用服务3发送“NOK”确认以通知IMS网络注册失败，在步骤12中，应用服务2返回“OK”确定以通知MS网络注册成功，以及在步骤13中，应用服务I返回“OK”确认以通知MS网络注册成功。在接收每个服务的注册状态之后，MS网络发送通知到MS客户端(步骤14)，返回确认到MS网络(步骤15)。在从MS网络接收通知之后，IMS客户端转发接收到的通知到与MS客户端连接的所有的应用:在步骤16中，IMS客户端将接收到的通知转发到应用3 ;在步骤17中，IMS客户端将接收到的通知转发到应用2，以及，在步骤18中，IMS客户端将接收到的通知转发到应用I。
[0051]图6是示出IMS服务的部分未成功注册的流程图，在IMS服务中，每个请求应用直接从相关的应用服务接收注册状态通知。应用I发送注册服务的请求至IMS客户端以确定为ICSI_1 (步骤I);应用2发送注册服务的请求至IMS客户端以确定为ICSI_2 (步骤2)；以及应用3发送注册服务的请求至IMS客户端以确定为ICSI_3 (步骤3)。在接受服务注册请求后，MS客户端发送的所有接收到的请求到MS网络(步骤4)，其返回确认消息到IMS客户端(步骤5)。在步骤6中，MS网络发送服务的注册请求确定为ICSI_3至应用服务3(其与ICSI_3相关联)；在步骤7中，IMS网络发送注服务的册请求确定为ICSI_2至应用服务2 (其与ICSI_2相关联)，以及在步骤8中，IMS网络发送服务的注册请求确定为ICSI_1至应用服务1(其与ICSI_1相关联)。在步骤9，IMS网络接收来自应用I的订阅请求以接收有关应用I发送的所有注册请求的通知信息。在步骤10中，MS网络转发订阅请求至应用服务I。在接收订阅请求后，应用服务I直接返回确认至应用I (步骤12)。在步骤13中，应用服务I发送通知至应用I，其返回确认至应用服务I (步骤14)。
[0052]注册状态机和基于每个应用的注册状态机
[0053]图9示出与向IMS核心注册的每个移动设备相关联的注册状态机(RSM)。如在RFC3680中列出的，RSM100与每个移动设备地址记录相关联。当没有移动设备注册地址记录时，RSM是“初始”状态105。当移动设备注册地址记录时，RSM过渡到“激活”状态110。RSM保持在活跃状态，只要有移动设备注册。当移动设备取消注册时，RSM过渡到“终止”状态115，然后立即转换到初始状态105。从初始状态过渡到激活状态，从激活状态过渡到终止状态，产生注册信息的任何订户通知。从终止状态过渡到初始状态不生成通知。
[0054]图9还描述了基于每个应用的注册状态机125，其与通过MS核心拨打服务电话的每个移动设备应用相关联。每个移动设备的注册与一组应用相关联。除了与移动设备相关联的RSM100，在移动设备上的每个应用与自己的状态机(“基于每个应用的RSM”)进行建模。然而，当没有应用被注册时，基于每个应用的RSM125不会存在。相比之下，RSM100始终存在不论地址记录是否存在。基于每一个应用的RSMs的初始状态130和终止状态140是短暂的，也就是说，基于每个应用的RSM在创建后立即过渡到激活状态135。当终止时，基于每个应用的RSM过渡到销毁状态145。因此，订户不会被通知关于从初始状态转变到激活状态，以及从终止状态到销毁状态。
[0055]无论RSM或任何基于每个应用的RSMs的状态何时发生变化，注册管理器335可以向移动设备发送注册信息。为了减少通知通信，服务器可仅当订户需要这样的通知时通知完全状态。这样的要求的通知可能会发生，例如，当具有到期定时器的订阅被接收时。否则，通知可能包含关于改变状态的RSM的唯一信息。
[0056]基于每个服务的注册状态机
[0057]正如前面所描述的，在移动设备上的每个应用可被注册一组一个或多个服务。这些服务被頂S通信服务标识符(ICSIs)或MS应用注册表标识符(IARIs)进行识别。这些服务的每一个与其自己的基于每个服务的注册状态机(“基于每个服务的RSM”)进行建模。基于每个服务的RSM当应用向IMS服务(由ICSI或IARI确定的)时被具体化，以及当由ICSI或IARI确定的IMS服务的应用的注册被移除时而被删除。基于每个服务RSM与基于每个应用的RSM是相同的，不同之处在于基于每个应用的RSM可以多于一个的基于每个服务的RSM。
[0058]每个应用服务可生成至订户的通知而不论事件发生是否适合于该服务。然而，在实践中，在服务层的每个事件的通知可能是不可取的。对于基于每个服务的RSM，过渡到激活状态和过渡到终止状态，可以被通知给所有订户。所有其他的转换可能会或可能不会被注册管理器335进行通知。此外，在实践中，避免生成包含整个注册状态的完全通知是可取的。相反，通知可包含有关实际发生的变化的注册信息。例如，应用可以注册第一服务确定为ICS1-1和第二服务确定为ICS1-2，从而导致两个基于每个服务的RSMs。当ICS1-2的RSM被终止时，则通知将包含只介绍这个过渡的注册信息。由ICS1-1确定的服务的事实保持活跃不被通知。
[0059]以这种方式应用基于每个服务的RSM以使得在移动设备上运行的应用订阅MS服务状态并仅在状态发生变化时被通知。在上面的例子中，MS应用传送由ICS1-2确定的服务可取消注册并通知用户，而应用传送由ICS1-1所确定的服务将继续运行。
[0060]在RSM、某于毎个应用的RSM和某于毎个服备的RSM之间的关系
[0061]图7中的图表描述了 RSM405、基于每个应用的RSMS410和基于每个服务的RSMS415之间的关系。当RSM为激活状态时，至少一个的基于每个应用的RSM必须存在，因为任何注册必须与一组应用相关联。然而，基于每个服务的RSM与由ICSI或IARI所确定的服务相关联。在实践中，应用可以为IMS注册但不会为某项服务注册。
[0062]订户(即，应用或MS客户端)可以请求在完整的RSM或在基于每个服务的RSM中的转换的通知。对于完整的RSM，订户可以按照RFC3680发送订阅请求。对于基于每个服务的RSM，订户可包括所有的识别在订阅请求或在单独的请求中的基于每个服务的RSM的ICSIs和IARIs。注册管理器335接受订阅到基于每个服务的RSM并生成代表由在订阅请求中接受到的ICSIs和IARIs所确定的服务。
[0063]注册信息文件
[0064]注册管理器335可传达注册状态中的变化到移动设备的注册信息文档。图8描述了具有代表性的注册信息文档800，其格式为可扩展标记语言(XML)文档。可以理解的是，除了所描述的语言格式也可以使用其他格式的语言提供注册状态信息。
[0065]注册信息文档由注册信息元素805和它的版本及状态属性所表示。RSM由注册元素810和责任区域、ID及状态属性所表示。基于每个应用的RSM由接触元素、它的属性(attr)和统一资源标识符(uri)元素所表示。未知-参数元素被专门定义为传达未在SIP规范文档(RFC3261)中指定的应用头部参数。在所描述的文档中，未知-参数元素被因此用来表示基于每个服务的RSM。具体来说，未知-参数元素由指定注册状态被寻求或提供的服务的ICSI和IARI参数815填充。正如在TS24.229中指定的，ICSIs被编码为g.3gpp.1csi一ref以及IARIs编码为g.3gpp.1ari一ref。所有的应用标识符和服务标识符由联系人和/或接受-联系头部中的移动设备在注册阶段进行添加。这些标识符也可以被包含在所有的适合于其他请求而不是注册请求的通用程序中。
[0066]除了包括确定服务的注册状态，注册信息文档还可包含元素820，元素820传达基于每一个服务的RSM过渡的原因。该原因当服务转换到终止状态时可被提供，也可以当服务转换到其他状态时被提供。例如，在图8中典型的注册信息文件描述激活的RSM，MMTEL服务的激活的基于每个服务的RSM和GAMEX版本I服务的终止的基于每个服务的RSM。特别是，注册信息指示GAMEX服务失败，因为“到GAMEX服务的[用户]订阅已被终止。”通过为应用提供这样的基于服务的过渡的原因，该应用能够将此信息传达给用户，以使用户能够采取措施补救终止条件。事实上，在过渡到终止状态的原因的目的是要显示给移动设备的用户的情况下，状态过渡的实际原因是特别重要的。
[0067]一般来说，本文所公开的系统和方法，由此扩展为在RFC3680中定义的基于每个应用的RSM和在MS中的上下文中定义了基于每个服务的RSM。因此，所公开的系统允许在移动设备上运行的MS应用订阅特定的MS服务的状态变化。还允许MS网络终止服务而让其他服务继续。
[0068]在基于每个服务的基础上提供注册状态信息以及为过渡到终止状态提供原因的能力使应用可以更有效地利用系统资源并更提供丰富的用户体验。例如，应用可使用状态和原因信息以维持已成功建立的服务连接，而重新尝试先前失败的服务。此外，注册状态和原因信息可允许应用通知用户为什么特定请求的服务不可用。本领域技术人员将会理解，注册状态和原因信息可允许公开的系统提供额外的可以提供更丰富的用户体验的功能，如显示指示服务中断是否是暂时性质的(例如，应用服务器暂时处于离线状态)，或显示指示表明服务中断将一直有效直到用户采取指定的动作(例如，支付逾期账单至服务提供商或同意支付一个或多个独立的服务)。
[0069]系统的实施例的上述的详细描述并非意在穷举或限制系统为上述公开的精确形式。而如上所述的系统的具体的实施例是说明目的，作为在相关领域的技术人员将认识到系统范围内的各种等同修改是可能的。例如，当过程或步骤以给定顺序呈现时，替代实施例可以以不同的顺序执行具有步骤的例程或采用具有步骤的系统，并且一些过程或步骤可被删除、移动、添加、细分、结合和/或修改，以提供选择或重组。这些过程或步骤中的每一个可以被以多种不同的方式实现。此外，虽然过程或步骤在时间上以串联方式被显示，这些过程或步骤也可以被并行执行或者在不同的时间被执行。
【权利要求】
1.一种在移动设备中接收来自注册的应用服务的服务通知的计算机可执行方法，所述方法包括: 从所述移动设备并通过互联网协议多媒体子系统aMS)传输请求，以向多个相关的应用服务注册在所述移动设备上的至少一个应用；和 在所述移动设备上从所述多个应用服务接收多个通知，在应用服务基础上，每一个所述通知指示所述对应的应用服务的所述状态，其中至少一个的所述通知指示所述对应的应用服务的失败。
2.如权利要求1所述的计算机可执行方法，其中所述多个通知包括，每一个被请求的注册是活跃或者是被终 止的指示。
3.如权利要求1所述的计算机可执行方法，其中所述多个通知进一步包括所述注册状态的理由的指示。
4.如权利要求3所述的计算机可执行方法，进一步包括如果所述接收到的通知指示所述注册终止，则撤销在所述移动设备上的所述相关的应用的注册。
5.如权利要求1所述的计算机可执行方法，其中所述通知由所述移动设备上的所述应用接收。
6.如权利要求5所述的计算机可执行方法，其中所述通知被从所述应用服务传输到所述应用。
7.如权利要求1所述的计算机可执行方法，其中所述通知由在所述移动设备上的IMS客户端接收，所述IMS客户端将所述接收的通知提供至所述移动设备上的所述对应的应用。
8.如权利要求7所述的计算机可执行方法，其中所述通知被从所述MS客户端中的组件传输至頂S客户端。
9.一种提供应用服务状态通知到移动设备的计算机可执行方法，所述方法包括: 从多个移动设备接收请求，以接收由所述多个移动设备经由互联网协议多媒体子系统(IMS)访问的应用服务的状态改变的通知； 从应用服务接收多个通知，每一个通知提供相应的应用服务的状态； 识别与在每一个所述接收到的多个通知中的所述应用服务相关联的移动设备； 对于每一个接收到的通知，提供所述接收到的通知至所述与所述应用服务相关联的所述被识别的移动设备，在应用服务基础上，所述通知指示所述应用服务的所述状态。
10.如权利要求9所述的计算机可执行方法，其中所述接收到的状态指示所述被请求的应用服务是否活跃或者被终止。
11.如权利要求9所述的计算机可执行方法，其中所述每一个通知进一步包括所述接收到的状态的理由的指示。
12.如权利要求11所述的计算机可执行方法，其中所述接收到的状态的理由被包含在可扩展标记语言(XML)文档中。
13.如权利要求9所述的计算机可执行方法，其中所述通知被从所述应用服务传输至所述被识别的移动设备上的一个或多个应用。
14.如权利要求9所述的计算机可执行方法，其中所述通知被从所述IMS客户端中的组件传输至在所述被识别的移动设备上的所述頂S客户端。
15.一种有形的计算机可读介质，其存储的指令当由移动设备的处理器执行时使得所述移动设备执行一个方法，以从通过因特网协议多媒体子系统(MS)访问的应用服务接收注册状态中的变化，所述方法包括: 在所述移动设备上接收请求，以向一个或多个经由互联网协议多媒体子系统访问的应用服务注册在所述移动设备上的一个或多个应用的； 经由所述MS传输所述请求以将在所述移动设备上的所述一个或多个应用注册至所述一个或多个相关联的应用服务； 在所述移动设备上接收一个或多个有关所述请求的注册的通知，在应用服务基础上，所述一个或多个通知指示每一个应用服务的所述注册，所述通知被提供给在所述移动设备上的相应的应用。
16.如权利要求15所述有形的计算机可读介质，其中所述一个或多个通知进一步包括所述注册的状态的理由的指示。
17.如权利要求16所述有形的计算机可读介质，其中所述注册的状态的理由被包含在可扩展标记语言(XML)文档中。
18.如权利要求15所述有形的计算机可读介质，其中所述指令还使得所述移动设备撤销在所述移动设备上注册所述相关联的应用，如果所述接收到的通知指示所述注册终止。
19.如权利要求15所述有形的计算机可读介质，其中所述通知由在所述移动设备上的所述应用接收。
20.如权利要求15所述有形的计算机可读介质，其中所述通知由所述移动设备上的IMS客户端接收，所述MS客户端将所述接收到的通知提供至所述移动设备上的所述相应的应用。`
【文档编号】H04W68/00GK103733701SQ201280019691
【公开日】2014年4月16日 申请日期:2012年2月23日 优先权日:2011年2月23日
【发明者】亚历山德鲁·卡他林·约内斯库 申请人:T移动美国公司