交换节点是一台计算机，希望它可以在由用户和国际标准所要求的 延时范围内处理作业。在宽带节点中，这些作业尤其位于非常不同的区 域，且具有不同的延时请求和随时间波动、类型完全不同的负载。这些 作业除了来自于用于数据和语音通信的交换技术外，也有一些来自于其 它作业范围，如协议处理(譬如CCS7信令、宽带UNI接口、宽带NNI 信令、全球域名解析(Global Title Translation)、PNNI协议，公用 接入接口、专用小交换机接入…)、信令网络管理(尤其在网络故障时)、 操作员接口控制、记帐、通信统计、用户端管理、线路接通、通道数据 和计费区等，此外还有用于将“失效时间”(在这段时间内，所有交换 节点或组成部分均不能使用)最小化的故障处理。 因为这种计算机工作在组合网络中，所以不仅正常运行必须要按时 间以最佳方式进行，而且其它运行状态，如投入运行时也必须如此—在 投入运行状态下网络内的通信将受到冲击。所以，延时请求将会随运行 状态而各不相同，因而必须对其作出适当的反应。 为此，交换节点希望的实时特性对节点结构和操作系统提出了特殊 要求。也即必须随时将处理器的运行时间容量尽可能最佳地分配给不同 的应用程序。为了保证这一点，在新的ATM交换节点内给操作系统提供 一种预算时间值，以保证不同应用可获取对处理器的最小访问时间。 因为通信网络要经历有关性能特征、结构和规模的不断变化，所以 通信网络中的交换节点必须能够在其提供的多变功能性和规模方面进行 标定。 因此，交换计算机必须能够扩展，并且具有最少的运行中断，甚至 尽可能没有运行中断：所以，需要HW升级来加强已有处理器的性能， 也需要SW升级来对性能特征进行高配置，以及(在相关情况下)对处 理器的预算时间进行重新分配，该重新分配也包括其它参数，如用于负 载控制的负载阈值、扫描间隔、协议预算等。尤其是所述的这些参数必 须能无中断地变更。 到目前为止，上述参数的分配文档都是在各用户中产生的，也即： 参数被写在应用程序之中。涉及参数的接口管理也同样通过用户来完 成。 因为所有负载控制参数和负载分配参数(以下简称负载控制参数) 都是四位数量级，且其对负载分配(根据信息通过量和延时请求-其中 有许多、但不是所有请求都需要调度-给不同的应用进行时间分配)和 负载控制具有最起码的重要性，所以它们在不同用户中(迄今)的分配 文档以及其通过用户(利用许多相应的用户接口)的管理将导致重大的、 或不可解决的工程问题，对此，该问题在于：为了进行最佳的负载分配 和负载控制，需根据情况对当前有效的参数值实行匹配(在一定配置情 况下和在运行时间内)。 本发明的任务就是解决上述问题。 通过负载模型管理器来实现该解决办法，这种管理器在所谓的负载 模型目录中对影响系统负载控制和负载分配的、以及由此影响系统性能 的参数进行统一管理。 下面借助四幅附图来对本发明的实施例进行详细阐述。 首先，借助附图1来说明ATM节点的结构。 在一种可标定的集群中，宽带节点的最重要控制是由主处理器来 实现的。所有处理器借助共同的内部协议通过ATM耦合网络(ATM结 构)进行通信。下文将单个主处理器与其位于系统总软件之上的部分 称作平台。 此处示出的集群在其最大配置时可由128个单独的平台组成。对 于所有的平台，硬件和基本软件(如操作系统和负载控制软件)都相 同。也就是说，该基础必须与所有已知的使用类型/应用的要求相一致。 同时该基础必须较全面，使得随时可以有效地跟上新的(可能现在还 未知)使用要求。这些使用类型可以通过平台上的不同应用软件包来 实现。存在用于如下方面的平台： ·交换技术(呼叫处理)(可多次存在于节点中) ·协议转换(可多次存在于节点中) ·操作、管理和维护(多次存在于节点中) ·网络信令管理(恰在节点中存在一次) ·操作员接口(恰在节点中存在一次) 包括基本软件在内，平台上用于上述任务的所有软件也被称为装载 类。除了这些“纯粹的”装载类外，还必须为平台提供所谓的组合装载 类，这样，便可以提供一些适合于用户的、且成本效率高的最小配置。 对于准确地调整应用的保证最小预算运行时间，这种平台恰好是一种挑 战，因为此处尤其是不同种类的用户程序在相互争用，以最大化地分配 到处理器的运行时间。 以下将详细说明操作系统和负载控制。 进程概念和CHILL 上述应用被作为进程的形式来实现，且在以下叙述中这些应用即意 为进程。在此，与运行时间相关的单元被当作进程来理解。作为可执行 的软件单元，进程具有一些属性，此处只对其中影响到对处理器的访问 权的属性感兴趣。该属性是静态地实现的。具有属性的进程可以用语言 (CHILL)解释和编译程序支持。系统起动时，在考虑该进程属性的情 况下，将其以一种适宜于操作系统的形式装入。 进程的两个用于实时特性的重要属性规定了： ·对一个任务组的归属，和 ·对该任务组内延时请求类的归属。 任务组是这样一些单元：在其驻留的平台的处理器上，它们被确保 有最小存取时间。 在该任务组中，进程的延时请求类确定了如下方式：如果同时准备 运行，在同一平台上属于同一任务组的进程将如何来争用计算时间。这 种区别任务组内各个进程的属性就是所谓的进程优先级。(参见下文“调 度”章节) 操作系统部分：业务寻址 尤其在扩充有大量节点的情况下，可以将请求如此地分配给集群， 使得尽可能不对单个平台提出过高要求。操作系统部分的业务寻址承担 了这一任务。 每个平台的操作系统把所有在全体集群内提供的、且可响应的功能 标识为“业务”。业务可在其要求的平台上和/或在集群的一个或多个平 台上被提供。为避免平台之间通信的额外开销，可将固有平台的业务的 响应地址-若此时存在-通知给有需要的用户。但假如该平台处于过载 状态(参见下文“负载控制”章节)，就在集群中选择另一个也可提供 该业务的平台(如果其处在较低的负载状态下)。这种做法是可能的， 因为每个平台上都有全体集群的当前负载图。 操作系统部分：调度 尤其在集群处于最小配置的情况下，必须准确地将单个处理器的计 算容量分配给各个应用。 对此，尤其在高负载情况下，每个平台的操作系统必须足以支持在 一个和同一个平台上争用计算时间的进程，以使其能够满足交换节点的 实时请求。为使上述情况成为可能，进程被综合为多个任务组。 附图2示出了进程调度的一个例子。对于每个任务组，利用负载控 制参数把处理器时间的最小保证部分定义为预算运行时间(也即净计算 时间)。因此，这些任务组也被称为虚拟CPU(VCPU)。进程按每个VCPU 和优先级被指定给FIFO队列，并在那儿等候CPU的分配。 调度以时间分割的形式进行。在每个时隙开始时，将每个VCPU视 作一种时间结存帐户，其方法是通过将VCPU进程的所有测量运行时间 之和与保证预算时间相比较。比较结果为一种VCPU专用的时间结存。 在具有最大时间结存的VCPU中，在最高优先级队列的第一个位置 上等待的此种进程获得第一计算时间(见附图2)。 假如进程在该时隙中还有延时，那么，下一进程可由相同的VCPU(以 及在一定情况下由相同的队列)产生。如果该VCPU已被进程用完，调 度算法便如同时隙开始一样起作用。为开始下一时隙，调度算法需要重 新找到应用。 负载控制 负载控制SW将固有平台的当前负载情况与平台专有的阈值进行循 环比较，并在一定情况下将处理器标记为已处在过载状态。当所提供的 总负载比处理器给定的负载阈值高时，那么处理器就处于过载状态。该 负载信息在系统范围内传播，以便业务寻址能够“保护”过载的平台。 一旦处理器处于过载状态，负载控制就借助于VCPU的预算运行时 间来确认是哪些VCPU超过了其预算。然后该VCPU就被标记为过载。通 知该过载VCPU中的一些合适进程，并由此请求减少其在处理器上的负 载强度。 于是，按照上述ATM交换节点的MP操作系统结构，操作系统的负 载控制和进程调度都利用了一系列负载控制参数来进行工作，以创造出 最佳实时特性的先决条件。因为操作系统和负载控制都是为所有MP平 台而产生的，也即对所有MP平台都是统一的，所以，一个平台所有可 能的功能特点的数据都必须对每个MP有效。此外，为了考虑该功能特 点，这些数据必须能通过人机对话在平台上被“激活”-譬如在配置时。 另外，这些数据必须和平台的相应运行状态(如恢复)相匹配，以最佳 地接受这些运行状态的不同请求。 负载模型管理 所述之请求和机理，如网络节点的可标定性、平台的负载强度分 配、平台的计算机容量对不同用户的划分、带有静态进程属性的进程 设计、以及负载控制等，它们还并不是所有与负载控制参数有关的机 理。此外，还有时钟脉冲信息、内部协议的运行时间限制、对基本负 载的考虑、其它子预算的划分和阈值等等，在此，我们无需关心它们。 如果人们考虑负载控制参数的数量和复杂性、请求分布、以及该种 参数所在的功能结构，那么就有必要条理清楚地实现它们，并用一种固 有的软件来进行控制，这是很显然的。 因此，所有影响系统负载控制和负载分配的参数都被暂存在一个在 各平台上复制的目录里。在设计阶段，如果使参数之一的变化对其它参 数值产生干扰，那么就可完成这种尤其重要的条理清楚性。在运行时间 内，仅有一个唯一的管理功能(LM管理器)访问该目录-该功能还维持 通向参数用户的接口。在运行时间内，有些触发可通过定义的接口请求 变更当前有效的参数(譬如通过人机对话由操作员来进行)，而上述管 理功能对该种触发来说也是易于接收的。该管理功能还负责将信息发送 给这种变更所涉及的所有用户。在选择参数目录的结构时，使有效参数 的在线变更合理地得到限制。只有通过这种形式的管理和结构化，才可 能实现复杂的作用参数工程，并使这种工程无故障地得以实施。 通过负载模型管理，负载控制参数可通过一种方法构造成复杂广泛 的多样性，一方面，除了要确保无故障实施之外，该方法还要为工程目 的确保一种条理清楚性。另一方面，也要实现一种灵活性，为了在负载 分配和负载控制方面实现最佳性能，这是根据情况对当前有效参数值进 行匹配(在一定配置情况下和在运行时间内)的先决条件。 通过人机对话，可以从参数目录中只选出一个单独的表格，并将其 “激活”，由此，不能从其它目录表中得到可用的值(只要该表“有效”)。 平台的交互运行状态只能重新从预制的数据组中选择，并在它们之间相 互切换。 附图3示出了负载模型管理器与系统中不同部分之间的关系。LM管 理器的用户具有三种不同的类型。第一种用户类型(用户1)只与LM管 理器相连。作为示例，用户在此被称为恢复部分。第二用户类型(用户 i)既与LM管理器相连，亦与负载控制相连。作为示例，用户在此被称 为调度部分。最后，第三用户类型(用户n)只包括负载控制值。作为 示例，用户在此被称为交换技术部分。 操作员接口 譬如在交换节点投入运行时，必须配置集群的每个单独的平台，这 意味着： ·分配和装入装载类，以及 ·从在所有平台上复制的负载模型目录中选出一个负载模型表。 在下文的“负载模型目录”章节中将深入地阐述负载模型目录中的 集中负载控制参数的编排方式。 从负载模型目录中给装载类单值地分配一个负载模型表，其中，对 于一个装载类可以有多个表格(譬如针对用户不同的负载期望或运行状 态)。 在表格选出后，只有该表格中列出的、且其内部一致的参数组的值 一直适用到该表格被无中断交换。这意味着一种合适的限制，它简化了 操作员对节点的控制，并确保了操作员在操作中总能采取相互协调的参 数。在不同负载模型表之间进行选择的可能性使得操作员能够对平台进 行调整。 也就是说，操作员可以根据对各种VCPU的负载期望来安排合适的 VCPU预算。因为操作员可以在运行期间无中断地交换当前有效的负载模 型表，所以预算能毫无问题地与被改变的条件相匹配(譬如通过节点内 的HW或SW升级)。 通过可由制造者检测一致性、并由其提供的SW插接，可以变更表 格中的值。然后操作员命令可以在运行无中断的情况下选择被插接的表 格(参见附图3)，并且由控制软件(负载模型管理)负责通知相关应用。 选择的协调参见“控制软件”章节及附图4。 负载模型目录 负载模型目录表示了这类集中实现的负载模型参数的编排结构。 (与此相反，进程属性在每个单独的进程中被解释为分散的，参见上文 “进程概念”章节) 该目录由单个的负载模型表格组成，这些表格可通过人机对话分配 给每个平台(参见“操作员接口”章节)。 一方面，每个源自负载模型目录的负载模型表都包含多个负载模 型，多个负载模型则包含有用于VCPU的保证预算。不同的负载模型被 用来考虑平台运行状态-譬如启动或正常运行-的不同请求。 另一方面，负载模型表还包含用于内部协议作业管理的时钟脉冲信 息、过载极限和用于内部协议管理的运行时间限制、负载预留量、基本 负载以及一种支持VCPU进程分配的表格。 控制软件(负载模型管理器) 控制SW(负载模型管理及管理部分)是一种与操作系统相近似的进 程，该进程在投入运行或平台状态变更时负责读出正确的参数。 负载模型管理器(缩写形式：LM管理器)实现了当前有效负载模型 参数的无中断交换。对此，该LM管理器为触发事件提供接口。此外， 该LM管理器负责通知与该结果有关的SW。操作系统以及诸如负载控制 的进程都属于该软件。如果通过VCPU的负载模型表的交换，完全去除 了预算，则显然必须将所属的业务收回。 按相关平台的内部运行状态来应用这个或那个负载模型。如果譬如 在运行期间进行恢复(也参看附图3或4)，那么，恢复就可以求助于负 载管理，由此可从正常的运行负载模型切换到特殊的恢复负载模型，这 样，可由恢复来考虑变更的运行时间要求。负载模型管理通知其中相关 的SW-如调度和负载控制-，且不依赖于该事件。 缩写 -ATM 异步传输模式 -CCITT 电报电话咨询委员会(今天的ITU-T) -CCS7 公共信道7号信令系统(固定带宽中继信令) -CHILL CCITT高级语言 -FIFO 先进先出 -ITU 国际电信联盟 -Lmo或LM 负载模型 -NNI 网络间接口(可变带宽“中继”信令) -PNNI 专用网络间接口 -SW 软件 -UNI 用户网络接口(宽带用户信令) -VCPU 虚拟CPU