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
