电信业务与网络第08讲.ppt
《电信业务与网络第08讲.ppt》由会员分享,可在线阅读,更多相关《电信业务与网络第08讲.ppt(66页珍藏版)》请在三一办公上搜索。
1、电信业务与网络,第八讲 电信业务开发及相关软件技术,Q.65(06/2000),Series Q:Switching and SignallingFunctions and information flows for services in the ISDN MethodologyThe unified functional methodology for the characterization of services and network capabilities including alternative object-oriented techniques,简介,本ITU-T建议取代
2、了97年版本的Q.65建议,描述了为了业务实现在提供业务和解决信令需求时使用的一个通用的功能体系结构。2000年版本Q.65描述了新版本的统一功能方法(UFM:Unified Functional Methodology),此新版本的UFM结合了Q.65 1988年版本中的方法、智能网描述方法中使用的一些方法、以及UFM中使用的一些方法。UFM使得从一个单一的统一功能体系结构出发,有两种方法可以到业务的功能描述。一种是使用基于SIB的技术,得到信息流(IF)、功能实体动作(FEA)、SDL描述;另一种是使用面向对象的技术,得到接口类描述、通用IDL描述和SDL描述。此统一的模型使得可以用类似的
3、手段描述所有的网络体系结构(例如ISDN、B-ISDN、IN、IMT-2000,以及TMN)ITU-T 1.130中描述了导出ISDN业务的交换和信令方面的需求的整个方法。,UFM的原则,在确定UFM时采用的原则包括:UFM允许在已有第1阶段业务描述的情况下、或是为了业务生成(service creation)已经描述了网络能力(network capability)描述的情况下,可产生功能描述(functional description)UFM主要基于使用以下方法所获得的经验:ISDN第2阶段方法(ITU-T Q.65(1988)、IN方法(ITU-T Q.1210,(1995)、由Rum
4、baugh,Booch等提出并在UML中得以提炼的分布式计算技术ITU-T Q.65(1997版本)提出了使用功能模型(functional model)、功能实体(functional entities)、功能实体动作(functional entity actions)进行业务描述IN方法提供了业务描述时所希望的灵活性(flexibility)、业务无关(service independence)、重用(re-use)等特性。利用UML这一工具,可得到接口类、以及接口类之间的关系的详尽描述。通过使用其它工具,可以得到接口的IDL描述(这些IDL形成API)。UFM基于一个统一功能模型(Th
5、e method is based on a unified functional model)(对统一功能模型,请参见附录II).统一功能体系结构(unified functional architecture)经过扩展包括新的需求,并可进一步扩展以满足用户的需要。对每一个业务描述,选择一个适当的功能实体集合来构成模型这样利于保持信息流、和/或API、SDL描述的一致性。,UFM的原则,维护一个SIB库(包括相应的信息流和SDL描述),这个库可用于确定分布功能平面中的功能体系结构 创建相应的SIB集以支持IN建议定义的能力集将SIB映射到功能体系结构,体现为映射到预定义的功能实体动作、预定义
6、的SDL描述、和预定义的信息流。维护一个包(Packages)、接口类(interface classes)和IDL描述库。IDL定义了一个特定的接口处的API。这些(包、接口类和IDL描述)也可用于确定分布功能平面中的功能体系结构UFM要 解决当前的需要,但是也必须能够演进以容纳新的进展和新技术。在UFM的演进过程中仍能使用UFM在ITU-T内部,对统一功能体系结构的使用,采取分阶段使用方法(Phased approach for use across the ITU-T,using the unified architecture.)需要开发新的SIB需要开发新的API需要定义新的关系(r
7、elationships)必须考虑新的业务(例如多方呼叫)虽然UFM不是一个自动化过程,但重用(re-use)将在其中起主要作用。必须开发通过SIB来描述业务的新技术(New expertise must be developed for describing services from SIBs),Application 1,Application 3,Application 2,Application/,Service plane,Package 2,Application/,Service Plane,Service package,requirements,Distributed,Fu
8、nctional,Physical,Plane,Plane,Plane,Package 1,Package 3,Package 4,IClass,IClass,IClass,IClass,IClass,IClass,GF/SIB1,GF/SIB2,GF/SIB3,CCAF,CCF,CCF,CCF,CCAF,SSF,SSF,SCF,SDF,SRF,IAF,SDP,SCP,Inter-networkGateway,SCP,SSPLE,LE,LE,LE,SRP,Figure 1/Q.65 Conceptual methodology model showing relationships betwe
9、en services,global functions/service-independent building blocks,service packages,interface classes,functional entities and physical entities,UFM的原则,对于第2阶段描述,UFM应该包括以下内容:标识业务或网络能力(identification of service or network capability);功能模型和功能实体定义(即统一功能模型)(functional model and functional entity definition(
10、Unified Functional Model))标识SIB和/或包(可选)功能实体动作和/或IDL定义(functional entity actions and/or IDL-definition)信息流和/API(information flows and/or APIs)SDL(动态描述)(可选)场景(功能实体到物理地点的分配)(scenarios(physical allocation of functional entities))定义物理场景(Define physical scenarios at an appropriate time.)需要确定推荐的网络实现对IN、B-I
11、SDN、IMT-2000及其它网络的的扩展,物理实体的类别将增加。对工具改善和功能描述过程自动化提出有关建议可以更加有效地利用ITU-T Z.100(SDL)和Z.120(Message Sequence Chart information flows)工具可用来验证SDL及信息流,业务描述的3阶段方法,对于需要标准化的业务和网络能力,方法的第2阶段将第1阶段对基本业务、补充业务和网络能力的描述作为输入。第2阶段定义所需的功能以及这些功能在网络中的分布。,第2阶段的输出用于:第3阶段的协议设计人员来描述分离的物理实体之间使用的协议;交换机(和其它节点)设计人员来描述这些节点的功能需求;网络规划
12、人员,第2阶段采用了一些提供下列性质的技术:功能描述(functional specification)可有不同的物理实现;对支持基本业务、补充业务以及网络能力所需功能的精确定义,以及这些功能在网络(在某些情况下,在用户设备)中可能的分配;对所提供的功能、信息流和API调用的详细描述,但并不说明这些是怎样实现的;将对协议和交换能力的需求作为方法的第3阶段的输入,Step 2,AltStep 2,Step 3,AltStep 3,Step 4,AltStep 4,Step 5,Step 6,Step 1,Using SIB,Methodology,Using O-O,Methodology,Fi
13、gure 2/Q.65 Use of Step 1 to 6,UFM的步骤,Step 1-Functional model,Step 2 Applications to Package(optional),Step 3 Interface Classes and Class Diagrams,Step 4 API descriptions in IDL,Step 2 SIB description of service features,Step 3 Information flow diagrams,Step 4 Functional entity actions,Step 5 SDL di
14、agrams for functional entity(optional),Step 6 Allocation of functional entities to physical location(scenarios),步骤1功能模型(Functional Model),为每个基本业务、补充业务、或网络能力到处一个功能模型在每种情况下,功能模型需与所考虑的业务的需求及特性匹配。业务的第2阶段描述中使用的功能模型包括功能实体(functional entities)以及功能实体之间的关系(relationship)对初始的功能模型的求精(refinement)可通过下面要讲到的步骤2到步骤6
15、的反复而完成,最终得到的功能模型代表第2阶段完整的工作结果。,1.1 统一功能模型(Unified functional model),第2阶段方法中使用的统一功能模型(unified functional model)考虑了ISDN、IN、B-ISDN、IMT-2000以及TMN中共有的功能实体、实体间的关系、信息流。下图给出了一个统一功能模型的实例,此模型由UFM描述的功能实体集中得到。基于此模型,可构建一个支持特定业务或网络能力的特定的第2阶段功能模型,CCAF,CUSF,SSF,CCF,SRF,SDF,SCF,SMF,SCEF,SMAF,SCUAF,To other SMFs,To o
16、ther CCFs,To other SDFs,To other SCFs,To other IAFs,To other SDFs,To other SCFs,Network,boundary,To other SDFs,To other,SCFs,Figure 3/Q.65 Unified functional model,SSF:Service Switching Function,IAF:Intelligent Access Function,CCF:Call Control Function,CCAF:Call Control Agent Function,SCF:Service Co
17、ntrol Function,SDF:Service Data Function,SRF:Specialized Resource Function,SCUAF:Service Control User Access Function,CUSF:Call-unrelated Service Function,CUSF:CUSF是与一个与呼叫无关(call-unrelated)的业务功能,此功能实体与CCF和SSF相连,提供与SCUAF交互所需的与呼叫无关的业务功能。CUSF还提供SCUAF与 SCF交互所需的功能。CUSF:扩展CCF的逻辑,以识别业务控制触发,并与SCF交互;管理CCF与SC
18、F间的信令在SCF的控制下修改(CCF中的)关联/连接处理功能在SCF的控制下修改(CUSF中的)与呼叫无关的交互处理功能支持与呼叫无关的用户交互,这些交互可以是用户发起的,也可以是SCF发起的。与SSF接口,处理与呼叫相关的交互SCUAF:SCUAF是业务控制用户代理功能,为用户提供接入。SCUAF是用户与CUSF间的接口。SCUAF:为用户提供接入,与用户交互,按要求建立、维护、释放一个与呼叫无关的业务实例;使用用于建立、操作和释放一个业务关联(association)或实例(instance)的业务请求(例如,set-up,位置注册(location registration)访问CCF
19、中的业务提供能力接收来自CCF的与呼叫无关的业务指示(indications),并按照要求将这些指示传给用户维护此功能实体所能掌握的业务状态信息,1.2 功能实体(Functional entities),业务通过功能实体之间的相互配合的动作来实现。功能实体之间的配合需要在它们之间建立通信关系(communication relationship):在一个特定的业务功能模型中,每一对相互通信的功能实体称为在一个关系(relationship)中相互通信的功能实体间的每一个交互(interaction)称为一个信息流(information)或API调用(API call)(API调用是针对使用
20、UML来描述参考点(reference point)而言的)。任何一对功能实体间的关系是它们之间的信息流或API调用的集合(API调用是指参考点的API)。如果一对相互通信的功能实体驻留在物理上分离的设备上,它们之间的信息流或API就定义了设备之间的信令协议(signalling protocol)的信息传送需求。不同的相互通信的功能实体对(pair)可以有不同类型的关系。关系的类型(type)通过两个功能实体之间的信息流或API调用的集合来刻画。,1.3功能实体关系(Functional entity relationships),基于上述定义,可使用以下准则和指导原则得到针对特定业务的功能
21、模型:基于对所希望的网络实现的多样性的了解,选择恰当的功能实体。需要考虑所有可能的功能分布,这样就使得管理人员(administration)在实际提供业务时有选择的余地。关系的类型在最初始的时候可根据对功能实体之间交互的性质的评估来确定。根据更详细的功能实体动作、信息流或API调用的定义,以及功能实体分布的物理地点的范围,有可能需要对初始功能模型进行修改。一些业务的模型需要一个功能实体被复制多次(例如,汇接功能)。功能模型在描述这种复制时,仅需描述到不会由于进一步的复制而增加新的外部关系(relationship)组合这种程度为止。这样,一个单一的功能实体可以代表提供同一功能的多个物理汇接实
22、体。统一功能模型应覆盖尽可能多的网络体系结构,1.4 导出功能模型(Derivation of the functional model),一个补充业务的功能模型应该与一个基本业务的模型相关在确定与补充业务相关的功能是否应与现有的基本业务的功能实体驻留在一起,还是以新的独立的功能实体出现时,应遵循下列指导原则:附加业务功能模型中的一组功能,如果它修改一个由基本业务控制的对象(例如,呼叫连接),应该将其与一个基本业务的功能实体合在一起不与一个基本业务的功能实体合在一起的一个功能实体,不需要详细的呼叫/连接状态信息。独立的功能实体也可以通过与一个补充业务的功能实体(此功能实体与基本业务的功能实体驻
23、留在一起)有事务关系来刻画。当且仅当补充业务的功能实体需要通信,并且基本业务中已定义的信息流并不能满足这些通信需求时,才定义补充业务的功能实体之间的关系,1.5 基本业务模型与补充业务模型间的关系(Relationship between basic and supplementary service models),步骤2业务属性的SIB描述(SIB description of service features),鼓励使用SIB和HLSIB来描述业务属性和网络能力。因为SIB的使用促进了已定义的SDL、信息流、功能实体动作的重用下面的指导原则适用于第2阶段方法:提供业务属性(service
24、 feature)的全局业务逻辑图,包括POI和POR全局业务逻辑(GSL)将SIB串接起来,定义了SIB操作的串接次序,从而构建了实现业务属性的业务处理流程在描述中提供SIB到同一功能模型中的功能实体的映射。另外,提供对所使用的SIB的定义的应用(reference)。提供业务所需的SIB数据参数,标识在业务的上下文中这些参数的数据取值,步骤3信息流(Information flow diagrams),3.1 标识信息流:功能的分布要求功能实体之间进行交互。这样一个交互称为一个“信息流”,需要为信息流取个能够说明此信息流目的的名字需要绘制信息流图(information flow diag
25、rams)来描述成功的业务操作所必需的所有信息流,同样也需要为其它情况绘制信息流图。3.2 定义每一个信息流:确定每个信息流的语义和信息内容。一个信息流可以是需要证实的,如果是需要证实的,需要一个具有相同名字的返回信息流当交互的功能实体在物理上分离的地点实现,信息流通常通过信令系统协议传送使用表来说明信息流中的每一项,并应该指出每一项是否是必需的,或者是可选的,并且指出信息流通过哪个关系传递,步骤4功能实体动作(Functional entity actions),对接收到每一信息流,标识并列出来从接收到此信息流到发出由此而产生的结果信息流(next resulting information
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 电信业务 网络 08
链接地址:https://www.31ppt.com/p-6389996.html