ImageVerifierCode 换一换
格式:PDF , 页数:8 ,大小:95.08KB ,
资源ID:798056      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-798056.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ITU-T I 130-1988 METHOD FOR THE CHARACTERIZATION OF TELECOMMUNICATION SERVICES SUPPORTED BY AN ISDN AND NETWORK CAPABILITIES OF AN ISDN《表征由综合业务数字网(ISDN)支持的电信业务和ISDN网络能力的方法》.pdf)为本站会员(ownview251)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ITU-T I 130-1988 METHOD FOR THE CHARACTERIZATION OF TELECOMMUNICATION SERVICES SUPPORTED BY AN ISDN AND NETWORK CAPABILITIES OF AN ISDN《表征由综合业务数字网(ISDN)支持的电信业务和ISDN网络能力的方法》.pdf

1、INTERNATIONAL TELECOMMUNICATION UNION)45G134 ) TELECOMMUNICATIONSTANDARDIZATION SECTOROF ITU).4%2!4%$G0G03%26)#%3G0G0$)4!,.%47/2+G0G0 )3$.G9%.%2!,G0G03425#452%-%4(/$G0G0b) to show how, starting from the service definition, it is possible to define protocols and network resourcesfor providing such se

2、rvices;c) to make reference to those Recommendations which are relevant to the above two points.2 Structure and application of the overall methodThe method is divided into three main stages of activity: service aspects (stage 1), functional network aspects(stage 2) and network implementation aspects

3、 (stage 3).Within each stage a number of steps have been identified, as shown in Figure 1/I.130. In principle, theapplication of the method is sequential, stage 1 given the service description from the user point of view, stage 2 offeringan intermediate view of what happens at the user-network inter

4、face and inside the network between different exchanges,and stage 3 giving the actual switching and service nodes descriptions, as well as protocols and format to be adopted.In order to classify and relate the various Recommendations relevant to the method, a three level structure isused where each

5、level applies to the three above-mentioned stages.Level 1 is a description of the overall method, and is contained in this Recommendation.Level 2 identifies and defines the tools for the work within each stage. Examples of these tools are frameworksfor service prose descriptions, libraries of pre-de

6、fined functions, graphical conventions, etc. All these tools are coveredby Recommendations.Level 3 is the actual application of the method to each individual service and is contained in variousRecommendations.The application of the method for stage 1 results in a description of the service. Stage 2

7、results in one or moreimplementation independent scenarios, and stage 3 results in a set of protocol and switching Recommendations neededto realize the service for each scenario.Figure 2/I.130 illustrates the concept of levels in relation to various Recommendations relevant to the method.3 Descripti

8、on of the methodAs referred to in 2 above, there are three stages of the method as follows:Stage 1 is an overall service description from the users standpoint.Stage 2 is an overall description of the organization of the network functions to map service requirements intonetwork capabilities.Stage 3 i

9、s the definition of switching and signalling capabilities needed to support services defined in stage 1.Each stage consists of several steps.2 Fascicle III.7 Rec. I.130d01FIGURE 1/I.130.D01Fascicle III.7 Rec. I.130 3d02FIGURE 2/I.130.D024 Fascicle III.7 Rec. I.1303.1 Stage 1Stage 1 is an overall ser

10、vice description from the users point of view, but does not deal with the details of thehuman interface itself. The stage 1 service description is independent of the amount of functionality in the usersterminal, other than that required to provide the human interface. For example the conference call

11、ing service descriptionis designed to be independent of whether the conference bridge is in the terminal, in the serving exchange or elsewhere.The steps in stage 1 are:Step 1.1 Service prose definition and descriptionThis step describes the service in terms of the perceptions of the user receiving t

12、he service and any other usersinvolved in the service. It describes events in a generic term which does not constrain terminal or networkdesign. It is intended to allow an understanding of the service without regard to implementation. Thedescription should include operational, control, interworking

13、and administrative aspects as well as interactionswith other services. A detailed format and list of definitions for terms used for service prose definition anddescription is contained in Recommendation I.210.Step 1.2 Static description of the service using attributesThe static, that is, time-indepe

14、ndent, aspects of a service can, in some cases, be efficiently described byattributes. An attribute is a characteristic or functional description which is common to several services andtherefore needs to be described in detail only once. Subsequently, it can be referred to by a name or otherdesignat

15、ion. Within the scope of an attribute definition there may be multiple parameters or identifiedfunctional variations which are called attribute values.The attribute technique is described more fully in Recommendation I.140. It contains an outline of thetechnique and definitions of attributes and att

16、ributes values, valid for both services and connection types. Theattributes and attribute values identified for services can be found in Rec. I.210 (Annexes B and C) for bearerservices and for teleservices. The use of the attribute technique in the description of supplementary services isfor further

17、 study.Step 1.3 Dynamic description of the service using graphic meansThe dynamic description of a service contains all the information that is sent and received by the user fromactivation invocation of the service to completion of the service. The information is presented in the form of anoverall S

18、pecification and Description Language (SDL) diagram. An overall SDL diagram is a flow chart whichidentifies all possible actions relevant to the service as perceived by the user. It treats the network as a singleentity, that is, no information flows within the network are considered. The method of u

19、sing the overallSDL diagrams for service description is given in Recommendation I.210, Annex D.3.2 Stage 2Stage 2 identifies the functional capabilities and the information flows needed to support the service asdescribed in stage 1. The stage 2 description will also include user operations not direc

20、tly associated with a call (e.g. userchange of call forwarding parameters via his service interface) as described in stage 1. Furthermore, it identifies variouspossible physical locations for the functional capabilities. The output of stage 2 which is signalling system independentis used as an input

21、 to the design of signalling system and exchange switching Recommendations.The steps in stage 2 are:Step 2.1 Derivation of a functional modelA functional model is derived for each basic and for each supplementary service. The functions required toprovide the service are grouped into functional entit

22、ies. The functional model is the aggregate of the functionalentities and their relationships. The concept of a functional entity is contained in the ISDN functionalprinciples Recommendation (I.310). In the case of supplementary services the relationship between thesupplementary service and the basic

23、 service is shown by a composite functional model.Fascicle III.7 Rec. I.130 5Step 2.2 Information flow diagramsThe distribution of the functions needed to provide a service as defined by the functional model requires thatinteractions be defined between functional entities. Such an interaction is ref

24、erred to as an “information flow”and has a name descriptive of the intent of the information flow. Information flow diagrams are created forsuccessful operation and may be created as appropriate for other cases. The semantic meaning and informationcontent of each information flow is determined.Step

25、2.3 SDL diagrams for functional entitiesThe functions performed within a functional entity are identified and represented in the form of a Specificationand Description Language (SDL) diagram. The inputs and outputs of the SDL diagram are to and from theusers as described in stage 1 and are informati

26、on flows to and from other functional entities.SDL diagrams are defined for each functional entity based on the information flows defined for the successfuloperation of the service. The SDL diagram also covers the unsuccessful cases.Step 2.4 Functional entity actionsThe actions performed within a fu

27、nctional entity are represented as a list, or sequence, of functional entityactions (FEAs) in prose form. These form the basis for understanding the meaning of the information flowsand provide a basis for the stage 3 switching Recommendations.Note The relationship between the FEAs and the elementary

28、 functions (EFs), as listed in Recommenda-tion I.310 is for further study.Step 2.5 Allocation of functional entities to physical locationsIn this step, the functional entities and information flows identified in previous steps are allocated to specifictypes of physical locations, e.g. a PABX or an e

29、xchange. Each allocation is called a scenario. The relationshipsupported between two functional entities located in different physical locations must be realized withinprotocol(s) supported between those locations.The detailed procedures and formats used and the concepts needed for the stage 2 descr

30、iption can be found inRecommendations Q.65 and I.310.3.3 Stage 3In stage 3 the information flow and SDL diagrams from the stage 2 output form the basis for producing thesignalling system protocol Recommendations and the switching Recommendations.The steps in stage 3 will need to be repeated for each

31、 service where, because of different allocations offunctional entities to physical locations, different protocols and procedures are needed.The steps in stage 3 are:Step 3.1 Protocols and formatsThe messages needed to support the information flows and the modifications to existing information flowsb

32、etween the nodes are identified and the detailed message elements and procedures are designed into therelevant signalling systems.Step 3.2 Switching and service nodesThe requirements identified for switching functions (functional entity actions) are incorporated into theswitching Recommendations (Q.500-Series).6 Fascicle III.7 Rec. I.130

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1