home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
i
/
i515.asc
< prev
next >
Wrap
Text File
|
1993-06-28
|
15KB
|
986 lines
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.