WPCL 2BJ|x ` H   x|@  6'6' SECTION 1 METHODOLOGY 2Contents of Recommendation Q.65ă A ,Stage 2 of the method for characterization 1of services supported by an ISDN   H  Page   1.Introduction ..................................................... 7 2.Steps of the method .............................................. 8 Appendix I:Formats and graphical conventions used in the Stage 2 service descriptions ...................................... 19 SECTION 1 METHODOLOGY Recommendation Q.65 X3STAGE 2 OF THE METHOD FOR THE CHARACTERIZATION OF X<SERVICES SUPPORTED BY AN ISDN1ă 1.HIntroduction 1.1HThe overall method for deriving switching and signalling Recommendations for ISDN services consists of three stages and is described in general in RecommendationI.130. This Recommendation (Q.65) describes Stage2 in detail. 1.2HStage 2 of the method takes as its input, the Stage1 basic and supplementary service descriptions contained in the I.200Series of Recommendations. The Stage1 description views the network (this term, in this context, could include some capability in the user equipment) as a single entity which provides these services to the user. The Stage2 description defines the functions required and their distribution within the network. The Stage1 user/network interactions are used and interpreted within Stage2, as illustrated in the following figure: XEFIGURE 1/Q.65 XK X=Stage 1/Stage 2 relationshipă   1 Note Some other CCITT Recommendations (e.g., I.310, I.324) deal with the functional description of the network. The relationship between some of the concepts in this Recommendation (Q.65) (e.g., function entity actions, service providing functions) and those in Recommendation I.310 (e.g., executive processes, elementary functions) needs urgent further study. 1.3HStage2 identifies the functional capabilities and the information flows needed to support the service as described in Stage1. The Stage2 service description will also include user operations not directly associated with a call (e.g., user change of call forwarding parameters via his service interface) as described in Stage1. Furthermore, it identifies various possible physical locations for the functional capabilities. The output of Stage2, which is signalling system independent, is used as an input to the design of signalling system and exchange switching Recommendations. 1.4HThis Recommendation describes the five steps of Stage2 in detail. The order of these steps represents an idealized application of the method, however, in practice there will of necessity be iterations to define fully the Stage2 outputs. The appendix contains detailed formats and graphical conventions to be used. The appendix has a parallel structure to the basic Recommendation. The service specific Recommendations which follow conform to these procedures. 1.5HStage2 of the method employs techniques that provide the following desirable characteristics:   HH© a precise definition of functional capabilities and their possible distribution in network equipment (and in some cases, in user equipment) to support the basic and supplementary services as described in Stage1;  `   8 HH© a detailed description of what functions and information flows are to be provided, but not how they are to be implemented;  `    HH© a single functional specification which can be applied in a number of different physical realizations for providing the service;  `   H HH© requirements for protocol and switching capabilities as input to Stage3 of the method;  `   H HH© consistency, within the ISDN principles, of service and protocol Recommendations which permits substantial implementation flexibility to administrations and manufacturers.  `    Note The Stage2 description method and specific service work currently address only ISDN user to ISDN user calls in an ISDN. The extension to interworking with other networks is for further study. 2.HSteps of the method 2.1HStep 1 functional model ,Ԍ   HA functional model is derived for each basic and supplementary service. In each case the model is matched to the requirements and characteristics of the service concerned. HThe functional model used in the Stage2 description of a service identifies functional entities and the relationships between them. (The concept of functional entity is similar to that of a stored program (not necessarily implemented in software).) H HThe refinement of the initial functional model is carried out by development and/or iteration of steps 2 to 5, as described below. The final functional model represents a result of the completion of Stage 2. 2.1.1HFunctional entities HFunctional entities are initially derived from an overall understanding of the network functions needed to support the service. Functional entities are defined as follows:  H HH© a functional entity is a grouping of service providing functions in a single location and is a subset of the total set of functions required to provide the service. Further work is needed to provide a formal way of identifying service providing functions. In particular the list of elementary functions in Recommendation I.310 should be used as the basis of this study;   HH© a functional entity is described in terms of the control of one instance of a service (e.g., one call or one connection);  `   H HH© a functional entity is visible to other functional entities that need to communicate with it to provide a service (i.e., functional entities are network addressable entities);  `    HH© a functional model may contain functional entities of different types. The type of a functional entity is characterized by the particular grouping of functions of which it is composed. Thus two or more functional entities are said to be of the same type if they consist of the same grouping of functions;  `   8 HH© a separate functional entity type is normally defined for each different grouping of functions that may be distributed to separate physical devices. However, where there is a high degree of commonality between different required groupings it may be convenient to define them as subsets of a single type rather than as different types;  `   H HH© functional entities are derived for each basic and supplementary service. The same functional entity type may occur more than once in a functional model and also may appear in the model of more than one service.  `  2.1.2HFunctional entity relationships   HServices are supported by the cooperative actions of a set of functional entities. Cooperation requires that communication relationships be established.  ( HH© Each communicating pair of functional entities in a specific service functional model is said to be in a relationship.  `    HH© Each interaction between a communicating pair of functional entities is termed an information flow. The relationship between any pair of functional entities is the complete set of information flows between them.  `   ( HH© If a communicating pair of functional entities is located in physically separate devices, the information flows between them define the information transfer requirements for a signalling protocol between the devices.  `    HH© Different communicating pairs of functional entities may have relationships of different types. The type of a relationship is characterized by the set of information flows between two functional entities. The relationships between functional entities FE1 and FE2 and between functional entities FE3 and FE4 are said to be of the same type if they comprise the same set of information flows.  `    HH© Relationships are assigned type identifiers (e.g., r1, r2, r3 etc.) which uniquely identify specific sets of information flows within the functional model of a service. The same relationship type may occur more than once in a functional model.  `  2.1.3HDerivation of the functional model   HBased on the above definitions the functional model for a particular service is derived using the following criteria and guidelines:  H HH© appropriate functional entities are chosen based on knowledge of the variety of anticipated network realizations. All reasonable distributions of functions should be considered, thus leaving the option open to an administration as to how actually to offer the service;  `   H HH© relationship types are initially assigned based on an assessment of the probable nature of the interactions between each pair of functional entities. Revisions to the initial model may be necessary in the light of more detailed definition of functional entity actions, information flows and the range of physical locations for functional entities;  `   H HH© the model for some services may require that a functional entity be replicated a number of times (e.g., tandem functions). The functional model should only describe replications up to the point where no new combinations of external relationships to functional entities are encountered by further replication. Thus, a single functional entity may represent multiple physical tandem entities providing the same functions,  `  HFigure 2/Q.65 illustrates a functional model.  ,Ԍ ;FIGURE 2/Q.65 A 3Example of a functional modelă  h Note 1 FE1, FE2 etc. are functional entities (type A, B, etc.) defined to meet the requirements of the particular service considered. The diagram also includes a functional extension to FE4. Note 2 rl, rj, etc. are relationship types between communicating pairs of functional entities. Note 3 This diagram illustrates the following points:  H HHa)h  a functional model may include more than one FE of the same type (e.g., type B);  `   H Hb)h  a functional model may include more than one relationship of the same type (e.g., rj);   HHc)h  an extension to an FE does not modify its type of relationship to adjacent FEs (e.g., r1).  `   p 2.1.4HRelationship between basic and supplementary service models  8 HThe functional model for a supplementary service is based upon, and includes at least part of a basic service model.  X HThe relationship between the model for a supplementary service and that for a basic service may be derived by comparing the models. How the functional entities of the supplementary service model relate to the functional entities of the basic service model is then clarified. HThe model for some supplementary services may not require the definitions of additional functional entities (e.g., when the service is a manipulation of an already defined service, for which the functionality required to provide the service cannot be remote from a functional entity of the basic service). In such cases, the supplementary service model will typically involve additional extensions to basic service functional entities and their relationships. HThe following guidelines should be followed in resolving whether the functions associated with a supplementary service should be defined in the form of extensions to existing functional entities or in the form of new functional entities. HA grouping of functions within a supplementary service model should be integrated into a basic service functional entity (e.g., see Figure 3/Q.65) if it modifies an object (e.g., call or connection) that is controlled by the basic service. HA functional grouping should be a separate functional entity if it is potentially assignable to more than one location in relation to particular functional entities of the basic service. A functional entity that is separate from a basic service functional entity typically would not require detailed call/connection state information. A separate functional entity may also be characterized by having a transactional relationship with a functional entity of the basic service (e.g., to provide number translation to the basic service functional entity). HFigure 3/Q.65 illustrates these relationships. JFIGURE 3/Q.65 P 2Alternative ways of adding supplementary service functions toă Abasic service functional modelă 2.2HStep 2 information flow diagrams 2.2.1HIdentification of information flows HThe distribution of the functions required to provide a service, as defined by the functional model, requires that interactions occur between functional entities. Such an interaction is referred to as an "information flow" and will have a name descriptive of the intent of the information flow. ,Ԍ HInformation flow diagrams are created to contain all the information flows necessary for typical cases of succesful operation of the service. Information flow diagrams may need to be created as appropriate for other cases. Figure4/Q.65 illustrates the general form of an information flow diagram for a basic or supplementary service. HInformation flow diagrams for supplementary services should not unnecessarily duplicate information flow descriptions that are part of a basic service. However, it may be that a supplementary service description identifies additional information flow requirements between the functional entities of the basic service representation, and this should be described. JFIGURE 4/Q.65 P ?Example of information flow diagramă 9(the example shows part of an information flow =diagram corresponding to the functional Amodel examples in Figure 2/Q.65 Notes to Figure4/Q.65 (1)HReceipt and emission of user inputs/outputs and information flows are shown by horizontal lines across the relevant functional entity columns. Conversely, the absence of a line indicates no receipt or emission. (2)HA reference number is assigned to each point in the overall sequence at which functional entity actions are shown. (3)HA brief description of the most significant functional entity actions is shown on the diagram. (4)HInformation flows are shown as arrows with the name of the information flow above and below the arrow. The descriptive name is written in capitals above the arrow and the label (e.g., reg ind) written below line in lower case. For unconfirmed information flows and the "request" part of confirmed information flows the label "req.ind" is shown in lower case below the information flow arrows. For the "confirmation" part of confirmed information flows the label "resp.conf" is used. (5)HIf knowledge of one or more of the items of information content in the information flow is important to the understanding of the diagram (i.e. the name of the information flow is not enough), the items may be shown in lower case in brackets, following the information flow name. (6)HIn a particular functional entity column:   HH© actions shown below a line representing the receipt of a user input or information flow are dependent upon that receipt (i.e. they cannot be carried out beforehand). Thus ActionC, for example, cannot be carried out before ESTABLISH X is received;  `    HH© similarly, actions shown above a line representing the emission of a user output or an information flow must be completed prior to the emission of the information flow. Thus, ESTABLISH X cannot be emitted until ActionsA and B are both completed. No implications regarding the order of execution of ActionsA and B are intended;  `   8 HH© actions shown below a line representing the emission of a user output or information flow do not need to be completed before emission (although in many practical implementations they may). No constraint on the relative order of the emission and the action which immediately follows it is intended. Thus ActionE may be executed before, after or in parallel with the emission of the "request" part of the CHECK information flow.  `   8 (7)HThe Stage1 service interactions are inputs to and outputs from the Stage2 information flow diagram. Stage1 service interactions from the user are either of the form XXXXX.req or XXXXX.resp. Stage1 service interactions to the User are either of the form XXXXX.ind or XXXXX.conf. 2.2.2HDefinition of individual information flows  ,ԌHThe semantic meaning and information content of each information flow is determined. An individual information flow may be identified as requiring confirmation, and if so, it requires a return information flow of the same name. HConfirmed information flows take the form of a request for an action (in one direction) and confirmation that the action has been carried out (in the return direction). Confirmed information flows are typically required for synchronization purposes. The two main cases are when requesting allocation and/or release of a shared resource. HWhen interacting functional entities are implemented in physically separate locations, information flows will normally be conveyed by signalling system protocols. When interacting functional entities are implemented in the same location, information flows are internal and do not effect signalling system protocols. 2.3HStep 3 SDL diagrams for functional entities   HSDL diagrams are used to provide a complete description of actions for each functional entity in relation to the associated information flows. They are based on (and consistent with) information flow diagrams but also cover more complex cases including cases of unsuccessful and/or abnormal operation. Consideration of such cases may result in the need to define new information flows. HThe inputs to and outputs from the SDL diagram for a functional entity are information flows. The Stage3 definition work will make use of these information flows to define signalling system output and input primitives (see Figure5/Q.65). Thus, signalling system SDL descriptions are precisely related to and derived from the Stage2 information flows and functional relationships which the signalling system is designed to support. Note The primitives to the underlying signalling system are derived from the information flows between the functional entities. HIFIGURE 5/Q.65 HO H4Relationship of primitives, information flows and SDLsă 2.4HStep 4 functional entity actions HThe Stage2 actions performed within a functional entity, from the reception of each information flow to the transmission of the next resulting information flow, are identified and listed. The need for a generic list of functional Entity Actions (FEAs), to ensure consistency between different services, is an urgent item for further study. All externally visible actions (those which are explicitly or implicitly notified to other functional entities) are included. The identified actions are then represented on the information flow diagrams and SDL diagrams by brief prose statements, or separately using reference numbers. 2.5HStep 5 allocation of functional entities to physical locations HIn Step1, a functional model consisting of functional entities, each of which has a well defined relationship to the others, is defined for each basic and supplementary service. Step5 is an allocation of these functional entities to physical locations and defines all relevant physical implementations, henceforth called scenarios. HMore than one scenario may be defined for one functional model so that administrations will have options as to where the service is actually provided. For example, a supplementary service functional entity could be located either in an ISPBX or in an exchange. HFor the allocation of functional entities, it should be noted that:   HHa)h  a functional entity may in principle, be allocated to any physical location;  `   ( HHb)h  a number of functional entities may be allocated to the same physical location;  `   H HHc)h  for every supplementary service, network scenarios which include , the location of its basic service functional entities should be defined;  `    HHd)h  different physical locations of functional entities may imply minor differences in node capabilities (e.g., the transmission path switchthrough actions may depend on whether the access is in an exchange or an ISPBX);  `    HHe)h  the relationships between pairs of functional entities, according to the functional model used, should be invariant for all of the recommended scenarios.  `    HItem e) implies e.g., that the information flows for a supplementary service would not be affected by a reallocation of one or more of the required functional entities from public network exchange to an ISPBX or viceversa. HAll identified scenarios will be considered in Stage3 for definition of signalling protocols, switching capabilities and service centre capabilities. HAppendix I M A(to Recommendation Q.65) M 3Formats and graphical conventions used in the Stage 2ă Dservice descriptionă 1.HGeneral HThis appendix describes the structure and conventions to be used when creating a Stage2 description of a particular service. It describes the contents of each section and the graphical conventions to be used. 1.1HIntroduction HEach Stage2 service definition starts with an introduction. The introduction includes the definition of the service from the Stage1 recommendation, plus any further sentences needed for clarification or to give extra background information. The Stage1 recommendation number is included. 2.HSteps of the method 2.1HStep 1 identification of a functional model 2.1.1HFunctional model description HThis section contains a description of the functional model of this service (i.e. there is one model for each service). The functional model identifies and names the individual functional entities and their types. It also identifies the relationships and relationship types between communicating functional entities. Functional entities are represented by circles and the relationship between two communicating functional entities is identified by a line joining them. The functional entity type is contained within the circle. Each functional entity is given a unique label (e.g., FE1, FE2) adjacent to the circle. HThe relationship types are numbered r1, r2, r3 etc., for ease of reference (see Figure3/Q.65 for an example). 2.1.2HDescription of functional entity "x" HThis section provides a brief prose description of the functional entity "x". Each functional entity identified in the model has a corresponding section and prose description. HIn the case of supplementary service it is necessary to describe how the model for this supplementary service relates to that of the basic service. This relationship may be derived by comparing the models. This relationship should be clearly indicated in accordance with the guidelines of section 2.1.4 of the main body of the Recommendation. A prose explanation may also be useful (e.g., to describe that certain supplementary service functions actually form a modular extension to a functional entity defined in the basic service). See Figure 3/Q.65 for an example. 2.2HStep 2 information flow diagrams 2.2.1HIdentification of information flows HThis section contains information flow (arrow) diagrams describing the information flows between the functional entities of the model. See Figure4/Q.65. The purpose of this section is to define in a precise and descriptive manner, the successful operation of the service. This may require a number of arrow diagrams depending on the service. Explanatory prose description may also be provided where useful. HThe following guidelines are observed in drafting these information flow diagrams:   HH© vertical columns represent each of the functional entities identified in the functional model for the service. Information flows are shown is descending order in which they are to occur in the processing of a call. The order of functional entity actions shown between information flows is not significant;  `    HH© an information flow will be characterized in the arrow diagrams as being associated with the terms request/indication or response/confirmation. This is reflected in the primitive which is communicated to the underlying signalling system as illustrated in Figure5/Q.65. The primitive name is, in general, a direct derivation of the information flow name. The terms "req.ind" and "resp.conf" are part of the information flow name. The terms are shown in association with the information flow to show the relation between the Stage2SDL and the SDL of the underlying signalling system.  `    HFurther details on drafting conventions can be found in the notes to Figure4/Q.65. HA reference number uniquely identifies a particular point in the Stage2 information flow sequence and appears on the information flow diagram at that point. It also serves as a pointer to a description (see section2.4 below) of the actions required at this point in the sequence. A brief description of the functional entity actions will also appear on the relevant part of the information flow diagrams. The reference numbering scheme to be used is described below. HEach number is of the form NNN and is a decimal number assigned by the drafter of the Stage2 description, which identifies a particular point in the , Stage2 procedural description (arrow diagrams and SDL) at which functional entity actions are described. HThis number is unique within the Stage2 description of a particular service (all variants). 2.2.2HDefinition of information flow name 2.2.2.1 Meaning of information flow name HThis section defines the meaning of the information flow in terms of the actions, operations, events, etc. which are requested and/or reported by the information flow. The description will indicate if this is a confirmed or unconfirmed information flow. If confirmed, the meaning of the confirmation is also identified. 2.2.2.2 Information content of information flow name HThis section defines the information content conveyed by the information flow. This consists of elements of static information (e.g., called address). For confirmed information flows, a set of elements is required in each direction. The name of each element, its range of values and the relationships where it occurs should be identified. 2.3HStep 3 SDL diagrams for functional entities HThis section contains an SDL diagram for each of the functional entities identified in the functional model in section2.1. If the provision of the service implies a modular extension to the SDL diagram for a functional entity of the basic service, then the SDL describing the extension is provided (e.g., see Figure I1/Q.65). This may require some modification to the basic service SDL to show the extension and the point in the basic service SDL where it occurs. Alternative approaches which do not require modification ("hooks") in the basic service SDL are for further study. FFIGURE I1/Q.65 M 7An example technique to describe extension toă :functional entity of the basic serviceă HThe reference numbers used in the relevant information flow diagrams (see section2.2.1 above) are also used in the SDL diagrams. Where a group of actions appears only on the SDL diagram, a reference number is also assigned. HEach group of actions is in a concise form in a single task box on the SDL diagrams. As before the associated reference number points to a  h description (see section2.4 below) of the functional entity actions required at this point in the sequence. HThe functional entity SDL diagrams employ conventions and procedures of SDL as described in RecommendationZ.100. An extract of Z.100 follows to identify briefly the use of some of these conventions in the context of the Stage2 service description. H A signal conveying a variable received from the preceding (in the context of call setup) functional entity or user. H A signal conveying a variable sent to the subsequent functional entity or user. H A signal conveying a variable received from the subsequent functional entity or user. H A signal conveying a variable sent to the preceding functional entity or user. XX X.X XX A set of alphanumeric characters which constitute the name Hof an object (e.g., a state, signal, variable or timer). 'XX XXX' An informal text.   HHEach process must begin with a START symbol. The START symbol is empty.  `  /*XXXXXX*/ Designates a note. ]H Designates a note. 2.4HStep 4 functional entity actions   HThis section contains descriptions of actions required for each functional entity and is identified by the reference number, as described in sections2.2.1 and 2.3.  H HThe presentation form for functional entity actions is illustrated in FigureI2/Q.65. H)   H- Functional entity FE2  H)   ,ԌH- Reference number: NN1  H)   H- Process service request  H)   H3 Receive and acknowledge user's service request  H3 Interact with user to accumulate information  H3 Select network access resource  H3 Reserve facilities, both directions, as required  H)   H- Reference number: NN2  H)   H3 Interact with user to obtain call address  H3 Determine and indicate end of dialling  H)   HN HGFIGURE I2/Q.65 HN H4Example of descriptions of functional entity actionsă HN H-2.5HStep 5 allocation of functional entities to physical locations HThis section describes the possible scenarios for the physical location of the functional entities shown in the functional model of the service. They are presented in a matrix form. HThe matrix represents the functional entities of the service description functional model as columns and each scenario as a row. The points of the matrix identify the physical location to which that functional entity is allocated for that scenario. HThe conventions used for the matrix are illustrated in FigureI3/Q.65. HGFIGURE I3/Q.65 HN H=Example of a scenario matrix formată HPossible physical locations and their corresponding symbolic representation are: HHTerminal equipment; Type 1 or terminal adapter:TE  ` HNetwork termination; Type 2:NT2 (typically an ISPBX) HLocal exchange: LE HTransit exchange: TR HService centre: SC