CN1329798A - 程序的下载用于在通信网内执行程序的方法和系统 - Google Patents

Abstract

本发明涉及在通信系统内的通信装置中,特别是智能网(IN)节点中有选择地和分布式执行一个或多个程序、及其成分或数据的方法。在通信网节点内执行程序之前,要先检验该程序和/或者数据是否应该被分布,以及哪个程序或程序模块或数据应该被分布。

Description

程序的下载 用于在通信网内执行程序的方法和系统

本发明总体涉及对通信系统的通信装置内，特别是智能网(IN)节点内的一个或多个程序或其模块进行最优化和分布式执行的方法。

除了单纯的业务交换(例如呼叫或传真消息)之外，电信网用户还不断要求提供用户指定的附加业务，即所谓的增值业务，这已经超出了网络的正常交换功能。

鉴于在过去，这种业务只能是单一网络制造商或网络运营商的专有解决方案，所以90年代初智能网的首次引入为网络和业务提供商提供了开放的接口。从而有可能为用户提供更多种类和更加灵活的附加业务。

ITU的Q.1200系列规范中借助IN概念模型(INCM)来描述IN标准，其结构被分为四个平面，每一个平面都抽象出IN网络的一个方面，其中包括业务平面、全局功能平面、分布功能平面和物理平面。

分布功能平面就功能以及功能之间的流来描述IN网的结构，如图1所示。其中虚线表示业务连接，而其它实线表示信令连接(这也同样适用于图2和图3)。功能中包括功能实体和数据，它们可以被全局功能平面(GFP)内的实体使用或接入(参见图6)。分布功能平面(DFP)的描述独立于这些功能、其功能实体或数据在网络中如何物理地实施和在哪里实施。

原则上讲，一个IN呼叫(包括语音或数据)按如下方式在分布功能平面上工作：

接收到来自用户的呼叫建立消息或者业务请求消息之后(例如“摘机”指示或者拨号)，呼叫控制代理功能CCAF会把该消息传递到呼叫控制功能CCF以及业务交换功能SSF。然后这两种功能实体处理该请求消息，并且根据特定准则和条件去判定该请求是不是对IN所支持业务的请求。如果是，该请求消息以及相关信息(例如检测到该请求的时间)还会进一步被传递到业务控制功能SCF。然后业务控制功能SCF根据例如请求的类型，随后要执行的主叫或者被叫的操作去识别适当的业务逻辑。在业务执行期间，业务控制功能SCF可以与用于检索附加数据的业务数据功能SDF、业务资源功能SRF或者所谓的CCF/SSF(呼叫控制功能/业务交换功能)功能交互作用以便为用户提供服务。

这种IN业务的一个实例可以是“呼叫转移”业务。在此，业务控制功能SCF判定要把呼叫转移到哪个号码上，把此结果通知给CCF/SSF功能，然后由后者把呼叫定向到新号码上。

另外一个实例是语音时钟，其中在CCF/SSF与业务控制功能SCF联系之后，SCF检测到用户想要得知一天中的时间，故业务控制功能SCF向业务资源功能SRF发送信令，然后再由SRF向用户发送提示音。

应该注意的是，业务控制功能SCF和CCF/SSF之间的连接、业务控制功能SCF和业务数据功能SDF之间的连接以及业务控制功能SCF和业务资源功能SRF之间的连接都只是信令连接，这就意味着通过这些连接是承载呼叫控制信号，而不是承载呼叫本身。

这里给出了一个简单的IN呼叫实例，其中仅仅与业务控制功能SCF进行一次联系。然而多数情况下，呼叫过程中与业务控制功能SCF以及SCF内的各个功能实体要进行多次联系。总之，在IN标准中都是采用描述呼叫序列和状态的所谓呼叫状态模型来描述呼叫的发起和终止。在这种呼叫状态模型中，当达到呼叫的特定状态时(即呼叫处理可以被停止并且必须要联系外部业务控制功能的呼叫状态)，由多个所谓的检测点定义所必须要执行的动作。然后业务控制功能判定例如如何继续进行呼叫、执行其它软件或者与用户或多个用户进行交互工作。根据业务或其它因素，业务控制功能或其自己的功能实体之一通常要与其它功能或功能实体进行多次联系。

分布功能平面的真正物理实施要在物理平面上进行，如图2所示。该平面中可以实现：把所描述的功能、其功能实体以及数据分布到多个节点中(见图3)，并且在7号信令系统网络(SS#7)上，通过智能网应用规程(INAP)进行它们之间的通信。物理平面的结构如下：

业务交换点SSP是能够检测IN业务的改进型交换节点。因此业务交换点SSP至少包括CCF/SSF功能。也可以有选择地包含业务资源功能SRF、业务数据功能SDF以及业务控制功能SCF的功能性。

业务控制点SCP负责业务控制，并且可以包含业务控制功能SCF和业务数据功能SDF的功能性。SCP中还包括若干用于执行IN业务的业务逻辑程序SLP以及数据。业务控制点SCP能够直接或者通过信令网访问业务数据点SDP内的数据，SDP内包括业务数据功能SDF的功能性。业务数据点SDP可以与业务控制点SCP处于同一个网络之中，也可以处于其它网络之中。

智能外设(IP)控制并且表示特定的资源，例如数字集、提示音、语音合成或语音识别等。其中包括交换矩阵，实现用户与这些资源的连接。它可以包含业务资源功能SRF的功能性，并且受业务控制点SCP的控制。

附加设备AD物理实体在功能上等效于业务控制点SCP(即包含相同的功能)，但它是直接连接到业务交换点SSP。附加设备AD与业务交换点SSP之间的通信可以由高速接口支持，这样就可以得到更好的性能特征。从内容上讲，应用层消息等同于由信令网承载到达业务控制点SCP的消息。

提高性能的另外一种可能性是把业务交换点SSP和业务控制点SCP组合成一个节点业务交换控制点(SSCP)。业务交换控制点节点的内部功能之间的连接通常都是专用的，并且其之间的联系也是很紧密的，但是它可以提供与业务交换点和业务控制点单独工作时相同的业务能力。物理平面内的业务交换控制点和其它节点之间的接口等同于物理平面内的业务交换点和其它节点之间的接口。

在IN概念模型的最高层(业务平面SP)中对IN业务进行了描述。业务平面表示了专门的面向业务的概观，并且从用户的角度出发来描述业务。此概观中不包括有关业务在网络中实施的信息。在业务平面上，IN业务的特点在于具备一个或多个核心业务特征，并且它也可以有选择地由其它业务特征增强。业务特征SF1、SF2、…SF5是能够与其它业务或者业务特征联合使用的特定业务方面。它可以是业务的核心部分也可以是提供做为业务增强的可选部分。

全局功能平面GFP内对业务和业务特征进行了定义，见图6。

该平面内包括被称为为业务无关构件(随后采用SIB命名)的业务功能单元，这些单元的描述独立于功能在网络中的分布方式。SIB是可以被重复使用的，即若干个IN业务特征可以使用相同的SIB。这也就意味着SIB独立于其所用于的业务或者业务特征。它们不知道以前或者随后将要用于描述业务(特征)的SIB。这样，网络运营商能够定义一组必需的SIB，例如包括用于呼叫处理、收费或者用户交互的SIB(见图中给出的实例)。然后业务提供商能够利用这种预定的SIB来开发其新业务。

通过提供带有数据参数的SIB可以实现业务相关性，这些参数使得可以设计SIB去执行期望的功能，并且因此可以为每个SIB独立地规定参数。要求每个SIB都具备两种数据参数：被称为呼叫实例数据(CID)的动态参数和被称为业务支撑数据(SSD)的静态参数。

呼叫实例数据定义动态参数，其取值可以随每个呼叫进行变化。这些参数被用于规定例如主叫或被叫线路信息的有关主叫或被叫的特定细节。该数据或者可以从基本呼叫处理(BCP)SIB中得到(例如主叫线路识别)，或者由SIB生成(例如转换号码)，或者由用户输入(例如被叫号码或PIN码)。

业务支撑数据定义SIB所要求的数据参数，这些参数专用于业务特征描述。当业务描述的全局业务逻辑GSL中包括SIB时，该全局业务逻辑GSL会规定业务支持数据的取值，即所谓的用于SIB的SSD。SSD中包括固定参数，对于所有呼叫实例来说，这些数据参数的取值是固定的。该SSD还包括域指针。域指针对SIB所要求的呼叫实例数据进行标识，并且在进行该操作时，为该数据提供逻辑定位。

业务和业务特征的实施实际上是在全局业务逻辑中实现的，在GSL中(例如脚本)定义SIB的链接顺序，以及必须触发SIB的时刻。这种GSL的操作、调用甚至生成都是根据特定SIB(基本呼叫处理(BCP)SIB)来进行的。这种特定SIB管理呼叫处理，并且通过起始点(POI)和返回点(POR)控制GSL，其中提供从基本呼叫处理到全局业务逻辑的接口。因此，基本呼叫处理SIB的存在可以被看作是执行IN业务所必须的。

某些全局业务逻辑脚本可以是静态的，在使用期限中保持不变。然而如下情况也是很普遍的，即对于每个单个呼叫来说，全局业务逻辑GSL或其中一部分是唯一的，并且要动态地生成去适应例如主叫或被叫。因此全局业务逻辑GSL内必须要包含SIB及其之间的逻辑连接，以及输入输出数据参数，为每个SIB所定义的业务支撑数据和呼叫实例数据，以便使SIB适应于各自的业务，甚至如上所述动态地适应于当前呼叫。

基于这些通用单元的功能，全局业务逻辑把这些单元链接在一起，提供特定业务。

如图6所示，SIB本身使用或者访问功能的一个或多个功能实体或数据，例如分布功能平面DFP内的SCF、SSF或SDF。这些功能中的一部分就是所谓的功能实体，图中采用三角符号来标注。此外虚线箭头表示一个指针，其它箭头表示信息流。

智能网不仅能够在固定网络中得到实现，还能够在例如全球移动通信网络(GSM)的移动通信网络中实现。在GSM网内，IN概念是连同CAMEL(移动网增强逻辑客户化应用)业务一起被引入的。固定智能网与GSM内CAMEL业务之间的主要区别在于：在CAMEL中，业务交换点(SSP)总是与用户归属网络的业务控制点(SCP)进行通信。这样的一个实例就是：归属网络在法国境内的用户当前在挪威境内的网络中注册，在这种情况中，挪威境内的SSP要与法国境内归属网络的SCP进行通信。

总之IN概念模型INCM利用GSL脚本和配有标准化接口的SIB，可以提供灵活的、与实施无关的业务定义，而不必了解真正的业务实施和位置。

例如SCF功能性可以位于多个节点内，其中包括SCP、SSP、SSCP或者AD。把业务逻辑或SIB放置在中央SCP中，会使得业务的生成、更新和管理都相对简单。然而这样做的缺点在于：所有的消息必须要经过SS7网络来进行传送，由于需要一段时间来对每个信号进行处理，所以这样做通常会导致SS7网络的负荷较高和/或者业务性能变差。

直接在业务交换控制点(称做SSCP)、业务交换点(称做SSP)或者附加设备(AD)中执行业务逻辑或者SIB，可以由于SSF与SCF之间的信令已经在SSCP、SSP或者专用SSP/AP接口中进行处理而减轻SS7网的负荷，而且还会使传送速度更快。然而这种解决方案的缺点是：业务的生成、更新和管理都变得复杂，还可能为只位于SCP内的功能引入附加信令。

从上述的描述中可以看到，智能网内功能性和数据的定位，对于资源的有效使用以及良好的业务性能都是十分关键的。

业务脚本或SIB，或者其中部分业务脚本或SIB，或者功能实体的定位通常都在业务生成阶段进行规定，一般在随后不再更改。特别是在CAMEL中，业务总是在用户归属网内的SCP中得到执行。然而最佳定位要取决于很多影响因素，而且不太可能在业务生成期间对此进行预测。这样的结果就是：业务脚本或SIB，或者其中部分业务脚本或SIB，或者功能实体的定位通常都不是最佳的，这样就会导致网络资源的负担过重，并且/或者导致业务性能较差(例如由于延迟的呼叫建立，或者由于额外的成本)。特别是在CAMEL中，SCP与SSP间的距离较远时，会导致信令路径非常长，由此所带来的结果就是业务性能比较差。

对于通常由业务数据功能(SDF)所管理的业务相关数据的定位也存在类似的问题。SDF功能也可以被定位于若干个节点中，而且数据的最佳定位对业务性能来说也是十分关键的。

因此本发明的目的在于提供一种方法和系统，去控制业务或程序以这样一种方式运行，使得能够实现资源的有效利用，并且可以达到足够高的业务性能。

上述提到的问题可以根据权利要求1中的方法以及权利要求15中的系统得到解决。

基本上根据本发明的一个方面，要对执行程序所请求的连接进行检验，而且程序或其成分和/或数据在若干节点间的分布要依赖于此。

根据本发明的另一个方面，数据不能够立即从连接本身获得，而是从存储装置中获得这些数据进行检验。

本发明的另外一个方面在于收集有关程序执行的统计数据，把数据存在该存储装置中，并且还利用这个数据去判定程序数据的最佳分布。

本发明的好处在于：可以对程序、程序成分或其它数据进行灵活和自适应地分布，这样可以有效地使用网络资源，并且能够提高业务质量。对统计数据进行附加收集和校验，可以对所选择的分布进行分析，将其与前一次选择进行比较，以及检验所选择的分布是否是最佳分布。

随后进一步通过实例，以及参考附图来描述本发明。随后的附图给出：

图1：智能网(IN)的分布功能平面(DFP)，描述各种IN功能之间的合作，

图2：智能网物理平面(PP)，概述物理实体及其连接，

图3：给出PP的节点内DFP的功能定位的可能性，

图4：能够实现程序数据最佳分布的本发明的基本消息流程，

图5：带有统计信息的附加评估和收集的本发明的基本消息流程，

图6：从其业务平面的描述到分布功能平面的实施，给出IN业务的通用分解框图。

随后，参考多个实施例来进一步描述本发明。

下面根据图4进一步描述本发明，其中给出本发明的一系列步骤。

在第一步骤1中，智能网用户执行动作，该动作被呼叫控制代理功能CCAF检测到。这种动作可以例如是拨号或者摘机动作。如果用户动作满足预定的要求，则在步骤2把该动作转移到呼叫控制功能CCF。在其它情况中，用户的动作可以只由呼叫控制代理功能CCAF进行处理。在步骤3，由呼叫控制功能CCF检测用户动作是否需要附加的IN业务，并且在步骤4查询业务控制功能SCF。通常不是所有的动作都需要调用IN业务。一种条件可以是已拨打特殊号码(例如以0800或0130开头的号码)或者主叫号码(A-号码)属于特定用户(例如特殊需要的用户)。

根据为特定业务而存在的所谓检测点(DP)的定义，在进行呼叫的过程中，也能够启用IN业务或者继续已经启用的IN业务。这种情况下，步骤1不再表示用户的初始动作，而是表示检测点所定义的用户动作，它可以导致对业务控制功能SCF进行查询。

在业务控制功能SCF开始执行业务或者继续执行业务之前(步骤9)，它在步骤5中要判定业务和连接的特征，并且在步骤7中计算整个业务的最佳分布，包括业务脚本或者一个或多个组件和/或业务相关数据。最终在步骤8a，b，c中，分布业务组件，而且在这种情况中，也对数据进行分布，在步骤8b业务数据功能SDF得到有关通知，并且在步骤8c对数据进行分布。此后在步骤9中执行业务。

基本上，分布判定可以分为两步：第一步去判定是否需要进行分布，第二步判定如何进行分布。可以对整个业务进行判定，也可以只对其中一个单元(例如部分脚本、部分SIB或数据)进行判定。在第一迭代中，检验对业务进行分布是否有意义，而在随后的迭代中决定是否以及如何对业务的各个单元进行分布。可以基于各种因素来决定是否并且如何分布业务，这些因素对于业务行为的影响不是等价的。

表1就是第一迭代的实例，其中在业务平面(SP)层决定是否进行分布：

影响因素	重要性	点数	总体权重
				分布可能吗？(0＝是，-1＝否)	100	0	0
SIB数量	2	4	8
				外部信令数量	6	2	12
特定处理器能力	3	-3	-9
				用户交互数量	1	7	7
…

        表1 SP层业务性能影响因素及其权重的实例

表中的“重要性”一栏指示各种因素的影响：例如“业务特征数量”因素的重要性就要低于“内部信令数量”因素的重要性。“点数”一栏描述业务或组件的影响因素的实际高度：“用户交互数量”要相对大一些，而“外部信令数量”要低一些。最后考虑重要性与点数，可以得到业务或其单元影响因素的整体权重。例如可以通过把两个数值相乘得到权重值，但是也可以采用其它的计算方法。这一层上的某些影响因素也可以从其它层推导得到。例如“信令数量”这一项可以通过把较低层内(例如全局功能平面GFP层)所有单元的信令数量相加得到。

决定业务是否进行分布的准则可以是所有影响因素的总体权重值。这样的结果是，可以决定分布全体业务，或是只对其中部分业务进行分布。

下一迭代中的这种决定可以再一次基于对业务组件影响因素的评估。

表2给出业务脚本或者部分业务脚本的分布影响因素的实例

分布可能吗？(0＝是，-1＝否)	100	0	0
				脚本长度	2	4	8
SIB数量	6	2	12
				相关数据定位	8	1	8
相关SIB定位	8	2	16
				可能复制并且执行所有包含的SIB吗？	9	2	-18
可能复制相关数据吗？	4	3	12
				SSP的能力	8	3	24
检测点(DP)的数量	5	5	25
				SDP和SCP之间的信令数量	1	3	7
SSP和SCP之间的信令数量	8	4	32
				SCP<->SDP的距离	3	5	15
SCP<->SSP的距离	7	6	42
				…

表2用于业务脚本(GSL)或其一部分的业务性能影响因素的实例

这里假设在外部业务控制点SCP内能够正常完整地执行业务脚本，而且必须从外部业务数据点SDP中检索数据。业务脚本的正常执行会导致业务控制点SCP和业务交换点SSP之间的信令数量较大。而且SCP和SSP之间的距离也比较大。因此对业务脚本进行分布，例如将其下载到业务交换点SSP节点中，是非常有用的。该脚本可以被完整地下载或者只下载其中部分业务脚本，而其余部分仍然留在业务控制点SCP中。对每一部分脚本都执行相同或类似的重复操作，然后对哪一部分需要下载做出决定。

表3中列出了某些示范影响因素，以及它们如何对业务行为造成影响。如果业务脚本或者部分业务脚本根本不能在远端节点(这里指业务交换点SSP)中执行，则业务脚本或部分业务脚本不被下载。造成这种状况的一个可能原因就是，远端节点没有执行脚本的能力。另一个原因在于脚本所使用的所有或某些SIB不能被下载，必须保留在业务控制点SCP中，从而导致需要过多的信令。

在某些情况中，也可以禁止把业务脚本或者任何其它单元下载到远端节点，例如不允许在一个节点(例如这些节点可以是一个国家内的业务交换点SSP或业务数据点SDP)和另一个节点(例如另一个国家的业务控制点SCP)之间传送数据。在这种情况中，可以把脚本或其中部分脚本从一个国家的SCP中下载到另一个国家的SSP中，并且在该国家中执行该脚本，这样做也是有意义的。

影响因素	影响情况
		分布可能吗？	如果根本不可能进行分布，则不再进一步查询
脚本长度	较长的脚本意味着较重的信令负担
		SIB数量	高SIB数量＝信令数量的指示
可能复制相关数据吗？	不能复制会导致较重的信令
		SSP能力	SSP有可能执行程序(模块)吗？
检测点(DP)的数量	高DP数量＝信令数量的指示
		SDP<->SCP的信令数量	指示对程序(模块)相关数据进行分布是否有意义
SSP<->SCP的信令数量	大量的信令通常是在SCP内本地执行业务的原因
		SCP<->SSP距离	距离越大，则本地执行业务通常更加有意义

                表3业务性能影响因素的描述

而且影响因素可以表示是否应该为可能的分布对组件进行额外地检测，并且哪些组件应该被检测。例如如果业务控制点SCP和业务数据点SDP之间的信令数量很大，则也对相关数据的分布进行检测是有意义的。

业务及其单元的点数可以与业务或单元一起存储，但也可以在业务将要被执行时动态地得到。如果业务不是静态的而是要动态地取决于若干其它环境因素(例如根据用户类型、用户的当前定位、服务网络节点的定位、能力或负荷)，则后面的一种获得方式是特别有用的。在某些情况中，技术上(例如由于节点内的负荷过重)可能暂时不能执行远端节点内的业务或业务组件。而且组件的行为可以取决于其所用于的业务类型，例如SIB是与业务无关的，并且通过业务支撑数据和呼叫实例数据变为业务特定的。

在本发明的另一方面中，检验程序数据是否已经存在于程序数据预计被发送到的节点中。也可能程序数据没有以出完全相同的形式存在，但是它由通信装置中的一个或多个功能来表示或模仿。可以提供通用功能库或者宏去支持业务脚本，例如通过提供要下载到远端节点中或者在远端节点中执行的必需功能来实现。某些程序数据已经存在或者可以在其它节点中提供/模仿的情况可以有助于决定业务是否应该被分布。

在这种情况中，能够决定不向远端节点发送已经存在的程序数据，这样可以减轻网络的负担。然而在其它情况中，尽管程序数据已经存在于节点中，但发送程序数据也是有意义的，例如在有更新的程序数据或者有其新版本时去覆盖重写已经存在的程序数据。

本发明的另外一个方面是检验程序数据是否已经存在于通信装置中，这是要把程序数据分布到通信装置时所需要做的。而且还可以检验是否能够把所需要的程序数据分布到此通信装置，或者通信装置中是否存在与所需的程序数据相对应的功能。

在不能满足上述准则之一的情况中，可以决定不对程序数据进行分布，或者首先检验所需的程序数据是否能够被分布。

本发明的另外一个方面就是，数据在被发送到节点之前要先经过转换。例如每个业务脚本都是由关键单元组成。这些关键单元都是通过每种普通编程语言可知的基本逻辑语句或者脚本流程控制语句。由于关键单元的种类是有限的，所以可以采用例如一个八位字节去表示一个关键单元。这样可以允许通过两个节点之间的接口(例如业务控制点SCP和业务交换点SSP之间所谓的TCAP接口)传递更长并且更复杂的业务脚本。在其它情况中，转换程序数据以便满足程序数据将要被发送到的节点的要求，是有用的。例如脚本可以从一种语言被转化为另外一种语言，使得其它节点内的脚本翻译器可以理解它。另一个实例是把数据从一种数据格式转化为另外一种格式。如果业务脚本可以被分布到其它节点中，并且可以在其它节点(例如呼叫处理节点)中执行，则可以采用功能更强的指令以及通过对库函数和宏的调用，使得业务脚本得到增强。

还根据本发明的一个方面，除了对面向连接的数据进行分析之外，还要采用从存储装置内检索或者通过向节点发送询问得到的附加数据去判定数据的最佳分布(步骤6a，b)。不是所有被分析用于判定最佳数据分布的信息都是可以立即得到的，而且某些信息必须要通过额外的询问进行检索。这种情况可以是例如有关各种节点能力、其当前负荷或者信令网络当前负荷的信息。

决定程序数据的最佳分布之后的步骤就是要执行这种分布方法，即在步骤8a执行程序模块的分布，或者在程序执行期间可以在步骤8b和8c中执行所需的数据分布。

程序模块分布的复杂性在很大程度上要取决于必须要被分布的程序模块数量，以及所涉及的层或平面。在简单情况中，只有业务脚本或部分业务脚本要被分布。例如，如果业务脚本不包括SIB的参考，或者如果所需要的SIB也存在于远端节点中，或者如果所需要的SIB也可以得到功能库或宏的支持，则这种业务脚本可以很容易地被例如从业务控制点SCP分布(即下载到远端节点)到业务交换点SSP，并且在该节点中执行。在只能下载部分业务脚本的情况中，可以向相关节点(例如SCP)进行查询，以获得进一步的信息。这样可能把大量的业务相关数据保留在原始节点中(例如SCP)，而不必将其下载到远端节点中(例如SSP)。这种只下载部分业务脚本的实例就是这种业务，即：部分业务用于管理用户的交互，而另一部分随后处理所接收的数据。对于这种业务来说，把那些负责用户交互的业务部分下载到SSP以减少到SCP的信令，而把对数据进行处理的部分留在SCP中，是有意义的。

在更复杂的情况中，还要对SIB和/或者其组件进行分布。这些可以在处理SIB或其组件的各个平面中进行。

在必须对业务数据功能所管理的数据进行分布的情况下，在步骤8b中把消息发送到业务数据功能，然后在步骤8c中业务数据功能对该数据进行分布。

本发明的另一个方面就是收集统计信息，并且在存储装置中存储这些信息，以供随后使用，例如用于判定程序数据的最佳分布，见图5中步骤11-13的描述。

通常情况下，由于影响因素的点数是根据例如用户行为而定的，所以它是不能预测的。这种情况中，可以在一个或多个用户执行一个或多个业务的期间来收集统计信息，以便得到影响因素点数的典型数值。

在其它情况中，不是所有的影响因素或者其相互依赖性都是已知的。这样的结果就是根本不能通过解决最优化问题来得到最佳分布，而必须要通过经验调查来获得最佳分布。而且这里对于统计信息的收集也能够证明：对于特定性能目标(例如信令量低或者执行速度快或者两者兼而有之)，被选中的程序数据分布是否最佳。

也可能在业务执行之前不导出程序数据的最佳分布。这样的原因在于，导出过程要花费时间，并且其本身就会降低业务的性能。这种情况中可以检验已经被存储的统计数据，查看其中是否包括相同或相似的情形，例如可以选择该情形的相同用户以及以前得到的程序数据分布。一般而言，对若干情形的一组最佳分布可以被保存在数据库中，以减小导出最佳分布所需要的时间。

典型的统计信息可以包括：业务自身的数据、用户、被选中的分布、实现被选中分布所需要的信令数量、执行期间的信令数量或者执行时间。

在步骤11开始收集统计信息。当然在分布决定期间就可以开始进行这种收集。在步骤13，统计信息被存储在存储装置中(这里由业务数据功能SDF来表示)。此外在中间步骤12中，当前统计数据与以前的统计数据进行比较，然后在存储装置中存储比较所得到的修正统计数据。这样可以保证，只有统计数据的当前最佳分布被存储在存储装置中。

本发明的另一个方面在于，需要在两个或多个节点中(例如从业务控制点SCP到业务交换点SSP)分布的程序数据在业务被执行完之后要被保存在这些节点中。

对程序数据进行缓存的优点在于：在随后的业务执行期间，不必再次发送这些数据，这样当第二次执行该业务时，会使得网络的负荷进一步降低。为了防止节点内由于程序数据过多而造成溢出，在一段时间之后删除某些被缓存的程序数据是有用的。判定哪些被缓存的程序数据要被删除可以基于多种准则，例如根据其大小，在特定时间段内被使用的次数，或者距离上次其被使用已经经过的时间。

尽管本发明主要通过其在智能网中的用途来描述的，但并不局限于这种网络。一般地，本发明可以被用于所有允许在多于一个节点内执行程序或者存储程序数据的通信网络中。

随后将进一步描述根据权利要求11的通信系统(无图)。通信系统内包括至少两个通信装置。该通信装置包括用于建立第一和第二通信装置之间连接的装置，以及对连接进行分析或者分析与连接相关的数据的装置。还提供用于根据该分析在通信系统内的两个或多个通信装置之间发送程序数据的装置。

此外还可以预见到用于检验通信装置内的程序数据的装置。这些用于检验程序数据的装置检验在通信装置中是否已经存在将要被发送到该通信装置内的特定程序数据或功能或者部分特定程序数据或功能。

程序数据可以是部分业务脚本或者业务脚本，它们也可以是执行业务所需要的一个或多个与业务无关的构件(SIB)或数据。

根据优选实施例，在发送程序数据之前对数据进行转换的转换装置是该装置的一部分。这也同样适用于存储收集到的统计数据的存储装置，这些数据可以在随后进行评估和存储。

智能网(IN)内，第一通信装置的实例是业务交换点，第二通信装置的实例是业务控制点。

Claims (16)

1.一种用于在通信系统中执行程序的方法，包括步骤：

-建立通信系统中第一和第二通信装置之间的连接，

-分析该连接或与连接相关的数据，

-在发送程序数据之前检验：在该程序数据将要被发送到的通信装置中是否已经存在了所请求的程序数据，或者通信装置中是否包括对应于该程序数据的功能，以及

-根据该分析以及该检验结果，在通信网中至少两个通信装置之间发送程序数据。

2.根据权利要求1的方法，其中

在向第一通信装置发送第一程序数据之前，检验该第一程序数据所需要的第二程序数据是否已经存在于或者能被分布到该第一程序数据将要被发送到的第一通信装置中，或者检验该第一通信装置是否包括对应于该第二程序数据的功能。

3.根据权利要求1到2之一的方法，其中

程序数据在被发送到一个或多个通信装置之前，要先经过转换。

4.根据权利要求1到3之一的方法，其中

除了分析与连接相关的数据之外，也要对附加数据进行检索和分析。

5.根据上述权利要求之一的方法，其中

程序数据是一个或多个程序的成分。

6.根据上述权利要求之一的方法，其中

在所接收程序数据的帮助下，在各个通信装置中执行程序。

7.根据权利要求6的方法，其中

在该通信装置之一中所执行的程序建立与其它通信装置的连接，并且通过这一连接发送程序相关数据。

8.根据权利要求4的方法，其中

收集统计数据，并且在存储装置中存储该数据。

9.根据上述权利要求之一的方法，其中

向一个或者多个通信装置发送程序数据之后，以及在该程序数据的帮助下执行完该程序之后，该程序数据被保存在该通信装置中。

10.根据权利要求8的方法，其中

与连接相关的数据是与通信网内一个或者多个用户有关的数据。

11.一种包括至少两个通信装置的通信系统，它包括：

用于建立第一和第二通信装置之间连接的装置；

用于分析连接或与连接相关的数据的装置；

用于检验特定程序数据或功能或者部分特定数据或功能是否已经存在于该通信装置中的装置；

用于根据该分析在通信网内两个或多个通信装置之间发送程序数据的装置。

12.根据权利要求的通信系统，包括

在程序数据被发送之前对其进行转换的转换装置。

13.根据权利要求11或12之一的通信系统，包括

存储被收集的统计数据的存储装置。

14.根据权利要求11到13之一的通信系统，其中

该通信节点是智能网(IN)节点。

15.根据权利要求11到14之一的通信系统，其中

在智能网中，第一通信装置是业务交换点(SSP)，第二通信装置是业务控制点(SCP)。

16.根据权利要求11到15之一的通信系统，其中

程序数据是执行业务所需要的部分业务脚本或者业务脚本，或与业务无关的构件(SIB)，或数据。

Images