InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 6_1_07.txt < prev next >

Wrap

Text File | 1991-12-22 | 104.7 KB | 2,290 lines

5i' PART III Recommendations Q.65 to Q.87 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Blanc Montage: PAGE = PAGE BLANCHE SECTION 1 METHODOLOGY Recommendation Q.65 STAGE 2 OF THE METHOD FOR THE CHARACTERIZATION OF SERVICES SUPPORTED BY AN ISDN 1 Introduction 1.1 The overall method for deriving switching and signalling Recommendations for ISDN services consists of three stages and is described in general in Recommendation I.130. This Recommendation (Q.65) describes Stage 2 in detail. _________________________ 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.130 (e.g., executive processes, ele- mentary functions) needs urgent further study. 1.2 Stage 2 of the method takes as its input, the Stage 1 basic and supplementary service descriptions contained in the I.200-Series of Recommendations. The Stage 1 description views the network (this term, in this context, could include some capa- bility in the user equipment) as a single entity which provides these services to the user. The Stage 2 description defines the functions required and their distribution within the network. The Stage 1 user/network interactions are used and interpreted within Stage 2, as illustrated in Figure 1/Q.65. Figure 1/Q.65, p. 1.3 Stage 2 identifies the functional capabilities and the information flows needed to support the service as described in Stage 1. The Stage 2 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 Stage 1. Furthermore, it identifies various possible physical locations for the functional capabilities. The output of Stage 2, which is signalling system independent, is used as an input to the design of signalling system and exchange switching Recommendations. 1.4 This Recommendation describes the five steps of Stage 2 in detail. The order of these steps represents an idealized applica- tion of the method, however, in practice there will of necessity be interactions to define fully the Stage 2 outputs. The Appendix con- tains 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 pro- cedures. 1.5 Stage 2 of the method employs techniques that provide the following desirable characteristics: - 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 Stage 1; - a detailed description of what functions and information flows are to be provided, but not how they are to be implemented; - a single functional specification which can be applied in a number of different physical realizations for provid- ing the service; - requirements for protocol and switching capabil- ities as input to Stage 3 of the method; - consistency, within the ISDN principles, of ser- vice and protocol Recommendations which permits substantial imple- mentation flexibility to Administrations and manufacturers. Note - The Stage 2 description method and specific service work currently address only ISDN user to ISDN user calls in an ISDN. The extensions to interworking with other networks is for further study. 2 Steps of the method 2.1 Step 1 - functional model A functional model is derived for each basic supplementary service. In each case the model is matched to the requirements and characteristics of the service concerned. The functional model used in the Stage 2 description of a ser- vice 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).) The 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 com- pletion of Stage 2. 2.1.1 Functional entities Functional entities are initially derived from an overall understanding of the network functions needed to support the ser- vice. Functional entities are defined as follows: - a functional entity is a grouping of service pro- viding 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; - a functional entity is described in terms of the control of one instance of a service (e.g., one call or one connec- tion); - a functional entity is visible to other func- tional entities that need to communicate with it to provide a ser- vice (i.e., functional entities are network addressable entities); - a functional model may contain functional enti- ties of different types. The type of a functional entity is charac- terized by the particular grouping of functions of which it is com- posed. Thus two or more functional entities are said to be of the same type if they consist of the same grouping of functions; - a separate functional entity type is normally defined for each different grouping of functions that may be dis- tributed 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; - 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.2 Functional entity relationships Services are supported by the cooperative actions of a set of functional entities. Cooperation requires that communication rela- tionships be established. - Each communicating pair of functional entities in a specific service functional model is said to be in a relation- ship. - 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. - 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. - 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 func- tional 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. - 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.3 Derivation of the functional model Based on the above definitions the functional model for a par- ticular service is derived using the following criteria and guide- lines: - 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 actu- ally to offer the service; - 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 func- tional entity actions, information flows and the range of physical locations for functional entities; - 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. Figure 2/Q.65 illustrates a functional model. Figure 2/Q.65, p. 2.1.4 Relationship between basic and supplementary service models The functional model for a supplementary service is based upon, and includes at least part of a basic service model. The 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. The model for some supplementary services may not require the definitions of additional functional entities (e.g., when the ser- vice 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 sup- plementary service model will typically involve additional exten- sions to basic service functional entities and their relationships. The 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. A 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 connec- tion) that is controlled by the basic service. A functional grouping should be a separate functional entity if it is potentially assignable to more than one location in rela- tion 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). Figure 3/Q.65 illustrates these relationships. Figure 3/Q.65, p. 2.2 Step 2 - information flow diagrams 2.2.1 Identification of information flows The distribution of the functions required to provide a ser- vice, as defined by the functional model, requires that interac- tions occur between functional entities. Such an interaction is referred to as an "information flow" and will have a name descrip- tive of the intent of the information flow. Information flow diagrams are created to contain all the information flows necessary for typical cases of succesful opera- tion of the service. Information flow diagrams may need to be created as appropriate for other cases. Figure 4/Q.65 illustrates the general form of an information flow diagram for a basic or sup- plementary service. Information 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 require- ments between the functional entities of the basic service representation, and this should be described. Figure 4/Q.65, p. Notes to Figure 4/Q.65 Note 1 - Receipt and emission of user inputs/outputs and informa- tion flows are shown by horizontal lines across the relevant functional entity columns. Conversely, the absence of a line indi- cates no receipt or emission. Note 2 - A reference number is assigned to each point in the overall sequence at which functional entity actions are shown. Note 3 - A brief description of the most significant functional entity actions is shown on the diagram. Note 4 - Information 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., req.ind) written below line in lower case. For unconfirmed informa- tion 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. Note 5 - If 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, follow- ing the information flow name. Note 6 - In a particular functional entity column: - 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 Action C, for example, cannot be carried out before ESTABLISH X is received; - similarly, actions shown above a line represent- ing 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 Actions A and B are both com- pleted. No implications regarding the order of execution of Actions A and B are intended; - actions shown below a line representing the emis- sion of a user output or information flow do not need to be com- pleted 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 Action E may be executed before, after or in parallel with the emission of the "request" part of the CHECK information flow. Note 7 - The Stage 1 service interactions are inputs to and outputs from the Stage 2 information flow diagram. Stage 1 service interactions from the user are either of the form XXXXX.req or XXXXX.resp. Stage 1 service interactions to the User are either of the form XXXXX.ind or XXXXX.conf. 2.2.2 Definition of individual information flows The semantic meaning and information content of each informa- tion 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. Confirmed 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. When interacting functional entities are implemented in physi- cally separate locations, information flows will normally be con- veyed by signalling system protocols. When interacting functional entities are implemented in the same location, information flows are internal and do not effect signalling systems protocols. 2.3 Step 3 - SDL diagrams for functional entities SDL 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) informa- tion 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. The inputs to and outputs from the SDL diagram for a func- tional entity are information flows. The Stage 3 definition work will make use of these information flows to define signalling sys- tem output and input primitives (see Figure 5/Q.65). Thus, signal- ling system SDL descriptions are precisely related to and derived from the Stage 2 information flows and functional relationships which the signalling system is designed to support. Figure 5/Q.65, p. 2.4 Step 4 - functional entity actions The Stage 2 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 infor- mation flow diagrams and SDL diagrams by brief prose statements, or separately using reference numbers. 2.5 Step 5 - allocation of functional entities to physical locations In Step 1, a functional model consisting of functional enti- ties, each of which has a well defined relationship to the others, is defined for each basic and supplementary service. Step 5 is an allocation of these functional entities to physical locations and defines all relevant physical implementations, henceforth called scenarios. More 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 func- tional entity could be located either in an ISPBX or in an exchange. For the allocation of functional entities, it should be noted that: a) a functional entity may in principle, be allo- cated to any physical location; b) a number of functional entities may be allo- cated to the same physical location; c) for every supplementary service, network scenarios which include the location of its basic service func- tional entities should be defined; d) different physical locations of functional enti- ties may imply minor differences in node capabilities (e.g., the transmission path switch-through actions may depend on whether the access is in an exchange or an ISPBX); e) the relationships between pairs of functional entities, according to the functional model used, should be invari- ant for all of the recommended scenarios. Item e) implies e.g., that the information flows for a supple- mentary service would not be affected by a re-allocation of one or more of the required functional entities from public network exchange to an ISPBX or viceversa. All identified scenarios will be considered in Stage 3 for definition of signalling protocols, switching capabilities and ser- vice centre capabilities. APPENDIX I (to Recommendation Q.65) Formats and graphical conventions used in the Stage 2 service description I.1 General This Appendix describes the structure and conventions to be used when creating a Stage 2 description of a particular service. It describes the contents of each section and the graphical conven- tions to be used. I.1.1 Introduction Each Stage 2 service definition starts with an introduction. The introduction includes the definition of the service from the Stage 1 recommendation, plus any further sentences needed for cla- rification or to give extra background information. The Stage 1 recommendation number is included. I.2 Steps of the method I.2.1 Step 1 - identification of a functional model I.2.1.1 Functional model description This section contains a description of the functional model of this service (i.e. there is one model for each service). The func- tional model identifies and names the individual functional enti- ties and their types. It also identifies the relationships and relationship types between communicating functional entities. Func- tional 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. The relationship types are numbered r1, r2, r3etc., for ease of reference (see Figure 3/Q.65 for an example). I.2.1.2 Description of functional entity "x" This paragraph provides a brief prose description of the func- tional entity "x". Each functional entity identified in the model has a corresponding section and prose description. In 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 com- paring the models. This relationship should be clearly indicated in accordance with the guidelines of S 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. I.2.2 Step 2 - information flow diagrams I.2.2.1 Identification of information flows This paragraph contains information flow (arrow) diagrams describing the information flows between the functional entities of the model. See Figure 4/Q.65. The purpose of this section is to define in a precise and descriptive manner, the successful opera- tion of the service. This may require a number of arrow diagrams depending on the service. Explanatory prose description may also be provided where useful. The following guidelines are observed in drafting these infor- mation flow diagrams: - vertical columns represent each of the functional entities identified in the functional model for the service. Infor- mation 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; - 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 Figure 5/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 Stage 2 SDL and the SDL of the underlying signalling system. Further details on drafting conventions can be found in the notes to Figure 4/Q.65. A reference number uniquely identifies a particular point in the Stage 2 information flow sequence and appears on the informa- tion flow diagram at that point. It also serves as a pointer to a description (see S I.2.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. Each number is of the form NNN and is a decimal number assigned by the drafter of the Stage 2 description, which identi- fies a particular point in the Stage 2 procedural description (arrow diagrams and SDL) at which functional entity actions are described. This number is unique within the Stage 2 description of a par- ticular service (all variants). I.2.2.2 Definition of information flow name I.2.2.2.1 Meaning of information flow name This paragraph 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 indi- cate if this is confirmed or unconfirmed information flow. If con- firmed, the meaning of the confirmation is also identified. I.2.2.2.2 Information content of information flow name This paragraph 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. I.2.3 Step 3 - SDL diagrams for functional entities This paragraph contains an SDL diagram for each of the func- tional entities identified in the functional model in S I.2.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 I-1/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. Figure I-1/Q.65, p. The reference numbers used in the relevant information flow diagrams (see S I.2.2.1) are also used in the SDL diagrams. Where a group of actions appears only on the SDL diagram, a reference number is also assigned. Each 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 description (see S I.2.4) of the functional entity actions required at this point in the sequence. The functional entity SDL diagrams employ conventions and pro- cedures of SDL as described in Recommendation Z.100. An extract of Z.100 follows to identify briefly the use of some of these con- ventions in the context of the Stage 2 service description. Diagrammes, p. I.2.4 Step 4 - functional entity actions This paragraph contains descriptions of actions required for each functional enity and is identified by the reference number, as described in SS I.2.2.1 and I.2.3. The presentation form for functional entity actions is illus- trated in Figure I-2/Q.65. Figure I-2/Q.65 [T1.65], p. (a traiter comme tableau MEP) I.2.5 Step 5 - allocation of functional entities to physi- cal locations This paragraph describes the possible scenarios for the physi- cal location of the functional entities shown in the functional model of the service. They are presented in a matrix form. The 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. The conventions used for the matrix are illustrated in Figure I-3/Q.65. Possible physical locations and their corresponding symbolic representation are: - Terminal equipment; Type 1 or terminal adapter: TE - Network termination; Type 2: NT2 (typically in ISPBX) - Local exchange: LE - Transit exchange: TR - Service centre: SC Figure I-3/Q.65, p. 9 Figure I-3/Q.65 [T2.65], p. 10 (a traiter comme tableau MEP) SECTION 2 BASIC SERVICES Recommendation Q.71 ISDN 64 kbit/s CIRCUIT MODE SWITCHED BEARER SERVICES 1 Introduction 1.1 General This Recommendation provides information on the functions in ISDN entities and the information flows between the entities which are required to provide en-bloc call set-up and call release pro- cedures for circuit mode switched 64 kbit/s, 8 kHz structured bearer services. Such services include: - speech information transfer, - 3.1 kHz audio information transfer, - unrestricted information transfer, - alternate speech/unrestricted information transfer. Information about digit-by-digit call set-up, in-call rear- rangement, relationship to and interworking with Teleservices, interworking with other networks and connections involving users with multipoint configurations is not included but is expected to be added to this Recommendation at a later date. 1.2 Definitions of services 1.2.1 speech information transfer (Recommendation I.231, S 1) This bearer service category is intended to support speech. The digital signal at the S/T reference point is assumed to conform to the internationally agreed encoding laws for speech (i.e. Recommendation G.711 A-law, u-law) and that the network may use processing techiques appropriate for speech such as analogue transmission, echo cancellation and low bit rate encoding. Hence, bit integrity is not assured. This bearer service is not intended to support modem derived voiceband data. All CCITT Recommendations for the transfer of speech informa- tion in the network apply to this service. 1.2.2 3.1 kHz audio information transfer (Recommendation I.231, S 2) This bearer service corresponds to the service which is currently offered in the PSTN. This bearer service provides the transfer of speech and for the transfer of 3.1 kHz bandwidth audio information such as voiceband data via modems, groups I, II and III facsimile informa- tion (see Note). The digital signal at the S/T reference point is assumed to conform to the internationally agreed encoding laws for speech A-law, u-law, i.e. Recommendation G.711. Connec- tions provided for this service should provide for the transfer of the information indicated above. (This means that the network may include speech processing techniques provided that they are appropriately modified, or functionally removed prior to non-speech information transfer.) The control of echo control devices, speech processing services etc. is only made by use of a 2100 Hz (disa- bling) in-band tone. All CCITT Recommendations for the transfer of speech informa- tion in the network apply to this service. Note - The maximum modem bit rate that can be used by users in applications of this bearer service depends on the modulation standard employed by the user and on the transmission performance within, or between, different Administrations. The extent of sup- port is a network, or bilaterally agreed matter. 1.2.3 unrestricted information transfer (Recommendation I.231, S 3) An unrestricted bearer service provides information transfer without alteration between S/T reference points. It may, therefore, be used to support various user applications. Examples include: 1) speech (Note 2); 2) 3.1 KHz audio (Note 2); 3) multiple subrate information streams multiplexed into 64 kbit/s by the user; 4) transparent access to an X.25 public network (Recommendation I.462, case a). User information is transferred over a B channel: signalling is provided over a D channel. Note 1 - During an interim period some networks may only sup- port restricted 64 kbit/s digital information transfer capability, i.e. information transfer capability solely restricted by the requirement that the all-zero octet is not allowed. For interwork- ing the rules given in Appendix 1 of Recommendation I.430 should apply. The interworking functions have to be provided in the net- work with restricted 64 kbit/s capability. The ISDN with 64 kbit/s transfer capabilities will not be affected by this interworking, other than conveying the appropriate signalling message to and from the ISDN terminal. Note 2 - Whilst speech and 3.1 kHz audio have been given as one application for this bearer service, it is recognized that it is the responsibility of the customers to ensure that a compatible encoding scheme is in operation. Customers should also recognize that no network provision can be made for the control of such items as echo and loss, as the network is unaware of the application in use. Furthermore, the quality of service attribute for information transfer delay will indicate the suitability of a particular ver- sion of this bearer service for speech. 1.2.4 alternate speech/unrestricted information transfer (Recommendation I.231, S 4) The service provides the alternate transfer at either speech of 64 kbit/s unrestricted digital information with the same call. The request for this alternate capability and the initial mode desired by the user must be identified at call set-up time. This service must be provided for the support of multiple capability terminals or single capability terminals. Note - Initially, this service will only be applicable to multiple capability terminals. The use of this service by, and the network support of, single capability terminals is for further study (e.g., how a user changes terminals). All references to sin- gle capability terminals reflect possible future enhancements and are subject to change and have only been included for information. 1.3 Service invocation Users indicate their required bearer service capabilities at the time of call set-up by including appropriate information in the service request sent to the network via the user/network signalling channel. Subsequent interactions involving status and control information also occur using the signalling channel. However, tones and announcements associated with speech and 3.1 kHz audio information services are sent to the user over the 64 kbit/s user access channel used for the call. 2 Call set-up and release 2.1 Functional model Figue 2-1/Q.71, p. CCAs are functional entities that serve the users and are responsible for initiating functional requests and interacting with CCs. CCs are functional entities that cooperate with each other to provide the services requested by the CCAs. r1and r2are relation- ships between functional entities wherein information flows occur in order to process call attempts or service requests. 2.1.1 Description of the call control agent (CCA) func- tional entity The CCA functional entity supports the functionality to: a) access the service-providing capabilities of the CC entities, using service requests for the establishment, manipu- lation and release of a single call (e.g. set-up, transfer, hold, etc.). b) receive indications relating to the call from the CC entity and relay them to the user. c) maintain call state information as perceived from this functional end-point of the service (i.e, a single-ended view of the call). 2.1.2 Description of the call control (CC) functional entity The CC functional entity supports the functionality to: a) establish, manipulate and release a single call (upon request of the CCA entity). b) associate and relate the CCA entities that are involved in a particular call and/or service. c) manage the relationship between the CCA enti- ties involved in a call (i.e. reconcile and maintain the overall perspective of the call and/or service). 2.2 Information flows required for en-bloc and digit-by-digit sending call set-up and call release 2.2.1 Information flow diagrams Information flow diagrams for 64 kbit/s circuit mode switched bearer service call setup and call release are shown in Figures 2-2/Q.71 through 2-6/Q.71: - Figure 2-2/Q.71 shows a successful call set-up using en-bloc sending; - Figures 2-3/Q/.71 and 2-4/Q.71 are reserved to show call set-up procedures for digit-by-digit sending cases; - Figure 2-5/Q.71 shows normal clearing initiated by a calling party disconnection; - Figure 2-6/Q.71 shows normal clearing initated by a called party disconnection. Figure 2-2/Q.71, p. 12 a l'italienne Figure 2-5/Q.71, p. 13 a l'italienne Figure 2-6/Q.71, p. 14 a l'italienne Notes to Figures 2-2/Q.71 through 2-9/Q.71 Note 1 - Through connection is dependent on the physical location of the functional entity: a) Originating local exchange - i) for 3.1 kHz audio bearer service, speech and telephony services, backwards only or both directions, depending on the approach adopted by the Administration or RPOA. ii) for 64 kbit/s unrestricted information transfer, backwards only, except for own-exchange calls, which may be either backwards only or in both directions at the discretion of the Administration or RPOA. b) Transit exchange - both directions. c) Terminating local exchange - no through connec- tion at this stage of call set-up, except as a national option for certain classes of users, e.g. PABXs. d) NT2 - may through connect as required. Note 2 - If not already done, complete the through connection in both directions. Note 3 - The method of initiating and stopping charging will depend on the Administration's method of charging for service (e.g. pulse metering, recording call detail and billing, etc.). The charging function may be performed at different entities at the discretion of the Administration and/or RPOA. Note 4 - Further study is required on the possible inclusion of an entity from/to which information is passed and on the information flows themselves. The "Report" indications may or may not be sent to the user terminal and/or to the user depending on the terminals involved. Note 5 - The intended use of the service (transfer capability required, e.g. speech, 3.1 kHz audio, unrestricted or alternate speech/unrestricted information transfer) must be indicated as an element of the call SETUP information flow from the CCA to the CC. Note 6 - Tones are used with speech and 3.1 kHz bearer services and telephony. The use of disconnect tone is a national option. 2.2.2 Definition of information flows 2.2.2.1 CONNECTED req.ind is used to acknowledge that a previ- ously sent SETUP resp.conf has been received and accepted. This is an uncomfirmed information flow within the r1 relationship and is sent from the CC to the CCA. 2.2.2.2 DISCONNECT req.ind is used to notify that the end user has disconnected from the connection or cannot be connected (e.g. the called user is busy). This is used to solicit a confirmed release of local channels and other resources associated with the connection. In general, it will not always result in immediate release of the connection and related resources. DISCONNECT req.ind is not confirmed and appears within relationship r1. The following item of information is conveyed with the DISCON- NECT req.ind information flow: Item Relationship Req.ind Cause r1 mandatory 2.2.2.3 PROCEEDING req.ind optionally reports that the received connection set-up is valid and authorized and that further routing and progressing of the call is proceeding. The user entity is not required to provide this indication. This information flow is not confirmed and appears within relationship r1. The following item of information may be conveyed with the PROCEEDING req.ind information flow: Item Relationship Req.ind Channel ID r1 optional 2.2.2.4 RELEASE req.ind and resp.conf is used to free the resources associated with the call/connection such as call refer- ences and channels. This is a confirmed information flow whose con- firmation indicates that all resources previously associated with the connection have been freed. It appears within relationship r1and r2. The following item of information is conveyed with the RELEASE req.ind and resp.conf information flows: Item Relationship Req.ind Resp.conf Cause r1, r2 mandatory mandatory 2.2.2.5 REPORT req.ind is an information flow that is used to report status and/or other types of information across the network. The type of information may be indicated (e.g. alerting, suspended, hold, resume, etc.). This is an unconfirmed information flow within the relationship of both r1and r2. The following items of information are or may be conveyed with the REPORT req.ind information flow: Item Relationship Req.ind Channel ID r1, r2 optional Conn. request r2 optional Called line category r2 mandatory Called line status r2 mandatory Report type r2 mandatory 2.2.2.6 SETUP req.ind is used to request establishment of a connection. This is a confirmed information flow and SETUP resp.conf is used to confirm that the connection has been esta- blished. The request for establishment of a connection can be ori- ginated by either the network or the user. This information flow is within the r1and r2relationships. The following items of information are or may be conveyed in the SETUP req.ind and SETUP resp.conf information flows: Use Item Relationship Req.ind Resp.conf Protocol info Conn. request r2 optional optional Bearer info Bearer capability r1, r2 mandatory Bearer info Nature of trans. r2 mandatory Bearer info Channel ID r1, r2 mandatory Routing info Called number r1, r2 mandatory Routing info Transit network sel. r1, r2 optional Orig. info Calling line ID r1, r2 optional Term. info Connected line ID r2 mandatory Term. info Connected line status r2 mandatory Access info Low layer compatibility r1 optional Access info High layer compatibility r1 optional 2.2.2.7 SETUP REJECT req.ind is used to notify the CCA that the SETUP req.ind has been rejected. This information is within the r1 relationship. The following items of information are or may be conveyed in the SETUP REJECT req.ind information flow: Item Relationship Req.ind Channel ID r1 mandatory Reject indication r1 mandatory Cause r1 optional 2.2.3 Additional information flows required for digit-by-digit call set-up cases Under study. 2.2.4 Information flow meanings - Summary table The individual semantics of the above information flows, and in particular the relationship between information flow meanings, is summarized in Table 2-1/Q.71. H.T. [T1.71] _________________________________________________ TABLE 2-1/Q.71 { Information flow meanings } _________________________________________________ | | | | | | | | | | Semantics SETUP req. ind. SETUP. resp. conf. SETUP REJECT req. ind. PROCEEDING req. ind. REPORT (Alerting) req. ind. DISCONNECT req. ind. RELEASE req. ind. RELEASE resp. conf. CONNECTED req. ind. ___ Request for connection X ___ Connection accepted by user X ___ Call information complete X X X ___ Connection request accepted X X X ___ Connection request rejected X ___ Called user being alerted X ___ Connection unavailable X X ___ { Demand to disconnect bearer resources } X ___ { Demand to release bearer resources with acknowledgement } X ___ { Disconnected - ready to be released } X X ___ { Bearer resources - released - reallocatable } X ___ Request to terminate call X X ___ Setup response accepted X ___ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 2-1/Q.71 [T1.71], p. 2.3 SDLs The SDLs included in this Recommendation cover only the allow- able (expected) sequences for successful call set-up and release. It is assumed that errors detected by the incoming and outgoing signalling system protocols are handled within those protocol state machines. The call controll states describe the state of the entity in terms of the states of the relationships in both directions (i.e. when describing states related to the relationship "r1- r2" the CC state identifies the states of the relationship over r1and r2). Figure 2-7/Q.71 shows the directional convention used in drawing event symbols. Figure 2-7/Q.71, p. 2.3.1 SDLs for the Call Control Agent (CCA) entity are shown in Figure 2-8/Q.71. 2.3.2 SDLs for the Call Control (CC) entity are shown in Fig- ure 2-9/Q.71. Figure 2-8/Q.71 (page 1 sur 11), p. 17 Figure 2-8/Q.71 (page 2 sur 11), p. 18 Figure 2-8/Q.71 (page 3 sur 11), p. 19 Figure 2-8/Q.71 (page 4 sur 11), p. 20 Figure 2-8/Q.71 (page 5 sur 11), p. 21 Figure 2-8/Q.71 (page 6 sur 11), p. 22 Figure 2-8/Q.71 (page 7 sur 11), p. 23 Figure 2-8/Q.71 (page 8 sur 11), p. 24 Figure 2-8/Q.71 (page 9 sur 11), p. 25 Figure 2-8/Q.71 (page 10 sur 11), p. 26 Figure 2-8/Q.71 (page 11 sur 11), p. 27