技术领域 本发明涉及用于电信网络的资源管理的方法、设备和系统。该管理包括资 源的分配，释放或保持。 诸如第三代无线网络(UMTS通用移动电信系统)的电信网络或诸如异 步传输模式网络的高速网络打算经由在网络基础结构上的计算设备提供诸如语 音、数据和多媒体的服务。为了支持具有特定服务质量(QoS)要求的各种服 务，资源供应是主要的问题。在每个情况中，通信网络至少包括一种资源，其 将以适当的方式被管理。 在当前电信系统中的许多应用是一对多的应用，其中一个或很少的源向多 个接收者发送。支持这种传输类型的有效方式是使用多播。多播是一种因特网 络(internetwork)业务，允许源将数据分组的一个拷贝发送到一个地址，其使 得数据分组被传送到多个接收者。在多播下只有一个消息拷贝将通过网络中的 任何链路，而数据分组的多个拷贝将只在通道分叉处实现。此外，如果只发送 一个消息的拷贝就足够了，即使该消息去往大量的接收方，则对于发送者具有 性能的改善。在多播传输的情况中，网络连接被预留用于多个用户并且服务器 也被多个用户访问，所以它的资源将在用户间分发，意味着资源供应要考虑共 享该资源的用户的数目。 使用资源的客户机的数量可以在特定时间点改变或消失。如果资源在较长 的时段没有被使用，它可能被释放或销毁(destroy)。这种资源可以是暂时分配 给网络某个节点的服务器功能，例如用于传送目的的选播(anycast)、广播或多 播“关联”，在节点间的信令关系等。共享资源的问题不仅存在于传送问题， 还适用于处理、存储容量等。 通常，如上面所述的共享资源的资源供应是网络中的主要问题之一，而呼 叫许可控制是供应策略之一，以限制网络中呼叫连接的数量，从而减少网络拥 塞和呼叫丢弃。一种呼叫许可模型被用于通信量整形，其例如被应用于确定一 个数据流是否应被允许发送。最简单的通信量整形方案设法使所有的通信量形 成为同步的流，以固定时间间隔发送的规则数量的数据。最简单的通信量整形 方案的一个例子是简单的漏桶。图7说明了漏桶方案。以数据分组形式的输入 数据流70被放入桶71。数据分组从桶的底部72流出并且在网络上以速率g被 发送。桶的大小B限制有多少数据可以在桶中等待输入到网络中。如果数据流 携带多于桶可以存储的数据，则超额的数据被丢弃。典型地，每个数据流具有 它自己的漏桶。概念上，每个主机通过一个接口被连接至网络，该接口包括漏 桶，即，有限的内部队列。 一旦资源被建立，呼叫许可算法被用于控制预留资源的使用。另一个方面 是所分配的资源的释放。 除了多播之外还有多个其它的例子，其中存在资源管理的问题，像例如作 为传输手段的广播或多播。此外所述问题还存在于点对点通信中，其中多个点 对点连接在网络中构成虚拟导管或隧道，其将被共享。而且资源管理问题还由 一些关联问题而存在，例如在客户机和它的服务器之间建立的SCTP流控制传 输协议的情况中。此处在服务器和客户机之间的SCTP关联是资源，其事实上 包括在客户机和服务器双方的存储器和处理容量，以及用于维持关联的网络容 量，其中合适的资源管理是有必要的。 应当注意，如果在某个时间段没有被使用后，它的预留到期，或被服务器 或负责资源管理的实体销毁，则资源是在“软状态”中。否则它被称为“硬状 态”资源。 相比于释放或销毁资源并在空闲时段后基于需要再次占用或创建它的成 本，频繁的保持空闲资源的成本是较高的。保持空闲的另一个关键原因是避免 当资源被需要时长的资源建立时间。 在下面给出了一个用于点对点连接中资源管理的例子。在无线网络中，诸 如在分组交换GSM和WCDMA网络中，PDP-上下文(PDP-context)被建立。 在该PDP上下文活动中移动用户身份与IP地址相关联。在PDP上下文活动期 间，一条隧道在网络中被建立。在该过程期间服务质量QoS协商也在用户移动 站和网络之间发生。在PDP上下文建立之后，所述PDP上下文被保持以用于 用户立刻发送或接收内容而不是先等待PDP上下文被建立。 为了保持资源活动的目标，用于不同协议的不同方法被开发，例如保持存 活机制，资源刷新消息和类似的当前被不同的网络标准(H.323、RSVP、NSIS 等)使用，用于保持特定资源存活或处于活动状态。例如在保持存活机制中， 一个实例(例如服务器或客户机)频繁地发送包括在数据分组中(例如在报头 中)的消息或信息，该消息或信息指示虽然当前没有数据在发送但连接被假定 为保持开放。因此，如果有数据发送，则通信在相同的已经建立的连接上被执 行。这会持续直到服务器或客户机决定结束通信，且它们中的一个丢弃连接。 通常生存时间参数被包括在该消息中，并控制资源的生存时间，这样资源 不会不必要地保持太长时间的开放。这种技术被开发用于点对点连接，其中一 个实例将它的准备就绪通知给其它设备用于保持连接开放。在定时器到期之后 连接被丢弃。 因此，当一个资源被分配给一个用户时，依照旧例的现有技术使用生存时 间参数来重置定义资源生存时间的定时器。那种方式很难考虑在多播连接中的 多个用户或资源拥有者的各种偏好，也不能估计抢先的或预期的资源使用，因 为资源的建立和释放当前是基于管理程序或来自资源用户的简单请求。这些程 序可能是不准确的并太早或太晚建立或释放资源。 然而，问题并不只存在于多播传输中。在现有技术的许多情况中既没有提 出也没有完全解决释放空闲资源的问题，并使它与实现相关。 发明概述 本发明的一个目标是提供一种在电信网络中有效管理资源的解决方案。 本发明具体表现为权利要求1、20和25中所公开的方法。优选实施方式 在从属权利要求中描述，在说明书相应的部分中被公开。 基本思想的方法在权利要求1中被公开，其公开了一种在资源代理中实现 的管理过程。 根据本发明的用于通信网络的资源管理的方法在资源代理中执行下面的步 骤，该通信网络具有提供资源的资源拥有者(RO)和至少一个使用资源的资 源用户(RU)，该资源代理被引入在资源拥有者和至少一个资源用户之间。在 第一步中资源使用量度(TTL)被发起。所述量度被用于跟踪资源用户资源的 预期使用。资源代理获得用户使用量度(Keep Alive，InterestMsg)，其通知资 源用户预期的资源的使用。用户使用量度可以作为来自资源用户的消息被接收 或可替换地，资源代理例如基于预留信息或历史信息计算所述量度。为了保持 资源使用量度(TTL)最新，执行一个更新过程，用于借助于通过考虑当前和 过去的资源使用量度(TTL)值的累积算法，使用用户使用量度(Keep Alive， InterestMsg)来更新资源使用量度(TTL)。该累积算法的共有特性是更多的值 的累积，特别是当前资源使用量度和所述值的历史的累积，从而补偿接收到的 用户使用量度的最终不确定性，该用户使用量度指示资源用户预期的资源使 用，其可能是不精确的且具有某种程度的不确定性。在这种情况中，通过在时 间和不同用户上平均使用量度，该算法补偿从用户到达的信息的可能的不确定 性或随意性。 根据建立的资源使用量度，作出是否执行管理动作的决定。为了这个目的， 执行检查过程以检查资源使用量度。假如资源使用量度证明管理动作的执行是 必要的，则执行相应的动作，该管理动作可以是分配、保持或释放资源。 由于累积算法考虑当前和过去的资源使用量度值，另外还有当前和预期的 资源用户的需要，有可能预测资源的使用，所以假如资源不被需要则将不被保 持开放并且关闭，即使当用户使用所述资源时。当前作出这种决定是由于静态 地设置的资源使用量度。 参照权利要求18，公开了根据本发明的资源代理。资源代理被安排以执 行用于通信网络的资源管理，该通信网络具有提供资源的资源拥有者(RO) 和至少一个使用资源的资源用户(RU)。所述资源代理(RB)被置于资源拥有 者和至少一个资源用户之间，并包括发起装置用于发起共享资源使用量度 (TTL)。此外资源代理包括获取控制器用于获取用户使用量度(Keep Alive， InterestMsg)，其通知资源用户对共享资源的预期使用。更新控制器被引入用于 通过考虑当前和过去的资源使用量度(TTL)值的累积算法，使用用户的使用 量度(Keep Alive，InterestMsg)来更新共享资源使用量度(TTL)。为了检查 资源使用量度的目的，使用检查监视器，资源使用量度指示执行资源管理动作 的必要性。依照检查监视器的结果，资源管理动作装置适用于执行资源管理动 作。所提到的装置是资源代理的部分，它们被安排以执行关于相应的方法步骤 所描述的功能。 建议资源代理具有更多特征。例如资源拥有者提供不可靠的资源给代理， 然后资源代理可以作为一种资源池的拥有者而工作，其管理资源并在失败的情 况下提供它们的冗余。 此外本发明公开了一种系统，用于通信网络的资源管理，该通信网络具有 提供资源的资源拥有者(RO)和至少一个使用资源的资源用户(RU)。所述 系统包括如上所述的资源代理(RB)，在所述资源代理(RB)和资源拥有者(RO) 之间的第一通信接口和在所述资源代理(RB)和至少一个资源用户(RU)之 间的第二通信接口。 在下面本发明优选实施例将被详细的描述，从而给技术人员提供本发明彻 底的和完整的理解，但是这些详细的实施方式只作为本发明的例子而并不意谓 着限制。下面的描述将参照附图，其中 图1示出了根据本发明的实施方式的网络结构的示意性表示， 图2示出了本发明的基本实施方式的流程图， 图3示出了根据本发明的实施方式的信令的示意性表示， 图4示出了用于释放共享资源的本发明实施方式的流程图， 图5示出了用于分配共享资源的本发明的实施方式的流程图， 图6示出了根据本发明的实施方式的系统结构和接口的示意性表示， 图7示出了根据现有技术使用漏桶方案的呼叫许可的示意性表示， 图8示出了用于使用漏桶方案释放资源的本发明的实施方式的示意性表 示。 图1示出了根据本发明的实施方式的网络结构的示意性表示，其中一种新 功能节点，称为资源代理RB，被引入到在至少一个资源拥有者RO和至少一 个资源用户RU之间的通信链路上。 应当认识到在本发明的上下文中的术语“资源拥有者”、“资源用户”、“资 源代理”或通常的“节点”、“装置”指的是在通信网络中用于提供预定功能的 硬件和软件的任意合适的组合。以这种方式，所述术语通常指的是可以扩展在 网络的多个物理节点上的逻辑实体，但也可以指的是位于一个物理节点上的物 理实体。 在其后描述的例子中，资源代理的功能由服务器或内容提供者执行，其中 服务器可以负责网络中的通信链接，内容提供者提供将被分发给用户的内容。 优选的，通信网络是移动通信网络，例如根据GPRS(通用分组交换无线 业务)或UMTS(通用移动电话系统)或GSM工作的移动通信网络。然而， 本发明也可应用在提供资源的任意通信网络中。 应当认识到术语“资源”指代任何种类的资源实体。在本发明中公开了两 种资源共享；同时共享，其意味着多个资源用户同时访问资源；和顺序共享， 其意味着在同一时间有一个资源用户访问资源。 在下面，所给出的实施方式示出了同时共享的资源。优选地，所述资源的 例子是网络资源，其可以是通信网络中的虚拟实体并为了分布用户的共用而占 有或创建。由此，这些可以是例如被用于多播/广播传输的网络连接，但是在某 个网络节点的资源，例如像处理时间、或存储量，也可以被认为是根据本发明 的分配资源。然而本发明不限于同时共享资源。事实上所建议的方法可以被用 于在单个资源用户的情况下的资源管理。例如该方法可以被用于释放任何传输/ 连接关联，例如在客户机和它的服务器之间建立的SCTP流控制传输协议的情 况。如上述的，在服务器和客户机之间的SCTP关联是资源，其事实上包括在 客户机和服务器二者中的存储器和处理容量，以及用于维持该关联的网络容 量。在这种情况中服务器是资源拥有者而客户机是资源用户，执行根据本发明 的过程来确定所述关联是否被保持，这个过程也可以由客户机或服务器执行或 由客户机和服务器两者独立地执行。这个控制可能对操作者是有用的，从而节 省在一个节点中的资源关联的成本。在下面给出的两个实施方式示出了用于共 享资源管理的本发明的应用。然而，同样的过程也应用于没有被共享的资源。 资源可以是分布实体，且不同节点拥有/持有资源实体的不同部分。然后 合理地指派/指定资源拥有者功能至多个或所有的共享资源拥有者身份的节点。 在这种情况中资源拥有者和资源代理的逻辑可以被配置在一个节点中。更甚至 每个共享资源拥有者身份的节点可以具有它自己的资源代理逻辑。拥有分布资 源的最昂贵部分或者具有在过载情况下可能影响系统/服务可用性特性限制的节 点/逻辑实体可以具有限制更多的资源管理过程，所以在多数情况中这个节点做 出关于是否预留、保持或释放资源的决定。在这种情况中每个RO也可以执行 它自己的RB角色。 回到图1，可以看到在一个网络结构中可以放置多于一个资源拥有者。如 上面提到的，有不同种类的资源可以得到，且每个资源拥有者拥有至少一种所 述资源。同样，有可能由资源拥有者中的每一个来管理一种资源。然而，在资 源代理中将被管理的一种资源具有它自己的管理过程。可替换地，每个资源代 理可以负责一种资源。 根据图1，在资源拥有者RO和资源代理RB之间有一个接口11，用于向 资源代理指示资源的可用性。此外在资源代理和资源用户之间有另一个接口12 用于与用户通信。所述接口被用于通知资源代理关于用户对于资源使用的准备 就绪。因此，用户可以通过该接口12通知资源代理它们是否想请求资源预留， 保持预留的资源或是否它们想要释放资源。此外该接口还可以被用于进一步的 通信目的，这将依照本发明进一步的实施方式而被描述。 优选地，真实的数据通信量不需要经由资源代理。例如共享资源是通信链 路的情况中，然后传输经过所述链路而不需要将资源代理包括在通信中。资源 使用相对于资源管理过程的独立通过在资源拥有者和资源用户间的直接接口13 在图1中描述。 可替换地，实际的数据通信量经过资源代理。例如资源代理RB是资源拥 有节点的逻辑部分的情况中。在那种情况中资源使用经过资源代理，其可以控 制资源使用是否根据所指示或请求的。此外资源代理可以使用资源使用用于计 费或统计目的。 图2示出本发明的方法的基本实施方式的流程图，具有在资源代理中执行 的步骤。下面的步骤将为了资源管理而被执行。优选地，一个资源代理管理多 个资源并因此根据图2的多个管理过程将在资源代理中被执行。可替换地，管 理过程可以分别为每个用户运行，并随后执行一个协调多个运行过程的算法以 将其减少为单个的值(像单个TTL定时器)。 根据图2中示出的用于资源管理的方法，在资源代理中执行的所述方法包 括步骤S21，其中发起资源使用量度。资源使用量度的发起可以以任何需要的 或合适的方式被执行。例如，资源代理可以使用一个值发起它，该值由资源代 理自己确定。可替换地，资源拥有者可以提供该值给资源代理。例如资源拥有 者确定关于资源的成本或时间间隔，其被发送给资源代理用于估计发起使用量 度。使用量度例如可以是使用时间或在某个时间段中花费的钱，这是一个组合 (钱，时间间隔)。此外，资源拥有者可以提供附加的信息，诸如像可以被用 于影响更新过程结果的资源成本。 而且发起阶段可以包括在资源和关于所述资源的信息之间提供关联。该关 联可以以任何需要的和合适的方式执行。例如当资源拥有者授予资源代理代理 资源实体的许可时，资源代理可以生成本地入口(例如资源项目表示)。可替 换地，该步骤也可以经由管理程序完成。发起过程导致产生所定义的关联，例 如包括更新过程的模型类型，它的参数和他们的起始值，例如模型＝“漏桶”， 量度类型＝“每个占有资源在特定时段中资源拥有者赚取的钱的平均数量”，该 数量由生存理由＝“对于占有资源实体而言足够的金钱的实际数量”而指定， 后者开启该资源。 另外地，其它参数也可以被初始化，例如资源使用量度被设置为定义保持 资源开放的时间的值。 在步骤S21之后，图1的方法进行到步骤S25，其中执行检查资源使用量 度。据此该步骤可以根据需要以任何优选的方式执行。例如它可以包括装置用 于改变资源使用量度以具有允许做出决定的可变的值。在S21和S25之间的连 接允许用户兴趣的检测。因此，在没有用户使用量度到达的情况中，在步骤S26 中该过程经由S25终止，其中执行相应的资源管理动作。 并行地实施步骤S22直到接收到来自用户的请求为止，其意味着该过程等 待一个接收到请求的事件，该请求通知关于资源使用的用户兴趣。用户能够例 如周期性地通过用户的使用量度或参数的列表提供他们预期的资源使用的一致 估计，其有利于在资源代理中的量度的计算。另一个例子可以是这个信息以不 同的间隔被提供。所述量度可以作为一种保持生存信息来实现，其被用在下面 的实施方式中。然而，除了发送请求消息之外还有不同的方式用于实现用户使 用量度。一些例子在图4中进一步给出。 可替换地从资源用户发送包括用户使用量度的消息至资源代理，资源代理 可以由自身计算用户使用量度。该计算例如可以基于一种资源的模型类型、历 史信息和已经接收的更新。 应当注意，可以有多个用户访问共享资源，意味着请求从不同的用户通常 在不同和变化的时间点到达。还应当认识到信息本身或信息值可能在时间上和/ 或每用户而不同。因此建议有某种识别过程以将接入资源用户与运行管理过程 相关。在本发明的一个实施方式中，建议有下面的解决方法。资源用户发送对 资源的请求至资源代理，并为预留资源指出特定类型的资源和可能的时间间 隔。当资源代理为资源用户预留资源实体时，资源代理发送带有预留的资源实 体的身份ID或关联ID的ACCEPT(接受)消息。随后如果资源用户想要按照 期望的资源使用在资源代理更新相应的资源，随后的KeepAlive消息涉及有效 的实体ID。 当用户的对于资源的使用量度请求到达时，S23，该方法进行到步骤S24， 其中用于通过累积算法使用用户的使用量度来更新资源使用量度的更新过程被 执行。 应当注意，在本发明的上下文中的术语“累积算法”指得是用于考虑其它 参数，像资源使用量度(TTL)和用户的使用量度(KeepAlive)的当前和过去 的值，执行新资源值计算的任何合适的方法。在随后的描述中作为例子，描述 了一种基于漏桶方法的方式。漏桶是当前用于系统负载控制和呼叫许可目的的 算法，这在本发明背景技术部分已经描述。可应用于累积方法的其它算法是所 谓的CUSUM算法。这是用于统计质量控制的统计算法，目的是为了检测随机 过程的行为中的改变。有多个其它的算法用于类似的目的，例如移动平均。类 似于移动平均的算法被用于因特网传输协议中的流控制目的。然而，那仅仅是 例子且本发明不应被限于这些例子中的任何一个。关于统计算法的更多信息将 在Basseville Michele，Nikiforov Igor，Detection of Abrupt Changes：Theory and Application，Prentice-Hall，Inc.，1993和Carlstein E.，Muller H.-G.，Sigmund D.(ed.). Change-Point Problems.Institute of Math.Statist.Lecture Notes Monograph ser.，V 23，1994中找到。 应当注意，该值同样地不是必须是标量，它们可以属于任何合适的值空间， 它可以是离散的或连续的以及多维的或任何其它自然数。当然需要另外的适配 例如为了运行定时器。 此外应当注意，将被使用的累积算法的类型通常在步骤S21被确定，当执 行整个过程的初始化时。在步骤S21做出关于哪个算法将被使用的决定。然而 自适应到用户的使用量度(KeepAlive)的输入数据流的在线算法也可以被使用。 在这种情况中新的用户的使用量度同样可以触发算法的改变。如果选择的算法 类型取决于多个参数，所述参数可以按照请求，或者基于任何统计/历史来估计。 这些参数可以使用最小二乘拟合方法被确定，其允许寻找对于给定的统计数据 集合/累积历史最好的拟合参数值，或任何其它合适的方法。该算法同样可以是 自回归统计算法。 此外应当注意，累积算法可以是自回归算法，其意味着根据给定的参数做 出决定，该算法将被使用。所述参数可以按照请求提供，或者基于任何统计/历 史来估计。 回到图2，在随后的步骤S25中，跟踪是否新的更新资源使用量度证明改 变资源状态的动作是有必要的。资源的状态可以是资源将被释放、预留或保持。 此外这可以是空闲资源的预留或已预留资源预留的延长。检查过程的目的是检 查任何动作条件是否达到以执行资源管理动作。该检查可以以任何合适的需要 的方式被执行。例如它可以通过比较功能被执行，将资源使用量度与任何合适 的动作条件相比较。例如资源使用量度是否达到动作条件可以从域/集合的值来 建立。资源使用量度可以具有单个标量值或向量的形式。例如在资源使用量度 的可能值的空间内可以定义三个域：域D1“释放”，域D2“预留”，域D3“保 持预留”，其中D2是D3的一部分，动作值可以取三个值“释放”、“预留/分配” 和“保持/延长分配”，其可以使用D1、D2、D3被确定。原则上这些域可以更 加复杂，计算几何学的方法(例如像在Franco P.Preparata，Michael I.Shamos， Computational Geometry：An Introduction，Springer-Verlag，1993中所描述的)可 以被用于校验新的值属于哪个域，以及将采取哪个动作。优选地资源使用量度 值被转换为正的标量并开始TTL定时器。总之这些仅仅是关于用于决定资源 管理动作的检查过程的例子。 既然如果比较的结果声明资源使用量度证明了改变是有必要的，则开始一 个动作以改变资源的状态，S26，例如通过决定相应资源的释放或预留或延长 预留。否则，当比较的结果是动作值没有达到时，该方法进行到步骤S22，其 中等待新的用户的使用请求。 在下面描述了根据图3的在资源拥有者、资源用户和资源代理之间的示意 性信令交换。在第一步骤，S31，资源拥有者提供资源，例如通过发送OFFER 消息至资源代理。优选地，所述消息可以带有一些参数，例如资源类型，资源 身份，可用性模式或保持生存标记，定义资源的可用性或通知任何计划下时间 和它的时间，或通知在资源使用时间中的变化，或通知资源冗余。随后，资源 代理决定它的对于管理提供的资源的兴趣。该决定在随后的步骤S32中通过通 知达到决定的ACCEPT/REJECT消息被发送至资源拥有者。 参照图3，在资源代理和资源用户之间有一个接口。资源用户例如通过 REQUEST(ResType，Usage Pattern)消息，3A，通知它的对于使用提供的资源的 兴趣。作为对接收到来自资源用户的请求的反应，资源代理验证该请求并发送 接受或拒绝消息至用户，3B。资源的使用独立于资源代理并在资源拥有者和资 源用户之间直接地执行，35。ACCEPT消息包括资源描述符，资源ID等。实 际上ACCEPT消息可以包括根据RB资源可以/将被多个资源用户占有用于共 用时的时间，例如所述消息可以包括多播会话的开始时间，其基于资源用户的 兴趣而估计。 在下面根据图4给出了本发明的一个实施方式，图4示出了用于释放共享 资源的本发明的一个实施方式的流程图。下面的步骤将被执行以决定共享资源 的释放。下面的实施方式是基于关于量度参数的一些例子。然而这些例子不应 被看作实现本发明的限制。在步骤S41，TimeToLive TTL作为资源使用量度的 例子被发起。如已经提到的，资源使用量度的发起可以以任何需要的或合适的 方式被执行。还如已经关于图2所提到的，使用量度可以是例如使用时间或在 某个时间段中花费的钱，其是一个组合(钱，时间间隔)。可替换地，资源代 理可以基于接收到的消息、事件或传送的服务，或历史知识来调整资源的生存 时间(TTL)定时器。例如在广播、多播或选播的情况中，无论何时内容被分 布到分组时，TTL可以增加一个默认值。 在步骤S41之后，图4的方法进行到步骤S44，其中启动了以TTL发起 的计数器。所述计数器的实现可以以任何需要的或合适的方式被实施，例如它 可以仅是与时间无关的计数器，或它可以与一些别的事情有关，诸如处理容量， 资源的成本或类似的。在下面我们使用定时器作为计数器的例子，然而这不应 被看作本发明的任何限制。 所述定时器的目的是指明保持预留资源的时间。在随后的步骤S45中示出 了定时器的运行终止，由此在定时器到达值0的情况下运行终止被传送，S46。 在这种情况中资源被释放，S47。在本实施方式中，步骤S44，S45和S46构成 检查使用量度的通常步骤，如在图2的步骤25中示出的。然而，停止定时器 被来自资源用户的输入更新消息停止，所以当前TTL等于定时器到期所剩下 的时间。如果没有来自资源用户的更新消息直到定时器到期，当定时器到期时， TTL被设为0。刚刚提到的流程描述了一种情况，即当使用量度被发起并没有 指明用户的兴趣的用户的使用量度消息到达时。此处过程经由S44，S45，S46 运行并结束于S47，其中释放资源，因为看起来没有用户对拥有资源预留感兴 趣。 在下面呈现了图4的第二部分，在步骤S42，KeepAlive消息到达。根据 本发明，用户能够周期性提供他们预期的资源使用的一致估计。可替换地，这 可以被管理地/手动地释放，例如资源代理基于每时段请求的次数估计要求的预 留时间。所述估计通过用户的使用量度被发送到资源代理。所述量度可以根据 图4的实施方式被实现为KeepAlive消息。用户在服务请求消息中发送 KeepAlive消息至资源拥有者并在他们的KeepAlive信息到期在适当的消息中 周期性地重发它。然而，不是真的必须周期性地发送KeepAlive消息。也可以 不是周期性地发送KeepAlive消息，而是当资源实际需要的时候发送。当资源 被预留时，资源代理可以向资源用户以ACCEPT消息的方式请求周期性的 KeepAlive更新。还应当注意，KeepAlive信息也可以通过将被分布的内容的接 收而被指示而不需要任何专用的KeepAlive指示符。用户的使用量度的值在从 资源用户发送到它的资源代理的不同的KeepAlive消息中可以具有不同的值。 当KeepAlive到达时，S42，方法进行到步骤S43，其中执行更新过程用 于通过累计算法使用接收到的KeepAlive更新TTL。 在下面描述了基于漏桶方式通过累计算法计算新TTL的实施方式。 如已经提到的，累计算法考虑资源使用量度的过去的值并加上用户的当前 需要。因此，在这个例子中Total_KeepAlive值通过其中的模型函数fct被更新。 Total_KeepAlive(n+1)＝fct(Total_KeepAlive(n)，KeepAlive，……) 其中对于漏桶方式，上面的公式具有下面的形式 Total_KeepAlive(n+1)＝MIN(Total_KeepAlive(n)-ΔTTL+KeepAlive*weight， MAX_Total) 其中Total_KeepAlive(n)描述累计它的过去值的当前资源使用量度；ΔTTL 是在最后TTL更新之后期满的时间；weight可以取决于考虑优先级的用户身份 或类别；MAX_Total定义漏桶的总容量。 新估计的Total_KeepAlive(n+1)值被用于确定新的TTL，其中 TTL＝Total_KeepAlive(n+1)-ReasonToLive ReasonToLive值影响资源释放的时间点。因此，ReasonToLive值越高对于 释放资源的决定越快作出。 如在图4中在步骤S44中说明的，初始地被设为TTL的定时器使用新计 算出的TTL更新并且所述定时器开始运行。 在下面，为了解释上面介绍的关于漏桶的参数，参照图8给出了用于TTL 的计算的实施方式。 图8示出了漏桶算法的示意性表示。漏桶具有上限值，其是指示可以被分 配给Total_KeepAlive的最大值的MAX_Total。 应当注意，在资源代理中可能有其它的控制漏桶的参数，例如，每给定时 间间隔的输入KeepAlive消息的最小数量被引入以便在资源代理中提供负载保 护。 所述桶的底部建有ReasonToLive值，其示出通过该桶管理的资源何时被 释放。进入桶的上面的箭头指示输入KeepAlive消息。出去的箭头指示TTL定 时器的下降。 如上所述，被设为TTL的定时器倒计数。根据图8，当新的KeepAlive消 息到达时，所述定时器被更新为较高的值，意味着桶的深度增加。另外当没有 新的KeepAlive消息到达时，定时器达到0级，意味着资源将被释放。 应当注意，诸如ReasonToLive，MAX_Total，weight之类配置参数的设置 和Model_function的选择取决于实际需要并可以随着情况而改变。特别地，应 当强调的是该函数可以考虑其它的参数，例如像资源成本，资源可用性等。由 于上述的计算步骤类似于CUSUM算法，开发的用于构建CUSUM模型的统计 方法全部可以被用于确定模型参数。 此外，应当注意，通过选择模型函数，一个函数对于不同使用情况可以调 整算法，例如该算法还可以考虑是否有一个或多个单元使用资源(例如，多个 源分布内容至多播组)并据此适配TTL。在多个源的情况中，该算法可以对于 内容提供者计算相同成本共享，例如在内容提供者(通常不是内容接收者)付 费的商业广告分发的情况中。提供较高的TTL意味着更高的相关成本。 还应当注意，KeepAlive值被与内容发送者身份存储在一起用于计费目的， 这样可以实现对于被使用或保持开的资源的合适的计费。本发明还能够对资源 预留但没有被资源用户使用的时间计费。 根据图8，还有指示用于分配新资源的可能值的ReasonToReserve值，如 参考图5的实施方式中描述的。 回到图4，说明了定时器被设为新更新的TTL值并开始运行，S43。所述 定时器的实现可以以任何需要的或合适的方式被实施。例如它可以倒计数时间 单元。倒计数也可以考虑资源的实际使用。例如当使用更多带宽时计数的减少 可以更快，这是通过在开始定时器之前恰当地缩放/加权TTL来完成的。在随 后的步骤中，S44，示出了运行的定时器。所述定时器周期性地被检查，它是 否达到了预定的值，步骤S45。在该实施方式中，预定的值被设为0。然而， 每个经历的值都适用。如果定时器已经到达了预定的值，则资源被释放。否则 过程返回到步骤S44，从其箭头也提供到步骤S47，其中等待新的KeepAlive 消息。 应当注意，资源释放过程可以根据资源的类型以不同的方式被实现。例如 如果资源是服务器中的存储器，则特定信息将被发送给服务器以通知资源释 放。 在下面呈现了根据图5的本发明的一个实施方式，图5示出了用于执行资 源分配的本发明的一个实施方式的流程图。下面的步骤将被执行以作出相应的 决定。 在步骤S51，资源使用量度通过预定的值被发起，其在这个情况中是0。 在步骤S51之后，图5的方法进行到步骤S56，其被执行直到接收到来自用户 的请求为止。所述请求在这个实施方式中被表示为InterestMsg，其指示用户对 于某个类型资源的兴趣。为了能够发送InterestMsg，用户将被通知这个资源分 配的可能性。这可以通过例如从资源拥有者发送到潜在用户的广播消息而完 成。然而，有多个已知的方法用于通知用户新的硬件或服务，所以这些在此处 没有描述。 在随后的步骤S53中，资源代理执行更新过程用于借助于累积函数通过 InterestMsg更新资源使用量度。 在下面的累计函数的实施方式中，在资源预留模式中，Total Interest表示 涉及兴趣量度的资源使用量度。在这个例子中，Total_Interest值借助于模型函 数fct2被更新，其中 Total_Interest(n+1)＝fct2(Total_Interest(n)，InterestMsg，...) 相应的模型函数可能具有下面的形式： Total_Interest(n+1)＝MIN(MAX(Total_Interest(n)- ΔTTL，0)+ InterestMsg*weight，MAX_Total) 其中 Total_Interest(n)描述当前资源兴趣量度； ΔTTL是在最后的Total_Interest更新后期满的时间； weight可以取决于考虑一些种类的优先级的用户的身份或类别； MAX_Total定义漏桶的总容量，且和在上面的资源释放模型中相同。 应当注意，对于一些资源预留模型，没有必要开始定时器，其取决于用户 在InterestMsg中提供的兴趣模式。然而在一些情况中，在最后更新之后过去的 时间将被考虑，因为它在上述的例子中通过在模型中包括ΔTTL参数指出。 模型函数的另一个例子可以是像移动平均这样的函数： Total_Interest(n+1)＝T_Weight(n)*Total_Interest(n)+weight*InterestMsg 其中 T_Weight(n)是在每个步骤中调整Toatl_Interest(n)的(平滑)参数。 当用户数量被计数时，用户可以周期性地发送InterestMsg或仅一次。然 而，这不应当被看作对本发明的限制。然而，使用更新过程，特定资源的累积 兴趣被估计。在每次更新之后，所述值与预定的ReasonToReserve值相比较， S54。如果所述值已达到，用于资源分配的过程被开始。否则过程回到状态，S56， 其中等待下一个InterestMsg。 优选地，建议当资源已经根据上述的过程被分配时开始资源释放方法。在 这种情况中Total_KeepAlive(0)被初始化，通过当前的Total_Interest(n+1)值或通 过任何其它合适的值，而TTL使用Total_KeepAlive(0)-ReasonToLive或任何 其它合适的值来初始化。 在下面根据本发明的系统结构和接口的实施方式被参考图6给出。图6示出了 出了用于广播或多播内容供应的系统的示意性表示，其中内容提供者CP表示 资源拥有者且资源是在多个用户间分发内容的共享的通信网络，用户在该上下 文中是内容接收者CR。进一步如已经提到的，共享资源也可以是多播组。根 据本发明，资源代理包含漏桶算法用于每个将被管理的资源。在内容提供者CP 和内容接收者CS之间，有一个资源代理RB管理共享的资源。进一步参考图 6，在资源代理和内容提供者之间具有查询接口。通过逻辑连接6C，内容提供 者发送内容至资源代理。 在这个实施方式中，真实的资源使用经由资源代理进行，所以所述资源代 理能够控制通信量。 优选地，资源代理也向内容提供者提供查询接口，6B和6A。所述接口被 用于查询对于执行管理资源的过程所需要的参数。在下面一些例子被给出以说 明哪个参数可以在通信实例间交换。例如通过6A接口关于资源可用性(像例 如资源是否已经被建立)的请求信息可以被查询。这个查询典型地用于非时间 紧急的内容，其优选地当资源已经被另一个内容提供者建立时被分发，例如以 减少的成本。进一步为了确保合适的工作更新过程，一些另外的参数或更精确 的估计参数可以被查询。在特别的实施方式中，关于漏桶参数的请求信息，诸 如ReasonToLive，资源用户的数量，可以被定制。此外资源代理可以要求关于 资源特性的信息，像例如可得到带宽，QoS，预留成本和/或此刻资源的实际使 用(由于成本可以取决于同时的资源用户的数量)，以设置影响关于以更好的 方式预留/分配或释放资源的决定的参数。用于管理资源的管理过程可以需要其 它的参数为了以更好的方式设置它的参数。例如更新过程的参数可以取决于资 源成本，其可以影响漏桶状态。 代替内容提供者查询资源代理，内容提供者也可以由资源代理通知，优选 地当它们已经为了相应的信息分发而登记。这种通信可以通过6B接口被执行。 例如资源代理可以发送一个消息，一些仅建立了类型“X”的资源和仍然有“Y” 数量的带宽可使用。 优选地，资源使用信息被存储且发送至计费服务器，其可以使用这个信息 以在资源用户间建立资源的更好的成本分布(甚至对于资源仅仅预留而没有实 际使用的时间)。这种通信在图6中被指明为6D。 然而这些仅仅是例子，示出通过接口另外的信息可以被查询以确保根据本 发明的资源管理过程的更好性能。