电信业务和网络(第08讲).pptVIP

电信业务与网络;Q.65（06/2000）;简介;UFM的原则;UFM的原则;Application 1;UFM的原则;业务描述的3阶段方法;Step 2;步骤1——功能模型（Functional Model）;1.1 统一功能模型（Unified functional model）;CUSF：CUSF是与一个与呼叫无关（call-unrelated）的业务功能，此功能实体与CCF和SSF相连，提供与SCUAF交互所需的与呼叫无关的业务功能。CUSF还提供SCUAF与 SCF交互所需的功能。CUSF： 扩展CCF的逻辑，以识别业务控制触发，并与SCF交互; 管理CCF与SCF间的信令 在SCF的控制下修改（CCF中的）关联/连接处理功能 在SCF的控制下修改（CUSF中的）与呼叫无关的交互处理功能 支持与呼叫无关的用户交互，这些交互可以是用户发起的，也可以是SCF发起的。 与SSF接口，处理与呼叫相关的交互 SCUAF ：SCUAF是业务控制用户代理功能，为用户提供接入。SCUAF是用户与CUSF间的接口。SCUAF： 为用户提供接入，与用户交互，按要求建立、维护、释放一个与呼叫无关的业务实例； 使用用于建立、操作和释放一个业务关联（association）或实例（instance）的业务请求（例如，set-up，位置注册（location registration））访问CCF中的业务提供能力 接收来自CCF的与呼叫无关的业务指示（indications），并按照要求将这些指示传给用户 维护此功能实体所能掌握的业务状态信息;业务通过功能实体之间的相互配合的动作来实现。 功能实体之间的配合需要在它们之间建立通信关系（communication relationship）： 在一个特定的业务功能模型中，每一对相互通信的功能实体称为在一个关系（relationship）中 相互通信的功能实体间的每一个交互（interaction）称为一个信息流（information）或API调用（API call）（API调用是针对使用UML来描述参考点（reference point）而言的）。任何一对功能实体间的关系是它们之间的信息流或API调用的集合（API调用是指参考点的API）。 如果一对相互通信的功能实体驻留在物理上分离的设备上，它们之间的信息流或API就定义了设备之间的信令协议（signalling protocol）的信息传送需求。 不同的相互通信的功能实体对（pair）可以有不同类型的关系。关系的类型（type）通过两个功能实体之间的信息流或API调用的集合来刻画。;基于上述定义，可使用以下准则和指导原则得到针对特定业务的功能模型： 基于对所希望的网络实现的多样性的了解，选择恰当的功能实体。需要考虑所有可能的功能分布，这样就使得管理人员（administration）在实际提供业务时有选择的余地。 关系的类型在最初始的时候可根据对功能实体之间交互的性质的评估来确定。根据更详细的功能实体动作、信息流或API调用的定义，以及功能实体分布的物理地点的范围，有可能需要对初始功能模型进行修改。 一些业务的模型需要一个功能实体被复制多次（例如，汇接功能）。功能模型在描述这种复制时，仅需描述到不会由于进一步的复制而增加新的外部关系（relationship） 组合这种程度为止。这样，一个单一的功能实体可以代表提供同一功能的多个物理汇接实体。 统一功能模型应覆盖尽可能多的网络体系结构;一个补充业务的功能模型应该与一个基本业务的模型相关 在确定与补充业务相关的功能是否应与现有的基本业务的功能实体驻留在一起，还是以新的独立的功能实体出现时，应遵循下列指导原则： 附加业务功能模型中的一组功能，如果它修改一个由基本业务控制的对象（例如，呼叫连接），应该将其与一个基本业务的功能实体合在一起 不与一个基本业务的功能实体合在一起的一个功能实体，不需要详细的呼叫/连接状态信息。独立的功能实体也可以通过与一个补充业务的功能实体（此功能实体与基本业务的功能实体驻留在一起）有事务关系来刻画。 当且仅当补充业务的功能实体需要通信，并且基本业务中已定义的信息流并不能满足这些通信需求时，才定义补充业务的功能实体之间的关系;步骤2——业务属性的SIB描述（SIB description of service features）;步骤3——信息流（Information flow diagrams）;步骤4——功能实体动作（Functional entity actions）;步骤5——功能实体的SDL图（可选） （SDL diagrams for functional entities（optional））;步骤6——将功能实体映射到物理位置（All