home *** CD-ROM | disk | FTP | other *** search
- 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.
-
-
-
-
-