CN1765144B - 预订服务中的方法、网络单元以及消息报头 - Google Patents

Abstract

公开了提供预订服务的方法，该方法包括：建立预订对话以启动预订；当确立所述预订时终结所述预订对话；以及通过下列步骤建立对用户的通知：确定用户的位置；建立通知对话以通知所定位的用户；以及当完成通知时终结所述通知对话。

Description

预订服务中的方法、网络单元以及消息报头

技术领域

所描述的发明涉及预订服务的领域，例如存在服务(presence service)，尤其涉及使用会话发起协议对话的预订服务的支持，但不限于此。

背景技术

通常，在3GPP全IP体系结构中，用户可以对预订服务进行预订。通常使用预订消息来启动预订服务。优选预订消息经常使用SIP(会话发起协议)消息。在检测到预订的事件时，预订服务器通常一般使用通知消息将事件通知用户。在已知系统中，通常通过配置为连接处理服务器(CPS)的代理服务器来帮助预订和/或通知消息。预订通常通过CPS建立SIP对话，并且CPS通常保持该对话并且它通常被用于所有通知。通过这种方式，CPS通常有效记录预订的路由。

在许多实际实现中，CPS可以支持大量预订，并且记录涉及大量预订的大量路由以利于通知的共同必要性可以显著冲击CPS的资源。此外，在许多时间内，通常未使用涉及所记录路由并且在CPS中存储的对话。因此，CPS的容量通常被不活跃对话使用。

3GPP IMS版本6引入出席服务。根据3GPP TS 23.2416.1.0的定义，对于出席服务的预订对话的记录路由通常至少不需存在方(presentity)的服务呼叫状态或会话控制功能(S-CSCF)。预订的“记录路由”通常实际上涉及充当对话的代理服务器、记录预订消息的路由的S-CSCF。更具体地，它一般涉及存储对话详细资料，换句话说，一旦预订被设置便维护对话的代理服务器。维护“记录路由”的代理服务器的常见缺点是它通常利用代理服务器的有限资源。

问题通常在于，根据被访问的服务的类型为代理服务器提供知道何时不适于记录路由以及何时记录路由有利的能力。

因此，本发明的某些实施例的目的是解决一或多个上述问题。

发明内容

基于一个方面，本发明提供了一种提供预订服务的方法，包括：建立预订对话以启动预订；当建立所述预订时终结所述预订对话；以及建立对用户的通知，包括：确定用户的位置；建立通知对话以通知所定位的用户；以及当完成通知时终结所述通知对话。

预订对话以及通知对话可以包括SIP会话。

该方法还可以包括在建立所述预订时存储预订标识符的步骤。

建立对用户的通知的步骤可以响应于所预订事件的出现。

确定用户位置的步骤可以包括发送预订标识符到定位服务功能。

在另一个方面，本发明提供了一种适于提供预订服务的网络单元，该网络单元包括：接收装置，用于从用户接收针对预订服务的预订请求；用于支持用户和预订服务之间的对话会话的装置；以及发送装置，用于向预订服务发送预订请求；其中接收装置还适于从预订服务接收预订确认，并且发送装置还适于向用户传递预订确认，并且其中响应确认，网络单元释放对话会话。

接收装置还适于从用户的预订服务接收通知，其中响应于此建立通知对话会话，发送装置适于发送位置请求以确定用户的位置，其中响应用户的位置信息，发送装置还适于向用户发送通知。

接收装置适于从用户接收所述通知的确认，其中响应所述确认，发送装置发送确认到预订服务并且释放对话会话。

对话可以包括SIP会话。

网络单元还适于在建立所述预订时存储预订标识符。

建立对用户的通知的步骤可响应于所预订事件的出现。

确定用户位置的步骤可以包括发送用户标识符到定位服务功能。

基于另一方面，本发明提供一种用于提供通信系统的通信系统，包括：用户，用于启动预订对话，包含发送预订请求；网络单元，用于接收预订请求并且用于传递预订请求到预订服务；以及预订服务单元，用于从网络单元接收预订请求，并且具有用于存储用户标识符的装置，其中响应来自预订服务单元的确认，网络单元释放预订对话，并且其中响应来自预订单元的通知对话的通知消息，网络单元确定用户的位置并且传递通知消息到用户。

基于另一个方面，本发明可以提供一种设置服务器的方法，包括：接收记录路由指令以及预订请求；以及根据记录路由指令，记录预订请求的路由。

在一个实施例中，在预订请求之前接收记录路由指令。在另一个实施例中，在记录路由指令之前接收预订请求。

记录路由指令可以被获取。记录路由指令可以被接收作为过滤条件的部分。过滤条件可以是特定于服务的。服务可以是出席服务。

记录路由可以被接收作为涉及预订的服务简表的部分。预订可以是SIP会话的消息。服务器可以是代理服务器或提供服务呼叫状态控制功能的服务器。

该方法可以包括建立服务的记录路由指令。

基于另一方面，本发明提供一种预订服务中消息的头，所述头包含记录路由指令，所述指令用于控制网络单元的特征。

在另一个方面，提供了一种提供预订的方法，包括：建立预订对话以启动预订；在所述预订对话中提供过滤条件；以及调整所述过滤条件以包含用于使网络单元有选择地在网络单元上记录预订路由的指令。

网络单元可以是涉及提供所预订服务的服务器的服务呼叫状态或会话控制功能。

本发明还提供了一种用于提供预订服务的网络单元，所述单元适于接收包含记录路由指令的消息，其中响应所述记录路由指令，网络单元有选择地记录涉及所述消息的通信会话的路由。

附图说明

参考附图以便正确理解本发明及其实施例，其中：

图1图解了涉及IETF(互联网工程任务组)例子实现的第一描述实施例的网络情形；

图2图解了IETF实现的第一描述实施例中的信令方案；

图3图解了IETF实现的第一描述实施例中的方法步骤；

图4图解了涉及IMS(IP多媒体子系统)例子实现的第二描述实施例的网络情形；

图5图解了IMS实现的第二描述实施例中的信令方案的综述；

图6图解了涉及第三描述实施例的网络情形；并且

图7图解了第三描述实施例中的信令方案。

具体实施方式

这里参考特定方案通过举例描述了本发明的某些实施例。具体地，这里通过参考两个特定实施例描述了本发明。然而，本发明不限于这种描述的实施例和/或方案。

这里通常参考图1到3描述本发明的第一实施例。图1，2以及3描述了应用于IETF实现的第一实施例。

图1图解了移动通信网络的单元，其中可以实现本发明的第一实施例。在第一实施例中，本发明通常涉及SIP-通知(SIP-NOTIFY)消息路由的执行。例如，通常可以在支持3GPP全IP体系结构的GPRS和/或UMTS通信网络中实现这种消息路由。只示出及描述了理解本发明的这个实施例一般必需的那些单元。本领域技术人员已知网络的完全实现最好具有或必需的其它单元。

网络通常由附图标记102指定。通常给网络102提供无线接入网络104，其提供移动设备对网络访问，例如但不限于用户设备(UE)100。出于理解本发明的第一实施例的目的，示出的网络102包含具有到无线接入网络104的连接116的代理服务器106，具有到代理服务器106的连接112的通知器108，以及具有到代理服务器106的连接114的定位服务器110。示出的单元通常至少是优选的，并且在某些情况下是SIP-通知消息路由所需的。3GPP IMS中的定位服务器的一个实施例是IMR/HSS。在某些实施例中，通知器可以被称作预订服务器。

还通过参考图2的典型信令图以及图3的流程图描述了在IETF实现中的本发明的第一实施例。

在第一步骤302，涉及UE(用户设备)100的用户通常启动对服务的预订。如步骤304所示，预订启动通常建立第一SIP对话。SIP预订(SIPSUBSCRIBE)消息通常被从UE 100发送到代理服务器106。接着SIP预订消息204通常被从代理服务器106发送到预订服务器108。接着，预订服务器108经常把涉及UE 100的用户的公开ID(标识符)存储在其预订服务的预订数据库中。

接着如步骤306所示，由返回所接受的预订消息206到代理服务器106的预订服务器108正常接受预订，代理服务器106接着通常把所接受的预订消息208返回到UE 100。所接受的预订消息是图2中示出的例子中的“202接受的响应”。然而，消息不限于这种格式。例如，所接受的预订消息可以是″200OK″消息响应。因而接受预订。因而，完成预订事务处理以及第一SIP对话。预订的信息被存储在预订服务器108中。

基于本发明的原理，在第一实施例中，如步骤308所示，接着通过代理服务器106释放或终结为预订建立的对话的资源。

应当注意，紧接在所接受的预订消息之后，可能需要发送第一通知消息。在这种情况下，在发送这个第一通知消息之后释放或终结为预订建立的对话是有利的。这是可选特性，其可以根据任何特定实现的需求来实现。例如，可能有其中不需要立即通知消息的实现，在这种情况下维护对话直到第一通知消息是没有好处的。

此后，在步骤310响应所预订事件的检测，预订服务器/通知器108启动UE 100的通知。如第一步骤312，预订服务器/通知器用包含通知请求的新事务处理建立第二对话。预订服务器/通知器108发送通知消息210到代理服务器106，从而识别涉及用户设备100的用户。这个通知消息包括所预订事件的通知。响应于此，在步骤314，代理服务器106发送位置查询消息212到定位服务器110。定位服务器110把具有涉及UE 100的用户的位置的详细资料的位置查询应答214返回到代理服务器106。

接着，代理服务器106发送通知消息216到UE 100。UE把通知确认消息218返回到代理服务器106，其接着把通知确认消息220返回到预订服务器/通知器108。多个通知消息可实际通过代理服务器从用户服务器发送到UE。在步骤316，在终结初始通知事务处理之后，通知事务处理以及通知对话可以被关闭，但也可以继续。

如果准备在近期发送一系列消息，则包含在通知消息中的附加头/参数可以指示代理服务器和预订服务器是否关闭通知对话。这个头/参数最好不与通知消息的现有″预订状态：终结″参数(向UE 100指示终结预订)混合。图3的步骤320示出预订的终结。

当终结通知对话时，到达步骤318。必须在预订的终结之前或与预订的终结相结合来终结通知对话。

从上述能够理解，不要求代理服务器106存储涉及活动会话之外的对话的任何详细资料。一旦预订被建立，代理服务器没有在其中存储用户的详细资料。代理服务器在需要通知时使用定位服务器定位用户。同样地，代理服务器不存储用户的所谓‘路由记录’。在活动对话期间使用代理服务器，但一旦这种对话不再活动，则不存储详细资料。

在图1中，为了简单只示出一个代理服务器。在实际3GPP实现中，会涉及多个代理服务器，作为涉及这种代理的多个呼叫状态或会话控制功能(CSCF)。不存储非活动对话的原理可应用于全部这种代理和CSCF。然而，在某些情况下会期望保持不活跃的对话。

可以以若干方式防止活动会话外的对话的保持。例如：

1.可提供新的或调整的SIP消息，其中在消息中指出代理服务器中需要或不需要保持对话的事实。

2.可向现有预订消息提供附加头，其中头指示代理服务器是否应当在完成预订或通知会话时保持或释放对话。

3.预订消息中的现有SIP头的值可以用于指示代理服务器是否应当在完成预订或通知会话时保持或释放对话。

4.可以在SIP代理中，在IMS实体或非IMS实体中默认自动省略记录路由。这种技术需要单元的调整。

尽管在代理服务器(多个代理服务器)或CSCF(多个CSCF)中释放对话资源，但是预订仍然在预订服务器/通知器中活动。因此在新预订的信息将被提交到用户/用户设备时，预订服务器/通知器以通常方式发送通知消息到预订服务器。因此不必修改预订服务器/通知器。可以发送通知消息以作为正常或单个事务处理。可以使用对通知消息的替代SIP请求。实施例提出只改变在代理或CSCF实体中的对话的保持。

基于本发明的这个实施例，通过访问定位服务器，或其它登记器或位置功能服务来补偿代理服务器(或等效功能实体)释放预订对话的事实，以在需要通知时向代理服务器(或等效功能实体)提供位置。

代理服务器106通常实际上是连接处理服务器(CPS)，用于建立用户设备和预订服务器108之间的对话。基于某些实施例，CPS最好是会话控制子系统的一部分。

本发明的这个第一实施例优选地提供释放代理服务器的资源的显著好处。另外，代理服务器，以及连接处理服务器，通常受到不得不存储对话和/或记录路由的严重限制。

应当注意，参考图1和2描述的本发明的第一实施例是本发明的可能实现的示例性例子。更具体地，例子涉及其中用户预订单个网络中的出席信息的情形。然而应当注意，本发明的第一实施例不限于只是应用于这种网络情形。本发明的第一实施例的原理也可以扩展到其中“观察者”位于出席者的归属网络之外的情形。在这种情形中，预订服务器或通知器108可以直接发送通知消息到观察者的归属网络中的代理，而不是发送到图1的代理服务器106。通知消息最好包含在预订过程期间存储的观察者的身份标识。一旦观察者的归属网络中的代理接收到通知消息，可以对观察者的归属网络中的定位服务器进行查询，并且通知消息的路由最好与本领域已知的正常终结路由一致。

因而，通常，基于结合第一实施例讨论的本发明原理，当通知器产生通知消息时，为通知所预订事件，通知消息被发送到用在预订期间存储的观察者的身份标识指定的目标网络的代理。这个代理可以是观察者的归属网络的代理服务器，并且有能力查找观察者的位置。

在下文的说明中，这个概括被应用于如图解了应用于IMS环境的本发明的第二实施例的图4和5所示的IMS环境。

本发明的第一实施例的原理也可以扩展到其中“观察者”位于出席者的归属网络外的IMS网络中的情形。在这种情形中，预订服务器或通知器108可以直接发送通知消息，或通过代理发送到观察者的归属网络中的代理(而不是发送到图1的代理服务器106)。如图4所示，在IMS情况下，观察者的归属网络中的这个代理可以是入口点代理，例如查询呼叫状态或会话控制功能(I-CSCF)。通知消息最好包含在预订过程期间存储的观察者的身份标识。一旦入口点代理，例如I-CSCF，接收到通知消息，可以对观察者的归属网络中的定位服务器，例如HSS，进行查询，并且通知消息的路由最好与本领域已知的IMS中的正常终结路由一致。

图4图解了移动通信网络的单元，其中可以实现本发明的第二实施例。只示出及描述了理解本发明的这个实施例一般必需的那些单元。本领域技术人员已知网络的完全实现最好或必需的其它单元。图5是进一步图解了第二实施例的各方面的信令图。在图5的信令图中，尚未包含图4的所有网络单元以便降低图的复杂性。图5的信令图和图4的网络实现之间的关系将在下文的说明中变得清楚。

参考图4，通常图解了网络604，即指定网络A，其中UE 606作为出席服务的观察者或用户。进一步图解了网络602，即指定网络B，其作为涉及UE606的观察者所预订到的预订服务提供商的归属网络。

观察者，即UE 606的归属网络包含P-CSCF 608，S-CSCF 610，I-CSCF 612，以及登记器614。出席服务提供商的归属网络602包含预订服务器616，S-CSCF 618，I-CSCF 620以及登记器622。应当注意，每个网络602以及604的登记器622以及614可以分别是定位服务器或归属用户服务器，适于提供与相应网络连接的单元的位置信息。

现在通过进一步参考图4和5来描述本发明的第二实施例。首先转向图4，观察者，即UE 606首先预订涉及预订服务器616的出席服务。

为了实现这个，如图4中信号624所示，UE 606发送预订消息到P-CSCF 608(作为涉及UE 606的P-CSCF)。接着从P-CSCF 608发送预订消息(如信号626所示)到S-CSCF 610，S-CSCF 610作为涉及UE 606的归属S-CSCF。接着S-CSCF 610发送预订消息(如信号628所示)到网络602的I-CSCF 620。本领域已知到预订服务器所位于的网络的I-CSCF的预订消息的发送。同样地，在图5的信号图中，从UE 606到I-CSCF 620的预订消息的发送如单个信号702所示。

再次参考图4，在收到预订消息时，I-CSCF 620发送位置查询消息到登记器622，如信号630所示。

在图5中，位置查询消息被表示成信号704。响应于此，登记器622把位置查询应答返回到I-CSCF 620，如图4的信号632所示。在图5中，位置查询应答被表示成信号706。

登记器622向I-CSCF 620返回S-CSCF身份标识，其可以用于路由预订请求到预订服务器，并且作为S-CSCF 618的身份标识。因此，I-CSCF 620传递预订消息到S-CSCF 618，如信号634所示，其接着传递预订消息到预订服务器616，如信号636所示。参考图5，从I-CSCF 620到预订服务器616的预订消息的发送被表示成单个信号708。

在收到预订消息时，预订服务器616为UE 606登记出席服务，并且UE 606变成预订服务器616的用户。如图5的块726所示，预订服务器616把用户的公开身份标识存储在其预订数据库中。此后，通过与发送预订消息相同的路径把202接受预订消息回送到用户设备606，如图4的信号635，633，627，625以及623所示。

类似于图5，接受预订(Accepted to SUBSRIBE)消息的返回路径通常如信号710以及712所示。

在这个阶段，完成出席服务的预订。基于本发明的技术，为预订而建立的对话被释放或终结。这由图5中的块728表示。

在此后的一些阶段，预订服务器616需要向观察者通知出席活动，并且新对话必须被启动。因此，预订服务器616产生发送到UE 606的通知消息。通过将用户的公开身份标识存储在其数据库中，预订服务器616直接发送通知消息到观察者网络604的I-CSCF 612，如图4中的信号638所示。这类似由图5中的信号714表示的情况。

I-CSCF 612接着发送位置查询信号到登记器614，如信号640所示，其返回位置查询应答到I-CSCF 612，如信号642所示。在图5中，从I-CSCF 612到登记器614的位置查询被表示成信号716，并且位置查询应答被表示成信号718。

此后，I-CSCF 612传递通知消息到S-CSCF 610，其身份标识由登记器614提供。传递到S-CSCF 610的通知消息被表示成图4中的信号644。接着S-CSCF 610传递通知消息到涉及UE 606的P-CSCF 608，其接着传递通知消息到UE 606，如信号648所示。从I-CSCF 612到UE606的通知消息的传递被表示成图5中的单个信号720。

此后，如本领域中所知的，UE 606向预订服务器616确认通知消息的接收。如图5所图解的，UE 606返回200通知OK消息到I-CSCF612，如信号722所示。实际上，此消息跟随返回路径，通过P-CSCF 608以及S-CSCF 610。接着I-CSCF 612传递200通知OK消息到预订服务器616，如图5中的信号724所示。

如图5中的块730所示，接着释放或终结为向观察者提供通知而打开的另一个对话。

因而，通常，基于结合第一实施例讨论的本发明的原理，当通知器产生通知消息时，为通知所预订事件，通知消息被发送到由在预订期间存储的观察者的身份标识指定的目标网络的I-CSCF。I-CSCF可以是观察者的归属网络的代理服务器。

现在参考图6和7描述本发明的第三实施例。

图6图解了移动通信网络的典型单元，其中可以实现本发明的第二实施例。在第二实施例中，本发明通常涉及SIP-预订以及SIP-通知消息路由的执行。可以在支持3GPP全IP体系结构的GPRS或UMTS通信网络中实现这种消息路由。只示出及描述了理解本发明的实施例必需的那些单元。本领域技术人员已知网络的完全实现必需的其它单元。

在参考图1描述的实施例中，描述了一个简单例子，其中用户设备以及预订服务器被连接在共同网络中。在图6的实施例中，示出了一个例子，其中用户设备以及预订服务器(或应用服务器)被连接在不同网络。

参考图6，示出两个网络。第一网络406是涉及观察者的用户设备(UE)402的归属网络(“归属网络#1”)。观察者是通常用于描述出席服务的用户的术语。第二网络404(′归属网络#2′)是出席方的归属网络。出席方通常是用于描述提供出席服务的实体的术语。出席方被表示为在应用服务器(AS)414上运行的出席服务器应用。在所描述的实施例中，通常能够被认为是提供应用服务的应用服务器414提供出席服务，并且可以因此被认为是出席服务器(PS)。

第一归属网络406包含连接到第一代理呼叫状态或会话控制功能(P-CSCF#1)420的无线接入网络418，其接着连接到第一服务呼叫状态或会话控制功能(S-CSCF#1)422。

第二归属网络404还包含无线接入网络416。查询呼叫状态或会话控制功能(I-CSCF)408连接到HSS(归属用户服务器)410以及第二服务呼叫状态或会话控制功能(S-CSCF#2)。第二服务呼叫状态或会话控制功能(S-CSCF#2)连接到应用服务器414。

参考图7的信令图，进一步描述基于第二实施例的本发明的实现。如上文根据出席服务所述可以被认为是观察者(或出席服务的用户)的UE 402发送预订请求消息到应用服务器414。预订请求包含观察者希望预订其出席信息的用户的公开用户身份标识。

预订请求涉及从UE 402向用户的归属网络的P-CSCF#1 420发送SIP-预订消息502，以及从用户的归属网络的P-CSCF#1 420向用户的归属网络的S-CSCF#1 422发送SIP-预订消息504。P-CSCF 420可以位于用户的归属网络中，或用户的归属网络外、所访问网络内，例如在用户在其本国外漫游的情况下。

在S-CSCF#1 422处，基于IP多媒体子系统中ISC接口的路由原理，执行预订的初始过滤条件的评估。

接着，基于将预订其出席信息的用户的公开用户身份标识，经由IMS从用户归属网络的S-CSCF#1 422发送SIP-预订消息506到第二归属网络，即出席方的归属网络的I-CSCF 408。接着，基于所接收的作为对发送到HSS 410的位置查询508的响应的信息，把SIP-预订消息510传递到出席方的归属网络的S-CSCF#2 412。

在接收SIP-预订消息之前，S-CSCF#2 412可以从HSS 410接收观察者想预订其出席信息的用户(出席方)的过滤条件。过滤条件可以包含用户的记录路由信息。因而，在接收预订消息之前，S-CSCF#2最好已经接收用户的记录路由信息。

然而，不是在所有实施例中都要这样。在其它实施例中，特定S-CSCF可以首先接收预订消息，并且然后获取包含在例如过滤条件中的记录路由信息。

在任何情况下，S-CSCF#2 412接收针对观察者想预订其出席信息的用户(出席方)的过滤条件，该过滤条件包含记录路由指令，最好包含在用户简表中。在一个实施例中从HSS 410接收这个。因而，用户的记录路由指令在一实施例中可以存储在HSS中。当由S-CSCF#2412，或更普遍地由代理服务器接收消息时，代理服务器可以选择是否基于所接收的过滤条件实现记录路由。在可选方案中，I-CSCF 408可以获取S-CSCF#2的过滤条件。

在S-CSCF#2 412处，基于所提出的本领域技术人员熟悉的出席服务的技术，实现初始过滤条件的进一步评估。初始过滤条件的进一步评估涉及验证用户的服务简表的S-CSCF#2 412。基于本发明的第二实施例，用户请求的过滤条件适于包含有关在不活动时S-CSCF#2 412是否将建立预订的‘记录路由’项的指示。过滤条件可向S-CSCF#2指示有关预订请求被路由到的应用服务器的情况，但指示不记录路由。

在本领域的出席服务的建议中，已经提出了S-CSCF不必记录路由所有SIP对话建立请求。在出席服务中，具体地，出席方的S-CSCF被有意从出席预订对话中省去以避免S-CSCF的静态分配。由于新事件软件包的不断涌现，保证S-CSCF针对是否记录路由SIP对话进行合理的判定越来越重要。重要的是当有必要这样做时，S-CSCF进行记录路由，但为了最大化系统资源，S-CSCF不必记录路由也是重要的。在S-CSCF充当SIP对话中的SIP代理服务器时，这个问题尤其明显。

因而，在第二实施例中，路由预订消息到应用服务器的S-CSCF#2使用初始过滤条件进行ISC接口上的路由判定。基于本发明原理，初始过滤条件可以扩展为向S-CSCF#2指示有关其记录路由行为的情况。初始过滤条件可以是特定于服务的，因此它是增加有关S-CSCF是否应当记录路由的信息的合适位置。

例如，在出席服务的情况下，在TR 24.841 0.5.0的流6.1.2.1，步骤7中，具有扩展初始过滤条件的行为可以是：

S-CSCF#2验证该用户的服务简表并且评估初始过滤条件。对于sip:user2_public1@home2.net，S-CSCF#2具有终结初始过滤条件，其具有这样的有关服务点，Method＝SUBSCRIBE，并且Event＝′presence′，并且action＝′create Record-Route entry:no′，其通知S-CSCF路由预订请求到应用服务器ps.home2.net并且不建立请求的记录路由项。

S-CSCF#2 412接着传递SIP-预订消息514到应用服务器414。如块516所示，接着如本领域已知的，建立涉及UE 402的用户的观察者授权。

一系列SIP 200OK消息接着遵循相同路由反向回到UE，以指示预订设置的完成：这由消息518，520，522，524，526表示。

此后，应用服务器对用户通知事件。如图7所示，应用服务器直接发送SIP-通知消息532到IMS上的UE归属网络的S-CSCF#1 422，接着S-CSCF#1 422发送SIP-通知消息530到P-CSCF#1，接着P-CSCF#1发送SIP-通知消息528到UE 402。一系列SIP-200OK消息遵循反向路由：这由SIP 200OK消息534，536以及538表示。因而，应用服务器直接发送SIP-通知消息到用户的归属网络的S-CSCF#1，不经由设置和确认预订所经过的路由。

因而，在连接于一个网络(“所连接网络”)的用户预订连接于另一个网络(“服务网络”)的服务提供方的情形下的预订服务实施例中，不要求服务网络中的任何代理或CSCF保留记录路由信息。

服务网络的S-CSCF可以保留或可以不保留记录路由信息。如果记录路由信息不被保留，则从路由通知的路径中撤除S-CSCF#2，即不通过S-CSCF#2路由通知。

在图6的实施例中，在上文描述了S-CSCF#2 412从HSS 410接收观察者想预订其出席信息的用户的过滤条件。此过滤条件可以由HSS410自动提供，或可以从HSS 410检索。在上述实施例中，过滤条件包含指示S-CSCF#2 412是否将记录路由该用户的SIP对话的记录路由指令。

现在描述图6的实施例的此方面的改进，具体地，改进涉及提供给S-CSCF#2 412或在S-CSCF#2 412中设置的过滤条件。在此改进中，除每个用户的用户过滤条件之外，系统过滤条件被引入到IMS中。系统过滤条件不涉及任何特定用户。可在所有情况下提供所有消息的总体系统过滤条件。可选地，可提供应用于特定类型的全部预订，或系统中特定点的所有预订的系统过滤条件。可以存在例如对于UE发起情形，终结注册情形，AS发起情形，终结未注册情形或任何其他情形有所不同的系统过滤条件。上面提出的4个情形在下面定义。

UE发起情形涉及流向用户的归属网络的归属S-CSCF的消息流，其中消息流来自于用户设备，流向代理CSCF(位于所访问的网络或在用户的归属网络中)，流向用户的归属网络的服务CSCF，并且流向应用服务器，或反向的消息流。在图1的方案中，其中用户设备以及应用服务器被连接在相同网络中，所有消息均属于发起情形。在图6中，发起情形涉及第一归属网络406中的消息传送。

终结注册情形涉及应用的归属网络中的消息流，通常从应用的归属网络的查询CSCF，流向应用的归属网络的服务CSCF，并且流向应用服务器，或反向消息流。在图6中，终结情形涉及第二归属网络404中的消息传送。

AS发起情形涉及用户的归属网络中的消息流，其中发起方是应用服务器。消息流从AS流向用户的归属网络的服务CSCF，并且可选地流向另一个应用服务器，或反向消息流。

终结未注册的情形涉及应用的归属网络中的消息流，其中例如用户设备的目标身份标识未被注册。如终结注册情形那样，消息流从应用的归属网络的查询CSCF，流向应用的归属网络的服务CSCF，并且流向应用服务器，或反向消息流。在图4中，终结情形涉及第二归属网络404中的消息流。

系统过滤条件可包含上面提出的针对每个或所有UE和AS发起和终结注册及未注册情形的一或多个系统过滤条件，使得不同系统过滤条件能被用于每种情形。可选地，系统过滤条件可以对一或多个所描述的情形是共同的。

通常，系统过滤条件可以被认为包括涉及运营商的IMS网络中的一或多个S-CSCF的运营商IMS网络的配置数据。

所有系统过滤条件或其部分可以在一或多个S-CSCF上设置，或提供给一或多个S-CSCF，和/或整个系统过滤条件或其部分可以从数据库，和/或从表，和/或从列表，和/或从文件，和/或从对一或多个S-CSCF共同的类似源载入一或多个S-CSCF。任何这种系统过滤条件可以位于一或多个S-CSCF，和/或任何其他网络实体和/或网络中的任何地方。

当在S-CSCF上设置整个系统过滤条件或其部分时，可以在S-CSCF的启动之前和/或之时和/或之后和/或当需要时进行设置。当在S-CSCF上加载整个系统过滤条件或其部分时，可以在S-CSCF的启动之前和/或之时和/或之后和/或当需要时进行加载。

系统过滤条件的使用允许任何特定个别用户过滤条件替换或被替换。例如，可以设置网络使得要求没有任何S-CSCF应当保留记录路由。然而，与特定用户相关的用户过滤条件集可以指示涉及建立对话会话的S-CSCF应当保留记录路由。系统过滤条件集的使用允许这种特定用户过滤条件信息被替换，使得网络保留网络配置的控制。通过另一个例子，可以设置网络使得要求没有任何S-CSCF应当保留记录路由。然而，与特定用户相关的用户过滤条件集可以指示涉及建立对话会话的S-CSCF应当保留记录路由。系统过滤条件集的使用允许默认的定义(即不记录路由)，使得特定用户过滤条件信息可以替换默认。

用户过滤条件可以指定对于出席事件的预订，没有记录路由项应当被建立。这可以在初始用户过滤条件中定义如下(从TR 24.841版本1.0.0子项6.1.2.1取得)：

Method＝SUBSCRIBE并且Event＝′presence′并且action＝′create record-route entry:no′。

为了保证针对每个用户事件没有记录路由被保留，必需在每个用户的每个会话中定义这种用户过滤条件。

作为保证网络中的一致操作的更有效的方式，例如，应用于所有预订出席信息的请求的系统过滤条件可以被定义如下：

Method＝SUBCRIBE并且Event＝′presence′并且action＝′create record-route entry:no′。

此单个系统过滤条件可以作为单个过滤条件在任意一个HSS410，S-CSCF 412或任何其他网络实体或任何数据库中存储和/或设置，但是应用于全部用户会话。此单个系统过滤条件可以存储和/或设置为单个过滤条件，或可以是所存储和/或设置的过滤条件集的一部分。所存储和/或设置的单个系统过滤条件的格式及内容可与用户过滤条件相同或不相同。

这允许简化用户过滤条件。所有想预订出席信息的用户的服务简表中的用户过滤条件可以被简化为例如：

Method＝SUBCRIBE并且Event＝′presence′。

因而，本发明的实施例的这个改进允许在系统过滤条件中只描述一次涉及记录路由是否应当保留的过滤条件的一般功能，因而避免了把它插入到每个单个用户的过滤条件中的需要。有利的是，这节省了HSS中的空间。单个系统过滤条件比大量用户特定过滤条件更易于维护。

在实现系统过滤条件时，也有必要实现用于处理存在于任何特定会话中的系统过滤条件和用户过滤条件之间的任何冲突的优先规则。在这种情形中，该实现可以把两种过滤条件结合成新应用过滤条件，以便系统过滤条件中的数据替换用户过滤条件中的相应数据，或以便用户过滤条件中的数据替换系统过滤条件中的相应数据。接着可以使用新应用过滤条件代替冲突的系统和用户过滤条件。

第一例子实现可以是系统过滤条件替换用户过滤条件的实现。在这个实现中，S-CSCF，例如S-CSCF 412，可以首先评估用户过滤条件。当针对特定用户会话的用户找到匹配时，选出应用该用户过滤条件。

此后，可以作为单个集合来评估系统过滤条件。当针对特定用户会话的系统过滤条件找到匹配时，选出应用该系统过滤条件集。

评估顺序也可以是：首先系统过滤条件，然后用户过滤条件。

如果选出的两种过滤条件，即系统过滤条件集和用户过滤条件集包含相同数据，例如值，参数或类似数据(例如变量，项，列表，数据，字段，表等等)，则系统过滤条件的数据可以替换用户过滤条件中的数据，并且使用系统过滤条件的数据而不是用户过滤条件中的数据。

第二例子实现可以是用户过滤条件替换系统过滤条件。在这个实现中，S-CSCF，例如S-CSCF 412，可以首先评估系统过滤条件。当针对特定用户会话的系统过滤条件找到匹配时，选出应用该系统过滤条件。

此后，可以作为单个集合来主体用户过滤条件。当针对特定用户会话的用户过滤条件找到匹配时，选出应用该用户过滤条件。

评估顺序也可以是：首先用户过滤条件，然后系统过滤条件。

如果选出的两种过滤条件，即系统过滤条件和用户过滤条件包含相同数据，例如值，参数或类似数据(例如变量，项，列表，数据，字段，表等等)，则用户过滤条件的数据可以替换系统过滤条件中的数据，并且使用用户过滤条件的数据而不是系统过滤条件中的数据。

在第三个例子实现中，代替一般优先规则，个别优先规则可以在过滤条件中实现并且在需要它们时使用。例如，系统过滤条件可以包含有关其数据替换用户过滤条件的相应数据或被具有相同优先级的用户过滤条件的相应数据替换的指示。可选地，用户过滤条件可以包含有关其数据替换系统过滤条件的相应数据，或被具有相同优先级的系统过滤条件的相应数据替换的指示。

在第四个例子实现中，可以使用一般和个别优先规则的组合。例如，除了在系统过滤条件或用户过滤条件中明确指定以外，默认情况可以是用户过滤条件的数据替换(或可选地被替换)系统过滤条件的相应数据。

在上述例子中，对于终结用户过滤条件，即终结情形的用户过滤条件，在存在针对不同情形(例如发起以及终结)的分立系统过滤条件的情形下，可以使用用户终结过滤条件以及终结系统过滤条件，即终结情形的系统过滤条件。

对于使用过滤条件的这种规则的修改可以基于网络要求在不同实现中提供。这种规则的各种组合与调整是可能的。

在上面的例子中，为了清楚起见仅示出了过滤条件的必要部分，并且省略了其它部分。

还应当注意，尽管在上述例子中描述了可以提供系统过滤条件和/或用户过滤条件，但是在实施例中，仅可以有利地提供系统过滤条件。例如，如果所有用户预订出席服务，则必要过滤条件可以由系统过滤条件处理，其中不要求提供任何用户过滤条件。

在UE发起情形下，在图6的例子中，在从用户设备到P-CSCF，到S-CSCF，并且到应用服务器的路由中，系统过滤条件可以定义记录路由项必须被插入S-CSCF中，以便S-CSCF可以保留在发起路径中。同时，系统过滤条件可以定义不要求针对终结情形保持记录路由项。

如结合图4和5以及图6和7所讨论的，具有其改进的第二和第三实施例更加普遍地适用于路由预订。它们可以应用于任何路由情形，其中需要针对在S-CSCF中是否保留记录路由信息进行判定。

在上面的实施例中，AS，S-CSCF，P-CSCF和I-CSCF是SIP代理服务器的例子。

本发明的某些实施例已经在这里用举例的方式加以描述。本领域技术人员将理解，本发明的适用性不限于这些实施例。由所附权利要求书定义本发明的保护范围。

Claims (29)

1.一种设置网络单元的方法，包括：

接收用于预订服务的预订请求；

接收指令以记录与所述预订请求相关的通信会话的路由，所述指令是过滤条件的一部分；

基于记录所述路由的指令，选择性地记录预订请求的路由。

2.如权利要求1所述的方法，其中获取记录路由的所述指令。

3.如权利要求1所述的方法，其中所述过滤条件是系统过滤条件。

4.如权利要求3所述的方法，其中为所有用户设置系统过滤条件。

5.如权利要求3所述的方法，其中在网络单元中预先设置系统过滤条件。

6.如权利要求3所述的方法，其中从另一个网络单元把系统过滤条件载入网络单元。

7.如权利要求6所述的方法，其中另一个网络单元包含归属用户服务器(410)、服务呼叫状态或会话控制功能(412)或数据库之一。

8.如权利要求3所述的方法，其中过滤条件还包含用户特定过滤条件。

9.如权利要求8所述的方法，其中如果用户特定过滤条件匹配系统过滤条件，则使用系统过滤条件和用户特定过滤条件两者的组合。

10.如权利要求9所述的方法，其中系统过滤条件数据替换用户特定过滤条件数据。

11.如权利要求9所述的方法，其中用户特定过滤条件数据替换系统过滤条件数据。

12.如权利要求1所述的方法，其中任何过滤条件是特定于服务的。

13.如权利要求12所述的方法，其中服务是存在服务。

14.如权利要求3所述的方法，其中接收记录所述路由的指令以作为涉及预订的服务简表的一部分。

15.如权利要求1所述的方法，其中预订请求是会话发起协议会话的消息。

16.如权利要求1所述的方法，其中网络单元是代理服务器或提供服务呼叫状态控制功能或服务呼叫会话控制功能的服务器。

17.如权利要求15所述的方法，其中所述消息包括报头，所述报头包含用以记录路由的指令，所述指令用于控制网络单元的特征。

18.一种设置网络单元的设备，包括：

接收用于预订服务的预订请求的装置；

接收指令以记录与所述预订请求相关的通信会话的路由的装置，所述指令是过滤条件的一部分，以及

基于记录所述路由的指令，选择性地记录预订请求的路由的装置。

19.如权利要求18所述的设备，其中所述过滤条件是系统过滤条件。

20.如权利要求19所述的设备，其中从网络实体和/或数据库接收系统过滤条件。

21.如权利要求19所述的设备，其中在所述设备中设置系统过滤条件。

22.如权利要求19所述的设备，其中所述系统过滤条件被应用于全部用户消息。

23.如权利要求18所述的设备，其中所述设备还包括接收用户特定过滤条件的装置。

24.如权利要求18所述的设备，其中如果用户特定过滤条件匹配系统过滤条件，则使用两个过滤条件的组合。

25.如权利要求24所述的设备，其中系统过滤条件数据替换用户过滤条件数据。

26.如权利要求24所述的设备，其中用户过滤条件数据替换系统过滤条件数据。

27.如权利要求18所述的设备，其中所述设备包括服务呼叫状态或会话控制功能。

28.如权利要求18所述的设备，其中从归属用户服务器接收用以记录路由的指令。

29.一种通信系统，包括根据如权利要求18至28中任一权利要求所述的设备。

Images