============================================================ Question 1/XI - New switching and and signalling techniques Considering (a) that the research into a variety of new switching techniques is already being pursued by many administrations, RPOAs and SIOs and the impact of technologies such as asynchronous time division multiplexing and optical switching could have a profound impact on the evolution of telecommunications networks; (b) that the ISDN should evolve to also satisfy the broadband telecommunications services requirements, taking into account new transmission and switching techniques; (c) that the ISDN may also evolve to incorporate advanced capabilities to provide the multi-media multipoint and distribution services including broadband connections; (d) that the circuit-mode and packet-mode capabilities are to be provided by the same network applying integrated techniques (e.g., ATM*); (e) that the availability of very high bandwidth transmission systems utilizing optical fibre could have a significant impact on the structure of future networks; (f) that there is a trend towards the separation of the intelligence required to support new and enhanced features, from that required to support basic circuit switching; (g) that new telecommunications service requirements are continuously emerging; (h) that the demand for the transport and processing of a wide variety of data services is growing rapidly, and further considering (i) that the network signalling capabilities should be enhanced according to the evolution of the ISDN including, amongst others, the following aspects: -low layer protocols, which absorb the difference of capabilities depending on the transfer mode and guarantees secure signalling information transfer, taking into consideration the following points: -various parameters, e.g., maximum frame length, maximum number of outstanding frames, timer values, - error correction method taking into account broadband applications of the ISDN, -identification of logical connections, e.g. whether to use an independent channel identifier or to rely on the ATM call address in case of full ATM, * ATM = Asynchronous Time Multiplexing. -the requirements on the signalling aspects of call control as defined in the separation into call control and bearer connection control protocols, taking into consideration, amongst others, the following points: -identification of various parameters to be decided through signalling, i.e., parameters related to the low layers (e.g., ATM and adaptation layers) including logical channel number, QOS* parameters such as throughput and delay, and dynamic functions to be applied for each connection, and parameters concerning various service attributes, -interactions between user plane, control plane and management plane functions including various primitives, -impact of usage monitoring on out-of-band signalling in case of ATM, -handling of various supplementary services, e.g., handling of user-to- user signalling, especially whether to use control plane or to use an ad hoc connection in the user plane, -application of the concept of callconnection separation to various services including multi-media, multipoint, distribution and interactive control of services. -the signal transport mechanism (e.g., static signalling channel, permanent logical channel or dynamically established channel) and the signalling network configuration (e.g., associated or quasi-associated mode of operation) which guarantee enough capability to provide various telecommunications services with adequate performance, (j) that a common signalling system is to be used in all parts of the network, including the access. What new switching and signalling Recommendations should be made to take account of new and emerging switching and transport techniques? * QOS = Quality of Service. ============================================================ Question 2/XI - Signalling and OAM Protocol Architecture Considering (a) that interworking requirements and the need for convergence between the various signalling and related protocols has given rise to the need for a common protocol architecture; (b) that the OSI reference model, studied by Study Group VII, provides a good framework, but may not necessarily meet all the needs of ISDN signalling protocols; (c) that Study Group XVIII has developed Recommendations I.324 on ISDN network architecture and I.320 on ISDN protocol reference model and that close cooperation will be maintained with Study Group XVIII; (d) that Study Group XVIII has developed Recommendation I.320 on the ISDN Protocol Reference Model; (e) that in relation to ISDN overall signalling architecture, there is a trend towards the "intelligent network" in which the intelligence required to support new and enhanced features for services and OAM functions is separated from that required to support basic circuit switching; (f) that allocation of functions to functional entities and application specific procedures to implement specific supplementary services and remote OAM functions will be studied under Questions CXI and DXI; (g) that in relation to mixed publicprivate network signalling architecture: i) hybrid privatepublic networks, virtual private networks, centrex and mobile networks will play an increasingly important role in the coming information age especially in the business sector, ii) CCITT ISDN Recommendations are intended to be applicable nationally and internationally not only to public ISDNs but also to private ISDNs; (h) that there is a need to let the existing protocols interwork with each other in a logical manner; (i) that there is a need to maximize commonality and uniformity in the new selection and definition of higher and lower layer protocols for new applications for economizing protocol selection and definition efforts and associated software development costs; (j) that there is a need to provide a bridge and guidelines for various protocol selection and definition activities in the Study Group; (k) that there is a need to work in close cooperation with Study Group VII and, in particular, to feed back the study results to Study Group VII in charge of OSI reference model; (l) that there is a need to provide a basis for consistency in approach between studies of Question EXI on supplementary services and studies of Question FXI on OAM functions; (m) that there is a need to apply the same set of protocols to public and private ISDNs, thus eliminating the proliferation of signalling protocols; (n) that there is a desire to have a common architecture between fixed and mobile networks; (o) that there is a need to manage and maintain a set of generic operation and ASEs in a central register available for use by different applications and users; (p) that Recommendation 940 has been developed giving a general guideline on the architecture concerning OAM at the ISDN usernetwork interface, What additional Recommendations andor enhancements to existing Recommendations are needed for: Study point a): ISDN call control and OAM protocol architecture With objectives: - to define an architectural framework within which the roles and relationships of existing and new signalling (e.g. DSS 1 and Signalling System No. 7) and OSI protocols is clarified and to provide guidelines for selecting and applying protocols, -to identify requirements and study methods which may be used as a basis reference model to satisfy needs arising from its application to the protocol selection and definition work in the Study Group, so that new protocol selection and definition works for new applications can take a maximum common and unified approach encompassing both supplementary services and OAM functions to facilitate evolution toward centralized control of services ("intelligent network"). Study point b): ISDN overall signalling architecture for supplementary services and OAM functions With an objective: -to produce an overall view of signalling architecture within an ISDN based on the results of studies on Stage 2 network function architecture, which encompasses both supplementary services and OAM functions to facilitate evolution toward centralized control of services ("intelligent network"). Study point c): Clarification of the signalling and OAM protocol requirements for hybrid privatepublic and virtual private networks With objectives: -to provide a basis for determining impacts on specific protocols; -to give the outputs to the Questions related to overall network architecture. The outputs of study points a), b), and c) will provide assistance and requirements to those studying protocol selection (Questions 5XI and 6XI). ============================================================ Question 3/XI - Switching functions and signalling information flows for implementation of basic and supplementary services Considering (a) that a general Recommendation exists on a method for characterizing services and supplementary services (I.130), and that Recommendation Q.65 describes Stage 2 of the method in detail; (b) that the introduction of new types of switching and signalling systems provide an increasing potential for basic and supplementary services; (c) that the need to allow supplementary services to operate throughout the network rather than being restricted to a single model and that they operate consistently also in a hybrid privatepublic, virtual private network and centrex network environment and with mobile networks; (d) that the ISDN access signalling and CCITT Signalling System No. 7 will allow a greater range of information transfer between the network and the user, and within the network; (e) that there is a need to ensure compatibility and consistency between: -the information-flow descriptions and the user-network signalling, -the information-flow descriptions and the inter-network-nodes signalling, -the user-network signalling and the inter network-nodes signalling, -the signalling systems and the switching capabilities; (f) that service centres will become increasingly used in the future; (g) that Stage 1 Recommendations (including packet mode services) are becoming increasingly available; (h) that network architecture studies will continue in the CCITT which could affect the studies on network functions and information flows, and that there will be a need for Stage 2 studies to interact with these architectural studies, further considering (i) that the CCITT has developed SDL for the ambiguous specification and description of the behaviour of telecommunications systems; (j) that CCITT and ISO are specifying further tools, such as abstract syntex notation (X.208) which may be useful in Stage 2 service specifications. 1. What enhancements to Recommendation Q.65 and what possible new Recommendations are necessary to specify the Stage 2 method? including: a) the overall signalling information flow for basic and supplementary services; b) the procedures within networks for the establishment and control of these services; c) a method of classifying basic and supplementary services for a systematic approach to the definition of Stage 2 and Stage 3 descriptions. 2. What new Recommendations and what enhancements to existing Recommendations are necessary in applying the methodology? a) to achieve compatibility and consistency between the switching functions, other network functions, and signalling systems required to implement these services; b) to optimize the balance between switching functions, other network functions and signalling systems required to achieve these services; c) to specify the logic procedures within the exchanges for services and supplementary services which require standardization and when necessary the possible location(s) of functions within the network (e.g., exchanges, terminal or auxiliary devices). Note 1 - This Question requires close cooperation with the present Study Groups I, II, III, VII, VIII, and XVIII. Note 2 - Analysis of services, especially supplementary services, will concentrate on those requiring procedures distributed throughout the network, rather than those capable of being implemented at a single terminal or exchange. This former group of services will include: - services to be operated internationally; - services requiring a unique solution for the purposes of the ISDN. ANNEXES 1 through 7 (to Question 3/XI) (See Contribution COM X7.) ============================================================ Question 4/XI - Switching functions and signalling information flows for implementation of OAM functions Considering (a) that a Recommendation (M.30) exists on the definition of a Telecommunications Management Network (TMN) and that exchanges and signalling systems are a part of that network, and that Recommendation Q.65 describes a methodology for defining information flows and allocation of functions to signalling and switching systems; (b) that the introduction of enhanced switching and signalling systems provide an increasing potential for enhanced maintenance and operations in a TMN; (c) that the ISDN access signalling, CCITT Signalling System No. 7 and packet switching systems will allow a greater range of information transfer between network entities subscriber equipment and OAM centres; (d) that OAM functions may be located in a specialized centres external to the signalling network(s), or in signalling points within the signalling network; and OAM functions may be centralized in specific elements or distributed among several elements; (e) that network architecture studies will continue in the CCITT which could effect the studies on OAM functions and information flows, and that there will be a need for Stage 2 studies to interact with these architectural studies; (f) that there is a need for OAM functions to be defined such that they operate consistently also in a hybrid privatepublic network, virtual private network and centrex environment and with mobile networks; (g) that Stage 1 like descriptions of OAMTMN functions are expected to become available; (h) that there is a need to study the impact on exchange overload characteristics due to common channel signalling traffic, data information transfer between exchanges and remote operations centressystems, etc.; (i) that there may be a need to define managed objects (OSI terminology), and further considering (j) that there is a need to ensure compatibility between: -the information flow descriptions and the user-network signalling systems, -the information flow descriptions and the inter-network- entity signalling systems, -the user-network signalling systems and the inter-network- entity signalling systems, -the signalling systems and the switching and other network entities; (k) that the CCITT has developed SDL for the unambiguous specification and description of the behaviour of telecommunications systems; (l) that CCITT and ISO are specifying other tools, such as abstract syntax notation (Recommendation X.208) which may be used in Stage 2 specifications of OAM functions. Questions 1. What enhancements to Recommendation Q.65 and what new Recommendations are necessary to specify the Stage 2 method for: a) describing the overall signalling information flow for OAM functions in switching and signalling systems, and, b) documenting the procedures for the invocation and control of the OAM functions, c) a method of classifying OAM functions for a systematic approach to the definition of Stage 2 and Stage 3 descriptions? 2. What new Recommendations are necessary in applying the methodology? a) to achieve the compatibility and consistency between operations systems and switching and signalling systems required to implement the OAM functions; b) to specify the procedures within network entities and across the user-network interface for OAM functions which require standardization and when necessary the possible location(s) of OAM functions within the network and at the user-network interface. Note - This Question requires close cooperation with the present Study Groups I, II, IV, VII, XV, and XVIII. ============================================================ Question 5/XI - Application of the Stage 2 Recommendations to the signalling protocols for services Considering (a) that a general Recommendation exists on a method for characterizing services I.130, and the output of Stage 2 of the method consists of Recommendations in the Q.70 and Q.80-Series; (b) that signalling systems will need to evolve to support a range of new basic and supplementary services; (c) that there is a need to coordinate the application of Stage 2 Recommendations to the selection and definitions of protocols, and that functions need to be allocated to both user and network entities, i.e., choice of specific physical scenarios from the Stage 2 Recommendations; (d) that new supplementary services should be able to use the appropriate component parts of Signalling System No. 7, DSS 1, andor other CCITT protocol Recommendations; (e) that there is a need to establish a set of generic operations and ASEs available for use by different applications and users; (f) that compatibility with OSI principles be considered in selecting protocols and in devising generic operations and ASEs; (g) that a means needs to be included for registration, cancellation and modification of services based on input from Stage 2; (h) that the signalling requirements for hybrid privatepublic networks, virtual private networks, centrex and mobile networks needs to be included; (i) that enhancements may be necessary to both the user-network and network signalling protocols to support the ISDN additional packet mode services at Stage 3; (j) that efficient interworking between the service related protocols (e.g., DSS 1 to Signalling System No. 7) needs to be ensured; (k) that updating of Recommendation Q.699 with regard to clarification and correction of technical errors of existing text may be necessary; (l) that close cooperation is needed with other CCITT Questions dealing with: - application of the Stage 2 Recommendation to the protocols for OAM (Question FXI), - OSI protocols, - OAM protocols. What guidance to Stage 3 signalling protocol groups, new Recommendations andor enhancements to existing Recommendations are necessary to meet the current and future signalling requirements of basic and supplementary services and applications used in the evolution of ISDNs? Study points should include: For each service for which a Stage 3 definition is to be provided: -selection of higher andor lower layer protocols needed to support the service and identification of their roles and relationships; -identification where appropriate of common elements of procedure andor application service elements; -identification of common encodings. ============================================================ Question 6/XI - Application of the Stage 2 Recommendations to the signalling protocols for OAM Considering (a) that a methodology is being developed for characterizing OAM, capabilities; (b) that signalling systems may need to evolve to support a range of OAM capabilities; (c) that there is a need to coordinate the application of Stage 2 Recommendations to the selection and definition of protocols, and that OAM functions need to be allocated to both user and network entities i.e., choice of specific physical scenarios from the Stage 2 Recommendations; (d) that the OAM functions should be able to use the appropriate component parts of Signalling System No. 7, DSS 1 and other CCITT protocol Recommendations; (e) that there is a need to establish a set of generic operations and ASEs available for use by different applications and users; (f) that compatibility with OSI principles be considered in selecting protocols and in devising generic operations and ASEs; (g) that means need to be included for the OAM of services and the network based on input from Stage 1; (h) that OAM requirements for hybrid, privatepublic networks, virtual private networks, centrex and mobile networks need to be included; (i) that close cooperation is needed with other CCITT Questions dealing with: -application of the Stage 2 Recommendation to the signalling protocols services (new Question EXI), -OSI protocols, -OAM protocols. What guidance to Stage 3 signalling protocol groups, new Recommendations andor enhancements to existing Recommendations are necessary to meet the current and future signalling and related protocol requirements of OAM? Study points should include: For each OAM function for which a Stage 3 definition is to be provided: -selection of higher andor lower layer protocols needed to support the OAM functions and identification of their roles and relationships; -identification where appropriate of common elements of procedure andor application service elements; - identification of common encodings. ANNEX 1 (to Question 6/XI) Draft Recommendation Q.941 ISDN USER-NETWORK PROTOCOL FOR MANAGEMENT PROTOCOL AND SERVICE SPECIFICATIONS 1. General 3. Services available at the System Management Interface (SMI) 4. Management protocol and information encoding rules 7. The convergence functions 7.1 Features of the convergence functions APPENDIX A (to draft Recommendation Q.941) (to draft Recommendation Q.941) ANNEX 2 (to Question 6/XI) List of open issues The following list of items allows contributing organizations to focus on the open issues that need resolution by this Question. 1) The method by which Fast Select Service can be used to provide a connectionless service to layer 4 is for further study. 2) Access to management services and management information may be subject to access control. Access rights and access control mechanisms need to be further analysed. 3) Should a list of protocols be produced that may be used at each layer of the communication model in the User-Network Interface Management Recommendation? It should be noted that preliminary information on which this list could be generated is contained in the X.220 Recommendation. ============================================================ Question 7/XI - Updating of Q-Series Recommendations (continuation of Question 17/XI studied in 1985-1988) Considering (a) that CCITT Signalling Systems are generally implemented over a relatively long period after their specifications; (b) that field trials and the subsequent operational experience with CCITT Signalling Systems, especially with newer systems, frequently lead to a modification of the existing Recommendations; (c) that the Telephone User Part of Signalling System No. 7 (TUP) is considered to be mature and stable and has been implemented by a number of administrationsRPOAs; (d) that continuing study is needed to cover all necessary modifications of the existing Q-Series Recommendations. What revisions or modifications of the existing Q-Series Recommendations falling within the responsibility of Study Group XI should be recommended? ============================================================ Question 8/XI - Structure and use of Signalling System No. 7 networks Considering (a) that the use of signalling networks employing non-associated signalling should provide significant operational and economic advantages to Signalling System No. 7; (b) that such a signalling network should be designed to support and serve as a transport system for many, as yet undefined, services for call control signalling and for the transmission of other non-call related information; (c) that guidelines for the structure of such a network should aid the inter-connection of Signalling System No. 7 networks and simplify signalling network management taking into account the existence of multiple RPOAs in a country and their need for diversity of services; (d) that the need to identify performance, reliability and security requirements of the Signalling System No. 7 network, to consider the parameters of the functional entities defined and quantified in the appropriate Sub-Working Parties and incorporate them into all Signalling System No. 7 network applications and to define guidelines on the responsibilities of network components which together support the required performance; (e) that the need to establish standard methods for description and analysis or common channel signalling network models, e.g., for the deployment of software tools; (f) that the need to establish one or more realistic reference signalling network models - realistic in the sense of size and structure - in order to prove the completeness and the proper working of procedures and algorithms and to investigate the dynamic influence of these procedures and algorithms on the signalling networks; (g) that during the evolution of the signalling system different versions of each part will be developed and general rules will be required to ensure compatibility of each stage; (h) that general flow control rules will be needed to ensure the coordination of the actions of component parts of Signalling System No. 7 to maintain orderly operation under congestion and failure conditions; (i) that the need to collate the signalling requirements for operation, administration management networks (e.g., TMN) and to match these to an appropriate signalling network structure, What technical Recommendation should be produced for the structure and use of Signalling System No. 7? ANNEX 1 (to Question 8/XI) Parameters for the hypothetical signalling connection The following parameters were discussed with regard to their inclusion in the hypothetical signalling reference connection and it was agreed that they should be considered as a basis for study (Ref. considerata (d)). Proposed general parameter set for signalling network performance Parameter Signalling connection establishment delay (ms); Signalling connection failure probability; Throughput; Data message (UDT or DT) transit delay (ms); Data message delivery failure probability; Data message error probability; Reset delay (ms); Reset failure probability; Signalling connection unsolicited reset and premature release prob; Signalling connection release delay (ms); Signalling connection release failure probability; Signalling node unavailability. In considering (d) "all Signalling System No. 7 network applications" are mentioned. This refers to the need to include in the next study period the hypothetical signalling reference connection for applications such as database interrogation, public land mobile networks and other data networks. ============================================================ Question 9/XI - Common Channel Signalling System No. 7 - Signalling Connection Control Part Considering (a) the increasing use of signalling networks utilizing Signalling System No. 7; (b) that such a signalling network has the capability to serve as a transfer system in an integrated services digital network (ISDN); (c) that the CCITT has recommended Signalling System No. 7 for use at 64 kbits in digital networks; (d) that the Signalling System is specified and structured into: -the Message Transfer Part, common for all services and applications, -the Signalling Connection Control Part, common for all non-circuit related signalling between all types of nodes, -the Transaction Capabilities Application Part, -the User Parts. (e) that the MTPSCCP interfaces have been specified; (f) that the transfer capability provided by the MTP and the SCCP has taken into account the requirements defined by the Open Systems Interconnection layered model defined in Recommendation X.200 by providing a standard OSI network layer service and a number of additional features; (g) that the CCITT has specified a digital access signalling system for access to the ISDN and that its interaction with the SCCP for new services and applications (e.g., for user-to-user signalling) may impose some additional requirements in terms of flow and congestion control; (h) that further study is required for SCCP to complete the specifications for such items as: - signalling network functions; -SCCP sub-system congestion control, SCCP management procedures; -signalling system performances, in particular. The effects of possible uneven traffic distribution due to the load sharing mechanism (SLS) on SCCP performance parameter values, What additional functions and what enhancements to existing SCCP Recommendations are necessary to meet the current and additional requirements resulting from further study of their application to support various services and capabilities in telephone networks Integrated Service Digital Networks (ISDN) and PLMNs? ANNEX 1 (to Question 9/XI) Unresolved issues in SCCP Recommendations This annex lists the topics in SCCP on which study is expected to continue in the period. It is not an exhaustive list, but does indicate where the Recommendations might change. In these areas, RPOAs may need to supplement the Recommendations, but in such a way so as not to conflict with on-going work; implementors should consider likely future developments and, where possible, design to accommodate these. The topics under study are listed below, the references are to the Blue Book: 1) inter-nodal communication model with SCCP connectionless service (1.3.3Q.711); 2) delivery confirmation service (N-DATA ACKNOWLEDGE primitive) (Table 1Q.711); 3) transitions caused by N-DATA ACK primitive (Figure 7Q.711); 4) facilities causing differences in the called and responding addresses in N-CONNECT request and response (2.1.1.2.2Q.711); 5) the need for Receipt Confirmation Service in SCCP (2.1.1.2.2 and 4.1.1.2Q.711); 6) connection identification parameter inclusion in Request types 1 and 2, and reply primitives between SCCP and ISUP (2.1.1.3.2Q.711); 7) connection identification parameter inclusion in N-CONNECT, N-DATA, N-EXPEDITED DATA, N-RESET, and N-DISCONNECT primitives (Tables 2, 3, 4, 5, 6, 7, 8Q.711); 8) the list of release reason parameter values (2.1.1.2Q.711); 9) QOS parameter set inclusion in N-INFORM (Table 7Q.711); 10) set up and release functions for permanent signalling connections (2.1.2.1Q.711); 11) integrating sequence control and return option parameters into the QOS set (Table 9Q.711); 12) sequence control parameter inclusion in the N-UNITDATA indication primitive (Table 10Q.711); 13) SCCP response to MTP-STATUS and MTP-RESTART (3.2.4, 3.2.5Q.711); 14) difference in QOS between permanent and temporary signalling connections (4.1.2.2Q.711); 15) SCCP management procedures for sub-system congestion (4.3Q.711; 3.11, 3.12, 3.15Q.713; 5.1, 5.3Q.714); 16) SCCP capabilities in OSI NSAP address translation (4.4Q.711); 17) possible need for diagnostic parameter (2.6Q.712); 18) constraints on order of optional parameter transmission (1.8Q.713); 19) destination local reference coded as all ones (3.2Q.713); 20) source local reference coded as all ones (3.3Q.713); 21) alignment with X.96 call progress information (3.11, 3.15Q.713); 22) inclusion of routing failure causes as for return cause in Q.713 3.12 (3.15Q.713); 23) data parameter maximum length for Unitdata and Unitdata Service messages (4.10, 4.11Q.713; 1.1.2, 4Q.714); 24) need for Released message cause value 1110 "not obtainable" (Annex AQ.713); 25) need for Reset Request message cause value 1011 "not obtainable" (Annex AQ.713); 26) notification regarding unrecognized messagesparameters (1.14Q.714); 27) classification of SCCP routing failure causes (2.4Q.714); 28) management procedures for non-dominant mode nodessub-systems with more than one backup (5.1Q.714); 29) receipt from a local originating sub-system of a message for a prohibited sub-system (5.3.2.1Q.714); 30) possible introduction of a sub-system out of service denial message (5.3.5.3Q.714); 31) mathematical analysis of SCCP performance; 32) Q.716 parameter values (section 3Q.716). ============================================================ Question 10/X1 - Evolution of the ISDN User Part Considering (a) that the ISDN User Part Recommendations have been issued and approved by the Plenary Assembly as being stable for 64 kbits switched services; (b) that the ISDN User Part Recommendations containing the procedures for circuit switched services have been finalized; (c) that other bearers may be added to the Recommendations taking into account that the existing procedures should remain stable; (d) that there is a need to add supplementary services associated with circuit switched services to the ISDN User Part; (e) that there may be a need to correct technical errors; (f) that there is a need to identify within the existing Recommendations those procedures and elements which are applicable on the signalling sections between international gateways, What amendments to existing Recommendations and what additional Recommendations are required? ============================================================ Question 11/XI - Call control and bearer control protocols in Signalling System No. 7 for the full range of ISDN telecommunication services The following text was agreed for a new Question covering the study of separated call and connection control protocols: Considering (a) that the increasing range of ISDN telecommunication services to be provided in national and international networks; (b) that existing ISDN User Part Recommendations have a field of application for circuit switched services and associated supplementary services; (c) that the variety of network resources and transfer techniques supported currently or in the future by the ISDN, such as: - digital (and possibly analogue) circuit switching, - packet switching, - frame switching and relaying, - asynchronous time division multiplex systems, etc.; (d) that the increasing number of supplementary services to be supported and the interest to unify the provision of supplementary services for various types of bearer services; (e) that the need to provide signalling to support multi-media, asymmetric and multi-point calls; (f) that an ISDN signalling protocol may be needed to support broadband teleservices; (g) that the desire that network signalling protocols should be designed to allow independent evolution of service control and network resource control; (h) that the CCITT now recommends a service description based on a three-stage approach, the definition of protocols (Stage 3) being based on an abstract service description (Stage 2); (i) that a great amount of technical problems for the 64 kbits circuit control have been solved in existing Signalling System No. 7 protocols and therefore there is no presently identified need to define procedures to establish, monitor or release ISDN 64 kbits circuits different from those defined in the ISDN User Part Recommendations; (j) that some architecture and protocol analysis has already been made in the 1984-1988 study period (see annex to the Question (note)) separating a generic Call Control Part (CCP) related to the control of telecommunication services from several specific Bearer Connection Control Parts (BCCPs) for the control of network resources, such as circuit BCCP, new packet mode BCCP, etc., and that the principle of such a full separation has been agreed; (k) that there is an urgent need to study the separation of call control from connection control; (l) that the call control part may take advantage of application service elements; What Recommendations based on the principle of separation of the Call Control and Bearer Connection Control Parts are necessary in Signalling System No. 7 to meet present and future signalling and service requirements in the evolving ISDN? ANNEX 1 (to Question 11/XI) Status on the studies on the separated ISDN User Part (See Contribution COM XI-3) ANNEX 2 (to Question 11/XI) Proposed draft Recommendations texts for the "Separated ISDN User Part (ISUP-S)" (See Contribution COM IX-3) ============================================================ Question 12/XI - Transactions Capabilities Considering (a) that signalling networks using Signalling System No. 7 Transactions Capabilities will become widespread; (b) that the TC protocol may need enhancing to support a variety of new applications, basic and supplementary services, OMAP, and the evolving Telecommunications Management Network (TMN); (c) that the Quality of Service required by the various applications needs to be mapped onto the functionality of TC, and that a connection- based network service may be needed to guarantee the Quality of Service required by some applications; (d) that TC will be used in different types of network nodes, e.g., exchanges, service control points and OA&M centres, all requiring standard functions and interfaces to be provided; (e) that a means may need to be devised to enable the transfer of information via TC to be charged; (f) that the requirements of other Recommendations may impact on TC, e.g.: - the SCCP, being the primary network service provider for TC, - other network services used in place of the SCCP, which may provide a different Quality of Service to Signalling System No. 7, - the X-Series protocols upon which TC is based, - transaction oriented protocols used between the subscriber terminal and network equipment, - evolving OSI system and layer management conceptsprotocols; (g) that is is essential to maintain compatibility between different versions of the TC protocol taking into consideration the issues identified in Annex 1 to this Question; (h) that performance requirements of TC need to be specified, What additional Recommendations and what enhancements to existing Recommendations are necessary to meet the current and future requirements of Transaction Capabilities? ANNEX 1 (to Question 12/XI) Ensuring compatibility between different versions of TC 1. Introduction A possible method of ensuring compatibility between different versions of TC would be to include protocol and version information in the transaction portion of a message. This annex examines this approach. In the following analysis, node "A" attempts to initiate a transaction with node "B". 2. Options 2.1 Include no information a) no need to specify data or procedures; b) how should B process a new information element sent by a later version of A? c) unable to use common functions for a number of different X.209210 based protocols (no protocol identifier). 2.2Include only a protocol identifier (object identifier) in initial message - no version information a) need data and procedure; b) TC should receive only messages with the protocol identifier = TCAP. Any other message would be discarded. A reply is not possible, since B does not understand A's protocol. Report problem to management entry; c) enables functions to be shared amongst many X.409410 based protocols; d) gives a "sanity check" on the protocol being used for the transaction; 2.3 Include protocol identifier and version identifier a) information contained in first message from A to B (BEGIN); b) enables B to check protocol and version compatibility with A; c) if B is same version - continue transaction; d) if B is a later version but it can "drop back" to A's version, it should do so. Transaction continues; e) if B is an earlier version than A, then need to "drop back" at A. B indicates this by responding to A with an ABORT message, which includes B's version identity; f) A should then initiate a new transaction with B by "dropping back" to B's versions if possible; 2.4As per 2.3, but in the ABORT message indicate all the versions of the protocol that B supports a) as in 2.3; b) as in 2.3; c) as in 2.3; d) as in 2.3; e) if B supports other version(s) then it informs A. B sends an ABORT message to A which contains a "bit-map" indicating which version(s) of the protocol B supports; f) A selects a mutually acceptable version of the protocol (if any) and initiates a new transaction with A; 3. Issues to be resolved 3.1 Is protocolversion information needed in TC messages to ensure ongoing compatibility? If so: 3.2 a) should the version information be contained within the protocol identifier (i.e. same object identifier) or be contained in another separate element? b) what form should the version information have in the ABORT message - a simple version number, or version indication(s) (i.e. bit map)? c) what procedures are necessary? 3.3 If this general approach is not used, then what alternative methods can be used? ============================================================ Question 13/XI - Signalling System No. 7 - Operation Maintenance and Administration Part (OMAP) Considering (a) that experience with Signalling System No. 7, Operation Administration and Maintenance (OAM) procedures and protocols is evolving; (b) that a signalling network can serve to transfer information relating to OAM of its own resources; (c) that a signalling network can serve as a transfer system for OAM information associated with resources of other telecommunications networks; (d) that increased quantities and diverse traffic characteristics of information carried by the signalling network will require control and management procedures; (e) that OAM functions may be located in specialized centres external to the signalling network(s), or in signalling points within the signalling network; (f) that OAM functions may be centralized in specific elements or distributed among several elements; (g) that some users of Signalling System No. 7 also utilize other CCITT Recommendations (e.g., X-Series Recommendations) for services and transfer of information; (h) that evolving applications, control and management systems may require services Signalling System No. 7 can provide (and vice-versa); (i) that such an evolving management system is the Telecommunications Management Network (TMN) that is under study in the CCITT and that close coordination is required; and considering that further study is required to enhance the existing Recommendations of measurements (Q.791) and the operations, maintenance, administration part (Q.795 OMAP) for such items as: 1. the basic measurements and the functions, procedures and protocols needed for the operations, maintenance and administration of the signalling network and signalling points including the various application and user parts which may be present in a signalling point; 2. the functions, procedures and protocols of the operation, maintenance and administration part needed to provide services to the ISDN and other Signalling System No. 7 Users e.g., TMN; 3. the services required by the operations, maintenance administration part from the lower layers of Signalling System No. 7; 4. the technical arrangements for the transfer of information associated with the operation maintenance and administration of telecommunications networks using Signalling System No. 7; 5. any technical arrangements necessary to perform accounting functions (e.g., for use of STPs); 6. the relationship among Signalling System No. 7 protocols, tests and traffic characteristics of transferred signalling information; 7. the relationship of signalling traffic to signalling point(s) processor(s) capacity; 8. the measurements, procedures and protocol for assessment of signalling network performance, e.g., network delays; 9. the technical arrangements for execution of distributed procedures e.g., time of day synchronization among network elements, update of routing tables etc.; 10. additional tests and the initiation and management of individual tests, classes of tests and sequences of tests; 11. the technical arrangements for working OAM procedures across network boundaries, What enhancements are necessary to measurements and OAM functions, procedures and protocols? ============================================================ Question 14/XI - Signalling System No. 7 - Protocol testing and test specifications Considering (a) that experience with signalling networks utilizing Signalling System No. 7 is evolving; (b) that prior to introduction, a signalling point needs to be tested; (c) that the signalling network, as a result of additions or rearrangements needs to be tested; (d) that signalling points need to be introduced in a timely and careful manner; (e) that there is a need for Testing Mechanisms; (f) that the CCITT has Recommended Test Specifications Q.780-Q.783 for MTP and TUP Testing, What enhancements to existing Recommendations and development of new Recommendations are needed to design and specify a Testing User Part and also to produce Test Specifications to test other parts of Signalling System No. 7 e.g., SCCP, ISUP, TCAP etc.? ============================================================ Question 15/XI - Guidelines for implementing Signalling System No. 7 in national networks Considering (a) that rapid developments in digital technology, together with demands for a broad range of advanced communications services, have resulted in a shift from analogue to digital networks; and that this trend is being carried further to create a multi- media integrated digital network which transmits voice characters, data, video images, facsimile, etc.; (b) that the implementation of Signalling System No. 7 is particularly significant as it can be used in the circuit switched public data network (CSPDN) and in the public switched telephone network (PSTN); (c) and that the procedures for implementing data and voice networks may not be applied to CCS networks, so that there is a need for advice by the CCITT on procedures for implementing CCS in the transition from analogue to digital networks, What guidelines can be given on the following aspects of Signalling System No. 7 implementation: 1) routing techniques in CCSS No. 7 networks; 2) implementation of communication procedures with network management centres; 3) implementation of interconnection between CCSS No. 7 networks and public data networks; 4) signalling network topologies for the different hierarchical levels in a national network; 5) possible constraints due to delay in the signalling network for real time applications; 6) signalling network performance; 7) software aspects of CCSS No. 7? ============================================================ Question 16/XI - Interworking of signalling systems (Continuation of Question 13/XI studied in 1985-1988) Considering (a) that Recommendations on interworking, using the SDL language, of most combinations of the CCITT Signalling Systems have been prepared (Recommendations Q.601 to 685 in Volume VI-6 of the Blue Book); (b) that as a result of the experience gained during the elaboration of the logic procedures contained in those interworking Recommendations, some rules have been prepared which should be complied with when specifying new signalling systems and which will help to facilitate interworking between existing CCITT Signalling Systems and new signalling systems (see Recommendation Q.607); (c) that new switching and transmission systems may give rise to new interworking problems; (d) that further updating of signalling system specifications may be necessary; (e) that the interworking of signalling systems may be affected by changes in other procedures, such as call-routing and echo control; (f) that the continued enhancement of existing, and generation of new, user parts for Signalling System No. 7 will require changes to interworking; (g) that the ISDN and new mobile services may give rise to new interworking requirements; (h) that ISUPDSSI interworking Recommendation is using arrow diagrams with primitives for interworking, accordingly the Interworking logic block might have to be modified to work with primitives facing ISUP, and FITES and BITES facing existing Signalling Systems (Nos. 5, 6, R1, R2, and TUP); (i) that a complete set of interworking diagrams for ISUP interworking with existing signalling systems using FITES and BITES was developed during 1985-1988 study period and is annexed to this Question, What new interworking Recommendations and what extensions to existing interworking Recommendations should be specified? ANNEX (to Question 16/XI) Signalling System No. 7 ISUP interworking diagrams (See Contribution COM XI-4) ============================================================ New Question 17/XI - Signalling for existing and future land mobile networks (Continuation of Question 14/XI studied in 1985-1988) Considering (a) that general Recommendations on land mobile networks are given in the Series Q.1000 to Q.1005; (b) that the basic interworking procedures between public land mobile networks and the telephone network and the ISDN are defined in Recommendations Q.1031 and Q.1032; (c) that the specification of the mobile application part is contained in Recommendation Q.1051; (d) that digital PLMN access signalling reference points, channel structures and access capabilities are defined in Recommendations Q.1061, Q.1062 and Q.1063; (e) that public land mobile networks should be capable of providing ISDN services; (f) that it is desired to use Signalling System No. 7 for efficient interworking between public mobile networks; (g) that additional functions within Signalling System No. 7 Recommendations may be needed to support mobile networks; (h) that there is an increasing demand for land mobile communications; (i) that there is an evolution towards moving access digital networks and personal telecommunications (e.g., mobility within both PLMNs and ISDNs based upon personal ISDN number via intelligent network data bases), What new Recommendations and enhancements to existing Recommendations are needed to support the land mobile services and personal communications? Note 1 - The study of this Question interests Study Groups I, II, III, VII and XVIII and CCIR Study Group 8. ANNEX 1 (to Question 17/XI) List of study items -General aspects and principles relating to digital PLMN signalling interface. -Digital PLMN access signalling reference configurations. -Digital PLMN channel structures and access capabilities at the radio interface. -Digital PLMN access signalling protocol model. -Digital PLMN access signalling interfaces layer 1. -Digital PLMN access signalling interfaces layer 2. -Digital PLMN access signalling interfaces layer 3. -Digital PLMN access signalling interfaces management entity. -Identification of additional procedures in MAP. -Signalling interworking with ISDN. -Technical realization of new ISDN services defined for mobile networks. -Further alignment of supplementary services with the definitions and principles established by CCITT on ISDN supplementary services. -Further study on network functions. -Performance objectives for Location Registers and Mobile Services Switching Centres. -Control of speech processing and echo control devices when interworking with ISDNPSTN. -ISDNPSTN interworking for non-voice calls. -Networks for advanced cordless telephones. -Adaptation to microcell PLMN. -Further study of integration of the digital mobile services with the fixed network to provide personal telecommunications services, e.g., personal telephone number via intelligent network via intelligent network's data base. -Study of general aspects and principles relating to Moving Access Digital Network(s) signalling interfaces ANNEX 2 (to Question 17/XI) Draft Recommendation Q.1012: Handling of supplementary services in PLMNs (See Contribution COM XI-5 and 6) ============================================================ New Question 18/XI - Interworking with mobile satellite networks Considering (a) that an international maritime-satellite service is being operated by the INMARSAT organization; (b) that the interworking between the INMARSAT system and the telephone network is defined in Recommendations Q.1100-Series; (c) that the basic interworking procedures between public land mobile networks and the telephone network are defined in Recommendations in the Q.1000-Series; (d) that plans exist to introduce a mobile telephone service with aircraft using radio and satellite techniques; (e) that automatic service to and from such mobile units is desired in relation to the existing international telephone network; (f) that such mobile units are often moving over large distances covered by radio stations - including satellite earth stations - based in several countries; (g) that public maritime land and aeronautical mobile satellite networks should be capable of providing ISDN services; (h) that it is desired to use Signalling System No. 7 for efficient interworking between public mobile networks; (i) that additional functions within Signalling System No. 7 Recommendations may be needed to support mobile networks, What new Recommendations and enhancements to existing Recommendations are needed to support the land, maritime and aeronautical mobile satellite network? Note 1 - The study of this Question interests Study Groups I, II, III, VII and XVIII and CCIR Study Group 8. ============================================================ Draft for Question 19/XI - Signalling requirements for new transmission equipments (Continuation of Question 16/XI studied in 1985-1988) Considering (a) that the planned implementation by some administrations, of echo cancellers and A5 law converters situated either remotely from, or co- located with, a switching unit; (b) that the need for control of speech processing devices in ISDN by exchanges; (c) that the present Recommendations concerning the use of echo control devices and ISCCNE control protocols; (d) that the need to provide a general signalling scheme for controlling echo control devices; (e) that the proposals by other Study Groups for changes to existing Recommendations on PCM equipment; (f) that the development of complementary Recommendations by other Study Groups concerning items such as transmultiplexers, transcoders, ADPCM and speech interpolation systems and where signalling matters are to be completed; (g) the possibility of interaction between new transmission equipments used in an international connection with the need to control such interaction; (h) that the need for a Study Group to maintain responsibility for signalling matters, What new Recommendations are required and what additions or modifications to existing Recommendations are necessary to ensure correct integration of transmission devices into the international PSTNISDN networks from a signalling point of view? Note - The study of this Question is of interest to Study Groups II, IV, XV, XVI, XVII and XVIII. ANNEX 1 (to Question 19/XI) Outline of concepts for signalling requirements The purpose for this annex is for further outline concepts of signalling requirements for echo control devices and new transmission equipments so that work may proceed in this area. -Recommendation for signalling system between ISC and CME is for further study; -the procedures for in call modification in CMEISC signalling; -further work is required on Recommendation Q.115. (Among other items consideration of deleting "half" in the expression "half echo suppressorcanceller"); -SDL diagrams for echo control given in Annex 2 will be a starting point for the work during the next study period. ANNEX 2 (to Question 19/XI) Call processing logic - Echo suppressor control FIGURE A-1Q.115 (Sheet 1 of 4) RECOUP RECOUP SHeet 2 RECOUP Sheet 3 RECOUP Sheet 4 Call processing logic - Echo control device control diagram notes Note 1 - "Yes" where incoming signalling system provides echo suppressor indicators (ESI). For terminal R2 calls ESI is only available on request using signal A14. Signal A14 should only be returned where an IHES can be inserted. Note 2 - ESI = 0, OHES not included, IHES not required. ESI = 1, OHES included, IHES required. ESI = 2, OHES not included, OHES required. Note 3 - Analysis of digits indicates a long connection which requires or already has echo suppressors; or route analysis indicates that permanent echo suppressors are fitted. Note 4 - IHES should be connected as close to called subscriber as possible. This decision relates to the capability of the next or a later exchange to connect echo suppressors from a pool. Note 5 - During the "register activated" phase all echo suppressors should be disabled. Enable or disable actions refer to the period after register deactivation, except for System R2 where it refers to the period after the reception of the answer signal. Note 6 - This exchange cannot connect OHES, but by bilateral agreement is to be connected at next exchange. The indicator ESI = 2 is only used in Signalling System R2 and can only be used between the outgoing R2 international exchange and the first transit exchange. ESI Echo suppressor indicator (= Echo canceller indicator). IHES Incoming half echo suppressor (= IHE canceller). OHES Outgoing half echo suppressor (= OHE canceller). SPITE 21 Incoming half echo control device to be included at distant end? See Recommendation Q.603. Note 7 - On R2 to R2 transit calls where I - 12 is received and half echo control devices are fitted to an outgoing satellite link, endtoend operation is allowed and I - 12 will therefore be sent (see Recommendation Q.479). Note 8 - Bearer services: Bearer service 1 = Speech Bearer service 2 = 3.1 kHz audio Bearer service 3 = 64 kbits unrestricted Bearer service 4 = altern. speech64 kbits unrestricted. 3.1 kHz audio bearer service is the service the user perceives in case of interworking between ISDN and PSTN. For 3.1 kHz bearer service the exchange enables, disables and inserts echo control devices like for speech bearer service. The control of echo control devices is performed from the terminal or circuit test equipment by using the 2 100 Hz (disabling) in-band tone, if necessary (see CCITT Recommendations G.164, 5 [2] and G.165, 4 [3]). Note 9 - If the outgoing exchange does not know, that an OHES is required on a succeeding link, but a succeeding exchange does, this succeeding exchange could request an OHES in its preceding exchange, if CCITT Signalling System No. 7 (TUP) is used (see CCITT Recommendation Q.724, 11). Note 10 - This information has to be stored for the duration of the call (no ESI in call modification message of CCITT Signalling System No. 7). Note 11 - Although no echo control devices required for 64 kbits unrestricted bearer service, an echo control device should be inserted from the pool (and disabled) for a 64 kbits unrestricted call with the possibility for in call modification, if no permanently associated echo control device is available for this circuit. ============================================================ Question 20/XI - Updating and enhancements of ISDN user-network interface call control protocol Considering (a) that although the 1988 (Blue Book) version of Recommendation Q.931 is considered firm and stable, there may be a need to update it (e.g., for the clarification of texts or options, correction of errors leading to mis-operations) and to introduce new elements as study on supplementary services progresses and necessitates enhancements; (b) that there is a firm requirement to ensure backward compatibility with the 1988 version of Q.931; (c) that Recommendation Q.932 defines generic protocols for the control and the management of supplementary services; (d) that general signalling requirements and principles will be provided from the study under the other Questions (e.g., service definition, network architecture definition); (e) that there may be a need for additional layer management functions; (f) that the support of terminal portability according to Recommendation I.110, Blue Book, is required; (g) that there may be a need to provide user guidelines for implementors, What enhancements to the existing Recommendations andor what new Recommendations are needed to support basic and supplementary service procedures at the user-network interface? Study points should include: 1. the support of bearer service or teleservice negotiation (user-to- network, user-to-user); 2. the alternate speechunrestricted digital information (UDI) bearer service requirements (i.e., in-call modification); 3. the support of the OSI network services (in the circuit switched mode); 4. the support of various user-to-user applications, the selection of compatible terminals and possible service negotiation requirements (e.g., application selection) in order to meet the requirements of existing and new Recommendations on services and telematic terminals, e.g., in point-to- multipoint configurations; 5. the support of the ISDN additional packet mode bearer services (Step 3); 7. the support of network signalling in a hybrid privatepublic network andor virtual private network environment; 8. possibly required mechanism to ensure backward compatibility. ANNEX 1 (to Question 20/XI) Texts for in-call modification and layer 2 protocol information (Recommendation Q.931, 4) Two items from Q.931, 4 are in the "awaiting review" state for the next study period: i) in-call modification; ii) coding of low layer compatibility information element, octet 6a. This annex contains the current material on these items. 1) In-call modification -Messages 00100111 MODIFY 00101111 MODIFY COMPLETE 00100011 MODIFY REJECT - Call state values in call state information element 011010 U26 - Modify Request N26 - Modify Request 011011 U27 - Modify Indication N27 - Modify Indication - Repeat indication in Repeat indicator information element 0001 Circular for successive selection 2) Layer 2 protocol information The following text is proposed for inclusion in the layer 2 information field (octet 6) of the low layer compatibility information element: "- Optional layer 2 protocol information (octet 6a) Modulo Bits 7 6 0 0 Reserved 0 1 HDLC operation using modulus 8 1 0 HDLC operation using modulus 128 1 1 HDLC operation capable of using either modulo 8 or 128." ANNEX 2 (to Question 20/XI) Draft Annex Q to Recommendation Q.931 In-call modification Q.1 Service description This circuit switched 64 kbits 8 kHz structured service allows the two users, on a point-to-point connection, to use the 64 kbits connection between them for speech information transfer and for unrestricted digital information transfer alternately during the same call. The procedure provides for the support of multiple capability terminals only. Alternation when single capability terminals are used is for further study. The request for this alternate use capability and the initial mode desired must be identified by the user in the service request for call setup by identifying each mode of operation with a separate bearer capability information element. Q.2 Call establishment At both originating and destination interfaces, the normal call establishment procedures (described in 5.1 and 5.2 of Annex D) apply. Q.2.1 Establishment at the originating interface The service is requested by the originating user by transferring a SETUP message to the network containing two bearer capability information elements immediately preceded by the repeat indicator information element with the repeat indication field coded "circular for successive selection". The first mode of operation shall be indicated by the first bearer capability information element, which shall have the information transfer capability field coded either "speech" or "unrestricted digital information". The second mode of operation is indicated by the second bearer capability information element which shall have the information transfer capability field coded as the alternate of the first. (Contributor's note - Editor has reference to 64 kbits restricted digital information transfer being also allowed as one mode.) A low layer compatibility may optionally be specified for each call mode. If any call mode includes a low layer compatibility specification, then multiple low layer compatibility information elements shall be present in the SETUP message. In such a case, the number of low layer compatibility information elements shall equal the number of bearer capability information elements. A particular low layer compatibility information element shall be empty if no low layer compatibility specification applies for the corresponding call mode. The set of low layer compatibility information elements shall be immediately preceded by the repetition indicator information element, coded "circular for successive selection". When no low layer compatibility specification exists for any of the call modes, then the low layer compatibility information elements and immediately preceding repetition indicator information element shall not be present. Similarly, a high layer compatibility may optionally be specified for each call mode. If any call mode includes a high layer compatibility specification, then multiple high layer compatibility information elements shall be present in the SETUP message. In such a case, the number of high layer compatibility information elements shall equal the number of bearer capability information elements. A particular high layer compatibility information element shall be empty if no high layer compatibility specification applies for the corresponding call mode. The set of high layer compatibility information elements shall be immediately preceded by the repetition indicator information element, coded "circular for successive selection". When no high layer compatibility specification exists for any of the call modes, then the high layer compatibility information elements and immediately preceding repetition indicator information element shall not be present. The high layer compatibility information elements may not be used to indicate teleservices. Regardless of the number of modes permitted for the call, only a single user-user information element shall be contained in the SETUP message. Q.2.2 Processing the SETUP message Each network equipment which is sensitive to the call mode shall examine each mode described in the bearer capability included in the SETUP message. If any of the described modes cannot be supported on that call, then the network shall initiate call clearing as specified in 5.3. If the procedures of 5.3 specify that a clearing message is sent, then one or more of the following causes are included as appropriate to specifically describe the situation: a) #57 "bearer capability not authorized"; b) #58 "bearer capability not presently available"; c) #65 "bearer capability not implemented", and d)#70 "only restricted digital information bearer capability is available". Q.2.3 Establishment at the destination interface The service is indicated to the destination user by a SETUP message coded in the same manner as above. At the destination local access, the user shall perform the compatibility checking for both requested services as described in Annex B. Both capabilities must be reachable by the same called party number and subaddress information elements. If compatibility checking fails, then the call may be cleared according to the procedures of 5.3 with one of the following causes, as appropriate, to specifically describe the situation: a) #57 "bearer capability not authorized"; b) #58 "bearer capability not presently available"; c) #65 "bearer capability not implemented"; d)#70 "only restricted digital information bearer capability is available", and e)#88 "incompatible destination". A user equipment may accept the call if the first capability indicated is free, irrespective of whether the alternate capability is free or busy. Q.3 Changing the call mode In order to change the call mode, the following in-call modification procedures shall be used. Either user may act as the requesting user to invoke in-call modification. Upon each successful completion of the in-call modification procedures, the call advances to the next mode listed in the SETUP message. After the last mode has been reached, the next successful completion of the in-call modification procedures causes the call to revert to the first mode listed in the SETUP message. There is no limit to the number of times in-call modification The in-call modification procedures are completely symmetrical at any user-network interface. Q.3.1 Initiation of in-call modification The procedure is initiated by the requesting user in the Active state who shall: reserve any internal resources necessary to support the next call mode; start the B-channel synchronization procedures specified in Q.3.3; send a MODify message; start time T322 if implemented and enter the Modify Request state. Upon receipt of the MODify message, the network shall check to ensure that the next call mode can still be supported. If so, at the initiating user- network interface the network shall: initiate the reservation of any network resources necessary to support the next call mode; and enter the Modify Indication state. At the remote user-network interface, upon completion of the reservation of any network resources necessary to support the next call mode, the network shall: start timer T322, send a MODify message; and enter the Modify Request state. If the network cannot support the next call mode, the network follows the procedures of Q.3.4. Upon receipt of the MODify message, the remote user shall: enter the Modify Indication state and check to ensure that the next call mode can still be supported. If so, the remote user follows the procedures of Q.3.2. If not, the remote user follows the procedures of Q.3.4. Q.3.2 Successful completion of in-call modification If the next call mode can be supported, the remote user shall: alternate to any internal resources necessary to support the next call mode; start sending B-channel information according to the next call mode; start interpreting received B-channel information according to the next call mode; send a MODify COMPlete message; and remain in the Active state. Upon receipt of the MODify COMPlete message at the remote user-network interface, the network shall: initiate the alternation to those network resources necessary to support the next call mode; stop timer T323; and enter the Active state. Upon completion of the alternation, at the initiating user- network interface, the network shall: send a MODify COMPlete message; and enter the Active state. Upon receipt of the MODify COMPlete message, the initiating user shall: stop timer T323; changeover to any reserved resources used to support the next call mode; start sending B-channel information according to the next call mode; start interpreting received B-channel information according to the next call mode; and enter the Active state. Q.3.3 B-channel synchronization The initiating user, after transmitting the MODify message, transmits the idle pattern consisting of sequence of "l"s and ignores the received bit stream. The terminating user, after receiving the MODify message, makes itself ready to transmit and receive the bit stream for the new service. The initiating user, after receiving the MODify COMPlete message, makes itself ready to transmit and receive the bit stream for the new service. In case of in-call modification failure, the initiating user, after receiving the MODify REJect message, resumes to transmit and receive the bit stream for the old service. No synchronization message is necessary to be transmitted. Q.3.4 Failure of in-call modification Q.3.4.1 Network rejection of in-call modification If any portion of the network cannot support the change to the next call mode, the network shall: release any resources which had been reserved for the alternation; send a MODify REJect message with cause #58 "bearer capability not presently available" to the initiating user; and enter the Active state. Note - XI6 has #71 "temporary failure"; is this more applicable. Upon receipt of the MODify REJect message, the initiating user shall: stop timer T323; release any resources which had been reserved for the alternation; resume sending B-channel information according to the present call mode; resume interpreting received B-channel information according to the present call mode; and enter the Active state. Q.3.4.2 Remote user rejection of in-call modification If any portion of the remote user cannot support the change to the next call mode, the remote user shall: release any resources which had been reserved for the alternation; send a MODify REJect message with cause #58 "bearer capability not presently available"; and enter the Active state. Upon receipt of the MODify REJect message, the network shall: stop timer T323; initiate the release of any resources which had been received for the changeover; and enter the Active state. Upon completion of, or contemporaneously with, the release of any resources which had been reserved for the alternation, at the initiating user-network interface, the network shall: send a MODify REJect message with the same cause code as received from the remote user; and enter the Active state. Upon receipt of the MODify REJect message, the initiating user shall: stop timer T323; release any resources which had been reserved for the alternation; resume sending B-channel information according to the present call mode; resume interpreting received B-channel information according to the present call mode; and enter the Active state. Q.3.4.3 Timeout recovery Upon expiration of T323 in either the user or the network, the procedures for call clearing of 5.3 shall be initiated with cause #102 Q.5 Abnormal procedures If a MODify, MODify COMPlete or MODify REJect message is received when the bearer service is not alternate speech64 kbits unrestricted digital, then the received message shall be treated as an unrecognized or unexpected message, as specified in 5.8.4. If a MODify, MODify COMPlete or MODify REJect message is received in any state except Active, Disconnect Indication, Disconnect Request, Release Request, Resume Request and Suspend Request, then the received message shall be treated as an unrecognized or unexpected message, as specified in 5.8.4. If a MODify, MODify COMPlete or MODify REJect message is received in the Disconnect Indication, Disconnect Request or Release Request state, then the message shall be discarded and no action shall be taken. If the network receives a MODify message from the remote user while the network is in the Suspend Request state then a MODify REJect message shall be If the network receives a MODify message from the remote user while in the Resume Request state then the Message shall be forwarded to the local user after the RESume ACKnowledge message has been sent. FIGURE Q-1Q.931 Successful in-call modification FIGURE Q-2Q.931 Example of in-call modification rejection ============================================================ Question 21/XI - Updating and enhancements of ISDN user-network interface data link layer protocol Considering (a) that the 1988 (Blue Book) version of Recommendation Q.921 on LAPD (ISDN user-network interface data link layer protocol) is firm and stable, however, it may require updating in order to correct for possible errors leading to misoperations; (b) that there is need to define a new data link layer protocol, based on LAPD, to satisfy the needs arising from: -application of the D-channel in a symmetrical fashion (e.g., NT2 to NT2), - application to channels other than the D-channel (e.g., for data transfer), -application to Additional ISDN packet mode bearer services (Step 2 - frame multiplexing and Step 3 - frame relay or frame switching, with out-of-band signalling); (c) that general signalling requirements and principles will be provided from the study under the other Questions (e.g., service definition, network architecture definition); (d) that there may be a need for additional layer management functions for both D- and non-D channel applications; (e) that a desire was expressed to provide user guidelines for implementors, especially for the implementation of the LAPD protocol on the primary rate interfaces (23B+D, 30B+D), What additional Recommendations andor enhancements to the Q.920-Series of Recommendations are necessary? The attached annex contains agreements reached during the previous study period; it is structured as an expedient to allow easy comparison with Recommendation Q.921, but the exact structure of a possibly new Recommendation in the Q.920-Series is a matter for further review. Study points should include: 1. symmetry (for user-to-user data transfer); use of CR bit; 2. structure of the address field; 3. need for HDLC additional frames (e.g., Test, Reset); 4. explicit congestion control (i.e., frame relay bearer service); 5. synchronization between the User (U) and Control (C) plane (e.g., by primitives); 6. data link layer structure and modelling issues; 7. compatibilitycommonalityinterworking with Q.921 and possibly with other HDLC elements of procedure; 8. definition of layer management functions and managed objects needed to support these functions. ANNEX (to Question 21/XI) A draft outline for an ISDN data link layer specification for non-D-channel applications Attachment 1 (to the Annex to Question 21/XI) 1. Dynamic window algorithm The dynamic window algorithm is a way to control network congestion (circuitswitched connections between two end terminals have no need for this procedure). The algorithm modifies the transmitting datalinklayer entity's send window when congestion is first detected, and again as congestion decreases. The receiving datalinklayer entity does not participate in the algorithm and does not require knowledge of the sending datalinklayer entity's participation. Congestion in one direction of a link is treated independently of congestion in the other direction. 1.1 Operation If a datalinklayer entity's transmit window parameter (k) is set to 1, the working window parameter V(k) will always have the value 1 and the algorithm need not be invoked. If the datalinklayer entity's k is greater than 1, it uses a V(k) equal to k in the absence of congestion. This congestion control algorithm is triggered by the loss of I frames. A datalinklayer entity detects this loss: -when it receives a REJ frame; -when its T200 expires and it transmits a command with the Pbit set to 1, and subsequently receives an I frame response or supervisory response in which the Fbit is set to 1, but in which the value of N(R) is less than the current V(S). When a datalinklayer entity detects either of these events, it invokes the dynamic window algorithm, setting its V(k) to 1. As I frames are then successfully transmitted and acknowledged, the transmit window size V(k) is gradually increased until it returns to k, its value in the absence of congestion. Several algorithms for control of the increase in V(k) are possible. Prior discussions included a procedure in which the rate of increase in V(k), i.e. the increase in V(k) per transmitted and acknowledged I frame, decreases as V(k) approaches k. The procedure described here is one in which the rate of increase in V(k) is constant. Following reduction of V(k) to 1, when Nw consecutive I frames are successfully transmitted and acknowledged, V(k) is increased by 1. For each additional Nw I frames that are successfully transmitted and acknowledged, V(k) is increased by 1. When V(k) reaches its maximum value, k, the dynamic window algorithm ends. 1.2 List of system parameters and variables In this algorithm, the following additional system parameters and variables are defined: 1) Transmit working window (V(k)) The maximum number of sequentially numbered I frames that may be outstanding (that is, unacknowledged) at any given time. In the absence of congestion, V(k) is equal to the maximum number of outstanding I frames (k). Initially, V(k) = k. 2) Dynamic window step size (Nw) The number (Nw) of I frames that must be successfully transmitted and acknowledged before the transmit working window is incremented in the dynamic window algorithm is a system parameter. The default value is 5. 3) Information acknowledge counter (Ia Ct) This counter contains the number of I frames successfully transmitted and acknowledged since the last adjustment of the transmit working window Ww, in the dynamic window algorithm. ============================================================ Question 22/XI - ISDN user-network protocol (DSS 1) conformance Considering (a) that the Blue Book (1988) version of ISDN user-network interface protocol Recommendations provides a consolidated basis for the implementation of ISDN terminal equipment and network equipment; (b) that the Recommendations specify a protocol to implement a function if the function is to be implemented, but does not specify, for each function, whether that function must be implemented or not. This allows different sets of functions to be implemented in terminal equipment and network equipment, which, as a result, may not correctly interwork with each other in their full range of capabilities; (c) that in addition, there is some freedom in the interpretation of the Recommendation texts, such as on the coding of High Layer Compatibility and Low Layer Compatibility information elements. This may lead to a situation where two terminals of the same teleservice (e.g., telephone) cannot offer the intended teleservice to the human user; (d) that the CCITT is cooperating with ISO to establish and apply uniform guidelines on conformance testing methodology and framework (draft Recommendation X.290) including a standard test notation (T TCN) (e) that Study Group VII provided Recommendation X.290 on the conformance test specification for X.25 and similar activities are undertaken by ISO on the conformance of OSI protocols; (f) that various regional and national organizations are studying the need, scope and method of conformance testing on ISDN equipment; (g) that activity can be undertaken by CCITT may range from acting as the focal point for information exchange among the regional and national organizations working on the same subject, to providing a set of Recommendations on the definition of conformance, scope and extent of conformance testing and conformance test specifications, What activity and Recommendations (if any), are required by the CCITT concerning the ISDN user-network interface protocol (DSS 1) conformance, so that common access to ISDN andor inter-communicability for specific ISDN teleservices are facilitated on a world-wide basis? ============================================================ Question 23/XI - Common channel Signalling System No. 7 - Message Transfer Part Considering (a) that the Recommendations on MTP have reached a great degree of stability; (b) that the increasing use of signalling networks utilizing Signalling System No. 7 with MTP in both national and international networks; (c) that such a signalling network has the capability to serve as a transfer system in an integrated services digital network (ISDN); (d) that the CCITT has recommended Signalling System No. 7 for use at 64 kbits in digital networks; (e) that the signalling system is specified and structured into: -the Message Transfer Part, common for all non-circuit related signalling between all types of nodes, -the Signalling Connection Control Part, common for all non- circuit related signalling between all types of nodes, -the Transaction Capabilities Application Part, -the User Parts; (f) that new applications and services may impose some additional requirements on MTP; (g) that further study is required for MTP to complete and enhance the specifications for such items as: - signalling network functions such as MTP flow control, MTP user unavailabilitycongestion control, -signalling system performance, in particular, MTP traffic model and performance parameters and the effects of possible uneven traffic distribution due to the load sharing mechanism (SLS) on MTP performance parameter values, What additional functions and what enhancements to existing MTP Recommendations are necessary to meet the current and additional requirements resulting from further study of their application to support various services and capabilities in telephone networks ISDNs and PLMNs? ============================================================ Question 24/XI - Enhancement and extension of the Q.500, Q.544-Series of Recommendations on digital exchanges Considering (a) that the Q.500-Series of Recommendations on digital exchanges have been developed over the last three CCITT study periods; (b) that a large number of digital exchanges complying with these Recommendations have already been supplied to administrations and RPOAs; (c) that operational experience in an IDN environment of digital exchanges complying with these Recommendations is rapidly building up; (d) that there is a trend in exchange design towards the separation and centralization of the intelligence required to support new and enhanced features, from that required to support basic circuit switching; and further considering: (e) that many national and international IDNs are already being evolved to become ISDNs; (f) that there is a need to develop these Recommendations in respect of aspects arising from: -the impact on digital exchanges of the evolution of the telecommunications management network (TMN), -the impact on exchange performance design objectives, OAM objectives and measurements of packet mode services, supplementary services etc., -the impact on exchange overload characteristics due to, common channel signalling traffic, data information transfer between exchanges and remote operations centressystems, etc.; (g) that there is a need to develop these Recommendations in respect of aspects arising from the requirement for digital exchanges to operate in conjunction with both public land mobile networks and competing fixed land networks; (h) that new services including broadband and data will be introduced in ISDNs and may require special interface and other functions within digital exchanges; (i) that digital transmission technology will continue to evolve, possibly at a different rate from exchanges and the latter may be required to support more than one such technology, e.g., the use of lower bandwidth transmission systems in rural areas which may require changes in the design of small digital exchanges; (j) that connections other than bi-directional circuit switched connections may be required to meet future service requirements, What additions and modifications should be made to the existing Q.500-Q.544-Series of Recommendations on digital exchanges? Note - This Question should be studied in liaison with Study Group II. ANNEX (to Question 24/XI) Proposed 3.5.4.2.2 of Recommendation Q.512; CV1 channel structure This annex contains a proposal for a 3.5.4.2.2 of Recommendation Q.512 which is now currently marked as for further study. "3.5.4.2.2 CV1 channel structure The frame structure in the CV1 channel is given in Figure 5Q.512 containing: -Abits words A1..A4 for the control of the activation deactivation of the line and T interface, the set up of loops and the signalling of fault conditions. -Mbits octets for the transfer of the monitoring channel data. -Ebit to indicate the validity of the following Mbit. -Tbit for the transmission of transparent data to be conveyed across the line. The use of the T bit is for further study. -Rbits representing a multiframe alignment word." Channel time slot no. of frames 0 1 2 3 4 5 6 - + - + SYN B1,1 B2,1 B1,2 B2,2 D+C B1,5 - + - + - + - + D D R0 M0 D D RO MO + + + + + + + + D D A1 A2 D D A1 A2 0.5+ + + + + + + + ms D D A3 A4 D D A3 A4 + + + + + + + + D D E T D D E T - + + + + + + + + D D R1 M1 D D R1 M1 + + + + + + + + D D A1 A2 D D A1 A2 + + + + + + + + D D A3 A4 D D A3 A4 4 ms + + + + + + + + D D E T D D E T + + + + + + + + = = + + + + + + + + D D R7 M7 D D R7 M7 + + + + + + + + D D A1 A2 D D A1 A2 + + + + + + + + D D A3 A4 D D A3 A4 + + + + + + + + D D E T D D E T - + - + D1 CV1 D2 CV2 + + + - + Basic access 1 Basic access 2 FIGURE 5Q.512 A1..A4:Activationdeactivation, test loop and line feed control T:Transparent channel E:Indication of information in the M-channel M: Monitor channel Rbit multiframe alignment word for every basic access: 1 0 1 0 0 1 0 1 ---4 ms------ Coding of the Abits The Abits are used for the coding of the Functional Elements across the V1 reference point, as identified in Recommendation I.AA. The coding for the Abits is given in Tables 2Q.512 and 3Q.512. TABLE 2Q.512 + + Bits Command Corresponding to the functional A1 A2 A3 A4 Exchange - BAMX elements identified in I.AA + - + - + 0 0 0 0 Idle Power down state 0 0 0 1 Not used - 0 0 1 0 National use - 0 0 1 1 Not used - 0 1 0 0 Req. REG loop FE 6 0 1 0 1 Req. NT loop FE 4 0 1 1 0 Req. LT loop FE 5 0 1 1 1 (M)PH-AR FE 1 1 0 0 0 MPH-LSARDR T FE 3 1 0 0 1 National use - 1 0 1 0 National use - 1 0 1 1 Not used - 1 1 0 0 Disable Req. Switch off power +U transmit sig. 1 1 0 1 Not used - 1 1 1 0 Not used - 1 1 1 1 (M)PH-DR FE 2 + + TABLE 3Q.512 + + Bits Indications Corresponding to the functional A1 A2 A3 A4 Exchange - BAMX elements identified in I.AA + - + - + 0 0 0 0 MPH-DI FE 12 0 0 0 1 Not used - 0 0 1 0 Not used - 0 0 1 1 PH-AI FE 7 0 1 0 0 Not used - 0 1 0 1 National use - 0 1 1 0 Not used - 0 1 1 1 Start timer T1 FE X 1 0 0 0 MPH-LSAI FE 8 1 0 0 1 Not used - 1 0 1 0 MPH-EI FE 18 1 0 1 1 Sync loss U Synchronization loss on U interf. 1 1 0 0 Disable ind. PowerTransmitterWake up disabl. 1 1 0 1 Not used - 1 1 1 0 National use - 1 1 1 1 MPH-EI General fault condition BAMX + + Mbit coding The Mbit coding is specified in Tables 4Q.512 and 5Q.512. TABLE 4Q.512 + + M0 M1 M2 M3 M4 M5 M6 M7 Exchange - BAMX description + 0 0 0 0 0 0 0 0 Idle state 0 0 0 0 0 0 0 1 National use 0 0 0 0 0 0 1 0- + + Reserved for future applications 0 0 0 0 0 1 1 1- + 0 0 0 0 1 0 0 0- Reserved for error counter readout 1 1 1 0 1 1 0 1- + + Reserved for future applications 1 1 1 0 1 1 1 0- + 1 1 1 0 1 1 1 1 National use 1 1 1 1 0 0 0 0- + + National use 1 1 1 1 1 1 1 0- + 1 1 1 1 1 1 1 1 Idle state + + TABLE 5Q.512 + + M-bit responses BAMX - Exchange description + Values of monitor counters: Eq. BER 1 octet, binary coded 1 octet binary coded + + Ebit coding The Ebit coding is given in Table 6Q.512. TABLE 6Q.512 + + E Description + - + 0 Valid data in the following M-bit 1 No valid data in the following M-bit + + ============================================================ Question 25/XI - Protocols for remote operation of specific OAM applications Considering (a) that there is a need for a common approach for remote operation of specific System Management Applications for switching, transmission, and customer equipment; (b) that there is a need to remotely request OAM applications (e.g., error reports, remote activation of loops, and selftests); which may be located at the customer premises (or in private networks), in switching, signalling, and transmission systems, or in Service Control Centres; (c) that the requestor of these specific OAM applications may be located within the customer premises or in one or more OAM centres, or in one or more Service Control Centres; (d) that the objects to be managed in various entities will be identified by other Questions (i.e., service definitions, TMN); (e) that the convergence with the general OSI concepts and principles is an objective; (f) that the selection of a common set of protocol elements is highly desirable, What new Recommendation(s) are required for the specific Application protocols to support OAM System Management Applications controlled from remote entities? Study points should include: 1. whether the scope of studies is to be enlarged to include the following management functions: - accounting (billing), - traffic measurements, - network configuration management: (such as control of dedicated network resources by a user), - security management, - performance management; 2. clarification of the functions and procedures identified as part of Layer Management; 3. the means of providing a capability for the user to locate faults between multiple networks (or service providers); 4. the following Questions pertaining to remote loop-back control: - how are loop-backs identified? - if a TE performs a loop-back on its B-Channels what cause is to be specified for the rejection of incoming calls? - how are channels on which loop-backs are to be performed identified from a remote location? - identification of the management information to be exchanged for maintenance purposes, - whether the protocol message flows should to be included in the management application service description andor the protocol descriptions of these services. ANNEX 1 (to Question 25/XI) ISDN user-network interface protocol for management protocol applications Annex 1 contains an initial draft Recommendation text defining the protocol applicable to specific remote user equipment maintenance applications (e.g., loop-back control, test calls, error or event reports). Draft Recommendation Q.942 ISDN USER-NETWORK INTERFACE PROTOCOL FOR MANAGEMENT - MANAGEMENT PROTOCOL APPLICATIONS 1. General This................................. 1.1 Scope Management ................................ 2.2 Fault management facilities 2.2.1 Spontaneous error reporting facility 2.2.9 Equipment identification facility 3.1.1.2Maintenance service states of the channels transported by an ST interface, as seen by the terminal 3.2 Control of selftests Procedures .............................. 3.3 Control of loop-backs Procedures for................................ FIGURE 3Q.942 Possible loop-back locations as defined in I.600 Note - ............................................. 3.3.2 Loop-back addressing and selection requirements The ..................................................... 3.3.4 Loop-back activation on existing calls The ......................................................... APPENDIX A (to draft Recommendation Q.942) Table A-1Q.942 shows the requirements on Q.942 services from maintenance operations described in the I.600 Series of Recommendations. TABLE A-1Q.942 Relationship between maintenance Recommendations in the I.600 Series and Q.942 services ============================================================ Question 26/XI - Definitions for switching and signalling (Continuation of Question 18/XI, studied in 1985-1988) Considering (a) that the need for uniformity of terminology in all Study Groups studying digital systems; (b) that the need to base this terminology on a set of fundamental telecommunication definitions; (c) that the need to harmonize the definition of terms, for example, terms such as "call", "connection", "function" and "transit", where there are differences in definition and application by other Study Groups, What definitions should be given to terms used for switching and signalling in the evolving telecommunications networks? ANNEX 1 Terms of reference for Study Group XI on aspects of mobile systems For the forthcoming study period, Study Group XI will direct its efforts to the study of Questions relating to mobile satellite systems of all three mobile services: land, maritime and aeronautical, as well as to the study of Questions concerning only the land mobile service. (Questions 17XI and 18XI.) It is most desirable in the forthcoming period not to lose sight of the problems concerning the maritime mobile service operating not only in the INMARSAT satellite system but also in traditional VHF and HF bands. In these bands, increasing use is being made of the automatic telephone service between ships and land subscribers as well as of the systems of the automatic printing service with their switching to the telex network. The types of services mentioned above will play a decisive role in a new Global Maritime Distress and Safety System (GMDSS), the main provisions of which were adopted by the WARC on Mobile Services in 1987. Some parts of the new GMDSS are already in operation, e.g., the COSPAS- SARSAT system, which has already saved more than 1,500 human lives. Regarding the problem of GMDSS, CCIR Study Group 8, which met in April 1988, requested that the CCITT's attention be drawn to the importance and urgency of studies of Questions connected with the introduction of the GMDSS. The IX CCITT Plenary Assembly agreed that Study Group XI in its future work should take into account this concern expressed by CCIR Study Group 8 for an urgent decision on important problems related to a noble task, namely the saving of human lives.