4. Recommendation I.515 PARAMETER EXCHANGE FOR ISDN INTERWORKING 1. General 1.1 Scope The objective of this Recommendation is to provide overall parameter exchange principles and func- tional descriptions for ISDN interworking. This Recommendation describes the principles for parameter exchange mechanisms. It is recognized that depending on the available (end-to-end) signalling capability, the exchange of parame- ters may use either out- or in-band procedures. Parameter exchange may be necessary to establish compatible interworking functions for a variety of applications. Typical examples where parameter exchange takes place include, terminal adaption compati- bility establishment, modem type selection and voice encoding compatibility establishment. This does not imply, however, any requirement for an ISDN to support network based modem interworking. Figure 1/I.515 illustrates several voice and data applications, supported by different networks and mechanisms. Parameter exchange may be necessary where interworking between different terminals or networks (as per other Recommendations) is required. Note - Where interworking procedures exist, the appropriate references are made herein. M = MODEM IWF = INTERWORKING FUNCTION (May TA(c) = TA WITH CODEC include: Physical Requirements, Signalling Require- ments, Terminal Adaptation Modulation, etc.) FIGURE 1/I.515 Notes to Figure 1/I.515 1. IWFs may be located: within the network(s), separate to the network(s), within the customer's premises. 2. The requirement for interworking between terminals may not be inferred from Figure 1. 3. Figure 1/I.515 is not exhaustive.1.2 Definitions and abbreviations Use is made of the following terms within this Recommendation. These terms do not necessarily refer to any existing protocol structure rather, they define information requirements in the context of this Recommen- dation. - Bearer capability information Specific information defining the lower layer characteristics of the network. - Low layer compatibility information Information defining the lower layer characteristics of a TE or TA. - High layer compatibility information Information defining the higher layer characteristics of a terminal. - Protocol identifier Information defining the specific protocols used by a terminal to support data transfer. - Progress indicator Information supplied to indicate to the ISDN terminal that interworking has occurred. - Out-band parameter exchange Information exchanged via signalling channels which are not within the channel used for user informa- tion transfer. - In-band parameter exchange Information exchanged using the same information channel as that used for the user information trans- fer. 2 Principles 2.1 Types of parameter exchanges Three types of parameter exchange need to be considered: i) end-to-end, out-band as shown in Figure 2/I.515. a) Parameter exchange is accomplished via the D Channel and Signalling System No. 7. FIGURE 2/I.515 Out-band parameter exchange via D Channel ii) end-to-end, in band as shown in Figure 3/I.515. a) via a transit network Note - 64 kbit/s connection type is assumed for ISDN b) direct through an extended IDN Note - The extended IDN shown has 64 kbit/s transmission channel (see I.231), however its signalling system is not compatible with that of the ISDN. FIGURE 3/I.515 In-band parameter exchange iii) Parameter exchange to select IWFs FIGURE 4/I.515 The in-band parameter exchange occurs after the establishment of an end-to-end connection and may provide for establishment of compatibility between the end points, based on characteristics such as protocol, rate adaption scheme and modem type. 2.2 Relationship of parameter exchange to call establishment Parameter exchange may occur: i) prior to Call Establishment (Call Negotiation); In this case parameter exchange will occur using out-band techniques. ii) after Call Establishment, prior to information transfer; In this case parameter exchange may occur using either in-band or out-band techniques. iii) during the information transfer phase of the call. In this case parameter exchange will occur using either out-band or in-band techniques. 2.2.1 Parameter exchange prior to Call Establishment (Call Negotiation) Call Negotiation may be used to satisfy a number of basic call requirements in ISDN. In addition, call negotiation may be necessary for interworking as described in I.510 (between terminals, services and net- works) for: a) Terminal Selection (see I.333, Q.931, Q.932); b) selection of interworking requirements when interworking between ISDN and other dedicated net- works is identified (e.g. modem type); c) the appropriate selection of network (ISDN or other network) functions to support the service required (e.g., use of call progress indicator); d) the selection of network functions when interworking between incompatible terminals is identified or when interworking of different services is required. Each of the requirements a) through d) above are necessary during the call establishment phase, there- fore, call or service negotiation mechanisms should beincluded within basic call establishment procedures. Further study is required. 2.2.1.1 Call Negotiation types Three types of Call Negotiation are currently envisaged. - Bearer capability (BC); - Low layer compatibility (LLC); - High layer compatibility (HLC). The relationship of these information elements to parameter exchange functions is for further study. Note - BC, LLC, HLC are information elements defined in Recommendation Q.931. 2.2.1.3 Transfer of information The transfer of information associated with Call Negotiation is illustrated in Figure 4/I.515. Note 1 - The examination of LLC by the network when the IWF is not an addressed entity, is for further study. Note 2 - The IWF can be distributed (see I.510 for definition of IWF). Note 3 - When the IWF is on the customer premises, examination of additional information elements to satisfy basic call requirements may be appropriate (e.g., sub-address called party ID). FIGURE 5/I.515 2.2.2 After call establishment and prior to information transfer phase This parameter exchange may be necessary when signalling to allow adequate compatibility checking during the call setup phase is not available, or when additional capability checking is required due to charac- teristics of the terminals which are not defined in call establishment procedures. When out-band parameter exchange is used refer to section 3.1.2. When in-band parameter exchange is used refer to section 3.2.1. 2.2.3 During information transfer phase This parameter exchange may be necessary when configurations change during the information transfer phase (e.g., maintenance, sub-channel information). Detailed aspects are for further study. 3. Parameter exchange procedures 3.1 Out-band parameter exchange 3.1.1 Prior to call establishment Refer to Recommendation Q.931 and Q.764. Other protocols are for further study. 3.1.2 After call establishment prior to information transfer phase Refer to Q.931 and Q.764. 3.1.3 During information transfer phase Refer to Q.931 and Q.764. 3.2 In-band parameter exchange 3.2.1 After call establishment prior to information transfer The following parameter exchange sequence identifies one method of establishing compatibility during interworking between an ISDN and existing networks and between ISDNs. - call establishment phase (e.g. refer to Q.931 and Q.764); - originating terminal changes from idle condition to busy condition; - connection enters parameter exchange phase; - connection enters information transfer phase. 3.2.1.1 Voice services Refer to Recommendation G.725. 3.2.1.2 Parameter exchange mechanism for terminal adaption protocol identification Some In-band Parameter Exchange (IPE) Procedures are in existence, e.g., Appendix 1 of Recommen- dation V.110. Two circuit mode terminal adaption procedures are emerging within CCITT (i.e., I.463/V.110 and V.120). In many countries, the Terminal Adaptor (TA) design may not be controlled by the administration/ RPOAs so that special forms of terminal adaption may be deployed. To support multiple forms of terminal adaption in a mixed ISDN/non-ISDN network, terminal adaption implementations which support multiple ter- minal adaption protocols will be required. For use with such implementations, a method is needed for some applications to identify the specific terminal adaption protocol to be used by the multifunctional adaptor (MTA) devices. This will allow the terminal equipment (or appropriate network component), to release the call where compatibility cannot be achieved, or to request the network to provide an appropriate interworking function. examples, for any given instances of communication, different parameters may be required. 4.1 Numbering parameters - subscriber number; - sub-address; - terminal selection (see Recommendation I.333). 4.2 Protocol control parameters Protocol control parameters can be used to identify the protocol supported. An example is the terminal adaption protocol supported, such as V.110, V.120. 4.3 DTE/DCE configuration parameters The protocol identification is performed during the following three steps after the call is placed by using the normal call establishment procedures: APPENDIX B TA protocol self identification This appendix discusses guidelines for self-identification procedures that may be used by multi-protocol terminal adaptor (MTA) implementations in selecting the protocol to be used on an individual connection. It is assumed that the multi-protocol terminal adaptor supports the procedures of I.463(V.110) and I.465 (V.120). Where out-band signalling is available multi-protocol terminal adaptors should function in accordance with the protocol negotiated during call set-up. Self-identification procedures are only applicable where such signalling capabilities are not available. MTAs intended to interwork with Uni-protocol TAs The MTA may initiate transmission as if it were a uni-protocol TA conforming to any of the capabilities pro- vided. The received signals would be examined by the MTA and the MTA should revert to transmission in accordance with the procedures of the protocol of the uni-protocol TA as indicated by the received signals. If compatibility is not achieved it would provide a disconnect. It is noted that there are a range of capabilities that may be implemented in TAs conforming to either I.463 (V.110) or I.465 (V.120). For distinguishing the capabilities of the different TA protocols, an MTA should follow the procedures specified in the individual Recommendations. MTAs intended to interwork with other MTAs The MTA should initiate transmission, following the connect indication, in accordance with Recommenda- tion I.465 (V.120). Note - Self identification can be extended to accommodate multiple protocols. It is only necessary to define the priority for the use of each protocol and a retry procedure. The general rule would be that an MTA would always initiate transmission assuming the protocol of the highest priority supported that has not been tried. The MTA would always delay disconnect, when the received signal is not recognized, for a period long enough for the necessary number of retries (this is protocol and implementation dependent - see, e.g., I.463 (V.110) and I.465 (V.120). APPENDIX C Parameter exchange for selection of IWFs ISDN - PSTN data interworking Note - The preferred methods for modem selection for ISDN - PSTN calls are for further study. C.1.1 Mechanisms which do not require the ISDN user to have prior knowledge of the modem characteristics of the PSTN user. C.1.1.3 Registration The DTE/DCE characteristics of the PSTN user are registered with the ISDN. C.1.2 Mechanisms which may require the ISDN user to have prior knowledge of modem characteristics of the PSTN network user. C.1.2.1 Default Identification Any DTE uses the same default modem characteristics. C.1.2.2 ISDN user selects the modem dynamically. Using available parameter exchange mechanisms (i.e. SN, LLC/BC, IPE) the user selects specific TA/ modem characteristics at the IWF. C.2 ISDN Bearer Capabilities for interworking. C.2.1 3.1 kHz ISDN Bearer Capability. The IWF may pass parameters (e.g. LLC) to the called user when establishing the ISDN portion of the call. the local exchange will insert the pre-subscribed modem type in the path. multi-standard modem at the IWF. The appropriate modem is inserted in the end-to-end path.